Ramblings

Classes you need for programming.

Don MacVittie — Wed, 27 Aug 2008 19:53:42 GMT

Great post by Walter Bright over at Doctor Dobbs (always my favorite programming mag) about what college classes you need to be a programmer. While there are some I disagree with - Lori thought she didn't need calculus for programming either, but then we went into Geographic Information Systems (GIS), and guess what? GIS - at least the vector parts and distance in raster parts - is calculus and geometry with a database attached. Lori picked it up quickly of course, but it could have been less painful.

I would add OS design to his list - knowing the architecture and knowing software design theory does you little good in the age of Virtualization. And I'd remove Jet Engines, replacing it with military history (because security for sure shares a lot with military history, and much of CS could learn from it) - in the same spirit that he included Jet Engines ;-).

I would also swap the location of physics and business accounting in the list - not having physics doesn't limit your career options, not understanding the basics of how businesses work will limit the options of the most geeky of us eventually.

And I'm a fan of learning one of each type of language - he included assembly language, I would add a low-level compiled language like C or Pascal and a higher-level language like Java or C#. Not because you'll use that particular language, necessarily, but so that your entire experience with them isn't with the theory of their workings that you picked up from that one chapter of your compiler/interpreter design course.

Anyway, I'm sure you'd all customize that list also, but thought I'd bring it to your attention. Read the bit on economics, it is both funny and true.

Don.

Share this post :

/reading: Sept/Oct Archaeology Magazine. A good read this issue.

It's always great fun until the makeup comes off.

Don MacVittie — Tue, 26 Aug 2008 17:56:26 GMT

So we were discussing relationships today, and I got to thinking of the parallels between relationships and vendor relations. Lots has been written on the topic, but I'm never shy about throwing my two bits out.

It's interesting to me that when a person sets their sites on you they are often putting on a mask - the first six or eight or twelve weeks of a romantic relationship are sometimes different than reality. People are on their best behavior at the start of a relationship, and you see the world through somewhat tinted glasses - most of us rose-colored, but no doubt some of you are analytical enough that I'll just say tinted. You trip along merrily thinking the world is a very cool place and wishing you could spend all of your free time with this person.

For some of us lucky ducklings, that feeling continues on unabated. I'm one of those. Thirteen years in and I still think Lori's the perfect woman for me. She's not the perfect woman for you though, she's married. ;-) For most relationships, once the make-up comes off and you have to deal with this person on a daily basis - without the shield of perception but in the harsh light of reality, you find faults. For most relationships those faults are condemning. That's why most of us date a lot more people than we marry.

The same is true of IT purchases. The problem is that it's far easier to lose a girlfriend/boyfriend that turns out to be difficult than it is to lose a technology that isn't all that you expected. And the same type of hype goes on during the sales cycle as goes on during the courting cycle. It is the sales representative's job to sell you products, not to point out the weaknesses in those products. And third-party accreditation has become a market unto itself, so while some test labs and analysts go out of their way to be truthful, for most taking their word is like asking your new girlfriend's best friend if she's a worthy person. Of course the answer is yes, they're invested in each other.

So the conversations are somewhat parallel...

You: I like stock car racing.

Her (in an evening gown): Me too!

Is functionally equivalent to

You: We have this business problem.

Sales rep: Our product is designed form the ground up to solve that problem!

Is it all sales reps? No, there are a fair number out there that are trying to help you solve your problems and believe that their products will do just that. Of course, they wouldn't be very good sales reps if they didn't believe that, so the question of applicability to your problems is still valid.

The reason that relationships end up with you finding faults is simple, this person wasn't hand-made for you, they grew up in a different environment with different inputs and experiences. That makes for great variety but also causes a lot of seemingly promising relationships to bottom out quickly.

Have no doubt, the same is true of your IT purchases. That product wasn't made for you, you're going to find things that you wish were better. After all, a database or an Application Delivery Controller are not going to solve your business problem, only give you the tools to solve it yourself. You have to work at it, much as you do at a real-life after-the-makeup relationship. So be aware of that, lots of things sound great in the sales pitch that don't pan out long-term, or that the work required to get there is too much.

The best you can do is some research to try and ferret out the weaknesses others have encountered - see what others who have dated your vendor think after the makeup came off. After all, there is no eHarmony for vendors.

The other thing you can do is ask some questions about how to work around unknown weaknesses. Ask about adaptability and programmatic interfaces - see if you can make your long-term relationship with this vendor into what you want with a bit of extra work. iRules, profiles, and iControl are part of our answer to the "we can't be your perfect life-partner out of the box" market reality of ADCs, which means you can make us into your perfect mate. Other vendors in every space should be doing the same - just ask them, because should be is not the same as are.

If you don't ask those questions, you may find yourself sitting in your datacenter late at night, trying to resolve your issues and listening to the blues.

And that's a great question for your next date too - "Are you adaptable to become whatever I want, whenever I want, even if it changes over time?"

/Just sayin'

Don.

Share this post :

Multi-core Parallel Processing - or Not.

Don MacVittie — Wed, 20 Aug 2008 17:07:49 GMT

Fortune has an article about multi-core CPUs and the struggles of software to make use of them.

If you follow software development at all, you knew this was coming, and like a car crash, can't seem to look away, though you know it's going to be ugly.

And it is all a question of market maturity. Funny thing about computers, in many ways the market has grown up over the last 20 years, but due to an endless stream of innovation, in many ways it hasn't.

This particular problem is probably the best example we have of this phenomenon.

Not every car needs to be a Maserati when a beat up old Ford will get you to work every day. This is common sense applied regularly in every industry and field of endeavor out there - you don't send strategic bombers to blanket the country where a bank robbery is occurring. And yet in computers, bigger and faster is always assumed to be better for every application. That's where the first, truly useful, wave of Virtualization came in - putting all of those servers that were using a tiny percentage of their resources together on one box... Because we always had to have the newest, fastest box. Many of you are about to decry "but that's all they sold..." yeah, that's a part of the problem. The other part is that while you're bringing in the faster bigger brighter box through the front door, perfectly serviceable boxes were going out your back door as "too old".

The other part of the problem is that this is a tools issue, not a developer issue. The vast majority of developers in today's world are focused on business problems, not technical problems. With millions of developers across the globe, asking them to do what we would have done even 10 years ago - relearn everything to the "cool new standard" - is not acceptable. Some will, no doubt, those who, like me, are intrigued by difficult programming problems (in my case preferably close to the metal), but most won't. It's not their job. Even if it was their job, the state of software development is such that most development occurs in virtual machines or as interpreted languages - not development that could or should have to worry about what the CPU is doing. And honestly, for most enterprise developers, their eyes glaze over when you start to say "parallel development". Start talking about atomic operations, protected code segments, and locks, and you'll lose them completely. That's no business problem.

So what do we do? Well, the tool vendors need to figure it out. Either your VM can handle multiple CPUs or it can't. Just let us know, so we know whether we need more cores or more boxes when the time comes. You could lay this at the feet of OS vendors - and I could make that case since that's one of the ways the development tools could be generated - but do you really want your OS wasting even more cycles worrying about whether your machine is multi-core or not? Yeah, me either.

Do I wish I was involved in the research? Oh heck yes, that type of development is really fun - in that frustrating until you get it sort of way. Do I think that Fortune mis-represented the problem? Only kind of. They never come out and say that the Enterprise should be worried about it, but their target market includes C-Level execs, and they never clearly state that this is not - and should not be - an enterprise problem either. Tool vendors and in some cases appliance vendors will have to struggle with this problem, but enterprise developers? Nope.

What can you do in the meantime? Well first off, don't oversize too much. Unless you're certain your app can take advantage of multi-core, it may not be doing you any good. Second off, when your application outgrows that server, save it as a hand-me-down, don't let Bob take it home to add to his network. Other apps likely don't have the same sizing requirements. And finally, watch the smart folks at Intel and AMD, that's where the problem is likely to be fixed first... Intel sells a C++ compiler that can directly take advantage of multi-core, so they're on the road to the solution, just need a little time to bubble it up to more commonly used enterprise languages.

Don.

/Reading: M10 GMC in Action

Share this post :

Your site, your input.

Don MacVittie — Mon, 18 Aug 2008 17:43:17 GMT

I've said this before, even asked this less formally before, but we've got 3x the users we did just around a year ago, so it bears asking again.

As you no doubt could guess, we spend quite a bit of time talking about what kind of content we provide to you and what will provide you with the best information in a timely manner.

Our dilemma is of course that there are 30,000 of you and four of us (five if you count our fearless leader, a few more if you count the extended team), and while some of you provide excellent content that helps us out a lot, we still have to focus our time on what will help the most of you or items that will tell you about things you may not have been considering. It's a struggle that we engage in pretty regularly, trying to balance our coverage.

The thing is, we can make these determinations in a vacuum - we know why you're here - but prefer to get your input so that our coverage is focused on what you feel is important. We've got a six month calendar to guide our coverage, but want your help making that calendar even more useful.

With that in mind, I'm dropping you a poll to see what you think.

Check as many as you like, let us know what you want/need. We're here to help you do your job, so don't hesitate to clue us in on how we can do that better!

Don.

/Reading: US Tank Destroyers in WWII

What topics would you like to see more coverage of? ( polls)

When SOAP has failed.

Don MacVittie — Thu, 17 Jul 2008 19:27:22 GMT

Interesting read over at The Register that posits the question "will Flex SOAP 1.1 work with .NET betas?"

The steps he went through and how he got things going was mildly interesting, more interesting to me was that he even had to ask.

I cannot say how happy I am that the answer was a resounding "Yes, they work together", because if we ever see a "no, these two mainstream Web Services products don't inter-operate" (ignoring those first few painful versions of yesteryear when people were figuring it out), then SOAP has well and truly failed.

The entire purpose of SOAP is interoperability, we shouldn't need to ask these questions. Indeed, they shouldn't even occur to us and the environment should be such that if we try and they don't work together, we assume that we did something wrong.

But some vendor will do it, guaranteed. Trying to get you to use their tools only, they'll fail to support the standard correctly. When that happens, we, as an industry, need to slap them.

Until then, we get to continue to flourish in Nirvana.

Don.

/reading: Programming Ruby - free electronic version.

Share this post :

Cash for Open Source? HuH?

Don MacVittie — Mon, 14 Jul 2008 22:15:43 GMT

There's a blog post - ironically touting a title with "economies" in it - over on C-NET.com talking about the need to get more enterprises to contribute cash and updates to Open Source Projects.

So the Freeks (Free Freaks who expect everyone else's work to be free but still want to be paid for their work) are now not-so-free? You can't have it both ways. Either capitalism in all of its glory reigns, or socialism in all of its glory reigns. But you can't destroy the free market and replace it with a mandatory payment scheme. Well you can try, if you're really interested in seeing your experiment dwindle on the vine. Just ask any of the (former) economists for the (former) Soviet Union.

Look, I use Open Source, I've contributed back to Open Source, but the point of OSS was to make software free. You did that. You start to sound like a drug dealer when you call for something in return for free software.

After all, the first hit is always free, right?

Don.

/Reading: This was a bonus post, see my last post from this morning if you actually follow my reading habits.

Share this post :

Storage - Where do we go from here?

Don MacVittie — Mon, 14 Jul 2008 17:10:57 GMT

There's a lot out there right now that is up in the air... The future direction of social networking, mobile vs laptops, security, when next I'll shave my head, and the topic of today's post, what to do about data storage.

There's a post over on DrunkenData.com that talks about preliminary results from a bit of UC/NetApp research that decided... SURPRISE! That 90% of your data is just sitting there taking up space.

The first thing that struck me about this claim was "Structured or Unstructured?" but I quickly remembered that it's NAS, so unstructured.

Not that this is really news to most people in the storage world, but the next question must be "what to do about that"? It's information we've had for a while, and things like ILM did nothing to help us capitalize on it, just as many of us predicted and analysts denied.

The post suggests going to tape and optical jukeboxes for those infrequently accessed files, and now that all OS's actually honor access times, that's possible in a NAS world (it wasn't, more recently than you think), and there are plenty of products like Acopia that can direct data based on access date/time. Another thing that gave me a chuckle was the tape world. Tape is good for long-term, off-site, archival storage. Its other uses have dwindled as the cost of disk has dwindled. But the article calls tape arrays "greener technology". Funny, it used to be sold as "cheaper". one can't help but wonder what it will be sold as after this post.

Another solution that doesn't require 15 year wait times for tape to seek to your users' files when they need access to them is disk arrays that spin down when not in use. Simple and to the point, EMC and NexSan make them, I'm certain others do too, but it's been a while since I was living/breathing in this space. The theory is simple, if this is tier two (or three) of your data architecture, and drawer #7 hasn't been accessed in X number of minutes, spin it down and leave it that way until someone does access a file stored there. That's green, it saves you green, and you don't have tape seek times to contend with (and in a jukebox, just tape or disk selection time could constitute the need for a coffee break).

Combine that with an intelligent tool for figuring out what goes on this system and what goes on your big, beefy, NetApp box, and you're in data nirvana, right? Well, at least your costs are down, your access times aren't up, and you are on the road to a greener Mother Earth. And tape can still be your archive format of choice.

I'm not as close as one might expect with the Acopia team (I know, I'm working on it), in fact, I know more about the competing technology one of our competitors sucked up, but migration based on access times is pretty simplistic as NAS Virtualization goes, so I'm going to stick my neck out with some amount of bravado and suggest we can do it.

So the architecture then would be simple. in front an Acopia box, behind it your spin-down disks on the right, and your NetApp Filers with hyper-active data on the left. As the data ages, it moves to the right (any presumed allegory to humanity is in the author's imagination, I assure you), the trays on the right are arranged such that all older data is in one tray, working backward to the newest stuff. So you'll have a couple of trays that never spin down, a bunch that are nearly always spun down, and your NetApp cranking out file after file. All coordinated by your NAS Virtualization engine, of course.

The only thing left in the seven-headed hydra that is data storage is SAN, and since the only company that truly managed the SAN/NAS leap is dead and gone, their technology and patents disappearing into the bowels of EMC, I guess you'll have to wait for the next revolution to work SAN into your NAS architecture.

Think about it, once set up you would have to do nothing and your electricity costs would go down. Monthly savings until such time as technology eliminates this architecture as an option versus the one-time expense of setting it up. Appealing.

Don.

/Reading: Smotherhood. These days I read while waiting for paint to dry on miniatures, and Lori left it lying around. Good book.

Share this post :

Trying out some new toys.

Don MacVittie — Wed, 09 Jul 2008 21:01:22 GMT

So Lori has a way to insert social media icons into her posts, I thought I'd try to one-up her. SO this Bookmarking widget for LiveWriter just... Does it. All the stuff at the bottom of this page is created by Insert Bookmarking Tags from the WLW Plug In directory.

I'm lazy, this was easy. I like.

I also finally downloaded the Polaroid blogging tool, here's a test of how it works...

Seems pretty cool to me. And yes, that's our youngest child in the picture.

So all in all, good stuff. Assuming these links work after I hit post...

Share this post :

Added the "share" button after the fact from: Add This That one is from Lori - thanks!

Don.

Technorati Tags: Windows Live Writer, Tools, Blogging Tools, dmacvittie

Online and Old Media Redux.

Don MacVittie — Tue, 08 Jul 2008 17:00:46 GMT

Heh. Good article about the state of publishing on the Associated Press. Seems someone has said all this before.

Here's hoping they figure it out, because they're not the only ones suffering from the problem.

Don.

Twitter Uptime: A Personal Solution.

Don MacVittie — Mon, 30 Jun 2008 19:54:20 GMT

I've been Tweeting more or less for the better part of a year.

Twitter has been down, more or less, for the better part of a year.

Clearly this organization did not take their rate of growth into account when designing (and redesigning) their architecture. No matter what they claim.

If I knew who our salesperson was for them, I'd send 'em off with a personal note, but even though I've met most of our salespeople at company functions, I only feel like I actually know two of them.

So instead, to help Twitter resolve their problems, I'm done Tweeting.

I'll take the month of July off, reduce their bandwidth, save them from the burden of carrying my oh-so-clever commentary and oh-so-important updates across their servers.

I suggest you do the same. Give them the opportunity to fix the problems, reduce their burden!

When you think about it, there's not much to Tweeting anyway. What can be said in 140 words is rarely enlightening or even impactful.

So if you're one of the people who follows me on Twitter, see you in a month.

If you're not, sign up and keep me honest. I sometimes find that I have something to say that I absolutely must Tweet to share with the world (though often the world doesn't care, that's the nature of Tweets!).

Don.