Product Details

• Paperback: 576 pages
• Publisher: Addison-Wesley Professional; 1 edition (January 9, 2009)
• Language: English
• ISBN-10: 0321534468
• ISBN-13: 978-0321534460
• Product Dimensions: 9.1 x 6.9 x 1.4 inches
• Shipping Weight: 1.8 pounds

For developers / testers not new to the agile world this book can be the most depressive piece of art. It tells a story of a way of development you know is out there, but most not yet have reached.  Lisa Crispin and Janet Gregory share their experiences through personal stories and examples from others.

There are some questions the authors want to answer:

• As a tester, what is my role on an agile team?
• How do I transition from a traditional phased/gated development cycle to agile?
• How do we get testers engaged with the rest of the agile development team?
• What tools do I need?
• Who does what testing on an agile team?
• How can testing "keep up" with short iterations?
• How do we know if we're doing a good job of testing? How can we improve?
• What do testers do the first few days of an iteration, before any stories are done?
• None of our testing is automated. Where do we start, and how do we find time to do automation?

Did I get answers to all this? Yes I did! There's a way of thinking that I was never aware of as a developer. I can now look through the eyes of a tester and my design is driven by the phrase: "Ok, but how would I test this?" How would I present that I have done what I was told to? How can I be sure to create what the customer wants me to. Besides giving a throughout view upon the work of an agile tester we get to know the fundamental elements of SCRUM.

Editorial Reviews

Review

Handling bugs is never an easy task. Some are not even meant to be logged while some can not be fixed without blowing up the whole system. Some of the books I've read described great ways to deal with defects. Most suggest to record them to a DTS, write some reproduction steps and wait for the programmer team to fix it. This approach works well and gives a good numbers to generate trends. I might be a bit obsessed with automation and TDD though, so I've started using something else.

What is a bug in this context?

A bug is a piece of behavior that doesn't work as expected from the user's point of view. The key points in the definition above are that we're only talking about defects that can be reproduced from the user interface only. Why? Because no one cares about the unseen.

So you've caught a bug!

Great! You probably have some notes about how to recreate the defect. You are aware of what it should be doing instead of what it is doing now. You'll probably record it to a bug tracker, but try this:

Create an automated test!

All levels of testing require inputs and expectations. Even the smallest micro-test that drive core methods rely on expected output from a known input. In the current scenario you'll have steps as inputs and you have expectations how your user interface should respond to those. For a primitive demonstration lets look at the following bug report:

Description:

A logged in user of the system cannot change the registered e-mail address!

Steps to reproduce:

1. Open the site.
2. Log into the site.
3. Click the "Account Settings" link.
4. Change the e-mail address via the settings form.
5. Click "Save" button.

Expected behavior:

The pre-populated e-mail field should contain the new e-mail.

Current behavior:

The new e-mail address is not saved, the old one is visible after saving the form.

In your automated test script you should be able to easily re-create the steps above. The interesting part are the expectations. The just enough assertions to consider the bug fixed depends on the complexity of the error. In our case it's a pretty straight-forward conclusion: assert that the e-mail field after submitting the data holds the e-mail address we've entered before. Having test like these is pretty nice if you make them part of your regression suite. It helps you target error prone parts of your system and if such test case is present you can be sure you'll be notified if the bug resurrects.

But how to handle these before the bug is fixed?

Create a test suite for bugs. With TestNG you can easily manage test groups. I prefer having a group named Bugs and one called Regression. The latter contains only bugs that are fixed. The tests in the former are executed via a nightly run for example. Each run will report the number of tests failed only in this case it will mean: the number of bugs still alive! If you hook these up with a CI server you can get nice little trends showing the number of living bugs over time. It works for us! Leave your thoughts if you have tried this approach, I'm extremely curious!

How many bugs live in your system?

Just found this great cheatsheet on twitter by @nickfloyd. Use it wise and be the proud creator of lots of nice clean code! download pdf

We're not superheroes I was reading bits of Coders at work, a book of interviews to famous programmers. I didn't like it very much: here's why. The first thing I noticed is that many questions are biographical. I do not care about knowing if Ken Thompson, which built Unix, worked on a PDP-10 or a PDP-11 or a PDP-7. By the way, I do not even know how those things look like: I was born in 1988. Besides that, this kind of books tells you how to live like a superhero coder, but most of us just aren't (me too). Thompson could work out the design of software in his mind for a month before starting coding, I can't (or I can waste less time by writing something in code). Knuth could design and code LaTeX in pencil and write for six months before do any testing. I can't (or I can, but I would be much more efficient with a quick feedback loop like Test-Driven Development's one.) Zawinski could pick up rolls of duct tape and make Netscape work in six months (picking up also a lot of technical debt and vanishing from the market in the following years). I prefer working software over comprehensive documentation but not over sustainable development. So we're not superheroes: test suites, source control, Continuos Integration are our bat-gadgets which enable us to deliver software while working for a living and not living for work, like Ken Thompson and his 28-hour days or Bill Gates and his nights at school programming. Let the people with the superpowers shoot webs all night long, while we go back to Wayne Manor and throw a party. At least Batman hasn't a day job: poor's Peter Parker must live a miserable life. Published by Giorgio via We're not superheroes - Invisible to the eye.

Product Details

• Paperback: 688 pages
• Publisher: O'Reilly Media; 1 edition (October 25, 2004)
• Language: English
• ISBN-10: 0596007124
• ISBN-13: 978-0596007126
• Product Dimensions: 9.2 x 8 x 1.4 inches
• Shipping Weight: 2.8 pounds

Not as bad as it may look by the cover! Elisabeth Freeman relies on the feminine way of association. There are a lot of pictures, arrows, speech bubbles, acts and life-examples describing the patterns. If you have a good imagination and can easily recall pieces of information by keywords like pizza and duck, then this book is for you. If you want a reference-book of design patterns that you can hit up while coding, look for something else. There is one thing you must read on page 526, the MVC song: MVC song

Editorial Reviews

Review

This is a gimmicky book that actually works for once. It is an intelligent and well thought-out discussion of Java design patterns, and if you dont know what a design pattern is then this is an excellent way to find out. It is also an interested discussion of object-oriented design. I found that the authors often anticipated my reaction to their initial explanations and asked the questions that I would have asked had it been a lecture. - Mike James, VSJ, April 2005

Product Description

You're not alone. At any given moment, somewhere in the world someone struggles with the same software design problems you have. You know you don't want to reinvent the wheel (or worse, a flat tire), so you look to Design Patterns--the lessons learned by those who've faced the same problems. With Design Patterns, you get to take advantage of the best practices and experience of others, so that you can spend your time on... something else. Something more challenging. Something more complex. Something more fun. You want to learn about the patterns that matter--why to use them, when to use them, how to use them (and when NOT to use them). But you don't just want to see how patterns look in a book, you want to know how they look "in the wild". In their native environment. In other words, in real world applications. You also want to learn how patterns are used in the Java API, and how to exploit Java's built-in pattern support in your own code. You want to learn the real OO design principles and why everything your boss told you about inheritance might be wrong (and what to do instead). You want to learn how those principles will help the next time you're up a creek without a design paddle pattern. Most importantly, you want to learn the "secret language" of Design Patterns so that you can hold your own with your co-worker (and impress cocktail party guests) when he casually mentions his stunningly clever use of Command, Facade, Proxy, and Factory in between sips of a martini. You'll easily counter with your deep understanding of why Singleton isn't as simple as it sounds, how the Factory is so often misunderstood, or on the real relationship between Decorator, Facade and Adapter. With Head First Design Patterns, you'll avoid the embarrassment of thinking Decorator is something from the "Trading Spaces" show. Best of all, in a way that won't put you to sleep! We think your time is too important (and too short) to spend it struggling with academic texts. If you've read a Head First book, you know what to expect - a visually-rich format designed for the way your brain works. Using the latest research in neurobiology, cognitive science, and learning theory, Head First Design Patterns will load patterns into your brain in a way that sticks. In a way that lets you put them to work immediately. In a way that makes you better at solving software design problems, and better at speaking the language of patterns with others on your team.

Product Details

• Paperback: 304 pages
• Publisher: Addison-Wesley Professional (March 11, 2004)
• Language: English
• ISBN-10: 0321205685
• ISBN-13: 978-0321205681
• Product Dimensions: 9.1 x 7 x 0.7 inches
• Shipping Weight: 1.2 pounds

I was holding this book in my hands a few times before I actually started reading it. I didn't believe that a book can actually get me into a mood that extreme development and agile means to me, but I was wrong. This book should be read by everyone who is envolved in software development. I believe that this approach could be aplied to other aspects of life, but that's just my opinion. We will be referring to this book in the Munchkin project, it gave us a lot of great ideas!

Editorial Reviews

Product Description

The concept of user stories has its roots as one of the main tenets of Extreme Programming. In simple terms, user stories represent an effective means of gathering requirements from the customer (roughly akin to use cases). This book describes user stories and demonstrates how they can be used to properly plan, manage, and test software development projects. The book highlights both successful and unsuccessful implementations of the concept, and provides sets of questions and exercises that drive home its main points. After absorbing the lessons in this book, readers will be able to introduce user stories in their organizations as an effective means of determining precisely what is required of a software application.

From the Back Cover

Agile requirements: discovering what your users really want. With this book, you will learn to:

• Flexible, quick and practical requirements that work

• Save time and develop better software that meets users' needs

• Gathering user stories -- even when you can't talk to users

• How user stories work, and how they differ from use cases, scenarios, and traditional requirements

• Leveraging user stories as part of planning, scheduling, estimating, and testing

• Ideal for Extreme Programming, Scrum, or any other agile methodology

---------------------------------------------------------------------------------------------------------- Thoroughly reviewed and eagerly anticipated by the agile community, User Stories Applied offers a requirements process that saves time, eliminates rework, and leads directly to better software. The best way to build software that meets users' needs is to begin with "user stories": simple, clear, brief descriptions of functionality that will be valuable to real users. In User Stories Applied, Mike Cohn provides you with a front-to-back blueprint for writing these user stories and weaving them into your development lifecycle. You'll learn what makes a great user story, and what makes a bad one. You'll discover practical ways to gather user stories, even when you can't speak with your users. Then, once you've compiled your user stories, Cohn shows how to organize them, prioritize them, and use them for planning, management, and testing.

• User role modeling: understanding what users have in common, and where they differ

• Gathering stories: user interviewing, questionnaires, observation, and workshops

• Working with managers, trainers, salespeople and other "proxies"

• Writing user stories for acceptance testing

• Using stories to prioritize, set schedules, and estimate release costs

• Includes end-of-chapter practice questions and exercises

User Stories Applied will be invaluable to every software developer, tester, analyst, and manager working with any agile method: XP, Scrum... or even your own home-grown approach.

Product Details

• Paperback: 528 pages
• Publisher: Apress; 1st ed. 2005. Corr. 2nd printing edition (August 29, 2005)
• Language: English
• ISBN-10: 1590595084
• ISBN-13: 978-1590595084
• Product Dimensions: 9.2 x 7.4 x 1.2 inches
• Shipping Weight: 2 pounds

I was expecting to have much heureka moments reading this book, but I was let down. Being good in encryption doesn't mean you're good at building secure websites. You shouldn't read this if you have experiences with xss, sql injection and apache with virtual hosts. If you have such knowledge, only read the first 20 or so pages. Pity for this book, I hope I'll find one covering the topic much more pro

Editorial Reviews

Product Description

Pro PHP Security is one of the first books devoted solely to PHP security. It will serve as your complete guide for taking defensive and proactive security measures within your PHP applications. (And the methods discussed are compatible with PHP versions 3, 4, and 5.)

The knowledge you'll gain from this comprehensive guide will help you prevent attackers from potentially disrupting site operation or destroying data. And you'll learn about various security measures, for example, creating and deploying "captchas," validating e-mail, fending off SQL injection attacks, and preventing cross-site scripting attempts.

About the Author

Michael Southwell is a retired English professor who has been developing websites for more than 10 years in the small business, nonprofit, and educational areas, with special interest in problems of accessibility. He has authored and co-authored 8 books and numerous articles about writing, writing and computers, and writing education.

Product Details

• Paperback: 448 pages
• Publisher: O'Reilly Media; 1 edition (May 8, 2007)
• Language: English
• ISBN-10: 0596529260
• ISBN-13: 978-0596529260
• Product Dimensions: 9.1 x 7 x 1 inches

I didn't really like the way were too over-descriptive. The knowledge inside the book is definitely makes it worth to read it. It made me actually get thinking the way of RESTful services. I got answers to all my questions about REST, and now I'm actually building a webservice the way the book told me to. If you can filter efficiently through a big mass of text, this book is for you! You can see a quite big preview on google books

Editorial Reviews

Book Description

Web services for the real world

Product Description

"Every developer working with the Web needs to read this book." -- David Heinemeier Hansson, creator of the Rails framework "RESTful Web Services finally provides a practical roadmap for constructing services that embrace the Web, instead of trying to route around it." -- Adam Trachtenberg, PHP author and EBay Web Services Evangelist You've built web sites that can be used by humans. But can you also build web sites that are usable by machines? That's where the future lies, and that's what RESTful Web Services shows you how to do. The World Wide Web is the most popular distributed application in history, and Web services and mashups have turned it into a powerful distributed computing platform. But today's web service technologies have lost sight of the simplicity that made the Web successful. They don't work like the Web, and they're missing out on its advantages. This book puts the "Web" back into web services. It shows how you can connect to the programmable web with the technologies you already use every day. The key is REST, the architectural style that drives the Web. This book:

• Emphasizes the power of basic Web technologies -- the HTTP application protocol, the URI naming standard, and the XML markup language
• Introduces the Resource-Oriented Architecture (ROA), a common-sense set of rules for designing RESTful web services
• Shows how a RESTful design is simpler, more versatile, and more scalable than a design based on Remote Procedure Calls (RPC)
• Includes real-world examples of RESTful web services, like Amazon's Simple Storage Service and the Atom Publishing Protocol
• Discusses web service clients for popular programming languages
• Shows how to implement RESTful services in three popular frameworks -- Ruby on Rails, Restlet (for Java), and Django (for Python)
• Focuses on practical issues: how to design and implement RESTful web services and clients

This is the first book that applies the REST design philosophy to real web services. It sets down the best practices you need to make your design a success, and the techniques you need to turn your design into working code. You can harness the power of the Web for programmable applications: you just have to work with the Web instead of against it. This book shows you how.

See all Editorial Reviews

For those of you out there who have problem implementing some complex xmls i have a good example for you: Xml : [cc lang="xml" lines="auto"] [/cc] And this is your Class Hierarchy representing it: [cc lang="java" lines="auto" escaped="true"] @Root public class UIElement { @ElementList(name="Elements") public List divContainers; } @Root public class DivContainer { @ElementList(name="DivContainer", inline=true) public List divs; @Attribute public String name; } @Root(name="Div") public class Div { @Element(name="test") public String test; @Attribute(name="name", required=false) public String name; } [/cc] And the serialize code: [cc lang="java" lines="auto" escaped="true"] public void testXml() { Serializer serializer = new Persister(); File source = new File("c:\\tmp\\test.xml"); UIElement ui = null; try { ui = serializer.read(UIElement.class, source); } catch (Exception e) { e.printStackTrace(); } for (DivContainer divc : ui.divContainers) { for (Div div : divc.divs) { System.out.println("Value of test: " + div.test); } } } [/cc] You have to look out for two things... First note the @Root under Div tag. That is necessary there. Writing in the attribute name there is necessary too. Also the 'inline' tag. Without them it wont work. Gergely.