Comecei na sexta, publicando o Domain Manager, esse inclusive foi o maior incentivo para iniciar minha jornada por lá, como disse neste post, nunca havia recebido tantas solicitação nos mais diversos meios digitais que participo. O Domain Manager já ultrapassou os 120 downloads, em uma semana. Isso pra mim é um retorno incrivel.

Em seguida publiquei dois plugins simultaneamente, Custom Report for Cforms2 e Custom Background. O primeiro é um plugin do plugin, Cforms2 que constrói fomulários dinamicos, gravando em banco ou enviando por email. Sentia falta da possibilidade de poder gerar CSV em formatos específicos, como data, campos, ordenação, etc.

Além da falta de relatórios, sempre perdia um tempo enorme para configurar expressões regulares, mascáras de formatação ( CEP, telefone, CPF), dessa forma fizemos um guideline com os principais campos criados, basta um Control C + Control V.

Já o Custom Background tráz como diferencial a possibilidade de poder associar um background específico para uma determinada categoria do Wordpress.Veja como background toda área por tráz do container principal. Pode ser utilizado para patrocínios de áreas determinadas de um site, ele também aceita tags de Openx na versão 1.5.

A dupla de Custom também já acumula mais de 120 downloads, na semana, juntos. Tenho mais alguns plugins desenvolvidos que estou “encapsulando” para publicar.

Gostei da brincadeira

Contudo, existe uma grande diferença entre a estrutura de clouding e uma estrutura tradicional baseada em hardware. Vamos desconsiderar a capacidade do hardware, assumindo que uma máquina com a configuração X na cloud computing equivale a mesma máquina X em uma estrutura de hardware.

Para mim, as maiores vantagens vem sendo o auto-escalonamento, o armazenamento de dados estáticos na CDN S3, o balanceamento, o extinção de manutenção de hardware e o custo.

Para não nos confundirmos, o tema é muito abrangente, existem varias nuances que podem fazer toda a diferença na construção dessa topologia. A idéia dessa série de posts é ilustrar uma infra estrutura de múltiplos serviços – todos baseados em wordpress – com uma audiência média de 250.000 acessos diários, 1.800.000 de page views por dia, e um peso médio de 600kb por página entregue, com um custo total de hospedagem de R$ 5.000 mensais. Em seguida abordarei as vantagens citadas, no parágrafo anteriror, demonstrando o ganho de performance, escalabilidade e facilidade de manutenção dessa estrutura.

O primeiro passo para a criação de uma estrutura no AWS é a criação de uma AMI (Amazon Machine Image), máquinas clones – fundamentais para o escalonamento – só podem ser geradas a partir de instâncias do tipo EBS (Elastic Block Storage) dessa forma o ideal é selecionar alguma AMI pública – da própria Amazon – que contenha apenas o OS instalado – eu costumo utilizar o Fedora 8 32 ou 64 bits dependendo do tipo de processamento da instância.

1 - Criando instâncias

Na imagem ao lado, apenas a terceira instância, pode gerar uma AMI, pois ela é do tipo EBS.

Dessa forma, após criar sua instância EBS, configurar a máquina com os serviços necessários, com tudo rodando. Você pode ir para o próximo passo que é gerar a AMI – clone – das suas máquinas de serviços.

Para criar sua AMI selecione a instância geradora e no menu acima selecione a opção Create Image (EBS AMI) – figura 2. Você também pode criar AMIS no S3, mas vamos nos concentrar no EBS. AMI’s também podem ser públicas no EBS ou S3, mas no exemplo seria uma AMI privada.

2. Craindo uma AMI

No exemplo – figura 3 -  foi criada uma AMI com: Fedora 8 32bits, Apache 2.2, PHP 5, MySQL. O webserver foi configurado, com seus virtual hosts necessários, e existe uma instalação do WP 2.92 e outra do WP  MU 2.92. Esse é apenas um exemplo fictício para explicar a crianção de uma AMI, fundamental para quem pensa em auto-escalonamento.

No entanto, apenas a AMI em si não é suficiente para pensarmos em distribuição e sincronização de dados, arquivos estáticos, balanceamento, etc. Na figura principal do post uma AMI estão dentro de TODAS as instâncias sendo ela de Banco de Dados, Cache, Webserver, Storage, etc.

3. AMI Criada

Ainda dentro do modelo proposto, no exemplo, devemos criar AMI’s curingas, que tenham todos os serviços, menos banco e cache, AMI’s de Banco de Dados, e AMI’s de cache, nesse caso memcache.

