RSS Feed

‘Internet’ Category

  1. As microempresas e a pseudo-vontade de aderir os padrões.

    outubro 27, 2009 by Igor Escobar

    Acredito que a grande maioria de vocês, senão todos vocês, começaram de baixo, em uma empresa pequena, com poucos funcionários porém lutadora.

    De todas as pequenas que trabalhei, lembro-me que a Web 2.0 era (e ainda é) utilizada como uma forma de atrair e conseguir clientes, era Web 2.0 aqui, Web 2.0 lá, os donos das empresas utilizavam o termo, mais nem sabiam ao certo, que ele queria dizer, eles só sabiam que isso estava atraindo a curiosidade dos clientes e eles depositavam as suas esperanças nessa tal de Web 2.0 (na época) a Web 2.0 já estava sendo muito bem falada, estruturada e aplicada por algumas grandes empresas que possuíam uma boa organização e principalmente maturidade.

    Era mais ou menos igual aquela propaganda da escova de dentes com o limpador de línguas: – Quando crescer, vou querer ser como você.

    Tudo bem, admirar não faz mal a ninguém, mas a maioria das empresas acabavam dando um passo maior que as pernas para poder logo sair contando para os clientes que podem desenvolver sistemas utilizando os conceitos que a Web 2.0 trazia.

    A Mudança

    Toda empresa esta familiarizada principalmente os lideres a desenvolver sites da forma tradicional, abrir um editor WYSIWYG (Ex: Dreamweaver) e sair criando tabelas, inserindo as imagens do layout, os textos etc, sem nem olhar o que esta sendo criado por trás. Este era o cenário a anos atrás.

    São poucas as microempresas que possuem maturidade o suficiente para entender o passo que é começar a desenvolver utilizando conceitos da Web 2.0.

    O cronograma aumenta, mais processos no ciclo de vida do projeto são acrescentados, pessoas precisam ser contratadas (dependendo do caso), documentação aumenta, o paradigma do desenvolvimento fica mais complexo e detalhado…tudo aumenta.

    Toda essa adição de pessoas, processos e complexibilidade é consecutivamente convertida em mais despesas e mais tempo aplicado a um único projeto. As micros querem isso? na visão deles é Web 2.0 pra todos os lados na cabeça do cliente, e o melhor, sem adição no custo, e no prazo.

    Quem apanha no final?

    O coitado do programador que tem que fazer milagres em um curto intervalo de tempo, o coitado do cliente, que só queria o site dele prontinho em Web 2.0.
    Mas quem toma o maior prejuízo no final, é a própria empresa que acaba tendo que gastar muito mais do que o vendido para o cliente, principalmente para correção de bugs e melhorias de processos que não ficou como o cliente esperava ou de acordo com a realidade da empresa.
    Resultado: O Cliente fica insatisfeito, desiludido com essa tal de Web 2.0, nunca mais volta a ser cliente da empresa, fala mal de você para toda a direção da empresa e dependendo do desgaste até para a família.

    A Web 2.0 trás conceitos inovadores que podem tornar uma pequena empresa, em uma grande empresa criadora de soluções e ideias. Mas toda essa força e os seus “benefícios” pode se virar contra a própria empresa e contra o seu próprio usuário, se a empresa não possui um processo sólido, com foco principalmente, no ciclo de vida de um projeto.

    Para quem já trabalhou em uma pequena empresa, na época do boom empresarial em prol da Web 2.0, sabe o que eu estou falando.

    Claro, que este cenário hoje já esta mudando muito, mas o velho ditado diz: Antes de melhorar, vai piorar…muito!

    Tem empresas que aprendem na prática, outras aprendem na teoria para apanhar menos na prática ou caem naquilo que eu falei anteriormente, contratar mais pessoas!
    Aplicar os conceitos da Web 2.0 nos seus projetos é uma questão de puro planejamento e estratégia se você entrar nessa só por entrar e ficar com um pé na web 2.0 e outro na 1.0 isso só vai fazer a sua empresa afundar e se comprometer cada dia mais com seus clientes.

    Esta é uma visão minha, baseando-se em todas as pequenas empresas que eu trabalhei, se alguém possui um ponto de vista diferente e queira compartilhar, por favor, os comentários são abertos e muito bem aceitos.

    Espero ter contribuído!
    []’s


    Posts Relacionados:


  2. Coding Standards

    outubro 27, 2009 by Igor Escobar

    Todos nós sabemos que programar  é um arte, certo? Errado! :D Resolver problemas e criar soluções, é sim, uma arte. Com o amadurecimento do desenvolvimento e a iteração de equipes cada vez maiores, esta “arte” passou a virar ciência.

    Não existe mais este lance de cada um tem seu jeito de programar, cada um tem seu jeito de escrever etc., cada programador tem o seu jeito de pensar, mas não seu jeito de escrever seu código.

    O Coding Standards foi uma dessas demandas surgidas com o crescimento e o amadurecimento do ambiente corporativo. Visando mais produtividade e padronização do ambiente de trabalho, caras como Walker de Alencar, Todd Hoff’s, e Fredrik Kristiansen (e mais uns por aí) trabalharam desenvolvendo um manual, um guia, de como o seu código deve ser escrito para que todos em uma equipe e/ou empresa desenvolva de forma padrão: dar nomes de funções classes, tabulação, espaçamento, tudo, absolutamente, tudo de forma padrão e sugestiva.

    Adotar o Coding Standards pode ajudar você a não ter que abrir aquele arquivo de funções enorme para lembrar como você escreveu a função que verifica o cadastro dos clientes.

    Verifica_Cadastro() ?
    VerificaCadstro()?
    verificaCadastro()?
    CheckCadastros()?
    verificacadastro()?
    ...
    

    Pode ser que, para algumas pessoas que nunca tenham visto isso, o coding standards pode ser uma lavagem cerebral, algo que vá mudar totalmente a forma como alguns programam, mas é extremamente necessário.

    Qualquer programador que leve a sério o seu trabalho, e que tem o mínimo de respeito pelos seus colegas de trabalho, vão desejar programar de forma padronizada.

    Manuais sobre Coding Standards

    PHP Coding Standards (Walker de Alencar)
    C++ Coding Standards (Todd Hoff’s)
    Code Conventions for Java
    [UPDATE]
    Code Conventions for Python (Guido van Rossum)
    Code Conventions for C#
    Code Conventions for .NET
    [/UPDATE]

    []’s
    Igor.


    Posts Relacionados:

    • Nenhum post relacionado!

  3. Afinal de contas, quanto devo cobrar?

    outubro 26, 2009 by Igor Escobar

    Essa é a dúvida que martela a cabeça de muitos freelancers, micro-empresários e principalmente profissionais que pouco se interessaram por esse lado da profissão e sempre ficam no back stage, fazendo o que lhes são de competência.

    Se você espera que ao final deste artigo tenha um uma tabela feita em excel com todos os produtos e custos, desista. Se você não quer levar a sua empresa para o ralo, os preços entre uma agência e outra pode variar e muito isso é fato, mas não vem ao caso deste artigo ensinar como escolher a melhor empresa.

    Na hora de dar o preço, tudo é uma questão de tecnologias envolvidas, pessoas, gastos mensais da empresa (água, luz, licenças, impostos ou qualquer outra coisa que gere gastos mensalmente para você).

    Muita gente por aí acha melhor utilizar o feeling para dar os custos. Isso pode dar certo como pode também não dar, geralmente o profissional cobra muito caro, ou muito barato ou meio termo, acontece que as grandes contas ou as empresas do ramo de TI que mais têm portas abertas são as pessoas e/ou agências que cobram “certo”.

    Na hora de dar o preço é muito importante ter em mente que dificilmente o seu cliente bate na porta de uma única agência, fecha o negócio e vai embora sorridente, as empresas fazem os orçamento em mais de uma empresa, isso é praticamente garantido, você nunca está sozinho.

    Ter esse pensamento é muito importante, dependendo da conta e do cliente o feeling nestes casos conta muito, é totalmente válido para um empresa as vezes cobrar um valor abaixo do que está acostumado para cativar o cliente e conseguir o case, afinal todos sabemos que quando se consegue um projeto e o mesmo é concluído com sucesso as chances de você receber outras propostas e o cliente bater na sua porta novamente são grandes, há quem diga que o primeiro job é o mais importante de todos pois o cliente dificilmente arrisca milhões de reais (exemplo) em um case de uma empresa que ele nunca trabalhou ou nunca teve contato antes.

    Há uma diferença em orçar preços de jobs de clientes que já passaram pela galeria de cases da agência e orçar preços para clientes que nunca conheceram a metodologia da agência, etc.

    É muito importante passar pela primeira barreira com o cliente (case) o preço tende a ser menor no primeiro, mais se o cliente ficar satisfeito, com certeza ele não irá se preocupar de pagar um preço um pouco maior no segundo case já que agora não há motivos para se preocupar, principalmente sabendo que ele vai poder dormir tranquilamente (claro que ele não precisa ficar sabendo disso).

    Para você não se preocupar em quanto deve cobrar, apenas cobre certo e não terá dores de cabeça. O grande problema de você cobrar sempre utilizando o feeling é que vai chegar um dia que com certeza irá faltar dinheiro no seu bolso, excesso de despesas, gastos com os filhos … estas coisas acontecem, porém, podemos nos prevenir.

    A empresa que cobra corretamente ele tem em mente a quantidade de projetos que geralmente ela fecha por mês, tendo isso em vista, podemos dividir os gastos da empresa balanceando os mesmos em projetos diferentes.

    Por exemplo, A empresa TI Exemple gasta 30 mil reais por mês somente com encargos empresariais (luz, água, profissionais, internet, impostos, etc) para manter a minha agência funcionando, preciso ter uma margem de lucro de 20% em cima de cada projeto, se a minha agência consegue manter a média de 10 projetos por mês vamos fazer o seguinte:

    Os gastos mensais para manter a minha empresa funcionando é de 30 mil reais, vamos balancear isso nos 10 projetos e dividirmos isso pelo número médio de projetos criados por mês, neste caso, teríamos 3 mil reais fixos para incluir no orçamento de cada cliente. Agora vamos incluir a margem de lucro do projeto de 20% em cada projeto:

    (3.000 / 100) * 20 temos 600 reais, mais os 3 mil fixos de encargos, fechamos o job por 3.600 reais.

    Ah! Então quer dizer que se um cliente vem até a mim e pede para eu editar uma imagem eu vou cobrar 3.600 reais?
    Claro que não, com certeza se você é uma empresa que pega jobs deste gênero o número de jobs executados por mês são maiores e o custo com estrutura e profissionais são bem menores também, tudo é uma questão de estratégia.

    Esta aí a diferença entre a empresa que cobra certo e o cara que cobra seguindo o seu feeling. Ele vai pensar: – Eu não posso cobrar 3.600 reais para editar/criar uma campanha visual para o cliente, vou cobrar apenas 600 reais, pronto o cliente abre um sorriso, sai cantarolando pela rua e aguarda o resultado, já você no final do mês terá que correr em busca do prejuízo.

    Claro que este é um exemplo extremamente simples e objetivo, ilustrando como devemos (por cima) fazer para cobrar por um projeto e não ficar de mãos abanando no final do mês e só acumular dívidas.

    Temos que levar em conta que quanto maior o número de funcionários mais jobs poderemos desenvolver simultaneamente.

    Cada profissional tem um custo diferente para empresa e consequentemente as horas de trabalho de cada profissional pode variar.

    Temos que ter também um certo nível de maturidade, para saber quantas horas iremos gastar no total em cada projeto, para depois então alocar os profissionais competentes, para executá-los, dentro do prazo combinado com o cliente.

    A diferença de cobrar usando o feeling e cobrar certo é que um dia você pode perder seu case ou sua agência para uma outra agência que ao invés de usar o feeling cobrou certo.

    Espero ter contribuído.
    []’s.
    Webtutoriais:52F051F1


    Posts Relacionados:

    • Nenhum post relacionado!

  4. Problemas com UTF-8 with BOM?

    outubro 26, 2009 by Igor Escobar

    Olá pessoal!
    Como um dos objetivos deste blog é apresentar soluções para problemas cotidianos, hoje eu vou falar sobre um problema que enfrentei utilizando a codificação UTF-8 BOM em minhas páginas e sinceramente, até a pouco eu não sabia a diferença entre o UTF-8 sem o BOM e o UTF-8 com o BOM.

    O Problema

    Quando usamos paginas codificadas em UTF-8, em alguns user agents eu recebo algumas linhas extras ou caracteres não esperados no TOPO do documento ou no TOPO de arquivos incluídos… como eu removo estes caracteres?

    Resposta

    Se você trabalha com um arquivo codificado em UTF-8, provavelmente, seus problemas estão sendo causados pela presença da assinatura (BOM) do seu documento que o user agent não reconheçe.

    A assintua (BOM) dos documentos UTF-8 estão sempre no topo do documento e normalmente você espera vêlos, mas não perca seu tempo. A única maneira (works for me) que fez com que pudesse ver a assinatura foi trocando a codificação do documento de UTF-8 BOM para um ISO, caso contrário, a única coisa que você verá, será uma linha em branco no começo do seu documento (e em alguns casos, como o meu, nem isso você vê).

    A confusão

    O grande problema causado pela assinatura dos documentos UTF-8 é que pêla experiência que cada programador possuí é de instinto o programador já sair à procura de linhas extras nos arquivos incluídos.
    É neste pronto onde se é gasto um grande tempo… Depois de perter todo o seu tempo, então, você começa a ficar frustrado por não encontrar a linhas extras nos arquivos e começa a acreditar que tudo isso não passa de uma conspiração do dêmonio com a sua pessoa.

    O que é a assinatura (BOM) dos documentos UTF-8?

    Algumas aplicações inserem uma combinação particular de bytes no começo dos arquivos e isso é usado para indicar que o conteúdo a seguir, possuí caracteres Unicode. Essa combinação de caracteres é conhecida como assinatura ou Byte Order Mark. Alguns editores mostram a assinatura como uma linha extra outras aplicações como o Zend Studio mostram a assinatura como ( ).

    A assinatura (BOM) do documento é importante?

    No caso dos arquivos codificados em UTF-8 não, você pode retirar esta assinatura sem causar problemas de interpretação, a assinatura (BOM) do documento só é importante para documentos UTF-16 e UTF-32 ela é usada para informar como o user agent deve interpretar os caracteres.

    Como detectar a presença da assinatura de arquivos UTF-8?

    Primeiro, nós precisamos detectar se esta linha extra no começo do arquivo é realmente a assinatura BOM.
    Você pode tentar procurar no olhometro, mas se o seu editor interpreta corretamente a assinatura do arquivo, lamento, mas você não verá. Se o seu editor não interpretar ou não reconhecer esta assinatura ele vai apresentar caracteres como  no início do seu documento. Se você utilizar um editor binário, capaz de mostrar valores em hexadecimal, a assinatura poderá ser indentificada pelo conjunto de bytes EF BB BF.

    Alternativamente, se você possuir em mãos um bom editor, ele vai te dizer a codificação do documento na barra inferior do editor ou em algum menu que apresente o encoding do seu documento.

    Se em nenhum destes casos você obter sucesso, existem algumas aplicações web que são capazes de detectar a assinatura (BOM) de documentos UTF-8.

    Removendo a assinatura (BOM)

    Se você possuí algum editor capaz de exibir esta assinatura, você pode remover na mão, apenas seleciona-la e apaga-la.

    Alguns editores como o Notepad++ (Windows, free) e Komodo (Linux, Free) permitem que você especifique se você quer ou não a assinatura no ato em que você salva o arquivo, dê uma olhada no menu “Format”.

    Outra opção, é você utilizar algum tipo de script que automatize a remoção da assinatura rápidamente e recursivamente em todos os seus arquivos. Existe um script feito em Perl, desenvolvido por Martin Dürst que faz isso para você:

    # program to remove a leading UTF-8 BOM from a file
    # works both STDIN -> STDOUT and on the spot (with filename as argument)
    
    if ($#ARGV > 0) {
        print STDERR "Too many arguments!\n";
        exit;
        }
    
    my @file;   # file content
    my $lineno = 0;
    
    my $filename = @ARGV[0];
    if ($filename) {
        open( BOMFILE, $filename ) || die "Could not open source file for reading.";
        while (<BOMFILE>) {
            if ($lineno++ == 0) {
                if ( index( $_, '' ) == 0 ) {
                    s/^\xEF\xBB\xBF//;
                    print "BOM found and removed.\n";
                    }
                else { print "No BOM found.\n"; }
                }
            push @file, $_ ;
            }
        close (BOMFILE)  || die "Can't close source file after reading.";
    
        open (NOBOMFILE, ">$filename") || die "Could not open source file for writing.";
        foreach $line (@file) {
            print NOBOMFILE $line;
            }
        close (NOBOMFILE)  || die "Can't close source file after writing.";
        }
    else {  # STDIN -> STDOUT
        while (<>) {
        if (!$lineno++) {
            s/^\xEF\xBB\xBF//;
            }
        push @file, $_ ;
        }
    
        foreach $line (@file) {
            print $line;
            }
        }
    

    Cuidado com o BOM

    Em alguns editores como o Widows Notepad, se você escolhe salvar o arquivo como UTF-8 ele automaticamente coloca a assinatura (BOM).

    A assinatura (BOM) em arquivos CSS pode causar a falha de de interpretação de algumas regras em alguns user agents, por isso, deve ser removida.

    Em alguns navegadores, a presença da assinatura pode fazer com que TODOS os caracteres da sua pagina sejam interpretados como se fossem UTF-8 independente de qualquer declaração contrária.

    E é isso pessoal, espero que seja útil para vocês, espero que você não perca horas do seu dia tentando resolver este problema como eu e algumas pessoas da comunidade PHP passaram.

    Em arquivos PHP, se você trabalhar como funções como header(); a assinatura causará aquele problema comum quando você enviar qualquer caracter para o browser antes dos header();

    []’s
    Igor


    Posts Relacionados:

    • Nenhum post relacionado!

  5. Web Standards vs. Projeto em dia

    outubro 26, 2009 by Igor Escobar

    Principalmente nas micro-empresas este é um dilema muito comum e recorrente na cabeça dos pobres desenvolvedores.

    Muitas vezes o fator web standards nem é um pré requisito no projeto, acontece que a grande maioria dos programadores que entendem a essência dos Web Standards, gostam e sabem, o motivo da utilização dos padrões no projeto.

    O grande problema surge, quando o cliente pede algo “lunar” e nós, desenvolvedores temos que entrar no mundo highlander do cliente e desenvolver soluções a altura.

    Acontece que, geralmente, soluções mirabolantes requerem implementações mirabolantes, consecutivamente, o nível de manipulação do documento XHTML por meio de Javascript é alto e muitas informações são expostas na marcação HTML, para que o JavaScript possa se guiar.

    Tenho certeza que de todos os meus leitores, pelo menos um! vai se identificar com um caso parecido.

    O grande pensamento vem a cabeça:

    - O sistema não esta validando, e agora? eu só consigo implementar esta solução desta forma, não consegui pensar em outra forma de implementar, e fazer com que meu código consiga se guiar de maneira eficiente, para manipular este documento.

    - Perco mais 1, ou 3 dias pensando em uma nova solução somente para implementar esta solução sob o plano B ou deixo este erro de validação passar e sigo em frente com o cronograma?

    Caros amigos, não se desesperem. Já se foi o tempo onde os programadores eram neuróticos por validação.

    Isso já cansou de ser dito: – Validar o seu código pela W3C nada mais é do que verificar se o seu código esta “gramaticalmente” escrita de maneira correta, ele estar validado não garante que o seu código será renderizado da mesma forma em outros navegadores.

    E entramos no dilêma da guerra dos browsers. Você segue os padrões, mas o browser do seu cliente não, e ai? o que acontece depois ? …

    Se você se preocupa com os padrões, ótimo!, Deve!

    Colocar em risco o ciclo de vida do projeto por causa de um erro de validação não compensa para você nem para sua empresa, pode ter certeza que se você tiver somente este erro, o seu site/sistema não vai se comprometer ou deixar a desejar para o seu cliente.

    Pense muito bem na hora de fazer esta decisão. Se você tem um código 100% validado, ótimo! se você tem próximo a 95% validado, ótimo também!

    A grande sacada deste texto é mostrar pra vocês que foi se o tempo onde as pessoas eram loucas e fissuradas pelo validador da W3C. O validador deve ser somente ser usado como parâmetro para verificar a sintaxe do seu código XHTML, muitas coisas podem passar despercebido na correria do desenvolvimento, da mesma forma que muitas coisas podem ser corrigidas sem comprometer o andamento do projeto com a “ajuda” do validador.

    Use o validador como uma ferramenta aliada e não como uma ferramenta inimiga.

    O W3C é uma organização que documenta “recomendações” e não “obrigações”, existe as recomendações que são extremamente fundamentais para a renderização e comportamento correto em diferentes plataformas, porém, temos que ter um meio termo para tudo.

    Links

    Espero ter contribuído!
    []’s


    Posts Relacionados:


  6. Tableless, o termo maldito ?

    outubro 26, 2009 by Igor Escobar

    Recentemente, vi alguns profissionais e blogueiros revoltados com a repercussão do termo “Tableless” na mente dos pobres alunos e aprendizes.

    Pensamento Tableless

    Meu objetivo com este texto, é tentar salvar as pobres mentes puras de alguns destes aprendizes que talvez cheguem até aqui através dos buscadores, sites que estejam licando a matéria, etc. Provavelmente grande parte dos meus leitores já saibam exatamente o significado deste termo e como utilizar esta técnica na prática, o aprendizado é inevitável, cedo ou tarde você acaba descobrindo o que é Tableless de fato.

    O Problema

    O termo Tableless veio à tona no Brasil em 2003, pelos amigos Elcio Ferreira e Diego Eis, fundadores do site www.tableless.com.br, que incentiva o uso da técnica, com exemplos, mostrando benefícios, boas práticas de desenvolvimento e diversos assuntos que giram em torno do código fonte do desenvolvedor. Para a maioria destes aprendizes, este site pode se tornar evangelizador (rs), você entra crendo no poder das tabelas e sai como table-killer.

    Esta é a visão interpretada pela maioria das pessoas. Sempre que alguém começa a ler sobre o termo, logo quer sair botando a mão na massa, e contar para todo mundo: – Agora eu sei Tableless, é fácil, é só nunca mais usar tabelas ;)

    As pessoas tendem a ler o conteúdo pela metade ou rápido demais, ignorando detalhes, afinal, a sua teoria já esta embutida no seu próprio título certo? Errado!

    Eu não sei ao certo o que acontece. É difícil identificar de quem é a culpa, enfim, de duas, uma:

    Pode ser nossa (disseminadores de conteúdo), que passamos a informação as vezes incompleta, sem muita clareza, omitindo alguns detalhes, ou a culpa é do próprio leitor.

    Tableless – Definitivo

    O termo Tableless fez começo de 2008, 5 anos que o termo vem sendo falado, estudado e colocado na prática no Brasil.

    O Tableless é um técnica de desenvolvimento web cujo o foco esta exclusivamente no seu código fonte. Antes de aplicar o tableless e sair por ai saltitando, estude a semântica das tags, amplie o seu conhecimento em relação às tags, se você não conhece o HTML a fundo, sua capacidade de criação de interfaces com Tableless fica muito limitada, e exposta ao famoso “jeitinho brasileiro” ou gambiarras, como preferir.

    Tableless não é NUNCA mais usar tabelas, Tableless é usar as tags do HTML respeitando os seus valores semânticos, se você programa sob esta filosofia, automaticamente seu código no final será um código, semântico, compatível e claro, Tableless.

    As tabelas foram criadas para exibição de dados tabulares e não para estruturação de layout e criação de interfaces.

    A W3C diz:

    “Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media.”

    Tabelas não podem ser utilizadas meramente para definição da estrutura do seu layout, isso provavelmente vai gerar problemas na rederização para midias não visuais.

    Se você parar para fazer uma análise, vai ver que é uma resposta meio lógica, se a web 2.0 encoraja o uso dos padrões web para o desenvolvimento, por que o Tableless, que é um técnica que surgiu junto com o amadurecimento da web, iria encorajar o contrário?

    O termo talvez gera dúvida na cabeça das pessoas por que todos os lugares que você encontra fonte de informação principalmente no tableless.com.br fala-se muito em livre-se das tabelas, o fim das tabelas, tabelas nunca mais etc.

    O autor do texto repete muito isso somente para fixar o objetivo do técnica e enfatizar o resultado em si. Mas em nenhum momento é citado que você deve esquecer as tabelas, se fosse somente isso, esquece-las, seria simples, tudo gira em torno de como se virar sem elas para fazer o básico o resto é com você.

    Tableless = Menos tabelas (rs) e não livre de tabelas ou sem tabelas ou qualquer outra variante.

    Aceita uma dica? Não leve as coisas tão ao pé da letra, tente entender o por quê das coisas antes de mudar.

    Eu sei que este texto não vai chegar nem a 0,00000001% das pessoas que estão começando com desenvolvimento web, mas se este texto pelo menos ajudar uma pessoa a pensar diferente sobre o Tableless se encontrando na definição dos termos já vou ficar contente.

    Links Úteis:

    Espero ter contribuído!
    []’s


    Posts Relacionados:

    • Nenhum post relacionado!

  7. SEO White Hat vs. Black Hat

    outubro 26, 2009 by Igor Escobar

    Hoje em dia é comum vir um cliente até você e perguntar:
    - Vocês conseguem fazer meu site ficar em primeiro nas buscas?

    Nessas horas muitos profissionais pensam em trocar o chapéu para poder deixar o cliente surpreso ou feliz.

    De todas as práticas que um SEO pode adotar para garantir um bom posicionamento ou não de um projeto nas buscas, elas são divididas em duas categorias, técnicas black hat e técnicas white hat.

    Técnicas Black Hat SEO (Técnicas de chapéu preto)

    Existe um amplo significado do termo Black Hat, profissionais do ramo de informática chamam Black Hat, as práticas adotadas por profissionais para atingir um certo objetivo sem a autorização prévia do orgão, empresa e/ou pessoa responsável.

    Este objetivo pode ser vários, mas especificamente neste texto irei abordar o termo Black Hat no mundo das buscas.

    Falando de SEO especificamente, black hat são técnicas utilizadas para garantir um bom posicionamento nos buscadores em curto prazo.

    Quem nunca se deparou com um site de fundo branco e ao apertar o CTRL + A, aparecer uns textos que normalmente não se pode ver, hoje é possível de encontrar prática como essa executadas em grandes projetos (que não posso citar) para tentar passar duas ou três paginas de vantagem dos concorrentes com o objetivo de tornar a pagina mais relevante na visão dos buscadores usando artifícios.

    Nas Diretivas para Webmasters do Google é recomendado que você:

    Como podem ver o próprio google já tem em seu banco de dados, as principais práticas que trazem resultados eminentes, lembre-se, a Google é uma empresa de milhões de dolares, não abuse nem duvíde da inteligência do seu negócio, eles estão de olho.

    Sou Black Hat SEO, o que pode acontecer comigo?

    O google afirma que é capaz de reconhecer tais práticas e afirma também que existe penalidades para pessoas que tentam ganhar posicionamento nos buscadores utilizando artifícios:

    • Ignorar o algoritmo sem penalizar o site.
    • Fazer com que caia o posicionamento do site nas buscas, tornando-o ridiculamente irrelevante.
    • Apagar o site do índice do Google.

    Técnicas White Hat SEO (Técnicas de chapéu branco)

    As técnicas white hat são as técnicas “legais” recomendadas, que podem ser executadas por um SEO para atingir bons resultados nos buscadores em alguns casos, em curto prazo e em alguns, a longo prazo.

    De modo geral, para ser um White Hat SEO basta criar o seu projeto com amor, com trabalho e com seriedade.

    Todo site que produz conteúdo para o seu usuário final, não tem por quê ser encarado de forma ruim pelos robots.

    Fechando o assunto…

    Se você possui um negócio, certamente não vai querer que o SEO do seu projeto use tais práticas, elas trazem bons resultados a curto prazo, porém, os sites que foram otimizados por um Black Hat SEO tendem cair nas buscas drasticamente no futuro, o que é bem ruim para os negócios.

    Se você quer ser sempre bem posicionado, faça o seu trabalho com calma e com carinho para os usuarios, boas notícias se espalham e as paredes tem ouvidos (google).

    Vale lembrar que existe várias coisas que favorecem o seu conteúdo a um bom posicionamento:

    • Código fonte semântico.
    • Quanto mais limpo for o seu código fonte, melhor os robots conseguiram classificar a relevancia e o teor do seu conteúdo.
    • Crie conteúdo para o seu usuário final e não para o buscador.
    • O Tempo de vida do dominio é um favor importante.
    • Troque links, faça parcerias com sites do mesmo gênero, isso fortalece o seu site (aumento de pagerank).
    • Evite o uso excessivo de animações flash, os robots tem dificuldade de ler tais formatos de mídia consecutivamente identificar o gráu de relevancia do seu material.

    Links Interessantes:
    http://www.seomarketing.com.br/black-hat-SEO.html
    http://www.marketingdebusca.com.br/black-hat-seo/

    Webtutoriais:AD9497F1


    Posts Relacionados:


  8. Aumente as chances do seu projeto/site dar certo

    outubro 26, 2009 by Igor Escobar

    O trabalho de concepção e amadurecimento de uma idéia é uma tarefa complicada. Todos os dias converso com profissionais do ramo de Internet e falamos sobre muitas idéias. Todas envolvem dinheiro, seja de forma direta ou indireta.

    O que é muito comum ser dito nesses grupos é sobre como ganhar dinheiro através de programas de afiliados como Google AdSense, Hotwords, Text Link Adst, UOL Links Patrocinados etc.

    Hoje eu não vou falar sobre como otimizar seus ganhos nestes programas, pois acredito que na própria internet, possuem muitos e muitos artigos falando sobre isso, não vale a pena ficar “duplicando” o que é dito por ai tão incansavelmente.

    Cuidado com o dinheiro

    Quando vamos elaborar uma idéia é muito comum pensarmos em dinheiro, é comum, e algo muito maligno para o futuro e sobrevivência do seu projeto. Devemos pensar, claro, porém, pensar só nisso, vai acabar te cegando para outros pontos importantes que vão além do que só encher o bolso de dinheiro.

    Deixe o fator “ganhar dinheiro” para último plano, amadureça a sua idéia todos os dias, anote tudo, não deixe nada escapar, e em último plano, pense em como trazer um retorno para você utilizando tudo o que você planejou de forma sadia, ou seja, de forma que o seu sistema, o seu planejamento, irá te sustentar a longo prazo, sustentabilidade.

    Dando forma a idéia

    Devo ressaltar, que não é meu objetivo ensina-lo como “documentar” a sua idéia, meu objetivo é te ajudar COMO você deve pensar para que o seu projeto dê certo ou ao menos aumente as chances dele dar certo.

    Certifique-se de que você, com sua experiência, consiga garantir longevidade ao seu projeto, o sucesso de um projeto, esta diretamente ligado a sua continuidade e não apenas o seu começo, ser hype esta completamente fora de questão. Não adianta começar algo e não saber como dar continuidade ao que começou.

    Não seja hype, seja original.

    Ser hype tem seus próis e contras, quem acompanha a blogosfera já viu o que tem de blogs por ai que vivem de hypes para poder ganhar dinheiro a curto prazo. Para quem não sabe o que é hype, vou te dar um exemplo:  Cicarelli, já sabe até do que eu estou falando né? Agora tente imaginar a quantidade de dinheiro que os blogueiros e sites que vivem de hypes ganharam com este acontecimento? Postando os videos, fotos e fakes em seus sites? Então, isso é uma hype, porém, o objetivo é manter uma renda, tirarmos da abstração uma idéia e torna-la sustentável.

    A volta é o mais importante.

    Esta talvez seja a parte mais importante no processo de amadurecimento de uma idéia, é muito comum, ver uma pessoa entusiasmada falando de um projeto, que você sabe que é legal, porém,  o idealizador do projeto simplesmente se céga e só consegue pensar em como o projeto vai ser legal por que tem isso e aquilo e zilhões de coisas, coisas que na prática não fazem diferença.

    Se concentrar no que é obvio não é a saída, centre-se em criar funcionalidades ao seu projeto que atribuíram valor ao seu projeto, esta são as melhores características de um projeto de sucesso, o mais importante não é atrair visitas, o mais importante é criar recursos e funcionalidades que farão com que o usuário volte. Esta é a grande sacada, visitas é consequência, a volta do visitante garante a sua sustentabilidade e o sucesso perpétuo (até que alguém lance algo que o substitua) do seu projeto.

    Acredito que se a sua linha de raciocínio caminhar por este lado, isso só irá aumentar MUITO as chances do seu projeto dar certo. Espero ter contribuído com seu projeto, e quem sabe, sua vida, sua profissão.

    []’s
    Igor.


    Posts Relacionados: