Packt publishes its 1000th and wants to celebrate with you

Packt Publishing reaches 1000 IT titles and celebrates with an open invitation

Birmingham-based IT publisher Packt Publishing is about to publish its 1000th title. Packt books are renowned among developers for being uniquely practical and focused.  Packt books cover highly specific tools and technologies which IT professionals might not expect to see a high quality book on.
Packt would like you to join them in celebrating this milestone with a surprise gift – to get involved you just need to have already registered, or sign up for a free Packt account before 30th September 2012.
Packt published their first book in April 2004. One of the most prolific and fastest growing tech book publishers in the world, they now have books on everything from web development to web graphics, e-learning to e-commerce, IT architecture to games, and app development.
Packt supports many of the Open Source projects covered by its books through a project royalty donation, which has contributed over £300,000 to Open Source projects up to now. As part of the celebration Packt is allocating $30,000 to share between projects and authors in a genuinely unique way, soon to be disclosed on their website.
Dave Maclean, founder of Packt Publishing explains, “At Packt we set out 8 years ago to bring practical, up to date and easy to use technical books to the specialist tools and technologies that had been largely overlooked by IT publishers. Today, I am really proud that with our authors and partners we have been able to make useful books available on over 1000 topics and make our contribution to the development community.”
For more information about Packt, the kind of books they publish, and to sign-up for a free account before the 30th of September, 2012, please visit their website: www.PacktPub.com.

Enjoy !!


Book: Oracle SOA Suite 11g Administrators's handbook

My next project is probably a Oracle SOA Suite 11g project, so start reading the following book. A review of the book will follow (http://www.packtpub.com/oracle-soa-suite-11g-administrators-handbook/book)

I hope to read useful information about

  • How to set up Oracle SOA Suite projects
  • How to unit test
  • How to deploy to DTAP
  • How to monitor
  • How to error log
  • How to govern


Business Process Management

Business process management
 is a management approach focused on aligning all aspects of an organization with the wants and needs of clients. It is a holistic management approach that promotes business effectiveness and efficiency while striving for innovation, flexibility, and integration with technologyBusiness process management attempts to improve processes continuously. It could therefore be described as a “process optimization process.” It is argued that BPM enables organizations to be more efficient, more effective and more capable of change than a functionally focused, traditional hierarchical management approach.


business process is a “series or network of value-added activities, performed by their relevant roles or collaborators, to purposefully achieve the common business goal.” These processes are critical to any organization as they generate revenue and often represent a significant proportion of costs. As amanagerial approach, (BPM) considers processes to be strategic assets of an organization that must be understood, managed, and improved to deliver value added products and services to clients. This foundation is very similar to other Total Quality Management or Continuous Improvement Process methodologies or approaches. BPM goes a step further by stating that this approach can be supported, or enabled, through technology to ensure the viability of the managerial approach in times of stress and change. In fact, BPM is an approach to integrate a “change capability” to an organization – both human and technological. As such, many BPM articles and pundits often discuss BPM from one of two viewpoints: people and/or technology.
Roughly speaking, the idea of (business) process is as traditional as concepts of tasks, department, production, outputs. The current management and improvement approach, with formal definitions and technical modeling, has been around since the early 1990s (see business process modeling). Note that in the IT community, the term ‘business process’ is often used as synonymous of management of middleware processes; or integrating application software tasks. This viewpoint may be overly restrictive. This should be kept in mind when reading software engineering papers that refer to ‘business processes’ or ‘business process modeling.’
Although the initial focus of BPM was on the automation of mechanistic business processes, it has since been extended to integrate human-driven processes in which human interaction takes place in series or parallel with the mechanistic processes. For example (in workflow systems), when individual steps in the business process require human intuition or judgment to be performed, these steps are assigned to appropriate members within the organization.
More advanced forms such as human interaction management are in the complex interaction between human workers in performing a workgroup task. In this case, many people and systems interact in structured, ad-hoc, and sometimes completely dynamic ways to complete one to many transactions.
BPM can be used to understand organizations through expanded views that would not otherwise be available to organize and present. These views include the relationships of processes to each other which, when included in the process model, provide for advanced reporting and analysis that would not otherwise be available. BPM is regarded by some as the backbone of enterprise content management.
Because BPM allows organizations to abstract business process from technology infrastructure, it goes far beyond automating business processes (software) or solving business problems (suite). BPM enables business to respond to changing consumer, market, and regulatory demands faster than competitors – creating competitive advantage.
Most recently, technology has allowed the coupling of BPM to other methodologies, such as Six Sigma. BPM tools now allow the user to:
Define - baseline the process or the process improvement
Measure - Simulate the change to the process.
Analyze - Compare the various simulations to determine an optimal improvement
Improve - Select and implement the improvement
Control - Deploy this implementation and by use of User defined dashboards monitor the improvement in real time and feed the performance information back into the simulation model in preparation for the next improvement iteration.
This brings with it the benefit of being able to simulate changes to your business process based on real life data (not assumed knowledge) and also the coupling of BPM to industry methodologies allow the users to continually streamline and optimise the process to ensure it is tuned to its market need.

You can read more on this blog item here


Still some misunderstanding about User Stories

In projects i often see that there is still a lot of confusion about User Stories and planning. This article of the famous Scott Ambler describes the way you should plan and use User Stories within Agile projects. One common mistake is that a User Story is much smaller than a Use Case.

Introduction to User Stories

A good way to think about a user story is that it is a reminder to have a conversation with your customer (in XP, project stakeholders are called customers), which is another way to say it's a reminder to do some just-in-time analysis.  In short, user stories are very slim and high-level requirements artifacts.

Initial User Stories (Informal)

As you can see in Figure 1 user stories are small, much smaller than other usage requirement artifacts such as use cases or usage scenarios.  It's important to recognize that each of the statements in Figure 1 represents a single user story. 
Figure 1. Example user stories.
  • Students can purchase monthly parking passes online.
  • Parking passes can be paid via credit cards.
  • Parking passes can be paid via PayPal ™.
  • Professors can input student marks.
  • Students can obtain their current seminar schedule.
  • Students can order official transcripts.
  • Students can only enroll in seminars for which they have prerequisites.
  • Transcripts will be available online via a standard browser.

Important considerations for writing user stories:
  1. Stakeholders write user stories.  An important concept is that your project stakeholders write the user stories, not the developers.  User stories are simple enough that people can learn to write them in a few minutes, so it makes sense that the domain experts (the stakeholders) write them.
  2. Use the simplest tool.  User stories are often written on index cards as you see in Figure 2 (at least when your project team is co-located).  Index cards are very easy to work with and are therefore an inclusive modeling technique.
  3. Remember non-functional requirements.  Stories can be used to describe a wide variety of requirements types.  For example in Figure 1 the Students can purchase parking passes online user story is a usage requirement similar to a use case whereas the Transcripts will be available online via a standard browser is closer to a technical requirement.  
  4. Indicate the estimated size.  You can see in Figure 2 that it includes an estimate for the effort to implement the user story.  One way to estimate is to assign user story points to each card, a relative indication of how long it will take a pair of programmers to implement the story.  The team then knows that if it currently takes them on average 2.5 hours per point; therefore the user story in Figure 2 will take around 10 hours to implement. 
  5. Indicate the priority.  Requirements, including defects identified as part of your independent parallel testing activities or by your operations and support efforts, are prioritized by your project stakeholders (or representatives thereof such as product owners) and added to the stack in the appropriate place. You can easily maintain a stack of prioritized requirements by moving the cards around in the stack as appropriate.  You can see that the user story card includes an indication of the priority; I often use a scale of one to ten with one being the highest priority.  Other prioritization approaches are possible – priorities of High/Medium/Low are often used instead of numbers and some people will even assign each card it’s own unique priority order number (e.g. 344, 345, …).  You want to indicate the priority somehow in case you drop the deck of cards, or if you're using more sophisticated electronic tooling.  Pick a strategy that works well for your team. You also see that the priority changed at some point in the past, this is a normal thing, motivating the team to move the card to another point in the stack.  The implication is that your prioritization strategy needs to support this sort of activity.  My advice is to keep it simple.
  6. Optionally include a unique identifier.  The card also includes a unique identifier for the user story, in this case 173.  The only reason to do this would be to do this is if you need to maintain some sort of traceability between the user story and other artifacts, in particular acceptance tests.

    You can read the full article here

Write good unit tests

It is not enough for today’s software developers to know their programming language well. There are further skills, that more and more companies are expecting from there employees. One of the most important is Test Driven Development (TDD). This is not an introduction to TDD. If you want to learn it, I recommend Uncle Bob’s awesome Clean Code Videos (Episode 6 - TDD) or simply ask Google for it. But many developers are writing bad code and applying TDD does not make them writing good code. Instead it makes them also writing bad tests. So this is about writing better test code.

Applying simple rules

To understand why test code can be bad, you should understand, what it should do. It should work as the parachute, that keeps you alive, when refactoring your code. Tests may help you to be sure nothing breaks, when adding new features to your code. But tests may also work as sample code, that documents your APIs better than any other documentaion except the code itself.
But how can you make your tests better? It might help to follow some simple rules, that could be easily applied to every language or test style like BDD or Junit-style.

Tests should be a state machine

Many people do not like BDD at all, but there is a pretty nice idea in it - the given-when-then style some frameworks promote. This style forces you into a way of thinking about tests, that you should adapt. Even if you do not use a BDD framework.
Writing a test this way means there is a start state, something happens and than an end state is reached. If your test is broken, the state machine in it is broken. In BDD frameworks the first part of your test is the given block, where all the setup stuff is done. The second part is the when block, where an action is applied on the test object, created in the given block. At least you have a thenblock, where you assert, that the correct end state is reached.
It is very helpful to have this in mind while writing a new test. Keep these three parts seperated and do not mix them in some way. Do not write code in your test, where an if appears, or even more complex logic. In a test you should only do the above three steps. Do some simple setup, call a method on your test object or invoke the test function and assert the result is correct.
This might also make your code better. If you write messy code, tests written this way are harder to create and maintain. If you have to much of inheritance, dependencies on other objects or resources like IO, you will have to set it up in every test you write and that is no fun. But you should write your tests first and hopefully it makes writing messy code harder, if you have written a well structured tests first.
More on this great article can be read here.