Learning BIRT, part 2

(This is the second half of my review for Practical Data Analysis and Reporting with BIRT).

Chapters six through ten cover various ways that reports can be enhanced. Each of these chapters is relatively self-contained, making it easy to refer back for details later when writing reports. Chapter six describes how reports can be parameterized, obviously a necessary capability to promote reuse. In particular the distinction between data set and report parameters in BIRT needs to be understood, and chapter six does a good job in explaining this difference. Also explained are more advanced parameter concepts, such as dynamic, cascading and group parameters. While a number of these parameter concepts are covered quickly, if you are a Java developer as the book assumes, the explanation should be a sufficient overview, and the BIRT documentation can serve to fill in the details.

Report project and libraries are described in chapter seven. By using the Eclipse projects configured for BIRT and report libraries, further reuse is enabled. For example, images that need to be shared across a team of developers creating reports can be stored in libraries, and these libraries are then referenced by each consuming report. As with the previous chapter, Java developers should have no problem understanding these concepts, and the use of specific project types will be very familiar to experienced Eclipse developers as well. Chapter seven also contains a tutorial about reusing resources, and this is useful for checking understanding.

An important aspect of report development is being able to customize rendering. Obviously we’d like to separate rendering instructions from main report data (if possible), so changes in rendering can be made independently. In chapter eight there are examples of several style options BIRT supports: BIRT built-in styles, custom styles, CSS, and style templates. For simple formatting requirements either the built-in style support or slight customizations of it will suffice. Style templates are more useful to apply over a range of reports, probably across groups or departments. Finally, the capability to use CSS allows BIRT users leverage vast resources from that style language. The examples in chapter eight are brief, but detailed enough to suggest the possibilities in each option.

Charts are a common requirement for reports. Luckily, BIRT’s Charting Engine supplies a number of thirteen popular charting options, including scatter, pie, bar and line charts. Further, drill-down (the ability to see more detailed information for a specific chart element) is supported by the Chart Engine. Chapter nine uses the pie, gauge and bar charts in simple, illustrative examples. While table reports are common and useful, you really get to see the power of BIRT as a reporting tool through these chart examples. Well designed charts can convey a lot of information in an attractive form, and drill-down allow you to present additional details without cluttering the initial chart presentation. Perhaps because of the visual appeal of charts, I found the examples in chapter nine more interesting than those in other chapters, and this made me wonder if incorporation of charts throughout the book might have been a good strategy.

BIRT includes scripting support using Java and JavaScript. Chapter ten discusses these capabilities, interestingly starting with a comment that knowledge of Java is useful for understanding the scripting examples. Yet the assumptions stated at the beginning of the book include being a Java developer and, as I’ve mentioned several times, those without Java experience will have to work hard to grasp much of the book’s content. Perhaps in an attempt to limit chapter size or to keep it accessible to those without Java experience, the script examples in this chapter only scratch the surface. A minor criticism: much of the code has pedestrian comments (about things that method names, etc. should suggest) and subsequent paragraphs have explanations similar to the comments. It would have been better to omit these comments, hence making the code more compact. Event handling, an integral part of BIRT scripting, is also covered briefly in a few examples. My feeling is that this chapter should assume a fair amount of experience with Java and the ability to pick up JavaScript while showing more detailed examples. Granted this would increase the length of the chapter and still would only show a fraction of the possibilities, but a more comprehensive example would be more instructive to the (stated) target readership.

The final two chapters deal with report deployment and a case study. The deployment material is good to get started with, and ideally your deployment requirements will fit within the basic cases. But, as is often the case with real world deployment scenarios, likely there will be complications requiring studying further BIRT documentation for alternatives. The working example chapter is only suggestive – to follow the example exactly requires a lot of set up and I doubt few readers will attempt it. As a summary of many of the concepts covered earlier, however, the case study is a nice summary and useful for pulling all of the previous threads together.

In conclusion, I believe John Ward’s book does a fine job of providing a quick start to BIRT. If you are a Java developing using Eclipse and want to take advantage of BIRT, starting with the BIRT “all in one” download and working through Practical Data Analysis and Reporting with BIRT will quickly get you up and running.

Reclipse

Hello everybody out there using Eclipse -

I'm doing a (free)Ruby version of Eclipse (“Reclipse” Just a hobby, won't be big and
professional like regular Eclipse) for Ruby and scripting language clones.  This has
been brewing since last april 1st, and is starting to get ready.  I'd like any feedback
on things people like/dislike in Eclipse, as my Reclipse resembles it somewhat (same
physical layout of the widgets (due to practical reasons) among other things).

I've currently ported JDT(3.4M3) and PDE(3.4M5), and things seem to work.
This implies that I'll get something practical within a few months, and I'd like to
know what features most people would want.  Any suggestions are welcome, but I won't
promise I'll implement them :-)

Stepping Aside…

Three years ago the DTP proposal was posted for community review and at EclipseCon in Burlingame, I first met many of the people who would form the core DTP team. For me EclipseCon this past week marked the completion of that circle, as I have decided to leave Sybase and step aside as the DTP PMC chair. My new position, starting the week of April 7, will be with the JBoss division of Red Hat. I will remain involved in DTP and the wider Eclipse community, working with DTP to help in the transition, and to assist in completing the DTP 1.6 (Ganymede) release.

Last week at EclipseCon there was a lot of talk about diversity in projects. Diversity is more than simply the number of committers or the number of organizations represented. Real diversity is about redundancy in project operations, so staffing changes can more easily be absorbed. All successful projects rely on having the right people, but no successful project should depend on a specific person. I am confident that DTP will succeed after this transition at least as much as it would have under my leadership.

I’d like to thank everyone who supported me and DTP up to this point -- the Eclipse community is really an amazing group of people to work with – and I look forward to continued collaboration in my new role.

Learning BIRT

Recently Packt Publishing contacted me about their new book, Practical Data Analysis and Reporting with BIRT (John Ward), and asked if I would be willing to review it. While DTP and BIRT have enjoyed a close relationship since the beginning of DTP and the early days of BIRT, I have never actually had a chance to use BIRT. Always interested in learning new technology, I figured reviewing the book would be a good chance.

It only takes a few minutes roaming around the Eclipse web site to realize that there’s a lot going on at Eclipse. It seems like new projects appear every week, and existing projects continue to push forward with new features. On the verge of EclipseCon next week, a survey of the Eclipse landscape yield a variety and depth that can be overwhelming. This is true whether you are a new user of Eclipse, or someone involved in working on an Eclipse project everyday.

There’s also no shortage of information about Eclipse. Mature, popular projects like BIRT tend to have numerous articles, books, web casts, and other source of information. The availability of information is great, but it can be hard for new users of a specific Eclipse technology to get up and running quickly. That’s where John Ward’s book fits: in about 300 pages, we are promised a “fast-paced, task-driven, tutorial style” introduction to BIRT, concentrating first on the BIRT Report Designer and later the BIRT Charting engine. OK, this sounds good, and I decided to take it step by step like a new user would. In this post and a series of follow ups, I will discuss my progress and observations. I hope that my commentary is useful for those considering how best to approach BIRT.

The first chapter is an overview of Business Intelligence (BI) and the BI market, with an emphasis on open source options. The author explains how he became interested in reporting tools, and this story helps to put the need for BIRT into the context of challenges that developers face. Frankly, the material in this chapter is a bit disorganized (for example, jokes about the name “BIRT” appear almost verbatim in a couple of places, leading me at first to believe that either the book had duplicated pages or I was reading it backwards.) While the coverage of BI and BIRT is adequate to get the essentials, the sections comparing BIRT to other open source reporting solutions (JasperReports and Pentaho) was sketchy and did not add much. After finishing the chapter, I couldn’t help think that perhaps part of it could have been skipped: the fact that I’m reading tutorial book about using BIRT seems to imply that I know enough about BI/reporting to understand that I at least need to learn how to use BIRT, and the fact that I’ve chosen a book about BIRT itself means that I’ve already made a (perhaps preliminary) choice of which tool to use. I understand that some introduction is necessary, and the first part of the chapter (describing the author’s need for a reporting solution) fits the bill.

The next chapter describes how to obtain and install BIRT. Since Eclipse projects tend to move fast and there are a number of ways to obtain distributions (various download packages, the Eclipse Update Manager), this can be a very confusing area. In fact, we in DTP have often diagnosed problems that arise from installing mismatched versions of various Eclipse components. Luckily, BIRT has an “all in one” download and the chapter recommends using it. I did, and quickly I had a working BIRT installation. (Detail: the chapter talks about the need to download the iText libraries separately. In BIRT 2.2.2, this is not necessary.)

Once you have BIRT installed and running, the first thing you’d like is a quick tour of its main features, and perhaps a simple working example. Chapter three provides this. First the basics of Eclipse (perspectives, views, etc.) are covered, and then a simple report project using the BIRT “Classic Models” sample database is created. This chapter has a “getting started with BIRT” feel, and does a good job of covering the main points in a brief presentation. Within a couple of minutes I was able to generate my first report, and everything worked as expected. Sometimes the hardest part of using software is simply getting the first set of tasks done: once you understand enough to do that, then well-designed software seems to “fall into place” as you learn the rest. Quickly scanning through the books remaining chapters, I found that they seemed to make more sense, now that I understood how to create even this very simple first report.

Of course there’s more to reports than simple charts: we need a variety of components for labels, images, and so on. Chapter four provides a quick tour of these visual components using the BIRT Palette. If you’ve used visual layout tools before, the BIRT components will be familiar, and they interact with the Properties view to set the usual parameters. One interesting difference between the book’s instructions and my development environment appeared when adding an image to the report. The book has us entering the URL for the image directly into a text box, but (at least in BIRT 2.2.2 on my machine), the text box was read-only. I had to open the Expression Builder and enter the URL text there. This was confusing because it seems (according the dialog’s appearance) that you should be able to enter text directly, but in fact it doesn’t work. Anyway, these minor deviations caused me to explore BIRT more, and I quickly understood the options the Palette provides.

After chapter four, the “quick start” feeling fades and the chapters get into more detail. Chapter five covers various ways of working with data sources, and this gives a key insight into the potential of BIRT. Because BIRT has a good assortment of data sources available (for example: databases, XML files, flat files, web services), you can easily imagine aggregating these for business intelligence scenarios. Without going into a lot of detail (and chapter five does cover a lot of ground), by the end of the chapter you will have seen many features provided by BIRT data access through the Open Data Access (ODA) layer. My only concern about the chapter is that, at over forty pages and a lot of material, perhaps it would have been better broken into a couple of separate chapters (maybe one extended example using databases, then another chapter skimming the other data sources?).

The first five chapters cover about one-third of the books length. Introductory material is crucial, since readers will not persist to later chapters if the early learning curve is too steep. My experience was very good: in a few relatively short chapters, I was able to learn enough about BIRT to create some really basic reports, and I felt ready to continue on to the later chapters. In future posts, I’ll discuss my experiences with the rest of the book.

Is DTP 1.6M5 ready?

As we wrap up the DTP 1.6M5 cycle, we thought of trying a more transparent way for deciding to promote the milestone build. We described this method in the Approved Build Sign-off Process for DTP, and it was accepted by the PMC and project leads. So, following this new process for DTP 1.6M5, we designated a candidate build date, produced a candidate build on the designated date and looked for sign-off notices to be posted on the DTP PMC mailing list by the end of last Friday. At best we would have received three sign-off emails, at worst, zero. It only takes a quick scan of the DTP PMC email archive to see that the grand total was zero.

Today we’re essentially back to how we’ve promoted DTP milestones in the past. That is, in the absence of any bug severe enough to delay the milestone, we promote. No severe bugs being found is a good thing, assuming there is testing. One sure way not to find any bugs is simply not to test and hope for the best. Works sometimes with luck, but generally is not considered a best faith effort, especially when your components are the foundation for others in the release train. During previous DTP milestones, I have been smoke testing the builds, and I rely on the project leads to work with their teams to do more complete testing. We think that this testing is taking place, but do we know? Do you want to know?

So, this leads me to my request for this week: I’d like to get feedback from the community about your expectations. Was the previous (“see no evil – promote”) process good enough, or would you like your DTP project leaders to say that they’ve completed a best faith testing effort and the build is milestone/release candidate/release ready? I have no interest in tracking and seeking conformance to policies that the community does not gain value from. In DTP 1.6M5 we’ve resolved 65 bugs. Does silence mean “ready to go?”

This week please send your thoughts about the sign-off process to the DTP PMC mailing list or the newsgroup. We’ll collect these and make a decision next week about whether to rescind the sign-off process or to delay promotion of future DTP milestones in the absence of sign-offs.

Of peguins and the end of the year

Peter and Roman commented on my Penguin Design post, and I got a number of other comments/questions from other channels too. A number of people asked what I meant to say, and I had to answer honestly: I'm not sure. It just seems like such a natural connection to make, and I think there's a number of associations you can draw from it. Let's see... on my bookshelf there are two books with penguins on the front cover: Segaran's Collective Intelligence and Chamley's Rational Herds. Over the holiday break I think I'll look more at these to see if I can clear up my thinking about Penguin Design :-)

Speaking of holiday breaks, I've always enjoyed the end-of-year pause, since it gives me time to decompress a bit and take stock of the past year. One point is already becoming clear though: while I'm used to a fair amount of chaos, generally I've been able to point to unifying theme or purpose in the flow. But, looking back at this year, I'm not sure I can do that. Yes, it was hectic and chaotic, but probably not more than usual. Yet, I'm having a hard time identifying the how it all "hangs together." I'll need to fix this next year...

Penguin Design

This weekend when trying to describe open source software to a friend, a neat association came to mind. Many of us have heard that "a camel is a horse designed by committee." What about open source. Well: "a penguin is a bird designed by open source!"

Assuming that I had heard this somewhere before, I searched but could not find it. Interesting: it seems like such an obvious connection to make :-) If anyone knows of a source for that statement, please let me know and I'll make the proper attribution here....