Safe with Android Devices

am taking a chance here by discussing a topic such as this, and in particular taking the stance that I am taking. So, with that in mind, let’s just get down to business. As is usually the case with these sorts of things, we’ll start off with a disclaimer or two. Most importantly you must realize that these are my opinions and observations, and some of them might be wrong. Please feel free to let me know if you disagree with anything I say. Keep in mind also that I am not saying that rooting your device does not have its benefits, but rather that one must be careful. Now that is out of the way Hackers are in hot pursuit of Google's popular Android OS, according to recent news & reports. As mobile security threats are tiny compared to PCs, you still need to protect your smartphone, even more so if it runs Android. Here by we are trying to collect some tips for staying safe.

Take a deep breath. There's a new report out highlighting a huge spike in threats against Google's Android platform. Yes, it's something to be concerned about. But don't freak out or return your cool new Samsung Galaxy Tab. Mobile threats are rising, but actual attacks against smartphones and tablets are still a tiny fraction of the number of new threats that target your PC, and to a lesser extent, your Mac. And remember the law of big and little numbers. When a number is small, it doesn't take a huge addition to pack a big percentage change.

The news here is this: Malware targeting the Android platform jumped 76 percent in the second quarter of the year, making it the most popular target for makers of malware that attacks mobile devices, according to researchers at McAfee, the anti-virus and computer security company now owned by Intel.

The reasons for the spike aren't hard to discern. Hackers like to attack popular platforms, and Android phones are now outselling Apple's iPhones. In order of popularity with hackers, Android is followed by the fading Symbian operating system and Java ME. If you're alert, you'll notice that iOS is not in the top three; in fact it's not on McAfee's list at all.

To explain why, let's take a look at a report issued by Symantec, McAfee's major rival in the personal security business. In June, Symantec said: iOS's security model offers strong protection against traditional malware, primarily due to Apple's rigorous app certification process and their developer certification process, which vets the identity of each software author and weeds out attackers.

Google has opted for a less rigorous certification model, permitting any software developer to create and release apps anonymously, without inspection. This lack of certification has arguably led to today's increasing volume of Android-specific malware. Those points are essentially the same as what the McAfee researchers have to say about Android vs. Apple mobile device security.

How to Be Safe

Just because you're statistically unlikely to be killed by a lightning strike, that doesn't mean playing golf in a thunder storm is a good idea. Similarly, don't take my calming words as license to pay no attention to security for your Android device. Malware is out there, and it targets personal information that you really don't want some bad guy to get his hands on.

Here are some things you can do to thwart the hackers.

