amirathi

We have never heard this before. User can provide details for us, but if others aren’t experiencing it, it’s unlikely to be prioritized

We have heard this before, but we cannot see it or replicate it. The user gets to do work for us and/or get no resolution

Well, if you're not willing to resolve individual customer's problem then don't expect to build goodwill with just prompt reply on support!

In the long run it's not punitive but rather amazing marketing for Anthropic. People crave what they can't have.

This is the best marketing Anthropic could have hoped for. People crave what they can't have.

Author says Claude now one-shots distributed systems bugs that used to take him two days but most top comments here are still playing down frontier model capabilities.

Are we collectively in denial? It's understandable as the craft as we knew it is being disrupted by tools that have improved at an astonishing pace.

I find OpenAI's speech-to-text model the best of the lot. It can handle my & my 5-year old daughter's Indian accent pretty well.

I wonder if they run the STT model's output through the current model (that we're chatting with) as a final pass - since the text seem to be well aligned to the current conversation context.

For long prompts, I often speak to OAI web/app and copy-paste the text to Claude / Gemini :)

Really cool. If somebody doesn't want to adopt a new platform, take a look at open source Jupyter MCP Server[1]. Once integrated with Claude, it can execute code on the live notebook kernel.

I just let Claude write notebooks, run top to bottom, debug & fix errors & only ping me when everything is working.

[1] https://github.com/datalayer/jupyter-mcp-server

Just uninstalling the endless scrolling apps (Twitter, Reddit, Instagram etc.) was enough for me.

I took a stab at this ~7 years ago - https://nurtch.com/

The idea has a lot of merit. We even gave a talk about it in JupyterCon Paris 2023 - https://www.youtube.com/watch?v=TUYY2kHrTzs

When you have executable code in the documentation, folks want to follow PR-review workflow with the docs as well - which is a bit more team investment than editing a wiki.

Good luck!

When you raise $$$ - the nice little API client needs to become "Enterprise API Platform"

Is anyone here worried about pouring hot water into Aeropress plastic? I know it's polypropylene, which is BPA-Free but could there be things that we haven't properly researched yet?

We all know .ipynb JSON format is not a great fit for Git. The Jupyter ecosystem has come a long way in the last few years. Solving this really comes down to a few tools -

- JupyterLab Git Extension[1] for local diffs (pre-commit diffs)

- nbdime[2] / nbdev[3] for resolving .ipynb git merge conflicts

- GitHub PR code reviews with ReviewNB[4]

- Alternatively, if you don't care about cell outputs then Jupytext[5] to sync .ipynb JSON to markdown

Disclaimer: I built ReviewNB. It's a completely bootstrapped business, 5 years in the making and now used by leading DS teams at Meta, AWS, NASA JPL, AirBnB, Lyft, Affirm, AMD, Microsoft & more[6] for Jupyter Notebook code reviews on GitHub / Bitbucket.

[1] https://github.com/jupyterlab/jupyterlab-git

[2] https://nbdime.readthedocs.io

[3] https://nbdev.fast.ai

[4] https://www.reviewnb.com

[5] https://github.com/mwouts/jupytext

[6] https://www.reviewnb.com/#customers

I'm just happy that Microsoft is finally charging directly for a developer product!

When they keep giving out freebies (VSCode, npm etc.), I never know which direction the product is going to evolve (e.g. unnecessarily tight integration with Azure).

With this, there's at least direct alignment between end user & the product.

Here are tools people commonly use for notebook version control with git -

[1] nbdime to view local diffs & merge changes

[2] jupytext for 2-way sync between notebook & markdown/scripts

[3] JupyterLab git extension for git clone / pull / push & see visual diffs

[4] Jupyerlab gitplus to create GitHub PRs from JupyterLab

[5] ReviewNB for reviewing & diff'ing notebook PRs / Commits on GitHub

Disclaimer: While I’m the author of last two (GitPlus & ReviewNB), I’ve represented the overall landscape in an unbiased way. I've been working on this specific problem for 3+ years & regularly talk to teams who use GitHub with notebooks.

[1] https://nbdime.readthedocs.io

[2] https://jupytext.readthedocs.io

[3] https://github.com/jupyterlab/jupyterlab-git

[4] https://github.com/ReviewNB/jupyterlab-gitplus

[5] https://www.reviewnb.com/

Jupyter Notebook is THE modern literate programming environment.

It's a shame that it's only primarily used for Data Science experimentation & teaching.

The problems you mention are solved by auxiliary tools in the notebook ecosystem.

- Look at nbdime & ReviewNB for git diffs

- Checkout treon & nbdev for testing

- See jupytext for keeping .py & .ipynb in sync

I agree it's a bit of a pain to install & configure a bunch of auxiliary tools but once set up properly they do solve most of the issues in the Jupyter notebook workflow.

Disclaimer: I built ReviewNB & Treon

This is great. Other comments here are underestimating the power of a group. An average bounty on an issue might just be between $10-$100 but there can easily be 50 people putting up a bounty for a popular issue (have you seen issues with hundreads of upvotes and are still open for years). If we start seeing (collective) bounty on an issue in the range of a few thousand $$ then it's decent money for maintainers or anyone else who's motivated enough.

My guess is this is eventually going to be built into GitHub (via acquisition or otherwise).

Why not just use JupyterLab with GitHub? You get all those enterprise features with GitHub. And you can augment the shortcomings with auxilary tools. E.g. JupyterLab git extension & ReviewNB for notebook version control.

Disclaimer: I built ReviewNB.

(for regular workloads) cost of maintaining such a DB >> cost of RDS

It's a very interesting problem from a technical standpoint nonetheless.

Notebooks as we know them today have many pain points (versioning, reproducibility, collaboration)

Absolutely. We're solving a small part of this by making notebooks play nicely with GitHub (https://reviewnb.com). Code reviews & collaboration for Jupyter Notebooks, essentially.

Happy to see more products taking a stab at this problem. I'd be curious to know how you implement version control (git or something else) & what kind of experiences does that translate to for the user. Congrats on the launch!

Right but a new prospect is going to want to evaluate $200/mo offering and see if that meets their needs. So you are loosing out on new business.

Post mortem for February events[1]. It was resource contention on their primary mysql cluster caused by unintended config change.

There's a total of 34 incidents in 2020 so far[2]. I wonder if all are DB woes or there are other factors at play (like move to Azure).

[1] https://github.blog/2020-03-26-february-service-disruptions-...

[2] https://www.githubstatus.com/history

Reading official documentation when working with new tools/frameworks.

Googling every hurdle as it comes & over relying on StackOverflow is neither effective nor satisfying. Some of the projects out there have amazing documentation (e.g. VueJS, Kafka). It's best to read the overview & skim high level stuff to understand the core components/principles/terminologies. It makes it so much easier & enjoyable to use those tools.

This is coming from creator of Redis so we better listen :)

Thank you for your work Salvatore!

How do you measure a good job?

If a story that I upvoted from /newest ends up getting lots of love(=upvotes) on HN then I have done a good job.

For this to work in practice there needs to be /staging. Here's the workflow,

- Karma hungry scavengers (like me) would go to /newest and upvote some interesting stories.

- Some of these stories move to /staging where non-scavengers (yet karma hungry) reads & upvotes the interesting ones.

- After a certain threshold on /staging the story moves to HN homepage.

- If my story makes it to homepage, I should get a % of final story points (say 10%) as a karma bounty. I help community discover great content from a river and I'm directly rewarded in proportion to the quality of content (maybe only after the story crosses a certain threshold).

- People who upvote from /staging should also get a % karma bump (although lower than me).

I know we are basically creating mini-HN with /staging but I'm suggesting this approach based on your past comments about folks's emotional connection to homepage (many people only want to see quality content on homepage).

One idea is to have more human curation of the content posted on /newest.

Currently users don't have much incentive to go through newest and curate/upvote. Adding some badges & special privileges (or just awarding karma) for folks who consistently help curate & discover great content would set the incentives correctly. Essentially, gamify the curation process so the load gets shared.

It's clear that Google don't want to hire humans and run customer support centers. According to reports, this has bit them in GCP adoption as well.

That's fine but at least have a human review before taking disastrous actions like taking down extensions, lockdown Gmail accounts. If you can't afford even that at least have an appeal process where human would review the case. If you can't make the economics work even for that maybe just don't run the app store.

Maybe you meant to link Traction[1] by Weinberg & Mares? You've probably linked the wrong book with the same name.

[1] https://www.amazon.com/Traction-Startup-Achieve-Explosive-Cu...

GitHub is having major availability issues these past three months. 4 incidents in Feb, 4 in March and 6 in April so far.

Source: https://www.githubstatus.com/history

I look forward to reading root cause analysis promised by Nat in Feb: https://twitter.com/natfriedman/status/1233079491204804608

Yes, nbdev can help with merge conflicts for notebooks [1]. Also checkout,

- GitPlus[2] - JupyterLab extension for git version control

- ReviewNB[3] - For notebooks diffs & commenting

Disclaimer: I built GitPlus & ReviewNB

[1] https://nbdev.fast.ai/#Avoiding-and-handling-git-conflicts

[2] https://github.com/ReviewNB/jupyterlab-gitplus/

[3] https://www.reviewnb.com/

Quill[1] editor has saved me (and many others) 100+ hours. Imagine building a rich text editor from scratch in your product.

Also - git, Django REST framework, VueJS

[1] https://quilljs.com/