Should You Build a Mobile App or Mobile Website?

Should You Build a Mobile App or Mobile Website?

There’s no doubt that mobile has gone mainstream with consumers increasingly on the move and companies seeking more ways to stay in front of their eyes and right at their fingertips. As a result, businesses are realizing the importance of maintaining a mobile presence, yet many are uncertain whether a mobile application or mobile website is the best way to go to reach consumers on the go. To outline the basics and benefits of a mobile website vs. mobile app, MDG Advertising developed the following informative infographic. It outlines the options and opportunities behind both mobile methods, along with the facts and figures regarding reach and response to help companies make the right move to mobile. [MDGAdvertising]

Source: http://dailyinfographic.com/should-you-build-a-mobile-app-or-mobile-website

How to Become an iPhone Application Developer in 7 Strategic Steps

The iOS mobile platform exploded onto the scene in 2007 with the launch of the iPhone, and has been increasing in popularity ever since. With the recent successful releases of its fifth operating system (iOS5), the iPhone 4S and the New iPad, the beast that is Apple's mobile device market shows zero signs of slowing. The success found by many iPhone application developers plus the increasing popularity and versatility of iOS devices have inspired many new and established programmers to pursue careers in iPad and iPhone application development.

For the non-programmer, however, the road to creating iOS applications for the iPhone and iPad can be a long one. Even for the casual programmer the iPhone application development experience can prove challenging; iOS utilizes a suite of technologies that are not often seen elsewhere, and iPhone's operating system includes technologies with a high degree of complexity that can be unwieldy for beginners. Beginners can go here to learn more about the iPhone Application Developer career path.

For those visionaries who are up to the challenge, here are the seven strategic steps to becoming an iPhone Application Developer:

01: Get the Necessary Tools

To create mobile apps for the iOS you need a Mac computer. Next you need to obtain the necessary development environment, called XCode. The XCode software is available on Apple’s Developer Web Site  or through the Mac App Store. With XCode installed you will now be able to write and compile iPhone applications directly on your Mac desktop or laptop.

Featured Course: BSIT Mobile Computing (Kaplan) | Highlights: Android, Blackberry & iOS App Development Training, Objective-C, Java & .Net Programming, Learn to Build Database Integrated Apps... COURSE DETAILS

XCode contains two very important tools for iOS developers. First is the iOS Simulator. The iOS simulator allows you to test most functions of the iPhone & Pad directly on your Mac. The simulator is limited, however, and it is recommended that you obtain an Apple smartphone or tablet for final testing. The second vital tool inside XCode is the Interface Builder. The interface builder provides all of the programming objects and controls needed to construct standard iOS application interfaces, such as buttons, calendars and data entry fields.

02: Learn C Programming

The C programming language is the ancestor of Objective C - which is the programming language used in iPhone application development. I strongly recommend that new programmers learn C first however, as it will allow you to grasp the basics of programming, and more importantly the basics of computer memory management, without the complex layer of Object-Oriented Programming (OOP) introduced in Objective C. I have always seen that it is easier to learn a procedural language first (such as C), and then move onto an Object Oriented Language.

03: Add the Objective C Layer

Objective C will be much easier to learn once you grasp the underlying C code. Objective C is a superset of C - meaning it takes everything that is the C programming language and adds more to it. Objective C adds Object Orientation to C. Object Orientation is a programming methodology which allows you to break programming problems into various objects that interact to solve a problem. While most major programming platforms today use some version of object orientation, it is still a steep hill to climb for a new programmer to become proficient. Once you’re comfortable writing Objective C programs it’s time to crack open the iOS!

Featured Course: Mobile Development Online Bachelor's Degree (Full Sail) | Highlights: Android and iPhone Application Development, Java & Objective-C Programming, UI Design & Usability Testing... COURSE DETAILS

04: Learn the iOS Environment

Now that you can code in Objective C, you can effectively learn the iOS programming environment. You’ll use the Interface Builder to create custom iPhone application user interfaces (UI), and write Objective C code to make them work. There are many Objective C classes (libraries of commands and functions) designed specifically for the iOS - for example classes that operate the on-board camera or address issues related to local data storage.

05: Write your First iPhone App

Choose a project you’ll enjoy completing and work it all the way through. Be careful not to choose an application that is overly complex or it will take a great deal of time. Don’t give up when it gets frustrating or seems difficult. Overcoming obstacles the first time you create an application is important, and the sense of pride you get from completing your first iPhone application will motivate you to create more complex and useful apps.

06: Sign-up as an Official iOS Developer

When you’re ready to release your iPhone app prototype, you'll need to register with the iOS Developer Program . The cost is $99/year, and it involves registering as an Apple developer, and selecting the program(s) you want based on the platforms (devices) you wish to develop for. Even if you're not close to completing the project, you'll need to be an iOS Developer to test and debug your code on an actual iPhone or iPad, as opposed to the simulator. Once you're registered as an official iOS Developer, you will also be able to submit your application to Apple's App Store, making it available to millions of potential customers.

07: Market Your Application

A good way to build an audience for your iPhone applications is submitting a free “Lite” version to the app store. Creating a Lite version will enable you to expose your iPhone app to the masses, as many mobile application consumers want to try before buying. If your app is special/entertaining/useful, users will get hooked on the Lite version and gladly pay your asking price. To further promote your iPhone app for free, write it up in blogs, forums, and social sites like Facebook, Twitter, LinkedIn and Google+. Utilizing the multitude of mobile application review sites is another great way to garner free press for your iPhone app; just send these sites a request to review your app. If you have an advertising budget, I suggest buying a moderate amount of mobile ads in the top iPhone Ad Networks, such as Admob & Quattro. If these ads are profitable you can increase your spend and expand into more ad networks.

You’re now on your way to becoming an iPhone Application Developer. Keep in mind that the career of a programmer involves a lifetime of learning and that learning the iOS platform and its related technologies is just part of that journey. Good luck!

Source: http://www.itcareerfinder.com/brain-food/blog/entry/how-to-become-an-iphone-application-developer-in-7-strategic-steps.html

10 things for making your Agile adoption successful

Ken Schwaber has been reported as saying that only 30% of teams who attempt Scrum
will be successful. On his blog he says he doesn’t remember this and instead suggests only 30% will become “excellent development organizations.”

What I find interesting about this quote is that it aligns with many other change management studies. Change experts like Harvard Professor John Kotter regularly say 70% of major change efforts fail.

However you look at it the prognosis isn’t optimistic. Then one day as I was finishing a course delivery someone asked me: “What can we do to ensure that we are in the 30% who make it?” – at that moment I knew I had write this list.

There isn’t anything magical about 10 items it could have been 7 or 12, all three numbers have a resonance but as I put the items together it seemed that these 10 were more significant than anything else I could think of, and taking anyone away made the list less effective.

So, with apologies for another top-10 list, here you are.

1)Use a physical board

“I put the shotgun in an Adidas bag and padded it out with four pairs of tennis socks, not my style at all, but that was what I was aiming for: If they think you're crude, go technical; if they think you're technical, go crude. I'm a very technical boy. So I decided to get as crude as possible.” William Gibson, Johnny Mnemonic

I have become convinced that the single biggest difference between teams which successfully adopt Agile working and those who try, fail, or end up stuck is the use of an actual physical board.

I know some teams find this difficult, I know some teams are distributed, I know there is technology out there to do this for you but I stand by my point. If you can make it physical, in a place where many, if not all, can see, then you are more likely to succeed.

It is hard to explain the logic involved in why I recommend this, you have to try it and witness it. I feel there is some kind of magic that happens when the very abstract, theoretical, world of software meets physical cards and board.

Visualizing the work is only the start: learn to read the board and act on what it is telling you.

2) Start collecting and using statistics

Velocity, burn-down, bugs identified, bugs logged, etc. etc. Metrics have a bad name in software development -rightly in many cases. But that only means they have been badly chosen, collected and/or used, it doesn’t mean they aren’t useful. At the very least measure your velocity and create a burn-down chart or cumulative flow diagram of the work.

The beauty of Agile working is that it is quite easy to measure a few simple metrics. Once measurements get complex people don’t understand them so it becomes more difficult to learn from them. Like the boards, the metrics are useful in their own right but are far more useful as a learning instrument.

3) Engage a coach/consultant

At the risk of being accused of trying to make work for myself I should say you can adopt Agile all by yourself. You can read the books, you can experiment, you can go on courses. But doing it without help makes the whole process slower and increases the risk that you won’t make it to the 30%. Plus, adoption will take longer – and that brings more risk.

Personally, I find it difficult to know just how an Agile Coach differs from an Agile Consultant. What ever you call the role you want someone who can:

• Observe, examine, query and challenge your thinking on what you are doing
• Provide advice on which practices and process to adopt, and how to best adopt them
• Offer examples of what they have seen work, and not work, elsewhere, and how other team tackle similar issues.

You may need to work with multiple advisors since few will be able to cover all process, practice, technology, product and strategy bases. On a very large team it might be worth having full-time consultants although the model I have had most success with is light-touch coaching in tandem with a pull-change model (below).

I don’t believe such an advisor needs to be full time but I do believe it should be ongoing. I practice, and have written before about, light-touch Agile coaching, in this model I return to companies at intervals, perhaps monthly, perhaps more frequently, sometimes less frequently and continue the discussion.

4)Action over talking

Action speaks louder than words, until you start trying to do Agile you can’t foresee all the issues and questions which will arise. The longer you spend talking about doing it, and not actually doing it, the more it anticipation will build up, the more more it will look like just another management fad.

By all means talk about it, plan a bit but there is no real substitute for just getting stuck in and doing it. Learn from what your doing and refine. Use some measurements to understand what is happening. Don’t waste your time looking for evidence, make your own.

In particular do not spend your time agonizing over whether to do XP or Scrum, or Lean or FDD, or DSDM or Kanban. They are all pretty much of a muchness and you will end you up crafting your own hybrid anyway

5) Give everyone training and start group wide discussions

Teams don’t get to be Agile by management deeming “thou shalt be Agile” - although plenty have tried the approach. Reading books works for some people but most books go unread, or the words go in one eye and out the other.

Invest in taking the time to explain to people what Agile is – or at least what Agile means to your organization.  Today most techies have heard the word “Agile” but what they have heard, which bits they remember, and whether the result was good or bad differs. Teams need to start with a shared understanding.

But don’t stop there, make time for people to talk about what Agile is to them, what they like, don’t like, will do, won’t do. Agile is a team sport and unless the team have a shared understanding they will be playing different games. This discussion should start in the training sessions as the team forms their own, shared, understating.

6) Enthuse, Pull, don’t Push

Anyone who has worked around companies for a few years will have seen management pushing the latest change initiative: BPR, ISO 9000, Sig Sigma, CRM, etc. etc. Someone dreams up these ideas and then a change machine sets about pushing them out.

We live in a post-modern, post-BRP, post-layoffs, post-recession, post-everything world. Employees aren’t children they’ve heard what happens. Too often before management initiated change, especially that involving consultants, has involved redundancies. If you want to cut staff then cut them then move onto Agile.

Apply a lean principle: Pull, don’t push.

The moment someone uses the words “change management” you are in the world of push change so forbid the words “change management.”

If you are in management this means you need to engineer a pincer movement: you want enthusiasm for change coming from the bottom up to meet your support coming top down. Introducing Agile top-down alone is, in my opinion, quite likely to kill it - employees are rationally skeptical of top-down management change.

Seek to enthuse individuals and teams, have them ask for Agile. Rather than impose change from the top down managers need to build, kindle people’s curiosity, get people asking questions and for help, create bottom-up change initiative and support it.

Do everything build the fire without extinguishing it, and when they ask give them the help and support they need: sign-off book expenses, provide budget for speaker, trainers or coaches, say Yes to time for conferences. Give and give generously.

Plus, involve yourself. You need to learn too – even if you know it all you need to be there when the shared understanding is built. And you need to change too, learn to change your own behaviors to match.

7) Be clear on Why you are going Agile

What ever level you are, engineer, tester, project manager, director, look beyond the Agile hype. What is the problem you want “Agile” to fix for you? Understand why you want change and what you expect from it.

Don’t just “get Agile” because it is this month’s fashion, get “Agile” to achieve something more important.  Understand what individuals want from Agile, what they want to make their life better, and understand what the organization wants from Agile – innovation? Reliable schedules? Fewer bugs?

Ask you team, ask your manager, and ask “What do you think your manager wants?” If everyone stands to benefit from Agile then everyone will be willing to help with adoption. When people don’t see benefits change will be hard.

As your adoption proceeds you use these aims to choose your tools, optimize your processes and measure your success.

8) Process and technical, Adopt technical side as well as process side

Don’t think you can just change the process and it will all be all right. You need to address the technical side too, you need to improve quality, you need to support the engineers, testers and others who are at the code face doing the work.

I’ve come across big companies who view the technical side as somehow dirty: the attitude seems to be “that's technical” or “ they get their hands dirty” or “we can ship it to [Low cost country of choice this week]”. If this is your attitude you will fail.

Get your hands dirty, talk to engineers, adopt Test Driven Development, refactoring, shun big up front design architecture, learn to live with rough designs and evolving architecture. There are real feedback loops here.

9) Get requirements flow clear and clean

