Made a few spelling and grammar corrections/adjustments to the docs under guide.
This commit is contained in:
@ -1,8 +1,8 @@
|
||||
Bonobo with Jupyter
|
||||
===================
|
||||
|
||||
There is a builtin plugin that integrates (kind of minimalistically, for now) bonobo within jupyter notebooks, so
|
||||
you can read the execution status of a graph within a nice (ok not so nice) html/javascript widget.
|
||||
minimalistically
|
||||
There is a builtin plugin that integrates (somewhat minimallistically, for now) bonobo within jupyter notebooks, so
|
||||
you can read the execution status of a graph within a nice (ok, not so nice) html/javascript widget.
|
||||
|
||||
See https://github.com/jupyter-widgets/widget-cookiecutter for the base template used.
|
||||
|
||||
|
||||
@ -128,7 +128,7 @@ Now let's see how to do it correctly:
|
||||
'index': i
|
||||
}
|
||||
|
||||
I hear you think «Yeah, but if I create like millions of dicts ...».
|
||||
I bet you think «Yeah, but if I create like millions of dicts ...».
|
||||
|
||||
Let's say we chose the opposite way and copied the dict outside the transformation (in fact, `it's what we did in bonobo's
|
||||
ancestor <https://github.com/rdcli/rdc.etl/blob/dev/rdc/etl/io/__init__.py#L187>`_). This means you will also create the
|
||||
|
||||
@ -12,8 +12,8 @@ If you're going a little further than that, you'll feel limited, for a few reaso
|
||||
|
||||
* Hardcoded and tightly linked dependencies make your transformations hard to test, and hard to reuse.
|
||||
* Processing data on your laptop is great, but being able to do it on different target systems (or stages), in different
|
||||
environments, is more realistic. You'll want to contigure a different database on a staging environment,
|
||||
preprod environment or production system. Maybe you have silimar systems for different clients and want to select
|
||||
environments, is more realistic. You'll want to configure a different database on a staging environment,
|
||||
pre-production environment, or production system. Maybe you have similar systems for different clients and want to select
|
||||
the system at runtime. Etc.
|
||||
|
||||
Service injection
|
||||
@ -44,7 +44,7 @@ Let's define such a transformation:
|
||||
'category': database.get_category_name_for_sku(row['sku'])
|
||||
}
|
||||
|
||||
This piece of code tells bonobo that your transformation expect a sercive called "primary_sql_database", that will be
|
||||
This piece of code tells bonobo that your transformation expect a service called "primary_sql_database", that will be
|
||||
injected to your calls under the parameter name "database".
|
||||
|
||||
Function-based transformations
|
||||
|
||||
@ -22,7 +22,7 @@ underscores and lowercase names:
|
||||
def uppercase(s: str) -> str:
|
||||
return s.upper()
|
||||
|
||||
If you're naming something which is configurable, that will need to be instanciated or called to obtain something that
|
||||
If you're naming something which is configurable, that will need to be instantiated or called to obtain something that
|
||||
can be used as a graph node, then use camelcase names:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
Reference in New Issue
Block a user