piątek, 21 sierpnia 2009

PHP MVC vs. C# ASP.NET or the cure is worse than the evil

I started programming using C++.
Then I was writing stuff in C, C++, Pascal, Java, C#.
When I wanted to get my first job I figured out that most students work as PHP programmers, so I borrowed a book about PHP, wrote a sample application and a month later I was a PHP programmer.
I must say that in the beginning I hated every single bit of PHP. I've never written an app that I din't have to compile in order to run it. These crazy PHP constructs such as $$. Wow, they're really crazy.
What is more, I have never written a web application before. I always wrote some console / desktop stuff.
However, after about 3 months of coding on a daily basis I was pretty comfortable with almost everything I was doing. Maybe not with PHP itself, to be honest - I have never become comfortable with this language, but whole MVC pattern and its connection with web interface is so intuitive and natural that it really became my world. I still think that navigation on web pages is far better than navigation in desktop applications. When everything is identified by URL and I can open every link in another tab, I feel comfortable with interface. When I have lots of buttons and no tabs to open, I feel crippled with interface.
When I see a link like /article/show/123 or /article/edit/123 and I have Article controller and methods like show or edit, I can just sit and write code I need. I just love that HTTP protocol is stateless. I love the fact that anyone who clicks the link, be it a real user or google crawler, sees (almost) the same content.
PHP also has great template frameworks, such as Smarty. It's very intuitive and readable. The most important this is that THAT guys ;) don't have problems working with it and can easily can change the markup without affecting application logic.
Even though PHP frameworks like Cake and basically all MVC frameworks are very intuitive (in fact we were using our own MVC framework), language that drives them is really crappy. I've seen lots of PHP code, even very good PHP, and I've never seen good object-oriented patterns. Yes, there were lots of classes, but concepts such as inheritance, static objects, interfaces or abstract classes are not a part of this world. Classes in php are quite important but they are not strongly related to each other. When I think of real OO classes, I think about inheritance, interfaces that they implement, I see that some of them are more specialized, while others represent some general ideas. PHP OO in my opinion is poor man's OO. The real power in php are its associative arrays.
If I ranted about PHP flaws in its implementation of OO and wouldn't say that I was a strong advocate of not using most of its features in PHP5, I would be very unfair with people developing this language. I was always a strong opponent of using private / public keywords. The main reason was that every time someone messed up with it, we got white page of death on production server. I consider private / public modifiers to be important while compiling the code, but they become completely unimportant during runtime. Even if you declare field to be private, you can still access it using reflection of some kind. In php, when you don't declare types of method arguments, concepts such as interfaces also don't mean anything. PHP function takes basically anything and then tries to execute some methods on it. You don't have to declare interface to be able to execute some particular method on a given object. Well, you just try to execute it.
I worked with php programmers who actually used to think about types of objects they passed to functions. All interface / abstract stuff WAS implemented in the logic but not in terms of keywords. It was convention over configuration, and it worked pretty well.
Unfortunately, when someone didn't want to keep the convention, we just couldn't force them to keep it. And hell yeah, I wanted all people using my code to pass only some particular interfaces as arguments. I was unable to do that.
To sum up, I think that PHP is crappy, but it has great MVC frameworks, nice templating systems and if you want, you can write really good code in it.

