Are you looking for my non-technical blog?

This is now my technical-only blog, my non-technical blog is here.

25 February 2012

Getting Real - Agile Software Development

Yesterday I read an interesting book, written by the guys behind 37Signals, it's called "Getting Real". 37Signals is a Software Company that was founded in 1999 by Jason Fried and others, and David Heinemeier Hansson who joined the company in 2003 is the one behind the famous web-development platform, Ruby on Rails, which he created as a result of his work on Basecamp, one of 37Signals applications.

So back to the book, which you can read online by the way, is their trial to summarize how one can create software quickly by dealing with the actual problems he is trying to solve and staying agile and less complex. Or as they put it here.

Getting real is less. Less mass, less software, less features, less paperwork, less of everything that's not essential (and most of what you think is essential actually isn't).

I advise you to read it, however let me put here the most import point I liked the most.

As you have seen, the main idea of the book is to "Build Less", where "Less is More" or as Seth Godin put it in his - yet another interesting book, "Small Is the New Big". And you can do this by sticking to the following:
  • Half the features is better than half-backed features.
  • Ask yourself what is the main problem you want to solve and focus on it. For example, if it's a blogging system that you are creating, then focus on blog publishing part and let the tagging and commenting modules come next.
  • Don't compete with your competitors on features, this is an endless war. Beat them with your simplicity and your focus on the needs of your core customers and not the needs of everyone. 
  • Feel free to say No to new features requests. If you get a request for adding a new feature, ignore it and let it go. If it comes back to you, its yours to implement. If it doesn't, then it was never meant to be implemented.
  • Each time you say yes to adding new features you are adding complexity to your product.
  • Settings and Preferences add complexity to your project, and puzzle the uses. Feel free to take decisions for your users.For example, imagine you are designing and on-line shop, why your user go somewhere and set the number of results he gets in a page when searching for something? Why not stop for a moment and think, ain't 10 results too few and will bother the users with pressing next, next. Also 100 results might be too much and confuse the users and might not be suitable for those with slow internet connection. So guess what? You find 25 results is the most comfortable option for you as a user, then why not hard-code it. Well, may be later on, your users might not like this, so then you can think about it, but not now.  
  • Start with the core functionality of your software, then move to the less important features.
  • Fine tunings like alight this to left, move that two pixels to the left, etc. Those are stuff to be ignored and focus on making things work, and "iterative improvement" is your friend later on.
  • If it's not a problem that you are going to face now, then ignore it for now.
  • Scale later, don't bother yourself with scalability too early, most probably you will find out how to scale when scalability is needed.
  • Skip meetings as much as you can. Most of the time meetings are waste of time, so do your best to collaborate via short and to the point mails, or even tweets.
 Your development work-flow:
  • Brainstorm => Sketch => Interface => Code
You sure do the first two steps, you brainstorm then sketch your idea, design, database tables, etc. But being a coder myself, I always start with code then add the HTML to it later on. But let me quote the book to make it clear why the prefer doing the interface first:

Too many apps start with a program-first mentality. That's a bad idea. Programming is the heaviest component of building an app, meaning it's the most expensive and hardest to change. Instead, start by designing first. Design is relatively light. A paper sketch is cheap and easy to change. html designs are still relatively simple to modify (or throw out). That's not true of programming. Designing first keeps you flexible. Programming first fences you in and sets you up for additional costs.
We [also] start with the interface so we can see how the app looks and feels from the beginning. It's constantly being revised throughout the process. Does it make sense? Is it easy to use? Does it solve the problem at hand? These are questions you can only truly answer when you're dealing with real screens. Designing first keeps you flexible and gets you to those answers sooner in the process rather than later. 
As I said in the beginning, I advise you to read it, because for sure I cannot summarize it in a blog post, and also they sure it delivers the idea more than I do. I also may buy it as a hard-copy although it is available on line for free as a thank you gesture for those who wrote it.

P.S. I wish I can also adapt those ideas to other things other than software development, my day job is a Presales Manager, so why not apply this to both Network Design, Technical Sales and Team Management. Also some ideas here can be adapted to something totally different like drawing, or as Patrick Lafleur put it: "I really got over the "get into details right away" attitude after I took some drawing classes...If you begin to draw the details right away you can be sure that the drawing is going to suck. In fact, you are completely missing the point. You should begin by getting your proportions right for the whole scene. Then you sketch the largest objects in your scene, up to the smallest one. The sketch must be very loose up to this point. Then you can proceed with shading which consists of bringing volume to life. You begin with only three tones (light, medium, dark). This gives you a tonal sketch. Then for each portion of your drawing you reevaluate three tonal shades and apply them. Do it until the volumes are there (requires multiple iteration) ..."

    17 February 2012

    Notepad++ Sessions

    I don't remember using an IDE for writing code ever. I am allergic to such stuff. I prefer a text editors and command line compilers or interpreters. Earlier when I used to write C/C++ code on Linux, I used to write the Make file myself, on Windows I only code in Python since it doesn't require the IDE fuss. I think one of the main reasons that backs me off of writing mobile applications is that IDE's, Simulators and stuff like that are required there, let alone my natural hatred for Java.

    Anyway, I normally use Notepad++ as my text editor on Windows, and one of its cool features is that it remembers the files you had open in your last sessions and opens them the next time you use the program. Think of it that same way Firefox remembers the tabs you had open the previous time you used it. It's cool, it makes life easier when working on a project consisting of many files, instead of opening each one of them every time, yet sometimes you find yourself having zillions of open files from unrelated projects. So here is some other alternative.

    Notepad++ Sessions

    In Notepad++ you can save your current session into a file, hence you can have a session file for each project you are working on.

    First of all, go to "Settings >> Preferences.." then un-check the "Remember current session ..." field and assign a file extension for your session files, I used ".npp" here, but you can invent any extension.

    Now whenever you are on a project with many open files, go to "File >> Save Session" and save your session into a file with .npp as its extension, next time whenever you click on that file your previous session for that project will be open. Whenever you add or remove files to your project you can Save your session and overwrites your session file with those new updates.

    Python vs Ruby - String to Integer

    I'm a big Python fan, but recently, I decided to have a look at Ruby. I'm still not that qualified to do a comparison between the two languages, so let me instead take a snapshot from each of them and do a quick comparison based on it, and based on my own understanding of each.

    Both languages have their ways to transform a strings with integers in there into integers.

    In Python:
    >>> int("33")
    >>> int("33 + 3")
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: invalid literal for int() with base 10: '33 + 3'
    >>> int("Three")
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: invalid literal for int() with base 10: 'Three'

    In Ruby:
    irb(main):007:0> "33".to_i
    => 33
    irb(main):008:0> "33 + 3".to_i
    => 33
    irb(main):009:0> "Three".to_i
    => 0

    So first of all, Ruby seems to be more strictly Object Oriented language, than Python. Sure, Python treats everything as an Object too, a String or an Integer are objects in both languages and they have their own properties and methods, which is not the case with C for example, however I see here that Python uses a built-in methods, while Ruby - which also has its built-in methods - yet it tended more to do the transformation here the object way. 

    Python prefers to have one - and preferably only one - obvious way to do things, hence when I typed stings composed of stuff other then integers it returned an error. It tends to make it easier for programmers to predict the result. While in Ruby, the result wasn't that obvious, it tried not to return an error and decided to think in an work-around for me me, on the second line it just took the integer part at the beginning of the string then ignored the rest of it, while in the third line it returned zero. At the end of the day, this is a matter of taste, some people might like the Python way of keeping everything predictable, while some others might like the Ruby easy-goingness and not nagging and returning errors to them all the time.

    16 February 2012

    Pinterested in getting new Glasses

    You sure was hit with the hype of nowadays, Pinterest. I got an account there about a week ago, was not able to figure out what's that! Well, I added the "Pin It" to my browser and every now and then, I pin something there and then visit the site out of curiosity to find out how the pin will look like there. See, it doesn't look like a pinteresting website at all. Pun intended. But today I found a use for that website, and may be this is how it's meant to be used.

    I want to buy new glasses, so once more out of curiosity I decided to search for men's glasses in the up left corner of Pinterest's homepage, and it's apparent according to the results that geeky plastic frames are hot nowadays ... wait a minute ... so this is gonna be a sort of social searching engine or something!? Why not? A generic search for something like Superman on Google gets you some results from Wikipedia and IMDB, while on Pinterest the results are different for the same search query. How about "Business Card Design" or "Future Technology"? See, there is a use for that thing.

    09 February 2012

    Kippt = Delicious + Instapaper

    When not coding, I like to write posts reviewing new Web2.0 services, it's fun, isn't it?

    Dilicious & Instapaper

    During the old days of the dial-up internet I used to visit pages, without reading them to keep them in my browser's cache to read them later. Later on, I started using, yeah, I started using almost after it was launched, and when its name was written in such domain hack way. At that time, Delicious was a hybrid of saving links for reading them later, a replacement for my browser's bookmarks, and more important, a way to discover interesting links and stuff to read via its social bookmarking capabilities. Almost a year ago when I got my first tablet, I started to explore the charm of reading my "to be read later" links from the couch or in bed, hence I started using Instapaper. It saves links, de-clutters the web-pages and syncs them to be read off-line. Now things started to get a bit confusing. How to sync my to-read links in Delicious to Instapaper? How to move the stuff I like in Instapaper to my Delicious for my future reference? If This Then That, or can be handy here, but still it works one way but not the other way round between Instapaper and Delicious.


    Won't it be great to find a tool that does the two tasks? Kippt, which is pronounced like "Keep It", is both a bookmarking service and read-later tool. They have a GTD-isque interface with a boxes marked as Inbox, Read-Later, and Starred Items. It can also import your Instapaper, Diigo, Delicious bookmarks, as well as some other services. However they are still in early-stage, so there are some missing features that I'd like to see there, such as:
    • Android Application to sync my "Read Later" pages. Something a-la InstaFetch, and integration with Android's Share Button to save bookmarks from my Tablet/Phone while surfing the internet.
    • Bookmarked links aren't tagged. As I told you, I am an old Delicious user and I am used to tagging my bookmarks there. Don't know if they are going to add Folksonomy to bookmarks and may be tag stuff saved for later reading as well or not?
    • Some social features, i.e. be able to see my see my friends bookmarks, or for example see all bookmarks people saved under the term "Python".
    • API, so for example can create recipes to integrate more services with them. Let's say, I want to import all links in tweets I star on twitter to Kippt.
    I am not sure if they are going to implement all those features, but I know for example that they will be releasing an API and Mobile App sometime soon.

    Kippt: - @KipptApp