Skip navigation

Category Archives: Uncategorized

I’ve transitioned back from Drupal to WordPress. I moved to Drupal as an experiment to get more familiar with it as we hosted quite a few drupal sites at work. However, I’ve moved over to another team and no longer have any day-to-day exposure to Drupal. . . and there’s no automatic update process with Drupal for new releases so it takes a while to actually update the blog when, say, a security release occurs.

So, to take care of that, I’ve moved back to wordpress. The old posts here may be a little less formatted than before, but the overall content is still the same, which is the important thing after all.

I read an article by Amy Ratcliffe about her first visit to Dragon Con. She’s got a lot of praise for the convention, but does touch on some of the downsides and shortcomings of the annual event in my fair city. I was in the middle of writing a reply to her to thank her for her writing as well as provide some useful tips I’ve accumulated during my many years of attending and volunteering and realized a) it was turning into a very big e-mail and b) it was something that might be useful to more than just her. Thus, this blog post was born!

So, here’s my “unordered list of things that help me survive Dragon Con and not go out of my mind”

  • Crowds in common areas start to get crazy around ~10:30am until ~2:00am. If you want to move quickly, try to time your travel to occur while panels are in session and absolutely avoid the time between panels.
  • Sky walks are very convenient, air conditioned and keep you out of the weather. They also tend to be slower than using the streets during the day. The streets are hot, humid and not somewhere I’d suggest folks go late at night without friends. But they are much faster when you’re trying to go from the Marriott to the Food Court and back inside of 25 minutes.
  • Speaking of the Food Court, the lines are crazy. I had good luck with Checkers, Great Wraps and My Friend’s Place this year. I avoided DQ and Sushi Yami like the plague due to the lines. I ventured into Momo for the promise of a breakfast buffet, but they’d swapped it out by ~11:00am when I made it in there, so didn’t try it (though I’ve been there in the past and they tend to have good food for reasonable prices.
  • If you have the option and can use stairs, get a room on a lower floor. I was in the Hilton on the 8th floor and, when the elevators were crowded and slow (which was between 8am and 2am) I used the stairs instead. This saved me a tremendous amount of time and had the added benefit of giving me more steps for my Fitbit which added to my daily calorie budget (which, given I was eating at Checkers and Great Wraps, was badly needed).
  • Always have a bottle of water in your backpack whether you needed it or not, because you will need it.
  • Stop by your hotel room for an hour sometime during the day to take a break. If you can’t get to your hotel room, find a quiet hallway or track room to take a break in. The Sheraton’s “non-registration” hallways tend to be not nearly as packed. The Westin’s been reasonable as long as you’re not on the same floor where the Peachtree ballroom load in is happening. In the motor lobby level of the Hyatt, there’s a long hallway that’s not heavily trafficked. In the Hilton, there are areas every 5-10 floors or so with tables and chairs where you can rest. In the Marriott . . . well, the Marriott is just crazy pants, but fortunately it’s connected to both the Hilton and Hyatt :-)
  • Don’t be afraid to push through a crowd saying “Excuse me” and “Pardon me” especially when folks are stopped in the middle of a walkway chatting, taking pictures or looking at a vendor booth instead of moving. Walkways are for moving. If you’re not moving, at the very least get to the edge of the walkway. If you can’t get to the edge of the walkway, keep moving. . . and act with the expectation that others should do the same.
  • If you want to take pictures of a costume, do so in a way that doesn’t block a walkway or hallway. Ask the cosplayer if they can step over to an area that doesn’t obstruct traffic. I’ve never had someone who wasn’t willing to do that and it helps everyone. If you’re of a mind, feel free to suggest an open area for folks to move over to for pictures. “You guys know there’s an empty area over there that’s not in the flow of traffic. If you guys could do pictures over there, that’d help a lot. Thanks a lot, guys” are words I said several times this past weekend.
  • Visit the dealer hall one or two hours before they close and, preferably, on Sunday or Monday. This isn’t for deals, it’s to avoid the crush of other folks. If there’s something you need, this may not be doable, but if you have the ability, it will mean less folks you have to fight with to move around.

