Making Meetup

Moving Day

richmeetup — Wed, 01 Mar 2017 11:57:25 -0500

We’re hosting our blog on Medium now. Make your way over there.

White House LGBTQ Tech and Innovation Summit

yvette-meetup — Tue, 30 Aug 2016 10:00:31 -0400

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.

More Than Binary: Inclusive Gender Collection and You

anne-meetup — Fri, 17 Jun 2016 15:53:20 -0400

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

confoundead — Mon, 23 May 2016 17:09:35 -0400

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

richmeetup — Thu, 05 May 2016 10:29:33 -0400

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

jakemeetup — Thu, 21 Apr 2016 09:50:49 -0400

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!

http://devpost.com/teams/meetup

Making Meetup’s Apps @ Mobile Week NYC

yvette-meetup — Mon, 18 Apr 2016 16:57:01 -0400

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.

Diversity and inclusion on Meetup’s engineering team

anne-meetup — Tue, 05 Apr 2016 12:00:16 -0400

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.

Anne DeCusatis is a Core Engineer on Meetup’s Retention team.

NE Scala 2016

vlad-meetup — Thu, 24 Mar 2016 17:46:47 -0400

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

I really enjoyed my time at NE Scala and learned a lot of new things, from theoretical aspects of Category Theory, to more applied concepts using pure functional scalaz. I am very excited for the next conference I’m going to attend (or even unconference, since Scala Days 2016 is approaching and will be in NYC :) )!

We’re hiring!

richmeetup — Thu, 17 Mar 2016 15:20:28 -0400

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.

http://devpost.com/teams/meetup

At NY Historical Society - Silicon City Exhibit

lena-anne-meetup — Thu, 03 Mar 2016 21:32:51 -0500

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.

I think Angry Cat is just lonely.

Futurizing Meetup

yvette-meetup — Thu, 03 Mar 2016 09:40:42 -0500

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.

If you want to build the future of Meetup with us, learn and experiment with new technologies, or have ideas to share, check out ways to join our team.

Hackathon!

jakemeetup — Wed, 24 Feb 2016 14:22:25 -0500

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 had our fair share of ridiculous hacks, as well as practical ones. It was a lot of fun, and a lot of cool ideas came out of it. Many of them might even get launched in some form or another!

Making Meetup Even Better

yvette-meetup — Thu, 18 Feb 2016 22:47:16 -0500

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.

This week, we’re all busy with one of our quarterly Meetup-wide hackathons, aptly themed: Rainbows & Unicorns: futurizing Meetup. Stay tuned for more about what we’re hacking and making – it’s guaranteed to be quite colorful and fun!

hackathon progress pic.twitter.com/rXkm5FWkU0— Adam Detrick (@akdetrick) February 18, 2016

brianmeetup — Thu, 18 Feb 2016 19:43:34 -0500

hackathon progress pic.twitter.com/rXkm5FWkU0
— Adam Detrick (@akdetrick) February 18, 2016

Sorting Out Japanese

jakemeetup — Fri, 23 Oct 2015 11:11:05 -0400

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).

This issue came up unexpectedly, but taught us a good lesson about not making any assumptions when dealing with language. If you want to develop a global product, you have to deal with your product in a global way, and that means building things that make sense in ALL languages.

Meetup and Slack

meetupjeff — Tue, 29 Sep 2015 18:47:48 -0400

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

Jeff is a Senior QA Engineer at Meetup

Apple In-App Purchase Mock Service (Fake it ‘till you make it)

confoundead — Thu, 27 Aug 2015 11:48:01 -0400

A configurable sandbox to test auto-renewing Apple IAP subscriptions

TLDR; We made a thing that pretends to be an Apple In-App Purchase service to make it easier for people to test their code. It’s open sourced and can be found here: https://github.com/meetup/apple-of-my-iap

The long story:

As part of Meetup’s iOS offering, we recently launched the ability for our members to use Apple In-App purchases (IAP) when buying Meetup subscriptions.

Implementing this feature was a lot of fun. The same kind of fun as running through a gauntlet full of sharp axes, hot flames, and killer piranhas.

But before we get into that….

What exactly is an Apple In-App Purchase, and more importantly why do I care? (Hint: It’s not Apple Pay)

An Apple In-App Purchase (IAP) is a purchase of digital goods or services through Apple’s native payment processing platform available on all iOS devices. If you’re an iOS user and you’ve ever been prompted by this screen:

then chances are you’ve made an In-App Purchase before. Typical use cases of include:

unlocking premium features within an application
purchasing extra levels or items from within a game
purchasing a subscription to digital content

