# Project Euler 18 and 67 in Scala using foldRight, zip and sliding

Nov 28, 2013

I’ve recently applied to Toptal and sucked miserably at the entry exam. My algo chops were blunt and I thought I’d rectify it by revisiting Project Euler. With the startup last year and the baby this year I just haven’t been able to find the time for programming challenges, but that has to change.

Looking at my Project Euler source directory, I saw that I left it at problem 17, so next up will be 18. The problem description, however, mentions that the problem repeats itselt as 67, but with a bigger input that will run 20 billion years if you go the brute force route.

I worked a little on this problem last night, and decided to by-pass the brute force solution completely. It was a bit late, though, and I pulled my eyelids open far enough to make it to bed. I then went on to dream about the damn problem all night. I knew there had to be a simple bottom-up fold-based solution, and the voila moment came for me when I realised I had to seed the fold computation with the base layer in the triangle.

Here you go:

# A little explanation

The triangle is represented as a nested list, like so: List(List(1), List(2, 3), List(4, 5, 6)) and so forth.

```
1
/ \
2   3
/ \ / \
4   5   6    <- this is the "base layer" in my explanation.
```

Since you need to add the maximum of the two immediate children to the layer above, a foldRight wouldn’t give me all the info I need in the curent iteration. Foldright for me means “the data is coming FROM the right”, i.e. List(4, 5, 6) will be processed first, then List(2, 3) but at no point in the iteration will they be available together so I can do the sum. List(4, 5, 6) would need to come into the iteration with List(2, 3) in another way, and I realised I can use the foldRight’s accumulator for that by seeding the foldRight with the base layer in the triangle (aka the last list List(4, 5, 6)).

The easiest way was to just seed the foldRight with a list of zeros one element larger than the base layer. You then break it up into pairs using sliding(2,1), take the max of the pairs, and sum the max with the corresponding (thanks to zip) element in the layer above.

```
1
/ \
2   3
/ \ / \
4   5   6
/ \ / \ / \
0   0   0   0    <- this becomes the new "base layer", or "seed"
```

No mutable state; no recursion; simple to understand. As Erik Meijer would say: “baby code”.

# A webwords Chef cookbook

Nov 10, 2013

There are a lot of new examples up on the Typesafe website, a few with the word “Reactive” in them to drive home the credo behind the framework. One of my favourite examples, however, seem to have been demoted but still remains one of my favourites: webwords.

The old Heroku link to the live running instance of webwords does not seem to be up anymore, so I whipped up a quick Chef cookbook with which to spin up your own local instance.

You can find the Github repo here. Spin it up and have fun.

# Pretty-print JSON in vim

Nov 05, 2013

TL;DR A quick way to pretty-print JSON in vim with no dependencies (here’s looking at you, Perl). Download jq then `:%!jq ‘.’`

Computational statisticiansData scientists have some the funnest tools, and I found a good write-up of a few more I didn’t know about called 7 command-line tools for data science. The first thing the article mentions is a gem called jq.

I found jq to be especially useful for formatting JSON in vim. So, before ado can in any way be furthered:

`curl http://stedolan.github.io/jq/download/linux64/jq -o ~/bin/jq`   `chmod +x ~/bin/jq`

In vim, open your unformatted JSON file, then: `:%!jq ‘.’`.

There you go, ladies and gents — a command so short, you don’t even need to put it in your vimrc!

# Dell XPS 13 LE

Nov 02, 2013

TL;DR If you’re a laptop-toting *nix user, then this is the laptop for you. Also, upgrade the kernel before you do anything else, for the best experience.

This advice is highly unqualified, though. The last time I ran *nix on a laptop was when I ran some flavour of Gentoo on an old Centrino-loaded HP in 2005. I’ve been a Mac user ever since those darned iPhones came out.

It’s just that I ran out of space on my 128GB SSD Air for the umpteenth time, and shuddered at the thought of breaking off glued-down components according to some iFixit guide. (Damnit! I just looked again, and there’s no glue involved in upgrading the SSD. Oh, well — the missus needed a new laptop anyway, and this was a welcome hand-me-down. Besides: new toys!)

# First thing’s first

When you do get one of these bad boys, the first thing I recommend you do is this:

That will get you the latest kernel without upgrading everything. As any Linux user would know, upgrading to fix one problem introduces a thousand other problems, and this felt like a nice trade-off.

The reason for the above command is that I did have some wifi stability issues to start with, so I hope to save you that initial few dropped connections.

