Skip to main content

Posts

Showing posts from August, 2005

Accomodating the Client

Working out how far to go to accomodate the client's needs. Despite my talk about how I have "fired" the industrial client, I have been working with them over the past three weeks on certain issues that they are having with the VB 6/SQL Server systems I helped to build. This support has been for free. It is becoming the scenario that I didn't want to get into-- having to support their system because the project champions at the client don't have enough technical competence to support the users, and the IT department is unwilling to support the application because "something better" is coming along soon. Despite my desire to wriggle free from this client, I can't, after all, just throw them overboard; I don't see that as being the responsible thing to do. I have also committed to helping them with the application that interfaces with the tool controllers, but I have made it clear that that application needs to be written in C++, in order to a...

The Never-ending Battle

Hints at market share for Windows and Linux. In the wake of the attack of the Zotob worm, I saw a chart from Netcraft that tracked the uptime of Fortune 100 web servers over the previous 24 hours. Apparently there was no effect from Zotob among the Fortune 100, as the server that had the most downtime was running Sun Solaris, and that might have been taken down for maintenance. Zotob seemed to cause more trouble on the intranets of several media companies, as CNN reported on Zotob as if it were some cyber-Armageddon. As it turned out, CNN's LAN just got hit especially hard. Looking over the Netcraft chart is enlightening. In addition to uptimes and other network-related statistics, the operating system of each site is also listed. The dominant OS in the Fortune 100 is not Windows, but... Solaris. Solaris runs on 42 sites, Windows Server runs on 25 of the sites, Linux on 17, another flavor of Unix runs 5 sites, and 10 sites have an "unknown" operating system. My gu...

Back to the Future

What can Lisp teach us about the future of programming? For a while, Slashdot was a favorite web hangout of mine, and I racked up probably close to 100 posts. My attention to that favored web site of geekdom was interrupted two years ago by my mother's illness and decline, as well as by my concentration on several dev projects that took up a lot of what had been my spare time. Now that I am off my last project and have a little time, I have been visiting with Slashdot again. A visit to the front page of Slashdot the other day is leading to an examination by me of-- of all things-- Lisp. The story that led up to this was a link to an article written by Simeon Simeonov, who, I believe, was the author of the Cold Fusion web scripting language. He discussed how he thought that "Rich Internet Applications" were the way of the future, and how "Composite applications"-- mixing HTML with server-side code and database access-- is not the right programming model, bu...

In The Trenches

Undertaking the task of converting a Visual Basic application to Python/C/C++. I have undertaken the task of dusting off a VB application I delivered to a client about 2 years ago and converting it to Python and C/C++. You might rightfully conclude from my previous blog entries that I am leaning toward Python/C and C++/LAMP as my development platform of choice. I do have a more favorable view of Python than Java or .NET, and I am just driven by curiosity about Python and C/C++ and what I am missing from my education about programming and systems design by having been stuck on VB 6 for the past 3 1/2 years. So, yesterday, I started authoring a document about the application I am porting to Python/C/C++/MySQL. The application currently has 29 different GUI modules (I will avoid the use of the word "form", *ahem*), which might be reduced to about 26 or fewer GUI classes through code reuse. According to my document, the design and creation of the database in MySQL will come f...

.NET: Separating the Hype From Reality

The .NET Framework is not the latest in application frameworks and tools from Microsoft. Windows application frameworks have been evolving continuously over the past 10 to 15 years. First, there was the Windows application programming interface (API), functions that were called from C that hooked into parts of the operating system that allowed you to do different things with Windows. Then there was Object Linking and Embedding (OLE), which allowed your application to use objects and incorporate them or link to them in both Visual Basic and C/C++. Later iterations of OLE have been known as ActiveX or COM (the Component Object Model). With the increasing use of the Internet, another extension of COM and OLE, called the Distributed Component Object Model (DCOM), allowed for the use of object linking and embedding over a distributed network computing architecture. In a lot of ways, these application interfaces have been built upon one another. OLE is built upon the Windows API, COM is...

The Case For (or Against) Java

Java is a robust, full-featured environment, but I am not sure it is the framework for me. At one point in 2002, when I was caught up in the idea that I had to make a choice between .NET and Java as the next platform to array my programming skills around, I might have been inclined to choose Java over .NET. A lot of negative sentiment about .NET was whipped up by conspiracy theorists who were concerned with what .NET was really about. A lot of these people were from the open source software camp, and were convinced that .NET was yet another attempt by Microsoft to take over the Internet and to drive Linux and any other operating system alternative out of existence, so that Microsoft could have a monopoly on computing. These fears have largely turned out to be unfounded, as Windows and .NET did not take over the world. .NET's adoption has been stalled by the unwillingness of a lot of enterprises to install the .NET framework on their machines. Microsoft has bundled .NET into S...

Evaluating the Candidates

Exploring The Philosophy Behind Application Frameworks In the past, when I have undertaken an exploration of what programming toolsets I will use when I "grow up", I have always evaluated them on the merits of what they promise they will deliver. I saw this as a useful exercise a few years ago when I felt like I would soon have to make a choice between Microsoft's .NET, Sun's Java, or something else. What I decided I wanted to use was "something else". It's what I called the "PyLJAM" platform-- Python, Linux, Java, Apache, and MySQL. This is not too different from the "LAMP" model used for web application development-- Linux, Apache, MySQL, and PHP/Perl/Python. The major differences in my forumulation are the focus on Python as the best scripting language tool I know of, and the inclusion of Java as a heavier-duty framework to enable remoting and other capabilities not available in Python. It was three years ago that I made that...

From Toys to Tools

Programming Languages that insulate the developer from the underlying API may not be the best choice. Following on the heels of my last blog entry from earlier today, about software projects: the reason that the environment where I was made such an important difference is that in the last couple of weeks, I was attempting to write code that did some low-level stuff that I had never written before. Specifically, I was trying to create a server with Visual Basic that used the Winsock API to listen on a socket for data from tool controllers that are located on an assembly line. I chose this approach because it would seem to be the best way to create a server for a non-PC device. However, I am afraid I did not succeed in writing code that used Winsock. I think it listened for a bit and then would hang up. What frustrated me is the lack of documentation of the Winsock API for VB 6. There were no "complete" code examples that I could find, specifically, of how to use select() o...

How Not To Run a Software Project

I have just finished a project with a client, a major industrial company. It was a situation where you might say that I "fired" the client. The reason I essentially fired the client is because of the nature of the working environment and the politics of the situation. I know, you might say that these are common reasons for consultants to end a project. I think it's worth highlighting how internal politics and a lousy environment can be killer to software projects. I am (still) a VB6/SQL Server programmer/consultant. This was a client where I worked on two such projects, and I might have had the chance to build more of them if things had worked out. The first problem was the IT department. I mean, not just the place, but the people. This was an industrial plant where I was working, after all, and it was not the swankiest in terms of offices and facility. I was on the factory floor many times, to install software, to check out a situation where the application appe...