Tel: (11) 3589-5008
contato@csbconsulting.com.br
Microsoft tem acordos de patente com mais da metade dos fabricantes de Android
Contrato firmado com a Compal Electronics, que fatura 28 bilhões de dólares por ano, busca dar segurança jurídica para a companhia.
A Microsoft anunciou um acordo de patentes com a empresa taiwanesa Compal Electronics para fornecer cobertura para o portfólio de patentes dos tablets, celulares, e-readers e outros aparelhos da Compal que usam o sistema Android ou a plataforma Chrome, ambos da Google. A Compal fatura cerca de US$ 28 bilhões por ano.
Como resultado do acordo, as companhias que possuem metade dos aparelhos Android agora entram nos acordos de licenças de patentes com a Microsoft, revelaram seus gerentes gerais, Brad Smith e Horacio Gutierrez.
Mais de metade da indústria global de fabricantes por contrato de aparelhos Android e Chrome está agora sob licença do portfólio de patentes da Microsoft, seguindo o exemplo do acordo com a Compal e outros também recentes, feitos com companhias como a Wistron e a Quanta Computer, afirmou a Microsoft.
A companhia alega sucesso parecido para o seu programa de licenciamento com empresas produzindo aparelhos sob suas próprias marcas, que ela chama de fabricantes originais de equipamento (OEMs).
A empresa anunciou no mês passado um acordo de licenciamento cruzado de patentes com a Samsung. O acordo dá à Microsoft o pagamento de royalties referentes aos telefones celulares e tablets da fabricante coreana com o sistema móvel Android.
Após o acordo com a Samsung e os mais recentes, a Microsoft possui agora acordo com fabricantes OEMs que correspondem a 53% de todos os smartphones Android nos Estados Unidos, afirma o conselho geral da fabricante.
Publicada em 25 de outubro de 2011 às 09h30
Fonte: IDG News Service / EUA
A CSB Consulting agora é Microsoft Partner
A partir de agora, a CSB Consulting passa a integrar a Microsoft Partner Network.
O que é o
O Microsoft Partner Network é uma comunidade que ajuda os parceiros da Microsoft a atingir todo seu potencial.
Atualmente, 640 mil parceiros da Microsoft formam uma das mais diversificadas e ativas redes no mundo, com amplas oportunidades para desenvolver relações confiáveis com seus clientes. A visão do Microsoft Partner Network é fornecer aos parceiros:
• Oportunidades para fortalecer capacidades.
• Conhecimento especializado para ajudar a atender melhor os clientes.
• Comunidades que estimulam inovação e conexão.
Trabalhando em conjunto, a Microsoft e os parceiros podem continuar com o foco na criação de soluções inovadoras que gerem lucratividade e mantenham a vantagem competitiva.
Fonte: http://partner.microsoft.com/brasil/
SQL Server 2008
Visão Geral do Produto
Seus Dados, em Qualquer Lugar, a Qualquer Hora
O SQL Server 2008 cumpre a visão da Plataforma de Dados da Microsoft ao ajudar sua organização a gerenciar quaisquer dados, em qualquer lugar e a qualquer hora. Armazene dados de documentos estruturados, semiestruturados e não estruturados, como imagens e mídia avançada, diretamente dentro do banco de dados. O SQL Server 2008 fornece um conjunto avançado de serviços integrados que permitem a você fazer mais com seus dados, como consultar, pesquisar, sincronizar, relatar e analisar.
O Microsoft SQL Server 2008 proporciona os mais altos níveis de segurança, confiabilidade e escalabilidade para suas aplicações críticas. Para aproveitar novas oportunidades no agitado mundo dos negócios, as empresas precisam da capacidade de criar e implantar rapidamente soluções orientadas a dados. O SQL Server 2008 reduz o tempo e o custo de gerenciamento e desenvolvimento de aplicações.
Acesse dados de toda a empresa e forneça controle sobre seus dados, não importando onde estiverem armazenados — dos maiores servidores dentro do datacenter a estações de trabalho e dispositivos móveis. O SQL Server 2008 oferece uma plataforma abrangente que fornece inteligência onde os usuários precisam dela. Profissionais da informação podem acessar dados diretamente usando as ferramentas que usar diariamente, como o 2007 Microsoft Office System.
O SQL Server 2008 permite que dados sejam consumidos a partir de aplicações personalizadas desenvolvidas usando o Microsoft .NET e o Visual Studio e de dentro de arquiteturas orientadas ao serviço (SOA) e processos de negócios através do Microsoft BizTalk Server.
Origem do Artigo: Site da Microsoft Brasil
O que é .NET
Introdução à Microsoft .NET
.NET é uma plataforma de software que conecta informações, sistemas, pessoas e dispositivos. A plataforma .NET conecta uma grande variedade de tecnologias de uso pessoal e de negócios, de telefones celulares a servidores corporativos, permitindo o acesso a informações importantes, onde e sempre que forem necessárias.
Desenvolvido sobre os padrões de Web Services XML,.NET possibilita que sistemas e aplicativos, novos ou já existentes, conectem seus dados e transações independente do sistema operacional, tipo de computador ou de dispositivo móvel que sejam utilizados, ou que linguagem de programação tenha sido utilizada na sua criação.
O .NET é um "ingrediente" presente em toda a linha de produtos Microsoft, oferecendo a capacidade de desenvolver, implementar, gerenciar e usar soluções conectadas através de Web Services XML, de maneira rápida, barata e segura. Essas soluções permitem uma integração mais rápida e ágil entre os negócios e o acesso a informações a qualquer hora, em qualquer lugar e em qualquer dispositivo.
Conectando seu mundo
A idéia fundamental por trás do Microsoft .NET é uma mudança de foco na informática, passando de um mundo de aplicativos, Web sites e dispositivos isolados para uma infinidade de computadores, dispositivos, transações e serviços que se conectam diretamente e trabalham em conjunto para fornecerem soluções mais amplas e ricas.
As pessoas terão o controle sobre como, quando e que informações serão fornecidas a elas.Os computadores, sistemas e serviços serão capazes de colaborar e interoperar mutuamente em favor do usuário, e as empresas poderão oferecer seus produtos e serviços aos clientes certos, na hora certa, da forma certa, combinando processos de maneira muito mais granular do que é possível hoje.
Origem do Artigo: Site da Microsoft Brasil
Os requisitos e o sucesso do seu projeto
Antes de começar de fato este artigo, quero passar algumas informações que colhi na minha pesquisa:
· Mais de 30% dos projetos são cancelados antes de serem completados
· Mais de 70% dos projetos falham na entrega das funcionalidades esperadas
· A média de falhas de projetos estoura em mais de 189% do orçamento e extrapola em 222% do cronograma previsto
Os seguintes fatores ajudam:
. Falta de informações dos usuários: 12,8%
. Requisitos/especificações incompletos: 12,3%
. Ausência de gerência de mudanças e especificações: 11,8%
O propósito da gerência de requisitos é estabelecer um entendimento comum entre o cliente/usuário e a equipe de IT/desenvolvimento em relação aos requisitos do cliente/usuário.
Parece simples mas não é! O desafio é tão grande que está presente até nas especificações do CMM (Capability Maturity Model). Além disto, estes requerimentos não ficam somente com a equipe de desenvolvimento: eles se propagam por todo o IT. Áreas como suporte, produção, telecom e outras são impactadas pelos requisitos que têm relação somente com aspectos internos destas áreas e que advêm dos requisitos básicos da aplicação em questão.
Pontos onde falhamos
1. Uma pobre gerência de requisitos:
Normalmente há a continuidade dos projetos mesmo com falhas nas informações dos usuários e sem a uma clara visão do problema que estamos tentando resolver
2. Falhas na gerência de mudanças:
Mudanças nos requerimentos e outras modificações são inevitáveis, apesar de raramente rastrearmos e entendermos o impacto destas mudanças
3. Controle de qualidade pobre
Temos fracas métricas de qualidade, pequeno conhecimento dos processos que afetam a qualidade, nenhum feedback para modificar o processo após testemunharmos os efeitos de uma estratégia de desenvolvimento particular (Web por exemplo)
4. Pequeno controle de cronogramas e custos Planejamento cuidadoso é a exceção enquanto expectativas irreais são a norma.
Com base nestes dados acima, acho que temos tema suficiente para conversarmos.
Vamos examinar o primeiro ponto:
Uma das coisas mais comuns é a falta de entendimento entre os clientes e os analistas. Acho que todos já viram um desenho muito comum nas áreas de desenvolvimento que mostra as várias fases de um projeto ilustrado por uma árvore e um balanço.
As perspectivas e a visão que os vários interessados no projeto têm nem sempre estão ajustadas. E para o pessoal de TI as coisas são um pouco mais difíceis porque o entendimento vai além de simplesmente entender qual é o negócio. Passa por verificar quais os impactos que a nova aplicação vai trazer para o ambiente já estabelecido, quais tecnologias serão envolvidas e etc...
Temos então vários tipos de requisitos: funcionais, de teste, de performance, de ambiente, uma gama enorme que precisa ser gerenciada e distribuída entre a equipe de TI em suas respectivas responsabilidades.
Passa a existir um grande problema que é gerenciar os múltiplos requisitos. Não importa se você usa papel, planilha, ou alguma ferramenta. O principal desafio é garantir os seguintes pontos:
Você e os seus entenderam o que o cliente quer
Você e os seus têm a mesma percepção do problema
Você consegue compartilhar com outros os problemas que vem da solução proposta
Você consegue acompanhar a execução e a implementação dos requisitos
Você já pensou nisto? Como resolveu? Quais foram os problemas que enfrentou? Quanto custou?
Vamos para o segundo ponto:
Temos a certeza de que vão ocorrer mudanças, sejam elas advindas do negócio, dos problemas enfrentados para sua implementação, pela ausência de recursos ou outro motivo que os gerentes conseguem pensar sem fazer força.
O problema em questão é como acompanhá-las. Mais uma vez os recursos para fazer o acompanhamento são vários, apesar de raramente se faz algumas análises importantes.
Entender o que cada mudança significa para cada parte do seu projeto é difícil, mas calcular o impacto que elas trazem para o todo é quase impossível.
A análise de impacto que cada mudança traz é uma atribuição da equipe envolvida no projeto e que normalmente não ocorre na sua total extensão. O que as pessoas fazem é calcular o tempo adicional ou alguns outros itens, sem ter também um rastreamento de que requisitos serão atingidos com as mudanças. E normalmente de forma manual... e sem que outras equipes de TI que vão suportar a futura aplicação tenham acesso às mudanças.
Com isto se têm uma perda de produtividade enorme. Aqueles que receberam a solicitação de mudança, seja ela evolutiva, corretiva ou emergencial, precisam comunicar as decisões de mudanças rapidamente para os outros de forma que haja uma diminuição da perda de recursos gastos em re-trabalhos ou conflitos. E não somente no desenvolvimento mas no suporte, produção e etc...
Este controle de mudanças traz também outros benefícios como começar a ter um histórico do projeto para servir de base de conhecimento para os próximos. Entender quanto tempo se investiu em determinada atividade motivada por uma mudança e melhorar as métricas gerais. Na realidade até ter algumas informações como qual é a carga de trabalho por elemento da equipe, quais são as solicitações em aberto, por prioridade, criticidade, tempo: bom uma infinidade de métricas e dados podem vir desta gerência, que é barata e efetiva.
Quando chegamos a este ponto, entendemos melhor o item 3 lá atrás.
Quais são as métricas de qualidade que você usa hoje nos seus projetos?
A pergunta é dolorosa mas normalmente mostra uma realidade muito pior do que queremos ver. Normalmente temos muito poucas e confiáveis métricas para saber onde estamos e o quanto já fizemos. É normal termos um projeto que está 80% pronto mas só falta um pouquinho. Só que este pouquinho às vezes se torna outro projeto. Mostrei as estatísticas no início do texto.
Gosto do que o Gartner chama de qualidade: Qualidade nos requisitos, no controle das mudanças e nos testes. Acho um tripé bastante claro e simples e que com ele dá para fazer várias análises em relação a se estabelecer métricas e pontos de controle.
O desafio mais uma vez é como implementar este tripé. Até mesmo porque a maioria não tem histórico para saber quanto custo não ter.
Nos meus contatos com os clientes há uma constatação de que está havendo uma maturidade em relação ao tripé descrito acima. Mais e mais empresas precisam ter diferenciais competitivos e rever seus processos de produção, seja no desenvolvimento seja na produção, são fatores de aumento de lucratividade ou diminuição de prejuízos.
Há vários institutos tratando do assunto métricas e meu intento aqui é só realçar a importância de ser ter algum, mesmo que depois se mude. Criar a consciência da importância de se medir e ter histórico que foi feito.
Independente das métricas que você pode escolher, é importante que você tenha ferramentas para fazer as duas gerências que trato desde o início deste texto: Requisitos e Mudanças
Sempre falo sobre o custo de não se ter ou ter alguma coisa e sempre tento analisar este fato. Penso que você também pode fazer esta mesma análise. E acho que você pode chegar a conclusões incríveis.
Agora vamos finalizar com os problemas de cronogramas e custos.
Várias vezes somos simplesmente informados de que temos uma tarefa a realizar e que temos um determinado prazo para tal. Este prazo foi gerado a partir de um desejo, nem sempre realista.
Não temos métricas ou históricos para antecipar a duração ou o custo de determinada atividade. Nossas informações são muitas vezes baseadas na experiência pessoal de cada um. Isto faz com que o nível de erro fique muito alto de acordo com as estatísticas do início do texto.
Não podemos nos eximir de ter algum planejamento. Porém o como vamos fazê-lo é determinante para diminuir a margem de erros. Os riscos associados à falta de planejamento são críticos para todo o IT, não somente para o desenvolvimento.
O custo dos riscos é proporcional à ausência ou cuidado no planejamento. E para fazermos este planejamento é fundamental termos todo cuidado na gerência dos requisitos e das mudanças.
Pensando simplesmente: O sucesso do projeto é proporcional à qualidade gerencial que investimos nele.
Fonte: autor desconhecido
VB.NET - Otimização e Performance
Veremos nessa matéria, dicas e regras para melhorarmos a performance de nossas aplicações usando Visual Basic .NET.
Quantas vezes nós já ouvimos falar que a linguagem X é mais rápida que a linguagem Y? Ou que a linguagem W é mais segura que a linguagem Z? Isso gera algumas discursões que nunca tem fim. Mas no fundo, o que acontece na maioria das vezes é que os programadores se esquecem que o quanto uma linguagem é segura ou performática depende quase sempre da forma como ela é usada e para que fim ela é usada.
Para não causar polêmica, vou comparar duas linguagens da Microsoft, o VB6 e VB.NET. Quando o VB.NET chegou ao mercado, em 2001, vi muitos desenvolvedores dizendo que o VB6 era muito mais rápido do que o VB.NET, e cansei de responder perguntas em fóruns de discursão onde o cidadão até dava exemplo disso. Bem, na grande maioria das vezes eles estavam errados, o problema é que não dominavam a nova linguagem, menos ainda o ambiente de desenvolvimento, portanto o que faziam era simplesmente a conversão de VB6 -> VB.NET. E isso está bem longe de ser a melhor forma de se comparar performance. Quando refiz muito destes códigos, tchan, tchan, tchan, milagre! O código em VB.NET foi mais rápido. Por que?
Veremos isso nas próximas linhas. Procure ter em mente a dobradinha: Performance X Segurança. Onde a segurança é o foco, a performance sai prejudicada e vice versa, embora ambas tenham sempre que andar juntas. Ache o meio termo.
Como esse assunto é muito amplo, vou dividi-lo em partes:
- Tipos de Dados
- Declarações
- Operações
- Procedimentos
- Outras Otimizações
Tipos de Dados
O tipo de dado que você escolhe para suas variáveis, propriedades, argumentos de procedimentos, variáveis de retorno, enfim, tudo isso afeta em muito a performance de sua aplicação.
Value Type x Reference Type
Tipos Value Type armazenam seus valores no seu próprio espaço de memória e são alocados na memória chamada Stack. Já os Reference Type guardam no seu espaço de memória apenas um ponteiro para o local onde o dado está armazenado, e que ficam em um espaço de memória chamado Heap. O gerenciamento da Heap é bem mais caro que o do Stack, devido à alocação de memória, acesso ao dado via referência, GC (Garbage Collection), etc. Isso significa que a escolha por um tipo Value Type na maioria das vezes é a melhor escolha. Contudo, os Value Types tem uma desvantagem: Ocupam mais espaço na memória. No final, a melhor opção é: Caso você não necessite da flexibilidade dos Reference Type, use os objeto do tipo Value type.
Para saber mais:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbls7/html/vblrfvbspec6_1.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbls7/html/vblrfvbspec6_2.asp
Early e Late Binding e o tipo Object
Uma variável declarada como Object pode apontar (lembre-se do tipo Reference Type) para qualquer tipo de objeto. Essa flexibilidade tem um custo muito grande devido ao fato de esse tipo de variável ser sempre Late Bound. Quando o seu código acessa membros dessa variável, o CLR é obrigado a realizar checagem de tipo e procurar esse membro dentro do objeto em tempo de execução.
Os objetos declarados como Early Bound tem uma performance significantemente superior aos Late bound. O seu código se torna mais legível e o número de erros em tempo de execução cai significativamente. Portanto, evite o uso de variáveis do tipo Object quando não for estritamente necessário.
Para saber mais:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcn7/html/vaconEarlyLateBinding.asp
Tamanho dos tipos de dados
O tipo de dado mais eficiente é aquele que é usa o tamanho de dado nativo da plataforma. Ou seja, na plataforma de 32 bits o tipo de dados com 32 bits será o mais rápido. No .NET o tipo de dado que possui esse tamanho é o tipo Integer ou Int32. O próximo mais performático é o Long, e em seguida vem o Short e Byte. Pode não parecer, mas embora o tipo Integer seja maior do que o Short e o Byte, mesmo assim ele é mais rápido. Caso você queira usar o Short ou Byte e obter uma performance parecida com o do tipo Integer, desabilite a checagem de Overflow. É uma prática que eu desaconselho, principalmente por que hoje em dia memória já não é um grande problema.
Caso você precise valores fracionários, a melhor escolha é o tipo Double, já que os processadores de ponto flutuante realizam suas operações em precisão dupla. Depois vem o tipo Single e Decimal.
Box e Unboxing
Boxing é um processamento extra que o CLR faz quando você trata um Value Type como um Reference Type. Isso é necessário quando, por exemplo: Você declara um tipo Integer e atribui a ele um tipo de variável Object ou passa-o para uma procedure que receba um Object como argumento. Neste caso, o CLR precisa converter a variável para o tipo Object.
Se você subseqüentemente atribuir uma variável que sofreu boxing para uma variável Value Type, o CLR irá reverter isso. Esse processo chama-se Unboxing.
Boxing e Unboxing, geram uma degradação de performance muito grande. Portanto se sua aplicação faz constantes operações como essa, prefira declarar o objeto inicialmente como Reference Type. Outra forma de evitar isso é definir a diretiva Option Strict On.
Arrays
Quanto menor a dimensão do array melhor a performance, então procure calcular bem o quanto você terá que usar, para não alocar espaço desnecessariamente.
Jagged Arrays ( Array de Array ) são bem mais eficientes do que o array multidimensional, ou seja, A(6)(6) é mais eficiente do que A(6,6). Isto é devido ao fato de os Jagged Arrays sofrerem uma otimização para um array de uma dimenção. Só para constar, ele é aproximadamente 30% mais eficiente.
ArrayList
Essa classe é ideal para utilizar quando o array é dinâmico, ou seja, sobre muita alteração na sua dimensão. Usar ArrayList é muito mais performático do que usar o ReDim. A desvantagem do ArrayList é que os seus membros são do tipo Object, logo, Late Bound. Mas a vantagem sobre o uso do ReDim é tão grande que compensa essa desvantagem.
Nessa primeira parte, vimos como o uso do tipo de dado correto pode tornar seu código mais eficiente. Na próxima parte iremos ver mais dicas sobre operações, procedimentos e outras otimizações. Até breve.
Leonardo Bruno Lima - Microsoft MVP (Most Valuable Professional)
Web Services: um novo modelo de negócios para Internet
Um dos novos conceitos apresentados pela plataforma .NET são os chamados Web Services (ou Serviços Web). Mas o que são exatamente estes serviços?
Para entender melhor este conceito é importante entender porque o mercado sentiu a necessidade de criá-lo. Muito se fala em computação distribuída, mas a realidade é que quando estamos trabalhando dentro de um ambiente controlado como as redes corporativas da nossa empresa, é possível criar aplicações que sejam compartilhadas por diversos servidores e desktops. Podemos inclusive escolher qual o melhor modelo de objetos para se construir tais aplicações, como o uso do COM+ da Microsoft, CORBA da OMG ou mesmo EJB (Enterprise JavaBeans) da Sun.
O problema aparece quando pretendemos utilizar a infra-estrutura da Internet para executar remotamente tais objetos. Como trabalham em formato binário, estes objetos exigem uma porta de comunicação exclusiva, o que gera problemas quando precisamos atravessar um firewall, por exemplo. Por questões de segurança estas portas são fechadas, pois oferecem riscos de invasão à rede interna.
A mesmo tempo uma linguagem para troca de dados entre aplicativos vinha ganhando grande aceitação do mercado, a linguagem XML. Com o objetivo de se tornar a "língua franca" da Internet, o XML oferece uma série de benefícios em relação aos formatos antigos. Para começar, além do próprio dado, ele leva ainda a descrição do mesmo. Por ser arquivo texto, pode ser interpretado em qualquer plataforma ou sistema operacional e não apresenta problemas quando encontra um firewall, já que não apresenta risco de segurança. Por último, e um padrão controlado por um órgão independente, o W3C (World Wide Web Consortium).
Com tantos atributos é XML foi a base natural para criação do SOAP (Simple Object Application Protocol), modelo de objetos utilizados nos Web Services. As chamdas aos métodos públicos do objeto são chamados através de um arquivo XML, da mesma forma que a resposta a requisição também utiliza o mesmo formato.
Mais dois padrões foram criados em cima destes, o WSDL (Web Service Description Language), uma espécie de contrato que descreve como o Web Service funciona (por sinal um arquivo XML), e o UDDI (Universal Defenition, Discovery Interface), a páginas amarelas de Web Services. Um serviço onde é possível cadastrar o seu serviço, categorizado, dentro dos serviços UDDI da Internet. Hoje este serviço é oferecido pela IBM, HP, SAP e Microsoft através do http://uddi.microsoft.com , mas novos serviços estão aparecendo a cada dia.
Resumindo, os Web Services são componentes de software que são chamados a partir de outros aplicativos. São "páginas web" para outros computadores e não para seres humanos com as páginas HTML tradicionais. É a tecnologia que permite que computadores na Internet conversem entre si sem a intervenção direta dos usuários.
Com toda esta infra-estrutura de tecnologia disponível, os Web Services estão se tornando uma nova opção de negócio para as empresas que planejam utilizar a Internet como meio de troca de informações. Os Web Services estão oferecendo uma nova proposição de negócios às empresas de tecnologia e abrindo um novo universo de oportunidades.
Por: Leonardo Tolomelli - Gerente do Programa de Desenvolvedores da Microsoft Brasil
Rua Caramuru, 417 - Conjunto 102/104 - Vila Mariana - São Paulo - SP - (11) 3589-5008
(c) Copyright 2011 - CSB Consulting - Todos os direitos reservados.
