Filipe Saraiva's blog

Tecnologia, sociedade e política.

Archive for the ‘Desenvolvimento’ tag

KDE passando o chapéu para realização do Randa Meeting 2014

without comments

Desde 2009 o KDE reúne durante alguns dias diversos desenvolvedores na cidade suíça de Randa para trabalharem em projetos chave da comunidade. Esses sprints já resultaram em importantes avanços para os usuários das tecnologias desenvolvidas pelo KDE, como o KDE Frameworks 5, o Plasma Next, melhorias no Qt, diversos softwares do KDE Edu, e mais.

Em 2014 haverá uma nova edição desse encontro, o Randa Meeting 2014, e a comunidade iniciou uma campanha de arrecadação para custear essa atividade.

Visite a página da campanha ou a versão que o KDE Brasil traduziu e saiba mais sobre os projetos desenvolvidos nas edições anteriores, quais os planos para a edição de 2014, quem deverá participar, quais os tipos de despesas, e mais.

Eu já fiz minha contribuição, agora é com você – seja usuário, desenvolvedor, ou simpatizante do KDE ou das comunidades e ideias do software livre em geral, contribua! Toda ajuda é bem-vinda.

Written by Filipe Saraiva

June 19th, 2014 at 3:26 pm

Complementação de código no editor de scripts do Cantor

without comments

Alguns meses atrás escrevi sobre as novas funcionalidades disponíveis no Cantor a partir do lançamento do KDE 4.13. Entretanto, eu acabei não escrevendo sobre uma nova e bastante útil funcionalidade também disponível naquele lançamento – a nova complementação de código disponível no editor de scripts do Cantor.

Eu havia desenvolvido o destaque de sintaxe padrão para cada backend que suporta o editor de scripts. Esse editor é baseado em KatePart/KTextEditor, uma impressionante biblioteca da KDE libs utilizada em vários softwares do KDE, como o KWrite, Kate, Kile, KDevelop, e mais.

Os desenvolvedores do Kate lançaram uma nova funcionalidade no KDE 4.13, uma versão melhorada da complementação de código para todas as linguagens suportadas pelo KTextEditor. Essa funcionalidade utiliza os mesmos arquivos XML usados no destaque de sintaxe de cada linguagem para disponibilizar a nova complementação de código.

Como eu desenvolvi o destaque de sintaxe padrão para o editor de scripts, essa nova complementação de código foi habilitada por padrão também. Fantástico!

Então, vamos ver algumas imagens dessa nova funcionalidade em ação:

code-completion-scilab-cantor

Complementação de código para Scilab

Na figura acima a complementação de código foi utilizada para escrever um comando plot no editor de scripts para a interface com o Scilab.

code-completion-maxima-cantor

Complementação de código para Maxima

No backend do Maxima backend podemos ver a complementação de código funcionando não apenas com os comandos que iniciam com o fragmento de texto digitado: por exemplo, contour_plot apareceu na lista de sugestões.

Esta nova complementação de código está disponível para todos os backends que implementam o suporte ao editor de scripts. Para utilizá-la basta digitar Ctrl+Espaço no editor.

Existem algumas melhorias para esta funcionalidade a serem implementadas no futuro. Por exemplo, seria interessante carregar funções dos módulos/pacotes importados no editor – em Python, eu poderia executar um import numpy e as funções do numpy poderiam estar disponíveis na complementação de código também. E seria bom se as variáveis na área de trabalho do Cantor estivessem disponíveis no editor de scripts.

Mas isto é um trabalho para o futuro. Por agora, você pode se divertir com essa nova complementação de código. E obrigado a todos os  desenvolvedores do Kate por esta funcionalidade!

Written by Filipe Saraiva

June 1st, 2014 at 8:33 pm

Code completion in Cantor script editor

with 2 comments

Some months ago I wrote about the new features available in Cantor from KDE 4.13 release. But I did not write about a new nice feature available in that release too – so let’s see the new code completion in Cantor script editor!

I coded a default syntax highlighting to each backend in script editor. Script editor is based on KatePart/KTextEditor, a great piece of code from KDE libs used in several KDE softwares like KWrite, Kate, Kile, KDevelop, and more.

