One of the toughest things about being an application architect at a small company is needing to know everything about everything, yesterday. I'm working on a very large project right now, and I need to get in depth with a huge number of topics, all at once, just to get the project kicked off. Other parts of the team are sitting on their hands waiting for me to get stuff done, and I hate being a bottleneck. It makes for some very busy days where I don't seem to get a lot done, or get to know as much about a topic as I really need to to make sure I am pushing us in the right direction.
For instance, today was a fairly typical day.
I spent an hour reading through emails and blogs this morning as I ate my breakfast and chatted about the inauguration in my office.
I then reviewed a spec I had written yesterday on Security Authentication, Authorization and Threat Modelling for my project. I had to go back and dig into the Geneva Framework and the .NET Access Control Service to see how close I was to the mark. I've got a real fear that I need to become a lot more familiar with threat modelling before I can consider this spec complete, or I need to con someone else in the office into become the SME on Security.
I spent two hours writing an application specific functional spec for a WCF Based Azure Web Service, mostly dealing with the 'what' side of the house, i.e. what it's supposed to do, but leaving out the 'how', i.e. how it's going to do what it has to do. This particular piece of the project is one of the more important aspects because the service has to be very secure, has a lot of validation built into it to prevent corrupt data from being uploaded or downloaded, and I had to build in a migration path to eventually move from one version of the service to the next without breaking existing clients. I actually took the time to put a lot of thought into that mechanism, but the spec isn't close enough to be ready to turn over to a developer (unless it is me), because I didn't cover any of the aspects of Azure or Geneva that need to be covered in a 'how' spec.
I spent an hour and a half re-arranging projects in my Team Foundation Server project to try to get everything organized and clean, the way I want it. This involved changing some namespaces, and working through a real bastard of a problem involving a confusion between the Silverlight Unity Framework and the Windows Unity Framework. Somehow the Silverlight Unity DLL had been linked into one of the non-Silverlight projects, and nothing was compiling. This problem came on the heels of a similar issue yesterday where the ICommand interface I was using in one of my projects got linked to System.Windows.Input instead of the PresentationCore library. That cost me three hours yesterday. I really need to lock down my project files (usually from myself).
I then spent 2 hours delving back into the MVVM pattern for WPF development to figure out how exactly to launch dialog boxes and other windows from a view in the 'correct' way. Where exactly does the code go to 'new' the view, and which view model do you bind it to? That's a whole blog post unto itself. I've just started with the MVVM pattern, and it's powerful, but in trying to explain it to a junior dev, he kept asking me how the View Model in our scenario wasn't just a big global variable, albeit a global variable with a lot of pizazz. It's those type of questions that lead me to doubt my understanding of the pattern, and I ended up spending a lot more time trying to explain the pattern to myself again, but we all came away with a slightly more enlightened view.
I spent an hour this afternoon trying to turn an XSD file into classes using XSD.exe and then trying to figure out how to turn those classes into database tables. We probably should have gone the other way and started with tables, but that's a whole other discussion. I'll have to finish that task tomorrow.
I also spent twenty minutes trying to help our project manager tie TFS Work Items to MS Project properly. We want to have two different project plan views, one for internal use, and one, a higher level view, for the customer, but we don't want to maintain the tasks in two places. We're working through some theories on exactly how to do that. I've never used TFS prior to this project, so we're learning some interesting lessons.
Tomorrow, I need to get a handle on the project plan as it is due by Friday. I need to review the WCF spec I did, get the classes converted to database tables, spin up an entity framework model for them, dig into SDS and attempt to migrate a SQL 2008 Data model into SDS, and then I'll need to map that back to my Conceptual Object model in EF. That exercise is also an upcoming blog post. And oh yeah, I need to build out the Access Control functionality so I can set up the 'how to' spec for the WCF services. Right after I finish the first draft of some other functional specs for the other applications we're designing so the QA team can start writing their test plans.
Wednesday, January 21, 2009
Tuesday, January 20, 2009
Nerd Dinner, Recap
I didn't quite know what to expect when I decided to go to my first Nerd Dinner last night. I was a little nervous, a little intimidated, and a lot worried that I would look like a complete idiot. I shouldn't have been nervous. I was more in awe of the opportunity than intimidated by the folks there. And I hope I wasn't a complete idiot.
I got to meet Scott Hanselman right off the bat (He sat down next to me). To my left, was one of the architects of VB.NET. I spent time talking with them about LINQ to SQL and my experience with the Entity Framework, and Scott encouraged me to blog about my experience working with both in the real world. I'll try to do that as soon as I can catch my breath and test out one more feature of EF.
We shuffled seats every 15 minutes or so, and I took the opportunity to get to meet a bunch of folks on the F#, C#, VB.NET teams, as well as the Silverlight Teams (working on the Line Of Business Toolkit, something I am really excited about), and the Powershell/WPF Team. Everyone was so friendly, and genuinely interested in hearing about my projects, and giving pointers on how to do things a little better and a little easier.
The last group I sat down with included Glenn Block, the Project Lead for the Managed Extensibility Framework. We got into a deep discussion of test driven development, something I am working on implement at my company. He brought in a crowd of people to contribute to the discussion and I learned a lot! I wish I had written down everyone's names to thank them later. Here are some of the points they made, paraphrased of course. My ehad was spinnign by this point in the evening.
They stressed a couple of fundamentals for how to do it (we all understood why TDD is important).
1. There are two types of unit tests: functional tests, and acceptance or validation tests
2. Functional tests should be written by the developer as they are writing the code to exercise the code they are writing. They should still write the test before the code, but the two are written at roughly the same time. Test what you are coding so you know why you are coding it.
3. Validation Tests can be written by the QA’s to test edge cases and to try things to make the dev cry, but have the benefit of being repeatable to save the QA time from needing to show the developer exactly what they did to break the code.
This is a little different from my original understanding of TDD and how I had envisioned we would implement it, but they were quite clear that we were headed for trouble if we tried to let the QA’s write all the cases. Not because the QA’s couldn’t do it, it was that the developers lost the advantages of writing their own tests to help them understand the requirements they were developing against. It helps to make the code clear and concise and to expose code ‘smell’ early on in the process.
The QA’s can still help to identify and clarify the requirements of each function, but it’s not until the developer believes they have met the functional requirements of the component that the validation tests should begin.
Anyway, I hope to go to many more of these dinners, and highly recommend it for anyone who wants the opporutnity to talk with, and listen to some of the really big thinkers in the development industry. My head was spinning the whole way home.
I got to meet Scott Hanselman right off the bat (He sat down next to me). To my left, was one of the architects of VB.NET. I spent time talking with them about LINQ to SQL and my experience with the Entity Framework, and Scott encouraged me to blog about my experience working with both in the real world. I'll try to do that as soon as I can catch my breath and test out one more feature of EF.
We shuffled seats every 15 minutes or so, and I took the opportunity to get to meet a bunch of folks on the F#, C#, VB.NET teams, as well as the Silverlight Teams (working on the Line Of Business Toolkit, something I am really excited about), and the Powershell/WPF Team. Everyone was so friendly, and genuinely interested in hearing about my projects, and giving pointers on how to do things a little better and a little easier.
The last group I sat down with included Glenn Block, the Project Lead for the Managed Extensibility Framework. We got into a deep discussion of test driven development, something I am working on implement at my company. He brought in a crowd of people to contribute to the discussion and I learned a lot! I wish I had written down everyone's names to thank them later. Here are some of the points they made, paraphrased of course. My ehad was spinnign by this point in the evening.
They stressed a couple of fundamentals for how to do it (we all understood why TDD is important).
1. There are two types of unit tests: functional tests, and acceptance or validation tests
2. Functional tests should be written by the developer as they are writing the code to exercise the code they are writing. They should still write the test before the code, but the two are written at roughly the same time. Test what you are coding so you know why you are coding it.
3. Validation Tests can be written by the QA’s to test edge cases and to try things to make the dev cry, but have the benefit of being repeatable to save the QA time from needing to show the developer exactly what they did to break the code.
This is a little different from my original understanding of TDD and how I had envisioned we would implement it, but they were quite clear that we were headed for trouble if we tried to let the QA’s write all the cases. Not because the QA’s couldn’t do it, it was that the developers lost the advantages of writing their own tests to help them understand the requirements they were developing against. It helps to make the code clear and concise and to expose code ‘smell’ early on in the process.
The QA’s can still help to identify and clarify the requirements of each function, but it’s not until the developer believes they have met the functional requirements of the component that the validation tests should begin.
Anyway, I hope to go to many more of these dinners, and highly recommend it for anyone who wants the opporutnity to talk with, and listen to some of the really big thinkers in the development industry. My head was spinning the whole way home.
Friday, January 16, 2009
Nerd Dinner
Scott Hanselman is hosting the January Nerd Dinner in Bellevue, and it looks like I am going to be able to make it this time. I'm excited to get to meet all these folks that provide so many answers to my questions. If you see me there, and you ever read this blog, say hi if you see me.
Thursday, January 8, 2009
A New Year
Yesterday, was the one year anniversary of starting my new job. So at this point, I guess I can stop calling it my 'new' job, and just call it my job.
Professionally, it's been a whirlwind of a year, and 2009 looks to be even more of a technical blizzard. When 2008 started, I was pretty proficient at C#, knew Informix pretty well, and knew a lot about the airline business. But when I made the jump from the IT division at an airline, to a position as a Senior Systems Analyst for a small software consulting firm, I viwed to learn some new skills, and to really put my nose to the grind stone for a few months to get 'caught up' on technology. Little did I know that it's pretty much impossible to get 'caught up'. But here's what I did get experience in during 2008. This isn't just 'I read the book', but real, systems to production experience.
1. Visual Studio 2008
2. Resharper 4
3. LINQ to SQL
4. Microsoft Component Application Blocks (Version 1 for VS 2005)
5. The Model - View - Controller Pattern
6. SQL Server 2000
7. SQL Server 2005
8. ASP.NET 3.5
9. VB.NET
10. ASP.NET AJAX
11. SQL Reporting Services
All of that before the beginning of November 2008. I draw the line there, because in November, I started a new project that currently has me buried in the following technologies
1. WPF
2. Silverlight 2.0
3. SQL Server 2008
4. Team Foundation Services
5. MS Test & Test Driven Development
6. Microsoft Azure
7. Microsoft SQL Data Services
8. Microsoft Sync Framework
9. Microsoft Unity Dependency Injection Framework
10. Rhino Mock
11. Geneva / Microsoft Data Access Control Service
12. SQL Server CE
13. Microsoft Entity Framework
By the end of the year, I hope to be proficient in all of these topics. Actually, hope isn't a strong enough word. I need to be proficient in all of these topics. Right now, my head is spining a bit, and the new stuff is coming faster than my brain can absorb it all. But a year ago I had no idea what LINQ was, now I can't work without it.
I just have to wonder though. If this is what I have planned, what else could possibly come along later in the year?
Professionally, it's been a whirlwind of a year, and 2009 looks to be even more of a technical blizzard. When 2008 started, I was pretty proficient at C#, knew Informix pretty well, and knew a lot about the airline business. But when I made the jump from the IT division at an airline, to a position as a Senior Systems Analyst for a small software consulting firm, I viwed to learn some new skills, and to really put my nose to the grind stone for a few months to get 'caught up' on technology. Little did I know that it's pretty much impossible to get 'caught up'. But here's what I did get experience in during 2008. This isn't just 'I read the book', but real, systems to production experience.
1. Visual Studio 2008
2. Resharper 4
3. LINQ to SQL
4. Microsoft Component Application Blocks (Version 1 for VS 2005)
5. The Model - View - Controller Pattern
6. SQL Server 2000
7. SQL Server 2005
8. ASP.NET 3.5
9. VB.NET
10. ASP.NET AJAX
11. SQL Reporting Services
All of that before the beginning of November 2008. I draw the line there, because in November, I started a new project that currently has me buried in the following technologies
1. WPF
2. Silverlight 2.0
3. SQL Server 2008
4. Team Foundation Services
5. MS Test & Test Driven Development
6. Microsoft Azure
7. Microsoft SQL Data Services
8. Microsoft Sync Framework
9. Microsoft Unity Dependency Injection Framework
10. Rhino Mock
11. Geneva / Microsoft Data Access Control Service
12. SQL Server CE
13. Microsoft Entity Framework
By the end of the year, I hope to be proficient in all of these topics. Actually, hope isn't a strong enough word. I need to be proficient in all of these topics. Right now, my head is spining a bit, and the new stuff is coming faster than my brain can absorb it all. But a year ago I had no idea what LINQ was, now I can't work without it.
I just have to wonder though. If this is what I have planned, what else could possibly come along later in the year?
Subscribe to:
Posts (Atom)
Posts
