Please be careful

MongoDB replica set tags with mongoose

2016-07-19T00:00:00+02:00

MongoDB replica set tags are a handy way to refer to a subset of nodes. Imagine a scenario where you have three nodes in your replica set and you want to dedicate one server to reporting or background jobs. This can easily be achieved by replica set tags combined with preventing that node from becoming primary.

After you have set up your MongoDB cluster you also have to configure your clients so they can read from the correct nodes.

Our production API is a node.js application that uses mongoose as an ORM or ODM if we want to be fancy with abbreviations. Fortunately mongoose supports replica set tags as readPreferenceTags. It claims to support them in the connection URI as well. We are a big fan of 12 factor apps so we pass the connection URI as an environment variable.

Up until this point everything is straightforward and pretty simple. When we configured everything we expected one of the MongoDB nodes to have little to no traffic. To our surprise this was pretty far from the truth. The traffic distribution was the same as before. All nodes got some portion of the traffic. At this point we had to deep dive into the source code of mongoose. I can tell you it wasn’t a nice experience.

The problem was pretty apparent from the get go. In the underlying package that handles the actual TCP connection to the database there is a function called pickServer which does what you expect. The strange thing about this is that the read preference tags were not passed down to this function. Every other relevant configuration was available and set properly. I tried to hunt down how the configuration is passed around and where the read preference tags get lost.

I ended up with the realization that the configuration is parsed but it is lost somewhere between the 3-5 underlying packages that are used by mongoose. I filed an issue on Github, maybe it saves a few hours of debugging for somebody.

Fortunately there is a quick and pretty painless workaround so we didn’t have to figure out where it gets actually lost. If the read preference tags are set directly and not via the connection URI then it sticks and gets passed the pickServer function.

var mongoUrl = process.env.MONGO_URL;
options = muri(mongoUrl).options;
mongoose.connect(mongoUrl, {
  db: {
    readPreference: {
      preference: options.readPreference,
      tags: options.readPreferenceTags
    }
  }
});

This only gets us half-way there. As it turns out there is another bug in one of the underlying packages. It is a pretty trivial bug so as a good open source citizen I opened up my text editor and fixed the issue. This was the easy part. Now I had to somehow force node.js to load the fixed package instead of the canonical one. This would be super simple in Ruby land. I would just declare that xyz dependency comes from a git repo and be done with it. In Ruby every loaded dependency is global so overwriting it in one place would solve it for every other package. This is not the case for node.js…

npm has a feature called shrinkwrap which is basically a version lock file. We can specify the exact version of one or more packages which will be consistent across all npm installs. Since npm version 3 we can specify only a subset of packages without specifying versions for all packages. We can use this to hack around node.js’s questionable module system so we can inject the fixed package.

Our npm-shrinkwrap.json is the following:

{
  "dependencies": {
    "mongoose": {
      "version": "4.4.20",
      "from": "mongoose@4.4.20",
      "resolved": "https://registry.npmjs.org/mongoose/-/mongoose-4.4.20.tgz",
      "dependencies": {
        "mongodb": {
          "version": "2.1.18",
          "from": "mongodb@2.1.18",
          "resolved": "https://registry.npmjs.org/mongodb/-/mongodb-2.1.18.tgz",
          "dependencies": {
            "mongodb-core": {
              "version": "1.3.22-alpha4",
              "from": "git+https://github.com/sspinc/mongodb-core.git#fix-tag-selection",
              "resolved": "git+https://github.com/sspinc/mongodb-core.git#e1fdf33a031ae653437aac3d419a81191a777bfa"
            }
          }
        }
      }
    }
  }
}

As the time of writing this is the only way to get read preference tags to work with mongoose.

Object-oriented controversies: Tell Don't Ask vs the Web

2015-09-14T00:00:00+02:00

Lately I have been thinking a lot about object-oriented principles and ways to better apply them in my day-to-day work. The more I think the more questions I have. Principles and best practices contradicts each other more often than not. This post is not a rant but rather me trying to understand some portions of object-oriented programming.

