by Bozho | May 11, 2014 | Aggregated, Opinions
Recently I’ve been trying to get a bit into music theory, machine learning, computational linguistics, so I ended up looking at libraries and tools written by the scientific community – examples include the Stanford Core NLP library, GATE, Weka, jMusic, and several more. The general feeling is that scientific libraries have mostly bad code. I will not point fingers, but there are too many freshman mistakes – not considering thread-safety, cryptic, ugly and/or stringly-typed APIs, lack of type-safety, poorly named variables and methods, choosing bad/slow serialization formats, writing debug messages to System.err (or out), lack of documentation, lack of tests. Thus using these libraries becomes time consuming and error prone. Every 10 minutes you see some horribly written code that you don’t have the time to fix. And it’s not just one or two things, that you would report in a normal open-source project – it’s an overall low level of quality. On the other hand these libraries have a lot of value, because the low-level algorithms will take even more time and especially know-how to implement, so just reusing them is obviously the right approach. Some libraries are even original research and so you just can’t write them yourself, without spending 3 years on a PhD thesis. I cannot but mention Heartbleed here – OpenSSL is written by scientific people, and much has been written on topic that even OpenSSL does not meet modern software engineering standards. But that’s only the surface. Scientists in general can’t write good code. They write code simply to achieve their immediate goal, and then either throw it away, or keep using it...
by Bozho | Apr 25, 2014 | Aggregated, Opinions
Below are several development “methodologies” that are popular and even industry-standard: Hype-Driven Development – you are either a startup, or you are given the freedom to choose whatever technology you like for your new cool-cutting-edge-distrupting-innovative-did-I-say-cool project. What technologies to use? The recently overhyped ones, of course. Let’s do it in Node.js, and you have to make it reactive, and do DevOps, even though your Linux experience is limited to running Ubuntu on your desktop, and store the data in MongoDB (it’s web-scale!). Speaking of web-scale, you will obviously need to go to the cloud. Then all of a sudden you have an unintelligible codebase, broken servers, pages take a second to load, you lose data every now and then, and you are unable to actually scale. But hey, you used cutting-edge, web-scale reactive technologies that you didn’t understand when you started, and were not applicable to your domain. But now your write a blogpost describing how to solve a problem with them, that has been solved for decades with other technologies. And you post it to hacker news, contributing to the hype. Demo-Driven Development – you work in a team, part of a big organization that has adopted Agile/SCRUM. Or you are a “lean startup” and define the projects on the fly. In both cases the project does not have a clearly defined goal, but somehow money are being poured into it, so it has to keep going. The end result doesn’t seem to matter, but process has to be followed and you need to be be able to demo stuff to the stakeholders. So you write your code...
by Bozho | Apr 3, 2014 | Aggregated, Opinions
Java is the most widely used language in the world ([citation needed]), and everyone has an opinion about it. Due to it being mainstream, it is usually mocked, and sometimes rightly so, but sometimes the criticism just doesn’t touch reality. I’ll try to explain my favorite 5 misconceptions about Java. Java is slow – that might have been true for Java 1.0, and initially may sounds logical, since java is not compiled to binary, but to bytecode, which is in turn interpreted. However, modern versions of the JVM are very, very optimized (JVM optimizations is a topic worth not just an article, but a whole book) and this is no longer remotely true. As noted here, Java is even on-par with C++ in some cases. And it is certainly not a good idea to make a joke about Java being slow if you are a Ruby or PHP developer. Java is too verbose – here we need to split the language from the SDK and from other libraries. There is some verbosity in the JDK (e.g. java.io), which is: 1. easily overcome with de-facto standard libraries like guava 2. a good thing As for language verbosity, the only reasonable point were anonymous classes. Which are no longer an issue in Java 8 with the the functional additions. Getters and setters, Foo foo = new Foo() instead of using val – that is (possibly) boilerplate, but it’s not verbose – it doesn’t add conceptual weight to the code. It doesn’t take more time to write, read or understand. Other libraries – it is indeed pretty scary to see a class...
by Bozho | Mar 19, 2014 | Aggregated, Developer tips, Opinions
Java 8 introduces the Optional class. In a nutshell, instead of returning null, and then checking for null, you return an Optional instance, which can either have or not have a value set. That way you don’t fail with NullPointerException. I won’t discuss whether the Optional type will eliminate NPEs completely (it won’t). Instead I’ll discuss things from a different perspective – API design. In addition to Java’s Optional, I’ll show guava’s Optional and scala’s Option, and compare them. An API, as Joshua Bloch suggests, should be as small as possible, but no smaller. The conceptual weight of an API should be minimized, and if you wonder whether to include something in your API or not, then you should leave it out. An API should be easy to use, and hard to misuse, and ideally should have one (or two) main usage patterns. The Optional type is a good example of having to make all these choices. What is the default usage of this? You get an optional type, and you want to execute some piece of code only if there is a value set. You could obviously do that by comparing to null, but you often tend to forget that and the optional types force you to realize that this value can actually be unset. The second important use-case is to be able to easily provide a default value, if none is set. Let’s first start with the worst of the three (in my opinion) – scala’s Option. At first it seems that this class offers you a lot of functionality. But, as it is normal for scala,...
by Bozho | Mar 8, 2014 | Aggregated, Opinions
Are you using an IDE, or an editor? Are you a “hardcore” programmer, or you are one of those sissy modern developers that use IDEs? Have you personalized your emacs or vim to make you 200% more productive? Or do you think that emacs is useless, at least for Java. Either way, it’s an interesting topic to discuss – what are the pros and cons of using an IDE vs using a customizable text editor (vim/emacs/Sublime/…). And of course, I’m starting with the disclaimer that the distinction between “IDE” and “editor” is not that sharp. Let’s first look at the trivial example – Java (and C#). It is a no-brainer there and the IDE wins by a huge margin, because of all the wonderful features like refactoring, debugging, hierarchies, integration with frameworks and build tools. Writing Java in anything other than an IDE should be restricted only for educational purposes, otherwise you are losing too much. But it’s not that black-and-white for other languages, where the IDEs are not that mature or you cannot have some of the features that you have in statically-typed/compiled/jvm/.. languages. Let’s take Groovy. A JVM language. The IDE has syntax coloring, autocomplete where possible, jumping to files with shortcuts. You get that with text editors as well. But with a text editor you can easily plug shell scripts that run your grails application and then run selenium tests, while running a grails application from within the IDE is (or at least used to be) painful. So, you might be better off going for a text editor? Additionally, the IDE may leak something into the...
by Bozho | Feb 25, 2014 | Aggregated, Developer tips, Opinions
Many websites (including big ones like Adobe, Yahoo, LinkedIn, Gawker, etc.) store user passwords insecurely. Either in plain text, or encrypted (reversible), or using a broken or brute-forceable hash function. Many websites continue to be built with poor password storage mechanism. So what? Well, if the database leaks somehow (and it obviously happens, see the link above), then users are in trouble – not only their accounts on the problematic site is compromised – many of their accounts around the web may be compromised, because of the natural tendency of users to reuse passwords. So if your site is broken, it’s not only about you – it’s about your users’ other accounts, and that alone means the matter is very serious. We know how to implement it, yes – use bcrypt/PBKDF2/scrypt. We know, but many people don’t. So I thought it may be good to give good websites a way to prove to their users that they take the password issue seriously. So I created SaltedHashed.com (as a weekend project). It requires website owners to expose their password-storing mechanism as a REST-like API endpoint, which my service invokes periodically to check if everything is ok. The invocation consists of a random-generated password, and the website must respond with the algorithm it uses, together with the final form of the password that is stored in the database. After the process is successful, the site gets a badge (like those “Valid XHTML”, “Valid CSS”, “Secured by VeriSign”, etc. badges that we (used to) have) which says “We store passwords securely” and links to a page that gets the up-to-date status of...
Recent Comments