Overview of Graphical User Interfaces
GUIs (graphic user interfaces) are very popular for computers nowadays. Very rarely will you find a program that doesn’t have some sort of graphical interface to use it. Most non-graphical programs will be found on Unix-like operating systems; even then, those programs are usually older ones where the programmer didn’t want (or see the need) for a graphical interface. > more <

I’ve started my hobby programming again. As some of you may know, I learned the Python programming language a few years ago because I wanted to make an online role playing game based on the movie Aliens. That dream slowly faded as I realized I didn’t have the skills to do it nor did I have the time to devote to gaining those skills. > more <

Bittorrent is an alternative to other peer-to-peer networks, such as Limewire. Peer-to-peer (P2P) is a way of distributing files between users, rather than downloading directly from a central server. This offloads the overhead of file distribution from organizations and moves it to the customers, making it cheaper to provide software files. > more <

There are several things you can do to ensure you get fast downloads when using the Bittorrent P2P network. Most client software has a good help file; my personal choice is Transmission. Here are a few things to consider when setting up your bittorrent software. > more <

On the Revolution Systems blog, the author has a good, common sense approach to making source code more programmer friendly: use better names and be consistent.

Though this is kind of like a “duh” moment, it’s amazing how frequently these practices are ignored. I’ve looked at a lot of source code that was simply horrible because the variable names were concise to the point of being worthless; for example, $tobj could be “temp object”, “time object”, or even “total observational bone joint”. You get the idea.

Alternatively, I’ve also seen code that had an object named something like “Group.classObject.Frame.Widget1.VariableTimer.CountdownToNextEvent”. Even using auto tools like in Visual Studio, it’s still a pain in the butt to write out a name like that every time.

Consistency is another big item. There always seems to be a push to standardize things, especially at my current shop. But even with all the SOPs and policies, I still haven’t actually seen anything discussing variable naming conventions, commenting standards, or even how source code should be put into the code repository. I think part of this is because we rely on the configuration manager to handle things like these; just give the code to the CM and he’ll take care of the logistics.

But what happens when he’s not around and you have to do it yourself? How do you train new people? What about audits or showing senior management how work is accomplished? Standards are made for a reason. They make life easier for everyone.

Found via Slashdot, some professors at NYU have written an article in a software engineering journal about the hazards of teaching students Java as their first programming language. It’s very enlightening, especially when they talk about the advantages other languages have to offer for problem solving. They also talk about how CS, as a discipline, is declining since students aren’t learning the fundamentals needed to actually solve problems; all they know how to do is fit the right part into the project and hope it works. When it doesn’t, they are at a loss to deal with it.

Here’s a quote from the article:

Because of its popularity in the context of Web applications and the ease with which beginners can produce graphical programs, Java has become the most widely used language in introductory programming courses. We consider this to be a misguided attempt to make programming more fun, perhaps in reaction to the drop in CS enrollments that followed the dot-com bust. What we observed at New York University is that the Java programming courses did not prepare our students for the first course in systems, much less for more advanced ones. Students found it hard to write programs that did not have a graphic interface, had no feeling for the relationship between the source program and what the hardware would actually do, and (most damaging) did not understand the semantics of pointers at all, which made the use of C in systems programming very challenging.

It is worth noting that the authors do have an interest in the Ada programming language, being part of AdaCore Inc.  Obviously they make a stand for learning Ada, so there is some bias to be expected. However, some of the ideas coincide with what I’ve learned over the years, especially having taken Java as my first programming course.

Personally, I think I learned more when I taught myself Python. It was the first time I actually understood OOP even though I “learned” it through Java and C++. I guess ultimately it’s whatever continued learning you do that makes you better. School is designed to make you “well rounded” and expose you to different ideas. Learning what’s needed to actually excel in your chosen field is left up to you.