Visual Studio "Orcas" and .NET FX 3.5 Beta1 shipped!
You can read about it on Soma's blog.
Or go right to the MSDN page.
I'm sure there will be more on this later.
Showing posts with label Microsoft. Show all posts
Showing posts with label Microsoft. Show all posts
April 19, 2007
Visual Studio "Orcas" and .NET FX 3.5 Beta1 shipped!
You can read about it on Soma's blog.
Or go right to the MSDN page.
I'm sure there will be more on this later.
April 12, 2007
ProClarity via MSDN
For all of you with MSDN subscriptions, you should now be able to download the ProClarity product line from the MSDN web site (version 6.3).
No word on whether Microsoft will mail out CDs...but is that really that important anymore?
Personally, I think this is wonderful news. Anything to get a wider base for ProClarity is good by me.
Do note: I am a former ProClarity employee, I'm sure there is still a fair amount of my code running around the desktop product...and I'm available for consulting! :)
No word on whether Microsoft will mail out CDs...but is that really that important anymore?
Personally, I think this is wonderful news. Anything to get a wider base for ProClarity is good by me.
Do note: I am a former ProClarity employee, I'm sure there is still a fair amount of my code running around the desktop product...and I'm available for consulting! :)
March 23, 2007
PLinq out of the bag
First off, a definition: PLINQ is Parallel LINQ. It allows you to run LINQ commands in parallel with minimal effort.
I didn't know this was out of NDA yet, but I just saw some links on MSDN's C# Developer Center.
PLINQ is being discussed in the wild!
I first heard about this at Microsoft's MVP Summit in a talk that Anders Hejlsberg was giving. It was probably one of two of the coolest things I saw at the MVP Summit (and the other will have to wait a while longer before I talk about it here).
Anyway, here are a few more links I've found on PLINQ:
http://themechanicalbride.blogspot.com/2007/03/dreaming-of-plinq.html
http://www.bluebytesoftware.com/blog/PermaLink,guid,81ca9c00-b43e-4860-b96b-4fd2bd735c9f.aspx
http://www.eweek.com/article2/0,1759,2009167,00.asp?kc=EWRSS03119TX1K0000594
I will be posting more about this later.
I didn't know this was out of NDA yet, but I just saw some links on MSDN's C# Developer Center.
PLINQ is being discussed in the wild!
I first heard about this at Microsoft's MVP Summit in a talk that Anders Hejlsberg was giving. It was probably one of two of the coolest things I saw at the MVP Summit (and the other will have to wait a while longer before I talk about it here).
Anyway, here are a few more links I've found on PLINQ:
http://themechanicalbride.blogspot.com/2007/03/dreaming-of-plinq.html
http://www.bluebytesoftware.com/blog/PermaLink,guid,81ca9c00-b43e-4860-b96b-4fd2bd735c9f.aspx
http://www.eweek.com/article2/0,1759,2009167,00.asp?kc=EWRSS03119TX1K0000594
I will be posting more about this later.
March 22, 2007
An Open Letter to Scott Guthrie on Elegant Code
OK, this post is just too good. Even better since I know the guy posting it.
It is a really worth a read: http://elegantcode.com/?p=539
October 03, 2006
Golden Rules of OLAP
I've been meaning to say this for a while now...
When working with an OLAP tool (say Microsoft Analysis Services 2005 -- or 2000 -- or Hyperion -- or any OLAP tool under the sun) there are three guiding principles.
#1: Know your data. It doesn't matter how snazzy your tools are, how good looking your web site/reports are if all the data is meaningless to you. Yes, it might mean something to your customer, but until it means something to you, you are going to have a hard time really helping the customer.
#2. Know your display tools. Depending on what tool your customers are going to use to see the data, it will change how you construct your cubes and dimensions. There are things you can get away with when your client is ProClarity that are a bad idea for Reporting Services, and a terrible idea for Excel.
Case in point is the naming of attribute dimensions. You might have a dimension named Project with an attribute hierarchy named "Name". Seems logical. Then you also have a Customer dimension with a "Name" attribute hierarchy. So in ProClarity or Reporting Services you will see the nice Project.Name and Customer.Name hierarchies. In Excel (via pivot , you will see "Name" and "Name". Not very helpful. So you have to name your attribute hierarchies "Project Name" and "Customer Name" to keep the Excel Pivot table people off of you back.
#3. Regardless of what tool your customer says they are going to use, always test the data in Excel -- especially Date dimension data. Why? Because some customer will always want to see the data in excel. They don't care that all the data is already in some other tool nice and formatted and pretty, if the data isn't in Excel it isn't useful to them. Just deal with it, you can't cant change their minds.
Also, be sure to test how your date dimension data looks when exported to excel. Excel has this helpful habit of looking at your data, seeing a date, and then formatting it incorrectly. What starts out as April 02 (for April 2002) is suddenly transformed into April 2, 2006. And you will be blamed for this. Not Excel. No, not our precious Excel that can do no wrong (quiet next time, it might hear you). You are in the wrong and must fix this error. And the fix is a four digit year which will anger someone else -- but you will get used to that.
I hope this becomes helpful to someone, it was a painful process for me to get to this point myself.
When working with an OLAP tool (say Microsoft Analysis Services 2005 -- or 2000 -- or Hyperion -- or any OLAP tool under the sun) there are three guiding principles.
#1: Know your data. It doesn't matter how snazzy your tools are, how good looking your web site/reports are if all the data is meaningless to you. Yes, it might mean something to your customer, but until it means something to you, you are going to have a hard time really helping the customer.
#2. Know your display tools. Depending on what tool your customers are going to use to see the data, it will change how you construct your cubes and dimensions. There are things you can get away with when your client is ProClarity that are a bad idea for Reporting Services, and a terrible idea for Excel.
Case in point is the naming of attribute dimensions. You might have a dimension named Project with an attribute hierarchy named "Name". Seems logical. Then you also have a Customer dimension with a "Name" attribute hierarchy. So in ProClarity or Reporting Services you will see the nice Project.Name and Customer.Name hierarchies. In Excel (via pivot , you will see "Name" and "Name". Not very helpful. So you have to name your attribute hierarchies "Project Name" and "Customer Name" to keep the Excel Pivot table people off of you back.
#3. Regardless of what tool your customer says they are going to use, always test the data in Excel -- especially Date dimension data. Why? Because some customer will always want to see the data in excel. They don't care that all the data is already in some other tool nice and formatted and pretty, if the data isn't in Excel it isn't useful to them. Just deal with it, you can't cant change their minds.
Also, be sure to test how your date dimension data looks when exported to excel. Excel has this helpful habit of looking at your data, seeing a date, and then formatting it incorrectly. What starts out as April 02 (for April 2002) is suddenly transformed into April 2, 2006. And you will be blamed for this. Not Excel. No, not our precious Excel that can do no wrong (quiet next time, it might hear you). You are in the wrong and must fix this error. And the fix is a four digit year which will anger someone else -- but you will get used to that.
I hope this becomes helpful to someone, it was a painful process for me to get to this point myself.
Subscribe to:
Posts (Atom)