redirect 8th Light blogs

unclebob · Jun 20, 2014 · 45bed34 · 45bed34
1 parent 8f7469c
commit 45bed34
Show file tree

Hide file tree

Showing 56 changed files with 58 additions and 11 deletions.
diff --git a/uncle-bob/_posts/2011-11-22-Clean-Architecture.textile b/uncle-bob/_posts/2011-11-22-Clean-Architecture.textile
@@ -3,6 +3,8 @@ layout: post
 title: Clean Architecture
 tags: ["Architecture"]
 ---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2011/11/22/Clean-Architecture.html" />
+
 In the weeks since I started talking about the need to clean up our architecture, I've noticed a surprising resistance to the idea.  Apparently the notion that it's a good idea to hide the framework, UI, or database from the application code is not universally accepted.
 
 I first blogged about this topic "here":{% post_url 2011-09-30-Screaming-Architecture %}, I did a whole cleancoders.com "episode":http://www.cleancoders.com/codecast/clean-code-episode-7/show on the topic. I've also done several keynotes on the topic, the slides for which are "here":http://dl.dropbox.com/u/4730299/Architecture%20the%20lost%20years.key, and a video recording of which is "here":http://mchenry.softwarecraftsmanship.org/the-a-word-a-discussion-about-architecture.

diff --git a/uncle-bob/_posts/2011-12-11-The-Barbarians-are-at-the-Gates.textile b/uncle-bob/_posts/2011-12-11-The-Barbarians-are-at-the-Gates.textile
@@ -3,6 +3,8 @@ layout: post
 title: The Barbarians are at the Gates
 tags: ["Coding"]
 ---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2011/12/11/The-Barbarians-are-at-the-Gates.html" />
+
 There's a revolution coming.  I wonder if anyone has noticed.  It's not subtle.  It won't be sublime, or easy to integrate.  Indeed, it'll probably muck up everything for a long long time.  But it's coming nonetheless, and you'd better be strapped in and ready for the impact.
 
 The challenge for computing is _power_.  How much processing can you get done per unit of time.  Over the last fifty years we've seen this power increase by a scale that we usually reserve for thermonuclear weapons, supermassive black holes, or core-collapse supernovae.  We might characterize that power increase with the following formula:

diff --git a/uncle-bob/_posts/2012-01-11-Flipping-the-Bit.textile b/uncle-bob/_posts/2012-01-11-Flipping-the-Bit.textile
@@ -4,6 +4,7 @@ title: Flipping the Bit
 tags: ["Testing", "Craftsmanship"]
 old_tags: ["TDD", "Professionalism", "Craftsmanship"]
 ---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/01/11/Flipping-the-Bit.html" />
 
 There's a bit you need to flip in your head.  It's just one bit.  In this blog we'll call it "THE BIT".  Some of you have already flipped THE BIT.  The rest of you need to flip THE BIT as soon as possible.
 

diff --git a/uncle-bob/_posts/2012-01-12-The-Letter.textile b/uncle-bob/_posts/2012-01-12-The-Letter.textile
@@ -4,6 +4,7 @@ title: The Letter
 tags: ["Testing", "Craftsmanship"]
 old_tags: ["TDD", "Professionalism", "Craftsmanship"]
 ---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/01/12/The-Letter.html" />
 We need to become a self-regulating and self-policing profession.  The stakes are simply too high to allow software to remain in the current ad-hoc limbo of hackers, heroics, and hermits.  
 
 Consider how much software you interact with every day.  Your alarm clock, your cell phone, the television and cable box, the remote control, your toaster oven, your watch, your car, the train to work, the cash register at Starbucks, the coffee maker at Starbucks, the elevator you ride,  etc. etc.  The list is virtually endless.  Nearly every aspect of our daily lives, nearly ever corner of our civilization is somehow touched, controlled, managed, or influenced by software.  

