Unlike some of those fervent Agile proponents who think the Agile process is "the end all and be all" solution of our IT ills, our approach to IT process improvement is based not on some vague process improvement for the sake of process, but on an organization's business needs and goals—the only condition for any process improvement effort to have a measurable and lasting success.



Step 1: Identify the Business Sponsor and Her or His Needs and Goals

As long as we recognize that the main objective in building software is to support a business, it will become obvious that for a software delivery improvement program to be successful, we have to link it to some specific business goals. This is the reason why the first step is to identify the owner of these business goals for whom you are supposed to implement this IT improvement effort.

Identify the Business Sponsor
Knowing whose business goals this IT effort is supposed to help achieve will help you identify the goals that will drive your improvement effort, as well as determine the metrics you should use to measure your achievement.

Identify Business Problems and Issues
Whether the idea to improve software delivery capability comes from within IT or from the business, it will always address some business problems and issues, which the business sponsor tries to solve.
For illustration purposes, examples of problems or issues that have to be corrected can be one of the following:
- Complaint that software delivered does not meet requirements, to better serve the company's customers
- Complaint that the software delivered contains a very high number of bugs, which make the customers' experience very unpleasant
- Complaint that it takes too long to deliver software while the competitor usually brings out new software in half the time
Identifying specific problems like these will help identify business goals and their measurements that help lead the IT improvement effort, which we address later.

Identify Business and IT Goals
Business goal:
Increase the number of customers who visit our website by 5%.
IT goals:
It should take the customers less than 1 minute to register their information.
The number of bugs should be reduced by 50%.
Business goal:
Increase the number of newly registered customers by 3% every quarter.
IT goals:
Project deadline should be reduced by 10%.
Key features should be delivered 10% times faster.

Identify Measurements
From the previous list of goals, we can identify the following as their respective measurements:
Number of unused features by users
Variance in delivery timeline



Step 2: Perform Environment Boundary Identification and Assessment

Even though the title of this book mentions IT-wide improvement, this does not mean that the whole IT department is going to be the object of an immediate and big-bang rollout. Rather, what we have seen work in the majority of cases is a phased implementation strategy that progressively takes the IT organization from an unsuccessful situation to a controlled state where the IT project is well undertaken and delivered. For this, what you will need to do first is to identify the boundary of organization that will be impacted by this IT-wide implementation.

Identify the Boundary
To do this, first meet and ask your business sponsor for the environment under her or his direction that will be the target of this IT improvement effort.

Environment Assessment
After identifying the boundary, contact everyone who will be impacted by the improvement effort, on both the business and the IT side, to find out what they think about the current situation and to gather suggestions and ideas that could help facilitate their buy-in for the success of this IT implementation effort.

Findings Summary
Because the result of the assessment could be lengthy, you are advised to sum up the findings in some sort of executive summary. Doing this will help facilitate both the discussion with the executive sponsor(s) and your own vision of what the future solution should address, in terms of key improvements from the current environment.



Step 3: Envision Scenarios and Risks

Before selecting one (best) improvement plan, experience has led us to believe that having two or three scenarios (options) is always something we would like to first come up with. Not only does this give top management and some key leaders an opportunity to see which scenario will address most of their needs, but it also provides them with an opportunity to provide input. This will, then, in turn allow them to take ownership of the solution as theirs and not that of an outsider.

In building these scenarios (options), please also remember to identify all the risks that are associated with each one of them. You should carefully point them out to the management team to ensure that they are fully aware of their impact on the future implementation.



Step 4: Detail the Chosen Action Plan

Once management and some of the key leaders have had the opporutnity to go through the pros and cons of the various scenarios (options), ask them to chose one of these scenarios or a combination of them to create a single plan from which to implement the improvement effort.



Step 5: Implement the Chosen Action Plan

Once the plan has been detailed and presented back to the management team for review, it is time to get prepared for execution.

Depending on what section of the business will be impacted by the chosen plan, the composition of the steering committee to follow up on the execution will be essential. The key thing is to make sure that the committee has access to up-to-date and accurate information for their understanding and help with removing impediments.

As the late management guru Peter Drucker often said, "Strategy is execution." What this means, in our case, is that having a plan is a good first step, but knowing how to execute it is what counts the most.



Step 6: Inspect the Implementation's Progress

As the popular saying goes, "A plan is only a plan." This is to say that we should expect some deviation from the chosen plan when it comes time to execute it. This is also to say that it is key to continuously inspect the execution's progress and remove impediments to help keep it moving.



Step 7: Adapt the Chosen Action Plan (as Needed)

While inspecting the plan's progress, you may need to make adaptations to the plan to make adjustments to the changes in the organization and surrounding business environment, depending on the level and nature of their impacts.

• 0 comments »

Although these acronyms and the constant evolution of cellular and wireless network technology
can be baffling, the important thing to understand is that a variety of networks are used to provide data connections to your users ’ devices. As with the physical and diversity - related challenges of the devices themselves, you need to be cautious about assumptions for these connections.

Speed or throughput of the network connection is an obvious constraint. At the end of 2010, according to Akamai, the average fi xed - line broadband speed in the United States was 5Mbps,
many factors faster than even the theoretical peak speed of most mobile networks. This has a direct impact on the users ’ Web experience because it defi nes the minimum time that an uncached web page takes to download to a device. You ’ re probably not surprised to read that many mobile devices also do not have comprehensive or long - lived caching capabilities, thanks to their memory constraints.

A user with a 3G UMTS connection in the United States might expect an average download speed of 250Kbps, and 750Kbps on HSDPA (although such speeds are drastically affected by movement and the density of other data users in the local area). Even this is six times slower than a typical wired desktop experience: A web page containing a 1Mb video fi le might load in 2 or 3 seconds on a desktop, but it would take at least 15 seconds on a fast mobile network. That may be longer than an impatient user on the go is prepared to wait for the download. If you expect to deliver rich media to your mobile web users, you certainly need to look at limiting or adapting fi le sizes.

In addition to pure speed, other factors significantly affect the impact of the network on the user
experience. One is the setup time for the data connection itself. A desktop or laptop computer
usually has a persistent connection to the Web, and the fi rst page visited by a user starts to
download immediately. Most devices, on the other hand, connect on demand (in order to preserve power when the data connection is not in use), and this can add as much as 5 to 7 seconds to the time for the first page to be requested. Your users may already be impatient by the time your page even starts downloading.

A more persistent but often overlooked consideration is that of roundtrip latency. This is a
measure of the time taken for data packets to proceed from the device, through the network, to
the destination service, and back again, although excluding the time actually taken for the server
to perform any processing. This is influenced entirely by the type and topology of the network, the route the packets take, and any intermediate proxies or gateways that process the data en route.

On a fixed - line ADSL connection, latency is so low that it is barely considered. Regardless of the throughput speed, a ping time of less than 80 milliseconds to most web servers can be assumed from within the United States, and at most a few 100ms to internationally hosted servers.

On a mobile network, however, latency is a real consideration. This is partly because packets
sent from a mobile device to a public web server traverse a number of sub - networks and their
boundaries. First, there is the cellular air interface to a nearby cell station — which has a
particularly significant impact on latency — then a backhaul link to the network carrier ’ s switching center. Then there is a sequence of gateways that connect the traffic, often through firewalls and proxies, to the Internet, and then finally the packet proceeds through web infrastructure to the server. The effects on latency can be significant.

AT & T quotes a latency overhead of between 100ms and 200ms for requests to servers immediately external to their current UMTS and HSDPA networks, and 600ms over their GPRS and EDGE networks. While this is impressive, given the complexity of the cellular network involved, you should still expect the latency of a typical browser - to - server - to - browser roundtrip to be an order of magnitude longer than for a broadband connection.

In some respects, latency is more important than the raw throughput of the network, and this is particularly true for web applications, where a page is made up of a large number of component
parts. The request for each graphic, each style sheet, and each external script is delayed by the latency of the network, and if those objects are small, this can easily dominate the total time taken for the page to fully download. Web developers can take real action to mitigate these effects, such as combining CSS files, using sprite techniques for interactive images, and tuning cache settings for external objects.

Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal

• 0 comments »

As you might imagine, the networks responsible for bringing content and services to a mobile device are also notably different from the networks to which you connect laptops and desktops. Many contemporary mid - and high - end mobile devices include WiFi data connectivity, and when used in that mode, the device is connecting to a local access point, which, in turn, is most likely connected to a regular broadband - grade connection. In this case, the network connection for the device is fast, reliable, and low in latency — just as it is for the other computers and devices that are connected through the same access point and service provider.

But leave the limits of the hotspot, and your mobile device needs to revert to the cellular network for its data connection. At this point, the behavior and characteristics of the connection can change dramatically. A responsible web developer needs to be aware of these likely characteristics — and how the device mitigates them — in order to ensure that the user still retains a pleasant experience.

Throughout the world, a small number of prevalent cellular and mobile data technologies are in
regular use. The most widespread, by both geography and number of users, is the Global System for Mobile Communications (GSM) and its evolutions, which provide over 4 billion connections in over 200 countries worldwide, including the United States. A rival family of standards, broadly termed CDMA, is also popular in the United States, China, and a number of other countries. Japanese networks offer particular implementations of various types, including some proprietary network technologies.