Essa é o primeirissímo passo para quem deseja ter uma infra estrutura baseada em Cloud Computing. No próximo post avançaremos no sentido de criar o primeiro balance de serviços, conectado a uma infra de banco e CDN S3. Nunca fugindo do conceito, em demonstrar a capacidade da Cloud Computing trabalhar com o Wordpress para criar uma infra-estrutura auto escalonável.

Apesar de estarmos falando em Wordpress, não estamos nos limitando a falar de blogs e sim, portais, blogs, hotsites, ad server, etc.

]]> http://reflexoesdigitais.com.br/diversos/cloud-constructor-uma-topologia-para-sites-de-grande-audiencia-parte-i/feed/ 1 http://reflexoesdigitais.com.br/novidades/domain-manager-faca-o-download/ http://reflexoesdigitais.com.br/novidades/domain-manager-faca-o-download/#comments Fri, 12 Mar 2010 01:30:36 +0000 Diego Cox http://reflexoesdigitais.com.br/?p=632 Nunca recebi tantos pedidos no meu blog, também nunca tinha desenvolvido um plugin tão estratégico para usuários do Wordpress MU. Depois que publiquei esse post, não parei um dia se quer de receber pedidos, por comentários, e-mail, twitter e afins.

Na época do post, esse plugin ainda era muito embrionário, funcionava bem apenas em um ambiente muito específico. Já submeti o plugin para download no wordpress.org/extend.

O primeiro Alerta: Se você utiliza um servidor compartilhado, não utilize o reload automático, e veja como vai controlar a criação de vhost e reload do webserver.

Vamos instalar o plugin – Domain Manager.

1. Plugin
1.1. Faça o upload do plugin com o modulo de restart para pasta /wp-content/mu-plugins/
1.3. Passe o modulo para root chown root /mu-plugins/domain
1.3. Passe o modulo para 777 chmod +x /mu-plugins/domain
1.4. Crie um DNS “A” apontando para o ip da maquina host – todo novo domínio deve ter uma entrada do tipo A no seu servidor de DNS

Segundo Alerta – O Domain Manger funciona de forma automática apenas no OS Fedora, não que ele não possa ser utilizado em outros OS. Mas, nesse caso, o arquivo vhost.conf deve ser editado manualmente, assim como o reload do Apache. Dessa forma, na explicação abaixo tudo que diz respeito a APACHE, se não for aplicado em um OS Fedora com APACHE 2.2, deve ser feito manualmente.

OBS: Caso não queira utilizar o reload automatico do APACHE não é necessário fazer o upload do módulo domain.
OBS2: Outra opção é criar uma rotina no cron para o reload do APACHE em um intervalo determinado de tempo.
OBS3: Querendo você pode mudar a parte de ligação com o APACHE para conectar no seu webserver. Também funciona em lighthttp.

2. Apache
2.1 Edite o arquivo /etc/httpd/conf/httpd.conf
Adicione na ultima linha include /etc/httpd/conf/vhosts.conf – Todos os seus Virtual Hosts serão chamados desse arquivo.

2.2 Edite o arquivo /etc/init.d/httpd – Caso não queira utilizar o restart automático do Apache, desconsidere essa parte.

Edite a função start() adicionando a linha do mysql alterando as informações de acordo com a so seu banco –user, –pass, –database
”
start() {
…
mysql –user=<usuario_db_wordpress> –pass=<senha_db_wordpress> –batch –raw –silent –database=<db_wordpress> –execute=”SELECT container FROM vhosts WHERE active = 1″ –skip-column-names>/etc/httpd/conf/vhosts.conf
LANG=$HTTPD_LANG daemon –pidfile=${pidfile} $httpd $OPTIONS
…
}
”

Agora, para utilizar o plugin basta ler o post anterior.

Ficam os agradecimentos, claro que não fiz tudo sozinho, Ricardo Lanes – o super desenvolvedor da – parceira – Blogfarm e Guilherme Neumas – o ninja do Esporte Interativo. A mão dessa galera vale ouro, o cérebro nem comento!!!

Sim claro, faça o DOWNLOAD aqui.

Dúvidas, elogios, xingamentos, é só escrever ali embaixo nos comentários que vamos trocando. A idéia é sanar todas as dúvidas nos comentários, afinal a sua dúvida pode ser a mesma de outra pessoa e vice-versa.

O Domain Manager funciona – muito bem – com o Domain Mapping – plugin do aclamado Donccha – que faz o caminho inverso, permitindo que vários domínios trabalhem com um mesmo blog.

