UZEDNunca é o bastante.

Jekyll

Desenvolvendo sites estáticos

Alexandre 2019-10-15

Jekyll

https://jekyllrb.com/

O Jekyll é um gerador de códigos estáticos. Onde você cria páginas e até mesmo um blog de forma estática, usando HTML, junto com alguns truques que irão ajudá-lo a converter seu site em arquivos estáticos, pronto para ser publicado. Ele é baseado em vários formatos como Markdown para formatação de textos e posts e um padrão de template chamado Liquid com um pouco de YAML para exibir e guardar os dados das variáveis.

Para hospedar seu site, você pode utilizar serviços como S3 da Amazon, ou serviços exclusivos para hospedagem estáticos.

Iniciando

gem install bundler jekyll
jekyll new my-awesome-site
cd my-awesome-site
bundle exec jekyll serve
# => Now browse to http://localhost:4000

Montando Conversor RGB -> VGA

MSX RGB -> VGA

Alexandre 2016-06-06

Resolvi me aventurar um pouco em eletrônica e montar um conversos RGB -> VGA para o meu MSX Gradiente para conectar em um monitor Samsung 710n.

Peguei esquema do site da http://www.msxpro.com/rgb-vga.html . Como não entendo como interpretar um esquema para montar o circuito, pedi muita ajuda para o pessoal da lista de MSX, agradeço a todos que me ajudaram.

adaptador

Utilizei esta lista de componentes:

  • 1 resistor de 1k;
  • 1 resistor de 680k;
  • 1 diodo Zener 5v1 por meio Watt;
  • 1 LM1881;
  • 1 soquete torneado de 8 pinos;
  • 3 capacitores 100n;
  • 1 conector fêmea db15 denso (vga);
  • 1 soquete macho din 8 ou din 7;
  • 1 cabo 8 vias;

Como não sei interpretar o esquema, acabei desenhando no papel como que faria o layout do circuito, e depois, montei um teste na protoboard.

Depois de testar, é hora de montar a placa e soldar os conectores.

Evolução das Camadas nas Aplicações Corporativas

Padrões de Arquitetura

Alexandre 2015-04-21

Texto retirado do livro Padrões de Arquitetura de Aplicações Corporativas do Martin Fowler.

Embora eu seja jovem demais para ter feito algum trabalho nos velhos tempos dos sistemas em batch, não sinto que as pessoas pensassem muito em camadas naquele tempo. Você escrevia um programa que manipulava algum tipo de arquivo (ISAM, VSAM, etc.) e essa era sua aplicação. Não era necessário aplicar nenhuma camada.

A noção de camadas se tornou mais visíveis nos anos 90, com o advento dos cliente-servidores. Estes eram sistemas em duas camadas: o cliente mantinha a interface com o usuário e um ou outro código código da aplicação, e o servidor era normalmente um banco de dados relacional. Ferramentas comuns para o lado cliente eram, por exemplo, VB, Powerbuilder e Delphi. Essas ferramentas tornaram particularmente fácil criar aplicações que faziam uso intensivo de dados, uma vez que elas disponibilizavam componentes visuais que trabalhavam o SQL. Assim, você podeia criar uma tela arrastando controles para uma área de desenho e então usando páginas de propriedades para conectar os controles ao banco de dados.

Se a aplicação tivesse somente de exibir e fazer atualizações simples em dados ralacionais, então esses sistemas cliente-servidor funcionavam muito bem. O problema surgiu com a lógica de domínio: regras de negócio, validações, cálculos, e assim por diante. Normalmente, as pessoas escreviam essa lógica no cliente, mas isso era desejado e , normalmente, feito embutindo-se a lógica diretamente nas telas da interface com o usuário. À medida que a lógica do domínio se tornava mais complexa, ficava muito mais difícil trabalhar com este código. Além disso, embutir a lógica nas telas facilitava a duplicação de códgio, o que significava que alterações simples resultavam em buscas de código semelhante em muitas telas.

Uma alternativa era colocar a lógica de domínio no banco de dados na forma de procedimentos armazenados (stored procedures). Estes, no entanto, forneciam mecanismos limitados de estruturação, o que mais uma vez levava o código desajeitado. Além disso, muitas pessoas gostavam de banco de dados ralacionais porque SQL era um padrão, o que lhes permitia a qualquer tempo mudar o fornecedor do banco de dados. Ainda que poucas pessoas realmente fizessem isso, muitas gostavam de ter a opção de mudar de fornecedor sem que isto implicasse em custos de migração altos demais. Por serem todos proprietários, os procedimentos armazenados eliminavam esta opção.