On the other hand, there are C# and ASP.NET. I must say that I just love C# 3.0. It has so many useful features, great attributes, lambda expressions, generics. Some things could be better in C# 4.0, but even now it is my language of choice. C# lets you write clean and descriptive code that you would not be able to write in PHP.
However, here comes ASP.NET. I'm not talking about ASP.NET MVC - I have no experience with it, I'm talking particularly about classic ASP.NET. Well, ASP.NET is such a poor abstraction that I still cannot understand how someone came up with this idea. The whole concept of WebForms is really far from what web is really about. How could they come up with a lifecycle like that: page lifecycle (click to see the picture). Honestly, how could anyone make such an unintuitive life cycle and say that it is easier for web programming because it's like WinForms programming?
Most ASP.NET developers think that ViewState and Session are perfectly good places for keeping variables responsible for page navigation. Yeah, it's so great when you click on a page and URL doesn't change. It's so easy to share content with other users. Crawlers also love it! And what is really cool, sometimes you have to debug your application to see what are your current arguments and then you may find out that e.g. you forgot to clear Session in some onclick event.
And the whole gridview thing. That's a neat idea. Take everything from any datasource you have (e.g. 10 million records from a database) and do all things like filtering, sorting, paging, etc. yourself! Furthermore, keep all data in ViewState.
Seriously, how could anyone come up with that?
Everybody knows that webpage is like a real desktop application and all actions should be seen as events, e.g. click. Everyone agrees? Great.
Templating engine? We will show how hard could that be. Even tags are messed up: inline tags.
Crossbrowser issues? Only in asp.net. Yeah, there are lots of controls that work in IE, but don't work in FireFox.
Someday, I will come back to asp.net issue. In this post I just wanted to show how crappy it is. In my opinion, when you write web apps in php, ruby or python, you feel that you're writing for the web. When you use ASP.NET, you're writing these stupid webforms.
To sum up, C# - great, ASP.NET - yuck.

And here comes the final conclusion.
If I had to write a web application that goes public (not some intranet application) I would choose...


... PHP + MVC. I'm really sure that the result would be far better using that technology.

If I had to choose a job and I could choose between using these two technologies I would choose...


... C# + ASP.NET. It's better paid and you have chances that you'll be writing some underlying layer in C# and you don't have to deal with ASP.NET.

I must check this ASP.NET MVC stuff. I hope it will solve all issues of classic ASP.NET.
Remember kids, choose the right tools for the job and keep in mind that all that glitters is not gold ;)
Q.E.D., Bitches!

środa, 19 sierpnia 2009

Prisoner of ice

All software companies talk about quality of their products. Quality is such a buzzword - sometimes I think that it doesn't mean anything at all.
However, quality means a lot to developers. Many developers that I know really care about products that they create, often against their managers and their companies. I understand when managers decide that they cannot spend more on some particular product, but I cannot understand a situation when a company makes developers work on some unimportant documents instead of making them focus on their work and implement the real thing.
I often encounter a situation when best developers in the team are assigned to create some specs in the early stages of development (often they have to analyze problems that they don't fully understand before the implementation), and people who are responsible for the actual implementation are unexperienced folks that have to learn how to solve problems during the project.
During the development everybody is in such a hurry that all tools and practices that are necesarry to create quality product are abandoned. This means no unit tests, no code reviews, etc. The project just flows. Because people who are developing it don't have any experience, they cannot solve even simple problems, they make obvious mistakes, copy code and everything becomes an awful mess. The project runs behind the schedule and, what is more important, it doesn't ensure any quality at all. After struggling with deployment, the product goes public and bugtracker is filled with bugs.
Unfortunately, because the budget was exceed, all funds are cut and people working on the project don't think about ways to heal it, but they start reading the specs, trying to persuade the client that the project meets specification requirements.
In this stage we can hear a bunch of silly questions, such as:
Do we have to log errors?
Do we have to support firefox?
Do we have to show error messages to users?
Do we have to validate input?

Well, the specs don't say anything about it. What's the conclusion? The project is just perfect. The only problem is that it just doesn't work.
After wasting lots of time on trying to vainly persuade the customer that it's not a bug, but it's a feature - the company faces the fact that they have to solve these problems. Unfortunately, as I've said before, they don't have any funds left. What is more, they discover that time spent on fixing the product generates loss, but if the developer does nothing or does not report his time on this particular product, no loss is generated. Now, the biggest issue is reporting the time spent on fixing the product. On paper it is better to sit and do nothing than to fix the damn thing.
It's like putting handcuffs on developers' hands. You just can't do anything. You know how to fix it, you have the idea, you know what you need, but you can't do it because, magically, the moment you report your time on the project, you start generating loss.
And the so story goes...

In my opinion, these problems are encountered in companies that are focused only on making money and they forget that they are making software. In the end, developers have to think about the budget and all that stuff around cost management, not about making great software. As the result, software is crappy and the income is far smaller than it was initially expected.
I have no experience running any company and maybe I am totally wrong, but I can tell bad software when I see one. And when I see developers that are prisoners of their projects, managers and procedures, I wish all project managers would be like Ron Jeffries or Joel Spoolsky. I wish developers could create applications that delight customers, create code that speak for them, have specifications consisting of test cases and work with the best programming teams in the world ;).

