jQuery Mobile Web Development Essentials – Second Edition

jQuery Mobile Web Development Essentials from PACKT publishing is in its second edition, this new revision introduces new and updated content.

 

As usual with PACKT you can expect great quality, jQuery Mobile Web Development Essentials is no exception and covers all you need to develop mobile applications.

 

Prior knowledge of HTML5, CSS or JavaScript is recommended but not essential as jQuery Mobile Web Development Essentials covers all aspects of mobile development with jQuery, like data attributes, events, styling, forms, dialogues or converting your app to a native application.

 

If you just want to get your hands dirty and start playing jQuery Mobile Web Development Essentials comes packed with examples so you can get started quickly

 

After reading this book you should be able to create mobile applications with ease.

 

You can get this book from Amazon or directly from PACKT.

User Story

User Story

A user story details a specific feature. It should be specify a single feature. For example the following story: “Create a login box with a remember me checkbox and a forgot password link” should be splited into tree stories, one for the login box, another for the remember me and another one for the forgot password link.

This ensures the stories remain small ans can be implemented quickly

 

A User Story, much like its implementation also has some phases or stages, this ensures the Story has enough quality when it reaches the development team

Definition of ready

The Definition of Ready is very important for the team and Product Owner.

It says when a User Story is in a state that the team can pick it up, as such is also the Definition of Done for the Product Owner

 

Our definition of Ready includes the following points:

 

The story is clear:

The Story specifies who, what and why

The story is testable:

Acceptance criteria is written

Team understands the story:

The story is discussed with the team before commitment

The client approved the story:

The client has seen the story, or at least the designs/wire frames and has given his approval

All needed resources are available:

Data from 3rd party

Layouts

Diagrams,

translations, etc

Only when this points are checked the User Story will be considered for development

Acceptance Criteria

The Acceptance Criteria is a list of behavioral requirements for the User Story, Functional and Unit Tests will be written based on the Acceptance Criteria.

Great care should be taken when writing the Acceptance Criteria, all possible Behaviors should be taken into consideration and described

As the User Story MUST comply to this criteria the Product Owner has in this criteria a very useful mechanism to ensure the Story behaves as he envisions.

The acceptance criteria is also very important to the team as it tells how the code should behave.

The Acceptance Criteria can also serve as feature documentation, when the project grows is hard to keep track of all features and they should do. By keeping a record if all Acceptance Criteria we can easily know how the system should behave

Examples of Clear User stories:

Example 1:

As a Site Visitor I can create an account in order to become a member of the site.

 

Example 2:

As an Account Holder I want to withdraw cash from an ATM So that I can get money when the bank is closed

Examples of Acceptance Criteria:

Example 1:

A user should enter an email address and a password

Test that both the email address and password are entered (not blank)

Test that the email address is in a valid format

Test that the password is at least 6 characters

 

Example 2:

Given the account balance is $100

And the card is valid

And the machine contains enough money

When the Account Holder requests $20

Then the ATM should dispense $20

And the account balance should be $80

And the card should be returned

 

Definition of Done

The Definition of Done is very important for the scrum team, it lets the team know when a User Story can be declared Done and another User Story can be picked up.

 

Our definition of done includes the following points:

Code has quality:

Code review passed

Build passes:

75% unit test coverage

No failing Unit Tests

Complies to coding standards

Code is tested:

QA approval

Functional tests to written according to Acceptance Criteria

Functional tests passed

Code can be deployed:

install package is created

code is deployed into the integration server

Story can be demoed:

All needed preparations to demo the story are done (power point, sample data, etc)

Agile development

This series of articles have been in my task list for too long now.

it is kind o shame that I'm being a scrum master for so long never ever wrote any article about it!  So I'm finally starting a new series of articles on agile development.

 

Agile development

Agile development is an old idea from the sixties but only in 2001 achieved the mainstream in the form of a public manifesto.

This methodologies is all about adapting to change, it relies on  iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Agile methodologies promote adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change

Don't worry about this definition, later we will explore SCRUM, one of the most successful implementations, and this everything will become clear

The agile manifesto

The funny thing about Agile is that there are no fixed rules, agile is a set of four principles that we should follow. Nothing is said about how we should follow, it is our responsibility to implement those principles in a way that works for us and our company culture.

We need to see agile as a way of thinking a way of living, this principles don't necessarily apply exclusively to software development, companies like Toyota use them successfully

 

Individuals and interactions over processes and tools

Agile development promotes self organization and communication is key.

We should favor short communication lines over rigid processes that define how we should interact with each other.

In the real world this means we should favor a short informal face to face or phone talk over a formal email or letter.

You can get much more valuable information from a direct informal conversation than in writing.

Don't take this to the extreme, written communication is important after all “if it is not written it never happened” . You can for example have the short face to face talk, then either send an email with the summary of the conversation.

 

Working software over comprehensive documentation

Working software is what you should stand for, after all that is what the client is expecting.

It is also a key instrument to gather feedback, most of the times the client only really gets the feeling of what he wants or doesn't want after trying the software.

So instead of going to meeting with enough paper to destroy a forest bring him a quick mock-up or a prototype. Later we will see some techniques to quickly build working software so the client can get a feeling of the product

No one likes to go through 500 pages of detailed descriptions, seeing it in action is much better.

 

Customer collaboration over contract negotiation

Requirements cannot be fully collected at the beginning of the software development cycle, therefore#Agile development

Agile development is an old idea from the sixties but only in 2001 achieved the mainstream in the form of a public manifesto.

This methodologies is all about adapting to change, it relies on  iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Agile methodologies promote adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change

Don't worry about this definition, later we will explore SCRUM, one of the most successful implementations, and this everything will become clear

 

Responding to change over following a plan

Everything changes, software is not different, we should embrace that idea instead of fighting it.

We need to accept and incentivate change for the customer competitive advantage.

When developing software we need to keep change in mind by  building software that can be changed, we need to be smart and design the system as series of small modules that can be combined to provide different functionality.

This does not mean that we should write code that predicts all possible situations just in case the client changes something, only write the code needed to fulfill our goal needs to be written, instead we need to make use of proper design, decoupling, meta-programming in order to write flexible systems

Managing dependies with composer

One of the most recurring events I face in the projects I'm involved is “How the hell do I manage all the dependencies?” You have internal libraries, frameworks, external libraries, it is just a big mess.

It is very hard to ensure all developers are using the same version of a specific library.

Sometimes their distribution provides a newer version and they develop according to the latest specifications.

When deploying they are faced with the sad reality, that version of the library is not available on the production server either because it is not approved by the Sys Admin team or simply it is not available

As result their code can not be deployed because it relies on a feature only the latest and greatest version provides! Continue reading

Unit testing in PHP with PHPUnit

So, your code is ready, or so you think. Now it is time for testing.

You fire up the browser and go through each feature. That is when you find an error.

You go back to the code, do some changes and test again, only to discover your fix has introduced another error.

Deja-vu? I bet yes.

What if there where a way to test your code automatically? Continue reading