Should we use Frameworks?

Over the past month there have been a number of security issues with the Ruby on Rails framework. These issues have been serious. Whilst there is some debate whether this is an isolated Rails issue or if we can expect more frameworks to start seeing these sorts of vulnerabilities discovered this has left me with a niggling question at the back of my mind.

Should we use frameworks?

Rails is a massive monolithic framework, but (security issues aside) do the benefits of using it outweigh the benefits of not using it? This goes for any framework, in any language. Are we ultimately better developers for using frameworks, or for not using frameworks?

To answer these questions, I have drawn up a (completely non extensive and totally subjective) list of pros and cons.

The main benefit of using frameworks is the lack of having to constantly reinvent the wheel. Every time you start a new project, is it easier to use a framework that comes with ready-made modules for accessing the database, session management, caching etc, or is it easier writing all this stuff from scratch?

The answer simply must be the former. The reason for this is two fold:

Firstly, the time you save not having to reinvent the wheel you can put to actually developing your application. In this respect it will greatly speed up development time.

Secondly, as these utility modules (for want of a better term) are within a framework, you can be sure that the code has had more people looking over it than if you wrote it yourself.

This leads on to my next point. As Eric Raymond dubbed “Linus’s Law”: “given enough eyeballs, all bugs are shallow“. With a popular framework that has a vibrant and engaged community you should be relatively confident that the code has been reviewed a number of times by a number of different authors. Or at least, you should be relative confident.

But what of the vulnerabilities found in Rails? These issues had been lying there for some time. They had certainly been there long enough for the issues to be reported multiple times, but no action was taken. Again, I’m not trying to single out Rails here, but it is the highest profile framework at the moment.

However, there is nothing stopping you from auditing the code on your favourite open source framework and contributing back to the community. In my opinion this is another benefit of using a framework – the community. If you engage with the community, follow the mailing lists, chat in IRC then you can really improve your usage and productivity with the framework, again helping you develop better applications.

But what about the disadvantages of using frameworks?

Firstly it is yet another thing to learn. If you are just starting out with a framework you have to learn it. You must learn it’s foibles and nuances. This takes time, slowing you down. Granted, once you have learned the framework your development time is quicker than without a framework as discussed, but to start off with, development is slower.

As well as learning a frameworks foibles and nuances you must also learn its limitations. There are just some things that some framework will either not let you do, or are harder to do than if you write the code raw. When developing with a framework this is something that must be taken into account.

Ironically, whilst frameworks contain limitations, a lot of them are also bloated. Zend for PHP springs to mind as in fact does Rails. When using frameworks such as these your application is not as optimal as it can be because it is carrying around the huge and for you possibly mostly unneeded weight of the framework.

However, in my mind the biggest disadvantage is the “black box” scenario. People just blindly using the frameworks without delving deep into the code that the framework is made from. There is an element of faith here. Faith that the code is sound and secure. Faith that the code in the framework and the development of that code has been treated seriously, professionally and with respect. This is especially true with Rails, in part due to it’s “cool” tag a lot of newbie programmers are using it. There is nothing wrong with this, Ruby and Rails are great places to start the journey of coding. But if you are just starting out you cannot possibly know of all the implications of taking a codebase on faith.

In this case the users of Rails were badly let down.

So what is the conclusion? Should we use frameworks?

Overall, I think yes. A framework should be used. But what type of framework? that is the more important question.

The framework you use should be small, small enough so you can truly get to understand it. Small enough to only contain the elements that you really need. However, it should have a vibrant and responsive community. Now I don’t mind if the framework you use is an existing one or it is a framework you have developed for yourself. But if you have lovingly hand-crafted your own framework you should open source it. It is imperative that the framework you use must have a community. A community to find and fix bugs, to keep the code clean and optimised. To document and battle-harden.

You must either find a framework that is small and has a great community, or build the framework you need with a community to match.

Sonar GNU/Linux on Indiegogo

In my random trawling through the internet I can across a very worthwhile Indiegogo campaign. It is raising money to help develop the Sonar Project, a GNU/Linux system focusing on accessibility.

This is the thing I particularly love about Linux, and the free software movement in general: the fact that you can take a product and improve it in the way that best suits you. This is a commendable effort for bringing Linux and computing to those with disabilities and should be supported.

Go and support Sonar now.

How to Improve your Programming Skills

As the subtitle of this blog indicates, I am a self taught programmer.

Like most self taught coders, I suffer from the horrible feeling that I am missing something in my programming education. As such I am continually striving for improvement. But how do you achieve improvement? Where do you start? What do you do? Is there any set methodology?

Searching the internet looking for direction yields a bunch of different advice, but it is mostly really common sense: write more code; read more code; learn a new language; do coding exercises; etc.

This is obviously all good advice, but it misses the heart of the problem: focus.

