Once in the web browser, the data has to be parsed and split up into different sentences based on what the user wants to do with the data.  Once the data is split into sentences it’s appended to divs that show the sentences in the web browser.  Some of these sentences have to be clickable, they must respond to a “click” event coming from the user.  This is completely ordinary in most JavaScript web apps.  The user clicks, the browser responds.  Imagine my surprise when my sentences weren’t responding to the click input.

I wasn’t surprised for very long, however.  By looking at how I prepared the sentence in the JavaScript code made it pretty obvious what was going on.

data[index] = data[index] + ". <span class=\"my_class\">" + choices[choiceIndex++] + "</span>";

This created the sentence that was to be clickable. It’s just string data that creates a span with a class. This is something jQuery can find by doing $(“.my_class”). Once I have all the spans with that class I can add a click event to them. Well, that’s true, but those spans have to be DOM objects before jQuery can find them.

The way I was doing it, those spans were just string data. Sure, the browser displayed them with the correct style but jQuery was unable to find them because they were not internalized as DOM objects. Opening a JavaScript console with Google Chrome would allow me to run the same code to make the spans respond to click events and it would actually work. Chrome’s console reads the DOM after the page has been rendered and creates the DOM objects based on the rendered page when the spans are in place. This is no good to me. I can’t tell my customer to tell his customers to open a JavaScript console and run this cryptic command after loading the page.

In order to get the behavior we want we have to create DOM objects using jQuery so jQuery can then find these objects to add the click behavior to them. Rather than creating spans as string data we use the jQuery function to create a DOM element with the correct class and text.

elm = $("<span class=\"my_class\">" + choices[choiceIndex++] + ". </span>");
elm.click(function(){
                  alert("Hey! You got the right answer!");
                  document.location = "http://localhost:3000";
                });

The jQuery function, $( ), first looks for elements based on the class, id or attribute selector passed in to it. If there is no selector then the function looks for any tags in the string passed in to it. If there are tags, in our case span tags, jQuery creates the appropriate DOM element based on the content of those tags! This is great! Now I can pass in my string data and have jQuery return a DOM element that I then bind to the click function specified.

Adding the click function later also works now.

$(".my_class").click(function() {
                  alert("Hey! You got the right answer!");
                  document.location = "http://localhost:3000";
                });

I’m happy with the way I can build a DOM element using the jQuery function. In order for jQuery to find the objects we look for those objects have to be DOM elements, not just string data appended to a div. DOM elements respond to events, strings do not.

Financially, for a small scale production or testing platform using the Amazon Web Services makes a lot of sense for a company whose core business is not IT-centric. Running a couple m1.small EC2 instances and paying for a backup to S3 or EBS is cheaper than purchasing a box and running the app in colo.

Since the start of the AWS platform I had the opinion that, as one starts using more and more EC2 instances and S3 storage space, there comes a point where it would be cheaper to bring the IT platform in house and hire a staff to run it instead of running on AWS forever. I have no idea where that point is, nor do I know of anyone with credibility who does. I thought the dollar amount where in-housing is cheaper is quite high.

I say those things in the past tense. At the risk of being accused of falling victim to Amazon propaganda, after reading the Economics of the AWS Cloud paper I think the expense of bringing a production app in-house for financial reasons alone is too great to overcome the benefits of using Amazon web services. What Amazon provides in terms of reliability, redundancy, management and scale can not be overcome unless you plan to compete with Amazon. This completely ignores in-housing due to compliance and auditing. AWS is not an option in that case.

The paper makes the argument that we can hit closer to 100% server utilization than an owned IT infrastructure. Though I’m not sure I buy this argument, idle CPU and unused memory are idle wherever they are, using a pay-as-you-go service implies someone might be more aware of hardware utilization because using more costs more in EC2. I guess the comparison is owning 10 boxes at 5% utilization vs. renting 2 EC2 instances at 60% utilization. Over 5 years renting EC2 instances at full price is cheaper than the capital expense of buying those 10 boxes.

