Yesterday I had the privilege of attending a Naturalization Ceremony for a close friend of mine. There were over 1000 new citizens taking the oath during this ceremony. The ceremony was interesting and a bit heartwarming. It is amazing how much some people will go through just to become part of our great country. I am truly gratefully that I was invited to attend his ceremony. During the ceremony a slide was shown of past immigrants taking the oath. It really opened my eyes to what makes this country great. The idea that we are not a distinct religion, race, or ethnic background, but rather a group of individuals with a common faith that we are united by our individuality is what really makes this a great nation. If you every have the chance to attend a Naturalization Ceremony I would strongly urge you to do so, as it is a true experience of the American way.

If you are using Ext Javascript Library, you are probably familar with the Ext.onReady() function. This is where you should put all of your initialzation code. According to the ext api documentation: "Fires when the document is ready (before onload and before images are loaded)." So you use this to ensure that all of the dom elements are loaded and available to the browser. This prevents you from gettting errors by attempting to refernece something the browswer has not loaded. This is really cool. But what happens when you need multiple independant functions to execute when ext is "ready"? For example you have a custom tag that defines a user search control, and you want to place that on any page regardless if there are other ext components on the same page. Well as it turns out, the onReady() function does nothing more than regeister your function to be called when Ext is Ready. This means you can register as many functions to execute when onReady fires. This is really handy as it allows you to seperate your controls and package them up nice and neat as customtags. Think of it this way, it simply creates an array of fucntions to call when the onReady method fires. Since this is an array the order of execution is the order in which the fucntions were added.

I am attending a SQL Server 2005 class, and have already learned a few new things. First of which is what SQL server does when you execute T-SQL commands. I would presume that it takes the command, interprets it and then persists the data to memory, writes the trans log, and eventually persist the memory to disk. Well this is not the case! From what I understand, the first thing it does after interpreting the commands, is write the instruction set to the transaction log. it then plays the transaction log back to apply to the db in memory. The last step would be to persist the in memory db to disk. This is pretty neat to know and kinda makes sense. The trans log is used for point in time recovery thus it makes perfect sense to write to this first. Another reason this is important information to know is because it has an impact on how you would setup a certain kinda of trigger (more on that later). This peek into how SQL server works under the hood is good to know, as all sorts of things make sense now. This explains several aspects of database maintenance planning and the importance of the trans log. Before I thought it was a simple standard log of what went on. Now I understand that the trans log is the actual working file for SQL Server. The trans log is basically a recorded macro file. This means that you can do "playback" from the trans log thus its importance in point in time recovery. Cool stuff!!