If anyone else has suggestions, feel free to send them to @dylannorthrup on Twitter, but for now this is my quick list of tips and generally applicable tricks for getting around the con without losing your sanity. There are few that aren’t generally applicable, but I’ll save those suggestions for next year and folks can buy me drinks at one of the hotel drinking establishments and/or room parties (again, tweet me @dylannorthrup to let me know what room party you’ll be at :-)

Update: The following suggestion comes courtesy of James Hsiao via his twitter account: 24/7 Games (some free) in the bottom of the Hilton, w/ the added benefit of excessive air conditioning if you’re running hot.

When listening to a recent episode of the Food Fight Show on the internals of Chef Client code, Dan DeLeo was discussing the creating Chef Clients and, specifically, what expectations should you have when calling Chef methods. For tracing execution order when invoking a method the suggest Dan provided was lots of git grep and “look through the code”. On the surface, this is a reasonable reply given the request. If you want to know what a program’s doing, the ultimate source of truth is the code. But there’s a trap laying there that has significant operational and supportability consequences.

Reading through the code is a fantastic way to figure out how something is being done. It’s pretty much the only way to get up to speed enough to be able to make reasonable suggestions for improving the implementation of whatever service the code/program provides. It should not, however, be necessary for someone writing a client to read the server code. If I want to write a web server, I don’t need to know the implementation specific details of how Chrome, Opera, Firefox, Safari, IE, et. al work. I need to make sure I speak the same common languages, HTTP and HTTPS, which everyone’s agreed to use. I’m quite certain Daniel Bernstein doesn’t care about which TCP stack you’re using when querying djbdns. He cares that his software’s giving back the right answers when queried using the defined, common methods.

If you’re writing a server, your APIs (aka Application Programming Interfaces) need to be documented. If you’re writing a server say “The code is the documentation”, a) that’s lazy and b) the documentation is only valid until the code changes. If I’m writing client code for Chef, should I subscribe to the git repository for change updates? How do I separate functional changes from refactoring or formatting changes? Should I also subscribe to all dependent modules (in case they change as well as recently happened for the excon gem causing chef client runs to abort and, thereby, prevent node convergence for nodes that had been recently updated)? How far down the rabbit hole does this go?

If I want to write a client, I believe it is a reasonable expectation to simply use the documented APIs. I also believe server developers should be responsible to have said documentation along with non-trivial examples of their use. I’m not saying you have to go to the level of DataDog’s API documentation but if you don’t you’re not doing it well. I think DataDog’s documentation looks so good because so many other people document their services so poorly.

There is a time and place for procedurally generated documentation based on comments, method definitions, etc. Javadoc and it’s brethren have their place. But if you’re providing a service and expect people to ultimately pay you for it (which Opscode does for their hosted and private offerings) expecting folks to ‘look through the code’ to determine functionality will work in the short term, but will cause heartache down the road when server implementations change and your client code breaks because of it. . . and hopefully your client code will break in a noisy, but not service impacting fashion. Service impacting breakages would not be good, but those silent failures that are around for weeks, months or longer that provide you a false sense of security are equally as dangerous. “Oh, yeah, we’ve got a process that checks for that. No need to worry. Let’s move on to the next thing.”

