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!