Fork me on GitHub

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, 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…

Why freemium might not be good for your business

Why freemium might not be good for your business?

In short because if you start a business the one of the most important things you need to do is to validate the idea.

Why spend time building something that actually no one values?

And what’s the best way to see if people value the service?

Of course it is to ask them to give you the money.

It’s not only about that - I’ve recently were talking with one of the friends using TeamStatus. We were talking about pricing too and he gave a number which he could pay for the service.

So I asked him to actually gave me the money and then we both realized some other constraints involved. Like he’s a contractor and it was hard for him to ask for the money the company he was doing the work for.

So I know not to focus on contractors, at least now ;-)

The other thing is that if you want to have a bootstrapped company you need to have some cash flow ASAP.

That’s why we’re not going to currently introduce any free plans for TeamStatus but we will offer a free trial period because we want to make sure we do bring value to the team.

If we are not we don’t want your money! 

It's time to grow the team (for TeamStatus)

Want to participate in a cool bootstrapped startup that helping teams visualize their progress?

We’re building a tool that lets teams see their progress, key metrics, and whatever else they need.

Currently looking for a new team member that would help us develop the product as there’s so much work to do (smile)

You’ll be a perfect fit if you’re interested in full stack development, we use tools like jQuery, AngularJS, Bootstrap, Ruby on Rails, NodeJS, Heroku.

As we are working remotely you need to be self-driven, organized and communicative. Have at least 15 hours per week solely for this project.

We’re looking for an enthusiast that would be a part of the founding team, we offer no salary, you’ll get equity if we succeed.

Please contact Janek for more details!