"
Apoiado por

Afinal a podridão é nobre

Durante anos queixei-me por o ambiente de desenvolvimento do SAP ser tão retrógrado e antiquado e por demorar tanto tempo a evoluir Sempre que mo ouvia dizer, um amigo meu avisava-me sabiamente: “não mordas a mão que te dá de comer”.

Mas como pode um homem ficar calado?

É exasperante trabalhar 8 horas por dia naquela coisa arcaica a que chamam ABAP Workbench depois de ter experimentado IDEs modernos como o XCode ou o Eclipse. Quando a SAP decide finalmente introduzir alguma nova funcionalidade ao IDE (como permitir completar automaticamente as palavras com base no contexto por exemplo) só quem nunca trabalhou no XCode, Eclipse ou VisualStudio é que, feliz ignorância, pode ficar contente. Porque os outros, que sabem bem que estas coisas são banais noutros IDEs desde o século XX, esses só largar um breve suspiro de alívio e continuar a tentar ignorar tudo o resto que lá falta.

No entanto o primeiro prémio vai para o descontrolo do controlo de versões do ABAP. Como é possível que, nos dias que correm, a gestão de versões seja ainda orientada ao ficheiro? Se uma classe é sempre constituída por vários ficheiros, é practicamente impossível não fazer asneira ao tentar recuar a versões anteriores de uma classe, pois a versão de cada um dos inúmeros ficheiros tem de ser gerida independentemente. Para não falar na trabalheira que dá. Fora do mundo SAP os sistemas de gestão de versões têm evoluido tanto que o Subversion, um sistema até há pouco tempo considerado sofisticado, é já considerado obsoleto desde que apareceram os sistemas descentralizados como o GIT. Eu venero o GIT. Mas até largaria um sorriso de alegria se o SAP disponibilizasse algo parecido com o Subversion. Só que nem isso.

Quem for à vinha e olhar para as uvas já vê que estão podres.

E de repente… em 2015… a SAP surpreendeu-me. Porque compreendi que afinal nos últimos anos ela tem andado a fazer a apanha (tardia, mas cuidada) de toda esta uva (podre, mas doce) e está agora a lançar uma série de vinhos late harvest excepcionais. E em vez de continuar a tentar fazer evoluir um IDE retrógrado e moribundo, largou tudo e começou do zero.

Já há uns tempos que ouvia falar em HANA e Fiori e SAPUI5 mas ainda não tinha entendido como é que iriam ser adoptados. Só em 2015, em boa parte graças aos cursos da OpenSAP, é que comecei a ver as peças a encaixar.

O curso In-Memory Data Management In a Nutshell permite ter uma ideia clara da revolução tecnológica que o HANA traz em relação às bases de dados relacionais hoje em uso.

O curso Developing Mobile Apps with SAP HANA Cloud Platform permite meter as mãos na massa e experimentar o lado mais UI das novas aplicações feitas em Fiori e SAPUI5.

Os cursos SAP S/4HANA in a Nutshell e SAP S/4HANA – Use Cases explicam como os super-poderes do HANA estão já a ser usados para implementar a nova infra-estrutura aplicacional que vai substituir o R/3.

Depois de tanta crítica, deixo aqui o elogio:
Mas que belo puzzle. Estou ansioso por começar a montá-lo.

A SAP andou distraída e a definhar durante uma série de anos. Mas reparou a tempo, reinventou-se e agora acelera em direcção ao futuro. Amigo, se também andas distraído e a definhar, segue o meu conselho e presta atenção ao que se anda a passar à tua volta porque ou reparas agora e começas a correr ou ainda perdes o comboio (ou melhor dizendo, o foguetão).

O Abapinho saúda-vos.

8 comentários a “Afinal a podridão é nobre”

  1. Artur Moreira Diz:

    Viva,

    Gostei imenso da solução disponível no WEB IDE (pode ser utilizado a partir de uma conta trial para programar em HANA):

    http://scn.sap.com/community/developer-center/hana/blog/2014/12/02/sap-hana-sps-09-new-developer-features-sap-hana-web-based-development-workbench

    Cumprimentos
    Artur Moreira

  2. Rui Nunes Diz:

    Olá Nuno,

    É possível utilizar o Eclipse como IDE para ABAP:

    http://scn.sap.com/community/abap/eclipse

    Um abraço,
    Rui

  3. Nuno Godinho Diz:

    Olá Rui, sim eu sei. É também uma óptima evolução. E estou curioso para experimentar. Principalmente para ver se conseguia começar a usar GIT. Infelizmente no projecto onde estou não é possível. No entanto diz quem já tentou que ainda não funciona assim tão bem.

  4. Rui Nunes Diz:

    Olá Nuno, eu fiz algumas experiências com Eclipse ao desenvolver uma aplicação Android há uns 3 anos atrás e também notei que existiam vários problemas. Talvez por isso a Google tenha baseado depois o IDE oficial para desenvolvimento Android no Intellij IDEA.

    De qualquer forma, também estou curioso para experimentar ;)

  5. Carlos Constantino Diz:

    Viva Nuno,

    Gostei de uma forma geral deste artigo de opinião, que é diferente do que costumas colocar por aqui.

    Mas relativamente ao futuro, não tenho ainda certezas de que este tenha sido o caminho correto (pelo menos do que já conheço).

    1. UI5: é baseado em JQwery. Usa HTML5, CSS3 e Javascript. Tudo standards, BOA! No entanto, optaram por colocar toda a renderização no cliente. Um cenário tipico: uma app que recorre a um serviço OData e depois mostra a info. O que acontece? Os dados vêm do serviço e depois é o web client (browser) que corre uma série de scripts para renderizar toda a página. Eu achava preferível que fosse o applicarion server a enviar o máximo de dados já em HMTL (dependendo da máquina onde corre, pode demorar mais ou menos tempo a correr todos os scripts de construção de controlos e a os adicionar à árvore HTML que vai renderizar).

    2. Ambientes de desenvolvimento:
    2.1. Eclipse e seus plugins… Demonstra o desconhecimento dos vários IDEs que existem por aí. O webstorm (inteliJ), embora pago, é de longe superior, e mais leve. Alem de que tem integrado ferramentas de controlo de versões, sejam elas o SVS ou GIT
    2.2. web IDE: para mim tem um defeito enorme: corre no browser. Acabamos por ter um gui, mas que não necessita de instalação… Os scripts são carregados e mantidos em cache. O que por vezes obriga a eliminar essa cache e a reinicializar o web IDE.

    Admito que tudo isto é bastante novo para mim, e não fossem os cursos da Open SAP e algum investimento pessoal, nem esta opinião era capaz de formar…

    Concluindo: acho que o salto para o HTML/CSS/Javascript é a opção correta, mas até ver, parece-me que o paradigma foi o errado.

    Abraços,
    Carlos

  6. Nuno Godinho Diz:

    Oi Carlos, compreendo o teu ponto de vista. Só estou em desacordo com uma coisa: eu sempre acreditei em ser o cliente a fazer o render. Mas são opiniões, claro. Não conheço o webstorm, vou investigar. Também concordo que o webIDE é um bocado limitativo, pelas razões que apresentas e porque trabalhar no browser dá pouca agilidade. Ainda assim é notável que tenham disponibilizado algo grátis tão sofisticado. Além disso eles não obrigam a usares o webIDE, é só uma alternativa que te dão. E bastante conveniente para algumas situações.

    Obrigado e abraço,
    Nuno

  7. Carlos Constantino Diz:

    Nuno,

    Eu não defendo que o rendering não deva ser feito no cliente. DEVE, mas apenas isso. O que acontece neste momento com o UI5 é que o que o servidor envia são scripts e muito pouco HTML.

    Um exemplo do contrário: uma aplicação web desenvolvida em Node.js com o motor de template handlebars, o que acontece é que quando a resposta é enviada pelo aplication server, já vai todo o HTML pronto a ser renderizado (deve levar alguns scripts para que na interacção de inserção ou remoção de linhas de uma tabela por exemplo, não seja necessário recarregar a página toda).

    No Fiori/UI5, o servidor ao enviar scripts, estes são executados. Tipicamente, cria uma view que associa a uma DIV na página. Ao criar essa view (seja XML ou JS) o init da view faz um pedido ao serviço para carregar dados e começa a construir objectos que serão traduzidos em elementos HTML. Na chegada dos dados é executado um script que vai criar cada um dos elementos visuais e adiciona-os à página (tudo através de JQuery).

    Enquanto que no exemplo do Node que dei o browser apenas renderiza, no Fiori são executados vários scripts que criam em memória os elementos HTML que serão depois renderizados.

    “They choose to base it on jQuery and its functional DOM manipulation approach just when the Web was abandoning it” (https://maxfavilli.com/sapui5)

    Se colocares ambas as aplicações (imagina que é apenas uma tabela com linhas) a correr num smartphone com apenas 256Mb de RAM e com pouco poder de processamento, a experiência de utilização é muito pior no caso do UI5…

    Existe outra questão que me lembrei, mas que ainda não estudei: cache e alterações à aplicação. Não sei como se comporta uma app fiori cuja aplicação foi modificada e não se fez no lado do cliente um CTRL+F5… será que os scripts são sempre recarregados? Se não forem, corre-se o risco de não se estar a correr uma app actualizada… (tenho que investigar melhor este tema).

    É por isto que não estou de acordo com a abordagem da SAP. Mas posso estar enganado e mudar de opinião (não era a primeira vez que teria que admitir que estava errado).

    Quanto ao Web IDE: tens razão no que dizes, é realmente uma ferramenta sofisticada, que permite plugins, templates, wizards e ferramentas visuais para desenhar as telas. E aliado ao SAP Splash, ainda melhor. Mas corre num browser…

    Relativamente ao Webstorm… para o Fiori/UI5 existe muito pouco. Existem uns tutoriais que ajudam a ter as bibliotecas e alguns templates… mas só isso. Mas como IDE é muito interessante (uso para desenvolver em Node.js e controlar versões com o GIT).

    Nota:
    É só uma partilha de ideias e uma oportunidade de através de uma discussão vir a aprender coisas novas… Até porque acho que (como dizes no final do teu post) quem não começar a estudar este assunto agora corre o risco de ficar para trás.

    (desculpa os testamentos…)

    Abraços,
    Carlos

  8. Nuno Godinho Diz:

    Olá Carlos, entendi agora o que dizes e tendo a concordar. Não tinha noção destas diferenças. Obrigado.

Deixe um comentário


Acerca do Abapinho
O Abapinho é suportado pelo WordPress
Artigos (RSS) e Comentários (RSS).