Fat Dutch Guy

Lets see how long this lasts

The HD-DVD key. Fighting censorship.

09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Real life project management using Scrum

Dody Gunawinata, founder of Silverkey Technologies, explaining real life project management using Scrum.

Scrum Tuning: Lessons learned from Scrum implementation at Google

Google Tech Talks December 7, 2006 ABSTRACT Adwords introduced a Scrum implementation at Google in small steps with remarkable success. As presented at the Agile 2006 conference this exemplifies a great way to start up Scrum teams. The inventor and Co-Creator of Scrum will use this approach in building the Google Scrum implementation to describe some of the subtle aspects of Scrum along with suggested next steps that can help in distributing and scaling Scrum in a "Googly way".

Scrum et al.

Google Tech Talks September 5, 2006 Ken Schwaber co-developed the Agile process, Scrum. He is a founder of the Agile Alliance and Scrum Alliance, and signatory to the Agile Manifesto. Ken has been a software developer for over thirty years. He is an active advocate and evangelist for Agile processes. ABSTRACT Scrum is an amazingly simple process that causes many, many changes when it is implemented. This seminar presents the basic framework of Scrum and some of the implementation issues associated with it.

Getting Started with Common Lisp, part 2

The first thing that you need to do when getting started with Common Lisp is to choose a Lisp implementation. Lisp has a standard, similar to C++. Choosing a Lisp implementation is similar to choosing a C++ compiler. Like C++ compilers, conformance to the standard varies. For this post I will only discuss Free CL implementations but there are a number of commercial CL implementations. If your lucky enough to be using Linux for development, there are quite a few Free CL implementations. You have the choice of CMUCL, SBCL, CLISP, GCL, and ECL. There are probably more but those are the ones I know of. I chose SBCL because of its speed and because ASDF comes pre-installed. (ASDF is a library management system similar to CPAN.) SBCL can produce standalone executables. If you're stuck running Windows for some reason then your choices are somewhat more limited. There is CLISP, GCL and ECL. Under windows I chose CLISP because of it's standards conformance and because there are a lot of libraries that are known to work with it. It is also very cross platform. It will pretty much run under whatever OS you want. There are also a number of interop libraries for it so you can make use of windows specific features easily. CLISP uses a VM and byte code system, similar to Java, so it is not as fast as some of the other LISPs but it is faster than Java.

Getting Started with Common Lisp, part 1

I've spent the last couple of months learning Lisp. I would say the hardest part about the process has been figuring out how to get a proper development process setup and learning how to install libraries.
Lisp is a significantly different environment than any of the other languages I have learned. It's not the syntax that is the real issue. Once you get used to prefix notation and how the libraries work, you really start to appreciate the language. If you get emacs setup correctly then Lisp syntax is actually easier than the more common languages. The bug hurdle in my adjustment to Lisp was getting used to working with the repl, learning about application images, learning how to work with SLIME and learning the primary library and application management system, which is called ASDF. Once you learn how to install ASDF, getting and installing libraries becomes simple, somewhat like CPAN or Python's easyInstall. The next few posts will be about how I overcame each of these hurdles and learning to appreciate Lisp and the Lisp way.

Lisp in Python

I was browsing through some Lisp sites and came across this cool article. Describes and implements a Lisp interpreter in Python. There are some other cool articles on this site as well.

A nice series of introductory Python articles

This series (Part1, Part2, Part3, Part4 ) articles looks like a nice intro to Python.

Mastering Ajax, Part 2: Make asynchronous requests with JavaScript and Ajax

Part 2 goes into more depth on using XMLHttpRequest. It details some basic uses like error handling and call backs. Nice article.

Read more at www-128.ibm.com/develop...

Mastering Ajax, Part 1: Introduction to Ajax

Yet another excellent Developer Works article. A nice intro to Ajax. Covers the basics of using the XMLHttpRequest object, including cross browser issues.

