Friday, 20 December 2013

Custom Career Development

Far too often in my life, it seems the lessons I learn, once repeated, end up being cliches. I sit there going "Man, I have learned so much and all I'm doing now is repeating age-old sayings that I and everyone around me has heard a million times", and I wonder why it was so hard to figure out in the first place...

Anyway, I'm learning one right now. It's "be yourself". I never really thought about the power of being myself when it came to my career. Yeah, I have a personality and I contribute to a team, but far too often I tailor my skills against my job description or the required experience for a job. However, if I take a cookie-cutter approach, I will live a cookie-cutter life, and that's not for me. Might be for others, but not for me.

I found myself in a conversation with someone senior to me in my field. I asked him "what do I need to do to get the position I am looking for?", and he responded "be yourself". Right. OK. I tried again: "What skills should I have?". His response? "The ones you want to have". Right back where we were. I didn't need to ask again, I knew what his answer would be. So I stopped, thought about it, and couldn't grasp it. So I asked him to explain.

He told me that the most important thing to becoming a leader is to play on the strengths I have, the strengths I build when I play. Those strengths will get me where I want to be. Far too often, I have "been myself" within the confines of a particular box. As I go forward, I need to tear down that box and be the person I want to be, not who I think I should be. Once I do that, I create a situation where it's possible for someone to take my strengths and skills, which I am strong at and passionate about, and turn those into a position.

So if a company has 2 people to lead a division, and those people are themselves, you would end up with two very different divisions, even though the core offering of those divisions are similar. One might be aggressive and pivot quickly, while the other takes the slow and steady road to building an unstoppable force. You might have one division run with a sense of togetherness, and another run with a competitive streak. It sounds like chaos, but you strong divisions that run on the people that lead them. They operate in the realm of reality because that's where we live, not in the world of theory and "looks good on paper". That's the upside. All that's left to do is manage any interactions and you're golden. It's not easy, but it's effective.

So when you're trying to move up the ladder, my advice is to just be yourself. If you just be yourself, you will have a job you love and people will love you being in that job.

Tuesday, 17 December 2013

Opening Files Your Way

Introduction

I was having problems with opening scripts. At first, I couldn't associate the .sql file with SSMS at all. Once I was able to open the file in SSMS, I found that each script opened in a new window, and I wanted them to open in the same window.

So I played around a bit, and here's what I found to fix it. None of this is official, just what I found to work and my theory behind it.

Investigation

So when I open a file of any type, my registry is checked to see what command to use to open that file. The keys are all stored in the HKCR (HKEY_CLASSES_ROOT) hive. If I was to open up the registry editor  and expand that hive, I would find all the file associations I have. In my case here, I opened ".sql" to find that the (Default) value was set to "sql_auto_file". Other people had other values, but it doesn't matter. It turns out that this value, when set, corresponds to another key within the HKCR hive that provides information on how to open the file.

So I opened that key up to find only a sub-key called "shell" with its own sub-key called "open". Within "open", there was only an empty (Default) value. That's why it wasn't working. It wasn't associated with anything. I examined some of the other keys in the hive and copied the approach they took. I set the (Default) value to be " "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\ssms.exe" "%1" ", according to the SSMS command-line arguments. Now, when I double-clicked my .sql file, it opened my file in SSMS. Yay!

But when I had an instance of SSMS already open, it would open any additional files in new windows. Not good enough.

So I started doing some research. People were talking about the "/dde" switch. I added it, but it didn't change anything. Files were still opening in new windows.

So I started researching what some other people were posting as the keys to message boards. Some of them had a key under "Open" called "ddeexec". I replicated the keys they were posting, creating the same keys on my end. It meant creating a sub-key under "Open" called "ddeexec", with two sub-keys called "Application" and "Topic". The (Default) key for "Application" was set to "ssms.11.0" and the one for "Topic" was set to "system".

Now, when I used the "/dde" switch with these new keys, the scripts opened in an already open window if there was one available! As it turns out, the window must already be open or it will create it. If I wanted to open several files at once, I had to make sure a window was already open. Makes sense. If it runs these commands at the same time, each one won't open in time to tell the next file there's already one open. I'm not sure if there's a fix for this.