The Kate guys released a new feature in KDE 4.13 release: an improved code completion for all languages supported by KTextEditor. It use the same XML file to syntax highlighting from each language to provide this new code completion.

As I coded the default syntax highlighting, the code completion for the script editor was enabled as default too. Amazing!

So, let’s see some pictures about this feature:

code-completion-scilab-cantor

Code completion in Scilab

This figure we use code completion to write a plot command in script editor from Scilab backend.

code-completion-maxima-cantor

Code completion in Maxima

In Maxima backend we can see the code completion working not only to the commands with initial string typed: for example, contour_plot is suggested in the figure.

This new code completion is available to all backends that have the script editor plugin implemented. To use it you just type Ctrl+Space in the editor.

There are some improvements to this feature to be implemented in the future. For example, it would be interesting load the functions to modules/packages imported in the editor – for example, in Python I can use import numpy and the numpy functions could be available in code completion too. The variables in the Cantor workspace could be available in the script editor too.

But it is work to the future. For now, you can have fun with this new code completion., and thanks for all Kate developers for this nice feature!

Written by Filipe Saraiva

May 13th, 2014 at 4:56 pm

KDE packagers: give some love to Cantor

with 11 comments

python2_select

I have some posts to write about Cantor but first I would like to request a help to KDE packagers of several Linux distros around the world.

I received some mails from users asking “how can I use python in Cantor?” or “where is python support in Cantor?”. Well, python2-backend is available in Cantor since KDE 4.12 release. If you is using KDE >= 4.12 but you can not to use python in Cantor, maybe the package was not build correctly.

python 2 development library (commonly packed as python-devel in some Linux distros) is required to build python2-backend. python 2 is required to use Cantor with python 2.

Then if you are a Cantor user and can not to use Cantor with python, please write a bug report in the bug management system of your distro. You can to put a link in the bug report to this post too.

Anyway, if your distro bring or not bring python2-backend, write a comment below and I will make a table with this information.

[UPDATE May 13, 2014] – In FISL I and Paulo Andrade, a Mandriva/Conectiva employer, noticed that Cantor is missing the Python backend in Fedora. Paulo wrote a bug report and the packager fix it. Maybe in one week the Cantor with the fix will be available in Fedora repositories. Thanks Paulo!

Written by Filipe Saraiva

May 13th, 2014 at 12:47 am

Haverá futuro para o Diaspora?

with 7 comments

Diaspora é aquela rede social que foi financiada via crowdfunding no Kickstarter e fez muito barulho na imprensa do mundo todo por conta do discurso que seus criadores utilizavam: “Diaspora será o Facebook killer”. Mas isso foi em 2010.

Perambulo pelo Diaspora desde a versão de testes, lançada em 2011. Na época você tinha que conseguir um convite para ter uma conta na instância (também chamada de pod) mantida pelo time de desenvolvedores, o joindiaspora. De lá para cá pouca coisa mudou quando falamos em funcionalidades – o que contrasta bastante com as grandes mudanças que ocorreram no gerenciamento do projeto, onde hoje os quatro programadores que recorreram ao crowdfunding para levantar a grana que pagaria o desenvolvimento já não trabalham mais com a plataforma, “doada para a comunidade” há um ano e meio, e que agora depende exclusivamente desta para avançar.

Antes de começar o artigo de fato, quero dizer aos amigos que não me tomem como pessimista ou alguém do gênero – ou pior, como alguém que não acredita que comunidades podem criar e gerir bons projetos de software livre. Eu participo ativamente como desenvolvedor em pelo menos dois projetos comunitários (a saber, KDE e Mageia) e sei que, sim, é possível termos bons projetos baseados em comunidades. Mas o que acompanho do Diaspora, em termos de desenvolvimento, não me deixa muito animado. Por outro lado, talvez os brasileiros que nos últimos meses lotaram o Diaspora possam dar sua contribuição para não deixar a plataforma morrer.

De qualquer forma, caso o Diaspora não decole, ainda temos muitos bons projetos de redes sociais descentralizadas, federadas, em software livre, para podermos migrar.

Diaspora – funcionalidades

Para um projeto que se propôs a desbancar o Facebook, faltam muitas funcionalidades no Diaspora. Basicamente você tem o stream (a sua timeline) com as pessoas que você segue. Você também pode seguir tags – a rede social permite a inclusão delas nos posts. E quando você adiciona alguém, a pessoa adicionada não o segue automaticamente de volta. Sempre que adicionar alguém você colocará o contato em um ou mais aspects – conceito criado aqui, depois copiado como Listas no Facebook ou o Círculos no Google+. Os posts podem ser escritos usando a linguagem de marcação Markdown – não há um editor WYSIWYG para usá-la.

Olhando bem para esse conjunto de funcionalidades, o Diaspora lembra muito mais o Twitter do que o Facebook, porém sem a limitação de caracteres do primeiro.

A partir das funcionalidades presentes, podemos listar as funcionalidades que mais fazem falta no projeto: não há suporte a grupos; não há chat; não há uma API que permita o desenvolvimento de clientes ou outras aplicações que utilizem o Diaspora; as tags não são federadas – portanto você só verá as tags dos perfis que estão no mesmo pod que você; entre outras.

Caramba, não há uma funcionalidade para importar um perfil em outro pod! Ou seja, você tem uma rede descentralizada, mas o seu perfil está amarrado ao pod no qual você o criou até o fim daquele pod. Você conseguirá exportar seu perfil, mas servirá apenas como backup em algum canto perdido do seu HD.

É um tanto decepcionante constatar isso, em especial quando você sabe que em outras redes sociais livres essas funcionalidades estão presentes, ou quando você conhece a história de um famoso fork do Diaspora chamado Diasp0raca.

Esse fork era mantido por um desenvolvedor chamado Pistos. Nenhuma de suas contribuições de funcionalidades foram aceitas pelos desenvolvedores do projeto original, mas Pistos mantinha-as em seu fork e também gerenciava um pod que rodava o seu código – que ficava em http://diasp0ra.ca/. Com o tempo, devido à presença dessas funcionalidades, outros pods adotaram o código de Pistos.

Para resumir, o Diasp0raca tinha grupos, chat, possibilidade de importar os contatos de um perfil, CSS customizável, preview de posts, entre outras funcionalidades. Inclusive ele estava trabalhando em uma API! Tudo isso já funcionava no início de 2012. Mais de dois anos depois, e a única dessas funcionalidades disponível no Diaspora é… o preview de posts.

Pistos acabou rompendo relações com o Diaspora após o anúncio de que os desenvolvedores desta fariam uma profunda alteração no protocolo de comunicação, o que cortaria a comunicação entre diversos pods e outras redes sociais que conseguiam se comunicar com a rede Diaspora (por exemplo, o Friendica), sem qualquer discussão com os desenvolvedores interessados e sem disponibilização de documentação. O hacker chutou o balde e lançou um novo projeto de redes sociais distribuídas, o LiberTree.

Diaspora – gerenciamento do projeto

Como já comentado, o Diaspora começou como o projeto de um pequeno grupo de desenvolvedores – quatro caras. Apesar do desenvolvimento ser livre e colaborativo, o gerenciamento do projeto era bastante centralizado nesse time, e poucas funcionalidades criadas por desenvolvedores externos foram absorvidas pelo projeto.

A impressão que fica é que eles tentaram criar um modelo de negócios no estilo do WordPress, mas não tiveram êxito. Relatório de dívidas quanto à manutenção do pod público (o joindiaspora), a falta de um plano de negócios para captar recursos, a criação de um novo projeto baseado na criação de memes (!!!), e o triste suicídio de Ilya, um dos fundadores, acabaram levando o grupo à decisão de desistirem do projeto e a tomarem a típica atitude de uma empresa que não está mais interessada em investir em um software livre antes desenvolvido por ela: “doaram o projeto para a comunidade”. Era agosto de 2012.

Desde então o Diaspora tem sido gerenciado por um grupo de desenvolvedores reunidos sob a Diaspora Foundation. Seus principais canais de discussão sobre o desenvolvimento da ferramenta são o grupo de e-mails, a wiki, a ferramenta de deliberação loomio, e o repositório do código hospedado no github.

