Foo Theory

March 2008 - Posts

• PhotoShop Express vs. Paint.NET

  Almost daily, I use some sort of digital editing program. Over the years my top 5 tools for digital editing have been Paint.NET and Photoshop. I use both programs daily for editing screen shots, creating educational material/training manuals, and blog posts. I love Paint.NET simply for the fact that its VERY quick to load and performs easy tasks quite quickly. On my machine Paint.NET is up and running in under 5 seconds. Paint.NET helped get the easy tasks done, but when I wanted to perform true graphics manipulation and do some hardcore stuff, I'd fire up Photoshop. The one thing that always crossed my mind was why Adobe did not offer a "Photoshop Lite" type of program. Paint.NET has always been my "Photoshop Lite" since it was released. But, I still wondered why Adobe was missing out on this market. Well, the other day Adobe released Photoshop Express. With my previous pondering finally answered, I HAD TO check out this product from Adobe. Could this be the "Photoshop Lite" I was hoping for? My First False Assumption My first initial impression upon reading the product SKU name "Photoshop Express" was that it was going to be a slimmed down version of Photoshop similar to Paint.NET that was installable. Having worked with Visual Studio for a very long time, I've become adjusted to recommending the "Express" SKU's to developers interested in .NET development. I'd recommend the Visual Studio Express SKU because it allowed them to get the feel for a good IDE (slimmed down on features of course) but they still got to use a lot of built in functionality, and it was FREE. That was the nice thing (note: if you're a student you can utilize the Dreamspark campaign to get a free version of Visual Studio Pro, and other products). Was this the slimmed down version? No... not at all. Not only was this version not slimmed down, it wasn't even installable - its a pure browser based solution. I was thinking that maybe it was a "Click Once" app, nope. Not even close. This is purely a browser based solution. Ok, that's not too bad, then I started to use it... My Second False Assumption I believe a company of Adobe's caliber would be able to create a compelling graphics app that would be very responsive and effective - regardless of the platform (install or web). Anyone who has worked with any graphics program knows that they are memory hogs. Literally, they eat memory for breakfast, brunch, lunch and dinner (and some snacks between). They need to utilize a vast memory base to keep the program responsive - I like to say - if its a' swappin' it's a' doggin'. I had assumed that this program would be snappy like its big brother Photoshop. Nope. Not at all. Since Photoshop Express is a web based hosted solution the images have to be uploaded to the server. The problem lies in the last four words of that sentence. Uploaded to the server. I don't know about you, but there is nothing snappy about loading up a 2MB file to a web site. Applying the filters are rudimentary, adjusting contrast, color balance and other tasks leave your image looking like you took a trip back to hippyville with too many pink elephants. Conclusion I had assumed I might be able to replace Paint.NET with Photoshop Express upon its initial release. Unfortunately Photoshop Express is insanely slow and the graphic manipulation tools that I need to accomplish my tasks are not what I need them to be. The lack of options are kind of a bummer and the responsiveness of the app is less than lackluster. But I'll say this... its a good attempt. Maybe version 2.x will be better. How could Adobe get me to use the app? They could make it a Click-Once app. Make it a local installation. Follow the Visual Studio Express SKU model. Look at Paint.NET, It's worked great for them, why wouldn't it work for Adobe? I know they have a ginormous Apple following so they'd have to use a installation procedure that would work with MAC's as well as Windows. Possibly supporting two different models of the software is just too much for them at this point to foot the bill for a Free product and support. But, if they did go down the route of an installable Express type of app, I'd be all over it. For the meantime I'll be sticking with Paint.NET. It's installable. Its a subset of Photoshop Features, and the real key is... ITS FAST. Any tool that I use MUST BE FAST. If its not, its gone.   Click thumbs for larger image Screenshot of Paint.NET Screenshot of Photoshop Express Posted Mar 31 2008, 09:58 AM by donnfelker with 1 comment(s) Filed under: Productivity, Design

• I Can't Read Your Screen, Mr. Presenter

  We've all been there, at the code camp/user group meeting/conference/etc where we CANNOT read the screen. Even though your code is projected onto a gigantic screen I cannot see you 10pt Courier Font, Mr Presenter, from 50 feet away in the back row. The audience faces contort and become scrunched up to the point of looking like the human version of a pug. This is one of my biggest pet peeves during a presentation - the presenter may know the content like no other, but they don't have the skills to present their content properly. What's even more amazing is that that 9/10 presenters (in my personal experience) do not attempt to adjust the font on their screen to increase content readability. Aren't you trying to teach me something Mr. Presenter? I can't learn what I can't read. :\ As said before by many others, if you, as the presenter say "You know, you probably can't see this..." - you're right, and you're wasting my time. You've got a gazillion pixels on the screen, make them work for you. :P What if the presenter bumps up the font to 18pt? That's all well and fine, and I can see the content, but I still have NO IDEA what the heck that 8pt menu font says, nor what menu you clicked on to get to that magical wizard that writes N-Layer architecture systems with a click of a button (sorry, got side tracked). Gimme Da' Big Font's and ZoomIt Buddy! Here's what I do when I'm giving a presentation... Use ZoomIt. I'm utterly baffled by how many presenters do not know about this tool. It's been around for quite awhile too! This tool allows you to zoom into a certain part of your screen with variable magnification. Once zoomed in, you can draw on your screen with multiple colors, write text on the screen and even change the color. You can also draw shapes as well (ellipse, rect, straight line). To view the options, double click the ZoomIt  icon (shown here to the left). How does it work? Simple, fire up the app. It will run in the background. When you hit the CTRL + 1 key combo, the screen is now magnified. Use your mouse to browse the the area where you want to display additional info. I've created a simple screen cast, which is below. Click to watch. (there is no sound in this, it's just here to demonstrate what can be done). Create an Account that has Big Fonts. I prefer to set up an additional account on my machine that has all of my tools set up. I mean, everything has big fonts. From the command line to Visual Studio, to Notepad++. These are nice, big ol' fatty fonts. Trust me, its not pretty to look at, but for presentations it does well. You can adjust the font size of your machine by setting the font size in the control panel as seen below: Note: This will REQUIRE a restart.     Next time you're presenting, don't forget the reason you're there - to present FOR AN AUDIENCE. Be kind to their eyes! Let them see what you're doing. Trust me, you'll get higher scores on your review sheets. Posted Mar 30 2008, 08:18 PM by donnfelker with 1 comment(s) Filed under: Misc, Productivity

