Can #NoEstimates lead to better decision making on project delivery?
#NoEstimates is a hashtag for the topic of exploring alternatives to estimates [of time, effort, cost] for making decisions in software development. That is, ways to make decisions with “No Estimates”.
Value in a user story narrows scope and adds clarity to what the story is about.
An important motivation for including the value component in a user story is that narrows and refines the scope of the story and adds clarity to what the story is intended to achieve. This helps to ensure that the intent of the story is understood by the reader. It might also prompt questions if the reader disagrees with the value and those questions might lead to better insight or understanding.
A look at Agile Release Trains.
To oversimply but capture the essence of intent a release train separates scope from timeline.
Meyer’s discussion on TDD adds clarity to the murkiness surrounding it--no code without tests.
Meyer points that it's impractical to expect that you not start any development until all tests pass. You may justifiably document the existence of bugs during development and rightly spend your time working other parts of the functionality that are deemed important.
Maybe a little ambiguity goes a long way.
The power of ambiguity in a working agreement is exploration required to remove the ambiguity. A little ambiguity is, in effect, a powerful learning tool for an engaged team.
Tools can create process bottlenecks in unexpected ways.
Tools affect process and shape workflow. They colour how we view the work we do.
Root cause analysis for defects is critical for improving your process.
Defects manifest as a behavioural or functional issue because something isn't meeting the expectation of "working". Since we have a patch for the defect we have a notion of what expected behaviour is. What we don't know is where the problem entered the lifecycle.
The difference between an estimate and a commitment is worth remembering.
An estimate represents a probability of completing a project. It often becomes a commitment to an end date.
Being part of a great team amplifies what people accomplish.
Communities place an emphasis on building mental models as a form of communication. Or more so, creating an environment wherein sharing mental models is rewarded. Recognizing generativity over personal productivity leads to symmathesy. (Symmathesy involves the notion that together we learn.)
Working agreements improve outcomes.
The team has created a working agreement for design reviews. This agreement requires the involvement of two people and the designer. The rationale for this approach is that it promotes better design and knowledge sharing amongst team members. Interactions are critical to good design because different perspectives can identify opportunities and alternative approaches.
A first look at the Agile Manifesto.
Two important things stand out that are very enlightened. First, the acknowledgement that we are still learning how to develop software better. Second, the emphasis on people rather than tools and process.
Yet another look at the Mythical Man-Month.
Yet another look at the Mythical Man-Month.
A look at qunatifying your retrospective data.
I’ve been engaged in retrospective for multiple teams and have always run them with the same principles:
- create an environment where people are free to discuss the good and poor outcomes.
- review our current best practice and revise if we can identify mitigations to prevent poor outcomes.
- drive towards an action or decision on each topic discussed.
Story points are more than just complexity.
I have a problem with relative costing using Fibonacci numbers because it's difficult for me to judge the difference between a 2, 3 and 5 point story. I am much more confident that halving or doubling the cost is an easier question to answer. If I run into a 3 point story I am happy to count it as a 4 and move on because I don't place an lot of emphasis on making "accurate" estimates.
Why you should use story points and the benefits velocity brings.
Duration is derived on Agile projects. It is derived by observing a team's velocity. It is the number of story points in a project divided by the team's velocity.
Applying the cone of uncertainty to software estimates.
Best case estimates are created by expert estimators. Worse case estimates are not considered. Furthermore, you must be diligent in improving and reassessing your estimates otherwise your cone of uncertainty becomes a cloud. The cloud of uncertainty is characterized as that notion of being 99% of the way through a project and having been there for a long time.
When I watch the team interact during stand up I'm dismayed by what I see. It's like I'm looking at two different groups of people. In reality, it's the same people in different situations.
My team hates their stand up. As a manager, it's painful to watch.
The Mythical Man-Month on independent subtasks.
Brook's clearly points out that adding more people to a late project makes it later. He points out that you should resource your schedules so that the number of people equals the number of independent substasks. Then decide if you want to adjust the number of people on the project.
The Mythical Man-Month and the #NoEstimates debate.
The key recommendation is to renegotiate the schedule without adding people and to do so that renegotiation needn’t happen again. This is ideal, but may not be practical because of commitments that require delivery at a specified time. For a look at what insight Brooks has to offer on schedules read Hatching a Catastrophe.
A call to action for the #NoEstimates community.
I'll leave this as a call to action for the #NoEstimates community. Help: identify and characterize the toolkit you are creating and identify the where (the domains) that this toolkit is most effective in.
Some insight from the construction industry on Agile project management.
People will use an approach that produces higher value. If you add this to an approach the embodies high involvement and learning then the approach should be self perpetuating and result in real positive change. For me, these two sentences really make explicit the motivation for Agile methods.
A look at Test-Driven Development in James O. Coplien's article on waste in unit testing.
This debate provides clarity on bootstrapping an architecture. Bootstrapping is hard and the transition from exploring the problem space and defining an architecture to developing executing code involves many tradeoffs. A balance is required. Perhaps poor judgement creates an imbalance that results in the use of TDD too early.
A call to action for more intelligent unit testing.
Coplien isn’t against unit testing. He’s for the intelligent use of unit testing and sees more value in the creation of tests that focus on features. This shifts the focus of the unit under test from a method to a feature.
Working agreements for better design.
Thinking for Programmers says the degree of specification of a program should reflect the complexity and subtlety of what you are trying to achieve. A design might be a couple of lines of prose.
Why I favour principles over prescription.
So I'll stand by the notion that good working agreements are principles because they force interactions. People, when motivated to achieve a goal can figure out the rest.
A introduction to good working agreements.
A working agreement as an informal contract defining a team norm. A team norm is a behaviour that the team wants to develop or maintain. It is an informal contract because the language can be informal but it must concisely describe the desired behaviour.
Working agreements should be unambiguous principles.
My notion of a good working agreement fits the definition of a principle.
A team's working agreements reflect that team's values.
If working agreements are principles and principles reflect values then what do your working agreements say about your team?
Working agreements and the inability to recognize the importance of interaction.
In the cases where these people got it wrong they failed to consider alternative designs or they failed to consider what other team members considered a valuable opportunity for knowledge transfer. It wasn’t a question of whether a design was created it. It was about the communication that would have resulted had they carried out the agreement.
Working agreements as tools for team learning.
I discuss one side-effect of using working agreements as principles and individual decision making. I view those examples as growing pains--an adjustment that people make when the nature of team engagement changes. Those discussions are healthy for a team because they re-enforce a new way of working together.
A book review on Todd Henry's book Accidental Creative.
The bulk of the book describes a framework that Todd says will help sustain creativity over the long term. I love frameworks because of the consistency they provide and because of the insight they can provide if you aren’t dogmatic when applying them. Todd’s framework was refreshing because it is well rounded and brings together elements that he says positively affect your ability to sustain creativity over the long term. I haven’t seen an approach like Todd’s associated with creativity before—much of what I have read on creativity has come from Edward de Bono.
Big Here 6, a kid-friendly movie.
Big Here 6, a kid-friendly movie.
A book review of Ansel Elkin's Blue Yodel.
A book review of Ansel Elkin's Blue Yodel.
A book review of David Moody's Autumn series.
A book review of David Moody's Autumn series.
Nautilus is like the Economist magazine, but with a scientific bent.
Nautilus is like the Economist magazine, but with a scientific bent.
A book review on Scarcity.
The effect scarcity has on people is that it tends to increase focus and create tunnelling. The increase in focus brings whatever is perceived as scarce to the forefront of peoples's thinking but the effect of tunnelling over emphasizes this scarcity to the point where it effects other aspects of their life.
Shakespeare's writing style--more than meets the eye.
The emphasis in Shakespear's writing is not so much on the puns contained therein but on the unexploded puns which retain their energy and create a lasting effect.
A book review for Do The Work!
A book review for Do The Work!
Tickler files for calendar events.
I find that using a separate calendar, different from the one that holds my appointments is useful. Then these optional events aren't in the way of my daily appointments and they don't distract me while I am working.
A look at David Allen's new book "Making It All Work".
Bookmarking has two major benefits. First, it allows you to track where you left off and thereby create a bookmark for the task if you move onto something else. This is handy if you have multiple projects on the go and need to return to wherever you left of on a task at some point in the future. It will certainly help save time when you try and pick up a task and you need to remember where you where. Second, it helps you deal with interruptions.
Managing information more naturally.
The notion I apply to these situations is always that of a parking place. A parking place is a term I use to capture the notion that there should be a natural place to store a piece of information. The new information should fit somewhere.
How I combine Getting Things Done with Covey's time management matrix.
David Allen describes an excellent system for personal productivity in his book Getting Things Done. I make a point of trying to review different sections of his book every few months. I usually review parts of the book that describe methods that feel unnatural or awkward to me. An unnatural or awkward activity is usually a good indicator of where an improvement is needed.
Evaluating how you prioritize is as important as the mechanism you use.
In all, the important message is about managing priorities and about selecting ways that support the identification of your priorities. Evaluating your productivity methods in light of how they help you determine your highest priorities and then focusing on them is a great way to simplify.
Unautomate? Yeah, right.
Unautomate? Yeah, right.
A look at the 6 Level Model for Reviewing Your Work in Getting Things Done.
I am amazed at how much is written about developing a purpose, vision, goals and objectives. So much so, that I am going to add my two cents to the discussion for anyone that wants another perspective on how to achieve this. In what follows, I promise to be short and to the point.
Resources for using QML and C++ models.
Qt uses a variant of MVC that combines the view and controller into a single entity and introduces a delegate.
A closer look at scales of measurement.
A closer look at scales of measurement.
A context manager exploiting Python's _with_ statement.
A context manager exploiting Python's _with_ statement.
Trying out Composite Primary Keys with Qt's QSqlTableModel.
I found the interaction between Qt’s QSqlTableModel and composite primary keys difficult to understand. Those difficulties involved recurrent “No Fields to update” messages from
QSqlError::lastError()when trying to insert. This post captures a small series of experiments to better understand the behavior. I started with a working example from the Qt Forum.
A look at how to deliver reliable software.
A look at how to deliver reliable software.
Domain entities are the most important elements of models.
The important part here is the shift in emphasis from operations on collection to operations on objects.
Another look at the value of code review.
I was pleased to learn from Vaidehi Joshi's article Crafting Better Code Reviews that Steve McConnell’s research included statistics for improvements on code reviews of one line changes.
Another look at better designs.
Design doesn't follow a rationale process.
A look at measurement and its application in software engineering.
If you only measure the code, you will probably not really understand your software or its development process.
A look at measurement and its application in software engineering.
If you only measure the code, you will probably not really understand your software or its development process.
A look at measurement and its application in software engineering.
If you only measure the code, you will probably not really understand your software or its development process.
A look at measurement and its application in software engineering.
Why do we measure? To make things more visible and controllable. Better information leads to more informed decision making. The key is proper selection, collection, analysis and interpretation of metrics.
A look at how to manage database schema revisions.
A database migration involves executing queries to alter the database structure of a live application.
A detailed analysis of how I code provided insight on poor practice.
I started to perform a deeper analysis of my approach to coding.
It's a what changes together stays together world-view.
Ruth references an article by Bjørn Einar Bjartnes titled Undoing the harm of layers. Bjørn makes an argument for avoiding technology-oriented decomposition in favor of domain-oriented decomposition. A technology-oriented decomposition manifests as having your top-level architecture devoid of domain concepts. This type of decomposition spreads domain concepts across different technologies instead of localizing them like you'd expect. This increases the number of modules to change when you update a domain concept.
A Domain-Based Look at Don't Repeat Yourself
The goal of DRY is to retain knowlege in a meaningful way.
A look at DRY in relation to SPOT and OAOO
I got interested in the relationship between Don’t Repeat Yourself (DRY), code structure and knowledge. In my view, DRY is domain based (i.e., system-wide), but leads into structure (i.e., the prevention of code duplication).
A Look at Patterns in Estimates
Estimate bias is the ratio of the sum of time spent to the sum of original estimates.
A Look at Error in Estimates
Estimate bias is the ratio of the sum of time spent to the sum of original estimate for a similar project.
_How to Write Smart Notes_, by Sonke Ahrens
Zettelkasten comprises an annotated bibliography and a slipbox containing your thought's, ideas and questions on topics of interest to you.
Simple graphical technicals to tell you about your data.
Simple graphical technicals to tell you about your data.
Simple graphical technicals to tell you about your data.
I recently took a tour of several programming languages. The objective was to try to implement the same solution in Rust, Haskel and Clojure. The important part of this exercise was that I hadn’t written anything in any of these languages previously.
How do you manage cost in McCall's quality model?
Quality factors affect cost, whether measured in terms of time, dollars or people.
A book review on the book of the same name.
Client-supplier complements SRP nicely because it forces you to extend your thinking beyond the responsibility to how the class will be used.
A look at how to deliver reliable software.
A look at how to deliver reliable software.
Some experience on code patch size.
I’ve had some funny experiences with a couple of positions I’ve held in relation to developers and their position on the size of commits (patches). For me, code review is one part quality activity and another part knowledge share. I prefer to frame code review as a decision on whether the patch is suitable for use in the product or not.
A Look at Problem Frames
A look at focusing on problem solving.
A Look at Problem Solving
Separation of concerns, semantic consistency across layers and non-heirarchical.
A client-side library for Review Board.
Read the Docs lets you create, host and search project documentation.
A look at the statistics underlying the Pareto Chart and how to improve it.
Post-hoc sorting of unordered categories by frequency induces a downward trend on random data.
Recognition that the less code you write the better.
Abstraction as a tool of obsfucation.
What constitutes a single responsibility?
Multiple responsibilities are OK if those responsibilities are expected to change together and if their separation leads to a poorer implementation.
A look at using information theory to measure software.
A look at using information theory to measure software.
Using Python's list() function properly.
Using Python's list() function properly.
A look at a lesson learned using Vagrant.
The value proposition of Vagrant and [Packer](https://www.packer.io) is that virtual machine builds become consistently reproducible--all of the configuration information is scripted and placed under revision control.
A look at James O. Coplien's article on waste in unit testing.
Focusing on features is necessary because it is the only system artifact capable of providing an explicit calling structure (or context) for the objects (and methods) it relies upon. An explicit calling structure is required to reason about the execution of a program.
Use retrospective to continually improve the Definition of Done.
Built into the Retrospective is the requirement that the Definition of Done be improved. It is an explicit manifestation of continual improvement for a Scrum team.
A test for self-organization.
The fact is that your team is at the level of self-organization that it’s at. Accept this. Move on. Seek ways to improve their level of self-organization but don’t get hung up on it. Effective teams don’t need to be self-organizing and they self-organize at different levels.
A model of velocity in 6 months.
I present the velocity during the sprint planning meeting as guidance. As guidance, I acknowledge that velocity is a model of team capacity. The team may have reasons to plan for more or less work.
What does Scrum require you to put in the Product Backlog?
In "Feature-Based Development The Lasagne and the Linguini", Bertrand Meyer raises the spectre of multiplicative complexity and the failure of the user story to address this complexity. In Meyer's view, a user story is too simple to manage requirements except for certain types of systems. User stories become unwieldy if there are feature-based interactions to manage.
Tease out the existing goodness before making process changes.
Not everything needs to change--if the business is producing value something is being done right. The trick is to tease out the existing goodness in what's right and identify small improvements to add.
Good Scrum Masters embody the Artist and Clown archetype.
The Anatomy of Story provided a new appreciation on how stories are constructed. This appreciation can be applied to movies, books and people. I was struck by the similarity between the Artist and Clown archetype and what makes a good Scrum Master.
How important the Scrum Master is to a Scrum team?
A good Scrum Master has a precise and wide-ranging knowledge of Scrum theory, practices and rules, wide experience in applying Scrum theory, practices, patience and ability to allow teams to make mistakes and learn from those mistakes, and humility and understanding both in terms of the Scrum Master's and Development Team's abilities.
Sorting out self-organization in self-organizing teams.
I support that a team should be empowered and that empowerment should include the ability to organize their work. I value the input from the people who work with me and I strive to create an environment where people can contribute to their fullest and can provide constructive criticism. It seems foolish and unwise to do otherwise. This is just common sense.
A comparison of definitions for self-organizing teams.
Is there a difference between self-directed and self-organized teams? If there is, it’s that self-directed teams have leaders with a set of responsibilities that are broader than the team’s responsibilities. In Humphrey’s view, a leader motivates people to achieve goals and provides an environment where team members focus on results and accomplishments. A manager controls resources to produce results.
Developing positive communication patterns.
A huddle is a conversation involving interested parties that occurs after the stand up. I like to origanize my stand up so that we action huddles, including the people who want to participate in them immediately after the stand up ends. The idea of the huddle is that it gets people out of the stand up who have something more important to do while permiting indepth conversation on topics relevant to the work we are doing.
Not sure I like rotating the Scrum Master role through a team.
When I hear about the Scrum Master role being fulfilled by the Development Team it usually includes a concessions to ensure the Scrum Master isn't taking on that role permanently. The motivation behind this concession is interesting.
A look at the FourSquare and LocalMind iPhone applications.
A look at the FourSquare and LocalMind iPhone applications.
We’ve failed to realize the Internet’s promise of cooperation and communication.
While we generally conduct our real-life interactions with strangers politely and respectfully, online we can be horrible. How can we relearn the collaborative techniques that enabled us to find common ground and thrive as a species?
A comment on craftsman is sexist.
In this case, the use of "craftsman" is asserted as exclusionary to women. To disagree requires some creativity. Or insensitivity.
The risk of revealling your real-time location.
The risk of revealling your real-time location.
Location leaking with social media applications.
It is the real time and public nature of Twitter and the ease with which you can provide updates that create the potential for leaking location information. A location leak can be explicit or implicit. An explicit location leak might include Geo Tagging a Tweet or you might mention a location explicitly. An implicit location leak might be something as simple as a Tweet that says you are not home.
Social media as an instrument of ignominy.
The loss of control over who picks up a tweet (or any social media) combined with their social context changes everything. In this case, a Tweet expressing dissatisfaction about a comment on appearance prompts more negativity on this woman's appearance and personality. The people making these comments are likely complete strangers.
A look at Twitter feed service.
A look at Twitter feed service.
A look at what FourSquare and LocalMind does for you.
In "What Job Does Social Media Do For You", Whitney Johnson identifies five jobs that she uses social media to accomplish. I thought it interesting to review jobs in light of what FourSquare or LocalMind might be able to accomplish. Of the four jobs that Whitney identifies as being achievable with social media, two are aligned with jobs that FourSquare and LocalMind are suitable for.
A look at introducing PCI DSS requirements into a workflow.
In Adventures in PCI DSS Compliance, I noted that the relationships between policies, processes, procedures and configuration standards need to be managed to create a meaningful set of documentation. Approaching compliance from this perspective creates a framework that is both consistent and easily explained to stakeholders.
A look at Barbara Liskov's paper on Abstract Data Types.
Liskov and Zilles' paper was written in 1974. It lists thirteen references that provide insight on how abstract data types were arrived at. It's an interesting list of references including work from Dijkstra, Neumann, Parnas and Wirth.
A look at documentation requirements for PCI DSS.
There is no definition of a process in the standard. The reference to "other documentation" in the testing procedures is a catch-all phrase that implies the existence of documentation for managing the configuration standards and processes. These documents may or may not be the policies referred to in the guidance.
Announcement for BSDCan 2011.
Announcement for BSDCan 2011.
A look at the fundamentals of testing.
Every test regime must have relevance and repeatability. To be relevant, tests must confirm the software works and attempt to break it. For repeatability, you must maintain complete control over the environment in which the tests are run.
How not to abuse metrics. Or how to use metrics to support goals.
What's missing from Fowler's essay is language directed at ensuring the responsibility of team members is clear. That's important enough to say again: you need to engage. Whomever you are and whatever your responsibilities. Engage to create understanding and allow for the possibility that your perspective needs to be adjusted.
A look at other essays by Frederick P. Brooks and the importance of hustle.
Hustle and urgency are closely connected. Urgency is an important component of focus. Focus improves execution. If you become excited about a one-day slip you have an opportunity to create a sense of urgency for your project. Urgency increases the odds of recovery and may help you recover lost time and keep your insurance (schedule buffer).
Is it clarity or simplicity we need?
In The thing with code clarity: you can't be proud of something I can't read, Santiago L. Valdarrama makes an plea for clarity. I applaud Santiago's position but think clarity misses the point. I prefer simplicity--the removal of non-essential elements.
Employ quality metrics to support developer and user needs throughout the lifecycle.
McCall's quality model was published in 1977 (see A Framework for the Measurement of Software Quality). It's significant because its one of the first models to capture user experience and developer perspective.
A a consultant to help with the introduction of PCI DSS compliance.
I'll add that the only consultant you want is one that can introduce compliance in a way that is sustainable. They have help create an on-going process.
A look at a client-side library for Review Board.
RBTLIB started life as a project to answer how many review requests were entered into Review Board during a fixed period of time. I extended this project to see if it could become a passable RBTool replacement.
A client-side library for Review Board.
Here I explore another approach using the URI templates provided by Review Board’s Web API.
Abusing design patterns by misapplying them.
Pattern languages have the benefit of describing a system of patterns that support each other. It's a nice approach that has the potential to clarify when, and perhaps more importantly, when not to use a design pattern.
Eric S. Raymond on distributed version control systems.
ESR writes an interesting article on DVCS.
Experiments with the Review Board web API.
Experiments with the Review Board web API.
A look at coding standards for PCI DSS.
The clearest explanation of how to use CERT’s Secure Coding Standards is the document describing the MITRE CWE and CERT Secure Coding Standards. The Mitre Common Weakness Enumeration (CWE) is a measurable set of software weaknesses that includes categories for architectural, design, low level coding and design errors.
A look at the original LISP paper.
The original documentation and papers from John McCarthy are available under the LISP 1.5 Family.
Utility and ease of use have been pursued at the expense of power and simplicity.
In Five thoughts on software, Seth Godin points out that utility and ease of use have been pursued at the expense of power and simplicity and that it is urgent that software companies create tools that increase the quality of what user's create.
Worth remembering: successful tests find bugs.
In my view, the purpose of testing is to find bugs. Thus a successful test is one that identifies a product deficiency relative to its stated requirements. If a test produces a successful result, great. It may be a valuable component of our regression tests but it hardly means we've been successful.
Emotional investment in poor code.
Each time, I created an experimental branch with the idea of exploring what was wrong with the implementation. Every time I did that I had a breakthrough. The two experimental branches have been merged to master and the implementation is better for it.
A look at great paper by Frederick P. Brooks Jr. on the role of tool building.
The key difference between Computer Science and the sciences is Computer Science's need to deal with arbitrary complexity. We don't have the most elegant solutions or the belief that some grand natural design is available and supports our exploration of Computer Science. Many other sciences have this advantage.
A look at a framework for creating well-aligned software metrics.
The chief contribution of GQM over McCall's model is the explicit introduction of goals coordinates based upon viewpoint, purpose, issue and object. The explicitness of the goal coordinates creates a wider perspective for goals.
A look at const-correctness and software architecture.
In all, the main take away I get from James' point is that programming in the small is part of the solution but don't loose sight of the architecture. If you do, none of the const data you create will make any difference whatsoever.
Using a framework to help diminish the requirements gap and to ensure documentation remains in place.
In PCI DSS, Requirement 6.5.5 states that all web applications must be developed using secure coding practices that prevent CSRF. The testing procedure for this requirement seeks to ensure that web applications do not reply on authorization credentials and tokens automatically submitted by browsers.
A look at CSRF and PCI DSS requirements.
In Spoofing Google search history with CSRF, Jeremiah Grossman shows how to create a CSRF (Cross Site Request Forgery) using the Google Web Service. Fortunately, his example is educational rather than destructive. An analysis of the blog entry’s source code reveals a single HTML statement as the primary culprit for delivering the CSRF. CSRF is so prevalent that PCI DSS includes explicit requirements to address it.
A fun look at writing specifications.
If you have struggled with the notion of audience for a specification James' post on specifying refrigerator content does an great job of drawing out this challenge.
How to create your own PyTest decorators.
How to create your own PyTest decorators.
A look at the Arrived iPhone application.
A look at the Arrived iPhone application.
Eastgate's Tinderbox viewer for iPhone and iPad.
Eastgate's Tinderbox viewer for iPhone and iPad.
Text files for storing gdb commands.
How to use command files in GDB.
A look at why I won't purchase an iPad.
My rationale for not purchasing an iPad comes down to two simple facts. First, not everything I want to use on my laptop is available on the iPad. Second, I don't need another device to carry around. I already have a MacBook and an iPhone. The thought of carrying a third device or having to make a decision on whether to take the laptop or iPad with me is not worth the effort.
Another look at why I won't be purchasing an iPad for myself.
Another look at why I won't be purchasing an iPad for myself.
I am royalty.
I am royalty.
A remedy for music library permisions on my Sonos system.
A remedy for music library permisions on my Sonos system.
A remedy for activiation failures on iPod Touch involving DNS.
A remedy for activiation failures on iPod Touch involving DNS.
How to add a Twitter timeline to a Jekyll blog hosted on GitHub pages.
How to add a Twitter timeline to a Jekyll blog hosted on GitHub pages.
Using Eastgate's Tinderbox to explore frameworks.
The benefit of using Tinderbox to explore and use a framework is twofold. First, you gain insight into the framework by developing a Tinderbox document describing it. Second, use the Tinderbox document describing the framework to explore a problem using the framework. It is this second benefit where Tinderbox really shines.
Making my Sonos work because of MAC address changes in the Play:1 and Play:5 devices.
Making my Sonos work because of MAC address changes in the Play:1 and Play:5 devices.
Experience upgrading to iOS 5.
Experience upgrading to iOS 5.
A remedy to correct my LaTeX installation on Yosemite.
A remedy to correct my LaTeX installation on Yosemite.
