SEO for Web Developers

When it comes to achieving sustainable SEO results the work of the web developer plays a major role in a campaigns success or failure. So much so that 2 of the 3 “On Page SEO” columns in the Periodic Table of SEO Ranking Factors, HTML and Architecture, rely solely on the work of our web developers. Preventing violations like cloaking and hiding words by using the same or nearly the same text colour and body background could be blamed on developers and designers who do not know enough about what works or doesn’t when it comes to SEO. The following post highlights 1112 SEO guidelines every web developer should know and try to adhere to.

1. Product Owners should assign SEO stories to each sprint.

Whether you like it or not visitors referred to your web application by search engines can be anything from one third to somewhere near 80% of all your traffic. If you are building anything that will be publicly available on the web- search engines, or rather their bots, should also be considered as a user. “How will search engines react to any change we make to our site?” should be asked when planning your Agile sprints therefore adding it as a user story will be beneficial.

2. Give SEO tasks higher priority in the Product Backlog

In most cases an SEO or agency’s expertise is consulted when the powers-that-be realize they need a boost in their rankings. The great thing about search marketing is that it’s never too late to provide assistance in increasing search engine traffic. Your engagement with an SEO usually results in an audit in which many tweaks and changes are suggested. From personal experience those tasks are assigned to somewhere near the bottom of the product backlog or don’t make it to the product backlog at all.

3. Page Speed – Make Your Code Harder Better Faster

Not only does the speed of you site have a positive effect on decreasing bounce rate, improving page views, and a higher conversion rate. The speed of you page is a factor in search engine algorithms too. I’d suggest reading Google’s Distinguished Engineer, Matt Cutts’ post. If you need more convincing that site speed effects the bottom line read Alistair Croll’s detailed article. Their are various add-ons plugins available for Firefox and Chrome that can assist web developers at improving page speed. Web Developers should take Daft Punk’s lyrics to heart…

Work It Harder Make It Better
Do It Faster, Makes Us stronger
More Than Ever Hour After
Our Work Is Never Over

Google have also released a web-based page speed testing tool. The easiest way to find out how to improve you site’s speed is to enter the URL, click analyze and follow the guidelines.

4. The URL’s impact on SEO

When it comes to SEO all URLs are not created equal. URLs should be constructed for users first, search engines second. A personal rule I like using is to keep the URL as close to the root directory as possible i.e do/no/put/folders/in/the/URL/if/it/is/not/needed. Rather use hyphens (-) as separators between words or numbers. Even though the underscore performs a similar function to the dash, works as a keyword separator in a URL, it requires an additional keystroke when typing _. There are still some people who believe people use the URL structure when browsing a website but have you ever witnessed the practice of navigation by URL structure recently? If you plan to change ensure the proper redirects are in place. This brings us to the next point…

5. Getting Redirections Right for SEO

You’re about to change the URL structure of your pages and would like to retain the traffic those pages are receiving via search engines. We’ve known for over a decade that links are vital when is comes to rankings in the SERPs and those URls you are planning to change may also may have vital links pointing to them from external sites which are sometimes impossible or time consuming to request other webmasters to update. Have no fear, the 301 redirect is here. Of all the redirect codes the 301 redirect is the most important one to know. This will alert search engines to the new location of a page(s) and pass almost all it’s link juice (ranking power). SEOmoz has a detailed guide to redirection using an Apache Web Server. When redirecting pages or folders on IIS do not forget to select “A permanent redirection for this resource”. If you require a guide to 301 redirect for PHP, ASP(.net), Coldfusion, JSP/Java, Perl or Ruby-on-Rails follow these guidelines.

6. Duplicate Content Mitigation & Parameter Handling

Duplication of content occurs on the web when various pages (URLs) contains the same or very similar content. The problem with having more than one piece of identical content on the Internet is that it’s difficult for search engines to decide which version is more relevant to a given search query. To provide the best search experience, search engines will rarely show multiple, duplicate pieces of content and thus, are forced to choose which version is most likely to be the original (or best). To assist in preventing duplicate content issues which may negatively impact your SEO efforts the rel canonical tag was introduced. The rel canonical tag is vital for ecommerce stores which allow users to toggle the order in which the products are displayed (order by price or alphabetically). In most cases the same URL with additional query parameters are created to order/sort products. The canonical tag will prevent duplicate content issues in this case. Another instance where you wouldn’t want to confuse search engines is when paginating pages with hundreds of products listed or archived content. Google advises you not to use the rel canonical tag in this case but rather another rel tag called rel prev an rel next.

7. Get to Know & Give Robots.txt a Go

The Robot Exclusion Standard, also known as the Robots Exclusion Protocol or robots.txt protocol, is a convention to prevent cooperating web crawlers and other web robots from accessing all or part of a website which is otherwise publicly viewable. Beware of blocking pages that should be indexed when using robotx.txt there is also a robots meta tag. The robots.txt or tag can be your best friend when implemented correctly or worst enemy if not This site dedicated to the Robots Exclusion Standard is a great place to start learning all you need to know.

8. Give Images Descriptive File Names

Digital cameras and mobile phones have the naming conventions that make no sense to us or search engine spiders. Instead of uploading an image as DSC00786.jpg rename it to something descriptive that give like may-the-force-be-with-you.jpg instead, if you were displaying an image of Yoda

