Ruby | Aspectized.com

We came on issue:

In production environment we still want to make JavaScript not readable, and compressed into one file, but just for now I need it better suited for AirBrake debugging, so new lines are preserved, and white space too..

As we now as of Rails 3 it uses assets pipeline for doing magic with javascript. So what I had to do is to hack config/environments/production.rb a bit with this:

<pre>
config.assets.compress = true

require ‘uglifier’

config.assets.js_compressor = Uglifier.new(

{:beautify=>true,

:beautify_options =>

{:indent_level => 2,

:indent_start => 0,

:space_colon => false}

})
</pre>

Above code still produces one big JavaScript file, but this time human can easily read it and see a line where possible JavaScript error occurs.
Instead of creating new compressor instance, one can do it via config option. But somehow I failed to use it properly

config.assets.js_compressor_options = {:except => ['$super']}

Basicly I found this idea from here: https://github.com/rails/rails/issues/2693

Doc on Uglifier gem options

I think that’s the rule that drives my programming style the most is:

#1: Keep it DRY: Don’t Repeat Yourself

more here http://media.pragprog.com/articles/may_04_oo1.pdf from smarter than me

But there are 2 very different parts of the code where DRY might and might not be applied: programmer’s code and “high level” domain logic

A) Programmer’s code

I say, it’s a place quite deep in your code, rather related to implementation and less to design. Those are rather controllers and views, and deep parts of model implementation, every helper and utility class. Details far away from actual functional requirements, use cases, business logic.

So there – in programmer’s world – I spend lots of time thinking how not to write the same/similar code twice. Really, I can even spend 10 hours or few days of thinking and writing ZERO code..
.. because I’d rather shoot myself in a foot with a railgun than used dumb-COPY-&-PASTE. We nowadays know it’s PLAIN WRONG, do we..

copy & paste exact parts of code is lazy (“lazy” the wrong way as opposite to being positively lazy as in yagni)
copy & paste similar parts of code might look and is quick solution at first, but it’s not. Someone WILL try to understand and refactor it later and WTF you
it’s about respect to other developers
it’s about write-once, read-100-times. It’s been always this way. So why bothering people after you with your unsolved problems
copy & paste is a smell for immediate action: extract similar code into a method, pass parameters, whatever.. make duplication gone
and obviously if a change must be later done to all duplicates, it must be made in X places instead of ONE

So this is BAD code. Effect of dumb COPY&PASTE&CHANGE-ONE-VAR


#example of BAD code duplication among 2 controllers
#that could be at least extracted to 1 base controller
class A::Controller
  before_filter :check_perms

  def set_points
    player.set_points params[:points]
    redirect_to :action => :index
  end

  def reset_questions
    game.reset_questions
    redirect_to :action => :show 'battlefield3'
  end
end

class B::Controller
  before_filter :check_perms

  def set_points
    player.set_points params[:points]
    redirect_to :action => :index
  end

  def reset_questions
    game.reset_questions
    redirect_to :action => :show 'mw3'
  end
end

B) Domain Code

.. we must make distinction on the “A)” code made for programmers and “B)” code meant to describe our natural world, our domain specific requirements.
This is a “high-level” domain code, possibly close to what customer say and do; to what their use cases describe. So it should really tell what it does.

Such code should not distract reader by forcing the reader to jump & dive around in & out of methods to see how things are implemented. I’d have all code served in front of me instead

In my opinion in domain code it is more important to see the intent of the code than to be pure DRY. I must admit I don’t make some strict rule on that yet. It’s rather my intuition today.

Applying all the fancy programming patters and refactorings just to make code few lines shorter does opposite and makes intent, the flow, the algorithm not clearly visible.

I say there are 2 cases where I’m not always fully DRY

acceptance tests – simulating user interacting directly with application (via browser mouse clicks, keyboard, triggering events, etc)
use cases – the most important domain code, domain algorigthms, business logic

So I would live with such code..


class RunningABikeUseCase
  def execute(player)
    player.wakeUp
    player.getTheBike
    player.ride
    player.rest
  end
end

class RunningABikeAndFailingUseCase
  def execute(player)
    player.wakeUp
    player.getTheBike
    player.ride
    player.crashIntoTree
    someone.help(player)
  end
end

class RunningABikeAndHydrating
  def execute(player)
    player.wakeUp
    player.getTheBike
    player.hydrateFirst
    player.ride
    player.rest
  end
end

.. and I think I would also live with this one, but maybe bit less comfortable in the long term..
..although at first those 3 cases now look shorter and more readable, but they also PRETEND that they do something by a nice method naming. In fact those methods might do sth completely different. They hide details, but those details ARE IMPORTANT, so should not be hidden


class RunningABikeUseCase
  def execute(player)
    player.wakeUpAndRide
    player.rest
  end
end

class RunningABikeAndFailingUseCase
  def execute(player)
    player.wakeUpAndRide
    player.crashIntoTree
    someone.help(player)
  end
end

class RunningABikeAndHydrating
  def execute(player)
    #player.wakeUpAndRide -- cant be used as it does bit different thing..
    player.wakeUpAndHydrateAndRide
    player.rest
  end
end

#why must I define those..
#it's too early..
#it's hard to tell if those fns should yet exist, and in this shape..
#I'd stay with former example and not try to extract a duplication so hard

def _wakeUpAndGetTheBike
  player.wakeUp
  player.getTheBike
end

def wakeUpAndRide
  player._wakeUpAndGetTheBike
  player.ride
end

def wakeUpAndHydrateAndRide
  player._wakeUpAndGetTheBike
  player.hydrateFirst
  player.ride
end