Scheduling Repeated Tasks in Android

April 17, 2014

A somewhat common usecase for android applications is to have them launched when the phone is started, and execute some piece of code periodically.

Sounds straightforward, but there are some pitfalls, so here are a couple of steps to take in order to achieve that. Start with the trivial stuff:

In your manifest you need the following in order to be able to receive the boot event:

    android:name="android.permission.RECEIVE_BOOT_COMPLETED" />

Then, again in the manifest, you need two receivers:

<receiver android:name=".StartupLauncher">
    <action android:name="android.intent.action.BOOT_COMPLETED" />
    <action android:name="android.intent.action.QUICKBOOT_POWERON" />
    <category android:name="android.intent.category.DEFAULT" />
<receiver android:name=".Notifier">
    <action android:name="com.yourpackage.HOURLY_CHECK" />

What are all these? You will see what HOURLY_CHECK is in a minute. The entries in the .StartupLauncher I gathered from multiple StackOverflow answers, claiming to work on multiple devices. What you are normally required to consume is just BOOT_COMPLETED, but put the rest just in case. Note the enabled attribute of the receiver – they are normally not needed, but make sure the recieve is not disabled by the parent application. Honestly, I wouldn’t advise for putting useless stuff “just in case”, but given the quirks of android devices, I’d keep them.

Now implement the Service that will receive the BOOT_COMPLETED event:

public class StartupLauncher extends BroadcastReceiver {
  public void onReceive(final Context ctx, Intent intent) {
    AlarmManager alarmManager = (AlarmManager) ctx.getApplicationContext().getSystemService(Context.ALARM_SERVICE);
    Intent intent = new Intent("com.yourpackage.HOURLY_CHECK");
    PendingIntent notificationIntent = PendingIntent.getBroadcast(ctx.getApplicationContext(), 1, intent, 0);
    alarmManager.setRepeating(AlarmManager.RTC_WAKEUP, 0, TimeUnit.MILLISECONDS.convert(60, TimeUnit.MINUTES), notificationIntent);

Why not do it with a ScheduledExecutorService? Because once you schedule a Runnable, your BroadcastReceiver dies, and the executor dies with it, so the runnable is never invoked.

Now you have a scheduled Alarm, where you perform your actual logic:

public class Notifier extends BroadcastReceiver {
  public void onReceive(Context ctx, Intent intent) {
    // ...

You can of course have a single BroadcastReceiver and distinguish based on the intent, but I think that’s cleaner.

Overall, it’s a process that may be tricky – as it usually happens with Android, unfortunately.


Common Misconceptions About Java

April 3, 2014

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.

  1. 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.
  2. 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., 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 like AbstractCommonAsyncFacadeFactoryManagerImpl. But that has nothing to do with Java. It can be argued that sometimes these long names make sense, it can also be argued that they are as complex because the underlying abstraction is unnecessarily complicated, but either way, it is a design decision taken per-library, and nothing that the language or the SDK impose per-se. It is common to see overengineered stuff, but Java in no way pushes you in that direction – stuff can be done in a simple way with any language. You can certainly have AbstractCommonAsyncFacadeFactoryManagerImpl in Ruby, just there wasn’t a stupid architect that thought it’s a good idea and who uses Ruby. If “big, serious, heavy” companies were using Ruby, I bet we’d see the same.
  3. Enterprise Java frameworks are bloatware – that was certainly true back in 2002 when EJB 2 was in use (or “has been”, I’m too young to remember). And there are still some overengineered and bloated application servers that you don’t really need. The fact that people are using them is their own problem. You can have a perfectly nice, readable, easy to configure and deploy web application with a framework like Spring, Guice or even CDI; with a web framework like Spring-MVC, Play, Wicket, and even the latest JSF. Or even without any framework, if you feel like you don’t want to reuse the evolved-through-real-world-use frameworks. You can have an application using a message queue, a NoSQL and a SQL database, Amazon S3 file storage, and whatnot, without any accidental complexity. It’s true that people still like to overeingineer stuff, and add a couple of layers where they are not needed, but the fact that frameworks give you this ability doesn’t mean they make you do it. For example, here’s an application that crawls government documents, indexes them, and provides a UI for searching and subscribing. Sounds sort-of simple, and it is. It is written in Scala (in a very java way), but uses only java frameworks – spring, spring-mvc, lucene, jackson, guava. I guess you can start maintaining pretty fast, because it is straightforward.
  4. You can’t prototype quickly with Java – this is sort-of related to the previous point – it is assumed that working with Java is slow, and that’s why if you are a startup, or a weekend/hackathon project, you should use Ruby (with Rails), Python, Node JS or anything else that allows you to quickly prototype, to save & refresh, to painlessly iterate. Well, that is simply not true, and I don’t know even where it comes from. Maybe from the fact that big companies with heavy processes use Java, and so making a java app is taking more time. And Save-and-Refresh might look daunting to a beginner, but anyone who has programmed in Java (for the web) for a while, has to know a way to automate that (otherwise he’s a n00b, right?). I’ve summarized the possible approaches, and all of them are mostly OK. Another example here (which may be used as an example for the above point as well) – I made did this project for verifying secure password storage of websites within a weekend + 1 day to fix stuff in the evening. Including the security research. Spring-MVC, JSP templates, MongoDB. Again – quick and easy.
  5. You can do nothing in Java without an IDE – of course you can – you can use notepad++, vim, emacs. You will just lack refactoring, compile-on-save, call hierarchies. It would be just like programming in PHP or Python or javascript. The IDE vs Editor debate is a long one, but you can use Java without an IDE. It just doesn’t make sense to do so, because you get so much more from the IDE than from a text editor + command line tools.

You may argue that I’m able to write nice and simple java applications quickly because I have a lot of experience, I know precisely which tools to use (and which not) and that I’m of some rare breed of developers with common sense. And while I’ll be flattered by that, I am no different than the good Ruby developer or the Python guru you may be. It’s just that java is too widespread to have only good developers and tools.

if so many people were using other language, then probably the same amount of crappy code would’ve been generated. (And PHP is already way ahead even with less usage).

I’m the last person not to laugh on jokes about Java, and it certainly isn’t the silver bullet language, but I’d be happier if people had less misconceptions either because of anecdotal evidence, or due to previous bad experience a-la “I hate Java since my previous company where the project was very bloated”. Not only because I don’t like people being biased, but because you may start your next project with a language that will not work, just because you’ve heard “Java is bad”.


Fixing The Android Camera API

March 28, 2014

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:

  1. 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.
  2. 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 Camera class and put it in a CameraActions class. Together with other methods that are only valid after preview is started (I don’t know which ones exactly they are – it is not clear from the current API). How do we obtain the CameraActions instance? It is returned by startPreview(..)
  3. So far we’ve made the main use-case straightforward and less error-prone by enforcing the right set of steps. But the takePicture(..) method still feels odd. You can supply nulls to all parameters, but somehow there are two overloaded methods. Arguably, passing null is fine, but there are other options. One is to introduce a PictureCallback interface that has all the four methods that can be invoked, and provide a blank implementation of all of them in a BasePictureCallback class. That, however, might not be applicable in this case, because it makes a difference if you pass null vs callback that does nothing (at least on my phone, if I pass a shutter callback, the shutter sound is played, and if I pass null, it is not). So, let’s introduce the Callbacks which is a builder-like class to contain all callbacks that you like.
  4. So far so good, but you need to restart preview after a picture is taken. And restarting it automatically may not be a good default. But in the situation we are in, you only have CameraActions and calling startPreview(..) now requires a surface to be passed. Should we introduce a restartPreview() method? No. We can make our interface methods return boolean and if the developer wants to restart preview, they should just return true. That would be fine, if there weren’t 4 different callbacks, and calculating the outcome based on all 4 is tricky. That’s why a sensible option is to add a restartPreview property to the Callbacks class, and restart only after the last callback is invoked and only if the property is set to true.
  5. The main process is improved now, but there are other things to improve. For example, there’s an asymmetry between the methods for opening and closing the camera. “open” and “release”. It should be either “open” and “close” or “acquire” and “release”. I prefer to have a .close(), and then (if you can use Java 7), make use of the AutoClosable interface, and therefore the try-with-resource construct.
  6. When you call getParameters() you can a copy of the parameters. That’s ok, but then you should set them back, and that’s counter-intuitive at first. Providing a simple camera.setParameter(..) method would be easier to work with, but the Parameters class has a lot of methods, so it’s not an option to bring them to the Camera class. We can make parameters mutable? (That isn’t implemented yet)
  7. One of the reasons the API is so cumbersome to use is the error reporting. You almost exclusively get “Came.takePicture failed”, regardless of the reason. With the above steps we eliminated the need of exceptions in some cases, but it would still be good to get better reports on the exact reason.
  8. We need to make the Camera mock-friendly (currently it isn’t). So EasyCamera is an interface, which you can easily mock. CameraActions is a simple mockable class as well.

My EasyCamera project is only an initial version now and hasn’t been used in production code, but I’d like to get feedback on whether it’s better than the original and how to get it improved. At some point it can wrap other cumbersome Camera functionality, like getting front and back camera, etc.

Broken APIs are the reason for hundreds of wasted hours, money and neurons. That’s why, when you design an API, you need some very specific skills and need to ask yourself many questions. Josh Bloch’s talk on API design is very relevant and I recommend it. I actually violated one of his advice – “if in doubt, leave it out” – you have access to the whole Camera in your CameraActions, and that might allow you to do things that don’t work. However, I am not fully aware of all features of the Camera, that’s why I didn’t want to limit users and make them invent clumsy workarounds.

When I started this post, I didn’t plan to actually write EasyCamera. But it turned out to take 2 hours, so I did it. And I would suggest that developers, whenever confronted with a bad API, do the above exercise – think of how they would’ve written it. Then it may turn out to be a lot less effort to actually fix it or wrap it, than continue using it as it is.


The Optional Type API

March 18, 2014

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, there are a lot of different ways to use a class and none of them is better than the rest. For me, the particularly bad decision in this case is making Option (implicitly) convertible to Iterable. For the non-scala developers, let’s assume it is an Iterable. But it can have only one or zero elements. So, in order to implement our default and most common use-case we have the following options:

  • Use imperative style if (option.nonEmpty) {option.get.doSomething()}
  • Use .foreachoption.foreach(v => v.doSomething)
  • Use a foreach loop (different from above): for (value <- option) {value.doSomething()}
  • Use a for comprehension (for...yield) (different from the two above)
  • Use pattern-matching - case Some and case None
  • Use map, fold, collect, etc - this takes the process one step further - not only you get the value, but apply some function to it

So, from the basic notion of an optional type, we have a class with dozens of methods. The conceptual weight of this API is huge. There is no obviously preferred way to handle the most common case, and in fact method preferred by many scala developers uses some form of foreach, which sounds a bit weird, when you know there is at most one value.

Now let's proceed with my 2nd place candidate - Java 8 Optional. You have only two ways to use it - the imperative check with an if-clause, and the ifPresent(function) method, where you supply a function that handles the code when there is a value. You also have a couple of overloaded methods to provide a default value (the 2nd use-case). What I don't like is the map, flatMap and filter methods there. They are useful, as the scala ones above, but they could be left out (and their usage handled separately, with almost no added verbosity), or they could be reduced to simply one function - map. It has a subtle difference with flatMap, and filtering a single element isn't the most useful thing out there, besides, you could do that with a map function.

I know that by now you are probably ready to ask (angrily) how you are going to write very concise code without the ability to fold, collect, flatMap, filter. Returning another optional type after performing an operation with the given optional type is a 3rd use-case, which is important for long methods. It is less common than the other two, so less attention should be paid to it. Ideally, one method is enough - all other sub-usacases can be handled in the map function itself.

So we get to the winner - guava Optional. It has only the imperative way of handling the first use-case (as it is developed for versions of Java that lack first-class functions). The 2nd and 3rd use-cases above have as few methods as possible (or and transform(..)). Leightweight API that can achieve pretty much the same things, in the same amount of code.

In fact, having a functional approach for the main use-case is not necessarily good - the point of having an Optional type is not to be able to work functionally with it - the point is to be made aware that the value might not be there. I'm not saying to get rid of it in scala and Java8, but then maybe .isPresent() and .get() could be reconsidered.

Bottom-line is - it is hard to design APIs. Even a simple thing as an optional type has a lot of aspects to consider in terms of primary and secondary usa-cases, and whether convenience methods are needed, or they add unnecessary complexity to the API and can instead be handled in a different (not necessarily more verbose) way.

And finally - use optional types when you can possibly return null - NPEs are easy to debug and fix, but are easy to miss and may happen at the wrong moment.


IDE vs. Editor

March 7, 2014

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 application. Novice developers may commit absolute build paths, the IDE might have a very cool support for a framework, but lack one very important parameter that appeared in the latest version, so that you have to make a workaround. The IDE may make it too easy to generate tons boilerplate code, that will later be hard to support. Minor, even subliminal pitfalls maybe, but still – an editor isn’t leaking anything because it doesn’t have anything to leak.

But let’s elaborate a bit more on customizability. The cool text editors allow you to write simple scripts that plug into the editor and thus let you improve your experience. And that’s important. I didn’t realize it until I had to switch to IDEA and there ALT+arrows didn’t jump through camel humps, but only through whitespaces. And hovering on a class didn’t show its package. Very minor things that it turns out are important for me. Luckily, IDEA had these things configurable, but it might not have had them. If you want to write a plugin, you may need to know OSGi, SWT, a complex plugin API and whatnot. It’s an overkill to write a plugin for such small things.

So a very important thing I would like to see from IDEs – they should be more easily customizable. Simply dropping a file (in any jvm language, for example) should have the ability to alter the behaviour. At your own risk, of course, and soon you may spend hours debugging which two files are in conflict and are blocking your IDE, but that should be available.

Remember the example where you add a shell-script that runs selenium tests. It poses a question that spans a lot of these editor customizations – should they really be part of the editor? Don’t they belong to the build tool instead? Many of them indeed belong to the build tool. Pre/post-processors, code-generation, one-command deployment, performing release, running functional tests, etc. I would say that these belong to the build tool, because a CI server must be able to do them as well, and it’s headless.

And apart from the “plugins” you would add to the editor, that make writing code and navigating the project easier, all others will probably need to be shared with other team members. Having a separate repository? And tested on multiple versions? That might turn out to be a time-consuming task, while keeping them to yourself may lead to inconsistency across the team. And you would usually bring your entire text editor configuration with you on each project, but then the configurations of other members may conflict with yours. I cannot give a concrete example, because I’ve never heavily customized a text editor, but the general feeling is that you should not make something too custom for yourself, and for your personal process, unless you are working on your own. A good argument here is that you will be able to switch the language you use without having to lose the productivity tricks. And that’s a fair point, given the lack of interoperability of IDEs. But most sensible IDEs do allow you to reach a certain, significant level of productivity, and maybe the rest 20% are not worth it.

Regardless of whether you agree with the statements in the above paragraph or not, if IDEs provide the “plugs” for quick and easy customization, I don’t think there will be any remotely compelling reason for using a text editor, apart from “I’m too used to that”. Any IDE by definition has more features than a text editor, but it lacks the flexibility/customizability. If that issue is fixed in a reasonable and reusable way, it will no longer be a tradeoff to use an IDE even for a dynamic language. Open-source IDEs, of course.


Verifying Secure Password Storage Externally

February 25, 2014

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 (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 the site and explains the user why this is important. It’s not much, I know, but it has the tiny chance of raising awareness of the issue, and that’s important.

The only algorithms that are recognized as secure are Bcrypt, PBKDF2 and Scrypt. SHA-512 isn’t. No simple hashing function is. Encryption is not allowed (because it is reversible, and if the attacker gets ahold of your key, all the passwords are revealed).

The solution is not bullet-proof – someone might expose a dummy Bcrypt endpoint, while still using plain-text passwords, but as noted in the docs – why would you not use functionality that you’ve already implemented for the sake of being “compliant”? In general, I think the effort on the side of developers, in order to expose the endpoint, is minimal.

The project is on GitHub. It’s written in Java, with Spring MVC. MongoDB is used as a database. It is currently deployed on OpenShift (RedHat’s PaaS) mainly because it’s easy to setup and is free. (Note: I obviously need a better designer to at least fix the badge and make the site less ugly, even though Bootstrap minimizes the change for a developer like me to make a really ugly thing). Authentication on is done only via Mozilla Persona – 3rd party authentication which doesn’t require storing passwords on my end (something I’d actually recommend to all websites).

I’m trying to address a small, but important problem. I hope I’m helping improve the situation at least a little.


Coping with Methods with Many Parameters

February 21, 2014

I will put my captain Obvious cape now and write in short how to get rid of methods with many parameters, especially if some of the parameters are optional, or depend on each other somehow (e.g. go in pairs, one excludes another, etc.).

Let’s take a simple RestClient class. You need to be able to pass the target resource, optional HTTP headers, HTTP method, request body, timeouts, etc. All of these, except the URL, are optional. How do you write this class?

The first thing that comes to mind is overloading:

public <T> T request(String url);
public <T> T request(String url, HttpMethod method, Object body);
public <T> T request(String url, HttpMethod method, Object body, Map<String, String> headers);
public <T> T request(String url, HttpMethod method, Object body, Map<String, String> headers, long timeout);

Good? No. Because you may want to call a URL with GET, specifying a timeout, but not specifying body or headers. And whenever a new parameter is to be added (e.g. for authentication), then you should copy all the methods and append the parameter. To put it simply: you cannot and should not have an overloaded method for each possible combination of the parameters.

How should we approach the problem? There are several ways, and the one I prefer is using something like the Builder pattern. The Builder pattern is supposed to be used for constructing objects and to replace constructors taking multiple arguments. But its philosophy can be transferred to the above problem. For example:

public <T> T request(RestCall call);

What is RestCall? It’s a mutable object that you configure, preferably with a fluent interface, in order to make your rest call. All fields have getters so that the RestClient can obtain all the fields in needs. A usage might look like this:


It reads like prose, it lets you have only one (or very few) methods, rather than overload for each possible combination, and at the same time allows you to have each possible combination of parameters. The “to(..)” method is a simple factory-method. An example implementation of a withX method looks like this:

public RestCall withBody(Object body) {
    this.body = body; //assign a private field
    return this;

You can also have reasonable defaults for each field. In this case, a GET method, a predefined default timeout.

This approach also gives you the option to specify constraints. For example, you shouldn’t allow setting a body for GET requests. So:

public RestCall withBody(Object body) {
    if (method == HttpMethod.GET) {
              new IllegalStateException("Body not supported for GET");
    this.body = body; //assign a private field
    return this;

And if two parameters go together, for example you want to add headers one by one, then you can have an addHeader(String, String) method.

Generally, the approach is more readable and is easier to extend and maintain.


Ideas Aren’t Worthless

February 18, 2014

It’s common knowledge that “ideas are worthless”. An idea will bring you nowhere – you need implementation, focus, a good team, the right environment, luck, etc. And I won’t argue with that – obviously, an idea doesn’t bring you anywhere by itself. Just google for “ideas are worthless” and you can find dozens of convincing articles. Ideas change, ideas evolve, initial idea doesn’t matter.

But that’s the perspective of the businessman. A person whose interest is to make profit (nothing wrong with that, of course). Emphasizing the worthlessness of ideas brings a whole slew of startups that are there for the sake of being a startup. We’ll build something. We’ll figure it out along the way. Then they master the skills of fundraising, they focus on Lean, MVP, time-to-market, exit strategies, etc. etc. And that’s all great. Except that it’s not technology.

The perspective of a “hacker” is different. A hacker is thrilled by technology, he wants to be challenged. The ultimate point is not to have a startup, to get acquired, to make money. The ultimate point is to make something cool, something different, something technologically innovative.

I can have a dozen ideas per day. Things that may actually be turned into a startup. I know all of the above buzzwords, like Lean and MVP, so probably I can turn them into some sort of company. Do I do that? No. And not because I’m afraid not to have a stable income or wasting a couple thousand bucks. I don’t do that just because I’m not convinced they are cool, technological and challenging enough.

Probably, that’s the difference between great startups and mediocre ones. Not between successful and failed, because even mediocre ones can be “successful”, in terms of some revenue, some investment, being acquired. But between game-changers and the rest.

Yes, your ideas may be worthless, if they are worthless to you. If your idea is motivating you by itself, rather than by making you envision the success of the future company (i.e. “fall in love with the process, not with the end result”), then it’s the most important thing. Not for “success”, but for your experience.

So I’d choose carefully how to invest my time. I may be more valuable to the world and to myself by doing my job for an existing company, than by starting a new company for the sake of starting a company. Ideas are what’s important for us.


Digital Signatures With Javascript

February 2, 2014

Several years ago I used to work on a project that required the use of smart cards and digital signatures. I’ve already shared my experience with signing with javascript and then verifying the signature on the server side (with Java).

What I did today is to simply get the javascript, tidy it up and put it on GitHub (js-signer), so that people don’t need to copy-paste from a blogpost, and also to be able to update the project whenever there are new developments (for example Chrome and Safari implement DOMCrypt)

What are the use-cases of that? Electronic identification most often makes use of smart cards. And so software that requires to identify a citizen securely (most often banking or government software) and let him perform some actions online, needs to read the smartcards certificate details and to digitally sign content – e.g. you digitally sign your bank transfer, or you sign your request for a government service.

There are several ways to do that – e.g. Java Applet (like this one) or a custom-made ActiveX control. And while the applet and ActiveX is fine for internal use in organizations, where you can be sure that there’s Java installed or that everyone is using IE, these solutions are not so great for the mass public, because making the user install something is a bad user experience, and luckily not everyone is using IE. So a javascript solution must exist. Of course, the preconditions are, that the user has a digital signature, issued by a CA, and has followed the CA’s manual for installing the certificate in a browser. If these steps are not completed successfully, js-signer wouldn’t work.

Unfortunately, there’s no unified javascript solution. IE comes with CAPICOM, and Firefox has window.crypto. Safari and Chrome are waiting for a standard from W3C (DOMCrypt) before they implement window.crypto. That’s why js-signer currently supports only IE and FF, and the UX is a bit different with them.

I hope that more governments will go for electronic governance and use digital IDs (note: with the so called “anonymous credentials”, in order to ensure the privacy of citizens), and that browsers will follow and make it possible to handle smartcards without any hassle and without the need for 3rd party software.


I Don’t Like Scala

January 13, 2014

Yes, it is my opinion, and yes, it might seem like a hate-post. But I’ll try to address the issues I have with Scala and its surroundings. I have used Scala in a single, relatively small project (currently working in production), so I guess I’m somewhere between “n00b” and “intermediate”.

  • there are multiple right ways to do the same thing – there are a lot of tasks that you can achieve with one or two lines in Scala. But often there is more than one way to do it, and there’s no obvious winner. The options vary on the brevity-readability scale, on the functional-imperative scale, and in many other ways. I know what currying, partial functions, partially applied functions, folding, collect, map, apply, etc. do, but given a simple task I can use all of them I don’t know which one. Probably because I’m a beginner – true, and over time I guess I’ll build a preferred set of approaches. Which will likely differ from those of any other co-worker, and the projects will me “messy”. It would be something like having half the project with curly brackets on same line, and the other half – on the next line.
  • it’s cryptic – you can probably be ok with all the symbols flying around after some coding, but I find it plain ugly. It is a high-level language and the use of so many symbols is troublesome. Take a look at this stackoverflow question to see what I mean.
  • binary incompatibilities – I have an error that in a Scala 2.10 project I can’t use a library compiled with Scala 2.9. There are reasons for that, and it will probably be improved or completely fixed in the future, but for now it’s making life harder.
  • not smoothly integrating with existing java frameworks and tools – this is partly due to the different mode of thinking (e.g. you may not need a DI framework in Scala), and there are already a couple of viable Scala alternatives (e.g. ORMs), but sometimes you would prefer to use proven technologies that you are familiar with. And it’s not only frameworks, but tools as well – I found it a nightmare to serialize JSON 6 months ago. All options had at least one thing that isn’t working as I need it, or lack a feature I need (both the java ones, the Java-Scala bridges, and the native Scala ones). I ended up using an abandoned project (jerkson). Luckily, the jackson support is now fixed (at least for my use-cases) and I switched to it. The same probably goes for other libraries as well.
  • random failures – the time I’ve wasted in random things that break during compilation is significant. I only remember the last example, where I extended some Java class and I got an “AssertionError”, with some extra information that I don’t think makes sense to anyone, other than the author of the compiler. This particular example is related to the previous point (as I extended a Java class), but there are some more that I don’t remember, because they were random.
  • irrelevant compiler errors – this isn’t universal, but sometimes you get a compiler errors that are not at all related to the actual problem.
  • slow compilation – I haven’t really experienced that to a significant extent, since the project was small, but worth mentioning – see here
  • IDEs used to be terrible. The scala-ide I’m using is from 6 months ago, and it is practically unusable – refactoring doesn’t work, inspection in debugging doesn’t work, sometimes compilation doesn’t work (while at the same time the maven build runs fine and classes are compiled). I tried IntelliJ back then, and it was slightly better, but I somehow didn’t always compile on save. Now the newest IntelliJ plugin works way better, and I’d say is actually usable. Probably the same goes for the eclipse-based scala-ide. So things are improving indeed, but used to be horrible at a time where you’d expect a technology to be more mature. And no, I don’t want to use vim/emacs/jedit/whatever for a statically-typed language that allows for refactoring, call hierarchies, etc.
  • annotations, enums, reflection – coming from Java, I “cherish” these things. And while if you are in a pure Scala thinking, you may not need runtime retention of annotations, I still haven’t reached that Nirvana, and I also need to use it in conjunction with Java libraries. The workaround is to define java annotations in your project, alongside the Scala classes. Enums – I just don’t like the way they are defined, it’s unnecessarily verbose. And reflection is coming to Scala, but things like @ScalaSignature(bytes) scare me a bit.
  • steep learning curve – even if you are familiar with functional programming, scala introduces a lot of stuff, including the “cryptic” symbols mentioned above. Not only that, but in order to get a full-featured scala project, you may need to learn a myriad or new frameworks and tools, like scalate, scalatest, Squeryl, etc. Partly because the Java-alternatives don’t work well with Scala, partly because the Scala alternatives are taking advantage of Scala features.

I’m not saying you shouldn’t use Scala. And obviously I haven’t listed all the good things about it. But for now I don’t like working with it – I am less productive due to the above problems that I would be in Java, and for me that trumps the productivity benefits that come from the cool language features. Things are obviously improving (both IDEs, the language, the runtime and the libraries), and I certainly don’t regret doing the project in Scala, as this is invaluable knowledge that I’ll possibly use later on.