Tiago Matos’ Nest

Este último fim de semana tive o prazer de participar no INEO Weekend, um evento em que se cozinha num espaço moderno e agradável, uma receita atípica. Têm-se como ingredientes “mentores” que adocicam e guiam a força e tempestuosidade dos “promotores”, com diagramas, passagens literárias, bons exemplos e bastante senso comum temperado pelo “been there, done that”. No final serve-se o cozinhado à prova dos “investidores”, à mercé de um projector cronometrando 10 minutos.

O resultado traduziu-se num fim de semana bem passado, repleto de discussões entre os todos os participantes, como ao redor das várias porções de salgadinho e Ice Tea de Manga.

De sublinhar o ambiente informal, em que todos dão o seu contributo e se esquecem um pouco as paneleirices muitas vezes subjacentes a eventos nesta área do empreendedorismo. Um estilo de evento a seguir.

Eu co-representei o nosso projecto Vendder que foi revisto e discutido sobre diversas luzes e ângulos por diversos mentores, como João Pereira da InovCapital, Ana Almeida da Tapestry ou Paulo Gomes da Reusable IT e aprendi ou re-lembrei que:

• Nem sempre é simples calcular o custo de um projecto
• Calcular break-even é um exercício para ser praticado
• Deve-se ter presente a fatia de mercado que pretendemos atingir
• Como sondar o mercado para definir o valor do serviço e assim preço a pagar.
• “Planos de negócio” são para esquecer e antes de “planos” quer-se “negócio” e simples projecções
• O capital existe, faltam as boas ideias, equipas e execução
• Há capitais de risco com bolsas de diferente tamanho
• Aposta-se em equipas coesas, eles são a alma do projecto
• Há que apontar o canhão para o cliente alvo a abater, não há muitas bolas nem tempo para algortimos balisticos refinados.

Fez-me lembrar os meus tempos em Londres, em que falavamos callbacks em AJAX entre duas pints de Guiness e umas apresentações que pareciam sempre sido feitas num iPhone entre 5 estações do Tube.

cross-post from http://www.nship.org/2010/04/ineo-weekend/

#reminder
find . | xargs grep '.tec-event-entry'

#reminder

ctrl+a moves your cursor to the beginning of the line
ctrl+e moves your cursor to the end of the line

tks to @pharaujo

I had a surreal experience the other day. I was sitting in a coffee shop and watched someone (at the recommendation of a friend who didn’t realize I was within earshot) open up my blog and start reading it. Right there, out of the corner of my eye, someone was experiencing me (well, digital me) for the first time.

Here it was, my first impression writ large. No fair running over and saying, “no, skip those two, those two aren’t so good, go back a month or two and read the generous, thoughtful ones I wrote…”

It’s like DNA. One cell carries the coding for all of them.

via http://sethgodin.typepad.com/seths_blog/2010/04/when-a-stranger-reads-your-blog.html

I remember having to explain why to favour distributed source control at Widetail. We use mercurial. Jilles couldn’t be more right…

Not using git limits you to one branch: trunk. Don’t fool yourself into thinking otherwise. I’ve seen branching in svn a couple of times and it was not pretty.
Not using git forces you to either work in small, non invasive increments or accept pro-longed instability on trunk with lots of disruptive change coming in. Most teams tend to have a release heart beat where trunk is close to useless except when a release is coming.
Not using git limits size of the group of people that can work effectively on the same code base. Having too many people commit on the same code will increase the number conflicting changes.
Not using git exposes you regularly to merge problems and conflicts when you upgrade your work copy from trunk.
Not using git forces a style of working that avoids the above problems: you don’t branch; people get angry when trunk breaks (which it does, often); you avoid making disruptive changes and when you do, you work for prolonged periods of time without committing; when you finally commit, you find that some a**hole introduced conflicting changes on trunk while you weren’t committing; once you have committed other people find that their uncommitted work now conflicts with trunk etc.
Given the above problems, people avoid the type of changes that causes them to run into these problems. This is the real problem. Not refactoring because of potential conflicts is an anti-pattern. Not doing a change because it would take too long to stabilize means that necessary changes get delayed.

via http://www.jillesvangurp.com/2010/04/18/git-so-far-so-good/

This Sunday I have done something diferent for a lazy day like this: hosted an informal presentation about e-commerce at Cooltiva-te at Clube Literário do Porto. It’s a very light presentation browse you from the early days of Ebay and Amazon to the last trends in e-commerce, like Goupon, Facebook and Manpacks. Check it out and share if off.

Randomly browsing the internet I bounced into CouchSurfing.com.. since February I do not check it (shame on me). Worse than that is the fact all incoming emails from CS were going directly to my trash folder. Result:

25 unread / unreplied CouchSurf request from people I know / don’t know (and other I still don’t).

Every time an international friend of mine send me a message always starts or ends with “where are you now?”.

First of all “textareas” do not have “value” attribute, so the title is a bit erroneous. Nevertheless, let’s get back to the point: updating texarea using jQuery.

I have tried:

$(’#textarea_id’).text(’value_to_update’);
$(’#textarea_id’).html(’value_to_update’);
$(’#textarea_id’).val(’value_to_update’);

and both “text()” and “html()” do the job but none brings you a flawless solution so my advise is to use native Javascript:

document.getElementById('textarea_id').value = 'value_to_update'

Most likely, you’ll do just fine with jQuery but for our translation functionality at Vendder we’re doing some funky stuff on automic updating / reading texareas.