As I've mentioned serveral times lately I'm currently working on a Rails application.  Overall, I've really enjoyed the experience and I'm glad that I took the plunge into unknown territory.  For the most part I've been creating everything within my Rails application as resources.  For those who don't know, using resources within Rails is how cool people build Rails apps these days.  Creating a Rails app as a set of resources makes it so your app automagically has a set of RESTful services that can be consumed by the likes of ActiveResource. Up until know I've had things setup pretty simply, and as such have only had standalone resources.  Tonight I needed to add a nested resources and found this post on the topic very helpful. 

One of the things that I've missed about using FeedDemon as my RSS Newsreader is the ability to sync my unread items locally and read them while offline.  Since my current RSS Reader is a web app, Google Reader, I had accepted the fact that syncing unread items to read on the train ride home or elsewhere was something I would have to live without.  Apparently, I'm not very forward thinking because with Google Gears I can now sync locally and use Google Reader while offline!  In fact, with Google Gears, any web app can now add offline support and thus open a whole new world of possibilities.  Gears provides a client side relational database that can be accessed via Javascript.  Under the covers Gears uses SQLite.

What's even more interesting is the thought of how Microsoft might respond, or perhaps how they've already responded.  Imagine being able to write Silverlight applications in managed code, ruby, or whatever language tickles your fancy and persist data to a local SQL Server Compact edition using the common ADO.NET programming paradigms that we're all used to.  Next imagine ADO.NET Synchronization Services thrown into the mix so that local data in the SQL Server compact edition database can be synced back to the server. 

While the advancements made by Google Gears excites me, I'm not real big on being limited to programming against it with javascript.  The idea of building web apps that can now work offline, and use local databases that can sync back with the data center using Sync Services, all within the nice managed environment provided by Silverlight would be a sweet deal.  Heck, even if that doesn't happen we should be able to write a managed wrapper on top of Google Gears so that our managed code within Silverlight can take advantage of it.

Over the weekend there was quit a flurry of heated discussion about the Composite UI Application Block (CAB) that was developed by the Patterns and Practices group at Microsoft.  It started with Ayende's " Why I don't like Patterns & Practices efforts " post, and continued with Sam On CAB and P&P and More on CAB and PAG .  Things continued with Ayende's Sam Gentile is mad at me , and On the CAB Again, and Be Silent they are Agile.  Not wanting to leave all the fun to Sam and Ayende, Hammet (of Castle fame) responded with The CAB way, and signs of community immaturity , Chris Holmes jumped in with his Ayende Bashes P&P and finally Adi offers a caution with his Caution: This blog contains personal opinions post.

From my perspective, there is a bit of complexity with CAB.  However, as some others have pointed out in the comments to the posts mentioned above, thats more due to the fact that CAB encompasses a couple different components that utilize patterns that not everyone who is starting out with CAB is comfortable with.  When you get past the initial hurdles, CAB can be broken down pretty simply.  It provides dependency injection so that the various components within your application can be loosely coupled and injected at runtime (similar to Windsor, Spring, etc).  It provides an eventing infrastructure that allows for the events and event handlers within your application to be loosely coupled (you might be able to think of it as a message bus for your UI), and it provides a number of infrastructure services that allow for your application to be broken up into a modules that can be used to create an application that can be dynamically composed (think MasterPages with a little bit of a plugin type architecture for building the UI at runtime).  For those starting out it requires familiarity with dependency injection, model view presenter or model view controller, loosely coupled events/commands, as well as an understanding of some of the requirements for a dynamically composed UI.  While it's not something I would use for every application I develop, I think it's a good fit for certain applications. For anything web related I'd steer clear of something architected in a similar fashion and go with MonoRail or if you can swing it Ruby on Rails. :)

Unfortunately, as I'm sure many in the chain of blog posts above would attest, blog posts aren't always the most effective way to carry out a discussion.  It doesn't help when those involved are a group of deeply passionate people who have strong feelings and opinions.  I think the primary points of each person's blog posts are important, relevant, and worth a continued discussion.  As Ayende points out, there are many things within Microsoft, as well as within the deliverables provided by P&P that seem to be more complex then they need to be.  As Sam states, we shouldn't lose sight of the fact that that P&P group is one of the few openly Agile groups within Microsoft.  I really believe they're trying to do the right things for customers, they're trying to do as many things as possible to make sure they're not developing in a vacuum, and that they're working on the things that their customers really need.  Are they perfect, absolutely not.  Are they trying, I think so.  Are the deliverables they offer for everyone, no.  Are their deliverables appropriate for some, yes.

I think Hammet brings up another important point for us all to think about regarding our community.  We have a lot to learn, and a lot of areas in which we can grow.  Insulting one another, isn't the way to go.  Letting our emotions get the best of us is something we should try and avoid.  However, at the same time we don't want to lose our passion and fire for what we believe in.  Let us remember that we're all part of the same community, and ultimately I think we're all after the same things.  When our emotions run high and we either say things that we wish we hadn't said, or state things that aren't exactly true, we need to take a step back and realize that sometimes our emotions do get the best of us.  But as far as I'm concerned, that's part of the process.  We're all human.

Over the last couple of days I've spoken with Sam a few times about what's unfolded.  For those of you who don't know, I have a unique perspective on the situation since I work with Sam.  He's a deeply passionate individual who loves technology.  He has an unquenchable thirst for new information as our printers at work can attest to.  He genuinely wants to help the .NET community, and one of the ways that he's done that is in pointing out some inaccuracies in Ayende's post on CAB and P&P.  Based on conversations Sam and I have had in the past, I think besides some of the inaccuracies on how CAB was developed, Sam agrees with most (or maybe just some) of what Ayende has said. As Jeremy pointed out, bringing up things that were said years ago isn't the way to address any problems you might have with Sam on how he voiced his concerns.  Sam is a perfectionist, and will welcome any positive and constructive feedback you can provide him.  My constructive feedback is to not let your emotions lead you to say things you'll regret the next day.  But I'd also suggest you keep your passion, and keep doing the things that make you you.  At the end of the day the most important things for all of us is to be happy.  Don't let what's happened in the past get you down.  We live and we learn.  All we can hope for is that we better ourselves over time.  Let's leave the personal attacks to the Java community (just kidding any of you Java peeps out there), and hope we can make the .NET developer community a better place for those of us who care about producing great software.

I spent some time today digging into the Persistence and Tracking services available within Windows Workflow.  During my escapades I came across the following set of articles that provided some useful information for building a basic understanding of these two key services within Workflow.  Depending on how some things unfold, we may need to write a tracking and persistence service that works against an Oracle database.  Since we support both SQL Server and Oracle, and since WF doesn't provide base classes and/or interfaces for some key infrastructure classes (SqlTrackingQuery, SqlTrackingQueryOptions, SqlTrackingWorkflowInstance, etc.), we may need to write wrapper classes that allow us to work against a configurable persistence and tracking service. 

Persistence Service

• Windows Workflow Foundation Runtime Services: The Persistence Service
• Workflow Tools
• Oracle Persistence Service
• Performing Transactions in Windows Workflow
• Execute Long Running Workflow Using Persistence

Tracking Service

• Foundations: Tracking Services in Windows Workflow Foundation
• Writing Tracking Services for Windows Workflow Foundation
• Tracking Services Deep Dive

Brian Marick has a great post where he talks about some values that he thinks agile teams should invest in.  While they're not part of the original Agile Manifesto, I agree with Brian (afterall who am I to disagree :)) that they're key to helping agile teams be successful.

• Skill
• Discipline
• Ease
• Joy

On a related note, I also recommend you take Sam's advice about "Being Real and Communicating".

When I heard that the Dynamic Language Runtime was going to be open source, and subsequently heard some things that Miguel said about it I knew it was only a matter of time before DLR support was added to Mono.  It sounds like only 15 days after the announcement of the DLR it's already made its way to Mono.  As M. David Peterson points out, it still has a ways to go but it's promosing to see them making such good progress so soon!

Mike Champion has a great post that offers up some theories for why LINQ to XML has been getting positive user reviews.  In short, he thinks it could be because Anders is "the man", and can read every developers mind.  He also has a magical crystal ball that he can look into to figure out what to include and more importantly what to exclude from the LINQ to XML API.  I might not be getting all the details of Mike's post right, so you *may* want to read what he said yourself rather than taking my word for it.

I've been working with LINQ to XML as part of my work on our LINQ book, and I must say it's a seriously kick ass XML API.  I've done a lot of XML work in the past and I've never had as much fun working with XML as I do when using LINQ to XML.  The key highlights for me are:

• Functional Construction: Have you ever created XML using existing .NET XML API's?  Enough said, functional construction beats the pants out of anything else out there for creating XML.
• Powerful Transformation capabilities: By combining the powerful querying capabilities of LINQ with the functional construction pattern for XML creation LINQ to XML provides a lot of really nice transformation capabilities.  In addition to supporting superb XML to XML transformations, we also get killer support for transforming our XML into object structures, LINQ to SQL objects, and whatever else you can think up.
• LINQ: What else needs to be said, sprinkling LINQ query support on top of an XML API makes for a kick ass query experience.  We get the best of XPath and XQuery but in a much nicer, cleaner, and straightforward API.

Now that I'm back on the "blogging wagon" I'll be looking to start the LINQ to XML for president campaign that I promised way back when.

Back in February I posted about when the right time for a new technology is.  As some likely guessed after seeing my review of Everyday Scripting with Ruby and the list of books that were on my next up list I decided to go with Rails as my new technology for one of the projects.  In a future post I'll detail how I've found the experience, and how it compares to .NET land but that's for another day.  Today, I'd like to point out the fact that nobody writes anything cool in .NET.  At least nobody writes any of the cool stuff that I need in .NET.  Ok, perhaps I'm exagerating a bit....in actuality the fact is that nobody writes social network visualization libraries in .NET. :)  The project that I'm working on that's using Rails involves social networks.  One of the things that I'll be getting to shortly is the actual visualization part of the project.  What I'd really love is if someone would write something as cool as this, in Silverlight.   That way I could have my Rails application call .NET code.  What could be better to piss off the Rails purists?  Afterall, I'm supposed to have given up all things .NET by now and truelly converted to Rails, right?  Ok, moving on....who wants to write prefuse in Silverlight?  It'd be a killer demo application to show off the capabilities of Silverlight and would undoubtedly make it so the only RIA platform anyone chooses is Silverlight.  Flash who?  Java FX what?  Flex...I think not.  With prefuse.NET, Silverlight is guaranteed instant mass approval.  Or maybe it'll just make me happy that I get to write .NET code that will access a RESTful Rails service for data that lives inside a rhtml page.  Either way you win, right?

In all seriousness I think Silverlight would be a great technology for building web based network visualization software.  While there's no way I'll have time to write something as fully functional as I'll need, I think I'll apply the learn a new technology even if it will take longer rule and give getting a basic network visualization demo in Silverlight working.  Luckily, I think some of the Silverlight samples (such as this one) might get me moving in the right direction.  If anyone cares to lend a hand, give me a shout!  Instance fame and fortune is within your grasp!