RAFAEL AUGUSTO PISSARDO Orientador: Prof. Dr. Jesus ...professor.ufabc.edu.br/~jesus.mena/misc/modelos... · This report has as main objective to describe as activities carried out

UNIVERSIDADE FEDERAL DO ABC

BACHARELADO EM CIENCIA DA COMPUTACAO

ESTAGIO SUPERVISIONADO III

RAFAEL AUGUSTO PISSARDO

Orientador: Prof. Dr. Jesus Pascual Mena-Chalco

Santo Andre – SP

2017

RAFAEL AUGUSTO PISSARDO

PROGRAMADOR JR II NA MJV SOLUCOES EM TECNOLOGIA E ESTAGIO E

TRAINEE EM DESENVOLVIMENTO DE SISTEMAS NA CODUS TECNOLOGIA

Relatorio de estagio apresentado a banca do Ba-

charelado em Ciencia da Computacao da Universi-

dade Federal do ABC como requisito parcial para

a obtencao do tıtulo de Bacharel em Ciencia da

Computacao.

Orientador: Prof. Dr. Jesus Pascual Mena-Chalco

Santo Andre – SP

2017

DEDICATORIA

A minha companheira de todas as horas, aos meus irmaos,e principalmente, minha mae que me

apoiaram desde sempre, incondicionalmente.

1

AGRADECIMENTOS

Ofereco meus sinceros agradecimentos:

Ao professor orientador Jesus, a minha famılia.

A todos da MJV pela oportunidade unica proporcionada.

A todos da Codus pelo treinamento e pela oportunidade de trabalhar com pessoas extremamente

capacitadas.

2

”Todo progresso economico e social, em

ultima analise, depende de novas ideias que

contestem a introspeccao e a inercia do

status quo”

Dodgson and Gann [3]

Resumo

Este relatorio tem como objetivo principal descrever as atividades realizadas como Programador

Jr II na MJV Solucoes e Tecnologia, alem de Estagiario e, posteriormente, Trainee em Desenvolvi-

mento de Software na Codus Tecnologia. Tais atividades foram exercidas durante o Bacharelado

em Ciencias da Computacao na Universidade Federal do ABC, entre 2015 e 2017. O relatorio

traz o desenvolvimento e aprendizagem de novos conhecimentos em ambas equipes, bem como

os detalhes profissionais proporcionados.

Palavras-Chave: Mjv, IoT, Agil, Desenvolvimento, Prototipagem, Codus, Ruby, Rails, Clean

Code.

4

Abstract

This report has as main objective to describe as activities carried out as Programmer Jr. II

in MJV Solutions and Technology, in addition to intern and later Trainee in Software Develop-

ment at Codus Tecnologia. These activities were carried out during the Bachelor’s Degree in

Computer Science at the Federal University of ABC between 2015 and 2017. The report brings

the development and learning of new knowledge in both teams, as well as the technical details

provided.

Palavras-Chave: Mjv, IoT, Agile, Development, Prototyping, Codus, Ruby, Rails, Clean Code.

5

Sumario

1 Introducao 8

1.1 Instituicao concedente: MJV Solucoes e Tecnologia . . . . . . . . . . . . . . . . . . 8

1.1.1 Objetivos a serem alcancados . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.1.2 Caracterizacao e analise da MJV . . . . . . . . . . . . . . . . . . . . . . . . 8

1.1.3 Caracterısticas da area onde o estagio foi realizado . . . . . . . . . . . . . . 9

1.2 Instituicao concedente: Codus Desenvolvimento de Sistemas Computacionais Ltda. . 11

1.2.1 Objetivos a serem alcancados . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.2.2 Caracterizacao e analise da Codus Tecnologia . . . . . . . . . . . . . . . . . 11

1.2.3 Caracterısticas da area onde o estagio foi realizado . . . . . . . . . . . . . . 12

2 Atividades na MJV 14

2.1 Atividades Desenvolvidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Buddies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Ferramenta para Auxiliar Criacao de Personas . . . . . . . . . . . . . . . . . . . . . 15

3 Atividades na Codus 18

3.1 Estagio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.1 Introducao as Atividades Propostas e Ferramenta de Controle das Atividades 18

3.1.2 Estudo HTML + CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.3 Estudo JavaScript +JQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.4 Leitura do Livro: Clean Code[5] . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.5 Implementacao de um jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.6 Leitura do Livro: Programming Ruby 1.9 and 2.0 [9] . . . . . . . . . . . . . 20

3.1.7 Leitura do Livro: The Rspec Book: Behaviour Driven Development with

Rspec, Cucumber, and Friends [2] . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.8 Leitura do Livro: Agile Web Development with Rails 4 [8] . . . . . . . . . . 21

3.1.9 Diario de Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Trainee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.1 Primeiro Grande Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.2 O projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.3 Modularizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2.4 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2.5 Diario de Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4 Apresentacao aos Alunos 38

5 Disciplinas necessarias para o estagio 38

6 Consideracoes finais 39

6.1 Contribuicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.2 Dificuldades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6

Lista de Figuras

1 Logo da MJV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Logo da Codus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Mapa do escritorio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Telas do Prototipo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Grafo Gerado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6 Tabela Ordenada por Centralidade de Intermediacao. . . . . . . . . . . . . . . . . . 17

7 Primeiro exercıcio feito na Codus. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

8 Caludadora construıda com JavaScript, HTML e CSS. . . . . . . . . . . . . . . . . . 19

9 Telas do jogo desenvolvido. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

10 Modularizacao de um botao utilizado inumeras vezes. . . . . . . . . . . . . . . . . . 30

11 Tela com modularizacao aplicada. . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

12 Slides da aula. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7

1 Introducao

Nessa secao, apresenta-se a caracterizacao geral do estagio, das empresas e das atividades es-

pecıficas realizadas. O Relatorio Parcial de Estagio I, iniciado na MJV Solucoes e Tecnologia, teve

inicio em 2016, porem, o vınculo empregatıcio dava-se desde 2015. O vınculo teve como principal

objetivo, desde o princıpio, o suporte e a construcao do Laboratorio Digital, ou Laboratorio de Inter-

net das Coisas. O Laboratorio foi composto por dois funcionarios (Programadores Jr II), alunos da

Universidade Federal do ABC. Uma sala com componentes basicos para eletronica e uma impressora

3D foram as primeiras ferramentas disponıveis, crescendo de acordo com a necessidade. O Relatorio

Parcial de Estagio II, teve inıcio em Setembro de 2016, quando fui chamado para ser membro do

programa de estagio da Codus. O conteudo principal do relatorio foi o Treinamento dado a todos os

estagiarios que entram na Empresa. Ao total, o Treinamento durou cerca de 45 dias. Finalmente,o

Relatorio Final de Estagio III, teve inicio apos a efetivacao como Trainee em Desenvolvimento de

Software em Fevereiro de 2017. A efetivacao deu-se apos 5 meses como estagiario na Empresa, e

