Find your next scenic drive!

August 25, 2004

Productivity is Tools...

Over at Java Pro, Peter Varhol takes a look at What Makes Developers Productive, and his conclusion is none other than tools.

The article does not really go into what tools will make developers productive (he promises to evaluate some soon), but it is an interesting read, as it focuses on some misconceptions of developer productivity, such as the concept that a productive developer will be 100% productive in any environment, doing any job. In reality, the quality will probably sustain, but if the interest is not there, the productivity will diminish. Furthermore, education may form a foundation, but it does not correlate to productive developers. Peter implies that this is generally a management issue, though.

On the other hand, however, Peter also mentions that tools are simply an extension of one's skills. As such, not all developers will improve their productivity with the same tools. The example that he gives is that a carpenter with a hammer will not produce the same quality as he would, and that a part of this is practice and experience. Without the right tools, I have to find other ways of accomplishing tasks, which usually takes me longer to do than it would if I had the proper tools.

Peter finishes off by stating that there is no way to really pick people for an organization; you really have to pick the people that are sufficiently skilled for the position, but also can grow with your organization.

August 23, 2004

Disconnected Tools in a Connected World...

Over the weekend, it was mentioned on Slashdot that Microsoft is planning a Web-based Office Suite [Slashdot discussion]. While I welcome their initiative, there has been little focus on how IBM has a similar plan. In either case, this reopens (if ever closed, that is) the software subscription model that has been proposed many times before.

The entire software world is really being flipped around right about now. We have people like Joel On Software that argues that Web-based applications are not as rich as desktop applications, but I think the gap is really getting closer, especially with technologies like Java and WebForms 2.0.

But aside from the richness of the experience, the real difference is deployment. With web-based deployment, most of the changes are instantaneous, and for the most part (and in successful deployments), the user is completely oblivious to the change.

Traditional software deployment, on the other hand, is different; when you release a piece of software, you have to wait for users to purchase it (or download it, in the case of Open Source and free applications). Unfortunately, the migration to the latest version of software is not always quick, such as deployment within large corporations that need to install the software on millions of computers, and deal with any issues that appear. As another example, according to this, users are still using Netscape 3.x and 4.x today, and Netscape is a free download (not to fail to mention that Mozilla and FireFox are likewise free). Of course, some advocate older software is better, for both security and bloat issues, but there comes a time where older software is just too hard to support, as is the case right now with Netscape 4. The other reason to go with traditional deployment is that you do not have online access.

And then there is the road in between: Java Web Start. It is amazing technology that is unfortunately not used that much. In this model, the software is cached directly on your computer and executed there. When you startup the application and you are on-line, it polls the server that you got the software from to see if there are updates, and if so, it redownloads them. For example, I occasionally use Gentleware's Poseidon via Java Web Start, and when Poseidon 2.5 was announced earlier this month (a lot of great improvements, BTW), I got the latest version the next time I started it up. Java Web Start reminds me a bit of the Coda Filesystem in this regard, but I do not see why it is not used more.

Does this deployment issue make any difference for end-users? I am not sure that it really does; if you talk to kids about computers, many of them will not really realize what is actually installed on the computer and what is on the web. If you think about this for a little while, this is really analogous to the difference between a hard drive and RAM. Sure these details are important at a low-level, but at a higher level, as long as it works smoothly, does Mom really need to understand the difference between the hard drive and RAM? I do not think this distinguishment is really important, and I think many of our users feel the same. The important factor is that it is smooth and works.

In summary, we live in a very connected world, but the majority of our software is still disconnected, both in the schemes that they are deployed and used. Major issues that are effecting software today such as security violations would be better served by a connected model, like the web and Java Web Start, in which updates are continuous and users are, for the most part, oblivious to the changes.

August 22, 2004

The Dijkstra QuickSort...

About two years ago, a colleague was developing a kernel driver; all of his tests were running great, until a kernel panic happened on a reboot. After investigating it for a while, it turned out that the driver was using the QuickSort algorithm, and it ran out of stack space. While it is sometimes easier to find another algorithm, sometimes it is just as easy to unroll your recursion, and the QuickSort algorithm is an easy one to unroll.

