I first started reading Roy Osherove’s “The Art of Unit Testing” over a year ago, as my team was ramping up design and development of a new application to be written, in its entirety, in new technology (.Net framework 4.0, WPF, EF 4.0, etc). So new in fact, that when we started development, there was no “4.0” released, it was still at the Beta 2 stage. Also, since we were to be the first truly “agile” (scrum) team, we knew we had a lot of eyes on us, both from above as well as from fellow developers. By “truly agile” we were fairly close to textbook. We all worked in the same environment (shared room), including 3 developers (with one added for a 1.5 month stint to make up lacking capacity), manager/scrum master as well as QA. We had a CI environment which was setup and maintained. We had a scrum board, or boards, which were large 24” x 36” post-its or a wall when needed, filled with user stories, tasks, backlog, all diligently written and managed on post-it notes.
Here’s a quick little handy shortcut for Agile Web Solutions’ 1Password product on the Mac.
In the past, when I needed to get information about a credit card or a password for an account I have stored in 1Password, I would take the long route of either editing the item, selecting the field, then either read or copy/paste the value, or simply use the “Copy” option found when hovering your mouse over the secret field.
However, I recently accidentally ran into the following trick, should you need to see the information that is masked, when running the full application (not the browser plugins), such as passwords, PIN, CCV, etc, do the following.
- Select the item you want to see from your Vault, be it login, wallet item, etc.
- Note the super-secret information is masked from view with dots, as in the example depicted above.
- Press and hold the “Option” key, and the secret information will be revealed, as in the example below.
That’s it! Very simple, but oh so effective and handy when dealing with a situation where you can’t use 1Password to auto-fill the information, either on a website that doesn’t play nice, or over the phone. Maybe auto-fill over the phone will be a feature in version 4!
Scenario: You are writing an application or library which targets the "AnyCPU" platform, but reference an external library (such as LeadTools) which are platform specific (x86/32 bit, x64/64 bit)
This situation is handled in several places, as there is no one unifying solution which applies to all phases of development.
During the Development Process
Storing the references
Create one folder for each supported platform. These can be placed either in a central location, or a subfolder of the solution/project. Best practice is to name the folder after the target platform. While this is by no means required, it is strongly recommended and urged.
- IA64 (very rate, not covered in this article, but the same steps apply and will work)
Initial project creation and adding references
Add the references to the project through Visual Studio as you typically would. Choose the binaries which are applicable for the platform which are presently using.
Working through the book Beginning WF: Windows Workflow in .NET 4.0 by Mark J. Collins, there came a point where the next step is to add an “Add” activity to the workflow (Chapter 4 for those interested). The method given is to make changes directly to the XAML of the Workflow designer, and it would then appear within the designer when switching out of code mode.
Unfortunately, I had a typo somewhere which my brain couldn’t reconcile immediately at this late hour, and took me thirty (30!) minutes and two re-types to get right. It didn’t help that there was no IntelliSense provided from within the XML editor, as I am accustomed to having with typical XAML code when doing WPF or Silverlight development.
Some time ago, Laurent Salat (@LaurentMT), who works in the R&D department of Tactineo, and member of the NUI group, wrote a paper (French version) about NUI development and suggested best practices specific to NUI development, called the “Bottom-Up Approach”.
Thanks to Joshua Blake (@joshblake), who understood the general concepts and wanted to share them with the rest of the NUI development and design community, he called out via Twitter, for the help of someone who was fluent in both English and French to translate Laurent’s paper. I volunteered, and after a few revisions, we now have an English translation available for those who cannot read French. I would also strongly recommend that you check out Josh’s book “Multi-Touch on Windows - NUI Development with WPF and Silverlight” , either when it gets released, or by getting in early through the Manning Early Access Program (MEAP), where chapters 1, 2, 4-7 are presently available.
The paper is a short, but invaluable read. It illuminates and brings forth concepts and best practices which are probably nagging at you to be done, without quite having been able to put your finger on it. In short, if you are designing or developing a Multi-Touch or any other type of NUI application, using the Bottom-Up approach should definitely help your users become more adept at using your system, and have a better time doing so, with less frustration, though the goal should be zero frustration!