Friday, March 30, 2007

If You Do Anything At All, Make Some Meaning

If you do anything, anything at all, make some meaning.

If you are thinking about launching a startup or are a programmer unhappy in the company you work for, this advice is for you. But really, it's mostly for me. In the future I'll need to hear it again and again. I don't know if you’ll need to hear it too but if you do, come back to this anytime you feel like it. I know I will.


The Importance of Making Meaning

As programmers, we wield an enormous amount of power. We can take 1s and 0s and forge them into something useful. We can create programs that do truly amazing things. We can (and have) fundamentally change the way the world works. We write beautiful code. We develop elegant techniques. We design and use brilliant patterns. And we’re learning quickly. We’re getting better at it all the time. The power and influence we have is growing at a rapid pace. This is our golden age and we know it.

But there’s a question that keeps cropping up for me and it is: What are we making? What does it mean?

As a programmer with the ability to influence so much, this question is terribly important.

I can’t answer that question for everyone but I can tell you what mine is.

What I’m hoping to convey here is the idea that once you discover what’s important to you, you'll gain a sense of clarity. Everything else becomes secondary.

I didn’t realize until last week that I was stuck between deciding if I wanted to make money or make meaning. They aren't mutually exclusive, but I had to decide what I wanted to truly focus on. My answer was to "make meaning".

But hang on. WHAT, for the love of god does “make meaning” mean?

For me, it has to do with people. All of our beautiful code, technology and technical advancements mean nothing if they don’t do something meaningful for humans. Even though we might not like that messy, emotional humans get in the way of our programs, it will always be that way. I tend to get lost in the details of what I’m doing and lose the sense that in the end, if it didn’t improve someone’s life however marginally, it didn’t matter. You can make beautiful code that is completely worthless and completely meaningless. To put it bluntly, I’d rather write terrible code that improved our ability to connect on a human level than write the fastest, most elegant routine for solving a Sudoku puzzle. When I’m at the end of my life I’ll be thinking about the human interaction I’ve had and certainly not that elegant piece of code.

So there's my bed and I'm lying in it. I DO hope to make money of course, but I hope to make money as a by product of doing what I love.

What’s meaningful to you? Figure that out and then do it with everything you’ve got.

It’s the only thing that matters.

Wednesday, March 28, 2007

Sandwich Markup Language

Haha! This is just great.

Here's how I like mine made:


<sandwich>
<bagel_top type="wheat" toasted="true"/>
<mayo extra="true"/>
<mustard type="dijon" extra="false"/&g;
<cheese_slice type="provlone"/>
<cheese_slice type="provlone"/>
<meat_slice type="roastbeef"/>
<meat_slice type="roastbeef"/>
<meat_slice type="roastbeef"/>
<bagel_bottom type="wheat" toasted="true"/>
</sandwich>


How do you like yours made?

Tuesday, March 27, 2007

There's Flaming and Then There's This

After reading the latest post on headrush.typepad.com I'm sick to my stomach. The treatment Kathy getting is criminal. Literally.

Monday, March 26, 2007

An Open Letter To Jeff Atwood

To: Jeff Atwood at www.codinghorror.com
Re: Your March 23rd post on www.thedailywtf.com

Dear sir:

Thedailywtf.com community (hereafter referred to as "the community") is writing to inform you that we take issue with your post titled "Our Dirty Little Secret". After seeing the damage your post has caused, it's clear the only dirty little secret we have is that we allowed you to post anything at all.

The community graciously let you post a guest article which appeared on our front page the morning of March 23, 2007. You violated our trust, sir. You destroyed the community's spirit, a spirit that has been carefully nurtured and cultivated. A spirit that has flourised in our perfectly constructed, completely flawless, self-sustaining community. You are a blight, sir. You ravaged our lands and pillaged our palaces. You destroyed our temples and called into question the very existence of our gods. You've shaken the very foundation of our being.

With your clever words and cutting sentences you challenged our perfection. Can't you see that we can't help it? How dare you challenge our very nature? How dare you!

Therefore Jeff Atwood, from this day forward until such day the community deems otherwise, you are "dead to us". Your passport has been revoked. You will never visit our pristine lands again. You will be forced to marvel at our splendours and achievements from afar. May you see the error of your ways.

We can only hope that the damage you have caused will fade with time. We can only hope that with each passing day and each new WTF that the memory of your damage will pass into lore. As we heal and recover our sense of perfection we hope that you begin to understand the magnitude of your actions.

