Wednesday, September 17, 2014

Separating concerns: Data vs Algorithm

I'm by no stretch of the imagination a Knuth, but I was pairing the other day with a newer developer; and we started looking at some fairly complex code - at least from their perspective.
[
  {
    key: :known_issue_ids, 
    data: Something::KnownIssue, 
    map_to: :known_issues
  },
  {
    key: :depth_of_market_ids, 
    data: Something::DepthOfMarket, 
    map_to: :depth_of_market
  },
  {
    key: :developer_history_ids, 
    data: Something::DeveloperHistory, 
    map_to: :developer_histories
  },
].each do |param_value|
  property_params[param_value[:map_to]] = create_data_mapping(param_value[:data].all, property.send(param_value[:key])) if  property.send(param_value[:key]).any?
end

Obviously, there's a lot going on there; but it seemed quite impenetrable. I couldn't seem to convey that the importance of the technique was splitting the input data from the actual operation/algorithm; even if it resulted in some slightly more abstract code.

For example, it's quite often easy to look at duplicated, similar code and realise that introducing a method would greatly reduce issues; but we often fail to do this with conditionals or iterators. Languages with lambdas/procs/blocks/etc tend to make this a little bit easier to pull off; markedly so when it's translating from A to B with a lot of exceptions to rules.

Here, it becomes a lot more obvious that mapping is really just a set of lookups; compared to other code like

if a.foo
  b.foo_translated = a.foo
end
if a.foo2
  b.foo2_translated = a.foo2
end
if a.foo_catfish
  b.blah_translated = a.foo_catfish
end

The above even looks simpler for simple operations, but when you start performing really convoluted logic the chance of mistakes increases; particularly if you end up doing copy/paste/replace scutwork.
I'm curious - how wide spread is this practice?

Is it just a variation on certain DRY refactorings; or is it just an idiom I've picked up inadvertently from other languages like C?

Apart from the minor cognitive load put on the next maintainer (I should have really added a one line comment explaining what it boiled down to); are there any inherent negatives?

Saturday, September 13, 2014

New project: CloCkWeRX/pittwater

CloCkWeRX/pittwater

By CloCkWeRX



Pittwater Council Development Applications



September 13, 2014 at 9:34PM

via GitHub http://ift.tt/1BB0iPJ

Friday, September 12, 2014

New project: CloCkWeRX/morph-docker-ruby

CloCkWeRX/morph-docker-ruby

By CloCkWeRX



Docker image for running Ruby scrapers in Morph



September 12, 2014 at 7:18AM

via GitHub http://ift.tt/1pUhTJF

New project: CloCkWeRX/RubyWikiScraper

CloCkWeRX/RubyWikiScraper

By CloCkWeRX







September 12, 2014 at 7:06AM

via GitHub http://ift.tt/1BvJM3r

Tuesday, September 09, 2014

New project: CloCkWeRX/yarra_ranges

CloCkWeRX/yarra_ranges

By CloCkWeRX



Shire of Yarra Ranges Planning Applications



September 9, 2014 at 11:03AM

via GitHub http://ift.tt/1pJwHuJ

New project: CloCkWeRX/lane_cove

CloCkWeRX/lane_cove

By CloCkWeRX



Lane Cove DA scraper



September 9, 2014 at 11:01AM

via GitHub http://ift.tt/1pJwFmF

Monday, September 08, 2014

New project: CloCkWeRX/melbourne

CloCkWeRX/melbourne

By CloCkWeRX



City of Melbourne Planning Applications



September 8, 2014 at 6:38PM

via GitHub http://ift.tt/1tkRtnW

New project: CloCkWeRX/morph

CloCkWeRX/morph

By CloCkWeRX



Morph the web by transforming that most ephemeral of things, data.



September 8, 2014 at 11:27AM

via GitHub http://ift.tt/1AoytHT

New project: CloCkWeRX/adelaide

CloCkWeRX/adelaide

By CloCkWeRX







September 8, 2014 at 12:02AM

via GitHub http://ift.tt/1pDXl8n

Sunday, September 07, 2014

New project: CloCkWeRX/victorian_liquor

CloCkWeRX/victorian_liquor

By CloCkWeRX



Victorian Liquor Licence Applications



September 7, 2014 at 10:25PM

via GitHub http://ift.tt/1CF7Dz9