Tuesday, January 29, 2013

Fixing ssh's "Connection closed" Error


I am unable to ssh as newly added user (hg aka "Mercurial User") ...


$ ssh hg@mini
Connection closed by <IP_ADDRESS_HERE>


I notice the following message in the system logs:


1/29/13 11:36:59.776 PM sshd[362]: fatal: Access denied for user hg by PAM account configuration [preauth]


I simply had to add the Mercurial User to the Remote Logins list for mini:




Now, I can ssh fine ***

$ ssh hg@mini
mini:~ hg$


*** Assumes the public key from the work computer has been added to the authorized_keys file of mini

Sponsor Ads


Setting up HomeBrew on Mac Mini

Building blocks: Homebrew, XCode, X11, and Git

This guide is for starting from a fresh Mountain Lion install, with nothing else installed. You can approximate that state, by getting rid of all your macports and finks and what have you. Delete your /usr/local. Uninstall all XCodes are their developer tools.
Install homebrew:
ruby <(curl -fsSk https://raw.github.com/mxcl/homebrew/go)
Homebrew lets us effortlessly install things from source. It is good, but it needs some help: Mountain Lion doesn’t come with developer tools, and homebrew is not able to do much right now.
Go to the App Store and download XCode (I am writing this in early August 2012, and the current version is 4.4). This can take a little bit, so while it’s downloading, let’s install X11 libraries that Mountain Lion stripped out.
Go here and download 2.7.2+. Install it, and after it’s done, fix the symlink it makes:
ln -s /opt/X11 /usr/X11
When XCode download is done, launch it and go to Preferences, Downloads tab, and install the Command Line Tools. When it finishes, we are almost ready to brew. Before we do, let’s have XCode tell everyone where the tools are (this tip is from Get Mountain Lion and Homebrew to Be Happy).
sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer
Open up a new shell to make sure everything is loaded from scratch, and check that homebrew is good to go:
brew doctor
Fix the stuff it complains about until it doesn’t.
Now let’s get git:
brew install git




When I ran brew doctor, I complained:

$ git config --global core.autocrlf input

$ brew doctor
Warning: Suspicious Git newline settings found.

The detected Git newline settings will cause checkout problems:
  core.autocrlf = input

If you are not routinely dealing with Windows-based projects,
consider removing these settings.

Alternatively run:
`git config -f /usr/local/.git/config --add core.autocrlf false`
Warning: Suspicious git origin remote found.

With a non-standard origin, Homebrew won't pull updates from
the main repository. The current git origin is:
  

Unless you have compelling reasons, consider setting the
origin remote to point at the main repository, located at:
  https://github.com/mxcl/homebrew.git

Brew did not like  core.autocrlf = input

 core.autocrlf = false worked better...

$ git config --global core.autocrlf false
$ brew doctor
Warning: Suspicious git origin remote found.

With a non-standard origin, Homebrew won't pull updates from
the main repository. The current git origin is:
  

Unless you have compelling reasons, consider setting the
origin remote to point at the main repository, located at:
  https://github.com/mxcl/homebrew.git

Still have problem with ORIGIN

$ brew --config
HOMEBREW_VERSION: 0.9.4
ORIGIN: (none)
HEAD: (none)
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CELLAR: /usr/local/Cellar
CPU: 8-core 64-bit ivybridge
OS X: 10.8.1-x86_64
Xcode: 4.6
CLT: 4.6.0.0.1.1358221012
LLVM-GCC: build 2336
Clang: 4.2 build 425
X11: N/A
System Ruby: 1.8.7-358
Perl: /usr/bin/perl
Python: /usr/bin/python
Ruby: /usr/bin/ruby => /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby

Run brew update to refresh the home brew install...

$ brew update
Initialized empty Git repository in /usr/local/.git/
remote: Counting objects: 98489, done.
remote: Compressing objects: 100% (42612/42612), done.
remote: Total 98489 (delta 69326), reused 81362 (delta 54988)
Receiving objects: 100% (98489/98489), 14.62 MiB | 813 KiB/s, done.
Resolving deltas: 100% (69326/69326), done.
From https://github.com/mxcl/homebrew
 * [new branch]      formula-cleanup -> origin/formula-cleanup
 * [new branch]      gh-pages   -> origin/gh-pages
 * [new branch]      go         -> origin/go
 * [new branch]      master     -> origin/master
 * [new branch]      superwip   -> origin/superwip
HEAD is now at 0fa466c #{prefix} should be interpolated
Already up-to-date.

$ brew doctor
Your system is raring to brew.

Looking good...

$ brew --config
HOMEBREW_VERSION: 0.9.4
ORIGIN: https://github.com/mxcl/homebrew.git
HEAD: 0fa466c17aae2097d77f555a6e98a1466a8963f0
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CELLAR: /usr/local/Cellar
CPU: 8-core 64-bit ivybridge
OS X: 10.8.1-x86_64
Xcode: 4.6
CLT: 4.6.0.0.1.1358221012
LLVM-GCC: build 2336
Clang: 4.2 build 425
X11: N/A
System Ruby: 1.8.7-358
Perl: /usr/bin/perl
Python: /usr/bin/python
Ruby: /usr/bin/ruby => /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby

So, it seems that installing Home Brew does not get the most latest version, which was needed b/c they recently fixed the ORIGIN bug.



References




http://sergeykarayev.com/work/2012-08-08/setting-up-mountain-lion/




Sponsor Ads


Generate XML in Rails and Ruby

If you're lucky enough to have a Rails console, you can use the to_xml to return a string containing an XML representation of its receiver:


{"fname" => "foo", "lname" => "bar"}.to_xml
# =>
# <?xml version="1.0" encoding="UTF-8"?>
# <hash>
#   <fname type="string">foo</fname>
#   <lname type="string">bar</lname>
# </hash>

If you don't have the luxury of the Rails framework, then checkout the XML Builder gem.


Install Builder

$ gem install builder

Alternatively, you can put it in your Gemfile.

Open an irb Console


$ irb



irb(main):001:0> require 'active_support/builder' unless defined?(Builder)
=> true

Use Builder's XmlMarkup  functionality


builder = Builder::XmlMarkup.new(:target=>STDOUT, :indent=>2)
builder.person { |b| b.fname("foo"); b.lname("bar") }


To generate XML


<person>
  <fname>foo</fname>
  <lname>bar</lname>
</person>

If you are interested in how the Builder code leverages Ruby's dynamic language features to make this magic happen, take a look at the humbug article below.


References

http://apidock.com/rails/v3.1.0/Hash/to_xml
http://www.humbug.in/docs/ruby-best-practices/I_sect13_d1e2654.html


Sponsor Ads


Run IOS Simulators

Create an alias to iOS Simulator...

From the Finder, press Command+Shift+G and paste in the following:

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/

Select “iOS Simulator.app” and either drag it into the Dock, Launchpad, or hit Command+L to create an alias


You can also install older versions of the IOS Simulator by launching Xcode, then go to Preferences, Downloads tab, and install the desired IOS Simulator version (e.g., 6.0, 5.1, 5.0.).


Sponsor Ads


Thursday, January 17, 2013

irb Console for Cucumber and Working Example


Most folks run cucumber features in their entirety from the command line.

Have you ever wanted to run individual steps interactively?

I'll tell you how in this blog posting...

Install the crb


crb is an irb console for cucumber world.

gem install crb

crb Documentation

crb
===
  An irb console for cucumber world

Features
========
  * Can define steps interactively
  * Can execute steps interactively like debugger
  * Can share cuke world and irb context in a same object
  * Can see instance variables of step files via irb
  * Supported hooks (but only before/after without parameters)
  * Supported World methods


Run crb 
$ cd to_root_of_your_project
$ crb


irb(CRB:3):001:0> Given "I have entered 3"
Undefined step: "I have entered 3"
=> #<Cucumber::Undefined: Undefined step: "I have entered 3">

irb(CRB:3):002:0> Given "I have entered 3 into the calculator"
=> [3]

irb(CRB:3):005:0> Given "I have entered 5 into the calculator"
=> [3, 5]

irb(CRB:3):006:0> Then "I press add"
=> 8

irb(CRB:3):007:0> @calc
=> #<Calculator:0x007fa7da9d0768 @args=[3, 5]>

irb(CRB:3):008:0> @calc.push 1
=> [3, 5, 1]

irb(CRB:3):009:0> Then "I press add"
=> 9

irb(CRB:3):010:0> Then "I press divide"
=> 0.6



Project Files


features/addition.feature


Feature: Addition
  In order to avoid silly mistakes
  As a math idiot 
  I want to be told the sum of two numbers

  Scenario Outline: Add two numbers
    Given I have entered <input_1> into the calculator
    And I have entered <input_2> into the calculator
    When I press <button>
    Then the result should be <output> on the screen

  Examples:
    | input_1 | input_2 | button | output |
    | 20      | 30      | add    | 50     |
    | 2       | 5       | add    | 7      |
    | 0       | 40      | add    | 40     |



features/step_definitions/calculator_steps.rb




# encoding: utf-8
begin require 'rspec/expectations'; rescue LoadError; require 'spec/expectations'; end 
require 'cucumber/formatter/unicode'
$:.unshift(File.dirname(__FILE__) + '/../../lib')
require 'calculator'

Before do
  @calc = Calculator.new
end

After do
end

Given /I have entered (\d+) into the calculator/ do |n|
  @calc.push n.to_i
end

When /I press (\w+)/ do |op|
  @result = @calc.send op
end

Then /the result should be (.*) on the screen/ do |result|
  @result.should == result.to_f
end

lib/calculator.rb




class Calculator
  def push(n)
    @args ||= []
    @args << n
  end
  
  def add
    @args.inject(0){|n,sum| sum+=n}
  end

  def divide
    @args[0].to_f / @args[1].to_f
  end
end


Sponsor Ads


Save your fingers - Use LastPass' Fill Forms Feature

If you have a repetitive typing to do, use Fill Forms Feature from LastPass.

You can use it for personal use, auto-filling form fields with your name, email, credit card number, etc.

If you are a software tester, it's a must.



Download LastPass follow instructions to install it for your browser(s)

http://helpdesk.lastpass.com/getting-started/downloading-and-installing/



Add a Fill Forms Profile

http://helpdesk.lastpass.com/fill-form-basics/#Adding+a+Fill+Form+Profile




Here's How to User your new FillForm Profile













Sponsor Ads


Basic Editor Settings - Tabs and Spaces

Use Spaces rather than Tabs


It's important that a development team use the same space/tab setting in their IDE's, else there will be many unnecessary code merges.

TextMate

In the bottom of the document window >> Click Tab Size and select 4.
In the bottom of the document window >> Click Tab Size and select Soft Tabs (Spaces)

Convert existing Tabs to Spaces

Select all text in current document.
Main Menu | Text | Convert | Tabs to Spaces


RubyMine and IntelliJ

Preferences | Code Style | General >> Uncheck Use tab character
Preferences | Code Style | General >> Set Tab size and Indent to 4

There is a setting in IntelliJ that will auto-format a document upon each save.

You definitely want to have everybody using the same code formatting rules if you use this.









Sponsor Ads


Wednesday, January 16, 2013

My Thoughts on Automated Testing

I recently attended an Automated Test Driven Development (ATDD) course led by Jeff "Cheezy" Morgan.

I started using his Ruby-based testing code to build a automated test suite for the Scala-based application I was developing.  The results are amazing.

I've been part of many software development efforts and seen the good, the bad and the ugly.

This is the good.  Actually, it's great stuff.  It rocks!

So, in this article, I'll present my current thoughts on Automated Testing and hopefully get others thinking about it.


Benefits of Automated Testing

(1) AT Save Time
(2) AT Improves Accuracy
(3) AT Makes Continuous Integration Feasible

(4) AT Improves Application Code Quality

(1) Automated Testing (AT) saves time, compared to manual testing.  Once the test code is written and running, the time it takes re-running that test code is minuscule  compared to re-doing the manual test cycle.

(2) AT is "automated".  Assuming the tests are properly written you don't need to worry about accuracy or reliability.  The same cannot be said for manual testing.

(3) Continuous integration (CI) is the practice, in software engineering, of merging all developer workspaces with a shared mainline several times a day. Its main aim is to prevent integration problems.  Build servers, which automatically run the tests periodically.  A software shop can configure it's CI infrastructure as need be, but typically unit tests run after every commit, integration tests are run periodically, combining several developers' code commits and regression tests are run on a less frequent basis due to the time it takes to run them.

When you are able to run your AT framework and verify that the code that was just deployed to your development environment runs properly, you can then more confidently move it to the QA environment and then on to production.

(4) In addition to automated unit tests, organisations using CI typically use a build server to implement continuous processes of applying quality control in general — small pieces of effort, applied frequently. In addition to running the unit and integration tests, such processes run additional static and dynamic tests, measure and profile performance, extract and format documentation from the source code and facilitate manual QA processes. This continuous application of quality control aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development. This is very similar to the original idea of integrating more frequently to make integration easier, only applied to QA processes.

Choose the Right Test Framework / Technologies

(1) Built upon a dynamic language
(2) Built upon a language that makes code re-use easy
(3) Abstracts low level communication and browser/dom manipulation


(1) Ruby is an example of a dynamic language, one that does not require an extra compilation step to see results of code changes; which provides rapid feedback.

(2) Ruby is object oriented and has features, e.g., mixins, that make writing re-usable code "easy".

(3) This is a tricky one.  You should choose a test framework depending on what you want to accomplish.  For example, if you want to create Acceptance Tests, where the Business Owner needs to communicate requirements and verify that the code delivered at the end of the Sprint meets all of those requirements, then Cucumber is an excellent choice;  However, if you need to write Regression Tests, e.g., for code that has already been delivered, then using RSpec would be a more appropriate choice.


Get the Biz Owner, Developer and Tester on Same Page

(1) Use the Agile Development Process when possible
(2) Get the Biz Owner, Developer and Tester working together

(1)  Agile software development is a group of software development methods based oniterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.

(2) The main reason for project slippage is poor communication.  When you get the Business Owner, Developer and Test together, speaking the same language, using the same terms and truly understanding each other, then you have greatly eliminated the risk of failing to deliver expected results.


Use the Right Development Process

(1) Use Acceptance Test Drivent Development Process
(2) Developer writes comprehensive Unit Tests 

(1) Acceptance Test Driven Development is the way to go.  

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test and finally refactors the new code to acceptable standards. 



In TDD, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed “new” feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature's specification and requirements. The developer can accomplish this through user stories that cover the requirements and exception conditions. This could also imply a variant, or modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.

TDD can lead to more modularized, flexible, and extensible code. This effect often comes about because the methodology requires that the developers think of the software in terms of small units that can be written and tested independently and integrated together later. This leads to smaller, more focused classes, looser coupling, and cleaner interfaces. The use of the mock object design pattern also contributes to the overall modularization of the code because this pattern requires that the code be written so that modules can be switched easily between mock versions for unit testing and "real" versions for deployment.


(2) It is in the best interest of the developer to write comprehensive unit tests.  Not only because it helps to focus the developer on exactly what to code, but also when it is complete and delivered, those unit tests serve to prevent code from other developers, who may not be fully aware, from breaking their functionality.  


Write the Right Tests the Right Way

(1) Validate Interfaces
(2) Validate Core Business Functionality
(3) Write the Proper Amount of Test Code


(1) Every system I've worked on has inputs and outputs.  Most have interfaces to external data sources.  Those are important interfaces one which to focus testing efforts.  If a system is not getting good data, it cannot be expected to behave properly.

(2) Test code is just that:  Code.  Writing and maintaining code comes with its intrinsic costs and should be architected, designed and implemented with care.   

(3) The more test code you write, the more code there is to maintain and the more work you'll have to do when your real application code needs to change.  So, it's best to focus on testing core business functionality.  When you start writing a lot of regression test code you should ask yourself, "How much value does this code provide?"  Always ask yourself, "Will this test/code help me sell more product/services?"



Costs of Not Having Proper Automated Testing

(1) Time
(2) Quality


(1) I've been part of software development teams that performed manual testing.  That worked okay for delivering the code the first time, but it was often not repeated when the code was refactored or requirements changed.  When it was repeated, it took about the same about of time the second, third and fourth time to test as it did the first time.

I've been part of software development teams that had sub-teams of developers that worked independently and did not attempt to integrate other sub-teams' code that interfaced with their code until very late in the development process.  When that effort began, work on the core application code had to stop because it became impossible to integrate different code modules when they are in flux.

Moving integration to time of code delivery moves that integration effort way up in the development process.


A study conducted by NIST in 2002 reports that software bugs cost the U.S. economy $59.5 billion annually. More than a third of this cost could be avoided if better software testing was performed. See http://www.abeacha.com/NIST_press_release_bugs_cost.htm

Typically, the earlier a defect is found, the cheaper it is to fix it.



(2) The better architected an application is, the more modular it's design will be.  It's interfaces will be better thought out.  All of this helps tremendously when working in a team development environment.

AT helps with communicating application requirements and validating that the software delivered meets those acceptance requirements.

Show me a software development organization that has quality Automated Testing and I'll show you quality software product.



The following few sections are include for clarity.  I discussed topics from each above, but Iinclude them here for clarity:

Software Testing



Software testing can be stated as the process of validating and verifying that a computer program/application/product:

  • meets the requirements that guided its design and development,
  • works as expected,
  • can be implemented with the same characteristics,
  • and satisfies the needs of stakeholders.


Testing Levels

(1) Unit Testing
(2) Integration Testing
(3) System Testing
(4) Acceptance Testing


(1) Unit testing, also known as component testing, refers to tests that verify the functionality of a specific section of code, usually at the function level. In an object-oriented environment, this is usually at the class level, and the minimal unit tests include the constructors and destructors.

These types of tests are usually written by developers as they work on code (white-box style), to ensure that the specific function is working as expected. One function might have multiple tests, to catch corner cases or other branches in the code. Unit testing alone cannot verify the functionality of a piece of software, but rather is used to assure that the building blocks the software uses work independently of each other.

(2) Integration testing is any type of software testing that seeks to verify the interfaces between components against a software design. Software components may be integrated in an iterative way or all together ("big bang"). Normally the former is considered a better practice since it allows interface issues to be localised more quickly and fixed.

Integration testing works to expose defects in the interfaces and interaction between integrated components (modules). Progressively larger groups of tested software components corresponding to elements of the architectural design are integrated and tested until the software works as a system.

(3) System testing tests a completely integrated system to verify that it meets its requirements.  System tests test application interfaces.

(4) At last the system is delivered to the user for Acceptance testing.


Functional vs non-functional testing

Functional testing refers to activities that verify a specific action or function of the code.  These are usually found in the code requirements documentation, although some development methodologies work from use cases or user stories. Functional tests tend to answer the question of "can the user do this" or "does this particular feature work."

Non-functional testing refers to aspects of the software that may not be related to a specific function or user action, such as scalability or other performance, behavior under certain constraints, or security. Testing will determine the flake point, the point at which extremes of scalability or performance leads to unstable execution. Non-functional requirements tend to be those that reflect the quality of the product, particularly in the context of the suitability perspective of its users.




Summary

The more software engineering projects and teams I have been exposed to, the more I have come to appreciate Automated Testing.

The good news is that it usually does not matter what software stack was used to develop the web application;  Once you have a solid AT platform, you can re-use it for many application development efforts.

As with anything in life, you get what you pay for.  If you invest properly in your AT framework, you will save time and money and have a higher quality product.




References

https://leanpub.com/u/cheezy http://en.wikipedia.org/wiki/Continuous_integration
http://en.wikipedia.org/wiki/Agile_software_development
http://en.wikipedia.org/wiki/Test-driven_development
http://en.wikipedia.org/wiki/Software_testing

Sponsor Ads


Monday, January 14, 2013

Fixing Close Window Keyboard Shortcuts in Rubymine


Do the following for enabling Command (or Apple) key + W to close the active file and Command + Shift + W to Close All open files in Rubymine:

Rubymine | Preferences | Keymap | Main Menu | Edit | Select Word at Caret  >> Remove Keyboard Shortcut: command+W

Rubymine | Preferences | Keymap | Main Menu | Edit | Unselect Word at Caret  >> Remove Keyboard Shortcut: command+shift+W

Rubymine | Preferences | Keymap | Window | Editor Tabs | Close  >> Remove Keyboard Shortcut: command+F4

Rubymine | Preferences | Keymap | Window | Editor Tabs | Close  >> Add Keyboard Shortcut: command+W

Rubymine | Preferences | Keymap | Window | Editor Tabs | Close All >> Add Keyboard Shortcut: command+shift+W

Note that you must first find and remove any existing keymappings to the shortcut keys strokes you want to define.

Disclaimer:  Unless explicitly specified, blog posts will refer to a Mac development environment.


References


http://www.jetbrains.com/ruby/webhelp/closing-files-in-the-editor.html
http://stackoverflow.com/questions/11444237/rubymine-close-file-shortcut-mac-or-windows

Sponsor Ads


Enabling the Debugger for Ruby Mine, rbenv and Ruby 1.9.3



Run this from the command line:
 
$ gem install ruby-debug19 -- --with-ruby-include=/Volumes/HoneyBadger1TB/Users/lex/.rbenv/versions/1.9.3-p194/include/ruby-1.9.1/ruby-1.9.3-p194
Fetching: ruby-debug-base19-0.11.25.gem (100%)
Building native extensions.  This could take a while...
Fetching: ruby-debug19-0.11.6.gem (100%)
Successfully installed ruby-debug-base19-0.11.25
Successfully installed ruby-debug19-0.11.6
2 gems installed


Note that your path will vary. What's important is that you specify the directory of your Ruby header files with the with-ruby-include setting




Include the following in your Gemfile:
gem 'debugger'
gem 'ruby-debug19', :require => 'ruby-debug'




Sponsor Ads


Wednesday, January 2, 2013

Maintainable Code Offers No Job Security

MDD Developer Manifesto

As a mortgage-driven developer,

I make the experience of collaborating
with me as awkward and
unpleasant as possible


* without actually getting fired






Manifesto for Half-Arsed Agile Software Development

We have heard about new ways of developing software by
paying consultants and reading Gartner reports. Through
this we have been told to value:
Individuals and interactions over processes and tools
and we have mandatory processes and tools to control how those
individuals (we prefer the term ‘resources’) interact
Working software over comprehensive documentation
as long as that software is comprehensively documented
Customer collaboration over contract negotiation
within the boundaries of strict contracts, of course, and subject to rigorous change control
Responding to change over following a plan
provided a detailed plan is in place to respond to the change, and it is followed precisely
That is, while the items on the left sound nice
in theory, we’re an enterprise company, and there’s
no way we’re letting go of the items on the right.




References


http://vimeo.com/39660655
http://watirmelon.com/2010/04/10/watir-selenium-webdriver/
http://www.halfarsedagilemanifesto.org/



Sponsor Ads