Re: [SP-pm] https://github.com/TJRest

2015-11-04 Por tôpico Daniel Vinciguerra 
Interessante o Mithril, não conhecia! :)



*Daniel Vinciguerra*
Web Solutions Architect and founder at Bivee
Cel: +55 (47) 9270-6171

*ATENÇÃO/ATTENTION:*
Este e-mail contém informações confidenciais e seu conteúdo é dirigido ao
uso do indivíduo ou da entidade mencionados acima. Se você recebeu esta
mensagem por engano, por favor, notifique o remetente e remova-o
imediatamente.


This e-mail contains confidential information intended only for the use of
the individual or entity named above. If you are not the intended
recipient, please notify the sender and delete it immediately.

2015-11-01 22:25 GMT-02:00 Eduardo Almeida :

> Em 11/1/15 19:43, Leonardo Ruoso escreveu:
>
> Aliás, digo-lhe, meus maiores pesadelos foram causados por desenvolvedores
> hackers que se acreditavam melhores por estarem fazendo coisas "na mão" em
> vez de seguir a arquitetura definida, seja no JS, no Perl ou no Java.
>
> Espero que não tenha entendido que eu sugeri isso: 'fazer na mão' ... na
> verdade eu estava falando sobre saber o que está fazendo.
>
> Inclusive, vai me desculpar, mas gerar componentes e com views explícitos,
> é 'fazer na mão', uma vez que você tem isso bem abstraído e com APIs e docs
> bem ricas e maduras como no EXT, DHTMLX, Dojo, Qooxdoo ... ai nesse
> quesito, angular, backbone e coisas afins, estão bem mais perto de 'fazer
> na mão' ... Se preocupar com HTML e css, hoje, pra mim, é fazer na mão.
>
> Abraços
>
> --
> Eduardo Almeida - Software Engineer
> edua...@web2solutions.com.br - 27.99831.8663
>
> *WEB2 Solutions* - Inovando, sempre!
>
> =begin disclaimer
>Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
>  L
> =end disclaimer
>
>
=begin disclaimer
   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
 SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
 L
=end disclaimer

Re: [SP-pm] https://github.com/TJRest

2015-11-01 Por tôpico Leonardo Ruoso 
Em 31/10/2015 4:59 PM, "Eduardo Almeida" 
escreveu:
>
> Em 10/31/15 08:23, Leonardo Ruoso escreveu:
>>
>> Não creio que o preço de tradução de código seja realmente uma questão
para grande parte dos desenvolvedores, quer estejam usando Dart, TypeScript
ou CofeeScript. Nem para quem está usando Jade, nem para quem está usando
SAAS/LESS.
>
> Ok, então você vai transpilar com grunt por exemplo, e não no browser ...

Isso é o que normalmente se faz com todos os recursos. O browser vai
receber um único objeto minimizado contendo JavaScript, templates, tudo.

> Leonardo, deixa eu te perguntar, você ja fez algum experimento desse
tipo? Ja escreveu alguma app em ES6 ou Typescript?

TypeScript especificamente não, mas outros supersets, sim, vários. Tanto de
JS, como de HTML e CSS. Não consigo ver onde estaria qualquer armadilha
especial do TypeScript. Pelo contrário, pelo que estamos vendo em PoC, pelo
que estamos conversando com colegas que estão usando e pela análise
conceitual, TypeScript parece uma escolha bastante consistente.

> Se ja, ok, você ja sabe onde está pisando. Te garanto que há "ovos e
cacos de vidro" por esse caminho.

Difícil que aja mais ovos e cascos de vidro que juntar um time de
desenvolvedores experientes que sabem JavaScript e jQuery e deixá-los
escrever código nos controles do Angular 1 ;)

> Sinceramente, se você ta querendo fazer um app séria,

Opa, até jogos são sérios.

> na minha humilde opnião, há muitos outros aspectos que você deveria dar
mais foco, do que querer modernizar seu ambiente de desenvolvimento.

Eu pareço querer modernizar o ambiente por si só? Se sim, eu me expressei
mal. Minha necessidade de modernizar vem de uma dificuldade em fazer
algumas coisas básicas com Angular 1, pior ainda sem. Uma série de coisas
que foram revistas com muito carinho Angular 2.

> Mais uma vez, na minha opnião, ter bons e verdadeiros devs de ES5,

Claro, claro.

Quando eu consego uns cinco bons e verdadeiros desenvolvedores de qualquer
coisa em um projeto com 12 mais alguns trainees meu nível de estresse cai
80% e eu passo a me preocupar quase que exclusivamente com o domínio da
aplicação. E me considero tendo um dream team.

> é a melhor solução (atualmente) frente a qualquer coisa que vc possa me
apresentar

Melhor solução é não usar framework?

>
>
> Abraços
>
>
> --
> Eduardo Almeida - Software Engineer
> edua...@web2solutions.com.br - 27.99831.8663
>
> WEB2 Solutions - Inovando, sempre!
>
> =begin disclaimer
>Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
>  L
> =end disclaimer
>
=begin disclaimer
   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
 SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
 L
=end disclaimer

Re: [SP-pm] https://github.com/TJRest

2015-11-01 Por tôpico Leonardo Ruoso 
Acho que há momentos em que os objetivos e os métodos se tornam tão
distantes que não há como conciliar.

Algumas pessoas acham que é mais fácil formar um desenvolvedor com
ferramentas de naus baixo nível, eu acredito que quão maior a abstração
melhor, mais próximo do que "do que" e não "de como".

Algumas pessoas acham que você deve ensinar Perl sem Moose, eu me sentiria
um idiota se fosse fazê-lo. Mesma coisa, a meu ver, a diferença de usar
backbone, para usar angular, para usar angular 2.

Facebook, Google, Twitter não me servem mesmo de parâmetro. São
discrepantes. Servem como laboratório para muita tecnologia, mas realmente
eles tem de ser preocupar com otimização num nível em que eu poucas vezes
precisei me preocupar, e quando o fiz provavelmente estava errado.

Muito mais importante para mim é criar um ambiente no qual o desenvolvedor
tenda mais a implementar OOP em vez de procedural, Rest em vez de RPC,
etc...

Aliás, digo-lhe, meus maiores pesadelos foram causados por desenvolvedores
hackers que se acreditavam melhores por estarem fazendo coisas "na mão" em
vez de seguir a arquitetura definida, seja no JS, no Perl ou no Java.

Se não devesse satisfação a ninguém eu estaria investindo pesado no Apache
Ísis, não no Spring Data Rest. Infelizmente não tem nada nem próximo em
Perl, sobre o Cayalyst ou não. Talvez seja um investimento para Perl 6.

Em dom, 1 de nov de 2015 19:27, Eduardo Almeida <
edua...@web2solutions.com.br> escreveu:

Em 11/1/15 07:28, Leonardo Ruoso escreveu:


Em 31/10/2015 4:59 PM, "Eduardo Almeida" 
escreveu:
>
> Em 10/31/15 08:23, Leonardo Ruoso escreveu:
>>
>> Não creio que o preço de tradução de código seja realmente uma questão
para grande parte dos desenvolvedores, quer estejam usando Dart, TypeScript
ou CofeeScript. Nem para quem está usando Jade, nem para quem está usando
SAAS/LESS.
>
> Ok, então você vai transpilar com grunt por exemplo, e não no browser ...

Isso é o que normalmente se faz com todos os recursos. O browser vai
receber um único objeto minimizado contendo JavaScript, templates, tudo.


Sim. Só que não! ..  Nem sempre. Depende do tamanho da sua app ...
depende do tamanho da banda do cliente.
Ainda não dá pra eliminar o 'on demand loading', e que por enquanto não tem
como não ser assync.


Browserify é lindo, mas não é bala de prata pra tudo.

Se tamanho de banda fosse uma preocupação só minha, não veríamos isso:
http://

www.meioemensagem.com.br

/home/

midia

/noticias/2015/10/28/