9. Do not hide content within Javascript or Flash

JQuery is used almost everywhere online these days which isn’t bad as it improves the user experience in most cases where content on a page can be changed on the fly. Search Engines may not see the content you wrap within Javasrcipt or Flash even though progress has been made by them to better read and understand them. This is where the <noscript> tag comes into play. When using Javascript or Flash be sure to also include the content you want indexed by search engines between <noscript> and </noscript>. A word of warning though, be sure that the content within Flash/Javascript is identical/similar. We do not want to violate their guidelines with keyword stuffing, cloaking or excessive link manipulation within the noscript tags.

10. SEO’s Future is Semantic

Seen those enhanced search results with movie ratings, personal information, product prices etc.. Google calls them rich snippets. The only way to enhance your site’s SERPs is providing semantically marked-up data. At SMX Advanced 2011 a new standard adopted by the Bing, Yahoo and Google was introduced called Schema.org. Utilizing schema.org may not be a major ranking factor right now but it certainly will be in the near future. The best advice I can give any developer who wants to build a web app that will perform well when it comes to search engines rankings and attracting traffic is that you have to learn and implement schema.org as soon as you can.

11. Social, Social, Social

Facebook, Twitter, Google+ and the thousands of other Social Media platforms your target market use helps your SEO efforts too. Don’t go out and spam the various Social Networks with messages that are not targeted/solicited. Rather provide the tools and widgets that allow users to easily share your content with their networks. Which networks you choose will depend on who your target audience is. In this article’s case of we allow you to tweet, +1 or Like on Facebook. If you’ve found any value in this article feel free to share it

12. How To Ensure New Content is Indexed by Search Engines Quickly

Google have recently updated their algorithm to ensure their results show you fresher content. The latest update impacts 35% of all search queries. What can you as a web developer do to ensure the content on your site gets indexed quickly? By utilizing XML sitemaps and alerting the major search engines to changes to your XML sitemap as soon as content at a new URL gets added, content at old URLs are updated (a comment is posted, or any editorial changes) or even when a URL is changed. What is an XML sitemap?

Sitemaps are an easy way for webmasters to inform search engines about pages on their sites that are available for crawling. In its simplest form, a Sitemap is an XML file that lists URLs for a site along with additional metadata about each URL (when it was last updated, how often it usually changes, and how important it is, relative to other URLs in the site) so that search engines can more intelligently crawl the site.

Learn more about the XML Sitemap Protocol and study the XML Sitemap WordPress plugin for a better technical understanding of how to create sitemaps and alert (ping) search engines to changes to your site quickly. This should ensure your new content is indexed quickly and should ensure pages from your site is included as part of the ‘fresh’ search results (when relevant).

This article was not intended to be the complete list of SEO Guidelines for Web Developers but the intention is for it to be the starting point on your journey to make the web applications you buiild more SEO friendly now and in the future. If you think or know of anything I may have missed feel free to comment below with your SEO tip(s).

Images used within this article are CC by Kalexanderson.

SWAT wholeheartedly supports the statement “Individuals and interactions over processes and tools”, made famous by the Agile Manifesto. Yet, at the same time, we also acknowledge the need for global companies (such as those that make up the Naspers/MIH group of companies) to take advantage of online tools in order to improve communication and interaction among the individuals who form a geographically distributed team.

As stated by Ken Schwaber, one of the co-creators of Scrum, in early 2009 there were more organizations using agile processes than waterfall methodologies and, of those employing agile, 84% were using Scrum.

Despite the obvious need for Scrum tools, there are only a handful of online Scrum management tools available in the market, both open-source and proprietary. Some of them do not adhere to the theory of Scrum, others are not mature enough to handle the process as a whole, and other are simply not meant to do so. This has led to a misunderstanding of the agile concepts and, consequently, a less than ideal adoption of the process. Very often, the form of Scrum implemented by a given company was modified to suit the tools that had been chosen.

This gap analysis aims at comparing several popular Scrum management tools in a pragmatic way, with the purpose of identifying the best options available. A mathematical model has been applied to the data collected, resulting in a final ranking with scores that range from zero to ten. Charts have been generated to present how effectively the evaluated tools have addressed particular phases within the Scrum process, as well as the popularity of each tool feature taken into account by this study.

It is important to bear in mind that we evaluated these tools according to our own selection of criteria, which include criteria to make it suitable for distributed development. According to our criteria, a final score was derived, but there may be other criteria which will give different results.

Writing a piece of code is an ever evolving process and never ending, its a puzzle. Let’s think of it in modern terms, writing a code is like solving a level in Angry Birds, your primary objective is to get it done and working, i.e. solve the level and go on. But it does not stop there, you often do not get it perfect on the first try, so you need to go back and do more work on it, make it perform better, use less memory, its like going back to that level in Angry Birds and trying to get a 3 star rating.

Somewhere along this process you will run into every artist’s greatest fear, the mental block. Once you hit a problem you often get to a point that you have so exhaustively thought of why and how to solve it that it simply becomes impossible to find a solution while still looking at that code. This is where the “mental breaks” come in. A different activity, to most its the simple act of going to get coffee or water, taking a stroll outside in the fresh air, some like sports, some like games.. everyone has their escape valve.

