address feedback by clemens

[hannesdatta]

• git
o does Tilburg university have a git server?
o in the Data Science Team at the CPB we use a gitlab server to keep track of our projects and use issues to keep track of tasks and their allocations. I find that to work amazingly well.
o this might be controversial. but mention one of the GUIs for git.
 starting to learn git via command line is tough and keeps people from actually using branches.
o in my experience git pull requests are where most of the problems happen. so this should be covered or at least linked to a good guide.
• What's the state of the russet servers? (Jupyter running on the servers of the UvT) I've heard that they were replaced.
• mention github education package. (https://education.github.com) which gives students (and faculty) a free pro account and some other goodies.
• With respect to the pipeline: I'd also add something about always noting which versions of software were used by a project. For python this can be done with a file called requirements.txt' o That way one always knows what version of (e.g.) pandas in python a piece of code was written with and reproduce the old results reliably • Are you planning to automatically updating all the version numbers? (R 3.4.1) otherwise something like R 3.x.x might be better. • Nothing about Julia? • Web Scraping: Browser emulation seems overkill for many applications. So also good to mention lxmlorbeautiful soup` in the web-scraping section
o also: you only mention selenium by name in the python extra session.
• API's should definitely be mentioned.
• I'd always mention alternatives: e.g.
o ``We recommend you to use github but there are also alternatives (gitlab)''
o (examples; Gitlab for git. MS visual studio code, emacs for editors)
o One exception being python < 3.6.x. Those versions don't exist.
• Also useful could be to link to documentation guides;
o example: https://www.python.org/dev/peps/pep-0008/
o surely people are not going to stick to it. but mentioning one guide might make documentation bearable to read.
• I'd also make a strict separation between guides on how to install software, workflow guides and specific applications (like webscraping)
• The concept of unit tests might be very useful for people working on bigger models. (i.e. programming automatic tests for components of the programme. i.e. choosing some parameters and checking if demand is always in (0,1), is increasing in prices) I found them quite useful to do automatic sanity tests of my

Just saw this article on Heise. @maciej sorry its in German.
• https://www.heise.de/developer/artikel/Was-zeichnet-lesbaren-Code-aus-4671909.html
Hope this helps in some way.
Best,
Clemens

PS: Ok, one last thing.

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

[maciej]

Hey @hannesdatta! I've been mentioned in this ticket. I believe you meant someone else.

[hannesdatta]

Indeed, used the wrong handle. Sorry for that! Outlook voor Android downloaden<https://aka.ms/ghei36>

…

________________________________ From: Maciej Biłas <[email protected]> Sent: Wednesday, March 25, 2020 10:56:37 PM To: hannesdatta/tilburg-science-hub <[email protected]> Cc: Hannes Datta <[email protected]>; Mention <[email protected]> Subject: Re: [hannesdatta/tilburg-science-hub] address feedback by clemens (#22) Hey @hannesdatta<https://github.com/hannesdatta>! I've been mentioned in this ticket. I believe you meant someone else. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#22 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AD6KNIX7AWPEE4EUET4QCNDRJJ4ZDANCNFSM4LMV3QJA>.