Moving...

I'm moving from blogger to wordpress and I got a new domain! In the next few days I'll be fixing some issues from the imported data, cleaning up old stuff and theme tuning. Here's is the new url: http://marcovaltas.com

Meanwhile I'll keep the old posts in blogger if eventually someone has a bookmark or a post shows up in Google search.

Best,

Marco Valtas.

Managing Geeks

I just read this blogpost from Patrick Kua which will lead you to this. As Patrick I don't agree with all, but some points got my attention.

Geeks are trained in logic and ordered thought.

With these skills you can't make BS decisions, if does not make sense they will detect it easily. When your IT resists to some business decision, is better check out what is happening, they can function as compass against illogic paths.

Respect is money

In the IT world respect is money. Note that all open source projects work this way. You can't earn respect with nice talk, smiles or other common social weapons. IT guys will respect those who knows what they are talking about and are humble for those things they don't know. Respect is earned with work, good work and team work. Force will just make them shut and let you, or your project, drawn alone. With respect they will follow you, work late and keep you project the best as they can.

IT can't fake work

This was something I never notice but, IT can't fake work (in general). So, anything that sounds like fake you be detected and can't be done at all. Usually other departments (who asked for the impossible) will throw stones on IT, telling that they are slowing the project. In fact, when I saw this, the root cause was a project without value, something to cover incompetence or IT is full and can't deliver at the velocity asked. Is a good thing check what has been asked to IT. In my experience, IT will prioritize by it self. They will not respect illogic priorities and the will organize as they see the business plan. It's very important to make it clear for IT where your business plan is pointed to, if you do, they will take care of projects that point in the same direction.

Conclusion

Well, these are just observations I made through the my years in IT. IT is a very important staff, usually they can spot problems very fast and a good understanding of the minds of IT is a good tool to lead your business to success.

Blog Quick note - disabled automatic line breaks

I just disabled the automatic line breaking option in blogger. Probably old posts will be a lot messy but I can't rewrite them all. Blogger is not the best tool for blogging but is what I have.

The reason for the change is that I'm now writing the posts using Markdown and Vim which makes me a lot more productive in writing for this blog and I hope to write a lot more now.

Best. Marco.

Software Philosophy - Refactoring Paradox

Another day I was talking with a colleague about the Interpreter Pattern to solve a implicit language problem. Martin Fowler describes a pattern called Query Object to solve this, which is a interpreter focused on database queries.

Refactoring as the best technique

Code Refactoring is, after learn a language, is the most important thing a developer should know. Refactoring is what really reveals what soft means in software. When building a bridge is practically a one shot, once the foundations are ready you can´t improve them as the construction continues. But with software, you usually improve the foundations as you go, mostly because nobody knows where is the other side of the bridge you are building.

Refactoring paradox

Refactoring has a implicit paradox, you have to factor before refactor. You can´t, at first, use such good technique without make mistakes a priori. This fact became clear when we had to refactor a code which was growing to cope with combinations of SQL queries. In the book Refactoring to Patterns this problem is described as Replace Implicit Language with Interpreter.

But if you think about it you have to code the queries and many methods to see what implicit language is taking form. Probably you will not foresee the language, if you try to predict such implicit language many anti-patterns and bad practices will rise, such as Premature Optimization, YAGNI and etc. For this particularly problem, if you try to code the solution at first, you will end with a criteria object and without any value from your code since this generic approach already exists.

Frederick Brooks in the Mythical Man-Month wrote about the Pilot System. This idea implies the construction of a throw-away when coding a new system. He argues that if you not plan you will throw-away anyway. This idea agree with the refactoring paradox, you can´t refactor before factor and there´s no need for refactoring a good code, but the chances to get it right on the first try is minimal, I will make a bold statement that is impossible to get it right on the first try.

Conclusions

• Brooks is right, plan to a throw-away, you will anyway, at least part of the code will be replaced.
• Don´t fear rewriting, is part of the job, put it on your estimates.
• Software is soft don´t try to make it hard, is unnatural.

That´s it.

JPA, a little more complex example.

This week I was writing a tool to extract reports from Mantis Bugtrack using JPA and EJB3. Since I´m not good in JPQL (sonething like a SQL for objects) the search for examples began. The problem was that all examples were too simple, here´s some notes one a more complex query and how was done. Mantis is a bugtrack tool and allows a bug relationship and custom fields, my report will make use of both. Below is a simplified diagram of the database tables involved in this process. The scenario was 2 projects. The first (I will call it A) will open bugs for the second (from now called B) the bugs will be related. Example: A operator opens a bug in project A, after that n other bugs are opened in project B, the relation between bugs is B are child of A. This relation is explicitly set using Mantis relationship features which will be reflected in our bug_relationship table. The last thing on this problem is that a custom field value should be retrieved too for a pivot transformation. Here's another diagram showing the relationship:

To not extend too much this post I will show a simplified version of the mapped entities. Gets, Sets, packages and imports were omitted for the sake of the reader.

@Entity
@Table(name="mantis_project_table")
public class Project implements Serializable {
 @Id
 private int id;

 private String name;

 @OneToMany(mappedBy="project")
 private Collection<bug> bugs;

