So I started to do a little snooping. I discovered many of my PHP files had a large string of characters at the start of every file. I also notice server not found errors in my log. I googled the error and server and discovered that this is a known WordPress virus. The solution was to eradicate it from every PHP file. I did, it was present in several dozen files including some plugins. But, things were no better, maybe worse! Now, my admin pages were all OK, editing worked, etc. But my blog’s pages came up empty, nata, nothing. No code at all in the pages. I spent some time on the WP forums and had some things to try but none worked.

I finally did a complete removal of my entire wordpress directory – except my wp-config and my uploads directory in wp-content. I did a manual reinstall of WP 2.9.1 and logged in. Same thing, no blog pages. Frustrated I went back to WP forums but found nothing helpful. Then I had an idea, I went to the Themes admin page and changed my theme to the Classic 1.5 theme. Reloaded, and voila, everything worked fine! I reinstalled my favorite theme – Vesper – and plugins and all is good on the EclecticGuy blog again. What a pain that was though. I changed all my passwords and admin login just to be safe.

Did anyone figure out what that drawing above is? It’s the common cold virus!

So, now that I’ve update four of our Macs (Family Pack) with Snow Leopard and used it for a few days, what do I think? Well, there is very little change in the user interface. That’s a good thing, I hate relearning new UIs. The real power of Snow Leopard is under the covers – full 64 bit support and a completely re-written Finder (that is, of course, 64 bit). Almost all of the Apple apps are now 64 bit too (Mail, Safari, iCal, and iChat). Snow Leopard’s “Grand Central Dispatch” is an enabling technology for software developers to write better multi-processor applications more easily. OpenCL taps in to graphics processors to use for more than just graphics. Very cool, I can hardly wait to see what developers do with it! Snow Leopard comes with QuickTime X also. It includes a new Player, really improved internet video streaming, and built in audio and video capture!

So far, Snow Leopard has been noticeably faster and completely transparent – meaning I have not run in to any problems with any of the apps I run – Photoshop CS3, ViaCAD, the iWork suite, Lightroom 2, TextMate, etc. The new XCode is also really solid.

My goal is to have this idea implemented in the next week or so, then we’ll have a complete – but simple – Shrugh prototype.

To check out the new demo. go to the Shrugh home page and click the create a shrugh link at the bottom of the page (or click the link I just typed!). Either way, check out the demo and please leave your comments/feedback at the end!

After I completed the demo though, the juices really got flowing! I am all for keeping it as simple as possible. As Albert Einstein said, “Everything should be made as simple as possible, but not one bit simpler.” Words to live by! So, let me try this on you – please let me know what you think!

1. When a shrugher creates a new shrugh, they pick from 1 of 3 types: Yes/No, Fish for Answer, and Pros/Cons. After picking the type, they enter their shrugh and an optional comment to add detail.
2. Each of these 3 types of shrughs has a different set of responses for users to choose from when they respond to a shrugh – this is the “Is your reply a…” option menu in the demo:
   • “Is your reply a…” Yes or No
   • “Is your reply a…” Verdict, Opinion, Kibitz
   • “Is your reply a…” Pro or Con
3. That is it, very simple. Anyone adding a reply (including the shrugh owner) does so the same way. The choose what their reply type is (see the list above) and then type in the reply. Very simple. Pros and Cons also have an “importance” (weighting) option 1-5 that can be set.

As I mentioned in the last status update, I had done some prototyping in both Ruby on Rails and Google App Engine to determine which direction I want to head. To be sure, this was not an apple-to-apple comparison. RoR is really a programming language and Web framework. You still have to choose an RDBMS (most likely MySQL since I have a lot of experience with it), find a hosting service, and deal with deployment and other issues. Google App Engine, on the other hand, is a complete Cloud Computing environment ready to go. It currently uses Python for code development, the Django Web framework, and Google’s BigTable object store. This all runs on Google’s App Engine environment – which provides automatic scalability, reliability, robustness, automatic application versioning and a host of other capabilities. In addition, it is free to get started (pricing model is usage based so it scales with the application). Finally, Google provides a really nice freestanding development environment that includes a simulated BigTable datastore along with the other services. It is very easy to download and start using this environment.

