Esquire Theme by Matthew Buchanan
Social icons by Tim van Damme

28

Apr

I like Mercurial better than git

I think I’m one of the few people that likes Mercurial better than Git particularly for close-source projects.

Git = better branching, Hg = better merging

Git has easier to understand and more unified branching. However I think Mercurial merges better. I don’t have actual evidence but Mercurial rarely seems to screw up a merge and it seems to almost always do the right thing (hg resolve —all). Because of various rebasing or some other incorrect workflow I have had serious issues in the past merging with git. This is important to me because branching is not scary… merging is. And even scarier is rebasing.. more on that.

Hg = better for closesource, Git = better for opensource

I think Mercurial just works better for companies because rebasing + fast forwarding are something that are just not available OTB with Mercurial. Even with Hg’s various rebase extensions history editing is generally eschewed by Mercurial. So while this leaves less workflow options it means your junior developers is far less likely to completely screw up the master branch. Also other than making multiple heads its really hard to screw things up in Mercurial but when I first started using git I routinely screwed things up (mostly my fault because I sort of mixed workflows).

I also royally hate the staging area for companies because I have seen developers routinely forget to checkin files. You get the… “it works for me”…

That being said I think Git is superior for opensource projects because of its staging area, unified branching, generally more widespread understanding and far more mature subrepository support. Also with Git you don’t have to push all branches. So you can have a lone private feature branch. For companies I don’t see this is as good thing.

However my biggest problem with Git is that every time I seem to have to do something I have to google how to do it. I also seriously wonder if Git would be as popular as it is if it weren’t for the fact it was initially designed/developed by Linus Torvalds. Git is good today but it was pretty horrible to use compared to Hg years ago.

01

Apr

I stumbled on this hilarious video demonstrating some nice video recruitment marketing.

The video is made by Kixeye. 

Since my company makes mobile recruiting software I was interested if their careers section was mobile optimized.

Kixeye Looking good at first

Now when you click on Apply:

Ah good’ole JobVite mobile failure. Notice the “Insert a Document”. What would be better is associate your LinkedIn, Github, Stackoverflow profile.

Anything would be better than what I’m about to show you:

Jobvite Mobile Failure

Notice the lovely popup that does not even work on mobile. I can’t really blame JobVite because its rampant in the industry: Complete and utter negligence for the candidate experience. 

13

Mar

JIRM 0.0.6 Released

A boring release of bug fixes.

One notable feature added is the ability to do SELECT FOR UPDATE and SELECT FOR SHARE.

02

Nov

JIRM 0.0.1 Released

I got lost in Vietnam for a few weeks fixing up my own Java ORM and releasing it.

ORM’s (and light weight SQL mappers) are like templating language (which sadly I have written one of those as well). They all suck!

I was very reluctant to spend time writing JIRM as there are of course many options out there:

Well why did I write my own? I just could not find one that worked the way I wanted it too:

  • There are very few that support truly immutable objects.
  • Many are stateful and do very complicated magic …cough.. JPA.
  • Some have there own query language when I would rather just use SQL.
  • Some don’t really make that much easier than just writing JDBC
  • Many want to handle transactions for you which I don’t like

Of all the libraries I saw I liked Joist.ws, MyBatis, and jOOQ best. I would have liked EBean but I just could not get it to work reliably with our environment. Also of those only MyBatis and jOOQ truly supported immutable objects. But for reasons that I’ll perhaps explain later I did not like those libraries and ended up writing JIRM.


09

Sep

Using AspectJ for JSR 305 Annotations (@Nonnull)

For fun a made a rather useful aspect for checking not null using JSR305 annotations. The weaving will only happen if you use a @CheckForNull on the top of the class or on a particular method. Then you can decide if you want to default that values can always be @Nonnull with @ParametersAreNonnullByDefault

If your concerned with performance later on you can remove the @CheckForNull and manually add Guava’s checkNotNulls.

I should note that I have sort taking my own interpretation of @CheckForNull. FindBugs may vomit and not like it. There is probably a better annotation to use so please comment for a better recommendation.

Here is the aspect in all its glory make sure you name it ending in “.aj”: Above is an example bean that will be validated.

Above is the maven depenency you will need for the JSR305 annotations its also a transitive dependency of Guava.

08

Sep

Getting jOOQ to work with Spring correctly.

After playing with jOOQ as an alternative to my JdbcTemplate wrapper I finally got transactions to work properly.

You can read more about on StackOverflow: JOOQ and Spring.

05

Sep

MyBatis SqlBuilder Rewritten!

MyBatis SqlBuilder is one of the few SQL builders that allows you to generate pretty Pre-Processed SQL. That is SQL that has place holders. 

Now MyBatis SqlBuilder is sort of a joke in that it uses ThreadLocal… seriously ThreadLocal for an extremely simple DSL.  I would expect that from something like Hibernate but a tiny one class DSL. In fact when I first saw it I decided I would probably never use/need it because things like JOOQ and QueryDSL exist.

However I recently implemented my own Immutable ORM and need some simple SQL for Spring JDBC.

Consequently I ported MyBatis SqlBuilder to JATL style. In other words the better way to do this is to use Anonymous classes and/or Fluent style.

My Gist Here: The above Gist might not show because Tumblr sucks. https://gist.github.com/3650165

13

Jul

Better Appendable: String Building in Java Sucks

I have created a few classes that make appendable better: https://gist.github.com/3101471. Namely “BetterAppendable” which is an appendable decorator that will soften the IOException, handle nulls, and do collection joins.

I created BetterAppendable because Guava’s Joiner is rather limiting and Commons StrBuilder is to specific and is not threadsafe. 

An example of its usage:

Java has lots of ways of creating, encoding, and building strings. Most libraries are written so that they only accept java.lang.String when they should accept either Appendable or CharSequence. I’m tired of needing so many libraries to escape XML/HTML or encode a URL or just build a string especially since so many of them are not Appendable based. 

Consequently if people are interested I might make the classes into a project on Github and add various escaping options (like correct XML element and attribute escaping  as there is a difference). Of course if your really interested in creating proper XML/HTML strings look at JATL.

18

Jun

JATL 0.2.2 Released

JATL 0.2.2 released. 

Most notable change is that you can now do functional composition of markup fragments through MarkupWriters.

15

Jun

URLs are not a subset of URIs

You have probably seen or read that URL’s are a subset of URI’s. In theory they are but in practice I have found that not to be the case. 

See my recent Stackoverflow Post on this. URL’s in the wild allow for characters in the Excluded US-ASCII Charset. URI’s do not!

I believe this is most likely because URL’s came before URI. User agents and web frameworks remain backward compatible with old URL’s so be wary of this.

Modern URL’s should be a subset of URI’s. So when constructing a URL its always best to use URI escaping rules when constructing a URL.