meanderingjourney

When I wrote about my Planning poker app for the first time, I had invested 3.5 hours into the app itself plus some more time into rescuing its version history. Things have been moving forward since then. More precisely, they've been moving in several different directions - sometimes all at once - for about 16 more coding hours.

What bothered me about the first "finished" version were slight glitches in the layout. Some gaps between cards were one pixel wider than the rest and it was just wrong. The wrongness was exacerbated by the fact that the cards were being carefully laid out by a script upon page load (I had to use absolute positioning due to the particular transition effect I had come up with).

I decided to fix both problems by letting CSS do its thing and using an overlaid extra card for the transition (yeah, I called it "joker"). It simplified the code and removed the layout irregularities. It also introduced aliasing artifacts. In other words, edges of cards were getting blurred at certain viewport sizes. The new transition mechanic also didn't work flawlessly - it glitched when you poked the app during the transition. I chalked it up as a failed experiment (the best kind!) and decided to be rigorous.

In the end, I have a responsive layout script that works with a size unit one might call VRSTAWPP (vmin reduced slightly to align with physical pixels). The entire layout takes up 100 VRSTAWPP on the shorter side of the display and however many are necessary on the longer side. As it's a reduced vmin, there may be extra pixels left. I distribute those as evenly and symmetrically as possible. The result is a joy to look at, provided you have a phone-vs.-eyes setup that lets you discern individual pixels. Otherwise you just won't care.

So what's next? Planning poker is now in that weird limbo between a project and a product. I'm happy with how it works but there are still bits that need polishing:

• the cards look like they were designed by a programmer
• there is no proper logo and no proper icon to show in an app store
• the app has no proper name to distinguish it from other Planning poker efforts
• only one deck of cards is supported
• there are other features I'd like to add (OK, those are "nice to haves")

As for cross-browser support, testing in Chrome has indicated that the web platform is as inconsistent as ever. There's a schism, for instance, when changing the transition CSS property on an element while it is transitioning: Chrome cancels the running transition immediately, Firefox lets it finish. The app is thus pretty much unusable in Chrome. I haven't done any testing in other browsers.

You can check out the current version of Planning poker at my modest projects page. The page features an install link as well; if clicked in a recent Firefox, it should store the entire app on your device for easy offline use. On Android and Debian it even gets nicely integrated into the appropriate menu.

I have yet to seriously try turning Planning poker into a faux-native Android app (for possible inclusion in the F-Droid market). I've played with mozilla-apk-cli but the resulting .apk weighs just 1.4 MB and I don't suppose it'd work on a device without Firefox installed.

I'm not really sure this is worth pursuing further but at least I could try publishing it into the Firefox Marketplace. As of now it only contains two other Planning poker apps, what a shame :-)

The story of IT is rapidly morphing into the story of IT security. One could describe it as a farce made up of many little tragedies. No people have been dying recently due to getting hacked (at least none that we the public know about) but the employees of Sony Entertainment or the many victims of ransomware could attest to the costs of an attack to its victim. The Snowden revelations, as well as several high-profile vulnerabilities and instances of blatant disregard for customer privacy by household names (Samsung? Lenovo?) have highlighted a curious trend: The more we rely on technology, the less trustworthy we find it.

What might look like a paradox is actually the result of a very simple dynamic. Rising IT usage means higher stakes: more attack opportunities and juicier targets. The software infrastructure is undergoing its first real stress test, yielding lots of interesting (if unsettling) data points. Testing is mostly done by people who have the most to gain from weaknesses: spies, criminals and hacktivists. It is still not clear how much there is to lose for the rest of the ecosystem, which is why its response has been somewhat lethargic so far.

The problem has complex economic and social facets. In particular, there are many instances of mis-aligned incentives: those with the means to prevent an attack don't bear the brunt of it when it comes. A coder who leaves a buffer overflow somewhere in Web-facing logic is not liable for the damage incurred by users once they get hacked. Or, from a completely different perspective, employees at signals intelligence agencies don't get fired when constitutional freedoms they are ostensibly protecting get eroded by their very actions. For yet another example, a skilled hacker faces a relatively low risk of being caught and punished.

