Navigation: Page 1 | Page 2 | Page 3 | Page 4 | Page 5 | Page 6 | Page 7

January 02, 2004

Growing old with code

One thing about knowing more about any subject is that you begin to realize how little you actually know. In this case, I am talking about software development. As a corrolary to this, you continually learn from those who know more or who have more experience. On that note, here are a couple of articles from "Thinking in C++" 's Bruce Eckel:
The Zen of Python, part 2, The Browser as a Desktop UI(My Comments).

January 01, 2004

Resolution: personal projects

Well here we are, a new year again -- may it be much better for us technical types than the last one. This is my first ever article on Hoang's web site and I guess introductions are in order. My name is Sonny; I'm a mid- to senior-level software engineer with very good software development skills, and I learned my professional habits from Hewlett-Packard's old PC-based server division (acronym was NSD -- Network Server Division, became VS -- Volume Servers, your fearless leader Hoang worked there for a few months). Although I've dabbled in the realm of software solution architecture both personally and professionally I feel "this isn't really my bag, baby" to use a line from the Austin Powers movies, and I definitely prefer the interaction and responsibilities I found on the engineering teams.

Now then, back to the topic at hand: New Year's Resolutions. It's strange but every year I come back to the same one which I didn't seem to complete to my satisfaction the previous year: developing software meant for my own personal enjoyment. This past year I came closer than ever, and even built up my multi-user virtual world. Turns out it's just a room rather than a world and compared to modern multiplayer videogames it's a dog, but I'm pretty happy with it considering I was the sole contributor to the project. There are few formal documents for this project which unfortunately led to less than spectacular results even after the third revision, but for the most part I had fun building it.

This year I think I'll throw in a variation: developing projects for my own personal enjoyment. The distinction I'm making involves forcing myself to look beyond the software development itself and actually writing up the formal documents and having written goals that will ground my expectations. I seriously doubt that I'll get any more enjoyment out of the projects I build, but if I ever questioned the need for distinct requirements documents or engineering reference specifications this last project gave me the answer. In order to have presentable software (that's the point of much of my recent work: "See how clever I am? Wouldn't I be a great addition to your team?") I need to use habits I formed during my years of professional experience which I've conveniently avoided this past year.

Anyway, I hope to contribute some thoughts to Jotsite as part of my penance for my wild coding frenzy of this past year. I'm a bit of a techno-weenie though so if I ever go off in the weeds just whack me with a comment. Happy New Year!

November 26, 2003

Code Lifetime

You would never believe it but computer programs have a life of its own.  Of course, when it is doing its job correctly, we really don't care.  When it breaks or requires improvements, that is when we notice it and look into its design again.  I am making some more improvements on the New York Times headlines.  (if you haven't used the service, check it out).  The last time changes were needed was 5 or 6 months ago.  I barely remember the control flow, which was written more than a year ago.  Studying it again reminds me of the times that I worked on it.  In this sense, its lifetime give me the ability to reflect upon my own.

October 26, 2003

Disappearing CodeVizor

I have been hunting for a coding tool that I have used a long time ago.  The tool allows you to construct a class hierarchy of large C++ frameworks and renders it visually in a chart.  If you have ever printed out the MFC class hierarchy chart, you would know how useful it is.  When I was working with MFC, pasting that chart on the wall was quite a typical thing to do.  After having dealt with many companies C++ code bases, I used to have to draw the charts by hand as I study the code.  Later on, I found a tool called CodeVizor which allowed me to print out their hierarchy chart. This chart was like a map when you deal with large code bases.

As it turned out, I needed CodeVizor again this weekend.  Unfortunately I no longer have the software since it has been almost half a decade since I bought it.  I went hunting for it on the internet.  Googling kept bringing me to dead-ends.  After some internet detective work, I think I may have found traces of what happened.  It used to be sold by a company named iftech (which was where I bought my original copy).  I think they sold the product to a company called MutekMutek took possesion and distributed for a while then changed its name to Identity SoftwareIdentity now don't sell such a product.  Somehow in the midst of all that change, CodeVizor ceased to exist.  What a shame because the product had a singular function which was sorely needed.

Dear reader... do you know of an alternative to such a tool?  I made a posting on Joel's discussion site but there wasn't much of a response.

October 22, 2003

High Tech Meltdown

I see a trend steam-rolling across the US in a big way.  Since high-tech jobs are overseas in tremendous amounts, work in this area is very commoditized.  Technology work is no longer cool-and-high-paying.  It is just cheap, difficult to find, and you can't earn a living with it.  College students realize this.  The Denver Post has just written about it this past weekend.  One of the primary reasons students go to college is so that they can find a living wage paying job once they graduate.  Majors in engineering and high-technology no longer hold this promise.  In fact, it may be the opposite: you might do worse than had you applied yourself to a fast food chain from the start.

The government stepped in to protect American farmers through import taxes and farming subsidies when its own workers jobs were at risk.  This protected American-made goods from the rock bottom prices of a world-wide economy.  For the past three years, what has the government done for the high-tech industry?  Not only did it not protect high-tech work, but every move it made actually commoditized high-tech work to the greatest extent.  When it raised the H1-B limit levels, hi-tech work became cheaper.  Now that off-shoring work is a natural thing that every company does, the government lowers the H1-B levels.  What will this achieve now that it is no longer profitable  for foreign workers to come to the US for work?  In the meanwhile, the sum of these actions have added to the sorry state of the US economy.  There is even more long-term harm to be done when the educational institutions no longer find reasons to promote studies in the engineering and computing arena.  I fear that it may be too little too late when the government finally recognizes this trend.

October 09, 2003

People vs.Tools

I am writing this down in order to share a good article on common-sense. Coding Smart: People vs.Tools. This is from a developer at WindRiver Systems, probably an old-school type of person. The article rings true because today we have a plethora of tools ranging from good, bad, and everything in between. What is lacking is experience, wisdom, and plain ole business common-sense. These aspects are unfortunately considered worthless compared to the cool, new-fangled, glitsy tools that arrive on the scene.

August 29, 2003

C++ Overiding versus Overloading

I had an occasion to revisit C++ and MFC recently.  A topic came up of differentiating between Overiding and Overloading.  Previously, I have used Overiding extensively to overide base class methods which were declared virtual.  In code, this is the typical usage that you would normally see.  With Overloading, the most recent recollection is Overloading of operators.  Some examples are ( =, [the equal operator], > [greater than], etc...).  Ok, that's not clear enough of how they are different so I hit the books.

My answer:
  • when Overiding applies, the entire method signature must be the same.  The method signature would be the return type, method name, and all its parameters in the proper sequence.   In order for Overiding to happen, everything must match.  Typically, a superclass method would overide its subclass method.

  • Overloading just means that the method name of a class is the same.  The same class can contain two or more methods of the same name but with different parameters or return types.  Overloading can help simplify the usage of complicated APIs if only a certain number of parameters were used frequently.

July 08, 2003

Social Software

Here are more of Clay Shirky's thoughts on social software.
A Group is its own worst enemy. The internet is here to stay and programmers are beginning to see the effectiveness their creation can have upon users. It behooves the program writer to understand more clearly how social interactions occur and what they can do to further facilitate it.

Navigation: Page 1 | Page 2 | Page 3 | Page 4 | Page 5 | Page 6 | Page 7