Recent blog posts
- If I could...
- A workflow for Distributed Version Control that uses lightweight branches
- Microsoft Beware: You don't own the mobile market
- Why Ubuntu Rocks
- Agile Development in Open Source
- Microsoft's Free and Intriguing CMS
- Cheap Arm9 Embedded Linux Platform
- How do you syndicate navigation?
- Fixing Eclipse after the Firefox 3 rc1 update in Ubuntu 8.04
- Amazon won't stop offering me watches
Bearfruit
Designing bfr coding, or coding bfr designing.
My english is not as good as I would like to so I’ll be very brief: I’ve explored both ways and certainly there are even and odds in both of them. Doing ‘the artwork’ before the ‘engineering work’ may deliver a good looking app, but perharps code will follow the form, and not the function; and doing the inverse process, will increase the ‘impedance mismatch factor’ between business logic and interfaces.
So my generic solution is: Work this two aspects independently and take your time to implement some flavor of ‘veiw helpers’ to short the distance between logic and interface. It works nice for me.
It has a second advantage: you can develop a method, which can be a very valuable tool for success replication.
That’s my point of view.
Great Blog!
Américo Patetta, Montevideo, Uruguay.