Once again, kudos to popey over on the #ubuntu-uk IRC channel for the advice.

Wifi has been stable and pretty quick. I suppose it’s not all down to the new kernel and drivers: I have Virgin 60Mb fibre optic, and my walls are refreshingly free of tin foil.

# The gear

The XPS 13 comes packed with some great specs which you can gloss over here, but I’ll re-iterate the key components: Intel® Core™ i7-3537U CPU @ 2.00GHz × 4, 8GB RAM, 256GB SSD of which 230-odd usable and a mega bright 13.3" screen all on a pretty little laptop that feels like an 11" one. I never put the brightness above a third of the available level, and at 1920 x 1080 it looks great.

The keyboard still sports a Windows button, but it’s the new Windows logo which I’m not familiar with yet, and I pass it off in my mind as a generic “dashboard” type button, so it’s all good. A Tux button would probably be a bit weird. I mean, what would a penguin button do? Summon a troop of penguins? Nah. Besides, penguins — just like seals and dolphins — can be dirty little scumbags.

# The ever-so-scientific bench test

I needed GIMP for something last night, and when I installed it and launched it for the first time, the realisation hit me that it all took about 30 seconds.

So, I purged GIMP and re-did it for your viewing pleasure:

Apart from this, I’m running about multiple Java server apps (for this thing I’m working on), plus a couple of VMs, plus some Python scripts that are running some numbers. My software does make efficient use of all the available cores, and CPU hasn’t been a problem for me in a while.

All the Linux games available on Steam runs like a dream. Just the addition of Steam of a *nix system feels like we’ve come full circle.

# Qualms

It’s early days — a lot might still happen. In fact, Murphy’s Law states that I’ll publish this favourable review and it will be shortly followed by the i7 going up in smoke.

Anyway, here are some of my initial qualms:

• The mouse is triggered sometimes whilst typing. This is configurable, and I have switched it to disable the mouse whilst typing, but to no avail.
• The password box looses focus more times than not, and you end up typing your password in unfavourable places. This could be related to the previous issue discussed.
• Keyboard is ever so slightly flimsy, because sometimes letters will double up. Perhaps this is just a keyboard I need to get used to. Besides, I’ve used the Mac chiclet-style keyboards exlusively since 2009.
• The palm rests — even though they feel great to the touch — seems to get a bit streaky after a while. My fingers are constantly greasy from chowing on ginger biscuits and stuff like that, and it doesn’t wipe down well.
• The backspace button does make a slight squeaky sound sometimes, but this could be because my pinky finger “pulls” on the button due to the angle I attack it with. Still — I don’t think this should happen.

# Outro

If anything else pops up, or if the XPS 13 makes my life significantly better in any other way, I’ll come back here to amend. (I won’t do those silly UPDATE things at the bottom — you can look at the Git history of this page for changes.)

This is my first ever piece of Dell equipment, and it doesn’t look nor feel like a grey, impersonal piece of office equipment. Also, Mr. Mark Hails-From-The-Same-Home-Town-As-I Shuttleworth got things very right with Ubuntu. Linux has certainly come a long way since that day in 1995 when my mate dropped off 25-odd floppies of Slackware.

I’m more productive than ever and won’t be going back to Apple. I certainly don’t want to shoehorn OSX into a usable system with macports any time soon.

# AngularJS and Internet Explorer woes

Nov 01, 2013

Aka endless clicking on crossbrowsertesting.com and why I love being a backend programmer.

A few weeks ago, one of my clients tasked me with building a public-facing single page app for their credit monitoring business. They’ve heard good things about AngularJS and said they wouldn’t mind if I learned it on the job. (I love those kinds of clients!)

At this point we’ve already solidified the backend API (Scala + Play! 2.1.3) and felt like getting my hands dirty with our good friend Javascript.

# At first, it was easy

I knocked the first version out quickly and got it working on the latest Chrome and Firefox on a Macbook Air. As we all know, my setup represents a small slice of humanity, so onto cross-browser testing I went.

# And then, it wasn’t

I’ve been solely a backend programmer for a good few years now, and I soon remembered why: building something for to work with every browser/platform combination in the world is a royal PITA. I wasn’t going to give up, though, and the tool I used to achieve this goal comes with an A+ thumb’s up 5 stars from me. I was saved the cost and effort of running every other major browser/platform combination.

