Construir produtos para cada feature principal

Para toda feature do site que pôde ser reusada em um outro site, construir um produto para isto. Por exemplo, eu procurei recentemente um site de Plone que permitisse que o Plone usasse a feature de “enviar ao amigo” para alguma página, baseada no URL, baseado não apenas no conteúdo do Plone. Isto requereu somente a mudança de 3 skins do CMFPlone, e pude customizar para este site. Alternativamente, eu escolhi separá-lo e colocá-lo fora do produto SendToURL, permitindo que eu o adicione, em um site imediatamente. E, se eu quiser customizar mais estes skins para um outro local, eu posso fazer assim:

Construir um produto de site para customizaçao de sites

Para o próprio site, construir “um produto de site” depender muito menos, de scripts de instalação, de gráficos, de skins, etc. mantenha esta informação, que é muito específica do site, nas features.

Evitar métodos, scripts, externos desconectados, etc.

Métodos externos ou outros tipos de páginas modelo ou scripts que são manipulados fora de seu ZODB acima são desconectados e duros de manter. Então faça-o parte da featute de seus produtos, ou se forem somente para o próprio site, parte de seu produto do site.

Use seu ambiente de edição favorito

Nunca subestime a importância disso. Eu uso vim, que sobe rapidamente (somente ele pode ser usado fàcilmente com ExternalEditor TTW), e que praticamente já está instalado em todo servidor(assim eu posso usa-lo através do ssh). Entretanto, sempre considerando isso, eu próprio o achei quase duas vezes mais produtivo, podendo trabalhar em meu ideal ambiente de edição, com minhas macros, scripts, caminhos, etc., já configurados.

Uma palavra: o grep!

grep e find são os “enviados de DEUS” para trabalhar no sistema de arquivos. Uma vez que você acostumou-se com ele, após anos usando a ZMI, você a ignorará e pensará que ele é uma maravilha.

Gerenciamento do código fonte

Você pode usar suas ferramentas de gerência usuais do código de fonte.

Estagiamento/replicação

Ele é fácil de replicar sua configuração para múltiplas instâncias.

Objetivo: Nenhum skin ou script no ZODB. Somente o resultado das configurações  e o conteúdo

Seu objetivo final será o de que o ZODB tenha somente os objetos de seu conteúdo e os dados da configuração feitos por scripts. Todas nossas skins e todos nossos scripts estarão no sistema de arquivos.

Às vezes, ele é muito útil por guardar scripts ou skins. Por exemplo, você pôde ter um logo diferente em partes diferentes de seu site, e uma prática comum do Zope para isto deveria ser: Ter logo.jpg na raiz de seu site, e um diferente em /about. Entretanto, isto deixa uma parte da skin no site, e prejudica nossa possibilidade de mantê-la bem. Melhor é ter na pasta raiz e na pasta /about  uma propriedade -- palavra, o nome do logo, que nos diz que logo a se usar nesta área. Então, nós podemos manter todos estes logos no sistema de arquivos, e conseguimos nosso objetivo apenas de manter a parte de configuração no ZODB.

Adicionando novo conteúdo armazenado no sistema de arquivos

Siga os exemplos dos tipos de conteúdo dentro CMFPlone

No CMFPlone, há uns exemplos de todos os tipos que podem ser armazenados no sistema de arquivos incluindo features como configuração do proxy, títulos, configurações de segurança. grep é seu amigo aqui: grep - r -- include="*.metadata" o proxy *  e dará a você um exemplo de como usar os arquivos .metadata para configurar um proxy. Este não é um exemplo de ZSQLMethod enviado com CMFPlone, CMFDefault, ou CMFPlone. Para uma discussão de ZSQLMethods e um exemplo de um ZSQLMethod armazenado no sistema de arquivos, veja http://plone.org/Members/pupq/reldb.

Arquivos .metadata para arquivos, segurança e regras de proxy

