Making Meetup

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

Our engineers have been doing a lot of i18n...

jakemeetup — Mon, 20 Jul 2015 15:13:47 -0400

Our engineers have been doing a lot of i18n (internationalization) work to make Meetup more friendly around the globe!

This past spring, we launched changes to how our pages are indexed by search engines. You can now access Meetup from links which correspond to different languages - for instance:

(you must be logged out, otherwise the page is rendered according to the language in your account settings)

In April we changed our sitemap to surface these URLs to search engines. Now, Meetup will be presented in search results in users’ local languages. Not only are people registering more often this way, they are getting a better, more native experience!

Steps Towards Automated Testing with Docker and Jenkins

jrodbeta — Tue, 30 Jun 2015 18:56:03 -0400

blog post written by Jose Rodriguez,
Product Engineering Lead at Meetup

Going from Play-Doh to Legos

We’re making an effort to clean up our core codebase. Most of Meetup’s architecture has been monolithic for a long time with a lot of our core code shared in the same scope of a singular webapp. We established no rules or boundaries for how our codebase should interface with other parts. Like a ball of mixed Play-Doh, our code can be hard to identify with no separation of concern. Pieces call other pieces in ad-hoc fashion, resulting in tightly coupled code that is both difficult to test and difficult to maintain.

Instead, we want our code to be like Legos. We want to build small identifiable components with defined interfaces of interaction. With the implementation of code reviews and some good luck in hiring talented engineers, Meetup’s code quality has improved over the past few years. Now we’re interested in enforcing constraints to keep our codebase modular, decoupled, and testable.

Meetup is older than most people realize. Just a few weeks ago we turned 13. While it’s exciting that we’ve lasted this long, it also means we’ve accumulated a lot of code over the years. The truth is that most of our code isn’t tested in an automated way. Much of it isn’t even testable. We have sustained this long by investing in a manual testing strategy. If we took a holistic view of Meetup’s testing coverage it might look something like this:

We know what a healthy testing population looks like and we’re far from it. Last year we took the first step by transitioning from a giant source tree, all in the same scope, to a hierarchy of modules. We even have goals set around the long term vision of those modules. The transition was a success and now we’re ready for the next step, to bring automated unit testing to Meetup with the help of Docker and Jenkins.

What have we learned from the past?

We’ve tried something similar before. Our systems team recognized the importance of testing and attempted to setup a continuous testing infrastructure. So why didn’t it work?

Tests depended on external services like MySQL, Redis, or Memcached.
We skipped any form of unit testing and went straight for integration. An isolated environment was required but our implementation was not reproducible. Since we use a shared development model at Meetup, two engineers running the test suite would end up in state conflict if run at the same time.
Engineers weren’t familiar with our continuous testing infrastructure.
There was only one instance of Jenkins running. With no alternative to poke and prod, engineers were hesitant to learn more about it. Engineers are curious, but less so when it may mean downing a running service.
An absence of gatekeeping for test regressions.
If an engineer broke an existing test no one was informed until after that code was merged to master. Bugs were created to fix broken tests but by the time it had been addressed, the tests were no longer salvageable or relevant.

Answering these problems with Docker and Jenkins

In the ladder to automated testing, the first step is unit tests. Integration tests are useful but harder to do. Unit testing is fast and easy. It gives us a solid foundation to start influencing design and prevent regressions. Once we have a solid unit testing foundation, then we can start moving towards higher forms of automated testing.

We need an automated testing setup that is reliable, reproducible and which prevents future regressions and breakage. In evaluating alternatives, we found that Jenkins with Docker would meet this criteria. Around this time we were introduced to the approaches that eBay had been trying with containerizing Jenkins slaves. You can find more about it here: http://www.ebaytechblog.com/2014/05/12/delivering-ebays-ci-solution-with-apache-mesos-part-ii/

We started with their second approach of mounting a slave container’s Docker sock inside of itself. The slave now has access to run other containers without the overhead of Docker in Docker.

Reliable builds regardless of environment

When introducing new infrastructure, reliability influences adoption. If the thing is a piece of junk, no one will want to back it. We needed a method to reproduce builds over and over from scratch with no environmental side effects. By running builds and tests inside of a container, we have detailed control over these side effects. Docker gives us confidence in these environments and an easy interface for working with them.

Creating a reproducible CI environment

To increase adoption with the continuous integration (CI) tooling, we wanted the tools and environment to be reproducible. The singular Jenkins instance didn’t work for us in the past. Our engineers should be able to reproduce the same configuration in their own environment, just like any production service.

We took eBay’s approach a step further by turning the Jenkins master into a container as well. We have a base Docker image with shared plugins and Jenkins version. We then extend the base image with detailed configurations for a particular Jenkins master. Now engineers can reproduce any configuration we have available.

In this reproducible environment, we wanted as much decoupling as possible. Configurations should have as little environment specific details as possible. We also wanted to create slave instances without needing configuration changes on the master. Jenkins Swarm allowed us to make starting a new slave as easy as starting a Docker container. (https://wiki.jenkins-ci.org/display/JENKINS/Swarm+Plugin) If we want another Jenkins slave, we just run the slave container pointed at the master. The slave will use JNLP and Jenkins Swarm to register itself.

The final result allows us to reproduce any CI setup or configuration in just a few Docker commands.

Preventing future breakage

Keeping engineers informed of breakage is good, but we also need to prevent it from entering our master branch. At Meetup, we’ve adopted GitHub flow with our core codebase using GitHub Enterprise. One of the features of GitHub we actively use are the Pull Requests (PR) to review code before it’s submitted for release. GitHub also comes with a feature to flag commits with statuses. In this case, we can use Jenkins’ GitHub Pull Request Builder Plugin to build PRs and their updates. (https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin)

Test breakage is now reported to both the submitting and reviewing engineers. A failing commit will alert the PR submitter, and the failed state of the PR alerts the reviewer that a problem exists.

Conclusion and what’s next?

We now have a reliable mechanism for determining failure. Engineers do not have to worry about false negatives due to infrastructure failure. Anyone interested in updating our infrastructure can test changes in their own CI setup. And finally, we have gates in place to prevent test breakage from going unnoticed.

Our next step is to create more isolation in pursuit of testable integration. We’re excited about the capabilities Docker offers us here. We’re hoping that the steps we’ve taken for unit testing will help influence our code design and move us towards a more testable future.

adrianparsons:For the most recent internal hackathon at Meetup,...

adrianparsons — Mon, 02 Feb 2015 11:21:43 -0500

adrianparsons:

For the most recent internal hackathon at Meetup, Evan Estola and I built a Party Mode toggle switch. Obviously, the switch turns Party Mode on and off. Party mode activates an animated CSS disco ball on meetup.com and on partymode.club.
Built with:
Mason jar (we live in Brooklyn, okay?)
Spark Core
USB charger
Toggle switch (from the hardware store across the street)

Tech stands up for the little guy at Seattle Interactive Conference

duncanmeetup — Thu, 06 Nov 2014 00:30:16 -0500

Earlier this month I was fortunate enough to attend the Seattle Interactive Conference, a two-day event “celebrating the convergence of online technology, creativity, and emerging trends in one of the world’s most creative cities.” Traditionally known as home base for two of the world’s tech giants, Seattle now plays host to a multitude of successful online startups, many of whom were represented at this year’s event. I learned a number of concepts I’m excited to bring back to NYC, but one thing I found particularly exhilarating is how tech continues to find new ways to empower those in need of agency or representation, which is something close to our hearts here at Meetup.

The first session I attended at the conference, a talk by Crowd Companies founder Jeremiah Owyang on how new companies are increasingly turning to crowd-based platforms as a basis for their business models, highlighted plenty of instances of the trend. Uber and Airbnb were mentioned (as they were in almost every session of the conference, at one point a speaker asked how many people in the room had taken an Uber to the conference that day and at least half the room indicated they had). But Owyang also highlighted plenty of little-guy-empowering startups that haven’t broken into billion-dollar-valuation visibility. LeftoverSwap helps connect people with extra prepared food with those looking for a bite to eat, helping reduce food waste and making locally-available food more affordable. Boatbound takes the concept of vehicle- and ride-sharing and moves it offshore. Helparound connects diabetics, so that if someone finds they are stuck without a glucose meter or other supplies, they can send a call for help to anyone in the area who might be able to provide them help in a pinch. Here at Meetup, we’re also doing what we can to build the communities of food swappers, boat sharers, and diabetes support.

Janelle Maiocco, CEO of Farmstr also hosted a fantastic session about the work Farmstr does to connect small farmers to sell directly to local produce buyers. This benefits farmers by eliminating a lot of guesswork farmers normally need to do in terms of how to bring to market, and saves them a lot of time because they are delivering to a specific place at a specific time instead of spending all day at market. She also spoke on the unfortunate statistic that only 5% of tech startups are founded by women. Local food and female entrepreneurship are two more topics that we here at Meetup hope to support and help build communities around.

As a side note, one other session at the conference had a bit less to do with tech supporting the little guy, but resonated with me as a Meetup employee nonetheless. It was given by Briar Waterman, the Director of Digital Creative at Starbucks. He touched on the company’s Meet Me At Starbucks, a campaign that sends filmmakers to Starbucks locations around the world to film interactions between communities meeting within, then publishes the footage. One such highlighted community was a Meetup Group, The Long Beach Scrapbooking and Digital Photo Group.

The videos serve to support Starbucks’ assertion that “good things happen when we get together.” Which, to me, sounds just a tad bit familiar.

A big thanks to all the organizers, speakers, and participants at Seattle Interactive for an educational, eye-opening, and supremely enjoyable two days.

Duncan is a QA Engineer at Meetup who thinks the Pacific Northwest is the Pacific Northbest

Meetup Hacks: Introducing Meetloaf!

krafte2 — Fri, 12 Sep 2014 00:30:00 -0400

Each quarter, Meetup holds a two-day internal hackathon. Engineers work on hacks ranging from launchable features, to internal tools, to the downright ridiculous. Meetup Hacks is a new feature focusing on these projects.

Caroline is a Core Software Engineer who recently graduated from Tufts University. When she’s not hacking, she listens to last.fm while working on Meetup notifications.

Being new on the job and wanting to contribute with something practical, I was all set to build something that might actually get pushed to production. I spent the week before the hackathon tossing around a lot of ideas, mostly relating to a big project I’m about to start.

Then, as I was sitting at my desk blasting some tunes and hunkering down on a tough bug, an incredibly random idea for a project came to me: what if I allowed our members to hook up to their last.fm accounts?

I’m the kind of person who loves data, and loves music, so when it comes to a combination of those two things, I swoon, just a little. I put feelers out into our dev hipchat channel to see if there were any other last.fm users around so that I could possibly justify doing this hack, but I only got two responses. Turns out, most people ditched last.fm a few years ago.

But, the more I talked to my friends about it, the more I wanted to do it. It’d be something fun and I’d get to learn about the authentication process.

And come, on what’s better than music?

Answer: nothing.

When we got around to presenting our ideas at the hackathon kickoff, it turned out that two of our Data Team engineers (Brian and Evan) had a similar idea. But, they wanted to use the Facebook “Like” data that we have from some of our members to generate a concept of the music taste profile for a group. At that point, I was pretty set on last.fm, so we decided to get together at the end of day 1 and see what we could do about combining our projects.

The Hack

So, then it was time for me to dig into the last.fm api. I explored a little bit and implemented calls to a few of the artist specific methods just to get comfortable before diving into user auth.

While the api is great on the whole, the one thing that might be frustrating to some developers is that they’ve developed their own authentication system. It’s incredibly similar to OAuth, but not enough so that I could use the framework that Meetup already has for linking to OAuth services like LinkedIn and Facebook. Some would groan, but I know next to nothing about authentication protocols, so I took this as an opportunity to get familiar with them.

There are a few different ways to authenticate with last.fm, but I chose the desktop application route so that I wouldn’t have to allow last.fm to make calls to our development environment. From there, it’s a relatively simple process: you get a token from last.fm, have the user request authorization using that token, and then you can fetch a session (and corresponding key) with last.fm. The somewhat difficult part comes from deciding how to store intermediary data (like the token) and how to proceed through all the stages I mentioned.

Because this was a hackathon, I took the hacky way out, and passed the token through the whole process, and kept track of the user’s state by monitoring the window I had opened for them to authenticate with last.fm (so that I would know when to trigger a request for a session key). Kids, don’t try this in production.

Despite all the hackiness, I got to learn something: for the first time, I got to play with our internal Ajax method library in the process to make the links between what was happening in the browser and storing the account tie in the DB.

Once I had authentication, I could actually start doing fun things with user data. As per Murphy’s law, the api call I was hoping to use was deprecated, and ended doing a bunch of fun set operations to develop a playlist for a meetup group based of the last.fm stylings of anyone authenticated in that group. Everything was fine and dandy, until I realized that I only had two Meetup HQers authenticated, and didn’t have enough data to make good playlists.

Luckily, Brian and Evan, who were working on the facebook side of things, let me dig into some of what they had built and I got to embark on the process of using the echonest api to convert between facebook’s identifier and musicbrainz ids, which is what last.fm uses. So, after all this work, anyone authenticated with last.fm could click a button to create a last.fm playlist for any group they were in.

Combining Forces

Finally, I got together with Brian and Evan to set up the beautiful integration of our projects. They had pulled all the facebook info and associated pairs of meetup groups and music artists with a numeric score. I supplied them with a way to look up the music taste for a member (since last.fm is more detailed than facebook on a per member basis), and Evan adjusted his beautiful group recommendation algorithm to recommend meetup groups to a member based on their music preferences. While the recommended groups were not ones that I might be interested in, it definitely knew me. I got recommended a couple Meetups in Urbana, Illinois (thanks, Elsinore), and though I was unaware that my music taste so heavily reflected my gender, I was recommended a lot of female focused groups.

While I was right in my assessment that this is not going to make it into production, I had a great time, got to know some other MEME teamers a little bit better, and most importantly, I now have a playlist on last.fm reflecting our collective music taste.

Special thanks to the guys for coming up with the ultimate name for the ultimate project: Meetloaf.