Blogs.msdn.com is a pretty good site, in that it displays all of the recent updates to MSDN blogs. However, I've got to think there's something wrong with their code that actually creates this display. Check out the following screenshot I got from earlier today:
There's one disturbing line in that image; see if you can find it. If it's actually true, I guess MS has bigger fish to fry than Longhorn. Where are they getting the plutonium, though?
One of the unfortunate points of the .NET Framework is that Microsoft neglected to distribute some pretty common controls for it. For example, a numeric textbox; nowhere in Visual Studio .NET will you find a textbox control that only accepts numeric values. That's bad, because there are a lot of times when you want to limit your data entry and display actions to just numeric values, such as when you're dealing with dollar amounts and percentages.
It's not too hard to half-ass something that kinda works here, but inevitably some edge case surfaces in your control (egads, someone entered two negative signs!) that causes your whole app to mess itself and go into seclusion. It is a nasty, brutal procedure to perfect the control, and for some reason, I dedicated my Sunday afternoon to it.
Ladies and gentlemen, I introduce you to my NumericTextbox (dll, code). With it, you can accept numeric user input into a textbox and display it as a formatted number, currency amount, or percentage. It filters for valid numeric data only, and allows the developer to specify decimal precision and comma formatting. Just slap it on your form, and when you want to access the value, call the appropriate Parse method for the data type you want (Float.Parse(numericTextbox.Text), Int32.Parse(numericTextbox.Text), etc.)
I've only tried it on my laptop, so if it causes your immediate office area to burst into flames, I will accept absolutely no responsibility. Feel free to mark up the code however you want.
Woo doggies, after a vacation and a brief illness, I'm back to the vlog. Huzzah huzzah, sayeth the people. Unfortunately, the time away didn't provide me with any ground-breaking insights, like a way to make rhubarb pie from toxic waste. In fact, I had no insights whatsoever until I got back to work and saw an email from my boss that I was due for my annual review. At that very moment, something occurred to me: why on earth do developers need annual reviews?
Reviews are definitely useful. Your boss gets a chance to lavish praise on you, and you in turn get to make completely insane demands for a wall made of plasma tv's in your office. Yes, reviews are good; it's the annual part that makes no sense to me. In my mind, the length of time between reviews should be directly related to how long you've been working as a developer; the shorter you've been there, the quicker your reviews should occur.
When I first started working as a developer, I wasn't very good. I didn't try to eat the keyboard or anything, I just wasn't sure of what I was doing. I got better quickly, though. If I were to measure my usefulness, I'd say it doubled after my first week. After another week, it doubled again. A month later, another doubling, etc etc. Through such geometric growth, I made the hard journey from crapdom to nearly-adequate city.
When I think about how much better I got in that first year, I realize there's no way it could've been recognized or even communicated during an annual review. There was simply too much ground covered. The process would've been much smoother with a series of monthly reviews.
I just finished my second year, and it was much the same. I got much, much better, although my improvement rate was less impressive than that first year. Still, it was too much to communicate in an annual review. Maybe a review every three months would've worked better.
I'm just now getting to my real point. Essentially, reviewing based on time periods seems a little arbitrary. In my mind, we should get reviewed every time we get 20% better. In our field, the learning curve is incredibly oppressive, and it worsens every day. Each time we make an impressive step forward, it should be recognized. If it happens every year, then hey, that's great. Sometimes, particularly when a person is new to the field, it happens a lot more than that, and attention should be paid to these instances.
With regards to measuring and formalizing a procedure like that, I throw my hands up and then lock myself in my closet. It's complicated, definitely. At the same time, though, it's fair and perhaps not totally idiotic.
Okay, I didn't get quite enough time last night to write more about prime numbers. What I wanted to talk about was just how long it takes to try to factor a number that's millions of digits long. Here's a little Python script that makes my point for me.
def Start()
global timeStart
timeStart = time.time()
def End()
global timeEnd
timeEnd = time.time()
def Seconds()
return (timeEnd - timeStart)
def TimedDivide(bigNum, divisor)
Start()
print "answer: " + str(bigNum / divisor)
End()
print "length of time: " + str(Seconds()) + " seconds"
>> TimedDivide(pow(4, 10000000), 3)
I got something like 7 hours for one divide. How many numbers would you have to divide your prime by in order to prove it's prime? Uhhh, a lot (check out Erastosthenes' sieve for more info here, although I'm sure there are better techniques). Multiply that by the number of hours it takes to do each divide, and I'm pretty sure you come up with a number greater than the amount of vienna sausages in the world. Not just North America, the WORLD! I don't mean to be an alarmist, but it's a biggun.
Here's some Python code that will give us an idea of the scope of really big numbers. It's related to yesterday's entry on giganto prime numbers, and it tells us how many digits long a number is, as well as how many bits it'd take to store the number.
def HowManyDigits(bigNum):
return int(math.log(x, 10)) + 1
def ShowNumberInfo(bigNum):
print "length in digits: " + str(HowManyDigits(bigNum))
print "size in bits: " + str(HowManyBits(bigNum))
>> ShowNumberInfo(pow(3, 1000000))
Recently, a colleague at work and I have been talking a lot about computing prime numbers. Specifically, his goal is to find the next largest prime number. Why? For the prime number groupies, of course. The current largest prime is somewhere in the neighborhood of 6 million digits. Through schooling and my own personal endeavors, I know a fair bit about this stuff, so I thought I'd share some here.
Think about a number that's one hundred digits long, something like 2 * 10^99. That's a big number. In fact, it's a huge number. According to some sources, that number we just created is several orders of magnitude larger than the number of atoms in the universe. When it comes to the world around us, we're not just whistling dixie when it comes to a 100 digit long number.
However, when it comes to prime numbers, a 100 digit number is nothing. Really, finding anything under several thousand digits is about as impressive as beating Jessica Simpson at Risk. That's a whole lot of digits, though. You have to take 100 instances of that 100 digit number, string them together, and then you'll have something of interest.
But even then, you're still incredibly far from the record. Right now, we've got a number that's 10,000 digits long. In order to get up the record, we'll need to take 600 instances of that 10,000 digit number, string them together, and then we're close. The numbers you're dealing with now are as large as any number anyone has ever used for anything.
Alright, so we've got our 6 million digit number. How do we store it? Let's try to store it in memory.
Being smart computery types, we know how to determine the max calue that a set of bits can hold; we just make use of powers of 2, remembering that our starting point is 0, not 1. One bit can represent the number 1, since 2^1 equals 2 (thus a spot for 0 and a spot for 1). Ten bits can represent 1023, since 2^10 equals 1024. That's easy enough. If we can just multiply 2^1,000,000, maybe we can start to get an idea of how many bits we'll need.
Err, there's a problem there: there's no easy way to calculate 2^1,000,000. You certainly can't fire up Windows Calculator and expect something to get a result. Compared to what we have to do, that's a pretty trivial calculation and we're still at a loss as to how to compute it.
That's the difficulty of this task. The operations are all simple: it's pretty much just division and multiplication. But on numbers this big, it takes an incredible amount of time. In order to do it quickly, we've got to do it crazily. Over the next couple of posts, I hope to introduce a few quick, crazy ways of computing prime numbers. Due to the terms of service here at codypowell.com, I can really only promise the crazy part.
Question for the unit testers out there: how do you test an abstract class? Do you have to inherit it and then test an instance of the inherited class? That doesn't seem like it'd do the job to me, simply because you'd be testing too much. If a test fails, is it because of the base class or is it because I screwed something up with inheritance? It seems too confusing.
Anyone out there got an answer? I promise absolutely nothing in exchange, although you'd definitely have dibs when the highly-anticipated CodyPowell.com IPO occurs.
No vloggy last week while I was out of the country. I'm back now, though, so you better watch your step.
I never took a class in school about databases. The meager amount of info I possess derives entirely from my idiotic attempts to interface with those wicked beasts. At work, we recently added a really sharp DBA. Since I ride the database short bus, I've been trying to latch onto him like some sort of parasitic howler monkey and suck as much knowledge as possible from him.
Well, in one of these sessions recently, we got into a topic I've never really understood: indexes. Specifically, we were talking about the difference between clustered and non-clustered indexes. Now I could give the textbook definition of both, but I never understood how a database (specifically SQL Server) differentiated internally between the two. Why does one sort faster than the other, and why can you only have one clustered index on a table?
Between him and some subsequent research, I think I've finally managed to grasp it. If a table has a clustered index, the data is stored as a B-tree with the leaf level nodes containing the data pages. If a table has a non-clustered index, the data is still stored as a B-tree, but now the leaf level nodes contain index rows. The index row is used a row locator, pointing to the actual data row containing the key value.
To simplify that (or amplify the geekyness one billion fold), a non-clustered index is a reference type, while a clustered index is a value type. It makes sense to me then that you could have many indexes that are references, while only one that contains the actual data. An actual database guy would probably tear me a new one over my treatment of the whole thing, but as long as this is my website, real database guys aren't allowed.