URLs should never have the server side technology

URLs should never have the server side technology used in them. Because it is just marketing for that technology and it does not just identify a resource.

Technologies that are shown in the URL but should not (with URL examples):

• CGI https://bugzilla.mozilla.org/show_bug.cgi?id=249338 my suggestion https://bugzilla.mozilla.org/bug?id=249338 or https://bugzilla.mozilla.org/bug/249338
• PHP http://www.facebook.com/home.php my suggestion http://www.facebook.com/
• JSP https://issues.apache.org/jira/secure/Dashboard.jspa my suggestion https://issues.apache.org/jira/
• ASP http://www.microsoft.com/en/us/default.aspx You should not ever have to refer to a default.aspx as http://www.microsoft.com/en/us/ should always be enough (ASP.NET also has problems rooting in the ancestor of the current MSWindows CP/M)
  

Most of the times these are examples of the lack of correct MVC web architectures. Always try to not use technologies that force you to have the technology name in the URL. It is bad practice. And a clear example of bad architecting.

You should also prevent using the technology name in the URL as in:

• http://help.open.collab.net/servlets/tracking

So, always try to call a controller that will render a resource (JSON, HTML, XML, or any other format)

On Programming Languages

Business code should never be developed using a non memory managed programming language. Being either reference counting or garbage collection (although reference counting is time predictive it can make your application more laggy and can not alone detect object cycles so garbage collection is the winner nowadays as Jamie Zawinski says). When writing business code you should not lose time managing memory when the computer can do it better for you.

The programming languages I recommend are:

• Java (for most applications including business or enterprise applications)
  
• Python (for any small application for computer administration)
  
• C/C++ (only for low level or computing intensive code)

Some other programming languages that I neither recommend nor discourage:

• JavaScript is the web browser programming language. There are alternatives like Google Web Toolkit that allows you to translate Java to JavaScript. I still have to take a look at Google Web Toolkit. The main reason I use JavaScript is because it is the browser programming language and client applications are finally settling. But JavaScript has some problems like the lack of a native (fast) function to know the length of an Associative array in contrast with Java's java.util.Map size() method and python's dictionaries len(). GWT implements java.util.HashMap with its own implementation in JavaScript instead of using its own maps because there is no fast size() function. What other people think about JavaScript.
  
• PHP is a specialized programming language for web applications that is currently powering huge sites like Facebook, Flickr and Wikipedia. It still lacks unicode support among other things, but it is quite easy to deploy since most commercial web application servers support PHP. As a weak typed programming language you may get lots of problems like PHP's handling of numeric values in strings. Anyway PHP has lots of design errors so you may want to skip it for any important website. PHP Sucks, But It Doesn't Matter. I just do not use PHP because I do not feel safe with a weak typed language and so many design errors.
  
• Ruby with its Ruby on Rails and great OO syntax it is a language that might have a bright future. It was used for sites like Twitter but ruby on rails has scalability problems that make it not ready for large sites. Twitter changed its core from Ruby to Scala. Ruby 1.8 lacks a bytecode interpreter, Ruby 1.9 transition will take some time as there are important changes and lacks Unicode support. These Ruby problems might get fixed in the future, but right now Ruby's not ready.
  
• C# is a Java clone so it is also quite a good alternative but lacks lots of opensource frameworks to base your software on. So it is only an option if you do not mind the Microsoft only lock-in.
  

I do not like scripting languages because I want my code to work flawlessly and not compiled programming languages do not allow me to catch any error at compile time.

C Libraries

These are some of the C libraries that I use and I recommend:

• GTK+ my preferred open source GUI widget toolkit (used in the GNOME desktop)
  
• SQLite best embeddable SQL database (take a look at File Locking And Concurrency In SQLite Version 3 so you can be sure that your data is safe with SQLite) (It is used in products like Mozilla Firefox, Google Android, iPhone and new Symbian based phones)
  

On Surrogate keys

I am against the usage of surrogate keys when you have a natural key even being it of type VARCHAR.

There should not be a problem using a VARCHAR as a primary key since if the database is correctly architected it may use internally an integer index to join to other tables. And anyway you always have to lookup the surrogate key from the natural key as the surrogate key should never be exposed outside of the application. You still have to declare UNIQUE the natural key and that will hurt the same (or even more), as having it as PRIMARY KEY, on INSERT.

Is there a REAL performance difference between INT and VARCHAR primary keys?

On Database Persistence