Use a security app designed for Android: Lookout Mobile Security is getting the best reviews I've seen. It's a free app (though there's also a beefier premium version) that does a number of things, including scan downloads for viruses. It also works as a phone tracker in case your Android is lost or stolen. Lookout has a Web site that will track its location. It also allows you to wipe your data remotely, lock the phone or set off an unpleasant alarm.

Finally, there's a Web site associated with the app you can use for backup.

Always check app permissions: Whenever you download or update an app, you are given a list of permissions for that app. If an app is asking for things it shouldn't need, get rid if it.

I must add that IMHO common users are overexposed to rooting. Basically, users do not pay enough attention to potential misdemeanor of freely available apps. When rooting, main question in people’s head is NOT to brick the phone, data security is not even on their minds.

Almost every website dedicated to Android has some kind of rooting information, tutorials, and/or news. I’m not saying that it’s bad. But when You take in to the account the basic users, it’s logical to assume that they will probably WANT to root their device, regardless if they really NEED it or not.

Hype about the rooting is just enough as a cause. With appearance of one-click-root apps the process has been stripped down to it’s simplest and almost anyone knowing how to click can root their device.

It seems to me that Android’s security system is solid one, but depends on user itself to make informed decision on what applications to install and what not to. Not paying the attention to the security notification when installing an app is just ignorant. If you want a password storage/encryption app,

and it requires Internet connection, shouldn’t You think twice? On the other hand if anti-virus warning pop’s up on Your’ PC’s desktop, do you ignore it or read what it says?

It all boils down to the fact that rooting does have advantages but users themselves MUST think really hard should they root their device, just like installing any other application/game from the market. And to conclude (I’ll probably sound like some manufacturer’s PR) but if it was (amongst other things) SAFE to have all the devices rooted initially wouldn’t they be?

I’m not sure about this next one but as from what I’ve read, every Android app runs in it’s own ‘sandbox’ thus effectively disallowing other apps to access it’s data, except if app ‘publishes’ it through public providers.

Don't install Android Package files: As our colleagues at PCWorld explained: "When Angry Birds first came to Android, you could only get it through a third party. This is called 'side loading' or, installing apps using an .APK file. While Angry Birds wasn't malware, it is highly advisable not to download and install .APK files that you randomly come across. Most of the time you won't know what the file contains until you install it. By then it's too late."

Bank with authorized apps only: Online banking and bill pay is a great convenience, but to be safe, only use apps supplied by your bank.

Rooting has a high chance to destroy data stored on the phone, and unless someone is completely OK with that, they should not go forward with rooting.

My suggestions only download popular apps: I know this sounds pretty stodgy. But there's a reason for it. Apps that have been downloaded a lot aren't likely to be poisoned. For that matter, they're likely to actually be worth downloading, if you believe in the wisdom of crowds, that is. Download from reputable publishers: If you're uncertain about an app, do a quick search under the publisher's name. If you find a number of apps with good reviews and lots of downloads, chances are you're dealing with a reputable outfit.

Keep an eye on your wireless bill: Some rogue apps do things like make expensive calls to foreign numbers in order to fatten the bank account of various intermediary sites at your expense. Often the calls happen in the background or at times when you don't realize your phone is doing something.

Don't dos,

As the more pervasive networked technology becomes, the more dangerous our common lack of security awareness will become. Eventually there will be a tipping point, a day of reckoning. Consider each of these things people commonly do:

1. Giving account credentials to Meebo.com so that you can use instant messaging more easily.

2. Giving account credentials to the likes of Plaxo and LinkedIn so that they can pull in all of your contact information from other providers.

3. Installing a tethering app from someone whose livelihood you have no serious ability to impact (ie you can seriously damage the profit of T-Mobile if you prove they did something malicious, but you cannot seriously harm developer X on the market who released AppY for free).

While this post covers most of the basic hacks that might become as common as a virus infected windows pc, it does not cover the extreme dangers that rooting may present. Hackers don’t have to stand a mile away with a laptop to steal your contacts, but what about the possibility of an application to steal the information off your company ID , any card? Or the ability to remote-brick your phone? Or turn your camera into a webcam while your phone is on your dresser pointing and you and your loved one bumping uglies. While these threats may sound far fetched, they are still threats. Or in typical IT way these are potential risks.

Think like a hacker, Study up before you perform any checks like a simple hacker. Try to learn what it does and what it can or might do. Never do your banking on you mobile device. Never store any passwords on your phone. And if you have any questions regarding an app that what’s some weird permissions, ask a the supplier / support or contact any developer forum / the dev of the program and an outside source/ they will be glad to help.

Agile Estimation Methods

The Cone of Uncertainty is a Project Management term used to describe the level of uncertainty existing at different stages of a project. We become more certain of our estimates as we learn more about what we’re estimating.

In Agile Project Management environments, we accept that software projects are ridden with uncertainty it comes with the territory. This uncertainty decreases as decisions are made around scope and approach the more we understand, the more certain we can be about our estimates.

To mitigate the risk of incorrect effort estimations we reduce the precision of our estimates according to how much we know about what we’re estimating. This in turn helps us to be more accurate.

Agile Requirements in order of Uncertainty

• Agile Theme
• Agile Epic
• Agile User Story
• Agile Task

Agile Estimation Techniques in order of Precision

• Hours
• Story Points
• T-shirt Sizing

Estimating in Hours vs. Fibonacci
As described in earlier post Software Estimation: The more precise you are, the less accurate you will be, studies suggest that estimates taking place during the Product Definition Phase exist somewhere between being 300% less and 0.75% longer than it actually took them to build the software i.e. out by a factor of x16. The cone of uncertainty narrows as you eliminate uncertainties.

In Agile environments, we use two main estimation metrics Fibonacci and Hours.

Estimation using hours is pretty self-explanatory, however it’s worth mentioning that Agile Teams only estimate Tasks in hours. By Tasks, I mean ‘parts of a User Story’ something very small that should take a couple of hours or so definitely no longer than a single day to complete. Because larger pieces of work are generally more complex and should/could probably be broken down into smaller component parts AKA there may still be a number of outstanding decisions that could affect the level of effort required to deliver the task. The larger the task, the lower the chances that you’ll be able to estimate the exact number of minutes/hours associated with delivering it e.g. Phone interruptions, toilet breaks, delayed meetings. In other words estimate SMALL things in time units.

Estimating in Fibonacci is the second Agile estimation metric - we call this Story Point Estimation. We use Story Points to estimate larger pieces of work i.e. User Stories and Epics. They work as follows:

0,1,2,3,5,8,13,21,34,55,89

In other words, a ’5 is 5x more effort than a ’1 and an ’8 is 8x more effort than a ’1.

Story Points can measure things we can’t measure in hours e.g. complexity do you include a task for every discussion you don’t yet know you need to have, every time you take 10 minutes out to Google an answer? It is however relatively easy (when you get started) to compare the size of one task/cluster of tasks with another task/cluster of tasks. Estimating in Story Points allows you to take into consideration all sorts of intangible ‘things’ that you sense but can’t quite put your finger on.

Estimation Using T-Shirt Sizes
T-shirt Sizing is also referred as an Agile Estimation method by many enthusiasts it’s used to estimate larger requirements i.e. Epics, but maybe the odd User Story also. In short, you attribute a number of story points to a t-shirt size that is for small it's X number of points an XXL might equal ’55 points’. T-shirt sizes are great for Product Owners and/or non-technical people as they’re totally abstract and non-threatening (that’s not meant to sound patronizing you know what I mean!). They’re easy to understand.

When estimating in T-shirt sizes, it’s still important to set your scale agree in advance what constitutes a ‘Small’, Medium, ‘Large’, XLarg and ‘XX Large’.

T-shirt sizing will normally take place at the Requirements Workshop this helps the Product Owner and Product Manager get a sense of scale, which will in turn help with the prioritization process. As always, the Scrum Team are the people that assign t-shirt sizes to Epics. The Product Owner and/or Product Manager are not allowed to participate in the estimation process they can offer insight and guidance but the estimations belong to the Scrum Team.

Estimation Using Story Points

Once the Epics have been estimated and prioritized for delivery, they will be broken down into User Stories by the Product Manager and Product Owner. The component User Stories will then be introduced at a subsequent requirements workshop and estimated in Story Points at Poker Planning.

Sprint Planning: Hours or Story Points , there is a lot of debate about whether to estimate sprint requirements in hours or to leave them in Story Points.
Mike is big on breaking User Stories down into tasks, which are then estimated in hours. Mike discusses this in his post: Why I don’t use story points for sprint planning.

Jeff claims that the best teams [he works] with burn down story points. They only burn down when a story is done.

Personally, we see pros and cons of both approaches but would use Story Points over hours where/whenever possible.

Mike claims that he doesn’t use story points for sprint planning because story points are a useful long-term measure. They are not useful in the short-term. I don’t agree with this statement as a whole. Story Points are indeed a useful long-term measure, however I believe they can also be useful in the short-term. When writing user stories, you should aim for each story to comply with the ‘INVEST’ acronym Independent, Negotiable, Valuable, Estimatable, Small and Testable. If each story is Small enough to be ‘accurately’ estimated, and Testable enough for one to create Test Confirmations then there may be little benefit achieved through breaking it down into smaller composite parts or re-estimating them in hours. In fact, back in the days when we were ’Doing Agile’, one of our teams used to create task cards with the words just do it written on them In this particular situation, the team were not benefiting from the time spent re-writing task cards and re-estimating the stories each story was taking no longer than 1-2 days to complete. We can baseline this for longer , efficient & better calibrations etc.

The main concerns we had when we initially discussed the idea of burning down in hours was that we’d not benefit from the early warning signs provided by the burn down and that we would only discover a story was taking longer than expected when it was too late.

The reality of the situation is that the team soon discovered their ‘Agile Heartbeat’ - in order to stay ‘on track’, they need to burn down +/- one story per day. Also, the team members generally know when something is taking longer than expected their communication is strong and they raise any concerns at the Daily Scrum.

With that said, if the team is less established, AND/OR if the stories are much larger AND/OR if the sprint duration is +/- 1 week or less then I’d be inclined to estimate in hours as they have the potential to provide a more granular progress snapshot.

I do agree with this point, in the sense that nothing is definite- you can’t be 100% certain that you’ll finish everything you commit to. With that said if a team has a velocity of 20 story points, aren’t they likely to commit to delivering +/-20 story points worth of stories in the next sprint? AND if they are true to their velocity, then surely they’ll deliver them will they not?

On the other hand, it is still important for the team to be comfortable and confident that they can deliver their commitments if they only accept 15 points one sprint then so be it. This discussion is about whether or not you can achieve the same end result burning down on story points vs. hours I think you can.

Value Points Estimating the relative value of a User Story

Value Points can be used to measure the relative value of User Stories using a Fibonnaci Sequence. Although not appropriate or particularly necessary in all cases, Value Points can help you to prioritize a product backlog and convey the relative importance of User Stories to a Software Development Team. This approach becomes increasingly useful as teams scale to cover multiple projects combined with Business As Usual activities.
If you are a Product Owner or a Programe Manager, you will be all to familiar with Return on Investment (ROI) models, Net Present Value(NPV) and Internal Rate of Return(IRR).
In short:

ROI measures how much money you will make off the back of an investment.
NPV measures the desirability of an investment compared to the minimum expected return over a pre-defined number of years.
Internal Rate of Return measures the percentage return of an investment after tax.

The traditional ROI model approach is useful when applied at a project level, particularly when attempting to measure viability and/or secure funding, however it is time consuming, requires business analysis skills and is wrapped up in a whole host of assumptions.

In Agile Software Development, we break projects down into Themes, Epics, User Stories and Tasks. We then define a minimum feature set (Minimum Marketable Feature(s)) and attempt to schedule development in a way that maximizes ROI early on.

So, what happens when you need to measure the value of a User Story? Do you produce an ROI model? What if there’s no direct financial return associated with the story? The reality is that this would be an unrealistic expectation due to 1) the time/effort involved and 2) the level of granularity that would be required.

