I was tooling around with some encryption code, trying to learn a bit more about the .NET encryption APIs, and it occurred to me that some of the documentation for the general usage of CryptoStream was a little bit confusing. I am referring to the "direction" of the stream, and what the actual effect of the CryptoStreamMode instance is in the constructor.
The reason for my initial confusion was the EncryptTextToFile and DecryptTextFromFile methods the documentation uses in its sample. These methods kind of make it look as if you should use CryptoStreamMode.Read if you are doing decryption, and CryptoStreamMode.Write if you are doing encryption. This is not the case - you are free to use either direction no matter what kind of transformation you are applying.
My confusion probably originated from my one-track mind when it comes to streams: In all my experience with BizTalk pipeline components, I don't do a whole lot of writing to streams, and so I default to thinking of streams as objects that either access a resource, like the file system or the network, or as machines that apply a transforms as you pull data through them. You can layer these machines like Matryoshka dolls, with the data source at the center, and pull the data all the way out, and what you'll get out is the grand sum of all the transformations applied in order, without necessarily having to get the full result of each transformation in sequence. This is exactly how CryptoStream works in Read mode - the first argument to the constructor is the stream you are wrapping. The second argument, the ICryptoTransform, determines the transformation that the stream applies as you pull the original stream through. Just like any other stream, you can Layer a CryptoStream and return it, and the consumer can use it just like any other stream. Keep in mind, though, that a CryptoStream in Read mode is read-only, and CryptoStreams are never seekable.
A CryptoStream in write mode works the other way: with the first argument to the constructor, you define the stream that goes inside of it. When you write to the CryptoStream, the result of the transform gets pushed to the underlying stream.
So which direction is preferable? It depends on the shape of the information you're putting in and getting out. If your input is not a stream, and is instead something like a string or a byte array that you know the length of, Write is probably a simpler option, because you can just write your data directly to it. If you're dealing with streams, Read is likely easier.
Just like every other kind of stream, don't forget to flush your CryptoStream. CryptoStream does have one twiddly bit about it - Flush is a no-op. For whatever reason, the important flushing method in CryptoStream is FlushFinalBlock. The documentation does a good job of hammering it home that you can call Close to make sure this gets done, but calling Dispose does it as well, which is good to know because "using" statements are generally preferable where applicable.
One more important bit that's easy to overlook - while you may be able to determine the length of a CryptoStream you are reading from at runtime, the length of the CryptoStream is not necessarily the size of the data you will get out of it, because it's transforming the data as it zips through. This goes for all streams - don't be lazy, and don't use the length of a stream to set the size of a byte array you're going to store the data in!
Wednesday, March 24, 2010
Tuesday, March 23, 2010
Publishing
I remember a few times throughout my childhood when a teacher would extol the virtues of writing for oneself. Whether it was taking notes, doodling, "mind-mapping," creating notecards from individual ideas, or simply writing down all the ideas that came into your head, there were always a few key messages:
Publish.
The goal I'm most excited to pursue over the next few months is a "documentation strategy" I'm going to assemble and present to my team. It's goal, in short, is to supplement the lifeless, monolithic spec templates we use here and encourage easy, simple and succinct publishing with a minimalist template. The focus is on publishing as opposed to writing because the benefits of having easily editable documents to collaborate over and record decisions and ideas are just too numerous to ignore.
It's not going to be easy - I need to develop and sell a strategy that isn't too "open" (I can't just tell my teammates to write clearer, more succinct documents without delivering something that they can use, like samples and templates) and isn't too "closed" (introducing another monolithic template and more hard rules defeats the point), all while convincing everyone that what looks like more work actually results in better quality with less effort. I have a whole lot of ideas and there are a few specific ones that a few specific, important people want to see, and so I need to make sure those get a good treatment as well.
I'm not going to get into heavy details in this post, but I am going to be writing about this more as I put this strategy together and figure out how to make it work for my team. Actually, one of the primary reasons I want to continue to write about this and show my work in progress is one of the reasons I want to introduce a strategy like this in the first place - it leads to greater collaboration and higher quality work. These two fellows from Google have some great insights about collaboration and showing your work to others, and how it leads to better quality work, faster. They talk about it in the context of version control systems, but these ideas outline one place I want to go to with this idea.
- You don't have to worry about remembering it anymore. A related Chinese proverb is, "the weakest ink is better than the strongest memory."
- Once you get your thoughts down, you can physically/visually rearrange them to fit your goal (remembering them, making sense of them, etc.)
- Writing down your thoughts helps you to find gaps in your reasoning or explanations, reinforce your opinions, and clarify your message.
Publish.
The goal I'm most excited to pursue over the next few months is a "documentation strategy" I'm going to assemble and present to my team. It's goal, in short, is to supplement the lifeless, monolithic spec templates we use here and encourage easy, simple and succinct publishing with a minimalist template. The focus is on publishing as opposed to writing because the benefits of having easily editable documents to collaborate over and record decisions and ideas are just too numerous to ignore.
It's not going to be easy - I need to develop and sell a strategy that isn't too "open" (I can't just tell my teammates to write clearer, more succinct documents without delivering something that they can use, like samples and templates) and isn't too "closed" (introducing another monolithic template and more hard rules defeats the point), all while convincing everyone that what looks like more work actually results in better quality with less effort. I have a whole lot of ideas and there are a few specific ones that a few specific, important people want to see, and so I need to make sure those get a good treatment as well.
I'm not going to get into heavy details in this post, but I am going to be writing about this more as I put this strategy together and figure out how to make it work for my team. Actually, one of the primary reasons I want to continue to write about this and show my work in progress is one of the reasons I want to introduce a strategy like this in the first place - it leads to greater collaboration and higher quality work. These two fellows from Google have some great insights about collaboration and showing your work to others, and how it leads to better quality work, faster. They talk about it in the context of version control systems, but these ideas outline one place I want to go to with this idea.
Monday, March 22, 2010
I Just Don't Have the Time
A small insight that someone shared with me a long time ago, paraphrased:
The concept of "not having enough time" to do something is a non-entity: it literally does not exist. When you tell someone that you don't have enough time to do what they want you to do, what you are telling them is that their task is less important than everything else you are doing. There's nothing inherently wrong with this - I get plenty of requests every day that are less important than what I'm doing, both at work and from friends and loved ones - but there are a couple things you need to think about:
The concept of "not having enough time" to do something is a non-entity: it literally does not exist. When you tell someone that you don't have enough time to do what they want you to do, what you are telling them is that their task is less important than everything else you are doing. There's nothing inherently wrong with this - I get plenty of requests every day that are less important than what I'm doing, both at work and from friends and loved ones - but there are a couple things you need to think about:
- Saying "I don't have the time to do that" means that the request is literally less important than everything else you are doing. Is it really? Can you take just a minute to try to fit it in with everything else going on?
- Most importantly, how would you feel about yourself if you just went ahead and said what you meant, even if you said it as nicely as possible? "Look, I'm really sorry, but your request just isn't important enough for me to get it done today/this week/ever." How would the person with the request feel about you?
IDisposable WCF Services
If you do any searching for the terms IDisposable and WCF together, you're likely to hit a lot of posts about my previous topic. However, last time I was searching for them, I was more interested in whether or not you can make a WCF service disposable.
The answer is yes - if you derive a class you are using as a WCF service implementation from IDisposable, WCF will call Dispose on it for you when the connection is closed.
The answer is yes - if you derive a class you are using as a WCF service implementation from IDisposable, WCF will call Dispose on it for you when the connection is closed.
Closing A WCF Proxy
MSDN has a whole page on why you shouldn't use a using statement to manage the lifetime of a WCF service proxy. Succinctly, closing a WCF proxy actually makes a call to the server to tell it to "hang up", and this action can fail if the server is unreachable. Disposing a WCF proxy closes it. If your proxy gets disposed and closed at the end of a using block and the call to the server fails, the closing brace of your using statement will throw an exception. What's more, if you threw an exception inside the using statement, it disappears, because the failing close/dispose threw its own exception afterwards.
The page gives an example of how to properly handle closing a proxy, but like many MSDN pages, a better answer is given in the Community Content at the end of the page: don't use the using statement, wrap your proxy work in a try, and in the finally block, have another try/catch that tries to close the proxy and aborts instead if the close fails.
The page gives an example of how to properly handle closing a proxy, but like many MSDN pages, a better answer is given in the Community Content at the end of the page: don't use the using statement, wrap your proxy work in a try, and in the finally block, have another try/catch that tries to close the proxy and aborts instead if the close fails.
finally { try { client.Close(); } catch { client.Abort(); } }
Don't forget to catch CommunicationExceptions and TimeoutExceptions before catching any others!
Friday, March 19, 2010
Goals
Where I work, just like most places, we have to set SMART goals for ourselves. Specific, measurable, achievable, results-based and time-bound goals – you know, the kind that you actually have to put some thought into and require you to challenge yourself. I think a lot of people dislike SMART goals and dislike their particular organization’s goal-setting metrics because they have enough work to do already, but if you hunker down and spend a couple hours on it, it can be a pretty rewarding activity that can help you to focus on what’s important to you and set aside things that aren’t.
What I Say I’ll Do vs. What I’m Responsible For – What’s the Difference?
My organization, like many, differentiates between “action plans” and “accountabilities.” That is to say, “what I’m going to do” and “what I’m ultimately responsible for delivering on” are two different things. At first glance, there is a problem here, because those two sound like the same thing. If I'm going to execute activity X, the result is that I executed activity X. If I'm going to publish document Y, the result is that the document is published. So why bother trying to differentiate between my “to-do’s” and my “responsibilities?”
The answer is the unwritten subtext after the word “accountabilities:” “to other people.” The items you are ultimately responsible for are effects or changes that manifest themselves in others. Publishing document Y is my action plan, and my accountability should be that my intended audience for that document should take up or at least consider the process I discuss, install and try out the tools I recommend, implement the pattern I illustrate in their future work, or start a conversation about how to make things better using my ideas as a foundation.
So My Goals Are All About Everyone Else?
Is it scary that your goals are things that hinge on other people; things that you may feel like you don't have full control over? Yes. The reason you set them that way is to encourage yourself to do everything that you can do to make them happen. Before you give the presentation that you want to affect your team, chat with some of them to make sure it’s on target. After you give it, if it wasn't enough, follow up on it. If your document wasn't clear, revise it. Sell it. If you fail, at least you will have a laundry list of everything you did to try to make it work, and that counts for something (you did do everything you could do, didn’t you?). Find your radius of impact and focus your accountabilities on influencing people within that radius – make their work better, make their job easier, raise their efficiency or satisfaction, and expand their minds. Also, make sure you let the people in your radius know that they are a big (possibly the biggest) part of your goals and that you really appreciate their time and feedback, so when you bother them with a request for a follow-up or tell them that the quality bar for the organization can be raised by giving them more work, they don’t get too fed up with you.
On Measurements
Not every accountability has to be "improve this by 5%" or "have 25% of participants do X". Just because your goals need to be measurable doesn't mean you need to set them with pinpoint accuracy, especially if the context doesn't call for it. One of my accountabilities is centered on evangelizing some development strategies not currently located in the worldview of my team and getting them to consider them for future projects, or at least making sure they understand what they are and what tradeoffs are involved so they can make more informed decisions. Is this goal specific, measurable, attainable, relevant and time-bound? Yes, it is all of those things, and with no percentages required. For those asking, “How do you measure it?” It’s pretty simple, really: ask my teammates. We’re all humans and goal-setting is a human process, so there needs to be room in your goals for explanations that go beyond ticking boxes and filling in percentages. If there’s not, there really is something wrong with your organization’s goal-setting processes and metrics.
What If I Really Am Accountable For a “To Do?”
Sometimes, "things I do" will still bleed into my accountabilities, and they can’t all be all about making others great. One place this happened for me is in my personal improvement commitments: I have a lot of accountabilities there about publishing things to my blog. For me, publishing a writeup is proof positive that I have learned and internalized what I have written about (and my boss knows this… or hopefully he does now), and even though I don’t exactly count on a lot of people reading it, I can share it with people in my radius to help them learn, show them what I’m learning, and encourage them to write too. I don't want my accountability to simply be "learn this,” because that’s too vague, and not SMART. So, publishing something here becomes a "proxy accountability:” by doing it, I prove that I have reached my actual goal in a way that meets the SMART criteria, and hopefully affects others in a positive way too.
Thanks to Hard Code for the inspiration. In response to some of the comments there… I don’t really have any comments on the effectiveness of any particular style of goal setting for ranking people in an organization, determining promotions and the like. My intention here was just to discuss how to think about goal-setting in a way that helps me challenge myself, expand my horizons and contribute to my team.
What I Say I’ll Do vs. What I’m Responsible For – What’s the Difference?
My organization, like many, differentiates between “action plans” and “accountabilities.” That is to say, “what I’m going to do” and “what I’m ultimately responsible for delivering on” are two different things. At first glance, there is a problem here, because those two sound like the same thing. If I'm going to execute activity X, the result is that I executed activity X. If I'm going to publish document Y, the result is that the document is published. So why bother trying to differentiate between my “to-do’s” and my “responsibilities?”
The answer is the unwritten subtext after the word “accountabilities:” “to other people.” The items you are ultimately responsible for are effects or changes that manifest themselves in others. Publishing document Y is my action plan, and my accountability should be that my intended audience for that document should take up or at least consider the process I discuss, install and try out the tools I recommend, implement the pattern I illustrate in their future work, or start a conversation about how to make things better using my ideas as a foundation.
So My Goals Are All About Everyone Else?
Is it scary that your goals are things that hinge on other people; things that you may feel like you don't have full control over? Yes. The reason you set them that way is to encourage yourself to do everything that you can do to make them happen. Before you give the presentation that you want to affect your team, chat with some of them to make sure it’s on target. After you give it, if it wasn't enough, follow up on it. If your document wasn't clear, revise it. Sell it. If you fail, at least you will have a laundry list of everything you did to try to make it work, and that counts for something (you did do everything you could do, didn’t you?). Find your radius of impact and focus your accountabilities on influencing people within that radius – make their work better, make their job easier, raise their efficiency or satisfaction, and expand their minds. Also, make sure you let the people in your radius know that they are a big (possibly the biggest) part of your goals and that you really appreciate their time and feedback, so when you bother them with a request for a follow-up or tell them that the quality bar for the organization can be raised by giving them more work, they don’t get too fed up with you.
On Measurements
Not every accountability has to be "improve this by 5%" or "have 25% of participants do X". Just because your goals need to be measurable doesn't mean you need to set them with pinpoint accuracy, especially if the context doesn't call for it. One of my accountabilities is centered on evangelizing some development strategies not currently located in the worldview of my team and getting them to consider them for future projects, or at least making sure they understand what they are and what tradeoffs are involved so they can make more informed decisions. Is this goal specific, measurable, attainable, relevant and time-bound? Yes, it is all of those things, and with no percentages required. For those asking, “How do you measure it?” It’s pretty simple, really: ask my teammates. We’re all humans and goal-setting is a human process, so there needs to be room in your goals for explanations that go beyond ticking boxes and filling in percentages. If there’s not, there really is something wrong with your organization’s goal-setting processes and metrics.
What If I Really Am Accountable For a “To Do?”
Sometimes, "things I do" will still bleed into my accountabilities, and they can’t all be all about making others great. One place this happened for me is in my personal improvement commitments: I have a lot of accountabilities there about publishing things to my blog. For me, publishing a writeup is proof positive that I have learned and internalized what I have written about (and my boss knows this… or hopefully he does now), and even though I don’t exactly count on a lot of people reading it, I can share it with people in my radius to help them learn, show them what I’m learning, and encourage them to write too. I don't want my accountability to simply be "learn this,” because that’s too vague, and not SMART. So, publishing something here becomes a "proxy accountability:” by doing it, I prove that I have reached my actual goal in a way that meets the SMART criteria, and hopefully affects others in a positive way too.
Thanks to Hard Code for the inspiration. In response to some of the comments there… I don’t really have any comments on the effectiveness of any particular style of goal setting for ranking people in an organization, determining promotions and the like. My intention here was just to discuss how to think about goal-setting in a way that helps me challenge myself, expand my horizons and contribute to my team.
"throw" vs. "throw ex"
Here is an interesting bit of C# knowledge I just picked up from a coworker the other day: rethrowing an exception with "throw ex" usually isn't what you want to do. You can do it, and at first glance it works fine, but when you use "throw ex" the stack trace of the exception is erased, making it appear as if the exception originated from your code, making debugging more difficult than it should be.
If you are catching an exception and you want to rethrow the exact same exception, just use "throw;". This will rethrow the exception with the stack trace intact. If you are throwing a new exception, make sure to set the original exception as the inner exception before throwing.
Thanks to this post for making it clear.
If you are catching an exception and you want to rethrow the exact same exception, just use "throw;". This will rethrow the exception with the stack trace intact. If you are throwing a new exception, make sure to set the original exception as the inner exception before throwing.
Thanks to this post for making it clear.
Subscribe to:
Posts (Atom)