Dropbox, ASP.Net, and a Mac

I recently switched to a Mac for my development platform, and have enjoyed the experience so far. Working with zsh and ruby and rails and all kinds of things have been much easier in OSX. Getting down with .Net is still done in Win7 for me, usually on my VM. (I haven’t booted into Windows for .Net development, yet, VMWare has done great.)

I set up my environment so that most everything is saved on the OSX partition, which isn’t a big deal because VMWare just shares folders over to Windows. So, all my files reside in one place. Nice and tidy. I have a Code directory set up to keep my code on one spot (genius on the naming of that directory, I thought). It’s shared over to Windows, and I can get to everything in either OS.

The downside to this plan is that to Windows it’s a network share. If you’ve ever fired up Visual Studio to do some ASP.Net development over a network share, you know it’s not a happy camper. But, I don’t want to duplicate everything for the sake of keeping Studio happy. If I do that for Visual Studio, then I’ll have to do it for everybody, and that’s a slippery slope I don’t want to go down.

A little Googling later, and I find somebody using Dropbox to keep it all synced up. I’m already a happy Dropbox customer, and had the, “Well, duh!” moment as soon as I read it. (If you’d like to become a happy Dropbox customer, get an extra 250 MB when you sign up with my invitation. They give me an extra 250 MB, too.)

Pretty easy to set up at that point. I installed Dropbox on the VM, created a folder in it for .Net development, and I was all ready to go. ASP.Net was happy because it was now on a local drive, I was happy because I could still move things in and out of git on the Mac side of things.

I can already hear some howling, “You’re duplicating your code! It’s stored twice on the same machine!” True…but I Dropbox does all the syncing for me, so it’s mostly an afterthought. The upside is that I can get to it with the tools I want in the OS I want whenever I want. Code it up in Studio, grep the VSS files out of it in zsh, commit branch and merge with git on the Mac, and debug away in Windows.

Even though the code files exist twice, the tools don’t. I don’t have git or a text editor installed on Windows because I can use the Mac ones.

Another big downside would be coding sans Internet connection. For the most part Dropbox syncs everything up so quickly I rarely notice it. But, if I’m away from an Internet connection, that’s not going to happen at all, and even though both copies are on the same machine, they’d be out of sync until I get hooked back up. For all practical purposes, this hasn’t been an issue, yet.

Overall, for having a little duplication on the hard drive and an extra layer of something-that-could-go-wrong in there, the experience has been, well, not noticeable. Everything just works, I haven’t had to wait on Dropbox to finish syncing files yet, and I get to use the right tool for the right job.

Setting Job Change Goals

Having just gone through a job change, I thought about sharing one of the bigger aspects of my job search process. When this process started for me – and don’t be fooled, it is a whole process and not one taken lightly – I set four base goals that my new (or current) employer had to meet.

I was given this idea while listening to Ken Auer speak at SCNA this summer. Ken was telling of when he decided to start his own company and one of his mentors said, “Set four goals for yourself, and only one of them can be monetary.” That hit home with me at the time: only one can be monetary. It was simple, and in regards to your career plainly obvious, but actually hearing it made it hit much harder.

1. Can I effect change?

I’ve spent the last 5+ years living agile development and working with XP development practices. I’ve been involved with Book Clubs and started Code and Coffee. I’ve picked up four different build servers, enjoyed development in ASP.Net MVC, and done a cannonball into the Rails pool. Can I take all this knowledge and use it for good instead of evil? Can I get a new organization on a path of continuous improvement?

2. Will I get to continue to push Agile/Lean and work with good technology?

I’ve put a lot of time into Lean and Kanban over the last year and a half. Both learning it, molding the process on various projects, then speaking about it to about anybody who’d listen. I want to keep on that course, because I think I’ve only started to scratch the surface of what Lean can bring to an organization.

Additionally, will I continue to get to work with cool technology, or better, be involved in the decision making process on what technology we’ll use? The phrase, “Right tool, right job,” means a lot to me.

3. Cool people to work with.