The Power Efficiency and Enabling Redundancy sections of the paper are particularly important. Running a data center costs more than just the price of the computers in it. Power and cooling isn’t free. Rack space isn’t free. The investments Amazon can afford to make in improving power efficiency and data center design is much greater than most other data center owners can afford. If you can afford to make this investment you’re already operating at Amazon-scale – why aren’t you competing with them?

Based on the go-big-or-go-home data center, who should build data centers? CDNs, hosting providers, colo facilities and business that are subject to regulation? Is that it? As someone who has been using AWS and other hosting providers for years for small customers and doing hardware recommendations for existing, poorly designed, non-regulated company data centers for large customers, I’m partial to the AWS/hosted approach if there is not already hardware that can do the job on site. Hardware procurement in large companies is a nightmare and hasn’t changed since I started doing this.

So where are we headed with AWS? Are new tech startups going to forego hardware purchases and use AWS as their infrastructure? In the last year I have worked with a lot of people making that choice. What about existing small businesses? I haven’t done a lot of work where people are migrating away from their colo’d software and I don’t expect them to, at least until the next upgrade cycle. Upgrade cycle – that’s another thing Amazon handles “in the cloud” for us. Certainly a small business needs to be aware of the AWS option and I don’t have a lot of experience with the IT companies that small businesses out-source to.

Of course I expect (non-regulated) big business to continue building poorly designed data centers based on use-it-or-lose-it budgets. “Our team has 30 boxes sitting idle and we need to order 10 more!”

These were just some of my thoughts while reading the paper. Leave a comment with any feedback or your own thoughts on the Economics of the AWS Cloud paper.

A weeks back I helped a development team set up a testing environment for their Ruby on Rails webapp.  The webapp is about 18 months old and had exactly zero tests.  Reverifying its intended behavior was a full time job for some of the developers on the team because there was no way to prove any behavior worked as intended at any given time.  Worse, behavior verification was a manual process and obviously error-prone.

Repeatable tests that prove the software is correct are of high value to this customer.  Testing their application had to be easy.  Writing tests and running them had to be easy.  For an existing webapp with little to no test coverage a black-box testing approach provides a  lot of return for the effort.  Black-box testing allows behavior testing.  We test  webapp behavior by making GET and POST requests to the known URLs the webapp exposes.

Before we set up a test environment for the existing webapp we must decide how to exercise its behavior.  There are a plenty of HTTP libraries available for different languages and platforms.  When you don’t have any tests any testing is better than nothing.  Don’t be afraid if your initial testing framework doesn’t match your webapp language and platform.  We can just as easily test a JSF webapp hosted on Windows with a Ruby client on Linux.  In fact, diversity in the test environment is a good thing.  Multiple black-box clients show how a webapp will perform in the wild.

Automated webapp testing with the Ruby Mechanize library is very easy.  The Ruby environment with RubyGems is required to use the Mechanize library.  There are instructions for setting up a Ruby environment on the Ruby on Rails getting started page.  Follow the instructions for Ruby and RubyGems.

Installing the Mechanize gem is easy.  On Mac OS X 10.5 and Linux the command is:
sudo gem install mechanize

Once you install Mechanize you probably want to play around with it.  You can do so with irb, the interactive Ruby interpreter.  Start irb on the command line by typing irb.  We write Ruby programs directly in irb and irb executes each line as we enter it.  Think of it like a bash shell for Ruby.

Initially irb loads only the core Ruby libraries.  We need to load Mechanize manually with the ‘require’ keyword.

>> require 'mechanize'

I like API documentation in front of me when I code.  The documentation for the version of Mechanize you’re using is on your local box if you installed it with the gem install command as it appeared a few paragraphs up.  Start the gem documentation server by typing ‘gem server’ on the command line.  Now visit http://localhost:8808 in your web browser.  Click the rdoc link in the Mechanize section for the API doc.

The fun stuff happens in the WWW::Mechanize class.  Let’s go back to irb and create an instance of this class:

>> agent = WWW::Mechanize.new

Now we have an instance of an object that makes HTTP GET and POST requests.  Start up your webapp and we can make a request.  Starting with a GET request we call the get method on the Mechanize object.  The get method returns an instance of WWW::Mechanize::Page.

