Google-Delicious Mashup

Noda Time is born

skeet — Fri, 06 Nov 2009 10:02:31 -0800

Reading Code: Unity

Mark Needham — Tue, 03 Nov 2009 07:22:56 -0800

I spent a bit of time reading some of the Unity code base recently and I decided to try out a variation of Michael Feathers 'Effect Sketching' which my colleague Dave Cameron showed me.

'Effect Sketching' is a technique Feathers describes in 'Working Effectively With Legacy Code' and the idea is that we sketch a diagram showing the interactions between the fields and methods in a specific class while browsing through the code.

Dave suggested doing a similar thing but with methods and classes instead while stepping through the code with the debugger.

I set up this code to step my way through:

var container = new UnityContainer(); container.AddNewExtension<Interception>();
container.RegisterType(typeof (IIDProvider), typeof (HttpContextIDProvider));
container.Configure<Interception>().SetDefaultInterceptorFor(typeof (GetPaymentBreakdownsService), new VirtualMethodInterceptor()); object resolve = container.Resolve(typeof (GetPaymentBreakdownsService));

These are some of my observations from this exercise:

I found it was much easier for me to remember where I was in the call stack then normal.
I often get quite engrossed in the individual method calls on objects that I forget where the code actually started before it ended up in the current location. Whenever this happened I was able to refer to my sketch to remind myself of where the code had started from.

Despite having the drawing I still got a bit lost when the PolicyInjectionBehaviourDescriptor made a call back to the container's Resolve method which meant that the code went through the same path that I'd just followed:

