Author Archive

Intern Creates Smart Phone App

Thursday, December 9th, 2010
Patrick Putnam presents his 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!

worked in academia, corporate research labs and several technology startup companies prior to GORGES. His expertise is software architecture, database development, and system administration. Matt brings GORGES over 25 years experience developing fast and robust software on a multitude of platforms and languages.

Web Development – Adapt or Die

Monday, November 22nd, 2010

The blog title sounds extreme, but there is truth to these words in our industry.

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.

worked in academia, corporate research labs and several technology startup companies prior to GORGES. His expertise is software architecture, database development, and system administration. Matt brings GORGES over 25 years experience developing fast and robust software on a multitude of platforms and languages.

Our GORGES Adventure

Wednesday, October 27th, 2010
Chris climbing

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 climbing

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

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.

worked in academia, corporate research labs and several technology startup companies prior to GORGES. His expertise is software architecture, database development, and system administration. Matt brings GORGES over 25 years experience developing fast and robust software on a multitude of platforms and languages.

New iPhone App: Rye YMCA

Tuesday, October 5th, 2010

We recently launched an iPhone app for the Rye YMCA.  It displays events, schedules, articles, videos, and other information useful to the members and community of the YMCA in Rye, New York.

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!

worked in academia, corporate research labs and several technology startup companies prior to GORGES. His expertise is software architecture, database development, and system administration. Matt brings GORGES over 25 years experience developing fast and robust software on a multitude of platforms and languages.

Developing Apps within Android’s 16MB Memory Limit

Friday, July 16th, 2010

One challenge to developing for the Android platform is how to squeeze everything into 16 megabytes of heap space.  App-phones with 16GB and 32GB are common, but that is solid state storage and not RAM.  For Android applications, the limit for each application is 16MB (24MB on newer Droid and Nexus One phones).

Images, audio, and video are memory-intensive items, and many apps have these features. There are tools to help monitor memory use (e.g. Eclipse MAT, Android DDMS), and these tools are good for diagnosing problems, but you still need to understand enough to be able to fix memory leaks.

Here are some ideas for reducing the memory footprint of your application:

Reduce image sizes:  Lower the width, height, pixel bit-depth, and compress your images as much as you can.  Of course when an image is uncompressed and loaded into a Bitmap object then it takes up more memory, but you can reduce the memory footprint by lowering the image quality (for example see: View.setDrawingCacheQuality and View.DRAWING_CACHE_QUALITY_LOW) or even disabling the cache on views containing images.

Lower audio and video bitrates: I don’t know this for a fact, but I would guess that a lower-bitrate audio stream may have a smaller memory requirement during playback.  For example a mono-48 kbit/second audio file would require decoded fewer samples per second than a stereo-192 kbit/second file. (Please comment to this post if you test this theory or know the answer.)

Destroy or reuse objects: When you can, re-use objects and make sure that old objects are fully-destroyed. when they are no used anymore.  Even better, never create objects in the first place if possible.  This is especially true for bitmap objects – be sure to call the Bitmap.recycle() method. Remember to clear callback methods of objects before destroying them, because otherwise an object may not be properly returned to the memory heap during a java garbage collection operation.

Use final and static:  Virtual methods take up more space, and are slower, than static methods.  Final variables and arrays are stored in code space and not the memory heap.  Granted the difference is very small compared with 16MB of space, but every little bit counts!

Separate applications for localization:  If you are developing apps for multiple languages, consider creating separate applications instead of including all the language-specific strings, images, audio files, and videos in a single application.

Rely on external storage:  If you know that there is smart-card memory available, use that to store data instead of in memory.

Revert to an earlier Android SDK: When we reverted our most-memory-challenged Android application from Android 2.2 to Android 1.5, we gained two important things: first, we are now compatible with almost all existing Android phones; and second we reduced our memory footprint by almost a megabyte.  This latter statement is extremely interesting, since it indicates that the Android framework is getting bloated by all the new features added between versions 1.5 and 2.2.

worked in academia, corporate research labs and several technology startup companies prior to GORGES. His expertise is software architecture, database development, and system administration. Matt brings GORGES over 25 years experience developing fast and robust software on a multitude of platforms and languages.

Distributed Dictionary Attack Solutions

Saturday, June 26th, 2010

We have had the misfortune of having attempted distributed dictionary attacks on our Linux servers.  A dictionary attack uses a long list of common usernames and passwords trying to find a way to gain a foothold and eventually root access of a password-protected server.

Our servers use utilities such as fail2ban or denyhosts that look for repeated failed login attempts, and once found they direct the firewall service to ban the originating IP addresses.  However this technique fails when the attack is distributed among thousands of compromised “zombie” computers that are doing the bidding of a malicious hacker.

Our log files correctly diagnosed each attempt from an individual IP address, but a new attempt was immediately started from a different IP address.  We were clearly looking at an attack coordinated from a single unknown source.

There are several ways to reduce or thwart these attacks, including:

  • never allow remote root logins (but attacks still occur on non-root-user names)
  • have a chroot jail shell in case an attack on a non-root account succeeds
  • changing SSH service to use a non-obvious port (such as port 5022 instead of 22)
  • deactivate password authentication and rely exclusively on authentication keys
  • restrict allowed IP address by country of origin
  • only allow certain IP addresses or ranges of addresses to have access

We chose to implement more than one of these solutions, and I wanted to share some techniques we used for our implementation.

For the last rule that only allows certain IP addresses, I wanted to start with a list of valid IP addresses used in the last month.  The following script extracts these IP numbers from our SSH log file, sorts them alphabetically, and then removes duplicates.  Note that this server uses Fedora – you may need to tweak it for other linux distributions.

root# fgrep "Accepted" /var/log/secure* | awk '{print $11}' | sort | uniq
166.77.6.4
205.232.34.1
67.255.5.155
...

The IP addresses from the above script should be added to the file /etc/hosts.allow in the following format:

# hosts.allow   This file contains access rules which are used to
#               allow or deny connections to network services that
#               either use the tcp_wrappers library or that have been
#               started through a tcp_wrappers-enabled xinetd.
#
#               See 'man 5 hosts_options' and 'man 5 hosts_access'
#               for information on rule syntax.
#               See 'man tcpd' for information on tcp_wrappers

# allow local addresses
all: 127.0.0.1
all: 192.168.1.*

# valid IP addresses gathered June 2010
all: 166.77.6.4
all: 205.232.34.1
all: 67.255.5.155
...

Now disallow all other IP addresses for SSH by editing the file /etc/hosts.deny:

# hosts.deny    This file contains access rules which are used to
#               deny connections to network services that either use
#               the tcp_wrappers library or that have been
#               started through a tcp_wrappers-enabled xinetd.
#
#               The rules in this file can also be set up in
#               /etc/hosts.allow with a 'deny' option instead.
#
#               See 'man 5 hosts_options' and 'man 5 hosts_access'
#               for information on rule syntax.
#               See 'man tcpd' for information on tcp_wrappers
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow.  In particular
# you should know that NFS uses portmap!

# deny SSH service except for IP numbers in /etc/hosts.allow file
sshd: all

Restart your SSH service, and your server should now be a bit more secure against distributed dictionary attacks:

root# service sshd restart

An Internet search using keywords from the other mentioned solutions above will teach you how to change SSH port, disallow password authentication, etc.

worked in academia, corporate research labs and several technology startup companies prior to GORGES. His expertise is software architecture, database development, and system administration. Matt brings GORGES over 25 years experience developing fast and robust software on a multitude of platforms and languages.
©2012 GORGES - All rights reserved
where programming meets design and lives happily ever after