Category Archives: Papers

A Watch – from an OOP perspective

Posted on by

A watch might be one of the most common types of objects, but it remains also one of the earliest pieces of human craftmanship to show an extreme level of complexity, all contained in a small amount of space. Since the late 1700s, artisan watchmakers in Switzerland and elsewhere have shown their pride and skills creating watches called “Grande Complications”, containing thousands of individual parts and performing incredible functions:

The most complicated watch ever made, known in watch enthusiasts’ circles as “The Ultimate Watch,” is Patek Philippe’s “Calibre 89. The incredibly precise operation of 1728 parts in this really ultimate masterpiece of watchmaking allows to perform no less than 33 (thirty-three!) complicated functions, among them a correction for the 400-year-rule, an Easter date indication, a star chart, a tourbillon, a perpetual calendar, a sidereal time indication, and, and, and … This watch was sold in 1989 for the nice round sum of about four million Swiss francs.”

(Ozdoba, 2005)

(Source: CNN.com, 2005)

More information about the “Calibre 89″ can be found here and in the Patek Philippe Museum website.

However, the same watchmakers that made these fine pieces were also aware of the basic information that their creations were to provide: time. As such, their watches remained extremely easy to use, and they set up the basic standard for analog watches, in such timeless designs that the latest Swatch models show the same basic layout and functionality.

The underlying concept is the very same used in today’s object-oriented abstraction and encapsulation. Even Apple uses the idea of the watch to show this characteristic:

All programming languages provide devices that help express abstractions. In essence, these devices are ways of grouping implementation details, hiding them, and giving them, at least to some extent, a common interface—much as a mechanical object separates its interface from its implementation, as illustrated in Figure 2-1.

(Source: Apple Developer Connection, 2006)

In this article I will provide my view about how different OOP concepts apply to a real-life object such as a watch, in all its forms. Continue reading →

Basic vs. Digest

Posted on by

In the series of highly boring posts ;) here’s another one; in this case, a simple explanation of two different authentication protocols available in the HTTP standard.

HTTP Basic Authentication Protocol

This is the simplest HTTP Authentication protocol available:

  1. The browser sends a request to a protected resource: GET /index.html
  2. The server looks for the “Authenticated” header in the request; since it does not find it, it replies back with a response with the 401 code (“Unauthorized”). The response contains a “WWW-Authenticate” header, with the value “Basic”. This response is called a “challenge”, and it also contains a “realm” text, which describes the protected resource in clear text (the “realm” is shown in the pop-up window that usually appears for you to type your password when this protocol is used).
  3. The browser creates a new request GET /index.html that contains an HTTP_AUTHORIZATION header, whose value is the word “Basic” followed by the ‘username:password’ string encoded in base 64. This algorithm is a two-way algorithm: you can retrieve the username and password from the base 64-encoded string.
  4. The server receives this response, and since base 64 is a two-way algorithm, it compares the MD5 (or SHA1) password hash to the one stored in the database. If they are the same, the request is processed. Otherwise, the user gets a 401 again.

Continue reading →

About Operating Systems, Abstractions and APIs

Posted on by

Introduction

Charles Petzold, in its book “Code”, states the following:

In theory, application programs are supposed to access the hardware of the computer only through the interfaces provided by the operating system. But many application programmers who dealt with small computer operating systems of the 1970s and early 1980s often bypassed the operating system, particularly in dealing with the video display. Programs that directly wrote bytes into video display memory ran faster than programs that didn’t. Indeed, for some applications – such as those that needed to display graphics on the video display – the operating system was totally inadequate. What many programmers liked most about MS-DOS was that it ‘stayed out of the way’ and let programmers write programs as fast as the hardware allowed.

(Charles Petzold, “Code”, pages 332 & 333)

This paragraph shows the state of things during the MS-DOS & early Windows versions timeframe (from late 1970s until 2000 approximately). During this time, programmers could directly access computer memory, bypassing the APIs offered by the operating system, and thus having total control of the hardware.

This shows two different trends in computer programming, one that respects the functionality offered by the operating system, and another that bypasses it. There are advantages and disadvantages to each approach, and the following paragraphs shows some of them. Continue reading →

How to test software security?

Posted on by

Howard and LeBlanc give a very complete answer to this question in their classic “Writing Secure Code” book:

Most testing is about proving that some feature works as specified in the functional specifications. If the feature deviates from its specification, a bug is filed, the bug is usually fixed, and the updated feature is retested. Testing security is often about checking that some feature appears to fail. What I mean is this: security testing involves demonstrating that the tester cannot spoof another user’s identity, that the tester cannot tamper with data, that enough evidence is collected to help mitigate repudiation issues, that the tester cannot view data he should not have access to, that the tester cannot deny service to other users, and that the tester cannot gain more privileges through malicious use of the product. As you can see, most security testing is about proving that defensive mechanisms work correctly, rather than proving that feature functionality works. In fact, part of security testing is to make the application being tested perform more tasks than it was designed to do. Think about it: code has a security flaw when it fulfills the attacker’s request, and no application should carry out an attacker’s bidding.

(Howard & LeBlanc, 2003, page 568). Continue reading →

Design by Contract

Posted on by

Introduction

Even if Design by Contract is a trademark (Eiffel Software, 2007) the idea behind it is the more general one of “defensive programming”. As software developers, we often concentrate our efforts in the main code of the application, which is the interesting part, and that provides the realization of the use cases identified during the early phases of the project.

My opinion is that defensive programming techniques lead to more secure, stable, and less bug-prone code, and that they require less documentation, since the resulting code is more “self-documenting”. Moreover, I will describe in this paper language-independent techniques, that can be used in different situations and systems, that are somehow similar to the Eiffel approach.

Contract Continue reading →

Browsers’ Multiple Connection Settings

Posted on by

Introduction

I’m not such a “power user” when it comes to web browsing, and having good connectivity both at home and at work helps forgetting about tweaking the maximum number of TCP connections in my web browser. However, I can think of a two cases where the establishment of multiple connections might bring great value to the power user: first, multiple file downloads. Being able to download several files at once might be really helpful in some situations. Secondly, in the case of complex web pages. When web pages contain different elements, the required download time goes up (which is often the case: images, sound, video, Java applets, Flash animations, JavaScript files, stylesheets, etc., are ubiquitous nowadays).

In this article I will provide an overview of multiple connection availability in some Mac browsers, and also provide some tips for Internet Explorer for Windows, in the context of the HTTP RFC. Continue reading →

About Mercury TestDirector for Quality Center

Posted on by

Mercury TestDirector for Quality Center is an enterprise-class solution, recognized as one of the most complete and integrated software suites geared towards the management of testing- and quality-related activities. Mercury Interactive, the company behind TestDirector, was bought by Hewlett Packard in 2006 for USD 4.5 billion (Wikipedia). TestDirector is used by several important organizations such as Nextel, the United States Navy, NestlĂ©, Qualcomm and Shell (Mercury Website, 2007a). Continue reading →

Web Development == Software Development?

Posted on by

Introduction

I have been developing web applications since 1996, and I still do a fairly large amount of web development nowadays. During these years I have seen some common misconceptions and myths about web development, that ultimately have a direct impact in the usability of the system. I will outline these in this article, providing at the end my opinion on how to achieve a proper QA process.

Web 2.0 Continue reading →