You are currently browsing the archives for the .net category


.NET 2015: Ótima notícia para usuários de Mac e Linux

Sou muito fã de .NET – curto muito C#, F# e ASP.NET MVC –, mas ter que bootar um Windão no meu Mac para poder mexer com isso nunca foi, absolutamente, algo que me agradou. Já tentei usar Mono algumas vezes, mas hmmmm acabou não rolando muito pra mim, então a solução do Windão no Parallels acabou sendo a menos inconveniente pra mim até hoje.

Mas agora há pouco li uma notícia que promete mudar isso de uma vez por todas:

Announcing .NET 2015 – .NET as Open Source, .NET on Mac and Linux, and Visual Studio Community

Pelo que diz o post, os caras estão construindo uma .NET Core CLR para Windows, Mac e Linux, totalmente open source e suportada pela Microsoft. E além disso, também, um web server chamado Kestrel, baseado em libuv, para rodar ASP.NET 5 no Mac e no Linux.

No que diz respeito a ferramentas de desenvolvimento, a galera que desenvolve o ASP.NET e web tools está trabalhando num projeto chamado OmniSharp, que prove “real intellisense & stuff” para SublimeText, Vim, Emacs, etc. Ou seja, vai melhorar bastante a experiência de desenvolvimento .NET em Mac e Linux.

So sweet.

Página nova e contratações

Virei a página outra vez….

Ontem assumi como diretor de tecnologia da Urban Summer, uma agência digital bem bacana, que tem feito trabalhos incríveis para uma porção de clientes legais. E como de costume, cá estou eu procurando por gente boa para trabalhar no meu time.

Tenho algumas vagas em aberto, que ainda vou postar aqui com mais detalhes, mas de cara, urgente, urgentíssimo, estou procurando por dois desenvolvedores client-side, como uns dois anos de experiência mais ou menos, com bastante habilidade em:

  • Recortar imagem – você pega um PSD e faz a mágica para transformar em página web
  • HTML
  • CSS
  • JavaScript

Se souber programar “razoavelmente bem” em Python, PHP, C#.NET, Objective-C, Java ou Ruby, que beleza, isso conta ponto a seu favor. Mas se não souber, tudo bem, não tem problema; esse não é um requisito obrigatório.

Se você não tiver interesse, mas souber de um camarada que tem, indique! Eu ficarei grato. Ele, certamente, também ficará – talvez ele até lhe pague um café.

Aguardo contato em leandro@urbansummer.com.br.

Valeu!

Composição e Integração de Sistemas em 2013

Hoje estive falando no TDC 2013, na trilha Arquitetura .NET, sobre a estratégia de compor e integrar sistemas a partir de micro-serviços, que é um tema que tenho bastante interesse e pretendo ainda falar um pouco mais a respeito, em eventos e aqui no meu blog.

Esta foi a segunda vez que falei nesse evento e, assim como no ano passado, a sala estava lotada, o pessoal bem interessado e participativo; e no final, uma galerinha veio trocar uma idéia comigo, fazer perguntas, etc. Foi bem bacana mesmo.

Parabéns aos organizadores e ao pessoal que participou!

A Locaweb está contratando!

A Locaweb está procurando por desenvolvedores experiêntes e talentosos para integrar nossos times de SaaS, Cloud Computing, Hospedagem, Q&A e Sistemas Centrais.

Se você tem experiência em Ruby, Python, Java, .NET, PHP, Perl, bancos de dados relacionais e não-relacionais, arquiteturas distribuídas, sistemas de agendamento de tarefas, filas assíncronas, desenvolvimento web, e umas coisinhas mais, pode ser que tenhamos um lugar aqui para você. Que tal?

O perfil completo pode ser visto na integra aqui, no OndeTrabalhar.com.

O quanto realmente importa a escolha de uma linguagem?

Há alguns meses perguntaram ao Rich Hickey:

“How much does a choice of language really matter? Are there good reasons to choose one language over another or does it all come down to taste?”

E sua resposta foi:

“I think it matters quite a bit. A good language is opinionated, and strives to make a particular style of programming easy and idiomatic. It only seems a matter of taste when you are comparing languages that are more similar than they are different, like Java/C# or Python/Ruby. Try something really different like Clojure, Haskell, or Erlang and the fact that it matters becomes readily apparent.”

Eu acho que concordo bastante com sua opinião. Discutir se Java é melhor do que C#, por exemplo, é inútil, porque as duas linguagens são muito semelhantes. Nesse caso, o que acaba pesando mais na hora da escolha é o ecosistema no qual cada linguagem está inserida, que pode agradar mais a um ou a outro programador. É puro gosto.

O mesmo vale para Ruby e Python, como ele mesmo cita.

Mundos diferentes

Mas e se a comparação for entre Java e Ruby, por exemplo, como é que fica? Na minha humilde opinião, fica no sense. Porque Java e Ruby não são liguagens de mesma proposta; e mesmo sendo ambas de propósito geral, ambas tem objetivos claramente diferentes.

Comparação entre mundos diferentes

Agora vou, propositalmente, contradizer um pouco o que eu disse à cima: faz sentido, sim, você comparar Ruby com Java; Erlang com Python; F# com PHP. Sim, faz sentido.

Faz sentido quando você está escolhendo a linguagem que oferece a melhor solução para um dado domínio de problema.

Super CRUD com Erlang? Não, acho que não.

Precisar de concorrência massiva, tolerância a falhas, processos distribuídos, downtime mínimo? Humm, não sei não, mas será que não é de Erlang que você precisa?

Entende? É nessa hora que a escolha de uma linguagem começa a pesar de verdade. Isso realmente importa.

Mundos diferentes se complementam

Tempos atrás, escrevendo programas Erlang/OTP, senti falta de uma ferramenta que me ajudasse a criar rapidamente a estrutura inicial do projeto e umas coisas mais. O que fiz? Criei uma ferramenta que faz isso: otp_kickoff. Em Erlang? Não, em Ruby. Fiz isso em poucas horas, usando Thor.

Pouco tempo depois, senti falta de uma ferramenta de build amigável. Novamente, o que fiz? Criei o ebuilder, usando Ruby/Thor.

Um outro exemplo de mundos diferentes que se complementam é o JSparrow, um cliente de JMS bem fluente, que fiz usando JRuby.

Essa é a ideia de tirar o melhor de cada linguagem!

Mesmo porque, dificilmente, você constroi um sistema de verdade – que não seja um super CRUD – com apenas uma única linguagem de programação. Na minha equipe mesmo, há sistemas desenvolvidos em C# .NET, que são buildados, testados e deployados com Ruby/Rake/Cucumber e usam Java/Ivy como repositório de assemblies. Isso sem falar em JavaScript, que também tem de monte.

Esse é o mundo real dos sistemas de verdade.

Moral da história

Isso me faz pensar que brigas de fanboys de linguagens – em frenéticas buscas por prosélitos – são uma verdadeira piada.

Quer saber onde será seu próximo trabalho?

Então não deixe de visitar…

O site é recém-nascido, mas já tem uns recursos bem legais, como sistema de pesquisa por palavras-chave, núvem de tags e entre outros. Vale a pena conferir e acompanhar sua evolução – e oportunidades de bons trabalhos.

Mais uma iniciativa bem interessante da Caelum. :)

Entrevista com Ola Bini: Ioke, JVM, .NET e mais!

Quem me conhece há algum tempo ou acompanha este meu blog, sabe que eu sou totalmente meio fissurado por linguagens de programação. Sempre estou dando uma olhada em uma aqui e outra ali. Lendo, fuçando…

Mas tem um cara que com certeza é ainda muito mais fissurado em linguagens de programação do que eu - e diferente de mim, manja pra caramba. Esse cara é o Ola Bini, membro do core team do JRuby, consultor da ThoughtWorks, escritor do livro JRuby on Rails, membro do expert group da JSR-292 e criador da linguagem Ioke.

Bem, como não podia deixar de ser, eu resolvi fazer uma pequena entrevista com ele sobre Ioke, linguagens para a JVM e a Microsoft CLR, e uma coisinha ou duas mais. Confira!

Ola Bini e nosso compatriota Fábio Akita

Ola Bini e o nosso patrício Fábio Akita (QCon 2008)

Fale-nos um pouco sobre sua paixão por linguagens de programação. Quando isto começou? O que mais te motivou?

Oh wow. Boa pergunta. Eu não sei quando isto começou. Em algum momento obscuro do passado – muito longe para me lembrar. =)

Eu comecei bem cedo, com Basic no Apple IIc. Fiz muito C e assembler na minha adolecencia, e então, aprendi C++, Java e Lisp.

Penso que minha atual facinação por linguagens começou quanto eu percebi como diferentes linguagens são e como muitas coisas ruins são usadas. Esta percepção levou algum tempo, mas ficou cada vez maior.

Eu comecei com a implementação de outra linguagem há 5-6 anos atrás.

Além de contribuir com o projeto JRuby, você também criou a linguagem Ioke do zero. O que você tem a dizer sobre a JVM com plataforma para outras linguagens (além da linguagem Java)?

Sim. Então, a JVM é uma excelente plataforma para linguagens. Você tem um JIT muito maduro no Hotspot. Você tem garbage collectors fantásticos; e você tem um monte de bibliotecas e ferramentas disponíveis. A parte ruim é que a JVM atualmente está muito amarrada a linguagens que se parecem com Java, no nível do bytecode. É possível contornar isto, e nós estamos trabalhando na JSR292 para dar suporte a invocações dinâmicas na JVM.