So, what to do?

I started using Value Points in hopes to simplify the process of measuring relative value. This scale uses the standard Fibonacci Sequence: 1,2,3,5,8,13,21,34,55,89 as a metric.

In the same way that Story Points cannot be converted to Hours, Value Points cannot be converted to Financial Return. Because when we measure value, particularly across Business As Usual, there are so many reasons for doing something not all of them will offer an immediate financial return:

Strategic : if we don’t make this investment, we will no longer be able to maintain our market share
Compliance: if we don’t make this investment, we could be in breach of the law(s)
Revenue Generation : if we don’t make this investment, we’ll miss out on a chance of making X money
Risk Management : if we don’t make this investment X could happen to us e.g. stakeholder dissatisfaction etc.
Cost Avoidance: if we don’t make this investment, we could realize additional costs in the future
etc

Value Points can offer a useful tool to help with the prioritization process e.g. you can plot effort against value to maximize delivery of those stories delivering the highest amount of value for each unit of effort.

Value Points can also empower the development team to identify the most appropriate solution for a particular card e.g. the value’s low, so I’ll not spend as much time on it as one of the higher value cards.

I’ve created a Product Backlog Template that provides some insight into the health of your product backlog the idea is to pack it with as many low-effort/high-value stories as possible.

This template uses a simple formula to help you prioritize your stories:

Value Points - Story Points = Priority Points

It also allows you to do the following:
Assign stories to sprints (release plan) : Calculate the number of releases required to deliver your backlog based on your velocity Calculates how many sprints you can afford to deliver based on your project budget Plots your user stories on a chart based on Effort vs. Value

Re-estimating stories in hours usually comes down to estimating tasks that were identified for each story and as such they become at some point incomparable. So we lose the ability to use relative estimates as tasks fall into different types of activities. This way we need to think about hours required for each task individually and maybe comparing them to other tasks of the same type (like designing UI, writing JavaScript code, etc.) may help in estimating them. I would strongly recommend such approach because this way you can notice where your estimations are more guessing than really touching the true value (if the story point is very big it means that you have to break it into smaller ones).

