So recently I was wrapping up development work with the same iPad app port for Mobile Innovations as I had mentioned in my last post, when I ran across a rather interesting problem.

We make use of multiple APIs for allowing you to share what you’ve made in our Applications with all of your friends. However with the iPad things take on a new dynamic. Before everything would be displayed as its own full-screen view controller but the iPad allows us to focus more into a single view. Popovers are a great way to add extra controls that are relevant to on-screen content but not important enough to take up the whole screen.

We currently make use of Facebook, twitter and email as means for sharing. The last two are relatively easy to display inside a popover. Facebook however, is a bit more of a challenge. The Facebook API, of which they have yet to make a native iPad port, displays a series of procedurally generated dialogs that are meant to take up almost the entire screen. This simply won’t do for the iPad, since it has so much screen real-estate doing something like that would break the design theme of centralizing all the content onto as few views as possible and making use of contextual  items to display related content.

Facebook doesn’t make this easy though. Since everything is generated in code, and not from a xib file, we’ve got to dig around to find the parts we need to alter to make it work. We just need to make a few key modifications to FBDialog.m and we’ll be set. As with my last post I’ll be using the self-defined preprocessor macro TARGET_OS_IPAD to separate the code out, so that the FB API remains usable for either device based on your build target.

First step, sizeToFitOrientation is the main function called to generate the main FB dialog window. We’ll just add this here:

 
I’ve excluded everything after the else, as it’s just the main body of the function. In this case we’re just telling it to set a static frame for all dialogs, you can alter this of course to size it however you’d like. Since all of our dialogs should be appearing inside a view we’ve already set up in the view controller we’ll be presenting in the popover it’s easy to just set a static size. Next:

We need to remove this because we don’t want the facebook dialog to try and re-orient itself on orientation change since our popover will automatically handle repositioning itself. Next we’ll add some important code to our Init function

By setting ourselves as the active popover delegate this lets us automatically dismiss any open dialog when the popover is dismissed.
And this goes at the end of dismiss method

The above returns the popover delegate to its original source and removes the FB dialog from our view hierarchy.  It’s important to remove the FB dialog’s view from the superview because otherwise you’ll get a memory exception later when the View Controller tries to deallocate the view again as part of its cleanup. This frees everything up in order so we don’t have anything lingering in memory. Now when assigning and removing the Facebook view your implimentation of the above may be slightly different. In my case my main controller view was given the tag 8426 and 9999 is a container view I created just for the Facebook API dialogs, which I move back and forth in the hierarchy as necessary. For the code to work that also means that the view you're adding the dialogs to must already be a part of the view hierarchy.

Normally you might not see this but there’s a grey border typically drawn along the outside of the facebook dialogs. Depending on your app you may want to remove this. If so just put the following code at the start of the drawRect method like so:

 
There’s still one more part of the code that tries to resize our view. Now, you can either do this the way I did, which was to comment out the body like so:

Using preprocessor statements. Or you can just do it in the add/removeObservers methods, which add the keyboard change notifications. Either way it’s important that the above code doesn’t get called for the keyboard notifications as it’s another point where the FB dialog tries to resize and orient itself according to the main screen.

This last part is from the end of the show method:

This adds our dialog to our specified view, and removes the last instances of it trying to dynamically size and orient itself. Now no matter where it appears, no matter what size it is, all of our facebook dialogs will appear inside our special view controller, which in our case will appear inside a popover.

One last important tip. When adding any dialog to a popover, it’s always a good idea just in case to have the top level view as a scroll view with the content size set to the frame’s proper width and height. Popovers will try and move to avoid the keyboard when it appears, and that can cause the view to get shrunk. So using a scroll view will ensure that you can scroll while the keyboard’s up, in case it obscures anything important.

One of our strong practices here at Syndicated Methods is design and implementation of Service Oriented Architectures (SOA).  When people immediately hear SOA, they think SOAP and bloated contracts.  Yes, SOA boasts some grandiose goals with its standards, and with those goals comes a complex implementation. I have seen SOA make sense of many enterprises, and like any loyal developer ready to fight for their technology,  this mantra has always rubbed me the wrong way.   As of the release of .NET 4.0 however, and the rise of REST services, it has become quite clear that SOA isn’t the only way.  It has actually changed how I think of our practice.  So much so that I make sure to tell clients and folks that I talk to that our practice specializes in “Distributed Architectures”.  I have come to realize that we can take all of those lessons learned in SOA and apply them to any number of manners for exposing enterprise data in a distributed fashion applying the most suitable manner for clients.

After reading a recent article on WCF Data Services, it got me thinking about how to spread the word for such technologies.  Oh yeah, did you know Syndicated Methods has a blog!  So, I want to start a series on the Syndicated Blogs titled ”Distributed Architectures”.  The first candidate … you guessed it.  WCF Data Services.

WCF Data Services

There are certain scenarios where the development overhead associated with SOA is just not necessary.  For example, you have an analytics group that needs to have open access to a data store.  Or, you have an application that allows the user to shape and export data how they see fit.  Maybe you do a lot of prototyping and are looking for a turnkey solution for getting to your data. Such business problems have been solved by the Open Data Protocol (i.e. OData).  Those familiar with RESTful services will immediately understand.  The idea is to expose a repository of data over a standard pathing system, such as urls.  WCF Data Services takes these concepts and allows you to define a WCF Service (without the contracts of course) over an Entity Data Model.  You can expose your data in just a couple of easy steps.

Step 1 – Create a new Web Project on your local file system.  Any name for the site should do.

Step 2 – Next we need an Entity Data Model of the standard Sql Server Nothwind database.  You will want to create a new Entity Data Model pointed to a local instance of Northwind.  Go ahead and run all of the default configurations (make sure you place this in the App_Code section of the project).  You should end up with a Entity Data Model that looks similar to the following diagram:

Step 3 –Now it’s time create your service.  Create a new WCF Data Service in the root of the website. Now we are going to have to write a little bit of code here.  We only want to expose the Employees table for this exercise, so we need to tell the WCF Data Service to expose the Employee table.  In a real world implementation this could be done for all of the data tables / data sources required.  The code is rather trivial and is represented below:

Step 4 – Now for the fun stuff.  Let’s get your data!  You can easily pull your Employee data from the service by pointing DataServiceQuery at the endpoint.  Pretty neat!  No messy configurations, no service endpoints to deal with, and better yet you get your data in 4 or less easy steps.  I will let you play around with your services to get an idea of what it’s like to pull this data. Below is sample code for consuming the endpoint.

Before I close out this post, I want to just show you something that you may have missed.  I know that I missed it the first time through, so I want to just call it out.  WCF Data Services are employing the power of .net and WCF to allow you to address your data.  Users of the system only need to know the schema of the database.  We accessed the data by pointing to the following url:

http://localhost/WcfDataService.svc/Employees

This url basically says, use this service repository location, and show me all of the employees.  If we wanted the Customer data (assuming it was exposed in the WCF Data Service) we only need to access the following url:

http://localhost/WcfDataService.svc/Customers

And keeping true to the RESTful theme, if you want to narrow your data down you can pass a query along with this path like so:

http://localhost/WcfDataService.svc/Customers('ALFKI')/Orders?$filter=Freight gt 50

This will capture Customers with the id of ALFKI and will then filter those by getting freight values that are Greater Than 50.  Pretty neat.  Using these powerful data services allows you to get to a repository of data by simply "asking" for data in a standardized format.  If you are wondering how all of this data gets transferred, under the hood .NET will serialize this data in POX or JSON format.  The following screenshot verifies our transport data as depicted in Fiddler

As you can see the output is a standard ATOM Xml format.  Internet Explorer will conveniently display this as a RSS feed.  Anyone that is tasked with exposing data in a distributed fashion should definitely put this one in their toolbox!

{Happy Coding}

Ad hoc distribution of iPhone, and now iPad, applications can feel like a circus sideshow.  Developers come clambering out of the Provisioning Portal like its an undersized automobile to jump through flaming code signing hoops.  Generate a certificate, create an application id, add devices, create a provision, install them all and try not to get burned.  If you fail to do one step, or perform a step incorrectly, the application build results will usually guide you to the solution.  But what about when you do everything by the book and you still get an error?

The majority of my distribution issues usually sprout up when Apple releases a new version of the iPhone SDK.  This time it happened to be installing iPhone SDK 4.  After upgrading I needed to generate some Ad Hoc distributions.  Since these apps are only supposed to be targeted for iPhone devices, the "Base SDK" gets configured for "iPhone Device 4.0" and the "Targeted Device Family" is set to "iPhone". The only other parameter that needed changing was the "iPhone OS Deployment Target".  This app was not quite ready for "4.0" so I switched the value to "iPhone OS 3.1.3".

I configured three apps using the described values in exactly the same fashion.  The Ad Hoc distributions were generated and then zipped off to be installed.  To my dismay I received an email saying that one of the apps was incapable of being installed.  When the app is dragged into iTunes, nothing happens.  Successive attempts to drag the app into iTunes prompts this warning:

A provisioning profile named embedded.mobileprovision already exists on this computer.  Do you want to replace it?

Click the "Yes" button.  Nothing happens.  Click the "No" button.  Nothing happens.  At this point, I have no idea if I want to replace it.  I just want the app to sync with iTunes.  Time and time again I verify that all provisions are installed and configured properly.  Of course, none of which are named embedded.mobileprovision.  Search Google for embedded.mobileprovision and see what turns up.  Maybe a Twitter feed from a confused and frustrated developer.

There may be a multitude of reasons why this warning would appear when attempting an Ad Hoc installation but let me share with you the reason I was experiencing this issue.  Contrary to the message, the problem had nothing to do with an existing embedded.mobileprovision profile.  Some secret sleuthing lead me to believe that the issue originated when I choose a different "iPhone OS Deployment Target" in the project settings.  While I cannot prove this, I can at least show you some things to check manually before iAnarchy.

Every application has an Info.plist file that is created out of the box.  Find it in your application "Resources" group and it may look something like this:

Notice the dictionary entry "Application Requires iPhone Environment".  Notice the checkbox is clearly checked.  That makes sense.  We are developing an application using the iPhone SDK so it is only necessary that the application requires an iPhone environment.  Now open that same file as "Plain Text" to view the XML document which makes up this info dictionary.  Ours looks something like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>CFBundleDevelopmentRegion</key>
    <string>English</string>
    <key>CFBundleDisplayName</key>
    <string>${PRODUCT_NAME}</string>
    <key>CFBundleExecutable</key>
    <string>${EXECUTABLE_NAME}</string>
    <key>CFBundleIconFile</key>
    <string></string>
    <key>CFBundleInfoDictionaryVersion</key>
    <string>6.0</string>
    <key>CFBundleName</key>
    <string>${PRODUCT_NAME}</string>
    <key>CFBundlePackageType</key>
    <string>APPL</string>
    <key>CFBundleSignature</key>
    <string>????</string>
    <key>CFBundleVersion</key>
    <string>1.0</string>
    <key>LSRequiresIPhoneOS</key>
    <true/>
    <key>NSMainNibFile</key>
    <string>MainWindow</string>
    <key>UIStatusBarStyle</key>
    <string>UIStatusBarStyleBlackOpaque</string>
</dict>
</plist>

The pertinent key/value pair we are looking for is "LSRequiresIPhoneOS" and an XML node indicating <true/>.  999 times out of 1000 I would guess this is normal.  But on my 1000th attempt to build an app I see different a value:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>CFBundleDevelopmentRegion</key>
    <string>English</string>
    <key>CFBundleDisplayName</key>
    <string>${PRODUCT_NAME}</string>
    <key>CFBundleExecutable</key>
    <string>${EXECUTABLE_NAME}</string>
    <key>CFBundleIconFile</key>
    <string></string>
    <key>CFBundleInfoDictionaryVersion</key>
    <string>6.0</string>
    <key>CFBundleName</key>
    <string>${PRODUCT_NAME}</string>
    <key>CFBundlePackageType</key>
    <string>APPL</string>
    <key>CFBundleSignature</key>
    <string>????</string>
    <key>CFBundleVersion</key>
    <string>1.0</string>
    <key>LSRequiresIPhoneOS</key>
    <string>YES</string>
    <key>NSMainNibFile</key>
    <string>MainWindow</string>
    <key>UIStatusBarStyle</key>
    <string>UIStatusBarStyleBlackOpaque</string>
</dict>
</plist>

