If you are like me, you probably think that the advertisements on Google are mostly annoying. In rare cases they show something interesting, but most of the advertisement on Google searches are not useful for the things I am looking for — unless I am trying to buy something.

Now, for a limited period of time, you can have access to Google search without the annoying ads. The trick is using the test search engine that Google announced recently.

The idea behind this is that Google wants to test its new infrastructure for search. So, they will allow anyone to search on it, as a way of checking that results are correct.

The interface is identical to the current system, but the results may be a little different.

So here is the tip: if you want to help test this new infrastructure and, more importantly, avoid seeing the ads showing everywhere on Google, just use the address http://www2.sandbox.google.com/ instead of google.com.

This is a piece of information I am posting for my own convenience, but that may be of use to other people using Git.

I use git to keep my local files. Not only programming files, but also all types of information, including blog entries and other miscellaneous data.

Sometimes I delete or move a whole directory, and wish to recover it later.

The recipe is simple, but easy to forget because I rarely use it:

git ls-files -d | xargs git checkout --

To explain this, notice that git ls-files -d just list deleted files. Then, xargs will feed these names to git checkout --, which is responsible for restoring the file.

This weekend I spent some time to test clsql on sbcl. I tried to do this before on Windows, but I couldn’t get it to work. So I used my trusted Amazon ec2 linux machine to do the job.

Initially, I had to use yum to install sbcl. It is as simple as

yum install sbcl

and watch the packages being downloaded. I also needed to install gcc and mysql-devel (this depends on the distribution).

yum install gcc
yum install mysql-devel

Then, I used asdf to install the required packages, including clsql. These are some of the commands I used:

(require :asdf)
(require :asdf-install)
(asdf-install:install :uffi)
(asdf-install:install :clsql)

There was a lot of complaining from asdf-install, especially related to a missing gpg library. Also, most backends other than mysql failed to compile, which is ok, and I just ignored it selecting one of the options given by the debugger.

Once installed, you can use clsql to make calls to mysql. I created a simple database called carlosdb with the commands (typed on mysql prompt):

create database carlosdb;
use carlosdb;
create table users (
     `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
     `name` VARCHAR(100) NOT NULL);

Then, we can use clsql in the following way:

(require :asdf)
(asdf:operate 'asdf:load-op 'clsql)
(use-package :clsql-user)
(connect `("" "carlosdb" "" "") :database-type :mysql)
(execute-command "use carlosdb");
(query "select * from users")

The two results of the last operation are lists like the following:

((1 "john nash") (2 "james jim") (3 "jon williams"))
("id" "name")

where the first list is composed of sublists, each have as elements the contents of a record. The second list just stores the names of the fields (id and name, in this case).

Some Helpful Resources

• Practical Common Lisp: a book that explains what asdf is all about.
• An example of clsql use
• The pages for clsql and uffi on cliki.

In the last post about learning to use the debugger, I mentioned a few tricks that you can perform with a good debugger, like for example changing the values at certain memory locations. These are tricks that can speed up your debugging process, because you don’t need to recompile lots of code and restart your program just to test a small change.

Another related technique consists of using the compiler itself to perform some check while you make changes to the code

An example of how this works is presented in a post by Hovik Melikyan. He discusses what he calls brute force programming, where the idea is to use the compiler to perform temporary checking.

For example, one of the techniques is to use the compiler to figure out exactly where a variable might be used. The simple thing to do in this case is just to rename the definition of the variable temporarily. During compilation, you will see all locations where the variable was used and fix them accordingly.

A related technique that I use in C++ can be used to show where a type was defined. If you want to find the definition of a type (usually from a library, such as MFC, for example), what you can do is just writing a new typedef with the type you are searching for. If the type is, say, Widget, you would then write

typedef int Widget;

If you do this, the compiler will immediately give you an error saying something like: “type Widget was previously define on file X, line Y.” So, now you know where the type was originally defined.

Is there any other trick that you use to make your compiler work for you? Let me know.

Hi, this is the 9th part of a series of posts on 30 tips to becoming a better developer. If you would like to keep up to date with the topics that I am covering, just check the main post.

However, despite the fact that we usually need to spend lots of time tracking down problems that show up in our code, it is interesting to see how few developers have familiarity with the facilities provided by their debuggers.

The most probable cause for this kind of overlook is that developers don’t see the activity of debugging in good sights, and with a reason. Spending too much time on debugging generally means that you didn’t spent enough time on the planning and design phases. It may also mean that you have been sloppy during writing and testing.

Still, there is no way to avoid the fact that humans make mistakes, and that these mistakes need to be fixed in some way. If we are talking about software, this means trying to find where the problem is happening and then finding a reasonable fix to the root cause of the problem.

Unless you are on the league of developers that don’t use anything else other than printf’s to debug code (I think Linus Torvalds is on this list), you need a debugger. So, you need to start looking at the debugger not as an evil that you should avoid, but as a tool that you can use on the right situations.

Other Uses for a Debugger

Once you get used to your debugger, you will start finding some uses for it that are not just related to finding and killing an existing bug. For example, a practice that many productive developers have is using the debugger as a first pass testing tool.

This method is not enough to replace serious testing, such as writing unit tests for all your code, but it is usually good enough to let you know if your “first draft” of code is working or not.

The idea is that, for each new method you write, you should put a breakpoint at the beginning of the method. Then, let the program run until the break point is reached. The next thing is to follow the execution of that part of the code step by step, until you are convinced that the results are correct.

Using the step-through method with each new method you write is a good practice, because it will give you more confidence on what you wrote. It is not a formal procedure like writing a unit test. But even if you are writing such tests it is still useful to use the step-through method. For example, while going through the code you could think of new tests that should be added to catch some extra cases that you didn’t consider initially.

A Debugger as a Poor Man’s Dynamic Language

The main reason why using a debugger can be very useful if you learn it well is that debuggers allow you to poke at the program as it is running, as opposed to just look at a listing of code. Even in a static language like C++, you still have a lot of freedom while using a debugger. You can, for example, change the contents of variables at will, and even modify the contents of specific memory areas.

The result is that the debugger can provide you with a dynamic view of how the code is working. For example, it is extremely easy to see the stack of callers that brought you to some point in the code. In an OO program, this can be a very useful information that is sometimes hard to find by just looking at the printed code.

Finding More Information

There is a huge amount of information about debuggers in their own documentation. You just need to take the time and learn what is available. Here are some links that will be helpful if you are using Visual Studio, gdb, or ddd.

You should also check Code Complete, which has a nice section on the marvels of debugging!

Go to the next post of the series:

• Day 9: Learn to Use Your Debugger
• Day 10: Learn Keyboard Shortcuts
• Day 11: Understand the Lower Layers of the System