    // gets and sets omitted.
}

@Entity
@Table(name="mantis_bug_table")
public class Bug implements Serializable {
 @Id
 private int id;

 @Column(name="project_id",insertable=false,updatable=false)
 private int projectId;
 
 @ManyToOne
 private Project project;

      //gets and sets omitted
}

public enum BugRelationType {
 DUPLICATED(0),
 RELATED(1),
 DEPENDANT(2);

 private final int relationship;
 
 BugRelationType(int rel) {
  this.relationship = rel;
 }

 public Integer toInteger() {
  return Integer.valueOf(this.relationship);
 }

}

@Entity
@Table(name="mantis_custom_field_table")
public class CustomField implements Serializable {
 
 @Id
 private int id;

 private String name;

      // gets and sets omitted

}

@Entity
@Table(name="mantis_custom_field_string_table")
public class CustomFieldString implements Serializable {

 @EmbeddedId
 private CustomFieldStringPK pk;

 private String value;
}

@Embeddable
public class CustomFieldStringPK implements Serializable {

 private static final long serialVersionUID = 1L;

 @Column(name="field_id")
 private Integer fieldId;
 
 @Column(name="bug_id")
 private Integer bugId;
}

Alright, with those entities in hand how we will compose a good JPQL without access the database more than one time? It's possible? Is possible to join all these entities? Those were my questions. The answer is affirmative, but to do so is not straight forward (at least for me) like when I'm writing SQL.

Here's is the final query:

SELECT 
    bt, cs.value  
FROM  
    CustomFieldString cs,  
    CustomField cf,  
    Project ps, IN (ps.bugs) bs, 
    Project pt, IN (pt.bugs) bt, 
    BugRelationship rel  
WHERE   
    ps = :projSource  
    AND pt = :projTarget  
    AND rel.sourceBugId = bs.id  
    AND rel.destinationBugId = bt.id  
    AND cs.pk.bugId   = bs.id  
    AND cs.pk.fieldId = cf.id  
    AND cf = :customField  
    AND rel.relationshipType = :relType  

Now just fill up the named parameters and you have it, a fairly complex JPQL query.

That's it.

What is keeping me busy

Just a small update on stuff I'm doing in the past weeks.

1. Creating Business Diagrams (BPMN) and Simulations in TIBCO Business Studio
2. Getting serious in SQL with analytical functions of Oracle 10g
3. Studying how to write mathematical proofs (book: How to Prove It)
4. Reading (at last!) the classic Frederick Brooks: The Mythical Man-Month
5. Reading some of Edsger Dijkstra writings

As you can see my current time in learning is devoted to mathematics, oracle and software development management. In short the mathematical is just improve my skills with logic and reasoning, the oracle study is for my current path to OCP and the management studies is for professional growth.

On the shelve (not at particularly order):

1. The Enterprise and Scrum
2. Software Language Engineering
3. SOA in Practice

That's it.

Technology Loop Paralysis - Anti-Pattern

Last Sunday I was in the "Falando em Java 2009" talking with a friend when we got in the subject of new technologies. During the conversation I realized one common anti-pattern that I didn't know about, the Technology Loop Paralysis, TLP for now on.

The TLP has the following major characteristics:

• It's seems right, without attention can't be caught.
• Once started, break the loop is hard.
• Scrambles all current problems, so disguises itself.

So, what is TLP? TLP is just the change of a technology, maybe a framework, a language or something similar to avoid difficulties in development. The catch is, when a new technology is added all kinds of problems will arise.

TLP Examples:

Sometime ago me and another developer had problems in delivering changes to a legacy Java system, the system was poorly designed and any change could break a lot of unrelated features. When the difficulties were explained the manager asked "If we use PHP? Can we fix?". This is a classic TLP. The problem wasn't with the language, any effort had to be directed in refactoring not in language change. Experienced developers will notice that this is trap easy to fall, if the developers were inexperienced and more comfortable with PHP they could fall on this trap.

Another TLP example. In a bugtrack system, developers didn't fill the forms right. Status, ETA and other fields were empty, they also didn't close issues properly. Relations were poorly added and resolutions were not written accordingly. Then, some reports were created to control issues, SLA and so on, but the data was not good. The solution proposed? Change the bugtrack system, but the system wasn't the problem, change it would only disguise all current problems.

TLP Effect:

New technologies will not solve any team, managing structure, unrealistic expectations and similar problems. Once TLP started these problems will disguise as implementation problems.

TLP Name Explanation:

• Technology: Any support system, framework, language or build block to a system.
• Loop: The fact that when faced with problems, the team or management choose change the technology without know root cause of the problems faced.
• Paralysis: The problems can't be solved and despite the feeling that something is been solved it's not.

TLP Forces:

Technologies change and grow more rapidly than our systems, so before a team can finish one project is common that the supporting technologies have new and better versions.

Inexperience and anxiety for new features can lure the team and management to adopt every brand new technology around.

TLP Solution:

Experience to avoid fall in TLP in the first place. During a TLP, the team can stop looping and stick with a technology until it finishes the project. After finished, the upgrade should be considered harmful unless all implications are well understood.