screaming at my screen http://screamingatmyscreen.com/ updates for screaming at my screen - the private domain of Timo Zimmermann en-en Timo Zimmermann Sun, 31 Aug 2014 21:32:31 +0200 Django & Rails - another year another comparison http://screamingatmyscreen.com/2014/8/django-rails-another-year-another-comparison/ http://screamingatmyscreen.com/2014/8/django-rails-another-year-another-comparison/ It is the time of the year where I start talking about Django and Ruby on Rails. Since my last two posts I received many questions about this topic and the old posts are still read frequently and quoted. So let me bring you up to date what changed, what improved since the last post and which framework is the best choice. Sun, 31 Aug 2014 21:15:00 +0200 It is the time of the year where I start talking about Django and Ruby on Rails. Since my last two posts I received many questions about this topic and the old posts are still read frequently and quoted. So let me bring you up to date what changed, what improved since the last post and which framework is the best choice.

If you did not read my last two posts about this topic I suggest you read them now. I will make claims and statements in this post I already elaborated in them and without the context they can be quite controversial. To the disappointment of some of you: this is still not Django vs Rails - it is no discussion that will come to the conclusion that there is a holy grail of frameworks, totally destroying one of them with arguments why the other one is so superior.

While Django is slowly moving towards migrations being part of the core functionality Ruby on Rails just added support for real foreign keys support. Django 1.7, which will bring you the joy of migrations, is currently not marked as stable, but release candidate two makes a good impression and it should not take long till you can start new projects with it. I am even aware of people already using it in production and they seem to be quite happy.

There are new benchmarks provided by TechEmpowered but there are no real surprises nor did anything dramatically change. But since you do not choose Django or Rails for performance reasons you should not give too much about benchmarks anyway.

More and more features!

It slowly feels like comparing Django and Rails is getting harder and harder. Rails 4.2 beta 1 was just announced. Let us just look at one feature: Active Job. For those of you who do not use Rails - it is an abstraction layer for task queues and is compatible to the most popular ones. And you can just start with the inline runner and move to more advanced queuing systems. More concrete: If you want to send a mail in two hours you just do Notifier.welcome(User.first).deliver_later(in: 2.hour).

Rails is getting more and more features and moving more and more towards a "you get everything you need and build from there" framework while Django is still keeping everything the same and only doing small, incremental improvements - at least most of the time, migrations is an obvious counter example.

Paying the price

With Rails you pay the price for always getting new features. Things are constantly changing. Upgrading projects between releases is more work compared to Django. I still have Django projects that, accumulated, needed not more than an hour or two and have been running with 5 releases now. Upgrading Rails projects is always a bit more troublesome. But in defense it got a lot better than it was some years ago.

Language improvements

I pity everyone starting a project and having to choose a Python version. The arguments between the Python 2 and Python 3 fractions are still the same, the problems are not getting any better, libraries are still not all ported. Starting with Python 3 can become problematic if you need many third party libraries, starting with Python 2 could mean that you will be porting your project pretty soon.

Looking at the Ruby community it is a bit different. People are discussing advantages and problems of Ruby 2. But they are slowly and steadily moving towards it, Rails 5 will likely target Ruby 2.2. And this is understandable. The language is getting better, sane features are added and not everything blows up once you try to port something. Even if there are discussions the biggest part of the Ruby community seems to be in the same boat that migrating to Ruby 2 is a good idea - or I miss the parts that are die hard Ruby 1 fans revolting against 2. I will not rule out that possibility.

I still cannot stand Ruby but I have to admit I am also not a big fan of Python 3. If I had to choose today I would still go with Python 2 and keeping Python 3 compatibility in mind, but Ruby is getting better and better and more attractive.

One year later

I am keeping this post shorter than the other two for two reasons. First of all not many things really changed. Second, Django 1.7 is not released yet, Rails 4.2 is not released, Rails 5 will likely see a lot more awesome things than Ruby 2.2 support and is planned around spring or summer 2015. With this in mind it feels like next year will be a good time to take a fresh look at both of those frameworks and go back to the already discussed points.

From my todays perspective I would still stick to the arguments why you should choose one over another as last year and the year before. But I would likely add one additional thing to it: If you are trying to build a throw-away MVP to prove an idea or just get something out Rails could be the better choice. You have it easier to build an API. You get a better asset pipeline, and have it a bit easier to use a frontend JS framework. And now with Active Job Rails just ships another feature you will need at some point and, as starting point, is awesome to have as part of the framework instead of having to evaluate all the different options. Of course, this only applies if you can stand writing Ruby.

You can discuss this post on HackerNews.

]]>
Review: Django Essentials http://screamingatmyscreen.com/2014/8/review-django-essentials/ http://screamingatmyscreen.com/2014/8/review-django-essentials/ A month ago Dyson D'Souza from PacktPub approached me asking if I would be interested in reviewing Django Essentials. I am using Django for some time now - somewhen pre 0.96, I remember the 0.96 release for some reason, I think it was the length of the release cycle but I am not sure anymore - and I really wanted to see how the introduction resources changed, so this was a good chance. Wed, 13 Aug 2014 15:45:00 +0200 A month ago Dyson D'Souza from PacktPub approached me asking if I would be interested in reviewing Django Essentials. I am using Django for some time now - somewhen pre 0.96, I remember the 0.96 release for some reason, I think it was the length of the release cycle but I am not sure anymore - and I really wanted to see how the introduction resources changed, so this was a good chance.

Samuel Dauzon does a really good job writing for people who are just starting to work with Django. Beside some history he manages to explain all important concepts and, this is something I especially like, transports them to the terminology used by Django. After explaining what MVC is he also explains what Django is calling the different parts and how they fit together. This is something I often missed when reading a blog post or skimming through another book.

While it is a good introduction you should already now a little bit of Python to feel comfortable. The book is suggesting Python 3 which is in my opinion still a risky route to take for a beginner. While most libraries are ported you can still easily run into something that will just not work. Knowing some Python and HTML is especially important since there are several errors in the code examples, like missing bracers or typos, so you should be able to see and correct those.

Some best practices are explained, which is nice. It teaches you how to use South for example and discusses the pros and cons of class based views (CBV) and function based views (FBV). While South is something I consider a must have CBVs are still a topic that is hotly discussed and where lovers and haters will likely never agree. Showing the advantages and problems in an objective way is the best way to help someone understand the situation - it will not replace the experience getting burned by CBVs or at some point noticing that a CBV would have made a lot more sense than a FBV, but no explanation, no matter how good, can do this.

Samuel is teaching some things in this book that make a lot of sense when working on bigger projects, like separating the views in multiple files instead of throwing everything in a views.py.

On the other hand there are also parts that are just bad. Creating a simple user model and storing passwords plain text before moving to django.contrib.auth is just wrong and the fact that it was shown will likely, at some point, cause someone who read it to do it and ship it to production. While it is great to show how much Django can help you with basic tasks there are things that should in my opinion never be taught or shown the wrong way. Authentication and authorization are on the top of the list.

The deployment section is a nice introduction to the most important concepts, but I consider Michael Hartls approach for Learn Rails by Example as superior. Just use Heroku. It is free. It provides everything you need and it gets out of your way so you can see results immediately. Just throwing some components on a virtual server can work, too, but it takes more time and brings you no advantage when trying to get your application into production.

Especially useful is the cheat sheet at the end of the book giving a quick overview over the different field types, common options, filters, and everything else you need to build your first application. Overall the book is making a good impression as learning material and getting a rough idea what Django is capable of and what can be done with it.

]]>
Drupan 2.0 - RAWR released http://screamingatmyscreen.com/2014/8/drupan-2-0-rawr-released/ http://screamingatmyscreen.com/2014/8/drupan-2-0-rawr-released/ It is done. Drupan 2.0 is officially released. You can find it on pypi and GitHub. If you read my last post about drupan you already know all the news. If you are migrating from an 1.x installation please read the migration guide - some things changed. For a new site you can use --init - the repository it tells you to download ships with the theme of this blog. As always: Have fun :) Sun, 10 Aug 2014 21:01:00 +0200 It is done. Drupan 2.0 is officially released. You can find it on pypi and GitHub. If you read my last post about drupan you already know all the news. If you are migrating from an 1.x installation please read the migration guide - some things changed. For a new site you can use --init - the repository it tells you to download ships with the theme of this blog. As always: Have fun :)

]]>
Sometimes I just want dumb things - or: Why adding features is not always a good idea http://screamingatmyscreen.com/2014/7/sometimes-i-just-want-dumb-things-or-why-adding-features-is-not-always-a-good-idea/ http://screamingatmyscreen.com/2014/7/sometimes-i-just-want-dumb-things-or-why-adding-features-is-not-always-a-good-idea/ I do not want a TV with a network interface. I do not want a DVD player with social media integration. I do not want an amplifier that supports AirPlay. I just want something that does its job. And does it right. Let me explain on the example of a DVD player why features can be harmful and are not always a good idea. Thu, 31 Jul 2014 21:52:00 +0200 I do not want a TV with a network interface. I do not want a DVD player with social media integration. I do not want an amplifier that supports AirPlay. I just want something that does its job. And does it right. Let me explain on the example of a DVD player why features can be harmful and are not always a good idea.

It is getting insanely hard to get dumb things - especially if you expect them to do their job.

Try to buy a TV that is just a big screen. No social media integration, not network connection, nothing. Some input ports. Displaying something from whatever you connect to them. Nothing else.

Try to buy a BluRay player that is just playing those little discs. My significant other still likes ancient technology - remember what those things are supposed to do? Play the content on the disc you put in. Nothing else.

But what do you get when you buy this stuff today? Most TVs start to offer 3D. Of course, you do not have to use it. You do not have to wear those silly glasses and hope that you have never $amountOfGlasses + 1 persons in your living room who want to watch a movie on your awesome 3D screen. You also do not have to connect it to the Internet. Remember when people complained that their TV was sending information to the manufacturer? I am still not sure if they ever thought about why a stupid display, displaying things (likely) over an HDMI cable needs a network connection.

