@ML4ALL Meet Clair J. Sullivan & Ricky Hennessy

ricky-hennessyUsing Machine Learning to Increase Health Insurance Coverage

Ricky (@rickyhennessy) works as a Sr. Data Designer at Fjord, Design and Innovation from Accenture. Previously, he was at frog design, where he worked as a Sr. Data Scientist. Working at the intersection of data science and design, he’s been able to apply a more human centered approach to data science. He has also earned a PhD in biomedical engineering at UT Austin.

Working with a state run healthcare exchange, Ricky & team utilized their existing data to develop a machine learning model that could predict whether or not an individual was going to sign up for insurance through the exchange in the next open enrollment enrollment period. This model can then be used to inform outreach campaigns targeted at individuals at risk of dropping out of the exchange.

In Ricky’s talk, he’ll cover the entire process from defining the problem to deploying the model, and discuss how this work has led to other application of machine learning inside of CoveredCA.

clair-sullivanA Machine Learning Win at GitHub …and So Can You!

Clair J. Sullivan (@cjisalock) is currently a data scientist on the Machine Learning team at GitHub. Prior to joining GitHub, she was a professor in Nuclear, Plasma, and Radiological Engineering at the University of Illinois at Urbana-Champaign where she worked on the intersection of the Internet of Things and machine learning with nuclear security. She also has worked on these topics from within the federal government and the national laboratory system. In addition to her work in nuclear security, she founded La Neige Analytics to provide data science services to the ski industry. She received her PhD in nuclear engineering from the University of Michigan and has published extensively in the subjects of geospatially-enabled machine learning and nuclear security.

In October of 2017, GitHub launched a new feature called Repository Recommendations as a way to connect people to code. Users are presented with a personalized list of repositories, sorted by which ones might be of most interest to the user. Repository Recommendations are a tool to grow the open source community by connecting users to projects they might be interested in contributing to or to other users with whom they might collaborate or learn from.

Machine learning practitioners will recognize this as a type of recommendation engine, but how was this actually implemented at GitHub? This talk will present the details for how the recommendation engine was created at GitHub, the math behind the scoring, and the technology used to make it happen. In addition to talking about how this was done at GitHub, the talk will also describe how users can make their own repository recommendation engine using GitHub’s publicly-available data.

Checkout ML4ALL and get your tickets to ML4ALL here!

ML4ALL Speakers – Meet Paige & Suz

Hello everybody and especially the upcoming ML4ALL attendees! For those that haven’t registered, here’s the link for that, and for those that have welcome aboard! Here’s two of the excellent speakers that will be presenting at ML4ALL Paige (@DynamicWebPaige) and Suz (@Noopkat)!

Paige & Suz both work on the amazing, now somewhat famous Microsoft Developer Advocacy team others like Peter Bright (@drpizza) wrote about in “Microsoft’s renewed embrace of developers developers developers” and James Governor (@monkchips) wrote in “On Hiring Jesse Frazelle: Microsoft’s developer advocacy hot streak continues” and I even wrote a blurb about many months ago. They’ve added even more awesome to a great team and will be coming to ML4ALL to do more of that.

Paige Bailey

Kill (Deep) Math

Paige will be showing us how to kill the maths of the deep. She tweeted a bit about this killing thread here…

Suz HintonNew Tools for Old Problems – Machine Learning for Access

Suz is going to show you how to level up around accessibility using script injection and machine learning  using some historic ‘guerilla accessibility’! She’ll give both a technical and social commentary of what the missed opportunities to use new technology for greater good. But alas, albeit we’ve missed those opportunities Suz has ideas on how we can code ourselves out of that difficult box!

Suz also videos on Twitch.

Beyond the Twitch, she’s also got a newsletter, you can sign up here and also a blog + site here.

Checkout ML4ALL and get your tickets to ML4ALL here!

Crazy Conf Notions. Viable?

While at Goto Conf in Chicago today I had two thoughts while talking with Joe (@joelaha) while hanging out with Bridget (@bridgetkromhout) while waiting for Lena’s (@lenadroid) talk on “Distributed Data Stores on Kubernetes“. All that wrapped up into a few ideas for future conferences. Here, I present them to you dear readers, please lament, lamblast, lacerate, or decimate this list of groovy ideas I have. Comments welcome, or scream at me a tweet or two on Twitter @Adron!

Idea 1 – Burn ALL the Slide Decks

0_vpfhlOa6GkQ8RGDp

I burnt down ALL the slide decks, they’re all gone. Join me!

I want to run a conference, and am curious who’s with me, where nobody would use slides to present. We’ll just toss all that out the window and present straight code. If you need cats in your presentation we’ll do what we did at Node PDX last time, we’ll just HAVE CATS ON THE STAGE!

So often the bullet points and images and distractions of slide decks are truly just a crutch. I write this as I see the beautiful, amazingly designed, inspirational, artistic, and awesome slide deck that Lena has and don’t want to lose that. But the idea of transferring that type of energy into just the pure presentation of the ideas would be an interesting challenge that I suspect would enable speakers to create some truly amazing talks. That is, for those brave enough to accept such a challenge!

Idea 2 – Complete Blind Topic Only Talks

justice

Justice!

Who would be interested in going to a conference that is only talk details and does not show or list the speaker that will present the topic? Would you attend a conference purely on the ideas presented? What would be the side details of this that would encourage you to attend such a conference? I personally would be stoked to go to a conference that is purely ideas only, and we get to have a surprise when we show up and there’s the speaker, whoever it may be, that shall guide us into the topic!

Idea 3 – Ideas Challenged BATTLE!

Think Battle Bots! If you’re unaware of the craze around Battle Bots, check out the Wikipedia, @BattleBots for more! The idea, is basically instead of bots though, you’ve got an idea and someone may oppose this idea and wants to pick it apart, and you want to defend it. It might get a bit rough, but it also could be – we’d of course keep it civil – very interesting to ensure we’ve got no proverbial elephants left standing in the room! Just imagine combing through an idea with a whole room full of people while two experts take apart an idea from two distinct points of view?

These are just a few of the ideas for organizing and setting up some new conferences that don’t fall into the same rut of the existing conferences. But this isn’t all, as Lena wrapped her talk (and I wrapped up this post) I found myself in another conversation about chaps, leather, distributed systems, and the various disparity in distribution of products to leather shops and the distinct supply demand invariances of managing this data.

Ok, so that’s a lot to load up in that last sentence, derived from the conversation, that I may wrap up into another post. But that’s for another time. For now, throw some tweets at me @Adron or leave a comment or three about what you’d like to see in a conference that would break the staleness of the same ole’ same ole’. Cheers!

My Node.js Story

Once upon a time in a part of the tech universe far far away, there was a general consensus to block all JavaScript from browser execution. It was the way things were because JavaScript was seen as harmful. You see, the early miscreants of that time had used JavaScript to write all sorts of problematic code that would attack, steal, or otherwise undermine the data one sent across and received on the internet. This is the time I could have started learning JavaScript, but because of its horrid reputation I stayed far away and wrote C, C++, C#, Java, and event some RPG, COBOL, Pascal, and some other code. It was glorious, and the languages were beautiful in their own ways, while JavaScript was shunned by almost everybody in that tech universe! **

Today, things aren’t all that much different, but we make it easier for the whole horde of miscreant scripters to write problematic code in JavaScript. The difference is we allow it everywhere and just try to catch it and prevent execution. Thus, different, but the same, it’s a crazy world we live in.

I started picking up a little JavaScript at the tail end of 2007, when the “JavaScript: The Definitive Guide” was the top book to delve deeply into using JavaScript. It wasn’t another year until the seminal “JavaScript: The Good Parts” cut down the size of what one really needed to delve into by removing the cruft and focusing on the good parts. Slowly, JavaScript was finally starting to take shape as something useful.

Writing JavaScript at this time was a mutant challenge of having it look like Java while being organized like a trash pile of scripts that had no way to manage dependencies or otherwise. I mean, NPM was years away from existing, and really the concept of libraries in JavaScript seemed to be a foreign concept at the time.

2008 rolled around, “JavaScript: The Good Parts” came out, the changes started rippling through the industry and as traction started to mount. The penultimate event occurred the following year in 2009, which at the time almost nobody noticed. Dahl started Node.js at Joyent to enable server side JavaScript code use. At the time, many were flummoxed by the notion, weren’t confident in the single threaded event loop, and overall its release and the project continuing were in jeopardy from this point.

But the project continued and persisted!

Two more years of development, which I knew of and even met, talked with, and had the chance to see Dahl present in Seattle at Seattle Scalability Meetup. I still hadn’t spent any real time dedicated to learning how to write JavaScript or even deal with this new Node.js thing! I was still slinging some solid C#, Java, and more SQL than I even cared to admit.

I then fell even further away from any notion of learning JavaScript further by getting into distributed database systems with Riak (It’s a now somewhat dead distributed database written in Erlang). It was honestly one of the most bad ass distributed databases that has or did exist! But I digress, I had fallen far outside of needing JavaScript but still had a huge fascination and interest in web development. At least, in a peripheral “I want to know this so I can build whatever I’d like when I’d like” type of way.

2012-logoThe turning point for me, while in the midst of working on cloud, distributed systems, and even fighting with Cloud Foundry, my good friend Troy Howard (@thoward37) and I after a few rounds decided we were going to run a conference as an excuse to learn Node.js better. That evening at The Side Door in Portland we decided we’d name the conference Node PDX and hold it in just about ~4 weeks. What’s obvious in hindsight is that one doesn’t merely run a conference with just ~4 weeks to organize it, but that’s what we did and we managed to – miraculously – pull it off!

