{
Royal Pingdom did an analysis of what "popular" sites are running beneath the hood (as easy as a query at Netcraft). Royal Pingdom reveal themselves as a certain "persona" (yeah, I'll overgeneralize for now) by their choice of sites: Technorati, Meebo, Feedburner and so on.
It probably isn't surprising that most of these sites run on Linux with Apache and MySQL involved somewhere on the back end. I'm surprised (of course I'm not in the LAMP game though) to see a bit of a surge in the use of Lighttpd - a more lightweight serving engine than Apache.
As a developer confined to the realm of Microsoft tools it's a bit disappointing albeit unsurprising. What lies beneath the statistics at Royal Pingdom is something bigger and more crushing: the people that seem to be at the forefront of thinking and building the web don't use our tools. Our tools are the favorite of the commoditized environment of your average big company - less thinking and less innovation.
In part I can see a chicken and egg scenario: people building startups and experimenting need a cheap platform upon which to do so. One doesn't license Windows Server, Visual Studio, SQL Server, and so on with a poor [wo]man's budget when comparable free tools exist. In other words, I would assume that some market economics are behind the choice of platform.
But if you're a person like me in the Microsoft space, perhaps a big part of the frustration of working within an environment that lacks passion and quirky inventiveness is that the birds of a feather live in a different place and use a different technology. Of course I work with a lot of people who are excited and innovative - and beyond my coworkers there are quite a few people pushing the envelope with Microsoft tools. But I'd say in general that a corporate developer has a different set of values and goals than the kind of person who would build at a startup. As time passes I see this less on a "success" angle - most types seem to do well enough for themselves - and more of a clustering of similar people.
The bright spark on Royal Pingdom's list is Alexaholic built buy Ron Hornbaker which follows a pattern I'd like to follow as an ideal - that a person can use Microsoft technology (with which I'm quite familiar) and implement any good idea. Beyond that, there is an advantage to a smaller pool of innovators - there is more room for folks like me who may not have the best ideas in the world, but who are good enough to perhaps take something from the startup/open source space and port it.
}
Monday, February 26, 2007
Monsterbugs: Any silver bullets?
{
A few weeks ago our client began to report errors with our Windows Forms (.NET 2.0) application when she'd retrieve certain records. It was a strange bug that would hang the program for about 60 seconds and then crash without reporting errors. We could reproduce it on the test machine, but in development even while pointing to the same database, everything worked. Perfectly.
I looked in the Event Log and noticed the following error:
So how do you pin something like this down?
My approach was as follows:
// code to load data
MessageBox.Show("Loaded data");
// code to display data
MessageBox.Show("Displayed data");
Our application is not small. The form that displays data contains 3300 lines of non-wizard generated code. Data is loaded from a set of methods in a separate library which itself may have upwards of 3000 lines, not to mention that that library references yet more libraries*... my point here is that it's not a small script to throw a dialog up after each line or call.
In the end I spent about 4 hours stepping through each of the major calls via dialog messages. I couldn't debug since our test machine doesn't have Visual Studio or other debugging tools on it (like all the other machines in their offices).
Although I think we've done a good job breaking the logic into pieces (ie. one method for getting data, one for display that is broken into methods for customizations on each object) it was still difficult to discover.
And in the end, of course, it was something small and subtle: calling the AutoColumnsResize method of a DataGridView can sometimes throw exceptions - because of the recursion of the resizing combined with the paint operation of the Windows Forms application. What was probably most annoying was that it wasn't even my code that was responsible for the hanging exception, it was the framework's inability to recover from an internal exception.
When I first started troubleshooting I thought I should have elaborated more on a "tracing" level in our application - we trace some exceptions but not all to the database. But when I finally found the bug, especially because it wasn't in the code we were responsible for writing, I doubt it would have done more than just save time. A stack trace would probably have helped as well, if caught at the point of the exception. But my big question is whether there are any well trodden techniques for finding and dealing with bugs like this, especially if they are in the framework and not in one's own code. How do you deal with stuff like this, or is it always a slog for which there is not silver bullet?
*I think the design of the application is okay (duh, I'm the one responsible) but it may sound more convoluted in that statement than it actually is. We've got a DataHelper library that is covered by unit tests which does all of our data access at the database level. It runs stored procedures, deals with parameters, and so on. One level of abstraction higher we've got a set of business layer objects for dealing with the entities related to our application: loans, disbursements, checks and so on. The Windows Forms application is what we use to let the user display/enter/modify data. We've got a few additional libraries for tracing, configuration, format, data validation, and Crystal Reports. Not so bad I hope...
}
A few weeks ago our client began to report errors with our Windows Forms (.NET 2.0) application when she'd retrieve certain records. It was a strange bug that would hang the program for about 60 seconds and then crash without reporting errors. We could reproduce it on the test machine, but in development even while pointing to the same database, everything worked. Perfectly.
I looked in the Event Log and noticed the following error:
"Faulting application epicenter.exe, version 1.0.0.0, stamp 45df84bf faulting module kernel32.dll, version 5.2.3790.2756, stamp 44c60f39, debug? 0, fault address 0x00015e02"Really, really helpful stuff. And especially because this wasn't something we could get in development, on any of our boxes, it was confusing. Google searches weren't giving specific answers - the error seemed to general in the realm of .NET 2.0 to make much of -
So how do you pin something like this down?
My approach was as follows:
// code to load data
MessageBox.Show("Loaded data");
// code to display data
MessageBox.Show("Displayed data");
Our application is not small. The form that displays data contains 3300 lines of non-wizard generated code. Data is loaded from a set of methods in a separate library which itself may have upwards of 3000 lines, not to mention that that library references yet more libraries*... my point here is that it's not a small script to throw a dialog up after each line or call.
In the end I spent about 4 hours stepping through each of the major calls via dialog messages. I couldn't debug since our test machine doesn't have Visual Studio or other debugging tools on it (like all the other machines in their offices).
Although I think we've done a good job breaking the logic into pieces (ie. one method for getting data, one for display that is broken into methods for customizations on each object) it was still difficult to discover.
And in the end, of course, it was something small and subtle: calling the AutoColumnsResize method of a DataGridView can sometimes throw exceptions - because of the recursion of the resizing combined with the paint operation of the Windows Forms application. What was probably most annoying was that it wasn't even my code that was responsible for the hanging exception, it was the framework's inability to recover from an internal exception.
When I first started troubleshooting I thought I should have elaborated more on a "tracing" level in our application - we trace some exceptions but not all to the database. But when I finally found the bug, especially because it wasn't in the code we were responsible for writing, I doubt it would have done more than just save time. A stack trace would probably have helped as well, if caught at the point of the exception. But my big question is whether there are any well trodden techniques for finding and dealing with bugs like this, especially if they are in the framework and not in one's own code. How do you deal with stuff like this, or is it always a slog for which there is not silver bullet?
*I think the design of the application is okay (duh, I'm the one responsible) but it may sound more convoluted in that statement than it actually is. We've got a DataHelper library that is covered by unit tests which does all of our data access at the database level. It runs stored procedures, deals with parameters, and so on. One level of abstraction higher we've got a set of business layer objects for dealing with the entities related to our application: loans, disbursements, checks and so on. The Windows Forms application is what we use to let the user display/enter/modify data. We've got a few additional libraries for tracing, configuration, format, data validation, and Crystal Reports. Not so bad I hope...
}
Friday, February 23, 2007
Configuration Ammendment
{
// get calling assembly settings classstring
assemblyName = System.Reflection.Assembly.GetCallingAssembly().FullName;
I had used the above in my previous code sample to retrieve the assembly name before obtaining settings from the config file. It works only if you are attempting to obtain configuration information from a library that is called by an *.exe. But what if you are in a library (*.dll) and you are using another library to read configuration information as I'd planned? The Assembly.GetCallingAssembly().FullName returns the name of the library, which as I mentioned before is not where the Configuration class naturally looks for settings. Using the following modification:
// get calling assembly settings classstring
assemblyName = System.Reflection.Assembly.GetEntryAssembly().FullName;
Ah, much better. A subtlety worth remembering: Assembly.GetCallingAssembly() returns a reference to whatever the caller, whether it's a library or executable whereas Assembly.GetEntryAssembly() will give you the name of an executable responsible for making that first call to the framework.
Interestingly, in an ASP.NET 2.0 application where the runtime is processing libraries directly, Assembly.GetEntryAssembly() returns a null.
}
// get calling assembly settings classstring
assemblyName = System.Reflection.Assembly.GetCallingAssembly().FullName;
I had used the above in my previous code sample to retrieve the assembly name before obtaining settings from the config file. It works only if you are attempting to obtain configuration information from a library that is called by an *.exe. But what if you are in a library (*.dll) and you are using another library to read configuration information as I'd planned? The Assembly.GetCallingAssembly().FullName returns the name of the library, which as I mentioned before is not where the Configuration class naturally looks for settings. Using the following modification:
// get calling assembly settings classstring
assemblyName = System.Reflection.Assembly.GetEntryAssembly().FullName;
Ah, much better. A subtlety worth remembering: Assembly.GetCallingAssembly() returns a reference to whatever the caller, whether it's a library or executable whereas Assembly.GetEntryAssembly() will give you the name of an executable responsible for making that first call to the framework.
Interestingly, in an ASP.NET 2.0 application where the runtime is processing libraries directly, Assembly.GetEntryAssembly() returns a null.
}
Thursday, February 22, 2007
Settings, Configuration, .NET 2.0
{
A while back I complained about configuration within Windows Forms applications, mostly because I lacked an understanding of the API. I hacked a simple xml file together wherein I could store simple name value pairs that we'd utilize for the application and surprisingly it's been the approach for quite some time.
I've been studying for the Microsoft 70-552 exam which would update my "MCAD" certification to "MCPD." I know, I know, certification is frown upon by so many people who think I should really be reading The Little Schemer to do cool parlor tricks. But this is a case where what I'd said earlier about certification rings true: it probes for weakness and exposes where you "fake it" with hacks without understanding the real structure and purpose of the technology. Case in point, configuration.
In my earlier post, I'd used Configuration.AppSettings which I now know as deprecated. Instead there's a nifty configuration/settings API one can leverage. What I've done here is based very heavily on Chris Sells's Windows Forms 2.0 Programming although I took liberty to modify some of the code to make it more reusable and generic (his intent was to show basics).
The first stop one needs to make is to add a Settings file to the project along with a reference to System.configuration (not sure why configuration is not Configuration).
Underneath the properties node if you "edit" the settings file, it's really a grid that allows you to enter settings with a key, datatype, scope, and value. The scope in here can be either as a user setting or an application setting - it's also possible to write your own section handler and extend the model.
After compiling this is converted into your app.exe.config file - the physical storage of your settings in the xml format well know to config files.
The code for retrieval is still, in my own view, a little verbose but it's easy to develop a simple accessor helper class. Even more slick in the design of the .NET Framework is that class library projects (DLLs) pull configuration settings from their hosted EXE so you the utility code here is from a DLL designed to be referenced and used from any application.
using System;
using System.Collections.Generic;
using System.Text;
using System.Configuration;
namespace SettingsGroperLib
{
public enum SettingType {
userSettings,
applicationSettings
}
public class ConfHelp
{
public static string GetConfSetting(SettingType settingType, string settingKey) {
// obtain current configuration
Configuration currentConfig =
ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
// obtain section utilizing enumeration
ConfigurationSectionGroup group =
currentConfig.GetSectionGroup(settingType.ToString());
// get calling assembly settings class
string assemblyName = System.Reflection.Assembly.GetCallingAssembly().FullName;
// yah, it's ugly, but it works
string friendlyName = assemblyName.Split(',')[0];
// obtain section by combining friendlyname to settings class
ClientSettingsSection section =
(ClientSettingsSection)group.Sections.Get(
String.Format(
"{0}.Properties.Settings",
friendlyName
)
);
// get setting key
SettingElement element =
section.Settings.Get(settingKey);
// return settings value as
return element.Value.ValueXml.FirstChild.Value;
}
}
}
Sorry about the format; you can download a nice formated version here.
It all seems so easy once you take the time. I think the unlearning was a big obstacle for me since working with config files was something I did all the time in .NET 1.x and old habits die hard. Oh yeah, the retrieval:
string test = ConfHelp.GetConfSetting(SettingType.applicationSettings, "DBUrl");
}
A while back I complained about configuration within Windows Forms applications, mostly because I lacked an understanding of the API. I hacked a simple xml file together wherein I could store simple name value pairs that we'd utilize for the application and surprisingly it's been the approach for quite some time.
I've been studying for the Microsoft 70-552 exam which would update my "MCAD" certification to "MCPD." I know, I know, certification is frown upon by so many people who think I should really be reading The Little Schemer to do cool parlor tricks. But this is a case where what I'd said earlier about certification rings true: it probes for weakness and exposes where you "fake it" with hacks without understanding the real structure and purpose of the technology. Case in point, configuration.
In my earlier post, I'd used Configuration.AppSettings which I now know as deprecated. Instead there's a nifty configuration/settings API one can leverage. What I've done here is based very heavily on Chris Sells's Windows Forms 2.0 Programming although I took liberty to modify some of the code to make it more reusable and generic (his intent was to show basics).
The first stop one needs to make is to add a Settings file to the project along with a reference to System.configuration (not sure why configuration is not Configuration).
Underneath the properties node if you "edit" the settings file, it's really a grid that allows you to enter settings with a key, datatype, scope, and value. The scope in here can be either as a user setting or an application setting - it's also possible to write your own section handler and extend the model.
After compiling this is converted into your app.exe.config file - the physical storage of your settings in the xml format well know to config files.
The code for retrieval is still, in my own view, a little verbose but it's easy to develop a simple accessor helper class. Even more slick in the design of the .NET Framework is that class library projects (DLLs) pull configuration settings from their hosted EXE so you the utility code here is from a DLL designed to be referenced and used from any application.
using System;
using System.Collections.Generic;
using System.Text;
using System.Configuration;
namespace SettingsGroperLib
{
public enum SettingType {
userSettings,
applicationSettings
}
public class ConfHelp
{
public static string GetConfSetting(SettingType settingType, string settingKey) {
// obtain current configuration
Configuration currentConfig =
ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
// obtain section utilizing enumeration
ConfigurationSectionGroup group =
currentConfig.GetSectionGroup(settingType.ToString());
// get calling assembly settings class
string assemblyName = System.Reflection.Assembly.GetCallingAssembly().FullName;
// yah, it's ugly, but it works
string friendlyName = assemblyName.Split(',')[0];
// obtain section by combining friendlyname to settings class
ClientSettingsSection section =
(ClientSettingsSection)group.Sections.Get(
String.Format(
"{0}.Properties.Settings",
friendlyName
)
);
// get setting key
SettingElement element =
section.Settings.Get(settingKey);
// return settings value as
return element.Value.ValueXml.FirstChild.Value;
}
}
}
Sorry about the format; you can download a nice formated version here.
It all seems so easy once you take the time. I think the unlearning was a big obstacle for me since working with config files was something I did all the time in .NET 1.x and old habits die hard. Oh yeah, the retrieval:
string test = ConfHelp.GetConfSetting(SettingType.applicationSettings, "DBUrl");
}
Tuesday, February 20, 2007
Monday, February 19, 2007
Top Ten Mistakes of Web Design
{
Jakob Nielsen just updated his list of top ten mistakes a web designer can make. I've got no clout like he does but my number one annoyance in web design is when people work against the browser.
The best example of this in my mind is the back button. On so many projects I've had "issues" submitted related to the use of the back button and had to write code to try to cheat the browser into not allowing its use. But the back button is there for a reason and working against the browser is almost always futile: trying to prevent using backspace, alt+arrow, right clicks, programmable mouse buttons, pasting to multiple browser sessions... at what point do we just allow users to keep their control?
I like apps that tolerate issues related to browser control - they let you do it but when they croak, it's an edge case that they aren't willing to reprogram the entire system for. I wish more people would grok the fact that browsers simply aren't fat clients and they've got to share control.
}
Jakob Nielsen just updated his list of top ten mistakes a web designer can make. I've got no clout like he does but my number one annoyance in web design is when people work against the browser.
The best example of this in my mind is the back button. On so many projects I've had "issues" submitted related to the use of the back button and had to write code to try to cheat the browser into not allowing its use. But the back button is there for a reason and working against the browser is almost always futile: trying to prevent using backspace, alt+arrow, right clicks, programmable mouse buttons, pasting to multiple browser sessions... at what point do we just allow users to keep their control?
I like apps that tolerate issues related to browser control - they let you do it but when they croak, it's an edge case that they aren't willing to reprogram the entire system for. I wish more people would grok the fact that browsers simply aren't fat clients and they've got to share control.
}
Language and Thinking
{
I'm fortunate enough to be sitting in on some training and the ice breaker at the beginning was to say which language one liked the most. Most in the room went with what they use for work, C#, but of course I had to break the flow and say I prefer Perl and Javascript in terms of raw language more than anything at the moment.
Talking about it later I brought up the old Sapir Whorf notion of language affecting thinking and problem solving and it's funny how you have a thought and seems to start jumping out at you all over the place. Tonight I ran into (courtesy of Raganwald) the following quotes regarding that idea:
}
I'm fortunate enough to be sitting in on some training and the ice breaker at the beginning was to say which language one liked the most. Most in the room went with what they use for work, C#, but of course I had to break the flow and say I prefer Perl and Javascript in terms of raw language more than anything at the moment.
Talking about it later I brought up the old Sapir Whorf notion of language affecting thinking and problem solving and it's funny how you have a thought and seems to start jumping out at you all over the place. Tonight I ran into (courtesy of Raganwald) the following quotes regarding that idea:
"The connection between the language in which we think/program and theproblems
and solutions we can imagine is very close. For this reasonrestricting
language features with the intent of eliminating programmer errors is at best
dangerous." - Bjarne Stroustrup
"The very fact that it's possible to write messy programs in Perl isalso what
makes it possible to write programs that are cleaner in Perlthan they could ever
be in a language that attempts to enforcecleanliness. The potential for
greater good goes right along with thepotential for greater evil." - Larry Wall
}
Wednesday, February 14, 2007
Wow
{
Microsoft's Vista Ad - quite a contrast to the Apple commercials. To the degree that commercials evoke a sense of a company's ideals, it's telling of something I've always thought of when comparing Microsoft to others - they are trying to solve harder problems than the home movie or virtual greeting card.
Of course, they could just be playing to my ideals and trying to make money out of it...
}
Microsoft's Vista Ad - quite a contrast to the Apple commercials. To the degree that commercials evoke a sense of a company's ideals, it's telling of something I've always thought of when comparing Microsoft to others - they are trying to solve harder problems than the home movie or virtual greeting card.
Of course, they could just be playing to my ideals and trying to make money out of it...
}
Saturday, February 10, 2007
Vote Hanselminutes
{
I'm just echoing the words of Chris Sells's post to vote for Hanselminutes on Podcast Alley. It's my personal favorite among technical podcasts.
}
I'm just echoing the words of Chris Sells's post to vote for Hanselminutes on Podcast Alley. It's my personal favorite among technical podcasts.
}
Wednesday, February 07, 2007
Queues with SQL Server 2005 Service Broker and C#
{
I recently had to set this up and didn't find all too many resources online. I don't have time for a full commentary but suffices to say this: SQL Server 2005 has some excellent reliable messaging capabilities through what's called Service Broker. If you, like me, are a complete skeptic when it comes to new products, this is what I think of as a compelling feature. In the following example, I'm setting up a queue for FileIDs - assume these are identifiers for files that need to be processed asynchronously. After I created my database in SQL 2005, I opened up the query tool and went ahead with the following TSQL:
-- you can attribute an hour to finding this requirement :(
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Password1';
GO
-- message, contract, queue, service creation
CREATE MESSAGE TYPE FileIDForQueue
VALIDATION = NONE;
GO
CREATE CONTRACT FileQueueContract
(FileIDForQueue SENT BY INITIATOR)
GO
CREATE QUEUE dbo.FileIDReceiverQueue
GO
CREATE QUEUE dbo.FileIDSenderQueue
GO
CREATE SERVICE SenderService
ON QUEUE dbo.FileIDSenderQueue
GO
CREATE SERVICE ReceiverService
ON QUEUE dbo.FileIDReceiverQueue (FileQueueContract)
GO
In order to leverage the queue, I wrote the following stored procedures to enqueue, dequeue, and peek:
/*
STORED PROCEDURE RESPONSIBLE FOR INSERTING A QUEUE ITEM
*/
CREATE PROC spSendFileToQueue
@FileID INT
AS
BEGIN TRANSACTION;
DECLARE @conversationID UNIQUEIDENTIFIER
BEGIN DIALOG CONVERSATION @conversationID
FROM SERVICE SenderService
TO SERVICE 'ReceiverService'
ON CONTRACT FileQueueContract;
SEND ON CONVERSATION @conversationID
MESSAGE TYPE FileIDForQueue(@fileid);
--END CONVERSATION @conversationID;
COMMIT TRANSACTION;
GO
/*
STORED PROCEDURE RESPONSIBLE FOR RETRIEVING QUEUE ITEMS IN FIFO STYLE
*/
CREATE PROC spGetFileFromQueue
@FileID INT OUTPUT
AS
RECEIVE TOP(1) @FileID = CONVERT(INT, message_body) FROM FileIDReceiverQueue
GO
/*
STORED PROCEDURE RESPONSIBLE FOR "PEEKING" INTO QUEUE
*/
CREATE PROC spPeekFileQueue
@FileID INT OUTPUT
AS
SELECT TOP(1) @FileID = CONVERT(INT, message_body) FROM FileIDReceiverQueue
WHERE message_body IS NOT NULL
GO
Now that my stored procedures are in place, I can test in TSQL:
-- to send it to the queue:
spSendFileToQueue 45
-- peek into the queue
DECLARE @F INT
EXEC spPeekFileQueue @FileID=@F OUTPUT
PRINT @F
-- to get it back
DECLARE @F INT
EXEC spGetFileFromQueue @FileID=@F OUTPUT
PRINT @F
From here it's trivial to port the procedure calls to C#:
public static void RunActionProc(string procName, SqlParameter parm) {
SqlParameter[] parms = new SqlParameter[] { parm };
RunActionProc(procName, parms);
}
public static void RunActionProc(string procName, SqlParameter[] parms)
{
SqlCommand co = new SqlCommand(procName, GetConnection(true));
co.CommandType = CommandType.StoredProcedure;
foreach (SqlParameter parm in parms)
{
co.Parameters.Add(parm);
}
co.ExecuteNonQuery();
}
public static void Enqueue(int value)
{
DBHelper.RunActionProc("spSendFileToQueue", new SqlParameter("@FileID", value));
}
public static int Peek(){
SqlParameter fileIdParameter = new SqlParameter("@FileID", SqlDbType.Int);
fileIdParameter.Direction = ParameterDirection.Output;
DBHelper.RunActionProc("spPeekFileQueue", fileIdParameter);
return Convert.ToInt32(fileIdParameter.Value);
}
public static int Dequeue() {
SqlParameter fileIdParameter = new SqlParameter("@FileID", SqlDbType.Int);
fileIdParameter.Direction = ParameterDirection.Output;
DBHelper.RunActionProc("spGetFileFromQueue", fileIdParameter);
return Convert.ToInt32(fileIdParameter.Value);
}
A sample project in C# can be found here.
}
I recently had to set this up and didn't find all too many resources online. I don't have time for a full commentary but suffices to say this: SQL Server 2005 has some excellent reliable messaging capabilities through what's called Service Broker. If you, like me, are a complete skeptic when it comes to new products, this is what I think of as a compelling feature. In the following example, I'm setting up a queue for FileIDs - assume these are identifiers for files that need to be processed asynchronously. After I created my database in SQL 2005, I opened up the query tool and went ahead with the following TSQL:
-- you can attribute an hour to finding this requirement :(
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Password1';
GO
-- message, contract, queue, service creation
CREATE MESSAGE TYPE FileIDForQueue
VALIDATION = NONE;
GO
CREATE CONTRACT FileQueueContract
(FileIDForQueue SENT BY INITIATOR)
GO
CREATE QUEUE dbo.FileIDReceiverQueue
GO
CREATE QUEUE dbo.FileIDSenderQueue
GO
CREATE SERVICE SenderService
ON QUEUE dbo.FileIDSenderQueue
GO
CREATE SERVICE ReceiverService
ON QUEUE dbo.FileIDReceiverQueue (FileQueueContract)
GO
In order to leverage the queue, I wrote the following stored procedures to enqueue, dequeue, and peek:
/*
STORED PROCEDURE RESPONSIBLE FOR INSERTING A QUEUE ITEM
*/
CREATE PROC spSendFileToQueue
@FileID INT
AS
BEGIN TRANSACTION;
DECLARE @conversationID UNIQUEIDENTIFIER
BEGIN DIALOG CONVERSATION @conversationID
FROM SERVICE SenderService
TO SERVICE 'ReceiverService'
ON CONTRACT FileQueueContract;
SEND ON CONVERSATION @conversationID
MESSAGE TYPE FileIDForQueue(@fileid);
--END CONVERSATION @conversationID;
COMMIT TRANSACTION;
GO
/*
STORED PROCEDURE RESPONSIBLE FOR RETRIEVING QUEUE ITEMS IN FIFO STYLE
*/
CREATE PROC spGetFileFromQueue
@FileID INT OUTPUT
AS
RECEIVE TOP(1) @FileID = CONVERT(INT, message_body) FROM FileIDReceiverQueue
GO
/*
STORED PROCEDURE RESPONSIBLE FOR "PEEKING" INTO QUEUE
*/
CREATE PROC spPeekFileQueue
@FileID INT OUTPUT
AS
SELECT TOP(1) @FileID = CONVERT(INT, message_body) FROM FileIDReceiverQueue
WHERE message_body IS NOT NULL
GO
Now that my stored procedures are in place, I can test in TSQL:
-- to send it to the queue:
spSendFileToQueue 45
-- peek into the queue
DECLARE @F INT
EXEC spPeekFileQueue @FileID=@F OUTPUT
PRINT @F
-- to get it back
DECLARE @F INT
EXEC spGetFileFromQueue @FileID=@F OUTPUT
PRINT @F
From here it's trivial to port the procedure calls to C#:
public static void RunActionProc(string procName, SqlParameter parm) {
SqlParameter[] parms = new SqlParameter[] { parm };
RunActionProc(procName, parms);
}
public static void RunActionProc(string procName, SqlParameter[] parms)
{
SqlCommand co = new SqlCommand(procName, GetConnection(true));
co.CommandType = CommandType.StoredProcedure;
foreach (SqlParameter parm in parms)
{
co.Parameters.Add(parm);
}
co.ExecuteNonQuery();
}
public static void Enqueue(int value)
{
DBHelper.RunActionProc("spSendFileToQueue", new SqlParameter("@FileID", value));
}
public static int Peek(){
SqlParameter fileIdParameter = new SqlParameter("@FileID", SqlDbType.Int);
fileIdParameter.Direction = ParameterDirection.Output;
DBHelper.RunActionProc("spPeekFileQueue", fileIdParameter);
return Convert.ToInt32(fileIdParameter.Value);
}
public static int Dequeue() {
SqlParameter fileIdParameter = new SqlParameter("@FileID", SqlDbType.Int);
fileIdParameter.Direction = ParameterDirection.Output;
DBHelper.RunActionProc("spGetFileFromQueue", fileIdParameter);
return Convert.ToInt32(fileIdParameter.Value);
}
A sample project in C# can be found here.
}
Saturday, February 03, 2007
The Future of Programming Languages
{
Imagine being able to pull Anders Hejlsberg, Chief Architect of C#, Herb Sutter, Architect in the C++ language design group, Erik Meijer, Architect in both VB.NET and C# language design, and a programmer's programmer, Brian Beckman into a conference room and have an hour's worth of conversation on programming languages - to hear about composability and functional programming and abstraction from people whose decisions literally shake our world from the top.
This recent video on Channel 9 is just that.
At the end, when they are getting kicked out because someone else is scheduled for the room I can't help but laugh. Guys like Anders Hejlsberg get kicked out of conference rooms too eh? They must be human.
Here are some quotes:
Anders -
"language is like the color of your glasses... "
Beckman -
"Scheme is sort of God's Lisp with all the noise boiled away..."
Meijer -
"By definition you cannot have too much abstraction because abstraction means leaving out the unnecessary detail. So if details are unnecessary you can abstract... sometimes you abstract from necessary details but that isn't true abstraction because you've taken away necessary detail"
}
Imagine being able to pull Anders Hejlsberg, Chief Architect of C#, Herb Sutter, Architect in the C++ language design group, Erik Meijer, Architect in both VB.NET and C# language design, and a programmer's programmer, Brian Beckman into a conference room and have an hour's worth of conversation on programming languages - to hear about composability and functional programming and abstraction from people whose decisions literally shake our world from the top.
This recent video on Channel 9 is just that.
At the end, when they are getting kicked out because someone else is scheduled for the room I can't help but laugh. Guys like Anders Hejlsberg get kicked out of conference rooms too eh? They must be human.
Here are some quotes:
Anders -
"language is like the color of your glasses... "
Beckman -
"Scheme is sort of God's Lisp with all the noise boiled away..."
Meijer -
"By definition you cannot have too much abstraction because abstraction means leaving out the unnecessary detail. So if details are unnecessary you can abstract... sometimes you abstract from necessary details but that isn't true abstraction because you've taken away necessary detail"
}
IDE Distrust
{
Some time back I read Charles Petzold's essay Does Visual Studio Rot the Mind which concerned itself with some of the negative aspects of how our tools drive us rather than us driving our tools. It's not just a handful of occasions where I've been called over to "troubleshoot" when a person's intellisense (or autocompletion) isn't popping up what they are expecting.
But Visual Studio does impress upon you the wrong ideas sometimes.
In this case it will show an error for a missing mime type on a script tag. Granted, this may be some part of XHTML validation but after listening to Douglas Crockford (and also, incidentally, running into it in the Rhino book), I discovered this type attribute isn't leveraged by any existing browsers.
If you give in for the sake of XHTML and supply this attribute, you'll notice that Visual Studio suggests text/javascript which is actually incorrect. It should be application/javascript.
Here is something even more concerning - Visual Studio is suggesting two parameters for a method that actually only requires one (I looked in the Rhino book).
Visual Studio is a great tool, don't get me wrong - as much as I'd love to be an Emacs junkie and do my demonstrations in it while showing off my profficiency, I like how effecient Visual Studio is at allowing me to focus on my code - not my libraries, or my classpath, or anything else.
With that said, it's important to master the tool, as opposed to being mastered by the tool. A healthy amount of distrust seems necessary to get the best out of it.
}
Some time back I read Charles Petzold's essay Does Visual Studio Rot the Mind which concerned itself with some of the negative aspects of how our tools drive us rather than us driving our tools. It's not just a handful of occasions where I've been called over to "troubleshoot" when a person's intellisense (or autocompletion) isn't popping up what they are expecting.
But Visual Studio does impress upon you the wrong ideas sometimes.
In this case it will show an error for a missing mime type on a script tag. Granted, this may be some part of XHTML validation but after listening to Douglas Crockford (and also, incidentally, running into it in the Rhino book), I discovered this type attribute isn't leveraged by any existing browsers.
If you give in for the sake of XHTML and supply this attribute, you'll notice that Visual Studio suggests text/javascript which is actually incorrect. It should be application/javascript.
Here is something even more concerning - Visual Studio is suggesting two parameters for a method that actually only requires one (I looked in the Rhino book).
Visual Studio is a great tool, don't get me wrong - as much as I'd love to be an Emacs junkie and do my demonstrations in it while showing off my profficiency, I like how effecient Visual Studio is at allowing me to focus on my code - not my libraries, or my classpath, or anything else.
With that said, it's important to master the tool, as opposed to being mastered by the tool. A healthy amount of distrust seems necessary to get the best out of it.
}
Thursday, February 01, 2007
Founders At Work
{
I'm looking forward to reading Jessica Livingstone's book, Founders At Work, which consists of interviews with various techie entrepreneurs. Joel Spolsky's interview, however, is available as a freebie and makes for some interesting reading. I've been a Joel "fanboy" for a while but it still impresses me how each time he writes (or comments) at length there's so much truth from which to learn.
There are several other interviews I'm looking forward to reading, particularly Philip Greenspun's on the making (and possibly breaking) of Ars Digita. A few years ago Philip did an interview on IT Conversations that impressed a lot of "lessons learned" upon me.
But back to Joel, the interview is insightful and there are many gleanings on consulting, founding, competition, learning, and making good software.
I'll get to the Woz interview this weekend.
}
I'm looking forward to reading Jessica Livingstone's book, Founders At Work, which consists of interviews with various techie entrepreneurs. Joel Spolsky's interview, however, is available as a freebie and makes for some interesting reading. I've been a Joel "fanboy" for a while but it still impresses me how each time he writes (or comments) at length there's so much truth from which to learn.
There are several other interviews I'm looking forward to reading, particularly Philip Greenspun's on the making (and possibly breaking) of Ars Digita. A few years ago Philip did an interview on IT Conversations that impressed a lot of "lessons learned" upon me.
But back to Joel, the interview is insightful and there are many gleanings on consulting, founding, competition, learning, and making good software.
I'll get to the Woz interview this weekend.
}
Tuesday, January 30, 2007
Are You Good?
{
A good way to get attention in the programming blogs is to draw a distinction between "good" and "mediocre" programmers and allow developers to question whether they can consider themselves "good."
Atwood posts that you're either good or mediocre at programming despite the amount of practice or effort you may decide to put in:
I wonder what it is in a programmer's DNA that leaves them with a self doubt? On the other end of the spectrum there are a lot of popular posts devoted to the topic of making oneself better - I found this old Steve Yegge post as a rebuttle to Atwood; that practice is not only a way to get better, but a necessity of the better programmers.
I have no idea how to categorize myself; I don't dare think of myself as good especially when people like Joel Spolsky can throw tests my way that pretty much leave me gaping and grasping.
But, although the blog post I bothered to take time to write speaks to the contrary, I'm not sure if questioning oneself is very productive. Most programmers I respect out there are unbelievably productive - there doesn't seem to be a lot of time for being paralyzed by self doubt.
Back to practice I go.
}
A good way to get attention in the programming blogs is to draw a distinction between "good" and "mediocre" programmers and allow developers to question whether they can consider themselves "good."
Atwood posts that you're either good or mediocre at programming despite the amount of practice or effort you may decide to put in:
"A mediocre developer can program his or her heart out for four years, but thatJoel Spolsky and a few others seem to use the tactic quite a bit; reeling people in by causing them to question themselves.
won't magically transform them into a good developer. And the good developers
always seem to have a natural knack for the stuff from the very beginning."
I wonder what it is in a programmer's DNA that leaves them with a self doubt? On the other end of the spectrum there are a lot of popular posts devoted to the topic of making oneself better - I found this old Steve Yegge post as a rebuttle to Atwood; that practice is not only a way to get better, but a necessity of the better programmers.
I have no idea how to categorize myself; I don't dare think of myself as good especially when people like Joel Spolsky can throw tests my way that pretty much leave me gaping and grasping.
But, although the blog post I bothered to take time to write speaks to the contrary, I'm not sure if questioning oneself is very productive. Most programmers I respect out there are unbelievably productive - there doesn't seem to be a lot of time for being paralyzed by self doubt.
Back to practice I go.
}
Monday, January 29, 2007
Querystring: Laziness or Design?
{
Mads Kristensen posted about retrieving items from the querystring by a series of checks against nullness (is that a word?) and type values. His starts with:
if(!Request.QueryString["foo"] == null){
// do interesting things
}
Continues with a little more elegance:
if(String.IsNullOrEmpty(Request.QueryString["foo"])){
// do interesting things
}
Finishes with a check on type integrity during the querystring check:
if(!String.IsNullOrEmpty(Request.QueryString["foo"]) &&
Request.QueryString["foo"].length == 5){
// do interesting things
}
I like seeing things like this because it's interesting to look at how someone does something I do all the time with a different twist. I'm a pretty lazy guy, and although I hope to attribute it to the perl affinity in me, I'm not sure if it's really a spade being a spade and I actually am lazy in a bad way.
For most of my projects (except when I'm at a client or somewhere that I need tocopy follow a defined pattern) I usually write a little "helper" class with static methods for this sort of thing:
class Helper{
public static string GetQS(Page page, string key){
return (page.Request[key] ?? String.Empty); // ?? is so slick yo.
}
}
When I'm reading out querystring values, I sometimes read and assign simultaneously:
string foo;
if((foo = Helper.GetQS(this, "foo"))!= String.Empty){
// do interesting things with foo
}
Of course this is a variation on Mad's theme, but one critical difference - a lazy one - is that my gut reaction is to intentionally allow failure on type integrity outside the querystring check. That failure usually invokes a more generic handler related to the operation in question rather than having to decide what happens the moment I know I have a bad querystring value. For example:
string quantity;
if((quantity = Helper.GetQS(this, "quantity"))!=String.Empty){
this.UpdateQuantity(Convert.ToInt32(quantity));
}
My rational is that I can write my exception handler for the operation "UpdateQuantity" rather than the specific querystring item. UpdateQuantity may throw different types of exceptions and I can capture them all in one fell swoop instead of defensively trying to test everything up front.
try{
string quantity;
if((quantity = Helper.GetQS(this, "quantity"))!=String.Empty){
this.UpdateQuantity(Convert.ToInt32(quantity));
}
}
catch(FormatException ex){
// specific exceptions I can of more assistance
}
catch(Exception ex){
// log and inform *shrug*
}
Of course that's lazy. I'd like to think it's lazy in a perl way rather than lazy in a couch potato way. What say you?
}
Mads Kristensen posted about retrieving items from the querystring by a series of checks against nullness (is that a word?) and type values. His starts with:
if(!Request.QueryString["foo"] == null){
// do interesting things
}
Continues with a little more elegance:
if(String.IsNullOrEmpty(Request.QueryString["foo"])){
// do interesting things
}
Finishes with a check on type integrity during the querystring check:
if(!String.IsNullOrEmpty(Request.QueryString["foo"]) &&
Request.QueryString["foo"].length == 5){
// do interesting things
}
I like seeing things like this because it's interesting to look at how someone does something I do all the time with a different twist. I'm a pretty lazy guy, and although I hope to attribute it to the perl affinity in me, I'm not sure if it's really a spade being a spade and I actually am lazy in a bad way.
For most of my projects (except when I'm at a client or somewhere that I need to
class Helper{
public static string GetQS(Page page, string key){
return (page.Request[key] ?? String.Empty); // ?? is so slick yo.
}
}
When I'm reading out querystring values, I sometimes read and assign simultaneously:
string foo;
if((foo = Helper.GetQS(this, "foo"))!= String.Empty){
// do interesting things with foo
}
Of course this is a variation on Mad's theme, but one critical difference - a lazy one - is that my gut reaction is to intentionally allow failure on type integrity outside the querystring check. That failure usually invokes a more generic handler related to the operation in question rather than having to decide what happens the moment I know I have a bad querystring value. For example:
string quantity;
if((quantity = Helper.GetQS(this, "quantity"))!=String.Empty){
this.UpdateQuantity(Convert.ToInt32(quantity));
}
My rational is that I can write my exception handler for the operation "UpdateQuantity" rather than the specific querystring item. UpdateQuantity may throw different types of exceptions and I can capture them all in one fell swoop instead of defensively trying to test everything up front.
try{
string quantity;
if((quantity = Helper.GetQS(this, "quantity"))!=String.Empty){
this.UpdateQuantity(Convert.ToInt32(quantity));
}
}
catch(FormatException ex){
// specific exceptions I can of more assistance
}
catch(Exception ex){
// log and inform *shrug*
}
Of course that's lazy. I'd like to think it's lazy in a perl way rather than lazy in a couch potato way. What say you?
}
Saturday, January 27, 2007
Yahoo Blew It
{
Just finished a Wired piece by Fred Vogelstein on how Yahoo fell behind Google. There's more detail in the tell but in a nutshell it boils down to a comment Joel Spolsky had made on his Venture Voice podcast: non-technical managers and CEOs are the doom of technology companies. Or, in the closing paragraph of Vogelstein's article:
It's a good morality tale and definitely one I see as true in the world around me. Especially as many non-technical people launch "Web 2.0" companies, I wonder how often it will be replayed for those of us with a different, more technical perspective.
But I'm not convinced that Yahoo is out for the count. There are a few things that I think they get right and with a change in approach can really capitalize on:
1. Mail - Yahoo makes my favorite web based mail client. I use the "beta" version of their mail software which was written by the folks from Oddpost. I wonder if they'd turn these guys loose to write some other cool software, like a killer RSS Reader to make Netvibes eat its heart out.
2. Curators - The craze at the moment is over user generated content but a model that I think will still remain profitable is that of having curated content; hiring someone who knows what they are doing to pick out what's interesting for others in a particular domain. Why can't Yahoo take what is done so well on Yahoo Picks and extend that to more specific content? Not overblown CNN style content heaviness, just a small group of people that find a few interesting things and keep the site sparse. What's ironic is that as "user generated" content seems to overtake the web, there is more need for people who can pre-parse it to find what's more special.
3. Developer APIs - One thing that made me happy about Yahoo's Developer Network was that it had to do with pushing out their philosophy and sharing what they standardize well. Their APIs are a bit bulky in my opinion at present, but there are some clever people over there who can really help developers be more productive.
4. Excellent content - Yahoo Movies, Yahoo TV to name a few. I keep going back because they are that useful.
There are more things but I'm an outsider who is simply commenting on what he likes. Yahoo has a lot of smart technical people they don't seem to be listening to. Reading Jeremy Zawodny and Josh Woodward shortly after the release of Google Finance seemed to confirm this sad fact.
Because the one thing about the Wired post that bothered me was that Vogelstein kept going back to the leadership of Yahoo under Terry Semel where I see as big of a problem in Yahoo not being able to leverage its developers for ideas beyond how to implement specifications. Semel's ability to make deals and encourage integration are a part of this, but it seems like it occured at multiple levels of management, not just at the top.
One more thing I can think of helping Yahoo stay relevent in their battle against Google and other web companies: why not buy some of Paul Graham's companies (or other "built to sell" companies that seem like winners)? Forget revenue models, forget integrations - forget all that MBA stuff for a moment. Thinkature (Yahoo anounces Visio modeling mixed with Powerpoint presentability for the future), Snipshot (Yahoo delivers online photo editing and hosting for the masses), Jamglue (Yahoo presents technology to mix/remix and make ringtones)... there are a lot more than these to be sure, but just of the top of my head - represent some ideas that can get people excited. Not only that, the young founders are the types of people who won't stop thinking even after their technology enters a bigger and perhaps more orthodox arena. Money doesn't grow on trees but Yahoo has a lot of resources and a big market capitalization to work with - it only takes one good idea to make the whole thing worth it.
I don't think Yahoo is done by any means. I sincerely hope they have a second life, not necessarily as a victor in a war against Google, but more as a successful web company staying relevant and making people happy.
}
Just finished a Wired piece by Fred Vogelstein on how Yahoo fell behind Google. There's more detail in the tell but in a nutshell it boils down to a comment Joel Spolsky had made on his Venture Voice podcast: non-technical managers and CEOs are the doom of technology companies. Or, in the closing paragraph of Vogelstein's article:
"At Yahoo, the marketers rule, and at Google the engineers rule. And for that,
Yahoo is finally paying the price."
It's a good morality tale and definitely one I see as true in the world around me. Especially as many non-technical people launch "Web 2.0" companies, I wonder how often it will be replayed for those of us with a different, more technical perspective.
But I'm not convinced that Yahoo is out for the count. There are a few things that I think they get right and with a change in approach can really capitalize on:
1. Mail - Yahoo makes my favorite web based mail client. I use the "beta" version of their mail software which was written by the folks from Oddpost. I wonder if they'd turn these guys loose to write some other cool software, like a killer RSS Reader to make Netvibes eat its heart out.
2. Curators - The craze at the moment is over user generated content but a model that I think will still remain profitable is that of having curated content; hiring someone who knows what they are doing to pick out what's interesting for others in a particular domain. Why can't Yahoo take what is done so well on Yahoo Picks and extend that to more specific content? Not overblown CNN style content heaviness, just a small group of people that find a few interesting things and keep the site sparse. What's ironic is that as "user generated" content seems to overtake the web, there is more need for people who can pre-parse it to find what's more special.
3. Developer APIs - One thing that made me happy about Yahoo's Developer Network was that it had to do with pushing out their philosophy and sharing what they standardize well. Their APIs are a bit bulky in my opinion at present, but there are some clever people over there who can really help developers be more productive.
4. Excellent content - Yahoo Movies, Yahoo TV to name a few. I keep going back because they are that useful.
There are more things but I'm an outsider who is simply commenting on what he likes. Yahoo has a lot of smart technical people they don't seem to be listening to. Reading Jeremy Zawodny and Josh Woodward shortly after the release of Google Finance seemed to confirm this sad fact.
Because the one thing about the Wired post that bothered me was that Vogelstein kept going back to the leadership of Yahoo under Terry Semel where I see as big of a problem in Yahoo not being able to leverage its developers for ideas beyond how to implement specifications. Semel's ability to make deals and encourage integration are a part of this, but it seems like it occured at multiple levels of management, not just at the top.
One more thing I can think of helping Yahoo stay relevent in their battle against Google and other web companies: why not buy some of Paul Graham's companies (or other "built to sell" companies that seem like winners)? Forget revenue models, forget integrations - forget all that MBA stuff for a moment. Thinkature (Yahoo anounces Visio modeling mixed with Powerpoint presentability for the future), Snipshot (Yahoo delivers online photo editing and hosting for the masses), Jamglue (Yahoo presents technology to mix/remix and make ringtones)... there are a lot more than these to be sure, but just of the top of my head - represent some ideas that can get people excited. Not only that, the young founders are the types of people who won't stop thinking even after their technology enters a bigger and perhaps more orthodox arena. Money doesn't grow on trees but Yahoo has a lot of resources and a big market capitalization to work with - it only takes one good idea to make the whole thing worth it.
I don't think Yahoo is done by any means. I sincerely hope they have a second life, not necessarily as a victor in a war against Google, but more as a successful web company staying relevant and making people happy.
}
Tuesday, January 23, 2007
view-source, javascript, about:config
{
A while back Aaron offhandedly shows me a slick trick with Firefox when I'm complaining about how it doesn't show namespaces on xml documents: you can use view-source as a protocol to look a website's source code. If you've got Firefox, check it out.
I've been making my way through the 5th edition of the Rhino book and Flanagan shows another technique of using your address bar with a protocol. You can type something like:
javascript:alert("Hello World");
into your address bar and just like that you've got a little play pen for your javascript. You can also extend it to include html that you'd like to render, for example:
javascript:alert("Hello There");<p>Hello</p>
Of course do not forget about:config as a way to configure Firefox. Any more of these goodies?
}
A while back Aaron offhandedly shows me a slick trick with Firefox when I'm complaining about how it doesn't show namespaces on xml documents: you can use view-source as a protocol to look a website's source code. If you've got Firefox, check it out.
I've been making my way through the 5th edition of the Rhino book and Flanagan shows another technique of using your address bar with a protocol. You can type something like:
javascript:alert("Hello World");
into your address bar and just like that you've got a little play pen for your javascript. You can also extend it to include html that you'd like to render, for example:
javascript:alert("Hello There");<p>Hello</p>
Of course do not forget about:config as a way to configure Firefox. Any more of these goodies?
}
Sunday, January 21, 2007
Certification
{
Jeff Atwood posted recently about certification, coming to the following conclusion:
Many of the comments are the predictable reactions to certifications: they suck, people who obtain them don't know anything, they are self taught without certification, those who can't code obtain certifications and so on.
Reading a lot of the comments makes me want to add my own perspective to the fray, as cluttered as it is, because I'm the product of certifications. My own conclusion on certifications doesn't fall far from Atwood's, but because I was and am tied to that world, I reach it by a different means.
My background is what led me to certifications. My degree was in Accounting, and the only company that took a serious look at me in the technology world as I frantically tried to leave the public accounting firm I worked at required them. In fact, during my interview, my interviewer told me that I was one of several candidates who they were considering, and the first of us to obtain a certification would probably get the job. I didn't really know where to start - I had some sparse computer experience from building web pages and working in my university computer lab, but I was limited in doing practical things with computers. I went to my neighborhood bookstore and inspected the shelves, settling upon the biggest book I could find (assuming it had the most content) to study for the Microsoft Networking Essentials exam. I spent my lunch breaks at the accounting firm memorizing differnent network topographies, cables, and protocols.
I failed the exam on my first try, but this was not because I missed anything in the book. I was a fairly good student, and I literally memorized large portions of the book. Rather, I failed because I didn't know how the test would relate to the material I had learned. Once in the "certification game" I understood how people study for the exams (practice exams, looking at exam objectives) and how to look for "keywords" - things that give away the answer to the question.
For that basic networking exam, relating Novel any time I saw IPX/SPX was half the hard work in finding an answer to the question. For example:
Q. You have connected several Novel print servers to your Network but users complain that they do not work. What should you do?
A. Verify that IPX/SPX protocol or client is enabled.
I never failed another certification exam. Well, alright, I failed a VB 6 Enterprise Application Development exam because I'd had a wisdom tooth pulled the day before and was under the influence of painkillers, but I'll pretend that didn't happen.
As the exams got more elaborate, I learned it was very important to know how questions were asked (use practice exams) and where I was weak (exam objectives). The exam objectives would tell you which part of a product you were weak on. For example, I was never very good at answering deployment questions when taking developer exams. Not only was this somewhat difficult (and boring) to simulate, it wasn't something I needed to do very often living primarily in the world of web application development.
Now that I've had some distance in the certification world, my conclusion for people - especially developers - is that people who certify are responsible for learning how to answer questions. Although these questions may be related to their experiences, experience and knowledge are not a sure way of passing an exam. One needs to know how the questions work. Even on exams that involve simulations, understanding what will be needed is critical.
I certified on SQL Server many years ago - I don't remember the exact year - but it was during the SQL Server 7 days. I will probably take the new SQL Server exams but much of this is based on simulations - I know this because a coworker recently passed on of the exams and told me about it. The interesting thing is that I've used SQL Server every day for at least 5 years and prefer to live in TSQL for most of what I do. I'd have to spend some time getting comfortable with the GUI in order to take this exam, but it would not be related to my experience. Even more frustrating - my time looking at the GUI would just be learning to do things I already do.
In this sense I share the frustration that many people have about certifications: ability to answer quiz questions doesn't translate directly into the workings of day to day development. Many of the typical questions even if unknown would be about a 1 minute trip to Google or the documentation.
Here is my "but:" certifications force exposure for the people taking them. I know a lot more about deployment than I would have if I based what I knew on what I was inclined to learn on the job. I know a lot more about networking than most of the people I work with simply because I did have to learn it to be "certified." I'm sure some of my time without certifications would have been spent on personal projects or readings of personal interest, but without discipline some of that reading is of only general benefit. And because certification objectives are very practical (if not boring) they usually result in knowledge that is more focused.
I had a friend who was largely self taught and extremely intelligent. His personal study took him into the world of C++ where he excelled, preferring to spend his time studying Open GL libraries. It's interesting stuff, to be sure, but it's not MFC or the Win32 API. As a result he could make a lot of cool demos, but he wasn't the type of person to write a banking application. He wasn't particularly interested in that but as a thought experiment what if he'd decided to endure some of the boredome and learn how to write MFC with database connectivity? Certification would have forced that exposure which, combined with his aptitude, would have made him quite a developer.
One final note before I give my own conclusion - similar to Atwood's but different enough that I felt compelled to write this. Atwood posts a comment from an older article on certifiction:
I recently realized that there is a little bit more economic activity in certification, not necessarily on the side of the big companies that sponsor them. Many people who have certification use it as a tool to restrict supply and drive up their own "value." For example, many Microsoft trainers are eager to have Microsoft require a "premier certification" in order to teach their coursework. The argument they use officially is that it will ensure that the trainer delivering content is knowledgable but the intersting facet of this argument is that obtaining and maintaining "premier certifications" (many of which have multiple exams) requires considerable effort (and massive opportunity cost - instead of learning the new GUI of SQL Server 2005 a person could be writing, say, a stored procedure generator using SMO). It leads me to believe that most of them know that increasing the amount of time and effort for certification is in the interests of their pockets as much as it keeps people "knowledgeable." I also observe this pattern in my own certification life: when I'm doing project work, which is usually intense and requires a lot of my off hours, I'm never certifying. When I'm between jobs, or if I'm asked to teach a class or do something that requires certification, I sit down and do what's necessary.
So my big conculsion? Everyone has a story of the MCSE who never installed Windows or the "certified" guy who had no practical experience. A lot of the time it's people like me - not disciplined in the work of computers and trying to put something on a resume. In that sense I don't disagree that a certification all by itself is meaningful. I defer to Atwood's comments about showing work that's been done and a track record of personal effort.
But.
Certifications in addition to a person's track record are a good thing to take into consideration. Not only do they show a person putting in some effort beyond work related requirements, it also means they've got some exposure (knowledge-wise) to areas of a technology outside of the context of immediate use.
In the end my apology is biased because I do have certifications. But there's a value to them that most people miss because they have had bad experiences with people that abuse them or try to compensate real experience and/or projects with them.
I'll continue to get certifications as a part of work related requests but I'll never get them again in the context I started with: a guy who loved computers and was trying to get a job and demonstrate to people effort and a little bit of knowledge. As I interview people and present myself I'll present my certifications as that original effort, not necessarily where I am now. I've got projects (day and night) to try to assert my credibility.
}
Jeff Atwood posted recently about certification, coming to the following conclusion:
"I don't believe in certifications. The certification alphabet is no substitute
for a solid portfolio; you should be spending your time building stuff, not
studying for multiple choice tests. But that doesn't mean they're worthless,
either. I don't think certifications get in the way, as long as you can
demonstrate an impressive body of work along with them. "
Many of the comments are the predictable reactions to certifications: they suck, people who obtain them don't know anything, they are self taught without certification, those who can't code obtain certifications and so on.
Reading a lot of the comments makes me want to add my own perspective to the fray, as cluttered as it is, because I'm the product of certifications. My own conclusion on certifications doesn't fall far from Atwood's, but because I was and am tied to that world, I reach it by a different means.
My background is what led me to certifications. My degree was in Accounting, and the only company that took a serious look at me in the technology world as I frantically tried to leave the public accounting firm I worked at required them. In fact, during my interview, my interviewer told me that I was one of several candidates who they were considering, and the first of us to obtain a certification would probably get the job. I didn't really know where to start - I had some sparse computer experience from building web pages and working in my university computer lab, but I was limited in doing practical things with computers. I went to my neighborhood bookstore and inspected the shelves, settling upon the biggest book I could find (assuming it had the most content) to study for the Microsoft Networking Essentials exam. I spent my lunch breaks at the accounting firm memorizing differnent network topographies, cables, and protocols.
I failed the exam on my first try, but this was not because I missed anything in the book. I was a fairly good student, and I literally memorized large portions of the book. Rather, I failed because I didn't know how the test would relate to the material I had learned. Once in the "certification game" I understood how people study for the exams (practice exams, looking at exam objectives) and how to look for "keywords" - things that give away the answer to the question.
For that basic networking exam, relating Novel any time I saw IPX/SPX was half the hard work in finding an answer to the question. For example:
Q. You have connected several Novel print servers to your Network but users complain that they do not work. What should you do?
A. Verify that IPX/SPX protocol or client is enabled.
I never failed another certification exam. Well, alright, I failed a VB 6 Enterprise Application Development exam because I'd had a wisdom tooth pulled the day before and was under the influence of painkillers, but I'll pretend that didn't happen.
As the exams got more elaborate, I learned it was very important to know how questions were asked (use practice exams) and where I was weak (exam objectives). The exam objectives would tell you which part of a product you were weak on. For example, I was never very good at answering deployment questions when taking developer exams. Not only was this somewhat difficult (and boring) to simulate, it wasn't something I needed to do very often living primarily in the world of web application development.
Now that I've had some distance in the certification world, my conclusion for people - especially developers - is that people who certify are responsible for learning how to answer questions. Although these questions may be related to their experiences, experience and knowledge are not a sure way of passing an exam. One needs to know how the questions work. Even on exams that involve simulations, understanding what will be needed is critical.
I certified on SQL Server many years ago - I don't remember the exact year - but it was during the SQL Server 7 days. I will probably take the new SQL Server exams but much of this is based on simulations - I know this because a coworker recently passed on of the exams and told me about it. The interesting thing is that I've used SQL Server every day for at least 5 years and prefer to live in TSQL for most of what I do. I'd have to spend some time getting comfortable with the GUI in order to take this exam, but it would not be related to my experience. Even more frustrating - my time looking at the GUI would just be learning to do things I already do.
In this sense I share the frustration that many people have about certifications: ability to answer quiz questions doesn't translate directly into the workings of day to day development. Many of the typical questions even if unknown would be about a 1 minute trip to Google or the documentation.
Here is my "but:" certifications force exposure for the people taking them. I know a lot more about deployment than I would have if I based what I knew on what I was inclined to learn on the job. I know a lot more about networking than most of the people I work with simply because I did have to learn it to be "certified." I'm sure some of my time without certifications would have been spent on personal projects or readings of personal interest, but without discipline some of that reading is of only general benefit. And because certification objectives are very practical (if not boring) they usually result in knowledge that is more focused.
I had a friend who was largely self taught and extremely intelligent. His personal study took him into the world of C++ where he excelled, preferring to spend his time studying Open GL libraries. It's interesting stuff, to be sure, but it's not MFC or the Win32 API. As a result he could make a lot of cool demos, but he wasn't the type of person to write a banking application. He wasn't particularly interested in that but as a thought experiment what if he'd decided to endure some of the boredome and learn how to write MFC with database connectivity? Certification would have forced that exposure which, combined with his aptitude, would have made him quite a developer.
One final note before I give my own conclusion - similar to Atwood's but different enough that I felt compelled to write this. Atwood posts a comment from an older article on certifiction:
I suggest that we have a perfectly fine selection mechanism at work today;
it's called the market. Some people get hired as software developers and some
people don't. It is a lot more competent than any appointed elite would be and a
lot more ethical.
I recently realized that there is a little bit more economic activity in certification, not necessarily on the side of the big companies that sponsor them. Many people who have certification use it as a tool to restrict supply and drive up their own "value." For example, many Microsoft trainers are eager to have Microsoft require a "premier certification" in order to teach their coursework. The argument they use officially is that it will ensure that the trainer delivering content is knowledgable but the intersting facet of this argument is that obtaining and maintaining "premier certifications" (many of which have multiple exams) requires considerable effort (and massive opportunity cost - instead of learning the new GUI of SQL Server 2005 a person could be writing, say, a stored procedure generator using SMO). It leads me to believe that most of them know that increasing the amount of time and effort for certification is in the interests of their pockets as much as it keeps people "knowledgeable." I also observe this pattern in my own certification life: when I'm doing project work, which is usually intense and requires a lot of my off hours, I'm never certifying. When I'm between jobs, or if I'm asked to teach a class or do something that requires certification, I sit down and do what's necessary.
So my big conculsion? Everyone has a story of the MCSE who never installed Windows or the "certified" guy who had no practical experience. A lot of the time it's people like me - not disciplined in the work of computers and trying to put something on a resume. In that sense I don't disagree that a certification all by itself is meaningful. I defer to Atwood's comments about showing work that's been done and a track record of personal effort.
But.
Certifications in addition to a person's track record are a good thing to take into consideration. Not only do they show a person putting in some effort beyond work related requirements, it also means they've got some exposure (knowledge-wise) to areas of a technology outside of the context of immediate use.
In the end my apology is biased because I do have certifications. But there's a value to them that most people miss because they have had bad experiences with people that abuse them or try to compensate real experience and/or projects with them.
I'll continue to get certifications as a part of work related requests but I'll never get them again in the context I started with: a guy who loved computers and was trying to get a job and demonstrate to people effort and a little bit of knowledge. As I interview people and present myself I'll present my certifications as that original effort, not necessarily where I am now. I've got projects (day and night) to try to assert my credibility.
}
Thursday, January 18, 2007
Stay on Java + Algorithms
{
Because I'm in C# all the time, my Java is passable with effort, but not pristine - like a Norwegian's use of Swedish or a Portuguese person required to use Spanish.
But there's good reasons to hang onto that Java; it seems like Google interviews may require rapid prototyping in the language.
Most algorithms are language agnostic (save the ones that leverage language features (think functional)) but it's also interesting to see that quick deployment of those with optimizations seems to be a part of the process.
}
Because I'm in C# all the time, my Java is passable with effort, but not pristine - like a Norwegian's use of Swedish or a Portuguese person required to use Spanish.
But there's good reasons to hang onto that Java; it seems like Google interviews may require rapid prototyping in the language.
Most algorithms are language agnostic (save the ones that leverage language features (think functional)) but it's also interesting to see that quick deployment of those with optimizations seems to be a part of the process.
}
Saturday, January 13, 2007
Crockford Javascript Presentation
{
I'm excited that next week I'll be in Los Angeles. I got the opportunity, along with some other people from Daktronics, to attend Developmentor training on Biztalk. Tonight I was going to watch a Biztalk presentation from TechEd but got a little sidetracked watching Douglas Crockford's excellent javascript presentation on the DOM.
Although the presentation is about the DOM which a lot of people think they know and understand, Crockford adds a lot of historical and insider information about how browsers work and what implications that has for writing DHTML. Really interesting.
There's a different presentation I was looking for - on javscript's prototype based inheritance, but I'll get to that on a different day.
}
I'm excited that next week I'll be in Los Angeles. I got the opportunity, along with some other people from Daktronics, to attend Developmentor training on Biztalk. Tonight I was going to watch a Biztalk presentation from TechEd but got a little sidetracked watching Douglas Crockford's excellent javascript presentation on the DOM.
Although the presentation is about the DOM which a lot of people think they know and understand, Crockford adds a lot of historical and insider information about how browsers work and what implications that has for writing DHTML. Really interesting.
There's a different presentation I was looking for - on javscript's prototype based inheritance, but I'll get to that on a different day.
}
Subscribe to:
Posts (Atom)
Posts