Por fim, fica um disclaimer, não há garantias que o plugin irá funcionar no seu ambiente. É preciso ter alguns tipos de acesso a configurações do APACHE e PHP que muitas hospedagens não permitem. Estou utilizando ele numa estrutura AWS, com Fedora 8, com 4 máquinas em balance. Utilizo o Fedora 8 64 bits, hospedando mais de 32 sites. Já vi funcionar também em ubuntu, mas ser o reload automatico, pois ainda não foi desenvolvida a função de reload para esse OS.

Durante o ciclo de vida do projeto, o grau de influência e autoridade das partes interessadas podem variar, dependendo da fase que esteja e, em geral, sua atuação é mais acentuada nas fases definição e planejamento.

1. Abordagem no Gerenciamento de Stakeholders

A maioria das organizações que empreendem novos projetos, independentemente do motivo, aborda os stakeholders de forma incompleta, concentrando suas preocupações nos envolvidos mais imediatos como, por exemplo, usuários, patrocinadores e equipe do projeto. Com o passar do tempo, percebeu-se que essa limitação era fator muito importante no sucesso ou fracasso do projeto e o conceito foi ampliado para abranger mais partes interessadas externas à organização como órgãos governamentais, reguladores e a sociedade civil.

Conforme vamos ampliando nossa consciência em relação aos impactos que um projeto pode ter sobre a realidade em que vivemos, cresce a importância de haver uma metodologia de abordagem para com cada uma das partes que irão ser influenciadas pelo trabalho do projeto e pelo produto gerado a partir desse trabalho.

Cada novo conhecimento requisitado pelo planejamento do projeto implica no envolvimento de um novo stakeholder e esta nova parte necessita ter seus anseios, suas necessidades e restrições compreendidas e incorporadas ao planejamento do projeto como um todo. De outra forma, o projeto não terá o resultado esperado, mas isso não significa que apenas o bom gerenciamento dos stakeholders poderá garantir o sucesso ou fracasso do projeto.

Portanto é importante que o gerente de projetos conheça detalhadamente os stakeholders. Para minimizar uma possível falta de entendimento, é importante que seja feita uma rodada de entrevistas com todos os stakeholders do projeto. Situações podem não permitir que todos sejam entrevistados, então os mais influentes devem ser priorizados. Perguntas que podem ajudar na montagem do plano de gerenciamento de stakeholders:

• Como você vê sua participação no projeto?
• O que você deseja que seja feito durante o projeto?
• Que tipo de informação quer receber, com que freqüência e de que forma?
• Existe algum item que considere importante e que ainda não tenha sido abordado?

1.1 Classificação dos stakeholders

Sabendo da natureza diferenciada de cada uma dessas partes componentes do projeto, precisamos definir diferentes estratégias de abordagem para cada uma delas. Primeiramente, precisamos definir os stakeholders-chave em um projeto:

Equipe do projeto: técnicos e conhecedores do negócio unem seus conhecimentos para definição e construção de um produto.

Usuários: quem vai efetivamente utilizar o produto do projeto.Sua contribuição é fator decisivo no sucesso ou fracasso do produto final de um projeto. Deve-se levar em consideração suas necessidades e suas relações com o meio em que se encontram e no qual irão utilizar o produto.

Sponsor: tem o comprometimento organizacional num projeto. Precisa ter grande influência na organização e auxilia o gerente de projetos quando decisões fora de sua alçada precisam ser tomadas. A Mobilização de pessoal-chave, resolução de conflitos e a estrutura organizacional do projeto são algumas de suas atribuições. Os sponsors são muito requisitados nas fases iniciais do projeto, mais especificamente definição e planejamento do mesmo.

Consultores especializados: não fazem parte da equipe do projeto, mas detêm conhecimento técnico ou de negócio que vai influenciar no planejamento, execução e controle do projeto.

Influenciadores: auditorias, legislação, sociedade, órgãos reguladores são alguns dos stakeholders que podem influenciar no projeto.

Financiadores: responsáveis pelo sucesso do projeto. Dão suporte e apresentam restrições ao gerente e sua equipe.

Clientes: apesar de não terem responsabilidade sobre a execução do projeto, tem grande interesse no produto final gerado pelo mesmo.

Gerente do projeto: responsável pela orquestração do projeto, especialmente pelo dia-a-dia do planejamento e por sua execução e controle.

Outros exemplos de stakeholders:
· Gerência Executiva;
· Outros projetos;
· Sindicatos;
· Associações;
· Família;
· Gerações futuras.

A figura a seguir mostra as principais partes interessadas em um projeto:

Figura 2 – Partes interessadas de um projeto Fonte: PMBOK 2004