>> page.header.class
=> WWW::Mechanize::Headers
>> page.header
=> {"last-modified"=>"Tue, 16 Jun 2009 02:41:30 GMT", "connection"=>"close", "date"=>"Fri, 17 Jul 2009 00:42:43 GMT", "content-type"=>"text/html", "content-length"=>"7466"}
>> page.body.class
=> String
>> page.body

Go ahead and enter page.body.  I omit the output here because it is a little long.  What you should see is the HTML of the web page you requested with the agent.get(…) method.  agent.get(…) assembles the HTTP headers and makes an HTTP GET request.  This method crosses the network if your webapp runs on a different box.  You can test remote webapps just as easily as local.

Play around with the API.  Next time we’ll cover HTTP POST requests.

Building software modules within a team requires communicating, at a minimum,  method or class signatures and a general idea of the functionality.  This may include a detailed design document clearly specifying method signature and a pseudo-code implementation or method stubs and comments about what the method should do right in the source file.  One thing that should never be used for communicating a signature and functionality is dummy code.

Dummy code looks like real code.  It is real code but it rarely works.  Even if it compiles it doesn’t produce the correct result when run.  Nor are there any tests that prove it (in)correct.  Dummy code exists only for the sake of its author’s gratification.

Rather than talk about the desired functionality through some more productive means the dummy code author thinks he is helpfully providing a guesstimate of correct implementation.  What he has actually done is provide a jumbled mess of non-working code cleverly disguised as a working part of the project when he checks it in to the SCM.  The dummy code author thinks someone else will come along and provide the correct implementation “later”.

What he doesn’t realize is that his dummy code is almost indistinguishable from code that should be part of the project.  The next person to try to reuse this code is in for hours of WTF moments trying to figure out WTF the code is supposed to do and why it’s got code branching five levels deep.

At my first post-college job I had a wonderful mentor.  Thys (pronounced Tays, like “taste” without the second ‘t’) and I were talking one day when he asked me a question.  “Anthony, if you were given a task of writing software that would only be run once would you do it quick-and-dirty or with a well-measured, engineered approach?”

How bad could “quick-and-diry” be if the software would run only once?  I thought about it for a moment before answering.  Quick and dirty.

Thys said he would never write quick and dirty software.  Doing so figuratively creates a  monkey on the developerment team’s back.  The software that only needs to run once inevitably needs to run a second time and a third time and eventually run regularly.  Thys helped me realize that software evolves and escapes.  Useful software will run indefinitely.  Any time and effort saved on the initial write will be lost 10 times (I made that number up.  It is actually higher.  Any want to provide real data or examples?) over on the maintenance, bug fixes and rewrites.

Writing dummy code is writing software quick and dirty without any idea of the implementation details.  Bad code and bad algorithms.  The worst of both worlds.  It’s been a long time since Thys and I had that conversation but the years have proven him right again and again.  Any code worth checking in to SCM is worth writing well.  That includes unit tests.

Dummy code has no place in SCM.  If you’re not going to correctly implement a method you stub out then don’t provide an implementation at all.  Leave some comments around the method stub if you have to.  Open a ticket in the issue tracking system to let someone know the method needs an implementation and describe the input and output.  Let the implementer determine which algorithms and data structures to use.

Dummy code is a hazard to software projects.  It violates the principle of least astonishment.  Next time you think about writing some remember that the next person that uses the code will waste time figuring out why it doesn’t work as expected.

If you check code in to your SCM where other people can pull it, take a look at what you’re checking in.  Does it work?  Does it work well?  Are there tests that prove it?  Helping someone by coding less is sometimes the best help of all.

I took on the project of integrating the start-up application with an application made by one of their customers.  The start-up application was running an instance in production for another one of their customers.  Part of the project was defining and building a RESTful API that both my customer, the start-up, and their customer could use to communicate between applications.  The API had to include comments made to different event types.  When someone makes a comment on the start-up app it gets propagated to their customer app.  When someone makes a comment on their customer’s app it would be sent to the start-up’s app through a RESTful API call.  It would be similar to having Facebook and MySpace synchronized on your status updates.  Update your status on Facebook and MySpace reflects the change too.

As I built the API I found that their comment model didn’t work.  I looked back a few months in the SCM and found the methods in the model hadn’t worked in months.  Comparing that version with the previous version showed that everything except the class definition was new.  The comment model never worked.  The comment model had no unit tests to verify its functionality is correct nor did QE raise any questions or file any bugs on it.  The developer never actually ran this code.  The mistake would have been obvious if they took the time to run it.

Asking if anyone knew that commenting didn’t work was met with blank stares.  “No, it works.”  I asked them to demonstrate on any environment they had set up.  I hoped I was wrong and I didn’t have my environment set up right.  Leaving a comment failed every time on every environment.  I found out someone checked in a fix “last week”, but that developer never bothered to run the code either.  I don’t know how he verified his fix.  No one could leave comments anywhere, not even in production.  Yep, this code was broken for months in production for another customer and no one noticed.

I finally found out someone was “cleaning up” the comment functionality.  I asked about the precautions the developer is taking with this bug and was told something I already knew – how to “temporarily” fix it while the developer worked on the “clean up”.

Fixing the bug was beside the point.  This company needed to figure out a way to prioritize development.  Priorities save developers from wasting time building software that no one will use for months, years or ever.  Part of the start-up mentality is “throw stuff against the wall and see what sticks” but at the cost of basic functionality?  That’s a poor implementation and a poor business decision.

Getting off to the right start in a project is critically important.  Automated test frameworks are available for every major software development platform.  Not using them right at the start of a project makes it impossible for meaningful tests to be added later.  Not difficult – impossible.  We don’t use the strict  “waterfall” methodology anymore because testing after development is complete doesn’t work.  As a community we have known this for a long time.  Short, tactical releases are the way to go.  These short iterations are the perfect time to write tests with or even before writing the software.  Test-driven development and behavior-driven development are hot for a reason.

A long time ago I picked up some work for a shop that had a test-first mentality as part of the culture.  Before day one at this company they decided a test-first approach was the way to go.  Every developer was held to unit-testing their own software.  They also didn’t build any software that wasn’t needed for the current iteration.  Looking to build functionality needed “in the future”, they learned, was a waste of time.  That future never came.  Instead they used that time to test the software that was needed for that iteration.  They typically had well-scoped projects and were customer driven.  They had a lot of customers.  Somehow they found a way to please everyone.  Short, planned, targetted releases made those guys a lot of money and it was a pleasure to work with them.

I was doing some work for a startup where I got to see the CEO warm up for his series B funding pitch.  He wanted to do the actual presentation he would give investors with an audience.  He invited me, the developers and some people in marketing to the practice talk.  He wanted us to think like the investors and ask some difficult questions about the company, product and business plan.  When asked about the kind of people he needed to hire for his plan to work the CEO quoted General Erich von Manstein to illustrate his point.

There are only four types of officer. First, there are the lazy stupid ones. Leave them alone, they do no harm. Second, there are the hard-working intelligent ones. They make excellent staff officers, ensuring that every detail is properly considered. Third, there are the hard-working, stupid ones. These people are a menace and must be fired at once. They create irrelevant work for everyone. Finally, there are the intelligent lazy ones. They are suited for the highest office.

The CEO claimed to the the fourth type of person, intelligent enough to make the big decisions and lazy enough to delegate the actions to someone else.  I’d like to think I work with reasonably bright people so I didn’t have a problem accepting his claim.  Moving on to the dumb and stupid, the CEO said he would never work with someone he classified as such.  They are a waste of capital and management.  They produce no results.  I tend to agree.  I never accept work from someone I deem waste of my time.  The stupid and hard-working produce results but leave so many problems in their wake that the intelligent and hard-working have to clean up after them.

The intelligent and hard-working are the people the CEO needs to bring his business plan to life.  His argument, though, was poor.  He claimed the intelligent and hard-working aren’t actually intelligent.  If they were intelligent they would be intelligent and lazy making the big decisions.  The intelligent and hard-working, he argued, are just smart enough to not create a mess of problems while they work.  They’re nothing more than worker bees who know enough to listen to his direction and not smart enough to make a decision, develop an idea or even communicate with other people like he could.  He only wants to work with the intelligent and hard-working because they were the ones that would do his bidding but they are not smart enough to question him.  He said this in a room full of people he worked with, his employees.

