Web 2.0 Generators

AjaxFlakes.com just posted a list of the top 100 Web 2.0 generators. Generators for everything from buttons to animated “loading” images to rounded corners.

Yeah, yeah, we all know Web 2.0 is just a fancy word to get VC funding or whatever, but you’ve got to agree, Web 2.0 has spawned a lot of nice looking web apps.

SandDock

Earlier releases of Code Toaster used the infamous Weifenluo DockPanel suite for managing the tabbed window interface. I found, unfortunately, that since DockPanel uses full-blown windows (Forms, in .Net), there was some annoying flickering and performance involved when windows were shown or hidden programmatically. Also, I found the API was a little clumsy and nonintuitive. It took (me, personally) forever to figure out how to automagically pop up the Errors window if errors were discovered after compilation, like VS does.

So I tried out SandDock from DivElements. SandDock windows inherit from Control rather than Form, so they’re lightning fast without all that extra windowing baggage hanging around. And if you’re already using Forms for your windows (as I was), it’s really easy to convert – you just change the base class from Form to the SandDock “window” control (I forget the name at the moment). You can do that because Form inherits from Control; of course if you’re using Form specific functionality you might run into some issues, but I discovered none.

The SandDock API is a breeze – no need to consult pages of documentation to figure out how to hide or show windows. Very intuitive and easy for a lazy developer such as myself. It’s not free, but it’s very reasonably priced at only $169 per developer. I consider that a good buy if it will make my app look nice and slick and tidy.

Last night while tinkering with Code Toaster I discovered my SandDock trial had expired, so I went ahead and bought a license. I’m planning on releasing the latest and greatest incarnation of Code Toaster within the next few weeks, possibly along with a very simple DAL generator, appropriately called SimpleDAL.

Keep watching here for more updates.

Embedded Databases

As I noted in an earlier post, I’ve been experimenting with SQLite, a super-small super-fast SQL database engine. SQlite is a small C library that supports transactions, implements most of SQL-92, supports terabyte-sized databases, and weighs in at only 150KB. I’m finding that it’s just perfect for desktop applications that need to store and quickly retrieve data from disk.

SQLite databases are made up of one file, which you can name whatever you want, and which can be encrypted. There are tons of GUI tools (almost all selling for $60 or more) for creating and configuring SQLite databases, but (for now) I prefer the free SQlite Administrator, which is just about as good as it gets. This isn’t an Enterprise RDBMS here; I just want to create some tables, add some indexes and primary keys, and go develop something cool, and this gets the job done. And you can’t beat the price.

I’m using .Net, so I needed a .Net provider, and I Google’d across this bodacious ADO.Net 2 provider for SQLite, which amazingly can be used either as a .Net provider, or as a “regular ol’” SQlite engine with no linker dependency on the .Net runtime. That’s really neat. Not that I would ever need that – but that’s cool anyway.

I can’t offer my esteemed opinion on performance metrics or whatnot, other than to say that, so far, it’s fast enough. It handles some of Code Toaster’s Intellisense queries lightning fast, against a database of roughly 20 MB in size.

There are other alternatives in the world of embedded databases, most notably SQL Server 2005 Compact Edition, which is also free, and also lightweight, weighing in at a mere 1 MB. The feature-set offered by this database engine is waaay more than SQlite could ever offer (being that SQL Server has more resources and more developers and so forth behind it), but SQLite wins hands down over simplicity. Deployment of SQLite is just the engine (~160KB) and a database file. I haven’t personally tried, but I’m guessing deploying SQL Server Compact Edition requires messing with a merge module or some nonsense that I don’t care to worry with right now (I know, I’m being a lazy blogger. Shame on me.).

The big downside to SQLite, and perhaps a big reason why you would want to consider SQL Server Compact Edition, is this whole locking of the database thing. You can’t write and read at the same time, lest you (and your users) get a nasty error message. Which means if your application is threaded in any way shape or form, you’ll probably need to use a flag, a Mutex, or somethin’ to keep from blowing your app to the moon.