The mainstream view of OOP seems to focus on classes and inheritance while the original interpretation is more about message passing and the Tell Don’t Ask principle.

Procedural code gets information then makes decisions. Object-oriented code tells objects to do things.

– Alec Sharp

Basically the Tell Don’t Ask principle says that you should tell objects to do things and not query their internal state, make a decision and then tell them what to do.

Not so good:

def sound_alarm(alarm)
  if alarm.enabled? && alarm.working?
    alarm.start_siren
  end
end

Better:

class Alarm
  def sound
    if enabled? && working?
      sound_siren
    end
  end

  # ...
end

alarm.sound

This seems quite natural as one of the core principles of OO is that data and behavior should be co-located: a behavior is “responsible” for the data that it needs to operate on.

On its own Tell Don’t Ask seems to be very close to the One True Way. Locality, encapsulation and data hiding are very pleasant side effects. Code written this way is very readable and the refactoring from the “old” way is pretty straightforward.

Things start to go south when you think about how to apply it in the context of web applications or more specifically in the context of Rails. You should put behavior where the data is and in a web application the most important data resides in models. It does make sense to couple data and behavior. For example if I query the user’s name the returning String object does not know how to make sense of itself. It is trivial that it should not know. The user object should know what its name actually means. The Tell Don’t Ask principle says that instead of asking the user for its name I should tell the user things to do with its name.

Following this logic basically every behavior would end up in the model classes. This is something that we know (by experience) is a bad idea. Hundreds or thousands of lines of code crammed into a single class is a recipe for disaster. Service Objects grew out of this frustration.

Service objects are great. It takes some time to shift your mind that classes can actually be verbs and instead of representing a piece of the real world they represent actions in the real world. At first I thought service objects (with names like CreateOrder) were abominations. You get a strange feeling about using verbs for classes, after all real world object and real world actions are different beasts. But with time I grew to appreciate service objects for their simplicity. They nicely obey the Single Responsibility Principle, they are basically glorified functions with their own internal state.

Let’s look at a trivial example:

class MentionUser
  attr_reader :post

  def initialize(post)
    @post = post
  end

  def call(user)
    return unless user.has_access_to?(post)
    return unless post.published?

    if post.content.include?("@#{user.nick}")
      post.watchers << user
      UserNotificationMailer.mentioned_in_post(user, post).deliver_later
    end
  end
end

This is nice and easy. All the behavior is in one place, we extracted this from the User model. It is testable and it has a clear responsibility. From the point of Tell Don’t Ask this is really bad. It queries objects for their internal state and then tells them what to do based on the queried data.

Nowadays the general wisdom is to keep your models thin (to act as a gateway layer to your database) and if possible only contain associations and very trivial derived properties. All the business related logic should go into service objects and kept as a separate layer. Martin Fowler wrote about this phenomenon about 12 years ago and called it an anti-pattern. As always, he is quite right. Service objects are a lot closer to procedural programming than object-oriented programming although they work surprisingly well.

Now we have two concepts that contradict each other. Tell Don’t Ask is really sensible but service objects are based on hard-earned experience. Some people tried to close the gap between them but it only addresses one level: the controller uses the Tell Don’t Ask principle on service objects but service objects are still querying models for their internal state and make decisions based on them.

At this point I was really stuck and it seemed that this conflict is impossible to resolve. After quite some thinking I realized that I treated the model as a fixed piece of the puzzle as if it cannot be moved or modified. ActiveRecord models are a very crude view of the data that makes up the domain of the application. It is not just ActiveRecord though, we could also mention JPA and its entity beans but .NET EntityFramework is also guilty as charged.

A user model is a very general view of our domain’s user concept. When we interact with a user we don’t always need every information that is associated with our user concept. For example for authenticating a user we really only need its username and password. What if we had a model to capture this. A small and very focused model that could hold the data and the behavior at the same time but adhere to SRP. It is certainly not a revolutionary idea but realizing that models should not be tied to database tables gives you a new perspective.

Suddenly ActiveRecord seems more like a constraint and not a convenient way to access the database. A more flexible mediation layer might be a better option where I can easily map database tables (even from different sources) to my domain models. ROM would be a great candidate here. Splitting up our domain concepts by context is taking us awfully close to DCI which is a huge topic that I’m not going to touch on.

Conclusion? As always there is no silver bullet. Service objects (with their procedural style) could work as well as the Tell Don’t Ask approach. A touch of pragmatism is needed to evaluate the different approaches and use a mixture that fits our needs. Although my gut feeling tells me that mixing too many approaches would lead to the same spaghetti code that we strive to avoid.

Thanks Balazs Varga and Zsofia Langi for reviewing.

View components in Rails

2015-03-01T00:00:00+01:00

I started poking around with Rails just after the release of 3.1. Since then not much changed in how we approach the view layer. We use the same abstraction or to be more precise we are stuck with the lack of abstractions and doing everything on the lowest possible level of string manipulation.

The interesting thing about this is how far we can go without noticing the lack of available tools. With templates, partials and myriads of built-in helpers we can get by for a long time. But there always comes a moment when our partials become too complicated and stuffed with logic or coupled to the context so much that it makes it really hard to reuse them.

When this moment came I started wishing for view components. The Rails-world is so big, there must have been somebody else who ran into this and came up with an elegant solution. To my surprise I couldn’t find one that fits all my needs.

What are view components anyway?

Before I go any further I’d like to take a moment and explain what view components are (at least for me). My first exposure to web application development was a framework called Wicket and I tend to think this is where my definition of view component comes from. Wicket tries really hard to bridge the gap between desktop and web development, but at the end it fails miserably. It is a pain to use but the component concept it promotes is ingenious.

A view component should be …

completely self-contained, which means it can be rendered anywhere on its own
easily extendable (think OO inheritance)
reusable across your application (or even between applications)

This means I can have a generic table component to render <table> elements and I can use that directly in my views. But nothing holds me back from pulling that out into its own component and create an ArticleTable that can easily render itself anywhere and the only thing it needs is a list of articles. The ArticleTable could use the template from its parent or provide its own if absolute control is needed over how it should be rendered.

The Rails way

What I described above is simply not possible with Rails. The best you can do is create helpers or helper classes which spit out some string. This way you lose the flexibility and clarity of templates because you have to shove pieces of html into your ruby class or use the clunky content_tag that Rails provides.

Another option could be a partial with a backing (view)model (or presenter if you like). This is a bit better but there is a huge disconnect between the template and the view model/logic. You have to remember to pass in the right view model every time you want to use your partial + view model combo. Not to mention that the syntax is pretty ugly:

render partial: 'articles/table', locals: { articles: ArticleTableViewModel.new(@articles) }

Arbre

Arbre basically fell out of ActiveAdmin for the same reasons this article is being written. Arbre has a few warts and bugs but it is really usable and provides most of the abstractions you need, and also provides a straightforward way to create components.

Unfortunately this is an all-in solution. It comes with its own Arbre::Context which makes it really hard to integrate with existing template engines. You basically have to drop erb or haml or whatever you’ve been using. This makes it virtually impossible to integrate it into an existing application.

The closest I could get with embedding it into an erb template was to instantiate a new Arbre::Context within Rails’ view context.

# in helpers/application_helper.rb
def arbre(&block)
  Arbre::Context.new(assigns, self, &block)
end

And then use this in a view:

<div id="container">
  <%= arbre { article_table(articles) } %>
</div>

But this is where integration ends. The following is not working:

<div id="container">
  <%= arbre do %>
    <% panel 'Article panel' %>
  <% end %>
</div>

Arbre is full-on ruby - your templates become ruby scripts that only vaguely resemble html. It takes some time to get familiar with how it works and how to work around its quirks (eg. using Rails’ built-in helpers).

