Using type providers to post slack messages.

December 5, 2016

Happy F# Advent!

I’ve been playing around with type providers recently, working on a few articles I have coming out for CODE magazine, and I thought it would be fun combine a couple type providers to post updates to slack from the F# Advent Calendar. I didn’t want to harass everyone on the F# Software Foundation slack channel (nor did I have the permissions) so this is more a short-and-sweet, to-be-expanded demo of what could be done. ;-)

So, I’ll show you how I was able to display today’s blog posts, calculate how far along F# Advent is, and send a DM with that info to my account. All in just a couple lines of code of course, because type providers.

Step 1: Get the current day’s blog posts

First, I had to do a bit of set up. I’m using the HtmlProvider and the JsonProvider from FSharp.Data, so I need to reference and open it. I also will often use a keys file for my demos to keep sensitive information, so I load and open that as well.

#r “../packages/FSharp.Data/lib/net40/FSharp.Data.dll”
#load “keys.fs”

open FSharp.Data
open keys

After this, I set up the HtmlProvider to link to the 2016 Advent Calendar official page, then find the table labeled “F# Advent Calendar in English 2016,” and return all the rows on that table.

let calendarUrl =

type AdventCalendar = HtmlProvider<calendarUrl>

let rows = AdventCalendar().Tables.“F# Advent Calendar in English 2016“.Rows

Finding the posts for today means that I need to filter the Date column, so we need to format a date string to match Sergey’s formatting. Then, I refined the text a bit by adding a check in case the post wasn’t yet up and folding the array into one string value.

let todaysPosts = 
  |> Array.filter (fun r -> r.Date = System.DateTime.Now.ToString(MMM dd (ddd)))
    (fun r –>
      if r.“Post Title“ =  then
        “Not yet available by  + r.Author + .
      else r.“Post Title“ +  by  + r.Author + .)
  |> Array.fold (fun acc s -> acc +   + s + \n ) 

Once I have today’s posts, I can reuse rows to find all the blog post titles, so that I can make the percent done calculation.

let postTitles = 
  |> (fun r -> r.“Post Title“)

Step 2: Make the calculation

Now I have an array of blog post titles, some of which are empty. The complete ratio value is the non-empty values divided by the total number of posts. So, I partition the array to find the non-empty values:

let complete = Array.partition (fun n -> n <> ) postNames

Then, I find the length of that array and the original postTitles array, convert both to floats, and divide. To find the percent complete, I multiply by 100.

let percent = (complete |> fst |> Array.length |> float)/(Array.length postTitles |> float) * 100.

Finally, I construct a basic message:

let message =
  sprintf Todays blog posts are:\n%s \nThe advent calendar is %.2f%% complete!
    todaysPosts percent

Step 3: Integrate with Slack

Integrating with slack was the most fun part of this post. I hadn’t really worked with the slack API before, and it was a pleasure to find out that creating an incoming webhook was basically trivial. I did have to first set up an incoming webhook custom integration for the team. On the slack web site, browse to Manage -> Custom integrations -> Incoming Webhooks. Click “add configuration” and you’ll be walked through the process. This step will give you a URL to which you can post your message.

Now, posting the message is just a matter of rigging up the JsonProvider to send it. I set up an example bit of JSON and use that to create a new WebHook type.

 webhookjson =
  “””{“text”: “This is a line of text in a channel.\nAnother line.”}“””

type WebHook = JsonProvider<webhookjsonRootName=“Message>

Next, I set up the call.

let newPost = WebHook.Message(message)

Finally, I make the request, to the URL that was provided when I set up the incoming webhook for the team.

newPost.JsonValue.Request keys.slackWebHookUrl

And voila! I have a private message sent to me:

Slack channel message

Slack messages with current F# Advent posts.

Originally, I’d planned to use the SwaggerProvider to call Slack. They have a pretty cool API with a lot of fun options, but since I ended up making a single call, it just doesn’t make sense here. Next post! :-)

