We all have to eat sometimes, even me. One thing I particularly like is hot and sour soup, but not the weird thick kind with egg in it. A long time ago, I found a recipe for the kind that’s thin, hot, and sour, but I’ve never been able to find it again. I remembered enough of it to at least be able to make the soup, though. Now, I’ll share my rather informal recipe with you. If I could remember where the original recipe was I’d just link there, but I found it once about five years or so ago, and never again.

This is not a recipe for the precise. I’m never very precise with it; no reason you should be either. Just eyeball it and taste it periodically to see if it needs more of whatever.

Ingredients

• Stock of some sort. I use chicken, but the vegetarians among us can use vegetable stock. Last time I made it I used 3 32 oz. cartons.
• Either that red Chinese BBQ pork you find at the store, or tofu, depending on your desire.
• A can of bamboo shoots. You could use two if you’re making a lot of soup, but that might be excessive.
• Lemongrass. Probably one per 24-32 oz. of stock, but you could add more if you wanted.
• Some basil, or Thai basil if you remembered to get it/can find it.
• Several limes.
• Some cloves of garlic, to taste.
• Some cooking oil.
• Some peppers, also to taste. I use habaneros, but you might want a lesser pepper. Last time I made some, I used two habaneros, but should have put in more. Your results may vary.
• Some rubber, latex, or nitrile gloves. If you’re using habaneros, you really don’t want to forget these. Once, I cut up a habanero without wearing gloves, and I was up with burning hands until about four in the morning. The gloves are pretty important.
• Optional If you’re afraid the habaneros won’t be enough, have some ghost pepper hot sauce handy to make it spicier. Remember, a little goes a long way.

Steps

• Put on your gloves.
• Mince the garlic and peppers.
• In a pot large enough for the soup you’re planning on making, heat some oil. Put the peppers and garlic into the oil and stir them around for a while. If you’re using habaneros it will be a little uncomfortable to be around. Turning the burner down a little can help there. Get a can or carton of the stock ready.
• Carefully clean off your cutting board and knife that you used for the peppers. Once that’s done, you can go ahead and take your gloves off.
• Once the garlic and pepper bits seem to be cooked, but before they get burned, dump the first thing of stock into the pot. Add the rest of the stock now as well.
• Squeeze a couple of limes and pour the juice in. Stir it around thoroughly, and see how sour it is. Add more lime juice as needed to make it more sour, but try to be careful not to add too much. You may want to only add one or two more limes worth of juice right now, and then see how sour it seems later. Sometimes it’ll get super sour all at once.
• Chop up the lemongrass and basil up and toss it in.
• Add the bamboo shoots. Don’t forget to open the can and drain it out first.
• Slice the Chinese BBQ pork into little strips, or cube up your tofu, and toss that in too.
• Check the sourness and hotness. If it should be more sour, add more lime juice. If it should be hotter, add some ghost pepper sauce one drop at a time. Stir thoroughly, then taste again. Repeat (carefully!) until it’s hot enough.
• Turn the soup up and let it boil for a while. Then, turn it down and let it simmer for however long seems appropriate. After an hour or so it should be good, but you can start munching on it earlier. I find, though, that it’s better after it’s simmered for a while, since the lemongrass isn’t as hard and the BBQ pork softens up a bit.

That’s pretty much it. It’s easy to make, tasty, and even better after it’s sat in the fridge over night, too. This recipe is pretty easy to adjust for taste as well; I like it spicy enough to strip the paint from the walls, but it’s easy to make less spicy for the benefit of the spice weenies among us too.

Equipment: 16” Dobsonian, 55mm, 12mm TeleVue eypieces, Paracorr.

New objects observed: NGC 3607, NGC 3608

Previously viewed objects: None.

Not that great of a night. I did see two new Herschel 400 objects, NGC 3607 and 3608, but even getting those took a while. This night was, sadly, murkier than the Clear Sky Chart indicated it might be (the smog’s still hanging around, and while it wasn’t as bad as it was for the previous few days it was still pretty bad), and that’s all I ended up being able to see. I think I may have a couple of eyepieces that need cleaning too.

To top it off, while I was setting the telescope I dropped one of the nuts that hold the wheelbarrow handles to the side of the telescope for moving it. I never did find the nut, but was at least able to get it back inside with just the eye bolt in place. The wheel on that side was leaning, though, and clearly before the next time I move the telescope around I need to get another nut.