That sounded bad. It’s really not that bad. I like SQLite. Seriously, overall I think SQLite is a simple, sleek little database engine machine thingy, with a wonderfully small footprint that will more than foot the bill if you can afford to take a little extra care in your coding.

Salted Passwords, and Other Cryptographic Goodness

Thomas Ptacek’s response to Jeff Atwood’s post on storing passwords securely is going in my bookmarks for posterity. This post, actually both posts, should be required reading for anyone building secure web site.

Make that all developers, period. We should all have a basic understanding of how to store passwords securely, and how bad it can be if we don’t.

Some important lessons I learned:

• Never try to roll your own “cute” security algorithm or whatever. Just use the solutions professional cryptographers have spent their lives perfecting. Your little algorithm may remain uncracked for years, until one day your customers’ credit card numbers (or worse) start showing up on some web site in Bangkok.
• Always salt stored passwords before hashing to thwart rainbow table crack attacks.

This is good stuff.

Threading Issues

Microsoft has made threading brain-dead easy to implement in the .Net framework.

For starters, every thread you allocate will consume a Meg of memory, right off the bat. In .Net 1.1, that 1MB was reserved, but not committed until the stack grows into it. In .Net 2.0, however, the CLR precommits the whole stack for reliability.

But the main problem n00bs deal with when implementing threading is not memory, but issues of concurrency. Each thread may be doing its own thing for the most part, but at some point its  going to have to reach out and touch data outside of its little thread context.

But what if something else is already touching that data?

Mr. Mutex to the Rescue!

That’s where it gets tricky. And that’s where we might use a little something called a Mutex.

In .Net, a Mutex is implemented in the Mutex class. A Mutex is like a ball that gets passed from thread to thread. Whoever has the ball gets to run (and do stuff). If a thread doesn’t have the Mutex, it has to wait until it gets it.

To create a new Mutex you would just call it’s constructor thusly:

private static Mutex mut = new Mutex();

Up to this point we’ve just pulled a ball out of the locker room, so to speak. But nobody has it yet. From within a thread, we would call the WaitOne() method.

mut.WaitOne();

So the thread will sit here and wait, forever, if necessary, until it owns the Mutex. If it’s the first thread to call WaitOne(), the operating system gives it the ball and it does it’s thing. If it’s not the first thread, it waits and waits and waits, until another thread calls…

mut.ReleaseMutex();

…which, as it says, releases the Mutex. The thread is done with it… let another thread play for a while.

And this leads us to a very important point. A thread can call WaitOne() multiple times, but it must also call ReleaseMutex() the same number of times, or the Mutex won’t get released to other waiting threads. Which basically means your other threads that are waiting, waiting, waiting… will wait forever. Or until the “naughty” thread terminates (which, in .Net 2.0, will raise an AbandonedMutexException).

So a Mutex makes it relatively easy to control threading concurrency issues, although I’m sure some of you out there could concoct nasty horribly complex scenarios that would drive the sanest debugger mad. But you get the point.

Real World 

So how ’bout a real world example? Code Toaster uses the SQLite embedded database engine to cache some of it’s Intellisense data. The problem with SQLite is that while you’re writing data, no other reads or writes can be made, or else an exception is thrown. Which is kinda stinky. SQLite doesn’t handle concurrency very well, does it?

But it is lightning fast, and works extremely well for something like Intellisense, where lots of data needs to be searched and retrieved almost instantaneously.

Since Code Toaster uses background threads to cache Intellisense information from assemblies and assembly documentation files, this was obviously a problem. More than one thread couldn’t write to the Intellisense database at once, lest an exception be thrown. 

So naturally I used a Mutex to allow only one thread to write to the database at a time. Problem solved. Elegantly.

And lightning fast.

iPhone Price Drop

Apple has dropped the price of the 8GB iPhone to $399, and tossed the 4GB model, which nobody wanted anyway.

For the same price you can snag the new 16GB iPod Touch, which boasts all the features of the iPhone except for the phone. If you’re near a wireless hotspot you can even browse the web.