Disclaimer: The following is a diversion from BeerRiot. To all Rioters waiting on new features, I apologize. I can only claim temporary insanity due to cold.

I ran across two interesting Erlang posts recently. The first was to the Trapexit help form, where someone was attempting to implement a Brainfuck interpreter in Erlang, as a way of learning the language. I didn’t understand the question being asked, so I decided to give it a go myself, to see if I ran into a similar question.

A little while later, this is the implementation I had:


run(Program) ->
    run([], Program, [], 0, []).

run(Left, [$>|Right], LP, Data, RP) ->
    case RP of
	[D|Rest] -> run([$>|Left], Right, [Data|LP], D, Rest);
	[]       -> run([$>|Left], Right, [Data|LP], 0, [])
run(Left, [$<|Right], LP, Data, RP) ->
    case LP of
	[D|Rest] -> run([$<|Left], Right, Rest, D, [Data|RP]);
	[]       -> run([$<|Left], Right, [], 0, [Data|RP])
run(Left, [$+|Right], LP, Data, RP) ->
    run([$+|Left], Right, LP, Data+1, RP);
run(Left, [$-|Right], LP, Data, RP) ->
    run([$-|Left], Right, LP, Data-1, RP);
run(Left, [$.|Right], LP, Data, RP) ->
    run([$.|Left], Right, LP, Data, RP);
run(Left, [$,|Right], LP, _, RP) ->
    Data = io:get_chars([], 1),
    run([$,|Left], Right, LP, Data, RP);
run(Left, [91|Right], LP, Data, RP) ->
    if Data == 0 ->
	    {NewLeft, NewRight} = pass_match(91, 93, [91|Left], Right),
	    run(NewLeft, NewRight, LP, Data, RP);
       true ->
	    run([91|Left], Right, LP, Data, RP)
run(Left, [93|Right], LP, Data, RP) ->
    if Data /= 0 ->
	    {[91|NewRight], NewLeft} = pass_match(93, 91, [93|Right], Left),
	    run([91|NewLeft], NewRight, LP, Data, RP);
       true ->
	    run([93|Left], Right, LP, Data, RP)
run(Left, [X|Right], LP, Data, RP) ->
    run([X|Left], Right, LP, Data, RP);
run(_, [], _, Data, _) ->

pass_match(This, Match, Accum, Source) ->
    pass_match(This, Match, Accum, Source, 0).
pass_match(_, Match, Accum, [Match|Source], 0) ->
    {[Match|Accum], Source};
pass_match(This, Match, Accum, [Match|Source], Depth) ->
    pass_match(This, Match, [Match|Accum], Source, Depth-1);
pass_match(This, Match, Accum, [This|Source], Depth) ->
    pass_match(This, Match, [This|Accum], Source, Depth+1);
pass_match(This, Match, Accum, [X|Source], Depth) ->
    pass_match(This, Match, [X|Accum], Source, Depth).

Basically, a list for what is to the left of the current execution point, and another for what is to the right, as well as a list each for what is to the left and right of the current data point. Just tail-recurse through the right list (with a little extra jumping for the loop operators), pattern matching the opcode at the head of the right program list. Run the program by calling bf:run(Program) where Program is just a list of characters (including Brainfuck symbols if you want any result other than 0). For example, the following code will print out “Hello World” (found on the Wikipedia page).

[>+++++++>++++++++++>+++>+<<<<-] The initial loop to set up useful values in the array
>++.                             Print 'H'
>+.                              Print 'e'
+++++++.                         Print 'l'
.                                Print 'l'
+++.                             Print 'o'
>++.                             Print ' '
<<+++++++++++++++.               Print 'W'
>.                               Print 'o'
+++.                             Print 'r'
------.                          Print 'l'
--------.                        Print 'd'
>+.                              Print '!'
>.                               Print newline").

The second post I happened across was someone noticing the alternative way to make Erlang atoms (by enclosing characters in single quotes). Commenters were unhappy that they had never found a good use for functions named using these atoms.

