Assignee removed

Adiado para a próxima Sprint. Vamos focar em estabilizar o Rails 4.

Reassigned to @terceiro

mentioned in issue #67

comecei a trabalhar nisso hoje, usando o branch indicado + um perfil com o tema angular-theme. cheguei até a ver o tema rodando. quando estava tentando logar com um usuário que não estava ativado ainda, dá o seguinte crash:

[2016-02-18 21:13:28 -0200] ERROR -- uninitialized constant Noosfero::API::Session::NoosferoExceptions
    /vagrant/lib/noosfero/api/session.rb:38:in `rescue in block in <class:Session>'
    /vagrant/lib/noosfero/api/session.rb:36:in `block in <class:Session>'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/endpoint.rb:67:in `call'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/endpoint.rb:67:in `block (2 levels) in generate_api_method'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/activesupport-4.2.5/lib/active_support/notifications.rb:166:in `instrument'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/endpoint.rb:66:in `block in generate_api_method'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/endpoint.rb:263:in `call'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/endpoint.rb:263:in `block in run'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/activesupport-4.2.5/lib/active_support/notifications.rb:166:in `instrument'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/endpoint.rb:231:in `run'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/endpoint.rb:314:in `block in build_stack'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/middleware/base.rb:25:in `call'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/middleware/base.rb:25:in `call!'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/middleware/base.rb:19:in `call'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/middleware/base.rb:25:in `call!'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/middleware/base.rb:19:in `call'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/rack-contrib-1.4.0/lib/rack/contrib/jsonp.rb:38:in `call'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/middleware/error.rb:27:in `block in call!'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/middleware/error.rb:26:in `catch'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/middleware/error.rb:26:in `call!'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/middleware/base.rb:19:in `call'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/rack-1.6.4/lib/rack/head.rb:13:in `call'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/endpoint.rb:215:in `call!'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/endpoint.rb:209:in `call'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/rack-mount-0.8.3/lib/rack/mount/route_set.rb:152:in `block in call'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/rack-mount-0.8.3/lib/rack/mount/code_generation.rb:96:in `block in recognize'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/rack-mount-0.8.3/lib/rack/mount/code_generation.rb:68:in `optimized_each'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/rack-mount-0.8.3/lib/rack/mount/code_generation.rb:95:in `recognize'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/rack-mount-0.8.3/lib/rack/mount/route_set.rb:141:in `call'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/api.rb:114:in `call'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/api.rb:44:in `call!'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/grape-0.14.0/lib/grape/api.rb:39:in `call'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/rack-1.6.4/lib/rack/cascade.rb:33:in `block in call'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/rack-1.6.4/lib/rack/cascade.rb:24:in `each'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/rack-1.6.4/lib/rack/cascade.rb:24:in `call'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/rack-cors-0.4.0/lib/rack/cors.rb:80:in `call'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/unicorn-4.9.0/lib/unicorn/http_server.rb:580:in `process_client'
    /vagrant/lib/noosfero/scheduler/defer.rb:86:in `process_client'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/unicorn-4.9.0/lib/unicorn/http_server.rb:674:in `worker_loop'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/unicorn-4.9.0/lib/unicorn/http_server.rb:529:in `spawn_missing_workers'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/unicorn-4.9.0/lib/unicorn/http_server.rb:140:in `start'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/gems/unicorn-4.9.0/bin/unicorn_rails:209:in `<top (required)>'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/bin/unicorn_rails:23:in `load'
    /home/vagrant/.ruby-standalone/gems/ruby/2.1.0/bin/unicorn_rails:23:in `<main>'

quando tentei com um usuário válido, rolou ok.

impressões iniciais:

• a abordagem traz váááárias outras dependências, npm, gulp etc. eu não tenho idéia de como vai ser o deploy disso. (talvez fosse o caso de investigar uma abordagem usando o asset pipeline do próprio rails pra não ter que trazer todo esse ferramental novo)
• eu acho que durante a instalação eu vi algum pacote nodejs desse baixando binários da internet. eu não verifiquei a fundo, mas se ele não estiver usando https e não estiver checando hash do arquivo, isso é um problema grave.
• acho que o fato de ser "apenas um tema" é uma ótima idéia, porque esse frontend novo pode conviver no mesmo servidor de aplicação com o frontend atual. por outro lado, nesse frontend a gente teria de fato que duplicar todo o frontend existente, acho difícil conseguir compartilhar código com o frontend antigo.
• bugzinho: quando eu clico no logo do noosfero eu volto para o "/", mas o "/" não está com esse tema selecionado.

segunda feira retomo esse processo

@terceiro, vou comentar cada um dos pontos:

1. Acho importante trazer o ecossistema padrão que se utiliza para desenvolver nas tecnologias propostas para essa POC;
2. Não reparei mas estamos usando a gestão de dependências comum aos projetos desse tipo;
3. A ideia é ser disruptivo com o modelo atual do frontend e não reaproveitar nada do antigo. Por isso a ideia de ser um tema, para que a transição seja opcional.
4. É uma prova de conceito, várias coisas não foram consideradas (essa é só uma delas).

