Entries from June 2008 ↓

Erlang needs more progress bars

I love Ruby’s progress bar gem. I’ve loved it long before I’d ever heard of or used Rails. It was really my first gem.

I’m a firm believer that the value of an application is directly related to how many progress bars there are in it. I couldn’t find an equivelent for Erlang, food
so I ported Ruby’s to Erlang. You can download it here.

And it makes sexy progress bars that look like this:

Example      95% oooooooooooooooooooooooooooooooooooooo   ETA: 00:00:03

The erlang implementation is less than half the size of the Ruby version. Likely this is because the Erlang version uses no control structures (like if/while/etc), doctor just pattern matching. At points the Ruby version wins in terms of legibility though, especially when it comes to calendar/datetime manipulation.

For example, here’s the ruby code to display ETA:

def format_time (t)
t = t.to_i
sec = t % 60
min  = (t / 60) % 60
hour = t / 3600
sprintf(”%02d:%02d:%02d“, hour, min, sec);

def eta
if @current == 0
ETA:  –:–:–
elapsed = Time.now - @start_time
eta = elapsed * @total / @current - elapsed;
sprintf(”ETA:  %s“, format_time(eta))

And the Erlang code:

current_time() ->

eta( 0, _, _ ) -> –:–:–“;
eta( Current, Total, StartTime ) ->
Elapsed = current_time() - StartTime,
{_,{Hours,Mins,Secs}} = calendar:gregorian_seconds_to_datetime( Elapsed * Total div Current - Elapsed ),
io_lib:format(”~2.10.0B:~2.10.0B:~2.10.0B“, [Hours,Mins,Secs]).

Usage goes something like this:

example(N) ->
PBar = progress_bar:start(”Example“, N),
example_work(N, PBar),

example_work(0,_) -> [];
example_work(N, PBar) ->
PBar1 = progress_bar:increment(PBar),
example_work(N-1, PBar1).

Enjoy! You can download it here.

MailSentry - rewriting a ruby mail analysis tool in erlang

I’m going to become an erlang ninja. So rewriting some of my old ruby code that could use some parallelizing seems like a good way to start. I’ll start with a description of what the project is and why I think erlang would do a better job than ruby and then I’ll set out to prove myself right!

Mail Sentry (Ruby Version)

Years ago I had a grand vision of an email analysis system for hospitals that would scan all outbound emails for patient health information or other sensitive data. The system could be configured to block offending mail and notify the privacy office or force the message through a challenge response process that forces the receiver to view it over a secure connection rather than allow the message to be sent unsecured.

So I built it using Ruby. It’s never seen any “real world” action, surgeon but it works. The gist of it is this:

You take all the sensitive data you have (patients name, drug addresses, treat medical record numbers, etc) and it’s tokenized and hashed and loaded into an in memory DB.

There is a message analyzer that’s added as a filter on your organization’s mail relay (to sendmail, zmailer, whatever). It rips apart the message and converts binary attachments into tokenized text (pdf, word, etc. It can even do OCR on scanned images). It’s passed off to a DRB service that hosts the in-memory DB of hashed sensitive data.

The algorithm

The assumption is that if you have a list of just the first name of 100 patients/clients/whatever, then you aren’t actually violating anyone’s privacy because you haven’t uniquely identified any specific patient. So the DRB service builds a list of hits against specific patients/entities. For example, it determines that a patient 1 had their first name referenced, patient 2 had their last name referenced, patient 3 had their first, last and social security number referenced.

Those “hits” are passed to a rules engine that allows each institution to define what constitutes a breach of privacy. Pretty much anyone would agree that patient 3 in the example above is enough info to uniquely identify them. The rules also specify the action (allow, deny, log, notify, etc) to perform.

Mail Sentry Architecture

The erlang re-write

This all works great. So.. why re-write it in Erlang?

Well, we have many processes (managed by the mail relay) generating analysis requests, but only 1 DRB service to manage them. If we want to scale beyond a certain point it’ll get rough.

So, here’s the plan: Let’s rewrite the “Message Analyzer” as an erlang server. The ruby is working perfectly for ripping apart the email, running the rules engine, converting the attachments and so on.. so let’s leave it as Ruby.

If it all works out, we should have a super scalable email analysis tool that can scale to any sized organization, with any amount of sensitive data.

Stay tuned!