I once worked with a good friend and an incredible developer and problem solver, he went simply by the name of “Chester”. It was really interesting to see how he worked a problem mentally and I had some of my best whiteboard coloring brain jamming sessions discussing architecture with him, but his block solving strategy was even cooler. Whenever he got stuck and brain crunching failed to find the solution he simply stopped and picked up a bucket of lego blocks. He sat there building whatever came to his mind until he came to that Eureka moment and the solution came up.

This strategy is something I see more and more in various development companies, like Google, Microsoft and so many others. The colorful rooms with beanbags, video games, or just plain outdoor places, little parks, sport courts and toys. Nerf guns, lego, desktop catapults, iPads with games these are just some of the examples that are out there. All of these have the same purpose as that bucket of building blocks my friend used, get your conscious mind off the problem and let your subconscious take a whack at it.

While this may not work for everyone or they may not be responsible enough to handle it, I believe advanced and competent developers are a perfect match for this, why? Firstly, the developer needs to be mature and responsible, otherwise all of the above are distractions from work, not breaks to solve problems. This is very crucial, if your developer is working to have a break and not taking a break to be able to work more, you have a team with low productivity or even worse with crappy code quality. Their minds are not in it, the code is now an obstacle in their way of the “free time”. Be careful to understand your team and select the right distraction, maybe lego’s will be productive and video games disruptive, or maybe its the other way around, there is no recipe, its all about knowing who works with you.

I truly believe in this process and have had some of the best professional years of my life in companies that understand the importance of this break and the flexibility of time in the office, right now we have a Lego NXT and an iPad and they work great for me whenever I hit a wall in my code. Does it work for you? Is your company in on this? Leave your comments.

Someone described NodeJS as the “first server-side JavaScript implementation you’d actually like to use”. According to its creator, Ryan Dahl, NodeJS is a set of bindings for the V8 (open source Javascript engine used in Google Chrome). It is focused on performance providing an evented and non-blocking environment. It is event-loop based and its goal is to allow writing high-performance web servers easily.

But how does NodeJS work?

NodeJS starts from the premise that we are not doing I/O correctly. Today, when we do a database query, the software just waits for a response and doesn’t do anything in the meantime. It implies that you block the entire process or you need a threading system that involves extra time, high use of memory or extra machinery. There is a big difference in the time used to access cache/RAM and the time used to access the disk or the network. We should not be treating these 2 groups the same way.

Ryan Dahl proposes a new way of doing I/O: supplying a callback to every call to the disk, network or another process. With this, your program can do other stuff (while querying the database, for example), and return to the event loop as soon as the query is over without extra expenses. So we can say that with NodeJS everything runs in parallel, except your code.

And why are we using javascript in the back-end?

Although most of javascript programmers never heard about event loop in their lives, the language has all the requirements to provide an event loop platform:

- closures and anonymous functions are available for making callbacks
- only one callback fires at a time
- I/O through DOM event callbacks – if someone clicks a button, you have a “click” callback.

Besides those reasons, since the release of V8, every browser vendor is pushing the speed of their engines in a velocity that no other programming language saw before. And, in the end, every web developer had one time in their life programmed with javascript (that inforces the easily part of the goal).

So, how do I use NodeJS?

First, you need to download it from the project page and install in your computer. The V8 engine is included in the pack and the only dependency you have is Python 2.4. It is a command-line tool, so you run your programs by typing in the terminal: node yourapplication.js. The “Hello World” of NodeJS looks like this:

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(8124, "127.0.0.1");
console.log('Server running at http://127.0.0.1:8124/');

This program creates an HTTP Server and prints “Hello World” when a request is done. By the way, one of the design goals of the project was to have support for all the important protocols: DNS, HTTP and TLS.

Where should I use NodeJS?

It should be used when high concurrency is really important. It is suitable for real-time, crawlers, process monitoring, file uploading and streaming applications, just to name a few. It is still not recommended to use it for entire websites – it is too buggy and low level for that in the moment.

More information can be found here:

Project page: http://nodejs.org/
Github: http://wiki.github.com/ry/node/
How to Node: http://howtonode.org/
Ryan’s Techtalk at Google: http://www.youtube.com/watch?v=F6k8lTrAE2g

Agile methods are often described as “common sense”. For this reason Ken Schwaber refuses being titled the Co-Creator of Scrum. Several software development practitioners such as Ivar Jacobson, Grady Booch, and James Rumbaugh all contributed to the set of principles that today form the Scrum framework.

However, having Scrum, XP, or any other method classified as common sense leaves a lot of room for interpretation by the individuals applying them. Thus, iteration planning efforts sometimes end up being superficial, not entirely committed to the system actors’ real goals. As a practical consequence, user stories are found reduced to single sentences hanging on the white-board.

It is clear that User Stories are not Use Cases or Requirement Statements, as detailed by Mike Cohn, and highlighted as follows. Firstly, use cases are generally written as the result of a long analysis, whereas user stories are written as notes that will be used to initiate further analysis conversations. Secondly, requirement statements make costs visible only when all of them have been formally written in a lengthy document, whereas with user stories a complexity estimate is associated with each story immediately. Costs are then easily calculated by taking into account the velocity of the team.

Nonetheless, developers should not underestimate the complexity inherent in each story, and complementary theory can be found on this topic. Ron Jeffries breaks down the stories into three aspects: Card, Conversation, and Confirmation.

Firstly, the card does not detail the story in depth, but successfully identifies it. Typically, team members and product owners adhere to the following template, popularized by Mike Cohn: “As an <actor>, I want to <action>, so that <achievement>”. Although advantages derived from using this template have been listed, other agile evangelists have proposed enhancements. Elizabeth Keogh, for instance, came up with a new user story format that better emphasizes business value. One way or the other, templating has been the common approach, and teams should adopt one that will fit in smoothly within their environment.

Secondly, conversation is the activity that communicates the requirement from customers to developers during the product and sprint planning. At this stage, details such as dependencies and barriers are mapped out. As depicted by Jeffries, the conversation is largely verbal, but is often supplemented with documents. It is important to bear in mind that good communication is a key success factor in any software development project, and none of the artifacts produced throughout the process may substitute that.

Finally, stories are verified through confirmation or, more specifically, acceptance testing. All criteria taking into consideration ought to be defined during planning phases as well.

Although the theory presented above brings some structure to the loose perception of user stories, the writing itself remains vague. So William Wake advocates that agile practitioners should INVEST in good stories and SMART tasks. Despite not being a particular fan of forced acronyms, I have to admit that some guideline will be welcome here.

Briefly, characteristics that form a good story description are the following:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

.
Hence, a story should be independent from others, negotiable between customers and programmers, valuable to customers, estimable in terms of complexity, small for the sake of understandability, and testable on account of readiness confirmation. Further studies suggest that “Small” should be replaced with “Sized appropriately”, as the bottom of the product backlog may contain items that are not fully understandable by the team yet, also known as Epics.

Tasks, in their turn, should be:

• Specific
• Measurable
• Achievable
• Relevant
• Time-boxed

.
So a task needs to be specific by addressing one particular point, measurable in order to be tested against the definition of done, achievable by the task owner, relevant to the story at hand, and time-boxed. This latter characteristic should not be perceived as a formal estimation in hours or days though, as it does not work. The raw material in Software Engineering is the developer’s own intellect, and nobody would be able to estimate its maturation time. The same applies to activities such as painting or novel writing. Civil Engineering, on the other hand, benefits from using raw materials that allow for accurate calculations, such as concrete and iron.

As a final note, during the planning, instead of defining longer iterations and allowing for bigger stories, you might be interested in giving the following set of constraints a try. SWAT has successfully built some of its software by adhering to them. Manageability goes through the roof!

• 5-day sprints
• 5-point stories, or less
• 2-developer teams, up to 4

.
In conclusion, a better organized agile planning is more likely to drive the team towards the goals identified by project stakeholders. Theories and guidelines have been proposed, and I suggest bringing these concepts to the table when starting a new agile project.

As outlined in his talk, the very first question when developing for mobile is: what type of application do I want my product to have? Currently, there are three different types: Native, Web and SMS. Choosing one is based on the purpose of your project as well as the target audience.

• Native: used when the aesthetics of the app is very important. Native is recommended when you want to access a core feature of the device, like a camera or GPS. And, because of their app stores, Native apps have the added advantages discoverability and visibility.  The disadvantage with this type of application is fragmentation, i.e. you must write a different application for each device.
• Web: used when the focus is on distribution. Web apps are available on any device enabled with Internet access and there is no need to download. Considering testing and supporting, web applications have an advantage since they do not need to go through all the bureaucracy of the app store. Updates are also up and running instantly. The main disadvantage of web apps is sand-boxing.
• SMS: rare and only used in markets where internet access on the phone is not available or prohibitively expensive. SMS apps don’t offer discoverability.

Considering the above, Web applications are usually the best choice. They are cheaper to produce, more standardized and easier to distribute. According to Stark himself, “If you CAN build your app with HTML, CSS and JavaScript, then you probably should.”

In the second part of the talk, two interesting tools were demonstrated:

jQTouch

jQTouch is a jQuery plugin for mobile webkit browsers developed by David Kaneda. It Allows native animations, navigation and automatic customization of theme. Even if you will not actually using it in your application, it is a great tool for prototyping it.

To set jQTouch, you have to add in your page:

That means:

(1) adding hardcore structural design rules. This is required and you shouldn’t edit it
(2) add your theme style file. There are some options in jQTouch website or you can write your own
(3) initialize jQTouch after javascripts files are added. You can pass an object as a parameter with some values as icon and preloadImages

You can learn more from the jQTouch website or its documentation.

You can also see a quick overview in the video bellow:

PhoneGap

PhoneGap is a framework for building cross-platform mobile apps. Using it, you can still take advantage of core features in iPhone, Android, Palm Symbian and Blackberry. It’s been recognized as a game-changer and its source code has been downloaded more than 200,000 times! Web applications can now compete with native applications when functionality is the main requirement.

For more information, you can visit the PhoneGap website.

To learn how to install it, check the video bellow:

Get the Best Apps Now!

We look at mobile apps from different app stores and find out the best ones for you! This is your place to find out the most useful apps for your various devices. Visit apps.mihswat.com for the best Android, iOS, Chrome, Firefox, PC, Mac , Amazong and Windows Phone apps.

For those not familiar with Scrum, let me summarise the key principles quickly:

1. A project team is setup usually consisting of between 5 and 9 resources.
2. The resources within the team have the set of skills needed to develop products.
3. There are defined roles within this setup, namely