alocado em projeto.

1.1 Instituicao concedente: MJV Solucoes e Tecnologia

Endereco: Rua Helena 280, 3o Andar - Vila Olımpia.

CEP: 04552-050

Cidade: Sao Paulo

Estado: SP

CNPJ: 06.944.264/0001-80

Representado por: Rafael Lopes Ribeiro Cargo: Head de Inovacao Estrategica

Supervisor de Estagio: Rafael Lopes Ribeiro

Horario do Estagio: 09h as 16h

Total semanal: 30 horas.

Atividades:

• Participacao na construcao do Laboratorio Digital

• Responsavel pela manutencao dos equipamentos do Laboratorio

• Desenvolvimento agil de prototipos para solucoes de problemas apresentados

1.1.1 Objetivos a serem alcancados

Durante o perıodo de estagio, o colaborador devera desenvolver e possivelmente implementar

conceitos e prototipos desenvolvidos no Laboratorio de Inovacao Digital, alem de, ocasionalmente,

interagir com as equipes de Designers de Servico envolvidas nos projetos para atualizacao de in-

formacoes. Alem disso, o colaborador, devera mostrar flexibilidade a mudancas de rumos e de

projetos.

1.1.2 Caracterizacao e analise da MJV

A MJV Tecnologia e Inovacao e uma empresa fundada ha 18 anos. Tem o escritorio principal,

localizado no Rio de Janeiro, e suas filias, em Sao Paulo, Londres e, a mais recente, em Atlanta.

8

Conhecida e premiada por desenvolvimento com Design Thinking, a MJV e uma empresa inovadora

que aposta em novos talentos e mentes jovens. Com clima descontraıdo a disposicao dos escritorios

permite que todos os colaboradores tenham acesso as mais diversas areas da empresa. Assim, um

programador tem acesso aos projetos de design e vice-versa. Por isso, a Empresa conta com uma

equipe multidisciplinar e mais de 300 funcionarios. Na Figura 1, apresenta-se o logo da MJV.

As principais areas de destaques sao:

• Design Thinking

• Gameficacao

• Bigdata

• Metodologia Lean

• Estrategia Digital

• Internet of Things

Alguns clientes que a MJV atende:

• Bradesco

• Coca-Cola

• Claro

• Schneider

• Ipiranga

Figura 1: Logo da MJV.

1.1.3 Caracterısticas da area onde o estagio foi realizado

Os trabalhos foram realizados no Laboratorio Digital (Lab) da MJV, em Sao Paulo, como Pro-

gramador Jr II. O Lab e o setor da empresa que mais integra todas as demais areas, sendo assim,

nao ha um responsavel unico. Cada projeto e demandado por um Diretor responsavel, que classifica

as necessidades e qualidades do Lab.

9

O Lab fica na sala 301 do escritorio da Mjv, Vila Olımpia. Ha outro Lab, maior, no Rio de

Janeiro. O Lab do Rio, conta com 5 colaboradores. Em Sao Paulo, o Lab conta, apenas com dois

Programadores Jr II e mais 2 pessoas de apoio. Um colaborador e desenvolvedor back e front e outro

cuida da parte de Infraestrutura da Mjv. Portanto, ambos somam ao trabalho do Lab.

O proposito, primordial, do Lab e fornecer prototipos e solucoes rapidas com o princıpio de uma

’Garagem Maker’ ou um Maker Space. Sendo assim, a empresa realiza constantemente Hackathons.

Ambiente descontraıdo e, um tanto quanto, informal, todos os colaboradores da Empresa tem acesso

e conhecem o Lab. Por vezes algumas ideias sao levantadas e verifica-se a viabilidade pelos membros

do Laboratorio.

10

1.2 Instituicao concedente: Codus Desenvolvimento de Sistemas Computacionais

Ltda.

Endereco: Avenida Paulista 575, conjunto 1211 - Bela Vista.

CEP: 01311-911

Cidade: Sao Paulo

Estado: SP

CNPJ: 15.440.554/0001-87

Representado por: Bruno Pereira Bueno Cargo: Socio Administrativo

Supervisor de Estagio: Bruno Pereira Bueno

Horario do Estagio: 09h as 16h


Horario do Trainee: 08h as 17h


Atividades:

• Estudo e participacao em treinamento de tecnologias de desenvolvimento Web

• Modelagem e implementacao de Banco de Dados

• Desenvolvimento de sistema web utilizando Framework Rails (Ruby)

• Analise de Sistemas

• Planejamento de Interfaces

1.2.1 Objetivos a serem alcancados

Desenvolvimento e crescimento do estagiario, envolvendo o desenvolvimento de sistemas, a capa-

cidade de gerar codigos utilizando boas praticas de programacao e profundo conhecimento em Ruby

e no Framework Rails. Capacidade em auxiliar o crescimento da equipe.

1.2.2 Caracterizacao e analise da Codus Tecnologia

A Codus Tecnologia foi fundada no final de 2011 pelos engenheiros de computacao Bruno Pe-

reira Bueno e Vinicius Alves Oyama, ambos formados na Escola Politecnica da USP apos anos de

experiencia em empresas como IBM, Taqtile, Software Express e Infosimples.

A Codus ja executou com sucesso diversos projetos envolvendo Startups, aplicativos mobile e

sistema de controle interno para grandes empresas, sempre com a visao de integrar cada vez mais

a tecnologia com conhecimento em negocios continua provando ser muito bem sucedida, recebendo

sempre bons feedbacks de clientes e parceiros.

Hoje a equipe conta com dezoito pessoas (entre efetivos e estagiarios), formadas nas melhores

Universidades do paıs e que sao excelentes no que fazem.

A Codus e responsavel pelo desenvolvimento dos sistemas de empresas como:

• Sistema Naja

• Galeria Espaco Arte

11

• Econovia

• Meta Aulas

• aLavadeira

Nesses projetos, a Codus contou com sua equipe de engenheiros de computacao e desenvol-

vedores especialistas no desenvolvimento agil de sistemas web e mobile. Durante o estagio, ficou

claro que alem de produtos de excelente qualidade, a Codus, tambem, tem preocupacao com seus

colaboradores. Eventos mensais sao realizados com o intuito de unir os funcionarios, bem como ha

uma visıvel humanizacao do relacionamento de todos na empresa, independentemente do cargo. Tal

processo, propicia um ambiente de desenvolvimento agradavel e, o mais importante, oportunidade

de crescimento pessoal e profissional.

Outro detalhe, nıtido durante o estagio, e que os compromissos estudantis tem prioridade na

formacao do colaborador. Caso haja necessidade de aulas durante a tarde ou qualquer outro detalhe

que remeta aos estudos do colaborador, a Codus sempre esta disposta encontrar a melhor opcao para

ambos os lados. Na Figura 2, encontra-se o logo da Codus.

Figura 2: Logo da Codus.

