Anúncios

Janelas no Tempo

Olá,
Como vai? Espero que bem.

Este não é um post técnico.

Eu acredito que na vida encontramos pequenas surpresas que acabam por influenciar o modo como enxergamos as coisas. Surpresas que nos abrem os olhos, nos motivam a seguir em frente e nos apresentam um novo foco sobre a realidade. Leia mais deste post

Anúncios

Microsoft – e-books grátis (free e-books)

A Microsoft disponibilizou vários livros, em versão digital, de forma gratuíta.
Resolvi compartilhar alguns links através deste post.
Seguem os links:

Own Your Space–Keep Yourself and Your Stuff Safe Online
http://www.microsoft.com/download/en/details.aspx?displayLang=en&id=1522

Windows Phone Programming in C# For Beginners
http://blogs.msdn.com/b/mvplead/archive/2011/01/28/free-ebook-windows-phone-programming-in-c-for-beginners.aspx

Silverlight for Windows Phone
http://blogs.msdn.com/b/lebanon/archive/2011/02/25/free-ebook-silverlight-for-windows-phone.aspx

Windows Phone Programming in C#
https://www.facultyresourcecenter.com/curriculum/pfv.aspx?ID=8729&c1=en-us&c2=0&Login=&wa=wsignin1.0

Programming Windows Phone 7
http://blogs.msdn.com/b/microsoft_press/archive/2010/10/28/free-ebook-programming-windows-phone-7-by-charles-petzold.aspx

Programming Windows Phone 7 (Special Excerpt 2)
http://blogs.msdn.com/b/microsoft_press/archive/2010/08/02/free-ebook-petzold-s-programming-windows-phone-7-special-excerpt-2.aspx

Own Your Future: Update Your Skills with Resources and Career Ideas from Microsoft
http://blogs.msdn.com/b/microsoft_press/archive/2010/03/03/free-ebook-own-your-future-update-your-skills-with-resources-and-career-ideas-from-microsoft.aspx

11 Steps to Create a Successful Web Site
http://blogs.msdn.com/b/officeliveguy/archive/2009/02/12/fre-ebook-11-steps-to-create-a-successful-web-site.aspx

Build a website that sells
http://blogs.msdn.com/b/officeliveguy/archive/2009/02/12/free-e-book-build-a-website-that-sells.aspx

Windows Azure
http://blogs.msdn.com/b/innov8showcase/archive/2010/07/06/free-e-book-on-windows-azure.aspx

First Look Microsoft Office 2010
http://blogs.msdn.com/b/microsoft_press/archive/2010/01/20/free-ebook-first-look-microsoft-office-2010.aspx

Microsoft Office 365: Connect and Collaborate Virtually Anywhere, Anytime
http://blogs.msdn.com/b/microsoft_press/archive/2011/08/17/free-ebook-microsoft-office-365-connect-and-collaborate-virtually-anywhere-anytime.aspx

Moving to Microsoft Visual Studio 2010
http://blogs.msdn.com/b/microsoft_press/archive/2010/09/13/free-ebook-moving-to-microsoft-visual-studio-2010.aspx

Windows 7 troubleshooting tips
http://blogs.msdn.com/b/microsoft_press/archive/2009/10/26/free-e-book-windows-7-troubleshooting-tips.aspx

Understanding Microsoft Virtualization Solutions
http://blogs.msdn.com/b/microsoft_press/archive/2010/02/16/free-ebook-understanding-microsoft-virtualization-r2-solutions.aspx

Introducing Microsoft SQL Server 2008 R2
http://blogs.msdn.com/b/microsoft_press/archive/2010/04/14/free-ebook-introducing-microsoft-sql-server-2008-r2.aspx

Mais livros em http://social.technet.microsoft.com/search/en-US?query=Free%20e-book%3a&startindex=0

Por
Fernando Henrique Inocêncio Borba Ferreira.

Livro – 97 Coisas que todo arquiteto de software deve saber

Nessas últimas semanas comecei a ler o livro “97 Things Every Software Architect Should Know” (“97 Coisas que todo arquiteto de software deve saber”). Achei interessante o título do livro, pois parecia ser o resumo de diversas dicas sobre comportamento, arquitetura, compromisso e análise de sistemas… E realmente este é o conteúdo do livro…

A obra reúne pequenos textos de diversos arquitetos de software de grande expressão no cenário de tecnologia mundial. Alguns dos profissionais que colaboraram com o conteúdo desta obra trabalham em empresas como: Google, ThoughtWorks, Oracle, InfoQ, Blue River Systems Group, Software Engineering Professionals Inc, entre outros.

O livro é bastante interessante para quem procura um resumo de experiências e lições aprendidas. Não necessariamente precisa-se ser arquiteto de software para ler esse conteúdo (mesmo porque eu não sou arquiteto de software =] ), o conteúdo não é voltado para tecnologia, e sim para a troca de experiências.

Seguem algumas dicas que achei interessantes, existem muitas outras, mas gostaria de inicialmente dar destaque a estas:

– Não coloque seus objetivos técnicos a frente dos requisitos do sistema: não utilize uma tecnologia sem que ela seja necessária. Não deixe que suas tendências tecnológicas direcionem os requisitos do software.

– A arquitetura da aplicação determina sua performance: Esta parece ser uma característica óbvia, mas para muitos não é. Muitas empresas investem no tunning de servidores como solução de ganho de performance, mas performance não é apenas isso! A performance esta diretamente atrelada no modo como seu software foi arquitetado e construído. Para obter ganhos de performance, antes de mais nada, reveja sua arquitetura e procure por pontos a serem melhorados.

– Entenda a necessidade dos requisitos: Procure entender a real necessidade pela qual os requisitos são necessários. Nem sempre o requisito desejado pelo cliente será aquele que melhor atenderá a sua necessidade. Questione, pergunte, julgue as escolhas dos usuários e procure entender sua real necessidade.

– Tudo um dia irá falhar: Hardware é falível, então adicionamos redundância. Software é falível, nós adicionamos monitoramento para nos contar quando a aplicação falha, mas este monitoramento é um software, e também é falível. Seres humanos cometem erros, por isso automatizamos processos e ações. Redes são feitas de hardware e software, redes são falíveis. Todo mecanismo que utilizamos para mitigar um tipo de erro adiciona novos modos de falhas. Então o que devemos fazer, se existe a certeza de erro em nossos sistemas? Devemos aceitar que falhas são inevitáveis, e assim construir em nossos sistemas reações para alguns tipos específicos de falhas, que controlem o erro e protejam o restante do sistema.

– Patologia de padrões: Design patterns são uma das mais valiosas ferramentas disponíveis na arquitetura de software. O uso de padrões favorece a criação de soluções fáceis de compartilhar e entender. Design patterns tornam-se um problema quando nós tentamos utilizá-los em todo problema que encaramos. Não podemos deixar que nossa admiração por design patterns torne os problemas de nosso projeto mais complicados do que o necessário. Design patterns não são mágicos, e não necessariamente qualificam sua solução como ótima.

– Se existe apenas uma solução, então peça uma segunda opinião: A arquitetura de software objetiva encontrar a melhor solução para um dado problema, é muito difícil conseguir cobrir todos os requisitos e restrições com a primeira solução que vem a mente. Se você possui apenas uma solução em mente, e não possui experiência sobre o domínio do problema, então é preciso pedir ajuda a alguém mais experiente.

 

Por
Fernando Henrique Inocêncio Borba Ferreira.