Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
work:semana_30_de_2021 [2021/07/28 00:13] – [Pesquisa] magsilvawork:semana_30_de_2021 [2021/09/14 14:46] (current) – ↷ Links adapted because of a move operation 65.21.179.252
Line 2: Line 2:
  
 ===== Pesquisa ===== ===== Pesquisa =====
-  * Reunião com [[Yuri Rafael Grajefe Feitosa]]: revisão do PDM. +  * Reunião com [[.students:yuri_rafael_grajefe_feitosa]]: revisão do PDM. 
-  * Submissão de artigo do [[Bruno Henrique Pachulski Camara]] no SAST 2021. +  * Submissão de artigo do [[.students:bruno_henrique_pachulski_camara]] no SAST 2021. 
-  * Leitura de artigos:+  * Leitura de artigos sobre revisão de artigos:
     * "Pains and Gains of Peer-Reviewing in Software Engineering" (doi:10.1145/3375572.3375575).     * "Pains and Gains of Peer-Reviewing in Software Engineering" (doi:10.1145/3375572.3375575).
     * "Pains and Gains of Peer-Reviewing in Software Engineering (4)" (doi:10.1109/ICSE-C.2017.49)     * "Pains and Gains of Peer-Reviewing in Software Engineering (4)" (doi:10.1109/ICSE-C.2017.49)
Line 12: Line 12:
     * "Double-Blind is Good but Open Would Be Better Perceptions of Peer Review in the SE Community" (doi:10.1145/3402127.3402133).     * "Double-Blind is Good but Open Would Be Better Perceptions of Peer Review in the SE Community" (doi:10.1145/3402127.3402133).
     * "A community’s perspective on the status and future of peer review in software engineering" (doi:10.1016/j.infsof.2017.10.019).     * "A community’s perspective on the status and future of peer review in software engineering" (doi:10.1016/j.infsof.2017.10.019).
 +    * "Peer Reviewing in Software Engineering: Perspectives from STVR Co-Editors-in-Chief" (doi:10.1145/3417564.3417568). Este artigo trouxe uma ideia simples, mas efetiva para um problema abordado no Congresso da SBC: pesquisadores com quantidades muito elevadas de artigos. Por exemplo, é normal que um pesquisador publique 50 ou 100 artigos em um ano? Um argumento levantado naquela seção (CAPES/CNPq) foi que não existe um parâmetro definido pelas agências de fomento e que isso deveria partir da comunidade. O artigo menciona algo que passa desapercebido: o processo de revisão por pares deve ser autosustentável. Em outras palavras, se você tem 100 artigos publicados, você deve ter prestado o serviço de revisão de uma quantidade compatível de seus pares (3 a 4 vezes a quantidade de artigos _submetidos_). Ou seja, na melhor das hipóteses, alguém que tenha publicado 100 artigos teria de ter revisado 300 artigos (considerando taxa de aceitação de 100%). Assim fica fácil perceber que isso é humanamente impossível. No entanto, mecanismos públicos para registrar as revisões realizadas ainda são escassos. Talvez com a ampla adoção de soluções como o Publons ou o RQC (ReviewQualityCollector), isso poderá se tornar uma realidade.
 +    * "Peer Review: Trust and Prejudice" (doi:10.1145/3417564.3417569).
   * Considerando a maratona de artigos acima, de nota temos o site de Empirical standards da ACM: https://acmsigsoft.github.io/EmpiricalStandards/. Será utilizado na disciplina de Tópicos em Engenharia de Software -- Revisão sistemática.   * Considerando a maratona de artigos acima, de nota temos o site de Empirical standards da ACM: https://acmsigsoft.github.io/EmpiricalStandards/. Será utilizado na disciplina de Tópicos em Engenharia de Software -- Revisão sistemática.
   * Disponibilização do Code Defenders em http://dacom.cm.utfpr.edu.br/codedefenders.   * Disponibilização do Code Defenders em http://dacom.cm.utfpr.edu.br/codedefenders.
-  * Reunião com [[Vinicius Bosa Petris]]: configuração do Code Defenders.+  * Reunião com [[.students:vinicius_bosa_petris]]: configuração do Code Defenders. 
 +  * Reunião com [[.students:rafael_rampim_soratto]]: apresentação dos resultados da análise de código e revisão da ferramenta. 
 +  * Leitura do artigo "An Interview with Laurie Williams - ACM Fellow 2020 (doi:10.1145/3468744.3468750). Entrevista com Laurie Williams, uma pesquisadora de destaque e muito ativa em Engenharia de Software, com um trabalho especialmente próximo da indústria. Um bom exemplo de profissional: completo, com ótima atuação tanto na pesquisa quanto no ensino. 
 +  * Reunião com [[.students:leandro_césar_da_cruz]]: revisão do script para obtenção e processamento dos dados sobre teste de software.
  
 ===== Educação ===== ===== Educação =====
   * Seminário sobre gamificação pelo Marcos Mincov Tenório no Conexão UTFPR: https://www.youtube.com/watch?v=HLopuOvp57k   * Seminário sobre gamificação pelo Marcos Mincov Tenório no Conexão UTFPR: https://www.youtube.com/watch?v=HLopuOvp57k
 +  * Consegui instalar o [[Use Case Maker]] no Linux. Primeiro, é necessário configurar o .NET Framework 4.5.2 com o [[winetricks]]. Por padrão, sempre configure um prefixo por aplicação (WINEPREFIX) e, por via das dúvidas, configure a arquitetura para 32 bits (WINEARCH=win32). Ao invés de usar o instalador da última versão [[https://github.com/hsharpsoftware/use-case-maker/ | (disponível no Github)]], utilize aquele do SourceForge: [[https://sourceforge.net/projects/use-case-maker/files/use-case-maker/2.0.0.1%20-%20Installer/UseCaseMaker2001.msi/download | 2.0.0.1]].
  
 +===== Gestão =====
 +  * Conversa sobre plano de ensino (ementa, conteúdo) para algumas disciplinas de engenharia de software: https://docs.google.com/document/d/1N2favEcwuZDAubjDh3jpHPuYE2uOUASN_QLAmhQdd2A/edit
  
 +===== Manutenção =====
 +  * Desativar beep no Fedora/Gnome: ''gsettings set org.gnome.desktop.sound event-sounds false''