i’m with coco
2010 Jan 13 3:13As seen on woot today. There’s nothing more to say!
As seen on woot today. There’s nothing more to say!
it’s no secret that i’m a big fan of plurk, despite my recent absence (social media exhaustion set in). i am especially happy because my plurkbuddy alvin woon moved back east to help promote the service, where it became the #1 microblogging service in China (prior to being firewalled).
not just because i want to see the little guy win, but also because it is just appalling that this occured:
Microsoft China stole Plurk’s UI and code and is pretending it’s their own service.
i could see a 2 bit startup doing this, or some non-multinational heavyweight that figured they could get away with it because they pay their lawyers more than the little guy. but this is just bald-faced theft.
i worked at a company many years ago who had their code stolen, and spent many years in the courts shutting down the competitor started by ex-employees who stole the code. from looking at the code involved, it was obvious it was a copy; in many places, error messages contained the same misspellings!
at the time, the ceo swore that he wouldn’t stop until he won back all of the business he lost to “the thieves,” and sued for damages for every cent lost. realizing they had a losing battle, the founders pled no contest, then the purchasing company settled out of court for about us$285mil all told. sadly, many of the customers they lost probably still use the purchasing company’s software instead; i think that company came out on top in the marketplace (for various other reasons). so my employer was vindicated, but didn’t manage to win back all of the business lost.
Plurk doesn’t have the resources to complete the lawsuit, but i hope that they find some other way to shut this down. it’s a different world now, 10-15 years later; maybe social media itself can stop this assault on the innovator. hopefully it will be before they, too, lose their loyal and active client base to a competitor.
Testing this Posterous thing. Trying to decide if I like it or not. *waves*
picked up an Elka Rhapsody 610 61-key string synthesizer for a bit more than I would have liked on CL over the weekend. seeing the unit in person, it became clear that most of the damage was physical, and that it’d probably been some teenager’s keyboard or a badly treated gigging unit. half of the slider caps were missing (with the stem sheared off at the control panel), the piano output didn’t work, the sliders worked backwards (bass sliders controlling the treble and vice versa), 60Hz hum, etc.
got the unit on the new basement workbench as an inaugural challenge. found the schematic online and buzzed things out. problems found:
it felt good to get this thing repaired in just a couple of hours, and with only about $1 CAD in parts.
plans before i decide if i’m reselling the device:
if you readers out there particularly want to buy a rhapsody 610 for that jarre-TD-vangelis sound, comment here with your real email address and i’ll be in touch. have yet to decide if i want to sell; it sure sounds nice through a phaser pedal or a spring reverb.
after japan, i had a craving for north american food. so, with doozer’s help, i made chicken pot pie very similar to this recipe. differences: instead of cream, an oil/flour roux to thicken. no pearl onions on hand. lesueur canned petits pois instead of frozen. seasoning with dried cilantro and a dash of paprika instead of parsley. and i used her pie crust 102 recipe – no vodka, just butter, all by hand, took all of 5 minutes to prep, honest injun.
the results were outstanding, if a bit high on the fat scale. slightly over half an 8″ pie later, i’m stuffed…the rest will be a great lunch tomorrow. also, the little pastry biscuit was a delicious appetizer. suddenly, puff pastry seems achievable! oyster patties are in my future, i think.
been a while since i got time to post something. after a sudden and draining trip to Boston, i decided to take the weekend entirely for myself. 75% of it was spent sleeping. the rest was cooking and eating.
here’s the recipe i worked up for pão de queijo, a delicious Brazilian cheese bread.
Ingredients
Directions
Preheat oven to 350°F / 180°C.
Mix the milk, oil and salt in a pan. Heat the mixture until the milk scalds and starts to boil over. Remove from heat immediately and stir briefly. Place the flour in a medium size bowl and pour the milk mixture over it, scalding the flour. Stir until incorporated and no large chunks remain, about 3-5 minutes by hand or 60-90 seconds by electric mixer with dough hook.
Allow to rest until total time mixing & resting is no less than 5 minutes. Dough should be very chunky and crumbly at this point. Mix in the beaten egg until the mixture is consistent but still quite thick. Then, gently stir in the grated cheese. Dough should be sticky and thicker than cookie or biscuit batter, but workable.
Prep a cookie sheet with parchment paper. Dip fingers in a bit of extra oil to prevent sticking and form small balls of batter approx. 3-5cm in diameter and place on cookie sheet. Bake until light golden brown, between 20 and 35 minutes.
Yield 20 pão.
the cassava flour (aka yucca flour, aka “tapioca” flour but not what we know as “tapioca” in western culture) forms a special gluten that is safe for those with gluten sensitivities. the gluten has a particularly cheesy texture, which adds to the actual cheese in the recipe. if available, use 2 parts polvilho doce (regular cassava flour) to 1 part polivlho azedo (fermented or “sour” cassava flour). as far as i have been able to determine, it is not possible to substitute other flour types. find a Brazilian grocer, or get “tapioca flour” from an Asian grocer (it’ll usually be the right product).
classically the recipe is made with oil as a fat source. some variants swap in butter for a “richer” taste. i’d avoid that. you could substitute some olive oil instead of the vegetable oil, but it might not hold up during baking.
the selection of cheese is critical. traditionally this would be made with Minas cheeses from the Minas Gerais part of Brazil. the cheese recipes there were invented locally, but brought over and adapted from recipes from Italy in the late 19th and early 20th century. when not available, freshly grated Parmesan Reggiano is a good substitute. you could add a bit of a higher moisture content cheese to assist with consistency, such as a freshly grated Pecorino Romano, cotija or mozzarella. personally i find an all-mozzarella version strays too much from the original texture and flavour but it’ll do in a pinch. i have seen variants on the ‘net where people insert chunks of cheese in the middle. i tend to prefer the more consistent dough; the magic of this bread is that the dough itself has the cheesy flavour and texture brought about by the flour itself. if you want cheese-filled bread, try making bolinhas instead (recipe to come).
i seem to have eaten them all without taking a picture! they were that good. that said they looked a whole lot like this:

picture of pão de queijo
inspiration for the recipe came from this amazing article, in which the function of each ingredient in the recipe is analyzed. their conclusions are as follows:

graph of pão de queijo batter viscosity
i encourage you all to research this and post more experiments, especially with different proportions and ingredients!
so a couple of weeks ago i presented my third academic publication, this one titled “persisting chat for communities of practice.”
in layman’s terms, it’s a new logging system for online group chat (irc, jabber, etc.) with special integrations into non-synchronous systems such as web forums (academically often called asynchronous learning networks), blogs, etc. the goal is to make chat less transient and throwaway, to promote it to a first class citizen within the wide variety of mechanisms that can be used to help communities. it’s especially designed for communities of practise as described by lave and wenger out at xerox parc way back in the day. go read the linked article, it’s not half bad for wikipedia.the system will be released under an open source license later this year. if you’d like to get involved, comment here using your real email address and i’ll get in touch.
Good buddy neillathotep has been bugging me to post about my okonomiyaki escapades – so here you go.
The recipe is really simple. Shred cabbage, green onion, garlic scapes (if you have them!), red ginger (you can buy this pre-shredded), shredded nori. Cut up a bunch of other foods you’d like in your okonomiyaki, such as bacon, mochi, pork, squid, etc. For today’s recipes I made one with bacon, and another with brie and asparagus. Mix up 2 parts flour to 1 part dashi — you can use buckwheat flour if you like, or a mix of white, whole wheat, sweet potato/potato, etc. You can use salted water if you don’t have dashi. Also get one egg per pancake.
In a bowl mix up the egg with the cabbage and a cup of the flour-water mixture. Heat up a griddle to medium hot. Oil with sesame or sunflower oil. Dump out the egg-cabbage-batter and spread out to a pancake. Top with your special toppings. Use a spatula to press down on the pancake until the bottom is well cooked. Flip the pancake over and repeat the pressing routine until the pancake looks dry in the center when viewed edge-on.
Remove from the grill. Top with shredded nori, red ginger, kewpie mayo (if you can find it!), katsuoboshi (dried bonito flakes – ditto) and okonomiyaki sauce (decent collection of recipes here). Cut into 4 pieces and serve.
I wanted to post a public thanks to the great minds over in freenode #couchdb, including Paul Davis and Jan Lehnardt for helping me learn more about CouchDB, and helping me investigate the performance issue I posted about last time. In fact, they both posted on planet couchdb with some thoughts about benchmarking in general.
I wanted to share my reason for benchmarking CouchDB in the manner I did. The fact is that it was entirely personal in nature, as in trying to make my own dataset and code as fast as possible. I’m not trying to generate pretty graphs for my management, for publication or for personal gain. This work comes out of having to load and reload fairly large datasets from scratch on a regular basis as a part of my research methodology. I need a large dataset to get meaningful results out of the rest of my system, and I was not content to wait for an hour or two each time my system bulk loaded the content.
So the suggestions provided – not using random UUIDs to help CouchDB balance the b+-tree, correctly using bulk insert, and redoing my code to use the official couchdb interface (instead of a hacked-up version using raw PUTs and POSTs) helped a lot.
It turned out that the spike that I was seeing (see last post) disappeared when I randomized the order of incrementing that variable, so much so that 3 randomized runs show almost no peaks. However, when I “scroll” through that variable (increasing the batch size) I still see the peak around a batch size of 3k.
Trying the software on another platform (AMD x64-3500 Debian lenny with a 3ware hardware RAID array, as opposed to a 4-core Mac Pro with only a single local disk) revealed that the peak shifted to a different value, a much higher one.
Lesson? Always benchmark your own application against your own data, and tweak until you’re satisfied. Or, in the words immortalized at Soundtracks Recording Studio, New Trier High School, “Jiggle the thingy until it clicks.”
I suspect suspected that Jan’s article ranting about benchmarking was at least in part stimulated by my experiences as shared over IRC. (I was wrong – see the comments.) They must have seemed somewhat inscrutable — why would someone care so much about something most database-backed applications will do rarely, as compared to reads, queries and updates? My application right now has a very particular set of criteria for performance (repeatable high performance bulk load) that is not likely anyone’s standard use case but my own. Nor is it going to be a worthwhile effort on the developers’ part to spend a bundle of effort optimizing this particular scenario.
That said, Jan also is calling for people to start compiling profiling suites that “…simulate different usage patterns of their system.” With this research, I don’t have the weight of a corporation who is willing to agree on “…a set of benchmarks that objectively measure performance for easy comparison,” but I can at least contribute my use case for use by others. Paul Davis’ benchmark script looks quite a bit like what I’m doing, except the number of documents is larger by a factor of 100 (~2mil here) and the per-document size is smaller by a factor of 25 (100-200 bytes here). Knowing the time it takes to insert and to run a basic map/reduce function on fairly similar data is a great place to start thinking about performance considerations in my application.
Oh, and knowing the new code on the coming branches will get me a performance increase of at least 2x with no effort on my part is the icing on the cake.
Thdavisp. Thjan.