Naming OCD

I have serious OCD about naming. Sometimes I just sit and think (or talk out loud..) about what a good/better name for whatever is.

And I really mean whatever- package names, class names, method names, variable names, project names, component names, build tasks.. Along with naming OCD, I also have convention OCD such as: singular or plural names (for database tables, packages), camelCase vs snake_case, space vs tab, 2 vs 4 vs 8 space indentation.

However, I’ve got a few preferences, only they sometimes are in conflict and I haven’t decided on how much weight each has (need to figure it out still). They are:

• when trying to keep things ordered, put them in alphabetic order (ignores, properties, imports, fields, setters/getters)
• when trying to find a name, given two real synonyms, use the shorter of the two (but it has to convey the same meaning)
• avoid abbreviations and acronyms (this is in conflict with the previous preference..)
• name it using English

For that last reason I’ll give an example. I have a project that uses assignments. Without going into detail, I sometimes deal with lists of assignments, other times maps of assignments. I, therefore, have started using the convention of writing variables such as assignmentsMap instead of assignmentMap, because the variable represents a map, a map of what? of assignments. Not of ‘assignment’. I think it’s a good convention to use.

Problems programming to an interface with java.util collections

I try to program by interface. It gives the code more flexibility. More details.

I have an issue however with the Java collections classes, which are always used. Checkstyle by default sets all implementing classes of the collections as illegal types. However, I don’t agree with it.

For instance: Set.remove(Object) makes no promises, it says it could simply throw a UnsupportedOperationException if the method isn’t supported. This isn’t usually a problem as most of the time the implementation is HashSet or possibly LinkedHashSet. Sometimes, however, I use ImmutableSet, which throws a UOE on remove. What I would like to do is return something which is a Set but which can be modified with remove.

Scala collections I think have a much nicer API.

For instance, Scala’s Set defines that the – method “Creates a new set with a given element removed from this set”, which is also the functionality of the mutable version (scala.collection.mutable.Set). The mutable version, however, also adds a -= method to modify the set in-place, something that only makes sense for mutable collections. But mutable.Set doesn’t define the implementation used, so it can be used as the type of any parameter or field that you declare to be a Set (no duplicate elements) and modifiable (-=, +=, etc).

If only, if only. If only Java’s collections had interfaces for mutable collections without implementation, that way I could return a MutableSet, leaving the user able to remove object (without having to create a new Set with the contents of the original Set), without having to specify the implementation..

Commands to run after ‘rails new’

This is for Ruby on Rails and Mercurial users, such as myself 🙂

• cp .gitignore .hgignore
• .hgignore: prepend syntax:glob: sed -i ‘1i syntax: glob\n’ .hgignore
• .hgignore: sort: sed -i ‘1,2d’ .hgignore && LC_ALL=C sort .hgignore && sed -i ‘1i syntax: glob\n’ .hgignore
• echo “Gemfile.lock” >> .hgignore
• (echo ‘*.swp’ >> .hgignore; echo ‘.idea/’ >> .hgignore)
• find . -name ‘.git*’ -delete
• find . -type d -empty -exec touch {}/.keep \;
• hg init
• hg ci -Am ‘Generate project, setup .hgignore & remove .git*’

(Edit: Split add header and sort, otherwise it trunks the first 3 lines of .hgignore prematurely)

(Edit: Simplify the two modification 1-liners using sed)

Idea: Continuous Branch Integration Server (CBIS?)

I was reading Martin Fowler’s Feature Branch article (as well as the linked Branch by Abstraction article) and it made me think of an idea.

What if there was a Continuous Integration Server that checked branch integration as well? A Continuous Branch Integration Server (CBIS) perhaps?! I’ll use an example to explain, instead of just blabbing about it 😀

Pimped-out blog

This blog has officially been pimped!
Check out: Search, Tags, Recent Posts, Archives (along with pre-existing Twitter Updates and RSS Feeds).
Sweet!

Now with RSS feeds

Check out (and use) the RSS feeds available on the right 🙂

Ruby on Rails vs Scala & Lift – take two

Less ranting, let’s just straight-up compare the two

Pros of Ruby on Rails:

• Quick turn-around during development (in Java/Scala you need JRebel or sbt’s reload and other such tools)
• Easy to read and debug what is in production (and, though it’s a bad practice, fix in production)
• In order to check that nothing broke, tests are written, maintained, extensive and of good quality
• One full-circle ecosystem – RubyMine as THE IDE, rake is THE build tool, gem/bundle is THE dependency manager, etc… In Java/Scala there are many alternatives, which can be daunting and cause fragmentation within a community.

Pros of Scala and Lift:

• Code isn’t a mess of gate-keeper checks, because of static type-safety
• There are libraries such as a wrapper of JQuery that gives type-safety when writing JQuery, which improves developing that part of the application.

Perhaps Ruby on Rails is the best choice, given good conventions, practices and consistency 🙂