remove old things
Deploy / Deploy (push) Successful in 2m17s
Details
Deploy / Deploy (push) Successful in 2m17s
Details
This commit is contained in:
parent
646f89a535
commit
52ab524be0
|
|
@ -21,6 +21,7 @@ markdown: kramdown
|
|||
gems:
|
||||
- jekyll-scholar
|
||||
- jekyll-feed
|
||||
|
||||
exclude:
|
||||
- Gemfile
|
||||
- Gemfile.lock
|
||||
|
|
@ -48,7 +49,7 @@ plugins: ['jekyll/scholar']
|
|||
# The publications plugin
|
||||
scholar:
|
||||
#Checkout this github: https://github.com/citation-style-language/styles
|
||||
style: mystyle.csl #apa #chicago-fullnote-bibliography #apa
|
||||
style: _includes/csl/mystyle.csl #apa #chicago-fullnote-bibliography #apa
|
||||
locale: en
|
||||
|
||||
sort_by: year, month
|
||||
|
|
|
|||
|
|
@ -1,19 +0,0 @@
|
|||
---
|
||||
layout: post
|
||||
author: Flávio Schiavoni
|
||||
title: One file, several owners
|
||||
lang: en
|
||||
lang-ref: One-file-several-owners
|
||||
---
|
||||
|
||||
It is possible that the same file on Linux has more than one user authorized to change it. Unlike chmod which only allows one owner on one file, the setfacl command allows adding permissions for multiple users on the same file. For this, we use the command:
|
||||
|
||||
<pre>
|
||||
setfacl -R -m user:LOGIN:rwx /FOLDER/FILE
|
||||
</pre>
|
||||
|
||||
To check which users have permissions on a file:
|
||||
|
||||
<pre>
|
||||
getfacl FILE
|
||||
</pre>
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
---
|
||||
layout: post
|
||||
author: Flávio Schiavoni
|
||||
title: Transforming directories into versioned repositories
|
||||
lang: en
|
||||
lang-ref: Transforming-directories-into-versioned-repositories
|
||||
---
|
||||
|
||||
A code repository, quite broadly, is a directory that contains files that have version control. This includes the possibility of auditing file changes, checking for possible changes from one version to another and even returning the file to a previous version.
|
||||
|
||||
Although we are used to using remote repositories, such as github or another similar service, it is possible with git to maintain any local directory as a versioned repository. This allows to audit modifications and guarantees a certain security because it would allow to check all previous versions of a file.
|
||||
|
||||
To transform a directory into a git repository, use the command:
|
||||
|
||||
<pre>
|
||||
git init --bare --shared
|
||||
</pre>
|
||||
|
||||
* --bare initialize the git repository to be a remote repository
|
||||
* --shared sets write permissions for group
|
||||
|
||||
Once the repository is started, it is necessary to add all files to it:
|
||||
|
||||
<pre>
|
||||
git add *
|
||||
</pre>
|
||||
|
||||
Then, you need to identify yourself:
|
||||
|
||||
<pre>
|
||||
git config --global user.email "alice@alice.dcomp.ufsj.edu.br"
|
||||
git config --global user.name "Alice"
|
||||
</pre>
|
||||
|
||||
Finally, submit the changes with the command:
|
||||
|
||||
<pre> git commit -m "Versão inicial do projeto"</pre>
|
||||
|
||||
With this, with each modification you want to save, just add the changed files and commit.
|
||||
|
||||
More information: [https://git-scm.com/book/en/v2/Git-on-the-Server-Getting-Git-on-a-Server]
|
||||
|
|
@ -1,64 +0,0 @@
|
|||
---
|
||||
layout: post
|
||||
author: Flávio Schiavoni
|
||||
title: Changing our website
|
||||
lang: en
|
||||
lang-ref: Changing-our-website
|
||||
---
|
||||
|
||||
# Source code and page
|
||||
|
||||
Our website uses Jekyll as a dynamic generator for a static website.
|
||||
The website is in the /var/www/html directory while the source code is in the /var/www/src folder.
|
||||
Do not change the site directly in the html folder, any change must be made in the src folder or it may be deleted in the next update.
|
||||
After changing a file, generate the site with the command:
|
||||
|
||||
<pre>
|
||||
./update.sh
|
||||
</pre>
|
||||
|
||||
Never use the sudo command to update the site.
|
||||
If your user does not have permission to change the site, change the file permissions.
|
||||
See [this post] (https://alice.dcomp.ufsj.edu.br/2020/01/21/Um-arquivo-varios-donos.html) for this.
|
||||
|
||||
|
||||
# Blog
|
||||
|
||||
The files for this blog are in the \_posts folder. See the existing files and follow the template. Note that the pattern of names of these files matters and will be used to create the index on the site. The name defaults to year-month-day-title.md. Example:
|
||||
|
||||
<pre>
|
||||
2020-03-26-Alterando-o-nosso-site.md
|
||||
</pre>
|
||||
|
||||
Our generator is configured to work in an incremental way, therefore, by having the website updated with the update command, only the files changed in the last modification will be updated.
|
||||
If the blog home page is not changed after the update command, update the modification date of the blog.html file with the touch command and then use the update command. This tip applies to any file that needs to be generated again and has not been changed.
|
||||
|
||||
<pre>
|
||||
touch blog.html
|
||||
./update.sh
|
||||
</pre>
|
||||
|
||||
|
||||
# Images
|
||||
|
||||
Images and other resources on the site are in the assets folder.
|
||||
The photos of the events and other photos are in the pics folder.
|
||||
These photos are listed by yml files available in the \_data folder.
|
||||
To add a new photo slide show, add the images to a directory in the pics folder and create a list of these photos in the \_data folder.
|
||||
Then, just link these photos in the include of the carrousel as a collection.
|
||||
|
||||
<pre>
|
||||
include carousel.html height="50" unit="%" duration="7" collection=site.data.[nome do arquivo].images
|
||||
</pre>
|
||||
|
||||
# Auditando modificações
|
||||
|
||||
The src folder is a git repository, although it does not have remote copies.
|
||||
After changing the site content, please add the changes and commit.
|
||||
Use the git commands for this.
|
||||
|
||||
<pre>
|
||||
git status
|
||||
git add [arquivos modificados]
|
||||
git commit -m "mensagem do commit"
|
||||
</pre>
|
||||
|
|
@ -1,228 +0,0 @@
|
|||
---
|
||||
layout: post
|
||||
author: Luan Luiz Gonçalves
|
||||
title: Development flow with the GitFlow model
|
||||
lang: en
|
||||
lang-ref: Development-flow-with-the-GitFlow-model
|
||||
---
|
||||
|
||||
# GitFlow
|
||||
|
||||
GitFlow is a branch model for software development, using the *git* version control tool. This model, created by software engineer *Vincent Driessen*, became popular. According to * Driessen *, suitable for software with explicit versioning or to maintain multiple software versions, ensuring stability of the main branch during the development process.
|
||||
|
||||
{% include image.html url="/assets/posts_imgs/gitflow.png" description="Figura 1: Fluxo de desenvolvimento do modelo de ramificação GitFlow." width="80%" height="80%" align_class="aligncenter" %}
|
||||
|
||||
<br>
|
||||
|
||||
The model has an organization of branches and workflow that makes it easy to find points of code changes, easily visualizing each implementation.
|
||||
|
||||
# Repositórios remotos
|
||||
|
||||
The project repository is centralized. Each developer contains a *fork* from the central repository to *push* the changes / commits instead of directly manipulating the central repository. Thus, for changes to be added to the central repository, the developer must create a *Pull Request*, allowing project administrators to review the changes before accepting them. *Pull* can also be made between forks, creating sub-teams to work on the same implementation - sub-teams of two or more members. The following image shows this configuration of remote repositories:
|
||||
|
||||
{% include image.html url="/assets/posts_imgs/centr-decentr.png" description="Figura 2: Configuração de repositórios: Centralizado mas descentralizado." width="60%" height="60%" align_class="aligncenter" %}
|
||||
|
||||
<br>
|
||||
|
||||
In the previous image, origin refers to the central repository and the other repositories are the central forks - Alice, Bob, David and Chair. The image illustrates the Alice / Bob, Alice / David and Clair / David sub-teams. It is worth mentioning that there is no Pull Request made to the central repository for changes in work in progress, the developer or a sub-team must finish the work in their respective fork before making the Pull Request.
|
||||
|
||||
|
||||
# Branches
|
||||
|
||||
In the GitFlow model, the central repository of the project contains two branches: * master * and * develop *, both with infinite life. The master is the main branch and its source code (HEAD) is always a stable version - production release. The develop branch always contains full feature implementations for the next release.
|
||||
|
||||
Developers do not work directly on the master and develop branches. Supporting branches are created for implementing bug fixes, implementing features, changing release metadata and other release processes. Unlike master and develop, support branches are finite and have implementations in progress.
|
||||
|
||||
Types of support branches:
|
||||
|
||||
* *Feature*: for implementing new features;
|
||||
* *Release*: for release processes like metadata changes and software packaging;
|
||||
* *Hotfix*: for bug fixes that can't wait for the next release.
|
||||
|
||||
Each of the types, in addition to having a specific purpose, are subject to strict rules about which branches may be their source branch and which branches should be their merging destinations, being categorized by the form of use. Next, we will see the details of each of the types of support branches, in parallel with examples illustrating the workflow of the GitFlow model and the commands used in each step!
|
||||
|
||||
|
||||
# Branches feature
|
||||
|
||||
{% include image.html url="/assets/posts_imgs/feature-branchs.png" width="18%" height="18%" align_class="alignright" description= "Figura 3: Branch feature." %}
|
||||
|
||||
Rules:
|
||||
|
||||
* Branching from the develop branch;
|
||||
* After finalizing the implementation, they are merged into the develop branch;
|
||||
* There is no name convention, the name only refers to the feature under development;
|
||||
* They exist only in the forks of the central repository.
|
||||
|
||||
**Creating a branch feature**
|
||||
|
||||
To implement a new feature, a support branch of the feature type is created from the develop branch. Example:
|
||||
|
||||
<pre>
|
||||
$ git checkout -b myfeature develop
|
||||
Switched to a new branch "myfeature"
|
||||
</pre>
|
||||
|
||||
The command `git checkout` with the parameter` -b <branch name> `, creates the branch and changes to the created branch. The develop parameter, at the end of the command, informs you that the branch will be created from the develop branch.
|
||||
|
||||
**Merge the branch feature into the develop branch**
|
||||
|
||||
After completing the implementation of the feature in the *myfeature* branch, the branch is merged into the develop branch. Once the merge is done, we delete the *myfeature* branch and upload the changes (push) to the developer's remote repository. For this, we use the following commands:
|
||||
|
||||
<pre>
|
||||
$ git checkout develop
|
||||
Switched to branch 'develop'
|
||||
$ git merge --no-ff myfeature
|
||||
Updating ea1b82a..05e9557
|
||||
(Summary of changes)
|
||||
$ git branch -d myfeature
|
||||
Deleted branch myfeature (was 05e9557).
|
||||
$ git push origin develop
|
||||
</pre>
|
||||
|
||||
In this and the following example, the *origin* parameter is the link to the developer's remote repository.
|
||||
|
||||
The `--no-ff` flag causes the merge to always create a commit to record the historical existence of a branch, grouping the commits of the branch. Compare, in Figure 4, the merge command with and without the flag:
|
||||
|
||||
{% include image.html url="/assets/posts_imgs/merge-flags.png" width="65%" height="65%" align_class="aligncenter" description="Figura 4: Diferença entre o merge com e sem a flag –no-ff." %}
|
||||
|
||||
<br>
|
||||
|
||||
If we don't use the flag, we would have to read the commits' log messages to identify which commits are consolidating an implementation together. With the flag, this identification becomes much easier. Figure 4 highlights the commits that consolidate the implementation of a feature, in both situations.
|
||||
|
||||
# Branches release
|
||||
|
||||
Rules:
|
||||
|
||||
* Branching from the develop branch;
|
||||
* After finalizing the implementation, they are merged into the develop and master branches;
|
||||
* Naming convention: `release- <version number>`.
|
||||
|
||||
|
||||
In the branch release, we finish the software release. The metadata is changed, updating the version number of the software and performing other release procedures such as packaging the software. In addition, minor bug fixes are allowed. The branch is created when the implementations in the develop branch are in a state very close to the new software release.
|
||||
|
||||
Finishing the release process, the release branch is merged for the develop branch and the for the master branch. At this point, the develop branch is free to implement new features in a future release.
|
||||
|
||||
|
||||
**Creating the branch release**
|
||||
|
||||
In this example, number 1.2 is the release version. Note that the branch name follows the `release- <version number>` convention:
|
||||
|
||||
<pre>
|
||||
$ git checkout -b release-1.2 develop
|
||||
Switched to a new branch "release-1.2"
|
||||
$ ./bump-version.sh 1.2
|
||||
Files modified successfully, version bumped to 1.2.
|
||||
$ git commit -a -m "Bumped version number to 1.2"
|
||||
[release-1.2 74d9424] Bumped version number to 1.2
|
||||
1 files changed, 1 insertions(+), 1 deletions(-)
|
||||
</pre>
|
||||
|
||||
After creating the branch and switching to it, we carry out the release procedures. The *bump-version.sh* file is a fictional script that changes the metadata files to reflect the new version. After executing the script, we commit to record the changes.
|
||||
|
||||
|
||||
**Finalizing the branch release**
|
||||
|
||||
When the state of the release branch is ready to become a real release, some actions need to be taken. First, the release branch is merged into the master (since every commit on the master is a new release by definition, remember). Then, we assign a *tag* to this commit on the master, to have a reference to this historical version. Finally, changes made to the version branch need to be merged back into the develop branch, so that future versions will also contain those changes.
|
||||
|
||||
The first two steps in Git:
|
||||
|
||||
<pre>
|
||||
$ git checkout master
|
||||
Switched to branch 'master'
|
||||
$ git merge --no-ff release-1.2
|
||||
Merge made by recursive.
|
||||
(Summary of changes)
|
||||
$ git tag -a 1.2
|
||||
</pre>
|
||||
|
||||
Merging the branch release into the develop branch:
|
||||
|
||||
<pre>
|
||||
$ git checkout develop
|
||||
Switched to branch 'develop'
|
||||
$ git merge --no-ff release-1.2
|
||||
Merge made by recursive.
|
||||
(Summary of changes)
|
||||
</pre>
|
||||
|
||||
This step can lead to a merge conflict. If so, correct and confirm.
|
||||
|
||||
Now, the release process has been completed and the release branch can be removed, as we no longer need it:
|
||||
|
||||
<pre>
|
||||
$ git branch -d release-1.2
|
||||
Deleted branch release-1.2 (was ff452fe).
|
||||
</pre>
|
||||
|
||||
# Branches hotfix
|
||||
|
||||
{% include image.html url="/assets/posts_imgs/hotfix-branchs.png" width="40%" height="40%" align_class="alignright" description="Figura 5: Branch hotfix." %}
|
||||
|
||||
|
||||
Rules:
|
||||
|
||||
* Branching from the master branch;
|
||||
* After finalizing the implementation, they are merged into the master branch;
|
||||
* Naming convention: `hotfix- <version number>`.
|
||||
|
||||
|
||||
Hotfix branches are very similar to release branches, as they also deliver a new version of the software, although not planned. They arise from the need to act immediately in an unwanted state from a released production version - production version.
|
||||
|
||||
When there is a critical error in a production version, we cannot wait for the next release to fix it. If so, a hotfix branch is created for the fix. The essence is that the work of team members (in the develop branch) can continue as long as the correction is made.
|
||||
|
||||
**Creating the hotfix branch**
|
||||
|
||||
This branch is created from the master and its name follows the `hotfix- <version number>` convention. In the following example, the bug is in version *1.2* (1.2.0) and we have added the third version number. This increment follows the rules of [Semantic Versioning 2.0.0] (https://semver.org/):
|
||||
|
||||
<pre>
|
||||
$ git checkout -b hotfix-1.2.1 master
|
||||
Switched to a new branch "hotfix-1.2.1"
|
||||
$ ./bump-version.sh 1.2.1
|
||||
Files modified successfully, version bumped to 1.2.1.
|
||||
$ git commit -a -m "Bumped version number to 1.2.1"
|
||||
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
|
||||
1 files changed, 1 insertions(+), 1 deletions(-)
|
||||
</pre>
|
||||
|
||||
After creating the branch and increasing the version number in the metadata files, we can fix the bug in one or more commits:
|
||||
|
||||
<pre>
|
||||
$ git commit -m "Fixed severe production problem"
|
||||
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
|
||||
5 files changed, 32 insertions(+), 17 deletions(-)
|
||||
</pre>
|
||||
|
||||
**Terminating the hotfix branch**
|
||||
|
||||
Upon completion of the bug fix implementation, the hotfix branch is merged with the master and develop branches. First, update the master and tag the version with the tag:
|
||||
|
||||
<pre>
|
||||
$ git checkout master
|
||||
Switched to branch 'master'
|
||||
$ git merge --no-ff hotfix-1.2.1
|
||||
Merge made by recursive.
|
||||
(Summary of changes)
|
||||
$ git tag -a 1.2.1
|
||||
</pre>
|
||||
|
||||
Then include the bug fix in develop as well:
|
||||
|
||||
<pre>
|
||||
$ git checkout develop
|
||||
Switched to branch 'develop'
|
||||
$ git merge --no-ff hotfix-1.2.1
|
||||
Merge made by recursive.
|
||||
(Summary of changes)
|
||||
</pre>
|
||||
|
||||
Finally, remove the hotfix branch:
|
||||
|
||||
<pre>
|
||||
$ git branch -d hotfix-1.2.1
|
||||
Deleted branch hotfix-1.2.1 (was abbe5d6).
|
||||
</pre>
|
||||
|
||||
|
||||
# References
|
||||
|
||||
1. [https://nvie.com/posts/a-successful-git-branching-model/](https://nvie.com/posts/a-successful-git-branching-model/)
|
||||
|
|
@ -1,61 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: About
|
||||
displaymenu: true
|
||||
lang: en
|
||||
---
|
||||
|
||||
ALICE
|
||||
-----
|
||||
|
||||
ALICE is the name of a laboratory in the Computer Science Department at the Federal University of São João del-Rei. The name of the lab is an achronimous to Arts Lab in Interfaces, Computers, and (Education, Exceptions, Experiences, Entertainment, Environment, Entropy, Errors, Everything, Else and Etcetera...).
|
||||
|
||||
This name is also a good hint to understand some concepts about the lab.
|
||||
|
||||
Firstly, a direct reference to Lewis Carroll book, Alice in the wonderland, can bring the idea of some non sense, fantasy and peculiar ideas that could guide researches on the lab. Lewis Carroll, a mathematician, used logic to entertain child and to create art. Certainly it is not a “really serious” lab and we believe that it is possible to have interesting computer science involving, mathematics, arts and humanities.
|
||||
|
||||
Secondly, it is an Art Lab. The presence of arts in the name can be another good hint to understand that we are worried about creative process and some ephemerous software creation, group performance and soon. We are also worried about interfaces and how the man can interact with the world, specially when involving computers to perform this interaction.
|
||||
|
||||
Thirdly, the infinity possibilities of an open name, that includes everything else, can really be a good chance to keep an open mind when thinking about computer science and art research.
|
||||
|
||||
Our current research involves:
|
||||
* Creation of New Interfaces for Musical Expression
|
||||
* Development of Art pieces using WebArt and Other open technologies
|
||||
* Research of creative process and collaboration in art creation
|
||||
* Investigation in audience Participation and interaction in Digital Performance
|
||||
* Research Art and Sustainability, specially Digital Art
|
||||
|
||||
Who are we?
|
||||
-----------
|
||||
|
||||
Most part of the members of this lab are computer science undergraduate students, studying computer science. There are also master's students in computer science (PPGCC - Programa de Pos Graduação em Ciência da Computação) and master’s students in Arts, Urbanities and Sustainability (PIPAUS - Programa Interdepartamental de Pos-graduação Interdisciplinar em Artes, Urbanidades e Sustentabilidade).
|
||||
|
||||
Since ALICE started to be an laboratory to art creation, some students in Music, philosophy, scenic arts, applied arts, music and also professors from different areas joined us in our projects.
|
||||
|
||||
Orchidea
|
||||
--------
|
||||
|
||||
|
||||
The Art development in ALICE is made by the Orchidea - an Orchestra of Ideas.
|
||||
|
||||
The Orchidea focuses on the development of collaborative art and the creation of an environment that encompasses students from diverse areas, be it theater, music, computer science, architecture, philosophy and others, to create art together.
|
||||
|
||||
By approaching this transdisciplinary concept, Orchidea ends up being a very promising environment in relation to the collective learning of the students, since students from different areas, have different abilities, which in group, can be shared, making the students help each other among themselves, overcoming their difficulties. Initially, the idea of the name of the group appeared in 2015, with the implementation of the tool called Orchidea. This tool was a mobile application, implemented in Java, where its purpose was to enable the creation of a mobile orchestra. The application was developed by an undergraduate student, who at the end of his monograph, ended up giving no continuity to the project.
|
||||
|
||||
In 2016, as a final result of the discipline of Introduction to Computer Music, Orchidea was resumed, gaining a second version, now based on the Web Audio API and mobile device sensors. Finally, in 2018, based on the need to create art and study new aesthetic concepts associated with technologies, our digital art group was finally created.
|
||||
|
||||
Currently, Orchidea has undergraduate and graduate students, and its objectives can be described as:
|
||||
* Fostering and performing digital artistic creations;
|
||||
* Integrate transdisciplinary knowledge of different areas through art;
|
||||
* Stimulate the collective and collaborative creation of art supported by the computer;
|
||||
* Use affordable and more sustainable technology for artistic creation;
|
||||
* Use and create free software for the diffusion of artistic creation and Enable public participation in the presentation and artistic creation that can happen anytime, anywhere.
|
||||
|
||||
Address
|
||||
-------
|
||||
|
||||
Universidade Federal de São João del-Rei – UFSJ
|
||||
Campus Tancredo de Almeida Neves – CTAN
|
||||
Prédio do Curso de Ciência da Computação, 3° andar/Sala nº 3.01A
|
||||
Av. Visconde do Rio Preto, s/nº, Colônia do Bengo,
|
||||
São João del-Rei, MG, CEP 36301-360
|
||||
20
_en_/art.md
20
_en_/art.md
|
|
@ -1,20 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Artistic Projects
|
||||
lang: en
|
||||
---
|
||||
|
||||
{% assign projects = site.projects | where:"project_type", "artistic" %}
|
||||
<div>
|
||||
{% for item in projects %}
|
||||
{% include project.html %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
|
||||
|
||||
<br style="clear: both;">
|
||||
|
||||
The Art development in ALICE is made by the Orchidea - an Orchestra of Ideas.
|
||||
|
||||
|
||||
Check our [Publications Page](publications.html) to see more about it.
|
||||
18
_en_/blog.md
18
_en_/blog.md
|
|
@ -1,18 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Blog
|
||||
displaymenu: true
|
||||
lang: en
|
||||
---
|
||||
|
||||
{% assign lang_posts = site.posts | where:"lang", "en" %}
|
||||
{% for post in lang_posts %}
|
||||
<div class="post-area">
|
||||
<p class="post-date">{{ post.date | date_to_long_string }} -
|
||||
<a href="{{ post.url }}" class="bold">{{ post.title }}</a>
|
||||
</p>
|
||||
<p class="post-draft">
|
||||
{{ post.content | strip_html | truncatewords: 50 }}
|
||||
</p>
|
||||
</div>
|
||||
{% endfor %}
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
lang: en
|
||||
---
|
||||
{% include carousel.html height="50" unit="%" duration="7" collection=site.data.index.images %}
|
||||
|
||||
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Links
|
||||
displaymenu: true
|
||||
lang: en
|
||||
---
|
||||
|
||||
Master Degrees
|
||||
--------------
|
||||
* [PPGCC - Programa de Pós-Graduação em Ciência da Computação](https://ppgcc.ufsj.edu.br)
|
||||
* [PIPAUS - Programa Interdepartamental de Pós-graduação Interdisciplinar em Artes, Urbanidades e Sustentabilidade](https://www.ufsj.edu.br/pipaus)
|
||||
|
||||
|
||||
Events
|
||||
--------
|
||||
* [SBCM - Simpósio Brasileiro de Computação Musical](https://compmus.org.br)
|
||||
* [NIME - New Interfaces for Musical Expression](https://nime.org)
|
||||
* [SMC - Sound and Music Computing Network](https://smcnetwork.org/)
|
||||
* [ISMC - International Computer Music Association](http://www.computermusic.org/)
|
||||
* [ISMIR - International Society for Music Information Retrieval](https://www.ismir.net/)
|
||||
* [DAFx - Digital Audio Effects](https://www.dafx.de/)
|
||||
* [LAC - Linux Audio Conference](http://linuxaudio.org/lac.html)
|
||||
* [Conferência Internacional de Pesquisa em Sonoridades](https://www.sonoridades.net/)
|
||||
* [CONGRESSO INTERNACIONAL DE ARTE, CIÊNCIA E TECNOLOGIA](https://seminarioartesdigitais.weebly.com/)
|
||||
* [Audio Mostly](https://audiomostly.com/)
|
||||
|
||||
|
||||
Partners
|
||||
--------
|
||||
* [CEGeME - Centro de Estudos do Gesto Musical e Expressão](https://musica.ufmg.br/cegeme/)
|
||||
* [Compmus - Grupo de Computação Musical - IME/USP ](https://compmus.ime.usp.br/)
|
||||
* [GTrans - Grupo Transdisciplinar de Pesquisa em Artes e Sustentabilidade](gtrans.ufsj.edu.br/)
|
||||
* [IDMIL - Input Devices and Music Interaction Laboratory](http://www-new.idmil.org/)
|
||||
* [NuSom - Núcleo de Pesquisas em Sonologia da USP](http://www2.eca.usp.br/nusom/)
|
||||
|
|
@ -1,92 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: People
|
||||
displaymenu: true
|
||||
lang: en
|
||||
---
|
||||
|
||||
<H1>Coordinator</H1>
|
||||
|
||||
<div>
|
||||
{% assign people_group = site.people | where:"grouped_by", "coordinator" %}
|
||||
{% for people_item in people_group %}
|
||||
{% include people.html %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
|
||||
<br style='clear: both;' />
|
||||
|
||||
<hr />
|
||||
|
||||
<H1>Master Students</H1>
|
||||
|
||||
<div>
|
||||
{% assign people_group = site.people | where:"grouped_by", "master_students" %}
|
||||
{% for people_item in people_group %}
|
||||
{% include people.html %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
|
||||
<br style='clear: both;' />
|
||||
|
||||
<H1>Undergraduate Students</H1>
|
||||
|
||||
<div>
|
||||
{% assign people_group = site.people | where:"grouped_by", "undergraduate_students" %}
|
||||
{% for people_item in people_group %}
|
||||
{% include people.html %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
|
||||
<br style='clear: both;' />
|
||||
|
||||
<H1>High School Students</H1>
|
||||
|
||||
<div>
|
||||
{% assign people_group = site.people | where:"grouped_by", "high_school_students" %}
|
||||
{% for people_item in people_group %}
|
||||
{% include people.html %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
|
||||
<br style='clear: both;' />
|
||||
|
||||
<hr />
|
||||
|
||||
<H1>Alumni</H1>
|
||||
|
||||
<br style='clear: both;' />
|
||||
|
||||
<H2>Master Students</H2>
|
||||
|
||||
<div>
|
||||
{% assign people_group = site.people | where:"grouped_by", "alumni_master_students" %}
|
||||
{% for people_item in people_group %}
|
||||
{% include people.html %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
|
||||
<br style='clear: both;' />
|
||||
|
||||
<H2>Undergraduate Students</H2>
|
||||
|
||||
<div>
|
||||
{% assign people_group = site.people | where:"grouped_by", "alumni_undergraduate_students" %}
|
||||
{% for people_item in people_group %}
|
||||
{% include people.html %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
|
||||
<!-- div class='people'>
|
||||
<img src="/assets/people/rabbit.png"/>
|
||||
<h1>Roney Rodrigo Ribeiro dos Santos</h1>
|
||||
<!-- a href='?'>Github</a>
|
||||
<a href='?'>Lattes</a>
|
||||
</div>
|
||||
|
||||
<div class='people'>
|
||||
<img src="/assets/people/rabbit.png"/>
|
||||
<h1>Valdir de Siqueira Santos Junior</h1>
|
||||
<!-- a href='?'>Github</a>
|
||||
<a href='?'>Lattes</a>
|
||||
</div -->
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Projects
|
||||
displaymenu: true
|
||||
lang: en
|
||||
---
|
||||
|
||||
{% assign lang_projects = site.projects | where:"lang", "en" %}
|
||||
{% for item in lang_projects %}
|
||||
<div class='art'>
|
||||
<a href='{{ item.permalink }}'>
|
||||
<h1>{{ item.name }}</h1>
|
||||
{% if item.pic %}
|
||||
<img src="{{ item.pic }}"/>
|
||||
{% else %}
|
||||
<img src="/assets/logos/rabbit2.png"/>
|
||||
{% endif %}
|
||||
</a>
|
||||
</div>
|
||||
{% endfor %}
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
Black Lives Matter
|
||||
------------------
|
||||
|
||||
|
||||
The Brazilian police killed 16 people per day in 2017 and 3/4 of the victims were black people. Recently, a Brazilian called Evaldo Rosa dos Santos, father, worker, musician, and black, was killed in Rio de Janeiro with 80 rifle bullets shot by the police. Everyday, the statistics and the news show that the police uses more force when dealing with black people and it seems obvious that, in Brazil, the state bullet uses to find a black skin to rest.
|
||||
|
||||
Unfortunately, the brutal force and violence by the state and the police to black people is not a problem only in this country. It is a global reality that led to the creation of an international movement called Black Lives Matter (BLM), a movement against all types of racism towards the black people specially by the police and the state. The BLM movement also aims to connect black people of the entire world against the violence and for justice.
|
||||
|
||||
In our work, we try to establish a link between the reality of black people in Brazil with the culture of black people around the world, connecting people and artists to perform a tribute to the black lives harved by the state force. For this, the piece uses web content, news, pictures, YouTube’s videos, and more, to create a collage of visual and musical environment merged with expressive movements of a dance, combining technology and gestures. Black culture beyond violence because we believe that black lives matter.
|
||||
|
||||
|
||||
{% include carousel.html height="50" unit="%" duration="7" collection=site.data.blm-2019-09-26.images %}
|
||||
|
||||
Participants
|
||||
============
|
||||
* Avner Maximiliano de Paulo
|
||||
* Carlos Eduardo Oliveira de Souza
|
||||
* Bruna Guimaraes Lima e Silva
|
||||
* Maria Esther
|
||||
|
||||
|
||||
## Presentations
|
||||
* (2019 / 09 / 26) Brazilian Symposium on Computer Music (SBCM). São João del-Rei.
|
||||
|
||||
|
||||
|
||||
Publications about it
|
||||
=====================
|
||||
|
||||
{% bibliography -q @*[title ^= *Black Lives Matter*] %}
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
5° Seminário de Arte Digital
|
||||
----------------------------
|
||||
|
||||
Entre os dias 23 e 26 de abril de 2019, em equipamentos do Circuito Liberdade (Belo Horizonte/MG - http://www.circuitoliberdade.mg.gov.br/pt-br/), acontece o Seminário de Artes Digitais de 2019. O congresso de arte, ciência e tecnologia alcança a sua 5ª edição e tem como tema geral "Projeções e Memória da Arte" consolidando-se como um evento internacional com membros em seu comitê científico composto por doutores de instituições do Brasil e do exterior. A participação de eminentes pesquisadores do exterior já vem ocorrendo desde a edição de 2017, sendo que o evento ocorre desde 2015 de modo ininterrupto mobilizando imensa rede nacional e internacional de grupos, instituições, pesquisadores e artistas.
|
||||
O 5º Seminário de Artes Digitais é organizado pelo Laboratório de Poéticas Fronteiriças (http://labfront.tk - UEMG/CNPq) a partir de comitê composto por membros de várias instituições (UEMG, CEFET-MG, UFSM, FAD/ICAT). A edição de 2019 é estendida e conta com o apoio de agências de fomento nacionais e diversos outros parceiros tais como grupos de pesquisa consolidados no país e no exterior.
|
||||
O tema desta edição foi um consenso produzido a partir das discussões presentes sobre a memória da arte em todas as edições anteriores do congresso. Além disso, projetamos as discussões sobre a memória da arte e de outras ações do campo desde o dia de hoje para o futuro, o que permite que comunicações de pesquisas (e de produção de obras de arte) de várias temáticas possam ser apresentadas no evento sendo apresentadas para toda a comunidade científica.
|
||||
As sessões plenárias e as conferências de nosso congresso trazem temas de áreas de interesse comum aos pesquisadores, professores e público, participantes do evento (tais como Artes, Ciência da Computação, Engenharias, Ciências da Vida dentre outras).
|
||||
|
||||
|
||||
{% include carousel.html height="50" unit="%" duration="7" collection=site.data.chaos-bh.images %}
|
||||
|
||||
[Back to Chaos](/chaos.html)
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
III Mostra Vestígios
|
||||
--------------------
|
||||
|
||||
A III Mostra Vestígios, do Programa Interdepartamental de Pós-graduação Interdisciplinar em Artes, Urbanidades e Sustentabilidade (PIPAUS), da Universidade Federal de São João del-Rei, é uma exposição coletiva que consiste na exibição de fragmentos dos trabalhos desenvolvidos na disciplina Arte Ciência com base no conteúdo estudado durante o período, a partir das teorias e dos autores propostos e da prática idealizada por cada grupo. O resultado é um trabalho teórico-prático e abordando a transdisciplinaridade de forma aplicada.
|
||||
|
||||
|
||||
{% include carousel.html height="50" unit="%" duration="7" collection=site.data.chaos-mostraVestigios.images %}
|
||||
|
||||
[Back to Chaos](/chaos.html)
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
Quinta Cultural
|
||||
---------------
|
||||
|
||||
|
||||
{% include carousel.html height="50" unit="%" duration="7" collection=site.data.chaos-2019-05-23.images %}
|
||||
|
||||
[Back to Chaos](/chaos.html)
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
17th Bazilian Symposium on Computer Music (SBCM)
|
||||
------------------------------------------------
|
||||
|
||||
The Brazilian Symposia on Computer Music are thriving and exciting venues for sharing ideas about recent developments in the fields of computer music, sound and music processing, music information retrieval, computational musicology, multimedia performance and many other things related to art, science and technology.
|
||||
We would like to invite you to contribute to and participate in this event, which will take place at the beautiful campus of the Federal University of São João del-Rei, Brazil, from September 25th to September 27th 2019. During the event, participants will have the opportunity to attend to keynote talks, oral presentations of music and technical papers, poster discussion sessions, workshops, discussion panels and concerts, and will have plenty of opportunities to interact and discuss collaborations with other participants.
|
||||
|
||||
|
||||
{% include carousel.html height="50" unit="%" duration="7" collection=site.data.chaos-sbcm.images %}
|
||||
|
||||
[Back to Chaos](/chaos.html)
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
Sons de Silício
|
||||
---------------
|
||||
|
||||
O Espaço das Artes da Escola de Comunicação e Artes (ECA) da USP recebe a ocupação Sons de Silício do dia 1 até 26 de abril. A exposição traz cerca de 20 instalações que exploram os limites do que tradicionalmente é reconhecido como som, estimulando efeitos inusitados através do uso da tecnologia. Ela é coordenada pelo Grupo de Práticas Interativas (GPI) do Núcleo de Pesquisas em Sonologia, sediado no Departamento de Música da ECA.
|
||||
Durante a ocupação, serão realizadas performances e oficinas, também no Espaço das Artes. As performances, com diferentes grupos e artistas, ocorrem nos dias 1º, 4, 8 e 22 de abril, sempre às 18 horas. Já as oficinas acontecem nos dias 8, 12, 23 e 26 de abril, às 10 horas. Sons de Silício faz parte da 15ª edição da série ¿Música?, promovida desde 2005 pelo Núcleo de Pesquisas em Sonologia.
|
||||
|
||||
|
||||
{% include carousel.html height="50" unit="%" duration="7" collection=site.data.chaos-sp.images %}
|
||||
|
||||
[Back to Chaos](/chaos.html)
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
O Chaos das 5
|
||||
-------------
|
||||
|
||||
"O Chaos das 5" is an audiovisual digital performance. The guideline of the performance is inspired by Alice, from Lewis Carroll book - Alice in the Wonderland, as a metaphor to take the audience to a synthetic and disruptive wonder world. The concept of the performance is to conceive the possibility to the audience to interact through digital interfaces creating an immersive and participatory experience by combining three important layers of information (music, projections and gestures) through their cellphones. Once that the audience members take part of the show on an immersive aspect,
|
||||
there is no stage or another mark to limit the space of the performers and the audience.
|
||||
|
||||
The Musical Layer is composed by the digital devices to be accessed by the public on their cellphones and with 5 musicians improvising with their unconventional digital musicians. The Visual Layer projections made in real time presents an aesthetic that puts the computer in scene, opening the "Black Box" and exposing the machine in its realistic imaging.
|
||||
|
||||
Public interaction is given by the capture of images and data to be used in the projections. The Gesture Layer counts with a performance that mixes a set of gestures, improvisations and physically interactions with the audience in the space of the show. The plot is organized in a first welcome, three scenes and a final credit show.
|
||||
|
||||
|
||||
{% include carousel.html height="50" unit="%" duration="7" collection=site.data.chaos-2019-05-23.images %}
|
||||
|
||||
|
||||
## Check the pics of some presentations
|
||||
* III Festeco - Mariana (20/09/2019)
|
||||
* [Sons de Silício - São Paulo (08/04/2019)](/chaos-sp.html)
|
||||
* [V Seminário de Arte Digital - Belo Horizonte (26/04/2019)](/chaos-bh.html)
|
||||
* [Quinta Cultural - São João del-Rei](chaos-quinta.html)
|
||||
* [Bazilian Symposium on Computer Music (SBCM) - São João del-Rei (25/09/2019)](/chaos-sbcm.html)
|
||||
* XIX Festival de Artes Cênicas de Conselheiro Lafaiete (FACE) - Conselheiro Lafaiete (19/07/2019)
|
||||
* [III Mostra Vestígios - São João del-Rei (23/11/2018)](chaos-mostraVestigios.html)
|
||||
|
||||
[Check it out!](webart/chaosdas5/)
|
||||
|
||||
Publications about it
|
||||
=====================
|
||||
|
||||
{% bibliography -q @*[title ^= *Chaos*] %}
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
<!-- Descrição e informações sobre o projeto. Assim como participantes e artigos ligados ao projeto. -->
|
||||
<!-- Além de conter link para acessar o site do projeto. -->
|
||||
|
||||
# GlueTube
|
||||
|
||||
GlueTube was created as a tool that aims to provide an environment for both musical and visual creation, based on collage techniques and the use of videos available on YouTube in addition to other online content.
|
||||
|
||||
**Participants**
|
||||
|
||||
* Avner Maximiliano de Paulo
|
||||
* Carlos Eduardo Oliveira de Souza
|
||||
|
||||
**Publications about the GlueTube**
|
||||
|
||||
{% bibliography -q @*[title ^= *GlueTube*] %}
|
||||
|
||||
**GlueTube project website**
|
||||
|
||||
[Click here](https://alice.dcomp.ufsj.edu.br/webart/gluetube){:target="_blank"} to access the project website.
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
|
@ -1,23 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
Per(sino)ficação
|
||||
================
|
||||
|
||||
The bell’s culture is a secular tradition strongly linked to the religious and social activities of the old Brazilian’s villages. In São João del-Rei, where the singular bell tradition composes the soundscape of the city, the bell’s ringing created from different rhythmic and timbral patterns, establish a language capable of transmitting varied types of messages to the local population. In this way, the social function of these ringing, added to real or legendary facts related to the bell’s culture, were able to produce affections and to constitute a strong relation with the identity of the community. The link of this community with the bells, therefore transcends the man-object relationship, tending to an interpersonal relationship practically.
|
||||
|
||||
Thus, to emphasize this connection in an artistic way, it is proposed the installation called: PER(SINO)FICAÇÃO. This consists of an environment where users would have their physical attributes collected through the use of computer vision. From the interlocking of these data with timbral attributes of the bells, visitors would be able to sound like these, through mapped bodily attributes capable of performing syntheses based on original samples of the bells. Thus the inverse sense of the personification of the bell is realized, producing the human “bellification”.
|
||||
|
||||
{% include carousel.html height="50" unit="%" duration="7" collection=site.data.pesinoficacao-SBCM2019.images %}
|
||||
|
||||
Participants
|
||||
============
|
||||
* Fábio dos Passos Carvalho
|
||||
* João Teixeira Araújo
|
||||
|
||||
Publications about it
|
||||
=====================
|
||||
|
||||
{% bibliography -q @*[title ^= *Per\(sino*] %}
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
[Check it out!](/webart/tear.html/).
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
Telefone sem Fio
|
||||
------------------
|
||||
|
||||
Under Construction
|
||||
|
||||
Participants
|
||||
============
|
||||
* Carlos Eduardo Oliveira de Souza
|
||||
* Jônatas
|
||||
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Publications
|
||||
displaymenu: true
|
||||
lang: en
|
||||
---
|
||||
|
||||
<div>
|
||||
<h3 style="margin-bottom:0px">Search</h3>
|
||||
<input style="width:400px" type="text" id="inputSearch" onkeyup="searchArticle();" placeholder="Type it what you looking for">
|
||||
</div>
|
||||
<br>
|
||||
|
||||
{% bibliography -q @*[year >= {{2015}}]* %}
|
||||
|
||||
|
||||
## Pré ALICE
|
||||
|
||||
{% bibliography -q @*[year <= {{2014}}]* %}
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Software Projects
|
||||
lang: en
|
||||
---
|
||||
|
||||
{% assign projects = site.projects | where:"project_type", "software" %}
|
||||
<div>
|
||||
{% for item in projects %}
|
||||
{% include project.html %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
|
||||
<!-- * [Mosaicode](/projects/mosaicode.html)
|
||||
* [Hadouken](/projects/hadouken.html)
|
||||
* [GlueTube](/projects/gluetube.html)
|
||||
* [Per(sino)ficação](/projects/personificacao.html)
|
||||
* [Simetria](/projects/simetria.html)
|
||||
* [Texturas](/projects/texturas.html) -->
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
---
|
||||
layout: post
|
||||
author: Flávio Schiavoni
|
||||
title: Um arquivo, vários donos
|
||||
lang: pt
|
||||
lang-ref: One-file-several-owners
|
||||
---
|
||||
|
||||
É possível que um mesmo arquivo no Linux possua mais de um usuário autorizado a alterá-lo. Ao contrário do chmod que só permite um proprietário em um arquivo, o comando setfacl permite adicionar permissões para vários usuários em um mesmo arquivo. Para isto, usamos o comando:
|
||||
|
||||
<pre>
|
||||
setfacl -R -m user:LOGIN:rwx /PASTA/ARQUIVO
|
||||
</pre>
|
||||
|
||||
Para verificar quais usuários possuem permissões em um arquivo:
|
||||
|
||||
<pre>
|
||||
getfacl ARQUIVO
|
||||
</pre>
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
---
|
||||
layout: post
|
||||
author: Flávio Schiavoni
|
||||
title: Transformando diretórios em repositórios versionados
|
||||
lang: pt
|
||||
lang-ref: Transforming-directories-into-versioned-repositories
|
||||
---
|
||||
|
||||
Um repositório de código, de uma forma bem ampla, é um diretório que contém arquivos que possuem controle de versão. Isto inclui a possibilidade de auditar as modificações dos arquivos, verificar possíveis mudanças de uma versão para outra e até mesmo voltar o arquivo para uma versão anterior.
|
||||
|
||||
Apesar de estarmos acostumados a utilizar repositórios remotos, como o github ou outro serviço similar, é possível com o git manter qualquer diretório local como um repositório versionado. Isto permite auditar modificações e garante uma certa segurança pois permitiria verificar todas as versões anteriores de um arquivo.
|
||||
|
||||
Para transformar um diretório em um repositório git, utilize o comando:
|
||||
|
||||
<pre>
|
||||
git init --bare --shared
|
||||
</pre>
|
||||
|
||||
* o --bare inicializar o repositório git para ser um repositório remoto
|
||||
* o --shared configura as permissões de escrita para grupo
|
||||
|
||||
Uma vez iniciado o repositório, é necessário adicionar todos os arquivos ao mesmo:
|
||||
|
||||
<pre>
|
||||
git add *
|
||||
</pre>
|
||||
|
||||
Depois, é necessário se identificar:
|
||||
|
||||
<pre>
|
||||
git config --global user.email "alice@alice.dcomp.ufsj.edu.br"
|
||||
git config --global user.name "Alice"
|
||||
</pre>
|
||||
|
||||
E por fim, fazer a submissão das alterações com o comando:
|
||||
|
||||
<pre> git commit -m "Versão inicial do projeto"</pre>
|
||||
|
||||
Com isto, a cada modificação que se deseja guardar, basta adicionar os arquivos alterados e fazer o commit.
|
||||
|
||||
Mais informações: [https://git-scm.com/book/en/v2/Git-on-the-Server-Getting-Git-on-a-Server]
|
||||
|
|
@ -1,64 +0,0 @@
|
|||
---
|
||||
layout: post
|
||||
author: Flávio Schiavoni
|
||||
title: Alterando o nosso site
|
||||
lang: pt
|
||||
lang-ref: Changing-our-website
|
||||
---
|
||||
|
||||
# Código-fonte e página
|
||||
|
||||
Nosso site utilizar o Jekyll como gerador dinâmico para um site estático.
|
||||
O site está no diretório /var/www/html enquanto o código-fonte está na pasta /var/www/src.
|
||||
Não altere o site diretamente na pasta html, toda alteração deve ser feita na pasta src ou a mesma poderá ser apagada na próxima atualização.
|
||||
Após alterar um arquivo, faça a geração do site com o comando:
|
||||
|
||||
<pre>
|
||||
./update.sh
|
||||
</pre>
|
||||
|
||||
Jamais utilize o comando sudo para atualizar o site.
|
||||
Caso seu usuário não possua permissão para alterar o site, altere as permissões dos arquivos.
|
||||
Consulte [este post](https://alice.dcomp.ufsj.edu.br/2020/01/21/Um-arquivo-varios-donos.html) para isto.
|
||||
|
||||
|
||||
# Blog
|
||||
|
||||
Os arquivos deste blog estão na pasta \_posts. Veja os arquivos já existentes e siga o template. Note que o padrão de nomes destes arquivos importa e será utilizado para criar o índice no site. O padrão do nome é ano-mês-dia-título.md. Exemplo:
|
||||
|
||||
<pre>
|
||||
2020-03-26-Alterando-o-nosso-site.md
|
||||
</pre>
|
||||
|
||||
Nosso gerador está configurado para trabalhar de maneira incremental, por isto, ao mandar atualizar o site com o comando update apenas os arquivos alterados na última modificação serão atualizados.
|
||||
Caso a página inicial do blog não seja alterada após o comando update, atualize a data de modificação do arquivo blog.html com o comando touch e então utilize o comando update. Esta dica vale para qualquer arquivo que precisa ser gerado novamente e não foi alterado.
|
||||
|
||||
<pre>
|
||||
touch blog.html
|
||||
./update.sh
|
||||
</pre>
|
||||
|
||||
|
||||
# Imagens
|
||||
|
||||
Imagens e demais recursos do site estão na pasta assets.
|
||||
As fotos dos eventos e outras fotos estão na pasta pics.
|
||||
Estas fotos são listadas por arquivos ymls disponíveis na pasta \_data.
|
||||
Para adicionar novo slide show de fotos, adicione as imagens em um diretório na pasta pics e crie uma lista destas fotos na pasta \_data.
|
||||
Depois, é só ligar estas fotos no include do carrousel como uma collection.
|
||||
|
||||
<pre>
|
||||
include carousel.html height="50" unit="%" duration="7" collection=site.data.[nome do arquivo].images
|
||||
</pre>
|
||||
|
||||
# Auditando modificações
|
||||
|
||||
A pasta src é um repositório git, apesar deste não ter cópias remotas.
|
||||
Após alterar o conteúdo do site favor adicionar as alterações e dar commit.
|
||||
Utilize os comandos git para isto.
|
||||
|
||||
<pre>
|
||||
git status
|
||||
git add [arquivos modificados]
|
||||
git commit -m "mensagem do commit"
|
||||
</pre>
|
||||
|
|
@ -1,230 +0,0 @@
|
|||
---
|
||||
layout: post
|
||||
author: Luan Luiz Gonçalves
|
||||
title: Fluxo de desenvolvimento com o modelo GitFlow
|
||||
lang: pt
|
||||
lang-ref: Development-flow-with-the-GitFlow-model
|
||||
---
|
||||
|
||||
# GitFlow
|
||||
|
||||
O GitFlow é um modelo de ramificação para desenvolvimento de software, utilizando a ferramenta de controle de versão *git*. Esse modelo, criado pelo engenheiro de software *Vincent Driessen*, tornou-se popular. Segundo *Driessen*, adequado para softwares com versionamento explicito ou para manter múltiplas versões softwares, garantindo uma estabilidade do ramo principal durante o processo de desenvolvimento.
|
||||
|
||||
{% include image.html url="/assets/posts_imgs/gitflow.png" description="Figura 1: Fluxo de desenvolvimento do modelo de ramificação GitFlow." width="80%" height="80%" align_class="aligncenter" %}
|
||||
|
||||
<br>
|
||||
|
||||
O modelo possui uma organização de branches e fluxo de trabalho que torna fácil a localização pontos de alterações do código, visualizando facilmente cada implementação.
|
||||
|
||||
# Repositórios remotos
|
||||
|
||||
O repositório do projeto é centralizado. Cada desenvolvedor contém um *fork* do repositório central para fazer o *push* das alterações/commits em vez de manipular diretamente o repositório central. Dessa forma, para que as alterações sejam adicionadas no repositório central, o desenvolvedor deve criar um *Pull Request*, permitindo que os administradores do projeto revisem as alterações antes de aceitá-las. Também pode ser feito o *pull* entre os forks, criando sub-times para trabalharem em uma mesma implementação -- sub-times de dois ou mais membros. A imagem a segui apresenta essa configuração de repositórios remotos:
|
||||
|
||||
{% include image.html url="/assets/posts_imgs/centr-decentr.png" description="Figura 2: Configuração de repositórios: Centralizado mas descentralizado." width="60%" height="60%" align_class="aligncenter" %}
|
||||
|
||||
<br>
|
||||
|
||||
Na imagem anterior, origin refere-se ao repositório central e os demais repositório são os forks do central -- Alice, Bob, David e Chair. A imagem ilustra os sub-times Alice/Bob, Alice/David e Clair/David. Vale ressaltar que não é feito Pull Request para o repositório central das alterações de trabalhos em progresso, o desenvolvedor ou um sub-time deve finalizar o trabalho no seu respectivo fork antes de fazer o Pull Request.
|
||||
|
||||
|
||||
|
||||
# Branches
|
||||
|
||||
No modelo GitFlow, o repositório central do projeto contém dois branches: o *master* e o *develop*, ambos com vida infinita. O master é o branch principal e o seu código-fonte (HEAD) é sempre uma versão estável -- production release. O branch develop contém sempre implementações completas de features para a próxima release.
|
||||
|
||||
Os desenvolvedores não trabalham diretamente nos branches master e develop. Branches de apoio são criados para a implementação de correções de bugs, implementação de features, alterações de metadados da release e outros processos de release. Diferente do master e develop, os branches de apoio tem finita e possuem implementações em progresso.
|
||||
|
||||
Tipos de branches de apoio:
|
||||
|
||||
* *Feature*: para implementação de novas features;
|
||||
* *Release*: para processos de release como alterações de metadados e empacotamento do software;
|
||||
* *Hotfix*: para correções de bugs que não podem esperar a próxima release.
|
||||
|
||||
|
||||
Cada um dos tipos, além de terem um objetivo específico, estão sujeitos a regras estritas sobre quais ramificações podem ser sua ramificação de origem e quais ramificações devem ser seus destinos de mesclagem, sendo categorizados pela forma de uso. A seguir, veremos os detalhes de cada um dos tipos de branches de apoio, em paralelo com exemplos ilustrando o fluxo de trabalho do modelo GitFlow e os comandos utilizados em cada etapa!
|
||||
|
||||
|
||||
# Branches feature
|
||||
|
||||
{% include image.html url="/assets/posts_imgs/feature-branchs.png" width="18%" height="18%" align_class="alignright" description= "Figura 3: Branch feature." %}
|
||||
|
||||
Regras:
|
||||
|
||||
* Ramificação a partir do branch develop;
|
||||
* Após finalizar a implementação, são mesclados para o branch develop;
|
||||
* Não tem convensão de nome, o nome apenas remete a feature em desenvolvimento;
|
||||
* Existem apenas nos forks do repositório central.
|
||||
|
||||
**Criando um branch feature**
|
||||
|
||||
Para implementação de uma nova feature, é criado um branch de apoio do tipo feature a partir do branch develop. Exemplo:
|
||||
|
||||
<pre>
|
||||
$ git checkout -b myfeature develop
|
||||
Switched to a new branch "myfeature"
|
||||
</pre>
|
||||
|
||||
O comando `git checkout` com o parametro `-b <nome do branch>`, cria o branch e muda para o branch criado. O paramentro develop, no final do comando, informa que o branch será criado a partir do branch develop.
|
||||
|
||||
**Mesclando (Merge) o branch feature no branch develop**
|
||||
|
||||
Após finalizar a implementação da feature no branch *myfeature*, o branch é mescado no branch develop. Feito o merge, deletamos o branch *myfeature* e subimos as alterações (push) para o repositório remoto do desenvolvedor. Para isso, usamos os seguintes comandos:
|
||||
|
||||
<pre>
|
||||
$ git checkout develop
|
||||
Switched to branch 'develop'
|
||||
$ git merge --no-ff myfeature
|
||||
Updating ea1b82a..05e9557
|
||||
(Summary of changes)
|
||||
$ git branch -d myfeature
|
||||
Deleted branch myfeature (was 05e9557).
|
||||
$ git push origin develop
|
||||
</pre>
|
||||
|
||||
Neste e nos exemplo a seguir, o parâmetro *origin* é o link do repositório remoto do desenvolvedor.
|
||||
|
||||
A flag `--no-ff` faz com que o merge sempre crie um commit para registrar a existência histórica de um branch, agrupando os commits do branch. Compare, na Figura 4, o comando merge com e sem a flag:
|
||||
|
||||
{% include image.html url="/assets/posts_imgs/merge-flags.png" width="65%" height="65%" align_class="aligncenter" description="Figura 4: Diferença entre o merge com e sem a flag –no-ff." %}
|
||||
|
||||
<br>
|
||||
|
||||
Se não usarmos a flag, teríamos que ler as mensagens de log dos commits para identificar quais são os commits que juntos consolidam uma implementação. Com a flag, essa identificação torna-se bem mais fácil. A Figura 4 destaca os commits que consolidam a implementação de uma feature, nas duas situações.
|
||||
|
||||
# Branches release
|
||||
|
||||
Regras:
|
||||
|
||||
* Ramificação a partir do branch develop;
|
||||
* Após finalizar a implementação, são mesclados para os branches develop e master;
|
||||
* Convenção de nome: `release-<número de versão>`.
|
||||
|
||||
|
||||
No branch release, finalizamos a release do software. É feito a alteração dos metadados, atualizando o número de versão do software e realizando outros procedimentos de release como o empacotamento do software. Além disso, é permitido pequenas correções de bugs. O branch é criando quando as implementação no branch develop está em um estado bem próximo da nova release do software.
|
||||
|
||||
Terminando o processo de release, o branch release é mesclado para o branch develop e o para o branch master. Nesse momento o branch develop fica livre para a implementações de novas features de uma futura release.
|
||||
|
||||
|
||||
**Criando o branch release**
|
||||
|
||||
Neste exemplo, o número 1.2 é a versão do release. Observe que o nome do branch segue a convenção `release-<número de versão>`:
|
||||
|
||||
<pre>
|
||||
$ git checkout -b release-1.2 develop
|
||||
Switched to a new branch "release-1.2"
|
||||
$ ./bump-version.sh 1.2
|
||||
Files modified successfully, version bumped to 1.2.
|
||||
$ git commit -a -m "Bumped version number to 1.2"
|
||||
[release-1.2 74d9424] Bumped version number to 1.2
|
||||
1 files changed, 1 insertions(+), 1 deletions(-)
|
||||
</pre>
|
||||
|
||||
Depois de criar o branch e mudar para ele, realizamos os procedimentos de release. O arquivo *bump-version.sh* é um script fictício que altera os arquivos de metadados para refletir a nova versão. Após executar o script, fazemos o commit para registrar as alterações.
|
||||
|
||||
|
||||
**Finalizando o branch release**
|
||||
|
||||
Quando o estado do ramo de release está pronto para se tornar um release real, algumas ações precisam ser executadas. Primeiro, o ramo de release é mesclado no master (já que todo commit no master é um novo release por definição, lembre-se). Em seguida, atribuímos uma *tag* nesse commit no master, termos uma referência a esta versão histórica. Finalmente, as alterações feitas na ramificação da versão precisam ser mescladas novamente ao branch develop, para que versões futuras também contenham essas alterações.
|
||||
|
||||
As duas primeiras etapas no Git:
|
||||
|
||||
<pre>
|
||||
$ git checkout master
|
||||
Switched to branch 'master'
|
||||
$ git merge --no-ff release-1.2
|
||||
Merge made by recursive.
|
||||
(Summary of changes)
|
||||
$ git tag -a 1.2
|
||||
</pre>
|
||||
|
||||
Mesclando o branch release no branch develop:
|
||||
|
||||
<pre>
|
||||
$ git checkout develop
|
||||
Switched to branch 'develop'
|
||||
$ git merge --no-ff release-1.2
|
||||
Merge made by recursive.
|
||||
(Summary of changes)
|
||||
</pre>
|
||||
|
||||
Essa etapa pode levar a um conflito de mesclagem. Se sim, corrija e confirme.
|
||||
|
||||
Agora, o processo de release foi finalizado e o branch de release pode ser removido, pois não precisamos mais dele:
|
||||
|
||||
<pre>
|
||||
$ git branch -d release-1.2
|
||||
Deleted branch release-1.2 (was ff452fe).
|
||||
</pre>
|
||||
|
||||
# Branches hotfix
|
||||
|
||||
{% include image.html url="/assets/posts_imgs/hotfix-branchs.png" width="40%" height="40%" align_class="alignright" description="Figura 5: Branch hotfix." %}
|
||||
|
||||
|
||||
Regras:
|
||||
|
||||
* Ramificação a partir do branch master;
|
||||
* Após finalizar a implementação, são mesclados para o branch master;
|
||||
* Convenção de nome: `hotfix-<número de versão>`.
|
||||
|
||||
|
||||
Os branches hotfix são muito parecidos com os branches de release, pois também entregam uma nova versão do software, embora não planejada. Eles surgem da necessidade de agir imediatamente em um estado indesejado de uma versão de produção lançada -- versão de produção.
|
||||
|
||||
Quando há um erro crítico em uma versão de produção, não podemos esperar a próxima release para corrigir-ló. S sendo assim, um branch hotfix é criado para a correção. A essência é que o trabalho dos membros da equipe (no branch develop) pode continuar enquanto é feito a correção.
|
||||
|
||||
**Criando o branch hotfix**
|
||||
|
||||
Esse branch é criado a partir do master e o seu nome segue a convenção `hotfix-<numero de versão>`. No exemplo a seguir, o bug encontra-se na versão *1.2* (1.2.0) e incrementamos o terceiro número da versão. Essa incrementação segue as regras do [Semantic Versioning 2.0.0](https://semver.org/):
|
||||
|
||||
<pre>
|
||||
$ git checkout -b hotfix-1.2.1 master
|
||||
Switched to a new branch "hotfix-1.2.1"
|
||||
$ ./bump-version.sh 1.2.1
|
||||
Files modified successfully, version bumped to 1.2.1.
|
||||
$ git commit -a -m "Bumped version number to 1.2.1"
|
||||
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
|
||||
1 files changed, 1 insertions(+), 1 deletions(-)
|
||||
</pre>
|
||||
|
||||
Após criar o branch e incrementar o número de versão nos arquivos de metadados, podemos corrigir o bug em um ou mais commits:
|
||||
|
||||
<pre>
|
||||
$ git commit -m "Fixed severe production problem"
|
||||
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
|
||||
5 files changed, 32 insertions(+), 17 deletions(-)
|
||||
</pre>
|
||||
|
||||
**Finalizando o branch hotfix**
|
||||
|
||||
Ao terminar a implementação de correção do bug, o branch hotfix é mesclado aos branches master e develop. Primeiro, atualize o master e marque a versão com a tag:
|
||||
|
||||
<pre>
|
||||
$ git checkout master
|
||||
Switched to branch 'master'
|
||||
$ git merge --no-ff hotfix-1.2.1
|
||||
Merge made by recursive.
|
||||
(Summary of changes)
|
||||
$ git tag -a 1.2.1
|
||||
</pre>
|
||||
|
||||
Em seguida, inclua a correção do bug no develop também:
|
||||
|
||||
<pre>
|
||||
$ git checkout develop
|
||||
Switched to branch 'develop'
|
||||
$ git merge --no-ff hotfix-1.2.1
|
||||
Merge made by recursive.
|
||||
(Summary of changes)
|
||||
</pre>
|
||||
|
||||
Por fim, remova o branch hotfix:
|
||||
|
||||
<pre>
|
||||
$ git branch -d hotfix-1.2.1
|
||||
Deleted branch hotfix-1.2.1 (was abbe5d6).
|
||||
</pre>
|
||||
|
||||
|
||||
# Referências
|
||||
|
||||
1. [https://nvie.com/posts/a-successful-git-branching-model/](https://nvie.com/posts/a-successful-git-branching-model/)
|
||||
66
_pt_/art.md
66
_pt_/art.md
|
|
@ -1,66 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Projetos Artísticos
|
||||
lang: pt
|
||||
---
|
||||
|
||||
{% assign projects = site.projects | where:"project_type", "artistic" %}
|
||||
<div>
|
||||
{% for item in projects %}
|
||||
{% include project.html %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
|
||||
<!-- <div class='art'>
|
||||
<a href='/projects/arts/chaos.html'>
|
||||
<h1>O Chaos das 5</h1>
|
||||
<img src="/pics/chaos/chaos-bh/1.jpg"/>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
<div class='art'>
|
||||
<a href='/projects/arts/blm.html'>
|
||||
<h1>Black Lives Matter</h1>
|
||||
<img src="/pics/blm/TM2_6535.jpg"/>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
<div class='art'>
|
||||
<a href='/projects/arts/persinoficacao.html'>
|
||||
<h1>Per(sino)ficação</h1>
|
||||
<img src="/pics/pesinoficacao/SBCM-2019/TM2_5715.jpg"/>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
<div class='art'>
|
||||
<a href='/projects/arts/rendase.html'>
|
||||
<h1>Renda-se</h1>
|
||||
<img src="/assets/logos/rabbit2.png"/>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
<div class='art'>
|
||||
<a href='/projects/arts/webart/O_olhar_de_quem/'>
|
||||
<h1>O Olhar de quem?</h1>
|
||||
<img src="/assets/logos/rabbit2.png"/>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
<div class='art'>
|
||||
<a href=''>
|
||||
<img src="/assets/logos/rabbit2.png"/>
|
||||
<h1>Texturas interativas</h1>
|
||||
</a>
|
||||
</div> -->
|
||||
|
||||
|
||||
<br style="clear: both;">
|
||||
|
||||
O desenvolvimento da Arte no ALICE é feito pela Orchidea - Orquestra de Ideias.
|
||||
|
||||
Publicações sobre a Orchidea
|
||||
============================
|
||||
|
||||
{% bibliography -q @*[title ^= *Orchidea*] %}
|
||||
|
||||
Confira nossa [Página de Publicações](/{{ page.lang }}/publications.html) para ver mais sobre isso.
|
||||
18
_pt_/blog.md
18
_pt_/blog.md
|
|
@ -1,18 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Blog
|
||||
displaymenu: true
|
||||
lang: pt
|
||||
---
|
||||
|
||||
{% assign lang_posts = site.posts | where:"lang", "pt" %}
|
||||
{% for post in lang_posts %}
|
||||
<div class="post-area">
|
||||
<p class="post-date">{{ post.date | date_to_long_string }} -
|
||||
<a href="{{ post.url }}" class="bold">{{ post.title }}</a>
|
||||
</p>
|
||||
<p class="post-draft">
|
||||
{{ post.content | strip_html | truncatewords: 50 }}
|
||||
</p>
|
||||
</div>
|
||||
{% endfor %}
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
lang: pt
|
||||
---
|
||||
|
||||
{% include carousel.html height="50" unit="%" duration="7" collection=site.data.index.images %}
|
||||
|
||||
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Links
|
||||
displaymenu: true
|
||||
lang: pt
|
||||
---
|
||||
|
||||
Programas de Mestrado na UFSJ
|
||||
--------------
|
||||
* [PPGCC - Programa de Pós-Graduação em Ciência da Computação](https://ppgcc.ufsj.edu.br)
|
||||
* [PIPAUS - Programa Interdepartamental de Pós-graduação Interdisciplinar em Artes, Urbanidades e Sustentabilidade](https://www.ufsj.edu.br/pipaus)
|
||||
|
||||
|
||||
Eventos
|
||||
--------
|
||||
* [SBCM - Simpósio Brasileiro de Computação Musical](https://compmus.org.br)
|
||||
* [NIME - New Interfaces for Musical Expression](https://nime.org)
|
||||
* [SMC - Sound and Music Computing Network](https://smcnetwork.org/)
|
||||
* [ISMC - International Computer Music Association](http://www.computermusic.org/)
|
||||
* [ISMIR - International Society for Music Information Retrieval](https://www.ismir.net/)
|
||||
* [DAFx - Digital Audio Effects](https://www.dafx.de/)
|
||||
* [LAC - Linux Audio Conference](http://linuxaudio.org/lac.html)
|
||||
* [Conferência Internacional de Pesquisa em Sonoridades](https://www.sonoridades.net/)
|
||||
* [CONGRESSO INTERNACIONAL DE ARTE, CIÊNCIA E TECNOLOGIA](https://seminarioartesdigitais.weebly.com/)
|
||||
* [Audio Mostly](https://audiomostly.com/)
|
||||
|
||||
|
||||
Parceiros
|
||||
--------
|
||||
* [CEGeME - Centro de Estudos do Gesto Musical e Expressão](https://musica.ufmg.br/cegeme/)
|
||||
* [Compmus - Grupo de Computação Musical - IME/USP ](https://compmus.ime.usp.br/)
|
||||
* [GTrans - Grupo Transdisciplinar de Pesquisa em Artes e Sustentabilidade](gtrans.ufsj.edu.br/)
|
||||
* [IDMIL - Input Devices and Music Interaction Laboratory](http://www-new.idmil.org/)
|
||||
* [NuSom - Núcleo de Pesquisas em Sonologia da USP](http://www2.eca.usp.br/nusom/)
|
||||
|
|
@ -1,93 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Pessoas
|
||||
displaymenu: true
|
||||
lang: pt
|
||||
---
|
||||
|
||||
<H1>Coordenador</H1>
|
||||
|
||||
<div>
|
||||
{% assign people_group = site.people | where:"grouped_by", "coordinator" %}
|
||||
{% for people_item in people_group %}
|
||||
{% include people.html %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
|
||||
<br style='clear: both;' />
|
||||
|
||||
<hr />
|
||||
|
||||
<H1>Discentes de Mestrado</H1>
|
||||
|
||||
<div>
|
||||
{% assign people_group = site.people | where:"grouped_by", "master_students" %}
|
||||
{% for people_item in people_group %}
|
||||
{% include people.html %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
|
||||
<br style='clear: both;' />
|
||||
|
||||
<H1>Discentes de Graduação</H1>
|
||||
|
||||
<div>
|
||||
{% assign people_group = site.people | where:"grouped_by", "undergraduate_students" %}
|
||||
{% for people_item in people_group %}
|
||||
{% include people.html %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
|
||||
<br style='clear: both;' />
|
||||
|
||||
<H1>Discentes de Ensino Médio</H1>
|
||||
|
||||
<div>
|
||||
{% assign people_group = site.people | where:"grouped_by", "high_school_students" %}
|
||||
{% for people_item in people_group %}
|
||||
{% include people.html %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
|
||||
<br style='clear: both;' />
|
||||
|
||||
|
||||
<hr />
|
||||
|
||||
<H1>Ex-alunos</H1>
|
||||
|
||||
<br style='clear: both;' />
|
||||
|
||||
<H2>Discentes de Mestrado</H2>
|
||||
|
||||
<div>
|
||||
{% assign people_group = site.people | where:"grouped_by", "alumni_master_students" %}
|
||||
{% for people_item in people_group %}
|
||||
{% include people.html %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
|
||||
<br style='clear: both;' />
|
||||
|
||||
<H2>Discentes de Graduação</H2>
|
||||
|
||||
<div>
|
||||
{% assign people_group = site.people | where:"grouped_by", "alumni_undergraduate_students" %}
|
||||
{% for people_item in people_group %}
|
||||
{% include people.html %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
|
||||
<!-- div class='people'>
|
||||
<img src="/assets/people/rabbit.png"/>
|
||||
<h1>Roney Rodrigo Ribeiro dos Santos</h1>
|
||||
<!-- a href='?'>Github</a>
|
||||
<a href='?'>Lattes</a>
|
||||
</div>
|
||||
|
||||
<div class='people'>
|
||||
<img src="/assets/people/rabbit.png"/>
|
||||
<h1>Valdir de Siqueira Santos Junior</h1>
|
||||
<!-- a href='?'>Github</a>
|
||||
<a href='?'>Lattes</a>
|
||||
</div -->
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Projetos
|
||||
displaymenu: true
|
||||
lang: pt
|
||||
---
|
||||
|
||||
{% assign lang_projects = site.projects | where:"lang", "pt" %}
|
||||
{% for item in lang_projects %}
|
||||
<div class='art'>
|
||||
<a href='{{ item.permalink }}'>
|
||||
<h1>{{ item.name }}</h1>
|
||||
{% if item.pic %}
|
||||
<img src="{{ item.pic }}"/>
|
||||
{% else %}
|
||||
<img src="/assets/logos/rabbit2.png"/>
|
||||
{% endif %}
|
||||
</a>
|
||||
</div>
|
||||
{% endfor %}
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
Black Lives Matter
|
||||
------------------
|
||||
|
||||
|
||||
The Brazilian police killed 16 people per day in 2017 and 3/4 of the victims were black people. Recently, a Brazilian called Evaldo Rosa dos Santos, father, worker, musician, and black, was killed in Rio de Janeiro with 80 rifle bullets shot by the police. Everyday, the statistics and the news show that the police uses more force when dealing with black people and it seems obvious that, in Brazil, the state bullet uses to find a black skin to rest.
|
||||
|
||||
Unfortunately, the brutal force and violence by the state and the police to black people is not a problem only in this country. It is a global reality that led to the creation of an international movement called Black Lives Matter (BLM), a movement against all types of racism towards the black people specially by the police and the state. The BLM movement also aims to connect black people of the entire world against the violence and for justice.
|
||||
|
||||
In our work, we try to establish a link between the reality of black people in Brazil with the culture of black people around the world, connecting people and artists to perform a tribute to the black lives harved by the state force. For this, the piece uses web content, news, pictures, YouTube’s videos, and more, to create a collage of visual and musical environment merged with expressive movements of a dance, combining technology and gestures. Black culture beyond violence because we believe that black lives matter.
|
||||
|
||||
|
||||
{% include carousel.html height="50" unit="%" duration="7" collection=site.data.blm-2019-09-26.images %}
|
||||
|
||||
Participants
|
||||
============
|
||||
* Avner Maximiliano de Paulo
|
||||
* Carlos Eduardo Oliveira de Souza
|
||||
* Bruna Guimaraes Lima e Silva
|
||||
* Maria Esther
|
||||
|
||||
|
||||
## Presentations
|
||||
* (2019 / 09 / 26) Brazilian Symposium on Computer Music (SBCM). São João del-Rei.
|
||||
|
||||
|
||||
|
||||
Publications about it
|
||||
=====================
|
||||
|
||||
{% bibliography -q @*[title ^= *Black Lives Matter*] %}
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
5° Seminário de Arte Digital
|
||||
----------------------------
|
||||
|
||||
Entre os dias 23 e 26 de abril de 2019, em equipamentos do Circuito Liberdade (Belo Horizonte/MG - http://www.circuitoliberdade.mg.gov.br/pt-br/), acontece o Seminário de Artes Digitais de 2019. O congresso de arte, ciência e tecnologia alcança a sua 5ª edição e tem como tema geral "Projeções e Memória da Arte" consolidando-se como um evento internacional com membros em seu comitê científico composto por doutores de instituições do Brasil e do exterior. A participação de eminentes pesquisadores do exterior já vem ocorrendo desde a edição de 2017, sendo que o evento ocorre desde 2015 de modo ininterrupto mobilizando imensa rede nacional e internacional de grupos, instituições, pesquisadores e artistas.
|
||||
O 5º Seminário de Artes Digitais é organizado pelo Laboratório de Poéticas Fronteiriças (http://labfront.tk - UEMG/CNPq) a partir de comitê composto por membros de várias instituições (UEMG, CEFET-MG, UFSM, FAD/ICAT). A edição de 2019 é estendida e conta com o apoio de agências de fomento nacionais e diversos outros parceiros tais como grupos de pesquisa consolidados no país e no exterior.
|
||||
O tema desta edição foi um consenso produzido a partir das discussões presentes sobre a memória da arte em todas as edições anteriores do congresso. Além disso, projetamos as discussões sobre a memória da arte e de outras ações do campo desde o dia de hoje para o futuro, o que permite que comunicações de pesquisas (e de produção de obras de arte) de várias temáticas possam ser apresentadas no evento sendo apresentadas para toda a comunidade científica.
|
||||
As sessões plenárias e as conferências de nosso congresso trazem temas de áreas de interesse comum aos pesquisadores, professores e público, participantes do evento (tais como Artes, Ciência da Computação, Engenharias, Ciências da Vida dentre outras).
|
||||
|
||||
|
||||
{% include carousel.html height="50" unit="%" duration="7" collection=site.data.chaos-bh.images %}
|
||||
|
||||
[Back to Chaos](/chaos.html)
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
III Mostra Vestígios
|
||||
--------------------
|
||||
|
||||
A III Mostra Vestígios, do Programa Interdepartamental de Pós-graduação Interdisciplinar em Artes, Urbanidades e Sustentabilidade (PIPAUS), da Universidade Federal de São João del-Rei, é uma exposição coletiva que consiste na exibição de fragmentos dos trabalhos desenvolvidos na disciplina Arte Ciência com base no conteúdo estudado durante o período, a partir das teorias e dos autores propostos e da prática idealizada por cada grupo. O resultado é um trabalho teórico-prático e abordando a transdisciplinaridade de forma aplicada.
|
||||
|
||||
|
||||
{% include carousel.html height="50" unit="%" duration="7" collection=site.data.chaos-mostraVestigios.images %}
|
||||
|
||||
[Back to Chaos](/chaos.html)
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
Quinta Cultural
|
||||
---------------
|
||||
|
||||
|
||||
{% include carousel.html height="50" unit="%" duration="7" collection=site.data.chaos-2019-05-23.images %}
|
||||
|
||||
[Back to Chaos](/chaos.html)
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
17th Bazilian Symposium on Computer Music (SBCM)
|
||||
------------------------------------------------
|
||||
|
||||
The Brazilian Symposia on Computer Music are thriving and exciting venues for sharing ideas about recent developments in the fields of computer music, sound and music processing, music information retrieval, computational musicology, multimedia performance and many other things related to art, science and technology.
|
||||
We would like to invite you to contribute to and participate in this event, which will take place at the beautiful campus of the Federal University of São João del-Rei, Brazil, from September 25th to September 27th 2019. During the event, participants will have the opportunity to attend to keynote talks, oral presentations of music and technical papers, poster discussion sessions, workshops, discussion panels and concerts, and will have plenty of opportunities to interact and discuss collaborations with other participants.
|
||||
|
||||
|
||||
{% include carousel.html height="50" unit="%" duration="7" collection=site.data.chaos-sbcm.images %}
|
||||
|
||||
[Back to Chaos](/chaos.html)
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
Sons de Silício
|
||||
---------------
|
||||
|
||||
O Espaço das Artes da Escola de Comunicação e Artes (ECA) da USP recebe a ocupação Sons de Silício do dia 1 até 26 de abril. A exposição traz cerca de 20 instalações que exploram os limites do que tradicionalmente é reconhecido como som, estimulando efeitos inusitados através do uso da tecnologia. Ela é coordenada pelo Grupo de Práticas Interativas (GPI) do Núcleo de Pesquisas em Sonologia, sediado no Departamento de Música da ECA.
|
||||
Durante a ocupação, serão realizadas performances e oficinas, também no Espaço das Artes. As performances, com diferentes grupos e artistas, ocorrem nos dias 1º, 4, 8 e 22 de abril, sempre às 18 horas. Já as oficinas acontecem nos dias 8, 12, 23 e 26 de abril, às 10 horas. Sons de Silício faz parte da 15ª edição da série ¿Música?, promovida desde 2005 pelo Núcleo de Pesquisas em Sonologia.
|
||||
|
||||
|
||||
{% include carousel.html height="50" unit="%" duration="7" collection=site.data.chaos-sp.images %}
|
||||
|
||||
[Back to Chaos](/chaos.html)
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
O Chaos das 5
|
||||
-------------
|
||||
|
||||
"O Chaos das 5" is an audiovisual digital performance. The guideline of the performance is inspired by Alice, from Lewis Carroll book - Alice in the Wonderland, as a metaphor to take the audience to a synthetic and disruptive wonder world. The concept of the performance is to conceive the possibility to the audience to interact through digital interfaces creating an immersive and participatory experience by combining three important layers of information (music, projections and gestures) through their cellphones. Once that the audience members take part of the show on an immersive aspect,
|
||||
there is no stage or another mark to limit the space of the performers and the audience.
|
||||
|
||||
The Musical Layer is composed by the digital devices to be accessed by the public on their cellphones and with 5 musicians improvising with their unconventional digital musicians. The Visual Layer projections made in real time presents an aesthetic that puts the computer in scene, opening the "Black Box" and exposing the machine in its realistic imaging.
|
||||
|
||||
Public interaction is given by the capture of images and data to be used in the projections. The Gesture Layer counts with a performance that mixes a set of gestures, improvisations and physically interactions with the audience in the space of the show. The plot is organized in a first welcome, three scenes and a final credit show.
|
||||
|
||||
|
||||
{% include carousel.html height="50" unit="%" duration="7" collection=site.data.chaos-2019-05-23.images %}
|
||||
|
||||
|
||||
## Check the pics of some presentations
|
||||
* III Festeco - Mariana (20/09/2019)
|
||||
* [Sons de Silício - São Paulo (08/04/2019)](/chaos-sp.html)
|
||||
* [V Seminário de Arte Digital - Belo Horizonte (26/04/2019)](/chaos-bh.html)
|
||||
* [Quinta Cultural - São João del-Rei](chaos-quinta.html)
|
||||
* [Bazilian Symposium on Computer Music (SBCM) - São João del-Rei (25/09/2019)](/chaos-sbcm.html)
|
||||
* XIX Festival de Artes Cênicas de Conselheiro Lafaiete (FACE) - Conselheiro Lafaiete (19/07/2019)
|
||||
* [III Mostra Vestígios - São João del-Rei (23/11/2018)](chaos-mostraVestigios.html)
|
||||
|
||||
[Check it out!](webart/chaosdas5/)
|
||||
|
||||
Publications about it
|
||||
=====================
|
||||
|
||||
{% bibliography -q @*[title ^= *Chaos*] %}
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
<!-- Descrição e informações sobre o projeto. Assim como participantes e artigos ligados ao projeto. -->
|
||||
<!-- Além de conter link para acessar o site do projeto. -->
|
||||
|
||||
# GlueTube
|
||||
|
||||
GlueTube was created as a tool that aims to provide an environment for both musical and visual creation, based on collage techniques and the use of videos available on YouTube in addition to other online content.
|
||||
|
||||
**Participants**
|
||||
|
||||
* Avner Maximiliano de Paulo
|
||||
* Carlos Eduardo Oliveira de Souza
|
||||
|
||||
**Publications about the GlueTube**
|
||||
|
||||
{% bibliography -q @*[title ^= *GlueTube*] %}
|
||||
|
||||
**GlueTube project website**
|
||||
|
||||
[Click here](https://alice.dcomp.ufsj.edu.br/webart/gluetube){:target="_blank"} to access the project website.
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
|
@ -1,23 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
Per(sino)ficação
|
||||
================
|
||||
|
||||
The bell’s culture is a secular tradition strongly linked to the religious and social activities of the old Brazilian’s villages. In São João del-Rei, where the singular bell tradition composes the soundscape of the city, the bell’s ringing created from different rhythmic and timbral patterns, establish a language capable of transmitting varied types of messages to the local population. In this way, the social function of these ringing, added to real or legendary facts related to the bell’s culture, were able to produce affections and to constitute a strong relation with the identity of the community. The link of this community with the bells, therefore transcends the man-object relationship, tending to an interpersonal relationship practically.
|
||||
|
||||
Thus, to emphasize this connection in an artistic way, it is proposed the installation called: PER(SINO)FICAÇÃO. This consists of an environment where users would have their physical attributes collected through the use of computer vision. From the interlocking of these data with timbral attributes of the bells, visitors would be able to sound like these, through mapped bodily attributes capable of performing syntheses based on original samples of the bells. Thus the inverse sense of the personification of the bell is realized, producing the human “bellification”.
|
||||
|
||||
{% include carousel.html height="50" unit="%" duration="7" collection=site.data.pesinoficacao-SBCM2019.images %}
|
||||
|
||||
Participants
|
||||
============
|
||||
* Fábio dos Passos Carvalho
|
||||
* João Teixeira Araújo
|
||||
|
||||
Publications about it
|
||||
=====================
|
||||
|
||||
{% bibliography -q @*[title ^= *Per\(sino*] %}
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
[Check it out!](/webart/tear.html/).
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
||||
Telefone Sem Fio
|
||||
------------------
|
||||
|
||||
Em construção
|
||||
|
||||
Participantes
|
||||
============
|
||||
* Carlos Eduardo Oliveira de Souza
|
||||
* Jônatas
|
||||
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
displaymenu: true
|
||||
---
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
title: Projetos de Software
|
||||
lang: pt
|
||||
---
|
||||
|
||||
{% assign projects = site.projects | where:"project_type", "software" %}
|
||||
<div>
|
||||
{% for item in projects %}
|
||||
{% include project.html %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
Loading…
Reference in New Issue