In most developed and some developing markets, network technologies have reached a third -
generation of data access, sometimes known as 3G, providing speeds up to 2Mbps. These include UMTS (also known as W - CDMA), generally deployed by GSM network carriers, and CDMA2000, deployed by their CDMA brethren. In the United States, AT & T and T - Mobile offer UMTS data networks, while Verizon and Sprint have CDMA2000 networks.

Markets that have not yet reached widespread 3G coverage but still provide data services (notably in the least - developed countries and many developing countries), tend to provide slower 2.5G or 2.75G data technologies. Most common of these are the GSM - based GPRS which provides speeds up to 60Kbps, and EDGE which provides speeds up to 240Kbps.

Looking forward, fourth generation mobile technologies, including Advanced Long Term Evolution (LTE), are, at time of writing, in the process of being specified and standardized, but theoretically offer speeds up to 1Gbps. Sadly, such networks and devices are unlikely to be widespread for several years. In the interim, many networks provide transitional 3.5G technologies, such as HSDPA, EV - DO, and WiMAX, all of which, with speeds of between 3Mbps and 14Mbps, offer significant increases of speed and capacity to the 3G platform.

Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal

• 0 comments »

Less than 5 years ago, when most mobile devices used their own embedded or simple real - time operating systems, it appeared to mobile web developers as though there were as many operating system versions as there were models of devices. Given that these operating systems tended to
contain their own varied browser implementations, with no option for users to upgrade them or install alternatives, the challenge of delivering a reliable web experience to all of them was almost insurmountable. Such browsers were typically very limited, and often derived from their WAP browser precedents, provided limited or incomplete XHTML or CSS capabilities, low - fidelity media support, and little or no opportunity to use JavaScript or AJAX in web pages.

In 2005, Opera, a Norwegian browser manufacturer, launched Opera Mini, a browser that could be installed by the user on such devices and which subsequently has become a very popular third - party browser for older and low - to mid - range handsets. (Opera also provides a more capable browser, Opera Mobile, which runs on high - end devices, primarily those running Symbian and Android.) Using a proxy architecture to compress, adapt, and re - layout the content on behalf of the device, this browser provided the first glimpse that rich and complex websites could be rendered well and made relatively usable on a typical mobile device screen.

At about the same time, Nokia released a new browser for their high - end S60 range of devices that was based on code from the open - source WebKit browser project. Given its desktop heritage, the WebKit engine provided an unprecedented level of support for HTML, CSS, and JavaScript on a mobile device. This was something of a watershed in the history of mobile browsers, and since then, a number of signifi cant mobile device platforms now ship with WebKit - based browsers, including Apple ’ s iPhone, Google ’ s Android, Palm ’ s WebOS, and most recently Blackberry. Microsoft ’ s mobile operating systems do not provide WebKit - based browsers, but the capabilities of their default browsers have risen significantly in recent releases.

While the different implementations of each of these browsers can vary radically — device diversity is not going away any time soon — they do at least share a common open - source ancestry. This has helped the cause of efficient mobile web development greatly, because a developer or designer can at least assume a reasonable level of support for image and media support, CSS, and AJAX (although not Flash, video, or vector graphics, which remain variable in their support across browsers).

Unfortunately, it ’ s easy to forget that not all users are necessarily running the latest and greatest smart phones. Many cheaper handsets still run on embedded operating systems with weak web.

Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal

• 0 comments »

Pick up any mobile device and look at it carefully. Of course, the first thing you notice is the size, shape, and weight of its physical implementation. Very old mobile devices can be easily recognized by their larger, ungainly form, but following a period in the 1990s and 2000s, during which manufacturers sought to develop ever smaller devices, most modern devices are now of broadly similar size and weight. Not by coincidence, this is about the size that fi ts comfortably into an adult hand.

A limited selection of device form factors tend to prevail in today ’ s mobile market place. Some are more popular in certain parts of the world than others or among certain demographic groups, so a conscientious mobile web developer needs to be aware of all of them. These broad categories include the following:

Candybar — These devices are rectangular and static, typically with the main screen on the top half of one face and navigational control keys and a numeric keypad on the lower part of the same face, as with the Samsung SGH - t349. This form factor tends to be prevalent for cheaper or legacy models, although a wider, flatter candybar form, with a larger screen and complete QWERTY keyboard, is often used for more pricey business devices, such as the RIM BlackBerry range and some of the Nokia E - Series range.

Slate — These devices are also rectangular and static, but with much larger screens and fewer physical buttons on the casing than the candybar form factor. The rise of popularity in slate devices has been largely driven by improvements in touch - screen technology, which allow for point - and swipe - based navigation and for numeric and QWERTY keyboards to be displayed in software. Often, these devices can be rotated between landscape and portrait mode to maximize screen usage for particular types of applications. With the advent of the Apple iPhone and Android - based devices, this form factor has become very popular on expensive consumer
devices, although some mid - range devices are now exhibiting similar characteristics. Additionally, a larger variant of the slate form factor, personified by the Apple iPad, Amazon
Kindle, and other tablet devices, is starting to inhabit the space between pocket - sized mobile devices and laptops, while still being quite feasible web clients for humans on the move.

Slider — These devices are rectangular and of similar proportions to candybar devices when closed. However, the two halves of the device, one supporting the screen and one the keyboard, are able to slide relative to each other. This extends the size of the device and exposes the keyboard for use. Portrait - style sliders are popular, often on low - end models, because the longer “ open ” shape can be easier to use for making calls. However, many contemporary handsets slide in a landscape manner, exposing a QWERTY keyboard to use with a wider screen aspect ratio, as with the HTC P4350 device shown.

Flip — These devices also are designed to open up and expose a concealed keyboard, but do so with a hinge, rather than a slider. As a result, the primary screen is not visible in the closed state and is generally smaller as a proportion of the device than for the other form factors. Some handsets provide a smaller secondary screen on the outside of the device, but this rarely supports a web browser. Motorola i410 device exhibiting a classic flip form. Despite all the differences between these form factors, you need to make some reasonable assumptions for the purposes of delivering mobile web content to a capable device. First, you can be fairly sure that the device has a screen upon which its browser can render your content, but also that it is fairly small, both physically and in terms of pixel dimensions — relative to a desktop or laptop.

Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal

• 1 comments »

Your ability to write a webbot can distinguish you from a pack of lesser developers. Web developers—who've gone from designing the new economy of the late 1990s to falling victim
to it during the dot-com crash of 2001—know that today's job market is very competitive. Even today's most talented developers can have trouble finding meaningful work. Knowing how to write webbots will expand your ability as a developer and make you more valuable to your employer or potential employers.

A webbot writer differentiates his or her skill set from that of someone whose knowledge of Internet technology extends only to creating websites. By designing webbots, you demonstrate that you have a thorough understanding of network technology and a variety of network protocols, as well as the ability to use existing technology in new and creative ways.


Webbot Developers Are in Demand
There are many growth opportunities for webbot developers. You can demonstrate this for yourself by looking at your website's file access logs and recording all the non-browsers that have visited your website. If you compare current server logs to those from a year ago, you should notice a healthy increase in traffic from nontraditional web clients or webbots. Someone has to write these automated agents, and as the demand for webbots increases, so does the demand for webbot developers.

Hard statistics on the growth of webbot use are hard to come by, since many webbots defy detection and masquerade as traditional web browsers. In fact, the value that webbots bring to businesses forces most webbot projects underground. I can't talk about most of the webbots I've developed because they create competitive advantages for clients, and they'd rather keep those techniques secret. Regardless of the actual numbers, it's a fact that webbots and spiders comprise a large amount of today's Internet traffic and that many developers are required to both maintain existing webbots and develop new ones.


Webbots Are Fun to Write
In addition to solving serious business problems, webbots are also fun to write. This should be welcome news to seasoned developers who no longer experience the thrill of solving a problem or using a technology for the first time. Without a little fun, it's easy for developers to get bored and conclude that software is simply a sequence of instructions that do the same thing every time a program runs. While predictability makes software dependable, it also makes it tiresome to write. This is especially true for computer programmers who specialize in a specific industry and lack diversity in tasks. At some point in their careers, nearly all of the programmers I know have become very tired of what they do, in spite of the fact that they still like to write computer programs.

Webbots, however, are almost like games, in that they can pleasantly surprise their developers with their unpredictability. This is because webbots operate on data that changes frequently, and they respond slightly differently every time they run. As a result, webbots become impulsive and lifelike. Unlike other software, webbots feel organic! Once you write a webbot that does something wonderfully unexpected, you'll have a hard time describing the experience to those writing traditional software applications.


Webbots Facilitate "Constructive Hacking"
By its strict definition, hacking is the process of creatively using technology for a purpose other than the one originally intended. By using web pages, news groups, email, or other online technology in unintended ways, you join the ranks of innovators that combine and alter existing technology to create totally new and useful tools. You'll also broaden the possibilities for using the Internet.

Unfortunately, hacking also has a dark side, popularized by stories of people breaking into systems, stealing private data, and rendering online services unusable. While some people do write destructive webbots, I don't condone that type of behavior here. In fact, KEEPING WEBBOTS OUT OF TROUBLE is dedicated to this very subject.

Source of Information : Webbots Spiders and Screen Scrapers A Guide to Developing Internet Agents with PHP CURL

• 0 comments »