Anexo: javascript.format.eclipse.xml

Um exemplo é o Java JDK, que (até a data desse post) já se encontra em sua versão 1.7.0, porém nos repositórios o openjdk disponível é o 1.6.

Outro exemplo é o Firefox, que, dependendo da versão do Ubuntu, se encontra nas versões 3.x ou 5.x e já está disponível a versão 6.0.

O problema se tornou crítico, quando tive alguns problemas no JDownloader com o JDK mais “antigo”. Então, busquei formas de atualizar a versão do java no sistema, sem provocar grandes problemas, pois se eu utilizava o APT pra desinstalar o JDK antigo, para fazer uma instalação manual, aquele programa sugeria desinstalar vários outros programas que dependem do JAVA, inclusive o JDownloader.

Foi então que descobri o update-alternatives, onde é possível definir alternativas para os programas instalados. De acordo com o help do comando, esse espera os seguintes parâmetros:

update-alternatives [<opção> ...] <comando>

O parâmetro <comando>, espera:

--install <link> <name> <path> <priority>
    [--slave <link> <name> <path>] ...
                           add a group of alternatives to the system.
  --remove <name> <path>   remove <path> from the <name> group alternative.
  --remove-all <name>      remove <name> group from the alternatives system.
  --auto <name>            switch the master link <name> to automatic mode.
  --display <name>         display information about the <name> group.
  --query <name>           machine parseable version of --display <name>.
  --list <name>            display all targets of the <name> group.
  --get-selections         list master alternative names and their status.
  --set-selections         read alternative status from standard input.
  --config <name>          show alternatives for the <name> group and ask the
                           user to select which one to use.
  --set <name> <path>      set <path> as alternative for <name>.
  --all                    call --config on all alternatives.

Mais detalhes do comando, digite man update-alternatives.

Sobre a solução encontrada, segue como atualizar o firefox e o jdk do java:

Java:

update-alternatives --install /usr/bin/java java /usr/lib/jvm/jdk1.7.0/jre/bin/java 3

Firefox:

update-alternatives --install /usr/bin/firefox firefox /usr/lib/firefox-6.0/firefox 1

Como visto anteriormente, o comando –install, espera os seguintes parâmetros: <link> <name> <path> <priority>

Então, no caso do java:

link: binário java, /usr/bin/java

nome: java

path: /usr/lib/jvm/jdk1.7.0/jre/bin/java

prioridade: nesse caso, como já tinha outro java, coloquei prioridade 3. Para verificar as alternativas já instaladas digite update-alternatives --display java

Créditos: http://balajitheone.blogspot.com/2011/08/installing-oracle-sun-jdk-17-on-ubuntu.html

Bom, não precisava pesquisar tanto, pois na própria documentação do Ubuntu, existe um tópico explicando como resetar a senha do usuário postgres.

Para versões novas do Ubuntu (8.10 acima), basta digitar no console:

sudo -u postgres psql postgres

Se estiver logado como root, o acesso será direto. Caso esteja com um usuário com direito de execução do comando sudo, você precisará digitar a senha desse.

Após isso, você já estará no console do PostgreSQL, bastando digitar

\password postgres

Será solicitada a nova senha e redigitação dessa. Para finalizar, digite o comando:

\quit

Para mais detalhes, acesse o site do Ubuntu.

Fonte: https://help.ubuntu.com/community/PostgreSQL

A grande vantagem disso é a facilidade de visualização das variáveis, trace exceções, mensagens de NOTICE, WARNING, PARSE ERROR, DEPRECATED, etc.

Muitas pessoas podem ter sofrido a mesma dificuldade que tive, ao habilitar essa funcionalidade. Apesar de as informações do PHP (phpinfo) mostrarem que a biblioteca está carregada, a saída do var_dump não vinha formatada. Após vários testes, seguir várias explicações, entre elas, uma sugeria definir o parâmetro “xdebug.trace_format=1“. Restartando o servidor web, as variáveis continuavam no formato padrão do PHP.

Inicialmente, eu pensei que o problema seria porque estou trabalhando com o Lighttpd e o PHP configurado para trabalhar em modo CGI (FastCGI). Isso ocorreu pois eu utilizava PHP como módulo do Apache e esse era meu servidor web. Ao migrar pra o Lighttpd, instalei o pacote php5-cgi (Debian/Ubuntu) e configurei as diretivas necessárias pra funcionar com aquele.

Felizmente, não há diferença, para essa funcionalidade, utilizar o PHP em modo FastCGI ou módulo do servidor Web. Mesmo se esse mesmo PHP fosse utilizado com o Apache em modo FastCGI, o problema persistiria, ou seja, o problema também não é o Lighttpd.

Quando instalamos o pacote php5-cgi, pelo menos nas distribuições Debian-like, as diretivas de configuração pra trabalhar nesse modo são dispostas em uma pasta separada, geralmente em “/etc/php5/cgi”. Na verdade, além de habilitar a extensão Xdebug, é necessário mudar uma diretiva do PHP, “html_errors”. Pelo menos no php.ini da opção CGI, essa estava desabilitada – html_errors = Off. Quando essa diretiva está Off/0 (zero) / false, o Xdebug não formata variáveis, trace de exceções e reporting de erros.

Portanto, se você está com esse problema, além de habilitar a extensão Xdebug (Veja o Post “Instalando o Xdebug no Debian/Ubuntu”), é necessário habilitar a opção html_errors.

