7June2010
Posted by Tomasz Łasica under: agile pm; it.
I completely agree with Manifesto For Software Craftmanship, I love the book “Clean Code” by Robert C.Martin. And I really try to create a clean code (and still do not get it right in many cases, as it is an neverending process).
I read the manifesto and try to combine it with the 12 principles (http://www.agilemanifesto.org/principles.html):
Not only working software, but also well-crafted software
Simplicity–the art of maximizing the amount
of work not done–is essential.
Not only responding to change, but also steadily adding value
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Not only individuals and interactions, but also a community of professionals
Continuous attention to technical excellence
and good design enhances agility.
Not only customer collaboration, but also productive partnerships
Business people and developers must work
together daily throughout the project.
15April2010
Posted by Tomasz Łasica under: it.
It seems that Agile Manifesto is very relevant for raising up kids. Let’s take a short walk through it:
Individuals and interactions over processes and tools
Your kid is always more important than the way you imagined the growing up may look like. You’d better talk and cooperate with your kid than try to force her to follow any well-organized process. Using tools may help, but only if you use them to interact.
Working software over comprehensive documentation
You have to find the time to watch your kid “in action”. This is the working software you develop. It is not enough to track notes from the kindergarden or school.
Customer collaboration over contract negotiation
Do not force your proposals. Treat your child as a valuable person, with appropriate respect. In most cases you can find a win-win strategy, even in rather complex situations. Please remember, that it is your responsibility to find the best solution.
Responding to change over following a plan
When you bring up small children the situation changes every minute. So be agile and adapt. If you plan something observe and change your plans. Goinf for bike when your child has completely wet paints might not be a good idea.
11April2010
Posted by Tomasz Łasica under: it.
After downloading Eclipse for JEE Developers I’have installed vaadin plugin for Eclipse. I had some minor problems with starting a new Vaadin Project:
- according to the startup guide I should be able to choose a Server run-time for the project (e.g. Tomcat 6). Unfortunatelly it was not avaliable – I had to install it additionally. In fact it was not required, because vaadin comes with built-in jetty which can be used when running and debugging apps.
- the same problem was with the vaadin version – one has to download it
One of the most usefull things was that I can simply choose my project directory as a place for sources and builds when creating new Vaadin Project. It solves the problems I described in the previous post.
And one more thing – The Vaadin Book is briliant.
7April2010
Posted by Tomasz Łasica under: it.
I decided to use GIT (git-scm.com) because I want to practice with it (I used RCS, CVS and subversion before).I work on Windows platform (I have to, I share workstation with my wife) and this platform is not a git-supported one. But look, there is a TortoiseGit available !
TortoiseGit or TortoiseSvn is one of the best tools you can use on Windows.I installed the msysgit than tortoise and voila ! You can now create git repo with RMB popup.
One of the most frustrating problem for me is how to keep sources in your VCS-managed directory and work on it in the Eclipse workspace. I will write it in the next post.
7April2010
Posted by Tomasz Łasica under: it.
I decided to create a simple application to track my water usage and compare results with my friends. Application should be available in the Internet and should be so simple, that anyone would use it.I write this story (I hope it will be a sequel with happy-end) to show the full lifecycle of the application.
First of all I decided to write a Vision Statement, containing following informations:
- Functional vision (what are the major users and how they use the application)
- Business vision (what are the benefitients and their benefits, what can I have from the project)
- Architectural/Technical vision (tools, technologies, frameworks, etc.)
- Organizational vision (how do I organize work, sources, build, tasks management etc.)
Then I decided to have some show analysis of current technologies.I decided to:
- use GIT as VCS
- create the system as a N-tier Java-based App with separated presentation layer
- use GWT and vaadin framework
- use Eclipse as an IDE
22February2010
Posted by Tomasz Łasica under: book; it.
I have finished the book in December.After few weeks of work I can say that I do not remember particular guidelines or code smells. But since then I look at the code and see how it can be improved. I put more impact to write and keep the code clean (despite the fact that nowadays I almost do not code).This book is simply great. This one of the books which I could read from time to time just to remind me how important it can be to write clean, readable code.
11November2009
Posted by Tomasz Łasica under: book; it.
I’ve started reading the book ‘Clean Code’ by Robert C. Martin. In the beginning it presents some definitions of the clean code provided by famous (and valuable) programmers or generally computer science people like Kent Beck, Ward Cunningham etc.I decided to give my owne definition of the clean code and verify it after i finish the book.
Here is my definition:
The code is clean, when I can get to the code after 3 months, read it, understand it and I do not want to change it.
Let me briefly explain what I mean:
- First of all my long-term memory is rather poor, after 3 months I usually do not remember my own ideas. So if I can get back to the code anyone else will be able to do the same.
- I want to be able to read the code, which means it will be so structured, formatted and named that it will be quite easy to follow the code top-down, navigate through the classes and methods without huge effort.
- I want to understand my concepts from the very first look at the code, without reading comments for methods or documentation.
- I have observed (it is quite obvious) that coding is an never-ending process. Usually if I get back to the code I was proud 3 months ago I see many potential improvements on different levels (in the names, algorithms, OOD etc.). I would like to write the code which I would not like to improve when I came back to it.
I suspect that reading this book will change my point of view on coding, even I am quite experienced guy.
16September2009
Posted by Tomasz Łasica under: it.
Well, it is the boost library (see www.boost.org)
14September2009
Posted by Tomasz Łasica under: it.
It is a real story. Once upon a time a programmer wrote some code in the automated test in C++:
...
result = 2 * result;
...
It was the C++, so it could be written shorter. But the reviewer of the code spotted that due to current implementation it is no more necessary to multiply the result by 2. And she put a comment on it to the review tool. What was the result?
...
result = result;
...
Well, I am not sure what was the reason. Was it only a mistake or was it caused by many years of work in the culture of measuring programmers efficiency by lines of code and treating refactoring as a cause of all evil?
AFAIK early optimization is rather the cause…)
11September2009
Posted by Tomasz Łasica under: it.
Lightweight, incremental code review seems to be quite usefull to improve the quality and readibility of the code. As I wrote in one of the previous posts, it requires to be short enough for keeping good review quality.
In many cases the review procedure is done by generating diff to be reviewed, so only the modified code (and maybe some context around the code) is presented to the reviewer. It make the review easier and of course less boring 
But this practice can cause you miss important bug.
Imagine that you created class with equals() method:
class Foo {
...
public:
boolean equals( const Foo & v) const {
return ( v.x == x );
}
...
private:int x;
};
You make a diff for the reviewer, he got the whole class and everything looks fine.
Then (maybe due to some optimization or another reason) you add new attribute to the class, but forget to change the Foo::equal() method. You pass the diff to the reviewer. The diff does not contain equal() method at all ! (because you did not change it).
For sure, the reviewer should take a look at the whole class (not only at diff file) if a new attribute have been added.
For sure it should be detected by unit tests (sure you have them, correct ?).
But unfortunately I’ve seen this kind of but which lasts almost 2 years, before it was detected after >10 hours of gdb debugging.
So my advice is:
- write precise unit tests (for methods, not special cases of using the class)
- take some time and review the code before you pass it to the reviewer
- if you make the diff basesd review and see modifications in attributes look for the places in code when the oldest one was used
- do the targeted review for all attribute sensitive methods (copy constructors, operators, equality, swap, etc.)