public IInterceptionBehavior GetInterceptionBehavior( IInterceptor interceptor, Type interceptedType, Type implementationType, IUnityContainer container) { InjectionPolicy[] policies = container.Resolve<InjectionPolicy[]>();

I was getting really confused watching various different injection policies being resolved instead of the type I was trying to resolve!

I've previously tried drawing diagrams which just contained the classes in a code base but I've found that including the methods that connect them makes it easier for me to understand what's going on.
I've been drawing these diagrams out by hand but I thought I'd translate some of it into dot notation so that I could create a version using graphviz to show on here.

The nodes in orange represent classes and the dotted line represents where an event was fired.
I realised that I still need to spend more time reading code so that I know when to dive into an object and when the details are probably not important. At the moment I'm too prone to getting distracted by wanting to see how a specific method works instead of looking at those details later on when I actually need to know.
I felt as I was reading the code that in a lot of places the option type from functional programming would have come in quite useful. There is often code similar to this bit from LifeTimeStrategy:
```
object existing = lifetimePolicy.GetValue()
if (existing != null)
{ context.Existing = existing context.BuildComplete = true
}
```
Instead of existing returning a null it could return 'None' to indicate it hasn't been resolved yet.
I've read about the 'yield' construct before but I've never seen a need to use it yet in any code I've written so it was interesting to see it being used quite frequently inside PolicySet:
```
public IEnumerable<InjectionPolicy> GetPoliciesFor(MethodImplementationInfo member)
{ foreach (InjectionPolicy policy in this) { if (policy.Matches(member)) { yield return policy; } }
}
```
From my understanding of this construct it seems like it acts in a similar way to a stream i.e. it's only evaluated when it's actually needed.
In the 'Fundamentals of Object Oriented Design in Uml' Meilir Page Jones suggests that we might want to avoid replicated behaviour in our public APIs since it leads to greater complexity.
This would therefore seem to suggest that having overloads of methods on an object is something to be avoided. Interestingly in this code base the overloads for 'UnityContainer' are actually defined as extension methods which then delegate back to 'UnityContainer' and pass in default values for unspecified parameters.

This seems like quite a neat way of getting around the problem since we keep the API clean while also providing users of the code an easy way to do so.

On the subject of reading code I recently came across an interesting post by designbygravity which describes some approaches for reading code more effectively.

In particular I really liked the section about not hating the code :

You can get sucked into hating the code, merely because it is not yours. Software people tend to be equipped with ample egos, and other people’s code can offend. But realize, their working code is better than your imagined code, because their working code exists right now. So put your ego aside and learn the code in front of you.

It's so easy to drift into this mindset but it's rarely helpful so if we can stop ourselves it's almost certainly beneficial.

MVP Again

skeet — Fri, 30 Oct 2009 14:14:09 -0700

Today's Top N

Catherine Powell — Wed, 21 Oct 2009 13:51:00 -0700

I don't drive very often - I live and work within the city, and I tend to take the T to work and pretty much everywhere else, too. Consequently, I don't listen to the radio very often. But this weekend I was on a road trip and I had the radio going. I kept hearing the same theme over and over as I flipped around the stations:

"Today's Top 10"

"the Weekly Top 20"

"Top 5 Countdown"

And I remember thinking, "What a good idea!"

After all, the top 10 songs, or top 20 albums, or whatever, are in some ways like the parts of our test plans:

some of them are the same over and over again: how many weeks is one song at the top of the charts, or at position two or five? Same thing with areas of code.
some of them change each time: eventually a song falls off the list, and eventually we're comfortable enough with an area of our test plan that we move on.
they sound a little different every time: maybe this week it's the dance mix and next week it's the acoustic version - same underlying thing, just a bit different.

So why not? Let's embrace the theme!

We happen to be really close to a release. So for this week, we're having the QA Top 4 (there are four of us, so this makes it easy). Every morning, we come in and pick the four areas we're currently least comfortable with, as a group. We all throw ideas around until we agree on the four. Then we go work mostly on those four items - they're the top of our list for the day. The next day, we repeat the procedure. Maybe it's four different items, maybe some of them are the same and some new - doesn't matter, really. But that's the new QA Top 4. So we work those new four for the day.

The idea here is that we get a chance, every day, to re-identify the scariest areas of the code. And then we work on them. If they're still scary, we'll work on them again the next day. If not, we'll work on the new scariest areas.

There are a lot of ways to prioritize things, but having new ways to think about it sparks new ideas. This is just a new (to me, anyway) way to present that old risk evaluation, and hey, it's kind of fun.

(And by the way, you should see the jokes.... "Replication, by the Again Agains" at #1, and "Defect Verification" off the "Oh Boy It Worked!" album at #2. We're pretty easily amused!)

Adding Variability in Test Case Design

I.M.Testy — Mon, 19 Oct 2009 19:03:00 -0700

Worst Practices for Domain-Specific Modeling

(author unknown) — Mon, 12 Oct 2009 06:52:41 -0700

Using UML takes 15% longer than just coding

(author unknown) — Wed, 07 Oct 2009 06:20:51 -0700

Book Club: Integration tests are a scam (J.B. Rainsberger)

Mark Needham — Tue, 06 Oct 2009 06:37:52 -0700

In our latest book club we discussed J.B. Rainsberger's presentation from Agile 2009 titled 'Integration tests are a scam'.

These are some of my thoughts and our discussion of the video:

While talking about how to write interaction tests he suggests that we should only be looking to create interfaces for Domain Driven Design services. If we find ourselves wanting to create interfaces for entities or value objects then we probably have a service wanting to get out. We should try to extract that responsibility out into a service.
I'm intrigued as to how repositories and factories would fit into this picture as I'm not sure whether they count as services, entities or value types. I've worked on code bases where we've created interfaces for them but I don't know if that means they would be services or that we did something wrong.

There also seem to be varying schools of thought on whether or not we should tests these types of things directly or whether we should just make use of them in our code and judge their correctness that way.
Rainsberger's main gripe seems to be with tests which cover more than one interesting behaviour and he identifies the slow feedback and complexity of test setup as being undesired consequences of this approach.
My feeling is that he was mainly referring to tests written directly from the UI although several colleagues suggested that tests where we call the code directly while using several real objects had the characteristics of the integration tests that Rainsberger dislikes. Ayende is having some success with what he coins 'system oriented tests' which sound similar to the latter so there might be something in this approach.
Rainsberger's solution for testing our systems thoroughly is to make use of contract and interaction tests – the former testing the real implementation of services and the latter the way that our objects work together with each other. Essentially making use of mocking as far as I understand.
He also suggests the need for a tool which would be able to indicate that every interaction test we write has a corresponding contract test which sounds quite similar to the NSynthesis tool that a couple of my colleagues have worked on. This tool only tests that we do have a contract test for each mock rather than testing with the exact parameters used in our interaction tests as Rainsberger describes. If I understand this correctly then that would seem to result in a lot of tests!

I think we still need some integration tests that go through the user interface particularly if we are writing javascript heavy front ends – from my experience only using unit tests doesn't take us the whole way to having confidence that this type of code works.

It is perhaps useful as a rule of thumb to test the happy path of pieces of functionality through integration tests and try and test the edge cases from tests that sit further down.
I like the idea that acceptance tests are supposed to be clarifying requirements and not testing correctness although it seems to be really easy to cross the line where they do end up verifying the correctness of our application.

Rainsberger has an interesting post on his blog where he goes through the feedback he received from the talk.

I'm not sure if I totally understand contract tests at the moment – there is a post on Rainsberger's blog which explains it a bit more and my colleague Danilo Sato wrote a comment on a post I wrote about using generic abstract classes for testing suggesting that this approach is similar to the one Rainsberger is advocating.

[Other] Research Stimulus

(author unknown) — Sun, 04 Oct 2009 00:00:00 -0700

[SOA] The Case for Reuse: if only developers would spend less time at their keyboards or play station

(author unknown) — Fri, 02 Oct 2009 11:33:54 -0700

Shared by turker
Reuse is not about reusing what has been written, reuse is about being able to modify what has been written without impacting whoever is currently using that code. Once you'll understand that, everything will be different.

A reader on InfoQ, Udayan Banerjee, commented about reuse.

Opportunity to use code without making any modification is very rare. There is always some architectural variation between different product line / project.

Effort required to modify an existing piece of code is much higher.

If the change required is more than 20% then it may be easier to rewrite the code.

To write a piece of code which can readily be reused requires significantly more effort – factor of 3 is a reasonable estimate.

Therefore, to derive benefit the code needs to get used at least 4 to 5 times – so large number of product lines with identical technology is basic necessity for reuse.

I would just say two things:

1) If you don't understand how versioning is intimately related to reuse, just look at the services you consume in your everyday life. How often are you notified that a service changed? how offen are you impacted when a service changed? If you don't understand anything about Forward versioning, start here. Reuse is not about reusing what has been written, reuse is about being able to modify what has been written without impacting whoever is currently using that code. Once you'll understand that, everything will be different.

2) Reuse IS-NOT an option. Look around in the enterprise, every single business object, in every single industry: PO, Invoice, Payment, Customer, Account, Product..., every single BO in every single industry has a lifecycle, this lifecycle is independent of the processes in which the BO, a.k.a resource, participates. Not reusing a BO lifecycle is the absolute black hole for IT. This is why duplicated business logic ends up in different places and everything is hard to change and integrate. Not reusing BO lifecycles has vast implications in terms of cost, compliance, security...

At the end of the day there are technologies and a programming model that help with reuse. This is not true of any technology or any programming model. The technologies and programming models that Computer "Scientists" have pushed down the throat of IT for decades are all MVC based (even the way RESTafarians use REST is MVC based), that is the problem, not the solution.

Calculating Velocity

Catherine Powell — Fri, 02 Oct 2009 06:39:00 -0700

When we're doing estimations, one of the tools I use is what I call a breadbox sizer. Basically, this is a tool to help us figure out how much work we should be committing to in an iteration - it's a measure of our velocity. Here's how it works:

Categorize the things you've done.

The idea here is to create a list of the things you work on. Usually this is features or product areas. You can also put performance testing or other categories on there. This is basically how you categorize your testing effort. For example, my categories include:

GUI management
CLI
Test Infrastructure
HA
Replication and snapshots
...

Try to keep this between 10 and 20 categories. Fewer than that and you'll be putting too much in each category. More than that and it gets unwieldy to work with.

Put your past stories in the categories.

Go back over the last three or four (or more if you can) iterations and put the stories/features/tasks you worked on into the categories you've created. For example, we just did a story "add separate timeouts to setup, test run, and teardown". That would go in the "Test Infrastructure" category.

Layer in the estimate sizes for each item.

This part is important. Take the size of the story as you estimated it, and add that to the category for that iteration. I don't care how long it actually took you. I care about how much time you thought it was going to take up front. (We're going to use this for estimates, so I care about how much of your estimated time you actually got done. We don't need another layer in the middle to translate "estimated time" to "actual time" worked.)

For each story, decide if it was "small" (1-3 units), "medium" (3-5 units), "large" (5-10 units), or "extra large" (bigger). If one category had multiple stories, add them up and put the overall time spent in that category. You'll wind up with something that looks like this:

Translate that into work done.

On the spreadsheet we're going to total the work done. Basically, we add 3 for every small, 5 for every medium, etc. This gives us the total amount of estimated work that we actually wound up doing in each iteration. Our example now looks like this:

In our first iteration, we managed 8 units of work, total. In our second, we got 15 units of work. In our third iteration, we did 16 units of work.

Get to a common denominator

Now we start dividing by the things that change. For example, during iteration 1, one of our QA engineers was on vacation, so we had two engineers. During iterations 2 and 3, we were at full strength. So we're going to divide this up to define how much work per engineer per iteration we can do. In addition, our iteration 3 was three weeks long (doesn't matter why for this example), but the first two iterations were two weeks long each. So we divide that up, as well. This gives us a number per person per week.

Make Conclusions

So now we know that each QA engineer can do about 2.5 units of estimated work each week. When we go into the next estimation session, that's where we'll draw the line for test work. We estimate just like we always do, and we then will walk down the list committing to 2.5 units of work per week. When we run out of allotted time, we'll stop. (By the way, our 2.5 is days, so we're getting about 50% effectiveness; my general experience says that's about right, and the rest of the work day is spent on email, meetings, escalations, sales assistance, and other tasks.)

There are a number of ways to calculate velocity. Many of those methods involve calculating how much time you actually spent, getting a velocity of actual time, and then working to get your estimates to match up how much time you spent. You can choose to go this way; it's perfectly legitimate. However, I prefer the way I've outlined here simply because it avoids the fuzziness factor you get when trying to figure out how much time you actually spent (which I find really hard to do).

So see what you find when you calculate your velocity. Good luck!

Agile Leadership: Methodology Ain't Enough

abby — Tue, 29 Sep 2009 06:26:00 -0700

A lot of people say you can’t be a good software manager without really understanding software development. But, let's face it, people who understand software development are a dime a dozen in our industry. What we really need are people who understand leadership & management. I mean... you know the drill – when was the last time a software project failed for technical reasons?

And so, it was very cool to hear David Spann share his research on Finding and Developing Agile Leader’s at last week’s ScrumClub.

It’s simply not enough to know the latest agile practices. In order for agile projects to succeed, they need leaders who exhibit agile behaviors and, here’s a hint – being a technical guru ain’t one of them.

Now, I don’t want to mislead – David isn’t saying agile leaders don’t have to know anything about software development. What he is saying is that the success criteria for leading agile teams is dependent on the leader’s beliefs and behaviors. That is, how they think and act is just as - if not more - important than what they know.

Beliefs

David identified 5 underlying beliefs that a successful agile leader should hold.
How many of these do you hold? How many does your manager?

1. A group of well intentioned, skilled people will make a better decision through consensus then I can on my own.

2. Five or more people with a single, clear purpose can (and often do!) change the world.

3. Asking the right questions will always create better outcomes then making a series of well-crafted statements.

4. The leadership role is about creating a great environment in which others can succeed.

5. Trust is the foundational component of any relationship and it must be tended to with care, integrity and humility.

Behaviors

David identified the behaviors that make agile leaders successful and from that came two very interesting observations:

The behaviors that make agile leaders successful are, largely, the same behaviors that make Facilitators successful.

The behaviors that cause agile leaders to fail are, largely, the same behaviors we seek when hiring Project Managers.

Behaviors We Want in our Agile Leaders

Strategic. Agile is very pragmatic, with a strong emphasis on the here & now. YAGNI, defer decisions, no Big Up Front anything. And so, it's interesting to see strategic, "taking a long range approach," as a key success criteria for agile leaders. I think this underscores the importance of having a clear vision for the team to rally around, and the need for our leaders to be thinking ahead to make sure that we're not just moving forward - but moving in the right direction.

Tactical. At the same time, agile is very pragmatic, delivery focused. So our leaders need to emphasize the importance of continuously delivering value by focusing on "short-range, hands-on, practical strategies."

Innovative. We are out there, every day, responding to change, creating things no one has before. Our leaders should be open to new ideas, willing to take risks, and comfortable with agile's level of change.

Excitement. We want our leaders to be passionate! To have excitement and energy and enthusiasm, and to pass that passion on to the team and make it felt by all who come in contact with it.

Communication. Agile is about bringing people together to produce more than they could individually. Those 5 people with a clear purpose out there changing the world. This requires communication, "stating clearly what you want and expect... clearly expressing your thoughts and ideas; maintaining a precise and constant flow of information."

Consensual. Agile teams are about respect. Leaders value their team's ideas and opinions and demonstrate this by using their position to help the team gain consensus on how to proceed rather than just telling them what to do.

Delegation. Agile teams are about trust. Leaders encourage this by enlisting team member's strengths to achieve results and giving the team autonomy to make their own judgments about the best way to meet objectives.

Empathy. Agile leaders empathize with and support their team members.

Behaviors that Hurt Agile Teams

Authority. Leaders who are - and believe others should be - deferential to authority, tend to be liabilities on agile teams. Agile teams need to be continuously on the look out for new and better ways to do things and a great way to kill that that is by saying "nope, we don't allow new ideas unless they come from/are approved by the guy at the top."

Structuring. The Plan-Driven Manager who spends weeks devising the "perfect plan" and the rest of the project aligning everything back to that is in direct opposition to the team's agility. Per the manifesto, agile teams value responding to change over following a plan.

Conservative. If it ain't broke don't fix it, says the conservative leader, while agile says, "what can we do better?"

Technical. While some technical understanding is good, being an expert is not only unnecessary but, as we've all seen, can be detrimental. We need our leaders helping us with communication and vision and supporting us to get the work done, not busy doing it all - or coming up with all the answers - themselves.

When we look for managers in our organizations, what kinds of traits do we look for? Managers should have Authority, right? And, just look at the PMP - you know, the thing that tells us how to manage projects - about 90% of it's Body of Knowledge is around planning, so Structuring must be important too. Conservative? Sure, old white guys in suits, right? ;-) And technical... well, we all know what role the techies get promoted to when they do a good job.

What about YOU: Which beliefs and behaviors do you see in your own agile leaders? What about in yourself?

