Compartilhar via

“Hello World!”

  • Artigo

Um guia para codificadores sobre como escrever documentação para APIs

Peter Gruenbaum

Você já se viu em uma situação em que o seu gerente pede para você escrever a documentação das APIs que você desenvolveu? Sejamos francos, se você for como a maioria dos desenvolvedores, deve adorar codificar, mas odeia escrever. Além do mais, escrever ocupa o tempo de tarefas críticas que você precisa executar, como desenvolver recursos e corrigir bugs.

Não é de surpreender que a documentação da API frequentemente acabe sendo frustrante e confusa para o leitor, pois ela raramente recebe a atenção que merece.

Este artigo é um guia sobre como escrever a documentação da API. Vou descrever os componentes mais importantes da documentação da API e darei algumas sugestões sobre como torná-la eficaz. Também darei algumas dicas de como criar boas visões gerais, bom código de exemplo e bom material de referência, inclusive indicando onde você deve concentrar o seu tempo e a sua atenção para obter o melhor efeito.

Por que documentar as suas APIs?

Vamos começar pelo lado não técnico da questão. A documentação da API existe desde que as primeiras linguagens de programação foram criadas. Houve muito tempo para desenvolver processos efetivos para a criação de documentação de qualidade; ainda assim, as documentações para APIs bem-escritas são muito raras. Por que isso não acontece?

Em primeiro lugar, raramente a documentação é priorizada. Embora ela tenha um grande impacto na adoção de uma plataforma de software, o impacto real da documentação é difícil de ser medido. O resultado é que a documentação quase nunca recebe tempo e orçamento suficientes. Quando os desenvolvedores são solicitados a escrever a documentação, em geral esse trabalho é acrescido às suas outras responsabilidades e eles precisam encaixá-lo de alguma maneira em sua agenda já sobrecarregada.

Em segundo lugar, desenvolver o código e escrever a documentação são duas habilidades diferentes. Às vezes os desenvolvedores são solicitados a escrever em um idioma que não é o seu idioma nativo. Mas mesmo que tenham nascido em uma região onde se fala inglês e sejam solicitados a escrever em inglês, é bem provável que eles tenham se esforçado nas aulas de literatura e estudos sociais na escola, mas tenham preferido usar esse tempo para resolver problemas nas aulas de matemática e ciências.

A primeira etapa na criação de uma boa documentação de API é solicitar que a gerência conceda o tempo e o orçamento para que isso seja bem feito. Dois pontos principais devem ser colocados para os gerentes:

  1. A boa documentação pode aumentar a probabilidade de adoção da plataforma, pois ela significa uma experiência menos frustrante para os desenvolvedores.
  2. A boa documentação reduz o custo do suporte, pois os desenvolvedores podem encontrar as respostas às suas dúvidas com mais facilidade.

Discutir a importância de uma boa documentação poderá ser um desafio para você, caso não goste de escrever ou esteja totalmente sobrecarregado de trabalho, mas existe uma alternativa. Se o orçamento permitir, você poderá contratar um redator técnico que reunirá as informações que você fornecer e escreverá a documentação.

Assim como os desenvolvedores, você encontrará redatores técnicos com uma variedade de experiências e competências. Muitos deles têm mais experiência em documentação e suporte para o usuário final. Para a documentação da API, no entanto, convém encontrar um redator que realmente tenha atuado como desenvolvedor de software. Em muitas empresas, esses tipos de redatores têm cargos como programador/redator.

Os redatores técnicos que têm alguma experiência em codificação compreendem a dificuldade dos desenvolvedores para tentar fazer uma plataforma de software funcionar, e sabem como uma boa documentação pode ajudar a melhorar o desenvolvimento da plataforma. Além disso, eles devem ter suficiente conhecimento especializado de linguagens, algoritmos e padrões para ler o seu código e entender as suas bibliotecas. Com esse conhecimento e essa experiência, a discussão técnica entre o redator e a equipe de desenvolvimento será mais direta e produtiva.

Dito isso, se o orçamento não permitir a participação de um redator técnico, você mesmo precisará escrever a documentação. Certifique-se de que a gerência entenda que você precisará arranjar tempo para fazer isso, assim como você faria para criar um novo recurso.

Componentes da documentação da API

