RDBMS Issues and Concerns

Check out this blog post: http://cacm.acm.org/browse-by-subject/data-storage-and-retrieval/32212-the-end-of-a-dbms-era-might-be-upon-us/fulltext

The first issue is that the RDBMS code base in ancient. The second issue is that we keep pushing the envelope on the RDBMS model; examples include OLAP and RDF triple-stores.

Some folks want to say "reports of the death of the RDBMS are premature."

Like COBOL, the relational model, and words like "DASD", some technologies will be with us for decades after their useful life.

The decline of COBOL and the Relational Database will be protracted, painful, inevitable and asymptotic with actual death. The old one-size-fits-all COBOL is being replaced by many other languages. Similarly, the one-size-fits-all RDBMS will be fragmented into more specialized data stores. Further, legacy technology never completely goes away.

Macintosh Support

A handy CNET review site: http://reviews.cnet.com/macfixit/

SQL Injection Attacks the Top Vulnerability

This is an amazing quote: "We see SQL injection as the top attack technique on the Web".

See ComputerWorld's SQL Injection Attacks Lead to Heartland, Hannaford Breaches for more on this topic.

I'm amazed because SQL injection is entirely a preventable bug. Yet, it's the top attack technique.

That's an amazing indictment of the programming profession. There are so many shoddy, incompetent programmers (and shoddy, incompetent customers of programming services) that SQL injection is the top attack technique.

I almost forgot the obligatory XKCD comic: http://xkcd.com/327/

Building Skills in Programming

I've updated Building Skills in Programming -- an introduction to programming for non-programmers.

The entire thing was redone in RST and Sphinx, leading to an easier-to-read, more colorful layout. The cross-references are generally better and more complete. I also get Sphinx's indexing and search capabilities.

Everything was touched, chapters were added and rearranged. Numerous Python 3 reminders were added.

I can now -- easily -- include Google Adsense advertising on each chapter.

Next steps will be to upgrade my MacOS Python to 2.6.2 and then revise the book to cover 2.6 so that it is completely up-to-date. Also, the math needs to be redone using one of the Sphinx Math extensions so that the resulting LaTeX (and PDF) work out correctly.

Currently, my casual use of dozens of Unicode math characters has lead Sphinx to create LaTeX that isn't source encoded properly.

Meetings

I found this note while cleaning up. I think it's a summary of John Cleese's short movie "Meetings Bloody Meetings".

1. Plan. Why are we meeting? What's the purpose? What are the subjects?
2. Inform. Tell the attendees what, why and the expected outcome.
3. Prepare. Create an agenda, with a time line, and the items to be covered.
4. Structure. If the purpose is to make a decision, this involves presentation of evidence, interpretation of the evidence and a decision. If the purpose is to inform, then present the information.
5. Summarize and Record.

I hear complaints about time wasted in meetings. This complaint is absolutely justified. I've wasted a lot of my professional career in dumb meetings.

Out of Touch Management. The out-of-touch manager requires long meetings in which each direct report provides a complete status report. The all-hands meeting appears to be the only time the out-of-touch manager ever talks to anyone. Consequently, it devolves to a sequence of one-on-one meetings which the rest of the team is forced to attend.

If the goal is for many people to inform one person, those conversations don't require a meeting.

Going Through The Motions. The going-through-the-motions manager is aware that a staff meeting is expected, but has nothing really to say or do. These meetings often devolve into awkward silences as open-ended questions are thrown out to try and stimulate some interaction.

If there's no goal (no decision, no information) then there's no purpose for the meeting.

Best Practice.

In the days before agility, I worked with two project managers who gathered information in one-on-one meetings. These are separate projects for separate customers. But the same best practice.

The PM would stop by your cube, figure out what you were doing, what you needed, what you were planning to accomplish. Then, at the ever-so-brief staff meeting, a few key interactions among the staff would be lifted up from all those one-on-one meetings.

Let's review the brilliance of these two PM's.

1. They stopped by your cube. They did not play the power game and make you come to their office. They stopped by. In later years this was called "Management by Walking Around" -- something hailed as brilliant. These PM's just did it.
2. They hung around long enough to actually get what was going on. They didn't waste time asking you to write and email status to them. They asked, listened, understood and summarized your status for you.
3. They recognized the needs for interaction and made them happen. The status meetings were like daily scrum meetings. Since they were weekly, they weren't as brief, but they were just as focused. No long status reports. No long conversations.

Objections.

Some managers don't have time to sit in everyone's cubicle. This overstates their value as managers by understating the huge cost of wasting everyone's time in serial one-on-one's done in a conference room. 12 direct reports means 13 man-hours wasted in a one hour meeting.

Some managers don't have time to write status reports. Instead they forward emails all day.

It's probably better to get off the email treadmill. Get status, write short, to-the-point status reports.

Focus.

Developers (DBA's, Sys Admins, all technical folk) live in a world of technology delivery.

Mangers, however, live in a world of budgets, status reports, and weird exercises in foretelling the future. ("How long will it take? How much will it cost?")

There's no good reason to impose the world of status reporting and fortune-telling on technical people. There are, however, lots of bad reasons for imposing unplanned, unprepared and unstructured meetings on a team that would rather be building product than talking about building product.

Code Kata Resources (Updated)

I've got a ton of exercises in the Building Skills books. Specifically, my OO Design book is based on my own personal Code Kata exercises.

Plus there's the established Code Kata resources. The CodeKata page, Mark Needham's blog posting on code-kata, Rizky Farhan's Collection of Software Projects, jp.hamilton's Code Kata Resources. The Coding Dojo page (which suffers from showing no usable URL's -- what a mistake.)

Plus there are the random problem sites: Project Euler, Top Coder, UVa, SPOJ, Google CodeJam.

I've done a few (63) Project Euler problems (I got stumped by problem 69). Another 37 and I'd be at level 3.

The question isn't "where are the problems?" The question is "Are these good Code Kata problems?"

Building Skills Books Toolset (Update)

I wrote the first Building Skills books using Appleworks. It wasn't too bad to organize the styles around basic semantics of the subject area. It's an easy, productive writing environment. Except, of course, for internal cross-references, indexes, and tables of contents.

I converted to DocBook XML markup. The conversion was arduous, but well worth it. I got better semantic markup. I used the DocBook XSL tools to convert to HTML both as a single document, and a chunked presentation. It worked out pretty well.

Two things don't work out well. First, the FOP processing is shaky. The books are big, and rather complex, with a fair number of embedded fonts. I have been unable to get the embedded fonts to work correctly with FOP.

The second thing that doesn't work out well is the language-specific markup. DocBook is biased toward C. There aren't enough tags for Python markup (module and library tags are missing, for example) and the syntax-oriented statement, class and function markup is all over the map in DocBook.

Objectives

My goal is to have the books in four formats: XML, single HTML file, chunked HTML and PDF. Of these, the single HTML is the least appealing. The chunked HTML is a great carrier for Adsense ads. The PDF is what I should be selling.

I don't mind writing in XML. Using XMLMind XMLEditor is generally pretty nice. Running the XSL-based tool chain to convert to HTML, and chunked HTML is easy.

Currently, I'm using FireFox to create the PDF. It's quick, but dirty. I'm not sure how many of the print-formatting CSS options FireFox can handle, so I haven't really customized the CSS for printing. However, the FireFox PDF has properly embedded fonts and cross-reference links.

Choices

Apple's Pages does a lot. It's a very nice product. But I'm not sure that the PDF and Chunked HTML will work out all that well.

The DocBook tool chain has problems identified above. The PDF output doesn't work because it overwhelms FOP.

• Currently, I use FireFox to create PDF's. I could dress up the CSS to make it look a little better.
• An alternative is to use Pisa to transform the XHTML into PDF. I started using Flying Saucer on another project and the XHTML to PDF idea has some appeal. This requires debugging the print-media CSS, which doesn't seem too bad.

On the other hand, RST can have almost all the semantic richness of XML. I've decided to redo Building Skills in Programming entirely in Sphinx, using RST. This has the advantage of being Python-specific, making heavy use of pygments for syntax coloring.

Also, I could stick with XML and use a different tool-chain to go from DocBook XML LaTeX. The dblatex package may do this nicely.

Tradeoffs

If I switch to Sphinx, editing is much easier. The source is plain text.

The chunked HTML created by Sphinx is outstanding. It's far better than the DocBook HTML. It's much easier to customize than the DocBook XSL, allowing use of Adsense ads with relatively little work.

On the other hand, to produce PDF, I have to go through LaTeX. This means that I have to find a nice LaTeX to PDF tool.

Currently, Sphinx doesn't easily produce a single HTML file. There may be ways around this; perhaps by using an alternate `.. toctree::` directive. But this is also a low-priority requirement, so this may have to be dropped in favor of a better-looking PDF page.

LaTeX to PDF

A Google search for "mac os x latex to pdf" turns up some interesting results.

- http://www.math.toronto.edu/joel/tex/

- http://www.math.wisc.edu/~andrejko/resources/LaTex-on-Mac-OSX.html

This list of references makes it look appealing to start with TeXShop and seeing if the LaTeX output from Sphinx can be used to produce PDF.

The TeXLive distribution includes a basic pdfTeX utility that might emit a nice PDF from the Sphinx LaTeX output.

Additionally, there is iTeXMac, which may also convert my Sphinx LaTeX to PDF.

These, however, seem to be largely WYSIWYG editing. While editing LaTeX isn't too bad, I want to work from a single RST source.

Python Solutions

The "python latex to pdf" Google search turns up the following projects for doing LaTeX processing in Python. These look very nice. In particular, they get away from manual editing of LaTeX.

- plasTeX

- pdfTeX

Better Still

Finally, I located the following: http://jimmyg.org/blog/2009/sphinx-pdf-generation-with-latex.html. This makes it clear that Sphinx expects TeXLive. This leads me to MacTeX, which -- it appears -- is what Sphinx expects.

Sphinx generates a makefile to create PDF from the LaTeX. Hopefully, this is not highly Linux-specific and will use the TeXlive distribution on Mac OS X.

Bonus Feature

Switching to LaTeX may also give me a better way to handle the formulas in the exercise sections. Currently, I have to write them and save the images. I don't know how many different equation editors I've used.

Alternative RST to PDF

There's an rst2pdf tool that may make it possible to go from Sphinx RST directly to PDF. Hopefully, this honors all the Sphinx extensions.