Showing posts with label productivity. Show all posts
Showing posts with label productivity. Show all posts

Thursday, December 29, 2016

Book review: The Power of Habit

http://charlesduhigg.com/the-power-of-habit/Charles Duhigg, a New York Times reporter, collects stories of building and breaking habits, supporting the thesis that habits form an important part of our lives and that they can make a big difference for better or worse. Both in the case of positive training or learning habits, or in the case of addictions, repeated behavior influences our energy levels, our free time and in the end many of our long-term results at work and in life (we will all go the gym in the new year, right?)

The storytelling style of the book may smell like anecdotal evidence, but it keeps the reader intruigued and entertained long enough the get its message across, without delving into fictional stories. Take the science expressed here with a grain of salt (like you would with Malcom Gladwell): all experiments are real but they may have been cherry-picked to prove a point.

The key take away for me was to think about our habits, try to influence them to stop or reinforce them depending on our second-order desires; for example with the cue-routine-reward framework proposed in the book but ultimately with whatever works for you as habit building and destroying must be very context-specific. Another concept that we find reasonable is ego depletion (willpower as a finite resource that must be renewed), but the jury is still out on whether it is a confirmed and sizable effect, as meta-analysis of hundreds of studies do not agree yet (for good reasons).

From exercising to learning, or from quitting smoking to a Facebook addiction, this self-reflection can have a large impact over our lives. Maybe it should be an habit?

Selected quotes from the book follow:
This process within our brains is a three-step loop. First, there is a cue, a trigger that tells your brain to go into automatic mode and which habit to use. Then there is the routine, which can be physical or mental or emotional. Finally, there is a reward, which helps your brain figure out if this particular loop is worth remembering for the future [...] Every McDonald’s, for instance, looks the same—the company deliberately tries to standardize stores’ architecture and what employees say to customers, so everything is a consistent cue to trigger eating routines.
“Even if you give people better habits, it doesn’t repair why they started drinking in the first place. Eventually they’ll have a bad day, and no new routine is going to make everything seem okay. What can make a difference is believing that they can cope with that stress without alcohol.”
Where should a would-be habit master start? Understanding keystone habits holds the answer to that question: The habits that matter most are the ones that, when they start to shift, dislodge and remake other patterns.
“Small wins are a steady application of a small advantage,” one Cornell professor wrote in 1984. “Once a small win has been accomplished, forces are set in motion that favor another small win.” Small wins fuel transformative changes by leveraging tiny advantages into patterns that convince people that bigger achievements are within reach.
“Sometimes it looks like people with great self-control aren’t working hard—but that’s because they’ve made it automatic”
“By making people use a little bit of their willpower to ignore cookies, we had put them into a state where they were willing to quit much faster,” Muraven told me. “There’s been more than two hundred studies on this idea since then, and they’ve all found the same thing. Willpower isn’t just a skill. It’s a muscle, like the muscles in your arms or legs, and it gets tired as it works harder, so there’s less power left over for other things.”
As people strengthened their willpower muscles in one part of their lives—in the gym, or a money management program—that strength spilled over into what they ate or how hard they worked. Once willpower became stronger, it touched everything.

Wednesday, August 31, 2011

Between Pomodoros

In the Pomodoro Technique, work is timeboxed into interval of 25 minutes. Between two Pomodoros, there is always a small break which lasts up to 5' minutes: here's what I (try as much as possible to) do during the breaks.

A note: this list is valid for short breaks, while they won't fill longer breaks like a 15' one.
  • 10 pushups: easy, fast, move your arms and legs after a long period on the chair. Or 10 squats, 10 exercises; you get the idea...
  • Refill my water glass from other rooms.
  • Check lighting and temperature to make sure there is no glare on the screen, or the windows do not need adjustment.
  • Adjust the chair and the position of the screen or the keyboard. 
  • Go to the bathroom, also for washing teeth or my face.
  • Unpack my bag.
  • Check phone for urgent messages (only urgent ones).
  • Get up and walk around a bit. Sitting too much tires me.
Here's what I don't do:
  • Engage in mental activity, like explicitly solving problems. Although I find that often since my hands cannot use the keyboard my brain starts to work on autopilot on the last Pomodoro's topic.
  • Browse the web. I try to rest my eyes and focus.

Tuesday, July 19, 2011

Hardware metaphors

Computer metaphors do not always work well in real world.

Here's an example of a metaphor that produces good results when transported in life: RAM vs. permanent storage. Each productivity system (e.g. Getting Things Done) worth its salt recognizes that our brains have limited RAM and we cannot keep in mind too many things at once. But we can use what is called an exocortex - an extension to our brain to augment our capabilities - namely, the Internet, but even a sheet of paper where to write our calculations, or diagrams.
One of the uses of the exocortex is storage: a simple paper notepad that is always with you will be able to function as an hard disk, and your brain RAM will be freed and available for other purposes. The point is not only to avoid forgetting an idea or a TODO, but to avoid worrying about forgetting at all.

Here's an example which doesn't work. Real time notifications are more and more embedded in our system; the sources of input are instant messaging system like email and Twitter. Technology does wonder: compare snail mail to an email being delivered in seconds.
Yet we find ourselves avoiding the wonderful technology of real time communications: interruptions are considered a menace for our flow and our Pomodoros. In order to get large batches, I visit GMail only few times a day, and I'm working on lowering this number; I avoid any kind of GMail or Twitter applet in my panel (although they may work for managers: I'm talking about creative work as put in danger by interruptions).
Polling is often a waste of CPU cycles for computers, and in fact they are built from the ground up on an event-based model: hardware interrupts. Yet the model fails miserably when, due to the inability of humans to multitask like a machine.

Thursday, July 07, 2011

The ultimate web 2.0 note-taking tool



It's always with you, because it fits in your pocket. You don't have strange synchronization processes which would eventually overwrite something. It does not require an Internet connection, so it works everywhere free of charge. It does not force you into a textual form or anything, you're free to draw mind maps or graphs.
And it is web 2.0, if you buy it on eBay (not suggested due to shipping costs).

No seriously, leave out the web 2.0 part. The fact is that the information I keep in this notepad has a cycle that goes from written to discarded of some days at maximum: I write on it Google queries I should make, ideas and exercises got from books that I should explore, or titles of articles to write.
Since I do not have to keep these information around for long, there are no disadvantages with respect to a digital form. I'll never write an article on it, but for my reminders works pretty well.

Thursday, May 27, 2010

What to do on weekends

At least, what I do on weekends in relation to software development, university and all my work-related projects and tasks. Feel free to add comments about your lifestyle and what you think of work-life balance: I think I finally found an equilibrium after all these years, without feeling guilty in my free time.

What I do on the weekend (when I have time)
When I have time because weekend is meant for resting, going out, drinking, partying... Still, you sometimes find yourself waking up at 10 AM on Sunday morning or find a free hour before going to a football game. How will this hour be spent?
I usually read books, monstly non-fiction, and articles from feed aggregator that built up until Saturday or Sunday.
I experiment sometimes, or start writing drafts for new articles. And I plan the goals and the required work for the upcoming week.

What I don't do in the weekend
I don't write code in the weekend: I know that even when I feel inspired writing code on Sunday, it would drain my energies for the subsequent week. There is a famous icon of the open source programmer that writes code in his free time, but free time shouldn't be oppressed by a todo list by definition. I schedule my contributions in the workweek, when I can establish a rhythm in my work and process also non-exciting programming tasks.
I never publish original content (something other than a link roundup) for the same reason. Brainstorming or writing a rough draft is simple when you have the inspiration and you want to capture some thoughts, but actually publishing it implies a polishing process (proofreading, formatting, editing...) that is boring to do when you're supposed to rest the mind.
A nice addition to this list now that I have embraced the Pomodoro technique: I never timebox on the weekend. This exclusion of free time from pomodoros is explicitly stated by the inventor of the technique.

As a sidenote, I never check email on purpose after a predetermined hour even in the workdays,or at least try to: now that I'm expecting feedback from eBay sellers I infringe the rule, unfortunately.
Since you wouldn't want to craft an answer to some complex question or start a new project following a late evening email, just don't check the inbox: reading such emails now will only result in worrying over the night. Having a different e-mail for work and life will be useful...

Image from Wikimedia Commons.

Monday, April 05, 2010

How I learned to stop worrying and love new words

Because of the subject of my Bachelor's degree thesis, I am currently busy learning more and more about Java technologies, in particular the OSGi specification and the frameworks that implement it.
In the past, I saw articles about OSGi passing in DZone's feeds, and never cared much about it. It's possible and desiderable to avoid contact with many technologies we are not considering for right now: somehow we have to limit the amount of new information in our self-improvement process to the actually useful fields.
However, the thesis subject (audio and video search) is interesting but it involves a large amount of Java technology, in particular a framework built on top of the OSGi model. Here comes the pain: I did not know what OSGi was at all. Instead of continue worrying about it, I decided to dive into OSGi and I'd like to recall my steps here so that you can decide to take a similar journey on an argument that you are required to know.

Step 1: Wikipedia
Wikipedia is the starting point of most of my researches, even if it is not 100% reliable as every community-crafted content is. Wikipedia took me from an empty word (OSGi) to a definition:
The OSGi framework is a module system and service platform for the Java programming language that implements a complete and dynamic component model, something that does not exist in standalone Java/VM environments.
Moreover, well-written Wikipedia articles have many internal links to related material, both in the page body and in the See also section. Every new term you encounter usually points to its own definition, a scenery that can lead to a tab explosion but also to deep knowledge.

Step 2: define concepts in your own terms
I quickly discovered that OSGi applications are composed of bundles. The bundle term is part of the Ubiquitous Language of OSGi, but I did not know an exact definition. When you are doing a panoramic of a technology, it's useful to start with a good approximation which uses already grasped concepts:
OSGi bundles are particula JARs which includes some metadata files along with the hyerarchically organized .class files that contain the bytecode. Bundles export or import Java packages they respectively provide or require.
This is an approximation, since JARs and bundles do not strictly overlap. But it is a good one and let me abstract away most of the bundle internal organization for a while.

Step 3: resources to learn more
  • Google is often the best friend of a developer (as the GIYF acronym correctly says.) You can look for tutorials, but also for particular frequently asked questions.
  • Books on the subject, particularly if they contain good code samples, are the best road to a deep understanding of the technology. However they may not be the right material if you're only looking for a crash course.
  • YouTube videos are instead highly distilled knowledge, and the equivalent of a crash course. A 1-hour long talk can teach you very much about the assumptions and the usage of a framework like OSGi without effort: you just need to listen to the speaker.
  • also a search on Wikimedia Commons will bring you a lot of diagrams about your preferred technology (example), used throughout all the Wikimedia Foundation wikis.
Step 4: practice
My first practising step was producing an OSGi bundle and deploying it in an OSGi framework. I've done it even before step 3 because I like to get a walking skeleton as soon as possible, but I've gone reviewing my code once I had learned a larger part of the theory. Getting a running example is always a confidence booster however, even if you are copying much of the code without knowing its meaning.

The same learning process is going on for me for other material I'm using in the thesis, such as BPEL and the SMILA framework. While there may be aliens with genetic memories, you shouldn't be afraid of new concepts: everything you know was learnt at some point in your life.

