This past Saturday, 4/4/09, I attended my first Pittsburgh
Code Camp. Not only was it my first Code
Camp, I was also a speaker this year with Rich Dudley, Shaun Eutsey, and Matt
Stultz. This year's presentation was
called ‘Squawking in the Cloud', which was to be a Silverlight chat application
hosted in Microsoft's cloud (Azure), incorporating SQL Server Data Services to
hold our data and using WCF & Web Services to get and put the data into the
cloud.
Let me be the first to say that Azure is definitely not in a
production form yet (actually, I'm sure the other guys I spoke with already
made mention of this in their blogs).
Over the past month, as we developed, we found many bugs/workarounds. In our application's most primitive pieces,
everything worked great. My piece of the
presentation was on the Silverlight application. The Silverlight front end was very simple and
probably could have been coded in less than an hour once I made up my mind on
what I wanted to do. Matt created the
WCF & Web Services, which were working fine when communicating with the
SQLEXPRESS instance on his machine. Rich
was going to do a middle piece using Workflow Foundation (an afterthought, but
would have been really nice functionality).
Shaun's duty was learning Azure and making sure we would be able to host
everything in the cloud.
Everything was built and working as separate pieces by the
Wednesday prior to the Code Camp (Rich's piece was on hold as he was helping
with some of the prep work of the separate pieces). We met to put all of these pieces together on
Wednesday and started to immediately run into issues. First issue - we couldn't obtain a seat in
the SQL Server Data Services in the cloud.
No problem, we decided to just use Azure Table Storage. It would work well enough for demo
purposes. That put us a little behind
(actually, it was a pretty devastating blow considering it was the driving
force behind the application). Thursday
night was spent reconfiguring the Web Services to talk with Azure Table Storage.
Next comes Friday night, and with the presentation the
following day, we set our goal to get everything working together. After finishing up some minor details, we
started on this task. The Web Service
was working fine outside of the ‘cloud' (as mentioned before), but we could not
get it to work once hosted in the ‘cloud'.
After 5 hours of researching and trying different things, Rich, Matt,
and Shaun stumbled across one single blog mentioning that there is a ‘not-so-well
known' bug with WCF in the cloud getting the WSDL after calling the service
(again, only one person has blogged about it so far). The workaround was listed, which we followed,
and all seemed to be working again (it was an odd workaround, obviously
temporary, and something that we did not necessarily need to present to the
group). This took about 5 hours Friday
night to find and fix, taking us into the early hours of the morning. Code Camp registration started at 8am, it was
already 1:30am, and most of us had a 45+ minute drive home and a 1+ hour drive
to the University of Pittsburgh where the Code Camp was held. We called it a night and decided to finish it
up the next morning prior to the presentation.
Saturday morning, we all immediately met in the speaker's
lounge, opened up the laptops, and started back at it. The first call to the web service failed, as
did every other one following. Our Web
Service was going to return XML, but was not working. Thinking it was the code, we started ripping
it apart, piece by piece, trying to find the issue. Ran a few tests and found out that we could
return a string from the cloud. This was
good news, but the bad news was that we were presenting in less than an
hour. We reconfigured the Web Services
once again to pass a string of XML. We put 2 + 2 together and contributed this bug
to the same issue as the WSDL problem since the WSDL also returns as an XML.
Now, with 20-25 minutes before the presentation, it was time
to try & link it with the Silverlight application. It didn't happen. We were up in the room until 3 minutes prior
to speaking and arrived just as the presentation started. I went out in the hallway with Rich to see if
there was any last minute coding I could do to get it to work (see Rich's blog,
there's a nice picture of me laying on the floor just outside the classroom
hammering away on the keyboard in a last-ditch-effort to get it to work). Mission unsuccessful. As Shaun, Matt, and Rich spoke on the other
pieces, I re-wrote my presentation in my head to show a high-level overview of
Silverlight & try to make the failure transparent to the audience. It was a little scatterbrained, but got the
job done. Not my best presentation ever,
but considering the lack-of-sleep and only minutes to re-do my game plan, I
would call it a success overall. The
entire group did a great job on this presentation, definitely showed strength
in some adverse conditions thrown at us, and we pulled it off.
For those that attended our Code Camp session, we're going to
get this finished up and send the code off to the PghDotNet guys to post. Stay tuned also to my blog, I should have a
blog post up soon on some of the Silverlight 2 functionality I used in the
front end (user controls, storyboards for animations, etc). I'll try not to throw in much design (as you
could see, I'm not much of a designer at all!).
Here's a little background on the project I've been creating for the
past 2 weeks... Take uploaded XML files, do some file validation
against a database using Linq to SQL, and distribute these files across
our network based on the values within the XML file. Through all this,
wire in notifications if the file fails a validation test.
As
with any other application, there are many variables. In my case, I
was setting file directories, strings for email attributes, error
messages, etc. Setting these variables within the app was not only
'ugly code' to fight through, but any changes meant recompilation.
Most of these variables are going to need changed over time as business
changes, so why put myself through that???
Given the fact I was
already reading XML files using Linq to XML, it was decided to create
an XML file to hold all these values. It's definitely something that
can be easily edited with new values & placed directly into
production without causing any major issues.
Example XML (we'll call this settings.xml and will be saved in the root directory with the app):
<Settings>
<Notifications>
<Email>
<To>anyone@someone.com</To>
<From>someone@someone.com</From>
<Subject>{0} Email Notification</Subject>
<Body>This is the {0} email for the {1} task.</Body>
</Email>
</Notifications>
</Settings>
So now, let me tell you how easy Linq to XML in VB really is. To get the email subject & body, the code is as follows:
Dim _xml as XDocument = XDocument.Load("settings.xml")
Dim _subject = _xml...<Settings>.<Notifications>.<Email>.<Subject>.Value
Dim _subject = _xml...<Settings>.<Notifications>.<Email>.<Body>.Value
In
3 lines of code, I was able to set a _subject and _body variable to the
value in the XML file. This, of course, comes with an assumption that
the child nodes only appear once in your XML file. Notice I did not
strongly type the _subject and _body variables, this is called
anonymous types. If the nodes appear more than once, you will return
a collection object called _subject and _body, rather than a string for
each, that will need to be looped through with logic to find the value
you are searching. In my case, the XML file I'm using for these
settings was something I created, so I purposely made sure nodes were
not repeated to only return one value when searching through the XML.
Another
thing you may have noticed was the use of token {0} in the Subject and
{0} and {1} in the Body values. You can now use these email settings
for a range of different emails without creating different values using
String.Format().
Example:
Dim _subject = String.Format(_xml...<Settings>.<Notifications>.<Email>.<Subject>.Value, "Failure")
Dim
_body = String.Format(_xml...
<Settings>.<Notifications>.<Email>.<Body>.Value,
"failure", "assigned")
In this case, the token {0} is replaced
by "Failure" (without quotes), so now your _subject variable string
will read: Failure Email Notification. The _body variable has the
"failure" string and "assigned" string replacing tokens {0} and {1}
respectively. The _body variable string will now read: This is the
failure email for the assigned task.
As you can see, Linq to XML
saves a lot of time when getting values from an XML file. Use this to
your advantage, I'm definitely glad I did.
I started using
Generics today to hold a collection of emails as the application
processes The last step of the application is to iterate through the
generic list, using the variables I set from my XML file to send out
the emails. I'm still getting my hands around generics, but once I do,
it should make for a great blog post! Keep your eyes open in the next
few weeks for it!
Well, I've been working on some non-ASP / non-Web Development related projects this week & need to jump back into Dynamic Data soon. MVC is almost here in its final form (RC1 was released this week after a few months in beta), so that will be fun to get into soon.
I've been trying to think of a good topic to blog about all week, and although this is more general development than directly related to ASP & ASP.NET, I thought I'd blog a little about these.
RefCardz - Free Cheat Sheets for Developers
For the developers (or in my case, developers in training) out there, I don't know how you couldn't use RefCardz. The idea about RefCardz is simple... Let's get bestselling authors and leading experts to write up reliable information about some of the best development topics, and we're going publish these in PDF format and give them away for free. Take a few minutes and look over the topics they have published already and the ones coming soon. Did I mention they are free???
So what's the catch? Can you deal with one tiny little advertisement on your RefCardz? That's about it!
Are you still reading?!?!? I imagined you would be looking over and downloading your favorite RefCardz by now. Not that I want you to leave, but you'll definitely get more out of the RefCardz than you will get out of me at this point! Enjoy!
Well, it's my first blog here at aspadvice.com, and what a topic to write about. I've been watching Dynamic Data for a little while now (something like 6 months) and every time I seem to want to pick it up and incorporate it into something I'm developing at the time, I can't find a legitimate reason to & end up using the Enterprise Library's DAAB (Data Access Application Block) to access data from the database.
Now enters Rich Dudley into the picture. I've known Rich for a few years and 'blame' him (in a good sense really) at least once every week for throwing something interesting my way, something that completely fills up my night/weekend to learn. Tonight's project (and probably the remainder of this week) - Dynamic Data... I've seen it, never played more than a few minutes with it because I couldn't find a good reason to take the time to learn it. Rich decided it would be great to do something to incorporate Dynamic Data into a project he came up with today.
For those of you that want to see some basic and moderate level videos, I definitely suggest the videos at www.asp.net by Joe Stagner. Start from the beginning, there is so much involved. There is a lot of code generation when using the Dynamic Data template in VS2008, but don't let it scare you away. Yes, you could go through and develop it yourself, but why? The code generation is basically the essentials and is highly configurable. Minimal setup is needed if using the template. You could literally be up and running in a matter of minutes (provided you are using a well structured database). The time spent on Dynamic Data is basically configuring it to match the need for the application. The hard part is done for you.
Dynamic Data uses all the .NET items you're comfortable using already (I say that in a very hopeful manner), and all the same features/functions are available to use within these controls (DataList, GridView, DetailsView, etc). Everything is captured in an Update Panel so you get the clean transitions at postback.
After watching the videos, ideas for incorporating this into some of my applications began popping into my head. Very nice addition with .NET 3.5 SP1 and VS2008 SP1. For those of you that haven't yet checked out Dynamic Data, I suggest you do so - especially the videos. Words mean a lot, but to see it in action definitely turned me onto it & I can see this incorporated into a few things I'm doing now. I hope you take the time to take a closer look at Dynamic Data. I'm glad I did!