São quatro os componentes de uma boa documentação de API:

  1. Visão geral: explicar as vantagens que os desenvolvedores têm ao usar a plataforma e, em alguns casos, fornecer uma descrição da arquitetura da plataforma.
  2. Introdução: ajudar o desenvolvedor a começar, na forma de tutoriais passo a passo ou mais simples.
  3. Código de exemplo: fornecer exemplos de código bem comentados com base nos quais os desenvolvedores possam criar.
  4. Material de referência: fornecer informações detalhadas sobre cada classe, membro, função ou elemento XML.

Quando os desenvolvedores começam a ler sobre uma API, a primeira informação que precisam saber é: quem usaria a API e por qual motivo. Se eles não entenderem isso, passarão rapidamente a usar outra coisa. Infelizmente, essa informação frequentemente tende a ser esquecida. Para as pessoas que desenvolvem a API, as informações são óbvias, mas para outras não.

Apresente exemplos claros de quando você usaria a API. Se você tiver clientes ou mesmo clientes potenciais, utilize-os como exemplos no mundo real. Liste as vantagens da plataforma de software, de preferência comparando-a com as abordagens existentes. Você descobrirá que os gerentes de projeto geralmente têm esse tipo de informação.

Visões gerais também são boas para explicar a arquitetura geral da API. Alguns tipos de APIs (por exemplo, muitas APIs da Web) são tão simples que uma discussão sobre arquitetura não é necessária. No entanto, se você estiver documentando algo complexo, com muitas classes e uma estrutura de herança, uma discussão completa sobre a arquitetura, acompanhada por diagramas, frequentemente é útil para o entendimento dos desenvolvedores.

Introdução

Quando os desenvolvedores decidirem dar uma chance para a sua API, a primeira coisa que vão querer saber é como iniciar. Em 2009, minha empresa (SDK Bridge LLC) fez uma pesquisa sobre documentação, e um dos pontos mais comuns entre as respostas foi que os desenvolvedores queriam ajuda para começar. (Consulte meu artigo “Pesquisa sobre documentação do SDK” em tinyurl.com/35l66yk.) Isso é imprescindível para a adoção: se os desenvolvedores acharem difícil iniciar, desistirão rapidamente e encontrarão outra maneira de atingir seus objetivos.

Uma ótima maneira de ajudar os desenvolvedores a iniciar é por meio de tutoriais. Essa abordagem geralmente é muito mais eficaz do que o texto descritivo ou os diagramas de arquitetura. Um tutorial orienta um desenvolvedor passo a passo no processo de criação de um aplicativo simples que demonstra como a API funciona. Geralmente ele começa com atividades não relacionadas à programação, como configurar o ambiente de desenvolvimento ou obter credenciais de autorização. Em seguida, ele direciona o desenvolvedor para adicionar código gradualmente, até poder demonstrar uma tarefa simples com a API. Se possível, tente estruturar o tutorial de forma que os desenvolvedores tenham algo para executar e ver os resultados rapidamente. Depois, continue o tutorial adicionando mais recursos.

É possível que você tenha trabalhado tão atentamente com a sua API que tenha esquecido como é utilizá-la de uma perspectiva totalmente nova. Ao trabalhar nesta seção, faça o possível para dar um passo atrás e se colocar no lugar de um recém-chegado.

Escrevendo código de exemplo

Outro ponto em comum nas respostas da pesquisa da SDK Bridge foi a importância de um bom código de exemplo. Os desenvolvedores aprendem sobre uma nova plataforma começando pelo código que eles já sabem que funciona e, em seguida, modificando-o ou aumentando-o. Muitos desenvolvedores, se não a maioria, acham mais fácil aprender através da prática e não da leitura.

Provavelmente você já sabe como criar um bom código de produção. Um bom código de exemplo tem algumas semelhanças com um bom código de produção, mas existem algumas diferenças importantes também. Em geral, o bom código de exemplo deve seguir estas diretrizes:

  1. As informações relevantes devem ser agrupadas.
  2. A clareza é mais importante do que a eficiência ou a potência.
  3. A simplicidade é mais importante do que uma interface do usuário de boa aparência.

Você pode aplicar essas diretrizes a áreas específicas do software e ver como o código de exemplo se compara com o código de produção.

Todo programador sabe que nunca deve usar valores embutidos em seu código. Esses valores devem ser transformados em constantes e devem ser colocados em um local fácil de ser encontrado caso alguém queira alterá-los.