But, still — this is how it all panned out: load the page, load dev tools, and then the clicking begins. The endless clicking through thousands of lines of AngularJS and jQuery code to find the point where things fall over, and then just before the Eureka moment, the connection would drop. Or IE devtools would throw a wobbly and loose its place in the source code. All of this via a Flash frame stuck with IE devtools. IE DEVTOOLS, people! Not fun.

Which is why this isn’t a detailed bug report: I merely stumbled onto a solution after pulling all my hair out and trying something different.

# The issue

Now, I’ve done exactly what the good AngularJS folks told me to do, but my scenario seemed unique. It turns out that if you use a custom directive from a partial in IE, it won’t be callable as an element (‘E’), but only as an attribute (‘A’), e.g. of a DIV.

I explain via two examples over here. If you are the lucky owner of a Windows box loaded with IE8 or smaller, please go and try it out and then lodge a proper bug report with the jQuery folks. Yes, yes — I know it sounds like this article is about AngularJS, but the real issue seemed to be with jQuery.

Something to do with `target.appendChild(elem);` on line 6,050 of the latest version of jQuery at the time of writing.

In the mean time, I hanker after my beloved Scala backend servers, where I get to choose exactly which platform and which flavour of VM I run on.

# Failed startup #2

Jul 19, 2013

Pollarize is a decision-making platform that makes it quicker and easier for you to query your friends across multiple social networks and gather their responses into one concise answer. I co-founded pollarize at Startup Weekend London, March 2012, which we won. Shortly after, we were accepted into Wayra UK, whom gave us enough money to work on releasing pollarize on iOS and web in December 2012. Sadly, we have since run out of cash and have failed to secure more funding.

## Startup weekend

That’s me in front behind the HP bag.

I won’t re-tell the story of pollarize’s beginnings, so I copy Mat’s post from the old pollarize blog:

If superhero reboots have taught me anything over the past few years it’s that people love an origin story so I thought I’d share ours with you:

At the most basic level Pollarize was born out of my long term courtship of Juan Uys, our CTO, and an indecisive iPad purchase.

Juan and I met for the first time at a Hacker News event in 2010 and I quickly identified him as the technical guru I needed to help me launch the startup I was working on. Unfortunately I discovered that Juan was working on his own project but the the two of us stayed in touch and ended up becoming friends instead.

Fast forward a year and a half and both of our previous projects have gone the way of the dodo so we decided to team up and attend London Startup Weekend. We met up towards the end of March of this year, a week or so before the event, and threw a few ideas around, including an idea borne out of my experience trying to decide which iPad version (3G vs. Extra Memory) I should buy…

Startup Weekend London was an awesome experience. I’d spoken to people that had attend similar events before so I knew that the key to doing well was forming a small, manageable, team and executing as quickly as possible. With Juan on board and taking care of the back end we set out to fill the gaps in our team as quickly as possible and recruited Michael Hobson to look after design and Sara Gozalo to focus on front end development.

We learnt a lot over the course of that weekend - I got further with a startup in those 54 hours than I had in a year of trying - but most importantly we went on to win. Winning that event had two major outcomes:

• It was a great validation of the project and encouraged us to continue with it after the event.
• It introduced us to the team behind Wayra UK - the weekend’s primary sponsors.

In light of this we decided to continue the project after we left Startup Weekend and also began the process of applying to accelerators.

Unfortunately we had to part ways with Sara at this point due to her other commitments and Juan quickly brought Phil Cole on board to take over front end development work.

A month or so later we made it through the final stage of selection at Wayra and became one of the first 16 teams to participate in Wayra UK.

A month after that we moved into the Wayra Academy as one of, if not the, earliest stage teams in the program and set about starting again from scratch.

It’s been 8 months since the Startup Weekend pitch that kicked all of this off and we’re still to break the ‘heads-down and execute like hell’ initiative that brought us that initial success. We have a wait list of 1,500 potential users signed up already, the second version of our iOS app in the app store and a brand new web app experience. It’s very early days for us but you can be sure that we’re giving it our best shot.

I’d like to take this quick opportunity to thank my team, our early adopters and all the people that have supported us behind the scenes - Pollarize may have been born out of an iPad purchase but it’s growing into something bigger thanks to the awesome group of people involved in the project.

Cheers,

Mat

Mat’s post above already aluded to Wayra Academy. I’ll fill in some more blanks.

