I'm a bit late due to various parties on Easter, but here are my original articles published during the past week.
Practical PHP Testing Patterns: Testcase Class per Feature explains how to divide tests basing on the feature they specify instead of on the class they refer to.
Linear trees with Git rebase explains what git rebase is handy for, and how it maintains a linear history of code even when managing different branches.
Practical PHP Testing Patterns: Testcase Class per Fixture is another possible division of tests, which is based upon a common initial state of the system when they are executed
Exploring TDD in JavaScript with a small kata is an execution of the FizzBuzz kata in JavaScript, with a Red-Green-Refactor cycle that executes automated tests from the command line.
A journey in web development, [computer] science, engineering:
getting to know what lies under the hood -- Giorgio Sironi
Monday, April 25, 2011
Thursday, April 21, 2011
Conferences and events
This page is a reference to the conferences I have attended. It was inspired by Juozas's example.
Here's where I have been. You may have met me there:
Here's where I have been. You may have met me there:
- phpDay 2010, Alba Adriatica as a speaker with Architettura e testabilità.
- PHP Barcelona 2010 with Architecture and testability.
- TEDx Lake Como 2010 as an attendee.
- WebTech Italia 2010 as an attendee.
- Italian Agile Day 2010 as an attendee.
- phpDay 2011 with Pursuing Domain-Driven Design practices in PHP and An year of Pomodoros.
- Dutch PHP Conference 2011 with Pursuing Domain-Driven Design practices in PHP and the 3-hour workshop Testing in isolation.
- PHP Barcelona 2011 with An year of Pomodoros.
- Domain-Driven Design Day with DDD in PHP.
- Global day of code retreat 2011, Milan, as an attendee.
- PHP Goes Mobile with Scrivere test in PHP che utilizzano il browser Android.
- PHP.TO.START 2012 with a talk on testability.
- phpDay 2012 with What they didn't tell you about object-oriented programming in PHP.
- Global day of code retreat 2012, Milan edition, as a coach.
- PHP Benelux 2013 with The Pomodoro Technique.
- PHP.TO.START 2013 with Accepting a legacy.
- phpDay 2013 with The test suite is slow.
- Legacy code retreat Milan 2013 as a coach.
- Italian Agile Days 2013 with Test sulle immagini and as a coach in the Code Retreat.
- Global day of code retreat Milan 2013 as a coach.
- Mobile World Congress 2014 as an attendee.
- phpDay 2014 with How to test 2 years of behavior for 16 countries in 4 minutes and 30 seconds.
- Vim Brulé as a Vim padawan.
- PHPCon Poland 2014 with Distributing PHP applications over HTTP.
- Codemotion 2014 where I helped Jacopo Romei in his workshop.
- phpDay 2015 as an attendee.
- Italian Agile Day 2015 with Property-based testing: Extending examples to a specification
- Global day of code retreat Milan 2015 as a coach.
- /dev/winter 2016 as an attendee.
- Agile in the City 2016 with How to test years of behavior for N countries in 18 minutes.
- Dutch PHP Conference 2016 with CQRS and Domain Events for integration.
- Pipeline Conf 2017 as an attendee.
- phpDay 2017 with Long-running PHP processes.
- PHP South Coast 2017 with Long-running PHP processes.
- Dutch PHP Conference 2017 with Long-running PHP processes.
- Agile Cambridge 2017 with Cheap and reproducible testing environments on AWS.
- Container Camp UK 2017 as an attendee.
- Pipeline Conf 2018 as an attendee.
- Agile Cambridge 2022 with From soloists to ensemble.
Sunday, April 17, 2011
Weekly roundup: e-learning
I'm participating on an ASP project which goal is using web 2.0 for e-learning services.
After a while, this tweet seems appropriate:
Here are my original articles published this week.
Practical PHP Testing Patterns: Parameterized Test explains how to use @dataProvider to avoid duplicating the code for some tests.
We cannot avoid testing JavaScript anymore is a survey on tools for testing JavaScript at the unit level. They're different from Selenium, which runs on the whole application with end-to-end tests.
Practical PHP Testing Patterns: Testcase Class Per Class is the simplest structure for organizing test cases. We'll get more complex next week.
WebSockets in 5 minutes is a panoramic on the functionalities and current support of WebSocket, and which alternatives we have available.
After a while, this tweet seems appropriate:
I get nauseated every time I heard someone saying "2.0" -- @stain(translation mine)
Here are my original articles published this week.
Practical PHP Testing Patterns: Parameterized Test explains how to use @dataProvider to avoid duplicating the code for some tests.
We cannot avoid testing JavaScript anymore is a survey on tools for testing JavaScript at the unit level. They're different from Selenium, which runs on the whole application with end-to-end tests.
Practical PHP Testing Patterns: Testcase Class Per Class is the simplest structure for organizing test cases. We'll get more complex next week.
WebSockets in 5 minutes is a panoramic on the functionalities and current support of WebSocket, and which alternatives we have available.
Sunday, April 10, 2011
Weekly roundup: an hot April
Nearly unrelated image |
These are my original articles published this week on DZone.
Practical PHP Testing Patterns: Named Test Suite shows how to execute test suites by name (dividing test in groups) in PHPUnit.
HTTP is your wrench tells you that studying REST is useful even if you don't write web services.
Practical PHP Testing Patterns: Test Utility Method is the basic brick for refactoring test code.
The measures of programming sustain a simple thesis: that a 80x25 window with 4 spaces for indentation is enough for reading source code.
Thursday, April 07, 2011
The Shower Methodology and Kanban
I'm still reading (really slowly, in order to absorb informations better) Test-Driven Development by example by Kent Beck.The author cites Paul Ungar's Shower Methodology for writing code:
Sometimes raising money becomes your shower top priority:
Test-Driven Development is an extension of Ungar's Shower Methodology. Given a red (failing) test, you'll have to make it pass:
For example, given the test for extracting the square root of 2:
If I'm unsure, I would insert return 1.4142 to get a green bar initially, and then go on writing the algorithm.
If I do not know the algorithm at all, I will insert another test for sqrt(3) to triangulate it (even more than one test if it's the case).
If now I wonder what the algorithm is and I have no idea on how to go on, I will take a shower and think about it.
Disclaimers: TDD in this version is a methodology for implementing a single feature (it doesn't cover prioritization, or estimation, or everything else). It acts as a low level of abstraction, which can become higher if you can write end-to-end and functional tests.
Note also that taking a shower may be metaphorical: you can go work on another project, or another component, or to a meeting, or google for some resource on algorithms and data structures.
After all this talking about breaks, the comparison that does not always fit is with Kanban and Work-In-Progress limits. If you have to build a car, indeed you will achieve a very short lead time if you limit the buckets of semi-finished parts: there will be less inventory to transport and store, they will be exchanged more frequently and so on...
If you have to develop software, well, it depends: if you always perfectly know what to type, you can place a WIP limit of one or two user stories and work only on one feature at the time. Scrum and every Agile methodology does exactly this with iterations; Kanban does it at a finer level by limiting the tasks that can be moved forward in each phase (analysis/development/testing/deployment/...).
If I am on a PHP web application, Usually I perfectly know what to type: no problem with WIP limits.
Yet if learning is involved, you may juggle different stories and tasks in the same time period, working for example for one day on each, rotating them. I am tackling a difficult computer vision project where I have to solve problems that range from tracking vehicles in a video to estimate their positions and understand if they will collide under certain conditions. I'm putting in it 4 hours a week: there's no way I will be able to do more due to the research and experiments involved (half of the time I do not know how to go on; and it's normal.) Multitasking is the only way to go if I do not want to lose the other 36 work week hours.
So if I had an hard WIP limit on the projects I can tackle, I would be screwed. You know what works with very large WIP limits? Universities. Normally in Italy you can have 6 courses at the same time. If you try to do one course at the time (20 hours a week for three weeks), you will shoot yourself. Formally, there are almost no limits in the engineering faculties: you can complete your studies following the order you prefer.
Thus I think WIP limits are important as they avoid attacking too many things at the same time, and never complete any. Yet if creativity is involved, shuffling projects and go taking a shower when you need it will help you more.
I went for a shower after writing a draft of this article, and I thought also about the analogy of reading books, which is an example of where Kanban is really useful (summing it up: don't buy books if you do not already read all the ones from the last order.) In the cases of user stories, car parts or books we have a set of items which is useless until it goes through all the stages: a user story is deployed, a car part is on the road, a book is ordered, unpackaged and read. You don't get value from a still wrapped book sitting on your shelf, a story you can't deploy yet or an engine not mounted on a car.
With university, it's beneficial to have related courses taken at the same time instead of serially: you can often apply in practice a concept coming from another course, or compare different approaches (mathematical one vs. physics one vs. the engineer's attitude to linearize and model everything as a Gaussian; or the operations researcher attitude towards a problem vs. the computer scientist goal to find the best data structure to solve it).
With research projects like the computer vision one, the end result is unclear and there are no subparts that can be defined earlier. That's how it works in scientific research. I often don't have user story to transport from one side to the other of the board: I have challenges to overcome with creative thinking, and creativity is not a very repeatable, optimizable process.
Note that there is always a bit of creativity in every software project: that's what makes it fun.
- If you know what to, type it.
- If you don't know what to type, go take a shower.
Many teams would be happier, more productive, and smell a whole lot better if they took his advice. -- TDD by ExampleThe shower is indeed the place where many difficult problems are solved. When you have a difficult problem, and it becomes and stay your top priority, your brain daemons (background processes) will work on it for you, and present a fresh solution in an unexpected moment, when you stumble on the problem in an unfamiliar environment such as the shower. When you are parking your car, or walking, or showering, these processes will leverage your free CPU.
Sometimes raising money becomes your shower top priority:
I realized recently that what one thinks about in the shower in the morning is more important than I'd thought. I knew it was a good time to have ideas. Now I'd go further: now I'd say it's hard to do a really good job on anything you don't think about in the shower. [...] Money matters are particularly likely to become the top idea in your mind. The reason is that they have to be. It's hard to get money. It's not the sort of thing that happens by default. It's not going to happen unless you let it become the thing you think about in the shower. And then you'll make little progress on anything else you'd rather be working on. -- The Top Idea in Your Mind
Test-Driven Development is an extension of Ungar's Shower Methodology. Given a red (failing) test, you'll have to make it pass:
- If you know what to type, type it: always start from the Obvious Implementation if you know what it is.
- If you don't know how to achieve the result, Fake It: return 0, return 4 and other hard-coded test-specific production code are ubiquitous as TDD starting points.
- If you still can't generalize after faking the response, try Triangulation: write another test which feeds the system other values and expects a different response. This test, when passing, will ensure there is no hard-coding anymore.
- If with triangulation you still don't know how to go on, take a Shower.
For example, given the test for extracting the square root of 2:
$this->assertEquals(1.4142..., sqrt(2));I would code an Obvious Implementation for sqrt(), if I already know the algorithm.
If I'm unsure, I would insert return 1.4142 to get a green bar initially, and then go on writing the algorithm.
If I do not know the algorithm at all, I will insert another test for sqrt(3) to triangulate it (even more than one test if it's the case).
If now I wonder what the algorithm is and I have no idea on how to go on, I will take a shower and think about it.
Disclaimers: TDD in this version is a methodology for implementing a single feature (it doesn't cover prioritization, or estimation, or everything else). It acts as a low level of abstraction, which can become higher if you can write end-to-end and functional tests.
Note also that taking a shower may be metaphorical: you can go work on another project, or another component, or to a meeting, or google for some resource on algorithms and data structures.
Our Kanban board |
If you have to develop software, well, it depends: if you always perfectly know what to type, you can place a WIP limit of one or two user stories and work only on one feature at the time. Scrum and every Agile methodology does exactly this with iterations; Kanban does it at a finer level by limiting the tasks that can be moved forward in each phase (analysis/development/testing/deployment/...).
If I am on a PHP web application, Usually I perfectly know what to type: no problem with WIP limits.
Yet if learning is involved, you may juggle different stories and tasks in the same time period, working for example for one day on each, rotating them. I am tackling a difficult computer vision project where I have to solve problems that range from tracking vehicles in a video to estimate their positions and understand if they will collide under certain conditions. I'm putting in it 4 hours a week: there's no way I will be able to do more due to the research and experiments involved (half of the time I do not know how to go on; and it's normal.) Multitasking is the only way to go if I do not want to lose the other 36 work week hours.
So if I had an hard WIP limit on the projects I can tackle, I would be screwed. You know what works with very large WIP limits? Universities. Normally in Italy you can have 6 courses at the same time. If you try to do one course at the time (20 hours a week for three weeks), you will shoot yourself. Formally, there are almost no limits in the engineering faculties: you can complete your studies following the order you prefer.
Thus I think WIP limits are important as they avoid attacking too many things at the same time, and never complete any. Yet if creativity is involved, shuffling projects and go taking a shower when you need it will help you more.
I went for a shower after writing a draft of this article, and I thought also about the analogy of reading books, which is an example of where Kanban is really useful (summing it up: don't buy books if you do not already read all the ones from the last order.) In the cases of user stories, car parts or books we have a set of items which is useless until it goes through all the stages: a user story is deployed, a car part is on the road, a book is ordered, unpackaged and read. You don't get value from a still wrapped book sitting on your shelf, a story you can't deploy yet or an engine not mounted on a car.
With university, it's beneficial to have related courses taken at the same time instead of serially: you can often apply in practice a concept coming from another course, or compare different approaches (mathematical one vs. physics one vs. the engineer's attitude to linearize and model everything as a Gaussian; or the operations researcher attitude towards a problem vs. the computer scientist goal to find the best data structure to solve it).
With research projects like the computer vision one, the end result is unclear and there are no subparts that can be defined earlier. That's how it works in scientific research. I often don't have user story to transport from one side to the other of the board: I have challenges to overcome with creative thinking, and creativity is not a very repeatable, optimizable process.
Note that there is always a bit of creativity in every software project: that's what makes it fun.
Monday, April 04, 2011
Kent Beck on Singletons
This is an excerpt from Test-Driven Development By Example, the book by Kent Beck which introduced a first formalized version of TDD to the world.
Singleton is cited as one of the most famous design patterns, along with Null Object and Composite:
There's also a more recent (re)tweet:
@natpryce is one of the two authors of Growing Object-Oriented Software, guided by tests.
Singleton is cited as one of the most famous design patterns, along with Null Object and Composite:
How do you provide global variables in languages without global variables? Don't. Your programs will thank you for taking the time to think about design instead.That's it, that's the whole Singleton chapter. First printing: October 2002.
There's also a more recent (re)tweet:
RT @natpryce: Someone (who?) gave me a good pattern tip at #accu2010: don't say "singleton", say "globalton" instead. Nice one!
@natpryce is one of the two authors of Growing Object-Oriented Software, guided by tests.
Sunday, April 03, 2011
Weekly roundup: computer vision
I still have an exam to pass after my first semester in the master's program. It is the exam of computer vision, which consists of a project - in my case, automated detection of traffic infraction.
My goal is, given a video of an urban intersection and some configuration of the scene parameters, to detect vehicles that do not respect priority. I'm more or less correctly tracking the vehicles, but the challenge now is to rectify the scene in real world coordinates (meters instead of pixels):
The project is all TDDed, and it is hosted on Github, just for backup's sake. So this is an example of what you can do at PoliMi, computer engineering's program.
Here are my original articles published this week.
Practical PHP Testing Patterns: Test-Specific Subclass goings on in the Practical PHP Testing Patterns series.
Struts vs. Zend Framework compares an old-style Java framework such as Struts 1 to Zend Framework 1.x.
What Firefox 4 means to web developers? is a light analysis of what features new browsers are providing us.
The PHP frameworks poll results presents the results of the recent popularity survey on Web Builder Zone.
My goal is, given a video of an urban intersection and some configuration of the scene parameters, to detect vehicles that do not respect priority. I'm more or less correctly tracking the vehicles, but the challenge now is to rectify the scene in real world coordinates (meters instead of pixels):
The project is all TDDed, and it is hosted on Github, just for backup's sake. So this is an example of what you can do at PoliMi, computer engineering's program.
Here are my original articles published this week.
Practical PHP Testing Patterns: Test-Specific Subclass goings on in the Practical PHP Testing Patterns series.
Struts vs. Zend Framework compares an old-style Java framework such as Struts 1 to Zend Framework 1.x.
What Firefox 4 means to web developers? is a light analysis of what features new browsers are providing us.
The PHP frameworks poll results presents the results of the recent popularity survey on Web Builder Zone.
Friday, April 01, 2011
The new PHP TARDIS Api
Yeah, from PHP 5.4 and further you will be finally be able to access your TARDIS from PHP code:
The good news is spreading all over Twitter and in PHP mailing lists, as frameworks and hosting services will never be the same thanks to the use of TARDIS (so much for the Java platform being more powerful for integrating external software.)
What are the advantages of such an Api, directly available as a core extension of PHP? Here's my take.
Translation of pages
You can access the telepathical hooks of the TARDIS to write your pages only one time, and then translate automatically the content by linking the device to the minds of your users.
Make sure to display an EULA, or some I Accept checkbox, before diving into this feature. However, i18n is finally solved!
Disclaimer: as you can see in the example on the right, it does not work with images for now. It seems that translation of image-contained text is covered by a patent that Gallifreyans couldn't obtain.
Dimensional trascendence
As you know, TARDIS interior is in a different dimension from the exterior appearance. This space is suitable for server clusters and other technology: for example by moving your TARDIS to your server room, you will have an enormous capacity for scaling as it can contain an huge amount of racks.
You may have to install some additional cooling mechanism, however.
Chameleon Circuit
You can rent rack space from other companies, but how can you make sure they not fiddle with your servers? You can simply link them to the chameleon circuit of the TARDIS. Their appearance will merge with the background, and no one will be able to find them without your permission.
But that's not all: you can also link newly spawned virtual machines to it via the PHP Api, so that they effectively disapper in the cloud and remain unreachable from attackers!
Teleportation
You can now physically access your production servers in case something is wrong and teleport them to the colocation site for production.
When this PHP script is executed (it can be chained to the failure of tests or to repeated failures of the db connection, or to the detection that someone wants to access your private customer data), the servers linked to the TARDIS are teleported back:
My conclusions
PHP is going to be revolutionized and empowered by the TARDIS integration. You'd better hurry up and join a startup based on this new technology - visit the project page for more information on TARDIS-enabled PHP.
$t = new Tardis("192.168.0.4"); // the IP address of the TARDIS $t->configureOwner(11); // only numbers from 1 to 11 supported // but we'll eventually get to 13You see the innovation here? PHP is providing a new extension with an object-oriented Api instead of a bunch of tardis_*() functions which take as parameters strings, arrays, integers and resources. Indeed we have jumper into the future.
The good news is spreading all over Twitter and in PHP mailing lists, as frameworks and hosting services will never be the same thanks to the use of TARDIS (so much for the Java platform being more powerful for integrating external software.)
What are the advantages of such an Api, directly available as a core extension of PHP? Here's my take.
Translation of pages
Homepage of TARDIS-powered Google Deutsch. |
Make sure to display an EULA, or some I Accept checkbox, before diving into this feature. However, i18n is finally solved!
Disclaimer: as you can see in the example on the right, it does not work with images for now. It seems that translation of image-contained text is covered by a patent that Gallifreyans couldn't obtain.
Dimensional trascendence
As you know, TARDIS interior is in a different dimension from the exterior appearance. This space is suitable for server clusters and other technology: for example by moving your TARDIS to your server room, you will have an enormous capacity for scaling as it can contain an huge amount of racks.
You may have to install some additional cooling mechanism, however.
Chameleon Circuit
My home servers |
But that's not all: you can also link newly spawned virtual machines to it via the PHP Api, so that they effectively disapper in the cloud and remain unreachable from attackers!
Teleportation
You can now physically access your production servers in case something is wrong and teleport them to the colocation site for production.
When this PHP script is executed (it can be chained to the failure of tests or to repeated failures of the db connection, or to the detection that someone wants to access your private customer data), the servers linked to the TARDIS are teleported back:
$tardis = new Tardis(...); $tardis->query('SELECT * FROM servers WHERE failed IS NOT NULL') ->fetchAll() ->teleport('22031', 'Italy');Of course substitute my parameters with your ZIP code and country. And yes, the TARDIS speaks SQL.
My conclusions
PHP is going to be revolutionized and empowered by the TARDIS integration. You'd better hurry up and join a startup based on this new technology - visit the project page for more information on TARDIS-enabled PHP.