It isn’t just about fixing the coding side, the requirements side needs to be addressed to. Specifically there needs to be a clear path from someone who represents requirements - typically called a Product Owner or Product Manager and frequently staffed with a Business Analyst - and the development team. Far more negotiation is going to happen over “what” then “when”. Someone needs to represent - and have authority - over that side of things.

Too many companies understaff this role to begin with. Agile makes that understaffing acute. Bottlenecks in requirements will have a knock-on effect in development.
As a mental exercise as yourself: if Agile doubles developer productivity what happens next?

The answer is you need twice as much effort on requirements. O, at first you might just burn off a big backlog. But as you do so your marginal value delivered may well be declining.

10) Structural changes-Functional groups

Staff your teams to do the work for which they are responsible, end functional groups - i.e. database developers and UI developers in separate teams. This is just the first of more structural changes you will need to make. But if you fail at this you won’t get to play again.

Teams which have to call out to other groups for specialist skills or authorizations will block. Other groups have other priorities. Little impediments build up, each one slowing the team down, sapping morale and making your adoption more difficult.

Source: http://www.infoq.com/articles/ten-things-agile-adoption

A Beginner’s Guide to Big O Notation

Big O notation is used in Computer Science to describe the performance or complexity of an algorithm. Big O specifically describes the worst-case scenario, and can be used to describe the execution time required or the space used (e.g. in memory or on disk) by an algorithm.

Anyone who’s read Programming Pearls or any other Computer Science books and doesn’t have a grounding in Mathematics will have hit a wall when they reached chapters that mention O(N log N) or other seemingly crazy syntax. Hopefully this article will help you gain an understanding of the basics of Big O and Logarithms.

As a programmer first and a mathematician second (or maybe third or fourth) I found the best way to understand Big O thoroughly was to produce some examples in code. So, below are some common orders of growth along with descriptions and examples where possible.

O(1)

O(1) describes an algorithm that will always execute in the same time (or space) regardless of the size of the input data set.

bool IsFirstElementNull(String[] strings)
{
 if(strings[0] == null)
 {
  return true;
 }
 return false;
}

O(N)

O(N) describes an algorithm whose performance will grow linearly and in direct proportion to the size of the input data set. The example below also demonstrates how Big O favours the worst-case performance scenario; a matching string could be found during any iteration of the for loop and the function would return early, but Big O notation will always assume the upper limit where the algorithm will perform the maximum number of iterations.

bool ContainsValue(String[] strings, String value)
{
 for(int i = 0; i < strings.Length; i++)
 {
  if(strings[i] == value)
  {
   return true;
  }
 }
 return false;
}

O(N²)

O(N²) represents an algorithm whose performance is directly proportional to the square of the size of the input data set. This is common with algorithms that involve nested iterations over the data set. Deeper nested iterations will result in O(N³), O(N⁴) etc.

bool ContainsDuplicates(String[] strings)
{
 for(int i = 0; i < strings.Length; i++)
 {
  for(int j = 0; j < strings.Length; j++)
  {
   if(i == j) // Don't compare with self
   {
    continue;
   }

   if(strings[i] == strings[j])
   {
    return true;
   }
  }
 }
 return false;
}

O(2^N)

O(2^N) denotes an algorithm whose growth will double with each additional element in the input data set. The execution time of an O(2^N) function will quickly become very large.

Logarithms

Logarithms are slightly trickier to explain so I’ll use a common example:

Binary search  is a technique used to search sorted data sets. It works by selecting the middle element of the data set, essentially the median, and compares it against a target value. If the values match it will return success. If the target value is higher than the value of the probe element it will take the upper half of the data set and perform the same operation against it. Likewise, if the target value is lower than the value of the probe element it will perform the operation against the lower half. It will continue to halve the data set with each iteration until the value has been found or until it can no longer split the data set.

This type of algorithm is described as O(log N). The iterative halving of data sets described in the binary search example produces a growth curve that peaks at the beginning and slowly flattens out as the size of the data sets increase e.g. an input data set containing 10 items takes one second to complete, a data set containing 100 items takes two seconds, and a data set containing 1000 items will take three seconds. Doubling the size of the input data set has little effect on its growth as after a single iteration of the algorithm the data set will be halved and therefore on a par with an input data set half the size. This makes algorithms like binary search extremely efficient when dealing with large data sets.

This article only covers the very basics or Big O and logarithms. For a more in-depth explanation take a look at their respective Wikipedia entries: Big O Notation , Logarithms .

Source: http://rob-bell.net/2009/06/a-beginners-guide-to-big-o-notation/