# in app/views/articles/show.html.arb
div class: 'container' do
  div class: 'row' do
    h3 article.title
    text_node link_to('Edit', edit_article_path(article))
  end
end

And it gets a little worse when you write your own components and you have to put the template code into a component’s build method.

From the Arbre docs:

class Panel < Arbre::Component
  builder_method :panel

  def build(title, attributes = {})
    super(attributes)

    h3(title, class: "panel-title")
  end
end

Arbre is a good choice when you use it inside ActiveAdmin but for general purposes it presents you with more challenges than solutions.

There is a very similar project called erector. I haven’t looked into it properly but it seems to have the same problem of mixing “template” code into ruby classes. I think a clear distinction between the template and logic is really useful.

Cells

Cells describes itself as view components for Rails but it has a slightly different definition of what a component is. It naturally plays well with existing solutions and really easy to add it to an application. When you have a CommentCell you can render that in a template with the cell helper method.

<div class="container">
  <%= cell(:comment, @comment) %>
</div>

It does a superb job of separating the presentation from the view logic: every cell has its own templates and a cell class which is basically the view model.

Cells is basically a way to replace Rails’ partials with maintainable and self-contained components. It falls short when you try to create generic components such as a table or a panel. The cell helper does not accept a block and you cannot yield from a cell’s template. Nick Sutterer, the author of Cells, has lots of great articles about how Cells works. I especially liked the one which showcases Cells with a sidebar component.

Cells gets so many things right but the ability to easily create generic components is sorely missing. Also there are a few conceptual things that I disagree with. A cell is basically a small MVC stack (in Rails kinda way) so it can have different actions or states (in Cells terminology) and these all have corresponding templates. I think that a view component should have only one representation.

In cells you could do the following:

class CommentCell < Cells::ViewModel
  def show
    # renders comment/show.erb
    render
  end

  def flagged
    # renders comment/flagged.erb
    render
  end
end

# in a view
<%= cell(:comment, @comment).call(:flagged) %>

I would much rather see two separate classes since I already have to manually decide which state I want to render.

The ideal solution?

There is no silver bullet. I couldn’t find an existing gem that would solve all my problems. It seems that at the end I have to get dirty and write my own view components library. In the meantime Cells is the best option I have.

This post became quite lengthy but I still have some thoughts on the subject. It is very likely I will post a follow up with a wish list for a view components library and some code experiments.

Sharing code between ActiveAdmin resources

2015-02-22T00:00:00+01:00

Recently I’ve been working with ActiveAdmin a lot, since we use it as an application framework to build an internal admin-like tool. It serves us very well most of the time but the level of magic it introduces is considerable.

The other day I had to implement the same functionality for two resources¹ and as every well-groomed Rails developer would want it, I wanted it DRY. Like super dry.

I created a new ActiveSupport::Concern and dropped it in app/admin/concerns and of course it didn’t work. I tried the obvious way to include it but it turns out that ActiveAdmin resources are a special kind of animals.

The ActiveAdmin.register block runs in the context of an instance of ActiveAdmin::ResourceDSL and somehow the included block threw a MultipleIncludedBlocks error. I couldn’t figure out why, but if include is not working we just try extend and bingo! it works like a charm.

I ended up with something like this:

# in app/admin/concerns/confirmable.rb
module Confirmable
  def self.extended(base)
    base.instance_eval do
      action_item :confirm do
        link_to 'Confirm', url_for(action: :confirm)
      end

      # omitting other gory details for brevity
    end
  end
end

And then

# in app/admin/post.rb
ActiveAdmin.register Post do
  extend Confirmable
end

This worked pretty well on my local machine but then I pushed it to origin and the CI build blew up. It could not load the Confirmable module. I was baffled because according to the source code ActiveAdmin simply loads everything in the app/admin folder. I thought maybe there is more to code loading in ruby that I know of. So I ran off and read some pretty good articles about the topic:

