Verified Commit 976a3e74 authored by Laurent Heirendt's avatar Laurent Heirendt
Browse files

add ppc cards from internal

parent ff99bb33
---
layout: page
permalink: /internal/ppc/add-gitignore/
shortcut: ppc:add-gitignore
redirect_from:
- /cards/ppc:add-gitignore
- /internal/cards/ppc:add-gitignore
---
# Add a .gitignore to your repository
The version control system git tracks all files in a repository.
Sometimes, you do not want certain files or directories to be tracked, but fully ignored by `git`. These files or directories
can include binaries, images, dependencies, log files, or analysis results. Also, hidden system files are usually picked up by `git`.
The idea is to create a file named `.gitignore` that lists all the files and directories that should be ignored by `git`.
For instance, in order to ignore all log files with the suffix `.log`, the content of the `.gitignore` file should be:
```
*.log
```
A common example is to ignore system files as well, such as the `.DS_Store` file:
```
.DS_Store
```
*Note:* Sometimes, you might not see the hidden system files. You can do so by browsing to the directory in the terminal and typing:
```bash
$ ls -lash
```
Once the `.gitignore` file has been created, you can add and commit the file as any other file in the `git`-tracked repository. A relatively complete collection of `.gitignore` templates can be found [here](https://github.com/github/gitignore).
More information on the `.gitignore` mechanism can be found [here](https://www.atlassian.com/git/tutorials/saving-changes/gitignore).
---
layout: page
permalink: /internal/ppc/publish-repo/
shortcut: ppc:publish-repo
redirect_from:
- /cards/ppc:publish-repo
- /internal/cards/ppc:publish-repo
---
# Publish a repository
By default, the repositories created on the LCSB Gitlab are private, i.e. they cannot be seen by anyone outside LCSB.
In order to change the visibility of the repository, you can do so by browsing to `Settings` and then expanding the section on `Visibility, project features, permissions`.
There, you can set the visibility to `Public`. It is important to note that the group must be public in order to change visibility of the repository.
Remember to follow the [LCSB policy regarding code development](https://howto.lcsb.uni.lu/?policies:LCSB-POL-BIC-07). In case of questions, please do not hesitate to contact the [R3 team](mailto:lcsb-r3@uni.lu).
\ No newline at end of file
---
layout: page
permalink: /internal/publication/10WaysImproveEnglish/
shortcut: publication:10WaysImproveEnglish
redirect_from:
- /cards/publication:10WaysImproveEnglish
- /internal/cards/publication:10WaysImproveEnglish
---
# 10 ways to improve your English
Francisco ARAGAON ARTACHO, former postdoc in the Systems Control group, has made a list of the ten most important points that helped to improve his English. In this article he shares them with you and explains what he means by each of them.
**1. Believe improving your English is something very important**
I think this is the most important point. If you don't believe a good written English is important, you will never improve it. So... why is it important? The way you write will give your reader a first impression about you. Even more, the reader will even get an impression about your personality (tidy / messy / arrogant / smart / knowledgeable / dumb). He / she probably doesn't know you, nor knows how good your ideas are. Don't give him / her a bad first impression: it will be hard to change his/her mind. While refereeing, I've directly rejected several papers because the English was terribly bad, or because it was full of typos. Nobody wants to read a text with many typos and which is clearly against the "golden rule" to never make a referee angry! Before submitting a paper / grant proposal, check it carefully. If one of your co-authors is a native English speaker, ask him / her to check the grammar of what you wrote. If not, ask a friend. If possible, wait for a week and read it again. You will probably discover that what you wrote is not as nice as you thought. You will find many typos and errors.
**2. Read**
Read as much texts in English as you can, especially novels. If you read good writers, perhaps (probably) something good will stick in your mind. Try to use their "fancy words and sentences" whenever it is possible.
**3. Listen**
I believe listening to music and watching movies / TV shows helped a lot to improve my English. Even during the most boring talk at a conference you may learn something good for your English.
**4. Use synonyms**
Synonyms are good. Avoid repeating words / structures whenever is possible. Use as many different sentence connectors as you can / know. Your text will look better and will be nicer to read. I normally use [Thesaurus](http://thesaurus.reference.com/).
**5. Use a dictionary**
While writing, I always have a dictionary open in my browser. I especially like [wordreference.com](http://www.wordreference.com/), which even has the British / American pronunciation for many words.
**6. Check what Google says about your sentences**
If you're not sure about a sentence you wrote, google it (or part of it), using quotation marks. If there are only a few hits, your sentence is probably wrong. If you doubt between two versions of the same sentence, the one with more results in Google is probably going to be the correct one.
**7. Write short sentences**
Long sentences make the reader feel exhausted, so do your best to avoid them. Try to punctuate correctly: use commas, colons, and semicolons.
**8. Write short paragraphs**
In a similar way to the previous point, long paragraphs are exhausting. I remember that when I was a kid I hated books without "white space" (breaks), and I guess I still have some similar feeling. A text with short paragraphs always looks easier to read at first glance. Additionally, while aiming to write short paragraphs, you will be forced to structure your ideas (next point).
**9. Structure your thoughts through the text**
Structure your ideas to explain yourself. It is very important to use sentence connectors, as for example: moreover, however, besides, although, nevertheless, in spite of, then, therefore, thus, hence, whence, on one hand / on the other hand, additionally, further, furthermore, otherwise...
**10. Ask people to correct you**
People (wrongly) believe that it is impolite to correct others when they're not speaking in their native language. I guess this happens because no one likes to be wrong, and even less to be pointed out for being wrong. At the beginning, when I started learning English, people used to correct me very often. Unfortunately, as soon as my English was "good enough", I noticed that I was getting less and less corrections, despite my English wasn't that good. For example, only last year my Aussie housemate told me that I was pronouncing "yellow" wrong (and, probably, every single word starting with "y" - pronouncing it like "j" in "jelly") because he wanted to piss me off. At that moment I guess he was disappointed to see that I liked to be corrected, but he started telling me my mistakes since then. Thus, if you want to be corrected you'll need to ask the others to do it, and remember to thank them with a not-very-fake-looking smile when they do it :).
---
layout: page
permalink: /internal/publication/publishInBiotools/
shortcut: publication:publishInBiotools
redirect_from:
- /cards/publication:publishInBiotools
- /internal/cards/publication:publishInBiotools
---
# Publishing a tool in *bio.tools*
First, *bio.tools* serve two main purposes:
- dissemination of your tools
- collecting systematic and reasonable statistics about the available
software for many purposes, including data science and performance reports
To get your contents in, you need to fill an application and get an account.
Filling out the application is particularly straightforward.
After you get the account, you can click "Add content" in the "Menu" on the top
right, then go through around 10 tabs that allow you to fill lots of
interesting information about your tool, and finally submit it, which makes the
contents immediately visible.
This card collects some reminders about what you should not forget while
submitting the tool, perhaps useful as a checklist.
## General tips
### Use search and consult the curation guide to resolve ambiguities
The guide is currently here:
https://biotools.readthedocs.io/en/latest/curators_guide.html#summary-group
It includes helpful and authoritative guidelines for almost all fields that you
can fill, including examples.
As the last resort when you do not know what to do with a field, you can try
search suggestions in the structured search box above, and try to be at least
consistent with the rest of the database. In the search box, type in a single
letter, wait for a moment (or press arrow down), choose the annotation
category, and see what others have used.
### Add a "backup" maintainer
This may remove a lot of unnecessary workload from you, and will help everyone
at times when you are not available. (Or, at least, reduce the stress levels.)
### Add _many_ links to all types of documentation
This helps in two ways:
- The search engines will be able to categorize and index your contents better,
possibly giving more helpful links to your tools.
- Users of *bio.tools* will be able to explore the most relevant parts of your
documentation very quickly, helping them to make a faster decision about
using your tool. For example, it is often a relief to quickly see that a
bioinformatics tool has an explicit step-by-step tutorial, and that a web
visualization framework has a complete useful API reference.
Include the (interesting) relations to other tools. This adds a bit more
interesting data to both search engines and statisticians who process
*bio.tools* content, and gives an documentation of possible "use-cases".
## Proper labeling
### Choose the bio.tools ID correctly
As the name says, the "Persistent biotoolsID" cannot be changed. It will be
permanently displayed as an identifier in almost all content that is
autogenerated from *bio.tools*. For users, that concerns mainly the URLs, so
you may want to apply similar formatting guidelines as for URLs (use hyphens
`-` instead of underscores `_`, do not use capital letters, ...).
### Add your tool to proper collections
Collections group the results of various larger cooperated (or loosely
organized) efforts, such as "Galaxy tools", "Parkinson disease research", and
"3D BioInfo".
If your tool is related to ELIXIR, you should fill in the correct ELIXIR node,
platform, community _and_ collection. Remember to:
- Add _all_ involved ELIXIR nodes.
- **Add your tool to the node-specific ELIXIR collections.** For LCSB, that is
usually **ELIXIR-LU**. This is counter-intuitive and seems duplicate to the
categorization by ELIXIR nodes, but:
- at least 2 nodes use collections labels instead of node labels to scrape
data about their tools
- there is search support only for the collections; currently (March 2021) it
seems that you cannot easily search for tools by ELIXIR nodes
### Fill in the tool "Function" very verbosely
The main reason for categorizing tool functions is to provide a systematic way
for listing the tools in topic-based catalogues that can be browsed by users.
The categories and data formats available for describing your tool function
rarely give a precise match. That is okay, you can choose a broader category.
Use all categories that match even a small part of your tool; it will
potentially help *bio.tools* users to find your tool even if they do not know
what precisely they are searching for.
Selecting a very specific category ("deeper" in the topic tree) also implies
all "parent" categories, so you do not have to be afraid of over-specification.
*Bio.tools* search box will automatically include your tool in searches for the
broader categories.
## References and publications
### Be comprehensive about publications
Add _all_ publications where you described, showcased, and benchmarked the
tool. Also add preprints.
There are several purposes for the precise publication tracking:
- the users may (and often will) sort the tools by the citation count, likely
trying the most tested approach first
- the publications provide an additional form of documentation (often more
colorful than the API docs)
- the links and citation counts provide a nice, easily available statistic
about ELIXIR performance
### Use the Credit tab
The purpose of the "Credit" tab is not immediately obvious -- basically, you
can credit anything that has helped you with creating the tool. This is
currently used for at least 3 purposes:
- systematic tracking of non-ELIXIR collaborators (add ORCIDs)
- listing the **industry partners**
- listing affiliations to particular research institutions
(**remember to add LCSB**)
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment