We developers are the masters of an ever-changing field. What programming is today usually isn’t the same as programming tomorrow. IT is improving, changing, trends arise and die, new languages, new platforms are born, better solutions come forth for old problems. We need to keep up with the changes and also constantly improve ourselves. This is not optional, this is crucial.

Below you can find a few tips which will help you walk the line, become a better developer.

Have you heard the term ‘Kaizen’? If not, shortly it’s a term for improvement. Of course it’s more than a mere word, it’s a philosophy, a philosophy of constant change for the better. It requires objective monitoring and improvement. Go ahead, read a bit more about it here, you won’t regret.

My tips are, without any specific order:

• Read code

Read others code often and thoroughly. Look for proven quality code in production software. Learn how things work. See others’ solutions to the problems you also face or will surely face sometime. Compare solutions, techniques.

• Write code

Choose a problem you’ve never solved before. Work your way through it, give it time. Try to objectively study yourself, your ways of thinking, your mental patterns. You will realize _many_ very interesting things by doing so. It’s not that hard and it’s an immense source of good feedback. Also try to implement things in different ways and compare the pros/cons of your solutions. Use aspects like “modularity” and “system integration”. Write code which is pure, simple. Almost everything can be solved in a simple way.

• Keep up to date with technologies and trends

You’re on twitter and facebook anyway, start following tech leaders and tune up your RSS source list. Don’t be the last to know about that new language. Of course be picky about what you delve into, don’t follow trends like a blind sheep. A big part of tech improvement is in fact improvement, so get to know it, as early as possible.

• Try to look at things from many different points of view

Sure, you’re a developer, but would you use your own product as a plain simple user? What about business values? Does that new pice of l’art pour l’art code bring any value? Did you make a change? What resources did it take? Weren’t there any more important things which would have brought greater value? What is the meaning of the software you’ve just delivered? What’s is role in the big picture? These questions seem banal and trivial, but they aren’t. We should be asking these questions constantly. Start and you’ll see the difference.

• Test your code, measure your code

Untested code is just a promise. Unmeasured code is hard to learn from or improve. Would you give your money to a complete stranger on a vague promise? Do your testing in many levels, starting from unit testing. Do functional and integration tests. Prove that your code works. Convince others. Push your code to that git repo with a big smile instead of a worried look. Measure your code coverage, code complexity and code smell. Tune. Improve.

• Seek community with other developers

Learn from others. Discuss problems with others. Take reading their code to a higher level. Help them if you can. Be open-minded, accept and analyse other solutions and ideas.

• Deliver something useful ever day.

Learn to break down long projects into smaller, deliverable parts. Do milestones. Do tested, proven, working milestones. Deliver something. Show your value. Don’t sit on projects for long weeks. Show your progress. Analysis and synthesis are essential to our trade. Deliver something, now, today. Watch the difference it’ll make in your self-confidence and in how others view you. Be a happier coder.

• Break away from programming from time to time

Recreation. Different activities, sports, nature. Your body and your brain needs it. Also the best ideas often arise not while sitting and staring at the screen but while walking in the forest.

Subtitle: A case study on why you should use HTTPS for all sites you have an account on.

So you want to know how to steal someone’s facebook identity. How to impersonate the poor victim. How to post embarrassing status updates, pictures in his/her name. Naughty, aren’t we? Let’s view this as a tech challenge instead, forget the nasty things we could do with it. This howto touches basic online security issues and some networking internals. Prepare for the journey, fasten your seatbelts.

Guys, first, seriously, this is definitely not a nice thing to do. Really. Don’t do it. Stop reading right now.

Well, if you still insist…

Here’s a list of ingredients:

• A LAN to operate on. It can be your school’s LAN, your workplace or your home router’s network.
• Some basic knowledge about network protocols: ARP, TCP/IP, Ethernet and HTTP
• Ruby skills. Get some. Really. Trust me, it’s worth it!
• A UNIX-based OS. This might work on windows, too, but no guarantees. I use OS X for daily work.
• Patience. Sometimes a lot.

A short intro to ARP

ARP stands for “Address Resolution Protocol” and – well, what do you know – it handles MAC and IP address conversions on a conventional TCP/IP ethernet based network. As you all know, TCP/IP packets are encapsulated in Ethernet packets, and Ethernet only knows those so-called MAC (Media Access Control) addresses, it has no idea about IP addresses or domain names.

When you send a standard TCP/IP packet from your machine, your OS wraps it up in a nice Ethernet packet and asks your network card to kindly send it to the network card which has the destination MAC address (it is much more complicated (routing, etc.) but this is enough for us in this project).

Therefore your OS needs to know which IP address(es) belong to which MAC address. Of course if there’s a router involved (and there must be if you’re on a LAN) it also needs to know this. This table is filled up when ARP messages travel on the network. An ARP announcement or reply message basically says “hey guys, the IP 1.2.3.4 is associated to the mac address 03:f9:06:e4:6b:0b”.

This IP <—-> MAC conversion list is called the ARP table or ARP cache. We are going to ‘poison’ this table. More on this a few paragraphs later.

A few thoughts on sessions, users and logins

Most sites are using cookies to handle user logins and authentication. HTTP is a stateless protocol. A stateless protocol does not require the server to retain information or status about each user for the duration of multiple requests. To have some kind of identification, we use cookies. A cookie is a key-value pair stored in the browser (so client-side) with two more extra information: lifetime and access control. With each request, if the cookie is still alive (lifetime) and the access control allows the server to receive the cookie, the client sends the cookie in its headers. You can read more on this here. The cookies are first sent by the server (or server application) which this way try to store user-level data, such as login state, userid, etc.

For example, the most interesting cookies coming from facebook are: c_user , datr , sct and xs – they are enough to identify session for a logged in user. When we log in to facebook, these cookies get set and on every request the server knows who we are (and that we are logged in) using these cookies which the browser sends back every time. We will  intercept these cookies travelling on the network from our victom to facebook’s servers.

How to intercept communication on a LAN

This is actually easier than you’d think, thanks to serious security flaws in the design of the ARP protocol. Well, ARP is old and back then there weren’t so big security concerns.

Basically we’re going to lie to our victim’s machine saying we’re the router, and also lie to the router saying we’re the victim’s machine.

Let’s imagine a network with 3 hosts: 1 router and 2 client ‘user’ machines. The router has the IP 10.0.0.1 and the clients have 10.0.0.100 and 10.0.0.101. We are 10.0.0.100 and our victim is 10.0.0.101.

