sshrkv is awsm

Annoying problems get annoying solutions.

Sun, 24 Feb 2013 16:41:04 -0500

Annoying problems get annoying solutions.:

The latest build of emacs came with a flakey erc timer that ZNC.el didn’t agree with during reconnects.

This is my highly engineered solution to the problem.

"The authors then did a separate experiment where instead of using ‘sexually naive’ rats as the..."

Tue, 06 Nov 2012 20:58:35 -0500

“The authors then did a separate experiment where instead of using ‘sexually naive’ rats as the stimulus rats, they used ‘sexually expert’ rats.”

- Can you turn a rat gay? (via outofcontextscience)

"On its third firing the chain snapped immediately and one ball tore into a nearby cabin, knocking..."

Sat, 20 Oct 2012 16:35:14 -0400

“On its third firing the chain snapped immediately and one ball tore into a nearby cabin, knocking down its chimney, the other spun off erratically and struck a nearby cow, killing it instantly. Gilleland considered the test-firings a success.”

- Double-barreled cannon

I am having trouble determining if this article is real or not

Sat, 07 Jul 2012 14:26:36 -0400

I am having trouble determining if this article is real or not

Photo

Wed, 06 Jun 2012 14:41:41 -0400

wilwheaton: I was playing Civilization: Revolution on my iPad...

Mon, 04 Jun 2012 19:58:18 -0400

wilwheaton:

I was playing Civilization: Revolution on my iPad today. When I got access to the “Fundamentalism” government, this is the warning the game gave me.

I stuck with Monarchy, and eventually won a cultural victory.

mcgoats: oh my god You have been warned.

Tue, 29 May 2012 17:54:27 -0400

mcgoats:

oh my god

You have been warned.

I don’t understand what’s going on, and I think...

Fri, 18 May 2012 00:28:00 -0400

I don’t understand what’s going on, and I think understanding would ruin the magic.

CLOS FSM with MOP Sauce

Tue, 15 May 2012 01:33:00 -0400

Common Lisp in the desire to be as cool as possible includes in its specification the Common Lisp Object System, or CLOS, which itself can be introspected and altered in great detail using the MetaObject Protocol, or MOP, as described in The Art of the Metaobject Protocol. Unfortunately, MOP didn’t make it into the ANSI standard, but most implementations include MOP as it is described in the book, and a compatibility package :closer-mop (available in Quicklisp) makes using the symbols described seamless between implementations.

One of the features of MOP is the ability to make an instance of a CLOS class funcallable, that is allow a class instance to be a valid first argument to funcall. This behavior in a lot of ways can resemble the traditional method model from other languages, but that’s not how I intend use it here.

The Idea

I’m going to show and tell an implementation of a generic finite state machine that uses the MOP concepts of funcallable-standard-object and funcallable-standard-class to marshal the flow of incoming events to the machine and the concept of CLOS generic method dispatch to handle the execution of transition handlers for any given state of the machine.

These features will allow us to build a structure that lets us focus solely on the problem at hand and defer features like event data binding, state-dependent method selection and unexpected state handling entirely to the language without pushing the boundaries of any specific feature.

The Design

The design we’re going for is such that we can define a class with a state slot that will hold :keyword name of a state. We’ll make instances of this class funcallable so that when we make an instance we will be able to simply (funcall fsm-instance fsm-evemt) repeatedly and have the machine dispatch to the correct event, perform any logic, and transition to the next state based on the input.

We would be able to query the state of the machine with (state fsm-instance) and receive a keyword, and we should be able to drive events into the machine until we’re in a desired or unexpected state. Any attempt to feed the machine an event while the machine is in an invalid state should result in an error.

Setup

Dependencies in Common Lisp these days should come from Quicklisp. Install it now before even reading the next paragraph, and during the installation phase ask it to write itself to your lisp configuration’s init file.

The code samples below, as should any code using MOP intending to run more than once, uses the :closer-mop package. Fetch it from Quicklisp before attempting these examples by evaluating:

(ql:quickload :closer-mop)

At the REPL before attempting to evaluate any example code.

Implementation

We’ll first declare the base of our state machine. We’ll call the base standard-state-machine to follow the convention CL seems to have of sticking the standard- prefix to base classes.

(defclass standard-state-machine (c2mop:funcallable-standard-object)
  ((state :initform :initial :initarg :state
          :accessor state)
   (last-event :initform (get-internal-real-time)
               :accessor last-event))

  (:metaclass c2mop:funcallable-standard-class))

This grants us the majority of our desired features from the design. The resulting class holds a :keyword state name in a state slot, and is declared to be funcallable by the inclusion of the funcallable-standard-object base and the funcallable-standard-class metaclass for the class itself.

When events fire through this state machine we will need to invoke a method that we can use to dispatch to various handlers in the machine depending on the state we happen to be in. We can use the CLOS generic method feature called eql specializers to distinguish which method should be invoked based on the name of the state a machine happens to be in. EQL specializers are just like type specializers for method parameters, but instead of the comparison of the parameter to the specialization happening based on the type of the parameter, it happens as if an (eql parameter-value parameter-specialization) test is performed to determine if a given method is applicable to an invocation.

With this in mind we can design a generic method that is aware of three things as parameters that we can choose to specialize: The current state machine, the state of the current state machine, and the event that was received by the machine.

(defgeneric standard-state-machine-event (machine state event))

We won’t define any such methods now, because right now we have no state machine to model, and as such have no state handing methods to define.

To actually invoke a function when the funcallable instance is called as a function a lambda must be bound to be the funcallable instance function of a given instance of a class. Since there is no mandate for an inherent this pointer in CL, the best place to bind this function is often in one of the specializations of initialize-instance and close over the current instance in the process. The attachment of a function to an instance is done with the MOP function set-funcallable-instance-function, which places no special requirements on the args list of the attached function.

We’ll bind our driver to the state machine instance in the :before specializer of its initialize-instance method, and use an args list that expects only the event that is being delivered to the state machine:

(defmethod initialize-instance :before ((machine standard-state-machine) &key)
  (c2mop:set-funcallable-instance-function
   machine
   #'(lambda (event)
       (multiple-value-bind (next-state recur-p)
           (standard-state-machine-event machine (state machine) event)

         (setf (last-event machine) (get-internal-real-time)
               (state machine) (or next-state (state machine)))

         (if recur-p
             (funcall machine event)
             (values machine (state machine)))))))

Now when we have instance of the state machine invoked with (funcall fsm-instance event), the inner lambda expression will get passed the event and compute a return. This function despite having some length does very little.

First, it dispatches the event to our previous standard-state-machine-event method using the instance of the state machine we closed over as the first parameter, the state of the state machine as the second parameter and the event that the machine was called with.

It expects a multi-value return, but if the method only returns one value, no error is raised and the second value, recur-p is left bound to nil. Its meaning will become abundant in a moment.

Once the state handler is called the new state returned by the handler is stored as the current state of the state machine, and if a second value was returned, the machine is invoked again with the same event it had just received before returning from the handler the value of the current machine instance for chaining and the value of the current state.

The second, recur-p value is a hook that can be used from a state handler to force the machine to retry handling the event in a new state. This is useful when the same event should loop through the machine a second time before the transition is complete, and the optional second value return from a state handler allows that without additional external plumbing.

Functionally, the implementation of the state machine is complete. It can now cycle through a graph of events, provided that those events are defined as specialized methods. But, in its current state, the API leaves very much to be desired.

The Polish

As the state machine stands now, to implement one that for all inputs remains in the default :initial state, one would have to be defined explicitly by specializing the standard-state-machine event.

(defmethod standard-state-machine-event
            ((fsm standard-state-machine)
             (state (eql :initial))
             event)
  nil)

The trailing nil makes the return value explicit, due to the length of the specializations. This makes the structure of the dispatch clear, and the nil return value could be traced through the driver above to determine that this machine would do absolutely nothing given any kind of input. Remaining eternally in the :initial state.

To make the task of defining states for a given type of state machine we can write a simple macro to write the above form for us. After all, the majority of it is filler.

(defmacro defstate (machine-type state-name (machine-sym event-sym) &body body)
  `(defmethod standard-state-machine-event
       ((,machine-sym ,machine-type) (state (eql ,state-name)) ,event-sym)
     ,@body))

Using the macro above we can now declare an identical looping :initial state for the standard-state-machine as follows:

(defstate standard-state-machine :initial (fsm event)
  nil)

Which results in identical code to the one we wrote previously. The symbols given in the argument list of the defstate forms are bound to the machine evaluating the event and the event that is being sent through the machine. The remaining forms will be evaluated just as in any other defun/defmethod with the return value treated as either next state for the machine to enter, nil to stay in the same state, or a multivalue return with one of the previous and a non-nil second value to indicate the event should be fired through the machine a second time before the final state is stored.

To create subclasses of the standard state machine, we again run into a similar situation as before with boilerplate requirements. Each subclass of standard-state-machine must not only include the standard-state-machine class in the list of parents, it must also include funcallable-standard-class as its metaclass, as in:

(defclass my-fsm (standard-state-machine)
  ()
  (:metaclass c2mop:standard-funcallable-class))

This peculiarity could be documented a thousand times in a thousand places, but that will make it no less ugly or difficult to remember. It would be much easier to provide a familiar tasting API to consumers that results in the same code. For example, using a structure like this to generate code equivalent to the above

(deffsm my-fsm ()
  ())

This leaves the consumer free to do whatever their heart desires with CLOS without disturbing the requirements of our function. Such a construct can be stated simply as another tiny macro.

(defmacro deffsm (name parents slots &rest options)
  `(defclass ,name ,(append (list 'standard-state-machine) parents)
     ,slots
     (:metaclass c2mop:funcallable-standard-class)
     ,@options))

The Result

If we were to put all of that code together in one place with a bunch of documentation strings for the methods, classes and slots in a slightly more condensed form than this article, it might look something like this. Which is actually a minimal extraction of the state machine that drives the HTTP parser in Hinge. If this article gets enough interest, I will extract standard-state-machine into a QuickLisp compatible package for even easier reuse.

The Demo

Let’s construct an FSM for determining if a sequence of characters contains the string “Hi”, but before the character “!” appears. Once a string contains “Hi” it can contain “!” characters again.

We’ll model this as a machine of three states, with events being single characters of input. The states will be :initial, :want-i and :done.

In the :initial state, we’ll accept any input without transitioning except for “!” which will cause the machine to transition into an error state so that no more input can pass, and “H” will cause the machine to transition to the :want-i state.

Any event other than “i” in the :want-i state will transition back to :initial and the event “i” will cause the machine to enter the state :done, which will be a no-op looping state that allows input to pass through uninspected. The implementation for such a machine would look like this, assuming we have previously defined the :fsm package.

(fsm:deffsm hi-fsm ()
  ())

(fsm:defstate hi-fsm :initial (fsm c)
  (case c
    (#\! :error)
    (#\H :want-i)))

(fsm:defstate hi-fsm :want-i (fsm c)
  (if (char-equal c #\i)
      :done
      (values :initial t)))

(fsm:defstate hi-fsm :done (fsm c)

We can observe it in action by running it through a couple of strings and measuring the terminal state of the machine:

(let ((fsm (make-instance 'hi-fsm))
       (input "Oh? Hello there. Hi. How are you!?"))
  (map 'list 
       (lambda (c) 
         (if (eql :error (fsm:state fsm))
             (format t "Skipping: ~S~%" c)
             (funcall fsm c))) 
       input)
  (fsm:state fsm))

Resulting in :DONE as the final state of hi-fsm.

This will iterate the string character by character through the machine we just defined, and unless the machine is in an error state, it will submit each token, then return the state of the machine when it has completed its run.

If we change the string to one where neither “Hi” nor “!” appear at all, the machine will remain in :initial and if “!” appears before “Hi”, then the machine will leave the loop in an :error state, and any tokens after the “!” won’t even be sent into the machine. Changing the binding of input in the above to “Go away! Now.” results in the value of :ERROR and the printing of the lines

Skipping: #\ 
Skipping: #\N
Skipping: #\o
Skipping: #\w
Skipping: #\.

So there you have it. You now know how to leverage the powers of Common Lisp and MOP to build a pretty cool and useful abstraction for a pretty common algorithm.

wilwheaton: Holy Balls, this is hilarious. My friend Joel...

Mon, 14 May 2012 12:21:12 -0400

wilwheaton:

Holy Balls, this is hilarious. My friend Joel witnessed a disastrous first date, and twittered the whole thing.

(via HijiNKS ENSUE – A Geek Comic - Starbucks DateWreck Live Tweet)

suztacular: This is horrible and I shouldn’t laugh

Wed, 09 May 2012 12:19:19 -0400

suztacular:

This is horrible and I shouldn’t laugh

Hinge -- v0.0.1

Wed, 09 May 2012 02:10:16 -0400

Hinge -- v0.0.1:

Hinge, my Node.js inspired API for Common Lisp wrapping libev is finally to a state where I feel okay giving it a non-zero version.

I’ve decided now would be a good milestone because the HTTP server functions, and has a set of exported APIs that let you reply to the requests it generates.

The quick set of terrible benchmarks I performed on the “Hello World!” example show me a requests/second throughput of 1500-2500 depending on the mood of ab (and the state of the number of sockets available on localhost). I intend to run it through a more serious (and HTTP/1.1 supporting) tool in the future, but for now ab has convinced me that the decisions I’ve made so far have not been abysmal.

The examples directory contains a bunch of example programs, or in the earlier cases, code snippets demonstrating various levels of functionality.

In the near future, in addition to covering the issues in the README, adding additional polish, and any bugs or blatant performance issues that come up I would like at some point to add support for:

HTTP Clients
SSL Sockets and Servers
SSL HTTP Servers and Clients
Async wrappers around FS calls
Websockets (RFC6455) support
Mongrel2 ZeroMQ handler support (through m2cl)
Mongrel2 ZeroMQ protocol-compatible server
SPDY Support (Somewhere down the list, maybe)

Any feedback is welcome however way you want to deliver it to me. This initial version stands to serve as a basic starting point for the concepts I wanted to convey, the take on the core APIs I wanted to offer, and a proof of a series of related concepts and architectural decisions. It may (hopefully) be useful as a stable base for progress, rather than chasing an otherwise potentially unstable head.

ilovecharts: Jason also gave me the opportunity to stretch the...

Fri, 04 May 2012 13:50:24 -0400

ilovecharts:

Jason also gave me the opportunity to stretch the idea of the graph format. The first graph I ever did for him, I think, was a Venn diagram that said “Diagrams” on one side and “Things That Venn Thought Of” on the other. The middle was blank. About a year later, I went back to the Venn to try to make sense of the most world-changing of modern inventions.

The Definitive Guide, now on Amazon.com

Wed, 25 Apr 2012 17:25:05 -0400

The Definitive Guide, now on Amazon.com:

You’ve never had less excuses to not own this 21st century classic by this up-and-coming, though inexplicably universally respected author.

GitHub and CI Project Workflow Guide

Mon, 16 Apr 2012 21:06:06 -0400

This is an overview of how I believe a real software project lifecycle can and should be managed when the tools at your disposal include a GitHub repository and a CI server. The explanation favors Jenkins but shouldn’t be exclusive to it.

It was originally written for work to finally get down in writing my opinions on project code, build and release management for the project I’ve suddenly started leading. I’m sharing it here because I believe these guidelines to be more generally applicable to any project that actually makes releases and has more than a single team member.

In an effort to reduce the number of pain and contention points during development as well as being able to maintain a high velocity without reducing the ability to experiment the following process should be applied to development of a given project. This applies for any developer providing code to the project: internal, external, senior or junior.

The process is always up for discussion and is not a dictated commandment, but a description of what seems to be a good idea over time. If in the process of applying the process something becomes clearly a bad idea we should try to figure out why and how to prevent it rather than pushing harder on enforcing process. Don’t be that guy, or that other guy and we’ll be ok.

Overview

The following assumptions should hold true at all times for the state of the repository and supporting tools.

Production code is always a `git-tag`‘ed promoted Jenkins build

Any code running in the production environment must have arrived there from a successful build from Jenkins that has been promoted to production using the Promoted Builds Jenkins plugin. Evidence for exception to this principle should be of similar quality as that one would expect for a serial murder defense.

`origin/master` is always in good shape

The upstream master branch should reflect the latest, well-tested, peer-reviewed state of the repository. It doesn’t have to always reflect the tree in production, but anything in the master branch should certainly be destined there. The features should be well tested and serve as a reliable starting point for new work.

Any merge that causes master to fail the test suite should be reverted immediately to the last passing state and work to resolve the problem should happen elsewhere.

Every line of code is peer reviewed

Nothing should ever get merged into a mainline branch of the repo until at least two people have seen the code: The original author and a team member.

Any code that wants to be included in the mainline of the project should be introduced to the project by the author as a pull request. It doesn’t matter if the request comes from a branch within the repository or a fork of the same as long as the branch is rebased on the current branch the request targets. It should be the responsibility of the author of the branch to keep the branch rebased if its integration target moves during development. The final resulting merge should appear as forced merge commit on an otherwise fast-forward merge.

Pull requests should never be merged by the same person that authored them, and should always be done with the press of the green merge button on GitHub. If no one is available for review and :+1: please chase someone down rather than bending this rule. This one practice pays massive dividends.

Every pull request passes the test suite

Before any pull request to the project can be merged a comment should be added to the pull request with a link to the latest Jenkins build of the branch under review. Those merging the request should actively seek out such a link, even if one is known to exist and refuse to merge requests that omit it until one is available and present in the conversation thread.

This practice forces the author to assert through an unfeeling machine that the code presented for review and inclusion passes not only the full test suite of the application, but also the tests it included as part of development. The presence of this step also tends to eliminate seemingly simple changes with unforeseen consequences.

The convention the author wishes to introduce for including such comments in a pull request is:

:sparkles: http://jenkins.your.host.com/job/project/170/ :sparkles:

Which renders using Emoji as a link to the build between two shiny sparkling thingies, which pretty much makes everyone happy. This also allows the shorthand conversational notation of “Sparkles” or “Sparkles build” for builds that pass the test suite, making everyone feel silly about themselves.

Everything that was ever a conversation is documented

If for any reason you need to offer an explanation, a walk through or a conversation about a topic relating to the development, deployment, operation or maintenance of the project you should instead of offering it directly take the time to write it down as a wiki page and link that instead.

This not only makes sure that the things we explain get written down for later, they can also serve as roadmaps or design documents for things still in development or earlier.

Since the internet is big and space is largely free documentation should not be reserved for special occasions. It should be written for design discussions, external and internal APIs, proposals, suggestions or even tangentially related ramblings. If it seems relevant, it should be linked together into groups of pages for easier navigation, like some sort of manual.

No new features without tests

If you write something that wasn’t there before, no one will believe you until you have tests proving that it works. When used in concert with the other guidelines this should also make sure that your feature works and does so well by the time it’s integrated.

Failure to do this should be easy to notice in peer review. If the feature is not only new, but also interesting it should also come with documentation.

On pull requests

Pull requests are the starting point of conversations about a set of changes. They are not demands, edicts, sticky notes or contracts. As such they can and should be opened whenever a conversation about a set of changes needs to take place. That is to say, they should not be a tool reserved for finished code waiting integration, they serve as an excellent platform to get feedback on code in progress or in question and should be used liberally.

Given that definition, the opening of a pull request should be given the same attention as a potential conversation with an audience. Don’t just accept the default copy inserted into the request based on your HEAD. Give the pull request a title that describes the code it carries and use the description field to explain the intent and approach of the changeset as well as any tradeoffs that may not be evident. Try to make the reviewers job easier rather than expecting them to divine details and direction of the change from the diff. It’ll save everyone time and sanity.

On Hotfixes

By the nature of the event, a Hotfix is something that is both urgent and completely unplanned so suggestion of a concrete process for dealing with them is quite ambitious and one won’t be attempted. Instead, these are some suggestions for how to find some generally relevant information and a best-case path for making an urgent code change, deploying it, and still managing to review and safely integrate it back into the codebase without generating a great deal of extra state, disruption and contention.

Determine which build is running in the affected environment by seeking the last promoted build in the CI environment. This should be linked with a specific build and an associated git commit. This would be a good place to branch from in the repository to implement the change with minimal impact.

You can do this by executing the following in the repository root.

$ git branch hotfix-description $COMMIT_SHA_FROM_CI_BUILD

The changes can then be made on the branch hotfix-description and pushed upstream as usual, triggering a CI build that can then be promoted to the required environment and deployed. If favorable, the same build can endure multiple, sequential promotions to be deployed first for internal testing in lower-risk sandbox or staging environments.

When the build carrying the hotfix is promoted and deployed to the desired environment and is tested to be a satisfactory solution to the hotfix condition, reintegration work can take place at a more relaxed pace without any incurred interruption to any other ongoing development work.

The hotfix-description branch can either be directly rebased on an upstream branch such as origin/master and replaced, left as-is, or copied to another upstream head. The resulting branch can then be submitted as a pull request for inclusion in the main line of code and a proper release can be made in the future, replacing the promoted hotfix build from earlier, but including the changes with proper review.

At least, as they say, that’s what is supposed to happen. In these cases, more so than most, defer to common sense, good judgement and experience.

TL;DR Checklist

origin/master never gets direct commits. Ever. By anyone.
We are not using git-flow. We will not be using git-flow. No one should use git-flow.
New work branches (usually) start at origin/master
Your branch has a meaningful, descriptive name (As in update-redis-library or fix-zmq-deadlock, not x-work, not freaking ever develop, not yourname-somework)
Your work stays in your branch
Your branch stays rebased to the head you started from
Pull request when you’re ready for review
:sparkles: comment on your pull request when tests pass
Someone else will merge it when they’re happy with it, find that someone if you’re not popular enough or its urgent
You break it, you fix it (tests, rebase, etc) so try to keep sharp things away from people

Photo

Sat, 24 Mar 2012 11:36:43 -0400

Summary of Antiques Roadshow: UK

Tue, 20 Mar 2012 12:07:08 -0400

And so it spoken hereinwithsuchthat in which there was such that as well the process herein follows is described within which such as much with respect to the following as is described thereafter henceforth ignoring here forth the following colon and subsequent newline, in so much that one may or may not be plural and the other must remain singular:

First off, this appears to be some sort of retarded ass holiday special. Too many of those if you ask me. I’m watching the intro, which is pretty much a summary of an old car driving past people with other old crap with a painting stuck into the too-small-for-it back seat. It transitions to black and white footage of a child, or now, children unwrapping christmas presents with narration. This serves as a setup to the annoying narrator in a horrible sweater showing off one of her pointless bears of a useless childhood to try to convince you that other people’s garbage can, indeed, be somehow overpriced treasure.

They’re not even pausing on items, just wandering around and showing shiny things that people previously owned. If I may opine, the entire point of the show would appear the juxtaposition of old junk with sudden wealth, and this show so far leaves out the entire second part of this tried and true formula.

Oh, back to the wood paneled room with a tree and an annoying narrator. Clip shows mean you care, set up the footage!

Maybe, just maybe this time they will actually walk through an entire presentation for an item rather than panning around and cutting people off. Nope. They absolutely inject the narrator into every single discussion and splicing content together to create a narrative that can’t even be slightly cared about. Even as someone who would otherwise be attracted to the antiques presented, this show serves more to, if you forgive the language, jerk itself off for no reason other than the ability to do so.

Oh! Great scott! A few thousand pounds, the first price named for arbitrary jewelry. It’s some long-lost jewelry, apparently. This is important to the old dude they earlier presented as import. The first time they’ve actually stopped on an item, and declared it worth in the five digit range. Obviously something of that nature warrants an interview with anyone and everyone involved. You want to be on what the other side of the couch holds? That’s right, a freaking christmas tree opposite the interviewer in the annoying sweater.

Onwards to the auction of stupid jewelry. It’s Lot 150, if you’re ever curious. The auction is supposed to show that the money that was quoted by the professional was far too small. It will sell for thirty-one thousand British. Not bad for an old chunk of metal. The old lady that owned is pretty pleased, and they much comment on the fact. Though, the setting moved from the large wood-panneled room into something resembling more of a library setting. The number of trees that are scattered throughout that house must generate a mess.

So the expert, during the interview I’ve been complaining through, is explaining how terribly wrong he was. Apparently the ten grand he pulled out initially was the largest amount he was able to come up with at the time, but his explanation for the 31K figure was “well, duh, obviously, it’s rare, shut up.”

Oh my fucking god. They are now making terrible puns around things. I’m actually suffering as I watch this, but I must soldier on.

The clip takes to a silver bull. They’re some sort of silver cups in the shape of a bull’s head. I have to admit, I don’t hate it. And if I could use them rather than just have them sit around for no reason, I would own them. 1869 was the year on it. And there are 12 in a set. Bulls are the rarest, he claims. Interesting right?

Oh, burn. The lady with the cups doesn’t even own them. So when they become incredibly valuable, she’s screwed. Let’s wait for the price. 150K, british, for the lot. Stupid bitch gets nothing and now has to know that she has to drag that much value around town for no reason. Way to go, guys, hope you can buy insurance on the go.

Oh come the fuck on, this is dumber than hell. It’s a train set. I don’t want to hear old people complain about toys and how awesome it is that it’s still around. They made it out of Tin, brass, and a few wood accents. It’s a freaking toy and they’re going to be talking about how awesome it was that it was ever made.

Now it’s German. Good job guys, you found a German toy trains. Even their children are trained to run trains from birth. Apperantly no one even wants it, and the only reason it has value is because only stupid people want them and they are rich. 50K for insurance. Good one. It’s a fucking train.

And another jump! A field with a castle in the background, and they’re staring down a rolex watch. No one cares about it. I care so little, I’m going to take this time to just go ahead and pee for no freaking reason. And you get to know nothing about the rolex. Consider, though, that if you’ve even read this far down you have serious problems. This is pretty idle to produce, and I assure you that I’ve only read it with a buffer of around three words around the cursor. The mere act of consuming this content, in full or even in significant part can be very well considered indicative of some sort of mental failure.

I also took the time to eat pizza. There were some watches, then a 10K painting, and we’re back to fucking toys. This show is so utterly useless if their idea of a good antique time is showing off a bunch of useless fucking toys. This is is an ugly ass wooden train and it looks like a fucking sex toy. SO fucking retarded. Let’s see what two blocks of wood coming together, and it’s either 20 or 5K, because no one has any idea and telling someone that they have crap is apparently fucking useless.

Are you kidding me? They’re talking with the irritating narrator in the christmas chamber showing off fucking christmas cards from the olden days. I can’t believe people actually give even a third of a shit about things like that. That was obviously a lead-in to an “offsite” as I will term it to look at more stupid fucking christmas cards. The first magic of innovation was a pop-up card of a church with a dude in a window. Truly inspirational.

This christmas thing is being ground into the ground. And now it’s basically the American’s fault for making christmas red and stupid shiny. They have this tiny little icon-looking picture of santa creeping on a kid. It’s owned by an ugly ass lady that’s fat, and it’s worth another ten grand.

There’s going to be another hour or so of this show, so I hope that you’re super pumped about the remainder. I might start considering easing off the livebloging of the entire program so that you can recreate a proper image in your mind’s eye and instead focus on just mentioning things on occasion and padding the remainder with boundless bitching. I can provide complaints in spades, and I don’t think I even need subject matter. I could just endlessly bitch about one thing then bitch about it in circles based on the earlier bitching.

BOXES! It’s an old man with a bunch of fucking gold boxes, the first one being worth at least five fucking grand. So he has a pile of fucking boxes worth thousands a fucking pounds a pop. Russian cigarette case? Twenty fucking grand. BRITISH. The total, apparently, is fifty to sixty. That’s pretty fucking nice, and he sold some of them and made 55K. I would keep some, I figure if they’re that old and still in one piece, they must work pretty well.

Now we’re on to the obligatory vase. It’s pretty pointless, and I guess kinda big. The dude claims it’s 200 years old, the appraiser is going to be like “no, older” I guess. We’ll see what he says about it. I’m not even sure if I’m going to pay enough attention for it to even matter. He said a year, but that sounds like math.

Oh, a thousand. Maybe the math even wasn’t hard. It was just garbage. The price tag!? 10-15. It seems they just like that range. “Oh, that’s old, how about 10K, get the fuck out of here let’s look at some fucking christmas cards!” They’re going to take it to auction.

More boxes, with some mail in it from 1903. A cup with some crap. They’re cups that are royal or something. Mass produced garbage, I guess. Hopefully it’s cheap, yes, it’s cheap according to them, but the wrapping was worth about four hundred.

Guitar. Potentially played by Bob Marley. This is starting to sound more and more like ebay. And now we’re pricing on speculation. That’s even better. We’re quickly approaching zero content for the time consumption.

What do you think is next? More boxes? Yep. Boxes. They’re going to probably boxes that are made of money. BUT. They are probably fake. Are they fake? Yes, they’re fake!? Let’s find out. He paid many many money for them, thousands, apparently, but they’re fake. Suck it bro! Oh, damn, he got a refund. That’s pretty unfortunate when I was hoping to see someone actually learning a lesson. Let’s follow this up with a speech from the dumbs narrator.

I’m going to skip this section, because it’s far more than boring and I think the time for the next few minutes might be better spent doing anything at all, maybe even just drooling.

I’m going to cut this short. It’s an antique show, and a christmas special at that. It’s dumb, and no one really cares about it. I’ve chosen to poop. Good day.

roxa: dannyundersee: flamebelladonna: thegoodshiprieru: marie...

Sat, 03 Mar 2012 11:40:05 -0500

roxa:

dannyundersee:

flamebelladonna:

thegoodshiprieru:

marielikestodraw:

beautifultimepieces:

These are clocks that knit. Clocks that knit. They knit 24 hours a day for 365 days and every year you get a new scarf to mark the passing of time.

But seriously: Clocks that knit.

You have no idea what I would do for this.

what

What a fucking cool idea! Holy shit.

thisismyinfinityplusone: Dude that first one. I lol’d...

Fri, 24 Feb 2012 23:46:44 -0500

thisismyinfinityplusone:

Dude that first one. I lol’d forever.

My, and I assume other 0-day orders of my book appear to have...

Fri, 10 Feb 2012 16:15:03 -0500

My, and I assume other 0-day orders of my book appear to have arrived.

Where the hell is yours?

sshrkv is awsm

Annoying problems get annoying solutions.

"The authors then did a separate experiment where instead of using ‘sexually naive’ rats as the..."

"On its third firing the chain snapped immediately and one ball tore into a nearby cabin, knocking..."

I am having trouble determining if this article is real or not

Photo

wilwheaton: I was playing Civilization: Revolution on my iPad...

mcgoats: oh my god You have been warned.

I don’t understand what’s going on, and I think...

CLOS FSM with MOP Sauce

The Idea

The Design

Setup

Implementation

The Polish

The Result

The Demo

wilwheaton: Holy Balls, this is hilarious. My friend Joel...

suztacular: This is horrible and I shouldn’t laugh

Hinge -- v0.0.1

ilovecharts: Jason also gave me the opportunity to stretch the...

The Definitive Guide, now on Amazon.com

GitHub and CI Project Workflow Guide

Overview

Production code is always a git-tag‘ed promoted Jenkins build

origin/master is always in good shape

Every line of code is peer reviewed

Every pull request passes the test suite

Everything that was ever a conversation is documented

No new features without tests

On pull requests

On Hotfixes

TL;DR Checklist

Photo

Summary of Antiques Roadshow: UK

roxa: dannyundersee: flamebelladonna: thegoodshiprieru: marie...

thisismyinfinityplusone: Dude that first one. I lol’d...

My, and I assume other 0-day orders of my book appear to have...

Production code is always a `git-tag`‘ed promoted Jenkins build

`origin/master` is always in good shape