So Dan Miser tagged me to carry on the 5 things you didn't know about me. So here goes.
1) The first computer I had was an Apple IIe and the first program I wrote on it was a game called lemon catch. The idea was to move along the bottom of the screen catching falling lemons. It really wasn't that hard of a game, but I was only 8 or 9.
2) When I went away to college, I wanted to be a physical therapist. Unfortunetly I did not enjoy my 7:00 am Friday lab so I dropped the class and changed majors. I think I remember saying "How hard could computer science be?".
3) The Dilbert cartoon still makes me laugh and I wish it was still on TV.
4) I have had the same number of Apple/Macintosh computers as I have had Windows/Dos computers. 3 each. On the apple side I had IIe, Mac LC, and a Duo 230. On the windows side, I had a non name brand Pro 200 pc, and of course a Dell, and a HP.
5) I have a blog. According to Google Analytics, I get roughly 5 visitors a month.
So now that you know 5 more things bout me I get to tag some people. I am going to tag James Roome, Brian Kapellusch, Cobbie Berhend, and Vibhu Srinivasan
Monday, January 22, 2007
Friday, January 19, 2007
Compact Framework Woes
So as I discussed in previous blogs, at work I have been doing mobile development using .Net 2.0 and the Compact Framework (CF). For the most part I have found the compact framework fulfills about 90% of our needs. However the remaining 10% of our needs causes a lot of headaches for our team.
I understand the need for the CF to remain compact but it is surprising some of the things that were left out of it. A great example of this is form and control loading. In a WinForms project using the full framework; Forms and UserControls inherit from Control. Control implements a Load event. So this causes Forms and UserControls to have a Load event that is fired shortly before the control or form is loaded on the screen. So if you are creating your UI dynamically at runtime, you have a way to set properties before displaying but after construction.
In the CF, Control does not implement Load. Load is only implemented on the Form. Controls have a Paint event that can be used to do the setting of properties. Most people will say see the CF still allows you to do what you need, but here is the rub.
Besides not being consistent, let's say this dynamic UI needs to be somewhat portable so that it will run on a mobile device and on a PC. the code will run nicely on the hand held device, but on the PC you get this flickering coming from the controls because the use of the Paint event.
So to solve this problem what I did was rather simple, but really tedious. Since in CF you do have a Load event on the Form, I decided to use that. Every UserControl that can be placed dynamically on a form sets the Load event. This was a bit harder than I thought it would be because my natural thought was to do the following in a method that could be called during setup of the control but before loading of the form...
Parent.Load += new System.EventHandler(Control_Load);
or
((Form)Parent).Load += new System.EventHandler(Control_Load);
Since the parent is really a Control type, and casting it as Form could be dangerous because the controls parent could be a TabPage or a Panel, I ended up setting the form as an attribute on a base class of all these dynamic control and ended up setting the event like this...
this.ParentForm.Load += new System.EventHandler(Control_Load);
This solution will allow for this dynamic approach to work both on mobile devices and PCs.
There are other places in the CF where the implementation differs greatly from the full framework. For example threading, but that is a discussion for another day.
I understand the need for the CF to remain compact but it is surprising some of the things that were left out of it. A great example of this is form and control loading. In a WinForms project using the full framework; Forms and UserControls inherit from Control. Control implements a Load event. So this causes Forms and UserControls to have a Load event that is fired shortly before the control or form is loaded on the screen. So if you are creating your UI dynamically at runtime, you have a way to set properties before displaying but after construction.
In the CF, Control does not implement Load. Load is only implemented on the Form. Controls have a Paint event that can be used to do the setting of properties. Most people will say see the CF still allows you to do what you need, but here is the rub.
Besides not being consistent, let's say this dynamic UI needs to be somewhat portable so that it will run on a mobile device and on a PC. the code will run nicely on the hand held device, but on the PC you get this flickering coming from the controls because the use of the Paint event.
So to solve this problem what I did was rather simple, but really tedious. Since in CF you do have a Load event on the Form, I decided to use that. Every UserControl that can be placed dynamically on a form sets the Load event. This was a bit harder than I thought it would be because my natural thought was to do the following in a method that could be called during setup of the control but before loading of the form...
Parent.Load += new System.EventHandler(Control_Load);
or
((Form)Parent).Load += new System.EventHandler(Control_Load);
Since the parent is really a Control type, and casting it as Form could be dangerous because the controls parent could be a TabPage or a Panel, I ended up setting the form as an attribute on a base class of all these dynamic control and ended up setting the event like this...
this.ParentForm.Load += new System.EventHandler(Control_Load);
This solution will allow for this dynamic approach to work both on mobile devices and PCs.
There are other places in the CF where the implementation differs greatly from the full framework. For example threading, but that is a discussion for another day.
Tuesday, January 16, 2007
Microsoft Team System(cont)
So this is the next post in my team system posts.
I have been working with Team System at work. Although right now we only use it learning. We are not currently running any projects with it. That said, here are some of my experiences with it so far. In this post I will discus working with work items.
A work item is nothing more than a description of work. Some one on the team will enter a work item into the system. If using Agile this item could be a bug, a new task, Risk, scenario, or quality of service requirement. I have only worked with tasks, although in the next few days I plan on creating risks, and quality of service requirements.
When creating a task I used studio. Microsoft says that excel and project both integrate with team system, however I was having trouble using both tools. When using project I could not get it to publish new work items back to the server. It always failed. I was rather disappointed, however I found when working in studio worked fine for me. I am not a Project Manager and so I really only need the work items to be tracked, and assignable to team members.
When creating new work items, you can define your task. Basically you give it a title, a description, assign it to someone on the team, set the items discipline, and define the iteration the item should be worked on. Additionally you can add documents, link it to other work items, view history, and set other details like remaining work hours, start date, and things like that.
Once the item is saved, there are many in the box queries that can be run in studio to view work items. for most people I would guess they would run the my work items query however certain roles may choose to run other queries like the all the work items, or active bugs, resolved bugs, or queries like that.
As a team member works on work items, they can update information and forward the items to other team members or close the items. Closed items can be reopened as needed.
So here comes my opinion. Yes the tool will meet most needs of item tracking. Have I seen tools that do it better, yes, however if you are doing DotNet, the intergration of these tools in studio is really nice. I currently use Jira and Confluence for these types of activities and although I like the interfaces, the fact they don't integrate to well with studio annoys me.
So that is what I have learned. I wish I could share more about integration with the web portal and other ms tools. In future posts I will be talking about other areas of team system.
I have been working with Team System at work. Although right now we only use it learning. We are not currently running any projects with it. That said, here are some of my experiences with it so far. In this post I will discus working with work items.
A work item is nothing more than a description of work. Some one on the team will enter a work item into the system. If using Agile this item could be a bug, a new task, Risk, scenario, or quality of service requirement. I have only worked with tasks, although in the next few days I plan on creating risks, and quality of service requirements.
When creating a task I used studio. Microsoft says that excel and project both integrate with team system, however I was having trouble using both tools. When using project I could not get it to publish new work items back to the server. It always failed. I was rather disappointed, however I found when working in studio worked fine for me. I am not a Project Manager and so I really only need the work items to be tracked, and assignable to team members.
When creating new work items, you can define your task. Basically you give it a title, a description, assign it to someone on the team, set the items discipline, and define the iteration the item should be worked on. Additionally you can add documents, link it to other work items, view history, and set other details like remaining work hours, start date, and things like that.
Once the item is saved, there are many in the box queries that can be run in studio to view work items. for most people I would guess they would run the my work items query however certain roles may choose to run other queries like the all the work items, or active bugs, resolved bugs, or queries like that.
As a team member works on work items, they can update information and forward the items to other team members or close the items. Closed items can be reopened as needed.
So here comes my opinion. Yes the tool will meet most needs of item tracking. Have I seen tools that do it better, yes, however if you are doing DotNet, the intergration of these tools in studio is really nice. I currently use Jira and Confluence for these types of activities and although I like the interfaces, the fact they don't integrate to well with studio annoys me.
So that is what I have learned. I wish I could share more about integration with the web portal and other ms tools. In future posts I will be talking about other areas of team system.
Thursday, January 11, 2007
Apple iPhone
So Apple had their big keynote address. Steve Jobs got in front of all the fanboys, and fangirls and announced a bunch of new products. The product getting the most press right now is the iPhone.
The iPhone has been rumored in the works for the last year. It basically is the morphing of a video iPod and a cell phone. For $499 + a 2 year Cingular wireless contract you can get a 4gb version. For $599 you can up that to 8gb. The phone also has some other useful things like a large touch screen, Bluetooth, WiFi, a 2 mega pixel camera and other applications like Google Maps, Safari, and iTunes (of course) with CoverFlow. Jobs said the phone will ship in June if you live in the US.
Now lets break this down a bit.
First, it is not a smart phone. There does not seem to be SDKs to support third party development. For example, where I work we do a lot of business applications that run on pocket pcs, this includes devices that have phones. By not allowing for third party development I believe the business world will not adopt this phone. So that only leaves consumers as buyers. I realize there are many people out there ready to waste money on this product but most consumers will find cheaper alternatives that offers similar options. I personally don't want or need a smart phone, so this is not the deal breaker for me.
The deal breaker for me is the iPhone ties you to Cingular wireless. Where I live Cingular provides terrible coverage. Sure Milwaukee is in there plan, and has good quality, but If I want to visit my parents, I might as well leave my phone at home. In fact you venture to far from our interstate highways, you lose coverage quickly. So Even if I wanted to drop $499 for a phone, I would never sign a contract with Cingular.
So a quick wrap up.
On the plus side...
Again I have not been given one of these to test nor have I been paid by anyone to give this review. I recieved my information from other websites, like Apple.com and Cingular.com. Also information was provided by Cingular users who phones do not work at my parents house or other places in Wisconsin.
The iPhone has been rumored in the works for the last year. It basically is the morphing of a video iPod and a cell phone. For $499 + a 2 year Cingular wireless contract you can get a 4gb version. For $599 you can up that to 8gb. The phone also has some other useful things like a large touch screen, Bluetooth, WiFi, a 2 mega pixel camera and other applications like Google Maps, Safari, and iTunes (of course) with CoverFlow. Jobs said the phone will ship in June if you live in the US.
Now lets break this down a bit.
First, it is not a smart phone. There does not seem to be SDKs to support third party development. For example, where I work we do a lot of business applications that run on pocket pcs, this includes devices that have phones. By not allowing for third party development I believe the business world will not adopt this phone. So that only leaves consumers as buyers. I realize there are many people out there ready to waste money on this product but most consumers will find cheaper alternatives that offers similar options. I personally don't want or need a smart phone, so this is not the deal breaker for me.
The deal breaker for me is the iPhone ties you to Cingular wireless. Where I live Cingular provides terrible coverage. Sure Milwaukee is in there plan, and has good quality, but If I want to visit my parents, I might as well leave my phone at home. In fact you venture to far from our interstate highways, you lose coverage quickly. So Even if I wanted to drop $499 for a phone, I would never sign a contract with Cingular.
So a quick wrap up.
On the plus side...
- the phone looks cool
- has a new interface
- nice set of applications
- Cingular
- Cost
- No third party development
- Small amount of memory
Again I have not been given one of these to test nor have I been paid by anyone to give this review. I recieved my information from other websites, like Apple.com and Cingular.com. Also information was provided by Cingular users who phones do not work at my parents house or other places in Wisconsin.
Subscribe to:
Posts (Atom)