Sequence of execution of SQL querry

Sequence of execution of SQL querry is discussed below which is so helpful to design a query if you are handling large DB results.

1. FROM
2. JOIN
3. ON
4. WHERE
5. GROUP BY
6. HAVING
7. SELECT
8. DISTINCT
9. ORDER BY
10. LIMIT (TOP)

Enjoy Programming!!!

PHP V6

PHP V6 is currently available as a developer snapshot, so you can download and try out many of the features and changes listed in this article. Features that have been implemented in the current snapshot are discussed below:

1. Improved Unicode support
Much improved for PHP V6 is support for Unicode strings in many of the core functions. This new feature has a big impact because it will allow PHP to support a broader set of characters for international support. So, if you're a developer or architect using a different language, such as the Java™ programming language, because it has better internationalization (i18n) support than PHP, it'll be time to take another look at PHP when the support improves. Because you can download and use a developer's version of PHP V6 today, you will see some functions already supporting Unicode strings. For a list of functions that have been tested and verified to handle Unicode
2. Namespaces
Namespaces are a way of avoiding name collisions between functions and classes without using prefixes in naming conventions that make the names of your methods and classes unreadable. So by using namespaces, you can have class names that someone else might use, but now you don't have to worry about running into any problems. Listing 1 provides an example of a namespace in PHP. You won't have to update or change anything in your code because any PHP code you write that doesn't include namespaces will run just fine. Because the namespaces feature appears to be back-ported to V5.3 of PHP, when it becomes available, you can start to introduce namespaces into your own PHP applications.
3. Web 2.0 features
Depending on how you use PHP and what your scripts look like now, the language and syntax differences in PHP V6 may or may not affect you as much as the next features, which are those that directly allow you to introduce Web 2.0 features into your PHP application.
4. SOAP
SOAP is one of the protocols that Web services "speak" and is supported in quite a few other languages, such as the Java programming language and Microsoft® .NET. Although there are other ways to consume and expose Web services, such as Representational State Transfer (REST), SOAP remains a common way of allowing different platforms to have interoperability. In addition to SOAP modules in the PHP Extension and Application Repository (PEAR) library, a SOAP extension to PHP was introduced in V5. This extension wasn't enabled by default, so you have to enable the extension or hope your ISP did. In addition, PEAR packages are available that allow you to build SOAP clients and servers, such as the SOAP package. Unless you change the default, the SOAP extension will be enabled for you in V6. These extensions provide an easy way to implement SOAP clients and SOAP servers, allowing you to build PHP applications that consume and provide Web services. If SOAP extensions are on by default, that means you won't have to configure them in PHP. If you develop PHP applications and publish them to an ISP, you may need to check with your ISP to verify that SOAP extensions will be enabled for you when they upgrade.
5. XML
As of PHP V5.1, XMLReader and XMLWriter have been part of the core of PHP, which makes it easier for you to work with XML in your PHP applications. Like the SOAP extensions, this can be good news if you use SOAP or XML because PHP V6 will be a better fit for you than V4 out of the box. The XMLWriter and XMLReader are stream-based object-oriented classes that allow you to read and write XML without having to worry about the XML details.

Things removed

In addition to having new features, PHP V6 will not have some other functions and features that have been in previous versions. Most of these things, such as register_globals and safe_mode, are widely considered "broken" in current PHP, as they may expose security risks. In an effort to clean up PHP, the functions and features listed in the next section will be removed, or deprecated, from PHP. Opponents of this removal will most likely cite issues with existing scripts breaking after ISPs or enterprises upgrade to PHP V6, but proponents of this cleanup effort will be happy that the PHP team is sewing up some holes and providing a cleaner, safer implementation.

Features that will be removed from the PHP version include:

• magic_quotes
• register_globals
• register_long_arrays
• safe_mode

Enjoy Programming!!!

Steps to publish the mobile application in Flash Builder 4.5

iPhone/iPad

1) Certificate file having extension “.p12”
2) MOBILEPROVISION File (Provisioning file)

Android

1) Certificate file having extension “.p12”

Steps to release the build for iPhone/iPad:

1) Select the target in Export Release Build screen.
2) Let we choose only Apple iOS, press next button after browsed the 'Export to Folder' path.
3) Now, we have to browse the 'Certification' to publish the application and with respect to this certificate, we have to browse the 'provisioning file'.
4) Now, we have to enter the password for the 'Certification' that has been given with the Certificate.

Note: We have to aware about that in the mobile-app.xml and provisioning file the 'PRODUCT ID' should be same.

After released, there are some steps to put the application into iPhone/iPad from MAC, detail as given below:

1) When you are done with release, you will get the file .ipa extension and transfer to MAC.
2) Right click on the file and achieve the file. Finally, you will get the .app file that will be compatible for iPhone/iPad.
3) Now, using iTune you can transfer the file into iPhone/iPad.
4) Enjoy the application in iPhone/iPad.

Steps to release the build for Android:

1) Select the target in Export Release Build screen.
2) Let we choose only Google Android, press next button after browsed the 'Export to Folder' path.
3) Now, we have to browse the 'Certification' i.e. “.p12” extension.
4) Now, we have to enter the password for the 'Certification' that has been given with the Certificate.

Note: You can also create your own certificate for Android by click on 'Create' button given with the 'Browse' button.

After released, there are some steps to put the application into Android, detail as given below:

1) When you are done with release, you will get the file .apk extension.
2) Now, using Android interface or Android Market you can transfer the file into Android Phone.
3) Enjoy the application in Android.

References:

i. http://www.adobe.com/products/flash-builder/features.html
ii. http://www.adobe.com/devnet/flex/articles/mobile-development-flex-flashbuilder.html

Enjoy Programming!!!

The Sprint Meetings

The sprint is the heartbeat of the Scrum cycle. It is bookmarked by sprint planning at
the start and by the sprint review and sprint retrospective at the end. The length of the
sprint is fixed and is never extended. Most Scrum teams choose two, three or four
weeks as their sprint duration. Each day during the sprint the team holds a daily
Scrum meeting. Every meeting in Scrum is strictly time-boxed. This means that is has
a maximum duration. It does not means that it needs to occupy this full time. For a 30
day (or four week) sprint the time boxes for planning 1 & 2, review and retrospective
are set at four hours each. For shorter sprints they should be adjusted in proportion to
the sprint length.
Some key attributes of the meetings are described in the following sections. First,
though, I have collected a few experiences I think are worth sharing.

• I find two-week sprints a good length to start with. After three sprints, let the
  team re-assess the sprint length.
  
• Teams need three sprints to grasp the new concepts, break down old habits
  and start to gel as a team.
  
• Never do sprint planning on a Monday morning. The team is not yet at its
  best and it is the most common day for holidays and sickness. Never hold
  reviews or retrospectives on a Friday afternoon. The team is tired and
  thinking about the weekend. Therefore choose sprint boundaries on
  Tuesdays to Thursdays.
  
• Teams running two-week sprints might be tempted to hold all sprint
  boundary meetings in one day. In other words, start the day with the review,
  then the retrospective; after lunch do sprint planning parts 1 and 2. The
  thinking is to get all the meetings out of the way and have 9 full days to do
  the work. In my experience there are two problems with this approach:
  
  • The team does not get that these meetings are part of the work—in fact
    the most important part to get right!
    
  • During the last part of the day—sprint planning 2—the team is brain-dead.
    
    Yet, as always, let the team try it out if they so wish!
    