1.2.3 Caracterısticas da area onde o estagio foi realizado

O estagio foi realizado no escritorio da Codus, na Avenida Paulista. O estagiario teve contato

direto, frequente e ilimitado a todos os membros da equipe, seja ele Diretor, Designer, Programador

ou estagiario. O ambiente da Codus e descontraıdo e com possibilidade de trabalho em diversos

ambientes. A Figura 3, mostra o mapa do escritorio.

12

Figura 3: Mapa do escritorio.

A Sala de ADM e a sala onde trabalham o RH e os Diretores da Codus.

A Sala de Dev e a sala de desenvolvimento. A sala mais silenciosa do escritorio.

A copa e livre a todos os membros.

Na sala Precisa acontecem algumas reunioes rapidas e descontraıdas bem como ha espaco para

trabalhos que exigem menos concentracao.

A Sala de Reuniao e utilizada com agendamento, e e onde a maioria dos encontros para o

treinamento ocorrem.

A Taverna dos Codinhos e o ambiente mais descontraıdo da Empresa. Nela ha puffs, mesa para

refeicoes, televisao entre outros detalhes. Quando a sala de reuniao esta ocupada, a Taverna e a

escolha para encontros e discussoes.

13

2 Atividades na MJV

2.1 Atividades Desenvolvidas

Durante o trabalho dentro do Lab, dois projetos foram desenvolvidos. Alguns sao projeto realiza-

dos anteriormente e que foram retirados da gaveta, por motivos financeiros ou interesses de clientes

pelo projeto.

2.2 Buddies

O projeto denominado “Buddies”, surgiu a partir de uma Hackathon interna, entre os colabora-

dores (Designers, Arquitetos, Programadores, etc) cujo o objeto era captar novas ideias, filtra-las e

repassa-las ao Lab para que tomassem vida.

O nome Buddies vem do ingles, “Amigao”. Um dos grupos percebeu o setor em potencial dos

andadores e donos de cachorros na cidade de Sao Paulo. A ideia, simplificada, era realizar um “Uber”

para cachorros.

Primeiramente, entao, pensou-se nas regras de negocio:

• Quais sao os tipos de usuarios? (Andadores, Donos, Administrador)

• Qual funcao cada usuario tem acesso?

• Qual a responsabilidade de cada usuario?

• Como sera o Aplicativo? (WebApp, Nativo, Mobile, Desktop)

• Como precificar?

Em reuniao com o Diretor do Projeto (Rafael Ribeiro) os Programadores membros do Lab e um

desenvolvedor de apoio, ficou decidido que por ser uma prova de conceito e, portanto, os resultados

iniciais deveriam ser visualizados de forma rapida, que a ferramenta de desenvolvimento utilizada

sera o Cake PHP. Nele, de forma rapida, somos capazes de criar e gerenciar as relacoes de banco,

sem maiores problemas.

No Cake dois tipos de arquivos sao os mais usados. Sao eles: Arquivos .ctp e os Controllers.

Nos .ctp, a principal funcao e o front-end. E no Controller, e o back-end. O Lab, portanto, foca

mais na parte de back. E a parte de front e adicionada, tambem, pelo Lab, porem apos passar pelas

mao de um Designer.

As relacoes e funcoes foram criadas de acordo com as regras de negocio, anteriormente estabe-

lecidas, e conforme o aplicativo foi tomando forma, tais regras de negocio, tambem, foram sofrendo

mutacoes. O aplicativo, basicamente, acontece em volta da API V3 do Google Maps. E pelo Maps

que o usuario localiza uma matilha, localiza sua posicao global, interage com outros usuarios etc.

Todo o codigo escrito para o Maps, foi escrita em JavaScript dentro do CakePhp. Sendo assim, existe

uma camada que recebe dados dos Controllers e executa variaveis de acordo com suas resposta.

A versao beta do prototipo foi realizada exclusivamente pelo Lab em tres semanas. Apos a

conclusao, testes internos foram realizados com colabores da Mjv SP, detectaram um problema

quando o sistema era aberto em Iphones. Tal erro, forcou o Lab recorrer a programadores mais

experientes da Empresa para sanar o problema.

14

Por fim, a versao, hoje, em teste interno e exibida (nao totalmente), mostrada na Figura 4.

Figura 4: Telas do Prototipo.

O Buddies ainda esta em fase de teste interna. Cada usuario tem um formulario para preencher,

que e conferido diariamente. Todas as sugestoes de mudancas, se simples e sensatas, sao realizadas

no mesmo dia pelo Lab. Caso contrario ou problema e levado ao Diretor do Projeto, ou armazenado

para discutir quando o aplicativo estiver mais maduro.

2.3 Ferramenta para Auxiliar Criacao de Personas

Em quase todos os projetos desenvolvidos na Mjv, ha uma camada importante de Design, mais

especificamente o Design Thinking. Com isso um problema foi levado ao Lab:

”Como reduzir o tempo gasto com leituras de entrevistas para caracterizacao de persona?”

Em um projeto que envolva personas, sao realizadas dezenas de entrevistas, com o maximo

de detalhamento possıvel sobre a pessoa entrevistada. Tal processo gera centenas de impressoes e

anotacoes bem como exige muito tempo dos designers avaliarem e separarem cada detalhe.

Pensando nesses fatos, basicamente, um sistema foi construıdo. Primeiramente, para efeito de

validacao de conceito, modelou-se um banco simples. Duas tabelas (nomes fictıcios, para efeito de

didatico):

• Texto Completo (id, Ctext, created)

• Texto Quebrado (id, Ptext, created)

A base em Cake Php foi levantada na plataforma em nuvem do Cloud9 e funciona em sincronia

com o Google Form. Com isso, a primeira etapa de coleta de dados estava quase completa.

15

O Designer disponibilizara um formulario do Google para o cliente/usuario responder, e sua

resposta sera submetida como arquivo .txt na plataforma do Cloud9. O arquivo .txt fica, entao

disponıvel para analise em nuvem.

Criou-se um codigo, que acessa o arquivo .txt especıfico do usuario desejado e faz dois proces-

samentos. Primeiramente, replica-se o texto completo para a tabela ’Texto Completo’, quebra-se o

texto, palavra por palavra (separadas por espaco) e sobe cada palavra, com um ID diferente, para

a tabela Texto Quebrado. Porem, um detalhe importante deve ser ressaltado. Determinamos que

ha palavras muito desejadas para analise (peso forte) e palavras que nao geram valor algum para a

analise. Assim, criamos dois vetores de palavras:

proibidas = [’,’, ’da’, ’das’, ’de’, ’do’, ’dos’, ’na’, ’no’, ’nos’, ’nas’, ’em’, ’onde’, ’aonde’, ’a’, ’o’,

’aos’, ’os’, ’as’, ’ao’, ’a’, ’e’, ’ou’, ’e’, ’cada’, ’por’, ’pelo’, ’pela’, ’pelos’, ’pelas’, ’para’, ’deles’, ’dele’,

’dela’, ’delas’, ’entao’, ’minha’, ’me’, ’enfim’, ’tambem’, ’tb’, ’q’, ’vc’, ’pq’, ’c’, ’n’, ’s’, ’qd’, ’mt’,

’depois’, ’antes’, ’assim’, ’etc’, ’isso’, ’tem’, ’essa’, ’esse’, ’pro’, ’pra’, ’com’, ’mas’, ’um’, ’uma’, ’la’,

’que’, ’aqui’, ’mais’, ’mas’, ’se’, ’ha’, ’deixe’, ’ate’, ’ate’, ’houve’, ’so’, ’vai’, ’cair’, ’ja’, ’ja’, ’vem’,

’disso’, ’,’, ’.’, ’;’, ’:’, ’(’, ’)’, ’[’ ,’]’ ];

qualitativas = [’bom’, ’ruim’, ’sim’, ’nao’, ’muito’, ’pouco’, ’bastante’, ’sempre’, ’nunca’, ’tudo’,

’fundamental’, ’importante’, ’principalmente’, ’parece’, ’raramente’, ’necessario’, ’precisa’, ’deve’];

As palavras proibidas, sao aquelas que nao agregam valor ao sistema e podem ser excluıdas da

analise. As palavras qualitativas sao aquelas que sao consideradas de extrema importancia para a

analise e, portanto, queremos que ele tenha uma influencia maior sobre as suas conexoes.

Conforme o texto e quebrado, tais palavras sao verificadas. Caso a palavra seja do tipo proibida,

ela nao e adicionada a tabela do banco. Caso for qualitativa, ela e duplicada da seguinte forma:

Frase inicial: ”Nao gostei desta marca e nunca mais usarei roupas dela”

Frase tratada: ”Nao gostei nao desta marca nunca usarei nunca roupas”

Observe que, reforcamos as palavras que querıamos, nas palavras relevantes ao sistema. ”gos-

tei”ficou isolado com o nao, e ”usarei ficou isolado com o nunca. Este princıpio de analise ja consegue

mostrar algum direcionamento no processo de criacao de personas, mas ainda nao e o suficiente.

Apos essa analise, totalmente independente de qualquer usuario, cria-se dois links para que o

Designer receba dois arquivos distintos. Um chamado nodes.csv e outro chamado edges.csv.

Esses dois arquivos contem todas as informacoes para gerarmos um grafo ordenado do sistema de

palavras. Ao digitar a URL com o nome do entrevistado analisado, o sistema baixa, automaticamente,

para o computador do Designer os arquivos referentes aquele processo.

Com esses dois arquivos e o software Gephi, a analise dinamica do sistema completo pode ser

feita. Bem como analise de centralidade e grau do grafo. Exibidos nas Figuras 5 e 6, respectivamente.

16

Figura 5: Grafo Gerado.

Figura 6: Tabela Ordenada por Centralidade de Intermediacao.

Analisando, estaticamente, o grafo, e sabendo que quanto mais em destaque a palavra maior

a Centralidade de Intermediacao. A set of measures of centrality based upon betweenness). Cabe

ao Designer, verificar dinamicamente, utilizando o Gephi, as ligacoes ordenadas, para facilitar a

determinacao de personas.

A Centralidade de Intermediacao foi escolhida devido ao trabalho de Freeman [4] sobre a influencia

de usuarios em outros usuarios em uma rede social. Este processo assemelha-se muito a rede gerada,

ou seja, busca-se a influencia em que uma palavra tem sobre a outra em um discurso direcionado.

Concluindo, no projeto utilizado para uma marca de joias e com clientes da classe alta percebeu-

se um padrao tanto na centralidade quanto no grau das palavras: ”eu”e ”compro”. Demonstrando

um certo egocentrismo e consumismo dos usuarios avaliados.

O sistema esta em fase de testes e, por enquanto, nao e utilizado para determinacao exclusiva

de personas. Ha uma busca pelas personas da forma classica (utilizada pelos Designers) e ao mesmo

tempo a comparacao com os resultados obtidos utilizando esta ferramenta.

17

3 Atividades na Codus

3.1 Estagio

3.1.1 Introducao as Atividades Propostas e Ferramenta de Controle das Atividades

A Codus fornece, para cada novo estagiario da equipe, um treinamento que dura em torno de

um mes e meio. Nesse treinamento, o novo membro fortalece e aprende alguns itens fundamentais

para o bom aproveitamento durante a realizacao dos futuros projetos dentro da Empresa.

Dentre eles:

• Nocoes avancadas em HTML, CSS, JavaScript e JQuery.

• Boas praticas de programacao e Clean Code.

• Linguagem Ruby.

O controle de todas as atividades realizadas no treinamento e nos projetos da Codus, e feito

por uma ferramenta desenvolvida pela propria empresa, denominada TimeSheet. Cada membro da

equipe controla e escreve seus horarios no sistema. Alem do fator para controle de horario o sistema,

tambem, capta o humor de cada membro diariamente e repassa os dados aos outros usuarios. Todos

da equipe tem total conhecimento de que o sistema nao foi feito para controle individual, mas sim

para repassar aos clientes detalhes do desenvolvimento do projeto.

O escopo do treinamento, tambem, inclui um momento denominado ”Hora da Duvida”. Duas

vezes por dia, a equipe se reune com os membros responsaveis pela tarefa (este membro, tambem,

passou pelo treinamento ao ingressar na Codus) e discutem duvidas pertinentes ao conteudo em

estudo.

3.1.2 Estudo HTML + CSS

Durante a primeira semana de treinamento, do dia 15/08 ao dia 19/08 o grupo estudou e

aprofundou os conhecimentos em HTML e CSS. Baseados no site W3, todo o conteudo foi revisado

e discutido. Como em todos os modulos, ha um desafio. Nesse modulo, o desafio foi montar em um

dia e meio um website para um suposto restaurante japones, denominado Sushi Ya!. Este WebSite

deveria ter quatro regioes obrigatorias: Home, Cardapio, Contato e Sobre Nos. O Sistema final e

exibido na Figura 7

Figura 7: Primeiro exercıcio feito na Codus.

18

3.1.3 Estudo JavaScript +JQuery

Apos a conclusao dos Estudos, discussoes e aprofundamentos em HTML e CSS o treinamento

abordou as ferramentas de JavaScript e JQuery. Apos a leitura teorica o desafio era construir uma

calculadora. Inicialmente programada sem o JQuery, a calculadora deveria ter algumas funcionali-

dades. Cada um era responsavel por toda a parte visual e inteligencia. Como sempre, a filosofia da

Codus era predominante: Deverıamos colocar Carinho no projeto. Mesmo que o codigo nao estivesse

perfeito ou com alguns bugs, a maxima de todos os projeto e Carinho. Abaixo a Figura 8 mostra a

