If you need a small, fast Java 1.4 compiler that you can embed in your application, try Janino.
There has been recent discussion about a merge between Jenkins and Hudson, after Oracle pushed the dead weight to Eclipse.
My prediction: Won’t happen.
Why not? Because Eclipse is run by lawyers and developers hate lawyers.
Exhibit A: “Is the Eclipse process so bad? … Yes. It’s very bad (for developers). Bad enough to end many contributions.” (https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Hudson+Reconciliation+Requirements)
Exhibit B: “MIT (or MIT-ish, e.g., ASL, BSD, EDL) license” (same page)
Exhibit C: To work on Eclipse projects, you must become a committer (http://wiki.eclipse.org/Development_Resources). That means signing a contract. You have to have an IP Log. All projects on eclipse.org must submit to the Eclipse Public License (http://www.eclipse.org/legal/).
Why is that? Because IBM is rich and Kohsuke Kawaguchi is poor. So trolls are suing IBM and they won’t sue Mr. Kawaguchi. Which is why IBM is raising their barriers and why Jenkins isn’t.
The projects won’t merge
Would you tell your GMail password to a friend? Your colleagues in the office? Publish it on the Internet?
The reason is that Google uses something called a “token” to allow apps your smartphone to connect to Google services like your mail box, your calendar, etc. The token is like a key on your keychain: Anyone who has the key can open the door it fits. Unlike keys on your key chain, anyone who can pick a token out of the air knows where that door is!
Related article: Catching AuthTokens in the Wild
If you have odd Unicode characters in the bookmarks/table of contents of your PDF viewer when using lualatex 0.60 and the package hyperref, try
Since Friday, a spammer tries to spam me via pingbacks 😦
It’s nice that WordPress lets me move this comment to spam, it’s not so nice that the spam keeps coming back.
But I’m sure they’ll fix that soon 🙂
Documentation usually has these three attributes: It’s incomplete, outdated and plain wrong.
That doesn’t apply to every bit of information in your documentation but it you can be sure the statement above is correct for the whole documentation.
As a consumer of such documents, it’s a nice puzzler to determine into which of the three categories a bit of information belongs.
This leads to the common “we hate documentation” stance that all software developers soon adopt, no matter if they have to write/maintain the documentation or if they have to use it.
As we all know, the only reliable source of documentation are unit tests. But they can still be incomplete (= missing the example you need) or outdated (= missing examples for the latest API).
The solution? Generate documentation from the source code. And I don’t mean “from javadoc in the source code”, I mean literally from the code. If a method is used in a certain way in 317 places in your code and once in a different way, then you have two examples. One of them probably works, the other is probably documents a bug which your tests missed.
This summer, Stefan Henß starts to work on an “extended documentation platform” for Eclipse.