Anthony Panozzo's Blog

My goal: to have a mobile app that downloads its initial database from the server instead of pulling the data down through the normal API one at a time. This was for speed reasons, and there are probably other implementations and methods to try. Basically, if the app has never synced, pull down the database.

A bunch of posts on the subject (not exactly what I needed, but helpful): Using a local database with Titanium Update database and table content DB install from remote sqlite file The official database documentation Some helpful SQLite documentation for generating the dump from your database A nice way to programmatically modify the table that you dumped with some examples

Here is a presentation that I gave to the Indy.rb Ruby user group in Indianapolis. It covers the advantages of using RR (double Ruby) for concise mocking and stubbing and gives some real-life use cases to inspire thinking about testing using test doubles.

(Slides no longer available.)

I got this strange error when in my Rails application:

DEPRECATION WARNING: form was removed from Rails and is now available as a plugin. Please install it with rails plugin install git://github.com/rails/dynamic_form.git.

With the popularization of lean startups, minimum viable products (MVPs) have recently entered into business and software lexicon. Who can argue with building more than you actually need?

Many people seem to interpret MVP as the first iteration of their product. Once they build that version, they can add more features, and users of the product will be even happier than before. Businesspeople sometimes talk about needing to build an MVP so they can launch and raise more funding.

If you are building out a half of a product as your first stab, you might as well just call it version one or iteration zero or something like that. No sense in polluting the MVP term.

In this article, I will argue that most so-called "MVPs" are not really MVPs because they are not focused on the process of learning, and as a result, wasteful. I think that there is a lot of value in not trying to build too much. This low-hanging fruit likely accounts for the proliferation of the term. But I think that a lot of the value of an MVP is testing the risky assumptions every startup has.

Definition of minimum viable product

Well, what is a minimum viable product, anyway?

A Minimum Viable Product has just those features that allow the product to be deployed, and no more. The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. It is a strategy targeted at avoiding building products that customers do not want, that seeks to maximize the information learned about the customer per dollar spent. "The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." The definition's use of the words maximum and minimum means it is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense.

Even if you are not running the same technology as someone else, you can gain insight into how they solve hairy problems by reading through their summaries of strange fixes.

Today there was a great post on debugging CSRF problems in Rails. I thought it was interesting and had run into something similar but not nearly as convoluted. It was useful to see the steps that the post author took to figure out what was the root cause of the problem, tracking back to what the change in the Rails code base was that caused him to have invalid assumptions.