WUSS 2012 Long Beach Paper

I have posted my paper (An Introduction to Git Version Control...) at my sas-resources.com site:
http://www.sas-resources.com/recipes/an-introduction-to-git-version-control-for-sas-programmers

Thanks to everyone at WUSS who attended, everyone who asked questions and everyone who has given feedback! -s

I Git Busy

While I was on vacation, I got a friendly email reminding me that my WUSS 2012 paper was due July 30th.  Yikes!  I had exactly one week to get home and write it.  My mother calls it procrastinating.  I prefer to think of it as Lazy Loading.

So I was a bit busy last week.

But I finished it.  And I think it's good.  At least, I hope it's good.

It is an Introduction to Git Version Control for SAS Programmers.

You see, back in March I wrote this blog post asking about the version control you use while developing SAS programs:
http://datasteps.blogspot.com/2012/03/version-control.html

Based on the _underwhelming_ response, I assumed most SAS programmers were like me and didn't use a version control system because version control is an enterprise thing and I was doing programming on my own or in small teams.  That was until I discovered Git.  Now version control is mine.  It belongs to me and is part of my workflow.  I'm enthusiastic about how it's helped me as a coder.  Hopefully my presentation and paper will share that enthusiasm with you.

Rainbow Table Salt

DISCLAIMER: I am not an expert at cryptology.  But I generally understand the industry best practices and have implemented this stuff on several sites.  That said, read on at your own risk :)


There's been a lot of talk about LinkedIN passwords getting stolen.  It's an interesting read and it made me think it would make for a good blog post.

If you read the link above you will see them referring to hashed passwords. First of all, nobody should be storing passwords in a data base as clear text.  Never, ever, nope.  You want to store the password after it's been hashed with a one-way hashing algorithm.  One-way just means it's computationally impractical on todays computers to go the reverse direction from hashed string back to password.

So now that you've got your hashed password, you can rest assured that your passwords are super-safe, right?  Well, almost.  You are still vulnerable to a dictionary attack.  A dictionary attack is where an attacker tries to guess your password using a set of likely candidates.

<rant>

Strict password requirements create bad passwords.

You know those password requirements like:

Must be at least 8 characters long and contain

at least one upper-case character

at least one punctuation character (_., etc

at least one number.

It _seems_ like those requirements should force people to create nice secure passwords that are hard to guess. But the reality is exactly opposite.

Those requirements practically force you to use a date.  I would bet good money that at least a quarter of you reading this has a favorite date password to satisfy those requirements.  Let's see, I was born in april of 1974. I can capitalize April put a comma in there and voila: April,1974. Requirements met!

Dictionaries invariably start with a bunch of variations of [month] [punctuation] [2 or 4 digit number].  Secure password fail.

</rant>

Ok, back to the discussion.  Your passwords are stored in your db as hashed strings.  So all an attacker has to do is pre-compute their dictionary and compare those hashes to the hashes they grabbed out of your db using an SQL injection (another topic for another time).  Yes, they would have to know which hashing algorithm you used, but there aren't too many in everyday use (MD5and SHA1 spring to mind).  And these pre-hashed tables exist.  They are called Rainbow Tables.

I have no idea why?

What would be better is to add something to the password before we hash it. Then the attacker can't use a pre-computed Rainbow Table.  The "something you add to a password before you hash it" is called salt. So now they would have to have stolen the salt along with the hashed passwords. And then create a Rainbow Table from scratch.

This is all sounding much better.  Add salt to the password and then hash it.  Got it?  Good.

Actually, there's one more little step we can take to make our passwords even more secure.  We can make sure the salt is unique for each password. This is usually accomplished using a unique identifier for the user (usually the primary key) and a simple random number to create the salt.  As long as the unique salts are stored securely, you can feel pretty confident that you've got things locked down.

I do this type of thing quite often in other languages, but I've neveractually had the need to implement it in SAS.  I will write a subsequent post that has some example SAS code to make the ideas a little more concrete.

Comparing Macro Values

I was working on some SAS macro code today that I hadn't touched in quite a while. Actually, I haven't even been working on much SAS code for a while. So it was nice to get my mind back to the language I am most familiar with. I spent a good thirty minutes staring at a problem that was so simple that it should not have taken me long to figure it out.

A funny thing happens when you spend your development time hopping from language to language. You learn lots of techniques and ways of thinking, but you lose out on some of the day-to-day habits that coding in one language can instill in you.

I had a macro variable named &PATH that I was checking to see if it had a value of NULL. This path variable contained the fully-qualified name of a file (all the directory info). But I needed to assign it a default value (NULL) and check if anything was truly assigned.

%if &path ne NULL %then %do.....

I kept getting ERROR: A character operand was found in the %EVAL function of %IF condition where a numeric operand is required. The condition was: &path ne NULL

What the hell? That's about as straightforward a line of code as you could write! Well, since I've been hacking away on everything but SAS this last month, I immediately start questioning the language. Can I not use a mnemonic operator? Does it have to be "not ="?Is it something else in the code that's throwing it off? Is NULL a SAS keyword or something? Am I going senile? Blah blah blah.

And then it hit me. &PATH is a variable that's resolving to a value during execution. The value contains special characters (/var/path/more/path/etc) that are being evaluated badly. I needed to escape the value (or on SAS Macro parlance: quote the value) to hide it from the macro processor.

EDIT: Oops, I even used the wrong quoting function (sigh).

%if %nrstr(&name) ne NULL ...

Should be:
%if %quote(&name) ne NULL ...

So the SAS Macro day-to-day habit that I temporarily forgot: Do not trust the values of macro variables during execution. Unless you explicitly want the value to be processed, always wrap it with an appropriate quoting function.

Maybe my 30 minute loss will be your 30 minute gain. :)

What's The Idea?

The easy part is done: code got written, various technical barriers were overcome, a prototype was built, and the proof-of-concept was proven.

Now the hard part: figuring out if the concept is even a good idea or not. Of course, _I_ think it's a good idea, but that doesn't always translate into the real world :)

So what's the idea? I want to solve a problem that I run into at large conferences. There are so many talks I attend, and so many new people I meet that I tend to lose track of it all. I want an easy way to track the people I meet and the talks I attend. As always it needs to be dead simple to use, and fun!

So I created a platform where each user attending a conference (if they opt-in of course) has a unique QR tag.

The QR tag is printed on a sticker and attached to their normal name tag. Then at the conference you make a "connection" with another attendee when you scan their tag.
And to make it fun, various social networking games can be layered on top. The easiest would be to award points for each connection. The person with the most points at the end of the conference wins. No more standing around with a drink in my hand wondering who to talk to.

And QR tags aren't only for conference attendees. Everything at the conference can be QR tagged. So for example, as you walk through a conference you can scan a poster and everything that the author has offered to share will be linked to your account (additional notes, power point, source code, etc). The same would apply to talks, hands-on-workshops, etc.

The only prerequisites are a smartphone with any (free) QR code reader, and access to the internet (3G, 4G, Wifi, etc).

Thoughts?

Conference/Smartphone

Just a quick two-part question:

Do you plan on attending a SAS conference this year (local, regional, global, any)?
Do you use a smartphone?

Version Control

Two things that make me nuts when I work with SAS:
no here documents
no string interpolation

Ok, now that I got that out of the way. I am thinking of putting together a talk on version control for SAS programmers. Do you currently use version control for your SAS programs? Yes, no, which one, why?

I use git for nearly everything. Not sure how I ever got by without it.

Resume Motivation

The other day I blogged about my new SAS-Resources site and some of my motivations for creating it. But I left one motivation out of that introductory post. Not because it is less important, actually it's one of the most important. So important that I wanted to talk about it in its very own post. So what motivation is that? Resumes. Specifically, resumes are broken.

They don't work. They fail you the job seeker. They fail the companies who want to hire you. They're a terrible way of communicating who you are and what you are capable of. Recruiters scan resumes for keywords. So people naturally cram their resumes full of keywords. The result is unreadable. It tells you nothing about the human you may be hiring.

Just as an example, I googled SAS RESUMES. The first hit was a sample resume from scribd.com:
SAS Developer Sample Resume

The good new is, if you want to learn how to write your SAS developer resume, this is a good one to follow. The bad news is, it's just as bad as most of the others. It's lacking one very important thing: a body of work.

A body of work is a much better way of showing who you are and what you are capable of. So when I started thinking about creating SAS-Resources it was very important for me to create a platform that people could use to promote themselves. Not every programmer has time to answer questions on mailing lists and forums, or write lengthy blog posts (ha!), or put together and present papers at conferences. But surely you've written code that could be explained in a recipe. So that another programmer who is wondering "How do I ___ in SAS?" could read your recipe and "like" it. Which creates an online body of work that you could easily share through your public profile (exa: www.sas-resources.com/user/stephen/public). Thus communicating to a potential employer that you are not just a set of keywords and technical terms, but a good coder who can get things done and explain how you did it.

SAS-Resources Site

Man it has been a long time since I updated this blog! But I have a good excuse. I have been working on a new site to share SAS stuff.

There are already sites for programmers to share information, why would you create another one? Good question!

Pretty much the top three online resources are: sasCommunity.org, SAS-L, and support.sas.com forums.

SAS-L is an awesome way to get questions answered quickly. If you've got a SAS related question, SAS-L is probably the best place to get it answered. Its user community is nothing short of amazing. However, an email list is not a very good platform to search for, view, and store information.

Same thing with the forums at support.sas.com. They are great for getting questions answered. And forums are a little more information friendly for searching, etc. But their main drawback is that threads lose visibility as they age.

The sasCommunity.org site is a better platform for sharing information. It allows users to create content through articles/pages. It has a tip of the day. It lets users comment on the content that people have shared. But... it uses a wiki format. It's probably just me, but I just cannot get my head around it. I find it confusing as all hell to use.

There are also some other online resources such as blogs, facebook, linked-in, analytic-bridge, etc. These each have their own pluses and minuses, but unfortunately it means a lot of good information gets spread across multiple places.

So I wanted to build a site that will:
Provide one place for SAS programmers to learn from and share with other SAS programmers.
Be dead simple to use.
Reward users for providing good content.
Allow content that users like to bubble-up and be more visible.
Be fun to develop and fun to use.

So those were the requirements I set out for myself a few months ago and here is the result (so far).
www.sas-resources.com

Please check it out and maybe share a code recipe, or two, or a few!

Any comments, questions, recommendations are always welcome. Thanks! -s