quais detalhes técnicos o programador de um aplicativo da web deve considerar antes de tornar o site público?
<p>o que um programador que implementa os detalhes técnicos de um aplicativo da web deve considerar antes de tornar o site público? se <a href="https://softwareengineering.stackexchange.com/users/37/jeff-atwood">jeff atwood</a> puder esquecer <a href="http://www.codinghorror.com/blog/archives/001167.html">cookies httponly</a> , <a href="http://www.codinghorror.com/blog/archives/001174.html">sitemaps</a> , <em> e</em> <a href="http://www.codinghorror.com/blog/archives/001171.html">solicitação entre sites falsificações</a> <em> todos no mesmo site</em>, que coisa importante eu poderia estar esquecendo também?</p><p>estou pensando sobre isso da perspectiva de um desenvolvedor da web, para que outra pessoa esteja criando o design e o conteúdo reais do site. portanto, embora a usabilidade e o conteúdo possam ser mais importantes que a plataforma, você, o programador, tem pouco a dizer sobre isso. o que você precisa se preocupar é que sua implementação da plataforma seja estável, tenha bom desempenho, seja segura e atenda a quaisquer outras metas de negócios (como não custar muito, demorar muito para criar e classificar tão bem quanto o google como o suporte de conteúdo).</p><p>pense nisso da perspectiva de um desenvolvedor que fez algum trabalho para aplicativos do tipo intranet em um ambiente bastante confiável e está prestes a ter sua primeira chance e lançar um site potencialmente popular para toda a grande e ruim rede mundial de computadores.</p><p>além disso, estou procurando algo mais específico do que apenas uma resposta vaga de "padrões da web". quero dizer, html, javascript e css sobre http são praticamente um dado, especialmente quando eu já especifiquei que você é um desenvolvedor web profissional. então, indo além disso, <em> quais</em> padrões? em que circunstâncias e por quê? <strong> forneça um link para a especificação da norma. </strong></p>
<p>a idéia aqui é que a maioria de nós já <em> já </em> saiba <em> a maioria </em> do que está nesta lista. mas pode haver apenas um ou dois itens que você realmente não analisou antes, que não entende completamente, ou talvez nunca tenha ouvido falar.</p><p><strong> interface e experiência do usuário </strong></p><ul> <li>esteja ciente de que os navegadores implementam os padrões de maneira inconsistente e verifique se o site funciona razoavelmente bem em todos os principais navegadores. em um teste mínimo com relação a um <a href="https://en.wikipedia.org/wiki/gecko\_%28layout\_engine%29">gecko</a> engine recente ( <a href="http://firefox.com/">firefox</a> ), um mecanismo webkit ( <a href="http://www.apple.com/safari/">safari</a> e alguns navegadores móveis) , <a href="http://www.google.com/chrome">chrome</a> , seus navegadores <a href="https://en.wikipedia.org/wiki/internet\_explorer">ie suportados</a> (aproveite as <a href="http://www.microsoft.com/downloads/details.aspx?familyid=21eabb90-958f-4b64-b5f1-73d0a413c8ef&amp;displaylang=en">imagens vpc de compatibilidade de aplicativos</a> ) e <a href="http://www.opera.com/">opera</a> . considere também como <a href="http://www.browsershots.org">browsers processam seu site</a> / em diferentes sistemas operacionais.</li> <li>considere como as pessoas podem usar o site que não seja dos principais navegadores: telefones celulares, leitores de tela e mecanismos de pesquisa, por exemplo. - algumas informações de acessibilidade: <a href="http://www.w3.org/wai/"> wai </a> e <a href="http://www.section508.gov/">section508</a> , desenvolvimento móvel: <a href="http://mobiforge.com/">mobiforge</a> .</li> <li>preparo: como implantar atualizações sem afetar seus usuários. tenha um ou mais ambientes de teste ou teste disponíveis para implementar alterações na arquitetura, no código ou no conteúdo abrangente e garantir que eles possam ser implantados de maneira controlada sem quebrar nada. tenha uma maneira automatizada de implantar alterações aprovadas no site ativo. isso é implementado de maneira mais eficaz em conjunto com o uso de um sistema de controle de versão (git, subversion, etc.) e um mecanismo de compilação automatizado (ant, nant, etc.).</li> <li>não exiba erros hostis diretamente para o usuário.</li> <li>não coloque os endereços de email dos usuários em texto sem formatação, pois eles receberão spam até a morte.</li> <li>adicione o atributo \_<code>rel="nofollow"</code>\_ aos links gerados pelo usuário <a href="https://en.wikipedia.org/wiki/nofollow">para evitar spam</a> .</li> <li> <a href="http://www.codinghorror.com/blog/archives/001228.html">crie limites bem considerados no seu site</a> - isso também pertence a segurança.</li> <li>aprenda a fazer <a href="https://en.wikipedia.org/wiki/progressive\_enhancement">aprimoramento progressivo</a> .</li> <li> <a href="https://en.wikipedia.org/wiki/post/redirect/get">redirecione após um post</a> se esse post foi bem-sucedido, para impedir que uma atualização seja enviada novamente.</li> <li>não se esqueça de levar em consideração a acessibilidade. é sempre uma boa ideia e, em determinadas circunstâncias, é um <a href="http://www.section508.gov/">requisito legal</a> . <a href="http://www.w3.org/wai/intro/aria">wai-aria</a> e <a href="http://www.w3.org/tr/wcag20/">wcag 2</a> são bons recursos nessa área.</li> <li>leia <a href="http://www.sensible.com/dmmt.html">não me faça pensar</a> .</li> </ul><p><strong> segurança </strong></p><ul> <li>é muito difícil de digerir, mas o guia de desenvolvimento <a href="http://www.owasp.org/index.php/category:owasp\_guide\_project">owasp</a> cobre a segurança do site de cima para baixo.</li> <li>saiba mais sobre a injeção, especialmente <a href="https://en.wikipedia.org/wiki/sql\_injection">sql injection</a> e como evitá-la.</li> <li>nunca confie na entrada do usuário, nem em qualquer outra coisa que esteja presente na solicitação (que inclui cookies e valores ocultos do campo do formulário!).</li> <li>hash senhas usando <a href="https://security.stackexchange.com/q/21263/396">salt</a> / e use sais diferentes para suas linhas para evitar ataques do rainbow. use um algoritmo de hash lento, como bcrypt (tempo testado) ou scrypt (ainda mais forte, mas mais recente) ( <a href="http://www.tarsnap.com/scrypt.html">1</a> , <a href="http://it.slashdot.org/comments.pl?sid=1987632&amp;cid=35149842">2</a> ), para armazenar senhas. ( <a href="http://codahale.com/how-to-safely-store-a-password/">como armazenar com segurança uma senha</a> ). o <a href="https://security.stackexchange.com/q/7689/396">nist também aprova o pbkdf2 para senhas de hash</a> "e é <a href="https://security.stackexchange.com/a/2136/396">fips aprovado no .net</a> (mais informações <a href="https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords">aqui</a> ) . <em> evite </em> usar md5 ou a família sha diretamente.</li> <li> <a href="https://stackoverflow.com/questions/1581610/how-can-i-store-my-users-passwords-safely/1581919#1581919">não tente criar seu próprio sistema de autenticação sofisticado</a> . é uma coisa tão fácil cometer erros de maneiras sutis e não testáveis ​​e você nem saberia até <em> depois de </em> ser invadido.</li> <li>conheça as <a href="https://www.pcisecuritystandards.org/">regras para o processamento de cartões de crédito</a> . ( <a href="https://stackoverflow.com/questions/51094/payment-processors-what-do-i-need-to-know-if-i-want-to-accept-credit-cards-on-m">veja também esta pergunta</a> )</li> <li>use <a href="http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt">ssl/tls</a> / <a href="https://en.wikipedia.org/wiki/session\_hijacking#prevention"> https </a> para sites em que dados confidenciais são inseridos (como credenciais, informações de identificação pessoal, informações do cartão de crédito). <a href="https://letsencrypt.org">let's encrypt</a> é uma autoridade de certificação gratuita que pode ajudar.</li> <li> <a href="https://en.wikipedia.org/wiki/session\_hijacking#prevention">impedir o seqüestro de sessão</a> .</li> <li>evite <a href="https://en.wikipedia.org/wiki/cross-site\_scripting">scripts entre sites</a> (xss).</li> <li>evite <a href="https://en.wikipedia.org/wiki/cross-site\_request\_forgery">falsificações de solicitação entre sites</a> (csrf).</li> <li>evite <a href="https://en.wikipedia.org/wiki/clickjacking">clickjacking</a> .</li> <li>mantenha seu (s) sistema (s) atualizado (s) com as últimas correções.</li> <li>verifique se as informações de conexão do banco de dados estão protegidas.</li> <li>mantenha-se informado sobre as mais recentes técnicas de ataque e vulnerabilidades que afetam sua plataforma.</li> <li>leia <a href="https://code.google.com/archive/p/browsersec/">manual de segurança do navegador google</a> .</li> <li>leia <a href="https://rads.stackoverflow.com/amzn/click/com/0470170778">manual do hacker de aplicativos da web</a> .</li> <li>considere <a href="https://en.wikipedia.org/wiki/principle\_of\_least\_privilege">o princípio do menor privilégio</a> . tente executar o servidor de aplicativos <a href="https://security.stackexchange.com/questions/47576/do-simple-linux-servers-really-need-a-non-root-user-for-security-reasons">como não raiz</a> . ( <a href="http://tomcat.apache.org/tomcat-8.0-doc/security-howto.html#non-tomcat\_settings">exemplo do tomcat</a> )</li> <li>coloque \_<code>rel="noopener noreferrer"</code>\_ em todos os links fornecidos pelo usuário com \_<code>target="\_blank"</code>\_ para impedir que o javascript na página de destino redirecione sua página para outro lugar, como uma página de login falsa. <a href="https://dev.to/phishing">mais informações</a> </li> <li>considere usar uma <a href="https://csp.withgoogle.com/docs/index.html">política de segurança de conteúdo estrita</a> .</li> </ul><p><strong> desempenho </strong></p><ul> <li>implemente o cache, se necessário, entenda e use <a href="http://www.mnot.net/cache\_docs/">http caching</a> corretamente, bem como <a href="http://www.w3.org/tr/2011/wd-html5-20110525/offline.html">html5 manifest</a> .</li> <li>otimizar imagens - não use uma imagem de 20 kb para um fundo repetitivo.</li> <li>compactar conteúdo para velocidade, consulte <a href="https://www.smashingmagazine.com/2016/10/next-generation-server-compression-with-brotli/">brotli</a> , <a href="http://developer.yahoo.com/performance/rules.html#gzip">gzip/deflate</a> (<strike> <a href="https://stackoverflow.com/questions/1574168/gzip-vs-deflate-zlib-revisited">deflate é melhor</a> </strike>).</li> <li>combine/concatene várias folhas de estilo ou vários arquivos de script para reduzir o número de conexões do navegador e melhorar a capacidade do gzip para compactar duplicações entre arquivos.</li> <li>dê uma olhada no site <a href="http://developer.yahoo.com/performance/">yahoo exceptional performance</a> , muitas ótimas diretrizes, incluindo a melhoria do desempenho do front-end e sua <a href="http://developer.yahoo.com/yslow/">yslow</a> ferramenta (requer firefox, safari, chrome ou opera). além disso, <a href="https://developers.google.com/speed/docs/best-practices/rules\_intro">velocidade da página do google</a> (use com <a href="https://developers.google.com/speed/pagespeed/insights\_extensions">extensão do navegador</a> ) é outra ferramenta para criação de perfil de desempenho e otimiza suas imagens também.</li> <li><strike>use <a href="http://alistapart.com/articles/sprites">css image sprites</a> para imagens relacionadas pequenas, como barras de ferramentas (consulte o ponto "minimizar solicitações http")</strike></li> <li>use <a href="https://24ways.org/2014/an-overview-of-svg-sprite-creation-techniques/">sprites de imagem svg</a> para pequenas imagens relacionadas, como barras de ferramentas. a coloração svg é um pouco complicada. você pode ler sobre isso <a href="http://tympanus.net/codrops/2015/07/16/styling-svg-use-content-css/">aqui</a> .</li> <li>sites ocupados devem considerar <a href="http://developer.yahoo.com/performance/rules.html#split">dividir componentes entre domínios</a> . especificamente...</li> <li>o conteúdo estático (ou seja, imagens, css, javascript e, geralmente, o conteúdo que não precisa de acesso a cookies) deve ir em um domínio separado <em> <a href="http://blog.stackoverflow.com/2009/08/a-few-speed-improvements/">que não usa cookies</a> </em>, porque todos os cookies de um domínio e seus subdomínios são enviados com todas as solicitações para o domínio e seus subdomínios. uma boa opção aqui é usar uma rede de entrega de conteúdo (cdn), mas considere o caso em que essa cdn pode falhar incluindo cdns alternativas ou cópias locais que podem ser veiculadas.</li> <li>minimize o número total de solicitações http necessárias para um navegador renderizar a página.</li> <li>escolha um <a href="http://garann.github.io/template-chooser/">template engine</a> e renderize/pré-compile usando os executores de tarefas como gulp ou grunt</li> <li>verifique se há um arquivo \_<code>favicon.ico</code>\_ na raiz do site, ou seja, \_<code>/favicon.ico</code>\_. <a href="http://mathiasbynens.be/notes/rel-shortcut-icon">os navegadores solicitarão automaticamente</a> , mesmo que o ícone não seja mencionado no html. se você não tiver um \_<code>/favicon.ico</code>\_, isso resultará em muitos 404s, consumindo a largura de banda do servidor.</li> </ul><p><strong> seo (otimização de mecanismos de pesquisa) </strong></p><ul> <li>use urls "compatíveis com o mecanismo de pesquisa", ou seja, use \_<code>example.com/pages/45-article-title</code>\_ em vez de \_<code>example.com/index.php?page=45</code>\_</li> <li>ao usar \_<code>#</code>\_ para conteúdo dinâmico, altere \_<code>#</code>\_ para \_<code>#!</code>\_ e, em seguida, no servidor \_<code>$\_request["\_escaped\_fragment\_"]</code>\_, é o que o googlebot usa em vez de \_<code>#!</code>\_. em outras palavras, \_<code>./#!page=1</code>\_ se torna \_<code>./?\_escaped\_fragments\_=page=1</code>\_. além disso, para usuários que possam estar usando o ff.b4 ou o chromium, <code>history.pushstate({"foo":"bar"}, "about", "./?page=1");</code> é um ótimo comando. portanto, mesmo que a barra de endereço tenha mudado, a página não é recarregada. isso permite que você use \_<code>?</code>\_ em vez de \_<code>#!</code>\_ para manter o conteúdo dinâmico e também informar ao servidor quando você enviar por e-mail o link que estamos após esta página, e o ajax não precisa para fazer outro pedido extra.</li> <li>não use links que digam <a href="https://ux.stackexchange.com/questions/12100/why-shouldnt-we-use-the-word-here-in-a-textlink">"clique aqui"</a> . você está desperdiçando uma oportunidade de seo e isso torna as coisas mais difíceis para as pessoas com leitores de tela.</li> <li>tenha um <a href="http://www.sitemaps.org/">xml sitemap</a> , de preferência no local padrão \_<code>/sitemap.xml</code>\_.</li> <li>use <a href="http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html">\_<code>&lt;link rel="canonical" ... /&gt;</code>\_</a> quando você tiver vários urls que apontam para o mesmo conteúdo, esse problema também pode ser solucionado em <a href="http://www.google.com/webmasters/">ferramentas do google para webmasters</a> .</li> <li>use <a href="http://www.google.com/webmasters/">ferramentas para webmasters do google</a> e <a href="http://www.bing.com/toolbox/webmaster">ferramentas para webmasters do bing</a> .</li> <li>instale <a href="http://www.google.com/analytics/">google analytics</a> logo no início (ou uma ferramenta de análise de código aberto como <a href="http://piwik.org/">piwik</a> /).</li> <li>saiba como <a href="https://en.wikipedia.org/wiki/robots\_exclusion\_standard">robots.txt</a> e as aranhas dos mecanismos de pesquisa funcionam.</li> <li>redirecione solicitações (usando \_<code>301 moved permanently</code>\_) solicitando \_<code>www.example.com</code>\_ para \_<code>example.com</code>\_ (ou o contrário) para impedir a divisão da classificação do google entre os dois sites.</li> <li>saiba que pode haver aranhas mal comportadas por aí.</li> <li>se você tiver conteúdo não textual, procure as extensões de mapa do site do google para vídeos, etc. há algumas informações boas sobre isso em <a href="https://stackoverflow.com/questions/72394/what-should-a-developer-know-before-building-a-public-web-site#167608">tim farley's answer</a> .</li> </ul><p><strong> tecnologia </strong></p><ul> <li>entenda <a href="http://www.ietf.org/rfc/rfc2616.txt"> http </a> e coisas como get, post, sessões, cookies e o que significa ser "sem estado".</li> <li>escreva seu <a href="http://www.w3.org/tr/xhtml1/"> xhtml </a> / <a href="http://www.w3.org/tr/rec-html40/"> html </a> e <a href="http://www.w3.org/tr/css2/"> css </a> de acordo com as especificações <a href="http://www.w3.org/tr/">w3c</a> e certifique-se de que eles <a href="http://validator.w3.org/">validam</a> /. o objetivo aqui é evitar os modos peculiares do navegador e, como bônus, facilitar o trabalho com navegadores não tradicionais, como leitores de tela e dispositivos móveis.</li> <li>entenda como o javascript é processado no navegador.</li> <li>entenda como o javascript, as folhas de estilo e outros recursos usados ​​por sua página são carregados e considere seu impacto no <em> desempenho percebido </em>. agora, é amplamente considerado adequado <a href="https://developer.yahoo.com/blogs/ydn/high-performance-sites-rule-6-move-scripts-bottom-7200.html">mover scripts para o final das páginas</a> das suas páginas, com exceções que normalmente são coisas como aplicativos de análise ou shims html5.</li> <li>entenda como a sandbox javascript funciona, especialmente se você pretende usar iframes.</li> <li>esteja ciente de que o javascript pode e será desativado e que ajax é, portanto, uma extensão, não uma linha de base. mesmo que a maioria dos usuários o deixe ligado agora, lembre-se de que <a href="http://noscript.net/">noscript</a> está se tornando mais popular. embora os robôs de rastreamento modernos suportem a indexação de conteúdo gerado por javascript, considere usar a renderização no servidor para outros robôs ou usuários que desativaram o javascript.</li> <li>aprenda a diferença <a href="http://www.bigoakinc.com/blog/when-to-use-a-301-vs-302-redirect/">entre os redirecionamentos 301 e 302</a> (esse também é um problema de seo).</li> <li>aprenda o máximo possível sobre sua plataforma de implantação.</li> <li>considere usar uma <a href="https://stackoverflow.com/questions/11578819/css-reset-what-exactly-does-it-do">redefinir folha de estilos</a> ou <a href="http://necolas.github.com/normalize.css/">normalize.css</a> .</li> <li>considere estruturas javascript (como <a href="http://jquery.com/">jquery</a> , <a href="http://mootools.net/">mootools</a> , <a href="http://www.prototypejs.org/">prototype</a> , <a href="http://dojotoolkit.org">dojo</a> ou <a href="http://developer.yahoo.com/yui/3/">yui 3</a> ), que ocultará muitas diferenças do navegador ao usar javascript para manipulação de dom.</li> <li>reunindo o desempenho percebido e as estruturas js, considere usar um serviço como a <a href="http://developers.google.com/speed/libraries/devguide">api das bibliotecas do google</a> para carregar estruturas para que um navegador possa usar uma cópia da estrutura que ele já armazenou em cache, em vez de fazer o download de uma cópia duplicada. copiar do seu site.</li> <li>não reinvente a roda. antes de fazer qualquer coisa, procure um componente ou exemplo de como fazê-lo. há 99% de chance de alguém ter feito isso e lançado uma versão oss do código.</li> <li>por outro lado, não comece com 20 bibliotecas antes mesmo de decidir quais são suas necessidades. particularmente na web do lado do cliente, onde quase sempre é mais importante manter as coisas leves, rápidas e flexíveis.</li> </ul><p><strong> correção de erros </strong></p><ul> <li>entenda que você gastará 20% do seu tempo codificando e 80% dele mantendo, portanto, codifique de acordo.</li> <li>configure uma boa solução de relatório de erros.</li> <li>tenha um sistema para as pessoas entrarem em contato com você com sugestões e críticas.</li> <li>documente como o aplicativo funciona para futuras equipes de suporte e pessoas que realizam manutenção.</li> <li>faça backups frequentes! (e verifique se esses backups estão funcionando) tenha uma estratégia de restauração, não apenas uma estratégia de backup.</li> <li>use um sistema de controle de versão para armazenar seus arquivos, como <a href="http://subversion.apache.org/">subversion</a> , <a href="http://mercurial.selenic.com/">mercurial</a> ou <a href="http://git-scm.org">git</a> .</li> <li>não se esqueça de fazer seu teste de aceitação. estruturas como <a href="http://seleniumhq.org/">selenium</a> podem ajudar. especialmente se você automatizar completamente seus testes, talvez usando uma ferramenta de integração contínua, como <a href="http://jenkins-ci.org/">jenkins</a> .</li> <li>verifique se você possui log suficiente usando estruturas como <a href="http://logging.apache.org/log4j/">log4j</a> , <a href="http://logging.apache.org/log4net/">log4net</a> ou <a href="http://log4r.rubyforge.org/">log4r</a> . se algo der errado no seu site ao vivo, você precisará descobrir como.</li> <li>ao fazer o log, certifique-se de capturar as exceções tratadas e não tratadas. relate/analise a saída do log, pois mostrará onde estão os principais problemas em seu site.</li> </ul><p><strong> outros </strong></p><ul> <li>implemente monitoramento e análise do lado do servidor e do cliente (um deve ser proativo em vez de reativo).</li> <li>use serviços como uservoice e intercom (ou qualquer outra ferramenta similar) para manter contato constante com seus usuários.</li> <li>siga <a href="http://nvie.com/about/">vincent driessen</a> 's <a href="http://nvie.com/posts/a-successful-git-branching-model/">git branching model</a> </li> </ul><p>muitas coisas foram omitidas não necessariamente porque não são respostas úteis, mas porque são muito detalhadas, estão fora do escopo ou vão um pouco longe demais para alguém que deseja obter uma visão geral do que deve saber. sinta-se à vontade para editar isso também, provavelmente perdi algumas coisas ou cometi alguns erros.</p>
<p>não existem "regras", apenas "diretrizes".</p><p>com isso, quero dizer que, em teoria, não há nada que o impeça de projetar qualquer interface que você queira, no entanto, existem vários fatores que podem impedir que você atinja seu objetivo.</p><ol> <li> <p>navegadores funcionam de uma certa maneira. o html pode apenas sugerir um layout para a página; portanto, embora você tenha um ótimo design que funcione no papel, ele poderá falhar em alguns navegadores com algumas resoluções de tela.</p> </li> <li> <p>os usuários esperam que certos elementos estejam em determinados locais. isso nem sempre é uma expectativa consciente, mas criada a partir da exposição a outros aplicativos, etc. se o seu design for muito diferente, eles podem não "entender" e achar seu aplicativo difícil, se não impossível, de usar.</p> </li> </ol> olá rafael,quando for construir elementos html na página, uma dica é você inserir diretamente no corpo, para evitar o uso excessivo do echo e também porque não é uma boa prática de programação o jei... <p>a resposta mais simples para sua pergunta é que os campos da ciência da computação e do desenvolvimento de software são muito novos e pouco compreendidos. embora todas as disciplinas científicas e de engenharia estejam avançando mais rapidamente nos tempos modernos, outros campos têm muito mais experiência para aproveitar e há uma compreensão compartilhada muito mais ampla de como elas funcionam.</p><p>por exemplo, apesar dos recentes avanços na ciência dos materiais, os engenheiros civis sabem há cerca de 2000 anos como construir um arco que não cairá, e isso é algo que pode ser ensinado e aprendido na universidade com relativamente pouca controvérsia. embora eu concorde totalmente com você sobre as técnicas que os desenvolvedores de software devem aprender, esse contrato é baseado na experiência pessoal e no raciocínio informal. para ser uma "melhor prática" aceita socialmente, precisamos de dados quantitativos que podem ser muito caros para reunir: quanto o controle de versão ajuda? como isso ajuda? teste de unidade? podemos argumentar sobre a eficácia de várias técnicas, mas na verdade provar que a eficácia seria muito cara. precisávamos executar um projeto de software completo e realista do começo ao fim, inúmeras vezes, com grupos de programadores com experiência equivalente, usando técnicas diferentes. no mínimo, precisaríamos de muitos dados sobre projetos existentes que esses projetos não estariam dispostos a liberar.</p><p>os engenheiros civis têm milhares de anos de pontes para examinar, com muitas informações. os desenvolvedores de software, por outro lado, têm apenas algumas décadas de informações, a maioria das quais é mantida em segredo, uma vez que há pouca motivação para as organizações coletarem e publicarem informações sobre a eficácia de seus desenvolvedores, mesmo que estejam coletando (o que geralmente não é necessário). 't).</p><p>há também alguma confusão de campos. desenvolvimento de software, ou "engenharia" de software, é realmente uma coisa diferente da ciência da computação. os desenvolvedores de software precisam de um conhecimento prático da ciência da computação, mas trabalhar nos limites da complexidade algorítmica ou raciocinar sobre paralelismo não é algo que um programador que trabalha faz todos os dias; da mesma forma, um verdadeiro "cientista da computação" escreverá um monte de código descartável que simplesmente não funciona ou não faz nada de interessante e não se beneficiará tanto do tipo de rigor que um produto de software real faria.</p><p>o surgimento da internet e da comunidade de código aberto pode fornecer dados suficientes para começar a responder a essas perguntas de maneira conclusiva, mas mesmo que as respostas estejam disponíveis amanhã, provavelmente levará 100 anos para que permeiem a sociedade internacional a ponto de todos concordarem com o que deve ser ensinado nas escolas.</p><p>finalmente, existem algumas considerações econômicas. faz um tempo relativamente curto, já que quase todos os envolvidos no desenvolvimento de software tiveram acesso fácil e barato a máquinas dedicadas para executar as ferramentas de desenvolvimento que desejarem. algumas décadas atrás, dedicar completamente uma máquina apenas para executar seus testes ou até abrigar uma história infinita de código-fonte teria parecido frivolamente caro para muitas pessoas.</p> Quando o documento é transferido através de HTTP, [as informações do cabeçalho HTTP são as informações crutial](http://www.w3.org/TR/html401/charset.html#h-5.2.2) :