Since a customer’s payment information is already stored in their iTunes account, they have the ability to make quick and painless payments without having to pull out their wallet and re-enter credit card number information. One tap and they’re done. This also means that you don’t have to spend time designing, building, and maintaining finicky payment forms.

And if that’s not enough incentive for you, Apple will kick you out of the iTunes store for attempting to sell digital goods/services in any other manner other than through IAP.

Sounds like a deal to me.

Meetup meets IAP

Here at Meetup, we elected to use the auto-renewing feature of Apple IAP, which means that Apple will automagically take care of all the nonsense that comes with scheduling and charging subscription payments. Hooray!

All we have to do is ask Apple who paid for what, and then ensure that we are delivering the right service and products to the right people. Since the Meetup platform exists on the web as well as on both iOS and Android, we delegate subscription management to the server in order to ensure a uniform experience across all 3 platforms.

So for any given member with a Meetup subscription bought through IAP, we query Apple’s iTunes endpoint and receive a response similar to this:

{
   "status": 0,
   "environment": “Sandbox”,
   "receipt": {
       "receiptType": “ProductionSandbox”,
       "adamId": 0,
       "appItemId": 0,
       "bundleId": “com.meetup.iphone”,
       "applicationVersion": “409000”,
       "downloadId": 0,
       "versionExternalIdentifier": 0,
       "requestDate": “2015-04-23 23:33:34 Etc/GMT”,
       "requestDateMs": “1429832014510”,
       "requestDatePst": “2015-04-23 16:33:34 America/Los_Angeles”,
       "originalPurchaseDate": “2013-08-01 07:00:00 Etc/GMT”,
       "originalPurchaseDateMs": “1375340400000”,
       "originalPurchaseDatePst": “2013-08-01 00:00:00 America/Los_Angeles”,
       "originalApplicationVersion": “1.0”,
       "inApp": [
           {
               "quantity": “1”,
               "productId": “com.meetup.iphone.test.7days”,
               "transactionId": “1000000151887289”,
               "originalTransactionId": “1000000151887289”,
               "purchaseDate": “2015-04-15 21:46:04 Etc/GMT”,
               "purchaseDateMs": “1429134364000”,
               "purchaseDatePst": “2015-04-15 14:46:04 America/Los_Angeles”,
               "originalPurchaseDate": “2015-04-15 21:46:06 Etc/GMT”,
               "originalPurchaseDateMs": “1429134366000”,
               "originalPurchaseDatePst": “2015-04-15 14:46:06 America/Los_Angeles”,
               "expiresDate": “2015-04-15 21:49:04 Etc/GMT”,
               "expiresDateMs": “1429134544000”,
               "expiresDatePst": “2015-04-15 14:49:04 America/Los_Angeles”,
               "webOrderLineItemId": “1000000029487694”,
               "isTrialPeriod": “false”
           },
           {
               "quantity": “1”,
               "productId": “com.meetup.iphone.test.7days”,
               "transactionId": “1000000151887546”,
               "originalTransactionId": “1000000151887289”,
               "purchaseDate": “2015-04-15 21:49:04 Etc/GMT”,
               "purchaseDateMs": “1429134544000”,
               "purchaseDatePst": “2015-04-15 14:49:04 America/Los_Angeles”,
               "originalPurchaseDate": “2015-04-15 21:48:06 Etc/GMT”,
               "originalPurchaseDateMs": “1429134486000”,
               "originalPurchaseDatePst": “2015-04-15 14:48:06 America/Los_Angeles”,
               "expiresDate": “2015-04-15 21:52:04 Etc/GMT”,
               "expiresDateMs": “1429134724000”,
               "expiresDatePst": “2015-04-15 14:52:04 America/Los_Angeles”,
               "webOrderLineItemId": “1000000029487695”,
               "isTrialPeriod": “false”
           }
       ]
   },
   "latestReceiptInfo": [
       {
           "quantity": “1”,
           "productId": “com.meetup.iphone.test.7days”,
           "transactionId": “1000000151887289”,
           "originalTransactionId": “1000000151887289”,
           "purchaseDate": “2015-04-15 21:46:04 Etc/GMT”,
           "purchaseDateMs": “1429134364000”,
           "purchaseDatePst": “2015-04-15 14:46:04 America/Los_Angeles”,
           "originalPurchaseDate": “2015-04-15 21:46:06 Etc/GMT”,
           "originalPurchaseDateMs": “1429134366000”,
           "originalPurchaseDatePst": “2015-04-15 14:46:06 America/Los_Angeles”,
           "expiresDate": “2015-04-15 21:49:04 Etc/GMT”,
           "expiresDateMs": “1429134544000”,
           "expiresDatePst": “2015-04-15 14:49:04 America/Los_Angeles”,
           "webOrderLineItemId": “1000000029487694”,
           "isTrialPeriod": “false”
       },
       {
           "quantity": “1”,
           "productId": “com.meetup.iphone.test.7days”,
           "transactionId": “1000000151887546”,
           "originalTransactionId": “1000000151887289”,
           "purchaseDate": “2015-04-15 21:49:04 Etc/GMT”,
           "purchaseDateMs": “1429134544000”,
           "purchaseDatePst": “2015-04-15 14:49:04 America/Los_Angeles”,
           "originalPurchaseDate": “2015-04-15 21:48:06 Etc/GMT”,
           "originalPurchaseDateMs": “1429134486000”,
           "originalPurchaseDatePst": “2015-04-15 14:48:06 America/Los_Angeles”,
           "expiresDate": “2015-04-15 21:52:04 Etc/GMT”,
           "expiresDateMs": “1429134724000”,
           "expiresDatePst": “2015-04-15 14:52:04 America/Los_Angeles”,
           "webOrderLineItemId": “1000000029487695”,
           "isTrialPeriod": “false”
       }
   ],
   "latestReceipt": “MIJA5AYJKoZIhvcNAQcCoIJA1TCCQNECAQEx …”
}

