Ben's profileNo Brain, No PainPhotosBlogListsMore  |  Tools Help |
|
22 October Blackmore's Night at House of BluesI was a big Rainbow fan in high school but never saw them live, so when I heard that Blackmore's Night was coming to Chicago I figured I'd better take the opportunity to see Ritchie live at least once in my life.
If you're not familiar with Blackmore's Night, it's a Renaissance music band formed by Blackmore in 1997 and fronted by his 25-year-younger fiance, Candice Night. Yeah, I know. When I first heard about the project I said to myself, "You've got to be kidding..." While I knew of their existance and checked out their web page a couple times a year, I never bought any of their albums, mainly because I'm not a huge Renaissance music fan. I enjoy most classical music, but I find Renaissance music to be a bit *too* formulamatic--kind of like taking Baroque music forms and simplifying them another order of magnitude.
Regardless, Blackmore was going to be in Chicago, and I wasn't about to miss it. Hell, I would have gone even if he was just playing spoons.
I really like House of Blues, too. While I find the whole HOB thing a bit too commercial, at least in Chicago they've got a decent sound system with a competent crew, and the size of venue is ideal. They were pretty full for the show; not quite packed like sardines, but more people than for any other show I've seen at HOB (although I've only seen a couple other acts there).
While they were setting up, I noticed the guitar tech putting a white Strat into one of the guitar stands. I have to admit, just the sight of that got the hair on my neck standing up. Hmmm, maybe they'd crank out a 20-minute version of "Catch the Rainbow"? Hey, I could hope!
It turns out that their music isn't traditional Renaissance music, but rather Renaissance-influenced rock songs. Take the direction Rainbow was heading in the 80's and throw in some Renaissance musical elements and lyrical themes and you'll have a pretty close idea what their music sounds like.
I was pleasantly surprised to see that Candice was an excellent singer and a great frontman (frontwoman???). Great tone and vibrato and no problems hitting notes. If anything her range was a bit limited, but I'm not sure if that was her or just the music. Overall, though, I was impressed.
The rest of the band was top-notch, which really was no surprise--Ritchie always had excellent players (and a hell of a lot of them!!!) throughout the history of Rainbow.
My favorite parts were the 3 songs he played on the Strat, they were much more straight-up rock n' roll and more to my liking. He even did an extended solo in one of the songs, nowhere near as long as the old Rainbow 15-minute solos, but he got a couple of minutes in.
One of the things I love about music is that you can still play it well into your 70's--witness Segovia or Alicia de Larrocha as a couple of examples. At 62, I thought Blackmore was playing better than ever. I have to give Blackmore credit, too--rather than just resting on his laurels and cranking out "Smoke on the Water" forever, instead he's pushing the musical boundaries a bit with his vision of Renaissance rock. While I'm sure there are others doing similar stuff, it's certainly something that isn't heard often.
Two other things also impressed me--first, the tone he got out of his Start. It wasn't the thin single-coil sound you usually expect with Strats, but it wasn't the traditional humbucker sound--rather it was a compressed sound that sounded... well, great.
The other thing was that I had never noticed in his playing previously was a similarity to Jeff Beck in that he didn't just *play* the guitar, rather he sounds like he's ripping the notes out of the guitar. Yeah, I realize it's a bad description, but I think Jeff Beck fans understand what I'm getting at.
In summary--very glad I saw them, and would certainly pay to see them again.
Ben 15 October Evil monolithic systems: Cause #1Although there's dozens of things that contribute to the creation of evil monolithic systems (spaghetti code, bad application of patterns), there's two main design elements that I find to cause the greatest pain. Unfortunately, they're also really prevalent design concepts, so... the list of people who think I'm completely nuts or stupid might get incremented by a few. All I ask is that you think about it a bit and ask yourself if you've run into the same issues in your experience before writing me off :)
With that disclaimer, here's evil monolithic system cause #1:
Using SQL databases to share data between applications
As I've stated before, I really love SQL databases: they're incredibly fast and powerful. And because they're so easy to use and efficient, it's very common to use them for inter-application communication. I can't count the number of systems I've encountered where there's dozens of applications that all access the same database.
But here's the problem: there's probably hundreds or thousands of SQL queries embedded within all these programs. And all these queries are tied intimately to the database for a few reasons:
First, SQL joins are completely dependent on the schema: if any of the relationships in the database change, every single query that references that relationship will have to change.
Second, most SQL data access in programs is tightly bound to the data type. So even though the SQL language itself is pretty datatype-agnostic, the programs themselves like explicitly reference the type. In other words, although the following SQL query is valid regardless of the datatype of the OrderNumber column
most likely the code actually reading the data is similar to this:
And that code will fail if, say, you need to change the type of the column from a number to a character string.
Third, SQL tends to get placed anywhere and everywhere. Some programs may have a data layer, others do not. Perhaps that program does all its data access through stored procedures. Or maybe there's some jobs running on the server. Or DTS packages. It's rarely an easy job determining all the places that a table is accessed.
The end result of all of this is that you end up locked to your existing database schema. And as requirements or performance dynamics change, you're stuck--either you have to say, "No, that's not how the database is set up" or perhaps you'll come up with some gargantuan estimate for how long it will take to modify all the code that needs to be changed.
In either case, it's a situation you should strive not to get into in the first place.
Ben 12 October Evil monolithic systems: What they are and why they're badSo what exactly is an "evil monolithic system?"
Well, "system" is easy--a collection of applications that, working together, complete a process. It could be any process; for example, an order entry and fulfillment system, or an engineering system that collects data, crunches numbers, and spits out reports. The key is that it's multiple applications which work together.
If the applications that comprise the system are overly coupled, though, you end up with what I like to call a "monolith"--because no one application can be changed without affecting the other applications. In other words, even though the system appears to be modular because it's split into several applications, in reality it's no different than having one huge application.
Here's a couple scenarios which are giveaways that you're dealing with a monolithic systems:
And that's where the "evil" part comes in--because monolihic systems are overly coupled, you can't efficiently change them to deal with changing requirements. Not only that, they tend to be fragile because it's easy for a legit bug fix in one applications to create a subtle, hard-to-find bug in another application within the system. The bottom line is that monolithic systems are bad, and something you want to avoid. Next up: the main causes of monolithic systems. Ben |
|
|
