Found a way to “justify” my recent splurge on a Raspberry Pi 2. Truth be told, I was enticed by an deal I saw on Lifehacker. I was drawn in by the idea of applying IoT on a new platform. Last year’s Arduino is sitting up in my closet, alongside its Furby friend, awaiting a visit with a soldering iron.

Lo and behold – one of my DevChix fellow email listers posted that Strange Loop’s Call For Proposals is open. Hmmm – if I can submit a talk, surely that justifies the dollars spent, yes? And heck, if it’s accepted, then I’ve further advanced a personal agenda of making women more visible in technology by showing how this ordinary woman becomes more visible in technology.

The trick: figuring out a topic that’s interesting enough _to me_ to justify the hours I’m going to spend building out the talk. For a technology talk, something just isn’t going to work out as originally planned, and there’ll be hours spent debugging and revising your original approach. Unless, of course, you already have the talk written, and where’s the fun in that? No, in my case, I want to see enough of the connect-the-dots to assure me it’s doable to get there, but not so many that there isn’t still a ‘reach’ and a ‘stretch’.

This go-round, I’m revisiting the Furby. It’s an easy attention-getter in an abstract. This time, though, I’m interested in playing with a new robotics kit called Gobot. I’ve been working with Go at work a bit, and getting a chance to see that skill used in a less practical form sounds like a lot of fun. Raspberry Pi is one of the platforms it supports, though it looks like I may need to contribute either an example or even possibly some driver code to help deal with sound… Knowing the hurdles I hit before with my Arduino/Furby talk and where I’d have liked to go farther, I’m really interested to see where a Raspberry Pi 2 + Gobot solution goes…

I’ll apparently find out by May 29th, and then the conference itself is at the end of September.  Looking forward to seeing what happens!

In some coding recently, I thought I saw an opportunity to explore Java8’s support for lambda expressions. I basically had a function I needed to call, once with one set of data, and once with another. I could repeat the logic (hey, it’s only 2 calls), I could write a method, or, maybe this is a candidate for a lambda expression.

In the below code, pre method or lambdas, the basic logic is that I’m examining a string to see if it’s wrapped in ‘/*’ ‘*/’. If it is, I’m stripping those off and returning that it was wrapped.

boolean isWrapped1 = false, isWrapped2 = false;
    
// first, strip off any comment wrappers, so we can appropriately parse
if (response2.endsWith("*/")) {
  response2 = response2.substring(0, response2.length() - 2);
  if (response2.startsWith("/*")) {
    response2 = response2.substring(2);
  }
  isWrapped2 = true;
}
  
if (response1.endsWith("*/")) {
  response1 = response1.substring(0, response1.length() - 2);
  if (response1.startsWith("/*")) {
    response1 = response1.substring(2);
  }
  isWrapped1 = true;
}

Written in lambda style…

boolean isWrapped1 = false, isWrapped2 = false;

Function<String, Boolean> isWrapped = s -> {
 if (s.endsWith("*/")) {
    s = s.substring(0, s.length() - 2);
    if (s.startsWith("/*")) {
      s = s.substring(2);
      return true;
    }
 }
 return false;
};

isWrapped1 = isWrapped.apply(response1);
isWrapped2 = isWrapped.apply(response2);

Now, the rub… and one which I realize would bite me in a method implementation, as well… I’m relying in my first implementation on the side effect that the string gets stripped of the ‘/*’. There’s no side-effects for strings when dealt with in a function. The original string goes in, you can muck with it all you want inside, and the original string is _still_ the one there on the outside.

Thinking it through, what I need to do is consider writing a 2nd lambda, so the code would look something more like this:

Function isWrapped {..
};

Function unwrap {..
};

isWrapped1 = isWrapped.apply(response1);
if (isWrapped1) {
  response1 = unwrap(response1);
}
isWrapped2 = isWrapped.apply(response2);
if (isWrapped2) {
  response2 = unwrap(response2);
}

Using strings clearly helped enforce no side-effect programming here… which, practically, makes for a better functional approach, at least per my understanding. Since I don’t intend to make those functions visible in any other place than within the invoking method, it appears to be a decently good pattern for DRY, without necessarily adding to the interface footprint of my class. Almost creates an approach of something even more private than private…