The official Grindr blog.
News and more from Team Grindr.
Midterm elections are right around the corner on November 4 – and we here at Grindr were curious to see how users felt about the current state of politics. We surveyed more than 2,400 of our Grindr guys asking them about Obama, Hillary and who they thought was the sexiest President in U.S. history (we couldn’t resist). So, what did our users have to say? Let’s take a dive.
It’s no secret that Barack Obama has done more for the LGBT community than any other President in U.S. history and 66% of Grindr users have voted for him. However, 54% said they would not vote for him again if he was able to run for a hypothetical third term. Yikes, looks like Obama is losing his approval rating among Grindr guys.
But you know whose approval rating is through the roof? Hillary Clinton. If Hillary runs for President in 2016 (now that’s something we’d like to see), 53% of Grindr users said they would vote for her. In fact, a majority - 58% - would vote for Hillary Clinton if she was to hypothetically run against Barack Obama for President. And 23% said they wouldn’t vote for either (those were probably the Republicans. Yes, there are Republicans on Grindr).
Enough about the politicians, let’s see what Grindr users think of how is America doing.
65% of respondents feel that America is better off now than in 2008, and half said the weak economy is the biggest issue facing the U.S. today. The economy beat out other concerns such as healthcare, minority rights or an Ebola outbreak.
When asked who was the hottest U.S. President, Grindr users overwhelmingly (64%) chose John F. Kennedy as the president of their dreams. Barack Obama followed in second place with a notably lower 15%. We can’t blame them, JFK was a hottie, but we’ve all looked at that shirtless pic of Barack on the beach … and we were impressed.
So in a nutshell, our election poll tells us that Obama’s scorecard is waning, America is still concerned about the economy and Grindr users are backing Hillary in a major way.
In response to recent security allegations surrounding location data, Grindr is taking proactive measures to keep users safe in territories with a history of violence against the gay community. Any user who connects to Grindr is these countries will have their distance hidden automatically by default, which include Russia, Egypt, Saudi Arabia, Nigeria, Liberia, Sudan and Zimbabwe. There are many more countries already being protected by this location change, and we will continue to add more to this list.
This change means that any user within these countries will not show distance on their profile (e.g. 1 mile away). Your location will not be able to be determined via trilateration or any other method, keeping your position private and secure. This change will not have any other effects on the Grindr experience as a whole: guys nearby will still populate in the correct order, with the first guy in the cascade being the closest to you.
Users that are not located in countries with anti-gay legislation will be able to see distance in profiles, as we believe geo-location technology is the best way to help guys meet up simply and efficiently. However, should you wish to hide your location data, simply open the side menu, tap ‘Settings’, then ‘Privacy’ and turn ‘Show Distance’ off.
There is nothing that matters to us more than the safety and security of our user and the Grindr community. We will continue to find ways to keep our users private, especially in countries with anti-gay legislation.
Stay tuned for continued enhancements and new features in our upcoming app updates.
There have been recent reports that Grindr has an alleged security flaw and we wanted to clarify the matter with you all. There is nothing that matters more to us than our users and protecting the Grindr community is a core priority. As part of the Grindr service, users rely on sharing location information with other users as a core function of the application. We are always focused on doing what we’ve set out to do from the beginning: help guys meet other guys. Grindr’s geolocation technology is the best way for users to meet up simply and efficiently. As such, we do not view this as a security flaw.
For Grindr users concerned about showing their proximity, we make it very easy for them to remove this option and we encourage them to disable ‘show distance’ in their privacy settings. If a user wishes to turn off his distance setting, all he needs to do is toggle the show distance option in Settings. The app will still work, however other users won’t be able to see exactly how far they are.
We are continuously updating our platform to increase security across our networks and we do our best to keep our Grindr community secure. Stay tuned for continued enhancements and new features in our upcoming app updates.
MobileBeat, an annual conference hosted by VentureBeat held it’s sixth conference this year. This influential, who’s who in mobile, conference focuses on emerging mobile markets, trends and products.
This year, the conference uncovered new case studies, insights, and strategies designed to help app founders and mobile providers leverage mobile to increase profitability for their companies.The primary question during the Conference was "How do I grow my users, and how do I engage with them better once I have them?"
Grindr's Matthew Norris spoke regarding the app's use of location data to re-engage with users by helping them connect better to the community, and ensure that the content delivered as a result of location based campaigns are relevant, rich and rewarding. This technology, coupled with friendly user-interface in Grindr's app, is one of the reasons why users keep on using and relying on Grindr in their daily activities with their smartphones.
Tech Talk - iOS Development with Test Driven Development, Unit Testing, and Monitoring Code Metrics (Part 1 of 3)
Welcome to the Grindr Tech Talk series. In case you missed our last meet up, Lukas Sliwka, Grindr's VP of Engineering, discussed architecture strategies being employed to ensure high availability and scalability of the Grindr 8 million+ user platform.
This month, Lukas and the Grindr iOS Team will be focusing on: Implementing Test Driven Development, Unit Testing and code metrics when building mobile iOS applications.
What you will learn:
1) How to implement Unit Testing in Xcode using IOC Container - iOS Development Team will be going into code level giving an overview of dependency injection mechanism facilitated by Typhoon container. In addition, they will do a code walk through unit tests employing the IOC mechanism.
2) How to cleanly manage dependencies in Xcode - iOS Development Team will showcase and discuss the usage and configuration of CocoaPods dependency management framework.
3) How to setup Continuous Integration environment enforcing Xcode code quality metrics - Release Management team will discuss and present Grindr’s Xcode Jenkins build pipeline with its continuous integration and code quality metrics.
About the Presenter:
Grindr’s VP of Engineering, Lukas Sliwka is a thirty-something technologist who's lived and worked in many different places around the world including Europe, Canada, and both coasts of the US. Lukas has a background in software engineering, agile methodologies, and agile transformation. He loves the disruptive nature of technology and seeks any opportunity to change the status quo. He recently joined Grindr to further its geo-social mobile platform and how it impacts the dating world. Lukas has also held key roles at Beachbody, Yamaha, and Mazda.
**** WE ARE HIRING ****
Interested in working for one of the most innovative mobile app companies on the planet? Check out http://www.grindr.com/jobs and contact: email@example.com
====== VIDEO TRANSCRIPT BELOW ==================
[0:08] Joel >> I’m Joel Simkhai, I’m the CEO, founder of Grindr. So I want to welcome you guys to our talk tonight. Before I introduce Lukas, I just want to give you a little bit of a background on Grindr. We’ve just celebrated five years a few months ago and we’ve started here in Los Angeles.
[0:28] Joel >> Actually I was telling someone over in my living room for about two years and now we’ve been here in this office for about a year now; a little less than that, and we’re global. We have about 5 million; over, actually, over 5 million monthly users who go on at least once a month and on a daily basis we have about a million and a half who use the service every day. Concurrent, we’re about three hundred thousand, two hundred and fifty thousand users who on at any given minute so a lot of traffic, a lot of usage, a lot of guys grinding, and this is global, so this is not just here in the US, this is literally any country you could name, we’ve got users there. And, this is, you know, it has to mean to you the power of the service. Helping guys meet other guys seems to be very popular and we love to do that for them.
[1:30] Joel >> And the other kind of interesting fact is that we’re self funded, so we have two versions of the app. We have a free version, and a subscription service. The free version is ad supported and the subscription service is a monthly fee and so between those two revenue streams we support the business here and you know, so we’ve never actually taken any outside capital. And something else we’re very, very proud of is that we’re committed to just creating great products and just doing a great thing for our users and for the team here and not really worrying about investors and spending time on pitches and all these other things. We’re focused on creating great products. So with that quick background, I’d love to introduce Lukas Sliwka who is our VP of Engineering and the Head of Tech.
[2:25] Lukas >> And I broke the microphone. Ok perfect. Welcome everybody. Today we’re going to take a deeper dive into iOS development, Xcode specifically. We’re going to focus on a couple of areas that are very important to me. I joined Grindr six months ago. Grindr experienced explosive growth as a company, and with that growth came a lot of development in terms of backend systems, the frontend clients. And when you’re in that mode when you’re growing so fast, a lot of times, you’re kind of throwing things together to keep up with other men, right? And it shows. It shows on our backend systems, it shows on our frontend clients.
[3:17] Lukas >> The first talk I did about two months ago, I talked about scalability, and so, during that talk I talked about what it actually takes to support millions and millions of users, and that’s not an easy thing. Today we’re going to focus primarily on iOS side of things, and how you can actually employ some of the strategies to best develop for your iOS clients.
[3:44] Lukas >> So before we go on, I want to introduce a couple of people who are going to be helping me along with this conversation. So, I’d to introduce John King who is our iOS developer and part of our iOS development team and also Rudi Hacopian who is our QA automation architect.
[4:06] Lukas >> Before I go forward, I want to, kind of set the stage in terms of, you know, a lot of startups, a lot of applications being built, you have maybe one guy, two guys, working on in a backroom, throwing things together, right? That’s all great as long as you know frontend and backend and all the ins and outs of scaling your application. There is a big difference between handling a hundred users versus ten thousand users versus a hundred thousand users and the scale goes on. I mean, as your organization grows, you need to have certain specialties, right? However, when you look at startups, you need to stay agile to help people who are kind of jacks of all trades but at the same time they are masters of few areas. So when you’re trying to set up a very successful startup or a company, a mid-sized company that is very lean, you can do a lot with 15-20 people as long as these people are very passionate about technology and you build a framework around them that allows them to innovate, fail fast, learn, rinse and repeat. So we’ll talk about some of that today.
**** WE ARE HIRING ****
Grindr.com is hiring for Senior Android Developers, iOS Developers and Principal Application Developers. If you are interested in our careers, check out http://www.grindr.com/jobs and email firstname.lastname@example.org
[5:25] Lukas >> So let’s start by discussing, you know, what we’re going to talk about today, so, specifically when it comes to iOS development, we’re going to talk about Test-driven Development (TDD), we’re going to talk about Inversion of Control. Another name of that is Dependency Injection. We specifically use Typhoon container for that. We’re also going to discuss Dependency Management powered by Cocoapods. We’ll talk about Burn, Build and Release Pipeline and we’ll talk about what makes a mature build and release pipeline for a mature organization. I will like to set a low-context why I want to talk about these things, alright? When you’re a company and you’re a startup, you want to have an environment that enables innovation. My job here is to essentially build and engineer an organization that promotes rapid change and rewards experimentation and that’s not an easy thing. As a developer, and if I could get a head count – how many developers in the room, people who actually write code? So most of you. So you know what I’m talking about; how difficult it to be in organization that has production applications already supporting revenue and that’s locked in and at the same time you’re trying to deliver all new projects and at the same time technology is moving so fast, you want to experiment with different technologies, possibly apply new things to improve things. It’s a constant battle between having a stable production environment that generates revenue, have a development engineering environment where you can innovate and you can agree with the product because product development also wants to deliver features so it’s a constant collaboration and a constant negotiation between those different forces.
[7:37] Lukas >> So what I want to talk about today is what it means to have a strong engineering practice. When I started with Grindr six months ago, my main charter was to build a strong engineering practice, and what I mean by that is, build a mature engineering practice that essentially enables people and allows people to experiment, allows teams to experiment and possibly fail fast, learn without affecting revenue, without affecting these core business applications that are already running.
[8:17] Lukas >> Joel mentioned that we are a mature business, that we’re making money. We have a lot of users in over 190 countries around the world. We’re processing massive traffic. Obviously, we’re not Facebook, we’re not Yahoo or whatever, but you know, we deal with close to 200-500 messages per second when it comes to chat. We talk about traffic like 250,000 RPMs to 500,000 RPMs. We have days when we reach one million RPMs. Those are not easy things to withstand. When you’re designing your backend systems and also frontend clients then there will soon be a lot of thought put in on how you orchestrate things. When it comes to the setting up of a strong engineering practice, however, there are a couple of different components that are a part of that and a lot of the stuff we’re going to talk about today are the different building blocks of the overall picture. I just want to give you a context of why we’re doing it.
[9:30] Lukas >> Why are we doing TDD, or why are we using IOC container or why are we writing Unit Tests? It’s not because it’s something cool and someone else is doing it. They’re doing it but there’s a purpose behind it and the purpose is to have that strong engineering practice. A strong engineering practice is composed of three components, which are, processes, technology and people. I kind of touched already on people and who we hire, who we want to be part of our team. Our engineering team is very small, we have right now, probably fifteen to twenty people that are making this whole thing happen. They are divided into various different functional areas so we have standard dev ups, NOC type of practice, we have QA practice, we have architecture practice, we have android, iOS development, we have backend practice. All these kinds of practices have to come together in some way to create a product. We use agile and scrum for that. I don’t believe that any sort of modern software development should be using anything different. I think that waterfall is dead. I am not afraid to say that. A lot of companies are claiming that they’re agile and scrum. In my opinion, if you have a status meeting in the morning that you call ‘standup’, that doesn’t make you an agile organization. There’s much more to that, there’s going to be a separate tech talk on that where I’m going to take a deeper dive. But there are also other things, like Lean and Test-driven Development and there’s KISS, which is, ‘keep it simple, stupid’ or YAGNI, which is, ‘you’re not gonna need it’ or metrics. It all comes down to the fact that we want to move very fast, we want to have a process in place that kind of sets a cadence to day-to-day development but, as an engineering organization, we also have architectural principles in place that are being governed and watched for in terms of how we build software.
[11:42] Lukas >> In terms of technology, I am in a certain business, right? So I am enabling the gay community to meet as fast as possible. I’m not in the identity management business, I’m not in the business of building databases, I’m not in the business of other engineering aspects that are very cool for engineers to play with, however, that’s not my core business. So it’s very easy as an engineer to get caught up in the rabbit holes where – “oh you know what, I’m going to build my own stuff, right, because it’s cool.” That’s not how we do things here. If we’re looking at the overall ecosystem of the Grindr application as a whole, I want to channel the development effort into areas that haven’t been done before and maybe there are no appliances or frameworks on the market to do them. I want to make sure that I apply open source technologies, I buy whatever I need to buy, and I integrate to build a strong solid platform that enables my team to do things that haven’t been done before. I don’t want to be in a business building cool geospatial algorithms because there are plenty of companies that specialize in that. The databases that have open source algorithms integrated inside them like Mongodb uses Google geospatial search. I want to leverage that. I don’t want to build that from scratch.
[13:13] Lukas >> When I joined Grindr, I looked at the overall ecosystem. There’s a lot of things that we’re fixing because, over the years, because we’re moving so fast, it was easier to build things from scratch as opposed to maybe take a step backward, look at our architecture and design things differently, so this year what we’re doing is we’re redesigning backend and we’re completely revamping our system, the overall platform as well as building clients.
[13:50] Lukas >> When it comes to clients, it’s kind of the same thing, right? When I look at Xcode and iOS development, iOS development just recently, last year, introduced the version 7 which brought, finally, unit testing tools and the ability to do things that haven’t been around for a very long time. It’s amazing to me, a lot of times when I talk to iOS developers - I don’t want to offend anybody - how special iOS and Xcode development is, when I tell you that you’re not special and the reason why you’re not special is because software engineering has been around for a very long time, and the concepts that have been introduced into your ecosystem have been around for a very long time, and there is a reason for that. The reason for that is because for a very long time we’ve done object oriented programming and we’ve solved things through frameworks and microframeworks, and patterns and those things should be applied. Xcode and iOS development is not different from Java or any other type of language, so what I want to stress is that things that we’re going to be talking about today are maybe new things that were introduced quite recently into the iOS development ecosystem, but they have a very strong foundation in computer science and the backing of at least 10 to 15, 20 years of object oriented development.
[15:25] Lukas >> So, when I talk about frameworks, containers, automation, that’s something that we use here to essentially provide these tools, provide the technology, and the frameworks and the process to allow our teams to experiment, learn, fail fast and do it better the next time. We work in one week sprint cycles so that means that within five days, you need to complete your development, you need to confront your definition of done which means that regression testing needs to be done. You need to have a certain level of quality. You cannot achieve that without automation and a certain level of maturity as an engineering shop.
[16:10] Lukas >> So, let’s talk about – before we take the deeper dive, I wanted to throw some definitions out there for people who have not done before. Test Driven development, have no doubts with dependency management, don’t know what the inversion of control is. Essentially, those are tools in our toolbag that we can apply to make our development faster, better more robust and at the end of the day we allow people to experiment with different framework, different technologies, different approaches, without worrying if we’re going to put something in production and that’s going to bring me down and my revenue is going to stop. I want to have a process in place as an engineering shop where I enable you guys to experiment, but in order to do that I need some of these tools.
[17:05] Lukas >> I’m not going to go through that, you guys can look it up on wiki. What I do want to do before we go into the code dive, is I want to take a brief moment to talk about inversion of control and testing.
[17:23] Lukas >> So I set up essentially a very simple scenario, where I have a Class, ‘Grindr’, that uses Grindr service and normally, if you don’t have any serve containers around that stuff you would just say, you know, I would instantiate my new Grindr class and if I’m referencing this Grindr service, I would have to have either in my constructor or right here, some sort of way that I’m instantiating this class or I can do it within my business logic so it’s populated.
[17:54] Lukas >> When it comes to Inversion of Control, it’s essentially a container that allows you to outsource, for the lack of a better word, the business of creation and wiring classes together. If I have two classes like this, my IOC container is essentially a way for me to create this class through that container without me worrying about how that’s done. Why it’s important, well if I’m doing test driven development, I want to have very atomic tests that are just testing this particular component, which means I will have to, most likely, mock this service and mock the responses of that service in order to have a valid test. Very high level, I’m not going to talk about more than that. I want to hand it off to John, who’s going to actually look at some code, show you how it’s done in Xcode, starting with Dependency Management using Cocoapods.
[19:36] John >> Hey everybody. Luke was kind enough to introduce me, I’m John King. I am an iOS developer here at Grindr. Who here has not heard any of these concepts before tonight?
[19:48] John >> Fair enough. Alright, so the first thing I want to talk about is Cocoapods. Oh! You can see what I’m talking about, huh?
[20:02] John >> Awesome. So Cocoapods is what we use for dependency management for our Grindr project. Cocoapods is in itself simply a Ruby gem we installed through terminal which will keep a reference to all the various key repositories that are managed by Cocoapods and gives us a really easy way to put them into our project.
[20:23] John >> To simply install it, we open our terminal and we gem-install Cocoapods just like you would in any Ruby gem. Simple enough and if we go into Xcode we can look at the key part of a Cocoapod. So this is called a pod file. A pod file is how we tell Cocoapods what dependencies we need for our project. This can be opened up as any simple text file and that’s exactly what this is. That’s a text file with some glorified Ruby in it.
[20:54] John >> Let’s go ahead and break this down for a bit. So you can see we have a couple different build targets, if you’re familiar with Xcode, that our entire workspace we build, for each target we tell them what particular pods we need in order to build this project for the winter. A pod is just a Cocoapod term for a framework that we use within this project.
[21:19] John >> So you see we have four various targets, they use all very similar things. Next to them you see a version number. This is an optional version number. If you omit the version number it will always install the latest version. At any time you can run a different command called a ‘pod update’ and it will take every dependency you’re using and automatically update.
[21:40] John >> We don’t have to worry about - oh has an update come out yet, have we received an email about it, is it up for release? Let’s go check and see if we have the latest versions for everything that we’re using.
[21:48] John >> We simply use a pod update. For certain reasons we have frozen every particular pod we’re using. We’re telling them this is the version we want to use. Always go and get this version. Cocoapods uses a file called a pod spec to give it all this information about how it might build in with your project. For 90% of new developers this is something you’ll never have to work on unless you’re building a pod for someone else to use. Pod specs are there, you need to know they exist. This pod file is the more important thing. There is a particular command that you see here. Looks like a tilde arrow. We can actually do something like this if we so desired and this would give us the latest men version of that file or of that pod, forgive me. So let’s say I’m using Yama framework and they have a new – I’m sorry, go ahead…
[22:46] Audience >> [Inaudible]
[22:48] John >> Oh yeah, I’m sorry. [typing] That’ll work.
[23:10] John >> Alright, how’s that guys?
[22:11] Audience >> [Laughter]
[23:12] John >> Apple says this is a good presentation size, it’s good enough for me. [Laughs] Alright, so, sorry, should have said something sooner guys.
[23:23] John >> So you see we have a tilde arrow here, we replace this with just our comma so instead of using the version we’ve given it, it’ll use the latest men version which is the second number here available to us. So let’s say Yama framework as you see here are – we currently use 0.2 of it. Let’s say they have a new 1.0 release of it but there’s also an 0.3, 0.1.0, it will give us the latest second number that is available without moving to the next incremental. This is useful if we want to keep using a similar version that we have but we are weary of using the latest and greatest in case there are any bugs, in case it doesn’t play right with our archives for any reason. It’s a handy little tool if you’re using your little pod file.
**** WE ARE HIRING ****
Grindr.com is hiring for Senior Android Developers, iOS Developers and Principal Application Developers. If you are interested in our careers, check out http://www.grindr.com/jobs and email email@example.com
[24:16] John >> So, this is the second most important part of the pod file for me. So we got a post install hook and this is our chance to write and review code and do some things to help with integration with any of these pods for example, we have a number of Xcode schemes that have their own particular settings to help us build and maintain the project and often times just doing a pod install - very basic - will not transfer these settings over to that, does not play nice. As I said earlier, a lot of what we need in order to make these libraries build properly with us is in that pod spec file that Cocoapods uses.