diff --git a/uncle-bob/_posts/2012-01-20-Fecophiles.textile b/uncle-bob/_posts/2012-01-20-Fecophiles.textile
@@ -4,6 +4,7 @@ title: Fecophiles
 tags: ["Craftsmanship"]
 old_tags: ["Professionalism", "Craftsmanship", "Clean Code"]
 ---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/01/20/Fecophiles.html" />
 I got an interesting email yesterday.   It contained the following paragraph describing an email he had sent to his co-workers about a refactoring he had done:
 
 bq. When I originally sent this email to my co-workers, I got the following reaction; 1 team member thought it was better & 2 team members thought it was harder to understand.  Of the 2 who thought it was worse; 1 thinks I should change it back, and the other is willing to put up with my change to shut me up :-)

diff --git a/uncle-bob/_posts/2012-01-31-The-Ruby-Colored-Box.textile b/uncle-bob/_posts/2012-01-31-The-Ruby-Colored-Box.textile
@@ -4,7 +4,7 @@ title: The Ruby Colored Box
 tags: ["Craftsmanship", "Tools"]
 old_tags: ["Professionalism", "Craftsmanship",  "Ruby"]
 ---
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/01/31/The-Ruby-Colored-Box.html" />
 I recently read a "blog":http://www.unlimitednovelty.com/2011/12/can-you-solve-this-problem-for-me-on.html about a guy who had a bad interview.  The blog was well written and pretty funny.  He metaphorically described the interview in terms of a mexican chef being grilled about how to make crème brûlée.  He made a bunch of interesting points about how unfair the interview was, and how you shouldn't ask a mexican chef how to cook pastry.  
 
 The blog was in two parts, the mexican chef metaphor, and then a rant.  By the time I got to the end of the metaphor I was pretty much thinking that the author was a bit of a whiner.  OK, so the interview was unfair.  What interview isn't?  Why would any employer want to conduct a "fair" interview.  I'm certainly not fair when I interview people.  I put them under all kinds of stresses, and throw lots of strange issues at them.  I want to see how they behave when confronted with unfamiliar problems.  I want to know if they can extrapolate their experience into a new domain.

diff --git a/uncle-bob/_posts/2012-02-01-Service-Oriented-Agony.textile b/uncle-bob/_posts/2012-02-01-Service-Oriented-Agony.textile
@@ -4,7 +4,7 @@ title: Service Oriented Agony
 tags: ["Architecture", "Craftsmanship"]
 old_tags: ["Architecture", "Craftsmanship",  "SOA"]
 ---
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/02/01/Service-Oriented-Agony.html" />
 I sat down with a group of developers today to do a retrospective on a project.  They told me that project management has been complaining about their velocity.  It wasn't serious, but the developers felt bad because things _do_ seem to take longer than they should.  When I asked them why, they said that the system was very complex, and making changes to it was time consuming. 
 
 I asked them to draw the system on the whiteboard.  Here's what they drew.

diff --git a/uncle-bob/_posts/2012-04-18-After-The-Disaster.textile b/uncle-bob/_posts/2012-04-18-After-The-Disaster.textile
@@ -4,7 +4,7 @@ title: After the Disaster
 tags: ["Craftsmanship"]
 old_tags: ["Professionalism", "Craftsmanship"]
 ---
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/04/18/After-The-Disaster.html" />
 There's a disaster coming.  I don't know when.  I don't know what.  But it's coming, and there's nothing we can do to stop it; but there _is_ something we can do to mitigate it.
 
 How much software is running near you at the moment?  Of course you are reading this on a web browser, and that computer you are sitting next to has lots of software running in it. And there are probably many other computers near you with software running on them.  Is there software in your cell phone?  Of course.  How about in your watch?  Likely.  In the light switch on the wall?  How about in the light bulbs?  The intercom?  The doorbell?  The thermostat?  Your furnace?  Your air conditioner?  Your refrigerator, dishwasher, washing-machine, drier?  How about your car; and all the other cars on the road?  How about the traffic signals?  Did you ride an elevator today?  Get in a plane or a train?  How about an escalator?  Do you have a pacemaker?  An insulin pump?

diff --git a/uncle-bob/_posts/2012-04-20-Why-Is-Estimating-So-Hard.textile b/uncle-bob/_posts/2012-04-20-Why-Is-Estimating-So-Hard.textile
@@ -4,6 +4,7 @@ title: Why is Estimating so Hard?
 tags: ["Craftsmanship"]
 old_tags: ["Professionalism", "Craftsmanship"]
 ---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/04/20/Why-Is-Estimating-So-Hard.html" />
 Consider the Gettysburg Address: 
 
 "Four score and seven years ago our fathers brought forth upon this continent a new nation, conceived in liberty and dedicated to the proposition that all men are created equal..."  

diff --git a/uncle-bob/_posts/2012-05-15-NODB.textile b/uncle-bob/_posts/2012-05-15-NODB.textile
@@ -4,6 +4,7 @@ title: NO DB
 tags: ["Architecture", "Tools", "Craftsmanship"]
 old_tags: ["Professionalism", "Architecture", "Database", "Rant"]
 ---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/05/15/NODB.html" />
 In the United States, in 1920, the manufacture, sale, and importation of alcoholic beverages was prohibited by a constitutional amendment.  That amendment was repealed thirteen years later.  During that period of prohibition, the beer industry died.  
 
 In 1933, when prohibition was lifted, a few giant grain companies started brewing beer.  They completely cornered the market.  And for nearly 50 years, we in the United State drank this fizzy bodily effluent and called it “beer”.  The only way to tolerate the flavor was to drink it very cold. 

diff --git a/uncle-bob/_posts/2012-08-13-the-clean-architecture.textile b/uncle-bob/_posts/2012-08-13-the-clean-architecture.textile
@@ -3,6 +3,7 @@ layout: post
 title: The Clean Architecture
 tags: ["Architecture", "Craftsmanship"]
 ---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html" />
 <img width="100%" src="/uncle-bob/images/2012-08-13-the-clean-architecture/CleanArchitecture.jpg"/>
 
 Over the last several years we've seen a whole range of ideas regarding the architecture of systems.  These include:

diff --git a/...ts/2012-08-24-functional-programming-for-the-object-oriented-programmer.textile b/...ts/2012-08-24-functional-programming-for-the-object-oriented-programmer.textile
@@ -4,6 +4,7 @@ title: Functional Programming for the Object Oriented Programmer
 tags: ["Tools"]
 old_tags: ["Clojure", "Functional Programming"]
 ---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/08/24/functional-programming-for-the-object-oriented-programmer.html" />
 This book, written by Brian Marick, is important.  Indeed, it may be _necessary_.  We need something to bridge the gap between the huge population of OO programmers, and the growing need for functional programmers.  I've seen nothing else that fills this need so well.  
 
 I read a lot of books, but few are so competently written.  I'm a hundred pages in and I'm loving it.  If you are a Java, C#, C++, Ruby, or Python programmer, and you are wondering what all this _functional programming_ noise is about, this is the book for you.  

diff --git a/uncle-bob/_posts/2012-09-06-I-am-Your-New-CTO.textile b/uncle-bob/_posts/2012-09-06-I-am-Your-New-CTO.textile
@@ -4,6 +4,7 @@ title: The New CTO
 tags: ["Craftsmanship"]
 old_tags: ["Craftsmanship", "Professionalism"]
 ---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/09/06/I-am-Your-New-CTO.html" />
 "So, what did you think of _that_?" I asked as we sat down at our regular table in the cafeteria.  As I scanned the other tables in the lunchroom I could see that many other teams were leaning in to their conversation and speaking in semi-hushed tones.  The normally light-hearted lunchtime banter had been replaced with a new intensity.
 
 "It started pretty well." said Jasper.  "I mean he was nice enough at first, introducing himself as the new CTO and all."

diff --git a/uncle-bob/_posts/2012-12-19-Three-Paradigms.textile b/uncle-bob/_posts/2012-12-19-Three-Paradigms.textile
@@ -4,7 +4,7 @@ title: Three Paradigms
 tags: ["Tools"]
 old_tags: ["Functional Programming"]
 ---
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/12/19/Three-Paradigms.html" />
 In the last 40 years computer hardware technology has increased the computing power of our machines by well over twenty orders of magnitude.  We now play Angry Birds on our phones, which have the computing power of the freon cooled supercomputer monsters of the 70s.  
 
 But in that same 40 years software technology has barely changed at all.  After all, we still write the same if statements, while loops, and assignment statements we did back in the '60s.  If I took a programmer from 1960 and brought him forward through time to sit at my laptop and write code; he'd need 24 hours to recover from the shock; but then he'll be able to write the code.  The concepts haven't changed that much.  

diff --git a/uncle-bob/_posts/2012-12-22-FPBE1-Whats-it-all-about.textile b/uncle-bob/_posts/2012-12-22-FPBE1-Whats-it-all-about.textile
@@ -4,7 +4,7 @@ title: FP Basics E1
 tags: ["Tools"]
 old_tags: ["Functional Programming"]
 ---
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/12/22/FPBE1-Whats-it-all-about.html" />
 h4. What's Functional Programming all about?
 
 By now you've almost certainly heard of functional programming.  I mean, how could you miss it?  Everybody's talking about it.  There are all these new functional languages coming out like Scala, F# and Clojure.  People are talking about older languages too, like Erlang, Haskell, ML, and others.

diff --git a/uncle-bob/_posts/2012-12-29-Brave-New-Year.textile b/uncle-bob/_posts/2012-12-29-Brave-New-Year.textile
@@ -4,6 +4,7 @@ title: Brave New Year
 tags: ["Community"]
 old_tags: ["Prognostication"]
 ---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/12/29/Brave-New-Year.html" />
 This is going to be one of those annoying, rambling, touchy-feely, new-years blogs.  You know the kind.  One that tries to make you think about what's passed, and what's coming.  One that tries to impress you with foresight and erudition.  One that claims profundity and depth.  You know the kind.
 
 Still, that's the mood I'm in.  So here goes.

diff --git a/uncle-bob/_posts/2013-01-02-FPBE2-Whys-it-called-functional.textile b/uncle-bob/_posts/2013-01-02-FPBE2-Whys-it-called-functional.textile
@@ -4,7 +4,7 @@ title: FP Basics E2
 tags: ["Tools"]
 old_tags: ["Functional Programming"]
 ---
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/01/02/FPBE2-Whys-it-called-functional.html" />
 h4. Why's it called Functional?
 
 In the previous episode I told you what all the functional programming hubbub is all about.  Remember: Referential Transparency and the multi-core freight train?   Since you are here, reading episode 2, I presume you were convinced by my arguments and want to know more.

diff --git a/uncle-bob/_posts/2013-01-07-FPBE3-Do-the-rules-change.textile b/uncle-bob/_posts/2013-01-07-FPBE3-Do-the-rules-change.textile
@@ -4,7 +4,7 @@ title: FP Basics E3
 tags: ["Tools"]
 old_tags: ["Functional Programming"]
 ---
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/01/07/FPBE3-Do-the-rules-change.html" />
 h4. Do all the Rules Change?
 
 Whenever we start to use a new paradigm, we confront the problem of our old rules and our old habits.  We ask ourselves whether all those rules and habits are valid in the new paradigm.  Consider, for example Test Driven Development.  Is it valid in Functional Programming?  If so, how do you do it?

diff --git a/uncle-bob/_posts/2013-01-29-FPBE4-Lazy-Evaluation.markdown b/uncle-bob/_posts/2013-01-29-FPBE4-Lazy-Evaluation.markdown
@@ -4,7 +4,7 @@ title: FP Basics E4
 tags: ["Tools"]
 old_tags: ["Functional Programming"]
 ---
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/01/29/FPBE4-Lazy-Evaluation.html" />
 #### Lazy Evaluation
 
 Remember my squares of integers program in clojure?

diff --git a/uncle-bob/_posts/2013-01-30-The-Craftsman-And-The-Laborer.markdown b/uncle-bob/_posts/2013-01-30-The-Craftsman-And-The-Laborer.markdown
@@ -3,6 +3,7 @@ layout: post
 title: The Laborer and the Craftsman
 tags: ["Craftsmanship"]
 ---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/01/30/The-Craftsman-And-The-Laborer.html" />
 In a recent [blog](http://blogs.tedneward.com/2013/01/24/On+The+Dark+Side+Of+Craftsmanship.aspx) Ted Neward made this remarkable statement:
 
 >I'm criticizing because this is what "software craftsmanship" gets us: an imposed segregation of those who "get it" from those who "don't" based on somebody's arbitrary criteria of what we should or shouldn't be doing. And if somebody doesn't use the "right" tools or code it in the "right" way, then bam! You clearly aren't a "craftsman" (or "craftswoman"?) and you clearly don't care about your craft and you clearly aren't worth the time or energy necessary to support and nourish and grow and....

diff --git a/uncle-bob/_posts/2013-02-01-The-Humble-Craftsman.markdown b/uncle-bob/_posts/2013-02-01-The-Humble-Craftsman.markdown
@@ -3,6 +3,7 @@ layout: post
 title: The Humble Craftsman
 tags: ["Craftsmanship"]
 ---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/02/01/The-Humble-Craftsman.html" />
 There is another side to Ted Neward's [blog](http://blogs.tedneward.com/2013/01/24/On+The+Dark+Side+Of+Craftsmanship.aspx); and it's a side that I agree with.  I believe Ted's overall thesis and analysis was wrong.  Software Craftsmanship does not automatically give us a blue-collar/white-collar dichotomy; it does not automatically separate those who "get it" from those who don't.  It does not automatically create a condescending elite who lord their self-perceived superiority over the unwashed masses.  And, in case you hadn't noticed, I _really_ disliked Ted's manipulative appeal to populism.
 
 However, Ted was not entirely wrong either.  Because there are folks (and, to my shame, I've sometimes numbered among them) who have behaved badly when pointing out problems or deficiencies in other peoples' code.  To those people (and to myself) I'd like to make the following points.

diff --git a/uncle-bob/_posts/2013-02-10-ThePrinciplesOfCraftsmanship.markdown b/uncle-bob/_posts/2013-02-10-ThePrinciplesOfCraftsmanship.markdown
@@ -3,6 +3,7 @@ layout: post
 title: The Principles of Craftsmanship
 tags: ["Craftsmanship"]
 ---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/02/10/ThePrinciplesOfCraftsmanship.html" />
 It should come as no surprise to anyone that I think 8th Light Inc. is a remarkable company.   The company was founded, and is run, by two of my previous apprentices; one of whom is my son Micah, and the other is Paul Pagel.   From the start they based their ideals on those of software craftsmanship.  They wanted to build a community of professionals who _believed in their core_ that the best way to build software was to build it well.  Now, with the better part of a decade behind them, they are one of the most successful software consulting businesses in Chicago; and will soon be able to make that claim about Tampa, Florida.
 
 The company is unique in many ways.  For example: Their employees are called craftsmen, and the recruiting model is based upon apprenticeship.  Craftsmen are not hired in the usual sense that an employee is hired.  Rather, they are brought on as apprentices and gradually inducted into the company through a months long intricate ritual of training, mentoring, challenge, and accomplishment.  It's a tough gauntlet to walk; and those few who make it through know they have achieved something difficult and important.

diff --git a/uncle-bob/_posts/2013-03-05-TheStartUpTrap.markdown b/uncle-bob/_posts/2013-03-05-TheStartUpTrap.markdown
@@ -3,6 +3,7 @@ layout: post
 title: The Start-Up Trap
 tags: ["Craftsmanship", "Testing"]
 ---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/03/05/TheStartUpTrap.html" />
 * **You** have joined a new startup.
 * **You** are a multi-talented mega-being.
 * **You** can work 60, 70, 80 hours per week to get the job done.

diff --git a/uncle-bob/_posts/2013-03-06-ThePragmaticsOfTDD.markdown b/uncle-bob/_posts/2013-03-06-ThePragmaticsOfTDD.markdown
@@ -3,6 +3,7 @@ layout: post
 title: The Pragmatics of TDD
 tags: ["Craftsmanship", "Testing"]
 ---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/03/06/ThePragmaticsOfTDD.html" />
 So my last blog: [The Startup Trap]({% post_url 2013-03-05-TheStartUpTrap %}) raised quite a ruckus.  Amidst the various shouts of agreement and support, there was also a group who vehemently disagreed.  I'm not going to summarize all their disagreements here, since I've already used up my quota of curse words for the month.  But one of those disagreements struck me as something I should address.  
 
 It's the old argument of pragmatism vs. dogmatism.  In essence, the complaint was that I was being too dogmatic.  That TDD might be great in some cases, but in others it might have too high a cost.  So you have to be pragmatic and choose wisely.

diff --git a/uncle-bob/_posts/2013-03-08-AnOpenAndClosedCase.markdown b/uncle-bob/_posts/2013-03-08-AnOpenAndClosedCase.markdown
@@ -3,6 +3,7 @@ layout: post
 title: An Open and Closed Case
 tags: ["Craftsmanship", "Coding"]
 ---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/03/08/AnOpenAndClosedCase.html" />
 I awoke this morning to see a twitter conversation about the Open-Closed Principle.  The tweeter was complaining that it didn't make a lot of sense.  He said things like: 
 
 >"Presumably true OCP fans barely use version control, btw. Only reason to change a source file is for bug fixes, right?"

diff --git a/uncle-bob/_posts/2013-03-11-TheFrenziedPanicOfRushing.markdown b/uncle-bob/_posts/2013-03-11-TheFrenziedPanicOfRushing.markdown
@@ -3,6 +3,7 @@ layout: post
 title: The Frenzied Panic of Rushing
 tags: ["Craftsmanship", "Testing"]
 ---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/03/11/TheFrenziedPanicOfRushing.html" />
 Last week I wrote a blog entitled [The Startup Trap]({% post_url 2013-03-05-TheStartUpTrap %}) in which I lamented the unfortunate tendency of developers in a startup to cast their disciplines aside in order to maintain the "high" generated by the illusion that effort is speed.  I specifically mentioned TDD as one of those disciplines that startup developers sometimes eschew.
 
 The response in support of the blog was gratifying.  The response in denial (Yes, that's the right word) of the blog was expected; though I was somewhat surprised by the vehemence and amplitude of the various pejoratives, barbs, insults, and other ad hominem statements.  I suppose that people who are addicted to a "high" do not take kindly to those who challenge their ability to justify and maintain that "high". 

diff --git a/uncle-bob/_posts/2013-05-27-FibTPP.html b/uncle-bob/_posts/2013-05-27-FibTPP.html
@@ -3,7 +3,7 @@
 title: Fib. The T-P Premise.
 tags: ["Coding"]
 ---
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/05/27/FibTPP.html" />
 <div id='wrap'>
 	<div class='post'>
 		<div class='post_header'>

diff --git a/uncle-bob/_posts/2013-05-27-FlashTpp.html b/uncle-bob/_posts/2013-05-27-FlashTpp.html
@@ -4,7 +4,7 @@
 tags: ["Coding"]
 ---
 
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/05/27/FlashTpp.html" />
 
 		<div class='post'>
 			<div class='post_header'>