Note to self: If you create a Java application and think you need DI but not AOP, then do not automatically reach for containers like Spring, CDI, Guice. Just do all construction and wiring in the standard main method.
Suggestions for other/better Free/Open Source plugins for current Intellij CE are welcome:
In its “Random Points” column, the June 2015 issue (Vol.5 #4) of Lidar News, recently renamed LidarMag, contains an opinion piece called “Open Source Mania” (PDF) by Lewis Graham, a director of the board with ASPRS, the organization that defines the LAS file format.
The article contains grains of interesting and potentially relevant comments on the LGPL, but without properly spelling things out: The LGPL – if not amended with a static linking exception as in the LASzip license – has “copyleft” implications when the library code is statically linked, which is somewhat similar to but not as strict as the “strong copyleft” nature of the GPL. I recommend reading the LGPL section of the “Copyleft Guide” or a good article on the Open Source “risks” and considerations during corporate acquisitions and mergers.
Having said that, Lewis Graham’s piece contains many inaccuracies and unfair judgements:
1) The author underhandedly attacks Martin Isenburg’s broadly supported attempts to have the LGPL-licensed de-facto standard LASzip accepted as an Open Standard and then goes into a rant about the GPL, while lumping both licenses together as “viral”. The LGPL – not the GPL – explicitly allows the use as dynamically linked library without any licensing impact on the main program. Combining the attack on the LASzip community with a rant against GPL while ignoring the main difference between LGPL and GPL is unfair to say the least.
Lewis also fails to mention that the LASzip license is actually LGPL with an additional clause that explicitly allows even static linking without licensing impact on the main program.
3) The article misleadingly mentions the Free Software Foundation as the “anchor organization” of Open Source, repeats the old misunderstanding that “Free Software” should not cost money and fails to mention the “Free Software” definition by the FSF.
4) The author spreads long debunked FUD (fear, uncertainty, doubt) about the GPL, claiming that all “code [that] touches GPL code in any manner [..] is now GPL”. In particular he makes false claims that the following uses of GPL code would be “viral”:
- Executing a GPL licensed program from a script via process execution (“Unix fork”) explicitly does not impose any licensing restrictions on that script, as per GPL FAQ
- Derived works that incorporate GPL licensed code, do not automatically become GPL licensed. Only when the derived work is distributed the following applies (quoting GPLv2, section 6): “Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions.”
5) The author repeatedly refers to an “Open Software Foundation”. He seems to confuse or conflate Open Source Initiative (OSI) and Free Software Foundation (FSF). The actual “Open Software Foundation” – later merged into “The Open Group” – has not much to do with either OSI, FSF or software licenses.
6) The author keeps calling the GPL “toxic”, while in fact the GPL is a widely known and court-proven license in the software industry that many companies use successfully as part of their business models, for example Redhat (Linux), Oracle (MySQL), etc. Especially Dual Licensing based business models actually benefit from the relatively restrictive nature of the GPL.
7) The author praises the MIT license as “reasonable” because of its permissive nature (i.e. not imposing any significant licensing restrictions on derived works). As he makes that judgement he takes only the perspective of companies that want to use Open Source libraries in their proprietary closed-source products. He ignores the perspective of Open Source developers, communities and companies who want to protect their work from embrace and extend and other hostile take-over strategies and deliberately use copyleft licenses like the GPL to protect their software.
8) Overall, the author fails to accept that it is the copyright holders freedom to chose a license that suits their needs and intentions.
A widely unnoticed revolution is going on in the field of capturing landscapes for mapping and other geographic purposes, and it is laser based:
LiDAR is the technology that uses lasers on small airplanes to literally scan in whole geographic regions and turns them into 3d point clouds. In many ways, especially for high-resolution 3D elevation data, LiDAR is already replacing traditional satellite based approaches, and enables a plethora of applications in many fields of science and business.
So far, the de-facto standard file formats for storing these “point clouds” are LAS and its compressed variant LASzip (Open Source, LGPL, developed by the German software engineering firm rapidlasso).
But recently ESRI, the market leader for Geographic Information System (GIS) software, has stepped into the arena with a closed source compression format, deceptively called “Optimized LAS” (aka *.zlas), and is positioning it as a direct competitor to the widely used Open Source LASzip format.
The closed-ness of the ESRI file format and the resulting fragmentation of the LiDAR community and its data stores, has now lead to a concerted “Open Letter of the Need for Open Standards in LiDAR“, signed by many representatives from LiDAR related companies, research institutions and the wider geo-informatics community.
I hope that this is a step towards protecting the LAS format from “hostile takeover” by ESRI and I have added my name to the signature list today.
In the very least the Open Letter will raise awareness of the importance of Open Standards and Open Source in the essential field of geographic data, data about our planet, about the world we all live in, which should be Open Data, available to all via Open Standards via Open Source tools, not locked away in vendor-proprietary binary formats that can only be read and processed using that single vendor’s tools.
I would like to group skill items from typical Java developer resumes – aka CVs – in a somewhat standardized way. See this jsfiddle for some work-in-progress.
I came up with the primary and secondary categories listed below, each with some sample items.
Your feedback is highly appreciated. Please comment on this blog post.
- Java features and APIs:
- Configurable JVM feature (Garbage collection, Remote debugging, JMX, etc)
- Java language feature (Generics, Threads, Annotations, Enums, Lambdas, …)
- Java SE API (Collections, Date/Time, NIO, java.util.concurrent, …)
- Java EE API (EJB, JMS, JPA, JSF, JSP, …)
- Java SE UI (Swing, JavaFX, WebStart, Applets, …)
- 3rd party Open Source web frameworks (Struts, Wicket, Spring MVC, …)
- Other 3rd party Open Source framework (Spring, Hibernate, …)
- Closed-source vendor technology (Java based but no JSR)
- Java Tools/Servers:
- Application Servers (Websphere, Weblogic, JBoss, Glassfish, Tomcat, Jetty, …),
- Developer Tools (IntelliJ, Eclipse, Netbeans, …)
- Build automation tools (Maven, Ant, Jenkins, Teamcity, Bamboo, …)
- Profiling and test tools (JVisualVM, SoapUI, JMeter, …)
- Methodologies (software engineering approaches and practices):
- Project level: Agile, Waterfall, RUP, …
- Engineering level: Dependency Injection (DI), Object-Oriented Development (OOP), Continuous Integration (CI), …
- Relevant non-Java technologies:
- Scripting languages (bash, Perl, ksh, Groovy, ruby, etc)
- Operating systems (Linux, MacOS, Solaris, …)
- Database servers (Oracle, MS SQL server, Sybase, …)
- Team tools (Confluence, JIRA, Crucible, …)
- Other programming languages (C, C++, Cobol, Fortran, Scala, …)