Who makes those initial estimates? Product owner + team together? Initial Product owner then at contract stages the team must re-visit or re-estimate everything again.

When exactly to they produce those estimates? Before the 1st sprint? Estimation is a live document that is need to be reviewed constantly whenever the changes would likely impact the project plan, schedule. This will also mitigate the risks of scope schedule / creep.

Also to add, The number of story points that a team can complete (on average) in one sprint is known as their ‘velocity’. Before you start estimating stories, make sure that everyone agrees on what a 1 point, 3, point, 5 point (etc) story ‘looks’ like. Some teams will bring these examples along to their planning poker workshops as a reminder until they get used to their scale. So, for example, all 3 point user stories should on average take the same amount of effort to deliver. With that in mind, assuming each sprint has the same amount of effort available (same number of people in the office, with the same skill set (ideally the same people!), for the same number of days) then the same number of points will generally be delivered in the pre-agreed number of days. It usually takes a few sprints before a team can get a sense of their true velocity. This velocity then acts as a starting point for negotiation more or fewer points may actually be committed to depending on other influencing factors (e.g. team members on holiday etc.)

HTML 5 great way to start web developments

In this blog, we will discover some of the great new features that HTML5 has to offer.
Let me start with, HTML5 is exciting and anyone who builds web pages is looking forward to implementing these new tags into their sites. HTML5 audio tags are definitely one of the ones on the list meant to make life much easier for both webmasters and end users. Another of the most exciting buzz these days in web circles is about HTML5 and specifically video on HTML5. HTML5 video tag has solved the age old problem site owners and designers face on how to best embed video on websites.
HTML5 improves interoperability and reduces development costs by making precise rules on how to handle all HTML elements, and how to recover from errors. Some of the new features in HTML5 are functions for embedding audio, video, graphics, client-side data storage, and interactive documents. HTML5 also contains new elements like <nav>, <header>, <footer>, and <figure>. The HTML5 working group includes AOL, Apple, Google, IBM, Microsoft, Mozilla, Nokia, Opera, and many hundreds of other vendors.
Note: HTML5 is not a W3C recommendation yet!
We will start our learning with the new semantic elements that aim to give meaning to the various parts of a modern Web page: headers, footers, navigation bars, side bars, and so forth.
Next, we will learn about the important new <canvas> element and the 2D drawing JavaScript APIs that you can use to create shapes, text, animations, transitions, and more. Following this, you will see how the new <audio> and <video> elements intend on replacing the Web's current dependency on Flash as a multimedia delivery platform.

Next, we will be introduced to the local storage APIs and offline applications support that will further bring Web applications in line with their desktop counterparts in terms of functionality, even when not connected to a network or the Internet. This section is wrapped up with a brief overview of the other new elements, attributes, and APIs that are proposed in the current HTML5 specification.
The HTML5 specification includes a series of new semantic elements that is used to give some meaning to the various sections or parts of a Web page, such as a header, footer, navigation, and so on. In previous versions of HTML, we would typically use <div> elements to create these parts, using ID or class attributes to differentiate them from each other. The problem with this is that this has no semantic meaning, as there are no strict rules defined that specify what class names or IDs are to be used, making it extremely difficult for software to determine what the particular area is doing. HTML5 should help alleviate these issues, making it easier for Web browsers to parse the semantic structure of a document.
It is worth pointing out that continuing to use <div> elements in HTML5 is perfectly valid, but in order to future-proof our work, it is recommended that we use semantic elements where relevant. On the other side of the coin, it is also suggested that we avoid using these new elements for purposes other than their intended. For example, the <nav> element should not be used for just any group of links; it is intended to surround the main navigation block on the page.

The main semantic elements that HTML5 introduces are:
<header>
This element is used to define a header for some part of a Web page, be it the entire page, an <article> element, or a <section> element.

<footer>
Like the <header> element, this new element defines a footer for some part of a page. A footer does not have to be included at the end of a page, article, or section, but it typically does.

<nav>
This is a container for the primary navigation links on a Web page. This element is not intended for use with all groups of links and should be used for major navigation blocks only. If we have a <footer> element that contains navigation links, we do not need to wrap these links in a <nav> element, since the <footer> element will suffice on its own.

<article>
The <article> element is used to define an independent item on the page that can be distributed on its own, such as a news item, blog post, or comment. Such items are typically syndicated using RSS feeds.

<section>
This element represents a section of a document or application, such as a chapter or a section of an article or tutorial. For example, the section we are reading now could be surrounded by a <section> element in HTML5. <section> elements typically have a header, although it is not strictly required. The header for the section we are reading now would contain the text "Semantic elements," for example.

<aside>
This new element can be used to mark up a sidebar or some other content that is considered somewhat separate to the content around it. An example of this might be advertising blocks.

<hgroup>
In some cases, a page, article, or section may require more than one heading, such as where we have a title and a subtitle. This tutorial, for example, has the title "Create modern Web sites using HTML5 and CSS3" and the subtitle "Implementing the canvas and video elements in HTML5." We could wrap these in an <hgroup> element, using an <h1> element for the main title and an
<h2> element for the subtitle.
The sample Web site at the end of this tutorial includes several of these new semantic elements, and I will explain their syntax and use in more detail at that point.

<canvas> element
The <canvas> element was originally developed by Apple® for use in Mac OS X Dashboard widgets and in Safari, but was later adopted by Mozilla® and Opera® in their Web browsers. The element has been standardized and included in the HTML5 specification, along with a series of 2D drawing APIs that can be used to create shapes, text, transitions, and animations inside the element.
Many believe that the <canvas> element is one of the most important aspects of HTML5 as it facilitates the production of graphs, interactive games, paint applications, and other graphics on the fly without requiring external plug-ins such as Adobe Flash.
The <canvas> element itself is quite basic, defining the width, height, and unique ID for the object. The developer must then use a series of JavaScript APIs to actually draw objects on the canvas, typically when the Web page has finished rendering. These APIs allow the developer to draw shapes and lines; apply color, opacity, and gradients, create text; transform canvas objects; and perform animation. The APIs also allow the <canvas> to be interactive and respond to user input such as mouse events and key events, facilitating the production of games and Web applications on the canvas. We will see an example of the <canvas> element in action in the sample HTML5/CSS3 Web site later in this tutorial.

Playing <audio> and <video>
In recent years, the popularity of video sharing sites such as YouTube and content delivery platforms like Hulu has seen a huge explosion in the use of the Web for multimedia streaming. Unfortunately, the Web was not built with such content in mind, and as a result, the provision of video and audio has by and large been facilitated by the Flash Video (.flv) file format and the Adobe Flash platform.
HTML5, however, includes support for two new elements, <audio> and <video>, which allow Web developers to include multimedia content without relying on the user to have additional browser plug-ins installed. Several browsers, including Mozilla Firefox, Apple Safari, and Google Chrome, have begun supporting these new elements and providing standard browser playback controls, should the user choose to use them. In addition, a set of standard JavaScript APIs has been provided to allow developers to create their own playback controls, should they wish to do so. A key advantage to native multimedia playback is that it theoretically requires less CPU resources, which can lead to energy savings. A key issue with these new multimedia elements, however, is the file formats supported by each browser and the patent licensing issues that go along with the various codecs that these files can be encoded with. Mozilla and Opera want to use the open source Theora video container and codec, which does not require patent licensing for the inclusion of the codecs in the Web browser. On the other hand, Apple and Google are not happy with the quality of Theora, particularly for the delivery of high definition (HD) content on the likes of YouTube. They prefer the H.264 codec, typically contained in MP4, MOV, or MKV files.
The issue is not just with video however, as the same problems reside with audio codecs. The MP3 and AAC formats are restricted by patents, whereas the Vorbis format is not. The problem with Vorbis audio is that it is not in widespread use, as portable media players and many media software applications do not support it.
There are many decisions to be made about HTML5 <video> and <audio> in the near future, and it will be interesting to see what codecs and formats are facilitated in the final recommendation. In the meantime, we can try to support all browsers by making video available in a variety of formats and by providing Flash video as a fallback. Let's hope that a final decision is made, and that it is not left to browser vendors to decide which formats to support, as that would essentially render these new elements useless.
Web developers have traditionally used cookies to store information on a visitor's local machine, allowing a Web page to read this information back at a later point. While cookies are very useful for storing basic data, they are limited by the fact that Web browsers are not required to keep more than 20 cookies per Web server or more than 4KB of data per cookie (including both name and value). In addition, they are sent to the Web server with every HTTP request, which is a waste of resources.
HTML5 provides a solution for these problems with the Local Storage APIs, which are covered in a separate specification to the main HTML5 document. This set of APIs allows developers to store information on the visitor's computer while remaining reasonably confident that they will still be there at a later date. In addition, the information is accessible at any point (even after the page has rendered) and is not loaded automatically with each HTTP request. The specification includes same-origin restrictions, which prevent Web sites from reading or changing data stored by other Web sites.
Most browsers store Web pages in local cache, allowing them to be viewed even if the user is offline. This works fine for static pages, but it is not available for dynamic content that is typically database-driven, such as Gmail, Facebook, or Twitter.

HTML5 provides support for offline applications, where the browser downloads all the files necessary to use the application offline, and when the user uses the application offline, the browser can allow any changes made in the process to be uploaded to the server when they reconnect to the Internet.

HTML5 includes so many new features; it's impossible to cover them all in this tutorial. This section provides a brief overview of some of the other enhancements in the specification.

Web worker
This allows JavaScript code to be set to run in a background process facilitating the development of multi-threaded applications. The chief benefit that Web workers offer developers is that intensive calculations can be processed in the background without adversely affecting the speed of the user interface.

Geolocation
HTML5 includes a geolocation API that allows a Web application to determine our current geographical location, assuming the device we are targeting provides features for finding such information (for example, GPS on a cellphone). If we do not have a device that supports this feature (such as an iPhone or an Android 2.0-based smartphone), we can use Firefox and download a plug-in that allows we to set our location manually.

Drag and Drop
Another interesting feature is the inclusion of a drag and drop API. Up until now, implementation of drag and drop without plug-ins was dependent on some very complex JavaScript or the use of a JavaScript library such as script.aculo.us.

Cross-document messaging
This allows documents in different windows (and iframes, for that matter) to send and receive messages to one another. This feature could prove very useful for the development of widgets and applications that are hosted on servers other than the primary Web page's server (similar to Facebook applications).

And more
Other new features introduced by HTML5 include MIME types and protocol handler registration, so Web applications can be registered as the default application for a particular file type or protocol; browser history management, which until now needed to be implemented manually or using an external JavaScript framework; and a host of other new elements and attributes that make Web developers' lives easier.

Let’s learn about the more enhancements in next blog. Till then please share your suggestion at ravindrapande@gmail.com

HTML5 advantages functionalities part 1

Top Challenges in Project Management

I was helping plan and implement a Web-based project management system for one of my clients, a global construction company, presented a number of challenges. One of the main challenges was developing a system that would allow the sharing of hundreds of thousands of documents among teams stationed around the world. While the organization considers the new Web-based project management system a success, the project did have its difficulties along the way. As with any other project, there were pitfalls to avoid and a learning curve to follow. Here are some of the challenges we faced, along with advice on how you can avoid some of the same problems. I am just trying to start to build a list here.

Balancing all the elements of a complex assignment - time, money, scope and people - is the project manager's job. Excellent PM training is essential to successfully dealing with the unexpected challenges that come with every plan. Following is an overview of the top 10 PM challenges that PMs may encounter on the job. I know this is well beaten track but I want to start giving current view & scope.

Naturally, there are many more project management challenges than stated here. However, these are the most frequently voiced by teams from a myriad of industries. If you are experiencing one or more of these challenges, then your team may benefit from implementing a project management software system. I will say this is a start & even I would like to collect these data point & prioritize on scenario, situation basis. Suggestion are welcomed to make this better.

Resource utilization : This is a key for success, project teams often complain that they do not have accurate or up to date information about their resources and what they are working on. Many project teams have more demand for projects than they have team members to execute the projects. Many project teams solve this challenge with a combination of meetings and either Excel or Microsoft Project.

For example, some teams meet once a week to determine what each person will work on. This can work, however, it depends on the pace of the work environment. One interactive agency with a very fast pace of work and lots of daily changes to the work schedule lost hours and hours of productivity as team members were only given assignments once a week.

Teams without centralized project management software often talk about using an Excel spreadsheet to manage workloads. Yet many state that it is a cumbersome exercise. Project managers benefit from leveling a single project in Microsoft Project. However, project managers utilizing desktop software may have a challenging time understanding how much work each resource has been allocated to across all projects.

At best, project managers using Microsoft Project’s resource pool can level resources across multiple projects. Yet, many project managers, even PMP certified project managers, find the resource leveling features of Microsoft Project to be dangerous. A commonly stated problem is that the projects’ timelines are extended beyond an acceptable timeframe, so many project managers abandon using the resource leveling functionality.

Time Wastage: For example simple task like looking for project documents and assets can kill critical time required for success. All projects have files, documents and assets that pertain to the project and tasks. Project assets can include project scope documents, risk lists, issues lists, files, emails, and deliverables, to name a few. Most project teams are sharing files on networks. The challenge with even the best file storage systems on the internal network is that team members still complain that they cannot find critical documents. It is simply too easy to forget where those assets and files are, unless they are frequently used.

The other problem with this is that usually third parties or those the project team needs to collaborate with outside one’s four walls (and network) cannot access these files. Many organizations do not permit third parties to VPN into their network for security reasons. This means that the project manager must resort to emailing those assets to these outside team members, which again can result in the version control.

A Web-based project management software solves these issues by posting all project assets in the centralized repository. The solutions that link documents repositories with the project they pertain to make finding the specific assets easy for the team members. An even more robust solution will permit team members to post assets at the task level, not just the project level.

Geographically dispersed project teams : Current new challenge. Many project teams are geographically dispersed. Projects are inherently collaborative efforts. The very nature of projects is such that project teams are usually comprised of multiple team members. Often, project teams incorporate multiple organizations. Team members can not only be employees, but also clients, vendors, sub-contractors and other third parties. Sometimes the entire project team belongs to the same company or organization, yet they often work from different offices either within the U.S. or globally. Even if the project team is in the same office, in today’s fast paced economy, information needs to pass as rapidly as possible, making a centralized project management software solution imperative. As the rise in outsourcing work and offshore development continues, project managers and executive management need to synchronize their work across multiple time zones. So, when the U.S. based team goes to sleep, and the team in Asia goes to work, they may login to the web-based project management solution to view their project, resource and task status. Companies that manage this asynchronous process well are excelling compared to their competitors. Also, clients are demanding more visibility and transparency into their projects’ progress. Client-facing project teams that possess a collaborative software system to interact with their customers are selling this as a competitive advantage and winning business over their competition.

Wrong tool for the job :Many companies attempt to manage projects using desktop software applications like Microsoft Project and Microsoft Excel. The main challenge with using desktop software to manage projects is that these applications were not designed for collaboration among several parties. At worst, the file is shared by emailing the file to all parties on the team. At best, the file may be posted on a network or on an extranet and shared from there.

One typical scenario that arises from using desktop software for project management is file ‘version control.’ For example, a project manager may email a Microsoft Project file to share project information to the team. If the file is updated frequently, then it can often be confusing as to which version of the project is the most recent one. Many times, the project manager will be conversing with an executive about a project and twenty minutes into the conversation find that they are both viewing two different versions of the project. Another issue with using desktop applications is that the minute they are emailed to the project team, the project data is outdated. That is, the information is not available in real-time. Projects are inherently dynamic efforts that change by the hour and sometimes minute.

A project management solution that is 100% web-based solves these issues by allowing project managers and their team members to access project information from any browser in the world, at any time of the day or night. The project information is centralized in one database and posted in real-time, assuring that all project members and executive management can view the most recent information about the project.

Excessive status reporting: Many project team members complain about spending too much time in meetings to update project status. No solution is ever going to replace the need for human communication and meetings. However, many teams talk about wasting too much time in meetings where everyone goes around the room and updates the project manager on his/her tasks. This is a very traditional way to getting status updates.

