Sunday, February 21, 2010
Some Recent Coffee Experiences
After the birth of my 2nd child, my wife thankfully encouraged me to go grab a shot at Barismo in Arlington Center. Lord knows with a newborn you need all the uppers you can get. Barismo was totally mind-blowing. The best shot of espresso I have ever had. On the day that I was there they were serving Koke. I went back the day after and had a 50/50 Doppelganger. Both were excellent, fully of crema. The Doppelganger had a downright raspberry flavor to it that I've never experienced with espresso. The Doppelganger was the first shot of espresso I've ever had that required absolutely no sugar. I bought some of the Koke and when I had it at home with my Mazzer Mini and Pavoni, it was delightful as well. Barismo is an experience unto itself, and it doesn't hide the fact that if you want really amazing espresso, coffee, or tea, you have to wait for it. Each shot requires some patience, but it's totally worth it. If the line is out the door, come back some other time. But if you hit the place in the middle of a slow weekday, you're in for a treat.
My mother in law--a huge fan of coffee--arrived a few days later to help take care of our son and as a treat I took her to see George Howell's new-ish coffee operation in Ashland, MA. We didn't make an appointment and truth be told I wasn't sure if the place was going to be corporate HQ offices, a giant loading dock, or an actual cafe. We just sort of stumbled into the place, walked into the back room and met George and his lovely daughter. George was kind enough to take me, my mother in law, and my 2.5 year old daughter on a quick tour of the operation, showing us a bit of R&D, bean packaging, roasting, and tasting. It was awesome. And his daughter pulled me a shot that rivaled Barismo's. It's clear that George loves coffee and all of the details that go into a relatively high throughput (at least compared to Barismo) roasting operation. I was a kid when George first opened coffee connection and as a teenager I lamented the dropoff in quality when the Coffee Connection was dragged asunder by Charbucks. So I'm very excited to see George Howell back at it, delivering us from the evils of Starbucks' brand of super dark, burned, thin coffee. I usually buy George's beans from Whole Foods, but I notice that sometimes the beans aren't terribly fresh. Mail order from GHH is pretty speedy and the beans are always very fresh.
Update: Some great espresso beans from George Howell: Kaguimoini, Sorento, and Gingerbread. All are terrific. The Kaguimoini is very complex. The Sorento is more caramel-y and chocolaty.
My mother in law--a huge fan of coffee--arrived a few days later to help take care of our son and as a treat I took her to see George Howell's new-ish coffee operation in Ashland, MA. We didn't make an appointment and truth be told I wasn't sure if the place was going to be corporate HQ offices, a giant loading dock, or an actual cafe. We just sort of stumbled into the place, walked into the back room and met George and his lovely daughter. George was kind enough to take me, my mother in law, and my 2.5 year old daughter on a quick tour of the operation, showing us a bit of R&D, bean packaging, roasting, and tasting. It was awesome. And his daughter pulled me a shot that rivaled Barismo's. It's clear that George loves coffee and all of the details that go into a relatively high throughput (at least compared to Barismo) roasting operation. I was a kid when George first opened coffee connection and as a teenager I lamented the dropoff in quality when the Coffee Connection was dragged asunder by Charbucks. So I'm very excited to see George Howell back at it, delivering us from the evils of Starbucks' brand of super dark, burned, thin coffee. I usually buy George's beans from Whole Foods, but I notice that sometimes the beans aren't terribly fresh. Mail order from GHH is pretty speedy and the beans are always very fresh.
Update: Some great espresso beans from George Howell: Kaguimoini, Sorento, and Gingerbread. All are terrific. The Kaguimoini is very complex. The Sorento is more caramel-y and chocolaty.
Wednesday, February 3, 2010
Hibernate/JPA confuses "legacy" with "high throughput", "scalable", and "complex"
I like Hibernate/JPA for dead-simple inserts and update. I detest it for queries. I also detest how the Hibernate documentation totally misuses the term "legacy". When I hear the term "legacy", I think "old and dumb". But on planet Hibernate, "legacy" means "Any application which operates on a piddly amount of data and doesn't buy into our myopic, java-centric view of the cosmos in which a relational database is just a pain-in-the-ass file system whose performance and data integrity issues exist only to perpetuate the hiring of very expensive DBAs".
For example, Hibernate says it doesn't support trigger-driven sequence creation because that's a "legacy" kind of a thing. What if my database is accessed both by Scala, Ruby, Perl, and Java? I'd like to encode some core business rules directly in the database so I don't have to duplicate logic in different languages. I don't call that "legacy". I call it "reality".
Hibernate thinks that compound unique keys are indicative of a "legacy" database. There are perfectly good reasons--from a (gasp!) data modeling perspective--to use complex unique keys and dispense with primary keys. Having to introduce new artificial primary keys into all my tables to make life easier for the object layer is something I am now more or less required to do so as not to infuriate application developers. But there is a real cost to the data model: the data model is forced to violate DRY. The data model has to maintain two redundant definitions of uniqueness: one that is natural and one that is imposed by Hibernate. Hibernate claims that having a foreign key refer to a unique key of the associated table rather than the primary key is "complicated and confusing". This is bullshit.
Hibernate thinks that only "legacy" tables have lots of columns. In reality, it's often very useful to make really fat tables to accomodate what would otherwise be complex, possibly inefficient multi-table queries. I've made fat tables before and I'll make them again. It's not legacy, it's reality.
Hibernate thinks that everyone should have "fewer tables than classes", and then claims that storing some attributes in a secondary table (hello
My needs aren't legacy needs. These are the needs of reality.
For example, Hibernate says it doesn't support trigger-driven sequence creation because that's a "legacy" kind of a thing. What if my database is accessed both by Scala, Ruby, Perl, and Java? I'd like to encode some core business rules directly in the database so I don't have to duplicate logic in different languages. I don't call that "legacy". I call it "reality".
Hibernate thinks that compound unique keys are indicative of a "legacy" database. There are perfectly good reasons--from a (gasp!) data modeling perspective--to use complex unique keys and dispense with primary keys. Having to introduce new artificial primary keys into all my tables to make life easier for the object layer is something I am now more or less required to do so as not to infuriate application developers. But there is a real cost to the data model: the data model is forced to violate DRY. The data model has to maintain two redundant definitions of uniqueness: one that is natural and one that is imposed by Hibernate. Hibernate claims that having a foreign key refer to a unique key of the associated table rather than the primary key is "complicated and confusing". This is bullshit.
Hibernate thinks that only "legacy" tables have lots of columns. In reality, it's often very useful to make really fat tables to accomodate what would otherwise be complex, possibly inefficient multi-table queries. I've made fat tables before and I'll make them again. It's not legacy, it's reality.
Hibernate thinks that everyone should have "fewer tables than classes", and then claims that storing some attributes in a secondary table (hello
@Secondary annotation) is really only for...you guessed it..."legacy" databases. Hold the phone. What if I have some bit of data that is part of an object but needs database-level security? For example, if I have a patient table and I want to expose access to social security numbers, perhaps I'd like to put the social security numbers in a separate table, or in a separate schema, and have the database manage the security of this table slightly differently? What if I have some huge freakin' columns that map to a particular subclass of an object, but I'd like to keep them stored separately for query performance? What if these columns are extremely rarely used? I don't want to risk pulling them all into memory (which I can control by FetchType.EAGER). I want to manage the storage for these data differently. Maybe the data is so large that I need to partition the backing tables. Hibernate seems to be saying that these situations are for those stupid old "legacy" applications. Just let your object model define the data model! What could possibly go wrong? My needs aren't legacy needs. These are the needs of reality.
Subscribe to:
Posts (Atom)