Facebook-cria-o-dia-da-internet-lenta.html


Então, mais uma vez, depende do tamanho da app ... principalmente.

> Leonardo, deixa eu te perguntar, você ja fez algum experimento desse
tipo? Ja escreveu alguma app em ES6 ou Typescript?

TypeScript especificamente não, mas outros supersets, sim, vários. Tanto de
JS, como de HTML e CSS. Não consigo ver onde estaria qualquer armadilha
especial do TypeScript. Pelo contrário, pelo que estamos vendo em PoC, pelo
que estamos conversando com colegas que estão usando e pela análise
conceitual, TypeScript parece uma escolha bastante consistente.


A questão não é o Typescript, ES6, ou ate mesmo 7
A demanda de desenvolvedor Javascript é infinitamente maior que a oferta
(não entrando no mérito da qualidade do dev) .. ta ai o Upwork pra
comprovar isso.

Acho que o primeiro problema é o seguinte, se já é difícil cobrir vagas de
ES5, suponho que seria mais difícil cobrir vagas pra qualquer superset

Sinceramente, a única grande vantagem que vejo num superset, hoje, é tornar
por exemplo o OO mais simpático pra devs vindos de outras linguagens, que
na grande maioria das vezes, se sente perdido com tanto patterns utilizados
no ES5. Outras coisas importantes, podem ser implementadas com polyfills.

Gostaria MUITO de poder estar usando generator function nos browsers ...
mas acho que ainda tá um pouco difícil de isso acontecer

> Se ja, ok, você ja sabe onde está pisando. Te garanto que há "ovos e
cacos de vidro" por esse caminho.

Difícil que aja mais ovos e cascos de vidro que juntar um time de
desenvolvedores experientes que sabem JavaScript e jQuery e deixá-los
escrever código nos controles do Angular 1 ;)

> Sinceramente, se você ta querendo fazer um app séria,

Opa, até jogos são sérios.

> na minha humilde opnião, há muitos outros aspectos que você deveria dar
mais foco, do que

Re: [SP-pm] https://github.com/TJRest

2015-11-01 Por tôpico Eduardo Almeida 

Em 11/1/15 07:28, Leonardo Ruoso escreveu:



Em 31/10/2015 4:59 PM, "Eduardo Almeida" > escreveu:

>
> Em 10/31/15 08:23, Leonardo Ruoso escreveu:
>>
>> Não creio que o preço de tradução de código seja realmente uma 
questão para grande parte dos desenvolvedores, quer estejam usando 
Dart, TypeScript ou CofeeScript. Nem para quem está usando Jade, nem 
para quem está usando SAAS/LESS.

>
> Ok, então você vai transpilar com grunt por exemplo, e não no 
browser ...


Isso é o que normalmente se faz com todos os recursos. O browser vai 
receber um único objeto minimizado contendo JavaScript, templates, tudo.


Sim. Só que não! ..  Nem sempre. Depende do tamanho da sua app ... 
depende do tamanho da banda do cliente.
Ainda não dá pra eliminar o 'on demand loading', e que por enquanto não 
tem como não ser assync.


Browserify é lindo, mas não é bala de prata pra tudo.

Se tamanho de banda fosse uma preocupação só minha, não veríamos isso: 
http://www.meioemensagem.com.br/home/midia/noticias/2015/10/28/Facebook-cria-o-dia-da-internet-lenta.html


Então, mais uma vez, depende do tamanho da app ... principalmente.

> Leonardo, deixa eu te perguntar, você ja fez algum experimento desse 
tipo? Ja escreveu alguma app em ES6 ou Typescript?


TypeScript especificamente não, mas outros supersets, sim, vários. 
Tanto de JS, como de HTML e CSS. Não consigo ver onde estaria qualquer 
armadilha especial do TypeScript. Pelo contrário, pelo que estamos 
vendo em PoC, pelo que estamos conversando com colegas que estão 
usando e pela análise conceitual, TypeScript parece uma escolha 
bastante consistente.



A questão não é o Typescript, ES6, ou ate mesmo 7
A demanda de desenvolvedor Javascript é infinitamente maior que a oferta 
(não entrando no mérito da qualidade do dev) .. ta ai o Upwork pra 
comprovar isso.


Acho que o primeiro problema é o seguinte, se já é difícil cobrir vagas 
de ES5, suponho que seria mais difícil cobrir vagas pra qualquer superset


Sinceramente, a única grande vantagem que vejo num superset, hoje, é 
tornar por exemplo o OO mais simpático pra devs vindos de outras 
linguagens, que na grande maioria das vezes, se sente perdido com tanto 
patterns utilizados no ES5. Outras coisas importantes, podem ser 
implementadas com polyfills.


Gostaria MUITO de poder estar usando generator function nos browsers ... 
mas acho que ainda tá um pouco difícil de isso acontecer


> Se ja, ok, você ja sabe onde está pisando. Te garanto que há "ovos e 
cacos de vidro" por esse caminho.


Difícil que aja mais ovos e cascos de vidro que juntar um time de 
desenvolvedores experientes que sabem JavaScript e jQuery e deixá-los 
escrever código nos controles do Angular 1 ;)


> Sinceramente, se você ta querendo fazer um app séria,

Opa, até jogos são sérios.

> na minha humilde opnião, há muitos outros aspectos que você deveria 
dar mais foco, do que querer modernizar seu ambiente de desenvolvimento.


Eu pareço querer modernizar o ambiente por si só? Se sim, eu me 
expressei mal. Minha necessidade de modernizar vem de uma dificuldade 
em fazer algumas coisas básicas com Angular 1, pior ainda sem. Uma 
série de coisas que foram revistas com muito carinho Angular 2.


> Mais uma vez, na minha opnião, ter bons e verdadeiros devs de ES5,

Claro, claro.

Quando eu consego uns cinco bons e verdadeiros desenvolvedores de 
qualquer coisa em um projeto com 12 mais alguns trainees meu nível de 
estresse cai 80% e eu passo a me preocupar quase que exclusivamente 
com o domínio da aplicação. E me considero tendo um dream team.


> é a melhor solução (atualmente) frente a qualquer coisa que vc possa 
me apresentar


Melhor solução é não usar framework?

Não foi isso que eu disse. Ter bons devs ES5, frente á querer 
implementar qualquer coisa usando superset.


Com certeza usar framework sim, mas exceto o caso de se criar um MVP, eu 
não usaria frameworks pra diversas coisas como por exemplo:


- MVC Routing
3 objeto literal (ou functions) + 2 observers ou um pubsub, e ta 
implementado.
Lógico que não tão rico quanto ao modelo deles, mas meu exemplo é 
so pra fazer frente á questão de que nem sempre é necessário mais uma 
lib ... e mesmo considerando toda a spec do modelo deles, não é nenhum 
bixo de 7 cabeças pra implementar


- Data-Binding
facilmente resolvido com pubsub ... sem se aprofundar em nenhuma 
técnica aqui (podem variar de acordo com o paradigma)


- Templates
Bom, tem um monte de solução bacana por ai ...

- Diretivas
É apenas mais do mesmo, num paradigma diferente. Abstrair 
componentes ricos em chamadas simples é coisa do arco da velha,  vem 
sendo feito a muito tempo.


Como eu disse, só mudou paradigma .. coisas que EXT, DHTMLX, Dojo, 
Qooxdoo fazem com puro JS ( 1 ), o angular faz usando DOM explícito.


1 - esses frameworks também ja ofereciam a opção de se usar html com 
template pra gerar componentes.


Uma outra

Re: [SP-pm] https://github.com/TJRest

2015-11-01 Por tôpico Eduardo Almeida 

Em 11/1/15 19:43, Leonardo Ruoso escreveu:
Aliás, digo-lhe, meus maiores pesadelos foram causados por 
desenvolvedores hackers que se acreditavam melhores por estarem 
fazendo coisas "na mão" em vez de seguir a arquitetura definida, seja 
no JS, no Perl ou no Java.
Espero que não tenha entendido que eu sugeri isso: 'fazer na mão' ... na 
verdade eu estava falando sobre saber o que está fazendo.


Inclusive, vai me desculpar, mas gerar componentes e com views 
explícitos, é 'fazer na mão', uma vez que você tem isso bem abstraído e 
com APIs e docs bem ricas e maduras como no EXT, DHTMLX, Dojo, Qooxdoo 
... ai nesse quesito, angular, backbone e coisas afins, estão bem mais 
perto de 'fazer  na mão' ... Se preocupar com HTML e css, hoje, pra mim, 
é fazer na mão.


Abraços

--
Eduardo Almeida - Software Engineer
edua...@web2solutions.com.br - 27.99831.8663

*WEB2 Solutions* - Inovando, sempre!
=begin disclaimer
   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
 SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
 L
=end disclaimer

Re: [SP-pm] https://github.com/TJRest

2015-10-31 Por tôpico Leonardo Ruoso 
Em 30 de outubro de 2015 22:52, Eduardo Almeida <
edua...@web2solutions.com.br> escreveu:

> Em 10/30/15 22:32, Hernan Lopes escreveu:
>
> Entra lá no canal do angular na freenode... irc.freenode.org #angularjs e
> pergunta: "Vou investir em um app de verdade, devo usar angular 2 ou 1.4.7?"
>
> Não fiz a pergunta, mas acho que só pelo fato de que a ES6 ainda ta longe
> de ser padrão em browsers ,a resposta fica clara ... a nao ser que o
> desenvolvedor não esteja se importando pelo preço de 'transpilar' o codigo
> ...
>

Não creio que o preço de tradução de código seja realmente uma questão para
grande parte dos desenvolvedores, quer estejam usando Dart, TypeScript ou
CofeeScript. Nem para quem está usando Jade, nem para quem está usando
SAAS/LESS.

TypeScript caminha para se tornar vencedor nessa disputa, uma grande
contribuição da Microsoft.

Eu penso que faz sentido iniciar um projeto OpenSource com Angular 2 agora,
assim como faria sentido iniciar com Perl 6, pensando que um MVP fique
pronto entre 9 e 12 meses, tempo em que todas essas tecnologias estejam bem
maduras.

Há também suporte para adicionar a sintaxe do Angular 2 no AngularJS.



> --
> Eduardo Almeida - Software Engineer
> edua...@web2solutions.com.br - 27.99831.8663
>
> *WEB2 Solutions* - Inovando, sempre!
>
> =begin disclaimer
>Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
>  L
> =end disclaimer
>
>


-- 
Leonardo Ruoso
Journalist, Perl developer and business consultant
Media, UFC/2006; Telecom, IFCE/1998
=begin disclaimer
   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
 SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
 L
=end disclaimer

Re: [SP-pm] https://github.com/TJRest

2015-10-31 Por tôpico Leonardo Ruoso 
Mas, acho que pensando ben, vale a pena contemporizar. Vamos abrir um
repositório para Angular 1, com TypeScript, e vamos ir com calma no 2, mas
como um sandbox para estudar os novos conceitos.

No 1.4 vamos por mais carga de trabalho agora, para termos o scafolding do
projeto em poucas semanas.

O importante é lutarmos contra código procedural e contra informação
out-of-band, que são dois vírus muito comuns por essas bandas e que violam
a arquitetura proposta.

Em sáb, 31 de out de 2015 08:23, Leonardo Ruoso 
escreveu:

> Em 30 de outubro de 2015 22:52, Eduardo Almeida <
> edua...@web2solutions.com.br> escreveu:
>
>> Em 10/30/15 22:32, Hernan Lopes escreveu:
>>
>> Entra lá no canal do angular na freenode... irc.freenode.org #angularjs
>> e pergunta: "Vou investir em um app de verdade, devo usar angular 2 ou
>> 1.4.7?"
>>
>> Não fiz a pergunta, mas acho que só pelo fato de que a ES6 ainda ta longe
>> de ser padrão em browsers ,a resposta fica clara ... a nao ser que o
>> desenvolvedor não esteja se importando pelo preço de 'transpilar' o codigo
>> ...
>>
>
> Não creio que o preço de tradução de código seja realmente uma questão
> para grande parte dos desenvolvedores, quer estejam usando Dart, TypeScript
> ou CofeeScript. Nem para quem está usando Jade, nem para quem está usando
> SAAS/LESS.
>
> TypeScript caminha para se tornar vencedor nessa disputa, uma grande
> contribuição da Microsoft.
>
> Eu penso que faz sentido iniciar um projeto OpenSource com Angular 2
> agora, assim como faria sentido iniciar com Perl 6, pensando que um MVP
> fique pronto entre 9 e 12 meses, tempo em que todas essas tecnologias
> estejam bem maduras.
>
> Há também suporte para adicionar a sintaxe do Angular 2 no AngularJS.
>
>
>
>> --
>> Eduardo Almeida - Software Engineer
>> edua...@web2solutions.com.br - 27.99831.8663
>>
>> *WEB2 Solutions* - Inovando, sempre!
>>
>> =begin disclaimer
>>Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>  SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
>>  L
>> =end disclaimer
>>
>>
> --
> Leonardo Ruoso
> Journalist, Perl developer and business consultant
> Media, UFC/2006; Telecom, IFCE/1998
>
=begin disclaimer
   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
 SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
 L
=end disclaimer

Re: [SP-pm] https://github.com/TJRest

2015-10-31 Por tôpico Leonardo Ruoso 
Em 30 de outubro de 2015 20:09, Geovanny Junio :: eutsiv <
geova...@eutsiv.com> escreveu:

> Você tem bons links para indicar sobre Rest?
>
http://www.slideshare.net/LeonardoRuoso/resttcs


> Pois eu já li muita coisa, mas toda vez que você fala sobre Rest eu sinto
> que estou por fora de algo.
>
> Cheers,
> On Oct 30, 2015 19:45, "Leonardo Ruoso"  wrote:
>
>> Apenas para deixar explícito, eu não tenho vagas de Perl neste momento
>> (apesar de ter passado o último ano trabalhando intensamente com Perl 5),
>> mas temos algumas vagas para analistas de requerimentos, especificação
>> (arquiteto de aplicação) e analista de testes funcionais para o Rio de
>> Janeiro. E vagas para Angular 2 e Spring Data Rest em São Paulo, em
>> diferentes níveis de proficiência.
>>
>> Trabalhar comigo pode não ser um dos desafios mais triviais, mas a pessoa
>> certamente sai do projeto bem diferente do que entrou :p
>>
>> A experiência prévia em Java ou Javascript é menos importante que a
>> competência demonstrada em aprender coisas novas, pois de uma forma geral
>> tem sido ainda bem difícil encontrar no Brasil profissionais experientes
>> que já tenham trabalhado com Rest --excessão para uma ou outra empresa
>> forte específica. Fora a questão já é diferente, Rest é hoje um lugar comum
>> em EAI. Espero ver isso mudar em breve :)
>>
>>
>> Em 30 de outubro de 2015 14:35, Leonardo Ruoso 
>> escreveu:
>>
>>> Galera,
>>>
>>> Estou iniciando um PoC de Rest, quem quiser se juntar, tem espaço para
>>> todos os gostos de profissionais: requerimentos, testes, arquitetura de
>>> aplicação, backend e frontend.
>>>
>>> Atualmente estamos iniciando um serviço baseado no Spring Data Rest, mas
>>> ficaria muito feliz se alguém se juntasse com algo baseado em Perl 6 ou
>>> Moose/Catalyst. O Spring Data Rest integra-se diretamente aos POJO's com
>>> anotação JPA, extendendo-os.
>>>
>>> O PoC em si é um GUI Rest para o TaskJuggler, ou seja, o domínio de
>>> negócios já está bem definido e não precisa de complicação alguma.
>>>
>>> O RIA (Rich Internet Application) será implementado em Angular 2,
>>> totalmente baseado em componentes. Vamos testar algumas bibliotecas de
>>> Hateoas.
>>>
>>> Mesmo que possamos ter mais de um serviço, a interface Rest será
>>> necessariamente JSON-HAL com ALPS, que é o padrão adotado pelo Spring Data
>>> Rest.
>>>
>>> Disclaimer:
>>>
>>> Eu devo estar contratando uma equipe razoável de profissionais no Rio e
>>> São Paulo para trabalhar em um outro projeto, que vai implementar o mesmo
>>> stack desse projeto, mas em um domínio completamente diferente. Esse
>>> projeto será totalmente GPL v2.
>>>
>>> --
>>> Leonardo Ruoso
>>> Journalist, Perl developer and business consultant
>>> Media, UFC/2006; Telecom, IFCE/1998
>>>
>>
>>
>>
>> --
>> Leonardo Ruoso
>> Journalist, Perl developer and business consultant
>> Media, UFC/2006; Telecom, IFCE/1998
>>
>> =begin disclaimer
>>Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>  SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
>>  L
>> =end disclaimer
>>
>>
> =begin disclaimer
>Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
>  L
> =end disclaimer
>
>


-- 
Leonardo Ruoso
Journalist, Perl developer and business consultant
Media, UFC/2006; Telecom, IFCE/1998
=begin disclaimer
   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
 SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
 L
=end disclaimer

Re: [SP-pm] https://github.com/TJRest

2015-10-31 Por tôpico Leonardo Ruoso 
Em 30 de outubro de 2015 23:19, Geovanny Junio :: eutsiv <
geova...@eutsiv.com> escreveu:

> Eu já li a especificação e as referências bem recomendadas, mas quando o
> Ruoso especificamente fala de Rest eu fico achando que estou perdendo algo.
>

Isso vai ser difícil de eu responder se você não elaborar.



> Estou dizendo isso pois em outras threads ele deu muita ênfase nessa coisa
> de poucas pessoas saberem Rest, e depois de ler tudo também concordo.
>

Tá, então estamos empatados. Nem acho que precisa ler tudo. Eu fiz um
resumo bem compacto numa apresentação de 1h30 mais ou menos.


> Eu só fiquei meio no loop me questionando se eu entendi tudo ou não, mas
> de toda maneira se o Ruoso tiver material a indicar, ou tiver algum post
> próprio ia ser legal, pois aparentemente ele está com autoridade para falar
> sobre.
>

Não acho que ninguém tenha uma solução concreta para tudo.

De fato, quando se opta por suportar ou privilegiar JSON, todo mundo tem
muita coisa concreta para definir. Em XML as coisas já são bem mais maduras
e mais bem definidas.

Tenho encontrado bastante gente enfatizando a importância de usar Rest
corretamente. Recentemente fui sabatinado por uma equipe de Enterprise
Architects americanos e eles enfatizaram todos esse pontos que eu tenho
enfatizado na sabatina. Mesma coisa quando há meses atrás eu fui sabatinado
por um pessoal europeu --coisas de trabalhar com arquitetura em empresas
globais: o pessoal fica "compartilhando" experiência sobre os projetos que
fizeram com o pessoal que está iniciando novos projetos.


> Cheers,
> --
> Geovanny Junio
> Consultor de Tecnologia
> geovanny (at) eutsiv.com
> +55 31 9422-8885
> www.eutsiv.com
>
> Este e-mail pode conter informação privilegiada e confidencial. Se você
> não é destinatário da
> mensagem, por favor apague a mensagem e comunique-nos o fato de imediato.
>
> This e-mail contains information that may be
> privileged and confidential. If you are not the intended recipient, please
> delete the e-mail and notify us immediately.
>
> 2015-10-30 22:31 GMT-02:00 Eduardo Almeida :
>
>> Em 10/30/15 20:09, Geovanny Junio :: eutsiv escreveu:
>>
>> Você tem bons links para indicar sobre Rest?
>>
>> Acho que essa é a dissertação original que define:
>> https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
>>
>> Pois eu já li muita coisa, mas toda vez que você fala sobre Rest eu sinto
>> que estou por fora de algo.
>>
>> Será que vc não está se perdendo talvez por peculiaridades citadas e
>> relacionadas a ambiente X ou Y? ou seja, padrão de framework X ou Y?
>>
>> Porque a especificação é uma só. Mas a forma de fazer, como no no mundo
>> Perl, poderão ser bem divergentes.
>>
>> Cabe também ressaltar que muito conteúdo relacionado a REST, nem sempre
>> cobre todos os aspectos da especificação em si.
>>
>> Nem sempre todos os serviços REST existente seguem 100% a especificação
>> original ou algum padrão implantado em alguma plataforma/framework/whatever
>>
>> Cheers,
>> On Oct 30, 2015 19:45, "Leonardo Ruoso"  wrote:
>>
>>> Apenas para deixar explícito, eu não tenho vagas de Perl neste momento
>>> (apesar de ter passado o último ano trabalhando intensamente com Perl 5),
>>> mas temos algumas vagas para analistas de requerimentos, especificação
>>> (arquiteto de aplicação) e analista de testes funcionais para o Rio de
>>> Janeiro. E vagas para Angular 2 e Spring Data Rest em São Paulo, em
>>> diferentes níveis de proficiência.
>>>
>>> Trabalhar comigo pode não ser um dos desafios mais triviais, mas a
>>> pessoa certamente sai do projeto bem diferente do que entrou :p
>>>
>>> A experiência prévia em Java ou Javascript é menos importante que a
>>> competência demonstrada em aprender coisas novas, pois de uma forma geral
>>> tem sido ainda bem difícil encontrar no Brasil profissionais experientes
>>> que já tenham trabalhado com Rest --excessão para uma ou outra empresa
>>> forte específica. Fora a questão já é diferente, Rest é hoje um lugar comum
>>> em EAI. Espero ver isso mudar em breve :)
>>>
>>>
>>> Em 30 de outubro de 2015 14:35, Leonardo Ruoso < 
>>> leona...@ruoso.com> escreveu:
>>>
 Galera,

 Estou iniciando um PoC de Rest, quem quiser se juntar, tem espaço para
 todos os gostos de profissionais: requerimentos, testes, arquitetura de
 aplicação, backend e frontend.

 Atualmente estamos iniciando um serviço baseado no Spring Data Rest,
 mas ficaria muito feliz se alguém se juntasse com algo baseado em Perl 6 ou
 Moose/Catalyst. O Spring Data Rest integra-se diretamente aos POJO's com
 anotação JPA, extendendo-os.

 O PoC em si é um GUI Rest para o TaskJuggler, ou seja, o domínio de
 negócios já está bem definido e não precisa de complicação alguma.

 O RIA (Rich Internet Application) será implementado em Angular 2,
 totalmente baseado em componentes. Vamos testar algumas bibliotecas de

Re: [SP-pm] https://github.com/TJRest

2015-10-31 Por tôpico Leonardo Ruoso 
Cê sabe que pode escolher entre ES5 ou ES6 como target, pode até gerar para
os dois e detectar o suporte. Essa questão faz pouco sentido.

Em sáb, 31 de out de 2015 16:47, Eduardo Almeida <
edua...@web2solutions.com.br> escreveu:

Em 10/31/15 08:23, Leonardo Ruoso escreveu:

TypeScript caminha para se tornar vencedor nessa disputa, uma grande
contribuição da Microsoft.


Em qual disputa? qual o melhor superset de ES? porque substituir a ES em si
é dificil eim:)


Eu penso que faz sentido iniciar um projeto OpenSource com Angular 2 agora,
assim como faria sentido iniciar com Perl 6, pensando que um MVP fique
pronto entre 9 e 12 meses, tempo em que todas essas tecnologias estejam bem
maduras.


Sei não  tem muita coisa pra ser feita ainda na ES6


https ://
kangax.github.io
/
compat-table
/es6/


Abraços

