Notes from StirTrek 2017

Full article

This is just a collection of my notes from the sessions I attended at StirTrek on Friday. If you're anywhere near Columbus Ohio (or even if you're not), check it out. It's typically the first weekend in May, and it's incredibly affordable at only $100 for a full day of sessions, lunch and light breakfast, and whatever movie du jour Marvel is coming out with.

If you want to see the full slide decks, some of the presenters are kind enough to share their material online, and the organizers aggregate them on GitHub:

Slides and materials from the 2017 Stir Trek Conference

Building concurrent systems with Akka.NET

Joe Wirtley shared his experiences with Akka.NET, a framework for building "highly concurrent, distributed, and fault tolerant event-driven applications on .NET & Mono". This session especially interested me since Akka.NET seems to bring the features of Erlang (which I've been using for the last year and a half) to the .NET world (which I've used for nearly 10 years). They both claim to support highly available, concurrent, fault-tolerant apps.

  • There are actors and supervisors, and the supervisors can handle a crashing actor (child) by restarting it, restarting all its child actors, or crashing and passing the problem to its supervisor. Very similar to Erlang.
  • It's possible to take a "snapshot" of a particular child, capturing information about it.
  • It supports many popular databases for storage.
  • Actors are not linked directly to one another; instead they send messages.
  • The messaging system is built-in.
  • If an actor crashes, all messages can be re-sent.
  • There's also a built-in scheduler that can easily send messages at some regular interval.
  • There are a couple Pluralsight courses for Akka.NET as well as a Gitter channel. There's a lot of resources at Petabridge too - not sure what their relation is to Akka.NET.

Joe uploaded his presentation to GitHub.

Securing Your API Endpoints

Seth Petry-Johnson shared some of the different methods you could use to secure API endpoints.

  • Basic HTTP auth is just base64 encoding the username and password, and sending them in plaintext in the header of every request. Requires TLS to be secure.
  • Digest auth md5 hashes the password, so it's more secure for transporting (no TLS required). The server looks up the password and hashes it too, then compares the two hashes. It's insecure because it means the password is unencrypted on the server.
  • API keys are even better, and replace sending passwords
    • Bearer tokens are sent in plaintext (requires TLS). Can be sent in header or querystring, but qs is considered less secure (cacheable, easy to accidentally share link with someone).
    • HMAC doesn't require TLS. It involves generating a signature using a private key (similar to SSH?), but since the server needs to be able to access the API keys, it poses a risk if the database is hacked. I think he said that could be mitigated by expiring the API keys occasionally..?

Seth also talked about how OAuth helps the apps you use share (limited) data between one another without exposing your passwords.

He said something else that caught my attention too - OAuth is for sharing data, not authenticating. It seems a lot of sites do use it for authentication. For example, Trello (a great product I've used for years and would recommend trying, btw) lets you create an account by authorizing with your Google account. I'm not sure if that's the kind of scenario he was talking about, and I didn't get a chance to ask him for clarification afterwards.

More Better Quality Coverage

Jim Holmes reminded us that quality is a team effort.

  • "Quality is something of value to someone" ~ Jerry Weinberg
  • Quality may mean something different for each project or customer, or even for people on the team
  • Business quality is not the same as team quality.
    • Business owners don't want to hear about cyclomatic complexity
    • They're more concerned with legal issues or the budget
  • Discussions between all concerned parties should start before writing a line of code.
    • Three Amigos is a strategy where a developer, tester and owner walk into a bar ... um, they sit down for 5 or 10 minutes and hash out: What am I doing? Why am I doing it? How will I know when it's working?
    • This is better than the "oh crap" method where, months into development, everyone discovers the project doesn't meet expectations
  • Give pairing an honest try, and devs should try pairing with testers too
    • Immediate feedback
    • Shared knowledge
    • Cross pollination
    • Better test coverage

Jim's presentation is on Speaker Deck.

The UX of Voice

Tim Rayburn covered an interesting growing field. Devices like Alexa, Cortana, Siri and Google Home have little to no physical or graphical interface. Their interfaces are through voice commands, so what does user design mean in that context?

  • Localization is important even within the same country due to local dialects. Like ordering a coke in one area might mean the brand Coke, but in another area it might just mean "a soda".
  • Queries and responses to the user should be kept short. More and short is better than less but really long responses.
  • Must respond quickly to avoid irritating delays.
  • Different ways of talking to the user
    • Text-to-speech easiest but least natural
    • SSML gives more control
    • Voice acting is best quality, important to convey emotion (but it's the most expensive option too, I'd wager)
  • Beware the uncanny divide (typically refers to rendering graphics, the point at which the mind stops filling in missing details, and begins pulling apart the rendition)

That last one is also referred to as the "uncanny valley". Basically, make something a little more "natural" or human and its okay, but make it too (yet not quite enough) human and it just gets creepy and annoying. Here's a decent video that demonstrates it.

There were a couple other sessions I attended, but not everything is going to be a hit with everyone and I didn't personally get much out of them. All-in-all though, great material.


Grant Winney

I write when I've got something to share - a personal project, a solution to a difficult problem, or just an idea. We learn by doing and sharing. We've all got something to contribute.

Comments / Reactions