• The Product Owner: Manages a list of product features that require development. These features are prioritized by the Product Owner.
• The Scrum Master: Ensures that the processes are followed and helps the team deliver the product features by removing any impediments that prevent them from delivering.
• The Team: Self organises around the product features and collectively work together to deliver these product features.

I’m simplifying the roles here of course – there are further responsibilities that are played by each role, but this is the essence.

4. The team produces working demonstrations of the product features at regular intervals (typically every two weeks).
5. These working demonstrations are visible to the business, allowing the business to get a view on where the product is going and whether it needs refinement or a complete change in direction.
6. The refinements or improvements are then fed back into the team, prioritised by the Product owner and driven through to demonstration once again.

The framework is agile in nature. Problems are quick to identify, and quick to change. Traditional project management methodologies would allow a project to proceed down a long and drawn-out development path and if the up-front analysis had not been 100% accurate, or if external factors had required a change to the project during development, this would be very difficult to accommodate. The Scrum process by contrast makes sense – it is a simple, logical way of delivering projects and caters for changing requirements.

That said, the question of how to setup the Scrum team and environment remains. As a new team, we are facing these questions and trying to figure out the best path to creating the esteemed “High Performance Team“. There are two schools of thought here. Let me deal with the first.
As competent and experienced team members, there is a sense of “doing things right, from the start”. This includes everything from ordering the right development hardware, deciding on what software is appropriate, defining the practices and principles the team is going to follow, which languages are best suited for the projects that need to be developed, and what the collaboration environments need to look like. All good stuff, and completely necessary. The planning also includes discussion and decisions around how to test the code that is developed, how it is documented, how much of this is automated versus manual, which tools are best suited for testing, how new issues get logged and fed back into the team, and how much test coverage is considered acceptable. Again, all good stuff, and all appropriate to the work that is being done within the team. It is also a good idea to get the overall context of the project defined up front so that broad architecture decisions can be made. Where the team needs to be careful however, and we are all sometimes guilty of this, is when it comes to over-engineering a solution up-front. Chances are that this picture is changing, or will eventually change. Nothing wrong with good architecture up-front, but trying to understand too much detail too soon is probably wasted effort.

Lets take a look at the second school of though for a moment. The principles of Scrum and Agile development methodologies and practices suggest that the value lies in delivering small, incremental features, regularly. Mistakes and changes to project scope are inevitable and it is the ability of the team to correct these mistakes, and accept the changes in scope that makes them “High Performance Teams”. Through continuous feedback and team “retrospectives”, the gaps get filled, and the holes get plugged. The team continues to improve as a result and the delivery continues to speed up – well, from the initial stages anyway. Its a situation in which the team adapts the principles of Agile software development to suit their unique environment, the individual strengths and weaknesses and their team characters.

The point that I am trying to make here, is that there are two ways to try and achieve the “High Performance Team”. There is the “Lets build the 6-foot armour-plated robot with Augmented Reality vision”, or, the “Lets build the stick man and determine what he needs next” approach. There is a fine line between setting up a team that does everything right from the start, and a team that is setup to learn how to do what is right for them.

I was recently made aware of an agile development team based in the UK that has been together for the past 60 months. They deliver code weekly, have a number of visible metrics for how many bugs are in their system and how quickly they are resolved, what the velocity (capacity for delivery) of the team is, converted into monetary value, and a number of other “reporting” metrics. Incredibly useful information, and a sign that they are a “High Performance Team”, but I wonder how much of that was setup from the start, and how much of it “evolved” as the team progressed through their 60 months of development together?

To take the analogy used above, whilst it is important to have a team vision in place and to follow best practices where ever possible, I firmly believe that it is best to create the stick-man from day one, and get him running in an agreed direction, rather than spend too much time thinking and planning the 6-foot robot that potentially is only capable of taking a few steps at a time, and hopefully, in the right direction.

That being said, our team is in a good place. We are positioned nicely and are moving forward as a unit. Hopefully the discussions that our team have had, and the conclusions drawn here, can help you position and setup your own team.

Nowadays it’s almost impossible to write an article about mobile phones without mentioning the very successful iPhone. Apple had practically turned the mobile  industry upside down with its touch screen device. Some people will argue to the death about how the iPhone, or the “Jesus Phone” as some call it, is the best thing since sliced bread – and nobody can argue against how successful this device has become. But I am predicting a total onslaught of Android devices within 2 years. The Android army of phones will be everywhere you look and you will not be able to visit any cellphone store without running into at least 50 different phones running this OS. OK – maybe that is going a bit far but I think you get the message and already we are seeing signs of it. At the time of writing this article there are 16 official Android devices. How will this army of Android devices be created you ask ? Enter the Open Handset Alliance.

The Open Handset Alliance was formed in 2007 and currently has 47 members. It is a consortium of technology and mobile companies all dedicated to bringing us better mobile experiences, with Android being their first project . There are some big names amongst the 47 members, including Google, Intel, Nvidia, HTC, Asus, SonyEriccson, LG, Ebay. With so many big names dedicated to Android development, it is bound to be amongst the top mobile device OS’s. You can read more about this argument here, let me get to the Android architecture.

Android is a Linux based software stack. On top of the Linux kernel layer lies a layer for the system libraries such as SQLite, SSL, OpenGL, etc. This layer also houses the Android runtime, which runs the Dalvik Virtual Machine. On top of this there’s the Application Framework, housing the managers like the Activity Manager, Window Manager, etc. Then finally there is the application layer, which is the layer we are most interested in.