Acontece que isso é verdadeiro para o código de produção, mas não para o código de exemplo. Você deve usar valores embutidos no código de exemplo para agrupar todas as informações relevantes o máximo possível. Se você seguir boas práticas para o código de produção e definir todas as suas constantes no início do arquivo, quando os desenvolvedores olharem a linha de código que utiliza a constante, eles precisarão rolar até o início do arquivo para descobrir qual é esse valor. Essa ação simples pode fazer com que seu raciocínio seja interrompido. Cadeias de caracteres, inteiros, valores hexadecimais e outros valores simples devem ser todos embutidos em código no exato local em que são usados.

Os comentários são bons tanto para o código de produção quanto para o código de exemplo, porém, no código de exemplo eles são imprescindíveis. Classes, membros ou funções devem começar com pelo menos uma linha de comentário explicando o seu significado ou a sua função. Você deve usar comentários em qualquer local em que o código não seja óbvio, especialmente se precisar documentar uma solução alternativa ou algo igualmente incomum. Esses comentários podem ter várias linhas, se necessário. Use sentenças completas e não tenha medo de ser prolixo.

Em geral, deve haver pelo menos uma linha de comentário para cada cinco ou dez linhas de código. No entanto, existem algumas exceções a esta diretriz. O código irrelevante para o que você está demonstrando não precisa de muitos comentários (por exemplo, o código da interface do usuário necessário para exibir os resultados da API). Se você estiver escrevendo um pequeno trecho com apenas algumas linhas de código que é incluído em algum material de referência, não precisará de nenhum comentário. Se estiver fornecendo um exemplo muito grande, mais parecido com o código de produção, poderá ser mais prático diminuir o número de linhas de comentários.

Nomes de variáveis, classes, membros e funções devem ser claros, independentemente de você estar escrevendo código de produção ou de exemplo. No código de exemplo, porém, você deve ir mais além do que no código de produção, pois a clareza é mais importante do que a eficiência. Nomes logos e complicados podem ser um problema no código de produção, mas geralmente valem a pena no código de exemplo, pois dão mais clareza. Tente fazer com que até mesmo o menor nome de variável tenha sentido e, por mais que você seja tentado, não utilize nomes de variáveis sem sentido como “foo” ou nomes com uma só letra.

A programação orientada a objeto é uma das melhores invenções da engenharia de software. Você pode se surpreender ao saber que, embora ela seja altamente desejável para o código de produção, de fato geralmente não é desejável para o código de exemplo. O motivo é que o design orientado a objeto distribui a funcionalidade de forma que os dados e as funções sejam agrupados, e utiliza herança para reduzir o código duplicado. Lembre-se: um dos princípios fundamentais do bom código de exemplo é que as informações relevantes devem ser agrupadas. O código orientado a objeto tende a distribuir as informações relevantes entre várias classes. Portanto, os desenvolvedores podem acabar pesquisando uma hierarquia de herança para saber o que um método faz, o que só serve para desperdiçar tempo e interromper o raciocínio.

É claro que existem exceções. Algumas APIs requerem a programação orientada a objeto para funcionar adequadamente. Exemplos muito grandes que se parecem mais com um aplicativo de produção também podem precisar do design orientado a objeto. Apenas esteja ciente de que o usuário quer ver todas as informações necessárias em uma classe, se possível.

Uma regra básica do bom design de software é encapsular a funcionalidade em funções e métodos. Para o código de produção, isso dá mais clareza e reduz o código duplicado. Também é bom para o código de exemplo, pois frequentemente pode criar um bloco de código que os desenvolvedores podem simplesmente copiar e colar em seu próprio código, facilitando o uso.

Ocasionalmente, o código de exemplo requer um grande número de linhas de código que não são diretamente relevantes para a sua API, mas que são necessárias para que o seu exemplo funcione. Nesse caso, convém tentar encapsular essas linhas de código irrelevantes em uma função ou um método, para que os desenvolvedores possam ignorá-las com mais facilidade.

A menos que a sua API forneça especificamente recursos de interface do usuário que você precisa demonstrar, você deve manter os elementos de interface do usuário o mais simples possível. O código de interface do usuário pode ocupar muito espaço e diluir as linhas importantes do código que você deseja demonstrar. Os desenvolvedores não estão preocupados com a aparência do seu exemplo — eles só querem entender como a sua API funciona.