calculadora desenvolvida.

Figura 8: Caludadora construıda com JavaScript, HTML e CSS.

Apos a implementacao com JavaScript, fomos desafiados a utilizar o maximo possıvel de JQuery

no sistema. Contudo, o design geral da calculadora se manteve. Apenas a logica de programacao

sofreu variacoes significativas.

3.1.4 Leitura do Livro: Clean Code[5]

Como futuro desenvolvedor de projetos em equipe, cada estagiario foi apresentado a um dos

livros bases da Codus. O Clean Code e um livro com regras basicas, porem nao universais de como

um codigo deve ser escrito para que a equipe siga um padrao e de forma que seu codigo fique legıvel

para a equipe.

Antes da leitura do livro, os codigos gerados anteriormente foram analisados e discutidos em

varias reunioes. Nesses encontros os codigos foram severamente criticados e a importancia do livro

tornou-se clara. Alguns vıcios, como declarar variaveis como x, y, z ou a, b, c, foram explicados e

desencorajados. Os capıtulos lidos foram: 1 ao 5, 7 e 10.

3.1.5 Implementacao de um jogo

Apos a leitura do Clean Code, a equipe determinou a criacao de um jogo com a implementacao

de tudo visto ate aquele momento. O jogo escolhido foi o classico Snake e deveria obedecer as

seguintes regras:

1. Igual ao Snake game classico.

2. Sistema de pontos para o jogador conforme come a comida.

3. Cada vez que come a cobra cresce.

4. Deve colidir com o proprio corpo (game over).

19

5. Ao bater na borda pode dar game over ou aparecer do outro lado.

6. Cada vez que come a cobra fica mais rapida.

Primeiramente foi proposto que uma solucao fosse pensada e transcrita. Apos a criacao da

estrategia de desenvolvimento, reunioes foram realizadas com os gestores para determinar os possıveis

problemas e os pontos fortes da solucao. Apos discutidos, o grupo teve a autorizacao para iniciar a

programacao, individualmente. A Figura 9, exibe como o jogo ficou, finalizado, em tres diferentes

telas.

Figura 9: Telas do jogo desenvolvido.

Durante o desenvolvimento reunioes e revisoes foram discutidas. A ultima reuniao direcionada a

este projeto, todos os participantes apresentaram e explicaram seu codigo. Alguns aspectos foram

fundamentais, na avaliacao, como: Carinho, Clean Code, e direcionamento do sistema para um

futuro suporte multi jogadores.

3.1.6 Leitura do Livro: Programming Ruby 1.9 and 2.0 [9]

A linguagem predominante nos sistemas desenvolvidos pela Codus e o Ruby e sua versao The

Rails. Portanto, nada mais coerente que seu estudo fosse parte do treinamento. O livro indicado

para leitura foi o Programming Ruby capıtulos 1 ao 11 e o capıtulo 16. Apos a leitura dos capitulos,

alguns exercıcios foram propostos e atualizados no repositorio (commit) no git lab da Codus. Sao

eles:

1. Um algoritmo que identifique que uma frase ou palavra e um palındromo.

2. Um algoritmo que identifique e retorne quantas vezes uma mesma palavra aparece em uma

frase.

3. Um algoritmo que simule o jogo Pedra, Papel ou Tesoura em duas etapas. Disputas em pares,

com o retorno do vencedor, e disputas em torneio, com o retorno do vencedor, apenas.

4. Um algoritmo que identifique os anagramas dentro de um array na entrada.

5. Um algoritmo que gere os anagramas das palavras de entrada, de acordo com um dicionario

pre-estabelecido pelo Ruby.

6. Um algoritmo com utilizacao basica de Programacao Orientada a Objetos, com pequenas

manipulacoes e retornos.

20

3.1.7 Leitura do Livro: The Rspec Book: Behaviour Driven Development with Rspec,

Cucumber, and Friends [2]

Rspec e uma ferramenta utilizada para teste. A importancia da leitura deste livro ficou bem clara

quando entende-se a filosofia por tras do livro. A conceito que envolve o Test Driven Development

(TDD) trouxe a todos os membros da equipe uma nova forma de pensar e desenvolver codigo.

Em poucas linhas, o TDD faz com o desenvolvedor em conjunto com outros desenvolvedores,

criem antes do codigo principal, um codigo de teste. Ou seja, e escrito um codigo que contera as

regras de negocio do sistema. E conforme o codigo do sistema e gerado, ele e testado, etapa por

etapa. O TDD sugere, tambem, que o desenvolvedor que fara os teste e escrevera os codigos de

testes nao seja o mesmo que desenvolvera o sistema.

O livro, tambem, aborda a utilizacao da ferramenta Cucumber, porem, ela nao foi abordada

durante o treinamento.

Para cada exercıcio realizado na etapa de aprendizado do Ruby, foi escrito um codigo para testa-lo

de acordo com a ferramenta Rspec. Neste caso a filosofia do TDD nao foi aplicada, afinal os codigos

ja estavam prontos e eram bem simples.

3.1.8 Leitura do Livro: Agile Web Development with Rails 4 [8]

A leitura deste livro, significa o iniciacao dos membros no desenvolvimento de projetos, efetiva-

mente. O Rails, e um framework de Ruby para desenvolvimento agil de sistemas para web. Como o

CakePhp era um conhecimento previamente adquirido, nao foi uma tarefa difıcil entender e programar

com o Rails.

A principal vantagem, sobre outros frameworks ja trabalhados, e que o banco de dados e sua

modelagem sao pertencentes ao aplicativo gerado. No CakePhp, por exemplo, todos os dados

contidos em banco sao armazenados de forma apartada do sistema. Ou seja em caso de migracao

do sistema para servidores diferentes, o banco deveria ser migrado junto ao sistema desenvolvido,

gerando dois trabalhos. Com o Rails, todo o conteudo do sistema, engloba o banco e seus dados.

Alem disso a estrutura em Model, View, Controller (MVC) torna todo desenvolvimento facil e

dinamico.

3.1.9 Diario de Atividades

Nessa secao, define-se as diferentes atividades realizadas em cada um dos dias de estagio.

Dia 15/08

• Apresentacao formal a equipe

• Leitura inicial sobre HTML e CSS

• Duracao: 7:08 horas

Dia 16/08

• Exercıcios em HTML e CSS

21


Dia 17/08

• Inıcio do da criacao do site do Sushi Ya! (Restaurante Real) em 3 versoes


Dia 18/08

• Inıcio dos estudos sobre JavaScript

• Workshop sobre HTMl e CSS. Exemplos revisados e exemplos mostrados com base nas duvidas

levadas durante a criacao do Sushi Ya!

• Duracao 6:32 horas

Dia 19/08

• Continuacao dos estudos teoricos e testes rapidos com variacoes pontuais

• Hora da Duvida: Discussao de duvidas


Dia 22/08

• Continuacao do estudo sobre JavaScript

