DEV Community: Bruno Rezende Novais

Compondo música com Java! É hora do Jmusic

Bruno Rezende Novais — Tue, 24 Oct 2023 11:56:13 +0000

É isso mesmo que você leu, se você sempre quis compor uma música ou imaginou como fazer isso com código saiba que é possível fazer isso e está a poucas linhas de distância. Hoje vou discutir um pouco e mostrar como é possível codar música usando Java.

Índice

O que é Música Computacional?
JMusic
Show me The Music
Quais as vantagens de se compor usando código?

O que é Música Computacional?

Primeiro é necessário darmos um passo atrás e falarmos sobre música computacional, para quem não conhece, de forma geral música computacional pode ser definida como música que envolve computação em qualquer estágio de seu ciclo de vida (Collins, 2009). Se aprofundarmos um pouco mais nessa definição, podemos pensar esse ramo como o estudo do uso da tecnologia computacional na música em quaisquer de seus estágios, seja na teoria ou prática.

Hoje com o avanço das inteligências artificiais a composição de música por máquinas já não é algo tão distante e geralmente não percebemos, mas já há o uso desse ramo de estudo em nosso dia a dia. Seja no Spotify que você abre, nos módulos de equalização de som que há no seu sistema operacional ou até mesmo no estúdio quando o engenheiro de som está usando compressores digitais ou efeitos de reverbs criados virtualmente. A música computacional é uma realidade.

Se ela é algo ético ou não, podemos discutir isso em outro artigo, mas hoje vamos passar a aprender um pouco mais sobre.

JMusic

Saiba que há uma infinidade de bibliotecas criadas para manipular e gerar som em diversas linguagens de programação, mas nesse artigo irei focar e mostrar que é possível criar música com Java. Para isso, vou introduzir a biblioteca JMusic, um projeto criado por Andrew Sorensen e Andrew R. Brown. Trata-se de uma lib completa e focada em composição que agrega desde exportadores de arquivo MIDI até mesmo instrumentos virtuais para você criar suas composições. Vale citar aqui também o livro escrito por Andrew R. Brown que foca exatamente na composição usando Java, vale leitura!

A documentação do JMusic está disponível aqui.

Show Me The Music

Vamos dar uma olhada no código e analisá-lo tal como um maestro.

Caso não esteja familiarizado com alguns termos musicais vou deixar um glossário no fim do artigo para ficar mais fácil :)


import jm.constants.ProgramChanges;
import jm.music.data.Note;
import jm.music.data.Part;
import jm.music.data.Phrase;
import jm.music.data.Score;
import jm.util.Read;
import jm.util.Write;

import static jm.constants.Durations.SEMIBREVE;
import static jm.constants.Pitches.C4;

public class Application {

    public static void main(String[] args) {

        Score score = new Score("JMDemo1 - Chromatic Scale");
        Part prt = new Part("Piano", ProgramChanges.PIANO, 0);
        Phrase phr = new Phrase("Chromatic Scale", 0.0);

        for(int i =0; i < 12; i++) {
            Note n  = new Note(C4+i,SEMIBREVE);
            phr.add(n);
        }

        prt.add(phr);

        score.add(prt);

        SimpleSineInst simpleSineInst = new SimpleSineInst(10000);

        Write.au(score, "WaveformExample.au",simpleSineInst);

        float[] audio = Read.audio("WaveformExample.au");

        Write.audio(audio,"waveform.wav");

    }
}

3.1 Definindo a partitura


      Score score = new Score("JMDemo1 - Chromatic Scale");
      Part prt = new Part("Piano", ProgramChanges.PIANO, 0);
      Phrase phr = new Phrase("Chromatic Scale", 0.0);

Primeiro instanciamos uma classe chamada Score (partitura) e precisaremos definir algumas partes dela como qual será o instrumento a seguir e qual canal do arquivo MIDI utilizaremos. Pense que o arquivo MIDI (Musical Instrument Digital Interface) é um arquivo que tem várias linhas ou canais.

A partir daí, já na linha seguinte criamos uma frase, que é onde conterá nossas notas e ritmos. Nesse caso, vamos fazer um exemplo mais simples e criar uma escala cromática começando a partir do minuto 0:0.


 for(int i =0; i < 12; i++) {
            Note n  = new Note(C4+i,SEMIBREVE);
            phr.add(n);
        }

Já no laço for, inserimos dentro da nossa frase as notas, a nota por sua vez tem também a sua altura. (usaremos a nota Dó – C na cifra americana) Adotaremos o Dó e como ritmo usaremos a semibreve que é uma unidade de tempo para a música. Assim, incrementalmente passaremos de nota em nota até completarmos o laço.


 prt.add(phr);

 score.add(prt);