O que sinto ao visitar esses lugares é um projeto ainda perdido, com pouco gás, sem aqueles desenvolvedores que se metem a criar grandes funcionalidades, que dedicam seu tempo a fazer o projeto caminhar de verdade. Claro que o pessoal está trabalhando, e o trabalho deles deve ser agradecido – mas a maior parte são ainda em pequenos detalhes, coisas pontuais diante das necessidades da rede.

Olhe por exemplo a lista de e-mails de desenvolvimento: você pode rolá-la e não verá nada de discussão sobre qualquer funcionalidade que aponte maneiras de implementá-la. Apenas diálogos sobre algo que precisa ser feito, ou propostas de implementações de funcionalidades pequenas.

No loomio também é assim. Há importantes tópicos abertos, mas que tiveram início há muito tempo – vários meses e alguns com quase um ano de idade. Há discussão no período imediato à abertura do tópico, depois ele esfria. Passam-se meses, depois volta um pouco de diálogo, apenas para morrer em seguida.

Enquanto escrevia esse post aconteceu algo que ilustra bem essa situação: compartilhei um merge request no github com código para prover acesso à aplicações de terceiros para o Diaspora – ou seja, boa parte de uma API. O Diaspora precisa disso para facilitar que seus usuários gerem e direcionem conteúdo para a rede. Há um serviço, o PaperBod, que direciona para o Diaspora o stream de sua conta do Twitter, Facebook, ou mesmo um feed RSS. O que ele precisa para funcionar? O seu login e a sua senha! Que dizer de uma rede social cujo discurso é baseado em maior privacidade e controle dos dados pelo usuário, onde você entrega o login e senha do seu perfil para uma aplicação?

Enfim, voltando à API, o desenvolvedor abriu o pedido de merge 5 meses atrás. O código foi dado como terminado por outro desenvolvedor há um mês, seguido de um pedido de revisão. Desde então, não houveram quaisquer manifestações – o código está lá, “flutuando”.

O Diaspora tem pela frente grandes desafios se ele quiser manter-se relevante. Há a necessidade da definição de um protocolo de comunicação que possibilite as diversas funcionalidades esperadas pela rede. Há discussões sobre o uso de protocolos já existentes, como o tent.io, zot2, ou pumpio, por exemplo, mas são discussões antigas, que não definiram a direção que o desenvolvimento deve tomar e que não produziram resultado até o momento.

Por conta dessas indefinições, eu tendo a ver os desenvolvedores do Diaspora como programadores que querem sim ter uma rede social distribuída funcionando, mas que eles não dão a ela uma importância central para o contexto das redes sociais hoje, mais ou menos como os históricos desenvolvedores de software livre encaravam suas aplicações como substitutas para os softwares proprietários que eram comumente utilizados, principalmente no início da história do movimento software livre. Essa atitude true é mais presente, penso eu, nos desenvolvedores do Friendica/Red – basta citar que os desenvolvedores do core dessas redes não tem conta em nenhuma outra rede social. Para eles, o Friendica/Red não é um “acessório”, algo que eles usam em paralelo com as redes centralizadas. Eles são obcecados com privacidade, segurança de dados – o software deles tem que funcionar porque eles não tem alternativa, não estão dispostos a utilizar uma rede social proprietária, centralizada, que terá acesso aos dados deles e de quem eles levarem para lá.

Haverá futuro para o Diaspora?

Apesar do post em sua maior parte apresentar uma visão negativa do Diaspora, essa rede social conseguiu algo que nenhuma outra rede social descentralizada conseguiu – ela tem muitos usuários. Certamente devido ao grande barulho e propaganda que uma rede autodenominada anti-Facebook conseguiu na mídia, mas também por pessoas dedicadas que subiram servidores, colocaram o projeto debaixo do braço, e foram fazer palestras/montar stands/dar entrevistas/participar de reportagens e todo o mais do bom trabalho de promoção que todo ativista de software livre, quando se encanta por determinado projeto, se propõe a fazer.