It is all well and good learning a new language, just as it is well and good completing some exercises, but this is ultimately busy work if you don’t know what particular aspects of your coding you want to improve.

Improving your ability to code complex algorithms is very different to improving your ability to code complex front-end user interfaces.

If you are aiming to improve the former, then no amount of learning the latter will help.

Programming is now a vast field, and it is only once you have decided what aspects of programming it is that you want to improve, where to apply your focus, can you truly start to improve.

So, what areas of your coding skills do you want to improve? Define that, then answering the question of how to improve becomes much clearer.

Coursera Programming Languages

Upon discovering Coursera last year I went a little bit mad and all of a sudden find myself enrolled in 8 classes beginning over the next two weeks. Obviously this is far too much, so I’ll have to cut back, but the thing I like about Coursera is that you can give all the classes a go, and then stick with the best ones.

There is one starting next week that I am particularly excited about: the University of Washington’s Programming Languages course, by Dan Grossman. I’ve watched the introductory videos and it looks pretty good. It is exploring concepts that I haven’t been formally taught, and promises that it will make me a better programmer. As a self-taught coder who is constantly looking to improve this sounds like just my cup-of-tea, If you are in the same boat, I strongly urge you to enroll as well.

Christmas Books

Father Christmas has been good to me this year as I received number of fantastic books to start making my way through next year. Here’s a quick run-down:

  • Enterprise Integration Patterns - Ignore the fact that the title includes the word “Enterprise”, this is a great book about asynchronous messaging for large distributed systems.
  • Hacker’s Delight – wow! At first glance this looks pretty hard-core. Loads of nifty little hacks, bit flipping techniques and all that malarkey. Way out of my league, but the only way to improve is by pushing yourself!
  • The Annotated Turing – again, another book that is way out of my league, however, it is fascinating and very well written. I am looking forward to working my way through this book, however, I think I’ll be making lots of trips to the Khan Academy to brush up on my maths skills.
  • The Inner Game of Tennis – A slightly different book to the others, but one I found through a link on Hacker News. So far, looking good.
  • Weinberg on Writing – I need to improve my writing skills so I added this to my wish list. Read a few chapters of it so far and pretty impressed. From what I can gather (and I’m only on page 32) the general thesis is to have plenty of projects on the go at once – which is something I like the sound of!

The Lovely Little Schemer

Although only half way through a curious little book, I have fallen in love.

The Little Schemer by Daniel P. Friedman is a quirky little book with a quixotic appeal. Admittedly it took some time to get into, but now I can safely say that it is bordering on the magical. It is one of the very few coding books (if not in fact the only coding book) I’ve read that genuinely makes me want to relax into a comfy seat, glass of wine at the ready, Nina Simone playing in the background and settle down to a good read.

Since working in Emacs every day I have been meaning to get around to learning Lisp and this gorgeous little tome has always been one of the top recommendations for not necessarily learning Lisp (in the form of Scheme) but learning how to think in Lisp. Well, if The Little Schemer is any indication of what thinking in Lisp is like, please count me in!

It is so very different to other coding books I have read before, with its strange conversation style, questions and answers, I can’t understand why it hasn’t been more of an influence to other authors. One of the particularly interesting aspects about it is that you are continually building on what has come before, and quite literally. You cannot advance through the book without constructing the functions required to progress. This forces you to step back and actually use your brain instead of passively consuming. This is what programming is all about, this is why we do it.

Although only half way through this curious little book, I have fallen in love.

Disclaimer: I have used Amazon Affiliate links in this post. The affiliate links help me fund this blog. However, if you prefer not to use an affiliate link, feel free to use the affiliate-free links.
Affiliate Links: Amazon US, Amazon UK
Affiliate Free Links: Amazon US, Amazon UK

Lua Documentation

I’ve been playing around with different methods for Lua documentation today. Took me a bit of time to get into the lua method of doing stuff, and I still haven’t quite worked out LuaRocks yet (nothing seems to install). However, using a combination of apt-get, LuaRocks and a bit of manual “Gittery” I managed to get both LuaDoc and LDoc installed.

After some tweaking, and rewriting of the inline docs to suit conventions, I think I prefer LDoc. Out the box it seems much more clean and I really like that fact that Markdown was so easy to set up.

Below you can see examples of the two different outputs from LuaDoc and LDoc respectively.

 

Example of Lua documentation using LuaDoc

Example of Lua documentation using LDoc

Set yourself a BHAG

Today, a story has appeared on HN which has divided opinion. Gusts Kaksis wrote a blog post with the bold statement that he is going to write his own OS. A lot of people are shaking their heads in disbelief, that this mere web developer could attempt such a thing! Does he know what he is getting himself into? Can he not see just how absurdly ambitions this project is for a PHP and JavaScript developer?

My message to Gusts is sod them.

So what if this is a hugely ambition project. So what if he is being naive about the task ahead of him. So what if it he may never get there. So what.