Podemos pensar então que um Score (ou partitura) contém partes e as partes contém as frases que por sua vez contém as notas. Dessa forma vamos adicionando-as até que a frase fique completa.

3.2. Sintetizando nossa partitura

SimpleSineInst simpleSineInst = new SimpleSineInst(10000);

Write.au(score, "WaveformExample.au",simpleSineInst);

Poderíamos já tocar nossa composição, porém vamos exportá-la primeiro. Para isso, vamos ter que usar um sintetizador para produzir os sons da nossa partitura, assim criaremos uma instância de SimpleSineInst (um sintetizador simples) e passaremos ele para o módulo de escrita, exportando-o inicialmente em um arquivo do tipo au.

3.3 Exportando em outros formatos


float[] audio = Read.audio("WaveformExample.au");

Write.audio(audio,"waveform.wav");

Tendo agora nosso arquivo.aufica fácil, basta que leiamos ele e em seguida pode-se escrevê-lo como arquivo de áudio na extensão .wav por exemplo que é mais comum. Agora temos nossa composição exportada!

Ouça aqui o resultado final! Mas antes, recomendo que abaixe o volume de seu fone de ouvido para evitar problemas.

Quais as vantagens de se compor usando código?

Bom, a primeira de todas é que compomos uma música e criamos um sample(amostra) usando apenas código. Sim, não tivemos que comprar um teclado, uma guitarra ou uma interface de áudio para podermos capturar o som, bastou apenas algumas linhas do bom e velho Java. Com isso a primeira vantagem é custo, o custo para criar música assim é bem reduzido.

Ainda assim, podemos dar uma extrapolada e ir para “fora da caixa”. Podemos pensar no uso disso em diversos lugares, como por exemplo: games. Pode-se gerar proceduralmente música, pode-se fazer com que a partir de uma determinada decisão do jogador um som seja gerado ou ele mesmo gere uma partitura e no final você toque-a usando o JMusic por baixo dos panos, pode-se ler uma imagem por exemplo e convertê-la em uma sequência numérica para poder criar música a partir disso, música a partir de uma imagem!

Em termos de acessibilidade, podemos agora dar o poder para queles que não conseguem tocar por suas limitações físicas para dentro do mundo virtual, onde conseguirão produzir música usando os recursos de assistência dos computadores.

Aqui, o que limita é apenas a sua criatividade e a sua habilidade no código.

Bibliografia

COLLINS,N. Introduction to Computer Music. West Sussex, Reino Unido. 2009. p 2

Glossário

Partitura: Paritura pode ser definida como uma representação escrita de uma música onde está definido o ritmo, o tempo e as frases da música.

Frase: Também conhecida como frase musical, pode ser definido como um trecho de música coerente e autonomo em relação a um ritmo definido pela partitura.

Semibreve: Semibreve é uma das figuras rítmicas usadas na música sendo ela uma das de maior duração.

Escala cromática: A escala cromática é uma das escalas na música, escalas nada mais são que uma sequência ordenada de notas. Você pode saber mais sobre essa escala neste link.

Formato de arquivo Au: arquivos .au são tipo um tipo voltado para áudio, menos usual porém focado em conter informações os dados de áudio divido em três grandes blocos de dados.

Formato de arquivo WAV: arquivos .wav são um tipo mais comum de arquivos de áudio, geralmente usados já para músicas completas com uma maior qualidade sonora, geralmente são arquivos mais pesados em termos de espaço (megabytes)

O que a Fórmula 1 e todo software tem em comum?

Bruno Rezende Novais — Fri, 15 Sep 2023 00:55:14 +0000

Se você não conhece, Fórmula 1 é a categoria mais relevante hoje quando pensamos em automobilismo e mesmo que você não goste desse esporte, saiba que ela tem um ponto em comum com a maior parte dos nossos softwares: telemetria.

Mesmo que você não goste do esporte, muito das tecnologias que hoje temos disponíveis em nossos carros, como o freio ABS, vieram graças ao desafio tecnológico imposto nessa competição onde cada milissegundo ganho em relação ao outro pode te colocar mais perto da vitória.

Para nós do mundo de software carros em alta velocidade podem parecer um mundo distante reservado para os engenheiros mecânicos, mas na verdade nós temos um trabalho vital nessa indústria de alta performance, em especial no âmbito da telemetria.

Índice

O que é telemetria?
Como a telemetria é aplicada no dia a dia?
Mas o que isso tem a ver com as minhas aplicações?
Como funciona dentro do software?
Em suma, temos telemetria

