All work and no play makes Jack a dull boy

quarta-feira, 29 de maio de 2013

Autenticação em Sites Django Utilizando Redes Sociais


Autenticação em Sites Django Utilizando Redes Sociais

Instrutor: Julio Cesar Martins


segunda-feira, 27 de maio de 2013

git reset {soft | hard | mixed} - como lembrar

Qual a diferença entre o soft, hard e mixed do commando git reset ? Veja um jeito fácil de lembrar. Bem, considere que você está trabalhando no seu código a partir de um git checkout . Então você segue trabalhando, coda, compila, testa e então faz  git add  e  git commit  Seria algo:
$ git checkout trampo
…. coda …. compila …. testa …
$ git add ….
$ git commit
Se nesse ponto você fizer um git reset , veja como cada tipo de reset afeta as coisas:
$ git checkout trampo
 # --hard fará o reset nesse ponto
…. coda …. compila …. testa …
 # --mixed (é o padrão) reseta nesse ponto
$ git add ….
 # --soft reset até esse ponto
$ git commit
Vale falar que o git commit --amend faz com que o git reset --soft se torne um tanto redundante.
{fonte}

domingo, 26 de maio de 2013

Como trocar a url de um repositório remoto Git

 git
Trocar a url do repositório remoto git? Sim, é possível!

Toda vez que clonamos um repositório local, a url clonada fica armazenada como "origin" no repositório local.

Como saber qual o remote do Git?

$ git remote -v
origin https://github.com/joncasdam/repositorio.git (fetch)
origin https://github.com/joncasdam/repositorio.git (push)

Mas se você quer ter mais informações sobre o "origin", por exemplo:
$ git remote show origin
* remote origin
  Fetch URL: https://github.com/joncasdam/repositorio.git
  Push  URL: https://github.com/joncasdam/repositorio.git
  HEAD branch: master
  Remote branches:
    dev    tracked
    master tracked
  Local branches configured for 'git pull':
    dev    merges with remote dev
    master merges with remote master
  Local refs configured for 'git push':
    dev    pushes to dev    (up to date)
    master pushes to master (local out of date)

Agora, se você precisa trocar a url do repositório, há um comando no git que permite fazer essa alteração:
$ git remote set-url origin https://github.com/user/repositorio.git

agora confirme a alteração:
$ git remote -v
origin https://github.com/user/repositorio.git (fetch)
origin https://github.com/user/repositorio.git (push)
pronto!

quinta-feira, 16 de maio de 2013

Apache: Could not bind address to port (make_sock)

Um tanto em função do último post, passei por uma situação bem semelhante ao post abaixo que resolvi traduzi-lo.
--
Se você está atualizando software ou alterando a configuração das portas, provavelmente dará de cara com esse erro ao tentar reiniciar o Apache.

O Apache está tentando 'ouvir' (Listen) a porta 8080, um exemplo, mas não consegue porque já está em uso. Eis algumas razões pelas quais isso pode acontecer.

Problema de configuração da porta
Se tiver entradas duplicadas para Listen, o Apache irá reclamar. Certifique-se que seu apache.conf e ports.conf NÃO tenham ambos essa diretiva. Se ela for listada apenas uma vez (veja o exemplo do arquivo ports.conf abaixo), então verifique se acidentalmente você não duplicou inadvertidamente seus ports.conf em algum lugar do seu Apache

NameVirtualHost *:81

Listen 81

<IfModule mod_ssl.c>
    Listen 443
</IfModule>

<IfModule mod_gnutls.c>
    Listen 443
</IfModule>

Vale também dar uma olhada nas configurações de seus Virtualhosts, pois já vi a declaração Listen ser feita junto dos VirtualHosts, então, se for o caso, veja em apache2/sites-enabled.

Outro servido pode estar usando a porta
Quando me deparei com esse erro, foi porque outra instância do apache já estava usando-a. Esse próximo exemplo usa netstat, grep e kill para resolver o problema.

$ netstat -tulpn | grep :8888

Que retornará:
tcp   0   0 0.0.0.0:8888    0.0.0.0:*     LISTEN      30661/apache2

Então faça:
$ sudo kill -9 30661 (ease é o PID que aparece para a instância)

Lembre-se que você deve investigar e avaliar problemas no servidor antes de simplesmente reiniciá-lo. Dei o boot quatro vezes antes de assumir que eu deveria ter errado em algo.

terça-feira, 14 de maio de 2013

Mais de um apache no servidor

 Você sabia que é possível ter múltiplas instâncias de apache no seu servidor? Sabia que ter 2 apaches no servidor (ou mais) já é algo previsto e préprogramando pelo próprio Apache?

Sim! Porém, antes é bom pensar: por que precisamos rodar múltiplas instâncias do apache no host?

Boa pergunta, afinal, com uma boa configuração em VirtualHost, você consegue ter tudo bem separado e organizado. Contudo esse caminho pode, com o tempo, te levar a um servidor pesado e lento.

Imagine que você trabalhe com diferentes sites, com requisitos distintos: um com mod_python outro com mod_php e etc); você configuraria isso tudo em uma instãncia apache, mas como resultado teria  grande consumo de memória.

Uma solução provida pelo próprio apache é ter configurações mais leves e separadas para, por exemplo, cada mod, usando portas diferentes.

E como fazer? Não precisa fazer uma série de sudo cp em tudo que é pasta.
$ sh /usr/share/doc/apache2.2-common/examples/setup-instance NOMEDAINSTANCIA