So say we all.

Signed, TheDailyWtf community.

Sunday, March 25, 2007

Another Blog Review

Yes, I'm resorting to link whoring swapping again. This time with http://www.jakeldaily.com

Ja Kel Daily Dot Com eventually wants to make money and is offering to link to your blog if you review his blog. Ja Kel's website looks suspiciously like John Chow's, but despite that fact I think he'll end up making a decent amount of money with AdSense. I want to make money too but I have a feeling that becoming a millionare from AdSense revenue is not in my cards!

All the luck to you Ja Kel!

The Paradox of Being Stupid and Knowing It

I just read an interesting journal entry written by Mike Lewis titled "Hey... YOU'RE DUMB!". He cites Coding By Dogma in the comments section which is how I came across his journal entry.

Boy, that journal entry really got me thinking.

Mike's position is that we make mistakes because we're "dumb". I think that word is a bit strong and think it's better to say "not as smart as we think are" instead of "dumb" because saying dumb implies there's an accurate way to compare one person's intelligence to another's (which I don't think there is, but that's besides the point).

But Mike makes a good point. We DO make mistakes because we aren't as smart as we think we are. At times we are too confident and do more than we should have. At times, we think we're being smart by being cautious when what we should have really done is executed with confidence and gusto.

The Paradox of Being Stupid and Knowing It

But so what? What does it mean to realize you aren't as smart as you think you are?

What does it mean to get up and say - "Hi my name is John, and I make mistakes because I'm dumb"?

What does being stupid and knowing it do for anyone?

Here's your paradox: Being stupid and knowing it makes you smarter.

If you're looking for a quick way to become smarter, more effective and make less mistakes then realizing that you are not as smart as you think you are is the best thing you can do.

When you do realize and admit it, you can learn to de-emphasize the areas where you aren't smart as well as emphasize the areas where you ARE smart. This is essentially, playing to your strengths.

If you're aware and mindful of your limitations then you'll make less mistakes. You won't feel so stupid. And that's because you won't be as stupid!

So Mike, if you're worried that you're dumb, please don't. You ARE stupid. I'M stupid. We're ALL stupid. The difference is, I know it and you know it. The question is, who else knows it?

And the BETTER question is, how can we use it to our advantage?

Thanks for reading.

Saturday, March 24, 2007

Things I Learned This Week #1

I learned lots of things this week. Here's a list outlining some of the more important ones.

  • Strangely enough, I learned a little bit more about human nature by writing about programming. I wrote about this in a post titled "Coding By Dogma". The post was an attempt to put my finger on why developers take sides. Even though the revelation was prompted by an example taken from the computer programming world, I believe that the ideas I talked about in the post can be applied to any situation where people people take sides and stick to their guns.
  • I learned that people can become even more unfair and nasty when someone gently points out they are being unfair and nasty.
  • I learned that the most important question you can ask yourself is: Are you here to make meaning or are you here to make money? I plan to blog a lot about this next week because this question is so important that once I answered it, things became a lot clearer for me.
  • I learned that you can manipulate Google's search ranking with an extremely clever tactic. I love clever tactics, and this one is so clever and obvious I feel like laughing, crying and being sick at the same time.
  • I learned that controversy is never a bad thing. As John from http://www.agilekiwi.com/ pointed out in an email to me, I got lucky with all the traffic and controversy my blog post. generated. When the hate mail poured in I was completely overwhelmed and a little angry that I was getting such a terrible response to something I thought was great. But as the saying goes, any coverage is good coverage. In the end, I'm still glad I wrote the article and I'm grateful I got a chance to learn more about what makes people tick.
Next week, I'm going to post about making meaning and making money. I hope you'll come back and join the discussion because I think it's the most important one we can have.

Thanks for reading

Friday, March 23, 2007

Jeff Atwood On TheDailyWTF

If you haven't already read it, check out Jeff Atwood's post on thedailywtf.com. I think it's a great post. I also think the comments people have been leaving are a bunch of crap.

I've decided to no longer visit thedailywtf.com after seeing what kind of a community sets up shop there. For me, the site has boiled down to a place where you can simply make fun of other people. Jeff's point is that we all make mistakes, so laughing at bad code should be done in good taste because we are essentially laughing at ourselves.