Gusts has set himself a target. That target may be way out of reach and he will never make it. But at least he has one. And I bet that even if he doesn’t reach it, I bet you that he is going to learn a hell of a lot along the way, which in turn will make him a better programmer .

Good for him, and good luck Gusts.

Node with Lua bindings? Luvit!

I have recently discovered the excellent “The Changelog” Podcast and a couple of weeks ago there was an interview with Tim Caswell that most people probably know from NodeJS fame. However, on this interview he wasn’t talking about NodeJS, instead about his new project Luvit – Lua + libUV + jIT (GitHub project page).

Having played around a tiny bit with Lua, I decided to give Luvit a go. As with my previous foray into Lua, it was great fun.

Installation of Luvit was straightforward on my Linux box and within a few minutes I was ready to go.

As Luvit is pretty new, there isn’t a great deal of documentation beyond a simple “Hello World” app, but “Hello World” apps aren’t enough to really get your teeth into. The only idea my ever- degenerating brain could come up with at such short notice was a simple bookmark saver, so apologies for the lack of imagination.

local http = require("http")
local url = require("url")
local string  = require("string")
 
function split(str, sep)
   local sep, fields = sep or ":", {}
   local pattern = string.format("([^%s%%s]+)", sep)
   string.gsub(str, pattern, function(c) fields[#fields+1] = c end)
   return fields
end
 
http.createServer(
   function (req, res)
      local entry, tags, body = {}, {}, ""
 
      -- get and parse the query string
      local parse_url = url.parse(req["url"], true)
      local query = parse_url.query
 
      -- if a url has been supplied, save it and any associated tags
      if query['u'] then
	 if query["t"] then
	    tags = split(query["t"], ",")
	 end
	 entry["url"] = query["u"]
	 entry["tags"] = tags
 
	 -- output to console
	 print "-= Saving =-"
	 print("url: ",entry.url)
	 for i,v in pairs(entry.tags) do print("tag: ",v) end
 
	 -- body of the returned output
	 body = "URL: "..query["u"].." saved."
      else
	 body = "To bookmark a URL simply pass u and t in the query string"
      end
 
      res:writeHead(200, {
		       ["Content-Type"] = "text/plain",
		       ["Content-Length"] = #body
		    })
      res:finish(body)
   end):listen(8080)
 
print("Server listening at http://localhost:8080/")

The above doesn’t do much apart from store a passed URL and it’s tags into a Lua Table.

For example:

URL: http://localhost:8080/
Response: To bookmark a URL simply pass u and t in the query string
Action: Does nothing.

URL: http://localhost:8080/?u=http://www.robsearles.com&t=test,blog
Response: URL: http://www.robsearles.com saved.
Action: Saves a table called entry

{
url: http://www.robsearles.com,
entry: { test, blog }
}

Whilst the code above is very simple, it did allow me to get more of a feel for both the language and the framework (if that is the right word) rather than mindlessly copying and pasting.

The only thing that threw me was that Lua doesn’t have a native split string function, unlike PHP, Python, Ruby etc, instead you have to roll your own as described in this wiki page.

In conclusion, yet again I really enjoyed delving into Lua – it really is something I would like to play around with more. Luvit looks like a great project, especially as Tim was saying on the podcast that it is benchmarking faster and has a lower memory footprint than NodeJS.

Luvit is definitely something to keep an eye on.

EmacsWiki vs WikEmacs

Lot of fun stuff going on with the Emacs Wiki.

Last week, Bozhidar Batsov wrote a controvertial post called Die EmacsWiki Die. Which made me think somewhat of Sideshow Bob, (especially as I’m in Germany and sometimes I get some Deutsch posts coming up on my reader). This sparked a flurry of debate, on HackerNews and Reddit as well as a response from Alex Schroeder , the creator and maintainer of EmacsWiki.

The result of all of this is a new Wiki: WikEmacs has now been set up by Bozhidar.

I’m not sure I agree with this. Yes the current wiki is a bit of a mess. Yes there are some outdated bits of information there, and some of it is incoherent. Yes it could be structured better, or use Markdown to help with the formatting.  But I can’t help but thinking it would be a huge mistake to disregard what it is, wipe the slate clean and start again. It reminds me of a Joel Spolsky article about “Things you should never do“. Whilst that article was obviously talking about software I feel that the same does apply to content.

Whilst a new wiki will start out with the best intentions, and to start off with it will be nice and clean and well structured etc, this is the same as most software projects. However, as we all know, as the project goes on, the code (or content) becomes legacy things can start to slip. Stuff is moved around, and new stuff added, and eventually the base is so large it becomes hard to navigate. Fast forward and you have a large unwieldy repository that someone new comes along, sees a huge mess so decides to start again from scratch.

Nope, in my mind the best thing to do is to refactor what is already there. And that’s exactly what I intend to help with.