niedziela, 16 sierpnia 2009

Some nice quotes


  • Never pay more than 20 bucks for a computer game - Guybrush Threepwood

  • Yes, there were some customers reporting problems with their phones, but it seems that most iPhones repaired themselves after plugging them to iTunes - guy at the cell phone store, when I asked him if iPhones break often. I wonder if the same thing goes with Mac's Xserves...

  • While all those other languages (Lisp and Smalltalk being particularly noteworthy offenders) tried to pretend that operating systems don't exist, and that lists (for Lisp) or objects (for Smalltalk) are the be-all, end-all of getting shit done, Perl did exactly the opposite. Larry said: Unix and string processing are the be-all, end-all of getting shit done. - Steve Yegge http://steve.yegge.googlepages.com/tour-de-babel

sobota, 15 sierpnia 2009

Nobobody wants to be THAT guy

Yesterday Jeff Atwood quoted some excerpts from Michael Braude's post Why I’ll Never Be A ‘Web Guy’ on his blog.
Of course it led to some flame wars about the question whether being a web programmer means to be a bad programmer or stupid programmer or anything else.
I must say that I completely disagree with Michael Braude's post. Especially with the hypothesis that web programmers are worse than desktop programmers. I cannot see the line that is between web and desktop programmers. Are there any big apps that don't connect with webservices or don't get any resources from the web?
Well, maybe I misunderstood Michael's post because in one of his comments he says:
I don't consider server-side programming "web programming" because SOA encompasses all mediums. Once you get into writing web services and DAL's you've left the world of aggravation.

So what the hell is he talking about? About creating simple html pages? Writing some javascripts?
In a company where I worked previously there was position called HTML programmer. We were making some jokes about it, because we, backend developers - "the real programmers" - didn't consider html to be a programming language. Due to popularity of XHTML we said the position name should be changed to XHTML programmer, however one of the HTML programmers left the job before the renaming took place and was claimed to be first ex-HTML programmer ;)
I must say that I really liked this distinction. I never had to deal with CSS or divs or anything. I just prepared some basic html (mostly including table layouts ;)) and then the template went to HTML guy and he prepared some decent looking webpage.
I always thought that HTML / javascript guys were not real programmers. They often didn't know how to program but they were never responsible for application logic. I never wanted to be a HTML guy and I never was. However, I would never say that they are better or worse than backend programmers. The reason why they wrote HTML was because they liked it, they chose this job, not because they weren't smart enough - they just had different skills.
I know good and bad html programmers. I think that writing good html and css requires lots of skill and I appreciate their work.
I don't consider c# / php guys smarter than html guys. On the other hand, I do think that being frontend developer is far less demanding that being backend developer. But that's just my opinion. If I say that being windows administrator is far easier than being unix administrator, I am not saying that windows administrators are dumber that unix guys. And if I needed windows administrator I would hire one. I would not hire unix administrator for this position because I think that his previous job was more challenging.
The problem with Michael Braude's post is that he somehow says that html programmers are inferior to backend developers. I am also considering their JOB inferior but I don't consider THEM inferior. Still, that's only my personal view on job market and it also reflects my ambitions and aims in my career as a developer.
The last remark is that people who use easier tools aren't dumber than people using the tools that are harder to maintain. What is more, maybe they choose better technologies and more powerful toys and in this way they are far smarter than people who think are intelligent enough to reinvent the wheel from scratch.

piątek, 14 sierpnia 2009

Unstoppable force meets immovable object