Depois disso, é importante descobrir qual é a importância e o interesse de cada um deles no projeto. Uma sugestão para isso é a criação de uma tabela onde serão mapeados todos os stakeholders de acordo com o nível de impacto em cada um deles:

Tabela 1 – Classificação dos stakeholders do projeto Fonte: do autor

1.2 Definição da abordagem

O mapeamento anterior vai nos ajudar a definir, de acordo com o grau de influência de cada um dos stakeholders, qual a melhor forma de abordá-los sempre tendo como linha guia o sucesso do projeto. Estaremos considerando que o sucesso do projeto de que aqui falamos representa o objetivo definido pela alta gerência da empresa durante seu planejamento estratégico traduzido em ação.

Para isso, vamos utilizar um gráfico de interesse X importância, onde cada quadrante indica a forma de atuação.

2. Definição do trabalho dos stakeholders

Cada parte interessada tem um trabalho a desempenhar em um projeto. A definição do escopo deve levar em consideração todas as partes integrantes e o trabalho que cabe a cada uma delas a fim de se conhecer toda a extensão do trabalho do projeto.

Conhecendo a dinâmica de influências de cada uma dessas partes, podemos traçar um plano de trabalho incluindo as atividades a serem executadas, responsável e prazo para execução. Essas atividades farão parte do cronograma do projeto e precisarão ser controladas,  realimentadas e corrigidas quando necessário.

3. Comunicação com stakeholders

Influenciado pela diversidade nos vários tipos de stakeholders envolvidos em um projeto, um plano de comunicação deverá ser desenvolvido indicando como, com que periodicidade, tipo e nível de informação deverá ser comunicado o projeto.
Esse plano deverá ser desenvolvido nas fases iniciais do projeto e deverá assegurar a maximização da utilização das influências de cada stakeholder no momento certo. Para isso, é necessário realizar uma divisão dos stakeholders com necessidades de comunicação semelhantes e isso pode se desdobrar em 3 partes:

Obrigatórias: geralmente estas incluem relatórios de andamento (Status) do projeto, exigências jurídicas, relatórios financeiros, etc. Essas informações são levadas aos receptores.

Informativas: Estas são informações que as pessoas querem saber ou que elas podem precisar em suas atividades. Essas informações são normalmente disponibilizadas por escrito, mas requerem que as pessoas tomem a iniciativa de buscá-las.

Marketing: Esta comunicação é projetada para promover o comprometimento, o entusiasmo sobre o projeto e os deliverables do projeto. Esse tipo de informação é levado às pessoas apropriadas. Para os projetos que requeiram mudanças de cultura da organização ou de hábitos de trabalho, você também poderá criar e divulgar uma marca ao projeto.

4. Conclusões
As relações dos stakeholders com o meio em que se encontram podem influenciar um projeto de várias maneiras. É importante entender essas relações e como tirar o melhor de cada uma para a condução ótima do projeto.

Essas relações nos levam a adentrar no mundo das comunicações, em seus vários modos e os diferentes níveis. Não nos é possível falar de gerenciamento de stakeholders sem nos remeter aos conceitos-chave da comunicação, sem perceber a necessidade de construir um plano de comunicações eficiente e que promova a melhor utilização destes recursos.

As estatísticas nos mostram que a boa comunicação em um projeto requer aproximadamente 90% do tempo do gerente de projetos. Se comunicar é indispensável para a abordagem a stakeholders, consideramos que o bom gerenciamento dos interessados é um ponto de suma importância para o sucesso do projeto, em qualquer contexto.

Referências Bibliográficas

• VEM CONCURSOS – acessado em 22/06/2007.
• FGV – IDENTIFICANDO E CATEGORIZANDO STAKEHOLDERS EM UMA INSTITUIÇÃO FINANCEIRA -  acessado em 22/06/2007.
• MYLIUS E MARODIN – A FIGURA DE UM STAKEHOLDER EM UM PROJETO -  acessado em 22/06/2007.
• BLOG TENSTEP – acessado em 22/06/2007.
• WIKIPÉDIA -  acessado em 22/06/2007.
• GALEATO, RODRIGO – Stakeholders e sua importância no projeto(2007) -  acessado em 22/06/2007.
• PROJECT MANAGEMENT INSTITUTE – PMBOK ® 2004 – 3ª EDIÇÃO

Sempre vale a pena avaliar quais os pontos estão funcionando bem e quais devem ser aprimorados.

O Scrum é uma metodologia iterativa que deve ser implementada aos poucos para evitar choques culturais, mas é importante chegar rapidamente a um ponto de maturidade para o processo não sofrer uma involução e começar a andar para trás.

Check Rápido

Preenchendo os requisitos abaixo, não é necessário preencher o resto do teste, o Scrum está mostrando os resultados esperados dentro da sua empresa.

( ) Entregando software funcional e testado a cada 2-4 semanas

( ) Entregando as funcionalidades de maior valor para o negócio

( ) O processo está em constante evolução

Check Completo

Caracteristicas fundamentais do Scrum, caso elas não estejam implementadas e funcionais não é possível garantir que o Scrum esteja funcionando da forma correta

( ) A função do Product Owner (PO) está claramente definida

• ( ) O PO está priorizando as demandas coerentemente
• ( ) O PO tem o conhecimento claro das prioridades do cliente
• ( ) O PO tem contato direto com o time
• ( ) O PO tem contato direto com os steakholders
• ( ) O PO escreve histórias claras

( ) O time possui um Sprint Backlog

• ( ) Claramente Visível
• ( ) Atualizado diariamente
• ( ) Administrado exclusivamente pelo time

( ) Daily Meeting acontecendo diariamente

• ( ) O time todo participa
• ( ) Problemas e impedimentos são revelados e resolvidos

( ) Demonstração de funcionalidades nos Reviews

• ( ) O time demonstra software funcionando e testado
• ( ) Feedback do PO para o time

( ) Possui a definição de feito

• ( ) A definição de feito é revista a cada iteração
• ( ) O time respeita a definição de feito

( ) A Retrospectiva é feita ao final de cada Sprint

• ( ) Resultados concretos nas melhorias propostas
• ( ) Algumas propostas já foram implementadas
• ( ) Participação de todo o time + PO

( ) O PO possui um Backlog do Produto (Product Backlog)

• ( ) dois ou três sprints pré priorizados a partir do valor de negócio
• ( ) dois ou três sprints com as complexidades estimadas
• ( ) As estimativas são feitas pelo time
• ( ) Os itens Top cabem em um sprint
• ( ) O PO entende todas as histórias do backlog

( ) Reuniões de Sprint Planning

• ( ) O PO participa
• ( ) O PO define a data fim do sprint
• ( ) Todo time participa
• ( ) O Sprint Backlog sempre é definido
• ( ) O time acredita no backlog comprometido
• ( ) O PO fica satisfeito com o comprometido

( ) Iterações “Time-Boxed”

• ( ) Os sprints demoram no máximo 4 semanas e no mínimo 2 semanas
• ( ) O sprint sempre termina na data estipulada
• ( ) O time não perde o foco nem é afetado por acontecimentos ou demandas externas
• ( ) O time sempre entrega o que foi comprometido
• ( ) Raramente um Sprint é cancelado e reiniciado

( ) O time trabalha – fisicamente – junto

• ( ) O time tem no máximo 9 e no mínimo 5 membros

Check Adicional

Algum pontos não obrigatórios, mas recomendados para o bom funcionamento do Scrum.

( ) O time tem as especialidades necessárias para finalizar os itens do backlog

( ) Os membros dos times não estão limitados a especialidades específicas

( ) O PO tem a visão do produto em sintonia com o Backlog do produto

( ) O Backlog e a Visão do produto estão claramente visíveis

( ) Todos no time participam das estimativas

( ) O PO está sempre disponível durante as estimativas

( ) A estimativa do grau de complexidade são definidos pelo time

( ) Todo o time tem conhecimento dos três principais impedimentos

• ( ) O Scrum Master (SM) tem estratégias para resolver os principais impedimentos
• ( ) O foco principal do SM é resolver impedimentos
• ( ) Os impedimentos são escalados para a gerência quando não resolvidos

( ) O time tem um Scrum Master (SM)

• ( ) O SM trabalha – fisicamente – perto do seu time

( ) Histórias do Backlog são quebradas em tarefas quando entram no Sprint

• ( ) As tarefas são estimadas
• ( ) As tarefas são atualizadas e acompanhadas diariamente

( ) A velocidade está sendo mensurada (número de pontos por Sprint)

• ( ) As histórias priorizadas no Sprint Planning já estão estimadas
• ( ) O PO utiliza a velocidade mensurada para planejar entregas
• ( ) A velocidade mensurada inclui apenas histórias feitas

( ) O time tem um gráfico burndown

• ( ) Visível a todos
• ( ) Atualizado diariamente

( ) O Daily meeting é feito diariamente, no mesmo horário e local

• ( ) O PO sempre participa
• ( ) O tempo máximo de duração é de 15 minutos
• ( ) Todo o time participa
• ( ) Todos dizem o que fizeram
• ( ) Todos dizem o que irão fazer
• ( ) Todos dizem o que está impedindo

Expandindo o Scrum para toda a empresa

Algun intens importantes para empresas que trabalham com mais de um time, PO e SM

( ) Existe um Product Developer ( para empresas com vários PO’s)

( ) Times dependentes realizam o Scrum of Scrum

( ) Times dependentes participam do Sprint Planning de outros times

Indicadores de Sucesso

( ) Todos os envolvidos estão satisfeitos com a metodologia

( ) Todos os envolvidos estão satisfeitos com os resultados

( ) Horas extras são raras e voluntárias

( ) O processo está gerando discussões, críticas e novos experimentos

O teste proposto não tem pontuação – é uma checklist -, quantos mais itens estiverem implementados, mais o Scrum estará funcionando dentro da sua corporação, esse check deve ser feito periodicamente e os itens que não estiverem implementados devem ser revisto com atenção. O check original foi publicado aqui, eu apenas traduzi e inclui alguns itens que considero importante para o sucesso do processo.

Não demorou muito, primeiro o UOL Notícias replicou o modelo, em seguida veio o Terra e, logo após o iG. Analisando esses portais fica muito claro a inspiração adquirida no portal global, as marcas do UX da globo.com estão presentes em vários aspectos nos portais citados.

Ontem foi lançado o R7, portal da Rede Record de TV, nesse projeto – em particular – é onde a inspiração global e a tendência lançada em 2007 estão mais presentes. Começando pelo nome que é uma grande alusão ao G1, portal de notícias da CGJ. Chega a ser curioso a composição desses nomes, na Globo G1 significa Globo 1, o pólo central do jornalismo ágil, dinâmico e participativo. Já o R7 – Record 7 – Significa notícias 24 horas por dia 7 dias por semana, sempre “frescas”e de primeira mão, pregando o jhornalismo contínuo e incessável.

A parte de Arquitetura da informação, dispensa comentários, é uma cópia escarrada do portal da Globo. Há alguns anos atrás não duvidaria de que a Record teria tirado profissionais da globo.com para contruir seu portal. Mas, dentro da realidade, isso pode ser feito sem nenhum ex-profissional global envolvido. Com um firebug, e alguns outros add-ons é possível “sugar” todo e qualquer arquitetura e layout de um portal on-line.

Para sua logomarca a Record buscou “inspiração” em outra URL – no Meme – da gigante Yahoo!, fica díficil encarar que qualquer semelhança é mera coincidência. Vejam as duas marcas e tirem suas próprias conclusões.

Mas o objetivo desse post não é vitimizar a globo.com, como plagiada, tampouco acusar a Record e os outros portais citados como plagiadores.

A grande questão é: por que veículos de porte tão grande, não criam sua própria identidade, seus própios padrões e seu próprio mundo. Por que dentro da história da internet, poucos lançam tendêncuas e tantos as copiam.

Outra questão: é positivo ou negativo ser copiado? Do ponto de vista positivo mostra a qualidade do produto lançado e a criação de um padrão genérico, a ser seguido pela concorrência. Pelo ponto de vista negativo, onde a percepção da falta de criatividade da concorrência é uma ameaça para as nova tendências que essa empresa almeja emplacar, assuta.

Penso que não existe lado certo ou errado, a mensagem principal dentro de todo esse conceito é que empresas como a globo.com conduzem a internet para a frente, enquanto que aqueles que copiam, pouco ou muito, estão de alguma forma correndo atrás de um prejuízo e certificando que a visão inovadora da sua concorrente tem mais futuro do que a sua própria visão.

Finalizando, ontem a Record abriu mais uma frente na sua incansável batalha com a TV Globo. A internet foi o último porto conquistado pela Record, na sua tentativa de consolidar sua superioriedade e conquistar o topo da mídia de massa no Brasil. Enfim, essa é uma outra estória, muito mais longa, complexa e sombria.

Agora é esperar a globo.com se reinventar e assistir – novamente – a adaptação da concorrência ao novo padrão.

Dessa forma, considerando:

PV - Impressões mensais de páginas

KB – tamanho em kb médio do arquivo de uma página.

PV * KB = X/1milhão

Os Page Views mensais você encontra no seu sistema de métricas, o Google Analytics, por exemplo. O tamanho médio de sua página pode ser visto aqui.

Exemplificando:

• Um site com 1,5 milhões de page views por mês.
• Com páginas na média de 500Kb
• Consome: 750 GB de Transfêrencia OUT – Download.

O consumo de transferência do tipo IN -Uploads varia de acordo com o que é uploaded para o servidor. Inclusãoes de artigos, fotos, vídeos, etc consomem esse tipo de banda. De qualquer forma, a transferência IN é sempre mais barata que a OUT e seu volume não ultrapassa os 5% do consumo OUT.

