terça-feira, 30 de abril de 2019

Quem usa código livre deveria contribuir com código livre


Você ou sua empresa usa código livre?

 

A cada dia mais empresas estão adotando software livre em sua infraestrutura. Linux em servidores e workstations, Gnome, Cinnamon, Jenkins,  Blender, Apache, NginX, PostgreSQL, Tomcat, Docker,  Kubernetes, Eclipse, entre muitos outros, fazem parte do dia-a-dia de muita gente.  Servem de base para muitos produtos que garantem faturamento e pagam muitos salários.

Todos esses softwares são desenvolvidos de forma livre, seus códigos-fonte estão disponíveis ao público, bem como as instruções de como compilar e debugar.

Além do código-fonte, fóruns, wikis e chats são acessíveis, bastando, no máximo, um e-mail para publicar. Geralmente as comunidades são muito receptivas, desde que você entenda onde você está primeiramente (perguntas em listas erradas ou que tem resposta amplamente disponíveis geralmente causam reações menos receptivas).

Por fim, sistemas de issue tracking estão disponíveis para a maior parte dos projetos, e quando não tem, as listas de e-mail fazem esse papel. Tudo isso para permitir que a comunidade, que faz uso desses softwares possa se comunicar e contribuir.

Mas porquê contribuir?

 

Todo trabalho humano tem um custo. Alguém dispendeu algum tempo para executá-lo. Quando há uma relação de trabalho, o custo desse tempo está definido no contrato, que ambas as partes acordaram.

Para desenvolver código também há trabalho envolvido, como as empresas de software bem sabem. E esse trabalho não é pouco, por valor agregado (como as empresas também sabem). Logo, se para desenvolvermos software comercial cobramos somas vultosas, quem paga pelo desenvolvimento do software "gratuito" que usamos? 

Pois é, quem paga por isso são os próprios desenvolvedores, que investem seu tempo livre, férias, período "entre empregos", para desenvolver algumas funcionalidades. 

Obviamente, como em todo projeto, o ânimo de começar é sempre maior. Mas e bug fixing? E refatoracões para adicionar funcionalidades que o autor nem conhece tão bem? E aquele ajuste de CSS para melhorar o layout? 

Nem sempre o autor tem tempo de retomar o projeto. Mudanças na vida pessoal sempre acontecem, a faculdade acaba, surge um emprego, casamos. Manter software custa caro e dá trabalho. Mas mesmo assim, muitos tem lucro com esse software e acabam reclamando da defasagem, dos bugs, dos workarounds necessários para usá-lo.

Todo desenvolvedor, empresa, ou simplesmente usuários de software livre, deveria tentar colaborar com a comunidade. Quem sabe programar, deveria estudar o código-fonte de algum projeto. Quando notar um bug, mesmo se não for programador, verifique se há uma issue aberta. Se houver , vote nela, inclua detalhes do ambiente onde o bug foi reproduzido, adicione casos de uso. Se não existir, crie uma. Tente achar uma correção, discuta com outros desenvolvedores sobre o problema ou a solução. Isso ajuda a melhorar sua técnica de programação, de análise e até a treinar o inglês.

As empresas de software podem incorporar tickets de bugs ou features em seus backlogs, ou estimular os desenvolvedores a colaborar com algum projeto. Caso não queiram colaborar ou não sejam empresas de software, podem fazer doações financeiras, únicas ou periódicas, para esses projetos. É possível até mesmo mandar uma mensagem junto com a doação pedindo alguma atenção especial para uma necessidade da empresa. As fundações que gerenciam alguns desses softwares fazem muito bom uso desses recursos. 

O software livre mudou a forma como vivemos hoje. Mas ele corre riscos a cada dia. Sempre existe pressão por parte de grandes empresas de monopolizar o seu desenvolvimento, de torná-lo menos relevante, ou simplesmente, torná-los uma versão freeware de seus próprios sistemas. 

Se você quer evitar ficar preso às grandes empresas de software, apoie o software livre de qualquer forma que puder.

sábado, 13 de abril de 2019

Aprenda mais linguagens de programação, mesmo que você não vá usar


Imagine que você tem uma tarefa para realizar, e é livre para escolher a linguagem de programação. A tarefa envolve diversos tipos de manipulação de texto: leitura, segmentação, recortes, concatenação e execução de expressões regulares, tudo em UTF-8 e, certamente, precisa suportar emojis. Qual linguagem você escolheria? C? Por favor, não.

Outra atividade, agora numa instituição financeira. Precisamos fazer dezenas de milhares de operações financeiras de forma concorrente. Alta performance é um requisito fundamental. Deveríamos usar… Ruby? Qual é. Próxima: um script para ser usado apenas uma vez que renomeia diversos arquivos… Escrito em Java? Num browser … em Python? Programando um controlador para um dispositivo médico com… C#? Swift? Lua? Acho que você entendeu.