Mas atualmente a JVM ainda está um bocado ligada a linguagens como Java. Isto não é necessário a tudo (muitas das tecnologias Java começaram em Smalltalk e Strongtalk).

Você acredita que a linguagem Java está caminhando para se tornar em uma linguagem de infra-estrutura? (Uma linguagem para escrever linguagens e outros componentes críticos de infra-estrutura.)

Espero que sim. Java não é uma boa linguagem para escrever aplicações – ela é realmente muito baixo nível.

Sobre Ioke. O que levou você a começar o projeto desta linguagem? Onde você pensa chegar com ela? O que você planeja para o futuro de Ioke?

Basicamente, a ideia com Ioke é ver o quão expressiva você pode fazer uma linguagem; e isto é o que tenho feito. Isto tem dado características linguísticas bastante avançadas; você pode fazer coisas nela que muitas pessoas inicialmente tem problemas para entender – mas ela permite você escrever código bastante sucinto e legível, que capture suas intenções.

O que acontecerá exatamente no futuro está no ar. Tenho muitas idéias, mas nada concreto no momento.

Recentemente, você também portou a linguagem Ioke para a Microsoft CLR. O que te motivou a fazer isto? O que você pensa sobre a plataform Microsft .NET como plataforma host para novas linguagens?

Sim! Eu fiz isto porque não queria que Ioke fosse somente uma linguagem da JVM. Queria ver como a CLR funcionaria para implementa-la e queria amplicar um pouco a base de usuário. A plataforma .NET é mais ou menos tão boa quanto a JVM. Algumas coisas são piores, outras são melhores.

O que você recomenda a aqueles que gostariam de, como você, serem designers de linguagens para a JVM? Esta recomendação seria mais ou menos a mesma para a plataforma .NET?

Há duas coisas que você precisa fazer. A primeira é ter uma boa idéia de como diferentes linguagens funcionam. Você precisa aprender linguagens de diferentes paradigmas e tentar entender como elas podem ser implementadas. Então, você precisa começar a fazer. Esta é a parte mais importante.

Comece realmente a implementar e ver o que acontece.

Finalmente, sinta-se à vontade para dizer o que quiser sobre Ioke.

Ela é muito “louca”. Ela é expressiva. Ela é muito lenta.

Penso que esta coisa de expressividade vai ser importante no futuro – já que nós estamos fazendo coisas mais e mais avançadas. Texto não escala se não podemos ter uma abstração estrutural (1). Ioke permite isto.

(1) N.T.: O que o Ola Bini quis dizer é que “texto, por si só, não pode ir a um nível superior, não pode evoluir, crescer, se não pudermos ter uma abstração estrutural sobre ele”. :)

Um pouco de diversão com Scala

Scala é uma linguagem de programação muito flexivel, que possibilita conceber construções extremamente sofisticadas, o que facilita bastante a criação de DSLs. Ela combina dois poderosos paradigmas: Programação Orientada a Objetos e Programação Funcional. Tudo em Scala é um objeto, inclusive, funções. Ela não é a única que faz isso, mas vem ganhando aplausos pelo seu design sofisticado. Na verdade, Scala foi inspirada em muitas linguagens – Java, C++, Smalltalk, Eiffel, OCaml, F#, Haskell, Erlang.

Scala também possui um ótimo modelo de programação concorrente, inspirado nos poderosos atores de Erlang.

Não bastasse tudo isso, Scala é open source e possui implementações para a plataforma Java e .NET.

Uma das coisas que mais gosto em Scala é sua natureza funcional. Não que eu seja um mestre da programação funcional. Mas este é um paradigma que tenho aprendido a apreciar bastante.

Sobre esse extenso assunto, quero fazer uma pequenina citação a “funções”.

Uma função em Scala é um first-class value. Como qualquer outro valor, uma função pode ser passada por parâmetro para outra função, bem como ser retornada como resultado. Funções que recebem outras funções como parâmetro ou retornam como resultado são chamadas de higher-order function. Isso dá um flexibilidade impressionante!

Um exemplo?

object Calculo {
  def soma(func: Int => Int, a: Int, b: Int): Int =
    if (a == 0 || b == 0) func(10) else a + b

  def main(args: Array[String]) {
    println("Ex1: " + soma((x: Int) => x + 100, 0, 0))
    println("Ex2: " + soma((x: Int) => x + 100, 10, 20))
  }
}

Este é um programinha bastante simples. O que ele faz é criar um objeto Calculo, que funciona como uma instância singleton, e executá-o a partir do método main – semelhantemente ao que acontece em Java.