These were very good but ultimately none of them helped. I moved the confirmable.rb file around but nothing seemed to help². And the most infuriating part was that I could not reproduce it on my local machine. It didn’t matter which environment I used, which gems were installed.

As my last resort I turned to the GitHub issues page of ActiveAdmin: there must have been somebody else who wanted to do the same thing. And yes! finally something usable. It turns out that you should not put your modules into app/admin, so I ended up creating an app/admin_shared folder. It’s not particularly nice but at least it works.

UPDATE: It was brought to my attention that include does actually work, but it is another piece of ActiveAdmin magic. You cannot use an ActiveSupport::Concern, you have to roll your own self.included hook.

If you are not familiar with ActiveAdmin, a resource is basically an autogenerated controller for a model. ↩
Interestingly the where to put things question always comes back to haunt you when you work with Rails. ↩

Sending and testing emails in Go

2014-10-12T14:00:00+02:00

My last project was to create a notification service for our back-end. It had to support a few different ways to send out notifications and of course sending email was among them. Go’s awesome standard library makes it super easy to send out emails. After some initialization it comes down to one function call. For example sending email via Gmail would look something like this:

from := "you@gmail.com"
auth := smtp.PlainAuth("", from, "<your gmail password>", "smtp.gmail.com")
err := smtp.SendMail(
    "smtp.gmail.com:587",               // server address
    auth,                               // authentication
    from,                               // sender's address
    []string{"recipient@example.com"},  // recipients' address
    []byte("Hello World!"),             // message body
)
if err != nil {
    log.Print(err)
}

This is all good but what about testing? It is good practice not to test your framework and standard library again, but what about all the other stuff? Building the email’s body, loading configuration and all the necessary preparation - that has to be tested somehow.

You could use an existing SMTP server (such as Gmail) but introducing external dependencies to your tests are a bad idea. You might think that mocking the SMTP server by spinning up a local from your test case could solve your problem. It certainly would but it is unnecessarily difficult and time consuming. Go has two useful features that really helps with testing. Interfaces and first-class functions.

Let’s create an interface for our email sender!

type EmailSender interface {
    Send(to []string, body []byte) error
}

This way we can mock the entire email sending later when we use it as a dependency and this approach also provide us a convenient way to test emailing and well.

Let’s create a simple implementation for this interface!

type EmailConfig struct {...}

type emailSender struct {
    conf EmailConfig
    send func(string, smtp.Auth, string, []string, []byte) error
}

func (e *emailSender) Send(to []string, body []byte) error {
    addr := e.conf.ServerHost + ":" + e.conf.ServerPort
    auth := smtp.PlainAuth("", e.conf.Username, e.conf.Password, e.conf.ServerHost)
    return e.send(addr, auth, e.conf.SenderAddr, to, body)
}

There is no call to smtp.SendMail yet, although in a constructor function we can easily wire it together. We pass the a function reference to smtp.SendMail to the a newly created emailSender instance - the outside world will never know the difference.

func NewEmailSender(conf EmailConfig) EmailSender {
    return &emailSender{conf, smtp.SendMail}
}

Now we can easily mock out the actual email sending function in our tests. Creating something similar to httptest.ResponseRecorder we can actually see what was passed to the sender function.

func mockSend(errToReturn error) (func(string, smtp.Auth, string, []string, []byte) error, *emailRecorder) {
    r := new(emailRecorder)
    return func(addr string, a smtp.Auth, from string, to []string, msg []byte) error {
        *r = emailRecorder{addr, a, from, to, msg}
        return errToReturn
    }, r
}

type emailRecorder struct {
    addr string
    auth smtp.Auth
    from string
    to   []string
    msg  []byte
}

Using a handy closure here we can record what was sent and we can emulate an error for the edge cases.

Now all we have to do is put everything together in a test:

