DEV Community: Marcio Frayze

What it was like to give a talk at Clojure South 2025

Marcio Frayze — Wed, 03 Dec 2025 14:45:59 +0000

What is Clojure South?

"Organized by Nubank, Clojure South is part of the official Clojure community schedule, connecting developers, enthusiasts, and companies to share real experiences, discuss trends, and strengthen the global network of the language." - Translated from Brazilian Portuguese by me.

Motivation

In a conversation with a Brazilian woman I met at Lambda Days 2025 (I talked about what it was like to attend this event in this article), I asked if she would attend the conference (she works at Nubank) and found out she would be an instructor for the Clojure workshop. During this conversation, she suggested that I should submit a talk proposal. I mentioned an idea I had in mind but was feeling a bit insecure about sending it. She encouraged me to try, and I decided to take a chance!

Although I already have some talks on my resume, I felt that maybe I should be more cautious in this case, and submit a proposal for a lightning talk (a 10-minute talk with no time for questions).

A few weeks later, to my surprise, the proposal was accepted!

Theme

I had two possible topics in mind. One about teaching Clojure and Functional Programming to beginners (because of my course Clojure: Introdução à Programação Funcional; an Introduction to Functional Programming through Clojure, for Brazilians). And another about a project I built at the company where I work, using Clojure in the backend and the programming language Elm for the front-end.

I chose the second one. It was already a project I wanted to talk about publicly, and this seemed like a great opportunity!

Another factor is that the project is related to a very well-known App in Brazil, the Digital Driver's License — an App developed by SERPRO and available for Android and iOS. I imagined this could increase the chances of the talk being accepted.

The full description I submitted was:

