Less Caching

We came across this unusual problem when developing. So for starters, there is a Gem that we use and a test application reside in the test folder of the Gem. The Gem uses only Javascript in the app/assets folder and has a minimal Ruby code.

The Gem uses Bootstrap's less version to set the CSS. We use the mixins by Bootstrap and overwrite variables and stuff. The Gem still used SASS and we felt a little odd with writing mixed CSS. Therefore we moved all the stuff to less files and put it all in assets/stylesheets. Nice and organized. 

Now we had the problem. We made a change to the less files and the application did not load them. We had put all our imports in a main file and any change to the main file reflected in the test app. but not if the change were done inside the individual imports.

We wanted to analyze if the problem was with Sprockets or with less-rails. After some probe and hunt we concluded that the problem indeed was with less-rails. The Gem caches the imports which prevent any compilation after the import to the base file (first level).

I tried adding options like

config.consider_all_requests_local = true config.action_controller.perform_caching = false 

inside the environment files, but alas! no change what so ever.

So we had to do the inevitable. Look at files and trigger a restart and cache clear.

The process was to be something like :

if Change? 
  rake tmp:clear 
  powder restart (or touch tmp/restart) [we use pow]

Guard was perfect for this.

2 Guard plugins were used for this :
  guard-process => To run the rake process
  guard-pow => To restart Pow

The file looked something like this

# RUN bundle exec guard -p -i -w ../../ 
guard 'pow' do 
 watch(%r{app/assets/stylesheets/**/.*\.less$}) 
end 

guard 'process', :name => 'ClearCache', :command => 'rake tmp:clear' do
 watch(%r{app/assets/stylesheets/**/.*\.less$}) 
end 

The guard command needed to run with
  -w because we were looking at a change from another directory
  -p for polling
  -i for no interactions

phew..

Simply Complex

Well .. I was reading through the Pragmatic Programmer's Guide and saw this piece of code.

def ExampleDate.once(*ids)
  for id in ids
    module_eval <<-"end_eval"
      alias_method :__#{id.to_i}__, #{id.inspect}
      def #{id.id2name}(*args, &block)
        def self.#{id.id2name}(*args, &block)
          @__#{id.to_i}__
        end
        @__#{id.to_i}__ = __#{id.to_i}__(*args, &block)
      end
    end_eval
  end
end

The guide said "Note that this redefinition uses the fact that methods may contain nested singleton method definitions, a clever trick." ..

Essentially the problem is to check if the value exists for the a variable. If not then do some calculations and set the instance variable. Then return that variable for all further calls to the instance method.

This variation does something unique.

First it makes an alias for the method which checks the if .. else. It redefines the name of the method to be __278626__ . The number signifies the identification number assigned for the symbol. This is done inside the module eval which adds stuff to the class which calls the once method like so.

once :abc, :def

The method is first declared with args and blocks. Then if you notice there is a self method declared too. The first fact is that we dont care whats in the instance method code block unless it is executed. For it to be executed, it should be called from an instance. Therefore when the method does get called, it is redefined in the scope of the object, ie the same method is redefined to return an instance variable. The call continues then to set the instance variable which is to be returned by the redefined method.

phew.

Semicolons in Javascript

I read this very interesting blog post today and kind of made me thinking .. 

Semicolons in JavaScript are optional - http://mislav.uniqpath.com/2010/05/semicolons/ by Mislav Marohnić (http://mislav.uniqpath.com/) 

Centralize a Tile based view

A project that I'm working on has a structure similar to what you seen in Pinterest. Except that the height of the Tiles do not vary as in Pinterest.

What happens essentially in Pinterest is that the Tiles are positioned absolutely. The Tiles are given left and top css properties and are positioned according with resize handlers.

But in this application, the height of the Tile is static. Therefore we could accomplish this with CSS and some javascript. One knows the width of the Tile (Look at Jquery's outerWidth) and the width of the window (Look at Jquery's width). One just has to set up a resize handler (Look at Jquery's resize) and do something similar to this.

var base = $('#content_wrapper'), window_width, post_width; 
if(base.length !== 0) { 
 window_width = $(window).width();
 post_width = $('.post:first').outerWidth(true); 
 if(window_width%post_width !== 0) {
  base.css({'width': window_width - (window_width%post_width)}); 
 } else { 
  base.css({'width': window_width}); 
 } 
} 

$(window).resize(function() { 
 // Call the function here .. 
});

We will also need to call the function when the page loads too for the initial set up.