I figure that this means that the "/dde" switch asks program to look at the "ddeexec" key and follow instructions there...

I noticed that under some of the keys, there was an additional key beside "Open" called "edit". Sometimes, when I right-click a file, I can see "edit" as a context-menu option. In the registry, this key had the same structure as "open". It turns out that you can specify a different program for editing than opening. Neat! So I decided to add my own key beside "Open", called "Edit In New Window". I created the sub-key "Command", and used the value from my previous values, but without the "/dde" switch. Now, when I right-clicked my .sql file, there was a new command: "Edit In New Window"! When I clicked it, it opened in a new window. I realized that I could add several different associations, each named as I wished. So cool :)

Key Structure

Here's the structure of my key:

  • HKCR\.sql
    • (Default) value = Key to look at when opening file
  • HKCR\<value from above>
    • \Shell
      • \Open
        • \Command
          • (Default) value = command to open file (%1 represents file path)
        • \ddeexec
          • Application
            • (Default) value = version of SSMS
          • Topic
            • (Default) value = "system"
      • \Edit
        • Same structure as "Open"
      • \<your custom name here>
        • Same structure as "Open"
There you go. Use that to repair how SSMS opens your files, and customize your context-menu entries :)

Possibilities

This can be used several ways. Some possibilities:

  • Open SQL scripts connected to a specific SQL server instance
  • Create short-cuts for opening files in multiple programs
  • Link to scripts to run multiple commands for a single file
  • Use complex move or copy commands with a single click

Monday, 15 July 2013

Tools for Enterprise Big Data, July 2013

Here is a list of tools and services I think is important to share that aren't on-premise, but instead harness the power of cloud computing:

Data Warehouse

Amazon RedShift- RedShift is a new service of Amazon's, built on the ParAccel stack, to help you build and scale your enterprise data warehouse (EDW) as quickly as possible, and touts a price of $1k/TB
Actian - An integrated solution that lets you store all sorts of information, and create triggers based on external data (including social media) to respond quickly to events
Treasure Data - Hadoop-based EDW
Teradata - Offers Hadoop and non-Hadoop EDW services

It should be noted that Hadoop isn't necessarily a better EDW. A great explanation of the differences can be found on the Teradata website

BI Tools

Jaspersoft
MicroStrategy
Pentaho
Tableau



Enjoy!

Tuesday, 21 May 2013

Project Zen

If you've read my previous posts, you would know I started off my career as the standard developer:

"I like to code, I like new technology, I have a weird fear of documentation and I do everything in my power to avoid the politics of management"

The first few projects I was on were awesome. I was learning so much! Over time, I become more aware of the various properties a project had, and learned to place a project on a spectrum of good/bad:

"I get to use the latest technology? I love that, so let's nudge the needle to the "good" side, please! Oh, but I have a complex, 30 page requirements document I have to follow? I hate documents, so we'd better put the needle back where it came from..."

Most developers I have talked to do this, and it's normal. Nothing wrong with it, just the way it is. I do the exact same thing myself.

...Except, I'm trying to become a consultant. Now and then, I may be somewhat dissatisfied with the nature of a project but if I want to complete my transition from developer to consultant, I must learn to work on any project, in any environment to do my best work.

The Process

Let's examine the process a bit. When evaluating a project, I collect information about it. Each piece of information becomes a property used to describe that project ("VB6 app", "agile", "highly contentious"), and then pass those properties through a filter where I determine how to feel about them ("boring", "easy", "honorable"). I weigh the values I get and assign a blended score that I assign ("good", "bad).

When the client asks "what's it going to be like to add some extra functionality?", I bring all those feelings and opinions to the table. Sometimes, who does the work tends to determine the solution, since I might try to minimize the amount of time I have to spend with VB6.

The Real Issue

So what's at issue here? The issue is that I'm making this about me when it's really not. I'm not paid to hold opinions based on personal beliefs and desires. In fact, I'm paid not to. Objectivity is why a company brings in consultants. By holding personal beliefs about a project, you are, by definition, violating that objectivity.