func TestEmail_SendSuccessful(t *testing.T) {
    f, r := mockSend(nil)
    sender := &emailSender{send: f}
    body := "Hello World"
    err := sender.Send([]string{"me@example.com"}, []byte(body))

    if err != nil {
        t.Errorf("unexpected error: %s", err)
    }
    if string(r.msg) != body {
        t.Errorf("wrong message body.\n\nexpected: %\n got: %s", body, r.msg)
    }
}

All the code stiched together. Download it and run go test email_test.go to run the test.

Math Is Necessary for Software Development

2014-01-16T17:30:00+01:00

Math Is Not Necessary for Software Development

Why are computer science and mathematics always combined? In my day-to-day as a developer I rarely do what I would call math. Now admittedly, computer science is different than software development, but I don’t think laypeople know that. I don’t think that high school kids who are deciding what do do with their lives know that. Our industry desperately needs more talented developers - and it turns out that the skills that make a good mathematician don’t necessarily line up with the skills that make a good software developer.

Math is always a tricky question. On a daily basis you might not directly use higher math, but everything you touch is built upon it. So math is actually super important, and you should know and understand the basic concepts. In the long run you cannot live without knowing how the low level stuff works. You can get by, but if you want to be a great (not a good) developer, then you must understand the building blocks that you are using. You cannot choose the appropriate hash function if you do not know what that is.

Math is everywhere in software development. Denying it would be completely foolish. You can try to shield yourself from it, but eventually you will have to sit down and understand how things really work. It doesn’t matter if you do this at a university or on your own, but you cannot avoid it.

On writing C

2013-12-22T00:00:00+01:00

A few days ago I had to write some C code again. I haven’t written a single line of C since freshman year. And that was 5 years ago. That is a long time and this little home assignment made me realize a few things.

In high school I already picked up some programming skills. The first year of university I lived off of these. Understanding new concepts and algorithms was easy and C seemed like just like any other programming language I had encountered up until that point. It had little quirks, but I was not bothered that much.

Using C was uncomfortable. I had to type much more, I missed strings and an infinite standard library. I just couldn’t understand why I had to re-implement all the string manipulation functions when somebody else have already done it, it’s all there and ready to be used. I couldn’t understand why I had to rebuild the building blocks instead of just using them and creating something worthy. Now I understand.

Now I know that learning the basics is invaluable. It is boring and tiresome, but it is a must. It has to be enforced upon you, otherwise an I-already-know-everything young titan would simply ignore it and die horribly when he has to really understand a problem to fix it.

Diving into C and the linux api after 5 years was interesting. I needed two days to catch up to speed. I’ve avoided manual memory management, zero terminated strings and obscure function names for a long time. After I got used to it again, it seemed like the world opened up. C felt liberating.

I felt like a god. I could create anything. The computer’s memory is my playground and I can shape it the way I like it. No one tells me how to allocate chunks of memory and how to use them. Close to the metal I felt like a child again. The constraints of higher level languages were all gone. It was like playing with Lego, but the instruction manual was out of reach and only my creativity could restrict me.

C is freedom. It is a burden and a gift at the same time. It’s pure engineering, when you can lose yourself in the nitty-gritty details of implementing something instead of focusing on the end goal and user satisfaction. It is the perfect playground, but it is poorly suited to be a first language for the CS students. I almost missed out on C, because of the bad memories and scars that I have due to not understanding it properly. I needed to spend 5 years writing high level stuff to really appreciate what C can offer.

Testing. Testing. Testing.

2013-12-08T00:00:00+01:00

I dropped this little pearl in my code the other day.

while (i < vec->len && vec->data[i] != value) ;

It is from a simple vector implementation’s remove method. Do you see any anything wrong with it? I did not for a while and oddly it behaved well. Too well actually. For a while I did not put more than one element in the vector, so this little loop never actually happened. The surprise came when there was two elements in it and I wanted to remove the second one.

My biggest mistake here is that I did not write unit tests for this, because I was confident enough I would not screw this up. Unfortunately my confidence was without merits.

Testing is always time well spent.

TIL: initialize an array with uniform values in C

