Remember Versioning Before Putting Fist Through Monitor

I am currently working on a project with a deadline in my day job, and I am having fun with it. Well, mostly. There was this little problem I was having that was beginning to make me quite frustrated. And you know that frustration occasionally results in a computer programmer putting his or her fist through the monitor display, right? Well, I guess that’s a favorite meme; nobody really does this, right? Gosh, I hope not. It wouldn’t be so dangerous these days, what with LED monitors and all, but in earlier ages when we had glass monitor screens we risked serious cuts and bruises.

I was trying to enforce some encapsulation by working with two different VS2012 solutions at the same time. Since I was planning to use a particular set of class libraries in multiple related projects, I wanted to make them into common components. No sense reinventing wheels. So here I was with the common component libraries in one solution and the application using those libraries in the other. The user application had references to the DLLs of the class library, and to the point, the references pointed to the Release folders of the class libraries. Since I was developing both pretty much at the some time (though the class libraries started life and got their major form prior to the user application), I would occasionally find I needed to go back to the class libraries to make tweaks and corrections. Then I would test the user application to see how well the changes worked. The user application was being neatly used as a test bed for the common libraries — meaning the next time I use them, which will be in a follow-on project this week, they will have been largely debugged. Two birds with one stone.

This worked out mostly OK, but I started noticing that sometimes my class library changes weren’t taking effect. I’d make changes, rebuild the libraries, and the changes wouldn’t take effect! But then again, sometimes they would! I was nearing the peak frustration level, with my dual monitors beginning to cringe in anticipation of the inevitable shattering blow from my Fist of Steel®, when suddenly it popped in there as to what was going on.


Here I was, rebuilding my libraries with the new changes, and failing to rebuild my user application! Of course the changes weren’t taking effect! The user application was never referring to the DLLs in the Release folders of the class libraries, it was referring to the copies of the DLLs it had placed in its own bin folder! And since I had not rebuilt the user application to pull the class libarary changes into the user application’s bin folver, OF COURSE it continued to use the old versions of the libaries.

In a certain sense I was creating my very own Hell. A versioning Hell. Complete with red-tinged, tailed demons wielding pitchforks. Jabbing me into a towering frustration! But realization is power, and so the demons are now banished to the nether regions. And all is now blue-sky with chirping birds again.

Gosh, I hope I remember this next time.

Posted in Miscellaneous | Leave a comment

Affording New Tech: Somebody’s Feeling Entitled

Jenna Wortham of the New York Times seems to think that new technology should be cheap enough for poor people to afford it. My first question is: Why?

Headlines are not normally created by the journalist, but are apportioned by editors who sometimes miss the point. Jenna’s article, which in the NYT has the headline “More Tech Magic, if You Can Afford It“, in my local newspaper is headlined “Tech magic comes at a price out of reach for many”. But in this case, the editors in question did get the point Ms. Wortham intended.

While writing about Google Glass, she reports handing her demo device back to the Google employee “…with the sinking feeling that it could be a while before I’d be that close to them again.”

And why would she have such a feeling? She writes:

That’s because they cost $1,500, and they are being made available largely to developers and people who are eager to figure out how to build applications for them.

Her entire article rants on and on about how wonderful the new technology is and how terrible it is that poor people won’t be able to afford it. Until the price does down. And even when the price does go down, how terrible it will be that the poor won’t be able to afford the newest versions, since the price for the latest and greatest will be higher than state-of-the-art.

But what the heck is she complaining about? It’s not fair! That’s what. “…it would be a shame if the only people who participate in this leap forward are those who can afford it.” Bat puckey. Cannot “the poor” wait five minutes until they CAN afford it? Apparently this is a tragedy. She agrees with Anil Dash, an entrepreneur and blogger who raised similar concerns last year in a post titled “You Can’t Start the Revolution From the Country Club.” She nods sagely in agreement with Dash’s pathetic premise, and except for the obvious fact that this premise is completely false, we might be tempted to go along with it, too. You can take it to the bank that technological revolutions almost always start from the so-called “country club”. The fact is simply this: if the “country club” doesn’t adopt the new technology at its inception, then nobody else is getting it either. It turns light outside when the sun comes up. No sooner. Deal with it. Just because you don’t like something doesn’t give you an entitlement to have it otherwise.

And fairness? What is it about certain people that they think that being poor gives one rights superior to the better off, who have to work for what they get, too? Oh, sure, you work at a dead-end job, a job that you qualified yourself for by spending your time goofing off instead of getting an education that would make it possible for you have a better job. Therefore you are entitled to the same choices in life as someone who put business before pleasure and prepared for the future?

Please spare me. I can sympathize with someone affected by breaks that resulted from circumstances truly beyond their control, but most people are poor because of choices they themselves made, or are in situations that they could, with some effort, work themselves out of. Ms. Wortham’s own experience shows clearly that being poor is, with some effort, only a temporary condition. She says she couldn’t afford that iPhone because she was working in a poorly-paying job. But now she can afford one. Does she think she’s the exception?

I’ve been poor, and I’ve been moderately well-off. I knew precisely why it was that way at every point. There was no-one to blame but myself, and I would have felt ashamed of myself for blaming anyone else but myself, and I would have felt like a fool for asking for extraordinary consideration for my condition. “Hey, Steve Jobs, I can’t afford that nice new iPhone because I’ve gotten myself into overwhelming debt due to wanting crap I couldn’t afford, so you must sell me one for one-third it’s retail value (or better yet gimme one for free). That would be fairer, wouldn’t it?”

Maybe my desire for an iPhone (or a Windows Phone) should lead me to better my condition so I CAN afford one.

Posted in Miscellaneous | Leave a comment

My Review of Regular Expressions Cookbook

Originally submitted at O’Reilly

This cookbook provides more than 100 recipes to help you crunch data and manipulate text with regular expressions. With recipes for popular programming languages such as C#, Java, JavaScript, Perl, PHP, Python, Ruby, and VB.NET, Regular Expressions Cookbook will help you learn powerful …

A Very Handy Addition to my Bookshelf!

By Cyberherbalist from Olympia, WA on 7/17/2012


4out of 5

Pros: Helpful examples, Easy to understand, Well Organized, Well-written

Cons: Index could be expanded

Best Uses: Student, Expert, Novice, Intermediate

Describe Yourself: Developer

I got this book hoping to find “recipes” for the various Regex problems I run into in my work, and it has more than fulfilled my expectations. Finding a thankfully clear tutorial on Regexes was an unexpected plus.

A previous reviewer, Steve of Houston, TX, complained about the recipe numbering scheme, like where the text might say “see Recipes 3.15 and 3.16”. He said he couldn’t figure out what these numbers meant or where there was a list of them. What?! Did he actually have a copy of the book in hand? The Table of Contents lists each recipe and gives its title. The format is X.Y, where X is the chapter and Y is the individual recipe. If one is referred to Recipe 2.6, it is child’s play to turn to chapter 2 and find the sixth recipe. They are clearly marked. This is entirely intuitive, and I cannot understand how he could have missed it.


Posted in Miscellaneous | Leave a comment

Should a database table always have primary keys?

The occasion for this post is a little contretemps I experienced on recently. The topic of this blog post is the question posed by acidZombie24, a member of StackOverflow, over 3 years ago. I was one of those who responded to the question. My answer was:

Databases don’t have keys, per se, but their constituent tables might. I assume you mean that, but just in case…

Anyway, tables with a large number of rows should absolutely have primary keys; tables with only a few rows don’t need them, necessarily, though they don’t hurt. It depends upon the usage and the size of the table. Purists will put primary keys in every table. This is not wrong; and neither is omitting PKs in small tables.

Note that the statement “Database don’t have keys…” refers to the original text of the question title, which was subsequently changed by an edit.

This answer did not make much of an impression on anyone (the questioner never marked any of the answers as Accepted and nobody gave me any upvotes), until just the other day. And this was a downvote (which subtracts reputation points). If warranted, I don’t mind a downvote, if it is a legitimate beef with my answer, but given the downvoter’s comment I thought it unwarranted. He commented on his downvote, and a little conversation ensued:

jmoreno: A single row table doesn’t need a primary key, anything else should have one defined to avoid duplicates. – Jun 21 at 0:57

Cyberherbalist: Yes, generally, but business rules determine whether duplicates are to be permitted — it is not inconceivable that duplicate entries in a table might not only be permissible, but expected. It depends upon what is being stored, and what use is made of it. BTW thanks for the rep hit — this answer doesn’t actually contradict the accepted answer. Your absolutism is noted. – Jun 21 at 17:15

jmoreno: If you’re storing exact duplicates, you’re storing the wrong thing. As for the rep hit, remove the slam at people that think that every table should have a PK, and I’ll remove it. – Jun 21 at 18:28

I was a little puzzled about the reference to my supposed “slam” at people who think that every table should have a PK. I looked over my answer and comments to others’ answers for any insults and did not see any. Unless by “slam” he meant the term “purist”? Perhaps he thought this was intended as an insult? It wasn’t so intended — heck, I am a purist about certain things, and I think I’m justified in those cases, and accept that differences of opinion are natural consequences of free speech. In fact, I am a purist when it comes to people trying to bully me around, and thus I will not remove the “slam.” I will simply wear the loss of 2 reputation points as a badge of obstinacy! No problemo.

It just so happens that at the moment I am working on a little utility at work which accesses a table that has no Primary Key. And that was not due to oversight by our typically conscientious and highly competent Data Administration staff. In this case, the table stores rows which, once inserted, are never updated or deleted. Our DA staff are really in love with “natural keys” (sometimes to a fault) as Primary Keys, and if they had thought a PK was necessary, then By Golly that’s we would have gotten, LOL. But this is the table:

CREATE TABLE [dbo].[agency_message](
[agency] [char](3) NOT NULL,
[subagency] [char](1) NOT NULL,
[effective_date] [smalldatetime] NOT NULL,
[message_text] [varchar](1000) NOT NULL,
[requested_by_user_name] [varchar](50) NOT NULL

The table is used as follows: when a user signs into the application, the system compares the system date/time with the “effective_date” in the table, and uses the row with the largest effective_date whose effective_date is not greater than the current system date/time, if one exists (the additional criterium is a match on agency/subagency).

The reason there is no primary key is because no row is ever updated or deleted once inserted, and we retain all rows for the sake of having a history of agency messages.

Given that our DA staff are, with all due respect and good will, purists of the best stripe, I consider that this table’s lacking of a primary key to be arguable evidence that tables do not always require primary keys. Business rules, as I said above, must prevail, and in this case, the Business Rules dictated the table structure.

Posted in Miscellaneous | Leave a comment

Old Nerd’s Post – “Ancient” Technology

Old High School friends of mine just posted some Facebook comments on “ancient” technology they still possessed, and it caused me to think back about my old devices.  Brian mentioned that he still had his father’s old slide rule (and could still use it), which was quite cool!  Some of the people reading this post may not know what a slide rule is, though.  Check it out on Wikipedia: Slide Rule.  For the record: I haven’t forgotten how to use a slide rule, either.

My very first scientific calculator was the Berkey 4030, which I purchased back in 1975 for $110, which is about $470 in 2012 dollars:

BERKEY 4030 Scientific Calculator, circa 1975

Posted in FractionCalc, Miscellaneous | Leave a comment

The Fix is Found

Earlier I said that there was this bad crashing problem with HamTechExam and that I better find it and fix it.  Well.

I cannot claim any heroism here.  It has taken me too long to get around to it, and the best thing I can say about the whole process is I don’t know how on earth this version of the app made it past the App Hub testers.  It couldn’t possibly have worked in the state it was in.  Maybe they were applying goose grease that day, and it just slipped in.

So, for what it’s worth (and for those who bought the app and couldn’t use it, that would be “not much”), the problem is fixed.  It is in certification and perhaps in a day or so it will be published.

All I can say is: my apologies.

Posted in Miscellaneous | Leave a comment

Ignore At One’s Peril

It’s just come to my attention that one of my apps (HamTechExam) is blowing chunks upon startup, failing to function.  When I first heard this I thought that it couldn’t be possible, since the other two similar apps (all running on the same basic code) were having no such problems.  But when I checked my own copy of the app it did not work, confirming it.  Really hard to understand how this was possible, since it was supposedly tested by Windows Phone personnel.  I know it was working then.  Perhaps it was the last update to WP7? 

Anyway, I now have 3 bad reviews in the Marketplace, which is unfortunate.  I am going to figure out what the problem is tonight and hopefully get this squared away.

Posted in Ham Radio Apps | Leave a comment