O site exemplificado acima, teria um consumo de transferência IN médio de 7,5GB a 37,5GB.

Foram duas baterias de testes com alguns perfis diferentes para testar quão efetiva é a utilização de um cacheamento abrangendo camadas de cada sistema (Expires, APC, Query Cache) e os Caches padrões do Wordpress (Supercache e Widget Cache).

Fiz uma instalação de Wordpress MU em um servidor com as seguintes características:

Hardware

• CPU – dual core 1Ghz
• Memória – 1.7GB
• HD – 160GB

Sistema

• Apache 2.2.2 – Headers Expires
• PHP 5.0 – APC Cache ativo
• MySQL – 5.0 – Query Cache Ativo
• Armazenamento de dados estáticos (imagens, videos, audios, .js, .css) armazenados remotamente.
• Wordpress – WPMU 2.84, Supercache e Widget Cache
• Plugins – +- 15 ativos
• Mu Plugins: +- 5 ativos + Domain Manager
• Blogs Ativos: 5 Blogs
• Captcha nos forms – Cacheado.

De fato trata-se de um Hardware bastante limitado mas ideal para um pequeno teste de estresse para entender melhor como tudo funciona junto. Realizei dois testes num site – bem bacana. O teste analisou o tempo de carregamento (User load time) da página no browser do usuário, com a profundidade de até 5 páginas + 2 interações – Comentários, buscas, etc – por visita. Além do Load Time o teste também analisou o consumo de banda, a qualidade dos códigos carregados, tamanho de imagens + tempo de carregamento, e de outros arquivos como .js, .php e .css.

Cada teste foi feito em 5 etapas começando por 10 usuários simultâneos e chegando a 50 usuários. Um volume não muito grande, compatível com sites que recebem cerca de 30 a 50 mil usuários por dia, ou mais chegando no máximo a 100 mil usuários por dia.

Do outro lado, enquanto os testes de estresse eram executados, fiquei monitorando o consumo do CPU, conforme Imagem 1, a seguir detalharei os dois testes, passo a passo, e suas particularidades que influenciaram diretamente nos resultados.

Teste 1

• Perfil 10 usuários - O WP estava sem cache algum, tempo médio de carregamento foi de 12.9 segundos.
• Perfil 20 usuários – O WP continuava sem cache algum, tempo médio de carregamento foi de 32.3  segundos.
• Perfil 30 usuários – O Supercache foi ativado, tempo de carregamento 45.3 segundos, navegação inaceitável, impossível postar qualquer tipo de informação.
• Perfil 40 usuários – O Supercache continua ativado e o Widget Cache é ativado, carregamento 27.9segundos , nesse ponto o site volta a ficar navegável, mas muito lento.
• Perfil 50 usuários – Todos os caches ativados (SC e WC), carregamento 32.7 segundos, o site continua lento mas navegável.

Teste 1 - Caches ativados com 30 usuários

Teste 2

• Perfil 10 usuários – Todos os caches ativados, carregamento 5.19 segundos.
• Perfil 20 usuários – Todos os caches ativados, carregamento 9.64 segundos.
• Perfil 30 usuários - Todos os caches ativados, tempo de carregamento 17.9 segundos, nesse ponto o site ainda continua bem navegável, tanto no front-end quanto no admin.
• Perfil 40 usuários - Todos os caches ativados, carregamento 26.9 segundos , nesse ponto o site fica lento.
• Perfil 50 usuários – Todos os caches ativados, carregamento 36.8 segundos, o site continua muito lento mas navegável.

Teste 2 - Tofdos os Caches ativados

Conclusões:

1. Fica evidente o ganho de performance do site entre o teste1 (30,22 segundos em média) e o teste 2 (19,28 segundos em média);
2. Em termos de processamento, a figura abaixo ilustra bem o desempenho do processador. Desconsiderando ser um processador de baixa performance e pouca memória, entre o teste 1 e o teste 2 o processador se comporta de forma diferente. No teste 2 a demanda de processamento, apesar de atingir os picos máximos, são bem menores do que no teste 1, demonstrando o alívio que o cache proporciona a máquina.
3. A idéia inicial era fazer o teste 1 todo sem cache, mas fiquei com medo de derrubar a instância. Por isso, a partir de 30 usuários tivei o WP-Supercache e com 40 ativei, também o WP-Widget Cache.
4. O resultado final prova que os caches ativos e, bem configurados, aumenta consideravelmente – cerca de 50% -, com máquinas mais robustas é possivel atingir um pico máximo entre 150 e 300 usuários. Prometo fazer o mesmo teste em uma máquina mais robusta.

