That friend
The one who sticks closer than a brother
And on whom you can count to any extent
Let them know
That caring mother
The one who is always there
And thinks so highly of you, like no other
Let them know
That special person
The one you enjoy so much to be with
And is always full of love and affection
Let them know
Let them know, in what you say
They’re prized gifts from God
In all and every possible way
Let them know, in essence
They’re fresh-scented flowers
Set on our path with a pleasant fragrance
Let them know, every day
Both in small and big acts alike
Do it now! Do it often! Do it always!
A kind word, a gentle smile, a loving act
Simple things that make life so wonderful in fact
A heartfelt compliment, a warm hug, a tender kiss
Expressions that truly bring about such a bliss
Little gestures, don’t take them for granted
What are you waiting for? Go do it:
Let them know.
(Alexandre Gazola – 28/12/2012)
I’ve been listening to an inspiring 4-part series on natural wisdom by Juan Vereecken and Roberto Bautista. In this post, I’m going to summarize some of the things that I learned about the wisdom related to ants. If you understand Spanish and want to listen to the messages yourself, they can be downloaded here.
“Four things on earth are small,
yet they are extremely wise:
Ants are creatures of little strength,
yet they store up their food in the summer (…) “(Proverbs 30:24, 25 – NIV)
Ants are wise because they store up their food in the summer so they’ll have enough in the winter. What is the principle here? Preparation. They get ready for the winter that eventually will come, before it comes. By preparing ourselves for the “winters” that will surely come along, we’re going to be secure.
Now there are things that we know they’ll come and when they’ll come, such as starting a new job, getting into the university, having a child (for some couples), etc. Besides, there are things we know they’ll come but we don’t know when, such as the loss of a loved one. There are still things that we don’t even know whether they’ll come, such as a rough financial situation, a disease, etc.The question is: what can we do before those things happen? The ants give us the answer: we ought to prepare ourselves beforehand. How can we do that? Some of the ways include:
- Establish firm criteria before things happen – Roberto gave as example two criteria he and his wife established in their own life: one is to not start something new in life with debts and the other is when they can’t seem to come to an agreement over any issue, they’ll look for a third-party’s opinion. Other firm criteria he mentions include not marrying a non-christian person, not having sexual intercourse before marriage and so on and so forth.
- Have right expectations toward people and toward life – this one is huge! What disappoints us is not the people or the situations of life, what disappoints us is our expectations toward them. Many people tell their spouse or their friends: “You’ve disappointed me!” In fact, they’ve disappointed themselves because of the high expectations they placed upon others. As tough as it may sound, that’s sheer reality. People get frustrated all the time because they have unreal expectations toward others. What’s worse, the people we love the more are the people who let us down the more, because they are the ones we expect the most from. Therefore let’s learn to have balanced expectations toward people and toward the circumstances of life. We ought to learn to give others the benefit of the doubt and make allowances for their mistakes. This will build up a healthy emotional protection for our lives.
- Eat healthy food and exercise yourself regularly - when you take care of your health by eating appropriately and doing physical exercises, you’re protecting yourself against health problems.
- Save money – it’s important to have a financial reserve to help you when unexpected events come along. Unforeseen things quit being unforeseen when you protect yourself against them in advance.
- Take care of your relationships – with God and with people - there are people who have never bothered to grow their faith, who never spend quality time with God. The time will come when they’ll need God’s help and, by then, will find themselves in trouble because they have not taken time to develop a steady relationship with God beforehand. How can we avoid that to happen in our lives? By spending daily time with God, praying and reading the Scriptures. In addition, we should take good care of our relationships with other people. Choose wise friends and invest time on them as well! Invest time on your main relationships, your family and friends. But do that in a systematic way! For example: every Friday night you’re going to spend with your spouse; every week you’re going to call your loved ones that live away from you, etc.
This simple message, extracted from the life of ants, is full of wisdom. In the next days, take time to think of how you can better prepare yourself in advance against the winters that will eventually come. Don’t forget that the best time for one to do that is in the summer, when things are well, because when the winter comes, it might be too late to do something about it.
Last year I finished reading the excellent book Domain-driven Design, by Eric Evans; but it was not until now that I’ve managed to put aside some time to write about it.
In a time when we have lots of different kinds of cool tools and technologies, it can be easy for us developers to become entangled in those issues and forget to pay close attention to the core problem domain. The approach of Domain-driven Design (DDD) shifts the focus back to the domain, joining together developers, users and domain experts through the use of a common language, spoken and understood by everyone: the ubiquitous language. With the terms of this shared language, we can develop a model which will be used to drive design (hence the term “model-driven design“). The idea is for the code to faithfully reflect this model. This approach enables excellent communication among the stakeholders and empowers the design with the richness of the domain which in turn makes it possible for the system to evolve more easily as the users demand new features.
And that’s Domain-driven Design in a nutshell! Simple, isn’t it?
Yes, that is DDD. However, putting that into practice is a whole different thing. In the book, Eric Evans explains how to apply DDD, what are the some of the challenges and difficulties, how to express the model in code, supple design, patterns, large-scale structures, etc. I definitely recommend reading the book, especially parts I, II and III.
Just one more comment to finish this post: I came to the conclusion that it is virtually impossible to apply DDD without continuous Refactoring. This happens because the ubiquitous language and the model are constantly evolving as developers and users gain new insights. Actually, coming up with a good model is a strenuous task and, therefore, things are likely to change often (especially at the beginning of the project) and the code needs to easily accomodate these changes. Since it’s unwise to do refactoring without automated tests, some flavor of Test-driven Development is highly desirable as well.
My new article on MundoJ magazine (former MundoJava) is out, after about one year without publishing. In this article, my colleague Rafael Pereira and I talk about an interesting but rather unusual topic: public competitive examinations (the best translation I found for “concurso público”, in Portuguese) in IT. The idea for the article came from the desire to help announce the publication of Rafael’s new book, whose subject is Java for public competitive examinations.
Different from what happens in other countries, here in Brazil the candidates for a job position in public companies must pass these kinds of exams; and they are highly competitive. In the article, we go over the advantages and (a few) disadvantages of working at public companies, with emphasis on the IT industry. At the end, we present some questions of real exams with answers and comments (the questions concern primarily Object-orientation, design patterns, Java SE and Java EE). We appreciate any feedback on the article.
Last weekend I took part in QCon Sao Paulo, the Brazilian edition of one of the main worldwide events of software developers and architects. The conference had a strong focus on issues related to scalability, cloud computing and replication in addition to Java, .NET, Ruby/Rails and Agile. Redis and memcached were two of the most mentioned tools used to deal with scalability issues.
Nick Kallen, Systems Engineer of Twitter, talked about how he designed and evolved solutions to deal with some of the fundamental types of data of Twitter: tweets, timelines and social graphs. Each of these real time data had different datastore needs. He discussed how the original solution to store the data in MySQL did not scale well and then went on to present the datastore strategies they created to meet their specific needs. They exploited techniques like master-slave replication with memcached for reads, data partitioning, temporal locality and indices. A recurring pattern to achieve efficiency and scalability that was identified was to partition, replicate and index the data.
Guilherme Silveira talked about REST, semantics and the future of the web. He presented some ideas that can be used such as exploiting the power of links, microformats with hypermedia, addition of semantics and the existence of a shared vocabulary.
Randy Shoup shared some of the best practices for large-scale web sites based on his experience as a chief engineer at eBay. Some pieces of advice were: 1) partition everything; 2) asynch everywhere; 3) automate everything; 4) remember that everything fails. He’d already presented this talk at QCon San Francisco in 2008 and it can be watched here.
Douglas Crockford presented about the future of JavaScript (or ECMAScript as he pointed out). He went through some changes that are being proposed to the language, especially better math support.
Rodrigo Yoshima talked about the method war we are witnessing these days: Scrum vs XP; Scrum vs Kanban; PMBok vs Scrum; Lean vs XP, etc. He reminded that the most important value of Agile is to deliver value more rapidly. We can be applying a handful of agile best practices but if we don’t stick to that one principle we won’t truly be Agile. He also pointed out that there is no such thing as a closed scope in software development.
Paulo Silveira talked about the blurry distinction between architecture and design; and also between design and implementation. He quoted several renowned authors and his conclusion was that “architecture is every decision that impacts in a big trade-off and can or not be difficult to change”. It also can be evolutionary (last responsible moment). When questioned about whether it makes sense to be a “java architect”, he replied with a quote by Joel Spolsky that says we need at least one architect with great experience on the chosen platform. Paulo then went on to discuss (with some real examples) the role of design as a key element to being able to make changes both to the implementation and the architecture of a software system.
The event had several other good talks that I won’t describe here. The organizers are working to make the talks available on InfoQ.
Say you have a class with 40-something methods, doing a number of different things… You, as a great software developer, identify that as a bloater smell and wisely conclude that code cries out for a refactoring. Sounds pretty reasonable. Nevertheless, you’re neck deep in work now trying to meet the deadline for the next release. So what you do? You simply leave a TODO comment next to the code for you to perform that change as soon as you have enough time available.
// TODO: This class is doing too many things. Refactor!
public class BloatedClass {
// 40-something methods
}
That’s it! Now you move on with your next task feeling good about yourself because you think you’ve already handled the problem “appropriately”.
“What’s wrong with that?” – you may ask – “after all, I do intend to deal with that later” . Come on, my friend! Let’s be realistic and face the facts! Chances are you’ll forget about that comment and it will remain there forever since neither you nor anyone else on the team will have the guts to carry out that refactoring afterward for fear that something might stop working. This happens because if you remember that comment, you’ll probably already have lost the general context that surrounds that code and thus you may not have enough confidence to refactor. Worse comes to worst when there isn’t a good suite of automated tests to back you up. As a consequence, your fellow workers will have to work and get along with that poor legacy code.
Bottom line: it’s best to try to keep yourself from adding TODO comments to your source code in the first place (in fact, this applies to code comments in general); but, if you do, make sure you don’t forget about them (Eclipse has a “Tasks view”, which can be useful to track those notes). Those comments might be indications of technical debt that you need to be mindful of, yet more often they’ll just be deodorant for poorly written code.
After nearly two years of procrastination, I finally finished reading Fred Brook’s classic “The mythical man-month: essays on software engineering”. It has lots of useful insights on software project management and development. Rather than making a summary, I’ll just go over the pivotal concept found in the book: conceptual integrity.
The author goes at great lengths in how to achieve conceptual integrity in our software products. From my understanding, he considers conceptual integrity as a user-centered view of the software system; and, therefore, it’s something deeply connected to ease of use. For the author, this is the most important thing to consider in system design. There are severe challenges that stem from large programming projects, where division of labor can make it harder to preserve conceptual integrity. And that’s why he suggests the role of the architect, who is the person responsible to envision the system as a whole and make sure the conceptual integrity will be preserved. As I mentioned, Brooks used this concept primarily to talk about the software product as perceived by its users. In my view, the idea of conceptual integrity is one also to be pursued and applied to the more inferior levels of the software system (e.g. software design, code). On a project using Agile practices, such as XP‘s collective code ownership and emergent design, good communication is crucial to achieving conceptual integrity in code.
The book is mandatory reading for any developer or software development manager. The phrase “there is no silver bullet”, for example, which has become something of a cliché in our industry, comes from an author’s paper “No Silver Bullet – essence and accident” and it was included as a chapter in the book.
Nevertheless, I do consider some parts of the book to be dated (the book was first published in 1975!). If you have little time, in a first reading consider reading chapters 1, 2, 3, 4, 7, 10, 11, 13, 16 (No silver bullet), 17, 18 (this chapter is a nice summary of the whole book) and 19 (this is a review of the original publication after 20 years). After reading this book, you may also consider reading the author’s new publication “The design of design” (I myself haven’t read it yet, but have seen good comments about it).
As a side note, I liked seeing the author use some bible-inspired thoughts to make some of his points in a technical book. A few areas of knowledge (e.g.: management, oceanography, etc.) have already benefited somehow from the wisdom found in the Scriptures. We still have a whole lot to learn in our craft and I really think the Word of God can be a source of inspiration no matter the subject matter. I finish this post with a quote by Brook’s himself:
“We need a God-given humility to recognize our fallibility and limitations”.
This blog completes one year today. It took me a while to start it, mainly because I didn’t know if I would have time to write (interesting) things regularly. Well, it turned out I’ve really liked the experience so far.
Among other benefits, with the blog I force myself to write down book reviews, which makes me review and ponder a little about what I read. I also like to summarize the talks I hear in events I go about software development as well as Christian messages. For this second year, I’d like to increase the number of general posts related to something other than books and events.
The blog still has modest numbers: 22 posts, 30 comments and 1,976 views (tracked by WordPress). I hope to improve on those.
“I will exalt you, my God the King;
I will praise your name for ever and ever.” (Psalm 145:1)
