rulururu

post What’s got you obsessed?

March 25th, 2008

Filed under: coding, programming — mike hall @ 11:29 pm

Jeff Atwood recently wrote about the Choose Your Own Adventure books and how they are early programming books. I couldn’t agree more. I owned a few in my childhood and have fond memories of them.

There were imitators like with anything that successful, and there were a few good ones (even some D&D flavored books), but the CYOA books were the originals.

For me, they more than sparked my interest in programming, they almost single handed started me programming. The first program of any real depth that I wrote was a QBASIC application that mimicked a typical book of the CYOA series. We all remember QBASIC right?

 

Anyone remember the one huge improvement that QBASIC had over BASIC? That’s right… no more line numbers! BASIC forced you to type a number at the beginning of each line. Don’t you try try to go back and add in too many lines near the beginning of your program, else you’ll be sitting there for a long time.

Anyway, so my program was a text based application that would basically give you a description of your current situation and ask you to make a choice. Very typical of the CYOA books. So you make the choice and then the whole thing repeats. Had I been smarter and more experienced, I would have done this in a loop with an array of objects or used a tree or something like that, but alas my original program was chock-full of goto statements. There’s no maintaining this application after the original version. But that’s ok. After a little while I could see the spaghetti-fied, spider-webbed, maze of death mess I had just created and I soon realized the difficulty and the magnitude of problems of the field in which I was entering. I grew a little that day and have tried to grow each day since.

That application was the first application I had written for fun, and it hasn’t stopped since. I’ve messed with writing an AI command prompt, a chat program, a file explorer, and a news reader, but my obsession as of late is a Twitter client named Bitter. (So now you now why the blog posts have been few and far between as of late.) When Bitter finally gets released (hopefully in a couple weeks), I can get back to blogging. In the mean time though, check out Twitter. This is yet another new Web 2.0 thing I first assumed was just for the punk kids nowadays and I wouldn’t like it, but now I can’t live without it. It’s a social site/service that allow you to post what you’re up to, what you’re thinking about, cool links you’ve found, and even allows you to use it as a public chat with other Twitterers. Here’s a cool tutorial explaining it. Anyway, I’m on Twitter as mikehall and wouldn’t mind seeing some other people on it.

So what was your first program and what’s been your latest obsession?

post DevCares Event: Security & Office

March 19th, 2008

Filed under: ASP.NET, coding, events, programming, security, web — mike hall @ 2:05 pm

I attended the Microsoft DevCares event here in Indianapolis a few weeks ago. It might not be on par with MIX, but whatcha gonna do? Anyway, the event was broken up into two sessions: security and Office.

In the security portion of the event, we looked at some common web exploits, how they work and how to fix them in your code. We went over cross-site scripting, cross-site request forgeries, SQL injection, insecure direct object references, information leakage and improper error handling, and broken authentication and session management. The presenter demo’d each one with a fictitious product website and some exploit code. It was pretty interesting although I had seen most of the demos already when I attended the previous month’s MSDN event on IIS7 and ASP.NET 2.0 application services.

We then broke in the Office integration session. Mostly talk around VSTO, WWF, Ribbon development and ClickOnce deployment. Not too bad, but not my cup of tea.

Anyway, I couldn’t get the exploit code, but I have the PowerPoint slides for anyone that wants them:

post Reinventing the wheel

March 15th, 2008

Filed under: UI, UI foible, coding, programming, usability — mike hall @ 12:50 am

Does HP do this on purpose? I don’t know if HP just likes to reinvent the wheel or what, but this just seems crazy. But let’s back up a bit before I go on any further…

I was at my brother-in-law’s house tonight and I was “privileged” to take on the role of family IT guy. What that meant tonight was diagnosing “Active Desktop disabled” errors along with random blue-screenedness. After a little investigating and some scrounging through the event logs, I saw that some services failing to start and other weird errors, so we decided it was time to wipe the slate, or in this case drive, clean.

So we backed up the stuff from his laptop (since no one ever backs up) and popped in the Windows XP install CD (this was back when HP actually gave you CDs). I reformatted the drive, reinstalled Windows and then moved on to the driver CDs. These are the custom gems provided by HP to return your laptop to the tip top amount of crapware that is on them by default. After the second driver CD, I was presented with this:

Um… huh? Ok… so I have the choice of both restarting my computer now and not restarting now? So I click on the restart later checkbox and now only the restart later checkbox is checked. I click on the restart now checkbox just to make sure and again only the restart now checkbox is checked. Hm… how come this smells like another control I so often encounter?

I’ve already talked about my previous dealings with HP software and them using the wrong controls at the wrong time. Here is yet another instance. This leaves me with a couple thoughts neither of which are very uplifting. Either the programmer at HP didn’t know about radio buttons and so reinvented the wheel by using exclusive OR checkboxes, or he did know about radio buttons but choose not to use them. Talk about a case of “Not Invented Here” syndrome. What gets me is even if the original programmer didn’t know to use radio buttons, do they not do peer reviews? or testing? Did these dialogs not get looked at by anyone else down the line? I’m just amazed that this slipped through the cracks.

But for whatever reason it was, this managed to get released as is. Whether because of the programmer, project manager or whatever force it was, this is how it is. But no matter what the reason, it’s not good…

post How stable is your code?

March 10th, 2008

Filed under: coding, programming — mike hall @ 11:59 pm

There is a principle in software called the “Stable Dependency Principle” which states:

Dependencies between released components must run in the direction of stability. The dependee must be more stable than the depender.

Which is of course what we all want when developing software. We never want anything we depend on to change its API, because that means we have to “unnecessarily” change our code too. (But if we have an API that we manage, we should be able to change it any time we darn well please.)

We measure the instability of a class by the number of classes that depend on it (C[a]) and the number of classes that it depends on (C[e]):

I = C[e] / (C[a] + C[e])

So the range of I is 0 <= I <= 1, where a value of 0 means that the class is completely stable (since nothing depends on it) and a value of 1 means, well, you can change your code whenever your heart desires. With I defined, we can restate the Stable Dependency Principle in terms of it:

Components should be arranged such that components with high I metrics should depend upon components with low I metrics.

which again basically means that instable components should depend on stable components. This leads us to a design principle to make use of this favorable dependency flow. This is called the “Stable Abstraction Principle”:

The more stable a component is, the more it must consist of abstract classes. A completely stable component should consist of nothing but abstract classes.

Of course in Java and .NET, you would replace “abstract class” with “interface”, but you get the picture. So basically the more interfaces you have, the more stable your component is (assuming of course your dependers are using your interfaces rather than some internal implementation that’s public). Let’s look at how you calculate the abstraction of a component:

A = (# of interfaces) / (# of classes and interfaces)

For example if your component has 2 interfaces and 3 classes, your component’s A value would be 2/5 or 0.4. As with I, the range of A is 0 <= A <= 1, with a value of 0 meaning you have no interfaces and 1 meaning it’s nothing but interfaces.

Calculating both I and A for your component will put you somewhere on this graph:

At the four extremes you have maximally stable and abstract components, maximally instable and concrete components, maximally stable and concrete components, and maximally instable and abstract components. Most components fall somewhere in between. What we want though is for our components to be somewhere along the main sequence with some stable interfaces and some changing concrete classes. Staying on the main sequence ensures that the more abstract your component is the more stable it will be. We measure the distance of the component from the main sequence like so:

D = |(A + I - 1) / sqrt(2) |

You want D to be as close to 0 as possible to make sure your component is on the main sequence, although values of up to about 0.707 are usually ok. But desirably, keep it close to 0.

So what do you think? Does a bad combination of A and I values necessarily mean your code is bad? I know that after learning about this, I’ve started to think about the abstractness and instability in my designs a little more. I’ll make a rough estimation of I and A in my components and see where I end up. At the the very least, it’s made think about using more interfaces and using them better, and that’s nothing but good.

ruldrurd

Powered by WordPress, Theme based off the "I'm Okay" theme by Laurentiu Piron

Creative Commons License This work is licensed under a Creative Commons Attribution 3.0 United States License.


Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.