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 28, 2014 | Aggregated, Developer tips
The other day I participated in a company hackathon and I decided to make use of the Android camera. I’ve always said that the Android APIs are very bad (to put it mildly), but I’ve never actually tried to explicitly say what is wrong and how it could be better. Until now. So, the Camera API is crappy. If you haven’t seen it before, take a look for a minute. You can use it in a lot of wrong ways, you can forget many important things, you don’t easily find out what the problem is, even with stackoverflow, and it just doesn’t feel good. To put it differently – there is something wrong with an API that requires you to read a list of 10 steps, some of which are highlighted as “Important”. How would you write that API? Let’s improve it. And so I did – my EasyCamera wrapper is on GitHub. Below are the changes that I made and the reason behind the change: setPreviewDisplay(..) is required before startPreview(), and it in turn is required before taking pictures. Why not enforce that? We could simply throw an exception “Preview display not set”, but that’s not good enough. Let’s get rid of the method that sets the preview display and then make startPreview(..) take the surface as parameter. Overload it to be able to take a SurfaceTexture as well. We’ve enforced the preview setting, so now let’s enforce starting the preview. We can again throw a “Preview not started” exception from takePicture(..), but that happens at runtime. Let’s instead get rid of the takePicture(..) method out of the...
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