-- 
Eduardo Almeida - Software Engineer
edua...@web2solutions.com.br - 27.99831.8663

*WEB2* *Solutions* - Inovando, sempre!
https://mail.google.com/mail/?ui=2=936395505a=0.0.1.1=150bf3a3da5375ca=fimg=150bf3a3da5375ca=w1600-h1000=ANGjdJ825-BRUMEQCLg2HKVhJs0OZ0E6sRtVfkC5SAqf_ADy3UkBr2JokvOGIcPClMZlPKh3Qhpa6yZqxEMJBDyrMyhf4rQ9M3cZ6yiLtfsXTEDNgHe2BHdq0CTpLOk=emb
">

=begin disclaimer
   Sao Paulo Perl Mongers: http:// 
sao-paulo.pm.org/ 
 SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
 Lhttp://mail.pm.org/mailman/listinfo/saopaulo-pm>mail.pm.org
/
mailman
/
listinfo
/
saopaulo-pm
>
=end disclaimer
=begin disclaimer
   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
 SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
 L
=end disclaimer

Re: [SP-pm] https://github.com/TJRest

2015-10-31 Por tôpico Eduardo Almeida 

Em 10/31/15 08:23, Leonardo Ruoso escreveu:
TypeScript caminha para se tornar vencedor nessa disputa, uma grande 
contribuição da Microsoft.
Em qual disputa? qual o melhor superset de ES? porque substituir a ES em 
si é dificil eim:)


Eu penso que faz sentido iniciar um projeto OpenSource com Angular 2 
agora, assim como faria sentido iniciar com Perl 6, pensando que um 
MVP fique pronto entre 9 e 12 meses, tempo em que todas essas 
tecnologias estejam bem maduras.

Sei não  tem muita coisa pra ser feita ainda na ES6

https://kangax.github.io/compat-table/es6/

Abraços

--
Eduardo Almeida - Software Engineer
edua...@web2solutions.com.br - 27.99831.8663

*WEB2 Solutions* - Inovando, sempre!
=begin disclaimer
   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
 SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
 L
=end disclaimer

Re: [SP-pm] https://github.com/TJRest

2015-10-31 Por tôpico Leonardo Ruoso 
Algo curioso, não temos nenhum HAL browser em Perl listado aqui.

HAL é um subset do JSON-Schema (tem até um Schema descrevendo o HAL).

Spring Data Rest optou por implementar JSON-HAL com Alps apesar de haver
uma tendência maior para que json-schema e hyperschema se tornem padrões.

Eventualmente haver um conjunto de Roles Moose para suportar/exportar HAL a
partir da DBIx::Class, como o Spring Data Rest faz com a JPA poderia ser um
projeto interessante.



Em 31 de outubro de 2015 10:28, Leonardo Ruoso 
escreveu:

> Mas, acho que pensando ben, vale a pena contemporizar. Vamos abrir um
> repositório para Angular 1, com TypeScript, e vamos ir com calma no 2, mas
> como um sandbox para estudar os novos conceitos.
>
> No 1.4 vamos por mais carga de trabalho agora, para termos o scafolding do
> projeto em poucas semanas.
>
> O importante é lutarmos contra código procedural e contra informação
> out-of-band, que são dois vírus muito comuns por essas bandas e que violam
> a arquitetura proposta.
>
> Em sáb, 31 de out de 2015 08:23, Leonardo Ruoso 
> escreveu:
>
>> Em 30 de outubro de 2015 22:52, Eduardo Almeida <
>> edua...@web2solutions.com.br> escreveu:
>>
>>> Em 10/30/15 22:32, Hernan Lopes escreveu:
>>>
>>> Entra lá no canal do angular na freenode... irc.freenode.org #angularjs
>>> e pergunta: "Vou investir em um app de verdade, devo usar angular 2 ou
>>> 1.4.7?"
>>>
>>> Não fiz a pergunta, mas acho que só pelo fato de que a ES6 ainda ta
>>> longe de ser padrão em browsers ,a resposta fica clara ... a nao ser que o
>>> desenvolvedor não esteja se importando pelo preço de 'transpilar' o codigo
>>> ...
>>>
>>
>> Não creio que o preço de tradução de código seja realmente uma questão
>> para grande parte dos desenvolvedores, quer estejam usando Dart, TypeScript
>> ou CofeeScript. Nem para quem está usando Jade, nem para quem está usando
>> SAAS/LESS.
>>
>> TypeScript caminha para se tornar vencedor nessa disputa, uma grande
>> contribuição da Microsoft.
>>
>> Eu penso que faz sentido iniciar um projeto OpenSource com Angular 2
>> agora, assim como faria sentido iniciar com Perl 6, pensando que um MVP
>> fique pronto entre 9 e 12 meses, tempo em que todas essas tecnologias
>> estejam bem maduras.
>>
>> Há também suporte para adicionar a sintaxe do Angular 2 no AngularJS.
>>
>>
>>
>>> --
>>> Eduardo Almeida - Software Engineer
>>> edua...@web2solutions.com.br - 27.99831.8663
>>>
>>> *WEB2 Solutions* - Inovando, sempre!
>>>
>>> =begin disclaimer
>>>Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>  SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
>>>  L
>>> =end disclaimer
>>>
>>>
>> --
>> Leonardo Ruoso
>> Journalist, Perl developer and business consultant
>> Media, UFC/2006; Telecom, IFCE/1998
>>
>


-- 
Leonardo Ruoso
Journalist, Perl developer and business consultant
Media, UFC/2006; Telecom, IFCE/1998
=begin disclaimer
   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
 SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
 L
=end disclaimer

Re: [SP-pm] https://github.com/TJRest

2015-10-31 Por tôpico Eduardo Almeida 

Em 10/31/15 08:23, Leonardo Ruoso escreveu:
Não creio que o preço de tradução de código seja realmente uma questão 
para grande parte dos desenvolvedores, quer estejam usando Dart, 
TypeScript ou CofeeScript. Nem para quem está usando Jade, nem para 
quem está usando SAAS/LESS.

Ok, então você vai transpilar com grunt por exemplo, e não no browser ...

Leonardo, deixa eu te perguntar, você ja fez algum experimento desse 
tipo? Ja escreveu alguma app em ES6 ou Typescript?


Se ja, ok, você ja sabe onde está pisando. Te garanto que há "ovos e 
cacos de vidro" por esse caminho.


Sinceramente, se você ta querendo fazer um app séria, na minha humilde 
opnião, há muitos outros aspectos que você deveria dar mais foco, do que 
querer modernizar seu ambiente de desenvolvimento.


Mais uma vez, na minha opnião, ter bons e verdadeiros devs de ES5, é a 
melhor solução (atualmente) frente a qualquer coisa que vc possa me 
apresentar



Abraços

--
Eduardo Almeida - Software Engineer
edua...@web2solutions.com.br - 27.99831.8663

*WEB2 Solutions* - Inovando, sempre!
=begin disclaimer
   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
 SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
 L
=end disclaimer

Re: [SP-pm] https://github.com/TJRest

2015-10-30 Por tôpico Geovanny Junio :: eutsiv 
Vocês estão usando Angular 2 em produção já?

Já experimentaram Mithril JS? É muito leve, usa virtual DOM no estilo React
JS, eu gosto muito da visão que o autor tem da forma de estruturar single
page apps, inclusive ele é brasileiro, mas foi para o Canadá muito cedo,
Leo Horie.
On Oct 30, 2015 19:45, "Leonardo Ruoso"  wrote:

> Apenas para deixar explícito, eu não tenho vagas de Perl neste momento
> (apesar de ter passado o último ano trabalhando intensamente com Perl 5),
> mas temos algumas vagas para analistas de requerimentos, especificação
> (arquiteto de aplicação) e analista de testes funcionais para o Rio de
> Janeiro. E vagas para Angular 2 e Spring Data Rest em São Paulo, em
> diferentes níveis de proficiência.
>
> Trabalhar comigo pode não ser um dos desafios mais triviais, mas a pessoa
> certamente sai do projeto bem diferente do que entrou :p
>
> A experiência prévia em Java ou Javascript é menos importante que a
> competência demonstrada em aprender coisas novas, pois de uma forma geral
> tem sido ainda bem difícil encontrar no Brasil profissionais experientes
> que já tenham trabalhado com Rest --excessão para uma ou outra empresa
> forte específica. Fora a questão já é diferente, Rest é hoje um lugar comum
> em EAI. Espero ver isso mudar em breve :)
>
>
> Em 30 de outubro de 2015 14:35, Leonardo Ruoso 
> escreveu:
>
>> Galera,
>>
>> Estou iniciando um PoC de Rest, quem quiser se juntar, tem espaço para
>> todos os gostos de profissionais: requerimentos, testes, arquitetura de
>> aplicação, backend e frontend.
>>
>> Atualmente estamos iniciando um serviço baseado no Spring Data Rest, mas
>> ficaria muito feliz se alguém se juntasse com algo baseado em Perl 6 ou
>> Moose/Catalyst. O Spring Data Rest integra-se diretamente aos POJO's com
>> anotação JPA, extendendo-os.
>>
>> O PoC em si é um GUI Rest para o TaskJuggler, ou seja, o domínio de
>> negócios já está bem definido e não precisa de complicação alguma.
>>
>> O RIA (Rich Internet Application) será implementado em Angular 2,
>> totalmente baseado em componentes. Vamos testar algumas bibliotecas de
>> Hateoas.
>>
>> Mesmo que possamos ter mais de um serviço, a interface Rest será
>> necessariamente JSON-HAL com ALPS, que é o padrão adotado pelo Spring Data
>> Rest.
>>
>> Disclaimer:
>>
>> Eu devo estar contratando uma equipe razoável de profissionais no Rio e
>> São Paulo para trabalhar em um outro projeto, que vai implementar o mesmo
>> stack desse projeto, mas em um domínio completamente diferente. Esse
>> projeto será totalmente GPL v2.
>>
>> --
>> Leonardo Ruoso
>> Journalist, Perl developer and business consultant
>> Media, UFC/2006; Telecom, IFCE/1998
>>
>
>
>
> --
> Leonardo Ruoso
> Journalist, Perl developer and business consultant
> Media, UFC/2006; Telecom, IFCE/1998
>
> =begin disclaimer
>Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
>  L
> =end disclaimer
>
>
=begin disclaimer
   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
 SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
 L
=end disclaimer

Re: [SP-pm] https://github.com/TJRest

2015-10-30 Por tôpico Geovanny Junio :: eutsiv 
Você tem bons links para indicar sobre Rest? Pois eu já li muita coisa, mas
toda vez que você fala sobre Rest eu sinto que estou por fora de algo.

Cheers,
On Oct 30, 2015 19:45, "Leonardo Ruoso"  wrote:

> Apenas para deixar explícito, eu não tenho vagas de Perl neste momento
> (apesar de ter passado o último ano trabalhando intensamente com Perl 5),
> mas temos algumas vagas para analistas de requerimentos, especificação
> (arquiteto de aplicação) e analista de testes funcionais para o Rio de
> Janeiro. E vagas para Angular 2 e Spring Data Rest em São Paulo, em
> diferentes níveis de proficiência.
>
> Trabalhar comigo pode não ser um dos desafios mais triviais, mas a pessoa
> certamente sai do projeto bem diferente do que entrou :p
>
> A experiência prévia em Java ou Javascript é menos importante que a
> competência demonstrada em aprender coisas novas, pois de uma forma geral
> tem sido ainda bem difícil encontrar no Brasil profissionais experientes
> que já tenham trabalhado com Rest --excessão para uma ou outra empresa
> forte específica. Fora a questão já é diferente, Rest é hoje um lugar comum
> em EAI. Espero ver isso mudar em breve :)
>
>
> Em 30 de outubro de 2015 14:35, Leonardo Ruoso 
> escreveu:
>
>> Galera,
>>
>> Estou iniciando um PoC de Rest, quem quiser se juntar, tem espaço para
>> todos os gostos de profissionais: requerimentos, testes, arquitetura de
>> aplicação, backend e frontend.
>>
>> Atualmente estamos iniciando um serviço baseado no Spring Data Rest, mas
>> ficaria muito feliz se alguém se juntasse com algo baseado em Perl 6 ou
>> Moose/Catalyst. O Spring Data Rest integra-se diretamente aos POJO's com
>> anotação JPA, extendendo-os.
>>
>> O PoC em si é um GUI Rest para o TaskJuggler, ou seja, o domínio de
>> negócios já está bem definido e não precisa de complicação alguma.
>>
>> O RIA (Rich Internet Application) será implementado em Angular 2,
>> totalmente baseado em componentes. Vamos testar algumas bibliotecas de
>> Hateoas.
>>
>> Mesmo que possamos ter mais de um serviço, a interface Rest será
>> necessariamente JSON-HAL com ALPS, que é o padrão adotado pelo Spring Data
>> Rest.
>>
>> Disclaimer:
>>
>> Eu devo estar contratando uma equipe razoável de profissionais no Rio e
>> São Paulo para trabalhar em um outro projeto, que vai implementar o mesmo
>> stack desse projeto, mas em um domínio completamente diferente. Esse
>> projeto será totalmente GPL v2.
>>
>> --
>> Leonardo Ruoso
>> Journalist, Perl developer and business consultant
>> Media, UFC/2006; Telecom, IFCE/1998
>>
>
>
>
> --
> Leonardo Ruoso
> Journalist, Perl developer and business consultant
> Media, UFC/2006; Telecom, IFCE/1998
>
> =begin disclaimer
>Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
>  L
> =end disclaimer
>
>
=begin disclaimer
   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
 SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
 L
=end disclaimer

Re: [SP-pm] https://github.com/TJRest

2015-10-30 Por tôpico Leonardo Ruoso 
Apenas para deixar explícito, eu não tenho vagas de Perl neste momento
(apesar de ter passado o último ano trabalhando intensamente com Perl 5),
mas temos algumas vagas para analistas de requerimentos, especificação
(arquiteto de aplicação) e analista de testes funcionais para o Rio de
Janeiro. E vagas para Angular 2 e Spring Data Rest em São Paulo, em
diferentes níveis de proficiência.

Trabalhar comigo pode não ser um dos desafios mais triviais, mas a pessoa
certamente sai do projeto bem diferente do que entrou :p

A experiência prévia em Java ou Javascript é menos importante que a
competência demonstrada em aprender coisas novas, pois de uma forma geral
tem sido ainda bem difícil encontrar no Brasil profissionais experientes
que já tenham trabalhado com Rest --excessão para uma ou outra empresa
forte específica. Fora a questão já é diferente, Rest é hoje um lugar comum
em EAI. Espero ver isso mudar em breve :)


Em 30 de outubro de 2015 14:35, Leonardo Ruoso 
escreveu:

> Galera,
>
> Estou iniciando um PoC de Rest, quem quiser se juntar, tem espaço para
> todos os gostos de profissionais: requerimentos, testes, arquitetura de
> aplicação, backend e frontend.
>
> Atualmente estamos iniciando um serviço baseado no Spring Data Rest, mas
> ficaria muito feliz se alguém se juntasse com algo baseado em Perl 6 ou
> Moose/Catalyst. O Spring Data Rest integra-se diretamente aos POJO's com
> anotação JPA, extendendo-os.
>
> O PoC em si é um GUI Rest para o TaskJuggler, ou seja, o domínio de
> negócios já está bem definido e não precisa de complicação alguma.
>
> O RIA (Rich Internet Application) será implementado em Angular 2,
> totalmente baseado em componentes. Vamos testar algumas bibliotecas de
> Hateoas.
>
> Mesmo que possamos ter mais de um serviço, a interface Rest será
> necessariamente JSON-HAL com ALPS, que é o padrão adotado pelo Spring Data
> Rest.
>
> Disclaimer:
>
> Eu devo estar contratando uma equipe razoável de profissionais no Rio e
> São Paulo para trabalhar em um outro projeto, que vai implementar o mesmo
> stack desse projeto, mas em um domínio completamente diferente. Esse
> projeto será totalmente GPL v2.
>
> --
> Leonardo Ruoso
> Journalist, Perl developer and business consultant
> Media, UFC/2006; Telecom, IFCE/1998
>



-- 
Leonardo Ruoso
Journalist, Perl developer and business consultant
Media, UFC/2006; Telecom, IFCE/1998
=begin disclaimer
   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
 SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
 L
=end disclaimer

Re: [SP-pm] https://github.com/TJRest

2015-10-30 Por tôpico Eduardo Almeida 

Em 10/30/15 20:05, Geovanny Junio :: eutsiv escreveu:


Vocês estão usando Angular 2 em produção já?

Já experimentaram Mithril JS?

Olhando o sample code em https://lhorie.github.io/mithril/, mais fica 
claro que conhecer bem js patterns e o vanilla puro elimina toda essa 
parafernalha ... performance então ... nem se compara


meus cents

--
Eduardo Almeida - Software Engineer
edua...@web2solutions.com.br - 27.99831.8663

*WEB2 Solutions* - Inovando, sempre!
=begin disclaimer
   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
 SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
 L
=end disclaimer

Re: [SP-pm] https://github.com/TJRest

2015-10-30 Por tôpico Geovanny Junio :: eutsiv 
Eu já li a especificação e as referências bem recomendadas, mas quando o
Ruoso especificamente fala de Rest eu fico achando que estou perdendo algo.

Estou dizendo isso pois em outras threads ele deu muita ênfase nessa coisa
de poucas pessoas saberem Rest, e depois de ler tudo também concordo. Eu só
fiquei meio no loop me questionando se eu entendi tudo ou não, mas de toda
maneira se o Ruoso tiver material a indicar, ou tiver algum post próprio ia
ser legal, pois aparentemente ele está com autoridade para falar sobre.

Cheers,
--
Geovanny Junio
Consultor de Tecnologia
geovanny (at) eutsiv.com
+55 31 9422-8885
www.eutsiv.com

Este e-mail pode conter informação privilegiada e confidencial. Se você não
é destinatário da
mensagem, por favor apague a mensagem e comunique-nos o fato de imediato.

This e-mail contains information that may be
privileged and confidential. If you are not the intended recipient, please
delete the e-mail and notify us immediately.

2015-10-30 22:31 GMT-02:00 Eduardo Almeida :

> Em 10/30/15 20:09, Geovanny Junio :: eutsiv escreveu:
>
> Você tem bons links para indicar sobre Rest?
>
> Acho que essa é a dissertação original que define:
> https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
>
> Pois eu já li muita coisa, mas toda vez que você fala sobre Rest eu sinto
> que estou por fora de algo.
>
> Será que vc não está se perdendo talvez por peculiaridades citadas e
> relacionadas a ambiente X ou Y? ou seja, padrão de framework X ou Y?
>
> Porque a especificação é uma só. Mas a forma de fazer, como no no mundo
> Perl, poderão ser bem divergentes.
>
> Cabe também ressaltar que muito conteúdo relacionado a REST, nem sempre
> cobre todos os aspectos da especificação em si.
>
> Nem sempre todos os serviços REST existente seguem 100% a especificação
> original ou algum padrão implantado em alguma plataforma/framework/whatever
>
> Cheers,
> On Oct 30, 2015 19:45, "Leonardo Ruoso"  wrote:
>
>> Apenas para deixar explícito, eu não tenho vagas de Perl neste momento
>> (apesar de ter passado o último ano trabalhando intensamente com Perl 5),
>> mas temos algumas vagas para analistas de requerimentos, especificação
>> (arquiteto de aplicação) e analista de testes funcionais para o Rio de
>> Janeiro. E vagas para Angular 2 e Spring Data Rest em São Paulo, em
>> diferentes níveis de proficiência.
>>
>> Trabalhar comigo pode não ser um dos desafios mais triviais, mas a pessoa
>> certamente sai do projeto bem diferente do que entrou :p
>>
>> A experiência prévia em Java ou Javascript é menos importante que a
>> competência demonstrada em aprender coisas novas, pois de uma forma geral
>> tem sido ainda bem difícil encontrar no Brasil profissionais experientes
>> que já tenham trabalhado com Rest --excessão para uma ou outra empresa
>> forte específica. Fora a questão já é diferente, Rest é hoje um lugar comum
>> em EAI. Espero ver isso mudar em breve :)
>>
>>
>> Em 30 de outubro de 2015 14:35, Leonardo Ruoso < 
>> leona...@ruoso.com> escreveu:
>>
>>> Galera,
>>>
>>> Estou iniciando um PoC de Rest, quem quiser se juntar, tem espaço para
>>> todos os gostos de profissionais: requerimentos, testes, arquitetura de
>>> aplicação, backend e frontend.
>>>
>>> Atualmente estamos iniciando um serviço baseado no Spring Data Rest, mas
>>> ficaria muito feliz se alguém se juntasse com algo baseado em Perl 6 ou
>>> Moose/Catalyst. O Spring Data Rest integra-se diretamente aos POJO's com
>>> anotação JPA, extendendo-os.
>>>
>>> O PoC em si é um GUI Rest para o TaskJuggler, ou seja, o domínio de
>>> negócios já está bem definido e não precisa de complicação alguma.
>>>
>>> O RIA (Rich Internet Application) será implementado em Angular 2,
>>> totalmente baseado em componentes. Vamos testar algumas bibliotecas de
>>> Hateoas.
>>>
>>> Mesmo que possamos ter mais de um serviço, a interface Rest será
>>> necessariamente JSON-HAL com ALPS, que é o padrão adotado pelo Spring Data
>>> Rest.
>>>
>>> Disclaimer:
>>>
>>> Eu devo estar contratando uma equipe razoável de profissionais no Rio e
>>> São Paulo para trabalhar em um outro projeto, que vai implementar o mesmo
>>> stack desse projeto, mas em um domínio completamente diferente. Esse
>>> projeto será totalmente GPL v2.
>>>
>>> --
>>> Leonardo Ruoso
>>> Journalist, Perl developer and business consultant
>>> Media, UFC/2006; Telecom, IFCE/1998
>>>
>>
>>
>>
>> --
>> Leonardo Ruoso
>> Journalist, Perl developer and business consultant
>> Media, UFC/2006; Telecom, IFCE/1998
>>
>> =begin disclaimer
>>Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>  SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
>>  L
>> =end disclaimer
>>
>>
>
> =begin disclaimer
>Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
>  L 
>

Re: [SP-pm] https://github.com/TJRest

2015-10-30 Por tôpico Eduardo Almeida 

Em 10/30/15 22:32, Hernan Lopes escreveu:
Entra lá no canal do angular na freenode... irc.freenode.org 
 #angularjs e pergunta: "Vou investir em um 
app de verdade, devo usar angular 2 ou 1.4.7?"
Não fiz a pergunta, mas acho que só pelo fato de que a ES6 ainda ta 
longe de ser padrão em browsers ,a resposta fica clara ... a nao ser que 
o desenvolvedor não esteja se importando pelo preço de 'transpilar' o 
codigo ...


--
Eduardo Almeida - Software Engineer
edua...@web2solutions.com.br - 27.99831.8663

*WEB2 Solutions* - Inovando, sempre!
=begin disclaimer
   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
 SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
 L
=end disclaimer

Re: [SP-pm] https://github.com/TJRest

2015-10-30 Por tôpico Eduardo Almeida 

Em 10/30/15 22:31, Eduardo Almeida escreveu:




Acho que essa é a dissertação original que define:
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

--
Eduardo Almeida - Software Engineer
edua...@web2solutions.com.br - 27.99831.8663

