Como clonar repositório privado do Github no Docker?

Clonar repositório privado do Github no Docker

O processo de deploy de uma aplicação pode ser feito de várias formas dependendo do ambiente escolhido tanto para o desenvolvimento quanto para a hospedagem final dele. Esse processo pode ser descomplicado com o simples fato de subir o código que está no seu Github direto na imagem docker e continuar com o processo de build e outras tarefas todas por lá, dessa forma tudo já fica bem mais encaminhado para usarmos CD/CI no futuro.

O problema…

Quando estamos lidando com repositórios públicos é bem simples de se fazer. Basta fazer o clone lá no Dockerfile da mesma forma que nós faríamos na nossa estação de desenvolvimento.

Algo como:

...
RUN git clone https://github.com/seu_usuario/seu_repositorio.git
...

Esse processo é simples porque o repositório é público e não precisa de nenhuma autenticação para clona-lo. O que obviamente não acontece no repositório privado.

Para fazer o clone do repositório privado nós precisamos estar autenticados e não seria interessante passarmos as informações de autenticação pela url, isso seria uma falha de segurança seríssima.

Então, para resolver esse problema vamos usar SSH para se autenticar de forma segura e mais elegante 🙂

Autenticando no Github por SSH

Para que o Github possa nos autorizar a fazer a clonagem do repositório na imagem Docker, nós vamos precisar gerar um par de chaves criptografadas na nossa estação de desenvolvimento. Você pode gerar as chaves em todas as máquinas que forem necessárias.

Se você não sabe o que é SSH, aqui vai um link bem completo que vai te ajudar, mas basicamente, usaremos um par de chaves assimétricos de criptografia, nas quais existem uma chave privada, que é sua (da sua máquina em questão) que vamos usar mais pra frente e uma chave pública que você vai configurar lá na sua conta no site do Github em seguida.

Uma coisa importante a saber é que cada par de chaves é único e a autorização é concedida quando a chave pública conseguir “entender” a chave privada que será passada à ela.

Feitas as apresentações, vamos ver como gerar nosso par de chaves SSH.

Verificando as chaves SSH

Antes de sair gerando as chaves, pode ser que você já as tenha gerado antes.

Vale lembrar que todos os procedimentos citados aqui podem ser utilizados em plataformas Microsoft Windows, GNU/Linux e MacOS. Nesse caso estou utilizando um GNU/Linux Ubuntu 20.04.1 LTS

Para verificar se você já possui um par de chaves SSH gerados, digite o seguinte comando no terminal do do seu sistema operacional  ls -al ~/.ssh para ver se existe alguma chave criada.

$ ls -al ~/.ssh
# Lista os arquivos do seu diretório .ssh, se eles existem

Por padrão os arquivos que nos interessam podem ter o nome de id_rsa e extensões .pub

Se você encontrou algum desses arquivos no seu diretório, é provável que possamos usá-los nos passos seguintes ao invés de criar um novo par de chaves.

Se você viu um par de chave pública e privada listado (por exemplo id_rsa.pub and id_rsa) e gostaria de usá-las para conectar com o Github, você pode adicionar sua chave SSH ao SSH-agent e pular o próximo passo da geração de chave do tutorial.

Se mesmo assim você quiser gerar um novo par de chaves não fará mal algum.

Como gerar o par de chaves SSH

Você vai precisar utilizar um pacote específico para gerar o par de chaves SSH. O mais conhecido é o openssh e ele tem versões para os sistemas operaacionais mais utilizados no mercado.

Para gerar o seu par de chaves, vá ao terminal do seu sistema operacional e digite ssh-keygen -t rsa -b 4096 -C “your_email@example.comsubstituindo o email pelo email da sua conta do Github.

$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Vai aparecer Enter a file in which to save the key no seu terminal. Você pode aceitar o caminho padrão (/home/seu_usuario/.ssh/id_rsa) pressionando enter ou digitar outro caminho para gerar suas chaves.

Enter a file in which to save the key (/home/you/.ssh/id_rsa): [Press enter]

Caso haja algum arquivo com o mesmo nome no diretório escolhido, será perguntado se você quer substituí-lo.

No próximo passo não informe nenhuma senha no arquivo, caso contrário teremos um erro de chave inválida (invalid key) quando gerarmos nossa imagem Docker.

Enter passphrase (empty for no passphrase): [Type a passphrase]
Enter same passphrase again: [Type passphrase again]

Depois disso seu par de chaves assimétricas será gerado. Vamos ver agora como adicioná-las ao seu agente.

Adicionado as chaves ao agente

Nessa etapa você pode adicionar as chaves já existentes ou adicionar as novas chaves geradas na etapa anterior.

Para adicionar as chaves no agente, vamos iniciá-lo em bacakground

$ eval "$(ssh-agent -s)"
Agent pid 43558

e agora adicione sua chave privada no agente. Se você alterou o nome e/ou o diretório da chave, substitua no comando.

$ ssh-add ~/.ssh/id_rsa

Esse procedimento deixa essa chave configurada e pronta para trabalhar em futuros commits e outros comandos, mas não necessariamente é obrigatório para gerarmos a imagem Docker, como vamos ver mais pra frente.

Adicionando a chave pública no Github

Lembra que para que a autenticação ocorra é preciso que as chaves pública e privada “conversem”? Nesse passo damos início á essa “conversa” configurando a chave pública na conta do Github. Para fazer isso, precisamos copiar o conteúdo da chave gerada no seu computador.

Você pode usar o xclip para fazer isso ou simplesmente copiar o arquivo gerado.

$ sudo apt-get install xclip
# Faz o download e instala o xclip. Se você não tem instalado o 'apt-get', você pode usar outro instalador (como o 'yum')$ xclip -sel clip < ~/.ssh/id_rsa.pub
# Copia o conteúdo da sua chave id_rsa.pub

Para usar o arquivo sem xclip

$ cat ~/.ssh/id_rsa.pub

Agora siga os passos para adicionar a chave na sua conta do Github.

  1. Acesse sua conta do Github
  2. Clique na sua foto de perfil no canto superior direito
  3. Clique em “Settings
  4. No menu à esquerda, clique em “SSH and GPG keys
  5. Clique em New SSH Key ou Add SSH key
  6. Adicione uma descrição para a nova chave (Ex.: note-dev)
  7. Cole a chave no campo Key
  8. Clique em Add SSH key
  9. Se for solicitado, confirme sua senha do Github.

Feito isso, vamos configurar nosso Dockerfile

Configurando o Dockerfile

Para configurar o dockerfile, vamos criar uma imagem intermediária para fazer o clone e depois elminá-lá, dando lugar apenas para a imagem definitiva.

# Choose and name our temporary image
FROM alpine as intermediate

# Add metadata identifying these images as our build containers (this will be useful later!)
LABEL stage=intermediate

# Take an SSH key as a build argument.
ARG SSH_PRIVATE_KEY

# Install dependencies required to git clone.
RUN apk update && \
    apk add --update git && \
    apk add --update openssh 

# 1. Create the SSH directory.
# 2. Populate the private key file.
# 3. Set the required permissions.
# 4. Add github to our list of known hosts for ssh.
RUN mkdir -p /root/.ssh/ && \
    echo "$SSH_PRIVATE_KEY" > /root/.ssh/id_rsa && \
    chmod -R 600 /root/.ssh/ && \
    ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts

# Clone a repository (my website in this case)
RUN git clone git@github.com:seu_usuario/seu_repositorio.git

# Choose the base image for our final imageFROM alpine
RUN apk update && \
    apk upgrade && \
    apk add --update nodejs npm && \
    npm install -g @angular/cli

# Copy across the files from our `intermediate` container
RUN mkdir app
COPY --from=intermediate /qualico/. /app/.

WORKDIR /app

Basicamente estamos dizendo apara o dockerfile que vamos informar uma variável $SSH_PRIVATE_KEY na hora de gerar a imagem. Queremos que ele crie uma instância intermediária só para fazer a clonagem do nosso repositório e depois elimine ela e aí sim nós configuramos a imagem definitiva.

Nesse ponto, já configuramos a chave pública na nossa conta do Github, agora chegou a hora de informar a chave privada para autenticação.

Para fazer isso, é preciso carregá-la em uma variável temporária no seu sistema operacional. Faça isso com o seguinte comando.

MY_KEY=$(cat ~/.ssh/id_rsa)

E agora já podemos fazer o build da imagem Docker

docker build --build-arg SSH_PRIVATE_KEY="$MY_KEY" --no-cache --tag clone-example .
…
Successfully tagged clone-example:latest

Nesse ponto já temos a imagem construída com sucesso e podemos fazer o nosso deploy para onde quisermos, mas se você ainda se preocupa com segurança e quer se livrar dos resquícios desse processo, siga em frente com mais alguns passos.

Limpando os vestígios

Mesmo utilizando uma imagem intermediária para dar mais segurança ao processo, se visualizamos os logs das operações, ainda podemos ver nossa chave privada por lá e não queremos isso, não é?

docker history clone-example
> IMAGE               CREATED             CREATED BY                                      SIZE
>b3dbbf389a73        2 minutes ago       /bin/sh -c #(nop) COPY file:90e3ecf812fe16bf…   254B
>39d11e01b3ad        2 minutes ago       /bin/sh -c mkdir files                          0B
>196d12cf6ab1        2 weeks ago         /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
><missing>           2 weeks ago         /bin/sh -c #(nop) ADD file:25c10b1d1b41d46a1…   4.41MB

Durante a configuração do Dockerfile utilizamos o comando LABEL onde especificamos o valor de intermediate. Fizemos isso justamente para identificar e facilitar a remoção dos dados sensíveis nessa etapa.

Onde apenas com um comando, vamos remover todos os vestígios da operação, não deixando a sua chave privada exposta.

Para isso, execute o comando:

docker rmi -f $(docker images -q --filter label=stage=intermediate)

Feito pessoas!

Agora seu processo de deploy está mais automatizado e seguro 🙂

Espero ter ajudado!

Grande abraço 🙂

Como resolver SEFIP “Lacre do arquivo não confere com a informação de controle”?

SEFIP

Oi pessoas, tudo certo?

Para resolver o erro “Lacre do arquivo não confere com a informação de controle” que ocorre na SEFIP no Windows é preciso fazer download do software 7Zip File Manager. Depois de instalado, utilize ele ao invés do “Compactador de arquivos” do Windows. Para utilizar, basta clicar com o botão direito sobre o arquivo e ir em “Extrair aqui”.

Dica bem rápida dessa vez!

Abração!

Como organizar meu aplicativo Angular

Organização

É natural que projetos comecem pequenos e naturalmente se expandam ao longo do tempo e se tornem algo monstruoso, principalmente se você estiver fazendo um monolito ou um espaguetão bem doido. Não te culpo, quem nunca fez isso?

O problema é que dependendo da dimensão que o projeto tomar com o passar do tempo e com o aumento do seu time você pode ter criado um grande problema para todo mundo, pois, na bagunça generalizada que ele vai se tornar, você perde velocidade, agilidade e consequentemente escalabilidade.

Imagine a situação: você tem 3 devs desenvolvendo 3 features diferentes, mas você está em meio a um caos no seu projeto, sem padrão qualquer todo mundo está editando o arquivo app.module.ts. Tranquilo, afinal cada um está trabalhando na sua branch e está tudo certo. Tudo certo até você ter que fazer o merge dessa bagunça e resolver os conflitos que não precisavam existir se o projeto estivesse organizado 🙂

Mas como organizar?

Uma sugestão é dividir as responsabilidades como nesse exemplo:

|-- modules

    |-- module1
        |-- [+] components
        |-- module1.service.ts
        |-- module1.module.ts
        |-- module1.routes.ts

    |-- module2 
        |-- [+] components
        |-- module2.service.ts
        |-- module2.module.ts
        |-- module2.routes.ts

|-- shared
        |-- [+] components
        |-- [+] mocks
        |-- [+] models
        |-- [+] directives
        |-- [+] pipes

|-- core
        |-- [+] authentication
        |-- [+] footer
        |-- [+] guards
        |-- [+] http
        |-- [+] interceptors
        |-- [+] mocks
        |-- [+] services
        |-- [+] header

|-- app.module.ts
|-- app.component.ts

Dessa forma o seu projeto está com cada domínio separado, devidamente modularizado com seus componentes, módulos, rotas, guards, services e etc.

Eu em particular gosto de trocar o diretório “Modules” por “Features” e isso é a prova que não existe uma regra, você faz a sua! Essa é apenas uma sugestão de organização proposta pelo próprio Angular e alguns outros figurões como John Papa por exemplo.

O diretório core contém tudo que for necessário para a sua aplicação funcionar, como os componentes principais do seu template, serviços de autenticação e o que mais for necessário.

Enquanto o diretório shared é responsável por guardar os componentes, pipes, diretivas, etc que serão compartilhados com os outros componentes. A única regra pra entrar nesse diretório é não pertencer a nenhum componente, apenas ser usado por eles 🙂

Mas me diz aí como você estrutura o seu projeto? Tem alguma ideia melhor pra compartilhar conosco?
Já teve que reestruturar um projeto no meio do caminho ou ficou com o custo tão elevado de manutenção que inviabilizou a continuidade de um projeto?

Comenta aí que vai ser legal a gente conversar sobre isso 🙂

Fonte

https://johnpapa.net/angular-app-structuring-guidelines/

https://johnpapa.net/angular-growth-structure/

https://medium.com/@motcowley/angular-folder-structure-d1809be95542

https://itnext.io/choosing-a-highly-scalable-folder-structure-in-angular-d987de65ec7

Como a Amazon define um novo produto?

Caminho errado volte!

Ei, você que tem uma ideia na gaveta ou trabalha com o desenvolvimento de um novo produto na sua empresa. Como você faz para tirar isso do papel? Que framework você utiliza? Ou simplesmente lança e vê no que dá?

Há quem faça questionários com o cliente, há quem só olhe para os stakeholders do projeto e também há quem apenas acredite que teve uma ótima ideia e isso basta para garantir o sucesso do seu projeto.

Na vida real não deveria ser bem assim. Muitas vezes as empresas empregam muito tempo e dinheiro em projetos que seus clientes não precisam de fato ou que não resolvem um problema e isso não significa que seu produto é ruim ou foi mal feito, e sim que talvez o seu cliente não precisava dele.

Existem diversos frameworks e metodologias que resolvem esse problema com abordagens diferentes, mas hoje eu vou te mostrar uma abordagem bem legal que eu nunca usei, mas pretendo aborda-la em breve aqui na empresa. O nome dessa técnica é Working Backward e essa é a forma que a Amazon desenvolve seus produtos.

Working Backward

Essa forma de desenvolvimento de produto é totalmente integrada ao consumidor final e parte do fim para o princípio. Entenda como funciona.

Press release

O primeiro passo é você escrever um anúncio do produto final e destinado ao público-alvo que vai utilizar o produto, isso mesmo, você escreve um artigo como se o seu produto já existisse e estivesse sendo noticiado pela imprensa. Pense em todos os detalhes e realmente pense como a imprensa noticiaria o seu produto. Escreva em um papel e tire várias cópias, você vai precisar delas na próxima etapa.

Reunião

Com a notícia em mãos junte a sua galera, de preferência que tenham skills e backgrounds bem diversificados, dê à eles o seu papel com a notícia do seu novo produto e prepare-se para as “pedradas.”

Pedradas

Naturalmente as pedradas virão. Esse pode ser um momento frustrante, mas é a parte mais interessante do processo. É aqui que você vai identificar as principais oportunidades e problemas do seu novo produto. Mas não leve nada para o pessoal, esse é o trabalho que a sua galera tem que fazer. Sempre com o foco no cliente.

Resultados

Se você sobreviveu a enxurrada de feedbacks da etapa anterior, agora é a hora de extrair os resultados desse processo. Provavelmente, surgiram diversos aspectos que podem fazer com que o seu produto tenha que ser modificado para potencializar os resultados ou o impacto no cliente, normalmente algo que você não pensou, mas aquele colega que teve um caminho diferente do seu na vida, conseguiu pensar por você.

Durante esse processo, você consegue perceber com mais clareza todas as etapas do processo de desenvolvimento e já pode aproveitar para gerar pequenos pacotes de entregas (baby steps) e depois disso é mão na massa!

Como implementar na sua empresa

Uma boa abordagem é a utilização de templates para a criação dos press releases. Mas vale lembrar que o importante é ser fiel ao lançamento de um produto destinado ao publico-alvo, seja ele interno ou externo.

Começando pelo press release, basicamente, você precisa descrever a sua solução e apresenta-la par o seu público de forma clara e simples, entendível pelo público-alvo. Você pode ver como estruturar um press release nesse link https://rockcontent.com/blog/press-release/

Feito isso, chame o pessoal e deixe eles lerem o conteúdo por 15 minutos, depois é a hora dos feedbacks.

Durante o retorno dos feedbacks, tire dúvidas, ajuste features e remova features desnecessárias.

O que aprendemos com isso?

No processo de criação de um produto muitas vezes a gente acha que teve uma brilhante ideia e que ninguém nunca pensou nisso. Quantas vezes você já pensou “poots, como ninguém fez isso ainda?”. Talvez tenham feito de uma forma errada ou num tempo errado, ou talvez não tenha o fit correto com o público alvo estabelecido, enfim, são “N” fatores.

Acho que o principal aprendizado é que nós desenvolvemos produtos para os clientes não pra nós, portanto, a dica é não se apegar a solução que você criou e sim ao problema que você resolve.

O foco no cliente, além de garantir o sucesso do produto também garante que você erre menos, se frustre menos e no final das contas perca menos dinheiro com esse processo.

E você, como desenvolve os produtos da sua empresa? Em quem você pensa primeiro? Comente aí em baixo como você faz para criar coisas incríveis!

Fonte:

https://www.product-frameworks.com/Amazon-Product-Management.html

https://www.quora.com/What-is-Amazons-approach-to-product-development-and-product-management?ref=http://www.product-frameworks.com/

Como hospedar seu app sem servidor?

Serverless

Como assim sem servidor? No seu dia-a-dia você vai ver que é isso mesmo, mas na real, nada mudou 🙂

Você já ouviu falar sobre serverless ou FaaS? Então é sobre isso que temos que conversar.

Serverless em tradução livre do inglês seria como “sem servidor”, de fato, o conceito é esse mas também não é bem assim. Na verdade a utilização de uma “arquitetura” serveless apenas “abstrai” a camada de infraestrutura de forma que você não precise se preocupar com isso.

Isso significa que podemos desenvolver um código na nossa máquina e simplesmente dar um deploy para algum player do mercado sem sequer configurar um docker, roteamento, alta disponibilidade, camadas de segurança, etc. Apenas desenvolva seu código e digite no terminal “plataforma_que_eu_escolhi deploy” e pronto! Olha que maravilha!

Tá mas e o FaaS? Essa é a sigla que utilizamos para definir Function As A Service, que pode ser considerado sinônimo de serverless. Os puristas por favor não me xinguem.

Beleza, então meu código tá viajando por aí e eu nem sei onde está? Mais ou menos.

Na verdade, o seu código está em um – ou mais – servidor(es) sim! A jogada aqui é que você não precisa se preocupar com isso, essa é a expertise do player que te fornece o serviço, você não precisa mais ficar dimensionando máquina virtual e configurando o ambiente.

Mas então é uma maravilha só! Vou usar para tudo. Calma! Não é bem assim. Veja abaixo as vantagens, desvantagens e quando usar.

Vantagens

  • Deploy muito prático
  • Setup muito rápido (muito mesmo)
  • Economia de tempo e dor de cabeça com infraestrutura
  • Não importa a quantidade de requisições, o seu serviço não vai “estrangular”

Desvantagens

  • O report de consumo geralmente não é muito claro (normalmente o serviço é cobrado por consumo)
  • Se você não tiver um “stop”, você pode gastar muito dinheiro, inclusive com um bug no código por exemplo
  • É bom que o seu código esteja bem otimizado
  • Não é legal usar para toda e qualquer coisa

Quando usar?

Já tentei usar essa solução de várias formas, certas e erradas (mais erradas do que certas hehe) até encontrar o caminho correto. Não tente subir uma API completa no Firebase Functions por exemplo, não é uma boa solução, não é bom para a sua aplicação e menos ainda para o seu bolso.

As functions são ótimos recursos para hospedar códigos que precisam ser chamados sob demanda para resolver um domínio da aplicação, algo que precise ser chamado, faça o que tenha que fazer e depois termine.

Um exemplo bacana seria: ao fazer o upload de um arquivo de imagem, o usuário envia uma imagem gigantesca para a aplicação, então você chama a sua função hospedada em uma arquitetura serverless e executa toda a otimização dessa imagem para depois armazena-la no bucket e com isso economiza, espaço em disco e grana no bolso, além de garantir o seu padrão da imagem, dimensões, tipo de arquivo, filtro, etc.

Outra aplicação legal é com a utilização de microserviços ao invés de um monolito. Mas isso é um papo para outra jarra de café.

Principais players

E aí, já se animou para testar essa infra? Praticamente todos os players que eu citei te fornecem uma conta gratuita onde você pode se divertir e testar suas aplicações. A experiência é maravilhosa, vai lá!

Em breve eu solto outro post pra te ajudar a fazer isso 😉

Clique em Serverless – Subindo meu código sem servidor (se o título ao lado não estiver com um link, significa que eu ainda não escrevi o post 🙂 )

Obrigado por ter me aturado até aqui e um grande abraço à todos!

Não esqueçam: vamos fazer coisas incríveis!

Fallback CSS e JS para jQuery

Tela com os erros de carregamento do site do Materialize

E aí pessoas, tudo certo?

Se você achou esse post pelo Google, dificilmente você não sabe o que é fallback, mas para quem chegou aqui de outra forma, aí vai. Fallback é o termo que usamos para mitigar a falta de algum arquivo. Por exemplo, se você está usando um arquivo em um CDN e por algum motivo esse arquivo não exista mais ou esteja com algum problema de acesso, nós testamos se alguma função desse arquivo funciona, se ela retornar um erro, a gente carrega esse arquivo localmente para que a experiência do usuário não seja afetada, afinal de contas ele não tem nada a ver com isso, certo?

Por que eu faria isso?

Mas aí você pode estar se perguntando: por que diabos eu me preocuparia com isso se eu já uso CDN, que de certa forma garante que tudo funcione sempre para mim? Ora, respondo eu mesmo: eu já fui estou “bloqueado” por CORS pelo jQuery por testar aplicações com o CDN em localhost. Isso faz com que eu não consiga usar os recursos que dependem de jQuery em sites que não tenham fallback. Um exemplo de site é o do Materialize, eu simplesmente não consigo acessar os menus (collapse). Mas felizmente uso IP dinâmico e assim que eu conseguir fazer com que alguém na operadora de internet entenda o que eu estou falando, eu trocarei o IP de borda.

Observe as mensagens de erro no console.

Tela com os erros de carregamento do site do Materialize
Captura de tela com erros de carregamento do Materialize

Failed to load resource: the server responded with a status of 403 (Forbidden)
jquery-3.2.1.min.js:1 Failed to load resource: the server responded with a status of 404 ()
jquery.timeago.min.js:1 Uncaught ReferenceError: jQuery is not defined
at jquery.timeago.min.js:1
at jquery.timeago.min.js:1
search.js:396 Uncaught ReferenceError: jQuery is not defined
at search.js:396
init.js:259 Uncaught ReferenceError: jQuery is not defined
at init.js:259

Fallback para Javascript

