Making Meetup

I was fortunate enough to be invited to a gathering of LGBTQ tech leaders at the White House to discuss and help address how tech and innovation could help issues ranging from social justice, to climate change, to women in tech.

Megan Smith was one of our event hosts, and I was so impressed with the way she approached the world’s issues with such a deep knowledge, optimism, and ambition for solving them.

In the afternoon we broke out into unconference style working groups to start planning the TechUP Inclusion + Innovation Week in DC in November. I chose the Women & Girls group and it was there that I was able to listen and speak with others about how to create an event that tangibly helped increase the exposure and inclusion of women and girls in tech.

It was a great event and I was overwhelmed with the concentration of brilliant, visionary, and humble tech leaders assembled in one place.  I learned a great deal just speaking with as many people as I could.

Thanks so much to Leanne Pittsford and the Lesbians Who Tech community for inviting me and organizing such an impactful event.  It was one of the most inclusive and diverse tech events I’ve ever been to, so a huge props to Leanne and the crew for intentionally making that happen.

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.

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)

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.

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!

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!

Our Devpost site contains bios and fun facts about some of our team members, myself included. We’ve also shared data on the ethnicity and gender background for some of our employees, broken down by the company and our engineering team.

There are many factors which go into building an inclusive culture at Meetup and this data represents only one part of the picture. A fuller portrait would include people such as our CTO, Yvette Pasqua, and other women in leadership roles. What this data does is provide a snapshot of team members who self-identify within the parameters of federally required EEO-1 reporting categories and have chosen to share this information. I care deeply about inclusion both within and beyond this. For example, this data doesn’t capture gender information aside from “male” and “female” - a topic which I will be speaking about at PyCon this June.

I think that sharing diversity data is a critical first step towards transparency and accountability. I’m proud to work to help create a company whose makeup reflects the diversity of our Meetup members, and to help create an industry whose makeup reflects the diversity of our world.

Towards the end of the first week of March, on March 4th and March 5th, Meetup put together a small team of engineers who volunteered to attend the 6th annual Northeast Scala Symposium in Philadelphia.

I am an engineer on Meetup’s Member Engagement team, building a system that delivers smart and personalized notifications to members on our platform. I am also a part of Meetup’s Core Engineering team, where we are using Scala a lot in order to build out our platform. Given my work and interest in Scala, I was one of the engineers who participated in the trip, and I’d love to share some of the things I learned during Day 2 of the event!

This was the first language conference I have ever attended and it was even more exciting to me, given that I only started working in Scala since I joined Meetup, almost 2 years ago, straight out of college!

Day 2

Day 2 was the unconference day and it started with a casual meeting, in which every participant who had something to present would take a timeslot on a spreadsheet, such that at the end of the meeting we had a relative schedule for the day. After this, everyone was free to go to whichever presentation was most appealing to them.

And off I went!

Early Morning Category Theory with (Rúnar Bjarnason)

Eager to learn more about Scala and the theoretical background behind it (and being a math nerd), I picked Category Theory as my first presentation to attend. I did not know much about what Categories are in Scala and what kind of rules govern these entities, but I went in excited to learn something new.

The talk started with an abstract definition of Categories as collections of objects and arrows (or maps/morphisms) that define relationships between the objects. These concepts seemed very familiar to me from those of Set Theory.

Rúnar went on into describing Functors (maps between Categories, that preserve their structure) and then explained what Monads, Monoids and Comonads were, while also doing some whiteboard Scala examples of all of this. These topics were necessary background needed in order to answer a question posed by someone in the audience:

Prove that List is a comonad in the monoid category of List

Using the information absorbed up to that point, we were able to follow a simple proof of the statement.

This was my first ever exposure to Category Theory and I loved it! Rúnar's explanations made me dig more into it after the conference!

Scalaz-Stream Workshop with (Rúnar Bjarnason)

The second presentation I went to was also led by Rúnar Bjarnason, but this time it was very hands-on. He introduced us to a small IRC client & server built using scalaz-stream and everyone in the room had to implement a feature of their preference to add to it.

I went on trying to implement the ability to change nicknames while in a chatroom. The process of working with scalaz-stream and, implicitly, with scalaz was relatively new to me since I haven't written pure functional code using scalaz before, but it was a really good experience to be exposed to both of these Scala libraries.

By the end of the workshop, my implementation ended up being somewhat functional :)

Living with SI-2712 with Daniel Spiewak

After a couple of other presentations, I got to my last presentation of the day. It was about a known Scala compiler bug and it involved a lot of live coding, type-level programming, category theory (d'oh) and just pure amazement.

The gist of the presentation was a proof of concept of the compiler bug and ways to get around it. It was very well explained and, even though the material got pretty intense towards the end, I enjoyed the deep dive!

Conclusions

Interested in working at Meetup? We worked with our friends at DevPost to put together a page about our engineering team. Find out details about dev process and our tech stack, plus check out interviews with our great engineers.

What happens when you take the Meetup engineering crew to the NY Historical Society - Silicon City Exhbit? Someone ends up on their modern laptop in the middle of a history lesson, was he just trying to mock the Univac or was he just trying to make sure Meetup was running smoothly!

We got to see some older progamming languages and associated mainframes.

We saw punch cards and old satellites, like the Telstar 1, launched in 1962 it successully relayed the first television pictures, telephone calls, and fax images.

All in all it was a great trip through the evolution of technology, which reminds us here at Meetup to continue to evolve our technologies and platform so that we can constantly improve the user experiences our organizers and members have. We love our tech, but we also love building community both inside and out of Meetup.

More pics

New York is home to companies who are evolving the face of technology.

We listen intently as we learn people used to be called computers and eventually as we all know it's what we now call the hardware.

Always be gaming.

Can't blame that on auto-correct.

We believe in constantly futurizing Meetup, so we’ve been spending a lot of time prototyping, learning, and making as we move towards Rainbows & Unicorns and making Meetup even better. We hope that by sharing what we’re learning along the way, it helps other engineering teams positively change their company too.

Selecting the right tool for the job is core to our engineering culture. There are five big areas we’ve been focusing on so far, and with each one we’ve been building a little piece of Meetup product as the key part of our assessment.

Build, test, launch, test, build...

We're rebuilding the backbone of Meetup -- our continuous delivery pipeline. We decided that in order to empower our engineers with the tools and infrastructure we have boldly envisioned, we’d need to use a new set of CI and automation tools and frameworks. We're currently using Jenkins which has served us well, but really like what we're seeing with Bamboo as a complete CI pipeline tool with very high quality plugins and orchestration hooks.

We're reassessing our testing frameworks across our core, web, and mobile platforms so that we have a stronger suite of unit/integration/UI/regression tests with even more coverage.  So far we’ve been really enjoying using Selenium, Appium for our native apps, and the Robot framework for acceptance testing.

Moving Meetup to the cloud

We're a (mostly) bare metal shop with multiple data centers now. We’re ready to take advantage of the benefits of moving to the cloud including auto-scaling, the ability to create phoenix systems with instances automatically rising out of ones that have crashed and burned, and reducing operational effort and total cost of ownership. 

Our infrastructure team has been building our new continuous delivery pipeline and other tools on both Amazon Web Services and Google Cloud Platform and we’re close to making a decisions as to which cloud provider we’re selecting.

A world full of services

Our core engineering team is breaking up our monolithic back-end platform into a service-oriented one.  We're not yet sure how “micro-service” we'll get since we're still figuring out how bounded contexts apply to Meetup product, where the seams really are in our codebase, and what parts of our monolith need to scale in bigger or different ways than the others.

We’re very excited to start on the path to learning and making decisions by building our first new service using part of the Netflix OSS stack. We did initial prototyping using Twitter’s Finagle and Typesafe’s Reactive Platform as well, and they’re all great stacks. But we’ve decided on the Netflix OSS and are starting off using Hystrix, RxJava, RxScala, and RxNetty to build our first service.

Data is king

Meetup has happily used MySQL as our primary data store for over a decade. Over the years we’ve added things like Hadoop for distributed computing and Redshift for data warehousing. We’re at the right time in our growth to evaluate if other data store options will enable us to scale and perform better. We did a lot of research and prototyping with SQL, NoSQL, and distributed NoSQL data stores, and were inspired by the idea of turning the database inside-out.

We decided that we’d learn the most valuable information if we built our first new service using a NoSQL distributed data store like Apache Cassandra, Amazon Dynamo, or Google Cloud Datastore, which we’re internally calling Cassandra* for short. Our decision on which one to use will align with our impending our cloud provider decision and until then we’re prototyping using Meetupy data with each.  

React or not here we come

Our web engineering team has been prototyping both Ember and React by building a small part of Meetup web product with each. After that was done, and a lot of debate throughout the whole team, we’ve decided on React as our new JavaScript web framework.  

We’re super excited to be building an isomorphic JavaScript web stack to facilitate iterating web product in a faster and more productive way. We especially like the React ecosystem, separation of concerns, and preference for small, sharp tools.

Futurize Meetup with us

While we’ve answered many questions, we still have a long way to go.  We’re thrilled to work at a company where we have the time to prototype different technologies and build towards the best answers for both current and future Meetup product. As we progress, we'll be writing posts that dive into the specifics of what we’re learning, the tools, technologies, and frameworks we're using, and how they're working for us.

Last week, Meetup's engineers took 48 hours off from their normal schedules in order to participate in our quarterly hackathon!

The theme of this hackathon was 'Rainbows and Unicorns', in reference to our remaking of the Meetup platform that you can read about here.

Check out some photos of the team in action:

At the end of the 48 hours, we all demoed our projects, whether they were successful or not!

And gave out these awesome Rainbows and Unicorns-themed prizes to the winners (yep, those are LED-lit horns):

The winners were:

Most Ridiculous:

Nathan Stilwell - Magic Pipe

Most on theme:

Evan Estola/Matt Kime - Meetup on Alexa

Best Overall:

Rick Boenigk - React Native Door Check

We're always making Meetup better. For 14 years, we've been growing, evolving and making Meetup a little better every day, with every release. This year, we've kicked off one of the biggest endeavors in Meetup's history to make Meetup even better. 

We're remaking the Meetup platform, infrastructure, and dev tools. Our objective is to empower our engineers to be more productive and love using our dev tools to make and ship product faster and better than ever before.

When we kicked this off, we did a lot of brainstorming, research, talking, listening, prototyping, and drew a lot of diagrams. The very first diagram we drew and took a picture of was this (raw, not doctored) photo:

What did we do when confronted with an unexpected rainbow shining right through our core platform as we drew up ways we’d re-architect it? Well, we of course named the remaking of Meetup the Rainbows & Unicorns project.

As we progress, we’ll be posting more specifics around what we’re prototyping, learning, and making as we move towards Rainbows & Unicorns. We hope that by sharing what we’re learning along the way, it helps others who might be doing something similar.

For years, Meetup has been available in 6 different languages. These are:

English

French

German

Italian

Portuguese

Spanish

And while these languages all have their own nuances and challenges when it comes to localizing for them, it was poor preparation for some of the issues we would run into when localizing for our next supported language...

Japanese

Yes, that is right, Meetup is now available in it’s 7th supported language, Japanese! It is our first supported language with a non-latin-based alphabet.

We have run into many issues because of this, but the most interesting presented itself when it came time to implement alphabetical sorting.

Alphabetical Sorting

On first glance, alphabetically sorting a list of strings seems like a trivial task.

>>> Ordering .natural() .sortedCopy(["eagle","cat","dog","bird","falcon","duck"]) [bird, cat, dog, duck, eagle, falcon]

However many things can actually complicate this, such as capitalized letters:

>>> Ordering .natural() .sortedCopy(["eagle","cat","dog","bird","falcon","duck","Dog"]) [Dog, bird, cat, dog, duck, eagle, falcon]

A user would expect Dog and dog to be sorted next to each other. However, because these strings are sorted by character code, this is not the case.

To do a more language-friendly sort, you can use something called a collator.

>>> Ordering .from(Collator.getInstance(Locale.US)) .sortedCopy(["eagle","cat","dog","bird","falcon","duck","Dog"]) [bird, cat, dog, Dog, duck, eagle, falcon]

This performs the sorting based on rules from the American English locale. So how about Japanese?

Japanese Alphabets

The first thing to note is that there are multiple alphabets in play here:

Kanji: Thousands of symbols borrowed from Chinese and that can form words. Ex: 東京 - 東 means East and 京 means Capital city, so that’s Tokyo).

Hiragana: Phonetic script (46 characters), for words that can not be described with Kanji, or to make the pronunciation of a word using kanji transparent. Each character corresponds to a sound, like ma, ka, sa…. Ex.: とうきょう (To-ky-o)

Katakana: Same as Hiragana (48 characters) but to represent the pronunciation of foreign words. Ex.: マクドナルド (ma-ku-do-na-ru-do, which is how the Japanese would pronounce McDonalds)

Romaji: Latin characters, used to make the pronunciation of Japanese words transparent for those who can’t read the Japanese alphabets (ex: Tōkyō), or used to look trendy, foreign, in some cases.

Japanese ordering

Strings in Japanese can be made up of characters in any of these alphabets, and using ‘dumb’ sorting, these alphabets wouldn’t sort together at all. However you can use a collator based on the Japanese locale, and that gets you pretty far already.

健康 (Health)

ダンス (Dancing)

テクノロジー (Tech)

家族 (Family)

ゲーム (Games)

Once sorted with the collator, it becomes:

ゲーム (Games)

ダンス (Dancing)

テクノロジー (Tech)

健康 (Health)

家族 (Family)

See Below:

x = [u”健康”, u”ダンス”, u”テクノロジー”, u”家族”, u”ゲーム”] >>> Ordering .from(Collator.getInstance(Locale.JAPAN)) .sortedCopy(x) [ゲーム, ダンス, テクノロジー, 家族, 健康]

