Category Archives: Technology

Why an API can be a start-up’s greatest asset

Posted on by
Reply

With a project I was involved in last year, I had a unique chance to work with many Web startups and their APIs ecosystem. An API (or Application Programming Interface) is a set of rules that software engineers create to facilitate the interaction between systems. Most of the time, Web startups use it to provide other businesses and developers some access to their features and data (see Twitter’s API or Facebook’s OpenGraph protocol).

For many Web startups, building and maintaining an open API is a great way to develop relationships with customers, developers, partners and investors. Here is why.

  • It’s good for business development.
    Other startups are looking for features that could boost their value proposition without investing money and developer time in what is not mission-critical. An open API is the ideal opportunity to team up with partners operating in the same field. It can lead to interesting partnerships.
  • It will create a developer ecosystem around your product.
    Such an ecosystem can really boost the quality of your product. Software engineers working all day with your API will find issues with it. They will find bugs you never tough they could exist. They will also come up with recommendations. This is gold, and all for free.
  • Investors are going to want one.
    Simply because your partnerships and ecosystems will bring more value to your product and your business. Facebook wouldn’t be The Facebook without it’s OpenGraph protocol now.

Aside from business and strategic goals, “thinking API” improves the application’s design. In fact, a good API is :

  • Easy to learn, to use and to memorize.
    Your partners should be delighted to save time and energy with your API. It will make their life easier solving complex issues and delivering more value to their customers while focusing on their mission-critical features.
  • Hard to misuse.
    Software engineering is just like product engineering. Mistake-proof design can save you and your developers’ ecosystem lots of time. Well built APIs need little or no documentation to get started. The Yellow API (providing business data in Canada) is a good example of such an API.
  • Is powerful enough to do what is has to do (no more, no less).
    Jack of all trades, master of none. Do one thing and do it well.
  • Is appropriate for the audience.
    Your API is unlikely to have the same specifications and usage if you target small businesses owners or if you target specialized IT departments. Always keep in mind what your audience want and what is their level of knowledge. A very secure but hard to implement authentication system might be too complex to use for beginners while some experienced users might expect such a level of complexity and security enabled by default.

On the other hand, poorly designed APIs can be very dangerous. The fact is that once it’s out, it’s very hard to change it. The ecosystem will rely on it’s design and maintaining useless or resource-intensive features can be costly. You don’t want to end up sacrificing scarce developer energies on stuff that is not creating value in the end. You have only one chance to do it right.

There is no need to say, if some feature can be re-used with an existing API, it should not be recreated. Maintaining many parallel features or a too-fat API can take your focus away from core-business features and prevent you from creating added-value.

An API is a powerful technological asset but it can also be a great marketing tool. A well built API will definitely bring visibility to your business.

For more:

What Is Git

Posted on by
2

Git is a distributed revision control system (RCS). Git is open-source and focuses on speed. It was originally developed by Linus Torvalds for the Linux Kernel Project.

Revision control systems allow developers to keep track of the changes they make to their code. Before such systems existed, developers would keep backups of their files in case their changes would break something. In case it happened, they could easily revert to the previously working version.

Such systems are an essential part of any technology business. Without them, it would be very hard to release early and often, quickly revert buggy releases of software, etc.

What Is A Distributed Revision Control System

Decentralized revision control systems (like Git) allow developers to :

  1. Track changes to their code;
  2. Work in teams without having to fear overwriting someone else’s code;
  3. Work on a given project without needing a central server for hosting the code.

Other systems like CVS or Subversion (SVN) are centralized. This means that they require a main repository to exist. Each developer then checkouts a working version from this main repository, and commits back changes when they are complete. In a decentralized system, there is no main repository. Each developer has it’s own complete repository and changes are exchanged across developers.

How It Works

Conceptually, there are many ways to work with Git. This is what is beautiful with decentralized systems, they allow the team to choose what best suits their needs. Let’s explore two common methodologies :

  1. Every team member has a private and a public repository.
    In this case, each developer has it’s own private repository where he can freely change code, revert modifications, etc. When changes are ready to be shared with other developers (code is tested, compiles or parses and is believed to be bug-free) it is pushed to the developer’s public repository. The public repository is remotely accessible by other developers. The rest of the team can then pull the newly committed changes in their own private repositories. This way of working allows team members to easily add only the changes they want in their working versions.
  2. Every team member has a private and share one master repository.
    Again, each developer has it’s own environment for working, but instead of having one public repository for each, there is only one master repository which is remotely accessible. It makes it easier for changes to propagate to everyone (each team member has only one repository to pull changes from).

