10 anos da revista MundoJ

mundoj

A edição deste bimestre da MundoJ marca os 10 anos da revista. Aproveito a ocasião especial para contar como me tornei autor de artigos dessa publicação (também vai ser o primeiro post em português do blog).

Tudo começou em 2003, quando eu comprei a terceira edição da revista numa banca, em Viçosa-MG. Era uma edição que falava sobre software livre… Isso foi quando eu ainda estava no segundo ano de faculdade e havia apenas começado a aprender Java (a revista se chamava MundoJava). Lembro-me da dificuldade que eu tinha para entender alguns artigos mais técnicos da publicação. E isso era justificável, pois até então o contato que eu havia tido com tecnologia para desenvolvimento era apenas com programação básica em C++/Java e Haskell (ótima linguagem para programação funcional, por sinal). Eu não sabia nada sobre desenvolvimento para a Web, plataforma Java EE, IDEs/frameworks, sistemas de controle de versões e toda a parafernália correlata com a qual quem trabalha na área está acostumado. Aliás, é bom ressaltar que o curso de Ciência da Computação não ensina essas coisas (e nem é esse o propósito, porque a tecnologia muda muito rápido). Boa parte do curso é composta de Matemática (Cálculo e mais Cálculo…), Física e aspectos teóricos de computação (algoritmos, linguagens formais, redes, compiladores, etc.).  Sendo assim, era (e ainda é) fundamental “correr atrás” e buscar livros e qualquer outro material que pudesse complementar a formação acadêmica teórica com as competências técnicas mais “práticas” demandadas pelo mercado de trabalho. Nesse aspecto, a revista contribuiu para que eu começasse a ter maior contato com todo esse universo.

Passados alguns anos, completei meu curso e decidi seguir no meio acadêmico, fazendo mestrado. Nessa época, eu estava aprendendo sobre padrões de projeto, um dos assuntos que eu mais gosto na área até hoje. Em meus estudos nesse tema, acabei me deparando com exemplos muito interessantes de implementação de alguns padrões usando o mecanismo de reflexão disponível na linguagem Java. Achei o assunto tão interessante e original, que resolvi submeter ao editor-chefe da MundoJava uma proposta de artigo nesse tema, que foi prontamente bem recebida. Depois de alguns meses de trabalho, em março de 2007, tive meu primeiro artigo publicado na revista, com o título “Padrões de Projeto e Reflexão” (edição 22).

Gostei tanto da experiência, que continuei escrevendo novos artigos até que, alguns meses depois, o editor-chefe me convidou para fazer parte da equipe técnica da revista. Com isso, além de continuar escrevendo, passei a revisar alguns dos textos publicados por outros autores. Com as frequentes publicações, de vez em quando, acontece de algum leitor enviar seus comentários e dúvidas por e-mail, o que também é algo bem gratificante.

O que eu vejo como diferencial da MundoJ em relação a outras publicações, além da qualidade gráfica de impressão e do aspecto temático (tentar reunir vários artigos dentro de um único assunto), é a característica de buscar trazer artigos que apresentem contribuições relevantes, ou com exemplos ou com ideias, e que não sejam mera repetição de tutoriais facilmente encontrados na Internet. Além disso, é a única revista nacional que eu conheço que aborda desenvolvimento de software de uma forma mais abrangente (sem o enfoque único em uma tecnologia específica). De qualquer forma, a revista também possui seus problemas, existindo pontos que certamente carecem de melhorias (distribuição é um deles).

Encerro este post, portanto, parabenizando toda a equipe da MundoJ pelas 60 edições publicadas ao longo destes 10 anos. Obrigado pela oportunidade de fazer parte dessa história!

(…) Senhor, Deus meu, graças te darei para sempre.” (Salmo 30:12b)

Book review: Domain-driven Design

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.

Public competitive examinations in IT – MundoJ 45

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.

Three things to remember on a software project

During our daily meeting today, my manager made three interesting remarks about software construction that IT professionals should be mindful of:

1) Don’t build the software system whatsoever – This might sound pretty obvious but many people just ignore it. Many companies, especially those on a loose budget, think a software system will be the panacea for all their business problems and so they just go for it. Therefore, remember: the best software system is the one that doesn’t need to be written.

2) Throw the system away before going into production – It may just be the case that you’ve already started developing the system and maybe are even about to release it into production. Nevertheless, suddenly an idea might strike or a breakthrough might come in such a way that the best thing to do is to throw the system away despite all the effort and resources spent on the project. This reminds me of the essay “Plan to throw one away” of “The mythical man-month“. Therefore, remember: the best software system is the one that doesn’t need to go into production.

3) Build the system using the best industry practices – OK, you’ve analysed the facts, talked to the stakeholders and came to the conclusion the software system is still currently necessary. Well, in this case, go ahead with the project, use the best industry practices you can and build a software with quality that will make your users happy. Therefore, remember: if you do have to build a software system, do it to the best of your abilities.

QCon Sao Paulo 2010

Last weekend I took part in QCon Sao Paulo, the Brazilian edition of one of the main worldwide events for 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.

Watch out for TODO comments!

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.

Book review: The mythical man-month

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”.