• Implementacao da calculadora, apos leitura do conteudo teorico

• Dois momentos para Hora da Duvida.


Dia 23/08

• Finalizando a Calculadora e ajustando pequenos detalhes

• Estudo de JQuery

• Dois momentos para Hora da Duvida: Revisao da Calculadora. Reuniao muito produtiva,

discussao dos codigos, bem como, dicas, fundamentais, para melhorar o codigo


Dia 24/08

• Continuacao dos estudos sobre JQuery

• Reimplementacao da calculadora utilizando JQuery

• Hora da Duvida


22

Dia 25/08

• Reimplementacao da calculadora utilizando JQuery

• Hora da Duvida: Direcionamento para novas tarefas


Dia 26/08

• Termino da reimplementacao da calculadora com JQuery e ultimos itens do estudo de JQuery

• Introducao ao Clean Code

• Hora da Duvida


Dia 29/08

• Leitura do livro Clean Code

• Hora da Duvida


Dia 30/08

• Continuacao da leitura sobre Clean Code

• Introducao Ruby

• Hora da Duvida

• Workshop sobre Orientacao ao Objeto


Dia 31/08

• Estudo de Ruby

• Hora da Duvida


Dia 01/09

• Estudo de Ruby

• Direcionamento para a implementacao do jogo Snake


Dia 02/09

23

• Implementacao do jogo Snake

• Hora da Duvida


Dia 05/09

• Finalizacao e ajustes do jogo Snake

• Hora da Duvida

• Worshop sobre Git e GitLab


Dia 06/09

• Finalizacao e entrega final do jogo Snake

• Estudo de Ruby

• Workshop sobre Git e GitLab (ultimos detalhes)

• Hora da Duvida


Dia 07/09

• Feriado. Nao houve expediente.

Dia 08/09

• Estudo teorico de Ruby

• Hora da Duvida


Dia 09/09

• Estudo teorico de Ruby

• Hora da Duvida


Dia 12/09

• Finalizando os estudos teoricos de Ruby

• Leitura do ”Ruby Style Guide”


24

Dia 13/09

• Finalizando os estudos teoricos de Ruby

• Hora da Duvida

• Praticando em Ruby: uma nova linguagem, um novo conceito

• Reuniao Geral na Sala de Dev


Dia 14/09

• Praticando em Ruby: uma nova linguagem, um novo conceito. Finalizando os exercıcios

propostos

• Estudo teorico sobre Banco de Dados

• Workshop de JavaScript Parte I


Dia 15/09

• Continuacao dos estudos teoricos sobre Banco de Dados

• Hora da Duvida

• Iniciando os estudos teoricos sobre RSpec

• Workshop de JavaScript Parte II

• Workshop de Ruby Parte I


Dia 16/09

• Continuacao dos estudos teoricos sobre Rspec


Dia 19/09

• Continuacao dos estudos teoricos sobre Rspec

• Workshop de Ruby Parte II


Dia 20/09

• Implementacao do Rspec nos algortimos desenvolvidos em Ruby

• Estudo teorico em Rails

25

• Hora da Duvida


Dia 21/09

• Estudo teorico em Rails

• Reuniao de FeedBack com o Vinicius. Apontamento e discussao de qualidades e futuras

melhoras para o estagio. Reuniao individual.


Dia 22/09

• Continuacao dos estudos em Rails


Dia 23/09



Dia 26/09


• WorkShop ministrado pelo Vinicius sobre Cliente-Servidor


Dia 27/09


• Hora da duvida


Dia 28/09


• Hora da duvida


Dia 29/09

• Inıcio da construcao do sistema em Rails. Passo 1: Desenvolvimento de mesa. Levantamento

de requisitos

• Reuniao com o Vinicius, individual, para alinhamento e definicoes basicas da Loja em Rails

26


Dia 30/09

• Continuacao da construcao do sistema em Rails


Dia 03/10


• Ultima parte do Workshop de Cliente-Servidor


Dia 04/10


• Workshop sobre Grid com Bootstrap


Dia 05/10



Dia 06/10

• Finalizacao do sistema em Rails

• Estudando o Slim


Dia 07/10

• Revisando o codigo do sistema em Rails

• Estudo de Bootstrap, Slim, Sass

• Estudo orientado com o Henrique para aLavadeira


Dia 10/10

• Estudo de Bootstrap, Slim, Sass



Dia 11/10

• Explorando o Material Design



27

3.2 Trainee

3.2.1 Primeiro Grande Projeto

A fase Trainee deste relatorio, tem inıcio dia 01 de Fevereiro de 2017. Durante o perıodo entre o

termino do treinamento e a efetivacao como Trainee em Desenvolvimento de Software, um projeto

teve inıcio e a oportunidade programa-lo do inıcio foi dada. A Equipe era composta, inicialmente,

por dois Desenvolvedores, um Team Leader e duas Analistas de Sistemas. Durante o projeto, o Team

Leader foi substituıdo por demandas em outras atividades na Codus, uma Analista migrou para outro

projeto de forma amortizada e um dos desenvolvedores foi alocado em outro projeto.

3.2.2 O projeto

O cliente era a W1 - Finance. Uma empresa Europeia que auxilia tomadas de decisao financeira

por meio de entrevistas e analises pontuais para cada cliente.

A proposta interna da W1 e uma equipe em formato de piramide. Nessa piramide esta a regra

de distribuicao de comissoes e pontos de producao interno. O desejo da W1 e automatizar e desbu-

rocratizar, ate certo ponto, esses processos internos. Antes do inıcio do projeto, a W1 sofria perdas

com erros em calculos e processos. Portanto, um dos principais objetivos do projeto e eliminar falhas

humanas atraves de processos automatizados e, ainda assim, dinamicos.

Alguns pontos sao de extrema importancia para o projeto:

• Sistema de login com restricoes de usuarios

• Sistema individual para Administradores e Consultores

• Sistema de pagamento online confiavel

• Conceitos de previsao de pagamentos e pontos de producao

• Sistema de hierarquia interna da W1

• Sistema de envio de emails

Todos os calculos automatizados pelo sistema deveria garantir integridade dos dados e garantir

que a ideia fundamental de hierarquia e a distribuicao das comissoes seriam realizadas da forma mais

correta possıvel.

Gemas como Devise (Gerenciamento de Credencial), Monetize (Calculos e conversoes monetarias)

e ASSM (Maquinas de Estado) foram utilizadas para garantir a maior integridade do projeto.

Hoje, todos os calculos internos da W1 sao feitos a mao, ou por um sistema precario, antigo

e bilıngue. Ou seja, nao houve um padrao no desenvolvimento de sistema atual, tao pouco o

desenvolvimento de ferramentas que possibilitem a usabilidade em todos os processos realizados na

empresa. A equipe formada pela Codus, teve como principal objetivo entregar um projeto pensado

em cada necessidade dos usuarios. Fundamentalmente, tambem, a equipe se preocupou com tres

pilares, basicos, de seguranca e de desenvolvimento:

• Integridade

28

• Disponibilidade

• Sigilo

Um exemplo disto e o processo de previsao de comissoes. Cada Consultor gera Propostas de

Produtos a seus clientes. Tais Propostas tem um valor fixo, em reais, que varia de acordo com cada

servico contratado. Apos o cliente assinar a proposta, o Consultor deve enviar os documentos ao

Escritorio para o qual responde. O Escritorio, por sua vez, recebe, avalia e devolve ao Consultor

(contrato recusado), ou envia para a parceira (contrato aceito). Entenda-se por parceira a Porto

Seguro, por exemplo. Assim que enviado a parceira, a equipe criou um algoritmo que calcula

quanto o Consultor devera receber daquela Proposta, em quantas parcelas e em quais dias. Hoje,

para o Consultor, tal ferramenta e de extrema importancia, afinal, os Consultores nao tem vınculo

empregatıcio com a W1, e necessitam gerar um orcamento mensal.

Um detalhe importante desta ferramenta e que, com as comissoes previstas calculadas, pode-se

dizer se a parcela recebida no mes corrente e adiantada, atrasada ou em dia. Ou seja, novamente, o

Consultor podera verificar seu orcamento no final do mes, bem como prever quais comissoes e seus

valores ele pode esperar receber.

O quesito seguranca, e um dos maiores focos do projeto. A preocupacao envolve nao apenas

o sigilo dos dados, mas a integridade dos dados e das ferramentas. E de suma importancia que

Consultores possam editar, ver ou gerar processos, de clientes cadastrados em seu nome. Bem como

receber corretamente os Pontos de Producao, sem que possa de qualquer forma, manipular os dados.

3.2.3 Modularizacao

Um topico fundamental para a descricao do projeto e o objetivo de componentizar os elementos

durante o desenvolvimento. Por exemplo, o projeto deve ter caracterısticas unicas que formam sua

identidade visual. Sendo assim, um botao de ’salvar’, deve sempre ser igual, bem como ’voltar’, e

outras acoes.

No inıcio cada desenvolvedor realizada a tarefa conforme bem entendia, seguindo as normativas

e padroes do projeto. Porem, duas ou tres semanas de projeto, percebeu-se que valeria a pena gastar

um tempo modularizando os botoes em um componente denominado ui button. Tal componente

receberia o texto do botao, algum possıvel ıcone, a acao que ele devera realizar, seu tipo (positivo,

negativo, neutro positivo, neutro negativo). Caso necessario, outros parametros html poderiam ser

encapsulados em enviados ao botao.

A modularizacao e de extrema importancia neste projeto. Ela possibilita criarmos uma identidade

visual padronizada e de facil mudanca, caso necessario. Suponha que por algum motivo a W1 decide

que todos os botao que tomem acoes positivas, como ’salvar’, ’aceitar’, entre outros, deve ser azul e

nao mais verde. Com este processo de padronizacao, deve-se modificar apenas a classe invocada no

componente ’ui button’. Ou seja, alem de economizar tempo, o conceito de modularizacao durante

o desenvolvimento garante um baixo custo na manutencao futura. Um exemplo que teve grande

impacto no projeto e o exibido na Figura 10.

O codigo apresentado acima na Figura 10 permitiu que telas fossem geradas sem preocupacao

com estilo ou comportamentos dos botoes. Todos os desenvolvedores do projeto, gerarem um codigo

claro e padronizado.

29

Figura 10: Modularizacao de um botao utilizado inumeras vezes.

Figura 11: Tela com modularizacao aplicada.

3.2.4 Testes

Durante o projeto, os testes tiveram vital importancia para o sucesso dos entregaveis em cada

sprint. Ate o momento, o sistema conta com 298 arquivos de testes. Com o desenvolvimento, ficou

nıtido que os testes evitam, se feitos de forma correta, apontam alguns erros pontuais, conhecidos

pelos desenvolvedores. Porem, por mais que o desenvolvedor tente, nao e possıvel abordar todos

os possıveis pontos de falhas para todos os testes. Mesmo que testemos os servicos, workers,

telas, botoes entre outros, e apenas com o uso contınuo da ferramenta em que situacoes locais e

independentes vao refletir em algo especıfico do sistema.

30

3.2.5 Diario de Atividades

Nessa secao, as diferentes atividades realizadas em cada um dos dias de estagio.

Dia 22/02

• Pensando no algoritmo de Comissoes

• Ajustes o Commission Preview


Dia 23/02

• Programando

• Reuniao Diaria


Dia 24/02

• Ajustes testes

• Ajustes ProductProposals

• #3147 Testes de Product Proposal. Programando.


Dia 02/03

• Ajustes card #3146

• Programando

• Ajustes Prev and Next metodos

• Card: Como BP quero acessar a secao ABC da Analise


Dia 03/03

• Card: Como BP quero acessar a secao Trabalho da Analise

• Testes

• Customer - Improvements. Programando


Dia 06/03

31

• Ajustes codigo

• Reuniao

• Juntando os processos

• Programando


Dia 07/03

• Programando


Dia 08/03

• Programando


Dia 09/03

• Ultimos ajustes

• Programando

• Ajustes Offices, programando.

• Ajustes Clients

• Testes


Dia 10/03

• Programando

• Programando o novo fluxo de Analise


Dia 13/03

• Ajustes


Dia 14/03

• Adicionando dados ao Health

• Ajustes em Comisoes

32

• Criando Metas


Dia 15/03

• Assitindo a apresentacao do Celso sobre Solid

• Criando Metas


Dia 16/03

• Programando


Dia 17/03

• Programando


Dia 20/03

• Programando


Dia 21/03

• Programando Testes do Economy Center


Dia 22/03

• Programando

• Workshop com o Celso


Dia 23/03

• Testes

• Programando

• Ajustes em Analysis

• Ajustes Invoice


33

Dia 24/03

• Ajustes Canvas

• Ajustes Invoice

• Ajustes Analysis


Dia 27/03

• Ajustes analysis. Programando Leads

• Reuniao Geral

• Ligando Client ao Parceiro

• Ajustes Client Profile


Dia 28/03

• Adicionando Calendar Event Address

• Programando

• Feedback com o Vinicius


Dia 29/03

• Teste

• Workshop Solid


Dia 30/03

• Ajustes notifications

• Ajustes

• Programando


Dia 31/03

• Reuniao

• Programando

34


Dia 03/04

• Programando

• Codus Show

• Ajustes


Dia 04/04

• Ajustando Tests

• Programando


Dia 05/04

• Programando e Ajustes


Dia 06/04


• Reuniao


Dia 07/04

• Programando

• Reuniao


Dia 10/04

• Programando

• Reuniao Semanal

• Reuniao

• Estudo


Dia 11/04

35


• Programando


Dia 12/04



Dia 13/04



Dia 17/04


• Planejamento de Sprint

• Reuniao Semanal


Dia 18/04



Dia 19/04


• Workshop de SOLID


Dia 20/04



Dia 24/04


• Reuniao

• Reuniao Semanal

36


Dia 25/04



Dia 26/04


• Worksho Extensoes do Chrome


Dia 27/04



Dia 28/04


• Reuniao


Dia 02/05


• Migracao para novo Projeto


37

4 Apresentacao aos Alunos

Em Novembro de 2016, o Professor Doutor Jesus P. Mena-Chalco, convidou-me para conversar,

com seus alunos, sobre dicas e o mercado de trabalho, tendo base as duas empresas citadas neste

relatorio.

Por motivos maiores, a aula foi ministrada em doze de Abril de 2017. O Professor Doutor, dispo-

nibilizou uma grande parte de sua aula de Algoritmo e Estrutura de Dados I, para a apresentacao e

discussao com seus alunos. Este pode ser o impacto mais esperado dentro da comunidade academica,

afinal, pude compartilhar um pouco de minhas experiencias fora do mundo academico e alerta-los que

a Universidade e fundamental, sim, mas nao e o ponto final. Ha muito para aprender e desenvolver

no mercado de trabalho.

Alguns alunos me procuraram ao final da aula perguntando mais sobre a Codus, com duvidas sobre

qual caminho seguir em sua carreira. Alguns currıculos foram encaminhados ao Recurso Humano da

Codus, como indicacao. Outros alunos me pediram dicas sobre os Trabalhos de Conclusao de Curso,

ou disseram estar infelizes no respectivo estagio e queriam dicas sobre como procurar novas areas.

Portanto, a partir do momento que um evento externo, necessario para a formacao dentro da

Universidade, tras mudancas e discussoes de pensamentos dentro da propria Universidade, podemos

concluir que o estagio realizou seu papel.

Na Figura 12, tem-se tres dos vinte e quatro slides apresentados na aula

Figura 12: Slides da aula.

Em suma, a discussao teve muitos pontos positivos e pode encerrar esse ciclo de mais um estagio

em Ciencia da Computacao pela Universidade Federal do ABC acrescentando um pouco mais de valor

ao conhecimento desses alunos que estao no inıcio, ou que ainda nao comecaram a vida profissional.

5 Disciplinas necessarias para o estagio

Para a execucao de tarefas em ambas as equipes, foram tomadas como base de conhecimento,

principalmente, as materias contidas na Tabela 1

38

Processamento da Informacao • Desenvolvimento de algoritmos• Logica de programacao

Programacao Orientada ao Objeto • Ruby e uma linguagem orientada ao objeto. Tal materia foifundamental para o desenvolvimento do estagio

Computadores, Etica e Sociedade • Capacidade de tratar os problemas e direciona-los aos clientes

Algoritmos e Estrutura de Dados • Organizacao de dados para buscas e ordenacoes eficientes• Ter opiniao formada e criticidade ao escolher certos tipos

de algoritmos• Questionamento sobre as linguagens e quais algoritmos seusmetodos utilizam

Banco de Dados • Modelos de banco de dados• Linguagem SQL• Conhecimento MySql, PostgreSql, SQLite

Compiladores • Entendimento de como as gramaticas e os diversos sistemasde programacao funcionam

Linguagens Formais e Automato • Construcao e entendimento sobre maquinas de estados fa-cilita o desenvolvimento de sistemas• O Ruby utiliza os fundamentos de Expressoes Regulares

em sua logica. Tal conceito foi fundamental e diferencial noaprendizado a nova linguagem.

Tabela 1: Materias relacionadas ao estagio.

6 Consideracoes finais

Essa secao tem como objetivo mostrar as contribuicoes do estagio para a empresa, para o es-

tagiario e as maiores dificuldades encontradas durante o perıodo retratado.

6.1 Contribuicoes

As atividades realizadas durante o perıodo de trabalho em ambas as empresas, permitiu que uma

carreira e um foco profissional fosse tomado. Bem como auxiliou no acompanhamento das disciplinas

e no melhor entendimento do conteudo exposto pelos Professores.

Um ponto crucial destacavel neste perıodo foi o fato de nao apenas aprender, ou reforcar, algumas

linguagens e seu contexto, mas tambem e mais importante, como programar de forma limpa, coerente

e eficaz. Alem disso o aprendizado e a dinamica de um projeto [7] [1] [6] e do desenvolvimento de

um software sera de suma importancia, nao apenas para a carreira como Bacharel em Ciencia da

Computacao, mas como futuro Engenheiro de Automacao, Instrumentacao e Robotica. Ou seja,

esse perıodo, somou e gerou caracterısticas irreversıvel na forma de trabalho e relacoes pessoas no

mercado profissional.

6.2 Dificuldades

A maior dificuldade foi absorver todo o conceito novo sobre como programar. Durante o curso de

Ciencia da Computacao o foco nao e boas praticas em programacao e, sim, as logicas de programacao,

metodos e algoritmos. Portanto, ao trabalhar em equipe, deve-se programar com certos padroes bem

como visar sempre a qualidade do produto final.

39

O aprendizado para superar e corresponder as pressoes e expectativas de terceiros, como clientes

e superiores, foi de suma importancia. Um carater maduro foi criado com decisoes e atitudes

necessarias no dia a dia. Tal situacao reflete no cotidiano academico, profissional e pessoal.

Referencias

[1] David Airey. Logo Design Love: A Guide to Creating Iconic Brand Identities. Peachpit Press,

2009.

[2] Dave Chelimsky. The Rspec Book:Behaviour Driven Development with Rspec, Cucumber, and

Friends. Pragmatic Bookshelf, 2010.

[3] Mark Dodgson and David Gann. Innovation. L&PM Pocket Encyclopaedia, 2010.

[4] Linton C. Freeman. A Set of Measures of Centrality Based on Betweenness. American Sociological

Association, 1977.

[5] Robert Cecil Martin. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall,

2008.

[6] David A. Patterson and John LeRoy Hennessy. Computer organization and design - The hard-

ware/software interface. Morgan Kaufmann, 1994.

[7] Paolo Perrotta. Metaprogramming Ruby. Pragmatic Bookshelf, 2010.

[8] Sam Ruby, Dave Thomas, and David Hansson. Agile Web Development with Rails 4. Pragmatic

Bookshelf, 2013.

[9] Dave Thomas, Chad Fowler, and Andy Hunt. Programming Ruby 1.9 and 2.0. Pragmatic

Bookshelf, 2013.

40

Bruno Pereira Bueno

Socio Administrativo

Jesus Pascual Mena-Chalco

Professor Doutor Orientador

19 de Marco de 2017

41

Documents

RAFAEL AUGUSTO PISSARDO Orientador: Prof. Dr. Jesus ...professor.ufabc.edu.br/~jesus.mena/misc/modelos... · This report has as main objective to describe as activities carried out