*WEB2 Solutions* - Inovando, sempre!
=begin disclaimer
   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
 SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
 L
=end disclaimer

Re: [SP-pm] https://github.com/TJRest

2015-10-30 Por tôpico Eduardo Almeida 

Em 10/30/15 20:09, Geovanny Junio :: eutsiv escreveu:


Você tem bons links para indicar sobre Rest?


Acho que essa é a dissertação original que define:
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm


Pois eu já li muita coisa, mas toda vez que você fala sobre Rest eu 
sinto que estou por fora de algo.


Será que vc não está se perdendo talvez por peculiaridades citadas e 
relacionadas a ambiente X ou Y? ou seja, padrão de framework X ou Y?


Porque a especificação é uma só. Mas a forma de fazer, como no no mundo 
Perl, poderão ser bem divergentes.


Cabe também ressaltar que muito conteúdo relacionado a REST, nem sempre 
cobre todos os aspectos da especificação em si.


Nem sempre todos os serviços REST existente seguem 100% a especificação 
original ou algum padrão implantado em alguma plataforma/framework/whatever


Cheers,

On Oct 30, 2015 19:45, "Leonardo Ruoso" > wrote:


Apenas para deixar explícito, eu não tenho vagas de Perl neste
momento (apesar de ter passado o último ano trabalhando
intensamente com Perl 5), mas temos algumas vagas para analistas
de requerimentos, especificação (arquiteto de aplicação) e
analista de testes funcionais para o Rio de Janeiro. E vagas para
Angular 2 e Spring Data Rest em São Paulo, em diferentes níveis de
proficiência.

Trabalhar comigo pode não ser um dos desafios mais triviais, mas a
pessoa certamente sai do projeto bem diferente do que entrou :p

A experiência prévia em Java ou Javascript é menos importante que
a competência demonstrada em aprender coisas novas, pois de uma
forma geral tem sido ainda bem difícil encontrar no Brasil
profissionais experientes que já tenham trabalhado com Rest
--excessão para uma ou outra empresa forte específica. Fora a
questão já é diferente, Rest é hoje um lugar comum em EAI. Espero
ver isso mudar em breve :)

Em 30 de outubro de 2015 14:35, Leonardo Ruoso > escreveu:

Galera,

Estou iniciando um PoC de Rest, quem quiser se juntar, tem
espaço para todos os gostos de profissionais: requerimentos,
testes, arquitetura de aplicação, backend e frontend.

Atualmente estamos iniciando um serviço baseado no Spring Data
Rest, mas ficaria muito feliz se alguém se juntasse com algo
baseado em Perl 6 ou Moose/Catalyst. O Spring Data Rest
integra-se diretamente aos POJO's com anotação JPA,
extendendo-os.

O PoC em si é um GUI Rest para o TaskJuggler, ou seja, o
domínio de negócios já está bem definido e não precisa de
complicação alguma.

O RIA (Rich Internet Application) será implementado em Angular
2, totalmente baseado em componentes. Vamos testar algumas
bibliotecas de Hateoas.

Mesmo que possamos ter mais de um serviço, a interface Rest
será necessariamente JSON-HAL com ALPS, que é o padrão adotado
pelo Spring Data Rest.

Disclaimer:

Eu devo estar contratando uma equipe razoável de profissionais
no Rio e São Paulo para trabalhar em um outro projeto, que vai
implementar o mesmo stack desse projeto, mas em um domínio
completamente diferente. Esse projeto será totalmente GPL v2.

-- 
Leonardo Ruoso

Journalist, Perl developer and business consultant
Media, UFC/2006; Telecom, IFCE/1998




-- 
Leonardo Ruoso

Journalist, Perl developer and business consultant
Media, UFC/2006; Telecom, IFCE/1998

=begin disclaimer
   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
 SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org

 L
=end disclaimer



=begin disclaimer
Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
  SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
  L
=end disclaimer



--
Eduardo Almeida - Software Engineer
edua...@web2solutions.com.br - 27.99831.8663

*WEB2 Solutions* - Inovando, sempre!
=begin disclaimer
   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
 SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
 L
=end disclaimer

Re: [SP-pm] https://github.com/TJRest

2015-10-30 Por tôpico Hernan Lopes 
Entra lá no canal do angular na freenode... irc.freenode.org #angularjs e
pergunta: "Vou investir em um app de verdade, devo usar angular 2 ou 1.4.7?"

2015-10-30 20:09 GMT-02:00 Geovanny Junio :: eutsiv :

> Você tem bons links para indicar sobre Rest? Pois eu já li muita coisa,
> mas toda vez que você fala sobre Rest eu sinto que estou por fora de algo.
>
> Cheers,
> On Oct 30, 2015 19:45, "Leonardo Ruoso"  wrote:
>
>> Apenas para deixar explícito, eu não tenho vagas de Perl neste momento
>> (apesar de ter passado o último ano trabalhando intensamente com Perl 5),
>> mas temos algumas vagas para analistas de requerimentos, especificação
>> (arquiteto de aplicação) e analista de testes funcionais para o Rio de
>> Janeiro. E vagas para Angular 2 e Spring Data Rest em São Paulo, em
>> diferentes níveis de proficiência.
>>
>> Trabalhar comigo pode não ser um dos desafios mais triviais, mas a pessoa
>> certamente sai do projeto bem diferente do que entrou :p
>>
>> A experiência prévia em Java ou Javascript é menos importante que a
>> competência demonstrada em aprender coisas novas, pois de uma forma geral
>> tem sido ainda bem difícil encontrar no Brasil profissionais experientes
>> que já tenham trabalhado com Rest --excessão para uma ou outra empresa
>> forte específica. Fora a questão já é diferente, Rest é hoje um lugar comum
>> em EAI. Espero ver isso mudar em breve :)
>>
>>
>> Em 30 de outubro de 2015 14:35, Leonardo Ruoso 
>> escreveu:
>>
>>> Galera,
>>>
>>> Estou iniciando um PoC de Rest, quem quiser se juntar, tem espaço para
>>> todos os gostos de profissionais: requerimentos, testes, arquitetura de
>>> aplicação, backend e frontend.
>>>
>>> Atualmente estamos iniciando um serviço baseado no Spring Data Rest, mas
>>> ficaria muito feliz se alguém se juntasse com algo baseado em Perl 6 ou
>>> Moose/Catalyst. O Spring Data Rest integra-se diretamente aos POJO's com
>>> anotação JPA, extendendo-os.
>>>
>>> O PoC em si é um GUI Rest para o TaskJuggler, ou seja, o domínio de
>>> negócios já está bem definido e não precisa de complicação alguma.
>>>
>>> O RIA (Rich Internet Application) será implementado em Angular 2,
>>> totalmente baseado em componentes. Vamos testar algumas bibliotecas de
>>> Hateoas.
>>>
>>> Mesmo que possamos ter mais de um serviço, a interface Rest será
>>> necessariamente JSON-HAL com ALPS, que é o padrão adotado pelo Spring Data
>>> Rest.
>>>
>>> Disclaimer:
>>>
>>> Eu devo estar contratando uma equipe razoável de profissionais no Rio e
>>> São Paulo para trabalhar em um outro projeto, que vai implementar o mesmo
>>> stack desse projeto, mas em um domínio completamente diferente. Esse
>>> projeto será totalmente GPL v2.
>>>
>>> --
>>> Leonardo Ruoso
>>> Journalist, Perl developer and business consultant
>>> Media, UFC/2006; Telecom, IFCE/1998
>>>
>>
>>
>>
>> --
>> Leonardo Ruoso
>> Journalist, Perl developer and business consultant
>> Media, UFC/2006; Telecom, IFCE/1998
>>
>> =begin disclaimer
>>Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>  SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
>>  L
>> =end disclaimer
>>
>>
> =begin disclaimer
>Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
>  L
> =end disclaimer
>
>
=begin disclaimer
   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
 SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
 L
=end disclaimer