I’m about 75% through writing the manuscript for a Sidebar gadget development book. The pre-order page made it to Amazon, so I need to finish it, right?

I’m into some of the more advanced AJAX topics. Since these gadgets are exclusive to Vista, I have to assume that a good chunk of developers interested in them are also using .Net backend web servers. So I’m including a bit about the ASP.NET AJAX framework to save people the trouble of manually writing JavaScript code to build SOAP messages.

At first glance, I was impressed both by the framework and by the extensive effort from Microsoft to make it easy to use. There’s helpful how-to videos on the site that really make it easy to understand. There’s information for adapting the framework for use with other non-MS server-side technologies.

And to top it all off — there’s a full set of pre-built, AJAX-ian web controls called the Control Toolkit that snaps on top of the framework. After seeing the ease of adapting the framework for gadgets, I assumed the controls relied on JS libraries that could be copied out and used inside a Sidebar gadget.

In the end, I discovered that the controls are actually compiled… into a DLL. For a second there, I really thought I had landed into a whole new world of .Net development. A land where community replaced proprietary. A place where building a simple web site didn’t require a 2 gigabyte development suite.

But it’s still the same as it ever was. I can’t easily recommend Microsoft’s AJAX control toolkit for use in their own gadget platform. Somehow the simplicity of plain text HTML and JavaScript code needed to get wrapped up into DLL hell.

Not much to report yet. I flew into Minneapolis this afternoon, shuttled to hotel and checked in.

The welcome reception was very friendly, a good chance to mingle and put some faces to the names in the ColdFusion community. I also got to meet a few new faces — I’m always happy to dish about CF.

After a few drinks, I fear I may have disparaged Asp.NET a bit too much. I’ll try to keep it positive the rest of the conference

There’s lots of ways right now to extend the web outside of a traditional web browser. Whether you call them gadgets or widgets, web-enabled desktop mini-apps can be a powerful way to bridge the divide between your users’ machines and your Internet applications.

With all the gadget platforms out there, it can be tough to sift through the options. But in reality, most of the gadget engines are nothing more than glorified web page renderers. If you know HTML and you’re comfortable with JavaScript, you’re already well on your way to churning out your own custom gadgets.

Read the rest of this entry »

DDJ.com has posted an audio interview with David Streams, Group Program Manager for the Windows Live Team at Microsoft, discussing the current field of gadgets.

Streams touches on a couple interesting topics: plans (or lack thereof) for integration with other gadget platforms, protecting intellectual property, and monetizing gadgets.

The basic gist is that monetizing gadgets at this point would be difficult. Primarily because gadget source is difficult to obscure and even more difficult to wrap within a licensing model. They are much better suited in the commercial world as complementary add-on’s to full-scale applications.

I’m more than a bit disappointed by the InsideMicrosoft blog’s latest round-up of “good” gadgets: Some Good Windows Vista Sidebar Gadgets, Issue 3.

Insanely long title aside, are any of these gadgets really impressive? I need more than simple search to get excited about using desktop gadgets. The latest versions of Firefox and IE both make this type of gadget obsolete with their customizable search bars. Who wants to keep a box open and running constantly on the desktop just to search Amazon?

Gadgets take up valuable pieces of screen real estate. They need to have a seriously compelling interface or piece of functionality to justify keeping one of these things open. And once a gadget is closed it may as well be uninstalled since it becomes easier to open an application than restore the gadget.

Twadget (pictured but not mentioned) is the most compelling gadget in this crop. The gadget itself isn’t doing anything amazing. It just helps people interact more efficiently with the Twitter social messaging service. It takes something that people are already using and makes it easier to access. The real power of desktop gadgets lies in opening new points of entry for larger applications, whether the apps are web-based or installed on the computer.

As long as the never-changing Homeland Security Terror Alert Level is considered a “good” gadget, there’s plenty of room for improvement.

What’s your idea of a “good” gadget?

Microsoft offers up its view on what makes for a good gadget in a document buried under their Windows Vista User Experience Guidelines: Windows Sidebar Gadgets.