To achieve this, recall ARP. We send an ARP announcement/reply to the victim’s machine stating that the router’s IP address is associated to our MAC address, thus every TCP/IP package sent to the router by the victim’s machine will actually be sent to us. The other half of the story is that we also send an ARP message to the router saying that the victim’s IP address is associated to our MAC address this way we get the response packages coming from the router to the client. Then all we need to do is read the travelling packages while forwarding them respectively to the router and the client (so that packages really also reach their destination).

Well, we also need to enable something in the OS which is called ‘packet forwarding’ so that packages not targeted to us get accepted and parsed.

In linux, it is a simple

echo 1 > /proc/sys/net/ipv4/ip_forward

In OS X, it’s a bit different

sysctl -w net.inet.ip.forwarding=1

Now the stage is set to do some programming.

We will use ruby (1.8 and 1.9 are both good), and we will need the gem called ‘PacketFu‘ and its dependency PcapRub which is a ruby wrapper to the libpcap library. These will help us with low-level network operations and packet capturing, parsing.

First things first, let’s send out the ARP spoofing packages:

arp_packet_victim = PacketFu::ARPPacket.new()
arp_packet_victim.eth_saddr = 'd2:7b:9c:71:7b:6f'       # our MAC address
arp_packet_victim.eth_daddr = 'd4:9e:cb:08:5a:27'       # the victim's MAC address
arp_packet_victim.arp_saddr_mac = 'd2:7b:9c:71:7b:6f'   # our MAC address
arp_packet_victim.arp_daddr_mac = 'd4:9e:cb:08:5a:27'   # the victim's MAC address
arp_packet_victim.arp_saddr_ip = '10.0.0.1'             # the router's IP
arp_packet_victim.arp_daddr_ip = '10.0.0.101'           # the victim's IP
arp_packet_victim.arp_opcode = 2                        # arp code 2 == ARP reply
 
arp_packet_router = PacketFu::ARPPacket.new()
arp_packet_router.eth_saddr = 'd2:7b:9c:71:7b:6f'       # our MAC address
arp_packet_router.eth_daddr = '29:ef:54:43:78:32'       # the router's MAC address
arp_packet_router.arp_saddr_mac = 'd2:7b:9c:71:7b:6f'   # our MAC address
arp_packet_router.arp_daddr_mac = '29:ef:54:43:78:32'   # the router's MAC address
arp_packet_router.arp_saddr_ip = '10.0.0.101'           # the victim's IP
arp_packet_router.arp_daddr_ip = '10.0.0.1'             # the router's IP
arp_packet_router.arp_opcode = 2                        # arp code 2 == ARP reply
 
# we send out both packages
arp_packet_victim.to_w(@interface)
arp_packet_router.to_w(@interface)

Actually in a real-world situation we need to keep sending these packages during the whole capturing session, for example in a thread.

Now we start a capturing session on the designated interface with some default filtering (port: 80 and HTTP requests. See the filter format tutorial for more info)

capture_session = PacketFu::Capture.new(:iface => 'eth0', :start => true, :promisc => true, 
                                        :filter => "tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)")

Now we only need to see if there’s any cookie travelling:

capture_session.stream.each { |packet|
  puts "Woohoo I found a cookie" if packet =~ /ookie/
}

Nice and easy. We can then parse these cookies and save them in for example netscape cookie format, which we can import  to a browser session with a firefox plugin called Cookie importer.

So, what is the lesson? Always use HTTPS. Always.

P.s.: If I get enough tweets, likes, +1-s and comments, I will post a complete ruby codebase which is a real working facebook and twitter session hijacker

UPDATE

I’ve published the code: https://github.com/ochronus/ArpSpoof

Concurrency is a hard topic in programming with many advanced concepts. We love libraries and solutions which help us during our everyday simple tasks. The ‘parallel’ gem is one of these – well, gems -. You can find it at github. The author’s own description:

Run any code in parallel Processes(> use all CPUs) or Threads(> speedup blocking operations).
Best suited for map-reduce or e.g. parallel downloads/uploads.

Let’s see some simple example of its usage.

Sample code:

require 'rubygems'
require 'rubygems'
require 'parallel'
require 'net/http'
require 'benchmark'
 
 
ping_hosts = lambda {|host|
  10.times { Net::HTTP.new(host).head('/') }
}
 
puts "#{Parallel.processor_count} procesor(s)"
hosts = ['www.ruby-lang.org', 'programmingzen.com', 'blog.headius.com', 'chadfowler.com', 'drnicwilliams.com', 'igvita.com']
 
Benchmark.bm do |x|
  x.report('normal') { 
    hosts.each &ping_hosts
  }
  x.report('thread') { 
    Parallel.each(hosts, :in_threads => Parallel.processor_count, &ping_hosts)
  }
  x.report('fork') { 
    Parallel.each(hosts, &ping_hosts)
  }
end

This code basically gets the root document of the http servers listening on port 80 on the list of domains, 10 times.
The first run in a simple sequential run, we call this ‘normal‘ in the benchmark.
Then we instruct the parallel library to use as many threads as our CPU core count is, this is the run called ‘thread‘
Finally we use forking (the default operation of the library), naturally this run is called ‘fork‘.

The results on my machine are:

8 procesor(s)
      user     system      total        real
normal  0.070000   0.080000   0.150000 ( 33.270311)
thread  0.040000   0.030000   0.070000 (  7.227803)
fork  0.010000   0.030000   0.330000 ( 10.276050)

I think this shows how easy and straightforward it is to use this library for everyday parallel tasks. Of course we haven’t covered advanced contexts as locks, mutexes, shared data, etc. – this library is not made for that.

Samurais are cool, but why? Is it that they wield sharp swords? No, it’s because they act cool. They act cool-headed, professional. They decide in the fraction of a second and they always get through their ways. They are zen warriors.

Now, I want this behaviour from all of my developers and team leads. Especially team leads as they show the way to others.

I want them to be like this:

And not this:

This should be easy, (really) yet somehow it poses a problem for many people. They seem to lack self-confidence and they feel they are not good enough. Well for some this might be true but most of them are good enough. Or would be. And this is the difference, this is the final step they need to take. They need to let go of fears, doubts and just do it (not a Nike ad, I swear). Hesitation kills the game. Make a bold, professionally based decision and go with it. Be the owner of your project right from the start to the end. Learn to decide and lower your reliance on others. Use your authority. That’s why you are here.

