As I said somewhere else in this site, I'm passionate when it comes to programming, seeing it as a craft to be perfected. It is no surprise, then, that I became a confessed Agilist.

Something happened today that made me think about what I think is the meaning to be Agile. The quick answer would be "To value the Agile Manifesto", but somehow I felt that there is more to Agile than that. This is the end result of my musings

Being Agile is more than follow a strict set of practices religiously, that span over all the software development life cycle. It more than trying to go faster, or trying to work better.

Being Agile means to embrace uncertainty, accept change. It means to work on what is actually needed, to produce actual value. It is not measured by the number of practices being followed, or by tagging your process with a methodology. It can be measured by how much we value the manifesto, but the best measure should be the smiles in our users and our team.

Being Agile is more than having a tag or following a procedure. It is a way of thinking, a professional lifestyle, that must be ingrained in the core of the corporate culture, from the C level to the developers, including all the departments.

To become Agile you must be ready to break some paradigms, to challenge the status quo.

Are you ready?




TWiki/Foswiki Facts

user-pic
Vote 0 Votes
Lately there has been a lot of buzz in twitter about TWiki vs Foswiki. Given that there are some inacuracies in both sides, I would like to put some facts so you can form an opinion by yourself.

The main point is that Peter Thoeny, on behalf of TWIKI.NET, imposed a governance model on the TWiki project that was already rejected by the active community[1]. I say imposed because, just minutes before a Release Meeting, everybody was locked down from editing TWiki.org (and I think svn privileges were locked too, but didn't check at the time) and the only way to regain the right of editing or commit was to accept the new governance model.

This offered those that didn't agree with the goverance model a "my way or the highway" scenario. The result is that most members of the active community (80%? 90%?) decided the highway option, and thus Foswiki was born. As a sidenote, several members of the TWiki CoreTeam moved to Foswiki, too. The only remaining member of the CoreTeam as it was in 2008 is Peter Thoeny.

Now, notice that I said "active community". To work with the current number TWiki has a community of about 46,000 registered users[2] . Of those, around 20 where active core developers, and about 20 active plugin developers not beloging to the previous group [3]. This is the group that formed Foswiki. From other 45,000+ users, around 6500 have accepted the governance model. And if you dig enough[4] you'll find that the big majority of them are new users. And almost none of them are now active in twiki.org.

You can compare both communities by checking the following:
For more information check both sides of the story (the relaunch of TWiki.org[6] and Why Foswiki was created)

Update: It seems that I got some figures regarding registered users wrong. Fixed that and added more references. Thanks gmc.

[1] By active community I mean those that actively commit patches, participate in discussions about TWiki on twiki.org or helped make TWiki a better product.
[2] Estimated from here . Around 47,000 topics, minus 1,000 assuming they are bogus or non-users topics.
[3] These figure are offhand estimates. the accurate number can be found by looking the commit history of TWiki in 2008. In the whole TWiki history, only around 50 developers have more than 20 commits.
[4] Use this search in a topic in the Sandbox web: %SEARCH{"META.*?AgreeToTermsOfUse.*?Yes" type="regex" web="Main"}%
[5] Before Foswiki, the top contributors table  in the Codev home topic would only have contributors with at least 20 contribution that month, and the table would be full (10 entries) top contributors reaching at much as 100 edits a month.
[6] You got to love the "And it is important to note that the governance model isn't democratic" part.




Today I was trying to create an equivalent of displaytag. During the exercise I found out few things a didn't know about the behavior of JSP tag files.
My code was as follows:

The jsp:
<mdisplay:table collection="${requestScope.mycollection}">
   <mdisplay:column property="id">
   </mdisplay:column>
</mdisplay:table>
The table.tag file:
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%@ attribute name="collection" required="true" rtexprvalue="true"%>
<%@ variable name-given="item" scope="NESTED" declare="true" %>

<c:foreach items="${collection}" var="item">
    <jsp:dobody>
</jsp:dobody>

</c:foreach>
The column.tag file:
<%@ attribute name="property" required="true" %>
${item[property]} 
Result: didn't work.

 I thought that it was just that I didn't understand the whole "variable" thing in tag files (which was likely), so I change my code the following way:

The table.tag file:
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%@ attribute name="collection" required="true" rtexprvalue="true"%>
<%@ variable name-given="item" scope="NESTED" declare="true" %>

<c:foreach items="${collection}" var="item">
    <c:set var="item" value="${a}" scope="request">
        <jsp:dobody>
        </jsp:dobody>
    </c:set>
</c:foreach>
The column.tag file:
<%@ attribute name="property" required="true" %>
${requestScope.item[property]} 
It didn't work either, throwing an exception stating " cannot find property id in class String"... WTH? It ends up that if you don't specify the type of a tag attribute, it is assumed to be "String". By stating that "collection" is in fact a java.util.Collection, everything worked fine: The table.tag file:
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%@ attribute name="collection" required="true" rtexprvalue="true" type="java.util.Collection"%>
<%@ variable name-given="item" scope="NESTED" declare="true" %>

<c:foreach items="${collection}" var="item">
    <c:set var="item" value="${a}" scope="request">
        <jsp:dobody>
        </jsp:dobody>
    </c:set>
</c:foreach>
It would have been nice that the JSP processor had the capability to infer the type of the parameter, but things are the way they are. Happy Coding!


While getting my daily fix of feed, I found this post on javablogs, describing a "bug" that crawled into the code because a design decision.

The problem they actually had was conceptual one, more than technical. The Comparable interface is meant to be implemented if there is an ordering that inherent to the class (ie, numbers, words, days of week, months, seasons). In their case, ordering by name is not inherent to the SelectablePerson class (you may want to sort by any other field in the future).


I'll follow with another Java quirk in my next post.




I was working in the same application where I found the previous quirk. This time I tried to make a cell renderer put a background color in the cell, to no avail. I even tried to explicitly return a JLabel as the cell renderer, with the proper background color set. Nothing.

The answer to the mystery is the fact that JLabel is transparent by default, transparent components don't render their background, and DefaultTreeCellRenderer extends JLabel.




I have been bitten. ListSelectionListener.valueChanged is called more than once when a selection in a List/Tree/Table is changed. After some googling, I found out that I'm not alone.