myShoggoth

New RSS Feed

Okay, Mr. Scoble convinced me to change my ways concerning my RSS feed philosophy.  His post (well, it is Scoble, so really there was a storm of posts...) convinced me not that my main feed should include all the content of each article, but that I should provide a full RSS feed for my site that people can subscribe to if that's what they want.

RSS is really easy, there's no reason for an either/or approach.  It is easy to provide very targetted feeds for different purposes, so in these cases where different audiences have different desires, there's no reason not to support them all and leave it up to the consumer to choose.  That's the point of RSS, right?

In other words, there is no one right way, so why not support all the right ways that make sense?

Speaking of which, I'm considering whether to add RSS .91 and ATOM type feeds (maybe more?).  Really the only way to find out if there's a demand is to go ahead and make it available and see if people subscribe.  At that point there's no good reason to take it down even if people don't.  So, I'll probably do it next time I've got some free time and am feeling geeky enough.

If you're a subscriber and would prefer to read everything in your aggregator, go ahead and change your subscription to the full feed.  I'll be very interested to see how many people change over.

High Level Languages

Whether or not a higher level programming language is the right tool is as much a function of the programmer as it is the application being built. I've seen too many coders who believe that higher level languages such as Java, C#, Smalltalk, Perl, etc. are substitutes to knowing the details of what is happening at lower levels. In my experience, this attitude leads to heartache.

Using a language and a platform at the right level of abstraction for the work to be done is key to maximizing productivity.  It is often technically possible to write code at the wrong abstraction layer, but the mismatch between the tool and the job ends up causing extra work and decreased productivity.  Imagine writing a device driver in Smalltalk, is that the right tool for the job?

On the other hand, there are plenty of projects for which assembly or C are too low level to maximize productivity. You end up rewriting (and re debugging) boiler plate code and having to re implement implementation patterns... or reinvent them if it your first time solving a particular problem.

Not having to solve a problem for the umpteenth time either by having the programming language abstract the solution for you or by building on a platform or API that does it does not mean that you don't need to understand it, only that you don't need to reinvent it.

Building on something but not understanding what it is doing and how is a form of "Ignorance Is Bliss."  You may be able to get away with it, even for a while, but there's a great chance the lack of understanding will cause very difficult issues.

Let's take a vague example: inter process communication.

Starting at the lowest level, you could write assembly to tell the CPU exactly what you want to happen, map memory around, and get it to work.  Clearly you need to know the ins and outs of the CPU and exactly what is going on at the lowest level to get it to work correctly and reliably.

At the next layer up, you can build on low level facilities provided by the operating system, let's use the example of memory mapped files in Windows.  These are built based on the same things you'd have to do at the previous layer, but it is already done and debugged.  This doesn't excuse you from knowing how it works, though, because proper usage of any technology requires understanding of its design, strengths, and limitations.  When APIs and languages are used improperly it can cause major problems in software that fundamentally can't be worked around without re architecture.

COM is a great example for the next layer of abstraction (and within itself has many layers).  It builds on memory mapped files and other facilities in the OS, adding its own semantics and twists.  If you code using COM and don't understand how it works, why it does what it does, and where the pitfalls lay you will cause bugs.  Trust me.

Next level up let's consider the ATL C++ wrappers around COM, smart pointers, etc.  There are a few new things to worry about here, but the important thing is to realize that the conveniences are not a substitute from an understanding of COM (like using COM is not a substitute from understanding IPC issues).  Raymond Chen gives a great ATL COM smart pointer example where not understanding COM requirements (when CoUninitialize can be called) while using the simplifying templates will cause you problems.

I'm a big believer in using ATL and smart pointers, but their usefulness is in allowing a programmer who does understand the issues to code more effectively and efficiently by removing the need to write (and potentially make a mistake with) a lot of boiler plate source.  The usage must still be correct, and the only way to ensure that is to know how all the underlying systems work and relate to each and to your usage of the smart pointers.

