Sorry, I forgot to include why I think blogs are awesome in my last post. I forget where, but I read that some people prefer the newsgroups to weblogs. I look at the newsgroups as a place to ask a targeted technical question. I can do that here on my weblog, but the weblogs also give all of us a chance to talk about things at random. So I get more bang for the buck here.
All of you are just as capable of answering a question as the people on the newsgroups are, and with the MS employees blogging also I am sure someone will point me to an answer.
OK, I'll admit it. I was slightly off base in my criticism of the Whidbey delay. I was just reading Lorenzo's blog about the Whidbey CTP and it got me thinking about this whole early insight thing. We are seeing something the likes of which I have never been privy to before at this magnitude : early bits and lots of early information.
I downloaded the CTP from MSDN the other night and this was the first time I had gotten to take it for a spin. I usually don't like playing with unstable stuff but I have an extra box hanging around so I figured what the heck. After reading so many of your blogs, MSDN articles, magazine articles and watching MSDN videos, I honestly had the impression that Whidbey was alot farther along than it is.
Basically I like it and I can see the potential, but right off the hop I could tell things were different - in a good way. It freaked out on me a couple of times but that was to be expected. I have to admire those of you that can work with software like this and get so much out of it. (I can't imagine what the Longhorn early adopters are going through) Right now I don't have time to play as much as I would like. I'll probably mess around with it here and there, but for now I'll just live Whidbey through you early adopter types. I like what I see and I can't wait for the finished product.
So yes, I made a judgement without having all of the facts. I'll have to be more careful from now on, but I still don't like the IDE being held up for Yukon. I could see Yukon being dependent on Whidbey, but the IDE is the IDE as far as I am concerned.
As far as Whidbey being delayed, it should be. Its not ready and I appreciate that fact, and I do appreciate what Microsft is doing by letting us see things at such an early phase. Is this some form as of Extreme Programming in their part? Just look at what they are doing with Longhorn which is a couple of years out. Oh, and by the way, yo Whidbey team - please take your time and make it rock solid. Now that I can see where you are at, I can wait.
The company is located in Madison CT and is right off of exit 61 on I-95. Their add goes in the local Sunday papers so if you are interested act quickly. You can email me at firstname.lastname@example.org for contact details.
Disclaimer : This is not a flame.
that said, I realize Yukon is important to alot of you, but my client uses Oracle. I would like to see MS offer better support for all databases. That I would be willing to wait for. Why don't they spend some of the 50 billion on that? I am as much an MS bigot as the next guy, but come on. Here they have a chance to really show that they are the industry leader.
Here's a good example - Object Spaces only support SQL Server as far as I know. (Please correct me if I am wrong). Yes, Chris, obviously the products are tied, but do I care if the enterprise manager is part of VS? Who is going to jump on Yukon as soon as it is released?
All I am saying is that they could have split the products - if they wanted to - and made a bunch of us really happy :0)
Are you kidding me? For what possible reason could a database hold up the release of a development tool? Is Visual Studio dependent on Yukon to work? If it is we are all in trouble. My client uses Oracle so Yukon makes no difference to me at this time.
As much as I love MS products this issue is really trying my patience. Only MS could cook up something this ridiculous. I am starting to get tired of the dependecy of every MS product to make other MS products work. Unbundle the Yukon features and fork over Whidbey!!!!
We recently had a security consultant come in to give us some guidance. Since I am the developer, not the database or network engineer, I learned a few things but the one that really got me was the use of ports with Oracle instance setups. Hackers always look for the obvious, and usually that means default settings that never get changed.
When you add a new tns name to your tns name file people usually take the default of port 1521. So right there we found one issue that could easily be corrected. This is in the same vain as companies that leave the default sa user with no password in SQL Server. You can bet your sweet bippy I'll be on the lookout for things like that from now on.
If you are looking for some really good sample code on ASP.Net security check out the Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication article series on MSDN. Lots of good stuff up there, especially the How Tos.
I mentioned in an earlier post that I thought the web services section was kinda light. I wish it was as good as this section.
We finally have a project that looks like a good candidate for web services. I have played around with some samples, but now I am looking for some meat. I have a basic understanding of what's going on but I am very concerned about security. I am aware that WSE is ready for release so I'll be looking into that.
I have looked up on the MSDN web site but to me, the coverage seems lacking. Can anyone recommend a good book that starts with but goes beyond the basics? Any good web sites? Any war stories?