Hugo Corbucci's Bloghttp://blog.hugocorbucci.com/feed.xml2017-01-28T20:06:46.978000ZWerkzeugThe Unbroken Line of the Moon - by Johanne Hildebranthttp://blog.hugocorbucci.com/post/the-unbroken-line-of-the-moon-by-johanne-hildebrant2017-01-28T20:06:46.978000Z2017-05-23T23:48:00ZHugo Corbucci<div>Another <a href="https://smile.amazon.com/Unbroken-Line-Moon-Valhalla-Book-ebook/dp/B01D2ZNXWQ">Kindle First book</a> that I got. This historical nordic fantasy brings us into the life of Sigrid Tostedotter, daughter of Skagul Toste who is the chieftain of a nordic clan called Scylfing. At the start of the book, she’s a young woman with a deep faith in the Nordic gods who has her first periods and foresees a change in her life.</div>
<div>In parallel to her story, we meet Sweyn, a Jómsvíking adopted by Parna who is their chieftain. The Jómsvíkings are mercenary soldiers known for their strength and combat abilities. Sweyn is sixteen years old which, at that time, means a young man ready for battle. We discover early on that Sweyn’s real father is Harald Bluetooth, kind of Denmark.</div>
<div>As we follow how the stories of Sigrid and Sweyn intertwine, we learn about the old Nordic religion, its gods and rituals. Both of them being sworn to the old religion are at odds with Harald’s imposed following of Christianity with the only God and a worship of the cross. Religion and politics mix together with battles, rapes, murders and betrayal in chapters that some times are captivating and some times very tiring and long.</div>
<div><br/></div>
<div>The book has enough in it to have kept me reading even if, in the middle, it got me a bit tired. Both the sex (rape or not) and the violent scenes are not widely described so even if the reader understands fully what is going on (or has happened), there isn’t much dwelling or details about it. I wouldn’t necessarily recommend it as it doesn’t fit my idea of an entertaining book and more of a very dry and unenthusiastic and unromantic view of that time and the lives people had then. A certain flare of Game of Thrones without as carefully designed characters and complex views of their minds.</div>
<div><br/></div>
The King of Taskim Square - by Emrah Serbeshttp://blog.hugocorbucci.com/post/the-king-of-taskim-square-by-emrah-serbes2017-01-22T22:33:25.435000Z2017-03-28T15:15:00ZHugo Corbucci<div><a href="https://smile.amazon.com/King-Taksim-Square-Emrah-Serbes/dp/1503951618">This book</a> is quite different from what I usually read. It is written from the point of view of a Turkish teenager, Çağlar, who starts the book explaining to the reader his admiration for his little sister, Çiğdem. As we start our journey with Çağlar, Çiğdem is about to go on stage to perform as a young Michael Jackson cover dancer in a competition to go on television. As we keep going during the book, we learn more about Çağlar’s family (his mother and uncle mostly) and his life (his studies, his friends) and how much he tries to help his little sister to anything. As the book evolves, the way Çağlar describes his surroundings and life changes and we discover that a lot of what he describes in the book is a very biased point of view with all the flaws that a teenager view of the world might have.</div>
<div><br/></div>
<div><div>The book touches on family, relationships, friendship, nepotism and, finally, politics and, later but also importantly, the political uprises that took place in Turkey in May 2013. In an attempt to immerse the reader in the narrator’s life and thoughts, the book goes a bit everywhere. It jumps from the work at the hotel to thoughts about an ex-girlfriend or about the policies put in place by Çağlar’s uncle who is the mayor of their city.<br/></div>
<div><br/></div>
<div>To me, the book was hard to read. I had to push myself through more than half of the book having a hard time to keep focused on the ramblings of a teenager’s point of view on his limited world view. It mixes historical political events with fiction in a way that did not help me enter either of the worlds. I would not recommend it unless you are looking for something VERY different then your average contemporary western fiction.</div></div><div/><div><br/></div>
The Einstein Prophecy - by Robert Masellohttp://blog.hugocorbucci.com/post/the-einstein-prophecy-by-robert-masello2017-01-22T22:33:24.622000Z2017-02-28T19:58:00ZHugo Corbucci<div>Another Kindle First <a href="https://www.amazon.com/Einstein-Prophecy-Robert-Masello/dp/1477829407">book</a> fiction that deals with super natural. The Einstein prophecy starts at the end of World War II west of Strasbourg with a team of allied soldiers in quest for some items that the nazi’s had stolen a few years back. In this case, our hero, Lucas Athan, is looking specifically for some ossuary that Hitler seemed to have a high esteem for. With a few hints of something not very normal going on, Lucas finds the ossuary but it comes at a cost. Fast forward a few months, Lucas is now a professor at Princeton where he shares the campus with Albert Einstein.</div>
<div>By chapter 3, a quick shift in the story introduces to us our other hero, Simone Rashid, a strong Egyptian woman holding the chairman office for the National Affairs Department at the University of Cairo. She’s on a red cross ship bringing her and her father to the U.S. And she knows more than others about the cargo they’re bringing along with the injured ones.</div>
<div><br/></div>
<div>As the book moves along, we see the story of Lucas and Simone intertwine. Together they’ll discover the mysteries of the ossuary and a few other events that escape our understanding of physics and rationality while also learning about carbon-14 technology and some wide and strong alliances of great mathematical minds of that time.</div>
<div><br/></div>
<div>The book flows very well with a lot of good action scenes and some romance. The super natural events are nicely built around a mythical story on demons and Egyptian history. To me It was a fun read that I would recommend if you’re hoping for some entertainment touching Egyptian mythology and some history around the work performance by scientists at the end of the second great war.</div>
<div><br/></div>
Here & There - by Joshua V. Scherhttp://blog.hugocorbucci.com/post/here-there-by-joshua-v-scher2017-01-22T22:33:24.425000Z2017-01-31T06:42:00ZHugo Corbucci<div>This book starts off as a letter from Daniel Brand to the author of the book, Josh. In that letter, Daniel apologizes for such a weird package but he didn't have any other way to get in touch or expose such unbelievable story. It's about his mother's work. As a psychologist, she developed this new technique called Psynar® that helps her understand victims or perpetrators and uncover truths otherwise hidden. Her last assignment is that surrounding a, so called, Reidier's test sponsored by DARPA that didn't result in exactly what they were hoping for. Her research is the text that follows in around 30 chapters.</div>
<div><br/></div>
<div>In them, we learn about Reidier's history. How his family got formed, how is work got shaped. Where he went and what he did. Who his friends were and how much devotion he poured into his profession. As a researcher and professor in physics, Riedier works around quantum physics and how they can change the world as we know it drastically. The book alternates between a number of narrators including Reidier's own notes or recordings, Daniel's mother (Hilary) notes, Daniel's own notes around his mother's notes and Eve (Riedier's partner) journals. They all intertwine throughout the book without much structure to keep the reader in a sense of multilevel analysis.</div>
<div><br/></div>
<div>The story mixes some mathematics and physics explanations from Riedier to Eve that help the author explain some concepts to the reader. Some of them (like public/private key encryption) are pretty good. But quickly, the book gets very long and some of the mysteries are fairly predictable. There are attempts to make it more analytical and critical to our human minds but it never got to me. I wouldn't recommend it. The author is apparently trying to make it into the movie industry and it shows. The book could be turned into a fun movie where not as many clues of the outcome and more emphasys on the highlights would work to keep the audience tuned. As its current novel version, it is hard to stay focused and I needed extra effort to finish the long chapters.</div>
<div><br/></div>
Javascript: The Good Parts - by Douglas Crockfordhttp://blog.hugocorbucci.com/post/javascript-the-good-parts-by-douglas-crockford2017-01-22T22:33:24.484000Z2017-01-17T19:06:00ZHugo Corbucci<p>This now <a href="https://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742">traditional book</a> about Javascript is the basis for a lot of what you’ll find in the most common javascript libraries out there before (and some after) EmacsScript 6. The book starts off defining why it is important to understand Javascript and take the best it has to offer to work with. As we move along, the author explains the grammar of the parts he considers to be the good parts of Javascript along with all keywords, literals (such as numbers and strings) and statements.</p>
<p>He moves on to explain how Javascript prototypal objects are different than the more common classical objects from Java and Smalltalk. An object in Javascript is simply a data structure that associates names to values. All objects have an associated prototype which is simply another object. The magic is that Javascript defines an implicit delegation between an object and it’s prototype. This means that if you try to access a given value on an object and it is not present, Javascript will try to access that value on the prototype of the original object. This happens recursively until you reach <code>Object.prototype</code> which will return <code>undefined</code>. Note that, a consequence of this is that you can augment any object in Javascript with functions by simply adding them to <code>Object.prototype</code>. And herein lie the same dangers of open classes that Ruby has. If you find yourself with multiple libraries that increment <code>Object.prototype</code> (or any other prototype for that matter) with similarly named functions, it is hard to know which implementation will apply to your program. This is one of the reasons why it is discouraged to increment Javascript prototypes that way unless they are your own.</p>
<p>Along those lines, Crockford explains that Javascript functions are also objects. But rather than having <code>Object.prototype</code> as their parent prototype, they use <code>Function.prototype</code> (which is itself linked to <code>Object.prototype</code>). As a consequence of being an object, functions can be attributed to variables, to arrays, passed as arguments to other functions or returned. This quirckiness in functions is the use of <code>this</code>. For functions embeded in an object, <code>this</code> refers to the object being a way to access the object's properties. Unfortunatelly, for functions nested in those functions, <code>this</code> does not bind to that same object. The workaround is to use a variable with another name (conventionally <code>that</code>) to trap the value of <code>this</code> in the embeded function. One of the many sources of issues in Javascript. A note from Crockford is that although Javascript functions can be recursive, there is not optimization regarding tail recursion so developers have to handle that manually.</p>
<p>Javascript also provides a few flow control keywords. <code>return</code> is the most known one and simply exits the current function returning whichever value was provided. If <code>return</code> is never invoked in a function, <code>undefined</code> is returned. Unless the function was invoked with <code>new</code> (we call those functions constructors) in which case, <code>this</code> (the object created) is returned. <code>throw</code> is another one and serves as an exception flow like Java or Ruby have. <code>throw</code> takes an object that is expected to have <code>name</code> and <code>message</code> attributes and simply interrupts the execution of all functions in the stack until there is a <code>catch</code> clause after a <code>try</code> statement.</p>
<p>Scoping is another big source of mistakes since Javascript does not offer block scoping even if the syntax makes it look like it does. This means that scopes are bound to functions or their encasing objects. As a consequence, newer Javascript programs tend to have anonymous functions that execute immediately return objects with embeded functions as a way to ensure encapsulation of variables.</p>
<p>There is a whole section of the book about how to Javascript can handle inheritance and a more 'classical' (from <em>classes</em> not from <em>classic</em>) approach. History has shown that we're better off ignoring that all together when working in Javascript and rather stick with what Crockford calls "differencial inheritance". The idea is to simply create an object based on another (with a regular prototypal <code>Object.create</code>) and then assign functions (or values) to the properties that the original object had.</p>
<p>Arrays are another one of those sources of issues in Javascript. Part of it is because an array is simply an object (that has <code>Array.prototype</code>) which has properties that are numbered from 0 to the length of that array. Arrays get (from their prototype) a <code>length</code> function which returns the last (numerical) property in the object plus one. There is no way to allocate a specific amount of memory for an Array in Javascript except for simply filling it with the data you want.</p>
<p>Crockford goes on afterwards explaining regular expressions in Javascript. They're mostly similar do perl's regular expressions and defined with <code>/</code>s. There are capturing and non-capturing group as well as positive and negative lookahead. Regular expressions accept 3 modifiers (after the expression itself) that are <code>g</code> for global (for multiple matches), <code>i</code> for [case] insensitive, <code>m</code> for multiline. If a regular expression is dynamic (and not hard-coded), one can use the <code>RegExp</code> constructor to build the expression dynamically.</p>
<p>Chapter 8 handles methods which is simply a description of the functions associated to multiple prototypes that Crockford considers useful. The examples and explanations are sometimes still better than oficial documentation so take a look if you're curious but no need to read everything in detail. Chapter 9 approaches style and essentially how to format Javascript code. By now, most editors already handle this for you and linters are available to inspect and verify your code. Skip this chapter and use a linter and you'll be fine. Finally Chapter 10 summarizes what Crockford identifies as a subset of Javascript (mostly described in the book) that make it beautiful (in his opinion). If you're only reading one chapter, read this one and refer to the others to consult specific information.</p>
<p>The book ends with a few appendixes. The first one (A - the awful parts) is great. It pretty much summarizes the most common mistakes or problems encountered in Javascript programs around. Read it. It's worth it and it'll show you why some of the weird behaviors in Javascript are there. The second one (B - the bad parts) is still very interesting but reveals slightly more obvious issues or mistakes. The third one (C - JSLint) describes the work Crockford put together for the first Javascript linter around. By now, it is not that useful anymore. The fourth one (D - Syntax diagrams) shows diagrams that describe how to write/parse the language. Not that useful unless you want to play around and write weird Javascript. Finally, the last one describes JSON or Javascript Object Notation which, by now, if you don't know about, you probably should read before even starting this book. Crockford also provides an implementation of a JSON parser in Javascript. Interesting even if no longer very useful as there are so many out there.</p>
<p>Overall, the book is still relevant if you're anywhere near Javascript (which is anywhere near HTML) and quite short to deserve the full read. If you are in a super hurry, get Chapter 10 along with Appendix A and B if you already know some Javascript. Use the rest of the book as references. If you know nothing, just read the whole book. You'll be better off. I really liked it and it was definitively worth my time.</p>The Big Fear - by Andrew Casehttp://blog.hugocorbucci.com/post/the-big-fear-by-andrew-case2016-09-04T01:00:31.999000Z2016-11-05T00:06:00ZHugo Corbucci<div>This <a href="https://www.amazon.com/Big-Fear-Hollow-City-ebook/dp/B011QZWCVW">book</a> is the first of the Hollow City series brings us to New York and a story that starts with Ralph Mulino, a NYPD detective in the Organized Crime Control Bureau (OCCB). Detective Mulino is investigating an alarm on a ship when he finds the body of a dead man and confronts another one hidding in the shadows. After some tense chasing in a huge boat loaded with containers, Mulino is forced to shoot his target after noticing he had a gun. Unfortunately for detective Mulino, once he gets close to the body, he discovers the dead man is a police officer.</div>
<div><br/></div>
<div>The next few chapters introduce us to two more important characters, Christine Davenport and Leonard Mitchell. Christine is Leonard’s boss at the Department to Investigate Misconduct and Corruption (DIMAC) and, as expected, they will have to handle Mulino’s case since most cop shootings fall in their lap anyway. Even more so when both ends of the gun are cops. Unfortunately for Leonard, Christine surprises him by quitting before the case reaches them and promotes him to take over her place.</div>
<div><br/></div>
<div>From then on, the story takes the reader to follow either those characters in each chapter or a few others that we’ll meet along the way in a sordid business involving corrupted cops, financial crimes and plain old murders. The end is not as surprising as it could be but there are still some surprises awaiting the reader along the way. All in all, a decent police/financial mystery book. It goes a bit everywhere with the characters along the line so it gets hard to get too into it but still entertaining.</div>
Darkness Brutal - by Rachel A. Markshttp://blog.hugocorbucci.com/post/darkness-brutal-by-rachel-a-marks2016-08-29T23:27:17.223000Z2016-09-09T18:09:00ZHugo Corbucci<div>The <a href="https://www.amazon.com/Darkness-Brutal-Dark-Cycle-Book-ebook/dp/B00S6Z3S82">first book</a> of a series called The Dark Cycle, Darkness Brutal sets the tone in the first few sentences. We are following a hero who speaks in first person, can see demons, and doesn’t look like a model citizen. We find out quickly that our hero can not only see demons, he can fight them, imprison them and cast spells on them. We find out he has a sister and a mother most likely dead and he can speak Latin.</div>
<div><br/></div>
<div>As we follow Aidan, our hero, we discover a world that is hidden from most people filled with demons, super natural items and powers and beings and some people who are not quite as unknowing as the rest of humanity. Aidan has special skill he uses to protect of his little sister and even if he doesn’t quite understand why what is happening to him is taking place. Her birthday is coming up and that is a big deal even though he can’t quite tell why or what is going to happen. Through the story, Aidan will find new allies and understand better the world he is in and his own powers. In very typical teenager supernatural book, there is a love story with serious and dangerous consequences, enemies that endanger all our hero loves, friends and allies that will sacrifice themselves to save our hero and values that can help mitigate the risks.</div>
<div><br/></div>
<div>Unlike <a href="http://blog.hugocorbucci.com/permalink/2bcc44fe26">Marked</a> from The Servants of Fate, this book dwells into the demonic and supernatural worlds of heaven and hell with a clear view on right and wrong. The lack of a balance of view points is likely the main reason why I found Marked a lot more fun and attractive. If you like supernatural demonic against angels type of stories, this one might be for you. It’s a short 4 hours read most likely and pretty much only kills time. No big questions or even exciting new things to look for after.</div>
Lean Enterprise - by Joanne Molesky, Barry O'Reilly and Jez Humble - Part IVhttp://blog.hugocorbucci.com/post/lean-enterprise-by-joanne-molesky-barry-oreilly-and-jez-humble-part-iv2016-08-29T23:06:33.040000Z2016-09-02T15:27:00ZHugo Corbucci<div><a href="http://shop.oreilly.com/product/0636920030355.do">This book</a> covers a lot about transforming a traditional enterprise into a newer, more suited Lean based company. It covers from finances to portfolio management going throught adoption, technical practices and lot more.</div>
<div>The book is long. And tiring. But full of very valid useful bits of knowledge. I’ve covered <a href="http://blog.hugocorbucci.com/permalink/23623fc92b">Part I</a>, <a href="http://blog.hugocorbucci.com/permalink/b54142f492">Part II</a> and <a href="http://blog.hugocorbucci.com/permalink/025dde3366">Part III</a> in previous posts. This is the final Part.</div>
<div><br/></div>
<div>In Part IV, the authors cover how to handle transformation of the whole organization. The first point the authors stress is that the transformation is a forever going effort and that it’s goal is to change the company culture to an innovation culture. The definition for culture that the authors use comes from <a href="https://modelviewculture.com/authors/shanley-kane">Shanley Kane</a>’s collection of articles "<a href="http://model-view-culture.myshopify.com/products/your-startup-is-broken">Your Startup Is Broken: Inside the Toxic Heart of Tech Culture</a>": “[…] Culture is about power dynamics, unspoken priorities and beliefs, mythologies, conflicts, enforcement of social norms, creation of in/out groups and distribution of wealth and control inside companies". The authors note that changing a culture is, by construct, hard to do. Cultures are created exactly with the objective of perpetuating behaviors and thinking patterns and they are created over time with a large body of constituents so they only change when all (or a large majority) of those constituents behaves and thinks differently.</div>
<div><br/></div>
<div>The first step in culture change the authors highlight is the need to make it safe for members of the organization to fail. In order to innovate and change, organizations have to try things that are not going to work. If failing is viewed as a negative thing in the organization, its members will not take risks and will perpetuate the status quo.</div>
<div><br/></div>
<div>The second one is to incentive and reward a growth mind-set. A growth mind-set is one where members are viewed as individuals who can grow their intelligence over time and increase the level of the problems they can handle. The growth mind-set opposes the fixed mind-set in which individuals that have a specific level of intelligence and can use that to solve the problems they encounter. Carol Dweck, a professor at Stanford, showed that people can shift to a growth mind-set if they are rewarded for the effort they put in solving problems they find challenging as opposed to rewarding the deployment of their existing skills. This step reshapes the way organizations hire and reward their members and allows to break past the “talent shortage" that so many complain about in IT.</div>
<div><br/></div>
<div>The third step is to eliminate bias but, especially, hidden bias. There are strong hidden biases when evaluating performance and value generated especially associated to gender and race. As a consequence, it is hard to retain or even attract people that could contribute a lot to help the organization change by providing different perspectives and experiences.</div>
<div><br/></div>
<div>The next big point the authors cover is Governance, Risk and Compliance. These groups in traditional enterprise organizations are often appointed as the blockers to change.</div>
<div>The first one, governance, is, according to the authors, about keeping the organization on course. It starts with the board of directors but continues throughout the organization and should deal with responsibility, accountability and authority, visibility and empowerment.</div>
<div>The second one, Risk, is the exposure to the possibility of something unpleasant occurring. The biggest lesson here is that risk should be managed proportionally to their impacts and likelihood. As a consequence, we should avoid “wouldn’t it be horrible if…" type of mentality as they stop us from being able to prioritize against the rest of the work we have.</div>
<div>The last one, Compliance, is the obedience to laws, industry regulations, legally binding contracts, and even cultural norms. Compliance can have serious consequence as fines, shut down or even jail. As a consequence, it is often treated as non-negotiable first priority always. This is harmful since it ignores the consequences of other events in your product or company. Using an economic framework (like Cost of Delay) helps consider the relative impact of any activity and make a more informed decision. Another great learning here is to architect your work in a way to limit the impact of frameworks and regulations so that there are less pieces affected by compliance.</div>
<div><br/></div>
<div>The third point point to transformation is financial management. The old style anual budgets, adherence to said budgets as key performance indicators and basing decisions on the structure of capital expenses versus operating expenses are old ideas that hinder our ability to innovate.</div>
<div>The authors expose that traditional budgets encapsulate target, forecast and resource allocation. If we consider each separately, we can now act consciously on each to improve our reaction time and ability. Forecasting can now happen continuously as, with each new data point, we are more likely to forecast correctly and, therefore, have a better forecast. With a better forecast, we can make decisions on resource allocation that are smaller and less risky in the sense that they are more likely to impact the target we set as those should be smaller as they should be reached in a short amount of time.</div>
<div>In order to understand the value provided by each group, the authors suggest activity based accounting (or costing). The idea is to follow what a given activity provides of value to the organization and how each part of the organization contribute in costs for such activity to be successful. This makes it easier to understand the impact of our investment decisions.</div>
<div><br/></div>
<div>The fourth point is very specific to old companies in which IT is viewed as an infrastructure cost. The authors argue that IT should become a competitive advantage should you expect to innovate quickly. They argue that a lot of that advantage can be obtained if central IT changes to be a product development organization; teams that build something, run that thing; and teams invest in reducing the complexity of existing systems. These steps should ensure that teams now hold both responsibility and freedom to make the decisions that impact their lives and to which they have the best information.</div>
<div><br/></div>
<div>The last point may sound a bit obvious but it is still very important: transformation should start where the organization currently is. The current situation in the one that is the best to start changing. Waiting for an ideal time or hoping things are going to change without starting to act on it is a fallacy. Organizational change is a long or even endless road and the simple fact that we introduce a desire for a change tends to improve the overall performance of an organization because people are pushed to think and impact the business differently than they currently do. Once the short-term thrill passes, people get back to their usual way of working and the performance improvements are lost. To mitigate for that, the authors recommend to think more about deploying the strategy rather than polishing the strategy itself. It is about understanding how each level will be able to understand and act on the goals being set. To start the change, the authors recommend a few principles:</div>
<ul>
<li>Ensure there is a clearly defined direction: the measurable business or organizational outcome</li>
<li>Define the initial scope and limit it: Choose a small part of the organization that support the change and start with it</li>
<li>Pursue a high-performance culture of continuous improvement: Use the Improvement Kata to help getting there</li>
<li>Start with the right people: Growth mind-set people who are willing to try the new ways</li>
<li>Find a way to deliver valuable, measurable results from early on: showing results early on helps draw attention and gather momentum to spread the result and keep people energetic to keep learning</li>
</ul>
<div><br/></div>
<div>And that takes us to the end of the book. A lot of the ideas shared by the authors in this book are a collection of learnings from Donald Reinersten's <a href="https://www.amazon.com/dp/B007TKU0O0">The Principles of Product Development Flow</a>, Eric Ries’ <a href="http://blog.hugocorbucci.com/permalink/ee85616cf0">Lean Startup</a>, Jez Humble and David Farley’s <a href="https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912">Continuous Delivery</a>, Taichii Ohno’s learnings from Toyota in many books including his own <a href="https://www.amazon.com/Taiichi-Ohnos-Workplace-Management-Birthday/dp/0071808019">Workplace Management</a> and many others. I’ll be posting more on the subject as it is of interest to me so keep tuned. If it wasn’t clear, I strongly recommend reading this book if you are in a large organization or if you interact with large organization or if you hope to (either become one or interact with one).</div>
<div><br/></div>
The altar girl - by Orest Stelmachhttp://blog.hugocorbucci.com/post/the-altar-girl-by-orest-stelmach2016-08-22T20:28:28.791000Z2016-08-26T18:08:00ZHugo Corbucci<div>This thriller by Orest Stelmach brings us in the journey of Nadia, a Ukrainian immigrant descendant who lives in New York but grew up not too far in Hartford, Connecticut in a Ukrainian immigrant neighborhood. The book sets the tone in the first few chapters quite excitingly.</div>
<div><br/></div>
<div>The author sets the action early in chapters that alternate between present Nadia, our hero, dealing with her present and past Nadia dealing with a childhood traumatic experience.</div>
<div>Presently, Nadia has a weird feeling that her godfather’s death has not been an accident despite the claims. On her way back from his funeral she cannot but feel uneasy. As she reaches her neighborhood in New York, she is abducted by an old Ukrainian acquaintance who has the reputation of being a hitman. That surely doesn’t help and brings Nadia back to her memories of the survival tests described in the following chapter.</div>
<div>When she was almost 12 years old, her father and brother took Nadia to a forest not too far from their house and left her there with a backpack of supplies to pass the survival test. A Ukrainian rite of passage in which the child has to survive on their own in a forest for 3 nights. Young Nadia is terrified of the idea of being in the forest by herself but even more terrified of disappointing her father. She has been training for it for years and feels prepared but the idea of being alone without her brother Marko is scary nonetheless.</div>
<div><br/></div>
<div>The story evolves to show us a hero that has handled a pretty hard life but managed to come on top even if it meant losing touch with a lot of people she cared about. Her desire to look for answers about her grandfather, the knowledge that she lived through her survival test but the questions around how she managed and, overall, a story about Ukrainian immigration and integration provides a good thriller with a very strong lead character and plenty of plot twists as we learn more about Nadia and her family and community.</div>
<div><br/></div>
<div>A good book for a weekend of intense reading or a week or two of commute reading. Probably not one I would bother re-reading or keep following (the author intends to continue the series).</div>
<div><br/></div>
Lean Enterprise - by Joanne Molesky, Barry O'Reilly and Jez Humble - Part IIIhttp://blog.hugocorbucci.com/post/lean-enterprise-by-joanne-molesky-barry-oreilly-and-jez-humble-part-iii2016-08-20T17:05:43.477000Z2016-08-19T15:26:00ZHugo Corbucci<div><a href="http://shop.oreilly.com/product/0636920030355.do">This book</a> covers a lot about transforming a traditional enterprise into a newer, more suited Lean based company. It covers from finances to portfolio management going throught adoption, technical practices and lot more.</div>
<div>The book is long. And tiring. But full of very valid useful bits of knowledge. I’ve covered <a href="http://blog.hugocorbucci.com/permalink/23623fc92b">Part I</a> and <a href="http://blog.hugocorbucci.com/permalink/b54142f492">Part II</a> in previous posts.</div>
<div><br/></div>
<div>This is about Part III which covers the exploit phase. Now that opportunities have been identified and evolved, they now need to be prepared to become mainstream. The general theme here is continuous “on-the-fly" learning. Be that for the process and the leadership team or actual application/system being developed.</div>
<div><br/></div>
<div><b><u>Improvement Kata</u></b></div>
<div><br/></div>
<div>The main learning of Part III is what the authors call Improvement Kata. The idea is fairly simple. You execute 4 steps repeatadly to improve your organization. It is done at all levels of the organization. The four steps are:</div>
<ol>
<li>Understand the direction or challenge</li>
<li>Grasp the current condition</li>
<li>Establish the next target condition</li>
<li>Iterate toward the target condition</li>
</ol>
<div>
<div>You can learn more about the improvement Kata at <a href="http://bit.ly/11iBzlY">http://bit.ly/11iBzlY</a>.</div>
</div>
<div><br/></div>
<div>The goal is to use the Improvement Kata for both your organization as well as your product or service and work on improving constantly. If you’re talking about your organization, you’ll be thinking about the process goals/challenges/directions and where to go. If you’re thinking about your product or service, you’ll be looking at what problems it is trying to solve for your customers, why you’re not solving it right now and how to assess how close you’re getting to actually solving it.</div>
<div><br/></div>
<div>
<div><b><u><b><u>Cost of Delay</u></b></u></b></div>
</div>
<div><br/></div>
<div>When it comes to judging how to prioritize what should be worked on and when, the authors use the now famous Cost of Delay popularized by Donald Reinersten in his book <cite><span style="font-style: normal;"><a href="https://www.amazon.com/dp/B007TKU0O0">The Principles of Product Development Flow</a> (which will earn a blog post in the coming month or so). The idea behind the Cost of Delay is not that hard to grasp but it is hard to evaluate in practice.</span></cite></div>
<div><br/></div>
<div>The idea is easier in to understand with an example:</div>
<div>Let’s say you have three tasks, A, B and C.</div>
<div>Task A takes 3 weeks to be completed, costs USD 10 000, and will bring USD 1000 per week for the remaining weeks of the next 50 weeks.</div>
<div>Task B takes 6 weeks to be completed, costs USD 15 000, won’t bring anything but the company will incur USD 1500 of fine every week if not completed in 10 weeks.</div>
<div>Task C takes 5 weeks to be completed, costs USD 25 000, and will bring USD 7500 per week for the remaining weeks of the next 12 weeks.</div>
<div><br/></div>
<div>If you consider only revenue, you’d choose task C first as it will bring you USD 52 500 (7 weeks - 12 minus 5 to complete - * USD 7500). Task A would bring USD 47 000 (47 weeks - 50 minus 3 to complete) and task B won’t bring anything.</div>
<div>If you consider profit, task A profits USD 37 000, B avoids a loss of USD 2000 per week after 10 weeks and C profits USD 27 500 if completed as soon as possible. So task A would be the choice.</div>
<div><br/></div>
<div>Obviously something is missing, cost of delay is the answer from Reinersten. He argues we should look at what it costs us to delay each task. He suggests we analyze the outcome of completing tasks in every possible order.</div>
<div>If we completed tasks A, B and C in order, A would profit USD 37 000, B wouldn’t incur any losses (but cost USD 15 000) and C wouldn’t bring any revenue (but cost USD 25 000) therefore leaving us with a loss of USD 3000.</div>
<div>If we execute A, C then B, A gives us USD 37 000, C has a profit of USD 5000 and B incurs USD 6000 loss (plus USD 15 000 cost) leaving us with a profit of USD 21 000.</div>
<div>If we execute B, A, C, B doesn’t incur any extra loss (but costs USD 15 000), A profits USD 31 000 and C doesn’t bring anything (but costs USD 25 000) leaving us with a loss of USD 9 000.</div>
<div>If we execute B, C, A, B doesn’t incur any extra loss (but costs USD 15 000), C incurs a loss of USD 17 500, A profits USD 26 000 so we end up with a loss of USD 6500.</div>
<div>If we run C, A, B, C profits USD 27 500, A profits USD 32 000 and B incurs an extra loss of USD 6000 leaving us with a USD 38 500 profit.</div>
<div>Finally running C, B, A, C still brings USD 27 500, B incurs an extra USD 1500 loss, and A profits USD 26 000, we end up with a profit of USD 27 000.</div>
<div><br/></div>
<div>As a consequence, we should obviously execute task C first and then B and A as this maximizes our profit. Had we not taken the time to calculate the cost of delaying each task, we would have made the wrong choice on what task to handle first.</div>
<div><br/></div>
<div>Having said that, we still don't know what the Cost of Delay is. And it's not easy to get that single number depending on your scenario. For Task B, the cost of delay is obvious: USD 1500 per week after week 10. For Task A, it's USD 1000 per week starting immediately. For C, it's a USD 7500 per week until week 12 and then it drops to 0 but incurs the full cost. My suggestion is to put as much effort as you can to understand the costs of delaying your tasks. If you cannot fully quantify them as of right now, estimate it and move along. As you think about it more frequently, it’ll be easier to quantify it.</div>
<div><br/></div>
<div>Note that we have not calculated the options in which we don't even execute task C. In some cases that is a viable options and might be the best one. In our example, if we only executed A and B, we would end up with a USD 22 000 profit and doing B and A would result in a USD 16 000 profit so neither of those options are better than our C, B, A alternative but you can probably find a scenario in which A, B is the best option (and a little harder but also one where B and A is the best).</div>
<div><br/></div>
<div>
<div>
<div><b><u><b><u>Cost of Delay divided by duration (CD3)</u></b></u></b></div>
</div>
</div>
<div><br/></div>
<div>The calculation method I provided previously for cost of delay is a great tool to understand how to prioritze work but the reality is that there are better and easier ways to calculate the cost of delay. When you do use those alternatives, Cost of Delay just tells you, for a given task, how much it costs to postpone that task. Unfortunately, that doesn't take into account how much time the task takes to be completed (which affects the outcome).</div>
<div><br/></div>
<div>That's why the authors talk about Cost of Delay divided by duration (CD3). This composed metric takes into consideration the time is takes to complete a given task and therefore, makes it obvious to choose betwen two tasks that have the same cost of delay but in which one takes less time than the other to complete. In such case, you always want to complete the shortest task first so that you start earning value sooner rather than later.</div>
<div><br/></div>
<div>CD3 is, therefore, the prefered prioritization metric used to decided what should be explored first and why.</div>
<div><br/></div>
<div><b><u>Value Steam Map</u></b></div>
<div><br/></div>
<div>
<div>Given a couple of tasks, thanks to CD3, you can now prioritize the most valuable tasks to be worked on. However, that doesn't help you understand which tasks you should be even looking at. A Value Stream Map (VSM) is a useful tool to help you understand, at an organization level, where you can start looking at tasks.</div>
</div>
<div><br/></div>
<div>Creating a VSM is not that hard. The first step is to work collaboratively with multiple groups in your organization and identify every step needed by the organization to deliver value to its customers. Once you have a map that shows you how customer value is delivered in your organization, work to add three metrics to each step of your map:</div>
<div>
<ul>
<li>Lead Time (LT) - This measures how long it takes between the time an idea/work reaches your organization/step and the time when that idea's value is delivered to customers/next step</li>
<li>Process Time (PT) - Process times shows you how long it takes for a piece of work to be completed afer it reaches a given step</li>
<li>Percent complete and accurate (%C/A) - This gives you an understanding of, for any given step, how often does the work exits that step but then returns to it because of a problem further down the line</li>
</ul>
<div>A VSM should help you understand where your process and systems bottlenecks are and how to focus your attention to identify tasks for improvements.</div>
</div>
<div><br/></div>
<div><b><u>Continuous Delivery</u></b></div>
<div><br/></div>
<div>A VSM is great at identifying what parts of your process need to be worked on in order to achieve better outcomes. Often, a big chunk of that work lies in your ability to reduce the friction between writing software (code) and ensuring that this software attends the actual needs of your customers and is avaiable for them to use.</div>
<div><br/></div>
<div>Continuous Delivery helps address this common bottleneck. Your organization might be a purely software oriented organization or an organization that provides software as a way to address non-software related needs. Regardless of your situation, it is very likely that your delivery is a considerable bottleneck in achieving the results needed. More so, delivering whenever it makes sense from a business perspective allows your organization to provide its customers with partial changes in order to validate what has been built actually addresses your customers needs.</div>
<div><br/></div>
<div>There are very many pieces to allow for Continuous Delivery to become a reality and the book of the same name (which also deserves a post to come within the year) provides a lot more when it comes to why and how to get it done. One of the authors of this book also authored the Continuous Delivery one so the synergies are pretty clear.</div>
<div><br/></div>
<div><u><b>Getting to results</b></u></div>
<div><br/></div>
<div>A VSM allows us to understand where in the process layed the value. CD helps us remove the friction between that understanding and actually delivering it. Now we need to make sure what we deliver has the impact we hoped it would. To do so, the authors offer two techniques.</div>
<div><br/></div>
<div>The first one is super simple and well known. Using why questions, navigate to the root cause of the issue and ensure that whatever solution is found addresses the root cause. If the anwer to the why question is not beyong the scope of your organization (as in, your organization can still change that), keep asking why. When you find an answer that goes beyong your organization's power/scope, get the last answer and it represents your actionable root cause. Changing that root cause state to your desired condition becomes your target condition. How that condition is achieved should be irrelevant to the organization so long as it is achieved (and is legal).</div>
<div><br/></div>
<div>The second technique is less known but comes from a famous author of the field: Gojko Adzic. Gokjo recommends an acitivity where all stakeholders work together to describe a mind map in which the center represents the problem as described by stakeholders originally and then slowly grown (collaboratively) to answer why that problem should be solved, who can solve it, how that may happen and what will solve it.</div>
<div><br/></div>
<div><u><b>Hypothesis Driven Development</b></u></div>
<div><br/></div>
<div>Now that we understand the root cause of the problem we're trying to solve, we need to understand if what we're actually thinking of building will, in fact, address that root cause. The proposed approached in the book is what is now called as Hypothesis Driven Development. It is highly similar to the scientific method used so commonly in physics, chemistry and so many other "actual" sciences. Overall, the idea is that you describe a cause-effect relationship and set yourself up to test whether or not you can validate that you only get the effect if the cause is present and that having only the cause is sufficient to get the effect.</div>
<div><br/></div>
<div>When it comes to software development, Jeff Gothelf and Josh Seiden offered a template that works for them in their book <a href="https://www.amazon.com/dp/B0074KA0A4">Lean UX</a> and the authors refer in the book:</div>
<div><br/></div>
<div>We believe that <b>[building this feature]</b></div>
<div><b>[for these people]</b></div>
<div>Will achieve <b>[this outcome].</b></div>
<div>We will know we are successful when we see <b>[this signal from the market]</b>.</div>
<div><br/></div>
<div>One of the easiest ways to eliminate hypothesis is by actually relying on other people's work or to understand your costumers without having to actually talk to them any single time. That's where your user research becomes key. The authors present a quadrant of types of user researches from <a href="https://www.linkedin.com/in/janicefraser">Janice Fraser</a> that I found very useful:</div>
<div><br/></div>
<div><img src="https://cdn-images.postach.io/2d3d8d3f-3e45-43cc-81eb-69145508daba/714f968d-9d43-4ca9-9341-67c4e29edc30/72c83ab4-0d4b-461b-918e-62ad85408006.png" style="width: 641px; height: auto;"/></div>
<div><br/></div>
<div>An important reminder at this stage of the process is that you're still trying your best to learn as much as possible. Regardless of the level at which you're trying to push your organization through, you need to keep in your mind (and others) that the goal to any experiment is to reduce uncertainty by the maximum amount possible with the smallest possible cost. That means that you're looking for experiments which balance the ratio between the amount of information obtained (quality of the information and quantity) and cost of preparation to obtain that information.</div>
<div><br/></div>
<div>A few good ideas to reduce experiment costs while maximizing amount of information obtained are:</div>
<div>
<ul>
<li>80/20 rule: handle 80% of the cases with 20% of the work and ignore the corner cases</li>
<li>Don't build for scale. When it comes to information, you'll get variability of data points within your first 1000 entries. No need to prepare for millions or billions data points.</li>
<li>A consequence of the 80/20 rule is to not handle cross-browser needs. Idenitfy your target audience and build only for them. You can handle the rest once you've proven it is worth investing in it.</li>
<li>Another one that is a bit more controversial is to not worry about having a significant test coverage. You want the common target case to work but it's fine if there are a few scenarios in which you get an error. You're not trying to actually develop the functionality, you just want to verify it yields the outcome you expected.</li>
</ul>
</div>
<div><u><b><br/></b></u></div>
<div><b><u>Handling operations</u></b></div>
<div><br/></div>
<div>Now that you've managed to get experiments running and you know why you're pursuing them, you're bound to find some things that work and should be kept running. The authors mention Amazon a lot here as a good example on how to make operations work in a Lean Enterprise.</div>
<div>The recommendations are quite famous by now. The first one is the "two pizzas" team rule. You should be able to feed any single team with two pizzas and no more. This ensures that the team is small enough that they are very aligned and communication overhead is kept to a minimum.</div>
<div>With such small teams, you might end up with a lot of teams. It all blends and loses power if those teams cannot accomplish anything on their own. To avoid this scenario, Amazon enforces that every team must provide APIs for their systems that will allow anyone (within or without Amazon) to integrate with them. More so, such integration should be possible without the need for a discussion between teams. APIs should be documented enough that anyone can find out how to integrate on their own.</div>
<div>Finally, Werner Vogels (Amazon's CTO at the time of the writing) enforces that "You build it, you run it". This means that each of those teams is also responsible to ensure that the services they have built are available, responsive and achieve the business outcome they desired.</div>
<div><br/></div>
<div>If we look at those three recommendations, they make heavy use of the effects of <a href="https://en.m.wikipedia.org/wiki/Conway%27s_law">Conway's Law</a> to ensure that teams match the desired systems boundaries. Instead of letting the teams shape the systems boundaries, those rules make it so that the system boundaries shape the teams (which will reinforce those) in a way that ensures the desired business outcome.</div>
<div><br/></div>
<div>The authors point out that there are couple more pre-requisites for this to actually work. The first one is to enable teams to thrive. <a href="https://www.youtube.com/watch?v=wdzHgN7_Hs8">Daniel Pink's, now famous, work</a> on the basis to allow for super performant individuals and teams is core to the argument here. The teams that are shaped to match desired system boundaries need to be able to decide on their own how achieve their goals (autonomy). They also need to have the skills to do it (mastery) so that the tasks are achievable. Finally, they need to really understand what the goal is. Not how to get to that goal, they can find that out on their own if they have autonomy and master, but where they really want to go (purpose).</div>
<div><br/></div>
<div>This last point is crucial and hard to get right. This is now the most important responsibility for the senior team: to align rewards with the desired outcomes. Similarly to experiments, it should not matter how the outcome is achieved. The idea is that the teams are most likely going to find smarter faster ways to reach the desired outcome than a plan laid out by leadership.</div>
<div><br/></div>
<div><b><u>Moving from current state to new architecture</u></b></div>
<div><br/></div>
<div>Hopefully all the arguments the authors have laid out make sense. If they do, you will find yourself with a problem: how do we transition from our current monolithic system and rigid processes to the new way of architecting organizations and systems.</div>
<div><br/></div>
<div>The pattern is common when it comes to software and will sound scary if you think about people and organization but the idea still holds. The pattern is called Strangler. When it comes to systems, the idea is that you build a new version in a new architecture that replaces a piece of the old system. Once happy with the new version, you slowly direct users to the new version instead of the old one until you have fully diverted the usage to the new system. You can then remove the ununsed piece of the old system.</div>
<div><br/></div>
<div>A similar approach works for organizations. You slowly change a piece of the process and a group of people to work differently. Once they start showing results, you expand the change to other groups slowly until everyone has moved to the new processes.</div>
<div><br/></div>
<div><br/></div>
<div>Part III is pretty dense because it handles one of the longest periods in an organization's life. The majority of the work will be in the exploit phase and that's where actual sizable value is returning to the organization. Ultimately, part III probably describes more so what daily life in a Lean Enterprise will feel life once you get there. In a few weeks, I'll tackle the last part of the book, Part IV, which covers how to transform your whole organization. What needs to change and where and when.</div>
City of Echoes - by Robert Ellishttp://blog.hugocorbucci.com/post/city-of-echoes-by-robert-ellis2016-08-14T00:00:26.559000Z2016-08-12T18:18:00ZHugo Corbucci<div>This police thriller takes us through the story of Matt Jones, our hero. The books starts as Matt heads to a fancy restaurant in Los Angeles to celebrate with an old time friend and partner his recent promotion to the homicide division of hollywood. As he sits at the bar to wait for his friend, he gets a call from his new boss asking him to start early and head to a crime scene a few blocks away. Matt agrees, sends a message to his friend cancelling the celebration and heads out to the crime scene. Straight across a community police station, a black SUV is filled with bullets from an automatic weapon and, inside, a body that can’t be identified due to the amount of bullets in it.</div>
<div><br/></div>
<div>As Matt gets more information from the other officers on the scene, he finds a cell phone in the car that will start a long journey through over sixty chapters. The investigation has a bit of everything: a hard time with the new partner, problems with other cops, a serial killer, a robber accused of murder who swears innocence and shattered emotions, family stories and romances.</div>
<div><br/></div>
<div>Chapters are mostly short, always from Matt’s perspective although the narrator is not Matt himself. As the reader follows along the book, it becomes evident as mysteries unfold that things are more complicated than they looked. Although not a fantastic storyline, the book mixes a good balance to keep you entertained and wondering what is next. It’s not a long read nor one that you’ll want to reread but it is quite an enjoyable time killer for a 5 hours flight or similar.</div>
Younger - by Suzanne Munshowerhttp://blog.hugocorbucci.com/post/younger-by-suzanne-munshower2016-07-11T13:35:57.310000Z2016-08-05T23:34:00ZHugo Corbucci<div>The title of <a href="http://www.amazon.com/Younger-Suzanne-Munshower-ebook/dp/B00NWS4AMQ">this book</a> suggests the theme quite easily. A woman in her fifties, Anna, gets involved into a project that allows to rejuvenate her appearance by about twenty or thirty years. The context is well set up with a protagonist who is struggling to remain relevant after over twenty successful years in the make up marketing industry. A start with alternating chapters between Anna dealing with her declining career and another character who is in her twenties who seems to be running away from something or someone gets the reader quite intrigued. How the two characters are related and how their story will come together are obvious questions that go along with what will happen to both of those women’s futures.</div>
<div><br/></div>
<div>The rest of the book gives the reader a description of what is means to be young in the years 2000 and how and why youth can affect so many things. With a bit of romance, a bit of mystery and a bit of secret service style action, Younger is a pleasant novel that debates on the old quest for eternal youth and the sacrifices one might make to achieve it. It surely isn’t the next “The Picture of Dorian Gray" but it is amusing and well worth the few hours it takes to read. It is, however, geared towards readers born prior to 1990s and I’m sure some of the comments and chapters are way less interesting if you’re part of the generation being described.</div>
<div><br/></div>
<div>Nevertheless, read anyway if you’re hoping to kill so time. Don’t get too high expectations and everything should be fine...</div>
Lean Enterprise - by Joanne Molesky, Barry O'Reilly and Jez Humble - Part IIhttp://blog.hugocorbucci.com/post/lean-enterprise-by-joanne-molesky-barry-oreilly-and-jez-humble-part-i-copy2016-08-20T17:03:46.364000Z2016-07-29T15:24:00ZHugo Corbucci<div><a href="http://shop.oreilly.com/product/0636920030355.do">This book</a> covers a lot about transforming a traditional enterprise into a newer, more suited Lean based company. It covers from finances to portfolio management going throught adoption, technical practices and lot more.</div>
<div>The book is long. And tiring. But full of very valid useful bits of knowledge. I’ve covered <a href="http://blog.hugocorbucci.com/permalink/23623fc92b">Part I in a previous post</a>.</div>
<div><br/></div>
<div>This is about Part II which is about how to explore the opportunities that exist around us. The authors point very early on that we tend to jump into solutions (and love them) before exploring the problem space. And, to add more to it, once we start spending to build a solution, the sunk cost fallacy makes us grip even stronger to the solution we’ve started to build regardless of the result we’re getting. To avoid it, the big advices are:</div>
<div>
<ol>
<li><b>Define the measurable business outcome to be achieved</b></li>
<li><b>Build the smallest possible prototype capable of demonstrating measurable progress towards that outcome</b></li>
<li><b>Demonstrate that the proposed solution actually provides value to the audience it is designed for</b></li>
</ol>
<div><br/></div>
<div>The first one helps us shape a goal that, even if the players (a.k.a. the product’s developers) follow unconventional paths to reach the goal, it is still beneficial for the product. The second allows us to spend as little as possible to try out ideas that may bring forward appropriate revenue. Finally, the third one requires us to ensure that we are, indeed, being rewarded by our audience for solving a real problem they needed solved.</div>
<div><br/></div>
<div>In order to achieve those 3 steps, we want to ensure that, instead of listing down requirements, we focus on hypotheses that we are putting forward. Something like “If we provide a high fidelity visual representation of the product we are offering, then we will observe a higher percentage of customers adding those products to their cart" instead of “Display high quality pictures on the product page". As a consequence of the hypothesis approach, it is clear that one should try to observe that the “then" piece of the sentence yields once we start developing a version (usually very simple, narrow and small) of the “if" piece rather than implementing high quality pictures. So one would run an experiment such as the following:</div>
<div>You would find a single (or a handful) of products, take high quality pictures and show it to certain customers while others would see the old lower quality pictures and try that out. If it didn’t work, you wouldn’t go through the trouble of putting in place processes and operations to ensure all products have high quality pictures before discovering it doesn’t yield any quantifiable results.</div>
<div><br/></div>
<div>A few other highlights of that section:</div>
<ul>
<li>“The job of an experiment is to gather observations that quantitatively reduce uncertainty." Note that the higher the level of uncertainty, the less information is needed to reduce uncertainty. On the other hand, the less uncertainty we have on a specific thing, the more information we need to reduce it even further. This hints us to search for a balance in which we have done all easy/low fidelity/quick experiments that reduced the bulk of the uncertainty but without having invested too much to reduce such uncertainty.</li>
<li>Measurement: A quantitively expressed reduction of uncertainty based on one or more observations. This means a measurement is a probability distribution that models how likely each result is to happen.</li>
<li>The fundamental question is not whether we can build a solution but rather if we should. And the answer should come from, first, a shared understanding of what problem is being addressed and how we might tackle it. A useful tool is the <a href="https://www.businessmodelgeneration.com/canvas">Business Model Canvas</a>. There are other canvases to address testing product/market fit such as <a href="https://www.leancanvas.com">the Lean Canvas</a>, <a href="https://comakewith.us/tag/opportunity-canvas">the Opportunity Canvas</a> and <a href="https://bit.ly/1v6Z5Ae">the Value Proposition Canvas</a>.</li>
<li>A Minimum Viable Product, as defined by Marty Cagan, is “the smallest possible product that has three critical characteristics: people choose to use it or buy it; people can figure out how to use it; and we can deliver it when we need it with the resources available — also known as valuable, usable and feasible" to which the authors add “delightful". This is not Eric Ries’ definition which Cagan rebrands as MVP test and describes something that already has commercial value (as opposed to Ries’ definition which serves to show potential value).</li>
<li>There are many different types of MVPs. A few are:
<ul>
<li>Paper: Throwaway hand-sketched drawings to illustrate a user experience or design.</li>
<li>Interactive prototype: Clickable, interactive mockup of a prototype or design</li>
<li>Concierge: A personal service instead of a product, which manually guides the customer through a process using the same proposed steps to solve the customer problem in the digital product.</li>
<li>Wizard of Oz: Real working product however behind the scenes all product functions are carried out manually unknown to the person using the product</li>
<li>Micro-niche: Reduce all product features to the bare minimum, socialize and drive paid-for traffic to the product to find out if customers are interested or willing to pay for it</li>
<li>Working software: Fully functioning working product to address a customer problem, instrumented to measure customer behavior and interactions </li>
</ul>
</li>
<li>There is The One Metric That Matters (OMTM). It should be close enough to the hypothesis so that it answers whether the assumptions hold or not. It provides a ground for focused discussion. It should be timely so that it can be quickly acted upon.</li>
<li>Defining what we measure will define how we will behave. Vanity metrics as described by Ries do not offer guidance to what action to take and are, therefore, useless. Good metrics change the way you behave. A couple examples are “Number of visits" vs “Funnel metrics or cohort analysis", “Number of downloads" vs “User activations". For service-oriented businesses, use cohort analysis on Acquisition, Activation, Retention, Revenue and Referral (AARRR - the pirate metrics).</li>
<li>In addition to Ries’ three growth engines (Viral, Pay, Sticky), enterprises should also consider two other: Expand in which the initial business model grows either in categories, geographically or adjacently. And Platform in which, upon establishing a successful, product, the company developers other products that integrate with the first one transforming it all in a platform.</li>
<li>When migrating between investment horizons, there are disruptions. Those should happen very consciously and with some enablers. From explore to exploit, there are five:
<ul>
<li>Market: The early adopters must be part of larger group and we can understand how to reach those</li>
<li>Monetization model: How is the investment going to be recovered? This tends to be hard to change in the future but critical to success.</li>
<li>Customer adoption: Albeit important to get customers, it is important not to sacrifice your vision and product to attract users quickly.</li>
<li>Don’t “big bang" releases: Test and learn, use alpha and beta launches frequently and surely.</li>
<li>Team engagement: Collaboration needs to keep flowing between the innovation and operations teams.</li>
</ul>
</li>
</ul>
</div>
<div><br/></div>
<div>And you can keep going about <a href="http://blog.hugocorbucci.com/permalink/025dde3366">Part III</a> now.</div>
Fated - by Sarah Finehttp://blog.hugocorbucci.com/post/fated-by-sarah-fine2016-07-10T17:35:46.037000Z2016-07-22T23:09:00ZHugo Corbucci<div>The last book of the Servants of Fate follows, as <a href="http://blog.hugocorbucci.com/post/claimed-by-sarah-fine">predicted in Claimed</a>, Aislin Ferry and Jason Moros, respectively Charon of the Ferrys and Lord of the Kere. They are both struggling to keep their power over their respective empires. While Aislin has to deal with family politics, Jason also has his own, quite different, family issues as one or more of his sisters are plotting against him and his Kere and he doesn't know how to reach them.</div>
<div><br/></div>
<div>As with the previous books, Sara's style of alternating chapters between her two protagonists points of view allows her to play on each character's uncertainties, fears and desires. She also manages to hide details of the plot from the reader or exposing them while hiding them from her characters very nicely.</div>
<div><br/></div>
<div>As with the previous books, Fated keeps a fast paced rhythm, a few erotic chapters and a lot of action. It's easy to follow the book even though, by mid book, the reader gets quite puzzled into why the book isn't over yet. The ending is not very surprising once you get there but it is not easily guessable before you start.</div>
<div><br/></div>
<div>As with the two previous ones, I devoured this in a matter of hours stopping only when I had no choice. It is not your super exciting book that you need to re-read many times but it surely makes for a very entretaining few hours and a quite dreamy description of worlds that might be.</div>
<div><br/></div>
<div>In short, if you're into fantasy read the first book (Marked). If you like it, don't hesitate and get the other two (Claimed and Fated) and devour as your time allows. It'll feel great to read and you won't regret deeply not having another one to read.</div>
Lean Enterprise - by Joanne Molesky, Barry O'Reilly and Jez Humble - Part Ihttp://blog.hugocorbucci.com/post/lean-enterprise-by-joanne-molesky-barry-oreilly-and-jez-humble-part-i2016-08-20T17:04:26.223000Z2016-07-15T20:44:00ZHugo Corbucci<div><a href="http://shop.oreilly.com/product/0636920030355.do">This book</a> covers a lot about transforming a traditional enterprise into a newer, more suited Lean based company. It covers from finances to portfolio management going throught adoption, technical practices and lot more.</div>
<div>The book is long. And tiring. But full of very valid useful bits of knowledge.</div>
<div><br/></div>
<div>Broken down in 4 parts, it starts by covering culture, strategy and how innovation starts and evolve in a group of people. Part I is probably the most interesting and exciting one even though it’s not the one that brings the most novelty. The concepts in there are essentially the same as the ones found in <a href="http://www.amazon.com/Implementing-Lean-Software-Development-Concept/dp/0321437381">Mary Poppendieck’s books</a> and in <a href="http://blog.hugocorbucci.com/post/the-lean-startup-by-eric-ries">Eric Ries’ Lean Startup</a>. A bunch of the stories, like the, now traditional, joint venture between Toyota and GM at NUMMI factory are also shared. Despite that, some of the conclusions formulated in this book are easier to grasp here rather than in other books. Since the book is quite long and there is a lot of learning in it, I’m gonna break down the review for each part of the book.</div>
<div><br/></div>
<div>For Part I, the most important learnings are:</div>
<ol>
<li><b>The Principle of Mission is meant to replace the old Command and Control.</b><br/>
This comes from warfare knowledge and a few modification for the enterprise from <a href="http://blog.hugocorbucci.com/post/the-principles-of-product-development-flow-by-donald-reinertsen">The Principles of Product Development Flow</a> by Donald G Reinertsen. The idea is that, in realms of high uncertainty, it is best to specify the desired end state, its purpose and as few constraints as possible. The people on the ground close to the action are best suited to make the best decisions to achieve that goal because they can react to the existing conditions much faster than any chain of command can.</li>
<li><b>Portfolio management needs to account for the high variability of looking for new ideas.</b><br/>
The key idea here is the concept of an option that is pretty common in financial markets. Essentially, you’re paying now for a chance of finding a great deal or minimizing your losses if you don’t. In that mindset, the authors advocate for a portfolio management process that allows for some investment in innovation while minimizing the risks for the company. They break investments down in three categories. Horizon 1 focuses on the currently established and explored opportunities. This is your current business and needs to bring value within the year. Horizon 2 is looking at tomorrow’s cash flow. It’s businesses that are growing well and steadily and may become your companies’ cash flow in 2 or 3 years from now. Finally Horizon 3 is looking at the following 3 years for options on the future businesses that your company might want to invest then.</li>
</ol>
<div><br/></div>
<div>And I’ve since published <a href="http://blog.hugocorbucci.com/permalink/b54142f492">Part II</a>.</div>
Developing Hybrid applicationshttp://blog.hugocorbucci.com/post/developing-hybrid-applications2016-06-08T18:32:23.276000Z2016-06-24T18:59:00ZHugo Corbucci<div>When it comes to mobile, native vs hybrid vs web is among the most common debates. The trade offs are not very complicated.</div>
<div><br/></div>
<div>Native means you have to re-implement similar features across at least 2 platforms but likely a couple more. It also tends to mean you have some sort of shared back-end anyway that doesn't have any user interface but still provides a bunch of common APIs to persist and share data across platforms. It often requires 2 or more teams to handle all the multiple specific platform changes and peculiarities but it often provides a more natural and better experience for the users.</div>
<div><br/></div>
<div>Web only tends to the easiest and quickest to achieve. HTML, CSS and JS are now decently standardized enough that the many mobile browsers around can handle a good chunk of what you need to generate a page that looks very similar across platforms. Those also tend to include the backend and the sharing. One platform for all. Obviously the look and feel won't quite match the user's usual platform but, then again, they likely have noticed it's only a website anyway. You also get limited when it comes to device specific hardware (camera, gyroscope, 3D accelerators, etc) and certain types of notifications.</div>
<div><br/></div>
<div>Hybrid promises to be the middle ground that settles it all. And honestly, in a world that has more and better wireless connection, we're getting there. The small thin native shells that provide you access to those native capabilities and integrations. There are two magic glues. The first one is the web view or equivalent that allows your html structure to be rendered by the default browser on your device. Along with the web view comes the ability to invoke JavaScript functions which is the second glue. Now your native code can (if properly designed) inform your web code of things that happened on the device. The other way around is a little harder (replace your html structure with native elements) but is getting there.</div>
<div><br/></div>
<div>For the first one, the beauty of firing events is the big magic. Whatever happens in the device on native code can simply trigger an event in JavaScript. Whoever listens to that event gets the appropriate notification and execution and you can easily shoot that back to the server. For example:</div>
<div><br/></div>
<div style="-en-codeblock: true; box-sizing: border-box; padding: 8px; font-family: Monaco, Menlo, Consolas, "Courier New", monospace; font-size: 12px; color: rgb(51, 51, 51); border-top-left-radius: 4px; border-top-right-radius: 4px; border-bottom-right-radius: 4px; border-bottom-left-radius: 4px; background-color: rgb(251, 250, 248); border: 1px solid rgba(0, 0, 0, 0.14902); background-position: initial initial; background-repeat: initial initial;">
<div>- (void) phoneInitialized {</div>
<div> [self executeJS:@"$.myApplication.trigger('phone:connected');"];</div>
<div>
<div>}</div>
</div>
</div>
<div><br/></div>
<div>The second option requires a bit more work and craft on the web site. Pieces of your html structure as well as JavaScript need to allow for the native experience to overwrite the default web-experience. The easiest solution is an iframe as it allows the web view to reject making the request and consider it should host that address natively. It does, however, limit how much that piece of the page can share with the outside area as well as what is shown and how.</div>
<div><br/></div>
<div>For now, I would say, my default go-to option would be the hybrid option to hook native events with javascript triggers and, therefore, define the interface façade that I support. Adding new devices means, if they only exist native events already known, is merely the work to ensure the native shell triggers those events. Add new events is a matter of ensuring the Javascript interface is well defined and then implementing the calls on the shell. If the shell doesn’t know how to react to the event, nothing happens and all continues along just fine.</div>
<div><br/></div>
Developing clojurehttp://blog.hugocorbucci.com/post/developing-clojure2016-04-10T05:50:05.433000Z2016-04-08T04:26:00ZHugo Corbucci<p>As part of work, I ended up having to learn and use clojure for something more than my <a href="https://github.com/espaco-guerra/engine-server">pet projects</a>. I have to say it grows on me every time. Ring and compojure make it quite pleasant to develop web applications. The smallest example of a ring web application I could come up with was the following:</p>
<p><a href="https://github.com/hugocorbucci/ring-compojure-samples/blob/master/src/clj/samples/minimal.clj">sample/minimal.clj</a>:</p>
<pre class='prettyprint lang-clj'><code class='lang-clj'>(ns samples.minimal
(:gen-class)
(:require
[org.httpkit.server :refer [run-server]]
[environ.core :refer [env]]))
(def handler
(fn [request]
{:status 200 :headers {"Content-Type" "text/html"} :body "Hello Minimal World!"}))
(defn -main [& [port]] ;; entry point, lein run will pick up and start from here
(let [p (Integer. (or port (env :port) 5000))]
(run-server handler {:port p})))</code></pre>
<p>All this gives us is the following:</p>
<pre class='prettyprint lang-sh'><code class='lang-sh'>
> curl 'http://localhost:3000/' -I -s
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 20
Server: http-kit
Date: Sun, 03 Apr 2016 07:42:10 GMT
> curl 'http://localhost:3000/' -s
Hello Minimal World!
> curl 'http://localhost:3000/testing' -I -s
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 20
Server: http-kit
Date: Sun, 03 Apr 2016 07:42:10 GMT
> curl 'http://localhost:3000/testing' -s
Hello Minimal World!
> curl 'http://localhost:3000/js/template.js' -I -s
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 20
Server: http-kit
Date: Sun, 03 Apr 2016 07:42:11 GMT
> curl 'http://localhost:3000/js/template.js' -s
Hello Minimal World!
> curl 'http://localhost:3000/css/template.css' -I -s
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 20
Server: http-kit
Date: Sun, 03 Apr 2016 07:42:11 GMT
> curl 'http://localhost:3000/css/template.css' -s
Hello Minimal World!
</code></pre>
<p>Ring's middlewares are the cherry on top of the cake. They are super powerful and feel very intuitive despite my expectations. There is a default ring middleware project that adds a bunch of pretty common useful middleware (like <a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet">CSRF</a>, content headers, caching, static assets like js and css, etc):</p>
<p><a href="https://github.com/hugocorbucci/ring-compojure-samples/blob/master/src/clj/samples/with_middleware.clj">sample/with_middleware.clj</a>:</p>
<pre class='prettyprint lang-clj'><code class='lang-clj'>(ns samples.with-middleware
(:gen-class)
(:require
[org.httpkit.server :refer [run-server]]
[ring.middleware.defaults :refer [wrap-defaults site-defaults api-defaults]]
[environ.core :refer [env]]))
(def handler
(fn [request]
{:status 200 :headers {"Content-Type" "text/html"} :body "Hello World with middleware!"}))
(def app
(wrap-defaults handler site-defaults))
(defn -main [& [port]] ;; entry point, lein run will pick up and start from here
(let [p (Integer. (or port (env :port) 5000))]
(run-server app {:port p})))
</code></pre>
<p>Now our results are as follow:</p>
<pre class='prettyprint lang-sh'><code class='lang-sh'>
> curl 'http://localhost:3000/' -I -s
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: ring-session=16bc73e9-ee70-4126-a7d4-c814fba7d6b7;Path=/;HttpOnly
X-Xss-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Length: 28
Server: http-kit
Date: Sun, 03 Apr 2016 07:42:21 GMT
> curl 'http://localhost:3000/' -s
Hello World with middleware!
> curl 'http://localhost:3000/testing' -I -s
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: ring-session=0e1792c2-de70-4405-984d-082f889886da;Path=/;HttpOnly
X-Xss-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Length: 28
Server: http-kit
Date: Sun, 03 Apr 2016 07:42:21 GMT
> curl 'http://localhost:3000/testing' -s
Hello World with middleware!
> curl 'http://localhost:3000/js/template.js' -I -s
HTTP/1.1 200 OK
Content-Length: 0
Last-Modified: Sun, 03 Apr 2016 04:47:10 GMT
Content-Type: text/javascript; charset=utf-8
X-Xss-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Server: http-kit
Date: Sun, 03 Apr 2016 07:42:21 GMT
> curl 'http://localhost:3000/js/template.js' -s
(function() {
var message = "I got loaded!";
document.addEventListener("DOMContentLoaded", function(event) {
if (console) {
console.log(message);
} else {
alert(message);
}
});
}());
> curl 'http://localhost:3000/css/template.css' -I -s
HTTP/1.1 200 OK
Content-Length: 0
Last-Modified: Sun, 03 Apr 2016 04:45:48 GMT
Content-Type: text/css; charset=utf-8
X-Xss-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Server: http-kit
Date: Sun, 03 Apr 2016 07:42:21 GMT
> curl 'http://localhost:3000/css/template.css' -s
body {
font-family: Helvetica;
}
</code></pre>
<p>Compojure itself just makes it easier for your application to handle the in-between of ring and your code. It ties the whole together quite transparently and so you barely even notice you're getting a lot from it but it's still awesome.</p>
<p><a href="https://github.com/hugocorbucci/ring-compojure-samples/blob/master/src/clj/samples/with_compojure.clj">sample/with_compojure.clj</a>:</p>
<pre class='prettyprint lang-clj'><code class='lang-clj'>(ns samples.with-compojure
(:gen-class)
(:require
[org.httpkit.server :refer [run-server]]
[compojure.core :refer [defroutes GET PUT POST DELETE ANY]]
[ring.middleware.defaults :refer [wrap-defaults site-defaults api-defaults]]
[environ.core :refer [env]]))
(defroutes site-routes
(GET "/" []
{:status 200 :headers {"Content-Type" "text/html"} :body "Hello World with compojure!"}))
(def handler
(wrap-defaults site-routes site-defaults))
(defn -main [& [port]] ;; entry point, lein run will pick up and start from here
(let [p (Integer. (or port (env :port) 5000))]
(run-server handler {:port p})))
</code></pre>
<p>The results are now as follow:</p>
<pre class='prettyprint lang-sh'><code class='lang-sh'>
> curl 'http://localhost:3000/' -I -s
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: ring-session=9aba80cc-501c-4cbb-9d77-d578ceed6289;Path=/;HttpOnly
X-Xss-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Length: 0
Server: http-kit
Date: Sun, 03 Apr 2016 07:42:32 GMT
> curl 'http://localhost:3000/' -s
Hello World with compojure!
> curl 'http://localhost:3000/testing' -I -s
HTTP/1.1 404 Not Found
Content-Length: 0
Server: http-kit
Date: Sun, 03 Apr 2016 07:42:32 GMT
> curl 'http://localhost:3000/testing' -s
</code></pre>
<p>Compojure handles everything that is route matching and other path matching activities. Note that this example is very simple with a single path. Composure handles wildcards in paths, variable capturing, contexts and many other things that would make the if condition in that request handler function a lot more complicated. If you didn't have compojure you'd have to handle all of this by yourself:</p>
<p><a href="https://github.com/hugocorbucci/ring-compojure-samples/blob/master/src/clj/samples/without_compojure.clj">sample/without_compojure.clj</a>:</p>
<pre class='prettyprint lang-clj'><code class='lang-clj'>(ns samples.without-compojure
(:gen-class)
(:require
[org.httpkit.server :refer [run-server]]
[ring.middleware.defaults :refer [wrap-defaults site-defaults api-defaults]]
[ring.util.request :refer [path-info]]
[environ.core :refer [env]]))
(def handler
(fn [request]
(if (= "/" (path-info request))
{:status 200 :headers {"Content-Type" "text/html"} :body "Hello World without compojure!"}
{:status 404 :body ""})))
(def app
(wrap-defaults handler site-defaults))
(defn -main [& [port]] ;; entry point, lein run will pick up and start from here
(let [p (Integer. (or port (env :port) 5000))]
(run-server app {:port p})))
</code></pre>
<p>Which produces about the same thing except for the 404 headers:</p>
<pre class='prettyprint lang-sh'><code class='lang-sh'>
> curl 'http://localhost:3000/' -I -s
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: ring-session=a76f0a3a-5f15-4600-9bb3-4470735f2626;Path=/;HttpOnly
X-Xss-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Length: 30
Server: http-kit
Date: Sun, 03 Apr 2016 07:42:42 GMT
> curl 'http://localhost:3000/' -s
Hello World without compojure!
> curl 'http://localhost:3000/testing' -I -s
HTTP/1.1 404 Not Found
Set-Cookie: ring-session=205fcee8-160b-477f-9f00-26ac9af29ec4;Path=/;HttpOnly
Content-Type: application/octet-stream
X-Xss-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Length: 0
Server: http-kit
Date: Sun, 03 Apr 2016 07:42:43 GMT
> curl 'http://localhost:3000/testing' -s
</code></pre>
<p>When it comes to generating html structure, I've chosen hiccup and have been quite pleased as well. Somehow sequences (think of them as arrays if that makes it easier) with the first element as a tag and the rest as content works very well with html. A nice little map as an optional second parameter makes attributes pretty obvious and a couple of nice tricks allow hiccup to feel very much like css selectors. Easy and natural:</p>
<p><a href="https://github.com/hugocorbucci/ring-compojure-samples/blob/master/src/clj/samples/with_hiccup.clj">sample/with_hiccup.clj</a>:</p>
<pre class='prettyprint lang-clj'><code class='lang-clj'>(ns samples.with-hiccup
(:gen-class)
(:use
[hiccup.page :only (html5 include-css include-js)])
(:require
[org.httpkit.server :refer [run-server]]
[compojure.core :refer [defroutes GET PUT POST DELETE ANY]]
[ring.middleware.defaults :refer [wrap-defaults site-defaults api-defaults]]
[environ.core :refer [env]]))
(defroutes site-routes
(GET "/" request
(html5
[:head
[:title "Home"]
(include-css "/css/template.css")]
[:body
[:p "Hello World with hiccup"]
(include-js "/js/template.js")])))
(def handler
(wrap-defaults site-routes site-defaults))
(defn -main [& [port]] ;; entry point, lein run will pick up and start from here
(let [p (Integer. (or port (env :port) 5000))]
(run-server handler {:port p})))
</code></pre>
<p>With the results:</p>
<pre class='prettyprint lang-sh'><code class='lang-sh'>
> curl 'http://localhost:3000/' -I -s
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: ring-session=f39247fe-c5ad-4b2b-9f07-039509b0c30b;Path=/;HttpOnly
X-Xss-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Length: 0
Server: http-kit
Date: Sun, 03 Apr 2016 07:42:53 GMT
> curl 'http://localhost:3000/' -s
</code>
</pre>
<pre><code class="html">
<!DOCTYPE html>
<html><head><title>Home</title><link href="/css/template.css" rel="stylesheet" type="text/css"></head><body><p>Hello World with hiccup</p><script src="/js/template.js" type="text/javascript"></script></body></html>
</code></pre>
<p>And since everything is just a sequence, it's super easy to just extract functions and share common structures between pages or within pages. I thought mixing clojure code and html would get real weird like <a href="http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial?_s=LuNe0H3cIFg_48Po&_k=qO78L1juzMTPGGSS">it did in Smalltalk</a> but somehow it worked a lot better.</p>
<p>Add to that the fact that Clojure runs on the JVM and it means that I could work with all of that while still being usable in a traditional enterprisy "give me a war and I'll deploy it". Gradle and lein don't quite interact together and you still have to maintain project.clj and build.gradle separately. It's not very hard to generate build.gradle from project.clj but you have to keep a pre-commit hook or some watcher to upgrade it when you change project.clj.</p>
<p>Overall, I would say I now have to think about where I want a project to go to chose between rails and clojure. Rails will give me more features faster: devise for authentication, cancancan for authorization, sprockets for asset-pipelines, lots of gem from aws-sdk to doorkeeper, sass-rails, will_paginate, new_relic and a bunch more. But clojure gives me access to all JVM. Sometimes with a bit more pain (need to handle the bridge or use the Java code) and sometimes with less than great bridges. But, overall, you can pull it together and, if you really need to, you can fall back to existing Java code or even flip to developing it if it makes more sense. You also get all the nice JIT compilation improvements the JVM can give. JRuby doesn't quite give you the same value and experience so, I'd pick clojure over ruby on any JVM environment and if the team I'm with if comfortable with functional programming.</p>From nothing to production in 10 mins with NodeJS, Grunt, SnapCI and Herokuhttp://blog.hugocorbucci.com/post/from-nothing-to-production-in-10-mins-with-nodejs-grunt-snapci-and-heroku2015-12-29T19:09:56.399000Z2016-01-07T17:15:00ZHugo Corbucci<div>A few weeks back, I gave a lightning talk at one of ThoughtWorks Chicago’s First Fridays about going from nothing to production in less than 10 minutes using NodeJS, Grunt, SnapCI and Heroku with Continuous Deployment. Since my friends convinced me that trying to live code this would be one of the most stupid things I could think of doing, I ended up recording a video of the process and talking over it.</div>
<div>It worked fairly well so I decided to share the results here:</div>
<div><br/></div>
<div><iframe width="480" height="270" src="https://www.youtube.com/embed/rF2lU63MxX8?feature=oembed" frameborder="0" allowfullscreen></iframe></div>
Refatoração em Ruby - by Marcos Brizenohttp://blog.hugocorbucci.com/post/refatoracao-em-ruby-by-marcos-brizeno2015-12-28T22:04:02.156000Z2016-01-04T15:42:00ZHugo Corbucci<div>This is a Portuguese-only book so I'll post the review in Portuguese.
</div>
<div>This is just a short summary in English if you're interested:</div>
<div>Marcos introduces 9 of the <a href="http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented-ebook/dp/B000SEIBB8">Gang of Four's design patterns</a> in Ruby. With great stories motivating the patterns and initial code samples, Marcos walks the reader through the work of refactoring code to design patterns. The walkthrough helps readers that are new to design patterns, ruby or refactoring. If you feel comfortable with all those 3, the book is still a nice work that merges it all together. If you're interested in having the book translated, shoot Marcos an email at "his first name dot his last name at thoughtworks dot com".</div>
<div>
<div><br/></div>
<div><pt-BR></div>
</div>
<div><a href="http://www.casadocodigo.com.br/products/livro-refatoracao-ruby">Neste livro</a>, Marcos nos guia por 9 exercícios de refatoração muito bem apresentados. Usando Ruby e mostrandos ótimos exemplos de código, acompanhamos vários desenvolvedores pela sua jornada que transforma seus códigos em implementações de alguns dos padrões descritos no livro "<a href="http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented-ebook/dp/B000SEIBB8">Design Patterns</a>" (ou <i>Gang of Four</i>). Ao contrário da maioria dos livros de padrões, Marcos não apresenta o padrão isoladamente. Ele descreve o problema que seus desenvolvedores imaginários enfrentam, explica suas necessidades e apresenta o caminho a ser seguido para transformar seus códigos em implementações de um determinado padrão.</div>
<div><br/></div>
<div>Já aviso que escrevi o prefácio ao livro e, portanto, sou enviesado no julgamento do mesmo. Mas realmente acho que esse livro é uma ótima ferramenta para explicar e aplicar padrões de projeto. É muito mais prático que os cursos costumam ser e apresenta situações com as quais é possível empatizar. O passo a passo de cada refatoração também ajuda aqueles que não se sentem completamente confortável refatorando. Por fim, o uso de Ruby é o mais simples possível. Isso faz com que não seja difícil entender o livro mesmo se você nunca estudou Ruby. Por fim, se você já se sentir confortável com padrões, ruby e refatoração, esse livro é uma ótima referência de como todas as coisas se juntam e interagem entre elas.</div>
<div></pt-BR></div>
Developing for iOS - part 2http://blog.hugocorbucci.com/post/developing-for-ios-part-22015-12-28T22:20:18.593000Z2016-01-01T03:26:00ZHugo Corbucci<div>If the <a href="http://blog.hugocorbucci.com/post/developing-for-ios-part-1">post for part 1</a> talked about language choice, there is another aspect of iOS development that is also a big choice but a lot less obvious: Graphical User Interface (GUI).</div>
<div><br/></div>
<div>XCode and iOS development are tightly coupled together as with most proprietary development platforms (think Visual Studio). When it comes to the user interface, there are two choices:</div>
<div><br/></div>
<div>1) Use what the IDE gives you to try to make your life better</div>
<div>2) Use the GUI APIs to code everything manually</div>
<div><br/></div>
<div>This isn’t much different than using Java and Swing or SWT or other graphical user interfaces (GUI). You either get a nice GUI to build your GUI and you’re restricted by how clear such GUI can be or you have to write A LOT of code to specify the GUI’s complex behavior.</div>
<div><br/></div>
<div>When it comes to iOS, it’s even more complicated since Apple gives a lot of attention to the GUI of their apps. There are tons of hidden specifications about icon sizes, launch image sizes, resizing rules, handling multiple screen sized devices and much more. XCode tries to provide useful error messages regarding the GUI but rarely succeeds doing so. A few of the ones that drove me the most crazy:</div>
<div><br/></div>
<div>1) Icon sizes for iPhone applications: the Xcode UI is nice to show you versions of the iPhone you’re trying to match but won’t help you figure out which dimensions correspond to which version. It’ll also just simply not succeed to compile or deploy if an icon for a given version is not available even when you’re deploying to a version that has an available icon.</div>
<div>2) Launch screens: those are not really being used anymore but they were a while back. So if you don’t add one for some older versions of iPhone, you’re main application screen won’t use the whole physical screen. No errors. No warnings. The screen just has a couple of black bands on top and bottom.</div>
<div>3) Constraints: iOS tries to have some flexible layouts to help developers handle similar yet different screen sizes. There are many many ways to specify those constraints. Some of them conflict with each other. Others are not constrained enough to have a single solution. Generally speaking, all components of a given screen have to be properly constrained. If one is wrong, they all can get funky. Error reporting in this case is, at best, wishful thinking. It’ll show a constraint issue but it won’t help identify the component and the solution is often very hard to find.</div>
<div><br/></div>
<div>On the other hand, XCode's GUI Storyboard metaphor is great to communicate with visual designers and non-technical folks. The flow is obvious and it provides a quick glance into how much work still needs to be done on a given screen. It’s also pretty easy to get something going very fast. It won’t be perfect and it won’t work on all devices but if you just want a quick test to get some feedback, it can take as little as 5 minutes to put a screen together that actually looks like the full-featured one would.</div>
<div><br/></div>
<div>I can easily imagine how insane maintaining those Storyboards in a distributed team that is still in the forming stage of an application. It also probably becomes quickly unmanageable as the application grows. On the other hand, fully manually developed code tends to suffer from similar issues.</div>
<div><br/></div>
<div>In the end, the reality is that GUI is complicated and it takes a lot of work to build and maintain a decent one. Being on the IDE’s hand for that maintenance seems too risk so I would recommend starting with the storyboard until you understand your GUI better and once it feels a little more stable, transition it all to be code driven.</div>
The Dead Key - by D.M.Pulleyhttp://blog.hugocorbucci.com/post/the-dead-key-by-d-m-pulley2015-12-03T03:57:13.436000Z2015-12-28T19:44:00ZHugo Corbucci<div><a href="http://www.amazon.com/The-Dead-Key-D-Pulley-ebook/dp/B00LWE0QZM">This mystery novel</a> starts slowly by introducing the reader to two young women starting their careers 20 years apart. In the late 70s, Beatrice is starting as a secretary at the First Bank of Cleaveland. 20 years later, in the late 90s, Iris is having her first job at an engineering firm that is in charge of drafting plans of all floors from the First Bank of Cleaveland's old building.
</div>
<div><br/></div>
<div>The book progresses slowly showing us Beatrice's life as a secretary living with her aunt Doris, her new friendship Max (or Maxine) from the bank and the way she discovers the world. On the other side, Iris is walking around a deserted building that was abandoned overnight nearly 20 years prior. What happened? Why is there a guard 24/7 in the abandoned building?</div>
<div><br/></div>
<div>While Beatrice takes steps towards her future, Iris seems to be taking steps towards the past as she discovers furniture, files, notes and keys in the old bank. Beatrice is young and innocent and Max is ready to help her grow and have fun. However, fun starts to get more complicated when Doris has a heart attack and, later, both Beatrice and Max discover that she had a few secrets that don't seem to make a lot of sense.</div>
<div><br/></div>
<div>Iris, on her side, is having a hard time focusing on her job to draft plans for all floors of the bank as she discovers that one floor is missing some space. The numbers don't match and floor sizes should match. Add to that a colleague that gets under her skin and a few friends who like to get really drunk, Iris gets easily distracted and when she finds a key with a number (547) on it, she's more interested in understand what that means than to work on taking boring measures of floors that look the same.</div>
<div><br/></div>
<div>That's about the point when things starts accelerating. Beatrice discovers Max snopping around her aunt Doris' drawer with some secret love letters and many weird notes. Iris discovers the bank closed over night and many people never got to touch their belongings. Something was up at the bank and none of them quite know what it is but both are committed to understanding more.</div>
<div><br/></div>
<div>Their opposite investigations provide the reader with a story that fills itself from two different angles that some times overlap and some times don't. Something doesn't smell right and things only get worse. D.M. Pulley's story spirals to speed the reader into an exciting set of events that is both scary and exciting at the same time. Loads of money, power, corruption, police, politicians and many more details drive both our protagonists to fill gaps for each other while maintaining the core of the story unknown. An unexpected gran-finale puts us to spin a last time before the curtains fall and the women in the book deal with their faith.</div>
<div><br/></div>
<div>A great mystery read. Not pretencious. A little slow at the beginning but quite fun and unexpected. This won't blow your mind but it'll likely keep you entertained for some good 8 to 12 hours. One sex scene and a few details on death make it a quite "calm" book for a mystery but still for adult public.</div>
The one that got away - by Simon Woodhttp://blog.hugocorbucci.com/post/the-one-that-got-away-by-simon-wood2015-12-03T03:56:13.852000Z2015-12-14T16:52:00ZHugo Corbucci<div><a href="http://www.amazon.com/One-That-Got-Away/dp/1612184081/ref=sr_1_1?s=books&ie=UTF8&qid=1449114917&sr=1-1&keywords=9781612184081">This exciting thriller</a> introduces our hero and protagonist, Zöe, in her weakest and most vulnerable point. The book starts when she finds herself naked in a shack tied to the floor. All she remembers was coming back on a car trip with a friend of hers, Holli, from Las Vegas and then darkness. She can hear Holli screaming and crying in another shack not too far. Fear pushes her to get free. Out of her shack, she finds the one her friend is in. Also naked but hanging by her tied hands sobbing and begging for mercy as she gets wipped. Zöe wants to free Holli but she can't see their captor. When she does, she notices he's much taller and stronger than her. She's also drugged and feels powerless. That's when Holli sees her and screams begging for her help but Zöe runs for her life and disappears in a car.</div>
<div><br/></div>
<div>The first chapter sets the tone for this exciting thriller that follows Zöe a little bit a year after her escape and Holli's most likely death. Zöe is going to therapy, she's quit her PhD program, gotten a security guard job in one of the most dangerous regions of the San Francisco bay area and isolated herself from friends and family. Recovering hasn't been easy on her. She blames herself for Holli's fate, for being weak. The police never found the place she was abducted to and some officers don't really believe her story at all. There has been no sign of the abductor or his M.O. since her escape.</div>
<div><br/></div>
<div>The following 30 chapters take us to follow Zöe when another woman is found naked and hanging in a pier in San Francisco where Zöe now lives. She is sure her abductor is back and she wants to make sure he's caught however possible. With fast paced exciting chapters, Simon Wood takes us through the many struggles that such a traumatic experience can generate along with a disturbed mind who feels the need to punish those who do not behave as they should.</div>
<div><br/></div>
<div>With a very strong female character and great pokes at our society's behavior towards those who are suffering from complicated mental conditions (be them temporary or longer term), this thriller goes by really fast. I recommend it as a great passtime that keeps you on the edge and brings you to a tense but somewhat predictable end (without taking away any of the value of the journey).</div>
Agile Brazil 2015http://blog.hugocorbucci.com/post/agile-brazil-20152015-12-03T03:52:32.180000Z2015-12-10T17:30:00ZHugo Corbucci<div>This year I went to Porto de Galinhas, Pernambuco, next to Recife to attend Agile Brazil 2015 and have a few more meetings. As a long time organizer of the conference, I ended up not spending as much time watching talks as one usually does.
</div>
<div>I did have the chance to attend 3 of the 4 keynotes, one open space session and a few other sessions along with a lot of meetings.</div>
<div><br/></div>
<div><span style="font-size: 18px;"><b>Keynote #1: The Agile mindset - by Linda Rising</b></span></div>
<div><br/></div>
<div>The first keynote was Linda Rising's "The Agile mindset". I had seen it before but any time you get the chance to hear Linda speaking, you should. I'm not reproducing everything here as Linda kindly provides her slides to anybody who wishes to reproduce her talks. In short, she explains how considering that intelligence or skill or ability is a fixed/genetic trait of any individual is damaging to our ability to improve. Based on scientific research, Linda explains that having a growth or Agile mindset is about believing that we get better by trying and putting in hard work. She explains that we can induce a given mindset with certain rewards, punishment and environment in general.</div>
<div><br/></div>
<div><b><span style="font-size: 18px;">Keynote #3: Afundando o barco - by Murilo Novaes</span></b></div>
<div><br/></div>
<div>This was our "out of the box" keynote. Murilo is a famous Brazilian sailor. He told us his impressive story on how, by arrogance, he sank a friend's boat, almost killed his son, his friend and himself. As with most accidents, he described the many mistakes/situations that culminated in a near death experience for him and the horror of almost killing his son.</div>
<div>My takeaway from his talk is about respecting the basics of our profession or activity. In software, it means automated tests, refactoring, basic security (SQL/JS/etc injections, encryption, limiting access etc). For sailing, it meant ensuring equipment is available and working, that you are not multi-tasking and that no task is so small that it can be assumed to be taken care of.</div>
<div><br/></div>
<div><span style="font-size: 18px;"><b>Keynote #4: Learning 3.0 - by Alexandre Magno</b></span></div>
<div><br/></div>
<div>Our Brazilian keynote was delivered by Alê Magno. It has been a long time that Alê has been working on learning. He explained that he is versioning learning methods.</div>
<div>Learning 1.0 is the type of learning in which the knowledge resides in a small amount of people that decide what should be taught to the students and know the correct answer. This is our typical school level education. The structure of knowledge in this case is very much a pyramid in which the top has the knowledge and pushes it to the bottom. The flow of learning is very clear. People take a class and learn then they go back to their jobs and apply those learnings. Work and learning are separate.</div>
<div><br/></div>
<div>Learning 2.0 is the one in which there are experts who know the correct answer but the students pull the information according to their needs. The typical scenario is having consultants that have the answers and that are available to answer the questions. In this case, the structure of knowledge doesn't change much. The flow is slightly different in that learning and working are a little more interwined.</div>
<div><br/></div>
<div>Learning 3.0 differs from the previous ones by not having a concentration of the knowledge. Learning happens by sharing and communicating with other practicioners and colleagues. </div>
<div><br/></div>
Life after Blink - by Romily Cockhttp://blog.hugocorbucci.com/post/life-after-blink-by-romily-cock2015-12-03T03:53:29.424000Z2015-12-07T18:43:00ZHugo Corbucci<div><a href="https://leanpub.com/lifeafterblink">This is a very short 5 chapters book</a> for those of you who have recently purchased or would like to purchase a simple common <a href="https://www.arduino.cc/">Arduino</a> (or Arduino kit).
</div>
<div>All Arduinos come with a short instruction to run the 'blink' program which essentially just blinks a LED (usually one that is embedded in the Arduino board itself) to show that everything is working. From then on, the owner of the Arduino is on their own.</div>
<div>Romily put together this e-book to help you take the next few steps. It goes over 5 little exercises that make you familiar with 5 very common components for the Arduino family: embedded LEDs, external LEDs, buttons, analog inputs for things like ight sensors, and sound emitting devices.</div>
<div><br/></div>
<div>The first two chapters require only an arduino board so you can get started without any other components. The first chapter shows you how to use the Arduino to generate a random text message like the unix program 'fortune' does and display it on your computer. Romily goes fairly slowly and explains every step in the code as the book is suitable for non-programmers. As a programmer, you will likely finish the chapter up quickly.</div>
<div>The second chapter shows us how to blink the embedded LED to generate morse code for anything we might type on our computer. You learn how to control a digital input/output which will be key for the rest of the work.</div>
<div><br/></div>
<div>Chapter 3 goes a little more in depth into controlling multiple digital input/outputs and dealing with binary base and bit operations. We learn to create a nice ripple effect on a series of external LEDs and then change them to display a number in binary.</div>
<div><br/></div>
<div>Chapter 4 brings us knowledge about how to control both buttons as well as a buzzer (or any other component that can generate sounds). We go into a little bit of electronic details about what a button is from an electric perspective and the consequences we have to keep in mind. Following that, we work on connecting the buzzer to the arduino board so that we can have a doorbell ring that plays every time you push the button.</div>
<div><br/></div>
<div>In the last chapter, Romily shows us what a light dependent resistor (LDR) is and how analog inputs can provide us with a less discrete world than digital (ON or OFF). Using the LDR and some LEDs, we build a simple system that shows how light (or dark) it is in the room the sensor is in by a scale of LEDs.</div>
<div><br/></div>
<div>The e-book is a great way to get started with Arduinos even if you're not a techie. If you buy one of the full fledged kits that many arduino vendors offer, you'll likely receive an instruction manual that will cover the usage of many of the components Romily talks about but if you're really trying to get a grasp of it, Romily's book requires very little investment in both time and money to get a very good sense of how to have fun with an Arduino.</div>
Developing for iOS - part 1http://blog.hugocorbucci.com/post/developing-for-ios-part-12015-12-03T03:53:55.356000Z2015-12-03T18:11:00ZHugo Corbucci<div>In the last few months, for multiple reasons, I was drawn into developing a few mobile applications for iOS. I wanted to share a bit of my learnings and the choices I've made when it comes to it. The first one has to be language: Objective-C or Swift.</div>
<div><br/></div>
<div>Well, I tried Objective-C. I did. For about 30 minutes. By then, I had to create 8 files, 4 headers and 4 implementations and I was trying to shape up what my interfaces would look like so I had to keep all of them open as I changed my mind. That was enough for me to give up and move to Swift.</div>
<div><br/></div>
<div>Swift itself, the language, is actually pretty nice. It's an object oriented language with strong functional programming paradigms. It maintains many of it's inline-parameter-calls features that Objective-C copied from Smalltalk but added an important distinction between variables and 'invariables' (or constants declared with 'let' instead of 'var'). It also approaches the, now traditional, segmentation-fault/null-pointer-exception/unknown-method-in-nil issues with an interesting usage of the ! or ? symbols. A variable that can be nil HAS to be declared of its type with either a ! or a ? at the end (ex: UIButton! or Product?).</div>
<div>Swift also 'allows for multiple inheritance' (but not really).</div>
<div><br/></div>
<div>The dreadful part is XCode. The imposed Apple IDE has been improving over time but it is still painful to use with Swift. Errors that don't exist, compilation times that vary, bad (or no) assistance for method invokation and the list goes on. I find myself typing the majority of the code without any sort of IDE help and common refactoring operations are still not very well tuned. The strong typing and inferring capabilities of the language get squished under the lack of help from the IDE.</div>
<div><br/></div>
<div>In the middle, many cocoa and ios libraries are still lacking Objective-C to Swift bridges that allow you to use them from Swift code. You can usually go around it by hooking some Objective-C manually crafted bridging code but it's likely that you're going to have to change that in the future. The language itself is also changing a bit (and Swift 2.0 is now available) so you have to be ready to upgrade your applications.</div>
<div><br/></div>
<div>Overall, I like the language. The IDE is very much behind what the best IDEs out-there can offer for top level languages. Apple is likely going to keep investing in XCode to make Swift one of it's top level languages for the IDE but it's not there yet. The libraries, bridges and upgrades will likely stabilize in the near future so I wouldn't worry too much about that. Plus, specifically for iOS devices, Apple has done a good job at pushing people to upgrade their applications as frequently as possible (even if releasing new versions is a pain from the provider's perspective).</div>
Claimed - by Sarah Finehttp://blog.hugocorbucci.com/post/claimed-by-sarah-fine2015-11-30T17:20:57.724000Z2015-11-30T17:14:00ZHugo Corbucci<div>The sequence from <a href="http://blog.hugocorbucci.com/post/marked-the-servants-of-fate-book-1-by-sarah-fine">Marked</a> follows a very similar style and story line. Marked had focused on Eli and Cacy and their growing romance. Eli being a new firefighter/rescuer in Boston and Cacy Ferry, the daughter of the most powerful man in Boston and his co-worker.</div>
<div>Our focus this time is on Galena, Eli's sister, and Chief Declan Ferry, Eli's boss and Cacy's brother. Galena is leading one of the most important researches in biotech for mankind and such position made her an important target for both Keres (dead humans kept alive by Jason Moros whose mission is to kill people who have been marked to die) and Ferrys (immortal humans charged of sending recently dead souls to heaven or hell according to the actions of their life). With Eli as a Ker, Moros swearing to protect Galena and some of the Ferry family on her side, she tries to continue her work and find a cure to the mutating disease that has been killing so many humans.</div>
<div><br/></div>
<div>As with Marked, Sarah Fine takes us on alternating chapters that follow either Galena or Declan as Galena struggles to overcome her past while falling for Declan and he tries to protect her from anybody who wishes her harm. It turns out, it won't be easy for either of them and the book takes us on a journey filled with explosions, some quite erotic scenes, attempted murders, memories, treason, attacks, escapes and a very complicated net of events that make it very hard to trust anyone.</div>
<div><br/></div>
<div>As with the first book, the 37 chapters of this one go by really fast. Read the first book if you haven't and enjoy that you can read this one right after. The balance of romance, action and politics keeps the reader involved in many events and trying to figure out who is doing what and how Dec and Galena will escape it.</div>
<div><br/></div>
<div>The third and last part of the trilogy called Fathed is supposed to come out in December and I would guess that we will focus on Jason Moros and Aislin Ferry as they try to ensure their respective reigns are in order and functioning under the threat of one or many of Moros' sisters.</div>
Building Micro services - by Sam Newmanhttp://blog.hugocorbucci.com/post/building-micro-services-by-sam-newman2015-11-02T17:52:13.943000Z2015-11-02T18:00:00ZHugo Corbucci<div><a href="http://shop.oreilly.com/product/0636920033158.do">This book</a> provides a great overview of what are micro-services, how they came to be, the complications and advantages that come from designing your systems with micro-services.
</div>
<div>Sam starts by providing an overview of micro-service architectures. Ease of change/upgrade, composability, polyglot environment, scalability and many others are some advantages that come with it. However, a micro-service architecture also brings a lot of extra work and complications such as logging aggregation, deploy automation, service orchestration, service compatibility and a few others.</div>
<div>He moves on to explain how various systems evolved since the late 1990s. Many of those systems were trying to follow an old Service Oriented Architecture (SOA) that was so commonly spread in the Java Enterprise Edition peak with all its Enterprise Java Beans (EJBs). As a consequence of failure, many companies abandoned services in favor of more monolithic solutions. Others slowly evolved towards what is now being called a micro-service architecture.</div>
<div><br/></div>
<div>By chapter 3, Sam starts describing how one would begin a path towards a micro-service architecture. He discusses how services should be shaped along the teachings of Domain Driven Design (DDD) looking for seams in the business. He moves to think about how those seam-shaped services will integrate with each other and with existing legacy projects. From then on, Sam helps us think about what to do with a big monolithic system to slowly get it towards a service architecture that works.</div>
<div><br/></div>
<div>As we get those services spawned, problems with ensuring that our changes can make it safely to where they are needed start showing up. Sam talks about deployment needs and problems. As we feel safe that one individual service is working as expected, how do we find problems that come from interactions between services? The following chapter talks about testing patterns that help us deal with the many moving parts of a micro-service architecture.</div>
<div><br/></div>
<div>Chapter 8 brings us back to the reality of production. Yes we can take many measures to avoid issues but reality is that there will be issues. Finding out which service (if any) is miss behaving is now a lot more challenging. Dealing with monitoring in this architecture is a lot more complicated than with a single monolithic application. The multiple servers, services and indirections make finding which log file has the issue a lot more complicated. And that's assuming the problem is not in the interactions. Along those lines, how can those multiple services handle security concerns? Should users be authenticated on every service? What happens if a malicious users gets access to one server of a given service? Is everything compromised? Chapter 9 helps us think through many of those questions.</div>
<div><br/></div>
<div>The last couple of chapters handle the impacts of micro-services on your company's structure and vice versa. Conway's law has impacts that cannot be ignored and that probably should be considered in the way your system will be designed. Chapter 11 finally talks about scaling micro-services and dealing with failure in an environment of many moving parts.</div>
<div><br/></div>
<div>Finally, Sam wraps it all up on the last chapter (12) giving a good quick summary of what you should be looking for if you're moving in the direction of micro-services and what to avoid.</div>
<div><br/></div>
<div>Overall, the book presents a broad theorethical overview of a micro-service architecture. It hints towards general good practices and things to look for. It is not a recipe book nor does it include detailed code samples of any part needed to build a system with a micro-service architecture. If you want to follow this path, Sam's book is a good (and small) start for what surely will be a lengthy and hard road.</div>
Everything burns - by Vincent Zandrihttp://blog.hugocorbucci.com/post/everything-burns-by-vincent-zandri2015-03-27T15:15:27.264000Z2015-03-28T03:44:00ZHugo Corbucci<div>This <a href="https://www.amazon.com/Everything-Burns-Vincent-Zandri-ebook/dp/B00KYVKDWU">exciting thriller</a> is written under the point of view of Reece “Pieces" Johnston, a fairly famous author who managed to publish a best seller (The Damned) around 8 years prior to the books’ events and has been living out of its fame. The book starts telling us the story of Reece's young childhood and how he lost his mother and two older brothers to a fire and developed a pyromaniac pathology that haunts him since then. Because of it, he has gone through 2 periods in psychological treatment that included shock therapy leaving him with some gaps in memory. His pathology also cost him his marriage just before the second treatment when his wife left him and took his daughter away shortly before he finally wrote and published "The Damned".</div>
<div>For 8 years they were apart and we get back into the history just a couple of months after they get back together. Reece is now famous and well established financially (which was not the case upon the divorce). His pathology is apparently under control. His life is finally aligning from his point of view.</div>
<div><br/></div>
<div>The book lasts around roughly 24 hours that start when his ex-wife, now current girlfriend, Lisa, leaves her house with their daughter and her mother to get eye surgery, leaving him alone with her dog, Frankie with whom Reece has imaginary conversations. But Frankie is not the only one with whom Reece imagines talking to. He also chats frequently with his recently deceased father. Over the following 80 chapters, Reece leads us through his day and his encounters with his wife's ex-boyfriend, David, also an author but who never reached success of whom Reece is amazingly jealous of. Reece's jealousy reignites his burning desire for fire. The text is composed of very few longer chapters and accelerating short chapters that drive the intensity of the actions that take place. Never fully certain that Reece's mind is playing tricks on him and never fully confident on the events, the thriller keeps the reader hooked by quickly alternating possibilities and doubts. Unbeliveable events and weird time loses keep the reader wondering what the hell is actually going on.</div>
<div><br/></div>
<div>A very entretaining novel full of mysteries, revelations and action. The protagonist bounces between good and evil so much that we never know what to expect next. A gran finale full of unexpected turn arounds keeps the reader hooked until the end.</div>
<div>Very enjoyable light read even if it does point out serious issues into mental health treatments, jealousy, hate and love. Although it has a lot of chapters, the majority are very short chapters which makes this book an 8 to 10 hours read which picks up pace as you get through the book. Recommend it for some nice dark but fun story.</div>
Crawl your app/site on build/commithttp://blog.hugocorbucci.com/post/crawl-your-app-site-on-build-commit2016-04-10T05:52:39.574000Z2015-03-17T23:03:00ZHugo Corbucci<p>I’ve recently been working to obtain some publicly available data from a few websites who list many projects. As part of that work, I wrote a small simple HTML crawler that identifies all links in a given html page and navigates to them downloading their HTML content. Writing this crawler took me roughly a day of development in Ruby and is not very interesting in itself.</p>
<p>The results of crawling through a website, however, are very interesting. Crawling is a great way to identify every page in your website that a user navigating can find. It is, in no way, a way to ensure ONLY the pages you want are available. But it can give you valuable information about what information can be publicly accessed, through which route and, in some cases, what information was meant to be accessible but was not.</p>
<p>If you ever had someone report to you that you’re website includes a link that isn’t working, a famous 404, you should definitively be thinking about putting in place a way to run a crawler against your staging environment (or similar) on every commit or, at least, on every deploy to that pre-production environment. Your test could be as simple as:</p>
<pre class="prettyprint lang-ruby"><code class="lang-ruby">
describe Application do
it 'should not include any link that leads to a 404 url' do
expect(Crawler.new(Application.new).errors).to_not include(‘404’)
end
end
</code></pre>
<p>Note that test is an end-to-end test and it will be slow because it exercises all the pages of your web-application. As such, it should not be run before we have some degree of confidence that the application is working. For now, if you can’t afford to write such code or need a compelling argument to spend some time on it, I found <a href="http://www.brokenlinkcheck.com/">a website</a> which offers to run similar crawlers to report dead links. It is not really set up as a service that you could easily integrate into your CI/CD application but clearly there is an opportunity here.</p>Miramont’s Ghost - by Elizabeth Hallhttp://blog.hugocorbucci.com/post/miramonts-ghost-by-elizabeth-hall2015-03-15T23:46:31.953000Z2015-03-13T18:59:00ZHugo Corbucci<div>Elizabeth Hall brings the reader to end of 19th century/early 20th century France and then United states with this <a href="http://www.amazon.com/Miramonts-Ghost-Elizabeth-Hall-ebook/dp/B00LTBWMJ6">sad drama story</a> that follows the life of Adrienne Beaver. A third person narrator brings us to the early years of Adrienne’s life with jumps between important moments of Adrienne’s life on each chapter. She’s a very young girl surrounded by richness in the south of France living in her grand-father’s castle near Beaulieu (not actually the current city of Beaulieu-sur-mer). Happiness and joy surround her and we see her attachment to her grand-father given an absent important diplomat father who cheats on her mother who doesn’t seem to have the guts to react and an authoritative and somewhat absent widow aunt focused on her son’s success in life since her husband’s death.</div>
<div><br/></div>
<div>We discover quickly that Adrienne sees things and quickly that those visions reveal true facts from both far away and close by as well as the near present or past or distant future. However, she doesn’t control her abilities nor does she understand them and, being a child, she just shares her visions openly regardless of their effects on people. It is this way that the Beaulieu community starts gossiping about the unfaithful father of the girl, the affairs of the baker and her unborn sisters’ hair color. Her grand-father is not surprised as we discover that his wife too had a similar ability.</div>
<div><br/></div>
<div>Through that ability, Adrienne attracts her aunt Marie’s animosity by putting at risk her elaborate lies to protect Adrienne’s cousin, her aunt’s son, called Julien, a young man who suddenly abandoned his diplomacy studies in Paris to become a priest in the Americas. As chapters roll, the time passes and Adrienne gets more attached to her grand-father and more distant or angry at her aunt. Adrienne’s mother, Geneviene is more worried about trying to have her husband, Pierre, spend more time with them (and hopefully cease his unfaithful activities) in Beaulieu instead of Paris where he works as a diplomat. The grand-father protects Adrienne from her aunt keeping the peace in the house and letting Lucie, the governess, take care of Adrienne. Life grows easily while Marie is in New Mexico helping Julien at a remote church. Adrienne sees him being poisoned minutes before the family gets announced both of them are back and Julien is sick. Marie’s stressed presence turns everyone’s life a little harder but, with grand-father around, peace is maintained.</div>
<div><br/></div>
<div>Unfortunately, as with all humans, Adrienne’s grand father is old and passes away a few months before Adrienne’s sister, Emelie, is born when Adrienne is 7. In his dying bed, he asks Adrienne to be careful about sharing her visions which causes the little girl to shut down on herself and stop sharing anything to anyone. We follow the rest of her early life through the chapters as more visions cause Adrienne to hate her ability while losing the desire to interact with anyone except her little sister and her governess, Lucie. An invitation from her father to the family and the young little brother Adrienne got a few years before changes her vision of life. She meets Gerard, a young diplomat who works with her father and he falls in love with her dragging her out of her pit of sadness. After a few visits, he proposes and they decide to announce it when her father comes back from a work trip in a couple of weeks.</div>
<div><br/></div>
<div>At this point, Adrienne’s visions increase even more her fear and desire to be away from her aunt. She is worried and she feels Gerard is her only option. The following events change Adrienne’s life and drag the reader into a set of revelations that destroys Adrienne’s life through about 15 chapters. The last 3 chapters switch to focus on Marie and Julien as we discover how the rest of their life evolved.</div>
<div><br/></div>
<div>Although very sad and quite depressing, the book highlights serious issues around nobility, reactions of society against people who are different, complex human relationships and the church. I would not recommend it unless you are cheerful enough to handle a few depressing hours and thing about the many atrocities that individuals can cause while still appearing perfectly normal towards society. In this book, Elizabeth spares nobody from guilt except for the children (in which Adrienne qualifies). Everybody has one or many sins and she shows we are ruled by them. She also presents a world were the worst is your offense, the less likely it is that you’ll be punished for it.</div>
<div>Overall, a good book to think about society, human behaviors and reactions although it is almost guaranteed to make you feel a little worst about everything once you finish.</div>
Automating your tutorials as testshttp://blog.hugocorbucci.com/post/automating-your-tutorials-as-tests2015-03-11T05:59:11.802000Z2015-03-11T05:59:11.802000ZHugo Corbucci<div>A few years back, I was working on <a href="http://www.storytouch.com.br">StoryTouch</a>, a desktop application which was meant to be used by users of an industry niche. As part of the release strategy, our product manager, Paulo Morelli, decided that it would be great to offer <a href="http://www.storytouch.com.br/tutoriais.html">video tutorials</a> explaining the basic usage of the software.</div>
<div><br/></div>
<div>As those tutorials were recorded and we were making fast paced changes to the software, we started bumping into discussions on whether or not we should re-record the videos or avoid major UI changes to the application or just hope users could pick up on the changes we made since the tutorial was recorded.</div>
<div><br/></div>
<div>We decided, back then, that the best thing we could do was to automate as much as we could from the tutorials into end-to-end automated tests named after each of the tutorials. As a result, each time we would change the application layout or interactions, those tests would fail and prompt us to have a conversation with Paulo about whether or not we should keep the change, update the tutorial or let it be knowing that there was a variation.</div>
<div><br/></div>
<div>I was recently explaining what we were doing to a colleague that was very excited about the idea and suggested I blogged about it so here we are. The way those tests were written were also very close to what the narrator of the tutorial was explaining what was happening. In a way, if we could run those tests reading the high level description of the test and recording what each step caused in the UI, we could potentially have been able to generate both the video and the audio for such tutorials upon each build of the software. This would ensure that your tutorials always work and that users can easily find out how to make a certain thing given their software version.</div>
<div><br/></div>
<div>We never quite actually got there. And those tests were a little brittle as most of those high level end-to-end tests tend to be. Nevertheless, I sense that the idea could be a good guideline into deciding what needs to be in your end-to-end high level automated test suite and what probably should be somewhere else. Critical features of your application that customers need to interact with are likely worth a tutorial and have an automated way to warn your development team that user behavior in a very import part of your application will be changed by a given release can avoid many nasty surprises.</div>
<div><br/></div>
<div>Now, in the era of mostly web applications, something like a decorated selenium driver that records interactions, high lights clicks/buttons and text field inputs might be capable of generating the video for tutorials. Text to speech software allied with a good abstraction level in your test’s code may be enough to generate the associated audio.</div>
<div><br/></div>
<div>Unfortunately, the decorated selenium driver is inexistent as far as I know and the text to speech is common but projects with automated tests with a good enough abstraction level are very rare, However, as we evolve our projects and platforms, we might get closer and closer to generating this critical piece of documentation from code alone (a step further along the BDD line).</div>
<div><br/></div>
<div>Please feel free to comment, disagree or agree and point out to any technology you might know that goes into this line.</div>
The Lean Startup - by Eric Rieshttp://blog.hugocorbucci.com/post/the-lean-startup-by-eric-ries2015-03-07T20:31:00.461000Z2015-03-07T20:31:00.461000ZHugo Corbucci<div>This <a href="http://www.amazon.com/Lean-Startup-Innovation-Successful-Businesses-ebook/dp/B004J4XGN6">book</a> has now become a classical for any person trying to start a company that isn’t going to replicate an established business. It may be a product (software or hardware) or a new service. So long as what you’re going to start isn’t just replicating an established and well understood business, you should read this book. The fact that it is associated to the start up world of silicon valley is an “unfortunate" association that excludes many businesses that could benefit from multiple ideas in the book.</div>
<div><br/></div>
<div>Eric starts by debunking the myth that start ups are about getting brilliant energetic young people to work in their garage having the right idea at the right moment and magically obtaining success. He points out that to make a start up work, one needs management. Not the traditional management that one usually finds in common large corporations. He provides his own example at IMVU, a company he founded and grew with three other co-founders. IMVU will be used largely throughout the book as a reference and example for many of Eric’s arguments. His main short point is that one has to try things ago and get feedback from customers to build something meaningful. Planning and hiding your product only increases the risk it doesn’t solve anybody’s problems.</div>
<div><br/></div>
<div>He points out five principles for the Lean Startup method:</div>
<ol>
<li><b>Entrepreneurs are everywhere.</b> This includes the stereotypical garage but also large organizations, governments and any other group of people who works at “a human institution designed to create new products and services under conditions of extreme uncertainty".</li>
<li><b>Entrepreneurship is management.</b> One has to manage the risks and uncertainties by validating and testing assumptions and deciding based on those results (not vanity metrics which he will explain later) what course of action to follow.</li>
<li><b>Validated learning.</b> Startups are about learning how to build a sustainable business with scientifically valid approaches.</li>
<li><b>Build-Measure-Learn</b> loop. This is a re-invention of the <a href="http://en.wikipedia.org/wiki/PDCA">Plan-Do-Check-Act cycle</a> from <a href="http://en.wikipedia.org/wiki/W._Edwards_Deming">Deming</a>.</li>
<li><b>Innovation accounting</b>. The measure part of the Build-Measure-Learn cycle is the tricky one because so many people are used to measuring the wrong thing. Innovation accounting is a proposal to measure better and more useful things and hold people accountable for the results discovered.</li>
</ol>
<div>The rest of the book is divided in three main Parts: Vision, Steer, Accelerate.</div>
<div><br/></div>
<div>In Vision, Eric goes into explaining the origins of the Lean Startup method in Lean Manufacturing, which originated in Japan with <a href="http://en.wikipedia.org/wiki/Taiichi_Ohno">Taiichi Ohno</a> and <a href="http://en.wikipedia.org/wiki/Shigeo_Shingo">Shigeo Shingo</a> from the <a href="http://www.amazon.com/Toyota-Production-System-Beyond-Large-Scale/dp/0915299143">Toyota Production System</a>. Eric makes a metaphor that building a startup is a lot like driving a car in that we have to constantly adjust our direction and speed according to the feedback we get from the road. In his view, most startup plans, however, are laid out like we were going to launch a rocket out of the atmosphere: any slight mistake can destroy the whole thing. This is not the case.</div>
<div>He moves to talk about issues around traditional management and why it doesn’t work in a startup but that doesn’t mean large organizations cannot benefit from it. So long as one has a bit of “a human institution designed to create new products and services under conditions of extreme uncertainty", then there is a startup and there is (or should be) an entrepreneur.</div>
<div>Vision finishes by getting ready for the next part: identifying what it is that needs to be validated and how to effectively validate it. The answer is that we validate learning and, unfortunately, previous attempts to prove that learning have failed and left a bad reputation. Therefore we need to apply a scientific method: experimentation. Establish hypothesis, define a test, execute it, measure the results and validate or invalidate the hypothesis based on those results.</div>
<div>Two basic hypothesis are important:</div>
<ol>
<li><b>Value hypothesis:</b> the product or service delivers value to the customers when they use it</li>
<li><b>Growth hypothesis:</b> customers will discover the product or services in a way that is sustainable for the startup</li>
</ol>
<div><br/></div>
<div>In Steer, we move on to understanding how to go about testing assumptions and iterating. The goal is to minimize the time to go through a full loop of the Build (creates product) - Measure (obtains data) - Learn (generates ideas). To do so, we must identify what Eric calls the <b>leap-of-faith</b> assumptions. Those are the core assumptions that the start up makes and need to be quickly identified and validated if possible. This is the goal of the famous MVP (Minimum Viable Product). The product with the least features that can help you go through a full Build-Measure-Learn loop as quickly as possible and decide whether to persevere or pivot.</div>
<div>Eric moves on to talk about how to define strategies and ideas about analogs and antilogs that both provide us with previous successful examples and previous opposite behaviors. Those can help identify good arguments in favor or against your plan. He also advocates for <i>genchi gambutsu</i>, or “go and see for yourself". A principle from Toyota that calls for everyone on the business to understand their customer deeply.</div>
<div>As we continue Eric reinforces the need to try small simpler versions of your product to get feedback even if it means faking those features with humans behind it. He describes a number of techniques to build MVPs that are unexpected:</div>
<ul>
<li><b>The video MVP:</b> just a video showcasing usability of the product that measures desire from potential customers</li>
<li><b>The concierge MVP:</b> very few users but those get premium treatment from the startup by having people assigned directly to them</li>
<li><b>People behind the curtain MVP:</b> looks like software but really is people answering your questions/requests/demands.</li>
</ul>
<div>He moves on to explain that quality is a variable thing and that “if we do not know who the customer is, we do not know what quality is".</div>
<div>As we continue, we get to one the most interesting parts of the book: innovation accounting. Eric goes in length into what vanity metrics are and how to switch to actionable metrics. The former being metrics that don’t represent the acceleration of growth but rather just the speed of it (which may increase even though it’s really slow). The latter focusing on what is growing and how.</div>
<div>Eric finished the Steer part by addressing the question of whether to persevere on an idea/hypothesis or to pivot and change the approach. He defines the lifespan of a startup and the number of pivots that startup can still make. It can shrink or expand according to investments, spendings and cost of each experiment and should be measured as such. However those decisions should be made based on facts collected from tests and not emotions or feelings from team members. He goes on to describe some types of pivot that can happen:</div>
<ul>
<li><b>Zoom-in pivot:</b> when a feature of the previous product becomes the whole product</li>
<li><b>Zoom-out pivot:</b> when the previous product is considered merely a feature in a bigger product</li>
<li><b>Customer segment pivot:</b> when the customer group changes</li>
<li><b>Customer need pivot:</b> when the problem we were trying to solve is not the main one the customer has</li>
<li><b>Platform pivot:</b> when a startup switches between having a platform with many applications to one application or vice-versa</li>
<li><b>Business Architecture pivot:</b> when a revenue model switches from Business-to-Business (B2B) to consumer products or vice-versa.</li>
<li><b>Value Capture pivot:</b> when the way the startup collects value switches. This can mean how a startup makes money but also what sort of value is captured (money or information or reach or etc)</li>
<li><b>Engine of Growth pivot:</b> when the way a startup spreads out changes (viral, advertising, individual reach, etc)</li>
<li><b>Channel pivot:</b> when the way to reach customers changes</li>
<li><b>Technology pivot:</b> when the way a company provides a solution changes</li>
</ul>
<div><br/></div>
<div>In the last part, we look at how to accelerate. Once startups are working, they will eventually need to grow and Eric argues strongly that size is not something that would get in the way of being Lean. He starts off explaining some of the advantages that small batches present by using some manufacturing examples. Doing the same thing many many times seems intuitively more productive as we assume that we will get better at that one thing quickly. However, keeping small batches allows us to identify problems faster as we go through the whole process. It also allows us to deliver partial results faster. Imagine two tasks that need to be done 10 times each. Each task takes 6 seconds to be completed. If we complete all of task 1 and then all of task 2, we have all finished products in 2 minutes. However, if we are stopped after 1 minute, we cannot deliver anything. If we, on the other hand, complete task 1 then 2 and go back to task 1 and 2 for the next product, even if we consider that we need say 3 seconds to go back, by the end of the first minute, we have completed 4 products and are ready to produce more. Not only that, but it also takes us 6 seconds (and only one unfinished product) to find out in this case if the outcome of task 1 is compatible with task 2. While in the other strategy it takes us 1 minute and 10 unfinished (and potentially wasted) products.</div>
<div>In the case of a Lean Startup, the product is learning (as previously stressed). So the smaller the learning, the faster we will be able to grasp it and react accordingly. In software, this means less changes and more frequent releases. Those gated by a technical <a href="http://en.wikipedia.org/wiki/Andon_%28manufacturing%29">andon cord</a> which allows the system to “stop the line" in case of identified problems.</div>
<div>Large batches incur more planning, more effort for each batch and longer times between batches in exchange for an economy of scale benefit. There are many scenarios in which those benefits come at even more prices. Whenever we talk about anything that perishes over time, there is an obvious cost at leaving things waiting. But even non perishables create larger stocking cost as well as larger initial investments.</div>
<div>With smaller batches, you can also move to a pull system which reacts to events instead of trying to predict them. Smaller stocks reduce the chance (or the quantity at least) that those stocks will become waste. As soon as an item is grabbed from the small stock, it can trigger a pull to the producing side to replenish that one single item.</div>
<div>Eric moves then to the engine of growth which is what he calls the strategy for the startup to grow. He lists 4 common growth powers:</div>
<ul>
<li><b>Word of mouth:</b> customers/users are so proud/excited that they will talk about the product/service to their network and attract new customers</li>
<li><b>Side effect of product usage:</b> certain products/services cause others who are not customers to be exposed to this new product/service. As a result, they may be attracted to become customers/users themselves.</li>
<li><b>Through funded advertising:</b> This is the common traditional one where a company advertises the new product/service in order to obtain new customers. Eric stresses that this is only an engine of growth if the cost of advertising is covered by the company’s revenue and not one off sources such as investment capital.</li>
<li><b>Through repeat purchase or use:</b> Some services or products are built around the idea that the customer will come back and pay again and again and again (like groceries or a subscription).</li>
</ul>
<div>From those, he defined 3 engines of growth:</div>
<ul>
<li><b>The Sticky Engine of Growth:</b> this engine relies on the fact that customers who start using a service/product will stick along with it for a long period of time. Companies modeled around this engine have to watch their attrition and churn rates very closely to understand whether they are actually growing or not. In general, if the rate of new customer acquisition is higher than the rate at which costumers leave, the company will grow.</li>
<li><b>The Viral Engine of Growth:</b> this engine relies on network effects to boost the awareness and adoption of the product or service. Online social networks are a clear example of products that rely on this engine. Success in a viral engine is determined by the viral coefficient which is how many new customers are attracted by an existing customer. Any viral coefficient higher than 1 is a sign of growth. It means that for each customers that we get in the network, he or she will attract at least one more person and a little more. The exponential effect makes it so that any tiny improvement in growing the viral coefficient above 1 is hugely valuable.</li>
<li><b>The Paid Engine of Growth:</b> this engine is all about getting customers to pay to use the product. A healthy paid engine of growth is one where the cost to attract a new customer in is less than the profit generated by that customer over its lifetime as a customer. The variables in this scenario are the cost of attracting new customers and lifetime revenue generated by a customer. We can grow faster by reducing the cost to attract new customers or by increasing the revenue generated by a customer.</li>
</ul>
<div>Although most products and services will likely have a bit of all 3 engines of growth, focusing on a single one allows for a startup to make more conscious decisions about what to validate and which experiments to create. It will also determine the product/market fit since it’ll hint which communities to reach to and how.</div>
<div>Eric follows by explaining that engines of growth, for as good as they are, will eventually run out of power. There are only so many early adopter customers we can reach in a network, only so long that we can hold a customer around and only so much revenue we can make out of a lifetime customer. At some point a company needs to transition to the mainstream customers. And those are different to please than early adopters. Startups should recognize that and be prepared to shift gears and priorities accordingly.</div>
<div>Adapting is the next focus going into why it is important to adapt to the situation the company faces. And, in order to adapt, a company must have a certain level of quality built into the product. Quality is something that changes over time depending on the users of the product/service but not being careful about it can hinder a startups’ ability to react to new findings. One powerful tool to allow a deeper quality and adaptation is known as The Five Whys. It’s a simple process in which for every identified problem, we ask ‘why did this happen?’, write the answer down and then reply to the answer with another ‘why?’ question. Doing so 5 times usually takes us closer to the real root cause of the issue and provides a path to invest in quality spending most efforts at the root of the issue and less at the surfacing one in order to get the best return on investment. However, Eric cautions the readers about the common miss-use of this tool to find “guilty people" for the observed issues. If blame gets into the exercise, the company rapidly develops at culture of mistrust and hiding issues which directly and immediately hinders the company’s ability to react.</div>
<div><br/></div>
<div>Finally, the books closes by address the point of maintaining innovation in mature or large organizations. His suggestions is mainly to recreate a third party startup environment within a company. Secure funds, be granted autonomy and ability to reach out to their needs and demand results. He also cautions people about the problems that this solution causes upon re-absortion of the startup in the larger organization. He suggests than an Innovation Sandbox that allows for any team to run experiments and obtain actionable metrics to drive their development. He also mentions that some people will stick with the product and some people will stick with experimenting and this is normal and should be allowed.</div>
<div>In the epilogue, Eric talks about evolving our companies and products around the scientific method as a way to reduce waste in general and allow us to find a sustainable industry development that better uses our cognitive abilities and natural resources.</div>
<div><br/></div>
<div><span style="font-size: 16px;"><b>My opinion:</b></span></div>
<div>Overall, the book is more valuable than the summaries most people give of it. The one word that the book made widely common is ‘pivot’ which I don’t believe should be nearly as important as other good ideas in the book. The Build-Measure-Learn loop is a nice adaptation of Deming’s PDCA. The idea that a startup lies on two fundamental hypothesis (value and growth) is an awesome basis to get a company started as well. I would definitively recommend the book to anyone thinking about starting a business that wants to suggest a new way of doing things or creating a new product.</div>
The Fire Seekers (The Babel Trilogy Book 1) - by Richard Farrhttp://blog.hugocorbucci.com/post/the-fire-seekers-the-babel-trilogy-book-1-by-richard-farr2015-03-05T08:20:37.707000Z2015-02-28T04:19:00ZHugo Corbucci<div><a href="http://www.amazon.com/Fire-Seekers-Babel-Trilogy-Book-ebook/dp/B00JXOTCFI">The book</a> is a fiction story written in first person narrator called Daniel Calder, "not-as-bright" son of two "geniuses".
</div>
<div>His father, William Calder, is a proeminent linguistic expert in essentially all ancient middle eastern languages, famous professor at the University of Washington. He is what is called a Babbler. Can talk at least 10 different languages and picks new ones up very easily/quickly.</div>
<div>His mother, Iona Maclean, is a brilliant technologist who figured out how to store information in something similar to DNA with capacities about 1000x better than any other storage information solution out there. She founded a company who made them millionaires and decided to retire at the age of 36 to dedicate herself to her son and other personal projects.
<div><br/></div>
<div>We start of knowing little about any of this and just figuring it out by Daniel's description of a trip in Crete when he was 10 years old with his father. It fast forwards quickly to another trip, this time with his mother when he is 17. His father is absent due to a last minute call to join Morag's parents in an escavation that might have found the library of Babel. Morag's mother was very good friends with Iona and Morag was born the same day as Daniel so they consider each other twins. Morag is a young genius who happens to also be a Babbler and admires Daniel's father a lot.</div>
<div><br/></div>
<div>In the 7 years between the trips, Daniel's father had a student called Julius Quinn who suddenly became a sort of priest in a new religion he founded called Seraphim that is growing madly. The idea of the religion is that the Architects (gods) are coming and need us to unlearn our languages and learn only theirs. If we do so, we will transcend into becoming infinite, endless beings, other Architects. The matter upsets Daniel's father, a die hard atheist, while intriguing his mother who his father describes as "still shopping for a religion".</div>
<div><br/></div>
<div>During the trip, an accident happens. But one that Daniel doesn't believe to be caused simply by natural causes. This is when our story truly begins. The rest of the book follows Daniel, Morag and Rosko (Daniel's best friend - also a Babbler) in what becomes a mix of Indiana Jones, Harry Potter (with Daniel being Harry, Morag being Hermione and Rosko being Ron), young super smart secret agents/tomb raiders in voyages around Greece and Eastern Europe teaching the reader about some historical events surrounding the Phaistos Disk, the Babel myth and its origins along with a few more things.</div>
<div><br/></div>
<div>Overall, the book stretches a bit long and too much in terms of those young heroes. Details are often provided in between long conversations about history or details of a specific event or technology. Events are set up very far from their actual pay off and the book turns quickly into a description of this new religion with many mystical events just being the reality. I wasn’t a fan.</div>
<div><br/></div>
<div><br/></div>
</div>Talking with Tech Leads - Hugo's answershttp://blog.hugocorbucci.com/post/talking-with-tech-leads-hugos-answers2015-03-05T08:20:37.752000Z2015-02-26T03:04:00ZHugo Corbucci<h2>What should a Tech Lead focus on and why?</h2>
<p>In my experience as a Tech Lead, my focus is on ensuring the team’s vision and direction for the code matches the product’s vision and direction. As part of that work, I need to have conversations with both the team developing the product as well as the people driving it and anyone else that will live with that product (operations, other teams etc).<br />
Most times, this calls for conversations. Be that in meetings or in corridor conversations or in front of a screen, most of the value I bring is not code producing. I will use the code as means for a better understanding from the team’s perspective and I might tackle a problem that I think is important to help me have other conversations but, end of the day, the majority of the code will come from the rest of the team. As a result, they know better than me what can and cannot be done although, sometimes, the team lacks experience to realize what is possible.</p>
<p>As I see it, this focus is a direct consequence of the team and organization structure. When there are less than 10 people involved, it is not that more expensive to get everyone in a room daily and adjust our shared vision. As the teams grow in size, it becomes unmanageable to use this solution and conversations take too long. We then chose to pay a communication overhead by having a person who bridges the multiple views and brings a vision for the technical aspect of the product/project. That’s the Tech Lead.</p>
<h2>What are the challenges of Tech Leadership?/What has been your most challenging situation and how did you handle it?</h2>
<p>Finding a good balance between sharing time with the dev team, business side and external concerns. Concerns and questions come from everyone and, most of the times, it is very hard to have a good answer right away. It means context switching a lot and being dragged away from conversations a lot. Being able to spend enough time with each party so that everyone shared the same vision about the product/project is probably the most challenging aspect of Tech Leadership.</p>
<p>My most challenging situation was at a client that had 3 major systems, one of which had a team of about 20 developers for whom I was the Tech Lead. One of our releases was a major cross-system release of 3 features that were demanded by our client’s clients. The 3 months that lead to the release stretched me thinner than ever having to balance between the needs of my project, a new team formed for the core of new feature, the 2 other systems tech leads and the business people involved (1 product owner for my system and 1 for the new feature). Trying to keep our technical delivery working as well as help the new team match the architecture we were trying to move to in our system and ensuring none of my teammates was feeling lost and abandoned was very hard.<br />
I’m not sure I handled it as well as someone could but my approach was mostly to put down a list of things that had priorities when it came to my time. My team and the new feature team came first since I needed them to work together. The 2 other tech leads had second priority if they had urgent matters but lower if they wanted to discuss architectural concerns. Business people asking for more features had the lowest priority. We were already stretched and I knew adding more work would be insane unless we were ahead of our plans. As a result, when interruptions would come, I would postpone the conversations according to the priority. Managed to get us all aligned and deployed something that worked although the end result didn’t achieve the architectural goal we had. The following few weeks were a battle to allow us to work on improving that architecture but we managed to get approval and spent the extra time we had forecasted making things better.</p>
<h2>What are your secrets to managing time?</h2>
<p>I need things in my calendar. Not events assigned already but invitations. This way I prioritize things upon accepting or not. Along with that, I hold 4 notes in my evernote:<br />
1. TODOs: list of actions to be completed and dates for completion as well as estimated time to complete. Added any time, reviewed and updated daily.<br />
2. Short term goals: measurable outcomes to be achieved by the end of the month. Updated monthly at the beginning of the month.<br />
3. Medium term goals: measurable outcomes to be achieved in the next quarter. Redone quarterly at the beginning of the quarter and slightly updated monthly.<br />
4. Long term goals: measurable outcomes to be achieved in the next year. Redone yearly and slightly updated quarterly.</p>
<h2>How do you strike the balance between writing code and dealing with other issues?</h2>
<p>I love coding so I mostly have to control myself to not keep on doing it all the time. Most times, there are some dynamics around the teams I’m with that mean certain times are more prone to being interrupted and others are less. I try to make sure I book the uninterrupted time for sitting with the team pairing and getting up to date with implementation problems. The rest of the time will be trying to deal with other issues and concerns.</p>
<h2>Hugo’s question: What decisions fall on the Tech Lead comparing and which fall to the team?</h2>
<p>In my view, ideally, the vast majority of decisions regarding the actual code will be taken by the team. Decisions about architectural concerns (e.g. breaking part of the app into its own app) should be shared between the Tech Lead and the team. The only case where the Tech Lead actually makes a decision is when the team is stuck. If there is no actual consensus between members of the team, the Tech Lead unties the decision.</p>
<h2>Hugo’s background</h2>
<p>Hugo has been a consultant at ThoughtWorks since 2011 and has worked as a Tech Lead for a team of over 30 developers that shrunk to a team of 8 developers. Before ThoughtWorks, he was in a six people team building a brand new software in which everyone was empowered to make architectural decisions. He saw many successful changes as well as some less successful decisions.</p>Talking with Tech Leads - From Novice to Practitioners - by Patrick Kuahttp://blog.hugocorbucci.com/post/talking-with-tech-leads-from-novice-to-practitioners-patrick-kua2015-03-05T08:20:37.764000Z2015-02-20T23:47:00ZHugo Corbucci<div>In <a href="https://leanpub.com/talking-with-tech-leads">this book</a>, Patrick Kua gathered a lot of interviews from multiple people that are or were, at some point, playing the role of Tech Lead in a team.</div>
<div>He starts off by defining what he is calling Tech Lead and how hard it is to tackle the role as most people are not really trained or prepared for it. His definition of Technical Leader is:</div>
<div style="margin-left:40px;">“A leader, responsible for a development team, who spends at least 30 per cent of their time writing code with the team."</div>
<div><br/></div>
<div>The book evolves into a series of interviews grouped in terms of 2 major parts, novice and practitioners.</div>
<div><br/></div>
<div>In the Novice part, Patrick goes into a bit of describing what he sees in common in Tech Leads that are novices in the matter.</div>
<ol>
<li>Looking to the future, not as much the present, of the project/code</li>
<li>Sensing greater responsibility</li>
<li>Guiding the Technical Vision</li>
<li>Less time for writing code</li>
<li>Juggling more context switches</li>
<li>Allowing people to fail</li>
<li>People aspects are hard. Maybe the hardest.</li>
</ol>
<div><br/></div>
<div>The book moves on to display a series of interviews that Patrick conducted with many people. The interview is fairly consistent and asks people to answer:</div>
<ol>
<li>Describe what responsibilities the Tech Lead has and/or Does the role of Tech Lead hold any surprises?</li>
<li>The pros and cons</li>
<li>Any preparation advice?</li>
<li>Where do you go for support?</li>
<li>Has your perspective changed?</li>
<li>The interviewee’s key question and their answer</li>
<li>The interviewee’s background</li>
</ol>
<div><br/></div>
<div>At about 25% of the book, Patrick moves to the Practitioners section. He describes a little bit what he sees in common for practitioner Tech leads:</div>
<ol>
<li><b>People</b></li>
<li style="display:inline;list-style:none;">
<ol>
<li>Remaining technically grounded</li>
<li>Finding and developing good people</li>
<li>Listening to the team</li>
<li>Appreciating individual strengths</li>
</ol>
</li>
<li><b>The Tech of a Tech Lead</b></li>
<li style="display:inline;list-style:none;">
<ol>
<li>Guiding the technical solution</li>
<li>Harmonising team direction</li>
<li>Managing technical risks</li>
<li>Taking a longer-term view</li>
</ol>
</li>
<li><b>Bridging the Business with Tech</b></li>
<li style="display:inline;list-style:none;">
<ol>
<li>Building trust</li>
<li>Finding time for technology</li>
<li>Making technology solutions easy to understand</li>
<li>Influencing planning</li>
<li>Championing business needs</li>
</ol>
</li>
<li><b>You</b></li>
<li style="display:inline;list-style:none;">
<ol>
<li>Adapting to new circumstances</li>
<li>Making yourself redundant</li>
<li>Using your own strengths</li>
</ol>
</li>
</ol>
<div><br/></div>
<div>And follows a similar interview style approach for the rest:</div>
<ol>
<li>What should a Tech Lead focus on and why?</li>
<li>What has been your biggest challenge as a Tech Lead?</li>
<li>Any time-management tips?</li>
<li>How do you strike the right balance between writing code and dealing with other issues?</li>
<li>The interviewee’s question and their answer</li>
<li>The interviewee’s background</li>
</ol>
<div><br/></div>
<div>Pat finishes the book drawing some conclusions from the interviews and summarizing the learnings.</div>
<div><br/></div>
<div><b><span style="font-size: 16px;">Overall</span></b></div>
<div>The book can get a little tiring due to the interview format being a little repetitive but the content is very reassuring for new tech leads and provides a few insights for those who have been doing the work for a while. In short, I recommend the book if you are thinking about what being a tech lead is, hope to become a tech lead or are a tech lead. If you can pace yourself to read one or two interviews a day, you’d probably spend 5 to 10 minutes a day with the book and be done within the month. Probably better that way than trying to read the whole book in a single shot.</div>Marked (The Servants of Fate - Book 1) - by Sarah Finehttp://blog.hugocorbucci.com/post/marked-the-servants-of-fate-book-1-by-sarah-fine2015-03-05T08:20:37.795000Z2015-02-14T01:32:00ZHugo Corbucci<div>A nice <a href="http://www.amazon.com/Marked-Servants-Fate-Book-1-ebook/dp/B00K8EM26S">fiction romance</a> drags the reader through the Romeo and Juliet story of Cacy Ferry and Eli Margolis. Written in third person but with a narrator that alternates the view points of the story between Cacy and Eli’s make the feeling almost like a first person narration with some detachment.</div>
<div>Their surroundings reveal a post semi apocalyptic future in which Kers, ruled by Jason Moros, and Ferrys, under the command of Patrick Ferry, Cacy's father, respectively mark humans fated to death and lead them to heaven or hell in exchange for afterlife coins which enrich them in the human world.</div>
<div><br/></div>
<div>The plot surrounds Eli and Cacy getting to know each other and work together as paramedics. Eli discovering this semi afterlife world in which Kers and Ferrys work and Cacy finding out about his past and present and the role his sister, Galena, has in the world.</div>
<div><br/></div>
<div>Overall a short and entertaining romance with some paranormal activities. An unexpected event by 2/3 of the book marks a clear desire for a second book which the author should publish around April 2015. The epilogue unravels a lot of questions that make you want to read the second book immediately. Entertaining and fun with a couple hot sex scenes, this is a nice ~8 hours book to have a light read.</div>
<div><br/></div>Guns, Germs, and Steel: The Fates of Human Societies - by Jared Diamondhttp://blog.hugocorbucci.com/post/guns-germs-and-steel-the-fates-of-human-societies-jared-diamond2015-03-05T08:20:37.822000Z2015-02-06T19:34:00ZHugo Corbucci<h2>Summary</h2>
<p>This anthropology <a href="http://www.amazon.com/Guns-Germs-Steel-Fates-Societies/dp/0393317552">book</a> goes back in time before mankind was a dominant species and explores how we evolved the way we did.<br />
The book starts off with a question which guides the book's line of thought: Why did Eurasians came to be the dominant human group and not native Americans, New Guineans, Australian Aborigines or SubSaharian groups?</p>
<p>The rest follows as a very summarized historian account of human evolution around each continent trying to identify various different paths each group took and when major breakthroughs happened. The book is divided into four parts that roughly move along human history: pre food production, food production start, growth after food production, the state of the world through Australia, New Guinea, China, Polynesia and Africa.</p>
<p>The main line the author follows is that evolution of human groups was shaped by the environment in which they established themselves. He starts describing how and where early humans distributed themselves throughout the world.<br />
Mankind is supposed to have evolved from 3 ape species in Africa around 7 million years ago. It took 3 million years to achieve an upright position and about 1.5 million years later we reached larger (yet small compared to modern) brain sizes. That's when stone tools started to appear. All of that evolution was restricted to Africa.<br />
It was only about 1 million years ago that we have evidence of humans outside the African continent.<br />
About 500 000 years ago, humans reached the Homo Sapiens stage that we are part of with similar brain sizes and posture. Around that time, humans are in African and all of Eurasia (continental Europe and Asia). No boat technology yet available so Polynesia or Australia are unpopulated. Cold resistant technology was also unavailable so Siberia and the northern parts of Europe and Asian are mostly uninhabited too as well as America (which could have been reachable through the Bering straight in Ice Ages due to lower ocean levels).</p>
<p>Neanderthals appear between 130,000 and 40,000 years ago and show first signs of burying their dead and caring for the sick. Around 50,000 years ago came what the author calls the Great Leap Forward. It is marked by an evolution in the stone tools used along with jewelry and bone tools (which can be shaped more easily than stone). It allows for specialization of tools making them much more efficient at their task and, therefore, making us more productive and effective.</p>
<p>Around 35,000 years ago, evidences are found that humans are found in Polynesia, Australia and New Guinea. Ice Ages could explain how humans got there without watercraft or we simply didn't find early watercraft evidence due to its crudeness. That time period also marks the disappearance of big mammals in Australia and New Guinea. Roughly during that time, humans start appearing in colder areas and, with some disputes, move towards the Americas via Bering Straight.<br />
Around 15,000 years ago, the large mammals in America met the same fate as the ones in Australia and were extinct. Reasons are unclear but the coincidence with human arrival is shocking in both places.</p>
<p>About 13,000 years ago, the world was mostly set when it comes to having humans in the major land areas and a start of a 'race' towards world domination. The author argues that, at that point, Eurasia and Africa were likely to be considered the most likely dominant continents since their human history is much older than that of Australia/New Guinea and Americas.</p>
<p>Those 13,000 years are the focus of the book. The author goes along to show reports of human interactions that we either have written evidence of or have seen ourselves to formulate hypothesis around motivations for archeological evidences found for earlier human groups.<br />
The central point is that food production was the major technological improvement that made Eurasia become the dominant continent. Thanks to its east-west shape, lack of major natural barriers and large landmass, Eurasian populations had an easier time growing, expanding and sharing knowledge. Along with the fact that it is the continent with most large domesticated mammals and that it was home to 5 out of 13 best domesticated plants, it means that food production was born in the Fertile Crescent (now the Arabias) and spread quickly from there to Europe and West Asia. The same food production arose in China with different plants and also spread to the West quickly.</p>
<p>With food production came animal domestication with cattle and horses being the most useful ones due to their ability to plow the land and, therefore, increase the amount of calories generates by a single farmer. Thanks to the food surplus caused by this domestication of plants and animals, farmer populations grew considerably faster than that of hunter-gatherers that previously populated the whole world. With population growth, society stratification started to happen and specialized work is born. This allowed for larger constructions to happen as well as crafts to evolve along with writing and other technologies like metal (bronze, iron and finally steel) tools.<br />
Living with animals and large quantities of humans also fosters disease spread. While those may sound like a disadvantage, they helped develop societies whose individuals were resistant or immune to multiple diseases such as smallpox, measles, influenza, typhus, bubonic plague and others.</p>
<p>With those in hands, Europeans were capable of arriving in 1532 with Pizarro some 100 Spaniards in Cajamarca and capture Atahualpa, Inca emperor, surrounded by 80,000 Inca warriors. And, a few years later, to essentially wipe out the entire Inca population. As the author points out, when Pizarro arrived with his 100 soldiers, the Incas were recovering from an internal war caused by a fight for power between two brothers trying to seize the throne left by their father who died of a "mysterious" disease introduced by Spaniards some 30 years ago. Along with that, Pizarro had steel armors and guns which allowed his soldiers to resist to virtually all attacks by Inca soldiers who only had clubs and quilted armors. Horses also allowed Pizarro's soldiers to outrun as well as out-power the walking or running Inca soldiers. Finally, guns allowed for a few Spaniard soldiers to take down many Inca soldiers from a safe distance.<br />
The result is that Pizarro's 100 soldiers army effectively defeated Atahualpa's 80,000 soldiers army while being in foreign territory in a matter of minutes or hours. Guns, germs and steel being the direct causes for the Inca's defeat. Society's structure, religion, and watercraft technologies being the indirect ones.</p>
<p>The author argues that all of those reasons, both direct and indirect, are outcomes of food production evolution. The book provides many "isolated" historical events that support the logical thought to reach this conclusion. It shows how repeated societies encountered similar fates when in similar situations regardless of 'race'.</p>
<p>One point that may not be very clear due to short summary is the fate of Africa (which also reflects in the fate of America). As said, America and Australia/New Guinea didn't host any large domesticated mammals to allow for better food production. Africa, however, is known to be the land of large mammals. It also benefits from two very commonly explored paths to Eurasian (the Gibraltar straight and the middle eastern region). One major difference between Africa (and America) with Eurasia is its north-south distribution. North-South axis means that the continent is subject to very different climate types and that moving plants throughout the continent is much harder than trying to move them along a east-west axis with similar climate conditions. This also impacted how America had a very hard time spreading food production (which arose in possibly 3 different locations in Americas). Africa also suffered from being divided by the Sahara desert and being home to both summer rains and winter rains regions which greatly affect plant development. As a result, food production in Sub-Saharan Africa developed summer rains crops which were unsuitable for winter rains regions common in Eurasia. As a result, African populations in the very South of Africa remained hunter-gatherers until the arrival of European boats in Cape of Good Hope with European winter-rains enabled crops. Thanks to such, Europeans had a stronghold for Sub-Saharan African conquest when facing food productive populations that, although less technologically advanced, still posed serious resistance through germs (yellow fever mainly) and iron tools.</p>
<p>Australia is, by itself, a case of study due to its isolation and inhospitable nature for crops production. The virtual disappearance of Australian Aborigines upon European arrival is very much due to the same factors as in the Americas. Germs wiped out the vast majority of the Aborigine population and guns under European hands did the rest. The lack of societal organization in Aborigines stopped them from even having a chance to resist. The same didn't happen in food producing New Guinea which managed to survive and still maintain a certain majority even though their lack of steel and guns didn't stop Eurasians from becoming mostly dominant.</p>
<p>The author goes into great details for all continents and provides very good accounts into continent interactions as well as human movements. The reasoning as well as archeological, linguistic and historical evidences are presented in great lengths and details. The epilogue touches on how those are part of a scientific method for what the author calls historical sciences, i.e., sciences that depend on time/evolution such as evolutionary biology, climatology, ecology, geology and others. It also looks at other unanswered questions about other factors that influenced history. Specifically an interesting one about China and Europe's contrasts with unity and disunity and the benefits and issues that arise from each.</p>
<p>The second edition of the book brings and extra chapter about Japan and its history which is very interesting. Japan is unique in that archeological evidences and linguistic evidences seem to be conflicting as to how Japanese people became who they are today. A long lasting animosity between Korea and Japan may be clouding some evidences but it is very much worth learning more about it.</p>
<p>Finally, the author concludes with some afterwords into where research as gone in the years after original publications and where it can still go. Nothing that noticeable here.</p>
<h2>My thoughts</h2>
<p>Overall the book is very long (around 450 pages) but covers a great deal into human evolution. It explains a lot about current politics in the world as well as our current society organization. The rationale in the book is a lot more systematic than usual anthropology or history books.</p>
<p>The author is, however, biased when it comes to analyzing what is "better" for humans. There is an obvious assumption that current power lies in the countries that have adopted a western European "lifestyle" with capitalism and exploitation of poorer groups as a technology, innovation and power source. Although he does present historical evidences that show that this lifestyle can provide such results, there is little account to other life styles inability to provide the same results or even the lack of failures from this style to provide the same results (as faced by many European populated or dominated societies in the New World or Africa).</p>
<p>I still recommend the book to anyone interested in human society and its evolution. It provides great understanding into our current world's shape as well as decisions being made everywhere to both maintain the current status or to try to become more similar to the powers that arose in the 20th century.</p>Javascript heavy projectshttp://blog.hugocorbucci.com/post/javascript-heavy-projects2015-03-05T08:20:37.830000Z2015-02-04T18:39:00ZHugo Corbucci<div>I’ve recently started a <a href="https://github.com/espaco-guerra">project</a> which will include a <a href="https://github.com/espaco-guerra/engine-server">clojure service</a>, an <a href="https://github.com/espaco-guerra/android">Android client</a>, an <a href="https://github.com/espaco-guerra/ios">iOS client</a> and a <a href="https://github.com/espaco-guerra/web">rails website</a> which will do a bunch of the user management but also provide a Javascript client to the clojure service. I started imagining I would just build the Javascript client inside the rails application but realized all of the rails environment actually distracts a lot from working on the Javascript itself and gets in the way of trying to structure a full fledged Javascript application.</div>
<div><br/></div>
<div>I decided then to start a pure Javascript project. Decided to go with <a href="https://www.npmjs.com/">NPM</a> (therefore <a href="http://nodejs.org/">NodeJS</a>) to manage packages needed for development and production, <a href="http://bower.io/">Bower</a> to obtain javascript libraries used in runtime, <a href="http://gruntjs.com/">Grunt</a> to automate scripts and tests with <a href="http://mochajs.org/">Mocha</a>, <a href="http://chaijs.com/">Chai</a> for assertions and <a href="https://github.com/gotwarlost/istanbul">Istanbul</a> for coverage.</div>
<div><br/></div>
<div>This may sound like a lot but it allowed me to get a base project that could:</div>
<ul>
<li>Run tests as soon as my files changes (using <a href="http://phantomjs.org/">PhantomJS</a> to not open a browser).</li>
<li>Compile all my JS files into a single file to improve download/cache.</li>
<li>Minify that file for production usage.</li>
<li>Provide me with coverage information (and a badge for the project thanks to <a href="https://codeclimate.com/">code climate</a>).</li>
<li>Provide me with dependency tracking (thanks to <a href="https://david-dm.org/">David</a>).</li>
<li>Run tests in the cloud against multiple browsers and multiple versions of browsers and operating systems thanks to <a href="https://saucelabs.com/">Saucelabs</a> (and a nice badge showing me it all worked).</li>
<li>Provide me with a Continuous Delivery (actually Continuous Deployment) thanks to <a href="https://snap-ci.com/">Snap-CI</a>.</li>
</ul>
<div><br/></div>
<div>Having all of that, my workflow is pretty simple:</div>
<ol>
<li>I start my test watcher with "<span style="font-family: 'Courier New';">grunt watch</span>"</li>
<li>Make the changes I want in my tests</li>
<li>Get a nice failure notification (if I know what I’m doing)</li>
<li>Fix my production code</li>
<li>Get a nice success notification (if I did it write)</li>
<li>Repeat 3 to 5 as many times as needed</li>
<li>Commit and push the changes when happy</li>
<li>Get a nice RSS feed (thanks to Snap) telling me everything was fine (or a failure email when I break the build) and my project's <a href="https://pages.github.com/">Github page</a> has the <a href="http://espaco-guerra.github.io/js/">latest valid (passed the build) version of the JS script</a> minified available.</li>
</ol>
<div><br/></div>
<div>Overall, the whole experience was quite nice. Thanks to NodeJS, developing Javascript only application is a lot more fun and doesn’t need you to keep a browser open at all times refreshing. It is also possible to write automated tests for fine grained non-client facing code making it so that you feel a lot more confident about the quality of your code. It also helps you enforce DOM isolation.</div>
<div><br/></div>
<div>Although documentation is not very good for most projects and there are a TON of different options of libraries that live and die daily, the Javascript world is finally getting some more mature and developing Javascript applications can no longer be a side thing.</div>Reality is Broken - Why Games Make Us Better and How They Can Change the World - by Jane McGonigalhttp://blog.hugocorbucci.com/post/reality-is-broken-why-games-make-us-better-and-how-they-can-change-the-world-jane-mcgonigal2015-03-05T08:20:37.851000Z2015-01-30T09:01:00ZHugo Corbucci<div><div style="font-size: 15px;"><b>Book summary:</b></div></div>
<a href="http://www.amazon.com/Reality-Broken-Games-Better-Change-ebook/dp/B004G8Q1Q4">The book</a> starts by describing some principles that describe what a good game has/does. Jane summarizes it in 4 important points:
<div>
<ol>
<li>A goal: Important to give the player a sense of purpose</li>
<li>Rules: Limitations into how to achieve the goal. The limitations force the player to be creative while looking for solutions.</li>
<li>A feedback system: to help the players learn how they’re doing. It provides motivation to keep playing.</li>
<li>Voluntary participation: one cannot be forced to play a game. By volunteering, it ensures the game lasts while it is pleasurable.</li>
</ol>
She provides examples of different successful games and how they map to those 4 points. Note that the feedback system can be as simple as saying, for chess, “The game is over when the king is taken". Although the system is not very dynamic, it is enough.
</div>
<div>She moves on to explain why gamers feel joy, pleasure, awe or flow and why those feel so much more rewarding then most real life activities. She continues with a discussion about happiness and what are different approaches to try to obtain some. She presents some studies that show that most durable happiness comes from intrinsic rewards, i.e., feelings we provide ourselves such as satisfaction for having completed a puzzle or produced a craft rather than extrinsic rewards which come from the external world such as shopping, drugs or other such activities.</div>
<div>She moves on to explain how we actually desire work so long as it is satisfying and shows as an example World of Warcraft quests which provide us with a clear objective, hints into how to achieve it and a clear reward.</div>
<div>As with all attempts to perform something, we will eventually fail. Jane explains that failing in the real world usually hurts or costs us. Failing in game is, most of the times, fun and safe and allows us to train more and try again. By removing the fear of failure, we can tackle harder tasks.</div>
<div>She continues explaining that we also tend to enjoy more thoroughly games that provide us with a social aspect. The ones in which we are involved with more people and allow us to have social interactions.</div>
<div>Those allow us to face challenges that go beyond our individual capabilities as they leverage the capabilities of the many and group them into very performant, motivated and skilled teams. Those challenges become massive achievements (epics) that players feel extremely proud of since they couldn’t have achieved them alone.</div>
<div><br/></div>
<div>After having discussed the benefits of games to the individuals happiness, Jane moves towards explaining how games can be used to improve reality. She starts by providing a few examples of games that challenge players to take actions in the real world to earn points in the game. Chore Wars awards virtual rewards for performing real chores at home. Thanks to configurable environment for groups of people, the goal is to have chores done. Rules are in place regarding who can get awards and how, players earn points which are clearly shown with a rank to provide a feedback system and each individual signs up on their own (voluntary participation). She explains how Chore Wars has successfully changed the dynamics of her household by sparking a competitive aspect into performing daily tasks.</div>
<div>Adding to this, she moves on to explain how much more motivated and rewarding life is once your achievements are acknowledged publicly and how alternate realities can help provide this feedback.</div>
<div>She then moves on towards using games to do real-world good. Games that mix local interactions and virtual objectives can help create communities or even improve people’s lives by simply making it more interesting for the players. By doing so, such games encourage players to interact with strangers, people they have never seen and probably won’t ever see again. But those interactions can lead to fun, happiness and, some times, relationships that improve everyone's lives.</div>
<div>Jane follows to present researches around how to be happy with simple actions. She lists 3 activities that will, according to the research, ensure you live a happier life:</div>
<div>
<ol>
<li>Practice kindness</li>
<li>Think a little bit about death daily</li>
<li>Dance more</li>
</ol>
All those activities are triggers from our bodies to release biochemicals that make us happy. However, she explains, just knowing about it doesn’t mean we’re going to do it truthfully. She then shows 3 games she created or helped create to encourage performing one of those activities and presents non-scientifical evidence of their success.
</div>
<div><br/></div>
<div>Moving to the next phase, Jane shows a few examples of games that allowed large communities to achieve in unprecedented speed goals that had direct impact in their lives. The first, a game sponsored by The Guardian, asked people to identify expenses from government representatives that looked suspicious. It allowed an investigation in weeks that would otherwise have taken years not to mention the cost reduction. She moves on to explain how Wikipedia’s creation is very much shaped as a game and that this aspect is very important for the most active wikipedia contributors and how researchers have used PlayStation 3’s network to gather help from thousands of players to discover how to fold proteins and help cure cancer.</div>
<div>Those arguments lead her to conclude that using this large collaboration network of players can help us achieve amazing results that would, otherwise, be unreachable. In a sense, the epic challenges we will face in reality can be tackled by groups of players just like the virtual epic challenges that so many games have offered their players.</div>
<div>Continuing on, Jane moves to show that games are currently becoming highly collaborative environments in which even with individual games, there are more and more ways to contribute with other players providing ideas, walk throughs and other helps. Jane then presents a study that says most of the younger generation (born around 1990) spends around 10 000 hours playing games and collaborating before they reach 21 years old. Based on another the well known research, she concludes that most of this generation has the capability of being amazing collaborators as 10 000 hours is a mark of practice needed before becoming really good at something.</div>
<div>Finally, on the last chapter, Jane McGonigal presents a few games targeted at leveraging those collaboration skills, creative minds and myriad of experiences to try to tackle our current real challenges such as world hunger, oil dependency and others.</div>
<div><br/></div>
<div>Her conclusion provides a summary of her 14 fixes for reality and an encouragement to embrace the idea that games are tools to improve our life as well as our perception of reality. The fixes are:</div>
<div>
<ol>
<li>Tackle unnecessary obstacles</li>
<li>Activate extreme positive emotions</li>
<li>Do more satisfying work</li>
<li>Find better hope of success</li>
<li>Strengthen your social connectivity</li>
<li>Immerse yourself in epic scale</li>
<li>Participate wholeheartedly wherever, whenever we can</li>
<li>Seek meaningful rewards for making a better effort</li>
<li>Have more fun with strangers</li>
<li>Invent and adopt new happiness hacks</li>
<li>Contribute to a sustainable engagement economy</li>
<li>Seek out more epic wins</li>
<li>Spend ten thousand hours collaborating</li>
<li>Develop massively multiplayer foresight</li>
</ol>
<div><br/></div>
</div>
<div style="font-size: 15px;"><b>Book review:</b></div>
<div>Jane is obviously deeply convinced by her arguments and ideas but the book does lack some better argumentation. She presents multiple beneficial aspects of playing games regarding joy, awe and other positive emotions such as fiero but she lacks completely to mention the frustrations, anger and irritation that may come from playing a game you care about but fail to complete. The bias is clear towards the beneficial aspects of playing games both towards the personal emotions as well as the social impacts. The argument that games make people feel better and happier is easily buyable if you’re a gamer but the only mention of other side effects Jane cares to mention is that spending too much time playing reduces the positive impacts that playing a game has on you. In short, her description make games sound very much like a happiness drug that can be consumed in moderated amounts.</div>
<div>Once we move on towards how to use the fact that games are very successful to improve the world, Jane does a good job showing many gaming techniques that can help getting people more engaged (even if for only a short to medium amount of time) and feeling better about doing whatever is required of them. The ideas around improving the feedback about how people are doing at their task and avoiding a situation of fear of failure to encourage people to try and be more creative are quite interesting and align with many practices found in software development by the agile movement. The examples around leveraging the power of the crowd in a gameful way to achieve tasks that would otherwise take a huge amount of time is also an awesome inspiration.</div>
<div>As Jane starts that the population we are forming are gamers and will, therefore, have a great potential for collaboration, she overuses the 10 000 hours argument by simply saying that playing 10 000 hours of video games, people are therefore getting great at collaboration regardless of the type of games, their performance or feedback on gaming. It is also widely contested that the 10 000 hours study provides any evidence that those hours are sufficient to become really good at anything. Finally, there is a general bias towards our ability to transform every problem or challenge we face into a rewarding, interesting game or, worst, making everything that is not “gamified" insanely boring and essentially not doable.</div>
<div>There is also a big social aspect that is ignored in all of the argument and book regarding our economic imbalances and cultural differences when it comes to feeling good and rewarding our behaviors positively. The reality fixes themselves I have found less valuable than the understanding of the qualities of a good game and why we feel so good playing them.</div>
<div><br/></div>
<div>Overall, the book is worth reading although it’s not a light read and it doesn’t necessarily present strong arguments all across. The perspective of using certain ideas from games and understanding better what makes individuals more committed is valuable in itself. Thinking about using people’s creativity and time to solve certain real world problems through games is another good tool to have in your belt. I recommended a critic when reading the book and care to ensure any attempt to gamify a problem or solution is well understood and not overly used. This is surely not a silver bullet but it’s also not at all useless so, learn, understand and apply when appropriate.</div>
<div><br/></div>
<div><br/></div>
<div><br/></div>
<div><br/></div>My first Clojure projecthttp://blog.hugocorbucci.com/post/my-first-clojure-project2015-03-05T08:20:37.901000Z2015-01-28T19:25:00ZHugo Corbucci<div>As part of a game I’m working on with a friend from college, we needed a server that could receive and send messages to multiple players taking part of one shared game. My very first idea was to go with <a href="http://rubyonrails.org/">Rails</a> as it is my default framework of choice to start a quick web project with. However, Rails is single threaded and, although there are web servers that will allow you to start up multiple instances of your Rails application to serve multiple concurrent requests, those Rails instances and requests are independent from one another. A consequence for such is that keeping a stream open between client and server consumes an instance in the server side. In our case, that could mean a lot of memory and overhead for a stream that really had very little to do with the logic in the Rails application itself.</div>
<div><br/></div>
<div>As a result, I decided to split the rails project which will serve web pages and manage users, login and a web service in <a href="http://clojure.org/">clojure</a>. The reasoning was that the <a href="http://en.wikipedia.org/wiki/Java_virtual_machine">JVM</a> (Java Virtual Machine) world has been dealing with concurrency for a long time and their web servers are quite performant. The JVM itself is also known for on-the-fly optimizations that make it many times as fast as any other language. Given that, the problem had a very functional feel: given the state of the world and a set of commands from multiple players, determine the next state of the world and stream that to each client. Most used/known current functional languages that run on the JVM are essentially <a href="http://clojure.org/">Clojure</a> and <a href="http://www.scala-lang.org/">Scala</a>. I have previously taken the <a href="https://www.coursera.org/course/progfun">Functional Programming Principles in Scala</a> course by <a href="https://twitter.com/odersky">Martin Odersky</a> on <a href="https://www.coursera.org/">Coursera</a> and wasn’t much of a fan of the Scala syntax and integration with Java. Having heard a lot of good things about Clojure, I decided to give it a try.</div>
<div><br/></div>
<div>Being a <a href="http://en.wikipedia.org/wiki/Lisp_%28programming_language%29">LISP</a>, I expected Clojure to be parenthesis-intensive and prefix based. I was not disappointed. The platform benefits from the many libraries created for the JVM but the most notable clojure one being <a href="http://leiningen.org/">Leiningen</a> (or Lein). It is the dependency management, project configuration and task automation tool for Clojure. It’s fairly simple to use basing itself mostly only on a <a href="https://github.com/espaco-guerra/engine-server/blob/master/project.clj">project.clj</a> file. Having that file, you can easily add multiple dependencies as well as lein plugins to enhance your project as well as the options lein provides you.</div>
<div><br/></div>
<div>By using a few things I managed to get the following:</div>
<ul>
<li>Run tests as soon as my files changes (using <a href="https://github.com/jakemcc/lein-test-refresh">lein-test-refresh</a> plugin and just “<span style="font-family: 'Courier New';">lein test-refresh</span>").</li>
<li>Compile all my clj files into a single JAR that be used standalone (thanks to lein itself with “<span style="font-family: 'Courier New';">lein uberjar</span>").</li>
<li>Provide me with coverage information thanks to <a href="https://github.com/lshift/cloverage/tree/master/lein-cloverage">lein-cloverage</a> with just “<span style="font-family: 'Courier New';">lein cloverage</span>".</li>
<li>Provide me with dependency tracking (thanks to <a href="http://jarkeeper.com/">jarkeeper</a>).</li>
<li>Provide me with a running server that reloads my changes in development immediately with “<span style="font-family: 'Courier New';">DEV=true lein run</span>" (using <a href="http://www.http-kit.org/">http-kit</a> and <a href="https://github.com/weavejester/compojure">composure</a>).</li>
<li>Provide me with a Continuous Delivery (actually Continuous Deployment) thanks to <a href="https://snap-ci.com/">Snap-CI</a> and <a href="https://www.heroku.com/">Heroku</a>.</li>
</ul>
<div><br/></div>
<div>My workflow goes about the usual:</div>
<ol>
<li>Start my test watcher with “<span style="font-family: 'Courier New';">lein test-refresh</span>" and my server with “<span style="font-family: 'Courier New';">DEV=true lein run</span>"</li>
<li>Write a test that fails (and get a nice notification about it)</li>
<li>Write the code to pass the test (and get a nice notification about it)</li>
<li>Repeat that until I’m happy.</li>
<li>Try the result out manually with a browser and JS (to use web sockets)</li>
<li>Commit and push</li>
<li>Receive a nice RSS feed from Snap-CI telling me all went fine and the result is available at <a href="http://espaco-guerra-engine.herokuapp.com/">Heroku</a>.</li>
</ol>
<div><br/></div>
<div>Overall, so far, I’m quite pleased with the experience except for a few things:</div>
<ol>
<li>The lack of structure in building types caught me a little by surprise. Having had most of my functional programming experience in <a href="https://www.haskell.org">Haskell</a>, strong static typing helped me ensure correctness of my data and code. Clojure seems to be a lot more into building your data structures just using lists and maps. When I want to change that structure, it is a lot more annoying to find all the places that are impacted by it. A few friends recommended <a href="https://github.com/Prismatic/schema">schema</a> to ensure the maps/lists are as expected. Haven’t tried yet.</li>
<li>Automated testing libraries are not as many but all of it is pretty obscure when it come to which is recommended. The default one is <a href="http://clojure.github.io/clojure/clojure.test-api.html">clojure-test</a> which feels just like another xUnit library. <a href="https://twitter.com/marick">Brian Marick</a> started <a href="https://github.com/marick/Midje">midje</a> which feels like a mix between BDD, TDD and some mathematical view of functional programming. <a href="http://speclj.com/">speclj</a> is a fully BDD like library. Finally <a href="http://blog.jayfields.com/">Jay Fields</a> started <a href="https://github.com/jaycfields/expectations">expectations</a>. When it comes to choosing one, it goes everywhere. Clojure-test is more common because it’s default but it’s also not the most feature heavy one. Midje seems to be very adopted but there aren’t that many obvious benefits to it. Speclj is slightly less adopted but, although it gives the BDD feeling to the way tests read, it doesn’t add all the benefits <a href="http://rspec.info/">RSpec</a> does. Finally expectations seems to have a lot of feature but is not very much adopted.<br/>
I decided to go with clojure-test on <a href="http://www.leonardoborges.com/writings/">Leonardo Borge</a>’s recommendation. Haven’t regretted it. My tests are fast and simple. Readability is not always great so I need to put in more effort to make my functions more expressive but aside from that, it’s fine. The simple data structure makes it so that pretty much all of my tests are just "<span style="font-family: 'Courier New';">(is (= expected actual))</span>" so it’s not that bad.</li>
<li>Namespacing still isn’t clear to me as a way to ‘hide’/'show’ functions and providing encapsulation. Deep structures also seem to be hard to mimic in that sense. I’m sure this is only my own inexperience as I know there are already at least mid-sized clojure projects out there that have had to deal with it. But, for now, it doesn’t seem the community is addressing that fact a lot.</li>
</ol>
<div><br/></div>
<div>In the end, I don’t regret my choice. My server is very fast and coding is going well. Immutable state and function composition makes it fairly simple to introduce changes and, aside from dealing with data, the whole thing is pretty smooth.</div>Martians, go home - by Frederick Brownhttp://blog.hugocorbucci.com/post/martians-go-home-frederick-brown2015-03-05T08:20:37.943000Z2015-01-23T23:15:00ZHugo Corbucci<div><a href="http://www.amazon.com/Martians-Go-Home-Fredric-Brown-ebook/dp/B00GVFQNS6">Short science fiction story</a> that touches on interesting matters, one of which fairly modern: the loss of privacy.
</div>
<div><br/></div>
<div>Frederick brown presents this novel in 3 parts: the arrival of martians on earth, their stay, their departure. The core is obviously around their stay although both opening and closing present interesting description of human reactions and behaviors.</div>
<div>The book is written from a semi-omniscient narrator that follows mostly the experience of Luke Devereaux, a science fiction writer in mist of a writing crisys. <span style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);">The only restriction to the narrator is that he can only see/present things the humans know or discover. Never from the martians point of view. </span><span style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);">The narrator also jumps to other stories as needed to present certain points but Luke is the only really recurrent character.</span></div>
<div>Martians are little green humanoid forms that all look alike and "kwim" (teletransport) instantaneously wherever they want. They are intangible and cannot touch anything either although they are capable of producing sounds and they are visible. They have all sorts of visions that allow them to ear and see all that they want regardless of the protection.</div>
<div>The story evolves to describe the impacts of such intrusion into human life in a society. Martians are particulary fond of revealing secrets if that can cause any sort of havoc. And they do. Military secrets, personal secrets, hidden desires and all sorts of undisclosed information is shared to anyone that would upset the holder of the information. Husbands, wives, kids, friends, enemies, oppositions. Everybody gets their share.</div>
<div>The story evolves into the impact of such revelations to society. Problems with the entertainment industry, difficulties of any sort of group activity, impacts on sex, psychological issues and then economy downfall as a whole are among the development of the martian presence on Earth.</div>
<div>Finally, the book gets into the departure of the martians and hypothesis about its cause.</div>
<div><br/></div>
<div>The story is obviously meant to be funny although it presents some subjects that are not the most hilarious. Impacts on the loss of privacy, the weakness of the economy and our psychological need for group activities. It’s a lightweight read with interesting perspectives and descriptions. Worth a good couple hours relaxing.</div>Notes on upgrading from Rails 4.1 to 4.2http://blog.hugocorbucci.com/post/notes-on-upgrading-from-rails-4-1-to-4-22015-03-05T08:20:37.950000Z2015-01-21T07:38:00ZHugo Corbucci<p>This one is a fairly easy upgrade although it was a little hard to discover all the issues. The main work was around removing <a href="https://github.com/josevalim/inherited_resources">Inherited Resources</a>.</p>
<p>Here are more detailed notes:</p>
<ul>
<li>All calls to <code>.deliver</code> become <code>.deliver_now</code>. Including in your tests and stubs. If you had any tests that depended on the code block to be executed, you have to call <code>.deliver_now</code> as method execution has been made lazy.</li>
<li>The configuration <code>config.serve_static_assets</code> is now renamed to <code>config.serve_static_files</code> in your <code>application.rb</code> or appropriate environment file.</li>
<li><a href="https://github.com/josevalim/inherited_resources">Inherited Resources</a> is no longer compatible with rails 4.2 (simply due to gem spec constraints but still). Removing it is tedious but not very hard. It’s a matter of changing any <code>actions</code> call in your <code>InheritedResource</code> controllers to actually implement the method. I actually cleaned a lot of filters along with those changes. Overall, I regret having used Inherited Resources in the first place. The laziness of not writing a few simple actions was surely not worth it.</li>
<li>Add the <a href="https://github.com/plataformatec/responders">responders gem</a> to your Gemfile if you used <code>respond_to</code> on class level controller and <code>respond_with</code> within controller actions.</li>
<li><a href="https://github.com/svenfuchs/i18n">I18n</a> was upgraded as part of Rails 4.2. With the upgrade, assigned locales are now enforced to be in the list of available locales. Rails supports this by allow you to configure i18n in the <code>application.rb</code> inside the <code>Current::Application</code> class. Just add <code>config.i18n.available_locales = [:en, :your_locale]</code>.<br />
However, if you are using <a href="https://github.com/alexgb/guard-konacha">Guard-Konacha</a>, it’ll try to load your rails configurations but will not consider this configuration. As a result, you are forced to add <code>I18n.available_locales = [:en, :your_locale]</code> at the top of the application.rb file (and not inside the <code>Current::Application</code> class). Check <a href="https://github.com/alexgb/guard-konacha/issues/31">this issue</a> for more details.</li>
<li><a href="https://github.com/pluginaweek/state_machine">State Machine</a> is broken. More even than in <a href="http://blog.hugocorbucci.com/notes-on-upgrading-from-rails-4.0-to-4.1">Rails 4.1</a>. Now my <code>config/initializers/state_machine.rb</code> is even bigger. I used a version of the code available in <a href="https://gist.github.com/exAspArk/88294f3e53af202428ed">this gist</a>.</li>
<li><a href="https://github.com/thoughtbot/factory_girl">FactoryGirl</a> causes <code>exists</code> to be called on the real <code>ActiveRecord</code> object instead of using <code>.id</code> so you get a warning like: <code>DEPRECATION WARNING: You are passing an instance of ActiveRecord::Base to `exists?`. Please pass the id of the object by calling '.id’</code>.<br />
I just left that one in there and decided to update FactoryGirl when a version higher than 4.5.0 comes out.</li>
<li><a href="https://github.com/justinfrench/formtastic">Formtastic</a> will call <code>column_for_attribute</code> for each input in the form. This can cause the following warning to show up: <code>DEPRECATION WARNING: ‘#column_for_attribute' will return a null object for non-existent columns in Rails 5.</code><br />
<code>Use '#has_attribute?' if you need to check for an attribute's existence.</code><br />
It means some of the attributes in your form is not in your model. This can happen if you use some confirmation (like password_confirmation) or have a helper (like tags separated by comma). Rails used to be fooled if you just created an <code>attr_accessor</code> for that attribute but that trick no longer works. This will need an update in formtastic (probably coming in version 4.x).<br />
I left this warning showing as well in hopes of either moving out of Formtastic or upgrade it when the new version comes out.</li>
</ul>Implementation Patterns - by Kent Beckhttp://blog.hugocorbucci.com/post/implementation-patterns-kent-beck2015-03-05T08:20:37.973000Z2015-01-17T04:12:00ZHugo Corbucci<div>Kent Beck provides on <a href="http://www.amazon.com/Implementation-Patterns-Kent-Beck/dp/0321413091">this book</a> much lower level details into his programming preferences. He presents and discusses a lot of very common programming options and decisions.
</div>
<div>Star<span style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);">ting the book with some explanation into why those small decisions are important in the overall development of any application, Beck presents arguments to justify the care for each decision in te book along with explanations into how to read and understand the book.</span></div>
<div><br/></div>
<div>He moves on to talk about specific implementation patterns around classes. From naming the class to structuring them into packages going through attributes and methods, multiple aspects about a class are covered. The approach is never to label a certain practice negatively but always to present the advantages it brings such as abbreviating names helps improving typing speed as well as "glancing" speed but not necessarily reading speed. And Beck argues quite well that every effort should be directed towards optimizing reading code rather than the other aspects except, in very rare cases, performance.</div>
<div><br/></div>
<div>The one thing that makes me pretty said is his suggestion in favor of fVariableName or lVariableName to differentiate between attributes/fields and local variables. He also defends the IStatus naming to differentiate between an implementation and an interface. Slightly disappointing nowadays.</div>
<div><br/></div>
<div>He moves on to talk about behavior patterns. Mostly methods and chunks of code. Nothing very impressive here. General techniques and some advantages vs disadvantages presented. In the state of impartiality all sorts of techniques are presented with appraisals and negative points.</div>
<div><br/></div>
<div>Moving on to methods, the books gets a little heavier on the Java side since a lot of the details are pretty focused on the way Java is structured. Ignoring those which talk about method signatures, return types and special methods, most of the effort goes around naming and levels of abstraction.</div>
<div><br/></div>
<div>It moves from there into the Java collection framework. The chapter starts by describing all the interfaces and implementations available from a short theoretical stand point and then moves on to a performance comparison of the main implementations. Although informative and educational, the analysis provides little in terms of usage or implementation insights. The books only appendix speaks more about the way the performance measures were taken in what seems to be an odd distraction from the book's main subject.</div>
<div><br/></div>
<div>The book finishes by creating an exceptional case regarding implementation patterns for Framework development. The main point being around the fact that Frameworks are meant to be "consumed" by other programmers to achieve another goal than the one of the framework author. Being so, there are concerns about coupling, release and other concerns that go deeper than just regular application development.</div>
<div><br/></div>
<div>Overall, the book is probably my least favorite Kent Beck book. The discussions are valid but very basic and taking on some practices that are very specific to a certain Java context that feels slightly outdated. For each chapter I caught myself expecting higher level arguments backed by actual code samples but only got slightly low level practices without as much of the valuable judgement side of each implementation. I would recommend the book for students that have reached the end of their first year of programming course and want some arguments around why certain things feel better than others. For people who have lived in a medium size codebase for over a year with a team of what Bob Martin would call Clean Coders, most of the contents of the book are probably very engrained in their mind and little would be valuable from reading the book except for the reference to point colleagues to.</div>
<div><br/></div>Notes on upgrading from Rails 4.0 to 4.1http://blog.hugocorbucci.com/post/notes-on-upgrading-from-rails-4-0-to-4-12015-03-05T08:20:38.076000Z2015-01-14T20:25:00ZHugo Corbucci<p>This upgrade was fairly easy. The thing that will potentially give you more work are tests around ajax requests.</p>
<p>Here are the few detailed notes:</p>
<ul>
<li>ActiveModels now includes a <code>none</code> scope by default. So if you have some <code>none</code> scope defined, just remove their definitions.</li>
<li>The <a href="https://github.com/pluginaweek/state_machine">state machine gem</a> has not been updated for Rails 4.1 yet. Rails 4.1 made private the <code>around_validation</code> method in ActiveModels. Since state machine uses this method to inject its own validations, you need an extension for it. I’ve created a file named <code>config/initializers/state_machine.rb</code> and added the following code:<br />
<code>module StateMachine::Integrations::ActiveModel; public :around_validation; end</code></li>
<li>CFRS is also possible in AJAX request. Because of this AJAX requests are checked against it as well as of Rails 4.1. Therefore, in your tests, <code>get :whatever, :format => ‘js’</code> has to become <code>xhr :get, :whatever, :format => :js</code></li>
</ul>Brazil's dance with the devil - by Dave Zirinhttp://blog.hugocorbucci.com/post/brazils-dance-with-the-devil-dave-zirin2015-03-05T08:20:38.085000Z2015-01-10T01:35:00ZHugo Corbucci<div><a href="http://www.amazon.com/Brazils-Dance-Devil-Olympics-Democracy-ebook/dp/B00IWGQ8G4">Dave Zirin’s book</a> brings his journalistic view around the impacts of hosting the World Cup and the Olympics in Brazil. Dave starts by describing a bit of the reality he found in Brazil during his investigative trip. He moves on to describe some of Brazil's history from the Portuguese colonization to the US imposed dictatorship. With this basis, he goes on to explain Lula’s administration and how it came to be that Brazil was selected for both the World Cup and the Olympics.</div>
<div>In what looks like a pause, Dave dives into the history of soccer in Brazil and two of its iconic figures: Pelé and Garrincha. This evolution through soccer in Brazil helps him get to the way the mega sport events (World Cup and Olympics) are used as political instruments since 1950s. He moves on to summarize some of his observations of most of those events between 2004 and 2014 and the coming 2022 world cup in Qatar.</div>
<div>Going back to Brazil, Dave shares the stories he discovered in Rio about what both events are causing to the poor portion of the population. He finishes by explaining some of the protests shown in 2013 during the Confederation Cup.</div>
<div><br/></div>
<div>Overall, the book is obviously very politically biased against neoliberalism and presents a dirty aspect frequently unobserved of such mega-events. Although some of Dave arguments are not necessarily very strong, there are lots of very factual data and explanations around how and why we should be worried of many of those events. Reading the book is enlightening even if you disagree with Dave’s political view. It is not a very positive perspective but it is a necessary one. Dave presents Brazil as an ‘example’ of many other countries in which the people are being screwed by large corporations in a neocolonialism based on information control and capital concentration. As with many other things, the whole mechanism exists to enrich the rich and let the poor pay with sweat and, many times, blood.</div>
<div><br/></div>
<div>I strongly recommend reading. The book is medium size (210 pages) but can easily be read in a week as the text flows fairly well and the information is interesting. Although there are parts that are focused on soccer, there is really no need to have any passion for the sport to make good use of the information in the book. This is a book about politics and history portrayed behind a ‘soccer’ disguise - quite ironic as it describes a neoliberal tank disguised as ‘sport’ events.</div>Notes on upgrading Rails from 3.2 to 4.0http://blog.hugocorbucci.com/post/notes-on-upgrading-rails-from-3-2-to-4-02015-03-05T08:20:38.107000Z2015-01-07T19:41:00ZHugo Corbucci<p>The upgrade itself is not that hard. The main thing is the change from models protected from mass-assignment to strong parameters in the controllers. The rest is fairly quick and simple.</p>
<p>Here are more detailed notes:</p>
<ul>
<li><strong>Strong parameters:</strong> Use the <a href="https://github.com/rails/strong_parameters">gem</a> in 3.2 and move any attr_accessible out of your models. Ensure you added the <code>config.active_record.whitelist_attributes = false</code> to your application.rb. The work is mostly moving whatever was attr_accessible in a model to the appropriate controller that creates that model using the <code>permit</code> syntax.<br />
All of your mass assignment tests and code disappears. Hopefully your controllers were already doing some checking on valid params. Otherwise, make sure you write loads of tests to transfer your mass assignment restrictions to your controllers.</li>
<li>Tests now have to respect strong parameters requirements so <code>post :create</code> and <code>put :update</code> will no longer work. You’ll have to add valid params in your tests. I recommend just using a <code>let :valid_params { whatever }</code> with RSpec.</li>
<li>Scopes need lambdas instead of plain where clauses. So look for any <code>scope :symbol, where(…)</code> and replace it with <code>scope :symbol, lambda{ where(...) }</code>.</li>
<li>Regular expressions with $ and ^ now show warnings to be replaced by \z and \A respectively.</li>
<li>Old <code>link_to ... :confirm</code> now have to become <code>link_to ..., data: {confirm: …}</code></li>
<li>Model queries that ended with <code>.all</code> or <code>.sum</code> have to become either <code>.load</code> or, mostly, just <code>.to_a</code> to force loading and use arrays instead of the lazy query.</li>
<li>Many application config changes. Going through <code>rake rails:upgrade</code> helps a long way but don’t just let it override your stuff. Ensure you choose diff and verify what should and shouldn’t be overwritten.</li>
<li>Gems that were in an assets group have to move out of it and just be in the main list. You can add <code>:require => false</code> after the gem in your Gemfile if you are worried about memory usage in production (as most assets will be precompiled before production).</li>
<li>Parameter filters have their own initializers now (out of application.rb). The rake task should show you that.</li>
<li>Routes no longer can use <code>match</code>. Replace by <code>get</code>, <code>post</code>, <code>patch</code> or <code>delete</code>.</li>
<li>The validation options <code>:presence => true</code> and <code>:allow_blank => true</code> don’t really play well together anymore. If you require presence, it cannot be blank. Otherwise change your require presence to be conditional (and your allow blank too). Something along the lines of <code>validate :name, :presence => { :if => lambda {|m| model.condition? } }, :allow_blank => { :if => lambda {|m| m.condition?} }</code>.</li>
</ul>The curious incident of the dog in the night-time - by Mark Haddonhttp://blog.hugocorbucci.com/post/the-curious-incident-of-the-dog-in-the-night-time-mark-haddon2015-03-05T08:20:38.113000Z2015-01-02T20:15:00ZHugo Corbucci<div>Beautiful <a href="http://www.amazon.com/Curious-Incident-Dog-Night-time-Childrens-ebook/dp/B000FC1MCS">book</a>. The story of a piece of the narrator, Christopher, life starting the day he his neighbor’s dog, Wellington, is killed. Christopher is a 15 year old autistic boy living in Swindon, UK. He loves puzzles and decides to investigate the murder of Wellington and writes the book to tell the story of the investigation upon suggestion by one of his teachers, Siobhan, which seems to be the only person that truly always understands and can communicate with him. We follow Christopher’s story in chapters numbered after prime numbers as he feel fit to describe. It captivates us in a journey that digresses to the past, to the way Christopher thinks, to his interactions with the world and desires.
</div>
<div><br/></div>
<div>The book is very quick to read (took me roughly 6 or 7 hours to go through all of it) and hooks you up to understand and live Christopher’s life. Although critiques say the book is both fun and sad, I felt very little of those through the book and was only captured in the fascinating mind of this young super good at math boy. There is some sadness in the end as Christopher goes through very challenging times of his life but, in a simplistic way, hope is always present and the reader can never sense a despair and hopelessness from Christopher.</div>
<div><br/></div>
<div>I strongly recommend it as a book to read and rethink life, interactions with human beings and how our mind deals with the world. Not a cheering up but not a depressing book either. A beautiful story with as much reality as you can get in an autistic point of view.</div>ThoughtWorks Antology 2 - by various authorshttp://blog.hugocorbucci.com/post/thoughtworks-antology-2-various-authors2015-03-05T08:20:38.126000Z2014-12-26T19:11:00ZHugo Corbucci<p>The [second of the ThoughtWorks anthology]:(http://www.amazon.com/ThoughtWorks-Anthology-Software-Technology-Innovation/dp/1937785009) about 4 years after the [first one]:(http://blog.hugocorbucci.com/thoughtworks-antology-various-authors). Like the previous one, this one balances between very narrow concrete subjects and more abstract ones which makes the book age very differently depending on the chapter.</p>
<p>The following notes detail each chapter:</p>
<h2>Chapter 1: Introduction - Neal Ford</h2>
<p>Presents why an antology is good and how it is not meant to stay current forever. Also presents some of the chapters to come.</p>
<h1>PART I: Languages</h1>
<h2>Chapter 2: The Most Interesting Languages - Ola Bini</h2>
<p>A newer version of Rebecca Parsons' essay in the first book but less concerrned about the enterprise vision and more about the diversity of concepts. Ola presents more code samples and is a bit more hands on. He presents Clojure, Coffeescript, Erlang, Factor, Fantom, Haskell and Io (note that those are in alphabetical order in here as well a the book so there is no preference in the languages themselves).</p>
<p>The approach touches various programming paradigms for each language emphasys and then provides resources to learn more about each language.<br />
- Clojure touches on its functional aspect (and lisp origins), immutability, java integration and Software Transactional Memory (STM) to allow for parallelization. This is the first of several JVM languages presented. The lisp syntax is also presented positively with appropriate differentiation with scheme.<br />
- Coffeescript is presented as an overlayer of Javascript with numerous syntax improvements that make the code readability much higher. Most focus around basic type creation, list comprehension and creating a class model.<br />
- Erlang represents the old languages that have interesting ideas. Functional aspect as well as immutability are briefly mentioned, some notes about the concept of patn matching and some applications but the most intersting piece is dedicated to the actors system in place in the language.<br />
- Factor is present to break from the main concepts present. Its stack based approach interrupts the dual OO/functional into something that looks like functional programming with a major state environment which is the stack. Obviously there are serious performance gains that can be achieved with such model but the thinking model has to change a lot.<br />
- Fantom shows an approach to bridge the gap between the JVM (Java Virtual Machine) and CLR (Common Language ? - .Net platform). As another layer on top of languages (similar to coffeescript), fantom is presented with the abstraction benefits that allow the code to be valid in both environments and operate in both. Some focus dedicated to the solution regarding generics and the idea that null objects are special instead of normal. It also covers the dynamic side that Fantom allows<br />
- Haskell shows on the pure functional idea. No mentions of Monads although Ola explains that IO is handled in a "different" way that allows the language to treat the fact as a functional aspect of it. Emphasys in the static typing, pattern matching solutions that Haskell presents as well as the powerful type inferrence system available. He closes with the lazy aspect and the power it can have for your software.<br />
- Io is shown as a pure object oriented language. It also presents the prototype based object orientation (although I missed seeing some comment about Javascript and, therefore, Coffeescript also being prototype based). Ola mentions the dynamic side that the model allows as well as the lazy solution that futures allow. There is also some example of the meta-programming allowed in a form that looks very much like Scheme.</p>
<p>The essay is very good. Great descriptions of concepts with practical examples. Obivously nothing is a deep dive but there no promise for such either. Ola concludes that we should all be studying different languages to learn about different ideas and thought paths.</p>
<h2>Chapter 3: Object oriented programming - Objects vs Classes - Aman King</h2>
<p>Aman works on presenting a name for the preference of delegation over inheritance as well as ducktyping over strong typing and other miss conceptions about object oriented modeling.</p>
<p>He starts by explaining what are classes and what are pbjects and t he difference between trying to model systems based on concepts instead of roles. The examples, although good, are not obvious in showing the downside of the first approach. One has to already have faced the problem to see real benefits in the roles approach.<br />
There are also some examples about the problems of utilities class but the samples don't really show the harm that can come from those utilities class nor the cost of those "microtypes".</p>
<p>He then shortly touches on the testability aspect of an object based approach and the use of mocks when designing for objects. Some arguable "wins" presented.</p>
<p>He finally moves into showing some example of object based programming on different languages. Ruby, javacript and groovy are shown for their preference on dynamic objects and mutability that come from that thinking model.<br />
Aman concludes that there are important things that should stay in a class thinking environment for design and compilation time safety but that our systems really deal with running objects in runtime and there are benefits from designing for those.</p>
<h2>Chapter 4: Functional Programming Techniques in Object-Oriented languages - Mark Needham</h2>
<p>Mark touches to specific elements of functional programming that can be applied in most object oriented languages. Mostly map-filter-reduce and non mutability. The advices are simple but very effective. There is also a fair amount of OO modeling warning regarding the pitfalls that diving into a functional mindset can bring to an object oriented system.<br />
Note that the filter image is not correct. It shows a map along with a filter.</p>
<p>The end focuses on using functions as first class citizens of a design system. A sucess and failure function to remove the error handling problems and the ideas of continuations (although the concept is not explained) are the end of the essay. Mark gives good advices but stays on a superficial level. The questions around when to start functional and stop oo and vice versa are not addressed.</p>
<p>Article is a good start for people that never had a functional experience.</p>
<h1>PART II: Testing</h1>
<h2>Chapter 5: Extreme Performance Testing - Alistair Jones & Patrick Kua</h2>
<p>Alistair and Pat present the idea that performance testing be integrated as a regular agile team's responsibility. They show how many of the concepts used for other testing activities can be applied for performance and the downsides from a traditional approach and benefits from the xp approach.</p>
<p>They touch in a lot of simple applications of basic principles but don't dive into how to deal with the problems that arise from trying to teach all the concepts and ideas as well as the values and costs of performance testing by the whole team.</p>
<h2>Chapter 6: Take Your Javascript for a Test-Drive - Brian Blignaut & Luca Grulla</h2>
<p>Brian and Luca show some applications of known patterns into javascript with a simple but effective example. They make the point that javascript usually is consisted of 2 or 3 Javascript systems that are integrated.<br />
- Javascript logic. That's the bit that contains the business logic aout what needs to happen from a busins perspective. Things such as "show an error message if user and password don't match".<br />
- DOM elements/the browser. That's the part that comes from HTML. It shouldnt hold any logic and likely changes as new layouts come out.<br />
- Server side. This is mostly a layer to help you communicate with the back end. This usually consists solely of AJAX calls.</p>
<p>If one follows this pattern for javascript, testing the first group becomes a simple exercise of regular unit test writting. Those tests are now protected from changes in the ajax end points or even from how to trigger a given result. They also should be protected from changes to the DOM.<br />
Now testing the second layer is also a task a lot simpler as there should be no logic other than hooking events and elements together or performing dom/css changes. This is tipically a lot hard to miss when developing since those are the obvious mistakes in a page.</p>
<p>Finally the last part is rarely exercised since it requires essentially a full stack application running to be used and not redundant. In this case, the tests are common integration tests but their failures tend to be easy to catch since they only hold on logic to put the ajax call together.</p>
<p>The article is well layed out and the advices valuable and nicely presented. Recommended for all who have not been writting javascript tests or have been having problems with their js suites.</p>
<h2>Chapter 7: Building better acceptance tests - James Bull</h2>
<p>The essay presents acceptance tests and some ideas to have the most benefit possible with them. The ideas showns are fairly basic and rely heavily on general automated tests good practices. James starts by defining acceptance tests as automated tests that are drive through the user interface, run on the full software stakc, on real integration points and are part of the continuous integration build. He goes on to argues that acceptance tests should be fast, resilient and maintainable and proposes some techniques to achieve each of those goals.</p>
<p>To keep them fasts, James talks about specific problems with selenium and finding dom elements with retry techniques and backoff retry policies. He also touches on paralelising the tests which force an unmentioned feature of test independence and a mentioned one of being able to run subsets of the test suite easily. Along the selenium road, he also talks about hidding the browser driver to allow for uns in multiple browsers.<br />
Regarding resilience, the suggestions range from not depending on html structure to find elements (using ids), using regular data population from other tests and having dedicated separated integration tests for external services.</p>
<p>Finally, regarding maintainability, the main specific element is the page object pattern. James also mentions treating test code as production code, having coherents suites and creating a layer to reduce the contact dependencies with the test framework.</p>
<p>I think my main insatisfaction with the essay is that it conveys very broad and general messages about automated testing good practices but spends many lines to do so. As an extra, I'm also unsure that I agree with some of the arguments presented in favor of the acceptance test as a growing large user facing automated suite.</p>
<p>The essay terminates by suggesting good practices to adopt the ideas shown in the article. Among those: pair programming, test maintenance, story kick off and demos. All of which are general agile practices.</p>
<h1>PART III: Issues in Software Development</h1>
<h2>Chapter 8: Modern Java web applications - Sam Newman</h2>
<p>Sam's essay addresses developers that live in the Java Enterprise Web development work.<br />
He starts off with a chronological summary of this environnments development.<br />
Due to the initial approach coming from desktop development, the first few servers were stateful using servere side session objects that would be referenced to from the client.<br />
To scale such architecture, application containers (such as tomcat, jboss, websphere, etc) had to rely on clustering and replication.</p>
<p>Such features were hard to develop and maintain and had an associated cost to them so stateless servers started growing popular in other languages. To share a session in a stateless server, those server would use browser cookies. Security comes in play since hijacking unencrypted cookies is very easy so secure cookies can be used in addition to regular cookies to store more sensitive data (such as authentication session for money related operations).</p>
<p>We move on then to the idea of containerless web applications for testing and even for regular usage. Now that we have single processed with less replication and clustering involved, being able to handle a certain request load is no longer as simple as adding more hardware. To even avoid getting into the problem, Sam proposes using existing Cache solutions with proper HTTP headers and response codes to enable caching both on browser as well as on CDNs (such as Akamai) or reverse proxies (such Nginx). He continues talking about the segmentation by freshness pattern to allow for page fragment caching or progressive enhancement as another form to allow for partial caching.</p>
<p>He finishes the essay on the post redirect get pattern to avoid double posting problems and bookmarks on weird form submissions.</p>
<p>In general the article shoots in a lot of directions but in a way that seems to encompass a broad amount of knowledge that should be interesting to most developers that are not http/web/java experts.</p>
<h2>Chapter 9: Taming the integration problem - Julio Maia</h2>
<p>Julio's essay addresses the hard problem of integration testing.<br />
He starts off mentioning various problems that come up when trying to set up a proper integrated environment. He goes on to talk about the stubbing solution and the various pitfalls that one can encounter when trying to implement it.</p>
<p>He moves on to build pipelines and how they can help identify if integration test results can or cannot be trusted and how much needs to be worked on if one of them fails. He goes on to mention how monitors can provide a live view of how much integration is healthy or not.</p>
<p>Moving to another topic, the essay approaches the matter of integration contracts and their monitoring and applications towards more dynamic and reliable testing.</p>
<p>Julio finalizes with the necessity to provide a visual representation of metrics collected about integration and its impact to the projects lifecycle.</p>
<p>In general, a good article that might need some more pictures and examples to be meningful for more people. There is also no addressing the fact that many integrated environments do not provide reliable preprod environments and how to handle continuous changes in both sides and avoid production surprisess.</p>
<h2>Chapter 10: Feature toggles in practice - Cosmin Stejerean</h2>
<p>Comin's essay is essentially about feature branches VS features toggles. He starts off by talking about feature branches and their pitfalls. He quickly moves into simple feature toggles with conditionals in the code and their better version with object oriented code. From there into some deviation towards very java/c# specific approaches using dependency injection frameworks and annotations to achieve the same goal of turning a feature on or off in a server side.</p>
<p>He then addresses the problems one might have with static assets (such as css, js, images, etc) having to be available differently according to the condition of the toggle.</p>
<p>Some more digression into the concerns about unexpected release and secrecy revelations to point out that this danger is often a higher management concern.</p>
<p>He moves on to talk about the difference between runtime and built time toggles and their advantages and disadvantages. One being the problem with incompatible dependencies which is very hard to solve in static languages after built time.</p>
<p>Finally, Cosmin briefly mentions the concern about testability of features branch essencially saying that there is no need to qa all combinations but only the ones that are going to be relased. The assumption here that I don't buy is that, with runtime toggles, this argument still applies. The essay ends reminding the reader that feature toggles are not meant to stay in the code forever but rather live a short fe and be cleaned up as soon as possible.</p>
<h2>Chapter 11: Driving innovation into delivery - Marc McNeil</h2>
<p>Marc's essay walks the read throught a process of evolving an idea to the point of delivery. He addresses the concerns about how to handle prioritizing, evolving, shaping and correcting the ideas with various activities from different methodologies.</p>
<p>He starts off talking about collaboration and ensuring common understanding of the idea and the goals. As the idea evolves, Marc moves into how to determine a feature set that is suitable to conquer your future customers and not make them feel upset or frustrated with your product. He goes into the fact that frustration rarely comes from a feature lack but frequently from a poor quality feature.</p>
<p>He suggests learning from others as well as learning from a trusted group of early users that are more willing to work closely with the developing team.</p>
<p>He also talks about putting yourself (and any member of the team) trying to achieve a goal in an area that is not their expertise to develop empathy with the users of the system to be. He talks about personas, insights from everywhere, gathering ideas from all levels and finally moves into estimating works and prioritizing work to be done.</p>
<p>He finishes up recommending to test your ideas and ensure that your can always quickly respond to a new feature requirement or customer change.</p>
<p>The whole essay brings several techniques from the lean and ux worlds along with various agile pratices to move an idea through all the development process needed to transform it into a successful product with a large, loyal and healthy customer base. Recommended to all that are starting into any of the various trends that lead towards building a product.</p>
<h1>PART IV: Data Visualization</h1>
<h2>Chapter 12: A Thousand Words - Farooq Ali</h2>
<p>Farooq brings a much less common subject into the book that opens a whole new set of ideas to explore. His essay is an introduction to the subject of Information Visualization or infovis.<br />
He starts by the problem of presenting the amount of data we are currently faced with. Spreadsheets and tables and most of the tools commons in the enterprise world is not suited to deal with the amount of data that most of our applications and customers generate. The ability to visualize that pletoria of data in matter of seconds is priceless to react appropriately and stay tuned to your customers and keep them happy and excited about your product.</p>
<p>Farooq presents a process very similar to the agile development processes to evolve infovis elements. We start defining a domain task which consist of understanding which information is desired from the data available. Once defined what to present, we move into understanding which tasks we would like the viewer of the graph to realize when looking at the graph. Example are filtering, identifying extremums, correlate and others.<br />
Once we understand what we would like to present and what task we wish the viewers to perform, the infovis designer works on identifying the data abstract that suits the purposes defined. Those can be to have a quantitative view on data (i.e. which has an order and magnitude of variation such as 1 unit vs 5 units vs 100 units), ordinal data (that is has an order but the variation is unknown or irrelevant such as happy vs unhappy) or nominal dara (which has no ordering, just discriminates between different data points).</p>
<p>In hands of the domain task, the task abstraction and the data abstraction, the infovis designer can choose an appropriate visual encoding to portrait the information desired. A 3 stages process helps discovering a good visual encoding: feature extraction, pattern matching and goal directed processing. Feature extraction works in our intuitive and automatic ability to extract information from an image. Things such a proximity, size, length, color intensity, form and enclosure (among others) are processed by our brains with such velocity that we are completely unconcious about it. To leverage this capacity of feature extraction with such speed allows the infovis desginer to capture his audiences attention.</p>
<p>Pattern matching is another one of those amazing abilities our brain has that allows us to identify common things within various elements and, intuitively, create an association between those elements. A lot of attributes that allow us to extract features also help us match patterns. Painting elements the same color or giving them the same form or linking them with a line are very powerful patterns to induce a feeling of associaton between those elements.</p>
<p>Once those two "automatic" processes are performed, we need to switch back to the conscious mind to process more complex elements such as words or numbers.<br />
Farooq moves on to quickly touch how to handle change over time and how it plays with our intuitive abilities. He finalizes the essay mentioning a few tools that help generate infovis graphic elements as well as deciding which ones are more effective for the desired goals.</p>
<p>The article presents the ideas and provides various sources to explore the subject a lot more. If you are already familiar with the techniques and ideas behind infovis, it is probably very basic on the matter. However, if you have merely seen some infovis and never actually tried producing one or failed to do so, this article is a great start in the right path.</p>
<h1>Overall</h1>
<p>In general, the book is, as described by Neal in the first chapter, a wide variety of experience reports, introductory essays and methodology descriptions for very different topics. It is unlikely that the whole book will be all news for any single reader but it is even more unlikely that there is nothing here that a reader will learn going through the book. Use this shorter descriptions of the chapters to identify the chapters that are more interesting to you and dive into the subjects that passion you.</p>In the valley of the kings - by Terrence Holthttp://blog.hugocorbucci.com/post/in-the-valley-of-the-kings-terrence-holt2015-03-05T08:20:38.182000Z2014-12-20T08:00:00ZHugo Corbucci<p>In <a href="http://www.amazon.com/Valley-Kings-Stories-Terrence-Holt-ebook/dp/B002PQ7B5Y">this book</a> composed of multiple short stories, Terrence Holt brings us to both the past and the future around self-discovery and death. Each story is independent and can be read in any order although it gets a little repetitive if reading from start to end in a day.</p>
<p>Here are notes on each story:</p>
<h2>'O Aoyos:</h2>
<p>Description of an epidemic disease related to seeing a word. This word being of any form and shape but affecting all humans that see it drawing them to madness followed by death and visibile by bruises all over their bodies and more proeminantely in the forehead.<br />
Turns out that this fictional story is all about the power of the mind over the body and the power of words of the mind. Written from the viewpoint of a character that is not affected by the epidemic but studies it. Fairly well written with a good rhythm.</p>
<h2>My father's heart:</h2>
<p>Again, written from the view point of a character. In this case, the protagonist owns its father's heart in a jar that stays at home with him. The narratve being around how the object causes violent sentimental reactions to the narrator.<br />
A fairly obvious metaphor about taking care of older relatives that have no autonomy or even concious of their state. The pain and anger coming from not being able to really help but still wanting to care and maintain around. It takes a little while during the story to understand this is the case but once the reader gets it, the subject becomes a lot less interessant and intriguing.</p>
<h2>Charybdis:</h2>
<p>As for all previous stories, this is narrated by the protagonist which turns out to be an astronaut adrift in a powerless spaceship en route to jupiter. The two companions of the protagonist having commited suicide previously and a "mission control" group back in earth trying to keep the narrator alive but without much hope.<br />
A lot of wandering in various delusions and dreams. Some sort of a mystery surrounding a dream which turns out to be a memory of the event that drove the ship to its present state. Too much wandering and not enough substance for the story. Gets fairly boring pretty quickly.</p>
<h2>Aurora:</h2>
<p>This time the narrator is trying to understand who he is, what is driving it and how it turned out to be how it is. A lot of delays to advance the narrative. Many repetitions as the narrator loses memory about the events and has to remember from scratch. Gets very boring and the discovery doesn't fulfill the expectation created around it. Vocabulary used is also very out of context and doesnt build over itself.</p>
<h2>Eurydike:</h2>
<p>First person again. Yet another self discovery story. This time it seems the narrator is an undead ressucitated by a "religious" project. Writing style is a little more dynamic and, therefore, less boring but the overall reported confusion makes it so that there is a lot of going in circles of self discovery. The themes for the author are very repetitive and so is the style.</p>
<h2>In the valley of the kings:</h2>
<p>This is likely the best writing in the book. This time, the narrator is an archeologist in search of a nameless egyptian King. With some clear delusions in both the events and the descriptions, this tale finally has more plot and mistery than the others. Through the nearly 80 pages of narrative, we follow a middle age researcher that made a hidden discovery of an old egyptian bottle indicating the existance of a nameless power which we discover afterwards had always been the researcher's obsession. The rest of the story brings the reader to the researcher's journey to find the tomb of this great nameless king and through his own madness and crimes. A fair amount of unsolved misteries leaves the reader the chance to create its own answers while still providing a thought direction.</p>
<h2>Scylla:</h2>
<p>This time a ship captain loses his ship misteriously due to "the Law". The short story told by the captain presents how his life evolves without his ship, crew and old life. All is attributed to the Law without ever knowing what is it. The only story that has a good perspective shown at the end instead of the dreadful perspective in all others.</p>
<h2>Apocalypse:</h2>
<p>The narrative now follows a character who seems to live in a world where hope is dead. Living with his wife next to a place where "accidents" happen frequently and cars drive off the road, they keep living in this world where most material goods seem to have lost value and people have mostly lost hope even though we never discover why. Slightly more structured text and less delusions although the main character keeps fighting his internal wish to give up and let himself go.</p>
<h2>OVERALL In the valley of the kings:</h2>
<p>Starts well with Aoyos but quickly gets tiring with the following overly mad/delusional/plot-less stories. In those, the author tries too hard to present an "artistic" and "enigmatic" perspective. The style and inflexibility of view points also limits the quality of the stories told. Little attention to descriptions and a heavy focus on human rationale and train of thoughts mainly towards some way of madness.<br />
The story that gives name to the book presents a refreshing read with a structured plot leading the reader into a journey to Egypt and mysteries. The following two short stories give a good end to the book with a "happy" end and a sincere love that holds against the lost of all hope.</p>Thoughtworks antology - by various authorshttp://blog.hugocorbucci.com/post/thoughtworks-antology-various-authors2015-03-05T08:20:38.202000Z2014-12-17T01:01:00ZHugo Corbucci<p><a href="http://www.amazon.com/ThoughtWorks-Anthology-Technology-Innovation-Programmers/dp/193435614X">This anthology</a> marks the first of multiple anthologies that ThoughtWorks published.</p>
<h2>Chapter 2: Last Mile - Roy Singham & Michael Robinson</h2>
<p>Precursor for Continuous Delivery. Including non functional requirements at start of development cycle.<br />
Doesn’t really provides ideas into how to avoid getting slow to release after growth. More into saying that just not pating attention will make it worse.</p>
<h2>Chapter 3: Ruby DSL - Martin Fowler</h2>
<p>Examples of various forms of describing a specific thing. Lacks describing what a DSLs is or exposing trade offs about generalization and specification of the language. Some cool patterns for those that have never written a language.</p>
<h2>Chapter 4: Languages - Rebecca Parsons</h2>
<p>A brief summary of concepts of programming languages. Tries to keep the concepts around more modern languages to talk to existing business. This ends up creating some awkwardness since most modern languages are a big mess of concepts.<br />
The academic approach to start with "pure" languages and move to the mistures seems better.<br />
Good different between imperative and procedural.</p>
<h2>Chapter 5: Polyglot programming - Neal Ford</h2>
<p>A praise to the JVM (and CLR... And .Net) to its ability to support multiple languages. The idea that certain languages are better for certain problems. No mention of the cost and difficulties of maintaining such diverse code bases and the concept mixtures (and mistakes) caused by inexperience with pne or another language.</p>
<h2>Chapter 6: Calystenics - Jeff Bay</h2>
<p>Rules to improve OO code. Very java oriented even if ruby could follow it.<br />
Some of the rules need to improve but still worth the exercise.</p>
<h2>Chapter 7: Iteration manager - Tiffany Lentz</h2>
<p>Description of an IM's responsibilities. Nice.<br />
Lacks a bit of elaboration into why one would not be able to perform this work along with PM.<br />
Also one worrying part is that 'the IM runs the retrospective'. This concentration of responsibility & power is a bit scary.<br />
Finally, there is no mention about how the IM interacts with the PM and that sounds wrong.</p>
<h2>Chapter 8: Radiators - Stelios Pantazopoulos</h2>
<p>Very basic radiator examples with few warning on metrica miss use and miss interpretation. To add to it, the examples provided picture a project with serious problems described as "on track". Not very recommended reading. Need to find a better sugestion for the topic. Chapter also lacka a summary</p>
<h2>Chapter 9: Service contracts/evolution - Ian Robinson</h2>
<p>Basic ideas behind my evolutionary systems talk heavily focused in XML soap interactions. Applicable only in environments where all consumers of the service are "under control". Idea is in general that service contracts should be an aggregation of minimalist consumer contracts.<br />
Json culture seems a lot more into this than xml.</p>
<h2>Chapter 10: Domain annotations - Erik Doernenburg</h2>
<p>Goal here is to implement certain business logic that may not seem 100% natural in the domain object using annotations. I have mixed feelins on this one. It looks to me like the example is not good enough to capture the real motivation behind it. The way it is presented it just looks like a bad way to separate responsibilities between domain objects and persistance details or other business rules that suld be represented in other objects.</p>
<h2>Chapter 11: Ant refactoring - Julian Simpson</h2>
<p>Aged a lot. Very specific to ant. Could have abstracted some ideas.<br />
Some refactorings are a bit confusing.</p>
<h2>Chapter 12: One click deploys - Dave Farley</h2>
<p>Build pipekine description. Addresses the problems and concerns that motivate a build pipeline. Hasnt aged very much. The technical details are easily ignorable and the lesson still applies.<br />
Pretty good piede of advice for those who are yet trying to automate their deployment. If you are already trying then this article offfers little value.</p>
<h2>Chapter 13: Testing in agile projects - Kristan Vingrys</h2>
<p>Very basic article. Talks essentially about the different types of tests., who is responsible for them and when they are executed. It emphasyses a lot automation but doesn't explain the problems that one may find hile trying to automate all. It also doesn't explain how to transition from one style of testing (waterfall) to another.</p>
<h2>Chapter 14: Performance testing - James Bull</h2>
<p>Calls out for more dedication regarding performance testing. Explains the ideal scenario where perf testing happens early on a dedicated environment and points how to downgrade the environment for those tests. Obviously biased article that doesn't talk about the costs associated with performance testing against the benefit it brings. Also doesnt address how to detect, after a test failure, where the bottleneck is and lets that to the developers. Doesnt address profiling or granularity of results.</p>
<h2>Overall:</h2>
<p>The book has somehow aged. Sill has interesting ideas for people who have not been doing agile. Most of the articles are a lot more about what to do and less about how to get there which makes the<br />
whole of it a bit harder.</p>