ParthBarot-BoTreeConsulting

var ShareCounter = {};

ShareCounter.Addthis = {
  totalHttpShareCount: 0, //This is to store the http share counts received from Addthis
  /*
  ** Following method gets the https share count generated by Addthis on the page elements.
  */
  getCurrentHttpsCount: function(currentHttpsCountVal){
    if(currentHttpsCountVal.length == 0 || 
        (currentHttpsCountVal.length != 0 && !isNaN(Number(currentHttpsCountVal)))){

ParthBarot-BoTreeConsulting

.fc-time-grid .fc-event, .fc-time-grid .fc-bgevent {
  position: relative;
  width: 100%;
  left: 0 !important;
  right: 0 !important;
  height: 40px;
  margin-bottom: 2px;
}

ParthBarot-BoTreeConsulting

##Basic Rules of estimation

• There are no fixed set of rules for estimation, but still there can be some based on what we have experienced so far in "Agile" projects. The so called "Waterfall" project execution model is obsolet and rarely used because now the products are constantly evolving and features are removed/added very quickly based on business dicisions ( :'( We all hate this! But its truth! )

• Understand the requirements first, in detail

• You should avoid estimating what you can count. And if you can't get a count, you should at least try to compute the estimate from a related count.

• Identify use cases and clarify each and every step for them. This will give more insights about the requirements, and clarifies whole flow.

• Like, What user will do here, when he clicks what happens, when he enters wrong/no data, what if file is bigger

ParthBarot-BoTreeConsulting

Some basic rules to follow, for diff. rails components. Please add comment if you want to add anything.

##Controllers

1. Extract common code in controller action, which loads data from DB using finder methods with params as arguments.
2. Same for any service object loading.
3. Above two cases, if being used in more than one controller, then define a concern using included do before_action :finder_method end and include that in both.
4. Do not write separate controller for API, instead use respond_to with diff. data format.

ParthBarot-BoTreeConsulting

1. Identify what are diff. use cases we need to test, and define 'test' method for each. For the above example, we need,

• breaking_fact
  • test for 0
  • test for 1
  • test for any other number (say 3)
  • test for big number, which should break and throw exception.
• fact
  • test for 0
  • test for 1
• test for any other number

ParthBarot-BoTreeConsulting

Ruby Notes - 1

• Use is_a?, kind_of?, instance_of? method to check type of any variable

• Explain the usage of method in detail, as a comments before method

• Use compact method to remove nil from arrays

• Use tap method as follows, avoid writing an extra line to return object Instead of,

  def update_params(params)

params[:foo] = 'bar'

ParthBarot-BoTreeConsulting

def users
  per_page = Variable::default_pagination_value
  @users = User.find(:all)
  # First, check to see if there
  # was an operation performed
  if not params[:operation].nil? then
    if (params[:operation] == "reset_password") then
      user = User.find(params[:id])
      user.generate_password_reset_access_key
      user.password_confirmation = user.password

ParthBarot-BoTreeConsulting

=================================
def slow(&block)
  block.call
end

def slow
  Proc.new.call
end

- The below one is 5 times faster then above, in execution 

ParthBarot-BoTreeConsulting

class UsersProfileController
  constructor: ->
    return
    
  assets: (params) ->
    @a = new AssetsHandler(params)
    @a.one()
    @a.two()
    return

ParthBarot-BoTreeConsulting

var TemperaturesController;

if (this.Elijah == null) {
  this.Elijah = {};
}

TemperaturesController = (function() {
  function TemperaturesController(opts) {
    this.opts = opts;
    console.log("temps init!");