Android applications can consist of different sections, namely Activities, Services, Broadcast Recievers and Content Providers. Activities form the User Interface(UI) part of the application, Services run in the background similar to RSS feed readers checking for updates. Broadcast Receivers just listen for particular system broadcasts, for example , when the battery is low. Content Providers just provide content to any asking application , for example your application asking the contact book to provide the users contacts for use within your application. We will mostly be concerned with Activities.

Activities were designed to be totally integrated with one another. What I mean is that Activities can call one another and pass data to one another, basically  like an event driven system, but on a system wide level. An application is thus a group of Activities passing Intents to one another. It is then possible to include , lets say, a Google Maps Activity into your application by passing a Google Maps Intent to it and waiting for a result from it. It would seem to the end user that you created a Google Maps section to your app. I think this is pretty powerful.

To get started with creating these applications you need the free Android SDK, Apple iPhone developers need to register first($99!). Then you going to need an IDE, there is an Eclipse plugin, the Android Development Tools(ADT) plugin that has everything including the latest stable SDK. You don’t immediately need a phone to test on as ADT comes with an Android emulator that you can debug and test with but you will eventually need a phone to properly test with. ADT is pretty awesome as it comes with many tools to tell you exactly whats happening on the phone, which threads are running,it has code completion, wizards to quickly create sub classes and much more. It took me less than 30 minutes to get a “Hello World” application running on the Android emulator from the time I installed the ADT!

Since ActionScript 3 is a lot like Java I could easily jump in even though there were a few syntax differences – but after about 2 days and the help of ADT I had a basic application drawing a ball bouncing round the screen. But that was only the beginning and have rewritten sections of the game many times. Now after two weeks of lots of learning I have created the game and have it running on my phone. It is still a prototype and even though it needs weeks more spit and polish, after demonstrating the game I have gotten the thumbs up to turn it into a real game which we will be registering in the Android market.  There is still a lot to learn from this wonderful framework but the Android groups have been great help, as well as all the Android forums and of course, the Reference guide which ships with the SDK. It has been a challenge to get to grips with this entirely new development area but it was far easier than imagined it would be. I spent about 10 times longer getting to know Flash, and that was with people available to help me.

What about my experience using the phone? I can honestly say I am now more connected than ever before. My email, both gmail and exchange, is pushed to the phone. My Twitter application runs in the background constantly fetching  tweets, while my Facebook application gets all my buddies’ status updates to me as often as I want to see them. News and weather is updated all the time. My calendar and contacs are synchronised between my phone and my mobile. I never get lost anymore, maps are always available and my Gtalk status is always “available” and running in the background, unlike on some other phones Oh, and it makes phone calls as well.

I will follow up with another article of my findings, good and bad, this time focusing on the actual Android game development.

The 5.3 release of PHP is the most important release ever, and adds a lot of new features – leading to a delay in its release date. We will look at the most important feature enhancements from version 5.2 to version 5.3.

Let’s first look at the enhancements from PHP 5.1.X to PHP 5.2.0:

• Memory optimizations
• Filter extension
• JSON extension
• ZIP extension
• File upload progress hooks
• DateTime and DateTimeZone objects
• A couple of others small ones

While these changes were interesting, (especially the first one, which lead PHP 5 to run quicker than PHP 4), they were not very visible and “hype” changes.
Now, let’s take a look at what PHP 5.3 will offer, and let’s try to judge the extent of the upgrade.

PCRE, Reflection and SPL functions are always enabled
It sounds obvious, but some libraries rely on Reflection/SPL to be able to work. One example is Doctrine ORM, which enables you to work at the OO level when using databases as storage medium.
PCRE is a faster library than POSIX RegEx, which may help you to write faster code when dealing with regular expressions.
Also, I am helping with the re-implementation of the spl_object_hash function, to solve some collisions and also to improve performance.

NOWDOC and HEREDOC syntax
While HEREDOC syntax has been available for quite a while, it has some interesting optimizations that will allow it to behave as fast as a normal string declaration. HEREDOC uses the same syntax as a normal string declaration with double-quotes.

$author = 'Guilherme Blanco';

$msg = <<< EOT
This is \x41 message from $author!
EOT;

$msg2 = "This is A message from $author!";

// $msg1 === $msg2
echo $msg1; // Prints: This is A message from Guilherme Blanco!

NOWDOC is a new inclusion to the language, which behaves exactly like a normal string declaration with single-quotes. This means it doesn’t convert the variables and symbol codes to their correspondent values.

$author = 'Guilherme Blanco';

$msg = <<< 'EOT'
This is \x41 message from $author!
EOT;

$msg2 = "This is A message from $author!";

// $msg1 !== $msg2
echo $msg1; // Prints: This is \x41 message from $author!

?: operator
Quick alias for those that have to do this all the time:

// PHP < 5.3.0
$data = isset($var) ? $var : 'default';

// PHP >= 5.3.0
$data = isset($var) ?: 'default';

__DIR__ constant and error modes E_USER_DEPRECATED, E_DEPRECATED
These two error modes are quite simple. They have been introduced to inform the user of stuff being scheduled for removal in future PHP versions.

The __DIR__ constant is a nifty feature for those who are not happy with include paths.
For many years, I personally had to work around directory mismatches by checking the directory of the current file.

Now we’ll be able to use this new constant (which is much faster):

// PHP < 5.3.0
require_once dirname(__FILE__) . DIRECTORY_SEPARATOR . 'File.php';

// PHP >= 5.3.0
require_once __DIR__ . DIRECTORY_SEPARATOR . 'File.php';

__callStatic(), __invoke() and dynamic access to static members
One awesome feature that PHP 5 introduced was the magic methods: __set, __get, __call were quite useful for developers who wanted to control access to their objects. But one missing feature was the ability to control static method calls. To fix that, PHP 5.3 will introduce the __callStatic magic method, which will allow it to handle static method calls, like Foo::bar();

With a new implementation of lambdas and closures that I’ll detail later, more dynamic behaviour will be required from the OO side. To make us – PHP developers – more comfortable, PHP 5.3 will introduce the possibility to call an instance of a class as a function. This support was included under the magic method __invoke(). Sounds weird, but I’ll show you a quick example:

class Foo
{
public function __construct()
{
echo "Calling from constructor...\n";
}

public function __invoke()
{
echo "Calling from invoke...\n";
}
}

$foo = new Foo(); // Prints: Calling from constructor...
$foo(); // Prints: Calling from invoke...

For those who do not know hebrew, the PAAMAYIM NEKUDOTAYIM is not more difficult to be found. Now it’ll be possible to do some weird calls such as $var::staticMethod(); and it’ll work!

Garbage Collector
After a lot of discussion and a Google Summer of Code project, David Wang devised a very good garbage collection mechanism that deals perfectly with cyclical references for PHP.
This means that PHP will use MUCH LESS resources on the server, consuming much less memory, not throwing memory exhausted exceptions any more when importing things.

This extension is built-in, and as far as I have been able to determine, it cannot be disabled. The only way to prevent the Garbage Collector from collecting lost cyclical references, is by calling gc_disable. The other gc_* functions will always be available. This means that you will be able to enable/disable GC through functions gc_enable(), gc_disable(). When it becomes necessary to remove non-referenced objects, simply call gc_collect_cycles(), and PHP will perform its magic for your server.

Late Static Binding
Currently, static references to the current class, like self or __CLASS__ are resolved using the class in which the function belongs, as in where it was defined:

// PHP < 5.3
class A
{
public static function who()
{
echo __CLASS__;
}

public static function test()
{
self::who();
}
}

class B extends A
{
public static function who()
{
echo __CLASS__;
}
}

B::test(); // A

Static references to the current class like self:: or __CLASS__ are resolved using the class in which the function belongs, as in where it was defined, so when we call the test() method on class B it will call the who() method of class A.

LSB tries to solve that problem by introducing a keyword that references the class that was initially called at runtime. Basically, a keyword that would allow you to reference B from test() in the previous example.

It was decided not to introduce a new keyword but rather use “static”, which was already reserved.

// PHP >= 5.3
class A
{
public static function who()
{
echo __CLASS__;
}

public static function test()
{
static::who();
}
}

class B extends A
{
public static function who()
{
echo __CLASS__;
}
}

B::test(); // B

Some people describe static:: as the $this-> resolution for static calls, this is not true as $this-> follows the rules of inheritance while static:: doesn’t.

Namespaces
After months of discussions and a lot of issues that had to be fixed, the namespaces implementation has finally been incorporated, and is already available under alpha 3.
The namespace separator doesn’t please everyone especially those that do not use english keyboard layouts. These people will suffer due to the lack of “\” char on keyboard.

Here is an example usage of this new feature of PHP 5.3:

// File1.php
namespace Foo;

class Bar
{
public function test()
{
try {
do_some_stuf();
} catch (Exception $e) { // Refers to Foo\Exception
// Special handling of Foo Exception
} catch (\Exception $e) { // Refers to PHP Exception
// Special handling of Exception
}
}
}

// File2.php
$b = new Foo\Bar();
$b->test();

// OR...

use Foo\Bar as Baz;

$b = new Baz();
$b->test();

Lambdas Functions/Closures
This can be considered to be an important new feature of PHP, as important as namespace support.

From now on, it’ll be possible to do this:

$func = function ($str) { echo $str; }

$func('Hello World!'); // Prints: Hello World!

Certain situations arose where variables from an outer scope should be allowed internally too. That was a limitation of PHP (variable scope), but it was fixed by the usage of new syntax when defining the lambda function:

$first = "Guilherme";
$second = "Blanco";

$func = function () use (&$first, $second)
{
$first = "Hello";
$second = "World";

echo $first . ' ' . $second; // Prints: Hello World
};

$func();

echo $first . ' ' . $second; // Prints: Hello Blanco

New SPL classes
A lot of work has been done, especially by Etienne on SPL (the Standard PHP Libraries). There is a bunch of new data structures that will be available to users starting on PHP 5.3.
Until now, no updated documentation has been made available, but looking at the source it is easy to figure out how to use these new structure.
Here are the new data structures which will become available:

• SplObjectStorage (added ArrayAccess support + new features)
• SplDoublyLinkedList
• SplStack
• SplQueue
• FilesystemIterator
• GlobIterator
• SplHeap
• SplMinHeap
• SplMaxHeap
• SplPriorityQueue
• SplFixedArray
• RecursiveTreeIterator
• MultipleIterator

