Faz tempo que não escrevo um artigo de opinião. Já era hora de desenferrujar e nada melhor do que polemizar para tal.
Não custa ressaltar que o que escreverei aqui é apenas MINHA OPINIÃO e não necessariamente reflete a verdade ou o que a comunidade pensa. E, por mais que o Power BI esteja mencionado no título, eu não falarei dele.
Sabendo disso, vamos em frente.
A bola da vez?
O assunto da vez, pelo menos no que tange o espectro de curiosos e interessados do Excel, é o Power BI e com ele, os Dashboards.
Não vou entrar no mérito do segundo por ele ser mais abrangente. Isso tem mais ou menos uns 2 a 3 anos da data deste post. Só se fala nele, só se dá curso sobre ele, masterclass, livros, etc. Isso é bom, aquece o mercado, alimenta famílias, engrandece o currículo.
MAS (em caixa alta mesmo) , se você sofre um mínimo do complexo de vira-lata, o que é o meu caso, provavelmente se sentiu “atrasado” em saber que nada sabia sobre o assunto. Como tudo curioso frustrado, fui lá tentar saber o que era. Para minha surpresa, o que encontrei foi isso…
O Power BI não é para mim, e talvez não seja para você
O subtítulo acima foi feito para incomodar, principalmente aos adoradores no Power BI. Entendo, mas há algo que precisa ficar claro aqui.
O Excel é um software com uma quantidade insana de funcionalidades. Nem mesmo os mais experientes conseguiriam enumerar todas, e eles admitem isso (vou deixar para você o trabalho de pesquisar isso. Minha dica é gastar um tempo no Quora vendo respostas dos MVPs).
Diante disso, toda vez que algum recurso revolucinário vem à tona, a primeira coisa que me vem a cabeça é ceticismo, e isso eu aprendi com o João Benito Savastano. Depois de quase 20 anos conhecendo e trabalhando com a ferramenta, achar que falta algo é “meio que” trair a confiança dela.
Não me leve a mal, eu gosto de novidades, tanto que faço questão de sempre ter a última versão do Office instalada no meu Windows. Mas, para ser sincero, depois do SOMASES, CONCAT e UNIRTEXTO, pouca coisa fez diferença para mim, e o Power BI é uma delas. Não é porque o Power BI é ruim. Os colegas da comunidade estão fazendo trabalhos Excelentes divulgando a ferramenta, escrevendo artigos, ministrando cursos e escrevendo livros.
Só que, bem, o Power BI não é para mim, e por alguns motivos simples:
ele não tornará meu trabalho melhor
ele não tornará meu trabalho mais rápido
meus projetos não se beneficiarão dele
meus clientes não se beneficiarão dele
eu gosto de Dashboards, mas nem meus clientes e nem eu precisamos deles
Isso é mais do que suficiente para eu não me preocupar com ele por enquanto, ou pelo menos até ele ser necessário para mim.
Coitado do Power BI
Aqui, um mea culpa. Eu basicamente massacrei o Power BI sem mesmo tê-lo conhecido. A verdade é que ele acabou sendo o bode expiatório de um problema maior que tentei elaborar acima.
Por isso, para qualquer outro recurso maluco que você acha que deveria conhecer, mas não conhece, pense que, se você é capaz de fazer seu trabalho com produtividade com os recursos que você já sabe, isso é tudo o que você precisa e você pode tranquilamente viver sem nada saber da “nova funcionalidade no pedaço”.
Conhecer coisas novas é tarefa obrigatória de todo profissional da atualidade, mas, com o tempo escasso e o mercado exigente, ser seletivo no que você vai utilizar é o melhor caminho a seguir.
Fazia tempo que não tinha um bom motivo para “escrever um artigo”. Ultimamente gravar e publicar vídeo tutorias tem sido cada vez mais fácil (valeu Youtube) e o pessoal parece gostar do formato.
Com a toada em que a internet se encontra, decidi deixar o título simples. Nada de click bait. Nada de “O VBA vai acabar” ou “VBA, a hora da verdade”. Isso me irrita tanto que não tenho coragem de fazê-lo com vocês, pelo menos até hoje.
Indo ao assunto, estamos falando de VBA, ou melhor, desenvolvimento para a plataforma Office, depois de trabalhar quase 17 anos com essa notável ferramenta, a qual me levou a ser o profissional que sou hoje. Não sou o cara mais bem sucedido do mundo, mas estando bem empregado no mesmo ramo e gostando muito do que faço diariamente, considero isso um ponto muito positivo.
Vamos ao que interessa, mas antes, as opiniões colocadas aqui são 100% minhas e têm como fontes além da vivência, longas conversas com colegas que manjam do assunto, incluindo MVPs em Office. E sim, isso foi uma carteirada. 🙂
Público Alvo
O público que pretendo atingir é o de programadores/usuários VBA e também a comunidade engajada no seu (bom) uso. Se por um acaso você é um programador não VBA mas se interessa pelo assunto, bem, meus parabéns e seja bem vindo!
Desenvolvimento para Office: Como estamos atualmente?
Tendo em mente que estou escrevendo este artigo no primeiro semestre de 2017, o que vou escrever aqui pode mudar muito nos próximos meses, quem dirá nos próxmos anos. O momento atual pode ser definido da seguinte forma:
O VBA ainda existe, vem como padrão na instalação do Office 2016, mas não é atualizado seriamente desde 1999. Houveram algumas funções adicionadas no Office 2003, mas nada sério.
A investida atual da Microsoft para desenvolvimento Office é o Office Add Ins, permitindo criar “Apps” que são embutidos no Office via barra de tarefas (aquela que aparece à direita), mas criadas em Javascript e distribuídas via Office Store.
O VBA está de fato cada vez mais bugado e isso só piora a cada versão.
Adicionalmente, alguns fatos precisam ser colocados para servir de base para a argumentação que farei neste texto.
O desenvolvimento para VBA está longe de acabar. Comunidades sobre o assunto só crescem e o interesse permanece estável. Abaixo podemos ver o gráfico do Google Trends que mostra o interesse na linguagem comparada ao que são suas alternativas:
Google Trends – VBA, VSTO, Office Add Ins e Interop
A comparação chega a ser ridícula. Ainda que seja possível argumentar que o desenvolvimento vem caindo, é muito pouco para uma linguagem que não têm investimento algum a quase duas décadas, enquanto outras lutam para ser manter no páreo. O que não entendo é como isso pode ser ruim.
O stackoverflow.com, que é no momento “O FÓRUM” para qualquer linguagem de programação, tecnologia ou framework em uso trás os seguintes números aproximados:
VBA: ~80 mil menções
VSTO: ~12 mil menções
Office JS: ~1,5 mil menções
Procurar por Office Add In não conta pois ele engloba toda e qualquer tecnologia na qual se pode construir um, desde o VBA até mesmo C++.
Convenhamos, a Microsoft é muito conhecida tanto por seus grandes acertos (Office, .NET, SQL Server, Azure) como por seus inesquecíveis fracassos (Windows Milenium, Vista, Infopath, Zune, Windows Phone).
Por fim, temos o VBA firme e forte, o VSTO sabe lá onde está, o Office Add In em Javascript está engatinhando, mas não estou muito otimista sobre. Já comento mais.
Qual é o real estado do VBA?
O estado do VBA em si, desde o mercado até a ferramenta é caótico. O grande problema é que ser caótico não é necessariamente ruim.
O caos se dá pela falta de direção que um programador VBA deve tomar. No meu caso, eu comecei criando macros simples sem entender muito o que estava acontecendo, para depois sim entrar num curso de lógica de programação, que foi quando as coisas começaram a fazer mais sentido. Depois de trabalhar 3 anos descobrindo o VBA, ingressei na faculdade de Ciências da Computação e aí tudo ficou mais polido, já que tive uma visão mais abrangente de como linguagens de programação e ferramentas como ele funcionam.
Entretanto, para a maioria o caminho não é bem esse. Muitos vem de outras áreas que nada tem em relação com programação em si. Eles encontram seu próprio caminho usando o VBA porque ele permite isso. No fim, temos soluções das mais variadas criadas pelo mais variados tipos de profissionais e que entendem do negócio (quem mais faria um código para o mercado financeiro do que uma analista de finanças?) resolvendo uma série de pequenos problemas e até mesmo movendo negócios.
Onde está o problema nisso? Manutenção.
É relativamente simples criar um código, mas mantê-lo, nem tanto. O criador da proeza faz tudo que pode para fazer funcionar sem o compromisso de manter um nível decente de manutenibilidade. E se você é um deles, eu não te culpo. Você não teve a contextualização suficiente para entender a importância disso pois você não é um programador e naturalmente não deveria se preocupar em ser. Você assumiu o papel de um. Você gosta de ser um quando está criando um código, mas não quer ser quando precisa resolver um bug nele.
O resultado? Milhares (quiçá milhões) de aplicativos VBA criados precisando desesperadamente de manutenção e não há quem queira fazê-lo. Quem criou não tem disposição ou noção para tal e programadores em outras linguagens (sim, porque este programador olha para o VBA como um patinho feio, algo de segunda linha) não querem chegar perto desse tipo de código.
A facilidade de criação permitida pelo VBA é o que o faz tão forte e utilizado, mas a mesma facilidade permite que o código vire uma bagunça logo e desenhe o cenário que temos hoje. É preciso encontrar um meio termo. Uma mudança drástica como as que vem sendo propostas não tem sido a melhor escolha e matar o ecossistema pode além de causar revolta nos usuários, sacrificar um número expressivo de negócios e fazer o mercado criar alternativas.
Alô Microsoft?!?
O que aconteceu com o VSTO?
O VSTO (Visual Studio for Office) foi a primeira tentativa oficial da Microsoft de dar ao Office um desenvolvimento “sério”, antes feito através do VBA ou das bibliotecas padrão do Office manipuladas via VB6, Delphi ou C++.
Antes mesmo do VSTO, tivemos um movimento chamado Smart Documents. Era, na minha opinião, algo incrível! Você mapeava áreas de documentos Word, planilhas Excel e/ou slides no PowerPoint e adicionava inteligência a isso, como uma tradução simultânea, acesso a contratos que estivesse no contexto. Notável! Podia ser feito tanto no VB6, o que era bom para programadores VBA, como em C# ou VB.NET. Envolvia muito XML (lembra daqueles mapas de documento?) e era chato de fazer, mas o resultado era bom.
O VSTO veio incrementar isso, sendo completamente integrado ao Visual Studio, permitindo abrir o Excel e o Word dentro da ferramenta para ver o resultado quase pronto, podendo arrastar controles, datasets, conexões com o banco de dados e o que mais a ferramenta entregava. Um marco! Era bom, mas assim como a alternativa acima citada, errava num ponto crucial:
A distribuição.
Publicar um aplicativo VSTO era (e ainda é) uma epopéia, envolvendo arquivos de manifesto (mais xml), privilégios de execução, etc, etc, etc. Fazer o usuário executar uma planilha feita nessa tecnologia era tão desencorajador que o desenvolvedor parava no meio do caminho e voltava para o VBA, mesmo sabendo que isso lhe custaria abrir mão de todos os recursos do Visual Studio e das linguagens que se pode utilizar nele. E sim, o problema continua até hoje.
O VSTO evolui bem em quanto ferramenta, bibliotecas e até implementou tipos dinâmicos para fazer ser mais fácil codificar em C#, mas nada mudou na forma de entregar o produto compilado ou para facilitar a vida de quem veio do VBA.
Office mais… Javascript?
Confesso que quando li isso pela primeira vez, quase pulei da cadeira. Trazer a linguagem mais utilizada na internet para o Office seria o pulo do gato para o desenvolvimento VBA!
Mas… sim, tem o “mas”. O que a Microsoft fez foi nada mais do que manter o VSTO só que ao invés de codificar C#/VB.NET, você faz isso em Javascript. O problema da distribuição permanece.
Aliás, é pior! Você só pode construir Add-Ins e publicá-los via Office Store, ou Office App Store, ou sei lá eu o que isso seja. Nunca tinha ouvido falar disso antes de ler sobre o assunto. Se eu como criador de aplicativos Office não sabia, que dirá o usuário.
A ideia ainda me empolga, mas se o modelo de distribuição não for modificado, eu vejo para o Office JS o mesmo fim do VSTO.
O que está errado?
Há um misto de enganos. Novamente, esta é minha opinião.
A Microsoft parece estar simplesmente ignorando as forças do VBA, que penso serem principalmente as seguintes:
Facilitade de desenvolvimento (Visual Basic é fácil de aprender)
Facilidade de distribuição (Salvar arquivo, Ativar macros, pronto)
Ubiquidade (o VBA já está lá, queira você ou não)
Nada disso está presente nas novas soluções propostas. O VBA não é para programadores. Ele forma programadores (presente!). Comentei isso com colegas de trabalho recentemente. Ninguém que não usa Office gosta de trabalhar com ele. O Office é bom para quem o usa diariamente, os usuários. Para todo o resto, especialmente programadores, ele não agradável de se lidar.
E é o VBA que torna a manipulação de objetos do Office algo torelável. E sim, o Office não seria o que é se não fosse o VBA e já teria sido facilmente substituído por alternativas como o Google Sheets ou as finadas que vieram uma década atrás.
A decisão óbvia que não foi tomada
Pelo menos era a decisão óbvia para mim. Como programador VBA e .NET, tinha a visão clara de que uma hora seria lançado o Visua Basic .NET for Applications.
Seria perfeito! Toda aquela estrutura do VB6 seria substituída por um subset do Visual Studio e teríamos acesso a todas as vantagens da então nova plataforma .NET. Mas não foi assim.
A Microsoft focou nos desenvolvedores, tentando atraí-los para programar para o Office. Deu certo com o .NET, por isso não os culpo por adotar tal estratégia.
Mas depois de algum tempo, ficou claro a falta de adoção por quem deveria tê-lo feito, os programadores VBA. A pergunta que fica é, porque ainda insistem tanto neste caminho?
O que está por vir
Sinceramente, não faço ideia. O que dá para prever é que se a direção não mudar, nós veremos o VBA cair na velhice e deixando de ser usado por pura inviabilidade técnica, o que já está acontecendo atualmente.
E, se você é um desenvolvedor VBA, qual é a probabilidade de adotar o VSTO ou Office JS como sua alternativa quando não houver mais escolha? O que fazer? Abandonar de vez?
Alternativas
O mercado não ficou parado. Os programadores VBA não deixaram de sê-lo e aqueles que precisam manipular documentos do Office continuam fazendo-o, mas nada de VSTO.
O acesso é feito direto via Office Primary Interop Assemblies. Isso deu um ar fresco para programadores que precisam criar soluções baseadas no Office via código, apesar de todos os problemas de compatibilidade, que vem sendo resolvidos com o tempo.
Entretanto, programadores VBA mal chegam perto desse tipo de solução.
Outra alternativa que apareceu recentemente foi o Excel DNA. Ele é uma biblioteca que permite criar AddIns para Excel usando C#/VB.NET. Você codifica no Visual Studio com todo seu potencial e no final gera o assembly .net junto com o arquivo xll (addin). É uma maneira muito elegante de resolver o problema da distribuição e prova para a Microsoft que há outros caminhos. Não tenho visto ele ser atualizado recentemente, o que é uma pena. 🙁
O que mais? O Google Sheets está vindo aí e já é possível codificar “macros” nele, e em Javascript! Até escrevi sobre isso aqui.
Não vi muito do que o Open Office está fazendo. Quem quiser comentar sobre, fique à vontade.
O que está sendo feito sobre isso?
Da Microsoft, a única certeza que tenho é que eles querem se livrar deste contexto, seja criando alternativas, seja matando o VBA, o que parece ser o caso.
Da comunidade, há um esforço enorme em espalhar o bom uso da ferramenta através de artigos e tutoriais dos mais variados tipos e autores. O material é rico e extenso. Há representantes de peso e engajados na causa do bom uso do VBA. Isso eu posso garantir que está sendo feito, e bem feito!
E o que eu vou fazer a respeito?
Até o momento, pretendo continuar compartilhando conhecimento em VBA. Ele está aí, presente, forte, ao alcance de um atalho para que qualquer profissional possa começar sem burocracia a criar seus primeiros códigos e trilhar uma carreira no mercado de programação, que foi exatamente o meu caso.
Eu tenho um sonho grande de poder criar algum tipo de alternativa ao VBA, mas no momento é um projeto muito grande para encaixar na vida. Quem quiser uma pista, esse projeto envolveria Roslyn e muito C#. É muito louco, mas quem sabe?
Outra ideia seria criar transpiladores, ou seja, ferramentas mais modernas em linguagens mais novas que produziriam código VBA. Não deixa de ser uma solução (acontece hoje com o Javascript), mas o VBA ainda estaria por lá e em pouco tempo, evoluções no mesmo seriam necessárias (como também acontece com o Javascript), o que já é um fato hoje.
Acredito ser o melhor a fazer já que não podemos mudar o produto por conta própria.
Agradecimentos
Meu agradecimento especial os integrantes do grupo Especialistas Excel e PBI, do qual tenho a honra de fazer parte e que tanto me esclarece em doses diárias de conhecimento e bom humor. 😀
É possivel prever o quanto posso ser alvo de relataliações, mas isto é a internet, este é meu blog e não fosse a liberdade que este meio oferece, não teria sentido ele existir.
Contexto
Acredito ser justo contextualizar o que me levou a fazer este texto e minha trajetória do mundo web. Se você não estiver a fim de ler tudo isso, pode ir direto para a próxima tópico onde falarei diretamente do assunto relacionado ao título do artigo.
Atualmente sou desenvolvedor web com quase uma década de experiência no ramo. Passei um tempo programando para desktop e serviços, mas não demorou muito para me apaixonar por redes, daí para sockets, daí para protocolos e então cheguei no HTTP.
O problema é que aprendi web errado. Fiz curso de HTML e estático quando escrevendo as primeiras linhas de PHP, fui apresentado ao .NET (lá em 2002). Tudo começou no console, passou para o Windows e logo estava no ASP.NET. Na época, só tinha o Web Forms. Como o conhecimento de web era pouco, não tive muito como julgar o “crime” que o Web Forms cometia ao tentar simular um gerenciamento de estado em um protocolo sem estado. A sacada era genial, mas o custo era demasiado alto. Simplesmente aceitei em fui em frente. Afinal de contas, o que contava era produzir, e nisso o Web Forms era bom.
Passado um tempo, me vi obrigado a encarar outras tecnologias web. Passei pelo até pelo ColdFusion (ouch!), que apesar de mal quisto, era muito bem feito. A Adobe, antes Macromedia tinha feito um ótimo trabalho. A adaptação foi terrível. Cadé os controles? Cadê a ferramenta? Os Adobe Builders da vida não ajudavam. Cadê o vento click do lado server? Porque os dados dos controles são perdidos depois do click? Cadê o postback?
Estava perdido. Nascia a necessidade de entender o que era web de fato. Ter programado 4 anos de sistemas web sem saber o que era um POST ou um GET me deu um nó na cabeça. Quando a ficha caiu, o respeito pelo ColdFusion cresceu e pelo ASP.NET, bem…
Não tive escolha. Tive que voltar aos projetos ASP.NET pois era o meu “metiêr” e o C# já era a linguagem das linguagens. Mas claro, olhei o Web Forms de um jeito diferente, querendo mudar tudo. Já namorava intensamente o Castle Project, na época, um alívio para desenvolvedores Web que se viam obrigados a trabalhar com ASP.NET. Mas não havia espaço. Nenhum desenvolvedor .NET fazia ideia do que era tudo isso Eram raros os que se interessavam. Passou a ser um suplício. Na época, frameworks Java como o brasileiríssimo VRaptor me enchiam os olhos, o Ruby on Rails me encantava e o Javascript já era uma linguagem do coração. No Web Forms, era quase anti-produtivo utilizá-lo. Gurus da Microsoft tiveram a coragem de dizer que o Javascript estava com os dias contados.
Em dezembro de 2007, a Microsoft deu os primeiros sinais do ASP.NET MVC. Os esboços eram estupidamente animadores. Qualquer coisa que fizesse não mais pensar em postbacks e viewstates, além das rotas, eram um alívio. Nascia um mundo web de verdade para desenvolvedores .NET.
Há que tenha entrado em pânico. Afinal, quem quer jogar fora anos de experiência e conhecimento? Meu pensamento sobre isso é o seguinte. Nos dias de hoje, se você passa mais de uma semana sem ouvir falar de um novo framework ou biblioteca, você já está quase desatualizado. Se você gosta de um bloco de código que escreveu há mais de um ano, provavelmente você não aprendeu muito.
Bem vindo ao mundo do desenvolvimento web.
A imersão
No meio da aventura citada acima, a imersão em HTML, CSS e Javascript foram inevitáveis. No meu caso, foi amor à “primeiras vistas”. Adorei cada pedaço do que vi e me envolvi totalmente com o mundo front-end.
Comia Tableless no café da manhã, seletores eram fichinha e as novidades do HTML5 foram um bálsamo. Nessa época, lia sobre frameworks Javascript, CSS e afins na mesma intensidade que acompanhava a evolução do .NET.
Era muito bom ver o mundo web crescer e notar como o Single Page Apps vieram para ficar, tendo no server side algo tão poderoso como o que o ASP.NET e outros frameworks faziam. Tinha tudo o que precisava para criar soluções profissionais baseadas em web de ponta a ponta, sem deixar pontas soltas.
As ferramentas (enfim)
Era difícil fazer qualquer coisa fora do Visual Studio, pois ele estava ali, quase sempre aberto. O editor é confortável e o autocomplete (intellisense para os fanáticos) era essencial e inteligente, mesmo para htmls simples e javascript. Estava feliz.
Mas a pulga, aquela que fica atrás da orelha, não parava de incomodar quando, ao ler artigos e assistir tutoriais em vídeo, me deparava com o uso de outros editores como o Sublime Text e o WebStorm. Alguns mais atrevidos usavam o Atom e os corajosos me faziam sentir um newbie quando criavam seus exemplos direto no vim ou emacs.
Parecia mágico. Me perguntava se realmente precisava de tudo aquilo que a ferramenta da Microsoft oferecia, pois tinha um custo, monetário e de memória. Os requisitos para instalação são generosos e o grande calcanhar de Aquiles é precisar estar no Windows.
Fui aos poucos me convencendo e deixando o Visual Studio de lado para tarefas mais simples como editar CSS, HTML ou mesmo Javascript, mesmo abrindo mão do autocomplete. Aquela sensação de estar livre do Windows era muito agradável. Sendo boa parte das ferramentas para a web multiplataforma, estando num Windows, Mac ou Ubuntu, não havia entrave algum para iniciar um desenvolvimento ou fazer uma manutenção.
O git, node e ruby, ferramentas sob as quais a maioria dos pacotes e utilitários executa atualmente já são quase tão comuns de instalar ou já estarem instalados quanto o python ou mesmo o java. Desenvolver para a web havia se tornado algo quase transversal.
Então porque o Visual Studio?
Apesar do que gostei por muito tempo chamar de “liberdade”, descobri que era mais uma frescura. Mesmo! E não venha me convencer do contrário.
Se você é daqueles que não admite executar um Windows porque o tio Bill é o capiroto encarnado, e por nada deste mundo teria um “eipou” (li isso de um enrustido num fórum uma vez), colega, baixe a guarda. A melhor coisa que descobri ao envelhecer como profissional de TI foi quando comecei a encarar o sistema operacional e qualquer outro software como commodity.
Passei muito tempo brigando contra colegas de trabalho sobre o que era melhor para chegar a conclusão que o melhor sempre era o que cada um tinha. Tinha um amigo fanático por Android, e defendia até morte, falando horrores dos concorrentes. Isso durou até ele comprar um Windows Phone, que passou a ser a oitava maravilha do mundo. Morte ao Android e iOS. Aí, veio o iPhone. Pronto, Android era um lixo cheio de vírus e Windows Phone era travado não tinha apps. O mesmo se deu com ontro colega era Windows, passou para Mac e agora é Ubuntu.
A melhor ferramenta é aquela que você usa. Pois bem, quando você desliga essa chave do orgulho exacerbado, você começa a enxergar as coisas mais claramente.
E é nisso que me baseei para chegar no título do artigo e por fim, em uma conclusão. O Visual Studio foi a ferramenta mais completa com a qual tive contato para a maior parte dos tipos de aplicativo que precisei trabalhar. Do editor poderoso, passagem pelo gerenciador de janelas, integração com controles de versão, tipos de projeto e o ápice, que são as ferramentas de depuração, o Visual Studio entrega em um pacotão só um Kit de ferramentas que abraça do que comumente é preciso alguns utilitários para alcançar. Para o povo da nova web, digamos que ele faz (e já faz um bom tempo) o que o bower, grunt e yeoman fazem hoje.
E aos que vierem com os argumentos de preço, uma novidade. A Microsoft há tempos oferece versões gratuitas e bem completas do Visual Studio para livre uso, que são as Express. São versões dedicadas a tipos de aplicativos, que no caso de vocês, basta se concentrar na versão web. Aos que acharem que a ferramenta não é suficientemente completa, coordenei com muito exito alguns projetos onde os devs utilizavam Visual Studio Ultimante e os Designers/Front End utilizavam as versões Express, sem problemas ou conflitos.
Se não bastasse tudo isso, recentemente (na verdade, parei a escrita deste artigo enquanto fiquei sabendo da notícia) a Microsoft liberou a versão completa do Visual Studio chamada Community, que é composta pela ferramenta integrada, com licença livre estudo e projetos Open Source. Quer saber mais?
E para os que ainda acham que tudo isso é balela, a Microsoft liberou o código da nova versão do .NET Framework, que já virá com versões compiladas para pronta execução em Linux e Macs. Quer saber mais?
Não bastasse isso, a Microsoft também liberou uma ferramenta chamada Visual Studio Code, um editor para código .NET multiplataforma e gratuito. Quer saber mais?
No momento da escrita deste artigo, o Visual Studio Code ainda estava em beta.
Concluindo
O fim deste artigo pode ter parecido algo como uma propaganda para a Microsoft. E não poderia ser diferente. Porém, esta não é a intenção aqui.
A intenção foi convidar aos que ainda alimentam um pouco de preconceito pelas ferramentas da Microsoft, que abram a mente e façam pelo menos um teste. Da mesma forma que fiz do mundo Microsoft para o mundo Open Source, o caminho contrário pode ser cheio de boas surpresas.
Algo que não mudará é a dependência do Windows, afinal, estamos falando de Microsoft. Caso ele não esteja à mão, é ao menos possível dar uma chance ao Visual Studio Code.