Following the great failure of Java EE 1.4 Enterprise JavaBean 2.x Entity Bean (Bean-Managed Persistence & Container-Managed Persistence) (now deprecated). Please, read Expert One-on-One J2EE Development without EJB to understand why EJB 1.x and 2.x has hurt so much Java EE reputation. Also watch Rod Johnson - Lessons Learned from Java EE to understand the dangers of design by committee.

I do not use any ORM tool in my Java projects as they create more problems than they try to solve. Hibernate vs JPA vs JDO - pros and cons of each?
Object-Relational mapping is the Vietnam of Computer Science
ORM is an anti-pattern
Using an ORM or plain SQL?

If you insist on using an ORM, here are two strong free implementations of the Java EE Java Persistence API (Java Persistence/What is JPA?) to choose from:

• Hibernate most popular ORM solution for Java.
• OpenJPA

What Java ORM do you prefer, and why?
JPA Implementations - Which one is the best to use?

On library and its API versions

Many people still confuse the library version and its API version. This leads to problems like not knowing what APIs are supported and when deprecated API will be removed.

There are lots of unuseful versioning examples out there. I am going to present the most useful and correct one.

The API version needs just one number, that is increased when new API is added to the existing one.

So, for example. we can have our "geometry3" API that has an API version number of 1.
If we add a method area() to our Shape class we increment the API version number to 2. There should not be any problem because old API version1 users will still be able to use all the implemented API.

Also, it is possible to have a library implement various APIs. Like in our example it would be able to implement "geometry2" and "geometry3" to support an easy migration to the new API. After some time of "geometry2" being deprecated it could be removed.

For the library version we just need a number (or date) to be able to differentiate old releases for new ones (and be able to differentiate library files).

So, for example, or library version could be 20080610 and if you look what API versions it implements you would be able to see "geometry2.5" and "geometry3.2".

So when you create a new interface like "geometry4" you start from scratch and can add API from new minor API version to the next, but you must not change or remove API since that would break compatibility from prior minor API version number users.

It is common to just have different binaries that implement each API mayor version like having libgtk-1.2.so.0 and libgtk-x11-2.0.so.0 but you could be able to just have a libgtk that implements both APIs in the same binary. You could also be able to have different binaries implementing the same APIs in that case there is a need to a way to specify what library should provide what interface to your binary, maybe using dependency injection.

So, package managers like APT, should work by having programs depend on API versions like "geometry3.2" and be able to fetch a library package that implements "geometry3.2" or newer like "geometry3.4"

On Software Build Systems

A Software Build System is a program that accepts a series of input files:

• Code (Java)
• External Dependencies (JAR files)
• Resources (HTML, translations, CSS, JavaScript, images, ...)

And outputs a series of files in another location (to allow building from read-only sources):

• Archives (WAR, or JAR) (compiled or minimized code and minimized HTML and CSS)
  

Apache Maven is a great build system as it can automatically upgrade and download external dependencies and uses a clear folder structure shared by most projects.

On Debian OpenSSL problem DSA-1571-1

It is sad what happened to Debian OpenSSL leaving all keys weak (DSA-1571-1 openssl -- predictable random number generator) (Slashdot | Debian Bug Leaves Private SSL/SSH Keys Guessable).

When I started using Valgrind long time ago and Valgrind warning about it, I knew something like this could happen.

To detect weak keys, all the keys to take advantage of this problem are already available: Debian OpenSSL Predictable PRNG Toys.

Open source software is getting lots of momentum and it needs software changes reviewing to prevent this kind of things happening. The Linux kernel has mostly good reviewing by having each patch needing review from at least two developers, one of the module maintainers and a core Linux developer (Introduction to Linux kernel development process).

On GNU Autotools

I do not like the GNU Autotools because they make me program shell scripts which I do not like, they generate shell scripts that must be distributed with the released tarball (I do not like to distribute generated files from source if I am already distributing source code), and it is neither backwards not upwards compatible making it problematic to maintain these files. Here is an old article that explains the main problems with the GNU Build System.

On SQL Injection

SQL injection is sadly still a very common problem. Software broadly deployed like WordPress still has SQL Injection Vulnerabilities because instead of using prepared statements in PHP with MDB2 they encode the parameters they think that could be used in a SQL injection. I really think that is not the way to go and I suggest to everyone using prepared statements (java). Also, many SQL servers like MySQL have support for prepared statements, so it may even speed up the application. To force you to use prepared statements and clean your application from unsafe SQL some databases, like H2, allow you to disable literals in SQL statements.

Using object-relational mapping solutions like Java Persistence API/Hibernate can ease programming to prevent SQL injection because most INSERT, UPDATE, DELETE takes care the ORM directly. You still have to use setParameter in SELECT.

Community owned software

The Linux kernel is community owned software because the source code is copyrighted by many individuals and companies whereas OpenOffice.org, OpenJDK or Qt is company owned software because Sun Microsystems and Trolltech have the copyright respectively. This allows them to license the software using any license, open source or privative ones. With community owned software like the Linux kernel this is really difficult because every owner should agree to any licensing changes and it can not be licensed privately because of this.

Client/Server APIs are essential

I have to work with lots of systems where only one UI is provided and no programming API is available so accessing that systems programmatically needs to use code like HtmlUnit or similar.
Instead business should always develop and/or install software with Service-oriented architecture always in mind. Another very important aspect is the use of Business Process Management to take care of every process of the organization first correctly documenting it and later automating it.

Component-based software engineering

I am a big supporter of Component-based software engineering.

When everything is a component you can remove any of its components without any problem and the application continues working but without that component. It is always a very good idea to componentize your application to clean the code and make it easier to read and modify.

In GLib you must always make your objects throw signals instead of calling other objects methods. This way you can remove any other object and have you component still working.

Using the GObject system of GLib is quite easy and efficient to make components encapsulated and reusable.
In Java you have Observer/Observable and OSGi.

On Memory Leaks

I have been using Purify and Valgrind to debug memory leaks in C/C++ programs both in open source projects and for some clients.
For practical reasons both have the same functionality and are able to debug the same problems (memory leaks and invalid access to memory regions)
If you are developing any C/C++ code and doing any allocation in the heap (either using malloc() or other means like new) you must run always your code through either these power debuggers that will almost always find any problems in your code.
If you need any help do not hesitate to contact me. I will help you with your code.

For Java, I recommend the great free open source Eclipse Memory Analyzer that will for sure help you plug the leak.

Unicode Strings and byte buffers

Prior to Unicode there was ASCII or ISO 8859-1 (except for Microsoft that used their own encoding to lock-in users) and string manipulation was not hard.

Now, Unicode is the future since everyone wants an easy solution to integrate all the characters of all the languages of the world to be supported by every application.

It seems like lots of programming languages have problems handling Unicode strings, mainly because they put Strings and byte buffers on the same bucket.
Maybe, some of the programming languages that have problems with Unicode handling is because programmers are using the API incorrectly, but some of them have a real design flaw that make working correctly with Unicode strings impossible.

My test to know if a programming language has correct Unicode support is just uppercasing the "á" string and verify the "Á" string is returned.

Languages that have a correct API include:

• C with glib (using UTF-8) : g_utf8_strup("á",-1) -> Á
  
• Java I do not know any way to do a better API. Java totally differentiates a string from a byte buffer. "á".toUpperCase() -> Á
  
• C# has correct Unicode support: "á".ToUpper() -> Á
  
• Python3 does Unicode handling just like Java did from 1.0 released at 1995. Python is finally catching up with Java! Take a look at What’s New in Python 3.0 so you can know what was fixed. print("á".upper()) -> Á
  

Languages with hard to use (but correct) Unicode support:

• Python2 Why Python2 Unicode Sucks. Python2 Unicode support just calls for problems like urlparse considered harmful as there is no difference between a byte buffer and a string. The slides Unicode In Python2, Completely Demystified will help you understand Unicode in Python2. Move on to Python3 and you will be safe. Python2 has correct Unicode support but it is hard to use: print u'á'.upper() -> Á
  
• Perl Unicode-processing issues in Perl and how to cope with it and Perl Unicode FAQ. Perl has hard to use Unicode support: perl -e 'use utf8; print uc("á\n");' -> Á

Languages that lack Unicode support:

• PHP Unicode not completely fixed until PHP 6 Unicode support in PHP 6 2005 meeting : strtoupper("á") -> Á
• Ruby Unicode handling in Ruby Ruby 1.9 Strings JRuby Unicode. Ruby does not have correct Unicode support #2350: print "á".upcase -> á
  

When standards go wrong

POSIX gets() function should not be used in any program as is a well known buffer overflow. But since it is in the POSIX standard gets() is very difficult to remove from C libraries like glibc because that means that it would break standard conformance. That means that deprecated and unsafe API can stay on standard libraries for long.

Programming languages I have stopped using

I do not support the use of these programming languages. Any people that is still choosing any of these programming languages for production code should be considered a bad manager or programmer. Of course, if you buy any software developed using these programming languages you will make a very bad decision.