Notice how the value for <key>LSRequiresIPhoneOS</key> has been modified from a (bool)<true/> to a (string)<string>YES</string>.  How on earth this happened I cannot guarantee, but I can tell you that this is the reason "A provisioning profile named embedded.mobileprovision already exists on this computer".  If you take the time to manually replace the <string> node with a <true/> node you may be one step closer to a successful Ad Hoc distribution.

With the release of the iPad back in April companies have been scrambling to take advantage of what this new platform has to offer. Only a little over a week ago the count of native iPad apps approved in Apple’s iPad store was over ten thousand.  So with this device flying off the shelves it’d be hard not to want to cash in with a native iPad app. We recently began work on such a port for Mobile Innovations, one of our clients.

In porting your app there are two very important things that need to happen. The first is that the App’s front end needs to be redesigned to take proper advantage of the iPad. With all the screen real estate it offers it gives you a chance to streamline your interface and reduce the number of controls a user has to click through to get where they need to go. Multiple pages can be condensed into a single page, and so on. But that’s not what I’m really here to talk about, I’m a developer and not a graphic designer so let’s talk about what we need to do to build our native iPad App from our iPhone source. So we can take fullest advantage of all the new features while re-using as much of our existing resources as possible.

First, open your project in Xcode and right click over your build target for the iPhone and click the option to upgrade your build target for the iPad.

After which you’ll be presented with another prompt regarding how you want to handle your codebase.

Next select option number two and click “Ok.” Option number two makes the most sense in this case; if you choose the first option you’d be building both targets from the same everything. Now, this is fine for simple apps where you really just want to have the layout flow into the larger screen with only minor differences. Option number two will copy all of your nib files to a separate area, allowing you to customize your user interface for just the iPad, with the interface being built determined by the active build target.

When viewing your Nibs you’ll notice the bullseye icon heading a column of check boxes. The box checked indicates which Nib is being loaded for the current build target.

This gives us all the freedom we want to customize our interface for the iPad to take full advantage of its display. There are still a few more steps to go though before our app is ready. Not all resources will be relevant to a given version of the App. So the next thing to do is to navigate to your project directory and make a copy of your app’s info.plist file into the new Resources-Ipad subdirectory in your project folder (I’d also recommend renaming it to something like appname-iPad-info.plist), then add it to the iPad resources folder in Xcode.

Next we need to tweak some version specific settings. The first of which is setting up version detection since we’re sharing the same source files.  There are two methods of detecting which version of an app certain code should run on;  one for detecting at compile time and one at run time.
You can detect at run-time using something similar to the following pseudocode:

#ifdef UI_USER_INTERFACE_IDIOM
#define IS_IPAD (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)
#else
#define IS_IPAD NO
#endif


if (IS_IPAD)
{
// iPad specific code here
}
else
{
// iPhone/iPod specific code here
}

Of course in our case we’re loading separate nibs for two separate versions, so it’s going to be more appropriate to conditionally compile our code using the preprocessor.  Run-time detection is generally only useful for universal apps.
Highlight the build target for our iPad app and click the blue info button to open the project settings for it.  Scroll down and add a little something like this to your preprocessor settings.

This way now when we need to run different code for different versions of our project we can just write

#ifdef TARGET_OS_IPAD
//iPad specific code
#else
// iPod/iPhone specific code
#endif

Depending on how much code you end up needing to be version specific performing version detection at compile time will offer a much better return speed wise. It also allows you to modify definitions in your header files as well, so that iPod/iPhone apps don’t need to load resources into memory that are only necessary on an iPad. Finally, let’s go back up in our project settings and change our info.plist for this build target.

And that’s it. From there it’s just a matter of reworking your nibs to fit the larger design. Code wise there are some things that do need changing between versions such as how modal inputs like the image picker need to be accessed via popovers in the UI. I can’t say what specific issues anyone else may run into when porting their apps over but with the above you now have everything set up so that you can build two separate apps from the same source and you can re-use as much or as little of your resources as necessary between either version. Just set your target and hit build.

The phrase "FBCDN image is not allowed in stream" does not have much meaning to most of the natural world, but to a developer integrating with Facebook features this phrase is a nightmare.  Over the past year we have been developing iPhone apps that will process images in unique ways.  We thought it would be interesting to allow users to share these images with their friends on Facebook, if they have any friends.  The normal procedure is a two part process.  First, a user would upload the image to their very own photo gallery hosted on their Facebook profile.  When that is successful the user could then choose to publish a message to their stream which would include a link to this recently uploaded image.  It was fast and it was fun.

About two weeks ago I noticed that some previously published feeds, and any new feeds, were missing the shared photo.  Immediately I thought there must be a problem with the code.  Let me take a look.  HMMMMMMM.  Everything looks good, but why is the image missing?  Wow, I don't have much time to continue debugging this.  Let me check Facebook Developer Documentation.  Nothing here about missing images.

On the 17th of June 2010 the shock was felt. I was testing a new iPhone app we are working on for in20years.com.  The Facebook integration was complete and I attempted to publish a message to my Facebook profile using a Facebook Photo Gallery image.  The process came to a halt and the dialog read, "FBCDN image is not allowed in stream ..... You can see this because you are one of the developers of the app."  Ouch.  I could indeed see this message and yet I have no idea what it means.  Endless Google searches return nothing.

With shifting priorities in schedule we decided to let this go for the weekend.  Monday morning was a bit more informative.  Facebook Developer Forums erupted in outrage that all existing apps ceased to work due to this error. The official word came through an RSS feed reading:

Serving Images in Stream Stories
Jun 18, 2010 3:21pm

We no longer allow stream stories to contain images that are hosted on the fbcdn.net domain. The images associated with these URLs aren't always optimized for stream stories and occasionally resulted in errors, leading to a poor user experience. Make sure your stream attachments don't reference images with this domain. You should host the images locally.

So what does this mean?  Well it depends on your point of view.  It means Facebook does not have enough consideration for current applications using images in the fbcdn.net domain to grace the developers with a warning of this new policy.  I was experiencing problems for weeks before this statement was released.  It means that developers cannot rely on any implementation of a Facebook API component to behave the way they expect on a day to day basis.  It means that developers must find a way to host their own images if they plan on placing them in a Facebook Stream.  It means we must react with Ninja-like reflexes.

As we’ve been doing some late spring cleaning here on the IT side of things, I recently ran over a whitepaper we produced a couple years ago regarding organic search engine optimization. Still very relevant, I thought I’d share the fantastic work of our own Stephen Dewitsky, now our Director of Mobile Engineering, in his publication: Eight Steps to Organic Search Engine Optimization.

Get a Free copy of the white paper here:

http://www.syndicatedmethods.com/fresh_methods/seo_research_whitepaper.aspx

One of the biggest lessons learned over the many years of software development is that if you aren't listening to your customers about what they want, you are completely missing the mark.  This is a rather simple point that so many times gets missed.  That's why I am proud to work on the Fashion Mobile  team at Syndicated Methods (stepping back for readers that are not familiar with Fashion Mobile, it is a specially tailored instance of MobilePipes for the fashion industry).  From inception, this product has incorporated features that have helped our customers solve problems.  We take in feedback, survey our users, and try to pick a couple of the most sought after features.  Doing so ensures that we are adding valuable additions that our customers want.

Recently, one of our sales representatives was visiting a client talking through a recent Fashion Mobile installation.  The topic of conversation was along the lines of how are things going, what would you change, is the product satisfying your needs.  This particular client used Fashion Mobile to fulfill their own sales process.   We designed an application that allowed their sales representatives to demonstrate their clothing lines using their iPhone.  The tool was very well received by the client, with one major exception.  Along with client information the sales representatives found it rather cumbersome to have to switch out of their application while on the road to find directions to the client site.  They wanted some way of staying within Fashion Mobile to find their customers on a map.

This sounded similar to feedback that we had received from other customers.  So, keeping true to the content in this article, we rolled it into Fashion Mobile.  Customers of Fashion Mobile now have a way to work with mass Geo Coded locations within the product.  There are two pieces that we have rolled in.  The first piece is the ability to load Geo Coded locations into the Fashion Mobile Control Panel.  With the latest release of Fashion Mobile, customers can now locate and save Geo Coded addresses for consumption on the iPhone client.  The second piece is a new Module in Fashion Mobile for retrieving those Geo Coded locations.  With this new Module, iPhone developers can retrieve multiple pairs of Latitude / Longitude pairs that allow for any development pattern that the iPhone supports.  Examples of this are dropping a point on the map, providing driving directions, finding distances between points, for example.   As just a little taste, the following screen shot shows you what the Control Panel looks like for this new feature:

As a software consultant I have spent multiple hours learning new languages and API's.  Having experienced this process myself many times one of the things that I appreciate in a product or code library is effective documentation. Reading documentation is a crucial first step in learning any new product.  However, any developer knows that when the rubber meets the road, there is one place that always falls a little bit short. 
Documentation almost always falls down when you actually start to consume the methods and classes.  The reason is because code is constantly evolving.  Documentation is great for high level components and understanding intent.  Where it fails is at the interface level. Wouldn't it be great if developers receive compile warnings if they were using your library incorrectly? 

Microsoft added something call Code Contracts into .NET 4.0 that allows developers to describe the behavior of their methods and classes in a way that consumers receive real time feedback from the compiler if they are using a method or class incorrectly.  The next version of MobilePipes will include Code Contract checking which will provide better documentation.  Customers that are customizing MobilePipes will really appreciate this addition because it will allow you to better understand how to effectively grow the product to fit into your business needs.  We are working to include all of the feedback we receive from customers into our customization interfaces to answer your commonly asked questions in real time when you are writing code. 

For example, take the IModuleOperation interface in MobilePipes.  This interface has the following definition:

Writing a custom module in MobilePipes involves implementing this interface.  The very first thing that MobilePipes does when it receives a request is to validate the Data argument that goes into these methods.  This validation consists of ensuring that the XDocument Data object contains the correct MobilePipes XML Schema.  If this schema does not exist then the method will not execute.  You will receive an "Invalid schema validation" message from the MobilePipes server.

With Code Contracts we can notify the developer early on in their testing code that they are passing a bad value by changing the interface to the following:

Now developers will receive an "Invalid schema validation" in their unit tests letting them know that their XML input string is incorrect.  This saves lots of time deploying and debugging and shows customers how to use our product more effectively.

NOTE: Some of the code here is pseudo code and is intended to demonstrate advances in the MobilePipes product.  It is not intended to be a demonstration of Code Contracts in .NET.  Readers that are intestered in Code Contracts should consult Microsoft documentation.  I recommend also viewing "Contract Checking and Automated Test Generation with Pex" from the PDC2008 < http://channel9.msdn.com/pdc2008/TL51/ >.

{ Happy Coding }

MobilePipes grows up!

The MobilePipes team works hard on our product suite making sure that our customers are buying software that is top notch, bright and shiny, reliable, easy to use, stands the test of time, and, well you get the point!  We could assure all day long that our products meet this criteria but we took the extra steps to prove it. 

MobilePipes was officially certified by Microsoft this month as a certified product.  This means a lot for our marketing and sales material because we get to include the logo all over the place, but more importantly, it assures our customers that they are buying a quality product. 

For those familiar with the process we ensured that our code meets the Microsoft standard for .NET based Web Services, Managed Code, and Windows Server 2008 Hyper-V. 

SyndicatedBlogs is a fairly new blog.  The staff here at Syndicated Methods are feeling our way through things to see what format works best for our company and customers.  We started the blog with lots of development tips and tricks that we found useful, but  hey, isn't that what  Google is for? Maybe people will stumble across those types of posts and find them useful but acting as a third party "tid bit" aggregation service will not serve our customers well.  It takes time to write those posts and make sure the content is relevant, and that is time taken away from product development and implementation work.

After some looking back we realized that we want a blog to distribute information about our organization and products that users would never see outside of the organization.  Tips and tricks about how to use MobilePipes is much more suitable for this channel.  And upcoming news such as MobilePipes becoming a Microsoft Certified Product (well, let's not get ahead of ourselves, this is pending approval of Microsoft but we are confident :)).

So, the future of this Blog will be dedicated to development news in the industry that relates to our services and products.  Additionally, news and tutorials about our products and client components for using those products.  I will conclude with an article from Joel Spolsky, to be exact, his last Inc. article where he posted hindsight on the blogging phenomena and gave tips for corporate blogs that are in line with this new strategy for SyndicatedBlogs.

Joel Spolsky's Last Word

{ Happy Blogging }