Mas há momentos em que o modelo não representa uma entidade do banco. Por exemplo, pode-se usar o modelo para executar uma função, uma procedure ou uma consulta à uma “View” de banco. Trabalhando nessa estrutura, onde o modelo representa os dados persistidos no banco, esse paradigma é quebrado.

O Zend Framework é bastante flexível em vários quesitos; um deles é o quesito mapeamento de dados, é possível sobrescrever algums métodos da classe herdada (Zend_Db_Table / Zend_Db_Table_Abstract). Um desses é o método “_setupPrimaryKey”, responsável por instanciar a chave primária da tabela; metódo, também, responsável por gerar a exceção quando, no mapeamento, não é encontrada a chave primária à partir das colunas buscadas à partir de um describe da tabela. Todo esse processo é executado automaticamente pelo Zend_Db.

Para resolver esse problema, é necessário forçar o mapeamento manual de algumas variáveis utilizadas pela classe “pai”. Nessa situação, foi suficiente forçar a variável “$this->_cols” para um vetor vazio. Adicionalmente, foi informado como vazio o nome da tabela, porém a classe pai define como sendo o nome da Classe filha o valor dessa variável ($this->_name).

Portanto, para trabalhar nessa estrutura, onde o modelo não representa uma entidade no banco basta sobrescrever o método “_setupPrimaryKey”:

public function _setupPrimaryKey() {
$this->_cols = array();
$this->_name = “”;
}

Inicialmente, eu clonei o HD de 80 GB e esperei pra ver o que aconteceria. Infelizmente não deu muito certo. Como meu tempo era pouco, preferi reinstalar o S.O, mas o Debian continuava reconhecendo 2 HDs. Porém, nada como nosso parceiro Google e as palavras-chave corretas pra encontramos as respostas pra tudo. Encontrei várias soluções, inclusive algumas na verdade sugeriam RAID via Software. Mas um dos documentos foi muito útil. Esse documento, faz parte da Wiki do Debian¹.

Conhecido o cenário e o contexto, vamos à solução. Quando o instalador iniciar na tela onde se escolhe a opção de instalação – Gráfica, Modo Texto, Recuperação…. – basta teclar “TAB”, após isso, aparecerão as opções de boot do instalador. Ao final da linha de configuração do inicializador, digite a opção “dmraid=true”. Pronto! Agora o instalador reconhecerá apenas o disco em RAID.

Obs.: Essa configuração funcionou para o Debian e provavelmente vá funcionar no Ubuntu também. Outras distribuições podem ter essa opção também.

Simples, não?

1. Debian Wiki, acessado em 27/02/2010, http://wiki.debian.org/DebianInstaller/SataRaid.

Pra quem já teve a mesma dificuldade que eu, pra instalar o componente xdebug no PHP, vai ai uma ajuda e tanto. Como utilizo o repositório do Ubuntu pra instalar meus serviços e programas, passei por uma dificuldade com a instalação do componente xdebug.

Eu utilizo o ZendServer Community Edition – um Apache + PHP + Componentes básicos do ZendServer todos num pacote -, e nessa situação, executei o comando padrão: “aptitude install php-5.3-xdebug-zend-server“.

Ao restartar o Apache, a surpresa, o serviço não estava no ar e ao analisar os logs a mensagem, que “diz tudo” e não diz nada:

[notice] caught SIGTERM, shutting down

Pesquisando nas listas do xdebug, encontrei algo que poderia resolver meu problema. Mas antes, tentei mais uma opção, compilar a extensão com o phpize. Fiz o download da última versão do xdebug, e executei os seguintes comandos:

# sudo su
# wget http://xdebug.org/files/xdebug-2.1.0beta2.tgz
# /usr/local/zend/bin/phpize
# ./configure –enable-xdebug –with-php-config=/usr/local/zend/bin/php-config
# make
# cp modules/xdebug.so /usr/local/zend/lib/php_extensions/

Como já havia instalado o xdebug do repositório, ele criou em /usr/local/zend/etc/conf.d um link simbólico “xdebug.ini” para o arquivo “/usr/local/zend/etc/ext.d/xdebug.ini”.

Bom, o detalhe maior está nesse arquivo, portanto não precisávamos dessa etapa de compilação. A extensão instalada do repositório cria a seguinte diretiva:

zend_extension=/usr/local/zend/lib/php_extensions/xdebug.so

Dessa forma, a extensão não é carregada e para matar a charada, basta mudar de “zend_extension” para “extension”, portanto:

extension=/usr/local/zend/lib/php_extensions/xdebug.so

O trabalho de melhoria do PHP, deveria ficar a cargo da própria Zend em parceria com a comunidade, mas parece que eles estão sem tempo e mais interessados no mercado corporativo, com suas ferramentas de desenvolvimento, proteção de código e servidor, do que com o crescimento e melhoria da linguagem.

Mais detalhes estão disponíveis em: http://www.geek.com.br/posts/12221-facebook-reescreve-php-do-zero-e-pode-estar-desenvolvendo-um-compilador-para-a-linguagem

Basta editar o arquivo “/etc/vmware/config”, e inserir as seguintes diretivas:

xkeymap.nokeycodeMap = true
xkeymap.keycode.211 =  0×035

No meu caso, como eu já havia instalado o S.O, nesse caso um Debian 5.0, tive que reconfigurar o teclado. Para isso basta digitar no console:

dpkg-reconfigure console-data

e configurar no padrão brasileiro. No meu caso foi bem simples, basicamente “avançar-avançar-finalizar”.