Off topic: Possibly something in my config, but I've recently got a lot of "Sorry, something went wrong. Reload?" when trying to view Jupyter notebooks on github itself. Seems to be working right now. I have used this as an alternate: https://nbviewer.jupyter.org/
I get it a lot, so I set a precommit hook to render all my notebooks to HTML. With GitHub Pages, I can access them easily.
Estimating Number of Jupyter Notebooks on Github
131–135 of 135 posts
Re: Estimating Number of Jupyter Notebooks on Github
#132Earlier quoted context omitted.
> because they are so unsuitable for use with git Can you going into a little more depth about this statement?
Diffs primarily I'm guessing - a, it's kinda hard to parse the jsons that you see when you look at a notebook in raw text b, every time I execute a cell, it shows up in the diff as a change. That being said, there are plugins and tools that deal with these issues quite well. check out https://nbdime.readthedocs.io/en/latest/
Re: Estimating Number of Jupyter Notebooks on Github
#133In the same spirit as “Effective Java” and “Effective C++” we need to have a book entitled “Effective Jupyter Notebooks”. Here are some of my items below. Maybe this sub-thread can come up with an outline for this book. Item #1 Writing a notebook is foremost an exercise in expository writing. Make sure the writing is high quality is the first objective when writing a notebook. This is the Knuth’s literate programming…
Re: Estimating Number of Jupyter Notebooks on Github
#134Earlier quoted context omitted.
Yeah but unfortunately there is no GPU support. I wish there was!
Ah yeah ok - we are not planning GPU support soon - what if we created one of those one-click deploy a VM to aws/digital-ocean buttons and from there if you wanted to post to Kyso you could do it with git or our jupyter lab plugin. You get most of the same experience and you can even customise various of the steps?
Re: Estimating Number of Jupyter Notebooks on Github
#135Earlier quoted context omitted.
Nice work on this! I think apart from the very valid points raised by Joel Gru in his presentation slides, Jupyter Notebooks are woefully inadequate for exploring and understanding code that utilizes libraries. I'll take the FastAI library as an example since Jeremy Howard is the one who took Joel to task regarding criticizing Notebooks: If I view any fastai notebooks taken from their repo, there are a million import…
Thanks for the kind words! I'm currently thinking about a model of notebooks / interactive programming where the default assumption is that you're using it as a scratchpad, i.e., you won't need to explicitly name the file in order to get the benefits of auto-save, but yet the file won't pollute your filesystem / project namespace until you choose to "keep" it. Hopefully this helps reduce the friction in the explorato…