• Implicitly Typed Locals - R# V4

  Recently Ilya Ryzhenkov posted a thread on the ReSharper blog. The article was about how R# 4.0 gives you a suggestion to use implicitly typed locals. I've been running R# 4.0 nightly builds for a few weeks now and I've noticed these little buggers popping up all over the place. Here's what it looks like:   Usually, I nearly agree with most of everything the R# team posts and even though sometimes I may disagree with something, I'll find the edge case where it does apply, so we're at a 99% agreement rate with them! Hell, you can't lie about it, R# seriously improves your productivity and it only keeps getting better. Unfortunately, this is the one time I'm going to fully disagree with this post and actually the suggestion in R# - which is why I have disabled it. You can disable it  by going to the R# options:     Why I Disagree The post stated that "It induces better naming for local variables". I don't know about that. I can still call an apple an orange and call a orange a banana I want. Nothing forces me to do anything. The only thing I know at that point is that it's still an anonymous type. A name is that, just a name. Nothing forces developer x to write a good variable name. I still see Junior developers using wrong variable names. The only thing that's going to help here is a good code review process. The post then goes into to say that it "It induces a better API". Again, I don't agree. How can this induce a better API? I feel that letting the compiler choose which types it is returning has its validity in certain cases, but not inside of your entire system. It brings back the horror days of VB's "Variant" (and yes, I'm aware that var is not Variant and I know the differences - but have you seen an old system where EVERYTHING was a variant? Oh my jeebus, save me now). Just because I'm letting the compiler do the work doesn't mean that I should have "good variable names" to help me distinguish what I'm working with. This the one that sent me over the top... "It removes code noise". *insert sound of game show buzzer* Yeah... um... I'd have to say that's complete non-sense (in my opinion). Over use of the var keyword is going to add code noise and is definitely a smell to me. If I open up a class and see everything as "var" type, I'm going to cringe. The readability of this code has diminished to a point where its now costing me more money to maintain and read the code than it is if I were to use a strongly typed variables when I could. Even the MSDN states: Overuse of var can make source code less readable for others. It is recommended to use var only when it is necessary, that is, when the variable will be used to store an anonymous type or a collection of anonymous types. [Source] The last one is almost not worth putting into the post... "it doesn't require a using directive". Wait a minute... I bought ReSharper so I could be more productive... hitting ALT + ENTER to add the directive isn't a bad thing. Who cares if another directive is up there, that's what its used for, to tell the compiler what blocks of code look into during compilation. Conclusion This is not a bash on the ReSharper guys, not at all, but an explanation of why I disagree completely with this post. Heck, I agree with most everything on that blog (most of the time) and I'll never speak up about it. I'm a huge ReSharper fan and I will continue to use it and proclaim its greatness, but while reading this post I noticed a smell immediately. While using var has its uses, I think it can be abused. The saying goes... "When all you have is a hammer, everything looks like a nail."  Lets not use var as our hammer. Its a special tool for special cases. We don't use ice axes for steak knives do we (even though that would be very manly and barbaric - and hell, kind of fun), so we shouldn't use var for unintended uses. Posted Mar 28 2008, 08:28 AM by donnfelker with 1 comment(s) Filed under: Productivity, .NET

