Apolonio's Blog


Our plan for Decurate was to establish retail flash sales at some point. We’ve decided to move ahead now rather than wait. As we looked around we see we that in addition to ourselves, we have many resources in front of us.

My co-founder Jordan and I met and worked together at an online retail provider for hotels. We’re still good friends with many of the people there. They’ll be invaluable in helping us avoid as many issues as possible.

The most important next hire is an account executive to help coordinate vendors. In another amazing, wonderful coincidence, our good friend Tamie and account manager at a games company quit her job this week. She starts with us on Monday.

On the design front, our illustrator should have the first sketches for us Monday.

I’m expecting things to not be this perfect in the future. I’m writing this blog to remind myself it’s OK, we’ve had quite a bit of luck regardless.

Our Third Curator

Our next curator is Irene from New York. Welcome. We’ll be sharing more details about them soon.

Another New Curator

We just hired another new content editor, or curator as we call them. Welcome Karyn. Her style is more traditional, but clean and elegant. Her style could be mixed with just about anything modern. We’re lucky and grateful.

Our newest team additions

Before launching Decurate we’re building a team of great content editors, and evolving the design of the site. We were lucky enough to find Brittney from California to be our first design editor. She has a modern, clean style.

We’re just as fortunate to have found an amazing artist to work to help us with graphics work, Alvaro Tapia Hidalgo, from Spain.

More to come.


We left LAX on July 2, summer, and were lucky enough to be offered exit row seats as we checked in. The seats were mid-center, in front of an aisle. This gave our legs as much room as business class and made the 14 hour flight feel half as long.

Arriving in Santiago on July 3, winter, we were met at the airport by our program’s assigned and gracious padrino at 5:30 AM. We packed our bags, monitors, and Jordan’s snowboard into his car. He dropped us off at the temporary apartment I found on Craigslist at the last minute for a cheap $29/night.

We slept for about two hours until the apartment manager came by to collect a deposit. He gave us a hysterically animated tour of every electronic device, appliance, faucet and kitchen drawer of the 400 square foot space. The portable electric heater that was the only source of warmth, blew a fuse as he was demonstrating how it worked. We managed to sleep for another two hours in the freezing cold. Later, our padrino met us and took us on a tour of the upscale east side of Santiago, with a clear view of the Andes from almost everywhere.

Since then, it’s been a blur. After three days of searching we found a furnished three bedroom apartment in a great neighborhood, Lastarria. That left us free the following weekend to visit Valparaiso, a beautiful city by the ocean 40 miles from Santiago. It’s filled with graffiti, stray dogs, 37 hills with century old inclined elevators, amazing views and architecture. I loved it. We ate at a great restaurant, Bijoux, where you discuss your options and preferences with the chef before deciding on a meal. We feasted on fresh fish caught that day, beef and pisco sours. As we explored the hill around our hostel, we met two local university students and were invited to join them in drinking boxed wine out of cans of Budweiser. I did, while Jordan deferred.

In the two weeks since we landed, we’ve received our Chilean social security numbers, bank accounts, gone through the program introduction, launched the alpha release of our latest project, and hired two people.

Next week we go to the north of Chile to attend a class at a university and share our start up experiences with the students. We’ve set aside some time to see the Atacama desert and will hopefully spend a few days in Bolivia.

I can’t say enough good things about our program and Santiago. Start Up Chile feels like a great opportunity.

New Ideas Rarely Are

I was lucky enough to meet Douglas Englebart a few years ago in a seminar at Berkeley. In 1968, he introduced the mouse, hypertext and other ideas to a group of 1000 computer scientists via video conference. It’s amazing how long it takes to see something right in front of us.

Building a Gameboy emulator. In javascript.

What can’t you do with JS?


The Electronic Home Library

Why don’t we imagine the future as much as we used to? This article from the Chicago Tribune in 1959 shows an electronic home library where you could project information onto the ceiling. It may not have been correct, but it took a lot of thought to forecast something so far from what technologically possible. Via PaleoFuture.    


I have a new favorite for managing our social media. I tried Postling last week and it was fantastic.

It was designed specifically for posting to other sites and is not another place you need to manage.  It’s a manager for everything else.  For me, it did two things really well.

We have a product blog, a corporate blog and I blog for Decorati.  It connects to any WordPress account you have, whether it’s a WordPress.org or .com site.

In a few seconds I updated two company blogs, twitter, and facebook. It’s nicely set up so as you’re creating an entry it’s streamlined if you choose twitter. You get both a larger form for your blog and facebook, and one just for Twitter.

That alone was good for me but it does one other great thing. It searches across the web for any comments on your posts. And you can respond back directly from one interface.

You can also update your Facebook status and schedule posts for later.

The Unsolvable Math Problem

In 1939 George Dantzig showed up late to a math class at Berkeley, saw three equations on the board, and wrote them down.  He found out later only two were homework.

His professor contacted him and let him know the third equation was only for a discussion he had missed.  It was an unproved theorem.

“It happened because during my first year at Berkeley I arrived late one day at one of [Jerzy] Neyman’s classes. On the blackboard there were two problems that I assumed had been assigned for homework. I copied them down. A few days later I apologized to Neyman for taking so long to do the homework — the problems seemed to be a little harder than usual. I asked him if he still wanted it. He told me to throw it on his desk. I did so reluctantly because his desk was covered with such a heap of papers that I feared my homework would be lost there forever. About six weeks later, one Sunday morning about eight o’clock, [my wife] Anne and I were awakened by someone banging on our front door. It was Neyman. He rushed in with papers in hand, all excited: “I’ve just written an introduction to one of your papers. Read it so I can send it out right away for publication.” For a minute I had no idea what he was talking about. To make a long story short, the problems on the blackboard that I had solved thinking they were homework were in fact two famous unsolved problems in statistics. That was the first inkling I had that there was anything special about them.”

