More Than Binary: Inclusive Gender Collection and You
This year, I was fortunate enough to be accepted to speak at a few tech conferences about a side project I’ve been working on over the past year. My project Gender Amender (https://github.com/anne-decusatis/genderamender) exists to collect gender information in a way that’s meaningful for both machine learning algorithms and people of all genders.
I just returned from PyCon (https://us.pycon.org/2016/) less than two weeks ago, which was a wonderful conference. I found the emphasis on community there to be inspiring and refreshing.
I’ll also be speaking at Open Source Bridge next week (http://opensourcebridge.org/sessions/1779) - I’m really looking forward to it, and I’d love to see you there!
If you can’t make it to see me speak in person and want to look at my talk resources online, or if you want to see all the sources I used, then you can find all that information in one place at my personal blog: http://anne.loves.technology/blog/talks/2016/05/16/more-than-binary.html
I’d like to thank all of my coworkers at Meetup for helping make this possible and for listening to me practice this talk over and over again for weeks and weeks.
Anne DeCusatis is a Core Engineer on Meetup’s Retention team.
Scaladays NYC 2016
This year, Meetup had the honor of sponsoring Scaladays NYC as well as hosting the official conference afterparty. For those unfamiliar with Scaladays, it is one of the largest yearly Scala conferences, often held in multiple cities around the world. This year’s conference in New York City had over six hundred attendees and almost sixty talks spread across four tracks over the course of two and a half days. Needless to say, myself and four other Meetup engineers had blast attending the conf.
(Opening keynote by Martin Odersky)
Some of our favorite talks in no particular order include (but are not limited to):
Data Structures of the Dark Side by Shimi Bandiel (@shimib)
Roll Your Own Shapeless by Daniel Spiewak (@djspiewak)
Implicits Inspected and Explained by Tim Soethout (@TimSoethout)
DDD and Onion Architecture in Scala by Wade Waldron (@wdwaldron)
Scala Goes Native by Denys Shabalin (@den_sh)
Two personal favorites of mine were Domain Driven Design and Onion Architecture by Wade Waldron and Being Creative with Genetic Algorithms and Typeclasses by Noel Markham (@noelmarkham). In his DDD talk, Wade illustrated DDD concepts via ‘the domain of cooking an egg,’ and even shared some sample code (https://github.com/WadeWaldron/scaladays2016). Noel’s talk was more Scala-centric, and was focused on explaining typeclasses by implementing a fun genetic algorithm which attempted to recreate the Mona Lisa.
(Side note: If anyone is interested in genetic algorithms, there’s a fun race car simulation that can be found here: http://rednuht.org/genetic_cars_2/)
We also got to hear directly from some folks at Lightbend (formerly TypeSafe) and the École polytechnique fédérale de Lausanne (EPFL) who are helping push the boundaries of Scala development. I would highly recommend checking out EPFL’s Dotty project, which “is a platform to try out new language concepts and compiler technologies for Scala” (https://github.com/lampepfl/dotty). Other exciting projects that were presented at the conference included enhancements to Scala.js, a registry for Scala libraries, and also taking Scala native by providing memory management features to Scala developers (https://github.com/densh/scala-offheap). The EPFL also announced the launch of the Scala Center, a new initiative that will act as the open source foundation for Scala with representatives from both the community as well as industry.
And of course, no conference is complete without a popping afterparty, hosted at your’s truly: Meetup HQ. We were pleasantly surprised at the turnout and had a great time mingling and hearing about all the exciting things (Scala and non-Scala related) our peers in the tech community are pursuing.
(Yay party!)
We were even blessed by the attendance of Scala’s creator Martin Odersky, along with many other luminaries of the Scala community.
(Meetup + Martin Odersky + Friends)
If any of the above post was remotely interesting to you and you’d like to find out more about what we’re all about here at Meetup, check out these interviews with our engineers (http://making.meetup.com/tagged/hiring)!
Meetup Core Engineering Manager Jake Levine on Phone Interviews
Ever wonder what to expect during a phone screen? Core Engineering Manager Jake Levine provides some insight into our process at Meetup with an interview with our friends at Devpost. If you missed our last interview with Devpost on culture fit, check that out here.
If you want to learn more about our hiring process and read some 1-on-1′s with our engineering team, go to our Devpost team page.
Meetup Engineering’s Rich Hsieh on Culture Fit
This week, Meetup’s own Rich Hsieh sat down with the folks at Devpost where they talked about culture fit. What exactly is it? And how is it valued at a company like Meetup? Check out the discussion here:
And then check out our awesome Devpost page where you can read more about what it’s like to work at Meetup, and what the interview process here is like. And you can check out all of our openings!
Making Meetup’s Apps @ Mobile Week NYC
Last week I was fortunate enough to give the keynote at Mobile Week NYC. It was entitled “It’s Time! What to do When Rebuilding Your App?” and is a case study in how Meetup made the exciting (and difficult) decision to rebuild and redesign our apps.
The keynote meant to answer the big question: “Once teams are spun up and start working on a project like this, then what?” Here are a few of the key Android and iOS engineering topics I covered in my talk.
iOS
One of the biggest decisions we had to make around rebuilding our apps was with our iOS app. Some background on our iOS app is that it was originally built in a 3 month extended hackathon type project back in 2009 by two engineers that did an awesome job getting an MVP shipped. The problem was, it was never re-written over the course of 6 years, accumulating a lot of technical debt. We knew the code wasn’t of the quality we wanted and our test coverage was way too low for our current standards.
Also, much of the institutional knowledge from those who had built the app over 6 years was gone, so we hired — in our opinion — the best mobile engineering shop in NYC — Lickability — to do an in-depth analysis of our codebase. Their output was a spreadsheet of every class in the app (almost 500 classes!), a recommendation as to whether or not the class was salvageable, and metrics around the test coverage.
Following such a detailed assessment, we had the data to know that we needed to re-write almost our entire model code. Naturally, in a redesign you have to rewrite the view/UI code as well, so it was a clear decision for us that in order to futurize Meetup, investing more time in a new codebase that met our quality and testing standards was the right decision for us. Futurize is one of our company values and means: “ We like shipping, but we like investing to ship faster in the future even more.”
After making that decision in 2015, it seemed obvious to us that if we’re going to rebuild our app, Swift was the only way to go. Among many other reasons we love Swift, we especially love that it is statically typed so is type safe just like the rest of our Scala/JVM stack.
Once the decision was made to rebuild our iOS app from scratch, the next key decision we had to make was Swift 1 or 2, because Swift 2 was still in beta. We decided on Swift 2 because it both compiles and runs faster, is a great boost to our team’s morale to be able to start off working with and contributing to a the latest open source iOS language, and we saw it as a great way to attract people who wanted to make Meetup now using the future of iOS.
The second decision we made was supporting iOS 9 and above for minimum version support in the new app. We had a lot of data that showed how quickly our member base would upgrade to iOS 9 and how few members would be left on iOS 8. We didn’t like that we’d leave any member behind. But, not only did the data support it, but our engineering assessment was that building for iOS 9 and above would significantly reduce the amount of code we’d need to write — freeing us up to build and ship other features faster. Specifically, supporting iOS 9 allowed us to use the new UIStackView class, providing an easy interface for laying out a collection of views and leveraging Auto Layout for creating UIs that adapt to the device’s screen size and orientation.
Android
The decision making process around building our Android app was very different. The foundation of our Android app was much better, the code quality and test coverage was much higher, and the lead engineer working on the app had already been working on it for several years.
We had the institutional knowledge in house to do an assessment of the codebase and determined that we’d have to refactor and re-write significant things, but that there were parts that would serve us well in the future. During our assessment we identified key areas we needed to address and this is how we handled them.
The biggest change we made was to go all in using RxJava for reactive programming in Android. It really helps us get concurrency under control with little effort because it abstracts everything to far fewer lines of code. This was a big deal for us because we’re loading so much data from the network using multiple API calls and our API has to support many different clients at once (Android, iOS app, Apple Watch, Web). So, it’s hard for the API to always return data to a client app in a single call that’s exactly the way each client app needs it every time.
Our Android team absolutely loves RxJava because they know that they can composite multiple calls on the client (meaning they can easily wait for both to complete, then do something in the app) in just few lines of code. They can do this without adding additional complexity (for example, composing Futures) or having to manage things like if a user tapped away from the screen. It’s been the biggest improvement for us in the new app architecture.
We’ve also loved using OKHTTP from Square as our HTTP client. It helps us load data from the API into the app faster, save bandwidth usage, and really make our app more responsive – it just feels and works awesomely fast.
We use Jackson for data processing and agree with the Jackson Project page that says it’s “the best data processor for Java”. It supports every format you’d want with streaming parsing and data-binding.
Last, but not least, Guava is a set of core libraries from Google that really helped us handle a broad range of things like collections, caching, I/O, and has really reduced the amount of code we’ve needed to write ourselves.
Thanks!
Mobile Week NYC was a great experience and there were a lot of interesting talks there. Thanks to the conference organizers for inviting me to speak and to everyone who attended and participated! I learned a lot and met many passionate, smart people doing great things in mobile.