I don’t want to be a one man dev team as the member of a one person dev team is never wrong. I want to be around people that I can continue to learn from, that will push me as much as I can (hopefully) push them. And, I want to have fun. It seems simple, but for many years of my IT career it hasn’t felt like work because it’s fun doing the job I do. A lot of that has to do with the people I’ve worked with in the past.

4. $$…can I get what I’m worth?

One of the four has to be about money – I don’t do this for free, after all.

Market value was one of the toughest things to determine. Different people value different skills at different levels. If you’re in the consulting game, you have to have a salary that your bill rate will support. And the downward pressure on bill rates the last year is no great secret.

The unspoken goal – family time.

This is one I never put on paper because it’s the first thing that concerns me while thinking about anything with my job and my career. I’ve been extremely lucky to have a wife and two boys who have supported me as I started speaking and being gone more weekends with code camps, give camps, and conferences. So, the length of the commute to any office becomes a big deal. In an interview don’t hit me with, “We have a mandatory 45 hour work week,” because you’re taking almost another day per month of my time away from my family.

If you’re in a position where you’re starting to poke around to see what might be next for you, take the time and spell out what you want. Talk it over with your significant other, with some close friends, and forge ahead. Writing it down makes you stop and think about where you really want to go.

At least it did for me.

Career.Next

When you start a new job, that first day is one of the most exciting you have while you’re there. You’re busy getting settled in, meeting new people, learning new ways of doing things, and eventually fitting in and finding your place. For me, that day was June 21st, 2004 and the new company was Quick Solutions Inc.

However, on that first day, you don’t start thinking about when the last day will be. But with most careers that last day on a job is out there somewhere. Eventually your career leads you on to something new, something more challenging, maybe something you never expected back on that first day. That’s exactly what has happened with me, and that last day at QSI that I never really expected will be January 8th, 2010.

To say I appreciate the opportunities granted me while I was at Quick would be a rather large understatement. I’m still in awe of some of the people I worked with over the years at QSI. Most everybody assembled in our app dev group was extremely talented and extremely passionate about technology, continuous improvement, and sharing what they knew. It was exciting to go to work most days because of who was going to be sitting at the desk next to you.

So what is next? I’m off to Reflex Design & Technology to help them build a development team. Actually, on day 1 I’ll BE the dev team - Lord help them. I’m more than a little excited to be stepping into this role with them. (Yes, if you’re doing the date math in your head, I’ll be at Reflex for two days then I head for Codemash.)

Again, many thanks to the folks I worked with at QSI. There’s no way I’d be ready to step into the role I’m taking without all that I’ve learned from all of you over the last five plus years.

I’m sure at this point many of you are asking, “Why did he leave?” That’s not easy to answer. It’s a very long and complex process I went through to arrive at this decision. But, I managed to sum it up in just two words…

Lotus Notes

Five Days with My MacBook Pro

With a few changes headed my way in the coming new year, it was once again time to get some new hardware. I took the leap and opted for a MacBook Pro. (2.66GHz/4GB/320GB/15” so not the biggest, baddest one.) Here are a few of my initial leaving-Windows-and-Dell thoughts.

I can say after five days that I’m pretty sure I made the right move. There are a few things I’m struggling with in the switch, mainly my fingers going to the correct keys. Years of hitting CTRL on a windows keyboard has me hitting the fn key on the MBP, which doesn’t do much. Getting used to the Command key will take some time, but the oddest keyboard issue I’m having is hitting the B key. The reach is apparently shorter because I’ve put a lot of spaces where there should be a B.

On the flip side, it didn’t take me very long to get used to the multi-touch functions on the track pad. Having an iPhone doesn’t hurt, but the two, three, and four finger operations didn’t take long to become comfortable with. Scrolling through blog readers, articles, and Tweetdeck is a lot easier.

Installing applications is a lot easier, and a lot quicker than on Windows. To be fair, I haven’t installed a lot of huge apps, but the fairly large ones I did install went really quickly. The only real side-by-side comparison of installation I have is Tweetdeck, and it was a fraction of the time getting it up and running on the Mac. Most apps are just download, mount the image, drag to applications, unmount the image, and run it.

Now on to one of the bigger reasons I was after a Mac: Ruby on Rails development.

