Skip to content, Skip to search

Changes

Philosophy

2,018 bytes added, 9 July
Jenkins -> Travis CI
{{DevelopmentDevelopMenu}}[[ImageJ]], and the [[SciJava]] software stack component collection in general, is developed according to certain biases, which we describe here. This philosophy has evolved over a very long development history, reflecting many lessons learned over a course of decades.
== Open source ==
The SciJava ecosystem is strongly committed to [[open source]] software development. But this software is not an [[open source]] software ''product''—it is an [[open source]] software ''project'' following an [[open source]] development ''process''. ImageJ is funded by taxpayer money, so the project strives to be as transparent as possible, by [http://blog.codinghorror.com/how-to-stop-sucking-and-be-awesome-instead/ doing it in public]!
ImageJ is funded by taxpayer money, so the project strives to be as transparent as possible. There are public [[Source Code|source code repositories]], public [[communication]] channels, public [[project management]] resources, and of course, this [[Help:Contents|community editable website]]. As you can see, we love [http://blog.codinghorror.com/how-to-stop-sucking-and-be-awesome-instead/ doing it in public]! == Extensibility Independent learning ==
[[Extensibility]] is [[ImageJ]]'s greatest strength<blockquote> Tell me and I forget. Teach me and I remember. ImageJ is not just a software application—it is an extensible ''platform'' for the development of image [[:Category:Visualization|visualization]], [[segmentation]], [[:Category:Registration|registration]], Involve me and I learn. &mdash;[[wikipedia:Category:AnalysisXun Kuang|analysisXunzi]] routines.</blockquote>
Isaac Newton attributed his success The ImageJ and SciJava communities intend to foster not only scientific ''independent thinking'', but just as importantly, ''[http://conference.imagej.net/2015/pariksheet-nanda/transcript.pdf independent learning]''. We want to not only [https://en.wikipediawiktionary.org/wiki/Standing_on_the_shoulders_of_giants standing on the shoulders of giants]. The SciJava software stack's powerful [[plugingive_a_man_a_fish_and_you_feed_him_for_a_day;_teach_a_man_to_fish_and_you_feed_him_for_a_lifetime teach people how to fish]] mechanism and [[open source]] software process codify that metaphor into the software itself. Not only are there many different types of plugins, but it is also possible ''teach them how to extend the system with your own new types of plugins. See the [[Extensibility]] page for detailslearn''.
== Interoperability ==As such, responses to questions on [[Communication|ImageJ public channels]] will often begin with "What have you tried?" or "Can you make a minimal, complete, verifiable example?"—see the [[Bug reporting best practices]] for details. A good rule of thumb for questioners is to "put as much effort into your question as you expect to be put into its reply"—and for responders, to cordially encourage this behavior in questioners. Responses may give detailed macro or script solutions to image analysis questions, but they will also often include details of ''how such solutions were produced'', as well as ''how they might be improved or tailored to other similar scenarios''.
One of the central goals of We are always looking for more ways to improve the [[SciJava]] software stack is to extend Java's mantra meet this goal of "write once, run anywhere" in new directions: encouraging independent learning. Write to the [[Help|ImageJ OPSforum]] for image processing algorithms, and [[SCIFIO]] for scientific image I/O.with your ideas!
[[ImageJ2]] commands work not only in the [[ImageJ]] user interface, but also from many other applications in the [[History|SciJava ecosystem]], including [[CellProfiler]], [[OMERO]], [[KNIME]] and others.== Extensibility ==
== Why Java? ==[[Extensibility]] is [[ImageJ]]'s greatest strength. ImageJ is not just a software application—it is an extensible ''platform'' for the development of image [[:Category:Visualization|visualization]], [[segmentation]], [[:Category:Registration|registration]], and [[:Category:Analysis|analysis]] routines.
While it was once true that Java is always slower than Isaac Newton attributed his success to [[wikipedia:Standing on the equivalent in C++, this is no longer shoulders of giants|standing on the caseshoulders of giants]]. The [http://paulbuchheit.blogspot.com/2007/06/java-is-faster-than-c.html There[Architecture|SciJava component collection]] have 's powerful [http://www.azulsystems.com/blog/cliff/2009-09-06-java-vs-c-performanceagain been[plugin]] quite mechanism and [http://vanillajava[open source]] software process codify that metaphor into the software itself.blogspotNot only are there many different types of plugins, but it is also possible to extend the system with your own new types of plugins.com/2011/08/java-can-be-significantly-faster-than-c.html a few benchmarksSee the [[Extensibility] comparing Java vs C++ performance, [http://keithlea.com/javabench/ this one] probably being the grandfather of allpage for details.
Pragmatically== Interoperability == One of the central goals of the [[Architecture|SciJava component collection]] is to extend Java's mantra of "write once, one should note that there is not really a big difference run anywhere" in performance when comparing Java to C++new directions: [[ImageJ Ops]] for image processing algorithms, and [[SCIFIO]] for scientific image I/O.
Java programs run without trouble and without recompiling on [[ImageJ2]] commands work not only in the major platforms: Windows[[ImageJ]] user interface, Mac OS X and Linux. And plugins compiled on one platform but also execute on all from many [[:Category:Related Software|other platforms without recompiling. And profiling applications]] in the [[SciJava|SciJava ecosystem]], including [[CellProfiler]], [[OMERO]], [[KNIME]] and debugging is easier with Java than with C++. And all programs/plugins double as libraries[[Alida]].
So the true reason why we use Java is probably: it makes [[ImageJ]] accessible.== Compatibility ==
See also Backward compatibility is one of ImageJ's most important goals. It must remain possible to use existing [[http://loci.wisc.edu/faq/isnt-java-too-slow Isn't Java too slow?plugins]] and [http://loci[macros]] with new versions of ImageJ.wisc.edu/faq/why-java Why is your software written in Java?See the [[Compatibility]] from the LOCI FAQpage for details.
== Release early, release often =={{SideboxBox
| title = What's the alternative?
| width = 30%
| body float = right| text = Some projects opt to release their entire software stack with a single monolithic version number. This has one extremely nice ramification: it clearly communicates which versions of which software components are intended to be compatible with one another.
<p>
For example, the [[OME]] project (which includes [[OMERO]] and [[Bio-Formats]]) employs this approach to versioning and release management. Before each release, the entire OME team performs careful and thorough integration testing of all components.
<th colspan="3">Versioning strategies</th>
<tr>
<td>''StrategyVersioning''</td>
<td>'''BOM'''</td>
<td>'''Monoversioned'''</td>
</tr>
<tr>
<td style="vertical-align: top">''Releases''</td>
<td>'''RERO'''</td>
<td>'''"Big bang"'''</td>
</tr>
<tr>
</table>
}}
== ImageJ subscribes to the [[wikipedia:Release early, release often |release early, release often]] (RERO) mantra often cited in software engineering circles. In particular—and especially because there is a small core development team—the project is driven by [http://blog.codinghorror.com/boyds-law-of-iteration/ Boyd's Law of Iteration]: '''speed of iteration beats quality of iteration'''. That is not to say that we do not strive for quality—we do. But we have found through experience that more releases, together with guiding user feedback, push a project forward more efficiently than a slower release cycle does. To ensure releases can happen quickly, each SciJava component is independently released and versioned, using [[Architecture#Reproducible_builds|reproducible builds]] with a "release ready" <code>master</code> branch. This allows individual SciJava components to be released with the [[Travis CI|push of a button]], in a ''timespan less than five minutes''. This puts bug-fixes into the hands of users as quickly as possible. == Convention over configuration == With increased [[modularity]] often comes increased complexity. One key way of addressing this issue is to provide sensible defaults (e.g., the [http://athinkingperson.com/2010/06/02/where-the-big-green-copier-button-came-from/ big green Xerox button]) as a way of dealing with complex software programs. We embrace the philosophy of [[wikipedia:Convention over configuration|convention over configuration]] utilized by many large software projects in recent years. For this reason, SciJava projects use the [[Maven]] build tool for [[project management]]. == Why Java? == While it was once true that Java is always slower than the equivalent in C++, this is no longer the case. [http://paulbuchheit.blogspot.com/2007/06/java-is-faster-than-c.html There have been] quite [http://vanillajava.blogspot.com/2011/08/java-can-be-significantly-faster-than-c.html a few benchmarks] comparing Java vs C++ performance, [http://keithlea.com/javabench/ this one] probably being the grandfather of all.
ImageJ subscribes to the [https://en.wikipedia.org/wiki/Release_earlyPragmatically,_release_often release early, release often] mantra often cited in software engineering circles. In particular—and especially because one should note that there is not really a small core development team—the project is driven by [http://blog.codinghorror.com/boyds-law-of-iteration/ Boyd's Law of Iteration]: '''speed of iteration beats quality of iteration'''. That is not big difference in performance when comparing Java to say that we do not strive for quality—we do. But we have found through experience that more releases, together with guiding user feedback, push a project forward more efficiently than a slower release cycle doesC++.
To ensure releases can happen quicklyJava programs run without trouble and without recompiling on the major platforms: Windows, each SciJava component is independently released Mac OS X and versioned, using [[reproducible builds]] with a "release ready" <code>master</code> branchLinux. And plugins compiled on one platform also execute on all other platforms without recompiling. This allows individual SciJava components to be released And profiling and debugging is easier with the [[Architecture#Jenkins|push of a button]], in a ''timespan less Java than five minutes''with C++. This puts bug-fixes into the hands of users as quickly And all programs/plugins double as possiblelibraries.
== Convention over configuration ==So the true reason why we use Java is probably: it makes [[ImageJ]] accessible. See also [http://loci.wisc.edu/faq/isnt-java-too-slow Isn't Java too slow?] and [http://loci.wisc.edu/faq/why-java Why is your software written in Java?] from the LOCI FAQ.
With increased modularity often comes increased complexity. One key way of addressing this issue is to provide sensible defaults (e.g., the [http://athinkingperson.com/2010/06/02/where-the-big-green-copier-button-came-from/ big green Xerox button]) as a way of dealing with complex software programs. We embrace the philosophy of [httpCategory://en.wikipedia.org/wiki/Convention_over_configuration convention over configuration] utilized by many large software projects in recent years. For this reason, SciJava projects use the [[Maven]] build tool for [[project managementDevelopment]].
Bureaucrat, emailconfirmed, incoming, administrator, uploaders
11,833
edits