mrkurt's devblog

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...

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...

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...