There was one thing that I didn’t quite get. As a founder who has a vision about your product (is there any other way at all?), why on Earth would you need a product manager? The founder, from all the people in the world, should be the one who knows exactly how the product should work and who it is for. Not having previous experience with product management shouldn’t be an acceptable excuse to any founder.

Apparently it seems that it is acceptable to work on the first stage for around 6-9 months and spend approximately $375K while doing that. Don’t you think that it’s a bit too much? If a founder doesn’t take any seed funding to build a minimum viable product (strongly recommended in my opinion) then I bet that most of the founders out there don’t have that spare $375K to spend just to see if their idea will fly or not.

If I wouldn’t have any previous experience I probably wouldn’t be surprised by the mentioned time and cost to build a minimum viable product. However, I have some experience when it comes to helping founders to get their MVP out there. With that experience in mind, I’ve found that it takes usually less than 3 months (one designer + one engineer + some additional help will go a long way) to get the first version done. It will usually be good enough to test if their idea and business model works and go after seed funding on much better terms than without a MVP.

You can do it for less

Now, some more personal experience. You might or might not know that we’re working on two products of our own and we’ve taken somewhat different approach on execution for both of them.

Shoperb, a rather complex eCommerce SaaS platform, has been in the works for over a year with total actual development time spent around 5 months or so. We want it to have all the necessary features to successfully run an online store when we launch some time next year. From technical point of view Shoperb has much more complex features (tax rules, shipping rules, etc) than an average product we work with (want to take a look at it, let me know). On top of that, at some point I realized that the design could be quite a bit better, so I redesigned it even before we launched. That could be considered as a mistake but I’m still thinking that it was a right decision – we’re coming out with better product thanks to that.

Then we have Photry, a cloud backup platform for photos, that was created within 48 hours at Rails Rumble 2010. With that time we built a MVP that works well and is actually getting some organic traffic and more signups than we would ever have hoped for. That was about a year ago. In the meanwhile a new design was created (a lot better, if I may add) and about a week ago one of our engineers started working on it. By the end of this year we will have a next version of Phtory ready and hopefully in early January we’ll have a nice re-launch.

Both of these services are being built with very limited resources. Only more lately one of our engineers have worked on Shoperb almost full time and the progress this far has been awesome. Same experience with Photry – amazing progress with minimum amount of time. How much is it costing us? A lot less than was brought out by Mr. Wilson’s post.

Conclusion

So what am I saying with all this? It is possible to build something without costing founders arms and legs. Hiring five employees that early in the product’s life cycle clearly seems like spending too much. Founders can do and do it well with less money spent. If a founder has some savings (lets say $50K) then they most probably can do without seed funding. Even if they need funding, they can take way smaller amount of funding and save more equity for themselves. They can find themselves a decent engineering partner to build the MVP for their awesome idea. When looking for that partner, a proper due diligence on partners is strongly recommended, just like it would be done with any investors or employees. Getting in touch with their previous clients will go a long way in building that relationship.

I know that I’m biased but with $50K it is more reasonable to just outsource this work to experienced experts (may I recommend us?). With constant communication it will be a breeze to get your first version out. Just like we would be sitting in your office. Except you don’t need to spend on office or anything related to it.

On top of that, this will save founders (even if they’ve taken seed funding) a big slice of equity. Now isn’t that what we all want, get more for less? I know that I prefer it that way and most probably so do you.

To start off what Minimum Viable Product means to us, I would like to quote an article from Wikipedia:

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.

From my own experience when working with various startups is that you don’t need to necessarily have that simplified approach. For us, a MVP means simply a limited subset of features and a possibility of some manual labor by the founder. However, by no means should it be acceptable that MVP stands for a crappy product. The user interface, and the user experience in general, has to be absolutely brilliant from the day one. That’s how you will create fans who love your product.