2013-12-06T00:00:00+01:00

Sometime I admire C and then in the next moment I want to die out of frustration. Immutable strings are a gift from the gods by the way. I can only now appreciate them properly. It’s a shame that C does not have them.

So back to the topic. This is such a great syntactic sugar. When you want to initialize an array with a uniform value you can do the following:

char my_string[30] = {0};

/* Or for pointers */
char *my_string_array[30] = { NULL };

How lazy is Hibernate's lazy initialization?

2013-12-01T20:00:00+01:00

Originally I was going to give a more catchy title, but then I figured there is no need to pick on Hibernate. It actually does its job well when you manage to tame it.

Part of our application is using AngularJS which talks to a REST API, and the data travels as JSON. So we needed a way to serialize our entities into JSON strings, so we can send it back to the client. We are using JAX RS for the REST API, which uses Jackson by default. It seemed like a straightforward decision to use Jackson as our JSON serializer library.

Our domain model is a bit problematic and has lots of bidirectional associations, which is not best kind to have when you want to serialize it.

I knew upfront that Hibernate proxies will cause some trouble, but I would have never imagined how much. When the serializer tried to access a lazily initialized property without a hibernate session, it threw an exception. There is no surprise there. Luckily others have encountered this before, so there is a handy library. Unfortunately there is a known issue about this as well.

This is the point where I made a mistake. I assumed that Hibernate4Module can handle Hibernate proxies correctly, so I reattached the entity to a Hibernate session and hoped for the best. It was like raining blood. Everything blew up. The whole thing got stuck in an infinite loop because of the circular nature of the associations in our domain model.

I went down the debugging rabbit hole to see where all the Hibernate proxies get handled and it seemed fine. It seemed to return null for the uninitialized proxies just as it was advertised in the docs. But somehow those proxies got initialized during serialization despite all of my efforts.

It seems that Hibernate’s lazy initialization is a bit more greedier than I thought. I had the impression that it only loaded an entity or a collection when you accessed one of its properties. So for an Employee ---> Workspace relation calling a employee.getWorkspace() would not fire a query to the database. When working with Jackson this was not the case. It loaded everything and caused me some serious headache. It might have been a bug in the Hibernate4Module that I did not notice or my setup was somehow broken.

I ended up using mixins and ignored all the properties that caused the trouble. I was lucky because I did not need those properties on the client.

TIL: JSF + Guava not such a good idea

2013-12-01T00:00:00+01:00

The other day I was working on a page that presents hierarchical data and I wanted to retrieve each new level with an Ajax request. So far so good, but JSF makes simple things harder than they should be.

I created a view-model for each level of data. It was very basic:

class EntityViewModel {
    private Entity entity;
    private List<EntityViewModel> children;
}

After querying the database for the entities, I had to transform and insert the retrieved data into the view-model object tree. The obvious solution is to wrap every entity in a view-model and set the parent’s children property to the new list.

My mistake was that I used Guava’s fancy Lists#transform method instead of a simple foreach. For the first level, everything worked fine, but when I wanted to retrieve the second level nothing came back in the response. Everything seemed to be fine, but somehow JSF did not pick up the changes in the object-tree and did not render anything. All the responses were empty.

After a few hours of staring at the screen helplessly and blaming JSF, I realized that the problem was with the List<> implementation that Guava returned. The #transform method only returns a view of the original list, so JSF did not have a chance to notice when the children property of an object changed, thus it never rendered anything below the first level.

The takeaway? Don’t shy away from using the good ol’ foreach. It will probably never let you down.

First

2013-11-30T00:00:00+01:00

This blog was born out the frustration and pain that I have to endure every day due to the frameworks that are trying to be too clever. And because of that, this blog probably will mostly consist of my ramblings and rants about software and frameworks.

This is the nth attempt at keeping a blog regularly updated. I did fail most of the time, but I’ll never give up trying. I’ll probably collect some of the older posts from my other blogs and move them here and close up shop everywhere else.