Instant logging: Harness the power of log4j with Jabber

A former collegue of mine was asking me how to see the log if the deploy is on a server with strict restriction… After searching a bit (mail was not good, database neither) I found this funny way to log events… It’s really cool!

Instant logging: Harness the power of log4j with Jabber
Writing an IM-based appender

The code outlined in this article shows how you can extend the log4j framework to integrate IM features. It’s designed to enable a log4j-compliant application to log its output onto IM networks. The IM appender actually works as a customized IM client. However, instead of System.out, files, or TCP sockets, it takes IM networks as the underlying output device.

To provide IM support, we don’t need to reinvent the wheel when developing ad-hoc solutions. Instead, we’re going to leverage a tool we consider the best of breed: Jabber. Jabber is an open, XML-based protocol for instant messaging and presence, developed by the Jabber community and supported by the non-profit Jabber Software Foundation.

We chose Jabber over other IM systems because it offers a wide variety of benefits, including its:

* Open nature: Unlike other proprietary systems, Jabber’s specifications and source code are freely available, allowing anyone to create Jabber implementations at no cost.

* Simplicity: Jabber uses simple protocols based on XML as its standard data format, and follows the well-understood client/server architecture.

* Interoperability with other IM systems: Jabber transport modules make it possible for Jabber users to reach other instant messaging systems such as AIM, Yahoo! Messenger, and ICQ.

* Resource awareness: Jabber provides explicit support for multiple client access. The same user can connect simultaneously to the Jabber server with different clients (or resources), and messages will be routed properly to the best resource available.

Domain-driven Design: What Is It?

Domain-driven Design: What Is It?

What Is Domain-Driven Design?
Over the last decade or two, a philosophy has developed as an undercurrent in the object community.The premise of domain-driven design is two-fold:

* For most software projects, the primary focus should be on the domain and domain logic; and

* Complex domain designs should be based on a model.

Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains.

To accomplish that goal, teams need an extensive set of design practices, techniques and principles. Refining and applying these techniques will be the subject of discussion for this site, generally starting from the language of patterns layed out in Domain-Driven Design, by Eric Evans.

A good article to start understanding the differences from MDD (model driven) and DDD is this article, always from Eric Evans.

Retrospectives

Another great thing learned at the ThoughtWorks immersion are the Retrospectives. In my former projects we had weekly team meetings but they were never effective.

What really can help a team to have more effective retrospectives is the starfish, where the team writes down (or puts stickers) on what Keep Doing , Less Of, More Of, Stop Doing or Start Doing.

I think that this is a good praticse not only at the end of a week or iteration or project release but in your everyday life! It isnt?

A book suggestion now: Project Retrospectives: A Handbook for Team Reviews by Norman L. Kerth.

What about Agile Estimating and Planning?

The best place to start to read something about this stuff is without any doubts the MountainGoat Website, of Mike Cohn. There you can find all his presentations and a lot of articles.

About Planning for example this is a really good presentation, after this I am sure that you’ll buy and read his great book: Agile Estimating and Planning.