Jon, Vicki, and Matt at the Ithaca 5&10 Race

One peril of software development is that there is too much sitting going on.  The mind and spirit get exercise, but not the bod.  We’ve experimented with knee stools, yoga balls, and stand-up desks at GORGES with mixed results.  Several of us walk or bicycle to work.

This fall our office manager Vicki has pushed a fitness challenge on the staff.  For those who volunteered (or were conscripted!), we divided up into three teams and are placing checkmarks on a master schedule when we exercise.  GORGES has sponsored trial memberships at the Finger Lakes Fitness Center for their six-week fall challenge.

In previous years we have taken the crew to the Hoffman Challenge Course at the Cornell Team & Leadership Center, and this year’s fitness challenge can certainly be labeled team-building.

The fall results aren’t in yet, but and unfortunately some of the fitness gains may be erased when we hold our gluttonous end-of-fitness-challenge party.

On Friday afternoon the event started with brainstorming sessions, and presentations of possible startup ideas were made that evening.  Votes were cast and teams formed around the half-dozen or so leading ideas.  Each team had students with different roles for the concept development, business modeling, and actual programming.

Fueled by caffeine and sugar, the teams worked all weekend in preparation for Sunday evening’s final pitch.  For GORGES’ role, Don Ellis and I were involved at the three mentoring sessions.  To the best we could, we asked questions and offered advice based on our own startup experiences.

On Friday evening the teams presented their ideas and working prototypes to a panel.  The presentations were well-attended, and I would not be surprised if a few of these teams evolved into real startup companies.

As for the actual ideas, most involved using mobile smartphones.  That is a clear indication of where future opportunities lie, and I’m glad we have cultivated and matured our mobile development talent at GORGES.

It was great to see such enthusiasm during the weekend, as well as impressive programming and business talent.  Kudos to Sohan and his team for putting together a great event.

Usually developers work directly on their workstations or laptops, and a development environment has both web and database services running similar to a production server. Ideally a development environment should have the same versions of services as the production server, for example PHP 5.2 or Ruby 1.9.  On more than one occasion I have been bitten by writing MySQL 4.3 or 5 code, but the production server has an older version of MySQL without sub-query support so the queries had to be rewritten.

Usually these development services are customized for development, for example the database does not have to be hardware-optimized and the web service can have debugging tools enabled.  I prefer to turn on all warning messages, so any identified problems that are not severe enough to halt page serving will be shown either in a log file or onscreen.

Just as important with having a staging server is to have clean and well-structured publishing scripts.  If you are relying on a manual process to upload files using FTP, then it is possible to skip an updated file by mistake.  Publishing scripts come in all sorts of flavors and approaches – we have both “pull” methods that use server-side scripts, and “push” scripts that execute on the developer’s computer and automatically upload files to the server.  The push scripts are built on Capistrano, which although it is based on ruby we sometimes use at Gorges for non-ruby websites.

We routinely protect our staging servers from prying eyes and search engines by using HTAuth username and passwords.  Once a website is scanned by a Google, Bing, or other web crawler then it is out of your control.

Having a staging server doesn’t mean much unless it is actually used to test new features and look for bugs.  Quality assurance is important, and I have yet to meet a developer that produces bug-free code or see a unit testing system that covers 100% of a web application feature set.

Not covered in this post is the issue of database migrations between developer environment and a staging server, and also from a staging server to a production machine.  These can be tricky, but as with all challenges the proper planning will guide you to the best solution.

After the application or update goes live to the production server most staging servers are continued as “sand boxes” to support additional updates and testing.

Team Mini-Figures: Willem Magre, Samuel Bazarov, Gaelen Walsh, Quinton Clark, Trevor Clark, Geoffrey Clark

The GORGES offices have been host to a Lego Club this school year.  About twice a month, a group of lego enthusiasts have met at GORGES to prepare a project and poster for the Junior First Lego League, the youngest category of the national organization FIRST.

The contest theme this year is Body Forward, and the directive was to create a project for biomedical engineering.  The team, who named themselves Team Mini-Figures, interpreted this as building a hospital that has advanced devices to help people, and several medical vehicles (ambulance, helicopter, boat) to transport people to the hospital.

Head extractor with spare parts in the hospital room.

One requirement of the project was to have at least one item that moves.  The team created an automated stretcher transporter and a windmill.  Ideally wind would drive the generator and provide electricity for the hospital, but for demonstration purposes the boys connected a battery to the generator so the windmill blades would spin.

Pictured to the left is my favorite device.  Samuel and his teammates created a head extractor in case someone needs a replacement.  There were spare bodies, heads, and legs in the extractor room for quick access.

On January 29th, 2011, the Mini-Figures team presented at their first competition.  The judges awarded the “Best Environmentally-Friendly Hospital” award to the team.  Thanks go out to the Cornell NanoScale Facility for sponsoring the local Jr. First lego event.

Our pro bono effort to help with Gulf oil cleanup (www.gulfsaversolutions.com) was a type of singular environmental action. That’s worthy, but what counts largest are the routine actions.

Here are some routine efforts that we make at GORGES.  If you would like to know about our experience with any of these, please contact me or Don.

Communicate electronically:  We send invoices electronically unless we are explicitly asked to send by postal mail.  This significantly reduces paper use, and we have found as a bonus that clients often pay more quickly with this method.

We send newsletters by email. It’s rare that anyone we are talking with declines to receive the newsletter. We use a service to send it and monitor the sending, and almost one-half of our recipients open the newsletter.  If given a choice, we ask businesses that send print newsletters to us by postal mail, or other recurring correspondence to switch us to email. If they are not setup to do that, we offer to help with the advances.

Reduce paper usage:  Over the holidays some of my family visited and we toured the GORGES offices.  My sister marveled at how little printed paper there was in everyone’s work area.  It’s true – we have set up collaborative file repositories and work almost exclusively electronically.  There are days when our group of seventeen prints nothing.

Turn off appliances:  This is obvious, but it does work.  Even devices on standby mode consume some power.  We supply power strips to each workstation area and encourage staff to turn off the entire strip at the end of the day.  Turning monitors off is common enough; turning the whole computer off helps even further.

When we switched offices last summer I changed our phone extensions from using many individual power adapters to a single power-over-ethernet switch device in our server closet.  The energy savings may be marginal, but the added benefit of reduced wires and freeing up a workstation power outlet was nice.

The biggest savings come from deactivating devices entirely.  By upgrading some servers at our co-location facility, we have decommissioned five servers in favor of two new ones.  An added benefit is reducing number of our uninterruptible power supply units, which require expensive lead-acid batteries that only last 2-3 years.

Reused & recycled items:  We built out our office with re-purposed furniture, saving thousands of dollars.  There may be a scratch or three on the new desks, but it sure beats the fold-up tables we had during our early startup years.  And old items and equipment are not always sent directly to the trash – we are regular contributors to the Finger Lakes ReUse Center.  Of course we also do the standard office paper, plastic, and metal recycling.

Plants:  We have many indoor plants. They are great to look at and help to clean the air, particularly in rooms with minimal air movement or no windows. Employing electrical devices to do the same is costly, annoying, and boring.

We have an active thermostat control program. We are after all a bunch of techies, so we can handle programming the devices!  We can all handle an extra degree without being uncomfortable, and this reduces our power consumption.

Location:  We love working downtown, and have remained here despite seeing other tech companies move to the office parks and ‘burbs.  Several staff (including myself) walk to work, and others bicycle or take public transportation.  We have one client who provides bus fares to all employees for going to and from the office (and even to travel to meetings).

In summary, I’m sure you can think of other ways to reduce your power or materials consumption in your own office as well; it all counts.  Let us help if our experience or technical skills can contribute to reducing consumption.

The first step was to research a solution, and a Cisco Linksys PAP2T device seemed like the best device.  Usually it is bundled with a service contract by VOIP Internet phone companies, and there are many unlocked units available ($32 incl. shipping – I love eBay).

Once the device arrived, I first created a SIP (Session Initiation Protocol) extension in our Trixbox configuration panel (we used extension 40).

Next we need to know the IP number used by the PAP2T so we can use a web browser to program it to interface with our Trixbox phone server.  First plug in the power connector, an ethernet cable to a DHCP-enabled network, and an analog phone into line 1.  The analog phone should have a dial tone, so from this phone type four asterisks (“****”) to activate the PAP2T voice-based setup menu.  When prompted, type “110#” to get the IP number of the PAP2T.  Another way of determining the IP# is to

From a web browser, enter the IP# of the PAP2T device (our device used http://192.168.1.131).  You should next see the PAP2T configuration screen.  Click the Admin Login link at the top-right, then click the Line 1 tab.  These fields had to be entered:

• Proxy: 192.168.1.2 (use the IP# of your Trixbox server)
• Display name: fax
• User ID: 40 (this is the extension)
• Password: **** (no, I’m not going to reveal our password here!)

Different trixbox setups may require different configuration settings, but these four items were all that we needed.  Click the submit button any you’re ready for faxing.

Note that this is not the only way to integrate a PAP2T with Trixbox.  Other solutions used TFTP to program the PAP2T during a device restart, but this seemed unnecessary compared with the simplicity of the above instructions.  And there are plenty of software or service solutions (e.g. HylaFax, asterfax), but our fax machine is also an office scanner and copier so we wanted a hardware solution.

Someday we may add an automatic fax signal detector and route a fax automatically to our fax machine (it seems to be a simple Trixbox setting or extension), but that’s a future project.

Patrick presents his iPhone and Android apps for the New Roots Charter School to the GORGES staff.

We recently hosted a student intern at the GORGES offices.  Patrick Putnam is a student at the New Roots Charter School, and joined us for his Intensives Week program, supervised by his teacher Sarah Rubenstein-Gillis.

We recommended that he try to create a mobile phone app that could be used by students and staff at New Roots.  Patrick came up with several features that would be useful to have on a mobile app, for example the school academic calendar, map directions, website links, and accessing an online system so students can check assignments.

After an intensive week (now we know why they call it that!), Patrick created working prototypes that run on both iPhone and Android devices.  He based his solution on the GORGES mobile framework we have developed that is in turn built on top of a leading mobile development platform.  The prototype has the calendar, map, and links features, and features Patrick’s photography in the splash image.

Every few weeks we host “GORGES University” where one of us shares some new knowledge or tidbits during a brown bag lunch meeting in our office lounge area.  This week Patrick presented his project, followed by an equally-lively discussion about mobile technology.

We have enjoyed having Pat with us for his program, and GORGES will support his iPhone app store submission when the app is finalized.

Our hats are off to Patrick for his successful internship!

I have been developing software since high school, and building software and web applications for about thirty years.  If there is one thing I can count on, it is that the software business will continue to change.

Ten years ago we had primitive web browsers, and web pages were usually exclusively HTML.  Microsoft and their proprietary ActiveX technology dominated the browser wars.  As a developer, there were few debugging tools and no decent server-side or Javascript frameworks.  Developing web sites took time, and the results were clunky and crude by today’s standards.

I am pleased at how efficient we are nowadays and how much value we offer, since we develop great solutions at a fraction of the time and cost compared to the days of web infancy.  We have learned to leverage existing open source or proprietary packages as much as possible, and have a wealth of development, debugging, and deployment tools in our arsenal.  If we are allowed to target “modern” browsers such as IE7/IE8, Firefox and Safari, then we can count on browser support for features required by web 2.0 graphics and behaviors.

The web server hardware industry has also had amazing strides, and every year we see better value and better prices.  For example we recommended a single modern server for hosting a client’s complex web application instead of their previous vendor’s recommended 3-server cluster approach; the resultant performance has been similar to our estimated model, and every month for the last three years our customer has saved thousands of dollars since hosted cluster solutions are expensive.

Back to the blog title:  in our business, if we do not continue to learn from and embrace technology improvements, then we will lose our competitive edge.  The obvious result would be that we will no longer be quality or price competitive in the web development market.  Few other industries have this sort of pressure – consumer electronics and mobile phones are probably other examples.

It is interesting to note that only the software industry allows small firms to compete with larger ones, since creating new hardware products require so much more capital than software development.  That is one reason why there is so much more innovation and creativity in the software industry, which really has exploded now that laptops and app phones are ubiquitous.

What will the web world look like in the future?  Prognostication is not one of my strengths, but I imagine we will see more web applications tailored towards mobile solutions (app phones & differently-sized tablets), continual improvements in frameworks, and probably the browser battles will continue to be fought between Microsoft, Firefox, and Google.

And as for myself, I plan on continuing to learn and adapt.

Chris climbs the tower.

In October we engaged the Cornell Team & Leadership Center for our annual retreat.  We spent an afternoon at the Hoffman Challenge Course, located just a few miles outside of Ithaca.  The weather could not have been better.

Jim Volkshausen, Paul Louis, and the other Cornell Outdoor Education staff were great,. They led us in team building exercises as we pushed ourselves through new challenges.

The first was to add one person at a time to a giant teeter-totter.  It took a while, but we were able to get our entire team on a seesaw platform without it tipping.  As you can imagine, it took planning, communication, coordination, and (you guessed it) teamwork.

Mia Climbs Wall

We moved on to other challenges, such as having four of us climb separately and then stand together on a very small platform on top of a tall pole while team members on the ground managing our safety ropes.  Once we were up, there was only one way down – trusting the rope team and just jumping! 

The Cornell Outdoor Education staff helped us understand our “high-functioning” team behavior. Every event challenged our communication and problem-solving skills. And, it was all great fun.

Other activities included climbing the 64-foot-high tower wall and shooting down the zip line. We jumping off the tower free-falling 10-15 feet before swinging in a giant arc through the tree tops.

Four Jump Together Backward from Pole

Our toughest moment wasn’t physical but emotional – Rasmus’s wedding ring flew off during a high-pole maneuver. We could not find it in the wood chips and leaves, but Chris and Paul succeeded the next day with a rented metal detector.

Belaying Team Supports the Jumpers

Alex caught the ring’s descent on video camera, and was able to send the movie to Chris’s smartphone to direct the search. It had flown much farther than anyone thought, and without the video help it could have been lost forever. Hurray for high-tech gadgets!

We love the Cornell Outdoor Education crew, and hope to keep going back.  Jim and his crew were quick to point out that we had only touched on a few of the many activities that they offer.

To make updating the app automatic, we use content on the Y’s website. The website for the Y is modern and it sends out several RSS feeds. We pull these feeds into the app to continually update it with the latest information. There are convenient links on the app for the Rye YMCA website, map location, Facebook, YouTube, e-mail address, and a single button to dial the Y telephone number.

The client is thrilled, and is considering adding Android and Blackberry apps as well.

To open the Rye YMCA link in your iTunes, click this link.  If you have an iPhone or iPod Touch, download it and check it out!