What If?

What if we instead, when evaluating a project, stopped right before we passed the properties through our filter. Isn't the project in a much more "real" form? Aren't the properties more objective?

What if we listened to those properties? What if we inferred knowledge about the client from the project? What if the fact that the project is in VB6 means something about the organization? What if we made that a statement about the people themselves?

What if we passed those properties through a filter, but not one of our own making? What if we painted every property as "valuable", or "necessary"? What does that say about the organization now? What does it say about the people?

Project Statements

If we can modify our evaluation process, playing with the filters we put a project through, it really becomes something new...

I feel this has gotten a little too rhetorical, so I will state some opinions on this matter, ignoring the irony therein:

  • A project isn't good or bad. A project is. 
  • A project exists because it results in a net increase in value. If it did not, it would not exist. 
  • A project has the attributes it does because those attributes are the ones that serve the organization best. 
  • A project is a mirror of the organization and the people that make it up
Bringing It Home

So how does this relate back to my satisfaction? Quite simply, it's important to not judge the project or the organization, but instead realize that you are in the position you are because you are an observer to the problem. If you want to truly help an organization, you must be able to see past your own thoughts and see the problem you are trying to solve as it exists in reality, which includes how it fits within the organization. Once you do this, you are better equipped to provide help. Helping the client in a more real way is, so far, the best way I have found to bring satisfaction to my life. Help them, help yourself.

Thursday, 7 March 2013

What I've Learned From Corporate IT Consulting

Background

I hesitate to call myself a consultant, because really, I don't do much consulting. Most of what I do is coding. Instead of doing it in an office for my company, I do it in a client office for a client. I only call myself a consultant because every once in a while someone will come to me and ask me what I think we should do, and I give them an opinion. Also, my company told me I was a consultant. Since I like having a job, I figured it would be prudent to just go with it.

My current company is a consulting firm. They cater to "enterprise" clients, which really means big companies. Oil and gas is big in Alberta, so anyone that services that sector is also pretty big, like construction. And since everyone needs services, there's also government and various other things.

I've been doing this for just shy of 3 years. Before this, I worked for a year in an IT department of a remanufacturing plant as a co-op student during the summer break of my diploma and the last year of my school. I was attracted to my current job because I wanted to make sure my skills stayed current, and it's hard to do that when you work in a company that doesn't focus completely on IT. The company was also very young, and being there while a company grows has benefits. Because it was so young, it was also very small, and I prefer to work with a fewer people that are of a higher caliber than to work with lots of people.

I started working for my company with the title "Solutions Developer", coding stuff for clients. I would leave the office very rarely. As the client list grew, however, so did the size of the clients. They started requiring that we be on-site, so I was sent out. Over time, it became obvious that client-site work was going to be impossible to avoid. Instead of risking my job trying to fight it, I just chose to embrace it and start educating myself on consulting as well as technical stuff.

Lessons Learned

So now that you have a brief idea of how I got here, I believe you have the necessary context to understand where I'm coming from for the rest of the post. I am going to assume that you are familiar with the job of a developer. If you aren't, then someone else's blog is probably the best place to find a breakdown of what that's like. I wanted to bring a consultant's perspective, since I believe it's very under-reported.