My latest experience in traveling without babby.

March 11, 2016

Update: I DM’d the agent info to Heathrow, and have received this response.

Screenshot 2016-03-11 10.55.44


I’ve been traveling without my family for a business trip this week in London. Since I’m still breastfeeding, I needed to pump. This is the 6th such trip so far this year, so this is not a new situation for me. Every previous time, if I go through security and am questioned why I have breastmilk with no baby, I explain (this has happened a few times in the last 6 months). (This rule makes no sense to me whatsoever. Were any mothers who breastfed involved in making this rule? Why on earth would I have breastmilk, if I *had* the baby with me? I would just let him feed from me. I ONLY carry breastmilk when I *don’t* have him, because I needed to pump.) Every time I have to explain how my body actually works, occasionally in front of coworkers and business associates. It’s super awkward and humiliating. There’ve been full pat-downs, even. But every time, at every airport, they allow the milk through once they understand the situation and felt they have sufficiently tested it. As I’ve read the rules, breastmilk is classified similarly to medicine and allowed in larger amounts and with ice packs to keep it cool. I spent maybe 20 minutes trying to explain this to the agent at Heathrow who was straight-faced, cold, and just kept repeating that he was *quite certain* he knew the rules better than I did and there could be no testing. The only available option was to check the bag (at my own cost, of course). I consented eventually to doing so, because that was my only option, even though this terrifies me. I’ve had bags misplaced before, and knowing that my son might not get this food because the airlines lost my luggage is extremely upsetting. As you must know, breastmilk will go bad. So, if they find the luggage the following day, it’s already too late.

However, once I had consented to checking the luggage, they explained that there were additional issues. Namely, that my pumping gear contained an ice pack. So, here’s the real problem: I have an 8-hour flight ahead of me, and I pump every 4-6 hours. They explained that I needed to throw away (or check) the ice pack, and risk having NO WAY TO KEEP MY MILK SAFE for my trip home. They might as well have asked me to throw out whatever I would be producing on the plane. There seemed to be confusion over the fact that I needed an ice pack for empty bottles. I offered to pump and return so there was liquid that needed to be cold, but was told I was being antagonizing. I asked them for ice before I left the area, because I needed to pump before I got on the plane and was very worried about being able to make the flight, find ice, and pump. Another agent refused to help me with this because he declared that I was being too rude. When I explained that I would absolutely be needing their information and would be posting this on social media, that same agent informed me that that was a threat, and if I continued in this manner, I would NOT BE ALLOWED TO BOARD, thus preventing me from seeing my family for longer. I wasn’t allowed access to my phone for the length of this (it was in the bin behind the bag I was forced to check and the pumping gear, and when I asked for it, I was told absolutely not.) I was escorted back out through security, an absolute mess, in tears and forced to check both the bag and ice pack.

After re-navigating security, I stopped by the United lounge and requested ice. The folks at reception were somewhat helpful. They opened the first-aid kit and gave me one of those instant ice packs that becomes cold with movement (it did not). So I asked at the bar, and was told there were no bags to contain the ice. Back to reception, who found me bags, and back to the bar. I was able to pump (a shorter session than I really needed) and make my flight (as one of the last who boarded). All of this still basically sobbing, with a complete lack of compassion from anyone.

However, as you may be aware, ice melts. When I pumped on the plane a few hours later, the bag had broken and water had seeped into the bottom of my pumping gear bag, coming into contact with my pump. I dried off the pump, emptied the liquid, and replenished the ice both times I pumped on that flight. However, navigating customs (AND baggage claim now!) as well as the trip home, meant that I was unable to relieve the pain in my breasts for closer to 8 hours (but at least I could just breastfeed this time, yay!). When I emptied the pumping gear bag at that point, there was water EVERYWHERE. I have been too upset to verify that there isn’t water damage to the pump itself (but will be doing so this afternoon). If there is, to whom should I be sending that bill? I cannot go without a pump.

