SdevLab – Dica de Desenvolvimento | Como descobrir as portas em uso no Linux e Windows

Eae turma!

No post de hoje, mais uma dica de desenvolvimento. Se você precisar descobrir em qual porta uma aplicação está funcionando, como você faria?

Como descobrir as portas em uso no Linux e Windows

A maneira mais simples de fazer esta verificação, é usando o comando Netstat.
Segundo a Wikipedia, Netstat (Network statistic) é uma ferramenta, comum ao Windows, Unix e Linux, utilizada para se obter informações sobre as conexões de rede (de saída e de entrada), tabelas de roteamento e uma gama de informações sobre as estatísticas da utilização da interface na rede.

Então, como usar?

No terminal (cmd ou shell) digite o comando:

$netstat

Ele vai apresentar várias informações. Para filtrar e conseguir uma coisa mais simples de verificar, você pode usar as opções do comando.
No windows ou no linux, para ver as opções digite:

$netstat -help

E agora, para finalizar, se for fazer isto no linux, um jeito legal de trabalhar o netstat, é concatenar o comando com pipes e greps (no windows também deve dar, mas eu não manjo muito de comandos para terminal do windows).

$ netstat | grep 8080

A descrição das opções do comando, eu não vou listar aqui, porque o help explica bem direitinho.

Valeu galera, até a próxima!

SdevLab – Dica de Desenvolvimento | Como Direcionar resultado de comandos DOS/SHELL para arquivo de texto

Fala Galera!
O post de hoje, é mais uma bobeira útil. Vou mostrar como direcionar o resultado de um comando no DOS (Windows) e no SHELL (Linux) para um arquivo de texto.

Como Direcionar resultado de comandos DOS/SHELL para arquivo de texto

A necessidade do post surgiu de uma demanda prática do trabalho. Estou fazendo um teste, mas é impossível acompanhar o resultado pelo terminal (principalmente quando sua janela tem limite de linhas, e você não pode fazer nada a respeito).
Eu poderia colocar algo como um sleep, ou timer pra poder ler o terminal antes da enchurrada de informações continuar, mas se tem um jeito mais esperto porque não?

Para direcionar a saída de um comando tanto no terminal do windows quanto do linux, vamos usar a sintaxe:

$comando > C:\Users\seu_usuario\Desktop\seu_arquivo.txt

Exemplo:

$ ls > C:\Users\seu_usuario\Desktop\resultado_ls.txt

Isso funciona tanto no Linux quanto no Windows. Veja que eu usei o caminho completo e indiquei um arquivo de texto que não existia. Assim quando executar o comando o arquivo vai ser criado e preenchido.

É claro que da pra misturar esta ideia com outros recursos. Por exemplo no Linux, podemos juntar esta ideia com o pipe e o grep para fazer algo mais interessante.

Exemplo:

$ ls | grep "algum filtro" > C:\Users\seu_usuario\Desktop\resultado_ls.txt

Valeu galera – esta é a dica de hoje. Até a próxima!

SdevLab – Passo a Passo | Instalando e Configurando o GitHub

Fala Galera,

Como já é de costume aqui no blog (heheh – infelizmente um mal costume – nem sempre é possível fazer alguma coisa e documentar então já viu né!), depois de um tempo vem a sequência de alguns posts onde comecei a falar sobre Controle de Versões e Git. Hoje vou mostrar como usar o GitHub na prática (pois o post anterior já foi a teoria que precisávamos).
Sendo assim, vamos para os trabalhos!

O que é o GitHub

“GitHub é um Serviço de Web Hosting Compartilhado para projetos que usam o controle de versionamento Git. É escrito em Ruby on Rails pelos desenvolvedores da Logical Awesome
(Chris Wanstrath, PJ Hyett e Tom Preston – Wernder). O GitHub possui planos comerciais e gratuitos para projetos de código aberto.” wikipedia

Como configurar o GitHub Desktop