I looked around at their faces.  Some were shocked he would so openly insult them.  Some were disgusted by what he said.  Others showed disappointment.  Disappointment in I don’t know what.  Maybe they were disappointed in themselves for coming to work for a man that thought so poorly of them.  Either way the company morale plummited.  No one missed the implication of the CEO’s words.

Perhaps he is a very bold man.  Or he might not have realized what he said until it was too late.  Either way he seemed unfazed by the fact he deeply insulted everyone that worked for him.

The company failed.  Series B never materialized and he laid off all of his worker bees a few weeks after the warm-up talk.

The ethical treatment of robots comes up a few times a year.  I always groan with the same response.  People from all over the world, typically people who should be well-educated enough to know better, argue that robots are people too and therefore deserve human rights.  Wrong.  Robots, more correctly androids are inanimate machines.

When we talk about the ethical treatment of robots we always bring up Isaac Asimov’s “Three Laws of Robotics“.  With all due respect to Mr. Asimov and his work, those laws don’t apply to reality.  Asimov was a science-fiction writer whose work was produced nearly 80 years ago.  The android subjects in his stories had positronic brains which exist only in our imaginations.  The machines in Asimov’s stories have consciousness that gave them cognitive and emotional abilities equivalent to the human brain.  He called them robots but they aren’t robots as we know them.  They are alive.

Creating living machines like those in Asimov’s sci-fi requires a real-life Pinocchio tale.  We don’t have the power to grant life to machines we’ve created.  Nor do we have the goddes Aphrodite to bestow life upon a modern-day Galatea.  Anyone looking to have a romantic relationship with an android won’t find one.  It might pass a Turing test but the love is unrequited.  Relationships with androids, romantic or not, are a charade and will remain so for the foreseeable future.  To illustrate this I’m going to let you in on a not-so-well-kept secret of software engineering.

Software engineering teams build software that is “good enough”.  Successful software is typically the software “good enough” for most people.  In a number-crunching application we can take two approaches: find the correct, exact answer or find an answer that is “good enough”.  Finding the exact answer takes weeks of computation time on a server farm.  Find an answer that’s “good enough” takes five minutes on commodity desktop hardware.  When faced with this choice we take the answer that’s “good enough”.  But that answer is not actually the answer.  We accept it as the answer.  All but the most trivial software takes shortcuts like this because the effort to arrive at an exhaustive answer just isn’t worth it.  In essence we’ve been fooled, but hey, it’s “good enough”.

Androids function exactly this way.  They don’t feel love, anger, happiness, fear.  At best the software could produce actions that we associate with those emotions.  This is just an approximation, though.  It’s “good enough” to fool us into thinking the android has experienced emotion.  In this way the android will never suffer.  Producing actions and facial expressions associated with suffering and happiness and producing the emotions suffering and happiness are so different they are in entirely different fields of study at this point.

While androids lack the “real thing”, the essence of that makes us alive, there can not be intelligent debate on granting them rights.  Sophisticated as they may be they are approximations of homo sapiens sapiens.  We have created them in our image but we can not grant them life.

The brewing process starts with creating koji-kome, a malt rice.  The koji-kome is rice with a fungus growing on it.  This fungus is what turns starch to sugar and sugar to alcohol.  Creating the koji-kome seems like a delicate process and I almost threw out the first batch because it didn’t smell quite right after the 40 hour growth period.  I washed the rice until it was white and there wasn’t any sediment in the run-off.  That took longer than I expected but I had no frame of reference for how long it would take.  I never washed rice to the point of spotlessness before that day.  I just put the rice in a fine strainger and used the sprayer on the kitchen sink to wash it.  I shook the strainer to move the rice around and get at the unwashed rice.  The rice should be white when it’s clean.  More white than white paper.  Putting a clear glass under the strainer to catch the runoff should give you a clear glass of water.

Soaking the rice for 90 minutes was the easiest part of the whole process.