Another common model for updating project status is the project manager asks each team member individually where their tasks stand. The problem with this model is that the project manager becomes a ‘glorified administrator,’ and spends time updating the Microsoft Project file or Excel file. Instead, project managers could be managing more projects or thinking about higher level project concerns.

A web-based project software solution permits each team member to report back on project tasks and activities throughout their working day instead of relying on status meetings, or asking each individual for an update. The beauty of web-based

solutions is that each team member is empowered to report back on his or her tasks, pushing the responsibility back where it belongs, to the team member. To add to this we have developed a in house web based time sheets system attached to our web portal which can also linked to the bug reporting system to understand the effort wastages etc & build the traceability required.

Unclear Goals: When goals are not clearly identified, it is impossible for the team to meet them. And, since upper management cannot agree to or support undefined goals, the plan in question has little chance of succeeding. The manager must ask the right questions to establish and communicate clear goals from the outset.

Measurement problem: For some team members using the new system, benefits appeared to be marginal. This effect was the result of a measurement problem. How did we measure benefits? The team needed to compare the old process with the new one. We had to devise a mechanism that measured the effectiveness of the new system in terms of resource usage, availability of reliable and timely information, and project controls. Some of the things we looked at included:

• The ability to consolidate multiple project plans.
  
• The average time a major, outstanding issue remained opened.
• The extent to which team members and project managers maintained their own separate schedules.

Many of the parties involved in the project did not have a clear definition of productivity. For example, for team members paid by the hour, reducing the number of hours required to do a job was not an attractive option unless there were balancing considerations, such as competitive pressures. Only the owners of the company were clearly motivated to do more with less. However, the owners were not the main users of the system.

Scope creep: The oldest & quite promising :-(. Too many scope changes & non agility in project execution methodologies, this phenomenon occurs when the plan's scope to extend beyond its original objectives. Certainly, clients and supervisors will ask for changes to a plan - but a good PM will evaluate each request and decide how and if to implement it, while communicating the effects on budget and deadlines to all stakeholders.

Inadequate Skills: A plan sometimes requires skills that the plan's contributors don't possess. Training can help a leader determine the needed competencies, assess the available workers and recommend training, outsourcing or hiring additional staff.

Risk Management short comings : Learning to deal with and plan for risk is an essential piece of PM training. And risk tolerance is a desirable project manager trait - because plans rarely go exactly according to plan. Gathering input, developing trust and knowing which parts are most likely to veer off course are all aspects of the PM's job.

Ambiguous Contingency Plans: It's important for managers to know exactly what direction to take in pre-defined "what-if" scenarios. But if those contingencies are not identified, the entire project can become mired in an unexpected set of problems. Asking others to identify potential problem areas can lead to a much smoother and more successful project.

Lack of Accountability: A PM's leadership qualities really shine when each member of the team takes responsibility for his or her role in achieving success. Conversely, a lack of accountability can bring an activity to a complete halt. Finger-pointing and avoiding blame are unproductive - but all-too-common - features of flawed management. Learning to direct teams toward a common goal is an important aspect of training.

Unhealthy Communication: Managers provide direction at every step, so each team leader knows what's expected. Effective communication to everyone involved is crucial to its successful completion. The major task delegation happens thru this communication channels which can be daunting many times. Communication to clients / stakeholders or reporting can kill the best performers many times.

Resource Deprivation: To be run efficiently and effectively, management must provide sufficient resources - human, time and money. Training shows how to define needs and obtain approval up front, and helps project managers assign and prioritize resources throughout the duration.

Planning is key: Impossible deadlines can add many challenges than we can sort out. A strong leader - and successful project manager - knows that repeatedly asking a team for the impossible will result in declining morale and productivity. The odds of successfully completing a project under unreasonable deadlines are not very good.

Refusal to use the system : We underestimated the high level of commitment and loyalty that some users had to the tools and techniques that were already in place, a factor that was apparent when some legacy tools and techniques conflicted with the new system. It took a considerable amount of time to convince several individuals about the benefits of adopting our new Web-based project management framework.

In spite of all the training efforts and directions from upper management to utilize the system, a few team members refused to use it. There were several causes for this problem. First, the implementation was taking place in the middle of a project, and the team members did not have time to learn new tools. Second, the team could not visualize the benefits from using this new system and were not willing to invest the time and effort to learn it. Third, in the beginning, management mandated the use of tools but failed to follow up with enforcement. In addition, we had to refocus training on how to perform job functions using the system—nobody wanted to take time away from work to learn something that wasn't directly relevant to his or her job. The primary lesson we learned is to introduce the system to the participants before project planning begins, as it is much more difficult to switch to a new system than to begin with a new one.

End user resistance is a fact of life and should not come as a surprise to anybody involved in implementing a new system in an organization. No matter how good the new system is, most people have a built-in inertia that cannot be convinced by arguments alone. For example the existing system can reward people in ways that all users know, but are afraid to admit. They will point out seemingly irrelevant problems in the new system, because it lacks the "hidden" rewards of the current system. Another often overlooked fact is that many people simply cannot understand the value of a new system in abstract terms or concepts. They have to work with the system before they "understand" the added value. The people I have found to be most resilient to change are programmers. It is unbelievable how much energy you have to put into getting a programmer move away from their favorite toys and move on to something that is more in line with current developments. Many programmers are resilient into understanding that a system not only consists of automated processes, but also have manually processes that form the interface between the organization and the automated system. Regardless the fact that this is known for about 40 years most programmers simply ignore it and focus on technology alone ignoring the value of usability and end-user acceptance.

Lack of Stakeholder Engagement: A disinterested team member, client, CEO or vendor can destroy a project quickly. It's like having a distracted paddler in a two-person canoe - you might get to the finish line, but not efficiently or on time. And you'll waste a lot of energy in the process! A skilled PM communicates openly and encourages feedback at every step to create greater engagement among participants.

Critical success factors : I believe that success in the implementation of a Web-based project management system was due to the following factors:

• The appropriate selection of technologies, tools, and techniques to support the analysis, design, development, implementation, and maintenance of the tool
• Senior management support and commitment to the tool
• Extensive training that focused on task completion
• The organization’s readiness, willingness, and ability to work in a Web-based project management environment, including assessing/adapting the organization’s people, technology, work environment and culture, systems, and processes

I believe this is more than required for theory now let’s dwell more on how to implement this.

Web App Security Step by Step :Part II

Web / Application Security how to Step by Step :Part II

As we have discussed in the last Blog about web security identification & importance now we are taking a step further on implantation. First we need to understand the vulnerabilities from the network / networks & build a scanning process to review these vulnerabilities on periodic basis depending upon the criticality of the application , domain, system etc.

Step 1: identify, priorities and categorize web applications

With enterprise applications, you need to itemize all systems and categorize them before conducting security audits. Web application threats are no different – you must identify all web applications for testing and decide on their relative priority of importance for assessing remediation. Tools include automated scanners that do most of the work for you. The undeniable fact is that a machine can do some things efficiently than us humans in repetitive jobs.

Step 2: Scan everything for threats & vulnerabilities Scanning is an automated process that tests items for security as measured by a dynamic database of known vulnerabilities and likely exploits. A web application scanner includes simulated attacks against each web application. The object is to see if it breaks.

Step 3: Verify vulnerabilities against a register which also maintains a scenario log to check the impact factor like risk registers in project management This step helps to reduce false positives and false negatives, which can lead to inefficiencies in the VM process. False positives inhibit some scanning by drowning the scan results with vulnerabilities that don’t match what’s in your inventory of network and IT assets and web applications. Chasing down false positives is a waste of IT staff time and an inefficient way to do the management. Likewise, a false negative may occur when the scanner fails to detect a vulnerability that actually exists or we might miss an impending threat in the device or application. This failure to detect actual vulnerabilities may place your applications at serious risk of exploitation by hackers.

Step 4: Classify and rank risks: Fixing everything at once is practically impossible. In fact, in large organizations, the amount of vulnerability data can be huge & increasing as good proportion so if it’s not properly categorized, segmented, and prioritized in a meaningful fashion. This defines the most critical issues that could impact the most critical applications – all the way to items of lesser importance. In a nutshell, you need to decide what to fix first.

Step 5: Test all bug-fixing , updates and workarounds before integrating to the web site / application. Patches and workarounds are usually meant for insecure networks and systems, but they apply equally to web applications. If an application is vulnerable, it must be fixed. Updates, patches, fixes, and workarounds are usually administered by security and IT team members. Fixing actual code requires the work of programmers as guided by the in-house development team. Once a fix is devised, the team must thoroughly test it before re-deployment.

Step 6: Apply patches, fixes, and workarounds Here’s where the repairs are applied to vulnerable web applications and other assets.

Step 7: Rescan to verify patching After conducting steps for remediation, it’s useful to re-scan the web application to ensure it was fixed. This step verifies that the fix worked and that it doesn’t cause other applications, network devices, services, or other applications to be exposed to additional vulnerabilities.

Step 8: plan a audit cycle to understand the changed scenarios & priorities to be incorporated in these vulnerabilities management cycles. Simply using IT policy compliance products for continuous control monitoring of web applications, for example, doesn’t automatically make audit issues go away. But use the right tools under the right policy framework, stay consistent, and keep your reports, and you can greatly reduce the amount of money you spend every year in audit!

It goes without saying that specifications for a web application security scanner vary depending on the needs of each organization. Traditional considerations include whether you should go for an Open Source (‘free’) solution, or purchase a commercial scanner from an established software company. Another consideration is whether to run a software solution on your own infrastructure, or to rent its functionality with

Software-as-a-Service. Let's have more to say in next Part about the advantages of SaaS. Meanwhile, what else should you look for in a scanner? We answer this question in greater detail in Part III, where we also describe the practical ins and outs of using a web application scanner.

Web application scanners automate the manual techniques that hackers and security researchers alike employ against websites. They range from simple scripts that may simply search HTML content for useful information, to more complex tools that spider (that is, discover and crawl through) a

website and catalog its content for further manual analysis. The scanner acts like a hacker, albeit one less antagonistic towards the web application. As with any technology, it’s useful to consider what to look for in choosing the right web application security scanner.

Let’s ponder more what a web application security scanner should do for us. As per my thought process a minimum standard suggests that a web application security scanner should:

Must have :

1. Identify specified types of vulnerabilities in a web application.
2. Generate a text report indicating an attack for each identified vulnerability.
3. Identify false positive results at an acceptably low rate.

Good to have

1. Produce a report compatible with other tools.
2. Allow particular types of weaknesses to be suppressed by the user.
3. Use standard names for weakness classes.

The top priority for a scanner is helping you keep on top of the constantly changing universe of web application vulnerabilities. In particular, your scanner must be capable of identifying the top vulnerabilities such as cross-site scripting and SQL injection. Our scanner will provide more value if it incorporates standard industry resources for this information.

I am still compiling this day by day also got help from various comments by mail to understand specific pain areas in detail, please share your concerns or any threat I missed in this. You can write to me at ravindrapande@gmail.com