Configuring Devcamps to run multiple Apache or NGINX instances

Here is a solution for enabling Devcamps to run your apps using separate instances of Apache2.

Out of the box, Devcamps does not configure our Apache2 setup.

It's nice to go from running mkcamp to viewing a live version of the app on the camp port without running any additional setup scripts.

I knew running multiple apache2 instances was possible. Googling some brought me to run this in my terminal:

cat /usr/share/doc/apache2/README.multiple-instances

The key take away is this:

The basic idea is to copy /etc/apache2 to /etc/apache2-xxx.

Since our 'camp type' directory [camp_type]/etc gets copied down to our camp directories on running mkcamp, we can copy the /etc/apache2 directory to our [camp_type]/etc directory and modify the appropriate Apache config files with our camp tokens. The 'magic' happens when we change httpd_command_path value in local-config to:

httpd_cmd_path:sudo cp __CAMP_PATH__/apache2-camp/apache2ctl __CAMP_PATH__/apache2-camp/apache2ctl-camp__CAMP_NUMBER__ && sudo __CAMP_PATH__/apache2-camp/apache2ctl-camp__CAMP_NUMBER__

This will allow us start the apache2 binary on separate processes for each camp.

The apache config files I tokenize are as follows:

apache2-camp/apache2ctl
apache2-camp/apache2.conf
apache2-camp/ports.conf
apache2-camp/envvars
apache2-camp/sites-enabled/site.conf

Update: 12/04/2015

The above code works. However, we don't want to run our web servers as root. There is a better way and it's baked into devcamps. The copy-paths.yml file lets us include the camp tokens in the paths with the 'parse_target' options.

source: /usr/bin/apache2ctl
target: apache2-camp/apache2ctl-__CAMP_NUMBER__
always: 1
parse_target: 1

Happy camping!

Create Value From Technical Difficulties

Like a fine tuned engine, great software development runs when there's minimal technical difficulties.

Let's refer to these technical difficulties as "FRICTION$". Like real friction they heat EVERYONE up and in the end they are costing us money and time.

It isn't uncommon that a developer could spend anywhere between 1 and 5 hours per week working on FRICTIONS$ of environment configuration. If you have a 4 person dev team you could be looking at 16-80 hours lost to friction in critical months across the team.

How many man-hours are you spending per month in configuration? Per developer? Per year?

By the end of this article you will know how to spot some FRICTION$ in your project and I will share with you a skill to turn FRICTION$ into value

Project stakeholders in a make or break position can quickly feel the burn on their checkbooks and calendars when projects begin requiring more complex environments. Coordinating upgrades with all engineers can become a large point of FRICTION$

Upgrades, integration of new modules and services, boots and reboots are naturally part of the creative process, and reaching stable environments quicker is the oil that increases your teams velocity. Here are some external FRICTION$ that we end up paying for if we work in traditional offices or in remote teams.

Human condition + Murphy's Law
What's the cost to your project if a laptop is stolen or has a virus? Flood? Battery failure? Lost power cord? Chewed power cord? What if a developer has worked on your project across multiple computers?

Did you know you can mitigate the risks of problems on a developer's computer effecting their ability to complete work on your product?

Is it costing you time when your engineers need to take the time to install development tools when they get Apple's newest Mac Book Pro or they need to dig out an older system because of a system failure or even worse, theft.

OS SHOWDOWN, Fragmentation, BYOD
For many start-ups, we want to stay LEAN and operate at a fast velocity. We find talent with different diversity and with that will come stakeholders who prefer or have requirements of different technologies, operating systems, system specs and in the Glory of the Chaos we must all collaborate and build something awesome, yesterday on our virtual islands and reconnect them the mother-ship for take-off.

Don't miss the rocket - Let me help you empower your team to drive your ship.

Even more burning questions. (Yes that is a large LION in the room)
How secure are the systems of your remote developers? How exposed is your data or your clients data?

Take a few breaths. There is hope. I started sleeping a lot better at night after I made one simple change as a developer.

This is a change that could save your project up to 200 hours per year. Now before I tell you the change that helped me wrangle the beast I want you to think about where you project could use another 200 hours of development. Got it? Good.

Coming through on my promise, the simple change I made that has helped reduce FRICTIION$:

I started developing and collaborating with teams on a remote development system. No development work took place on my actual computer. It all happens on an AWS instance. This all hands on deck approach has turned repetitive apples and oranges configuration, and "island life" into unified development work that creates product value. The tools that make this possible go by the names of Vagrant, Docker, github and Devcamps.

Please leave a comment below if FRICTION$ are costing your project time and money and you want to reclaim 200 man-hours. Developers, how do you combat FRICTION$?

The Future of Wireless Internet in Costa Rica

Clients always want to know about my internet connection in Costa Rica

Until recently, using the internet was a challenge I have had pretty much every day for the past 8 years.

It wasn't till this last month when my service provider Japi delivered a flat-line signal to my off-the-grid office for the last 30 days that I had to start the search again on backup solutions.

I did an exhaustive search talking to every company providing WiWax to Microwave (Point-to-Point) services about what could be done to get service here, including the possibilities of installing towers.

The ultimate solution was to rent an office in town for about $200 per month including internet expenses and to fix the problem up here at the off-the-grid office permanently.

Here is what I found and would recommend.

GET READY FOR IT!!!!

Wait till 2016!

Yesterday I spoke with Alberto Araya regarding cell signal boosters and he told me that in 2016 affordable internet in off-the-grid locations problem will be possible. I confirmed what he told me. There are two scheduled satellite launches for late 2015 (Eutelsat 117W B) and mid 2016 (Via-Sat 2) that will bring the same technology used in "in-flight" internet service to the Central America region of the world. It will probably come in a package in this form: Tooway or may be sold by other national carriers. This isn't any ordinary satellite internet. We're talking 5Mb uplink! 22Mb downlink.

In the mean time you might need to test/try different carriers and boosting their signals. Under the "about your phone" menu on your phone there's a menu that shows signal strength (-60dbm to -110dbm). A strong and steady signal keeps your connection strong is on the -60dbm side. As the number increases and gets around -100dbm your signal degrades and calls are dropped. There's also an app called Antenna Point that should point you in the direction of the tower you are connected to.

My past weekend was spent walking around my place and taking measurements at places I noticed signal. I found I could get 3G internet at most places from Kolbi and Movistar. The hill up there getting a steady -77dbm to -83dbm. The house getting about a -90dbm. The Antenna Pointer program helped a lot too because it showed me I was actually on a different tower and that different carriers needed slightly different angles.

I will be having Alberto boost my signal. He's in Ciudad Colon and will sell the equipment or install.

It could give a nice improvement to the signals that arrives here so there is better backup in the home office in case Japi is down.

Like a pilgrim, waiting for latest ship from GB I wait eagerly for news of the satellite launches!

I am published!

I want to thank the team at Tealeaf Academy for inviting me to contribute to their Introduction to Programming with Ruby book.

Diarrhea Cure

Healthy software development starts with healthy mind and body.

Here is my cure for diarrhea.

Ingredients:
1 handful Guarilama
5 teabags of chamomile tea (te de manzanillo)
5 ripe guava
4 tablespoons linseed (semilla de linaza)
2 liters of water

Preparation:
1. Bring 2L of water to boil with the Guarilama, chamomile tea, and guava.
2. Turn off heat and mix in the linseed.
3. Let sit for about 5 minutes.
4. Chill.

Serve chilled and drink 2-3 8oz glasses per day. Symptoms should improve within a few hours of the first glass.

4 Quick ProTips for New Ruby on Rails Programmers and Managers

I'm writing these four tips for programmers and managers who are starting to work professionally on projects using the Ruby on Rails development framework. These tips are helpful in fine tuning your understanding, and productivity on the apps you are working on. Bottom line, your team mates and project managers will be happy you have these things under control.

1. "Read the code"

   Often, our expectations mislead us and the code that we or others have written produces different outcomes. The first reaction might be to ask other team members for help. The next time you hit this, first ask yourself, "Did you read the code?" Did you read it all? Did you go to the next file in the stack-trace? Did you dig into dependent gem's code? You see new methods or syntax you don't understand? Keep reading! The solution is in the code!

2. rake routes

   Are you curious about a path in the app that you need to hook up client-side code to? The Rails stack along with rake has a slick command that breaks down all the paths that the app handles. Simply run: rake routes
   Does the app have tons and tons of routes? Pipe the output through grep to search for the keyword you are looking for: rake routes | grep 'resource_name'

3. Speed up your Rails Environment

   The faster your environment, the faster you can deliver value on your projects. Rails apps grow, and loading dependencies takes time. Constantly look for ways work around these known obstacles and you will find you can quickly iterate on your rails app confidently. For many years I found myself waiting for test runs, console restarts, rake tasks, etc. I recently started using a tool (zeus) to eliminate these wait times. Make sure you and your team aren't wasting time.

4. Write integration and unit tests

   Without evidence of a fully integrated system, you have no control of your app. This lack of control quickly will be seen in uncontrollable errors, costs, and expectations. Do your team a favor and demand any code commit for feature or bug fix go in with passing unit and integration tests. But we aren't just writing test code for clients, we're writing them for other programmers too! I currently prefer using rspec for unit tests and cucumber with capybara for integration specs where browser interaction is required.

Move terminal cursor to front of prompt while attached to GNU Screen

Moving your cursor to the front of a terminal prompt will save you time and frustration. To move your cursor to the front of the terminal prompt in a bash shell session simply use the key binding

C - a

Since it is common that C - a is the key binding for GNU Screen, you have to use:

C - a - a

The other option is to bind it to a key for your shell. In bash, add this line to ~/.bashrc

bind '"\C-p": beginning-of-line'

Then

source ~/.bashrc

Now you can nail that cursor home anywhere with:

C - p

This is the two-step of terminal prompt dance moves. Learn it.