Tizra Blog

I have been working on my tutorial for the O'Reilly Tools of Change conference. I'm presenting PDF as a cost-effective option to create revenue from the the backlist as an alternative to XML. As a dedicated markup advocate from the days of SGML, and someone who helped simplify SGML down to XML, I still find it odd to be talking about other kinds of solutions, but I think I learned something from my custom web site customers... The XML Paradox is that XML is a high-quality archival medium, and obviously then, books and scholarly content would make the jump first. It just makes sense that everyone would use the high-value format for the longest-lived, highest value content. Wrong! The economics of publishing have played out the opposite way. The more ephemeral the content, the faster production methods can change. So newspapers were doing full-text databases from very early on. In the scholarly markets, journals are now almost all electronic. Books, however, are only start...

We spend a lot of time explaining ourselves to funders and prospects. In one of our first "real" presentations we were describing why readers will get better value from the improved reading experience of Tizra sites, and publishers will be attracted by that superior usability combined with really flexible and sophisticated selling and management tools. Someone jumped right in at that point and asked "whose side are you on, publishers or readers?" I tried to "unask the question" and say that we were on both sides, but was greeted by a flat contradiction -- "You can't be on both sides you have to pick who's more important." This dichotomy of sides seems to contaminate a lot of thinking in the "content industries", and it's fundamentally flawed. Simple economics gives the answer: Publishers and customers are fundamentally on the same side. The publishing industry generates value for readers, who pay for that value via the ma...

If there is something the web as surely changed, it was the way that software engineers need to work. It is now a crucial aspect of our work to be able draw from the huge internet knowledge base out there in an efficient way to get to the right answers. Part of that information extraction is related to the keeping-up-to-date effort that every developer is required to accomplish to continue to be productive. While previous a software engineer could rely mostly on print material, nowadays we need to rely as well on content available on the net. Podcasts are such a source that can bring an amazing amount of information to the mix of knowledge one needs these days. If you are a software engineer and have not jumped into the podcast wagon yet, I suggest you do so. Here is a list some technical podcasts that we hear at Tizra: The Java Posse : a fantastic podcast on Java development. Containing news info update, analysis of tools, overall software development discussions. Software as She Dev...

One ramification of Chris Anderson's economics of abundance argument was nicely summarized by David Hornik: don't do one thing, do it all; don't sell one piece of content, sell it all; don't store one piece of data, store it all. The Economy of Abundance is about doing everything and throwing away the stuff that doesn't work. In the Economy of Abundance you can have it all But for most publishers this has been easier said than done. They may have an abundance of content, but building, feeding and tuning current online distribution and marketing systems is enough of a resource hog to dampen the experimental spirit at all but the richest. This, as you may have guessed, is the problem we're working on at Tizra. We think we're pretty close to solving it.

Tom Coates recently picked up a great post on a how much better a nice, intelligble URL scheme can make almost any web application. It's a place where system architecture and information architecture often diverge, and where thinking holistically about both at once from early on can result in software makes as much sense to people as to servers.

Jeremy Zawodny is rightly torqued about the needless complication of tools that purport to help with information sharing. The web's always had that pretty well covered, thanks to the simple magic of the URL. Anything you find, you can bookmark, email, or with a tinyurl , disseminate on a cocktail napkin. If my dear grandfather had been born later, he probably would never have picked up the habit of mailing articles lovingly clipped with a pen knife, and instead would have referred me to his del.icio.us feed. Zawodny points to a bizarre assortment of pop-ups, forms, and other unwelcome surprises that result from the "helpful" new sharing features, and notes... they seem to be placed on the sites under the assumption that I'm too stupid to send email (to the people I presumably email frequently already) with a URL in it... Thanks for the confidence boost. At Tizra, we're more inclined to say thanks to for the opportunity to do better. Our AgilePDF™ , for exampl...

Leading a team of developers in the effort of building a robust, quality software product should involve the establishment of some process and tools to assist the team effort and serve as a safety net for the errors of getting people to work together. Continuous integration is, I believe, a crucial element of that process. Introduced by Martin Fowler and Matt Foemmel (see article Continuous Integration ), continuous integration establishes the practice of frequent integration of work developed by the several team members verified by automated build and testing of integrated code within a clean sandbox. This practice is valuable for several reasons: It promotes the development of a clear process of building/deployment independent of any specificity of developer's platforms. Code that exists on a single platform only is bound to become dependent on specific aspects of that platform without anyone really noticing the dependencies until trying to port to other platforms. The existence ...