More fixes on docs

Author: AlvarBer

docs/persimmon.bib

@@ -331,6 +331,14 @@ @article{zmud1980management
   publisher={JSTOR}
 }
 
+@book{schwaber2002agile,
+  title={Agile software development with Scrum},
+  author={Schwaber, Ken and Beedle, Mike},
+  volume={1},
+  year={2002},
+  publisher={Prentice Hall Upper Saddle River}
+}
+
 % Risk Analysis
 @article{boehm1991software,
   title={Software risk management: principles and practices},

docs/src/evaluation.md

@@ -19,9 +19,9 @@ Mining and Machine Learning is saved, as well as any additional feedback about
 the system.
 
 
-Proposed tasks
+Proposed Tasks
 --------------
-The evaluation is composed by three different closed tasks.
+The evaluation consists of by three different closed tasks.
 The task are defined as to gradually introduce more complex concepts, following
 the seen workflows on the workflow chapter and also being introduced to the
 concepts of reconnecting and complex block that require more actions than just
@@ -32,7 +32,7 @@ connecting.
     terms. Using the iris dataset they perform a cross validation evaluation
     of their chosen classificator.
 * Second task is modifying the previous workflow to create a more complex
-    worflow thatfits and predicts using an estimators and two sources of files.
+    worflow thati fits and predicts using an estimator and two sources of files.
     It is only slightly more complex than the previous one, but it introduces
     the concept of re-cabling to the participants.
 * Third task and final task. This one involves adding hyper-parameter tunning,

docs/src/implementation.md

@@ -4,15 +4,15 @@ Implementation
 On this chapter the implementation of the system is detailed, explained what
 was done in each iteration.
 After the iterations Persimmon intermediate representation is explained.
-Finally some of the most complex technical problems along their respective
+Finally, some of the most complex technical problems along their respective
 solutions are detailed.
 
 
 First Iteration
 ---------------
 ![Implementation of the first interface](images/interface.png)
 
-For the first iteration the priority was to get a proof of concept in order to
+For the first iteration, the priority was to get a proof of concept in order to
 see where the difficulties can appear, with a few simple classifiers and
 cross-validation techniques. As such a button-based interface with very limited
 workflow creation was chosen.
@@ -25,8 +25,8 @@ Trees, but gives good results in wide variety of problems.
 All these classifiers have few parameters on their respective sklearn
 implementations, and for this prototype the interface did not allow modifying
 any of them, as the it would have cluttered and it was not a necessary feature.
-Also all of them are classifiers, as it simplifies the interface, since
-regressors and clustering have some incompatibilities.
+Also, all of them are classifiers, as it simplifies the interface, since
+regression and clustering have some incompatibilities.
 
 Apart from the temporary interface the backend had to be built. Since the
 workflow was fixed the backend simply received the node as arguments and
@@ -36,7 +36,7 @@ needed for this iteration.
 
 Second Iteration
 ----------------
-For the second interface the drag and drop feel was the main priority.
+For the second iteration the drag and drop feel was the main priority.
 As such after developing the tab panel draggable boxes were developed, these
 boxes needed to be connected through pins.
 The logic behind the pins and the blocks is quite heavy, as there is a tight
@@ -54,7 +54,7 @@ particular function tools such as `Numba`[^Numba] or `Cython` could be used.
 
 Third Iteration
 ---------------
-For the third and final iteration the focus was on improving the visual aspect,
+For the third and final iteration, the focus was on improving the visual aspect,
 adding helpful aids to the user experience.
 The main addition being adding a notification systems that gives feedback to
 the user about the outcome of their actions and the type systems that prevents
@@ -69,7 +69,7 @@ a warning showing up when a block has only some of their inputs connected.
 Model View Controller
 ---------------------
 Since the beginning of development separation of logic and presentation has
-been a priority. For this matter the Model View Controller[^MVC] pattern has
+been a priority. For this reason, the Model View Controller[^MVC] pattern has
 been applied, separating Model (represented by the subpackage backend), View
 (represented by the `.py` files on view subpackage) and Controller
 (corresponding to the `.kv` files on view subpackage).
@@ -79,7 +79,7 @@ the current kivy framework for another one by just changed the view, no
 modifications to the backend needed.
 
 In order to avoid repetition extensive use of classes coupled with reusable
-custom kivy Widgets was used. This for example meant that each individual pin
+custom kivy Widgets were used. This for example meant that each individual pin
 on each block is a class, this proved useful for defining matching pins in
 different blocks (like when connection a pin that sends data to a pin that
 receives it).
@@ -89,7 +89,7 @@ For more information about internal package distribution check appendix A.
 
 Making a Connection
 -------------------
-One of the most complex part of the system is starting, reconnecting and
+One of the most complex parts of the system is starting, reconnecting and
 deleting a connection between blocks, it involves several actors, asynchronous
 callbacks and a very strong coupling between all elements.
 
@@ -99,7 +99,7 @@ In order to understand how connections are made it is necessary to understand
 how `Kivy` handles input.
 At surface level `Kivy` follows the traditional event-based input management,
 with the event propagating downwards from the root.
-However while traditionally inputs events are only passed down to components
+However, while traditionally inputs events are only passed down to components
 that are on the event position `Kivy` passes the events to almost all children
 by default, this is done because in phones (one of `Kivy` targets is Android)
 gestures tend to start outside the actual widget they intend to affect.
@@ -109,7 +109,7 @@ when a key is is pressed, `on_touch_move` that is notified when the touch is
 moved, i.e. a finger moves across the screen, or on this cases when the mouse
 moves, and `on_touch_up` that is fired when the touch is released.
 
-Lets represent the possible actions as use cases, the outer \* represents
+Let's represent the possible actions as use cases, the outer \* represents
 `on_touch_down`, - represents `on_touch_move`, and the inner \* `on_touch_up`:
 
 * (On pin) Start a connection.
@@ -123,9 +123,9 @@ Logic is split in two big cases, creating a connection and modifying an
 existing one.
 Creating a connection involves creating one end of the connection, both
 visually and logically and preparing the line that will follow the cursor.
-On the other hand modifying a connection means removing the end that is being
+On the other hand, modifying a connection means removing the end that is being
 touched.
-This two cases can be handled by different classes, pin on the first case and
+These two cases can be handled by different classes, pin on the first case and
 connection for the last.
 Moving and finishing the connection use the same code for both.
 
@@ -138,14 +138,15 @@ canvas, and when a connection is destroyed (this only happens inside
 depending if the connection is destroyed because the pin violates type safety
 or there is no pin under the cursor respectively) it has to unbind the logical
 connections of the pins themselves.
-For this reason connection has high-level functions that do the unbind, rebind
+For this reason, connection has high-level functions that do the unbind, rebind
 and deletion of ends, as long as the necessary elements are passed (dependency
 injection pattern).
 
 This is the reconnecting logic, notice how the reconnecting is *forward* or
 *backwards* depending on which edge the touch has happened, of course if neither
 has been touched the touch event is not handled.
 
+
 ~~~python
 def on_touch_down(self, touch):
     """ On touch down on connection means we are modifying an already
@@ -169,6 +170,9 @@ def on_touch_down(self, touch):
     else:
         return False
 ~~~
+\begin{figure}
+\caption{Connection modification handling}
+\end{figure}
 
 Visualizing the Data Flow
 -------------------------
@@ -186,7 +190,7 @@ But the frontend does not receive the block, only the hash, since that is all
 the backend has, and it has to compare with all block hashes to find the actual
 block.
 
-After this the backend has to make the outgoing connections of that block
+After this, the backend has to make the outgoing connections of that block
 pulse, meaning for example changing the value of the width of the line between
 certain values, a function that works well for this is the sin function.
 The tricky part is that each time the function is called it has to remember the
@@ -198,7 +202,7 @@ generator (also known as semi-coroutines).
 But what happens when coroutine needs to be stopped from being called? Kivy
 has a mechanism where if the scheduled function returns `False` it will stop
 calling, by default our coroutine does not return any meaningful value, but
-we can put a final `yield False` that will stop the calls.
+it is possible to yield a final `False` that will stop the calls.
 But how is that yield triggered? The proper solution solution is using
 a full coroutine (either a generator-based one of the newer asyncio ones), but
 then concurrency issues appears, such that since the coroutine is being called
@@ -256,9 +260,9 @@ importing, it also breaks resource loading at execution time (since it has to
 create a temporary folder). This results in manually specifying hidden
 dependencies and non python files (on this case mostly `kv` files).
 
-Unfortunately this process has to be done on a windows system, and as such
+Unfortunately, this process has to be done on a windows system, and as such
 cannot be done on the CI[^CI] server, to see how Persimmon utilizes CI check
-the appendix on how this document was made.
+the appendix B.
 
 
 [^blackboard]: Blackboard is where the blocks and connections reside.

docs/src/interface.md

@@ -1,7 +1,7 @@
 Interface Design
 ================
 
-The main way users interact with the system is trough the visual interface, and
+The main way users interact with the system is through the visual interface, and
 as such is very important that all the information and operations available are
 easily accessible on an intuitive manner, removing the need for extensive
 training with the software.
@@ -10,9 +10,9 @@ Sketches
 --------
 ![Sketch of the first interface](images/sketch_1.png)
 
-On the first interface there was a focus on getting a prototype done as soon as
-possible.
-For this reason the interface had to be easy to implement and easy to use, with
+On the first interface, there was a focus on getting a prototype done as soon
+as possible.
+For this reason, the interface had to be easy to implement and easy to use, with
 the few navigations steps required to perform all possible actions as to allow
 for quick debugging.
 This meant sacrificing flexibility in favour of usability, because the
@@ -23,20 +23,20 @@ shapes or any other kind of visual aid.
 
 ![Sketch of the second interface](images/sketch_2.png)
 
-For the second iteration however the extensibility had to be present, meaning
+For the second iteration, however, the extensibility had to be present, meaning
 the old interface was not reusable for the new functionality.
 The block based interface gives a lot more of control to the final user, still
 some underlying mechanisms such as optional parameters or saving into file were
 not present.
 
-Finally on the third iteration the proposed improvements to the interface were:
+Finally, on the third iteration the proposed improvements to the interface were:
 
 * Adding a smart bubble[^bubble] that shows the blocks that make sense to spawn
     according to the connection.
 * Optional parameters.
 * Hide/Toggle parameters.
 * Data transfer visualization, meaning that the connection between two blocks
-    starts signaling when data from one is moved onto the other.
+    starts signalling when data from one is moved onto the other.
 * Type safety indicator while dragging a connection, such as turning the
     connection cable to a bright red to signal that if the cursor is unpressed
     at that location a connection will not form.
@@ -49,7 +49,7 @@ Colour Palette
 --------------
 One of the most important parts of the system where colour played a vital role
 was connections, symbolizing types with colours.
-The relations goes as far as each types has a colour associated with it on
+The relations go as far as each types has a colour associated with it on
 code, meaning that pins are not coloured, their type is specified and their
 colour is derived from the type.
 

docs/src/introduction.md

@@ -12,12 +12,12 @@ Description
 Data Science has seen exponential growth in the market on recent years, with
 some predictions stating that one million data scientists will be needed by
 2018 [@onemillion].
-Bubble or not data scientists find themselves on a golden age, for the Harvard
-Business Review it is the sexiest job of the 21st century [@sexy].
+Data scientists find themselves on a golden age, for the Harvard Business
+Review it is the sexiest job of the 21st century [@sexy].
 Despite all the hype, there is a shortage of skilled data scientists, the field
 is inherently multidisciplinary, as coding, statistics and domain knowledge are
 required, making the path to mastery long and complex, leading to the so
-called Unicorn hunts [@unicorn, @hunt].
+called Unicorn hunts [@unicorn] and [@hunt].
 
 Tools such as scikit-learn[^skl], Weka or Tableau provide a very high
 level access to some of the required tools data scientists require, easing the