Steaming the rice, on the other hand, proved to be a little more difficult than I expected.  I thought my vegetable steamer would be plenty big enough.  Steaming the rice sterilizes it so that only the koji-kin mold grows on it.  I found out later that I could have just used the rice cooker, though steaming gives better results.  The steaming tray on my steamer has large holes in it, much too large to keep the rice from falling through into the boiling water.  I put a flour sack cloth into the steaming tray to keep the rice from falling through.  The flour sack is a very thin material that doesn’t impede the steam passing through and into the rice.  The cloth was also useful in keeping the condensing water from falling onto the rice.  I created a little pouch for the rice to sit in with the cloth and then put the cover on and let it steam for about 70 minutes.  At the end of the steaming process the rice should be slightly transparent or tan.  I wasn’t sure the color was right but I continued anyway.  My steamer may be too small to steam all the rice in 70 minutes.  The amount of rice in the recipe was a tight fit into the tray.  I wonder if a larger steamer would steam the rice better.  After cooling the rice I sprinkled the koji-kin mold on it, placed a damp flour sack cloth over the container and let it sit on a heating pad set to low.  

Not sure that I did everything right I started a second batch of koji-kome the next day under my wife’s supervision.  I hoped to rectify any mistakes I made with the first batch which I suspected would not produce the moldy rice I wanted.

This is where I almost threw out the first batch koji-kome.  It seems like the heating pad, even set to low, was too warm for the rice and it appeared to dry out.  Mold needs a dark, damp location to grow and I thought the rice got too dry during this time.  At the end of the 40 hour growth period I didn’t think the rice had the strong cheese smell indicated by the recipe.  Rather than deal with it immediately I went to work.  When I came home Christina told me the rice reeks and I needed to deal with it.  I took a sniff and really stuck my nose in there.  Smelling the strong cheese smell made my day!  It seems like the first batch of koji-kome worked after all.  Maybe the mold needed a few extra hours.  Maybe my nose was stuffed up in the morning and I couldn’t distinguish the mold smell from the rice smell.  Though the recipe says it is a strong cheese smell I think it was mild.  I decided to continue with the first batch of koji-kome.

The second batch of koji-kome should be better than the first.  After steaming it I kept it warm by filling two 2-liter Diet Coke bottles with steaming hot water.  I turned the kitchen sink to as hot as it would go and let the water run until steam was coming from it.  I put these bottles under the koji-kome container.  The container had a damp flour sack cloth on top of it, then I put the lid on the plastic container as best I could.  It wouldn’t snap into place due to the damp cloth hanging over the sides.  I put the container on top of the bottles and wrapped them all in two beach towels I arranged in an X shape.  I replaced the water in the bottles with steaming hot water every 8 hours or so to ensure the temperature stayed as close to 86F as possible.  

With my malt rice ready to go I had to steam another 3.3 lbs of rice.  This is the rice that will be turned to sugar then alcohol during the brewing process.  The 0.9 lbs. of rice used to make koji-kome was about the limit of what the vegetable steamer could handle.  The 3.3 lbs. of rice for brewing was way too much.  I decided to divide and conquer.  I put 1 lb. of rice in the steamer and the rest in my fine strainer.  The strainer was precariously balanced over the largest pot we own.  By the way, I didn’t actually weigh the rice in any of the steps in the recipe.  I eyeballed everything and verfied by putting it in my hand and saying “close enough”.  I left the steamer and pot of boiling water for about 70 minutes and hoped for the best.  

When I came back down to check on the rice I found the rice in the steamer looked about the same as the rice for the koji-kome.  Checking on the rice in the strainer/pot combo I found that, whoops, I melted my strainer.  The handle is now a nice L shape.  As the handle melted before my eyes the rice approached the boiling water.  I had to rescue the rice before it was immersed or it would be unusable.  I got the strainer out before it was fully submerged.  Only a little bit of the rice on the bottom contacted the water.  That rice immediately turned to mush and was easily separated from the steamed rice.  I lost a miniscule amount of rice to the boiling water.

Like I said, I didn’t actually measure the rice or water during the process.  I may have used slightly more than the 4 liters of water in the recipe.  It wasn’t much more but it may have watered down the end product.  I won’t know for sure until I use the second batch of koji-kome.  I estimated 4 liters of water by using two sterilized 2-liter Diet Coke bottles.  

I left the mixture of koji-kome, water, citric acid, rice and yeast to brew for 10 days.  I mixed the ingredients on a Monday night and bottled the sake the following Thursday night.  Most of this time the mixture smelled like yeast.  It didn’t actually start smelling like sake until Sunday.  I bravely decided to try a couple teaspoons of the mixture to see how it progressed.  It tasted the best on Wednesday night before bottling.  It was very sweet and a pleasure to drink.  I got a bit braver and tried a mouthful.  I swished it around in my mouth and looked for the sweet, slightly bitter taste.  I was very happy with the brew and I consider that the taste’s peak.

On Thursday I thought the flavor declined in my after-work tasting.  The sweet flavor was not as pronounced and the bitter flavor was more intense.  The rice in the brew turned into a white paste-like gelatin.  Because we had only one pot large enough to hold the brew I had to use several smaller pots to strain it.  I used the large spaghetti strainer to filter the rice out once I got the brew to a more managable volume.  After using the spaghetti strainer I ran the brew through my melted fine strainer to get the last of the large sediment out.  The resulting liquid was cloudy just like the recipe said it would be.  

I pasturized the sake in order to kill the yeast and preserve the sake long enough to enjoy it.  I put the sake back in the large pot and put it on the stove for about 20 minutes.  The sake needs to be heated to 145F to kill the yeast.  I had about 3.5 liters of sake and getting it up to 145F took about 15 minutes.  After I pasturized the sake I had another mouthful.  The taste improved dramatically.  Killing the yeast seemingly turned the clock back by a day and the sake tasted closer to Wednesday night’s tasting.  I used the same sterilized 2-liter Diet Coke bottles for the sake.  Don’t worry, I got the nasty Diet Coke flavor out of the bottles before pouring the sake in to them.  

After spending Thursday night and Friday in the fridge the sediment in the sake fell out of the solution.  Most of the flavor in the sake comes from the sediment though.  Looking at the sake through the bottle there was about 15% of the solution on the top and the bottom 85% of the bottle had the settled sediment.  After dinner I pulled it out of the fridge, shook the bottle and poured a glass.  Served cold the sake tasted fantastic.  I poured a second glass when I was done with the first.  The quality of the sake is very high which surprises me.  I was unsure of how well it would taste while it was brewing.  I’m excited to start the next batch tomorrow.  Once I figured out what I was doing the process was enjoyable.  I’ve worked out the first-time problems which should lead to even better tasting sake the next time around.

Here are some of the topics I want to talk about:

• Data growth and access – What kind of DBMS topologies allow maximum scalability without breaking the budget? What if the budget wasn’t a problem? How do you migrate your data model from hundreds of users to millions of users? Should you partition user data across shards or keep it in a central database? How do you profile data access paterns? Is your application mostly-read or mostly-write? When should you use an LDAP directory for data storage? When should you use MySQL and when should you use Oracle?
• Application server scaling – app server clustering, web server integration, load balancing, application session management, data caching
• Web Tier – load balancing reverse proxies, data caching, working with HTTP, considerations for exposing functionality via REST
• Language conisderations and platform choices – Dynamic languages vs. Static languages, Linux vs. Windows, Solaris vs. Linux, RedHat vs. Oracle, IBM vs. Oracle – How do you make these choices? What evaluation critera are most important? Which ones are misleading?
• Framework scalability – How can you scale if your framework can’t? Does Rails really scale better than Spring Web MVC? Where do PHP frameworks fit in? What are the alternatives? This is where we will investigate what you gain and lose by binding yourself to a particular framework, how to keep the coupling to a minimum and how to use your framework as a solid foundation instead viewing it as a cage.
• Emerging technology – Should you become familiar with Map Reduce and Hadoop? What kind of impact do object databases have on your application? Should you buy your own Sun or Dell boxes or use Amazon’s EC2 and S3?
• Application architecture – How do you write an application that scales? What does your application look like as it grows from servicing hundreds to millions of users? How does it handle session management? How does it access datastores? Are there any design patterns that are helpful? What are the anti-patterns to be aware of?

