Fork me on GitHub

Zen - the stupidest idea ever

I decided to built new JIRA from scratch. What a stupid idea.

I've been using JIRA for years. I even worked as a developer and team leader on JIRA team for years. I quit some time ago.

I was building different projects in my spare time. Usually my focus was on building something for others and making this my main income source. I wanted to be an entrepreneur. Guess what - I'm bad at it. I never succeeded. I lack the major part - interest in discovering user pains. I usually were creating something out of my need. And seems I have pecurial needs ;-)

Recently I decided to build something just for fun. I wanted to learn React so there's no better way.

I have an ambitious goal of making JIRA MVP but better than JIRA. I know there's plenty of different project management tools but they are lacking. JIRA is a customization beast.

I named it Zen as I registered this domain for some other purpose some time ago. But it actually matches what I want to achieve - mindless and easy project management which is powerful at the same time.

The current stack is React+Redux+Redux router+ECMAScript 6. Backend based on PostgREST.

Ansible vs Chef knife solo

I've been struggling with Ansible for some time. When I first got into building servers, provisioning, etc. I used chef knife solo. I enjoyed its modularization and plethora of modules available online.

I made couple of servers using it. But once I wanted more advanced features like encrypted vaults it kicked. I had to setup certificates (which I never did) and things got harder.

At the same time I played with Ansible which was new kid on the block. It had rough edges. I didn't like its approach - there wasn't any modules, you had to do anything by your own. I was duplicating stuff found on line.

But as the project move forward I now enjoy using it. Now you can also write your own modules. Also the core got more features so you can get a lot out of it.

If you didn't have a chance I think it's worth trying out. I think it's the one that will stick as it has a nice learning curve. You can start in minutes and then progress to more advanced topics.

Also with Ansible Tower (which I don't use) you should be able to scale to enterprise level.

How too much modularization can lead to poor performance

I've been leading a team working on improving JIRA's performance for large customers for a few months. I think it's time to share some observations about the changes we did and the overall way to make applications fast. This will be the first post in the series in which I'm going to describe the landscape.

JIRA has more than 12 years so you can imagine many different patterns in the code, it is like geological eras laying one on top of the other. You can see all those different ways of crafting the code that were once popular. So you have simple POJOs, Smart Objects, Managers, Services, Web Actions, different templating systems (like Soy, Velocity and Webwork JSPs), you have two way to handle dependency injection PICO for internals and Spring for external plugins.

Now when I mention plugins you need to understand JIRA is a product with multiple extension points, you can do a lof of things with plugins, actually half of the product is built as plugins for it - so you understand how powerful the plugin system is.

There's a huge number of different APIs you can use to write a plugin. Because JIRA is so popular and so many customers built their own plugins there had to be an API for everything ;-)

And this is the first problem, that I'm going to discuss.

You see generic APIs lead to generic performance. Modularization and de-coupling is great. But imagine an action that uses multiple components to do its job, each of them queries the database, and say they are actually getting objects that are tight closely (for example all backed by tables that are sharing foreign keys).

Now the code is nice and simple to follow, but the performance is not - each of those separate components queries could be potentially replaced with one single JOIN. But that would be totally against this modularization, also this would probably be a specialized method that the plugin needs, so it should not land in the official API.

To make things worse because those APIs can be used by plugins and those plugins also do complex stuff there needs to be a lot of caching done because otherwise performance would be tragic.

So you see what I'm getting at - at some point modularization can be really expensive in terms of overall performance.

That's why I like the idea Ruby on Rails uses that encourages writing real queries against the database and discurages you from creating any managers/services. You see in Java you usually write a service that runs validation, inserting and updating, then you have some stupid POJOs that are written/read from the db. You need to have this mid layer.

In Rails contrary the idea is that the object that gets stored in the database handles all the validation, publishes events which can be consumed by other parts and so on, that gives you a way to escape away from this middle layer, so you can write queries whenever you like, real SQL (ok, not real, but via nice abstraction model).

I believe this approach scales better, now we'll have to figure our how to combine it with the existing code and persistence framework.

But in case you're starting from scratch you can try using ActiveJDBC or ActiveJPA which offer the same model for Java!

Why longstanding Open Source projects might not be so secure as thought


Many of you probably already heard about Heardbleed bug in OpenSSL that made all SSL useless for like two years and which was until recently discovered.

Basically because of the bug you were not only able to actually steal the private key (so having this key you can decode any communication between the client and the server that was done in the past two years) but also to steal other stuff residing in the memory of the whole server (passwords or any other secrets).

What’s more interesting is that an attack would not be detectable at all. No traces, no signs. The dream come true for anyone wanting to get you.

It was all caused by a tiny bug in OpenSSL library which is the most popular security related library used on Linux, *BSD and Mac.

It leads to couple of interesting observations - first I think it was the biggest trojan horse ever. You would never expect your “security” library to be actually malicious :-)

Being an open source with a long history OpenSSL was widely adopted as a security foundation in many operating systems - Linux, BSD flavors and even Mac. So by breaking it you actually broke all of them. That’s huge!

Only Microsoft and Mac (partially for apps that don’t use OpenSSL) were not compromised because they have their own implementation of SSL library.

Thinking about recent NSA scandal it makes me think - who was involved and whether this issue was “random” or “engineered”?

It also makes me wonder if you are running an open source project (especially so widely spread) you need to be aware that you might be under an attack.

Someone may want to put a bad code into your app.

Scalaconf 2014 retrospective, or why I no longer like Scala




This Saturday I attended ScalarConf first (and free) Scala conference organized in Poland. I was going there as a Scala enthusiast just to leave it with an impression that we should stop using Scala :-)

Our team’s history with Scala started like a year ago when we started using it mostly for tests in one of the plugins. We are forced to use Java 1.6 but we can use Scala, so it was obvious choice. Scala’s less verbose syntax is what we were after.

We enjoyed using it that way so we decided to try it on a bigger scale and wrote a whole JIRA plugin in it (not the first one in JIRA, but first done by us).

We also enjoyed it, but we started to notice sharp edges. Especially when browsing and reading code from an older plugin that uses Scala - there were some parts really hard to understand (but we ignored this bad sign back there).

We wrote the plugin using Scala with no additions like Scalaz, etc. We tried to keep the code clean. Although we did introduce a bunch of implicits (there’s a lot of places when we map values from one type to another and they were handy for that).

So we happily signed up for ScalaConf thinking it would be a great learning experience and it was. We learned not to use Scala ;-)

There are couple of issues that struck us.

Like the code presented as “readable” or “cool” was actually not. There was a great example of a code validating a form written in Scala, then refactored in Scalaz, and once again for the third time refactored a bit.

Version 1 was ugly, version 2 was uglier, version 3 was a mess.

Scalaz looks like a maintenance nightmare. I would not want to read code written using it. Never.

Another great example was about creating domain specific language in Scala on an example of Spray.io, it was ok at first glimpse, but why was there a strange operator combining those GET/POST rules together? Because we can ;-)

Compare it to the great Sinatra or Ruby On Rails DSL and you see that once again Scala folks made it wrong :-/

There was also a great presentation about good and bad sides of Scala with awesome list of resources at the end. Here are couple of them. Watch them if you’re thinking whether or not to use Scala.

They persuaded me not to pursue Scala further (and I was not the only one leaving with this impression). Referring to the video above - if people creating the language say how bad it is it’s a sign that the whole product is mismanaged and you should avoid it.

Look the code should be simple and understandable. The more complex it gets the harder it is to maintain it and we all maintain code - ever got a bug report from someone or CI?

Scala (meaning everything it offers) is a great way to boost your ego proving how clever you are using all those funky abstracts. But I don’t give a shit - I want to see a readable code.

Haven’t we learned from PERL? Well, maybe it’s a history for some but I still remember reading PERL code and it was shit. I don’t want to go back there.

So, I’ll pass.

I don’t think any software company that cares about long term future should actually invest their time in Scala. I believe there are better alternatives that make code actually look decent and terse.

Because if you’re going to introduce Scala no one’s stopping “clever folks” doing crazy shit in it.

We’re going probably to investigate a few alternatives in the future (like Kotlin), also in some time we’ll be allowed to upgrade our product to modern Java 8 and maybe this will be good enough?

But for sure I’m not longer going to advocate for Scala…