Código-fonte de um game completo!

Está completando 5 anos que publiquei este livro, Manual do Indie Game Developer. Agora, estou escrevendo a versão 3D dele. Mas vou te dar um presente: Vou disponibilizar o código-fonte completo de um game real, baseado nos ensinamentos deste livro, que está na Google Play há 5 anos! https://play.google.com/store/apps/details?id=com.obomprogramador.games.byball&hl=pt_BR

Novo livro: Game 3D com Unity e redes neurais

Um presente de ano novo para você: Meu novo livro, continuação do Manual do Indie Game Developer, agora com versão 3D! E com IA baseada em Deep Learning! Aprenda a criar jogos de nova geração, usando um dos melhores game engines do mercado! Em breve!

Plotando gráficos com R

Quer aprender a plotar gráficos com a linguagem R? É fácil criar visualizações bonitas e funcionais, para você arrasar naquela reunião chata! Vamos lá! Rasgue estes postits! Aprenda algo útil para seu futuro! CLIQUE AQUI.

Cuidados com sua vida digital

Hoje, foi noticiado amplamente a descoberta de um banco de dados na web profunda, contendo mais de 1,4 bilhão de logins, senhas e emails. 

Spark e R em 15 minutos

Tem um tempinho? Que tal aprender a usar Spark com a linguagem R?

R em 5 minutos!

Eu admito! Tinha uma certa aversão à linguagem R. Talvez fosse uma alergia, sei lá… Mas eu comecei a trabalhar com ela e obtive excelentes resultados, com pouco esforço. Como tenho visto algumas pessoas reclamarem muito sobre a dificuldade em criar um ambiente para executar análises usando R, decidi escrever este guia de 5 minutos para instalar um ambiente completo para usar R em trabalhos de data science.

Aguarde meu novo livro: “Data Science para Programadores - Um Guia Completo sobre Data Science usando Python”

Um guia completo sobre data science, utilizando a linguagem Python, contemplando desde inferência estatística até big data. Nele, você verá como realizar análises profissionais, sejam de aprendizado supervisionado ou não, com visualização prática e funcional.

O universo de data science hoje abrange diversas áreas, como: estatística, mineração de dados (data mining), inteligência de negócios (business intelligence), aprendizado de máquina (machine learning) e big data. 

Para prosperar em um ambiente em rápida transformação, como o nosso, é necessário conhecer e entender os dados, de maneira rápida e precisa. 

A proliferação de técnicas, ferramentas e algoritmos, torna o aprendizado complexo, mas este guia se propõe a introduzir o assunto com uma abordagem prática, utilizando a linguagem de programação Python e as principais bibliotecas de data science, como: Numpy, Pandas, Scikit-learn, Tensorflow e PySpark. 

Veremos os tópicos:

• Estatística básica, probabilidades e inferências;

• Introdução à linguagem Python e ao ambiente Jupyter;

• Storytelling com Notebooks Jupyter;

• Regressão linear, não linear e múltipla;

• Classificação e agrupamento (clustering);

• Algoritmos: árvore de decisão, K-Means e Support Vector Machines;

• Big data com Apache Spark;

• Machine learning com Tensorflow;

#datascience #book Meu novo livro sobre data science

Será um livro épico sobre data science, machine learning e deep learning, com Python, TensorFlow, Spark etc.
Haverá uma boa introdução de estatística, data mining e análise preditiva. Um curso de pós graduação completo em um único livro.
Você me conhece e sabe como os meus livros são!

Aguarde

Descutindo a relação com o Manifesto Ágil

Discutindo a relação com o Agile - Gran finale: Repensando os valores e princípios.


Se você chegou até aqui, ótimo! Tem interesse em discutir a questão dos "Métodos Ágeis". Então, vamos à conclusão. Se você não leu os outros dois artigos, seria interessante que o fizesse, de modo a ter contexto:

1) Discutindo a relação com o Agile 1: Lendo o Manifesto (https://www.linkedin.com/pulse/discutindo-relação-com-o-agile-1-lendo-manifesto-de-melo-junior)

2) Discutindo a relação com o Agile 2: Desconstruindo os princípios (https://www.linkedin.com/pulse/discutindo-relação-com-o-agile-2-desconstruindo-os-de-melo-junior)

Keep calm! E aguarde nosso tutorial de data science

E aí? Querendo impressionar o Chefe, fazendo "bonito" na reunião? Quer mostrar ao seu ou a sua "crush" que você é "Cientista de Dados"? Então não seja "mané" e evite agir como os otários que fizeram essas análises AQUI. Aguarde o nosso tutorial e viva feliz, como "pinto no lixo"! Ah, e é "di grátis", seu pão duro!

A guerra do Frontend não está decidida!

Por algum tempo, todos pensamos que a Guerra do Frontend, que estabeleceria o framework padrão para Web e Mobile, estaria decidida em favor do Angular (JS). A própria equipe do Angular acreditou nisso.
Porém, depois da desastrada transição para o Angular (2+), os desenvolvedores passaram a questionar a sabedoria de se "amarrar" em algo tão volátil e comprometedor. Então, outros frameworks ganharam vida, entre eles o EmberJS, menos ambicioso, porém muito interessante. Estamos preparando um tutorial sobre Ember e publicaremos em breve, mas, enquanto isso, leia o que o pessoal do Technology Radar tem a dizer: https://www.thoughtworks.com/pt/radar/languages-and-frameworks
Eles classificaram o AngularJS como "hold"! É claro que não falaram do Angular, a nova versão, porém, em linhas gerais, estão se referindo a ele. Por que investir em algo que está mudando tanto? A versão 4 saiu em Março de 2017, e a 5, sairá em Setembro, pegando todos os desenvolvedores "de calças arriadas"!
Veja o que o pessoal do Technology Radar fala sobre o Angular 2:
"In the previous Radar, we moved AngularJS into the Hold ring (where it remains in this edition). When it comes to Angular 2, we're seeing mixed messages. Over the past year some teams at ThoughtWorks have used Angular 2 successfully and consider it a solid choice. However, Angular 2 is a rewrite, not an evolution, of AngularJS, and switching from AngularJS to Angular 2 is not much different than switching from AngularJS to another framework. Given the, in our experience, superior contenders such as React.js, Ember.js and Vue.js, we're still hesitant to give Angular 2 a strong recommendation. We do want to highlight, though, that it is not a bad choice, especially if you bought into TypeScript."
É de se pensar, não?
Não seria melhor usar algo mais estável?
Conheça o Ember, o Redux, o React e forme sua opinião!
https://www.emberjs.com/

#agilesucks Processo vs pessoas

Todas as vezes que eu observei projetos "ágeis", vi problemas. Em todas as vezes que vi problemas, as pessoas envolvidas no trabalho braçal, acabam sempre sendo as culpadas. É meio óbvio esse comportamento dos "agilistas" em culpar a Equipe pelos problemas, afinal, quem trabalha, erra, quem trabaalha muito, erra muito, quem não trabalha, não erra, e, finalmente, quem não erra vira "agilista"!
Mas sério, vamos pensar um minutinho... eu já entrevistei alguns agilistas, sem que eles soubessem que estavam sendo entrevistados, e as respostas foram sempre muito coerentes entre si, como se todos fizessem parte de um "culto secreto". E a resposta é, quase com as mesmas palavras: A culpa é das pessoas, que são rresistentes às mudanças provocadas pelo "ágil".
Hum! Se um modo de trabalhat exige TAMANHA MUDANÇA nas pessoas, é por ser antinatural, certo? Provavelmente, as pessoas estão resistindo, por que o "ágil", mais especificamente o SKPP (Scrum+Kanban+PlanningPoker), deve ser muito diferente da maneira que estão acostumadas a trabalhar.
Então, por que não valorizar mais a maneira natural de trabalhar? Por que não valorizar mais as pessoas, como o próprio Manifesto Ágil propõe?
Será que SEGUIR UM PROCESSO virou mais importante do que OBTER RESULTADOS?

#agilesucks PlanningPoker

Planning Poker! Na minha opinião, nenhum profissional de informática deveria levar isso a sério! Essa, diga os assim, "técnica", surgiu para desempatar estimativas subjetivas, em times pequenos, coesos e muito experientes. Provavelmente, foi criada em uma mesa de bar... Bem poderia ser substituída, com maior eficácia, por dados!
Os "agilistas" a elegeram como base para suas "estimativas"! Por que? Porque é lúdica, totalmente subjetiva, e desprovida de fundamentação teórica.
Seu uso gera distorções, que, em vez de serem analisadas sob a ótica da Engenharia de Software, sofrem pressão por "consenso"!
Acho ridiculamente divertido observar tal OBSCENIDADE ser praticada, como se fosse sério... fico me segurando para não molhar as calças de tanto rir!

#agilesucks Scrum

Olhando superficialmente, o Scrum é um método realmente genial! Simples, lúdico e subjetivo o suficiente, para ser entendido em minutos! Qualquer um pode entender Scrum e se tornar um evangelista desta prática! E, de fato, ele funciona! Bem, desde que o Projeto, a Equipe e a Cuktura da Organização sejam adequadas. O problema é que o Scrum não apresenta bons resultados em todas as situações, e nem com todas as pessoas! Nem todos se sentem confortáveis com suas práticas, e são obrigados a conviver com aberrações, como as "daily meetings", em pé!
Se todos fossem feitos de Lego (c), talvez se adaptassem melhor.
Devido à sua antinatural desorganização, este método pode provocar diversos efeitos indesejáveis, que podem ser rápidamente notados: Nervosismo, Ansiedade e Heroísmo! Tudo o que os métodos ágeis deveriam combater.
E o pior de tudo: Seus defensores culpam as pessoas, alegando que é preciso mudar a cultura!
Então, eu pergunto... Se você precisa usar um método, que necessita mudar TANTO as pessoas, não seria mais fácil mudar de método? Não é isso o que o Manifesto Ágil prega? Deixe-me recordar...
"PASSAMOS A VALORIZAR: INDIVÍDUOS E INTERAÇÕES, MAIS DO QUE PROCESSOS E FERRAMENTAS"!
Tá escrito lá, não? Ou será que eu sou tão imbecil, que nem sei mais ler?

#agilesucks Kanban

Kanbans são muito lúdicos e "bonitinhos", dando a ilusão de que tudo vai bem. Para pequenas coisas, podem até servir, mas deixam de capturar e exibir questões fundamentais, como: disponibilidade de recursos, interdependência de tarefas e impedimentos.
Ok, essas coisas são discutidas nas "daily scrums"... tá... até parece que todos se lembram e se preocupam com tudo o que é dito nessas perdas de tempo.
Exitstem tentativas de tornar o Kanban mais objetivo e útil, e um bom exemplo disso é a ferramenta Redmine. Porém, os "agilistas" preferem os Kanbans de post-it, pois, por serem totalmente subjetivos, ajudam a ocultar o estado real das coisas.
Acorde!

Contra-indicações dos "Métodos ágeis"

Todo remédio tem uma bula, certo? E, nesta bula, há indicações, contraindicações e efeitos colaterais. Deveria ser assim para qualquer coisa, até mesmo para processos de desenvolvimento de software.
Os, assim chamados, "métodos ágeis" possuem contraindicações e efeitos colaterais muito graves, mas que são menosprezados pelas equipes, gestores e clientes de desenvolvimento de software.
Minha experiência, em vários cursos e projetos desenvolvidos, somente confirma essa convicção, que gostaria de compartilhar com vocês.

Agile still sucks!

Odeio constatar, mais uma vez, que estou certo!

Os, assim chamados, "métodos ágeis" não podem ser aplicados a todos os projetos e equipes. Não é assim que funciona!

Enquanto em alguns casos o Scrum, o Planning Poker e outras, digamos assim "técnicas", podem dar bons resultados, em outros, podem levar a um desastre total!

E o pior: O assunto é visto como DOGMA! Falar mal dos métodos ágeis é visto como HERESIA! Você será taxado de ignorante, inexperiente e será visto como incapaz de trabalhar em equipe.

Mas os problemas continuam a acontecer, então, os "agilistas" passam a culpar as pessoas, porém, jamais o PROCESSO!

Eu digo que o emprego de "métodos ágeis" deve ser repensado e limitado a aqueles Projetos e Equipes, para os quais, são mais adequados. Jamais indiscriminadamente!

Leia mais em: https://www.linkedin.com/pulse/gestão-de-projetos-morreu-viva-cleuton-sampaio-de-melo-junior

Correção de rumo do robô

Funcionando! Agora vou acrescentar uma Unidade de Medição Inercial (Bússola + Acelerômetro + Giroscópio) para manter a rota. Se ele estiver indo reto e se desviar, por alguma razão, será capaz de corrigir o rumo.

Robô pronto!

Hardware mintado! Robô completamente montado. Estou terminando o software. Ele é capaz de detectar obstáculos, medindo com precisão a distância e o ângulo de movimento em cada roda. Com isto, é capaz de resolver labirintos e criar mapas do trajeto, o que lhe permite "mapear" uma área e rodar por ela.
Tem um sensor infravermelho, dois encoders óticos e um wifi shield (ainda vou imstalar) que lhe permitirá se comunicar com seu controlador (um raspberry remoto) e com a Internet (IoT).
Aguarde!

Mais um projeto de IoT e automação

Mais um projeto de Internet das Coisas e automação. Além do Projeto Kuaray, estou investindo nessa nova carreira!

Ebook gratuito: Avaliação da qualidade de software

Baixe AQUI!
Como podemos avaliar ou classificar um projeto de software? Como podemos quantificar seu “status” ou suas capacidades, e medir quantitativamente sua evolução? Ferramentas, existem várias, porém, carecemos de um padrão único, que nos permita tirarmos conclusões a partir das métricas, sem nos prendermos aos “construtos” artificiais de cada uma delas. É o que este trabalho pretende fazer.

Peer review: faça ou arrpenda-se!

Peer review, ou "revisão por pares", é uma prática de qualidade de software frequentemente negligenciada nas empresas de TI, sigam elas "métodos ágeis" ou não. Porém, esta prática pode diminuir os custos de desenvolvimento, evitando problemas no momento mais crucial do Projeto: A aceitação.

Backend ready

Our Backend is ready! Using AWS services: IoT + Lambda + DynamoDB, our nodes can send hourly  their measurements!

A typical Kuaray node: Raspberry PI 3, quad core, 64 bits, 1 GB RAM, running Ubuntu Mate, and our Server software (Node.js), powered by a 12 v battery, charged by a 50w solar panel.