Refactor This

Solutions are due Friday, May 06, 2011 at 05:00:00 PM PDT. Source Code

Hi and welcome to team Amazing Electronic Code Cluster (Blue-Cyan). As you know, we are a large provide of things that exist solely in a nebulus mass of stuff (like tubes, interconnected tubes, a whole series of them). Anyway, you're not the astronaut in charge of designing it, we hired you to do useful work. Here's a run down of the existing functionality.

• A region can contain zero to many availability zones
• An availability zone can contain zero to many instances
• Instances need to have valid account numbers when supplied
• Instances with an availability zone must be uniquely named
• Instances can only be inactivated in certain situations (the actual situations are not important, but inactivation needs to be prevented when they occur)

We recently experienced ... well let's say something that is statistically distinguishable from perfect. An availability zone was not available yet we continued to try and add instances to it and update existing instance. It wasn't a good situation. This caused us to think that we should handle that a little better. You're first task is to implement the following functionality.

• Don't save the instance when its availability zone is not available

We've decided to allow for three levels of changes (so please specify which level you are solving for). Remember that whichever path you choose the existing functionality must be maintained and the new functionality must work correctly.

• Free rein, you are allowed to change everything within the current system
• Restricted, you are only allowed to change the Save method in InstanceController (this includes changing the content and the signature). You can add new classes and extension methods but you cannot change any other existing class (with the exception of the Program class of course)
• Compatability, you are only allowed to change the contents of the Save method in InstanceController. Again, you can add new classes and extension methods but you cannot change any other existing class (with the exception of the Program class of course)

FAQ
Yes, this was adapted from real production code.
No, it has nothing to do with cloud technology.
Yes, I am familiar with the offending code.
No, I didn't originally write it.
Yes, I have added to it's nastiness.
No, I don't feel good about it.
Yes, you are awesome and want to impress me.
No, you are not solving a problem for me (it's just a piece of crazy code I was looking at recently and thought it'd make for a good refactoring exercise).

 

Lightsaber IDE

Now that I have something that works, let's make it better!

The first thing I'd like to do is make the feedback cycle better. I had setup a build file initially

but I soon realized that a simple mistake would lead to me wiping out my IDE and forcing me to go back to notepad or keep a working copy of the IDE around some other place. Also, I would run the make.cmd and then I'd have to run bin\DevPad.exe. I decided to update the build file to stage the executable and only when the compile succeeds do I overwrite the actual IDE.


To make it a one step process I added an upgrade file


For tidiness I added a clean script

One annoyance I was running into a lot, was getting prompted with the save dialog AND the confirmation that it was okay to overwrite the specified file when I wanted to save. By storing the file name as a variable I'd be able to know if I'm working on an existing file or something new.

I also wanted to make my IDE smarter. If I wasn't careful I could lose unsaved changes. I wrote the logic of remembering if there were usaved changes and prompt for when there were out in its own class, UnsavedChanges and then wired it up inside MainForm. I don't like how UnsavedChanges has to have a IWIn32Window and Action (the Save() method) but it works for now.

The final bits of improvements I wanted to add are to show the current file on the form, set the default size to 800x600, to start maximized, and to set the default font new Font("Consolas", 10, FontStyle.Regular, GraphicsUnit.Point, 0).

Lightsaber IDE

The first thing you'll want to do is get your IDE self-hosted. The best way to figure out what the most important thing to work on is by dogfooding. I also suggest that you use the most basic tools to bootstrap yourself. This way you are more likely to use your IDE rather than the one you usually do.

I've chosen to use notepad with a goal of switching to my IDE ASAP.

So it seems like the first step is to get a form to show up. Obviously, this is rather trivial:

I'll need something to type into, a RichTextBox should do for now. I put all the code to add it to the form in MainForm.designer.cs and set it's Dock property to DockStyle.Fill. Next, I need to be able to open and save files. Instead of the traditional File, Edit, ..., Help menus I decided to just have the three items right there as root menus: Save, Open, and New. Some things I ran into: I had to add the STAThread attribute to the Main() method as I wanted to use the built-in OpenFileDialog and SaveFileDialog; the RichTextBox control does not have carriage returns ("\r"), so I had to do a Replace on new lines ("\n") with Environment.NewLine when writing the file; and finally I had to use the Encoding.Default encoding option, so that © et al. will get displayed on the form and saved to the file properly. With that I have a self-hosted IDE that I can begin using.

Refactor This

I sent around a little challenge at work. Bobby was nice enough to post about it so I'll leave it at that. I'm happy to report that it got picked up by a software craftsmanship course.

Lightsaber IDE

So after getting fed up with people complaining about problems with their *favorite* IDE, it occurred to me. Why don't we just make our own? You know, like how a Jedi builds their own lightsaber. Talking about it at work and thinking about it on the commute I came up with a list of big ticket items that would need to be addressed.

• Editing a file
• Multiple files
• Compiling
• Debugging
• Test runner
• Syntax highlighting
• Find usages
• Go to definition
• Intellisense
• Snippets (prop, propg)
• Source code integration
• TeamCity, StyleCop, etx integration
• ReSharper refactorings
• Underscoring

While there is a ton more and it's a big task (and most likely a tremendous waste of time) it seems like a fun thing to do, at least for a little while. I also came up with a name, DevPad.

In case my handwritting is unintelligible.

Worked
• Justin stepping up to be the customer rep.
• Liked the environment/facilities
     same room
• No negative interactions
• New phrases
• Good/committed product owner
• "C# is better than Java" -Scott
• Good learning experience
• Made the product owner think about the workflow, rethink the process
• Demoing often
• Having a central place to demo

Didn't
• Backbone derailment
     (communication problem?)
• Needed a skeleton/starter kit
• Not much to do @ first
     a smaller group for a new project (4~5)
     a larger group for adding features to an existing project
• Needing a benevolent dictator
• Conflict between getting an understanding of the problem & solving the problem
• Didn't solve the file backup project
• Needed more formality
     timebox
     actually standing up
• Loving the CRUD
• Very painful to watch the rubber band effect
• Didn't do it the way we KNOW we should have

We also thought we should have had a time-lapse camera.