Saturday, April 5, 2014

Markdown (and github markdown) Syntax

Markdown is a text-to-HTML conversion tool for web writers.

Markdown file extension is .md

You often see the file in the root of github projects.

markdown syntax tips


# Header - level 1 #
## Header - level 2 ##
### Header - level 3 ###
(and so on)


> Quoted text



Escape `inline code` with backticks

Github Fenced Code Blocks

Just wrap your code in ```

function test() {
  console.log("notice the blank line before this function?");

Github Language Syntax Highlighting

require 'redcarpet'
markdown ="Hello World!")
puts markdown.to_html

We use Linguist to perform language detection and syntax highlighting. You can find out which keywords are valid by perusing the languages YAML file.


Simple Table

First Header  | Second Header
------------- | -------------
Content Cell  | Content Cell
Content Cell  | Content Cell

Table with Cell Alignment

| Left-Aligned  | Center Aligned  | Right Aligned |
| :------------ |:---------------:| -----:|
| col 3 is      | some wordy text | $1600 |
| col 2 is      | centered        |   $12 |
| zebra stripes | are neat        |    $1 |


Unordered Lists

* Use 
* The 
* Asterisk

Ordered Lists

1. Use
1. Number
1. Followed by Period

Horizontal Lines

Three or more dashes





Escape Emphasis

Use backslash

not \*itialic\*
not \*\*bold\*\*

Github Striketrhough

Double squigly used to ~~strikethrough text~~

Thursday, April 3, 2014

Downloads for Apple Developers

I recently needed to download the latest xcode developer command line tools directly because I got this error message ...

Xcode is not currently available from the Software Update server

 ...when attempting to run xcode-select --install

Friday, March 28, 2014

Go language IntelliJ IDEA Plugin

Support for Go programming language.(see

Release notes for version 0.9.15
The plugin provides the following features:
  • Basic language parsing and highlighting
  • Code folding and Brace matching
  • Comment/Uncomment (Single/Multiple line) support
  • Go application file and library generation.
  • Auto completion of sdk package names and/or local application packages.
  • Compilation of the go applications (supported semantics are similar to those of gobuild)
  • Native plugin code formatter
  • GoTo class (go types) implementation
  • ColorsAndSettings page with a new color scheme
  • Completion/Resolution of vars/types/functions/structs/methods (works across some expression chains).
  • Refactorings: Introduce variable/constant
  • Inspections: Unused imports/variables/constants/parameters/symbols
  • Inspections: Validate the format param for the fmt.Print suite of functions
  • Inspections: Detect non constant expression used in constant declarations
  • Intentions: Invert if condition/Merge nested 'if's/Split into 2 'if's/Convert switch statement to if chain.
  • Intentions: Convert between interpreted string and raw string.
  • Intention: go get a package.
  • Intention: Add/Remove parentheses.
  • Intention: Move simple statement out.
  • Inspection: Validate that the package names in files are correct with respect of the folder name.
  • Documentation for functions, methods, variable, constants and types.
  • Function parameter information.
  • Ctrl+Shift+T to jump between source file and test file.
  • Navigation from stack trace in output panel.
  • Ctrl+Shift+Enter to add curly brackets for "func", "if" and "for" statements.
  • Live templates: "sout", "souf", "soutm" and "soutp".
  • Go aware imports optimizer and auto import generator
  • Import usage highlighting (and detecting of wrong imports)
  • Better Structure view
  • Automatically add new line at end of file
  • Force UTF-8 encoding for go files
  • Detection of bundled Go Sdk packages (useful when deployed as GoIde)
  • Run configuration creator (right click on a program file and you can run it).
  • Go SDK (Go 1.2 on linux/mac/windows)
  • Go module type
  • Go App engine sdk type
  • Go App engine credentials safe storage
  • Added go application wizard
  • Makefile based build system (bring your own Makefile). Experimental. Configured in project settings.
  • Always use tabs instead of spaces (but configurable if desired).
  • go fmt integration via Tools -> Go menu options (default CTRL+ALT+SHIFT+F for file and CTRL+ALT+SHIFT+G for project)

Change Notes

Fix project creation in multiple IntelliJ products.


Plugin homepage


1.4 M    

Tuesday, March 25, 2014

Software Management Tool Suggestions

Project Management
  • Jira (Altassian product)
  • Pivotal Tracker
  • Redmine
Used for story/requirement and defect tracking
Configuration Management
  • Puppet
  • Chef
There are a number of other configuration mgt software options, but Puppet and Chef are the best Ruby ones.
Continuous Integration
  • Bamboo (Altassian product)
  • Jenkins
Version Control
  • Git/github
Information Sharing
  • Confluence (Altassian product)
  • Google Apps
Dependency Management
  • Bundler

Thursday, March 6, 2014

Refactoring Legacy Code

You can't change it safely because it doesn't have tests...

...and you can't write tests without changing it to adequately support testing.

Code undergoing test-proven refactoring will begin to experience the benefits of new unit tests, and these benefits will incrementally make new tests easier to write.

Don't forget to create integration tests for verifying user story scenarios.

Ultimately, these efforts will make the legacy codebase more maintainable.

Stubs, Mocks, Fakes and Dummies

A “mock object”, or “mock”, is a specific kind of test double. It is an object used in a Unit Test which stands in for another object, and carries certain expectations about how what methods will be called, and how they will be called. If the expectations are not met, the test fails. By contrast, other test doubles, such as stubs objects, make no assertions about which methods will be called. The term “Mockist” refers to those programmers who use mock objects in their unit tests. There is another camp of programmers, called “Classicist” by Martin Fowler, who eschew mock objects entirely in their tests.


  • passed around but never actually used. Usually they are just used to fill parameter lists


  • have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example)

Stubs (classical unit testing)

  • make the SUT believe it's talking with its real collaborators
  • state verification
  • provide canned answers to calls
  • may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'
  • typically, you have to create not just the SUT but also all the collaborators that the SUT needs in response to the test
  • sometimes, alot of work goes into creating test fixtures, but they can be resused
  • cares about the final state - not how that state was derived
  • it's important to only think about what happens from the external interface and to leave all consideration of implementation until after you're done writing the test
  • stubs do not define behavior, just a return value
  • mainly useful when testing query methods that return a result and do not change the observable state of the system (are free of side effects)

Mocks (mockist/behavior driven testing)

  • make the SUT believe it's talking with its real collaborators
  • behavior verification
  • pre-programmed objects with expectations which form a specification of the calls they are expected to receive
  • typically, the SUT and mocks for its immediate collaborator objects
  • less fixture setup required, but mocks must be created every time
  • you are testing the outbound calls of the SUT to ensure it talks properly to its suppliers
  • Mockist tests are thus more coupled to the implementation of a method. Changing the nature of calls to collaborators usually cause a mockist test to break (This can be worsened by the nature of mock toolkits)
  • couples tests to implementation (changing the nature of calls to collaborators usually causes tests to break)
  • Coupling to the implementation interferes with refactoring, since implementation changes are much more likely to break tests than with classic testing
  • writing the test makes you think about the implementation of the behavior
  • must constantly think about how the SUT is going to be implemented in order to write the expectations
  • encourage behavior rich objects
  • Mocks act as a canary in coal mine: they are an early warning system that your code is beginning to depart from the path of small methods, each having a single responsibility, and each interacting with a very small set of collaborators
  • if you aren’t using tests to drive your design, there’s little point to using mock objects
  • Mock objects make more sense in an outside-in model of test-driven development
  • Mock objects enable developers to ferret out the needed interfaces of objects that don’t exist yet
  • The mocks you write while TDDing one layer of the design gives you the clues you need to work out the necessary responsibilities of the next layer down
  • mocks expect a certain method call, but define no return value
  • mainly useful when tesing command methods that change the state of a system but do not return a value


Stub Example

public interface MailService {
  public void send (Message msg);
public class MailServiceStub implements MailService {
  private List messages = new ArrayList();
  public void send (Message msg) {
  public int numberSent() {
    return messages.size();

We can then use state verification on the stub like this.

class OrderStateTester...
  public void testOrderSendsMailIfUnfilled() {
    Order order = new Order(TALISKER, 51);
    MailServiceStub mailer = new MailServiceStub();
    assertEquals(1, mailer.numberSent());

Mock Example

class OrderInteractionTester...
  public void testOrderSendsMailIfUnfilled() {
    Order order = new Order(TALISKER, 51);
    Mock warehouse = mock(Warehouse.class);
    Mock mailer = mock(MailService.class);
    order.setMailer((MailService) mailer.proxy());


    order.fill((Warehouse) warehouse.proxy());

Example Discussion

In both cases I'm using a test double instead of the real mail service. There is a difference in that the stub uses state verification while the mock uses behavior verification.

In order to use state verification on the stub, I need to make some extra methods on the stub to help with verification. As a result the stub implements MailService but adds extra test methods.

Mock objects always use behavior verification, a stub can go either way. The difference is in how exactly the double runs and verifies the results.


Tuesday, March 4, 2014

Better Design Yields Awesome Fast Tests

Before all the hype of Behavior Driven Development (BDD) and Test Driven Development (TDD), I had a lot of success with the following development technique:

  1. Create Unit Test to test Application (We'll take an API based application as our example.)
  2. Implement simple API
  3. Verify Unit Test works
  4. Add more tests and build Test Suite

I called an API and asserted that the state of response based on inputs.

That was in a compiled language.

Then I started developing in Ruby, which is a dynamic language.

I learned a few things:

  • Unit Tests are more important for Ruby than Java b/c a complied language will catch interface issues early
  • Integration Tests are more important when using mocks and stubs
  • Though coding is much more enjoyable in Ruby/Rails than Java, compilation time was replaced by the time it took to run the Rails test suite

BDD Testing Didn't Make Sense

I found that every time I wrote tests for a Rails app, I had to duplicate all the objects with mocks and stubs (and the tests still took too long).

While I still don't appreciate the fact that I must use a different DSL, rspec, (which is constantly changing) to implement effective tests, I have come to accept rspec as the lingua franca of test DSLs for Rails apps.

It's just annoying to not be able to use the more recent features of rspec when working on a legacy, at this time Rails 3.x app.

Things Get Better

Eventually, I learned to not only deal with the rigorous testing requirements, but to take that pain as an incentive to design better applications.

As you find things difficult to test, you should alter your design (not your tests).

Test First Development

Here, you alter the way to test to alleviate the pain, i.e., the time it takes to run your tests.

You use Spork or Zeus to speed up your testing environment.

Without such tools, running spec_helper takes too long.

With these tools, the test environment, e.g., the Rails environment, including database connections for ActiveRecord gets loaded in the background.

Test Driven Development

With TDD, you improve the way you design your application, which in turn makes your tests run faster.

Dependency Injection

DI allows us to mock all the time consuming operations and to isolate testing to the interface of the object under test.

This typically means that we'll keep not only our controllers thin, but also our models.

We'll introduce the use of Service Objects, with flexible initializers, making it easy to swap out the persistence logic.

We'll use mocks for testing and the real thing, e.g., ActiveRecord for production.

We'll avoid using datbase operations, and isolate ourselves from 3rd party APIs.

We'll Use a rather than a Factory.create to build in memory data relations.

Instead of running Spork or Zeus ask yourself, why does this take so long?

What is the biggest 3rd party thing I'm depending on? "Rails"

Escape from Rails Dependency

Use Ruby Mixins or Delegation.

Use Delegation when using a service is beneficial; Otherwise, use a Mixin.


Do This

  • Isolate your App from 3rd Party Frameworks and Libraries
  • Don't let controller actions talk to ActiveRecord (wrap calls to db or 3rd party libraries)
  • Use Controllers to route and pass data into something else (don't use Finders)
  • Use Cucumber (or some other integration test suite) to test for inclusion of modules
  • If its not an ActiveRecord model, then only call scopes or hand-built scopes (wrap to avoid hash construction conflicts)
  • Use Dependency Injection
  • Delegate quickly
  • Write your application in Ruby and let the Rails code call it

Get This

  • Easier Maintenance
  • Faster Tests
  • Higher Cohesion