Para fazer com o que o seu usuário tenha a mesma experiência, garanta que ele consiga acessar o arquivo do seu próprio servidor, caso o CDN falhe.

Para o javascript fazemos isso testando alguma funcionalidade que só o arquivo js em questão contenha.

Coloque esse código antes da tag </body>.

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.4.1/jquery.min.js"></script>
<script>  window.jQuery || document.write('<script src="/content/js/libs/jquery-1.7.1.min.js"><\/script>')</script>

Observe que na primeira linha tentamos carregar o arquivo normalmente no CDN e na segunda linha testamos se a função window.jQuery existe, caso não exista a gente carrega o arquivo local. Obviamente, você precisa ter o arquivo salvo no seu servidor.

E o CSS?

Geralmente ocorre o mesmo com o CSS, mas como aplicar essa mesma lógica para o CSS, se ele é só uma folha de estilos?

.invisible {
       display: none;
}

Para fazer isso, nós vamos criar uma div invisível e verificar se ela realmente está invisível por exemplo.

Dentro do arquivo CSS que a gente quer testar, a gente deixa a div invisível

Depois, colocamos o elemento que vai nos ajudar a testar a funcionalidade no body da pagina

<div class="invisible"></div>

Por fim a gente usa uma função em Javascript / jQuery para verificar se o CSS definido no arquivo foi aplicado.

<script>
    // CSS Fallback
    $(function () {
        if ($('.invisible:first').is(':visible') === true) {
            $('<link rel="stylesheet" type="text/css" href="/assets/css/jquery.css" />').appendTo('head');
        }
    });
</script>

A lógica é a mesma, se o CSS não foi aplicado talvez o arquivo não foi carregado, então nós mesmos carregamos ele do nosso servidor local.

Conclusão

Basicamente a lógica é a mesma tanto para javascript quanto para CSS, a diferença é como fazer o teste. Fique atento que para testar o CSS você precisa do javascript e não necessariamente do jQuery, mas já que você já o carregou para outra tarefa, não custa usá-lo.

Vale lembrar também que essa lógica pode ser usada para qualquer arquivo, não apenas para o jQuery.

Referências

Mas por que ter esse trabalho se eu posso usar direto do meu sistema de aquivos e garantir a experiência do usuário da mesma forma?

Tem a ver com performance, cache e otimização de recursos do seu servidor. Falarei mais sobre isso em posts de performance, SEO e CDN em breve.

Espero ter ajudado! Grande abraço!

Como testar o envio de e-mail sem ter um servidor de e-mails

E aí gurizada do café, tudo tranquilo?

Enquanto você desenvolvia uma aplicação, você já teve que testar o envio de e-mails e não tinha um servidor de emails para fazer isso? Ou tomou aquele sufoco para configurar e autenticar o seu servidor? Quem nunca?

Existe uma aplicação pra nos ajudar com esse pepino… o nome dela é jenifer, digo Mailtrap 🙂

Para começar a brincadeira você precisa fazer um cadastro super simples e que pode ser feito por login social (Google ou GitHub).
Até o dia em que eu postei esse texto, existem várias formas de contratação onde a diferença entre os planos é basicamente as quantidades das features, mas o que nos interessa por aqui é a conta free, não é mesmo?

A conta free te permite ter apenas um projeto configurado, uma mailbox, nenhum redirecionamento/encaminhamento, 500 mensagens e as mensagens são apagadas todo o mês. Perfeito pra gente que só quer testar a API 🙂

Após o cadastro você será redirecionado para a tela inicial com a sua mailbox já configurada. Nessa parte você só pode trocar o nome, se preferir… ou deletá-la.

Tela inicial do mailtrap com sua mailbox criada.

Ao clicar na mailbox, nese caso “Minha inbox”, você será redirecionado para a página inicial da sua mailbox.

Página principal da ferramenta mailtrap, contendo as configurações do serviço e mensagens

Aqui que a mágica acontece… nessa página você tem todas as informações para configurar na sua aplicação, seja ela desenvolvida em Node.js, PHP, Ruby on Rails, etc…