1 – Faça o download do GitHub Desktop (https://desktop.github.com/) e instale no computador
2 – Abra o Git Shell, e vamos configurar o seu nome e email no Git, para aparecer nas suas ações:
git config –global user.name “YOUR NAME”
git config –global user.email “YOUR EMAIL ADDRESS”
3 – É possível esconder o email nas configurações, e o email deve ser o mesmo que está cadastrado na sua conta.
4 – Para autenticação é possível usar o HTTPS, que é recomendado pelo site, ou usar SSH. Vamos seguir a recomendação.

Até este passo, se tudo saiu bem, o GitHub foi instalado na máquina. Para colocar um projeto no GitHub, e então compartilhar com quem você quiser, um repositório será necessário. Para criar um clique em um ícone + como a Figura 1 para adicionar um repositório (ele aparece em qualquer lugar do software). Preencha o campo Name com o nome do diretório, e o path deste diretório será exibido em Local path.

Figura 1

Clique em Create Repository para criar. Como estou usando uma conta free, eu só posso criar um diretório Público, mas também é possível ser assinante do serviço e ter repositórios privados.

Depois que criar o repositório, para usar é bem simples.
Salve os arquivos que você deseja compartilhar neste repositório. Então publique o diretório, e para colocar os arquivos online clique no botão Sync que tem nesta tela, como a Figura 2.

Figura 2

Agora algumas considerações úteis:
– Para ver os arquivos no explorer, na página do GitHub ou no Shell do Git, basta clicar no botão que parece uma engrenagem.
– Na página do GitHub você consegue o link para compartilhar seu repositório com seus amigos
– Além destas ações básicas do tutorial, podemos também fazer um Fork, ou seja baixar uma versão dos arquivos e trabalhar separadamente sem causar danos no que já existe (ideal para testar sem medo)
– E você também pode seguir outros desenvolvedores e ajudar nos projetos.

Para o objetivo básico do post, o que temos é suficiente. No link abaixo tem mais informações úteis, e a visita é recomendada.

O bom deste post, é que apartir de agora, os códigos do SDevLab estarão todos por lá, contribua!
Até a próxima!

Fonte: https://help.github.com/categories/bootcamp/

SdevLab – Artigo |Git – O que é e como funciona

Fala galera,

Continuando uma ideia que iniciei em um post que postei há um tempão, sobre sistemas de controle de versão, hoje vou falar sobre aspectos básicos do Git. Boa leitura!

Uma breve história do Git, e como ele funciona

O Git, segundo site oficial, nasceu de uma maneira um pouco controversa. Para entendermos como isto aconteceu, vamos voltar um pouco antes do nascimento do Git.

O Linux foi desenvolvido sem usar um controlador de versões. As alterações eram distribuidas em forma de patches e arquivos. Apartir de 2002 o projeto passou a utilizar um controlador de versões proprietário chamado BitKeeper.

Porém, a relação entre a comunidade do Linux e os proprietários do BitKeeper foi se deteriorando até acabar. As ferramentas da empresa que a princípio eram free, passaram a ser cobradas. Este fato deixou muita gente brava, inclusive nosso ilustre amigo Linus Torvalds. Isto na verdade foi uma coisa boa, pois este desentendimento fez o pessoal do Linux pensar em uma ferramenta própria baseada no que eles tinham aprendido durante o tempo do BitKeeper.

Para alcançar o objetivo, traçaram algumas metas:

• Velocidade
• Design Simples
• Forte suporte a desenvolvimento não linear (milhares de branches trabalhando em paralelo)
• Amplamente distribuído
• Ter a capacidade de trabalhar com projetos do porte do Linux Kernel (afinal, foram eles que desenvolveram!)

Então, em 2005 nasceu o Git.

Apesar de ter várias semelhanças com o CVS e Subversion (entre outros), o Git é conceitualmente diferente. Explicando de uma maneira bem fácil de entender: o CVS trata a informação como uma série de arquivos que mudaram com o tempo. É assim que ele guarda as informações. O Git funciona um pouco diferente: em vez de guardar o arquivo propriamente dito, o Git tira uma “snapshot” de como o arquivo se parecia no momento. Esta informação é guardada. Em um caso onde algum arquivo não tenha sido alterado da versão A para B, ele não vai ser mantido duas vezes. Um link é criado de uma versão para outra. Seguindo na contramão dos controladores de versão, o Git não aproveitou o conceito dos seus antecessores criando o seu próprio.

Outro aspecto interessante do Git, é que em termos de velocidade ele também sai na frente. Uma vez que a maioria das operações são locais, não temos latência de rede. Um desenvolvedor pode dar commits de dentro de um avião por exemplo, e assim que conseguir uma conexão com a internet, pode fazer upload de suas alterações (isto sim é vantagem! hehehe).

Sobre segurança de informação posso destacar que o Git faz um controle baseado em checksum (SHA-1 hash) nas interações usuário x servidor, então é praticamente impossível alterar algo no servidor “despercebidamente”.

Vale falar também que a maioria das operações que o Git faz somente adiciona dados. Então, uma vez que a informação está no servidor, fica difícil perder algo – literalmente falando.

Mais um ponto que deve ser destacado: os três estados que um projeto pode assumir: commited, modified e staged.

• Quando você faz um commit no Git, significa que salvou seus arquivos no seu servidor local.
• Quando você faz um modify, significa que você fez alterações, mas estas ainda não estão salvas localmente.
• Quando um arquivo esta “staged” significa que você fez alterações (ou seja, esta com um arquivo modified) e estas estão prontas para serem comitadas na próxima iteração com o servidor.

Tendo explicado estes três estados, podemos entender mais facilmente as três seções de um projeto Git: o diretório Git (Git Directory), o diretório de trabalho (Working Directory) e o Staging Area.

• O Git Directory é o diretório mais importante. Nele ficam guardados os metadados e demais objetos relacionados ao seu projeto. Quando você clona um diretório de um computador para outro, este Git Directory é copiado.
• O Working Directory é um checkout de uma versão de um projeto. Os arquivos são extraídos do database do Git Directory e colocados em disco para que o usuário possa modificar.
• O Staging Area é um arquivo, normalmente dentro do seu Git Directory, que guarda informações que farão parte do seu próximo commit.

E agora, para fechar o artigo, vamos ver como ficaria o workflow de um projeto:

• Modificar arquivos no Working Directory
• “Stage” os arquivos, preparando o próximo commit
• Commit, onde os arquivos são resgatados da Staging Area e salvos no Git Directory.

Isto é o básico sobre a teoria do Git, um exemplo de Sistema de Controle de Versões Distribuído. Para usá-lo, existem duas saídas: ou usar o Git com linhas de comando, onde todo o set de comandos está disponível, ou então baixar um programa do tipo GUI, onde existe uma interface gráfica que implementa estes comandos.

No próximo post, vou mostrar um exemplo prático no mais famoso dos Gits, o Git Hub.

Fonte: https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git

SdevLab – Passo a Passo | Como Deployar (ou depurar) uma aplicação Java no Tomcat

Eae galera,

No post de hoje, vou mostrar mais uma dica de Java – vamos ver como deployar (ou depurar) uma aplicação Java no Tomcat. Pode parecer bobeira, mas deixa bastante gente na dúvida.

Boa leitura!

Deployando uma Aplicação Java no Tomcat

Para deployar uma Aplicação Java no Tomcat, é preciso ter uma aplicação já pronta, no formato WAR. Partindo do ponto que você já tem uma aplicação destas, e só não sabe como deployar, vamos aos passos:

1 – Pare o servidor Tomcat
2 – Com o Tomcat fora de serviço, cole o arquivo WAR na pasta “webapps” de seu Tomcat
3 – Abra um Prompt de Comando e navege até o diretório “Bin” do Tomcat – dentro do prompt
4 – Digite “startup.bat” no prompt.

Isto deve fazer com que sua aplicação seja deployada no servidor assim que o serviço iniciar. Se nenhum erro foi detectado, é possivel acessar a aplicação no endereço de ser server, por exemplo: http://localhost:8080/teste/.

Até a próxima!