toniBlog

How to get more than opinions @johannakoll #lsmlondon talk

Mon, 17 Oct 2011 03:29:00 -0700

I still have loads of videos to convert, next one in the line are Sal's ones :-)

Permalink | Leave a comment »

#luxr LUXi notes dump

Sun, 24 Jul 2011 00:26:00 -0700

Principles of lean UX:

team of 3 people: 1 designer + 1 product manager + 1 developer > highest velocity possible > quickest learning cycles
externalise : kanban for designers
goal driven and outcome focused
repeatable and routinized
FLOW think/make/check
focus on solving the right problem
Recognize hypotheses and validate them
Research with users is the best source of information
Generate many options and decide quickly which to pursue

Lean UX Practises:

write the test first
user quote need as sprint name
wireframe check
designer developer pairing
UX & Product Mgt participate in standup meetings daily
validation step
retrospective periodically

Permalink | Leave a comment »

#luxr LUXi books shopping list

Sun, 24 Jul 2011 00:21:00 -0700

The Four Steps to the Epiphany - Steven Gary Blank

The Entrepreneur's Guide to Customer Development - Brant Cooper, Patrick Vlaskovits

The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses - Eric Ries

Extreme Programming Explained: Embrace Change - Kent Beck, Cynthia Andres

Lean Thinking: Banish Waste and Create Wealth in Your Corporation - James P. Womack, Daniel T. Jones

Rocket Surgery Made Easy: The Do-it-yourself Guide to Finding and Fixing Usability Problems - Steve Krug

Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers - Dave Gray, Sunni Brown, James Macanufo

Don't Make Me Think!: A Common Sense Approach to Web Usability - Steve Krug

Permalink | Leave a comment »

#luxr LUXi tweets roundup

Sat, 23 Jul 2011 23:52:00 -0700

@SaintSal Externalise! It's about post-it notes and sharpies man! 4 people can stand around it together and talk about it. #luxr

@SaintSal Repeatable and routanised. Startups are notorious in making up ways to work. Work in repeatable ways that get results. #luxr

@Ultraman : Ux own customer empathy and work with developers to create something realistic is not only a #LeanUx #LUXr principle but a #design one

@SaintSal Pairing with designers saves a lot of time. To see how much, start with a test - pairing with a tricky bit. #luxr

@SaintSal Test-driven devel is for designers too! Why are developers allowed to get it wrong but designers are expected to get it right at 1st? #luxr

@SaintSal: @luxrco on emergent rituals vs strict processes: try starting with more rigidity then relaxing as it becomes habit. #luxr

@jacwex: Tom McCoy on product stewardship http://www.cooper.com/journal/2011/02/lean_ux_product_stewardship_an.html #luxr

@Ultraman : 3 person startup means you all have to chip in to fill gaps. Do what ever it takes! #LeanUx #LUXr

@hmitsch: Roman Voting: it's all about not talking and making decisions. #LUXr

@pmgandhi Behaviours are symptoms. Find the real problem #luxr

@pmgandhi: Research is not about surveys, it's about conversations with people. Get them to tell you a story #luxr #LeanStartup

@pmgandhi: Demographics less imp than behaviour and needs. Rich socialites and farmers use amazon alike #LUXr

@SaintSal @ultraman is talking about #gamestorming. More info on that at http://gogamestorm.com and http://leanca.mp too! #luxr

@mahemoff Apple UX works according to one persona, his name is "Steve ". Elsewhere personae are actually useful. #luxr

@javame Innovation at Google http://slidesha.re/prAolY the paper prototyping kit to build the park-jerk app I just mentioned at #luxr

@SaintSal: With personas, look for edge cases where if you design for them, you get the common user "for free." #luxr

@SaintSal: Pairing with designers saves a lot of time. To see how much, start with a test - pairing with a tricky bit. #luxr

@SaintSal: A good tool to track your learning is the risk log on thestartuptoolkit.com by Londoner @robfitz #luxr cc @luxrco

