New to VS 2010 and Framework 4.0 is a new protocol: WTF
WTF stands for Web Transport Feature and is a means of publishing and consuming REST-style data to the cloud.
I experimented with it today. I coded a simple WCF service with an OperationContract and pressed F5. Visual Studio then crashed and restarted. WTF?! Yes, it was WTF. WTF is synchronous - if a transaction is interrupted the entire operation is cancelled. WTF!
Yes, I exclaimed WTF! a lot today.
(Surely you didn't take this seriously?)
Thursday, August 27, 2009
WCF Localhost Gotcha
.Net Framework 3.5 SP1
Beware the WCF Configuration tool in Visual Studio. Auto-magic gone awry. If you make any configuration changes and save them, it will place a certificate tag in your web.config that will blow away your ability to run your service through localhost.
The solution is: Nuke the tag.
This cost me 2 hours of research.
Beware the WCF Configuration tool in Visual Studio. Auto-magic gone awry. If you make any configuration changes and save them, it will place a certificate tag in your web.config that will blow away your ability to run your service through localhost.
The solution is: Nuke the tag.
This cost me 2 hours of research.
Wednesday, August 26, 2009
So Now Visual Studio Insults Me?
'
' This code was generated by a tool.
' Runtime Version:2.0.50727.42
Sigh.
' This code was generated by a tool.
' Runtime Version:2.0.50727.42
Sigh.
Thursday, August 20, 2009
VFP to .NET Developer Survival Guide
Reported from the Universalthread. I had a lot of positive response so I am reposting here:
Folks,I'm going to keep this simple. Early last year I went on haitus as a test engineer and moved back into the developer world. I was fortunate that I was hired by a company that I had already worked with years ago and they re-hired me by past reputation and were willing to overlook the fact that my last relevent programming experience was .Net 1,0 and sketchy with that and needed time to ramp-up.
I know a lot of you don't have that advantage and employers are looking for immediately usable skills. Especially in this economy. So I am going to suggest a series of steps to gain a foundation that you can use to get to where you need to be. I'm assuming that you're willing to bust butt on your own time while doing what you have to do to pay the bills.
Also, I don't want to take anything away from the EDS or Oak Leaf bootcamps and training. My only concern with those is that they go a mile wide but an inch deep. I'm not clear what marketable skills you gain with practical application.So here are the lessons I've learned and my suggestions. They are not all-inclusive. They are not expert. They are just what has helped me and the pitfalls I've run into and how you can mitigate them.
1. Language is irrelevent when at the ground-level. Walk away from the C# versus VB argument. From the VFP perspective, VB.NET is easier to understand and 99% as functional. What you'll find as you get more proficient is that it's just as easier to understand or code in either. So focus on VB.Net. Once you understand VB code without a reference manual, C# will make sense and you'll find yourself pretty much equally adept at either.
2. Get foundational literature. Anything by Charles Petzold works for me (the Programming Windows series, for example). I found myself using old functions like Str() because I could when I should have been thinking x.ToString. I had to make a mental effort to break that pattern and it really pays off as you get more into the complex Framework types.
3. Get a buddy. You are going to have, from a .NET developers perspective, stupid questions. It's inevitable. Have someone or someones who are willing to answer your seemingly dumb questions without issue.
4. Ignore the bleeding edge. If building a basic ASP.NET page befuddles you, you have no business looking at Silverlight or cloud computing. Get confident in the basics and it'll add tremendously to your understanding of the other stuff.
5. Set a functional goal. If an employer is not already paying you to do so, finf something simple worth doing and code your first project towards that. Or convert your simplest VFP app.
6. Apply Extreme Programming (XP) principles. Your first app may work but your code will suck. So what? One ot the tenets to XP is to refactor until good. Once something works, refactor towards best practices. If you break it,so what? Revert to working code.
7. Do not assume examples on the Web are canon, In the old Fox world, for the most part, people only posted code that they knew worked. Not so these days - there is a lot of crap out there. Take the ideas to heart as presented but be very leery of the code - especially if it's using Northwind or AdventureWorks since those dbs seem to be the refuges of the semi-competent.
8. Take pride of ownership, If you're a good VFP developer you will be a good .NET developer. Be proud of making things that work no matter how minor. You'll get better because if you've already mastered VFP then .NET is just a different syntax.
9. Give it time. Don't get frustrated, Think about how long it took you to master what you already know and expect another learning curve here as well. Not all skills are transportable to .NET from VFP but common sense is.
Folks,I'm going to keep this simple. Early last year I went on haitus as a test engineer and moved back into the developer world. I was fortunate that I was hired by a company that I had already worked with years ago and they re-hired me by past reputation and were willing to overlook the fact that my last relevent programming experience was .Net 1,0 and sketchy with that and needed time to ramp-up.
I know a lot of you don't have that advantage and employers are looking for immediately usable skills. Especially in this economy. So I am going to suggest a series of steps to gain a foundation that you can use to get to where you need to be. I'm assuming that you're willing to bust butt on your own time while doing what you have to do to pay the bills.
Also, I don't want to take anything away from the EDS or Oak Leaf bootcamps and training. My only concern with those is that they go a mile wide but an inch deep. I'm not clear what marketable skills you gain with practical application.So here are the lessons I've learned and my suggestions. They are not all-inclusive. They are not expert. They are just what has helped me and the pitfalls I've run into and how you can mitigate them.
1. Language is irrelevent when at the ground-level. Walk away from the C# versus VB argument. From the VFP perspective, VB.NET is easier to understand and 99% as functional. What you'll find as you get more proficient is that it's just as easier to understand or code in either. So focus on VB.Net. Once you understand VB code without a reference manual, C# will make sense and you'll find yourself pretty much equally adept at either.
2. Get foundational literature. Anything by Charles Petzold works for me (the Programming Windows series, for example). I found myself using old functions like Str() because I could when I should have been thinking x.ToString. I had to make a mental effort to break that pattern and it really pays off as you get more into the complex Framework types.
3. Get a buddy. You are going to have, from a .NET developers perspective, stupid questions. It's inevitable. Have someone or someones who are willing to answer your seemingly dumb questions without issue.
4. Ignore the bleeding edge. If building a basic ASP.NET page befuddles you, you have no business looking at Silverlight or cloud computing. Get confident in the basics and it'll add tremendously to your understanding of the other stuff.
5. Set a functional goal. If an employer is not already paying you to do so, finf something simple worth doing and code your first project towards that. Or convert your simplest VFP app.
6. Apply Extreme Programming (XP) principles. Your first app may work but your code will suck. So what? One ot the tenets to XP is to refactor until good. Once something works, refactor towards best practices. If you break it,so what? Revert to working code.
7. Do not assume examples on the Web are canon, In the old Fox world, for the most part, people only posted code that they knew worked. Not so these days - there is a lot of crap out there. Take the ideas to heart as presented but be very leery of the code - especially if it's using Northwind or AdventureWorks since those dbs seem to be the refuges of the semi-competent.
8. Take pride of ownership, If you're a good VFP developer you will be a good .NET developer. Be proud of making things that work no matter how minor. You'll get better because if you've already mastered VFP then .NET is just a different syntax.
9. Give it time. Don't get frustrated, Think about how long it took you to master what you already know and expect another learning curve here as well. Not all skills are transportable to .NET from VFP but common sense is.
Wednesday, August 19, 2009
Generics Love
Wow ... been a long time since I posted here. I've been really busy learning a whole new set of technologies and paradigms; well, at least new to me.
I'm on a WCF project in VB.Net, Framework 3.5 SP1. The class model being used is beautiful as far as OOP goes (yes, I think .Net has finally surpassed VFP in OOP in almost all aspects).
It's a bit of a pickle with the model handed to me which I must adhere to. The output will be serialized based on the model and the consuming requires a certain structure.
Here's a simulation of the model, roughly, in psuedocode:
Class ClubMember
(a number of attributes like Name, MemberID, et al)
Public Property Talks as Presentations
Endclass
Class ActiveMember
Inherits ClubMember
(a few more atomic properties+
Endclass
Class ActiveMembers
Inherits List (of ActiveMember)
Endclass
Class Presentation
(Buncha attributes for a presentation)
Endclass
Class Presentations
Inherits List (of Presentation)
Endclass
ActiveMembers are derived from a stored proc from a source table, Members
Presentations are derived from a Presentations table with a Many to One to Members
My question is, where is the focal point in this model to integrate the DAL when requiring ActiveMembers? Simply put, where does the code go to create the individual objects and the lists? I mean, I can make it work as it stands but it ain't pretty. What would be a best practice approach?
I'm on a WCF project in VB.Net, Framework 3.5 SP1. The class model being used is beautiful as far as OOP goes (yes, I think .Net has finally surpassed VFP in OOP in almost all aspects).
It's a bit of a pickle with the model handed to me which I must adhere to. The output will be serialized based on the model and the consuming requires a certain structure.
Here's a simulation of the model, roughly, in psuedocode:
Class ClubMember
(a number of attributes like Name, MemberID, et al)
Public Property Talks as Presentations
Endclass
Class ActiveMember
Inherits ClubMember
(a few more atomic properties+
Endclass
Class ActiveMembers
Inherits List (of ActiveMember)
Endclass
Class Presentation
(Buncha attributes for a presentation)
Endclass
Class Presentations
Inherits List (of Presentation)
Endclass
ActiveMembers are derived from a stored proc from a source table, Members
Presentations are derived from a Presentations table with a Many to One to Members
My question is, where is the focal point in this model to integrate the DAL when requiring ActiveMembers? Simply put, where does the code go to create the individual objects and the lists? I mean, I can make it work as it stands but it ain't pretty. What would be a best practice approach?
Subscribe to:
Posts (Atom)