Depois de integrar na sua aplicação e testar, é só clicar nas mensagem que ficam no painel da esquerda e visualizá-las.

E aí, essa ferramenta parece útil para você? Comente aí em baixo se te ajudou e sugere alguma coisa que você gostaria de ver por aqui.

Grande abraço!

Easter Egg do Thanos no Google

Easter Egg do Thanos no Google

Não sei quem surpreende mais, o Google ou a Marvel. Na ocasião do lançamento do filme da Capitã Marvel, eu fiz um post sobre o site do filme que causou uma nostalgia tremenda nos programadores tiozões como eu, você pode conferir esse post aqui.

Se na vez da Capitã Marvel foi a vez da Marvel, agora é o Google quem surpreende. Vai lá, teste você mesmo! Entre no google, pesquise por thanos e clique na manopla…

Capitã Marvel causando nostalgia em desenvolvedores

E aí galerinha do café, tudo tranquilo?

O desenvolvimento web que conhecemos hoje tem um passado nebuloso… hehehe

Hoje em dia temos muita gente nova que provavelmente nem ouviu falar em MIcrosoft Frontpage (eca!), já que na época em que ele “resolvia” alguns problemas, a maioria do pessoal estava nascendo…

Na época, mesmo com uma baita ascensão da internet, programadores web eram vistos com desdenho por programadores desktop, que era o que mais havia. A frase mais comum era “PHP não é linguagem, é tecnologia”, “ASP é gambiarra”, “HTML só formata”, “progama em C que nem gente grande”, etc…

Fato é que a gente não dava muita bola (mesmo eu já programando em C também nessa época heheh) e desenvolvíamos coisas “incríveis” para os sites da escola, da turma, do condomínio, da família e para tudo o que mais poderia haver, sempre com muitos códigos copiados e alterados de diversos tutoriais e upados com o velho FTP.

Recentemente,  iria fazer um comparativo de sites que eu fazia na época para os que rola hoje (a diferença é enorme!!!) para uma talk que fiz na trilha Inspire do TDC, mas a Marvel resolveu isso pra mim. Como o filme da Capitã Marvel rola nos anos 90, eles fizeram o site oficial bem do jeitinho – horrível – que a gente fazia na época. Isso deu uma baita nostalgia!

Confere lá: https://www.marvel.com/captainmarvel/

A web melhorou não é? hehehe

Valeu, grande abraço!

Como remover a senha de uma planilha do Excel xlsx

E aí galera do café, tranquilo?

Post rápido para salvar aquela planilha com a senha perdida 😉

Aproveitem!

 

Este método somente aplica-se a planilhas protegidas por senha. Se o arquivo está protegido com o recurso “Encriptar com uma senha”, ele não funcionará.

  1. Abra o Windows Explorer e habilite a exibição de extensão de arquivos conhecidas. Para isso, pressione a tecla para exibir os menus superiores e entre no menu Ferramenta > Opções de pasta
    Na aba Modo de Exibição, desmarque a caixa Ocultar a extensão dos tipos de arquivo conhecidos e clique em OK.
  2. Altere a extensão do arquivo de .XLSX para .ZIP
  3. Extraia o arquivo para um diretório com o seu extrator favorito (Winzip, 7-zip, tar, etc)
  4. Entre no subdiretório xl e depois em worksheet que você acabou de extrair
    Deverá ter um ou mais arquivos com nomes como: sheet1.xml (sheet2.xml, etc. Eles representam as planilhas que você tem no seu arquivo.
  5. Dentro de cada um destes arquivos terá uma tag XML: <sheetProtection password=… />. Delete esta tag XML inteira usando um editor de texto (como o Bloco de notas, Visual Studio Code, etc).
  6. Re-zip os arquivos novamente.
  7. Renomeie o arquivo de .ZIP para .XLSX

E era isso!
Escrevam aí como foi a experiência de vocês com esse método…

Grande abraço!

Fonte

How to unprotect a password protected .XLSX file – Adam’s Code Blog – http://blog.bitcollectors.com/adam/2011/10/how-to-unprotect-a-password-protected-xlsx-file/