I uploaded most of our Workspace setup here: https://github.com/jschaf/bazel-postgres-sketch. The tooling is a bunch of Go to manage the Postgres process. Basically, give it schema files and receive a running database with a tear down command.
We make temp instances of Postgres quickly by:
- avoiding Docker, especially on Mac
- keeping the data dir on tmpfs
- Disable initdb cleanup
- Disable fsync and other data integrity flags
- Use unlogged tables.
- Use sockets instead of TCP localhost.
For a test suite, it was 12x faster to call createdb with the same Postgres cluster for each test than than to create a whole new db cluster. The trick was to create a template database after loading the schema and use that for each createdb call.
Oso | Engineering Leader, Software Engineer, Developer Experience Engineer | New York City (NYC) | Onsite or Remote
Old problem, new $25B+ market
Companies like AWS, Stripe, and Twilio have demonstrated that if a technology is not core to your value proposition, you should offload it. Still, every engineering team builds and rebuilds one piece: *authorization*, how you control who has access to what in your app. You’ve probably started with something quick 'n dirty – some IF statements and roles in a database...until you need to add more features, and more features. And inevitably you band-aid onto this system until you have to do a big refactor. Have you seen this before?
We're changing this picture and in doing so, we are creating the next $25B+ dollar market: the authorization market. We’re on a mission to create the global standard for authorization. Our vision is that in 10 years engineers will spend 1/10 the time and brainpower they spend on authorization today.
Why now?
This is a once-in-a-career opportunity to join a company at a stage late enough that the problem and solution are de-risked, but early enough that you can shape the product, company, and the market.
At Oso, we give the written word the same level of attention and respect as code, because we know that our audience — developers — values high quality writing. Every engineer on the team writes. And if you are an engineer that can write well, this role is for you – you will be celebrated, respected (and paid the same as the other engineers on the team).
We are based in NYC and hiring folks remote or onsite.
Y Combinator (yes, the people who run this site) | Software Engineer | Anywhere in US | REMOTE | Full-time
Y Combinator has a small ~10 person team that builds all the software that runs YC. We don't hire for this team very often, but we're looking to hire a couple of people now. Several of the people we've hired have come from prior monthly Who's Hiring threads.
This is a great role for somebody who loves startups and is interested in being part of the YC startup community, and wants to own projects from start-to-finish.
It could also be a great role for someone who's interested in doing a startup in the future (though that's certainly not a requirement). If you're interested in getting funded by YC as a founder in the future, but you don't have a startup that's ready for that yet, joining the YC software team could be a great step. Several former software team members are now running YC startups.
We work primarily in Ruby on Rails and React (learning on the job is fine though), and we spend most of our time coding. That said, we encourage everyone to participate in all of YC -- read applications, join our batch talks, help out with Demo Day and speak up on the projects you'd want to work on.
The software team you'd be joining has about ten people with lots of collective years of start-up and big company experience, so you'll get the best of both worlds: moving fast and shipping and strong teammates/mentors to help you learn. About half of us are YC alums and several of us are parents. We're open to people 2+ years out of school or with 10+ years of experience. Lastly, the work-life balance and compensation are great, and you get to work with people across the company.
YC is fully remote and is hiring people anywhere in the US. We plan to reopen optional, part-time in-person offices in the SF Bay Area in the future for employees in the area.
There are two specific product teams we're hiring for at the moment. The first is https://www.startupschool.org/, which is the world's largest course about startups. The second is the YC admissions team, which is the team that builds software that helps us decide which startups to invest in.
If that sounds interesting, apply below or email me: jared@ycombinator.com
On a note related to eye strain, but unrelated to blue light: the best solution I've found for eye strain is to wear reading glasses (or if you are near-sighted, glasses with an additional diopter or two) even if you don't need them. With the correct SPH value, the screen will be at optical infinity and your eyes will be fully relaxed.
Another pro-tip unrelated to the article: if you like to read at night in bed but find LCDs/OLEDs bothersome, I recommend trying red-on-black text. Particularly nice for glasses wearers who are bothered by chromatic aberration.
---
On the subject of this article: does anyone have a translation of the study itself? While I'm not at all surprised that there is no retinal damage, I'm very surprised that they found sleep was unaffected. Blue light does more strongly activate ipGRCs, after all.[0] And that clearly suppresses melatonin.
I'd also like to know if by blue-light blocking lenses the article means the ones that block "high-frequency blue" light (Zenni brands these as "Blokz Blue Blockers") which are probably useless because the violet/UV light they block aren't actually produced by most displays, or if they mean the orange-tinted glasses that obviously cut into blue light.
I’ve never been more motivated to quit than when on the other side of this. The thing that already exists only seems from a distance like it does what I need. It makes different trade offs, it’s poor quality, the team that owns it is far away, and they “agree in principle” with all my proposed changes but “it’s a question of resources.” On smaller projects I have sucked it up, and wow. Something special about tying yourself up in knots to do work you’re ashamed of in the end.
On the bigger projects I’ve always managed to wriggle out, thank god. Usually by building something domain specific so as to avoid the appearance of direct competition. Language and branding are crucial here. If your design doc uses the words “rules engine” half the company perks up. Why aren’t you using ours? On the other hand “configuration” is totally fine.
Retool (https://retool.com) might be what you're looking for on the front-end. It's built for engineers, so it abstracts away a lot of the boiler-plate stuff (e.g. fetching data from an API, showing errors if it fails, showing a loading indicator on the button when the REST API is in progress, etc.). But you still write code for the custom bits (e.g. if you want to hide a component for certain users).
It's something we started working on a few years ago before low-code was a thing, haha. It's funny to see what you work on become a buzzword, haha. If any of you have any thoughts / feedback, please let me know! (HN, honestly, has been the main source of feedback for us as we've been working on it.)
We make temp instances of Postgres quickly by:
- avoiding Docker, especially on Mac
- keeping the data dir on tmpfs
- Disable initdb cleanup
- Disable fsync and other data integrity flags
- Use unlogged tables.
- Use sockets instead of TCP localhost.
For a test suite, it was 12x faster to call createdb with the same Postgres cluster for each test than than to create a whole new db cluster. The trick was to create a template database after loading the schema and use that for each createdb call.