Laughing at bad code is well and good, I know I've done it - but Jeff's right, when you take the attitude that you've got it down pat and all the rest don't...well...there's something wrong with that picture.

The community over there doesn't want to hear that kind of talk. And that's a shame.

Coding By Dogma

I learned lots of things this week, but the most important thing I learned is that coding by dogma is a widely followed practice. Who knew? I didn't. And it really took me by surprise.

It all started with my post, "Who Needs a Database?" which despite its provocative title was not anti database in nature. Rather, it was a post about shirking convention and building something that works by using simple techniques and simple code. The end result was a two page website that works exactly the way it was designed to. The sticking point for many people was that it didn't use a database but used a few flat files instead.

There were a few things about the reactions that took me by surprise. The first was that many readers left comments insinuating that my post was "anti database". The second was that the subject of not using a database utterly, completely and totally (I know, those adjectives are redundant - I'm trying to make a point here) polarized people. People either thought it was the most stupid thing in the world or they thought it was great.

In fact, some of the backlash was so vehement that JimboJones took it upon himself to post a link to the article on http://www.thedailywtf.com/. Link is here. For those of you who haven't been to thedailywtf, it's like the kiss of death. To see a reference to your code on thedailywtf is one of the most shameful things that can happen to a developer.

A curious thing happened when I saw the link to my code on thedailywtf and the laugh fest that followed. I entered a state of deep calm when I saw that there are developers who code by dogma. I understood then, what made people so angry.

Coding By Dogma

Even though I had clearly written that databases are standard pieces of any architecture for good reasons, nobody seemed to care. They couldn't see past the fact that I WASN'T USING A DATABASE!

Even though I clearly explained that based on the requirements for my site (requirements that I came up with, for a site that was all mine, not a client), there was no need for a database and I could accomplish exactly what I set out to do with just a few flat files, they still shouted "BUT YOU AREN'T USING A DATABASE!".

Even after I wrote in a follow up post explaining that people were missing the point which was essentially, if the site does exactly what it's designed to do, if the site is lean, simple and took me just a few hours to put together then what's the problem with using a few flat files? But they still shouted, "THE PROBLEM IS THAT YOU DIDN'T USE A DATABASE AND BECAUSE YOU DIDN'T YOU MADE SOMETHING TERRIBLE!"

Ok, so nobody actually shouted at me, but it sure felt like it.

So, why did my responses make those guys so angry, even angrier?

I think it's because many of us code by dogma. When presented with a problem (say, building a simple site exactly like mine) we automatically say: "ok, first, we know we're going to need a database, so let's do that".

In the vast majority of the cases we'd be right. What I tried to do was challenge that convention. I didn't do it senselessly however, I did it in the context where not using a database was a fine choice. But context doesn't matter to us when we code by dogma. We can't see past not using a database. There is no situation that might warrant using a flat file over a database. That's coding by dogma.

This discussion is by no means new. I'd like to wrap up here with a few examples.

Example 1:

radar.oreilly.com



Gabe (of memeorandum.com) wrote: "I didn't bother with databases because I didn't need the added complexity... I maintain the full text and metadata for thousands of articles and blog posts in core. Tech.memeorandum occupies about 600M of core. Not huge."

Mark (of bloglines.com) wrote: "The 1.4 billion blog posts we've archived since we went on-line are stored in a data storage system that we wrote ourselves. This system is based on flat files that are replicated across multiple machines, somewhat like the system outlined in the Google File System paper."


My goodness, these are fairly well known companies. I mean, Google uses databases AND flatfiles...

Make sure you read some of the comments. You'll hear a lot of the same rhetoric there that you'll see in the comments left here and on thedailywtf.com


Example 2

Joel Spolsky got massive backlash when he wrote about Wasabi, the custom language his company developed. When I first heard about it I thought it was the most stupid thing in the world. The more I thought about it though, the more I realized why he did what he did.

Joel says:



In most deployed servers today, the lowest common denominators are VBScript (on Windows), PHP4, and PHP5 (on Unix). If we try to require anything fancier on the server, we increase our tech support costs dramatically. Even though PHP is available for Windows, it's not preinstalled, and I don't want to pay engineers to help all of our Windows customers install PHP. We could use .NET, but then I'd have to pay engineers to install Mono for all our Unix customers, and the .NET runtime isn't quite ubiquitous on Windows servers.

Since we don't want to program in VBScript or PHP4 or even PHP5 and we certainly don't want to have to port everything to three target platforms, the best solution for us is a custom language that compiles to our target platforms.



When we don't pay attention to the context - to the real problem we're trying to solve we fail to see that what Joel did was smart. Hard, but smart.

What made some people angry was that Joel WROTE HIS OWN LANGUAGE! To most people, that's just a programming excercise, something you'd do in college, not something you'd ever want to do in "real life".

Well, that's just code dogma.

Thanks for reading!

Thursday, March 22, 2007

Blog Review: The Paper Bull

I'm not planning on doing frequent blog reviews but I came across The Paper Bull (by way of John Chow's batch 39) and would like to say just a few words about this site. I just love the "feel" that's developing over there. (Is that a weird thing to say about a blog?)