> 
> [...] agentes de usuário conformes devem observar as seguintes prioridades para determinar a codificação de caracteres de um documento (da mais alta prioridade para a menor):
> 
> 
> 1. Um HTTP " `charset`" parâmetro em um " `Content-Type`campo".
> 2. Uma `META`declaração com " `http-equiv`" definido para " `Content-Type`" e um valor definido para " `charset`".
> 3. O `charset`conjunto de atributos em um elemento que designa um recurso externo.
> 
> 
> 


Portanto, verifique se você declarar a codificação de caracteres no [`Content-Type`campo de cabeçalho](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.17) e não apenas dentro do documento. <p>tudo em ordem também, vamos lá:</p>
<ul><li>impactos:</li></ul>
<p>em alguns projetos pode haver uma grande necessidade de refatoração e configuração, pois, isso vai mudar a maneira como as importação e carregamentos estão sendo feitos.</p>
<ul><li>benefícios:</li></ul>
<p>separar os códigos em pequenas partes ai garantir uma maior performance do projeto, irá consumir menos banda de internet do usuário, trafegar menos informações na rede.</p>
<ul><li>tradeoff:</li></ul>
<p>mas, nem tudo são flores, em alguns momentos pode ser que não seja aconselhável essa separação.</p>
<p>uma vez que a gente baixou tudo, a aplicação irá funcionar normalmente, a mudança de telas acontecerá mais rápido.</p>
<p>quando separados em pequenos pedaços, o primeiro carregamento será mais rápido, mas, as mudanças de telas irão ter a necessidade de baixar os arquivos correspondentes para aquele novo pedaço, sendo assim, será necessário adicionar loaders ou algum indicador visual para o usuário.</p>
<p>as vezes pode trazer uma complexidade maior para o projeto também.</p>
<p>cabe a vocês (time) definir se faz sentido ou não e onde faz sentido ou não faz.</p>
<ul><li>mostrar resultados:</li></ul>
<p>infelizmente não posso, são projetos internos do meu trabalho e não posso mostrar.</p>
<p>mas já pegamos páginas de 13mb de <em>download</em> e baixamos para 3mb, por exemplo.</p>
<p>espero ter ajudado.</p> :smile: certificações são sempre bem-vindas, mas foca em certificações de acordo com a área profissional que você pretende estudar. quanto mais certificações melhor. pelo que estudei desta certificação ela é muito boa, mas para a área de programação mais baixa.

