Recently, I went to package the JuffEd text editor for Ubuntu (it’s on REVU now), and I was surprised that it used bundled Tango icons by default. Then I looked at the code and saw that support for XDG icon themes was really hackish, and didn’t work with inherited themes such as gnome-colors flavors.

It’s strange that support for “stock icons” is not in Qt, unlike GTK, but still, I’d like non-KDE Qt applications to support them properly. So, yesterday, I wrote a small library to properly implement the icon theme specification.

If you’re writing a Qt application dealing with icons, there are two classes of note in that library:

• XdgIconManager keeps the list of themes installed in the system, and returns themes by human-readable names or directory names, or the user’s default theme.
• XdgIconTheme looks up icons by names such as document-new and returns the full path to the file. If used from GUI applications, it can also return a QPixmap, rescaled to the required size if there is no exact match.

Q-XDG library at Google Code

IntelliJ IDEA 9, codenamed… Maia? I am amused.

[whistles and opens Eclipse]

“…be conservative in what you send.” A lot of software works by that principle, and I like it. It makes sense: while you have no control over what you receive, you have control over what you send. My ideal data converter would be one that takes all kinds of weird malformed inputs and produces (e.g.) valid standardized XML.

This is why I find myself writing constructs like:

public static SortedSet<TimeSpan> intersectWithDisjointSet(Collection<? extends TimeSpan> spans) { … }

I apply this principle to human relations as well. I give people a lot of leeway in what they are and how they act, as long as they stick to two basic principles: (a) assume good faith, and (b) don’t be a pillock. It isn’t easy to shock me. While on the other hand, I have a strict code of what I allow and disallow myself (even though sometimes I fail at following it). That’s how most people probably act, but hey.

And to raise the Mandatory Gender Topic™: this is how I treat gender identity. I see other people the way they want to be seen, as long as I don’t see any evidence that they act in bad faith, that it’s a prank or trolling attempt. However, I hold myself to higher standards. This is why I didn’t assume the Maia identity and bombarded it with doubt until I felt completely, absolutely confident that it’s not just roleplaying, and I won’t regret it later.

On an amusing note, elky thinks that transgender people and “veg*ns” [sic] are naturally predisposed towards open source by their tradition-challenging mindset, which explains the unusual concentration of both there. “Most of the women who really participate in open source are feminist leaning too; it’s the strong ones that stick through though, and their involvement has short lifespans since the burnout rate is phenomenal.”

I can already see what a pain it will be to maintain an existing application based on this atrocity of a framework.

It’s exactly like Oleg said: an application written in XML with configuration files written in Java.

When it comes to operations outside the scope of standard SQL, Oracle developers have a… strange perception of usability. Operations that should by all means be simple and intuitive often have highly counterintuitive solutions.

Question: How do I reset an Oracle sequence to its initial value?

The solution is, apparently, to use ALTER SEQUENCE to set its INCREMENT BY value to the negative of the current value, then select NEXTVAL from it, and use ALTER SEQUENCE again to set the increment value back to 1.

Really, it’s easier to just drop and recreate the sequence… Intuitive, all right.

And how do you generate SQL INSERT statements from a table in Aqua Data Studio? The answer is, obviously, to export the data to a delimited file, then re-import it, but instead of committing the changes to the database, select the “Preview INSERT statements” import method. And Stallman forbid you accidentally select different tables for export and import, because it will gleefully try to interpret the file as describing data from the wrong table, with predictable results.

Everything written below comes from personal experience of maintaining a Java CMS written by our predecessors, who gave us next to no instructions regarding that pile of code.

• Don’t use an ORM library. If someone calls you on it, tell them that there were no ORMs available in 2003. Instead, write your own ad-hoc, bug-ridden object mapping layer that only works with Oracle.
• Don’t use reflection to automatically handle POJO classes being mapped without writing boilerplate code. Instead, ensure that every class has a corresponding DAO class consisting entirely of copy-pasted code to insert, fetch, and update database records on the JDBC and SQL level.
• As such, for every new database table, add three new classes and two interfaces.
• In the base class for all those, use a primary key field of type Object. Ensure that it can really mean BigDecimal, Long, or Integer depending on the context, even for the same class, so to actually get the number value of the primary key, you have to write something like Long.valueOf(obj.getPK().toString()).
• Pass all data in non-generic Lists (admittedly, generics weren’t invented yet) without any comments about what type these Lists actually contain.
• Ensure that the core CMS library, the individual websites, and the utility application used for copying the database between hosts all use different technologies. For bonus points, make the utility application use pure JDBC on the lowest level possible.
• Use a helper library written by your predecessors whose source code is lost, so your successors will have to decompile it first.
• Depend on an application framework but never use its core features, rather only helper classes and tag libraries.
• In JSPs, use nondescriptive names for temporary variables holding objects being rendered, such as “obj” or “list”.
• Instead of using the traditional MVC pattern and letting the controller select the view, link to JSPs and let these JSPs call “pseudo-controller” classes that do all the parameter processing and redirection.
• Start the name of such a pseudo-controller class with an arbitrary letter combination and ensure that nobody knows what it means (such as “PL”). Give all instances of these classes an identical and equally arbitrary name (such as “UC”).
• In said pseudo-controllers, don’t use POJOs to represent submitted form data. Instead, use a self-written form-parsing library that requires to create a member object for every request parameter. Make all these fields public and refer to them from JSPs, better several of them at once.
• Inherit these pseudo-controllers, so that you can’t tell what form fields are being handled without going all the way to the top of the class hierarchy.
• Include JSPs in other JSPs, and in the included ones, reference objects declared in the outer one.
• Create new sites by copy-pasting old ones, so that common functionality added along the way ends up being spread instead of consolidated in the core library. Ensure that every new UI-related feature requires modifying every site in which it’s already implemented.
• Hardcode application logic into JSPs, or into the obscurest classes you can find in random places.
• Tie the core library to the common admin panel, requiring it to be redeployed every time something changes.
• Make said admin panel ridden with editable features that don’t actually work because they weren’t implemented for this particular site but nevertheless can’t be disabled in the admin panel.
• For every feature, write two classes in different packages that do the same thing but slightly differently.
• Use lazy singletons everywhere. Inherit them and initialize them in the strangest of places so that everything breaks down if an include is forgotten.
• Use a self-written authentication system that randomly clears the session upon authentication for an unclear reason, and make the authentication so mind-boggling as to make that particular quirk as unfixable as possible.
• Make the admin panel (which every application depends on) cache the page tree for every single site that exists in the system upon loading, and write that part as inefficiently as possible, so that the server spends minutes reloading the application when it starts fetching page structures from the database.
• Have three different ways of sending mail and make each application use one that its developer liked the most.
• Upgrade the built-in proprietary JavaScript-based text editor with major pain, then downgrade it when it turns out that the customer bought the wrong version by accident.
• Make the menu handler return URLs that end in “.jsp” even though such JSPs don’t really exist and are all handled by one three-line JSP per page type.
• Require restarting the target server every time the utility copy application is used.
• Hardcode full URLs in the database, so that a text replace function has to be built into the utility application specifically to replace those.
• Make error messages that the end user sees as non-descriptive and user-unfriendly as possible. They’re sure going to be fascinated when trying to register an account to find out that “NAME_EXISTS”.
• Hire a web designer who insists on using table layouts, tag soup HTML, split images and no doctype on the grounds that everything should be compatible with IE5. In 2008.