First, let's start by considering a a standard QuickSort algorithm, such as from Data Structures and Algorithms in C by Mark Allan Weiss (which is also on Algorithms and Data Structures Version 2 CD-ROM). I have implemented a class in Java that implements a basic case, called RecursiveQuickSort (for convenience, it derives from QuickSort). There is not a lot of fancy things going on. The algorithm selects a pivot point, swapping some elements whilst it is there, and then recurses.

Class Diagram of the QuickSort classes

One of the easiest ways to remove the recursion is to use a technique similar to that employed by Dijkstra's unweighted shortest-path algorithm. By creating a queue of the quickSort() parameters, the algorithm can simply be unrolled, as I have done in DijkstraQuickSort. As Java does not have a Queue class in 1.4 (there is a generic one in 1.5), I had to implement a very simple Queue class using a List.

The core algorithm is essentially just wrapped in the queue manipulation algorithm that comes from the Dijkstra algorithm. Of course, while this is incredibly simple, this does beg the question of whether allocating a Queue on the heap is more efficient some function calls on the stack, but this really depends on your environment. If you have limited heap also, you may want to consider another algorithm. But in the IRIX kernel, we had ample memory available to us, so this solution worked quite nicely.

August 21, 2004

Where are my interfaces???

As many of you are probably aware, the C++ Standard is presently being revised, lovingly referred to as C++0x; Herb Sutter has mentioned the topic a few times during the last two years in CUJ. One topic that I haven't seen expressively described for consideration is that of interfaces. While C++ does not explicitly define syntax for interfaces, you can generally implement interfaces via abstract base classes, but as Peter Coad warns in Java Design, “in C++, both concepts are expressed with a single syntax blurring the distinction between these very different mechanisms.”

What Peter is talking about is that interfaces are generally implemented in C++ as classes; these classes should only have methods defined, however, this is not enforced by the language. Of course, there are methods of implementing proper interfaces in C++, such as David Abrahams's template-based solution published in CUJ's September 2004 issue in an article by Christopher Diggins entitled “C++ with Interfaces.” But while this is a very interesting fashion to implement interfaces, it requires a substantial declaration that is not as convenient as a Java or IDL interface.

Conceptually, an interface defines the set of methods that a class implements; it does not define any member variables or a default implementation. From a design perspective, this provides maximum flexibility, as any object that implements that interface (the set of methods) can be utilized. Such design, when done properly, allows for extensibility.

Peter Coad's words are right, though; it is hard to tell to difference between an interface and an abstract class in C++, but it is equally hard to determine when a set of functions forms an interface and when that set of functions forms a class. While abstract classes provide a simple solution, interfaces provides a more flexible and extensible implementation. In the aforementioned book, Peter Coad provides us with a simple way to determine when to use classes and when to use interfaces; for each relationship between classes, Peter recommends that we ask whether that relationship is specific to those two classes, or if any object that implements a specific interface would be allowed to be used. While this advice is sound, I still believe that you really need to see interfaces in action before you can fully realize their power. Consider the following class design:

Communication class, with a derived SerialCommunication and CorbaCommunication class

In this class diagram, we see an abstract Communication class that defines a few abstract methods methods, and two derived classes, SerialCommunication and CorbaCommunication. As the SerialCommunication class is intended to communicate to something via a serial communications port, its mapping is a one-to-one mapping to the abstract class. But in the case of the CorbaCommunication class, this is not really as clear. While the server side of this class could correlate directly to a serial communication object directly, it does not necessarily have to; it could simply append and read from a file on disk.

In this particular case, a user of the Communication object does not require more an the above interface, and as such, an interface can provide more flexibility than a class.

But why is this and why am I bothering to talk about this? Well, later in the same September 2004 CUJ issue, Herb Sutter and Jim Hyslop talk about containers in their Conversions Column (#51 to be specific), and specifically mention that typedef std::list<int> ListType and iterators can be used to minimize the amount of code to change when changing the container type (in the article, they convert the container from a list to a vector). But why should we go through all this mess?

Each Java container class implements the java.util.Collection interface, in which changing a container is as simple as changing the assignment where the container is created. In C++, this is not that easy, even with the two above suggestions from Herb and Jim. For example, Item 44 of Effective STL reminds us to prefer the member functions to algorithms with similar names, or more specifically, if you have a std::set, you should prefer using the member function set.find() to std::find(). As such, when changing a container from a Set to a Vector, for example, you must go through the code to ensure that either you are using the most optimum code for that specific container, and you are using code that compiles. Both cases can be rather painstaking exercises. With Java, however, the Container interface ensures that I have a contains() method implemented that is the most probably the best choice for whichever container that I utilize (it should be noted that to be used in C++, it would require a templatized interface).

While they could have used an abstract base class to depict a container, the designers elected against it, for probably one the reasons that Chris mentions either in the aforementioned article or on his C++ Proposal for Interfaces. Some of the reasons that are mentioned are performance-related, and this probably had the most bearing on the design decision. Never the less, if the decision had been to create a common interface to all these classes, the entire issue could be moot.

While many object-oriented languages support interfaces (such as Java, SmallTalk, and C#), C++ does not yet enforce true interfaces, blurring the definition between an interface and an empty abstract class. While I have not heard anything about it, I hope that true interfaces will be part of the next C++ standard.

August 19, 2004

Multicast Sockets...

I have recently purchased Multicast Sockets: Practical Guide for Programmers by David Makosfske and Kevin Almeroth, and it is a good book on multicast development.

In Using Multiple Vendor's ORBs with Name Service, I showed a simple multicast implementation in C++, C#, and Java. This book is an extension of this, and also implements a full interface for C, C#, and Java. The C++ not implemented, but would be easily implemented. I find the C# bit especially amusing, in that it actually states that C# is pronounced C-Sharp. I would be rather surprised that developers today are unaware of C#. In the C# section, they also discuss silliness of the UdpClient class, but not as harsh as my first exposure to C#.

While Unix Network Programming: Volume 1--Third Edition provides you with a fast overview of multicasting, this book goes a little more in depth. It discusses, for example, SSM at length, whereas the second edition of UNP was published prior to SSM and the third edition only mentions the functionality. That being said, however, I was a little surprised that the Multicast Sockets did not talk more about IPv6 and Chapter 2 does not even implemented IPv6 support, whereas UNP does this quite nicely.

The book primarily focuses on multicast applications as a method of streaming video, audio, and data like UDPCast, but it is important to realize that the concepts in this book can be used for all kinds of things, such as the discovery of the CORBA nameserver as previously mentioned. As the book is targeted towards developers, the authors state that there are details that are left out that are not important for developers; I would have discussed a little bit more about some applications for multicasts to get developers thinking where they can use this important technology.

UNP does not go into elaborate detail about some of the techniques surrounding multicasting, but Multicast Sockets goes into a little more detail. It discusses, for example, the history of multicasting, some problems relating to multicasting, and some methods for dealing with reachability, scalability, and congestion. One quote mentioned when dealing with congestion that I have not seen in a while has been the Internet Robustness Principle, which states “Be liberal in what you accept and conservative in what you send.”

While the book has a lot of great information, the programs developed in the book is a multicast-specific ping application and an mrouted-type application. While these applications do not seem to be the best examples of multicasting, with multicast-based ping application, they highlight the issues of reachability, scalability, and dealing with congestion. Likewise, the mrouted application seems redundant, except for the fact that commercially-developed applications would need such a utility to be able to route multicasts reliably over the Internet.

If you are going to work with multicasts and really want to know what it is about, I would recommend that you get Multicast Sockets: Practical Guide for Programmers.

Earlier Entries

<  12  13  14  15  16  17  18  19  20  21  22  >


Recent Posts