Vista Sync Toy.
Since I use a USB drive for data backup, one of my favorite XP programs is SyncToy from Microsoft. Now that I am using Vista I missed this tool, so I was very happy to find SyncToy 1.4 which works with Vista!
http://www.microsoft.com/downloads/details.aspx?familyid=E0FC1154-C975-4814-9649-CCE41AF06EB7&displaylang=en
Tuesday, January 30, 2007
Sunday, January 21, 2007
So a few weeks little Avery was running around and snapped my wife’s iPod Shuffle off her USB port. So she went out and bought a new one, and WOW. So this thing is 1 GB, rectangular in shape, and has a built-in clip. The biggest complaint I had with my Creative Zen is its size, trying to work out and/or run with the Zen is like attaching a small brick to my shorts, and I’ve dropped it several times resulting in the belt clip breaking. So today, my lovely wife surprised me with a new iPod. So my allegiance to Microsoft notwithstanding, I think I am going to love this thing! I can just clip it on my sleeve and the weight is negligible. I am still not sure how it will work with my music, stay tuned!
Friday, January 19, 2007
So for some reason I have lost my icons for Office, Office Documents, and Acrobat documents in Vista.
http://www.mscrmguy.com/vista_icons.html
Hmmm....
http://www.mscrmguy.com/vista_icons.html
Hmmm....
Thursday, January 18, 2007
I found this 8th Grade Math test via Ben Riga's Blog
You Passed 8th Grade Math
Congratulations, you got 10/10 correct!
I always knew that 5-year engineering degree would come in handy! :)
I recently saw a hypothetical situation which described an ISV who has developed a solution on Java Servlets and they are thinking about moving to MSCRM.
Here is a condensed version of how I would go about addressing this question.
First we need to find out some info about where they are today.
1. The first question I would ask is why they chose to develop with only servlets, which are traditionally a presentation layer technology, and not utilize features such as EJBs
2. I would next ask about vendors, who the web server is, what about the servlet container, is there an application server, etc. Usually those come from several sources and can be used to create some FUD around who is supporting this application, what about licensing costs of any servers, this gets passed on to the end-use resulting in higher costs. This could relate back to #1. Servlet containers can be had for free whereas full-fledged J2EE App Servers generally have high costs associated with them ala WebSphere!
3. I would next ask about their team, do they have developers who are aligned with the technology directions? What are their skill sets, if any? For all we know they could have outsourced the entire project which leads to whole different set of questions and issues! Sometimes, more often than not, it turns out a very small team of people have developed the code base, no one has documented anything, and they are not sure where the code is!
4. Are they keen to leverage some of their existing work, most probably yes, any J2EE project is a substantial work so if we can re-use some work as part of a migration strategy then great.
So those are 4 main questions which generally lead to more questions as we dig into their environment. Some strengths of the MSFT platform I usually address are:
1. People love to say Microsoft solutions are proprietary, but most people do not understand the difference between Open Source and Open Standards. For example, MSCRM adheres to open standards such as the Web Services Interoperability Basic Profile 1.1, and the utilization of a SaaS architecture for its API. This means that if an ISV embarks on a substantial project customizing MSCRM, the tools and APIs they would use, all from Microsoft, lend themselves to maintainability. If, half-way through a project the team lost some people, it is relatively easy to replace those people and ramp them up due to the consistencies of the Microsoft tools. Not so the J2EE environment where in this example we might have 5 different vendors, and the code to tie all those vendors together was probably custom written by someone on the project., In this scenario companies find themselves locked to a proprietary solution not from 1 company, but proprietary to 1 *person*!
2. What about future directions? Who are the vendors, what are their future plans, who is maintaining the products they use in their solution in the future? Let’s say they chose a more obscure servlet container suck as Gemstone/J. What happens if Gemstone goes out of business? Although Java promised a “write once, run anywhere” paradigm, the reality is this was not the case and changes almost certainly have to be made when porting from one app server to another. Similarly, what if they chose an open source container for cost reasons, and then find they need to go to a paid product? This could drive the costs of the project beyond acceptable limits. With the Microsoft platform, the web server and application server are IIS and .NET technology, a fully supported platform from Microsoft.
3. Future enhancements to their products? They develop a solution for HR, so I am betting there are *lots* of paper forms involved. This can be a logistical and storage nightmare, so what about possibly extending the solution to include document management via Sharepoint Team Services? This is yet another Microsoft product, so incorporating this into their solution (once it is developed using .NET) would be a lot less labor intensive than if they tried to hook into Sharepoint using their current servlet implementation. And I wouldn’t even want to begin to estimate what it might take to find an open source Sharepoint equivalent or develop one from scratch. In fact, a guy from Canada even has step-by-step instructions on his blog on how to hook MSCRM and Sharepoint together! J
4. If their in-house team has Java development skills, the transition to .NET will be relatively painless due to the language support. The team could use C# which is so syntactically similar to Java that I have seen Java developers productive with the language in as little as 1 day. Or their in-house team might have VB people who were not used for the current project, but could be utilized with greater productivity when they start developing with .NET.
5. By utilizing MSCRM as the basis for their development, they can significantly decrease the time it takes to implement new features. MSCRM has extensive built-in functionality that would otherwise need to be developed from scratch, so instead of concentrating on the “plumbing” the ISV can do what they do best, develop a solution based on their area of expertise and spend their time adding value to the solution.
So let’s assume the ISV likes what they hear and are interested in beginning to look at the platform, but want to leverage some of their existing technology as they transition. I would suggest a phased migration, utilizing the interoperability features of .NET to allow them to exploit the work they have done on the presentation layer using Servlets, and being by hooking their servlets into the MSCRM business logic layer via web services interoperability. Something like this:
With the business and data tiers being provided by MSCRM.
Here is a condensed version of how I would go about addressing this question.
First we need to find out some info about where they are today.
1. The first question I would ask is why they chose to develop with only servlets, which are traditionally a presentation layer technology, and not utilize features such as EJBs
2. I would next ask about vendors, who the web server is, what about the servlet container, is there an application server, etc. Usually those come from several sources and can be used to create some FUD around who is supporting this application, what about licensing costs of any servers, this gets passed on to the end-use resulting in higher costs. This could relate back to #1. Servlet containers can be had for free whereas full-fledged J2EE App Servers generally have high costs associated with them ala WebSphere!
3. I would next ask about their team, do they have developers who are aligned with the technology directions? What are their skill sets, if any? For all we know they could have outsourced the entire project which leads to whole different set of questions and issues! Sometimes, more often than not, it turns out a very small team of people have developed the code base, no one has documented anything, and they are not sure where the code is!
4. Are they keen to leverage some of their existing work, most probably yes, any J2EE project is a substantial work so if we can re-use some work as part of a migration strategy then great.
So those are 4 main questions which generally lead to more questions as we dig into their environment. Some strengths of the MSFT platform I usually address are:
1. People love to say Microsoft solutions are proprietary, but most people do not understand the difference between Open Source and Open Standards. For example, MSCRM adheres to open standards such as the Web Services Interoperability Basic Profile 1.1, and the utilization of a SaaS architecture for its API. This means that if an ISV embarks on a substantial project customizing MSCRM, the tools and APIs they would use, all from Microsoft, lend themselves to maintainability. If, half-way through a project the team lost some people, it is relatively easy to replace those people and ramp them up due to the consistencies of the Microsoft tools. Not so the J2EE environment where in this example we might have 5 different vendors, and the code to tie all those vendors together was probably custom written by someone on the project., In this scenario companies find themselves locked to a proprietary solution not from 1 company, but proprietary to 1 *person*!
2. What about future directions? Who are the vendors, what are their future plans, who is maintaining the products they use in their solution in the future? Let’s say they chose a more obscure servlet container suck as Gemstone/J. What happens if Gemstone goes out of business? Although Java promised a “write once, run anywhere” paradigm, the reality is this was not the case and changes almost certainly have to be made when porting from one app server to another. Similarly, what if they chose an open source container for cost reasons, and then find they need to go to a paid product? This could drive the costs of the project beyond acceptable limits. With the Microsoft platform, the web server and application server are IIS and .NET technology, a fully supported platform from Microsoft.
3. Future enhancements to their products? They develop a solution for HR, so I am betting there are *lots* of paper forms involved. This can be a logistical and storage nightmare, so what about possibly extending the solution to include document management via Sharepoint Team Services? This is yet another Microsoft product, so incorporating this into their solution (once it is developed using .NET) would be a lot less labor intensive than if they tried to hook into Sharepoint using their current servlet implementation. And I wouldn’t even want to begin to estimate what it might take to find an open source Sharepoint equivalent or develop one from scratch. In fact, a guy from Canada even has step-by-step instructions on his blog on how to hook MSCRM and Sharepoint together! J
4. If their in-house team has Java development skills, the transition to .NET will be relatively painless due to the language support. The team could use C# which is so syntactically similar to Java that I have seen Java developers productive with the language in as little as 1 day. Or their in-house team might have VB people who were not used for the current project, but could be utilized with greater productivity when they start developing with .NET.
5. By utilizing MSCRM as the basis for their development, they can significantly decrease the time it takes to implement new features. MSCRM has extensive built-in functionality that would otherwise need to be developed from scratch, so instead of concentrating on the “plumbing” the ISV can do what they do best, develop a solution based on their area of expertise and spend their time adding value to the solution.
So let’s assume the ISV likes what they hear and are interested in beginning to look at the platform, but want to leverage some of their existing technology as they transition. I would suggest a phased migration, utilizing the interoperability features of .NET to allow them to exploit the work they have done on the presentation layer using Servlets, and being by hooking their servlets into the MSCRM business logic layer via web services interoperability. Something like this:
With the business and data tiers being provided by MSCRM.
Sunday, January 14, 2007
2007/01/14
So the phone system at work is an IP system, and a particularly cool feature is that when I get a voicemail it comes to my email inbox. However with every cool feature comes more frustration – the VMs are saved in WAV format, which doesn’t play back on WM 10 Mobile (or whatever version is on my WM 5 Smartphone). Why is that? I have no idea.
So after a Live search (www.live.com) I found a really cool mobile player that plays WAV files:
http://tcpmp.corecodec.org/download
So the phone system at work is an IP system, and a particularly cool feature is that when I get a voicemail it comes to my email inbox. However with every cool feature comes more frustration – the VMs are saved in WAV format, which doesn’t play back on WM 10 Mobile (or whatever version is on my WM 5 Smartphone). Why is that? I have no idea.
So after a Live search (www.live.com) I found a really cool mobile player that plays WAV files:
http://tcpmp.corecodec.org/download
Subscribe to:
Posts (Atom)
