I went to XOXO. If you want a summary of what happened Anil live blogged it. If you want a shorter summary Jason has it.

Though I agree with Jason in that no summary will really capture what it was like because “you had to be there.”

But this isn’t about XOXO, it’s about something I saw there. It’s about something I have been obsessing about since I saw it and it’s about a possible future.

I have been aware of the MakerBot and 3D printing for many years. Sometime in 2002 a friend mailed me a Klein bottle he secretly made on his company’s multi-million dollar machine. The curves of the bottle were made up of tiny segmented angles that when viewed from a distance looked like a smooth curve, but up close you could see where the computer was. It was very pretty and very fragile (oops).

This weekend among the toys, art, games, and electronics being shown in the Market there was a MakerBot working away on a watchband. In front of the device were some of the items it had made, and I was surprised to see that the plastic quality and accuracy was much better than I would have imagined.

You can still see those segments in this Klein bottle printed on a MakerBot. But the difference is that it is much cheaper to use and maintain.

But it still didn’t click for me. What clicked is when my friend told me how she got her new ring. She said she complimented someone on their ring at XOXO and that person just went and printed one for her. Now they both had the ring.

You can make one for yourself here.

Rather than thinking about the MakerBot as a printer or creator of objects. It feels more like one end of a doorway between computer models and physical objects. Sort of how printed (on paper) words as representations of text files can be OCR’d right back into the computer for archiving.

Anil Dash has already walked down this road. In his post a MakerBot (when paired with a 3d camera) could “teleport” your cool ring or wine stopper to a friend by scanning and sending the bits to their fabricator. Rather than thinking of it as a fax machine or simply a printer of new things, you can think of it as a kind of “teleporter” of existing things. Either from here to your friend over there or from here to yourself a few years from now.

It’s funny to me that I had read Anil’s post last year, but only after touching and seeing a MakerBot work did it really click with me. My mind has been racing with ideas of a future where you could scan all your possessions and archive them along with digital photos for unarchiving. All the chairs, salt shakers, lamps, computer keyboards, picture frames, alligator clips, and stuff you keep around because you might need it someday could be archived on disk in case you do need them someday.

I really, really want a MakerBot.

I’ve had this idea bouncing around in my head for a while, and I want to do it, but the project would require a lot of time that I do not have. So here is the idea for someone else to take and make.

The point of this site is to help people build sites they are dreaming of building (THE IRONY).

Description: A site that you sign into with Github. You create a new project and then point it at a publicly accessible Git repo containing a suite of tests that you wrote for your project. Yes, you have to write all the tests first.

But here is the cool part: people can fork your project of tests, build the app that the tests are testing and then issue a pull request. You then can initiate tests (here be some magic) via a brand new EC2 instance that gets fired up, and if all tests pass you can accept the pull request and thank/pay/whatever the person who submitted the completed or partial project.

I did this today. I thought I’d write it up so I can remember for next time.

I’m working on another project using Django and have liked using the ORM more than any other of the big Python ORMs out there. On MLKSHK we use the beloved FlyingCow, one that we (Ivan) wrote, but when working for clients I like to use as much existing, tested code out there as possible.

First, create a new directory in the root of your project. Throw two files in there: __init__.py and models.py.

Next, create a settings.py file in your project, fill in the necessary stuff for your database and for INSTALLED_APPS include the name of the directory you made. In this case I made a directory/module called “orm”.

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': '',
        'USER': '',
        'PASSWORD': '',
        'HOST': '',
        'PORT': '',
    }
}

INSTALLED_APPS = (
    'orm',
)

Now create your models in models.py. Note the Meta class.

from django.db import models

class Doink(models.Model):
    name = models.CharField(max_length=25, blank=True)
    created_at = models.DateTimeField(auto_now_add=True, null=True)
    class Meta:
        db_table = u'doink'
        app_label= u'orm'

The first attribute:

db_table

is self-explanatory, but

app_label

is there to help Django know this is part of the orm package. Normally it would infer this from the module it lived in inside of Django but since we’re not in Django it breaks without it.

Last thing you need to do is set the DJANGO_SETTINGS_MODULE environment variable:

export DJANGO_SETTINGS_MODULE=settings

You can now run

django-admin.py syncdb  --pythonpath=.

and your models will be created.

In your code, use your models like normal:

from orm.models import Doink
Doink.objects.all()

Doink will now work like any other Django model.

This past _why day an email made the rounds that _why had sent two years prior to someone asking how they could become a better programmer.

The crux of the email was: if you follow the rules you are not going to maximize your risk and your creativity will suffer. Programming, for him, was about experimentation and discovery versus adhering to rules to produce objectively good code. He didn’t write tests. He didn’t follow any particular style or convention. He did some pretty amazing things. (And then he disappeared.)

The entity/story/folk hero that was _why is one of my favorite subjects to talk about when I’m drunk and talking about Ruby or Rails. If you haven’t read about _why you really should start with his Wikipedia page and definitely his book: Why’s (Poignant) Guide to Ruby. (I’m a fan of _why, can you tell?)

BUT…here at Simpleform one of our (and I will use this word even though my Catholic mother would give me a dirty look for using it that way) religions is testing. The other is shipping. We love shipping. Shipping is what makes your day worth it and if I leave my office having not shipped anything I mope.

The shipping is the fun part, the work is the testing. Testing builds trust amongst our team and with our clients. Without testing we’re potentially handing our clients a time-bomb, and worse, we’re charging for it. I hate this feeling.

So we test because we want to ship. And we ship because we want to make our clients happy. And if we can’t ship then nobody is happy. So we adhere to a set of standards and styles guides on how to test and how to organize our code.

There’s this line religious people use when they encounter atheists: “Without religion, where do you get your morals from?” Which is hilarious because I responded the other day to someone, “Without tests, where do you get your confidence in the code from?” and then realized what I was sounding like and laughed and laughed—but really I don’t get where the confidence comes from.

I used to think I was good enough to write code without tests. And to be honest, I never experienced a problem so major that data was lost or leaked. At FM every engineer was responsible for their own code and that plan mostly worked. Nothing catastrophic ever happened. But in the back of my mind there was always a worry that it might. It would only be a matter of time before something bad happened and I always felt a little nervous when I’d hear something wasn’t working correctly.

Even worse, changing a critical part of the application was always an arduous task of user testing and re-testing. It wasted time. It created a lot of worry and even when it was done I’d never feel great about it. Automated testing means you can make those changes and feel great when you ship.

And we love to ship.

When you’re done reading _why’s email, you’ll notice the top comment that was voted up is:

“As someone who maintains _why's code these days, please, write some tests.”

Back during SXSW Caterina posted about FOMO. The Fear Of Missing Out. I'm a big consumer of social media but sometimes I realize I’m consuming because of FOMO rather than having time or an interest in what people are sharing at that moment.

When I first read her piece we were deep into MLKSHK and trying to get it out the door. It stuck with me that I was very likely helping to create FOMO for our users and I wanted to be sure we gave them some control over that.

One feature of MLKSHK is the bookmark. It looks like this:

A bookmark gets automatically generated when you first hit MLKSHK and will (try) to stay in that location even if adjacent files are deleted.

The part that says “You started reading here 5 minutes ago” is how it launched about two months ago. As you read through your paginated stream you would run into your previous location and know that you had caught up. The problem with this is that it sometimes felt like a bottomless pit. When am I going to hit the end?

We just added the second part: “Jump to previous”. This allows you to jump back in time to your last bookmark and begin reading forward. You’ll be able to get an idea how far back you are by the post times on files.

We have a lot more ideas on how to combat FOMO. I hope to be showing you some more of them in the coming weeks as we roll them out.

“Complain about the way other people make software by making software.”

I keep wanting to tweet that, but I feel like it's too big of an idea to stuff in a tweet without explanation. It should be unpacked because not everyone can make software, and not everyone works somewhere that they can contribute to good software. Plus, it is complaining about people complaining and meta-complaints never seem to work on Twitter.

But I do feel that many people who take shots at products (some they don't even pay for) are overly critical of them with no goal of providing their readers or friends with a constructive perspective.

Worse is when the people doing the complaining also make software or web sites or iPhone applications themselves. As visible leaders of the web, I think there are a lot of folks who could do a favor to younger, less experienced people by setting an example of critiquing to raise up rather than critiquing to tear down.

If you're a well known web or app developer who complains a lot on Twitter about other people's projects, I am very likely talking about you. You and I both know that there are many reasons why something works a certain way or why something in the backend would affect the way something works on the front-end.

As I tweeted a few weeks ago:

I love reading the changelogs for apps I use. On my iPhone I read each update before upgrading, excited to see where the developers are spending their time. From libraries I rely on I use changelogs to figure out where the library is going and if the engineers still have their hearts in it.

I love making software. I feel like it's my way to state what I believe is a good way of doing things. When we didn't do infinite scrolling on MLKSHK it was because we wanted to say "We don't think that's an experience that's needed for viewing images and engaging with others—it's a way to quickly scan." We have very little AJAX except where it serves to keep the user from navigating away from a page. We love to think about these things. It's fun.

Because of this I feel a lot of empathy for other teams that end up as punching bags on Twitter due to rough edges on their products or missing features that "would just be so easy to add". While I don't want to make excuses for real, poorly run and developed products, or dysfunctional teams or teams with sales and marketing with their fingers in the product, I just don't see how complaining in 140 characters can solve anything.

I think making the right choices when you face them is the best way to say how things should be done. Having empathy for people doing what you are doing is as important as having empathy for your own users.

I'm the co-founder of MLKSHK an image and video sharing site I started with my wife. Sign up for the waitlist we'll let you know when we're ready to add more users.

You may have heard that Delicious is shutting down (or not?). Someone on Twitter suggested that a group of engineers should get together on a weekend and build a Delicious clone. In anticipation of this mystery group of people sitting down and doing this, I thought I'd make a quick todo list for them.

1. Account System - You'll have to adopt all the standard patterns that are typical of a web application:
   1. Database to hold accounts.
   2. Register and install an SSL cert to appease the security minded. Also: where are you hosting this? What database? MySQL? Good. InnoDB? If you're deploying with another engineer, have the typical 30 minute conversation about deploying databases every two hours.
   3. Decide on the ORM, or just write some lightweight classes that do the tedious crap. Hopefully you selected a framework that has some helpers for all the verification options otherwise…
   4. Methods in the User account model to verify email, length and strength of password, a good idea of the account names you want to hold back so you can still make paths like /admin or /static later on.
   5. Lost password flow. You'll want to generate a key and store it someplace for when someone requests to reset their password. So that's another email that has to go out.
   6. Sign In flow.
   7. Sign Out flow. (Be sure and use a POST method to sign out. See why here <- signs you out of delicious)
   8. Sign up, display errors.
   9. Update your settings, name, password, email—Doh! You'll have to verify the email again.
   10. An account verification system done through email so you can verify people have given the correct information.
   11. Scheduled backups of your database being pushed to a separate location. Binlogs? Mysqldump? You'll have to write a script or configure your off-site DB slave. You might also want to test that it works.
   12. Oh hey, you can delete your account on Delicious? What does this mean for the bookmarks, favorites, and friend relationship interfaces you haven't even written yet? Save that one for later I guess.
2. Following and being followed flow. This includes:
   1. A database for holding friend relationships.
   2. An interface for looking at everyone you follow.
   3. An interface for looking at everyone who follows you.
   4. Ability on each of the above pages to follow (or unfollow), probably using AJAX because people don't want to leave the page. Also you're going to want to paginate that, some people are popular.
   5. Blocking followers and the processes that recognize a follower has been blocked when displaying content.
   6. The required database indexes for extracting and displaying follower counts.
3. So before we get to bookmarks, what about import tools? Why would anyone move to your system without import tools? You will need:
   1. A task queue. Hopefully distributed so you can pass importing off to your workers on other boxes when things get overloaded.
   2. Some sense of the different formats you'll need to process. Delicious being the big one, but there's Google's product, Diigo, Xmarks and Pinboard. Also people are going to want to import from their browsers. I'm not even talking about actually processing these things, just understanding and researching the formats and pitfalls is going to take some time.
   3. Actually doing the processing. What happens when something fails? Do you offer a report? There's a new page. Can they retry without duplicating inserts? I'm really only scratching the surface here, this is tedious shit.
4. Tags. Related tags. Searching tags. Recent tags. Explore tags. You gotta use that task queue for offloading a lot of this. When does it run? What happens when it fails? Seriously, I don't even want to think about tags right now. There has to be a module out there that will do it. Go read the docs to that.
5. Three letters: A P & I.
6. You are going to write unit tests for all this, right?

You still haven't fully inspected all your XSS issues, implemented the searching of content, thought about design and UI, errors and documentation, the various methods for storing links like bookmarklets (tested in every browser), or, you know, actually saving bookmarks to a database for presentation to you and others.

Then there's pattern matching on URLs that can be an issue (http://xyz.com/ versus http://www.xyz.com versus https://xyz.com/ versus http://xyz.com/index.html ), I never really thought about that problem, I'm sure it will only take a few minutes. We can deal with it later.

(Thanks to usernameguy and Anil for some inspiration.)

I probably don't understand the iPhone 4 antenna attenuation issue (I barely get Photoshop) but…

The internal layout likely dictates why the antenna has the break below rather than above—meaning they needed space for the camera—but still, I was holding my phone and I noticed my finger never goes between those buttons.

Update: Turns out you can't have an antenna at the top of the phone.

Geeking out with this, but here's an idea on how templates and the template languages should do date formatting. Instead of requiring me to type (and remember) something cryptic like:

"%A %d %B %Y %I:%M%p"

I should be able to type something like this:

"Monday 12 July 2010 02:30PM"

And the formatter be smart enough to figure out that the first word is obviously a day name, the next number a day of the month since you wouldn't put a bare year after a day name, the month, the full year, and then following that is obviously a time.

So tired of looking up date formatting strings for every framework and language.

"If VHS home recording is made legal then our industry is ruined."
"If CD quality music is allowed to be sold then our industry is ruined."
"If DAT is made legal then our industry is ruined."
"If the Rio PMP3000 is allowed to be sold then our industry is ruined."
"If file sharing is permitted then our industry is ruined."

The tactic is as old as the hills and used by some pretty dishonest people in the last few years to combat technology they feared would upset the nice apple cart they'd set up. If X happens, then 100% of Y will happen.

continued