Blog
Why Firefly Requires an SLA to Support Outside Hosts
by Jeremy Usher, Co-Founder, President
Occasionally a client will ask us why Firefly charges more to work with third-party web hosts than we do to physically host applications internally. Because many factors are at play, we have put together a brief post describing a few of the more important ideas.
Firefly specializes in high quality, enterprise level hosting. Our hosting clients include state government, school districts, colleges, municipalities and multinational corporations. We utilize only the best Tier III or better datacenters in the US and Western Europe - guaranteeing geographic redundancy, biometric access, 24 hour armed security, redundant access to major carriers, backup generators and more. Firefly's applications are monitored around the clock for performance and threat mitigation. Meanwhile, complete backups of sites are synced offsite to Amazon S3 each week so that all materials can be retrieved and restored to any location in the event natural disaster or other calamity. Since our incorporation 10 years ago, Firefly has never lost a single client because they were unhappy with our hosting. Furthermore, because clients always have complete access to their site and materials, they are always free to migrate materials elsewhere if they ever desired to do so.
Virtually all Firefly clients host on Firefly's affordable, powerful and secure infrastructure, but for those requiring an outside presence for any reason, Firefly requires a minimum $1,200 / year Service Level Agreement (SLA) to cover the time needed to handle third-party environments.
There are many reasons that working with outside hosts requires extra time and effort and so necessitates a separate contract governing systems administration and support. A few examples are below.
Introducing Gitdown - A Markdown/Pygments Class for PHP
by Jeremy Usher, Co-Founder, President
One of the things missing from PHP is a syntax highlighter as good as Python's Pygments. Enter Github, which renders beautiful, extended Markdown along with Pygmented code - and they expose it through a simple API! So here you have it kids - beautify your Markdown with one line:
$html = Gitdown::pretty($markdown);
Interested in just the CSS they use on Github? We've figured that one out, too.
Jump to EOL with SublimeText
by Jeremy Usher, Co-Founder, President
Using SublimeText for your dev? If you find the right arrow key maddeningly far away, and you want to jump to the end of your current line, enter the following into your user key bindings:
{ "keys": ["super+j"], "command": "move_to", "args": {"to": "eol", "extend": false} }
Your hand is always on the "J," and EOL is far more important than the default "Joining Lines" operation.
Compressing Serialized Objects in GET Parameters
by Jeremy Usher, Co-Founder, President
Many web applications face the common problem of parsing GET parameters to render a page. Most often, those parameters drive some sort of database operation that delivers the correct records or view; a process that might include pagination, searching, sorting or programmatic transformations of one kind or another. Regardless of whether you are using tools like Doctrine, ActiveRecord or the like to simplify and standardize this access, there is inevitably a step of sifting through parameters, sanitizing them, and structuring them to be compatible with the programming language that is ultimately responsible for the real maneuvering. It's a little like the object relational impedance mismatch applied to the structure of the Web vs. the structure of applications. If you have one or two parameters this is of little consequence, but sometimes it is useful to maintain more complete and structured information.