When I say web service scale testing I mean testing to figure out how many instances of your service you need. This type of testing is really easy to explain but typically hard to get right.
Yet another retrospective idea: Successes, Frustrations and Opportunities
During a training I was teaching recently we were talking about retrospectives and different ways to make them interesting. Afterwards one of the students came forward and suggested something interesting.
Posted by cellfish at 09:11 2 comments:
Is logging raw HTTP requests ok?
When you are working on services that need to scale to millions of users you typically come to the conclusion that you will never be able to start a debugger on one of your live services. Instead you need instrumentation (also known as logging, tracing or diagnostics) to make sure you can figure out what went wrong. What I see happening a lot is that developers start logging the raw HTTP request to capture all data. And there are several problems with this approach...
Writing your own LINQ extension methods?
I stumbled upon this article with "best practices" for writing your own LINQ extension methods.
Preventing DoS attacks with puzzles
So when a web service is getting too much traffic it starts returning the 503 status code. Well written services also return the Retry-After header hinting the client when it should come back again. Good behaving clients then respect that or will back-off by themselves to make sure the server is not getting too much traffic. However this is not enough if there are bad behaving clients in the mix. And how do you identify the bad behaving clients?
Posted by cellfish at 06:11 No comments:
Sprint forecast over commitment
Every team I've ever been on that did Scrum (or ScrumBut) have always used the term sprint commitment when it comes to describing the result of sprint planning. Commitment is however a bad word.
Posted by cellfish at 06:15 No comments:
What is the best time of day for stand-up meetings?
Daily stand-ups. Either you love them or you don't. I have tried a lot of different times of day for it and a lot of people wonder what is the best time to do it? But before I answer that I have to remind you that daily stand-ups is the daily planning meeting for the team - not a reporting meeting.
Posted by cellfish at 18:19 No comments:
Where does the Repository belong?
Historically I've always viewed repository objects as part of the storage layer fairly deep down. But I recently had an interesting discussion that made me realize I never really meant it to be that way.
Team Health Check
Teams are important.
Posted by cellfish at 09:10 No comments:
Two types of lazy
I recently updated a bathroom in my house and being given my interest in agile software development and craftsmanship I always find it interesting to work with painters etc since they in theory are the role model for craftsmanship. While greatly impressed by the tile guy the painters surprised me with a new level of laziness.
Posted by cellfish at 02:10 No comments:
Subscribe to: Posts (Atom)