Cerebral Critical

•February 20, 2010 • Leave a Comment

In this industry, it seems that the one way to get noticed is to be critical and negative of what others are creating. I fail to fully understand the reasons for this but continually witness it through the various pipelines of the Internet.

I wonder if it’s just the times where people feel more free than ever before to speak their mind? It seems that common sense morals of treating people nice are dwindling. It’s open season and you better watch what you create or what technology you use as the super critical that have an opinion about everything are alive and thriving, and looking to get some attention.

Why so negative? It’s so draining, and really… what purpose does it serve? It’s one thing to criticize, but it’s just sad to do so in a manner that is reminiscent of a 5-year-old child telling you she doesn’t like you. The child would say something different if she was developmentally advanced enough to translate her feelings into words other than “I hate you, because you’re stupid!”

So, as engineers, great thinkers, amazing problem solvers, etc… it seems ridiculous for us to flap off at the mouth and share our negative thoughts about product X or technology Y or thingy Z. If you really must have an opinion that’s worth sharing then do so in a manner that is respectable. Hold back if there is any question because chances are it’s just another tantrum that you’re experiencing, and your reactions are purely selfish in hopes of drawing attention to yourself.

Please spare us next time. Don’t worry, even when you’re nice people will still think you’re cool and follow-worthy.

New SSRS PowerShell Provider

•November 6, 2009 • Leave a Comment

Introduction

A lot of the code that gets written for any software project can end up being for the supporting systems surrounding the end product. This can include build systems, tests, installers, deployment tools, etc. I’ve found that some of the greatest explorations in learning can be found by writing these systems. One gets to learn potentially new technologies and be a little more experiential with how they approach the problems. To me, some of my favorite projects have been for the supporting systems. One of those recent projects gave me the opportunity to dive a bit deeper into PowerShell.

History

This actually all started years ago when we wanted to find a good way to deploy SSRS reports during part of our one-click build and deploy system, powered by NAnt. We ended up writing a custom NAnt task which worked very well. It could take a source directory tree and pretty much replicate it to SSRS, all using the web service. It ended up being a very efficient, low impact way to deploy reports and resources. We were able to also use this little NAnt gem to deploy reports on a real customer install. Albeit we had to distribute a trimmed NAnt system in our deploy package. This worked for a while but we soon outgrew what the system could provide in a reasonable manner.

The biggest downside is that our NAnt task was pretty much an all or nothing deploy. There was no in between. Plus, being an XML build system, if we wanted to change any aspect of the deploy it required editing the NAnt project file. We therefore turned to PowerShell to help us accomplish this.

Solution

We’ve created (and are using internally) a full blown PowerShell Provider to help us accomplish this task:

In performing administrative tasks, the user may need to examine data stored in a data store (for example, the file system, the Windows Registry, or a certificate store). To make these operations easier, Windows PowerShell defines a module called a Windows PowerShell provider that can be used to access a specific data store, such as the Windows Registry. Each provider supports a set of related cmdlets to give the user a symmetrical view of the data in the store.

As you can see a provider fits the bill perfectly and the solution ends up being super dynamic as it currently allows for the following operations on SSRS:

  • list items on a report server
  • navigate the report server structure
  • create/delete reports
  • create/delete folders
  • create/delete data sources
  • create/delete resources

With this in place one can either script the deployment or wrap it up in a pretty GUI front-end by using a Runspace in your favorite .NET language.

Open Source

All of this has been placed on CodePlex under the SSRS PowerShell Provider (ssrsposh) project and is available for the all. It has served our immediate purpose and hopefully it will serve others. If not, my hope is for it to continue to evolve to meet those needs of others.

More to come in the future.

For the love of your users!?!

•September 3, 2009 • 2 Comments

This is supposed to be something good right?

C++Builder 2010 is by far the best release for upgrading existing projects. I was able to open over 110 projects in an external editor, perform some text replacements via a macro for 3rd party runtimes, and rebuild all. And do it fast.

This is taken straight from the official What People Are Saying page on Embarcadero’s (once CodeGear… once Borland) about RAD Studio 2010. Seriously? As one might deduct from this statement, it is not a pleasant experience for the existing users to perform their project upgrades to the latest version of RAD Studio. However, I’ve learned that very little change can happen by being a prick about everything. Therefore, in the spirit of trying to stay positive, let’s approach this in a diplomatic way.

Upgrades are great and all, but I don’t have the luxury of our software ALWAYS building on the freshest version of development tools. At the same time, I don’t let the environments get too stale. Within the last few months, I took the upgrade from RAD Studio 2007 to 2009. It’s always exciting to get on the latest version of the software to see what new features, speed improvements, etc. are available. Part of the reason behind not going to the 2009 version sooner was because of the long, drawn out process I went through with the 2006 to 2007 version. As with most IDE’s when a new version comes out, there is inevitable changes to the project files. This proved to be the pain point I had faith that the experience must have gotten better and that the 2009 upgrade would be a breeze. Unfortunately, this was not the case.

For customers that pay the hefty maintenance price (approx $6K/year for us), the experience and pain to upgrade projects is atrocious. Especially when expectations are being set by having an automatic project upgrade feature in the IDE (which most IDE’s have as well). Oh sure, I open the 2007 version of the project file and the IDE automatically converts it to 2009 but nothing builds! In order to get things working, some TLC and pixie dust is required.

While I won’t go into details, I’ll just say that the experience was tedious and very much like the person described in the quote above. One HAS to actually create scripts to properly modify the project files in a predictable and repeatable pattern. If you didn’t you risk a great deal more doing it manually, by hand or through the IDE. We never get it right the first time and being able to back out a project change, modify the script and try again saves so much time in the end. Without a script or some type of automation, the amount of work to upgrade the project files is directly proportional to the number of project files! This begs the question, why not make this experience better and built in to the software. If a user can script it out, why can’t the people that make the software and dictate the new project file requirements?

As with any software company, priorities get set to work on certain features and the input usually comes from a variety of sources:

  • Marketing and sales for the new potential users
  • The request from existing users of the software
  • Internal engineering input on refactoring and bug fixes.
  • Etc.

I have a hard time believing that the existing users of the RAD Studio product line have not complained about the project upgrade process between versions. One would think they’ve experienced the same sort of things I have. There is a reason for everything so the fact that it has not been addressed is a logical one.

  • Maybe it’s not painful enough yet for the existing user base to yell.
  • Maybe it’s very painful but the existing user base is not yelling loud enough.
  • Maybe there is no friendly way to acquire feedback from the existing user base.
  • Maybe the existing way of acquiring feedback is not effective.
  • Maybe the existing user base has given up because they’re just used to second class treatment (hope not)?
  • Maybe the existing user base that is giving feedback only represents a small percentage of the total.

These are hard questions and only the software maker truly has a shot at answering them (or asking new questions all together). What I do know is that as an existing user I find it frustrating when a blog post comes out talking about how the MOST requested feature that made it into the 2010 release is a complete rework of the the Class Explorer. Are we serious here? The Class Explorer was at the top of the list? This doesn’t make sense! Isn’t there better things to work on than investing in a complete rewrite of a small IDE feature? Do people actually use this kind of thing anymore (or ever)? Well, according to the existing users that that are giving feedback, the answer is yes.

To me, this seems like a feature that was played with when RAD tools started going mainstream (circa 1990’s?). A cool idea that somebody thought would help illustrate this new idea of a RAD environment, by visually displaying the class structure of the file being edited. I don’t use this feature and cannot see myself ever doing so. For me, there has never been a substitute for actually reading code in an editor. That’s just me though, and I’m a small percentage of the existing user base.

In all honesty I could be at one extreme of the user base, while the majority use the class explorer to navigate their code. Coming from a Unix/Linux background this may just be my preference. Who knows. It just illustrates why being in touch with as many different types of users when getting feedback for future development is so important.

Unfortunately, every new release of the RAD Studio product line that I’ve experienced ends up taking down 1-2 weeks of time to perform the project upgrades. In my opinion this type of work is an unnecessary waste.

Please make it stop for the love of your users!

The last few have hurt so bad that I truly question whether the upgrade is worth it or not. I always end up convincing myself that it is worth because that’s the programmer geek in me who cannot resist the new stuff. Please don’t use this against the users.

The fact that an upgrade can be scripted out via regular expression search and replace is not a feature, but a shame.

Taking Tweets to the Grave

•August 19, 2009 • Leave a Comment

Recently, there has been an increase in many Twitter users to have a way at getting back to their old tweets. Apparently, one is currently only able to get back to their 3200 most recent tweets. A problem I don’t yet face, but probably will at some point. Because of this there seem to be services popping up to help those approaching or encroaching on the limit. Sites like, BackupMyTweets, allow one to start archiving the old tweets. For me, one question starts to arise when I hear about this.

Why?

It’s probably just me, but I don’t find my tweets that useful. Sure, I crack myself up sometimes and get to interact with some pretty cool people, but I’m struggling to find the need to relive them. I’m speaking for myself as I know others use Twitter much more intensely that I ever have or will. Some, to the point that it helps them do their job better. Maybe being able to get as these old tweets helps in some way? I’m sure there are reasons that I just don’t understand yet.

To me, this is one of the unique things about Twitter that so many other service miss. Twitter is lightweight. One is allowed to post anything up there, from multiple mediums, about anything the heart desires. This is a benefit! Who cares if anyone (including myself) ever sees it again? The whole fact that they don’t hold on to ALL of our precious tweets is right in line with the service. Short and sweet.

Maybe it’s another one of those things that as we use it more and more we get more attached to it. With this attachment, grows the feeling that there’s more meaning to it. Maybe because we’ve spent so much time on this service… hours and hours of tweeting… that it would be a shame if ALL of that work goes to the bit bucket.

When the ultimate bit bucket calls your name will you be taking your tweets with you? Maybe they’ll help me on the other side… somehow.

Mashup: Key Blobs, Win32 CryptoAPI and .NET

•December 30, 2008 • 5 Comments

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.

Time Well Spent

•December 20, 2008 • Leave a Comment

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.

IRC and Distributed Teams

•October 6, 2008 • 5 Comments

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!

Keeping it Sharpened (part 1)

•August 20, 2008 • Leave a Comment

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.

A Visual Studio (.NET) Developer Dilemma

•August 13, 2008 • Leave a Comment

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.

Mojave OS is sweet!

•July 30, 2008 • Leave a Comment

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!