Alas, but so it goes sometimes. I’m learning better now, at least, to tell how clear the sky actually is from how the mountains and whatnot look. Mt. Rainier was looking better yesterday, but still not great, and the other mountains were barely visible. I can’t be too surprised, though, since I’m also looking for pretty tough objects now, particularly in a city. If these conditions keep up I may have to put off looking for Herschel 400 stuff from home for a while. It doesn’t look like I’ll have any observing time for a little while though, according to the weather report.

Equipment: 16” Dobsonian, 55mm, 6mm, 12mm TeleVue eyepieces, Paracorr.

New objects observed: NGC 4216, NGC 4251, NGC 4278, NGC 4274, NGC 4283, NGC 4526, NGC 4414

Previously viewed objects: None. All new things this time.

The weather’s been pretty nice here over these last few days. Now that I’ve observed all of the Messier objects, I decided to take a crack at the Herschel 400. Everything I was looking for this night was pretty difficult; there were a number of galaxies that I was looking for that I never was able to definitely find, but I was able to find many of the ones I did set out to find. Most of the galaxies I found were 9th to 10th magnitude, but one (NGC 4283) was 12th. I didn’t expect to be able to see something that dim from my house in the city, but I kept seeing it with averted vision while looking at NGC 4274. I think it was just in a really good spot in the sky.

I fell into a general routine while looking for galaxies of this magnitude with the light pollution issues I have. I had a fair amount of success with using the 55mm eyepiece to look around at the general area until I could find where I thought the galaxy was. Sometimes I could just see it with the 55mm eyepiece, but sometimes if I couldn’t see it with the 55mm I could with the 12mm TeleVue, so once I found the general area the galaxy ought to be I’d pop the 12mm TV in and look around with that. Sometimes it didn’t work, but generally this process worked pretty well. I had to use averted vision a lot, however; these were pretty dim galaxies, after all. At one point I tried using the 6mm eyepiece when the 12mm TV wasn’t cutting it, but it didn’t actually help. I think I’m getting spoiled by the big eyepieces.

I also used the Paracorr coma corrector again for the first time in a while. It does help smooth the view out and didn’t seem to hinder finding the galaxies too much. It does narrow the field of view, though, which is why I don’t always use it. Still, it makes the stars look more point-like, which is always nice.

If you have the Octopress ADN timeline plugin on your site, and want to do the App.net domain verification, it’s really easy.

First, start the verification process on App.net.

Second, in whatever custom aside you put your ADN timeline in, find the link to your ADN profile (it should be something like “Follow @yourname”). Add ‘rel=”me”’ to the anchor tag.

Explaining further, change this line:

1

Follow <a href="https://alpha.app.net/{{ site.adn_timeline.username }}">@{{ site.adn_timeline.username }}</a>.

1

Follow <a href="https://alpha.app.net/{{ site.adn_timeline.username }}" rel="me">@{{ site.adn_timeline.username }}</a>.

Then, of course, finish the verification process on the ADN website.

And that’s it. Adding a configuration option to the plugin for verification would be easy enough, but since a new Octopress is theoretically coming out very soon, an easy solution like this is probably sufficient. I would imagine that whatever ADN timeline plugin that comes with the new Octopress will have the verification stuff built in.

Equipment: 16” Dobsonian, 55mm, 12mm TeleVue eypieces.

New objects observed: Messier 61, NGC 4261, NGC 4260, NGC 4270, NGC 4273, NGC 4281, NGC 4268, NGC 4324, Messier 98, Messier 100, NGC 4312, Messier 83 (Update: Geez, how did I manage to forget to actually list these when I first wrote this? I plead distraction by kids.)

Previously viewed objects observed: Messier 44, Saturn

Location: Near Mt. St. Helens

I had been on the verge of having observed all of the Messier objects for a while, but conditions here haven’t been good for observing for months. Finally a clearish night presented itself, and I decided to make a last minute trip down to the Mt. St. Helens area to try and observe those last Messier objects.

It ended up being good that I did, since as I was leaving Tacoma I saw thin high clouds in the west. I didn’t stay down there super long, since I was feeling kind of tired even on the drive down and wanted to get home at a halfway reasonable hour, but I did pretty well on this trip.

Saturn was an accidental observation; I looked at it while I was getting oriented, and I thought I was aiming at Spica. Oops. Messier 61, 98, and 100 were all pretty straightforward in the nice dark skies down there. The other objects just fell into place, because they happened to be there and I didn’t have to do a whole lot of looking. Sometime I want to do some heavy Virgo Cluster observing at a dark site when I can be more relaxed about leaving.

Messier 83 was the most difficult object of the night. It wasn’t particularly hard to see, but it was about 13º above the horizon, so it was at a bad angle and kind of hard to find.

