I enjoy building stuff that fits the needs of large groups of individuals. I specialized in doing so with limited resources, deep layers of uncertainty and great doses of ambition. I contribute to Internet startups that plan and rationalize their course of action.
I founded @itnig and @camaloon. While holding the helm of Camaloon I help other entrepreneurs at itnig to build products and services with strong technological and internet basis and deliberate vocation to differentiate.
I find specially interesting the case of Richard Moross and MOO.com. They started out by partnering flickr, which made them global right from the early days. At the time, they were sending their fancy boxes and business cards everywhere in the world from their headquarters in London. After some time, they had gathered enough data to analyse what countries were showing greater traction. That seems to me a very Lean approach to internationalization taken by Moross. From their business model perspective, their strong focus on developing key partnerships initially and using their $5M VC money to give away freebies in exchange for critical mass proved to be a successful strategy.
The top 1 country was, indeed, the USA. So, after two years, they established there they second base of operations, at Rhode Island. Today MOO.com is one of the 10 best companies in UK according to the Guardian Newspaper and they have almost a hundred employees.
Two interesting concepts taken from an interview to Paul Graham in 2005:
[talking about types of founders] The big difference between hackers and business guys, at least in the beginning, is that what you need is hackers and not business guys.
When you are young, you finished school, it is the best time to invest. There’s time to cash in later. Do something hard, take a work where you can learn, start a business. Don’t satisfy yourself by doing something you know you can do.
In the project I’m working on I had to create a script that would allow users to update their information directly from their (show) views.
From a general perspective, I think it is useful to give users the option to edit-in-place contents by just clicking them, leaving forms for when there is no other alternative (such as creating new objects). To me, an in-place editor feels more natural and usable and helps notably the user experience. The obvious fact is that most real world applications, such as Flickr or Facebox have implemented this feature in most of their interfaces.
Basically, BestInPlace makes possible to tag (via HTML classes and HTML5 data* attributes) any field that is going to be user-editable so that the script automatically converts it to an form input when the user clicks on it, with no further muss or fuss for the developer. Of course, this field can take the form of a one-line text input, a textarea for longer texts, a select dropdown that will populate with your custom collection of options or boolean sort of data that works the same way a checkbox would, and allows value customization as well. Additionally, the script will trim and sanitize all user input, display server errors in case the format is not proper, it will also allow you to provide an external handler to activate the input.
Before getting into details.
I thought it might help somebody the way I’m currently managing my WordPress theme. First of all, I have to say it would be better to have an actual WordPress installation in my localhost, so it would be easier trying out changes (on themes and plugins) before committing them. I’m just too lazy for that, so I’d rather have only one running installation of WordPress on my server and a moving git repository for the theme alone. So this is how I do:
1. I have a Github public repository to share my theme (not like anyone is interested anyway)
2. I have another private repository in my server to store all the changes of the theme and actually update it.
3. I have a local repository in my computer for the theme.
4. The theme is actually stored at my_server_root/my_wordpress_path/wp-content/themes/bernatfarrero/
As most of Rails developers, recently I’ve been through a process of unlearning all concepts of older versions of Rails and learning again the new ones of 3. But hey! I must admit that so far it’s been more pleasure than pain as things only get simpler and more natural than they used to be!
Here I’d like to talk about how simple it has become to integrate unobtrusive jQuery to a Rails app. Let’s use as an example a system of comments. I’ll create a simple app to create YouTube like comments:
Last week in Artificial Intelligence (5th year’s subject in FIB, my university), we worked in a project analysing the empirical differences among some local search algorithms. We were given AIMA, an AI Java framework, and a problem to solve with those algorithms. The problem consisted basically of creating optimal K bus routes in a squared city (called SquareTown) for a randomly generated set of P bus stops. By optimal they meant minimal cover distance including all stops and minimal difference between the distances of every two consecutive stops. The algorithms to be used were Hill Climbing and Simulated Annealing. The full formulation of the problem can be found here (in Spanish).
I needed to copy the EXIF information data from one image to another and I found the nicest program ever: ExifTool, a Perl command-line program by Phil Harvey. It works on Mac and Windows. Once installed, you open your terminal and type:
<code>exiftool image.jpg #To read exif data
exiftool -tagsFromFile original.jpg new.jpg #To copy EXIF tags from original.jpg to new.jpg</code>
You can also read the docs to know how to change any field of the EXIF data and so on. Very handy, thanks Phil Harvey!
If you are a nerd, inexhaustible-price-tracker, (too often) fancying some expensive gadget to be bought but being permanently strapped for cash? Well, that’s me. And sometimes I get damned by the false surprises of coming across scams like this (or this, or this). A brand new Nikon d90 for 600€, The worst is my reaction of almost forcing myself to believe that it could be true, who knows, someone could be taking stuff straight from factory and selling it half-priced over the Internet. So I always waste those seconds of my life carefully writing those people with strange names, only to be answered in few minutes by some automaton. This time the name was not strange, it sounded very English:
Another common task in a Web app is to create a register of events. Sometimes you want to email your users about something that happened, others you just want to show somewhere a table with the timeline of recent events. For example, let’s take the example of a project managing application (like the well-known Basecamp of 37Signals).
This comes from the last app in which I worked. I reckon there are two ways to embrace this problem. One involves adding or using the rails default field updated_at of every table in the database. Of course some other handy fields might be added as well, such as updated_by and updating_description. Showing a register of events in this case means taking every model in the database, ordering it by the updating date and limiting the results to a given constant. All of those should be added by the controller to a hash or an array and would later on be globally ordered by the value of the update field, only to be delivered to the views and finally displayed. Nonetheless, this method could get stuff complex over time, specially when using a large set of models, and it gets events dependent to subjects.
Another approach is using a self-contained concept of event. Everything done in the system is recorded and added to a register, to which we can access whenever we please and display it. As usual, someone has had this problem before and created a useful plugin for us, in this case it’s called timeline_fu. I added though a very small modification to serve my purposes.
I’d say one of the most common aims of an application is making it self-sustainable and self-maintainable. When we deliver the last version of an app, we usually dream of forgetting completely about it. We want to have nothing else to do with that client (unless of course she wants an upgrade, another product, or she refers us to another potential client). Nonetheless, this hardly ever happens just like this. At least not to me (why is that?). A finished project usually means infinite calls and all kind of unexpected sorts of stressing problems.
Most frequently the reason is someone not reading your thoughtfully written documentation, or maybe someone regretting the way some particular functionality works (usually one explicitly detailed and requested by herself in the past) or [and that's my point today], someone simply “forgetting” how to add or format content in their web.