So, in summary, server or service developer: document your APIs (and include good examples, not simply “Here’s how I do ‘Hello World'”). And, if you’re a client developer, demand good documentation of the APIs you’re using. If you’re feeling generous, contribute documentation back to the community and make sure the developers know what your expectations are when using their product. Increase communication and do so via good documentation!

But that’s just my opinion. I could be wrong.

I’ve been a big user of ‘screen’ for a couple of decades. Yes, I’m old and have been using some form or another of unix for over 20 years. Aside from the fact that means I’m becoming older than dirt, it also means I’m also set in my ways. I find methods to do things and, over time, customize those methods until they become like an old pair of shoes or leather jacket. “Why should I change? The way I’m doing things works really well.” And that’s what I thought of ‘screen’. For those who don’t know, screen’s a way to take a single terminal window and be able to have multiple sessions going on inside that single window. You could detach it on one computer, then re-attach on another computer without losing any of the session you were working on. Back in the days of dial-up, it was crucial. It was crucial for the occasional maintenance task that “Absolutely Positively Cannot Be Interrupted At All” to help mitigate me being disconnected from whatever I was working on (typically a long-running compile or software install). Eventually I started using it in my every-day workflow to interrupt tasks in medias res to be picked up later when someone wasn’t telling me how they’d broken something or other. It stood me in good stead for 20+ years through many, many jobs. Recently, though, I’ve migrated away from ‘screen’ to a newer alternative: ‘tmux’. It fills the same role as ‘screen’ by allowing mutiplexing sessions in a single window, but improves on ‘screen’ in a few significant ways:

  • Much better handling of the changing of screen size. ‘tmux’ dynamically adjusts when any of the attached terminals looking at the particular session resizes. It will choose the size of the smallest attached terminal. Also, the size of any individual multiplexed session is independent of the size of any other session, so if you’ve got multiple terminals of different sizes attached to the same overall tmux server, they can each be different sizes and it won’t affect any other window. Very handy.
  • Easier splitting of windows. ‘screen’ would let you split a window horizontally, so you had one up top and one down below. I believe there was a way to adjust the sizing, but it was a pain and I didn’t use it much. With tmux, you can split a session vertically as well as horizontally. I typically like the left half of my window as a tall editing pane, then the right half split between two panes for entering commands, reading man pages, or editing secondary files. With ‘screen’, I’m not sure if that’s possible. With ‘tmux’, it’s trivial.
  • Scriptability. ‘tmux’ allows you to execute arbitrary commands read in from scripts. I have a script that allows me to set up a new window with my default pane layout. Any time I create a new pane, it’s already set up for me without any additional work on my part.
  • Mouse interaction. When I first started using ‘tmux’, I found out you could select windows using a mouse. It was really cool, but interfered with the select and copy inside iTerm 2, so while it was a selling point, it’s something I’ve stopped using.

Modifications I’ve done…

  • I’ll say that old habits die hard. The default bind key in ‘tmux’ is Control-b, but I’ve switched it to Control-a which is the default in ‘screen’. Two decades worth of keystrokes is hard to overcome. In fact, the first part of my .tmux.conf file is adding in some ‘screen’-like key binds.
  • ‘tmux’ by default doesn’t let you easily attach multiple windows to the same server like screen does with ‘screen -a’. I’ve got an alias of ‘ta’ set to ‘tmux new -t 0′ which will re-attach itself to a currently existing server. It’s not as smart as screen in that it’ll create a new server if one’s not currently existing, but I know to simply use ‘tmux’ after restarting my box.
  • Using the scripting infrastructure, I’m able to use a script to open an arbitrary number of panes ssh’ing to different hosts and have the keystrokes synchronized so what I type goes to all of the hosts. I found a script named ‘ssh-multi’ by a D.Kovalov that I’ve renamed ‘mwin‘ (for ‘multiple windows’) and been using during maintenances to log in and execute the same commands on all affected hosts instead of having to retype them on each individual box.
  • Useful pattern to use with ‘mwin': SLEEPTIME=$(expr $(hostname | sed -e 's/non.*numeric.*hostname.*bits//') * 30); sleep $SLEEPTIME; sudo /etc/init.d/java_thingy restart . . . You can replace the hostname bit with ifconfig or some such that’ll get you a number that’s unique to that host.

If you’re a long-time ‘screen’ user, spend a few days playing with ‘tmux’. I think you’ll find it’s worth the time investment.

There’s an idea in game design regarding interactions and choices. It was originally brought to my attention when I was an avid player of the Vs. TCG. Every decision you make is a chance to make a wrong decision. Vs. as a game had several different phases in a single turn and, in each of those phases, there are a lot of different decisions that can be made. Characters, equipment, locations and resources are brought into play during the recruitment phase; typically you want to play the highest cost character you can as a character’s power increases roughly logarithmically with its cost; if you can’t play the highest cost character, you’ll have to decide how to split your available resources during recruiting to make the best of a non-optimal situation. Characters are arranged in the preparation phase; if characters are able to attack, be attacked, reinforce/support other characters depends on how they’re arranged. Attacks take place during the attack phase; the optimal order of attacks will depend on the arrangement of attacking characters *and* order of defending characters to be able to remove support away from vulnerable characters first, then attack through those vulnerable characters for maximum damage. During the recovery phase, if any of your characters became stunned during combat, you can choose one of them to recover and the rest get KO’d. If it sounds like the game is complicated, you’re a good judge of descriptions. I’ve not even gotten into the specifics of combat (when to play Plot Twists; powering up; activating abilities; etc.) just the high level game play. If you make a mistake early on in the game (play the wrong character; arrange in the wrong formation; attack in the wrong order; used extra cards during combat you might need later) it is a mistake that could lose you the game due to that decision (took more damage from an attack than you should; had an extra character get stunned that you could not recover; or the converse of both of those). Because there are so many decision points during the game, that’s a lot of opportunities to make the wrong decision. Part of the appeal of Vs was, to a large extent and given equally matched deck builds, the better player would win the game because they would make fewer mistakes. Inevitably it didn’t really matter how many correct decisions you or your opponent made, the game would come down to who made more mistakes and when. The challenge of the game (and a lot of the fun) came from how well you could play and how many bad decisions you could avoid. What’s good in a game is horrible in a production computing environment. When I’m making a modification to a system, my ideal method for doing so is to not make any decisions during the process. I follow a documented procedure, preferably using a script to perform the change and the post-change validation. The script(s) is(are) run using some automation tool and done in a “one -> many -> all” procedure where the changes are validated in an incremental fashion before rolling out across an entire infrastructure. Every time I type on a keyboard, that’s an opportunity for making a mistake. There are many websites and plenty of horror stories admins can tell you over drinks about typing ‘sudo rm *’ in the wrong directory; rebooting the wrong box; installing an upgrade to a package that should have worked but didn’t; or any other number of unforeseen complications that caused what should be a routine change to go horribly awry. I’ve got a few stories of my own I’m not proud of, but which I will definitely bring up during any sharing of “disaster porn” stories. But I’ve also got the story of increasing server capacity for the FoxNews and USAToday websites on 9/11 and how neither of those sites needed to go to a stripped down front page due to the quick reaction, standard procedures and automation framework we had in place. I’ve got the story of rolling out RAM upgrades to 800+ servers over two nights without a single site impact. I’ve got stories of things going right and they’re the ones I’ll also tell along side the time I stopped up to 1.3 million people from being able to send e-mail. Making choices is fun as long as you make the right choice. Making the right choice is much easier when you’re planning things ahead of time instead of doing it on the fly while systems are down, customers are impacted and senior VPs are on a bridge asking for status updates. You should always make your mistakes early, often and in a way that you’re able to avoid when you eventually promote them to production. That way you have plenty of time to go make mistakes playing games and not running your site.

First off, thanks for a wonderful game that I’ve spent far too much time playing. WoW is an amazingly crafted experience and it keeps bringing me back in time and again. Thank you for you and your team’s contribution to that experience. Now, on to the reason for this post. I tweeted you a few weeks ago asking why the new MoP bag pattern is stuck behind two daily reputation grinds. You side-stepped the question in your reply. So, I’ll ask again and do so in more than 140 characters. If answering this properly will require more than 140 characters, feel free to respond in a dev blog or something similar, but I’m asking again because I’d like to get an answer specifically relating to the reputation locking for the new MoP bag recipe. I’ve been a tailor since vanilla. There were three reasons I become a tailor back then: 1) crafting gear for my priest; 2) being able to turn cloth into Enchanting mats (I coupled Tailoring and Enchanting); and 3) to make bigger bags. Those reasons (along with Spellthread) are largely reasons to continue with Tailoring as a profession. . . at least up until Mists. I still have crafted gear for myself. I’ve still crafted gear to DE so I can level my Enchanting. I’ve also made Spellthread for all of my characters. But I haven’t been able to make a new bag in Mists. Prior to Mists, in every expansion Tailors had access to a new bag pattern with minimal effort and a second “rare” pattern that required much larger effort to attain (and increased materials to craft, including daily cooldowns). This seemed a very reasonable compromise. Don’t want to spend the extra effort? Use the smaller pattern. Care a lot about space? Spend the additional time to get the biggest bags and simultaneously WoW and amaze your friends and guildies! The common bag pattern was typically the same size as the “rare” bag from the previous expansion. Mooncloth Bags and Netherweave Bags both have 16 slots; Primal Mooncloth Bags and Frostweave Bags both have 20 slots; Glacial Bags, Abyssal Bags and Embersilk Bags all have 22 slots. With MoP, the only available bag pattern is the Royal Satchel. While its size is impressive with 28 slots, it’s also stuck behind two reputation grinds. There’s no incremental steps for a tailor to increase their carrying capacity. I can see not wanting a common crafted bag to jump 4 slots from the previous expansion to 26 slots even if that’s how much the Illusionary Bag carried. There’s an open tier for crafted bags at 24 slots. It would seem straightforward to add a new “Windwool Bag” recipe at that tier, have it require 20x Windwool Bolts and 1x Eternium Thread and call it a day. If you want to follow in the steps of the Embersilk Bag, have it require 15x Windwool Bolts and 15x Spirit Dust. If you want to be less straightforward, throw in a Dreamcloth pattern that requires Windwool as a reagent on a daily cooldown to effectively make the Illusionary Bag the new MoP common recipe. But having a huge gap in effort between Cataclysm and MoP for making new bags seems a large break with what has become the traditional bag progression. While I do prefer comfortable, knowable situations, I understand not wanting to continue doing things in a certain way because “that’s the way we’ve always done it”. However, from the outside, this seems like change for change’s sake. Right now I’ve completed the Golden Lotus rep grind on my Tailor and I’m just starting to work on the August Celestials. Working with this faction interacting with the four beings responsible for defending Pandaria from the Sha seems like it would be awesome for a lore nerd like me. It’s not. I resent being forced into it for a bag recipe. I’m not looking for the mount. I’m not looking for the high level gear. I’m looking for the bag recipe and in order to get it, I need to spend a month and grind to Exalted. This is after the 2-3 weeks it took to grind Golden Lotus to Revered. A HUGE difference between “how it’s always been done” and how it’s being done now. And, as a side note, I’m enjoying the Shado-Pan dailies. I don’t have specific incentive for doing them, I just enjoy their story. I wish it was the same with the Celestials, but it’s not and that’s because of the choice to lock the bag recipe behind a double grind, one to Revered and the other to Exalted. So, with all this as preamble, here’s the question: Why? … Ok, that’s a bit open ended for a question, so here’s some specific questions: What was the reason behind changing bag pattern acquisition in MoP? Why put the new pattern behind TWO reputation grinds? Why not have a common bag recipe that simply takes Windwool Bolts as a reagent? If you just wanted to “shake things up”, are you happy with the results? Has the feedback you’ve gotten from other players been positive or negative regarding this change? Are you likely to continue with the “One Giant Leap” idea for bags in future expansions; return to the previous practice of having a common and a rare pattern; or do try something new again? Thanks for taking the time to read through this post and I look forward to seeing your responses in whatever venue you choose to post them.