The problem

This will sort words starting with Katakana and Hiragana correctly, but will always put the words starting with a Kanji at the bottom of the list. Why? Because a computer does not know how a Kanji is pronounced, and ordering in Japanese is based on pronunciation, following the strict Gojūon (literally, “fifty sounds”) ordering table for kana alphabets. First should come the words starting with the sound a then with i, u, e, ka, ki, ku, etc.). With Kanji, the characters used do not each correspond to the same sound every time. The pronunciation changes depending on context, and currently computers can not guess that.

Ex.: 今日 can be read as きょう (kyō) or こんにち (konnichi).

The solution

Given a large list of arbitrary kanji strings, we would be unable to sort them correctly without human intervention giving us an indication of how it’s pronounced in its context. But luckily for us, we don’t have a large list of arbitrary strings! We have a relatively small list of static, already known strings. So we did in fact have a solution. The thing we needed to sort was the list of categories that Meetup Groups can belong to. We just needed the phonetic spellings of our categories which had Kanji-based names, as we learned earlier that any Kanji-based name can be converted into a more transparent phonetic version.

We asked our translators to help provide these, and then created a new locale called ‘Japanese Phonetic' (ja-x-phonetic) and a new translation file containing these phonetic translations. And then, when ordering the list on the backend, we temporarily translated the categories into ja-x-phonetic, sorted them using a Japanese collator, and then re-translated them back into normal Japanese while maintaining the same order. Et Voilà!

Conclusion

So we solved our problem, but this is an issue which continues to exist for things like user generated content. If we had a large list of member names in Kanji that we wanted to sort, this would be impossible to do without either transliterating each of these ourselves (not scalable), or prompting users to provide phonetic spellings of their names in addition to the Kanji one (more scalable).

Meetup recently made the switch to Slack for our team communication platform and our clearinghouse of puppy gifs. One of my favorite features on Slack is how incredibly easy it is to create integrations. In order to get familiar with how the webhook system works, I decided to write a little ruby app that uses the Meetup API to post the next available Meetup event for a given group. If you are an organizer who is using a Slack team to facilitate conversation outside of your Meetup events, host Meetups in your office, or just want to let your coworkers know when something interesting is happening, this might come in handy. Enjoy!

https://github.com/jeffcampbell/meetup-slack