Diferentes linguagens de programação são boas em coisas diferentes, e ruins em outras. Cada uma faz certas coisas ficarem fáceis e outras mais difíceis. Dependendo do que nós queremos fazer podemos economizar muito trabalho escolhendo a linguagem que resolve o tipo de trabalho que enfrentamos mais facilmente.

Esse é um dos benefícios tangíveis de aprender mais linguagens. Você adiciona outra ferramenta ao seu repertório e quando surge a oportunidade, pode escolher a melhor opção. Mas eu quero ir um pouco mais à fundo.

Eu acredito que haja um enorme valor em aprender novas linguagens de programação mesmo caso — e lá vem — você nunca as use!

Linguagens modelam a forma como pensamos, cada uma de uma forma peculiar. E isso é verdade para linguagens de programação também. Cada linguagem possui um modelo mental diferente, uma perspectiva diferente para pensar sobre computação e como escrever programas.

Pegue SQL, por exemplo, e como ele modela sua ideia sobre o fluxo e a forma dos dados em seu programa. Agora considere como isso ficaria com uma linguagem imperativa, orientada a objetos como Java, ou uma linguagem funcional como Haskell. Ou em C. Imagine como seria um servidor de jogos multi-player em Python, em Haskell, em Erlang; Fazer streaming e processar terabytes de dados em C, em Go, em Clojure; uma interface de usuário em Tcl, em Lua, em JavaScript.

Toda linguagem de programação é uma lente através da qual podemos ver o problema que estamos tentando resolver. Através de algumas delas o problema parece complexo, exaustivo. Através de outras ele nem parece um problema, parece apenas diferente de outras coisas comuns que se faz nessa linguagem.

Aprendendo uma nova linguagem, mesmo que ela fique na sua caixa de ferramentas por toda a eternidade, você ganha uma nova perspectiva e uma forma diferente de pensar sobre os problemas. Uma vez que você implementou um servidor de jogos em Erlang, você verá servidores de jogos sob uma nova perspectiva. Depois de ter processado dados em Lisp, pensando nos dados como series de listas que podem ser moldadas enviando-as por diversas pequenas funções que podem ser compostas para formar pipelines de funções, você observará sombras desse padrão aparecer em todos os lugares. Assim que você tiver experimentado o gosto de gerenciar memória em C, você começará a apreciar o que Python, Ruby e Go fazem por você — enquanto nota o custo desse trabalho. E se um dia fizer uma interface de usuário em JavaScript com React.js, você notará que está pensando sobre componentes de UI de uma forma completamente diferente.

Essas novas perspectivas, essas ideias e padrões — elas perduram, elas ficam com você, mesmo que você acabe usando outra linguagem. E isso é poderoso o suficiente para te manter aprendendo novas linguagens, porquê uma das melhores coisas que podem acontecer com você, quando está tentando resolver um problema, é uma mudança de perspectiva.

Original disponível em https://thorstenball.com/blog/2019/04/09/learn-more-programming-languages/

segunda-feira, 7 de outubro de 2013

Alterando o browser padrão no Ubuntu (e similares)

Toda vez que reinstalo uma máquina, tenho que lembrar como alterar as configurações do browser padrão e, toda vez tenho que fazer a mesma busca para lembrar. Então, a título de arquivo e para ajudar quem tem o mesmo problema, ai vão as instruções:

Supondo que o browser que você deseje instalar seja o Chromium, e que ele esteja em /opt/chromium/chromium,  em um terminal digite:

#sudo update-alternatives --set x-www-browser /opt/chromium/chromium
#sudo update-alternatives --set gnome-www-browser /opt/chromium/chromium
#xdg-settings set default-web-browser chromium.desktop

Para o último comando, você deve ter criado uma entrada no menu para o Chromium (usando o alacarte ou um editor de textos).

sexta-feira, 28 de junho de 2013

Engenharia reversa no Arduino (2ª parte)

Outro dia eu postei como ler o conteúdo de um arquivo .hex compilado pelo Arduino IDE. Neste post vou mostrar como fazer o dump da memória do AVR de forma que possamos analisar seu conteúdo e descompilar as seções relacionadas ao programa.

domingo, 23 de junho de 2013

Estabilizando a imagem de um vídeo no Ubuntu

Hoje, após realizar uma pequena filmagem com o meu celular e constatar que a imagem ficou bastante tremida, resolvi procurar uma forma de estabilizar a imagem de forma automática e simples. Vou passar os passos que eu segui para conseguir um resultado bastante satisfatório.

O software utilizado para realizar essa tarefa foi o MELT, que possui um filtro muito bom para obter a informação sobre o deslocamento da imagem entre os frames chamado videostab2.

Para realizar essa tarefa, eu segui um tutorial muito bom, escrito por Nicolas Bernaerts, e fiz alguns ajustes.

As ferramentas necessárias são o FFmpeg 0.9+ e o MELT 0.7.6+. Para testar a versão atual (se estiverem instalados) use:
# ffmpeg -version
# melt -version

Caso não tenha algum desses software instalado ou se a versão disponível form menor que a esperada, utilize os seguintes comandos para instalar/atualizar:
# sudo add-apt-repository ppa:jon-severinsson/ffmpeg
# sudo apt-get update


Caso já tenha o ffmpeg instalado use:
# sudo apt-get upgrade

Caso não tenha, use:
# sudo apt-get install ffmpeg

Para o MELT, use:
# sudo add-apt-repository ppa:sunab/kdenlive-release
# sudo apt-get update


Caso já tenha o MELT instalado use:
# sudo apt-get upgrade

Caso não tenha, use:

# sudo apt-get install melt

Agora, com as ferramentas necessárias instaladas, vamos para o processo de estabilização do vídeo.

Este processo é dividido em duas etapas. A primeira etapa consiste na verificação do vídeo pelo filtro videostab2 que vai calcular o deslocamento dos quados e gerar um arquivo de configuração que será usado na segunda etapa, que desloca o vídeo para estabilizar a imagem final.

Para a primeira etapa utilizamos o seguinte comando:

# melt "${ORIGINAL}" -filter videostab2 "shakiness=4" -consumer xml:vectors.xml all=1 real_time=-1

Onde $ORIGINAL é o caminho para o video que será estabilizado.

Depois desse passo, será produzido um arquivo (nesse caso vectors.xml) que conterá os vetores de deslocamento.

Para o segundo passo utilizamos o seguinte comando:
# melt vectors.xml -audio-track "${ORIGINAL}" -consumer avformat:"${FILE_STAB}" vcodec=libx264 b=5000k acodec=libmp3lame ab=128k "tune=film preset=slow"

Esse comando vai gerar o arquivo $FILE_STAB, com o áudio original do arquivo $ORIGINAL. A saída será um vídeo h264 a 5Mbits com áudio AAC de 128Kbits.

Script para o Nautilus

Para quem usa o Gnome2, transformar esse tipo de operação em um script que pode ser utilizado pelo menu de contexto no Nautilus é uma excelente opção.

O autor do artigo original criou um script excelente, e eu quero ter a oportunidade de compartilhá-lo e fazer algumas observações.