O que é telemetria?

Seguindo o dicionário podemos definir telemetria como processo ou técnica de obtenção, processamento e transmissão de dados a longa distância. Graças ao avanço da Internet das Coisas (IoT) e das redes móveis a transmissão e obtenção de dados vem se tornado cada vez mais fácil e constante no nosso cotidiano. Não só isso, os aparelhos computacionais vêm se tornando cada vez mais invisíveis no nosso dia a dia e diminuindo a barreira entre o mundo digital e o físico, tal como imaginou Mark Weiser em seu artigo “The computer for the 21st Century”.

Não só em veículos, a telemetria hoje está presente em tudo, em usinas de energia, aparelhos médicos, dispositivos vestíveis (wearables) ou até mesmo nos nossos celulares, todo dado hoje é passível de ser extraído e processado.

Como a telemetria é aplicada no dia a dia?

Voltando ao nosso exemplo da Fórmula 1, se você nunca viu um carro aqui está um exemplo.

Fonte: Oracle Red Bull Racing

A princípio pode parecer apenas uma “nave”, mas acredite, esse carro tem sensor para tudo e quando eu digo tudo é tudo mesmo, pressão externa do pneu, pressão interna do pneu, combustível, pressão aerodinâmica em cada parte do carro, velocidade absoluta e relativa, GPS, temperatura interna e externa, enfim, existe uma diversidade de dados que podem ser obtidas de um “simples” carro e que são todas transmitidas por sensores conectados a redes móveis (5G) e processadas na nuvem dando luz a uma gama de dados que são analisados pelos engenheiros e estrategistas das equipes praticamente em tempo real, dando-os mais munição para tomarem as melhores decisões.

Por exemplo, um engenheiro ao ver que o carro está tendo mais pressão aerodinâmica do que o esperado pode pedir ao piloto mude a configuração do carro no próprio volante fazendo com que ganhe mais vantagem em relação ao adversário, isso só é possível graças a telemetria.

Mas o que isso tem a ver com as minhas aplicações?

Como disse anteriormente hoje em dia praticamente tudo produz dados e é passível de ser extraído e processado, basta você extrair as métricas certas. Com nossos softwares não é diferente, seja um simples CRUD em NodeJS ou um website Angular, tudo produz dados.

Você pode obter por exemplo qual o tempo de resposta médio da sua aplicação em NodeJS, quanto de memória e processamento de CPU ela está gastando, quantos requests por segundo ela está recebendo?

Assim como no front você pode ter métricas de quantos usuários estão baixando meus arquivos estáticos? Quais os pontos eles mais clicam na tela? Quanto tempo eles demoram para trafegar de uma tela a outra?

Tudo vai depender de o que exatamente você quer observar, a partir daí você extrai esses dados, transforma-os em métricas e gera informação que pode ser usada para otimizar ou ganhar mais vantagem em relação a concorrência ou otimizar a sua aplicação em pontos que ela ainda tem espaço para melhoria.

É claro que diferente de um carro, aqui não temos sensores físicos, usamos outros softwares como Prometheus por exemplo para extrair essas métricas a partir das máquinas/containers que estão rodando essas aplicações ou então bibliotecas que disparam eventos para outros servidores que por sua vez coletam e armazenam esses dados.

Fonte: Prometheus

Como funciona dentro do software?

Fonte: Cisco Code Blog

Bom, é claro que aqui vai diferenciar um pouco de caso a caso, mas de forma geral pode-se imaginar que as métricas geralmente são exportadas de um dispositivo e coletadas por outro. No meio desse caminho podemos ter outras ferramentas que por exemplo categorizam esses dados deixando-os mais palatáveis para nossos olhos. Ou seja, podemos de forma geral pensar que a telemetria funciona como uma pipeline (popularmente conhecido como esteira), você tem um ponto de origem, alguns processos e um ponto final no qual um processo depende do resultado do anterior. A isso nomeamos de arquitetura de pipeline ou arquitetura pipe-and-filter. (Abordei em um artigo futuro mais sobre esses modelos arquiteturais).

Ainda no exemplo do Prometheus, pense que temos uma aplicação em NodeJS rodando, o prometheus estará plugado como uma biblioteca nessa aplicação exportando dados como número de requisições sendo recebidas, status https sendo respondidos, tempo de resposta entre outras métricas. Essas métricas são enviadas para outra aplicação que atua como um coletor e capta esses dados, levando-os para uma fila por exemplo a qual irá transportar esses dados até uma outra aplicação que os processa e pode gerar dashboards, como por exemplo o Grafana o qual cumpre bem essa função.