Well, guess where that thought took me:


-export(['>'/2, '<'/2, '+'/2, '-'/2, '.'/2, ','/2, '['/2, ']'/2, stop/2]).

-record(tape, {left=[], current=0, right=[]}).

function_list() ->
    lists:foldl(fun({Atom, _}, Funs) ->
			case atom_to_list(Atom) of
			    [Char] -> [{Char, Atom}|Funs];
			    _ -> Funs
		end, [], proplists:get_value(exports, bf2:module_info())).

run(Program) ->
    Funs = function_list(),
    Atoms = lists:foldl(fun(C, T) ->
				case proplists:get_value(C, Funs) of
				    undefined -> T;
				    A -> [A | T]
			end, [], Program),
    [Current|Rest] = lists:reverse([stop|Atoms]),
    bf2:Current(#tape{current=Current, right=Rest}, #tape{}).

advance(Program, Data) ->
    [Next|Rest] = Program#tape.right,
    bf2:Next(#tape{left = [Program#tape.current | Program#tape.left],
		      current = Next,
		      right = Rest},

stop(_, #tape{current=Value}) ->

'>'(Program, Data) ->
    case Data#tape.right of
	[X|R] -> NewPoint = X, NewRight = R;
	_ -> NewPoint = 0, NewRight = []
    advance(Program, #tape{left = [Data#tape.current | Data#tape.left],
			   current = NewPoint, right = NewRight}).

'<'(Program, Data) ->
    case Data#tape.left of
	[X|L] -> NewPoint = X, NewLeft = L;
	_ -> NewPoint = 0, NewLeft = []
    advance(Program, #tape{right = [Data#tape.current | Data#tape.right],
			   current = NewPoint, left = NewLeft}).

'+'(Program, Data) ->
    advance(Program, Data#tape{current = Data#tape.current + 1}).

'-'(Program, Data) ->
    advance(Program, Data#tape{current = Data#tape.current - 1}).

'.'(Program, Data) ->
    advance(Program, Data).

','(Program, Data) ->
    In = io:get_chars([], 1),
    advance(Program, Data#tape{current = In}).

'['(Program, Data) ->
    if Data#tape.current /= 0 ->
	    advance(Program, Data);
       true ->
	    {Left, Right} = skip('[', ']',
	    advance(#tape{left=Left, current=']', right=Right}, Data)

']'(Program, Data) ->
    if Data#tape.current == 0 ->
	    advance(Program, Data);
       true ->
	    {Right, Left} = skip(']', '[',
	    advance(#tape{left=Left, current='[', right=Right}, Data)

skip(Up, Down, Acc, Src) -> skip(Up, Down, [Up|Acc], Src, 0).

skip( _, Down, Acc, [Down|Src], 0) -> {Acc, Src};
skip(Up, Down, Acc, [Down|Src], N) -> skip(Up, Down, [Down|Acc], Src, N-1);
skip(Up, Down, Acc, [Up|Src], N)   -> skip(Up, Down, [Up|Acc], Src, N+1);
skip(Up, Down, Acc, [X|Src], N)    -> skip(Up, Down, [X|Acc], Src, N).

Basically, create a function named for each Brainfuck operator. Then, convert all of the valid Brainfuck operators in the program into atoms, and use them to call the functions sharing their names. Run it just like the earlier example, bf2:run(Program).

Now, I’m not going to call the first implementation ugly. In fact, I think it’s a fair example of walking a list, doing different things depending on the value of the head of the list. But, I have to say that The second version does read a bit nicer, in some respects. (I also tried using the tape record in the first example, but I thought it made things worse.)

Yeah, okay, Brainfuck clearly still isn’t a great use for quirky-atom function names, but perhaps it represents some problem space that can make good use of them?

Anyone have a better neat trick – for either Brainfuck interpretation or funky-atom function names?

P.S. My apologies for not posting an answer to Alboin (the Trapexit poster). I can’t remember my login details for Trapexit. πŸ˜›

Disclaimer 2: WordPress really doesn’t like dealing with so many <s and >s. I think I got everything, but if something doesn’t work, that’s probably the culprit.

Denormalization, Processes

If you read the news, you’ll know that tuneups are happening behind the scenes of BeerRiot. If you came to this blog after reading that story, you’re wondering what, exactly, they are.

If I’m not feeling particularly communication-challenged, I’ll be able to explain them to you. πŸ˜‰

The first tuneup is one every webmaster has heard of: denormalization. I had been using a view to select data from three tables with one call. The performance drag of that query was serious enough, though, that I’ve decided to complicate things a bit and copy the extra bits of data I need from the other tables into the main one for the query.

The speed gain is great, and, somewhat strangely, the denormalization actually cleaned up a bunch of my code. ErlyDB lacks a “one-to-one” relation, so it was impossible for me to say “each record in this view is really just a record in this other table with some extra data.” That made for a bit of hackery swinging from one type to another. Without that extra table, I think the code reads more clearly.

(Disclaimer: I’m far from being an relational database master, so it’s likely that there is a much better way to express everything I’m doing. But, I’m happy to be making what seems to be forward progress.)

The other main change is more Erlang-centric. Until now, I had been tracking sessions using a customization of the Yaws recommended session server. This is basically a central process that stores opaque data associated with an id string. Whenever your app gets a request, it pulls the cookie value out and checks with this central process to find out if there is any opaque data associated with this key. It works (quite well, in fact), but it seems like a bit of a bottle neck.

So, I’ve decided that there’s a more Erlangy way to do things. What BeerRiot is doing now is starting up a new process for each session, and saving that process id in a client cookie. Then, whenever a request comes in, if it has a cookie with a PID, we can try to contact that session’s handling process directly. No central service required.

It turns out that there’s loads of benefits to having this session hanging around beyond relieving the central service bottleneck. It can cache data, smartly (i.e. listen for updates, etc.). It’s a natural place to run background processes (like propagating live changes to durable storage). I see other potential uses, but since I haven’t tested them yet, I’ll hold my tongue to avoid getting too many hopes up. πŸ˜‰

For Facebook developers: This process-session system wasn’t possible until just a few weeks ago, when Facebook started supporting cookies on the canvas page. Unfortunately, they only support them for canvas requests, and not for their “mock ajax.” For mock ajax, I’ve decided to just encode the cookie values in post parameters. It works (and it’s no more inconsistent than the rest of the Facebook Developer experience).

Update 2.Jan 18:52 EDT: If you spent any part of today poking at BeerRiot to see how the speed-ups turned out, you were probably rather dissatisfied. I just figured out that I didn’t fully rollout the update. πŸ˜› It’s there now, and I think you’ll be much more impressed.


Hi all. In case you’re wondering why BeerRiot has been down most of today – it’s a hardware problem. Something about faulty drives on the machine hosting my VPS, which keeps throwing things into read-only mode.

Hopefully they’ll get it fixed soon.

Erlang2Facebook Updates

I’ve just committed a couple of minor updates to the erlang2facebook library that I’m sure some of you are interested in.

The first (SVN revisions 7 & 9) is an API update to follow the Facebook team’s changes to profile_setFBML. Now, instead of just passing a single chunk of FBML, containing markup for the profile box, profile actions, and mobile profile, there are three distinct fields to shove those chunks in. Sorry about the non-consecutive SVN commits. πŸ˜›

The second update (SVN revision 8 ) is intended to show how to use ErlTL better (thanks for the tips, Yariv!). I’ve created render.et, and moved all of the render_* functions from canvas_controller into it. This allows me to use the more HTML-like syntax (code efficiency), while also taking advantage of ErlTL’s automatic use of Erlang’s binaries (runtime efficiency).

Erlang2facebook has Users!

Fun news this morning. BeerRiot’s Facebook App is no long the only Facebook App based on Erlang! The word is that these four are also using the erlang2facebook library:

Birthday Greeting Cards

Animated Gifts

Will you KISS me?

FB President

Awesome! Care to step up and take credit for your accomplishments, Mark?

Beer for Wine Lovers

As I sit here enjoying a home-brewed wine (!) that my parents made last fall (great, guys, by the way!), I’m reminded of a thought I had a few days ago, reinforced at yesterday’s NERAX North event. I was reading a piece in the New York Times about cask-conditioned ale, when I noticed that the piece was written by their wine reviewer.

As I was grumbling about a the Times sending their wine reviewer to do a beer review, it occured to me that the pairing was actually perfect: there is no beer that a wine-lover is more likely to enjoy than a properly-served cask-conditioned ale.

Think about it. What are the main differences between wine and your typical beer? Forget grapes vs. barley – those are inescapable. The three that come to my mind are: carbonation, serving temperature, and flavoring particles.

To start with, most wine is uncarbonated. Unless you’re specifically talking about champagne or sparkling wine, the assumption is that wine is still. Some people prefer their beverages this way. No sparkling on the tongue or in the nose, no unfortunate gaseous releases to deal with later.

What they don’t know is that most craft beer, especially true for cask-conditioned and “real ale”, has much less carbonation than macro-brewed beer. Artisanal brewers realize that large amounts of carbonation only hide the flavor of beer. The mild carbonation is intended only to keep the beer dancing on the tongue, and they stop before it goes all house-bouncing-rave style. Someone expecting a typical beer may even complain that what they got was flat. I think a wine-lover could truly appreciate the stillness and lack of distraction from the beer’s other flavors, though.

Most wine is also served only mildly chilled. Whites are often cool on the tongue, but reds are usually nearly room-temperature. Again, a certain amount of personal preference plays into the choice. Teeth are sensitive to temperature swings. There’s less pressure to finish a beverage before it gets warm, if it starts out at room temperature.

But, here again is a place where cask-conditioned ale stands apart. Casks live in, and are served from cellars. As such, the beer in them is served at “cellar temperature”, usually around 50ΒΊF. At this temperature, the beer’s flavors are much more available to the tongue. Beers served colder, sometimes even “ice cold”, numb the tongue as they’re drunk. The tongue is so frigid, it can’t tell if it’s drinking beer or iced tea.

But what about the flavor? Even if you serve with less carbonation and a higher termperature to allow the tongue to taste more, what if you don’t like the taste of beer? Certainly, wine is made from grapes, and beer is made from barley, and they taste different. But, there is one flavor aspect that are extremely important to many wines: tannins.

Tannins come from woods, and that skins of fruit, leaves of plants, and hulls of grains (really just the “fruit” of grasses). Homebrewers are familiar with cautions not to heat grain too high lest they extract the tannins of the hulls. However, cask-beers do extract tannins from another source – the cask! Yes, the wood in the barrel, often the same wood used in wine barrels, contributes tannins to the beer contained within. Familiar flavors for the wine connoisseur, right there in cask-conditioned ale.

Wine, served still, at or just below room temperature, drawn from a wooden container. Beer, served only slightly sparkling, just below room temperature, drawn from a wooden container. Now you’re just down to grapes vs. barley and hops. I think there may be hope for converting the wine-lovers yet. πŸ™‚

(And if you really want to push the grapes vs. barley and hops argument, I’ll offer two for comparison: mead (honey wine) and Brackett ale (honey and malt). Where’s the difference now?)

RSS Feeds

In case you’re using this blog’s feed to get updates about new features on BeerRiot, here’s a notice that BeerRiot now has its own feeds. πŸ™‚

I’m pretty green to the RSS scene, though, so if I’ve committed some terrible crime against RSS, please let me know, and I’ll get on fixing it. Or, if there’s just some way that I could improve the experience, which all of you RSS-fiends know about, those suggestions are most welcome.

BeerRiot Forums

Yes, the update I promised earlier in the week is now live. BeerRiot’s Forums are now open for discussion.

I know what some of you are thinking. “Forums?! Every site under the sun has forums. What did you waste weeks on forums for?” Clearly, if there was an ounce of sense in my head, I would have grabbed the nearest PhpBB implementation, tossed it up, and been done with it.

Well, I agree.

Except that I just couldn’t bear having such a disconnected, tacked on hunk of lameness. Even assuming that people wouldn’t mind the pain in the neck of having a second logon for a forum system, what I really wanted was a system that could really relate to the rest of the content on the site.

For example, I expect people to want to talk about a group (or several) of beers. Maybe someone will have a question about how two styles relate (porter and stout, hefeweizen and wheat, …), or they will have just returned from an event with an interesting selection. I think they should be able to easily set up a discussion about exactly the set of beers they want. So, since we were already doing this to some extent with tags, I have made it a key feature of discussion topics that they should be able to have tags associated with them.

I also expect people to want to get the word out about upcoming beer events. They’ll want to tell people where, and when, but then also discuss how it went afterward. So, in the events forum, all topics are allowed to have dates and locations associated with them.

As such, I went on my merry way developing. An opportunity to sling more Erlang code – how could I resist? πŸ˜‰

As if that weren’t bad enough, there was the realization late in the project that the new forum system was so much better than the beer comment system that there was no way I could leave the elder in place. So, out came the old, and in went the new. And hey – I always wanted to let people comment directly on breweries, why not add that in too?

If you’ve been anywhere near the software industry (or, in fact, I suspect any industry), you recognize now the project spiral. “Just one more thing, then it will be ready.” That’s how it went for the first couple of weeks. Luckily I recognized the spiral at that point too, and cut off some of the broader plans to get this pushed out (don’t worry – they’re still on the agenda, just on a different deadline).

Believe it or not, I believe I was lucky enough to be able to pick joints at which to truncate plans, that after this big, bulky update I should be able to roll out some nice, smaller updates fairly quickly and smoothly. The next news item shouldn’t be three weeks away. πŸ˜‰

So that’s that. In case you’re wondering, no, I still don’t regret choosing Erlang/ErlyWeb for this project. I didn’t run up against anything in this development that this system was incapable of handling. As mentioned above, I likely would have been delving deep into the guts of any forum system I chose, so development time would have been just as long. Getting to do it in a language that doesn’t annoy me [yet] was a real treat.

Despite reports to the contrary…

…I’m still alive and plugging away at BeerRiot code. I thought you all might just like to hear that despite the fact that I haven’t made a post here in a while, or updated the news section on the site, development is far from dead. There are things in the works, and I hope they will be ready soon.

But, I’m running into the oldest code-project slow-down in the book.[1] New code is making me rethink old code. Especially since I was much more of an Erlang amateur at the start of this project, my old code often looks ugly now. So, since my new code is doing very similar things to some of the oldest code here, I’m reworking the old stuff – mainly to avoid duplication, of course, but also because I understand the domain better now.

Unfortunately for you, the user, I’m still having quite a fun time slinging Erlang around, so it’s hard for me to just say, “Enough – post it!” But, I think I’ve defined the final goals, and the web of changes is starting to contract. The updates should happen soon (probably within a week), and then there will be lots of new toys to play with. πŸ™‚

[1] Okay, so actually, there are older slowdowns in the book, but I ran into them too (that is, real life has demanded extra attention recently). But I think there’s a lull in them for a while, so things should progess faster now.

Why YOU Should Drink Green

Wait! Before you skip this post thinking that I’m just another “tree hugger” ranting about saving the planet, I want to tell you that I’m going to divide this post into two parts. The first part will be reasons you should drink green that only affect your enjoyment of the beer. Only the second part will be about why drinking in this manner also saves the planet. I’ll let you know before the switch.

Okay, well let’s get on with it!

First of all, there are several things you should be doing to ensure that you’re drinking green. In no particular order, here are my top several:

  • Drink from a glass.
  • Drink local beer.
  • Drink seasonal beer.
  • Drink ales.
  • Drink barley.
  • Enjoy cellar temperature.
  • Love yeast.

Some of those are going to need explaining. So, here are the reasons for each of them, in how they relate your your beer enjoyment.

Drink from a glass. If you’re drinking from a bottle, you’re severly limiting your ability to taste the beer. A large portion of a human’s taste sensation comes from smell. A glass allows your nose to get right down in the aroma.

Drink local beer. For all of its exploits, all around the world, beer is, at some level, a fragile, tempermental beverage. It needs to be stored in a dark place, at a proper temperature. Even then, it has a maximum shelf life of only a few months. Drinking locally means that you have the best chance of enjoying that beer before it has been subjected to terrible storage practices.

Drink seasonal beer. Same as above, beer has a maximal shelf life, and should be drunk as soon as it’s ready. Find out what’s in season and drink it in its prime.

Drink ales. The world of ales is vast. Pale, IPA, Brown, Strong, Stout, Porter, Wheat, Red – and that’s not even making a dent. If you’re looking for a particular flavor, there is an ale to match it.

Drink barley. If you’re a typical American, you get your daily fill of corn without even thinking about it. Demand that your beer supply you with something else. Barley has a complex flavor all its own, and nutrients to match. Seek the different roasts, and never be bored.

Enjoy cellar temperature. Ice-cold serving does one thing: numbs your taste buds. You’re drinking a fine beverage – why would you want to avoid its taste? Store and enjoy your beer at cellar temperature – you’ll find more flavor that way.

Love yeast. Yeast is a very simple organism that plays a very large role in beer’s flavor. Some beers (include real ale, unfiltered wheats, and bottle-fermented varieties) still have yeast (alive and/or dead) in the beer while you drink it. This adds yet another flavor for your tongue to ponder. Yeast is also a great source of vitamin B – so it’s good for more than just your tongue.

Alright, this is the point where I go all tree-hugger on you. Hopefully I’ve caught enough of your interest with the points above that you’d like to know why these things are important for more than just taste. If so, read on.

Drink from a glass. If you’re drinking from a glass, you most likely had your beer poured from a keg. That means no extra energy was wasted on making a bottle, cleaning a bottle, or transporting a bottle. Just make sure it’s a reusable glass.

Drink local beer. If your beer is made locally, much less energy has been used in getting it to you.

Drink seasonal beer. It takes extra energy to provide conditions in which to brew unseasonal beer out of season. Embrace the cycle.

Drink ales. Lagers must ferment (and be stored) at much lower temperatures than ales. If you know someone that still makes lagers by burying casks in caves, covering them with ice harvested from a lake in the winter, then good for you, and drink up. However, most lagers are brewed by refrigerating large warehouses, and delivered in refrigerated trucks.

Drink barley. Americans are practically made of corn. Barley is an excellent source of nutrition, and encouraging its growth means that our farms have other profitable crops to fall back on when weather ruins corn crops. It’s unhealthy for the planet to run farming monocultures.

Enjoy cellar temperature. Even if you’re not drinking a lager, if your ale is served ice-cold, it’s being refrigerated in a way that is completely unnecessary. Turn the thermostate up a few degrees, and save some watts.

Love yeast. Naturally-fermented beer requires no extra piping of CO2, no extra pump pressure to force beer through a filter, and no extra cooling. And, you get smaller bubbles (which make for thicker head) without bothering with a Guinness-style nitrogen “widget”.

So there you have it. Drinking green – good for both you and the Earth. If you’d like to read more about the benefits of drinking beer responsibly, I recommend Christopher Mark O’Brien’s Fermenting Revolution.


P.S. This post is part of Blog Action Day. Yes, I agree that actions speak louder than words, but I already act on the words I wrote above, so I figured adding the words couldn’t hurt.

P.P.S. I know it’s been a while since I posted here, and this post isn’t likely to be on the topic many of you were hoping. But, I assure you that there is BeerRiot development going on. I’ll be posting about it soon.