KludgeHack

Steve Jobs and Bill Gates
31 May 2007 in Microsoft & Random tidbits & TV | Comments (0)

Yesterday at D5 Conference both Bill Gates and Steve Jobs were interviewed. This hasn’t happened for a while, and its worth seeing.

You can watch the highlight of the interview here:

For those interested in watching the full interview (Over an hour. I recommend), visit the website here.

Also, at Wired, Leander Kahney wrote an article about who’s the star between this very popular guys: Bill Gates and Steve Jobs. It’s an interested twist about how Bill Gates is giving is billions to improve the world, when Steve Jobs is the one “taking on the role of single-minded capitalist”.

Google Gears - The new runtime in town
31 May 2007 in Programming & WebDev | Comments (2)

Google finally entered Microsoft and Adobe competition in the RIA (Rich Internet Application) by introducing Google Gears.

Google Gears is nothing more that a small (700K) runtime that allows any website to benefit from its offline capabilities, local isolated storage and faster Javascript (asynchronous).

The runtime is available for Windows Vista, Linux and Mac. Also, the code is available via the new BSD Licence.

Some of Google’s applications are already supporting this technology, mainly Google Reader, and there notable increase of speed in them.

The picture on the right shows the dialog that pops up to let you know that Google gears is going to be storing data locally.

The data is stored in a SQLite database, and the web application can use Javascript to CRUD (Create, Read, Update, Delete) the data.

You can easily use SQLite tools to browse the database.

Here’s a snippet of Javascript that is used to detect if Google Gears in installed. There are three (currently) different ways to do this, one for each of the supported browsers: Firefox, IE and Safari.

  var factory = null;

  // Firefox
  if (typeof GearsFactory != ‘undefined’) {
    factory = new GearsFactory();
  } else {
    // IE
    try {
      factory = new ActiveXObject(‘Gears.Factory’);
    } catch (e) {
      // Safari
      if (navigator.mimeTypes[“application/x-googlegears”]) {
        factory = document.createElement(“object”);
        factory.style.display = “none”;
        factory.width = 0;
        factory.height = 0;
        factory.type = “application/x-googlegears”;
        document.documentElement.appendChild(factory);
      }
    }
  }

Here are some websites with more information:

• Google Gears Developer site
• Google Gears Frequently asked questions
• Google Gears Developer Forum

A Gears Tutorial is available that illustrates the basic concepts. You may also find the Google Gears sample applications useful. Source code for these samples can be downloaded in a zip file found on the same page.

The runtime looks pretty good. I will try to explore more soon.

Let’s see how this will fit in the current Silverlight vs Apollo vs Flash space.

How to write awesome code
31 May 2007 in Personal Experience & Programming | Comments (0)

I’ve been wanting to write a HowTo, but couldn’t find an appropriate subject. Finally occurred to me to talk about something I really appreciate: techniques to write good, simple and comprehensible code.

Writing good code always was a challenge to me, mainly because the definition of good code isn’t somehow very clear.

So, what is Good code? I believe that is a program that works flawlessly and has no bugs. Unfortunately, this can’t be easily archived, at least in practice.

Design, I think is the key to writing the good code. Planning in advance what the code must archive is crucial.

Whatever is the language of choice, all good programming must show this same good qualities:

• Simplicity means you don’t do in ten lines what you can do in five. It means you make extra effort to be concise, but not to the point of obfuscation. It means you abhor open coding and functions that span pages. Simplicity—of organization, implementation, design—makes your code more reliable and bug free. There’s less to go wrong.
• Readability means what it says: that others can read your code. Readability means you bother to write comments, to follow conventions, and pause to name your variables wisely. Like choosing “taxrate” instead of “tr”.
• Modularity means your program is built like the universe. The world is made of molecules, which are made of atoms, electrons, nucleons, quarks, and (if you believe in them) strings. Likewise, good programs erect large systems from smaller ones, which are built from even smaller building blocks. You can write a text editor with three primitives: move, insert, and delete. And just as atoms combine in novel ways, software components should be reusable.
• Efficiency means your program is fast and economical. It doesn’t hog files, data connections, or anything else. It does what it should, but no more. It loads and departs without fuss. At the function level, you can always optimize later, during testing. But at high levels, you must plan for performance. If the design requires a million trips to the server, expect a dog.
• Elegance is like beauty: hard to describe but easy to recognize. Elegance combines simplicity, efficiency, and brilliance, and produces a feeling of pride. Elegance is when you replace a procedure with a table, or realize that you can use recursion—which is almost always elegant:
• int factorial(int n) {
      return n==0 ? 1 : n * factorial(n-1);
  }
