Here’s a similar talk (less funny more scary) about MySQL:
Here’s a similar talk (less funny more scary) about MySQL:
This is the list we’ve all been waiting for. The top 10 productivity booster techs for programmers that – once you’ve started using them – you can never do without them any longer.
Here it is:
You’ve never used Git? Get started with this guide.
No kidding. Have you ever googled for anything tech-related back in 2005? Or altavista’d something back in 2000? Or went to FidoNet in search for answers in 1995? It was horrible. The top results always consisted in boring forum discussions with lots of un-experts and script kiddies claiming wrong things.
These forums still exist, but they don’t turn up on page 1 of Google search results.
Today, any time you search for something, you’ll have 2-3 hits per top 10 from Stack Overflow. And chances are, you’ll look no further because those answers are 80% wonderful! That’s partially because of Stack Overflow’s cunning reputation system, but also partially because of Stack Overflow’s even more cunning SEO rewarding system. (I already got 98 announcer, 19 booster, and 5 publicist badges. Yay).
While Stack Overflow allows its more active user to pursue their vanity (see above ;-) ), all the other users without any accounts will continue to flock in, finding perfect answers and clicking on very relevant ads.
Thumbs up for Stack Overflow and their awesome business model.
We’re a small startup. Keeping costs low is of the essence. With Office 365, we only pay around $120 per user for a full-fledged Office 2013 suite, integrated with Microsoft Onedrive, Sharepoint, Exchange, Access, and much more.
In other words, we get enterprise-quality office software for the price of what students used to pay, before.
And do note, Office 2013 is better than any other Microsoft (or Libre) Office suite before. While not a 100% Programmer thing, it’s still an awesome tool chain for a very competitive price.
While Eclipse is great (and free), IntelliJ IDEA, and also phpStorm for those unfortunate enough to write PHP are just subtly better in almost every aspect of an IDE. You can try their free community edition any time, but beware, you probably won’t switch back. And then you probably won’t be able to evade the Ultimate edition for long ;-)
PostgreSQL claims to be the world’s most advanced Open Source database, and we think it’s also one of the most elegant, easy, standards-compliant databases. It is really the one database that makes working with SQL fun.
We believe that within a couple of years, there’s a real chance of PostgreSQL not only beating commercial databases in terms of syntax but also in terms of performance.
Any time you need a data storage system with a slight preference for SQL-based ones, just make PostgreSQL your default choice. You won’t be missing any feature in that database.
Let’s hear it for PostgreSQL.
Java is almost 20 years old, but it’s still the #1 or #2 language on the TIOBE index (sharing ranks with C), for very good reasons:
While some languages may seem a bit more modern or sexy or geeky, Java has and will always rule them all in terms of popularity. It is a first choice and with Java 8, things have improved even more.
Now, learning this from the jOOQ blog is really unexpected and a shocker, but we think that jOOQ fits right into this programmer’s must-have top-10 tool chain. Most jOOQ users out there have never returned back to pre-jOOQ tools, as they’ve found writing SQL in Java as simple as never before.
Given that we’ve had Java and PostgreSQL before, there’s only this one missing piece gluing the two together in the most sophisticated way.
When you try Less CSS for the first time, you’ll think that
Why isn’t CSS itself like this!?
And you’re right. It feels just like CSS the way it should have always been. All the things that you have always hated about CSS (repetitiveness, verbosity, complexity) are gone. And if you’re using phpStorm or some other JetBrains product (see above), you don’t even have to worry about compiling it to CSS.
As an old HTML-table lover who doesn’t care too much about HTML5, layout, and all that, using Less CSS makes me wonder if I should finally dare creating more fancy websites!
Never again without Less CSS.
Yes, sometimes, jQuery can be overkill as is indicated by this slightly cynical website: http://vanilla-js.com
Do note that we’ve also published a similar library for Java, in case you’re interested in jQuery-style DOM XML manipulation. Along with Java 8’s new lambda expressions, manipulating the DOM becomes a piece of cake.
C8H10N4O2 (more commonly known as Caffeine) is probably the number one productivity booster for programmers.
Some may claim that there’s such a thing like the Ballmer Peak. That might be true, but the Caffeine Peak has been proven times and again.
Have Dilbert’s view on the matter:
We’re certainly not the only ones believing that there is such a thing as a programmer-productivity-booster. Enjoy this alternative list by Troy Topnik here for more insight:
Yeah right. A bargain. Read CNN’s 10 other things Facebook could have bought with $19 billion.
We at Data Geekery are more down to earth, selling actual value to our own customers. So we take the opportunity to issue this friendly reminder about what happens when you and your shareholders believe that a primitive chat service is worth $19B because of its oh-so-many users:
So, should our own business not work out, we can still make tons of money this year through PUT warrants on FB. Because the above is not the only issue with Facebook. Check out this video:
Have you ever thought about “Free” Open Source with commercial support vs. commercial software? We have and we found that the following is true:
… is the best business model for companies selling services for very complex OSS software where customers might lack skilled personnel. This includes things like
The above systems can cause terrible pain to your productive environments when they crash. You want to have extremely skilled fire fighters ready when your system goes down. Some of the above systems have been said to be deliberately complex in order to be able to pursue this particular business model.
… is the best business model for companies selling very simple, easy to use software where customers do not rely on skilled personnel in the event of a crash. This is particularly true for
The above software are so easy to handle and to maintain, their vendors would hardly make any money with support. Granted, support is always included in the license fees. That’s just part of the service quality.
Military Campaigns?? Haha. Let’s meet Capt. DBA, mastering Sun Tsu’s Art of SQL:
Citing from the book cover:
Do you view database applications as military campaigns?
Do you see data as row upon row upon row of enemy columns to be winnowed down and slashed away? [sic!]
SQL veteran Stéphane Faroult does.
This is a book about SQL, doing marketing by comparing SQL to war. Well, others might claim that SQL is fun and writing SQL with jOOQ is even more fun. So, after Sun Tsu’s Art of SQL, and after the Vietnam of Computer Science, meet now jOOQ: the Peace Treaty between SQL and Java.
The MEDIT Symposium is one of this year’s international conference gems that you shouldn’t miss, if you’re into Open Source! It features three very interesting tracks
I’m delighted to line up my own talk about jOOQ with Apache committers (Cassandra, Cordova, Isis), Groovy Language Toolkit developers, researchers and book authors. This mix of topics will certainly lead to inspiring discussions at lunch and at the later happy hour.
Apart from the fact that the admission fee is very reasonable, there’s nothing like an escape from cold northern October to Sicilly, southern Italy:
I’m looking forward to meeting you numerously at the MEDIT Symposium in October 2013!
We’re all Software Engineers of one type or another. Most of us have one thing in common, though: We’re lazy. And we know that someone else was less lazy and has already solved that tedious problem that we’re on. And because we’re not only lazy but also stingy, we search for Free Open Source software.
Here are some things to look out for, when evaluating an Open Source software (in no particular order)
This is one of my favourites. It is very easy to google. No one is completely safe from these annoyances. But when you find stack traces, bug reports, investigate them closely.
It’s a matter of good design to be able to avoid NullPointerExceptions and ClassCastExceptions. It happens to everyone. But no NullPointerException should be thrown from a place that can be statically discovered by the Java compiler or with FindBugs.
Needless to say that the list of no-go exceptions thrown from a database library, for instance, can be extended with SQLExceptions due to syntax errors produced by that library.
For larger projects, the community also extends to Stack Overflow, Reddit, Twitter, etc. These next steps are a sign of popularity of an Open Source software, but not necessarily a sign that you should use them. Also, don’t be blinded by users saying “hey this is so cool”, “it just made my day”, “best software ever”. They say that to everyone who’s supporting them out of their misery (or laziness, see the intro of this post).
What you should be looking out for is whether the community is discussing visions, strategies, features, truly awesome ideas that can be implemented next year, in the next major release. It’s a true sign that not only the software will probably stick around, it will also become much better.
The converse to this is a community that mainly discusses bugs (see NullPointerException, ClassCastException). Unlike a “visionary” community, a “buggy” community will just create work, not inspiration to the vendor. But which one’s the chicken, which one’s the egg?
Another converse to this is a community that is disappointed by the false promises given by the visions of the vendor. I often have a feeling that Scala’s SLICK might qualify for that as it introduces an insurmountable language-mapping impedance mismatch between its own, LINQ-inspired querying DSL and SQL.
That’s easy to discover. Do you really want that? The best and most authoritative information should come from the software vendor, not some weirdo forum on the web that you’ve googled.
A good example are PostgreSQL’s Manuals.
A rant about bad examples can be seen here:
Don’t be deceived by the idea that it might get better eventually. Poorly documented software will be poor in many other aspects. And it’s such an easy thing to discover!
Of course, the “right” amount of documentation is an entirely other story…
Search for release notes and see if you’ll find something that roughly corresponds to semver.org. You will want patch releases when your Open Source software that you’re using in mission-critical software fails. When you get a patch release, you don’t want 50 new features (with new NullPointerExceptions, ClassCastExceptions).
Again, we’re in times of GitHub. The good old CVS times are over, where HTML was still used to share cooking recipes. Check if your Open Source software uses those tools. If they show that they’re using them. It will help you ascertain that the software will still be good in a couple of years if the vendor isn’t crushed by the mess they’ve gotten themselves in.
Now that is a sign not everyone may agree upon, I guess. But after the experience I’ve made in previous jobs, I strongly believe that software that has evolved out of necessity before making it a product really suffers from its legacy. It wasn’t a product from the beginning and it has strong ties to the vendor’s original requirements, which doesn’t bother the vendor, but it will bother you. And because the vendor still has very strong ties to their offspring, they won’t be ready to make fundamental changes in both code and vision!
Specifically, in the database field, there are a couple of these software, e.g.
Note, I don’t know any of the above tools, so they may as well be awesome. But be warned. They weren’t designed as products. They were designed for a very narrow purpose originating from a pre-Apache context.
Generics were introduced in 2004 with Java 5. Now that the heated debates about generic type erasure are over, generics are well adopted. Or aren’t they? The latest stable release 3.2.1 of Apache Commons Collections is still not generified! That must’ve been the number 1 reason why people had started shifting to Google Guava (or its predecessors) instead. There’s not much making for a lousier day than having raw types (or eels) slapped around your face.
The other thing that you should look out for, though, is over-generification. Generics can become really hard, even for top-shot Java architects. A common blunder is to strongly correlate subtype polymorphism with generic polymorphism without being aware of the effects. Having too many generics in an API is a good sign for an architecture astronaut. (or a design astronaut in this case). We’ll see further down how that may correlate with the person behind the design decisions.
Here’s how to find out, who’s behind the Open Source software. While this isn’t important for a small, geeky tool, you should be very interested in the vendor as a person when looking for a strategic OSS addition, especially if you’re dealing with a benevolent dictator. The vendor should be:
Even if this is Open Source, there’s no point in being arrogant or conceited. The vendor should treat you like a customer (as long as you’re not trolling). Open-mindedness will eventually lead to the better product in the long run.
Now, (Free) Open Source is nice for many reasons. As a vendor, you get:
True? Yes. But that’s true for commercial software as well. So what’s the real reason for doing Open Source? It depends. Adobe for instance has started opening up a lot, recently, since their acquisition of Day Software. All of JCR, JackRabbit, the upcoming JackRabbit Oak, Sling and Felix are still at Apache with the original committers still on board. But one can certainly not say that Adobe has no commercial interests.
OSS vendors should think economically and build products. Eventually, they may start selling stuff around their core products, or separate community and commercial licenses. And unlike they get too greedy (see Oracle and MySQL, vs RedHat and MariaDB), that can make commercial Open Source a very interesting business, also for the customer who will then get the good parts of Open Source (partially free, open, with a vibrant community) along with the good parts of commercial software (premium support, warranties, etc.)
In other words, don’t choose overly geeky stuff. But you might have recognised those tools before (poor documentation, no semantic versioning, poor tooling).
To wrap this up, here’s an obvious last one. Many Open Source products don’t show any traction by the vendor. That goes along well with the previous point, where the vendor has no commercial interest. Without commercial long-term interest, they’ll also lose all other interest. And you’re stuck with maintaining a pile of third-party code yourself (fixing its many many ClassCastExceptions, NullPointerExceptions).
You should chose Open Source just like commercial software. Economically.
If Open Source fails you on any of the above, the joke will be on you, the customer. You’ll get a bad product, and you’ll pay the price with exaggerated maintenance on your side, which you thought you’d avoid by chosing something free. Nothing is free. Not even Free Open Source. Ask the Grumpy Nerd
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
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: