Active Coder

My thoughts about staying active as a husband, parent, and generalist while keeping skills current and creating great software

52 Tools: WebSequenceDiagrams

WebSequenceDiagrams is a site for generating UML sequence diagrams using a mini scripting language.

For example, this:

participant Sync\nService as SS  
participant Authorization\nService as AS  
participant Resource\nService as RS

activate SS  
activate AS  
SS->+AS: [1] Request Authorization with X.509 Certificate  
AS-->-SS: [2] Return Token  
deactivate AS

SS->+RS: [3] Request encrypted data using token  
RS-->-SS: [4] Return encrypted data

deactivate SS  

Gives you this:

Super cool, and no silly Visio hijinks like this one (Animated GIF):

52 Tools: Devolutions Remote Desktop Manager

Remote Desktop Manager is another entry in what's turned out to be a series of remote desktop management tools. This type of tool is proving critical for me to be able to maintain multiple lab and testing environments, which is becoming more of a priority as Hubstream grows.

The winner in this fight (for now) is Remote Desktop Manager, a paid product ($99 US) that does some new things compared to RDCman and mRemoteNG:

  1. Integrates with password manager tools (standalone encrypted files as well as onlin services). We have a need as a team to share credentials to various web sites, services and remote desktop sessions. By keeping that process separate from the RDP list, we don't have to keep two separate credentials lists such as if we used RDCMan exclusively. The flexibility in this area gives me some confidence that if we change password management suites, I can keep my connection database and remap the credentials.

  2. Scales awesomely at different resolutions, multi-monitor, etc. This one is great at even if I switch to a smaller monitor, the screen resizes in a usable way. If I reconnect, I get that monitor's native resolution.

  3. Lets you encrypt and password protect the connections database. This makes me slightly more confident storing the file on shared cloud storage. In the next version, there will be two-factor authentication for which I'm hoping to use my YubiKey.

52 Tools: mRemoteNG

mRemoteNG is a multi-remote desktop client that works on High DPI monitors and across different screen resolutions. This is a must-have feature for which RDCMan fails horribly.

Lessons from the software field

A friend posted this prompt on Facebook and I thought I'd repond here.

  • How would you counsel the next generation about your chosen profession? Any regrets? Surprises? Unexpected perks? What do you wish you had known then that you know now?

I'm in the computer software field. My career has been an amalgamation of a software developer and a technical consultant. I love my role, and I'm at the pinnacle of my career because I've been blessed to have the right blend of customer and technical focus that works for me and my family.

It's a broad set of overlapping career choices, so I'll speak to my part as an individual contributor who helps make software as well as talk to customers to integrate ideas and resolve their issues. First, I'd offer some advice about considering this career. Consider software development and related consulting work if:

  • You have some perspective on how things should be done. Or you see that technology doesn't work the way you think it should. The world needs more diversity of thought in this field. For instance, "the data prove(s)" that technology fields need more women.
  • Even if you don't have the big ideas yet, or if you don't feel like you have a unique perspective (although you do...), think about a software career if this is how you want to make a difference. Know that every organization has Information Technology needs, so skills in this area can help you make inroads into non-profit or government work, or working with various other causes that are important to you. It can also make you a lot of money, if that's important to you. Also know that most of these organizations are underserved, and that even basic things like providing new simple data insights or collaboration capability can be completely revolutionary. Allowing people to focus on interesting problems rather than the mundane tasks such as data processing is really satisfying.
  • You like to tinker and have fun making things. Or you like to pick things apart and understand them. There's lots of analysis in this field.
  • You research and bring in others' ideas.
  • You love working by yourself and with little direction.
  • You're able to clearly and effectively communicate your thoughts and ideas, and aren't afraid to speak up when you sense a poor direction.

If you're starting in the field, here's some advice:

  • Learn the basics. Javascript and some other programming language. It's cool to know some buzzwords but if you can't create something interesting from nothing, you'll miss out on a lot of background knowledge will help you diagnose issues. And there will always be issues.
  • Come up with a side project and do it. Anything, really. Just build something. In my teens, I created a running log program that I evolved over years and had hundreds of users. It taught me about customer feedback and deploying updates and deconstructing a large system into smaller bits. Nowadays, this could be a mobile app or a web site or something from the maker movement. Heck, something cool in Minecraft (or older, Second Life) could prove to be valuable time spent.

Some surprises I've run into:

  • Deploying and making software work for customers (which is what pays the bills) is insanely more difficult than writing a novel bit of code or interface in a lab. It's slightly less fun, but in the end it's what matters. You learn by shipping. That isn't to say that you shouldn't create the novel bit of code or interface, but be as considerate of the folks who need to make it work (if it's not you) as the customer using the feature.
  • Nobody can really define roles in this field. In college, I always hoped somebody would tell me what a consultant and software developer do differently. Where the line was between the test team and the development team. What tasks I'd actually be doing. These things are all muddied, although larger companies try to separate it out a bit more. The point is that you have to be passionate about creating interesting and usable products, and not be completely married to only working on the new or exciting front edge efforts. I've seen large test teams, and huge consulting efforts focused on quality delivery, but in the end everyone (including customers, sometimes reluctantly) needs to help validate the system in order to create anything with viability or traction.

I'd consider travel and ongoing training to be unexpected perks. Depending on the role and your preferences, traveling to customers and improving skills are both things that make development consultants more effective, so companies tend to allow and focus on these things. My experience may not be typical, but I had my grad school paid for, and get to travel around the world to set up and deploy my company's technologies. Very cool.

Finally, there are a few things I wish I'd known in my teens and 20's that I have since learned about this field:

  • Much of this work is dependent on personal information management. So, choose some "sticky" tools to organize your notes, snippets of code, and full code solutions. By this I mean devise a system that you can stick with over numerous years. It's quite often that I remember something I did years ago, and wish I had that old code. Of course, NDAs and customer agreements may preclude doing this in some cases. If this is so, seek out solutions within your employer or customer environments. Something simple like a file share, SharePoint site, or common OneNote notebook. Beware that when you leave all of these things will probably be deleted forever, so if you want to pass them on, do it via another means first.
  • Your boss may not fully appreciate you unless you can communicate your value. This is incongruent with the tasks being performed because this is an extraverted (salesman-like) task rather than a deep introverted technical task, so I've found this to be difficult. So, get used to explaining your projects to others. Talk about your approach and your thought process. I wish I had done more of this in college rather than focusing as much on delivered solutions.
  • Using external dependencies you don't understand, or before they are needed, is a really bad idea. I'm a big fan of incorporating other's work for algorithmic things and for aspects of software projects like user interface "widgets" that serve a particular goal. When it comes to some of the more generic tasks required of software development, it can be tempting to keep tacking on more and more libraries and dependencies that fit your needs or to plan for future expansion. If there's an issue, this makes tracking it down much more difficult. If you get into a large or complex system, knowing why your data grid doesn't display the time formatted properly is much harder if you don't understand how the data grid got displayed. Case in point, I worked on a really neat project in college for Microsoft's Imagine Cup competition. It was a web-based code compiler and testing engine. I spent literally weeks of my time implementing a Microsoft library to display a wizard-like interface on the web, and this was distracting from the core features of the platform. The key reason for this delay is that I didn't understand it and when I understood it well enough to use it, I found it was the wrong tool for the job. In retrospect, I should have focused on delivering the simple solution and iterating on it, rather than doing this deep novel library integration.

52 Tools: Tools for working with icons in Paint .NET

I've found BoltBait's plugin pack and Evan Olds' Icon plugin valuable for working with ICO files. I didn't know that the file format supports different pixel densities, so ours is now rocking all different scales. Took a while to figure out how to make it scale down OK to 16x16.