@javame: @ericries article about Vanity Metrics vs. Actionable Metrics http://bit.ly/q4lSID #luxr

@Ultraman : Build it and test it as early as possible. It is the only way to truly know if something works. #LeanUx #LUXr

@javame: if you are stuck just go faster! @clevergirl = legend #luxr

@Ultraman : If it does not work pull it. Knee jerk reactions are affordable when you do not have a brand reputation yet. #LeanUx #LUXr

@whatterz: "Test in pennies, spend in dollars." #LeanUx #LUXr

@hmitsch: Move from "Product Owner" terminology to "Product Stewardship" understanding, creating things together. We are one product team. #LUXr

@javame: empathy mapping http://t.co/F6gI70F to develop personas #luxr”

@SaintSal Usability testing is like your liver. It won't keep you alive but it will keep you from dying. #luxr #LeanStartup

@javame: http://slidesha.re/pGLFiM Janice aka @clevergirl slides are here! #luxr

Permalink | Leave a comment »

Ruby Developer opportunities in a Post Agile / Programmer Anarchy environment in Central London

Wed, 22 Jun 2011 01:28:00 -0700

I received this email from a recruiter yesterday and I had a good laugh, beside that I found the description of Forward quite spot on.

Hi Antonio,

I hope you are well. I have come across your CV on my database as I am currently recruiting for a number of Developer roles for a company in Central London, operating in a Dynamic Language environment (primarily Ruby and Clojure).

My client are at the fore front of Agile practices as they work in a "Post- Agile" environment or a "Programmer Anarchy" environment which was introduced and led by a former VP and Director of Strategy and Plans from ThoughtWorks.

In case you have not come across the term "Programmer Anarchy" before (it is very new as far as I understand), it is an environment that empowers the Developers to take full ownership of the project and work off of your own initiative as opposed to being set projects and targets by PM's / BA's, etc..

My client is able to pay a very competitive salary in Central London and their benefits scheme is healthy and innovative, offering innovation leave where you are able to work on your own projects. Although the salary is competitive, my client is looking for Developers who are looking to work in one of the most forward thinking environments in the industry and they will quiz you on your outside work interest (own projects, conferences attended, github accounts, etc...)

The CV I have of yours (I appreciate that it may be out of date and I apologise if this is no longer relevant) looks very interesting so I would like to speak to you about this opportunity.

Does this sound interesting to you and if so, what time and number can I call you on?

Thanks Antonio,

Regards,

The Recruiter

Permalink | Leave a comment »

introducing vanderlyle

Sat, 11 Jun 2011 19:39:54 -0700

I am so bored and disgusted of the flickr UI (and relative poor usability) that this afternoon I started a new side project. I called it vanderlyle¹ and it's a simple ruby app built with the excellent gems padrino & flickraw. The idea is to have just a stream of pics, the content are the shots, dear flickr, the rest is just noise and it disturbs me. Flickriver does something very similar, but again, there are way too many options, too much text around the images, I want just to see the pictures, in full screen. Right now the images are loaded on the fly, I need to write a cronjob (whenever with mongoid will do it) to store the urls locally, that should speed up the page load. Given that the flickraw api are amazingly easy to use I am also thinking of a simple script to "push" the images straight on flickr, from command line, obviously I do hate as well how iphoto and flickr uploadr handle the upload process. Good idea? Bad idea? Waste of time? I don't know yet, comments are more than welcome, if there's any interest in such an app it would be rather easy to support multiple users. [1] vanderlyle comes from here

Permalink | Leave a comment »

ETL lessons learnt

Sun, 13 Feb 2011 17:46:56 -0800

The search team at forward does a lot of ETL, data is our daily business. Recently I wrote a script that:

Collects some data from our Hadoop cluster
Calls a 3rd party API via HTTP
Pools the 3rd party API waiting for the requests to be processed
Downloads and stores locally the result of the 3rd party call

