SHARE
TWEET

Untitled

a guest Sep 16th, 2019 87 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. ### Colab, le gestionnaire de tâche
  2.  
  3. Click **[here](https://colab-task.herokuapp.com)** to visit the site on Heroku
  4.  
  5. _Google Fonts are used for this app. It is recommended to open the app in Chrome_
  6.  
  7. testing accounts:
  8.  
  9. colab_user0@yopmail.com//1111111
  10. colab_admin@yopmail.com//1111111
  11.  
  12. * * *
  13. ##### Concept and functions
  14.  
  15. Colab is a web app to manage your to-do lists and share a common list between collaborators. It is a one-page app for normal users, whereas admin has a dedicated page to see user details.
  16.  
  17. Its original concept is as follows:
  18. * * *
  19.  
  20. ```Sujet :
  21. J'ai besoin d'une application pour gérer mes taches dans plusieurs domaines.
  22. Il me faut donc une application qui me permet de gérer plusieurs listes de taches.
  23. Je dois pouvoir créer une tache, modifier une tache, cocher une tache une fois que je l'ai réalisé.
  24.  
  25. Vu que personne n'a jamais créé une application qui permet de gérer des taches, j'aimerai la proposer au public et pouvoir gérer plusieurs utilisateurs qui se connecterai pour gérer leur taches dans des listes.
  26.  
  27. J'aimerai qu'une fois la tache réalisé elle disparaisse de ma liste. Mais j'aimerai pouvoir la retrouver dans mes archives pour savoir que je l'ai réalisée et quand est-ce que je l'ai réalisée.
  28.  
  29. Quand je termine toutes les taches d'une liste j'aimerai recevoir un mail qui me félicite.
  30. Et oui, c'est important d'encourager ces utilisateurs.
  31.  
  32. Pour la suite j'ai plusieurs idées de feature, dis moi ce que tu en penses:
  33. - J'aurais besoin d'un admin pour voir toutes les listes et toutes les taches de mes utilisateurs.
  34. - J'aimerai qu'on puisse rechercher les taches avec un champs texte. On m'a parlé d'Algolia, je sais pas si ça marche pour ça.
  35. - J'aimerai que certains utilisateurs puissent collaborer sur une liste de taches. Se serait une bonne feature payante ça!
  36. - J'aimerai avoir un reporting tous les matins qui me dise combien j'ai d'utilisateur, combien de taches ont été créées et combien de taches ont été terminées.
  37. ```
  38.  
  39. The above description is translated into the following realised functions,
  40.  
  41. * Different users can log in the site :heavy_check_mark:
  42.  
  43. * Each user can have multiple lists :heavy_check_mark:
  44.  
  45. * Each list can contain multiple tasks :heavy_check_mark:
  46.  
  47. * Each user can create, modify and check "done" their tasks :heavy_check_mark:
  48.  
  49. * Multiple users can work on the same list :heavy_check_mark:
  50.  
  51. * When a task is checked "done", it moves to the buttom of the list with a line through, the name of the user finished it and the date the task is finished :heavy_check_mark: (instead of "disappearing from the list" originally asked)
  52.  
  53. * When the last task of the list is checked "done" or deleted, which means all tasks in the list are finished, all users working on this list recives an email of congrats :heavy_check_mark:
  54.  
  55. * When the last task of the list is checked "done" or deleted, which means all tasks in the list are finished, the user no longer sees the list in his profile page :heavy_check_mark:
  56.  
  57. * Each user can click on a button to see all lists, including those completely finished :heavy_check_mark:
  58.  
  59. * Each user can search in history with key words. Lists including one or more tasks containing the key words will be returned as results :heavy_check_mark:
  60.  
  61. * Site admin has a dedicated page where all  users are listed. Admin can see username and email of any user, can delete their profile or see all their lists and tasks, with indication whether they are finished.:heavy_check_mark:
  62.  
  63. * Admin recieves (for the sake of easy testing) every 10 min, an email reporting the number of users and tasks, as well as new users, new tasks created and finished in the last 10 mins.:heavy_check_mark:
  64.  
  65. * * *
  66. ##### Time table
  67.  
  68. The first version of this app is developped in two weeks. Time spent in each part is as following (development happend more or less in the same order)
  69.  
  70. * BDD diagram, model (written in TDD) : 5.5 hours
  71.  
  72. * Controllers and 1st ajax : 16h
  73.  
  74. * 1st version of front : 6h
  75.  
  76. * Git + Heroku + CI setup : 6h (one of the great difficulties, had to ask for help from an experienced developper)
  77.  
  78. * 3 features: archived lists, search bar and admin interface: 9h (3h each)
  79.  
  80. * 2nd version of front : 8h
  81.  
  82. * mailer function for 2 mails : 4h
  83.  
  84. * Bug check after each Heroku deploiment : 4h
  85.  
  86. * Final correction: 3h
  87.  
  88. **Total: 61.5h ( 9 whole days)**
  89.  
  90. A project Trello is regularly kept and uodated. Time spent in such work is not counted.
  91.  
  92. Due to time limit, and to the developper's great regret, the app is delivered without controller optimization, controller and system tests nor refacto. These shall be done after delivery.
  93.  
  94. * * *
  95.  
  96. ##### Realisation of functions
  97.  
  98. Most of the functions are realised in straight-forward logics. Due to time limit, no particular effort are made to massively explore solutions that weren't known before this project, with only two exceptions:
  99.  
  100. * use of Heroku scheduler and rake job to send the "daily" report
  101.  
  102. _With a normal admin mailer and a mail view prepared, install the Heroku Scheduler addon. Define a rake job in `scheduler.rake`, set up to launch it every 10 min in heroku._
  103.  
  104. * use of class method for the search bar
  105.  
  106. _Create a `search` method in controller, linked to the User#search method, created in the model. The #search method uses `LIKE ?` sql query. Algolia suggested originally was not used,
  107. mainly due to timing, but also because using and API for such a simple project seemed exagerating._
  108.  
  109.  
  110. Other solutions came up include:
  111.  
  112. * For the User-List N-N relation : a join table
  113.  
  114. * For double update of task (meaning the normal "update" of a task changing its name and the "check done" update which changes its status): creation of `finish` method
  115.  
  116. * For deciding whether a list should be archived (thus disappearing from the user's normal profile and triggering the congrats email): creation of an instance method.
  117. The model provides one List-Task 1-N relation. `archived` method is an instance method in the model `List` that checks whether a list contains at list one task and whether
  118. the array containing all tasks' `finished` boolean includes `false`.
  119. In the `lists controller`, after every `finish` and `destroy`, this method is called and a congrats email is sent when necessary.
  120. The logic is twisted, but more really intelligent alternative was found in the tight timing.
  121.  
  122. * For users to be able to invite other user, use of select list within all existing user, avoiding miss typing the email or inviting unregistered user.
  123. All users already related to the list are excluded from selection, avoiding duplicates.
  124.  
  125. * For one page app: use of ajax. A simple "cheating" solution is found : a lot of ajax merely refreshes the page, causing a large number of queries at any action.
  126. Development was made easy by this way, but an impact on the loading speed is observed.
  127.  
  128. * For KPIs in the admin daily report: creation of class methods using `where`. If time had allowed, the `scope` option would have been preferred.
  129.  
  130. * * *
  131.  
  132. ##### Development principles
  133.  
  134. The developper had the following in mind during the project:
  135.  
  136. * Push as early and often as possible
  137.  
  138. * First find a solution. Only when it is possible, find a better one
  139.  
  140. * 20% of the UI detail means 80% to the users
  141.  
  142. * Don't get blocked. Ask, move on or abandon.
  143.  
  144.  
  145. * * *
  146.  
  147. ##### Difficulties and regrets
  148.  
  149. CI and testing are two major difficulties in the realisation of this project.
  150.  
  151. **CI**(external help was involved)
  152.  
  153. The notion of CI is new to the developper, who had just once successfully configured an app. In the attempt to reproduce the steps for [Colab](https://colab-task.herokuapp.com),
  154. it turned out localhost wouldn't work, nor would postgres locally. This developper had figured out her first app configuration without guidance nor structured information,
  155. causing a lot of incoherences in the CI setup of  Colab. After two days of struggle, a senior developper was consulted and corrected the configuration. This is the only external intervention
  156. in the development.
  157.  
  158. The issue was detected at an early stage of development, at the beginning of controllers development. The developper had hoped to work on the app alongside and discover the solution.
  159. However, by the time the 1st version of app was ready to be test in prod, the issue persisted. The developper inisisted on resolving this issue in order to push to staging,
  160. so that prod bugs be detected as early as possible.
  161.  
  162. Ever since correction of this difficulty, pushes to Heroku have been frequent.
  163.  
  164. **Testing**
  165.  
  166. The models were developped in TDD. The same method was attempted on the controllers, when the developper realized she didn't know how to test a one-page app.
  167. Later on, for timing reason, no more tests were added. If time had allowed, the developper would have at least written system tests gladly and look for resources on single-page app testing.
  168.  
  169. The tests are written in Minitest.
  170.  
  171. * * *
  172.  
  173. ##### Other limits
  174.  
  175. A lot of effort was deliberately put in the front of this project. Due to the timing, back has received less attention than it should.
  176.  
  177. * Only strictly the functions asked. Some "logical" functions were not available (user welcoming email. option to change user info by user or admin)
  178.  
  179. * Controller hardly has control on access (who can access to what, who can modify what etc)
  180.  
  181. * A lot of actions that may fails have no error messages displayed in UI
  182.  
  183. * Mails have no css
  184.  
  185. * Average responsiveness
  186.  
  187. * Each action triggers an ajax that refreshes almost the whole page. Speed is impaired.
  188.  
  189. * Things can certainly be refactored
  190.  
  191.  
  192. * * *
  193. ##### Takeaways
  194.  
  195. * This developper definitly needs guidance
  196.  
  197. * Asking for help does limit time loss
  198.  
  199. * Pushing as early and often as possible proves to be the right thing to do. Almost no prod bugs are encountered in this project
  200.  
  201. * Maybe next time. more reflection **before** action. This time, too much back and forth in simple stuff.
  202. Maybe blocking a time to explore all desired technologies would lead to more opportunites to test new stuff.
  203.  
  204. * Front can be fun
  205.  
  206. * * *
  207. ##### Technical specifications
  208.  
  209. * Ruby version: 2.6.4
  210.  
  211. * Rails version: 6
  212.  
  213. * gems: devise, faker, table_print, letter_opener, pry, simplecov among others
  214.  
  215. * Google Fonts are used, Firefox doesn't show the font
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
 
Top