BlogThis! is an easy way to make a blog post without visiting blogger.com. Once you add the BlogThis! link to your browser's toolbar, blogging will be a snap. Or rather, a click. Clicking BlogThis! creates a mini-interface to Blogger prepopulated with a link to the web page you are visiting, as well as any text you have highlighted on that page. Add additional text if you wish and then publish or post from within BlogThis!
July 17, 2012
bookmarklet to blogger
What is BlogThis! ? - Blogger Help:
February 2, 2012
reading about retrospectives
retrospective dialogue sheets seems interesting.
using personal kanban/ lean coffee format for retrospective should also work well.
Esther Derby - slides on agile retrospectives.
1. focus, 2. gather data, 3. generate insights, 4. decide, 5. close
http://idiacomputing.com/moin/IntrospectionAndRetrospectives
- including more resources by Esther:
January 20, 2012
change management - agile, continuous delivery, ITIL, CABs
Jez Humble's work blog: Continuous Delivery and ITIL: Change Management
Many large organizations have heavyweight change management processes that generate lead times of several days or more between asking for a change to be made and having it approved for deployment. This is a significant roadblock for teams trying to implement continuous delivery.
.... it’s possible to follow ITIL principles and practices in a lightweight way that achieves the goals of effective service management while at the same time enabling rapid, reliable delivery.
.... Normal changes are those that go through the regular change management process, which starts with the creation of an RFC which is then reviewed, assessed, and then either authorized or rejected, and then (if authorized) planned and implemented.
Standard changes are low-risk changes that are pre-authorized.
....the approval can be made by somebody close to the action – it doesn’t need to work its way up the management chain.
.... Often CAB approval can be a lengthy and painful process. However it certainly doesn’t need to be. The ITIL v3 Service Transition book specifies both that CAB approval can be performed electronically, and that not everybody in the CAB needs to approve every change (pp58-59). Getting agreement on exactly who needs to authorize a given type of change, and making sure those people know in advance the information they need to decide whether to approve it, can mean a fully compliant authorization process that can be performed in seconds in a just-in-time fashion.
.... We can see that ITIL provides several mechanisms which enable lightweight change management processes:
- Standard changes that are pre-approved.
- CAB approvals that are performed electronically, rather than at face-to-face meetings.
- Arranging in advance which subset of CAB members are required to approve each type of change.
.... ITIL follows the common-sense doctrine that each change must be evaluated primarily in terms of both its risk and value to the business. So the best way to enable a low-ceremony change management process is to reduce the risk of each change and increase its value.
....
In a traditional delivery lifecycle, even with agile projects, the delivery cadence looks rather like figure 1. The first release can often take some time: for really large projects, years, and even for small projects typically at least six months.
.... In the world of continuous delivery, .... projects will provision their production environment as part of project inception, and begin releasing to it as early as possible in the delivery process – potentially long before the service is actually made available to users. Further changes are made as frequently as possible
.... Project managers will focus on optimizing for cycle time, ensuring that changes to the system get put live as rapidly as possible.
.... early and iterative release process also exerts a strong pressure to ensure that the system is production ready throughout its lifecycle.
.... The value proposition of continuous delivery – keeping systems in a working state throughout their development and operational lifecycle – is threefold.
.... allows the customer much more fine-grained control over what is delivered, and perhaps even to discover more radical changes that need to be made to the service in order to make it even more valuable. Second, incremental releases from earlier on are much less risky than a big-bang release following an integration phase. Finally, it allows project and program managers real data on the progress of the project.
.... [pre-approved] standard changes should be much more widely used than they are.
.... sufficient level of automated testing at all levels before a build ever gets towards operations-controlled environments. That means implementing a deployment pipeline which includes unit tests, component tests, and end-to-end acceptance tests (functional and cross-functional) that are run in a production-like environment. Worried that pressing the “deploy” button might break stuff? That means your automated testing and deployment processes are not up to snuff.
.... Once all this automation in place, it is possible to kick off a positive feedback cycle.
January 6, 2012
agile testing: who i listen to
with agile testing i'm thinking about work to improve quality, and work to reveal quality (or lack thereof).
first an interesting idea for learning:
testing dojos
http://www.methodsandtools.com/archive/archive.php?id=114
http://www.testingdojo.org/Public+Dojos
a few people:
Gojko Adzik
- http://gojko.net/
- http://specificationbyexample.com/
- (books - esp. the above, twitter)
- focus on living documentation/ spec by example
- ex
Michael Bolton
- http://www.developsense.com
- http://www.developsense.com/blog/
- (blog, twitter, book)
- focus a bit on sentient testing
- don't like scripts so much... (unless automated)
- don't like testing certification so much
- "infoslides", pdf
- ex:
- http://www.developsense.com/resources.html#exploratory
- http://www.developsense.com/blog/2011/12/what-exploratory-testing-is-not-part-2-after-everything-else-testing/
- http://www.developsense.com/blog/2011/12/what-exploratory-testing-is-not-part-4-quick-tests/
- http://www.developsense.com/blog/2011/12/what-exploratory-testing-is-not-part-5-undocumented-testing/
Lisa Crispin
- http://lisacrispin.com
- (blog, twitter, book: agile testing)
- focus a bit on whole team aspect
- ex: http://lisacrispin.com/wordpress/2011/11/08/using-the-agile-testing-quadrants/
October 12, 2011
Vinod Singh: m2eclipse plugin makes M2_REPO variable non modifiable in Eclipse
After installation of m2eclipse plugin Eclipse was not able to resolve the absolute path of the jars in classpath.
The value of the M2_REPO variable was changed itself to some path other than what I configured. When I tried to fix that, to my surprise I can't edit it any longer. It was marked with this text "M2_REPO (non modifiable)".
i experienced the same as this guy, but my solution was not quite the same.
i got eclipse to use an external maven's settings.xml (eclipse preferences -> maven -> user settings), which had a value set to the right location.
September 9, 2011
Testing Email Notifications with Apache James 3.0
Enter Apache James. Not long ago I came across this wonderful blog posting below about using Apache James 2.x in order to test application email notifications:
http://livingtao.blogspot.com/2007/05/testing-application-generated-emails.htmlIT is amazing to see that this is pretty much the only dedicated blog posting on the internet regarding a seemingly very common issue. You would think that almost every serious enterprise application has to sent out email notifications, and be it solely for the "forgot password" feature
....
Anyway, the steps illustrated in the blog above also work nicely for James 3.0
....
Here are the simple steps to get things set up for Apache James 3.0:
Subscribe to:
Posts (Atom)
Posts