Code generation - here I come, once again.
Once upon a time I had to create a cms system. The system was quite large and I had to do it in about one month. What is more, the main reason I was creating the new system was to fix the issues we had with the old one. The point is that I had really not enough time.
However, I was able to create quite a decent application. I was rather satisfied with the result and the system didn't have a lot of code repetitions in its core.
Most of the logic was handled by business classes and they implemented good abstraction, i.e. versioning, cache and such stuff were implemented in base classes. However, the project had similar controllers and models (models in framework I used were something between a classic model and controller) for every module such as article, news, banner, etc. Due to a short deadline I was literally copying the files and changing names in them using replace function in IDE. Then, when I had some time to work on that code I changed all literal strings and other things specific to modules to constants that pointed to configuration in particular modules. My aim was to create classes that didn't force me to think while I was replacing text in source files, e.g. instead the sentence "Article has been added successfully" in template file I started using something like $moduleConfig[ARTICLE][TEXT_ADD_SUCCESS]. Well, that was my poor man's code generation. It had all the features of code generation besides the generator ;) At least I didn't have automatic code generation but I was manually copying files from other modules that were my templates.
To be honest, we've never encountered any serious problems with this approach and it worked quite well. However, I always thought that if I were given a week or so to work on this code and refactor it to extract base classes for models and controllers, the project would be so much better. The project was crippled with the fact that the whole code for these controller and model classes was duplicated. Unfortunately, I was never given the time to fix it before I left my ex-company. Everything was prepared, base classes should implement all the logic and child classes would know who they were and what constants they should use.
That story showed me that code generation, when used improperly, may seem an easy solution to a problem that should be addressed in another way.
Every tiny bit of logic that is generated shows that it should be placed in another element in design or higher in inheritance hierarchy.

First observation - IMHO, no application logic should be automatically generated.

But what about classes that give us strong typing for a cost of code generation? I'm not talking about typed DataSets in .NET because they suck so bad that they are not even worth mentioning but let's talk for example about classes generated from SubSonic. In the simplest approach generated classes reflect tables in database and they have strongly typed fields that represent columns in tables.
What are the advantages?
- you won't misspell a column in a table
- you also won't assign e.g. a string to an integer
But what are the disadvantages?
- you end up having lots of code that doesn't implement any logic at all
- every time you change database schema you need to regenerate your database classes
- if you generate CRUD from it, you will have problem achieving good level of code coverage
- if you change field name in database and want to keep property name in class, you may get confused using different names for same thing

Sometimes I think that we are paying too much for strong typing. Maybe the IDE should check the database and automagically check source code? For example, when I was writing a simple program in F#, the IDE checked if I specified correct format in literal string that was used in the method. When I specified in string representing format that I was expecting int and the corresponding argument was string, the IDE was smart enough to discover this problem. What is more, even if you misspell some fields you must have not tested the application at all if you didn't find this error.

Some frameworks let you write code that goes pretty well without the need to generate code (e.g. PHP frameworks); others (like ASP.NET that needs to see every control as a variable with a type, name and all that stuff) may try to force you to generate some code. Of course, I'm not a big fan of the latter.

And one final remark. I don't consider operations performed by a compiler to be code generation. Generated code may occur only in source files that developers are maintaining. We don't maintain byte code or low-level assembly instructions. The same goes with different forms of syntactic sugar that are handled by compiler and translated to "normal code" behind the scenes.
My friend wrote a note about on his blog: http://binary.freeperspective.net/countzero/2009/08/14/code-generators/. He says that he will come back to this issue. I'm eager to read his thoughts about the topic of code generation.

poniedziałek, 10 sierpnia 2009

Static code analysis - how much is it worth?

Recently, I've been using some tools to statically analyze my code. These tools are:
StyleCop
FxCop
CloneDetective

The sooner you start using these tools, the better. If you start using them in early development of your project, they may give you some hints about structure of your code and lead you to some good patterns. However, if you try analyze a project that consists of thousands of lines... well, what can I say - you'll just get the message that you did something wrong.
For instance, if you always use ToString() without specifying CultureInfo you'll get so many warnings that it would be almost impossible to correct them. To get meaningful notices that are important to your project you'll have to uncheck lots of rules in FxCop and StyleCop.
Clone Detective is a bit different from the previous tools. It analyzes source code to find code duplication. It's nice to have such a tool, especially when working with rather big projects. It may show that you're writing something that has been already written and also it encourages people not to use copy and paste. In one of my previous posts I wrote that code generation is just another way of doing copy and paste, my buddy Clone Detective says same thing ;) Yet again, if you start working with Clone Detective early, you'll be glad to see code duplication statistics showing maybe 5% of duplicated code. However, if you run it against a big project and see statistics at 40% or higher, it will just show you how miserable your life is.