• Visual Basic, Visual Basic .NET, Visual Basic for Applications and VBScript they have inconsistent syntax like totally insane array creation (Dim age(6) as Integer will create a seven element array). Visual Basic is such a badly designed language that has made a lot of harm to IT. Microsoft should stop adding features to it and just keep maintaining for some years (there is lots of installed base) and encourage costumers to move to C#. All of the Visual Basic projects I have ever seen have been a failure or much worse than a similar project in a decent programming language. You should be moving to Java and JavaScript or C# if you are still in Microsoft world.
  
• Tcl It is slow, not object-oriented and totally dynamic (I prefer static typing). You should be moving to Python if you want a clear scripting language. Tcl problems [Reddit]. 10 problems of Tcl.
  
• MATLAB were indexing is one based, as it is conventional in mathematics, instead of zero based like normal programming languages. You should be moving to SciPy if you need clear syntax and a complete programming language. Take a look at "Bye Matlab, hello Python, thanks Sage" to know a personal history why the migration is worth it.
• Perl. It does not have a cycle detecting garbage collector (so it can leak memory). It is quite difficult to do object-oriented programming. The code written is not easy to maintain with a group of people. You can see Perl5 drawbacks at Lua Versus Perl5 and Why Python?. Switch to Python.
  
• Shell script as I said in a previous post, shell scripting can be handy but it is not worth the trouble and it is not an option for anything but a simple small script.
• I have never programmed in COBOL, but I am happier for not having to. Just compare the same code in C# and in COBOL. COBOL is a dinosaur.
  

I agree with Edsger W. Dijkstra (Why numbering should start at zero) that any one based array programing language is not serious.

On Java

I have to say that Java is my preferred language to build user applications (as I love C to develop operating system code or low level code).
The things I love from Java are:

• Static typing: I love when variables do not change type and types are checked at compile time.
  
• Powerful Integrated development environments with code completion and inline error checking like Eclipse.
• Speed. Java is not significally slower than C but is much less programming error prone.
  
• Structured and correct Application programming interface.
  
• Correct String based manipulation APIs for Unicode text. I have still not seen a "scripting" language that manages strings correctly with its encoding and differentiates correctly a string from a byte buffer.
• Opensource OpenJDK

XML (and DOM) vs JSON

The main problem with XML is that it is being abused, by unexperienced programmers, for applications where it is not suited (XML is designed for document text markup) like general data structures serialization (like SOAP where formats like JSON are much more suited) and persistence (where a RDBMS like a SQL database is much more suited).

XML is OK as markup for text documents, but it is not suited as a data serialization format.

In my honest opinion, XML should always be created and accessed through DOM. I have seen lots of software creating XML documents not using DOM and thus making huge mistakes like malformedness, incorrect escaping and even making the data serialized to XML not being the same as the data deserialized from that XML. Take a look at this tutorial to generate XML with DOM otherwise you may perform these XHTML common errors.

The biggest mistake made with XML was making it a text file format by default instead of a binary format. If it was made a binary format everyone would always use DOM to access and modify it both from client and server applications (exiting templates using a XML editor) and many of the mistakes developers make today would not me made.

I have found that for data structures serialization JSON (or its sibling YAML, as used in Google App Engine) is much more suitable than XML, because accessing a list hash and scalar data hierarchy is easier than accessing data from XML DOM. I totally agree with Kris Zyp - XML vs JSON.

Anyway, for maximum efficiency and speed you need to use ASN.1 DER or a less standard but maybe with even more future like Google's Protocol Buffers (see what Google has to say about the inefficiency of XML).

What is the worst abuse of XML that you have seen?

Why shell scripting sucks

Writing any program in shell script is like shooting in your own foot in my humble opinion. I am talking about Bourne shell and its descendants. Here are my reasons:

• Having the default setting of globing '*' returning '*' instead of nothing when there is nothing to match is just plain wrong. Suppose I write a shell script that updates the modify time in all the files in a directory so I write 'touch *', if there are files it works as expected, but if there are no files it creates '*' file!
• To test that a variable is equal to something you have to do: if [ x$1 = x-h ] that can not be a good programming language.
  
• Lack of associative arrays, so it is not useful for anything but really basic scripts. (Bash 4.0 finally has support for associative arrays)
• It is not compiled, but executed line by line (you may not know it but python is compiled to bytecode at runtime and the bytecode interpreted unlike Java where the bytecode is also compiled to machine specific code)
  

So, in my opinion you better stop doing any shell scripts and write java or python instead of a sucky shell script.
If anyway, you code a shell script please see Bash Pitfalls to know about all the common shell script mistakes you can make and always write robust shell scripts.