Em suma, temos telemetria

Telemetria é talvez a grande ferramenta para a mina de ouro da era que estamos atuais: a era da informação, a era orientada a dados. Dados são ouro e informação é o ouro trabalhado. Seja em um micro-ondas, em um carro de Fórmula 1 ou na sua aplicação de estudo, sempre temos que ter isso em mente: como posso extrair e disponibilizar mais dados? Como posso processá-los e gerar valor com isso? Onde posso encontrar as perguntas que ainda não descobri e encontrar o caminho para a resposta? A telemetria nos dá o poder para isso.

Por que a habilidade política é importante na engenheria de software?

Bruno Rezende Novais — Sun, 05 Feb 2023 23:10:39 +0000

Recentemente estive lendo o livro The Staff Engineer’s Path da Tanya Reilly e um dos aspectos bem abordados no texto é sobre o uso e aquisição do capital social durante nossa evolução como engenheiros. Mas, esse pensamento levou-me a outro questionamento: e quanto ao nosso capital político? Não estou falando aqui de política partidária, de esquerda ou direita, partido A ou partido B e sim no sentido de guiar ou influenciar o modo de organização de um grupo principalmente através do debate de ideias.

Então, isso nos traz a outra reflexão bem importante, geralmente em meio aos códigos ou livros técnicos muitos acabam negligenciando essa soft-skill bem importante. Quanto de nós não lembra de na faculdade ter uma matéria como “Administração de conflitos” ou “Administração de relações” e simplesmente ignorar ela ou estudar apenas para passar? Essas disciplinas no fundo falam, entre outras coisas, sobre a política e como você pode usá-la para ajudar a guiar um grupo ou organização, infelizmente na maioria dos casos acabamos por simplesmente ignorar essas disciplinas talvez por nossa imaturidade.

Pois bem, neste texto irei trazer algumas reflexões do por que a política é tão importante para nós devs no dia a dia e alguns conselhos para ajudar a obter esse capital político.

1. Você não trabalha sozinho.

Não deveria ser novidade para qualquer desenvolvedor ou aspirante que os profissionais da TI não são aqueles profissionais que ficam escondidos no seu box no seu setor e não interagem com ninguém da empresa. Muito pelo contrário. O Engenheiro de Software hoje não é mais essa pessoa fechada, ele deve saber dialogar, deve saber expor suas ideias, mostrar para outras áreas suas visões quanto aos projetos das empresas e dialogar em uma linguagem em que os demais entendam e não somente eles. Trabalhar com desenvolvimento de software é trabalhar em equipe.

Já que trabalhamos em grupo, é normal que divergências de ideias apareçam ou que tenhamos dúvidas de como guiar um projeto para uma direção ou outra. É nesse âmbito que a política aparece. Saber mostrar seu ponto de vista é crucial, mas saber além disso conseguir convencer as pessoas de que seu ponto de vista é o mais importante para o momento é uma habilidade ímpar que fazem muitos juniors alavancarem suas carreiras rapidamente. Cada decisão tomada pelo grupo é uma direção na qual o software e por conseguinte o projeto irão. O preço é pago por todos, assim como a glória também vem para o grupo. Não importa se você foi o que mais se esforçou, se o projeto falhar, o grupo falha e por isso ter a noção de como conseguir esse capital político para ganhar força nas decisões é tão vital.

Muitas vezes teremos ideias que são as corretas para o momento, mas elas não serão ouvidas ou acatadas imediatamente. De fato, isso frusta, porém o grande desafio mora exatamente em como mostrar seu ponto de vista. Nem sempre de início você conseguirá mostrar a todos sua ideia da forma que você quer, ou outras pessoas olharão, mas não conseguirão dar a mesma importância que você deu para ela. Entender isso faz parte do processo. Entretanto existem jeitos de facilitar esse processo e aqui vão algumas dicas:

Construa amizades no seu dia a dia.
Seja objetivo nas suas argumentações.
Crie materiais visuais das suas ideias (diagramas, desenhos, o que for).
Saiba o momento certo de atacar.

Dessas quatro dicas talvez a quarta seja a mais complicada de executar, isso exige um pouco de feeling e com o tempo você conseguirá desenvolver isso. Tente sempre buscar a melhor hora, durante um refinamento, um 1:1 com seu líder técnico, existem momentos em que é uma boa hora para expor suas ideias com mais tranquilidade e ver como será a reação das pessoas. Se não for de primeira, reveja as quatro dicas e volte a tentar.

2. Você responde a alguém.

Bom, a menos que você seja o CTO ou CEO, essa dica servirá para você. Normalmente temos que responder a alguma pessoa na nossa organização, seja nosso líder técnico, nosso coordenador, gerente, diretor, o que seja. Quanto mais alto estamos na hierarquia da empresa, maior nosso contato será com os diretores e até com os executivos e nessas horas construir capital político é mais do que necessário.

Diagrama de organização de time de engenharia, por Alisson Lynch

Seja conciso nas suas ideias, busque oportunidades e principalmente busque ajudar nas dores deles para que você ganhe capital social e com isso possa convertê-lo em capital político, tendo apoio nas suas ideias e/ou decisões. Vê algum time que está com um problema complexo do qual você já resolveu alguma vez? Se proponha a ajudar! O prazo está apertado para a equipe? Veja onde a equipe pode ganhar tempo e proponha planos de ação. Consegue visualizar alguma oportunidade de crescimento para o negócio? Converse com seu gestor sobre.

Lembre-se, de uma forma ou outra você responde a alguém e ele deve ser a primeira pessoa que você deseja ter uma grande quantidade de capital político. Alinhe suas ideias com a do seu gestor, entenda a direção que ele quer seguir e veja como pode agregar boas ideias para isso, o processo se tornará muito mais feliz se você buscar aliados e não inimigos.

3. Escolha as lutas que deseja lutar

Esse talvez seja o conselho mais importante desse post. Durante nosso trabalho veremos muitos fluxos que podem ser melhorados, seja dentro da nossa própria área ou não. Porém entenda que não é por ver melhoria em todos que devemos sair propondo mudanças em todos. A cada mudança que você propõe, você está escolhendo uma luta, está gastando seu capital político, e há brigas que simplesmente não valem a pena naquele momento.

Veja, não estou querendo dizer que você deve simplesmente fazer nada se notar uma possibilidade de melhoria. Mas sim que existem momentos diferentes, momentos em que seu capital político estará maior e será mais fácil para você dialogar e outros momentos em que sua ideia será simplesmente ignorada pela falta desse capital. Algumas dessas brigas causarão atrito entre sua área e outras e com isso você irá erodir seu capital ainda mais, tome cuidado!

Por isso, escolha bem em quais lutas gastar seu capital político e como você irá chamar essas lutas.

4. Grupos distintos, capital político distinto.

Normalmente em grandes organizações é comum que tenhamos que conversas com áreas distintas e em muitas exista uma certa cultura de “silos”, grupos que fecham-se em si mesmo e acabam não dialogando com as outras áreas e tornando-se alheias com as dores das outras áreas. Isso é ruim quando necessitamos pedir alguma requisição por exemplo e estamos com uma sensação de urgência muito maior do que a outra área sente. Isso reflete exatamente nosso capital político. Para poder provocar essa sensação na outra área temos que ter capital para gastar, precisamos fazer com que principalmente os líderes daquela área simpatizem-se com nossa demanda e urgência.

Isso nos leva a outra reflexão, em grupos distintos teremos capital político distinto, pode ser que na área A sejamos super bem vistos e nossas demandas recebam a priorização que desejamos, porém pode ser que na área B não seremos priorizados e tenhamos que ter algumas reuniões até que a real urgência seja exposta.
Por isso, volto na dica que dei anteriormente: Construa amizades, busque ajudar e faça aliados, não inimigos.

5. Conclusão

No todo esses conselhos podem parecer até óbvios, todavia muitos nãos os aplicam. Muitos devs podem ser talentosos tecnicamente, mas carecem nessa parte e se frustram ao não entender porque suas ideias não tem tanto impacto ou porque sua promoção demora muito a sair, talvez essa seja uma possível resposta.

Como realizar um bom troubleshooting ?

Bruno Rezende Novais — Sun, 22 Jan 2023 21:47:11 +0000

Bom, atualmente muito de nós engenheiros de software (em especial os mais iniciantes) preocupam-se com a tecnologia X ou Y a ser usada, qual provedor cloud usar ou qual design pattern devo usar nesse código. Mas, antes dessas perguntas, é extremamente necessário que todo engenheiro treine uma habilidade básica, inerente a própria engenharia: a habilidade de quebrar problemas e solucioná-los, em outras palavras, como realizar um bom troubleshooting?

Ao se esquecer dessa parte primordial, muitos engenheiros irão simplesmente navegar no mar da dúvida sem atacar o problema real. Tal como um médico que receita remédios ao seu paciente sem procurar a causa-raiz, um engenheiro de software sem compreender o problema real apenas nadará no mar de incertezas, muitas vezes aumentando o custo do projeto, sem saber exatamente se solucionou de fato ou não a dor.

Para isso, a mentalidade por trás dessa solução e investigação deve ser completamente analítica: paramos o “sangramento”, investigamos e por fim completamos o ciclo corrigindo o problema. Mas para isso, é necessário não só experiência e muitas vezes técnicas, as quais com o tempo se tornarão naturais no dia a dia. Sobre isso, falarei um pouco mais sobre as técnicas logo abaixo, onde dividirei esse artigo em cada parte do ciclo de solução.

Sumário

Parar o sangramento
Investigação
Correção
Conclusão

Parar o sangramento

Por mais que seja tentador falar que a correção do problema seja a fase mais importante, as vezes interromper imediatamente o efeito direto ou colateral causado por uma falha, na maioria das vezes, é a melhor saída inicial. Se você trabalha em algum sistema financeiro, sabe que uma falha pode custar muito, muito dinheiro. Quanto mais cedo parar o sangramento, mais feliz os stakeholders ficarão. Para isso, você pode utilizar o acrônimo O.Q.C:

O que mudou?
Quando mudou?
Como mudou?

Fazendo essas três perguntas, você conseguirá ter uma visão mais imediata do que mudou no seu sistema, seja um fator interno ou externo, e assim reverter essa situação ou contorná-la, diminuindo o impacto nos seus clientes.

Logs de aplicação, traces, change orders e documentações são sempre bem-vindos nessa hora, mas entenda que apenas ter essas informações não mudará muito, é necessário adicionar na fórmula a sua análise do problema.

Investigação

Essa fase é quando a primeira tempestade acabou, agora é hora de analisar o problema mais profundamente, procure reler o que aconteceu no incidente para relembrar de alguns detalhes e assim parta para a investigação. Nessa etapa, podemos ter algumas ferramentas que podem nos ajudar: reprodução e isolamento.

Se seu sistema permitir a capacidade de reprodução daquele cenário, ótimo, utilize-a exaustivamente. Tente reproduzir o máximo possível da condição daquele incidente, suba a aplicação localmente, coloque os mesmos dados de entrada e através dos breakpoints na sua IDE observe passo a passo da aplicação até chegar no erro esperado. Essa é uma técnica muito poderosa, mas que infelizmente muitos programadores não a utilizam frequentemente, seja por não conseguir simular completamente as condições (por questões de uma má arquitetura ou falta de ferramentas) ou por simplesmente desconhecerem sua utilização.

Outra possível técnica é isolar o problema. Comece pensando no seu sistema de fora para dentro. Será que foi alguma integração externa que causou isso? Alguma dependência de outro sistema? Será que foi algum tratamento de dado que falhou, alguma regra não prevista ou entrada de dado não prevista? Será que foi alguma comunicação entre os serviços que falhou? Será que o próprio serviço falhou?

Repare que nessa linha estamos sempre questionando nosso sistema de fora para dentro, avaliando se o ofensor é externo ou se de fato é interno. Se o sistema foi bem testado, a chance de ser um ofensor externo é grande, porém essa etapa também é importante para elucidarmos se o nosso sistema foi bem testado ou não.

Nos momentos em que percebemos que o ofensor é externo, sempre se lembre disso: não busque culpados, busque causas. Não é interessante para você ou para sua empresa que ao localizar que a falha veio por um sistema de outro setor que falhou, saia apontando o dedo em direção ao outro departamento. Não faça isso. Ao contrário, busque mostrar aos seus colegas a causa daquela falha no seu sistema e como eles podem fazer para ajustar. Será uma conversa muito mais proveitosa para ambos.

Correção

A fase final do ciclo na solução de um problema. É quando ao já termos parado o sangramento e investigarmos, procurarmos uma força de corrigir aquele problema já sabendo sua causa raiz, procure solucionar o problema não apenas para “tapar o buraco”, mas sim para entender como melhorar o código ou como evitar que isso ocorra novamente.

Após feito, teste o sistema exaustivamente, afinal nem você nem seus clientes querem que isso volte a ocorrer, implemente a correção e não esqueça de documentar o que foi feito. Assim você ou outros colegas no futuro saberão o que causou e como foi resolvido, se um problema similar aparecer, já terão um bom norte.

Conclusão

Resolver problemas não é fácil, mas é uma habilidade crucial de todo engenheiro. Se você se vê como um engenheiro de software ou deseja se tornar, talvez essa seja a melhor aptidão para masterizar. A linguagem X ou Y, os detalhes da tecnologia e arquiteturais, tudo isso é importante, mas tudo isso são ferramentas, e se você não souber qual é o problema a ser resolvido, de nada adianta ter o melhor martelo. Não adianta ter as melhores tintas e pincéis, se você sequer tem ideia do que quer pintar.

