Arquivo da tag: Desenvolvimento

Gulp, Grunt ou Webpack?

No meu post anterior, (Utilizando o Visual Studio Code para desenvolver com TypeScript), falei sobre como utilizar o Visual Studio Code para desenvolver sua aplicação com TypeScript. Caso não esteja familiarizado com TypeScript, veja o primeiro post da série: JavaScript e TypeScript – Breve histórico, definição e primeiros passos.

Parte do sucesso de um projeto depende de um bom setup, ou seja, de como você o configura para facilitar a sua vida durante o tempo de desenvolvimento.

No ciclo de vida de uma aplicação, é comum que novos recursos sejam adicionados a aplicação e, com isso, apareça a necessidade de instalação de uma nova versão da aplicação. Ou, durante o tempo de desenvolvimento mesmo seja necessário copiar as referências de terceiros de uma pasta para um local onde você possa rodar a aplicação e ver se suas modificações funcionaram, ou ainda, minificar e fazer o bundle dos arquivos que você utilizou para desenvolver para que sejam otimizados para o ambiente de execução.

É importante lembrar que uma aplicação web, ou melhor a parte correspondente ao client de uma aplicação web, consiste basicamente de arquivos JavaScript, HTML (estrutura da página), CSS (formatação da aparência), arquivos estáticos (imagens, fontes e outros recursos utilizados na página) e APIs para comunicação com o servidor. Dessa forma, sempre que um usuário acessar sua aplicação, o browser fará o download desses arquivos para o computador do usuário e qualquer otimização que você conseguir apresentar terá um impacto grande na experiência do usuário.

Enfim, seja qual for o motivo, uma coisa é certeza: você acabará executando tarefas repetitivas e, como programadores, nossa tarefa é automatizar esse tipo de tarefa sempre que possível.

Com esse intuito, surgiram várias ferramentas no mercado. Muito provavelmente você deve ter ouvido falar de pelo menos uma delas: Webpack, Gulp ou Grunt.

Se eu tivesse que traçar uma linha do tempo, diria dessa forma: muitos desenvolvedores começaram com o Grunt, depois mudaram para o Gulp e, atualmente, estão no Webpack. Mas no fim, é uma escolha muito pessoal. Alguns desenvolvedores combinam Gulp + Webpack para a realização de tarefas, mas essencialmente, você pode escolher qualquer um deles e ser feliz.

Por definição, tanto Gulp quanto Grunt são Task-Runners, enquanto o Webpack é um module bundler.

Para ajudar na decisão, a linha de tendência de acordo com o Google:

Particularmente, eu comecei com o Grunt e depois fui direto para o Webpack. Mas novamente, isso é uma escolha puramente pessoal e de acordo com o time que você está inserido.

O que você precisa saber:

Todos são customizáveis (alguns mais e outros menos) e possuem um ecossistema interessante de plugins para facilitar nas tarefas mais comuns e lidar com casos de exceção particulares ao seu projeto.

Grunt

As configurações são baseados em declarações, veja o exemplo abaixo.

Por isso, tende a ficar meio bagunçado conforme o arquivo cresce e novas tarefas são adicionadas. A tendência, atualmente, é não utilizá-lo mais.

Gulp

Ao contrário do Grunt, no Gulp as tarefas são funções JavaScript. Existem times que preferem configurações (naturalmente irão para o Grunt) ou times que preferem código.

Apesar de EU nunca ter utilizado o Gulp, vendo os exemplos de arquivos de configuração na internet tenho a impressão de que eles são mais simples, mais fáceis de serem mantidos e de melhor entendimento.

Outro fator interessante é que ele é mais rápido do que o Grunt, e tira vantagem do recursos de Streams disponível no Node. Notem o uso do Pipe no código.

Webpack

O webpack trabalha analisando todo o seu projeto e gera um mapa de dependências. É bem útil em projetos que utilizam vários assets que não são somente código, como fontes, imagens, css e etc.

A desvantagem do webpack é que ele pode parecer mais complexo de configurar, principalmente no início.

Após o mapa de dependência estar definido, o webpack utiliza as configurações pré-definidas para processar as dependências e gerar o resultado final.

Um conceito muito utilizado é o de Loaders, onde você define quais plugins serão executados quando o Webpack encontrar um tipo específico de arquivos.

No exemplo acima, o webpack utilizará o babel-loader para todos os arquivos do tipo .js que existirem no projeto.

 