There are lots of resources about all of these tools (guides, podcasts, etc.) so I don't want to talk about it in details. Yet, I wanted to state my current opinion on all of these tools.
If you're writing code that cannot pass static code analysis tests, I don't think these tools will "show you the way". These tools are for people who want to write good, bug free code. Good code is far more than sequence of brackets and letters. Good code has meaning, has design and all these little things that static analysis just cannot check. If you have some time and want to write and learn how to write code according to standards, then, hell yeah, give it a shot. However, if you are going to spend one hour writing unit tests or one hour adding all those CultureInfos - write some unit tests.
I was using these tools on my project that has lots of unit tests and I think that it was the main reason I was able to easily resolve all warnings. To be honest, I don't really think that the code is better after the analysis, but it's nice to see that I don't get any warnings. Also, I agree that these tools showed me some nice patterns that I didn't know about. But the bottom line is that I wouldn't be able to correct my warnings without unit tests. What is more, maybe my application is more portable and code is sticking to the rules, but it passed the tests before, and these tests are the real mark that everything is fine and the project is healthy.
Recently I ran a static analysis against some big project at work and they just showed me that the project sucks (as if I didn't know that before). I also think even if it would pass fxcop and stylecop tests it would still suck (clone detective is a different story). As Homer Simpson said: "This book has no answers". These tools also don't have real answers. Maybe some day these kind of tests will be run by compiler but we all know that code that compiles is not an indication of a bug free application.
I'm still under the spell of Bruce Eckel's article Strong Typing vs. Strong Testing.
Static analysis, in my opinion, is somewhat like strong typing.

P.S. My friend wrote an interesting post about static code analysis - Static analysis tools – one step closer to writing bugfree software.

sobota, 8 sierpnia 2009

Epic fail of proz kudoz

My wife is a translator and a user of proz.com. Recently she found a polite mail from proz team in her inbox saying that their site was hijacked:

This notice is to inform you that certain ProZ.com user
information was recently accessed improperly. Your profile may be
among those affected.

Among the forms of data accessed in the security breach were
name, email address, postal address and phone number. Login
information (usernames and passwords) was also accessed, though
passwords are protected by encryption. Other forms of information,
such as financial information, etc., were not accessed. (ProZ.com
does not store credit card information, etc.)

For more information about this incident, see:
http://www.proz.com/about/security


When I saw this email I checked if md5 hash of her password was present in hash databases - fortunately it wasn't. Then I started thinking about rainbow tables attacks and such stuff. I also thought that maybe password was hashed with sha-1, salted and there was more magic going on with it. I tried to ask myself if releasing password information was such a big deal if password was properly encrypted. Well, I still think it IS a big deal but i couldn't foresee what was coming.

I checked the page from email and read some faq about this recent security breach. One of the questions was:

Can you explain in more detail how password encryption works?

If your password is "uncle3pablo", what is stored in the database is something completely different: an encrypted version of the password like "dW5jbGUzcGFibG8=". What was accessed were the encrypted versions. If a person attempts to log in to your account with the encrypted version of your password, it will fail.


Hey... dW5jbGUzcGFibG8=??? It's goddamn base64. WTF?! You're showing that you're using base64 and you're saying that password is safely stored?! What is more, you're saying that a hijacker cannot log in with this password. Well, if you add "a" letter before password the hijacker will also be unable to log in with this "encrypted" password version.
To all people responsible for proz: base64 is an encoding used for transferring binary or other data in ascii text format http://en.wikipedia.org/wiki/Base64. Base64 IS NOT cryptography. Base64 is as safe for storing password as plain text.

What really makes me wonder is that someone responsible for such a big portal for translators decided that passwords will be encoded with base64.

FAIL!
UHJvei5jb20gLSB5b3Ugc3VjayE= - crack that password.