I want now to share what I learnt writing this script. Drop OOD, think functional I didn't wrote a single domain object, I used just hashes, they comes from Hive, they get used to call the external API, the xml that comes from the API becomes an hash, the data gathered from there goes straight in Mysql as CSV. I wrote the script in ruby, but I wrote few functions, the application is Stateless but stageful. There's no state but every single stage status is saved in mongo. In this way the script can fail at any point but always recover in a consistent state and start again from where it did stop. Nokogiri does crash for a bug every noun when parsing the API request page where I get the current status of the 3rd party processing. If anything can go wrong, it will I didn't care of fixing that bug or understanding why it does crash, the script will recover and try again till the parsing is successful. I don't need to be fast, cos the 3rd party server is rather slow in processing our requests. Speed is not a requirement. Consistency is. The 3rd party server went down as well quite few times, for networking issues and load. I just keep polling and let the script fail on timeout, it will start again in a 10 seconds and try again. Forget about REST, the important stuff is the rest Data is the important bit, not the way you get it. The URL provided by the 3rd party is not rest, so what? What I care about is the Data that they give to us. Being rest or not won't change my life, the value is in the content not in the transport. RTFM Read the fucking manual. I actually spent more time tuning/troubleshooting MySql (where I store the data) rather than writing the script, that deserves a full separate post, but the point is: read the manual, read the manual page till the end. Drop frameworks I use Sequel for the DB connectivity but I just use it to efficiently get the connection to the DB, I actually use plain SQL so that at least I know what's going on, when you start having tables with 80 Millions rows you better start being careful about what's going on. In conclusion, the funny bit is that web application are ETL too :-) What I wrote is valid for writing web applications too. The wikipedia page says: The typical real-life ETL cycle consists of the following execution steps: Cycle initiation Build reference data (think about populating drop downs, static data) Extract (from sources) (user input) Validate (validate user input) Transform (clean, apply business rules, check for data integrity, create aggregates or disaggregates) (business logic) Stage (load into staging tables, if used) (store) Audit reports (for example, on compliance with business rules. Also, in case of failure, helps to diagnose/repair) (analytics, audit) Publish (to target tables) Archive Clean up

Permalink | Leave a comment »

The way we design our software these days

Mon, 06 Dec 2010 11:31:22 -0800

Rory Gibson wrote a nice write up of Fred's open space talk that did happen last Monday at the 10th XPDay in London. Jamie wrote a comment on that post that deserves a reply. He says:

You won’t know it works until later… What debt are they now in? What happens when complexity grows? How do they resolve conflict? Many start ups work because debt is hidden. If peer pressure is their number 1 hr strategy they will stagnate and *not* be able to respond to changes in their business.

The comment was mainly on our philosophy, another commenter on the blog post describes it as JFDI. During my talk at the Agile Day I've got a comment that I forgot to mention in my post-talk write up. One guy on the audience said, well you guys just design your software with a Unix Philosophy. Oh man, this is so true. It's even on wikipedia. I particularly like theMike Gancarz check list of the Unix Philosophy:

Small is beautiful.
Make each program do one thing well.
Build a prototype as soon as possible.
Choose portability over efficiency.
Store data in flat text files.
Use software leverage to your advantage.
Use shell scripts to increase leverage and portability.
Avoid captive user interfaces.
Make every program a filter.

Then let me paste here also the golden rules from Eric Raymond:

Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Clarity: Clarity is better than cleverness.
Rule of Composition: Design programs to be connected to other programs.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
Rule of Simplicity: Design for simplicity; add complexity only where you must.
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
Rule of Transparency: Design for visibility to make inspection and debugging easier.
Rule of Robustness: Robustness is the child of transparency and simplicity.
Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
Rule of Least Surprise: In interface design, always do the least surprising thing.
Rule of Silence: When a program has nothing surprising to say, it should say nothing.
Rule of Repair: When you must fail, fail noisily and as soon as possible.
Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
Rule of Diversity: Distrust all claims for "one true way".
Rule of Extensibility: Design for the future, because it will be here sooner than you think.