I saw Messier 44 with the naked eye, and ended up aiming the telescope at it before I decided to leave.

Without trying, I also added a few objects my Herschel 400 list: NGC 4281, NGC 4261, NGC 4273, and M61.

Now that I’ve observed all the Messier objects, I’ll mostly focus on what parts of the Herschel 400 I can see from my house. Many of the objects there, however, aren’t visible from light polluted skies like mine, so I’ll only be able to get the easy ones there. I’ve been thinking about building a list of objects observable from an urban environment with a variety of telescopes, which I could do when there aren’t any city-visible Herschel 400 objects available. I also have that refractor that I’ve been working on that I need to finish, which would be nice for planetary and double star observations.

All in all, this is a pretty big milestone for me.

I’ve had these handy-dandy pages with wonderful vim tips up in tabs on my browser for a couple weeks or so now, and I don’t want to lose them. They’re super cool and worthy of study, though, so I’m stowing them here. As much as I’ve used vi and its derivatives over the years, there’s always more to learn.

• http://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118
• http://www.fprintf.net/vimCheatSheet.html
• http://vim.wikia.com/wiki/Search_and_replace

At long last, I’ve cleaned up and generalized the cookbook we’ve been using to install lighttpd on our servers here, and finally released the Chef cookbook for lighttpd to the world.

It works pretty similarly to the cookbooks for other webservers, so there aren’t really any surprises there. I have a few further things planned with it, like adding CentOS support and getting it to work with test-kitchen. In the meantime feel free to check it out, especially if you use or have used lighttpd in the past, and let me know if you have any suggestions. More information is available in the README and the lighttpd docs.

Update: And now it’s on the community site.

If you have a “mature”, “legacy”, or just plain old application and are considering using Chef or similar to automate provisioning and deployment, you might be a little discouraged when you browse through the available cookbooks and see that the vast majority of them are written for the latest and greatest programs and frameworks. You might be discouraged at first, like I was, when you see tons of resources for rails apps and ngnix, but not so much for, say, mod_perl and lighttpd. You’ve looked at the documentation for writing cookbooks, and writing a bunch of recipes for your setup looks pretty daunting.

Fortunately it’s not as bad as it looks. I wanted to get our infrastructure at Daily Kos using chef, which meant I had to get it working with our legacy software. The benefits definitely outweighed the headaches from it, and it turned out to be a lot less daunting than it seemed at first. Here are a few general lessons that I’ve learned from getting legacy apps working happily with Chef:

1. Dig around to see if someone else has already written the cookbook. It may be that someone else has already written cookbooks for parts of your stack. Dig around, use the Googles, or even ask people if they know of a relevant cookbook. Just because you don’t see it in the official Opscode cookbook repo or on the community site doesn’t mean that it’s not out there somewhere.

2. Could it be added to an existing cookbook? Historically, Daily Kos has run on a mod_perl backend, which has not been the new hotness for many years. Not surprisingly, no one had written a recipe for mod_perl when I first looked into it. Adding it to the existing apache2 cookbook was trivial, though, so I did that. It made what could have been a needlessly difficult task quite straightforward.

3. Is there an existing cookbook you can crib from? If there’s not an existing cookbook you can use untouched or extend, you might be able to cannibalize it for your purposes. For example, for a while I thought I was going to have to get Apache 1.3 working with Chef. This would have been pretty terrible for many reasons, not least of which having to forward port the old apache13 package from etch to later versions of Debian, and I ended up not having to take it to production. When I thought I was going to have to, though, I adapted the existing apache2 cookbook to install and configure apache13. They weren’t exactly the same, but it was a lot less work than it would have been otherwise.

   Another example from personal experience is the lighttpd cookbook (which has been Real Close™ to being released to the world at large for quite a while now, but I’ll get around to it eventually). There wasn’t an existing cookbook I could directly adapt, but I was able to at least derive quite a bit of it from the apache2 cookbook.

4. Write a cookbook from scratch after all. Hopefully by the time you reach this point, you’ve been able to use the tips above to lessen your load enough and familiarize yourself enough with Chef that it won’t be that big of a deal.

5. Take the opportunity to tighten your deploys up. If you’re like me, you settled into a workflow for setting up servers that works, but might not be the most efficient. Getting your app working with Chef might be a good opportunity to tighten that process up a bit. For me, the big improvement was finally building custom debs for a bunch of CPAN modules rather than building them directly from CPAN. CPAN is great and all, but after enough time spent sitting and waiting for them to build, along with modules unexpectedly upgrading or dropping certain old versions out of CPAN entirely I took the time to build those debs, and now provisioning’s a lot faster and more consistent. You might not need to build debs, but there’s probably something that could be improved.

Getting your legacy stuff working with Chef might not be quite as straightforward as it is with a newfangled Rails or Sinatra app, but it’s really not that big of a deal. Plus, once it’s out of the way you’re less likely to get delayed by little things like completely forgetting certain random dependencies, or not having anyone else in your company able to set the servers up.

If you’re doing local mod_perl development on Mac OS X and find that after Software Update runs that Apache is segfaulting on every request with an error like [Tue Mar 19 23:30:01 2013] [notice] child pid 43158 exit signal Segmentation fault (11), check your /etc/apache2/httpd.conf for a line like this:

1

LoadModule hfs_apple_module libexec/apache2/mod_hfs_apple.so

If it’s not commented out, do so. For whatever reason, mod_hfs_apple and mod_perl do not play nicely together. Remove mod_hfs_apple, and you’ll be up and running again.

Automation’s great for ops, no matter the size of your workplace. I’ve noticed, however, that there seems to be a certain assumption that automating deploying and maintaining servers with something like Chef is most useful for huge outfits with dozens, hundreds, or thousands of servers. Undoubtedly it’s great for them, but I think that same kind of automation is important even if you’re the only ops guy at your company and you only manage a small handful of servers. In fact, it may almost be more important, but there are a few considerations and best practices that are different with a small shop that I’ve noticed.

My experience is with Chef, but I imagine this applies to other automation systems like Puppet. These considerations would also apply to big places too, but I think they’d be easier to avoid with bigger staffs, and more servers may force better behavior.

The most important best practice with using Chef in a small shop is: Don’t cut corners with your cookbooks. If you only have a few servers, it’s easy to throw your hands up and leave important steps out of your cookbooks because it’s easier to just do it by hand when you deploy. I cannot stress how important it is that you not do this. It will bite you on the ass down the road, and you’ll waste a bunch of time tracking the problem down before you realize that you’ve been running ntpdate by hand rather than using the cookbook, or plunking some cron jobs in by hand rather than adding them to your cookbook. Even if you remember everything, eventually you’ll find a situation where you wish you had everything in place. Just bite the bullet and get it over with. Build your own packages if you need to.

I know better than anyone how easy it is to not follow this practice. Legacy setups are the hardest to be good about following the best practice here, but you really need to. Your cookbooks for legacy apps and systems don’t need to be beautiful examples of cookbook writing, but you’ll appreciate the effort later. Trust me.

“Grab-bag” cookbooks can be handy when you’re chef-izing an existing setup. Those little packages that are important but don’t need much to get them installed? Shove them in. If, later, you find they need some custom work, split them off to their own cookbook.

This isn’t as important as the above practice, and it applies to everyone, but if you’re on your own or working with one other person, you may need to Work hard at keeping your roles neat. Now that chef’s had environments for a while, it’s even easier. Rather than having separate roles for different subtly different installations, like “rails_staging” vs. “rails_production”, have a “rails” role and use “staging” and “production” environments to hold the differences. Some people prefer to use master cookbooks to keep these straight, but the point remains: minimizing the number of different versions of the same thing is good. Otherwise you may find, using “rails_staging” and “rails_production” as examples, that changes in one role may not make it to the other and strange differences may creep in that you don’t notice. The reason this is a small shop best practice when it applies to everyone is that without others to keep you in line, it’s easy to dash off that separate role when it isn’t really appropriate, and then you have all these extra roles that are just barely different from each other hanging around.

Resist the urge to be too clever for your own good with your cookbooks. Someday, some poor bastard might come along and have to figure out what on earth that cookbook you wrote is doing. It might even be you, so don’t make it too hard to figure out.

Finally: Make time to make sure all your Chef stuff works the way you think it does. The time to make sure that all your Chef ducks are in a row is when you’re sitting around bored, not when you’re single-handedly rebuilding your infrastructure in a different data center in a race against time before a hurricane hits the city currently housing your infrastructure. It may or may not make it run any faster, and events totally out of your control may strike you down, but at least you’ll feel a little less stressed while pulling everything together.

All of these small shop best practices boil down to “discipline”. They’re practices that would be good for any Chef user to follow, of course, but for those lonely souls out there who are the entirety of the ops team by themselves it’s doubly important. It kind of sucks, but if you’re by yourself you need to keep yourself disciplined to get the most out of Chef and not take the easy way out because it’s quicker at that moment. It will pay off later though when you really need it, and you don’t have to worry about installing that one package on all those servers manually when you have to rebuild all your webheads because the data center you had everything in went away.