E sabemos que o que atrai usuários para uma rede social é a presença de outros usuários – que geram conteúdo e atrai atenção para a rede, resultando em mais conteúdo que atrairá a atenção de mais usuários que irão gerar mais conteúdo… e por aí segue.

Existem redes sociais hoje que entregam as funcionalidades mais desejadas que não existem no Diaspora. O Friendica é uma delas, que utilizei por quase um ano, e era ótimo como tudo funcionava bem. Mas acabei saindo porque só me relacionava com outras 2 pessoas. Enquanto isso continuo no Diaspora, mesmo tendo consciência de todo o cenário que descrevi aqui – querendo ou não, lá ainda existe alguma interação.

No final de 2013 um pod brasileiro, o DiasporaBR, foi lançado e enquanto escrevo essa frase ele conta com 6475 usuários. É muita gente. 1% disso dá 64.75 pessoas, com certeza um número muito maior que os atuais desenvolvedores do Diaspora. Se 0.1% desses usuários se tornarem desenvolvedores (6 pessoas e meia =D), com certeza será uma boa arrancada para a rede social.

O que fica para nós, ativistas do software livre, é uma encruzilhada complicada. O Diaspora tem mais usuários, mas se ele não avançar e prover novas funcionalidades, esses perfis serão apenas números sem pessoas por trás. Mas a alternativa de migrar todo esse contingente para uma rede social que funciona hoje, é uma alternativa viável? Se sim, quem está disposto a bancá-la – na forma de disponibilizar servidores e mão de obra técnica?

Novidades no Editor de Scripts do Cantor

without comments

Um post rápido sobre o Cantor antes da última metade das festas de Carnaval.

KDE 4.13 está com as funcionalidades congeladas agora, e tive tempo de desenvolver algumas melhorias para o editor de scripts do Cantor, que estará disponível no próximo lançamento estável do KDE por volta de 16 de abril.

Agora, os backends para Python 2 e Scilab tem suporte ao editor de scripts! Veja algumas imagens:

python_script_editorEditor de scripts do Cantor para Python 2

scilab_script_editor Editor de scripts do Cantor para Scilab

Você pode acessar o editor de scripts via barra de menu Exibir -> Mostrar Editor de Script. O editor é baseado em kate-part, então ele disponibiliza destaque de sintaxe, numeração de linhas, mini-mapa do texto, e todas as outras coisas legais disponíveis no Kate. Você também tem um botão Executar Script que, após pressionado, carrega o script na área de trabalho do Cantor, como pode ser visto nos exemplos.

Há outras novidades também para os demais backends do Cantor. O Editor de Scrips agora carrega o destaque de sintaxe padrão para cada backend – nas versões anteriores, isso não acontecia. E também, se você pressionar o botão Novo, o novo editor já terá o destaque de sintaxe padrão funcionando também.

Estas são as novidades do meu trabalho no Cantor para o KDE 4.13. Eu pretendo melhorar o backend para Python 2 e o editor de scripts em lançamentos futuros.

Mas agora é hora de aproveitar o restinho do carnaval nas festas de rua do Brasil. Feliz Carnaval! ;)

Cantor’s script editor news

with 4 comments

A small blogpost about Cantor before Brazilian Carnival parties.

KDE 4.13 is feature freeze now and I developed some improvements in Cantor’s script editor. It will be available in next KDE stable release around April 16.

Now Python 2 and Scilab backends have support to script editor! See some pictures:

python_script_editorCantor Script Editor for Python

scilab_script_editor Cantor Script Editor for Scilab

You can access script editor in menu bar View -> Show Script Editor. The script editor is based in kate-part, so you have syntax highlighting, line numbering, mini-map, and all cool stuffs from Kate. You have a Run Script button too, so you can just push this button and the script will be load in Cantor worksheet, as you can see in examples.

There is news for others Cantor backends too. Now script editor load default syntax highlighting for each backend – in old versions it did not happen. And, if you push New button, the new script editor will have the default syntax highlighting working too.

It is the news about my work in Cantor for KDE 4.13. I intent improve Python 2 backend and script editor for future releases.

But now it is time to go to Brazilian street parties! Happy Carnival! ;)