Just like with everyuuid.com, you too can explore the space of all possible Claude code buddies. And find legendary shiny wise ducks. And install them by patching your binary on macOS.
That's a great question. We haven't done the calorie calculations yet but they're full of healthy fats. Each meal is about three servings, if that helps any.
We use produce and groceries we were already selling as parts of our kits, as well as partially prepared food we prep/cook in-house. 80% of what we sell is made within 200 miles of SF.
We also assume you have things like olive oil. Hah.
Also worth mentioning is that we hold onto produce for usually less than 24 hours from the farm to your door.
Let me know if you'd like a beta invite to try the kits out. (Or to talk Operations Engineering (my team), it's fascinating and full of classic compsci problems)
This is a variant of "should you compress or encrypt first?"
Compression relies on pattern matching, and compressed size will leak details about what you compressed, even if that result is encrypted. (Unless you then pad the encrypted size, but then what was the point of compressing? I can see some more or less secure ways to do this like establishing a compression ratio/bandwidth/entropy limit, then padding and achieving that constraint so each encrypted payload looks more or less the same, but latency sensitivity makes this difficult)
In the case of VOIP, the codec uses a lookup table for distinct parts of speech (tch, sp, buh, etc). Then "all it has to send" is table cell numbers around (certainly not all). On the receiving side, you just look in your speech table and reconstruct.
These values have distinct output patterns, particularly when compressed. If you can guess better than 70% of the time (I forget the exact number they achieved) what table value was used, then reconstruct it, you can listen in on what they're saying, without having to break the underlying encryption.
Voice codecs are also awful at encoding music which may explain why when you're on hold, the hold music may just be dropped and replaced with white noise because it's reached some bandwidth cap. C.f. video encoding and falling snow.
This is wonderful. I read the whole series in one sitting. It actually made video codecs feel way more approachable, rather than some patented black box magic I'll never understand.
It also reminded me of a recent article talking about how you can break audio codecs by guessing which quantizer was used by the packet, then using it in reverse to produce speech! Which I suppose is obvious in retrospect, that lossy codecs are trying to compress data by making it perceptually similar, whatever the domain.
I also appreciated the ties to video game networking. Gaffer on Games has had a long-running series on designing multiplayer networking protocols with UDP and you two approach bit-shaving very similarly (unsurprisingly I suppose - it's a very specific process with its own tools).
Recently I've been trying to find people to do IT tasks, but we're not at the full-time IT level, we're still a small business.
Stuff like:
- Setting up a RAID0 dev ubuntu box and transferring my data to it
- Setting up a VPN to EC2 for both our office (using our router that does VPN) and our personal machines (for when we're away from the office)
- Diagnosing office internet issues
This fits in very neatly with Casey Muratori's "Compression Oriented Programming" which is essentially Write your usage code first, keep YAGNI in mind, then Refactor.
I was once asked in an interview whether, on a new project, I would start with a monolithic app or some sort of SOA. ("Microservices Architecture" is the new SOA)
I answered that I would start with a monolith because usually you're trying to find product/market fit as quickly as possible, and having an SOA would likely slow you down due to its upfront cost. (How many services? Any redundancy? What do they do? How many databases? How do you keep them up? How do you diagnose when they're failing? etc)
They responded that they always do SOA, that the benefits are clear, that monolithic apps are idiotic, etc.
I didn't want the job... but I was confused about our differing opinions.
What I've learned since then is basically: are you constructing a building, or making an art installation?
Construction is thousands of years old. Contractors have huge tables of how long each part of the process takes, in what order, down to the quarter-hour (in some cases) and are fairly accurate in their estimations. (They're still hilariously wrong on occasion either in time or budget, building anything is pretty difficult)
In this case, architecting SOA would work out since you've done it before. You know about how long it takes, what the pitfalls are, what support infrastructure you need, etc.
When you're making art, making something new, with new materials, without a manual, with only some best practices in mind, time becomes essentially unbounded.
Upfront architecture in this case would be poorly suited to the situation - you'll probably end up changing it a lot, and each time you introduce a bit of "rigor" to the system it becomes a bit more difficult to change. Especially over socket boundaries and different API versions.
I also feel like bad code has a survivorship bias - you only hear about it because the company took off. To get the company to take off, the code perhaps was necessarily rushed just so the company could stay around long enough to make money.
"Ah, but if we could have done it right in the first place!"
You don't hear about the companies who die, no matter the quality of their code.
We're making higher education more affordable: Helping students compare their bookstore's prices to those of its online competitors; Giving recommendations on close-to-market bookstore prices; Getting professor book choices in faster; Helping bookstores buy and sell books on a level playing field.
We guide every stage of a used book's life. We help students save money, and bookstores become and stay relevant, competitive, and transparent.
Metrics: 350 colleges and universities, serving 4.5 million students, tracking ~200k unique book titles, integrating with 7 vendors & 20 retailers, raising the "win rate" for bookstores to 80%, and dropping prices across the board. 23 employees, 3 part-time. 2 dogs. 5 cats. 3 children.
Profitable. Growing.
Code: Ruby, Rails, JS (Coffeescript/Backbone), Clojure for Hadoop, MySQL on RDS, AWS w/ Chef. We love experiments and go with what works! We also love making a stable, solid product which is why we have a ton of metrics and a one-click build pipeline.
What's in it for you: A great team and company culture, benefits (even for part time!), a laptop, unlimited books, BART pass, pool table, healthy (and un-) office snacks, great conversation during our yearly company work-cations, and hard, challenging, fulfilling, good (in the public sense) work.
Message us if: You want to help make education better. You've got strong Rails knowledge (several years worth), solid testing practices, a good head for architecture, and know enough JS to help out on front-end. A stats background, experience with Hadoop and knowledge of scheduling algorithms would be awesome, but not required.
How to get the job: Write a cover letter that speaks to why this job might fit with you, and how you could help us out. The first step is a phone screen to solve a small programming problem. Then we'll schedule an on-site interview for a few hours, where you'll present for 15 minutes on any topic you'd like, have you walk through some of our code with us, and then deep-dive into the whole stack. Also we'll ask you some historical behavior questions, not logic puzzles. Then we'll make you an offer, and you'll accept and we have a new employee party!
(And now a personal message from me!)
I came for the people. I've been at a few companies, I've written a lot of code, and in the end it's who you spend every day with that matters and shapes you.
The problems of higher education are many, and this is just one avenue of attack, but it's a fantastic start. Books are simply way too expensive.
What surprised me the most when joining was that everyone in the company is very kind, that their customers LOVE them, and everyone is highly performing. This doesn't mean that everyone just works long hours and burns out - no, it seems everyone is careful about being at their mental peak and intend to stay that way. This informs every aspect of the culture here: planning, creating, getting feedback, paying off technical debt, retrospectives, always thinking about how to work better and more easily, time off, going to conferences, health care, 401k. Everything.
It's like this company wants to stay around for a long time or something.
* Rails/JS Product Focus - FULL-TIME or HALF-TIME with benefits [work on your side projects!]
Verba thinks that college should be more affordable, so we help bookstores get books faster, cheaper, and sell them competitively.
We guide every stage of a used book's life. We help students save money, and bookstores become and stay relevant, competitive, and transparent.
Numbers: 450+ colleges and universities (and more beating down our door), tracking ~200k unique ISBNs, serving millions of students ("rush" season, when students are buying, means 100 requests/s), raising the "win rate" for bookstores to 80%, and dropping prices across the board. 19 employees, 3 part-time. 2 dogs. 5 cats. 3 children.
Code: Ruby, Rails, JS, Clojure and Impala for Hadoop/EMR, MySQL on AWS w/ Chef. We love experiments and go with what works! We also love making a stable, solid product which is why we have a ton of tests, metrics and a one-click build pipeline.
What's in it for you: A great team and company culture, benefits (even for part time!), laptop, books, BART pass, pool table, somewhat healthy office snacks, great conversation during our yearly company work-cations (http://verbasoftware.com/vacay), and hard, challenging, fulfilling work.
Message us if: You want to help make education better. You've got strong Rails knowledge, solid testing practices, a good head for architecture, and know enough JS to help out on front-end. We prefer slope over y-intercept.
How to get the job: Write a cover letter to [email protected] that speaks to why this job might fit with you, and how you could help us out. The first step is a phone screen to solve a small programming problem. Then we'll schedule an on-site interview for a few hours, and have you walk through some of our code with us. Also we'll ask you some historical behavior questions, not logic puzzles. Then we'll make you an offer, and you'll accept and we have a new employee party!
* Rails/JS Product Focus - FULL-TIME or HALF-TIME with benefits [work on your side projects!]
Verba thinks that college should be more affordable, so we help bookstores get books faster, cheaper, and sell them competitively.
We guide every stage of a used book's life. We help students save money, and bookstores become and stay relevant, competitive, and transparent.
Numbers: 400 colleges and universities (and more beating down our door), tracking ~200k unique ISBNs, serving millions of students (rush season means 100 requests/s), raising the "win rate" for bookstores to 80%, and dropping prices across the board. 19 employees, 3 part-time. 2 dogs. 5 cats. 3 children.
Code: Ruby, Rails, JS, Clojure for Hadoop, MySQL on AWS w/ Chef. We love experiments and go with what works! We also love making a stable, solid product which is why we have a ton of tests, metrics and a one-click build pipeline.
What's in it for you: A great team and company culture, benefits (even for part time!), laptop, books, BART pass, pool table, somewhat healthy office snacks, great conversation during our yearly company work-cations (http://verbasoftware.com/vacay), and hard, challenging, fulfilling work.
Message us if: You want to help make education better. You've got strong Rails knowledge, solid testing practices, a good head for architecture, and know enough JS to help out on front-end. We prefer slope over y-intercept.
How to get the job: Write a cover letter to [email protected] that speaks to why this job might fit with you, and how you could help us out. The first step is a phone screen to solve a small programming problem. Then we'll schedule an on-site interview for a few hours, and have you walk through some of our code with us. Also we'll ask you some historical behavior questions, not logic puzzles. Then we'll make you an offer, and you'll accept and we have a new employee party!
> Want to lose weight? Eat fewer calories than you burn. Want to gain muscle mass and tone? Work out regularly. Etc.
This is why research about diet is important. Animals are complex systems, and rarely are "simple" explanations correct (or correct enough). What we know about about food and how we process it is remarkably incomplete considering how important it is to supporting life.
So with that in mind, I'm excited that the prevailing view of diet, nutrition and health in our society for the last century or so is getting challenged, just as science should be challenged and overturned ("disrupted" in SV parlance) in the face of new, better, more sound evidence.
What's coming out of this new research is that, perhaps, the mechanisms concerned with storage of energy (fat) are unconcerned with the rest of what's going on in the body. That perhaps the reservoir of energy available to your muscles and brain to burn, intentionally and with conscious control, are in competition with a sometimes overly-aggressive energy storage system.
It reminds me of how the U.S. does income tax - it comes directly out of your paycheck, before you can even think of spending it. Even if you wanted to go negative, the Govt still gets theirs.
And let's say that the regulator of storage vs. use is controlled by the kinds of food that you eat... that, stretching this metaphor, your income tax bracket was affected by where you worked, or where you got the money from.
Anyway, a more complete picture of how our bodies actually function is a good thing, and the more people try these "fad diets" is actually a boon for the people studying them. ;)
(As an aside - the gluten free craze has helped a lot of people who actually have celiac disease to have more options in eating things that don't taste like crap, or, you know, eat out once in a while.)
We offer flexible work schedules (half time, full time, anywhere in-between) with benefits.
1. A. In my experience it's hard to find unless you're contracting or have extremely rare knowledge.
1. B. We're a rails shop, (mostly) b2b edtech.
2. Not at all just greenfield. Having flexible schedules means that you have to be realistic with scheduling and expectations. You have to work out what will work best with the team and when they need to synchronize with you.
In some cases your work is orthogonal to main development critical paths, so the need for synchronization is less (still important though for staying synced with the culture).