Estes são arquivos que acompanham anexos todo e "qualquer material”; para objetos, títulos, configurações de segurança, regras de proxy para scripts Python, e mais. Estes substituem os arquivos de propriedades em umas versões mais adiantadas do CMF. Um erro comum é customizar um arquivo de objeto skin (palavra, foo.py) pela copia para um diretório novo, mas não copiando algum foo.py.metadata. Note que o arquivo .metadata deve estar no mesmo diretório, Assim, neste caso, o objeto customizado do foo é usado, e não inicias as configurações no arquivo metadata. Se isto contivesse coisas importantes, como configurações de segurança ou do proxy, isto poderia ser desastroso.

Modo Debug e Conteúdo Armazenado no Sistema de Arquivos

No modo debug, mudanças para armazenamento de conteúdo no sistema de arquivos são vistos imediatamente. Se você não está no modo debug, você terá que ou reiniciar o servidor de Zope ou fazer um refresh do produto usado. Note que se você está usando SpeedPack abaixo do modo debug, você deverá ver mudanças nos objetos da skin, por tanto tempo que eles não serão copiados de um diretório a outro. Entretanto, se você customizar um objeto da skin para um diretório novo e estiver funcionando SpeedPack abaixo do modo debug, Zope já fará cache da posição velha do objeto skin, e não usará a posição da nova versão. Reinicie ou faça refresh do produto usado para ter a informação de Zope sobre isto.

Exemplo de arquivo metadata

From register.cpy.metadata:

[default]

  title=Register a User

  proxy=Manager,Anonymous

  [validators]

  validators = validate_registration

  [actions]

  action.failure=traverse_to:string:join_form

  action.success=traverse_to:string:registered

  action.prefs=traverse_to:string:prefs_users_overview

Armazenamento de novos tipos em sistema de arquivos

Isto é possível para criar seus próprios tipos armazenados em sistema de arquivos. Se houver uns objetos que de não-conteúdo que você usa frequentemente, é importante criar um pequeno script que permitirá que seja armazenado no sistema de arquivos. Você pode olhar o código em CMFCore para armazenar os tipos existentes (Modelos de Páginas, Scripts Python, Arquivos, etc..) Um exemplo disso é FSExternalMethod. Isto é examinar um tipo de objeto existente no Zope e criar uma versão dele capaz de armazenar no sistema de arquivos. Procure no produto "FileSystemSite".

Compensação de corrupções no sistema de arquivo

Algumas vezes não é possível trabalhar no sistema de arquivos. Você pode somente ter o acesso por um navegador web ou ter criado muitos objetos na skin existente no ZODB. FSDump fará exame dos objetos existentes da skin e irá removê-los do sistema de arquivos.

FSDump: 

Dumps do material existente no ZODB para o sistema de arquivos

Você necessita escrever dumps para seus tipos armazenados no sistema de arquivos.

Se você escrever tipos customizados para armazenamento no sistema de arquivos, você terá que escrever seu próprio plug-in do dump para esto. Isto é completamente fácil de fazer -- veja o código em FSDump para exemplos de como são os tipos básicos de dump.

Muito menos - use FSDump para backups

Crítico para equipes

Se sua equipe é maior que um, gerenciamento de código fonte é essencial. Permitirá que sua equipe trabalhe junto mais rapidamente, com muito menos "Estou fora desta; Eu estou trabalhando nele", e muito menos "Eu não sei direito o que esta pessoa fez aqui". As Mãos à Obra, a execução bem sucedida de Gerenciamento de Código Fonte será  uma grande vitória para coordenação e desempenho de sua equipe.

Útil para arqueologia do código 

Quando encontrar seu próprio código velho, ou então, algum código de alguém, ver as mensagens de log e a maneira como foi construído é frequentemente e inacreditavelmente útil para encontrar erros e fazer manutenção.

Branches (Ramos de Desenvolvimento)

Frequentemente, você trabalha por um dia ou dois em uma idéia nova, somente para descobrir que você não estava trabalhando nela, você precisa se organizar e você pode não lembrar de todos os bilhões de coisas que você mudou, enquanto se divide pra botar para fora esta idéia nova. Isto é exatamente o que branches em um sistema de controle da versão significa para o gerenciamento. Aprenda como usar branches para seu sistema de Controle de Versão. Eles são mais fáceis do que você pensa, especialmente no subversion.

Subversion 

Similar ao CVS, mas redesenhado de baixo para cima

Commits são por um conjunto de mudanças inteiro, não apenas por arquivos

Mais fáceis de compreender o relacionamento dos commits

API para utilitrios Python

Subversion em 1 Minute

svnadmin cría /var/lib/svn

Cria a estrutura do seu produto e arquivos

Svn import * URL para o repositório *

Livro excelente sobre o subversion publicado por O'Reilly - baseado no livro on line.

Gerenciador de Controle de Fontes não apenas para codificadores

Interfaces gráficas e linha de comando para Windows, Linux, e OS X

Simples bastante para que os desenhistas e os escritores usem

Fácil de vender - "Você não tem que preocupar-se"

No início, a tarefa de ter n desenvolvedores usando seu sistema de controle da versão parece desanimadora. Eu posso encontrar, entretanto, n desenvolvedores que podem amá-lo quando realizam facilmente seu trabalho fora dos arquivos de seu computador e sincronizado com o servidor dele, e compreendem que não tem que preocupar-se com erros. Isto é como você vende toda esta idéia.

As melhores práticas para Gerenciadores de Controle de Fontes

Mensagens de log são suas amigas

Assim não tratem-nas como suas inimigas:

Consulte os itens das mensagens no collector.

É bom escolher uma sintaxe simples e padrão para isto. Eu uso freqüentemente a frase "Collector # 123", e posso construir ferramentas WEB que permitem que você pule direto para esse erro e ver os detalhes do que você está tentando reparar. Isto ajuda a fechar o loop sobre do porque você fazia estas mudanças em primeiro lugar.

Focalize sobre porque, não o que

Naturalmente você editava o login_form. Nós podemos ver o que. Por que, entretanto, você fêz aquelas mudanças? Que era quebrado? Que requisição de cliente para este endereço? Esta é a informação que você quer mais tarde. Explanações do que você deve fazer tem que estar comentadas no código em todo o caso.

Verifique no "pristine" copia como primeira cópia

Se você quiser customizar o login_form do Plone, por exemplo, não faça a cópia dele para o seu diretório de produtos do site e imediatamente inicie o corte nele. Alternativamente, copíe-o para seu diretório, verifique-o se está correto, em seu pristine form, a seguir inicie o corte separado. Agora, você pode resolver dois problemas: (a) Ele é trivial para você para diferenciar a revisão 1 da revisão 2 deste arquivo para encontrar porque você estava customizando ela em primeiro lugar, e (b) quando Plone é atualizado e lá estão mudanças no envio do login_form, Ele é muito mais fácil de incorpora-los, desde que você saiba exatamente como login_form estava quando você iniciou, sem ter que procurar ao redor para encontrar essa versão.

Estas coisas fazem somente de uma minúscula parte da disciplina - e elas realmente pagam depois. Eles tornam isto muito mais fácil de compreender porque você customizou uma skin de Plone dois meses atrás.

Inspiração para colocar na minha base de dados. Liberação. - Kapil Thangavelu

Tudo que é trabalhado com o Zope por mais de alguns meses encontra o “ZODB Dread”: Isso é um risco terrível, Sentimento profundo de que que você afundou um grande pedaço de sua vida em uma simples base de dados orientada a objeto no formato binário, sem nenhuma esperança de sempre poder lembrar de todos os scripts, skins, propriedades, e configurações que você pôs nela. Você sabe que se este filhote de cachorro começar mal sempre estará corrompido, você estará em um mundo passional. Isto é o que nós queremos evitar, é aquilo pelo qual nós criamos o código de instalação no sistema de arquivos.