The thing about all this is, when I finally did board my flight, I discovered a bottle of hand sanitizer in my pumping gear. It’s been there for a couple weeks. They were so busy harassing me about my breastmilk that they COMPLETELY MISSED an ENTIRE BOTTLE of liquid.

F# Community Code Sprint

July 17, 2014

This weekend, Nashville had our first Community Code Sprint. Modeled after the code sprint that NYC held last October, we gathered a group of folks interested in F# (10 of us this time! We had folks even drive in from Georgia and Indianapolis!) and hacked on open source F# projects all day. In the car back from CodeStock (also amazing!) the day before, Tomas Petricek, Paul Blasucci, and I brainstormed a few easy to tackle projects to make sure we had good starting points for anyone who didn’t have a plan on arrival; shortly after arrival and coffee intake, everyone sat down while we reviewed the suggested ideas — and we were off!

I looked first at something I’d been planning to fix for months — support for Mono out of the box for the SQLProvider. I’d hacked together my own version previously and knew it was just a matter of remembering the few changes I’d made. It took a couple hours to get exactly right, but I submitted a PR around noon. :D I next started fiddling with the F# binding for Xamarin, but that’s been a tad more slow finding my way around.

In addition to bunches of bugs fixed in FSharp.Formatting and F# Project Scaffold, we had two other really cool projects come out of the Sprint: Karlkim Suwamongkol’s very cool FsReveal and Luke Sandell’s awesome COM type provider! I highly recommend checking out both of them.

We’re planning to hold the Nashville Code Sprints once a quarter. Hope to see you at the next one!

Rewriting from C# into F#.

June 29, 2013

I know this is almost an old story by now, but it’s the first time I’ve been able to produce any numbers myself. :)

Recently, I rewrote into F# a super simple data transferring app that I’d built for work last fall in C#. There’s not much to it: I grab data from a couple different databases, smash it together in multiple and occasionally bizarre ways, and send it on to its new database home. It’s a perfect use case for F#.


I ran into a couple issues along the way with the SQLEntityConnection and SQLDataConnection type providers.

First, a “mapping of CLR type to EDM type is ambiguous” error. I was using the SQLEntityConnection type provider for all the connections, but Entity Framework doesn’t allow mapping from two databases with any of the same table names.

So, I switched to using the SQLDataConnection type provider. For one database, it worked like a charm. (Progress!) A second one, not so much. I was confronted with somewhere near 680 schema errors. Eeek. After much (MUCH) random flailing about, I discovered that setting StoredProcedures = false for the connections rights everything. I worked out the rest of the code in a few hours this morning. Awesome!


First: during the rewrite, I noticed that I was actually processing tremendously more data than I needed. Heh, oops? This wasn’t as obvious in the C# code, and I’d apparently glossed over it. Going back and fixing this in the C# version actually brought the total processing time down to about 7 minutes (7:14.119 to be exact) from a couple hours.

70% less time!
Second, the longest part of the app, somewhat obviously and by far, was the middle step of processing the data. For the F# version, I used an Array.Parallel.partition to split out and then process what I needed. That, and a couple other details brought the total app time down to nearly 2 minutes (2:24.145.)

25% less code!
Third and finally, I ran a line count in C# (VS shows 140 lines of code, I’m guessing that doesn’t count brackets? Because that seems way too low for 2 projects and 15 total files.) The F# version is 103.

F# is the best ever.

Times, btw, are DateTime.Now differences from the first line of main, until just before the final line is printed to the console. Nothing fancy.

The MIT Study

May 18, 2013

I’ve been trying to blog about this since before “blog” was a word. :)

A long time ago in a state far, far away….

Women In Science and Engineering (WISE)

So, let’s first back up. In college, I was part of this amazing WISE mentoring program, as a math and physics major. We were assigned study groups and had many, many opportunities for mentorship. It was absolutely key to keeping me involved. As part of the program, we were all required to take a certain class — a women’s studies focused on STEM course — which ended with us choosing and then interviewing a woman scientist and writing up a paper on it. I don’t recall if there were more requirements. Being who I am, naturally I couldn’t choose just one; I chose three women to interview:

  • a Physics post-doc, on RHIC maybe(?);
  • a mid-career Chemist at Brookhaven, in charge of her lab;
  • an editor for a prominent Physics journal, who was nearing retirement.

Once I had their stories, I struggled with how to tie them together into a single paper. They’d all contributed an interesting point of view, and one that I wanted to share, but their stories were pretty varied and didn’t seem to flow well together at all. I spent a reasonable chunk of one night in search of research, and found:

The MIT Study

Please go read the whole study, even though I’m paraphrasing. It’s fascinating. :)

How the study came about

  • Three tenured women faculty started a conversation one day, and realized that gender had likely caused distinct differences in their careers, as compared to their male colleagues.
  • They polled the remaining other 12 women in all the departments in the School. Recognition that a problem existed was “instantaneous” amongst most of the remaining women.
  • They requested that the Dean of the School of Science establish a committee to improve the status of the women faculty. The Dean quickly started to champion the cause, and interviews were collected, as well as data on salary, space, resources for research, named chairs, prizes, awards, amount of salary paid from individual grants, teaching obligations and assignments, committee assignments – departmental, Institute, outside professional activities and committees, and pipeline data: numbers of women/men students and faculty over time.

Findings of the Committee

  • The number of women faculty had not changed in at least 10, and possibly 20, years. There was no indication that this number might rise. See Table 2 and Figure 2 for the data on the pipeline leaks at every stage of career.
  • Junior women faculty felt supported, but concerned over balancing work and home lives.
  • Senior women faculty felt “invisible,” and as if they had no power.


An important finding to emerge from the interviews was that the difference in the perception of junior and senior women faculty about the impact of gender on their careers is a difference that repeats itself over generations. Each generation of young women, including those who are currently senior faculty, began by believing that gender discrimination was “solved” in the previous generation and would not touch them. Gradually however, their eyes were opened to the realization that the playing field is not level after all, and that they had paid a high price both personally and professionally as a result.

Back to my paper

After digesting the major findings of the study, I realized that I had interviewed both junior- and senior-level women, and their comments had matched the MIT faculty exactly:

  • the Physics post-doc had commented that it seemed like most of the major work of feminism had already been achieved, and that whenever anyone had a problem with her, she just ignored it; clearly it was *their* problem. She was upbeat and positive.
  • the mid-career Chemist had ranted for a good portion of the time I was with her. She toured me through times she’d undeservedly lost funding, as well as comments other scientists had made to and about her and her work. We discussed the fears and regrets she had, and the backlash she’d faced to speaking up, to fighting for something, and to not behaving how one was expected to behave. She drove home just how much *work* I was in for by detailing some of her personal costs, but she was also torn: she loved her work, and couldn’t imagine doing anything else. It was tremendously illuminating.
  • the Editor had been a practicing scientist for the vast majority of her career. I don’t recall her exact words, but she had stopped practicing her field, in short, because she was tired of fighting constantly. I would refer to her mood as “resigned” for the course of the interview.

It was one of the more depressing moments of my life. I *don’t* want to end up in a non-practicing role. But it was also one of the most empowering, because one result of the MIT study, was that after the committee’s findings were announced, measures were taken to bring the women faculty onto more equal footing. And there were comments like this:

[One] woman, describing the change in her professional life, noted, “I was unhappy at MIT for more than a decade. I thought it was the price you paid if you wanted to be a scientist at an elite academic institution. After the Committee formed and the Dean responded, my life began to change. My research blossomed, my funding tripled. Now I love every aspect of my job. It is hard to understand how I survived those years – or why.”

I have so much more to add, but it will have to wait for a future post. ‘Til then, internet.

VTFun talk on F# Agents

April 27, 2013