Monday, March 15, 2010

Coffee and programming

A mathematician is a device for turning coffee into theorems. -- (attributed to) Paul Erdos
Coffee is indeed an omnipresent drink in many different science fields - probably for its property of aiding concentration and focus over a short period of time. In the field of software development, just think about the Java platform and programming language, named after a coffee, whose symbol is a cup and certain constructs are called beans. Many programmers declare themselves coffee addicts, and present guides to coffee roasting and brewing.

As you probably now, high consumption of caffeine, which is the principal psychoactive component of coffee, is not very healthy. The reason is the substances in a cup of coffee are derived from coffee beans, and the Coffea plants have been naturally selected to produce hazardous chemicals. Plants generally do not want their seeds to be eaten: while the man-made cultivation, which favors the more productive varieties, dates back to some centuries ago, the natural selection of the Coffea plants has been a continuos process for thousands and thousands of years. That's why roses have spines and poison ivy is... well, a bit poisonous.
The overall effects of a moderate consumption of caffeine, as they have been exposed by scientific studies, are controversial. And the picture cannot be different: there are many types of coffee, also with different serving sizes, and possibly different effects (and side effects). Particular beverages such as tea and Coca Cola contain caffeine, but in a much lower concentration.

My current practice is avoiding influential substances as much as possible. I drink occasionally a cup of tea in the morning, mainly because of the cold season. I did multiple rounds of coffee in the past, but the benefits on concentration (and in recovering from hangovers) were not very significant on me, and I also had to add the side effects on my stomach and my sleep cycle, which is an important variable in my life.
Nearly every morning I see many students come in with hot, tiny espressos made by automatic machines. I guess it's more a placebo than a real help. In fact, they are usually not the most brilliant ones in the classroom, but the ones that sleep less.

Do you drink coffee? What is your idea of its benefits and disadvantages?
 

Image courtesy of Julius Schorzman.

Thursday, March 04, 2010

Why I'm leaving Subversion for Git

I always believed in Subversion's potential and that it would be a wide improvement over the nightmare that was CVS, but I found out that, as Linus says, There is no way to do CVS right.
Subversion is fairly good and it's probably the better centralized version control system on the market, and it's open source. But after my first day of Git real-world usage, I now cannot negate that the distributed model of Git will be superior at last.

For example, in Git, you are not forced to have a remote repository: you can start with your local repository, and commit to it. No need to set up server software if you don't want to, as your machine is already your own server.
After working locally for some time and having done very fast commits as you usually did much more slowly with your remote Subversion server, you can push or pull changesets to other repositories. I was worried about the inherent uncertainty in this process (which branch? Which repository?), but Git tracks the origin of your repository, precisely the common ancestor in the remote branch, which your master branch was forked from. When you start by cloning a remote repository (as it is almost always the case), it will push to that origin. But you can also push to nearly everything, even if there is not a common ancestor.
The converse is true: you can also pull to update your repository from an external one, that may be your point of convergence. Obviously, you can also pull from everywhere, in a local branch if you are not sure to incorporate the changes.

The commit access notion vanishes in Git. You and I typically do not have commit access to major projects such as Zend Framework or Doctrine anyway (ok, I have to Doctrine, but when I come out with a small patch I just put it the bug tracker for a review), and we have only our working copy, having to upload patches to the bug tracker. Multiple versions of those patches. That quickly become not in sync with the current revision of the codebase.
Collaboration between working copies is difficult, as an official branch is needed. Moreover, it's rare that you know a branch is needed ahead of time. If for every feature you started a remote branch, even with Subversion (which has cheap copy-on-write branches) the development would be very slow. So many times you end up working on the trunk and struggling because you cannot break it, and sending patches by email. These problems are described in Linus's talk at Google about Git - which is amusing. When I watched his talk using Subversion really started bugging me; I knew that here was an alternative, and it consisted of mature software since the talk was old, from 2007.
What's the solution then? In Git everyone has his own repository, so you can just pull changes from other people and pushing changes to them. There is no commit access, only a group the lead developer trusts and he will pull from. This group may pull and review from other people, in a hierarchical work flow where a chain of trust is established. For an open source project, Git is worth its weight in gold (which actually I don't know, but it will be surely expressed in hexadecimal.)
You can break your repository if you want, committing all the day without problems, and being able to revert to every commit's revision as if Git were a time machine, and very cheaply (in Subversion you are forced to hit the network to revert to revisions older than the last commit.) When you have fixed your copy after ten, twenty or an hundred commits and all tests are passing, you may finally push. Awesome.

And this was only my first day in Git!

Friday, February 12, 2010

Tuning your Ubuntu machine with command line-fu

Ubuntu is in my opinion the leading Linux distribution because of its extended support for peripherals and large software repositories. Though, the default installation profile can be a bit heavy since it is thought as a catch-all configuration for a general purpose system.
Thus many software developers have the need for lightening the system load and reducing the disk space occupied by the distribution, along with the Ram eaten by daemons. This guide also works with Debian boxes since it is based on the dpkg and apt packaging system and on standard unix tools.

Let's open the hood and start with an example of unrequired packages. If you search packages that match the name ttf*:
dpkg -l ttf* | grep ii
you'll see the list of font packages installed. This collection comprehends Japanese, Korean, Gothic fonts, and so on till Futurama Alien Alphabet. You may want to remove some of them if you do not understand the languages which are written with these fonts.
Note that sometimes you will be asked to remove a package with a seemingly important name, such as ubuntu-standard. These metapackages are simply empty debs that depend on a large set of normal packages; they are meant as a shortcut for installing all those packages in a single shot: the Ubuntu installer simply requests the installation of ubuntu-standard and the apt system works out the details.

