As Turing descended from Mount Compute – with the two iPads of the testimony in his hands as he descended the mountain – he did not realize that the skin of his blog shone as a result of his Compiling the Code.
Turing assembled the entire Geek community and said to them, “These are the things that the Compiler has commanded you to do:”
- Thou shalt not GOTO
- Thou shalt not TODO
- Thou shalt not catch all
- Thou shalt not <br>
- Thou shalt not label thy code to
- Thou shalt not bear false witness or side effects in getters
- Thou shalt not neglect your curly braces
- Thou shalt not desire the Unsafe
- Thou shalt not covet your neighbor's private fields or methods
- Thou shalt not deceive with cleverness in names
But the Geek community did not obey, and the Compiler was not amused:
Neither Turing nor the Compiler may not have actually said these things
Bloggers are a different breed. They’re spending a lot of time investigating issues in a systematic way that is presentable to others. And then they share – mostly just for the fun of it and for the rewarding feeling sharing gives them. Whenever we google for a technical issue, chances are high that we stumble upon such a blog post.
One of the best blogs out there is Petri Kainulainen’s Do You Want to be a Better Software Developer? Petri has also written a book about Spring Data, which is available from Amazon, O’Reilly and Packt Publishing.
Most recently, I have found his two Maven-related tutorials very useful and well-written:
- FindBugs Maven Plugin Tutorial
- Integration Testing with Maven
- Creating Profile Specific Configuration Files With Maven
Also, in 2013, he has written an extensive series of blog posts titled “What I Learned This Week”. Some examples:
Petri’s blog is certainly one that you should follow. His posts are very well structured and quite complete. Currently, he’s also writing an extensive series about jOOQ, which is a very useful additional resource for new jOOQ users.
Thanks for all this great content, Petri!
OK, now this beats everything I’ve seen so far. I can now code in the cloud with Koding.com. From a first, very quick glance, I get:
- A VM with a terminal (looks like a Debian distribution)
- PHP and all sorts of stuff that is already installed
- An app store for apps like PostgreSQL or MySQL
- 1.2 GB of free disk space and 2 GB of RAM
Wow. Coding in the cloud. Sounds awesome. What’s next!? And who are they? See the Koding, Inc. blog for their press release about opening up their services to the public:
I’ve just discovered the Ninja Web Framework. This one isn’t “yet another framework”, it’s actually heavily based on the very popular Play Framework ideas. It seems to provide a substitute for the latter, since Zenexity and Typesafe have formed an alliance to further support Play primarily in the Scala ecosystem. Some people may feel that this makes the Play+Java combination a second-class citizen. The Ninja Web Framework is maintained by a Berlin-based company called FinalFrontierLabs, who were great fans of Play when they were using it in Java. You have to love their company profile:
As some people seem to have regretted Play’s focus on Scala, this framework is certainly one to keep an eye out for in the near future!
A great database has just gotten better. PostgreSQL 9.3 has been released today. While improved reliability and availability is certainly quite a thrilling addition, from the jOOQ perspective, the most interesting features are new SQL syntax elements. These include:
- Better support for JSON
- LATERAL JOIN (or as SQL:1999 calls it: lateral derived table)
- Materialised views
- Updatable views
See all the improvements for yourself:
Erik Meijer (famously known for LINQ, lots of other .NET goodies, and tie-dye shirts of timeless beauty) teams up with Typesafe‘s Martin Odersky (Scala Language) and Roland Kuhn (Akka) to bring you a 7-week-course on the Principles of Reactive Programming, starting on November 4, 2013.
This cooperation of sharp minds can only mean good things, far beyond the scope of this concrete course. Sign up for the Coursera course here:
Curious what Erik Meijer is up to these days? Check out his new company Applied Duality, Inc’s website:
The slogan is quite cheeky:
After being stuck for > 40 years in a first-order flat model of rigid tabular data locked up in a closed world, it is time for a developer revolution. It is time to embrace monads and duality to lift the database industry to the next level.
No matter what programming language we choose, we programmers all share one big misery: Having to deal with calendars. We all get it wrong dozens of times in our working lives. And when we think we finally understood calenders, we get taught better. While some take the time to delve into the misteries of calendars, others are faced with this situation:
Google “programming” and “calendars”, and you’ll find lots of interesting discussions, such as:
In 2015, things might change (again). Here’s an interesting article about what would happen if we stopped coupling our calendars to our earth, moon, and sun – a programmer’s dream! Enjoy…
This blog post I’ve found from 2009 has a nice way of looking at the problem of comparing the ease of use with the ability to reuse. It claims that usability and reusability is always a tradeoff between building
- a heavyweight, coarse-grained software component with few dependencies (very usable)
- a lightweight, fine-grained software component with complex dependencies (very reusable)
The following picture nicely depicts this relationship:
Indeed, coarse-grained components are hard to reuse because they try to solve too many problems in the context of the coarse overall point of view. But I’m not sure if they’re necessarily easier to “use”. Being coarse, and thus complex, they may have solved the problem in the wrong way. And since they’re so complex, they cannot be changed easily to fit a slightly different problem domain. Since time can change the original problem setup (and it will in any project), heavyweight, coarse-grained components often cannot even be used nor reused for their “original” purpose. I.e. a coarse solution that is developed in a project over several years cannot be finished, because it cannot be changed after those four years.
And fine-grained components aren’t necessarily hard to use. It is possible to create components with very little dependencies, such that they do not introduce a lot of complexity. jOOQ is one example of such a component, which has no dependencies itself, apart from the JDK. But jOOQ is a library and not a business module, i.e. it implements horizontal reusability, not vertical reusability.
So, let’s hope the original post was not entirely correct and there is a good, middle way! See for yourself:
As an open source developer, I’m often asking myself why the hell am I going through all of this pain in my free time to deliver quality software, when I’m already doing this in my office?? Sure, it’s fun, you can try out new things, deepen your knowledge in a specific field, it helps boost your career, etc. etc.
But every now and then, I’m reminded of another reason:
I believe in open source
This is just like other people saying
I believe in charity work
I believe in militia politics
I believe in volunteer firefighter engagement
I believe in helping that poor grandma across the street
They do, whereas I…
I believe in open source
All these things make the world go round, without most people noticing, as there is no big fame in it. Of course, there’s always that other point of view on open source. You can make as much money with organised open source, as with organised charity work, or organised militia politics (a.k.a. lobbying), and that’s perfectly fine – why shouldn’t you? But the driving force is always the same, regardless of the pay: It’s belief. Here’s another open source project I’ve recently re-discovered, that has a very nice reason of being, along the same lines. It’s EMMA. Citing the EMMA website:
Until recently, the world of Java development had been plagued by an absurd discrepancy: Java developers had excellent free IDEs, free compilers, free test frameworks but had to rely on code coverage tools that charged an arm and a leg in license fees. As a Java pro, I would like to use the same free coverage tool regardless of whether it is a massive commercial project at work or a small fun project at home. I’ve created EMMA to be that tool.