Making your repository available to your team

It is up to the team to decide where is the right place for hosting the remote repositories. Git can be remotely accessed from anywhere (HTTP, NFS, etc.). You can even share your repositories on Dropbox (something that was not possible with Subversion). There is also the famous GitHub.

What revision control tool do you use? Where and how do you share changes to your code? Feel free to add your methodology in the comments.

Support for OpenGraph Protocol META tags with Zend Framework’s HeadMeta

Posted on by
3

This is good news for all Zend Framework developers. Next release of 1.11 will allow us to set OpenGraph Protocol META tags right away from the HeadMeta view helper.

You can now do:

$this->headMeta()->setProperty('og:title', 'Title of this page');

Thanks to Marc Hodgins for this patch!

Note: To ensure your documents will validate, you need to use the XHTML1_RDFA document type. Read the HTML+RDFa 1.1 specification. Thanks to Roy Toledo who points out that this can be done with : $view->doctype(‘XHTML1_RDFA’);

View resolved issue ZF-9743.

Testing CloudFlare

Posted on by
1

Most people know what is CloudFlare and what they are doing because they presented the company at Tech Crunch Disrupt. Sadly I couldn’t watch the presentation live, but I saw all the hype that was on Twitter about this exciting product. CloudFlare enhances your site’s performance and security by taking over your DNS and rerouting incoming requests through it’s proxy, caching commonly requested pages, scripts or content and weeding out evil robots that could be scanning all your pages for vulnerabilities.

Setting up CloudFlare

CloudFlare is simple to setup. In fact, if your DNS zone is simple, the setup process will automatically detect all it needs without asking too many questions. For blogs or small websites, this rocks. But, if you have a complex DNS zone, do not forget to double check twice that all your DNS records are also listed in CloudFlare. To finish the setup, you need to change the name servers of your domain to the assigned CloudFlare name servers. Et hop! Your website is now faster than ever!

CloudFlare and Nagios/NRPE

If you really care about your website, you probably (or maybe your hosting provider does this for you) monitor your services, disk/cpu usage with Nagios/NRPE (or any other monitoring software). To prevent the monitoring server from monitoring through the proxy, CloudFlare will ask you to create “direct” sub-domains. Those entries will point to the same IP, but won’t pass through the proxy. If you don’t do that, your pager might get a call or two because CloudFlare’s proxy does not route NRPE traffic.

Support

Support is very important when it comes to this kind of service. Good news: even you are using the free service, they are fast. I’ve had my e-mails answered in 2-3 hours.

Conclusion

CloudFlare is really giving what small websites need to enhance page loadings and prevent bad things from happening without installing your own reverse proxy and intrusion detection system. This is HUGE. But in the end, you are giving up control on your DNS and (almost) all traffic to your website. Risky. What do you think? Have you tried it yet?

Subversion Best Practices: Tags, Branches and Merging

Posted on by
1

Matt Wood shared on SlideShare a short presentation of what would be Subversion Best Practices. Here are a few of them:

  1. Repositories need to be kept as simple as possible. Projects should be separated from each other.
  2. Use tags. Tags meant to give symbolic names to a group of files like snapshots.
  3. Use branches. Branches provide space to experiment (easily contain parallel changes without breaking production code). They are a good way to generate releases.
  4. Each release is a branch.

Happy merging.

Here is the presentation:

empty and ArrayObject

Posted on by
Reply

Many PHP programmers make extended use of ArrayObject. Extending the ArrayObject class allows developers to create objects that behave like traditional arrays in PHP, which is very useful. A frequent problem with those objects, is that when using the empty construct on inaccessible properties, it will call the __isset overloading method. So, if your property is empty but exists, empty will return true.

An easy workaround is assigning your property to another variable, then calling empty on your variable.

Know a better workaround? Feel free to add it in the comments.

Friendly URLs and User Generated Content (UGC)

Posted on by
1

If your website allows users to create content, you will likely want to equip the content’s URL with the name or title of that content. The classic example, a blog post, would have an URL like this one: http://example.com/blog/1234/title-of-the-post

As the SEO experts will explain you, having good keywords or content titles in the URL should increase the odds that your page is displayed to search engine users first. Also, friendly-URLs are more easy to remember, to type and they look great.

The most common problem with UGC is data filtering and normalization. You will want all of your URLs to have URL-friendly characters only so you do not generate broken links. This block of PHP code strips all unwanted characters and builds a clean content “name” that can be used in your URLs.

// Strip accents
$name = str_replace(
    array('à', 'á', 'â', 'ã', 'ä', 'ç', 'è', 'é', 'ê', 'ë', 'ì', 'í', 'î',
          'ï', 'ñ', 'ò', 'ó', 'ô', 'õ', 'ö', 'ù', 'ú', 'û', 'ü', 'ý', 'ÿ',
          'À', 'Á', 'Â', 'Ã', 'Ä', 'Ç', 'È', 'É', 'Ê', 'Ë', 'Ì', 'Í', 'Î',
          'Ï', 'Ñ', 'Ò', 'Ó', 'Ô', 'Õ', 'Ö', 'Ù', 'Ú', 'Û', 'Ü', 'Ý'),
    array('a', 'a', 'a', 'a', 'a', 'c', 'e', 'e', 'e', 'e', 'i', 'i', 'i',
          'i', 'n', 'o', 'o', 'o', 'o', 'o', 'u', 'u', 'u', 'u', 'y', 'y',
          'A', 'A', 'A', 'A', 'A', 'C', 'E', 'E', 'E', 'E', 'I', 'I', 'I',
          'I', 'N', 'O', 'O', 'O', 'O', 'O', 'U', 'U', 'U', 'U', 'Y'),
    $name
);

// Replaces all but alphanumeric characters, underscores and dashes.
$name = preg_replace('/[^\w\d\s_-]+/', '', $name);

// Trim the white space at the start and at the end of the string.
$name = trim($name);

// Replace whitespace with dashes.
$name = str_replace(' ', '-', $name);

// Repleace double dashes with single dashes.
while(strpos($name, '--') !== false)
{
    $name = str_replace('--', '-', $name);
}

// Lowercase all characters.
$name = strtolower($name);

// URL Encode the string.
$name = urlencode($name);

You think this could have been done in a better way? Feel free to add your idea in the comments.

CloudCamp Montreal

Posted on by
7

Last Friday, I’ve attended the first CloudCamp event here in Montreal. Being more experienced in traditional systems and services administration, I was very intrigued about what would be the main interests and concerns of the Cloud’s early adopters. But first, to get there, we first need to agree on what is Cloud Computing.

The Definition of Cloud Computing

The NIST (National Institute of Standards and Technology) came out with a very good definition (original document can be found here):

“Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability [...]“

Simply put, the five essential caracteristics of a Cloud are:

  • On-demand self-service;
  • Broad network access;
  • Resources pooling;
  • Rapid elasticity;
  • Measured service.

Security concerns

The main question business owners should ask themselves when they switch to the cloud is “how much money will I loose if this thing goes down?” (because, yes, it could). While the technologies put in place by major Cloud Computing providers is very good, switching is always a trade between flexibility and control. Before going cloud, a few questions should be asked:

  • Will my system be secure?
  • Will my system be fast and available? (enough bandwidth for your needs?)
  • Does my system requires specific customizations the provider won’t support?

In business context, this should always be viewed more from a business perspective more than a tech-trends perspective. Those risks can be calculated.

There are also many legal issues. Remember that your data can be stored anywhere in the World and the ability to define where you want it to be hosted is not supported by all providers. For instance, if your data is stored in the US, it is subject to the Patriot Act.

Conclusion

The conversation about security was obviously the main topic of the event. Environment (power consumption, cooling, etc.), application development and management (systems, people, etc.) could have been more discussed. Hope that by next year, most of those security concerns will have been solved by robust and proven solutions so we can dive into other very interesting subjects.

As a side note, Nicolas Roberge posted on his blog cool pictures of the event.