Simple backups for your Mac
Tags [ backups for mac, hosting, Mac OS X backups, rsync, simple Mac backups, ssh ]
You are probably well aware of the need for offsite backups; as a technology professional this is one of the first arrangements I look into for any permanent storage of business information. When I started two years ago for an internal “startup” for a large company, one of the first things we did was set up an SVN repository and then work out an arrangement with an offsite data storage provider.Measure your improvements
Tags [ kaizen, lean engineering, metrics, process improvement ]
Metrics are an important part of any development group’s toolset. If we want to continually improve our ability to develop software (through a lean engineering kaizen approach, or simply as a learning organization), then we need to have a way to figure out: what parts of our process need improvement? when we make a change, did it help or hurt? This is where process metrics come into play. I’ll start with my definition of a metric, which is a numerical measurement of something.Cracking down on technical debt
Tags [ architectural debt, configuration debt, technical debt, transition debt ]
“Simplicity is the ultimate sophistication.” –Leonardo da Vinci. “Everything should be made as simple as possible, but no simpler.” –Albert Einstein “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.” –Antoine de Saint-Exupery I’ve written before about the notion of technical debt. In this post, I want to discuss a few specific sources of technical debt that are easy to accrue, particularly in an agile, iteration-based setting.The Crucible
Tags [ negotiation, prioritization, product owner, Scrum, teams, timeboxing ]
We’ve recently re-adjusted our sprint length to be 3 weeks, down from 4. The reasoning behind this was to allow us to align with sprints on other products, to give us a uniformity of scheduling and to permit inter-product developer swaps from sprint to sprint, if needed. One of the side effects is that our planning process now takes up proportionately more time of the sprint and so the actual work time of the sprint is quite compressed.Sprint Review
Tags [ burndown, estimation, Scrum, Scrum master, sprint review, teams, timeboxing ]
Just wanted to follow up on my previous post about how we were going to get back to scrum basics this sprint. We had our sprint review and sprint retrospectives today, and the sprint was viewed as a great success. Here are some things that I think contributed to our success: Better estimation: We used past task estimation history plus monte-carlo simulation, as I described earlier, to sign up for a set of achievable tasks.REST: Unix programming for the Web
Tags [ architecture, design philosophy, microservices, REST, REST programming, Unix, Web 2.0 ]
I’ve been giving some thought to REST-style architectures recently, and recently re-read some of The Art of Unix Programming by Eric S. Raymond. The author notes that some of the characteristics of Unix-style programming include: Do one thing, and do it well (attributed to Doug McIlroy) Everything is a file. Comprise complex systems by connecting smaller, simpler programs (e.g. Unix pipes). Unix-style systems have had undeniable success and remarkable stickiness for a technology; I have an old copy of my father’s System V manual from when he worked at Bell Labs (yeah, they actually printed out the man pages and bound them!Return on INVESTment
Tags [ INVEST, pre-planning, Scrum, user stories ]
At our last pre-planning meeting, we made a point of putting all the user stories into INVEST format, and I was pleased that there was a general consensus that this worked well. I think this took quite a while, partially because we were all getting used to evaluating the statement of the stories critically, but I think this was worth it. We had product, IA, and engineering folks suggesting wordings for stories, and at least some of our stories came in in a canonical format:INVESTing in User Stories
Tags [ cross-team dependencies, estimation, INVEST, product owner, Scrum, Scrum master, user stories ]
In my previous post I made reference to the INVEST acronym for evaluating user stories: (I)ndependent (N)egotiable (V)aluable (E)stimable (S)mall (T)estable I’d like to spend a little bit of time talking about each of these characteristics, and motivating why each is important through some anecdotes about what happens when each characteristic is not attained. Independent The idea here is that stories are free of dependencies from one another.Back to Basics
Tags [ INVEST, Scrum, sprint goal, user stories ]
I’ve been re-reading Agile Software Development with Scrum to see if it has any insight for some of our current product struggles. Fortunately, I think it does, and I’ve been getting fired up for a great Scrum revival. [ Revival tent picture courtesy of PinkMoose on Flickr, used under a Creative Commons Attribution license ]. I’m going to be reprising my role as Scrum Master for my team next sprint as well, so hopefully I’ll be able to transmit some of these values.REST-based service design, v2
Series [ REST-Based Service Design ] Tags [ CRUD, REST API ]
I want to revisit the basic “favorite food” service from last post, in light of some further discussion I’ve had with colleagues. http://host/path/{userid}/favorites GET: returns a list of the user’s favorite foods, in some representation. Returns 404 NOT FOUND if the user has never specified favorites. PUT: sets the list of the user’s favorite foods to be the value sent, creating it if necessary. DELETE: removes the user’s favorite list.