Now believe or not but you can trash away lots of books just following these rules. Unix is, IMO, the most stable software humanity ever wrote (think about unix, linux, macos and so on) This is the way we work. We do have technical debt and we have plans to rewrite our small applications, we do that continuously, since they are small, modular, with a single responsibility (think about cat, ack, grep, etc... do) it's never a big deal.

Permalink | Leave a comment »

The way we write software these days

Sun, 28 Nov 2010 11:47:39 -0800

In my previous blog post I did write about most of the conversations and feedbacks I've got after the Italian Agile Day. In this one I want to address the software design. Rewrite preferred over Refactoring As I said during the speech we don't do that much refactoring anymore and we rather throw away the code and rewrite it from scratch. Paolo Polce said more or less something like this:

"You guys are good and write good enough code already, that's why you need less (or none) refactoring"

It's probably true, he gave me a good explanation, from a scale from zero to ten we probably write code that is already a six or a seven, so there's little need for refactoring. I've to say that we do refactor a bit, especially when a new feature comes in or when we re-open the code base after a week or more. The big difference is that if we don't like it at all anymore, if there are some code smells, if the code is resistant to change we just rewrite it. Also, one type of refactoring we do often is to reduce the codebase size. I truly believe that the main goal of refactoring should be keep the codebase small. I had a chat with Mike the other day and I found that he's doing the same thing in his team, he keeps trying to keep a part of his code base under 200 lines, even if they are adding new features. I used to be obsessed in writing small classes and small methods. Let me tell you, that's just nothing compared to writing small modular applications. Also, small classes and short methods too often imply huge codebases: it's hard to understand the intent of a system when its intent is scattered through hundred of files. Bounded Contexts We do use bounded contexts and this helps to keep the applications simple, easy to change, to rewrite when needed. It does allow us to use the right tool for the job (picking up node.js or clojure or plain ruby) for the task. Aggregation Talking with ziobrando after the conference I've realized that we implement in most of the projects aggregates, as DDD defines them:

Cluster the Entities and Value Objects into Aggregates and define boundaries around each. Choose one Entity to be the root of each Aggregate, and control all access to the objects inside the boundary through the root. Allow external objects to hold references to root only. Transient references to the internal members can be passed out for use within a single operation only.

Using noSQL helps a lot. But we implement it also with mysql. The key is to throw away all the frameworks and the patterns that dominated the market of the last 5/6 years: we don't use Sequel Models, we don't use (rails) Active Records. Most of the time we don't even write domain objects, we just use hashes. In functional programming this is definitely easier to achieve, however, in ruby you can obtain pretty good results as well. Blue Green Deployment The way we deploy our code to production has been well explained by Martin Fowler in this blog post. I admit I didn't know the name of this technique, I was just using it. Thanks again to ziobrando for suggesting me the name! DSLs preferred over Patterns As I said in the presentation I can't remember the last time in the last six month that I did introduce or use a pattern in my code. We do use tiny frameworks and DSLs rather than patterns. I think that this is the way to go. Sinatra is a brilliant dsl for writing web applications, haml is a lovely dsl for writing html, sass is a brilliant dsl to write css, capistrano, rake... It's all about dsls.

Permalink | Leave a comment »

Agiler at forward and successful at the #IAD10

Sun, 21 Nov 2010 15:52:14 -0800