Se for absolutamente necessário ter um grande número de linhas de código para a interface do usuário, empacote esse código em funções separadas que os desenvolvedores possam examinar ou ignorar com facilidade.

Finalmente, embora a manipulação de exceções seja crítica para o bom funcionamento do código de produção, no código de exemplo ela pode diluir o código relevante e criar uma distração. Com frequência, uma boa solução é não haver manipulação de exceções, mas colocar um comentário indicando que tipo de exceções devem ser manipuladas no código de produção. No entanto, existem situações em que certas chamadas sempre devem ser feitas com manipulação de exceções e, nesse caso, vale a pena ter linhas extras de código para mostrar exatamente como essa manipulação deve funcionar.

A Figura 1 mostra um exemplo de função do código de exemplo que demonstra como fazer uma solicitação REST em C# para um site de rede social, retornando as IDs dos usuários que estão conectados ao usuário especificado. No código de produção, a URL do ponto de extremidade de REST seria armazenada como uma constante juntamente com outras URLs relevantes. No código de exemplo, no entanto, é melhor colocar essa informação onde é mais provável que os desenvolvedores a vejam e fazer a conexão com o seu papel na função. Observe também que o tratamento de erro é sugerido, mas não implementado. O processamento de XML foi removido deste código de exemplo para maior brevidade.

Figura 1 Exemplo de código

/// <summary>
/// Returns an array of user IDs for users that 
/// are connected to the specified user. Note that 
/// this is a simple, synchronous way to obtain the data.
/// </summary>
/// <param name="userId">The ID of the specified user.</param>
/// <returns>An array of user IDs that are connected to 
/// the specified user.</returns>

public int[] GetConnectedUserIds(int userId) {
  // Create variable to hold the returned IDs
  int[] connectedIds;

  // Construct a URL using the userId and the authorization token
  string url = 
    "http://webservices.contoso.com/users/connections?userid=" + 
    userId.ToString() +
    "&token=" + 
    authorizationToken;

  // Create the Web request using the url
  HttpWebRequest request = 
    WebRequest.Create(url) as HttpWebRequest;
 
  // Get the response
  using (HttpWebResponse response = 
    request.GetResponse() as HttpWebResponse) {

    // Read the response XML
    StreamReader reader = 
      new StreamReader(response.GetResponseStream());
    string xmlResponse = reader.ReadToEnd();

    // Process XML to extract user IDs for connected users 
    // and responseStatus
    ...

    if (responseStatus != "ok") {
      // Handle errors here
      ...
    }

    reader.Close();
  }

  return connectedIds;
}

Material de referência

Em geral, o material de referência compõe a maior parte da documentação da API. Para cada classe, membro, função, elemento XML etc., há a necessidade de informações detalhadas sobre o seu significado e o seu uso. O material de referência deve abranger, no mínimo:

  • Uma breve descrição
  • Descrição de todos os parâmetros e valores de retorno
  • Quaisquer comentários importantes que auxiliarão o desenvolvedor

Se houver mais tempo e orçamento, adicione estas informações:

  • Exceções que podem precisar ser detectadas
  • Links para outras visões gerais ou outros tópicos de referência relacionados
  • Um trecho do código de exemplo, de preferência do código de exemplo que você já escreveu

A boa documentação de referência possui um estilo consistente em todo o conteúdo. Em algumas ocasiões as diretrizes de estilo já existirão, mas com frequência ficará a seu cargo defini-las. A Figura 2 apresenta algumas diretrizes gerais para descrições curtas.

Como exemplo, considere as descrições mostradas na Figura 3 para a classe Button do Microsoft .NET Framework. Elas foram obtidas diretamente da documentação do SDK no MSDN.

Figura 2 Estilo da documentação de referência

Tipo Diretriz Exemplos
Classe Inicie com uma palavra como “Representa” “Representa um álbum de fotos do usuário.”
Métodos e funções Inicie com um verbo

“Retorna o número de contatos da área especificada.”

“Pausa o vídeo.”
Propriedades Use um substantivo ou inicie com verbos como “Obtém” ou “Obtém e define”

“As tarefas do usuário.”

