Storm Threequal js vs ruby
The E myth Org chart for yourself
QFD = ideas into actionable items
| <input placeholder="ping something" /><button>ping!</button> | |
| <pre></pre> | |
| <script src="//localhost:8888/socket.io/socket.io.js"></script> | |
| <script> | |
| (function () { | |
| var socket = io.connect("//localhost:8888"), | |
| pre = document.querySelectorAll("pre")[0], | |
| input = document.querySelectorAll("input")[0], | |
| button = document.querySelectorAll("button")[0]; |
| # MOTIVATION: As rails apps are growing, people are noticing the drawbacks | |
| # of the ActiveRecord pattern. Several apps I have seen, and several | |
| # developers I have spoken to are looking towards other patterns for object | |
| # persistence. The major drawback with ActiveRecord is that the notion | |
| # of the domain object is conflated with what it means to store/retrieve | |
| # it in any given format (like sql, json, key/value, etc). | |
| # | |
| # This is an attempt to codify the Repository pattern in a way that would | |
| # feel comfortable to beginner and seasoned Ruby developers alike. | |
| # |
I wrote this up here: http://blog.steveklabnik.com/posts/2012-02-27-hypermedia-api-reading-list
| require 'integration_helper' | |
| require 'rack' | |
| require 'rack/handler/webrick' | |
| describe HttpClient do | |
| before :all do | |
| @server = WEBrick::HTTPServer.new( | |
| :Port => 9293, | |
| :Logger => Rails.logger, | |
| :AccessLog => Rails.logger |
| #!/usr/bin/env ruby | |
| # Lean Architecture example in Ruby - without ContextAccessor | |
| # In this example, the context passes the needed roles into each method it | |
| # invokes, and so the roles have no reference back to the context. | |
| # Model class with no external dependenices. Includes a simple find method | |
| # to create and store instances given an id - for illustration purposes only. | |
| class Account | |
| attr_reader :account_id, :balance |
| #!/usr/bin/env ruby | |
| # Lean Architecture example in Ruby - with ContextAccessor | |
| # This example keeps interaction state in a "current context", represented | |
| # by a ContextAccessor module. This can be mixed in to any class that needs | |
| # access to the current context. It is implemented as a thread-local variable. | |
| module ContextAccessor | |
| def context | |
| Thread.current[:context] |
| # This is a short collection of tools that are useful for managing your | |
| # known_hosts file. In this case, I'm using the '-f' flag to specify the | |
| # global known_hosts file because I'll be adding many deploy users on this | |
| # system. Simply omit the -f flag to operate on ~/.ssh/known_hosts | |
| # Add entry for host | |
| ssh-keyscan -H github.com >> /etc/ssh/ssh_known_hosts | |
| # Scan known hosts | |
| ssh-keygen -f /etc/ssh/ssh_known_hosts -F github.com |
| Testable Abstractions in Rails | |
| ============================= | |
| In Java or C#, it is common to build abstractions around external | |
| dependencies like Logging or Caching libraries. | |
| The advantages of such abstractions are twofold: | |
| 1) They can allow the caller to hide the methods/usage patterns that aren't | |
| relevant to their application. |
| require 'active_record' | |
| require "#{Rails.root}/app/models/user" | |
| describe User do | |
| it "does something sweet" | |
| it "does something cool" | |
| end |