Meadows Design

I admit it. I’m a math and science geek. I am, undoubtedly, a software engineer as well so I better be darn good at working with numbers and recognizing patterns.

The other night, I was playing around with math. When I was younger I would play games with license plate tag numbers trying to make equations out of them. It was pretty easy. By assigning numeric values to the letters using a base-10 system with A = 1, you could take a tag number of AC214D and come up with the individual numbers 123144. You’d then have to figure out some way to make the equation work. The equival
ency operator and parenthesis could go anywhere in the equation and you could combine numbers. This particular tag number supports:

(1+2-3+1)*4 = 4
1+2-3+1 = 4/4
12/3*1*4 = 4

You get the idea, but back to the point.

The other day I noticed something about the number 7. Particularly about 7 and 21. I found it odd that the sum of the digits of 21 (2+1) is also the multiplier of 7 required to equal 21. Or 7 * (2+1) = 21. I started playing randomly with other numbers to see if it would work and then I realized that it applies to the following:

7*(4+2) =42
7*(6+3) = 63
7*(8+4) = 84
7*(10+5) = 105
…
7*(18+9) = 189

(My math language is likely going to start to break down here so bear with me. Anyone have a whitboard?)

The pattern, in case you don’t see it yet, is that the two numbers in the sum, when concatenated as strings, equal the
product of the sum and 7. Further, the first number of the sum is always a multiple of two and the second number of the sum is 1/2 the first number (9 is half of 18).

I was pretty excited (yes, excited) until I reached the following:

7*(20+10) != 2010

Rats. Unthwarted, I started to pursue this a little further and realized there was a more subtle pattern. Instead of concatenating the string representation of the numbers, what if the first number was moved over one digit (multiplied by 10) and then added to the second number.
This would mean:

7*(2+1) = 21 = (2*10)+1
7*(10+5) = 105 = (10*10) + 5
7*(20+10) = 210 = (20*10) + 10

Low and behold, it worked. And it works for much larger numbers as well.

7*(14296+7148) = 150108 = (14296*10)+7148

One thing I noticed that I thought was neat until I could easily explain
it away is that the product of the numbers abiding by this pattern was always divisible by three. The reason is that your multiplying 7 by (2x+x) This is the same as multiplying 7 by 3x and so all numbers are divisible by 3. Incidentally, if the sum of the digits of a number are divisible by three, then the number itself is divisible by 3.

Turns out there IS a simple reason this occurs. If you multiply 7 by (2x+x) you essentially have (7 * 3x). Thusly, 7*3x = 21x = 20x+1x. So the reason the pattern occurs is pretty simple to understand but I still think it’s pretty neat.

Did I mention I love math?

andy Uncategorized

There has been a lot of chatter lately about good design practices. I don’t know if this is because I’ve just noticed it more, if it’s part of the alt.net push on the community, or if there are actually more people interested in improving our craft.

Several sites exist out there that urge developers to think about what they’re doing and they range from the architectural perspective (codebetter.com) to the human factors perspective (codinghorror.com — an excellent site that never disappoints.
)

Regardless of the reason, it appears to me that a fundamental piece of the puzzle is missing. That piece being coding better isn’t the same thing as coding smarter. It appears to me that some developers have a unique form of savant syndrome granting them all the architectural prowess for which one could ever hope but none of the common sense development practices that can actually make or break an application.

I’m an excellent developer.
 

Let’s take the following scenario that, sadly, is one of four from an application I inherited.

The first scenario in “Coding Smarter” involves understanding your medium. By that, I mean that you should really understand how the technology you’re using functions.

This application wanted to maintain a user
id once the user was logged in. I wrote about an expansion of this method on Stackoverflow.

The general idea is that you want to maintain as little (or as much, sadly) state as you can between requests and given that HTTP is a stateless protocol you need to store it somewhere. Typically this information is stored in the session on the server but the authors of the application didn’t deem the session worthy and decided that they would store the user id of the user making the request in… wait for it… the ViewState.

 

Think about this for a second. What do we know about the ViewState?

n
Well, for starters, the ViewState is sent back and forth between the server and the client. This means that for every item that is stored in the ViewState, that item must be returned from the client to the server with every request. (Incidentally, they also made liberal use of UpdatePanel). This might be “OK” — not really, but wait for it — because the user id is only an integer, but this application stored EVERYTHING in the ViewState that it needed. No use of session variables were involved.

The BIGGER issue with storing the user id in the ViewState is that it is not secure. ViewState is not encrypted by default, merely encoded. Not surprisingly, there was no encrypting of the ViewState taking place in the code so anyone that could access it could decode it.

In the devel
oper’s defense, they did encrypt the individual fields that were going into the ViewState, but unless they were encrypting them properly they may as well not have encrypted them at all.

The BIGGEST problem is that there is, essentially, no user authentication timeout. That means that the user can be using the site, step away from the computer for a week, a month, even a year, and then come back and continue on their merry way on the site. Or, go about browsing other sites, hit back in their browser to load a page from the site (there was also no client-side cache expiration), perform some new action and automatically be logged into the site. This might be fine on a site that’s not handling sensitive information. Unfortunately, this site is.

The lesson is that just because a framework or platform makes something available to you doesn’t mean that you have to use it. If
you want to use it, make sure you understand what it is, how it functions, and what the repercussions of using it actually are.

I’m debating on turning this into a series given the number of issues I typically stumble upon when inheriting projects. If you would like to see more of this, let me know.

andy Coding Smarter