38 Matching Annotations
  1. May 2020
    1. Hot Reloading refers to the ability to automatically update a running web application when changes are made to the application’s code.

      Hot Reloading is what provides a great experience with updating your Dash code inside the Jupyter Notebooks

    2. JupyterDash supports three approaches to displaying a Dash application during interactive development.

      3 display modes of Dash using Jupyter Notebooks:

      1. app.run_server(mode='external')
      2. app.run_server(mode='inline')
      3. app.run_server(mode='jupyterlab')
    3. # Run app and display result inline in the notebookapp.run_server(mode='inline')

      Moreover, you can display your Dash result inside a Jupyter Notebook using IPython.display.IFrame with this line:


    4. If running the server blocks the main thread, then it’s not possible to execute additional code cells without manually interrupting the execution of the kernel.JupyterDash resolves this problem by executing the Flask development server in a background thread. This leaves the main execution thread available for additional calculations. When a request is made to serve a new version of the application on the same port, the currently running application is automatically shut down first. This makes is possible to quickly update a running application by simply re-executing the notebook cells that define it.

      How Dash can run inside Jupyter Notebooks

    5. You can also try it out, right in your browser, with binder.

      Dash can be tried out inside a Jupyter Notebook right in your browser using binder.

    6. Then, copy any Dash example into a Jupyter notebook cell and replace the dash.Dash class with the jupyter_dash.JupyterDash class.

      To use Dash in Jupyter Notebooks, you have to import:

      from jupyter_dash import JupyterDash

      instead of:

      import dash

      Therefore, all the imports could look like that for a typical Dash app inside a Jupyter Notebook:

      import plotly.express as px
      from jupyter_dash import JupyterDash
      import dash_core_components as dcc
      import dash_html_components as html
      from dash.dependencies import Input, Output
    1. For many data scientists, the finished product of a work session is a business analysis. They need to show team members—who oftentimes aren’t technical—how their data became a specific recommendation or insight.

      Usual final product in Data Science is the business analysis which is perfectly explained with notebooks

  2. Apr 2020
    1. Development Pros Cons

      Table comparing pros and cons of:

      • IDE/Editor
      • REPL/shell
      • Traditional notebooks (like Jupyter)
    2. This kind of “exploring” is easiest when you develop on the prompt (or REPL), or using a notebook-oriented development system like Jupyter Notebooks

      It's easier to explore the code:

      • when you develop on the prompt (or REPL)
      • in notebook-oriented system like Jupyter

      but, it's not efficient to develop in them

    3. notebook contains an actual running Python interpreter instance that you’re fully in control of. So Jupyter can provide auto-completions, parameter lists, and context-sensitive documentation based on the actual state of your code

      Notebook makes it easier to handle dynamic Python features

    4. They switch to get features like good doc lookup, good syntax highlighting, integration with unit tests, and (critically!) the ability to produce final, distributable source code files, as opposed to notebooks or REPL histories

      Things missed in Jupyter Notebooks:

      • good doc lookup
      • good syntax highlighting
      • integration with unit tests
      • ability to produce final, distributable source code files
    5. Exploratory programming is based on the observation that most of us spend most of our time as coders exploring and experimenting

      In exploratory programming, we:

      • experiment with a new API to understand how it works
      • explore the behavior of an algorithm that we're developing
      • debug our code through combination of inputs
    1. Version control is at the heart of any modern engineering org. The ability for multiple engineers to asynchronously contribute to a codebase is crucial—and with notebooks, it’s very hard.

      Version control in notebooks?

    2. Reproducibility is an issue with notebooks. Because of the hidden state and the potential for arbitrary execution order, generating a result in a notebook isn’t always as simple as clicking “Run All.”

      Problem of reproducibility in notebooks

    3. A notebook, at a very basic level, is just a bunch of JSON that references blocks of code and the order in which they should be executed.But notebooks prioritize presentation and interactivity at the expense of reproducibility. YAML is the other side of that coin, ignoring presentation in favor of simplicity and reproducibility—making it much better for production.

      Summary of the article:

      Notebook = presentation + interactivity

      YAML = simplicity + reproducibility

    4. Notebook files, however, are essentially giant JSON documents that contain the base-64 encoding of images and binary data. For a complex notebook, it would be extremely hard for anyone to read through a plaintext diff and draw meaningful conclusions—a lot of it would just be rearranged JSON and unintelligible blocks of base-64.

      Git traces plaintext differences and with notebooks it's a problem

    5. There is no hidden state or arbitrary execution order in a YAML file, and any changes you make to it can easily be tracked by Git

      In comparison to notebooks, YAML is more compatible for Git and in the end might be a better solution for ML

    6. Python unit testing libraries, like unittest, can be used within a notebook, but standard CI/CD tooling has trouble dealing with notebooks for the same reasons that notebook diffs are hard to read.

      unittest Python library doesn't work well in a notebook

    1. Visual Studio Code supports working with Jupyter Notebooks natively, as well as through Python code files.

      To run cells inside a Python script in VSCode, all you need to is to define Jupyter-like code cells within Python code using a # %% comment:

      # %%
      msg = "Hello World"
      # %%
      msg = "Hello again"

    1. JupyterLab project, which enables a richer UI including a file browser, text editors, consoles, notebooks, and a rich layout system.

      How JupyterLab differs from a traditional notebook

  3. Mar 2020
    1. Jupytext can be configured to automatically pair a git-friendly file for input data while preserving the output data in the .ipynb file

      git-friendly Jupytext options include

      • Julia: .jl
      • Python: .py
      • R: .R
      • Markdown: .md
      • RMarkdown: .Rmd
      • and more!
    1. The point of nbdev is to bring the key benefits of IDE/editor development into the notebook system, so you can work in notebooks without compromise for the entire lifecycle
  4. Jan 2020
  5. Sep 2019
  6. Jul 2019
  7. May 2019
  8. Jul 2018
    1. We want to even go even further and add reproducible elements to JATS documents. We are working together with Stencila on extending Texture to allow both textual narrative and executable code to coexist in one document.
  9. Apr 2018
    1. JupyterHub, a multi-user Hub, spawns, manages, and proxies multiple instances of the single-user Jupyter notebook server.
    1. At one point, Pérez told me the name Jupyter honored Galileo, perhaps the first modern scientist. The Jupyter logo is an abstracted version of Galileo’s original drawings of the moons of Jupiter. “Galileo couldn’t go anywhere to buy a telescope,” Pérez said. “He had to build his own.”

      Cool name/logo story!

    2. At every turn, IPython chose the way that was more inclusive, to the point where it’s no longer called “IPython”: The project rebranded itself as “Jupyter” in 2014 to recognize the fact that it was no longer just for Python.

      Such an interesting progression!

    3. At every turn, IPython chose the way that was more inclusive

      Nice to see that decision pay off!

  10. Jan 2018
  11. Aug 2017
    1. markdown_display_priority

      I don't know why or when my annotations will be properly applied.

      This is quite confusing. The interface remembers my tag, but not the content of my annotation.

      It does not seem to allow the application of an annotation to text inside of an iframe. This prevents proper testing of hypothes.is as a jupyter notebook annotation tool.

      In some ways it's great, but the interface and user model could use a lot of work. If it allowed annotations inside iframes I'd gladly navigate those rough edges. But without that feature it's hard to justify trying to use this for the purpose of annotating notebooks.

      Hopefully, this can be fixed, in which case I'll edit this annotation to acknowledge that annotation inside iframes works. That would mean the annotation of Jupyter notebooks would be be a process capable of supporting code review on a notebook via GitHub.

    1. markdown_display_priority

      Unfortunately this is probably the easiest place to apply a hypothes.is annotation. They don't look inside iframes. So the rendered version of the notebook will not work.

  12. Mar 2017
    1. Seco, si bien es una implementación del 2004, tiene varias ideas que son similares a las de Grafoscopio de hoy, incluyendo la persistencia de una imagen (ellos usan HyperGraphDB, pero incluso mencionan Smalltalk), el hecho de ser una aplicación de escritorio y la idea de una computación p2p, o la opción de embeber el motor de rendering de un browser o el browser mismo en un ambiente más rico, incluso la inspiración de los notebooks de mathematica.

  13. Jan 2017