On most cases it should be possible to create a Minimum Viable Product in about 3 months of development. Of course it takes more time and resources if you’re building a SaaS platform to maintain nuclear power plants. Not doing anything that high scale? Well, 3 months should be enough to put together a simple, yet beautiful, product that gives your future customers something to work with. Something that gets them thinking on what more could they use and what could be changed in the product. Now that’s a perfect position to be in and I bet that most founders would love to be there.

You can start building some traction with that product, get more ideas on which features to implement and just do what your customers will love. Instead of going somewhat blindly in guessing what they might want. If you’re lucky, you can even implement billing/subscription plans and already start charging customers for the awesome service you have built for them.

I believe that the following will conclude it perfectly. Minimum Viable Product will help to remove the guesswork in building your awesome product or service.

Lets build it together. If you want to know more about how we work, just get in touch with us.

Let’s get started with code right away – this is how the feature works:

Now the common pattern in controllers looks like this:

What I want to be able to do is this:

Adding this functionality is actually pretty simple – we just have to create some code extending the render function.
This next piece of code actually extends the module containing the functionality for the redirect calls.

You can place this in an initialize or somewhere in your library directory and explicitly require it. Hope this is helpful for you as much as it is for me!

We are hiring!

More specifically we’re looking to fill two positions in our Tallinn office. You should be awesome and down to earth kind of guy (or girl), know your stuff and be easy to talk and work with. You should be really great with Ruby (Python, PHP and Java are good starting points as well) or with HAML, SCSS and Javascript. As always, we prefer people who are comfortable in wearing multiple hats – the more you can do, the better. You will be working on various projects for our awesome clients (mostly startups around the world), as well as on our internal projects – Shoperb and Photry. Besides that, we have a lot more ideas that we want to try out and will also support you with making your ideas form into something meaningful as well.

If you’re interested in joining us or have any questions then just get in touch with me and we’ll take it from there.

Shoperb – it’s all coming together now

Lately we’ve been able to get a lot of work done on Shoperb and it’s all coming together rather well. We’re currently preparing for the launch of a highly customized Shoperb store for an online music business, which will be followed by a private beta for the platform. If you’re interested in participating, please go to www.shoperb.com and sign up for beta program. We will get in touch with you as soon as we get going with the beta. In the meanwhile, if you have any questions or thoughts about Shoperb, feel free to drop me a line.

We’ve moved to a new office

Secondly, we have moved and are now located in Delta Plaza that is just a few kilometers away from our last office in downtown Tallinn. We have been looking for a new office for quite a while and when the opportunity came, we decided quickly. About a week or two later we were already in our new office. Anyway, enough of this chit-chat – lets look at the photos.

First you’ll need to enable Cron for your Heroku application. That can be done from Heroku control panel and the basic version is free. It runs once per day which is enough for this use case.

The next thing you have to do is add the Heroku gem to your Gemfile:

The last step is to create lib/tasks/cron.rake and copy the below code:

You can get HEROKU_USERNAME and HEROKU_API_KEY from ~/heroku/.credentials. Probably HEROKU_API_KEY is just an hashed password and not really an API key, but it will work just fine :)

Just remember it’s not really public information so don’t use it in open source projects or anything big – it’s probably fine for personal and small projects where you are not worried about someone stealing your Heroku login – pretty much what the free Heroku package is for anyway.

With the shared database you are allowed 2 backups for free and the above script will always delete the oldest one before capturing a new backup. This means that you can have nightly backups with 2 days history for free.

Enjoy :)

Lets keep it easy and maintainable

WordPress works rather well for creating awesome websites. Even our own site is built on top of WordPress with some customization here and there. What should you keep in mind when you’re just starting your WordPress development career? I’m actually not going too much into the technical stuff (you need to become friends with WordPress code anyway) but instead I’ll share some tips and tricks that have worked well for me in the past.

Clean start for a new project

I’ve created a clean database dump that I can use to easily setup new project from scratch. It doesn’t have any posts, categories etc – just a blank skeleton that I can easily import.

If you do lot of themes then you probably want to create a skeleton theme that you base your other themes on. That’s what I did and it saves me bunch of time when starting with new projects.

Version Control System (VCS) to use with WordPress

Just one word – Git. If you’ve ever tried to use Subversion with WordPress then you’ll know that updating any plugins will mess up your live installation. Subversion keeps .svn folders in every folder that has been checked into VCS. When you update the plugin then the old version’ folder will be deleted, zip file downloaded and the folder re-created. This time, without the .svn folder and we’ll have a problem.

WordPress Core, themes and plugins

All of the core files are kept in Git repository. When an update comes out I’ll just download it to my local development machine and make sure that it’s working fine with my plugins etc. From there on I’ll just push it to the repository and deploy to live system. Same pretty much applies to themes.

When upgrading plugins, quite often a database update is needed as well. That’s one of the main reasons why I don’t keep the plugins in Git repository but instead upgrade them in our live system. Of course, first I’ll make sure that they work on my development system.

Importing older versions made easy

We’ve created a rake script that converts data from one messy WordPress database to a new and clean one. It pretty much takes over the content part of the database – posts, tags, categories etc. Helped me a lot to create this site in rather short time.

W3 Total Cache for performance

W3 Total Cache is your best friend for performance. All of our assets are hosted on Amazon AWS and served to you quickly. On top of that, you’ll get a good Google Page Speed score.

Disable WordPress AutoSave and Post Revisions

I find both of them to be highly annoying and usually turn them off as the first thing I do. There’s few lines that should be added before the end of wp-config.php. Just before where it says “That’s all, stop editing! Happy blogging.” (and they mean that).

That’s all folks

As you see, getting started with developing websites that are based on WordPress isn’t really rocket science. It’s always helpful if you’re already familiar with PHP and MySQL – makes your life with WordPress a lot easier.

If you have any comments or questions then just post them below here and I’ll update the post to answer these (or reply to your comment).

Let’s take a theoretical example – you have a medium sized Rails application with a need to calculate statistics based on the data. This calculation has to be done often (like once per 10 minutes or once per hour) and it’s really not that expensive – let’s say it takes about 1500ms to complete.

Note that the calculation task itself is defined in a model and it uses various resources from the application, which means the taks has to load the whole application environment.

I will skip the actual crontab definition as it would serve no purpose at this time.

Now this task will be ran every 10 minutes, and as it’s not really expensive, it doesn’t require much resources either. But what happens when this task runs during the peak hours of your application, when you have the most visitors?

As the task loads up your Rails application environment every single time the cron job is invoked, it will eat up HUGE amount of resources because booting the Rails environment is really expensive (and I mean really expensive). So even though the task itself is harmless, the rake task will cause spikes in your server load, which coupled with peak visitor hours will cause swapping and slow response times.

In our case, we had 3 different cron tasks, which ran in 5, 10 and 1 hour intervals. This means that every hour there were 3 Rails environments booted and loaded and 2 environments every 10 minutes.
You can imagine the strain this is putting on the application server. We saw response times up to 20 seconds because of trashing.

Some people suggested that I should use Whenever instead of plain old cron, but what they did not realize is that this gem just eases the process of defining cron tasks, but the end result of invoking the task is the same – the rake task loads the whole environment. The ultimate goal is to avoid booting up an extra Rails application environment and to re-use an instance already loaded in memory instead.

One of the first solutions I considered was having a separate, special controller which would contain the task specific logic and then invoke those controller actions from cronjobs via wget.
While this would achieve the ultimate goal of re-using an existing instance of the application environment (as the Passenger worker handling the request would already be bootstrapped), this felt somehow fragile
and inefficient. Plus I’d have to deal with some extra security to prevent those actions from being accessed from the outside.

The other solution was to use resque-scheduler which let’s you to schedule tasks for Resque similar to crontab. And we are already using it for several background jobs anyhow.

The way Resque scheduler works is it runs a separate scheduler worker, which polls the configured schedules after every 5 seconds and checks if there are any tasks that should be ran. If any are found, it looks up the task definition and pushes the task to the configured queue for Resque to handle. From here on everything is handled like a regular background job.