So, with the demo Mockups and user feedback “on screen”, I began by designing the “model” for Shrughs and implemented them iteratively in Python. Similar to Django, App Engine uses a Model class for managing data storage.  You write your model as a Python class and App Engine does the rest. This makes it very easy to just jump in and get started.

My goal for this first iteration was to create a reasonable model for Shrugh objects, display them on screen using CSS and a templatized presentation (also part of Django), and deploy all of this on Google App Engine. This would give me experience with the entire cycle of develop and test locally then deploy, test and activate on The Cloud. That’s a lot in a short time!

So, I knew that a Shrugh needed to have these attributes: an owner, a type (yes/no, list, pros vs cons), the actual question, and a few access control attributes. Here is what I came up with:

class Shrugh(db.Model):

	owner = db.UserProperty()

	shrugh_type = db.IntegerProperty(default=0, choices=set([0,1,2]))	

	question = db.StringProperty(multiline=True)

	comment = db.StringProperty()

	share_on_open = db.IntegerProperty(default=1, choices=set([0,1,2]))

	created_datetime = db.DateTimeProperty(auto_now_add=True)

	close_datetime = db.DateTimeProperty()

	share_on_close = db.BooleanProperty(default=True)

	everyone_add = db.BooleanProperty(default=False)

A few things need to be said about App Engine and BigTable that are demonstrated in this class. First, you’ll notice that I derive from db.Model. Model is the superclass for data model definitions whose properties are static. There is another form, db.Expando, which is a superclass for data model definitions whose properties are determined dynamically. I chose Model simply because that seemed easier to get started.

Next, you’ll notice that owner is a UserProperty. App Engine is tied to Google’s user model through UserProperty. This is one area of App Engine that I am still trying to wrap my head around – and apparently so are a lot of other developers based on the number of discussions and blog posts on this subject! Ideally, Shrugh users would not have to have a Google user account. That’s fine for now during the early development stage though. (turns out that Django has its own user model and it is possible to combine it with Google’s to support Google users and non-Google users.)

You’ll also notice that some properties have a default value as well as pre-configured values (choices) for the property. This is all very easy to do.

Probably the biggest difference with BigTable and traditional RDBMs is that queries using GQL (Google’s SQL-like query language) can not perform “joins”. Unlike RDBMs, BigTable uses a distributed architecture to manage scaling to very large data sets. Developers can optimize how data is distributed by describing relationships between data objects, and by defining indexes for queries. Defining a relationship is straight-forward, simply use a ReferenceProperty to another model instance. Defining indexes for query optimization is a little less friendly – both in how it is done and in how it is deployed on the App Engine service. Defined indexes are also required for sorting result sets (like date/time ordering).

Indexes are defined in the index.yaml file (part of an application’s configuration). Once you realize that and understand what needs to be indexed and why, creating the indexes is not too tricky. The nasty part comes during deployment. When you upload your application to App Engine, the service looks at this yaml file and builds the indexes. There are reports of this taking 24-36 hours! My experience creating a single index on created_datetime (so that I can sort query results) was not very positive. I ended up having to create 2 different “applications” on App Engine before I finally got it right. The first time, App Engine completed the index build in about 30 minutes but execution resulted in a terminal failure. I never figured out why! Finally, after some reading and experimenting, I was able to upload my Shrugh prototype and App Engine built the index in about 10 minutes. Here is the current version: Shrugh Development Version.

One quick sidebar, the Google AppEngineLauncher application for Mac OSX is really nice! It manages the local application server as well as uploading to the App Engine service along with log viewing and access to the App Engine Dashboard. Here’s a screenshot:

So, in just a few hours, I had defined a model for a Shrugh and wrote some code to display Shrughs in a decent layout with a little form to let users create a Shrugh and choose a type. Not bad!

May I trouble you one more time to run through the demo and give me your comments? Simply go to www.shrugh.com to get started.

