juliennakache

Is that a reference to LeChuck in Monkey Island? Love that game!

The R&D credits are deducted from Payroll taxes, so they impact pre-revenue startups as well.

We’re Hiring Founding Engineers @ Medbill AI (US Remote, NYC, Seattle)

Hi HN,

Medbill AI is hiring Founding Software Engineers! We’re building the most trusted service for reducing the time, money, and stress associated with medical bills and health insurance.

The Problem: 40% of medical bills in the U.S. contain errors, contributing to over $195B in medical debt annually. Navigating health insurance and resolving billing disputes is a nightmare for millions.

About Us: Backed by Top Investors: $17M seed round led by Forerunner, with participation from the founders of HuggingFace, Oscar Health, RocketMoney, and Tim Ferriss.

Our Team: We’re a small but mighty group of 6 engineers, including 3 former Staff Engineers from Oscar Health.

What We’re Looking For: -4+ years of experience engineering software as a product/full-stack engineer or back-end engineer. -Excited to solve complex problems in health tech and shape the technical foundation of a fast-growing startup.

Have questions? Reach out to hiring@medbill.ai or apply at

https://jobs.ashbyhq.com/medbill-ai?utm_source=d9ljn0qBe4

Looking forward to hearing from you!

Medbill AI | Founding Senior Engineer + Founding Designer | Full Time | Remote - US timezones

We are building an AI assistant that helps people with medical billing and health insurance issues. Thanks to AI and new healthcare regulations around patient data access and price transparency, it is now possible for everyone, including you, to have their own assistant who works around the clock to save them time and money on medical bills and health insurance issues.

Reach out if you’re interested in the role or want to learn more about what we’re up to!

https://www.medbill.ai/about

Some of the product team is in EST so that's going to be too tight. Thanks for offering though!

Medbill AI | Founding Senior Engineer + Founding Designer | Full Time | Remote - US timezones

We are building an AI assistant that helps people with medical billing and health insurance issues. Thanks to AI and new healthcare regulations around patient data access and price transparency, it is now possible for everyone, including you, to have their own assistant who works around the clock to save them money on medical bills and navigate the disjointed US healthcare system.

Reach out if you’re interested in the role or want to learn more about what we’re up to!

https://www.medbill.ai/about

Hi, sorry just seeing this.

What about the comments on commits? Are those all displayed in the Github PR when it's merged, and attached to all the correct lines, even the ones that were made on branches that were rebased?

Thanks!

Seems interesting! I've been very unhappy with Github workflow and UI for PRs. It's insane that each time you rebase a PR, you lose all your existing comments on that PR (i.e. they are no longer attached to lines in the UI).

Does anyone know if you need Graphite to see a PR once it's been merged in the Github repo? I'm curious about how locked you in when you start using Graphite.

From a link shared in a thread below:

“High-temperature properties such as the volumetric storage density, viscosity and transparency are similar to water at room temperature. The major advantages of molten salts are low costs, non-toxicity, non-flammability, high thermal stabilities and low vapor pressures. The low vapor pressure results in storage designs without pressurized tanks (Fig. 1). Molten salts are suitable both as heat storage medium and heat transfer fluid (HTF). In general, there is experience with molten salts in a number of industrial applications related to heat treatment, electrochemical treatment and heat transfer for decades.”

I don’t know anything about this but it does seem that things are not as clear cut as your comment made it seem.

ref: https://onlinelibrary.wiley.com/doi/10.1002/cite.202000137

EDIT: From ChatGPT 3.5:

“ One of the most commonly used molten salts in nuclear reactors is a mixture of lithium fluoride (LiF) and beryllium fluoride (BeF2), commonly referred to as FLiBe. FLiBe is used as both a coolant and a neutron moderator in some types of nuclear reactors, such as molten salt reactors (MSRs) and some advanced small modular reactors (SMRs).

FLiBe has several advantages as a coolant in nuclear reactors, including its good heat transfer properties and its ability to operate at high temperatures without evaporating. Additionally, FLiBe is not highly corrosive to many materials commonly used in reactor components, which can help reduce maintenance and replacement costs.

However, FLiBe does have some potential disadvantages, such as its relatively high viscosity, which can make it more difficult to pump and circulate, and its high melting point, which can increase startup times for reactor systems. Additionally, FLiBe can be corrosive to some materials, such as aluminum and some types of steels, so care must be taken in selecting materials that are compatible with FLiBe.”

Interesting. How does local development work or remote debugging work if the entire production toolchain is abstracted away with proprietary software?

Looks great. I've waiting for a service like that ever since Microsoft released their paper on speech synthesis using voice samples. Feature requests: - make the voice generation available via API so devs can embed that in their app - expose a streaming API like Polly so we can feed it text in real time and get the voice as an audio stream - make it Hipaa compliant and have a plans that offer signing a BAA

I'll be your first customer if you do this! You can get in touch with me at @juliennakache

The main ideas it that theoretically the demand should shift to greener alternative. However, as far as I understand the issue is that currently it shifts the demand to another producer. There is this concept of additionality in carbon offsets but it's intractable to measure. IMHO the only way to really prevent it would be to pay most or all polluters so they stop. One day we might get there when we've offset most emission sources of a given type (ie say land forest). But in the meantime, those offsets are not actually moving the needle. And also, does that mean we should start paying via carbon offsets every single owner of an oil pit so they don't get oil off the ground?

