tag:blogger.com,1999:blog-91156446058333841382024-03-13T21:16:17.380+01:00X de XavierUnos y ceros. A veces, en el orden adecuado.-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-9115644605833384138.post-68501944382327851562007-11-30T00:17:00.000+01:002007-11-30T01:38:00.131+01:00Yay! Barcelona Python Meetups are here!Back from the first <a href="http://python.meetup.com/185/">Barcelona Python Meetup Group</a> event. The event was good, with two talks:<br /><ul><li><a href="http://www.linkedin.com/pub/0/a5/280">Maik Röder</a>, based on the <a href="http://tarekziade.wordpress.com/2007/09/24/eight-tips-to-start-with-python/">Eight tips to start with Python</a>. Maik added an additional tip (use <a href="http://divmod.org/trac/wiki/DivmodPyflakes">PyFlakes</a>, a faster PyChecker) and asked the attendants for our own tips: <a href="http://ipython.scipy.org/moin/">IPython</a> (a great shell that I should be using again) proved to have many fans! I mentioned my love for <a href="http://docs.python.org/lib/module-ctypes.html">ctypes</a>.</li><li><a href="http://jardigrec.eu/">Ramon Navarro Bosch</a>, on Design Patterns in Python. Ramon recommended us <a href="http://www.aleax.it/">Alex Martelli</a>'s <a href="http://video.google.com/videoplay?docid=-3035093035748181693">Google TechTalk video</a> on the topic.<br /></li></ul>If the event was good, the post-event (beers, croquetas and bravas) with Maik was great and I'm bringing home lots of food for thought. Most of the talk was about <a href="http://www.openplans.org/projects/funittest/project-home">Funittest (<span style="font-style: italic;">Making it easy to go from use case to functional test</span>)</a>. Maik uses daily a high level Test Driven Development flow:<br /><ul><li>write the functional test, to get aligned with the user's needs/customer value,<br /></li><li>write unit test, that can be driven faster and focus in the approapiate level of abstraction</li><li>write the code</li></ul>My impression is that his ideas have lots of commonalities with <a href="http://fit.c2.com/">Fit</a> and <a href="http://fitnesse.org/">Fitness</a>, and the story-based-testing that they advocate. Maik said that Funnitest's theoretical foundation can be grasped in <a href="http://blogs.msdn.com/micahel/archive/2005/05/04/FromAccountantToScientist.aspx">The Braidy Tester articles</a>; I'm adding them to my to-read list...<br /><br />Beyond functional testing, the programmer's flow, the business-technical gap, Barcelona, Sevilla, tele-working... an intriguing an promising idea: the I-told-you-that-this-was-a-wrong-decision year-end bonus.-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com0tag:blogger.com,1999:blog-9115644605833384138.post-40448192226429035622006-12-28T02:02:00.000+01:002006-12-28T02:05:34.044+01:00Mary Poppendieck: Competing On The Basis Of SpeedI watched <a href="http://www.poppendieck.com/">Mary Poppendieck</a>'s talk at Google: <a href="http://video.google.com/videoplay?hl=en&docid=-5105910452864283694">Competing On The Basis Of Speed</a>. It is a good talk, but it does not compare well to Mary and Tom's most excellent <span style="font-style: italic; font-weight: bold;">Lean Software Development: An Agile Toolkit</span> <span style="font-size:85%;">(<a href="http://www.amazon.com/gp/redirect.html?ie=UTF8&location=http%3A%2F%2Fwww.amazon.com%2Fdp%2F0321150783&tag=xdexa-20&linkCode=ur2&camp=1789&creative=9325">amazon.com</a> <a href="http://www.amazon.co.uk/gp/redirect.html?ie=UTF8&location=http%3A%2F%2Fwww.amazon.co.uk%2Fdp%2F0321150783&tag=xdexavie-21&linkCode=ur2&camp=1634&creative=6738">amazon.co.uk</a> <a href="http://safari.oreilly.com/0321150783">safari</a>)</span>.<br /><br /><embed style="width: 400px; height: 326px;" id="VideoPlayback" type="application/x-shockwave-flash" src="http://video.google.com/googleplayer.swf?docId=-5105910452864283694&hl=en" flashvars=""></embed><br /><br />I took some messy notes, way too powerpointish :-(. My advice: go for the book<span style="font-weight: bold;"></span>.<br /><br /><span style="font-weight: bold;"><span style="font-size:130%;">Intro</span><br /></span><ul><li>Fast companies (e.g. Dell, Toyota, Google)</li><ul><li>competitive advantage<br /></li><li>lower costs<br /></li><li>large barrier to entry for competition<br /></li></ul><li>Speed's enemy: complexity</li><li>3 faces of complexity [1]:</li><ul><li><span style="font-weight: bold; color: rgb(255, 0, 0);"> waste</span>: anything that depletes resources without <strong style="font-weight: normal;">adding customer value<br /><span style="font-weight: bold; color: rgb(51, 204, 0);">keep it simple</span><br /></strong></li><li><span style="font-weight: bold; color: rgb(255, 0, 0);"> inconsistency</span>: anything uneven, unbalanced, irregular<br /><span style="font-weight: bold; color: rgb(51, 204, 0);">make it flawless</span><br /></li><li><span style="font-weight: bold; color: rgb(255, 0, 0);"> overload</span>: excessive burden<br /><span style="font-weight: bold; color: rgb(51, 204, 0);">let it flow</span><br /></li></ul></ul><span style="font-weight: bold;font-size:130%;" >Keep it simple</span> (<span style="font-size:85%;"><a href="http://video.google.com/videoplay?hl=en&docid=-5105910452864283694#5m45s">video 5m45s</a></span>)<br /><ul><li>Common infrastructure:</li><ul><li>Architecture</li><li>Conventions: naming, coding, security, logging, ui, configuration management...</li><li>Tools</li></ul><li>Refactoring to keep simplifying</li><li> Sustainable simplicity: <span style="font-weight: bold;">change tolerance</span> (<a href="http://video.google.com/videoplay?hl=en&docid=-5105910452864283694#7m52s"><span style="font-size:85%;">video 7m52s</span></a>)</li><ul><li>60%-80% of code is written after the first release</li><li>the development process has to anticipate change</li><li><span style="font-weight: bold;">decide as late as possible</span>, when you have more info<br /></li><ul><li> make decissions reversible whenever possible</li></ul><ul><li>make irreversible decissions at the <span style="font-weight: bold;">last responsible moment</span></li><li><span style="font-weight: bold;">set-based development</span>: explore the whole solution space at once (Toyota worked on 10 motors at once for the Prius). Keep multiple options, and one has to work at the last responsible moment.</li><li>paradox: these redundant solutions are not waste</li></ul></ul></ul><span style="font-weight: bold;font-size:130%;" >Make it flawless</span><span style="font-size:130%;"> </span>(<a href="http://video.google.com/videoplay?hl=en&docid=-5105910452864283694#18m28s"><span style="font-size:85%;">video 18m28s</span></a>)<br /><ul><li>2 kinds of inspection</li><ul><li>to find defects -> waste</li><li> to prevent defects -> essential</li></ul><li>Mistake-proof every step: detect defects the moment they ocurr</li><ul><li> don't track defects on a list: find them and fix them</li></ul><ul><li> test first, automated test suites</li></ul><li>Role of testing (<a href="http://video.google.com/videoplay?hl=en&docid=-5105910452864283694#21m55s"><span style="font-size:85%;">video 21m55s</span></a>)</li><ul><li> manufacturing:<br /></li><ul><li>a quality process brings quality into the products (unlike in software development traditional view)<br /></li></ul><ul><li> finding process in verifcation -> you have a defective process</li></ul><li> focus on preventing defects. Cannot be at the end of development, adding waste in the form of test-fix churn. It has to be integrated into the development process.</li></ul><li>4 kinds of testing</li><ul><li>unit testing: developer intend. Automate them.<br /></li><li>acceptance/regression testing: business intend. Automate them.</li><li>exploratory + usability testing. Manual by definition.</li><li> property (response, security, scaling....) testing. Take advanteg of tools.</li></ul><li>Technical debt (<a href="http://video.google.com/videoplay?hl=en&docid=-5105910452864283694#26m55s"><span style="font-size:85%;">video 26m55s</span></a>)</li><ul><li> anything that makes code difficult to change</li><li> the longer you acquire debt the worse it gets</li><ul><li>cost ofcomplexty is exponential</li><li> regression deficit: more features, longer testing, until it dominates the release cycle</li><li> unsync code branches: the longer apart, the longer it will take to merge</li></ul></ul><li>Build Quality in (<a href="http://video.google.com/videoplay?hl=en&docid=-5105910452864283694#33m17s"><span style="font-size:85%;">video 33m17s</span></a>)</li><ul><li>configuration management, one click build, automated testing, continuous integration, frequent depoyment</li><li>nested synchronization: test as early and often as possible<br /></li><ul><li> every check in - unit tests</li><li> evrery day - regression test harness</li><li> every week - operations test harness</li><li> every iteration - deployment ready code</li></ul></ul></ul><span style="font-weight: bold;"><span style="font-size:130%;">Let it flow</span> </span>(<a href="http://video.google.com/videoplay?hl=en&docid=-5105910452864283694#43m40s"><span style="font-size:85%;">video 43m40s</span></a>)<ul><li> cycle time : customer problem to customer solution.</li><ul><li> software development cycle time: requests to deployment</li></ul><li style="font-weight: bold;"> process capability: wether you have or not a reliable and repetible cycle time for a given set of problems<br /></li><li> delays: hint of opportunities for cost/waste reduction</li><li> queuing theory</li><ul><li> total cycle time = number of things in process / average completion rate </li><li> shorter cycle time: ability to add new features</li><li>small tasks and slack decrease the total cycle time<br /></li><ul><li> utilization paradox (<a href="http://video.google.com/videoplay?hl=en&docid=-5105910452864283694#48m23s">48m23s</a>) - not having slack increases the cycle time. This is one of the ideas behind 3M's 15% of free time rule (Google's 20% precedent). Organizations targeting 100% utilization are meassuring the wrong thing.<br /></li></ul></ul><li>Keep a <strong>honest queue</strong>/to-do list: short and in the realm of the things that can be reasonably expected to be done; no useful purpose for long queues</li><li>Stablish a regular cadence, limit work to capacity, minimize the size of things in the process.<br /></li></ul><span style="font-size:130%;"><span style="font-weight: bold;">System meassurements</span></span><br /><ul><li> cycle time (lean classic) - process capability</li><li> business case (are you making money) - business return</li><li> customer satisfaction <span>—</span> sustainability</li><ul><li> net promoter score [2]</li></ul></ul><br />[1] From Matthew May's <span style="font-style: italic;">The Elegant Solution: Toyota's Formula for Mastering Innovation</span> (<span style="font-size:85%;"><a href="http://www.amazon.com/gp/redirect.html?ie=UTF8&location=http%3A%2F%2Fwww.amazon.com%2Fdp%2F0743290178&amp;amp;amp;amp;amp;amp;tag=xdexa-20&linkCode=ur2&camp=1789&creative=9325">amazon.com</a> <a href="http://www.amazon.co.uk/gp/redirect.html?ie=UTF8&location=http%3A%2F%2Fwww.amazon.co.uk%2Fdp%2F0743290178&tag=xdexavie-21&linkCode=ur2&camp=1634&creative=6738">amazon.co.uk</a></span>)<br />[2] Frederick F. Reichheld's <span style="font-style: italic;">The Ultimate Question </span>(<span style="font-size:85%;"><a href="http://www.amazon.com/gp/redirect.html?ie=UTF8&location=http%3A%2F%2Fwww.amazon.com%2Fdp%2F1591397839&tag=xdexa-20&linkCode=ur2&camp=1789&creative=9325">amazon.com</a> <a href="http://www.amazon.co.uk/gp/redirect.html?ie=UTF8&location=http%3A%2F%2Fwww.amazon.co.uk%2Fdp%2F1591397839&tag=xdexavie-21&linkCode=ur2&camp=1634&creative=6738">amazon.co.uk</a></span>)-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com0tag:blogger.com,1999:blog-9115644605833384138.post-24551017959984335482006-12-26T01:47:00.000+01:002006-12-28T00:00:59.562+01:00Google Tech Taks (engEDU videos)You *have to* keep an eye on Google's TechTalks. I have not seen an obvious link, so here it is a <a href="http://video.google.com/videosearch?q=Google+engEDU&so=1&start=0">search</a> and a <a href="http://video.google.com/videofeed?type=search&q=Google+engEDU&so=1&output=rss">feed on that search</a> (better, since it provides longer descriptions). They are mostly about computer science, but the range of topics is quite broad.<br /><br />It is great that they are choosing to publish all these terrific talks they host.<br /><br /><span style="font-weight: bold;">Update:</span> from <a href="http://video.google.com/googleplex.html">http://video.google.com/googleplex.html</a><br /><blockquote>Google TechTalks are designed to disseminate a wide spectrum of views on topics ranging from Current Affairs, Science, Engineering, Humanities, Business, Law, Entertainment, Medicine, and the Arts.</blockquote>I also learned about the <span style="font-weight: bold;">Authors@Google</span> series:<br /><blockquote>Authors@Google is a speaker series where thought-provoking, Zeitgeist-making, trend-setting authors come to the Googleplex to read from their works and share their thoughts with us. The following authors have agreed to release their talks to the world on Google Video.</blockquote>-Xvhttp://www.blogger.com/profile/12954073038736466058noreply@blogger.com0