Escrevendo Código de Instalação

Conselho Geral

Cada função da instalação é um método que você pode chamar independentemente.

Registro das funções.

Qualquer um pode prevenir chamadas duplicadas ou deletar e recriar como dono.

Como eu aprendi a parar de preocupar-me e amar a API

DocFinderTab

DocFinderTab fornece o acesso instantâneo à WEB através da API para todo o objeto que você puder chamar na ZMI. Em muitos casos, é mais agradável do que olhar atrvés do código de fonte, desde que você vê todos os métodos das classes basicas, e mais agradável que olhar no debugador, porque você chama coisas arranjadas pela classe basica. Este produto é absolutamente simples de instalar e usar. Não há nenhuma desculpa para não a tentar experimentá-lo hoje. Isto realmente deve estar embarcado como parte de Zope.

Epydoc

Epydoc é uma versão mais esperta e mais funcionalmente completa do módulo do pydoc que está embarcado no Zope. Ele constrói consideravelmente a documentação indexada à API para seu produto, ou uniforme para Zope e no próprio Plone. Pode mesmo, gerar isto como um pdf, que imprima clientes e economize seu tempo em criar este tipo da documentação. N mais, ver realmente suas macros e conjunto de configurações é um bom incentivo para escrever mais e melhor. 

Arquivos de instalação .py de outros produtos

Uma grande forma de ver como configurar coisas é ver como outros produtos o fazem, naturalmente. Olhe o Install.py de seu produto favorito. Por exemplo, para aprender como instalar workflows novos do disco, veja como nós fazemos isto no PloneHelpCenter (no collective.) 

CMF 1.5

Inclui um dumper XML para muitos (mas não ainda todo) CMFCore/ferramentas padrão

Assim, você pode fazer as mudanças na ZMI, rapidamente e intuitivamente, fazendo uam fotografia dessas mudanças. Estas fotografias podem ser verificados em seu sistema de controle de versão, comandos diff, etc. E você pode restaurar de uma fotografia, tornando ele mais fácil de retornar a uma instalação diferente. 

Não necessitará fazer chamadas à API

Para a maioria de coisas, pelo menos. 

A compatibilidade e os dumpers de CMF 1.5 para nossas ferramentas permitiram migrar para Plone 2.1.

Documentação do desenvolvedor

Use interfaces Python

Use Definitivamente suas macros

Faça testes alfa de sua documentação com outros desenvolvedores

Regra: Testes unitários

Documentação útil de produtos

DCWorkflowGraph

DCWorkflowDump

EpyDoc

ArchGenXML

Debugando

(para um exemplo mais completo do trabalho no debugger, ver usando PDB)

A vida sem debuggers não é harmoniosa

Os problemas simples são resolvidos em 2 minutos

Os problemas complicados são possíveis de resolver

O Debugador é seu amigo

Usando debugger com o ZEO em Zope 2.7

zopectl debug entrará no debugador sob ZEO

Pode examinar qualquer coisa

Pode executar o código arbitrário, mudar variáveis, mudar ZODB

Executando requisições

Zope.debug (...)

Ler a documentação sobre debug com Zope

, user do u="usuário:senha"

, pm=1 para pós-morte

Brincando no ZODB

Frequentemente, ainda mais útil do que eliminar erros é a habilidade do simples exame direto de seu ZODB a par de toda requisição ou passo do debug. Uma vez que você usá-lo, você provavelmente encontrará razão para abrir o debugador todo o tempo enquanto você estiver desenvolvendo e eliminando erros, para ver apenas rapidamente como as coisas são criadas realmente e trabalhadas em Zope.

A maioria de funcionalidades úteis

Pode interativamente examinar e mudar o ZODB fora do debug

A raiz de ZODB é app

Mudanças no ZODB

Para comitar sua transação: get_transaction () .commit ()

Para sincronizar você mesmo ao ZODB corrente: app. _p_jar.sync ()