Inclusive, se você já pensou um pouco sobre o problema do excesso de engenharia (overengineering) dê uma lida neste artigo.

The price of Overengineering

Bruno Rezende Novais — Sat, 21 May 2022 17:42:03 +0000

Hello everyone, in this article I will talk about over engineering and the price it costs to any project, plus I’ll discuss about identifying and how to avoid doing it.

On first, let’s simply define the term over-engineering as the act of providing or creating a solution to a problem that other more simpler solutions could solve the problem with the same effectives and manner. In other words, means that when you design a new system or implement some new technology without thinking of the costs and trade-off or just using it by the hype, you’re doing over-engineering.

But, what’s the problem with that? Isn’t using the new hype technologies or adopting Big Tech solutions the right way to solve software problems? Well, knowing new technologies is really a thing with us engineers, when we see an elegant solution or a breaking ground framework, we almost want to adopt it and experiment in many ways. Doing that in personal problems or proves of concept is quite okay, the real problem becomes when you adopt it as the definite solve for any situations at the work.

Software Engineering, in any step of the chain, since design the idea or codding, costs money, a lot of money to be honest. Most of us reads Netflix’s, Amazon, or any of the FAANG tech articles and then the eyes sparkles and the first thought is “Well, let’s apply that to our company, so our product will grow up jut like theirs”. In most cases, that think will lead to project failures.

Every company and any project have their financial state, technological state, and team moment. Everyone is different and has their own peculiarities. So, applying those new technologies just for experiment can turn projects into truly chaos. You need to think that any solutions come with a cost called TCO – Total Cost of Ownership, which means that you’ll pay not only for the development teams, but for maintenance, training, and license if there’s any. The sum of all costs resolves into the TCO. All over the time, the first developers that worked on this innovation can leave or be in other projects, so you’ll have to pay more and more in TCO. The Overengineering price is when you are in this snowball situation.

To be honest, I think that every software engineer will commit that in one moment of its career, so the true question is: how to avoid?

In this diagram I try to bring you all a flow diagram chart that I hope it helps you and your team to identify when the time is to implement innovations or use an cheaper and already tested solution.

Talking more about each step, in the first decision it’s the moment where you have a engineering problem and you should start to search for solutions for similar or same problems. When you reached it, you’ll think about the company moment, and when I say about company moment, means either the technical, cultural, and financial moment. Maybe that solution you found is a good one, but the teams are not technically ready yet, or the cost of maintaining in a cloud provider would cost too much.

Looking at the left-side of the chart we have that iteration flow, we look for a solution, look if matches the company moment and if no restart the search. On the right side, we have the innovation ground. When, and only when, there’s no solution for similar problems, your team have a good technical background and your company is in a good moment, then you can bring new or bigger solutions to the table. And if you did not find any solution and if is too risky to your team leads with the new challenge. Then you need to step back and rediscuss the project, probably breaking it into minor parts and more projects.

So, if you or any team member try to skip some steps of this flow, it will certainly cost your over-engineering.

Of course, this flow isn’t the silver-bullet for all process, but it should help you to think about the engineering and fit it to your costumers demands.

Hope you liked it! And even about software engineering costs, or IT costs, how about reading this article about the most expensive part in software development ?

What is the most expensive part in software development?

Bruno Rezende Novais — Wed, 04 May 2022 00:49:16 +0000

Well, a few days ago a developer colleague asked on Twitter: “how to reduce costs in software development process?”, this question made me think about all the steps in producing a software and making him available to the customer. After thinking about it a while I came to the following response: “the best way should be doing a great requirement engineering process” and now I will show to all you readers what made me answer that.

On first, what is Requirement Engineering?

Nowadays the Agile Movement take a great space into software development culture, with its many advances in delivering high quality software with time-to-market asked in the customer segment. But, as Fred Brook precisely said in The Mythical Man-Month: “There is no silver-bullet in software engineering”. Exactly as he said, Agile culture is a great advance in this engineering but with its gain comes the price, many software engineers visioning the agility and time-to-market pressure takes the requirement engineering process to a second order. What a big mistake!

