Older blog entries for johnnyb (starting at number 33)

The best interview question I've ever come up with for a programmer is asking them about their favorite programming language. The following questions work very well: What is your favorite programming language and why? What is your favorite feature of that language? In what way could that language be improved? What is your least-favorite language you've had to work with? Why was it your least-favorite? The point is not to judge them on their language preferences, but instead to determine if they can think analytically about the tools they use. A programmer's main tool is his programming language, and if he is not exposed to a wide variety and does not understand them in-depth, then you shouldn't hire him. Hiring people who understand what they do and why they do it is essential. Too many projects have people who only know one way - the way they were originally tought. No matter what way this is, this is a bad situation. You need programmers who have a depth of knowledge, not people who can only copy things from books and hold on the line for support to answer questions.

I sent the following message to Nicholas Petreley on my thoughts on GNOME:

If you're interested, these are the things that attracted me to GNOME:

1 - Try to do it the right way first. KDE seems to try to get it done first, and then make it the right way later. This makes them polished earlier, but I imagine you will start to see GNOME expand in many ways that KDE can't when it gets to that point. It's kind of like Linux - start with a sound, if perhaps rough, base, and expand from there.

2 - Non-GUI cooperation. Many of the pieces of GNOME can be used in non-GUI applications. GLIB, ORBit2, even pieces of Bonobo are fundamentally separated from their GUI parts. This is characteristic of good library design, and also increases the utility of the platform to developers, since the skills are not bound to GUI-based applications.

3 - CORBA. This is an instance of #1. CORBA is an excellent, robust platform for distributed object communications. It is also not-hard. Those who claim so have probably not tried. It takes all of two hours to learn the basics, and everything comes easily after that.

4 - libglade. This is one kick-butt feature. It allows user-interfaces to be loaded from XML files. This allows nondevelopers to work on interface issues. GLADE has not matured to the point where this is really useful, but it has wonderful potential.

