Bjarne StroustrupJuly 18, 2007
Yesterday I had the pleasure of going to hear a talk at uwaterloo by none other than
Bjarne Stroustrup, inventor of the C++ programming language. Hey, cool... he's the top search result on Google if you search for "Bjarne" :) Because C++ is one of the premier programming languages on the planet, used by most large software companies, and favored by many proficient developers, Bjarne's impact on the software world has been pretty huge to say the least. His talk was on C++0x, the next revision of C++, due out hopefully by '09.
As a would be programming language designer, it was utterly fascinating for me to sit there and hear this guy talk about the challenges of revising C++. Frankly, it sounded painful: Wanting to improve the language, but having to be meticulous about not breaking existing code. Talk about hand cuffs. After his talk he took questions, and mine was essentially "As you've said, revising C++ is very difficult because you have to be very careful not to break existing code. Do you think you'll ever invent a new language where you wouldn't be limited by these restrictions"? His answer, not surprisingly, was "No". I have to respect the man: You get the sense that he really does want to do what's best for the community, and in his case, that is improving C++, not starting from scratch and making something new.
Logging business logicJuly 15, 2007
Where would we be without log files? They help users, system administrators, and developers peak under the hood of software. And while developers may have access to debuggers in some cases, avoiding time consuming debugging sessions with good log output is a smart practice.
Something I've learned this year is that it can be very useful to specifically log business logic. More specifically, if you were to create a flow chart for your program's execution consisting of the various steps, decisions, etc, and then translate that into log output, you'd have a representation of what the program is doing. When the program starts behaving in a suspicious way, you compare the log output to the flow chart that you created, and from there you're in a very good place to proceed with either fixing the program or simply explaining why the program is doing what it's doing.
Again, this level of logging should be highly analagous to the business logic / business processes and shouldn't include any trace output from low level functions to confuse the matter. If the logging output is polished enough, a technical support person should be able to read it comfortably. Here's an example:
2007-07-01 02:33:43: Purchase request
2007-07-01 02:33:43: Username: dbigham
2007-07-01 02:33:43: Valid username and password? Yes
2007-07-01 02:33:43: Book ID: 2922882
2007-07-01 02:33:43: Book in stock? Yes
2007-07-01 02:33:43: Valid credit card number? Yes
2007-07-01 02:33:43: Charge credit card
2007-07-01 02:33:45: ERROR: Couldn't connect to billing server
2007-07-01 02:33:45: Abort transaction |
|
Each of the lines with a question mark correspond to a decision point in the flow chart, and items such as "Charge credit card" are analagous to subroutine calls that may have their own flow chart.
The next step is to mark your log output with a unique identifier that represents the transaction/event. For example, the above output could have the text "TRANSID:1892828" put on to each line. With this in place, the log file can be easily parsed into a database and transactions/events can be listed and made searchable on a web page, with the relevant logging output available by click. Furthermore, the error lines can be flagged in the database and presented in an error log, again clickable, so that given an error you can see what was happening at the time.
Silent softwareJuly 11, 2007
I was doing some random googling today and found a software blog called
Silent Software... I haven't been in the habit of reading software blogs because I haven't found any that really caught my attention, but this guy has some great stuff. For example:
  | "Mondrian at Google": Python's inventor Guido van Rossum is at Google. His first project was a tool for code reviews called Mondrian. Described here and in a video. |
| "I was in Southern Ontario last week, and saw some amazing wind energy windmills near Lake Erie near Long Point. These things are massive and dominate the skyline in a war-of-the-worlds sort of way. Thanks to Ian Bigham for the tour -- I took a short movie: video |
Ok, so maybe it was the "Bigham" and "Long Point" references that caught my attention, but regardless, this is a great blog.
older >>
