Recent blog posts…

Problems upgrading your iPhone to iOS4 ?

Posted by Andrew, 22nd June 2010. Share this:

• ios4
• ipad
• iphone
• iphone backup extractor

We've recently become aware that a number of people are experiencing problems upgrading their iPhones to the latest iOS 4 software. Problems range from the upgrade process appearing to stall, to some users reporting partial or total data loss.

If you are one of those unlucky enough to encounter problems, we suggest you read the following suggestions and advice.

Firstly, if you suspect you have lost data, do NOT sync your iPhone with iTunes just yet. If you do, you run the risk that iTunes will overwrite any previous backup files you may have with fresh backups, which will no longer contain your missing data. Instead, browse to your iTunes backup folder and take a copy of any files or folders you may find there and save them into a completely separate location.

Under OS X, iTunes will store backups in /Users/USERNAME/Library/Application Support/MobileSync/Backup.

Under Windows XP, iTunes will store backups in /Documents and Settings/USERNAME/Application Data/Apple Computer/MobileSync/Backup.

Under Windows Vista and Windows 7, iTunes will store backups in /Users/USERNAME/AppData/Roaming/Apple Computer/MobileSync/Backup.

Secondly, try restoring your iPhone. This seems to have resolved many issues, albeit not all of them. As mentioned above, make sure you've copied any iTunes backup files to a safe location before you try this.

Thirdly, if the restore didn't work or you are still missing data, download and run the iPhone Backup Extractor. The free version will allow you to locate and restore individual files from within an iPhone or iPad backup file - just point it at the backup files you copied to a safe place in the first step (you did take a copy, didn't you?!).

If you want to know more about the iPhone Backup Extractor, visit our website at http://www.iphonebackupextractor.com

This post has 0 comments »

Which language should my startup use?

Posted by Aidan, 20th January 2010. Share this:

• .net
• c#
• development
• django
• java
• language
• php
• software

We're often asked by entrepreneurs which language their startups should adopt when developing their technology. Attending events around London, or talking with some of the development agencies present at the events, one might hear a startling set of opinions. PHP is insecure? Ruby on Rails doesn't scale? It can be difficult -- without experience building software -- to make an informed choice which is most suitable. Technology enthusiasts tend to get tangled up in enthusiasm for their chosen platforms, so we'd like to provide an objective summary.

But wait

Not all startups are alike. Some are more technical, or more mature than others. Whilst this guidance should be of interest to technical startups, if they have capable senior staff they should be able to get this from them. Businesses with more complex needs or pressures may use multi-platform solutions. In particular, they may use service oriented architecture, or SoA. This can be used to spread some of the platform risk a business might face.

What to avoid

Fortunately for entrepreneurs, there are only a few technology language choices that are likely to be fundamentally "wrong". ASP (or Visual Basic) does not have a justifiable use, other than by companies needing to service existing ASP technology. Microsoft replaced ASP with the .NET platform more than five years ago, and even at the height of its popularity ASP was wholly inadequate. ColdFusion, one of the few languages to have an "is this language dead?" page, can -- despite the occasional new release from Adobe -- be considered a dead language, with all that this entails (difficulty finding and retaining good developers, vendor lock-in, horrendous cost, poor support, porting nightmares, infrastructure constraints). ColdFusion occupied a niche for rapid web development since the late '90s, and its legacy consists of around ten very vocal agencies and developers, some of whom are moving slowly to .NET.

Languages like Tcl -- which powered Vignette's CMS products in the dotcom heyday -- are now rather unusual in web development. They're not entirely without use or benefit, but like Lisp, Flash or Silverlight, they're often not the best choice. There's nothing inherently wrong with Flash or Silverlight, but most often their use should be considered only for incremental interface enhancements to a system built on an establish web framework.

It's worth noting that technically capable startups may use esoteric languages with a great deal of success. 37signals repopularised Ruby this way, and last.fm have been beavering away with Haskell. These languages work well for the companies because they are solidly technical, and are able to kickstart their own frameworks or adapt other projects. Many startups do not have this luxury, and although they've been very successful, 37signal's David Heinemeier Hansson was quite indulgent and not at all risk averse in choosing to single-handedly reinvent a language.

Language doesn't matter

Complex web applications can be built in just about any programming language, and it's not really the language that is so important as the frameworks that are available. Despite what some vendors may say, all languages scale, and it's hard to argue that one language is fundamentally less secure than another. One can, however, make these arguments about different frameworks. Development frameworks are toolkits to guide developers in building particular pieces of software. Critically, they provide implicit (and sometimes explicit) structure to what the developers are developing, and will allow the team to use pre-built blocks of functionality. No company, in any industry, should be building functionality without recourse to significant chunks of other peoples' frameworks. (The common argument used to be "this isn't rocket science, it's likely someone's already built at least part of what we're doing before". However, nowadays even the rocket scientists at NASA are using external frameworks.)

But frameworks really do matter

Above all, in order to make an informed choice of platform, consideration must be made as to the framework. Why would one chose to develop with a particular framework over any other? Consider these eight areas:

1. Cost of development (rates, productivity, time cost to recruit & availability)
2. Platform cost (& total cost of ownership, or TCO, including hosting, support, licensing, cost of requirements)
3. Quality of developers (& barrier to entry)
4. Maturity (& continued maintenance)
5. Similar business use
6. Suitability for web (& your domain)
7. Support & documentation (don't forget release cycles and open vs. proprietary, RTFM = STFW?)
8. Ease of integration & adaptability (SoA, other components & processes)

There are five or so fairly common languages that startup companies might use to address their needs. These are Java (from Sun), .NET (from Microsoft), and three Open Source options: PHP, Python and Ruby. We’ve tried to convey a flavour for each language as concisely as possible.

Java stands alone from the four others. It -- along with Perl, ASP and a host of proprietary platforms -- powered many of the enterprise sites of the late nineties and around the turn of the century. It's a powerful object oriented language, and is effectively Open Source. Java can be used in both Microsoft or Open Source environments. As it presents a relatively high barrier to entry in terms of technical complexity, Java developers tend to be more capable (and expensive) than many developers who use simpler scripting languages. However, Java is not a particularly productive language to work with, and many elements of functionality can be delivered more rapidly in the other languages. Java developers pioneered some of the best early web frameworks and tools: J2EE, Spring, Eclipse, Hibernate, Ant, Struts, Tomcat. Java has a fair amount of syntax in common in common with some of the .NET languages which were designed by Microsoft to counter Java's success. Java is a great language for enterprises and is commonly used by many big dotcoms, banks and airlines, but its relatively slow development pace and higher barrier to entry make it inappropriate for most early-stage businesses.

PHP is a widely-used Open Source web scripting language. Many small to medium size sites use it, alongside a few massive ones such as Facebook. Of the languages considered here, PHP has the lowest barrier to entry, which has some big drawbacks. First of all, PHP powers a number of content management systems (CMS) – such as Joomla! and Drupal – which are often confused for frameworks. It’s possible to get very simple sites up and running very quickly with CMSes, but often businesses can get caught up trying to extend them. Having a site built on a CMS platform may make sense for the first iteration, but beware of falling into trying to upgrade the modified CMS to support a complex site. It won’t, or at least, it won’t work well and be a robust, fast and high-quality solution. (This isn’t to say PHP doesn’t have frameworks – it has many, from Symfony, CakePHP and Zend to a host of others.) Secondly, the ease of use of the language means that many of the programmers and agencies available are, at best, hopeless. PHP programmers are often unfairly stigmatised by colleagues who work with more complex languages, and whilst there are some excellent ones out there, many more are poor. Grand Master Programmer theory states that around 1 in 20 (or 5%) of programmers are super programmers, and in “easy” languages this number is even lower. Hiring a good team of PHP developers is neither likely nor easy for the non-technical. A team of poor developers won’t just take longer to deliver a solution: they’ll build something which is insecure and complex, and subsequent modifications will become increasingly costly with time.

The .NET framework is a set of proprietary languages (most prominently C#, VisualBasic.NET and ASP.NET) developed by Microsoft. Microsoft made a half-hearted attempt to “open” the languages by publishing an ECMA standards document, and there is an Open Source implementation (Mono) available, but for the most part development with .NET requires use of Microsoft operating systems and licenses. This isn’t a discussion of the merits of Closed vs. Open Source, but it’s worth noting that each Microsoft server costs around $1,000 to license, and their database software costs between £2,000 - £16,000 per CPU (most servers have two to four) to license. These are usually insignificant amounts once a business is proven but can seriously eat into seed or first round capital. (Microsoft have a Bizspark programme to provide these products freely for the first three years of a startup’s life.) The .NET languages, and particularly VisualBasic and ASP.NET have a barrier to entry only slightly higher than that of PHP. That, and the fact that they represent “point and click computing” have resulted in an industry segment full of sub-par programmers. Like PHP, when hiring Microsoft programmers there’s much to be wary of. .NET powers sites of all sizes (though relatively few massive ones) and is very common. .NET has some CMS frameworks such as dotnetnuke and Community Server which often distract startups. Most startups don't have "legacy applications" to deal with, but .NET can be particularly easy to integrate with older Windows applications and services, and is an easier migration choice for older "Microsoft" code. Reincubate have been called in to rescue twice as many project disasters on .NET than any other platform.

Ruby on Rails is a combination of framework and language, with Ruby being the language and Rails being the framework. Ruby was considered a dead language to all but some system administrators when it was revived in 2003 by 37signals to develop their award-winning productivity startup Basecamp, and then taken on to power Twitter. Their lead developer built the first parts of the Rails framework before throwing it open to the Open Source community for further work, and in doing so the first true Web 2.0 framework was built. With a mid-level barrier to entry and a fan-base of intelligent, capable, multi-skilled developers, Rails represents an excellent choice for a startup. The project is mature enough and well documented enough to have attracted developers seeking refuge from other, more tiresome languages. Some purists consider it a joy to program in, and anecdotally it appears to be the platform of choice for many of the hot American companies on TechCrunch. Rails is a web framework at heart, and is less suitable for non-web projects. Being so fashionable, there are many developers both on and off-shore (increasing rapidly) but finding available resource can sometimes be tricky.

Finally, Python’s Django framework has catapulted it into a serious contender to web development. Python is an Open Source language (with a philosophy behind it) long-beloved by Object Orientation enthusiasts, system administrators and Google, and has had a number of different web frameworks – like Zope – before. However, it’s only really with the appearance of Django over the last few years that it’s been more widely used by start-ups. Describing itself as a framework "for perfectionists with deadlines", Django is comparable only to Rails in its tight focus on delivering functionality very quickly for Web 2.0 web applications. Whilst technically there are some interesting differentiators between Django and Rails, there are only a few key differences worth considering. Django is much newer and has a more immature codebase. This means there’s far less supporting documentation, far fewer experienced developers, and is more likely to change as it gets away from version one. Such is its impressiveness, however, that Google released Django as the first supported language on their App Engine cloud computing platform, and a number of Rails developers are starting to transition over. Central to Django are the principles or DRY (“Don’t repeat yourself”) and Python’s lack of TIMTOWTDI (“there more than one way to do it”), with a medium barrier to entry, these help less experienced developers get it right -- the first time around -- in a way which PHP frameworks cannot.

At a glance

Being one of the few expert companies assisting early start companies with their technology strategy and platform, we’re particularly well exposed to platform disasters through the rescue projects we’ve embarked on. In fairness, early-stage business failure caused solely by language or platform choice is rare, but it's often a significant contributory factor.

From what we see, one of the biggest technology risks is where companies take on agencies or developers who have built their own, idiosyncratic frameworks, and we see these tripping up companies time and time again. Seed money gets invested on something that shouldn’t be in use, rather than something provided by an off-the-shelf framework which won’t tie the business to a particular agency. We’ve written previously on the other technical challenges start-ups will face when working with agencies or developers.

• The good: Python (Django), Ruby on Rails
• The bad (or less good): Java (also J2EE, JSP), .NET (includes C#, VB.NET, ASP.NET), PHP
• The ugly: ASP (also Visual Basic), ColdFusion, Flash, Silverlight Lisp, Tcl, Perl, any framework built and provided by a development agency, even if they say it’s “open source”

We value our independence and do not endorse any agencies or developers. However, we will publish a short round up of resources and guideline rates in a follow-up to this article.

A guiding principle

It is impossible to give general advice on which languages are better than others, and this post makes a number of generalisations. An expert in a particular language or framework will usually be more productive than a non-expert in another language. Whatever the choice, it's important that the experts aren't using the platform in an idiosyncratic manner.

It never hurts to focus on simplicity. A business should own as little technology as is suitable to fulfil its strategy. This should translate to every variable one can use to measure technology: number of servers, number of licenses, lines of code owned, technical staff. The less a business owns, the easier it is to change and grow. Other considerations aside, the framework that's most suitable for expressing the business' logic as simply as possible is often the right choice.

This post has 2 comments »

Launch48 last weekend

Posted by Andrew, 19th October 2009. Share this:

• launch48
• protectedcc
• security
• startup
• weekend

Phew! What a weekend.

Launch48 is a fascinating concept. What would happen if you got together a room full of creative people, got them all to suggest ideas, picked six of the best and then spent 48 hours developing them into a viable business? And, of course, fuel the process with beer and coffee.

Head over to the Launch48 website to find out the answer...

Reincubate have supported launch48 from its inception. Aidan has been a mentor at both Launch48 weekends. Andrew lead the team for protected.cc, after his idea was chosen as one of the six finalists this weekend just gone by. And TechCrunch gave us a lovely write-up - thanks Mike!

This post has 0 comments »

Delisted from Google? Fix it quickly...

Posted by Aidan, 6th October 2009. Share this:

• google
• seo
• web optimisation

We've been rather quiet the last month, hands full with a number of prototyping projects, a redesign, work on one of our own products and a startup launch. Despite that, we found time to get involved with a few other dramas.

Whilst we're no SEO experts, we'd remarked to one of our clients about some parts of their site, suggesting that they might fall foul of some of Google's natural search guidelines. Their SEO agency was duly brought in and questioned, and reassured our client that keyword stuffing was fair game and unlikely to lead to problems.

What a surprise then, that within the month we got a panicked call from the CEO. Google had sent him a short note through Google Webmaster, banned the site from their search index, and in a stroke killed off a good £30,000 per day worth of site's traffic. It read:

Dear site owner or webmaster of ourclient's.com,

While we were indexing your webpages, we detected that some of your pages were using techniques that are outside our quality guidelines, which can be found here: http://www.google.com/support/webmasters/bin/answer.py?answer=35769&hl=en.

Specifically, we detected keyword stuffing on your site. For example at http://www. ourclient's.com/guilty we found:

Blatant keyword stuffing

For more information about what keyword stuffing is, visit http://www.google.com/support/webmasters/bin/answer.py?answer=66358&hl=en.

In order to preserve the quality of our search engine, pages from ourclient's.com are scheduled to be removed temporarily from our search results for at least 30 days.

We would prefer to keep your pages in Google's index. If you wish to be reconsidered, please correct or remove all pages (may not be limited to the examples provided) that are outside our quality guidelines. When such changes have been made, please visit https://www.google.com/webmasters/tools/reconsideration?hl=en to learn more and submit your site for reconsideration.

Sincerely, Google Search Quality Team

Note: if you have an account in Google's Webmaster Tools, you can verify the authenticity of this message by logging into https://www.google.com/webmasters/tools/siteoverview?hl=en and going to the Message Center.

30 days? That was nearly £1M in revenue to our client. There's not a lot of information online on what do to in the event of a delisting. We got in touch with a pair of SEO companies that we'd worked with before, but neither of them had had to deal with a delisting.

In the very short term, we pushed up PPC activity to cover the shortfall from SEO / natural search. It appears that only repeat offenders might have their PPC affected by delisting, and our client had never been in trouble before.

Noticing that the GoogleBot was still crawling the site heavily, we got our client's developers to do an immediate take-down of the offending content, made sure the Google Webmaster account was in order, and submitted a very simple reinclusion request. We cut the out the fluff and made it as brief as possible. On behalf of the client we established in as few words as possible the key things: 1. they're sorry, 2. it was fixed immediately, 3. it won't happen again, and 4. thanks.

Would you know it, but they were back in the search results by the next morning. We have a few tips for working with SEO agencies:

Working with an SEO agency can feel like an unnecessary expense, and often it is. Getting advice from a third party can help keep your agency in check. Even better, getting other agencies to pitch for the business and critique the current agency's performance is a good way to keep them on their toes. This requires not signing any long contracts with your agency (you shouldn't, anyway), and should prevent what usually happens: the agency assigning you some of their sharper staff for the first four months, and then doing little else for their fees for the rest of the time.

Where possible, pay based on performance and ensure that -- right from the start -- you have a strong framework by which to assess and compare performance. Don't tolerate meaningless reports, or irrelevant data: the agency need to be conversant in the conversions or goals that are most important to you. If you end up repeating yourself it's time to find a new agency.

Don't be afraid of switching. In our experience, the vast majority -- big and small -- perform poorly. Larger agencies find it hard to recruit and retain strong staff, as they have little incentive not to start their own agencies, or move out of what is quite monotonous work. Smaller agencies are often fly-by-nights, although their killer staff, working all hours that can really make the most positive difference. However, just like development agencies, as their companies grow they'll experience growing pains which can sorely effect their clients.

Be prepared for your developers to conflict with your SEO agency. Quite reasonably, the agency will be held back most by the speed with which your team can change the site to suit them, unless you're able to give the agency control access to alter the site. The agency, being under pressure from you, will invariable apply that pressure to the developers, and resentment will build. This needs careful management.

If you don't manage PPC internally, keeping it separate from SEO can be a good idea. If you sack your agency for mismanaging one or the other, you'll have less to worry about. Also, most agencies usually do both, so your PPC agency can often give you tips on where the SEO team can improve, and vica versa.

Keep a careful eye on any work labelled "link-building" or "directory submission". It's important to know your site is being linked to from, and submission to inappropriate sites or membership of link-swapping schemes is another way to get delisted by Google.

Use agencies wisely. An SEO agency can really help if your team isn't up to scratch with search engine optimisation, or if you're making major alterations to the site. If the site is well-established and your team knows what they're doing, an agency might not be the most effective way to drive performance.

Finally, if you have a real challenge, contact us. We love rescues.

This post has 1 comments »

Apache with Django and mod_wsgi

Posted by Aidan, 30th August 2009. Share this:

• apache
• django
• mod_wsgi

It's been a busy August for us, working on a number of new and existing projects, and a series of investor code reviews. We plan to start publicising one project in particular soon, helping people with their day-to-day management of IT. We put together a short survey which readers may be interested to complete if they have five minutes.

As usual, most of the development work we're doing at the moment is in Django, and we've recently switched to using mod_wsgi. In putting together our Apache and wsgi configuration, we found that neither mod_wsgi's nor Django's wsgi installation instructions contained a truly portable configuration include. We came up with the script below. It's far from perfect but it does the job for now:

# Assumes this is in the project root, parallel to settings.py, etc.
# We'd typically have our 'docroot' folder one level down for security reasons.
import os, sys, django.core.handlers.wsgi

project = os.path.dirname(__file__)
workspace = os.path.dirname( project )

sys.path.append( project )
sys.path.append( workspace )

os.environ['DJANGO_SETTINGS_MODULE'] = '%s.settings' % project.rpartition( '/' )[2]
application = django.core.handlers.wsgi.WSGIHandler()

Happy hacking!

This post has 0 comments »