“Ohio really did go to President Obama last night.
And he really did win.
And he really was born in Hawaii.
And he really is legitimately president of the United States, again.
And the Bureau of Labor Statistics did not make up a fake unemployment rate last month.
And the Congressional Research Service really can find no evidence that cutting taxes on rich people grows the economy.
And the polls were not skewed to oversample Democrats.
And Nate Silver was not making up fake projections about the election to make conservatives feel bad. Nate Silver was doing math.
And climate change is real.
And rape really does cause pregnancy sometimes.
And evolution is a thing.
And Benghazi was an attack on us, it was not a scandal by us.
And nobody is taking away anyone`s guns.
And taxes have not gone up.
And the deficit is dropping, actually.
And Saddam Hussein did not have weapons of mass destruction.
And the moon landing was real.
And FEMA is not building concentration camps.
And U.N. election observers are not taking over Texas.
And moderate reforms of the regulations on the insurance industry and the financial services industry in this country are not the same thing as communism.”

— Rachel Maddow from 7 November 2012 transcript of “The Rachel Maddow Show”

Time is a limited resource. Through hard work, cleve investing you can always get more money. Money brings power and other worldly things. Money can also bring you friends (though not actual friendship) but nothing in this world gives you more time. So, today I am quitting one of the major time sinks in my life: RSS news feeds. I spend quite a bit of time each day trying to keep myself informed about a wide variety of topics: gaming, politics, finance, media, geek culture and a few other random things. Today I am voluntarily opting for time over knowledge.

There are a few feeds I will continue to read but they primarily involve webcomics and the blogs of friends and people whose opinion or knowledge I highly value. While I will walk down the path of ignorance consciously, I won’t do so without leaving a trail of breadcrumbs I can follow back if or when I complete the experiment and, based on the conclusions, decide to head back to the land of being fully informed. I will still have some large time consumers in my life. My job is the major one, but it’s also what keeps the roof over my head, food in the pantry and clothes in my dresser so I don’t see giving that up voluntarily any time soon. My kids are the second biggest one and time will eventually lead to them going to college and reducing their reliance on me (for good and for ill). This leaves the frivolous time sinks: television, podcasts and gaming.

I actually have been cutting back on television quite a bit of late and shifting my viewing to Netflix. This means my TV is more infrequent and can correctly be characterized as binging. It also means, while I won’t always be current on a show, I can schedule watching of the show at a more convenient time where it won’t intrude on other pursuits.

Next up is podcasts. I consume podcasts similar to how I consume RSS news feeds (and for a similar purpose). I’m not going to do anything with them right now, but will keep them in mind as another avenue for experimentation to recover time from. For now, I will try to minimize its impact on my free time by indulging it concurrent to the final time sink: gaming.

For me, gaming is equivalent to World of Warcraft. I spend a couple hours a night playing it. It is how I decompress in the evenings and wind down after a long day. I don’t spend nearly the amount of time I once did on WoW. When I was actively raiding I was easily spending 40 hours a week in the game. Now, it’s closer to 10-15 hours a week. There was a time when it was 0 hours a week, but I still enjoy being able to hang out with some of my friends, even if I’m doing so virtually instead of in real life.

What will I do with my newly freed up time? Hopefully some writing. Hopefully spending more time with my kids. Probably doing more reading. We’ll see how it goes and, if the results indicate the experiment was a failure this is an easily reversible change.

I often forget some of the more semi-complicated ways of doing things in the programs I write.  Typically I’ll just cut and paste from a previous bit of code I’ve written and adapt that bit to what I’m doing (essentially, filing the serial numbers off the code).  If I don’t have example code handy, I’ll go to Google and see what examples are out there for whatever I’m trying to do.  This works pretty well since I’m rarely trying to tread new ground and there are a lot of folks out there on the internet who are much smarter/more experienced than me.\r \r Read More »

As in all things, it’s important to remember what happened before so a) we know how we got here and b) we know what to do going forward.  Now, this is a good life lesson, but for the purposes of this post, I’m actually talking about the history of commands you type at your bash prompt. Read More »