Last Thursday, I gave a talk to the most fabulous user group I know ;-) — @VTFun, the Vermont Functional Programming group. We’d previously had a couple talks on actors: one covering Erlang by Dennis, and one on Elixir, by Alan, and the group wanted to know how F#’s actors/agents worked. Seeing as I’d only first heard of actors in December, I spent all last month attempting to devour what I could find.

Here’re some of the most useful articles and videos I found recently.

I am totally planning to post my slides and demos, but wanted to reorganize and rewrite parts first.


Boston Code Camp! And upcoming Community for F# talk!

April 6, 2013

I’m rather late at posting my content from the Boston Code Camp talks, but it was because it was just that much fun I needed the extra time to recover? I’ll go with that option. :)

I gave two talks:

– my Getting Started with F# talk that I’ve given a bunch of times before (VT .NET group, NY F# group, NY Code Camp, Richmond Code Camp, Philly Code Camp) which went over really well. My final example uses the WSDL type provider to grab the local current temperatures, and even though *I’ve* always thought it’s a good sample, it was fun to see it get applause. One audience member even commented they were planning to head to a different talk during the next slot, but that demo convinced them to stick around for the Type Providers talk. Aw shucks. :D

– and my second talk, Consuming Data with F#’s Type Providers. This was only the second time I’d given this talk, but type providers are really an easy win. They’re fun, they’re easy, people <3 them. I’m going to really enjoy giving this talk.

I’ve reorganized my code samples and the powerpoints for both. I’ll leave the old version of the slides for the Getting Started talk on slideshare (link in previous post if you *really* want to see them), but updated versions are with the code samples over on github.

If you’ve not seen the Getting Started talk yet, you’re in LUCK. I’ll be presenting it online for the Community for F# on April 16, noon EST. Details here:  If you miss it, you’ll be able to catch the recording later. I’d love to know what you think about it!

NYC F# User Group Talk

August 3, 2012

Hey, a big thanks to the NYC F# User Group last night for having me! I had some great conversations, and I know a bunch of folks left with a much better understanding of F# and functional programming. I’m just glad I could help!

Just as I’d promised, I’ve posted my samples over on github and the slides over on slideshare. I’d love any feedback you wish to share.


Progressive F# Tutorials

November 6, 2011

I had a bunch of friends attend and tweet about the Progressive F# tutorials this past week. I couldn’t quite instantaneously make it to London for the conference, so I’ve been following up watching the videos (all online, here: Don Syme’s keynote is great, and from what I’ve seen of the rest of the talks, I’d love to be able to head over for the next one. Or have one here!

F# Koans

The other supercool thing I learned about was the F# Koans – Chris Marinos created a project based onEdgecase’s Ruby Koans. The way it works, you’re presented with a project full of failing tests, and you’re required to adjust them to passing. This walks you through very basic examples, and requires you to actually interact with the language. I had tons of fun! It took me a while to finish them all — and I’ll admit I had no end of trouble with the Options one — but I solidified some knowledge & learned a few new things, and I’d recommend them to anyone just starting out! Or not, ‘cause I bet you’ll learn something anyway! ;)

Upgrading Orchard and XML-RPC Error posting with Live Writer

October 15, 2011

I decided to upgrade my blog to the 1.3 version of Orchard last night.

Upgrading to a new version is laid out here: and is, honestly, very easy. Make backup, install in new directory, copy over a couple important folders, and update modules from the website. And it just works. :)

Ok, well mostly.

I had been in the middle of a blog post (saved locally in Live Writer) when I decided to upgrade. When I returned to the post, finished, and tried to publish; Live Writer would error, with the following:


I was able to re-connect to the blog successfully, and re-download the theme, but it just would *not* publish either a post or a draft. With a bit of searching I was able to find the following (simple) advice on the Orchard forums: copy and paste the post into a “new” post, and you’ll be good to go.

Happy blogging. :)

Powered by Wordpress and MySQL. Theme by Shlomi Noach,