--
Learn more in David Spann's articles on his research into Agile Management Behaviors:
» Agile Management Behaviors: What to Look For and Develop
» The Facilitative Mind of Agile

New! See Patrick Wilson Welsh's response: Agile Team Lead : Useful New Role?
which takes this idea to the next level, and join in the conversation!

‘Exploratory Software Testing’ – a cheat of a book

adam — Mon, 21 Sep 2009 06:15:56 -0700

Much like in software, when you release a book into the hands of the masses it is largely out of your control. Part of the lack-of-control with a book is the review process where you send out free copies to people who have a platform in hopes they give it a nice review (thus garnering more interest and sales). I’ve been doing this the last week for Beautiful Testing and I get books sent to me periodically. James Whittaker’s Exploratory Software Testing is one such book that landed in my mailbox, but the review is not going to be positive.

Lack of control sucks.

I really wanted to like this book. Exploratory testing is an extremely powerful technique which is largely passed from person-to-person rather than through books. This lack of textbook presence keeps it out of University curriculums. But when reading it, the only word I kept thinking of was cheat.

At its core, Exploratory Software Testing is about the useful metaphor of a tester as a tourist and the software their destination. An application, like a city, can be broken down into a number of districts (business, historical, tourist, entertainment, hotel and seedy) and for each district a number of ‘tours’ can be had (guidebook, money, landmark, intellectual, fedex, after-hours and garbage collectors for the business district for example). This metaphor is fantastically developed and is quite useful in developing a testing strategy.

But is that metaphor enough to justify a book? No. Not really. I wouldn’t dream of pitching SLIME as an entire book though I think it is just as useful to keep in mind as being a tourist. More on that in a second.

But first…

I took James Bach’s Rapid Software Testing August of 2005 (during hurricane Katrina) and during it there was a discussion of ‘tours’ you can take through an application. Specifically Mike Kelly’s FCC CUTS VIDS was mentioned. Mr. Whittaker joined Microsoft in 2006 and started to develop the idea of tours of there (on the soccer pitch according to Alan Page who did the Foreword) which ultimately culminated in this book. Now, there is nothing wrong with taking an idea and evolving it. We’ve all done it. But when you do that, you are obligated to say that is what you did and to cite the sources. The lack of background material in Exploratory Testing is a concern. Not only is there no mention of people who did work on the Testing-as-Touring idea, but there is no mention of people who are known thought leaders in exploratory testing. You mean to say you can write a book on exploratory testing without mentioning James or Jon Bach, Cem Kaner or Michael Bolton? Really? What does that do to your credibility on the subject?

The lack of citation is actually not my biggest criticism of Exploratory Testing. Like I said, I think the metaphor is wonderful and a useful addition of testing lore. My biggest complaint is that the book even got published.

Exploratory Software Testing is 224 pages in length and if we operate on the premise that the tour metaphor is the main focus of the book then it should be the majority of the content. Right? Well, James’ work on it lasts for 39 pages (chapters 4 and 5). Total. In fact, the original work ends on page 143 at which point he reprints a bunch of StickyMinds articles and his MSDN blog for the remainder. Even that content before the reprints isn’t all his. The chapter after the tour metaphor is finished is mini-essays (34 pages) by people inside Microsoft who have used tours successfully on their project.

In short, there isn’t enough content to warrant publishing a book that retails for $39.99 USD ($47.99 CDN). Take the tour metaphor one more step and bind it as a pocket tourist guide that sells for $15 and you have a winner. But for this price and packaging, unless you have an unlimited book budget, I can’t recommend that you pick it up. Eventually someone will post a description of each district and its tour and a few minutes of google-fu will give you the same value and still have enough money in your pocket for a week’s work the lunches.

Having been through the book process once this feels a lot like the publisher saw that they could sell a bunch of books based on the author having had successful books in the past and a title that is somewhat misleading but popular in their target audience’s lexicon rather than producing something of lasting value.

Here is another thing from the publishing world; they really don’t like publishing a book with the same(-ish) title as an existing one. Especially in the same subject matter space. It is a shame that this book is what will forever carry the mantle for exploratory testing.

Who Owns Quality?

alanpa — Fri, 18 Sep 2009 02:29:19 -0700

TDD: Testing with generic abstract classes

Mark Needham — Thu, 17 Sep 2009 07:40:09 -0700

In a post I wrote earlier in the week I described a dilemma we were having testing some code which made use of abstract classes and Perryn Fowler, Liz Keogh and Pat Maddox pointed out that a useful approach for this problem would be to make use of an abstract test class.

The idea here is that we create an equivalent hierarchy to our production code for our tests which in the example that I provided would mean that we have roughly the following setup:

public abstract class ParentModelTest
{
} public class BusinessProcess1ModelTest : ParentModelTest { }
public class BusinessProcess2ModelTest : ParentModelTest { }
public class BusinessProcess3ModelTest : ParentModelTest { }

We then want to create an abstract method on the 'ParentModelTest' class to create the object under test and we'll implement this method in the sub classes.

We can then put the common tests into the abstract class and they will be run when we run the tests for each of the sub class tests.

My colleague Matt Dunn and I were looking at how you would implement this and he pointed out that it provided quite a nice opportunity to use generics to achieve our goal.

If we make the abstract test class take in generic parameters then it allows us to create our specific type in the 'create' method rather than having to create 'ParentModel' and then casting that for our specific sub class tests.

public abstract class ParentModelTest<T> where T : ParentModel
{ protected abstract T CreateModel(); [Test] public void ShouldTestThoseCommonDependencies() { var model = CreateModel(); // Do some awesome testing that's common across all 3 sub classes here }
}

[TestFixture]
public class BusinessProcessModel1Test : ParentModelTest<BusinessProcessModel1>
{ protected override BusinessProcessModel1 CreateModel() { return new BusinessProcessModel1(...); } [Test] public void ShouldDoSomeEquallyOutstandingStuff() { var model = CreateModel(); // and test away }
}

It seems to work quite well and we realised that it's actually a pattern that we had also used to test that our controllers would actually be injected with all their dependencies from our DI container or whether we have forgotten to register some of them.

We have an abstract class similar to this which all our controller tests extend:

public abstract class ContainerTest<T> where T : Controller
{ [Test] public void ShouldHookUpAllDependencies() { var container = CreateTheContainer(); var controller = container.Resolve<T>(); Assert.IsNotNull(controller); }
}

public class AwesomeControllerTest : ContainerTest<AwesomeController> { }

When we haven't got all the dependencies injected correctly the code will actually blow up on the resolve step so the last line is not strictly necessary but the test seems like it's not testing anything at first glance without it.

My Get-Back-To-Work Hack

Alex Payne — Mon, 14 Sep 2009 00:00:00 -0700

My Get-Back-To-Work Hack

I’ve been looking for a way to fight distractions on the web. I’ve tried SelfControl, but just getting a “server not found” error in the browser when I visit a temptingly unproductive site isn’t particularly motivational.

The hack for this I came up with today is cheap and dumb, but it works. If you want to be sure it’s worth your time, watch this 46 second long screencast, then read on if you like what you see.

If you’re an experienced web developer, this will probably take you all of ten minutes to set up. If not, I’ve tried to explain it in pretty friendly terminology, but you might want to grab the nearest techie to help you out.

Step One: Block Distracting Domains

The /etc/hosts file tells your computer where other computers are. Normally, this file is almost empty; it just points your computer at itself, reminding it that its local address is 127.0.0.1. Your computer doesn’t need to know much more than that because it uses DNS and similar protocols to find other computers over the network. Still, every time your computer tries to talk to another computer, it checks /etc/hosts to see if we’ve specified the other computer’s address.

We can make use of the /etc/hosts file to block specific domains that we shouldn’t be spending time on. We just associate those domains with a bad address – in this case, the address of our local machine.

My /etc/hosts looks like this. It’s the lines below the commented-out line about “distractions” that matter. Those lines say that the specified domains are served by my own computer. They aren’t, of course, so when I visit those sites, my browser gives me an error page.

Go ahead and put your own time-wasting sites in there; be sure to add the “www.” variant, if the site has one. If you like, you can collapse all the domains onto one line after the “127.0.0.1”, but I find it easier to read over multiple lines.

To an extent, this solves the problem: if you visit one of the domains you added to the file, you don’t get there. But as with SelfControl’s solution, an error page in your browser isn’t very motivational. Let’s go further.

Step Two: Serving Content for Blocked Domains

Since we’re directing requests for distracting domains to our own system, why not do something with those requests? Fire up a web server on the usual port (80). On a Mac, this is as simple as going to Sharing in System Preferences and ticking the box for Web Sharing. The text there may say that your computer’s website is available at some fancy address, but it’s also available on http://127.0.0.1/.

Now, visit one of those sites you put in your /etc/hosts. You get a real webpage this time, right? Most likely, it’s whatever default page came with your web server software; it might say “It worked!” or something equally inane. The name of this file is probably index.html.en (or maybe without the “.en” part). On a Mac, it lives at /Library/WebServer/Documents/index.html.en. You should modify that file. Make it pretty, but not too pretty. Put a message in there that’s motivational to you. Visit one of your blocked sites, and you should see your custom message instead. Pretty good.

There’s a problem, though. Say you blocked dumbsite.com. If you visit http://dumbsite.com/foo/bar/baz.html, you’ll get a 404 File Not Found error from your local web server. That’s because you don’t have the files and directories the server is looking for inside the default folder your web server stores web pages in. You don’t want to have to provide these, either; you just want to serve the same page for every domain you’ve blocked.

If you’re using Apache, you can use a couple of lines like this inside your httpd.conf to rewrite any URL to point to a file in your document root (in this case, index.php, but change that to whatever you want). That will get you back to seeing your custom page when you visit a blocked domain, regardless of the URL.

If you want to keep it simple, get all that working and stop here. You’ve got a nice custom reminder to get back to work, and few moving parts to maintain. If you’re comfortable setting up PHP, though, venture on for a little gravy.

Step Three: Doing Something Useful with Blocked Domains

I didn’t just want a motivational message. I wanted a reminder of exactly what I should be doing.

Once I got the above working, I flipped on PHP in my httpd.conf and set Apache to run as my user. Then, I changed my index.php to this. The key lines are at the bottom. They tell PHP to fire off a command, just as if I issued it from a terminal. In my setup, the command will fire up Things if it isn’t running, or move it to the front of my windows if it is.

Variations

There’s a bunch of ways you could do this differently. Rather than modifying /etc/hosts, you could firewall off any distracting domains. You could run your own HTTP proxy and do the filtering there. Or, rather than popping up an application, you could have that PHP script (or however you decide to implement it) pull your to-do list right into the admonishing web page. Or, you could, y’know, just use plain old real actual self control. But that’s easier said than done, I’ve found.

What you do with the block page is really up to you. All I know is, popping up my to-do list works for me as motivation to get something done. I took a couple extra steps and ensured that only my local machine could get to that page, so folks on my local network couldn’t be popping up Things all day long by hitting the right IP in their browser. Other than that, I haven’t wanted to do anything fancier. That’s not really the point, after all.

Incidentally, I’ve found that limiting my consumption of distracting domains to the iPhone is a good way of regulating my time. If I have my iPhone in hand for more than a minute or two, I’m probably waiting around for something, in which case it wouldn’t hurt to see what’s up on Hacker News. Because reading on the iPhone isn’t optimal, I’m not likely to get lost in a sea of interesting links for an hour or two.

Six Hopes for This Year's Microsoft Company Meeting

noreply@blogger.com (Who da'Punk) — Wed, 02 Sep 2009 22:50:00 -0700

And the Winner is…

marlena — Mon, 31 Aug 2009 19:11:35 -0700

My last semester of school ever has begun. For the past few months I’ve been going back and forth about what I would study. I wrote a previous post about some of my options. The school I attend is very application based. There’s not a lot of research going on and most people just want the piece of paper. No one here expects a fancy internship at Microsoft or Google. Those recruiters have yet to show up on our campus. Students at Southern Poly just want their resume to look good. This means that the majority of people here focus on acronyms.

In looking around for a topic, I initially looked at holes in my skillset and the acronyms involved. I’m not that great with xml, css or xslt. I haven’t worked with SOAP, REST or LAMP. Although my thesis is about data visualization for software quality, I was telling myself that my thesis work should be enough “fun stuff” for me to be satisfied. Then I remembered how my parents relentlessly convinced me that a career should not be fun.

As a high school student, I was obsessed with a career in technical theater. I loved the design and build of sets. To me it was the creation of a new world within the limited space of a stage. There are just as many theater classes on my high school transcript as math classes, and I was committed to finding a great theater program for college.

To say that my parents were not encouraging is an understatement. They were so pissed off! Oh, the screams! For them, the only real jobs were the ones listed in the classified section of the Sunday paper. “Show us a ‘want ad’ for set designer,” was their common refrain. I heard this over and over for months in the living room, in the car on my way to freshman year in college, on the phone when I was at school. Eventually, they repeated this often enough that I became discouraged and dropped out of the theater program at Appalachian State.

Last week, it was finally time to put my intentions for this final semester into the system. As the acronyms were cycling through my head, I reflected on this whole show-me-the-want-ad mentality, and realized that I was in a similar situation with my last semester. I’ve got all the practical, resume-enhancing choices behind Door #1 and the topic with no want-ad attached, data and software visualization, behind Door #2. I can just see the indignation on my parent’s faces.

This is how I know, absolutely, that Data Visualization is the RIGHT choice. My thesis advisor (bless him!) helped me put a curriculum together for a survey of data visualization with a focus on software. I feel like I’ve gone back in time and re-traced my own steps. It’s like I’ve gotten a big, fat do-over as my SPSU swan song. The new Stephen Few book, Now You See It: Simple Visualization Techniques for Quantitative Analysisis my textbook along with Software Visualization: Visualizing the Structure, Behaviour, and Evolution of Software..

Even if I never have another job where I use this, even if I have to keep it as a hobby forever, it’s priceless to me that I will have the time and faculty support to broaden my expertise in this area. I have the rest of my life to learn “REST.” The important acronyms seem to change after 3-5 years anyway. At this point, I know that Data Visualization is not going anywhere. That might actually make it the most practical even though there’s no want-ad for data visualization specialist in the paper.

BTW, my parents eventually realized the damage they had done when I ended up an overqualified (and miserable) secretary. It took a few wayward years and another college degree, but I finally realized that sometimes it is necessary to ignore your parents.

Sample: Parsing Content in C# Using IFilter

Jasonz — Mon, 31 Aug 2009 00:09:06 -0700

Motley says: "What's wrong with mixing Scrum and Waterfall? You get a nice 'Scrummerfall'!"

James Waletzky — Tue, 25 Aug 2009 10:45:00 -0700

Windows 7 Party: Sent from mobile phone

Fri, 07 Aug 2009 23:12:23 -0700

Windows 7 Party:

Sent from mobile phone

Lego Store: Sent from mobile phone

Mon, 06 Jul 2009 08:13:30 -0700

Lego Store:

Sent from mobile phone

Application Generation: Domain Specific Modeling: Choosing a Meta-metamodel

Thu, 02 Jul 2009 07:18:50 -0700

Application Generation: Domain Specific Modeling: Choosing a Meta-metamodel

Arda at the park with momy: Sent from mobile phone

Thu, 02 Jul 2009 07:04:36 -0700

Arda at the park with momy:

Sent from mobile phone

Arda at the park with dady: Sent from mobile phone

Thu, 02 Jul 2009 07:04:34 -0700

Arda at the park with dady:

Sent from mobile phone

Michael Nielsen » Is scientific publishing about to be disrupted?

Wed, 01 Jul 2009 07:03:36 -0700

Michael Nielsen » Is scientific publishing about to be disrupted?

The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines

Mon, 29 Jun 2009 05:08:06 -0700

The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines

stuart kent's blog : So what is a DSL anyway?

Mon, 29 Jun 2009 05:08:06 -0700

stuart kent's blog : So what is a DSL anyway?:

“I prefer to think of a language having different dimensions, and to categorize a language we need to place it on each of the dimensions relative to other languages. This leads to a much more fluid…

IUpdateable from Eric Nelson : Three Men and a Whiteboard: Windows Azure

Wed, 24 Jun 2009 03:05:06 -0700

IUpdateable from Eric Nelson : Three Men and a Whiteboard: Windows Azure

Welcome to IEEE Xplore 2.0: What Types of Defects Are Really Discovered in Code Reviews?

Tue, 23 Jun 2009 02:48:47 -0700

Welcome to IEEE Xplore 2.0: What Types of Defects Are Really Discovered in Code Reviews?

ProjectPlan - unladen-swallow - Plans for optimizing Python - Google Code

Tue, 16 Jun 2009 02:25:47 -0700

ProjectPlan - unladen-swallow - Plans for optimizing Python - Google Code

Effective Windows PowerShell: The Free eBook - Windows Live

Sun, 14 Jun 2009 02:25:29 -0700

Effective Windows PowerShell: The Free eBook - Windows Live

Moserware: The First Few Milliseconds of an HTTPS Connection

Sun, 14 Jun 2009 02:25:29 -0700

Moserware: The First Few Milliseconds of an HTTPS Connection

Memory Usage Auditing for .NET Applications

Mon, 08 Jun 2009 01:56:53 -0700

Memory Usage Auditing for .NET Applications

InfoQ: Metamodel Oriented Programming

Fri, 05 Jun 2009 01:24:17 -0700

InfoQ: Metamodel Oriented Programming

YouTube - homeproject's Channel

Sat, 30 May 2009 15:47:31 -0700

YouTube - homeproject's Channel:

We are living in exceptional times. Scientists tell us that we have 10 years to change the way we live, avert the depletion of natural resources and the catastrophic evolution of the Earth’s climate.

Rebecca Norlander - Challenge and Success | Behind The Code | Channel 9

Mon, 25 May 2009 02:56:34 -0700

Rebecca Norlander - Challenge and Success | Behind The Code | Channel 9

tortoisegit - Google Code

Mon, 25 May 2009 00:56:26 -0700

tortoisegit - Google Code

Stevey's Blog Rants: Dynamic Languages Strike Back

Sun, 24 May 2009 22:56:21 -0700

Stevey's Blog Rants: Dynamic Languages Strike Back

InfoQ: Developing Expertise: Herding Racehorses, Racing Sheep

Sat, 23 May 2009 19:55:33 -0700

InfoQ: Developing Expertise: Herding Racehorses, Racing Sheep:

In this presentation made during QCon 2007, Dave Thomas talks about expanding people’s expertise in their domains of interest by not treating them uniformly as they had the same amount of knowledge…