Skip to content

Instantly share code, notes, and snippets.

View ecoologic's full-sized avatar

Erik ecoologic

View GitHub Profile
@ecoologic
ecoologic / when_monkeypatching
Created February 3, 2015 04:16
avoid getting screwed when you update a gem you monkey-patch
# If the behaviour the gem you're monkey patching changes
# your monkey patch might not work anymore
if Gem::Specification.all_names.detect { |gem_v| gem_v == 'haml-3.1.8' }
# my monkey patch here
else
raise "Please check this gem works with the above monkey patch"
end

Faster Development

I'm looking for techniques to produce the same or better result in less time (without sacrificing quality). I'd be happy to read a good fluent book on the topic.

I work for a small web app development consultancy company. Our code doesn't need to be perfect and our clients are happy to have a few non-critical bugs / imperfection and save some money. I understand.

I hate when I'm in the middle of my development and I discover some detail that forces me to rewrite part of my envisioned solution. Once I TDD a controller API that turned out to be completely useless. It didn't take too long, but it's the sort of waste I'm referring to. Another time I learned how to use a small library, but never used it. Since then I've been doing some research to avoid useless development and become more effective in general.

Searching around "faster development" or similar keywords produces mostly results that focus on tools, like snippet and shortcuts for IDE, ZSH tricks etc, I think I'm setup fine for

@ecoologic
ecoologic / basic_oo_principles.md
Last active August 29, 2015 14:06
Slides about basic principles to code Object Oriented

class: center, middle

@net_engine

@erikecoologic

Slides available at ???????


class: center, middle

Boundaries

@ecoologic
ecoologic / x.md
Last active August 29, 2015 14:05
Template Inheritance

Similarly to the Layout Inheritance logic, if a template or partial is not found in the conventional path, the controller will look for a template or partial to render in its inheritance chain. For example:

# in app/controllers/application_controller
class ApplicationController < ActionController::Base
end

# in app/controllers/admin_controller
@ecoologic
ecoologic / cc.coffee
Created May 2, 2014 06:28
credit card validation
cardType = (cc) ->
result = "unknown"
result = "mastercard" if /^5[1-5]/.test(cc)
result = "visa" if /^4/.test(cc)
result = "amex" if /^3[47]/.test(cc)
result
luhn = (cc) ->
sum = 0
alt = false

POODIR (Sandi Metz)

In this post I'm going to answer the question: Why should every ruby developer read Practical Object Oriented Design In Ruby by Sandi Metz?

In short: two reasons:

  1. As correctly suggested by the title, it's about useful everyday choices of design, arguably your most important skill as a developer

  2. It's easy and useful to read cover to cover

App = Em.Application.create() # use App for every app and Em as a shortcut
window.h = # h a hash with all the non oo helpers
formatDate: (date) ->
date = new Date unless date?
[date.getDate(), (date.getMonth() + 1), date.getFullYear(), ].join('/')
$ ->
$('.datepicker').datepicker()
$('.tab').tabs()
$('form#new_invoice:not(".invoice-project-select")').submit ->
$form = $('form#new_invoice')
$tasks = $form.find('.task-checkbox')
$flatFees = $form.find('[data-flatfee]')
confirmCheckAll = 'You have not selected a single item. Please take note that all items that are unbillable are unchecked by default.\n\nDo you want to check them all and create the invoice?'
confirmInvoiceWithFlatFees = "There are either tasks or projects that have a fixed fee set. If you would like to instead invoice these by hours logged, please set them to 'hourly' before creating the invoice.\n\nDo you still wish to create the invoice now?"
# $tasks.find(':not(:checked)').click() # this keeps the graphic in sync
$tasks.attr('checked', true) if $tasks.find(':checked').length == 0 && confirm(confirmCheckAll)
@ecoologic
ecoologic / conventions.rb
Last active August 11, 2020 09:47
My Conventions
{}.as_json # {}
{}.to_json # "{}"
# query / command
user_params # query, no get_params etc, prefer queries over commands, leads to more declarative code, which is simpler
remote_document # Query, not get_document, more declarative
buy_document! # Exception to the above, it's probably a POST and I want to express that it's not a free call
prepare_document! # Bang to express imperative behaviour (?)
compact_params(params) # command - takes args and can be reused
compacted_user_params # YES, a noun is better
[user]
name = erik
email = [email protected]
[color]
ui = auto
[core]
whitespace = trailing-space,space-before-tab
editor = vim
excludesfile = /Users/netengine/.gitignore_global
[diff]