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.