Tuesday, January 29, 2008

More fun with Yahoo Pipes + Ohloh + Google charts

UPDATE 3/16/2008: Apparently the project commits XML I was getting from ohloh wasn't an official API call, so now all pipes that depend on that are broken :-(
Hopefully the guys at ohloh will implement it soon!

The more, the merrier, right? This time I took the pipes from my previous post and graphed the commit activity using google charts. For example, this is the resulting graph of the latest commit history of Subversion code (at least the commits processed by ohloh):

Note: If you're reading this from rss, the graph will most probably not show up

The graph above is generated on the fly, it's not a static image. In fact, it's contained in an iframe. The page that generates the graph is customizable via querystring, so it is kind of a widget. It's all javascript, so you can drop it anywhere. These are the parameters it takes:

  • api_key: ohloh api key (required)
  • project_id: ohloh project id (required)
  • page_count: how much history to get (roughly 25 commits per page) (default 1)
  • interval: shows date on the x axis of the graph only every x days, to avoid overlapping (default 5)
  • width (default 600)
  • height (default 150)

In addition to the pipes from my previous post, I had to build a couple more:

For date parsing, I used the awesome datejs.

PS: Please respect the Ohloh API terms, get your own API key and link back to their site. PS2: Let me know if you use this! Or if you find any bugs!

Wednesday, January 23, 2008

Fun with Ohloh + Yahoo Pipes

UPDATE 3/16/2008: Apparently the project commits XML I was getting from ohloh wasn't an official API call, so now all pipes that depend on that are broken :-(
Hopefully the guys at ohloh will implement it soon!

A couple of days ago I was looking around ohloh and thought it would be cool to publish my OSS stack. They don't provide a feed for that, but there's yahoo pipes and ohloh's API, so I got to work on it. Pipes wouldn't read ohloh's xml since it didn't have a xml header, but I asked and the ohloh team promptly fixed it. So here are the pipes I built:

All of them need an ohloh api key.

Thursday, January 3, 2008

Castle Facility for Windows Fax Services

Some months ago, at work I was facing the need to send faxes from the main application server. "No problem", you might say, "just use Windows Fax Services". But the fax server was far, far away, only to be accessed through the internet. So I wrote a wrapper Castle facility around the fax API and published it as a SOAP-WS. Interfaces and implementation are in separate assemblies, so the ws-client doesn't have to depend on fxscomex.dll et al (the Windows Fax DLLs). It is also possible to send faxes via email, by setting up a couple of components outside the facility. These components periodically check an IMAP account for the destination fax number from the subject and the actual fax as an attachment. Usually you would send a TIF or PDF for faxing. Plain text also works, but I guess nobody would use that...

Ok, here's a more formal documentation:


The facility (Castle.Facilities.WindowsFax.dll) should be installed and configured on the machine that is the direct client of the fax server.

Required assemblies:

  • Castle.Facilities.WindowsFax.dll
  • Castle.Components.Fax.WindowsFaxService.dll
  • Castle.Components.Fax.dll
  • Castle.Core.dll
  • Castle.MicroKernel.dll
  • Interop.FAXCOMEXLib.dll
  • Windows Fax installed

Those are the bare minimum assemblies required, however you probably already have also Castle.Windsor, so I'm going to assume that for the rest of this documentation. If you don't have Windsor for some reason, you'll have to configure it manually using MicroKernel or provide your own configuration.


<facility id="fax" type="Castle.Facilities.WindowsFax.WindowsFaxFacility, Castle.Facilities.WindowsFax">

<serverName> refers to the machine that has the actual Windows Fax Service running, the one with the actual fax hardware. If not specified, localhost is assumed.

To make a fax operation, ask the Windsor container for Castle.Components.Fax.IFaxService, it has all the operations.

Scenario 1: Local fax server

If your fax server is on the web server's network, just drop the configuration above in your windsor config, setup the fax server name and you're good to go.

Scenario 2: Fax server is on another network

Here you can use the SOAP web services provided (client proxy here) or alternatively use remoting, WCF, etc. Leaving firewalls aside, it looks like this:




Required assemblies on "Web App Server":

  • Castle.Components.Fax.dll
  • Castle.Components.Fax.WebServiceClient.dll

On "Fax Web Server", just install the web service provided.

Sending faxes by email

The web service miniapp also comes with the optional components to send faxes via mail. It works by periodically polling an IMAP account for mails with subject with the format "<fax number>, <fax subject>"

  • IMAPClientWrapper is just a wrapper around Lumisoft's excellent IMAP Client.
  • MailFaxSender is the one that does the actual work of checking the mail account and sending any pending faxes found.
    This component takes the following configuration:
    • Username, Password: to access the IMAP account
    • Server, ServerPort: to the IMAP server
    • FolderInbox: IMAP folder where to look for new faxes
    • FolderError: IMAP folder where faxes processed with errors are stored.
    • FolderSent: IMAP folder where sent faxes are stored.
    • FolderNotFax: IMAP folder where mails not related to the fax service (ie doesn't comply with the subject format specified above) are stored.
    These IMAP folders are automatically created when needed.
  • MailSenderScheduler is a basic scheduler that executes the IMAP polling every x minutes. It relies on the startable facility to be...er... started.
    Configuration: SleepingMinutes: pretty much self explanatory.


  • Problem: I can't perform any fax operation, I always get some COM Operation Failed exception.
    Solution: Make sure the fax service is running. If it's not that, it's probably a matter of permissions. Open the Fax Console, Tools -> Fax Service Manager, right-click on Fax (Local), Properties, Security tab, allow all operations to the user running the facility (probably NETWORK SERVICE or ASPNET). Also check the permissions on the fax printer: from the Fax Console, Tools -> Fax Printer Configuration, Security tab, etc.
  • Problem: I can't send PDF files.
    Solution: Install Acrobat 4, then modify the path on the registry file acrobat_printto.reg, then apply that reg. UPDATE: also try HKCR\AcroExch.Document.x\shell\Printto\command (where x is the acrobat version)
    Explanation: Windows fax services sends different file types by printing them internally to the fax printer. This registry modification tells Windows to use Acrobat 4 to print the PDF. Why Acrobat 4 and not the latest version? Because Adobe has removed the support in Reader to directly print a PDF. UPDATE: turns out this still works with Acrobat 8.1. Couldn't get it working with Acrobat 9 though.
  • Problem: I can't send DOC (Word) files.
    Solution: DOC files are not supported (if you find something to print docs on the server reliably (ie NOT Microsoft Word) please tell me)


  • Generalize it to support Hylafax and other fax providers.
  • Support POP3

Project homepage at SourceForge.

SVN repository.