Rails on Windows was painfully slow at times. I tried all kinds of stuff to get my specs to run in less time than it took me to go downstairs and brew a cup of coffee. After copying the git repo of one of my sample apps over, I ran the specs and it reported .7-ish seconds. And it actually WAS .7-ish seconds. Not the 45 seconds of dead time at the command prompt while it fired up servers and stuff then reporting .7-ish seconds when it was done with the tests that I was used to. I’m already looking forward to doing some more of this.

Before I start sounding like a total fan boy, it hasn’t all been awesome. There was a 2 hour fight with an iso and some printer drivers to try and get my printer at home to work. Still haven’t got it to work, so I gave up and grabbed Brendan’s netbook to print off what I needed.

I’m also not enthralled with only having 1440 x 900 resolution. But, I’m getting old and my eyes would get tired staring at the hi-res Dell I had before, so maybe I should not worry about this one too much.

Also, couldn’t find any decent blog writer that lived up to Windows Live Writer, so this is being written in Live Writer in my Windows VM. (Bootcamp + VMWare Fusion + Win7 is freaking awesome. Looking forward to some .Net dev when I get Studio installed.)

Suffice it to say, the positives out weigh the negatives so far. I’m sandals-to-work away from swallowing the blue pill with the Apple logo on the side of it. :)

Beware Your Buffering

In a twitter discussion that was centering around some Kanban joy, the point of buffering came up. I offered a bit of twitter-esque advice, meaning it was short, could be interpreted as terse, and lacked the detail it needed. As any good friend would do, Jim called me out for my 140 character bit of guidance.

So, in more than 140 characters…

Be careful with your queues on your Kanban board. (I say queue here, because a buffer is just the queue for the next step.) By definition, any queue is waste. It’s a step in the process where something is waiting, therefore value isn’t being provided to your customer.

Can queues be used effectively? Yes. Quite effectively, but you have to stay on top of them. In reality, there has to be some queuing going on to give a pull system something to pull. In practice, those queues need to be as small as you can keep them to keep things flowing.

My tweet that started this mess was that I’d been burned by buffers on more than one occasion. Here’s one nasty one where the queue wasn’t a help, it was hiding the real problem.

We had a project where our developers far outnumbered our testers. This isn’t an unheard of scenario in the world of software development, but we handled it badly on our Kanban board. We ended up with not one, but two buffers between the dev team and the QA folks. The true, root cause problem was we had a resource problem because we needed more testers. Instead, we masked it with some queuing.

The biggest problem was that we lost our short feedback loop from development to demo. Early in the process, we’d complete a feature and it would demo within a day or two. As the project progressed and the developers’ momentum took off, the testing team was backed up and the feedback loop grew. Bugs were sitting open longer, code complete features waited to be tested, and the churn began.

Our solution was to swarm the test queue to get it lowered. Having a dev or two help get some testing done got our backed up test queue fixed, but it put devs in a testing role which I’m not a big fan of doing. (Devs are notorious for making sure something works rather than looking for ways something could break.) Also, this solution was very temporary as the queue naturally filled back up once the dev team was back in high gear. The actual solution: add a testing resource. Our full queues told us that, but we didn’t listen too closely for a while.

In the end, some buffers and queues are inevitable in many situations. However, make sure to do the following:

1. Make them as small as you can, maybe half the size of the queue limit of the step that the buffer is feeding. Adjust as necessary, but don’t keep increasing it as it fills up.
2. If you need to increase its size, ask why a couple times to clear it up. If the answer is, “Because we need more room!” then look at the next step and see why it’s backing up your process.

So, back to what started all this…buffers can bite you in the butt as they tend to mask the issue rather than solving it. Make sure your buffers aren’t hiding a bigger problem.

Rails Study Apps

I’m trying to pick up some rails in my spare time. Been plugging away at my pet project when I can, which leads to a lot of googling while I do it. If one of my known Rubyist friends is at a Code and Coffee session, I spend a fair amount of time picking their brains and pairing up to learn what I can in an hour or so.

