General Archives - Page 16 of 26 - {5} Setfive

I’ve worked with a number of start-ups and young companies over the years and one thing I’ve noticed is that it is quite common that a smaller company does not think much about their IT. They are not insuring that it is properly structured, safe, and reliable. The smaller companies can become so focused on their product/business that they forget to make sure their underlying infrastructure is solid. Companies place all their energies on their code and their code quality; however, often overlook equally important setups: such as, the servers that run the code. Here are some of tips I frequently give companies.

Where is your code?

Small companies are often focused on making sure that their product is bug free, or doesn’t crash in certain browsers, etc. However, if tomorrow their outsourced developer disappeared or their server crashed, they might not have access to their code. I recommend that companies keep a hard copy document stating how to recover the code, which is in turn backed up across multiple company computers in which multiple people have access.

Knowing how to recover the code without outside help is critical. If the outsourced development firm/developer disappears, there is a conflict, or any other reason they are unreachable or will not cooperate, it is important to be able to have access to the code. Far too often outside contractors disappear and I’ve seen companies stuck being unable to get their own code.

Making sure there is always access to the up-to-date codebase, will save the headaches later. Also, the current developer won’t be needed to ask for the code if you want another developer to work on it or do a code review.

Where is your database?

Similar to above, what happens if for any reason (server crash, hackers, an act of God, etc.) your production database disappears? Do you and your colleagues know where to recover the information?

Often data is the most valuable possession of your business. Being able to recover it is critical. If you can’t recover any of your data, it is very possible that will be the end of your company. How often should you back your data up? That depends on your business. Some companies a daily backup will be plenty, however for others such as companies which pay people to take surveys, losing a day of data could equate to tens of thousands of dollars lost. This is something you’d need to discuss with your colleagues.

Another important part of database backups is making sure that they are stored for long enough. If you only keep one backup which happens at midnight each night what happens in the following situation? At 11:59 PM one night your database is compromised and most of the data is corrupted. That night when your backup runs, it will erase all your data.

Nowadays, data storage is very cheap (under 9 cents per month per GB), so keeping backups for plenty of time is well worth it. At a bare minimum you should make sure that your database backups are kept long enough that you’d notice any problem with the data before the oldest backup is removed. For example, for a forum you may want to keep at least 2 weeks of database backups. If someone deletes data from your forums, you’d most likely notice it within 2 weeks and can recover it. Again, data storage is cheap so keep backups for plenty of extra time (or forever).

Server Configurations

Using the cloud? Your own private hardware? Either way, an often overlooked backup is the backup of how your servers run. Without a server to run your code and serve your data, the other two become insignificant. Keeping up to date backups of your server configurations are critical. You need to make sure that you can always recover a failed server.

I’ve seen several Amazon EC2 instances fail. With the failure, sometimes companies are left scrambling to figure out how to get their site or product back online. How long can your company afford to be offline? If over an hour is too long, make sure that you always have up to date server images that you can immediately boot.

If you don’t have any documentation of how your server is setup, it’s likely that when it crashes you may not be able to get back online quickly. It’s even more likely you’ll forget different settings that will continue to cause the product or site to not fully function correctly.

Aside from keeping a backup of your server configuration, having access to the server permissioned correctly is equally important. An example of what I’ve seen: A company hires a new contractor who they want to work on a development version of the product while the main developer works on a different feature. The contractor mistakenly runs the wrong command on the server and wipes out the entire site. This happens all too often and is narrowly avoided at other times. Making sure that different users only have access to specific environments (such as the development environment above) on the server is very important. Everyone should have their own logins to the server so that you can remove any user without requiring everyone to know the latest password. I also recommend always using SSH Keys, they make weak passwords irrelevant and the server more secure.

Have a Written Disaster Plan

I’ve listed out some key tips above for how to keep your business running properly. However, all these should be summarized in one document. The document should be backed up itself and accessible to multiple people in your company which you trust. If something happens to you, you don’t want it to ruin your entire company, so distribution of the disaster recovery plan is critical.

Making sure you understand the plan and that the plan is effective is equally important. At least once a month it makes sense to go through the plan, make sure it is up to date, that all the different parts are actually working (you aren’t backing up a blank database due to a typo), and doing the steps to do a recovery.

While planning for disaster, failure, and unforeseen events takes time, it will pay for itself when something goes wrong.

Have any questions? Shoot me an email with any questions!

Happy Movember all! This year some of us are participating in Movember. Movember is where you grow a moustache to support men’s health. Each week we’ll be taking a picture as our moustaches grow and are shaped into beautiful sculptures.

Our team page show’s some updates, how much we’ve raised, and who has joined our team. Join up with us or donate to the cause!

Here are the three mugshots of us who are participating (smiles not allowed) so far:

Here’s to a great Movember!

Since going live early this month, Healthcare.gov has been universally panned for being unstable, unusable, and close to an outright disaster. As the publicity of the problems have intensified, it’s become clear that the project has was mismanaged and probably sloppily developed. The team certainly faced daunting challenges like going from 0 to full capacity overnight but with a reported budget of over $50 million dollars and three years to execute it’s hard to have too much sympathy. Anyway, without knowing the project guidelines, business constraints, and other considerations it would be irresponsible to armchair quarterback and predict technical decisions that would have performed any better. However, on the non-technical side there are some strategic and architectural decisions that are disappointing.

The Team

Like any large project, the success of the project is ultimately driven by the strength of the team behind it. The experience, structure, and mindset of the team building the project will be the key drivers for what tradeoffs are made, how things are architected, and of course how development is executed. Unfortunately for us, according to the Washington Post, CGI Federal the company that built healthcare.gov is both a relative newcomer to US government IT consulting and also has a spotty track record of building large, commercial web applications.

I’ll be the first to admit that I have no background in government procurement, but it strikes me as odd that the Obama administration didn’t handpick the team that was going to build the software for their watershed legislation. Most notably, since the sweeping democratic win in 2008 has largely been attributed to the Obama campaign’s exceptional technology resources. Brad Feld actually suggested bringing in Harper Reed who served as the CTO of the campaign to fix the problems, but why wasn’t he leading the project from the outset?

Transparency (or lack thereof)

For an administration that campaigned on transparency (lets ignore NSA/drones), the lack of transparency surrounding healthcare.gov has been severely dissapointing. The lack of information has left media outlets reporting outlandish claims like that the site is 500 million lines of code or that Verizon has been brought in to help triage the situation. Apart from technical details, the White House has also remained completely silent on visitor and enrollment statistics even though they clearly have them since the site is running a slew of analytics and monitoring services. Leaving the public in the dark has driven rampant speculation and left everyone wondering “What if they aren’t releasing data because its THAT bad”.

Another area where healthcare.gov has been dissapointingly secretive is the actual source code of the project. Although some people, including Fred Wilson, are recommending open sourcing the code as a potential triage measure the code really should of been available from the outset. Even if the proprietary licensed technology had remained private, tax payer dollars financed the site and open sourcing it from the outset would have added some much needed oversight and accountability. Looking at the site, its using several open source libraries anyway including Twitter Bootstrap, jQuery, BackboneJS, and apparently violating the OSS license for jQuery.Datatables.

No Plan B

One of the accepted truths in software engineering is that shit is going to break and that bugs will crop up in even the most heavily tested applications. Mix in things like legacy integrations and 3rd party APIs and issues almost become a guarantee. Despite this, looking at the rollout of healthcare.gov it’s clear that the team had no contingency plans for how to handle various error scenerios. As pieces of the application started to fail, they didn’t have any way to mitigate poor user experiences, losing data, or simply showing “fail whale” style error messages. And although bad at launch, the situation still seems just as bad 3 weeks later – with their band aid to simply boot users once they’ve reached their concurrent session limit.

Building a high traffic web app that interfaces with legacy systems, is highly available, and is also easy to use is undoubtedly still difficult but the failures of healthcare.gov haven’t just been technological but procedural and organizational as well. Hopefully someone has the experience and political clout to right the ship before the website’s troubled launch defines the healthcare law it was built to implement.

On the East Coast, most of us woke up from a long weekend to news that Microsoft had purchased Nokia’s mobile hardware manufacturing business. The news didn’t exactly come as a shock, given that the companies had announced a particularly Microsoft friendly operating agreement where Nokia Lumina phones would ship with Windows. What did surprise me was the general skepticism and outright negativity surrounding the deal. From Fred Wilson to the several threads on Hacker News, it seemed like everyone was happy to discount this deal as DOA and go back to arguing about Android and iOS. Personally, I wouldn’t immediately count a combined Microsoft & Nokia team out of the mobile fight for a couple of key reasons.

Consumers are fickle and upgrade cycles are short

This point was brought up on Hacker News and I think it’s one of the key points surrounding this discussion. Consumer attitudes and loyalty surrounding consumer electronics have historically been fairly transient. Six years ago, the iPhone was just hitting store shelves and every teenager was clicking away on a Blackberry. Contrast that with today, where RIM is largely an afterthought and Apple is clearly the dominant player. Discounting that a combined Microsoft/Nokia team could make significant inroads

Along with volatile loyalties, consumer electronics, especially mobile phones have a short upgrade cycle. Compared to desktops or laptops, most American consumers predictable replace their cell phones every 2 years because of free carrier upgrades. Because of this, the mobile phone ecosystem has the potential to change and evolve at a much faster pace than it’s predecessors. This tight upgrade cycle benefits Microsoft/Nokia since it gives them the opportunity to iterate and improve devices much faster than say in the console market where Microsoft has previously used this strategy.

Developers care about install base but it isn’t the only thing

Several comments around the web today pointed to the staggering number of iOS and Android devices already in the wild and made the contention that it doesn’t even make sense for Microsoft to compete. Their primary contention was that since users select a mobile OS based on available apps and developers will only build apps for the biggest platforms there’s a vicious cycle of the less popular platforms not garnering developer attention or user adoption.

The absolute number of available devices is obviously important to developers but it isn’t the only thing they care about. Resource constrained startups are still often building iOS first or iOS only and even larger companies also sometimes focus primarily on their iOS builds. Reasons for this range from everything from the lack of device fragmentation to the engagement and willingness to spend of iOS users.

A combined Microsoft/Nokia should be able to control device fragmentation and also have the software engineering chops to create a best in class toolchain. Visual Studio is generally regarded as a fantastic IDE and if Microsoft can parlay it into creating a true “mobile first” IDE I think they’ll be able to attract developer talent. Another interesting angle is what approach Microsoft takes with HTML5/JS, especially “crossbuild” tools like PhoneGap and Titanium. Playing from third place would give the combined Microsoft/Nokia ample reason to support these crossbuild tools to get more apps onto Windows.

The Living Room and Facebook

It’s becoming clear that the “battle” for consumer living room’s is far from over. With the proliferation of InternetTV devices like the Roku and AppleTV to the announcement of next generation consoles, it’s clear that companies are still very interested in “owning” the living room. The lay of the land is also constantly changing as companies move throughout the value chain. So where does that leave Microsoft? Well its not clear. There’s clearly a lot of XBoxes in living rooms and they’re years away from having any unified mobile + living room experience but that could ultimately serve as a key differentiator and bargaining chip with content owners.

Facebook has always wanted deeper integration on mobile and their Android Home app only solidifies that fact. Microsoft and Facebook also share close ties, Microsoft was a large, pre-IPO investor and Bing is currently powering Facebook’s web search. Given this close relationship, it seems obvious that the two companies would work to tightly integrate Facebook into a phone that was developed in-house. The results could obviously go either way, but there’s no denying that social has helped drive mobile adoption in the past.

However, despite their combined potential the two companies are still facing frighteningly large challenges. With Balmer’s announced departure, the biggest one is certainly who is qualified and willing to lead such a large, multifaceted, corporation down a path that will certainly involve uncomfortable if not downright impossible choices. In any case, consumers and developers shouldn’t count Microsoft out just yet, if nothing else to prevent a Goolge/Apple duopoly in the mobile space.

I spend my days almost entirely developing in PHP and Javascript with the occasional trip to Bash. For the most part, the style of the code ends up looking mostly the same, object oriented PHP and a mix of OO and functional Javascript. Because of this, I’ve been researching a couple of new languages I’d be interested in testing out. Anyway, here is my list – I’d love any feedback or suggestions!

Scala

From Wikipedia:

Scala is an object-functional programming and scripting language for general software applications, statically typed, designed to concisely express solutions in an elegant, type-safe and lightweight (low ceremonial) manner. Scala includes full support for functional programming (including currying, pattern matching, algebraic data types, lazy evaluation, tail recursion, immutability, etc.). It cleans up what are often considered to have been poor design decisions in Java (e.g. type erasure, checked exceptions, the non-unified type system) and adds a number of other features designed to allow cleaner, more concise and more expressive code to be written.

So what makes Scala interesting? Personally, a couple of things stand out. First, the type system looks powerful while also being unobtrusive enough to not offend my dynamic sensibilities. I’ll butcher any explanation of how it works but this presenation does a much better job. Another interesting Scala feature is its rich support for functional programming techniques. I’m excited to try out things like currying and pattern mathing. The last Scala feature that is particularly appealing is that it can be run through the interpreter or compiled to a JAR. Because of this, it would facilitate writing simple “one off” scripts and running them through the interpreter.

Go

Go has been making the rounds on the blogosphere lately so naturally its piqued my interest. From Wikipedia:

Go aims to provide the efficiency of a statically typed compiled language with the ease of programming of a dynamic language. Other goals include:

Safety: Type-safe and memory-safe.

Intuitive concurrency by providing “goroutines” and channels to communicate between them.

Efficient garbage collection “with low enough overhead and no significant latency”.

High-speed compilation.

At face value, Go looks familiar and comfortable primarily because of its C inspired syntax and imperative style. The big ticket Go features that look the most interesting are concurrency support and its package and dependency management system. I haven’t written much (or any?) concurrent code and exploring Go’s “goroutines” seems like a great place to start. The official docs provide a great overview of the concurrency features Go exposes. Managing dependencies is painful and nothing is worse than getting stuck in dependency hell. Go has a unique approach to solving these issues, favoring convention over configuration. This post has a great rundown of why Go’s solution looks like a win.

Lua

From Wikipedia:

Lua , from Portuguese: lua meaning moon; explicitly not “LUA”) is a lightweight multi-paradigm programming language designed as a scripting language with “extensible semantics” as a primary goal. Lua is cross-platform since it is written in ISO C.[1] Lua has a relatively simple C API, thus “Lua is especially useful for providing end users with an easy way to program the behavior of a software product without getting too far into its innards.”

Functionally, Lua is a fully featured scripting language written in C which makes it a perfect candidate for embedding places where users need to be able to “script” the behavior of a program. Looking at Wikipedia, Lua has made its way into dozens of projects – including Nginx and Apache. From a language perspective, Lua looks “clean” and somewhat similar to Javascript but the most interesting feature is the possibility of embedding it into a host application. PHP also has out of the box functionality to support embedding Lua.

Anyway, that’s my list – I’d love to hear about any other languages worth checking out.

Category: General

Tips: Small Business IT Best Practices