Mashup: Key Blobs, Win32 CryptoAPI and .NET

December 30, 2008

A while back I had the pleasure of getting more in touch with my crypto side. It was, and still is, very under-developed. Cryptography (and the surrounding use cases) seems to be one of those elite-like skills that people can spend lifetimes researching and learning more about. Therefore, it generally is difficult to pick up when you run into for the first time.

I had used simple encryption functions with different languages before, but never to the extent at which this project took me. In this case, I had a written a pure C++, Windows dll which produced a session key that needed to be consumed by a .NET application.

It seems that one solution to the complexity (like the .NET framework’s solution) is to make pretty wrappers around the system calls so one doesn’t totally freak out. While this is nice and I think a very natural progression of a framework it actually made it more difficult to solve the problem. Not only is the documentation horrendous for this, it would appear that .NET’s implementation is not really in sync with the native CryptoAPI’s. 

Aside from battling through the documentation over at MSDN, Google searches were coming up blank on this. While working through things I ended up posting the question to Stack Overflow. If any of this stuff interests you at all you can check it out over there. I also ended up posting a solution to the problem once I figured things out, as the help at the overfloweth of stacks was limited.

It’s all very anti-climactic but felt since there was no straight answer anywhere on the web, I would try and share mine in hopes of helping some other lost geeky sole.

-

If you enjoyed this post, it would be rock-a-licious if you subscribed to future updates via rss.

5 Comments | .net, c++, crypto, cryptoapi, stackoverflow, win32 | Permalink
Posted by Scott Saad

Time Well Spent

December 20, 2008

My time has been divided recently as much is going on. From a missed PDC 2008 event; to a wonderful home birthing experience with our third child; to learning to play more than twinkle twinkle on the guitar; to spending an absorbent amount of time on Stack Overflow.

hourglass-small

Like sand through the hour glass, these are the days of my life.

Yes, I missed this years PDC event due to the encroaching due date of our unborn child. Most of the content is now online so it’s just a matter of time before one can be caught up. The biggest thing that is hard to recover is the people networking that occurs at these events. So many bright minds in the industry come to share the knowledge. There is always next time and for now… I can always connect with people on twitter. :)

Next came the birth of our third child. We had this one at our house (yes, it was planned that way). All I can say is that the experience was absolutely amazing and a wonderful switch from the hospital environment.

Where else has the time went? Between family, work and play there is Stack Overflow. A developer’s haven for learning, helping others, etc. It’s a community site for geeks of the software trade to hangout and share their experiences.

I had the pleasure of being part of their private beta and was addicted from the start. It’s now in public beta and open to everyone (has been for months now). Check it out if you have not yet done so. It has become another tool in the box that assists in climbing out of those crazy situations us developers always seem to find ourselves in. If I didn’t have so many other things going on in my life I’m sure that a majority of my time would be spent at this site.

Thank goodness for all the other stuff that tends to bring balance to this software developer’s life.

Leave a Comment » | reflections, stackoverflow | Permalink
Posted by Scott Saad

IRC and Distributed Teams

October 6, 2008

The one thing in this field could use more of (or any field for that matter) is better communication. We have a distributed team where almost 50% of the core engineers are working out of their homes across the country. Inevitably, being remote can always pose obstacles. The remoters are always looking for better ways to connect with the main office.

Our team definitely has tried all sorts of tools and tactics to help facilitate better communication. All have helped in some fashion:

  • Human-to-Human – All local engineers sit in the same large room, along with our Product Manager
  • Email – We all know that this has its purpose, but ultimately is becoming the snail mail form of communication
  • VOIP Phone – All have a Cisco phone where everyone is only an extension away
  • IM – Always a great choice where communication needs are non-vocal
  • IM & Video- Skype works great for this as having the ability to see the person you’re talking to makes all the difference OK the world

However, even with everything listed above something seemed to be missing. How do you rope in the remoters to conversations that happen on the fly? We’ve tried a speaker phone where everyone is dialed into the number but there is just way to much chatter and background noise. Nothing was going to replace having them here in the office, but we were determined to try and find something. We needed a better way!

Enter IRC:

About 6 months ago I started doing some side contributions to the open source bug tracking solution, Bugzilla. Here is a system that is developed by true remoters… contributors from areas all around the world. Talk about communication nightmares! How the heck do they make this happen?

Within minutes of reading their developer guide, I realized that that use IRC heavily.  Their developer wiki indicates that its prefered over any other form of communication. So I opened up my client and was “in the mix” with the developers on Bugzilla. I quickly realized that this was an excellent form of communication for distributed teams.

For those that are unfamiliar with IRC, it has a bit of history. It is still heavily used around the globe as it serves as a very effective way to have group discussions. The best way to think of it is like a chat room with a geek polish (or not-so-much-polish) to it. When I realized how effective it was working for the Bugzilla team, I decided to try and get a similar environment going over in our office.

Usage:

For our team, since half of us are in the same room, and the other half in other geolocations, we use this to complement our existing forms of communication. It would be crazy if I had to ask Joe, who is sitting right next to me, a question and I did so in IRC. Just ask him! What I may end up doing is posting the answer to my question in IRC for everyone to see if it relates. Otherwise, we try and keep conversations that relate to the team in the IRC, even if it means that Joe is sitting right next to me.

Observed Benefits:

This is a touchy one as the benefits completely depend the experiences. For us, our experience has been good and therefore, the benefits are great. Put it this way, it only helped communication get better and now occurs at a whole other level. The remoters feel more connected to the team as they have a complete running log of all conversations, and therefore can pipe in at anytime to give input or ask questions.

The Nitty Gritty Details:

While there are many public IRC servers out there that could potentially host our channel we wanted to keep things inside our network for security reasons. Many server software exists out there so this I will leave up to the reader their own research. Here is what we ended up using:

  • Server: UnlrealIRCd (required)
  • IRC Services: Anope IRC Services (optional, but nice to have to increase your IRC geek-ness level)
  • IRC Bot(s): Supybot (optional, but provides for some nice hooks/bells/whistles that are just plain cool)
  • Clients: This one we left up to the developers as there are many out there to choose from
Platform Concerns:

IRC servers thrive mainly on Linux/Unix systems, but we are a Windows shop and the above configuration worked great as all had Windows options available. However, if you have any questions while setting things up, please feel free to contact me anytime and I can try to be of assistance.

-

If you found this post helpful in any way, it would be super cool if you subscribed to future posts via RSS!

5 Comments | team, tools | Tagged: , , , | Permalink
Posted by Scott Saad

Keeping it Sharpened (part 1)

August 20, 2008

Given the previous post on how the niceties of Visual Studio may unconsciously causing our skills to atrophy. In line with that I wanted to post a few action items we can take to help ensure our skills continuously receive sharpening. This is part one of more to come.

One thing we can start to do is pick a completely different editor to work in once in a while. Maybe a favorite one that was pre-Visual Studio (I hope you have one). There are many to choose from but here are a few:

This serves as a great little exercise which once can follow as they see fit. It forces us to think a bit more for various reasons.

  • Code complete is not available available. This forces our brain to think more, which in turn can have good results if kept up.
  • More time is spent researching outside of the IDE. SDK docs, books, magazines, blogs, etc. are read with more vigor which can produce a positive overall learning experience.
  • For whatever reason it seems to get us back to the roots of the language. Remember what it was like when we had to write our first piece of code without referencing something else? Blind so to say? Once the crutch went away we probably felt a little lost, but as time went on we actually LEARNED.
  • The IDE has the potential of making us feel so comfortable and therefore causing us to never step outside of it. We should never get so comfortable that it becomes scary or we lose our balance when put into an environment that is not similar. I mean, how many of us cannot operate when we head over to a teammates computer and they have everything configured different!

This tip of working outside of the IDE cannot always be done. Obviously, when working on anything strictly UI related, this becomes more of a challenge and we’re probably better off remaining in the design tool. Also, until there is some way to build code on the command line, it becomes somewhat tedious to have to switch between IDE and external editor for every compile. So, this is a prerequisite and needs to be done. Can you build on the command line (this is itself another post all together)?

Remember that anything we can do to spawn more thinking is actually good! It forces us to use the brain pieces. The best of the best are those that when placed in unfamiliar conditions/environments adjust and do so in a rapid manner. So the question becomes, if somebody took away our precious environment could we adapt, or would it hurt so bad that it pretty much rendered us useless?

-

If you enjoyed this post it would be cool if you subscribed to future posts by ways of RSS.

Leave a Comment » | learning, theory, visual studio | Permalink
Posted by Scott Saad

A Visual Studio (.NET) Developer Dilemma

August 13, 2008

I started using the Microsoft Visual C++ IDE back on version 6 (before that, it was pure Unix with gcc). Visual Studio is a great product. The evolution of the IDE has been astounding. Scratch that… the evolution of the the entire platform has been monumental. When .NET made its way into the picture it was first kind of sketchy. It has since become a very respectable, dependable, fun platform to develop for. The tools that surround the platform are a big reason of what make it desirable to develop for.

Lately, however, I’ve had some strange realizations that have spurred deep fears that dig at the root of software developers on a Windows platform. For example, I’ve witnessed others using the Code Complete functionality as a form of documentation. If I’m not mistaken, Code Complete was originally intended to help reduce the number of keystrokes, thereby saving time. When I see developers using this functionality to seemingly browse through a list of methods they might be able to call on some object, I want to slap the keyboard right from under their hands! Nothing, but maybe somebody teaching you replaces documentation. Therefore it’s probably a misuse of the tool to be using code complete to browse an API in hopes of finding the method called, “Object.SolveMyProblems()”. Be resourceful and do some research!

Also, at some level, the .NET framework is one big Win32 library wrapper. When coding against it, I’m finding that developers are less inclined to “figure out” what is really going on with the code. For example one can pretty much write three lines of code and get full crypto functionality, where the same would have taken you… well… quite a bit more code in pure C/C++ for Win32. This is not necessarily bad or undesirable. We are all looking for ways to perform our duties in less lines of code. The question becomes, is the understanding still there?

Are we now just going through the motions not really knowing what we’re doing? Should we care? Does any of this really matter? Isn’t this just a natural progression of tools/platforms that make a developer’s life easier?

I would argue that there are potentially hidden costs to having such kick ass tools. Costs that in my mind start to freak me out a bit. What kind of developers are we breeding here if their background knows nothing else but this extraordinary tool set? Many seasoned developers have experience with various others prior to Visual Studio and .NET. These developers at least have a chance of being aware of what’s happening, but are not immune to it. The type of developer that I fear is being bred is one that is unknowingly being conditioned to do less thinking.

What happens when the “thinking” muscle doesn’t get as much use? Like any other muscle, it starts to atrophy. Somebody who develops software needs to be an effective problem solver, which requires serious brain activity. The concern is that we are going to become so comfortable with our frameworks and tools because they take care of so many of the “hard software problems” for us, that we forget how to effectively solve.

What this really boils down to is that as time goes on, the need for understanding dwindles. As tools continue to get better, the requirement to actually understand what is happening behind the curtain disappears. I don’t know about anyone else but this is what scares me.

I’m very curious to see where others stand on this. Am I just unnecessarily freaking out? There will always be the superstar like developers that are not affected by this type of stuff. My anxieties lie with other 95% of developers. Of this percentage there are many developers that think they’re really good, but could it be that the tool set and/or platform is making them look good?

Even if our team was doing primarily developing in Visual Studio (which it’s not), hiring anyone without previous experience in C/C++ would not happen. I would venture to say that even if we were doing primarily .NET development, I would be hesitant at hiring anyone that only has experience with that platform and not with C/C++. That maybe a cry of just not accepting the times and being a grumpy old programmer but hey, everyone has their line.

Leave a Comment » | microsoft, tools, visual studio | Permalink
Posted by Scott Saad

Mojave OS is sweet!

July 30, 2008

This is a short little post that I felt must be done.

I’ve been running Mojave OS for a while now and I cannot move to any other OS for Windows development. It just rocks… plain and simple. I wrote a previous post relating to developers and their duty to upgrade to this new sweetness. There are no more excuses.

If you’re still not convinced, you must check out the Microsoft’s Mojave Experiment for yourself!

Leave a Comment » | microsoft, mojave | Permalink
Posted by Scott Saad

PowerShell – Unix which Command

July 10, 2008

I’m not sure how many PowerShell peeps were once Unix shell dorks, but I would imagine that there are some out there. One command that I relied on heavily was the which command. For one reason or another, finding where the execution path of a file came in handy. Sometimes you may have different versions of the file floating around and you would like to know which one is actually being executed.

The script itself was born from a tiny function I had setup to list my path environment variable in a readable format:

function Get-EnvPath
{
    $env:Path.Split(";") | where {[System.IO.Directory]::Exists($_)}
}

Which produces output like the following:

PS> Get-EnvPath
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools
C:\Windows\Microsoft.NET\Framework\v3.5
C:\Windows\Microsoft.NET\Framework\v2.0.50727
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\VCPackages
C:\Program Files\\Microsoft SDKs\Windows\v6.0A\bin
C:\Windows\System32\WindowsPowerShell\v1.0\
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Program Files\Microsoft SQL Server\100\Tools\Binn\
C:\Program Files (x86)\PowerShell Community Extensions
C:\Program Files (x86)\Perforce\

We can now write our which function that searches through each of these paths for some file. My first implementation of it looked like the following:

function which
{
    param([string]$name)

    [System.IO.FileInfo[]]$theFindings = $()
    foreach( $thePathDir in Get-EnvPath )
    {
            $thePotentialFile = Join-Path $thePathDir $name
            if ( [System.IO.File]::Exists( $thePotentialFile ) )
            {
                $theFindings += new-object System.IO.FileInfo $thePotentialFile
            }
    }    $theFindings
}

Not too shabby I guess. It works, but you can definitely see that the mode in which this function was written fell victim to my normal procedural  ways. Sometimes (for me at least) it’s hard to switch into the PowerShell pipeline way of thinking.

After some deep meditation, the pipeline gods smacked me across the face and somehow a much simpler version of the function came to be:

function which
{
    param([string]$name)
    Get-ChildItem -path (Get-EnvPath) | where { $_.Name -eq $name }
}

To my pleasure, Get-ChildItem can take an array of paths to search through and therefore we are able to utilize the list that Get-EnvPath returns, only listing items that match the incoming name. Definitely much cleaner, but the runtime on it takes longer than I’d like (you can count 1-1000, 2-1000, etc). This is because the where filter is applied after all items have been retrieved, which can be quite large. Would be much better to filter while things were being looked at. Let’s change things around a bit to use the built-in filter parameter of Get-ChildItem, instead of passing to where filter:

function which
{
    param([string]$name)
    Get-ChildItem -path (Get-EnvPath) –filter $name
}

This runs order of magnitudes faster as things are being filtered in real time.

I mean… are you kidding me? That’s it? At first I was embarrassed with the initial attempt. It is like seven times more code than the final  solution. However, if there’s one thing I’ve learned, it’s that we never write something perfect the first time. The process that it took to come up with the final solution was born from what was learned with the first attempt.

-

If you learned anything from this post and would enjoy more at some point, please feel free to subscribe via rss.

4 Comments | powershell, unix | Permalink
Posted by Scott Saad

Purposeful Software Development

July 2, 2008

The post is a quick response to mtelligent’s post on “The Cargo Cult of Test Driven Development”. Somebody referred me to this link and while reading, something struck a nerve (not a bad one… just one).

In the post it talks about how there is a feeling that Test-driven Development (TDD) is a form of Cargo Cult Programming. This can be interpreted to mean that the process of where you write tests in hopes of driving out the production code, has turned into another ritualistic software development process where the meaning of doing such actions is lost.

First off, this phenomena is something we all fall victim to now and again. What use to have real purpose has now become more habit than anything else and we forget why we even started. I have seen this happen first hand with TDD and will be the first to admit guilt. However, let me take you back to when it really meant something.

About 5 years ago I was placed on a project that was completely foreign to me… new team, new code, new technology, new everything. Prior to that I had worked with a team that practiced a modified form of Extreme Programming. In this version, there was no pair programming, there was no test-driven development. There were user stories, iterative development, refactoring, etc. With this new team I decided that I would give this TDD a try as I was hearing that a big piece of the agile benefit(s) were being missed by not unit testing.

I ended up doing a best attempt at TDD… actually writing tests before doing the development: i.e. making the test fail; implementing the code to make the test pass; ensuring the test passes. Holy crap! This took some serious brain tweakage. I mean, my mind was not supposed to work that way and it was some kind of miracle that I didn’t throw the whole idea out the window within the first week. However, I kept following it in hopes that I would start seeing the light. And then it finally happened! There was something absolutely amazing taking place… my code was slowly becoming more robust, testable (obviously), architecturally sound, etc.

This is something that I did not realize though while actually going through the pain. From what I could tell, I was just experiencing a new method of development that was preventing me from being truly effective. It took a while before enlightenment finally took place and I could see that what had happened was something quite magical. It’s kind of like that scene in The Karate Kid where Daniel LaRusso gets all pissed off at Mr. Miyagi because he felt that the only thing he’s been learning how to do is some old guys chores (paint the fence, wax that car, etc). This ain’t no Karate! It was at that moment in time that Mr. Miyagi reveled what was really happening. While performing these seemingly mundane chores, Daniel had learned Karate’s foundational body movements of self defense. He was on his way to becoming a wicked Karate Kid.

