The Deep Woods Brigade

Earlier we talked about building a stable economy for a contractor, freelancer, and small software company. We didn't have all the answers for our own direction at the time, but we were fairly sure which direction we were going to head ourselves; app development, web services development, and sustained paying mentorship. Since that post my outpost partner and I have been talking and positioning ourselves towards that end goal.

Today I got a phone call from my partner which moves us to our next phase. We have closed our doors to actively taking on new contracts. We have figured out a transitional path, and we are looking forward to the next couple of years of our roadmap. We will be releasing a few web services this year and at least two applications. The next couple years will be a continuation of being a full fledged software company: consultancy is secondary, if happening at all.

I say consultancy is secondary, because we have clients that we still want to continue providing support for. It's important not to leave them hanging out to dry. If you choose to make this kind of move, considering your current clientèle is vital.

The second thing to happen today is the Ubuntu SDK Live Sessions. This is awesome, as one of the applications launching this year is for the Ubuntu platform. The client will integrate with a web service launching this year, and should serve as an example for other clients on other platforms to match. I'm really excited about this particular move, as I am excited about becoming an Ubuntu shop. We're a rarity in the world to date, but I see things moving more in that direction in the near future.

Finally, it's important not to be too proud to step backwards, in order to move forward. This can be painful, and if you do this you must follow through or the move really will be a step backwards.

This is important - Have a plan; follow through with it.

My partner is taking on a full time job so that he has steady hours, in order to focus on development.

I'm helping launch my wife's next business and we're scaling back on expenses as a family. That will allow me to work full time on the new products coming out.

So, I look forward to a bright future, because we are going to continue to follow through. We are pushing most of our work, or spin off utilities, tools, and frameworks, open source to our github repo.

This is part of my journey that started almost 20 years ago. It's worth pursuing. We hope this will bring you guys a brighter future as well through this. Remember, plan, and carry on.

Bob Roberts recently posted a little bit about his journey on his own and he has had to face some difficult questions.

Setting, 'to freelance, or not to freelance' aside, the top most question on my mind is, 'How do you develop a stable income eco system as a developer.'

I am a veteran by now; darn right crusty. My wife scrapes the barnacles off of my foot each night when I pull into port. Yet the goal is constantly evading my grasp. Most of my career has been consulting, with a few jaunts off to start two ISP's and so on. I'm always changing gears and correcting course. This year I changed gears again.

This is the year of product for me and my co-workers.

Our Outpost is still doing consulting, but we're more focused on building services and applications. We realize that it's hard to do both at the same time, but at the same time, we cannot endure the feast and famine cycle that comes from only one or two sources of income. It's time to cast our bread upon the waters and see what returns.

That said, I think consulting or freelancing can still be sustainable. It just takes a lot of work.

For starters, making sure you have a good site and marketing package ready, should be a first step foreword. Then shopping said portfolio around and buying a fair share of drinks at meetups.

The biggest mistake I've seen, and we've done ourselves, is to get too wrapped up in client work. We end up spending less time with the community that helped build us, and us them, and more time dwelling on the stresses that kill us in the end. Spend time in your community; build one if you don't have one near you; and cap your work load so that you can focus on your company instead of always placing priority on other people's companies. If you don't focus on your company's infrastructure, marketing, and skill sets, you're only doing your clients a disservice because in the end they suffer most when you fall.

It's been a tradition since last summer at RebelHold, to have fridays be a hack day. We work hard to get our client work done in advance and then prepare to hack with each other whilst drink beer in a day set aside for camaraderie and learning.

Last friday we decided to make a series of challenges to learn and teach new technologies and techniques. We've always kind of done something along those lines, but now it's official. It's a thing now.

I was recently trying to use SHA2 encryption for an api when my tests kept coming back with this error:

'Encoding::UndefinedConversionError:'

It was having trouble doing an ASCII-8bit to UTF-8 conversion; or rather Digest::SHA1 and 2 were.

I tried a lot of of fixes, adding an encoding explicitly to the ruby files, placing the setting in various rails config files, using #force_encoding, the works. I threw the normal book of tricks at it, and then slammed it down a few more times for good measure. Nothing was working.

Finally I went searching for a better SHA solution when I ran into SHA3 here:

http://blog.phusion.nl/2012/10/06/sha-3-extensions-for-ruby-and-node-js/

Needless to say I learned two things:

It works like a charm,

And I need to follow Phusion's blog a little more closely.

So I finalized the move of a major app from Heroku on Sunday. On Monday I get a  request to mass change some data through the database, because changing 510 items through the web interface would be too time consuming and tedious.

No Problem! Pulls up terminal: heroku console...

Yep, I lost that. Time to toss a crutch!

So I wrote a small rake task to make it easy to log into the MongoDB instance:

namespace :production do   desc 'Log into the production mongodb cloud'   task db: :environment do     config = YAML.load_file(Rails.root.join('config', 'mongoid.yml'))['production']     system "mongo --username #{config['username']} --password #{config['password']} --host #{config['host']}:#{config['port']} #{config['database']}"   end end

I made sure to load the mongoid.yml instead of hard coding it in. That will make it easier to maintain.

So, Now to the task at hand! I need to unpublish all the items that are marked one of a kind, so that they don't show up on the site.

rake production:db

Works!

> db.items.find({published: true, one_of_a_kind: true});

That works but gives me a lot of results. Let's see how many:

> db.items.find({published: true, one_of_a_kind: true}).count(); 390

So let's update them en masse:

> db.items.update({published: true, one_of_a_kind: true}, {$set: {published: false}}, {multi: true}); > db.items.find({published: true, one_of_a_kind: true}).count(); 389

Hmmm. I tried a few variants of that, and every time it only updated one record. That option should update all that match that query.

So a workaround. Time to use forEach():

> var items = db.items.find({published: true, one_of_a_kind: true}); > items.forEach( function(item) { db.items.update({_id: item._id}, {$set: {published: false}}) } ); > db.items.find({published: true, one_of_a_kind: true}).count(); 0

Woot! And just like that all is well.

There are some takeaways from this.

I've long been too reliant on Heroku's tools; but also Rails console. By going this route I can more easily move between Rails, Node.js, etc., on any server or service

I am more likely to optimize my finds, updates, and so on

I better understand the underlying structure that my wrapper hides from me

All of that leads to me wanting to write a better MongoDB wrapper. Both MongoMapper and Mongoid have served me well for years, but I have my complaints which are not unreasonable.

Recently Heroku and I have not been getting along. Our relationship is strained, and Heroku doesn't seem to want to patch things up.

So I decided to start taking matters into my own hands. I taking my toys back!

One client's site, that gets hit hard for cyber monday every year, has been going down randomly on Heroku. Heroku fails to acknowledge the problem or give any credible support (beyond simple responses like 'look at your logs with: heroku logs --tail'). So I am moving them. They've been on Heroku for a couple year now, but when the Heroku router can't keep the site up for more than ten minutes, and they don't even notice or acknowledge that, let alone look into it themselves, it's time to move.

So here I am on Black Friday getting production servers ready on AWS in time for the Monday onslaught.

I tried Engine Yard, to somewhat mixed results. I don't think they are bad, it's just that I I don't have the time to clear those up. I'm an EC2 veteran though, and their Elastic Beanstalk looks promising.

So site requirements, a load balancer, 1-4 instances running at a given time for the application, backup, rolling logs, and a mongodb instance or two. For brevity I can continue using the cloud service the site is currently using for mongodb storage; given that in the near future I will replace it.

So I stepped into a project I haven't been on in months, with a feature clean up item to do. I need to switch the text for a link called 'Remove' and put 'Delete' in it's place.

Being a TDD/BDD shop, the place for me to look first is our tests:

bulletin-builder [master] % ls spec/requests spec/requests/site_settings_spec.rb:290:    click_on 'Remove' spec/requests/bulletin_inserts_spec.rb:62:    click_link 'Remove Section' spec/requests/bulletin_inserts_spec.rb:87:    click_link 'Remove Section' spec/requests/bulletin_inserts_spec.rb:111:    click_link 'Remove Section' spec/requests/bulletin_inserts_spec.rb:253:        click_link 'Remove' spec/requests/bulletin_inserts_spec.rb:266:        click_link 'Remove' spec/requests/manage_multi_text_blocks_spec.rb:70:      click_link 'Remove Section' spec/requests/manage_multi_text_blocks_spec.rb:92:      click_link 'Remove Section' spec/requests/manage_multi_text_blocks_spec.rb:110:      click_link 'Remove Section' spec/requests/manage_multi_text_blocks_spec.rb:132:      click_link 'Remove Section' spec/requests/manage_multi_text_blocks_spec.rb:328:        click_link 'Remove' spec/requests/manage_multi_text_blocks_spec.rb:349:        click_link 'Remove' spec/requests/manage_multi_text_blocks_spec.rb:373:        click_link 'Remove' spec/requests/bulletin_sections_spec.rb:98:    click_link 'Remove Section' spec/requests/bulletin_sections_spec.rb:169:    click_link 'Remove Section'

Crap. There's a lot there and they aren't very descriptive.

Here is where I pull out a very interesting and often overlooked tool: Grep

bulletin-builder [master] % grep 'Remove' -Rn spec/requests spec/requests/site_settings_spec.rb:    click_on 'Remove' spec/requests/bulletin_inserts_spec.rb:    click_link 'Remove Section' spec/requests/bulletin_inserts_spec.rb:    click_link 'Remove Section' spec/requests/bulletin_inserts_spec.rb:    click_link 'Remove Section' spec/requests/bulletin_inserts_spec.rb:        click_link 'Remove' spec/requests/bulletin_inserts_spec.rb:        click_link 'Remove' spec/requests/manage_multi_text_blocks_spec.rb:      click_link 'Remove Section' spec/requests/manage_multi_text_blocks_spec.rb:      click_link 'Remove Section' spec/requests/manage_multi_text_blocks_spec.rb:      click_link 'Remove Section' spec/requests/manage_multi_text_blocks_spec.rb:      click_link 'Remove Section' spec/requests/manage_multi_text_blocks_spec.rb:        click_link 'Remove' spec/requests/manage_multi_text_blocks_spec.rb:        click_link 'Remove' spec/requests/manage_multi_text_blocks_spec.rb:        click_link 'Remove' spec/requests/bulletin_sections_spec.rb:    click_link 'Remove Section' spec/requests/bulletin_sections_spec.rb:    click_link 'Remove Section'

That's better. I know this is related to bulletins so that helps my search a bit. But, I don't know if the previous developer worked on this feature. It was failed by the client. I better look for 'Delete' as well.

bulletin-builder [master] % grep 'Delete' -Rn spec/requests spec/requests/site_settings_spec.rb:106:    click_link 'Delete' spec/requests/site_settings_spec.rb:160:    click_link 'Delete' spec/requests/site_settings_spec.rb:476:      click_link 'Delete' spec/requests/site_settings_spec.rb:478:      page.should have_content 'Custom STB Deleted' spec/requests/site_settings_spec.rb:515:      click_link 'Delete' spec/requests/site_settings_spec.rb:517:      page.should have_content 'Custom MTB Deleted' spec/requests/quote_section_spec.rb:82:    click_link "Delete" spec/requests/quote_section_spec.rb:183:    click_link "Delete" spec/requests/quote_section_spec.rb:185:    click_link "Delete" spec/requests/bulletin_inserts_spec.rb:90:      click_link 'Delete' spec/requests/bulletin_inserts_spec.rb:242:          click_link 'Delete' spec/requests/reading_section_spec.rb:81:      click_link 'Delete Section' spec/requests/reading_section_spec.rb:115:      click_link 'Delete' spec/requests/user_settings_spec.rb:52:    click_link 'Delete' spec/requests/rss_feed_multi_text_spec.rb:110:        click_link 'Delete RSS Feed' spec/requests/rss_feed_multi_text_spec.rb:115:        click_link 'Delete RSS Feed' spec/requests/organization_contacts_spec.rb:62:  #   click_link 'Delete' spec/requests/organization_spec.rb:71:    click_link 'Delete' spec/requests/manage_multi_text_blocks_spec.rb:96:        click_link 'Delete' spec/requests/manage_multi_text_blocks_spec.rb:354:        click_link 'Delete' spec/requests/bulletin_spec.rb:106:      page.should have_link('Delete') spec/requests/bulletin_spec.rb:147:        click_on 'Delete' spec/requests/bulletin_spec.rb:159:        click_on 'Delete' spec/requests/bulletin_sections_spec.rb:179:    click_link 'Delete Section' spec/requests/bulletin_sections_spec.rb:204:    click_link 'Delete' bulletin-builder [master] %

And so, with that fancy old timey tool, I have a grasp on where I could head first.

I don't know about you, but having paperclip output in test output is freaking annoying! Here's a simple way to eliminate that. Drop this at the bottom of your config/enviroments/test.rb:

Paperclip.options[:log] = false

Recently I had to use the old rails 2 style url in a spec. This was not a mailer spec. Rspec gave me the error of not having a default host set; that you would normally get if it wasn't set up for your environment in a mailer. All of my mailer stuff was set up fine, so what gives?

Well I did recently install email_spec to start testing mailers. Perhaps that mucked with it?

More on that later. Meanwhile, after digging around a bit, I found this issue:

https://github.com/rspec/rspec-rails/issues/255

So, I spun up vim and edited my spec/support/capybara_support.rb

Just paste this in the bottom and it should cover most classes that need the default_url_options for view helpers:

[ApplicationController, ActionController::Base, ActionView::TestCase::TestController, ActionDispatch::Routing::RouteSet].each do |klass|    klass.class_eval do      def default_url_options(options = {})        {          host: 'example.com',          port: Capybara.server_port        }.merge(options)      end    end end

If you want to get started on using Rails 4 Beta, if you want to live on the edge, here's how you'd most likely start:

This will get the rails app ready to install. Next replace your Gemfile with this:

Lastly:

Accept all overwrites.

I was dinking around in rails api to see if there were any new tricks that I hadn't used yet, and I had a particular need to add an email confirmation field to a current project, when I found the confirmation key for validates on an ActiveModel.

Normally When I have this need I add separate validates for each aspect, like so:

class User   includes Mongoid::Document   field :email

  attr_accessor :email_confirmation

  validates :email, presence: true   validates :email_confirmation, presence: true, if: Proc.new {|user| user.email == user.email_confirmation} end

But now, with the confirmation key, I can whittle that complexity down by a line:

class User   includes Mongoid::Document   field :email

  attr_accessor :email_confirmation

  validates :email, presence: true, confirmation: true end

Not only is that easier to read, but every line counts on the readability of your models in a distributed team.

Adding to the series on Responsive Design is Hard, I thought this link was relevant; especially since all of my design is done is Sass. Adam is an excellent designer and I think this link shows some of the underbelly of that.

After several jibes from our friends about not having something up for people to read, here we are!

We plan on basically writing about everything we do, from our open source projects, to our apprenticeship programs through RebelHold, to how our worker owned and run co-operative works across many states, time zones, and even management structures.

We hope you enjoy.