With this conference it lit of an interest far beyond what I had expected. Troy and I were already starting, after this great experience organizing and running this conference with this absolutely stellar community and audience, we were ready for round two! At the time both he and I spent a little time helping out AppFog (previously PhpFog, now gobbled up by CenturyLink). By proxy of this we started, oddly enough largely on the side, getting more and more into Node.js and JavaScript itself.

nodepdx-badge_256x128_white_noborder.gifNode PDX then took on it’s 2013 version! Again, a super awesome experience for all and more JavaScript everywhere! We started to get involved with Nodebots, drones, and more with the community at this conference. Node.js was enabling JavaScript to permeate practically every project at this juncture in time. Which was great for us that actually dug JavaScript, but horrible for those that hated JavaScript. But haters, meh.

IMG_3529-5K

The organizing of this Node PDX had Luc Perkins join Troy and I. We expanded even further and this event was really huge, with more peripheral activities and even more hacking on cool projects, conversations, and things launched outside of the conference itself then we could have even imagined. It’s rather amazing what started as just a random idea over beers (while hacking on some code projects) can turn into!

This slideshow requires JavaScript.

Then, my experience and use of Node.js with intensive client and server side JavaScript was amplified even further when I formed a startup with my friend Aaron. This was a great experience, even met and brought in Milan (@MilanLoveless) to help out with coding, and built a wicked awesome distributed ingest and processing analysis system (even with a little sprinkling of early days machine learning) all with Node.js. JavaScript EVERYWHERE!

Over the years since, we’ve had another Node PDX which was awesome too. We’re aiming, prospectively, for another one in the coming years but we’ve not pinpointed the exact dates yet.

In the meantime I’ve started writing a ton of other code that isn’t always in JavaScript. More C#, Java, Go, and even some Python. I’ve gotten mixed up in the wild landscapes of data analysis tools running machine learning algorithms all the way to some of this crazy site reliability work in the midst of devops monikers writing server side CLIs with JavaScript and Go. But nothing specifically focused around writing JavaScript with Node.js in spite of my working to keep up with where the technology is headed for the future.

Because really, if things unfold right, JavaScript and Node.js are positioned for continued growth and relevance going forward. There’s significant reasons to move forward projects with that versus a lot of traditional stacks. It’s led the way technologically (remember when Nodejs had streaming? Yeah, like a year or more before most of the other stacks, and it was implemented well versus the trash pile of streaming in let’s say, the .NET world – since fixed, but at the time holy smokes it was bad). This trend continues with Node.js, albeit the stack being a bit more consistent, solid, and enterprise focused now than it was back in the early days of 2009-2013.

Now I’m at GOTO Conf Chicago, 2018, about to present tomorrow on the wild gesticulations of Node.js and JavaScript over the years and where it’s headed. I’ve even started to put together a reference app (which goes slowly at the moment). I’m rolling multiple nodes of Node.js and using Cassandra for a multiple cluster node underneath all that with Kubernetes hosting said service nodes on Kubernetes nodes all amongst it. Needless to say I think my title is fitting, “Node Systems for Node.js Services on Nodes of Systemic Nodal Systems“. It’s gonna be a fun talk, and a great place-marker for me as Node.js v10 has just been released, and Nodejs itself is turning 9 this year!

Alas, the story continues, and I’m looking forward to the saga!

Notes:

** The tech universe that I speak of was merely, shockingly, the tech universe of the early 00’s and late 90’s. JavaScript, being created in 1995 and not really gaining real traction as anything legitimate to use for application development until around 2005-2008. Even then, so often seen as problematic, and today we just seem to deal with the frustrations of using a scripting language as the primary driver of modern web based application development.

Kubernetes 101 Workshop

Today I TA’d (Teacher’s Assistant) a course with Bridget at GOTO Chicago Conference. There were a number of workshops besides just the Kubernetes 101 like; Working Effectively with Legacy Code with Michael Feathers (@mfeathers), Estimates or NoEstimates with Woody Zuill (@WoodyZuill), Testing Faster with Dan North (@tastapod), Data Science and Analytics for Developers (Machine Learning) with Phil Winder (@DrPhilWinder), and so many others that I’d love to have multi-processed all at the same time! Digging through Kubernetes from a 101 course level was interesting, as I’ve never formally tried to educate myself about Kubernetes, just dove in. My own knowledge is very random about what I do or don’t know about, and a 101 course fills out some of the gaps for me.

The conference is located in a cool and sort of strange place for a conference, out kind of in the lake, called the Navy Pier. Honestly, I dig it, it’s a cool place for a conference. I enjoyed the ~15 minute walk from the hotel to the location too, because it’s right there on the tip of the pier, as shown in the fancy map below.

chicagonavypier

The workshop is going well. Bridget is filling up student’s brains and I’m going to dork around Kuberneting some Cassandra and Node.js for my talk. I’m pretty stoked as the talk has given me a good excuse to delve into some Node.js again, from a nodal systemic viewpoint, “Node Systems for Node.js Services on Nodes of Systemic Nodal Systems” this Thursday.