Sorry for the jaunt there… Anyway, from that day on I would tell whoever asked on what I felt about TDD and how I was convinced (and still am) it changed the way I did software development. However, time goes by and I we tend to slip into our old habits quite easily. Plus, at this point in time the TDD philosophy had permeated throughout the entire team and it was easy to see the bad habits that we all had picked up. Writing tests, just for the sake of writing tests was a common problem. Feeling things like, “Well Bob, I guess before we can start any real coding we need to write a test first.”

What really happened here is that we fell into the trap. We forgot why we started doing TDD in the first place. We forgot the purpose behind our actions. It’s not to mindlessly fill our test suite with a plethora of tests. It’s not to get 100% code coverage. It’s not to merely improve the quality of the product. All of these things cannot be accomplished through the sole act of TDD. These are usually things that we get for free as a result of reflecting on our code. Test-driven development is something that is chosen to be followed because it simply helps us write better software. While performing continuous analysis on the code our minds engage and we are able to operate at a level where we relentlessly make the code better.

With all that being said it seems a bit unfair to state that TDD as a whole is a form of Cargo Cult Programming. There are many flawed theory’s of testing out there. There always will be. However, if we as programmers can try and remember the purpose behind the methods we follow we can limit our chances of becoming part of the Cargo Cult.

-

If you enjoyed this post, it would be totally righteous if you subscribed to future posts via rss.

6 Comments | reflections, tdd | Permalink
Posted by Scott Saad

Clarification on Purpose

June 25, 2008

My recent posts have all been related to PowerShell. Given this, it might be helpful to clarify reasons. First off, this blog is not another PowerShell blog… it’s a developer’s blog. As a developer we have tools that help us make our jobs easier. For me, PowerShell is one of those tools. When running Windows, I always have it open.

While working on our day to day activities we may run across things that we feel can be automated or easily solved with some custom program. Many of us have these types of tools that we’ve written (or somebody else has written) laying around and there is potential that these tools become absolutely necessary for us to feel productive.

Have you ever had to reinstall your OS? Or better yet, have you ever had your machine crap out and you had to share one of your colleagues? Or perhaps get a loaner from the IT department while your baby undergoes surgery? How awful does it feel not having our happy environment with all our precious tools installed? Any developer usually needs some base set of tools installed for them to feel above average on productivity. PowerShell has become one of the first things I install on a squeaky clean system.

And now to the purpose:

What I find interesting about software development is that it is nothing but how to solve problems… in hopes that the solution to these problems are somewhat elegant. We can lean on our communities for help on this. Why do we subscribe to developer blogs? For me, it’s to learn how to become a better problem solver in hopes that I can incorporate their experiences into my own.

Recently, PowerShell has been one of those tools that keeps helping me solve my problems. Invariably, it has given me the opportunity to evolve my skill set (freebie).

This blog is just a reflection of what I have found useful in solving my developer related problems, in hopes that I can pass on some helpful bits to me fellows.

-

If you enjoyed this post, it would be cool if you subscribed for future posts via rss.

Leave a Comment » | learning, reflections | Permalink
Posted by Scott Saad

PowerShell VsVars32 – 64-bit style

June 19, 2008

I ran across this post which is a frickin’ must for PowerShell and Visual Studio integration. Being very excited about this I ended up trying it out right away and ran across a problem. Digging deeper into the VsVars32 function, it became evident that things bonked because the registry path to Visual Studio was not all there:

1> $theVSKey = Get-ItemProperty HKLM:\SOFTWARE\Microsoft\VisualStudio\9.0

2> $theVSKey.InstallDir

This yields nothing at all as $theVSKey is empty. What the crap is going on here?

Well it ends up being a problem related to running on a 64-bit machine. We need to remember that when in 64-bit mode, applications like Visual Studio are really 32-bit and run in the WoW64 mode. In WoW64 there is a separate section of the registry dedicated to 32-bit apps (settings for Visual Studio live here).

What to do now? This is why PowerShell installs the x86 version of itself along side the 64-bit version. This was the first time that I realized the need for the  x86 version. At first I thought it was for those peeps that just couldn’t let go to 32-bit land. I guess not.

Ahhhh… all better now.

-

If you enjoyed reading this little piece, please feel free to subscribe to future ones via rss.

Leave a Comment » | powershell, tools | Permalink
Posted by Scott Saad

« Previous Entries