DevDash–Update and Diagrams

Anyone who knows me, or reads my blog, knows that I start a lot of projects and never finish them. Usually, I take them far enough to prove that I can do what I wanted to do. Then I get bored and moved on to something else. I’ve been doing that for 15 years. While all of the projects have potential to be good, I am but one person, and there are aspects to projects that I just don’t care to do. For instance, GUIs. They kill me. I can spend hours working on some stupid thing to get it to look and behave the best I can; but it’s still crap when I’m done.

Dev Dash is no different. I’ve probably been working on this for 8 months off and on (that’s just a guess though). I’ve put it down a couple times so that I could come back recharged. But, unlike other things, I have always come back to it.

Early on, I was trying to keep it simple. I figured the simpler I kept it the more likely I would be to finish it. But, I over-did it. It was too simple. After stepping away for a couple weeks, I came back and gutted it. I kept a good portion of the objects, but had to completely reverse the architecture. Instead of the hub keeping track of the nodes, the nodes update the hub.

Also, I spent a lot of time in MVC. I started by hosting the hub services in the MVC client application. That worked fine, but I ended up with these obnoxious base classes. When I did it, I settled for them, but then later couldn’t tolerate it anymore. I could’ve resolved it a different way, but instead, I removed the services from the MVC app altogether.

For months I’ve been saying that I’m almost done. And I am. I’ve never liked or been wrong about that. But it’s a moving target. I keep thinking certain things can wait until later, but then I end up doing them anyway. I’ve ended up doing big things I wasn’t planning on doing now. (There are 500 other big things I would like to do, but I think I actually can wait on most of those).

At long last, I am closing in on being “done”. In this case, “done” means that I will demo it, and we can use it how I want to use it. But, there will always be a million more things to add, and a million things in there already that I want to do better.

The architecture is good. The implementation is good, with a few ethical shortcuts. The website is weak but functional, particularly the admin screens. The admin screens work, but I wouldn’t try to break them because I know I would succeed. They’re minimal. I’m making many things that are functional rather than a few things that are completely done. That way we can use it faster.

There are a few things left

  • Edit Commands. Being able to execute remote commands is a key feature, but it’s useless if you can’t add and edit them. I will take the same shortcut on this page that I took with the deployments: it will allow you to edit the relevant xml element rather than provide a gui that ultimately builds the xml for you. Sure, the gui would be immeasurably better, but I can it working much faster with a direct edit.
  • Save setup changes. DevDash is based on a configuration hierarchy. Right now, that hierarchy can be edited, but it’s not persisted. Not persisting it makes it easier for me to reset; just restart the hub and the changes are gone. Clearly, that’s not a feature real users would appreciate.
  • Bug in a plug in – DevDash consists of widgets that you plug into it. The widgets do whatever you want it to do; you wrote it, after all. One of my widgets revealed what I think to be a problem in one of our services. Under some condition, a TextWriter issue is introduced. That’s not a DevDash problem, but I need to solve it anyway so that the widget works.
  • Node Variables – The node variables seem to be getting deleted. I have to look at that.

This is the diagram I use to keep track of all of the objects per container.

  • image

This is how the stupid bus is used.

image

The main page, with some custom plug-ins

image

The admin menu

image

The installer page. If you have the proper access to a remote machine, it will install a node on that machine automatically.

image

The contents of the WS-DISCOVERY server.

image

The NodeStatus dialog – not too exciting with just entry.

image

Edit A Deployment

image

Execute a Deployment

image

image

Sample Command Execution. This is just a dumb example, but you can write a command to do whatever you want. (It’s just a windows batch file, essentially. Write it, the service will substitute node specific variables as necessary, then execute it. One anticipated use of this is to build installer for us.)

image

In conclusion: this is the closest I’ve come to finishing something. Almost there…

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: