Live data from Hacker News

Estimating Number of Jupyter Notebooks on Github

kyso.io

131–135 of 135 posts

Re: Estimating Number of Jupyter Notebooks on Github

#131
post #6

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.

Sounds useful, care to share that hook?

Re: Estimating Number of Jupyter Notebooks on Github

#132
post #60

Earlier 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/

I have not had good luck with nbdiff. Minutes-long runtimes and huge memory consumption on fairly standard ipynb’s.

Re: Estimating Number of Jupyter Notebooks on Github

#133

In 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…

Check out: Ten Simple Rules for Reproducible Research in Jupyter Notebooks, https://arxiv.org/abs/1810.08055 and https://github.com/jupyter-guide/ten-rules-jupyter

Re: Estimating Number of Jupyter Notebooks on Github

#134

Earlier 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?

Interesting! That would be super awesome. Like a one-click deploy with auto-shutdown after the end of run to save money. I would definitely pay for a service like that!

Re: Estimating Number of Jupyter Notebooks on Github

#135

Earlier 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…

Awesome! Wish you guys the best. As someone who has made a few electron apps in the past couple of years (I am not a front-end/back-end guy), I have immense respect for the VSCode team and the quality of the product. They pretty much showed the whole world what a quality electron app can look like and that most of the blackeye electron gets for "performance" can be chalked down to poor programming practices and software design in the case of a lot of other electron apps.
Post reply on HN