Utilizando o Visual Studio Code para desenvolver com TypeScript

No meu post anterior (JavaScript e TypeScript – Breve histórico, definição e primeiros passos), falei sobre os primeiros passos para um desenvolvedor que está iniciando com o desenvolvimento client-side utilizando JavaScript, suas dificuldades quando o projeto começa a crescer e um pouco do TypeScript, uma linguagem que a Microsoft criou para tentar solucionar alguns problemas que desenvolvedores enfrentam em projetos que utilizam essa linguagem.

Antes de entrar nos detalhes específicos das linguagens – coisas que abordarei em posts futuros – gostaria de ressaltar o editor de códigos Visual Studio Code.

Muitos desenvolvedores Web tinham (ou ainda tem) um certo preconceito com tecnologias Microsoft. Muitos que conheço, nem sequer tentaram utilizar o Visual Studio Code para formar uma opinião sobre o produto. A semelhança do nome com a IDE completa (que ainda existe e é um produto completamente diferente) criou uma certa barreira.

Quando conseguimos passar essa barreira inicial e mostramos as vantagens de se utilizar o Visual Studio Code no dia-a-dia eles ficam encantados e imediatamente consideram a trocar as ferramentas que utilizavam antes pelo Code (apelido carinhoso :)).

Se você ainda não utilizou, recomendo que testem a ferramenta. Dentre as vantagens que a ferramenta oferece, posso citar algumas:

  • Intellisense aprimorado, inclusive para códigos C#;
  • Multiplataforma, ou seja, roda no Mac, Windows ou Linux.
  • Debugging direto da ferramenta
  • GIT integrado
  • Diversos plugins para melhorar ainda mais a experiência
  • Leve! Muito LEVE!

Voltando ao objetivo do post, mostrar as vantagens do Code para o desenvolvimento de códigos TypeScript, vou apresentar como começar a escrever suas primeiras linhas de código.

Instalando o TypeScript

Como eu disse no outro post, TypeScript utiliza-se de um Transpiler (compilador de código-fonte para código-fonte) para transformar o código que você está escrevendo em JavaScript. Você precisa instalá-lo.

A maneira mais simples de fazer isso é instalar o NPM (Node Package Manager) e utilizá-lo para instalar o TypeScript para você. Para instalar o NPM, e o Node JS, utilize esse link https://nodejs.org/en/download/.

Após instalado, abra um terminal e rode o seguinte comando:

npm install -g typescript

Após a instalação, se tudo der certo, você poderá checar a versão do TypeScript instalada, rodando o seguinte comando:

tsc –version

Esse procedimento mostra como instalar o TypeScript globalmente em sua máquina. Entretanto, em um cenário real de projeto, você pode instalar o TypeScript projeto a projeto e evitar interferências e conflitos de versões de um projeto para outro. Para fazer isso, só remover o -g do comando de instalação acima e o TypeScript será instalado na pasta do seu projeto (pasta atual).

Primeiros passos com o VS Code

Após instalar o VS Code, abra-o.

Eu gosto de criar um atalho para poder iniciar o code a partir de um terminal. O mais legal é que o Code já vem com uma opção pronta para fazer isso por você. Para ativar, digite CTRL+SHIFT+P ou CMD+SHIFT+P se estiver no Mac para abrir as ações do Code e escolha a opção Shell Command: Install ‘Code’ command in PATH.

Após isso, você poderá iniciar o code em qualquer lugar através do terminal rodando o comando “code .”, que abrirá o Code na pasta atual.

Com o Code aberto, vou criar um arquivo TypeScript para iniciarmos.

Como vocês podem ver, o visual é bem clean e na barra de ferramentas (em azul, na parte de baixo) existem algumas informações úteis sobre o arquivo.

Comece a programar!

Notem que o Intellisense, recurso que auxilia mostrando os detalhes do código é muito útil.

Notem que inclusive os tipos das propriedades são apresentadas.

E se eu tentar atribuir uma string a uma variável do tipo numérica, o VS Code alerta que isso não é possível.

 

Configurando o projeto para TypeScript

Em um projeto do tipo TypeScript, é necessário criar na raiz do projeto um arquivo chamado tsconfig.json. Esse arquivo será utilizado pelo Transpiler para gerar o código JavaScript de acordo com os parâmetros definidos nele.

Até nisso o VS Code nos auxilia bastante. Primeiro crie um arquivo e atribua o nome tsconfig.json.

Ao digitar { } e depois abrir as aspas (“) o VS Code mostra todas as opções possíveis para esse tipo de arquivo.

Para esse primeiro momento, utilizaremos da seguinte forma:

{
    "compilerOptions": {
        "target": "es5",
        "module": "commonjs",
        "sourceMap": true
    }
}

Após isso, voltei ao meu arquivo Test.ts e adicionei uma funcionalidade apenas para demonstrar a conversão do código TypeScript para JavaScript e podermos rodar o código no browser. Ele ficou assim:

Para gerar o código JavaScript, abra o terminal e rode o seguinte comando

tsc test.ts

Se tudo deu certo, você verá que um novo arquivo foi gerado na mesma pasta, mas com a extensão .js.

Ao abrir o arquivo gerado, você verá o resultado em JavaScript:

Esse código está pronto para ser rodado no browser. Se você abrir o console do Chrome e rodar o código lá, verá que ele funcionará.

 

JavaScript e TypeScript – Breve histórico, definição e primeiros passos

Para muitos desenvolvedores que estão começando agora ou para aqueles que estão tendo o primeiro contato com JavaScript, a forma como a linguagem foi projetada pode gerar bastante confusão e resultar em códigos bem ruins.

Ocasionalmente, encontramos soluções onde os desenvolvedores acabaram criando um código “de qualquer jeito”, simplesmente por ser JavaScript. O mais triste é que esses mesmos desenvolvedores, não escreveriam esse mesmo código tão desestruturado em outras linguagens server-side.

Antes de mais nada, vamos começar estabelecendo alguns conceitos:

Para uma solução Web funcionar, basicamente você uma aplicação dividida em 2 partes: Cliente e Servidor. A parte que fica no servidor geralmente é responsável por cuidar da autenticação do usuário, fazer o acesso a banco de dados, lógicas de negócios e disponibilizar informações/dados para a parte do cliente. São exemplos de linguagem de servidor: C#, Java, PHP, entre outras.

Já a parte do cliente é geralmente dividida em 3 partes: HTML, CSS e JavaScript. Essas 3 linguagens (tríade), rodam diretamente no browser (navegador) da pessoa que está acessando o site/aplicação.

Breve histórico: o desenvolvimento do JavaScript teve início em meados de 1995, na Netscape Communications, empresa que criou o browser Netscape (Alguém se lembra dele? :D). Na época, a Netscape Communications percebeu que precisava de uma linguagem para melhorar a experiência do usuário, o que resultaria em uma maior adoção. Como Java era uma linguagem que estava em evidência naquela época, decidiram que a sintaxe na nova linguagem seria parecida com ela. O resultado foi uma linguagem com recursos semelhates à Scheme, com sintaxe parecida com Java e orientação à objetos parecida com SmallTalk.

Não vou me aprofundar muito sobre JavaScript nesse artigo, mas com certeza vocês encontrarão várias referências na internet sobre a linguagem e até mesmo exemplos de códigos que você pode rodar diretamente no console do browser, sem nem mesmo criar uma página Web.

Com o passar do tempo, as aplicações evoluíram. Cada vez mais, é comum criarmos aplicações complexas utilizando basicamente o JavaScript. Quanto mais complexa é uma solução, mais precisamos pensar na arquitetura que vamos adotar.

É imprescindível criarmos uma base de código que seja de fácil manutenção, que nos permita fazer com que a ferramenta que criamos evolua. Com esse intuito, vieram vários frameworks para nos ajudar. Talvez um dos primeiros frameworks nesse sentido seja o jQuery.

Todo desenvolvedor front-end, ou que tenha se aventurado em fazer código client-side, em algum momento escreveu algumas linhas de código utilizando o jQuery ou deu manutenção em alguma solução que foi construída utilizando essa biblioteca.

Em uma época que as APIs dos browsers estavam engatinhando, era muito mais simples manipular elementos da página utilizando os métodos, propriedades e eventos que o jQuery nos proporciona. Ainda mais para os desenvolvedores que tinham conhecimento em desenvolvimento server-side mas estavam se aventurando pelo admirável mundo novo do desenvolvimento client-side.

Aproveitando que comentei da manipulação dos objetos de uma página da web, preciso comentar sobre outro tópico, o DOM.

Document Object Model (DOM)

Quando o browser interpreta um código HTML, ele monta o DOM da página. O DOM é uma árvore de objetos composta por todos os elementos que estão na página. Ou seja, todos os controles de formulário (Input, textarea, etc), referências à scripts, CSS, estão lá.