“Obtém e define um conjunto de tarefas do usuário.”
Eventos Inicie com uma frase como “Gerado quando” ou “Ocorre quando” “Gerado quando a resposta do servidor é recebida.”
Elementos XML Use uma frase substantiva “O código postal da cidade.”
Valores boolianos Para as propriedades boolianas, inicie com “Indica se”; para valores de retorno boolianos em métodos e funções, inicie com “Retorna se”

“Indica se o controle é visível.”

“Retorna se duas regiões se interceptam.”

Figura 3 Exemplo de documentação de referência

Classe ou membro Tipo Descrição
Descrição de classe Classe Representa um controle de botão do Windows.
Construtor de Button Construtor Inicializa uma nova instância da classe Button.
Foco Método Define o foco de entrada para o controle.
Visível Propriedade Obtém ou define um valor que indica se o controle e todos os seus controles filho são exibidos.
Clique Evento Ocorre quando o controle é clicado.

APIs da Web

O número de APIs da Web tem crescido rapidamente nos últimos anos, portanto, vale a pena pensar nas diferenças entre as APIs da Web e as APIs locais. O Software como Serviço está se tornando um modelo de negócio popular e as empresas estão descobrindo rapidamente que seus grandes clientes desejam poder usar seus serviços diretamente dos seus próprios sistemas. Isso significa que o provedor de serviços precisa ter uma API pública que seus clientes possam chamar.

(Uma observação sobre terminologia: eu utilizo o termo “API local” para descrever o tipo comum de API que existia antes da Web. Tecnicamente, essas APIs podem ser Chamadas de Procedimento Remoto, portanto, não são locais; tecnicamente, as APIs da Web podem ser chamadas em um servidor que é o mesmo computador que o cliente, portanto, elas são locais. No entanto, na maioria das instâncias, as APIs da Web, que usam protocolos padrão como HTTP, são usadas remotamente e outras APIs são usadas localmente.)

Como as APIs da Web são relativamente novas, não há nenhuma padronização na aparência da documentação. A qualidade da documentação da API da Web varia bastante — às vezes é bem-organizada e completa, às vezes reduz-se a um mínimo de informações produzidas rapidamente em um wiki. Se você for escrever a documentação de uma API da Web, vale a pena passar algum tempo verificando como várias empresas documentaram suas APIs, para encontrar um bom modelo a ser seguido. Por exemplo, a Twilio, uma plataforma para aplicativos de voz e mensagens, possui um excelente exemplo de documentação da REST, que pode ser encontrada em twilio.com/docs. Espera-se que, com o tempo, o setor se acomodará com um pequeno número de modelos efetivos.

De certas formas, a documentação da API da Web é mais crítica do que a documentação da API local, porque pode ser mais difícil para os desenvolvedores experimentar APIs da Web para descobrir como elas funcionam. Os desenvolvedores podem ter limitações (cotas) no número de chamadas que podem fazer, ou a sua experimentação pode estar afetando um sistema online, ou talvez seja difícil emular condições específicas, como a alta utilização do servidor.

Como já foi mencionado anteriormente, os desenvolvedores dependem muito do código de exemplo. Uma das características fortes das APIs da Web é que elas não dependem de plataforma e linguagem. Infelizmente, isso significa trabalho extra ao criar o código de exemplo. Talvez você tenha que escrever código de exemplo em Python, Ruby, Java, C# etc. Tente descobrir o que os seus clientes utilizam mais e concentre-se nas linguagens que são mais importantes para eles.

As duas tecnologias mais comuns para APIs da Web são SOAP e REST. A tecnologia SOAP possui um formato de definição (linguagem WSDL) que é um ótimo ponto de partida para a documentação de referência, enquanto a tecnologia REST não possui. Chamadas HTTP de exemplo e arquivos XML/JSON são úteis em ambas as tecnologias para ilustrar o seu funcionamento, porém não são suficientes. Os exemplos devem ser seguidos de tabelas que descrevam cada elemento, bem como seu formato de dados.

Por exemplo, talvez não seja suficiente descrever um parâmetro como uma cadeia de caracteres. Existem caracteres especiais que não podem ser manipulados? Existem limitações em seu comprimento? Se um elemento XML for uma data, você deverá especificar o formato da data. Se for uma hora, você deverá especificar seu fuso horário.

Além disso, será necessário explicar como os erros são tratados. Isso pode variar para os diferentes formatos aos quais a sua API dá suporte. Se a API usar códigos de resposta HTTP para sinalizar erros, eles deverão ser documentados. A documentação de erro deve explicar por que um erro ocorre e como corrigi-lo.

A autenticação frequentemente é necessária para as APIs da Web e isso precisa ser documentado em detalhes também. Se os desenvolvedores precisarem de chaves de API, não deixe de fornecer instruções passo a passo sobre como obtê-las. Além disso, não se esqueça de que as APIs da Web são criadas com base no HTTP, que é um protocolo incrivelmente avançado. Talvez você tenha informações relacionadas ao HTTP que precisem de documentação, como armazenamento em cache, tipo de conteúdo e códigos de status.

As APIs da Web são tão novas que nós ainda estamos na fase de descobrir a melhor maneira de documentá-las. Esperamos que haja uma padronização nos próximos anos.

Publicação

Até agora eu me concentrei no conteúdo, mas você também precisará publicar a documentação para que os desenvolvedores possam lê-la. Em geral, os desenvolvedores esperam ver uma documentação com hiperlinks, baseada na Web, em vez de arquivos simples como um PDF. Existem várias maneiras de colocar a sua documentação na Web.

Se a sua API for pequena, talvez seja mais simples apenas criar arquivos HTML. Use CSS para obter a aparência correspondente ao site da sua empresa.

Os wikis fornecem uma estrutura para APIs mais complexas. Eles também permitem que você atualize ou adicione conteúdo à documentação facilmente com o passar do tempo, sem precisar acessar outras ferramentas ou outros servidores. Além disso, os aspectos de colaboração em grupo dos wikis permitem que equipes inteiras — até mesmo os seus usuários — façam contribuições. No entanto, produzir rápida e displicentemente um wiki e esperar que os seus desenvolvedores e usuários escrevam os documentos não é uma estratégia viável para a documentação da API.

Vários mecanismos gratuitos de wiki, de software livre, estão disponíveis e estão se tornando populares para a documentação de API, como o MediaWiki baseado em PHP (mediawiki.org/wiki/MediaWiki) e o TWiki baseado em PERL (twiki.org).

As ferramentas de documentação comerciais como o Madcap Flare (consulte madcapsoftware.com/products/flare) e o Adobe RoboHelp (consulte adobe.com/products/robohelp) destinam-se principalmente à documentação para o usuário final, mas podem ser facilmente adotadas para a documentação de API. Elas fornecem uma interface do usuário simples para inserir informações e proporcionam uma aparência mais refinada do que um wiki. Elas podem gerar documentação da Web e de arquivo simples a partir da mesma origem.

Os serviços de colaboração online, como PBworks (pbworks.com) e MindTouch (mindtouch.com), também estão sendo usados para a documentação de API. Além dos recursos de colaboração dos wikis, eles oferecem recursos adicionais, como hospedagem, controle de acesso refinado e recursos de script. Em geral, esses serviços requerem uma taxa de assinatura para uso comercial.

Despache-o!

Uma boa documentação de API é fundamental para que a sua plataforma seja adotada e para reduzir o número de ligações de suporte que a sua empresa recebe. Se você puder convencer o seu gerente a contratar um redator técnico com as habilidades certas, faça-o. Mas, se não puder, siga as diretrizes deste artigo.

A sua documentação deve ter uma visão geral, ajuda para iniciar, código de exemplo e material de referência. Na visão geral, explique por que a sua plataforma deve ser usada. Crie tutoriais para ajudar os desenvolvedores a iniciar. O código de exemplo deve se claro e simples, e nem sempre seguirá os mesmos princípios de codificação do código de produção. O material de referência deve ser detalhado e consistente. Existem várias ferramentas disponíveis para publicar a sua documentação na Web.

Comece a escrever!

Peter Gruenbaum  começou sua carreira como físico, mas tornou-se desenvolvedor de software, trabalhando em tecnologias tão diversas quanto Tablet PCs, Realidade Aumentada, CAD e simulação de cirurgia. Fundou a SDK Bridge LLC para combinar seu amor pela tecnologia e pela escrita, onde ele ensina e escreve sobre tecnologia.

Agradecemos aos seguintes especialistas técnicos pela revisão deste artigo: John Musser (ProgrammableWeb) e Eugene Osovetsky (WebServius)