According to Ian Sommervile, in his Software Engineering book, this process is defined as : “the first stage to be done in the software engineering process”. In fact, this step is done mostly in Scrum or Kaban with the term “technical refinement”, but many just skip the step “functional refinement” because thinks it a step only to satisfy stakeholders thoughts, and here lives one of the big mistakes in software development. Well, we can refine technically the most as we can, but if it doesn’t satisfy stakeholders it won’t serve. So as the opposite works, if stakeholders think a big project, in many cases it will just be unfit for just one project and should be break into two or more. In any cases, the fault of a well-done functional refinement will lead into a more expensive process, the technical refinement will take more time than expected and result in more doubtful requirements that obligates the team to stop and revisit it in the future.

By its time, a confusing and bad-done technical refinement will take to a bad software modeling and a not efficient architecture, summing it together we have the recipe to more costs into developing process and as consequence the software will probably have a larger memory consuming than it should, what in a Cloud Computing perspective means more money wasted.

In my words I usually say: “Requirement engineering process is the fundamental to spend less money in software engineering”.

So, what would I do to do better in it?

To be honest, there is no cake recipe, every company, every department, every squad has its own differences and dynamic. But you should take the following advice with you: Do not fear in taking a considerable time in this process. See, many projects that I participated focused it’s time in codding. I should suggest you the following as an experiment: invert it. Focus many part of it in refining and mapping requirements, negotiates it with the stakeholder and in the end you will write less code and the stakeholders will spent less money too. Happy ending !

Jokes apart, we know that stakeholder’s pressure are a real pain in many cases, so if you need to do daily reports, I should suggest you spent about 30% of the project time in this step. Define with clarity and objectively the non-functional and functional requirements, the business rules too, and attaches them to its following history, you should spend like one week to one refine one-two history and discover all its requirements and demands.

As you do the refinement, produces in parallel artifacts and documents about it, UML diagrams, requirement documents ( do not bind yourself in the waterfall model, create a template that should take only the essential about the requirements), record meetings and then in the final produce a final report that should map the UI with the followings requirements, talk to the other necessary areas and then do a final meeting, after that you are clear to code.

Taking those steps in mind, developers will not only have less stress than more money will be saved and the success project chances will increase considerably.

Thank you!

Thinking about software engineering, have you already asked yourself: “Why should I still care about doing a colleague”? Check this article !

Why should we still carry about doing a college?

Bruno Rezende Novais — Wed, 23 Mar 2022 00:24:24 +0000

Nowadays we are surrounded by tons of practitioner courses and masterclass about the mainstream framework or programming language. In this way, many of my colleagues at work and myself included have been questioning about the necessity of doing a college to ingress at Software Engineering area.

In this text, I want to share my humble opinion about that, but a little disclaimer before: this is my personal opinion. It’s not an absolute truth neither a rule. I will share with you, my reader, my point of view based on what I saw and studied along my programming journey.

On first place, why we should do a college?

Despite humanity had an enormous advance in technology along the last millennium, we still bet on a classic model of teaching and learning. Classes with hundred of students, dozens of works to do, years of studding, established curriculum and other things that we are used to.

Of course, many colleges had been tried to implement new models and breakthrough this classic teaching-learning paradigm. Yet, many people still have the thinking of college be a requisite for working at your area.

Well, talking only about tech area we have a kinda of certain. You don’t need to do a full college to work at it. At least if you only want to do the minimum. Today many frameworks are already really abstracted. I will take for example Java Spring. If you want to do a simple CRUD to attending an e-commerce requirement, probably the deep implementation of algorithms or data structures behind that framework will pass unnoticed. And there’s no problem into that, you only want to build a simple CRUD for an e-commerce website.

But, if you want to advance to other critical scenarios like financial transactions, health software’s, or problems where you error percentage need to be minor as possible then the practice knowledge of using a framework will not serve. In those cases, learning the fundamentals of computing like those I wrote before is essential. Efficiency of a software, space & time cost of an algorithm, which data structure is better in your case, what architecture is better, how to ensure that the required software will be delivered to the client respecting costs and market time. A masterclass will not teach you all of that.

So what’s the true advantage in doing a college?

When we talk about software engineering, we’re talking more than just lines of code and what stack use. The thinking needs to be with the premise: How this decision will help to deliver my costumer desire more quickly, safety and efficiently? To discern about it, you need to learn more than the fundamentals, need to have a least of experience that a college can provide to you with works or arguing with you colleagues.

Data Structures video by Willian Fiset

In resume, if you want to explore new steps into your programming career, in certain time you’ll need to learn more than the day-a-day knowledge. Breakthrough needs that you know deeply the frameworks and what’s behind it.

If you want to end in the basic, that’s okay, there’s nothing wrong with that too, but to lead the innovation, maybe you will need to step back and learn those simple, but yet complex things.