About the Name

The overwhelming majority of you like the name Shrugh and even figured out how to pronounce it! A handful of people couldn’t figure it out, so here is the story on the name:

The name “Shrugh” stems from the concatenation of “shrug” and “ugh” pronounced Shru-ugh. A “shrug” is body language that is often used when a person is confused or indecisive. An “ugh” is an exclamation of “I don’t know” or “this is going to hurt”! Shrugh seemed like as good of a name as any, and the domain name was free and clear!

Demo Details

Many of you asked for more details about the demo itself. Well, as I wrote on my blog “Assembling demos from balsamiq Mockups” I use a product called balsamiq Mockups to design the screens (I blogged about Mockups here). Mockups creates static screens and has the ability to export them as PNG files. So I developed a technique using CSS styles to let me link static screens together to create a demo of sorts. That is how the Shrugh demo works. One handy trick that I just thought of and didn’t mention in either of my updates to the demo technique, is to show the “hotspots” while you are figuring out what their coordinates are. If you use my css source file “selection.css“, you will see a commented out style at the bottom. If you uncomment this style, you will be able to see your hotspots while you work on the demo! Just comment the style out before you present the demo.

Shrugh Demo Lessons Learned

The current Shrugh demo has 43 Mockups PNG screens and 48 HTML wrapper files. You’ll notice that the top of each page has a link to take the user back to the Shrugh Homepage. My friend Bob made that suggestion and it has been well received! I also added a Google Form to collect feedback directly as part of the user’s demo experience. It was very easy to create the form and it tabulates all of the feedback in a spreadsheet so it is easy for me to manage. Finally, I include a short description and explicit directions on what the user is seeing and what they should do next. That has really helped too.

One comment on demos done this way, they do result in more screens and user clicks than the actual product will have. The reason for this is that the PNG files are of a fixed size and trying to kludge vertical scrolling would have been time consuming. So, rather than have a single screen to create a shrugh, it is divided between 4 screens. It will be a simple matter to combine these elements on to a single screen and significantly improve usability. Thanks to all those who commented on this!

What’s Next?

While I’ve been developing the demo, I’ve also been looking at implementation technologies and platforms. I had narrowed it down to two – Ruby on Rails and Google App Engine. They are very different platforms, each with strengths and weaknesses. So, I did a rapid prototype on each to test capabilities and get a feel for them. I developed the same application on each – a simple Yes/No shrugh creation screen that saves the shrugh to a database and displays shrughs in a list. It was actually easy to build this on both technologies but in the end, I chose Google App Engine as the platform of choice for several reasons:

1. It is a new cloud computing platform and I am very intrigued with the future of cloud computing. What better way to learn about it than to actually develop an application for one?
2. Google App Engine currently supports the Python programming language and I already know Python.
3. Google App Engine also supports the Django Web framework. Both Rails and Django support the DRY principle but I really like Django’s URL scheme and templating. (Rails relies on 3rd party modules for more powerful templating, like Liquid).

I am also considering using Google App Engine to develop and host Shrugh. I already know Python and there are a lot of great attributes to cloud computing that would be fun to build on.

To that, I have an answer: look at the Mockups generated XML file! Here is an example for a Button:

<control controlID="23" controlTypeID="com.balsamiq.mockups::Button"
x="139" y="393" w="82" h="-1" zOrder="6" locked="false" isInGroup="-1">
  <controlProperties>
    <text>Push%20Me</text>
  </controlProperties>
</control> 

It will have the x, y coordinates for the top left corner of each item on the Mockup. For many, it will have the width (w) and height (h) too, however, if w=”-1″ or h=”-1″ it means Mockups is automatically determining the control’s width and height. In this case, you will just have to take a quick guess, try it, and refine until you get it right. Use the x, y, w, and h values as the starting point in your hotspot CSS markup. Test the demo page to make sure the hotspots are where you want them and tweak them if they are not.

Once you become familiar with the process and use my templates on the original post, it should only take a minute (or less) to layout a new Mockup demo screen!