[IDS] Bitbucket: Como clonar um repositório

Com uma conta criada e um repositório criado, devemos fazer um clone do repositório de forma a obter localmente o repositório e de forma a atualizá-lo com os avanços que forem feitos. Como podem ver abaixo, precisamos de fazer um clone do repositório antes de fazer push das alterações. No terminal, com o git instalado, executa o seguinte comando, onde:

• $BRANCH É o nome do branch ao qual o clone deve ser feito. Como no projeto existem três branches: production, quality e development, vamos utilizar "develop" como esse valor.
• $USER É o nome do usuário (deve ter acesso ao repositório) que vai fazer o clone e o push. Como o nome do meu usuário na Cloud é guilherme-marcello, esse será o valor utilizado por mim.
• $PASS É a password do usuário (deve ter acesso ao repositório) que vai fazer o clone e o push. Uma vez que a password é a parte mais importantante da credencial, para o exemplo, vou utilizar ***.

git clone --single-branch --branch $BRANCH  https://$USER:$PASS@bitbucket.org/guilherme-marcello/cfqc-mobile-flutter-hackathon-ma.git

Ao substituir:

git clone --single-branch --branch development  https://guilherme-marcello:***@bitbucket.org/guilherme-marcello/cfqc-mobile-flutter-hackathon-ma.git

Após executarem, podem fazer um ls para verificar se o repositório foi clonado e podem fazer cd para ele e começar a trabalhar!

cd cfqc-mobile-flutter-hackathon-ma

[IDS] Bitbucket: Como criar repositório e um projeto

Após criar uma conta no Bitbucket (não acredito que seja algo difícil de se fazer, portanto é escusado de fazer um step-by-step disso), o que deve aparecer no ecrã deve ser algo parecido com:

Ao clicar em "Projects" no menu lateral e em seguida em "Create project", é possível criar um projeto com definições mais específicas (como nome, key, descrição, privacidade e avatar do projeto):

Depois de selecionar "Create project" para concluir a criação do projeto na plataforma, é possível criar repositórios para o projeto (atenção: um projeto é algo grande, então convém dividir cada serviço ou programa por repositórios. "workspace">"projeto">"repositório"). 

Para isso, deve clicar em "Create repository" e definir as propriedades iniciais (podem ser alteradas) do repositório:

Para finalizar a criação do novo repositório, é preciso clicar no botão "Create repository" e o resultado deve ser algo parecido com:

[IDS] Trabalho em Equipa: Legibilidade do código e reuniões

    Começar a trabalhar em equipa não é nada prático no sentido em que qualquer ideia pessoal deve ser exposta de forma simples, objectiva e clara para todos os constituintes do trabalho. O mesmo se aplica ao grupo de desenvolvedores de um determinado projecto, isto é, o código deve ser universal e de fácil leitura. Com o tempo, as exigências se tornam costumes e costumes se tornam preferências pessoais e características de cada pessoa quanto desenvolvedor e colaborador de projectos.

    Quais práticas eu costumo adoptar para facilitar a comunicação e leitura do que escrevo?

    - Declaração de variável próxima da primeira utilização:

uint variavel = -5;
Console.WriteLine(variavel.GetType());

    - Nomes das variáveis com algum sentido:

uint PortugalResources = -5;
Console.WriteLine(PortugalResources.GetType()); 

    - Tipo ou classe antes da designação:

uint uintPortugalResources = -5;
Console.WriteLine(uintPortugalResources.GetType()); 

    - Comentários sobre a alteração ou resposta da implementação:

uint uintPortugalResources = -5;
Console.WriteLine(uintPortugalResources.GetType()); // System.Int64

    - Comentário com o meu nome e data:

// Guilherme Marcello - 2020/11/01
uint uintPortugalResources = -5;
Console.WriteLine(uintPortugalResources.GetType()); // System.Int64

    - Estar sempre disponível para tirar qualquer dúvida acerca dos motivos da minha alteração em reuniões!

[IDS] Estrutura do ambiente de desenvolvimento: rplotter

    Qualquer software bem estruturado divide cada uma das funcionalidades em tantas parcelas quantas possíveis e quantas necessárias forem para melhor desenvolvê-las. Somente desta forma, com a "divisão do código" por propósito e utilidade, os pequenos erros são mais facilmente removidos e alterados.

    O exemplo apresentado abaixo demonstra a estrutura do "rplotter", um simples programa desenvolvido por mim para automatizar o processo de geração semanal de gráficos (apresentados em meetings):

home@marcello:~/development/release/rplotter$ ls
assets  main.pdf  main.tex  first  second

    

    Ao nível de código, foram desenvolvidos dois grandes blocos: 'first' e 'second'. Para o directório 'first':

home@marcello:~/development/release/rplotter$ cd first/ && ls
assets  exe  source

    

    Em 'exe' ficam os binários, mas o código-fonte fica em 'source':

home@marcello:~/development/release/rplotter/first$ cd source/ && ls
chart  example  main.sh  packages  setup.sh

    

    No directório 'chart' estão todas as classes que geram os gráficos, em 'example' estão os ficheiros definidos como default e em 'packages' estão as dependências da aplicação.

    E se, houver erro no processamento dos dados importados?

    - Em rplotter/first/chart/processing/import a classe read está definida, portanto pode ser onde o erro é originado. 

    Analogamente, um erro na exportação do gráfico pode estar em rplotter/first/chart/processing/export, onde as classes get_plot e saveas estão definidas.

    Em suma, uma estrutura sólida e bem construída proporciona um ambiente de desenvolvimento saudável, limpo e preparado para qualquer processo de debug.

Figura 1: Exemplo de output da aplicação