This story has been used to show that it’s our own preconceived notions about the difficulty of a problem that keep us from solving it.  Over time the details of this story have been exaggerated but the main idea holds true. I’m about to dig into more of the programming side and this is useful to me.

Another interesting tidbit was this his professor asked him to only submit the solution as his doctoral thesis. Instead having to produce a document in a specific format, the key information was what was most important.

I will wake up at 10 tomorrow and be late.

Jordan's Blog

The sum of our parts

I just realized the other day that as Specify continues to grow and add new features, we are constantly leveraging more and more third-party services to get things done quicker and more efficiently. That list has gotten long enough to warrant a blog post! So here are some of the tools that we have found useful (or at least interesting). We don’t use all of these, but have spent some time checking them out.

  • Beanstalk. I love Beanstalk deeply. Its automated deployment system has changed the way we write software as a team. If you use SVN or Git, check out Beanstalk.
  • WordPress, of course (it powers this blog). Heard of it?
  • KISSmetrics. We haven’t started tracking data with KISSmetrics yet, but I am impressed with the product. We recently got a lifetime free account through an AppSumo deal and have been playing around with its API a bit on our development server. Very cool and powerful. A big step up from Google Analytics.
  • Chargify. Chargify gets an honorable mention here, even though their latest pricing maneuvers really pissed us off. If you can afford their premium pricetag, they offer the best subscription billing API out there. We even wrote a ColdFusion API wrapper for it.
  • Strophe.js. We wrote out own XMPP chat client in javascript using Strophe.js to power our collaboration features. Strophe is a great tool for adding XMPP support to your app.
  • Openfire. Openfire is our XMPP server of choice.
  • UserVoice. We’ve just started using UserVoice to allow our users to give us feedback so we can improve Specify.
  • SnapEngage. Another one we haven’t started using yet, but it looks great. We are going to add it to our home page.
  • TypeKit. TypeKit is the best! We use it for the nice font on this blog. Excellent service, well done.

Bike Shelf

Check out this awesome Bike Shelf!

The Future of the Book.

More wonderful work from IDEO. A very thought-provoking exploration of three unique concepts for digital books.

The Future of the Book. on Vimeo

Good Job, Google! Two-step Verification

Google announced today that they will be rolling out a new two-step verification process for all of their Google Apps users.

These days, more and more companies are moving their data into the cloud. Its excellent to see Google setting the bar a lot higher when it comes to keeping it all secure. With the traditional style of authentication that most software uses, if your password gets stolen your account is toast.

The two-step verification process that Google has created lets you choose to have a SMS sent to your phone when you log in. This SMS contains a short verification code that you enter to finish logging in. To keep this from becoming cumbersome, you can opt for the verification once per computer.

This means that even if someone has stolen your password, they won’t be able to log in to your account without also having access to your phone – quite a nice added level of security!

Check out Google’s official blog post about it.


I’m a big fan of bookmarklets. While Specify’s not so top-secret Clipper bookmarklet is in the works, I thought I’d share another one that I use from time to time.

quietube | Video without the distractions.

Parsing Measurements or: How I Learned to Stop Worrying and Love Regular Expressions

Our most recent challenge came while trying to figure out how to let Specify users enter dimensions on their specs.

In earlier versions of Specify, we offered a simple text area. This worked fine until we learned that some of our users often need to describe dimensions in varying units of measurement (imperial and metric systems).

In order to meet this need, we had to create a new Add/Edit Measurement dialog to allow for more structured entry of measurements.

After some research and discussion, we agreed on the following points about the Add/Edit Measurement dialog:

  • A measurement consists of 1, 2 or 3 dimensions, named width, depth and height. The user should use one dialog to enter a 1, 2 or 3-dimensional measurement and give it a label.
  • Users should be able to enter each dimension in plain English. For example, acceptable input should include strings like 4 inches, 4.5′, 5ft 5.5in and 5′ 6 3/16″
  • Users should be allowed to freely mix different units of measure within one measurement. For example, 3cm w x 4in d
  • The app must be able to convert these measurements between the two different systems (metric and imperial) for display on spec pages and exports.

The dialog we designed looks like this:

All the codey details after the jump… Continue reading…

Making your own success()

Earlier on during the development of Specify, we faced the need to extend some of jQuery’s ajax functionality.

Specify makes heavy use of jQuery’s various ajax functions in order to request various pieces of the UI as the user navigates the site. In fact, there are only 3 real “pages” in the traditional sense – almost everything happens without any page refreshes. This includes handling the submissions and responses for a few dozen form elements.

Normally, jQuery assumes that any response that doesn’t trigger an error (404, a timeout, a JSON parsing error) is “successful.” This certainly is useful, but wouldn’t it be even more useful if jQuery’s ajax functions could also judge whether or not a request was successful based on what is actually contained in the response?

We accomplished this by adding our own global success() and error() functions which wrap around the default jQuery.ajax() ones. These check for the existence of either HTML elements with certain class names (if it was an HTML request) or a root-level JSON node of certain names. This means that we can have the server send back something like {“ERROR”:”This is an arbitrary error!”} and the ajax() function will react as if a “real” error has occurred, which is exactly what we want.

Code after the jump…

Continue reading…

Copyright © 2004–2009. All rights reserved.

RSS Feed. This blog is proudly powered by Wordpress and uses Modern Clix, a theme by Rodrigo Galindez.