segue a minha opinião ...

Novo frontend como um tema

Acho que fazer o novo frontend como um tema é uma ótima idéia, e possibilita ter o novo frontend ao mesmo tempo que o antigo. Por exemplo aquela estória que google/facebook fazem às vezes e pedir para abilitar a "versão nova", permitindo você voltar à antiga se quiser. A idéia que eu tinha tido de ter o novo frontend como uma opção ao iniciar o servidor de aplicação não permitiria isso.

Angular e Javascript

Separei um tempo pra "aprender" Angular seguindo o tutorial no site e fazendo uma brincadeirinha ou outra com o código do próprio tutorial. Segue a minha percepção sobre.

Prós:

• permite uma organização do código do frontend muito boa, com componentes desacoplados e testáveis.

• facilita muito o desenvolvimento de frontends com boa interatividade

• se bem usado, possibilita reduzir muito a carga no servidor e fazer frontends com tempo de resposta muito melhor.

Contras:

• Corremos o risco de chegar numa situação onde uma parte das pessoas só consegue trabalhar no backend do noosfero, e outra parte só consegue trabalhar no frontend, porquê os 2 seriam substancialmente diferentes. Talvez pra aplicações do porte do noosfero isso seja inevitável (?)

• Javascript como uma linguagem é um lixo, e eu pessoalmente preferiria nunca tem que desenvolver nada além do trivial em JS. Provavelmente eu sou só um cara chato, e essa é uma tendência sem volta. :-/

Toolchain

O que mais me preocupa é o toolchain. A prova de conceito está usando npm, bower, e gulp. Apesar da documentação do Angula assumir esse tipo de coisa, seguindo o tutorial eu só precisei dar um npm install uma vez no início e era isso, o resto todo foi independente.

Eu entendo que "a comunidade de frontend" esteja usando essas ferramentas, e tudo mais, mas:

• ter 2 toolchains diferentes no projeto noosfero (o do rails + npm/bower/gulp) provavelmente pode agravar o que comentei acima sobre criarmos "nichos" de desenvolvimento e dificultar ainda mais que as pessoas sejam capazes de atuar em qualquer parte do projeto.

• efetivamente, gulp dublica a funcionalidade do asset pipeline.

• o grafo de dependencia dessas coisa é insano, e talvez não seja viável ter pacotes debian disso tão cedo (como o pessoal do SERPRO usar rubygems/npm/bower/gulp/etc, eles provavelmente não se importam com isso).

a gente teria duas opções: ou utilizar Angular através do toolchain to rails (i.e. asset pipeline), ou simplesmente se dar por vencido e cair pra dentro de npm/bower/gulp etc etc.

Sugestão de encaminhamento

• Fazer o novo frontend como um tema; usar Angular parece ser uma boa escolha
• Ao invés de escrever 1 única aplicação Angular para todo o frontend, provavelmente seria bom escrever uma aplicação Angular "pequena" para grande parte do frontend, e.g.:
  • home (/)
  • "mural"/timeline (hoje está misturado com o perfil)
  • perfil (/profile/$fulano)
  • painel de controle
  • conteúdo (content\_viewer). talvez uma específica para cada tipo de conteúdo? assim ficaria bem extensível.
• Tentar utilizar o toolchain to Rails (i.e. asset pipeline) ao invés de introduzir npm/bower/etc. A opção mais utilizada parece ser angularjs-rails.

tem que ver se a infra de testes do angular, que é muito boa por sinal (karma/jasmine/protractor etc), está disponível via rubygems, ou se pelo menos a gente consegue algo equivalente. se não rolar, provavelmente não tem escapatória dos npm/bower/gulp da vida.

valeu @terceiro!

@diguliu @daniela @melissawen, quero conversar com vocês para alinharmos os desdobramentos disso, possivelmente o @marcosronaldo ficará com esta missão, claro que todos nós teremos que dar suporte à ele. Vamos conversar na segunda-feira dia 29/02? Vou mandar email sugerindo horário.

@terceiro alguma objeção quanto ao uso do TypeScript?

@terceiro Legal sua avaliação!

Comento apenas que as ferramentas npm, bower, etc não precisariam estar inclusas no pacote debian, apenas os js e css gerados como resultado da execução delas. Precisaríamos delas apenas no ambiente de desenvolvimento.

@joenio por mim, tranquilo na segunda! Prefiro a tarde ;)

@joenio Blz por mim, de manhã ou de tarde.

Status changed to closed

oi @joenio, chegaram a alguma posição sobre essa issue?

oi @vfcosta, conversamos internamente, infelizmente @terceiro não participou pois está no evento do Debian esses dias, mas ficou encaminhado que @marcosronaldo irá assumir isso, com apoio do resto da equipe, devo marcar outro bate-papo quando terceiro tiver disponibilidade e gostaria da sua presença nessa reunião.

mentioned in issue #145

legal @joenio, conte com a gente!