Wayra was the hardest I’ve ever worked in my life. Apart from having to keep my day job (the guys didn’t — bless ‘em), I squeezed pollarize deliverables into every spare minute I had. As can be read from my old pollarize posts, I used a few technologies which enabled me to iterate very, very quickly. I worked 3 hours before work in the morning, one hour over lunch, then another few hours in the evening. Weekends were 2 ten hour days. Needless to say, I never burned out. I followed a healthy diet and went to the gym every morning to stay limber. I did regret not spending the week days in the shiny new office with the guys, but with the help of good old email, Pivotal Tracker and some Basecamp, I did a mighty good job of getting those tickets out and keeping the bugs at bay.

I rushed through hours and hours of Scala, and used some Python for some add-on NLP and recommendation projects which we never launched. Mike designed everything we threw at him perfectly, whilst also juggling what was to become his tech events business. Phil became my personal hero when he learned, developed and launched a gorgeous iOS app in 3 months. And Mat kept hustling all the way through it all, meeting, greeting, wining, dining and basically trying to secure us some funding.

We were going for the Big Bang, one-in-a-million, “get lucky” exit — something one is especially hungry for when your app is social and free.

## Dublin Web Summit

Mike won 2 Web Summit tickets, and Wayra sponsored another 2, so we were all able to attend. We implemented and refined about double the amount of features from the previous 6 months at the Web Summit weekend.

We had a successful iPhone app launch, got some good PR going, and met with more angels and investors you can shake an executive summary at.

.

We spoke, we demo’d, we networked with other startups and got the buzz going. This was the best times of our respective professional lives.

## Big Bang

Big bang? No: crash and burn. We failed to secure funding. We pivoted, then re-pivoted in a panic to make ourselves matter. We desperately wanted to stick together as a team and make more stuff. We do sometimes wonder if we were in a different startup environment if things would have panned out differently. Besides, we weren’t the only ones making opinion apps: there are Amen, Thumb, Polar and others.

We started an agency called Strange, heavily inspired by BERG. All of us, however, went on to separate things, because bills needed paying, and our respective better halves couldn’t sustain us too much longer. (My story is slightly different. Having kept my day job, the missus really just needed some help with the renovations already!)

## Exodus

A couple of days ago I put a stop to all our bills: Github, Pivotal, Heroku Postgres, SSL, Mongo, etc etc. The free instance on Heroku is in maintenance mode, and our splash page will remain until the domain expires, and we probably won’t renew it. The demise of pollarize is sad for the 4 of us considering the hours we put in.

We are doing great, though. Phil went on to work (and take equity in) one of the Wayra shining stars: Night Zookeeper. Mike, like I said, is crafting the best tech events, now worldwide. (Silicon Drinkabout Copenhagen, anyone?). Mat continues to conquer the world, one idea at a time. The missus and I just had a baby, and I’m planning my next move.

Now, I just have to wait for the guys to become slightly more available again so we can hack up our Next Big Thing. We did everything perfectly before, but the world just wasn’t ready. Our next product will be perfect again, but it won’t be free ;-)

# Redefine thyself.

Jul 16, 2013

We’ve just had a baby, and it has put things into perspective a little bit.

I never think of the future - it comes soon enough. – Albert Einstein

Thanks, Einstein, but it does not apply to me anymore.

Wish me luck with my imminent adventure. Details to follow.

Image: my own rendition of Saul Steinberg, Untitled, 1948

# Pollarize architecture at a glance

Nov 20, 2012

X-posted from the pollarize.me blog

# Genesis

Pollarize was bourne out of a 54 hour hacking stint at Startup Weekend in March 2012. The Thursday night before that weekend, I thought about the various tech I knew and wanted to have a good idea how to kickstart our hack before putting pen to paper on the Friday night.

The decision was made: Pollarize was going to be a Spring MVC web app running on an Amazon EC2 instance. I was going to worry about the database later, and maybe get away with using an in-memory map or something for the data.

Come Friday night, I felt a bit different. Why not learn something new, I thought. Besides, AWS might be a bit clunky for a weekend hack. And I’ve heard good things about the Play! framework, and the v2 was released just a few months before.

# Today

Fast forward 7 months, over 200 deploys, and over 1,000 commits. This is what our API looks like now:

## Core

The core app is a lightweight Play! 2.0 (Scala edition) web app which exposes a JSON web API, and it makes transactional writes to our operational Postgres database. Most other (unimportant) write operations happen via fire-and-forget calls to other modules via Akka. The IDs for these data is pre-chosen, so subsequent calls will be idempotent.

