A Comment On RSVP’s On Meetings

While I’m thinking about it, another quick comment.  If you’re asked to RSVP to a meetup, user group, etc. please do not say “I’ll attend” unless you’re sure you’ll attend.  As dumb as it sounds we have a few people around the Metro Detroit area (not naming any names) that seem to consistently sign-up for meetups and indicate they are planning to attend and then simply never show up.

Perhaps if I explain why this is a problem my point will become clearer.  The organizers of these user groups, meetups and so forth often want to feed attendees.  In order to get the right amount of food because if we get too little some will go hungry and if we get too much food may go to waste we need an idea of how many people to expect.  Hence if you RSVP that you’re going to attend and then just don’t bother to show up you’re simply making it harder for those who run these meetings.  By the way, the people I have in my mind have done this multiple times.

If you join a meetup group because you’re interested in the topic you are not obliged to RSVP yes to attendance.  You won’t be kicked off of the meetup group’s mailing lists. But if you do RSVP yes and don’t bother to show up you may eventually find yourself removed.

Why I Am Not A Fan of Screen Sharing For User Group Meetings

So I want to capture these thoughts while I can for whatever value they may have to myself or others in the future.

Last night we did a coding dojo on building Android apps with F#.  Reluctantly, after a little cajoling from a co-worker I decided to add a Google Hangout to the meeting.  NB: While I specifically mention Google Hangout don’t misunderstand; the problems I’m addressing have been problems with pretty much any teleconferencing solution I’ve had experience with.  AnyMeeting, WebEx etc. etc. etc. all seem to have the same issues.

So I don’t think it went particularly well (others may feel differently).  And I think I’ve finally figured out my issues with the screen share/videoconferencing approach.

The technology still has some rough edges. Repeatedly last night I was sharing a screen to show people on-line some point that I was discussing.  And repeatedly the screen share simply stopped by itself. The video conferencing portion just stopped working by itself at some points too.  This issue will go away as the technology improves, of course, but we’ll also ask more from the tech so this issue will never really resolve completely.

The speaker’s focus is split. For me, the bigger issue was trying to help the developers in the room (coding dojo) and trying to assist the developers online.  There was no way I could simply talk to the people online and also address the people in the room.

The speaker ends up having to run the video conference. This is a relatively tough issue to address because the speaker has the slide deck and the speaker knows which examples he (or she) is going to show so they end up running the video conference from their machine.  It’s tough enough to give an intelligent talk without having to worry about the side issues of when you should share your screen and when you should be showing the video feed and such.  I think if I were to do this at a user group meeting again there would be a designated video conf assistant and I’d practice things with that video conf assistant at least three or four times before the actual presentation.

If others have thoughts or suggestions on these issues, please feel free to comment.  Perhaps I’m simply not seeing what may be simple answers to these issues.

Slick Use Case For Active Patterns

So I love it when a very natural use case arises for a feature that I want to practice.  I’ve been trying to better my understanding of active patterns lately and today I found a great use for them.

I’m fetching json data from a REST endpoint.  Of course I get back a string.  And the string contains some very specific text when there’s a problem processing the request on the server side.  So I ended up doing something like this:

let errResult = "Error creating user"

let (|ContainsErrString|) (stringToTest:String) = stringToTest.Contains(errResult)

//And further down in the code:

let res = sr.ReadToEnd()

let u1 =
 match res with
 | ContainsErrString true -> None
 | _ -> Some(JsonConvert.DeserializeObject<user>(res))

Simplifies the code dramatically and hides detail that the match doesn’t need to know about.  Terrific use case for an active pattern.

Prerequisites For F# and Android Development

If you want to build Android apps with F#, you’ll need the following things:

  • Xamarin Studio (true on both Mac and PC).  I hope soon we’ll have an Android/F# option within Visual Studio but as of today (17 October 2013) it’s not there.
  • F# 3.0 or later (seems to go without saying but just in case)
  • Within XS, you will need both the F# language bindings and the F# For Android Add-ins
  • If you wish to be able to debug the app on your phones
    • On Mac you don’t need to do anything special
    • On Windows you need to make sure you have the proper driver installed from the phone manufacturer.  The Xamarin docs say get the latest Google USB driver but it appears you need to get the specific driver from the phone manufacturer.