What I like best is that the blog is that you aren't going to find yourself wading through a million posts that start with "hey, try this out - it worked great for me!" What you DO get are posts that are all about developing strategic ideas and blogging alongside their development. See, this way you aren't being told what works, you get to understand what works and what doesn't work.

The Paper Bull is currently doing a backlink case study. To see what I mean, go here. I wish The Paper Bull all the luck and am glad I can help them out by providing the links above.

Wednesday, March 21, 2007

Make Money Online With John Chow

John Chow dot Com is a blog that helps you make money online. He is offering to link to your blog if you review his blog. I recommend visiting his blog and his blog post as it contains an extremely valuable lesson about how Google search ranking can be manipulated. In a clever way.

Tuesday, March 20, 2007

On "Real Developers"

This is loosely related to my last few posts regarding building a site with no database backend. You can read them here and here.

Bob writes in this post about what makes a "real developer". Read his post and then come back here.

I agree with his viewpoint which essentially boils down to this: "Real developers" don't waste time bashing other languages and methodologies. They use a language to it's full potential. Above all, they use it to create real solutions to real problems.

The reason I think this is related to my other posts is that too often people get caught up in convention and forget to look at what it is they're trying to solve. We make things more complicated than they really need to be and we waste time convincing ourselves that our hammer is better than the other guys hammer when it's really about building a house, not nailing. In the end, it's not the nails and the glue that makes a beatiful house. It's the design and how it feels to live in it.

A Response to Those Who Hate My "How To Build a Site With No Database" Post

After reviewing many of the comments left on my post about building a site with no database backend, I'm convinced that a lot of people are missing my point.

I just want to be clear about something before I continue on with this post. I'm NOT advocating that you build sites without database backends. It's not my intention to say, "hey look, you don't NEED a stupid database! see...I did it with flat files!" I'm well aware of the inherent limitations you get when you use flat files over a database. You'll get no argument from me about that.

Let me be even clearer: There's a very good reason why using a database to store data is the conventional way of doing business. It's BECAUSE it's a good reason!

So, how can I possibly defend my post? Well, let me try.


My Point


I think the point that's been missed here is that when you look at the requirements of the site, when you look at what it's actually required to do, I think there's a very strong argument for not using a database. If you change the requirements, you change the implementation.

fwgx left a comment which is a good summation of other readers' comments. He says:

"...It's not hard to imagine what other requirements may be required later and as soon as that happens you're stuck. Can you easily get the maximum score per user between two dates? Can you find the average score for users who's name starts with a 'W' and who have played 5 games between midnight and 3 am?All reasonable queries that are easily answered using SQL but that would require tight coulping and nastiness in this solution.Not to mention the lack of type safty, referential integrity checks, FK constraints, transactions, load balancing, query caching, index tuning over time, backup systems, running on redundant servers, triggers etc..."

I'm going to argue here that he's completely missing the point. And believe me, my point is simple.

Don't invent requirements. Don't pre-optimize. Don't build stuff you don't need to. Just. Keep. It. Simple.

The requirements of the site I built don't require me to "find the average score for users who's names start with "W" and who have played 5 games between midnight and 3 am"? Why not? Because the site isn't going to show that information! And for another very good reason.

The site doesn't have users. This means that a user doesn't log in. A user doesn't have an account. If the site required that, then yes, I would have built it with a database. Period.

I appreciate the comment, and I appreciate the example here - but this is exactly what happens when we (developers) stop looking at what we're trying to solve and start inventing possibilities. We make things more complicated. We start talking about triggers, redundant servers, FK constraints.

As far as being "stuck" when/if requirements change later on. Far from it. Changing the code that reads the text file to code that reads a database table will be trivial. In fact, if anyone wants to challenge me - I'll do it and blog about how long it took to do. And I will be completely honest about the experience.

The bottom line here is that I'm not advocating text files as a replacement for databases. Far from it. I'm advocating that you should build software that solves the problem. Not make the problem more complicated.

Let's keep it simple.

Monday, March 19, 2007

How to Use Reflection to Compare Two Objects

The Code


Private Function IsEqualTo(ByVal objA As Object, ByVal objB As Object) As Boolean

Dim different As Boolean = False
Dim type1 As Type = objA.GetType
Dim props() As PropertyInfo = type1.GetProperties

For Each p As PropertyInfo In props
Dim pValue As Object = p.GetValue(objA, Nothing)
Dim pValue2 As Object = p.GetValue(objB, Nothing)

If pValue <> pValue2 Then
different = True
Exit For
End If
Next

Return Not different

End Function


This code snippet is pretty simple. It uses reflection to iterate over the properties of one Object (objA) and compares each property to the other object (objB) of the same type.

How would you use it?



This example will return "equal"


Dim objA as New Person
Dim objB as New Person

objA.FirstName = 'John'
objA.LastName = 'Smith'
objA.Phone = '555-1234'

objB.FirstName = 'John'
objB.LastName = 'Smith'
objB.Phone = '555-1234'

If IsEqualTo(objA,objB) Then
MsgBox("equal")
Else
MsgBox("not equal")
End If




This example will return "not equal"



Dim objA as New Person
Dim objB as New Person

objA.FirstName = 'John'
objA.LastName = 'Smith'
objA.Phone = '555-1234'

objB.FirstName = 'John'
objB.LastName = 'Smith'
objB.Phone = '555-1235'

If IsEqualTo(objA,objB) Then
MsgBox("equal")
Else
MsgBox("not equal")
End If


It's All About Blog Trust

I have an idea I'm certain would vastly improve the blogosphere, enhance a blogger's ability to find a larger audience and enable blog readers to find worthwhile blogs. And it has everything to do with trust.

Blog Trust


One of the most popular features on many blogs is the "links to other blogs" section. And for good reason, it is a great way for bloggers to list out blogs they find interesting. These kinds of links are what the web is all about, after all.

As an example, here's a screenshot of Guy Kawasaki's "Blog Scratching" section:



He's got tons of links, but the one I'm interested in is the link to Bill Joos' blog.

So, what's the problem? Well, it's not so much of a problem as a greatly missed opportunity. Let me explain.

Because Guy Kawasaki links to Bill Joos' blog, we can assume that
Guy "trusts" the information that Bill Joos dishes out on his blog. If I start out on Guy Kawasaki's blog, and I have a great deal of respect for the information that Guy gives out (which I do) then I can feel pretty good about going over to Bill Joos' blog.

But what happens if I come across Bill Joos' blog? I have no idea that Guy recommended Bill. And that's exactly where Blog Trust comes in.

The Blog Trust Proposal


I'm proposing that in addition to a "Blog Roll" bloggers put in a "Recommended By" section which links to bloggers who recommend the blog you're currently reading. If you think about it, it's a great way for you to provide links back to bloggers who "trust" you and it helps bloggers get to know who you are.

If Bill Joos' had that section up there and listed Guy Kawasaki as someone who trusted him - I'd be able to "trust" his blog much more.

Wait, There's Something Wrong With This!


Yeah, I know. You're thinking, "some sleazy blogger can just slap a link to Guy Kawasaki and say hey, he recommends me!" You're absolutely right.

What would solve this problem is a central service which would allow people to recommend a blog. If you are the blog owner, you can display the list of bloggers who recommend you right there, front and center on your blog. Hmm....you know, the more I think about it, the more it sounds like a FINE startup idea. Don't you?*


*If you do think this is a good startup idea and run with it, you BETTER link back to this post AND recommend my blog on your brand new service! And that's if you beat me to the punch - cause I'm working on it already. ;)

Wednesday, March 14, 2007

Who Needs a Database? How I Built a Fully Functioning Website Without One

Why?


Why would you want to build a website without a database? I'll try to answer this question for you by explaining some of the reasons why I did it.



  • One of the reasons was purely academic - could I build a site that persisted data and was fairly interactive but with no database? If I did, what kind of problems would I run into, would the implementation be stable? Could I build it in such a way that if I ever needed to use a database - woud it be hard to convert? In short, it was a challenge I couldn't resist.


  • Another reason was simply because there was no reason not to do it! Once I had settled on the site design, there was just no solid, compelling reason other than convention why I would have to use a database as my persistence medium. None whatsoever. Many of you will disagree with me of course, and I welcome your comments and rants. :)



With no reason not to use a database, and with the challenge in hand, I got down to the business of building the site. Before I explain how, I'd like to give you a quick overview of what the site is and what it does:



The Site


The site was built using ASP.NET 2.0
To reference the fully functioning site throughout this tutorial, go here.

The site design is very simple. Every day ten Sudoku puzzles are displayed on the main page, which I call The Scoreboard:



Clicking on a Scoreboard widget (shot below) will take you to a page where you can solve the puzzle. If you solve it quickly enough, you get to enter your name and url and take your spot on the scoreboard. If someone comes along and solves it more quickly than you did - they bump you down the list. Only the top 5 players are shown for each puzzle.




Nice and simple.


The Ingredients



The Solutions File
The first hurdle was to decide how I would generate the 10 daily puzzles. I didn't like the idea of having a scheduled process generate 10 new puzzles at midnight every day so I went with generating several months worth of puzzles and placed 10 puzzles into their own "solution" text file. Each file is placed into a folder labeled with the date it is to be used for. Essentially, when the scoreboard needs to get the list of puzzles for the day, it nagivates to the directory labeled with the current date and retrieves the puzzle information from the file inside the folder.

The solution file is simply a delimited file with the first value being a GUID (to uniquely identify the puzzle) and then a comma delimited list of values that represent the Sudoku puzzle.

Here's what the solution file looks like:



The Puzzle List

Since this file contains the list of puzzles for the day and once read would never change, it made it a great candidate for caching. And that's what I did with it. The Scoreboard never directly interacts with the solution file, instead it interacts with a Class (called Sudoku) that exposes a Shared method. The method returns a Hashtable called PuzzleList. The key is the puzzle Guid and the value is the comma separated puzzle values.

The benefit of this approach is that the Shared method can determine if the puzzle list needs to be reloaded (say, it's a new day). If not, it the hashtable is automatically returned.




Public Class Sudoku

Shared _puzzleList As Hashtable

Public Shared Function PuzzleList() As Hashtable

If _puzzleList Is Nothing Or Now.Date > HttpContext.Current.Application("lastSudokuCachedDate") Then '

Try

_puzzleList = New Hashtable
'populate puzzle list.

Dim puzzles() As String
Dim puzzleContents() As String
Dim i As Integer
Dim fileContents As String

Dim server As HttpServerUtility = HttpContext.Current.Server



fileContents = My.Computer.FileSystem.ReadAllText(Now.Date.ToString("MM-dd-yyyy") & "/puzzles.sln"))

puzzles = Split(fileContents, vbCrLf)


For i = 0 To puzzles.Length - 1
puzzleContents = Split(puzzles(i), ":")
'key is guid
'value is comma separated values represeting puzzle.
_puzzleList.Add(puzzleContents(0), puzzleContents(1))
Next

HttpContext.Current.Application("lastSudokuCachedDate") = Now.Date

Catch ex As Exception



End Try

End If


Return _puzzleList


End Function

End Class



The Scoreboard

When scoreboard.aspx is requested, it simply makes a call to Sudoku.PuzzleList() and iterates over the collection. A scoreboard widget is added to the Page's control collection and assigned a Puzzle GUID. That's it. All the scoreboard knows about is showing those scoreboard widgets (and Google Adsense of course!)

The Puzzle File

When a solution file is generated, an scores file is generated for each puzzle. This file is responsible for storing the information that you see on the scoreboard. It's a delimited file as well, storing the time, the name and the url of the person who solved the puzzle.



The Scoreboard Widget
This is perhaps the most important of all the ingredients. The scoreboard widget is a u ser control that takes one parameter - the id of the puzzle. When the widget loads it does two things - it looks in the cache to see if there is a score listing for the puzzle and if there isn't, grabs the file, parses it and sticks it in there.

Essentially, the scoreboard widget only ever displays the data from the cache. This is VERY fast especially when the alternative is to read it from disk every time.

Well, what happens when someone makes it on the scoreboard and the cache is different from what's in the .scores file? In that case, the scores for the puzzle is removed from the cache. So the next time someone goes to the scoreboard and the widget looks in the cache, it's not going to find anything and will grab it from the disk then cache it.

In other words, the first time through, the file is cached forver, until someone beats someone out of their spot on the scoreboard at which point, the file is updated, and the cache is invalidated. The cycle starts all over again.




Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load

Dim fileContents As String

If (IsNothing(Cache(PuzzleID))) Then

fileContents = My.Computer.FileSystem.ReadAllText(PuzzleID & ".scores"))

Cache.Add(PuzzleID, fileContents, Nothing, DateTime.Now.AddHours(1), TimeSpan.Zero, CacheItemPriority.Normal, onRemoved)

End If

'get the data out of the cache.
fileContents = Cache.Item(PuzzleID)

Dim scores() As String
scores = Split(fileContents, vbCrLf)

Dim i As Integer

For i = 0 To scores.Length - 1

'parse the contents...blah blah blah
'snipped for brevity

Next

End Sub




The Puzzle Page
I thought I would throw in a description of the puzzle page in for good measure.

The puzzle page take a QueryString parameter ("id"). When the player is ready to play the game, he or she clicks the START button. The START button makes an AJAX call to another page which returns an XHTML representation of the puzzle. It uses the values in the solution file and randomly removes a set number of clues to the puzzle. When the user is done he or she clicks the SUBMIT button and the time is compared to the score values stored in the cache. If the player has beaten any of the times, the file is rewritten to disk with the new players information and the scores data removed from the cache.

And...that's it!


Conclusion



Is it feasible to build a site without a database? You bet! As I hope I demonstrated above, it all depends on is what you're trying to accomplish. The site I built didn't need a database. I just didn't need the overhead or the added complexity.

I have to admit that it was a refreshing excercise for me since I tend to do things just because it's how "they're done". It was great to take a step back, decide on a different approach and implement it. It's also incredibly gratifying to see it work. The site feels snappy because of caching and is very easy to maintain because of the simple file structure. And did I mention debugging? A cinch! I don't have to worry about queries, stored procedures, database connections, password, etc.

I hope this tutorial encourages you to try something out of the norm, or at the very least makes you think about ways in which you can simplify your designs.

As always, thanks for reading!

Update 8:37 A.M. 3-16-07

Reddit user bluGill left a comment:
"...I see several databases: First the the filesystem, which is itself a database. Second is his scorecard, which is a database..."

I can't disagree with this - but I think it's a bit picky. I assumed that it was very obvious that when I refer to a "database" I'm referring to a relational database such as Oracle, SQL Server, MySQL etc.

Update 10:14 A.M. 3-20-07

See my follow up post which is a response to anyone who thinks this is an incredibly bad idea. Please read it and feel free to comment!

Update 1:13 P.M. 3-23-07

I wrote another post about this topic called "Coding By Dogma"

Monday, March 12, 2007

How I Went From 100+ Page Views A Day to a Whopping 5 a Day

I think it might be time for me to throw in the towel and loudly proclaim that I just don't "get it." What I'm referring to here is the process of developing web site traffic.

I'm looking for feedback from any SEO types out there - or anyone who might link to any of my sites out of good will or genuine interest.

Three weeks ago I developed a new site called The Sudoku Challenge. The idea is simple. Every day 10 sudoku puzzles are posted. Solve a puzzle and if you solve it quickly enough - you get your name on the scoreboard. The scoreboard starts fresh every morning. Sound simple, right? I mean, LOTS of people like Sudoku, so you'd think it'd be relatively easy to attract visitors and keep them coming back! Not so, batman.

Initially, I posted links to it on del.icio.us, reddit, digg, and netcape. After getting 100 page views a day (that's not a lot, I know) traffic has all but died. NOBODY is coming back to play.

I have also sent emails (individually written, not templated) to several sudoku related sites letting them know about The Sudoku Challenge. So far, no response.

So I ask you, what is it that I'm doing that is apparently so uninteresting? Is it time to throw in the towel with this idea? Is it time to resort to begging for links (like I'm sorta doing now)? Should I wait, is a month too short a time to decide if an idea is viable?

Any feedback or links would be incredibly welcome! Please comment or email me at john at todotoh dot com so I can thank you personally.