Read more at www-128.ibm.com/develop...

Another nice Python Tutorial

Nice tutorial. The color scheme is not so hot though.

Discover Python

There is a nice set of introductory Python articles over on Developer works.

Planner Mode for EMACS

I came across Planner mode a couple of weeks ago. It has been working very well for me. It integrates with a variety of other EMACS applications. It is also able to keep track of time spent on a given task, which is handy for a number of uses.
In the past I have used a variety of contact management/calendaring software including Outlook and Evolution but they are big and bulky and get in the way. They are also overly complicated and it is hard to associate notes with a given piece of information.

Useful web site

This site has a lot of interesting articles on a number of different languages.

Very Interesting Lisp Primer

It gives a very nice history and current state of Common Lisp as well as pointers to a lot of additional material. Pascal Costanza's Highly Opinionated Guide to Lisp

Find 'hidden' resources in extension DLL's

While creating your new, nifty grid control for your MFC extension DLL, you put your resources into your MFC extension control. Then when you compile and run your test application, or worse, your production application, it can’t find the controls resources. A worse problem is that it silently uses the wrong resources.

Identifying the problem

The problem is that MFC assumes that all of the applications' resources reside in the main executable. There are two ways to solve this problem. The first method is to let MFC hunt for the correct resource using AfxFindResourceHandle. The second method revolves around treating the extension DLL like a separate resource DLL.

However, there are significant disadvantages to both methods. The main disadvantage with the first method, which uses AfxFindResourceHandle, is that there can’t be any duplicate resource IDs in any of your applications DLL’s. Also, this method is slower.Both occur because AfxFindResourceHandle searches the entire link chain in the application and returns the first module with a matching resource.

The primary disadvantage with the second method is that you have to explicitly get a handle to the target module; and since loading each kind of resource uses different functions, you end up with code that is almost identical for each kind of resource.

Ask MFC politely for the resource

To have MFC do all the heavy lifting, call AfxFindResourceHandle, like this:

HINSTANCE hInst;
HANDLE hIcon;
hInst = AfxFindResourceHandle(MAKEINTRESOURCE(IDI_YOURICONHERE),
RT_GROUP_ICON);
hIcon = FindResource(hInst, MAKEINTRESOURCE(IDI_YOURICONHERE),
RT_GROUP_ICON);

This will work fine--until someone adds an icon with a duplicate ID to the code base. There is one advantage to this method of loading a resource: You don’t have to know which module the resource resides in.

When something can go wrong, it will.

Being a firm believer in Murphy’s Law; I like to be as explicit as possible. So I prefer the second method of loading resources in my extension DLL’s. Although it requires a little more investment upfront, it pays off when your code goes into maintenance mode. Basically, for each kind of resource you use in your extension DLL, you’ll write a function like this:

CString LoadResString(UINT ResID, CString strModuleName)
{
TCHAR szBuffer[256];
//The module handle can be obtained in a variety of ways the
//following is the most
//straight forward
HMODULE mod = ::GetModuleHandle(strModuleName);
ASSERT(mod);
if (!mod){
AfxMessageBox(_T("GetModuleHandle failed in LoadResString."));
RaiseException(1814, 0, 0, NULL);
}
//This is where the resource actually gets loaded and will be
//different in each function
int count = LoadString(mod, ResID, szBuffer, 255);
ASSERT(count);
if (!count){
AfxMessageBox(_T("LoadString failed in LoadResString."));
RaiseException(1814, 0, 0, NULL);
}
CString rslt(szBuffer);
return rslt;
}

MFC extension DLL’s are a nice feature but because of all the legacy code that Microsoft has to support we are stuck with some “interesting” features like this problem with MFC not looking in the extension DLL for resources first. It’s an easy problem to overcome but it can give you a headache the first time you encounter it. It doesn’t help that you have to know what the problem is before you can find the answer in the documentation.

Note: Technically, there is a third method for specifying which module to load resources from. I chose not to examine it in this article because it's an even less explicit than the AfxFindResourceHandle method.

Marking an ActiveX object safe for scripting

I recently ran a cross a problem where I had to create a COM component for use in Internet Exploder. In order to mark component safe for scripting you need to add the following to your Python class.

_reg_catids_ = ["{7DD95801-9882-11CF-9FA9-00AA006C42C4}"]

Now the class won't cause Internet Exporer to prompt for permission to load the component. I wonder why there is such a spyware problem? :0

Event logging the .NET way

Those of you who have used the event logging API are in for a pleasant surprise. In the past, event logging required (comparatively) arduous coding. After creating an executable with specially formatted resources to be used as a message source, you had to register the message source. Then you finally got to write to the event log.

The System.Diagnostics name space contains (among other things) the event logging API. The two classes we'll focus on for reading and writing to the event log in .NET are the EventLog and the EventLogEntry classes.

Write to the event log

Writing to the event log in .NET follows the same basic procedure as using the Win32 API. First, open the event log.

//The period means this machine
EventLog log = new EventLog(“Application”, “.”, “MySource”);

Then write the event:

log.WriteEntry(“Test message”, EventLogEntryType.Information);

Read from the event log

Reading the event log the Win32 way requires you to open the log with the OpenEventLog function and retrieve a handle to the Event Log. Then you have to retrieve the EVENTLOGRECORD structure with the ReadEventLog function.

The EVENTLOGRECORD structure has both static and dynamic fields. In order to access the dynamic fields of the structure such as the message and the source, you have to treat the structure like a byte array. To make things inconsistent, you access the static fields with the dot operator like normal. Although it’s not difficult, it can be error-prone, and if you miscount bytes, you'll get access violations or bad data.

Reading the event log the .NET way is much improved. Instead of dealing with an EVENTLOGRECORD structure, you get to deal with a much safer and easier EventLogEntry class. When you create an EventLog instance pointing at a specific log, the Entries property (which is an instance of the EventLogEntryCollection class) automatically fills with EventLogEntries. You can use the following code to access the Entries collection:

foreach EventLogEntry entry in eventLog.Entries{
    Console.WriteLine(entry.Source);
    Console.WriteLine(entry.Message);
}

Create a custom event log

You can also create a custom event log by calling the static method CreateEventSource of the EventLog class. For example:

//Check to make sure that the source that will
//be associated with the new log doesn’t exist.
//SourceExists is also a static method
if (!EventLog.SourceExists(“MySource”){
    //If MyNewLog does not exist it will be created.
    EventLog.CreateEventSource(“MySource”, “MyNewLog”);
}

As the above code indicates, you can check to see if a source is registered. If the source name already exists, you could overwrite someone else’s source, creating havoc.

Compare the previous code to what you would have to do to create a custom event log with the Win32 API:

1. Create a message file.

2. Compile it using the message compiler.(Be sure to include the created resource into the resources of the message synch DLL or Executable.)

3. Register the message synch (which is about 100 lines of code) in the event system by creating the requisite registry entries.

4. Take a look at the keys under HKLM\System\CurrentControlSet\Services\EventLog in the registry.

5. Open and retrieve a handle to an event log.

6. Now you can write the custom event log.

Conclusion

As you can see, event logging the .NET way is quite easy. The only drawback is that your application has to be running on a version of Windows based on Windows NT. But since Windows XP is the new consumer OS, this issue will soon be moot.

MASTER THE MYSTERIOUS EVENTLOGRECORD

When dealing with the Windows event log, a developer usually only wants to write events to the log. The Event Viewer, on the other hand, is good at displaying event log messages and lets you view, sort, or filter these messages from a local or remote machine. However, sometimes it's necessary to read events from the log. For instance, if you're dealing with end users and you want the users to be able to click on an icon and have all relevant event log entries sent to you via e-mail.

OVERVIEW

If you look at the documentation for the event-logging API, it appears that reading entries from the log is as simple as this.

       DWORD nBytesRead, nBytesMin;
       EVENTLOGRECORD record;
       HANDLE hEntry = OpenEventLog( NULL, "Application");
  
       While(ReadEventLog(hEvent, EVENTLOG_SEQUENTIAL_READ |
                          EVENTLOG_FORWARDS_READ,
                          0, &record, sizeof(EVENTLOGRECORD),
                          &nBytesRead, &nBytesMin)){
              //Do something with record
       }

READING AN EVENT

There are a number of problems with the preceding code, which stem from the fact that EVENTLOGRECORD is a dynamic structure. If you look at the documentation for EVENTLOGRECORD, you'll see the following:

typedef struct _EVENTLOGRECORD {
DWORD  Length;
DWORD  Reserved;
DWORD  RecordNumber;
DWORD  TimeGenerated;
DWORD  TimeWritten;
DWORD  EventID;
WORD   EventType;
WORD   NumStrings;
WORD   EventCategory;
WORD   ReservedFlags;
DWORD  ClosingRecordNumber;
DWORD  StringOffset;
DWORD  UserSidLength;
DWORD  UserSidOffset;
DWORD  DataLength;
DWORD  DataOffset;
//
// Then follow:
//
// TCHAR SourceName[]
// TCHAR Computername[]
// SID   UserSid
// TCHAR Strings[]
// BYTE  Data[]
// CHAR  Pad[]
// DWORD Length;
//
} EVENTLOGRECORD, *PEVENTLOGRECORD;

All of the fields in comments are just examples. Yet if you try to do something like this:

     _tcslen(record.SourceName);

you'll get a compile error. All of the fields after DataOffset are one big buffer, and you have to treat it as such to work with it. For instance, to get the length of the SourceName field, you must do the following.

        //precord is declared as a pointer to a byte buffer.
        DWORD length = _tcslen((TCHAR*)precord + 56);

The magic number 56 happens to be the total number of bytes preceding the SourceName field. So if you want to get the value of the ComputerName field, you use the following code:

        DWORD offset = 56 + _tcslen((TCHAR*)precord + 56) + 1;
        //The +1 is for the NULL byte
        DWORD length = _tcslen((TCHAR*)precord + offset)

The other major problem is that there isn't a way to tell how big the EVENTLOGRECORD is ahead of time without attempting to read it. This means you have to call ReadEventLog log twice: the first time with parameters that you know will fail and the second time with the correct parameters. If you look at the last parameter, nBytesMin, this variable will contain the number of bytes necessary to read the requested number of records. If you didn't catch that, you can read multiple records with each call to ReadEventLog. Here's some code that works:

  DWORD nBytesRead = 0;
  DWORD nBytesMin = 0;
  DWORD nBytesToRead = 0;
  BYTE *precord = NULL;
  BYTE fake[1];

  HANDLE hEntry = OpenEventLog( NULL, "Application");


  //This one fails but gives us the event record size
  ReadEventLog(hEvent, EVENTLOG_SEQUENTIAL_READ |
               EVENTLOG_FORWARDS_READ,
               0, fake, 1,&nBytesRead, &nBytesMin);

  nBytesToRead = nBytesMin;
  precord = new BYTE[nBytesToRead];
  ReadEventLog(hEvent, EVENTLOG_SEQUENTIAL_READ |
               EVENTLOG_FORWARDS_READ, 0,
               precord, nBytesToRead, &nBytesRead,
               &nBytesMin);//read one record

Now we extract some fields.

   CString SourceName(precord + 56);
   CString ComputerName(precord + 56 + SourceName.GetLength() + 1);

SUMMARY

Even though the event log API isn't the most difficult to master, it isn't well documented or obvious. Yet once you master the EVENTLOGRECORD structure, it's smooth sailing.