By the way, many kudos to Dave Thomas (@7Sharp9) who has tirelessly worked on bettering the Xamarin/Android/F# experience.  None of this would be possible without his hard work.

GLFPC 2013 Unconference

Thanks to the fine folks at Detroit Labs we’ve been able to do a pivot on GLFPC 2013

Announcing the Great Lakes Functional Programming Unconference!

Are you sad that Great Lakes Functional didn’t get off the ground this year? We are too. Super sad.

It’s ok though, you can stop being sad now. Why? Well, a few of us here in the Detroit area are really dedicated to making sure there’s an awesome, thriving functional programming community here, and we’ve decided we’re going to throw an event anyways! We’re inviting anyone who purchased a ticket or planned to speak at GLFPC to come hang out for a free event at the Detroit Labs office on Saturday, November 9th, the same day we would have had the conference. We know it’s not exactly the Century Theater, but we’re pretty sure it will still be an awesome time, with plenty of space and chances for some open discussion. Detroit Labs has also offered to provide light refreshments.

If interested please contact Onorio Catenacci at Catenacci@ieee.org to reserve your spot, and once again, a big thanks to Detroit Labs, Ann Arbor Scala Enthusiasts, and the GLFPC staff for continuing to assure that the FP community in Detroit thrives!


GLFPC mini-event

Saturday Nov 9th, times TBA

Detroit Labs Offices, 1520 Woodward, Detroit MI

BTW–one of the reasons that GLFPC 2013 failed to get off of the ground was the fact that no one was sharing the news.  If you support functional and you want to see functional programming conferences, I cannot emphasize enough–share this with your friends!  I (Onorio) don’t have money for an advertising budget for GLFPC (either conference or unconference) so I rely on those of us who are interested in functional programming to spread the word.  Even this unconference won’t succeed unless you help to get the word out.

F# Tip Of The Week (14 October 2013)

It is possible to declare a list or an array without the separating semicolons by declaring each element on a separate line.  Like this:

let favoriteBreeds = [
    "Swiss Mondaine"


let favoriteBreedsArray = [|
    "Swiss Mondaine"

Note: for reasons I confess are unclear to me, the first member of the list/array must be on the next line from the opening symbol of the collection. Well, to be precise (this is software development after all) this is true of arrays–the same is not true of lists. But since putting the first element of the array on the next line works in both cases, it’s simplest just to do it this way.

EDIT: Per Dave Thomas, you can put the first element of the collection on the same line as the opening symbol; you just need to insure that you align all of the other elements, DIRECTLY beneath the first element, as in this code gist which Dave put up.

Personally I consider it’s easier to simply stick to the convention of always putting the first element on the next line so you don’t have to worry that much about the alignment but this does work.


Functional Programming Makes Simple Easy

I do love the fact that F# (and functional programming in general) gives a developer the tools to make it easy to build simple code.
I was hacking together a function to convert a DateTime to a Unix Time Stamp (for using with the Meetup Restful API).  This was my initial pass at it:
    let unixTimeStamps startDate endDate=
        let startOfEpoch = new DateTime(1970,1,1)
        let startTS = uint64 (startDate - startOfEpoch).TotalMilliseconds
        let endTS = uint64 (endDate - startOfEpoch).TotalMilliseconds
        (startTS, endTS)
(BTW that may not be the exact working code but it should give the idea.)
Then I thought to myself–why should I return a tuple?  If I simplify the function to simply convert a DateTime to a UTS, I can just call it twice.  So I got this:
    let unixTimeStamp d =
        let startOfEpoch = new DateTime(1970,1,1)
        uint64 (d - startOfEpoch).TotalMilliseconds
Simpler but still not as simple as I could make it.  I was bothered by the fact that I had to truncate the decimal part of the returned timespan.  I had to truncate it because Meetup’s API balks at a time span with a fraction on the end of it.  So I modified the function one more time to make it both simpler and more generic:
    let unixTimeStamp d =
        let startOfEpoch = new DateTime(1970,1,1)
        (d - startOfEpoch).TotalMilliseconds
And I added a little function composition to handle Meetup’s little quirk:
    let fixUnixTimeStampForMeetup = unixTimeStamp >> uint64
At any rate, this is part of the reason I’ve got such a crush on FP and F#.  It does make it easy to build simple, reusable but still generic code.