Sprint Planning - Part 1
Part 1 of sprint planning (SP1) is really a detailed requirements workshop. The product
owner presents the set of features he would like and the team asks questions to
understand the requirements in sufficient detail to enable them to commit to delivering
the feature during the sprint. The team alone decides what it can deliver in the sprint,
taking into account the sprint duration, the size and current capabilities of its
members, its definition of DONE, any known holidays or leave days and any actions it
committed to during the retrospective held just prior this meeting.
The product owner must be present during this meeting to lead the team in the right
direction and to answer questions—and they will have many. The ScrumMaster must
ensure that any other stakeholder needed to help the team understand the
requirements is present or on call.
Any new backlog items for inclusion in the current sprint and not previously estimated
will be sized immediately during this meeting. This not, however, an excuse to avoid
grooming the backlog—see below!
At the end of SP1 the team commits to the Product Owner what they believe they can
deliver in the form of running tested features. An experienced team may use historic
velocity as a predictor ('yesterday's weather'). This is known as velocity-based
planning. My recommendation to most teams is to do commitment-based planning.
The backlog items the team has committed to is called the selected product backlog.

Sprint Planning - Part 2
If part 1 is a requirements workshop, part 2 of sprint planning (SP2) is a design
workshop. In this session the team collaborates to create a high-level design of the
features it has committed to deliver. An outcome of this session is the sprint backlog,
or the list of tasks that the team collectively needs to execute in order to turn the items
in the selected product backlog into running tested features. This set of tasks is called
the sprint backlog and is most often represented on a physical task board.
During SP2 the team may have additional questions regarding the requirements. The
ScrumMaster must ensure that the Product Owner and, if necessary, other
stakeholders are on call to answer them.
Design, as everything else in Agile, is emergent. Also, the meeting is time-boxed. So it
is normal that the team won’t get the design perfectly done in this session and will
discover more tasks during the sprint. This is not a sign that something is wrong. They
will simply grab a post-it note and pen and create more tasks whenever necessary
during the sprint.
You will know that SP2 is working when the team is gathered together
around the white board discussing noisily or even arguing about the 'best' or
'right' way to implement a feature.

(Do Better Scrum)

Enjoy Programming!!!

Roles Introduction (SCRUM)

The scrum process constitutes various roles and are discussed below:

Roles Introduction
There is no Project Manager role in Scrum. The responsibilities of the traditional project
manager are divided over the three roles in the Scrum Team:

• The Product Owner manages the product (and return on investment)
• The ScrumMaster manages the process
• The team manages itself.

This is challenging to individuals who currently fulfil this role and to managers in
organisations in which they work. Michele Sliger and Stacia Broderick have written a
helpful guide to the transition from Project Manager to Agile Coach [Sliger and
Broderick 2008].
There are no appointed leaders of the Scrum Team beyond the Product Owner and
ScrumMaster; none is required. The need for line managers is reduced, as teams
manage themselves to a great extent. It is not uncommon for 50 team members to
report directly to a single line manager in an organisation that has made the transition
to Agile.

Self-organisation
Self-organisation does not at all imply a laissez-faire approach; on the contrary, selforganised
teams are highly disciplined. They are given full autonomy and carry
correspondingly greater responsibility for delivery accordance with their own
commitments. They are encouraged to take reasonable risks and to learn through
failure and self-reflection. High trust and high commitment is an automatic outcome of
truly self-organising teams.
Teams new to Scrum will require some encouragement to explore their new, broader
boundaries and to take ownership. They frequently need to overcome strong ‘muscle
memory’ of the poor ways in which they were managed and worked, sometimes for
years.
Self-organisation is not an option in Scrum; it is a core principle. Without this, highperforming
teams will not happen. Caveat emptor!

Product Owner
The responsibilities of the Product Owner role are:

• Working on a shared vision
• Gathering requirements
• Managing and prioritising the Product Backlog
• Accepting the software at the end of each iteration
• Managing the release plan
• The profitability of the project (ROI)

Metaphor: The Product Owner is a CEO.

ScrumMaster
The responsibilities of the ScrumMaster role are:

• Empowering and shepherding the team
• Removing impediments
• Keeping the process moving
• Socializing Scrum to the greater organisation

Metaphor: The Scrum Master is a facilitator, coach, mentor and bulldozer!

Team
The responsibilities of the Team or Team Member role are:

• Estimating size of backlog items
• Committing to increments of deliverable software and delivering it
• Tracking own progress
• Is self-organising—but accountable to the Product Owner for delivering as
  promised

Enjoy Programming!!!

Online Escrow Payment Flow Algorithm (Instructions Set)

On the basis of analysis to implement Escrow Payments, below is the generic algorithm:

Online Escrow Payment Flow Algorithm (Instructions Set)

State – 1: Buyer requests for the service* and pay the amount through any payment gateway. There should be commission and/or transaction fees included in the amount, then
Total Amount = Amount to seller + Commission and/or Transaction Fees.
At this moment, the status of escrow process will be "0"(zero).

State – 2: The amount that buyer paid will go to the Escrow* (Admin) account using any specific payment gateway.

State – 3: Both the parties (buyer and seller) will be informed (through email and/or any other mean) after successful payment with all required details. The status of this escrow process will be set to "1" i.e amount has been paid by the buyer.

State – 4: If the payment was not successful, then buyer will be informed about it and escrow status will be set to "-1". Seller may be informed about the initiation of this process and this will depend on the type of service.

State – 5: Service will be provided to "Buyer" by the service provider which should follow necessary set terms and conditions which will depend on the type of service.

State – 6: The required time slap will be provider to "Buyer" to raise dispute against the payment paid for the service. If dispute arises then this would be the duty of Escrow (Admin) to resolve that dispute and there should be set parameters which will be used to resolve dispute. In this condition "Dispute" status will set to "1" from "0" and payment will be blocked, "dispute resolution time" will be added to the "Escrow Complete" time.
This whole process will depend on the type of service and several different service specific approaches will come handy.

State – 7: If resolution of dispute goes in the favor of buyer then "Dispute" status will be set to "2" else
it will be set to "3".

State – 8: Dispute should be resolved in the set interval of time i.e “dispute resolution time”. After this set interval of time, check “Dispute status”. If its value is “2”, then transfer amount back to buyer account after deducting commission and/or transaction fees else transfer set amount to the account of service provider.
Now set escrow process status to “2” i.e Escrow complete.

State – 9: If all goes well and there is no any dispute, after completion of “Escrow Complete” time, transfer set amount to the account of seller and set escrow process status to “2” i.e Escrow complete.

(Rajesh Bhatia)

Enjoy Programming!!!

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others
do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left
more.

Principles behind the Agile Manifesto

1. Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self-organizing
teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly.

Highsmith (2001)

Enjoy Programming!!!

Key points if you are following Agile Software Development

Key points if you are following Agile Software Development

1. “More working hours” doesn't necessarily mean "more effective work".
2. Be adaptable to new changes (if they are billable :)) and let positive energy flow with your blood i.e "Don't worry be happy".
   
    Enjoy Programming!!!
   
   
   
   
   
   
   

Case Study on the optimization of server set up for Magento

Hello All:

I just found really nice pdf document on the optimization of server set up for Magento which can be downloaded using URL http://www.magentocommerce.com/whitepaper/.

Enjoy Programming!!!

Note on Magento Cache

It may be required to disable the built-in Magento cache (that is
enabled after installation by default) during active development, but please make sure that
caching is enabled on production sites as disabled cache makes the store frontend 5-6 times
slower and less responsive under load.

On the use of php accelerator:

The APC cache backend improves the results, which are 2-3 times better than the
default filesystem cache backend. The memcached cache backend shows 10-15% better results
than APC. And from the tests of Magento team, the eAccelerator cache backend shows the best results which are
5-10% faster than memcached.

Enjoy Programming!!!