But this is something I do not care that much about. Of course, I pay for features I do not want and do not want to use. That is just how it is. New features are developed, companies need to release something new and shiny so people buy more or newer stuff and they need to try to offer something different, something competitors do not have.

This is fine, but there was the point when it was too much for me.

As I already mentioned my significant other still likes DVDs. As a present I bought her a BluRay player. She already owned some BluRays but no player so far. I did some research and decided to get a Samsung. Reviews suggested it is playing everything you want and is not too loud. When we set it up I noticed that it supports YouTube, Twitter and other services. I did not really care. There is no network connection and as long as it plays the disc we insert everything is fine.

While watching a movie we wanted to pause for a short moment, hit the wrong key and a Twitter popup appeared. Here is the cool thing: the whole DVD player crashed. The UI did not respond anymore. You could do nothing put pull the power cord. Great, isn't it? But you know what was not so easy compared to crashing it? Getting it to continue playing the scene where we stopped watching.

More and more features are put in devices who have absolutely no benefit of having them. Can I sync my DVD with a friends one so we can watch the movie parallel if we cannot meet for a movie night? No. But can I tweet about it while watching it? Well, maybe, if the player does not crash.

If someone does not already own a device to tweet, how likely it is that a DVD player will make him or her a user or cause more tweets? Short answer: No likeliness given. My parents will never start using Twitter just because they buy a DVD who has a Twitter client integrated. We will never use the DVD player to tweet - there are smartphones, tablets and laptops doing this a lot better, the whole day, not just when watching a DVD.

There are times when I want intelligent, smart, or feature-rich stuff. I like my phone being able to send and receive mails, let me interact with Twitter, watch a short clip on YouTube, read a webpage, check my blog statistics and whatever. But I like it to be able to do this because most of the time when using it I have no other option available. If I only would sit at home I would not own a smartphone.

The sad thing is: everything is getting smarter. But this does not mean the quality of the software running on it is getting better - it just introduces more problems you have to live with. Software is not and will never be perfect, adding more and more features does not result in better and more stable software. I see the reasons why stuff is getting smarter and I am fully aware that I will be forced to buy something smart if anything I currently own breaks, but if I had the choice I'd still buy something dump again. It is just more likely to suck less.

What we should remember

And this is where I just want to add a little reminder: Whenever you start working on a feature for a project you should make sure that

  1. there is a likelihood of people using it
  2. it does not break things
  3. it makes sense to be included in the product

I know this is something we all read every other day, especially as loyal HackerNews reader for example. Define your product, look at user behavior, etc - but please remind me why I have a feed reader that lets me post a link to 20 different social media sites, to productivity tools and whatever but I cannot tell it to cache the images from web comic feeds for offline reading.

I believe everyone is aware of the three points I mentioned above, it looks like too many people just forget about them when they try to add new, cool features that will make them stand out. You know what really makes you stand out? Quality and Usability - something you do not find very often today.

]]>
State of drupan 2 - RAWR http://screamingatmyscreen.com/2014/7/state-of-drupan-2-rawr/ http://screamingatmyscreen.com/2014/7/state-of-drupan-2-rawr/ There went quite some development time in drupan and a release is in sight. The most common question I receive about drupan is what features will make it into 2.0 - codename RAWR. Let me give you a rough idea what is done and what will be done. Thu, 03 Jul 2014 22:24:00 +0200 There went quite some development time in drupan and a release is in sight. The most common question I receive about drupan is what features will make it into 2.0 - codename RAWR. Let me give you a rough idea what is done and what will be done.

From a first look RAWR will not be very spectacular. It is mostly a refactoring, rewrite and improvement of what I learned from using 1.x in production for 2 1/2 years and listening to people who decided to use it privately or for commercial projects.

The code became a bit more opinionated but more flexible for plugins. The opinionated part went into which steps are executed in which order and which part of the system is in charge of which task. This was not very clear in 1.x. Also there is now only support for jinja - I am not aware of anyone using anything else.

The flexible part is something you will notice if you write a plugin or create a new template. You can now query the storage object for specific entities which allows you to use drupan to split a large single page application into small, maintainable parts or create a site that is not a blog more easily.

The other new feature I am particularly excited about is directly deploying to S3 and CloudFront. Hosting a site without any need for maintenance and having it delivered as fast as possible for anyone, no matter where the person is located, is a huge win if you ask me. Currently this happens with the invocation of aws-cli. A boto based implementation will follow.

All other features will ship as minor update when RAWR is released - this is also true for tag based feeds.

Unsorted list of things to know about RAWR:

  • 1.x will not be supported anymore
  • configuration syntax changed
  • you now specify the configuration file instead of the directory when generating your site (this allows you to place templates, the output directory and content directory in different places)
  • it is easier to import it in scripts or other projects
  • first measures suggest that there is a vague possibility that it could be faster by a not specified quantity
  • there will be new features released frequently
  • it should now be as simple as building a blog to build any kind of website

I think this are the most important things you should know about RAWR. I am trying to get it done, but there is still some work to do and I still suffer from a jet lag. So no promise when the exact release will happen. You can use the RAWR branch, it should be fine, but no guarantees.

]]>