Let's try a more radical way to find space to free on the distribution partition:
dpkg-query --show --showformat='${Package}\t${Installed-Size} ${Status}\n' \
    | grep -v deinstall | sort -k 2 -n \
    | awk '{printf "%.1f MB \t %s\n", $2/(1024), $1}' \
    | tail -n 20
When I say that Unix tools are beautiful, now you'll know why.
This commands chain will show you the 20 packages with highest installed size, so that you can remove them with sudo apt-get remove. For example, I removed ubuntu-docs (hundreds of megabytes) and the openoffice Australian thesaurus (I'm not very keen on searching "synonyms" in the other emisphere.)

You may want to install some very small tools to simplify the management of your system:
  • bum is a tool to enable and disable services at the bootstrap (this is actually a graphical tool, if you want you can play with /etc/rc2.d/);
  • deborphan is a command line utility which lists packages that no other .deb depends on. deborphan | grep lib shows the list of libraries that are not used and so can be removed.
Remember to execute these commands periodically:
  • sudo apt-get autoremove removes packages installed to satisfy dependencies that are now useless. For instance if you install the vlc video player and it requires also 100 MB of Qt libraries, if you subsequently remove vlc the libraries are still there. autoremove will delete such packages: if you want to keep some of them, sudo apt-get install package-name will set package-name to manually installed, making you free to execute autoremove on the remaining packages.
  • sudo apt-get clean deletes cached *.deb files which have been downloaded in the past. After a successful installation, there is no need to keep them around.
I hope these tips can help you shrink your distro impact on machine resources. I have a 2 GB root partition on my EeePC, and in my case it is very important to remove packages installed by default that do not have a real use.

Friday, January 22, 2010

Teachers and the value of formal education

Question: is it clever to drive for half an hour and drive back another half hour to listen to a 90 minutes lecture?
If the teacher is worth it, yes. At Politecnico di Milano I found out that very often the professors are not in their position because of some random event. And what is true for school and university professors is usually true for other kinds of teachers, like consultants and coaches.
When I give advice on php applications, I do my best to distill knowledge from my previous experience, like a good teacher would do. The focus in every technical subject is not on giving fish, but in teaching how to fish.

You probably want to improve yourself and your career if you're reading here. So, what a teacher or a mentor gives you in order to become better?
  • interest for the discipline: maybe the most important  job of a professor is stimulating interest and passion about his subject. I am glad that many teachers I encountered during my education left me with a desire to deepen my understanding of computer science. Many did not - maybe I would be a little more knowledgeable on history if I did not become fascinated by it only half the way in high school, because of the way my teacher conducted lessons. The only thing I remember before the year 1000 is that the Roman Empire was formerly a republic.
  • Insights which we could take years to arrive to: the fact that, as engineers, we focus on the technology-independent algorithms is still one of the best lesson I have learnt during this semester. Or let's talk about the importance of conservation laws...
  • Solution to a question in a few seconds as an authoritative source. However, we should not abuse a teacher's time: even the best professor may be wrong or outdated sometimes, and other students have the same right for teacher's time as us.
  • Goals which are adequate to the industry standard. If you are very interested in the discipline, maybe you'll want to expand those goals.
  • And yes, a degree which should be useful when you apply for a job.
And what you invest in a teacher?
  • money: subscription to the high school or university, or fee if he's a private teacher, Agile coach, etc. In Italy nearly all the universities are public and I am in range to go everyday to the best  technical university of the country (this may only be luck); this means that I will graduate debt-free and I am scared by seeing people in US taking a 50,000 or 100,000 dollars loan to cover education expenses. Wouldn't you think that Harvard isn't lucrating on subscriptions? At least MIT created Open Course Ware.
  • Time to schedule and show up at encounters such as lessons and exercises sessions. If you are very familiar with a subject you may skip lessons altogether to save time, but beware of spending more time in catching up with the lessons than the one you saved by skipping them.
  • Will to work hard instead of sleeping all morning.
Courses in database systems, computer science, software engineering... are probably the smartest way to become a qualified, all-round software developer. Today I am going to the last semester lesson at 14:15 CET.

    Tuesday, January 05, 2010

    New Year's resolution (a bit late)

    I think setting smart goals is a good practice in personal and professional development. I decided to share my goals for the solar year 2010 to become accountable for the results I achieve and my potential failures. It's January 5th, but it's better late than ever.
    These are my plans for 2010:
    • first, maintaining this blog with a regular posting schedule throughout all the year. I took a pause during the holidays but I intend to post 5-6 new articles a week, whilst the topic of the blog does not change: software development and engineering. Given the 52 weeks contained in an year, this goal results in 285 posts that should fill the 2010 archive.
    • this year I will obtain my bachelor's degree in Computer engineering. I commit to sustain the final test in the July or September sessions.
    • I will get a B2 English language certification, in order to graduate. This is an independent exam, external to my university, required for the degree.
    • finally, I commit to produce a stable release of my personal project, NakedPhp. NakedPhp is a php port of the Naked Objects Framework for Java, which generates a user interface for direct manipulation of objects and classes. Currently the subversion repository has reached the hundredth revision, which is not bad for a solo developer.
    Considering the English language certificate as part of the degree, these are my three major projects for the year. I think I can sustain this workload, as I have no strong need to take freelancing gigs for financial reasons in this period, which would consume time I dedicate to open source.
    Though, the main issue with goals is not the setting phase, but achieving them: every two months I will post about these goals and the steps I will have taken to reach them.
    Happy new year everybody and happy resolution!

    Tuesday, December 08, 2009

    5 reasons to be happy in a terminal

    I am not talking about an airport terminal, but about one of the terminal emulators which are provided by modern window managers, like gnome-terminal for Gnome and the similar Konsole for Kde, along with the minimal xterm. These are all unix applications but equivalent applications exist for other platforms like Windows, although their integration with the underlying operating system and with specific programs can be tricky.
    Why should you, a software developer/engineer, want to pass most of your time in a dumb terminal instead of in a powerful and costly IDE? I have five reasons to convince you.
    • instant access to unix programs. GUIs facilitate the job of naive users but the real power resides in the command line tools which perform the real work; moreover, cli programs can be chained in infinite ways using their universal plain text interface.
    • the classic 80x25 terminal has short lines and a short number of lines: too much logic in a line stands out because the line wraps on the subsequent one. Too long methods are spotted as well, because they don't fit in a single or double screen and require multiple scrolling.
    • transparent remoting with ssh. The same can be said for VNC, but it can be very slow and it's not always supported while many servers have a ssh daemon. It is so fast I did not notice the latency between my local machine and other boxes in my Lan, so I have given them different colored prompts to easily distinguish between environments.
    • uninterrupted flow; not using the mouse makes you move very quickly in the cli environment, once you know what to write and how to leverage the text- based tools.
    • every executed command is registered for possible future repetition and modification. Try record a procedure of 90 control panel clicks instead.
    As a side note, thanks to history, it's also very simple to calculate statistics on which are the most popular commands you type on your development box:
    [12:29:32][giorgio@Indy:~]$ history | awk '{print $2;}' | sort | uniq -c |
    > sort -nr | head -n 10
       4924 vim
       1326 svn
        879 nakedphpunit    // it's an alias for phpunit --bootstrap=...
        616 sudo
        438 cd
        266 ls
        238 osstest_sqlite
        207 phing
        135 ./scripts/regenerate
        127 grep
    Of course most of them were only typed the first time and then recalled. From these data you can infer that I use the command line interface a lot, and I've never been more productive. This statistic is a typical leverage of command line tools in a construct that took me less than a minute to write and that I can repeat whenever I want in a few seconds.

    Sooner or later, the time comes when a developer feels constrained by his graphical interfaces and resorts to use the command line directly. If he avoids the command line, probably it's because he does not know how to work with it. Don't be so proud like this developer and take some time to learn: the cli will repay you soon.

    Monday, December 07, 2009

    PHPUnit and Phing cohabitation

    During the publication of Practical Php Testing some readers asked me to include information on how to make PHPUnit and Phing work together. It was not possible due to time constraints to include an appendix on this topic, so I will talk about it here.

    First, some background:
    • PHPUnit is the leading testing harness in the php world: it consists in a small powerful framework for defining test cases, making assertion and mocking classes.
    • Phing is an Ant clone written in php, that should become the standard solution for automating php applications targets such as deployment, running different test suites at the same time and generating documentation. Why using Phing instead of Ant? Because it interfaces well with php applications.
    Integrating these two tools means giving Phing access to a PHPUnit test suite and letting the phing build files, which manage configuration, contain also information on how to run the test suite. In the build.xml file of an application you should find different targets like generate-documentation, test-all, compile-all (if php were a compiled language), and so on.

    There are two ways for accessing PHPUnit test suites via phing: exec and phpunit tasks.
    At the time of this writing, the phpunit task bundled in stable releases of Phing lacks functionalities, primarily the ability to define a bootstrap file to execute before the test suite is run. I can't live without --boostrap and I look forward to a release of Phing that lets me specify this file in the configuration.
    This release will be Phing 2.4.0 (at least a Release Candidate 3 version, while on December 2009 it is in RC2). There are two things that are being fixed and that would annoy the average developer a lot:
    • There was a bug in the last RC release affecting the bootstrap parameter, and the inclusion took place too late in the process, producing fatal errors when the suite for instance relies on autoloading. This bug is fixed in the repositories and will be gone in the next RC release. I downloaded the simple patch and applied it manually to try out the bootstrap functionality and it works very well. (http://phing.info/trac/ticket/378)
    • The summary formatter is not a summary: it uses the wrong hook method, producing a report for every single test case and resulting in an output hundreds of lines long. I opened a ticket to tackle this issue. (http://phing.info/trac/ticket/401)
    What we will be able to do
    <target name="test">
        <phpunit bootstrap="tests/bootstrap.php">
            <formatter type="summary" usefile="false" />
            <batchtest>
                <fileset dir="tests">
                    <include name="**/*Test.php"/>
                </fileset>
            </batchtest>
        </phpunit> 
    </target> 
    
    When you push the big test button on your desktop (from the cli type phing test), this xml configuration will hopefully produce a report while your test suite runs.
    The problems with this approach are it does not work yet due to the bugs I have listed earlier, and that it eats quite a bit of memory, forcing me to increase the limit to 128 Megabyte for a suite composed of 144 unit tests.

    What we do now
    Until a stable version of Phing 2.4 is released, we should rely on exec commands, which directly call the phpunit binary executable (not so binary: it is in fact a php script):
       <target name="test">
            <exec command="phpunit --bootstrap tests/bootstrap.php 
    --configuration tests/phpunit.xml --colors"
    dir="${srcRoot}" passthru="true" />
            <exec command="phpunit --bootstrap=example/application/bootstrap.php  
    --configuration example/application/tests/phpunit.xml --colors"
    dir="${srcRoot}" passthru="true" />
        </target>
    $srcRoot is a property that specifies the working directory to run the phpunit command in. passthru makes the task echo the output of the command.
    This approach is sometimes more flexible than using the specialized phpunit task. More flexible in the sense that you don't have to expect that phing includes in its tasks options for configuring new phpunit features, because you can use them just as they are available from the command line. On the other hand, it may be difficult to perform different actions (like lighting up a red semaphore in your office) basing on the last build state (red or green).

    So I'm relying on exec tasks for now. By the way, the result is pretty and colors are even conserved, but I have to expect the end of the exec command to see any output (no dots slowly piling up on the screen).
    If you enjoy using Phing and PHPUnit, please provide feedback and contribute to the projects, especially in the case of Phing. It is a project that deserves more attention from the community due to its integration tasks.
    UPDATE: Phing 2.4.0 was released on January 17, 2010.

    Wednesday, December 02, 2009

    Practical Php Testing is here


    Practical Php Testing, my ebook on testing php applications, is finally here as promised, in the first days of December.
    How many times in the last month have you seen a broken screen in the browser? How many times did you have to debug in the browser, by looking at the output, inserting debug statements and breaking redirects? How many times did you perform manual testing, by loading a staging version of your application and tried out different workflows in the browser?
    If the answer to these questions is more than very few, it's likely that
    you should give automated testing a chance.
    This book is aimed to php developers and features the articles from the Practical php testing series, while the other half of it is composed by new content:
    • bonus chapter on TDD theory;
    • a case study on testing a php function;
    • working code samples, some of whom were originally kept on pastebin.com;
    • sets of TDD exercises at the end of each chapter;
    • glossary that substitutes external links to wiki and other posts, to not interrupt your reading with terms lookup.
    The book comes for free and is licensed under Creative Commons. This phrase means you are free to copy it and give it to anyone. If you find my work useful and you want to be supportive, you can make a donation with the link on the right menu or with the one provided in the book.

    Thursday, November 26, 2009

    Agile estimating and planning review

    Agile Estimating and Planning by Mike Cohn is a masterpiece on Agile management techniques, especially in dealing with schedules and application features. I just finished reading it and it gave me a very positive perspective on classical development conundrums like schedule and scope.
    Agile does not solve problems for us, nor promises to eliminate every issue. The 300+ pages cover the majority of the topics in the, like the title says, estimation and planning field for an Agile team. The author writes in an honest style and anticipate reader's questions and objections.
    There are many concepts scattered trough the book:
    • The Agile planning approach: we don't know much at the start of a new project, but after every iteration we get to know more about the domain and the application. Thus, we can improve our estimation of remaining work, while changing scope and release dates to deliver the maximum value. So we should keep planning, but be ready to throw away the plans.
    • Estimating size and estimating time are two different processes: velocity is the parameter that links them. Size is described by different, relative variables than actual time needed (like story points or ideal days).
    • What's a story point? And a release burndown chart? We often use Agile terms without referencing read formal definitions and they can seem mumbo jumbo to the uninitiated developer. Actually, Agile is not complicated if you take a bit of time to learn; you probably already know nearly all of the math involved in this book, but a glance at probability theory could help.
    • Tools like questionnaires and charts for tracking progress explained from the ground up. Back at the first chapter, I had not an Agile theorical foundation, but I still found the book exciting to read and very accurate.
    • Common practices for stories management can help you to mix up, split and join user stories. Estimation can be a difficult process but in this context it is not a random guess.
    • Prioritization of stories, along with iteration and release planning: the 1,000 and 10,000 feet views on your project life and scope.
    • Plenty of practical examples are spreaded throughout the chapters, and the author reports how to implement the techniques described in a real project, by consistently taking a swimmer statistics management application as the main example. This consistency helped me to get the overall picture.
    • Finally, a fictional case study is presented at the end of the book, to pull all things together and see an Agile project worked out from the initial requirements gathering to the deliver date.
    After having read this book, every project now seems a big opportunity to apply an Agile approach. I strongly recommend it if you want to get started with story points, iteration and other great Agile concepts.

    Tuesday, November 24, 2009

    Mistakes of a freelancer

    I have been inspired by a post by Soon Hui to write about my mistakes. I have evolved much on the programming side during these years, but my biggest mistakes have been social and economic: dealing with other people. Thus, I have collect a list of my errors committed as a php freelance developer.
    • Giving out your personal phone number: no matter what, use separate phone numbers for clients and friends. People have the tendency to call in awkward hours, and having a single number you can shut off after the workday has finished helps your work-life balance .
    • Lack of tests: every application you write will be maintained in the future, often by you. Even small tweaks (that you can't honestly charge for) can break an application and the safety net of a test suite will free you from the burden of manual testing.
    • Providing fixed estimates: estimates should be given in the form of a range, and the whole process of estimation and planning in software development is more complex than the average person thinks. Counting billable hours just does not work and an application's size should be assessed during the requirements gathering.
    • Tasks instead of features: one pillar of Agile processes is that features are the metric of success and accomplishment, and not tasks. Even if you're working on fixed-price waterfall projects, focus on giving out the features requested because no customer has the time to comprehend technical and infrastructure tasks such as "database modelling".
    • Thinking that a client knows what he needs: even in porting legacy applications, no customer really understands the kind of software he wants. It is our job to interact with him to distinguish between mandatory and exciting features and providing the highest value in an application, since we have great  programming skills but little domain knowledge. Often emphasis is put on gold plated features which are really not worth their cost and can cause disasters in the long run (and maybe you are even forced to prioritize features with high risk and little reward). Dialogue, dialogue, dialogue.
    • Not defining economic terms early: when you write the first line of code you should have an agreement on your reward. This rule of thumb can seem obvious to us, but remember that customers usually come from a whole different world.
    It's a long list, but I feel that I have grown for more than five years and since I started my journey in computer science even before, I'm approaching the 10000 hours as a developer but still gaining basic experience in business. These errors are something I really had to try by myself.
    Have you some freelance experience to share? What do you feel you could have done differently during your career?

    Monday, November 23, 2009

    Firefox without a mouse

    As a developer I have made an habit of using the keyboard for the majority of tasks. Vim for example is my favorite text editor, which does not require point-and-click. This is a productivity requirement: the less my fingers move between the keyboard and the mouse, the faster I am in consulting documentation and other developers' blogs; vim even goes further and lets you scan a document without leaving the home row.

    Firefox is also an application where I try to avoid mouse (or touchpad if I am using the EeePC). Unfortunately most sites are not really accessible and I have to resort to mouse for links and forms: it's not satisfying when you [Tab] trough a form and end up in some other place in the page.
    Though, Firefox's user interface is really usable without resorting to the mouse. Here are some shortcuts I wanted to share with you:
    • <Ctrl>T: create a new, empty tab, and give it focus.
    • <Ctrl>W: close the currently selected tab.
    • <Ctrl><Shift>T: reopen the last closed tab.
    • <Ctrl>PagUp, <Ctrl>PagDown: move between the opened tab.
    • <Ctrl>L: give focus to the location bar.
    • <Ctrl>K: give focus to the quick search bar. If you set the browser.search.openintab directive in about:config to true, search queries will be opened in new tabs. Remember that often search engines and websites like php.net and Wikipedia implement the OpenSearch specification, allowing you to add them to the quick search list of engines.
    • <Alt>Down to select the search engine when you are typing in the quick search bar.
    For instance, to search the strpos() function on php.net, assuming that you have stored it in the available engines:
    <Ctrl>T, <Ctrl>K, <Alt>Down to select php.net, strpos<Enter>
    Or, if browser.search.openintab is set:
    <Ctrl>K, <Alt>Down to select php.net, strpos<Enter>
    If php.net is already selected since you have already looked for other functions:
    <Ctrl>K, strpos<Enter>
    Or, given that php.net implements nice urls:
    <Ctrl>T, <Ctrl>L, strpos<Enter>

    Happy browsing with Firefox and the keyboard! :)

      Tuesday, October 27, 2009

      Programming Cone of Experience

      The Cone of Experience is a model formulated by the educationist Edgar Dale in which he summarized the various learning media and their effectiveness. Like every model, it has limits and should be adapted to your personal vision, but since learning is something a good developer does every day to improve himself, having a methodology for acquiring new knowledge is fairly essential.

      The Cone shows different activities in crescent order of memory retention. People are generally able to remember more things if they are learning trough the lower and larger layers and less if they are working in one of the top and thin ones. We will show an example of a developer learning Test-Driven Development and good software design, comparing different layers of the cone. There are many examples of phrases like "People remember 10% of what they read, 20% of what they see, ... 90% of what they do", but these numbers are totally made up and there are no quantifications in Dale's original work.
      However, this is the Cone:

      Let's analyze the different way a developer can learn a new technology or practice, such as TDD. We will start from the less powerful experiences and descend towards the end of the cone where the experiences have a great effect on the human memory and we are less prone to forget and confuse informations.
      I want to learn TDD, so what I can do?
      • I read a book. However, reading one, two or ten books does not make me an expert on TDD or software design, and if I don't refresh my knowledge often I will probably forget everything but Red-Green-Refactor.
      • If the book has nice figures, they will improve my understanding and I will be able to remember at a glance different concepts that fit together in a single picture.
      • I listen to a podcast or see a video of Misko Hevery doing a talk at Google. This is more impressive for the brain and typically will have a longer-lasting effect on me than reading a book.
      • If I see him writing code in real time, the experience is even best.
      • The next step is simulating a real world situation by writing code for a toy project. This is also probably the last step we can make.
      • The final step is real experience: TDD some classes for my preferred application and analyze the results, then start again. The real experience is often not available for learning, or it presents some restrictions, fortunately: think of surgeon that practices on human beings. He must gather real world experience, but he is under the strict control of senior colleagues for years.
      So suppose you want to learn TDD or the new technology. What you should do? Skim a book of course, to know the theory. But don't stop here: write code snippets, compile real code, work on a small project you can afford to throw away. If you have the time and the money to invest, go to a conference where in one hour the speaker will give you a general knowledge of the subject.
      If is it available, a live coding session is the best thing to start with a new technology or language. That's why in university's exercise sessions and laboratories we learn much more what we would do while staring at a professor. Taking notes is a step further down in the Cone of Experience, but if you are missing pieces because you are too busy writing down everything to bother listening to the professor, it is not an improvement.

      The hello world applications presented by many frameworks are not meant for being simply read. They are made for being compiled and hacked. The usefulness of a hello world program resides in helping you setting up the environment and the tools to build the simplest application - the one that does nothing. By experiencing the steps needed to build such a small binary, you start to grasp how to work with the new technology.
      First-hand experience is the most powerful learning tool for the majority of people in the world and we should give it the right priority.

      Monday, October 26, 2009

      Validity of development tactics

      Many software development practices and methodologies are presented as panaceas and silver bullets, seeming to be valid in every domain and situation. But a responsible developer must be pragmatic (and a successful book and series started from this term) about where and when he applies his preferred technology, knowledge, or workflow.
      I blogged some weeks ago about the overusing of a specific technology, but now I am focusing on the more general methodologies and paradigms like object-orientation, particularly if they involve killing a fly with a bazooka.
      Let's start with a series of examples regarding field of application:
      • Test-Driven Development might be the best and most controversial XP practice and is widely applied for producing robust and maintainable software. Though, it is obviously not applicable to application which are not object-oriented as you cannot easily isolate piece of functionality in structured programming; moreover, there are specifical tasks where TDD is an obstacle, like creating a graphical user interface or a throwaway prototype.
      • Limitations are intrinsic in Design Patterns: Ralph Johnson, one of the author of the original Design Patterns book, affirmed along with his fellow authors in a recent interview that functional programming requires for instance different patterns than the ones presented in the book.
      • Digging further, even object-oriented programming is not applicable in every domain and delopyment node, mainly where there is not the infrastructure to provide polymorphism and inheritance, like in embedded applications which typically employ the C programming language or in low-level operating systems routines. Some zealots will say that an object-oriented website will never scale, but this is an exaggeration.
      • Agile software development is a great methodology for delivering value to a customer, but it is not suitable if your organization does not support it, or software development is not your job. One could argue that software development should be managed by professionists, but this is not usually true in the real world, where in-house programmers have more than one responsibility.
      • At the programming level, using a Factory to build your objects is a good choice if they require external dependencies, but sometimes this is not the case. For instance objects that has to be serialized commonly are required to not have external dependencies, as you can always pass any service class trough the stack while calling a method. These objects are often declared newables.
      • Version control is great and even solo developers should give it a try. I put nearly everything I produce in a Subversion repository, but I do not store binaries in it for example, since they can be generated from source code stored in the repository and they would only slow down the server while performing enormous diffs. In the previous post I said that Subversion and similar applications are general purpose systems, but even here there is a limitation in what they are meant for.
      I can go on for hours and I'm sure you can find a flaw in every single practice I can mention here. As Fred Brooks wrote in his famous essay:
      There is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity. --Fred Brooks
      And it is indeed true that every practice we implement has limits in field of application and in the productity improvement it can give back to us. There is the temptation to apply straight our new knowledge or technology to every problem at hand, but instead of perform well the technique usually jumps the shark and produces an horrible result like the ones I listed previously.
      Consider the TDD example: test-first programming helps us to produce decoupled components for our applications, and shrinks the time required for bug fixing. So should we apply this technique to user interfaces? I would say a big No as it would slow down our development, cluttering the codebase with brittle tests that have to change every day. So the improvement in productivity is not gained on all the production code, but only in the domain layer, which is fortunately the most important one. You also may have to write other infrastructure code which serves as the glue between layers. Is it useful to test-first this code? I think it is not. The effort spent for automating the tests and discover wiring or user interface bugs is often not worth the value they provide.
      You also have to test the wiring of your application, and unit tests like the ones prescribed by TDD are not useful here.

      Take care of what you learn and also research and discover when you can use it. Like in physics, no formula is always valid and you must put it in context before starting to tackle a problem with your swiss-army knife.

      Saturday, October 24, 2009

      How to transform a broken laptop into a server

      I bought my second-hand Toshiba Tecra A3 for about 500 Euros while still in high school, with the earning of my first web projects. During the sebsequent years, it slowly fell into pieces, one step at the time:
      • the first things that failed were the speakers;
      • then, the Combo Dvd reader and Cd writer suddenly was unable to read an entire disk;
      • third, the hard disk began to be unreliable, as files saved on a particular portion of it became corrupted instantly;
      • then the lcd screen suffered a hit and was rendered useless, as only a big stain of color filled (and still now fills) all the screen.
      In this situation, I ordered a new ASUS Eee PC from eBay to substitute my former portable working station. This was one of my best purchases, and the Tecra A3 was put in a box and forgotten. However I am glad that I did not throw it away.

      Towards the end of 2008, I felt the need for a development/staging server at home, as part of my freelancer work with php applications. The server did not need to run 24/7, but only during my work sessions and with only me and a few other people to work for. I was aware that servers which run Apache and Subversion do not need high-end components and I started to gather ideas on how to recycle my old laptop.
      The CD reader was not required for a server, and I could not change it easily anyway. The screen and the speakers were useless for the same reasons, but the hard disk is something a server usually needs. So I bought a cheap 10 gigabytes Eide unit on eBay for less than 30 Euros. Substituting the old drive with this one restored Indy status as a working machine.

      The next problem was how to install software on a blank machine like this one, without a CD drive and a screen to complete the graphical or command line installation process.
      For the screen problem, I temporarily attached my primary machine monitor and figured out quickly that installing a command-line interfaced system like Ubuntu Server would have given me a system accessible via ssh, without the need for a real screen as I would be able to use the server via other machines like the Eee PC and my primary computer.
      The installation was more difficult as I had to find another medium for the Ubuntu iso image. My laptop is not capable of booting via Usb, so I chose an installation with a boot via Ethernet (PXE). This involved setting up a tftp server on my desktop machine to host the installation files, and I suggest you to use a Usb card installation if you want to do the same thing.

      Normally, Ubuntu systems run the NetworkManager application in the user bar of Gnome providing a list of wireless network to connect to. I wanted to have a connected system at startup, since without a already existing connection the ssh login is not available. Thus, I configured wpa_supplicant, the daemon used by NetworkManager as a backend, to automatically connect to my home WPA wireless network. Obviously I installed the ssh daemon and after this step I was able to remove the temporary monitor and use my new server remotely.

      Once I had a working machine, I installed apache, php, mysql and subversion via the Ubuntu repository, running apt-get over ssh, that is the interface I administer the server still today. Now I had a web and source control server that I periodically backup just in case something goes wrong. Reliability is nor critical as even is the server explodes I can roll out my backups the next day on my desktop machine.

      There is an enormous amount of electronics garbage out there to dispose of, and recycling an old pc is by far cheaper than buying full-featured servers just for testing purposes (unless you're doing a stress test): the servers on the market are meant for production sites and php development activities, which do not require compilation, do not stress even a poorly equipped machine as they include only a few http requests per second to satisfy. If you manage to reuse old hardware, you are doing a favor to yourself and to the environment.

      Featured post

      A map metaphor for architectural diagrams

      It is a (two-dimension) representation of a pipe. The map is not the territory , but in software engineering terms they are models of it....

      Popular posts