É através do DOM que você acessa um elemento que está na página e interage com ele, programaticamente falando. Por exemplo, quando você precisa alterar um texto dentro de um input, você está manipulando o DOM.

Seja com Vanilla JavaScript (Vanilla = uma outra maneira de falar JavaScript puro, sem bibliotecas e frameworks) ou através de algum framework ou biblioteca, o que você estará fazendo é manipulando essa árvore de objetos e o browser se encarregará de mostrar as alterações para o usuário.

 

Voltando para o JavaScript, conforme a necessidade de organização, planejamento e estruturação foram aparecendo (ou crescendo), em conjunto com a evolução das aplicações, os desenvolvedores (E empresas!) notaram que alguns recursos que ajudam no ciclo de vida de desenvolvimento de uma aplicação faltavam ao JavaScript. Entre eles:

  • Verificação de erros em tempo de compilação – Nos códigos que são compilados, o compilador (utilitário que transforma o código escrito por humanos em código que o computador seja capaz de entender) analisa todo o código escrito e, caso ele não siga algumas regras, erros são apresentados para o desenvolvedor. Com isso, o desenvolvedor consegue resolver alguns erros básicos durante a etapa de desenvolvimento, sem precisar rodar a aplicação para ver o erro.
  • Checagem dos tipos de objetos e intellisense – Outro recurso que ajuda bastante é saber o tipo das variáveis durante o tempo de desenvolvimento. Embora muitos IDEs e editores de código façam um ótimo trabalho nesse sentido, um suporte melhor ajudaria na produtividade.

Pensando nessas dificuldades, a Microsoft criou o TypeScript.

TypeScript é um superset da linguagem JavaScript e, com ele, você ganha o recurso de tipagem estática dos objetos, ou seja, se você tentar atribuir um texto a uma variável numérica você será informado do erro. 🙂

Como os browsers só entendem JavaScript, você precisará de um Transpiler. Para quem não está familiarizado com o termo, Transpiler é um tipo de compilador source-to-source, ou seja, que pega o código-fonte gerado em uma linguagem e gera código-fonte em outra linguagem. Nesse caso específico, pega o código em TypeScript e gera um código em JavaScript.

Não vou me aprofundar nesse tema agora, mas deixo um link da Wikipedia para quem quiser saber mais sobre o assunto: https://en.wikipedia.org/wiki/Source-to-source_compiler

A título de curiosidade, o Anders Hejlsberg Lead-Architect do C# e criador do Turbo-Pascal e Delphi trabalhou no desenvolvimento do TypeScript.

Como se pode imaginar, a sintaxe do TypeScript é bem parecida com o C#, o que ajuda na adaptação de desenvolvedores server-side acostumados com C# a fazer uma transição mais tranquila para o client-side.

Vejam:

Entenda como objetivo principal da Microsoft ao criar o TypeScript a tentativa de facilitar o desenvolvimento de códigos complexos e de larga escala.

No próximo artigo vou abordar como extrair o máximo do Visual Studio Code (se você ainda não conhece, recomendo muito! Sempre que posso utilizo o Visual Studio Code como ferramenta de trabalho. Além de tudo, é gratuito!) no desenvolvimento de código TypeScript. Fiquem ligados!

Recapitulando

Nesse artigo abordei o básico de como o código de uma aplicação web é dividido e os tipos de tecnologias envolvidas. Comentei sobre o JavaScript, como sua interação com elementos de uma página funcionam e como o TypeScript auxilia no desenvolvimento de aplicações robustas e de larga escala.

Abraços!

 

Monitorando uma aplicação Node JS com o Application Insights

Olá SharePointers,

Com todas as opções de integrações que o SharePoint fornece, podemos construir ferramentas que consomem dados utilizando qualquer linguagem. Eu mesmo já compartilhei vários exemplos que utilizam o Node JS para consumir os dados do SharePoint de alguma forma, seja diretamente ou através de webhooks.

Para quem tem acompanhado a evolução do Azure, deve ter visto o lançamento do recurso Application Insights. Essa ferramenta está disponível há algum tempo, mas, recentemente a Microsoft tem disponibilizado SDKs para integrarmos o Application Insights com linguagens fora do Stack Microsoft: Node JS e Java.

Do jeito que a Microsoft projetou o SDK, a sua utilização é tão simples como se estivéssemos utilizando .NET.