• Beginner Test Driven Development Habits

  Having worked on quite a few teams where I've been the lead responsible for helping implement TDD or been an Agile Coach - I've seen a group of habits develop when teams first start utilizing TDD. These are ...   1. No test isolation All functionality that is being tested is in one test. Tests are heavily over specified. How to fix: Spend some time pairing with the developers that are having the issue. Help explain why we want to break tests apart into smaller units, aka: "UNIT" tests. Let them know that we do not want to test the entire class in one unit test. Just because it can be done doesn't mean it should be done. Ya know, I COULD drive into oncoming traffic, but its just not a good idea. :)   2. Failure to recognize the TDD Mantra  Most  new TDD'rs will go from Red to Green to - I'm done! Nope. I'm sorry guys, we have one more in that list - Refactor. Let's say it together.  Red/Green/ReFactor, Red/Green/ReFactor :) How To Fix: Help the developers realize that we want to refactor for a reason. We have a passing test, we know what to expect from our results. Now lets clean up our code, maybe introduce some interfaces, change some variable names, introduce some fields, extract some methods, etc. Doing this allows us to clean up the code as well as have the confidence that our changes did not muck up the expected result. Run the unit tests after you refactor. If it breaks, oops, lets go figure out WHY it broke. We caught the error early, its a lot cheaper now. :)   3. The previous lends itself to Insufficient Test Coverage/TDD is my new Debugger The developers usually will do enough to get the test passing and then move onto the next task. They think of TDD as a new debugger. How To Fix: Sit down with the developers that have this issue and explain: Just because we can now unit test a method/object and step through it with a debugger doesn't mean that this is the new debugger.  That's not the point. Just because the test passes doesn't mean we're done. Just because your method passes if you pass a valid object into it doesn't mean that its fully tested. What happens if I pass a null object into it? What happens if I pass a new'd up object with nothing instantiated? Have those instances been tested? Have we tested that our objects are interacting as we expect them to? Do we know if the Logger got called? How do we know if we didn't test it?  That its the classic question: How do we know it works, if we don't have a test to prove it?   4. No concept of separation of concerns or IoC/dependency injection. This is not a big deal and I expect it of most new TDD converts. Usually while learning TDD the first few tests do not need DI/IoC, but this is something that will help in the future and will need to be understood to really grasp. This really comes into play when we start separating our concerns and breaking dependencies between objects. The refactoring that takes place here can really get deep into DI/IoC sometimes. How To Fix: Give them a great intro into interfaces and how they're used. Show them great articles on DI/IoC written by Martin Fowler, Jeremy D. Miller, Ayende, and have them join certain mailing lists such as altdotnet to join in/read the discussions. On that list alone, DI/IoC discussions occur on a daily basis. 5. TDD Complaints I've seen complaints such as: It takes too long to write the tests I write more test code than real code. The tests are harder to write than the real code. How is this going to help me get my project done? I can just hit F5 and test it and I can tell if it works or not with my own eyes. Who cares if it passes a unit test, I'm the only person who works on this project. How To Fix: This is one of those habits I've seen in every place I've coached. These are classic examples of someone who hasn't "seen the light" of TDD yet. In my experience, the easiest way to help them see the light is to pair with with them while writing unit tests. They will instantly see why the unit tests help them and the team. Every single time I do this I help the TDD newcomer realize that by writing this test they've exposed X bugs that they didn't think about before. It usually goes like this: "Ok, that test passes, what would happen if an empty string was passed into this? Would the DB accept an empty string?" Them: "Oh... good point, I didn't think of that." Instantly lights start turning on. Another thing that works great to help developers see the light is to ensure that you're utilizing Continuous Integration such as CCNET, or TeamCity. Have them create a unit test for a section of code. Check it in. Watch it build and watch unit tests pass. . Then have them change the code (the code which is under test) and ensure it returns a different result. Maybe it returned a user's name, such as "bob", now have it return the users name with some characters appended to the end of it, such as "bob123". Have them check it in, watch the build fail because the unit test failed. Explaining to them that this helps catch errors before the product is live is crucial. Once they have the "Ohhh!! I get it now moment", they won't want to stop writing tests. Posted Mar 23 2008, 12:28 PM by donnfelker with no comments Filed under: TDD, Agile

• TIP: Getting the Base Directory of where your App is running

  This is an oldie but a goodie. It was brought up that not one developer at my current client knew about this object in the framework. So, how do you find where the app is running at? Easy: Use the AppDomain object. This works for both Web and Non-Web projects. Code: 1 AppDomain.CurrentDomain.BaseDirectory The AppDomain object will return the application's domain information, which includes the info about where it is executing. We get the current domain of the executing thread and then get its BaseDirectory to see where it's executing. This: Returns this:   Enjoy. Posted Mar 11 2008, 04:18 PM by donnfelker with no comments Filed under: .NET

• The Calendar and the Cloud

  Update: There seems to be an issue with recurring events that are NOT set up by you. This is a huge inconvenience. Hopefully the Google Calendar team fixes this soon as this renders this sync tool un-usable as most of my recurring events are set up by others (Project Managers). Google dropped the Outlook Calendar Sync yesterday. You can see the alert in your Google Calendar. The great news is that it offers a two way sync between Outlook and Google Calendar. As a consultant, this is great. I can now have a synced calendar between my different clients an my personal life. I can sync my clients outlook (dfelker@example.com) with my personal calendar and then sync my work Outlook with my personal. Therefore I have a master calendar that is updated at all times. Regardless if I'm at the client, logged into their domain, or logged in at the office, or at home, I get the reminders and notifications I need. No more checking 3-5 calendars to make sure I do/don't have a meeting that day. :) As you may or my not know, you can have Google Send you text messages for calendar events every morning as an Agenda. So when  you wake up, it will be waiting for you in your cell as a text message. What it looks like installed: I downloaded it and it places an icon in your tray that looks like this: When the calendars are sync'ng up, this icon is displayed: Posted Mar 11 2008, 08:23 AM by donnfelker with no comments

• Knock Knock. Who's There? Me. Too Bad. Go Away.

  Yup, that's right. Team Foundation Sever told me TOO BAD, SO SAD, GO AWAY, TRY AGAIN ANOTHER DAY. What a great way to start a Monday. Oh, any by the way, we have an emergency release that might have to get pushed out. We're waiting on upper management to make the final decision... fun-fun it is. Photo By: Auntie P This weekend I rebuilt my machine. I have a Dell Inspiron 6400 Laptop and it came loaded with Vista Business (and TONS of junk-ware I don't need/nor care about). The one thing I love is that to restore back to factory settings only took about 10 minutes. Yes, 10 minutes - that's craziness. Most rebuilds take hours (unless you're using Ghost or something like that). There is a little partition on the drive that has the factory restore files on it. Just boot into the boot menu during start up (F8) and then choose restore to factory default and you'll have a factory machine within 10 minutes, total awesome-ness. After I spend the next 6-8 hours installing VS2005, VS2008 (yes, I need both, some clients will only have VS2005 and the solution files in VS2005 and VS2008 are different, by a line), Office 2007, and my list of tools that are close to Hanselmans tools list I finally was ready to get back to work on Monday. I came in today and tried to connect to TFS (2005). Nope. Not going to happen. Here's the error:   TF31002: Unable to connect to this Team Foundation Server (...) Please contact your TFS Administrator.   Me: *Expletive* Great, I am the TFS administrator. I have FULL access rights to TFS, I AM THE ADMINISTRATOR!! I have no idea why this would happen. I was able to connect last Friday, on Saturday before the re-install and team members are working against TFS as I speak. Then I rebooted, tried a few other things. Checked Windows firewall and a few other places. Nope. Still didn't work. Me: *Expletive*   The Fix I had a hunch this was caused by some type of interception of a call to TFS. I then decided to uninstall Macfee Anti-Virus because, well, because I can't stand anti-virus software that bloats my system. After the always-required-reboot, I started up VS2005 and tried to connect to TFS. It worked. I wanted to know if anyone else had this problem so I did a little poking around and I found this thread on the MSDN forums. It looks like this is the EXACT problem that I had. Oh what a joy AV software is. Actually, I can't stand it - not one bit. Posted Mar 03 2008, 09:07 AM by donnfelker with no comments Filed under: Visual Studio, TFS