At Stripe, weβve always been intentional about how we communicate, share information, and stay connected. Back when Stripe was smaller, it was easy for this to happen automatically. But by the time we hit around 150 people, it became hard to know everyoneβs name. So at a company hackathon, a few Stripes created People, a directory to help Stripes meet and get to really know each other.
People focused on connecting individuals across the company: Stripes could set their own bios, create networks around common interests, and generally experiment with new ways to express who they are. People also gave us our first concept of a people API, which set the stage for automating our notification systems and made it quick to roll out new people-oriented features (like seating charts!).
Weβve since turned People turned into a full-fledged product called Home, weaving both how we know one another and share information beyond email into the same product. Used by 99% of Stripes in the last month, Home is the source of truth for who we are, what weβre doing, and whyβand a platform for enabling individuals and helping them get to know one another.
Hereβs a quick tour through a few Home highlights:
People worldwide
The people at Stripe are what bring and keep so many of us here, so weβve made it easy to meet folks across the company. In the spirit of the original People, new Stripes are front and center on Home along with their own quick video introductions, a flipbook through existing Stripes (can you get their name right?), and activities happening around the company (ranging from classes we host to events for our users).
Home was also designed to encourage Stripes to get to know each person beyond their team and the projects theyβre working on. Weβve found that building connections across the company makes it easier for us to share, learn from fresh perspectives and build a sense of belonging early on. Everyone has their own personal page that describes how to get ahold of them for work, where they work, and any quick background theyβd like to share.
Home canβt paint the complete picture of the person behind the page, but it helps break the ice. Outside Home, we encourage people to meet in personβone of our more structured approaches involves a chat bot that helps schedule lunches among Stripes who are least likely to know each other (more than 5,000 lunches have been facilitated since it was set up!).
Multiple teams, one company
We donβt view teams as information silos or hard boundaries. Instead, weβve designed teams to empower a group of individuals to take end-to-end ownership over an area and act autonomously toward their goals, while sharing lessons with the rest of Stripe. Helping teams share their knowledge to the company makes it easier for individuals at Stripe to find context that will both guide them in their work and help them learn above and beyond their role.
But with dozens of teams at Stripe, itβs tough to keep track of every area. To help, we built the team index as a central place to find any team at Stripe. Home randomly features teams and the individuals within them at the top to help keep Stripes aware. Individual team pages are like the people pages: they provide a common interface for getting ahold of the team, finding useful resources the team has shared, and even watching video introductions for the entire group at once. (We now have ten offices globally and built similar pages for those at a recent hackathon.)
Knowledge sharing
Individual Stripes collaborateβa lot. Last year we created more than 20,000 documents, ranging from email drafts to project proposals to canonical documentation relied on across the entire company.
Our search system lets Stripe look across documents, people, teams, and even API models, with live filters to help narrow the corpus quickly. The search interface is completely API-driven with modular content indexers underneath, so itβs easy to add new types of content to the same interface we use to find everything else. (API models were a recent addition.)
We still have a lot to do along these lines. Search satisfies the curious who know roughly what theyβre looking for. Next up, weβd like to incorporate our canonical documentation into a structure that not only helps people browse and keep up with changes, but also helps Stripes find information they wouldnβt go hunting for on their own that would nevertheless benefit them (like lessons from another teamβs retrospective).
Under the hood, Home is built on the same technology as our user-facing products (such as the Dashboard) because we wanted to make it easy to move between developing user-facing and internally-facing products. This has made Home a favorite for new Stripesβ spin-up projects and a popular go-to for Hackathon projects. The search feature described was built by a new class of Stripes as their very first project and office pages were built at our most recent hackathon.
Home is such an important part of how we work together and stay connected; it remains a work in progress along with Stripe as a whole. Weβre still figuring out how to balance transparency with information overload, serendipity with curated content, and crisp interfaces and team boundaries with the actual human part that makes the company what it is. Our next projects are all about evolving knowledge discovery: from team pages that weave the individuals, metrics, and our users together to a better way to browse and publish information.
Interested in working on Home? Join Stripe. View Openings
On July 15, 2014, I decided to delete my Facebook account. The social media behemoth had gone too far in using all our personal data for profit, psychological research, and crowd manipulation. I was done.
I wanted to take back what was mine and leave the platform, which meant downloading all of my data. But I was surprised to find that when I clicked the βDownloadβ button on the settings page, all I got back was a copy of my profile page.
As a computer programmer, I knew that Facebook keeps usersβ pictures, private conversations, lists of friends, likes, shares, locations, technical data about usersβ devices, and much more, and stores it all in their data warehouses around the world. The vast majority of my personal data was missing. I took it anyway, and deleted my account.
A lot has changed since then, including how much you can take with you when you leave Facebook β though Facebook keeps that data and a lot more they still donβt let you download when you leave. With the revelations of the Cambridge Analytica scandal and the media circus thatβs ensued in its subsequent fallout, many people outside the developer community have become aware of the scope of Facebookβs data collection practices.
Iβm sure there was a time when feudal serfdom and colonial rule seemed βtoo big to quitβ as well.β
Our personal data is β to put it simply β used to create highly detailed Facebook advertising profiles. The company releases some information to law enforcement or academic researchers on an ad hoc basis, but keeps the bulk of the data for Facebook and Facebook only. Of course, unscrupulous firms like Cambridge Analytica are also able to access some usersβ personal data by finding exploits in Facebookβs policies.
Long before the internet became an everyday tool for everyone in the developed world, minimalist sculptor Richard Serra suggested thatΒ if you arenβt paying for the product, you are the product. This is very obviously true in the case of Facebook, which collects data not to be creepy, but because it is profitable to do so. (Creepiness is just a byproduct.) In 2016, the company generated about $43 per user in the United States and Canada alone, and over $4 billion worldwide.
The biggest problem with Facebook is not the newsfeed, the algorithms or even the ads. Itβs that Facebook considers its usersβ accounts as part of the companyβs private assets. Our data is acquired en masse, collected, and assembled in order to be monetized without regard for the interests of the people and communities from whom this data is harvested.
The public is starting to see the data practices of large tech companies for what they are: invasive, dehumanizing, and corrosive to the public conversations and civic institutions that form the bedrock of our social and political lives.
When the Cambridge Analytica news broke, major media organizations like The New York Times published a string of fatalistic pieces warning users that Facebook may have become βtoo big to quit.β Facebook controls so much of our online experiences, in one way or another, the argument goes, that attempting to leave the social media platform can prove catastrophic. (Iβm sure there was a time when feudal serfdom and colonial rule seemed βtoo big to quitβ as well.)
There is a kernel of truth to these kinds of warnings. Facebook exercises outsize control over our online behavior. Weβve become so accustomed to seeing βSign in with Facebookβ on registration forms and login screens that it barely registers an impression. And many people donβt realize Facebook directly owns platforms like Instagram or WhatsApp, which means those user accounts belong to Facebook, too. These seemingly innocuous interfaces have an insidious way of restricting our freedom in cyberspace. Thatβs the price of convenience, but for many of us that price has become too high.
The total number of active users on Facebook today is as large as the total number of people on the internet in 2011: 2.1 billion users. In other words, as many people as there were on the entire planet during World War II. Today, Facebook and Google refer over 70 percent of all web traffic, which is justΒ one wayΒ they can collect usersβ data.
Opt-in to Facebook and you give up important rights to have a say in how your personal data is used; opt-out of Facebook and potentially isolate yourself from your friends, family, professional opportunities and more. Since Facebook opened its gates to the public in 2008, billions of people have chosen the former. The network effect of all of these individual choices means, for many who would like to opt out today, the opportunity costs are simply too great.
If we can choose which medium to use when sharing our data, we can be active on a digital social network and independent from the privatized internet.β
We have a word for relationships you canβt afford to leave: coercion. Far too many people today are on Facebook not because they choose to be there, but because the company has consciously and deliberately created a platform that forces them to stay. As Margaret Thatcher used to say, βThere is no alternative.β
Except there is.
A year ago I joined a group of programmers who are building a new type of social network, called Secure Scuttlebutt. Itβs not a startup or even a nonprofit β itβs just open-source software that allows users to be in touch with their friends.
What makes Scuttlebutt unique is the simple idea that users should own and control all of their data. My Scuttlebutt account is not kept behind a login gate. Itβs just stored locally on my computer, like any other file.
Because users own all of the files that make up Scuttlebutt, they can store their data anywhere. For example, I have 800 MB worth of data β thatβs small enough to fit on a microSD card. This represents two years of status updates, friendsβ status updates, contact information, photos, and what have you. As soon as I put the card into my phone, Scuttlebutt automatically updates and syncs with the new posts that my friends or I make. The user always owns their data β they can take it out and literally hold it in their hand β but this data is also dynamically linked in to the social network.
Letβs make our virtual selves as free as our physical selves.
One way we can do this is to embrace peer-to-peer protocols across the Internet. Scuttlebutt excels at this β your app talks to your friendβs app and asks for the latest. This is how it updates across the social network.
Because your data is always with you, Scuttlebutt allows you to share it in different ways. For instance, through a shared wifi network, you can transfer the latest news between two computers that are physically near one another. In the future, we will also enable Bluetooth transfer. This means itβs a social network that uses the internet, but it is not dependent on the internet.
If we continue to keep data locked up in cloud accounts, there is no future for the web. On the other hand, if we can choose which medium to use when sharing our data, we can be active on a digital social network and independent from the privatized internet. Letβs make a home for each digital being.
Setting up your own Scuttlebutt account is easy. Take a look at the video below, or visit their website for instructions on getting started.
This week will make it 20 years since I was one of the lucky ones to ring the opening bell for the American Stock Exchange. It was spring of 1998 and our company Sonic Foundry would officially begin trading that day.
Sonic Foundry Prospectus fromΒ 1998.
The IPO market had been hot in 1997 but it was getting tougher and we knew our window was probably closing. It was a Saturday in New York City and Rimas, Sonic Foundryβs CEO, and I were on our way to meet with Ray Dirks, head of a small firm we hoped would help take us public. When we walked in no one was there but Ray in a large empty office with row upon row of desks. It was like something out of a Wall Street movie. I clearly remember Rimas, my best friend and recent MBA graduate, turning to me and saying βI smell moneyβ. I was thinking something along the lines of βare you sure you arenβt confusing emptiness and despair with money?β It turned out that Rimas had a pretty accurate nose and in a matter of months we would be doing our IPO.
No one told me I had to give aΒ speech.
I was required to give some words before the opening bell. I remember trying to be inspiring but realizing half way through that not a single person on the trading floor gave a crap about what I had to say. They just wanted to get to work.
It was great fun. I rang the bell, the market opened, and then we toured the trading floor and watched our symbol SFO appear on the electronic ticker for the first time (we would become SOFO when we later switched to the NASDAQ). We were whisked off to a celebratory lunch and then spent the afternoon in Manhattan continually checking the stock price. There was great joy (and relief) when we actually closed above the opening price.
My co-founder Curtis J Palmer and I with some sweet phones on the trading floor. (My skin tone and slight puffiness would never suggest that I was a coder from Wisconsin)
It had taken us 7 years to get to this day, but it was only a little over 3 years since we had taken our first friends and family investment changing the direction of our company forever. The first 4 years we scraped by through savings, VISA cards, and sales from Sound Forge. Once we decided to take outside investment priorities changed. It suddenly wasnβt just about making the best product we could. It was now about revenue and growth and doing things we thought would make investors happy. It sometimes meant sacrificing long term results for short term gains and making decisions you may have done differently without that added requirement.
I donβt regret going public or our crazy ride during the internet bubble. After all we were able to create many products still in use today, Sound Forge, CD Architect, Acid, Vegas, Mediasite just to name a few. The list of companies and products created by XSOFOβers is an impressive one. I spent 20 years working with extremely intelligent people building incredible products and making life-long friendships.
But I can tell you that the time I look back on most fondly is 1994. It was the year that Curt left Microsoft to drive across the country to join me in Madison, Wisconsin. The two of us hired a young engineer right out of university, John Feith, and the 3 of us spent all of 1994 writing Sound Forge 3.0. It would be the break out version for us and Macromedia would show up at the end of the year looking to buy us out. We spent that year working night and day, surviving on Glass Nickel pizza, in a mostly empty concrete walled building, with Curt blasting us with Tool and Pearl Jam. We didnβt worry about recurring revenue, or quarterly results. We just wrote code and that made us happy because we knew we were creating something people would love.
So next time youβre at a meetup and someone dumps on you for your βlifestyle businessβ I want you to think of this Kurt Vonnegut quote
βI urge you to please notice when you are happy, and exclaim or murmur or think at some point, βIf this isnβt nice, I donβt know what is.β
Because for me both 1998 and 1994 certainly were nice.
Now researchers in Singapore say they have trained one to perform another task known to confound humans: figuring out how to assemble furniture from Ikea.
A team from Nanyang Technological University programmed a robot to create and execute a plan to piece together most of Ikeaβs $25 solid-pine Stefan chair on its own, calling on a medley of human skills to do so. The researchers explained their work in a study published on Wednesday in the journal Science Robotics.
βIf you think about it, it requires perception, it requires you to plan a motion, it requires control between the robot and the environment, it requires transporting an object with two arms simultaneously,β said Dr. Quang-Cuong Pham, an assistant professor of engineering at the university and one of the paperβs authors. βBecause this task requires so many interesting skills for robots, we felt that it could be a good project to push our capabilities to the limit.β
He and his Nanyang colleagues who worked on the study, Francisco SuΓ‘rez-Ruiz and Xian Zhou, arenβt alone.
In recent years, a handful of others have set out to teach robots to assemble Ikea furniture, a task that can mimic the manipulations robots can or may someday perform on factory floors and that involves a brand many know all too well.
βItβs something that almost everybody is familiar with and almost everybody hates doing,β said Ross A. Knepper, an assistant professor of computer science at Cornell University, whose research focuses on human-robot interaction.
In 2013, Mr. Knepper was part of a team at the Massachusetts Institute of Technology that presented a paper on its work in the area, describing the βIkeaBotβ the team created, which could assemble the companyβs Lack table on its own.
But chairs, with backs, stretchers and other parts, pose a more complex challenge; hence the interest of the Nanyang researchers.
Their robot was made of custom software, a three-dimensional camera, two robotic arms, grippers and force detectors. The team chose only off-the-shelf tools, in order to mirror human biology.
βHumans have the same hardware to do many different things,β Dr. Pham said. βSo this is kind of the genericity that we wanted to mimic.β
Also like humans, the robot had a little help to start: It was fed a kind of manual, a set of ordered instructions on how the pieces fit together. After that, though, it was on its own.
The robot proceeded in three broad phases, spread out over 20 minutes 19 seconds.
First, like humans, it took some time to stare at the pieces scattered before it.
The robot spent a few seconds photographing the scene and matching each part to the one modeled in its βmanual.β
Then, over more than 11 minutes, the robot devised a plan that would allow it to quickly assemble the chair without its arms knocking into each other or into the various parts.
Finally, it put the plan in motion over the course of nearly nine minutes. The robot used grippers to pick up the wooden pins from a tray and force sensors at its βwristsβ to detect when the pins, searching in a spiral pattern, finally slid into their holes. Working in unison, the arms then pressed the sides of the chair frame together.
Of course, the robot didnβt succeed right away. There were several failed attempts along the way and researchers tweaked the system before the robot was finally able to assemble the chair on its own.
The accomplishment was the culmination of three years of work, but the team is eager to see what else it can automate, Dr. Pham said.
With the help of experts in artificial intelligence, the researchers may be able to create a robot that can build a chair by following spoken directions or by watching someone else do it first, he said. Or maybe, he said, theyβll eventually develop one that assembles furniture in a way that is truly human: by ignoring the manual altogether.
Niraj Chokshi is a general assignment reporter based in New York. Before joining The Times in 2016, he covered state governments for The Washington Post. He has also worked at The Atlantic, National Journal and The Recorder, in San Francisco. @nirajc
A version of this article appears in print on , on Page B8 of the New York edition with the headline: Robot Cures Human Headache: Putting Together Ikea Furniture. Order Reprints | Todayβs Paper | Subscribe
βThere is a mountain of demand and a trickle of supply,β said Chris Nicholson, the chief executive and founder of Skymind, a start-up working on A.I.
That raises significant issues for universities and governments. They also need A.I. expertise, both to teach the next generation of researchers and to put these technologies into practice in everything from the military to drug discovery. But they could never match the salaries being paid in the private sector.
In 2015, Elon Musk, the chief executive of the electric-car maker Tesla, and other well-known figures in the tech industry created OpenAI and moved it into offices just north of Silicon Valley in San Francisco. They recruited several researchers with experience at Google and Facebook, two of the companies leading an industrywide push into artificial intelligence.
In addition to salaries and signing bonuses, the internet giants typically compensate employees with sizable stock options β something that OpenAI does not do. But it has a recruiting message that appeals to idealists: It will share much of its work with the outside world, and it will consciously avoid creating technology that could be a danger to people.
βI turned down offers for multiple times the dollar amount I accepted at OpenAI,β Mr. Sutskever said. βOthers did the same.β He said he expected salaries at OpenAI to increase as the organization pursued its βmission of ensuring powerful A.I. benefits all of humanity.β
OpenAI spent about $11 million in its first year, with more than $7 million going to salaries and other employee benefits. It employed 52 people in 2016.
PhotoAn old video game used for training an autonomous system at OpenAI, a nonprofit lab in San Francisco.Credit
Christie Hemm Klok for The New York Times
People who work at major tech companies or have entertained job offers from them have told The New York Times that A.I. specialists with little or no industry experience can make between $300,000 and $500,000 a year in salary and stock. Top names can receive compensation packages that extend into the millions.
βThe amount of money was borderline crazy,β Wojciech Zaremba, a researcher who joined OpenAI after internships at Google and Facebook, told Wired. While he would not reveal exact numbers, Mr. Zaremba said big tech companies were offering him two or three times what he believed his real market value was.
At DeepMind, a London A.I. lab now owned by Google, costs for 400 employees totaled $138 million in 2016, according to the companyβs annual financial filings in Britain. That translates to $345,000 per employee, including researchers and other staff.
Researchers like Mr. Sutskever specialize in what are called neural networks, complex algorithms that learn tasks by analyzing vast amounts of data. They are used in everything from digital assistants in smartphones to self-driving cars.
Some researchers may command higher pay because their names carry weight across the A.I. community and they can help recruit other researchers.
βWhen you hire a star, you are not just hiring a star,β Mr. Nicholson of the start-up Skymind said. βYou are hiring everyone they attract. And you are paying for all the publicity they will attract.β
Other researchers at OpenAI, including Greg Brockman, who leads the lab alongside Mr. Sutskever, did not receive such high salaries during the labβs first year.
In 2016, according to the tax forms, Mr. Brockman, who had served as chief technology officer at the financial technology start-up Stripe, made $175,000. As one of the founders of the organization, however, he most likely took a salary below market value. Two other researchers with more experience in the field β though still very young β made between $275,000 and $300,000 in salary alone in 2016, according to the forms.
Though the pool of available A.I. researchers is growing, it is not growing fast enough. βIf anything, demand for that talent is growing faster than the supply of new researchers, because A.I. is moving from early adopters to wider use,β Mr. Nicholson said.
That means it can be hard for companies to hold on to their talent. Last year, after only 11 months at OpenAI, Mr. Goodfellow returned to Google. Mr. Abbeel and two other researchers left the lab to create a robotics start-up, Embodied Intelligence. (Mr. Abbeel has since signed back on as a part-time adviser to OpenAI.) And another researcher, Andrej Karpathy, left to become the head of A.I. at Tesla, which is also building autonomous driving technology.
In essence, Mr. Musk was poaching his own talent. Since then, he has stepped down from the OpenAI board, with the lab saying this would allow him to βeliminate a potential future conflict.β
A top-tier Android phone can cost upwards of a thousand dollars, and for that money, youβll get some amazing features. It will have a stellar screen, top-flight camera, gobs of storage, and an absolutely atrocious texting experience.
Itβs a problem. In fact, itβs always been a problem. Google has spent nearly a decade trying β and failing β to fix it with an ever-rotating cast of poorly supported apps. While iPhone users have had the simplicity of iMessage built in, Android users have been left to fend for themselves.
Now, the company is doing something different. Instead of bringing a better app to the table, itβs trying to change the rules of the texting game, on a global scale. Google has been quietly corralling every major cellphone carrier on the planet into adopting technology to replace SMS. Itβs going to be called βChat,β and itβs based on a standard called the βUniversal Profile for Rich Communication Services.β SMS is the default that everybody has to fall back to, and so Googleβs goal is to make that default texting experience on an Android phone as good as other modern messaging apps.
As part of that effort, Google says itβs βpausingβ work on its most recent entry into the messaging space, Allo. Itβs the sort of βpauseβ that involves transferring almost the entire team off the project and putting all its resources into another app, Android Messages.
Google wonβt build the iMessage clone that Android fans have clamored for, but it seems to have cajoled the carriers into doing it for them. In order to have some kind of victory in messaging, Google first had to admit defeat.
What Chat will be
Chat is not a new texting app. Instead, think of it more like a new set of features inside the app already installed on most Android phones. βChatβ is the consumer-friendly name for Rich Communication Services (RCS), the new standard thatβs meant to supplant SMS, and it will automatically be turned on inside Android Messages, the OSβs default app for texting.
When people begin using Chat, theyβll get many features that are standard in any other texting app, including read receipts, typing indicators, full-resolution images and video, and group texts.
But remember, Chat is a carrier-based service, not a Google service. Itβs just βChat,β not βGoogle Chat.β In a sign of its strategic importance to Google, the company has spearheaded development on the new standard, so that every carrierβs Chat services will be interoperable. But, like SMS, Chat wonβt be end-to-end encrypted, and it will follow the same legal intercept standards. In other words: it wonβt be as secure as iMessage or Signal.
The new Chat services will be turned on for most people in the near future, though timing will be dictated by each carrier. Google is optimistic many carriers will flip the switch this year, but there could be some stragglers. Chat messages will be sent with your data plan instead of your SMS plan, so youβll likely only be charged for whatever (minimal) data it costs to send a message. Though, again, it will be up to the carriers.
If you are texting somebody who doesnβt have Chat enabled or is not an Android user, your messages will revert back to SMS β much in the same way that an iMessage does. Nobody outside of Apple knows when (or if) the iPhone will support Chat.
Instead of continuing to push Allo β or creating yet another new chat app β Google is instead going to introduce new features into the default Android Messages app, like GIF search and Google Assistant. Android Messages will be the default on many (but not all) Android phones. Samsung phones will also support Chat using Samsungβs app. You will still be able to download Googleβs app if youβd prefer to use it, though it seems unlikely that third-party developers will be able to create full RCS-enabled apps.
Reboot again
Google has put a new executive in charge of the effort: Anil Sabharwal. He led the team that created the Google Photos apps, which are perhaps the most successful Google apps of the past few years. Theyβre also a great example of how Google salvaged ideas originally built into Google+ and turned them into a great set of cross-platform apps.
So it makes perfect sense that CEO Sundar Pichai tasked Sabharwal with fixing one of the oldest and most vexing problems at Google. Sabharwal has to find a way to make the default texting experience on Android not just good, but part of a dominant global network that can actually compete with the likes of WhatsApp, Facebook Messenger, and iMessage. And he needs to do it without alienating any of the hundreds of powerful companies that have a stake in the smartphone market.
βIβm coming into this as a consumer product person,β Sabharwal says. Six months ago, he took over the communications team and took inventory of Googleβs offerings and strategies. As a result of Googleβs βtry everythingβ approach to messaging, the company currently has four major competing messaging apps: Hangouts, Allo, Duo, and Android Messages.
Letβs go through them one by one. Hangouts is becoming an enterprise app to compete with Slack, called βHangouts Chatβ instead of being a consumer focused app. That transition is taking awhile and at some point, Google will need to clear up its messaging for consumers that are still using Hangouts for personal texting. Right now, the companyβs guidance is that βthe consumer version of Hangouts will be upgraded to Hangouts Chat ... but our focus for Hangouts still rests on enterprise/team communication and messaging.β I wouldnβt be surprised if a free version was made available to consumers someday, but, as with Allo, if might be time to start looking for alternatives.
And Duo, Googleβs new-ish video chat app, is actually surprisingly successful; a quarter of Duo calls are to or from an iPhone. But itβs primarily a video chat app, which leaves Allo and Android Messages: two apps that, from a βconsumer productβ perspective, do essentially the same thing.
Android Messages has all the users. Even though Samsung phones donβt use Android Messages as the default SMS app, most of the other major manufacturers do (outside of China, anyway). That adds up to 100 million monthly active users, according to Sabharwal. βAt the end of the day β¦ the native SMS app is where users are,β he says. βTheyβre not interested in going to a different place to use SMS.β
People, even in 2018, tend to just use the default app. Though WhatsApp and Facebook Messenger each have over a billion installs, those users are still falling back to SMS when they have to. Itβs the universal, default option; every phone supports it, and it always works. Sabharwal estimates that 8 trillion SMS-based messages are sent every year.
Allo, though itβs a perfectly capable and functional messaging app, has never managed to build a large user base. Sabharwal looked at Allo and saw βa clearly great set of product features, a great set of capabilities.β He looked at Android Messages and saw βa product that has tremendous momentum.β
So the move was obvious: shift all that effort from Allo, which doesnβt have a clear path to getting more users, and put it into migrating the appβs features into the default, Android Messages. βMy first thing is Iβm going to bring these things together,β Sabharwal says. βThatβs the first decision that weβve made.β
Put more bluntly: Google is giving up on having its own consumer messaging app, a heads-up competitor to Facebook Messenger. βThere are a lot of great messaging products and experiences that are out there,β says Sabharwal. βJust because Google may want to be one of them is not a reason for us to invest or build products. We fundamentally build products because we believe we can deliver better, improved user experiences.β
Take a step back. It seems ridiculous that a company as large and powerful as Google would simply give up on directly competing in the messaging space, but here we are. The question, then, is how on earth did we get here?
Allo the apps that didnβt work
Googleβs plan this time around is much more complicated than just launching a new messaging app. To get it started, it has had to corral more than 50 carriers and nearly a dozen manufacturers into adopting a new standard. It had to ensure that Chat would work the same, everywhere, and that it would actually have a decent set of features. Oh, and all those companies are fierce competitors who distrust each other and Google.
It is as close to the hardest, most winding road that I can imagine for fixing the messaging mess on Android. Itβs also probably one of the only roads Google had left to try.
Googleβs most prominent messaging dead end was Hangouts. Launched almost exactly five years ago, it was Googleβs most ambitious attempt to compete with iMessage, WhatsApp, and Facebook Messenger. It had a huge, splashy launch befitting its scope, and it successfully managed to merge a bunch of disparate Google apps into a single, unified system.
Hangouts was undone by Googleβs often schizophrenic corporate priorities and, frankly, sometimes institutional inability to execute on consumer products. It began as a product that was deeply enmeshed in Google+, Googleβs failed social network. Extricating Hangouts from that fiasco took years.
Hangouts also became an integration point for other services like SMS, a live video streaming service, Google Voice, and Project Fi. That sounds good in theory, but in practice, it meant the appβs overall purpose kept changing. One moment, it was an integrated SMS and chat app, and the next, it wasnβt. All the while, the thing began to feel slow and lumbering on phones, and too basic on desktops.
Instead of spinning Hangouts down (itβs honestly too enmeshed in Googleβs own internal work culture to do that), Google pivoted it. Hangouts is now an enterprise chat app designed to compete with Slack.
The next road Google took was more obvious: launch a new, mobile-first texting app and convince people to use it. That app was Allo, which launched two years ago.
Allo is a βfineβ app, with all the features youβd expect along with integration with Google Assistant, which launched alongside Allo. βThe strategy behind Allo was βletβs build a really great consumer messaging product really from the ground up,ββ Sabharwal says.
But in 2016 (to say nothing of 2018), simply making a good messaging app wasnβt enough β not when it has to compete with established giants. Allo also likely suffered from Google messaging app fatigue. People worried it wouldnβt be supported over the long term. (It turns out, they were right.)
If youβre going to launch a messaging app, you need a good strategy for achieving growth. iMessage worked because it was built right into the iPhone. WhatsApp worked because it was tied to phone numbers and let users avoid paying SMS fees. (And it had the benefit of being the first popular app to take advantage of push notifications.) Facebook Messenger worked because it was built on Facebook.
Allo had no such strategy for acquiring users. The closest Google came was a scheme using Googleβs own services on Android. When you sent an Allo message to somebody who didnβt have the app installed, theyβd receive a Google push notification instead of an SMS. The notification encouraged them to install the app (though they could reply directly without it).
Two years later, fewer than 50 million Android users have installed Allo. Considering that WhatsApp and Facebook Messenger both clock in at over a billion installs, those numbers just arenβt good enough. As Sabharwal gamely puts it, βThe product as a whole has not achieved the level of traction that weβd hoped for.β
That means that Google had to admit that the Allo experiment didnβt work. As a result, Sabharwal says that Google is βpausing investmentβ in Allo. That doesnβt mean that itβs shutting down; Sabharwal says that Google is βcontinuing to support the product.β But if youβre an Allo user, itβs definitely time to start looking elsewhere. My guess is that itβs a dead app walking (or, if you like, texting).
Thereβs one other option that I and many others have always hoped Google would have the courage to try: just copy iMessage, but for Android.
Though Google wonβt say so, I think that road is fundamentally too dangerous for the company. One would think that Google has more than enough leverage to simply create something that the carriers would have to accept whether they like it or not. What are Verizon and Deutsche Telecom and all the rest going to do, switch to Tizen in protest? Please.
But the truth is that these carriers have points of leverage over Google that go beyond choosing to sell Android phones. Android is, after all, open source. And though Google can (and does) dictate some requirements in order to include Google services, it canβt dictate them all. A carrier could set Bing as the default search, for example, or set up its own RCS client as the default texting app.
Perhaps Google could have gotten away with a proprietary, baked-in messaging protocol back in 2011 when iMessage launched. But in 2018, carriers arenβt fond of iMessage, and they arenβt going to take kindly to a similar service acting as the default, especially on Android, the globally dominant operating system. Even though it looks like they wonβt charge exorbitant SMS prices to consumers, RCS is still preferable to carriers as it will give them the opportunity to sell RCS services to businesses. The GSMA estimates that will be a $74 billion market by 2021.
In sum, Google tried damn near everything. Only two roads were left: one that would cause all its carrier partners to freak out and one that handed them the keys to a shiny new messaging platform they could call their own.
Sabharwal doesnβt paint the decision to partner with carriers in those terms, of course. Instead, he points to Googleβs penchant for keeping Android not just open, but neutral. Instead of the nuclear option, Google wants to keep the platform at least nominally neutral. βWe believe that thereβs a fundamentally better experience we can deliver to users,β Sabharwal says. He continues:
We canβt do it without these [carrier and OEM] partners. We donβt believe in taking the approach that Apple does. We are fundamentally an open ecosystem. We believe in working with partners. We believe in working with our OEMs to be able to deliver a great experience.
The rollout
SMS is awful. It started as a kind of a hack on top of preexisting cellular systems, and it never really developed much. The Multimedia Messaging Service add-on came later and was equally crappy. These services arenβt just antiquated; theyβre expensive. βNo one says βHey bud hit me up on MMS,ββ Sabharwal quips. They say βtext me.β And again, the default texting experience on Android is bad. This is a problem that needs fixing.
Since 2007, the fix was always supposed to be RCS, but RCS hasnβt taken hold for completely predictable reasons. Different carriers developed incompatible versions of the βstandard,β each trying to gain an edge. All the while, they were getting disrupted by tech companies who simply made over-the-top vertically integrated messaging products that just relied on data connections. Talk to nearly any analyst in the tech space, and youβll find theyβre dismissive that RCS could ever work. Hereβs Dean Bubley of Disruptive Analysis last year on RCS:
So ignore it. There are no customers, no use-cases, and no revenues associated with βadvanced messagingβ. Itβs the same pointless RCS zombie-tech Iβve been accurately predicting would fail for the last decade. Itβs still dead, still shambling around and still trying to eat your brain. Itβs managed to bite Google and Samsung, and theyβll probably try to infect you as well.
And yet, Google has spent the last couple of years trying to get consensus around something called the βUniversal Profile,β a standardized way to make RCS work across carriers. Googleβs pitch to carriers is simple: SMS is going to be replaced one way or another. You can either be part of the replacement or continue to watch Apple and Facebook run away with text messaging.
Google has also been lining up businesses that want to replace SMS for communicating with customers. Instead of a text message with a short link, you can have your boarding pass or Subway sandwich order or whatever appear right in your texting app. Right now, the best options for businesses that want rich messaging opportunities for customers are iMessage and Facebook β neither of which are as universal as SMS.
Carriers have slowly been coming on board. Two big holdouts, AT&T and Verizon, quietly agreed to support the standard in the past few months. Given how fractious the history has been here, Iβm sort of impressed that Google got everybody to call this feature βChatβ instead of βAT&T super premium advanced messaging plusβ or whatever. As of this writing, 55 carriers, 11 OEMs, and two operating system providers have all pledged to either adopt or switch over to the system.
The two operating system providers that have signed on to the Universal Profile: Google and, interestingly, Microsoft. That doesnβt necessarily mean that you can expect a native Chat app in Windows 10, but it does mean itβs possible. Microsoftβs statement on RCS is noncommittal at best: βRCS Universal Profile support for capabilities such as dialer and messaging functionality or other applications is considered on a device-by-device basis, where there is demand for those features.β
Unfortunately, we arenβt likely to get one big, splashy moment when Chat βjust works.β I press Sabharwal multiple times on this issue: when are carriers going to switch users over? βI donβt have a crystal ball,β he demurs. βI donβt know exactly how long itβs going to be, but we really feel that we are on the cusp of it right now.β Later, he relents and says, βLook, I can speculate, which I think is what youβre asking me to do.β
βBy the end of this year, weβll be in a really great state, and by mid-next year, weβll be in a place where a large percentage of users [will have] this experience.β Though, he cautions that βit will differ from country to countryβ and from region to region. Europe and Latin America are likely to enable it before US carriers. Still, he stresses, βThis is not a three- to five-year play. Our goal is to get this level of quality messaging to our users on Android within the next couple of years.β
In the United States, Sprint supports Chat right now between compatible Android phones. T-Mobile has promised to do so in Q2 of this year. When I asked for comment, neither Verizon nor AT&T would give me a timeline for when they intend to flip the switch to support Chat.
The middle period is going to be annoying. If your carrier or your device doesnβt support Chat, youβll get old-fashioned SMS and MMS messages β and vice versa. Importantly, that means that iPhone users wonβt be part of this ecosystem.
But I have a hunch that the pressure is on to get Apple to support Chat, not just from Google but from carriers and other businesses. Sources familiar with RCS say Google, along with multiple mobile operators, is in discussion with Apple about supporting RCS. Apple declined to comment.
Carrier control
If youβre still trying to wrap your head around the idea that Google wonβt have a standalone consumer chat app, well, so am I. βThe fundamental thesis behind the RCS protocol is itβs a carrier service,β Sabharwal says. That means that the carriers will be the final arbiters of what Chat can and canβt do β and whether it will be successful. The good news is that Google appears to have herded all the carrier cats into a box where their Chat services will actually be interoperable.
Right now, the expectation is that carriers wonβt charge SMS-style rates for Chat messages. βMessages will work just like any other IP-based messaging protocol. So, in that respect, itβll just be βfreeβ and part of your data plan,β Sabharwal says. Thatβs probably true, but itβs definitely outside Googleβs control. Any communication standard that depends on the largess of wireless carriers is inherently at risk of getting messed up in dozens of ways, including price.
The companies that support the RCS Universal Profile as of April 2018.Image: GSMA
The worse news is that carriers arenβt fond of strong encryption and donβt have a great history of pushing back against government demands for information.
βRCS continues to be a carrier-owned service, so legal intercept and other laws that exist that allow carriers to have access to the data continues to be the case,β Sabharwal admits. And though Google isnβt shutting down Allo, itβs also not working to create a chat service that is as secure as iMessage, Signal, or even Telegram. βAt this point, the answer is no. We will not have that option,β Sabharwal says. Allo offers an βincognitoβ mode that does support end-to-end encryption, but thatβs it.
For a company that has a reputation for rapaciously collecting user data and then turning that data into ads and services, itβs surprising to hear that Google doesnβt want an owned-and-operated chat app. Basically, it sounds like Sabharwal doesnβt think it has to. And it may not have an alternative: the company hasnβt been able to find a way to make an owned-and-operated chat app succeed in nearly a decade.
βI donβt want to say that were βceding messagingβ [to the carriers],β Sabharwal says. Instead, Google believes that it can deliver Google services inside the Android Messages app. It wonβt control the transport of those messages, but it can improve the user experience by building the app itself.
So expect a couple things to happen on the app front. First, Google will finally make a desktop web interface for texting. At least in the initial version, youβll authorize it with a QR code, much as you do with WhatsApp. That makes it essentially an extension of your phone, like the WhatsApp client, so the only message history itβll have is what is on your phone.
Second, expect the Android Messages app to rapidly acquire more features. With luck, its development wonβt stagnate like Hangouts did. Itβs worth keeping an eye on, because some features can be developed in the app itself and others may require coordinating work with all the carriers on the Chat standard itself.
Sabharwal can explain the nuances of RCS hubs, carrier negotiations, and Googleβs own (optional) Jibe RCS cloud services. But more than any of that, heβs eager to talk about the features he wants to bring to Android Messages. Smart replies. Google Assistant. Integration with his other project, Google Photos. Clearer organization of messages. Better search. More βexpressivenessβ (read: GIFs and stickers).
At the end of the day, users care about those features. They care about having βblue bubbles,β those cultural indicators that youβre having a conversation in a channel that isnβt limited to 160-character messages hurled into the void. Googleβs path to getting those features to the 2 billion-plus Android users around the world has been rocky, to put it mildly.
The rollout of Chat could be equally rocky. Some carriers will hold out either through obstinacy or inability. Some Android phones may also be left out, depending on their manufacturer. There are risks that infighting between all the companies trying to work together could collapse the whole effort. And, especially in the US, nobody really knows if or when Apple will bow to pressure to support RCS. (Apple, as youβre surely aware, isnβt one to bow to pressure.)
After talking about all that, Sabharwal finally lets me take a look at a presentation showing an upcoming version of Android Messages. It has all the features heβs hoping to deliver. The messages delivered over Chat happened to be blue. But that was just happenstance: one of the features of Android Messages is that you can pick a custom color for your chat messages, depending on whom youβre speaking with. This is Android, after all, and Android is all about customization.
Customization is messy. Android is messy. So it makes sense that the ultimate fix for Android messaging wasnβt to eliminate messiness, but to embrace it.
We're looking for an experienced Head of Product to join OneSignal's leadership team and build a world class Product Management organization.
Weβre a small, fast-growing team. Owing to our size, youβll be expected to work in several different areas of the business including design, marketing, process refinement, support, and potentially development.
What youβll be doing
Joining OneSignalβs executive team to ship products, help craft the vision and set the roadmap for our engineering team.
Owning the product roadmap and setting expectations both internally and externally on deadlines.
Communicating the value of the product to clients.
Understanding the mobile product ecosystem, especially when it comes to Push, Marketing Automation, and Email to assist in setting long term strategy.
Owning the roadmap and managing the entire product introduction lifecycle from fact-finding to product shipment.
Developing metrics to assess the success of products and features and determine necessary enhancements.
Working with OneSignalβs engineering team to guide technical implementation, set priorities, time schedules, and maintain a fast delivery cadence of product improvements.
Building a world class Product Management organization.
Qualities we look for
Friendliness and empathy
Humility
Strong written and oral communication skills
Detail-oriented and organized
Ability to collaborate well on a team
Can deliver solutions independently as well
Love of learning
Requirements
While this isn't an engineering role, we are an engineering-driven startup and we're looking for a very technical product management leader.
Being an expert on modern forms of product planning, customer discovery, product discovery, and the product development process.
Proven history of shipping and managing products with cross-functional teams.
At least 4 years of experience in a product management role.
Being up to speed on mobile and web trends.
Experience interviewing and communicating with customers.
Experience using product management software, github, design tools, and data analysis tools.
Compensation
Salary: $160k - $210k
Equity: 0.8% - 1.2%
Location
San Mateo, CA
In keeping with our beliefs and goals, no employee or applicant will face discrimination/harassment based on: race, color, ancestry, national origin, religion, age, gender, marital domestic partner status, sexual orientation, gender identity, disability status, or veteran status. Above and beyond discrimination/harassment based on 'protected categories,' we also strive to prevent other, subtler forms of inappropriate behavior (e.g., stereotyping) from ever gaining a foothold in our office. Whether blatant or hidden, barriers to success have no place at OneSignal.
Weβre seeking an experienced Full Stack developer to lead the development of
improvements to OneSignalβs dashboard and API.
Every day over 10,000 clients visit our website and dashboard and thousands more
use our API. Our clients love what weβve built so far and we canβt wait to make
it even better.
Your responsibilities will include working closely with a product designer and
our clients to help build new features and improve our existing ones. You will
primarily program in Ruby on Rails, Typescript, and React. You will
also contribute to improving OneSignalβs API and bare-metal infrastructure
alongside our backend development team.
Get in touch with us if you:
Get excited about the idea of joining a small but fast growing startup.
Enjoy rapid iteration. We ship code multiple times per day.
Have at least 5 years of prior experience in roles that include front-end and
back-end development at a small or mid-sized business.
Know Ruby on Rails, Django, or similar MVC framework.
Are fluent in Javascript, HTML, and CSS.
Have experience writing complex queries with MySQL or PostgreSQL.
Have worked in an environment where developers have written tests and shared
ownership of code.
Compensation
Salary: $120k - $165k
Equity: 0.2% - 0.35%
Location
San Mateo, CA
In keeping with our beliefs and goals, no employee or applicant will face discrimination/harassment based on: race, color, ancestry, national origin, religion, age, gender, marital domestic partner status, sexual orientation, gender identity, disability status, or veteran status. Above and beyond discrimination/harassment based on 'protected categories,' we also strive to prevent other, subtler forms of inappropriate behavior (e.g., stereotyping) from ever gaining a foothold in our office. Whether blatant or hidden, barriers to success have no place at OneSignal.
Weβre seeking an experienced Full Stack developer to lead the development of
improvements to OneSignalβs dashboard and API.
Every day over 10,000 clients visit our website and dashboard and thousands more
use our API. Our clients love what weβve built so far and we canβt wait to make
it even better.
Your responsibilities will include working closely with a product designer and
our clients to help build new features and improve our existing ones. You will
primarily program in Ruby on Rails, Typescript, and React. You will
also contribute to improving OneSignalβs API and bare-metal infrastructure
alongside our backend development team.
Get in touch with us if you:
Get excited about the idea of joining a small but fast growing startup.
Enjoy rapid iteration. We ship code multiple times per day.
Have at least 2 years of prior experience in roles that include front-end and
back-end development at a small or mid-sized business.
Know Ruby on Rails, Django, or similar MVC framework.
Are fluent in Javascript, HTML, and CSS.
Have experience writing complex queries with MySQL or PostgreSQL.
Have worked in an environment where developers have written tests and shared
ownership of code.
Compensation
Salary: $110k - $140k
Equity: 0.1% - 0.15%
Location
San Mateo, CA
In keeping with our beliefs and goals, no employee or applicant will face discrimination/harassment based on: race, color, ancestry, national origin, religion, age, gender, marital domestic partner status, sexual orientation, gender identity, disability status, or veteran status. Above and beyond discrimination/harassment based on 'protected categories,' we also strive to prevent other, subtler forms of inappropriate behavior (e.g., stereotyping) from ever gaining a foothold in our office. Whether blatant or hidden, barriers to success have no place at OneSignal.
Weβre seeking an experienced front-end developer to lead the development of
improvements to OneSignalβs dashboard.
Every day over 10,000 clients visit our website and dashboard and thousands more
use our API. Our clients love what weβve built so far and we canβt wait to make
it even better.
Your responsibilities will include working closely with a product designer and
our clients to help build new features and improve our existing ones. You will
primarily program in Typescript, and React.
Get in touch with us if you:
Get excited about the idea of joining a small but fast growing startup.
Enjoy rapid iteration. We ship code multiple times per day.
Have at least 2 years of prior experience in roles that include front-end
development at a small or mid-sized business.
Are fluent in Javascript, HTML, and CSS.
Know React, or a similar framework.
Have worked in an environment where developers have written tests and shared
ownership of code.
Nice to have:
Experience with Webpack, Redux, CSS grid
Know Ruby on Rails or similar MVC framework.
Experience building and integrating REST API's.
Have experience writing queries with MySQL or PostgreSQL.
Compensation
Salary: $110k - $140k
Equity: 0.1% - 0.15%
Location
San Mateo, CA
In keeping with our beliefs and goals, no employee or applicant will face discrimination/harassment based on: race, color, ancestry, national origin, religion, age, gender, marital domestic partner status, sexual orientation, gender identity, disability status, or veteran status. Above and beyond discrimination/harassment based on 'protected categories,' we also strive to prevent other, subtler forms of inappropriate behavior (e.g., stereotyping) from ever gaining a foothold in our office. Whether blatant or hidden, barriers to success have no place at OneSignal.
We're looking for a Senior DevOps Engineer to help us scale the OneSignal
service. An ideal candidate has experience deploying scalable systems for
another SaaS product. As an early member of this team, you will have lots of
opportunity to establish processes and make architectural decisions.
What you'll be doing
Working closely with a small team to scale and improve reliability of the
OneSignal service.
Architecting scalable solutions for our ever growing dataset and heavy OLTP
and OLAP workloads.
Manage a fleet of webservers running Rails, database servers running
PostgreSQL, and a handful of other servers providing Redis, OnePush, and
Sidekiq job queues.
Working with application engineers to deploy new services and improve
deployment of existing services.
Planning and testing disaster recovery scenarios.
Figuring this out as we go along. We don't have all the answers right now, but
we will do our best to figure them out together.
Qualities we look for
Friendliness and empathy
Modesty
Proficiency in written and oral communications
Ability to collaborate well on a team
Can deliver solutions independently as well
Love of learning
Requirements
Proficient with Linux system administration
Proficient with at least one IT automation tool such as Ansible, Chef, or
Puppet
On-the-job experience doing DevOps/SRE work
Nice-to-haves
Have scaled a web service to 20,000+ requests/second
Experience maintaining Redis and PostgreSQL databases
Worked with a non-relational database such as Apache Cassandra
Deployed distributed analytical system such as Apache Spark
Experience with PostgreSQL backup technologies like WAL-E or barman
Have worked with container orchestration tool such as Kubernetes
Compensation
Salary: $140k - $165k
Equity: 0.2% - 0.35%
Location
San Mateo, CA
In keeping with our beliefs and goals, no employee or applicant will face discrimination/harassment based on: race, color, ancestry, national origin, religion, age, gender, marital domestic partner status, sexual orientation, gender identity, disability status, or veteran status. Above and beyond discrimination/harassment based on 'protected categories,' we also strive to prevent other, subtler forms of inappropriate behavior (e.g., stereotyping) from ever gaining a foothold in our office. Whether blatant or hidden, barriers to success have no place at OneSignal.
We're looking for a DevOps Engineer to help us scale the OneSignal
service. An ideal candidate has experience deploying scalable systems for
another SaaS product. As an early member of this team, you will have lots of
opportunity to establish processes and make architectural decisions.
What you'll be doing
Working closely with a small team to scale and improve reliability of the
OneSignal service.
Architecting scalable solutions for our ever growing dataset and heavy OLTP
and OLAP workloads.
Manage a fleet of webservers running Rails, database servers running
PostgreSQL, and a handful of other servers providing Redis, OnePush, and
Sidekiq job queues.
Working with application engineers to deploy new services and improve
deployment of existing services.
Planning and testing disaster recovery scenarios.
Figuring this out as we go along. We don't have all the answers right now, but
we will do our best to figure them out together.
Qualities we look for
Friendliness and empathy
Modesty
Proficiency in written and oral communications
Ability to collaborate well on a team
Can deliver solutions independently as well
Love of learning
Requirements
Proficient with Linux system administration
Proficient with at least one IT automation tool such as Ansible, Chef, or
Puppet
On-the-job experience doing DevOps/SRE work
Nice-to-haves
Have scaled a web service to 20,000+ requests/second
Experience maintaining Redis and PostgreSQL databases
Worked with a non-relational database such as Apache Cassandra
Deployed distributed analytical system such as Apache Spark
Experience with PostgreSQL backup technologies like WAL-E or barman
Have worked with container orchestration tool such as Kubernetes
Compensation
Salary: $110k - $140k
Equity: 0.1% - 0.15%
Location
San Mateo, CA
In keeping with our beliefs and goals, no employee or applicant will face discrimination/harassment based on: race, color, ancestry, national origin, religion, age, gender, marital domestic partner status, sexual orientation, gender identity, disability status, or veteran status. Above and beyond discrimination/harassment based on 'protected categories,' we also strive to prevent other, subtler forms of inappropriate behavior (e.g., stereotyping) from ever gaining a foothold in our office. Whether blatant or hidden, barriers to success have no place at OneSignal.
We're looking for an engineer interested in writing Rust. Experience with the
language is not required, but we are looking for experience in some sort of
statically typed language and a couple years of experience.
We have several projects using Rust today including the OnePush delivery
service, pstats, our stats daemon that runs on each server, and oscachemgr,
a cache manager for our front end servers. We've recently started another Rust
project pertaining to analytical work on our ever-growing data set. We're also
starting to plan a project to integrate Rust into our Rails application.
In addition to the Rust projects, business needs may at times require you to
work on another part of the application such as Rails or infrastructure.
What you'll be doing
Working closely with a small team shipping lots of code
Writing Rust and Ruby
Adding features to and improving our push delivery service
Working on native Rust extensions to our Rails application
Open source contributions - we have contributed patches to several crates and
released one of our own. We aspire to do more of this as time progresses.
Contributing to our stats monitoring process (Rust) which runs on all of our
servers
Architecting solutions to address our scaling needs
Designing and building a custom message queue
Qualities we look for
Friendliness and empathy
Modesty
Proficiency in written and oral communications
Ability to collaborate well on a team
Can deliver solutions independently as well
Love of learning
Requirements
2+ years of experience writing software
Experience writing with a scripting language such as Node.js, Python, or Ruby
Experience writing with a statically typed language such as Rust, Java, C++,
etc.
Solid understanding of web service architecture. To be less ambiguous, we are
looking for knowledge of the following systems and how they fit together: http
clients, DNS, load balancers, reverse proxies, CDNs, application servers (ex.
Rails), databases, and caches.
Open to learning and writing Rust
Nice-to-have Experience
Experience extending an interpreted language with native code
Familiarity with Redis and PostgreSQL
Proficiency with Linux systems
Familiarity with POSIX C APIs
Understanding of how multiplexed I/O works
Again, these are nice-to-haves. Even if you don't know them, we hope you are
interested in learning them!
Compensation
Salary: $120k - $165k
Equity: 0.2% - 0.35%
Location
San Mateo, CA
In keeping with our beliefs and goals, no employee or applicant will face discrimination/harassment based on: race, color, ancestry, national origin, religion, age, gender, marital domestic partner status, sexual orientation, gender identity, disability status, or veteran status. Above and beyond discrimination/harassment based on 'protected categories,' we also strive to prevent other, subtler forms of inappropriate behavior (e.g., stereotyping) from ever gaining a foothold in our office. Whether blatant or hidden, barriers to success have no place at OneSignal.
We're looking for an engineer interested in writing Rust. Experience with the
language is not required, but we are looking for experience in some sort of
statically typed language and a couple years of experience.
We have several projects using Rust today including the OnePush delivery
service, pstats, our stats daemon that runs on each server, and oscachemgr,
a cache manager for our front end servers. We've recently started another Rust
project pertaining to analytical work on our ever-growing data set. We're also
starting to plan a project to integrate Rust into our Rails application.
In addition to the Rust projects, business needs may at times require you to
work on another part of the application such as Rails or infrastructure.
What you'll be doing
Working closely with a small team shipping lots of code
Writing Rust and Ruby
Adding features to and improving our push delivery service
Working on native Rust extensions to our Rails application
Open source contributions - we have contributed patches to several crates and
released one of our own. We aspire to do more of this as time progresses.
Contributing to our stats monitoring process (Rust) which runs on all of our
servers
Architecting solutions to address our scaling needs
Designing and building a custom message queue
Qualities we look for
Friendliness and empathy
Modesty
Proficiency in written and oral communications
Ability to collaborate well on a team
Can deliver solutions independently as well
Love of learning
Requirements
2+ years of experience writing software
Experience writing with a scripting language such as Node.js, Python, or Ruby
Experience writing with a statically typed language such as Rust, Java, C++,
etc.
Solid understanding of web service architecture. To be less ambiguous, we are
looking for knowledge of the following systems and how they fit together: http
clients, DNS, load balancers, reverse proxies, CDNs, application servers (ex.
Rails), databases, and caches.
Open to learning and writing Rust
Nice-to-have Experience
Experience extending an interpreted language with native code
Familiarity with Redis and PostgreSQL
Proficiency with Linux systems
Familiarity with POSIX C APIs
Understanding of how multiplexed I/O works
Again, these are nice-to-haves. Even if you don't know them, we hope you are
interested in learning them!
Compensation
Salary: $110k - $140k
Equity: 0.1% - 0.15%
Location
San Mateo, CA
In keeping with our beliefs and goals, no employee or applicant will face discrimination/harassment based on: race, color, ancestry, national origin, religion, age, gender, marital domestic partner status, sexual orientation, gender identity, disability status, or veteran status. Above and beyond discrimination/harassment based on 'protected categories,' we also strive to prevent other, subtler forms of inappropriate behavior (e.g., stereotyping) from ever gaining a foothold in our office. Whether blatant or hidden, barriers to success have no place at OneSignal.
OneSignalβs 15 first-party Mobile and Javascript SDKs are installed into nearly
100,000 websites and applications that reach 900 Million unique users a month.
Our SDKs must remain easy to install, work alongside other services and
consistently improve as we add new features.
This is no small feat, but the effort is well worth it: Our clients rave about
the quality, documentation, and ease of use of our service.
We're looking for a skilled developer to help us build upon and maintain SDKs
across over a dozen platforms. The right candidate must have the skill and
confidence to learn new programming languages, programming techniques, and
fearlessly troubleshoot bugs in mobile devices and web browsers.
Responsibilities
Writing code in Java. Additionally writing SDK bindings for
C#, Lua, C++, JavaScript, and more.
Writing high quality code in previously unfamiliar programming languages.
Creating and maintaining open source SDKs used by hundreds of thousands of
developers.
Weβre looking for someone who
Is a polyglot programmer and enjoys learning new programming languages.
Has built and published a native app for Android.
Enjoys diving deep to find solutions to tricky bugs.
Gets excited about the opportunity to join a small but fast growing startup
company.
Compensation
Salary: $120k - $165k
Equity: 0.2% - 0.35%
Location
San Mateo, CA
In keeping with our beliefs and goals, no employee or applicant will face discrimination/harassment based on: race, color, ancestry, national origin, religion, age, gender, marital domestic partner status, sexual orientation, gender identity, disability status, or veteran status. Above and beyond discrimination/harassment based on 'protected categories,' we also strive to prevent other, subtler forms of inappropriate behavior (e.g., stereotyping) from ever gaining a foothold in our office. Whether blatant or hidden, barriers to success have no place at OneSignal.
OneSignalβs 15 first-party Mobile and Javascript SDKs are installed into nearly
100,000 websites and applications that reach 900 Million unique users a month.
Our SDKs must remain easy to install, work alongside other services and
consistently improve as we add new features.
This is no small feat, but the effort is well worth it: Our clients rave about
the quality, documentation, and ease of use of our service.
We're looking for a skilled developer to help us build upon and maintain SDKs
across over a dozen platforms. The right candidate must have the skill and
confidence to learn new programming languages, programming techniques, and
fearlessly troubleshoot bugs in mobile devices and web browsers.
Responsibilities
Writing code in Java. Additionally writing SDK bindings for
C#, Lua, C++, JavaScript, and more.
Writing high quality code in previously unfamiliar programming languages.
Creating and maintaining open source SDKs used by hundreds of thousands of
developers.
Weβre looking for someone who
Is a polyglot programmer and enjoys learning new programming languages.
Has built and published a native app for Android.
Enjoys diving deep to find solutions to tricky bugs.
Gets excited about the opportunity to join a small but fast growing startup
company.
Compensation
Salary: $110k - $140k
Equity: 0.1% - 0.15%
Location
San Mateo, CA
In keeping with our beliefs and goals, no employee or applicant will face discrimination/harassment based on: race, color, ancestry, national origin, religion, age, gender, marital domestic partner status, sexual orientation, gender identity, disability status, or veteran status. Above and beyond discrimination/harassment based on 'protected categories,' we also strive to prevent other, subtler forms of inappropriate behavior (e.g., stereotyping) from ever gaining a foothold in our office. Whether blatant or hidden, barriers to success have no place at OneSignal.
Weβre seeking an experienced Enterprise Account Executive to lead our enterprise
publisher sales efforts. Weβre looking for someone who has experience building a
pipeline, pitching enterprise mobile app publishers/websites and signing them to
annual enterprise contracts. Weβre looking for someone who is comfortable
signing annual SaaS contracts in the $25-100K range while managing a pipeline of
100+ active deals.
Your responsibilities will include working closely with our VP of Business
Development and our team to help to sign, integrate and work with our account
management team to onboard new publishers. The role is focused on signing new
enterprise publishers to the OneSignal push platform.
Get in touch with us if you
Get excited about the idea of joining a small but fast growing startup and be
the first person selling this product
Want to work harder than youβve ever worked before in your career but also get
the ability to set your own ceiling and work closely with your manager to
excel
Enjoy working on a small team, have a large impact and have the trust of the
team
Have at least 3 years of prior experience in roles that include Experience
selling mobile SDKs especially analytics, CRM or marketing automation/push.
Sales experience in adtech, digital media or marketing solutions is also
acceptable
Have a track record of meeting or exceeding sales quotas
Are looking to work closely with Product to add features, capabilities and
integrations that will help you to better win head to head deals against
other vendors
Responsibilities
Managing a pipeline of publishers with over 1M MAU looking to use OneSignal
for push
Working toward meeting or exceeding a sales goal agreed upon with your manager
on a quarterly basis
Comfortable with the high level technical details of the product and capable
of answering technical questions from the lead decision makers
Sourcing, Pitching and managing a pipeline of publishers across or free and
paid push platform, including suggesting changes to the pitch to better
address publisher needs
Providing feedback to Product and Engineering on what features will help to
close new clients and/or are preventing deals from closing
Compensation
Salary: $90k - $145k
Equity: 0.05% - 0.15%
Location
New York, NY
In keeping with our beliefs and goals, no employee or applicant will face discrimination/harassment based on: race, color, ancestry, national origin, religion, age, gender, marital domestic partner status, sexual orientation, gender identity, disability status, or veteran status. Above and beyond discrimination/harassment based on 'protected categories,' we also strive to prevent other, subtler forms of inappropriate behavior (e.g., stereotyping) from ever gaining a foothold in our office. Whether blatant or hidden, barriers to success have no place at OneSignal.
Weβre seeking an experienced Technical Account Manager to lead help onboard
our largest partners and oversee the relationships with our most strategic
publishers. Weβre looking for someone who has led the onboarding and scaling
of strategic partnerships with mobile and website publishers who leverage
OneSignal for Push Notifications.
Your responsibilities will include working closely with our CRO and our team
to help to onboard, integrate and scale the OneSignal SDK into their apps
and websites. All of our Enterprise publishers along with our high MAU
free clients will be managed by you. The role is focused on two main
responsibilities -- retaining/growing our top existing publishers and
onboarding new publishers.
Get in touch with us if you
Get excited about the idea of joining a small but fast growing startup.
Want to be the first team member on account management with the ability
to help build the whole team.
Have current hands-on experience working with mobile SDKs, Javascript
and ability to customize code for clients needs.
Want to work harder than youβve ever worked before in your career but
also get the ability to set your own ceiling and work closely with your
manager to improve.
Enjoy working on a small team, have a large impact and have the trust of
the team.
Are excited to build best practices for getting the most from the OneSignal
platform
Have at least 4 years of prior experience in roles that include working with
mobile publishers, working with SDKs, mobile marketing, account management and/or
adtech.
Are looking work closely with our product team to be the voice of our largest
publishers.
Responsibilities
Managing top OneSignal publishers using our free/paid push platform across a
book of business of 50+ publishers.
Lead Onboarding and Business Reviews for Managed publishers
Serve as the technical and product expert for publishers.
Experience working with Engineers and code to help address clients needs.
Grow the MAU from existing publishers on a quarterly basis.
Onboard new signed clients to use OneSignal SDK / Platform for Push
Educate existing publishers about new products and features
Demo the OneSignal Platform to new publishers
Build the template / playbook for all future Account Managers
Compensation
Salary: $75k - $106k
Equity: 0.05% - 0.15%
Location
New York, NY
In keeping with our beliefs and goals, no employee or applicant will face discrimination/harassment based on: race, color, ancestry, national origin, religion, age, gender, marital domestic partner status, sexual orientation, gender identity, disability status, or veteran status. Above and beyond discrimination/harassment based on 'protected categories,' we also strive to prevent other, subtler forms of inappropriate behavior (e.g., stereotyping) from ever gaining a foothold in our office. Whether blatant or hidden, barriers to success have no place at OneSignal.
Weβre seeking an experienced Business Development Manager to lead the our data monetization efforts. Weβre looking for someone who has led the onboarding and scaling of revenue partnerships with partners who buy or resell data.
In exchange for our free service we are able to monetize the data collected from our SDK across iOS, Android and Web Push. The core data we monetize is cross device, location and audience data.
Your responsibilities will include working closely with our VP of Business Development and our team to help to sign, integrate and scale revenue with our Data Partners. All data revenue will roll into you. The role is focused on two main priorities - Signing new data partners and maximizing the revenue from our existing partners.
Get in touch with us if you
Get excited about the idea of joining a small but fast growing startup and want to be the first member of the team dedicated to data monetization.
Enjoy working on a small team, having a large impact and the trust of the team.
Looking for a manager who can also be a mentor and will help you excel at your career.
Have at least 5 years of prior experience in roles that include data partnerships, mobile data sales, enterprise sales and/or sales at adtech companies leveraging data.
Are looking to work closely with Product help build our data platform.
Responsibilities
Owning all data partners and all revenue from data on the OneSignal platform.
Pitching, signing and managing a pipeline of all data partners, including working with marketing to build necessary sales collateral.
Educating Marketers, Trading Desks, DSP and Advertisers on the OneSignal data asset, how to access it and help drive spend against our data.
Managing and ramping up revenue for existing data partners.
Providing feedback to Product and Engineering on how to better monetize our data asset.
Compensation
Salary: $120k - $165k
Equity: 0.1% - 0.25%
Location
New York, NY
In keeping with our beliefs and goals, no employee or applicant will face discrimination/harassment based on: race, color, ancestry, national origin, religion, age, gender, marital domestic partner status, sexual orientation, gender identity, disability status, or veteran status. Above and beyond discrimination/harassment based on 'protected categories,' we also strive to prevent other, subtler forms of inappropriate behavior (e.g., stereotyping) from ever gaining a foothold in our office. Whether blatant or hidden, barriers to success have no place at OneSignal.
Abstract: Real-time strategy games have been an important field of game artificial
intelligence in recent years. This paper presents a reinforcement learning and
curriculum transfer learning method to control multiple units in StarCraft
micromanagement. We define an efficient state representation, which breaks down
the complexity caused by the large state space in the game environment. Then a
parameter sharing multi-agent gradientdescent Sarsa({\lambda}) (PS-MAGDS)
algorithm is proposed to train the units. The learning policy is shared among
our units to encourage cooperative behaviors. We use a neural network as a
function approximator to estimate the action-value function, and propose a
reward function to help units balance their move and attack. In addition, a
transfer learning method is used to extend our model to more difficult
scenarios, which accelerates the training process and improves the learning
performance. In small scale scenarios, our units successfully learn to combat
and defeat the built-in AI with 100% win rates. In large scale scenarios,
curriculum transfer learning method is used to progressively train a group of
units, and shows superior performance over some baseline methods in target
scenarios. With reinforcement learning and curriculum transfer learning, our
units are able to learn appropriate strategies in StarCraft micromanagement
scenarios.
Comments:
12 pages, 14 figures, accepted to IEEE Transactions on Emerging Topics in Computational Intelligence
Subjects:
Artificial Intelligence (cs.AI); Learning (cs.LG); Multiagent Systems (cs.MA)
People searching for a Google Chrome ad blocking extension have to choose from dozens of similarly named extensions. Only few of these are legitimate, most are forks of open source ad blockers trying to attract users with misleading extension names and descriptions. What are these up to? Thanks to Andrey Meshkov we now know what many people already suspected: these extensions are malicious. He found obfuscated code hidden carefully within a manipulated jQuery library that accepted commands from a remote server.
As it happens, I checked out some fake ad blockers only in February. Quite remarkably, all of these turned up clean: the differences to their respective open source counterparts were all minor, mostly limited to renaming and adding Google Analytics tracking. One of these was the uBlock Plus extension which now showed up on Andreyβs list of malicious extensions and has been taken down by Google. So at some point in the past two months this extension was updated in order to add malicious code.
And that appears to be the point here: somebody creates these extensions and carefully measures user counts. Once the user count gets high enough the extension gets an βupdateβ that attempts to monetize the user base by spying on them. At least stealing browsing history was the malicious functionality that Andrey could see, additional code could be pushed out by the server at will. Thatβs what I suspected all along but this is the first time there is actual proof.
Chrome Web Store has traditionally been very permissive as far as the uploaded content goes. Even taking down extensions infringing trademarks took forever, extensions with misleading names and descriptions on the other hand were always considered βfine.β You have to consider that updating extensions on Chrome Web Store is a fully automatic process, there is no human review like with Mozilla or Opera. So nobody stops you from turning an originally harmless extension bad.
On the bright side, I doubt that Andreyβs assumption of 20 million compromised Chrome users is correct. There are strong indicators that the user numbers of these fake ad blockers have been inflated by bots, simply because the user count is a contributing factor to the search ranking. I assume that this is also the main reason behind the Google Analytics tracking: whoever is behind these extensions, they know exactly that their Chrome Web Store user numbers are bogus.
For reference, the real ad blocking extensions are:
A common analogy for explaining gradient descent goes like the following: a person is stuck in the mountains during heavy fog, and must navigate their way down. The natural way they will approach this is to look at the slope of the visible ground around them and slowly work their way down the mountain by following the downward slope.
This captures the essence of gradient descent, but this analogy always ends up breaking down when we scale to a high dimensional space where we have very little idea what the actual geometry of that space is. Although, in the end itβs often not a practical concern because gradient descent seems to work pretty well.
But the important question is: how well does gradient descent perform on the actual earth?
Defining a cost function and weights
In a general model gradient descent is used to find weights for a model that minimizes our cost function, which is usually some representation of the errors made by a model over a number of predictions. We donβt have a model predicting anything in this case and therefore no βerrorsβ, so adapting this to traveling around the earth requires some stretching of the usual machine learning context.
In our earth-bound traveling algorithm, our goal is going to be to find sea level from wherever our starting conditions are. That is, we will define our βweightsβ to be a latitude and longitude and we will define our βcost functionβ to be the current height from sea level. Put another way, we are asking gradient descent to optimize our latitude and longitude values such that the height from sea level is minimized. Unfortunately, we donβt have a mathematical function that describes the entire earthβs geography so we will calculate our cost values using a raster elevation dataset available from NASA:
importrasterio# Open the elevation datasetsrc=rasterio.open(sys.argv[1])band=src.read(1)# Fetch the elevationdefget_elevation(lat,lon):vals=src.index(lon,lat)returnband[vals]# Calculate our 'cost function'defcompute_cost(theta):lat,lon=theta[0],theta[1]J=get_elevation(lat,lon)returnJ
Gradient descent works by looking at the gradient of the cost function with respect to each variable it is optimizing for, and adjusting the variables such that they produce a lower cost function. This is easy when your cost function is a mathematical metric like mean squared error, but as we mentioned our βcost functionβ is a database lookup so there isnβt anything to take the derivative of.
Luckily, we can approximate the gradient the same way our human explorer in our analogy would: by looking around. The gradient is equivalent to the slope, so we will estimate the slope by taking a point slightly above our current location and a point slightly below it (in each dimension) and divide them to get our estimated derivative. This should work reasonably well:
defgradient_descent(theta,alpha,gamma,num_iters):J_history=np.zeros(shape=(num_iters,3))velocity=[0,0]foriinrange(num_iters):cost=compute_cost(theta)# Fetch elevations at offsets in each dimensionelev1=get_elevation(theta[0]+0.001,theta[1])elev2=get_elevation(theta[0]-0.001,theta[1])elev3=get_elevation(theta[0],theta[1]+0.001)elev4=get_elevation(theta[0],theta[1]-0.001)J_history[i]=[cost,theta[0],theta[1]]ifcost<=0:returntheta,J_history# Calculate slopelat_slope=elev1/elev2-1lon_slope=elev3/elev4-1# Update variablestheta[0][0]=theta[0][0]-lat_slopetheta[1][0]=theta[1][0]-lon_slopereturntheta,J_history
Great! Youβll notice that this differs from most implementations of gradient descent in that there is no X or y variables passed into this function. Our cost function doesnβt require calculating the error of any predictions, so we only need the variables we are optimizing here. Letβs try running this onMount Olympus in Washington:
Hm, it seems to get stuck! This happens testing in most other locations as well. It turns out that the earth is filled with local minima, and gradient descent has a huge amount of difficulty finding the global minimum when starting in a local area thatβs even slightly away from the ocean.
Momentum optimization
Vanilla gradient descent isnβt our only tool in the box, so we will try momentum optimization. Momentum is inspired by real physics, which makes the application of it to gradient descent on real geometry an attractive idea. Unfortunately, if we place even a very large bolder at the top of Mount Olympus and let it go, itβs unlikely to have enough momentum to reach the ocean, so weβll have to use some unrealistic (in physical terms) values of gamma here:
defgradient_descent(theta,alpha,gamma,num_iters):J_history=np.zeros(shape=(num_iters,3))velocity=[0,0]foriinrange(num_iters):cost=compute_cost(theta)# Fetch elevations at offsets in each dimensionelev1=get_elevation(theta[0]+0.001,theta[1])elev2=get_elevation(theta[0]-0.001,theta[1])elev3=get_elevation(theta[0],theta[1]+0.001)elev4=get_elevation(theta[0],theta[1]-0.001)J_history[i]=[cost,theta[0],theta[1]]ifcost<=0:returntheta,J_history# Calculate slopelat_slope=elev1/elev2-1lon_slope=elev3/elev4-1# Calculate update with momentumvelocity[0]=gamma*velocity[0]+alpha*lat_slopevelocity[1]=gamma*velocity[1]+alpha*lon_slope# Update variablestheta[0][0]=theta[0][0]-velocity[0]theta[1][0]=theta[1][0]-velocity[1]returntheta,J_history
With some variable tweaking, gradient descent should have a better chance of finding the ocean:
We have success! Itβs interesting watching the behaviour of the optimizer, it seems to fall into a valley and βroll offβ each of the sides on itβs way down the mountain, which agrees with our intuition of how an object with extremely high momentum should behave physically.
Closing thoughts
The earth should actually be a very easy function to optimize. Since the earth is primarily covered by oceans, more than two thirds of possible valid inputs for this function return the optimal cost function value. However, the earth is plagued with local minima and non-convex geography.
Because of this, I think it provides a lot of interesting opportunities for exploring how machine learning optimization methods perform on tangible and understandable local geometries. It seems to perform pretty well on Mount Olympus, so letβs call this analogy βconfirmedβ!
If you have thoughts on this, let me know on twitter!
Hi HN! We're Ed and Jeremie, the founders of SharpestMinds in YC's W18 batch. We're building a free online community for ML/AI developers through which they can access job opportunities. (You can apply to join it at https://www.sharpestminds.com/members)
We're ML developers from non traditional backgrounds. Ed did a PhD in biological physics, and Jeremie studied quantum optics before dropping out of grad school to work on SharpestMinds. We started looking for ML jobs after school, thinking it shouldn't be too hard to get one. We found to our naive surprise that we fell short on a number of skills that are needed to do good work in industry. You just don't learn much devops in grad school.
As a result we decided to build something that would make it easier for ML devs to develop (and discover!) skills they might be missing, and then get their first jobs or internships. From the outset we also wanted to build a community around the process, since looking for your first job is usually a pretty lonely experience. Because we monetize directly through hiring, we can afford to create a space for discussion without ads or algorithmic distractions :)
To qualify for joining, you do an online deep learning quiz (here: https://www.sharpestminds.com/members/apply), followed by a technical interview. If you pass both, we invite you aboard. It's possible to retake the quiz a month later if you don't pass it, and we'll send you tips on what to study in the meantime.
Once you join you get access to a job board with exclusive (i.e., not scraped) internship and full-time opportunities on it. We've created an application system where your profile gets customized to the job you're applying for, to maximize the odds that you'll get an interview. We also have lists of common interview questions, mentors that you can practice interviewing with, and periodic AMAs with ML hiring managers from companies like Skydio and Airbnb.
The hardest part about building this has been figuring out the best way to present our users to employers. Early on we found that hiring managers were passing on qualified people, because their eyes would glaze over from reading too many CVs. We ended up building application profiles that let our users display their most relevant personal projects prominently in their application. The interview rate has increased significantly as a result.
If our approach works for the ML/AI field, we'd like to build communities like this for other fields too.
We're looking forward to getting feedback and hearing ideas from HN! We know there are lots of ML devs / enthusiasts on here, and we'd also be very interested in hearing about your own experiences making the transition, or similar programs you might know about. We'd also be interested in hearing about what, in your experience, are the most important programming skills needed by someone with a good knowledge base but little practical experience to be a strong contributor at their first job or internship.
βWe were so fascinated that they could stay underwater much longer than us local islanders,β Dr. Jubilado said. βI could see them literally walking under the sea.β
Even as anthropologists study Bajau culture, biologists have grown curious about them, too. Bajau divers been observed plunging more than 200 feet underwater, their only protection a pair of wooden goggles β a physiological marvel.
In 2015, Melissa Ilardo, then a graduate student in genetics at the University of Copenhagen, heard about the Bajau. She wondered if centuries of diving could have led to the evolution of traits that made the task easier for them.
βIt seemed like the perfect opportunity for natural selection to act on a population,β said Dr. Ilardo.
Her first step was to travel to Sulawesi, Indonesia, and then to a coral reef island where she reached a Bajau village. After she proposed her study, they agreed to the plan. She returned a few months later, this time with a portable ultrasound machine to measure the size of the Bajau peopleβs spleens.
PhotoDr. Melissa Ilardo taking an ultrasound scan of a Bajau diverβs spleen. Scientists have found that marine mammals with larger spleens can dive deeper β the enlarged spleen acts much like a bigger scuba tank.Credit
Peter Damgaard
When people plunge into water, they respond with the so-called diving reflex: the heart rate slows and blood vessels constrict as a way to shunt blood to vital organs. The spleen also contracts, squirting a supply of oxygen-rich red blood cells into the circulation.
All mammals have a diving reflex, but marine mammals like seals have a particularly strong one. Scientists suspect that the reflex helps them dive deeper β as it turns out, seals with bigger spleens can dive deepest. An enlarged spleen seems to function like a bigger scuba tank.
Dr. Ilardo scanned the abdomens of the Bajau villagers and then traveled about 15 miles inland to a village occupied by farmers known as the Saluan. She scanned them, too.
When Dr. Ilardo compared scans from the two villages, she found a stark difference. The Bajau had spleens about 50 percent bigger on average than those of the Saluan.
Yet even such a remarkable difference might not be the result of evolution. Diving itself might somehow enlarge the spleen. There are plenty of examples of experience changing the body, from calloused feet to bulging biceps.
Only some Bajau are full-time divers. Others, such as teachers and shopkeepers, have never dived. But they, too, had large spleens, Dr. Ilardo found. It was likely the Bajau are born that way, thanks to their genes.
PhotoBajau homes built on stilts. Only some Bajau are full-time divers, while others are teachers and shopkeepers, but Dr. Ilardo found that all Bajau had enlarged spleens.Credit
Melissa Ilardo
On her visit to Sulawesi, Dr. Ilardo also took mouth swabs from the Bajau and Saluan from which she extracted DNA. She looked at the genetic variations in each village and compared them to people from neighboring countries, such as New Guinea and China.
A number of genetic variants have become unusually common in the Bajau, she found. The only plausible way for this to happen is natural selection: the Bajau with those variants had more descendants than those who lacked them.
One variant of a gene called PDE10A influenced the size of spleens in the Bajau. People with one copy of the mutant gene had bigger spleens than those with none. People with two copies had even bigger spleens.
Scientists had never found a special role for PDE10A in the spleen. βThis connection was a bit bizarre,β Dr. Ilardo said.
But thereβs one possible link. PDE10A has been shown to control the level of thyroid hormone in the body. And scientists have found that injecting thyroid into mice with stunted spleens can make the organs grow larger.
Still, that wouldnβt pin down exactly how PDE10A became so common in the Bajau. βItβs the question thatβs harder than others,β said Rasmus Nielsen, a geneticist at the University of California, Berkeley, who collaborated with Dr. Ilardo.
PhotoA diver with a traditional wooden mask. Some researchers suspect the Bajau only began diving when Chinese demand for sea cucumbers rose in the 1600s. Other experts believe the Bajau began earlier, at the end of the last Ice Age, when rising sea levels turned the region into islands.Credit
Melissa Ilardo
For her own part, Dr. Ilardo suspects that natural selection favored the Bajau variant of PDE10A because deep diving is so risky. βI would think, as morbid as it is, that if they didnβt have this, it would kill them,β she said.
FranΓ§ois-Xavier Ricaut, an anthropologist at the University of Toulouse who was not involved in the study, said that it wasnβt clear yet how quickly this evolutionary change happened.
Some researchers suspect the Bajau only began diving to great depths when a market for sea cucumbers opened up in China in the 1600s. Or perhaps the adaptation began thousands of years earlier, at the end of the Ice Age, when rising sea levels turned the region around Indonesia into islands.
βThis study acts as a cornerstone for exciting questions to follow,β said Dr. Ricaut.
Dr. Ilardo said there were likely a number of other genes that help the Bajau dive. She and her colleagues also found evidence for natural selection on a gene called BDKRB2.
To see if thatβs the case with the Bajau, Dr. Ilardo will need to take another trip to beautiful Sulawesi. βI would be happy doing this as long as I can,β she said.
Video streaming has traditionally been considered an extremely power-hungry operation. Existing approaches optimize the camera and communication modules individually to minimize their power consumption. However, designing a video streaming device requires power-consuming hardware components and computationally intensive video codec algorithms that interface the camera and the communication modules. For example, monochrome HD video streaming at 60 fps requires an ADC operating at a sampling rate of 55.3 MHz and a video codec that can handle uncompressed data being generated at 442 Mbps.
We present a novel architecture that enables HD video streaming from a low-power, wearable camera to a nearby mobile device. To achieve this, we present an "analog" video backscatter technique that feeds analog pixels from the photo-diodes directly to the backscatter hardware, thereby eliminating power-consuming hardware components, such as ADCs and codecs. To evaluate our work, we simulate an ASIC, which achieves 60 fps 720p and 1080p HD video streaming for 321 Β΅W and 806 Β΅W, respectively. This translates to 1000x to 10,000x lower power than it used for existing digital video streaming approaches. Our empirical results also show that we can harvest sufficient energy to enable battery-free 30 fps 1080p video streaming at up to 8~feet. Finally, we design a proof-of-concept prototype with off-the-shelf hardware components that successfully backscatter 720p HD video at 10 fps up to 16 feet.
Google's App Engine may not have been designed to provide a way for developers to evade censors, but for the past few years it has offered one, via a technique known as domain fronting. By wrapping communications to a service with a request to an otherwise innocuous domain or IP address range such as Google's, application developers can conceal requests to domains otherwise blocked by state or corporate censors. It's a method that has been used both for good and illβadopted by Signal, the anti-Chinese censorship service GreatFire.org, plugins for the Tor anonymizing network, some virtual private network providers, and by an alleged Russian state-funded malware campaign to obfuscate Tor-based data theft.
But on April 13, members of the Tor Project noticed that domain fronting had become broken. The reason, according to a report by The Verge's Russell Brandom, is that Google made changes to the company's network architecture that had been in the works for some time. A Google representative told Brandom that domain fronting had never been officially supported by Google, and it only worked until last week "because of a quirk of our software stackβ¦ as part of a planned software update, domain fronting no longer works. We donβt have any plans to offer it as a feature.β
Ars attempted to contact Google, but we've received no response as of press time. [Update, 4:40 PM EDT:Β Google sent the same statement as given to Brandom in response to our query.]
//βDomain fronting has never been a supported feature at Google, but until recently it worked because of a quirk of our software stack. We're constantly evolving our network, and as part of a planned software update, domain fronting no longer works. We don't have any plans to offer it as a feature.β
Domain fronting uses a manipulation of the secure HTTP Web protocol (HTTPS) and the Transport Layer Security (TLS) standard to help fool deep packet inspection systems and firewall rules about the intended destination of a Web request and to exploit the functionality of content delivery networks (CDNs). Domain names show up three times during a Web requestβas part of a DNS query for the IP address of the site, in the Server Name Indication (SNI) extension of TLS (which tells a server with multiple sites which domain the traffic is for), and in the HTTP "host" header of the Web request. For HTTP traffic, all three of those instances of the domain name are visible to a censor's network gear; when surfing an HTTPS site, the HTTP header is encrypted.
In a domain fronting scheme, the DNS request and SNI extension use the domain name of an unblocked host, but the HTTPS header contains the actual destinationβwhich the request is then forwarded to, as long as it's part of the same CDN. That destination is usually a proxy server, VPN gateway, or a Tor bridge. On Google, that proxy could be on an AppEngine host; on major CDN networks, it could be hosted on any server that is a paying customer. To anyone sitting between the client and the CDN, the traffic appears to be going to a harmless site, but it is, in fact, getting re-routed to its intended location.
There's a straightforward reason Google and other cloud and Web service providers don't intentionally support domain fronting: the potential damage to their business they would face if their networks were blocked as a result. "We donβt support domain fronting," Cloudflare CEO and co-founder Matthew Prince said in an email to Ars. "Doing so would put our traditional customers at risk as it would mask banned traffic behind their domains."
And that may be part of why Google has made changes that have broken domain fronting based on Google's own internal CDNβincreases in censorship of encrypted communications tools have had a major impact on Google's other paying customers.
Telegram and Zello were recently ordered blocked by Roskomnadzor, Russia's telecommunications authority, and the blocked addresses in that effort rapidly expanded to encompass Google and Amazon Web Services addresses as Telegram users started using cloud-based proxies. When Amazon reportedly asked Zello to stop hosting proxies on AWS, the service moved to Google. And many Telegram users in Russia have been using proxies on various cloud services to evade censorship. With the loss of domain fronting, users are forced to point at specific IP addresses for proxies in the cloudβaddresses that censors can block wholesale.
Atrium is a data-driven law firm designed to make access to corporate legal services transparent and price-predictable for everyone. We're doing this by building the first structured data platform for organizational data. We use modern techniques for extracting data that is locked away in legal documents, modeling how best to store this information, and inventing new ways for lawyers and paralegals to interact with the resulting structured data to help advise clients.
Atrium LTS ("Legal Technology Services") technology provides a better experience for legal clients than they previously thought possible, increasing communication and speed of service.
We're growing our product and design team and are looking for exceptional product designers to join us in building a modern law firm from the ground up. Weβre seeking a product design leader to join our fast-growing engineering, product, and design (EPD) team. Youβll work in an industry that has been underserved by design and technology by turning complex, manual work into elegantly-crafted solutions that are exponentially more intuitive and efficient than established processes. As an early member of Atriumβs EPD team, youβll also have an outsized opportunity to shape Atriumβs design language and brand, hire and grow our product and design team, and build the future of legal services for clients and legal professionals.
I'm a sophomore in college, and feeling pretty bogged down by the not-so-relevant required courses at my school. I love the CS courses but I keep finding myself looking at entry level code monkey jobs and thinking of dropping out. I work part time as a developer right now and I enjoy working far more than doing any of my homework, so this is something that is on my mind a lot.
What are some lesser known areas of CS that would be worth studying while I have the chance? I would say the subjects that excite me the most are Machine Learning, p2p tech like IPFS, UX-design, and alternative computer-interface things (like brainwave sensors, VR, and that jawbone thing from MIT that was posted a few weeks back [1]).
At one end are single-function npm libraries that led to the left-pad fiasco[1].
At another end are things that you should only be implementing yourself in highly unusual circumstances, such as cryptography libraries.
Where on this spectrum do you usually implement the thing yourself, and what is your thought process?
What are the costs of importing a library, and how are those costs different for different projects? Are there security risks? What are the benefits?
Conversely, what are the costs and benefits of implementing something in-house?
Has there ever been a case where you've tried to roll your own and it ended in disaster? Or where you'd wished you'd never added a dependency on some library?
I just came back from an unexpected trip to Tokyo and Hong Kong. On the whole, I was lucky to roam around without much agenda. There was space to explore, soak in the vibe of the cities, get unguided impressions and think about what I noticed.
I'm not a big π―π΅ or Asia freak and did not do any research in advance. I simply arrived on the spot with minimal preparation, a deliberately clueless attitude and let things hit me as they came. These are my raw, naive conclusions, so take it all with a grain of salt. Also, I will not mention food as foodie stuff is boring π
TL;DR: Tokyo is insanely clean, feels sadly old but still futuristic. Many face masks on people, the coolest sounds and faces on objects, lots of weird pervy elements and it's so enormous that it messes with your head. Hong Kong was designed for bankers with slaves but has that mesmerizing Blade Runner skyline. The lower class Chinese outskirts are overwhelmingly full of life, it made me feel that the "future" will clearly happen in Asia.
Although having lived in several β mostly πͺπΊβ countries, this was easily my biggest trip in a decade and the first proper one in Asia. Typically I'm not a big traveler-nomad type, family visits and gig travel made me jaded about frequent trips. The ~10 hour flight was my longest flight ever.
What I've noticed is that long-distance air travel has gotten a LOT smoother. There's in-flight WiFi above the artic circle and Siberia. Surprisingly, I also didn't have to have any human interaction after testing false positive for explosives (??!!) in Berlin. Once that amusing episode got sorted on the journey's first leg, there was no more passporting hassle as EU biometric passport scanners are fully automated gates. For me, the most worrisome were the thermal cameras upon arrival in Tokyo which could land one in quarantine. Getting the 90-day visa in both places was a 1-minute rubber stamp procedure with bored customs officers wanting to get you out of their way as fast as possible π
This city is the largest megapolis on Earth with almost 40M people living in the metro area. It's insanely big and DENSE. It took a good 40 minutes from the center with the Shinkansen π trains roaming at takeoff-speeds until I began seeing small, sporadic patches of unused land. Witnessing the sheer scale of the place tripped me out big time. When you see it, it puts your own (and anyone's) significance in perspective βοΈπ΅
It is also the cleanest place I've ever seen. There are no trash bins on the street, you simply carry your own trash and dispose it at home. Like the foam padded construction scaffoldings in Barcelona, this would be a good candidate for wholesale adoption worldwide. I have a hunch that personal feedback loops are important - similar to cooking your own meals or cleaning up after, it's probably a good idea to feel how much trash you produce.
An immediately obvious travel fail was forgetting my audio recorder. In Japan, the use of sounds and music in machinery is omnipresent to the point that it feels like discovering a new sense. The conscious use of sound design and music for feedback clarifies what is happening without needing to attentively read or listen to speech. This feels so cool that communication elsewhere seems incomplete in comparison.
Despite 99% of the visible writing being undecipherable to me, getting around was easy. I was told that (English) signage has improved significantly in the past few years, and is poised to get even more common with the preparations for the 2020 olympics.
Obviously, your biggest friend in a foreign place is the Internet π Sort that out ASAP with either getting one of the pan-Asian 4G data sim-cards or better, renting a slightly more expensive pocket wifi device with a generous multi-GB daily data allowance. Internet connectivity is far ahead of Europe and makes it look like a joke in comparison. I had several video calls while walking through the city, something I stopped attempting with the tragicomically outdated "startup capital" infrastructure of Berlin - take cues π
In general, Tokyo is optimized for giving you all the tools to keep you stay the night at work. Most places have 24/7 stores and you'll find everything you'd need - wet wipes, contact lenses, fresh underwear, shirts and so on.
Money wise, don't be like me and take at least two credit cards from different banks. I had a small freak-out moment upon arrival when my card didn't work for a few hours - turned out to be the bank's routine nighttime maintenance on the weekend, but the time difference made it mid-day in Japan.
You can also use your rechargeable π€ Pasmo or π§ Suica public transport card to pay for stuff. If you can figure it out, just load them on your phone's NFC chip and then you have one less thing to fumble with. This felt easy and refreshing, I think it might catch on.
Face masks are a cool staple of Japan. You can buy them on every corner, but you'll often get a pack for free as a street promo item. Unlike in China, the air quality isn't too bad. Why wear them then? They serve a number of purposes:
π¨π½βπ create a "minimum viable bubble" in crammed spaces
π lets you send embarassing ninja vids to friends & family
The are other practical reasons. Air in Tokyo is extremely dry in the winter. When it's cold, the mask will help keep your face warmer and wetter. While face masks might be weird to an European outsider, they totally make sense in the context of large, crowded cities.
Despite the anonymous nature of a huge city, I noticed that any public display of affection is rare. You rarely see couples holding hands or anything similar. I don't think I've seen anyone kiss in public my whole time here.
The most mind-boggling thing in Japan is the general politeness and sense of the common. Perhaps it's a down to wanting to cause the least disturbance to the carefully constructed environment. Maybe even a sense of duty to protect a shared, fragile order. After a few days, I noticed unexpected changes in my own behavior. I was trying hard to be more polite, kept quieter and tried to get out of everybody's way. Everything is organized and not left to chance, down to the system of queing for boarding trains β¬ οΈ
I noticed a lot of pensioner-volunteers just passing time, helping tourists find their way. Sometimes they also help directing traffic in and out of parking lots or construction sites. There are plenty of caretakers and minders of all things.
The ticket office opens at 5:30:00
You do get a feeling that you're in "the past of the future". There's an old and melancholic tinge, perhaps partly due to the winter season. But the average age is noticeably old and too "middley". It's not a fresh, youthful place. In this sense it's similar to Germany, but way further down the line. When you're here, the historical ties between the countries will suddenly become obvious. The right-wing conservative roots of the cultures are hand-in-glove - there's an emphasis on public order, precision and preserving traditions, to the detriment of free expression and a sense of social freedom.
I guess the pressure-cooker environment also drives ones attention inward. There's a lot of care and thought put into every facet of life, and a sense of pride thereof. As a real-life illustration of the insane attention to detail, see the ticket office man as one of my favorite moments of the whole trip...
There are still strong leftovers from the late 80's culture peak, which is most obvious when you see all the crazy gaming arcades. If you can, please check out any of the pachinko parlors, in which the noise is higher than in factories or industrial aircraft. I only lasted about as long as previously in a -140 Β°C cryo chamber. It's so loud there that it's beyond me how people spend hours in these ultra-stressful environments.
Needless to say, there's a lot of weird freaky shit to be randomly found when hanging out in Japan.
Like "smile trainers"...
...or a large assortment of replica guns, including rocket launchers. It's obvious that they have a thing for military stuff here. I've seen a lot of airsoft/paintball stores and there are all kinds of advanced Metal Gear Solid style training compounds. A recent Vice video piece offers some cues to how this came to be.
Perhaps the most disturbing stuff I ran into was something I'd describe as a thriving business mixture of pretend underage girlfriends, pop idol shows and sports (or more accurately, cheerleader) card collectibles. Some of these girls are in their early teens and you can buy their pictures in many stores:
Apparently they're part of a bizarre pop group that has hundreds of members and millions of fans. They are grouped into teams so that they can perform in several cities on the same dates. When you look into it, it's super pervy stuff that goes several layers deep. Each girl has their own feed with solo video clips and you can meet them at "handshake events" in their group's own theatres...I talked about this with some friends over dinner and this weird Japanese obsession is clearly not as innocent as tries to appear on the surface. Search for "JK business" if you want to go further down a distressing rabbit hole...
You will also definitely see the infamous burn-outs, collapsed people on the metro traveling home late at night. If this is the pitch for your post-school life, no wonder many just drop out and become shut-ins.
In Tokyo, everything seems to have a face. I'm a huge fan of character design, smiley faces and just putting faces on objects in general. In this sense, Tokyo was a paradise right up my alley, by far the best signage and graphics I've seen anywhere. I don't know where it comes from, but I'd guess a tendency of humanizing and personifying objects might stem from earlier animist traditions and religions. Pretending - or acting - as if everything had personhood feels strangely primal and makes you care more about your surroundings. Cool and good.
In Japan, automation actually delivers. From super-fast tap and soap dispenser sensors to vending machines, things just work as they should. After a few days, I felt strangely confident in appliances. In Europe, I'm always suspicious and never really sure if a machine will work out - they feel slow and clumsy in comparison.
I've also met my first, legit, real life robot. It's a big difference to see robots in Youtube clips versus your own eyes. This thing somehow totally overwhelmed me for a moment, I almost cried π
But what's more interesting than the robots themselves is watching children interact with them. Kids are growing up in Tokyo thinking that humanoid robots are completely normal. If proper robots are going to happen somewhere, it's in Japan - I think they'll just will them into existence.
Up until a few months ago I was not aware of the existence of snow monkeys, and promptly assumed they were some Yeti/Bigfoot type fake news when a friend mentioned them. So when I got this close to their alleged habitat, I wanted to go check and see. I'm happy to report that the snow monkeys are real:
This was a nice little trip to take and a refreshing peak into small-town/village life in Japan. The only downside was the typical overtourism. You will see a lot more apes than monkeys:
As I said, Tokyo is futuristic but does not feel modern in the present-day sense. I was looking for some signs of the actual future, and the closest thing I found was a VR arcade / theme park. It was full of "force-feedback" style machines - cars, skiing threadmills and a full scale room where you can move around freely while wearing VR goggles.
I've been keeping and eye on VR stuff for a while now. It's obviously still in its infancy, even the best goggles are a bit clumsy and there's plenty of room for improvement. Yet the level of deep immersion is already there and unexpected; the few rare instances where I've seen people scream and fully let go happened here. I went twice to the Shinjuku VR zone - but make sure you schedule it in advance, the demand is high and there are hour long queues. I wish I could've spent more time here and dwelve deeper, but it was time for the next stop...
In most ways, Hong Kong turned out to be the exact opposite of Tokyo. If Japan is order, Hong Kong is chaos.
The city will force you think in 3D. Getting around on a street level is not simple, you will likely have to use corridors and overpasses that connect one building to another. Hong Kong has the most skyscrapers in total - all the fluffy talk about its beautiful skyline and futuristic Blade Runner vibes is no exaggaration. It's a truly special place that sucks you in.
I vaguely recall watching the British handover of Hong Kong as a small kid. There's still some ghost-like tinge of the colonial past, but the legacy doesn't stretch far beyond Pret-a-Manger and a few graveyards.
Still, everything is bilingual and you can fully participate in English. Setting yourself up is therefore trivial. Transportation is modeled after London, except the maskot is an π instead of an π (the oyster emoji was apparently removed from the standards π’).
I did feel a sense that mainland China's influence is getting stronger. There's visible pushback to that. As a sign of rifts, there were small groups of resilient protesters campaigning here and there, but it didn't seem to me like they could prevail in the long run.
Sadly I didn't manage to properly explore clubs in Tokyo. I did get a small peek in Hong Kong though. The existing scene is driven by a few ultra-enthusiatic expats, trying to nail down the tech-housey vibe of Berlin. Clubs are rather tiny and hidden away in the middle of buildings that gives them a distinct windowless, "overground" feel. It's all super small but legit. The enthusiasm and zeal renewed my appreciation to what we have in Europe. You tend to forget that after a while as you adapt π€
It felt like the city suffers from an age gap, most people going out are either slightly underage teens with fake IDs or expats in their mid 30s. Not much inbetween as kids typically go study abroad once they're out of high school.
Compared to Tokyo, people seemed way friendlier and affectionate. There's sort of a jovial chaos going on, especially as you venture outside of the city core. At the Chinese street markets, you'll find various disturbing stuff - sketchy meats, caged birds and probably even shadier things if you know where to look for it...
The saddest thing about Hong Kong is that it seems to have been designed for bankers. A lot of precious downtown real estate is dedicated to expensive stores and shopping malls. While observing the habits of Tokyo sararΔ«men provided for an amusing pasttime, I concluded that the Hong Kong bankers are boring and have no edge in comparison. Everything smells of a culture of haha-business! bullshit, in a saddening way.
Suprisingly, there are a lot of Teslas everywhere. I'd guess about every 10th car is a Tesla. A lot of Model Ss or Xs. Further contenders are Porsches, top of the line BMWs or other luxury cars costing millions of HK$/ε (about β¬1/10). I found out that until recently, electric cars were exempt from to an approx. 100% registration tax - that explains it all, a Tesla cost half of what similar gas vehicles would.
There's a lot of tasteless, cheesy stuff, like stupid-looking statues and golden gates in front of apartments. But there's a weird, troll-like twist to this splashy display of wealth β plumbing in most dwellings is
quite ridiculous. There might be a million millionaires in Hong Kong, but they seem to lack the collective will to get their shit together on water and waste. I've heard this is common throughout China. Many flats have pipes rigged on the outside.
Talking about π€, I noticed a suspicious lack of anything Bitcoin with interest. While in Tokyo there were mentions of blockchain left and right, I saw nothing at all in Hong Kong. There were plenty of visibly run-down banks and front offices for fake-sounding companies, though.
Outside of banker districts, everything is teeming with life. Full of hustle and buzz. Many children around. Already super young kids are helping out in family stores without anyone turning a head. Despite being poorer, people seem paradoxically happier and in better overall shape, fuller of energy. There's a strange sense of optimism, determination and relentless progress - at least that's how it felt to me.
During the day, you'll also see a lot of helpers walking kids and dogs in richer residential areas. This is a super disturbing phenomenon that I'm unable to accept but also don't pretend to understand the nuances of. There seems to be a hidden life in their community, a parallel societal stream of sorts. Sunday is typically their "free day", when the entire downtown is swarmed and taken over from the bankers, if temporarily.
There are lots of other festivities and a joyous atmosphere in the evenings and weekends, due in no small part to the great climate, beautiful hills and the crazy city lights. LED balloons seem to be a big hype now, to the point they're being banned from the subway. As I found out only later, you have to watch for counterfeit balloons filled with cheaper hydrogen. Scary, as you cannot tell just by looking.
Returning to Europe was quite a letdown. In the first few days, everything seemed eerily slow, derelict and empty, especially back in Berlin. I kept thinking I missed an announcement about staying inside and preparing for an impending apocalypse.
It's normal to get some kind of a post-travel depression after living a more intense life for a while, but it's been a couple weeks and the feelings didn't quite disappear. There's a disproportionate impact.
Truth is - Advanced Asiaβ’ is just incomparably more vibrant right now. There's constant movement. A steady, fast-paced struggle. Seeing it IRL reinforced my presentiment of feeling like we're living in a lazy, cushioned and outdated region with little hope for rapid advancement. The trip recalibrated me to pick up my own pace and just to try harder.
I don't know how to pin it down exactly, but it feels like Europe is suffering from the culture and attitude of pensioners who are still living in their ignorant version of a 20th-century fantasy. They are reassured by their situational wealth and are either unaware, or scared of reality. Everything is hedged, risk averse and there's a general sense of aimlessness and cluelessness. More than that, there's a baffling and dangerous tendency of trying to isolate and roll things back instead of pushing ahead.
While I've yet to visit the other big cities in China or Korea, this trip already demonstrated to me that the current thinking here is centered on a long outgrown scale... Everything needs to be addressed at 10Γ - 100Γ larger levels, in all terms of speed, size and social impact.
I would still say Berlin is the best place to base off in Europe (Rotterdam or Barcelona might be 2nd), but its pace and trends make me seriously worried. And this applies to the whole continent. It's not looking good.
Think about it this way β if someone from SEA/EA visited, it'd already be difficult to show them something culturally new. Besides the hedonist π― dungeons (which thrive mainly thanks to a happy accident during post-WWII occupation) and some galleries, what cool things do we still have here? There's less and less as the city slowly ages out. Everything is about the past, and not about what's current.
The weirdest thing was that I somehow never felt out of place or terribly far from home when I was away. It feels more like that after my return. You know, I don't want to live in an old, outdated and lethargic place. That's how Europe makes me feel right now. The way things are going, I'd wager that more and more young, prolific πͺπΊ creators will essentially leave to Asia or other pockets of innovation (as they already do). It's just beginning to feel more apt to do so, somehow.
Nationality is a fading illusion, nobody cares where they were born unless they have nothing else to cling to. We are citizens of the globe. Home is basically where a good bed, a supportive environment and fast Internet is. The former you can get from IKEA pretty much anywhere. For the latter, we'll just travel and spend most of our time where things are easier, cooler and better.