Candidates should be prepared to work intensively with our developers and support organization when writing documentation. Being a distributed team,  we meet mostly on IRC and coordinate our work through email and versioning systems such as Subversion. The base format we're using is DocBook XML, and we're not just writing but also processing and publishing all our documentation ourselves.

This means you should be ready to use "non-wysiwyg" text editors, have a clue about XML and XSL, and be prepared to communicate over the Internet most of the time. Naturally, you should have some experience documenting database software. We're striving for high quality (good and understandable writing, accuracy, completeness, attention to details, timeliness) — people are actually reading the documentation we provide; our online viewable formats get millions of page views every month.

If you think you qualify, drop me a mail, and let me know what time would be best to get together on the phone.

Candidates should be prepared to work intensively with our developers and support organization when writing documentation. Being a distributed team,  we meet mostly on IRC and coordinate our work through email and versioning systems such as Subversion. The base format we're using is DocBook XML, and we're not just writing but also processing and publishing all our documentation ourselves.

This means you should be ready to use "non-wysiwyg" text editors, have a clue about XML and XSL, and be prepared to communicate over the Internet most of the time. Naturally, you should have some experience documenting database software. We're striving for high quality (good and understandable writing, accuracy, completeness, attention to details, timeliness) — people are actually reading the documentation we provide; our online viewable formats get millions of page views every month.

If you think you qualify, drop me a mail, and let me know what time would be best to get together on the phone.

• MySQL design basics
• Data Modeling Basics
• Physical and Logical Models
• "Dos" and "Don'ts"
• How to design MySQL for your specific application
• Datatypes
• Indexes
• Foreign keys
• MySQL Workbench
• Design
• Reverse Engineering
• Design
• Deploy (Forward Engineer)
• Maintain (Synchronize)
• Develop
• SQL Coding

I use Workbench for my daily work, and it’s a great tool.  If you haven’t tried the 5.2 release yet, you should.  While performing some maintenance, I happened to issue a DELETE statement against a table which had no indexes (it was 10 rows), and Workbench complained:

Error Code: 1175
You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column

It turns out this is a new feature in 5.2.26 (and is still there in 5.2.27) – Workbench now uses the equivalent of –safe-updates mode for the mysql command-line client (also known as the –i-am-a-dummy option – seriously).  This wasn’t exactly convenient for me, especially since the DELETE was part of a larger script which I then had to revise and step through manually after it failed, but there’s an easy way to change this behavior.  If you’re like me, you might consider disabling this:

• Go to Edit -> Preferences
• Select the SQL Editor tab
• Uncheck “Forbid UPDATE and DELETE statements without a WHERE clause (safe updates)”

Despite the text, the –safe-updates mode affects more than UPDATE and DELETE statements without WHERE clauses – it requires such statements to explicitly use indexes.

I’m changing this behavior on my installation before I run into other problems.

I’m no dummy.