## MongoDB

All writes to the operational database is fired off to a MongoDB actor, which serves as the read-only cache for API reads. The data in MongoDB is already in the format the caller will consume, so it is extremely quick. The cache can be rebuilt asynchronously with the click of a button.

## Media

The media module accepts profile pictures and poll images, and we use Blitline to get them into our signature circular format (and different sizes), and then we store the results in Amazon S3 and expose it to the world via Cloudfront. If you have any image processing to be done, definitely give Blitline a shot: they’re very helpful and the API is a lot of fun to play with.

## Notify

Notifications is triggered via an Akka scheduled job in the case of poll expiry, and via events in the case of registration, password reset, poll creation from people you follow and follow notifications (yes, we’re a tiny social network). In general we use email via Mailgun’s simple API, Pubnub for web users, and Urban Airship for our mobile users.

## Other

We played with some other tech but those were chucked out for various reasons. Redis is awesome, and we used it initially for our social network, but in our case it was just another piece of your architecture to worry about. Our social network now happily lives in our operational database where it belongs. One day, if Postgres buckles under the graph, we’ll reconsider. Then there’s RabbitMQ. It’s beautifully stable, and has a very good monitoring plugin, but once again: it’s one more thing to manage, and besides, Akka mailboxes will suffice for now. You bet your PaaS we’re using Heroku

Heroku has been great for getting started. Have an idea? Code it, commit, push, et voilà. No worrying about builds, deploys or anything like that: one less operational hassle to worry about when you’re building features. However, we do have a chunky \$5,000 AWS credit, and I’m slowly but surely creating Puppet manifests for all our components (Vagrant has been great for testing this locally), but this is still a nice-to-have for the size of our user base, so I’m really just hacking at this in the in-between moments.

## Conclusion

So, there you have it. Our architecture at a glance. There will be some more detail later down the line. In fact, I’m already drafting a Play! best practices, jotting down everything I’m learning along the way. Questions and comments on the back of a postcard.

# Adding SMS functionality with Twilio

Oct 15, 2012

Pollarize helps the world make up its mind via its beautiful, delightful suite of apps. However, not everyone owns a smartphone. Luckily, Twilio brings voice and messaging to web and mobile applications. Which means that Pollarize now allows our brick-lugging friends to compose polls via SMS.

# How we built it

The usual Pollarize system constraints are the following:

• poll question can not exceed 100 characters
• options A and B can not exceed 100 characters each

The requirements are the following:

• a poll SMS should be in the format “Question text. A. First option B. Second option”
• if either A or B is omitted, then default to “Yes” and “No” respectively
• a poll SMS can exceed the 160 character limit, but not exceed 308 characters if we take into account the delimiters ” A. ” and ” B. “

This meant that an entire poll can at least be described at least by one SMS, and at most by two, since 308 is less than 2 * 160, or two SMS fragments.

# SMS

Twilio seemingly don’t maintain any state on their side. I.e. if a user sends a large SMS, Twilio will not bundle the resulting SMS fragments up and send it to us in one piece. Instead, Twilio will send us the fragments one after the other as they become available from the mobile network.

To illustrate this, here are the `application/form-url-encoded` payloads represented as Scala maps:

# Implementation in a nutshell

The trick here is to assemble the SMS text once we’ve received all the fragments. Since Twilio doesn’t tell us there’s a second fragment coming, we don’t create a poll immediately after an SMS is received. Instead, we dump the payloads into MongoDB as they are received. A background worker then scans all “unprocessed” SMSes and check if there were other SMSes from the same phone number within the last 10 seconds. Once we have all the SMSes, we combine the original SMS text into a single text, create the poll, and we mark the Mongo record as “processed”.

The “within the last 10 seconds” bit only came after I discovered a massive bug. Let me explain…

# The Poll-from-SMS scheduled job

The background job server re-assembles the SMS fragments into a single SMS and checks if they’re poll-worthy.

The first version of the SMSWorker accidentally did the following (using the data from the two Gists above):

## Poll #1

```Question: I don't have an iPhone, so I thought I'd build SMS functionality.
Option A. Great, what about something that interprets smoke signals?
Option B. Good, now get on with
```

## Poll #2

```Question: the Android app already!
Option A: Yes
Option B: No
```

See what I did there? Option B got cut off due to the 160 character SMS limit, and we accidentally created a whole new, unintelligible poll. Not quite what I had in mind, as you can imagine. I had to start making some assumptions about the way Twilio and the mobile networks interact in light of the absence of an SLA from either.

I assumed a maximum of 10 seconds between SMS fragments. A counter point to this is that we assume a user won’t create polls via SMS in quick succession.

# The Poll-from-SMS scheduled job V2

The second version of the SMSWorker can be seen below.

The value inProximity are the SMS fragments within a 10 second period. The SMS fragments belong to the same user, as obtained via the groupBycall on line 8.

The SMSParser on line 19 is really nothing special, but from the test cases you’ll see that we’re catering for every eventuality:

# Conclusion

This was a fun little addition. Next up is voting via SMS.

MongoDB allowed me to store the entire SMS payload and worry about the contents later. I didn’t create a model for the SMS payload, because it isn’t core to my domain. Also, the 10 second window seemed like a safe trade-off in light of being in the dark (huh?) with regards to mobile network SLAs. We’ll measure and adjust accordingly, of course.

Twilio was easy to integrate with, and it all just works. Now I feel like SMS-enabling all my apps.

Jul 31, 2012

Or, actually:

# Semantic Web Crash & Burn

I sent a very naïve open letter to a few key players in the semweb space a few years ago. I got no responses, and hence thought that either my question was posed incorrectly, or the field is so new no-one can really answer me, or the race is on to lay the groundwork and therefore there’s no time to get a newbie up to speed, or X. (I don’t know what X is yet.)

Fast-forward 3 years and I now have a project going which may or may not generate some valuable data soon. I want to store the data in a way that makes sense for humans and computers alike. I do not want to index everything, because being presented with a list of 10 close matches to what you want is so archaic. And since I’m a big fan of free PaaS hosting plans, the data needs to be stored very efficiently, and I should be able to operate on it every efficiently. Besides, your Big Data is big enough, so I should be OK.

Without further ado, I’ve dedicated my evening to a Deep Dive of everything semweb.

I love the web and I’m a web programmer. I also want to give meaning to my data, i.e. attach some sort of semantics. Roll on.

# Overview

I started this post at 7 and now it’s 11. I got stuck on a handful of Wikipedia articles and W3C recommendations and working groups. It all reminded me of this XKCD on standards:

After hours of randomly clicking and reading bits and pieces, I’ve managed to get a better overview of the state of semweb.

# And then a funny thing happened

This is where I was supposed to write about it all, dissect it, make sense of it and summarise it.

I was going to give you a primer on simple terms like taxonomy, vocabulary and ontology. I was going to tell you how we’re still far away from data and still very much document-based, stuck in silos, and how traditional markup doesn’t cut it—how it does not describe what something means, how microformats is a web-based approach to semantic markup, and how this proliferation of formats can luckily be ground down into something coherent using GRDDL. Most importantly, I was going to tell you about knowledge representation using OWL and RDF, and the software tools to peruse said formats.

Then I realised: my brain is so crammed with 4 hours worth of reading all this stuff, that I need to find a way to do exactly that: a knowledge representation of what’s in my brain.

Then something in my head went snap.

I ended up on the floor in a spasmodic fit of hilarity, sucking my thumb. The confusion punctured my prefrontal cortex, and I now only speak to uppity wooden chairs. In reverse. My brain turned on itself in the most meta way possible. I had to stop.

# Conclusion

I don’t want to duplicate any knowledge here, so there will be no summaries. But, I’ve seen the suffering, and will leave with you the following tips:

• if you ever publish anything, and it’s not data, please annotate it for generations to come. The web is too noisy to scrape anything anymore and we’re too busy to build a spider to make sense of your mash of markup.
• there are places where you can ask questions if you get stuck.
• don’t silo your data or think it belongs to you especially if your users created it (here’s looking at you, Facebook). It should be free.
• don’t break the web by creating user profiles and not annotating it with hCard at the very least. There’s also FOAF and XFN.
• don’t expect silver bullets. There are smart people doing good things to take this movement forward, like http://www.opencalais.com/ (even though OC are too focused on companies/mergers news)
• there’s too much standards documentation for me to consume right now. Process can scare the most optimistic of us away, but it seemed the folks at W3C managed to pull something wonderful together. I really do hope I can get through it all one day.
• a few weeks after doing this 7-11 stint, I found a semweb on-line test, and memory served me well. I’ll consume you yet, semweb, just you wait.

# And, then some…

…other things I wanted to write a few words about, but responsibilities beckon.