the course was simple: every week the teacher would ask us to bring something we didn't notice to class, about things in our personal lives. the idea was to start rewiring our brains so we could be more effective reporters, interviewers, photographers.

sometimes the teacher asked us to bring something we noticed on the commute to the class, or something that could be newsworthy in the campus. sometimes it was something we didn't notice about someone important to us, like the way they walked, or how they talked. it didn't need to be big; just something.

some people didn't bother, and just came up with something to tell the teacher ("my mom laughs weird" became an in-joke). I took it a bit more seriously, though. in a few months, I went from "I want to turn my brain off while I commute" to "oh, there's an interesting graffiti here, I wonder what it means". since I always enjoyed photography, this class changed the way I go on walks.

so I invite you to do this experiment: the next time you go on a walk, look for things that would be interesting to you. you don't need a camera or your phone (though it helps). you don't even need to remember it afterwards - just look around you.

notice how the light hits the pavement, or how things look in a different time of day. pay attention to the people that are there, what they are doing, how they go about their lives.

bring something you didn't notice with you.

for people that know about my thoughts on AI, this is probably a logical conclusion. but for those who are not convinced, or that would like to understand a bit more about the whys, stay with me. breathe deep, this is a tough one.

let's start with some disclaimers (you may skip this)

it's hard to talk about these topics, because discussing AI use on software development is tricky. you risk alienating some people if you're too careful with your words, and you risk offending others if you're not. so, for the sake of the argument, I'll try to present my thoughts in a way that establishes a common ground. hopefully.

as in all discussions, I will assume you always remember that I'm speaking in general. edge cases and model companies and teams will always exist. discussing them here is useless, since there's no such thing as a "one size fits all" opinion. so always assume that whatever I say is prepended with "in general".

second, this is not a discussion about what AI is good or bad for, or about the ethics of AI. I won't be talking about my opinions on the tech itself, so bring me to a bar and pay me a few beers if you want to discuss them (we'll need the alcohol). here, I'll try to be as down to earth as I can.

also, this is my opinion, folks. no need to be mad. always remember there's a human being on the other side of an internet discussion. I may also make jokes, or make things more dramatic than they are, because it wouldn't be me if I didn't.

ok, here we go.

three things to keep in mind

to understand why I think that people should get a bonus for not using AI, we need to establish a few things.

AI speeds up software development

wait, I thought you were saying that people that do NOT use AI deserve a bonus, you thought.

yes. exactly. stay with me.

we already have scientific studies on how AI can speed up software development. while some are inconclusive, or end up implying that results may vary from negative to positive, some show that there is a real and significant gain in development speed.

since we're talking in general, and I don't want to talk too much about anecdotal stuff, let's assume a Good™ scenario, with gains of around 30%. yes, kind of a magic number. cool? cool.

but AI generated code is "as good as" or "worse" than a good dev's code, never better

the general consensus is that AI generated code tends to ramp up code complexity and add code with "code smells" - you know, the classic tech debt. so if we want the best results, we would need to pair up these tools with a competent and experienced developer that can recognize bad code in real time or use the AI tools in better ways.

the thing is: competent and experienced developers already are good at what they do, and will deliver better code if they just make it themselves. they are the baseline.

sure, they can get some of the speed increase (and we're assuming they do for the sake of the argument), but usually the biggest speed ups are achieved by more junior people, with stinky code as a trade-off.

friendly reminder: in general. there are edge cases, different ways to use AI, and person to person differences that will not be discussed here.

and using AI will potentially deskill your team

this might be the most controversial and situational topic of the bunch (that's why I threw in the "potentially" there). just to sum up this one: using AI tools can and probably will deskill your team if they're not careful, or make their learning journey longer - be it because they're not engaging with the code as well as they could, or because they're not remembering how the code was implemented, since they didn't write it themselves.

I'm not saying that it surely will deskill everyone; I'm not saying that your devs' brains will become goo if they touch AI. I'm saying that there is a real risk that some of your devs will become over-reliant on AI tools (yes, even Anthropic thinks so, though their answer is, who could've seen it coming, more AI). we're seeing this happen in other areas as well.

anecdotally, I've seen it happen, both with people I worked with, and with myself. it feels pretty obvious, to be honest.

oh, and it costs money

did I forget to say that? well, here it is: it costs money. you have to pay your dev and the tools.

so if you're keeping tabs, you know where this is going

assuming a good scenario (let's not talk about the bad ones), the pros and cons would be that AI tools:

• might speed your dev team up a bit. not 10x, not 2x, but a significant amount (single to double percentage points);
• will probably give you worse code than people by themselves would, with more tech debt. bad, broken, unsafe code in the worst cases, Good™ code in the best;
• risk making your team technically worse in the long run, and risk increasing the time it takes to transform junior devs into seniors, unless you have pretty strict guidelines on AI use;
• cost a significant amount of extra money.

if we have these in mind, we arrive at this conclusion: people in your dev team that opt not to use AI as much will tend to take a bit more time to get something done, but give you better code; will tend to keep their skills sharper in the long run; and will definitely save you money on that fancy AI subscription you're paying, even if it's means downsizing their AI subscription plan from the "Infinite Tokens" plan to the "I Only Have a Few Questions" plan.

so if the difference is just the type of dev person you get, and one costs more than the other, it's only fair that you just... give them the extra money you'd spend on the AI tool.

no, really, give them the money

jokes aside, I don't think what I'm saying is too far-fetched, or that this should be applied to every scenario. what I'm saying is that it's funny how most tech companies prefer to pay someone else - be it Anthropic, OpenAI, Cursor, whatever -, instead of investing in their own people. how they are always eager to outsource expertise.

so here's the deal: if the dev person wants an AI subscription, sure, give them. heck, some cases even require it, like projects that could benefit from LLM knowledge and/or integration. and knowing the basics about how AI tools work is important, even if it is only enough to be able to discuss it with people and future proof yourself.

but AI is a tool that has real costs - like those fancy JetBrains IDEs or good programming courses - and hidden costs, like tech debt and potential deskilling. if a dev person says "no, I prefer to code it myself and learn something else", not giving them a bonus is effectively punishing them for saving you money.

also, giving them the extra money sends your devs some hints: you're not doomed for not adopting AI, and you're not wrong in investing in yourself; you can try to use it if you want, see if it fits with your workflow, but know that there are trade-offs; and always remember that you'll be responsible for the code you put out there, AI assistance or not. there's already so much pressure to adopt AI out there, this might be worth it.

it also forces your company to be more mindful about the money you spend on AI subscriptions. I feel like we're currently in a spot of "we need to give the devs all them tokens", and that's not healthy for anyone involved.

oh, and if you're thinking "but this only means that you'd be punishing people that choose to use AI instead", you might need to read this post. :)

phew, I hope this whole thing made sense; this thought just crossed my brain while I was in the shower, and I just wanted to write it down so it doesn't keep nagging me. if there's anything that I missed, or if you want to curse at me and tell me I'm wrong about everything in life, talk to me on bluesky or mastodon.

this post is just a thought, not a manifesto, so please treat it as so. it's also very focused on software development, when there are other areas as well.

I tried not to put my opinions on AI in this post, but I KNOW I failed. it's hard to talk about money costs, when there are so many other costs associated with AI. but hey, I tried.

I didn't touch on a topic I wanted to, which is "what if we don't even need the increased development speed in the first place", but I thought it was too opinionated and didn't fit well with the rest of the post.

also, I did not use any AI tool to write this post (typos are my own), but I did use local models and Lumo to help me find the academic papers I linked. I still read their conclusions before linking them up, though.

so yeah, I hope to see you next time!

I hate long intros, so here we go.

summary

• the ones I've fully played
  • hollow knight
  • contradiction
  • everhood 2
  • metaphor: refantazio
  • rhythm heaven fever
  • hollow knight: silksong
  • blippo+
  • hyperbeat
  • unbeatable
  • year walk
  • bits & bops
• the ones I've tried, but didn't vibe with
  • nine sols
  • void stranger
  • skin deep
  • felvidek
• the ones I'm currently playing
  • possessor(s)
  • clair obscur: expedition 33
  • metal gear rising: revengeance

the ones I've fully played

hollow knight

it's kinda crazy to me that I only got to play this game at the end of last year. it instantly became one of my favorites of all time (surely on the top 10). I looooove games that reward exploration, allow for player creativity to flourish, and offer a bit of fair challenge, so it does not surprise me that I enjoy most metroidvanias, this one included.

I loved it so much that, right before silksong, I've replayed it in one sitting, to get my brain ready for the next game in the series.

it was definitely an obsession. not as big as silksong though.

contradiction

or Contradiction: Spot the Liar

this one was FUN. for those who don't know about it (I surely didn't before playing), it's a point-and-click detective game, focused on spotting, well, contradictions in the characters' testimonies.

the fun part: everything, from the setting to the characters, was acted with real people, on real places - so it feels more like you're interacting with a movie. you know, like we used to on those DVD menu games. #old

it all started when my brother was starting to speedrun it. the game was made with NW.js, a very... quirky webkit wrapper for desktop applications that I've used professionally before. it was the perfect game for me to mod and dive under the hood. in a few days, we found some very interesting unintended behaviors, mostly related to how the game autosaves and how it flags that a cutscene has been watched.

so I started by fiddling with the source code, and ended up just playing the game. except for a few very obtuse puzzles, it was a great time. the story is interesting, the characters are amazing, and the game never takes itself too seriously. 100% recommend it for people that have the patience for puzzle games and don't mind looking up a guide once in a while.

everhood 2

everhood 1 was a very psychedelic rhythm game I'd previously played, and had a great time with. I'm a sucker for rhythm games (as you'll see), so playing the second game in the series was a sure thing.

and yeah, it was basically the first one (very, very trippy), with a marginally worse story (if you can call it a story), and bigger scale.

if you like rhythm games, check it out. it's pretty goos. very goos even. nothing more to add.

metaphor: refantazio

a good game. a very deeply flawed game, but a good game. metaphor is a JRPG that follows the persona blueprint very closely. it fixes a lot of gameplay issues I've had with persona games, but ends up making a lot of its own mistakes, mostly in the story department.

imo, the pacing is all over the place, and there are giant plot holes everywhere. I do mean everywhere. also, the plot twists are so frequent that you can never trust anything - so I ended up not even trying to make sense of things. I won't spoil it, just in case you want to give it a go, but there's a part of the game that you go through 5 plot twists in 30 minutes, one making less sense than the next. it's SO fatiguing.

the characters, art style, gameplay, and overall mechanics are good though. nothing groundbreaking, but good. if you like persona games, you'll probably like it.

I'm glad I've played it, but it's one of those that I'll never play again.

rhythm heaven fever

wabadubadub, is that true? yeh.

the quintessential rhythm game, made for the wii. two buttons, good minigames, and a great soundtrack is all you need to make a classic rhythm game. a must play, if you can press buttons on cue.

hollow knight: silksong

without a doubt, my game of the year. it's like team cherry fixed all of the mistakes from hollow knight, expanded the world threefold, and learned how to be cruel.

let's be real: you haven't learned about this game through this post. either you already know about it and will/is/has played it, or you don't really love the genre, which is totally valid. I just need to say that ever since the game has launched, I've played it more than I'd like to admit, and sometimes I catch myself going on twitch to find some random streamer playing it for the first time.

and yes, I love it more than the first one. and it was the equivalent of 12 dollars here in Brazil, I've had lunches this week that were more expensive. it will forever be the best deal (and, at the time of writing, it's with a 20% discount on steam). a masterpiece - a very challenging masterpiece. and I would be mad that it didn't win more categories in the game awards, if the game awards weren't a shitpost.

blippo+

ok, this one was a trip. the premise of the game is: you're watching cable tv. a very weird, very different cable tv. lots of channels, lots of recurrent programs and characters, and all around a good time. of course, there's more to it than just that, but I don't want to spoil it. just grab a drink and blippo+ and chill.

hyperbeat

yeah, another rhythm game. I know, I have a problem.

hyperbeat was probably the most artsy of them all, and the one with the weirdest (but most amazing) control scheme. it's kinda hard to describe: you basically control a customizable avatar in a tunnel, and use the analog stick and the shoulder buttons to match the rhythm of tiles that appear in front of you. kind of like super hexagon, but way better.

it's a very challenging, and a very niche game, since you do need to really like rhythm games to enjoy it. but if you do, you'll have a great time. the characters and the instrumental electronic soundtrack are a blast. there isn't much of a story, though.

I'm just sad it was too short - though it's pretty cheap too.

unbeatable

guess what? it's a rhythm game. :)

this one, in my opinion, is all about the story; and the story is reeeeeally good (except for a small section, that will remain unspoiled). the game is about a dystopic society in which music is forbidden, so the setting is really interesting.

but it's also about how to deal with emotions, grief, and growing up - so be sure to have water and tissues nearby, because you are going to cry.

the gameplay is good, but some decisions are questionable. for example: the game has two lanes (one top, one bottom), and you have to press buttons when tiles appear on them, one button per lane. the problem is that the default controls are left and right triggers, instead of up and down; though they do have a reason for that.

also, the left trigger controls the bottom lane, not the top one. my brain always thinks that left is up, right is down, since I read from left to right. half of the game, my brain was short-circuiting on which button I should press. changing the settings is fully recommended.

even so, the game slowly grew on me, even the gameplay sections. the soundtrack is very nice (if you enjoy pop punk rock), the art style is gorgeous, and the characters are very relatable. it also has an arcade mode, if you want to play specific tracks on different difficulties. very nice.

I'm fully replaying it. like, right now, as you're reading this. yes.

year walk

not a rhythm game this time. year walk is a point-and-click adventure game made by Simogo, the studio behind some of my favorite games (sayonara wild hearts and lorelei and the laser eyes). as expected, it's a very interesting story that blurs the line between real and fake, with a mix of swedish folklore and spooky gameplay.

very short, and a great time. just be ready for jumpscares, they will get you.

bits & bops

aaaand we're back to rhythm games. this one is an homage to the rhythm heaven series - but it can barely be called that. it's borderline plagiarism. the minigames are really "inspired" by rhythm heaven games, so if you like rhythm heaven, you'll have a good time.

but it's just not worth the price, in my opinion. at the time of writing, it's more expensive than silksong, and it took me 3 hours to beat. I expected at least triple the gameplay. really sad.

the ones I've tried, but didn't vibe with

nine sols

yeah, I know. you're thinking "how can you like hollow knight and silksong, but not nine sols?"

I don't know, a mix of everything? personally, I don't like the art style (I can't really explain why). I'm not a fan of its parry mechanics. and I hate, hate skill trees. the story didn't really catch me, but, being honest, it didn't really have the time to, since the gameplay didn't hold my attention enough for the story to really get started.

I still don't know, but I can't see myself playing this game. it feels like a metroidvania specifically made to not vibe with me. *shrugs*

void stranger

I didn't keep playing this one not because it's bad, or that it's a bad match for my tastes. this game committed the sin of having too interesting of a story, and combining it with interesting, but grueling and long puzzle sections. it just felt like the devs said "hey, here's a great plot and interesting characters, but to read the next page you need to solve 100 wordles. yes, every page."

so I ended up just watching the story on youtube. it's really good, kind of a mindfuck really, and there definitely are some gameplay sections that tickled the right parts of my brain.

but when your job already requires you to solve puzzles every day, seeing even more puzzles as fun is sometimes a bit too much. I'll probably revisit this one one day.

skin deep

I've seen some people talk about this game with high praise, but when I tried it, it just didn't catch my attention. tbh, I didn't play it for very long, so I can't talk too much about it. seems interesting; not right now.

felvidek

this is another one of the "seems interesting; not right now". it's a very crude game, but with a cool art style, and it seems to subvert some of the tropes of the genre. but yeah, it didn't really click, so I'll leave this for the future Luciano to deal with.

the ones I'm currently playing

possessor(s)

this is another metroidvania game, and it's from heart machine, the studio behind hyper light drifter, one of my favorite games. nice aesthetics, nice soundtrack, nice gameplay, but I'm still not too fond of the characters and the story, and that's kind of a deal breaker.

I'm one of those people that prefers a game with no story or with bland characters, instead of one that does have a story, but it's bad, or that does have characters with personality, but they're annoying.

hopefully things get better on the plot department. if they don't, I can see myself skipping this one.

clair obscur: expedition 33

the motherlode of overhyping. I've played like an hour, so I don't have much to report, but this game was so hyped that I have the highest of expectations; when I know I shouldn't. I really hope it's a good one.

metal gear rising: revengeance

yeah, the meme game. I mean, it was not meant to be a meme game, but it is. it feels like a team of edgy 15 y/o metal gear solid fans wrote it, and I love it.

certainly the game I'll reach for when I have a bad day. it's laughter guaranteed.

well, that's it. all in all, I think this was an awesome year for gaming, and I've had a great time. I don't have any expectations for new games for 2026, but at the very least we'll have the silksong DLC.

if you have any recommendations, add a comment, or bug me anywhere. see you next time!

em resumo:

TLDR: LLMs are okay at coding, but at scale they build jumbled messes. I’ve scaled back my use of AI when coding and gone back to using my brain and pen and paper.

faz duas semanas, eu fiz a mesma coisa: desliguei tudo que era baseado em LLM pro trabalho. achei que seria legal compartilhar os motivos, os resultados e alguns pensamentos, por mais parecidos que sejam aos de Alberto. recomendo inclusive que leiam o post dele, é bem interessante.

e meu intuito é não discutir tanto a parte ética, apesar de eu colocar alguns dos meus pensamentos sobre isso no final do post. se você for uma pessoa só interessada na parte ética, pula pro final!

antes de tudo, vou falar do que tentei

eu sei que tem uma parcela (pequena, mas extremamente chata) que vai olhar pra esse post e falar que eu não usei os LLMs de forma correta, ou que não configurei ou passei parâmetros suficientes pros modelos; então já vou logo me defender.

eu tentei bastante coisa: desde ferramentas feitas pro uso de LLM como o Cursor, até opções como o Continue + Ollama. múltiplos projetos, múltiplas linguagens de programação, múltiplos modelos, múltiplas abordagens.

também vou dizer que eu não acho essas ferramentas inúteis. como dev frontend, muita parte do meu trabalho é lidar com estruturas repetitivas, e esse é o melhor dos problemas pra serem resolvidos com LLM.

defesa feita, vamos falar dos problemas, começando pelos que todo mundo já sabe.

os problemas óbvios

bom, o problema óbvio mais gritante é que o código gerado sempre - e eu digo sempre - é pior do que o código que você poderia escrever. se você acha que o LLM faz um código melhor que o seu, mais motivo ainda pra não usar e aprender a fazer por si só. afinal, se você não sabe fazer tão bem quanto um LLM, como que você vai revisar o código gerado?

"ah, mas é só dar acesso a sua base de código, fazer um prompt engineering, que tudo funciona bem", alguém vai dizer. vou ser direto e sincero com a minha opinião: se você tá tendo todo esse trabalho de ler artigo, testar o que funciona ou não, usar modelos diferentes pra problemas diferentes, seria mais fácil aprender como resolver o problema. você sairia sabendo mais e se sentindo uma pessoa mais confiante no que faz.

e aqui chegamos no meu ponto principal.

meu jeito de programar tava mudando - pra pior

comecei a notar que eu escrevia duas palavras e fazia uma pausa, que variava de 2 a 10 segundos, esperando uma resposta do Copilot - resposta essa que precisava de modificação ao menos 70% das vezes. ok, tudo bem, é uma ferramenta útil, mas ainda tá num estágio bem ruim.

juro pra você que eu não teria problema em virar revisor de código, desde que o código fosse bom. e quanto maior o problema, mais ele erra, ou gera algo que exige adaptação. muitas vezes eu caía no ciclo de "não tá bom, ajeita isso pra mim, nossa, ficou pior".

e eu quase posso ouvir a pessoa dizendo "comigo funciona, você deve tá fazendo algo errado", mas a verdade é que se os LLMs fossem tudo isso que as pessoas dizem que é, uma galera não estaria tendo esse problema, eu incluído. se tem uma coisa que eu me orgulho como pessoa dev é que eu sobrevivi trabalhando em frontend desde os tempos da jQuery até as doideiras de hoje, e isso demonstra uma coisa: que eu ao menos consigo me adaptar a novas tecnologias.

mas quanto mais eu usava o Copilot, mas eu percebia que eu tava perdendo a noção de como fazer as coisas, que meu cérebro ficava com preguiça de fazer na mão, e eu ficava dependendo cada vez mais de uma ferramenta que não entrega bem, e que gera muita frustração.

então eu desliguei o Copilot e...

imediatamente me senti uma pessoa improdutiva. essa é a parte que me irrita mais sobre isso tudo: eu me senti lerdo e incapaz de entregar coisas rápido. e, até certo ponto, eu tava correto em me sentir assim. agora, aquele trecho gigantesco de HTML que antes tava sendo gerado pra mim não tava mais aparecendo no autocomplete.

eis que eu descobri duas coisas: copiar e colar. claro que tô sendo sarcástico aqui, mas o que tava fazendo eu me sentir lento era a falta do retorno visual dos próximos passos. era a dopamina que era jogada no meu sangue toda vez o Copilot tava certo e eu não precisava digitar aquilo tudo, esquecendo de todas as vezes que eu tive que corrigir algo errado.

mas me forcei a passar por essa sensação, lembrar que eu trabalhei sem Copilot por mais de uma década, e que tá tudo bem. continuei o processo.

em dois dias, uma tarefa que era pra demorar uma semana tava pronta. o código tava limpo, lindo, perfumado. não tive que adaptar nada, porque não tinha nada pra adaptar; não tive que revisar nada, porque fui eu que fiz. eu me senti tão produtivo quanto antes - minto, eu me senti mais produtivo do que antes -, porque agora eu sabia o que tava acontecendo.

precisei passar por isso pra entender o óbvio, que fazer as coisas com calma nos faz bem. que meu problema com o uso do Copilot era que há uma tentação gigantesca de aceitar uma recompensa pequena em curto prazo, em vez de lutar por uma recompensa muito maior em longo prazo.

quer dizer então que você não usa mais LLM pra nada, né?

dizer que sim seria um exagero. é fato que eu cancelei minha assinatura do Copilot e removi as extensões do meu editor de texto, mas vez ou outra eu ainda uso o Chato GPT (não é um typo).

um exemplo é quando eu quero converter componentes Vue escritos com a API de options pra API de composição + script setup. outro exemplo é revisar (mas não reescrever) textos grandes em inglês, principalmente quando é algo corporativo. ou seja, coisas que eu sei fazer, mas que o LLM vai me dar um retorno muito mais rápido, facilmente revisável.

mas vou dizer que não uso mais de um prompt por semana. fica a mensagem pro povo que gosta de LLM: dá pra viver melhor sem essas ferramentas.

mas e se essas ferramentas fossem boas?

ética e ideologia

acho que não preciso dissertar sobre o quanto esses modelos de LLM foram desenvolvidos em cima de conteúdos com copyright. também acho desnecessário dizer o quanto de energia e recursos naturais e humanos são usados no desenvolvimento dessas ferramentas. esses pontos são totalmente factuais.

mas viver no capitalismo é isso: as empresas vão investir em coisas sem pensar na ética ou nas repercussões sociais. os LLMs já existem, e falar que a OpenAI é x, y ou z não vai fazer ela parar de explorar ninguém.

já que essas ferramentas já existem, o que nos resta é decidir se queremos usar elas ou não; ou melhor, qual o limite mínimo que nos faria usar. é o impacto energético? é a licensa do modelo? é a origem dos dados de treinamento? é o fato do processamento ser local ou remoto?

no final das contas, não foi nada disso que me fez tomar a decisão de cancelar o Copilot, mas o fato de eu ter certeza que eu não preciso saber mexer com LLM pra garantir meu emprego. de que eu não tô em risco de ser trocado por uma pessoa que sabe usar LLMs pra programar melhor e mais rápido.

pelo menos por enquanto.

fica aqui meu convite pra você também tentar parar de usar essas ferramentas. se tiver alguma dúvida, ou quiser me xingar, só falar comigo no mastodon/bluesky/telegram, ok? até a próxima!

só quero escrever uns negócio

olha, nada te impede de usar alguma plataforma proprietária, mas se você tá aqui, você provavelmente quer fugir delas e ter seus próprios dados. infelizmente, é um pouco difícil fazer isso sem saber um pouco de programação.

então recomendo que você comece criando uma conta no Github ou (ainda melhor) no Codeberg. com a conta e um pouco de conhecimentos de git e markdown, você pode usar qualquer ferramenta de geração de sites estáticos (SSG) e publicar em um domínio usando Github Pages ou Codeberg Pages. caso você já tenha um domínio e não queira usar o domínio gerado automaticamente, você também pode usá-lo de graça.

daqui pra frente, vou assumir que vamos usar uma ferramenta de geração de sites estáticos e que estamos usando o Codeberg como plataforma. vamo lá!

geradores de sites estáticos

geradores de sites estáticos são ferramentas que lêem seu conteúdo de algum lugar no seu computador (em geral arquivos .md) e geram páginas HTML prontas para serem servidas na web. existem várias dessas ferramentas, então vou colocar aqui as minhas favoritas, em nenhuma ordem específica.

marmite

o marmite é uma ferramenta criada pelo nosso caro Bruno Rocha, escrita em Rust, e projetada pra ser extremamente veloz e direta ao ponto. ela te dá de cara tudo que você precisa: um bom tema visual, conversão de Markdown pra HTML, feed RSS, tudo.

caso você já tenha as ferramentas do Rust instaladas, você pode instalar via cargo, mas caso você não tenha, dá pra baixar o binário diretamente.

como eu disse, o marmite é simples e direto, perfeito pra quem só quer escrever uns negócio e publicar. não vou colocar o passo a passo aqui porque a documentação é ótima, mas basicamente é só rodar um comando pra criar um post novo, escrever em Markdown e gerar o HTML.

testei localmente com os posts que já tenho no meu site (todos são em Markdown), e ele gerou todas as páginas e o RSS bonitinho, depois de eu adaptar um pouco os metadados.

como toda ferramenta simples, você vai sofrer um bocado a mais caso queira fazer algo um pouco mais rebuscado, então eu recomendo mais pra pessoas que só estejam interessadas em fazer um blog simples.

astro

o astro é, na minha opinião, um ótimo meio termo. ele não é tão veloz quanto o marmite, mas também não precisa ser, a não ser que você tenha centenas ou milhares de posts. ele também oferece tudo que você precisa, e é bem mais flexível caso você queira algo mais que só um blog.

pra usar o astro, você precisa ter o NodeJS e o NPM instalados. depois, é só entrar em astro.new, escolher um dos templates e rodar o comando que eles te dão. no meu caso, escolhi o template de blog, que foi gerado usando npm create astro -- --template blog.

ele tem um passo a passo bem tranquilo de seguir (em inglês) e também te dá opções de adicionar frameworks de frontend, pra quando você quer adicionar algo mais dinâmico nas suas páginas e posts. a documentação como um todo é ótima também.

assim como o marmite, é só criar um arquivo .md novo na pasta de conteúdo que você tem um post novo pronto. a diferença é que você pode rodar um servidor de desenvolvimento pra ver como as coisas estão sendo geradas em tempo real.

ele também funcionou com os meus posts em .md, depois de adaptar os metadados. um único problema que tive foi que eu gosto de ter o post de blog inteiro no meu feed RSS, mas a própria documentação tem instruções de como customizar o XML.

então se você quer algo mais customizado, ou pretende adicionar outras páginas além do blog, o astro é uma ótima ideia.

menções honrosas

como não quero ficar eternamente enumerando opções (que são muitas), aqui ficam outras ferramentas que são tão boas quanto as que citei, mas que pessoalmente eu não usaria ou já usei:

• Hugo: extremamente famoso, escrito em Go, mas não tão focado em blogs especificamente;
• Pelican: pros pythonistas, o Pelican é ótimo pra blogs e pequenos sites, também razoavelmente flexível;
• 11ty: baseado em JS, a ideia do Eleventy é ter o mínimo de configuração possível, com o máximo de flexibilidade de conteúdo e altíssima performance de geração de conteúdo. ótimo pra galera do Node que precisa de algo mais parrudo que o astro;
• faz o teu: se você gosta de se ferrar (como eu), não é tão difícil fazer seu próprio site que usa algum framework web e ferramentas de conversão de Markdown. se quiser um péssimo exemplo, dá uma olhada no código do meu site.

beleza, escolhi o meu e gerei os HTMLs. e agora?

agora é seguir o passo a passo do Codeberg Pages. em resumo, o caminho mais fácil é:

• cria um repositório no Codeberg pro código fonte e taca seu código lá;
• cria um segundo repositório no Codeberg chamado pages (tem que ser esse nome). não inicializa com nada não, e deixa a página com as instruções finais aberta;
• na pasta do seu projeto, cria uma pasta pages;
• dentro dessa nova pasta, cria outro repositório (git init) e aponta pro repositório pages usando os detalhes da página de instruções no Codeberg;
• quando tiver com o conteúdo pronto, gera os arquivos HTML e copia tudo pra pasta pages;
• commita tudo e dá push pra ambos os repos.

se tudo deu certo, você vai ter seu site pronto e acessível em https://nome-do-seu-usuario.codeberg.page. quer um post novo? adiciona o conteúdo, gera e copia o HTML, faz o push, tá no ar.

se quiser exemplos de como isso funciona, dá uma olhada nos meus dois repositórios no Codeberg, tem todos os detalhes lá. caso queira usar o astro então, é só fazer fork e seguir com a vida.

depois é configurar seu domínio, caso queira e tenha um, e seguir postando! qualquer dúvida ou sugestão, manda aqui nos comentários ou fala comigo no Mastodon ou Bluesky. abraço pra quem é de abraço e até a próxima!

então por que as empresas não migram pra Svelte? e o que nós podemos fazer sobre isso?

acho que consigo resumir meu pensamento em alguns pontos, então aqui vai o tl;dr:

• as empresas que vendem frontend moderno acham "mais fácil" contratar pessoas e vender projetos que usam React ou Vue;
• empresas que compram esse software não querem o risco de perder dinheiro comprando algo que usa uma ferramenta vista como nova, quando as alternativas são mais sólidas e famosas, como React e Vue;
• empresas em geral não querem gastar dinheiro pesquisando ferramentas novas, quando as que existem funcionam.

vou usar o React como exemplo principal pra comparar, mas mais como um símbolo de ferramentas com maior adoção. então bora explorar cada tópico um pouquinho mais.

contratar pessoas e vender projetos em React é "mais fácil"

já ouvi essa frase várias vezes, principalmente quando citei que Svelte - principalmente o Svelte 5 - era muito fácil de aprender e de manter a longo prazo. as empresas adotam essa postura de contratar pessoas e vender projetos em React por ser uma decisão mais fácil, cujos custos são fáceis de estimar, mesmo que isso acarrete em ineficiências.

por exemplo, abrir vagas em Svelte significa:

• ter gente interna que treine pessoas em Svelte (mesmo que o treinamento seja ridiculamente curto);
• saber qual o preço de mercado de pessoas que trabalham com Svelte;
• aceitar que muito menos pessoas vão se candidatar, por mais que qualquer pessoa que saiba outros frameworks consiga trabalhar com Svelte em pouquíssimo tempo.

na hora de vender um produto pra outras empresas, convencer a pessoa que tá te contratando que seu projeto vai ser mais estável e mais fácil de manter em longa data já é uma baita tarefa. isso se torna ainda mais difícil se essas pessoas não conseguirem reconhecer imediatamente a ferramenta principal que vai ser usada no projeto, sejam essas pessoas devs ou não. as chances de tomar uma decisão correta crescem muito se essa ferramenta que vai ser usada já for famosa.

a verdade é que o caminho mais fácil não é o que as pessoas dev querem, ou o que é objetivamente melhor pro produto, mas o que as empresas já usam.

comprar projetos em tecnologias "novas" é um risco

acho que não preciso explicar muito sobre isso. React, por exemplo, é um projeto famoso desde 2013; o Angular, desde 2010. foram projetos extremamente inovadores, que mudaram o jeito com que a gente faz frontend. o futuro dessas ferramentas é visto como algo 100% garantido. algumas pessoas já chamam ferramentas como o React de "ferramentas de legado", que ficarão em bases de código por décadas.

e isso é algo que o Svelte não é, e não vai ser tão cedo.

não é um problema só de adoção, documentação ou ecossistema, mas de percepção de longo prazo. mesmo nós, que gostamos e acompanhamos o Svelte faz muito tempo, não temos certeza de até quando a Vercel vai ter dinheiro pra bancar o desenvolvimento do Svelte, e mesmo que a Vercel fosse uma empresa com uma marca mais forte, não temos como comparar ela com a Meta.

então na hora de comprar um projeto, o nome React tem peso.

empresas não querem investir em ferramentas "novas"

é rara a liberdade das pessoas dev pra criar projetos nas tecnologias que elas querem dentro de empresas. mesmo quando, em raríssimas situações, as pessoas dev possam tomar de decisões de maior impacto, sempre há a necessidade de explicar os motivos da adoção de uma nova ferramenta pra quem é gerente, ou é da parte de negócios.

isso quando essa discussão pode acontecer, que também não é algo comum de acontecer.

para as empresas, minimizar riscos vem antes de investir em inovação. por isso, o tempo de estudo em uma ferramenta nova, mesmo que sejam poucas horas, significa "perder dinheiro" pro pessoal de negócio, principalmente quando React funciona, e funciona bem.

então o que podemos fazer?

antes de tudo, precisamos continuar o trabalho que já fazemos: traduzir documentação, criar conteúdo, publicar ferramentas novas, etc. também acho óbvio dizer que, no caso do Brasil, nossa comunidade perdeu bastante força, e falta gente pra tomar a frente de fazer encontros online e conteúdos em língua brasileira (não foi um typo). sem esses fatores, fica muito difícil mudar a cabeça de empresas.

mas, na minha opinião, o mais importante é mostrar como é objetivamente melhor usar Svelte pras pessoas que trabalham com a gente. isso significa criar e compartilhar aquele projetinho de fim de semana com a galera, fazer um blog, conversar com mais gente, tomar pra si a decisão de fazer um projeto interno da empresa usando Svelte.

e eu sei que nada disso é fácil de fazer. a gente já trabalha demais, toma risco demais de ser demitida, e, em grande parte, ganha pouco pro que a gente faz.

mas como em tudo na vida, a gente só ganha confiança e transparece essa confiança aos outros quando a gente sabe como e quando usar as ferramentas - suas aplicações, seus limites, seu produto final. sem essa confiança, a gente não convence nem nós mesmos de que dá pra usar Svelte em projetos grandes e corporativos.

pra fechar, deixo aqui o link pro código do meu blog e pras [minhas ferramentas de fazer live]. bora compartilhar algo em Svelte?

This is an update to my 2022 post about this issue. Since we're now at the Svelte 5 era, stores are starting to be deprecated, so here's the update.

Sometimes, when the internet connection is not ideal, SvelteKit apps might look like they froze when navigating to another page. This is how I solved this issue.

SvelteKit provides a lot of useful state objects that may give you a better insight on how the app is behaving. One of them is the navigating state. Whenever the client-side routing is transitioning between pages, this state is updated with the paths of where you're coming from, and where you're going to (and some other useful data):

{
   from: "/"
   to: "https://ratamero.com/blog"
}

When it's not transitioning between pages, the from and to keys just return null. That allows us to add an {#if} block that renders a loading overlay is there's any value on the store:

<script>
  // ...
  import { fade } from "svelte/transition";
  import { Circle3 } from "svelte-loading-spinners";
  import { navigating } from "$app/state";
</script>

<!-- ... -->

{#if navigating.to}
<div class="fixed w-full h-full z-10" in:fade={{ duration: 150 }}>
  <div class="absolute w-full h-full bg-white dark:bg-cyan-800 opacity-50 z-10"></div>
  <div class="absolute w-full h-full flex justify-center items-center z-20">
    <Circle3 />
  </div>
</div>
{/if}

This implementation works fine, but there's a problem: since SvelteKit is really fast, the user may see flashes of the loading overlay when navigating, since there's simply no time for the user to recognize that the flash is the loading overlay.

To fix that, I added a navigationIsDelayed state to my base +layout.svelte that listens to the navigating.to state and only changes it's value to true when the navigation is hanged for more than 500ms:

let timer = null;
let navigationIsDelayed = $state(false);

$effect(() => {
	if (timer) {
		clearTimeout(timer);
	}
	if (navigating.to) {
		timer = setTimeout(() => {
			navigationIsDelayed = true;
		}, 500);
	}
	navigationIsDelayed = false;

	return () => {
		if (timer) {
			clearTimeout(timer);
		}
	};
});

Notice the timer is a plain JS variable, since we don't want the effect to be triggered when timer's value changes.

This way, the loading overlay only appears if the user's internet is so bad that can't load a couple of KBs in less than 500ms.

That's it for now! I hope this was useful to you, and see you next time :]

IA veio pra ficar

pra felicidade de uns e chateação de outros (eu tô no segundo campo), IA teve um papel bem grande no evento. das 23 palestras, 6 tinham IA como tópico principal. até pra mim, uma pessoa que não gosta do assunto, algumas foram interessantes, como a de "IA Generativa no Combate à Desinformação" e a de Langflow; mas ficou o sentimento de que foi um pouco demais pra um mesmo assunto.

diversidade importa cada vez mais

achei maravilhoso o quão diverso foi o público e as pessoas palestrantes. tivemos muitas, MUITAS palestras maravilhosas sobre isso, sob várias perspectivas: carreira (Sankofa: Educação em Tecnologia e Sonhos de Carreira), comunidade (Orumverso: Tecnologia Afrorreferenciada Na Prática) e inclusão (Inclusão e diversidade - do discurso para a realidade), dentre outras.

essa última foi a que me abriu mais os olhos, por abordar um assunto que eu praticamente nunca vejo abordado, que é o da neurodivergência. é impressionante pensar em como empresas geralmente não tem estrutura, tanto hierárquica quanto física, pra lidar com pessoas neurodivergentes. também foi interessante pensar em quanto o modelo 100% remoto remedia grande parte dos problemas presentes em empresas em geral.

vinta trazendo sua experiência com django, como sempre

na questão técnica/web, a vinta sempre entrega bastante conteúdo bom, e não foi diferente dessa vez. a palestra do Bessa sobre django migrations foi muito rica, e trouxe pra mim duas ferramentas que vou ter que olhar mais a fundo: django-pg-zero-downtime-migrations e django-safemigrate.

só ter uma trilha: qualidade vs quantidade

esse evento foi bem diferente dos outros em um aspecto: não tivemos múltiplas trilhas de palestras. isso teve uma série de repercussões; algumas positivas, muitas negativas (na minha opinião). sem dúvida, a qualidade das palestras foi altíssima, e o experimento de ter uma trilha só funcionou muito bem.

no entanto, menos trilhas significa menos espaço e menos gente participando. senti falta de ter palestras menores, com pessoas mais iniciantes, sobre assuntos de nicho. ter mais palestras menores incentiva quem tá entrando na comunidade, recompensando essa entrada com um palco.

também temos o problema de vivermos em um momento em que um assunto é dominante, como IAs. meu caso foi esse: eu não tenho nenhum interesse na área, e se um terço das palestras é sobre um assunto que você não tem interesse, não importa o quão alta é a qualidade do conteúdo.

apesar dessas opiniões, achei o experimento maravilhoso e super bem executado. o pessoal da organização mandou bem demais, e valeu muito a pena - mas definitivamente é outro tipo de evento.

comunidade, comunidade, comunidade

uma coisa sempre é certa: a comunidade de python no brasil continua linda. pra ser sincero, não importa o formato do evento, ou o conteúdo ser útil ou não, eu sempre vou ter um grande motivo pra ir às pybrs, rever velhos amigos.

já comprei o ingresso pro ano que vem, que vai ser em São Paulo. vejo vocês lá!

Esse post foi publicado originalmente em 2019. Não sou muito fã da maneira com que escrevi, então dei uma reeditada. No entanto, o conteúdo é bom e vai ser útil, então decidi repostar.

Escrever texto é muito difícil. Pra nós programadores, as coisas muitas vezes fazem total sentido dentro da nossa cabeça de uma maneira intuitiva. Mesmo assim, colocar as ideias no papel parece ser uma tarefa monumental. Nessas horas, ter me formado em jornalismo me ajuda muito - então vim aqui compartilhar com vocês algumas das coisas que me ajudam a escrever um post ou formatar uma palestra. Vamos lá!

Problemas mais comuns

Quando eu converso com a galera da Labcodes, eu noto que os problemas mais comuns são os seguintes:

• não saber qual assunto abordar;
• não saber o que falar sobre dado assunto;
• não conseguir encadear o conteúdo direitinho;
• não saber como concluir ou resumir o texto.

A questão é que jornalistas fazem isso o tempo todo; até quando não devem.

A matéria jornalística que chocou o mundo

E se você tá se perguntando, sim, nós temos uma receitinha de como fazer essas chocantes matérias.

Ao pensar sobre o assunto, o importante é o público

Quando você começa a pensar sobre um post/palestra, a primeira coisa que eu gosto de fazer é pensar em quem vai ler/assistir ao conteúdo. Esse post é pra prospectar clientes? Então de repente vale ter os valores do cliente na cabeça. É uma palestra pra iniciantes? Então vale deixar de lado os jargões.

Outro fator importante é ter em mente que um post é uma via de mão dupla. Você, autor, está contribuindo com algo que você pode dar (conteúdo, entretenimento) em troca pelo que a pessoa leitora pode dar: atenção.

Manter essa troca de informação por atenção é essencial se você quer que as pessoas continuem lendo seu texto.

Pra fechar essa parte, uma boa dica pra resolver sobre qual assunto abordar é pensar sobre o que te frustra diariamente como profissional. Os ModelSerializers do DRF te incomodam por serem acoplados demais? O docker é muito complicado de configurar? Então provavelmente esses são assuntos que poderiam interessar a outras pessoas. E com o assunto em mãos…

…tudo começa com uma frase

A gente tem que começar de algum lugar, certo? Pessoalmente, acho a primeira frase muito importante. Ela delimita o tom do texto; e ela nem precisa dar informações sobre o assunto. Pode ser algo como:

• Fazer deploy é chato.
• É 2019 e ainda tem muita gente que não usa grid nos layouts.
• Essa é a história de como eu descobri o Flask.
• Escrever texto é muito difícil.

Pegando o exemplo do deploy, vemos que a primeira frase geralmente é o porquê de você estar escrevendo o texto. O que você quer com essa frase é dar contexto e se engajar com o leitor. Fale algo que faça a pessoa leitora pensar “putz, é verdade, deploy é chato mesmo, quero ver que que essa pessoa vai falar”.

E com o tom dado, a gente pode continuar o primeiro parágrafo com informações mais precisas sobre o tópico. Você poderia continuar, por exemplo, com “Aqui na Labcodes, a gente resolveu esse problema com x, y, z de uma maneira bem elegante e simples”. Algo que deixe claro sobre o que você vai falar, deixando os detalhes pro corpo do texto.

Pra concluir o primeiro parágrafo, é importante ter algo que ligue o que você disse com o que você vai falar. Ainda no caso do deploy, poderia ser algo como “Mas as soluções que nós demos criaram um novo desafio: como vamos usar x, y, z nos nossos projetos legados?” que deixaria a pessoa leitora pronta e interessada em ler a próxima parte do texto.

A estrutura de contexto > informação > ligação é uma boa receita tanto pra começar quanto pra escrever todo o texto.

E com o primeiro parágrafo rascunhado, as coisas ficam bem mais simples.

Escrevendo o corpo do texto

Escrever o corpo do texto geralmente é mais fácil. Nesse ponto, você provavelmente já tem uma noção de quais tópicos abordar, e já dá pra montar qual parte vai ver depois da outra. Mesmo assim, é importante ter algumas coisas sempre em mente.

Lembra que eu falei pra ter em mente seu público ao escrever? No corpo do texto, isso é importante pra você saber como dosar partes de respiro. Essas partes geralmente são imagens, gifs, subtítulos ou frases de destaque.

No corpo do texto, mais que nunca, a troca entre informação e atenção é essencial.

Pra me manter focado, eu gosto de me dar um número de minutos pra escrever cada parágrafo. Isso me previne de ficar mexendo em coisa que já tá pronta enquanto eu podia estar pensando em outra coisa. Escrever é um processo cíclico (iterativo) e de descoberta, então é melhor você escrever muito e cortar o que é demais do que ficar polindo um parágrafo e nunca terminar o texto.

De resto, é repetir a estrutura de contexto > informação > ligação e escrever a conclusão.

Legal, mas meu problema é exatamente concluir!

Relaxa, já chegamos no que te interessa então! Como sempre, tudo depende de quem vai estar lendo o texto e qual sentimento ou informação você quer que a pessoa saia dali sentindo ou sabendo. Pra facilitar, eu gosto de falar sobre três possíveis padrões de conclusão:

• revisão;
• opinião;
• referenciação.

Revisão é o mais autoexplicativo. Pense exatamente sobre o que a pessoa precisa sair do post sabendo, ou o que é mais difícil de entender, e escreva sobre. Um exemplo seria o seguinte:

“Vimos hoje que o Django Rest Framework tem muitos pontos de acoplamento, mas que com uma boa estrutura de código, podemos testar tudo sem abrir mão da documentação automática. Lembre-se de separar bem a lógica de negócio do framework e testar tudo direitinho. Nos vemos por aí, até a próxima!”

Opinião é um pouquinho mais complicada. Se você está concluindo com uma opinião, é importante que todo seu texto tenha já expressado sua opinião, e que a conclusão seja só para que a pessoa saiba resumidamente qual opinião foi dita. Por exemplo:

“O Django Rest Framework deixa muito a desejar. Os ModelSerializers, além de lentos, geram um acoplamento muito grande entre os Models e a API. Pense bem se ele é a melhor opção antes de entrar de cabeça, e cuidado com os hacks. Nos vemos por aí, até a próxima!”

A forma mais popular de concluir, no entanto, é o referenciação. Basicamente, você deve falar sobre onde a pessoa pode adquirir mais informações sobre o assunto. Algo como:

“Caso queira saber mais sobre o Django Rest Framework, leia a documentação (link) e veja essa app Django que eu criei com os exemplos (link). Não tenha medo de comentar com as suas dúvidas, e se quiser dicas sobre casos específicos, falem comigo no telegram da Python Brasil. Nos vemos por aí, até a próxima!”

Epa, então fechou, né?

Pera, calma, tenho umas coisinhas pra falar ainda, mas é jogo rápido! Com o texto pronto, se dê um tempinho pra colocar em bold as palavras-chaves; isso ajuda muito quem tá lendo rápido ou relendo pra pegar referências.

E se você não tá se sentindo bem com alguma parte do texto, tente identificar qual frase ou qual termo tá te deixando desconfortável. Às vezes é uma palavra, às vezes é o fluxo da frase, mas muitas vezes é a ordem gramatical mesmo. E eu não quero falar de gramática não.

No pior dos casos…

…comece do zero. Sério. Como tudo na vida, escrever bem é questão de prática. No começo, vai demorar muito e vai ser um processo chatinho, mas depois de você internalizar o processo, você vai conseguir criar em cima disso com uma certa facilidade.

E se teve algo que você queria que eu falasse sobre e eu não falei, pode me xingar no twitter. Mentira, melhor que você me diga nos comentários mesmo, com calma, pra eu poder complementar depois. Valeu pela atenção, e nos vemos na próxima!

tl;dr

if you want a simple answer, I don't really have one. both of them are better for specific cases, and both are "good enough" for 99% of the scenarios.

that being said, my gut feeling was right, and I ended up liking the developer experience of SvelteKit better. it comes around to the features that I care about most, like simplicity, amount of code, and, well, using Svelte instead of React.

if you want to just look at the code, here are the repos. just be mindful that they are proof of concepts, so I bypassed most of the things I would do properly on a real app, like better error handling and a more intuitive UI.

• https://github.com/lucianoratamero/sveltekit-todo
• https://github.com/lucianoratamero/nextjs-todo

there's a bit more nuance to it, so if you're interested on the details, here they come.

the project

whenever I try to test a full-stack framework (which is the case for both of them), a CRUD scenario with small bits of interactivity is always a good proof of concept. to do that, I opted to use Prisma to interact with a Postgres database (provided by Supabase, which was a great combo), and to make a simple 'todo' app, with editable and autosaving todos.

that meant that the user would have to be able to not only create the todos, but update them inline, and having them autosave whenever the user changes the todo in any way. this way, I could test the front-end features (sending data automatically to the backend, adding loading overlays, etc.), while experimenting with ways to interact with the data on the back-end.

I also used TypeScript for the Next.js app, and TypeScript in comments (JSDoc) for the SvelteKit app, which are both recommended by their own stacks. both of them were deployed to Vercel.

lessons learned from Next.js

as I expected, developing with Next.js was really straightforward. whenever you create an app, it comes with plenty of examples, so you don't really need to go to the docs as much; and when you do, the docs are great.

the way we deal with creating and updating data in a Next app is really close to what people are used to with React: get data from the form, send a fetch request to an API endpoint, update the UI with the new data, done.

creating the API endpoints was pretty easy, so I have absolutely nothing to complain about this topic. great job by the Next team.

there were a couple of problems that I needed to go through, though. for example, using TypeScript with React requires a bit of a learning curve, and the temptation to not type anything is pretty big. I already had a little of experience with it, so it wasn't that time consuming, but it's always, always frustrating to not get something done because of mismatching types that you know are compatible. Prisma helped me a lot on this front, since it autogenerates types for the database models.

another issue was, well, working with React again. I know, React pays my bills, but there's not that much argument to keep using it, since most frameworks, including Svelte, are way ahead of it in many aspects. I always feel that React requires more of my brain to work with, and that the cognitive load is always a bit bigger than it should.

I also couldn't make the forms work without javascript - at least not in an easy way. I'll talk more about it on the SvelteKit section.

some other small things that bugged me were not having Prettier installed by default, not having the possibility of having a test structure set up from the start, and having to force a page reload to update the content of the page in a little bit of a hacky way. nothing major, though.

but SvelteKit... oh, man, I loved working with SvelteKit.

lessons learned from SvelteKit

first of all, most of the good things from Next were found in SvelteKit as well, like file-based routing and architecture in general. but I think it's safe to say most of the good parts were even better here.

for example, when creating a SvelteKit app, the CLI asks me a few questions that helped me a lot from the get-go. not having to set up Prettier and Playwright helps a lot when you're starting a project.

I also felt like I was just writing HTML with sprinkled bits of JS instead of JS everywhere, and that's an easy win provided by Svelte, the whole "use the platform" thing. I wrote the forms like real forms, I dealt with native Request and Response objects instead of something custom, and that even helped me learn a bit on how HTML forms work.

another thing that caught my eye was that it was really easy to make the forms work without JS, since SvelteKit comes with the use:enhance action. just by adding use:enhance to the form tag (and, in my case, adding a callback to turn the loading overlay on and off), SvelteKit is able to provide an app-like experience to a normal HTML form, not needing a full page reload.

there's also the form actions feature, that allowed me to not need to write API endpoints, giving me a simpler way to deal with forms. in summary, the whole CRUD experience was simpler and required less code. it did take me a one-time while to learn how to make them, though, since they're specific to SvelteKit.

there were other small improvements as well, like autogenerated types for server to client page data, faster build times (like 3x faster), smaller bundles (70k vs 280kb), and slightly lower layout shifts.

it wasn't all good, though. Intellij users, like myself, have to deal with a worse developer experience when writing typed code, because JetBrains hasn't made much effort to make the Svelte plugin as good as the one for VS Code (so I just used VS Code instead). also, SvelteKit is clearly the less stable and debuggable of them both, since Next is a way more mature and battle-tested platform. it's also missing some of the key features from Next, like Incremental Static Regeneration, making SvelteKit not proper for all types of apps.

conclusion

as I always say, when making the decision to use one vs the other, everything depends on everything. they are clearly better for different use cases. but if you asked me which one I liked more, I can't stress how much I enjoyed developing this app with SvelteKit. it took me a little bit to understand some of the naming conventions and the design decisions, but when I did, everything just clicked - and it didn't take more than a few hours to understand the differences.

I also really, really enjoyed using Prisma as a database ORM with Supabase. the experience was so good that now I'm seriously considering leaving Django behind and just using SvelteKit + Prisma for full stack apps. I can make another blog post about it, if people want me to.

I'll leave you with my pros and cons for each framework, and if you have anything to ask or add, be free to use the comments :]

pros and cons

Next.JS

pros

• really easy to get started
• familiar to those that are used to the React way
• great docs

cons

• react's DX is seriously lacking in comparison with svelte
• typescript on react is a bit hard to understand sometimes. prisma helped a lot with their autogenerated types for models
• didn't come with prettier installed out of the box (personal preference)
• still needs js to create/update data (or, in other words, it's not easy to do so)
• bigger bundles and slower build times

SvelteKit

pros

• the cli to create the project is great
• closer to "the platform" - I ended up learning a lot about how forms work
• form actions take a bit of time to properly understand, but when you do, they're awesome
• progressively enhanced forms means my forms will still work if js fails or is blocked
• svelte improvements: less code, less cognitive load
• significantly faster builds and smaller bundles

cons

• bad integration with my preferred IDE (intellij idea)
• missing big features such as incremental static regeneration
• a little bit harder to debug when things go wrong, mainly on the back-end

getting started

when I'm trying out a new language, there are a few pain points that make me lose my interest fast. they are mostly:

• difficulty on starting a project: I'm way too spoiled with Python and JavaScript, so if installing the language tools, configuring the IDE, and writing and executing code demands a manual, I won't do it;
• weird syntax: to me, programming should be democratic, should be readable. of course, every language will introduce new things, and, for that, new syntax needs to be introduced - but if your programming language is not easy to intuitively understand, or the balance between readability and features is too big, that turns me off. currently, my limit would be something like Rust, which is hard to understand, but extremely powerful;
• weak standard library and bad dependency/module management: in my opinion, if the language has a bad or problematic standard library (hello JS!), or if the tools for dependency/module management are complicated (hello Go!), I'll struggle a lot;
• bad documentation: well, I don't think I need to explain this one;
• too many hoops needed for me to test my code: when I play with a language, I need to get confident with it, and one of the ways to be confident is to have a simple way to create and run tests. I don't really mind having to install separate tools to test my code, but it has to be simple.

I'll go topic by topic in the next sections.

starting an Elixir project

to start a project, you need to install Elixir (it was one command), then run mix new. that's it. configuring the IDE was as straightforward as with other languages: install the plugin, set up which version I was using, and that was it as well, it all worked on the first try.

writing new code was easy (I'll talk about the syntax next) and running it was a breeze. even the interactive shell (iex) was easy to use, and together with mix (which comes with the language), I was recompiling and executing code in minutes.

Elixir's syntax

the first thing to note here is the elephant in the room: Elixir is a language based on functional programming. somehow, inside my head, functional programming made a lot of sense, but came with a huge syntax cost. I had played with Elm and even a bit of Haskell before (not that I remember anything about them), and both of them left me a bad impression. for the old me, the syntax you needed to learn was far too abstracted from what the code was doing, while being far too powerful to ignore.

so when I started playing with Elixir last week, I came prepared, clad in armor, ready to dig in and get my hands dirty.

but the confusion and the weird syntax never came. in fact, I didn't remember how close to Ruby the language feels; at least at first. I felt like I was just playing around with functions, and that was exactly what I was doing - without fear, without any of the hardships I was expecting.

that left me open to appreciate some of the amazing features Elixir has - and I don't use the word amazing lightly.

here's a sample of Elixir's syntax. tell me if it's hard to understand:

defmodule Cards do
  def create_deck do
    values = ["Ace", "Two", "Three", "Four", "Five"]
    suits = ["Clubs", "Spades", "Hearts", "Diamonds"]

    for suit <- suits, value <- values do
      "#{value} of #{suit}"
    end
  end

standard library and dependency management

Elixir's standard library, at least as far as I've gone, is no more than expected for a functional language. the Enum module has everything you need to deal with lists, and if you know the basic types and knows how to deal with lists, you're mostly set.

installing new dependencies with hex was pretty easy too. not as easy as on JS (npm install packagename) or with Python + Poetry (poetry add packagename), but still easy enough. you just need to run mix hex.info packagename, copy the package info into your mix.exs file and install it with mix deps.get. pretty straightforward, so no complaints here.

documentation, oh, beautiful documentation

not only Elixir's documentation is plentiful, but it's also easily searchable and literally built into the language. it was really easy to find what I needed with a couple of web searches, and, together with the IDE's autocomplete, it was a bit rare to really need to search for it.

if, for example, you want to understand how the Enum module works, you just need to go into the interactive shell by running iex, then type h Enum. that gives you all you need to know about the module right from the command line. the same goes for module functions. for example, h Enum.split returns you this:

testing Elixir code

whenever you start a new project or module, it automatically creates a test file for it. not only that, but it also has all the basic tools to test your code built-in. I just needed to run mix test and the test was running.

that would be enough for me to give it more than a passing grade, but there was one more thing that caught my eye, and that's insanely useful: Doctests.

when you're writing your Elixir code, as with any other language, it's encouraged to write documentation for your functions. here's what it looks like:

defmodule Cards do
  def create_deck do
    values = ["Ace", "Two", "Three", "Four", "Five"]
    suits = ["Clubs", "Spades", "Hearts", "Diamonds"]

    for suit <- suits, value <- values do
      "#{value} of #{suit}"
    end
  end

  @doc """
    Deals cards to a hand, returning the hand and the deck's remaining cards.
    The `number_of_cards` argument relates to the size of the hand dealt.

  ## Examples
      iex> {hand, _deck} = Cards.create_deck |> Cards.deal(1)
      iex> hand
      ["Ace of Clubs"]
  """
  def deal(deck, number_of_cards) do
    Enum.split(deck, number_of_cards)
  end
end

do you see the Examples section above the deal function? cool, right? it's always nice to add examples on how the code works, right? what if I told you that the example you see there is already a test? because it is. if you open the test file, you'll see this:

defmodule CardsTest do
  use ExUnit.Case
  doctest Cards
end

the doctest line signals to the testing framework that you want to use the examples inside of the documentation as tests, and it's generated by default. so if I run mix test, I'll see this:

that not only gives you a free test for your code, but it also encourages you to write the docs and to keep them updated. this is the first time I've seen such a feature on any stack, and for that to be built into the language is awesome!

btw, you can also generate a full fledged static site from your code documentation too with ex_doc. just install it and run mix docs and it's done.

so yeah, I really like it

I'll keep on learning and trying to document some of the cool and bad things here on the blog. I've not been this interested in learning a new programming language in ages, so I'll be completely honest with my findings. my goal is to properly understand what I'm doing when I get to a Phoenix app, but that will probably take a while.

any thoughts or questions? leave a comment! and, as always, thanks for your attention :]

Quick summary on how I listen to music

So, as millenials do, I have grown listening to cassette tapes, CDs, and eventually MP3s. I remember being 15, using a huge ass pair of headphones (real cheap ones too) with my 128MB MP3 player - and it was awesome.

With time, I grew my MP3 collection, both through good channels (like bandcamp for example), and less... legal channels (like Napster, Kazaa, and Souseek, whic I still use now and then). I can't say my library is big, but it's around 4200 musics in size.

The problem is that a good chunk of it is garbage; not in quality of the music itself, but in the quality of the file compression. And now that I have the money to get some better headphones, some of my music library is just too dank.

As with anything, Python can help me.

Enter mutagen

mutagen is a Python library that helps us to find metadata for our audio files. After discovering it, discovering which MP3 files were too compressed was pretty straightforward.

First, I installed it locally (in my case, it was already installed somehow. I probably fiddled around with it in a distant past):

pip3 install --user mutagen

Then, I wrote a quick and really dirty Python script to tell me which of my MP3 had a bitrate lower than 256kbps. The higher the bitrate, the less it's compressed:

import os
import mutagen


def list_dank_mp3s(folder):
    matches = []
    for root, dirnames, filenames in os.walk(folder):
        for filename in filenames:
            if filename.endswith(".mp3"):
                # I didn't take the time to understand 
                # why it was formatting things wrong
                # so I just hammered the names
                matches.append(os.path.join(root, filename)[:-1] + "3\n")

    bad_mp3s = []
    for item in matches:
        # here, we get the bitrateof the MP3 file
        # there are a LOT of other metadata there,
        # if you want to use it
        bitrate = mutagen.File(item.strip()).info.bitrate
        # if the bitrate doesn't end with 000, it means it's most likely variable
        # if it is, we leave it be. if not, we check if it's below 256kbps
        if str(bitrate).endswith("000") and bitrate / 1000 < 256:
            bad_mp3s.append(os.path.join(os.path.dirname(os.path.abspath(__file__)), item))
    return bad_mp3s

This function gives me a list, that has the paths of the MP3s that I may want to buy or redownload in a better bitrate. I then write the list to a file, and voilà, all my bad sounding MP3s are listed.

Do you have any other uses for this kind of library? Do you have any tips on good headphones? Send me a comment down here so we can keep the discussion going! Thanks for your attention, and see you next time :]

SvelteKit provides a lot of useful stores that may give you a better insight on how the app is behaving. One of them is the navigating store. Whenever the client-side routing is transitioning between pages, this store is updated with an object that contains the paths of where you're coming from, and where you're going to:

{
   from: "/"
   to: "https://ratamero.com/blog"
}

When it's not transitioning between pages, it just returns null. That allows us to add an {#if} block that renders a loading overlay is there's any value on the store:

<script>
  // ...
  import { fade } from "svelte/transition";
  import { Circle3 } from "svelte-loading-spinners";
  import { navigating } from "$app/stores";
</script>

<!-- ... -->

{#if Boolean($navigating)}
<div class="fixed w-full h-full z-10" in:fade={{ duration: 150 }}>
  <div class="absolute w-full h-full bg-white dark:bg-cyan-800 opacity-50 z-10"></div>
  <div class="absolute w-full h-full flex justify-center items-center z-20">
    <Circle3 />
  </div>
</div>
{/if}

This implementation works fine, but there's a problem: since SvelteKit is really fast, the user may see flashes of the loading overlay when navigating, since there's simply no time for the user to recognize that the flash is the loading overlay.

To fix that, I created a navigationIsDelayed store that listens to the navigating store and only changes it's value to true when the navigation is hanged for more than 500ms:

import { derived } from "svelte/store";
import { navigating } from "$app/stores";

let timer = null;
export const navigationIsDelayed = derived(navigating, (newValue, set) => {
  if (timer) { clearTimeout(timer); }
  if (newValue) {
    timer = setTimeout(() => set(true), 500);
  }
  set(false);
});

Then updated my __layout.svelte using the new store:

<script>
  // ...
  import { fade } from "svelte/transition";
  import { Circle3 } from "svelte-loading-spinners";
  import { navigationIsDelayed } from "$lib/stores.js";
</script>

<!-- ... -->

{#if $navigationIsDelayed}
  <div class="fixed w-full h-full z-10" in:fade={{ duration: 150 }}>
    <div class="absolute w-full h-full bg-white dark:bg-cyan-800 opacity-50 z-10"></div>
    <div class="absolute w-full h-full flex justify-center items-center z-20">
      <Circle3 />
    </div>
  </div>
{/if}

This way, the loading overlay only appears if the user's internet is so bad that can't load a couple of kbs in less than 500ms.

That's it for now! I hope this was useful to you, and see you next time :]

Every time you see a link, I encourage you to take a look. Most of them are not direct external links, but notes I've made about that topic. Some of the information there can complement what you're reading right now :]

How it was

My previous site, while entirely made by me and very customized, was not 100% easy to maintain. It already used SvelteKit, but in a very, very dumb way. The thing is: I wanted to keep old posts alive, and they were converted to plain HTML, which was served by SvelteKit, and that was that.

That meant that every time I wanted to write something new, I needed to write it in HTML. It's not entirely bad, and allowed me to do some fancy stuff, but it was impractical, to say the least. Because of that, I never posted anything anymore, and didn't want to migrate to something else, since that meant migrating lots of posts from HTML to something like Markdown.

How it changed

It all changed when I discovered Obsidian. If you want to know more about my feelings about it, take a look at the A week with Obsidian post. But what really enticed me to make a blog based on it were two details: it's really easy to write notes on it (like most Markdown-based editors), and that the notes link to each other easily. That blew my mind a little bit, since it meant I could write things fast and give more context through links.

How it is

Now, while I still use SvelteKit for the ease of use and the performance, I decided to go with a mix between two SvelteKit templates: SwyxKit and Svelteland's Markdown Blog Demo. SwyxKit gave me the basic infrastructure and sane visual defaults, while the Markdown Blog Demo gave me the piping necessary to write in Markdown and output HTML.

So I write everything in Obsidian, which makes notes in Markdown, and my SwyxKit Markdown Frankenstein's monster publishes it as HTML. The problem then was moving what was inside of the Obsidian vault to the folder my site expected the posts to be.

To solve that, I used this byotiful python library called obsidianhtml. It's mostly used to generate static sites from an Obsidian vault, but it's flexible enough to do strictly what I want it to: to capture internal links between the notes and substitute them with real links, and output the Markdown files to the blog posts folder of my site. I've made a custom shellscript function to do that for me.

The end result

Now, I can simply open Obsidian, write what I want to write (links, images and all), run a command to export the Markdown files to the site's source code, check that it's working on the site locally, and push the code. Oh, and I've been using Vercel as the hosting/publishing solution (and it's been awesome so far), since it takes care of building the app and publishing the new version.

Be free to take a look at the site's source code and give me feedbacks and suggestions on Twitter! Thanks for your attention, and see you next time :]

Since some of these are community plugins, to use them, you need to know how to turn on community plugins.

Periodic notes + Calendar

Ok, these are two different plugins, but they help each other a lot. The Periodic Notes plugin helps us organize... well, periodic notes. For example, I use it to create (almost) daily notes about what I've done, how I'm feeling, things people did that are worthy of note, etc. It keeps the notes organized.

With Calendar, though, it shines ✨ Calendar gives me a visualization on which days I've made notes, how much did I write on that day, and, if you click any day, it creates the note for that day using Periodic Notes' configs, so they're put at the right folder, with the right name.

For example, I wrote too much on the 21st, since it has two dots below the day number. I love it.

Templater

Not to be mixed up with Templates, which is a core plugin.

Templater gives people with a little bit of development experience (or a lot of patience) some superpowers for creating new notes. For example, I have a blog post template that puts all needed metadata in a Frontmatter block:

With this template, all dates are correctly set, and, as long as create the note with a title hyphenated-like-this, the post title will be Capitalized like this. Saves a lot of time for recurrent notes at work too.

Kanban

Because I'm an Agile software development lapdog.

Kanban gives you a kanban board inside of a Markdown file. Really useful for tracking down to-dos, be them work or life related.

While it shows you and interacts like a Kanban board (you can drag things around, archive cards, etc.), it's still a Markdown file under the hood, so yeah 👍

Various Complements

This plugin gives you a better autocomplete, almost IDE-like. Not much to say here, it's just better.

Slides + Fullscreen mode plugin

Obsidian comes with a pretty handy feature: you can make a presentation with multiple slides just by writing sections in a Markdown file separated by a --- line. With the note done, you just need to press Ctrl+P, search for Start presentation and you'll have it on your screen. Sometimes it's a little buggy when the presentation starts, so I just go to the second slide and back, and it fixed itself.

It only has one small issue: it's not fullscreen. You can't see it in the gif above, but my OS's top bar is still appearing for people that see me sharing my screen, for example. That's where the Fullscreen mode plugin comes in. I just need to enable focus mode (Ctrl+P is your friend here as well), and then start the presentation. Done.

Emoji shortcodes

👍💖

That's it for now!

Those are the plugins that I've been enjoying as of late. If you have any other that you like, or want more information on any of them, ping me on Twitter! Thanks, and see you next time! ✨

It's really simple, you just need to add a couple of rules into your CSS and you'll be good to go:

.hide-scrollbar {
  -ms-overflow-style: none;  /* IE and Edge */  
  scrollbar-width: none;  /* Firefox */
}

/* Chrome, Safari and old Opera */
.hide-scrollbar::-webkit-scrollbar { display: none; }

This is really useful for when you have an off-canvas panel (or anything absolute/fixed positioned), and you want it to scroll by itself if it has too much content.

Reference: https://www.w3schools.com/howto/howto_css_hide_scrollbars.asp

What is Obsidian?

Obsidian is mostly a text editor, and it was made for you to organize your thoughts, research topics, writings, anything. The general idea is that you write simple Markdown files, which is plenty for most writing scenarios, and link them together, effectively making a knowledge base.

That way, you can slowly build a graph of what you know about a topic. The simple linking of your documents is enough to make a rough map of what's on your brain.

Why would I need that?

Well, I can't say about your habits, but I'm using it for three main areas:

• researching and publishing about topics I like (this blog is built based on my Obsidian notes!);
• work related issues, like keeping notes about meetings, making new workshops or talks, keeping track on how people I mentor are evolving, what has been most effective, etc.;
• life things, like mood tracking, to-dos, and a general daily notes on what I've done and how I was feeling that day.

Researching

Obsidian is almost perfect for research notes, be them academic or not. The two important features here are forward-referencing notes, and the graph view.

To make a link between notes, you just need to wrap them with [double brackets](/notes/double brackets). If the note exists, you're done, the link is made; but if the note does not exist, it creates the link anyway, and when you click it, it opens up a new note with the link's title. It seems so simple, and it is.

This allows us to preemptively select certain words that may be popping out too much, or may be important for the subject. It also makes us remember that maybe a specific idea or topic needs more work.

When you're done with your notes, or if you want to have a better idea on what the main topics are, you can open the graph view.

It not only helps a lot on visualizing how things relate to each other, but it gives us a better sense on how much we've accomplished with our learnings - and I love this feeling of accomplishment. It gives me more confidence that I really worked hard on something, and that, if I need my notes on that, they're there.

Oh, and I think I don't need to tell you about the benefits of writing things down, right?

Work related notes

I need to be frank: my memory sucks. It's so bad. To mitigate that...characteristic, a couple of years ago I started taking small notes, even if not entirely accurate, about what happened at meetings, or about project roadmaps, anything I thought that was useful or that I was sure I'd forget.

It already helped me a lot, but sometimes it was a bit hard extracting useful, long time data from the notes I had. If I wanted, for example, to know what were the areas that people I've mentored had the most trouble with, I'd have to go through all the notes, for all people, and reread everything, making even more notes. And I'm too lazy for that.

Forward-referencing links help me a lot here as well. I can see pretty quickly how many people had the same problem, or how much they talked about it, just by looking at the graph. This kind of information is priceless for people that teach, write, or make content.

life... things

This may be the area Obsidian had the most impact with, and the advantages will probably keep getting bigger with time. Before Obsidian, I never kept notes about myself, never had a tool to track my mood, or what brought me down or made me happy.

Now, it's pretty easy for me to, you know, sit down and write about shit. Just write about shit. The good and the bad. And just by referencing things, you start to notice patterns emerging, be it bad/good habits, situations, or people that help me feel better or make me feel bad.

I started to understand a bit better what are the things I love, how to to them, why I do them. And while the other two areas were about productivity, this one is not. This one is about mental health, about keeping in touch with yourself and others, and maybe a little bit about recording history too; so that when I'm 40, even if Obsidian is not a thing anymore, or my life has completely changed, I still have notes.

Notes about what I learned. Notes about what work was all about. Notes about love.

apesar de ambas as linguagens serem razoavelmente parecidas, achei interessante a ideia, então aqui vão algumas diferenças pra se ter em mente na hora de virar a chave. algumas são de Mario Pabon, o autor do post original, e algumas coisas são minhas mesmo. :)

ah, só um detalhe: aqui vamos supor que você está usando python 3, sim? bem, vamos lá!

Resumo

• sintaxe
  • declaração de variáveis
  • blocos
  • controle de fluxo
  • if...else
  • while
  • for
• tipos
  • números
  • listas
  • strings
  • dicionários
  • None
  • funções
• módulos
  • definindo um módulo
• programação orientada a objetos
  • herança

sintaxe

declaração de variáveis

para ambas as linguagens, declarar variáveis é simples.

javascript

 var x = 3;

python

x = 3

mais tarde vamos falar de tipos, que fazem toda a diferença entre as linguagens. só vamos deixar clara, por enquanto, uma grande diferença: variáveis em python sempre pertencem ao contexto do seu bloco.

blocos

python tende a sempre ser mais estrito do que javascript. em python, não seguir a indentação do código pode fazer com que ele nem rode. isso se dá porque o python usa a indentação para definir blocos, no lugar das chaves do javascript.

blocos em javascript

 function exampleFunction () {
   // isso é um bloco, com um contexto pras variáveis
   var a = 5;
 }

blocos em python

 def example_function():
     # isso também é, também com seu próprio escopo
     # que é definido pelo que tá no mesmo nível de indentação
     x = 5
     print(x)

se a linha do print(x) tivesse mais um ou menos um espaço antes da chamada da função, o interpretador do python levantaria uma exceção IndentationError, porque a diferença de espaços criaria um bloco inválido.

outro possível problema causado pelo mau uso de indentação em python é o de escopo.

 x = "fora"
 # no escopo de fora, x = "fora"
 def example_function():
     x = "dentro"
     # no de dentro, x = "dentro"
     print(x)
     # retornaria "dentro"
 print(x)
 # retornaria "fora"

controle de fluxo

if...else, while e for em python são razoavelmente parecidos com javascript.

if...else

javascript

 if (x > 1) {
     console.log('oi');
 } else if (!x > 1) {
     console.log('io');
 } else {
     console.log('ioi');
 }

python

 if x > 1:
     print('oi')
 elif not x > 1:
     # 'elif' em vez de 'else if', 'not' em vez de '!'
     print('io')
 else:
     print('ioi')

while

javascript

 while (x < 3){
   x++;
 }

python

 while x < 3:
     x += 1

for

em python, ao iterar sobre uma lista, não precisamos declarar o índice ou resgatar o objeto internamente - o objeto da vez já está implícito.

javascript

 var lista = [1, 2, 3];
 for (var i=0; i < lista.length; i++){
   var item = lista[i];
   console.log(item); // 1; 2; 3
 }

python

 lista = [1, 2, 3]
 for item in lista: # o item da vez ficará na variável 'item'
     print(item) # 1; 2; 3

o javascript até aceita a sintaxe de for (item in lista), mas se comporta de maneira diferente, colocando na variável item o valor do contador do loop.

tipos

os tipos em python são razoavelmente parecidos ao de javascript, já que você não precisa declarar os tipos para cada variável na hora da declaração (como se faz com java ou C#, por exemplo).

a grande diferença é como os tipos interagem, já que várias operações permitidas em javascript não são em python. python prefere levantar um erro em vez de fazer uma operação entre tipos que pode gerar um dado errado.

um dos exemplos mais clássicos é o da soma de números com strings:

javascript

 var a = 5; // número inteiro;
 var b = "5"; // uma string que contém o número 5
 a + b // retornará a string "55"

python

 a = 5 # número inteiro
 b = "5" # uma string que contém o número 5
 a + b # 'TypeError', já que não se pode somar tipos diferentes
 # em python, devemos transformar o número em string
 # ou a string em número
 str(a) + b # string "55"
 a + int(b) # inteiro 10

já que tiramos essa dúvida da reta, vou dar um apanhado básico dos tipos em python.

números

ao contrário de javascript, python tem vários tipos diferentes para diferentes números.

• inteiros (integer): 1, 2, 3
• ponto flutuante (float): 4.20, 4e420
• números complexos: 4 + 20j
• booleanos (boolean): True, False

você pode fazer as mesmas operações em ambas as linguagens, como, por exemplo, soma, subtração, divisão, multiplicação e potenciação.

listas

listas em python são bem parecidas com as de javascript, com alguns adereços a mais. elas podem conter uma mistura de tipos:

 [4, "2", [0, "zero"]]

há também uma sintaxe especial para pegar partes de uma lista:

 lista = [1, 2, 3, 4, 5]
 lista[0:2] # 1, 2, 3
 lista[3:] # 4, 5
 lista[2, -2] # 3, 4
 # se aceitam índices negativos, pegando do final da lista

e algumas funções e métodos úteis:

 len([1, 2, 3]) # 3
 [1, 2, 3].reverse() # [3, 2, 1]
 [1, 2].append(3) # [1, 2, 3], igual ao 'push' do js

para concatenar listas, é só somá-las:

 # [1, 2, 3, 4]
 [1, 2] + [3, 4]

pra fechar, temos em python o que chamam de list comprehension. é uma forma de criar listas dinamicamente.

 lista = [1, 2, 3, 4]
 maiores_que_2 = [numero for numero in lista if numero > 2]
 # maiores_que_2 é agora [3, 4]

strings

strings em python são praticamente iguais às de javascript. você pode acessar cada caractere individualmente, mas só pode alterar o conteúdo ao reassinalar a variável.

 nome = 'Luciano'
 print(nome[0]) # L
 nome[0] = 'D' # TypeError

dicionários

dicionários são listas associativas em python, muito parecidos com objetos em javascript. eles são declarados praticamente da mesma forma.

 pessoa = {
     'nome': 'Luciano',
     'idade': 27
 }
 print(pessoa['nome']) # Luciano
 print(pessoa['gênero']) # KeyError, gênero não foi declarado

já que em python nós preferimos levantar erros em vez de falhar silenciosamente, temos um método padrão dos dicionários para resgatar valores default no caso de eles não terem sido declarados:

 pessoa.get('gênero', 'não-binário')
 # não achamos a chave "gênero", retornamos 'não-binário'

None

None é equivalente a null em javascript. isso significa que None representa a ausência de um valor e é avaliado como false.

detalhe: não há par para undefined em python, já que tentar acessar algo não definido em python levanta uma exceção NameError.

funções

assim como em javascript, funções também são objetos em python. isso significa que você pode passar funções como argumentos/callbacks ou até assinalar propriedades pra funções.

 def func_tainha(a, other_func):
     print(a)
     other_func()
 
 def another_func():
     print('marilene')
 
 func_tainha('olá', another_func)
 # olá
 # marilene
 
 func_tainha.vinho = 'sinuelo'
 print(func_tainha.vinho)
 # sinuelo

módulos

não quero falar sobre ES6 aqui, mas os módulos (pacotes) em python são bem parecidos (em sintaxe) com os módulos em javascript ES6.

definindo um módulo

ao contrário de ES6, em que você tem que declarar o que você tá exportando pro seu módulo, em python você sõ precisa criar um arquivo .py e suas punções/classes/oquefor estão prontas pra serem importadas. basta que, na mesma pasta do seu módulo, você coloque um arquivo __init__.py pra que o interpretador python reconheça o módulo

 # qualquercoisa/qualquercoisa.py
 def dizer_quelquercoisa():
   print('qualquercoisa')

 # qualquercoisa/__init__.py
 # pode ser vazio mesmo

# qualquercoisa/lala.py
import qualquercoisa
# importando o módulo inteiro
qualquercoisa.dizer_quelquercoisa()
# qualquercoisa

from qualquercoisa import dizer_quelquercoisa
# importando apenas a função 'dizer_quelquercoisa'
dizer_quelquercoisa()
# 'qualquercoisa'

ah, e pra instalar pacotes disponibilizados pela comunidade, tipo npm, você usa o pip.

pip install django

programação orientada a objetos

em python, assim como ES6, há suporte a classes e herança entre objetos. isso é diferente da herança baseada em prototypes clássica do javascript.

  # você pode definir uma classe que representa qualquer animal
 class Animal:
     # qualquer variável definida aqui será uma propriedade da classe
     idade_inicial = 1
 
     def __init__(self, nome, especie='humano'):
         # aqui, declaramos que, ao criar um animal, podemos passar um nome e espécie pra ele
         # se não passarmos uma espécie, por padrão, ela será 'humano'
         # 'self' se comporta parecido com o 'this', mas sem toda a confusão de escopo
         self.nome = nome
         self.especie = especie
         self.idade = self.idade_inicial
 
     def comemorar_aniversario(self):
         # ao comemorar aniversário, acrescentamos 1 à idade
         self.idade += 1
 
     def falar(self):
         # se for um humano, ele fala besteira
         if self.especie == 'humano':
             return 'blablablawhiskassachê'

desse jeito, se inicializarmos um humano chamado Jorge e comemorarmos seu aniversário, teremos o seguinte:

 jorge = Animal('Jorge')
 jorge.idade
 # 1
 
 jorge.comemorar_aniversario()
 jorge.idade
 # 2
 
 jorge.falar()
 # blablablawhiskassachê 

herança

tendo como base nossa classe de animal, podemos, por exemplo, termos uma subclasse de animal chamada Girafa:

 class Girafa(Animal):
     """
     ao passar Animal entre parênteses, herdamos tudo de Animal
     aqui, declaramos que girafas são da espécie 'girafa'
     e que não precisam de nome.
     pra isso, sobrescrevemos o __init__, que inicializa uma girafa.
     """
     def __init__(self):
         self.idade = self.idade_inicial
         self.especie = 'girafa'

assim, se inicializarmos uma girafa...

girafa_nova = Girafa()
# não precisamos mais passar nome
girafa.idade
# 1
    
girafa.comemorar_aniversario()
girafa.idade
# 2
    
girafa.falar()
#
# isso mesmo, girafa não fala,
# então se mandarmos ela falar, não sai nada :)

é claro que tem MUITO mais sobre python do que só isso, então se tiverem qualquer dúvida ou acharem que algo poderia ser explicado melhor, só falar nos comentários.

e lembrem que a melhor forma de aprender uma linguagem é meter a mão na massa e fazer um projetinho! se não souberem por onde começar, eu recomendo fortemente o tutorial das pyladies do Django Girls, mas se não quiser aprender com desenvolvimento web, tem sempre o python para zumbis do querido e fofíssimo Masanori.

abraços, e até a próxima!

chegamos à parte 3 dos posts sobre git e github! nos outros dois, falei sobre o que são o git e o github e slguns conceitos básicos pra começar a usar o git. hoje, vou falar mais sobre algumas boas práticas pra organização de branches, baseado nas sugestões do git flow.

o que é o git flow?

o git flow é uma extensão do git que permite uma maior organização e agilidade na hora de lidar com o git. ele segue uma série de convenções que caracterizam alguns tipos de branches com responsabilidades diferentes, próprias pra cada etapa do processo de desenvolvimento. vou detalhar melhor o papel de cada um dos tipos de branch.

lembre-se:

essas são apenas sugestões minhas e das próprias convenções do git flow.

o uso dessas sugestões muda de projeto a projeto, apesar dessas sugestões funcionarem em grande parte dos casos.

branch master/main

o branch master (ou, preferivelmente, main) é o branch no qual está o código que está em produção, ou seja, que está sendo diretamente usado pelos clientes. ele é caracterizado por sua grande quantidade de tags, que refletem cada versão do projeto que foi pra uso corrente. nele, não se deve ter commits soltos; devemos apenas adicionar commits nele através de merges de branches de release e de hotfix.

branch develop

o branch develop é o que contém o código previsto para a próxima release, ou seja, o próximo código que irá pro ar. nele, também não devemos commitar diretamente, deixando que seu código seja fornecido pelos branches de feature e hotfix, mas essa regra é um pouco mais flexível que a do master. uma boa prática é sempre deixá-lo estável, pronto para ir para o ar a qualquer momento, para evitar que uma funcionalidade não vá pro ar por causa de instabilidade de outras.

branches de release

os branches de release são aqueles que resumem o que uma nova versão do seu projeto terá. ele tem a responsabilidade de sair do develop, se mergear no master e no develop e, ao mergear no master, criar uma tag com o número da nova versão. geralmente, recebem o nome release/[numero-da-versao]. na minha experiência, acho uma má ideia commitar em branches de release, pelo simples motivo que, assim, temos certeza de que todo o código veio dos hotfixes e das features. dessa forma, os branches de release servem apenas como um ritual para que você tenha certeza do que está colocando no ar e qual é a versão desejada. é uma burocracia que já salvou minha vida algumas vezes. ;)

branches de hotfix

os branches de hotfix são os que são abertos na hora que algo em produção dá problema. são branches criados a partir do master e que se mergeiam novamente no master e no develop, já que precisamos das correções também no código que está sendo desenvolvido. geralmente, recebem o nome hotfix/[numero-da-versao]. eles também recebem suas próprias tags, que servem para dizer que, nesta versão, o problema x foi corrigido.

branches de feature

os branches de feature servem para, bem, features, né. eles partem do develop e mergeiam também no develop. geralmente, recebem o nome feature/[descricao-da-funcionalidade]. neles, commitamos o que é necessário para novas funcionalidades ficarem prontas, apesar de que eu, novamente, não recomendo que sejam feitos commits diretamente nele. o motivo disso é que, ao meu ver, features têm a tendência de terem muitos commits, o que deixaria difícil a revisão do código em um pull request. recomendo que, a partir dos branches de feature, sejam criados branches de topic, que terão o conteúdo de uma parte da funcionalidade, em um tamanho que permita a fácil revisão do código por outras pessoas.

branches de topic

os branches de topic são os coringas. geralmente, recebem o nome topic/[nome-do-topico-abordado]. são usados em qualquer lugar em que seja legal ter mais de um tópico, para facilitar a revisão de código. na real, uso os branches de topic saindo dos de feature e mergeando nos mesmos, ou partindo de um branch de hotfix e mergeando nos mesmos. são os menores branches, feitos para serem lidos e revisados rapidamente.

e o que o git flow tem a ver com isso tudo?

o git flow, como eu disse, é uma extensão do git. ele cria comandos que servem de atalhos para os processos descritos acima. ele tem comandos para abrir e fechar releases, features e hotfixes, e é facilmente configurável. se essa organização de branches te interessou, acho que vale a pena dar uma olhada no repositório deles e ler o post sobre o workflow deles. nesse post, eles detalham melhor o que é realmente necessário ser feito pra realizar essa proposta de organização.

como sempre, qualquer dúvida ou sugestão, é só falar nos comentários. espero que tenham gostado dessa série de posts e que tenha sido útil :D

eu fico por aqui, até a próxima! o/

eis que voltamos para a parte 2 dos posts sobre git e github! dessa vez, vou discutir alguns conceitos básicos necessários para quem quer trabalhar com git. se ainda não leu o primeiro post, façam o favor, porque não vou explicar de novo (#ranzinza). então vamos lá!

merge e conflitos

a última coisa que discutimos no último post foi a questão de termos branchs diferentes para commits e tarefas diferentes. ter múltiplos branchs é importante para que uma tarefa não influencie na outra, mas o que importa no final das contas é que todas as tarefas estejam prontas, juntas, entregues.

pra isso, os branchs paralelos precisam ser misturados novamente em um só, usando o processo que chamamos de merge. merge significa, ao pé da letra, convergir. essa convergência é necessária para que saibamos que tudo funciona em conjunto e para que possamos criar uma nova versão do projeto que está sendo desenvolvido.

isso se complica na hora que pensamos que, em branchs diferentes, os desenvolvedores podem mudar o mesmo arquivo, na mesma linha. quando isso acontece, ocorre o que chamamos de conflito. na hora do merge, o git tenta misturar o código (e geralmente é bem inteligente em se resolver sozinho), mas quando conflitos acontecem, é necessária intervenção manual no código para que tudo funcione bonitinho, então fiquem ligados pra que seu processo se adapte visando evitar conflitos.

cherry-pick

digamos que no branch 1 temos uma tarefa e no 2, outra. pode acontecer o caso de que o branch 2 desenvolva algo que seria importante para o desenvolvimento do 1, mas, obviamente, temos o código de um separado do outro. nessas horas, podemos usar o cherry-pick.

cherry-pick é o processo de pegar um commit específico, ou uma série de commits, e copiá-lo(s) para outro branch. pode ficar tranquilo, isso não vai interferir na hora do merge (mas pode dar a ilusão de que mais coisas foram mudadas na hora de gerar um pull request). use o cherry-pick com muita parcimônia.

rebase

muitas vezes acontece de você criar um branch a partir de outro, mas perceber que devia ter esperado mais, porque foi feita alguma nova alteração importante no branch base. nessas horas, você pode usar o rebase.

rebase é o ato de mudar o commit base de uma série de commits. ele é útil em alguns momentos, mas deve ser evitado, já que ele altera o histórico do git e pode gerar inconsistências de dados quando mais de uma pessoa está trabalhando no mesmo branch.

a maior utilidade que vejo no rebase é na hora em que você faz um commit local e, nesse meio tempo, alguém enviou um novo commit no repositório. nesse momento, para evitar um commit de merge na hora de sicronizar o código, você pode simplesmente usar o comando git pull --rebase pra pegar seu commit e colocar logo em seguida do que estava no repositório remoto.

remotes

uma das coisas mais interessantes do git é a possibilidade de configurar múltiplas origens pra um mesmo projeto. assim, podemos enviar código de um projeto para múltiplos repositórios, e isso é feito a partir da configurações de remotes.

geralmente, só temos uma origem remota pra cada projeto, mas podemos ter, por exemplo, um outro repositório remoto configurado para fazer o deploy da aplicação. esse processo é usado por alguns serviços de hospedagem de site, como o heroku.

tag

quando você tem vários commits com várias funcionalidades diferentes, você tende a não saber mais muito bem em qual commit que tal feature ficou pronta. para que você possa nomear o estado do projeto em um commit específico, você pode usar uma tag.

uma tag nada mais é do que um atalho a um commit específico, que descreve um estado do seu projeto. você pode, por exemplo, nomear de 1.0 a versão inicial de seu projeto e ir criando novas tags pra cada nova versão de produção.

por hoje, acho que é isso, pessoal. no próximo, e último post, vou discutir um pouco sobre boas práticas para desenvolvimento usando git. caso tenham alguma dúvida ou sugestão, só mandarem ver nos comentários, sim? abraços, e até a próxima! o/

hoje eu tava conversando com uns amigos sobre git e github e percebemos um problema: não temos atualmente um lugar com conteúdo sobre os dois em português, principalmente para leigos ou iniciantes. depois de pegar com o pessoal uns pontos importantes, decidi fazer alguns posts sobre o assunto, para servir de referência. aí vamos nós o/

o que é o git?

git é uma ferramenta para versionamento de arquivos.

um exemplo: digamos que você queira escrever um poema pro seu amorzinho e tenha várias ideias. você escreve um verso, escreve outro e pronto, taí seu poema, o amorzinho.txt. você manda o arquivo pro seu amorzinho, que fica apaixonado. depois de alguns dias, você tem uma ideia nova, volta no texto, reescreve um verso e manda pro seu amorzinho de novo, esperando coraçõezinhos de carinho. mas seu amorzinho diz "a versão antiga era tão mais bonita... tem como me mandar a antiga?". mas, oh!, você esqueceu como o texto era e não tem mais salvo em lugar nenhum! aí que entra o git.

o git serve para que você possa criar uma linha do tempo com diferentes pontos das alterações feitas. assim, você consegue manter o histórico das alterações de um mesmo arquivo ou arquivos ao longo do tempo.

nem preciso dizer o quanto isso é crucial para projetos de software, já que esses projetos exigem que você e sua equipe criem novas funcionalidades nos mesmos arquivos, com uma versão antiga salva pro caso da nova dar problema. vou explicar melhor como ele funciona daqui a pouco, mas, antes, tenho que explicar o que é o github.

o que é o github?

github é só um site no qual você pode fazer upload de projetos git.

o github (palavra que seria traduzida como "agregador de gits") é o site mais conhecido de hospedagem de projetos git. ele serve para que você e sua equipe possam manter as versões do projeto em que trabalham em um lugar centralizado, na internet, acessível a quem pertence ao projeto.

além de hospedar projetos git, o github dá visibilidade da linha do tempo de diferentes versões do projeto, provê ferramentas de métricas (como quais usuários alteraram mais o projeto, quando alteraram, o que alteraram, etc), gerência de problemas relatados (tickets ou issues), dentre outras. vou detalhar um pouco melhor daqui a pouco.

lembrem-se:

a diferença entre git e github é que o git é só uma ferramenta para versionar projetos, enquanto o github é o site no qual você colocará esses projetos versionados. uma analogia válida seria que o git é seu pincel e tintas enquanto o github é um museu.

beleza, mas como o git funciona?

vou tentar explicar conceitos básicos, mas não vou fazer um tutorial de como usar a ferramenta, porque tem vários por aí.

bem, digamos que você tenha uma pasta com seus textos, ok? seria muito legal saber, ao longo do tempo, como foi sua evolução como escritor, ou seja, quais textos foram adicionados, removidos ou alterados. você decide começar a usar o git na pasta de textos e quer salvar o estado atual da pasta.

pra isso, você cria um commit inicial.

um commit é um documento que descreve uma alteração, um ponto na linha do tempo do projeto. ele é como um registro de uma alteração no projeto. essa alteração é salva com seu nome, seu email, data da alteração, suas alterações na pasta e uma descrição da alteração, que você mesmo escreve.

então, na hora que você coloca os textos na pasta pela primeira vez, você cria um commit com a descrição "adiciona os textos que tenho agora", seleciona todos os arquivos e pronto, você tem um ponto na linha do tempo!

ok, mas agora quero usar o github pra salvar meus textos na nuvem? comofas

pra isso, você cria uma conta no github e cria o que chamamos de um repositório.

na linguagem do povo de computação, repositórios são locais nos quais colocamos arquivos na internet. eles servem para que qualquer um consiga repor o código de um projeto no seu computador, caso você não tenha ele salvo. isso significa que, quando você for colocar seu projeto no github, você primeiro precisa criar um repositório lá.

com o repositório criado no github, você só precisa configurar onde está seu repositório e empurrar as alterações pra lá. ou seja, você define a origem do repositório e faz um push dos commits pra lá.

legal, agora tenho os meus textos salvos no github. que que eu faço com isso?

agora, com os textos lá, você pode fazer várias coisas. vou enumerar algumas, as mais básicas e úteis. :)

clonagem de repositórios

digamos que você foi passar o fim de ano na casa dos seus pais e você quer alterar algum texto. você sabe que tem todos eles no seu computador, mas você (sua anta) esqueceu de trazê-lo. você até pode copiar os textos direto do site do github pro computador da sua mãe, mas isso significa que, se você quiser salvar a nova versão lá, você vai ter que criar outro repositório. relaxa, pra isso serve a clonagem de repositórios.

clonar um repositório significa baixar o projeto git inteiro, direto da origem, pro seu computador. isso quer dizer que todas as alterações, de toda a linha do tempo, estão agora no seu computador. assim, ao você clonar um repositório, você pode simplesmente criar novos commits e dar push das novas alterações.

isso permite que uma equipe possa fazer alterações no projeto, cada um em seu computador, e possa sincronizar essas alterações através de pushs (empurrões) e pulls (puxadas) de commits (alterações) de um mesmo repositório (projeto). é assim que uma equipe de software trabalha hoje em dia. :)

forks de repositórios

ok, digamos que seu amigo tem um amorzinho também e quer escrever aquele poema lindo, mas não tem muita criatividade. você diz pra ele "cara, pode usar o amorzinho.txt, mas tem que dar uma alterada, senão vai pegar mal". você não quer, no entanto, que seu amiguinho use seu repositório, porque, né, é seu, com seus textos. o que seu amigo pode fazer pra ter a versão dele dos seus textos é criar o que chamamos de fork.

um fork é um repositório criado a partir de outro. tudo nele é literalmente igual, desde o conteúdo dos arquivos até os commits salvos; a única diferença é que pertence a um usuário diferente.

no entanto, a utilidade de um fork só se revela totalmente quando começamos a falar sobre issues e pull requests.

issues e pull requests

seu amigo, ao ler o seu poema amorzinho.txt, percebe que você escreveu errado o nome do seu amorzinho. ele quer te avisar que isso precisa ser corrigido, porque isso é um problema, uma issue.

uma issue é um relatório de um problema que precisa ser corrigido. imaginemos que seu site, por exemplo, tem um link quebrado. qualquer um pode abrir uma issue no seu repositório no github dizendo que o link da página tal está quebrado.

o problema é que você, mantenedor do projeto, tá extremamente ocupado dando aulas pro seu amigo de como escrever um poema romântico. você vai lá e responde pro cara, na própria issue, que você tá enrolado demais, mas que ficaria muito agradecido caso o cara pudesse corrigir esse problema pra você.

o cara é esperto: ele cria um fork do repositório, localiza o arquivo problemático, corrige o link, salva, cria um commit, faz um push das alterações pro fork dele, tudo certo. só um detalhe: a correção precisa ser misturada com o seu repositório**. pra isso, ele cria um** pull request**, ou seja, um** pedido de empurrão de alterações**.

nesse pull request, constam os commits feitos, os arquivos alterados e uma descrição da correção. mas digamos que o cara esqueceu de alterar em outro lugar; você comenta no pull request dizendo que precisa alterar no outro lugar.

esse detalhe deixa claro que pull requests também são issues. ambos são discussões sobre um problema. mas, claro, issues não são necessariamente pull requests, porque pull requests têm como objetivo a correção de uma ou mais issues.

ufa. tá tenso. mas ok, vamo lá, mais alguma coisa?

só mais uma, juro, tá acabando! digamos que você e seu amigo querem fazer diferentes versões de um mesmo poema num mesmo repositório. se você alterar e fizer um commit, seu amigo vai acabar fazendo outro commit por cima do seu, e isso não é legal. o que você pode fazer é criar uma bifurcação no repositório e dizer pro seu amigo que o seu branch é o seu e o dele é o dele. assim, enquanto você faz commits em uma bifurcação, seu amigo faz em outra, sem que uma interfira na outra. isso significa que, agora, seu projeto tem dois branchs (tecnicamente, três, porque tem o branch base, né).

branchs são bifurcações ou ramificações dentro de um projeto git. eles servem para que tenhamos diferentes versões baseadas em um mesmo ponto do tempo. são usados para que a equipe se organize, para que um desenvolvedor faça a correção do link em um branch, enquanto outro desenvolvedor continua commitando em outro branch, sem interferirem um no processo do outro.

tl;dr (resumo)

bem, falei até demais, mas acho que valeu a pena. vamos resumir alguns termos então.

git

git é um programa, uma ferramenta para versionamento de arquivos. serve para que você tenha uma linha do tempo de alterações de uma pasta, de um projeto.

commit

um commit é um ponto da linha do tempo de um projeto git. ele descreve as alterações feitas num ponto do tempo, criando um snapshot do projeto.

repositório

um repositório é um local na internet onde podemos colocar nosso projeto git.

github

o github é o site mais famoso de hospedagem de repositórios.

clonagem

a clonagem de repositórios é a ação que cria no seu computador local uma cópia de um projeto git ligada diretamente a um repositório. permite que você possa rapidamente criar um novo commit e empurrar as alterações diretamente para seu repositório.

push e pull

push e pull são as ações mais feitas para se sincronizar o estado de um projeto git. com o push você empurra os commits feitos localmente e com o pull você pega as alterações que estão no repositório.

forks

forks são repositórios criados a partir de outro. servem para que um usuário possa ter sua própria cópia de um repositório, para que faça suas próprias alterações.

issues

issues são tickets, relatos de problemas de um projeto. permitem discutir um bug, propor uma nova funcionalidade, etc.

pull requests

pull requests são issues* que contém commitsque solucionam issuesou adicionam funcionalidades**. também servem para discutir problemas, soluções e também para revisar alterações feitas.

branchs

branchs são bifurcações em um projeto git. servem para que pessoas possam trabalhar em paralelo em um mesmo projeto sem medo de sobrescrever ou alterar algo que outra pessoa está fazendo.

acho que é isso então

é, falei aqui sobre alguns aspectos básicos do git, mas muita, muita coisa ficou de fora. pra quem é leigo, acho que tá tranquilo parar por aqui, mas pros programadores iniciantes, pessoas que querem se envolver na área ou curiosos, tô preparando uma parte 2, com conceitos um pouco mais avançados.

enquanto isso, discutam nos comentários sobre o que ficou confuso ou o que pode melhorar! é isso aí, pessoal. até mais o/