Fork me on GitHub

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!

What is the most important thing you need to be doing when bootstrapping a project

I’ve worked in distributed teams for most of my professional career. For the last 6 years I was in a position to cooperate with people living up side down - there’s from 8 to 10 hours of difference between us (depending on DST).

The communication window is so narrow it’s impossible to keep up face to face. To ease our life we had to communicate asynchronously for the most of the time and the most important thing I learned to do to succeed is to over-communicate.

I think it’s the single thing that influences whether you are successful or a failure in a relationship like that.

Master your writing, master your thinking, be precise, be easy to understand and leave out ambiguity, state your intentions, expectations, write down your assumptions. It’s like trying to document your thinking process. Try to predict follow up questions and answer them before they are asked.

I know it’s a lot of work but think how much time you will lose if you have to wait for an answer at least 10 hours and then you get an answer to the wrong question :-)

Then spending an hour or two writing a letter is nothing, you really safe your time!

Photo Macostones Megaphone by Katie Lips on Flickr.