Filipe Saraiva's blog

Tecnologia, sociedade e política.

Archive for the ‘Desenvolvimento’ tag

Minha lista TODO para o LaKademy 2014

without comments

logoazul_menor

Nesta semana em São Paulo, uma das maiores cidades deste planeta, sediará a segunda Conferência Latino Americana do KDE – ou, como chamamos, o LaKademy!

O evento ocorrerá no Centro de Competência em Software Livre da Universidade de São Paulo, um lugar interessante onde academia, empresas, e comunidades, trabalham juntas para criar, melhorar, e pesquisar sobre software livre.

Neste evento, a comunidade Latino Americana do KDE tentará algo novo: teremos apresentações sobre particularidades do KDE. Em eventos específicos do KDE por aqui, é mais comum termos apenas sessões de hacking, enquanto as apresentações e mini-cursos são ofertados nos eventos de software livre mais gerais. Desta vez nós organizamos um evento aberto para não-contribuidores do KDE, e talvez ao final eles se tornem contribuidores do projeto.

A programação do evento tem vários assuntos: arte, port de softwares do GTK para Qt (um potencial flamewar), KDE Connect, e mais. Eu apresentarei um tutorial introdutório sobre C++ + Qt + KDE no Android. O principal caso de estudos será o GCompris, e será interessante mostrar um software cujo o mesmo code pode ser compilado e executado no Linux e no Android. Também apresentarei outros softwares: liquidfun, uma biblioteca C++ para simulação de fluídos (que tem uma demo muito massa no Android); VoltAir, um jogo desenvolvido em QML pelo Google para o Android (e open source!); e talvez KAlgebra, mas eu preciso compilá-lo ainda.

Sim, isso é C++ e QML no Android!

Para as sessões de hacking eu reservarei um tempo para estudar o port do Cantor para Qt5/KF5; é hora de começar esse trabalho. Ainda sob esse tópico, pretendo conversar com os amigos do KDE sobre um software para auxílio de escrita de artigos científicos… mas bem, espere por novidades no próximo ano. =) Farei também algum trabalho com os bots do KDE Brasil que funcionam nas redes sociais, corrigindo alguns bugs, etc.

Para as reuniões, espero discutir sobre as ferramentas de comunidação que temos (e minha proposta é usar o KDE todo para auxiliar no gerenciamento de nossas ações), e contribuir com a avaliação das ações do KDE Brasil no nosso país. Desde o pultimo LaKademy (2012, Porto Alegre), nós continuamos a promover o KDE nos eventos de software livre, e pudemos trazer vários contribuidores do KDE para o Brasil. Agora é hora de pensarmos em mais e novas atividades para realizarmos.

Mas LaKademy não é apenas sobre trabalho. Nós teremos algumas atividades culturais também, como o Konvescote no Garoa Hacker Club, um hackerspace em São Paulo, e algumas cervejas para bebermos na Vila Madalena. Mais importante, estou muito feliz em rever os amigos do KDE de novo (Brasil, por que tão grande?).

Estamos trabalhando para fazer um LaKademy fantástico esse ano! Fique de olho no Planet KDE e no Planet KDE Português para acompanhar mais notícias diretamente do evento!

Vejo você no LaKademy!

(ou no Akademy, mas isso é história para um outro post :) )

imgoingtoLakademytamanhopequeno

My TODO List for LaKademy 2014

without comments

logoazul_menor

Next week São Paulo, one of the biggest cities in this planet, will host the second KDE Latin America Summit – or, how we call, LaKademy!

The event will be held in the FLOSS Competence Center of University of São Paulo, an interesting center where academia, enterprises, and community works together to create, to improve, and to research free and open source software.

In this event, Latin America community will try a new thing: we will have presentations about KDE stuffs. In specific KDE events of this part of the world it is more common to have only hacking sessions, and KDE presentations and short courses are given only in more general free software events. This time we organized an “open” event to non-KDE contributors too – maybe in the end of event they will be new gearheads.

The event program have a lot of topics: artwork, porting software from GTK to Qt (potential flamewar detected =D), KDE Connect, and more. I will present an introductory tutorial about C++ + Qt + KDE on Android. The main study case to be presented will be GCompris, and it will be interesting to show a software with a same source code compiling and running on Linux and Android. I will to show another software too: liquidfun, a C++ library to liquid simulation (it have an amazing demo in Android); VoltAir, a QML-based game developed by Google to Android (and open source!); and maybe KAlgebra, but I need to compile it yet.

Yes, it is C++ and QML on Android!

For hacking session I will reserve a time to study the Qt5/KF5 port of Cantor; it is time to begin this work. Other thing in this topic, I would like to talk with my KDE colleagues about a software to help scientific writing… well, wait for it until next year. =) I will work in KDE Brazil bots on social networks to fix some bugs too.

For meetings, I expect to discuss about communications tools (my propose is to use KDE todo to help with promo actions management), and to contribute with evaluation of KDE Brazil actions in the country. Since last LaKademy (2012, Porto Alegre), we continues to spread KDE in free software events, and we can to bring several KDE contributors to Brazil too. Now we must to think in more and news activities to do.

But LaKademy is not only about work. We will have some cultural activities too, for example the Konvescote at Garoa Hacker Club, a hackerspace in São Paulo, and some beers  to drink in Vila Madalena district. More important, I am very happy to see my KDE colleagues again (Brazil, why so big?).

So, let’s to do an amazing LaKademy this year! Look at Planet KDE and Planet KDE Portuguese to see more news directly from the event!

I see you at LaKademy!

(or in Akademy, but it is story to other post :) )

imgoingtoLakademytamanhopequeno

Written by Filipe Saraiva

August 23rd, 2014 at 3:13 am

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?