PHP 5 and MySQL 4.1 bring prepared statements to the masses. While various database extensions supported prepared statements already, they were not quite as popular as MySQL and remained obscur. PHP 5 arrives with a new MySQLi extension for MySQL 4.1 and above with support for prepared statements. In addition, PDO offers a unified API for databases and has PDOStatement objects (created by PDO->prepare()).
Using statements has the advantage of reducing the amount of data transfered to the server by sending the query once and only sending data afterwards. In the process, any work required to escape the values is usually handled by the bind process (which is a huge time saver). Of course, the basic rule is to reduce the amount of queries to the database as much as possible, but in the real world, maintenance tasks often require to perform a lot of processing and update queries are not very flexible when multiple rows need to be updated at once.
Read more…
I learned C++ a few years ago and honestly, I havn’t written a single line in over a year. We used Visual C++ 6 in college. For some reason, I felt like learning more about the language details and what it’s really supposed to be. What can be better than a book written by Bjarne Stroustrup, the language’s original author? C++ is a very impressive language. It can be as efficient at very low levels while allowing extreme abstraction. Generic programming and operator overload really is missing in Java. I would say the downside of the language is that, compared to development platforms, it offers very few high level facilities and the standard library, while being very well designed and robust, remains very low level and does not really provide a plus-value in real applications. Of course, there are multiple libraries available around the web to achieve most tasks. Still, searching for a library is additional work.
The thousand-page monster did cover the entire language as I expected it to. The book is divided in 5 main sections: basic facilities, abstraction mechanism, standard library, design using C++ and the appendicies (which are really part of the book). The book tend to get C++ to look very complex as a lot of pages are used to explain the ambiguities, special cases and obscur syntaxes. To avoid any complexity, my recommandation is to keep code clean and don’t abuse those ambiguities, special cases and obscur syntaxes.
Multiple analogies to real world concepts are used to explain technical details and design decisions. Some of them are quite hillarous. Here is one of my favorites. Static and dynamic type checking is compared to electric plugs:
The most obvious thing about these plugs is that they are specifically designed to make it impossible to plug two gadgets together unless the gadgets were designed to be plugged together, and then they can be connected only in the right way. Had you been able to, you would have ended up with a fried shaver or a fried shavee.
Read more…
I often had to deal with converting data from various formats to others. Most of the time, the task is trivial and only requires writing a single script that does the job. It might be convert data from an old system to a new one, to allow different tools to perform analysis on it or simply to import data from an external entity. In most cases, errors can have huge implications. Since conversions don’t usually occur very often, it’s usually wise to waste a few CPU cycles to make sure incoming data is right and the output makes sense.
In a perfect world, you decide what the input format is and what the content is. In the real world, it’s not always possible due to restrictions on the capacities of the exporting application. The worst case will cause informations to be missing or unaccessible due to bad references. It’s not uncommon to see data scattered across multiple applications and some tasks might require to access multiple sources. Accessing multiple databases or gathering informations from multiple files should not be a technical problem. The problems come with inconsistencies in the data. I have seen systems where the same entry is not referenced to with the same number in different systems or where the numbering conventions simply changed with time and were never documented. The task was actually to make the user’s work more efficient when accessing various systems.
In those cases where the conversion can’t be 100% automated due to the lack of information, user input is required to perform parts of the conversions and resolve ambiguities. Users hate it and users usually hate developpers for it. The only way to actually make it better is to make the interface as friendly as possible. Reducing the amount of clicks and thinking required is a must. Using color highlights, suggesting possibilities and setting the most likely option as the default value usually helps the process (in the case of a web interface, JavaScript for validation or common tasks can be added). Sitting down with an expert user for a few hours to figure out what the common rules are and coding them into the system can cause miracles. When 100% automation can’t be reached, the goal should remain to get as close as possible to it.
A good trick to solve further problems is to write a good user documentation (yet an other task most developpers hate). Documentation is the only protection against user errors and fake bug reports a developper can have. The documentation shouldn’t only explain the different interface details of the application, but also what is the scope of the application (what it can do, what it can’t do and why it exists). A simple RTFM will then solve most problems.
I have been using VIM as my primary editor for as long as I can remember. Still, I keep finding new feature making it even more efficient. I actually had enough time today to dig into the documentation. I guess I now have an argument against all those who pretend GUIs are better than VIM simply because it has class navigation.
With folding, VIM offered a great overview of classes already. Today, I found out that there was actually a “go to definition” feature hidden. Using ctags (exuberant-ctags actually), a simple Ctrl-] while over a token such as a function or class name teleports you to the definition. Using Ctrl-W Ctrl-] (as a sequence) will open a split buffer with the destination in it. Once you’re done looking at the actual code, Ctrl-T bring you back exacltly where you were. The process works as a stack: you can navigate multiple definitions and Ctrl-T take you back to the previous until the stack is empty. As always, everything is lightning fast. The search uses a ctags file located in the current directory. The file is generated using your favorite ctags implementation (`exuberant-ctags -R` worked just fine for me).
Exuberant-ctags supports 33 languages (including all those you really need) and is integrated with multiple open source editors out there (including vim, emacs, nedit, …). From what I can understand, it seem to have started as a sub-project of VIM.
As if it was not enough, ‘gf’ over a file name loads it. :find file_name searches for file_name in all known paths (can be changed using :set path). These can be useful, but I still prefer switching files using buffer numbers.
I visited Google today (which isn’t really original right?) and I noticed a small note at the bottom of the page: In memoriam, Jef Raskin 1943-2005
. Seems like Jef Raskin died on February 26, 9 days after I finished reading his book and gave the worst review ever. I have to admit I feel quite bad about giving such a bad review now.
Even if his book wasn’t very good, Raskin remains one of the very important actors in the development computers and especially interfaces.