I like the ad on the whole, but I was a little upset about the destruction of seemed like a perfectly good guitar. I play the guitar as a hobby.
But then again, rock bands have been making me upset by smashing guitars on stage for decades now. And these are the same kind of musicians who are apparently outraged now.
Can sort of understand the discomfort, but musicians have been smashing their own instruments for dramatic effect for a while now.
We serve the movie industry at Qube. Once a movie is made and mastered it’s a 300GB stack of encrypted files, and the product that I work on sends that movie to thousands of theatres all over the world. Over physical hard drive copies, satellites and broadband downloads (ask me what our bandwidth bill is when you interview). Multiply that for many movies each week and trailers and ads as well.
Then we use asymmetric key infra like HSMs to securely receive and re-encrypt the movie’s keys targeted at each specific device that’s playing the movie. All done so not even we ourselves can compromise or decrypt the movies we’re sending.
We also design and make the servers that play the movies themselves; along with more public facing systems like high volume ticket booking, box office systems and movie databases.
Our tech stack is Go and React, with a little bit of Java, Ruby/Rails and Node. Databases are Postgres and Redis, with lots of AWS services like SQS+SNS, S3 etc.
I posted a couple months ago and wanted to apologise to everyone who applied from outside India - we’re not equipped legally to hire globally just yet.
Simple no-bullshit work-from-home culture with good work life balance - we’ll set OKRs periodically and you’ll be left in peace on work with weekly checkins, with the option to ask for help at any time. We do have an on-call rotation, since thousands of theatres stop working if we go down, but we jealously guard our time to make sure we only stay up late or work weekends in real emergencies.
Many of us have kids and families, and we respect each other’s time and boundaries. We also have an almost even gender ratio and don’t discriminate on any basis, although written and spoken English is necessary to work effectively.
iOS would likely kill the app as soon as it got out of hand, and rely on the state restoration hook to bring back the state as the user left it. Normal macOS apps don't have that, though.
If the leak was in some part of the system, maybe a problem, but I'm sure they test pretty rigorously, and get enough crash reports to figure things out fast with that many devices in the wild, all in pretty constant use.
"lost $25M" doesn't necessarily mean they set it on fire. If the wording is changed to "invested all their revenues and a further $25M of raised or borrowed capital", wouldn't that make more sense?
The way these arguments are usually phrased doesn't do the company justice. Amazon "lost" money for decades because they were building giant and ambitious infrastructure, not setting burning in on executive parties.
Similar experience here. People want "growth", but that's an abstract word. In the context of a employer-employee relationship, that usually means growth in compensation and rank from the employer, and the enablement of some kind of valuable work from the employee.
Managers need to align the two, if that's not done well most of these goals become nonsensical. As one example someone had ML as a goal despite it not being used in the company, so I found one part of the system where it would be useful and put them on that part time. Product got better with an ML component, senior management was impressed with the result and new capabilities, employee got to learn the new hotness, also got promoted.
Doesn't always have to be so much win-win-win all around, definitely needs effort put into alignment.
Yeah, Rails doesn't currently strongly analyze what it needs to do. Based on my experience with it, I remember that it either 1) checks out a connection at the beginning of the request into a thread local / request context and releases it at the end of the request, or 2) checks out when the first active record work is attempted, and releases at the end of the request.
Either way, if you have a request flow of 1) DB read - 50ms 2) Network request - 200ms 3) DB write - 50ms, you can see that the connection is idle for 2/3 of your request handling time. Rails does this so that if you start a transaction in step 1 you can commit it in step 3. All your writes are also automatically wrapped in a transaction, I think.
In Go on the other hand, step 1 will checkout and release the connection immediately, and step 3 will checkout and release. So the connection isn't idle locked for the 200ms in step 2. But if you don't remember this explicitly and try in step 3 to finish something (transaction/advisory lock/prepared statement) that you started in step 1, you're screwed.
So Rails saved you from doom by holding onto a connection for an inefficient extra 200ms, and Go shoots you in the foot in the name of efficiency.
Isn’t sidekiq working off Redis? You might be adjusting the Redis concurrency instead. And if I remember correctly even with sidekiq you’re still using normal Rails and ActiveRecord, so a process that’s running 25 sidekiq jobs simultaneously is going to need 25 active record DB conns from the database.yml. I doubt the sidekiq config is overriding it in some way.
But basically if your sidekiq workers and app servers are using the same database.yml values, you’ll need to set the greater of the two on both. I assumed you have different settings on app servers and workers.
It depends on how knex is used. If it gives you a method to run a DB query, and internally checks out a connection, runs the query and releases the connection, then it’s already doing exactly what would happen with a proxy.
If it or you are setting up middleware to start a transaction before every request, or put a checked out connection in the request context, that’s a lot of possible inefficiency. If you really want the convenience this offers, and have request flows that do a lot of other non-DB work, you’ll need a pooling proxy.
If your request handling is very database heavy and does nothing else, then automatic request level connection check out is still efficient, even without a proxy. Even if you have a proxy one real connection is going to be working the entire duration of the request anyway.
I'm not familiar with specific implementations, but from what I've seen with Redis and Postgres clients there's always a reconnect hook of some sort, which I assume pooling proxies give you as well. We've had plenty of broken pipe errors and we just reconnect.
Have edited to "These systems allow you to make as many database connections as you want without worrying about management, because the connections..."
Yeah, the Go decision was more because of familiarity and some tooling I have available for Dynamo. The real problem I was tackling is zero marginal cost multi tenancy. Right now a new Ghost installation costs 500MB on a disk and 1GB in RAM, and I would like to to cost one row in an existing database instead.
And yeah, don’t think the $5 / month is sustainable for a company, but for a solo founder it might work. Of course, that might be a classic case of this time it’s different.
I was trying to make it multi tenant, move it a serverless database like DynamoDB, and rewrite the server in Go.
I’m trying to make a Ghost hosting service that’s free / $5 a month for personal use. I’ve figured out a way to make the economics work with the existing 500MB disk + 1GB RAM requirements, but it would have been a lot easier with Go and Dynamo.
Thanks a ton to you and the team for the work you’re doing. I think you’re making a fantastic system, and want to make it available to more people as a personal blogging platform. I just wish it could run multi tenant or with lower memory needs.
I don’t suppose making it easier for others to compete with the official Ghost revenue model is a priority, so I doubt this is anything you’ll want to take up. But I’m happy to share revenues on this - I just think Ghost should be a lot more accessible to individuals around the world.
Will edit that, yeah. I was am struggling to explain the GIL without having to talk about the GIL, because if open that can of worms it becomes a much longer article and goes off track.
All of the GL and event loop based stacks go multi threaded a the lower library levels, really. Will think about how to explain that. And will move Python off that general category.
But then again, rock bands have been making me upset by smashing guitars on stage for decades now. And these are the same kind of musicians who are apparently outraged now.
Can sort of understand the discomfort, but musicians have been smashing their own instruments for dramatic effect for a while now.