danielnegri

require 'nokogiri'
require 'sqlite3'

class Converter

  def initialize(file, database_name = "flashcards")
    @file = file
    @database_name = database_name
    @database = open_database()
  end

danielnegri

class PubligrationsController < ApplicationController
  before_filter :admin_required

  def index
    render widget: Views::Publigrations::Index, user: current_user
  end

  def publish
    messages = []
    unless subtrack = Subtrack.find_by_id(params[:subtrack_id], include: {question_sets: :questions})

danielnegri

My issues with Modules

In researching topics for RailsCasts I often read code in Rails and other gems. This is a great exercise to do. Not only will you pick up some coding tips, but it can help you better understand what makes code readable.

A common practice to organize code in gems is to divide it into modules. When this is done extensively I find it becomes very difficult to read. Before I explain further, a quick detour on instance_eval.

You can find instance_eval used in many DSLs: from routes to state machines. Here's an example from Thinking Sphinx.

class Article < ActiveRecord::Base

danielnegri

require 'rubygems'
require 'bundler'

Bundler.require
require './application'

namespace :assets do
  desc 'compile assets'
  task :compile => [:compile_js, :compile_css] do
  end

danielnegri

Services.factory("LawnchairFactory", function($window, $log, $parse) {
  return function(name, config) {
    var collection = {};
    var array = [];
    var isArray = config && config.isArray;
    var idGetter = $parse((config && config.entryKey) ? config.entryKey : "id");
    var transformSave = (config && config.transformSave) ? config.transformSave : angular.identity;
    var transformLoad = (config && config.transformLoad) ? config.transformLoad : angular.identity;

    function getEntryId(entry){

danielnegri

#!/usr/bin/env ruby

require 'digest/sha1'

class UnAuth
  LIMIT = 10
  SALT = ''

  def initialize(encrypted_password)
    @digits = [*('0'..'9'), *('a'..'z'), *('A'..'Z')]

danielnegri

Environment variables in Jekyll templates

This is one way to pass some data (API tokens, etc.) to your Jekyll templates without putting it in your _config.yml file (which is likely to be committed in your GitHub repository).

Copy the environment_variables.rb plugin to your _plugins folder, and add any environment variable you wish to have available on the site.config object.

In a Liquid template, that information will be available through the site object. For example, _layouts/default.html could contain:

danielnegri

# -*- mode: ruby -*-
# vi: set ft=ruby :

VAGRANTFILE_API_VERSION = "2"
WORKSPACE_ROOT = "/Users/grockit/workspace"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "saucy-i386"
  config.vm.box_url = "https://cloud-images.ubuntu.com/vagrant/saucy/current/saucy-server-cloudimg-i386-vagrant-disk1.box"

danielnegri

package com.scalapenos.spray

import spray.json._

/**
 * A custom version of the Spray DefaultJsonProtocol with a modified field naming strategy
 */
trait SnakifiedSprayJsonSupport extends DefaultJsonProtocol {
  import reflect._

danielnegri

/*
 *GoogleService
 * 
 * CommonJS module for Google
 * Uses OAuth2 for authentication/authorization
 * 
 * Ayorinde Adesugba
 * SISC
 */