Consumo da CPU

Essa limitação complica a hospedagem de blogs em múltiplos domínios dentro de uma mesma instalação do WPMU. Para hospedar múltiplos domínios existem alguns pré-requisitos.

1. Criar o Virtual Host do dominio a ser hospedado dentro do Apache;
2. Reiniciar o Apache;
3. Fazer um update no banco de dados do MU, dentro da ID do blog em questão, para atualizar as URLS do novo domínio;
4. Alterar o wp-config.php, por padrão vem configurado com o nome do domínio de instalação fixo, é necessario alterar para algo do tipo: $_SERVER['HTTP_HOST'];
5. Apontar o DNS para o IP do servidor WPMU;

Executar essas tarefas manualmente é bastante trabalhoso e arriscado, qualquer erro pode comprometer toda a instalação do WPMU.

Com essa necessidade e a limitação apresentada, comecei a pesquisar o que já existia por ai de plugins que executassem essa tarefa. Encontrei apenas um – no WPMU DEV – o Domain Mapping que não faz o trabalho completo. Dessa forma, eu e meus amigos desenvolvedores começamos a criar nosso próprio plugin – o Domain Manager. Que executa todas as operações necessárias para a migração de um blog para um novo domínio.

Seu uso é bastante simples, basta instala-lo na pasta mu-plugins e preencher as informações necessárias que o blog é renomeado e apontado para o novo domínio, com a criação do Virtual Host e Updates no banco, até um reload no Apache o plugin executa.

Um ponto forte desse plguin que o wp-admin – do novo blog – pode ser acessado pela própria URL do novo domínio, de fato, temos um blog “stand alone” funcionando dentro de uma única instalação de WPMU que hospeda N domínios.

Existe apenas uma particularidade nesse processo, a diferença entre uma instalação WPMU por sub-direório ou por sub-domínios.

• instalação por subdomínio - não é possivel criar blogs do tipo: http://dominio.com.br/nomedoblog, é possível criar blogs do tipo http://dominio.com.br, http://subdominio.dominio.com.br, http://outrodominio.com.br, http://dominio.com, e assim por diante.
• instalação por subdiretório – é possível criar blogs na raiz do domínio, contudo o WPMU nessa modalidade insere um /blog em blogs criados na raiz impedindo a navegabilidade do mesmo. Blogs criados na raiz devem utilizar algum tipo de redirect para um blog do mesmo domínio hospedado em /alguma coisa. Por exemplo: http://dominio.com.br redirecionando para http://dominio.com.br/nomedoblog. Não é obrigatório criar blogs raiz para todos os domínios, isso é feito no caso do domínio principal ser divulgado e/ou ter alguma relevância em buscas on-line.

Assim, automatizei o processo de criação de blogs em múltiplos domínios no WPMU. Ainda estou na tentativa de resolver o problema do /blog em blogs criados na raiz de uma instalação por subdiretório. Mas de resto o Domain Manager está funcionando muito bem.

Quem tiver interesse em saber mais informações sobre esse plugin entre em contato!

A seguir umas imagens que ilustram o funcionamento do Domain Manager, clique na primeira e navegue pela galeria.

Instalação por diretório

Instalação por domínio

Domain Manager - O primeiro passo é buscar o ID do blog que deseja renomear

Domain Manager - Configuração do novo domínio

Domain Manager - Bloag renomeado e apontando pro dominio

Sem problemas, mudanças me agradam, me incentivam a crescer ainda mais e a mudar algumas coisas que gostaria de ter mudado há tempos.

Uma delas é esse blog, desde 2006 com o mesmo layout cada vez mais defasado, estava ainda na versão 1.3 do Wordpress, casa de ferreiro espeto de pau, como sempre.

Como nas últimas três semanas tenho trabalhado pesadamente em cima do Wordpress MU, junto com a “Nuvem” da Amazon; aproveitei para migrar o blog, a versão e o layout para esse novo mundo. Daqui uns dias vou falar sobre o Wordpress nas Nuvens, por enquanto ficamos com as novidades aqui do Reflexões e a minha promessa que voltarei a atualiza-lo com freqüencia.

Bem vindos ao recomeço e vamos nessa!

OBS:
Ah! Esse é o tema Magazine Basic do – fera! – c.bovota, impressionante como o mundo evolui rápido no Wordpress, hoje em dia o barato não são mais temas bonitos e sim, temas com funcionalidades, flexibilidade e customização.

Curti, esse ar de NYT no blog…