That all works pretty well, but at my pace I’ll be forever getting my Ruby code to look less like C# and more like Ruby. So, as Steve blogged recently, why not find a few Rails apps to read? So, I hit up my twitter friends: http://twitter.com/timwingfield/status/6464205602

I got three pretty good responses, and finally got time tonight to pull them down and take a quick look at them. I don’t have a lot of info on any of them, but I did browse the source to get a feel for what was going on.

Radiant CMS

http://github.com/radiant/radiant

This one was recommended by Dugald Wilson. Decent amount of code here to look at, and uses RSpec for the test framework. This one definitely fit the bill for what I was after.

Spot.us

http://github.com/spot-us/spot-us

I got this one as a tag team recommendation from Scott Walker and Matt Darby. This is a non-profit company doing Community Funded Reporting and is coming from the folks at Hashrocket. More RSpec out of this project, and again a fair amount of code to pour over.

Redmine

http://github.com/edavis10/redmine

The third one came through Ben Wagaman. This one uses TestUnit instead of RSpec, but still some decent reading. I’m going to have to dig into the tests a bit more on this one, though, because the file names aren’t jumping out at me as model/controller/etc type tests. But, that’s the point of this exercise, to see what other folks are doing.

I’ve got a little flying and a lot of driving ahead of me this weekend, hopefully I get some time to dive deeper into what each of these apps is up to, and get some more Rails code under my belt.

If you’ve come across a few more open source Rails apps out there, please drop a link in the comments.

ASP.Net MVC: A Step in the Right Direction

A link to Doug Copestake’s article “ASP.Net MVP: A Step Backwards?” was forwarded to me, and it made some short rounds on twitter. I read it and had a comment underway and thought, “This is WAY to big for a comment, let’s blog it!” So here we are.

Off the top, I’d like to give a tip of the hat to Doug for stepping outside his day to day and taking a look at ASP.Net MVC. It’s very easy to hide behind FUD and just blow off something different. Additionally, his initial findings are pretty much on par with most other folks happy with WebForms who take their first look at MVC.

The MVC framework definitely provides simplicity and separation of concerns to web development. It allows you to only write the code you need to write to get the job done, and it allows you to work with the framework. Views become very small and very specialized, controller actions mature to be very thin, and it’s all easily testable.

This has made my work with the MVC framework extremely successful. Since everything is easily testable, as we refactor the code to clean it up or add new functionality, it all flows very easily.

Control reuse comes from veteran WebForms developers quite often. But if we again point at simplicity, how many of those drag and drop controls were written to cover more functionality than you need? You drag a grid control out and use 15% of it’s power because its made for everyone. Yes, you can write your own application controls to do exactly what you want, but you can do that in MVC, too.

Another point to control reuse is the leveraging of more javascript frameworks to do many of the things that the WebForm control suites do. In jQuery UI alone, you’ll get tabs, accordion panels, sliders and other UI elements, all with out that “server side” part that is so prevalent in WebForms. The win there is in more than just lighter weight controls, you gain a much better user experience. (And who doesn’t like happy users?)

The spaghetti code point Doug makes is quite valid, though I think that’s not a factor of one framework or the other as much as it is the person writing the code. The Glen Vanderburg quote, “A bad developer will move heaven and Earth to do the wrong thing,” applies to all languages and frameworks. The person with the keyboard under their fingers is responsible for keeping their code clean, not the framework developers, but I digress.

Spaghetti code in the views is a big sign that you’ve done something wrong. Even before moving to Spark, if you see lots of server instructions in your views, it’s time to stop and think, “What can I do differently here?” Same can be said of your controllers. If you’re used to writing a 50 line page load method in WebForms, turning similar code into 50 line controller actions is a step in the wrong direction. I guess the main point here is instead of relying/hoping for the framework to do the work for you, the onus is now squarely on the shoulders of the developer to keep his or her code concise.

Doug’s last point is very true, though: if you have a lot invested in WebForms in your current situation, there’s no real reason to switch away from it. Switching for the sake of switching to anything usually isn’t a good move.

That said, you can easily run WebForms and MVC in the same web application. If you have a little something to add to the project that can stand on its own, I’d say a look at MVC is in order.

This definitely would have been too long of a comment… :)