So what have I learned? Very few things are either good or bad. They are what they are, and you must decide for yourself. Here's the list:


  • New things - Your world will constantly be changing. You will be exposed to new things all the time. It may be hard to handle such constant change, but at least it's constant, so you can rely on that... You won't really have to deal with a problem for more than a couple months at a time, but you will also not be able to settle down and enjoy any benefits for too long. The best thing about this part is that you will get experience with both, and more, over the course of your career. You will see awesome solutions to problems and be able to take those to other companies. Probably the ultimate benefit of this point (for me, at least) is the chance to see past the individual attributes of a company and see the roots. Every company is like a person, with its own personality, likes, and dislikes. It's seeing those characteristics that make a consultant so valuable. It just takes time.
  • Change is slow - Change takes (what seems like) forever in an enterprise. I have come to believe that if change is quick, something is wrong (or soon will be). Large groups of people need time to adjust properly. Working in an enterprise presents a chance to chill out, since there is only so much change an organization should make within a certain time period. It also means that not every idea, even the good ones, will be implemented. It can be tough to sit idly by while good opportunities pass by, but it's for the best. Every company must choose which opportunities to grab. So sit back and take it easy. There's very few times I've been called on to work overtime, which means I arrive and leave at the same time. So use the in-between times to prepare for the next move, or learn something new. I prefer to read a company's manuals and other training material to absorb the knowledge they offer. Just remember to respect any NDAs ;)
  • Clients aren't friends - Clients don't really see you in the best light. You really have to earn trust, especially the trust of the employees. Managers see your credentials and have chosen you based on your skills, which means they already trust you enough to hire you, but employees see you differently. Most of them probably don't understand your value, and see you as an omen of change (which most people resist), as well as the guy who makes solutions and then leaves them to maintain it. So be prepared to be disliked. You will get a chance to hone your ability to win people over quickly as you move from engagement to engagement, but it's going to be a constant effort. Once you can get into the good graces of the crowd, things get easier. It just takes time and practice. Also be sure that you are making friends outside of work. A lot of developers tend to make friends through work, and being at client sites means you can't rely on the employees for socialization. Over time, however, you will build a network of people you keep in contact with. It's just not as seamless compared to being a developer.
  • Deep knowledge is key - Keeping your skills up-to-date is key, but it's hard to invest in a specific skill-set when you are constantly moving around. Becoming valued as a specialist takes time, too. So it's important to study the concepts behind technologies. Yes, you should also be aware of specific technologies and what they can do, but a lot of your time will be spent learning background info. This has the side effect of making you look like an idiot to some people, as you become a generalist. It will become harder to explain your job, and any attempt doesn't work that well. You must motivate yourself to learn, or you will find yourself without work. Still, it's a great way to keep your skills up to date.
  • Strangers are good for work ethic - Your typical office isn't a labor camp. There's always time to fool around and take informal breaks to relax your mind. Today's developers are creative and need time away from the keyboard to recharge the juices. It's easy, however, to forget the time and goof off for an hour, which also makes it really hard to get back to work. Being forced to sit down and code under the eyes of budget-conscious managers and judging employees is a great way to develop the ability and desire to sit down and work for hours on end. It's a skill that takes practice. That level of work ethic isn't cultivated in every organization, but will be valuable in all of them. It's also essential when you want to 
As you can see, consulting is very different from being a developer. Corporate consulting even more so. I hope you got an idea of what a consultant's life is, and saw what it offers compared to a developer position.

Tuesday, 26 June 2012

Binding To Event At Runtime In Windows 8 Metro

So I wanted to use the MVVM pattern in Win8 Metro WPF, but was without the classes and functionality I would use in WPF4. So I decided to create my own, but I got the error:

Adding or removing event handlers dynamically is not supported on WinRT events.

I found a blog post on the MSDN where some guy posted about using the WindowsRuntimeMarshal to get around that, but he didn't post a code sample. So, I decided to figure it out, and let everyone know!

So here's the code:

var eventName = "Click";
var myButton = new Button();
var runtimeEvent = myButton.GetType().GetRuntimeEvent(eventName);
var handlerType = runtimeEvent.EventHandlerType;
Func<RoutedEventHandler, EventRegistrationToken> add = (a) => { return (EventRegistrationToken)runtimeEvent.AddMethod.Invoke(myButton, new object[] { a }); };
Action<EventRegistrationToken> remove = (a) => { runtimeEvent.RemoveMethod.Invoke(runtimeEvent, new object[] { a }); };
RoutedEventHandler handler = (a, b) => Command.Execute(b);
WindowsRuntimeMarshal.AddEventHandler<RoutedEventHandler>(add, remove, handler);

So that's how we can add an event handler to an event at runtime in WinRT. Pretty simple, really. The one limitation of this code is that if you are trying to bind to an event that isn't a RoutedEvent, you're going to have to re-do the code. But I'm sure this is able to become a generic function with a little bit more work.