eu considero web developer a programa… <p>não acho que eles sejam mutuamente exclusivos, mas, nos casos em que são, você deve observar o que seus clientes desejam/precisam.</p><p>qualquer interface pode ser simplificada movendo funcionalidades complexas para outro local. eu acho que esse é o principal compromisso. para facilitar o uso para o usuário médio, você precisa torná-lo mais complicado para o usuário avançado. eles precisam fazer mais alguns cliques para obter suas coisas.</p><p>mas é claro que muitas vezes o software pode ser facilitado tanto para usuários avançados quanto para usuários casuais, sem sacrificar a usabilidade de nenhum deles. uma coisa importante é criar recursos ortogonais que possam ser combinados facilmente. muitas vezes, o software é complicado porque há muitos recursos sobrepostos. em vez disso, ao criar alguns recursos distintos que podem ser facilmente combinados, o software pode ser muito mais flexível e simples.</p><p>descobrir isso criando uma matriz de objeto/ação. liste o número de objetos diferentes no seu aplicativo ao longo de um eixo e as ações que você pode executar neles em outro eixo. a matriz não deve ser muito escassa.</p> <p>um fator importante para que as atualizações funcionem sem problemas é não fazer nada que confunda o gerenciador de pacotes. ou seja, você não deve tocar em áreas do sistema que o gerente de pacotes espera que sejam seu domínio. alguns exemplos concretos.</p><p>se você mesmo compilar/instalar programas usando o ./configure; faço; make install install, não os coloque diretamente em <code>/usr</code>. é melhor usar <code>/usr/local</code> ou <code>/opt</code>, como alternativa (ainda melhor) para lançar seus próprios pacotes deb.</p><p>ao remover pacotes, você pode fazer uma remoção normal ou uma limpeza explícita. a menos que você limpe o pacote, o gerenciador de pacotes pode deixar os arquivos para trás em <code>/etc</code>, <code>/var</code> e assim por diante. não exclua esses arquivos você mesmo, pois o gerenciador de pacotes espera que eles estejam lá. em vez disso, use o gerenciador de pacotes para limpar explicitamente os restos do pacote.</p><p>usar o pacote deb de repositórios de terceiros deve ser teoricamente seguro, assumindo que eles sejam cuidadosamente construídos etc. no entanto, para estar do lado seguro, você pode querer considerar remover esses pacotes e/ou repositórios antes de executar uma atualização para uma nova versão do ubuntu.</p><hr><p>ok, deixe-me ver se posso adicionar mais carne a esta resposta ...</p><p>primeiro de tudo, tudo o que você faz no diretório inicial é perfeitamente seguro em relação ao gerenciador de pacotes. ele nunca tocará em nada em <code>/home</code>.</p><p>(obviamente, você ainda pode causar muita confusão ao fazer coisas ruins no diretório inicial. felizmente, isso geralmente é recuperado removendo os arquivos de configuração quebrados do diretório inicial e permitindo que eles sejam recriados por padrão no diretório inicial. próximo uso: observe que a recriação automática da configuração padrão é válida apenas para seus arquivos de configuração pessoal, não para todo o sistema em <code>/etc</code>)</p><p>no papel de um usuário de desktop (avançado), acho que a criatividade mais comum em todo o sistema será a instalação de aplicativos extras, bibliotecas, modos emacs, etc.? novamente, a parte realmente importante é sempre colocar nenhum item do pacote deb em <code>/usr/local</code> em vez de em <code>/usr</code>; usar <code>/usr/local/bin</code> em vez de <code>/usr/bin</code>, usar <code>/usr/local/share/emacs/23.1</code> em vez de <code>/usr/share/emacs/23.1</code> e assim por diante.</p><p>depois de começar a brincar com os daemons do servidor, em breve você será confrontado com a configuração geral do sistema em <code>/etc</code>. embora você geralmente possa modificar arquivos em <code>/etc</code>, "nunca" deve realmente remover um arquivo ou diretório, a menos que tenha sido você quem o criou. da mesma forma, você deve ter cuidado ao criar novos arquivos, caso eles colidam posteriormente com um arquivo de configuração que o gerenciador de pacotes deseja criar. dito isto, definitivamente existem arquivos que você pode (e deve) ser criado em <code>/etc</code>. um dos exemplos mais comuns é definir o apache virtualhosts em <code>/etc/apache2/sites-available</code>.</p><p>pode haver momentos em que você deseja criar arquivos ou diretórios em <code>/var</code>. embora seja um lugar completamente diferente de <code>/etc</code>, ainda considere as mesmas regras sobre ser cuidadoso e fazer as coisas sob consideração individual.</p><p>caso você queira saber mais, não fará mal dar uma olhada no <a href="http://www.pathname.com/fhs/">padrão de hierarquia do sistema de arquivos (fhs)</a> ou no <a href="http://www.debian.org/doc/debian-policy/">manual de políticas debian</a> . embora possa ser um exagero em responder à sua pergunta original, ainda é uma boa leitura.</p> <p>olá leandro, tudo bom?</p>
<p>os pré-requisitos para os cursos são sugestões de conteúdo que podem ser importantes para que você acompanhe o curso mas não são obrigatórios.</p>
<p>caso você se sinta confortável para fazer o curso sem fazer seus pré-requisitos, vá em frente, mas lembre-se que pode sempre parar e iniciar o curso pré-requisito se tiver dificuldades.</p>
<p>no caso do curso de spring, temos como pré-requisito o <a target="\_blank" href="https://cursos.alura.com.br/course/servlet-3-e-fundamentos-web" rel="nofollow">curso de servlets</a>. porém este tem como pré-requisitos outros cursos como o <a target="\_blank" href="https://cursos.alura.com.br/course/http-fundamentos" rel="nofollow">curso de http</a> e o <a target="\_blank" href="https://cursos.alura.com.br/course/java-util-lambdas" rel="nofollow">curso de java, parte 6</a>.</p>
<p>como mencionei acima, se você já tem alguma familiaridade com esses assuntos, é bem tranquilo pular os pré-requisitos e seguir direto para o curso final. mas se tiver alguma dúvida em um assunto ou código do curso, dê uma olhada nos pré-requisitos e veja se algum deles ajuda a resolver o seu problema.</p>
<p>lembre-se também que você pode vir aqui no fórum tirar suas dúvidas sobre o conteúdo do curso &#61;)</p>
<p>espero ter ajudado! um abraço e bons estudos!</p> bem...nem o arquivo disponibilizado no site do fabricante é 100%, pois pode sofrer um ataque de um cracker e se tornar uma "ameaça"....rs...


agora...primeiro que tudo que vc baixar de terceiros, podem ou nao ser alterados....vai da sua conciência e sorte...não tem como garantir nada..... sites como mega, rapidshare, ou mesmo torrents, etc.... vc não sabe quem disponibilizou ou o interresse de disponibilizar......instalar ou não vai da conciência de cada um.....


segundo que programas crackeados não tem garantia nenhuma.... imagine.... o cara cria um "programa" (crackeador) que ilegalmente lhe permitirá usar o programa sem pagar....se é ilegal...que garantia quem fez o crack pode lhe dar?..... é tão "sinistro" que vc tem que desativar o antivirus para usar o crack...portanto, tb é "sorte"....e se dar qualquer erro o "problema" é todo seu....


então vc pode baixar e usar qualquer programa "ilegal"....mas caso der errado o problema é todo seu....assim como se der certo a sorte é sua.....não tem como ninguém aqui lhe garantia nada....e não adianta passar o antivirus, pois os antivirus detectam o crack como nocivo e remove e vc não poderá usar o programa....