I am just back in London and I am full of notes, thoughts and comments on the presentation I gave at the 7th Italian Agile Day. To start with I want to thank all the guys at Forward that created such an environment, they are in the credits at the end of the presentation, but for this blog post I want to put them first. Secondly, I want to say thank you to all the audience, I never had such a brilliant audience, the room was full and I struggled to finish the presentation cos there were something like ten hands up or more. And the conversation didn't finish there, outside and for the whole day I did talk with so many great developers who gave me so many insights that I am now struggling to remember all of them. And that's the reason of this blog post. To give you an opportunity to better understand my presentation (especially if you weren't there) and to write what I learned after it. Agile is now mainstream, with all the consequences Nusco gave us an awesome keynote, at a certain point he did quote the original paper of the waterfall methodology which sounded weirdly similar to the agile one. I did check and he was right, not only. I saw the waterfall diagrams and now I remember where I saw them the first time. Craig Larman showed them to the audience, at the Italian Java Conference. It must have been 2004 or 2005. I can't remember. I love the part on the paper where the author admits:

I believe in this concept, but the implementation described above is risky and invites failure.

The point is that since Agile is becoming mainstream it's getting polluted by certifications, labels, zealots, people reading and learning about agile but forgetting that implementation can be risky and lead to fail, same as waterfall. My presentation tried to explain that you should use just the right tools for the context you are in and avoid using the full stack just because you heard of it. As ziobrando put it on twitter: " Great insights from @javame yesterday evening. Funny to see how contexts put dogmas in perspective." emadb did tweet something like: @javame is a revolutionary, we should reflect on his good session, a lot. I have to say that it's pretty sad to be called a revolutionary in 2010, as I said before, we are just following the Agile Manifesto. So, what's going on? What happened to Agile? Why Agile these days does mean following books and papers over individuals? Why Agile in these days does mean writing tons of tests rather than delivering working software? Why Agile these days does mean strictly following a set of practises rather than responding to change? Why Agile these days does use external business analysts rather than direct customer collaboration? These are the questions to reflect on. I don't want to be a revolutionary, we just follow the manifesto, but so many teams lost the original plot these days. Agile is not dead, agile now needs to prove that he can survive in a mainstream/enterprise context without getting polluted.

Permalink | Leave a comment »

Forward Technology Blog

Wed, 03 Nov 2010 17:21:47 -0700

A couple of weeks ago Andy pushed live the Forward Technology website, I strongly recommend you to subscribe to the blogs aggregator: we do cool stuff. We like to talk about it.

Permalink | Leave a comment »

context is king

Sun, 31 Oct 2010 14:59:52 -0700

I've got quite some constructive comments (online and offline) on my blog post about reducing feedback loops. So I thought about collecting all the feedbacks here in this post to better explain my position on the topic. There are some contexts were that "methodology" I did explain, let's call it process 0.01%, won't clearly work. Now, I still don't fully understand why, but it's a fact. (many times is caused by politics and fear in dysfunctional organizations) There are enterprise contexts where there's need of tools to keep the project on track from a quality and delivery perspective. It's still questionable that the tool will fix the problem. I think that spending a month training/staffing the team most of the times will pay back more than installing (buying) CI server, tracking tool, estimating, planning, etc. A common mistake in those enterprise contexts is that the enterprise manager will always ask for perfection. I sow so many good websites done by startups with little bugs still providing an excellent service. Foursquare went down, people are still using it. Facebook has many bugs but it's a success story. My understanding is that it's more important to go live with an enough good system most of the times rather than having a perfect system frozen on your source code repository. If I would have to work for a Nuclear Power Station control system or if I would have to write the software to control a surgery robot I would probably write lots and lots of tests or I will maybe, use a language that supports formal methods. In the hippie funky world of the web small mistakes are allowed, building software for space rockets would be fun as well I guess, but that's another context. The sad thing is that lots and lost of former startups with the help of shit consultancy companies such as IBM, Capgemini, Accenture; to mention few, became enterprise-like. So my message is, think as a startup as much as you can, always, it's more fun for your employees and you will be faster to market.

Permalink | Leave a comment »

wanna go fast? reduce your feedback loops

Fri, 29 Oct 2010 11:15:45 -0700

I did work for years using the full XP/agile stack on a daily basis, after all that experience I can now finally judge when to use a methodology and when it's not the case. In the last years I had more than once the impression that all the various tools that are supposed to reduce the lead time where actually slowing me down. Now I am lucky enough to work in an environment that doesn't force me to use any particular methodology or technology. So, how is that possible that here we go live in weeks and not in months? What happened? No CI. Yeah, we don't use CI. How does it work? - Hire good developers, most of the times they will not commit&push crap - Keep your application simple, prefer having lots of small applications collaborating rather than having a monolithic huge application - Deploy live rather than on CI, that's where the system really runs, not on CI, that's where you will really understand if it's broken or not - Integrate often. The fact that the CI runs for every commit doesn't mean that you are integrating. Pushing live your changes is real integration - Failover on a previous version of the code/automatic rollback on the live system if the deploy breaks the application Test but not that much. Profanity? - Hire good developers, most of the times they will write decent code without a test - Hire good developers, most of the times they will test themselves the code they wrote - Keep your code simple, as simple as possible. If a method is 3/5 lines of code and your code base is small it will be simple enough to change/maintain/evolve - Write a test when you start feeling uncomfortable, most of the times a http://en.wikipedia.org/wiki/Read-eval-print_loop">REPL will be actually good enough to prove you are writing your code in the right way Ok, what about maintainability and refactoring? Let me tell you, refactoring is overrated. Maintainability is overrated. Write your application as prescribed above, use some dynamic language that will help you going faster and as soon as you will be fast enough you will realize that if you are not happy with your code you can actually trash it all out and write it again from scratch, it will take you less time. I've seen this working here, I am not talking bullshit. I've seen in the past projects that should have taken weeks taking months with huge amount of wasted time spent fixing the build, fixing the selenium tests, maintaining hundreds of tests, writing non sense mocks tests, writing non sense tests. You may have embraced change, now it's time to embrace courage, be a fearless dev.

Permalink | Leave a comment »

think different, think nosql

Fri, 29 Oct 2010 09:41:50 -0700

I just came across this post from the high scalability blog. I just want to say what the nosql movement gave me back. We just finished writing a new application which visualizes pseudo realtime analytics information, it's a web application, most of our analytics data is stored in hadoop, for this web app we decided to use mysql. Hive wouldn't be appropriate given its response time to execute a query (and lots of map reduce indeed), so we do get the data from hdfs on an hourly basis and store it in mysql. After a quick spike on hbase we picked up mysql because we needed group by semantics, but at the same time we started using mysql in a different way, we don't have any relations, we don't do joins, we store our data as in a big table. So basically we use the best of both words: no relations but sql. This db grows pretty fast, the application has been running fully operational live for less than a day now and the total db size (two tables) it's 48GB. Then, for once, I came out with a good idea, we split the big table in a dozen of other smaller tables, basically the analytics source regions, what before was a column and a where clause in our queries became just a suffix of the original table. I've been strongly inspired by the way hadoop manages partitions. In conclusion that's what the noSQL movement gave me back: he made me think differently to common data problems.

Permalink | Leave a comment »

10 good reasons to switch to Ruby

Fri, 03 Sep 2010 14:51:14 -0700

I've been working for three months with ruby now, I feel like I need to write down a list of the top 10 things I loved about the language.

Writing ruby code is a pleasure

Before switching to ruby I did lost my interest in writing software, I was totally bored of writing lots of bolier template patterns stuff, lots of lines of code, maintaining huge deployment scripts, build files. With ruby I rediscovered the passion for writing software, the syntax is just awesome and very rich: tasks that may require a lot of ugly silly code in java/c# can be written in a very expressive form in a line.

Deployment

Capistrano is just magically wonderful, it gives you for free so many features that are missed in the not ruby world, you can be up and running with a capistrano deploy script in minutes, deploy is safe, predictable, repeatable.

Available libraries and dependency management

Gems are just the best system for dependency management I ever seen, and the gems that are generally popular for ruby are definitely powerful.

Write less, do more

With ruby you write less code, less code means less maintenance, code more readable, less tests to write, less tests to maintain, you will go live quicker.

Quicker development cycle

An obvious consequence of all the other points listed in this blog post but also, since the language is dynamic you won't wait for compilation or to reload the application in your server.

No xml, really no xml

No more xml, what a win

No (n)ant

There must have been a day where ant has been good but I can't remember when it was. Ant scripts are a pain to maintain and write, it's one of the biggest fail of the Apache Foundation (Maven is another big fail)

Microframeworks

Another big difference with the usual C#/Java world is that you don't get huge beasts frameworks like what it is Spring now, gems (a part from Rails) are usually quite small and they just do the job they are supposed to do.

To mention few: Sinatra, Haml, mongo...

It's dynamic

See this quite long blog post.

You'll be faster, it's guaranteed

Permalink | Leave a comment »

I prefer small monitors over big monitors

Fri, 03 Sep 2010 14:05:12 -0700

Having big monitors seems like a must have these days in software development. I never liked them, I remember having this conversation with Felix and Graham years ago, I didn't change my opinion, I am actually writing a blog post to reinforce my believes. Big is bad Big is bad because a big monitor is a wall between you and your team, with a couple of 21+ monitors in front of you I bet you can't neither see anymore your colleagues face, it blocks conversations. Big will tempt you to write less readable code, longer, larger code base with more space on the screen you will be tempted in doing it. Small is awesome We all work here with mac laptops, I am pretty happy with a 12" mac, I don't miss a huge monitor, I can move my mac around the office, I can see the face of my colleagues. Some tools are not helping you: tools such as visual studio, eclipse and intellij require a lot of not so necessary space on the screen, I admit that with those tools it would be hard; using textmate, emacs or vim you will be fine. Small is eco-friendly, you can't argue with this one. Where big is still good As information radiator or for your home tv, that's it.

Permalink | Leave a comment »

Java vs Ruby vs Clojoure

Fri, 06 Aug 2010 14:38:17 -0700

Java: Time spent to think on what to write: 0 Time spent in writing: 60 Clojure: Time spent to think on what to write: 30 Time spent in writing: 5 (if you're good with brackets) Ruby: Time spent to think on what to write: 5 Time spent in writing: 5

Permalink | Leave a comment »

links for 2010-06-22

Tue, 22 Jun 2010 08:01:13 -0700

RubyAMP

(tags: ruby textmate autocomplete)
RVM and Textmate - Mostly Sane

(tags: ruby textmate rvm)

Permalink | Leave a comment »

Last day at #Thoughtworks

Fri, 11 Jun 2010 13:11:13 -0700

Today is my last day at ThoughtWorks, it has been an intense, challenging year. Monday I will start a new adventure at Forward, I am excited about this as much as I was to join ThoughtWorks the first time in 2006. I will work with some very talented former colleagues and friends like Mike & Pingles and many others great guys, in a very agile/lean company, I will finally learn Ruby & Clojure and practise continuous deployment... There's enough good stuff to keep me busy and happy for a while!

Permalink | Leave a comment »

Change the company culture first

Tue, 25 May 2010 06:18:36 -0700

I've been involved in quite some agile consulting gigs in my work life. There's one lesson I want to share: if you want to change an organization you have to change their company culture first. If you are trying to employ a consultancy firm try to get ready your people to start with, avoid wasting money making sure that your employees are ready to embrace the change. Make sure that you communicated well and straight that things are gonna change now. If you are a consultant, make sure that you will have enough slack on the project to work on the company culture, plan, discuss with the client when and how that work will be performed. Otherwise change won't work: people will work in micro waterfall iterations, they will use continuous feedbacks to drive others people carriers, they will still micro manage their teams, they will eventually fail and all their effort to "change" and your effort to make them "a better" place to work for will vanish without evident benefits.

Permalink | Leave a comment »