On August 26, I will have the pleasure of giving a talk on Architecture as a work in progress at an event organized by the Limited WIP Society Switzerland in Zurich.
One key aspect of dealing with the Work in Progress is to visualize the queues. We have come a long way with dealing with explicit requests that come from outside. But, how do we deal with technical problems that come from within?
Let’s take the architecture of the system. It’s rather important as it can make or break your system in the long run. Of course, the agile mantra tells us that we should emerge the architecture. This sounds great, but how do we make sure it goes in the right direction?
One way to approach it is to make technical tasks explicit and put them in the same queue as the functional ones. This never really works because of two reasons: (1) business can rarely prioritize the work, and (2) it does not fit development workflows.
We argue that it is necessary to approach technical concerns differently. We still need to make them explicit, and we also need a queue. Only, it’s a different queue that is managed exclusively by the team and worked while dealing with regular tasks.
In this interactive talk we show concrete examples of how this works in practice.
Humane assessment is a versatile and generic method. That is both a strength and a weakness. The strength is that it can be applied in many situations. The weakness is that it is perceived to be too distant from concrete scenarios that development teams face.
To bridge the perception gap, I have started to look since a couple of years for classes of problems that are concrete enough to be directly applicable. The first one is that of steering agile architecture for which I designed a 2-day course.
The concept of architecture started to regain traction recently. For example, two new industrial conferences were launched recently on the subject  . That’s a good thing.
However, there are still quite some open questions as to how architecture fits within agile development. Of course, the main focus still tends to be placed on how to create architecture, and less about how to deal with the existing one. Humane assessment fills the latter space quite well. Specifically, the daily assessment process helps teams to make architecture concerns explicit and keep track of what goes on in the system. That is why the course is not about good or bad architecture. It’s about knowing the real architecture of your software system, and choosing to how to steer based on that reality.
If you are interested in working with me, please drop me an email.
Here is a teaser video.
GTSpotter received the 1st prize at the ESUG 2015 Innovation Technology Awards. To celebrate, I downloaded the award badge and admire it from within GTSpotter.
We, the Glamorous Team, would like to thank the community for the trust and for the support. We assure you that we do not take this for granted.
We started on an ambitious project of rethinking the IDE from the ground up. We started with GTInspector and showed how object inspection can be a great deal more than the state-of-the-art offers. Now we redefined searching for objects. These are great milestones, but the road ahead is still long and challenging.
While the Glamorous Team is at the forefront, we cannot do it alone. We need you to work with us and show the world that we can reinvent what was started decades ago in Smalltalk. Only this time we’ll make it happen in Pharo.
Searching for and through XML files can be a common activity during certain kinds of software projects. Yet, the way we deal with these activities is typically rather cumbersome based on a combination of file search tools intertwined with editors.
In this post we show how a workflow like searching for XML files and then inside a target XML is seamlessly supported by GTSpotter.
First, finding an XML file is as easy as navigating through the file system. Let’s say we found our target XML.
The preview shows us the text. But, XML is not text. It’s XML. It has a clear structure, and we should be able to search in terms of that structure, too. Thus, diving into the XML file, exposes the internal structure of the XML directly in GTSpotter.
In our case, the XML contains a catalog of books and related details. If we want to find for books, we can simply search and the elements are matched. Again, selecting an element offers a preview of the corresponding source to the right.
And this interface can be applied at any level within the XML document. For example, diving into a book allows us to quickly spot the author.
But, how difficult was it to implement this? Let’s take a look behind the scene.
Pharo already comes out of the box with extensions for navigating through
FileReference instances. Thus, we only need to focus on the link between an XML file and a way to search inside the corresponding XMLDocument. To this end, we use the diving option of GTSpotter to go inside the
FileReference, and we add a processor that uses the
XMLDOMParser to parse the XML file and provide elements.
self extension = 'xml' ifFalse: [ ^ self ].
title: 'XML document';
allCandidates: [ (XMLDOMParser parse: self) allElements ];
itemName: [ :element | element gtDisplayString ];
Similarly, we also extend the
XMLNodeWithElements with a processor that can search throughout all elements.
title: 'All elements';
allCandidates: [ self allElements ];
itemName: [ :element | element gtDisplayString ];
The cherry on top comes in the shape of the preview. To offer the preview for an XML element, we another simple extension:
display: [ :anElement | self prettyPrinted ];
As these extensions are specific to the XML Parser project, they are naturally packaged in that project. This pattern is followed by other packages and it scales well.
That is all. With a very small investment, we provided a support for a custom use case. Even more interesting is that even though the interface is generic, it still matches quite naturally on our non-trivial use case.
GTSpotter can look deceptively simple, yet the potential is tremendous.
GT Spotter, the novel Pharo search interface, just entered the ESUG 2015 Innovation Technology Awards competition.
GT Spotter is part of the Glamorous Toolkit project and it offers an elegantly uniform search interface for any objects, including classes, packages, methods, senders, files, playground pages, examples, projects, and even your custom objects. It can be easily extended, currently featuring more than 100 such extensions.
Here is the original trailer:
And an updated overview slideshow: