"No one should watch sausage or software being made."
It works on so many levels. It's wrong on so many levels. I love it.
Wednesday, October 31, 2007
Another Profound Quote
I'm participating in a day-long online meeting via phone, and someone just came out with this gem:
It works on so many levels. It's wrong on so many levels. I love it.
It works on so many levels. It's wrong on so many levels. I love it.
PacMan is Loose on CodePlex!
PacMan - The SQL Server Integration Services Package Manager is a utility designed to permit batch operations on arbitrary sets of SSIS packages. Users can select a single package, a Visual Studio project or solution or a file system folder tree and then validate or update all selected packages in one operation.
And you can find it here: http://www.codeplex.com/pacman
PacMan is a utility that I developed primarily for my own use, and secondarily for use by members of my development team. Although I had always intended to share the PacMan utility with the SSIS community eventually, I kept pushing it back further and further since it wasn't "ready."
But my speaking schedule this month has convinced me that either it's never going to be ready, or else it's already ready. Maybe both. At various presentations this month in Stockholm, Sweden and here at home in Central New York I demonstrated PacMan to illustrate some of the things you can accomplish by using the .NET object model included with SSIS, and the response was an overwhelming "I want that!" from the seminar participants. I explained how this was a personal dev utility that wasn't really ready for prime time, and the interest didn't wane at all with that warning.
So here we are. I've done minimal cleanup, and the code isn't perfect (and there are very few comments, which is something that I would never allow to happen on a "real" project) but I could not find anything similar online, and I thought the best thing to do would be to share the code today instead of waiting to polish it before sharing it.
This is the first CodePlex project (or open source project in general) that I have started, so I honestly do not know how I am going to handle other project participants. I'll the first public alpha release is already available for download so everyone should be able to download the code to use (and tweak) on their own, but I don't currently know what I'll do when people want to contribute directly to the source code. I guess we'll find out when people ask.
And you can find it here: http://www.codeplex.com/pacman
PacMan is a utility that I developed primarily for my own use, and secondarily for use by members of my development team. Although I had always intended to share the PacMan utility with the SSIS community eventually, I kept pushing it back further and further since it wasn't "ready."
But my speaking schedule this month has convinced me that either it's never going to be ready, or else it's already ready. Maybe both. At various presentations this month in Stockholm, Sweden and here at home in Central New York I demonstrated PacMan to illustrate some of the things you can accomplish by using the .NET object model included with SSIS, and the response was an overwhelming "I want that!" from the seminar participants. I explained how this was a personal dev utility that wasn't really ready for prime time, and the interest didn't wane at all with that warning.
So here we are. I've done minimal cleanup, and the code isn't perfect (and there are very few comments, which is something that I would never allow to happen on a "real" project) but I could not find anything similar online, and I thought the best thing to do would be to share the code today instead of waiting to polish it before sharing it.
This is the first CodePlex project (or open source project in general) that I have started, so I honestly do not know how I am going to handle other project participants. I'll the first public alpha release is already available for download so everyone should be able to download the code to use (and tweak) on their own, but I don't currently know what I'll do when people want to contribute directly to the source code. I guess we'll find out when people ask.
Multi-Monitor Goodness
Do you use multiple monitors?
Do they have different resolutions?
Have you ever wanted to display different wallpaper images on each monitor, or to have the same image displayed appropriately (without cropping or stretching and the like) on both monitors?
Well, welcome to DisplayFusion (http://www.binaryfortress.com/displayfusion/)!
DisplayFusion is a free software utility that lets you quickly and easily manage multiple monitors. It does more than just give you control over the desktop wallpaper (although this is all I'm using it for today) - there's also a nice list of features related to managing window position across monitors with global hotkey support.
And did I mention it's free?
So if you answered yes to any of the questions above, you should download DisplayFusion and give it a try.
Do they have different resolutions?
Have you ever wanted to display different wallpaper images on each monitor, or to have the same image displayed appropriately (without cropping or stretching and the like) on both monitors?
Well, welcome to DisplayFusion (http://www.binaryfortress.com/displayfusion/)!
DisplayFusion is a free software utility that lets you quickly and easily manage multiple monitors. It does more than just give you control over the desktop wallpaper (although this is all I'm using it for today) - there's also a nice list of features related to managing window position across monitors with global hotkey support.
And did I mention it's free?
So if you answered yes to any of the questions above, you should download DisplayFusion and give it a try.
SSIS Myths - Call for Entries
I mentioned this to Greg Low during our SQL Down Under chat this morning, so I should probably mention it here in writing as well. I'm planning to start a series of "SSIS Myths" entries on this blog. What this will entail (based on what I see today, in any event) will be presenting a misconception about SSIS, and then digging into the details behind it and presenting the truth (or truths) behind the myth.
So although I have a few of these already in mind, I'd like to put out an open call for entries. If you have a myth in mind, if you've seen or heard statements about SSIS that you don't know if they're true, please let me know. Post a comment or send me an email[1] and I'll add it to my queue. Hopefully I'll have the first myth debunked by next week and will keep a steady stream of them coming your way in the weeks that follow, but in order to keep them coming I will need your help.
So let your voice be heard!
[1] Matthew MCT at Gmail dot calm - you can figure out what to do with it.
So although I have a few of these already in mind, I'd like to put out an open call for entries. If you have a myth in mind, if you've seen or heard statements about SSIS that you don't know if they're true, please let me know. Post a comment or send me an email[1] and I'll add it to my queue. Hopefully I'll have the first myth debunked by next week and will keep a steady stream of them coming your way in the weeks that follow, but in order to keep them coming I will need your help.
So let your voice be heard!
[1] Matthew MCT at Gmail dot calm - you can figure out what to do with it.
The Cake is a Lie
I don't have much time for computer games these days, but I've been playing Valve Software's game Portal over the last few weeks. I finished it last night, and have had a big smile on my face ever since. If you own an XBox 360 Windows PC with a decent video card you should definitely check it out.
Really.
There will be cake.
Really.
There will be cake.
Another Thought on Competition
I posted some thoughts on competition a few months back, and some recent conversations have made me visit this topic again. One was a recurring conversation that I've had with my six year old son. He's very competitive (I wonder where he gets that trait, eh?) but hates to lose. I've been trying to explain to him for years that losing (and by extension, competing against someone better than yourself) is the only way to get better, and that getting better is the only way to win. It's taken a while, but the lesson is starting to stick.
But it doesn't stick everywhere.
I had a conversation a few weeks back with my friend and colleague Ted Malone. We were talking about team dynamics, and Ted came up with this great quote:
Wow, that's profound. I don't know if Ted gets credit for this quote (I think he said it was not his own, but my memory is poor for that type of thing) but he certainly gets my thanks for sharing it with me. In so many walks of life - and software development and architecture is certainly one of them - the people who shine the brightest[1] are the ones who try to surround themselves with the best and the brightest they can find. Any candle, no matter how dim, will look bright in a dark room; you never know how bright your light shines until you take it out in the sunlight.
So what's the moral of the story?
Good question. I always have trouble with that whole "wrapping up and making a point" thing. But if there is a moral, it is that we should always attempt to raise the bar against which we are being judged, and against which we are judging ourselves. Think of it as a process of continuous improvement for the individual. What better investment could we make?
[1] Please note that I'm not trying to say that I fall into this category! Although I like to think that I'm always learning, any time I start to think of myself as an "expert" in any given topic I meet someone whose knowledge puts mine to shame. So I try to hang out with them. :-)
But it doesn't stick everywhere.
I had a conversation a few weeks back with my friend and colleague Ted Malone. We were talking about team dynamics, and Ted came up with this great quote:
Tier one people always try to surround themselves with tier one people.
Tier two people always try to surround themselves with tier three people.
Wow, that's profound. I don't know if Ted gets credit for this quote (I think he said it was not his own, but my memory is poor for that type of thing) but he certainly gets my thanks for sharing it with me. In so many walks of life - and software development and architecture is certainly one of them - the people who shine the brightest[1] are the ones who try to surround themselves with the best and the brightest they can find. Any candle, no matter how dim, will look bright in a dark room; you never know how bright your light shines until you take it out in the sunlight.
So what's the moral of the story?
Good question. I always have trouble with that whole "wrapping up and making a point" thing. But if there is a moral, it is that we should always attempt to raise the bar against which we are being judged, and against which we are judging ourselves. Think of it as a process of continuous improvement for the individual. What better investment could we make?
[1] Please note that I'm not trying to say that I fall into this category! Although I like to think that I'm always learning, any time I start to think of myself as an "expert" in any given topic I meet someone whose knowledge puts mine to shame. So I try to hang out with them. :-)
That Was Fun!
I just got off the phone with Greg Low from SQL Down Under. I had a great time talking to him about SQL Server Integration Services, covering some of the best practices that I've compiled over the years of working with SSIS. I've always loved Greg's casual interview style, and it made the time fly. I wish we had another few hours to talk, but then of course no one would listen to the whole thing. ;-)
In any event, the show should be online by next week. I'll post another notice here when it's ready to download.,
And before I forget (again), many thanks to Chris Randall for demanding SSIS coverage on SQL Down Under. Without his nudge, I probably never would have gotten to speak with Greg, so it's official: I owe you one, Chris!
In any event, the show should be online by next week. I'll post another notice here when it's ready to download.,
And before I forget (again), many thanks to Chris Randall for demanding SSIS coverage on SQL Down Under. Without his nudge, I probably never would have gotten to speak with Greg, so it's official: I owe you one, Chris!
Happy Halloween!
I can't believe October has come and gone already. Usually this is my favorite month of the year, but this year I've barely noticed it. Things have been so busy I've even forgotten to update my email signature. Usually I will update it to use this great seasonal quote:
"October. When the leaves turn blood and the wind turns bone: a time for doings
dark and strange."
This is attributed to the author Glen Cook, as it's taken from the cover of his classic novel October's Baby[1] but it was probably written by the same guy the publisher got to write the summary for the back cover. Still, I like it anyway, and it generally sums up the way that October usually feels for me.
This year was strange in its own way with trips all over the US, speaking gigs both at home and as far away as Stockholm, and more work than any one person should ever have. Not that this is a bad thing, but hopefully next year October will have a little more time for blogging. And baking...
[1] Which is finally back in print after 20 years as part of the A Cruel Wind compilation.
Tuesday, October 30, 2007
Real World Experience
Have you ever noticed how the term "real world experience" comes up quite a bit in the IT world? Employers aren't just looking for someone with a college degree or with professional certifications - they want someone with real world experience. Trainers who have worked "in the trenches" always go out of their way to say so when talking with potential clients. Savvy students who are looking for quality training try to make sure that the trainer delivering the courses they attend have "been there and done that."
But why? What does this "real world experience" deliver?
Before I answer that question, let me first say that I do not mean to disparage classroom learning in any way. As a long-time trainer (and before that, a long-time student) I truly believe in the value of that traditional learning experience. And as someone with far too many Microsoft and Oracle certifications I obviously believe in the value of using certification to validate knowledge and the ability to apply that knowledge to solve problems.
So what does real world experience give us that nothing else does?
Pain. Real world experience gives you pain.
How is this a good thing, you ask?
Simply put, there is nothing quite like pain, be it physical, mental or emotional, to drive home lessons in the human brain. The lessons you learn through pain are the ones that stay with you the longest.
Here's an example:
Many years ago, before I got a desk job and started getting softer and softer with every passing year, I was involved with the Society for Creative Anachronism, fighting in various competitions with sword and shield.[1] Since I was coming from a competitive fencing background, I went with very minimal armor and a small shield, and focused on speed and agility instead of brute strength.
This was both good and bad. The good part was that I was able to apply many of the techniques I had learned (learned the hard way, I might add) through years of fencing. The bad part was that I tended to bleed a lot. There was this one spot on my left leg, above the top of my leg armor that I could not seem to guard. People kept hitting this undefended spot, and for some reason the sweatpants I wore under my armor (and which were the only thing covering this part of me) kept not protecting me.[2]
So after a few weeks of this some kind soul pulled me aside and, after praising my stubborn dedication, told me that I would do one of these three things.
1) Give up.
2) Get a bigger shield or heavier leg armor.
3) Move faster.
Of course, option one was no option at all. Option two was also unrealistic (remember - this was before I got the job that pays well but conspires to keep me out of armor and out of shape) because I couldn't afford new equipment. So option three was what remained. And yes, I did learn to move faster (and to effectively punch-block, but that's probably another story) and to guard that spot very well, because the pain kept motivating me to do it right.
Of course, it's rare that you're going to suffer physical pain when working an IT job in the real world, but the pain of working all weekend, or explaining to your client that it was you who brought down the production server... Those pains are real too, and are also excellent motivators.
So why is real world experience important and unique? Because once someone has felt that pain himself, he's never going to forget it, and he is going to be able to avoid that pitfall when it shows up in his path again. And if you put that person in the right position at the right time, he can help the other members of the team avoid those pitfalls too. At least for the time being; until they feel the pain themselves, nobody else is really going to understand...
So at this point you're probably wondering what inspired me to go off on this tangent. You see, my wife has bitten her cheek several times over the past few days. As you know, once you bit your cheek (or lip, or tongue, or whatever) once, it's much easier to do it again (and again) because it's all swollen from the last bite. So when she bit it again this morning I pulled her aside and told her she would do one of these three things...
...and hopefully I suffered enough pain that I'll never make that same mistake again. ;-)
[1] Yes, I'm a nerd in many aspects of my life, I know...
[2] My wife took a few photos of the bruises I earned this way - I've never seen anyone but Barney with more purple skin...
But why? What does this "real world experience" deliver?
Before I answer that question, let me first say that I do not mean to disparage classroom learning in any way. As a long-time trainer (and before that, a long-time student) I truly believe in the value of that traditional learning experience. And as someone with far too many Microsoft and Oracle certifications I obviously believe in the value of using certification to validate knowledge and the ability to apply that knowledge to solve problems.
So what does real world experience give us that nothing else does?
Pain. Real world experience gives you pain.
How is this a good thing, you ask?
Simply put, there is nothing quite like pain, be it physical, mental or emotional, to drive home lessons in the human brain. The lessons you learn through pain are the ones that stay with you the longest.
Here's an example:
Many years ago, before I got a desk job and started getting softer and softer with every passing year, I was involved with the Society for Creative Anachronism, fighting in various competitions with sword and shield.[1] Since I was coming from a competitive fencing background, I went with very minimal armor and a small shield, and focused on speed and agility instead of brute strength.
This was both good and bad. The good part was that I was able to apply many of the techniques I had learned (learned the hard way, I might add) through years of fencing. The bad part was that I tended to bleed a lot. There was this one spot on my left leg, above the top of my leg armor that I could not seem to guard. People kept hitting this undefended spot, and for some reason the sweatpants I wore under my armor (and which were the only thing covering this part of me) kept not protecting me.[2]
So after a few weeks of this some kind soul pulled me aside and, after praising my stubborn dedication, told me that I would do one of these three things.
1) Give up.
2) Get a bigger shield or heavier leg armor.
3) Move faster.
Of course, option one was no option at all. Option two was also unrealistic (remember - this was before I got the job that pays well but conspires to keep me out of armor and out of shape) because I couldn't afford new equipment. So option three was what remained. And yes, I did learn to move faster (and to effectively punch-block, but that's probably another story) and to guard that spot very well, because the pain kept motivating me to do it right.
Of course, it's rare that you're going to suffer physical pain when working an IT job in the real world, but the pain of working all weekend, or explaining to your client that it was you who brought down the production server... Those pains are real too, and are also excellent motivators.
So why is real world experience important and unique? Because once someone has felt that pain himself, he's never going to forget it, and he is going to be able to avoid that pitfall when it shows up in his path again. And if you put that person in the right position at the right time, he can help the other members of the team avoid those pitfalls too. At least for the time being; until they feel the pain themselves, nobody else is really going to understand...
So at this point you're probably wondering what inspired me to go off on this tangent. You see, my wife has bitten her cheek several times over the past few days. As you know, once you bit your cheek (or lip, or tongue, or whatever) once, it's much easier to do it again (and again) because it's all swollen from the last bite. So when she bit it again this morning I pulled her aside and told her she would do one of these three things...
...and hopefully I suffered enough pain that I'll never make that same mistake again. ;-)
[1] Yes, I'm a nerd in many aspects of my life, I know...
[2] My wife took a few photos of the bruises I earned this way - I've never seen anyone but Barney with more purple skin...
Sunday, October 28, 2007
Visual Developers of Upstate New York
Following my successful SSIS seminar last weekend for the Syracuse, NY chapter of the ACM, I am now scheduled to speak at the Visual Developers of Upstate New York users group meeting in December. The meeting is scheduled for Wednesday, December 19th at 6:00 at the Microsoft offices in Rochester, NY. I'll be speaking on SSIS deployment best practices, so if you're in the area, please plan on attending, as we're sure to have a lot of fun.
Tuesday, October 23, 2007
SSIS Down Under
I'm talking to Greg Low, the host of the wonderful SQL Server-focused podcast series SQL Down Under about being a guest on the show and talking about SQL Server Integration Services best practices. I've long been a fan of this podcast series, so I'm awfully excited.
We've yet to set a firm agenda, so if there is anything SSIS-related you'd like to hear covered, why not post a comment?
We've yet to set a firm agenda, so if there is anything SSIS-related you'd like to hear covered, why not post a comment?
Monday, October 22, 2007
Ok, So We Fired Bob...
Have you ever had one of those moments where you needed to look across all of your Team Foundation Server projects to find every file that is currently checked out? I know I have, and when that moment comes around it is never a time of leisure - you always need to know right away because someone is breathing down your neck while you manually navigate through the project tree.
Thankfully, the fine folks at Ekobit have produced a free Visual Studio 2005 add-in called List Pending Changes Browser that will allow you to not only find pending changes across the entire tree, but also to filter by project path, including wildcard paths. It looks pretty slick.
And did I mention it's free?
So download it, install it and check it out!
Thankfully, the fine folks at Ekobit have produced a free Visual Studio 2005 add-in called List Pending Changes Browser that will allow you to not only find pending changes across the entire tree, but also to filter by project path, including wildcard paths. It looks pretty slick.
And did I mention it's free?
So download it, install it and check it out!
SSIS and DTS
This past Saturday I delivered a one-day seminar on SQL Server Integration Services for the local chapter of the ACM. Based on the setup information I'd received leading up to the seminar I'd prepared an introductory (this is Control Flow, this is Data Flow...) set of slides, but I was very pleasantly surprised Saturday morning. There were around 20 people attending, and almost every one of them had some previous SSIS experience, so we covered much more information and much more interesting topics than I'd planned. I had a great time, and based on the feedback I've already received post-session from the attendees, they did as well.
One of the topics we touched on was that of migrating from DTS to SSIS. Anyone who has spoken to me on this topic before knows my basic stance, but it's worth summarizing here:
"On Saturday you mentioned that you recommend importing old DTS packages into SSIS because there isn’t a migration tool.[3] This would allow us to keep using our old packages without having to rewrite them prior to upgrading to SQL Server 2005. My questions is would we be able to open and edit the old DTS packages or just open and run them?"
The short answer is that SQL Server 2005, out of the box, only allows you to run DTS packages, not to edit them. So when SQL Server 2005 was released, you still needed a SQL Server 2000 machine with Enterprise Manager installed in order to make changes to your DTS packages or (lord help you) to build new ones. Thankfully, Microsoft has released a "Feature Pack" for SQL Server 2005 that includes the Microsoft SQL Server 2000 DTS Designer Components, which allow you to edit DTS packages in SSMS or BIDS without needing Enterprise Manager installed.
You can download the Feature Pack components here: http://www.microsoft.com/downloads/details.aspx?FamilyID=50b97994-8453-4998-8226-fa42ec403d17&displaylang=en
There is also a good overview topic on SSIS backward compatibility in SQL Server Books online, which you can find online here: http://msdn2.microsoft.com/en-us/library/ms143706.aspx
Enjoy!
[1] Canned peaches, remember?
[2] That's right - fresh peaches!
[3] Please note that I didn't exactly say that there was no migration tool. I simply said that there was no migration tool that worked for non-trivial real world packages. ;-)
One of the topics we touched on was that of migrating from DTS to SSIS. Anyone who has spoken to me on this topic before knows my basic stance, but it's worth summarizing here:
- DTS was a simple tool for solving simple problems.[1]
- SSIS is a powerful tool for solving just about any data integration problem, but while it makes it easy to do things the right way, it's not always simple to do simple things.[2]
- You can run DTS and SSIS side-by-side on the same SQL Server 2005 server.
- If you have DTS packages that do what you need them to do, leave them as DTS packages. Don't attempt to migrate/upgrade them to SSIS.
- The DTS migration tools that supposedly allow you to upgrade DTS packages to SSIS packages largely exist to make the VB6 -> VB.NET upgrade tools look good.
"On Saturday you mentioned that you recommend importing old DTS packages into SSIS because there isn’t a migration tool.[3] This would allow us to keep using our old packages without having to rewrite them prior to upgrading to SQL Server 2005. My questions is would we be able to open and edit the old DTS packages or just open and run them?"
The short answer is that SQL Server 2005, out of the box, only allows you to run DTS packages, not to edit them. So when SQL Server 2005 was released, you still needed a SQL Server 2000 machine with Enterprise Manager installed in order to make changes to your DTS packages or (lord help you) to build new ones. Thankfully, Microsoft has released a "Feature Pack" for SQL Server 2005 that includes the Microsoft SQL Server 2000 DTS Designer Components, which allow you to edit DTS packages in SSMS or BIDS without needing Enterprise Manager installed.
You can download the Feature Pack components here: http://www.microsoft.com/downloads/details.aspx?FamilyID=50b97994-8453-4998-8226-fa42ec403d17&displaylang=en
There is also a good overview topic on SSIS backward compatibility in SQL Server Books online, which you can find online here: http://msdn2.microsoft.com/en-us/library/ms143706.aspx
Enjoy!
[1] Canned peaches, remember?
[2] That's right - fresh peaches!
[3] Please note that I didn't exactly say that there was no migration tool. I simply said that there was no migration tool that worked for non-trivial real world packages. ;-)
MDX (almost) in the Mainstream
A few months back I posted a link to a New York Times article on data mining, marveling how such a cool technology was getting coverage in the non-technical press.
Well... MDX isn't quite ready to make the business section of the New York Times, and it probably never will be. But The Register (yes, again) has started a series of articles trying to explain to the "mainstream" software developer audience what MDX is and why it is important to them. Check out the first article here: http://www.regdeveloper.co.uk/2007/10/22/mdx_intro/
I think this is very interesting because with the SQL Server 2005 generation of tools, including SSIS and SSAS, developers can include BI functionality in traditional, "non-BI" applications. If you read this blog for BI information, odds are this article won't be telling you anything you don't already know, but odds are also good that you do know someone who develops software but who hasn't "seen the light" when it comes to BI. Send this article to them...
Well... MDX isn't quite ready to make the business section of the New York Times, and it probably never will be. But The Register (yes, again) has started a series of articles trying to explain to the "mainstream" software developer audience what MDX is and why it is important to them. Check out the first article here: http://www.regdeveloper.co.uk/2007/10/22/mdx_intro/
I think this is very interesting because with the SQL Server 2005 generation of tools, including SSIS and SSAS, developers can include BI functionality in traditional, "non-BI" applications. If you read this blog for BI information, odds are this article won't be telling you anything you don't already know, but odds are also good that you do know someone who develops software but who hasn't "seen the light" when it comes to BI. Send this article to them...
Insert Expletive Here - That Was Good Food!
One of the reasons it's been so long since I've blogged regularly is my travel schedule. Normally I tend to travel in the United States, but this month I spent most of a week in Stockholm, Sweden, delivering an "Advanced Topics" seminar on SQL Server Integration Services. The trip was delightful, the seminar was a great success, and I can't wait to return to the City on the Water.
But the thing I keep talking about is the food.
The night before I returned to New York, my host took me out to the most fantastic dinner I've had in many years. I can't say that it was the best meal of my life, but it was definitely in the top three, and I honestly cannot remember a better one. Oh my goodness, was it good. The restaurant was called Esperanto, and the tasting menu we got was the "Menu Arabesque" which you can find online here:
http://www.esperantorestaurant.se/menuarabesqueF.aspx
Wow.
Words fail me to describe the food - although I am a "foodie" in that I am an accomplished home cook and baker, and that I seek out good food wherever I go, I can't tell you what it was that made this food so incredibly good. But I can tell you this: Because of this dinner I ended up getting 1.5 hours of sleep before starting my 27 hour trip home[1] and I have no regrets. I'd do it again in a second if the opportunity were to present itself.
With that said... Hey Tobias - when am I coming back to Stockholm? ;-)
[1] This is thanks to Air France and JFK. The trip was supposed to be much shorter.
But the thing I keep talking about is the food.
The night before I returned to New York, my host took me out to the most fantastic dinner I've had in many years. I can't say that it was the best meal of my life, but it was definitely in the top three, and I honestly cannot remember a better one. Oh my goodness, was it good. The restaurant was called Esperanto, and the tasting menu we got was the "Menu Arabesque" which you can find online here:
http://www.esperantorestaurant.se/menuarabesqueF.aspx
Wow.
Words fail me to describe the food - although I am a "foodie" in that I am an accomplished home cook and baker, and that I seek out good food wherever I go, I can't tell you what it was that made this food so incredibly good. But I can tell you this: Because of this dinner I ended up getting 1.5 hours of sleep before starting my 27 hour trip home[1] and I have no regrets. I'd do it again in a second if the opportunity were to present itself.
With that said... Hey Tobias - when am I coming back to Stockholm? ;-)
[1] This is thanks to Air France and JFK. The trip was supposed to be much shorter.
Wisdom from Microsoft's Bill Buxton
Yet again I've taken an unplanned and extended leave of absence from blogging. My work and travel schedule lately has been overwhelming, and after spending seven weeks on the road (not the entire week each week, but it's still been brutal) I'm finally back in the office and looking up to see that there is still a world around me.
One of the things I've done this morning is walk through my favorites, checking the news and so on. And on The Register there was an interesting article about Bill Buxton of Microsoft Research. And in that article was this great quote:
Now of course there are still opportunities for a talented lone software developer to make a big difference, but most "interesting" problems today need to be viewed from a broad range of contexts in order to be solved. This is something that I've thought for years (albeit on a much smaller scale, I'm sure) so it makes me happy to see that my views are shared by someone as brilliant as Mr. Buxton.
One of the things I've done this morning is walk through my favorites, checking the news and so on. And on The Register there was an interesting article about Bill Buxton of Microsoft Research. And in that article was this great quote:
"The renaissance is over - the problems are far too difficult for any one individual to have sufficient knowledge to advance them. On the other hand, the renaissance team is possible and our only hope is the collective - the cross disciplinary team. Engineering and computer science, interaction design, ethnography, marketing and sales."
Now of course there are still opportunities for a talented lone software developer to make a big difference, but most "interesting" problems today need to be viewed from a broad range of contexts in order to be solved. This is something that I've thought for years (albeit on a much smaller scale, I'm sure) so it makes me happy to see that my views are shared by someone as brilliant as Mr. Buxton.
Subscribe to:
Posts (Atom)