DEV Community: Henrique Marques Fernandes

1. How I Stopped Building Random Features and Found a Product Direction

Henrique Marques Fernandes — Wed, 22 Jul 2026 00:25:49 +0000

This is part two of my Growing HAID in Public series. In part one, I wrote about building a fitness app, failing at distribution, and realizing that my product still lacked a clear reason to exist. This is what happened next: turning a pile of ideas into an actual roadmap.

The problem after the problem

I had finally figured out what HAID should be.

Not just another fitness data aggregator, but a system that uses the context of your life to help you understand how you are actually doing.

Great. Clear direction. Finally.

Now what?

I had a Notion workspace that would make Sheldon from The Big Bang Theory proud. Tasks everywhere, feature ideas piling up, integrations I wanted to build, and interface redesigns I had been sketching.

Everything was organized in the sense that it was written down. It was not organized in the sense that mattered: I had no idea what to build first.

I have owned features and contributed to roadmaps at every company I have worked for. I have sat in prioritization meetings, talked to product managers, and debated scope.

But I had never been the person responsible for building everything from scratch. The person who decides not only what goes in, but also what stays out and in what order.

That was a different kind of problem.

What I thought product thinking was

As an engineer, I used to think product thinking looked something like this:

List the features.
Estimate the effort.
Sort everything by impact and effort.
Start with high-impact, low-effort work.

That is not exactly wrong. But it is incomplete.

It is the spreadsheet version of product thinking. It skips the harder questions.

What is the first version of this product that can make someone care? Not the version with every feature, but the one that delivers the core promise well enough for a stranger to keep using it.

That question changed the way I looked at everything.

And, honestly, an MVP is rarely truly minimal anymore, especially when you enter a category full of large, established companies. Users will compare your product with the incumbents immediately. There is no way around it.

You need enough familiar functionality to feel like a serious alternative from day one. At the same time, you need to give people a clear reason to switch from what they already use.

That was the real shock for me: HAID could not feel like one more app layered on top of Garmin, Strava, Apple Health, and everything else. It needed to start replacing at least one of them while pointing toward a larger vision.

Defining what HAID actually is on paper

I forced myself to write.

No code, Figma, or tasks. Just words.

What problem does HAID solve? Who is it for? Why do existing apps fail to solve that problem? What would make someone leave their current setup?

The document I used to turn the idea behind HAID into a product direction.

Putting everything on paper gave me more clarity than I expected. Ideas that seemed obvious in my head became questionable once I wrote them down. Things I had been avoiding became clearly important.

And some features I was excited to build revealed themselves for what they were: nice ideas that had no place in the first version.

Choosing what goes into the MVP

This is where it became difficult. My definition of an MVP had to change.

At first, “MVP” meant the smallest thing I could release. Basic data ingestion, a simple dashboard, and perhaps one social feature.

The classic developer instinct: ship something quickly and iterate.

But after the Reddit experience, someone asked, “Why would I download this?” and I did not have a good answer. I realized that an MVP that was too minimal would simply repeat the same problem.

If the first version does not deliver the core promise, it does not matter how quickly you release it. You will receive the same feedback again.

My new definition became: the minimum version capable of answering “How am I doing?” with enough depth to deliver real value.

That completely changed the order of the roadmap.

Life context moved to the top

The context feature was already in the backlog. The problem was that it was buried in the fourth quarter, behind several things I wanted to build because they looked more exciting and easier.

It needed to become the priority.

Travel, stress, injuries, and recovery could not be a distant add-on. They were precisely what separated HAID from another dashboard full of training charts.

The experience needed to adapt to the person

I hate opening an app and seeing empty spaces every day for data I will never produce.

That meant defining personas and designing an adaptable experience. A casual user and a professional athlete should not see exactly the same thing or feel judged or overwhelmed by the app.

Their experiences can be different, but they need to share the same core principle: use data and context to help each person understand how they are doing.

Some ideas had to go

I also cut things I wanted to build simply because they would be fun.

Achievements and route segments, for example. They are enjoyable features, but do they create a meaningful difference? Would an AI bot actually help, or would it make people reject the product before trying it?

“Not now” is a frustrating answer when you know you can build something. But it became a necessary part of the process.

How I organized the work

I am not going to pretend I discovered a brilliant framework. I did not.

This is what I actually did.

Everything lives in Notion

I have a product backlog, a screen inventory, and PRDs for the main features. Every screen in the app has a corresponding Notion page with requirements, edge cases, and design decisions.

It is probably too much engineering for a one-person project. But it keeps my head in order.

Prioritization is simple

For every feature or task, I ask: does this move me closer to a version of HAID that answers “How am I doing?” in a way someone genuinely values?

If the answer is yes, it enters the roadmap. If it is interesting but tangential, it goes onto the “later” list.

Time is also part of the product

This was the hardest shift.

I am a solo developer with a full-time job. HAID is a side project. I cannot simply enter an endless sprint.

I had to accept that things take time and that I cannot rush the product just because I am excited. Setting realistic timelines, and not tearing myself apart when I miss them, was a skill I had to develop.

Life context was one of those cases.

The idea sounded simple, but it hid several decisions. How do you record a trip without turning it into an annoying form? How do you represent periods of travel, stress, injury, or recovery in a structured way? And how do you carry that context through the rest of the app instead of trapping it on one screen?

I estimated two weeks.

I was very wrong.

The first version felt clumsy. Once I started testing it, both the input flow and the way context appeared throughout the app felt wrong. The result was not what I had imagined.

So I tore it down and started again.

It took five weeks to reach something that made me think: yes, this works.

I had also overcomplicated the first interaction. My original idea was a chatbot-style field where someone could send a message and the app would infer the context from natural language.

I still like the idea. I still want to build it. Just not now.

To validate the flow, a simple form, a few emojis, and a date picker were more than enough. KISS.

What “minimum” actually means

The definition that stayed

Minimum does not mean small. It means focused.

My MVP is not a weekend project. It represents months of work. But every part serves the same goal: provide enough context around fitness data to make someone return the next day.

That is the bar.

Not “How many features does it have?” but “Does this make someone open the app again?”

In the first draft of this article, I estimated that I was about a month away from that version. After missing a two-week estimate by a considerable margin, I would rather not turn another estimate into a promise.

Once it is ready, the focus shifts to bugs, experience refinements, and then the big unknown: getting people to try it.

What I learned about product as a developer

If I had to summarize what I have learned so far, it would be this.

Functionality is not value

I could build every feature perfectly and still end up with a product nobody wants.

The “what” matters less than “Why should I care?”

Writing forces clarity

Whenever I felt confused about the direction, putting things into words instead of code helped me see what I was actually trying to do.

PRDs are not bureaucracy when you are building alone. They are thinking tools.

Cutting is harder than building

Saying “not yet” to a feature that excites me is genuinely painful. But a focused product beats a product stuffed with features, especially when you do not have enough users to tell you what truly matters.

Product thinking is a skill

I was not born knowing how to prioritize or define scope. I am learning it the same way I learned engineering: by doing, making mistakes, and adjusting.

It is uncomfortable, but it can be learned.

Being able to build quickly can even become a trap. When you are an engineer who enjoys building, it is very easy to confuse “This would be fun to build” with “This would make a difference.”

For me, a large part of product thinking has been learning to distrust that instinct a little and ask a harder question: does this solve a real problem, or does it merely satisfy my own taste?

What comes next

First, finish the MVP. Then comes the part I am least prepared for: growth.

The goal I set was to reach 500 users, but the number alone does not answer the harder question: how do the right people discover the product and find enough value to keep using it?

The next article will be about that attempt: how a developer with no marketing experience tries to earn attention in a market flooded with apps that promise to solve everything with AI.

If you want to follow what I am building: haid.app.

