Over the break I took a look at updating my Facebook Developer Toolkit (FDT) Starter kit to the latest v3.0 release that was announced at PDC. My first thought was to download the sources via SVN but unfortunately, that failed so I resorted to using the SDK Source download which I’d rather not do as it leaves no easy way to keep up-to-date with recent checkins.
Anyway, I built the sources which “just worked”, surely a good sign.
Next, I worked to compile and run my Starter Kit application and here is what I found (at least so far):
- Delete old referenced assemblies
- Change using statements:
- using facebook; –> using Facebook
- using facebook.web; –> using Facebook.Web;
- using facebook.Schema; –> using Facebook.Schema;
- Master.API.uid; –> Master.Api.Users.GetLoggedInUser();
- Master.API.friends.getUserObjects(); –> Master.Api.Friends.GetUserObjects();
- Master.API.photos.getAlbums(); -> Master.Api.Photos.GetAlbums();
- facebook.Schema.user –> Facebook.Schema.user
- Master.API.users.getInfo(Master.API.uid); –> Master.Api.Users.GetInfo(Master.Api.Users.GetLoggedInUser());
- facebook.fql q = new facebook.fql(Master.API);
- Add using Facebook.Rest
- facebook.fql q = new facebook.fql(Master.API); –> Fql q = new Fql(Facebook.Session.FacebookSession);
- Convert Site.Master page Page_Load method to a constructor setting RequireLogin = true;
- Regular Expression bug
Until I get some time to resolve the RegEx issue the rest will be on hold for a bit though things are looking pretty good and the above didn’t take long at all. I have noticed a few worrisome comments on the discussion forum.
At the Silicon Valley Code Camp 2009 I gave a talk called Extending CruiseControl.NET through the use of plugins. I discussed the necessary steps and illustrated with an example ISourceControl provider using the LinqToTwitter OS project on Codeplex. The provider polls a configurable Twitter account looking for Tweets that that start with “CI:” allowing the Tweeter to trigger a build of the project simply be tweeting something like: “CI:Start the build”.
It’s a simple example but illustrates how easy it is to create CC.NET plugins an extend the platform to uses beyond classic Continuous Integration.
Here is a link to the Starter Kit. Btw, you will need to update the ThoughtWorks assembly references to match your build of CCNET.
After working on this problem the other day I started Googling looking for posts written about using LINQ for text file processing. I found the post Parsing textfiles with LINQ (or LINQ-to-TextReader) by Arjan Einbu.
LINQ shows us alternate ways to write code, introducing a more declarative coding paradigm. To use LINQ over the lines of a file, we can read all the lines in the file into a collection, and use LINQ over that collection. There’s some overhead to this; the need to read the entire file upfront and to fit the entire file in memory at once.
The solution was to create an extension method on TextReader for IEnumerable<string>. That post was followed up by another post, rather unfortunately titled, improving upon the solution using TextFieldParser class in the Microsoft.VisualBasic.FileIO namespace, something I wasn’t aware existed and now find it odd this class is stuck well off in left field.
One of the reasons this subject interests me is I’ve been working with EDI files for awhile now and querying data directly from this file format would be really nice. For example, given a PO with line item segments like this:
PID*F****PRSL ROMNE BBY TRAY ORGNC~
PID*F****PRSL SPRG BBY TRAY ORGNC~
PID*F****PRSL SPNCH BBY TRAY ORGNC~
PID*F****PRSL SPRG W/HRB CLM ORGNC~
You can calculate the total quantity, highlighted in yellow, of all line items using LINQ like this:
using (var reader = new StreamReader("c:\\edi\\inbound\\850_09022009_1311_89.txt"))
var query = (from line in reader.GetSplittedLines("*")
where line.Equals("PO1") && line.Length > 0
Using Arjan’s implementation of GetSpittedLines, that’s his name not mine for the extension method he wrote, you can apply logic to any of the columns from the file which is pretty cool.
Of course, there are a myriad of ways of doing the same thing but it’s interesting to have access to the columns allowing for calculations and querying. For my EDI work I’m using FileHelpers which works well though I really like this LINQ option. That said, I haven’t done any benchmarking so I’m not sure about the performance but most of the PO’s I’m working with are less than 4KB and the volume isn’t so great that this would be a major factor. At any rate, I hope you find useful for you too.
Btw, if you’re looking for custom EDI implementations feel free to contact me.
A few months ago I started working in an area I previously knew little about, EDI. EDI stands for Electronic Data Interchange and it defines standards for how businesses communicate with one another electronically. The basic flow of information for what I’m working on looks like this:
The document numbers above correspond to the following:
- EDI 850 = Purchase Order (PO)
- EDI 810 = Invoice
- EDI 997 = Functional Acknowledgement
My client represents the seller’s side of this diagram and I’m specifically working on the lower half of this picture, the invoicing portion, as there is existing software which handles PO’s. As indicated in light red there is a trading partner involved which brokers various services between buyers and sellers including providing EDI services. The EDI “documents” are cryptic delimited text files exchanged via numerous transport mechanisms though FTP is used in this case.
Basically, there is a system which polls the trading partner, again via FTP, looking for new purchase orders. When one is found the file is downloaded, validated, processed and an acknowledged (EDI 997) is transmitted back to the trading partner. Eventually, the order works it’s way through the system and an invoice is generated at which point, an EDI 810 is generated and transmitted to the trading partner, validated and again acknowledged with an EDI 997, a mirror image of the EDI 850 processing. For brevities sake I’m glossing over parts of this process but you get the gist of what’s going on.
When I first was assigned to start working on EDI invoicing I had a lot of things to learn including EDI, the current processes involved in invoicing and the software that handled purchase orders among others. I quickly learned via not so subtle hints that the existing software which handles PO’s wasn’t considered maintainable and is badly in need of replacement.
Once I got my feet grounded I realized this system closely resembled a continuous integration process and started investigating using CruiseControl.NET as the primary engine to drive invoice handling. I already knew CruiseControl.NET brought a number of interesting features to the table including:
- Open Source
- Polling architecture for trigging task execution
- Open plug-in architecture for things like source control providers and task execution
- Easily configured using XML (ccnet.config)
- A customizable web based portal for monitoring projects
- Email publishing for notifications
Basically, you can envision CruiseControl.NET as the two blue circular arrows in the middle of the above diagram. In a future, post talk more about the specific implementations of ISourceControl and ITask that I’ve written to manage this EDI process.