soledad penadés

repeat 4[fd 100 rt 90]

During the past three years I've been working in two different environments: big and small companies. Both producing the same kind of final products (corporate applications with web interfaces) have similar problems, and I thought it may be interesting to share them with you so we can find out if there's any solution, and if not, we always can complain and moan about the horrible career we have chosen for our life and how well we would do taking care of green lettuces in a peaceful but lost country farm. So there we go with my appreciations!

About Open Source

• Open Source is good but it is not free
  Although having access to the source code of something means you can adapt the software at your complete will, it doesn't imply that it will be quicker than writing it from scratch. The Open-* Philosophy is great, brilliant, but contributors come from very different backgrounds and sometimes the quality is not what you would expect. Most of the times, mixing several open source projects under another one results in a funky mix of interfaces, classes and methods, with lots of conversions and patches here and there. That is not good, mainly if you want a robust, well thought code, and also for obvious maintenance reasons.
• Using OS without contributing back to the community sucks
  You might believe you're ingenious by using Open Source code and saving some money, thus gaining advantage over your competitors, but developers feel bad about doing that. They know they should give something back to the community and feel really dispaired when you strictly forbid it "because it would mean losing your investment".

About the skills

• The cheapest option is always the most expensive
  Hiring unexperienced developers at a very cheap salary with the hope that they will come up to date in a couple of months is an utopia. The senior developers will feel stupid having to explain once and once again the basics to someone who must know that, and then will get unmotivated the third time they have to argue why using functions instead of copying and pasting the same code is better, for example.
• Sometimes, employees know more than the employer
  Face it. You may have lots of experience from ten years ago, you may know how to negociate even with a Demon, but you're not up to date with nowadays technologies.
  If they discuss any of your decissions, do not try to impose your methods using brute force. It is not an act of rebellion which needs to be dealt with quickly. Just listen to them and learn the most that you can, then think again about your decission.
• Improving the skills
  Good developers are curious, they love to learn new things. Allowing, and encouraging them to spend work time to find out new techniques and be up to date will not only make them happy and unestressed but that will also reflect in the efficiency of your products.
• Respect the spare time
  Everybody needs to rest and have a break from work, even if you think that it is superexciting. Making the people stay for half an hour more every day, suggesting to study new things in their commute home, etc, it's not only dishonest but it's also stressing.

About the interface

• You absolutely need a designer
  Every interface should be created by a designer. They know where to place things. They are professionals on that. No matter how distinguished and exquisite your graphical skills are, you will never be as good as a real designer.
  If you can't afford to hire a designer full time, just look for any decent agency and get a good design made for your product. (I could spend hours describing the horrible interfaces I've seen in these three years, all of them consequence of wanting to save some money in the designer area.)
• Good print designers may be horrible web designers
  Basically, what works in paper may not work in a screen. The style guide of a corporation may be appropiate for printed materials but not for a web product. Unfortunately, there are lots of self-called web designers which create painful html+css layouts, impossible to understand, maintain or modify, so finding a really good web designer may be a tedious task, but will prove to be worth it.
• An interface design is more than a screenshot
  Good interface design will be based on a style guide. Do not think of an style guide as an arbitrary imposition of rules, think of it as a framework that will help you develop the application, saving time on decissions and not having to fix things which are not consistent later on. It is better to provide the developers with all the elements that they will need for the development: logotypes in the needed sizes, interface elements (bullets, fonts), colours (do not give them a Pantone number, they are not designers and they do not have a Pantone list: give them an HTML hexadecimal code, as that's what they will finally use).
  By doing so, it's very complicated that they miss anything.

About treating people

• Developers aren't machines for converting code into money
  They are people, and they have feelings, and they also notice yours. If you're trying to manipulate them, they will notice. And they will turn angry at that (possibly leaving the company in the most stressful moment).
• Don't try to look smarter than you really are
  Because good programmers are also good observers, they will notice instantly that you're pretending to be what you're not, and will probably lose respect for you.
• Verbosity produces boredom
  Being detailed is good. Developers love to hear details about things because it helps them to anticipate what's next, getting a better overview of everything, which is a must for doing a good product. But being too verbose each time you get to talk to them will make them avoid talking to you, because you'll bore them, and they hate boredom. You don't need to revisit every single detail when you're being asked a simple question, nor is there need for explaining the technical implications of using one or another method for whatever to someone which possibly already told you about those technical implications (because he noticed before). Keep it short and they will come back often!
• Keep meetings to a minimum
  Directly related to the above suggestion!

About your clients

• Your client might use IE, but the public might not
  Your client's browser is not the browser that people will use. Do not develop for their browser. Develop for the standards, and you won't get angry calls some years after when (hopefully) bad hacks for IE stop working.
  Also, developers tend to use Firefox. Telling them to use IE "because that's what the client uses" will turn them into an anger machine, and you don't want that, obviously.
• Your client might be wrong
  He doesn't neccessarily need that flash intro, for example.

About the users

• Users are not idiots
  It may occur that the interface is confusing them and then they act as idiots. Maybe they have a different logic - not everybody thinks like you. Maybe you didn't test properly in other scenarios and they are getting errors that didn't arise in your environments.
  But if you refer to them as idiots, the developers will finally believe it, and get unmotivated, because no one likes to work for idiots.

Can't really think of something else now. Feel free to add whatever you are missing in the comments!

And once you understand what is Mongrel you'll have the strong desire to shout it loudly - as many times as possible, just like I'm feeling now! Like "how come I hadn't found this before!? where have I been for the last months?".

For those of you which do not understand my sudden explosion of joy (why is she shouting about dogs? is she now going to talk about dogs every day? etc), I'll explain you what Mongrel is and why it's so extremely useful, apart from lovely.

Developing in Rails has shiny and bright aspects. Scaffold a couple of models in front of your friends and all of them will go oooooooh aaaaaah! (unless they are django users, but that's another discussion). Show them the power of plug-in's and how to extend capabilities of objects thanks to ruby's features and you'll hear a couple of jaws hitting the floor. RJS - anybody heard of it, writing javascript code without actually writing javascript code? Database migrations, anyone? Yeah, Rails is good stuff.

And starting your app, locally, is so easy! ruby script/server and you're done! "Welcome Aboard: You're riding the rails".

Ok. Now go and install it in your favourite host. No one moves - suddenly silence dominates what was an animated and cheered crowd. Why?

Because installing a Rails application in a usual web server is a Pain In You Know Where…

PHP is so popular because there are a couple of fast modules for Apache (mod_php4 and mod_php5) which make running any php script through a server extremely easy. But the ruby module for Apache (mod_ruby) seems to be the most unreliable stuff I have heard of in a long time. So that's why we were told to use another server - Lighttpd with FastCGI and the Ruby module for FastCGI. The problem with it is that it is complex. You need to configure Lighttpd, using another port, proxy it through Apache, create a cron process which takes care of the process and makes sure it will be running even if the server is restarted or the process killed, etc.

Summarising: I spent like two weeks trying to understand how to deploy an application in my hosting. At last it worked but I'm not quite sure how I did it.

But then Mongrel arrived. I had heard about it repeatedly these past months. Everybody talks a mix of capistrano-mongrel-blabla. I found out about Capistrano on the past LRUG meeting, and now I wanted to know what was that mongrel thing. And ooooohhh aaaah!! it is "like a webrick on esteroids", a fast ruby server that you can use in your favourite host, as easy as using webrick.

So, instead of doing

ruby script/server

you would do

mongrel_rails start

And voila:

** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment…
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart).
** Rails signals registered.  HUP => reload (without restart).  It might not work well.
** Mongrel available at 0.0.0.0:3000
** Use CTRL-C to stop.

And you're riding the rails again :)

The best of all is that you can use it the same way in your favourite-host-with-mongrel, which luckily seems to be  the case of mine. You just need to add a cron line for making sure that the process is alive (or the application won't work!), and then you can go for as much complexity as you want, like configuring a "cluster" of mongrel's (for increasing performance), adding plugins, making apache serve images and static content, etc.

I still haven't tried it in the live server, just locally, but it is really faster than WEBrick. Reading the documentation, it even gives you support for running the applications in the same domain but different paths. Like mydomain.com/app1path/ and mydomain.com/app2path. That's very cool - I really hate setting up subdomains because there can't be anything easier than creating a new directory in your web.

And the dog pictures, aren't they lovely?

I absolutely dig Mongrel!

We decided to start using database sessions instead of the usual php storage method, just to check if that would fix the extremely annoying problem of cakephp completely ignoring the maximum session time settings (no matter what setting did it have, it always logs out people after 20 minutes).

So seems that it worked, people could be inactive for a while and after that they didn't find a "You've been logged out" message. But it revealed a new problem: each requestAction was forcing the creation of a new Session object. And each time it is made, it generates like 3 or 4 queries. Which absolutely gave me the creeps when I saw the queries list!

I knew about the potential bad performance of requestAction, I had been warned, but I decided to use it for a couple of "blocks" because I couldn't believe it was going to perform so badly. I could cope with creating a new Dispatcher for handling the request, but those repeated accesses to Session objects are just plain terrible.

I'm impressed no one has noticed it already. It could be solved using a Singleton approach, just as they do with the ConnectionManager. It also could use some kind of cache since all the session functions are in cakephp's domain when you use the database session handler, so why does it need to query the database to retrieve something that was already retrieved 20 milliseconds again?

I finally removed all the calls to requestAction (by creating an instance of the model which was called by the controller and asking it the values directly, etc) and did a pseudo-cache of the session data in my code, and minimised as much as possible the calls to Session->read. While this is code optimised, it is not readability-optimised. It hurts my eyes to see this structure, it goes against nature and against MVC and against something else I can't recall now. Endless pain and agony! ARRGHH!

Two authors were discussing about their writing methods and specially, about the paper they used to write in. The first writer (let's call him Phil) used to prepare himself ruled paper sheets, because -he argued- it was the only method to know exactly how the rules were spread across each sheet, so he could control the height between lines, the amount and exact tone of the ink used to print the rules, etc. The second writer (called Rube) used to prepare the ruled paper but he gave up quickly and decided to just buy ruled paper notebooks, so that he could concentrate on the actual writing instead of the rules alignment.

At the end, Phil's home-made sheets were just quite messy and didn't look as professional and serious as Rube's one. Rube was always able to deliver the books on time, while Phil spent hours and hours improving his custom made method for drawing rules and making sure it was efficient and fast. Often the method failed and he had to restart from scratch.
No wonder Phil's father was a very weird architect which believed in making his own bricks. He took it with lots of dedication and pride but was only able to finish a couple of buildings in his life. Going up the family tree, Phil's grandfather was a mechanic which absolutely defended the need to build oneselves' wheels and tyres and re-engineer their design with every new patron which came to his little workshop.

Phil thinks Rube is a pretentious arrogant guy trying to impress women in any of the multiple social acts which he can attend (as he's got lots of free time thanks to just using conventional ruled paper when writing), and would like to be able to say this to the entire world but he's just too busy drawing lines in order to do any actual work at the end.

I don't know why but I always miss these things. This time it happened one week ago and I get to know now :-(
Anyway, there you have this supercool video of a mob con recorded in one of my favourite train/tube stations, Liverpool Street Station.

Grrroooooooovy!