Tuesday, December 29, 2009

My Most Memorable Mushroom Hunt


I had to turn back. The already-overgrown remnant of a road I had been climbing was becoming more impassable and I was getting this sketchy feeling deep in my bones. I was already nervous. Maybe some dealer/grower was going to emerge from the side woods, shotgun in hand, demanding to know what the hell I was doing on his land. So I started walking back down when I saw one - Dr. Snow had showed me a similar pine tree only hours ago, and told me that when hunting Matsutake, what you're really hunting is this tree. I lifted one of the green, low hanging branches up and there they were - three gorgeous, white-cinnamon mushrooms in a bulge of dirt and pine needles, about two feet from the trunk. My heart was racing. No way. Is this why I had come up here in the first place?! I pulled one of the white giants to my nose - it's unmistakable.

I love hunting mushrooms, and I love the forest. I became interested in mushrooms for the same reason any curious college kid might. The dream of finding a raw, natural magic led me and my willing compadres on too many four am drives out east of Austin. We'd jump short fences off remote country roads and scamper around in the dew, staring into piles of cow manure as the sun came up. After around twenty minutes we'd start yawning with boredom and fatigue, and that was that. I never did find the famed psilocybin cubensis of Texas.

Then I got into cooking. Cooks are like car-loving gearheads when it comes to ingredients. A cook who doesn't want to taste everything the world has to offer is merely a preparer of food. When I made my first wild mushroom dish, chicken with black trumpet mushrooms in veloute sauce, I jumped into the game. I started buying all sorts of dried mushrooms, and fortunately this was about the time that bulk bins started appearing in Texas grocery stores. My selections included porcini, black trumpets, and morels. I remember the time I got ahold of a fresh, black truffle while working in Lupin's kitchen. The chef was too busy doing blow to notice one little missing nugget, so when I got home that night I made up some soft-scrambled eggs and shaved the little gem on top. I was totally underwhelmed. I had come to love the deep, rich, dark earthy flavor of wild mushrooms, and truffles are something else entirely.

Since we moved to California three years ago, I've been making frequent pit-stops down at the Ferry Building store to check on what's in season. I've purchased rare blue chantrelles, queen boletes, perfect morels, and many more thanks to Far West Fungi and Ian. Angela and I have even rented zipcars a time or two to drive out of town for some "hiking" in the forest. Honestly though, on some of our hikes I tend to become a single-minded human radar, scouring the ground for shrooms, and I'm lucky and grateful that Angela is tolerant, supportive, and now also a converted fungiphile.

After meeting local legend Eric Schramm during our last visit, I decided to call him before this trip to see if I might get some info about what the mushroom forecast was, or maybe see about finding a guide or something. He very kindly called me back, and said he could only talk for 30 seconds because things were "fucking crazy up here", but managed to get me a phone number for Dr. Ryane Snow, who we'd read about. I called him up and voila, he had a slot open and we were set for a after-breakfast trip for 10am on Dec. 27th.

Not only did I meet and get to walk with this living legend of American mushrooming, but Dr. Snow is a cool, humble, honest, and brazen hero. He exudes the kind of confidence that comes from knowledgable self-reliability - and he is excited and willing to share what he's discovered from information on medicinal plants, seaweed, trees, botany, to right-brain expansion and thinking visually. We hiked for about three and a half hours in gorgeous, lush, public forestland, picking loads of hedgehogs, candy caps, yellowfoot chantrelles, pig's ears, and a few others. Dr. Snow told me all their names in Latin, helped me learn how to distinguish one from another, and shared my excitement when we came into a particularly abundant patch. We even sampled a russula that was spicy. It would not no exagerration to say that I was completely in HOG HEAVEN =)

We searched low and low for some end-of-the-season matsutakes but alas, had no luck. I had mentioned before our walk that I'd never eaten a matsutake but would like to, and Dr. Snow assured me that they were delicious and special (he affectionately calls them "Matsies"). Lucky for me, Snow was kind and generous enough to give me one to take home from his personal stash, so that I might experience this culinary oddity and magnificence. When he dropped me off at the Stanford Inn, I was grinning from ear to ear.

The Stanford Inn serves an all vegetarian menu, but that does not include lunch - if it had, I would have sat down to eat in bliss. I knew Angela wouldn't be there to pick me up for at least two hours. At first I just wandered around the grounds to acquiesce my hunger - the place is amazing, with lush gardens, and beautiful buildings. But I am addicted - even Dr. Snow pointed this out to me on our walk in case I didn't know already - and within 30 minutes I was stalking the nearby hillside, but still within the cellphone coverage provided by the Stanford, in case Angela called. Initially I came across a lot of russulas and amanitas, but after twenty minutes I'd found two lovely, golden chantrelles. After an hour I had a few more chantrelles, plus a couple of huge hedgehogs. My ankles were starting to become loose and weak from clinging to the steep hillside. At the hour and a half mark I came across that pine tree and those three matsutakes on my own. I was truly fortunate to have that one in my bag from Dr. Snow, to aid in my identification, but the smell of a matsutake is truly telltale, and now I will never forget it.


Wednesday, November 11, 2009

Security Tests on Browserscope

[The text below is reprinted from stevesouders.org, since it's far better than what I would've written anyway. -Lindsey ;]

Today, the first new test suite for Browserscope was launched: Security.

Browserscope is an open source project for measuring browser capabilities. It’s a resource for users and developers to see which features are or are not supported by any particular browser. All of the data is crowdsourced, making the results more immediate, diverse, and representative. Browserscope launched in September (see my (Steve's) blog post) with tests for network performanceCSS selectorsrich text edit controls, and Acid3.

The new security tests in Browserscope were developed by Adam Barth from UC Berkeley, and Collin Jackson and Mustafa Acer from Carnegie Mellon University. It’s exciting to have these experts become Browserscope contributors. The tests cover such areas as postMessage APIJSON.parse APIhttpOnly cookie attribute, and cross-origin capability leaks. See the Security about page to read about all the tests.

This is the point at which you can contribute. We don’t want your money - all we want is a little bit of your time to run the tests. Just click on the link and sit back. All that’s needed is a web client that supports JavaScript. We especially want people to connect using their mobile devices. If you have suggestions about the tests, contact us or submit a bug.

So far we’ve collected over 30,000 test results from 580 different browsers. Want to see how your browser compares? Just click on this button to add your browser’s results to Browserscope.




Saturday, October 24, 2009

If you don't like omakase, I don't like you

Or at least, I'll have a really hard time taking your opinions about "good food" seriously. Omakase, or chef's choice, is often the best way to branch out and try new things that you never knew you'd like (or possibly dislike). Last night, me and 9 other folks visited San Francisco's Jai Yun Restaurant for what was one of the greatest Chinese food feasts of my life. If you haven't been and you care about Chinese food and you're nearby, get a reservation ASAP. This morning I started thinking more about this style of dining/eating.

You don't have to go out to a sushi restaurant to experience omakase, though that is context where this word comes from. But the idea that you'd go out to eat, pay some amount of money, and have limited say in what you get is what's important. As I'm not allergic to any foods, it's certainly easier to be voiceless, but again, that's just a detail and has nothing to do with the spirit of omakase.

Do you loathe "prix fixe" meals? Don't take me out to eat. I'll admit that I'm not always in the mood for this, but more often than not, I'm game. It doesn't have to be fancy. It could be some authentic Americana chips and dip at your place, but the point is that it's exposure to something cherished.

When I was in Korea, probably one of the greatest meals I ate was this crazy package-o-ramen soup mixed with spam and hot dogs and spicy as hell. If you told me about the ingredients weeks in advance and tried to get me excited you'd have a hard time, but in the moment, my friend Kihyun knew I'd be up for it, and I'm so grateful he let me experience this meal. He could've taken me out, trying to impress me or something, to eat more crazy sea urchin sashimi, but variety is indeed the spice of life. And Koreans love spicy, oh brother. This soup dish came about as South Koreans were trading with American soldiers during the Korean war, and has become a national pasttime these days - everyone at the restaurant  was eating this spicy, hearty soup for lunch.

So if you haven't done it in awhile, tell the chef at one of your favorite places to surprise you - let him/her make something special for you that they love to cook. Don't think twice and don't waste a bite.

Saturday, September 26, 2009

Browserscope & Chrome Frame


I imagine many front end developers out there like me are currently pretty thrilled about the announcement of Google Chrome Frame this week. I've always been an admirer of Alex Russell's writing and work. To be fair though, I was once also a very excited Flash developer who thought I'd end up writing code for a single engine/consumer. I've felt that burn, but I'm still really just a kid at heart - so I'm psyched.

Chrome Frame presented a pretty interesting challenge for Browserscope. I wish we'd solved it fully before this morning. The problem is in detecting the user agent. When it first came out, I thought Browserscope wouldn't need any quick changes due to Chrome Frame, because we wouldn't be serving the <meta http-equiv="X-UA-Compatible" content="chrome=1"> header. Fortunately Steve read about the "cf:" way to run Chrome Frame the next morning - though unfortunately, that meant we had a problem.

Browserscope originally did its user agent classification based on the HTTP_USER_AGENT header sent from the browser when you share your test results. Chrome Frame adds a "chromeframe" string within the IE user agent string, so at first we thought we could detect Chrome Frame based on the presence of that string. But correctly, IE has the "chromeframe" string whether Chrome Frame has been invoked on the page or not (it's still an installed plug-in). And we wanted to be able to distinguish the IE/Chrome Frame results - which someone could submit by going to cf:http://www.browserscope.org/.


So then we thought we could just detect whether the client side render engine was Webkit, which is doable - and it turns out that if you ask the browser for window.navigator.userAgent you get a typical Chrome user agent string (type cf:about:version into IE with Chrome Frame installed). It's kind of a bummer that at the client level, you cannot tell that you're in Chrome Frame versus Chrome proper, but the Chrome Frame team may tweak the Chrome Frame user agent string if enough people also encounter this as an issue. Functionally, it should be a lot more like Chrome proper; Browserscope itself should be able to report if, and if/when that isn't the case.

While we'd anticipated new user agents on Browserscope, we hadn't imagined a hybrid sort of User Agent. We had to make some changes under the hood to support this in the back end (thanks slamm!). Now you should be able to go to Browserscope and compare your test results for IE and Chrome Frame (if you have it installed). Parsing-wise, we're grouping Chrome Frame along with the browser family(IE at this point) and major version bit(6|7|8) in the UI. We'd love your feedback on that decision.

Now, not only can you run the tests on Browserscope in Chrome Frame, but once you do, you'll then experience Browserscope itself in Webkit (check out all the rounded corners and text-shadows). And, how awesome is Webkit?! Of course, you can always toggle the checkbox on the homepage to switch back and forth to IE proper.

This experience reminded us on the Browserscope team how crucial it is to parse user agent "correctly" - and in this case that requires a combination of client and server information! - so I'll make a plea for folks to check out and add comments to a design doc for a user agent string parsing project we'd love to see take shape. Want to build it?

Sunday, September 13, 2009

Announcing Browserscope

I'm excited today to announce the release of Browserscope at www.browserscope.org.


Browserscope is an open-source project for profiling web browsers and storing and aggregating crowd-sourced data about browser performance.


The goals are to foster innovation by tracking browser functionality and to be a resource for web developers.


Browserscope is based on Steve Souders' UA Profiler, and his original tests have been preserved here as the Network test category. Other test categories include Ian Hickson's Acid3 test (ported by Jacob Moon into Browserscope), Annie Sullivan's Rich Text Edit Mode tests, and John Resig's Selectors API Test Suite (ported by Lindsey Simon into Browserscope).


The Advantages of Crowdsourcing
The ability for users to contribute results is the key for Browserscope's longevity, accuracy, and currency.
  • No dedicated test resources are required; enabling the project to run in perpetuity
  • Tests are run under a wide variety of real world test conditions
  • Aggregating results reduces selection bias
  • New browsers show up immediately due to developer testing
 And this is where you come in! Click the button below to run your browser through the tests on Browserscope.


Roadmap
Below are some ideas culled from the project issue tracker on Google Code. Do you have some ideas? Add them, or feel free to checkout and work on the code. We'd love to get your patches (as directory diffs) and review those for inclusion in Browserscope!
  • Visualize test result trends over time
  • Wall of fame, up-and-comers, Billboard top 50
  • More test categories - cookies, security, reflow
  • More contributors
  • Tagged/personalized test results
  • Normalize time-based results across platforms
  • User agent parsing library

Links


Thanks
I want to extend my sincere and deep gratitude to everyone who's offered feedback, worked on the codebase, or otherwise helped Browserscope along. Specifically I want to thank:
Steve Souders: you've been a great mentor to work with, and your ability to think BIG and beyond is something I hope continues to rub off on us all a little ;) 
Steve Lamm: I've never worked with anyone who writes code that is of such high quality and readability. Browserscope's backend would not be the same without you.
Annie Sullivan: You're quick, wise, and totally fun to work with - I also really hope that Rich Text Edit  mode development will get easier thanks to your dedication.
John Skidgel: Design master, cohort, and all-around tolerater - you love problems, you has solutions.
Brett Slatkin and the App Engine team: Your insight into the overall system design was critical to our being able to deploy this on App Engine, and the Task Queue API rocks.
Jacob Moon: We sure got lucky that you provided the first outside-the-project developer experience! Thanks for bringing the Acid3 tests (and others) into Browserscope and for showing us how doable it is to port new tests into the system.
Christian Stockwell and the IE team: Your feedback was essential to uncovering issues regarding selection bias, hopefully the reflow tests will make their appearance again soon once we've done some more to address this issue.
Mike Belshe and the Chrome team: Your advice and feedback re: benchmarks versus compatibility testing was crucial. Yall run the tightest ship on the planet and it shows, i <3 Chrome.
David Baron, Dion Almaer, Ben Galbraith, John Resig and the Mozilla team: Your ideas and suggestions are present in many parts of the codebase - and additionally I couldn't have made the site look nearly as decent without using Firefox.
Robert Bowdidge: Thanks for inspiring me to work on this.
Lastly a big thanks to Google for giving me 20% time to work on this project for the last year.

Tuesday, June 23, 2009

Go With the Reflow

Posted my slides to SlideShare: http://www.slideshare.net/lsimon/go-with-the-reflow

Wednesday, June 17, 2009

Speaking at Velocity about reflow next week


Velocity 2009



Hey - if you want to talk reflow and render time, come to Velocity next week. I'll be giving a 15 minute presentation on the subject. See ya there.

Friday, May 8, 2009

Clearing floats without overflow hidden

Clearing floats is a topic near and dear to web developers fighting with CSS to produce grid layouts. There are a number of methods to do this, but not all work well in all situations. I wanted to mention one I'm using at work at Google that's gotten pretty good mileage so far in ways that others have not.

Our grid system is very similar to Yahoo's - it's designed to nest two units inside of a container and then further nesting takes place in one of the two units. Our system can scale to infinite nesting in browsers that support first-child selectors, and for those that don't we bake a nasty mix of descendent selectors to achieve a baseline of 4 levels of nesting (which seems pretty sufficient for most projects).

A fixed layout of 180-px on the left and fluid on the right looks like this in HTML:

<div class="g-section g-tpl-180">
<div class="g-unit g-first">
<div class="box-1">1</div>
</div>
<div class="g-unit">
<div class="box-2">2</div>
</div>
</div>


This grid/horizontal column layout is done in CSS by making the g-first element float:left and then have a fixed width:180px then the second g-unit float:none and margin-left:180px. So, since something is floating here, we want our g-section to contain it.

For containing floats, here's what I've found:
* Clearfix is nice, but doesn't work when nesting sections within units, so for our framework it is useless.
* Faux Absolute Positioning is pretty cool, but doesn't mix well on pages that don't adopt this approach whole hog (i.e. everything has to be inside of a div with class="line". So that's out.
* overflow:hidden - Overflow hidden for a CSS framework is like using crack - it's solves the immediate problem nicely, but as things build up and edge cases kick in, it's unsustainable and gross. Hiding parts of the UI and not providing users with a scroll bar is just plain wrong, even if it makes your design "look" good still. All sorts of things in Web Apps will get you into this situation - dynamic-width/column data tables, form input elements, images, etc.. Cutting them off and asking your user to get a bigger screen is wretched.

I'm going to paste the code and comments I'm currently using for g-section below. Hopefully it will be of use to someone stumbling across this. I have unit tests that test against float-drops and sizing of the template is all the basic cases as well as cases where the sections are nested up to 4 in depth as well as nested inside of floats. This last case is one where I'm noticing some issues related to how width of the outer float container gets calculated - but that's a subject of a whole other post.

Update May 10: So it seems that the fix for a pure float-left container is to set width to be auto for the outer container and then display: inline for nested g-section's. If that makes sense then you'll be happy to hear it solves the problem of width aggregation for the inline-blocks!

I welcome your suggestions - thanks!


/**
* g-section fundamentally has to clear floats. There are many ways to do this.
* This technique is nice because it doesn't rely on overflow: hidden, which
* has the potential to hide your content in situations where a fixed size
* node takes up too much space (like a big table, or a text input or image.
* Works in Webkit, IE8, and FF3.
*/
.g-section {
width: 100%;
vertical-align: top;
display: inline-block;
}

/**
* IE7-only hack. Nicely IE7 will clear floats with just block display
* and hasLayout.
*/
*:first-child+html .g-section {
display: block;
}

/**
* IE6 cannot hang with overflow: visible. If we use the IE7 display block
* trick in IE6 we get severe float drop in nested grids.
*/
* html .g-section {
overflow: hidden;
}

/* FF2 can't actually hang with overflow: visible. */
@-moz-document url-prefix() {
.g-section {
overflow: hidden;
}
}

/**
* FF3 now needs to be reset after the previous block which affects it as well.
* We target the tt element in this hack because no one uses it.
*/
@-moz-document url-prefix() {
.g-section,tt:default {
overflow: visible;
}
}

/* Forces "hasLayout" fixing a gamut of bugs in <= IE7. */
.g-section,
.g-unit {
zoom: 1;
}