The Problem: Testing with IAP

Apple provides an iTunes sandbox environment which can be used to test In-App Purchases without spending real money. For auto-renewing subscriptions, the sandbox environment allows you to create a subscription which then automatically renew itself six times before expiring. Since many subscriptions periods last one week at the very least, Apple provides shorter test durations for the sandbox environment which are mapped to production durations in the following manner:

Production -> Sandbox

1 week -> 3 minutes

1 month -> 5 minutes

2 months -> 10 minutes

3 months -> 15 minutes

6 months -> 30 minutes

1 year -> 1 hour

However, there were some serious limitations with the iTunes sandbox which made it difficult to develop and test for, especially for non-iOS engineers like myself.

You need to have an iOS device with IAP functionality already built into your app in order to simulate an IAP purchase. This would require our iOS engineers to try and build IAP functionality into the app before any backend support for it existed.
It’s impossible to manipulate test subscriptions once they have been created in the sandbox. Testing edge cases such as refunds, cancellations, early renewals, late renewals, etc. are only doable by writing mock subscription creation cases within the iOS app. This would require our iOS engineers to spend extra time creating tooling around a feature that they couldn’t yet test.
The shortest amount of time it takes for a subscription to expire is 18 minutes, which is particularly irritating when you’re trying to debug expiration logic in your application.

Points #1 and #2 would have created heavy inter-team dependencies between our iOS engineers and our backend engineers, something which would have slowed down development immensely.

Point #3 is just annoying.

Unable to get what we wanted from Apple’s iTunes sandbox environment, we decided to roll our own mock service which simulates IAP subscriptions. Our requirements were pretty straightforward. We wanted a service that:

would mimic responses we’d receive from the iTunes store
was isolated from our codebase and behave as a 3rd party service
could simulate IAP transactions without an iOS device
could simulate different IAP subscriptions states (refunded, cancelled, etc.)

So we built it!

The end result is a service that any of our engineers could spin up at a moment’s notice, create mock subscriptions, test weird edge cases, and then shut it all down with a few keystrokes.

If you’re interested in trying out our service, simply grab the code from our github repo: https://github.com/meetup/apple-of-my-iap and take it for a spin!

All future support tickets to be written in iambic pentameter

adrianparsons — Wed, 05 Aug 2015 10:00:10 -0400

Senior Machine Learning Engineer Evan Estola recently filed a support ticket… in iambic pentameter. Our systems team promptly upgraded his workstation.

It is in the nature of my job here, that my poor dev box is frequently down,
overloaded as it were by process - whom by their own nature and not of fault,
are very intensive of memory.

I enjoy engaging primarily - in the habit of a linux machine, and because I
sometimes do rely on (e.g. data which I need to spy on) complex data
visualizations, a racked machine would be less than ideal.

Therefore the idyllic setup for me (and lo I know that this demand be bold, and
understand if it unlikely be); a workstation under my desk as now,
but with 64G of memory.

Python 2.x and Unicode: A Story of Love and (almost) Murder

anne-meetup — Thu, 30 Jul 2015 10:00:13 -0400

by Anne DeCusatis, Core Engineer on Meetup’s International/Partnerships team