What is feature hell and how to escape it? Have you ever been on a project that just never seemed to get done because tons of features were planned (and added as the project went)? Well, my friend, then you’ve walked through feature hell. Feature hell is implementing features that will be rarely used, are not crucial and don’t deliver (much) customer value. Moreover these features can easy lead to overcomplication of the product, resulting in bad user experience and much worse maintainability. See the wikipedia entry for feature creep.

So how can we escape? Well, this escape starts from above, management and product owners need a paradigm shift. They need to understand that by removing unneccessary, delaying features the product will be even more of value, not less and it will even be delivered earlier. It’s a hard thing at the beginning, “letting go” of features but after a few iterations it starts to show its value.

Nice, but how do we know which features would be useful and which wouldn’t? Everyone wants their ideas implemented and delivered and they all think theirs is the most important feature ever.

Based on my experience most of the unimportant features can be weeded out by just taking an objective point of view and thinking. Yes, common sense has its proven powers. This is not always enough, measurement is also very important. Measure the usage (how many users use it, how they use it), try out scenarios, A/B test a lot, do focused surveys, involve many colleagues in brainstorming. Usually it’s not that hard. It takes a bit more time while planning, but spares a lot of resources when implementing. Also create project plan scenarios to show management the big win. Tell them that implementing with the top 20 features will take 2 weeks but if they want the other 15 unimportant (based on common sense and former measurements/surveys) features it will take a month. Let them choose. Trust me, everyone loves short and effective projects.

I’m sure you’ve been in the situation you had to test some ideas quickly, but irb itself was not enough because the code was too complicated for a simple run-while-typing scenario, so you’ve created your Nth test.rb and ran ruby test.rb for the gazillionth time. You must have wondered if there’s a better way. Aye. There is. It’s called interactive_editor and it’s a gem. In both meanings

You can do a simple gem install interactive_editor . If you want to take a closer look, see https://github.com/jberkel/interactive_editor.

What this gem does is basically allowing you to launch an editor from your irb session and edit your code there, which is run upon exiting from the editor. If you need to modify, just relaunch the editor and you’re presented with the code again. Priceless. In pictures – click the image for a real-world size:

Then you want to modify the code:

Oh, and interactive_editor supports vim, mvim, vi, emacs, nano and textmate. Nice.

Another tip: you can just add this to your .irbrc so it gets auto-loaded on every irb launch:

require 'rubygems'
require 'interactive_editor'

Interactive_editor leaves no trash behind, it operates using temporary files. Nice and clean.

sony playstation, playstation network, security breach, sony hack

With Sony‘s recent fiasco (PSN hacked, user data, including passwords stolen) the old topic of password storage is in spotlight again. Is it really that hard to store passwords securely? Obviously not. Let me show you how a post-stone age developer would solve it and some of the cryptographic background.

First of all, what’s so wrong with storing passwords as-is (plaintext)?

Basically, it offends your users’ right to privacy. You, the sysadmin, the IT guy or a hacker can get access to it. It’s a huge security risk in your service (the hacker can then impersonate your users easily) and also many users use the same passwords on many sites, so you might easily be posing a security threat to other sites, companies. Moreover, many people choose personal passwords – sensitive insights about them is thus revealed by their password choice. As a summary, it’s both unethical and insecure to store plaintext passwords.

What’s the solution then? We have to be able to verify the user somehow upon login, don’t we? True, but for this, the password itself is of no information. The real information in the authorization process is whether the person on the other end of the line knows the password or not. It’s a huge difference. So how do we verfiy the knowledge itself without actually storing the information? We need something that produces some obfuscated info from the original, sensitive plaintext data (password). We have many possible candidates for this, e.g. simple checksum, crc , the point is that it’s like a function which always produces the same output from a single input. With such a function at hand we only need to store the result of the function, the obfuscated info, then during authorization use the same function on the typed-in password and see if the outcome is the same as the stored value.

This is only one part of the whole story, though. Simple checksums and crc’s are not considered secure, because when someone gets hold of your database containing the obfuscated values, there are mathematically very easy (simple and fast) ways to recover the original password from them. Enter secure hashes.

A secure (also called cryptographic) hash is an one-way function which has the following properties:

• it is easy to compute the hash value for any given message (fast forward calculation),
• it is infeasible to generate a message that has a given hash,
• it is infeasible to modify a message without the hash being changed,
• it is infeasible to find two different messages with the same hash.

Some of the best known secure hash algorithms are MD5 and SHA*. Their usage is quite simple: take your favourite language (or use MySQL‘s, etc. built-on functions), get a lib for it if these crypto functions aren’t built-in, when the user registers, calculate the hash, store it in your DB and when it’s stolen, no hacker will be able to recover the password.

Really? Well, not really. Simple MD5 and SHA-1 are still quite vulnerable. There’s a clever attack on them, known as the rainbow table attack. Basically rainbow table is an efficient data structure to store precomputed hash chains. It’s like a cache for brute-force trial attack and it’s proven to be quite effective.

OMG, what can I do then?

Don’t panic. It’s not a lost fight. Fortunately rainbow table efficiency can be nulled with using a very simple method: salts. Salting is adding a pre-generated (used as a constant in the registration-authorization cycle) string which you automatically add (concatenate) to the passwords before you’re giving them to the secure hash functions. For example given your pre-generated salt is ‘iw8ahphieBa7aesahLeenaKae3lae0ee’, when the user registers with the password ‘i love bunnies’, you’ll be hashing like this: stored_hash = md5(‘I love bunnies iw8ahphieBa7aesahLeenaKae3lae0ee’).

Even better, periodically ‘change’ your salt. Say at every 10th user you generate a new salt and from that time you use it. Of course this method requires storing additional information, like salt history, but it’s a quite secure solution.

Well, I hope you agree by now that secure password storage is not a myth, it’s a quite easy method. Please share your experience and further thoughts!

Edit

A few really nice comments came up, and after reviewing some solutions I feel you’re right – currently the best way is to use bcrypt. Thanks for the great comments and suggestions guys!

As a sequel to my HTML5 page structure article I present a basic CSS1/2/3 reset:

* { outline: 0; }
html, body { min-height: 100%;  }
body, ul, ol, dl { margin: 0; }
img { border: 0; }
article, aside, audio, footer, header, nav, section, video { display: block }
input[type="submit"]::-moz-focus-inner, input[type="button"]::-moz-focus-inner { border : 0px; }
input[type="search"] { -webkit-appearance: textfield; }
input[type="submit"] { -webkit-appearance:none; }
img.right { float: right; margin-left: 2em; clear: right; }
img.left { float: left; margin-right: 2em; clear: left; }
table { border-collapse: collapse; }
th { background: #000; color: #fff; }
td { padding: 1em; border: 1px solid black; }

A html5 website template starter kit.

<!DOCTYPE HTML>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>My shiny site</title>
</head>
<body>
<header>
<nav>
<ul>
<li>Menu item</li>
</ul>
</nav>
</header>
<section>
<article>
<header>
<h2>Article title</h2>
<p>Posted on <time datetime="2011-04-15T16:31:24+02:00">April 15th 2011</time> by <a href="#">Writer</a> – <a href="#comments">6 comments</a></p>
</header>
<p>Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.</p>
</article>
<article>
<header>
<h2>Article title</h2>
<p>Posted on <time datetime="2011-04-15T16:31:24+02:00">April 15th 2011</time>  by <a href="#">Writer</a> – <a href="#comments">6 comments</a></p>
</header>
<p>Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.</p>
</article>
</section>
<aside>
<h2>About section</h2>
<p>Donec eu libero sit amet quam egestas semper. Aenean ultricies mi vitae est. Mauris placerat eleifend leo.</p>
</aside>
<footer>
<p>Copyright 2011 Your name</p>
</footer>
</body>
</html>




 

In this post I look at some hand-picked changes in ruby 1.9 including new features and deprecations. Of course you can check the full changelog anytime at the main Ruby Language Site.

Ruby 1.9 brought forth some very nice and important changes which have been refined in v1.9.1 and v1.9.2. Naturally upgrades come with a cost: some of the new features might/will break compatibility with old codes and solutions. I’ll show you the most important things to look out for and also some of the awesomeness of this new version of ruby.

Some of the most important improvements in ruby 1.9

• Much better threading – performance and tools are superior to ruby 1.8. Read more about threads and fibers at Paul Barry’s blog.
• Unicode support, finally. Also a brand new encoding engine has been added. There’s a very informative blog post about this on Yehuda Katz’s blog.
• The interpreter’s performance had been vastly improved. Check out the (v1.9.0) benchmark.
• Rubygems is now integrated into ‘ruby’ itself.

Let’s look at the main incompatibilites that can break your code

• The shiny new String class.
• Literal Hash constructor has changed.
  • {“a”, “b”} no longer makes a Hash but a nice syntax error. You have to use {“a” => “b”} or {:a => “b”} or  {a: “b”}

Now for the other important changes and upgrades

Changes in the Hash class

• Hash finally preserves insertion order
  • Ruby 1.8
    
    ^?View Code RUBY

    hash = {:a=> 'A', :b=>'B', :c=>'C', :d=>'D'} hash.keys ====> [:b, :c, :d, :a] hash.values ====> ["B", "C", "D", "A"]

  • Ruby 1.9
    
    ^?View Code RUBY

    hash = {:a=> 'A', :b=>'B', :c=>'C', :d=>'D'} hash.keys ====> [:a, :b, :c, :d] hash.values ====> ["A", "B", "C", "D"]

• Hash#to_s behaves much nicer
  • Ruby 1.8
    
    ^?View Code RUBY

    hash = {:a=> 1, :b=>2, :c=>3, :d=>4} hash.to_s ====> "b2c3d4a1"

  • Ruby 1.9
    
    ^?View Code RUBY

    hash = {:a=> 1, :b=>2, :c=>3, :d=>4} hash.to_s ====> "{:a=>1, :b=>2, :c=>3, :d=>4}"

• Hash#select now returns a hash, not an array
  • Ruby 1.8
    
    ^?View Code RUBY

    hash = {:a=> 1, :b=>2, :c=>3, :d=>4} hash.select{|k,v| k == :c } ====> [[:c, 3]]

  • Ruby 1.9
    
    ^?View Code RUBY

    hash = {:a=> 1, :b=>2, :c=>3, :d=>4} hash.select{|k,v| k == :c } ====> {:c=>3}

String changes

• Single character strings
  • Ruby 1.8
    
    ^?View Code RUBY

    irb(main):001:0> ?c => 99 irb(main):001:0> "cat"[1] => 97

  • Ruby 1.9
    
    ^?View Code RUBY

    irb(main):001:0> ?c => "c" irb(main):001:0> "cat"[1] => "a"

• Encoding, encoding, encoding
  • All strings have an additional chunk of info attached: Encoding
    
    ^?View Code RUBY

    ruby-1.9.2-p136 :003 > "whatever".encoding => #<Encoding:UTF-8> ruby-1.9.2-p136 :004 > "whatever".encoding.name => "UTF-8"

  • String#size takes encoding into account – returns the encoded character count
    
    ^?View Code RUBY

    puts utf8_string.size # >> 6 puts latin1_string.size # >> 6

  • You can get the raw datasize
    
    ^?View Code RUBY

    puts utf8_string.bytesize # >> 8 puts latin1_string.bytesize # >> 6

  • Indexed access is by encoded data – characters, not bytes
    
    ^?View Code RUBY

    puts utf8_string[2..4] # >> sum puts latin1_string[2..4] # >> sum

  • You can change encoding by force but it doesn’t convert the data
    
    ^?View Code RUBY

    my_string = "Whatever" puts my_string.encoding.name # >> US-ASCII my_string.force_encoding("UTF-8") puts my_string.encoding.name # >> UTF-8   # changing the encoding doesn't convert the data though! latin1_string.force_encoding("UTF-8") puts latin1_string.encoding.name # >> UTF-8 puts latin1_string.bytesize # >> 6 puts latin1_string.valid_encoding? # >> false latin1_string =~ /AR/ # !> ArgumentError: invalid byte sequence in UTF-8

  • You can re-encode a string to ‘fix’ the above ‘error’
    
    ^?View Code RUBY

    transcoded_utf8_string= latin1_string.encode("UTF-8") puts transcoded_utf8_string.valid_encoding? # >> true

  • Iterators have changed as String is not Enumerable anymore
    
    ^?View Code RUBY

    #Use each_byte, each_char or each_codepoint   utf8_resume.each_byte do |byte| puts byte end # >> 82 # >> 195 # >> 169 # >> 115 # >> 117 # >> 109 # >> 195 # >> 169   utf8_resume.each_char do |char| puts char end # >> R # >> é # >> s # >> u # >> m # >> é   utf8_resume.each_codepoint do |codepoint| puts codepoint end # >> 82 # >> 233 # >> 115 # >> 117 # >> 109 # >> 233   # if you need custom processing, you can get the enumerators with bytes, chars, lines and codepoints   p utf8_resume.bytes.first(3) # >> [82, 195, 169] p utf8_resume.chars.find { |char| char.bytesize > 1 } # >> "é" p utf8_resume.codepoints.to_a # >> [82, 233, 115, 117, 109, 233] p utf8_resume.lines.map { |line| line.reverse } # >> ["émuséR"]

Block variables now shadow local variables

#Ruby 1.9
 
irb(main):001:0> i=0; [1,2,3].each {|i|}; i
=> 0
irb(main):002:0> i=0; for i in [1,2,3]; end; i
=> 3
 
#Ruby 1.8.6
 
irb(main):001:0> i=0; [1,2,3].each {|i|}; i
=> 3

tr and Regexp are Unicode-compatible

You can now specify source file encoding

Basic

# coding: utf-8
Emacs

# -*- encoding: utf-8 -*-
Shebang

#!/usr/local/rubybook/bin/ruby
# encoding: utf-8

Inject methods

#Ruby 1.9
 
[1,2].inject(:+)
 
#Ruby 1.8.6
 
[1,2].inject {|a,b| a+b}

Lambda shorthand syntax

#Ruby 1.9
 
p = -> a,b,c {a+b+c}
puts p.(1,2,3)
puts p[1,2,3]
 
#Ruby 1.8.6
 
p = lambda {|a,b,c| a+b+c}
puts p.call(1,2,3)

Complex numbers

#Ruby 1.9
 
Complex(3,4) == 3 + 4.im

Multi-splat

# This will work on both Ruby 1.8 and 1.9
a, b, c = *[1, 2], 3
 
# This will fail on 1.8, but work on 1.9
a, b, c = 1, *[2, 3]
 
# Even this will work on 1.9, but not 1.8
a, b, c, d, e, f = *[1, 2], 3, *[4, 5]

Blocks now can accept block arguments

define_method(:answer) { |&b| b.call(42) }

What do we have to learn from the last years’ extreme popularity of iPhone, iPad and their top applications? Why is the appearance of these devices so important? Do they really mean the end of an era and the beginning of the next one?

To me, they do mean the end of an era: the end of developer-driven design. Game over. Now usability is king. Now the user, the customer drives design. Crappy devices, inconsistent interfaces can’t make a living anymore. Apple has started this silent revolution with realizing the opportunity and now others start to follow the path.

Need something? “There’s an app for that” – and usually a nice, consistent one (of course we come across lame apps from time to time but those don’t live long now). Know OS X? Used iPhone/iPad a bit? You already know most of the important stuff for your next Apple device. We like good interfaces and now we know we can get them. From now on any company that thinks it can feed us with crappy user experience is doomed. We’ve tasted good design and there’s no going back.

I’m writing this on my hackint0sh as my MacBook Pro sleeps quietly in my backpack and my iPhone is synchronizing my contacts, mails and calendars.

Apple might be evil and of course it only focuses on its own success and profit – but for now its interests coincide with our interests.

What makes the candidate ‘click’? Programming or creating?

Does the candidate seem like a person who feels projects his own?

Will he take responsibilty and ‘parent’ his projects? Specifications and needs are many times incomplete and devs who pay extra attention to their projects usually spot these ‘weak points’ or holes, thus they get fixed/covered before the release, not days/weeks after in the forms of bugreports.

School is important but it will never replace experience.

School is great and neccessary for a firm understanding of maths, structured thinking, etc..

Experience is king, things rarely work as specified in 10 years old books in the field of development. It’s even more true for online development.

Do I see the will to improve in the candidate?

Nobody’s perfect. Nobody knows everything. This field is ever-changing, devs need to keep updating their knowledge. Enthusiasm for the field is a must, they need to have that ‘fire in their eyes’ when they talk about their profession. People generally won’t improve only because of the fear of getting fired, they need real motivation – which greatly comes from their own enthusiasm.

I like to surprise the candidates with questions/problems from different fields.

It shows if they’re smart or only experienced in development. Begin smart and analytical is very important, they should be able to quickly analyze and solve problems in general, not only in development. It’s a different mindset which won’t form by simply writing tons of code. Look for the architect, not the coder.

Is the candidate prepared to “unlearn”?

Some methods, knowledge are just simply outdated, not valid anymore. Many people have trouble letting go of old knowledge – and it will mess with new knowledge in that field.

Is he able to focus and simply keep unimportant things out?

Unfortunately like the last point It’s hard or impossible to test. It’s very important when people come bugging him or there’s a ton of things to do and he has to priorize.

Teamwork.

Lone wolfs are fine from time to time, but being the part of a team is neccessary. Decent communication skills are required.. Also here ‘letting go’ can play role as sometimes someone else will take his work over. People get reassigned, etc.

Testing skills.

Lack is a no-go. They should at least have the right mindset.

Polyglot skills.

Have a whole picture – it’s related to experience vs. education only.

Experienced developers tend to have better overview and won’t get lost in the details. If you spend 2 weeks trying to figure out how to make a query work faster in MySQL, you’re probably wasting time. After a day or to you should have moved on to another solution and went on with the project.

Also check out my post on how to be a better deveoper - you might even pass an interview

The net’s been loud with google’s mod_pagespeed lately.

According to the project page:

mod_pagespeed is an open-source Apache module that automatically optimizes web pages and resources on them. It does this by rewriting the resources using filters that implement web performance best practices. Webmasters and web developers can use mod_pagespeed to improve the performance of their web pages when serving content with the Apache HTTP Server.

mod_pagespeed includes several filter that optimize JavaScript, HTML and CSS stylesheets. It also includes filters for optimizing JPEG and PNG images. The filters are based on a set of best practices known to enhance web page performance. Webmasters who set up mod_pagespeed in addition to configuring proper caching and compression on their Apache distribution should expect to see an improvement in the loading time of the pages on their websites.

This all sounds very nice, so what are my objections? Read along.

First, I’m always very critical of automatic optimisation techniques. They shade developer responsibility and awareness and can do some disastrous, unintended modifications in the background.

My points are:

• A web developer should have a clear knowledge about optimization techniques and do them in the template, css, etc.
• Don’t impose additional load on the web server just because you lack the knowledge or you’re just lazy
• There’s much more to web sites than performance. How about SEO? Are you sure that an automatic reorganization of your html source is SEO friendly? Maybe mod_pagespeed is harmless in 99% of the cases, but still TAKE A DAMN LOOK.
• mod_pagespeed can be a very nice tool supporting development, though! You can use it to check out possible optimizations, opportunities that you might have missed. Use it as some kind of HTML+CSS template generator that transforms your first-run code to something possibly more optimized which you can alter by hand.

So as a summary, I’m sure mod_pagespeed can be a very nice tool in development mode to spot possible optimization opportunities, and also for large static-html CMS, etc. providers so that big chunk of unoptimized and messy static html pile gets a major performance upgrade, but I’d encourage every web developer to do these optimizations by hand or semi-automatically.

Let’s meet HTTP GET ‘s little brother

According to Wikipedia:

Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.

This means that we have a faster way of checking the headers and some server info for a given resource on the server. So the first trivial way of using a HTTP HEAD request is checking if a given url is serviceable, a given file exists, etc.. This can be used for example for creating a faster link verification service.

Also HEAD returns the full headers, so we can do a LastModified/ContentLength check to decide if we want to re-download a given resource.

There’s another simple use of HEAD: you can log js based content appearances. For example you have an ad service which is js based and you’d like to log the number of appearances. You could naively count the number of downloads in the web server’s access log to that specific js but that has some false positives so you’d better move the ‘I’m shown’ logic to the ad itself. The classic way is counting the number of image accesses or adding a special 1-pixel image, but there’s also a simpler way: just have the js code make a HEAD request to the server. You can then configure the server to log those HEAD requests separately and voila – you have your ad display stats with near zero resource usage (at least in regards of serving content) on your server.

These are just some basic ideas, I feel that HTTP HEAD is unfairly forgotten.

Generating the wonderful Mandelbrot set in Ruby and Haskell – it’s amazing how simple math can give birth to such a sophisticated shape. It’s elegance fits Ruby and Haskell well. Come closer and see the wonders!

I just came across one of my favourite books which I read when I was a kid: ‘The emperor’s new mind‘ by Roger Penrose. I remember I was very enthusiastic reading it and became amazed by fractals – especially the good old Mandelbrot set. I wasn’t really into programming back then – I was like 15, only starting out with *blush* Pascal, but now I’m equipped with two wonderful languages, so I decided to code my childhood dream.

Some very basic maths for the things to come:
The Mandelbrot set is a set of complex numbers for which the simple iterative polynomial z(0) = 0; z(n+1) = z(n)^2 + c remains bounded.
It’s the boundary of the set which is a fractal, an ever-zoomable, self-repeating source of wonders. The complex plane is a two dimensional plane on which the x-axis is the real part and the y-axis is the imaginary part of any complex number (at least let’s make this our convention), thus every complex number defines a point on this plane.

After some trial and error, the following area of the complex plane is best used for the well-known generic Mandelbrot fractal:
x: (-2.0) – 0.5
y: (-1.0) – 1.0

The algorithm is this: for every point (complex number) inside this area we check if the iterative polynomial remains bounded. Of course we can’t check up to infinity, so we need to define some maximum iteration limit, say 500 (for our console plotting, a much lower value would be good enough). If the magnitude of the 500th iteration of the polynomial is lower than 2.0 (a hand-picked but close-enough upper limit), then the given point is part of the Mandelbrot set.

Let’s code a quick console plotter in ruby:

require 'complex'

def mandelbrot(a)
  Array.new(500,a).inject(a) { |z,c| z*z + c }
end

(1.0).step(-1,-0.05) do |y|
  (-2.0).step(0.5,0.0315) do |x|
    print mandelbrot(Complex(x,y)).abs < 2 ? '*' : ' '
  end
  puts
end

Pretty straightforward, I think. All numbers are hard-coded for simplicity (iteration step size is calculated based on the x-y range and the number of characters in our terminal). One neat trick is the iteration itself: Enumerable#inject is used instead of classic looping. I just love ruby’s functional side. Array.new(500,a) generates an array by repeating ‘a’ 500 times. Inject is fold in a disguise, reducing the array to one element by the operations given in the block.

It produces the following cool little output:

Pretty nice for starters. Let’s see the Haskell version.

import Data.Complex

mandelbrot a = iterate (\z -> z^2 + a) a !! 500

main = mapM_ putStrLn [[if magnitude (mandelbrot (x :+ y)) < 2 then '*' else ' '
                           | x <- [-2, -1.9685 .. 0.5]]
                           | y <- [1, 0.95 .. -1]]

Some definitions here:

• ‘iterate’ by definition: iterate f x returns an infinite list of repeated applications of f to x: iterate f x == [x, f x, f (f x), ...]
  Quite clear, I think – just what we need.
• list !! n: take the nth item from the list
• mapM_ by definition: Evaluate each action in the sequence from left to right, and ignore the results. What it does is actually ‘executing’ the operations on its right without using their results – outputting the mandelbrot set itself.

I have one more thing up in my sleeve: a full-fledged ruby drawing version using RMagick, so here it is without comments, use it to your liking:

require 'rubygems'
require 'complex'
require 'RMagick'
include Magick

# this is the interesting area of the complex plane
X_START = -2.0
X_END = 0.5
Y_START = -1.0
Y_END = 1.0

# wanted image dimensions
WIDTH = 800.0
HEIGHT = 600.0

# set this to higher values and sleep well 
ITERATIONS = 200

STEP_X = (X_END - X_START) / WIDTH
STEP_Y = (Y_END - Y_START) / HEIGHT

def mandelbrot(a)
  Array.new(ITERATIONS, a).inject(a) { |z,c| z*z + c }
end

complex_plane = Image.new(WIDTH.to_i, HEIGHT.to_i)

MIN_X =
x_pixel = 0
y_pixel = 0 

x = X_START
y = Y_START

while y < Y_END
  x_pixel = 0
  x = X_START
  while x < X_END
    mandelbrot(Complex(x,y)).abs < 2 ? Draw.new.fill('#000000').point(x_pixel,y_pixel).draw(complex_plane) : nil
    x_pixel += 1
    x += STEP_X
  end
  y_pixel += 1
  y += STEP_Y
end

complex_plane.write("mandelbrot.png")

I hope you liked this quick and simple post I hacked this together in 30 minutes, so I know it’s not high quality code, but I did it for fun mostly.

Everyone wants to be good in what he’s doing – that’s human nature, that’s how we’re raised. The key is constant improvement without being disappointed by small failures and bumps on the way. In the last 10 years I’ve been working as a developer and I feel I’ve learnt a lot of valuable lessons – many of which can be applied to other areas of life and work. Let me share my lessons with you, dear reader.

Lesson #1 – See the big picture

It’s very easy to get lost in details, focus on small things and lose the vision. The whole is always more than the sum of its parts. Even if you’re only a rookie coder, try to look for other aspects of your projects – business, social, whatever those aspects might be. When you’re working as a professional, coding is not l’art pour l’art anymore – it has a reason and a goal. The goal is never ‘completing coding tasks’. It is the same thing as the concept of ‘done done’ in agile development – a project is only done when it is tested, accepted, goes live, tested in the wild again and regressions are fixed. The final test is rarely technical rather has more to do with management and concepts like profit, brand building and customer/user satisfaction. To be successful in this manner, you must always have the global vision of the project in sight.

Lesson #2 – Take your time

It might sound easy and natural, but it’s usually really hard when deadlines are closing in. Don’t go for speed, though, speed will give birth to lost focus and neglect – bugs. In the end it will cost you more time, energy and morale. Speed will naturally come with good design and architectural choices and solutions, plus with experience and proficiency. These things you cannot achieve while rushing. Note that it has nothing to do with being lazy or mooning around, those are bad habits.

Lesson #3 – When things go wrong, be ready for a paradigm shift

This also takes time and experience, but it’s an invaluable thing. When technologies and solutions become slow or unusable, you should stop trying to fit new problems into old schema – look for alternatives. The recent NoSQL ‘movement’ is such an example – but also, where a proven old solution is good, don’t go for the hype and use a trendy lib or software. If your good old relational DB scales well for your problem, there’s no reason to use a NoSQL server. The same goes for functional languages – just because you can have a more elegant solution, don’t introduce a new language into your codebase. If, on the other hand, your OO paradigm seems unnatural and ineffective for the problem, look for a functional solution. For this, stay up to date with new trends, read a few interesting articles about new technologies at least weekly. See my ‘Top 5 trends in sw tech‘ for example.

Lesson #4 – Keep your brain trained

Don’t settle with everyday tasks, do some extra training. Look for problems at sites like Code Golf or Project Euler and try as many solutions as you can think of and compare them. Also practice maths, especially set , graph and group theories, they can be real life savers when you come across some harder algorithmical problem. Being a developer does not stop when you leave your desk in the afternoon – it’s a lifestyle. Also, good ideas usually come when you’re not working, so:

Lesson #5 – Have/get a life

This is probably the most important one. Young geeks may seem like programming gods, but that fire can burn out fast. Without proper rest and motivation you won’t last long in this business. Minimize overtime working by doing your job well and having a decent relation with project managers, thus encouraging proper planning. Sleep, sleep, sleep. Staying up one or two nights can be inevitable sometimes, but watch out because this can easily harden into a pattern – and your brain needs sleep. You won’t get far with sleep deprivation. Also be social, have a family, friends and have as much fun as possible, your brain also needs diverse activities.

Lesson #6 – Focus

Focus on one thing at a time (without losing the big picture). Avoid multitasking (and thus interruption) as much as you can. Sometimes it’s just not possible in your office environment, but multitasking in your brain has the same price tag as in parallel programming: task switching is a tedious work for our brain too. You lose focus and subtle ideas and need much time getting back on track.

Lesson #7 – Be persistent

Don’t give up at the first failure. Or at the second. Try again. You can learn the most from your mistakes, not from your success stories. If all else fails, try to find a way around the problem (this is related to Lesson #3). In most of the cases you will find the right solution with time, trust me. Don’t be afraid or shy to ask for help – a fresh look at the problem might do miracles!

Lesson #8 – Measure

Always measure whatever you can. Don’t just ‘think’ your solution will be good enough. Don’t assume, see for yourself. Will that new color scheme attract more users to the sign-up form? Do some A/B testing and you’ll see. Human judgement and forecast is faulty. You’ll be surprised how far your estimate is from reality sometimes!

Lesson #9 – Don’t focus on code performance

Most of the times it’s irrelevant. Don’t spend two more days optimizing that page so it loads in 500ms instead of 550ms. It’s not worth it. Your users won’t see the difference and you’ve lost valuable time, you should have been working on your next task. There are other factors which are usually much more important – clarity, simplicity, elegance, for example.

Lesson #10 – Be ready to chop off features

Sometimes you just can’t complete the task in time. Be ready to make some sacrifices, reorder your list of to-do features by importance and just chop off the least important ones if you can. Later you can schedule an ‘after-party’ and complete those nitty-gritty featurettes. Don’t consider this as failing. It’s how our job is.

Lesson #11 – Have ‘coding standards’

Even if you’re not on a team – be consistent with yourself. That list of standards can and will evolve, of course, but always try to be consistent. It will save much time for you and your team .

Lesson #12 – Test

Consider testing as part of the job and plan, not some tedious extra work. Dedicate time for proper testing. Test on multiple levels. Test code consistency but more importantly do functional testing. Test with many people. Have a testing toolset at hand – a testing/staging server, software tools (RSpec, Cucumber, PhpUnit, etc.).

Lesson #13 – Usability

When doing UI development, keep usability principles at the top of your importance list. It’s hard, we all have our concepts but accept that a developer will never be able to see the UI as a normal user. It’s a fact. Do mockups, design plans, show them to many people – especially your future users if possible. Embrace criticism, it’s part of the process and it’s not personal insult.

Today I’d like to present the implementation of the quicksort algorithm, starting from a naive imperative solution and improving it for elegance and clarity.

Why quicksort? Well, it’s a quite good sorting algorithm which can be effectively implemented on modern architectures and also very easy to understand, making it a nice test subject. To learn about the algorithm itself, look here. The short description of the algorithm goes like this:

1. Pick an element, called a pivot, from the list.
2. Reorder the list so that all elements which are less than the pivot come before the pivot and so that all elements greater than the pivot come after it (equal values can go either way). After this partitioning, the pivot is in its final position. This is called the partition operation.
3. Recursively sort the sub-list of lesser elements and the sub-list of greater elements.

Based on this description, here we go with a straight-forward naive implementation in ruby:

def partition(items, left, right, pindex)
   pvalue = items [pindex]
   swap(items, pindex, right)
   sindex = left
   for i in left .. right-1
       if items[i] <= pvalue
          swap(items, sindex, i)
          sindex = sindex + 1
       end
   end
 
   swap(items, right, sindex)
   return sindex
end
 
def swap (arr, l, r)
  tmp = arr [l]
  arr[l] = arr[r]
  arr[r] = tmp
end
 
def qsort(items, left, right)
	if (right > left)
	    pIndex = left
	    newPindex = partition(items, left, right, pIndex)
	    qsort(items, left, newPindex-1)
	    qsort(items, newPindex+1, right)
	end
 
end
 
def quicksort(items) 
  qsort(items, 0, items.size - 1)
end

Well, not particularly nice. Isn’t ruby supposed to be a terse language? Wait and see. First what bothers me the most is the ‘swap’ function there. There’s no need for that, in ruby you can use parallel assignment, so :

   items[sindex], items[right] = items[right], items[sindex]
   #swap(items, right, sindex)

Also, do we really need that ‘partition’ function? Nope. Ruby’s Enumerable module has it already. It says:

^?View Code RUBY

enum.partition {| obj | block } => [ true_array, false_array ]

Returns two arrays, the first containing the elements of enum for which the block evaluates to true, the second containing the rest.

Nice. Let’s write an alternative version using this knowledge:

def quicksort2(items)
   return items if items.nil? or items.length <= 1
   less, more = items[1..-1].partition { |i| i < items[0] }
   quicksort(less) + [items[0]] + quicksort(more)
end

So much nicer! Another alternative could be this, using Enumerable#select:

def quicksort(items)
  if not items or items == [] then 
    []
  else
    x, *xs = items
    quicksort(xs.select { |i| i <  x }) + [x] + quicksort(xs.select { |i| i >= x })
  end
end

Notice the line ‘x, *xs = items’ – it’s just like head and tail in functional languages! Beautiful. It works like this:

irb(main):007:0> a = ['first','second','third','fourth']
=> ["first", "second", "third", "fourth"]
irb(main):008:0> x, *xs = a
=> ["first", "second", "third", "fourth"]
irb(main):009:0> x
=> "first"
irb(main):010:0> xs
=> ["second", "third", "fourth"]

For a comparison, here is my Haskell version:

quicksort :: (Ord a) => [a] -> [a]    
quicksort [] = []    
quicksort (x:xs) = quicksort (filter (< x) xs) ++ [x] ++ quicksort (filter (>= x) xs)

Almost the same, right? The difference again is that the Ruby version says how to do the sort while the Haskell version is describing the algorithm, the method itself, it’s closer to saying what quicksort is. It has no ‘do it next’ and ‘return this’.

What is the first term in the Fibonacci sequence to contain 1000 digits?

This is the quesion I’m answering, comparing the Ruby and the Haskell solutions.

Let’s see the ruby version first, with an imperative approach.

require 'matrix'
 
limit = 10**999
FIBONACCI_MATRIX = Matrix[[1,1],[1,0]]
def fibonacci(n)
  (FIBONACCI_MATRIX**(n-1)) [0,0]
end
i = 1
i+=1 while fibonacci(i) < limit
puts i

Here I am using the fast matrix-based fibonacci calculation method, see the Wikipedia entry – no, memoization is not faster in this case, I’ve tried it.
The code is pretty straight-forward, first I define the limit and initial 2×2 matrix used for the calculation, then I define the fibonacci calculation function. Probably it would be much faster using the native NArray package for matrix calculation.
The runtime on my macbook pro has an average of 3.5 seconds.

And now for the Haskell solution:

limit = 10^999
fibonacci_numbers = 0:1:(zipWith (+) 
                        fibonacci_numbers (tail fibonacci_numbers))
 
index = length w where w = takeWhile (< limit) fibonacci_numbers
 
main = do
  putStrLn(show(index))

This probably requires a bit more explanation. I think the variable ‘limit’ is clear, let’s look at the definition of the fibonacci_numbers function. This resolves to a list and is quite simple and logical when we give a bit of thought to it.
First, define a few things.

• ‘:‘ – this is the list concat/construct operator, it concatenates the item(s) on its right to the item(s) on its left
• ‘zipWith‘ – this is a list function, by definition “makes a list, its elements are calculated from the function and the elements of input lists occuring at the same position in both lists”
• ‘(+)‘ – this is the addition operator as a function.

What is the Fibonacci sequence? A list of numbers, starting with 0,1 where every other element is the sum of the previous two elements.
So, how is this fibonacci_numbers list being built? It has a recursive definition: start with 0 and 1, then calculate all further items by adding the previous two (zipWith (+) does exactly this). We are using this approach because of it’s witty speed – it doesn’t recalculate previous elements. One other thing about this construct: it’s called a lazy list. It’s lazy because the elements aren’t computed until they’re accessed. Also, this is an infinite list. If we tried printing it, it’d go ‘forever’ (until it has no more free RAM).

takeWhile behaves as it name suggests: it takes more and more elements from a list while its function predicate evaluates to true – we are scanning a list until we find an item which is not less than the limit specified.

Apart from its speed (an average of 0.008 seconds on my macbook pro) this solution has elegance and is much closer to the original (mathematic) definition of the Fibonacci sequence. Notice the biggest and most important difference between the approaches:
The Ruby implementation tells how to calculate the nth item of the Fibonacci sequence, the Haskell version defines what the Fibonacci sequence is.

If you liked it, take a look at my older post about solving project Euler problem #1 in erlang here

Stay tuned for more Project Euler solutions in haskell and ruby!

UPDATE

Code after applying HLint (thank you, Neil Mitchell!) suggestions:

limit = 10^999
fibonacciNumbers = 0:1:zipWith (+) fibonacciNumbers (tail fibonacciNumbers)
 
index = length w where w = takeWhile (< limit) fibonacciNumbers
 
main = print index

Much nicer!

* Top 5 trends and technologies in software development

In this ever-changing world of software development it’s extremely important to keep up with current technologies, methodologies and trends.

* Top 5 mac tools for web development

See my recommendations for web development tools on macs

* Ruby blocks and closures 101

Let’s go on with diving into the beauties of ruby – this time check out how elegant blocks and closures and their first-class support in ruby can make our codes.

* Ruby class system introduction and teaser

This is part one of a forthcoming series about ruby – and why I love it. This first episode focuses on general ideas, concepts and philosophy about ruby and a gentle introduction to its class system.

* Of PHP, Facebook’s HipHop and C++

My thoughts on Facebook’s new PHP to C++ translator