Debugadores Gráficos

BoaConstructor

Pode debugar scripts Python no ZODB

Pode construir objetos de Zope

WingIDE

Poderoso debugador remoto

Pode debugar scripts Python armazenados no sistema de arquivos

Komodo

Debugador Regex

IDE excelente

Desenvolvendo, estagiando e sincronizando

Trabalhar no laptop fora da rede e mover para o servidor

Mover do servidor de estágio para o servidor de produção

Trabalhar em equipe

Você possui um Laptop: Use ele

Ele não é um cliente SSH de $3000

Edição rápida/teste/ciclo de debug.

Sem fio, sem wireless

Mais fácil de trabalhar confidencialmente

Subversion para compartilhamento

Trabalhe em seu laptop

Quando “no ponto certo”, verifique seu código

rsync para sua área de trabalho no servidor

As mudanças de emergência no servidor podem ser manuais, também

Área de trabalho simples

Cada desenvolvedor tem uma skin folder no seu produto

rsync de suas mudanças na skin para sua skin folder

Cada desenvolvedor tem seu próprio skinpath, com sua skin folder com mais customizações

Desenvolvedores podem comutar de seu skinpath da área de trabalho ao skinpath comum.

Sincronização do Conteúdo

Crie starter content nos seus scripts de instalação

Crie starter content em arquivos .zexp

Não pode mudar, embora

Use ZSyncer para sincronização de um servidor a outro

Testando

PloneTestCase faz isto facilmente

Economiza um pouco de tempo para muito de preocupação

Pensar amplamente sobre os benefícios

Por exemplo, os bons testes permitirão reusar mais seu código, porque você terá a confiança para fazer assim.

Olhar um produto com boa evidência de testes &mdash tal como ATContentTypes

Mechanize-driven para testes de elementos da interface

Considerar faturar separadamente isto para seus clientes

Modelo para a instalação de teste

Modelo para a instalação de teste para PloneHelpCenter:

class PHCSiteTestCase(ArchetypesTestCase.ArcheSiteTestCase):

   """Test structure for PHC"""

   def afterSetUp(self):

         ArchetypesTestCase.ArcheSiteTestCase.afterSetUp(self)

  self._portal = self.app.portal

        # login as manager

        user = self.getManagerUser()

        newSecurityManager(None, user)

  self._portal.invokeFactory(type_name='HelpCenter',

            id='helpctr')

        self._hc=getattr(self._portal, 'helpctr')

   def beforeTearDown(self):

  ArchetypesTestCase.ArcheSiteTestCase.beforeTearDown(self)

  noSecurityManager()

  del self._hc

Modelo de Teste

Modelo de teste para o PloneHelpCenter

class TestFAQ(PHCTestCase):

    """Test those parts of FAQ and FAQ Folder that don't

    require a real site framework. Allows tests to run faster

    """

    def afterSetUp(self):

        PHCTestCase.afterSetUp(self)

        self._dummy = FAQ.HelpCenterFAQ(oid='dummy')

        self._dummy.initializeArchetype()

   def test_answerSTX(self):

        dummy = self._dummy

        dummy.setAnswer(example_stx, mimetype='text/structured')

        answer=no_whitespace.sub('',dummy.getAnswer())

        self.failUnless(answer==example_html, 'Value is %s' % answer)

Mais informações sobre teste unitário

Lotes material e dos tutoriais disponíveis na WEB

Pegue a apresentação "Unit Testing Zope for Fun and Profit" de Stefan Holek para a EuroPython

Um livro muito bom é Unit Testing book de Kent Beck

José Carlos Gaspar - tradução para o português

Joel Burton - autor do original

Kapil Thangavelu - Inspiração para colocar na base de dados e muito mais

Calvin Hendryx-Parker e David "Whit" Morriss - idéias e feedeback

Alan Runyan Por liberar diversos produtos que ensinam o “caminho certo”

Alexander Limi - Conversão do PloneHelpCenter e insistência.