Sunday, May 29, 2011
Doing a bit of belated Spring Cleaning and computer upkeep this weekend, so not a ton of time. Thus, links:
Wednesday, May 25, 2011
How Boyd Wrote
I'm currently reading a biography of John Boyd, and in light of Sunday's post, I found a recent chapter particularly interesting. Boyd was a Fighter Pilot in the Air Force. He flew in Korea, made a real name for himself at Fighter Weapons School (which was later copied by the Navy - you may have heard of their version: Top Gun), and spent the latter part of his career working on groundbreaking strategic theories. He was an instructor at FWS for several years, and before leaving, he made his first big contributions to the Air Force. He wrote a tactics manual called Aerial Attack Study. Despite the passage of Vietnam and the Gulf War, nothing substantial has been added to it. It's served as the official tactics manual all over the world for over 40 years (actually, more like 50 at this point).
And Boyd almost didn't write it. Robert Coram (the author of the aforementioned biography) summarizes the unconventional manner in which the manual was written (on page 104 of my edition):
Boyd could not write the manual and continue flying and teaching; there simply wasn't enough time. Plus, the idea of sitting down at a desk and spending hundreds of hours writing a long document brought him to the edge of panic. He was a talker, not a writer. When he talked his ideas tumbled back and forth and he fed off the class and distilled his thoughts to the essence. But writing meant precision. And once on paper, the ideas could not be changed. ...It's a subject I didn't really cover much in my last post: the method of communication can impact the actual message. The way we communicate changes the way we think. Would Boyd's work have been as great if he didn't dictate it? Maybe, but it probably wouldn't have been the same.
Incidentally, I don't normally go in for biographies, but this is an excellent book so far. Part of that may be that Boyd is a genuinely interesting guy and that he was working on stuff that interests me, but I'm still quite enjoying myself.
Sunday, May 22, 2011
About two years ago (has it really been that long!?), I wrote a post about Interrupts and Context Switching. As long and ponderous as that post was, it was actually meant to be part of a larger series of posts. This post is meant to be the continuation of that original post and hopefully, I'll be able to get through the rest of the series in relatively short order (instead of dithering for another couple years). While I'm busy providing context, I should also note that this series was also planned for my internal work blog, but in the spirit of arranging my interests in parallel (and because I don't have that much time at work dedicated to blogging on our intranet), I've decided to publish what I can here. Obviously, some of the specifics of my workplace have been removed from what follows, but it should still contain enough general value to be worthwhile.
In the previous post, I wrote about how computers and humans process information and in particular, how they handle switching between multiple different tasks. It turns out that computers are much better at switching tasks than humans are (for reasons belabored in that post). When humans want to do something that requires a lot of concentration and attention, such as computer programming or complex writing, they tend to work best when they have large amounts of uninterrupted time and can work in an environment that is quiet and free of distractions. Unfortunately, such environments can be difficult to find. As such, I thought it might be worth examining the source of most interruptions and distractions: communication.
Of course, this is a massive subject that can't even be summarized in something as trivial as a blog post (even one as long and bloviated as this one is turning out to be). That being said, it's worth examining in more detail because most interruptions we face are either directly or indirectly attributable to communication. In short, communication forces us to do context switching, which, as we've already established, is bad for getting things done.
Let's say that you're working on something large and complex. You've managed to get started and have reached a mental state that psychologists refer to as flow (also colloquially known as being "in the zone"). Flow is basically a condition of deep concentration and immersion. When you're in this state, you feel energized and often don't even recognize the passage of time. Seemingly difficult tasks no longer feel like they require much effort and the work just kinda... flows. Then someone stops by your desk to ask you an unrelated question. As a nice person and an accomodating coworker, you stop what you're doing, listen to the question and hopefully provide a helpful answer. This isn't necessarily a bad thing (we all enjoy helping other people out from time to time) but it also represents a series of context switches that would most likely break you out of your flow.
Not all work requires you to reach a state of flow in order to be productive, but for anyone involved in complex tasks like engineering, computer programming, design, or in-depth writing, flow is a necessity. Unfortunately, flow is somewhat fragile. It doesn't happen instantaneously; it requires a transition period where you refamiliarize yourself with the task at hand and the myriad issues and variables you need to consider. When your collegue departs and you can turn your attention back to the task at hand, you'll need to spend some time getting your brain back up to speed.
In isolation, the kind of interruption described above might still be alright every now and again, but imagine if the above scenario happened a couple dozen times in a day. If you're supposed to be working on something complicated, such a series of distractions would be disasterous. Unfortunately, I work for a 24/7 retail company and the nature of our business sometimes requires frequen interruptions and thus there are times when I am in a near constant state of context switching. Noe of this is to say I'm not part of the problem. I am certainly guilty of interrupting others, sometimes frequently, when I need some urgent information. This makes working on particularly complicated problems extremely difficult.
In the above example, there are only two people involved: you and the person asking you a question. However, in most workplace environments, that situation indirectly impacts the people around you as well. If they're immersed in their work, an unrelated conversation two cubes down may still break them out of their flow and slow their progress. This isn't nearly as bad as some workplaces that have a public address system - basically a way to interrupt hundreds or even thousands of people in order to reach one person - but it does still represent a challenge.
Now, the really insideous part about all this is that communication is really a good thing, a necessary thing. In a large scale organization, no one person can know everything, so communication is unavoidable. Meetings and phone calls can be indispensible sources of information and enablers of collaboration. The trick is to do this sort of thing in a way that interrupts as few people as possible. In some cases, this will be impossible. For example, urgency often forces disruptive communication (because you cannot afford to wait for an answer, you will need to be more intrusive). In other cases, there are ways to minimize the impact of frequent communication.
One way to minimize communication is to have frequently requested information documented in a common repository, so that if someone has a question, they can find it there instead of interrupting you (and potentially those around you). Naturally, this isn't quite as effective as we'd like, mostly because documenting information is a difficult and time consuming task in itself and one that often gets left out due to busy schedules and tight timelines. It turns out that documentation is hard! A while ago, Shamus wrote a terrific rant about technical documentation:
The stereotype is that technical people are bad at writing documentation. Technical people are supposedly inept at organizing information, bad at translating technical concepts into plain English, and useless at intuiting what the audience needs to know. There is a reason for this stereotype. It’s completely true.I don't think it's quite as bad as Shamus points out, mostly because I think that most people suffer from the same issues as technical people. Technology tends to be complex and difficult to explain in the first place, so it's just more obvious there. Technology is also incredibly useful because it abstracts many difficult tasks, often through the use of metaphors. But when a user experiences the inevitable metaphor shear, they have to confront how the system really works, not the easy abstraction they've been using. This descent into technical details will almost always be a painful one, no matter how well documented something is, which is part of why documentation gets short shrift. I think the fact that there actually is documentation is usually a rather good sign. Then again, lots of things aren't documented at all.
There are numerous challenges for a documentation system. It takes resources, time, and motivation to write. It can become stale and inaccurate (sometimes this can happen very quickly) and thus it requires a good amount of maintenance (this can involve numerous other topics, such as version histories, automated alert systems, etc...). It has to be stored somewhere, and thus people have to know where and how to find it. And finally, the system for building, storing, maintaining, and using documentation has to be easy to learn and easy to use. This sounds all well and good, but in practice, it's a nonesuch beast. I don't want to get too carried away talking about documentation, so I'll leave it at that (if you're still interested, that nonesuch beast article is quite good). Ultimately, documentation is a good thing, but it's obviously not the only way to minimize communication strain.
I've previously mentioned that computer programming is one of those tasks that require a lot of concentration. As such, most programmers abhor interruptions. Interestingly, communication technology has been becoming more and more reliant on software. As such, it should be no surprise that a lot of new tools for communication are asynchronous, meaning that the exchange of information happens at each participant's own convenience. Email, for example, is asynchronous. You send an email to me. I choose when I want to review my messages and I also choose when I want to respond. Theoretically, email does not interrupt me (unless I use automated alerts for new email, such as the default Outlook behavior) and thus I can continue to work, uninterrupted.
The aformentioned documentation system is also a form of asynchronous communication and indeed, most of the internet itself could be considered a form of documentation. Even the communication tools used on the web are mostly asynchronous. Twitter, Facebook, YouTube, Flickr, blogs, message boards/forums, RSS and aggregators are all reliant on asynchronous communication. Mobile phones are obviously very popular, but I bet that SMS texting (which is asynchronous) is used just as much as voice, if not moreso (at least, for younger people). The only major communication tools invented in the past few decades that wouldn't be asynchronous are instant messaging and chat clients. And even those systems are often used in a more asynchronous way than traditional speech or conversation. (I suppose web conferencing is a relatively new communication tool, though it's really just an extension of conference calls.)
The benefit of asynchronous communication is, of course, that it doesn't (or at least it shouldn't) represent an interruption. If you're immersed in a particular task, you don't have to stop what you're doing to respond to an incoming communication request. You can deal with it at your own convenience. Furthermore, such correspondence (even in a supposedly short-lived medium like email) is usually stored for later reference. Such records are certainly valuable resources. Unfortunately, asynchronous communication has it's own set of difficulties as well.
Miscommunication is certainly a danger in any case, but it seems more prominent in the world of asynchronous communication. Since there is no easy back-and-forth in such a method, there is no room for clarification and one is often left only with their own interpretation. Miscommunication is doubly challenging because it creates an ongoing problem. What could have been a single conversation has now ballooned into several asynchronous touch-points and even the potential for wasted work.
One of my favorite quotations is from Anne Morrow Lindbergh:
To write or to speak is almost inevitably to lie a little. It is an attempt to clothe an intangible in a tangible form; to compress an immeasurable into a mold. And in the act of compression, how the Truth is mangled and torn!It's difficult to beat the endless nuance of face-to-face communication, and for some discussions, nothing else will do. But as Lindbergh notes, communication is, in itself, a difficult proposition. Difficult, but necessary. About the best we can do is to attempt to minimize the misunderstanding.
I suppose one way to mitigate the possibility of miscommunication is to formalize the language in which the discussion is happening. This is easier said than done, as our friends in the legal department would no doubt say. Take a close look at a formal legal contract and you can clearly see the flaws in formal language. They are ostensibly written in English, but they require a lot of effort to compose or to read. Even then, opportunities for miscommunication or loopholes exist. Such a process makes sense when dealing with two separate organizations that each have their own agenda. But for internal collaboration purposes, such a formalization of communication would be disastrous.
You could consider computer languages a form of formal communication, but for most practical purposes, this would also fall short of a meaningful method of communication. At least, with other humans. The point of a computer language is to convert human thought into computational instructions that can be carried out in an almost mechanical fashion. While such a language is indeed very formal, it is also tedious, unintuitive, and difficult to compose and read. Our brains just don't work like that. Not to mention the fact that most of the communication efforts I'm talking about are the precursors to the writing of a computer program!
Despite all of this, a light formalization can be helpful and the fact that teams are required to produce important documentation practically requires a compromise between informal and formal methods of communication. In requirements specifications, for instance, I have found it quite beneficial to formally define various systems, acronyms, and other jargon that is referenced later in the document. This allows for a certain consistency within the document itself, and it also helps establish guidelines surrounding meaningful dialogue outside of the document. Of course, it wouldn't quite be up to legal standards and it would certainly lack the rigid syntax of computer languages, but it can still be helpful.
I am not an expert in linguistics, but it seems to me that spoken language is much richer and more complex than written language. Spoken language features numerous intricacies and tonal subtleties such as inflections and pauses. Indeed, spoken language often contains its own set of grammatical patterns which can be different than written language. Furthermore, face-to-face communication also consists of body language and other signs that can influence the meaning of what is said depending on the context in which it is spoken. This sort of nuance just isn't possible in written form.
This actually illustrates a wider problem. Again, I'm no linguist and haven't spent a ton of time examining the origins of language, but it seems to me that language emerged as a more immediate form of communication than what we use it for today. In other words, language was meant to be ephemeral, but with the advent of written language and improved technological means for recording communication (which are, historically, relatively recent developments), we're treating it differently. What was meant to be short-lived and transitory is now enduring and long-lived. As a result, we get things like the ever changing concept of political-correctness. Or, more relevant to this discussion, we get the aforementioned compromise between formal and informal language.
Another drawback to asynchronous communication is the propensity for over-communication. The CC field in an email can be a dangerous thing. It's very easy to broadcast your work out to many people, but the more this happens, the more difficult it becomes to keep track of all the incoming stimuli. Also, the language used in such a communication may be optimized for one type of reader, while the audience may be more general. This applies to other asynchronous methods as well. Documentation in a wiki is infamously difficult to categorize and find later. When you have an army of volunteers (as Wikipedia does), it's not as large a problem. But most organizations don't have such luxuries. Indeed, we're usually lucky if something is documented at all, let alone well organized and optimized.
The obvious question, which I've skipped over for most of this post (and, for that matter, the previous post), is: why communicate in the first place? If there are so many difficulties that arise out of communication, why not minimize such frivolities so that we can get something done?
Indeed, many of the greatest works in history were created by one mind. Sometimes, two. If I were to ask you to name the greatest inventor of all time, what would you say? Leonardo da Vinci or perhaps Thomas Edison. Both had workshops consisting of many helping hands, but their greatest ideas and conceptual integrity came from one man. Great works of literature? Shakespeare is the clear choice. Music? Bach, Mozart, Beethoven. Painting? da Vinci (again!), Rembrandt, Michelangelo. All individuals! There are collaborations as well, but usually only among two people. The Wright brothers, Gilbert and Sullivan, and so on.
So why has design and invention gone from solo efforts to group efforts? Why do we know the names of most of the inventors of 19th and early 20th century innovations, but not later achievements? For instance, who designed the Saturn V rocket? No one knows that, because it was a large team of people (and it was the culmination of numerous predecessors made by other teams of people). Why is that?
The biggest and most obvious answer is the increasing technological sophistication in nearly every area of engineering. The infamous Lazarus Long adage that "Specialization is for insects." notwithstanding, the amount of effort and specialization in various fields is astounding. Take a relatively obscure and narrow branch of mechanical engineering like Fluid Dynamics, and you'll find people devoting most of their life to the study of that field. Furthermore, the applications of that field go far beyond what we'd assume. Someone tinkering in their garage couldn't make the Saturn V alone. They'd require too much expertise in a wide and disparate array of fields.
This isn't to say that someone tinkering in their garage can't create something wonderful. Indeed, that's where the first personal computer came from! And we certainly know the names of many innovators today. Mark Zuckerberg and Larry Page/Sergey Brin immediately come to mind... but even their inventions spawned large companies with massive teams driving future innovation and optimization. It turns out that scaling a product up often takes more effort and more people than expected. (More information about the pros and cons of moving to a collaborative structure will have to wait for a separate post.)
And with more people comes more communication. It's a necessity. You cannot collaborate without large amounts of communication. In Tom DeMarco and Timothy Lister's book Peopleware, they call this the High-Tech Illusion:
...the widely held conviction among people who deal with any aspect of new technology (as who of us does not?) that they are in an intrinsically high-tech business. ... The researchers who made fundamental breakthroughs in those areas are in a high-tech business. The rest of us are appliers of their work. We use computers and other new technology components to develop our products or to organize our affairs. Because we go about this work in teams and projects and other tightly knit working groups, we are mostly in the human communication business. Our successes stem from good human interactions by all participants in the effort, and our failures stem from poor human interactions.(Emphasis mine.) That insight is part of what initially inspired this series of posts. It's very astute, and most organizations work along those lines, and thus need to figure out ways to account for the additional costs of communication (this is particularly daunting, as such things are notoriously difficult to measure, but I'm getting ahead of myself). I suppose you could argue that both of these posts are somewhat inconclusive. Some of that is because they are part of a larger series, but also, as I've been known to say, human beings don't so much solve problems as they do trade one set of problems for another (in the hopes that the new problems are preferable the old). Recognizing and acknowledging the problems introduced by collaboration and communication is vital to working on any large project. As I mentioned towards the beginning of this post, this only really scratches the surface of the subject of communication, but for the purposes of this series, I think I've blathered on long enough. My next topic in this series will probably cover the various difficulties of providing estimates. I'm hoping the groundwork laid in these first two posts will mean that the next post won't be quite so long, but you never know!
Wednesday, May 18, 2011
Recent tales of adventure on the internet:
Sunday, May 15, 2011
Adventures in Brewing - Beer #3: Bottling
After two weeks in the fermenter, I went ahead and bottled the Bavarian Hefeweizen yesterday. I probably could have bottled it a few days ago, but I decided to give it a little more time, especially since I don't really do secondary fermentation - that's a process where I would transfer the beer from the primary fermenter to a secondary, separating it from the majority of the yeast and giving it a chance to condition and clear. However, I only really have one fermenting bucket, and besides, transferring the beer opens it up to the air and the possibility of infection (by wild yeast strains, bacteria, etc...) I'm pretty good about sanitation, but still, the less chances for mistakes the better. Also, Hefeweizens are supposed to be cloudy - the name itself literally translates to "yeast wheat", or "wheat beer with yeast". The question of whether or not to use secondary fermentation seems to be a pretty contentious one, but for simplicity's sake, I'm going to stick with only using the primary for now.
The final gravity was 1.010. For some reason, Northern Brewer never mentions target gravity for any of their kits. Nevertheless, for a beer with a starting gravity of ~1.050, that final gravity was appropriate. My previous two batches came in a little lower than I was expecting, but this one was just what I was hoping for (in monitoring temperatures, it seems that conditions were ideal for this batch). Doing the math on this, I find that this will be a 5.25% ABV beer, which is just about perfect for the style.
As with my previous two attempts, the bottling process went smoothly. I did invest in an auto-siphon this time around, and yes, it was worth every penny. Not that getting a siphon to work was particularly difficult, just that it was a huge pain in the ass to get going. The auto-siphon makes that process very easy. Otherwise, nothing new to report - sanitizing bottles is a tedious chore, filling and capping the bottles is a little more fun, but also tedious and repetitive. I ended up just shy of two full cases of beer.
Like last time, the beer looked and smelled fantastic. It's a little brighter than I expected, but I expect it to darken up a bit as it conditions in the bottles (about 3-4 weeks after bottling the tripel, the color was significantly changed). The smell was really wonderful - all due to the yeast I used. It's a German yeast, but it has very distinct characteristics that I usually associate with Belgian yeasts. I really can't wait to try this beer!
(Cross Posted on Kaedrin Beer Blog)
Wednesday, May 11, 2011
Back in March, I posted about Neal Stephenson's new novel:
Not long after the release of Anathem, it was announced that Neal Stephenson's next novel was due in 2011 and would be titled "Reamde". The computer geeks among Stephenson's fans (which is to say, most of Stephenson's fans) were quick to wonder if the title was really supposed to be "Readme", a common name for help or pre-installation files on computers, but everyone insisted that it "wasn't a typo". Well, a couple of days ago, I see on Tombstone that HarperCollins has now listed the book on their site... as Readme. So was it a typo all along, or are the new listings (also on booksellers like Amazon) the actual typo?Well, as it turns out, the new listings actually were a typo. I don't know when it was corrected, but the book is now listed as Reamde everywhere. Also, on another Harper Collins site, there's a plot synopsis:
Four decades ago, Richard Forthrast, the black sheep of an Iowa family, fled to a wild and lonely mountainous corner of British Columbia to avoid the draft. Smuggling backpack loads of high-grade marijuana across the border into Northern Idaho, he quickly amassed an enormous and illegal fortune. With plenty of time and money to burn, he became addicted to an online fantasy game in which opposing factions battle for power and treasure in a vast cyber realm. Like many serious gamers, he began routinely purchasing viral gold pieces and other desirables from Chinese gold farmers— young professional players in Asia who accumulated virtual weapons and armor to sell to busy American and European buyers.Fans of Stephenson will notice tons of overlap with his previous work. Gold, virtual money, virtual worlds, etc... The blurb isn't exactly a barn burner, but if Stephenson is writing it, I'm reading it. It seems to have also been pushed back to September 20. It can't come soon enough.
Sunday, May 08, 2011
SF Book Review, Part 7
Continuing to make some progress through my book queue... and, of course, adding new books to the queue as I go along. This time, it's Lois McMaster Bujold's fault, as I enjoyed Shards of Honor so much that I went out and read the next two books in the (apparently long running and loosely connected) series. I've now got about 10 more of her books in the queue. If the first three are any indication, I'll probably move through them pretty quickly... but I'm getting ahead of myself.
I'm going to start with one from the actual queue though: Timothy Zahn's Cobra Trilogy. I've been listing it as one book, but it's technically an omnibus edition of Zahn's first three Cobra novels, and I'll review each separately below. As a side note, Zahn is currently in the process of writing another trilogy set in the same universe (the second novel was published this year, with a third tentatively planned for January 2012) and plans a third trilogy at some point in the unspecified future.
Wednesday, May 04, 2011
As per usual, interesting links from the depths of teh internets:
Sunday, May 01, 2011
Adventures in Brewing - Beer #3: A Wheat Beer for Summer
I had wanted to start this batch a little earlier, but compared to my first two attempts, this one is actually a lot simpler and should take less time to mature. It's a wheat beer (a Bavarian Hefeweizen to be exact), which is generally light and refreshing - a perfect beer for summer. Since I brewed this yesterday, it will take about a month for this to be ready to drink, which will be right around June, just in time for summer.
My last attempt was a Belgian style Tripel. It was a relatively ambitious attempt, but it came out reasonably well. I like it better than my first homebrew, though it's clearly not a perfect beer. Still, it was quite encouraging. This time around, I went with a kit from Northern Brewer and was surprised to learn how much simpler the Hefeweizen is to brew. No specialty grains and only one hop addition means that the time between each step is relatively long, letting me get some other stuff done while waiting to finish the boil (or whatever).
Brew #3 - Bavarian Hefeweizen
April 30, 2011
6 lb. Wheat LME
1 lb. Wheat DME
1 oz. Tettnang hops (bittering)
Wyeast 3068 Weihenstephan Wheat Yeast
As you can tell from the relatively small recipe (compare that to the recipe for the tripel), there's not much to this one, and the process really was a lot simpler. This was, however, the first time I've ever used one of Wyeast's "Smack Packs", which come in a little packet containing yeast and a sealed nutrient packet. A few hours before you're ready to brew, you "smack" the nutrient packet, which gets the yeast started. It's a little weird, and I wasn't sure if I did it right at first, but after about a half hour or so, I could actually hear the yeast going, and about an hour later, the packet was starting to swell (which is how it's supposed to work). Comfortable that my yeast would be ready to pitch once I finished, I started the process proper.
Brought 2 gallons of tap water to a boil, after which I removed from heat and added the liquid and dry malt extracts (incidentally, I've heard that it's better to rehydrate the DME separately, though I've never done that - perhaps next time I use DME), stirring carefully. Put it back on the heat and returned it to a boil. Added the hops, stirring carefully to avoid any overflow, started my timer, then sat down with my book and read for about 50 minutes, stopping only once or twice to check on the boiling wort, stirring occasionally. I prepared my ice bath and started sanitizing the rest of the equipment. When the 60 minute mark was reached, I added the pot to my ice bath. This continues to be a bit of a challenge, but the temperature dropped quick enough. Once it was at about 100° F, I took it out of the bath and poured through a strainer into the fermenter. Topped off the fermenter with enough cold water to bring it down to about 68° F, which was just about perfect according to my yeast package. Pitched the yeast, sealed up the fermenter, and installed the airlock.
I was surprised that I could really smell the yeasty character while pitching, though it makes sense, given that the nutrient packet had already gotten the yeast started. Previous attempts were using dry yeast (which would have no odor) and a vial of White Labs yeast, which was more concentrated (though probably around the same volume as the Wyeast packet, it didn't have the whole nutrient pack to get things started). Temperature in my closet seems to be a pretty steady 70° F, which is about exactly what I was looking for. I just checked the fermenter, and the airlock is bubbling away happily.
Original Gravity: 1.048-1.050 (approximate). The recipe called for 1.049, so I'm almost dead on there. Strangely, the Northern Brewer site/directions make no mention of the expected Final Gravity (not that it really matters, fermentation ends when it ends).
Though the process was easier, I didn't really cut much time off of the session. It came in at around 2-2.5 hours, which isn't bad at all. The real advantage of the simple process was that there was enough unbroken periods of time that I could get other stuff done while waiting. The really time consuming part continues to be getting the pot to a boil. This is probably because I'm on a electric stove. Well, now that it's warmer out, I may be able to invest in some outdoor equipment, which might make things easier.
I'm already working on the recipe for my next beer, which will probably be a saison in the style of the excellent Saison Dupont, one of my favorite beers and another crisp and refreshing beer for summer. The recipe won't be an exact clone, as my understanding is that the Wyeast version of Dupont's yeast is infamously finicky with regard to temperatures (which is the part of the process I'm least able to control at this point). So unless global warming hits with a vengeance in late-May/early-June, I'll probably end up using the Wyeast 1214 Abbey Ale.
(Cross posted at Kaedrin Beer Blog)
Where am I?
This page contains entries posted to the Kaedrin Weblog in May 2011.
Kaedrin Beer Blog
12 Days of Christmas
2006 Movie Awards
2007 Movie Awards
2008 Movie Awards
2009 Movie Awards
2010 Movie Awards
2011 Fantastic Fest
2011 Movie Awards
6 Weeks of Halloween
Arts & Letters
Computers & Internet
Disgruntled, Freakish Reflections
Philadelphia Film Festival 2006
Philadelphia Film Festival 2008
Philadelphia Film Festival 2009
Philadelphia Film Festival 2010
Science & Technology
Security & Intelligence
The Dark Tower
Weird Movie of the Week
Copyright © 1999 - 2012 by Mark Ciocco.