Pop up one more level to managed (.NET) code like C#, and interop with COM objects.  You can easily make calls to COM objects with C#, but once again it does not remove the need to understand what is going on.  Now you need to understand what the .NET Framework is doing and how it interacts with COM in addition to everything already discussed (and this is only for the IPC portion of the code!).

This is not to say that there are not substantial gains from using a higher level of abstraction, I firmly believe there are.   But too often people assume that everything underneath their layer is being handled in such a way that they don't need to understand the details (or even the generalities), and go about writing code that makes no sense to anyone who really understands the full system.

In the end it all comes down to 1s and 0s, knowing the details about how the CPU performs its calculations, what a cache line is, and for pity sake what a pointer is and how it works is essential to being a computer programmer.  Knowing how to manipulate pointers and writing code on a daily basis that does so are two different things, and I think that gets confused by some who are good C programmers.

A really good C/C++ programmer can do great work in Java or C# once they learn how things work for that language, platform, and abstraction level.  Someone who only understands high abstraction layers, however, has a major task ahead of them to understand how things work at the fundamental level needed to write good C.  Whether or not they work in C, understanding the system they work at in that depth will make them more productive, more correct, and better programmers.

Home Roasting Coffee

Roasting your own coffee is one of those unique activities that makes it possible to optimize for both cost and quality.

Green Coffee Beans

The coffee bean is the dried seed of the fruit of the coffee tree, and because it is dried it has a long shelf life.  If you store green (unroasted) coffee beans correctly, they can last a year or two with only slow taste degradation.  I've kept some for four or more years and the results are still drinkable but very bland.  For the cost conscious, you can buy in bulk and store for a long time.

My rule of thumb is you can expect to pay half the price of roasted coffee for green beans as starting point, and it goes down from there.  An example of prices (for illustrative purposes only) might be:  one pound at $4.50/lbs., two pounds at $4.25/lbs., five pounds at $4.00/lbs., twenty pounds at $3.50/lbs.  I would expect the same coffee, roasted, to be for sale at $8-$9/lbs. or more, and you don't have as much control over quality (over the specific beans, roast level, and freshness).

Roasting

Roasting coffee is similar to popping popcorn; you heat the beans to high temperatures and the bean goes through big changes including expanding in size, which causes them to pop loudly.  You're cooking the beans, and many of the same principles and concepts apply from other styles of cooking:

1. There are a number of different ways of getting the heat to the beans, and each imparts a different type of taste.
2. Thermal inertia is very important, once the beans are heated to the temperature you want them it is critical to cool them down quickly.
3. Oxygen is the enemy, causing staleness.  Store roasted beans in an airtight container.
4. For optimum flavor you should "rest" the beans after roasting for a while, how long depends on the beans themselves and can vary from 12 to 48 hours by variety.

Rather than duplicate all the information about the different methods for roasting, I'll just give a pointer to my favorite source and his instructions on home roasting methods and devices.  The number of specialized small appliances for home roasting coffee beans has been steadily getting larger, and they have been getting better over time.  You can go from roasting beans in your oven or in a wok all the way to a specialty device where you put the beans in, dial a setting, and hit a button.

The next step up is small commercial roasters, which can handle one to four or five pounds of coffee and generally cost thousands of dollars.  Many are meant for large commercial outfits that want to try samples of the beans they're considering buying in bulk (and are thus called "Sample Roasters"), but more recently a niche has been found for small coffee shops and espresso stands that want to roast their own in small batches for cost savings and product differentiation.  High end home roasters have been known to buy them, but it is pretty rare due to both cost and batch size.

I have one big warning: Roasting coffee produces smoke, especially if you want to experiment with the darker roasts.  I used to roast over a vent in the kitchen, but now I strictly do it in the garage.  It only took a few mishaps and smoke filled house incidents before I was learned my lesson.  Once the batch size gets above 3 oz. or so, having a venting system to get all that smoke outside is important.