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 🙂

Ruby on Rails vs Scala & Lift

I develop Java web applications, but I would like to change.

In the last few weeks and months, I’ve looked at various alternatives and I’ve basically come down to 2 choices, a situation I very often find myself in.

Ruby on Rails or Scala & Lift?

I like them both, and I’m leaning very heavily on Rails, for various reason, but one reason keeps me with an eye and a hand still looking and reaching for Scala and Lift – refactoring.

In the amazing world of Java and especially Java tooling, great IDEs such as Eclipse allow me to greatly refactor code with the security of knowing that it works simply because the IDE tells me it compiles successfully. This, however, is also a double-edged sword. It might compile, but that doesn’t cover all cases. You need tests for that, and those tests to be respected and maintained.

So, Scala and Lift allow me to build, maintain and extend a web application due to the fact that the code is statically typed, compile-checked and there are powerful tools (Intellij Idea X is what I prefer for Scala) that allow me to make big changes quickly and securely.

With Ruby and Rails I would (and have already) use RubyMine. And it does let you refactor, as well as jump to and from method usages/declarations, and from controller to view and back (which is really really cool). However you don’t get a code-wide check that a automatic compile does, so you have to fall back on to your tests.

This gives tests a much bigger importance than in Java. In Java the compiler can easily become your only test (and until a year and a half ago, I didn’t write tests, but that’s another story). Nowadays, I really think tests are important, they help me and they make me confident of the code I write. So I like the idea that tests gain importance, that way the development team will have to maintain and expand on tests during development, otherwise there won’t be any guarantee.

On the otherhand, some tests aren’t necessary, or at least they aren’t in general. Until your system breaks. Such as changing, what would be called in Java, a ‘getter’ (or attribute writer in Ruby, right?). “Damn, let’s pass it a Map (Hash in Ruby) instead of a List (Array)!” In Java or Scala, everything turns red in the IDE; in Ruby? Well I guess you have to work through all the code that called that method and change it accordingly. System-wide functional or integration tests would help- traversing the entire project to test common or edge-case functionalities and integrations would make these tests jump out.

So the type system and the compiler does help, because it simply tests that statically everything makes sense. And this can be used. I don’t have to check everything that comes in and comes out of a method, because the compiler assures me what it is. This makes the code less full of mid-execution gate-keeper checks, and leave more space for the application logic to shine (hopefully :D).

I’m a little afraid of stepping down from statically-typed languages. I’ve heard horror stories of applications (Twitter I think) that basically coded up a type-system in Ruby whilst making their application. I don’t wanna have to do that.

See my dilemma? 🙂

One last thing, pro Ruby, because refactoring takes a little longer, and is more error prone, you tend to make smaller commits, which is good pratice and a good practice. As in, it’s a good thing to commit often, and you can practice, for instance, writing good commit messages as well. I’ve been known (and know even worst cases) for massively refactoring code in single commits.. gets the job done, but it’s not the best.

Comments are welcome 🙂

Picking a theme

I’m currently using ChaosTheory, and I quite like it, but I’m not sure.

Alternatively I’ve also looked at ChaoticSoul, which looks similar, perhaps it will become my theme. 🙂

Why the blog?

I’ve been telling myself I should create a blog and start posting the ideas, thoughts and other crazy things I work and play with everyday, but I just never got round to it.

So, today, inspired by Jeff Atwood’s post How to Write Without Writing, I finally did. 🙂

Welcome!

(Let’s see how good I am at posting 2-3 times a week… 🙂 )