Além do método main, lá está nossa função soma. Ela é uma função simples de soma. Bem, não tão simples assim. Ela recebe uma função anonima por parâmetro (func) e, caso a ou b seja zero, ela a usa passando 10 como parâmetro.

Se quiser rodar este programinha e ver o resultado de sua execução, basta:

1- Instalar a versão de Scala para seu SO;
2- Salvar esse código em um arquivo Calculo.scala;
3- Compilar esse arquivo com scalac Calculo.scala;
4- Executar com scala Calculo.

Scala é uma linguagem fantástica. Quando mais a conheço, mais a aprecio!

JRuby ou Groovy?

Não, não quero começar nenhum flame war em torno de JRuby e Groovy.

O que ocorre é que ontem um cara que tem um blog legal, o Diego, fez um comentário num de meus posts que me fez pensar a respeito… Até agora…

Na hora, sinceramente, não tive nada de muito substancial para responder, porque ainda não havia pensado a respeito. Mas tenho que confessar que isso ficou martelando a minha cabeça o tempo todo… Existe alguma vantagem de se usar Groovy invés de JRuby?

Bem, lendo e pensando a respeito, cheguei a algumas simples conclusões:

Se você tem familiaridade com Java e quer permanecer 100% no ambiente Java, sem a perspectiva de migrar, Groovy é a melhor opção pra você.

Porque a sintaxe de Groovy é muito parecida com a de Java; Groovy traz consigo uma porção de vantagens de uma linguagem OO moderna e dinâmica, como meta-programação, duck type, e closures; e você ainda pode programar usando objetos Java e Groovy numa mesma classe, de forma totalmente transparente (já que .groovy ao ser compilado se transforma em um .class qualquer).

Só que, mais uma vez: Não há qualquer possibilidade de se rodar código Groovy fora de ambiente Java, porque Groovy foi especificamente criada para ser uma “alternativa” à linguagem Java.

Se você quer que seu código seja portável para outras plataformas de runtime, tal como .Net, por exemplo, JRuby é o melhor pra você.

Acho que este é um dos fatores primordiais na escolha de JRuby invés de Groovy. Porque o fato da sintaxe de Groovy ser próxima à de Java, sinceramente, pra mim não quer dizer nada – aprender uma nova sintaxe não é coisa de outro mundo; e é até legal. Agora, portabilidade, isto sim faz a diferença – quando necessário, claro.

Você pode escrever, por exemplo, uma aplicação Ruby on Rails comum e coloca-la para rodar em um web container Java, sem muito esforço. Aliás, se você estiver usando o NetBeans, ele faz isso pra você em um ou dois cliques. E se num dado momento decidir rodar, sei lá, num Mongrel, tudo bem, você pode fazer isso sem problema algum. Isto é fantástico!

Se você quiser se manter 100% compatível com a MRI, isto é totalmente possível, porque JRuby é uma implementação completa de Ruby para a plataforma Java. E se você quiser aproveitar algum código escrito em Java, você também pode fazer isto – mas neste caso, claro, sacrificando a portabilidade.

Outro fator primordial que vejo é “comunidade”.

A comunidade JRuby tem crescido a cada dia – claro que por conta do próprio Ruby/Rails. E a indústria de software tem investido nisto, aja vista o ótimo suporte do NetBeans a Ruby/Rails; e a própria contratação de membros chaves do JRuby pela Sun há algum tempo.

E a comunidade Groovy? Bem, acho que Grails tem ajudado a levanta-la. Mas o seu barulho ainda não é dos maiores não. (Espero que isto mude.)

E o fim deste pensamento, qual é?

Use JRuby. Use Groovy. Use o que melhor atender aos seus próprios requisitos e aos de seu cliente. Porque não há apenas uma linguagem de programação, nem uma única solução pra tudo!

Atualmente estou propenso a usar tanto JRuby [on Rails] quanto Groovy [on Rails]. O que vai me fazer decidir entre um e outro serão os requisitos do momento – e a expectativa futura.

Então, seja JRuby ou Groovy, o que importa é desenvolver o software certo, no tempo certo, com a qualidade certa.

(Valeu Diego, por me fazer pensar um pouco sobre isto.)

Até a próxima!

Projeto Da Vinci Machine

A Sun caminha a passos cada vez mais largos em direção à consolidação da Plataforma Java como tecnologia de base para multiplas linguagens de programação, tal como a plataforma .Net da Microsoft. Assunto que abordei em um de meus posts recentemente.

Mais um grande esforço neste sentido é o projeto Da Vinci Machine, que visa facilitar a implementação de outras linguagens para a JVM.

New York Times/IDG: Sun’s Da Vinci Machine Broadens JVM Coverage.