Despite being hidden away on the MSDN site, this is actually a really focused, useful set of guidelines for anyone thinking about creating desktop gadgets.

After some basic info on what a gadget is, the document explores what type of functionality belongs in a desktop gadget. There are visuals comparing examples of good and bad gadget layouts. There’s also guidelines for making the most of the Sidebar gadget framework, advice on handling different states of interaction visually, and recommended sizing standards.

I’ve been keeping this under wraps, but since I turned in the signed contracts there’s really no turning back. I’m working on a book about Windows Vista Sidebar gadgets.

The book’s part of a series called Visual Blueprint targeted to technically inclined people looking to learn a new skill. It’s really for people who have put together a few web sites and want to learn how to make interactive gadgets for the Vista desktop. It covers all the basics you need to make a gadget with lots of helpful screen-shots.

It’s going to take up most of my time for the next few months, but I’m really happy to be working on it. I think it’s a great subject — gadgets of all types are really going to change the way people interact with their desktop and with the web. It’s exciting to help people create their own gadgets.

I have never really grokked Microsoft SQL Server’s GO statement. Sure, I had a vague notion that it grouped execution of SQL statements in Microsoft utilities. But the specifics eluded me. Perhaps this is one of the reasons why I’m not a SQL administrator at work.

But enough about my short-comings, and on to an example of how not understanding GO can cause problems. Here’s a typical CREATE PROCEDURE generated by SQL Server Management Studio:

GO
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF
GO

CREATE  PROCEDURE [dbo].[some_procedure_name]
(
	@param_name_one varchar(60),
	@param_name_two integer,
	@param_name_three bit
)
AS

UPDATE some_table
SET some_field_one = @param_name_one
	,some_field_two = @param_name_two
WHERE some_field_three = @param_name_three

When I want to publish some development stored procs to a production server, usually I auto-generate create scripts for the stored procs. My current work environment uses different sql users for each project database, so I need to append a GRANT EXECUTE ON [proc_name] TO app_user_name for each proc to assign appropriate permissions.

But without a GO statment between the CREATE PROCEDURE and the GRANT statement, the grant statement never runs. It actually becomes part of the stored procedure.

SP_HELPTEXT on the procedure shows the resulting proc text:

CREATE  PROCEDURE [dbo].[some_procedure_name]
(
	@param_name_one varchar(60),
	@param_name_two integer,
	@param_name_three bit
)
AS

UPDATE some_table
SET some_field_one = @param_name_one
	,some_field_two = @param_name_two
WHERE some_field_three = @param_name_three

GRANT EXECUTE on [some_procedure_name] TO app_user_name

Eeeg! That’s not what I expected. It seems that placing a GO after the CREATE PROCEDURE script tells the Microsoft script engine to terminate the batch of SQL statements and start a new one for the GRANT statement. That way, the body of the proc ends at the GO, and the GRANT statement actually executes.

I needed to set the expiration date for Active Directory accounts in a VB.net web service today. Sounds simple, but it’s actually a bit tricky.

Turns out there’s a way to get around using the nonsensical large integer that AD uses to store the accountExpires field:

Dim NewADObject As DirectoryEntry
Dim ADContainer As DirectoryEntry

ADContainer = New DirectoryEntry(adPath,user,pass,authtype)
NewADObject = ADContainer.Children.Add(cn,objectClass)

NewADObject.Properties("SAMAccountName") = "newusername"

... yadda yadda yadda ...

'Set expiration date for account
Dim expireDate As DateTime = DomainAccountExpDate
NewADObject.NativeObject.AccountExpirationDate = expireDate

NewADObject.CommitChanges()

The bold bit is the pertinent section. NativeObject allows direct access to the properties of the underlying DirectoryEntry COM component. AccountExpirationDate can be set as a DateTime value.

Mesa Dynamics has released Amnesty Generator, a freeware app that packages various formats of web gadgets automagically into Vista Sidebar Gadgets.

The site claims Google gadgets and other web widgets can be quickly added to the Sidebar. While I can certainly live without annoying MySpace audio players on my desktop, if this works as advertised, it would bring an immediate boost to the library of available Sidebar gadgets out there.