AI Will Take My Job, but First I Need to Review Its PR

Henrique Marques Fernandes — Wed, 22 Jul 2026 00:25:14 +0000

At the beginning of the year, I was certain artificial intelligence was going to end the world.

Not in the metaphorical “this tool will change the market” sense. In my head, the whole script was already written: AI would take every job, money would become meaningless, humans would become obsolete, and we engineers would be the first to go. The ironic twist would be getting replaced by the very systems we helped build and maintain.

I am not usually drawn to paranoia or conspiracy theories. The problem is that I have a vivid imagination, and every now and then it decides to drive without a license.

When I wrote about why I am growing HAID in public, I mentioned that AI scared the hell out of me and that I feared what it would do to my job. This is the post I promised back then.

Or at least my view today. A new model could launch tomorrow and I might come back here pretending I never said any of this.

The panic faded. The amount of stuff to learn did not

After a while, the dust settled. At least a little.

Developers already work in one of the most dynamic markets around. Every week brings a framework, language, library, or tool that, according to someone on X, makes everything you learned before yesterday completely useless.

We are used to studying. It is part of the job.

AI did not simplify that treadmill, though. It placed another treadmill on top of it. Now we need to understand how to work with agents, provide context, organize tasks, compare models, learn what each one is good at, and decide which one to use. By the time you finish comparing them, another has probably launched.

It was supposed to make things easier. Somehow, it made them easier and harder at the same time.

My first strategy was to assume I was special

I kept using AI heavily and started noticing that some engineers around me had barely tried these tools.

My reaction was deeply human and not especially noble: “Okay, maybe I still have a job.”

I consider myself a good engineer. I study, I try to keep up, and I was already using AI extensively. For a while, I imagined that advantage would protect me. If someone had to be cut, it would be the others, not me.

It is a comforting line of thought. It also has an expiration date.

Knowing how to use the tool may create an advantage today, but the tool keeps getting easier to use. The differentiator cannot simply be talking to it better than the person at the next desk.

Product and engineering are starting to become the same job

Then I began noticing another shift: the boundary between product and engineering was getting less clear.

That part excited me. I love product. I have built plenty of side projects, attempted startups, and more recently had to stop piling random features into HAID and find an actual direction.

If writing code has become cheaper and faster, choosing what to build matters even more. Understanding the problem, talking to people, setting priorities, seeing tradeoffs, and making architecture decisions increasingly belong in the same package.

Maybe the engineer will not disappear tomorrow. Maybe the role will become an even stranger mix of engineer, product manager, architect, researcher, and robot babysitter.

I can picture myself in that role. The uncomfortable question is: how long will it remain a human role?

What if programming languages are just a phase?

I have a slightly wild idea, and it is not exactly a future I am rooting for: if we keep programming with AI, high-level languages may stop being necessary for a large part of the work.

I am not saying that understanding code has become less important. I think the opposite is true. Reading code, spotting bad abstractions, anticipating problems, and validating behavior matter more than ever. What may matter less is manually writing every line.

Today, we use languages designed so humans can express instructions and machines can execute them. But vibe coders and even experienced developers are already submitting PRs without looking at their own code. If that behavior continues, it feels inevitable that someone will ask: why keep a representation designed for humans who are no longer reading it?

I do not want that to happen. I want us to keep understanding what we put into production. I can simply imagine a future where machines create most code and, as a consequence, representations optimized for them emerge while we move further away from the implementation.

That future still feels far away. To trust that level of abstraction, we need much better tools, environments, tests, observability, and verification mechanisms.

Until then, please review your PR. Run the project locally. Check that the application at least starts before asking someone else to review it. And if you do not understand the code you are submitting, ask for help.

We are all learning, but production does not need to learn alongside us.

The work may move from the keyboard to the control room. The responsibility stays on our side.

The numbers still need to add up

There is another huge uncertainty in this story: how much all of this really costs and who ultimately pays the bill.

We still do not know whether there is a bubble, when it might burst, or how the price of these tools will reach end users. If capital becomes more expensive and services stop absorbing part of the cost, access may become more limited. Adoption could slow down, and a technology sold as democratizing could widen the gap between those who can afford it and those who cannot.

The opposite could happen. Models may become smaller, more efficient, and cheaper. Infrastructure may improve. Competition may drive prices down.

I do not know which path wins. Anyone who claims they do probably also has a newsletter to sell you.

People starting out may pay most of the bill

This is where my concern moves beyond my own job to the people still trying to enter the field.

I have spent a long time working mainly with teams of senior engineers. I do not closely follow the current reality of junior positions, so I do not want to invent a picture of the market that I cannot actually see.

But I can see the risk: if companies expect one person with AI to produce what once required a larger team, where does someone gain the experience needed to become senior?

The easy answer is that beginners can use AI to learn. They can. But that view did not begin with AI. In April 2020, when I wrote my guide on how to start learning JavaScript, I was already arguing that the best way to learn was to have a concrete project and get your hands dirty. AI may speed up the journey, but I still have not found a better way to learn than building something real.

But even learning how to learn requires a foundation. Knowing how to formulate a question, doubt a convincing answer, tell a good explanation from a hallucination, and persist when nothing works are not skills distributed equally.

If entering tech already depended on time, education, and access, adding a monthly subscription and another layer of knowledge may make that path even more unequal.

My temporary conclusion

At the beginning of the year, I saw a race where AI was ahead and we were just trying to catch up.

Today, I think running faster may be the wrong metric. For now, our value lies less in the speed at which we produce code and more in our ability to decide, connect context, review, take responsibility, and notice when the machine is solving the wrong problem extremely well.

Product and engineering will probably keep moving closer together. People who can learn the other side may buy themselves some time. I do not know how much.

I also do not know whether the bubble will burst, whether we will program in a language made for machines, or whether “software engineer” will become a title as old-fashioned as “webmaster.”

I only know that continuing to learn still seems like a better strategy than pretending nothing is happening. Reviewing the PR before the apocalypse costs nothing, either.

These are my two Brazilian cents on a subject nobody asked me about. I do not have an answer, only a slightly better-organized paranoia.

P.S. Yes, this article was reviewed by an AI. It would have been rude not to invite the prime suspect.

0. Why I’m Growing HAID in Public, Not Building in Public

Henrique Marques Fernandes — Sun, 05 Apr 2026 16:00:00 +0000

The Hook

Everyone's doing build in public. Twitter (Sorry, X) threads about tech stacks, architecture decisions, deployment pipelines. I love reading those, but that's not what this is.

I'm a software engineer with over 15 years of experience. I've shipped products used by thousands of users well before AI was part of anyone's vocabulary. Building is my comfort zone. I know how to do that. Yes, I know build in public is also about early feedback, not literally asking people to write your code. But bear with me.

Growth? Marketing? Getting strangers on the internet to care about something I made? I have no idea how to do that. And that's exactly what this series is about: documenting the honest, messy process of a developer figuring out growth from scratch.

This is also a return to writing for me. One of my first side projects was marquesfernandes.com, which nowadays is more of a portfolio than a blog. But back then, writing was good for me. It forced me to think more deeply, learn things properly, and gave me a mindfulness moment doing something I'm not particularly good at. After a couple of years without writing, it felt like time to get back to it.

So here's the story so far: how HAID went from a frustrated athlete's side project to something with a real direction, and why the hard part is only starting now.

Why HAID Exists

I'm a runner and triathlete, and for years I've been frustrated by the same thing: there's no single place I can call home for my fitness data.

Strava is great for the social side. Garmin Connect throws a wall of data at you, with a UI that's still rough despite recent redesign attempts. Apple Health is clean and gets a few things right, but misses the social and motivational layer that I think matters. Each app is great at one thing, none at everything, and none of them really talk to each other in a useful way.

I'd already scratched a similar itch before: I built apuama.com because finding running and triathlon events in Brazil was unnecessarily hard. So I'm the kind of person who, when frustrated by a missing tool, just starts building it.

And since I love a side project: let's do this.

The First Instinct: Just Build

I started HAID using technology I knew. First POC, structuring the repo, getting data ingestion working from Apple Health and Garmin, it came together fast. That phase is pure dopamine for a developer. Ideas flowing, pieces clicking into place, the feeling that everything is possible.

I needed a focus point, so I picked one: challenges. Me and a bunch of friends were using Gymrats for group fitness challenges, and I thought I could build something better. It gave me direction and momentum, a concrete feature to rally around instead of drowning in a sea of "wouldn't it be cool if..."

Good instinct. Wrong timing.

The Wrong Early Bet

Challenges are a social feature. And social features need people.

For them to be useful, you need users. But users won't come if no other users are there. Classic chicken-and-egg. Even if I convinced every single person in my network who exercises, that's maybe a few dozen people, and it's not enough for meaningful interaction or useful data.

The challenges idea wasn't wrong forever. But it was wrong as the first lever, because it depended on solving distribution before the product had earned distribution. I didn't see that at the time.

I just needed to get some people in there. How hard could it be?

Trying Everything I Could Think Of

My Own Network

Everyone tells you to start with your own network. So I did. I reached out to friends, colleagues, and training partners. Some joined and were genuinely helpful, testing features, reporting bugs, and giving honest feedback. I'm grateful for them.

But the majority? Read the message, ignored it. Or replied, "yeah for sure, I'll check it out!" and never did.

And that's okay. People are busy. My side project is not their priority. But I'd be lying if I said it didn't sting a little. It did.

I had a couple of close friends, people I've helped in the past with their own stuff, who sent me, "Yeah dude, I'll download it for sure." Never did. That one stings differently than a stranger ignoring you.

Influencer Outreach

Next: founder-led outreach. I followed a bunch of smaller influencers in the running and endurance space. I sent personalized messages and offered Pro tier for life. Almost no replies and zero downloads.

And I get it, social platforms nowadays make it hard for random people to reach creators, which is a feature, not a bug. If I were them, I wouldn't want strangers spamming me either. But it leaves you with a question: if not my network and not influencers, then how?

No budget for ads. No marketing knowledge. Where do people discover new products for free?

Everyone talks about going viral on Reddit. I'd never really used it, but I figured it was worth a shot. I researched subreddits related to fitness tracking, running, and wearables. The goal was simple: share what I was building and ask for help testing.

The few posts that weren't immediately banned got... interesting reactions.

A lot of hate comments. People being harsh for no apparent reason, even when you come with the best intentions. But I get it, this was the internet I always knew existed… I'd just never been on the receiving end before. I'm a private person. I don't like overexposure. So this was new territory.

I got that a lot. And damn, it got under my skin. I've been building software professionally for over 15 years. I've shipped products used by thousands of people at real companies, long before GPT existed. And now, because it's 2026, everything a solo developer puts out gets dismissed as AI-generated garbage?

Don't get me wrong, I use AI. I'm shit scared of it and what it's going to do to my job (but this is a topic for another post), but there's 15 years of caring, learning, understanding tradeoffs, scalability, and security research behind this. How dare user PinkToe1994 say otherwise? hahaha

I think I handled it reasonably well in the end. I took a step back, understood the dynamics, realized people on the internet are often projecting their own frustrations, and moved on. A few users did actually download the app. It was fun seeing random strangers show up in my database. But the conversion rate versus the emotional cost? Not worth the attempt.

The Painful Part Is That People Were Kind of Right

Here's the thing though.

Buried under all the noise, there was one useful signal. I got two pieces of feedback from Reddit and one from a close friend. All three said essentially the same thing:

"Why would I download this? What's different here?"

And honestly? At that point, there was no good answer.

My first iteration of HAID was basically Apple Health + Strava + Garmin mashed together. My only pitch was "everything in one place," and even I wasn't fully convinced that was enough.

I had great plans for the app. I could see the future version in my head. And in my ego, I was thinking: people need to just understand the vision! I just need users to test the data pipeline!

But why would they? Nobody owes me anything.

It hit me because I probably wouldn't download it either. I scroll past app ads every day. Why should other people be different?

I was not just missing users. I was missing a reason for users to care.

That's the lesson.

I had confused functionality with value.

What HAID Actually Became

So I sat down and forced myself to answer the question: what is HAID for? Not what it could be someday, but what it is for right now that nothing else does.

HAID stands for How Am I Doing. And I realized the answer to that question shouldn't come from just wearable data. It should come from context.

Here's what I mean: I love to travel. When I'm traveling, my training falls off. My training load drops. My step count changes. But I'm not a professional athlete. When I travel, I eat, drink, stay out late, enjoy life. No app knows that. And no app uses that information to actually help me. Something as simple as: "You're traveling, enjoy it, but how about one easy run this week?"

Same thing with injuries, stress, life changes. These things directly impact training and recovery, but no fitness app accounts for them. Your Garmin doesn't know you pulled a muscle, had a terrible week at work, or just got back from vacation.

Think about injuries. Apps track training load, TSS, all that, but do they actually warn you to slow down before it's too late? Imagine if the app could see the pattern: three stressful weeks, poor sleep, and a climbing training load. That's a recipe for injury. And with enough users sharing that context, injury prevention gets smarter over time.

The point of HAID is not just to aggregate data, but to help answer a better question: how am I doing, really?

Once I landed on that, things started clicking into place.

Now the Hard Part Starts

I thought I was mostly trying to validate the ingestion pipeline, the UX, and the challenge features. But the real thing I needed to validate was much simpler: did HAID already give people a reason to care?

At that stage, the answer was no.

That was hard to hear, but also useful. Because from that point on, HAID stopped being "a bit of Strava, a bit of Garmin, a bit of Apple Health" and started becoming a product with a more specific idea: helping people understand their fitness through life context, not just raw data.

Building it was the part I already knew how to do.

Growth is the part I'm learning now.

If you want to check out what I'm building: haid.app

Next post: how I turned a mess of feature ideas into an actual product roadmap and what I learned about product thinking as an engineer who'd never done it before.

Como encontrar facilmente eventos de corrida, natação, ciclismo e triatlhon no mundo todo

Henrique Marques Fernandes — Mon, 08 May 2023 17:32:26 +0000

Se você é um entusiasta de esportes, como corrida, triatlhon ou natação, sabe como é importante participar de eventos para melhorar sua performance e se desafiar. No entanto, encontrar os eventos certos pode ser difícil. Felizmente, existe um site que pode ajudar: o Apuama.

O Apuama é um site gratuito que permite que você encontre facilmente eventos de corrida, triatlo e natação em sua região ou em qualquer lugar do mundo. Ele fornece informações detalhadas sobre cada evento, como distância, localização, data e hora, e permite que você se inscreva diretamente no site.

https://apuama.app/

O que faz o Apuama ser tão especial?

O Apuama se destaca por sua facilidade de uso e pela ampla variedade de eventos esportivos disponíveis. O site é projetado para ajudar atletas de todos os níveis a encontrar eventos que se encaixem em seus objetivos e nível de habilidade.

Além disso, o Apuama oferece recursos úteis, como filtros de pesquisa avançados, para ajudá-lo a encontrar exatamente o que você está procurando. Você pode filtrar eventos por tipo de esporte, localização, data, distância e muito mais.

Outra característica que faz o Apuama ser tão especial é a sua comunidade de atletas. O site permite que você se conecte com outros atletas, crie grupos e compartilhe suas experiências e dicas. Você também pode acompanhar a evolução de outros atletas e participar de desafios para manter-se motivado.

Como usar o Apuama?

Busca inteligente Apuama

Usar o Apuama é muito simples. Basta acessar o site, criar uma conta gratuita e começar a pesquisar eventos de corrida, triatlo e natação em sua região ou em qualquer lugar do mundo. Ao encontrar um evento de seu interesse, você pode se inscrever diretamente no site e acompanhar todas as informações relevantes sobre o evento.

Conclusão

Página de evento

O site Apuama é uma ferramenta indispensável para qualquer atleta que queira encontrar facilmente eventos de corrida, triatlo e natação em todo o mundo. Com sua ampla variedade de eventos, recursos úteis e comunidade de atletas, o Apuama torna mais fácil do que nunca encontrar e participar de eventos. Então, comece a usar o Apuama hoje mesmo e descubra eventos incríveis para melhorar sua performance.

O post Como encontrar facilmente eventos de corrida, natação, ciclismo e triatlhon no mundo todo apareceu primeiro em Henrique Marques Fernandes.

boringproxy: Como expor serviços locais publicamente na internet

Henrique Marques Fernandes — Mon, 02 Jan 2023 13:56:58 +0000

Você já precisou compartilhar algum serviço, banco de dados, API ou site que está sendo desenvolvido na sua máquina local publicamente na internet com alguém? Existem maneiras de compartilhar seus projetos sem precisar necessariamente subir ela em algum servidor ou cloud.

Há algum tempo eu escrevi o artigo Túnel/Encaminhamento de Portas com SSH – Ubuntu/Debian que explica exatamente como fazer isso utilizando apenas o SSH, porém para muitos isso pode não ser o suficiente ou de difícil gestão/manutenção. Existem alguns serviços pagos, como o ngrok, mas seu pacote gratuito é bem limitado e o pacote mais barato acaba sendo caro para simples projetos pessoais (algo em torno de 20 USD mês), mas não se preocupe, existem soluções open source para isso.

O desenvolvedor Anders Pitman criou um repositório muito legal de alternativas para o ngrok, nesse tutorial vamos focar em um serviço específico, o boringproxy.

Casos de uso

Veja abaixo alguns casos de uso para esse tipo de túnel.

Você está desenvolvendo uma aplicação local e precisa expor sua API publicamente para compartilhar com alguém ou simplesmente utilizar alguma ferramenta que precise ter acesso a uma URL pública
Você está estruturando um banco de dados e gostaria de conectar para desenvolver em alguma ferramenta como o Retool
Você está criando uma aplicação frontend e gostaria de realizar testes com o Google PageSpeed ou alguma ferramenta de benchmark e para isso precisa que elas consigam encontrar seu projeto publicamente na internet

Esses são alguns de inúmeros casos de uso, e o mais legal é que com o boringproxy podemos expor toda nossa infraestrutura de uma vez, banco de dados, API, frontend e qualquer outro serviço que queremos expor na internet.

boringproxy

boringproxy é uma combinação de um proxy reverso e um gerenciador de túnel.

O que isso significa é que, se você tiver um serviço auto-hospedado (API, MySQL, Postgres, Redis, Frontend em React, Vue, Angular, …) em execução em uma rede local e privada, o boreproxy visa fornecer a maneira mais fácil para expor com segurança (ou seja, com suporte a HTTPS e até proteção por senha) esse servidor à Internet, para que você possa acessá-lo de qualquer lugar.

Começando nossa infraestrutura

Para esse tutorial vamos precisar de basicamente um computador rodando alguns serviços locais, um servidor com IP público para internet e um domínio.

Servidor com IP público

Para o servidor com IP público vamos utilizar o Google Cloud Platform pois ela nos oferece uma máquina no nível gratuito, ou seja, não vamos precisar gastar um tustão.

Primeiro você precisa criar uma conta no GCP. Após a conta criada, vamos criar uma máquina virtual que se enquadre no nível gratuito, que no caso seria uma e2-micro em alguma das regiões: us-west1; us-central1; us-east1.

Instâncias de VM" width="799" height="448">
Acessando o menu do Compute Engine > Instâncias de VM

Primeiro precisamos acessar no menu lateral o serviço de Compute Engine > Instâncias de VM.

Habilitando a API do Compute Engine

Se for a primeira vez que você estiver acessando o serviço de Compute Engine do Google, você será notificado para habilitar a API, basta clicar em Habilitar e esperar o término da habilitação.

Criar instância de VM

Clique no botão de Criar Instância para começar a configuração de nossa nova máquina virtual no GCP.

Configurando nossa nova VM

Agora vamos configurar nossa máquina virtual para as configurações que se aplicam dentro do plano gratuito do Google Cloud, e2-micro e a região escolhida foi aus-central1 (Iowa). Não se preocupe se um preço aparecer a direita, o desconto do nível gratuito será aplicado ao final de cada ciclo de pagamento.

Por padrão a máquina será criada com o sistema operacional Debian e um disco permanente de 10 GB, vamos prosseguir com essa configuração padrão para o nosso tutorial.

Habilitando os protocolos HTTP e HTTPS

Precisamos adicionar uma última configuração, descendo a página você encontrar a sessão de Firewall, selecione para habilitar os tráfegos de HTTP e HTTPS no servidor.

Agora clique em Criar e aguarda a criação da máquina virtual.

Copie o IP público da máquina

Com a criação finalizada, temos agora o IP público de nossa máquina, salve esse número, usaremos ele para configurar nosso domínio.

Configurando o domínio

Eu sempre indico como resolvedor de DNS o Cloudflare, pois ele oferece muitos serviços legais e o melhor, é gratuito. Caso você utilize algum outro serviço, acesse ele para configurar os domínios necessários para o boringproxy funcionar.

Vamos precisar configurar dois domínios, o primeiro domínio será referente ao painel administrativo do boringproxy, por exemplo, boringproxy.marquesfernandes.com e o segundo será domínio do tipo wildcard, ele será o responsável por automaticamente gerenciar os tuneis que vamos criar posteriormente, nesse caso vamos criar um domínio *.boringproxy.marquesfernandes.com.

Ambos irão apontar para o mesmo lugar, o IP público do nosso servidor criado na etapa anterior, então nossa configuração para o primeiro domínio será do tipo A e do segundo vamos utilizar um CNAME para o primeiro, dessa maneira se precisarmos trocar a configuração no futuro, só precisaremos alterar em um lugar.

Criando o primeiro domínio

Crie o primeiro domínio selecionando o tipo como A, insira o IP do servidor copiado na etapa anterior e não se esqueça de desabilitar o proxy do Cloudflare.

Criando o domínio Wildcard

Agora precisamos criar o nosso domínio Wildcard, para isso utilizaremos o * antes do nome do subdomínio que queremos utilizar, nesse caso *.boringproxy.marquesfernandes.com, ele será responsável para quando criarmos nossos tuneis no boringproxy, por exemplo, api.boringproxy.marquesfernandes.com a configuração funcionar sem mais a necessidade de criar subdomínios no Cloudflare.

Configurando o boringproxy no servidor

Agora que temos nossos domínios configurados, podemos finalmente partir para a configuração do boringproxy em nosso servidor, para isso vamos acessar o SSH de nossa máquina virtual. Volte na tela de listagem das máquinas virtuais no Google Cloud e selecione a máquina criada, clique no botão SSH e uma nova janela com o nosso terminal abrirá.

Acessando o SSH da máquina virtual

Aguarde a transferência das chaves de SSH e uma janela parecida com essa deverá ser carregada:

Terminal VM SSH

Ok, agora vamos criar uma pasta que abrigará a instalação do boringproxy, recomendo que a pasta seja criada em /usr/local/boringproxy. Por se tratar de uma pasta em um local que requer permissões root, precisamos utilizar o comando sudo. Vamos utilizar sudo su para não precisar digitar toda hora sudo, mas cuidado, você estará executando qualquer comando com privilégios elevados.


$ sudo su
mkdir /usr/local/boringproxy

Entre na pasta usando o comando cd /usr/local/boringproxy.

Seguiremos as instruções de instalação da documentação do boringproxy para Linux x86_64.

Dentro da pasta criada execute:


curl -LO https://github.com/boringproxy/boringproxy/releases/latest/download/boringproxy-linux-x86_64

chmod +x boringproxy-linux-x86_64

sudo setcap cap_net_bind_service=+ep boringproxy-linux-x86_64

Se você pretende usar os tuneis para encaminhamento de serviços como banco de dados, que utilizam o protocolo TCP e não HTTP, precisamos editar a configuração do sshd para permitir o encaminhamento de portas TCP.

Vamos editar o arquivo /etc/ssh/sshd_config e trocar GatewayPorts no por GatewayPorts clientspecified. Você pode utilizar o seu editor preferido, no meu caso, nano /etc/ssh/sshd_config.

Iniciando o boringproxy no servidor

Muito bem, agora podemos iniciar o boringproxy em nosso servidor, no comando abaixo troque boringproxy.marquesfernandes.compelo primeiro domínio que você configurou.


./boringproxy-linux-x86_64 server -admin-domain boringproxy.marquesfernandes.com

Seu e-mail será solicitado, essa informação é utilizada para gerar os certificados HTTPS necessários utilizando o Let’s Encrypt. Se tudo estiver correto, você deverá ver a mensagem Successfully acquired certificate...

Utilize o comando ctrl + cpara cancelar o serviço, agora utilize o comando ls para listar os arquivos da pasta, note que um arquivo chamado boringproxy_db.json foi criado, ele é um mini banco de dados das configurações do boringproxy. Utilize o comando cat boringproxy_db.json para ver o conteúdo do arquivo e pegar o token de acesso, salve esse token em algum lugar seguro.

Execute novamente o comando ./boringproxy-linux-x86_64 server -admin-domain boringproxy.marquesfernandes.com para iniciar o boringproxy e acesse de seu navegador o domínio do admin, em nosso caso, boringproxy.marquesfernandes.com. Se tudo foi configurado corretamente, uma tela solicitando o token de admin deve aparecer, insira o token e acesse o painel administrativo. Mantenha a janela do terminal da máquina virtual aberta e o serviço rodando para os próximos passo.

Painel administrativo boringproxy

Subindo algumas aplicações locais

Vamos deixar algumas aplicações rodando em nossa máquina local para expor elas na internet usando os tuneis criados. Usarei dois exemplos simples, vamos subir um projeto em React e um banco de dados em Postgres rodando em Docker para testar tanto uma configuração HTTPS e uma TCP, lembrando que você pode usar para qualquer serviço que você queria disponibilizar na internet, seja uma API, algum outro banco de dados, etc.

React App

Vamos utilizar o create-react-app para criar uma aplicação simples em nossa máquina local e expor ele publicamente na internet.


npx create-react-app my-app
cd my-app
npm start

React App funcionando

Se tudo der certo, sua aplicação estará rodando e disponível na porta 3000. Deixe esse terminal rodando.

Postgres no Docker

Para subir o banco de dados, você precisa ter o Docker instalado e executar o seguinte comando:


docker run --name my-postgres -e POSTGRES_PASSWORD=123456 -p 5432:5432 postgres

Executando o Postgres no Docker

Agora temos o nosso banco de dados disponível na porta 5432. Use algum cliente de banco, como o DBvear, usando o usuário postgres e a senha 123456 para garantir que a conexão foi bem sucedida.

Criando os tuneis

Agora que já temos algumas aplicações rodando, podemos criar a configuração de nossos tuneis, para isso vamos voltar ao painel administrativo em boringproxy.marquesfernadnes.com.

Adicionando um cliente

Criando um cliente no boringproxy

Primeiro precisamos criar um cliente, para isso navegue até a aba de clients e adicione um cliente com o nome de admin.

Criando os túneis

O painel de túneis permite criar e remover túneis. Ele fornece uma maneira de especificar as configurações de um túnel:

Domain O FQDN de um domínio apontando para o boringproxyservidor. Com a configuração do caractere curinga do DNS, pode ser qualquer subdomínio do admin-domain. Você deve inserir o domínio completo a partir do qual deseja que o túnel seja acessado, não apenas o subdomínio. Por exemplo, se você tivesse um registro DNS curinga *.boringproxy.marquesfernandes.comapontando para seu servidor de proxy chato e desejasse que um servidor de mídia fosse acessado em api.boringproxy.marquesfernandes.com, você teria que inserir api.boringproxy.marquesfernandes.com neste campo.
Client Name Escolha um cliente conectado como parceiro de túnel
Client Address O destino de encaminhamento visto do cliente
Client Port
O encaminhamento de porta para
Allow External TCP Ativa o túnel TCP bruto para outros protocolos além do HTTP
Password Protect Ative para definir nome de usuário e senha para autenticação básica HTTP

Adicionando o túnel para a aplicação React

Agora vamos criar o nosso primeiro túnel, ele fara o proxy para a nossa aplicação React. Configure o domínio desejado no campo de domain utilizando o padrão do dominio. wildcard que criamos.

Domain: react.boringproxy.marquesfernandes.com
Tunnel Port : Random
Client Name : admin
Client Port : 3000 (port da nossa aplicação react)
TLS Termination : Client HTTPS

Adicionando o túnel para o banco de dados

Vamos criar um túnel também para o nosso banco de dados, seguiremos os mesmos passos do túnel para o React, porém, trocando algumas configurações.

Tunnel Port : 5432
TLS Termination : Server HTTPS
Allow External TCP : Sim

Listagem de túneis do boringproxy

Agora você verá os dois túneis criados como na listagem acima.

Configurando o boringproxy na máquina local

E por fim, precisamos instalar o boringproxy em nossa máquina local, siga na página oficial as instruções de instalação referente ao seu respectivo sistema operacional. Lembrando que se você estiver usando MacOS como eu, você precisa baixar a versão boringproxy-darwin-x86_64 e executar o comando sudo chmod +x boringproxy-dawrin-x86_64 para que ele se torne um executável.

Agora precisamos iniciar o serviço para conectar em nosso servidor, para isso executaremos o seguinte comando:


./boringproxy-dawrin-x86_64 client \
    -server boringproxy.marquesfernandes.com -user admin -token <token_copiado_do_servidor> -client-name admin

Os túneis serão sincronizados, os certificados necessários para o lado cliente serão emitidos e se tudo caminhar conforme o esperado, suas aplicações agora estarão disponíveis na internet. Em um navegador acesse a URL configurada para o React e veja a magia e faça o teste com o seu banco de dados também.

React App acessível via Proxy

Configurando o boringproxy para rodar como serviço

Se você deseja configurar o boringproxy no lado servidor como um serviço, para evitar o trabalho de toda vez que quiser utilizar, precisar ir no ssh do servidor e subir, siga o tutorial:

Criando um Serviço Linux com systemd

O post boringproxy: Como expor serviços locais publicamente na internet apareceu primeiro em Henrique Marques Fernandes.

Top 6 Sites para Encontrar, Gerar, Criar e Compartilhar Memes

Henrique Marques Fernandes — Fri, 19 Aug 2022 14:10:19 +0000

Os memes caíram no gosto da internet, especialmente para nós brasileiros, vamos ser honestos, adoramos um bom meme não? Memes são divertidos e passam a mensagem provavelmente melhor do que poderíamos escrever, afinal, uma imagem vale por mil palavras.

Você já se pegou procurando aquele meme antigo? Ou então querendo criar um meme customizado para mandar para algum grupo no zapzap? Pois bem, vamos facilitar sua vida com uma lista dos 6 melhores sites para você encontrar e criar memes online! Nada de baixar Photoshop ou qualquer outro programa para isso.

1. Meme Generator

memegenerator.net

O Meme Generator é possivelmente uma das melhores ferramentas disponíveis para criar seus próprios memes. Simples e intuitivo, ele também permite que você navegue por memes criados por outras pessoas, um marketplace de memes!

2. quickmeme

quickmeme.com

O quickmeme permite navegar pelos memes e criar os seus próprios a partir de qualquer combinação de imagens e texto. Seu layout lembra muito o design do site 9gag, com a possibilidade de votar e avaliar memes, bem como gerar memes aleatórios.

3. Imgur

imgur.com/memegen

Imgur vem com muitas imagens embutidas que podem ser usadas para fazer seus memes instantaneamente. Esse site é amado pelas comunidades do Reddit, possui uma ampla variedade não só de memes, como de imagens e ferramentas.

4. Imgflip

imgflip.com/memegenerator

Os geradores de imagem Imgflip são projetados para serem incrivelmente rápidos e fornecer personalização poderosa, ao mesmo tempo, em que são simples e fáceis de usar. As imagens criadas no Imgflip podem ser “privadas” se você quiser apenas baixar a imagem e salvá-la para si mesmo, ou podem ser salvas publicamente para a comunidade.

5. livememe

livememe.com

Já na página inicial do LiveMeme você encontra uma enorme seleção dos personagens virais recorrentes mais populares da web, de Fry de Futurama a Jean-Luc Picard e Batman. A partir daí, basta adicionar sua legenda e pronto!

O post Top 6 Sites para Encontrar, Gerar, Criar e Compartilhar Memes apareceu primeiro em Henrique Marques Fernandes.

8 Playlists do Spotify para Programação e Foco para 2022

Henrique Marques Fernandes — Tue, 29 Mar 2022 11:45:49 +0000

Quando precisamos focar para resolver aquele problema difícil, aquele código que trava a nossa mente, ou simplesmente tirar todo aquele barulho externo, seja no home-office (quem nunca teve problema com furadeira?), ou no escritório presencial como todas aquelas conversas em volta. É cientificamente comprovado que a música pode nos colocar no clima certo e desencadear o fluxo de ideias. O problema é que encontrar a música certa não é fácil por isso montei essa lista com as playlists que mais escuto no meu dia a dia, se você precisa encontrar a música certa para desenvolver e se concentrar melhor no trabalho veio no lugar certo. Mas Henrique, eu não tenho Spotify… Deixa no comentário qual app você usa que a gente da um jeito!

1. Coding Beats

Coding Beats é uma playlist bem balanceada, perfeita pra aqueles dias que concentrar está difícil.

2. Aesthetic Lofi

Se você está procurando uma playlist com batidas leves e músicas extremamente agradáveis ao ouvido vá de Aesthetic Lofi.

3. Lofi Coding

Lofi Coding é pra quem busca algo mais tranquilo, que inspire a paz interior para não socar o computador.

4. Lofi Coders

Outra playlist com músicas para acalmar a alma, Lofi Coders pode evitar que você xingue algum colega.

5. Code-fi / lofi beats

Code-fi / lofi beats é mais uma playlist de boas para a acalmar a mente.

6. Chill Lofi Study Beats

Chill Lofi Study Beats traz algumas músicas focadas em batidas mais profundas.

7. Chasing Sunsets

Se você busca uma playlist mais animada para sua sessão de trabalho, Chasing Sunsets é com certeza uma das melhores playlists na minha opinião.

8. Ibiza Lounge Music

Outra alternativa animada, Ibiza Lounge Music vai te fazer sentir estar trabalhando numa vibe bem relax e animada.

E você? Tem alguma playlist favorita para aqueles momentos de foco? Compartilha aí com a gente nos comentários!

O post 8 Playlists do Spotify para Programação e Foco para 2022 apareceu primeiro em Henrique Marques Fernandes.

Melhores temas de ícones para Ubuntu e Linux Mint (Debian)

Henrique Marques Fernandes — Sat, 03 Apr 2021 21:27:22 +0000

Se você não gosta dos ícones que vieram na sua distro, seja ela Ubuntu ou Linux Mint, ou simplesmente quer dar uma nova cara para o seu desktop, saiba que é possível dar um toque de personalidade a mais usando temas de ícones personalizados!

Existem centenas de temas de ícones por ai, separei os que eu mais gosto e já usei pra facilitar a sua busca. Eles variam de veráios estilos que vão desde glifos sutis, planos e 2D a pacotes que vão de encontro ao brilho, gradiente e detalhes.

1. Papirus Icon Theme

Papirus é um tema de ícone SVG gratuito e de código aberto para Linux, baseado no Paper Icon Set com muitos novos ícones e alguns extras, como suporte para Hardcode-Tray , suporte para esquema de cores KDE , suporte para Folder Color e outros .

O tema do ícone do Papirus está disponível em quatro variantes:

Papirus
Papirus Dark
Papirus Light
ePapirus (para sistema operacional elementar e Pantheon Desktop)

2. Numix Circle

Circle é um tema de ícone para Linux do projeto Numix. O conjunto de ícones do Círculo Numix agora abrange vários milhares de ícones de aplicativos, desde os favoritos dos velhos tempos até os mais novos, todos eles (sem surpresa) colocados em uma moldura circular.

3. Qogir Icon Theme

Qogir é um tema de design plano para GTK 3, GTK 2 e Gnome-Shell que suporta ambientes de desktop baseados em GTK 3 e GTK 2 como Gnome, Unity, Budgie, Cinnamon Pantheon, XFCE, Mate, etc.

4. OS Catalina

Se você deseja fazer o Ubuntu se parecer com um Mac – você pode gostar da aparência do sistema operacional, mas não de suas limitações – um conjunto de ícones como o OS Catalina é uma maneira fácil de fazer isso.

5. Vimix

O tema do ícone Vimix é baseado no Paper-Icon-Theme, um tema moderno de ícones freedesktop cujo design é baseado no uso de cores fortes e formas geométricas simples para compor os ícones. Cada ícone foi meticulosamente projetado para uma visualização perfeita de pixels.

Embora se inspire nos ícones do Material Design do Google, alguns aspectos foram ajustados para se adequar melhor a um ambiente de desktop.

O post Melhores temas de ícones para Ubuntu e Linux Mint (Debian) apareceu primeiro em Henrique Marques Fernandes.

Como saber e validar o dígito verificador do RG (Registro Geral)

Henrique Marques Fernandes — Sat, 03 Apr 2021 21:04:51 +0000

O RG (Registro Geral), ou cédula de identidade, carteira de identidade, identidade é o nosso documento nacional de identificação civil no Brasil. Os dados que constam nesse documento variam de acordo com o órgão responsável pela sua emissão bem como a sua regra matemática de autenticidade. Nesse artigo vamos demonstrar a regra e validação baseado em um documento emitido pela SSP-SP.

O dígito verificador , nada mais é que o dígito que vem após o traço (xx.xxx.xxx- d ). Ele é um mecanismo de autenticação utilizado para verificar a validade e a autenticidade do um valor numérico, funciona como uma prevenção de fraudes ou possíveis erros de transmissão e geração do documento.

Como calcular o dígito verificador do RG

Para aprender a lógica por trás da geração do dígito verificador utilizaremos neste artigo um RG válido e gerado randomicamente: 39.406.714-?

Primeiro vamos fazer uma tabela com 3 linhas e 8 colunas, teremos na primeira linha os 8 primeiros algarismos do número do RG.

| 3 | 9 | 4 | 0 | 6 | 7 | 1 | 4 |
| | | | | | | | |
| | | | | | | | |

Agora precisamos preencher a segunda linha, ela sempre obedecerá uma sequência lógica de números para todos o cálculo de qualquer RG. A sequência é 2,3,4,5,6,7,8 e 9.

| 3 | 9 | 4 | 0 | 6 | 7 | 1 | 4 |
| 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| | | | | | | | |

Agora para obter os valores da terceira linha devemos multiplicar os números de cada linha por coluna. Por exemplo, 3×2, 9×3 e assim por diante.

| 3 | 9 | 4 | 0 | 6 | 7 | 1 | 4 |
| 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 6 | 27 | 16 | 0 | 36 | 49 | 8 | 36 |

Agora que temos nossa tabela completa, precisamos somar todos os números obtidos na terceira linha. Em nosso exemplo teremos: 6 + 27 + 16 + 0 + 36 + 49 + 8 + 36 = 178.

Agora precisamos descobrir o resto da divisão desse número por 11, você pode descobrir usando a calculador do seu computador usando o operador mod : 178 mod 11 = 2.

Agora precisamos subtrair de 11 o resto da nossa divisão e teremos finalmente o nosso dígito verificador: 11 – 2 = 9.

Abaixo você encontra o algoritmo feito em JavaScript ES5 seguindo a lógica explicada acima.


function descobrirDigito(rg) {
    var digitos = rg.split("");
    var totais = [];
    var total = 0;

    // Multiplicamos os que seriam da primeira linha com os da segunda    
    digitos.forEach(function (digito, index) {
        totais.push(Number(digito) * (2 + index));
    });

    // Multiplicamos as colunas
    totais.forEach(function(numero) { total += numero });

    // Descobrimos o resto da divisão
    var resto = total % 11;

    return 11 - resto;
}

console.log(descobrirDigito("39406714"));

Casos especiais

Como tudo no Brasil, temos alguns casos especiais que precisamos estar atentos:

O dígito verificador do RG é X

Quando nos deparamos com o dígito verificador X , isso significa que o resultado da última etapa de nossa conta é 10 (11 – 1). Então o dígito verificador 10 foi substituído pelo algarismo romano X.

O dígito verificador é 0

Qundo nos deparamos com o dígito verificador 0 , isso significa que o resultado da última etapa de nossa conta é 11 (11 – 0). Então o dígito verificador 11 foi substituído pelo algarismo 0.

O post Como saber e validar o dígito verificador do RG (Registro Geral) apareceu primeiro em Henrique Marques Fernandes.

Como configurar o headset bluetooth com microfone no Ubuntu, Mint (Debian)

Henrique Marques Fernandes — Fri, 02 Apr 2021 14:26:15 +0000

Se você usa ou acabou de migrar para o ambiente linux, especialmente nas distros Ubuntu ou Mint, derivados do Debian, você pode encontrar problemas com o microfone do seu headset bluetooth.

Especialmente agora durante a pandemia, as famosas call (videoconferência) fazem cada vez mais parte do nosso cotidiano. Então você resolveu comprar aquele fone bluetooth bacana pra usar e quando conectou o seu microfone não funcionou? Não se preocupe, existe uma maneira de conseguir fazer o microfone do seu headset bluetooth funcionar no linux.

Esse tutorial foi testado com fones da JBL e Air Pods, mas ele deverá funcionar para a maioria dos casos.

Ativando o microfone do headset bluetooth

Para que o headset consiga funcionar corretamente com o microfone, você precisará habilitar o perfil de áudio HSP/HFP. Porém, por padrão, o pulseaudio (servidor de som embarcado nessas distribuições do linux) só oferece suporte para o HSP. Para fazer o HSP/HFP funcionar, precisamos habilitar o HFP no pulseaudio e para isso vamos utilizar o serviço ofono.

Instale o ofono


$ sudo apt install ofono

Configure o pulseaudio para usar o ofono

Edite o arquivo /etc/pulse/default.pa , encontre a linha load-module module-bluetooth-discover e mude para load-module module-bluetooth-discover headset=ofono
Adicione o usuário pulse ao grupo bluetooth para que ele tenha as permissões necessárias


$ sudo usermod -aG bluetooth pulse

Edite e adicione as permissões no arquivo /etc/dbus-1/system.d/ofono.conf adicione o código abaixo logo antes do fechamento </busconfig>


<policy user="pulse">
    <allow send_destination="org.ofono"/>
</policy>

Para fazer o ofono funcionar é necessário fornecer um modem para ele. E para isso vamos instalar um emulador de modem chamado phonesim que será implementado pelo ofono para funcionar. Instale o ofono-phonesim:


$ sudo add-apt-repository ppa:smoser/bluetooth
$ sudo apt-get update
$ sudo apt-get install ofono-phonesim

Configure o phonesim adicionando as seguintes linhas no arquivo /etc/ofono/phonesim.conf


[phonesim]
Driver=phonesim
Address=127.0.0.1
Port=12345

Agora, reinicie o serviço ofono:


$ sudo systemctl restart ofono.service

Agora precisamos definir e habilitar alguns serviços para iniciar o ofono-phonesim como serviço.

Para executar ofono-phonesim -p 12345 /usr/share/phonesim/default.xml na inicialização do sistema, crie como root o arquivo /etc/systemd/system/ofono-phonesim.service com o seguinte conteúdo:


[Unit]
Description=Run ofono-phonesim in the background

[Service]
ExecStart=ofono-phonesim -p 12345 /usr/share/phonesim/default.xml
Type=simple
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Depois que o ofono-phonesim for executado, você também precisará habilitar e colocar o modem phonesim online.

Para isso vamos usar o código de um repositório git:


$ cd /tmp
$ git clone git://git.kernel.org/pub/scm/network/ofono/ofono.git
$ sudo mv ofono /opt/

Agora você pode habilitar e tornar o modem phonesim online criando outro serviço do que depende do serviço ofono-phonesim.Novamente, crie um novo arquivo de serviço como root o arquivo em /etc/systemd/system/phonesim-enable-modem.service e coloque o seguinte conteúdo:


[Unit]
Description=Enable and online phonesim modem
Requires=ofono-phonesim.service

[Service]
ExecStart=/opt/ofono/test/enable-modem /phonesim
ExecStart=/opt/ofono/test/online-modem /phonesim
Type=oneshot
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Em seguida, execute os seguintes comandos para habilitar e executar os dois daemons:


$ sudo systemctl daemon-reload
$ sudo systemctl enable ofono-phonesim.service
$ sudo systemctl enable phonesim-enable-modem.service
$ sudo service phonesim-enable-modem start

Verifique se tudo ocorreu como esperado e se o serviço está sendo executado:


$ sudo service phonesim-enable-modem status

Por fim, reinicie o pulseuadio:


$ pulseaudio -k.

Agora você já deve conseguir enxergar o seu headset como dispositivo de input na parte de configuração de som. Existe uma certa instabilidade nesse setup, de vez em quando pode ser que o seu fone de uma desconfigurada ou a troca de perfil de áudio não funcione, quando isso ocorrer, reinicie os serviços como descrito acima e também o pulseaudio.

O post Como configurar o headset bluetooth com microfone no Ubuntu, Mint (Debian) apareceu primeiro em Henrique Marques Fernandes.

O que é codificação de URL e como funciona?

Henrique Marques Fernandes — Sun, 21 Feb 2021 00:46:42 +0000

Um URL (acrônimo em inglês para Uniform Resource Locator) é o endereço de um recurso na rede mundial de computadores. Os URLs têm uma estrutura bem definida que foi formulada na RFC 1738 por Tim Berners-Lee, inventor da rede mundial de computadores.

Uma URL segue a seguinte sintaxe:

protocolo:[//[usuario:senha@]host[:porta]]caminho[?parametro][#fragmento]

O uso mais conhecido para a URL é para a conexão em sites, como podemos ver no exemplo abaixo.

https://google.com.br

Diversas melhorias foram feitas na RFC inicial. O RFC atual que define a sintaxe do URI é o RFC 3986. Esta postagem contém informações do documento RFC mais recente.

Diferença entre URL e URI

Você provavelmente vai escutar em alguns lugares falando URL e em outros URI.

Um URI é um identificador para um recurso específico. Como uma página, livro ou documento
A URL é tipo especial de identificador que também lhe diz como acessá-lo, como HTTPs, FTP, etc. Um exemplo seria o próprio site https://marquesfernandes.com

Se o protocolo (HTTPS, FTP, etc.) estiver presente ou implícito para um domínio, você deve chamá-lo de URL, embora ele também seja um URI. Todos os URLs são URIs, mas nem todos os URIs são URLs.

Codificação de URL (codificação com percentual)

Um URL é composto de um conjunto limitado de caracteres pertencentes ao conjunto de caracteres US-ASCII. Esses caracteres incluem dígitos (0-9), letras (AZ, az), e alguns caracteres especiais, ("-", ".", "_", "~"), por se tratar de US-ASCII, os caracteres permitidos não incluem os acentos como os encontrados na língua portuguesa.

Existem alguns caracteres especiais que possuem um uso especial nas URLs. Alguns exemplos de caracteres reservados são ?, /, #, :etc. Quaisquer dados transmitidos como parte da URL, seja em consulta segmento de corda ou caminho, não deve conter esses caracteres diretamente.

Além disso, caracteres perigosos como espaço, \, <, >, {, }etc, e qualquer carácter fora do conjunto de caracteres ASCII, não são permitidos diretamente nas URLs.

Então, o que fazer quando precisamos enviar dados na URL que contenham esses caracteres não permitidos? Usamos a magia da codificação.

A codificação de URL converte os caracteres reservados e inseguros em um formato compreendido por todos os navegadores e servidores da internet. Primeiro convertemos o caractere em um ou mais bytes. Então, cada byte é representado por dois dígitos hexadecimais com um prefixo de % (por exemplo %20). O sinal de porcentagem é usado como um caractere de segurança.

Exemplo de codificação de URL

Espaço: um dos caracteres codificados de URL mais frequentes que você provavelmente encontrará é um espaço vazio. O valor ASCII do espaço vaziocaractere em decimal é 32, que quando convertido em hexadecimal passa a ser 20. Agora, adicionamos o prefixo de porcentagem ( %), que nos dá o valor codificado do URL: %20.

Tabela de referência de codificação de porcentagem de caracteres ASCII

A tabela a seguir é uma referência de caracteres ASCII para sua forma codificada de URL correspondente.

Decimal	Personagem	Codificação de URL (UTF-8)
0	NUL (caractere nulo)	%00
1	SOH (início do cabeçalho)	%01
2	STX (início do texto)	%02
3	ETX (fim do texto)	%03
4	EOT (fim da transmissão)	%04
5	ENQ (inquérito)	%05
6	ACK (reconhecer)	%06
7	BEL (sino)	%07
8	BS (retrocesso)	%08
9	HT (guia horizontal)	%09
10	LF (alimentação de linha)	%0A
11	VT (guia vertical)	%0B
12	FF (alimentação de formulário)	%0C
13	CR (retorno de carro)	%0D
14	SO (mude para fora)	%0E
15	SI (mudança)	%0F
16	DLE (escape do link de dados)	%10
17	DC1 (controle de dispositivo 1)	%11
18	DC2 (controle de dispositivo 2)	%12
19	DC3 (controle do dispositivo 3)	%13
20	DC4 (controle do dispositivo 4)	%14
21	NAK (reconhecimento negativo)	%15
22	SYN (sincronizar )	%16
23	ETB (fim do bloco de transmissão)	%17
24	POSSO (cancelar)	%18
25	EM (fim da mídia)	%19
26	SUB (substituto)	%1A
27	ESC (escapar)	%1B
28	FS (separador de arquivo)	%1C
29	GS (separador de grupo)	%1D
30	RS (separador de registro)	%1E
31	US (separador de unidade)	%1F
32	espaço	%20
33	!	%21
34	“	%22
35	#	%23
36	$	%24
37	%	%25
38	E	%26
39	‘	%27
40	(	%28
41	)	%29
42	*	%2A
43	+	%2B
44	,	%2C
45	–	%2D
46	.	%2E
47	/	%2F
48	0	%30
49	1	%31
50	2	%32
51	3	%33
52	4	%34
53	5	%35
54	6	%36
55	7	%37
56	8	%38
57	9	%39
58	:	%3A
59	;	%3B
60	<	%3C
61	=	%3D
62	>	%3E
63	?	%3F
64	@	%40
65	A	%41
66	B	%42
67	C	%43
68	D	%44
69	E	%45
70	F	%46
71	G	%47
72	H	%48
73	I	%49
74	J	%4A
75	K	%4B
76	L	%4C
77	M	%4D
78	N	%4E
79	O	%4F
80	P	%50
81	Q	%51
82	R	%52
83	S	%53
84	T	%54
85	U	%55
86	V	%56
87	C	%57
88	X	%58
89	Y	%59
90	Z	%5A
91	[	%5B
92	\	%5C
93	]	%5D
94	^	%5E
95	_	%5F
96	`	%60
97	a	%61
98	b	%62
99	c	%63
100	d	%64
101	e	%65
102	f	%66
103	g	%67
104	h	%68
105	i	%69
106	j	%6A
107	k	%6B
108	eu	%6C
109	m	%6D
110	n	%6E
111	o	%6F
112	p	%70
113	q	%71
114	r	%72
115	s	%73
116	t	%74
117	u	%75
118	v	%76
119	C	%77
120	x	%78
121	y	%79
122	z	%7A
123	{	%7B
124
125	}	%7D
126	~	%7E
127	DEL (apagar)	%7F

O post O que é codificação de URL e como funciona? apareceu primeiro em Henrique Marques Fernandes.

Como baixar todas suas fotos marcadas no Facebook

Henrique Marques Fernandes — Tue, 05 Jan 2021 23:06:13 +0000

O Facebook vem caindo em desuso há um tempo. Então recentemente pensei em fazer um backup de todas minhas fotos, até que me deparei com um problema: como baixar as fotos em que eu fui marcado?

O Facebook agora permite que você baixe todos os dados fornecidos a ele, fotos, curtidas, publicações, contatos e muito mais, mas ele não oferece a opção de baixar suas fotos marcadas/tagged por amigos.

Eu encontrei uma solução, relativamente simples, mas você vai precisar ter o Python 2 instalado para rodar um script:

Baixe o script em Python: https://github.com/mgjohnston/fmpd
Acessa a página “Fotos com você” e role até o final dela- https://www.facebook.com/me/photos
Abra o Inspecionar do Google Chrome (ctrl + shift + i), ignore o aviso de segurança e executa o seguinte código:


for (link of document.getElementsByTagName('a')) { 
  if (!link.href.includes("?fbid=")) continue; 
  console.log(new URL(link.href).searchParams.get("fbid")); 
}

Agora você precisa copiar todas as URLs geradas e salvar em um arquivo chamado list.txt. Não esqueça de limpar o arquivo e deixar apenas os FBIDs das fotos.

Vamos precisar agora dos cookies do Facebook para o script conseguir funcionar e acessar as fotos para baixar em seu computador. Eu recomendo que você use a extensão cookies.txt para o Chrome e salve o arquivo como “cookies.txt” na mesma pasta em que você baixou o script.
Use o Python 2 para rodar o script e baixar as fotos.


python download.py

O post Como baixar todas suas fotos marcadas no Facebook apareceu primeiro em Henrique Marques Fernandes.