Sérgio Berlotto - Site Pessoal : Nova arte…

Agora é a vez de um cartão de visita, ao estilo Arch, com direito a logo e tudo…

Segue o download do SVG para inkscape:

Detalhe, a fonte utilizada foi a Papyrus ( download aqui )

Você pode utilizar a vontade, somente alterando os dados ou até utilizando-o como base para um novo cartão. Se gostou deixe um comentário aqui !

Valeu

Arch Linux Brasil : netcfg v2.5.2 - Nota: Mudanças na configuração automática de Wireless

Esta release trás um mecanismo completamente novo de configuração automática de conexões wireless/cabeada. O antigo net-auto estava legado e não foi mais incluso. Existem também várias pequenas mudanças na configuração que podem afetar algumas pessoas.

Para a nova configuração automática de conexões wireless/cabeada O novo mecanismo de conexões automáticas trás um bom suporte a roaming e se mostrará mais confiável do que o antigo setup - em particular com configurações wireless mais complicadas. Para migrar para a nova configuração automática wireless siga:

1. pacman -S testing/wpa_action 2. Insira WIRELESS_INTERFACE="" para a sua interface wireless em /etc/rc.conf 3. Adicione net-auto-wireless em seu DAEMONS=().

Nota: Os perfis wpa-config não funcionam com isto, converta-os para perfis wpa-configsection. Um exemplo está incluído em /etc/network.d/examples/

A nova configuração automática de rede cabeada utiliza uma configuração similar - Siga as instruções que foram apresentadas, levando em conta que você irá utilizar o daemon net-auto-wired e a opção de configuração WIRED_INTERFACE.

Novas funcionalidades: - net-auto-wireless/wpa_action - Roaming wireless real/conexão automática. Baseado no mesmo princípio do autowifi. Requer dependências opcionais: wpa_actiond - net-auto-wired - configuração ethernet automática. Requer dependências opcionais: ifplugd - Configurações de Interface - Seta opções para todos os perfis utilizando uma interface - Outpu Hooks - Limpeza interna & melhorias

Mudanças internas: - Utiliza wpa_supplicant para todas as configurações wireless por padrão, incluindo wep/sem segurança. Estes adicionais melhoram o suporte para a maioria dos usuários e aumenta a confiabilidade. - Usa iproute por padrão para toda configuração estática. net_tools que contém o ifconfig é efetivamente obsoleto e ainda não foi visto algum lançamento por mais de 8 anos. O 'ethernet-iproute' e os tipos de conexão 'ethernet' foram unificados para simplesmente 'ethernet'. Toda as opções continuam sendo suportadas e as configurações existentes continuarão funcionando para ambos os tipos. Um link simbólico é criado para garantir que os perfis utilizando 'ethernet-iproute' continuarão funcionando.

Mudanças na sintaxe de configuração: - net-auto e AUTO_NETWORKS está agora depreciado em favor do net-auto-wireless/net-auto-wired. - wireless: se você estava previamente especificando o driver wpa_supplicant em WPA_OPTS, você agora precisa especificar em WPA_DRIVER. - wireless: configurações baseadas em iwconfig para wep/nenhum podem ser utilizados trocando para wep-old ou none-old. Isto não deveria ser necessário e é deixado no lugar apenas para a possibilidade de drivers muito antigos que não suportem wpa_supplicant. - ethernet-iproute: Como o 'ethernet' é agora baseado no iproute, aqueles utilizando 'ethernet-iproute' podem reverter o nome. Existe um link simbólico no lugar, portanto configurações existentes deste nome continuarão funcionando. - wireless-dbus: Não suportado. A interface dbus do wpa_supplicant em particular não está bem documentada e não se encaixa bem na base de código do netcfg. Existe um link simbólico no local para que as configuraçõesutilizando o wireless-dbus continuem funcionando utilizando os scripts de conexão 'wireless'.

Download: netcfg 2.5.2 está no [core] Fonte: ftp://ftp.archlinux.org/other/netcfg/netcfg-2.5.2.tar.gz PKGBUILD: No subversion

Documentação: http://wiki.archlinux.org/index.php/Network_Profiles

Contribuições: Temos alguns grandes contribuidores para esta release: Jim Pryor: Muitas modificações internas e melhorias Thomas Bächler: Auto roaming/conexão baseado no wpa_actiond Obrigado rapazes!

Bugs: No bug tracker como sempre.

Rodrigo Flores : Últimos acontecimentos

Pois é... faz tempo que não blogo . O final de 2009 e começo de 2010 foi bastante corrido: tive que terminar meu trabalho de conclusão de curso e comecei a trabalhar. Mas agora as coisas já estão mais calmas.

Finalmente me formei. Agora posso me declarar cientista da computação e já estou aprovado no mestrado, que começa mês que vem. Minha colação de grau foi na quarta feira e agora fico no aguardo da colação de gala, na qual irão meus familiares e amigos.

