perplexes

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.

RE-PC in Seattle is like an indoor tech junkyard.

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.

Fixed - send me an email :)

Oh, totally - it's one of the very next things we're implementing (personalization/recommendation, etc)

I work for Good Eggs. If you you live in the greater bay area want a dinner kit with local ingredients and focus on minimizing waste and packaging...

https://www.goodeggs.com/sfbay/dinner-kits

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.

http://www.sfchronicle.com/food/article/Good-Eggs-hatches-ne...

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)

Is there a recording of the signal available anywhere?

Here's the paper - https://www.cs.jhu.edu/~cwright/oakland08.pdf

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).

Anyway, thank you! I learned a lot.

https://news.ycombinator.com/item?id=10364197

"Twitter has over 4,100 employees in more than 35 offices"

I'm surprised no one has mentioned Esper yet: http://www.espertech.com/esper/

Esper does exactly this - you run streams of events over it and it continuously executes SQL to see if it matches. If so you can:

- run code

- make new streams

- store the results

Esper's been doing this kind of thing for 9 years now.

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

https://vendorform.com/ is trying to do this for the college store industry

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.

SENIOR RAILS DEVELOPER, San Francisco, CA

FULLTIME or HALFTIME with benefits.

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.

JOIN US AND MAKE EDUCATION GOOD.

VERBA - San Francisco, CA

http://verbasoftware.com/

jobs@verbasoftware.com

* 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 jobs@verbasoftware.com 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!

Ah, another DabbleDB! I hope you stick around longer. :)

http://en.wikipedia.org/wiki/Dabble_DB

VERBA - San Francisco, CA

http://verbasoftware.com/

jobs@verbasoftware.com

* 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 jobs@verbasoftware.com 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).

We make a few (mostly B2B) SaaS products for college bookstores. Namely:

Compare, where students come to buy their books through a portal that compares their book store's prices to their online competitors.

Compete, which helps bookstores buy and sell books online and price them competitively (for buying from/selling to students).

Collect, which helps them get their book selections in from faculty.

Each of these are part of the ecosystem of college textbooks and we've really helped turn struggling bookstores around in the face of, e.g., Amazon.

VERBA - San Francisco, CA | INTERN, VISA http://staging.verbasoftware.com/ (we're mid-refresh) | jobs@verbasoftware.com

* Rails/JS Product Focus - FULL-TIME or HALF-TIME with benefits * Analysis/Infrastructure/Performance Focus - HALF-TIME with benefits

Verba believes in challenging the status quo of college textbooks. As it stands, every participant in the market lacks information, and the textbook market is even the basis for the definition of "Broken Market".

By injecting information at precisely the right places, Verba is changing the landscape of higher education affordability: Getting professor book adoptions in faster; Giving recommendations on close-to-market bookstore prices; Helping students compare their bookstore's prices to those of its online competitors; Sourcing cheaper books from online markets; Selling them back to multiple wholesalers and online markets.

We guide every stage of a book's life. We help students save money, and bookstores become and stay relevant, competitive, and transparent.

Numbers: 350 colleges and universities, tracking ~200k unique ISBNs, serving millions of students, raising the "win rate" for bookstores to 80%, and dropping prices across the board. 17 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 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, 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. 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 to jobs@verbasoftware.com 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!

Part-time is easy to come by when you're doing consulting work, since you can work out the requisite hours with your clients. I did full-time remote consulting for about 5 years, dropped to part-time consulting for a year to concentrate on music.

Finding a client that we could be flexible on hours with was difficult, though. Many clients are tied to the ass-in-chair time cycle. We eventually found a small company that was made of people who were largely remote and worked really flexible hours themselves.

Eventually I found a job in SF that offered full-time and part-time, and you can move between the two. This has been really great since we started a family last August - I took a month off, then came back doing 4-day weeks.

If you're in SF, we're hiring - https://news.ycombinator.com/item?id=6477194

Hello, I really like working here. Everyone is very kind. :D

Seeing that most large hospitals pay 50+ million for their EHR/EMR setup, $500/month sounds reasonable.

When I worked for a construction project management startup, this too sounded reasonable: many software systems for this audience were in the six-figure range... we were only asking $100/month or so. ("And a free trial!!!")

We learned that when your monthly price point is the size of an accounting error, no one can take you seriously.

This software was also holistic in nature: everyone, everyone, everyone has to use it for it to work well and as a core part of their organization. It's a superset of the marketplace business problem.

To address these we had to charge more. Much more. This raised the stakes on both parties and also filtered out less serious buyers who would probably fail with our software.

The construction companies who were serious buyers really considered thoroughly whether they could implement the change; we worked with them for, sometimes, months going through how the change would take place. And training, training, training. Usage metrics. Account hand-holders. Keep them using the system.

--

As others have said, medical software is some of the hardest to break into. Medical staff HATE CHANGE, and need to. Change in the short term leads to mistakes and mistakes cost lives or careers. The system is bureaucratic, politicized and slow moving. Anti-disruption.

I believe that a guerrilla approach to insurgent medical software is ultimately what will work - things like https://www.radiologyprotocols.com/, where a radiology tech wanted a common repository of knowledge for others in his field. Then, through word of mouth and using it with his colleagues, it gained first use in his hospital, then international use, and now it's starting to take off in the US. (Reminds me of "Big in Japan" first, or conversely Japanese artists having to become popular in the US before being taken seriously back in Japan.)

--

Okay, advice.

Sell it before you make it. If you have multiple hospital/medical contacts, play with pricing. Try outrageous things. If not, just try to work out any sort of deal and have them sign a piece of paper that says they'll pay.

Then build it.

Iterate with the first customer until it's "So Good They Can't Ignore You".

After this, you might get better traction outside the US. There are hospitals in other countries who are desperate for good software and also don't have the money for the large EMR software many US hospitals use.

GOOD LUCK!

What does NATS achieve that isn't available by using RabbitMQ or 0MQ?

Oh wow, it's so much better than airbrake.

http://dl.dropbox.com/u/2126879/Screenshots/0q.png

Bad graphic design. The spinny wheel thing from the ads is way better. They still have hints of shading on the new logo, but it looks horrible and flat.

Time is the only thing I can't make more of. The deregulation of airline prices and the subsequent obsession over the lowest fare has led us to treat airlines as a commodity, and the airplanes have thus become cattle cars in the sky. I and most people I know are willing to pay $50 extra for a better experience. "Agony" is the correct sort for us.

I hate the future.