Year: 2012

Thank God Not Everything Is Software

On an average day I’d see a comics like this, smile and walk by.  But I am currently involved in a project that makes me feel stronger about it.

Consider, for example, a client request I got a couple of days ago:

We are using the database for this project, right?  We are using it for a reason – to store data.  If we store data, we should be able to retrieve data.  So I want a report that retrieves data.  I want a report with all data, all on a single page.  But it shouldn’t be too much or too complicated.

Funny?  Well, I laughed at first too.  But when I actually managed to build that report, I had a few things to think about.  And a few to reconsider.

Google : 60,000 dollars for a bug report

I’m a Google fan, there is no reason to hide it.  And this is one of the reasons.  They are setting a good example to follow.

Open sourcing company products changes the way code is written.  The moment programmers know someone else will be looking at their code, they start paying more attention as to what and how they write.  Paying money to outsiders for discovering bugs with company code is like the next level of Open Source Software.  Just open source gives the possibility to review.  Money provide a good incentive to.

TripAdviser can be confusing

I’ve heard plenty of good things about the TripAdvisor website.   I’ve never used it myself yet, but I know that a few people that I trust with reviews do.  Today, I was searching for information on a restaurant and Google suggested that I check out this TripAdvisor page.  Looks good, doesn’t it?  Here is a screenshot of it, just in case it will change in the future.

 

Reviews, ratings, and even photos – that is all very useful.  But I needed more.  Given that I had no idea where exactly the restaurant was, I thought the most helpful details would be the address or at least a phone number.  A link with “More restaurant details” only told me that I’d need a reservation.  But again, no information on how to actually make the reservation.

Without that basic info, the rest is pretty much useless.  Gladly, that’s not the only website on the Internet.  This one seems to have both the address and the phone number…

Cyprus photography by Brian JC Osbourne

I came across Brian JC Osbourne’s portfolio in one of the Cyprus-related Flickr groups.  There are only just a few pictures, and most of them have a simplistic, village even,  feel to them.  Yet, I did enjoy them quite a bit.  The choice of subjects and post-processing filters match the Cyprus atmosphere nicely.

GitHub compromise : lessons to learn

GitHub has been compromised.  That, by itself, is important enough – with millions of projects and developers using it.  But there is more to it.  Have a look at these links:

There is more coverage all over the web, but I’m sure you know how to find your way around.  Now, to the lessons that we can learn from what happened.

  1. “Don’t panic” in big friendly letters, courtesy of Hitchhiker’s Guide to the Galaxy.  It’s obvious something out of the ordinary happened in GitHub’s routine life.  While they regained the clarity of mind pretty fast, they were caught off-guard.  Don’t panic is the first rule of panic situations.
  2. Pay attention!  Given the size and active lives of both GitHub and Rails, it’s difficult to pay attention to every little detail.  But you should always weight the “large number of installations” or “large user base” considerations.  Even if there is an issue with a documented feature.  We’ve seen examples of this again and again – something that was a part of original functionality once in a while is turned into a malicious attack vector.  Your answer shouldn’t be the simple “check your code”.
  3. Stay transparent.  As you can see from a few comments in the above links, the actual compromise is not the biggest deal.  People in general and software developers in particular are very much used to security issues in every software.  It happens.  The bigger deal is, of course, how you handle that.  When you obviously have a problem, don’t try to hide it or misinform people who rely on you.  Say it loud and clear.  Or you will lose trust.
  4. Mind the stack.  Today’s computing world is rather complex.  Most projects rely on third-party libraries, tools, and solutions.  And that’s a good thing.  But when you do that, don’t treat the third-party item as a black box.  That is especially frequent in Open Source Software development.  It’s easy to trust something that is open.  It’s free, it’s open, it’s secure and reliable.  Not always the case.  And sometimes it is the case, but you need to read the documentation and think carefully.  As much as you are concerned about the security of your own code, there is no guarantee that the libraries, framework, or even the language compiler that you are using are secure.  Keep that in mind.

With all that, what’s my attitude to GitHub now?  It’s still the same.  I love the service and I trust the company.  Everybody makes mistakes.  Not everybody learns from them.  When things like that happen, I’m always willing to give a second chance (and sometimes even the third).  Maybe I’m just hoping that when I screw up people won’t just turn away.  Maybe I’m just an optimist – who knows.  But GitHub still provides the service that I enjoy using.  No matter the compromise, I (or any of my projects) haven’t been affected.  And I think that GitHub will learn from this experience.  So I don’t see any reason to change my attitude.