Interesting. Still pretty limiting but I can see creative ways of working around the limitations. Thanks for sharing!

Does anyone have a sense of how the Shopify integration work under the hood? Specifically, how were they able to have Chat-GPT makes a recommendation from their product database? Given the model cannot be fine-tuned and there is a 4000 token context limit, I'm guessing the only thing really possible is to have chat gpt extract a few keyword and generate a query in their internal product search and return the first one? Is there anything else that might going under the hood?

Same here I keep getting the same spam from ACE Hardware. I've been reporting it a couple of months now but they keep coming in. It's weird.

I liked very much the idea of dynamic masking. However, I wonder how good it works in practice. I was actually assessing one of your competitor (www.satoricyber.com) and found an easy to workaround the masking - I was able to essentially access any mask data using not-so-advanced SQL functions. Do you guys have a publicly available test suite against your proxy that people and security researcher can review? Also, do you have a bug bounty program and / or a clear disclosure policy when a vulnerability is found?

Is there a way to toggle / collapse bullet list? I find that it’s one of the most useful features when organizing my thought as it allows me to explore one nested branch very deeply while still keeping the doc easy to deal with. You can hide the unnecessary details when you want to keep think a higher level.

Probably the darkest UX pattern I've seen in a while... It's not spam per say so I'm not sure if this can be reported to the FTC, but it sure is a dirty move. Whoever designed is either evil or had was forced by an evil organization who would do anything to make their stock go up after a rough SPAC introduction.

Does anyone know if this can be reported to a public agency?

Looking forward to trying this out. I've always felt that PagerDuty was absurdly expensive for the feature set they were offering. It costs something at least $250 per user for organization larger than 5 person - even if you're not an engineer who is ever directly on call. At my previous company, IT had to regularly send surveys to employees to assess if they really needed to have a PagerDuty account. Alerts are a key information in an organization that runs software in production and you shouldn't have to pay $250 / month just to be able to have some visibility into it. I'm hoping Grafana OnCall is able to fully replace PagerDuty.

Because as far as I know you can't easily access your password outside of Chrome. For example, it's not practical to use on my iOS devices. If you want to log into an app, I believe you can't easily use passwords stored in Chrome.

I haven't looked into the Django ORM recently but last time I checked I think it would have been a lot more challenging to implement something similar. SQLAlchemy is a lot more flexible, very well designed and actively maintained. My recommendation would be to try using SQLAlchemy with Django. It should work without any problems but you might lose the ability to use some of the Django plugins that assume the Django ORM.

Quick plug: we've made good progress on solving this very problem for the SQLAlchemy ORM in Python. Our approach is a bit like Join-Monster but more flexible because:

  - we introspect your SQLAlchemy models and generate Dataloader-based resolvers that emit small independent SQL queries. This way this optimization composes naturally with other GraphQL types in your schema.
  - we are thin wrapper on top of Graphene, the main GraphQL Python library. It makes it very easy to extend your type if needed. We also added ways to rename and modify the type of a column / field.
  - for the SQL query generation we currently lean on SQLAlchemy to do the heavy lifting. It can emit efficient in IN() JOIN queries for us.

So far, it's been working quite nicely for us. We were able to generate decently performant schemas with very boilerplate on top of our existing SQLAlchemy models. And each time we've run into a case that the library did not optimize well for us, we were able to easily override its behavior by writing our SQLAlchemy queries.

There is still room for performance improvements but I'm confident we'll get there eventually (though I expect the optimizations to only work for DBs that support LATERAL JOINs). My main focus at the moment is to come up with an API that it possible to create performant types that aggregate multiple tables.

Links - https://github.com/graphql-python/graphene-sqlalchemy - https://github.com/graphql-python/graphene-sqlalchemy/pull/2...

EDIT: formatting

Such a great conference. It is awesome to see GraphQL community grow and mature over the years.

Quick plug - If you're interested in mocking your API in test as described in the "build your own graphql tools", my company just released a library that lets you do that more easily than with `graphql-tools`. We've been using internally for months in our UI tests. Hopefully you find it useful.

https://github.com/oscarhealth/graphql-mock-factory

I've been playing with this a for a few months now. Thanks to webpack / react starter (https://github.com/webpack/react-starter), you get that for free (with server-side rendering of your apps).

What I'd like to see is for webpack to add features from Pants like self-bootstrapping executables (PEX) or run tests based on which part of the code was affected by a commit. For the executable part, I guess Docker kind of solve that issue. See http://pantsbuild.github.io/ for more info

To be continued :)

Wow! That was fast!

Awesome stack. It's exactly what I've started working on lately. I have 2 questions for you :) 1. What router do you use for react as it's necessary if you want multiple entry points into your app ? Rrouter seems promising. 2. How do you elegantly proxy client cookies from your node app to your api ? (both way: read and writes) Thx!

Thanks for the feedback. I'll update the landing this week. The most common use cases we have so far: dates / young couples that want spend quality time, friends dinners, supper clubs, cooking enthusiasts who want to learn new recipes from top Chefs... You just order the recipe you want: no subscription yet(people have requested it). Cut off time is 10pm the day before your delivery. If you have friends in NYC, feel free to share the joy of cooking :)

Fair point. But with Heroku, you still need to build your app yourself. Coming up with a recipe is really easy compared to build an app from scratch. Maybe we're the Ruby on Rails of cooking. What do you think?

http://www.chefday.com/ is Heroku for cooking :)

+1