During the development of the Carteira Digital de Trânsito (Digital Driver's License), I realized how challenging it was to support an App with millions of users integrated with many systems. I dreamed of creating a simple, friendly internal interface for queries that would make support easier. That’s how Apoio CDT was born, a web system that automated processes and enabled fast and secure queries. With a Clojure backend and an Elm front-end, we developed an MVP in three weeks. The result was a simple, efficient, and easy-to-maintain web architecture over the years.

As far as I know, this was the company’s first project using Clojure and also the first using Elm. And it was the first time I had the opportunity to talk about this system to people outside the company where I work!

Other Talks and Workshops

The event lasted two days, and the first day featured the two workshops:

Clojure Workshop

An introductory Clojure course, in English, taught by Christoph Neumann, Clojure Developer Advocate at Nubank.

Although I already have experience with Clojure, it was great to reinforce the main concepts of the language and I even learned some fundamentals I didn’t know yet!

Datomic Workshop

The afternoon of the first day was dedicated to the workshop of the Datomic database. It was taught in Brazilian Portuguese by Carolina Silva (the same one I mentioned at the beginning of this article) and Hanna Figueiredo, both Software Engineers at Nubank.

I had already watched several talks about Datomic and always found it an intriguing and interesting database. I believe it would make a lot of sense to use it in several projects I have worked on or currently work on.

The workshop covered many theoretical concepts of Datomic, but it was also very hands-on.

You can check out the hands-on portion of the workshop in this GitHub repository!

I confess it was a lot of information in a short time. I will definitely need to revisit the repository and practice a lot more to internalize the core concepts of this database. But it was totally worth it!

If before I already thought studying this database was worthwhile, now I’m certain of it!

Conversations and Feedback

Right when I arrived at the event, I had the chance to talk to some people I only knew online, such as Arthur Fücher. Besides being a Senior Software Engineer at Nubank, Arthur is very active in the Brazilian Clojure community!

And even though I am quite shy, I was able to meet many great people from Brazil and other countries.

In particular, I was welcomed very warmly by Christoph Neumann. I was standing quietly in a corner during the happy hour, after the second day of the event, eating and thinking about heading home, when he approached me and started a conversation. We talked a bit, and I began asking a few questions about Datomic. During the conversation, I mentioned that Datomic might be a good fit for the company where I work. When I said what the company does, he became very interested! And soon offered to introduce me to Joe Lane, Principal Engineer Building Datomic at Nubank!

I talked to Joe and, again, was very kindly received! He seemed genuinely excited when I mentioned where I worked and the types of projects SERPRO develops, and he offered to answer any questions about Datomic — even mentioning that SERPRO could be a great Datomic case study.

During the event, I also had the opportunity to meet people who took my Clojure course! Among them, I met Bruno Guimarães, currently a Senior Software Engineer at Nubank and the host of the conference.

Meeting students of my online course in person is always a very special experience! The numbers, the stats, the comments — they gain a face, a voice, life. It's truly rewarding!

On the second day, after my talk, many people came to talk and learn more about how I introduced Clojure into a federal government system in Brazil. Some had specific questions about my motivation for using Elm on the front-end (instead of opting for ClojureScript), plus several other interesting conversations.

The feedback was very positive, and all the conversations were friendly, fun, and respectful.

Food (and More Conversations)

The event had a welcome coffee in the morning and coffee breaks throughout the day. The quality was excellent and everything was quite formal (maybe a bit too formal? lol).

For lunch, there were several options (not included in the ticket price) within the same building complex where Nubank Sparks is located. This made things much easier, especially on the workshop day, since I had my laptop with me.

You could eat wherever you wanted. But I liked the nearby options, and it became yet another opportunity to talk to more people from the event. Again, even being shy and sitting somewhere more secluded, several people soon came to sit with me and chat. At that moment, I met a Ukrainian attendee who showed us the Diia App, where she can have digital versions of several documents such as her Driver’s License, Passport, and more — with access to over 130 government services (you can learn more about this App on its Wikipedia page)!

Was It Worth It?

Definitely, yes!

The event happened on two weekdays (a Monday and Tuesday). This may make it difficult for some people to attend — for example, a colleague of mine couldn’t go because his company didn’t allow him to take those days off. But for those who can attend, it’s far less tiring than having an event like this over the weekend after a long workweek.

I had purchased the early-bird tickets before my talk was accepted, but later the event organizers refunded me — I received free tickets for both days as a speaker. They also offered help with transportation and lodging, which I declined since the event was close to where I live.

The experience of speaking at an event of this magnitude, even if only for 10 minutes, was incredible! It’s a feeling of great gratitude to the people who organized the conference and who trusted in my potential!

Did you like this article? Don't forget to leave a reaction! They serve as a big incentive for me to write others.

You can also discover more articles, podcasts and videos at: https://segunda.tech/tags/english.

And if you want, follow me on twitter, blue sky and Linkedin.

Como foi palestrar na Clojure South 2025

Marcio Frayze — Sun, 23 Nov 2025 21:40:28 +0000

O que é a Clojure South?

Segundo site oficial:

"Organizada pelo Nubank, a Clojure South faz parte da programação oficial da comunidade de Clojure, conectando pessoas desenvolvedoras, entusiastas e empresas para compartilhar experiências reais, discutir tendências e fortalecer a rede global da linguagem."

Motivação

Em uma conversa com uma brasileira que conheci na Lambda Days 2025 (falei sobre como foi participar deste evento neste artigo), perguntei se ela iria assistir às palestras (ela trabalha para a Nubank) e descobri que ela iria ser instrutora do workshop de Clojure! Nesta conversa ela sugeriu que eu deveria enviar uma proposta de palestra. Comentei uma ideia que eu tinha para submeter, mas que estava meio inseguro de enviar. Ela me encorajou a tentar e eu resolvi arriscar!

Embora tenha no meu currículo algumas palestras e participações em podcasts, sentia que talvez fosse mais interessante, neste caso, submeter uma proposta no formato lighting talk (palestra de apenas 10 minutos e sem tempo para perguntas).

E algum tempo depois, para minha surpresa, a proposta foi aceita!

Tema

Havia pensado em enviar propostas sobre dois possíveis temas. Um sobre o ensino de Clojure e Programação Funcional para iniciantes (por conta do meu curso Clojure: Introdução à Programação Funcional). E outro sobre um projeto que fiz na empresa onde trabalho, que utiliza Clojure no backend e a linguagem de programação Elm para o front-end.

Optei pela segunda opção. Já era um projeto que eu queria falar sobre publicamente e esta parecia ser uma boa oportunidade!

Outro fator é que o projeto em questão está relacionado com um App bastante famoso no Brasil, a Carteira Digital de Trânsito — App desenvolvido pelo SERPRO e disponível para Android e iOS. Imaginava que isso poderia aumentar as chances de a palestra ser aceita.

A descrição completa que enviei foi:

Durante o desenvolvimento da Carteira Digital de Trânsito, percebi como era desafiador dar suporte a um App com milhões de usuários integrado a diversos sistemas. Sonhei em criar uma interface interna simples e amigável para consultas que facilitassem o atendimento. Assim surgiu o Apoio CDT, um sistema web que automatizou processos e permitiu consultas rápidas e seguras. Com backend em Clojure e front-end em Elm, desenvolvemos um MVP em três semanas. O resultado foi uma arquitetura web simples, eficiente e fácil de manter ao longo dos anos.

Até onde sei, este foi o primeiro projeto da empresa que utilizada Clojure e também o primeiro a utilizar Elm. E esta foi a primeira vez que tive oportunidade de falar sobres este sistema para pessoas de fora da empresa onde trabalho!

Demais palestras e workshops

O evento durou dois dias, sendo que no primeiro ocorreram os 2 workshops:

Workshop de Clojure

Um curso de introdução ao Clojure, em inglês, ministrado pelo Christoph Neumann, Developer Advocate de Clojure no Nubank.

Embora eu já tenha experiência com Clojure (e inclusive seja instrutor do curso Clojure: Introdução à Programação Funcional), foi muito legal reforçar os principais conceitos desta linguagem e também aprendi alguns fundamentos que ainda não conhecia!

Workshop de Datomic

O período da tarde do primeiro dia foi destinado ao workshow do banco de dados Datomic. Este foi ministrado em português pela Carolina Silva (a mesma que citei no começo deste artigo) e Hanna Figueiredo, ambas Software Engineering no Nubank.

Eu já havia assistido várias palestras sobre o Datomic e sempre achei um banco de dados muito intrigante e interessante. Acredito que faria muito sentido utilizá-lo em vários dos projetos que atuo ou já atuei no passado.

O workshop mostrou vários conceitos teóricos do Datomic, mas também foi muito prático.

Você pode conferir a parte prática do workshop neste repositório do GitHub!

Confesso que foi muitas informações em pouco tempo. Definitivamente, vou precisar voltar ao repositório e praticar bastante ainda para internalizar os principais conceitos deste banco de dados. Mas valeu muito a pena!

Se antes eu achava que valeria a pena estudar este banco, agora tenho certeza!

Conversas e feedbacks

Logo ao chegar no evento tive a oportunidade de conversar com algumas pessoas que só conhecia virtualmente, como o Arthur Fücher. Além de ser Senior Software Engineer no Nubank, Arthur é uma figura muito presente na comunidade Clojure do Brasil!

E mesmo sendo uma pessoa bastante tímida, foi possível conhecer muitas pessoas bacanas do Brasil e de outros países.

Em especial, fui muito bem recebido pelo Christoph Neumann. Eu estava parado em um canto no happy hour, após o segundo dia de evento, comendo e pensando em já ir pra casa, quando ele se aproximou e puxou conversa. Conversamos um pouco e comecei a fazer algumas perguntas sobre Datomic. Ao longo da conversa, citei que talvez fosse um banco de dados interessante para empresa onde trabalho. Quando falei onde trabalhava e o que a empresa fazia, ele se mostrou bastante interessado! E logo se ofereceu para me apresentar o Joe Lane, Principal Engineer Building Datomic na Nubank!

Conversei com o Joe e, mais uma vez, fui super bem recebido! Ele mostrou bastante entusiasmo quando comentei onde trabalhava e os tipos de projetos que o SERPRO desenvolve, e ficou à disposição para tirar dúvidas sobre Datomic, inclusive comentando que o SERPRO poderia ser um ótimo case para o Datomic.

Ao longo do evento também tive a oportunidade de conhecer algumas pessoas que fizeram meu curso de Clojure! Entre essas pessoas, conheci o Bruno Guimarães, que atualmente é Senior Software Engineer no Nubank e foi host da conferência.

Conhecer pessoalmente pessoas que fizeram meu curso online é sempre uma experiência muito legal! Os números, as estatísticas, os comentários, ganham um cara, uma voz, vida. É sempre muito gratificante!

No segundo dia, após a minha apresentação, muitas pessoas vieram conversar e querer saber mais sobre como consegui introduzir Clojure em um sistema do governo federal brasileiro. Tiveram algumas dúvidas mais pontuais, sobre minha motivação para usar Elm no front-end (e não optar por utilizar Clojure em sua versão ClojureScript), entre várias outras conversas interessantes.

O feedback foi bastante positivo e todas as conversas foram muito bacanas, bem humoradas e respeitosas.

Comidas (e mais conversas)

O evento contava com welcome coffee no início do dia e coffee breaks ao longo do dia. A qualidade era muito boa e tudo muito formal (talvez formal até um pouco demais? rs).

Já para almoçar, existiam várias opções (não inclusas no valor do ingresso) de restaurantes dentro do mesmo complexo de prédios onde encontra-se a Nubank Sparks. Isso facilitava bastante, já que não precisava sair do local, especialmente no primeiro dia, de workshops, já que estava com meu notebook.

Você pode almoçar onde quiser. Mas gostei das opções que estavam disponíveis ali perto e foi mais uma oportunidade de conversar com mais pessoas do evento. Novamente, mesmo sendo bastante tímido e sentando em um lugar mais afastado, logo vieram várias pessoas sentar junto comigo e puxar conversa. Neste momento conheci uma Ucraniana que mostrou pra gente o App Diia, onde ela pode ter versões digitais de vários de seus documentos, como Carteira de Motorista, Passaporte, entre outros e ter acesso a mais de 130 serviços do governo Ucraniano (você pode saber mais sobre este App nesta página do Wikipedia)!

Valeu a pena?

Definitivamente, sim!

O evento ocorreu em dois dias da semana (uma segunda e terça-feira). Isso talvez atrapalhe a participação de algumas pessoas — um colega meu não conseguiu participar pois a empresa não liberou este dias para ele, por exemplo. Mas para aquelas pessoas que conseguem participar, fica muito menos cansativo do que ter um evento como este no final de semana, depois de uma longa semana de trabalho.

Eu havia comprado os ingressos na pré-venda, antes de ter minha palestra aprovada, mas depois tive o valor estornado pela coordenação do evento - ganhei ingressos para os dois dias por ser palestrante. Também me ofereceram ajuda para transporte e estadia, a qual eu recusei, já que o evento seria próximo da minha residência.

A experiência de palestrar em um evento desta magnitude, mesmo que por apenas 10 minutos, foi incrível! É uma sensação de muita gratidão às pessoas que ajudaram a organizar a conferência e que confiaram no meu potencial!

How was my experience at Lambda Days 2025

Marcio Frayze — Fri, 14 Nov 2025 17:49:51 +0000

A Brazilian Portuguese version of this article is available here.

What is Lambda Days?

Lambda Days is an international conference dedicated to functional programming languages held every year in Kraków (Poland). The event brings together researchers, developers, and enthusiasts from communities such as Erlang, Elixir, Scala, F#, Clojure, Haskell, Elm, and many others, creating a space for exchange between academia and industry, and lasts for 2 days.

In addition to technical talks, Lambda Days also covers topics such as data science, distributed systems, artificial intelligence, and good development practices. The atmosphere is very vibrant, bringing together participants from different countries in one of the most beautiful and historic cities in Europe.

What motivated me to go this year?

I had 10 days of vacation to take and no certain destination to go. All the places I thought about visiting seemed to have great potential for a nice trip, but indecision took over. Until I remembered the feeling I had when I saw that Evan Czaplicki was going to give a talk at this conference!

For those who don’t know him, Evan is the creator of the Elm programming language and probably my favorite speaker! I am a great admirer of his technical abilities, but I am also equally impressed by the philosophical ideas he often includes in his speeches.

I had always wanted to attend a talk by Evan in person, and in recent years he hasn’t made many public appearances, being more focused on developing his newest creation: Acadia. That’s why, when I saw that he would be there, I got very excited.

Another key factor in my decision was that, although Poland was not exactly among the top places I wanted to visit in the world, it seemed to be a very interesting and beautiful country, with very distinct cultural, gastronomic, and tourist options. And it is also not one of the most expensive European countries to visit.

What is the city like?

Lambda Days takes place every year in the same city, Kraków. I liked the choice for several reasons. The first, as I already mentioned, is the cost. Although Poland has been a member of the European Union since 2004, it has never adopted the Euro, and its official currency is the złoty (PLN). This can make some things slightly inconvenient, but I found everything quite affordable, especially when compared to richer European countries. The price of the hotel, food, public transportation, and day-to-day expenses were not much higher than what I would find on a trip within Brazil.

The flight, departing from Brazil, is also not excessively expensive, especially considering it’s an 11-hour trip to Frankfurt and then another hour to Kraków (I prefer not to include how much I paid because the price would become outdated too quickly).

Kraków is a beautiful city! And since the event takes place in the summer, the sun rises very early and sets very late (photo taken at 9:45 PM).

I felt very safe the whole time. Since the city is very flat, it’s perfect for walking or cycling. And, of course, there are countless trams that run throughout the entire city! Through an App on your phone (or a machine at the stops) you can buy your ticket. I opted to use an App and buy a time-based ticket. This way, I could move around the city without worrying. You just validate it once (by typing the tram car number, which is printed inside near the doors) and that’s it! They say there is strict ticket inspection (in that case, you just show the validation on the App, otherwise you’ll be fined!), but in practice, I didn’t see any checks. I also found the price very reasonable (especially compared to what I paid in Norway… I almost fell backwards when I saw the public transport prices in Oslo!).

Apparently, it’s quite easy to get from the airport to the city using regular trains. But I chose to use Uber. I was super tired from the trip and felt safer choosing this option.

Another highlight is that Kraków has some very unique tourist attractions. When I travel, I usually prefer walking around the city instead of doing very touristy tours. But this time I decided to visit Auschwitz I and Auschwitz II (Birkenau). It’s hard to describe the feeling of being in a place where literally thousands of people (mostly Jews) died. I still haven’t fully processed it. It’s not the kind of place everyone will want to visit, but if you’re interested and emotionally prepared, I’d recommend going.

I also visited the famous Wieliczka Salt Mine. It’s a beautiful place, but it probably would have been more interesting to visit other parts of the city, such as a forest park a bit farther away.

Another very famous place (and one I regret not visiting) is Schindler’s Factory, which shows the efforts Schindler made to save 1,200 Jews from the Holocaust (those who watched Schindler’s List may know part of this story).

I chose to stay only in Kraków, but it seems quite easy to travel to other Polish cities by train. If I could go back in time, I would’ve planned the trip better and spent a few days in Warsaw, the country’s capital.

The only thing I really disliked about the city was the invasion of “vapes” (electronic cigarettes). Although it’s relatively common to see people using these devices here in Brazil (even though they’re prohibited), in Kraków it seemed like every young adult on the street was carrying one. A real epidemic! And they were sold in many places across the city. It’s a sad sight, considering the well-known health issues associated with these products.

Level of the talks

There were 3 tracks, with talks happening in parallel. Some were very easy to follow, such as the discussion panel Learning How to Learn, where four women (including a Brazilian!) shared their journeys learning, teaching, and growing in their Functional Programming careers.

Other talks were more philosophical, such as Evan Czaplicki’s keynote, titled Rethinking our Adoption Strategy. In it, he talked about what he calls a Platform Language and what differentiates it from a Productivity Language, and what we — people not directly related to the business world — could do to make Platform Languages more appealing than Productivity Languages.

There were also more abstract talks, such as Moa Johansson’s keynote: AI for Mathematical Discovery: Symbolic, Neural and Neuro-Symbolic Methods. I must confess, the level of this (and some others) was far above what I could follow. I still managed to learn some things, but a lot of it I couldn’t fully understand. Another example was the keynote by Martin Odersky, creator of the Scala programming language, titled Making Capabilities Safe and Convenient. I understood the basics, but after a certain point, I got lost and couldn’t follow the proposals anymore.

Since there were 3 rooms/tracks happening concurrently, you can choose whichever talks seem most interesting and useful to you (except keynotes — those happen in the main room with no parallel sessions). A mistake I made was not researching the speakers beforehand. I could’ve made better choices and enjoyed more of the content.

Good food!

The event included breakfast, two coffee breaks (morning and afternoon), and lunch. That was great because I didn't have to worry about meals, and it also gave everyone more opportunities to socialize, chat, and make (or strengthen) friendships. I found everything very organized and tasty.

Party / Happy hour

At the end of the first day, there was a gathering after the event, at another venue. To enter, you just needed to show your event badge.

I don’t have many details about how it went, because unfortunately I didn’t attend. I was very tired after a long day of talks and went back to my hotel. But I regret not taking the opportunity! I was especially regretful when I heard, from some Brazilian attendees I met, that José Valim (creator of Elixir) was at the party! And they were able to talk to him! He didn’t give a talk at the event and I didn’t see him at any point, so I was surprised to learn he was there (and I missed the chance to meet him…).

First trip with so much technology at my disposal

I’ve had the privilege of taking several international trips over the past decades, from Argentina, Chile, and Uruguay, to Norway, Sweden, and the Netherlands, to Costa Rica, the United States, Cuba… but this trip to Poland was different.

When I visited Cuba in 2009, making a phone call to Brazil was very expensive and restricted (I made a few calls from the hotel’s landline). Zero internet or cell phone access. On my trip to the Netherlands in 2012, I only had internet when I found Wi-Fi (using my iPhone 3GS!). Most of the time I navigated the city using a physical map — no GPS.

On this trip to Poland, for the first time I had several technologies available that made my stay MUCH easier!

Unlimited internet

Before traveling, I bought an eSIM (a virtual SIM card — still not very popular in Brazil) through the Holafly app. The process was super simple and in a short time I had a second SIM installed on an iPhone 14. As soon as the plane stopped for my layover in Germany, at Frankfurt International Airport, my chip started working and I already had unlimited internet! WhatsApp working normally and everything else I’m used to using in Brazil. For the first time, I arrived in another country already with internet active on my phone!

Uber

Uber also operates in Poland and I felt safer and more comfortable using the service to get to my hotel. Poland’s train network is very good and I’m sure I could’ve arrived using trains alone, since the hotel was near a station — something I should’ve checked before getting there, but I didn’t! Poor planning there. In any case, the Uber dropped me off right at the hotel door. It was the first time I didn’t have to worry about anything to arrive safely at my first stop on an international trip.

I also used Uber to return to the airport. The rest of the time, I used only public transportation. But knowing that I had that option at any time made me feel more at ease to explore the city freely.

Google Maps / GPS

Google Maps works extremely well in Kraków and helped me a lot getting around the city using trams. It told me exactly when the tram would arrive at the stop, showed me how many stops were left, and alerted me at the correct moment to get off. It had never been so easy to use public transport in an unfamiliar city!

Of course, even so, I got lost a few times haha. In the rush, I would hop on a tram going in the wrong direction. But it was easy to notice by looking at the map, and since I bought time-based tickets, I just got off and took the correct tram.

Chat GPT

Another novelty was traveling for the first time with the possibility of using more recent Generative AI technologies like Chat GPT. I asked questions throughout the trip to understand how things worked in the city, and it helped me find stores and some nice places to visit.

Something I tried a few times was taking a screenshot of Google Maps with my current location and sending it to Chat GPT, asking for tips on things to visit nearby or stores where I could buy certain items I was looking for. The result was very cool!

If it weren’t for Chat GPT, I wouldn’t have visited, for example, the Kościuszko Mound. I was right next to it but it wasn’t on my list of places to visit. I followed the process I mentioned above, and it recommended going there — and I really liked it!

Opportunities for incredible conversations

As I said in the beginning, my biggest motivation for going to this event was to attend Evan Czaplicki’s talk and, of course, I had expectations that he would talk a bit about his new project, which very few people have had access to. When I saw the title of the talk, I already imagined this wouldn’t be the focus — and indeed it wasn’t. But what about behind the scenes?

During the two days of the event, he was talking with attendees in the hall where the coffee break took place. On the first day I tried to approach him to ask some questions, but my shyness won and I went back to the hotel feeling defeated! There, I told myself: you came all the way here because of this! If he’s there tomorrow, you will talk to him!!

And to my surprise, the next day he was there again, talking to people. Once again I felt embarrassed, but gathered the courage and approached. I didn’t know how to start, so I just greeted him and the person he was talking with using a nod and waited my turn while, for some reason, they were discussing Japanese culture.

At some point, he turned to me and gestured to start a conversation. I introduced myself, thanked him for the talk, praised his work as a programmer but also as a speaker and philosopher, and told him I was very inspired by his talks. We exchanged a few words and I soon asked about his “secret” backend project. I asked some general question about what it was about, and he paused for a few seconds. I got worried, honestly. Would he give a dry response? Was I being too invasive? Who was I to ask about a project he clearly doesn’t want to share widely yet??

But after a few seconds, he said: do you want to see it? I have my development notebook here — if you have a few minutes, I can give you a demo.

I accepted immediately! He asked me to wait a moment so he could call two more people who were interested in seeing the demo. Soon the four of us gathered around a high table in the hall, where he opened his notebook and began presenting the project. After some time, the other two had to leave, and I was also leaving with them when he said: I have one more demo, don’t you want to see it? And once again, I enthusiastically said yes!

At that moment, he presented the demo only to me. I asked a few questions and after 40 minutes of conversation, I thanked him and said goodbye. Then he asked for my opinion about the product, whether I would use it. And he also asked for my opinion about the demo — whether it was good, and if the proposal of the project was clear.

There I was, in Poland, giving my personal feedback to one of my idols! What an indescribable experience!! Those 40 minutes alone made the whole trip to Poland worthwhile!

Was it worth it?

As you can imagine — yes, it was totally worth it!

Overall, it wasn’t a cheap trip. Far from it! There were the flight, accommodation, the event ticket… all paid with my own money, without any company support. Because of that, it’s hard to recommend a trip like this without some hesitation.

I loved it. I had fun, I learned, I discovered a new country, I made new friends… And maybe you will meet incredible people and get the job of your dreams? Maybe. But probably not. If that’s your only goal, I recommend searching online instead — in communities, social networks, writing articles or software…

So if you’re thinking about doing something similar, do it for pleasure. For fun. Only then is it truly worth it!

Did you like this article? Don't forget to leave a reaction! They serve as a big incentive for me to write others.

You can also discover more articles, podcasts and videos at: https://segunda.tech/tags/english.

And if you want, follow me on twitter, blue sky and Linkedin.

Como foi minha experiência na Lambda Days 2025

Marcio Frayze — Mon, 10 Nov 2025 23:56:51 +0000

O que é a Lambda Days?

A Lambda Days é uma conferência internacional dedicada a linguagens funcionais realizada todos os anos na Cracóvia (Polônia). O evento reúne pesquisadores, pessoas desenvolvedoras e entusiastas de comunidades como Erlang, Elixir, Scala, F#, Clojure, Haskell, Elm e muitas outras, criando um espaço de troca entre a academia e a indústria e tem duração de 2 dias.

Além das palestras técnicas, a Lambda Days também aborda temas como ciência de dados, sistemas distribuídos, inteligência artificial e boas práticas de desenvolvimento. O ambiente é bastante vibrante, reunindo participantes de diferentes países em uma das cidades mais bonitas e históricas da Europa.

O que me motivou a ir este ano?

Eu tinha 10 dias de férias para tirar e nenhum destino certo para ir. Todos os lugares que pensava em visitar pareciam ter muito potencial para uma viagem bacana, mas a indecisão tomava conta. Até que lembrei da sensação que tive quando vi que o Evan Czaplicki iria fazer uma apresentação nesta conferência!   Para quem não o conhece, Evan é criador da linguagem Elm e provavelmente o meu palestrante favorito! Sou grande admirador das suas capacidades técnicas, mas também fico igualmente impressionado e atento às ideias mais filosóficas que ele costuma incluir em seus discursos.

Sempre quis assistir uma palestra do Evan pessoalmente e nos últimos anos ele não tem feito muitas aparições públicas, estando mais focado no desenvolvimento da sua mais nova criação: Acadia. Por isso, quando vi que ele estaria lá, fiquei bem empolgado.

Outro ponto importante na decisão foi que, embora a Polônia não estivesse exatamente entre meus lugares prioritários para conhecer no mundo, me parecia ser um país bem interessante, bonito e com opções culturais, gastronômicas e turísticas muito distintas. Além de não ser um dos países europeus dos mais caros de se visitar.

Como é a cidade?

A Lambda Days ocorre todo ano na mesma cidade, Cracóvia. Eu gostei da escolha por várias razões. A primeira, como já mencionei, é econômica. Embora a Polônia seja membro da União Europeia desde 2004, ela nunca adotou o Euro e sua moeda oficial é a złoty (PLN). Isso pode dificultar algumas coisas, mas considerei o preço de tudo bastante convidativo, especialmente quando comparado com outros países mais ricos da Europa. O preço do hotel, comida, transporte público e dos gastos gerais do dia a dia não são muito acima dos preços que eu encontraria em uma viagem dentro do próprio Brasil.

A passagem, saindo do Brasil, também não é um preço exorbitante, especialmente se considerarmos que trata-se de uma viagem de 11 horas até Frankfurt e depois mais uma hora até Cracóvia (prefiro não colocar os valores de quanto paguei pois iria se desatualizar muito rapidamente).

Cracóvia é uma cidade linda! E como o evento ocorre no verão, o sol nasce super cedo e se põe bem à noite (foto tirada às 21:45h).

Me senti bastante seguro o tempo todo. Como a cidade é super plana, é perfeita para andar à pé ou de bicicleta. Além, claro, dos inúmeros trens de superfície (vulgo bondinhos) que percorrem a cidade toda! Através de um App no celular (ou de uma maquininha nos próprios pontos de parada) você pode comprar sua passagem. Eu acabei optando por usar um App e comprar passagem por tempo de uso. Assim, conseguia andar a cidade toda sem precisar me preocupar. Basta validar uma vez (digitando o número do vagão, que está impresso na parte de dentro, próximo das portas) e pronto! Dizem que existe bastante fiscalização (neste caso, basta mostrar que você validou sua passagem no App, caso contrário você será multado!), mas na prática não vi nenhum controle sobre isso. O preço também achei bastante aceitável (principalmente se comparado com que eu tinha que pagar quando visitei a Noruega… quase caí pra trás ao ver os preços do transporte público quando estive em Oslo!).

Aparentemente é bastante tranquilo chegar do aeroporto para a cidade usando trens (não os bondinhos - trens mesmo). Mas eu optei para usar Uber. Estava super cansado da viagem e me senti mais seguro optando por este meio de transporte.

Outro ponto de destaque é que Cracóvia possui algumas opções turísticas bastante únicas. Quando viajo, costumo optar mais por andar pela cidade e evitar um pouco passeios muito turísticos. Mas desta vez decidi conhecer Auschwitz 1 e Auschwitz 2 (Birkenau). É difícil descrever a sensação de estar em um lugar onde literalmente milhares de pessoas (em sua maioria judeus) morreram. Até agora não consigo acreditar. Não é o tipo de lugar que todas as pessoas vão querer visitar, mas se você tiver interesse e disposição, eu recomendaria conhecer.

Também fui na famosa Mina de Sal de Wieliczka. É um lugar bem bonito, mas provavelmente teria sido mais interessante ter ido para outras partes da cidade, como algum parque florestal mais afastado.

Outro ponto bastante famoso (e que me arrependo de não ter visitado) é a Fábrica de Schindler, que mostra o esforço feito por Schindler para salvar 1.200 judeus do Holocausto (quem assistiu o filme A Lista de Schindler deve conhecer um pouco desta história).

Optei por ficar apenas na Cracóvia, mas parece ser bastante fácil ir para outras cidades da Polônia de trem. Se pudesse voltar no tempo, organizaria um pouco melhor minha viagem e passaria alguns dias em Varsóvia, capital do país.

A única coisa que eu realmente não gostei na cidade foi a invasão dos “vapes” (cigarro eletrônico). Embora seja relativamente comum ver pessoal no Brasil com estes dispositivos (mesmo sendo proibido), na Cracóvia parecia que todo jovem adulto que estava na rua carregava um “vape” na mão. Uma verdadeira epidemia! E o mesmo era vendido em vários lugares da cidade. É uma cena um pouco triste, já que os problemas associados ao consumo deste tipo de produto já são bastante conhecidos.

Nível das palestras

Haviam 3 trilhas, com palestras acontecendo paralelamente. Algumas eram bem tranquilas de acompanhar, como o painel de discussão Learning How to Learn, onde quatro mulheres (incluindo uma brasileira!) contavam um pouco sobre a sua jornada para aprender, ensinar e crescer em suas carreiras em Programação Funcional.

Outras palestras eram mais filosóficas, como a keynote realizada pelo Evan Czaplicki, intitulada Rethinking our Adoption Strategy. Nesta, ele falou sobre o que ele chama de Platform Language e o que a diferencia de uma Productivity Language e o que nós, pessoas não relacionadas ao mundo dos negócios, poderíamos fazer para tornar as Platform Languages mais atrativas que as Productivity Languages.

Haviam ainda palestras em níveis mais abstratos, como o keynote de Moa Johansson: AI for Mathematical Discovery: Symbolic, Neural and Neuro-Symbolic Methods. Confesso que o nível desta (e de algumas outras palestras) estavam muito acima do que eu conseguia acompanhar. Sempre era possível tirar algum conhecimento novo, mas muita coisa eu não tinha capacidade de compreender totalmente. Outro exemplo foi a keynote do Martin Odersky, criador da linguagem de programação Scala, com o título Making Capabilities Safe and Convenient. Consegui entender os fundamentos, mas a partir de um determinado momento da palestra, me perdi e não conseguia mais acompanhar as propostas.  

Como eram 3 salas/trilhas com palestras acontecendo de forma concorrente, você tem a opção de escolher aquelas que julgar mais interessantes e que vai tirar mais proveito (menos às keynotes - essas ocorrem na sala maior e sem outras palestras no mesmo momento). Um erro que cometi foi não ter estudado melhor sobre as pessoas que iriam palestrar. Poderia ter feito escolhas mais interessantes e ter aproveitado mais conteúdos.

Comida boa!

  Estava incluso no evento o café da manhã, dois coffe-breaks (pela manhã e tarde) e um almoço. Isso é bem legal pois não precisava me preocupar com alimentação e também era um momento a mais que o pessoal utilizava para socializar, conversar e fazer (ou fortalecer) amizades. Achei tudo bastante organizado e gostoso.

  Festa / Happy hour

No final do primeiro dia ocorreu uma confraternização após o evento, em outro local. Para entrar bastava mostrar a credencial do evento.

Não tenho muitos detalhes de como foi, pois infelizmente eu não participei. Estava bastante cansado depois de um longo dia de palestras e acabei voltando para meu hotel. Mas me arrependo de não ter aproveitado esta oportunidade! Fiquei especialmente arrependido quando soube, através de algumas pessoas brasileiras que conheci no evento, que o José Valim (criador da linguagem Elixir) estava presente na festa! E que conseguiram conversar com ele! Ele não palestrou no evento e não o vi em nenhum momento, então fiquei surpreso ao saber que ele estava lá (e eu perdi a oportunidade de conhecê-lo…).

Primeira viagem com tanta tecnologia à minha disposição

Tive o privilégio de fazer várias viagens internacionais nas últimas décadas, desde Argentina, Chile, Uruguai, até Noruega, Suécia, Holanda, passando por Costa Rica, Estados Unidos, Cuba, … mas esta viagem para Polônia foi diferente.

Quando visitei Cuba, em 2009, fazer uma ligação telefônica para o Brasil era muito caro e restrito (fiz algumas vezes, de um telefone fixo do Hotel). Zero acesso à internet ou telefone celular. Em minha viagem para Holanda, em 2012, internet apenas quando conseguia uma wi-fi (usando meu iPhone 3GS!). A maior parte do tempo me locomovia olhando um mapa físico da cidade, nada de GPS.

Nesta viagem para Polônia, pela primeira vez tinha a minha disposição diversas tecnologias que facilitaram MUITO a estadia por lá!

Internet ilimitada

Antes de viajar eu já havia comprado um eSIM (um chip virtual de celular - coisa que ainda não é muito popular no Brasil) através do App da Holafly. O processo foi super simples e em pouco tempo tinha um segundo chip instalado em um iPhone 14. Assim que o avião parou na escala que eu precisava fazer na Alemanha, no aeroporto Internacional de Frankfurt, meu chip já passou a funcionar e eu já tinha acesso ilimitado à internet! WhatsApp funcionando normalmente e tudo mais que eu já estava acostumado a usar no Brasil. Pela primeira vez cheguei em outro país já com internet disponível em meu celular!

Uber

A Uber opera também na Polônia e me senti mais confortável e seguro utilizando o serviço deles para conseguir chegar em meu hotel. A rede de trens da Polônia é muito boa e com certeza eu conseguiria chegar usando apenas trens, já que o Hotel ficava perto de uma estação - coisa que eu deveria ter visto antes de chegar lá, mas não fiz! Meu planejamento deixou a desejar também neste ponto. De qualquer forma, o Uber me deixou na porta do hotel. Foi a primeira vez que não precisei me preocupar com nada para conseguir chegar tranquilo em meu primeiro destino em uma viagem internacional.

Acabei optando por utilizar o Uber também para voltar para o aeroporto. De resto, usei apenas o transporte público. Mas saber que eu tinha esta opção a qualquer momento, me deixava mais tranquilo para explorar a cidade à vontade.

Google Maps / GPS

O Google Maps funciona muito bem na Cracóvia e me ajudou demais a me locomover pela cidade usando os trens de superfície. Ele me avisava exatamente quando o trem iria chegar na estação, me mostrava quantas estações faltavam para descer e me alertava na hora exata de descer. Nunca foi tão fácil andar de transporte público em uma cidade desconhecida!  

Claro que mesmo assim eu me perdi alguma vezes haha. Na pressa entrava no trem no sentido errado e coisas do tipo. Mas era fácil perceber o erro ao olhar o mapa e, como as passagens que eu comprava eram por tempo, bastava descer e pegar o trem correto.

Chat GPT

Outra novidade foi viajar pela primeira vez com a possibilidade de usar tecnologias mais recentes de Inteligência Artificial Generativa, como o Chat GPT. Fazia algumas perguntas ao longo da viagem para tirar dúvidas sobre o funcionamento das coisas nesta cidade, ele me ajudou a encontrar lojas e também a encontrar alguns pontos bonitos para visitar.

Uma coisa que experimentei fazer algumas vezes foi tirar um print da tela do Google Maps de onde eu estava naquele momento e a enviava para o Chat GPT, pedindo dicas de lugares para visitar naquela região, ou dicas de lojas onde eu poderia comprar determinadas coisas que eu estava buscando. O resultado foi bem legal!   Se não fosse ele, eu não teria conhecido, por exemplo, o Kościuszko Mound. Estava ao lado dele mas não estava na minha lista de lugares para conhecer. Fiz o processo que citei acima e ele me recomendou ir para lá, e achei bem legal!

Oportunidades de conversas incríveis

Como disse lá no começo, minha maior motivação para ir neste evento era assistir a palestra do Evan Czaplicki e, claro, tinha expectativas dele falar um pouco sobre seu novo projeto, que poucas pessoas tiveram acesso. Quando vi o título da palestra, já imaginei que este não seria o foco - e realmente não foi. Mas e nos bastidores?

  Durante os dois dias de evento, ele estava conversando com as pessoas do evento, no hall onde ficava o coffee-break. No primeiro dia eu ensaiei abordá-lo para fazer algumas perguntas, mas minha timidez venceu mais uma vez e fui para o hotel me sentindo derrotado! Lá, disse para mim mesmo: você veio até aqui por conta disso! Se ele estiver lá amanhã, você vai sim falar com ele!!

E para minha alegria, no dia seguinte ele estava lá novamente, conversando com pessoal. Mais uma vez fiquei com muita vergonha, mas tomei coragem e me aproximei. Não sabia como abordá-lo, apenas cumprimentei ele e a pessoa com quem ele estava conversando com um aceno de cabeça e aguardei a minha vez de falar enquanto, por algum motivo, eles conversavam sobre a cultura japonesa.

Em um determinado momento ele se virou pra mim e fez um gesto indicando um início de conversa. Me apresentei, agradeci pela palestra, elogiei seu trabalho como programador mas também como palestrante e filosofo, e disse que me inspirava muito em suas palestras. Trocamos algumas palavras e logo depois perguntei sobre seu novo projeto de backend “secreto”. Fiz alguma pergunta meio genérica sobre do que se tratava e ele ficou pensativo por uns segundos. Fiquei preocupado, confesso. Será que iria receber uma resposta meio atravessada? Será que eu estava sendo muito invasivo? Quem era eu para perguntar sobre um projeto dele que eu sei que ele não está querendo ainda compartilhar com muitas pessoas??  

Mas após alguns segundos, ele responde: você quer ver? Estou com meu notebook de desenvolvimento aqui, se você tiver uns minutos livre eu posso fazer uma demo pra você.

Aceitei na hora! Ele pediu para esperar um pouco, que ele iria chamar mais 2 pessoas que estavam interessadas em ver a demo. Logo nos juntamos em uma mesa alta, ali no hall mesmo, onde ele abriu o note e começou a apresentar o projeto. Depois de algum tempo as outras duas pessoas tiveram que sair, e eu estava saindo junto com elas quando ele disse: tenho mais uma demo, não quer ver? E mais uma vez, aceitei entusiasticamente!

Neste momento ele passou a apresentar a demo apenas para mim. Tirei algumas dúvidas e depois de 40 minutos de conversa, agradeci e me despedi. Nisso ele pergunta a minha opinião sobre o produto, se eu usaria. E em seguida também pergunta minha opinião sobre a demo, se estava boa, se dava para entender a proposta do projeto.

  Estava eu lá na Polônia, dando minha opinião pessoal para um dos meus ídolos! Que experiência indescritível!! Esses 40 minutos de conversa já fizeram a ida para Polônia valer a pena!

Valeu a pena?

Como você já deve imaginar, sim, valeu muito a pena!

Somando tudo, não foi uma viagem barata. Longe disso! Teve preço da passagem, estadia, ingresso do evento... Tudo pago com dinheiro próprio, sem auxilio da empresa onde trabalho. Por isso, é difícil indicar uma viagem dessas.

Eu adorei. Me diverti, aprendi, conheci um país diferente, fiz novas amizades... E talvez você conheça pessoas incríveis e consiga o emprego dos seus sonhos? Talvez. Mas é mais provável que não. Se este é seu único objetivo, recomendo que busque na internet mesmo. Nas comunidades, nas redes sociais, escrevendo artigos ou softwares, ...

Então se você está pensando em fazer algo parecido, faça por prazer. Por diversão. Aí sim, vale muito a pena!

Launch of the Edudu App for iOS and Android

Marcio Frayze — Thu, 06 Jun 2024 19:20:11 +0000

Release of Edudu

It is with great pleasure that I announce the launch of the Edudu App for iOS and Android!

In this article, I present the Edudu app and discuss the technologies I chose to develop this project.

What is Edudu?

If you are a teacher looking for a more efficient way to manage your classes, students, and attendance records, Edudu is the app you have been waiting for!

Key Features

Class, Student, and Lesson Registration: Create and manage multiple classes, keeping all important information organized in one place. Quickly and easily register your students.
Class Diary: Record all your lessons and keep track of your students' attendance in a simple and effective way.
Cloud Storage: All data is securely stored in the cloud, ensuring easy access and protection against data loss.
Intuitive and Easy-to-Use Interface: Edudu was developed with ease of use in mind, providing an intuitive experience for users.

Technologies

To implement this product, I chose:

Dart/Flutter: I chose the Dart language and the Flutter framework because I already have experience with these technologies and was looking for a solution that would allow the creation of an app for both iOS and Android without needing to create two separate codes.
Firebase Authentication: Everyone with a smartphone has a Google or Apple account. To facilitate the login process, I use Firebase Authentication for user authentication.
Cloud Firestore: I wanted the data to be maintained in the cloud (not just locally on the user's device). The Firestore database was an almost natural choice. It integrates easily with Firebase Authentication, is secure, fast, and requires minimal maintenance.
Firebase Crashlytics: Every app needs a mechanism for monitoring failures. Crashlytics fulfills this function very well.

The main challenge that led me to choose these technologies was the fact that I was developing this app alone. I was looking for solutions that would allow the construction of a product with reduced effort but with a strong foundation for long-term evolution. Flutter + Firebase proved to be a very good combination for this scenario!

In the coming months, I intend to write some articles sharing more about this journey.

Where can you find it

The app is free and available on the Apple Store and Google Play.

Lançamento do App Edudu

Marcio Frayze — Thu, 28 Mar 2024 20:11:25 +0000

É com muito prazer que anuncio o lançamento do App Edudu para iOS e para Android!

Neste artigo apresento o App e discorro um pouco sobre as tecnologias que escolhi para desenvolver este projeto.

O que é o Edudu?

Se você é um professor ou professora em busca de uma maneira mais eficiente de gerenciar suas turmas, alunos e registros de presença, o Edudu é o aplicativo que você estava esperando!

Principais recursos do App:

Cadastro de Turmas, Alunos e Aulas: Crie e gerencie múltiplas turmas, mantendo todas as informações importantes organizadas em um só lugar. Cadastre seus alunos de forma rápida e fácil.
Diário de Classe: Registre todas as suas aulas e mantenha o controle das presenças dos seus alunos de forma simples e eficaz.
Armazenamento na Nuvem: Todos os dados são armazenados de forma segura na nuvem, garantindo acesso fácil e proteção contra perda de informações.
Interface intuitiva e fácil de usar: O Edudu foi desenvolvido pensando na facilidade de uso, proporcionando uma experiência intuitiva para os usuários.

Tecnologias utilizadas

Para implementar este produto, optei por usar:

Dart/Flutter: escolhi a linguagem Dart e o framework Flutter pois já tenho experiência com estas tecnologias e buscava uma solução que permitisse a criação de um App para iOS e para Android sem a necessidade de criar 2 códigos separados.
Firebase Authentication: toda pessoa que possui um smartphone tem uma conta da Google ou da Apple. Para facilitar o login, utilizo o Firebase Authentication para fazer a autenticação do usuário.
Cloud Firestore: queria que os dados fossem mantidos em uma nuvem (e não apenas localmente no dispositivo da pessoa). O banco de dados Firestore foi quase uma opção natural. É fácil de integrar com o Firebase Authentication, seguro, rápido e não exige grandes manutenções.
Firebase Crashlytics: todo App precisa de algum mecanismo de monitoração de falhas. O Crashlytics cumpre esta função muito bem.

O principal obstáculo que me levou a escolher estas tecnologias foi o fato de estar desenvolvendo este App sozinho. Buscava soluções que permitissem a construção de um produto com um esforço reduzido, mas com uma fundação forte que permita uma evolução à longo prazo. Flutter + Firebase se mostrou uma dupla muito boa para este cenário!

Nos próximos meses pretendo escrever alguns artigos contando um pouco mais sobre esta jornada.

Onde baixar??

O App é gratuito e encontra-se disponível na Apple Store e na Google Play.

How I developed a web backend in Clojure

Marcio Frayze — Thu, 06 Jul 2023 13:54:05 +0000

One of my students from the course Clojure: Introduction to Functional Programming (Brazilian Portuguese only) asked an interesting question:

Hello teacher, I would like to know about the deployment of an application, with a frontend sending requests and getting responses (as in the case of the shopping cart, for example). I'm enjoying the course, but I think a minimal application with a front-end or a service implementation would bring us closer to "real world" usage.

Although the question is quite outside the scope of the course (which focuses on the concepts of the functional paradigm - the language is just a detail), it is understandable. It is natural to want to know how to apply the new concepts in practice.

I answered the student, but decided to write this article so I could give a better and more complete response. I will not show how to create a REST service in Clojure step by step, but will give some possible paths, aiming to facilitate the journey of those interested in this topic.

Throughout this article I show what was my train of thought during the implementation of a REST backend in Clojure that I started developing last year and that I continue to support and add features to this day.

Single Page Application or Server Side?

One of the decisions I had to make early on was whether to render the HTML on the backend and use a fullstack Clojure framework or whether to implement a SPA, using Clojure only on the backend (through REST services).

Clojure supports both approaches. And when choosing to develop a SPA, you can even use Clojure to implement the frontend as well, using ClojureScript!

But I chose to use Clojure only on the backend and developed the frontend using my favorite programming language: Elm.

I wanted to use only functional languages in my stack and since (at least for now) Elm is focused on frontend development, I needed another language for the backend. As I already wanted to explore the use of the Elm Land framework and the Elm UI library, I chose to create a SPA in Elm and use Clojure only on the backend.

But if you want to, it is possible to implement the whole solution in Clojure.

Frameworks or libraries?

In many languages it is common to have web frameworks that includes various functionalities. Anyone who has ever programmed in Java has probably studied Spring or Quarkus. In Ruby we have the famous Ruby on Rails, in PHP there are solutions like Laravel and Symfony (or even the infamous Wordpress), and many others. But there are also many libraries.

It's hard to segment and define what makes a piece of technology to be a framework or a library, and I won't try to do that here. For this article, just consider that while a framework tries to solve many different types of problems, a library tends to have a much smaller scope. Thus, in general, it is necessary to compose a set of libraries to solve a larger problem.

As examples of libraries, in Ruby I could mention Sinatra, for Java/Kotlin Spark, and many others.

And as you might guess, there are also frameworks and libraries for web development in Clojure. And one famous framework is Luminus.

Luminus

Luminus defines itself as a micro-framework based on a set of lightweight libraries. This is a relatively common feature among web frameworks: putting together several small libraries in a cohesive and well-integrated way that, together, have everything usually needed to implement a complete web solution.

I recommend learning the basics of Luminus to see what is possible to do in Clojure. With it, you can easily create a well-organized project with all the features currently expected in a modern web framework, including a migrations system for the database schema, automated tests, environment-specific configurations, some helpers to interact with the database, etc.

But, while very interesting, it seems to me that this approach is not popular within the Clojure community. What I have observed is that, in general, Clojure developers tend to prefer to choose some libraries and build their own framework, according to their needs.

And this was also the path I chose to follow: creating my own customized framework for the needs of my project. In part, I went this way because what I had to build wasn’t that complicated. So I took the opportunity to venture into the various libraries of the Clojure universe!

Selecting the libraries

Automation and dependency management

I chose Leiningen to manage project dependencies and automate tasks like running automated tests, generating the project build (Uberjar), running the REPL terminal (Read-Eval-Print Loop), etc.

If you come from the Java world, think of Leiningen as an alternative to Apache Maven or Gradle.

There are other similar tools, but Leiningen seems to be the most used by the Clojure community and it works fine.

HTTP server

To develop a web application it is necessary, of course, to have a server to receive the requests. For this, I chose the Ring library.

For those familiar with Python, you might think that Ring would be something equivalent to WSGI (Web Server Gateway Interface) and developers used to Ruby might associate it with Rack.

Ring is simple but very low-level and can be tricky to set up. I chose to use the Ring-Defaults library, which aims to provide a secure initial configuration that meets most cases. This way it was very easy to configure Ring and create my first REST service in Clojure.

Route management

Ring is so slim that it doesn't even have a route management system! So I needed to add a library for this purpose.

For this, I chose to use Compojure. It is a very simple library, which adds some functionalities to Ring related to routes creation.

Creating a /hello-world endpoint using Compojure is straightforward:

(defroutes app
  (GET "/hello-world" [] "<h1>Hello World</h1>"))

For complex services you can (and should) delegate the processing of the requests to other functions.

Connecting to the database (PostgreSQL)

With the libraries listed above, it is possible to create a simple server and reply the requests. But most projects will need more than that.

A common need is to communicate with a database. In my case, I needed to access a PostgreSQL database.

I chose to use the clojure.java.jdbc library. But note that although this library is still maintained (the author continues to apply bug fixes and minor releases), it is described on the website as being "Stable" (no longer "Active") and they recommend using next-jdbc instead.

Therefore, in a new project, I would give priority to this other library (and it is in my plans to migrate the project to it in the future).

PostgreSQL

The clojure.java.jdbc library is agnostic and can be used on any database with JDBC support (Java Database Connectivity). To connect to a PostgreSQL database, I also needed to include org.postgresql/postgresql.

Connection Pooling

The two libraries I mentioned above are enough to connect and execute queries in the database but, for performance reasons, it is important to use a pool of connections. For that I use and recommend hikari-cp. I already used it when programming in Java and it always worked fine.

Creating the queries

Developers familiar with object-oriented programming languages (such as Java and C#) should be used to ORM (Object Relational Mapper) tools like Hibernate or Entity Framework. But within the Clojure community, I don't see this type of tool being used much. In the context of Clojure, it is more natural for a database call to return a data structure, such as a map.

I chose to write the SQL code manually in a few complex queries, but for most cases I use the Honey SQL library. With it, you can build queries as if they were Clojure data structures.

An example would be:

(defn query-select-audit-xpto-by-user-id
  [user-id]
  (-> (h/select :created_at
                :remote_address
                [[:raw "request_headers->'x-alias'"] :alias])
      (h/from :audit)
      (h/where [:= :user_id user-id]
               [:= :path "/api/xpto/"]
               [:= :response_status 200]
               [:= :method "GET"])
      (h/order-by [:id :desc])
      sql/format))

Note that this function does not execute the query, it just generates the SQL command, therefore it is a pure function. When you run it, the result will be:

(query-select-audit-xpto-by-user-id "123.456.789-01")

;; Result:
["SELECT created_at, remote_address, request_headers->'x-alias' AS alias FROM audit WHERE (user_id = ?) AND (path = ?) AND (response_status = ?) AND (method = ?) ORDER BY id DESC" "123.456.789-01" "/api/xpto/" 200 "GET"]

To actually process it, you have to call the jdbc/with-db-connection function from the clojure.java.jdbc library, passing the query as a parameter. Before that, of course, you must configure the user, password and address of the database, in addition to the connection pool configuration. But that is beyond the scope of this article.

JSON

JSON is used very often in web projects. To facilitate the parsing (and generation) of this format, I use the data.json library.

Its use is quite simple:

(json/write-str {:a 1 :b 2})
;; Result:
"{\"a\":1,\"b\":2}"

(json/read-str "{\"a\":1,\"b\":2}")
;; Result:
{"a" 1, "b" 2}

Performing HTTP calls

In addition to receiving HTTP requests, I needed to integrate with other systems through REST services (another very common need in distributed web applications).

For that I used the library clj-http and its use is quite simple. To make a GET call, just run something like:

(client/get "https://example.com/resource/1234" {:accept :json})

Caching

The system I developed executes a few heavy queries in a large database, to generate some reports. But while those processing are costly, the end result is not a huge amount of data and it doesn't need to be fully up-to-date all the time. Therefore, some of these operations may be cached in memory.

For that, I used the clojure.core.cache library.

Although this library works well, I found its interface a bit confusing. To work around this I created my own abstraction. After some tweaks, I managed to create some functions that, although they hide some of the more advanced library functionalities, make the creation of caches quite easy.

Asynchronous calls

At a certain point I needed to integrate with the Microsoft Teams chat (through an HTTP call). As I mentioned above, I use clj-http for this. But I wanted this part of the system to be asynchronous (non-blocking). For this I use the core.async library.

For those familiar with the Go programming language, this library works similarly to the famous Goroutines. That is, it is a lightweight thread.

Turning a blocking function into non-blocking is very easy: just pass the expressions/functions you want to run in parallel to the async/go function. In the case of an HTTP call, it would be something like:

(async/go
  (try
    (client/post webhook-teams-url
                 {:body (json/write-str {"text" "A message to MS Teams"})
                  :headers {"content-type" "application/json"}
                  :socket-timeout 3000
                  :connection-timeout 3000})
    (catch Exception e
      (println (str "Failed to send message to Teams: " e)))

Scheduler

Another common need for a web application, and which I also needed to do, is scheduling the execution of tasks that must be executed periodically (in my case, executing a function every 10 minutes). For this purpose, I chose to use the Chime library.

Although it is relatively simple, as with the cache library, I initially found it hard to understand how to use it. It's nothing too complex, but I found the documentation a bit confusing. Again I was able to isolate this part of the code in a more specific function and it worked. I had no more problems with it.

Mocks and automated tests

I'm a fan of TDD, so I also wanted to create automated tests.

In the beginning I chose to implement, in addition to the most basic unit tests, several integrated tests. For that I used the Ring-Mock library to mock the web server. I also created a test double for the function that accessed the database.

Over time I began to have trouble maintaining these tests, which broke in non-trivial ways. Another big problem was that when trying to practice TDD I missed a type system to create the asserts.

Sometimes I created the entire end-to-end scenario, but at runtime, when I was running the application and connecting to the real database, the returned type was different from what I was imagining. And again, it was frustrating at times to pinpoint exactly where the problem lay. The error messages were not always meaningful.

Over time I chose to minimize (at least for now) this type of test. I try to maximize the amount of pure functions and focus my tests on them. I miss testing some layers of the application, which is something I still need to experiment and explore further.

Isolating the pure functions

I don't want to go into too much detail about the software architecture in this article, but it's pretty straightforward. Each use case (service) has its own folder, and the pure and impure functions are in different namespaces. I strive to transform impure functions into pure ones and make those impure ones into orchestrators.

Functions that cause some kind of side effect should be as "dumb" as possible. For example: a function that executes a query in the database cannot have any business logic. Same for a function that performs an HTTP call, etc.

I already considered this to be a good practice when programming in other languages, but in Clojure (due to its functional-first approach), it becomes effortless and natural to do so.

Over time, I ended up decreasing the number and even eliminating some integrated tests and increasing the amount of unit tests. For my context, this worked fine, but sometimes I still miss broader tests.

Dependency injection

Developers used to languages like Java or C# might search for a dependency injection library so they can practice inversion of control.

To achieve this goal in Clojure, all I've needed so far is to pass function references as parameters. If a function needs, for example, to execute a query in the database, I pass as a parameter the reference to the function that, when receiving an SQL command, executes it and returns the result. I do the same for HTTP calls or other forms of side effects.

In the context of my application, this was enough. If I need to create a test double (mock/spy/stub), I just pass the reference of another function as a parameter, avoiding coupling with external layers (such as a database or other systems) in the tests and giving full control over the return in these calls, allowing me to write asserts that won't break over time. This way my tests can also run concurrently, in addition to being very fast.

Hosting

One of the great advantages of Clojure - and one of the main reasons I chose it - is the fact that it is a language that runs on the JVM (Java Virtual Machine). The end result is an Uberjar (a jar file with -standalone.jar suffix) containing all the application and project dependencies.

And it is possible to start the server with the following command line:

java -jar target/project-name-0.0.1-SNAPSHOT-standalone.jar

In my case, I'm using an on-premise private cloud. And an interesting point is that this cloud already supported the Java platform and I had already developed many solutions in this language. Migrating to Clojure was trivial, not having to make any infrastructure changes. For the operations team, it's completely transparent.

So applications developed the way I described in this article can be hosted on any server that supports Java! 🎉

Bonus: Updating dependencies

A concern I always have in every project is to avoid rusting. It is a natural process in every application, so it needs constant attention. And at least for some of these types of problems, the process can be automated!

Leiningen has a command that checks for outdated dependencies and, if it finds any, is able to update them and then run the automated tests. If any tests fail, the change is undone and an error message is displayed indicating the problem.

This feature helps me daily! I usually start my day running it to make sure the project's dependencies are always up to date.

The command in question is:

lein ancient upgrade :interactive :check-clojure

But to be able to run it, you need to configure the lein-ancient plugin.

My current project.clj

All Leiningen configuration is done in the project.clj file.

Below I share how my project is set up at the time I write this article. In addition to the libraries I've presented here, I use a few other settings that I didn't find relevant enough to highlight, but that might be useful for some people.

(defproject project-name "1.0.0-SNAPSHOT"
  :description "Here would be the description of the project."
  :url "https://git-repository-address"
  :min-lein-version "2.10.0"
  :dependencies [[org.clojure/clojure "1.11.1"]
                 [compose "1.7.0"]
                 [ring/ring-defaults "0.3.4"]
                 [com.github.seancorfield/honeysql "2.4.1045"]
                 [org.clojure/java.jdbc "0.7.12"]
                 [org.postgresql/postgresql "42.6.0"]
                 [hikari-cp "3.0.1"]
                 [org.clojure/data.json "2.4.0"]
                 [org.slf4j/slf4j-simple "2.0.7"]
                 [clj-http "3.12.3"]
                 [org.clojure/core.cache "1.0.225"]
                 [jarohen/chime "0.3.3"]
                 [org.clojure/core.async "1.6.673"]]
  :plugins [[lein-ring "0.12.6"]
            [lein-ancient "0.7.0"]
            [lein-cloverage "1.2.2"]]
  :ring {:handler a.namespace.routes/app}
  :repl-options {:init-ns a.namespace.whatever.logic}
  :profiles
  {:dev {:dependencies [[javax.servlet/servlet-api "2.5"]
                        [ring/ring-mock "0.4.0"]]}})

Conclusions

Clojure, plus all the libraries that I showed throughout this article, served me very well. I managed to create an architecture that is both simple and easy to add new services. The server consumes few resources and has a very good performance.

Choosing to create my own framework, selecting each library separately, initially took some time. I had to test each one of them, discard the ones that didn't meet my needs and create some code to "glue" these libraries together.

Using a full framework (like Luminus) would probably increase my productivity in the first few iterations, but since it's a project I hope to keep for many years, having full control over every part of it is probably the ideal scenario.

The Clojure community seems to have a culture of crafting small, well-defined purpose libraries. I believe that this characteristic, plus the fact that Clojure is a functional-first language, made this process much easier. These two features together allowed me to be able to create large abstractions by just using function composition, without adding too much complexity.

But it's important to make it clear that this is a small project, where I didn't need to use any fancy architecture. I didn't cover anything like Domain-driven design, Hexagonal Architecture, Microservices, ... So I can't say that Clojure (or even the functional paradigm) would be a good fit for complex scenarios. But so far, I'm not regretting the choice and, if it's up to me, I won't be programming in an object-oriented language again anytime soon! 😇

Did you like this article? Don't forget to leave a reaction! They serve as a big incentive for me to write others.

You can also discover more articles, podcasts and videos at: https://segunda.tech/tags/english.

And if you want, follow me on twitter, blue sky and Linkedin.

Como desenvolvi um backend web em Clojure

Marcio Frayze — Mon, 03 Jul 2023 11:45:35 +0000

Um dos meus alunos do curso Clojure: Introdução à Programação Funcional fez uma pergunta interessante:

Olá professor, gostaria de informações sobre o deploy de uma aplicação, com um frontend enviando solicitações e obtendo repostas (como no caso do carrinho de compras, por exemplo). Estou gostando do curso, porém acho que uma construção mínima com um front-end ou implementado um service nos aproximaria mais do uso "no mundo real".

Embora a pergunta fuja bastante do escopo do curso (cujo foco são os conceitos do paradigma funcional - a linguagem em si é um detalhe), é uma dúvida bastante compreensível. É natural querer saber como aplicar os conhecimentos na prática.

Respondi o aluno, mas resolvi criar este artigo para poder explicar de forma mais completa. Não irei mostrar o passo a passo de como criar um serviço REST em Clojure, mas vou dar alguns caminhos possíveis, visando facilitar a trajetória daquelas pessoas interessadas neste tema.

Ao longo do artigo mostro como foi a minha linha de raciocínio para implementar um backend REST em Clojure que comecei a desenvolver ano passado e que continuo sustentando e adicionando funcionalidades.

Single Page Application ou Server Side?

Uma das decisões que precisei tomar logo no início foi se iria renderizar o HTML no backend e utilizar um framework Clojure fullstack ou se iria implementar um SPA, utilizando o Clojure apenas no backend (através de serviços REST).

Clojure permite as duas abordagens. E ao escolher desenvolver um SPA, você pode até mesmo utilizar Clojure para implementar também o frontend, utilizando ClojureScript!

Mas optei por utilizar Clojure apenas no backend e desenvolvi o frontend utilizando minha linguagem de programação favorita: Elm.

Queria utilizar apenas linguagens funcionais em toda a stack e como (pelo menos por enquanto) Elm é uma linguagem focada no desenvolvimento de frontends, precisava de outra linguagem para o backend. Como já queria explorar o uso do framework Elm Land e a biblioteca Elm UI, optei por criar um SPA em Elm e utilizar Clojure apenas no backend.

Mas é possível implementar toda a solução em Clojure, caso você ache interessante.

Frameworks ou bibliotecas?

Em muitas linguagens é comum existirem frameworks web que agregam diversas funcionalidades. Quem já programou em Java provavelmente já estudou sobre o Spring ou Quarkus. Já em Ruby temos o famoso Ruby on Rails, no PHP existem soluções como Laravel e Symfony (ou ainda o famigerado Wordpress), entre tantos outros possíveis exemplos. Mas existem também muitas bibliotecas.

É difícil segmentar e definir o que faz com que uma tecnologia seja considerada um frameworks ou uma biblioteca, e não vou tentar fazer isso aqui. Para este artigo, basta considerar que enquanto um framework tenta resolver diversos tipos diferentes de problemas, uma biblioteca costuma ter um escopo bem mais reduzido. Desta forma, em geral, é necessário compor um conjunto de bibliotecas para solucionar um problema maior.

Como exemplos de bibliotecas para o universo web, no Ruby poderia citar o Sinatra, para Java/Kotlin o Spark, entre muitos outros.

E como você deve imaginar, existem também frameworks e bibliotecas para desenvolvimento web em Clojure. E um framework famoso é o Luminus.

Luminus

O Luminus se classifica como um micro-framework Clojure, baseado em um conjunto de bibliotecas leves. Esta é uma característica relativamente comum entre os frameworks web: juntar diversas pequenas bibliotecas de forma coesa e bem integrada que, juntas, possuem tudo que normalmente é necessário para implementar uma solução web completa.

Vale muito a pena conhecer este projeto e ver o que é possível fazer em Clojure. Com ele, você poderá criar facilmente um projeto muito bem organizado e com todas as funcionalidades esperadas atualmente, incluindo um sistema de migrations do schema do banco de dados, testes automatizados, configurações separadas por ambientes, algumas facilidades para interagir com banco de dados, etc.

Mas, embora muito bacana, me parece que esta não é uma abordagem tão popular dentro da comunidade Clojure. O que tenho observado é que, em geral, as pessoas desenvolvedoras Clojure costumam preferir escolher algumas bibliotecas e montar o seu próprio framework, de acordo com suas necessidades.

E este também foi o caminho que escolhi seguir: criar o meu próprio framework customizado para as necessidades do meu projeto. Em parte, segui este caminho pois o que precisava construir não era algo tão complexo assim. Aproveitei então para me aventurar nas diversas bibliotecas do mundo Clojure!

Selecionando as bibliotecas

Automação e gestão de dependências

Escolhi o Leiningen para gerenciar as dependências do projeto e automatizar tarefas como executar testes automatizados, gerar a build (Uberjar) do projeto, executar o terminal do REPL (Read-Eval-Print Loop), etc.

Se você vem do mundo Java, pense no Leiningen como sendo uma alternativa ao Apache Maven ou Gradle.

Existem outras ferramentas similares, mas o Leiningen parece ser a mais utilizada no universo Clojure e atendeu bem minhas necessidades.

Servidor HTTP

Para desenvolver uma aplicação web é necessário, claro, ter um servidor para receber as requisições. Para isso, escolhi a biblioteca Ring.

Para quem conhece Python, pode pensar que Ring seria algo equivalente ao WSGI (Web Server Gateway Interface) e o pessoal acostumado com Ruby pode associá-la ao Rack.

Ring é uma biblioteca simples, mas de baixo nível de abstração. Por isso pode ser um pouco complicada de configurar. Optei então por utilizar a biblioteca Ring-Defaults, que tem como objetivo prover uma configuração inicial segura e que atenda a maioria dos casos. Com ela foi muito fácil configurar o Ring e criar meus primeiros serviços REST.

Gerenciador de rotas

Ring é tão enchuta que não conta nem mesmo com um sistema de gerenciamento de rotas! Então precisei acrescentar uma biblioteca para esta finalidade.

Para isso, escolhi utilizar a Compojure. Trata-se de uma biblioteca bastante simples, que acrescenta algumas facilidades ao Ring relacionadas à criação de rotas.

Criar um endpoint /ola-mundo utilizando a Compojure é bastante fácil:

(defroutes app
  (GET "/ola-mundo" [] "<h1>Olá Mundo</h1>"))

Mas claro que para serviços mais complexos você pode (e deve) delegar o processamento das requisições para outras funções.

Conectando ao banco de dados (PostgreSQL)

Com as bibliotecas listadas acima, já é possível criar um servidor simples e retornar as requisições. Mas a maioria dos projetos vai precisar mais do que isso.

Uma necessidade comum é se comunicar com um banco de dados. No meu caso, precisava acessar um banco PostgreSQL.

Optei por utilizar a biblioteca clojure.java.jdbc. Mas note que, embora esta biblioteca ainda seja mantida (o autor continue aplicacando patchs de correções), ela está descrita no site como sendo "Estável" (não mais "Ativa"). O site ainda recomenda que em seu lugar seja utilizada a next-jdbc.

Portando, em um projeto novo, eu daria prioridade à esta outra biblioteca (e está em meus planos migrar o projeto para ela no futuro).

PostgreSQL

A biblioteca clojure.java.jdbc é agnostica e pode ser usada em qualquer banco de dados com suporte ao JDBC (Java Database Connectivity) e para conseguir me conectar ao banco PostgreSQL, também precisei utilizar a org.postgresql/postgresql.

Pool de conexões

As duas bibliotecas que citei acima são suficientes para conectar e executar queries no banco mas, por questões de performance, é importante utilizar um pool de conexões. Para isso utilizei e recomendo a hikari-cp. Já utilizava ela quando programava em Java e sempre me atendeu muito bem.

Criando as queries

Pessoas que estão acostumadas com Java, C# e similares, devem estar habituadas a utilizar ferramentas de ORM (Object Relational Mapper) como Hibernate ou Entity Framework. Mas dentro da comunidade Clojure, não vejo este tipo de ferramenta sendo muito utilizada. No contexto de Clojure, é mais natural que uma chamada ao banco retorne uma estrutura da dados, como um mapa.

Optei por escrever o código SQL manualmente em algumas poucas queries mais complexas, mas para a maioria dos casos utilizei a biblioteca Honey SQL. Com ela é possível construir as queries como se fossem estruturas de dados Clojure.

Um exemplo seria:

(defn query-select-auditoria-xpto-por-cpf
  [cpf]
  (-> (h/select :created_at
                :remote_address
                [[:raw "request_headers->'x-alias'"] :alias])
      (h/from :auditoria)
      (h/where [:= :cpf cpf]
               [:= :path "/api/xpto/"]
               [:= :response_status 200]
               [:= :method "GET"])
      (h/order-by [:id :desc])
      sql/format))

Note que esta função não executa a query, apenas gera o comando SQL, sendo portanto uma função pura. Ao executá-la, o seu resultado será:

(query-select-auditoria-xpto-por-cpf "123.345.789-01")

;; Resultado:
["SELECT created_at, remote_address, request_headers->'x-alias' AS alias FROM auditoria WHERE (cpf = ?) AND (path = ?) AND (response_status = ?) AND (method = ?) ORDER BY id DESC" "123.345.789-01" "/api/xpto/" 200 "GET"]

Para processá-la de fato, é necessário chamar a função jdbc/with-db-connection da biblioteca clojure.java.jdbc, passando a query que deseja executar como parâmetro. Antes disso, claro, precisa configurar usuário, senha e endereço do banco, além do pool de conexões. Mas isso já foge do escopo deste artigo.

JSON

O padrão JSON é utilizado com muita frequência em projetos web. Para facilitar o parsing (e geração) deste formato, utilizo a biblioteca data.json.

Seu uso é bastante simples:

(json/write-str {:a 1 :b 2})
;; Resultado:
"{\"a\":1,\"b\":2}"

(json/read-str "{\"a\":1,\"b\":2}")
;; Resultado:
{"a" 1, "b" 2}

Executando chamadas HTTP

Além de receber requisições HTTP, eu precisava me integrar com outros sistemas através de serviços REST (outra necessidade bastante comum em aplicações web distribuídas).

Para isso utilizei a biblioteca clj-http e seu uso é bastante simples. Para fazer uma chamada GET, basta executar algo como:

(client/get "https://exemplo.com/recurso/1234" {:accept :json})

Caching

O sistema que desenvolvi executa algumas queries pesadas no banco, para geração de relatórios. Mas embora o processamento seja oneroso, o resultado final não é um volume grande de dados e não precisa estar totalmente atualizado o tempo todo. Por isso, algumas destas operações podem ser cacheadas em memória.

Para isso, utilizei a biblioteca clojure.core.cache.

Embora esta biblioteca funcione bem, achei a sua interface um pouco confusa. Para contornar isso criei a minha própria abstração. Depois de alguns ajustes, consegui criar algumas funções que, embora escondam algumas funções mais avançadas da biblioteca, tornam a utilização do cache bastante simples.

Chamadas assíncronas

Em um determinado momento precisei fazer uma integração com o chat do Microsoft Teams (através de uma chamada HTTP). Como já mencionei acima, utilizei a clj-http para isso. Mas queria que esta parte do sistema fosse assíncrona (não bloqueante). Para isso utilizei a biblioteca core.async.

Para quem conhece a linguagem Go, esta biblioteca funciona de forma parecida com as famosas Goroutines. Ou seja, é uma lightweight thread.

Tornar uma função bloqueante em não-bloqueante é muito fácil: basta passar as expressões/funções que deseja executar em paralelo para a função async/go. No caso de uma chamada HTTP, seria algo como:

(async/go
  (try
    (client/post url-webhook-teams
                 {:body (json/write-str {"text" "Uma mensagem para o MS Teams"})
                  :headers {"content-type" "application/json"}
                  :socket-timeout 3000      
                  :connection-timeout 3000})
    (catch Exception e
      (println (str "Falha ao tentar enviar mensagem para o Teams: " e)))

Agendamento de execuções (scheduler)

Outra necessidade comum de uma aplicação web, e que também precisei fazer, é o agendamento de execução de tarefas que devem ser executadas de forma periódicas (no meu caso, executar uma função a cada 10 minutos). Para esta finalidade, utilizei a biblioteca Chime.

Embora seja relativamente simples, assim como ocorreu com a biblioteca de cache, inicialmente tive um pouco de dificuldade para entender como utilizá-la. Não é nada muito complexo, mas achei a documentação um pouco confusa. Novamente consegui isolar esta parte do código em uma função mais específica e deu tudo certo. Não tive mais problemas com ela.

Mocks e testes automatizados

Além do código de produção, queria criar testes automatizados.

Nos primeiros serviços optei por implementar, além dos testes unitários mais básicos, vários testes integrados. Para isso utilizei a biblioteca Ring-Mock para mockar o servidor web. Também criei um dublê da função que fazia acesso ao banco de dados.

Com o tempo comecei a ter dificuldade para manter estes testes, que quebravam de forma não muito trivial. Outro grande problema era que, ao tentar praticar TDD, senti falta de um type system para criar os asserts.

Às vezes criava todo o cenário de ponta a ponta, mas em runtime, quando estava executando a aplicação e me conectando no banco real, o tipo retornado era diferente do que eu estava imaginando. E mais uma vez encontrar exatamente onde estava o problema era um pouco chato às vezes. Nem sempre a mensagem de erro era realmente significativa.

Com o tempo optei por minimizar (pelo menos por enquanto) este tipo de teste. Tento maximizar a quantidade de funções puras e foco meus testes nelas. Sinto falta de testar algumas camadas da aplicação, sendo algo que ainda preciso experimentar e explorar mais.

Separando as funções puras

Não quero entrar muito em detalhes da arquitetura do sistema neste artigo, mas ela está bastante simples. Cada caso de uso (serviço) tem a sua própria pasta, e as funções puras e impuras estão em namespaces distintos. Me esforço para tentar transformar funções impuras em puras e tornar aquelas impuras em apenas orquestradoras.

As funções que causam algum tipo de efeito colateral devem ser o mais "burras" possível. Exemplo: uma função que executa uma query no banco não pode ter nenhuma regra de negócio. O mesmo para uma função que executa uma chamada HTTP, etc.

Já considerava isso uma boa prática quando programava em outras linguagens, mas em Clojure (por ser funcional), torna-se muito fácil e natural fazer isso.

Com o tempo, acabei diminuindo e até eliminando alguns testes integrados e aumentando a quantidade de testes unitários. Para o meu contexto, isso funcionou bem, mas às vezes ainda sinto falta de testes mais abrangentes.

Injeção de dependências

Pessoas acostumadas com Java, .NET e similares talvez queiram buscar alguma biblioteca de injeção de dependência para poder praticar inversão de controle.

Para atingir este objetivo em Clojure, tudo que precisei até agora foi passar referências de funções como parâmetros. Se uma função precisa, por exemplo, executar uma query no banco de dados, eu passo como parâmetro a referência para a função que, ao receber um comando SQL, o executa e retorna o resultado. Faço o mesmo para chamadas HTTP ou outras formas de efeitos colaterais.

No contexto da minha aplicação, isso foi suficiente. Caso precise criar um dublê (mock/spy/stub), basta passar a referência de outra função (usada apenas para testes) como parâmetro. Assim consigo evitar o acoplamento com camadas externas (como banco de dados ou outros sistemas) nos testes, permitindo que tenha total controle sobre o que será retornado nessas chamadas, permitindo criar asserts facilmente, que não irão quebrar com o tempo. Isso permite também que meus testes possam ser executados de forma concorrente, além de serem muito rápidos.

Onde hospedar

Uma das grandes vantagens da linguagem Clojure - e um dos principais motivos de tê-la escolhido - é o fato de ser uma linguagem que roda na JVM (Java Virtual Machine). O resultado final da aplicação é um Uberjar (um arquivo jar com sufixo -standalone.jar) contendo toda a aplicação e dependências do projeto.

E o servidor criado da forma como descrevi neste artigo pode ser iniciado no ambiente produtivo com a seguinte linha de comando:

java -jar target/nome-projeto-0.0.1-SNAPSHOT-standalone.jar

No meu caso, estou utilizando uma nuvem privada on-premise. E um ponto interessante é que esta nuvem já tinha suporte à plataforma Java e eu já havia desenvolvido muitas soluções nesta linguagem. Migrar para o Clojure foi trivial, não precisando fazer nenhuma alteração na infraestrutura. Para o time do centro de dados, é totalmente transparente.

Ou seja, aplicações desenvolvidas da forma como descrevi neste artigo podem ser hospedadas em qualquer servidor que tenha suporte ao Java! 🎉

Bônus: atualizando as dependências

Uma preocupação que sempre tenho em todo projeto é evitar o seu envelhecimento. É um processo natural de toda aplicação, que precisa de atenção constânte do time. E pelo menos para alguns destes tipos de problemas, o processo pode ser automatizado!

O Leiningen possui um comando que verifica se existem dependências desatualizadas e, caso encontre alguma, é capaz de atualizá-la e em seguida executar os testes automatizados. Caso algum teste falhe, a alteração é desfeita e uma mensagem de erro é exibida indicando o problema.

Esta funcionalidade me ajuda diariamente! Criei um script com o comando e normalmente começo meu dia executando-o para garantir que o projeto está com as dependências sempre atualizadas.

O comando em questão é:

lein ancient upgrade :interactive :check-clojure

Mas para poder executá-lo é necessário configurar o plugin lein-ancient.

Meu project.clj atual

A configuração de um projeto que utilize o Leiningen é toda feita no arquivo project.clj.

Abaixo compartilho como está a configuração do meu projeto no momento em que estou escrevendo este texto. Além das bibliotecas que aprensentei aqui, utilizo algumas outras configurações que não achei relevantes o suficiente para destacar, mas que podem ser úteis para algumas pessoas.

(defproject nome-projeto "1.0.0-SNAPSHOT"
  :description "Aqui ficaria a descrição do projeto."
  :url "https://endereço-repositorio-git"
  :min-lein-version "2.10.0"
  :dependencies [[org.clojure/clojure "1.11.1"]
                 [compojure "1.7.0"]
                 [ring/ring-defaults "0.3.4"]
                 [com.github.seancorfield/honeysql "2.4.1045"]
                 [org.clojure/java.jdbc "0.7.12"]
                 [org.postgresql/postgresql "42.6.0"]
                 [hikari-cp "3.0.1"]
                 [org.clojure/data.json "2.4.0"]
                 [org.slf4j/slf4j-simple "2.0.7"]
                 [clj-http "3.12.3"]
                 [org.clojure/core.cache "1.0.225"]
                 [jarohen/chime "0.3.3"]
                 [org.clojure/core.async "1.6.673"]]
  :plugins [[lein-ring "0.12.6"]
            [lein-ancient "0.7.0"]
            [lein-cloverage "1.2.2"]]
  :ring {:handler um.namespace.qualquer.routes/app}
  :repl-options {:init-ns um.namespace.qualquer.logic}
  :profiles
  {:dev {:dependencies [[javax.servlet/servlet-api "2.5"]
                        [ring/ring-mock "0.4.0"]]}})

Conclusões

Clojure, em conjunto com as bibliotecas que mostrei ao longo deste artigo, me atenderam muito bem. Consegui criar uma arquitetura que é ao mesmo tempo simples e fácil de incluir novos serviços. O servidor consome poucos recursos e tem uma performance muito boa.

A escolha por criar o meu próprio framework, selecionando cada biblioteca isoladamente, inicialmente consumiu certo tempo. Tive que testar cada uma delas, descartar as que não atendiam minhas necessidades e construir alguns códigos para "colar" essas bibliotecas.

Usar um framework pronto provavelmente iria aumentar a minha produtividade nas primeiras iterações, mas como é um projeto que espero manter por muitos anos, ter total controle sobre cada parte dele provavelmente é o cenário ideal.

A comunidade Clojure parece ter uma cultura de criar bibliotecas pequenas, com propósitos muito bem definidos. Acredito que esta característica, em conjunto com o fato de Clojure ser uma linguagem funcional, facilitou muito este processo. Essas duas características somadas permitiram que, apenas utilizando composição de funções, eu fosse capaz de criar grandes abstrações, sem adicionar muita complexidade.

Mas é importante deixar claro que este é um projeto pequeno, onde não precisei utilizar nenhuma arquitetura muito avançada. Não abordei nada como Domain-driven design, Arquitetura Hexagonal, Microsserviços, ... Então não consigo afirmar que Clojure (ou mesmo o paradigma funcional) seria uma boa opção para cenários mais complexos. Mas, até o momento, não estou arrependido da escolha e, se depender de mim, não volto a programar em uma linguagem orientada a objetos novamente tão cedo! 😇

E você? Quais tecnologias têm utilizado para desenvolvimento web? Conte um pouco das suas experiências mais recentes nos comentários!

Gostou deste texto? Conheça meus outros artigos, podcasts e vídeos acessando: https://segunda.tech.

E se quiser, me segue lá no twitter e blue sky.

What it was like to spend a month using GitHub Copilot and why I plan to not use it (next month)

Marcio Frayze — Thu, 15 Jun 2023 13:57:57 +0000

You're probably already familiar with GitHub Copilot: a tool created by Microsoft to help developers by providing real-time code suggestions. While tools like ChatGPT are also capable of generating code, GitHub Copilot takes advantage of tight integration with the code editor.

There are several ways to use it: you can write a feature as a comment and the tool is capable of generating a function, method, or even a complete class to contemplate what you described. Or you can type the name of a function or method and let the autocomplete try to predict the corresponding code. Or you can just use it as a slightly "smarter" autocomplete for smaller parts of your code.

The first way (using only comments) I don't trust and would never recommend. The second, writing just the name of the function or method, usually works surprisingly well for snippets of code with reduced and closed scope, such as creating a function that will receive a data structure and do some simple transformation or filter operations. The last way, as a more "efficient" autocomplete, had mixed results. Sometimes it hit the jackpot! 🎯 But it wasn't uncommon to need adjustments or even come up with a solution that was just plain wrong.

Throughout May 2023, I used this tool to program in Clojure and Elm. In this article, I tell you a little about what I thought of this experience.

Why I decided to give it a try

In April 2023 Kent Beck posted the following message on Twitter:

This twit was so successful that he ended up writing a post to better explain his opinion.

For those who don't know him, Kent Beck is one of my favorite technical book authors, having written such books as eXtreme Programming Explained, Planning Extreme Programming , Test-Driven Development: By Example, among others.

In April 2023 I was also reluctant to try ChatGPT, but after reading this twit, I immediately opened it and started testing it. It soon became clear that I was facing something very different from what I had experienced before. I was very impressed and spent hours doing various experiments, including code generation.

After a day of testing ChatGPT, one thing stuck in my head: if it manages to generate codes so well when it wasn't even created for this purpose, imagine what it must be like to use GitHub Copilot!

To my joy, I remembered that the company I work for was selecting a group of people to test this tool in the following month, in partnership with Microsoft. I ran and managed to include myself in this team. Couldn't wait to get started! 🎉

First impressions

Initially, I didn't know (and, I confess, I still don't know) exactly how to use this technology. As I reported at the beginning of the article, there is no formula, and each person can adapt to their way of working. But it was very impressive. I started small, writing functions in Clojure (backend) and Elm (frontend) in well-defined contexts, and it felt like it could read my mind! I wrote the name of the function and... the implementation appeared! 🧙🪄

Looked like facing a great revolution and that the way I would program would never be the same. I felt more productive. As if I didn't waste more time with boilerplates and repetitive codes in general. Now I could focus on what matters!

But little by little I noticed some not-so-cool things, both in the generated code and in my behavior.

Confusing and non-standard codes

I used Copilot in a web application that had been in production for over 6 months, with many screens and services that already had a clear design pattern. And while Copilot can adapt, there are limitations. Suddenly I began to notice that the construction of some functions was quite odd, adopting mechanisms that I didn't even know about.

When I realized that, I tried to see it as a good thing: Wow! I didn't know it was possible to do that. How cool, it's helping me in learning new things! And it was true. I learned new things because of Copilot. And I could of course reject those suggestions and rewrite them as I wanted.

On the other hand, it's very easy to get carried away. Gradually I began to feel more and more comfortable in accepting the proposed suggestions. I analyzed the solution, but less judiciously. In some moments it even generated codes that I didn't fully understand. It wasn't necessarily complex but used some language tricks I didn't understand. In some cases, I did some testing (both automated and manual) and it worked. What should I do in these situations? I have a fully working code, but I don't quite understand how it works. I even accepted the solution a few times, saying to myself that I would come back later to study that part (but, of course, I never had the time and inclination to do so).

At the same time, I felt that the fact that I was able to write code more quickly was worth it.

Could this be the future? Writing code that we don't quite understand? Perhaps I should create more automated tests and trust that the code is correct as the tests are passing? But wouldn't I use this same technology to write the tests? Do I want to program this way? 🤔

Many questions started running through my head. Until the worst happened.

Oops, I put a bug in production and didn't even notice! 🐛

When I'm programming in Elm, it's not uncommon to start writing not very organized code, to test my ideas. Once I have the screen ready, displaying everything the way I want, I reorganize the code. This usually works great, in part because it's a statically typed language with an amazing compiler. I'm able to change the code and let the compiler guide me, and usually when the code compiles, my application still behaves as expected.

I'm a big fan of automated tests, but for this part of the application, there were no complex rules. All I had to do was make a REST call to the backend and display some formatted information on the screen. So my test coverage was low.

And it was during one of these modifications that something strange happened.

The problem I was solving

I won't go into too many business details, but I was working on a new functionality for an internal support web page (similar to a dashboard), where it's possible to consult various reports about a given system. This system provides a series of services to other third-party systems, and I needed to expose the usage metrics of these services through a page, with tables, graphs, etc.

Internally, there is an identification table for these third-party systems, containing (among other things) an identifier (an integer) and a description (a string).

To do this, I built a new endpoint in the backend that returned a json containing 2 lists: one of them was a simple key-value, containing the third-party system code and its respective name/description. The other list contained some metrics about the accesses made by these systems, grouped by month.

In a simplified form, the json returned was something like this:

{
    "hits": [
        {
            "monthYear": 1633057200000, // date in POSIX format
            "consumerSystemCode": 10,
            "quantity": 61
        },
        {
            "monthYear": 1635735600000,
            "consumerSystemCode": 10,
            "quantity": 220
        },
        {
            "monthYear": 1635735600000,
            "consumerSystemCode": 11,
            "quantity": 34032
        },
        {
            "monthYear": 1638327600000,
            "consumerSystemCode": 11,
            "quantity": 179301
        }
    ],

    "consumerSystemCodes": [
        {
            "id": 10,
            "decription": "XPTO Systen"
        },
        {
            "id": 11,
            "decription": "Foo System"
        },
        {
            "id": 12,
            "decription": "Another System"
        } 
    ]
}

Note that in this example the first list contains information about systems with identifiers 10 and 11, while the list of consumerSystemCodes contains identifiers with numbers 10, 11, and 12. This is important to understand what went wrong in my code.

How I solved the problem (without Copilot's help)

I wasn't using Copilot yet while building the first iteration of this screen. It contained a general report, with a summary gathering all systems, followed by a more detailed report, separated by sessions (one for each system).

To implement this, it is necessary to start from one of two lists: hits or consumerSystemCodes. A more distracted person might start from consumerSystemCodes, since it seems to be easier, after all, one could just make a map on top of it and generate a session on the screen for each system. Or, even better, could generate some intermediate data structure first, so it can be sorted and transformed however necessary before moving on to the view layer.

After reflecting a bit, I chose to start with the hits list, for two main reasons:

1- There are no restrictions that make it impossible for the hits list to have an entry with an id that is not present in the consumerSystemCodes list. And I wanted to be sure that all entries would be displayed on the screen and, in case this unexpected situation happens, that a new session was created on the screen, with the title "Unknown System (ID: x)" (one session for each unknown identifier).

2- And the opposite can also occur: the list consumerSystemCodes may contain systems that do not have any data in the list hits, so it would be displaying sessions with empty information.

There are several ways to get around these problems. The way I chose to do it was to start processing with the hits list.

So I started with a code that, I confess, was more complex than I initially imagined. Had to create some helper functions to get the needed data, but in the end, it worked fine.

Rearranging with the help of Copilot

I was eager to see the results on the screen and the code reflected that: it was messy and disorganized. But luckily it had been written in Elm! And the compiler was there, ready to help me with the reorganization. And this time I was already using Copilot.

When I started to change the design of the code, Copilot tried to implement it in the simplest way possible, through the list consumerSystemCodes. My mind was no longer focused on the potential problems of this path and... I let the Copilot guide me. Suddenly I was smiling, deleting various auxiliary functions that were "no longer needed". And, unfortunately, there were no automated tests to help me with this part of the redesign. Then I opened the system, pointing to my development environment, and... all right! All reports continued to appear as expected.

I was so excited! I remember texting a colleague to celebrate how Copilot had helped me drastically reduce the complexity of my code! 🥳

Time to push and let the pipeline publish to production.

As soon as I opened the page in production, I realized that something was wrong. 🪲🐞🪳 Multiple sessions with empty information! In development, this did not happen, since the database content was different. Lucky for me, although I was in the production environment, I hadn't made the link available in the menu yet, so no one else had access to this page and I had time to better analyze what was happening. My first reaction was to create a filter to remove empty entries. But that didn't happen before! What has changed? That's when I realized the source of the problem. And it wasn't just filtering the empty entries, since doing just that wouldn't solve problem 1 that I mentioned above.

Once again I needed to change the code, this time returning to a logic closer to the original implementation. And once again, Copilot insisted on starting the process through the consumerSystemCodes list. All autocompletes took me the wrong way and suddenly, I was almost re-implementing the logic in the wrong way again! Even knowing what needed to be done, it was hard not to let Copilot lead me down the wrong path. 🤦

After some fight, I won! But this battle left a bitter taste in my mouth. And spent hours thinking: would I have included this bug if not for Copilot? Probably not. Could I have avoided this through more automated testing? Probably yes. What if I was doing mob or pair programming? Maybe someone would spot the problem. And would an asynchronous code review catch this situation? I think it's unlikely, but maybe.

But this was just one of the scenarios where something like this happened. There weren't many and this was the most annoying, but they were enough to start causing me some discomfort.

More weird code

At some point, I was reviewing the code and noticed something VERY strange: a function was returning an anonymous function, without any reason why. I don't know exactly when that happened, but my hypothesis is that I had created a new function and forgotten to include one of the parameters to do what I needed. Any developer would notice this right away and change the function signature, but Copilot is not able to change the code, it only suggests new code. To solve the problem, I think it created an anonymous function with the missing parameter! The rest of the code was as expected and did the right thing, which is perhaps the reason I accepted the suggestion without realizing the existence of the anonymous function. 😳

I wondered what it would be like if someone else had encountered this problem in my code! What would they think? That made no sense! Even more so in Elm, where every function has currying by default! If it weren't my code, maybe I'd even be afraid to change it, after all, no human being would write something like that without having a good reason. I could spend hours looking at that lines without realizing why it was returning an anonymous function.

Trust or distrust autocomplete?

After a while, I realized that even though I was quite skeptical at first and understood the limitations of an AI-assisted tool, it got it right enough times to slowly gain my trust. And that needed to change.

Ever since I started working professionally as a software developer, I've been using some kind of code autocomplete tool. In general, simple things like the name of a function or method. One of the advantages of autocompletes in IDEs and code editors is that I can trust them. If my IDE is telling me that this object has a certain method or if a certain module has a certain function, I've learned to believe this information. When I don't remember if the function is called getTaxpayerStatus or retrieveTaxpayerStatus and the first option appears in my editor, I know that this is the correct name and trust it.

But from the moment that my autocomplete starts to hallucinate and invent names for functions or methods, I need to be more cautious. Of course, my IDE (or code editor) autocomplete and Copilot autocomplete are visually quite different, but I need to "turn off" a switch in my brain, which is used to trusting all autocomplete. Now I always have to ask myself: is this based on facts or was this generated by a plugin that is just making things up based on probability and statistics?

How to proceed?

Copilot positively surprised me in many ways. I studied AI during my master's degree and didn't expect that it would be possible to have such an advanced tool so soon.

And in the first days it was just joy, but after a month and some non-trivial to detect bugs, using this tool started to generate some stress and anxiety. And something that should have lessened my cognitive load has started to increase it.

I started to distrust everything that was generated and that pleasant feeling of the first days become less common.

This doesn't mean that I think GitHub Copilot is bad or that I don't recommend it. On the contrary. It was a really cool experience! And I recommend that every developer try it out and draw their conclusions. I think it's likely that we're moving towards a time when this type of technology will become part of (almost) every developer's day-to-day. Whether this will be good or bad, only time will tell.

But still, I chose not to use it anymore. At least for a while.

Although I didn't do any measurements, turning this tool off seems to have slowed me down. Writing a filter, simple parsers, and boilerplates, in general, have become more onerous processes. But this is not necessarily a bad thing. Taking time to reflect on what I'm doing has taken a weight off my shoulders.

Copilot's slogan is: "Your AI pair programmer". And yes, it felt like there was a person programming with me all the time - but an annoying one, who wouldn't shut up for a second. 📣 It was like doing pair programming, but with someone who has no idea what it means to work this way. Who understands absolutely nothing about the problem I want to solve. And when something goes wrong, blames me.

In the first hours without Copilot I really missed it! I was already used to the idea of typing the name of a function and seeing the code being generated. But soon readjusted to the way I programmed before. And felt more in control. More relaxed.

I still don't know if (or when) I'll ever use a technology like this again, but for now, I'm fine without it. When I need something very specific, I talk to ChatGPT and that has been enough for me.

And what about you? Have you tried Copilot yet? What are your thoughts? Leave your comments below!

Did you like this text? Check out my other articles at: https://segunda.tech/tags/english and follow me on Twitter and Blue Sky.

Como foi passar um mês usando o GitHub Copilot e por que pretendo não utilizá-lo (no próxino mês)

Marcio Frayze — Tue, 13 Jun 2023 11:58:57 +0000

Provavelmente você já deve conhecer o GitHub Copilot: uma ferramenta criada pela Microsoft para auxiliar pessoas desenvolvedoras, fornecendo sugestões de código em tempo real. Embora ferramentas como ChatGPT também sejam capazes de gerar código, o GitHub Copilot tem como vantagem ter uma forte integração com o editor de código.

Existem várias formas de utilizá-lo: você pode escrever uma funcionalidade (até mesmo em português) em formato de comentário e a ferramenta é capaz de gerar uma função, método ou mesmo uma classe inteira completa para contemplar o que descreveu. Ou pode escrever o nome de uma função ou método e esperar que o autocomplete tente prever o código correspondente. Ou pode ainda utilizá-la apenas como um autocomplete um pouco mais "inteligente" para partes menores do seu código.

A primeira forma (utilizando apenas comentários) eu não confio e nunca recomendaria. A segunda, escrevendo apenas o nome da função ou método, costuma funcionar surpreendentemente bem para trechos de código com escopo reduzido e fechado, como por exemplo a criação de uma função que irá receber uma estrutura de dados e fazer alguma operação simples de transformação ou filtro. Já a última forma, como um autocomplete mais "eficiente", tive resultados mistos. Às vezes acertava em cheio! 🎯 Mas não era incomum precisar de ajustes ou até mesmo apresentar uma solução simplesmente errada.

Ao longo do mês de maio de 2023, utilizei esta ferramenta para programar em Clojure e Elm. Neste artigo conto um pouco sobre o que achei desta experiência.

Por que decidi experimentar

Kent Beck postou em abril de 2023 a seguinte mensagem no Twitter:

"Estava relutante em experimentar o ChatGPT. Hoje superei essa relutância. Agora entendo por que estava hesitante.
O valor de 90% das minhas habilidades acabou de cair para $0. A importância dos 10% restantes aumentou mil vezes. Preciso me reajustar." - Kent Beck

Este twit fez tanto sucesso que ele acabou escrevendo um post para explicar melhor sua opinião.

Para quem não conhece, Kent Beck é um dos meus autores de livros técnicos favoritos, tendo escrito livros como eXtreme Programming Explained, Planning Extreme Programming, Test-Driven Development: By Example, entre outros.

E em abril de 2023 eu também estava relutante em experimentar o ChatGPT, mas depois de ler este twit, o abri imediatamente e comecei a testá-lo. Em pouco tempo ficou claro que estava diante de algo muito diferente do que já havia experimentado antes. Fiquei muito impressionado e passei horas fazendo diversos experimentos, incluindo geração de códigos.

Depois de um dia testando o ChatGPT, uma coisa não saía da minha cabeça: se ele consegue gerar códigos tão bem sendo que nem foi criado para esta finalidade, imagine como deve ser usar o GitHub Copilot!

Para minha alegria, lembrei que a empresa onde trabalho estava iniciando um projeto justamente para testar esta ferramenta, em parceria com a Microsoft. Corri e consegui me incluir no grupo de pessoas que iriam testá-la no mês seguinte. Mal podia esperar para começar! 🎉

Primeiras impressões

Inicialmente não sabia (e, confesso, ainda não sei) exatamente como utilizar este tipo de tecnologia. Como relatei no início do artigo, não existe uma fórmula, cada pessoa pode adaptar para sua forma de trabalho. Mas logo fiquei impressionado positivamente. Comecei pequeno, escrevendo funções em Clojure (backend) e Elm (frontend) em contextos bem definidos e parecia que ela podia ler minha mente! Escrevia o nome da função e... aparecia a implementação! 🧙🪄

Sentia que estava diante de uma grande revolução e que a forma como iria programar nunca mais seria a mesma. Me sentia mais produtivo. Como se não perdesse mais tempo com boilerplates e códigos repetitivos em geral. Agora poderia me focar no que realmente importa!

Mas aos poucos fui observando algumas coisas não tão legais assim, tanto no código gerado quanto em meu comportamento.

Códigos confusos e despadronizados

Utilizei o Copilot em uma aplicação web que já estava em produção há mais de 6 meses, com muitas telas e serviços já prontos e que já tinha todo um padrão de como o código estava sendo estruturado. E embora o Copilot consiga se adaptar, existem limitações. De repente comecei a observar que a construção de algumas funções estavam bastante fora do padrão, adotando mecanismos que eu nem mesmo conhecia.

Quando percebi isso, tentei ver pelo lado positivo: nossa! não sabia que dava pra fazer isso. Que legal, além de tudo estou aprendendo coisas novas! E, por um lado, era verdade. Realmente aprendi coisas novas por conta do Copilot. E claro, bastava não aceitar aquelas sugestões que estivessem fora do padrão e reescrevê-las como eu queria.

Por outro lado, é muito fácil se deixar levar. Aos poucos comecei a me sentir cada vez mais confortável em aceitar as sugestões propostas. Analisava a solução, mas de forma mais abrangente e menos criteriosa. Em alguns momentos ele chegou a gerar códigos que não entendia perfeitamente. Não eram necessariamente complexos, mas usavam algum artifício da linguagem que desconhecia. Em alguns destes casos, fazia alguns testes (automatizados e manuais) e funcionava. O que devo fazer nestas situações? Tenho um código funcionando plenamente, mas que não entendo direito como funciona. Cheguei a aceitar a solução algumas vezes, dizendo para mim mesmo que iria voltar depois para estudar melhor aquela funcionalidade da linguagem (mas, claro, nunca tinha tempo e disposição para fazê-lo).

Ao mesmo tempo sentia que o fato de estar conseguindo escrever códigos mais rapidamente valia muito a pena.

Seria este o futuro? Escrever códigos que não entendemos direito? Talvez devesse criar mais testes automatizados e confiar que o código está correto, já que os testes estão passando? Mas eu não iria usar esta mesma tecnologia para escrever os testes? Será que eu quero programar desta forma? 🤔

Muitas perguntas começaram a passar pela minha cabeça. Até que o pior aconteceu.

Ops, coloquei um bug em produção e nem percebi! 🐛

Quando estou programando em Elm, não é incomum começar escrevendo códigos não muito organizados, com objetivo de testar minhas ideias. Depois que tenho a tela pronta, já exibindo tudo como quero, reorganizo o código. Normalmente isso funciona muito bem, em parte por ser uma linguagem estaticamente tipada com um compilador incrível. Consigo alterar o código e deixo o compilador me guiar e, em geral, quando o código compila, minha aplicação continua tendo o comportamento esperado.

Para alguns cenários crio testes automatizados, mas para esta parte da aplicação que estava desenvolvendo, haviam poucas regras complexas. Bastava fazer uma chamada REST para o backend e exibir algumas informações formatadas na tela. Então a minha cobertura de testes estava baixa.

E foi durante uma dessas alterações que algo estranho aconteceu.

Ententendo o problema que estava resolvendo

Não vou entrar em detalhes de negócio, mas estava trabalhando em uma nova funcionalidade de uma página web de apoio (uma espécie de dashboard), onde é possível consultar vários relatórios sobre um determinado sistema. Este sistema provê uma série de serviços para outros sistemas de terceiros e precisava expor as métricas de uso destes serviços através de uma página, com tabelas, gráficos, etc.

Internamente existe uma tabela de identificação destes sistemas de terceiros, contendo (entre outras coisas) um identificador (um número inteiro) e uma descrição (uma string).

Para fazer isso, construi um novo endpoint no backend que retornava um json contendo 2 listas: uma delas era bem simples, do tipo chave-valor, contendo o código de sistema consumidor e seu respectivo nome/descrição.

A outra lista continha algumas métricas sobre os acessos feitos por estes sistemas, com informações agrupadas por mês.

De forma simplificada, o json retornado era algo como:

{
    "quantidades": [
        {
            "anoMes": 1633057200000, // data no formato POSIX
            "codigoSistemaConsumidor": 10,
            "quantidade": 61
        },
        {
            "anoMes": 1635735600000,
            "codigoSistemaConsumidor": 10,
            "quantidade": 220
        },
        {
            "anoMes": 1635735600000,
            "codigoSistemaConsumidor": 11,
            "quantidade": 34032
        },
        {
            "anoMes": 1638327600000,
            "codigoSistemaConsumidor": 11,
            "quantidade": 179301
        }
    ],

    "codigosSistemasConsumidores": [
        {
            "id": 10,
            "descricao": "Sistema XPTO"
        },
        {
            "id": 11,
            "descricao": "Sistema Foo"
        },
        {
            "id": 12,
            "descricao": "Outro Sistema"
        } 
    ]
}

Note que neste exemplo a primeira lista contém informações sobre sistemas com identificadores 10 e 11, enquanto a lista de codigosSistemasConsumidores contém identificadores com os números 10, 11 e 12. Isso é importante para entender o que deu errado no meu código.

Como resolvi o problema (sem ajuda do Copilot)

Ainda não estava utilizando o Copilot durante a construção da primeira iteração desta tela. Ela continha um relatório geral, com um resumo juntando todos os sistemas, seguida de um relatório mais detalhado, separado por sessões (uma para cada sistema).

Para implementar isso é necessário partir de uma das duas listas: quantidades ou codigosSistemasConsumidores. Uma pessoa mais desatenta talvez começasse a partir da codigosSistemasConsumidores, já que parece ser mais fácil, afinal seria apenas fazer um map em cima dela e gerar uma sessão na tela para cada um dos sistemas. Ou, melhor, poderia gerar alguma estrutura de dados intermediária primeiro, para que pudesse ordenar da forma que quisesse e fazer qualquer outro tipo de transformação antes de partir para a camada de visualização.

Depois de refletir um pouco, optei por iniciar pela lista de quantidades, por duas razões principais:

1- Não existe nenhuma restrição que impossibilite que a lista quantidades tenha uma entrada com um id que não esteja presente na lista codigosSistemasConsumidores. E queria ter absoluta certeza que todas as entradas seriam exibidas na tela e, caso esta situação inesperada aconteça, que fosse criada uma sessão nova na tela, com o título "Sistema Desconhecido (ID: x)" (uma sessão para cada identificador desconhecido).

2- E o contrário também pode ocorrer: a lista codigosSistemasConsumidores pode conter sistemas que não tenham nenhum dado na lista quantidades, então estaria exibindo sessões com informações vazias.

Existem várias formas de contornar estes problemas. A forma que optei por fazer foi iniciar o processamento pela lista quantidades.

Parti então para o código que, confesso, ficou mais complexo do que imaginei inicialmente. Tive que criar algumas funções auxiliares para obter os dados que precisava, mas no final funcionou adequadamente.

Reorganizando com a ajuda do Copilot

Estava muito ansioso para ver os resultados na tela e o código que escrevi refletiu isso: estava confuso e um pouco desorganizado. Mas felizmente havia escrito em Elm! E o compilador estava ali, pronto para me ajudar na reorganização. E desta vez já estava utilizando o Copilot.

Quando comecei a alterar o design da parte do código que fazia esta lógica que citei no item anterior, o Copilot tentou realizar o processamento pela forma mais simples possível, através da lista codigosSistemasConsumidores. Minha mente não estava mais tão ligada nos potenciais problemas deste caminho e... deixei o Copilot me guiar. De repente estava super sorridente, apagando várias funções auxiliares que deixavam de ser necessárias. E, infelizmente, não havia nenhum teste automatizado para me ajudar nesta parte do redesign. Abri então o sistema, apontando para o meu ambiente de desenvolvimento e... tudo certo! Todos os relatórios continuavam aparecendo como esperado.

Estava muito feliz! Lembro que mandei uma mensagem para um colega, celebrando como o Copilot tinha me ajudado a reduzir drasticamente a complexidade do meu código! 🥳

Hora de fazer push e deixar a pipeline publicar em produção.

Assim que abri a página em produção, percebi que algo estava errado. 🪲🐞🪳 Várias sessões com informações zeradas! Em desenvolvimento isso não acontecia, já que a massa de dados estava diferente. Para minha sorte, embora estivesse no ambiente de produção, não havia disponibilizado o link no menu de funcionalidades ainda, então ninguém mais tinha acesso à esta página e eu tinha tempo para analisar melhor o que estava acontecendo. Minha primeira reação foi criar um filtro, para retirar as entradas vazias. Mas isso não acontecia antes! O que mudou? Foi quando percebi a origem do problema. E não era apenas filtrar as entradas zeradas, já que fazer apenas isso não resolveria o problema 1 que citei mais acima.

Mais uma vez precisava alterar o código, desta vez voltando para uma lógica mais próxima à original. E mais uma vez, o Copilot insistia em iniciar o processo através da lista codigosSistemasConsumidores. Todos os autocompletes me levavam para o caminho errado e - acredite - quando vi, estava quase implementando novamente a lógica de forma errada! Mesmo sabendo o que precisava ser feito, era difícil não deixar o Copilot me guiar para o caminho errado. 🤦

Depois de alguma luta, venci! Mas esta batalha deixou um gosto amargo na boca. Passei horas pensando: será que teria incluído este bug se não fosse o Copilot? Provavelmente não. Teria conseguido evitar isso através de mais testes automatizados? Provavelmente sim. E se estivesse fazendo mob ou pair programming? Talvez alguém percebesse o problema. E uma revisão de código assíncrona, pegaria esta situação? Acho pouco provável, mas talvez.

Mas este foi apenas um dos cenários onde algo deste tipo aconteceu. Não foram muitos e este foi o mais chato, mas foram suficientes para começar a me causar certo desconforto.

Mais códigos estranhos

Em algum momento estava revendo o código e percebi algo MUITO estranho: uma função estava retornando uma função anônima, sem necessidade nenhuma. Não sei exatamente quando aquilo aconteceu, mas minha hipótese é que havia criado uma nova função e esquecido de incluir um dos parâmetros para fazer o que precisava. Qualquer pessoa desenvolvedora perceberia isso na hora e iria alterar a assinatura da função, mas o Copilot não é capaz de alterar o código, apenas sugerir novos códigos. Para resolver o problema da falta de um dos parâmetros, acredito que ele tenha criado uma função anônima com o parâmetro que estava faltando! O restando do código estava como esperado e fazia a coisa certa e, talvez por isso, aceitei a sugestão em algum momento sem perceber a existência da função anônima. 😳

Fiquei imaginando como seria se outra pessoa tivesse encontrado este problema! O que ela iria pensar? Aquele código não fazia o menor sentido! Ainda mais em Elm, onde toda função possui currying por padrão! Se não fosse meu código, talvez tivesse até receio de alterá-lo, afinal, nenhum ser humano escreveria algo assim sem ter uma boa razão. Poderia passar horas olhando aquele código sem entender o motivo daquilo.

Confiar ou desconfiar do autocomplete?

Em algum momento percebi que, mesmo sendo bastante cético no começo e entendendo as limitações de uma ferramenta de IA, ela acertava quantidade suficiente de vezes para, aos poucos, ganhar minha confiança. E isso precisava mudar.

Desde que comecei a trabalhar profissionalmente como desenvolvedor de software, uso algum tipo de ferramenta de autocomplete de código. Em geral, coisas simples, como o nome de uma função ou método. Uma das vantagens dos autocompletes das IDEs e editores de código é que eu posso confiar neles. Se minha IDE está me dizendo que este objeto tem um determinado método ou se um determinado módulo tem uma certa função, eu aprendi a acreditar nesta informação. Quando não lembro se a função se chama obterSituacaoContribuinte ou consultarSituacaoContribuinte e aparece a primeira opção no meu editor, eu sei que este é o nome correto e confio nisso.

Mas a partir do momento que meu autocomplete passa a alucinar e inventar nomes para as funções ou métodos, preciso ficar mais atento. Claro que o autocomplete da minha IDE (ou editor) e o autocomplete do Copilot são exibidos de forma bastante distintas visualmente, mas preciso "desligar" uma chave do meu cérebro, que já está acostumado a confiar em todo autocomplete. Agora preciso sempre me questionar: quem está dizendo isso está se baseando em fatos ou isso foi gerado por um plugin que está apenas inventando coisas baseado em probabilidade e estatística?

E agora?

O Copilot me surpreendeu positivamente em muitos aspectos. Estudei sobre IA durante meu mestrado e não esperava que fosse possível existir uma ferramenta tão avançada como esta tão cedo.

E nos primeiro dias foi só alegria, mas depois de um mês e alguns bugs não triviais de detectar, o uso desta ferramenta começou a me gerar algum estresse e ansiedade. E algo que deveria diminuir minha carga cognitiva, começou a aumentá-la.

Passei a desconfiar de tudo que era gerado e aquela sensação gostosa dos primeiros dias começou a ficar menos comum.

Isso não significa que considere o GitHub Copilot ruim ou que não o recomende. Pelo contrário. Foi uma experiência muito legal! E recomendo que toda pessoa desenvolvedora experimente e tire suas próprias conclusões. Acho provável que estejamos caminhando para um momento em que este tipo de tecnologia vai passar a fazer parte do dia a dia de (quase) toda pessoa desenvolvedora. Se isso vai ser bom ou ruim, só o tempo dirá.

Mas, ainda assim, optei por não utilizá-la mais. Pelo menos por enquanto.

Embora não tenha feito nenhum tipo de medição, desligar esta ferramenta aparentemente diminuiu a minha velocidade. Escrever um filtro, parsing e boilerplaites em geral tornaram-se processos mais onerosos. Mas isso não é algo necessariamente ruim. Ter um tempo para refletir sobre o que estou fazendo tirou um peso das minhas costas.

O slogan do Copilot é: "Your AI pair programmer", que poderia traduzir em algo como "seu programador em par com IA". E realmente sentia como se estivesse uma pessoa programando comigo o tempo todo - mas uma pessoa chata, que não calava a boca um segundo. 📣 Era como fazer pair programming, mas com alguém que não faz ideia do que significa trabalhar de forma pareada. Que não entende absolutamente nada sobre o problema que quero resolver. E que quando algo dá errado, coloca toda culpa em mim.

Nas primeiras horas sem Copilot senti muita falta! Já estava acostumado com a ideia de digitar o nome de uma função e ver o código sendo gerado. Mas logo me readaptei à forma que programava antes. E me senti mais no controle. Mais relaxado.

Ainda não sei se (ou quando) vou voltar a utilizar uma tecnologia como esta, mas por enquanto, estou bem sem ela. Quando preciso de algo muito específico, converso com o ChatGPT e isso tem sido suficiente para mim.

E você? Como já experimentou o Copilot? O que tem achado? Deixe sua opinião nos comentários.

Gostou deste texto? Conheça meus outros artigos, podcasts e vídeos acessando: https://segunda.tech.

E se quiser, me segue lá no twitter e blue sky.

Why I decided to learn (and teach) Clojure

Marcio Frayze — Mon, 20 Mar 2023 13:06:24 +0000

In 2017 I started to learn more about the universe of Functional Programming. This paradigm was gaining traction and most object-oriented programming languages were adding more and more features inspired by this paradigm, including the language that I used the most: Java.

After the JDK 8 release in March 2014, it became common to hear Java developers using terms like: functional programming, streams, optional, map, flat map, etc. But many people around me still ignored these new features and, I confess, it took me a while to adopt them. The ideas sounded very interesting, but putting them into practice turned out to be more difficult than I expected.

After much trial and error, I decided to dig deeper into the concepts. The book Functional Thinking helped me take my first steps in the right direction.

In parallel I decided to learn a functional-first programming language instead of trying to partially apply the functional paradigm in an object-oriented language. After doing a lot of research, I chose to learn Elm. The fact that it is a pure and immutable functional language caught my attention. Also, it is focused on webapps development and, until then, I hadn't found any solution for developing web pages that I liked.

After going through the whole Introductory Guide to the Elm Language and reading the Elm in Action book, I already felt quite comfortable developing webapps in this paradigm. I liked Elm so much that I started a project to teach programming to beginners using this language and made the first classes available on the website elm.dev.br (in Brazilian Portuguese).

But there was a serious problem that I still had to face: Elm is a language designed for webapps development and works very well for that, but I was looking for a general purpose solution, that could also be used in backends development. So I started hunting for another language again.

Elm is a statically typed language inspired by Haskell. The natural step would be to use Elm on the frontend and Haskell on the backend. And that's what I tried to do. I read with some difficulty the Learn You a Haskell for Great Good! book (available for free here) and learned a lot of cool stuff. But creating a complete backend using Haskell proved to be more than I could chew. So I decided to look for alternatives...

During this whole process the word Lisp kept popping into my head! From time to time I would come across a video of someone influential in the community talking about it (like this video or this twit by John Carmack, founder of id Software). It felt mystical. And the fact that Nubank adopted Clojure brought a very real and pragmatic case study of the use of a Lisp dialect here in Brazil.

Until then I was postponing studying it because I was prioritizing statically typed languages and the most famous dialects of Lisp are dynamic languages. But in early 2021 I finally decided to give it a chance. I chose the language Clojure and started reading the Getting Clojure book. Unlike my Haskell studies, I managed to read this book in just a few days! At the same time, I started taking Clojure classes at Alura (a popular online programming school in Brazil), which helped me to see how to program in this language in hands-on. It was a good combination: in the book I learned the concepts of the language more deeply and in the course I reviewed these concepts and learned the more practical parts.

Clojure's key features

Lisp is not a programming language, but a family of languages with many dialects. The most famous dialects include Common Lisp, Clojure, Scheme and Racket. So after deciding that I was going to learn Lisp, I had to choose one of its dialects.

Clojure stood out to me for two reasons:

it uses the Java Virtual Machine, enabling interoperability with Java applications (which, as I said at the beginning of the article, is the language I usually use in the backend).
it predominantly uses the functional paradigm. Some Lisp dialects (like Common Lisp) are multiparadigm, but as my intention was to go deeper into the universe of functional programming, it made sense to adopt a dialect that was functional first.

The experience of programming in Clojure was quite liberating. Practice TDD together with REPL Driven Development (technique quite widespread inside the Clojure community) makes the feedback loop very fast. The fact that Clojure is a dynamic language also contributes to that.

Another characteristic of Clojure is that it is an impure language, that is, we can have side effects at any time. The main advantage of this is that it makes the language easier to learn (although it brings with it a host of other problems that don't happen in purer languages like Elm or Haskell).

But although it is an impure language, it encourages a series of good practices that significantly reduces the potential problems of this approach.

Getting started with Clojure

Clojure might be intimidating at first, but after a few hours you get used to it's syntax and it's actually quite easy to learn. That's why I also chose this language to share with other developers the basic fundamentals of functional programming.

If books are your thing, I recommend starting with Getting Clojure, which as I said earlier, is a great way to understand the basic principles behind Clojure. But if you are looking for a free option, you may start with the online version of the Clojure for Brave and True book. Another option more focused on the foundations of the paradigm and that addresses languages other than Clojure is the book Functional Thinking, by Neal Ford.

I created a 10 hours course on Introduction to Functional Programming with Clojure with optional payment (yes, you can enroll for free if you want to!). But right now it's only available in my native language: Brazilian Portuguese. 😉

And you, what is your favorite paradigm? Have you tried programming using the functional paradigm? What were your main difficulties? Share your experiences in the comments!

Did you like this text? Checkout my other articles at: https://segunda.tech/tags/english and follow me on twitter.

Fantasy Consoles: What would the retro console of your dreams look like?

Marcio Frayze — Thu, 16 Mar 2023 16:31:33 +0000

A Brazilian Portuguese version is available here.

In the mid-1990s I had my first contact with a computer: a Gradient Expert (MSX 1) of my older brothers. At the time it was already an old computer but I had a lot of fun. And it was in this computer that I wrote my first lines of code, using the BASIC language.

A few years later I had access to a 486DX2-66Mhz running the Microsoft DOS operating system and Windows 3.11. But I never had that same MSX's era feeling again. Pressing the power button and in a few seconds being in a terminal, typing lines of code right away, has become somewhat nostalgic. After that, on all computers had to wait several minutes, use the mouse, click icons, wait several more minutes... 😮‍💨

With the evolution of technology it was natural to expect the experience to improve, but it was not what I felt. Of course the experience has somehow improved: more memory, better graphics, disk space, dozens of times faster processors... but the feeling was that everything got worse, that before everything was more fun. Typing Run and pressing Enter was much nicer than clicking an icon on the screen. But you can't slow progress. At some point I surrendered to Windows and it's mouse (after all I also wanted to play the latest game releases!).

Perhaps because of this nostalgic feeling, when I first opened a Fantasy Console I was very excited! The terminal was similar to the one I was used to as a teenager. The games too: simple sprites, without too much visual and sound effects. It was like using a computer from the 80s again, but in a thousand times more organized, practical and fun environment. This was my first sensation when using PICO-8.

In the animation above you can see PICO-8 running with its terminal screens and code, sprites, maps, sound effects and music editors. Everything you need to create your games with a retro style! 🕹️

Definition

The term Fantasy Console was coined by Joseph White, creator of the first console of its kind, PICO-8. According to the PICO-8 FAQ:

"A fantasy console is like a regular console, but without the inconvenience of actual hardware. PICO-8 has everything else that makes a console a console: machine specifications and display format, development tools, design culture, distribution platform, community and playership. It is similar to a retro game emulator, but for a machine that never existed. PICO-8's specifications and ecosystem are instead designed from scratch to produce something that has its own identity and feels real. Instead of physical cartridges, programs made for PICO-8 are distributed on .png images that look like cartridges, complete with labels and a fixed 32k data capacity."

Advantages

The main advantages of programming for a console that never existed is that real consoles like Atari 2600, NES, Master System and others were created in order to be as powerful as possible, spending the minimum required with hardware. This makes programming for these platforms not to be very beginner friendly, after all, this was never the intention. The focus was on major studios, with many professional game developers.

Fantasy consoles can afford not to worry about it so much. They do not need to be as fast as possible or worry about the hardware production. Everything revolves around softwares. This makes the user experience much more enjoyable and a great way for beginners to enter the game development world.

Limitations

Every fantasy console imposes some artificial technical limitations. You will have to work with a lower video resolution, limited sound effects and music creation tools, reduced color palette, etc. At first this may sound like something very bad and it seems that it will be more difficult to program like this, but in practice these restrictions end up being very liberating and become one of the main attractions.

The goal is retro game development and the imposition of these limitations helps to maintain our focus. Besides, they force us to use more of our imagination. The end result is usually simple and fun to play games.

Each fancy console will impose its own restrictions. Games created with the PICO-8, for example, will have the following restrictions:

128x128 pixel screen;
Palette of 16 colors;
32Kb as the maximum "cartridge" size;
Four sound tracks;
Lua programming language;
256 8x8 Sprites;
Map with 182x32 tiles.

There are other consoles that are even more limited than that! But also some way more flexible and powerful (and consequently more complex) systems.

Some games developed for fantasy consoles

Celeste Classic

You may have heard of a game called Celeste, available for Nintendo Switch, Playstation 4 and Xbox One. What you may not know is that it was based on an homonymous game (now known as Celeste Classic) developed by the same team. This original version was developed in 4 days in a game jam, using PICO-8.

You can play Celeste Classic directly in your browser by going to this page.

Celeste Classic 2

Celeste for Switch, PlayStation 4 and Xbox One don't have a sequel and the authors have said it probably never will. But to our joy, Celeste Classic has one! With new dynamics but the same high degree of challenge. You can play Celeste Classic 2 directly in your browser by visiting this page.

PakPok

If you like platform games that mix puzzles and precision movements to advance to the next screen, you'll probably like PakPok

NanoMan

Remember MegaMan (RockMan in Japan) from the NES console? I loved this game! And I love this version of NanoMan, inspired by this game. Another really cool game made using PICO-8. You can play it in the browser in this page.

Fetch Quest

Fetch Quest is another platform game where you also have to solve puzzles, but this time you're in the role of a dog!

This game was created using the TIC-80.

Everdawn

While fantasy consoles are great for 2D platform creations, there are a myriad of other games of the most diverse styles! Among them is Everdawn. An RPG also created using the TIC-80.

And many others!

You can find more games created using PICO-8 on this page and others created for TIC-80 on this and on this other page.

Programming language and development environment

Each fantasy console will have its own development tools. Some will allow you to use several different languages and allow you to program in external editors, even containing plugins to program using the famous VSCode.
Others will require you to program in a more traditional and limited way, forcing the use of only the editing and programming tools built into the system.

Which fantasy console to start with?

There is a huge amount of fantasy consoles (and computers). A list with a summary of the characteristics of each one is available here.

You have options that will allow you to program in JavaScript, Lua, BASIC, Python, among many others. Some consoles will restrict you a lot, others will leave you very free.

Because there are so many options, some similar and some very different, it is very difficult to choose which one to start with. So I'll leave here two suggestions for you: one that needs a license to use and one free.

PICO-8

My favorite fantasy console is still PICO-8. This was the first project of its kind and the author managed to keep all the initial philosophy. It's not the most powerful but that's exactly the beauty of this project!

To develop your games you will use the famous Lua programming language and you will have at your disposal a very simple editor to use. In it you'll create your codes, your sprites, maps, sound effects and music: everything already included, very intuitive and easy to use.

But this is proprietary software. At the time of writing this article, the license costs $14.99. And you can choose to pay $5 more and also receive a copy of the alpha version of Voxatron, a fantasy console for 3D gaming that it is still being developed by the same team as PICO-8.

While there are rumors that they are working on a mobile version, PICO-8 is currently only available on major desktop platforms (Windows, Mac and Linux).

TIC-80

TIC-80 is another popular fantasy console. It is more versatile than the PIC-8 and in addition to supporting the main desktop platforms, it also has an Android version. That's right! You can run and create your games on this fantasy console right from your mobile phone!

Another very positive point of TIC-80 is that it is open-source (source code available in this github repository) and that it can be downloaded for free.

The animation above was taken from the website tic80.com.

And you? Have you ever developed games with a retro style? What are your favorite tools? Tell me about your experience in the comments!

References

Did you like this text? Checkout my other articles at: https://segunda.tech/tags/english and follow me on twitter.