Monday, July 29, 2013

Awesome Ruby Stack with Vagrant

Environment + vmware = Provisioning of your development environment - automate installation of needed programs for deploying ruby code

Ruby Servers

Friday, July 26, 2013

Backbone JS lessons learned ... Ongoing

  1. Two major frameworks to consider, Chaplin and Marionette help give you guidelines when building applications in Backbone. After using both I like Marionette the most especially for the way it manages the screen with Regions and Layouts.
  2. When developing widgets in Backbone you will most likely want to the sync the Model when the view changes and the reverse when the model is updated. Think this through very carefully I have seen many bugs in this type of logic.
    1. One bug occurred when a developer built widgets that would get themselves into a circular event firing loop. He unknowingly did this by listening to the change event on the element, the issue arose because this same view listened to model change events. The model would be fetched and fire a change event which would update the view. Then the change event on the element would fire causing the model to update and so on ... Initially he solved this by checking if the value on the model was different than the value on the element. This got around the issue, but the issue could be avoided by not listening to change events on the element. Instead we should listen to user events on the element like onBlur, ...
  3. Decide early on how you are going to handle the loading part of the application, will widgets simply listen to change events and render when the data comes in, sort of having them pop up when available. Another approach is explicitly showing a loading sign while all the ajax calls are fetching models and collections.
  4. If you are going to need to relate your models and collections you will most likely pick between backbone relational and backbone associations. Be aware that if you pick backbone relational you will only be allow one model with the same id per type. In order to fix this you will likely have to call YourModelType.findOrCreate throughout your code instead of simply instantiating a new model. TODO I need to look into how backbone associations handles this problem.
  5. Routing across your application should also be well thought out. Are you going to need to programmatically navigate from one page of your application to another. Also think about your handling of where your javascript is deployed, will you need to know the context path in order to route properly?

Saturday, July 20, 2013

Functors, Applicatives, and Monads
  • Functor
    • Functors apply a function to a wrapped value:
    • Easy example to remember it by:  getPostTitle <$> (findPost 1)
    • A value can be in a context. Now when you apply a function to this value, you’ll get different results depending on the context
    • Functor is any data type that defines howfmap applies to it. 
    • The Maybe data type defines two related contexts: we’ll see how function application is different when something is a Just a versus a Nothing
    • When a value is wrapped in a context, you can’t apply a normal function to it:This is where fmap comes in
  • Applicatives
    • Applicatives apply a wrapped function to a wrapped value:
    • Easy example to remember it by: Just (+5) <*> (Just 3)
    • Applicatives allow you to apply a function that takes two arguments to two wrapped values?
  • Monads
    • Monads apply a function that returns a wrapped value to a wrapped value.
    •  > Just 20 >>= half >>= half >>= half,_applicatives,_and_monads_in_pictures.html

Friday, July 19, 2013

Temporarily ignore file checked in to git

So, to temporarily ignore changes in a certain file, run:
git update-index --assume-unchanged <file>
Then when you want to track changes again:
git update-index --no-assume-unchanged <file>

Tuesday, July 16, 2013

Software Engineering Points

I have tried to distill some knowledge that has come from building a few green field projects. These are the three points that have come about from this experience.
  • Focus on building up a language of "higher concepts" that are relevant to your system.
    • As your system progresses into later stages of development the hope is that you will be able to begin to spend more time applying the "higher concepts" you built in earlier stages.
  • Naming, Modularization, and Code Organization should not be under estimated.
    • Giving modules a well defined purpose and exporting a public interface is crucial. While it may not affect how the the code works it allows you to think at a higher level and keep less information in your brain at once. KISS
  • The eventual goal is to build software that is "product ready", in other words you want to be able to release the software and leave it alone.
    • If you have to hire a big IT team to support your software maybe you can improve your code to be more self sufficient.

Git pick out individual commits

The following approach was easy and straightforward to migrate some code on a branch that had diverged greatly from the current one. I was able to grab a specific commit out.

git format-patch -1 b50788b
git am 0001-First-pass-at-rake-task.patch

Tuesday, July 9, 2013

A Resilient RPC Infrastructure with Thrift Finagle ServerSets Zookeeper

One use case for ZooKeeper within Twitter is service discovery. Finagle services register themselves in ZooKeeper using our ServerSet library, see finagle-serversets. This allows clients to simply say they’d like to communicate with “the production cluster for service a in data centre b” and the ServerSet implementation will ensure an up-to-date host list is available. Whenever new capacity is added the client will automatically be aware and will start load balancing across all servers.

Great tutorial on building a Finagle Search Service,

Another interesting article on unique id generation,

Distributed databases,