Optimizing incentives has been the perpetual challenge of every society since the dawn of time, of course. It would be great if the problem could be solved technologically but it's becoming obvious the new tools are no different from those before: empowering attackers and defenders, thieves and detectives, opressors and the oppressed alike.

Having said that, the attacking side clearly has the upper hand at this point in the game, and not just due to its intrinsic asymmetric advantage. It is simply too easy to build systems without security considerations and too difficult to build with them. That is to say, even the industry's culture and tools work against the defenders.

It is, fortunately, within the remit of IT to make difficult tasks easier and expensive propositions cheaper. It should be possible to use IT to make robust IT more affordable. There are, in fact, many exciting developments in this area and I hope to write about some of them in more detail in the future. As for making the disregard of security more expensive, that's a completely different can of worms...

On February 21, the venerable Konzerthaus in Vienna welcomed a peculiar trio as part of its series "Jazz im Konzerthaus". The musicians call themselves Mare Nostrum, apparently due to the fact they all come from countries with substantial shorelines. The trio featured the God of Jazz Accordion himself, Richard Galliano, along with Sardinian trumpetist Paolo Fresu and Swedish pianist Jan Lundgren.

The gentlemen filled almost two hours with pleasing romantic tunes which nevertheless packed plenty of substance. The individual musicians' temperaments contrasted each other nicely, with Mr. Lundgren laying heartfelt backgrounds reminiscent of the likes of Debussy, Mr. Galliano embroidering melodic lines in his trademark style and Mr. Fresu contributing a more reserved, conservative jazz phraseology.

And yet, it was largely Galliano's show all night. He dominated the stage without imposing himself in the least, simply by virtue of his consummate musicianship. He is one of those improvisers who play as if they were talking, so natural and fluent is his melodic concept. Regardless of the tune, he always has interesting things to play and I don't think he's capable of producing a single boring note.

I wish I could say the same about Paolo Fresu but his playing somehow went right past me. Perhaps I simply wasn't attuned to his mood that night. I can definitely state, however, that at the start of the concert he wasn't attuned to his band-mates. His notes were distinctly sharp, so much so that I can't honestly believe it was intentional. He seemed to adjust his instrument after about four numbers which made him sound much better and rescued my overall impression of the concert.

In conclusion, I spent a most pleasant evening, as I usually do amid the Art-Deco splendor of the Konzerthaus. I wouldn't mind seeing Mare Nostrum again if they happen to stick together for some time. Come to think of it, I'd probably bet on Richard Galliano in any constellation at all. This one wasn't half bad.

The new team lead on my current project started using Planning poker for estimation. It turned out that all colleagues except me had installed a corresponding smartphone app in order to avoid mucking about with actual paper cards. The apps are exceedingly simple: all the cards are displayed on the screen, you tap one and it fills the entire screen, you tap it again to restore the initial view. Pretty graphics and fancy animated transitions are just about the only embellishments.

My Fairphone comes without Google Play and I usually fulfill my app needs through F-Droid, the app store dedicated to open source offerings. To my surprise, F-Droid offered no Planning poker app (granted, the store is rather small at about 1000 items). I decided to build my own, of course. Given my current interests, I chose to write it as a HTML5 page instead of a native Android job.

I was done in about 30 minutes and the result was perfectly adequate for the intended purpose. It was pretty spartan, though, so I spent about an hour tweaking the visuals and two more hours adding an animated transition effect. I did all the work in one file without any version control and by the end I wished I had kept track of the various stages. I hadn't done much work in HTML5 before and there was a lot of trial and error involved, especially concerning CSS (I have to thank the friendly spirits at Stackoverflow, MDN and W3C, of course, for speeding up the journey immensely).

And then I found out that I had, in fact, kept all the intermediate versions without even knowing about it! You see, I had set up a shortcut to the Poker page on my Android home screen to speed things up a bit. As it happens, each time I tapped the icon, Firefox opened the page in a new tab. By the time I noticed, I had 60 open tabs. It's a pretty annoying behavior, if you ask me, but in this case it provided a welcome benefit: all iterations of my creation were neatly laid out in chronological order. I only had to save them as separate files.

