We had 10 years+ plus of having products like Facebook, Twitter, YouTube, hell even LinkedIn with a basic content model of "you build your own graph of people who you pull content from" and their job was to show it to you and puts ads in there to fund the whole enterprise. If I decided to follow harmful content? That was a pact between me and the content creator, and YouTube was nothing more than a pipe the content flowed through. They were able to build multi-billion dollar businesses off of this. That's really important, this was enormously profitable. But then the problem happened that people's graphs weren't interesting enough, and sometimes they'd go on the thing and there were no new posts from people they followed, and this was leaving money on the table. So they took care of that problem by handing over control of the feed to the reward function.

More accurately, especially for Meta products: they completely took control away from you. You didn't even have the option to retain the old, chronological social graph feed anymore. And it was ludicrously profitable. So now the laws of capitalism dictate that everyone else has to follow suit. I now have extensions on my browser for Instagram and YouTube to disable content from anything I don't follow - because I still find these apps useful for that one original purpose they had when they blew up and became mainstream. Why are these browser extensions? Why can't I choose to not see this stuff in their apps? That's the major regulation hole that led to this lawsuit, imo.

It's the same thing you see with people blaming smartphones for brainrot. We've had 15 to 20 years of smartphones with more or less the same capabilities as they have today and for the vast majority of that time my phone didn't make books less interesting or make me struggle to do chores or manage my time. For a full decade or more I saw my phone as a net positive in my life, was proud to work for Twitter and generally saw technology like the Louis CK bit about the miracle of using a smartphone connected to WiFI on an airplane. But in the last five years or so, things have noticeably and increasingly gone to shit. Brainrot is a thing. All my real life friends who are the opposite of terminally online or technical are talking about it. I don't use TikTok but it seems like that is absolutely annihilating attention spans. The topic of conversation over drinks is how we've collectively self-diagnosed with ADHD and struggle with all kinds of executive function.. but also are old enough to remember a time when none of this existed. Complete normies are reading Dopamine Nation and listening to Andrew Huberman trying to free themselves.

I don't know what the exact solution is, but there's at least a simpler time we can point to when we all had smartphones and we were all connected via platforms and we all posted and consumed stupid pictures of each other and it wasn't.... _this_.

We're looking for engineers to come work on Twitter's Cloud Platform team in downtown San Francisco. All of Twitter's stateless services run on our platform, and this means we need to support hundreds of thousands of tasks running across tens of thousands of machines (and growing every day!).

Our platform is almost entirely open sourced via Apache Mesos and Apache Aurora, and we're looking to push on and improve the efficiency, usability and reliability of our platform at our unique scale.

We have the following technologies on our team:

* Mesos - C++ - Isolation and resource management (https://github.com/apache/mesos)

* Aurora - Java - Service scheduler. (https://github.com/apache/aurora)

* Workflows - Scala/ReactJS - our internal Continuous Delivery platform

* Analytics Pipeline - Scala/Python - our data pipeline to feed back to users to help them make smarter decisions about how they use our platform.

* Operations - Python/Go/Puppet/etc. - The tooling we use to do all of this with a pretty painless oncall and only two SREs.

As you can imagine, it's a great team for an experienced generalist who enjoys all parts of building a product, but we also have problems that a specialist in any of these areas would have a field day with.

We're mostly looking for candidates who have at least a couple years experience designing (and implementing) complex systems in a team environment, as well as candidates excited about this space.

If this interests you at all or you'd like more information on the work we're doing, our roadmap or any other questions, please get in touch at dm@twitter.com

We're looking for engineers to come work on Twitter's Cloud Platform team. The majority of this work revolves around developing Apache Mesos[1] and Aurora[2].

Aside from the constant challenge of making sure our platform can scale with the company (we have the largest Mesos clusters in the world), Twitter is in an exciting stage where efficiency (and thus hard performance problems) are becoming more and more important.

Because most of our platform is open sourced, contributions you make on this team will also be felt across a huge number of companies in the community. Mesos is used at companies like Apple and Netflix and Aurora adopters include Paypal, Uber and Electronic Arts. Twitter's commitment to OSS as well as our unique position in terms of platform size gives us a huge opportunity to lead development of key features.

One of my favorite things about working on this team for the last few years has been that I get to touch literally every part of the stack. It's a constant learning process. Mesos is written in C++ and is very heavy on systems, Aurora is on the JVM, much of our developer tooling and automation is in Python, and then we also have a product layer and other tooling that are written in a modern JS stack (React/redux/etc.). So no matter your interests, you can make a huge impact here.

From a product point of view - trying to keep thousands of developers happy and productive in the face of constant comparisons to public offerings like Heroku and AWS, as well as other platforms like Kubernetes, Docker Swarm, etc. is also a huge (but fun) challenge. So if you're a product-focused engineer, this is also a great opportunity.

We have a great team that's based in SF and within six months will be completely onsite. So we're not looking for remote workers right now.

If this interests you at all or you'd like more information, please get in touch at dm@twitter.com for my work e-mail or david@dmclaughlin.com for my personal e-mail.

[1] - http://mesos.apache.org/ [2] - http://aurora.apache.org/

My team is working on monitoring and alerting for all of the different services at Twitter. Zipkin (https://github.com/twitter/zipkin/) is an example of the kinds of tools our team is building right now. The two central components are a dashboard/charting monitoring service as well as our own alerting system.

Most of our infrastructure challenges stem from the sheer number of writes we need to deal with as well as the temporal nature of what we're doing - all of our writes need to happen within certain time periods and reads have to be consistent within certain time-frames to avoid engineers being woken up at 4am due to incorrect data from a dirty read. Given that we're the service which observes all the other critical components - our reliability requirements are also a huge challenge.

The product challenge on this team is making sense of a whole lot of data. So there is a lot of cutting-edge data visualisation work. You have certain services running on thousands of nodes and teams want to use our product to quickly find outliers and scan their dashboards with key metrics. This means you have potentially thousands of timeseries with thousands of data points on the screen at the same time. This is a JavaScript gig where you get to think about algorithms and performance on a daily basis. We're also an internal tool, so we have the option of targeting cutting edge, modern browser features. In reality it means 90% of your time is working on cool stuff and not on getting IE to work.

I think the biggest benefit of working on our product team is that you a level of autonomy which is hard to find on a user-facing product. So if you're the creative type who doesn't want to be micro-managed or told where to push those pixels, I think this is a really good gig.

Right now we're looking for experienced engineers for both infrastructure and product. Our infrastructure is JVM-based and written in Scala, with some Python. Our product is written in JavaScript and we have some Ruby to deal with. Knowledge of these platforms is beneficial, but solid experience and passion for this problem domain is even better.

A systems position: https://twitter.com/jobs/positions?jvi=ospeWfwL,Job A dataviz position: https://twitter.com/jobs/positions?jvi=og12VfwY,Job

The dataviz position doesn't accurately reflect the open rec we have for my team, so don't worry if you don't match the skills exactly.

I work on both infrastructure and product for the positions I described, so if you're interested you can send your resume to me directly at david @ dmclaughlin.com to speed up the process.

Also - we're hiring across the board at Twitter so also take a look at all open positions here: https://twitter.com/jobs

The number of operations and suffering he had to endure still lives with me to this day and I could see why any doctor would choose not to go through this if they had to see such futile attempts at extending life end the same way. They flew in special equipment from the USA that was deemed highly experimental and would cut him open and try it out, only to have to cut him back open a few weeks later to remove what they put in. They tried surgery after surgery in the hopes something would be successful. They did not save his life but I like to think they at least learnt something about a cancer they simply don't see that often, that gave the next person a better shot. When they finally told him there was nothing more they could do, he asked them to stop all further treatment and to let him die on his terms.

The outlook for patients with breast, stomach, lung, testicular, skin or any other form of "common" cancer used to be as bad as pancreatic or bile duct cancer, but these days it's not a death sentence and a lot of people had to lose hard fought battles to get to this point.

Wow. For six years I've been doing "UP + CTRL^A + sudo + SPACE" instead. This is much better.

The anti-spam systems work because they are based on content of emails and properties across the providers entire user-base. Every time you click "Mark as spam" you are contributing data for all users in the service. In a decentralised service, even if people agreed to submit all their emails and information for the greater good (which they probably wouldn't), the data still needs to be centralised somewhere and secured by experts. The blacklist/whitelist of notorious spammers and servers needs to be maintained somewhere. You end up having a committee to do that, an elected/trusted group of people and they need to deal with appeals, etc.

Two:

If the logic for blocking spam were public, don't you think that would make it much easier for spammers to circumvent?

Edit - I can't reply to the user below. Must be some HN feature. But the logic for accepting an email is essentially a decision tree, it is based on data and evolves over time. It is a very different problem from something like encryption.

At work we had a researcher from Yahoo Mail come in and give a presentation on the machine learning techniques they use to try and stop spammers abusing their mail servers. It was eye-opening to learn just what kind of hourly battle they face to keep spam out of their systems and the ways they are trying to combat it. It was even more enlightening when the presenter told stories about the problems that machine learning can't solve - like people within the company being bribed to whitelist spam companies based in Vegas.

On the surface it's such a simple problem, and I'm sure anyone who's tried to prevent their web application's outgoing mail being marked as spam by the evil corporations of Yahoo and Google will have had the desire to go write a blog post saying what a crock of shit the whole thing is and how they would never take part in that. But here's the thing - those systems are in place because if they weren't, email would be a completely useless form of communication at this point.

The people sending spam make _millions_ of dollars abusing a system which is popular because its open and based on trust. That kind of money combined with greed gives people all different levels of drive and incentive to get their emails about bigger penises and viagra through to your inbox. Every time they prevent one form of attack, these guys will create a new one.

To do this they do things like install mail servers on unsuspecting user's machines, specifically targeting Yahoo/Hotmail/Google users because their IP will obviously need to be trusted by those companies. They will also hack into other people's private mail servers. They will spoof email headers and pretend they're someone else. They will hire people, experts, who will find new ways of breaking in to servers they detect as having mail servers running on them. All this just to get past the spam filters and prevention that make email a useful form of communication to begin with.

And let's forget the people who couldn't set up their own mail server for just a second. I like to think I know what I'm doing. After installing Postfix and jumping through all the hoops to get my emails whitelisted by Gmail and making sure I didn't have an open relay on my mail server, you know what happened? Someone managed to hack in by brute force anyway. I only noticed because of the _millions_ of automated replies that were coming in every day from dead email accounts or people that were out of office.

Now, I could have worked hard to fight this. I could have did something other than changing my passwords and hoping they didn't get crack them again. But the point is - I only ran a mailserver to get email delivered to me on my personal domain. I didn't want to have to fight and battle and dedicate myself to solving this problem. I wanted to take this thing for granted. I just wanted to send and receive email. Instead bad people could not only sit there and read all my incoming mail - but they could use my server to spam people and get me blacklisted and blocked from so many other services I worked so hard to be trusted by. And they did all this without even specifically targeting me. I was a statistic to them, someone who simply didn't know what they know. In the end, I moved my personal mail account to Google Apps, free of charge. Problem solved.

By using Gmail or Yahoo Mail or Hotmail - you are almost definitely more secure than setting up your own mailserver. You have people paid hundreds of thousands of dollars a year working full time to make sure your data is secure. I mean if privacy is your reason not to use Gmail, then I hope for your sake your mail server is secure. Maybe you think it is. I know I did too.

And all these people complaining about advertisements based on the content of their emails. Yahoo Mail had a team of like 30 people just doing _research_ on how to stop spammers. Then all these other people working on support. How does that service get provided to us _free of charge_ without advertisements or some sort of monetisation? I know in some people's heads they think it's literally just a Bayesian classifier and some hand-coded rules, but it's so beyond that.

And of course, let's not forget the fact that a lot of people would not be able to set up their own mail server anyway. Maybe you don't need them, but Hotmail, Gmail and Yahoo Mail enable hundreds of millions of people to communicate _for free_ with other people around the world that otherwise wouldn't be technically competent enough to buy a domain name and set up a local mail server. It lets you communicate with them too, because they don't get frustrated wading through hundreds of spam emails just to read the good stuff.

And that system only works because we have good guys that are fighting the bad guys who want to ruin it for the rest of us. And this is just the one example of email. Which has all this decentralised and open properties that you desire. I am reminded of Diaspora when they released a first beta of their code and it got absolutely torn to shreds for security reasons, and we haven't heard much since.

The real world sucks.

That's why I think it might be a good idea for you to go work for Google.

It is similar to something like Blueprint (http://www.blueprintcss.org/), which I have used for my prototypes with a lot of success, but just taken much further.

In my own case I disliked Java so much in my first year of University because I couldn't understand why there was so much effort just to get this little black screen to print "Hello, World."

I would go on but I actually already wrote about this a couple years ago on Reddit: http://www.reddit.com/r/programming/comments/84c90/i_fear_as...

I have been flirting recently with a return home to Scotland (from Berlin) recently, and have found it extremely difficult to find any interesting opportunities on par with what I'm doing right now. The quote above reminds me why I had to leave to stay sane.

Completing the Khan Academy playlists for Linear Algebra and Probability would be pretty useful if you want to be prepared in time for October.

I would rephrase this to learn a new programming paradigm. There are fundamental differences between static typing and dynamic typing, object orientation and functional, manual memory management and garbage collection. There are also "pure" single-paradigm languages and multi-paradigm languages. If you learn the same type of language multiple times, you're really just learning new syntax and probably a couple of extra idiosyncrasies, so it's important that you pick languages with fundamental differences.

Compare going through this learning path:

Perl -> PHP -> JavaScript -> Python -> Ruby -> Node.js

To going through this:

Java -> C -> Scheme -> JavaScript -> Erlang

For example.

http://blog.tmorris.net/anti-intellectual-euphemisms/

Specifically:

> using the word complex, unnatural, academic, “your world” or unintuitive to mean “I am not able nor am I willing to invest the effort to come to to understand this.”

Other than those people:

The blog author I quote above is one of the many "PL gurus" you speak of that rip into Scala because of its various deficiencies when compared to the likes of Haskell. The ones I am smart enough to understand mostly revolve around the type inference and type erasure problems. You mentioned those but I have already run into issues where I did care about them so I don't think its fair to dismiss them as you did.

The amount of hyperbole that comes from elements of the Scala community on actors I think is a cause of a fair amount of vitriol, mostly because actors are not a silver bullet and come with their own host of problems. Akka is trying to solve some of those problems of course :)

And of course the lack of tools. It's hard for me to talk about this because I loathe IDEs. So far I have been writing my medium sized project entirely in vim + NERDTree and it's been great. I imagine with enterprise scale projects I would start to miss Eclipse though.

http://speedtest.10-fast-fingers.com/

You reached 395 points, so you achieved position 14664 of 1148922 on the ranking list

You type 588 characters per minute You have 98 correct words and you have 6 wrong words

Which is close to 99th percentile, although that website may have a bias towards slow typists. What speed would a touch typist expect?

The problem I have with your post is that you are repeatedly mistaking the high level idea of an ORM with the (seemingly) Spartan implementations that you have used.

Here is an ORM that provides support for automatically profiling the performance of queries over a period of time:

http://squeryl.org/performance-profiling.html

Sample output:

http://squeryl.org/profileOfH2Tests.html

I cannot begin to tell you how much time this has saved me when optimising performance of my webapp.

Note that that particular ORM also has the advantage of having type safe queries - i.e. it can tell at compile time if there's a syntax error in your query (subject to bugs in the ORM :)) - even in dynamically generated queries. In practice this is a fantastic feature as it is so much safer than building up SQL queries with string manipulation and dealing with multiple code paths that depend on user input. The test paths alone in such code (even if you have a "query builder" layer) are the stuff of nightmares.

There are many features missing from Squeryl though that I've had in other ORMs because it makes different trade-offs. But this is what you do when you choose a library, and it's important to understand what trade-offs you're making upfront... otherwise you might find yourself writing off an entire approach to software development as an anti-pattern because you picked the wrong library.

ORMs reduce code duplication. They speed up development, especially when you're treating the underlying data storage as a "dumb" datastore that could just as easily be sqlite or H2 as MySQL or Postgres.

As for ORMs having some sort of negative impact on the queries sent to the underlying database - it really depends on what ORM you use but any ORM I've used had support for pre-loading relationships in advance when required, removing that N+1 problem.

I also want to add that I wrote an ORM for the first company I worked for and when it was finished it was a drop-in replacement for 90% of the queries in our application - and I mean that literally the SQL generated by the ORM was exactly the same as the SQL being replaced. The queries that it couldn't replace (mainly reporting queries) already had an aggressively tuned caching layer in front of them anyway because they were so hairy.

But the real point is this: the performance of the ORM didn't really matter because we were a database driven website that needed to scale - so we had layers upon layers of caching to deal with that issue.

And that is an extremely important point - the way ORMs generalise a lot of queries (every query for an object is always the same no matter what columns you really need) lends itself to extremely good cache performance. Take the query cache of MySQL for example - it stores result sets in a sort of LRU. If you make n queries for the same row in a DB but select different columns each time - you store the same "entity" n times in the query cache. Depending on how big n is, that can cause much worse cache hit performance than simply storing one representation of that entity and letting all n use cases use the attributes they need.

Now, relying on MySQL's query cache for anything would not be smart, but replace it with memcached or reddis or whatever memory-is-a-premium cache and the same point stands. Another example to drive the point home is a result set where you join the result entities to the user query so that you can get all the results back in a single query. In theory this is a great way to reduce the number of queries sent to your DB but if you have caching then there are many times where you could have very low cache hit ratios for user queries since they tend to be unique (for example they use user id) but where you could still get great cache hit performance if certain entities appear often across all those result sets by leaving out the join and doing N+1 fetches instead.

ORMs prevent you from scaling as much as using Python or Ruby over C does.

So I guess that leaves the point about leaky or broken abstractions. Well I would never claim that you can abstract across a whole bunch of databases anyway, I think that's a ridiculous claim that most ORMs make. These types of abstractions when people try to hide the underlying technology are really just a lowest-common-denominator of all the feature sets. So if you chose some technology because you really wanted a differentiating feature then most likely you will find yourself working against such abstractions. Interestingly enough, the dire support for cross-database queries which are perfectly legal in MySQL but not in other vendors is the reason I had to roll my own ORM. But the productivity and maintainability benefits were well worth it.

So yeah I guess what I'm saying is: premature optimization is the root of all evil, there are no silver bullets and performance and scalability is about measuring and optimising where needed. And finally: ORMs are not an anti-pattern.

At my previous company we had these "auto-login" links in emails and they are extremely powerful.

But maybe once every six months people would call or write in and say "I forwarded a job posting from one of your email alerts to a friend and they had full access to my account!" and we'd have to revisit the issue again, but the conclusion was always the same - we were getting absolutely ridiculous user engagement from emails because of this feature and this was too valuable to give up.

Before I left the solution I had started to push was to introduce a new intermediate user level - "logged in but not trusted" - to the standard logged out/logged in two-level ACL. The basic implementation would have looked like this:

1) A logged in but not trusted cookie is set on both manual login or auto-login from marketing materials. It allows us to assume that this is user X and they are taking action Y on website Z. It also allows the user to receive the user logged in view where that UX has been tweeked to minimise effort for logged in users.

2) A logged in and trusted cookie is only set on an explicit manual login, and is required to perform _any_ write operation as well as to read certain sensitive information.

Where the practical implementation gets difficult is you really need to refine when to require the trusted cookie - at what point in your UX - to keep the engagement high. It will almost definitely go down, you just want to minimise that.

For an example, say you're a service like LinkedIn. You send emails to your users whenever they get a private message and you want to make it easy as possible for that user to reply because recruiters getting candidate engagement happens to be one of your key metrics. User clicks on the message in their email and instantly gets a login page, they might have been 50/50 about engaging with this recruiter so now that you presented an obstacle they just close the tab and get back to what they were doing. Alternatively, you show them the message from the recruiter and allow them to type up a reply and only ask for a password confirmation when they hit send, and it's possible your engagement will go up.

It requires more thought and is surprisingly tricky to implement once you get past the really easy "read-only" versus "write" type security checks, but it seems to be the way things are going.