Like I said, I haven’t found a group dedicated to discussing these topics. If you know of one in the Boston area please let me know. Assuming there isn’t one I am willing to start one. I’d like to start off small and meet at coffee shops around Burlington or Lowell. I have no delusions that this is going to start off or even become as big as NEJUG is now. If it starts off as a few people getting together to talk about scalability trends, cool caching solutions and specific products then I’d call it a good start.

The meeting location is still TBD and will be based on how many people are interested in attending. It will probably be somewhere in Burlington, MA. There is no planned presentation at this time. Instead we will have a meet and greet and then discuss scalability trends and news, what approaches to scalability are commonly used now and what are the plans for the future.

If you are interested in coming or in finding out more information please email me at <my first name>@<my domain name>.<my tld> or leave a comment below. Please make sure to include your email address when you fill out the form so that I can get in touch with you – your email address will not be displayed on my site.

• Intel Core 2 Duo 1.6 GHz T5200
• 2 GB Dual Channel DDR RAM
• ATI Mobility Radeon X1400 256 MB RAM
• 80 GB SATA 7200 RPM hard drive
• 15.4″ WSXGA+ screen

and…

• Windows Vista

So far I’m pleased with the quality of the computer. Even with the 9 cell battery it’s much lighter than my Toshiba Satellite, I’d say by a good 3 lbs. The only place where it feels flimsy is on top of the laptop when it is closed. The CD/DVD combo drive is silent! In comparison my Toshiba sounds like a 747 using my desk as a runway whenever media is in the drive.

Visually I’m very happy. The maximum screen resolution is 1680×1050 and I love it. I had some reservations about my eyes being able to handle a resolution that high on a 15.4″ screen but so far there are no problems. The increase in resolution from 1280×800 to 1680×1050 is almost as exciting a leap as 640×480 to 1024×768 in 1997. I just did a quick calculation and it seems like I’ve got about 72% more viewable area now than on the Toshiba and it’s a huge, noticable difference. If you have the choice and the $100 take the upgrade to WSXGA+. Aero, the user interface for Windows Vista looks great on this screen powered by the Mobility Radeon X1400. I haven’t got too much into Aero’s functionality but the eye candy does not (yet) distract me from my work (because I haven’t done much on this laptop yet). I’m not sure Aero adds much more functionality than the “3D switch windows” featurette, but like I said I haven’t got too far into it yet.

I installed Java 6 and Eclipse 3.2 tonight and it seemed to go smoothly. I dislike the Windows Vista security “feature” that asks me if I’m sure I want to run this program five times when I tried to run the installer for Java 6 and the My Book Pro II RAID software. Unzipping the Eclipse 3.2 archive went fairly quick, but I don’t have any hard numbers to share with you. Go to Tom’s Hardware if you want stats that badly. Unzipping a large archive like that would have taken at least five minutes on the old laptop but took less than two on the new one. The processors were both at less than 50% utilization for the duration of the unzip.

The keyboard and touch pad/buttons feel nice. The keys have some resistance so you know you’re pressing them. The touch pad buttons are actually real buttons that depress rather than previous generation laptop buttons that barely move when pressed. The touchpad also has horizontal and vertical scroll bars on it to make scrolling easy without having to move your hand back and forth across the touch pad a few times.

After just a few hours of use I’m very happy with my new E1505. I haven’t tried out all of its features yet but so far so good. Hopefully this post illustrates some of the nicer features I’ve found so far.

I plugged in the My Book Pro II I got on Monday and setup was just as easy as it was on the other laptop. Transferring files to and from it was quick and easy, as it shows up just like another hard drive in Windows Vista. To make the deal even better, the E1505 and My Book Pro II are the same color.

Tomorrow I’m going to drop my Toshiba Satellite laptop off to get repaired since it is covered by a new warranty due to a class-action lawsuit. This weekend I’ll spend a little time repurposing the old desktop to be a dedicated database and application server playground.
I’ll get back into writing more software now that I have a working computer again, which means I’ll also be posting more regularly as well.

Thanks for reading. Let me know if sharing my thoughts on the Dell was helpful or useless.