Em dezembro comecei a trabalhar. Estou trabalhando na agência de publicidade Sabbre fazendo o desenvolvimento de aplicações web com Ruby on Rails. Um trabalho que tem me dado motivos para gostar do que faço e que me tem feito aprender muitas coisas.

Infelizmente, tive que abrir mão de algumas coisas, principalmente de software livre. Saí da equipe de desenvolvimento do archlinux Brasil, pois não estava conseguindo tempo para me dedicar. Como não gosto de assumir compromissos que não posso cumprir, eu acabei optando por sair. Desejo boa sorte e muito sucesso a todas as pessoas que continuam por lá. Continuo agora só gerenciando a equipe de tradução do GNOME, que aliás já está em pleno ritmo de tradução para o GNOME 2.30.

Helio Costa - hlegius : Eu uso estático porque é mais rápido.

Ouvi e já pude ler isto não uma, nem duas, mas sim diversas vezes. Argumentação padrão de quem defende uma “Orientação à Objetos mais estática” – se é que podemos chamar isso de OO.

Vejamos um exemplo nada científico que fiz:

Criei os seguintes exemplos:

<?php
class Estatico {

    public static function fazAlgumaCoisa() {
        $i = 0;
        while ($i < 10000) {
           echo Estatico::outraCoisa();
           $i++;
        }
    }

    public static function outraCoisa() {
        return "Conteúdo";
    }
}

Estatico::fazAlgumaCoisa();

<?php
class Instancia {

    public function fazAlgumaCoisa() {
        $i = 0;
        while ($i < 10000) {
            echo $this->outraCoisa();
            $i++;
        }
    }

    public function outraCoisa() {
        return "Conteúdo";
    }
}
$objInstancia = new Instancia();
$objInstancia->fazAlgumaCoisa();

Os resultados após rodar quatro vezes cada foram:

Ou seja: 91.09 ms para o estático contra 90.07 para a versão non-static. Obviamente foi apenas um teste sem qualquer relevância, pois rodei em minha máquina pessoal com várias outras aplicações rodando em background. É perceptível porém, que a diferença não é absurda que compense o uso de estático por este motivo.

Deixando a questão de “performance” de lado, partimos para questões arquitetônicas:

• Identidade
• SoC – Separation of Concerns (Principio de Separação das Responsabilidades)
• Encapsulamento
• Estado
• DRY – Don’t Repeat Yourself
• Associações – sejam elas composições ou agregações

Ao perder Identidade e Estado as possibilidades daquele método – ou da classe inteira, caso use estático em tudo – tem o leque de utilidade reduzido para:

• Service
• Facade
• Factory
• Helpers – no âmbito de serem apenas funções que realizam determinada tarefa na aplicação sem qualquer valor ao Domínio

Com isso, perdemos também o Princípio de Separação das Responsabilidades, ou seja, a classe perde o controle sobre a integridade dos dados que ela deveria controlar e proteger contra acesso ou alteração indevidos.

Listei o DRY também por um motivo simples: com métodos estáticos, perdemos a grande chance de usar as variáveis de instância da classe à favor da mesma. Exemplo:

class UsuarioEstatico {

    public static function login($usuario, $senha) {
        // valida o usuário e zaz
        $autenticador = new Autenticador();
        $autenticador->autentica($usuario, $senha);
    }

    public static function logout($usuario) {
        // verifica se a sessao está aberta
        $autenticador = new Autenticador();
        $autenticador->fechaSessaoPara($usuario);
    }
}

class Usuario implements Autenticavel {
    private $autenticador;

    public function __construct($usuario, $senha) {
        // manipula os dados de entrada
        $this->autenticador = new Autenticador($this);
    }

    public function login() {
        return $this->autenticador->autentica();
    }

    public function logout() {
        return $this->autenticador->fechaSessao();
    }
}

Repare no modelo estático: foi necessário instanciar o antenticador por duas vezes em pontos diferentes. Opa, repetiu ! Mesmo que o autenticador fosse estático, teriamos duplicação, pois teriamos que certificar que o usuário existe e tudo mais. Isso porque não comentei como ficaria o lado cliente dessa implementação estática. O cliente – seja Controller, WebService ou qualquer classe em outra camada no domínio – teria que conhecer muita coisa sobre implementação dessa classe para poder manipulá-la.

Como bônus, repare que perdemos neste caso também o Polimorfismo, uma vez que eu poderia ter esse Autenticador() como base de autenticação para qualquer tipo (Usuário, Funcionário, Gerência, Administradores…)

O uso de métodos ou funções – sim, há diferença – estáticas pode ser bem-vindo nos itens já enumerados. Alguns developers porém, ainda que nestes casos são contra o uso por achar a ideia estática demasiadamente anti-oo.