5 - Ultra-customizability - I haven't used KDE in a while, so it might have gained on GNOME in this, but the configurability is awesome. The ability to have multiple panes going every which way is great. The only thing that I miss is KDE's ability to do Mac-like menus :(

6 - Use of the actual language. QT depends on that horrid MOC to compile C++. If C++ wasn't a horrid enough language already, they had to go and put a preprocessor on it. Makes me want to run away screaming.

Of course, GNOME has a few things that drive me buggy -

1 - Bonobo. Many parts of Bonobo are well-written. However, there are many parts that are taken from Microsoft (like GUIDs) that are totally stupid. Interfaces should be identified with text strings that include vendor-strings. Also, it appears that they implemented argument marshalling on top of CORBA, which already does marshalling. They do this to avoid making the poor developer learn CORBA, which is a terrible goal. Keeping developers stupid is not a good goal. Also, they implemented a service for finding servers, when there is already a well defined CORBA trading service for this purpose. Ugh. They seem to re-implement the CORBA architecture in several places.

2 - GLADE. This could be an excellent tool. It only takes one more feature to make it great. That is to add a few hooks for minor source-code generation. Specifically, for the Python side, to allow it to auto-create Python classes that will create new widgets on instantiation, and also have skeleton methods for any signal handlers that are defined. This would make programming this environment stupidly easy.

3 - An immersive book on application development. Most current books ignore the issues that make GNOME programming more than just advanced GTK programming. Things like integrating Bonobo, Session management, Accessibility, Gnome-VFS integration, Nautilus integration, printing, configuration, sound, i18n, and scrollkeeper. Basically, taking an app and adding each piece. It doesn't need to go in-depth, but just show how each one works togehter. Unfortunately, the "mother tome" (GGAD) seems to want to delve into the murky depths of GDK - for which I don't have the faintest clue why an application developer would care. Anyway, this one item would help developers out immensely. It needs to immerse the developer in how development is done, not go in depth on any one subject. That's what API references are for.

Anyway, that's my 2c

A rant on Zombie processes.

I am really tired of so many people who are in top levels of support not knowing jack squat about what a zombie process is. System administrators, DBAs, Sun support staff, and so many others are completely clueless about what a zombie process is.

A zombie process is a process that has terminated, but has not been "waited" on by its parent. wait() is the call that the parent process uses to collect status information about the child. When a process dies, exits, whatever, it has status information that can be collected. The operating system keeps it in the process table as a zombie process so it retains it's records, and it just waits there until it's parent calls wait().

So, what do you do about zombies? Well, they aren't really a problem unless you have a lot of them. In that case, any linear scan over the process table is going to start taking a lot of time. Usually, the reason for them is that the parent isn't set up to handle the SIGCHLD signal correctly (this is the signal sent to the parent when a child dies, so it knows it needs to call wait() when it has a chance). You can't kill a zombie process because it's already dead. However, you can kill off all of the zombie processes parents until it finds one that will wait() for it. Eventually, it will get to the init() process, and the init process doesn't do hardly anything except call wait() continually, so then the zombie will go away.

So many support people have told me the only way to get rid of zombies is to reboot. Ack! What are these, former Windows admins?

And then the other day, I called Fujitsu Global Services because we had a process that we could not kill that was taking up 25% of CPU time. They transferred me to Sun support, who said it was a zombie process. AHHHH!!!!!!!!!!! Zombies don't use CPU time, because they are not running. Eventually, I showed them where in the process table it said it was active, and they finally believed me. Why doesn't Sun support know what a zombie process is!!!???

Anyway, I have run into so many people who should know better that know jack squat about what a zombie process is, that it is really, really irritating me.

I'm waiting for a good GUI to do XML publishing. I'd write one myself - I have a pretty clear idea of what needs to be done - but I lack the time at this point.

What I want is this - be able to edit my documents as a tree (I don't want ANY tags to be just plain text), but also inline some of the tags (just do a superscript with the tag name). So, for example, the tree on the left would expand out book/chapter/sect1 and maybe para, but things like emphasis and productname would be inside the text itself. Double-clicking on them would bring up the properties.

In addition, there would be a pane to modify the style sheet. By default this would be CSS, but you could, if you were an advanced user, translate the CSS style sheet to DSSSL, where more advanced processing could be done.

In addition, the DSSSL implementation would include hooks to read Processing Instructions (I don't know why these aren't used more - the br tag should have been replaced by a processing instruction in XHTML but for some reason it wasn't).

Finally, there would be a preview pane that you could switch to (or view interactively) which would show what the final output would look like.

Anyway, I use docbook constantly (see the book I'm writing at http://www.eskimo.com/~johnnyb/computers/Programmi ngGroundUp/ ), but I think a GUI interface would do wonders for the XML publishing market, because the separation of the content generation verses the typesetting is just an amazingly useful feature.

Plus, openjade uses TeX, which produces awesome-looking documents.

Added a few updates to the book, but mostly minor edits. Hopefully I'll have another big block of time to write soon before baby #2 comes along!

Updated my chapter on functions in my book. I covered most of the C calling convention, and am now to the point where I need to update my section on recursive functions.

I've been thinking a lot about meta-information. I've been perusing standards such as RDF, thinking about how to apply them functionally. A lot of the work has been largely theoretical, with a lot of the people aiming toward making computers sentient beings. Not quite, but almost.

Anyway, I've been thinking of practical uses of metadata repositories and RDF-like things.

I've come to the conclusion that GNOME needs to incorporate meta-data into it's API and GUI, and doing so will enable it's users to combine information like no other system.

Let's start with the basics. Let's say I'm running a project. I want to know all of the information that has come in for this project in the last 3 weeks. Current tools only let me query the filesystem. However, if applications were allowed to store metadata centrally, a user could search information within emails, files, their calendar, and any other tool that supported metadata. The user simply has to tag (or set up rules to autotag) information that comes in as relating to the project, and then if they need to search for such information, they can do it all from one place.

Anyway, I've got some more ideas on this, and I will post them as I have time.

Did some more work on my book. Started the "Optimization" and "Robust Programming" chapters. If anyone has any good things they want to say to newbies on these points, please let me know.

I need to work some more on the files chapter, but I'm having trouble doing so without completely overwhelming the reader.

Okay, got the new version of the book uploaded. Take a peak at http://www.eskimo.com/~johnnyb/computers/ProgrammingGroundUp/. It has all of the chapters I will include at least mentioned.

The one thing I wanted to do, but don't think I'll have enough space to is an introduction to object-oriented assembly language programming. However, if this book sells well, I might follow it up with "Data Structures from the Ground Up" which includes object-oriented programming.

Any suggestions are welcome. Let me know if this is something you would be willing to pay for in "real book" form. I'm thinking about setting the price at $39.95. Anyway, take a read and let me know what you think!

Working on my book. I should have an updated PDF out soon. I decided to put a basic chapter on memory at the beginning since it is so basic to everything done on the computer. Originally I was going to try to introduce it a piece at time as the example programs came across them, but decided the issues were too overreaching to not just present at the beginning. Hopefully, it will be a short enough chapter that noone will mind waiting for the real code.

In addition, I am looking into self-publishing options. I found a place called Gorham Printing (http://www.gorhamprinting.com/) which seems to have good rates since I'm not going to need any services besides printing. I'm just at a total loss as to how many to run. I'd like to run the first one as small as 25, but that's too few to get enough reviewers. Anyway, 100 is likely. That should get to all the reviewers I want, plus have a few to sell. The only problem I see is turnaround time for reprintings. I don't want to delay orders, but I don't want to overinvest, either. Probably going to charge $39.95.

If anyone has done this before, please let me know what you think!