• Clarity is the boss of good programming, the platinum quality all the others serve. Computers make it possible to create systems that are vastly more complex than physical machines. The fundamental challenge of programming is managing complexity. Simplicity, readability, modularity, efficiency, and elegance are all time-honored ways to achieve clarity, which is the antidote to complexity.

All of these mean nothing if you don’t really understand what you’re doing. Good programs are more about a clear goal than coding skills. That’s why planning in advance is important. If you can’t write it down, if you can’t explain it to others, you don’t really know what you are doing.

A good programmer, is the one who applies such quality’s on their code 100% of the time. They understand the benefits of such code. But such skill, needs practice to grow. Writing great code doesn’t come fast and easy.

One other very important point in writing really good code, is using automated tools to test, profile and verify your code. There are actually many tools for almost every *popular* language to simplify the task of the programmer in simplifying, optimizing and speedup the code.

For .NET programmers I recommend using this tools:

• FxCop (code analysis tool) to check the code conformance to MS .NET Framework Design Guidelines.
• NUnit (unit-testing framework) for creating tests on your code.
• Lutz Roeder’s .NET Reflector is a class browser and decompiler that can examine an assembly and show you just about all of its secrets.
• NDoc (code documentation tool) will automatically generate documentation for your code using reflection to examine the assembly and using the XML generated from your C# XML comments.

There are others great tools, and not only for .NET. As always, a quick search away.

Finalizing, there’s so much I’ve left out, but I want to reinforce the idea of Simplicity. Writing code to make you look clever isn’t a good idea. Even if you are all that clever, don’t try to create obfuscated code, making to many in only on row of code. This seems something good, but it completely costs you when you face the inability to quickly fix a bug in it. The point here, is that we shouldn’t make code even less comprehensible. The programmer should apply some skills of code refactoring. There are others ways of ending on Worse than Failure.

I would also recommend you to read Paul Stovell post “We are what we repeatedly code”.

Happy coding!

Introducing Microsoft Surface
30 May 2007 in Microsoft & Tech | Comments (1)

Microsoft announce was indeed its new Microsoft Surface (old PlayTable or ‘Millan’).

The Microsoft Surface, is a table that integrates a 30-inch display that allows one or more simultaneous users to interact directly with images on the screen. Users can paint with their fingers, move and resize items like photographs, and manipulate content—all without touching a mouse or a keyboard.

Visit their official website to watch a showcase of this technology.

You can also watch the 18-minute interview with Mark Bolger on Channel 10 to see a great demonstration.

The object recognition is simple awesome. The feeling that will actually be able to use this at retail locations in the coming months makes it even more real.

If you want to know more, check out the press release and executive Q&A. For historical purposes, you might even enjoy watching the Channel 9 video interview with Stewart Tansley and Andy Wilson from August, 2005, where he shows off a “touchlight” prototype.

The need to Change the Way we Program
30 May 2007 in Programming | Comments (1)

Now a days companies like Intel and AMD, responsible for almost every desktop computer processor, are facing a new challenge.

As processors speed are now becoming impossible to improve, chip makers start to build ever increasing multi-core systems. From dual (2), quad (4) to hundreds of cores, this recent new type of processors is here to stay. Programmer have to start giving it some attention.

A big percentage of software, from Operative Systems to Commercial Applications, still don’t benefit from parallelism properly.

Intel fellow Shekhar Borkar said recently: “The software has to also start following Moore’s law, Software has to double the amount of parallelism that it can support every two years.”.

Amdahl’s Law, a principle that holds that there is only so much parallelism that programs can incorporate before they hit some inherently serial task, is going to be a challenge most software companies will have to face.

Microsoft already acknowledge: “We do now face the challenge of figuring out how to move, I’ll say, the whole programming ecosystem of personal computing up to a new level where they can reliably construct large-scale applications that are distributed, highly concurrent, and able to utilize all this computing power, that is probably the single most disruptive thing that we will have done in the last 20 or 30 years.”.

Microsoft is already planning its next Windows to handle the amount of processing cores that will become standard in a near future.

Programmers should start to use more, and benefit, from threading. Although almost every language supports this paradigm, Intel released several months ago some tools (Windows and Linux) to help in this matter:

• Intel Threading Building Blocks – C++ Extension to ease the process of writing parallel routines, or threads, within an application
• Intel Thread Checker – reduces time to market for threaded applications by speeding up the development process.
• Thread Profiler – helps you understand the structure of threaded applications and maximize their performance.

Its up to the programmer to learn, change and benefit from it.

 ”For every software (company) that doesn’t buy this, there is another that will look at it as an opportunity,” Borkar said.