In case you are not familiar with Resque, I’ll briefly explain how it works in general. Basically you take a piece of code you want to execute asynchronously and queue it with Resque. Jobs are stored in Redis, with the ability to define multiple different queues and also set a specific queue per task. To process the tasks, you run worker processes, which can monitor one or multiple queues and execute any tasks found in them.

Booting up a worker process loads the whole Rails environment into memory and the process itself will running infinitely until you shut it down. This fits our needs perfectly, as we can queue any number of tasks we would otherwise run from cron, and there would be zero bootstrapping overhead. The only thing left now is to configure the scheduler.

I will provide the original cron configuration and the whole scheduler setup by code examples.

Note that all Resque tasks must implement the class method self.perform(*args), which is invoked when the task is processed.
I preferred to group all my cron tasks into one single class CronTask and work a little magic to handle all of them from single point of invocation.

The logic behind this implementation is pretty easy – you define your job class, queue name and cron schedule in the schedule.yml file and when the task is queued for processing, the self.process method is invoked with the method name as it’s argument. This will in turn create a new instance of CronTask, and invoke the method that was passed to self.perform. Simple and effective.

“So how big of an optimization was it?” you may ask. This image should speak for itself – it’s the application servers load for the last 24 hours (those big spikes are deployments and application server restarts).

The application went from choking on peak hours to almost completely idle. The improvement in response times and in general performance was huge that it actually baffles me how this issue is overlooked in most of the discussions of about how to handle cron tasks with Rails applications.

If your periodical tasks do not run that often, or they run during idle hours (when there is next to no traffic), you are probably okay with using a simple cron/rake solution. But if you have tasks that run often, and even more if there are several of them, I strongly suggest checking out Resque and resque-scheduler and hopefully this post will be of help understanding and configuring it for your application

If you have any questions or notes about this post, please leave a comment.

The first issue I encountered with assets was that they were only concatenated in production, but not minimized or packed or anything like that. Now as we didn’t generate a new blank Rails 3.1 application, we missed out on some critical configuration variables (and the documentation on the new stuff is understandably pretty sparse at the moment). So to enable any kind of compression for your assets, you need to add the following configuration statements to your environment specific configuration file (these are default values in 3.1 applications).

I did a little of poking around in the source and it seems that in addition to Uglifier, you can also use YUI Compressor and Closure Compiler as Javascript compressor backends.

Now the second issue was a bit more weird – only a really small subset of the assets were being compiled with rake assets:precompile.
I spent quite a lot of time tracking the cause for this behavior and finally stumbled upon the configuration for the assets feature:

The regexp is meant to find all of the non-css and non-js files in the asset paths and compile them – I’m guessing that this is mainly to handle SCSS and CoffeScript files (again the documentation is hard to come by).
As an unexpected side-effect it’s matching files like jquery.min.js and jquery.autocomplete.js, but not top-level assets like admin.js, which does not really seem to be the desired behavior.

There are basically two ways asset compiling would make sense:

• All of your assets get compiled: every single file from the asset path – from plain .css to .scss and .coffee files and manifests – get compiled and compressed. Then you just use whatever assets you like in your layouts.
  
  
• Only the top-level manifests are compiled: this means the files you are explicitly linking in your layouts, stuff like application.js and admin.css and so on.

Considering that you have top-level manifest files that group all of your dependencies, you rarely need to just use one single asset so I decided to go with the second option.
In order to only compile the top-level manifest files, you need to avoid the built-in regexp from being run and define the files your want to compile manually.

This does seem a bit verbose (especially if you have lots of top level manifests), but I prefer this over the default broken solution or a mess of files that compiling every single asset would result in.

Still not satisfied

There is one more thing that bugs me about the asset pipeline in Ruby on Rails 3.1 – if you reference a manifest file in your layouts in development mode, you will get a concatenated resource as the output.