mysqlnd
This is a replacement library (and it’s not an extension) for libmysql, offering a lot of advantages over it the latter. While libmysql was developed primarily for C and C++, mysqlnd is optimized for PHP, taking advantage of the Zend Engine.

These advantages are:

• Tight integration with Zend Engine
• Faster execution
• Lower memory
• Easier compilation of PHP,since it’s native now (libmysql was bundled with MySQL Server)
• Usage of PHP stream API
• Statistical Data Collection
• Client-side (PHP userland) Query Cache
• License compatibility
• Easy to introduce future improvements (prepared statement cache, built-in profiling, automatic load balancing, etc)

Fileinfo
This great PECL extension is now enabled by default in PHP to replace mime_magic.
It is possible to pick the right content-type of files, giving you more secure code and preventing some security issues the previous library allowed, such as uploading a PHP script as a GIF file for example.

Here is a piece of code that shows how to use this extension:

$fileinfo = new finfo(FILEINFO_MIME);
echo $fileinfo->file('/path/to/file/to/be/checked.jpg'); // Prints: image/jpg
$fileinfo->close();

Phar
How do you share your library? How do you share all the source code?
While other languages provide a nifty packaging system, PHP until now had not features to support anything like this.
With PHP 5.3, phar has been included for all of us.

You may not be aware of this – but I work on my spare time on the Doctrine ORM project. Let’s use Doctrine as an example.

First we want to pack our entire project into a single file called “doctrine.phar”.

$phar = new Phar('doctrine.phar', 0, 'doctrine.phar');
$phar->buildFromDirectory('/path/to/doctrine/lib');
$phar->setStub($phar->createDefaultStub('Doctrine.php', 'Doctrine.php'));

It’ll generate a “doctrine.phar” file that we can distribute to people.

Once you have the phar file, you would have to do the following to load the library:

include '/path/to/doctrine.phar';

Improved Windows support
As a member of the PHP Windows team, I cannot finish this article without mentioning that some PHP developers are working extremely hard to be able to provide a lot of *NIX only features for Windows server too.
Two days ago Pierre finished the link() support, which creates symbolic links (shortcuts for Windows users) through PHP. Currently there is a list of functions for which support on Windows is planned – this list can be accessed via URL: http://wiki.php.net/internals/windows/todo

Also, I worked on a PHP webpage at http://windows.php.net which provides customized Windows builds of PHP. It’s possible to pick a snapshot or a VC9 compiled version.

I hope you all enjoy it! =)

Let me provide some background. The majority of our team members, both in South Africa and Brazil, had been Microsoft .Net developers at some point in their careers, and some had never been anything else. We used to hire people based – in part – on their expertise with Microsoft development tools.

As a business unit, SWAT comes into contact with a large number of organisations from around the globe that are members of the MIH group. In our interaction with these companies we were experiencing a great deal of resistance to implementing Microsoft software.

The reasons for this resistance were varied but often based on cost – both the cost of the software and the cost of the people who are skilled in the use of Microsoft tools. Cost was not the only consideration – the general perception out there is that the Web is built on open source software, and that open source is where the best developers want to place their efforts and build their reputations.

It was very clear that we had to cross the great divide if we wanted to stay relevant in the markets where the group operates.

Although we had never been a pure Microsoft shop – we used Flash technologies, Javascript , CSS and their kin, as well as various tools for mobile development – our core development tools were Microsoft Visual Studio, using C# with .Net and ASP.Net, and the challenge was to change our primary development platform.

Our greatest concern was what the reaction of the team members would be – I mentioned earlier that the majority of people in the team at that time were skilled in Microsoft technology, and we were worried that the re-skilling that would be required would present us with a very steep (and costly) learning curve. A further concern was that the changeover may cause people to leave the team, rather than lose the skills they have already acquired in Microsoft technologies.

Once the decision had been made to shift our focus to open source development, we had to choose a platform. The obvious choice was PHP 5.0. “Obvious” because of the wide popularity of the language within the group, the wide support for PHP and the vibrant PHP community. An additional consideration was that PHP is fairly similar to C#, in terms of syntax and in terms of being a “traditional” object oriented language. Although we considered options such as Ruby, we concluded that PHP would represents the best option for migrating to open source.

It has been more or less a year since we finally phased out Microsoft tools, and here’s the summary of our experience:

• Great programmers do not care about the language. We lost no-one because they wanted to work only on Microsoft platforms.
• The web IS built with open source tools – and using open source tools gave us a wider audience.
• Costs for software development tools have plummeted to virtually zero.
• The Microsoft Visual Studio IDE is one of the best (if not the best) development environments available.
• If you are going to use open source, you must be willing to change and adapt all the time. Frameworks, tools and methodologies are continuously changing in the open source world – forget about well-planned migration routes for technology. Be pragmatic, and use what works. We still use Microsoft tools when our clients require it.
• Because it is open source, it is possible to look into the code to find why things do not work as expected. Often it is very hard to find the solution, and there is hardly ever a helpdesk which you can call. But you can look if you want – the option is there.
• Microsoft is not bad. In our experience it is simply a matter of choosing the most appropriate tool for the job, and the Microsoft tools are more suited for enterprise development. Although of course the platform CAN be used for web development.

In summary – the decision to go open source was the best decision for our team, and I would encourage every team that does web development to do the same thing.