I'm taking a little break from Windows Workflow to refresh my knowledge of UML and Use Cases. To tell the truth, I never really bought into the whole use case stuff at my previous job. I can give a hundred excuses, all valid of course, for why I didn't believe in UML, but it was mainly because I didn't see my customers buying into the process of software development. They wanted the software. They wanted it now. They didn't want to do any work. Whatever tools we used, whatever diagrams and documentation we drew up, was for our own purposes. They never saw the use in it. By the time the diagrams were done, there was a new crisis du jour, and the last project was already passe.
But I was in a meeting with a new client last week, and one of the reasons I was being brought in to help with this project was to help build an industry standard set of requirement documents which could be handed off to the developers, whether it be my team, or someone else. I was there to do the architecture.
And on the way home that night, it hit me. I might not be there in six months to answer a developer's questions on what was needed. And they might take my name in vain. And they might say that I was incompetent. I can't afford that.
So I picked up my UML book this morning and started re-reading. Realistically, most of the stuff I already knew, but I had never formalized the terminology. I have never put UML / Use Cases on my personal resume because I lacked this formal experience with the process. So with the goal of not looking incompetent, and knowing that I would immediately apply this knowledge to my current daily responsibilities, I am digging in and now seeing the positive side of learning something that I consider 'non-technical'.
In fact, after reading the first 5 chapters this morning, I'm convinced that I can give this book to a project manager I work with, and that with both of us using this style my consitently, we will be better able to understand each other.
Who da thunk it?
Tuesday, July 22, 2008
Wednesday, July 16, 2008
Initial Impressions of Windows Workflow Foundation
In my last post, I mentioned I was reading Pro WF Windows Workflow in .NET 3.5 by Bruce Bukovics. I also used the words Whoop-Tee-Doo.
Well, I'm now 335 pages into the book, and into the concept of state machines, and this morning I finally had an 'Aha!' moment. See I've been trying to solve a problem at work, and knew that Workflows would probably help me, but the Sequential Workflows weren't blowing my mind. They just seemed like a lot of overhead to implement something that I could do inmany other ways.
However, the State Machine Workflows are definitely something I can see real possibilities for. I'm going to mock up my problem as a state workflow today, and see if I can get it to work.
I have two concerns:
1. Will I be able to call a .NET 3.5 Workflow DLL from a .NET 2.0 Application. I think so, as long as the .NET 3.5 Framework is installed on the clients (which it is)
2. Should I, as the architect, introduce another new technology into an application which is already difficult to support, even if it makes the problem I am trying to solve easier to solve. I am conciously trying to not alter the core of the application because of the size of it and the cost of fixing stuff that isn't broken, but the framework of the application is really limiting what we can do, and I think I can just peel out some pieces and make the application better. I also don't want to be the only one able to support it going forward, and if the rest of the team doesn't take their education in the new technologies as seriously as I do, I could be painting myself into a corner.
Well, I'm now 335 pages into the book, and into the concept of state machines, and this morning I finally had an 'Aha!' moment. See I've been trying to solve a problem at work, and knew that Workflows would probably help me, but the Sequential Workflows weren't blowing my mind. They just seemed like a lot of overhead to implement something that I could do inmany other ways.
However, the State Machine Workflows are definitely something I can see real possibilities for. I'm going to mock up my problem as a state workflow today, and see if I can get it to work.
I have two concerns:
1. Will I be able to call a .NET 3.5 Workflow DLL from a .NET 2.0 Application. I think so, as long as the .NET 3.5 Framework is installed on the clients (which it is)
2. Should I, as the architect, introduce another new technology into an application which is already difficult to support, even if it makes the problem I am trying to solve easier to solve. I am conciously trying to not alter the core of the application because of the size of it and the cost of fixing stuff that isn't broken, but the framework of the application is really limiting what we can do, and I think I can just peel out some pieces and make the application better. I also don't want to be the only one able to support it going forward, and if the rest of the team doesn't take their education in the new technologies as seriously as I do, I could be painting myself into a corner.
Monday, July 14, 2008
VS2008 Printing Issue
Today, I wanted to print a DBML Document from VS2008. The fact that I've been using VS2008 for 6 months now, and haven't run into this shows how much printing I actually do.
Anyway, I tried to print, and I kept getting an Error 'No Default Printer Istalled', which is bizarre, since I do have a default printer installed. What it really meant was the ID I was running as (admin), had no default printer installed. Even though I am an admin on my box, the admin user itself had to have a default printer set up.
Of course, I don't have the Admin user ID and password for my machine (I've never needed it in the past), so I had to recruit one of our tech support guys to fix this. After setting up the printer, and then switching back over to my id, everything was, whoa... still didn't work. Huh? Switch back over to the admin ID, test the printer. It works. Switch back over, restart VS2008, still nothing.
Close everything, log out, log back on, openup VS2008. Print. Ta-da!
Hoep this helps save someone half an hour.
Anyway, I tried to print, and I kept getting an Error 'No Default Printer Istalled', which is bizarre, since I do have a default printer installed. What it really meant was the ID I was running as (admin), had no default printer installed. Even though I am an admin on my box, the admin user itself had to have a default printer set up.
Of course, I don't have the Admin user ID and password for my machine (I've never needed it in the past), so I had to recruit one of our tech support guys to fix this. After setting up the printer, and then switching back over to my id, everything was, whoa... still didn't work. Huh? Switch back over to the admin ID, test the printer. It works. Switch back over, restart VS2008, still nothing.
Close everything, log out, log back on, openup VS2008. Print. Ta-da!
Hoep this helps save someone half an hour.
Friday, July 4, 2008
Back from where-ever I've been
Not that I've totally forgotten about updating this blog, but it wasn't until I started getting some people posting questions on here did I realize that, hey, someone is actually reading it! I'm going to try to get back into updating it more regularly, though it is difficult to find time to do it when I am at work, and that's when most of my technical tips, tricks, techniques, etc. come to me.
Anyway, since I last updated this site, a lot has changed. I spent pretty much the whole month of May, and most of June, heads down in developing my first major e-commerce web site. I worked with two other developers and a QA, and we started out really far behind the eight-ball due to a number of staffing issues early in the project. I was brought in to 'pound code', which isn't my normal role in projects, but it is something I do enjoy immensely.
When I say we were pounding code, I really mean it. It's been at least eight years since I've been heads down, fully dedicated to doing nothing but coding. We built 80 screens to administer the site, and the front end was over 40. We assembly-lined the project, where I did the admin site and part of the data access layer, one developer focused on CSS and doing the grunt data access layer (99.9999% in LINQtoSQL), and one developer building the security, transaction auditing and credit card processing and the front end screens. Our QA tracked the issues and gave us feedback on every screen as it was completed (and sometimes before we completed it, to our chagrin), and we really made efficient use of time and resources. I didn't think we'd get it all done in time, but we really did, and met all of our customer's expectations, and blew them away with the site over all. Not bad for my first time. Luckily, we did have experience in the office on some of the tricks of the trade (cc processing and auditing), so we didn't have to work that all up from scratch, but still, we're pretty proud of what we got done.
These days, I'm starting to dig into a Windows Forms application which was built 4 years ago in C# using the Microsoft Application Blocks 1.0. We migrated it up to .NET 2.0 earlier this year, and now have some major enhancements to do to it. A lot of the code is auto generated from an XML file which documents the data objects, and while I can see that it kicks out a lot of code in a hurry, it also seems to saddle the application with a lot of code which may never be used. It does everything from creating the database objects and stored procedures to spinning up the Controllers and data objects. There's a lot of cookie cutter code left after that to do, and it makes it fairly easy to build, but it is missing some things, like database side referential integrity and really good error handling.
I've also touched on some Sharepoint development. Sharepoint's a product which is not ready for prime time when it comes to the development environment. It really feels kludged together and is very temperamental. The most often seen comment on Sharepoint support blogs when discussing some weird Sharepoint behavior is 'Welcome to Sharepoint Development'. That's a really bad sign. I was really disappointed because I'd heard such good things about it. Hopefully Sharepoint 2008 improves the situation.
My current reading is Pro WF: Windows Workflow in .NET 3.5 by Bruce Bukovics. I'm only in Chapter 3 right now, and while the content makes sense, I haven't yet figured out how to apply this to the real world. I need to make a leap in my brain, and right now, I'm only getting little hops. I was expecting something that really blew me away. So far, not so much. "Visual If Statements". Whoop-Tee-Doo. I'm sure in 5 Chapters, I'll know it' much more than that, but that's why I read the book. To learn.
The book I'm most looking forward to reading is Microsoft® .NET: Architecting Applications for the Enterprise. Hopefully this helps me to put it all together so I can see the big picture better.
Anyway, since I last updated this site, a lot has changed. I spent pretty much the whole month of May, and most of June, heads down in developing my first major e-commerce web site. I worked with two other developers and a QA, and we started out really far behind the eight-ball due to a number of staffing issues early in the project. I was brought in to 'pound code', which isn't my normal role in projects, but it is something I do enjoy immensely.
When I say we were pounding code, I really mean it. It's been at least eight years since I've been heads down, fully dedicated to doing nothing but coding. We built 80 screens to administer the site, and the front end was over 40. We assembly-lined the project, where I did the admin site and part of the data access layer, one developer focused on CSS and doing the grunt data access layer (99.9999% in LINQtoSQL), and one developer building the security, transaction auditing and credit card processing and the front end screens. Our QA tracked the issues and gave us feedback on every screen as it was completed (and sometimes before we completed it, to our chagrin), and we really made efficient use of time and resources. I didn't think we'd get it all done in time, but we really did, and met all of our customer's expectations, and blew them away with the site over all. Not bad for my first time. Luckily, we did have experience in the office on some of the tricks of the trade (cc processing and auditing), so we didn't have to work that all up from scratch, but still, we're pretty proud of what we got done.
These days, I'm starting to dig into a Windows Forms application which was built 4 years ago in C# using the Microsoft Application Blocks 1.0. We migrated it up to .NET 2.0 earlier this year, and now have some major enhancements to do to it. A lot of the code is auto generated from an XML file which documents the data objects, and while I can see that it kicks out a lot of code in a hurry, it also seems to saddle the application with a lot of code which may never be used. It does everything from creating the database objects and stored procedures to spinning up the Controllers and data objects. There's a lot of cookie cutter code left after that to do, and it makes it fairly easy to build, but it is missing some things, like database side referential integrity and really good error handling.
I've also touched on some Sharepoint development. Sharepoint's a product which is not ready for prime time when it comes to the development environment. It really feels kludged together and is very temperamental. The most often seen comment on Sharepoint support blogs when discussing some weird Sharepoint behavior is 'Welcome to Sharepoint Development'. That's a really bad sign. I was really disappointed because I'd heard such good things about it. Hopefully Sharepoint 2008 improves the situation.
My current reading is Pro WF: Windows Workflow in .NET 3.5 by Bruce Bukovics. I'm only in Chapter 3 right now, and while the content makes sense, I haven't yet figured out how to apply this to the real world. I need to make a leap in my brain, and right now, I'm only getting little hops. I was expecting something that really blew me away. So far, not so much. "Visual If Statements". Whoop-Tee-Doo. I'm sure in 5 Chapters, I'll know it' much more than that, but that's why I read the book. To learn.
The book I'm most looking forward to reading is Microsoft® .NET: Architecting Applications for the Enterprise. Hopefully this helps me to put it all together so I can see the big picture better.
Subscribe to:
Posts (Atom)
Posts
