Every attempt I have read about involves brute forcing, be it using CPUs (locally, in the cloud, or distributed) or GPUs. If the contest can be won simply by having the most computing power at your disposal, or by sheer luck, then its really not very interesting. Let’s assume that Engine Yard gave some subtle clues about how to do better at guessing than pure brute force. Since everyone is brute forcing the same answer space, how about at least trying to start at an interesting place in that space?

So here is my attempt at constructing a nice, convenient rationale for ‘where’ to begin searching.

Engine Yard is clearly trying to promote their business and their hosting services.  They suggest using the cloud to access lots of processing power.  The prizes you can win are an iPhone 3GS and $2000 of hosting credit.  Engine Yard suggests that you use brute force with a fast SHA1 algorithm.  

Let’s make some assumptions:

The cost of an iPhone 3GS will ‘exactly’ cover the cost of using the Engine Yard virtualization services long enough to find the exact/or best answer.  An iPhone 3GS, without a ATT service contract costs from $499 to $599.  The cost of the Engine Yard ( http://www.engineyard.com/docs/EY_Managed_Hosting.pdf ) Slice is $399/month (plus a setup fee), the cost of a Fractional Cluster is $599/month (plus a setup fee).  In order to spend $499 to $599 in 30 hours (the length of the contest) using Engine Yard Services you would have to have roughly 30 instances (Using 1 months credit in 30 hours).  An instance contains either 1 or 2 VCPU that are equivalent to a 2.4-2.6 GHz Xeon.  From this paper (which just happens to have used a 2.6GHz Xeon CPU) (http://www.cs.ucr.edu/~bhuyan/papers/ssl.pdf) you can find the CPI of a fast (maybe the fastest known?) SHA1 algorithm.  The CPI is 10723.  Lets assume that you can also find the CPI, or closely approximate it for a Hamming Distance function.  That takes care of two steps of a program that brute forces hashes.  The other steps are, permute the dictionary/words, and compare the score to the stored ‘best hash score’.  Let’s say you can approximate the CPI for these functions, which would give you a sort of ‘time to calculate and compare a single permutation’.  Once you have that, you can figure out how many permutations 30 2.6GHz Xeons could crunch through in 30 hours.

 
Assume that you start at the beginning of the 1000 word list and also use the allowed 5 random digits, and do every permutation of random digits and capitalization, in a systematic way.  You can estimate from the CPI calculation about how many permutations you can get through.  You should be able to then calculate which sequence of words, random chars, and caps that permutation would be.  Maybe you can estimate your error in calculating the number of permutations, and start brute forcing from a lower bound number of permutations.

Why does this make any sense at all?

Well, it doesn’t really.  It would just seem to be somehow poetic if the answer hash could be found by using one months worth of Engine Yard processing in 30 hours and you were rewarded with an object that cost the same amount as the services used to win it.

Since everyone else is brute forcing away, you might as well make some assumptions about an interesting place to start.  These assumptions make some sense from what we know about Engine Yard servers, the contest, the answer space and maybe what would make sense in terms of the value of a prize that would equal the outlay of cash or compute resources for a ‘perfect winner’.

Richard Stump, of the Kentucky Startup Blog wrote an informative piece on FlowMingle.  KSB is one of our regular sources of information about business going-on in the home state, and it’s an honor to get a mention.

.. you don’t have as much time to blog.

Blogs and Online Dating

That isn’t to say I don’t have time to read other people’s blogs.  One that speaks to my own heart, and is tied in not only with online dating but also much geekery is Geek’s Dream Girl.  There’s a series on online dating etiquette that’s a must read for everyone looking for love online.  While a few of the articles don’t apply to FlowMingle’s type of online dating, they’re all worth reading—it’s unlikely we’re your only stop on the online dating express.

If you have a minute, weigh in on her trigger words article.

Using google blog search I sometimes peruse the b’sphere to see what people are writing about online dating.  Articles are not usually enlightening, but sometimes amusing, such as this gem by The Hypocrite Bastard.  It’ll be interesting to see how that potential saga plays out.  More often, people using sites we consider somewhat dated are frustrated with their experiences.  If only they’d come to us.  

Mourning RailsConf

I didn’t get my stuff together in time.  I have no excuse.  As much as I’d have like to attend railsconf, there was simply too much going on and not enough free capital in my budget.  Maybe next year.  Here’s hoping.

Search Engines and Online Dating

On the internet, page rank is king.  For a growing site, it’s something we have to seriously consider, and search engines are getting smarter.  No more linking through traffic sites full of unrelated content (see the cautionary tale of JustSayHi, and, no, I’m not linking it), no more getting rank out of cute but inappropriate widgets.  It’s about content—and our focus (online dating and group dating) is a quite crowded space.  At the end of the day though, that’s where traffic comes from for a site like ours: search.  What makes things somewhat difficult is that most of our content is members-only, and as such not crawlable or searchable.  Nuts.

Ladies: Be In Our Focus Group

My partners and I are guys, and while our geekery varies (I’m an RPG and computer nerd), the fact that we’re a geek remains.  We’d like very much for some brave ladyfolk volunteers to help us figure out what’s the most intuitive Mingle interface, and we’ll throw in a t-shirt as tempting bait.  If you’re interested, mail me (ben@flowmingle.com) and I’ll get you set up.

FlowMingle is composed of a lot of moving parts, which we try to farm out as much as possible.  It’s my sincere belief that the days of hosting your own web app are dead and are rapidly being buried—I am having a hard time conceiving of a scenario which requires dedicated, owned hardware in a rack that’s physically accessible.  So here’s what we’re using to get the job done, and you’ll sense a theme: minimum hassle.  We don’t have much time to worry about the incidentals, so we go with what’s easy; whatever gives us the most bang for the least money, work, and irritation.

SliceHost

We’ve been slicers from day one, and have yet to have problem #1 (even when I’ve forgotten to pay the bills).  Slicehost hosts our web, mail, and database servers courtesy of Ubuntu 8.04.  We want bigger slices, they grow.  Smaller, they scale.  All through an effortless interface, and at resonable rates.  We host at least one Ubuntu server there at any given time, and it covers our needs with some change to spare.  When we need more, I have no doubt SliceHost would be happy for more of our business.

Amazon S3

The greats say content delivery is key, and we agree.  Our images are served via Amazon S3, and if CloudFront had reasonable image versioning and cache proposition, we’d be using that as well.  The aws-s3 gem syncs whenever we deploy, so management is non-existant. We maintain separate buckets for development, staging, and production.  When we need to access things directly, or set up new stuff, our tool of choice is Transmit.  Mostly the CDN is for the benefit or our users’ photos and images, but it’s nice to have the 128K worth of media making up our home page just as fast.

Google Analytics

Sure, but it works for us.  We’ve looked at GetClicky, and a few other solutions, but there are problems with each.  The most reliable, if not the most up-to-the-minute is still Google Analytics. At some future date, we’ll be doing more detailed analytics, but for now this cuts the mustard.

Basecamp

One of the toughest things about a startup is keeping everyone on-task and on-message.  The tighter the message, the greater the tendency to want to add to it.  One solution is keeping a solid task list.  Historically, we used Trac for much of this, but we signed on to Basecamp about a year ago.  Straigtforward, easy to use, and no-nonsense.  We probably use the to-do lists feature more than anything else, though we collectively compose docs on the Whiteboard.

Github

I know, right?  Git has simplified our lives significantly.  Github imported all of our old repos without a burp.  It gets the nod.

Integrity

Possibly the most hassle of anything so far, but not so much because its fundamentally incorrect, but our code wasn’t geared toward continuous integration.  Integrity’s setup was almost dirt-simple, but digging around for answers is time-consuming.  I can forsee a time in the near future when we’re going to need a little more than integrity provides.

That’s the setup.  How do we actually develop?

RubyOnRails

Given the choices, it fit the best.  Wide user base, easy answers, lots of people working to solve its problems.  Plenty of plugins to make our lives easy.  Go.  We deploy on nginx and thin, and host data via mysql. There are a blue million plugins we take advantage of, but in the words of Alton Brown, that’s another show.

TextMate, vi

There simply are not enough good things to say about TextMate.  While not presenting full IDE capabilities (at least, not without several bundles) it gets the job done admirably.  I use vi quite a bit for quick edits, or remote edits, but the lion’s share of programming work takes place in TM.

CssEdit, Photoshop, and Fireworks

While CSSEdit isn’t strictly a graphics application, it’s invaluable in getting the CSS right.  Photoshop (Phil’s tool of choice) and Fireworks (mine) get a lot of use in image composition.

Firebug

I don’t think we would live without Firebug.

That’s it.  If there are questions, direct them to the usual places.

There are substantial communities online devoted to helping people find personal and communal solutions to dealing with gaming addiction, including addiction to World of Warcraft. I want to take the time to share what has been helpful to me. Keep in mind, I think that WoW is a great game and is not a pure time suck. If I didn’t have people, hobbies, or work that I cared about; if I didn’t have the real desire to be free of WoW, I’d be leveling my characters right now, ad infinitum. At a later date I will write about the virtues of WoW and how its structure can inform social media, and help to move forward many forms of online interaction.

For real diametric personal change to take place, you first have to disgust yourself — see that your current way of living is not helping you become a better person, and is in fact hurting you.

To understand game addiction it is first important to dissect why the game is so enjoyable. This will undoubtedly be different for many people depending on play style, if they use the medium to socialize, what their in-game objectives are, etc.

• Simple tasks / reward system
• Vast world to explore
• Interaction with other players
• Simple problem solving / Effieiency
• Desire to figure out the logic and psychology of how/why the game works

People will find that WoW addresses and rewards many facets of their intelligence — and this is very enjoyable but can build addictive behavior. For example, I am a person that strives to be very efficient especially in computer related tasks, and I enjoy problems that challenge me to be more efficient — like programming with a DRY (Don’t Repeat Yourself) methodology. If I could be satisfied leveling at a slow rate, and if I didn’t mind taking the round-about way to complete a WoW task, then perhaps I would have an easier time turning the game off after 2 hours. Instead, whenever I would stop playing for the day, I would still be thinking about how to make my next day’s playing more efficient, how I could alter my spell sequence, how I should plan my quest route, what it would be like to level this other class using this talent tree? These are fine things to think about while playing, but when I’m not playing WoW, I don’t want to be playing WoW.

In a world of thankless jobs, long and difficult projects, bill payments, debt, high-school (if you’re still there), ennui, depression… it’s so enticing and enjoyable to disconnect from that world and plug into Azeroth where the problems are easy to solve, the tasks don’t take long to finish, and the rewards are frequent. The real challenge and opportunity involved with playing WoW (as it is with any drug) is applying what you have learned and experienced from the fantasy world (inebriated/altered mental state) to your real, sober living to make you a better person. But this task becomes impossible when the fantasy/inebriated world and the real/sober world become inextricably linked because you never really leave the game.

How to Quit

 

At first I thought that by simply understanding how the game worked, by understanding that from 0-80 it’s all the same (kill mob, collect nut, talk to dude, PvP, get on boat, visit trainer, repeat) that I would be able to put WoW down easily… but it didn’t happen that way.

• Play A Private “Fun” Server
  Because my goal was to use all the spells and deep talents of every class, and I knew that I didn’t want to spend every waking hour playing, the solution for me was to play on private “fun” servers that had x20 XP, instant 70, or whatever. If you can get yourself tired of the game this way, then I heartedly recommend it.
• Have Something Interesting and Engrossing At Hand
  When you are quitting it’s important to have something really substantial to take the place of WoW. And it’s equally important to be disciplined about doing it, building this new habit. Reading was very helpful to me because I could pick up a book whenever I wanted. If you haven’t read Dune, by Frank Herbert, get it, have it ready — it would be a great option. This book illustrates a world lightyears more fantastic and rich than Azeroth, and the writing and story is excellent. Other books to consider: Any of the Audubon Field Guides, The Mists of Avalon, by Marion Zimmer Bradley; Siddhartha, by Herman Hesse; The River Why?, by David James Duncan… have your trusted book friends recommend a few.
• Delete The Game
  Of course Blizzard will keep your characters around should you start up again, but deleting the game is more about keeping the temptation of playing from sucking you back in while you’re involving yourself in something else that’s equally or more interesting.

Postscript

As I was thinking about this post and reflecting on my experience, part of a poem by the late A. R. Ammons came to mind:

the form forms and if you’re

empty space only, the form is open
to artificial, say, irrational, say,

mad fixations that drop into your
bowl: arrange a full life or

the terror of emptiness will fill
emptiness with terror: love’s the

best filler but isn’t cheap and
anyway money can buy only a semblance:

if your forms aren’t full of love it
doesn’t matter what they’re full of:

excerpt from 52 from Glare
by A.R. Ammons

according to sramana mitra, bootstrapping is becoming sexy again. worth a read.

I work at a computer for most of my waking day, and though I enjoy many things about programming and design and computers in general, staring at a screen and thinking about things relevant to tech can be draining. There are some things that I do to release tension, recharge myself, and ultimately help myself become a happier person.

Look At Things Not Computer

I try to spend some time whenever I think about it looking at something far away, exercising my eyes. Watching a dog explore. Looking at the clouds until I can discern which direction they are traveling, and from there discern whether they are dissipating or growing.

Observe Natural Minutia And Balance

 

As a designer, paying attention to pixel level details as well as balance as a whole is something that has become an instinctual and enjoyable aspect of my work, but it can also be tedious and boring — and I can often feel stuck in my way of thinking. At these times I find it’s helpful to apply and expand those same levels of attention within nature. I love the Audubon Field Guides for this purpose — they suit perfectly the personality of someone who enjoys categorizing, exploring, identifying tiny similarities and differences, trying to grasp complex systems, and being reminded of how little one really knows.

Contra Dance

Contra dancing is a social folk dance somewhat similar to square dancing. You have a partner that you stay with for each dance, but as a couple you dance with all the other couples iteratively throughout a called pattern-based dance that is taught each time. Contra draws a lot of left-brained people because of the pattern-based structure of the dance, because there is no prescribed footwork to learn, and because the contra dancers themselves are generally a welcoming and forgiving bunch — so the learning curve for most is very gentle. I started contra dancing about 5 years ago (being a complete newbie to all forms of dance), and although I immediately enjoyed it, it is something that I have grown to appreciate even more as a mentally and socially expanding opportunity.

The latest set of ruffled feathers among the dogmatics in software development revolves around some comments made by Joel Spolsky in Stack Overflow podcast #38, where he talks about the pointlessness of 100% coverage, then digresses with Jeff on general concepts of quality. Naturally there were some responses, both well thought out and reactionary and wrong-headed. In one descendent that bears referencing, Giles Bowkett says there will be more rails(es).

He’s right, but he doesn’t tie this effectively into the larger discussion (though that may not have been his goal). His point is that new innovation comes from small businesses (I whole-heartedly agree) and not the major vendors, and that everyone eventually does their own thing. Rails is not the end-all be all, and I don’t think it’s intended to be.

I’ll pick up here and tie this back to the testing methodologies. Bottom line: Do whatever works for you. The goal remains to produce a quality product that’s as defect-free as possible. The relevant discussion points:

• quality of code It should be cleanly designed, maintainable, and smell-free. Do you worry about indention and naming conventions? is the code descriptive? Is it sufficiently decoupled? Some might include the question "What does the code’s coverage look like?", but I think that belongs somewhere else. The quality of the code affects its ability to be extended and understood. If you have a codebase that’s going to be expanding, these are important things. If you don’t, they’re probably not.
• quality of the product How well the product does what it intends to do, how well it fulfills its functional requirements, whether detailed and documented or not are the concerns. For any given release, how many defects are going to be found? How many functions are going to behave as expected? Is the user interface sufficiently intuitive? Do the user’s like it? Is sufficient progress being made on new functionality or existing defect being made to satisfy demand?

Both of these areas are affected by testing, both pre and post-release.

Unit tests should fall into the realm of pre-commit testing. They make sure you’re sane before you check your business back into the codebase. The depth and coverage of unit tests varies from place to place, as does whether or not test are written proactively or reactively. Hallway usability lives here. Depending on the complexity of the application, regression may fall post-commit, especially if the regression tests the build process itself. (Which it should.) Pre-commit testing is obviously intended to prevent new defects (whether code-related or usability-related) from being deployed. This can be supplemented by a post-commit continuous build and continuous integration system.

Some tests are best ran against a release candidate in a staging environment by a QA team divorced from development. Load tests come to mind. Regression tests. Full UAT’s and signoffs by management, if those things are required. For a product which releases across multiple environments, test high and low hardware requirements for load and regression. This level of testing checks for systemic problems that may not be evident to the developer on his own hardware, or to the people in the hallway for applications reaching a broad demographic segment.

Post-release, you monitor the software with automated tools. Users file defect reports, which are verified and put into the dev queue. Security monitoring for web-based applications takes place after the release. In general, post-release is concerned more with monitoring than testing. It’s reactive. Problems come back through a prioritization system, and are planned for future releases. The cycle starts over.

At the end of the day, there’s a threshold. Do you need 95% coverage unit tests with a full selenium suite, backed up by a continuous integration setup, staged release candidate deployment tested by a QA team, with load tests against every variety of hardware against which the code might be run? Maybe. There’s a ‘good enough’ level that’s different for every developer, but should be uniform across a team. For large projects and teams, this should be policy. For small ones, it can vary from week to week.

For me, unit tests need to be in place before a refactor, and can serve as a reality check for core functionality. Load tests are useful if you’ve made major changes, but are unnecessary for every deployment. UATs tend to be small affairs, so long as a rich feedback mechanism is provided for the end users on the live site. In short, testing is light and fast, and shouldn’t be a roadblock. Our team is very small and close. We’re notified of exceptions we didn’t see via email, and we fix them quickly and redeploy.

The bottom line is be informed of what’s available, stay up-to-date, but then use what works for you. Valuing ignorance is a recipe for inefficiency, but barring that, so long as your code and product are of a quality that’s acceptable to you, you’re doing the right thing. Your process is fine.

Go build something amazing.

Great Dating Services just published a solid review of FlowMingle.

They provided a good overview of what we have to offer.  The only catch is that they didn’t quite describe the process of the MingleWeek accurately.  The MingleWeek lasts five days, during which time you interact with the other group members.  Each day we ask the entire group a question.  The questions explore different areas of a person’s life.  We start with a First Impression, which includes media items you have recently enjoyed as well as your thoughts, pictures, and a listing of what you have been doing recently.  The next topic is A Day in the Life, then Opinions and Attitudes, and finally Show Your Creative Side.  Everyone answers the question individually, then the next day you are able to read the other group member’s responses and comment on them.

In this way we work with an Intimacy Gradient.  At first people don’t know one another and so we start by sharing information that is not very personal.  Most people don’t have a problem sharing the movies they have watched, or the music they are listening to.  Then, gradually, we approach more personal subjects, so that by the end of the week, as people become more familiar and more comfortable with one another, they are able to open up a bit more.

 We will try to make the description of the MingleWeek clearer in the future.

While the concept of a back channel isn’t new, it’s a powerful idea. I’ve read more than a few articles suggesting that Twitter is the next back channel medium. It’s even being adopted by TV shows like MTV’s The Hills, as was pointed out by Stowe Boyd in a recent post to his /message blog.

When to Use?

When is a back channel useful? Can it be more than snide commentary? Clearly it’s entertaining, a draw all on its own (I’m tempted to watch the next ep of ‘The Hills’ just for the back channel). It can also provide an instant feedback mechanism for conferences, classes, and presentations without disrupting the event generally. When I was at the Web 2.0 Expo in SF earlier this year, a few presenters had a back channel running (via Twitter) on one of the projectors during the talk. They took topics and questions from the channel as often as their notes. They wanted to know what their audience was thinking, immediately—and the channel gave them that opportunity. It’s a powerful feedback tool, and can turn a mostly one-way communication into a much more interactive thing.

It seems like back channels are at their peak usefulness in a moderately sized group (~150 people) during a timed event that is more ‘presentation’, and less ‘conversation’, and wherein the participants are all observing events synchronously, either by physical or remote presence. The conference mentioned above is the ideal situation. As groups get larger, the signal to noise ratio becomes less favorable. As the target of the back channel extends, becoming constant rather than temporally limited, the urgency of the channel becomes less of a factor, and a message board becomes just as appropriate, something that necessitates a permanency to the chatter. Finally, in a ‘conversation’ setting, the back channel content is best presented in the front channel, and so it’s not generally useful to have a second feed.

Uses for Social Networking ..

Most social network sites have the concept of multi-lateral messaging. Few have a running back channel. The more successful the are, the less likely a constant back channel would be useful. FaceBook applies something serving a similar purpose to their groups, ‘fan of’ pages and the like, but it’s less like a live back channel, and more like a message board. The way people use social networking is asynchronous. They leave messages, they come back later. Most people don’t spent a committed period of time waiting for their mini-feed to update. I’d say that for most social networking apps, a back channel isn’t a useful thing.

.. Specifically, Online Dating

For most internet dating websites, a back channel would not be any more useful than a feedback form for anything other than commenting and kibbitzing. The only ‘events’ are person to person, and for those types of communications, the front channel is fine. For FlowMingle, the mingle events last a week and have 20 people. It is largely asynchronous. It’s useful for us to have a channel for meta-discussion: was the last group question stupid? is anyone headed to the concert tonight? is anyone else having trouble with the portrait editor? Some of that conversation, occurring within the group, we would find useful, most of it they would find useful, and as such, it’s worth including a group channel, based around the event. There is no reason that it needs to be synchronous, however, at least during the main mingle.

A Speed Mingle, or Quickie, might be handled differently—these would be much more synchronous and time-restricted. For these events, live feedback is likely just the thing, especially if delivered via IM or Twitter. We should file this in the ‘needs more research’ box.