Para saber como implementar em sua aplicação, eu publiquei um exemplo no Github que mostrará o passo-a-passo da implementação: https://github.com/RARomano/ApplicationInsights.NodeJS

Abraços!

SharePoint Framework – Quick Samples

Olá SharePointers,

Criei um repositório no Github onde colocarei alguns exemplos rápidos, mas que podem ajudar bastante no nosso dia-a-dia.

O link do repositório é: https://github.com/RARomano/SharePointFramework-Samples – Se gostarem, cliquem no ícone Star no Github 😀

O primeiro exemplo, mostra como carregar CSS de um CDN, o que acredito que será muito útil para todo mundo.

Para quem quiser o Link direto dessa dica é esse aqui: https://github.com/RARomano/SharePointFramework-Samples/tree/master/AddCustomStyles

 

Grande Abraço!

SharePoint Framework – Overview

Olá SharePointers,

O SharePoint framework, atualmente em General Availability (https://github.com/SharePoint/sp-dev-docs/wiki/Release-Notes-GA), está pronto para utilizado e precisamos ter algumas coisas em mente:

Contexto de execução

Diferentemente do que acontece com os Add-ins, as webparts criadas utilizando esse framework rodam no contexto da página. Ou seja, não roda dentro de um iFrame.

Isso é muito importante!

Quando instalávamos um add-in, um site isolado era provisionado e a sua aplicação residia lá. No SharePoint Online por exemplo, a URL era: https://[tenant]-[id].SharePoint.com.

Mesmo quando você utilizava uma App Part para colocar o seu App dentro do contexto do seu site principal, internamente isso acontecia dentro de um iFrame e, com isso, a aplicação não conseguiria fazer mal ao seu site principal. (Lembre-se que ao instalar o Add-in, você precisa aceitar as permissões que são solicitadas).

Em uma Webpart do SharePoint Framework, por outro lado, roda diretamente no site, no DOM da página e com as permissões do usuário atual. Apenas para deixar claro, tudo o que o usuário logado tiver permissões para fazer, o código também terá permissões para fazer.

Utilização de Bibliotecas de Terceiros

É muito comum utilizarmos bibliotecas de terceiros em nossas aplicações. E, as vezes, utilizamos essas bibliotecas diretamente de CDNs.

Como eu disse no tópico anterior, como essas WebParts rodam diretamente no contexto do usuário, é preciso ter um critério muito grande em relação aos scripts que for utilizar, caso sejam maliciosos, eles podem causar problemas – fica aí um ponto de atenção para os administradores do portal.

Framework de Desenvolvimento

Uma coisa muito interessante desse modelo é que você tem a liberdade de trabalhar da forma como achar melhor.

Você pode utilizar Angular, React, Knockout, Handlebars ou seja lá o que for mais confortável para você. Isso é um grande passo da Microsoft, nos dá liberdade como desenvolvedores e permite trabalharmos da forma como nosso time estiver mais confortável.

 

E aí pessoal, compartilhem suas experiências com o esse novo framework. Estão utilizando?

Abraços! 😀

“Image Renditions” no SharePoint com Cloudinary

Olá SharePointers, 

O SharePoint possui vários recursos interessantes e, um deles, é o Image Renditions. 

Image Renditions faz parte do SharePoint enterprise e, com ele, você consegue subir uma imagem em alta resolução e fazer com que o SharePoint crie versões alternativas conforme você precisa delas.

Por exemplo, você sobe uma imagem com resolução 1080×1024, mas em algum lugar do site, você tem um espaço de 300×200 para exibir a mesma. O que muitos acabam fazendo é carregar a imagem inteira e formata por CSS. Mas, fazendo dessa forma, o peso de carregar a imagem inteira e transferi-la para o cliente é o mesmo, não importando o tamanho que a mesma está sendo exibida.

Com esse recurso, você melhora muito o carregamento da sua página, pois você transfere exatamente o tamanho que será utilizado.

Seguindo o passo-a-passo abaixo, você configura os renditions em um site:

E quando for utilizar as imagens, você pode utilizar de uma das formas a seguir:

Passando o tamanho desejado

<img src="/sites/pub/Assets/Lighthouse.jpg?Width=400&Height=200" />

 Ou passando o ID do rendition

<img src="/sites/pub/Assets/Lighthouse.jpg?RenditionID=2" />

Dessa forma, a imagem vem do SharePoint da forma que deverá ser utilizada no conteúdo, reduzindo tráfego de rede adicional e acelerando o carregamento da sua página.

Entretanto, esse recurso só está disponível no SharePoint ENTERPRISE.

Infelizmente, nem todas as empresas possuem essa versão e com o surgimento (e consolidação) cada vez mais de serviços baseados em nuvem, muitas tarefas podem nos auxiliar grandemente.

Um desses serviços é o Cloudinary

Esse serviço é simplesmente fantástico! E o melhor, é gratuito! Existem planos que atendem a diversas necessidades, mas a versão gratuita, que é completamente funcional, atende bem na maioria dos casos.

Veja alguns casos que você pode fazer com esse serviço:

Imagem Original

 

Imagem centralizada no rosto e arredondada

(http://res.cloudinary.com/demo/image/upload/w_400,h_400,c_crop,g_face,r_max/w_200/lady.jpg)

Lembre-se que essa imagem é transformada “on-the-fly”, ou seja, você pode alterar os parâmetros conforme quiser para obter resultados diferentes.

 

Imagem centralizada no rosto e arredondada (preto-e-branco)

(http://res.cloudinary.com/demo/image/upload/w_400,h_400,c_crop,g_face,r_max/w_200/e_grayscale/lady.jpg)

Notem que nesse caso, só adicionei o e_grayscale na url para aplicar uma transformação adicional na mesma imagem.

 

As possibilidades são infinitas! Leiam a documentação para mais detalhes. 😀

Além disso tudo, criaram APIs para todas as principais linguagens!

 

Espero que gostem! 

Abraços!

SharePoint Framework – Visão e Futuro

Olá SharePointers,

Para quem acompanha meu blog, venho falando das novas formas de desenvolvimento para SharePoint e incluindo minhas experiências com novos frameworks há algum tempo.

A Microsoft disponibilizou, ainda em preview, um novo framework para desenvolvimento de soluções para o SharePoint – falei sobre isso nesse link:  http://rodrigoromano.net/2016/09/01/sharepoint-framework/.

Vendo os movimentos mais recentes da Microsoft, podemos perceber a sua estratégia de aproximação com as comunidades/plataformas Open Source e como isso têm transformado a experiência com os próprios produtos da Microsoft.

Dito isso e, pensando em toda a transformação que o próprio modelo de Add-ins nos propiciou – ou nos forçou – podemos inferir/constatar que o desenvolvimento Server Side para SharePoint, se ainda não deixou de existir, tende a morrer. 

Quando eu falo isso, estou me referindo apenas a códigos de servidor rodando no mesmo box do SharePoint. É claro, que se você fizer um add-in provider hosted, você poderá ter códigos de servidor rodando normalmente em qualquer linguagem que preferir.

 

Add-Ins

Tenho falado bastante sobre esse assunto, também. Nesses posts http://rodrigoromano.net/2015/11/04/aumentando-a-produtividade-com-sharepoint-add-ins-parte-1/ e http://rodrigoromano.net/2015/11/23/aumentando-a-produtividade-com-sharepoint-add-ins-parte-2-a-beleza-do-upgrade/ falei sobre como utilizar esse modelo para ganhar produtividade.

Quando esse modelo foi introduzido, a mensagem chegou para a comunidade de forma distorcida e não entendemos a sua proposta e como ele poderia nos ajudar. Para nós, desenvolvedores de SharePoint acostumados a fazer tudo da mesma maneira, foi complicado aceitar essa alteração na nossa metodologia de trabalho. Muitas pessoas acabaram por simplesmente deixar esse modelo de lado e não aproveitar os seus benefícios.

Concordo que essas mudanças são muito grandes, principalmente para quem estava acostumado com desenvolvimento somente do lado do servidor e tiveram que passar para o lado do cliente e entender todos os seus desafios e características.

Muito embora as aplicações web tenham evoluído para modelo semelhantes, não estávamos acostumados e talvez nem preparados pra isso.

 

SharePoint Framework

A Microsoft tenta, cada vez mais, aproximar os desenvolvedores de outras plataformas e permitir que eles trabalhem com o SharePoint de maneira mais simples, sem uma curva de aprendizado muito alta.

Com o modelo de Add-ins, nesse caso específico os SharePoint-Hosted, isso era uma meia verdade. Embora a linguagem utilizada seja o Javascript, todo o tooling e os processos de desenvolvimento eram todos muito distintos. 

Na minha visão, o modelo de Add-ins foi um primeiro passo nessa transformação. 

O segundo passo, foi a criação do SharePoint Framework.

Com esse novo modelo, que ainda está em preview, a Microsoft aproximou esses mundos de uma forma nunca vista antes. Veja abaixo, um comparativo entre os toolings utilizados no desenvolvimento Server-Side e no novo modelo:

Tooling SharePoint Atual Tooling SharePoint Framework
IIS / .NET Framework Node
NuGet NPM
MS Build Gulp
Visual Studio Templates Yeoman
C# TypeScript

Notem que agora, as ferramentas são as mesmas utilizadas pelos desenvolvedores front-end por muito tempo. Eles não terão nenhum tipo de dificuldade de se adaptar nesse mundo novo, ou seja, a Microsoft atingiu seu objetivo.

Eu acredito que, eventualmente, esse modelo substitua o de add-ins, pelo menos o SharePoint-Hosted.

Uma das coisas que posso comentar, é que a Microsoft está investindo bastante nesse modelo. Recomendo, portanto, que o utilizem. Testem-no. Deem feedback. A Microsoft está focada em pegar tudo o que ela tem aprendido com a comunidade, principalmente no PnP e tentando trazer para o produto.

 

O que acham desse assunto? Comentem aí! 😀

 

Abraços!

 

SharePoint WebHooks

Olá SharePointers,

Como eu postei recentemente aqui, a Microsoft tem apresentado uma série de novidades interessantes em toda a sua gama de produtos e não tem deixado faltar o nosso amado SharePoint.

Uma das features que devem ser anunciadas em breve para o SharePoint é o “SharePoint Webhooks“.

 

O que são os Webhooks?

Webhook é um conceito atual que está ganhando cada vez mais popularidade. Com ele é possível receber notificações em tempo real, sem ter que ir consultar no sistema fonte. É conhecido como Web Callback or HTTP Push API.

Muitos lugares já utilizam/disponibilizam esse tipo de APIs, como:

Github – envia notificações quando alguma ação acontece em um repositório. 

Foursquare – envia notificações quando um usuário faz um checkin em algum lugar.

 

SharePoint Webhooks

No SharePoint, a previsão é que este recurso esteja disponível, em modo General Preview, nesse trimestre e de forma final no final do ano.

 

Alguns podem perguntar: e os Remote Event Receivers? Quando escolher um ou outro?

Os Webhooks não suportarão os eventos do tipo “ING”, ou seja, você não será notificado enquanto uma ação está acontecendo, e consequentemente, não poderá interferir nelas. As notificações serão somente depois que a ação ocorrer.

Eles são mais seguros, nenhuma informação sobre o evento é passada durante a chamada.

Os Webhooks são mais “industry standard”, ou seja, os desenvolvedores de outras tecnologias já estão acostumados com esse padrão e será mais fácil a adoção.

Não será necessário utilizar serviços baseados em WCF, Serviços HTTP comuns já são suficientes.

 

Para mais informações, veja o video abaixo:

 

Referências:

https://dev.office.com/blogs/introducing-sharepoint-webhooks

https://blogs.technet.microsoft.com/stefan_gossner/2016/05/04/sharepoint-developer-announcement-the-sharepoint-framework-an-open-and-connected-platform/

https://github.com/SharePoint/sp-dev-samples

 

 

Migrando uma aplicação ASP.NET (MVC) para Provider-Hosted

Olá SharePointers,

Muitas vezes temos aplicações desenvolvidas em .NET mas precisamos colocá-las no SharePoint. Mesmo que no início, acabamos por não utilizar nada efetivo do SharePoint.

Avaliando as opções do Visual Studio, acabei passando, sem querer, por uma opção que me chamou muito a atenção: “Convert to App for SharePoint Project

 

Para chegar lá, segui o passo-a-passo abaixo:

1- Criar uma solução ASP.NET MVC

 

Com a solução criada, cliquei com o botão direito no projeto, fui em Convert e depois em Convert to App for SharePoint

Escolhi a URL do Site e depois marquei como SharePoint Online e pronto! Open-mouthed smile

A solução estava migrada automaticamente para mim…

 

Ao apertar o F5, para rodar a solução o Visual Studio subiu no SharePoint Online e apareceu a tela para confiar na aplicação

E após isso, estava rodando a partir da minha máquina local!

 

O processo é bem simples, e pode ajudar bastante no nosso dia-a-dia!

 

Abraços!