Category: tecnologia

10 Suggestions for the Architect of an Agile Team

Tom Hollander, a Solutions Architect at Microsoft Australia, held a presentation entitled The Role of an Architect in an Agile Team at TechEd Australia where he discussed  what he does as an architect leading an agile team.

When talking about the role of an architect, Hollander means a “solution architect’ or an application architect. He does not refer to an enterprise architect or a specialist one (specialized on a specific field like messaging or infrastructure).

Hollander’s team has a 4 week iteration process with a stabilization period – code freeze for a few days – at the end, practices daily stand-up meetings, continuous integrations with daily builds followed by automated tests, and is employing a number of roles:

  • PjM – is the Project Manager, similar to a Scrum Master, making sure the team is following the process.
  • PdM – is the Product Manager, also known as the Customer or the Product Owner, determining what the product is supposed to be
  • Architect – a solution/application architect
  • Dev – the development team
  • Test – the test team
  • UX – the User Experience team
  • Release – the Build and Release role taking care of the building process

Hollander has come up with a top 10 list of things for a solution architect to be successful in an agile team:

  1. “Just enough” upfront design – except for very simple projects, a certain amount of upfront design – 1-2 weeks – is absolutely needed based on what type of application is – web app, smart client, mobile or batch –, what are the basic functionality requirements, a long term solution or an intermediary, temporary one. The purpose of the upfront design is to decide: what technology to use – for example, ASP.NET or MVC –, what type of application – a 2-tier, a 3-tier or a service-oriented application –, accessing the DB – stored procedures, Entity Framework, LINQ, DI. All that can be contained in a short document for reference.
  2. Start with a vertical slice – means starting with a small piece of functionality – a logon page, for example – which cuts as many vertical layers as possible in order to tie together all the technology pieces decided during the previous phase. This will demonstrate that the design decisions are correct and all pieces are working together, and will represent a pattern for developers to follow when developing the additional code. If the initial design decisions turn out to be inappropriate, now it is a good time to change them.
  3. Just-in-time design each iteration – At the middle of a 4-week iteration, the project manager, the product manager and the architect should meet to discuss the requirements to be addressed during the following iteration, to make sure they all agree on them, what is more important is put up in front, and everything is understood. That discussion goes on for a week in the background of the current iteration. The following week, the last of the current iteration, the architect reviews the requirements for the next iteration, making the necessary design decisions so the team can start working on them the following week. If the requirements are quite different from previous ones, then the architect does some prototyping, writing some code as a proof of concept, writing some diagrams and putting it all together in a 5-page document for reference. This is not meant to do detailed design decisions made for the developer, but rather to make sure the new requirements fit into the big picture.
  4. Trust your team… but be there for them – this has to do with the relationship architect-developer. The architect needs to make sure he does not overstep his role, making the developer’s job boring by taking all the fun of decision making. In the same time, the architect needs to be a mentor for the team, solving difficult problems that might bog down the developers. The architect should be in contact with every developer each day, knowing what they are doing and helping them if there is a coding problem. This is especially needed when dealing with developers that don’t like to ask for help and try to solve problems on their own with the price of spending an entire week with that. This kind of relationship also applies to the PjM and test/build/release team.
  5. Write code! – The architect should know what’s in the code in order to have a better idea on the impact of his decisions. He can also figure out when a refactoring is needed. A code writing architect has better credibility with the development team. That being said, Hollander does not believe in role dissolution. He still thinks an architect remains an architect, and he’s not necessarily as good at writing code as a regular developer.
  6. Be involved in everything – It is good for the architect to be involved in all meetings related to his project: design, development, code reviews, requirements planning, etc., because he can have a larger and more clear perspective on what is going on, and he can help the product manager to avoid making wrong decisions in an early stage by informing him/her on their possible outcome.
  7. Drive a culture of quality – A successful team, one that anyone would like to be part of is one built on a culture of quality: nobody cuts corners, nobody checks-in sloppy code, if there is a major flaw in the design it won’t pass unnoticed, all are honest and open, looking for the best outcome of the entire team. Hollander admits that it is hard to build such a team, but it is possible. Firstly, the architect should establish some rules in the beginning, rules are are not going to change over time because a developer happens to not like them. One example is the decision to write unit tests. Another is having a code review before each check-in, including the code submitted by the architect. If the code is not accepted by the reviewer, which can be anybody in the team, the code is not checked-in.
  8. Know when changes are required – The architect should be very flexible and ready to make design changes when they are required. It may be that an early solution is no longer appropriate, or new requirements demand a different approach.
  9. Shield the team from external randomization – While this is usually the job of a project manager/Scrum master, the architect can get involved in protecting the team from external requests that tend to divert the team’s focus and take time from actual work. One example could be various requests coming from the operations team wanting certain things to be done in a certain way, and their requests are not always reasonable or something that has to be implemented.
  10. Write docs … but only if someone needs to read them – Hollander is not the adept of documenting everything, nor one of writing no documentation. He thinks there is necessary to have a balance, writing the amount of documentation that is actually helpful and is read by someone. Documents are good to remember detailed design decisions like a data model. Iteration design decisions, while they are discussed with the team at the beginning of the iteration, it is recommended to be saved in a 5-pages document for the developers to go to if one of them does not remember what the architect said. This also helps new people working on the project long after the initial developers and architect moved to another project to understand why some of the decisions were made.

As a conclusion, Hollander said the architect should make sure he is part of the team in theory and in practice. The architect is not supposed to write all the code, only a small portion, he is not testing or deploying it, but he is rather making sure the entire process runs smoothly.

Minimalismo

O fino equilíbrio de tão pouco é uma visão bem-vinda em um mundo tão ocupado. (Patrick McNeil)

Menos elementos, site mais rápido,  direto ao ponto, fácil de consumir, difícil de distrair, conteúdo óbvio, menos tempo perdido… onde menos é mais. Minimalismo é o termo pela arte e pelos círculos de literatura, para descrever um movimento em direção à simplificação extrema da forma e da cor. Como dizem os designers, foca a usabilidade, a estética e permite que o conteúdo seja a estrela.

The New Wallpapers and Theme of Ubuntu 10.10

Marcus Nestor, Softpedia, talks about seventeen new beautiful
wallpapers and a lightweight and eye-candy theme the he says will
please every existing and future Ubuntu 10.10 users!

To see the screen shots of these new looks for your desktop go to:

http://news.softpedia.com/news/The-New-Wallpapers-and-Theme-of-Ubuntu-10-10-153934.shtml

Microsoft won’t stop .Net on Android

Oracle’s patent and copyright lawsuit against Google for its use of Java in Android won’t be repeated by Microsoft if .Net is used on the Linux-based mobile operating system instead.

Director of the open source technology centre at Microsoft Tom Hanrahan said the Community Promise allows projects like Mono to fully support its technology.

“The type of action Oracle is taking against Google over Java is not going to happen,” Hanrahan said.

Microsoft’s Community Promise has made the .Net runtime and C# specifications available to Miguel de Icaza and the Mono project developers.

“If a .Net port to Android was through Mono it would fall under that agreement,” he said.

Hanrahan is visiting Australia for Microsoft’s annual Tech.Ed conference.

Novell has already developed MonoTouch for Apple’s iOS-based devices like the iPhone and iPad, and a Mono port to Android, dubbed “MonoDroid”, is on the roadmap, due for a preview release in Q3 this year.

“Mono for Android will have an entirely different set of APIs, at most you would be able to reuse business logic, but any user interface and device specific code will have to be rewritten,” according to the Mono developers.

Oracle’s complaint against Google centres around its development of the Dalvik virtual machine that can run applications written in Java.

Dalvik is not an officially sanctioned Java runtime environment, however Sun did initially praise Google for supporting Java on Android.

Potential conflict between Sun and Google over Dalvik was also predicted back in 2007, but did not eventuate until Oracle acquired Sun.

With Java use in Android under fire, Microsoft is unlikely to disrupt any port of C# to the mobile platform, however, Microsoft’s Community Promise has been criticised by the Free Software Foundation for not going far enough to protect open source implementations from patent litigation, which is at the heart of the Oracle-Google case.

“The Community Promise does not give you any rights to exercise the patented claims. It only says that Microsoft will not sue you over claims in patents that it owns or controls,” according to the Free Software Foundation.

“If Microsoft sells one of those patents, there’s nothing stopping the buyer from suing everyone who uses the software.”

Mono developer Miguel de Icaza is not concerned about legal challenges by Microsoft over .Net implementations and wrote on his blog that Google could switch from Java.

“Google could settle current damages with Oracle, and switch to the better designed, more pleasant to use, and more open .Net platform,” de Icaza wrote.

Rodney Gedda is Editor of TechWorld Australia. Follow Rodney on Twitter at @rodneygedda. Rodney’s e-mail address is rodney_gedda@idg.com.au. Follow TechWorld Australia on Twitter at @Techworld_AU.

References

Automatic Resource Management in Java

Part of Project Coin is the ability to deal with Automatic Resource Management, or simply ARM. The purpose is to make it easier to work with external resources which need to be disposed or closed in case of errors or successful completion of a code block. Consider the following trivial file-copy operation, from the Java Bytestream Tutorial:

FileInputStream in = null;
FileOutputStream out = null;
try {
  in = new FileInputStream("xanadu.txt");
  out = new FileOutputStream("outagain.txt");
  int c;
  while ((c = in.read()) != -1)
    out.write(c);
} finally {
  if (in != null)
    in.close();
  if (out != null)
    out.close();
}

Not only is there a lot of boiler plate, but the documentation for InputStream.close() suggests that it can throw an IOException. (An exception is far more likely on the OutputStream but in any case, there needs to be an outer catch or propagation in order to successfully compile this code.)

The lexical scope of the try-catch-finally block also requires the variable for FileInputStream in and FileOutputStream out to be declared lexically outside the block itself. (If they were defined inside the try block, then they wouldn’t be available inside the catch or finally blocks.)

To eliminate this boilerplate code, and to tighten the lexical scoping of the resources used inside the block, a new addition has been made to the try block in the Java language. An initial specification of the try-with-resources blocks (or ARM blocks) was made available via an ininitial implementation, which has subsequently made its way into build 105 of JDK 7.

A new interface, java.lang.AutoCloseable, has been added to the proposed API, which defines a single method close() which throws Exception. This has been retro-fitted as a parent of java.io.Closeable, which means that all InputStream and OutputStream automatically take advantage of this behaviour. In addition, FileLock and ImageInputStream have also been fitted with the AutoCloseable interface.

This permits the above example to be written as:

try (
  FileInputStream in = new FileInputStream("xanadu.txt");
  FileOutputStream out = new FileOutputStream("outagain.txt")
) {
  int c;
  while((c=in.read()) != -1 )
    out.write();
}

At the end of the try block, whether by completion normally or otherwise, both the out and in resources will have close() called automatically. Furthermore, unlike our original example, both out.close() and in.close() are guaranteed to be executed. (In the original example, had in.close() thrown an exception, then the subsequent out.close() would not have been executed.)

There are some subtle aspects to this which are worth noting:

  • As it currently stands, a trailing semi-colon is not permitted after the final resource in the resources section.
  • The resources block is separated with () rather than the more usual {}, to separate it from the existing try body. If present, it must contain one or more resource definitions.
  • Each resource definition is of the form type var = expression; you can’t have general statements in the resource block.
  • The resources are implicitly final; that is, they behave as if the final modifier is present. Any attempt to assign to the resource variable is a compile-time error.
  • The resources must be a subtype of AutoCloseable; it is a compile-time error if this is not the case.
  • The order of closure is the reverse order in which the resources are defined. In other words, in the refined example, out.close() is called prior to in.close(). This permits nested streams to be built and then closed from outer-in, which makes more sense than in order (e.g. for flushing buffers before the underlying stream is closed).
  • Each block may generate n+1 exceptions, where n is the number of resources. This can occur if the main body throws an exception, and each resource closure throws an exception as well. In this situation, the body’s exception will be thrown, but the others will be added to the exception’s suppressed exception list. They can be accessed via getSuppressedExceptions().
  • Exception stack traces may now have code prefixed with Suppressed: in these cases; the format of the serialized Throwable is now different as well. (This may impact Java 6 clients invoking remote services on Java 7 runtimes, or vice-versa.)
  • javax.swing and java.sql do not participate in ARM at the current time; classes need to opt-in by inheriting from AutoCloseable to be used by ARM. JDBC 4.1, if part of JDK 7, will support ARM but it’s not clear when this will happen.

The ability to remove boilerplate code from the Java developer’s work-flow is likely to be a minor productivity boost; but although it’s available in JDK 7, it will be sometime before source code can be written to take advantage of that fact. Many libraries will need to be compiled to run against Java 6; and any use of the automatic resource management will only be applicable for code compiled with -target 7 (or similar). Once Java 6 is EOL and Java 8 has been released, then using ARM will become an automatic way of working.

Original article here