Ember's official documentation describes a number of low-level APIs, but doesn't talk much about how to put them together. As a result, a simple task such as creating a simple CRUD application is not obvious to a newcomer.
defmodule Boydm.Utilities.Map do | |
#============================================================================ | |
# similar to List.meyers_difference, the below code compares two maps | |
# and generates a list of actions that can be applied to the first map | |
# to transform it into the second map. | |
#-------------------------------------------------------- | |
def difference(map_1, map_2) when is_map(map_1) and is_map(map_2) do | |
# remove any keys from map_1 that are simply not present (at all) in map_2 |
My largest Sidekiq application had a memory leak and I was able to find and fix it in just few hours spent on analyzing Ruby's heap. In this post I'll show my profiling setup.
As you might know Ruby 2.1 introduced a few great changes to ObjectSpace, so now it's much easier to find a line of code that is allocating too many objects. Here is great post explaining how it's working.
I was too lazy to set up some seeding and run it locally, so I checked that test suite passes when profiling is enabled and pushed debugging to production. Production environment also suited me better since my jobs data can't be fully random generated.
So, in order to profile your worker, add this to your Sidekiq configuration:
if ENV["PROFILE"]
source 'https://rubygems.org' | |
gem 'rake' | |
gem 'lotus-router' | |
gem 'lotus-controller' | |
gem 'lotus-view' | |
group :test do | |
gem 'rspec' | |
gem 'capybara' |
defmodule XmlNode do | |
require Record | |
Record.defrecord :xmlAttribute, Record.extract(:xmlAttribute, from_lib: "xmerl/include/xmerl.hrl") | |
Record.defrecord :xmlText, Record.extract(:xmlText, from_lib: "xmerl/include/xmerl.hrl") | |
def from_string(xml_string, options \\ [quiet: true]) do | |
{doc, []} = | |
xml_string | |
|> :binary.bin_to_list | |
|> :xmerl_scan.string(options) |
(ns scrabble.core) | |
(def letter-scores [{:score 1 :letters "aeioulnrst"} | |
{:score 2 :letters "dg"} | |
{:score 3 :letters "bcmp"} | |
{:score 4 :letters "fhvwy"} | |
{:score 5 :letters "k"} | |
{:score 8 :letters "jx"} | |
{:score 10 :letters "qz"}]) |
Below are the actual files we use in one of our latest production applications at Agora Games to achieve zero downtime deploys with unicorn. You've probably already read the GitHub blog post on Unicorn and would like to try zero downtime deploys for your application. I hope these files and notes help. I am happy to update these files or these notes if there are comments/questions. YMMV (of course).
Other application notes:
- Our application uses MongoDB, so we don't have database migrations to worry about as with MySQL or postgresql. That does not mean that we won't have to worry about issues with the database with indexes being built in MongoDB or what have you.
- We use capistrano for deployment.
Salient points for each file:
I spent a lot of time trying to find a pretty optimal (for me) setup for Clojure… at the same time I was trying to dive in and learn it. This is never optimal; you shouldn't be fighting the environment while trying to learn something.
I feel like I went through a lot of pain searching Google, StackOverflow, blogs, and other sites for random tidbits of information and instructions.
This is a comprehensive "what I learned and what I ended up doing" that will hopefully be of use to others and act as a journal for myself if I ever have to do it again. I want to be very step-by-step and explain what's happening (and why) at each step.
class GroupOfThingies | |
attr_accessor :thingies | |
# Use like this: | |
# | |
# group_of_thingies = GroupOfThingies.new | |
# group_of_thingies.each do |thing| | |
# puts "Check out this awesome thing: #{thing}!" | |
# end | |
# |