Para instalá-lo, copie o texto para um arquivo em ~/.gnome2/nautilus-scripts/StabilizeVideo (o nome fica a seu critério) e dê permissão de execução (# chmod u+x ~/.gnome2/nautilus-scripts/StabilizeVideo).

#!/bin/sh
# --------------------------------------------
#  Video Shooting Stabilization
#  Command-line & Nautilus script
#  Depends on :
#   * mlt 0.7.6 minimum
#   * ffmpeg 0.9 minimum
#   * yad
#  Revision history :
#  04/03/2012 - Creation by N. Bernaerts
#  04/04/2012 - Add codecs as parameters
# -------------------------------------------

# ----------------------------------------------------
#  User variable section
#  Please, do not modify anything out of this section
# ----------------------------------------------------

# You can define default encoding codec and rates in kbits/s
VIDEO_CODEC="libx264"
VIDEO_RATE=5000
AUDIO_CODEC="libmp3lame"
AUDIO_RATE=128

# You can setup optional parameters for stabilization & h264 encoding
OPTION_STABILIZER="shakiness=4"
OPTION_ENCODER="tune=film preset=slow"

# ------------------------------------
#  check if script is called
#  as command-line or nautilus-script
# ------------------------------------
if [ -n "$1" ]
then
  # at least one parameter, called as command-line
  FILE_PATH="$1"
else
  # no parameter, called as a nautilus script
  FILE_PATH="${NAUTILUS_SCRIPT_SELECTED_FILE_PATHS}"
fi

# ----------------
#  Initialisation
# ----------------
STABILIZE="TRUE"
CANCELED="FALSE"

# go in the video file directory
cd $(dirname "${FILE_PATH}")

# generate the filenames
ORIGINAL=$(basename "${FILE_PATH}")
FILE_NAME=`echo ${ORIGINAL} | sed 's/^\(.*\)[.].*$/\1/g'`
FILE_STAB="${FILE_NAME}"-stab.mp4
FILE_LOG="${FILE_NAME}".log
FILE_MLT="${FILE_NAME}".mlt

echo "---" > "${FILE_LOG}"

# --------------------------------------------
#  function to follow progress of the process
# --------------------------------------------
MELT_PROGRESS()
{
# loop till the end of melt process
PERCENTAGE=0
while [ "$PERCENTAGE" != "100" ]
do   
  # wait for 1 second
  sleep 1

  # if process is still running
  RESULT=`ps aux | awk '{print $2}' | grep "$PID"`
  if [ "$RESULT" -eq "$PID" ]
  then
    # get percentage of completion
    PERCENTAGE=`cat "${FILE_LOG}" | tail -n 1 | sed 's/^.*percentage:[ ]*\([0-9]*\).*$/\1/g'`
  else
    # else, force percentage to 100
    PERCENTAGE="100"
  fi

  # display current percentage
  echo $PERCENTAGE
done | yad --width=400 --height=30 --progress --auto-close --title "$TITLE" --text "$TEXT"

# if encode has been canceled, kill the current process
CANCELED="FALSE"
RESULT=`ps aux | awk '{print $2 }' | grep $PID`
if [ "$RESULT" -eq "$PID" ]
then
  kill $PID
  CANCELED="TRUE"
fi
}

# -----------------------------------
#  Selection of encoding parameters
# -----------------------------------
TITLE="Stabilization of ${ORIGINAL}"
TEXT="\nFinal video file will use $VIDEO_CODEC video and $AUDIO_CODEC audio.\nPlease select the encoding parameters :\n"
CHOICE=`yad  --title "$TITLE" --text "$TEXT" --image "dialog-question" --form --field=Stabilize:CHK ${STABILIZE} --field="Video bitrate (kbits):NUM" ${VIDEO_RATE} --field="Audio bitrate (kbits):NUM" ${AUDIO_RATE}`

# extract the parameters
STABILIZE=`echo ${CHOICE}  | cut -d"|" -f1`
VIDEO_RATE=`echo ${CHOICE} | cut -d"|" -f2 | cut -d"," -f1 | cut -d"." -f1`
AUDIO_RATE=`echo ${CHOICE} | cut -d"|" -f3 | cut -d"," -f1 | cut -d"." -f1`

# -------------------------
#  Phase 1 : Stabilization
# -------------------------
if [ "$STABILIZE" = "TRUE" ]
then
  # set text & title of progress window
  TITLE="1 - Stabilization of ${ORIGINAL}"
  TEXT="This phase may take a long time ...\n"

  # start the stabilization phase with melt and videostab2 filter
  melt -progress "${ORIGINAL}" -filter videostab2 ${OPTION_STABILIZER} -consumer xml:"${FILE_MLT}" all=1 real_time=-1 2>> "${FILE_LOG}" &

  # get the process id
  PID=`ps -ef | grep melt | grep "${ORIGINAL}" | sed 's/^'$USER'[ ]*\([0-9]*\).*$/\1/g'`

  # follow the stabilization progress
  MELT_PROGRESS
fi

# if canceled, no encoding to be done
if [ "$CANCELED" = "TRUE" ]
then
  VIDEO_RATE=0
fi

# --------------------
#  Phase 2 : Encoding
# --------------------
if [ "$VIDEO_RATE" -gt "0" ]
then
   # set text & title of progress window
  TITLE="2 - Encoding of ${FILE_STAB}"
  TEXT="This phase may also take a long time ...\n"

  # start melt encoding process with stabilized video and original audio
  melt -progress "${FILE_MLT}" -audio-track "${ORIGINAL}" -consumer avformat:"${FILE_STAB}" vcodec=${VIDEO_CODEC} b=${VIDEO_RATE}k acodec=${AUDIO_CODEC} ab=${AUDIO_RATE}k ${OPTION_ENCODER} 2>> "${FILE_LOG}" &

  # get the process id
  PID=`ps -ef | grep melt | grep "${FILE_MLT}" | sed 's/^'$USER'[ ]*\([0-9]*\).*$/\1/g'`

  # follow the stabilization progress
  MELT_PROGRESS
fi

# ------------------------------------
#  cleaning-up of all temporary files
# ------------------------------------
rm "${FILE_LOG}"
rm "${FILE_MLT}"

exit 0


Esse script utiliza uma ferramenta chamada yad que permite a criação de interfaces gráficas da mesma forma que o Zenity, mas com muito mais opções (possivelmente à custa de estabilidade).

Para instalar o yad no Ubuntu, utilize:
# sudo add-apt-repository ppa:webupd8team/y-ppa-manager
# sudo apt-get update
# sudo apt-get install yad


Observação

Caso você tenha problemas ao executar o segundo passo, recebendo a informação que os codecs não estão disponíveis, instale o pacote libavcodec-extra-53:
#sudo apt-get install libavcodec-extra-53

Referências

sexta-feira, 21 de junho de 2013

Engenharia reversa no Arduino

Procurando uma forma de entender melhor o funcionamento do meu Arduino, procurei saber como fazer a engenharia reversa do código que está sendo enviado para ele. Espero tentar repassar o que eu consegui descobrir para vocês.