I love working with Unicode. It’s fascinating how we’ve designed complex ways to represent something as simple and fundamental as characters. It also allows us to support the incredible diversity in languages of computer users. It appeals to my engineering brain as an interesting problem and to my more emotional side, since having Unicode support helps people express themselves on our platform.

Recently, I worked on a bug that attempted to change my warm-and-fuzzy Unicode feelings.

At Meetup Engineering, we use a Python script to push our code into review. This script integrates with both Github Enterprise and Bugzilla. Recently, one of our engineers added support to this script to pull the bug title and description from Bugzilla into the Python script. The title and description can then be approved or edited by the developer and sent to Github. This was a great improvement, since copy/pasting the bug description every time was tedious and multi-line descriptions weren’t handled well when pasting.

What’s the problem here?

I’ll give you a hint: Python 2.x has a surprisingly lengthy page in its documentation describing how Unicode string/byte string conversions work. I found it to be a fun read, the first time! The tenth time, not so much.

Specifically, our problem was:

Non-ASCII Unicode characters in Bugzilla titles and descriptions were (1) not displaying properly in the terminal and (2) throwing a UnicodeDecodeError when we tried to dump them into a JSON string to send in an HTTP request to Github Enterprise.

This seemed pretty simple to me, since I knew that Python’s json.dumps has a parameter you can pass in to create a Unicode string instead of a byte string, so I agreed to take this bug on. “Python is fun, and Unicode is interesting,” I thought. “This will probably take about an hour, at most, and then everyone will give me credit for having improved our dev process immeasurably, and I will ride a wave of admiration into the sunset.”

After a day or two of messing with it, frustrated with Unicode, Python, and myself, I worked on other projects until I was again feeling up to the challenge. This brings us to the present day.

The solution

A non-Unicode tip I learned working on this: there are diminishing returns after 6pm on a Friday. Go home and look at it Monday morning – it’s likely you’ll get the same amount of progress as continuing to work several more hours.

I digress. There were two parts to the problem: the incorrect display of characters, and the UnicodeDecodeError when sending them out.

The incorrect display of characters was caused because, as I found, the byte string from our MySQL Bugzilla database was not in the format expected of a byte string by Python. To explain this, let’s go into a little detail about strings in Python, and about how a computer stores characters.

Python 2.x stores two kinds of strings: Unicode strings and byte strings. Byte strings are meant to hold ASCII characters, which always take up one byte, and can be coerced into holding other Unicode characters. Python reads and displays byte strings one byte at a time. This is bad for displaying Unicode because Unicode characters may take up more than one byte per character. Unicode strings, on the other hand, are more suitable for printing Unicode characters, since Python knows that one byte of a Unicode string might not be one character. The conversion between these types of strings is supposed to be relatively seamless. I found that the character I was testing with, » (RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK), was represented in the byte string that came from our Bugzilla database as “\xbb”, whereas a new string created with » would be encoded as “\xc2\xbb”. This meant that I would see a question mark block (�, the computer-universal symbol for “I don’t know what this character is”) when printing the string instead of a right guillemet.

To solve this, I took a round trip. Character by character, I called unichr(ord( c )).encode(“utf-8”). In Python, ord() returns the value of a character, and unichr() returns the character from a value. Since I wanted to print a Unicode string, I also called .decode(“utf-8”) on it. My code eventually looked like this:

#A workaround for 47510
def bugz_unicode(bugz_output_string):
    return u"".join([process_char(c) for c in bugz_output_string])

def process_char(c):
   return unichr(ord(c)).encode("utf-8").decode("utf-8")

What can I say? It does the job.

Great, now I can dump a JSON string, right? Well, not exactly. It turns out, urllib2 (with which we were sending the HTTP request to our Github Enterprise instance) only takes byte strings, and I just went through a lot of work to ensure I had a Unicode string.

This was solved by calling .encode(”utf-8″) again, once I figured out that was what I needed to do…

One more note: I could only test this when my working directory was clean of changes, because the script prevents you from pushing to git if you haven’t committed yet. This led to some fun commit logs:

Eventually, though, it got merged, and is now launched and propagating its way to all the other developers’ environments.

Note that there were, in the end, 45 commits, but only 20 lines changed. In other words: I wrote over twice as many lines about the problem as I did to fix the problem.

In conclusion…

1. Python 2.x + Unicode = CAUTION

2. We use Jython, so we’ll likely be on Python 2.x for a while.

3. I still love Unicode, and I still love Python. But I no longer feel that they could be two great tastes that taste great together.

via https://twitter.com/honest_update/status/625659846285627392