Direto ao ponto – Instalando o JetBrains Rider

Seguindo nossa série “Direto ao ponto”,

Hoje, vamos instalar o JetBrains Project Rider no Windows

E pra quem não conhece, essa é uma ferramenta para desenvolvimento .NET multiplataforma e que ainda está em fase de desenvolvimento. Porém conta com toda a experiência da equipe JetBrains que tem em seu currículo grandes ferramentas como IntelliJ IDEA para  desenvolvimento Java, PHPStorm para PHP, PyCharm para Python, CLion para C/C++, RubyMine para Ruby, DataGrip para banco de dados, WebStorm para frontend, etc…

E pra galera do .NET que já contava com a extensão ReSharper para VisualStudio, e ferramentas como dotPeek e dotTrace, agora também terá sua própria IDE da família JetBrains.

É isso aí, espero que curtam, e se inscrevam no meu canal no YouTube.

Até o próximo artigo.

 

Direto ao ponto – Instalando o Git no Windows

As vezes não queremos nenhum bate-papo ou informação adicional, o que precisamos é somente resolver um problema básico. Pensando nisso estou produzindo algum conteúdo simples, mas que vai direto ao ponto.

Hoje, vamos instalar o Git no Windows de forma a disponibilizá-lo no Command Prompt.

Tenho visto que é comum os desenvolvedores utilizarem o emulador Bash do Linux no Windows para usar o Git, isso se explica muito bem se levarmos em conta que o Git é feito especificamente para Unix; mas como ele é escrito seguindo o padrão POSIX foi possível a portabilidade do mesmo para outros sistemas, inclusive o Windows.

Porém as primeiras versões liberadas para Windows só rodavam com o emulador Bash, isso era um incômodo pra mim principalmente porque os binários disponíveis estavam sempre atrasados, ou seja, se a última versão do Git era a 2.2, os binários disponíveis para Windows eram da versão 1.8 por exemplo, e eu usava o Git mais atual no Linux, porém no Windows precisava usar uma versão anterior. Mas graças ao projeto http://git-for-windows.github.io, isso acabou, e a última versão para Windows está alinhada com a última versão real do Git.

Pois bem, mas mesmo assim, os programadores continuam usando o Git no Windows como se fosse no Unix, isso porque usam o emulador Bash ao invés do Command Prompt. Eu acho isso um desperdício porque, se você está usando o Windows (e aqui não tem nenhum paixonismo pelo Windows) faz sentido você usá-lo como se deve, até para que você possa tirar o máximo proveito do OS; aí quando você está usando o Linux também é razoável tirar o máximo proveito dele.

E como já falei de mais, segue o vídeo instalando o Git no Windows da forma como uso para meus trabalhos, e deixo essa recomendação para você.

Até o próximo conteúdo.

Uma dica do GIT que pode te salvar

E aí amigo(a) leitor, tudo bem?

Hoje estou “passando por aqui” só mesmo pra deixar uma dica rápida sobre GIT que pode te salvar, assim como me salvou.

Eu estou constantemente desenvolvendo e estudando sobre tecnologias emergentes, nesse caso usar as ferramentas mais atuais faz parte do meu dia a dia. Só que muitas vezes eu estou fazendo isso dentro de uma “caixa” que é o desenvolvimento nos ambientes corporativos.

O que quero dizer com isso?

Quero dizer que muitas vezes estamos dentro de uma rede corporativa, com firewall’s e proxy’s e uma série de outras restrições. E um dos problemas mais comuns que encontro, é a utilização de ferramentas como bower, npm, cordova, compose, gem, yeoman, e companhia.  O problema está em acessar os repositórios para instalação/atualização dos nossos componentes usando essas ferramentas.

Na verdade o acesso aos repositórios (GitHub na grande maioria) está livre na rede em que trabalhamos. Podemos notar isso quando acessamos a url do repositório pela web. O problema na verdade existe porque essas ferramentas tentam acessar os repositórios usando o protocolo GIT:// ao invés de HTTPS://,e esse protocolo está normalmente bloqueado nas redes corporativas, enquanto o HTTP:// e HTTPS :// são desbloqueados por padrão.

Em algumas ferramentas é possível até mudar o protocolo de acesso aos repositórios através de uma configuração nos arquivos da mesma, mas em muitos casos não é possível. Tente por exemplo clonar o projeto do “mono” e seguir as instruções para compilação; uma dessas instruções será [git submodule update --init --recursive] mas se você observar as definições dos módulos verá que as url’s apontam sempre pra GIT:// e não para HTTPS://); nesse caso então fica um pouco mais difícil de resolver o problema se o protocolo GIT:// está bloqueado.

Então a dica de hoje é…

Deixe as ferramentas como estão, e diga ao GIT pra usar o protocolo HTTPS:// toda vez que alguém pedir pra ele acessar com o protocolo GIT:// e pronto!

Legal e como fazemos isso?

Com a simples linha de comando abaixo:

git config --global url."https://".insteadOf git://

Isso fará com que o GIT use HTTPS:// toda vez que alguém tentar algo como “git clone git://seurepositorio/online.git” por exemplo.

 

Bom, é isso aí, espero que ajude você como me ajudou!