Yeah, I didn't think it would be simple, either. Firefox for Android offers just one "Save as" option: "Save as PDF" which wasn't much use to me as I was after the source code. The Firefox Add-ons page yielded an interesting extension called "View Source Code". I installed it pronto, only to find out that it displayed the source code of the latest version of the file, regardless of which tab I was looking at (all the tabs had the same URL and the extension obviously reloads the source in order to display it).

I tried another extension: "Save as TXT". This one saved only the text visible on the rendered page, of course, which wasn't that useful either. The extension looked rather simple, though, so I downloaded it and poked around in its source code to see if I could adapt it for my purposes. I had had some exposure to the XUL universe before so I wasn't completely confused but even so, the task was far from simple.

My biggest hurdle consisted of the fact that I had to iterate here as well but couldn't restart Firefox in between (lest I lose all my precious tabs!). I found out that uninstalling an extension and installing a newer version of it leaves some hooks registered by the older version in place (something a restart would surely fix) so my changes weren't taking effect. I had to install each new version with a different extension ID, making the whole process pretty cumbersome.

In the end, I bludgeoned the extension into doing what I needed after 8 or 9 iterations. It took two and a half hours and the result was a primitive hack. Having to activate the extension 60x by hand afterwards wasn't much fun either. I did rescue the history of my Planning poker page, however, and that's all that matters.

I would like to welcome myself back to my little corner of the Web. Many reasons kept me away from these pages since October 2013 but a scarcity of topics was never among them. I did, in fact, write several drafts and short snippets I simply never saw as "done". Still, by now they're as finished as they'll ever be and there's no point nursing them further. Besides, new fascinating topics abound. One way or another, I hope to keep things decidedly more lively.

My three-month break from paid programming work was largely spent dealing with various Real Life issues. I did get to try a few things, however, mostly in September in preparation for various interviews. Here's an overview of those experiences for posterity:

• I started on my first Android app. I was surprised by how rich my own testing feedback was - it substantially changed the whole proposition I'd had in mind. Touch UIs really are a completely different ballgame. That's why I can't see myself developing with emulated devices. I don't worry too much about fragmentation, testing on one specimen of each feasible screen size (say 4.5", 7" and 10"). For a modest app that doesn't use any esoteric hardware features, it seems to be working out OK.

• I took a look at JSF 2, CDI and the rest of the JEE 5 stack (or at least the web profile). I was pleasantly surprised by how easy it was to deploy a toy application into the various containsers. I tried GlassFish, TomEE and JBoss. Especially the latter surprised me as a well-thought-out, approachable piece of software. I even ventured to create a FrankenContainer by mashing up JBoss Weld with Mojarra, Apache OpenEJB, Hibernate JPA etc. That didn't quite work but the few hours of debugging proved amusing.
  
  I also used the JEE web profile to implement a basic version of a web app idea I'd had for some time. I deployed to all three containers and there wasn't any issue. I do have to say, though, that I didn't find the experience all that enjoyable. The templating approach taken by JSF 2 is about equally powerful as other mature approaches yet it makes you suffer its baroque verbosity. This became even more apparent when I re-implemented the app in Python (using the Pylons framework and Mako templating) to keep my OpenBSD home server free of Java. The Python version is much more compact and has much easier URL manipulation. I suppose JEE comes into its own with really big projects.

• I was fortunate to play a little with Apache Wicket, as well. It feels incredibly fresh compared to JEE. I found the binding between the Java and HTML incarnations of a page to be slightly tighter than I'd expected (the component trees have to match pretty much exactly) and I missed an expression language a bit (not wanting to muck around with Velocity integration) but I found myself doing a lot of work very quickly and fluently. Unless the heavy sessions are a deal-breaker, I find Wicket a pretty obvious choice for writing web apps.
  
  Regarding Wicket, I was amused by how varied the Spring integration examples I found turned out to be. One had the standard Wicket servlet with a Spring context starting in the init method of the Application class. Another used a special Spring dispatcher servlet with the Application class as its init parameter. It goes to show that both technologies are well suited for working with other components (in case of Spring that's the whole point, of course). Having multiple ways of doing the same thing is a mixed blessing but what I saw was pretty easy to follow.

• I wrote a plug-in for the QStarDict desktop dictionary. QStarDict has a really nice Qt-based UI and perfect KDE integration but I found its German-Czech dataset quite useless. I did found a great German-English dataset that ships with another tool, though, so I taught QStarDict to parse it. This was my first "major" C++ undertaking since my high-scool project in 1995 so I spent some time scratching my head over things such as namespaces, references and nested template parameters. In the end it all worked out OK. I have to find the time to polish it a bit and talk to the QStarDict folks to see if it's interesting for them.
  
  Working with Qt was a pleasure as always, it all looked rather civilized despite the C++. It even made me feel a bit uneasy the way C++11 does. On the one hand, improved safety and readability are generally worthy goals. On the other, the language should signal its fundamentally unsafe nature. Hiding it too well gives a false sense of safety and it somehow feels hypocritical. I do suppose experienced C++ folks working on large projects simply appreciate all the help they can get.

• Finally, for the current project I needed to look into the Eclipse Rich Client Platform. It's not trivial and I'm sure I'll keep discovering new facets for a while. It's really nice to interact with the underlying UI libraries (SWT and JFace) simply due to their contrast vis-a-vis Swing. Exploring a different way of thinking is always useful as well as fascinating.
  
  While investigating Eclipse RCP I stumbled upon SWTBot, a functional testing tool for SWT applications. It's not perfect but it seems to be usable. It fits neatly into my toolbox alongside FEST and Selenium.

Now that I look at it, the summer wasn't completely wasted after all! I wish I could've delved into some of the topics a little deeper but so is life. I don't like how I've been neglecting the JavaScript/HTML/CSS universe. I hope I'll make good use of my commute time to fill this void.

So I've successfully landed a contract with a major IT services provider in Vienna. Given that my search was not nearly as thorough and deliberate as I'd hoped, I'm pretty happy with the outcome. The interview was smooth and the team seem to know what they're doing. Of course, the proof of the pudding is in the eating so we'll see how things go. I'm writing this on a commuter train, eager to start my first day.

30 June 2013 marked the conclusion of a successful co-operation between myself and an important client. My involvement in the project had lasted almost 6 years and I felt it was time to move on. Having handed over my responsibilities, I'm enjoying a three-month hiatus and plan to start another engagement in October.

What's on offer

As it says in the sidebar, I'm mostly a Java guy with 15 years of experience. The details are in my CV (doc or odt) but I don't think a CV can convey what really matters.

I believe I have good analytical and problem-solving skills. I appreciate the complexities of requirement gathering and the value of customer feedback. I always consider the usability impacts of my design decisions. I understand that IT is not a cure-all and that true solutions to many problems are actually non-technical.

I'm keenly aware of the social nature and the inherent uncertainties of software development. I crave good craftsmanship and wish there were more of it in our industry. I recognize the importance of great tools and take time to learn them properly. I'm always willing to reconsider my opinions but I'm also capable of defending them - always in a friendly and civil manner.

What I'm looking for

I hope to join a team of developers who care about the quality of their output. I like a developer culture with emphasis on knowledge sharing, learning and improvement. That implies open and constructive communication. Agile practices are a plus as long as they're implemented consequently.

I'd love to work on stuff that matters. I'm especially interested in renewable energy, smart grid and energy efficiency, but also medical software, education or any other world-changing area I haven't thought of. Having said that, any software is worth working on as long as it improves the lives of its users or their customers.

I'm largely geographically constrained to Europe (ideally somewhere around Vienna) but a really great offer might tempt me overseas. I'm keen to try teleworking - huge open-source projects come from dispersed teams so it's got to be feasible. Hybrid models are also an option (3 weeks at home, 1 week on-site etc.).

If you're interested

Do write me a quick note - coding 'at' journey 'dot' sk.