Ao mesmo tempo em que a arquitetura cliente-servidor estava ganhando popularidade, o mundo o mundo orientado a objetos estava ascendendo. A comunidade de objetos tinha a resposta para o problema da lógica de domínio: migrar para um sistema em três camadas. Nesta abordagem, você tinha uma camada de apresentação para a sua interface com o usuário, uma camada de domínio para a sua lógica de domínio e uma camada de dados. Desta maneira, você poderia tirar toda a complexa lógica de domínio da interface com o usuário e coloca-la em uma camada na qual você poderia estruturá-la apropriadamente utilizando objetos.

Apesar disso, a popularidade dos objetos fez pouco progresso. A verdade era que muitos sistemas eram simples, ou pelo menos começavam simples. Embora a abordagem em três camadas tivesse muitos benefícios, o ferramental para o desenvolvimento cliente-servidor era convincente se o seu problema fosse simples. Além disso, as ferramentas para o desenvolvimento de cliente-servidor eram difíceis, ou mesmo impossíveis, de usar em uma configuração com três camadas.

Acho que o abalo sísmico aqui foi o advento da Web. De repente as pessoas passaram a querer instalar aplicações cliente-servidor usando um navegador Web. No entanto, se toda a sua lógica de negócio estivesse enterrada em um cliente rico, então toda ela precisaria ser refeita para ter uma interface Web. Um sistema bem projetado, em três camadas, poderia simplesmente acrescentar uma nova camada de apresentação e estaria pronto. Além disso, com a linguagem JAVA, vimos uma linguagem orientada a Objetos ocupar sem pudores. As ferramentas que surgiram para criar páginas Web eram muito menos amarradas à linguagem SQL e, assim mais adaptáveis a uma terceira camada.

As Três Camadas Principais

Apresentação – diz respeito a como tratar a interação entre o usuário e o software. Isto pode ser tão simples quanto uma linha de comando ou um menu baseado em texto, porém, hoje é mais provável que seja uma interface gráfica em um cliente rico ou um navegador com interface baseada em HTML. As responsabilidades primárias da camada de apresentação são exibir informações para o usuário e traduzir comandos do usuário em ações sobre o domínio e a camada de dados.

Lógica de domínio – também chamada de lógica de negócio. Este é o trabalho que esta aplicação tem de fazer para o domínio com o qual você esta trabalhando. Envolve cálculos baseados nas entradas e em dados armazenados, validação de quaisquer dados provenientes da camada de apresentação e a compreensão exata de qual lógica de dados executar, dependendo dos comandos recebidos da apresentação.

Camada de dados – diz respeito à comunicação com outros sistemas que executam tarefas no interesse da aplicação. Estes podem ser monitores de transações, outras aplicações, sistemas de mensagem e assim por diante. Para a maioria das aplicações corporativas, a maior parte da lógica de dados é um banco de dados responsável, antes de mais nada, pelo armazenamento de dados persistentes.

Há também uma regra estabelecida sobre dependências: o domínio e a camada de dados nunca devem ser dependentes da apresentação, isto é, não deve haver chamadas de sub-rotinas da apresentação a partir do código do domínio ou da camada de dados. Essa regra torna mais fácil utilizar apresentações diferentes sobre a mesma base e torna mais fácil modificar a apresentação sem ramificações sérias mais abaixo. O relacionamento entre o domínio e a camada de dados é mais complexo e depende dos padrões arquiteturais usados para a fonte de dados.

Paradigma

Metodologias Ágeis

Alexandre 2013-01-08

Estava eu lendo o livro Metodologias Ágeis Engenharia de Software Sob Medida de JóseH. Teixeira e Paulo Cesar de Macedo quando me deparo com o assunto que mais gosto, Paradigma. Sempre admirei as pessoas que conseguem mudar de paradigma com facilidade, pessoas que não querem ser colonos mas sim colonizadoras. Em toda a história, muitos cientistas ou apenas curiosos, sempre tiveram dificuldades com as suas descobertas. Muitas invenções foram além da sua época que foram inventadas, porque as pessoas não estavam preparadas para ela. Assim também funciona com diversas idéias ou serviços. Tem um outro livro o Mitos da inovação, no qual conta a dificuldade que muitas inovações tiveram até se tornarem populares.

Tirei alguns trechos do livro Metodologias Ágeis Engenharia de Software Sob Medida que achei interessante compartilhar:

4.10.1 O que é um paradigma?

O termo paradigma foi introduzido pela primeira vez pelo historiador Thomas Kuhn, em seu trabalho A estrutura das revoluções científicas, em 1962. Nesse trabalho, Kuhn se preocupava com as discrepâncias e os desentendimentos entre os cientistas no tocante à aplicação dos métodos e das técnicas utilizadas pela ciência. A partir daí ele propôs e desenvolveu a idéia de estruturas de conhecimento evolutivas e competitivas as quais chamou de paradigmas. Como conseqüência, Kuhn observou que quando um paradigma é aceito pela maioria da comunidade científica, ele se torna um modo obrigatório de abordagem de problemas. Portanto, os paradigmas não tem apenas uma função explicativa, mas também uma função normativa, pois tendem a definir o que é e o que não é possível.

4.10.2 Como os paradigmas sugem?

Kuhn também observou que, de tempos em tempos, novas descobertas aparecem e não se ajustam às considerações prevalecentes. Os pesquisadores então começam a procurar uma forma alternativa para explicar ou compreender a realidade dos casos que eles observam. Eventualmente, uma nova maneira de conceituar o cenário estudado é apresentada como um modo melhor de compreender as coisas: surge então um novo paradigma.

4.10.3 Competência paradigmática

#Definição:# é a crença na existência de múltiplos paradigmas e na capacidade humana de entender e incorporar essa noção às práticas científicas e profissionais. Exemplo de mudança de paradigma: Copérnico revelou que nosso sistema planetário girava em torno do Sol, substituindo as idéias anteriores centradas na Terra.

Observação importante:

Administradores que possuem competência paradigmática, ou seja, possuem o conhecimento de uma variedade de estruturas conceituais, serão capazes de julgar a aplicabilidade e o valor de diferentes formas de ver as coisas, de abordar e de analisar problemas. Ter competência paradigmática permite não ser prisioneiro de um único paradigma.

Cubos com Arduino

Artes

Alexandre 2010-06-14

Na matéria de escultura, a professora solicitou que fosse construindo três cubos. – Um cubo simples – Um aberto com as fotos do aluno – Um cubo fechado com as fotos do aluno

Como eu estava estudando o Arduino, resolvi fazer os cubos utilizando leds verdes e leds RGB.

Vejam o resultado da brincadeira:

Mitos da Inovação

Resenha

Alexandre 2008-10-23

Scott Berkun trabalhou como a equipe do Inernet Explorer da Microsoft de 1994 a 1999 e deixou a empresa em 2003 com o objetivo de escrever alguns livros. Ele dá aula no curso de graduação de pensamento criativo na Universidade de Washington. No seu livro Mitos da Inovação, Scott tem como objetivo identificar os mitos sobre inovações, explicando o porque que elas são tão populares, utilizando uma linguagem direta e diversos exemplos e referências.

Ele inicia o livro contando sobre o mito da epifania, explicando a sua origem e como ela nos influencia até os dias de hoje. Usando exemplos de grandes inovadores, explica as diversas trajetórias das inovações, visando sempre o trabalho árduo e o objetivo de cada caminho. Em outra parte, ele critica os historiadores, pela forma que é abordado o contexto histórico das inovações. Explica que o melhor método de entender a história das inovações, é pensando em vários fatos em paralelo, como se fossem galhos de uma árvore, pois uma inovação nunca é trabalhada em forma de pirâmide. Muitos dos famosos inovadores não foram necessariamente os primeiros a demonstrar para o mundo suas descobertas. Segundo o autor, pelo fato de termos quase as mesmas experiências de vida e estarmos no mesmo círculo social e cultural, ocasiona vários focos para soluções parecidas para os problemas.

O medo é citado como a maior barreira para os inovadores. Muitas vezes eles recebem críticas muito negativas sobre seus trabalhos e estas, regem um âmbito emocional muito forte. Além das críticas, o inovador tem que avaliar o impacto que o seu trabalho irá causar na sociedade. A propagação de suas idéias devem estar determinadas pela psicologia e pela sociologia, e não pelos seus méritos abstratos. É relatado a influência das pessoas que detém o poder de decisão em relação aos inovadores. Muitos gerentes não conseguem incentivar suas equipes. Os inovadores encaram muitos desafios para alcançar seus objetivos. Deve manter a vida de suas idéias; manter um ambiente saudável para poder desenvolver; proteger suas idéias de críticas destrutivas; executa-las e convencer as pessoas que ela realmente é uma boa idéia.

Desde nossa infância somos doutrinados a acreditar no mito do herói, da epifania, do bem e do mal e do certo e do errado. Mas, nem sempre o bom e o popular, são as melhores opções. Fatores como cultura, tradição, política e economia, influenciam diretamente no sucesso de uma inovação.

Estruturar bem os objetivos para os desafios aumenta as chances de sucesso. Inovadores devem procurar métodos de resolução não convencionais para trabalhar. O autor conclui que melhor coisa a fazer, é aceitar tanto as mudanças quanto as tradições. Que as novas idéias e as antigas têm o seu lugar no futuro, e o nosso trabalho é coloca-las lá.

Este livro proporciona uma rápida visão sobre a maneira de pensar da maioria das pessoas. Sempre usando exemplos reais o autor consegue passar as suas idéias, focando sempre a realidade dos fatos.