If you are requiring a lot of different files in your manifest, it will most definitely be annoying to debug your javascripts/stylesheets. This is where Jammit really outperforms Sprockets – you define
a resource (basically the same as a manifest) and in development mode that resource is expanded into separate files, making debugging really easy as you know exactly which file you need to check etc.
And in production the same resource is concatenated and compressed into one single, small file.

I feel this is the way how assets should work in Rails 3.1 by default also – the benefit is pretty clear, at least for me.

Update: So it seems you can avoid having your assets being concatenated in development like this:

Thanks for the tip, Bruno Michel!

His previous work experience includes a small design agency and bunch of freelance experience. Over the years he has created wonderful website, user interfaces and logo designs (and lets not forget the iOS user interfaces).

His first task at PerfectLine is to give Photry a new, better looking face. Thanks to his design and excellent collaborative skills, Photry will become better service that I hope you’ll enjoy. More about the work we’re doing with Photry in my next post.

What’s allowed by default

The sandbox disables almost everything by default. The two major exceptions are that reading/writing to %TEMP% is allowed and reading from the registry is allowed. If this is all your plugin needs you are lucky :)

Part 3 of Inside Adobe Reader Protected Mode discusses the whitelisted features in more detail. Part 1, Part 2 and Part 4 are also worth reading for more background information on protected mode.

What’s possible

Fortunately it’s possible to customize the very restrictive default policies.

The Inside Protected Mode series indicates that there seems to be some sort of API to customize the sandbox rules (AddRule() examples), however it seems yet to be released or it doesn’t even exist (which kind of makes sense from a security point of view).

Fortunately there’s another way: ProtectedModeWhiteList.txt.

ProtectedModeWhitelist.txt must be in the same directory as AcroRd32.exe (HKLM\Software\Adobe\Acrobat Reader\10.0\InstallPath).

It must also be enabled by creating the following registry key bUseWhitelistConfigFile (type: DWORD, value: 0×1) under HKLM\SOFTWARE\Policies\Adobe\Acrobat\Reader\10.0\FeatureLockDown.

After enabling the usage of whitelist config we can define our own custom policies that allow the plugin to read/write to any location on the filesystem or any location in the registry.

Adding registry exceptions

REG_ALLOW_ANY = HKEY_CURRENT_USER\Software\MyPlugin

Adding filesystem exceptions

FILES_ALLOW_ANY = %APPDATA%\MyPlugin\data.txt

There are actually a few more things that can be allowed using this file, see Adobe Application Security for more details.

Debugging Protected Mode

If you are having a problem with Reader X that doesn’t exist in Reader 9 or Reader 8 then Protected Mode is a very likely cause.

The first thing you should do is to try disable Protected Mode and see if the problem continues to exist. To do that uncheck Edit -> Preferences -> General -> Enable Protected Mode at startup.

When you have determined that the problem is really caused by Protected Mode the next thing you should do is enable Protected Mode Log file. To that check Edit -> Preferences -> General -> Create Protected Mode log file.

With this file enabled you can see most things being denied by Protected Mode and hopefully it will also recommend a rule to add to ProtectedModeWhitelist.txt.

What’s impossible

Also there are a few things that I’ve found impossible to do with Protected Mode enabled.

First it seems to be impossible to use the Windows Help system. It seems that the call to HtmlHelp() wants to launch an external process and it gets denied silently by Protected Mode. Another thing that seems impossible is reading proxy settings stored by Internet Explorer.

I have tried creating ProtectedModeWhitelist.txt rules that allow almost anything (events, process exec, files, registry etc.) and have no ACCESS_DENIED lines in there – but it still doesn’t help. When disabling Protected Mode everything works fine so those things somehow get blocked silently.

The general rule seems to be: don’t try to talk to other processes :)

Conclusion

Last thing I would like to mention is that when creating ProtectedModeWhitelist.txt files (probably by your plugin installer) – be nice and leaving the existing rules there, don’t overwrite anything.

Hope this was useful to someone and don’t be shy to leave comments if you discover something more about Protected Mode :)