Jessica Temporal

Recuperando commits perdidos com git reflog

Sat, 20 Jun 2026 12:00:00 +0000

Tem um tipo específico de pânico que bate quando parece que um commit simplesmente sumiu. Talvez você tenha rodado um hard reset, ou um rebase deu errado, e o trabalho que estava aí um minuto atrás não aparece em lugar nenhum do seu histórico. Antes de assumir que ele foi embora para sempre, tem um comando que pode te ajudar a trazer isso de volta: git reflog.

O que é o reflog?

O Git mantém um registro privado de todos os lugares por onde o HEAD passou. Tudo o que você faz no Git que move o ponteiro HEAD fica registrado, seja porque você fez um commit, deu um checkout, rodou um reset, ou porque um rebase ou merge mexeu nele.

Esse registro de movimento fica no log de referência (do inglês reference log ou reflog, para encurtar) e ele é local na sua máquina. Então, mesmo quando um commit não aparece mais no git log, a referência para ele geralmente ainda está no reflog.

Encontrando o commit que você perdeu

Para ver o reference log, você pode rodar o comando abaixo:

git reflog

Você vai ver uma lista de movimentos recentes, com a entrada mais recente no topo, como na imagem abaixo.

Cada linha tem um hash curto, uma referência como HEAD@{2}, e uma descrição do que aconteceu, coisas como “commit”, “reset: moving to” ou “checkout”.

Mesmo que seja difícil se acostumar a ler esse novo formato de log, a descrição e a ordem geralmente deixam claro onde você estava e podem ser a indicação que você precisa para saber para onde quer voltar.

Voltando para lá

Quando você encontrar a entrada certa, copie o hash. Depois, mova o seu branch de volta para aquele ponto:

git reset --hard <hash>

Substitua <hash> pelo hash que você encontrou no reflog.

Por exemplo, pensando na imagem acima, se você quiser voltar para o estado antes do reset, você precisaria rodar o seguinte:

git reset --hard a68cffa

Depois disso, o seu estado de trabalho volta a bater com o momento antes do erro, como se nada tivesse acontecido.

Uma observação rápida: git reset --hard descarta as suas mudanças não commitadas. Então tenha certeza de que você realmente quer cair nesse estado anterior antes de rodar o comando. Se você não tiver certeza, você pode usar git switch para ir até o hash primeiro e dar uma olhada sem mover o seu branch.

Recapitulando

A maioria das pessoas aprende sobre o reflog do jeito difícil, depois de perder trabalho por causa de um reset ou de um rebase. Então saber que ele existe pode ser uma mão na roda numa emergência.

Recapitulando os passos para restaurar um estado anterior perdido com o reflog:

Encontre o estado para o qual você quer voltar e copie o hash.
Confira se esse é mesmo o estado que você quer restaurar com git switch <hash>. Se não for, repita os passos 1 e 2 até encontrar o estado certo.
Rode git reset --hard <hash> para voltar para ele.

O reflog combina bem com os outros comandos que movem o HEAD: desfazendo o último commit e reaproveitando a mensagem, atualizando um branch com git rebase, e usando git stash. Se algum deles te fizer perder trabalho, o reflog é a sua rede de segurança.

Recovering lost commits with git reflog

Sat, 20 Jun 2026 12:00:00 +0000

There is a particular kind of panic that hits when a commit looks like it just vanished. Maybe you ran a hard reset, or a rebase went sideways, and the work you had a minute ago is nowhere in your history. Before you assume it is gone for good, there is one command that may be able to bring it back: git reflog.

What is the reflog?

Git keeps a private log of everywhere HEAD has been. Everything you do in Git that moves the HEAD pointer is recorded, whether you made a commit, did a checkout, ran a reset, or a rebase or merge moved it around.

The log of that movement lives in the reference log (reflog for short), and it is local to your machine. So even when a commit no longer shows up when you do git log, the reference to it usually still lives in the reflog.

Finding the commit you lost

To see the reference log you can run the command below:

git reflog

You get a list of recent moves, with the most recent entry at the top, like shown in the following image.

Each line has a short hash, a reference like HEAD@{2}, and a description of what happened, things like “commit”, “reset: moving to”, or “checkout”.

Even though it may be hard to get used to reading this new format of log, the description and order usually make it clear where you were and can be the indication you need to know where you want to go.

Getting back to it

Once you have spotted the right entry, copy its hash. Then move your branch back to that point:

git reset --hard <hash>

Replace <hash> with the hash you found in the reflog.

For example, thinking of the image above, if you want to go to the state before the reset you’d need to run the following:

git reset --hard a68cffa

And after that, your working state matches the moment before the mistake, like it never happened.

A quick note of caution: git reset --hard discards your current uncommitted changes, so make sure you actually want to land on that older state before you run it. If you are not sure, you can use git switch to the hash first to look around without moving your branch.

Recap

Most people learn about the reflog the hard way after losing the work to a reset or a rebase, so knowing it exists can be extremely helpful in a pinch.

Here’s a recap of the steps to restore a previous lost state with reflog:

Find the state you want to go back to, and copy its hash.
Check if that’s the actual state you want to restore with git switch <hash>. If it’s not, repeat steps 1 and 2 until you find the correct state.
Run git reset --hard <hash> to get back to it.

The reflog pairs well with the other commands that move HEAD around: undoing the last commit and reusing the message, updating a branch with git rebase, and using git stash. If any of those ever lose you some work, the reflog is your safety net.

Automating CSS versioning in staging through GitHub Actions

Tue, 03 Feb 2026 06:00:00 +0000

While setting up a staging environment in a new hosting platform, I ran into an issue where static assets were aggressively cached with no straightforward way to invalidate them. This made staging deploys unreliable and validating changes slow.

I could have spent hours fighting with cache headers and purge APIs, but there’s a simpler approach. Rather than fighting the cache, I leaned into patterns that avoid invalidation entirely and make staging behaviour explicit and predictable.

The Problem

This staging environment was behaving badly:

Static assets were cached aggressively
Cache purging is unavailable
Deploys appear as “successful” but changes were not visible

So I was stuck with a cache that I couldn’t purge and changes I needed to validate somewhere other than my local machine. So I figured it was time to version the styling scripts.

Versioned static assets

One reliable way to bypass aggressive caching is to change the asset URL on every deploy.

Static assets are referenced with a deploy-specific version, in my case I went for short git SHA.

<link rel="stylesheet" href="/static/css/base.css?v=6ea4bbe">

This was enough to fix the problem:

CDNs cache by URL.
A new URL guarantees a cache miss.
No reliance on purge APIs or cache headers.
Simple, deterministic behaviour.

This approach works well for staging, where correctness matters more than caching efficiency. Then my next challenge was: how to get this into my deployment without me manually editing the URLs every single time?

Label-gated staging deploys

I can’t remember to update URLs manually every single time, so instead of suffering every time my CSS wouldn’t update accordingly, I adjusted my code and added a step in my GitHub Actions to take care of this for me.

Since I’m the sole developer on this project, my staging deploys are explicitly controlled using pull request labels.

A pull request is deployed to staging only when the preview is applied.

GitHub Actions

In case you want to replicate this for yourself, here’s how to do it. The steps are pretty simple:

Run your tests;
If tests pass deploy the app to the staging environment
Make a comment on your PR so you know the version of the CSS that should be live
Enjoy QA-ing your staged deployment

First the setup for your action:

name: Run tests and stage changes

on:
  pull_request:
    types:
      - opened
      - synchronize
      - reopened
      - labeled
      - unlabeled

jobs:
# ...

This names the action and tells it which Pull Requests to look at, in my case all of them.

1. Tests running

I want to make sure that all pull requests pass my test suite, so the first job checks out the pull request, installs the dependencies and creates necessary files, then runs the tests:

# ...

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout PR branch
        uses: actions/checkout@v4

      - name: Install uv
        uses: astral-sh/setup-uv@v7

      - name: Install dependencies
        run: uv sync --extra dev

      - name: Setup test environment
        run: cp .env.example .env

      - name: Run tests
        run: uv run pytest

  deploy-staging:
  # ...

This guarantees code quality in all pull requests before I even consider deployment.

With a successful test we can move on to deployment.

2. Stage the deployment

The deployment job only needs to run when the preview label is included.

Then a neat trick: you can get the SHA for the deployment with github.sha and write it out to a file, in this case .deploy_sha and once the code is sent to the cloud it can use that file to read the information.

jobs:
  test:
    # ...

  deploy-staging:
    # Only run after tests pass
    needs: test
    if: contains(github.event.pull_request.labels.*.name, 'preview')

    runs-on: ubuntu-latest
    
    permissions:
      contents: read
      pull-requests: write

    steps:
      - name: Checkout PR branch
        uses: actions/checkout@v4

      - name: Install uv
        uses: astral-sh/setup-uv@v7

      - name: Set deploy SHA
        run: echo "$" | cut -c1-7 > .deploy_sha

      - name: Deploy to staging
        env:
          CLOUD_TOKEN: $
          CLOUD_APP_ID: $
        run: # your deploy command here
      
      # ...

My code also needed to account for that. So first I created a function in my FastAPI app to grab the first few characters of the SHA from either the environment variable or the .deploy_sha file. I also set a fall back to dev.

# Deploy SHA for cache busting - check env var first, then file, fallback to "dev"
def get_deploy_sha():
    """Get deploy SHA from environment or .deploy_sha file."""
    sha = os.getenv("DEPLOY_SHA")
    if sha:
        return sha[:7]
    
    # Try reading from file (created during CI/CD deploy)
    try:
        with open(".deploy_sha", "r") as f:
            return f.read().strip()
    except FileNotFoundError:
        return "dev"

# Automatically make the deploy_sha available in all templates
templates.env.globals["deploy_sha"] = get_deploy_sha()

The environment variable is used in production which normally doesn’t change unless I see some weird caching I’m not expecting to, whereas while developing locally the fallback takes action and in staging we use the file.

Finally the HTML template looks like this:

<link rel="stylesheet" href="/static/css/base.css?v=">

Since we pass the deploy_sha automatically as part of the globals variables for templates, any page will have the information they need when the application is being built.

3. Get a comment

Finally, I wanted to get a comment I can see both:

That the deployment is live
The hash I should look for in case I notice some discrepancies between what I’m seeing and the deployment

To this I added a final step to the deploy-staging job with the following code:

# ...
jobs:
  test:
    # ...

  deploy-staging:
    # ...
    steps:
      # ...

      - name: Comment staging URL on PR
        uses: actions/github-script@v7
        with:
          script: |
            const sha = '$'.substring(0, 7);
            const marker = '<!-- staging-deploy -->';
            const body = `${marker}\n🚀 **Staging deploy complete**\n\nPreview: $\n\nCommit: \`${sha}\``;
            
            // Find existing comment
            const { data: comments } = await github.rest.issues.listComments({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
            });
            
            const existing = comments.find(c => c.body.includes(marker));
            
            if (existing) {
              await github.rest.issues.updateComment({
                owner: context.repo.owner,
                repo: context.repo.repo,
                comment_id: existing.id,
                body: body,
              });
            } else {
              await github.rest.issues.createComment({
                owner: context.repo.owner,
                repo: context.repo.repo,
                issue_number: context.issue.number,
                body: body,
              });
            }

Since I also didn’t want every new commit to generate a new comment, I used an HTML comment to mark the message:

const marker = '<!-- staging-deploy -->';

Since comments render Markdown the HTML shows up in edit mode but gets hidden when displayed.

And this is what that looks like as the final step of the deploy-staging is completed:

Trade-offs of this approach

This gave me full control over which pull request is staged and my staging represents “currently under review” making it easier for me to even QA the changes myself.

The only downside from this approach is that I can’t have multiple ephemeral per-pull-request environments since I can only make one PR deployment at a time but that works well for my development workflow.

The goal is clarity and control, not maximum automation.

Conclusion

Versioned static assets and label-gated deploys solved my staging cache problem. Now CSS files get a git SHA in the URL, GitHub Actions handles deployments when I apply the preview label, and I always know which version is live. No cache invalidation needed.

AI-powered software development flow: Lessons from shipping My Yarn Stash

Tue, 03 Feb 2026 05:00:00 +0000

When I started building My Yarn Stash, I wasn’t trying to prove AI could build an app for me.

I wanted to answer a practical question:

What actually changes when you treat AI tools as long-term collaborators across planning, implementation, and design?

Not with demos or toy examples, but with a real product that has users, persistent data, billing, authentication, and migrations—all the unglamorous constraints that come with shipping software meant to stick around.

What follows is a breakdown of how AI fit into each phase, where it helped, where it failed, and what I learned or was reminded about tool boundaries by building something real.

The day the AI deleted my database

Early in the project, I asked a coding agent to help with a schema change. It confidently suggested:

rm yarn.db
# Then recreate with new schema

And I let it.

Gone. All the test data I’d been building up. Hours of manual entry to stress-test edge cases. Deleted in a single command because the AI treated the database like a throwaway artifact.

The AI didn’t behave incorrectly. It did exactly what made sense if you assume databases are ephemeral. The problem was that I hadn’t established guardrails.

That moment reminded me to both pay more attention and adjust how I collaborated with AI tools. I needed to be very clear about constraints.

Later I added rules to my copilot instructions:

NEVER delete database files
ALWAYS run migrations instead
Before any destructive operation, run backups first

And went on to recreate my database. The AI didn’t change its behaviour. I changed mine.

This became the pattern for the entire project: AI amplified my clarity and punished my ambiguity and lack of attention.

The database deletion reminded me of something fundamental: vague instructions produce unpredictable results. That lesson shaped how I approached every other phase of this project moving forward.

Separate conversations, separate contexts

After the database incident, I knew I needed better constraint management. That started with how I structured conversations.

I treated ChatGPT like a colleague I’d grab for specific discussions.

Each feature got its own conversation thread:

One for billing and entitlements
One for the AI extraction flow
One for soft-delete patterns
One for launch strategy

This wasn’t about organization. It was about context management.

graph TB
    %% Styles
    classDef orange fill:#FEF3E6,stroke:#F59E0B,stroke-width:2px,color:#7C2D12;
    classDef blue fill:#E8EEF6,stroke:#3C87C9,stroke-width:2px,color:#0f172a;
    classDef green fill:#E6F4F1,stroke:#00B478,stroke-width:2px,color:#064E3B;
    classDef purple fill:#ECE7F8,stroke:#9C8AD9,stroke-width:2px,color:#0f172a;
    classDef note fill:#F3F4F6,stroke:#6B7280,stroke-dasharray: 5 5,color:#111827;

    %% Central collaborator
    AI[ChatGPT
as collaborator]:::purple

    %% Separate conversations
    Billing[Billing & entitlements
conversation]:::blue
    Extraction[AI extraction flow
conversation]:::blue
    SoftDelete[Soft-delete patterns
conversation]:::blue
    Launch[Launch strategy
conversation]:::blue

    %% Separate outputs
    BillingOut[billing.md]:::green
    ExtractionOut[extraction.md]:::green
    SoftDeleteOut[soft-delete.md]:::green
    LaunchOut[launch.md]:::green

    %% Connections (no cross-links!)
    AI --> Billing
    AI --> Extraction
    AI --> SoftDelete
    AI --> Launch

    Billing --> BillingOut
    Extraction --> ExtractionOut
    SoftDelete --> SoftDeleteOut
    Launch --> LaunchOut

    %% Note
    Note[Each conversation has a single purpose and is bounded context]:::note
    Note -.-> AI

When everything lives in one chat, the AI starts to get slow and confused, that’s when constant “summarizing history” increase time to answers, so as an engineer leveraging AI, you have to dutifully manage the context window. A billing conversation shouldn’t bleed into UI discussions. Implementation details shouldn’t pollute planning threads.

Separate chats forced clarity. Each conversation had a single purpose, which made it easier to:

Stay focused on one problem
Evaluate outputs against specific goals
Make decisions without noise

What those conversations actually looked like

Branding: From vague to concrete

I started with “I want it to feel cozy and calm.” Through discussion, we identified edge cases I hadn’t considered:

Text baked into images would need rework every time pricing changed
Realistic imagery would read as generic stock photos
“Organizing” visuals imply judgment. Better to frame as “inventory tracking”
Gradients applied inconsistently would create visual noise

The conversation forced specificity. By the end, I had constraints like “no text in images” and “single vertical gradient system” that my coding agent could implement reliably.

Account page: Surfacing failure modes

When planning the account page, ChatGPT helped identify non-obvious problems:

Timezone drift: Automatically updating timezone when users travel would silently change project dates. Solution: only update on explicit user action.
Empty state guilt: Showing “0 finished projects” or prompting users to “finish your first project” creates pressure. Solution: gentle empty state with no call to action.

These weren’t implementation details. They were experience risks that would erode trust if missed.

Launch strategy: Reframing the goal

I initially thought about launch as a visibility event: where to post, how to announce.

The discussion reframed it as a state change: from “only I use this” to “other people can use this safely.”

That shifted focus from:

“How many people see this?”

To:

“What breaks when the first real users arrive?”
“Is this experience internally consistent?”
“Where can people get confused or succeed quickly?”

I deprioritized announcements and spent more time on onboarding clarity instead.

Every useful insight got distilled into markdown. Feature specs, constraints, architectural decisions: all rewritten in my own words with the help of ChatGPT, structured for clarity, stored alongside the code.

This forced two things:

I had to actually understand the decision
The output became durable and reviewable

Stack decisions: What I chose vs. what I asked about

With clear conversation boundaries established, I could make better stack decisions. I came into the project with strong opinions about some parts of the stack and no opinion at all about others.

graph TB
    %% Styles
    classDef orange fill:#FEF3E6,stroke:#F59E0B,stroke-width:2px,color:#7C2D12;
    classDef blue fill:#E8EEF6,stroke:#3C87C9,stroke-width:2px,color:#0f172a;
    classDef green fill:#E6F4F1,stroke:#00B478,stroke-width:2px,color:#064E3B;
    classDef purple fill:#ECE7F8,stroke:#9C8AD9,stroke-width:2px,color:#0f172a;

    %% end
    subgraph ME ["Stack I chose"]
            Auth0[Auth0 for auth]:::blue
            FastAPI[FastAPI]:::blue
            Supabase[Supabase for database + storage]:::blue
            Frontend[Vanilla JavaScript and CSS]:::blue
            Emails[Resend]:::blue
            AIproviders[Replicate]:::blue
        end

        %% Subgraph: What AI helped evaluate
        subgraph AI ["AI evaluated"]
            Payments[Payment gateway]:::orange
            Deploy[Deployment platform]:::orange
        end
    %% Relationship between the two
    ME:::green
    AI:::purple

What I decided before asking AI:

Auth0 for authentication (familiar, reliable, scalable)
FastAPI as the web framework (Python, async, good docs, also familiar and with great Auth0 support)
Supabase for database and storage (Postgres with good tooling and prod database at 0 cost)
Vanilla JavaScript and handwritten CSS to start instead of a framework (less abstraction, easier to reason about with AI and for me to follow along)
Resend for emailing users: a welcome email for the users and another to notify myself when new user signed up
Replicate: to provide AI features like the label extraction information

These choices weren’t about AI compatibility. They were about reducing cognitive load and keeping a codebase I could jump in without the help of AI if needed.

What I asked AI to help evaluate:

Payment gateway: I had no strong opinion. We discussed options and landed on Polar for simplicity and developer experience.
Deployment platform: I wanted something low-cost that I already understood. Heroku fit both criteria.

The pattern here matters: I brought constraints and context to the conversation instead of asking “what should I use?” in a vacuum.

AI didn’t tell me what to build with. It helped me think through trade-offs for the decisions I hadn’t made yet.

Learning which model does what well

Stack decisions settled, the next challenge was figuring out which AI tool to use when. Understanding model strengths came from repeated experience across different contexts.

I didn’t use one AI tool for everything. That was deliberate. Through building, I found a flow that worked for me:

flowchart TB
    %% Styles (modern, readable, low contrast)
    classDef blue fill:#E8EEF6,stroke:#3C87C9,stroke-width:2px,color:#0f172a;
    classDef decision fill:#F3F4F6,stroke:#6B7280,stroke-width:2px,color:#111827;
    classDef simple fill:#E6F4F1,stroke:#00B478,stroke-width:2px,color:#064E3B;
    classDef complex fill:#FEF3E6,stroke:#F59E0B,stroke-width:2px,color:#7C2D12;
    style one fill:#E8E8E8,stroke:#CCCCCC,stroke-width:2px;
    style two fill:#E8E8E8,stroke:#CCCCCC,stroke-width:2px;

    %% Nodes
    A[Chat with ChatGPT:
Map out the work
and generate markdown]:::blue
    B[Commit markdown
in GitHub Mobile app]:::blue

    D[Open GitHub issue
Assign Copilot]:::simple
    H{PR stuck?}:::decision
    I[Download branch locally
and unblock with Opus
in Agent mode]:::simple

    F[Review markdown 
locally
with Haiku 
in Plan mode]:::complex
    G[Implement with Opus
in Agent mode]:::complex

    E[Review and 
merge PRs]:::blue


    EE[No]:::decision
    II[Yes]:::decision

    subgraph one ["`For simple tasks`"]
        direction TB
        D --> H
        H --> EE
        H --> II --> I
        %% Z@{ shape: brace-l, label: "identifies the tool to use,
packages user query in
the format the server
understands"}
    end

    subgraph two ["`For complex tasks`"]
        direction TB
        F --> G
    end
    %% Flow
    A --> B
    B --> one
    B --> two
    G --> E
    EE --> E
    I --> E

ChatGPT for planning and exploration

Most planning conversations happened in ChatGPT in the mobile app. I used it on my phone during downtime to think through features, identify edge cases, and explore design decisions before writing any code.

The mobile accessibility mattered. I could sketch out billing logic while having my coffee in the morning or map out future features during a commute. By the time I grabbed my computer to code, I’d already worked through the conceptual problems.

GitHub Copilot Agents for straightforward work

Well-defined low-complexity features and bugs went to GitHub issues and I would let Copilot handle implementation through PRs asynchronously by assigning Copilot to a given issue. It freed me up to work on more-complex and high value things while Copilot handled the implementation of the “no-brainer” tasks.

When agents got stuck online, I’d download the code and ask Claude Opus to step in.

VS Code Copilot for local development

I used VS Code with Copilot in different modes and with models depending on the work:

Claude Haiku:

Mostly in Plan mode;
Quick iterations when following up on features locally;
Good for refactoring and adjusting implementation details that didn’t require more scope other than one file

Claude Opus:

Mostly in Agent mode;
Complex situations with many moving pieces
Used when precision and accuracy mattered more than speed

No matter the model though, they were always constrained by explicit conventions in copilot-instructions.md. The lesson wasn’t “use the best model.” It was knowing not only when to switch models and modes but also why switching should happen.

That judgment is a skill. AI tools don’t remove it.

The database deletion happened because I let my guard down. I got comfortable with AI-assisted coding and stopped questioning the suggestions. It was a good reminder that different contexts need different constraints. By this phase of the project, I’d learned to match tool capabilities to task requirements.

Functional first, pretty later (because I’m not a designer)

With implementation flowing more smoothly, I turned to design. This required a different kind of clarity.

I deliberately delayed visual design work. Not because of anything AI-related, but because CSS and JavaScript are not my strong suit.

I focused on making things functional first: flows, data models, interactions. Once those settled, I could tackle design from a more stable foundation. It didn’t look ugly but it clearly wasn’t beautiful:

My first exploration with Stitch, Google’s Gemini-based tool that transforms text descriptions into UI designs, showed me how powerful it was. I dropped the link of the working app and asked for a redesign. It made something pretty, but it didn’t look like my product.

So I used ChatGPT to put together the branding guidelines: tone, colour direction, what feelings I wanted the UI to convey. Once I had that document written down, I went back to Stitch with:

Screenshots of the functional app
The branding document
Specific constraints like “redesign this following the brand guidelines”

The result you see below:

That combination worked. The design felt right because I’d done the thinking first. And did I mention it now supports dark mode as well?

The lesson: Tools work better when you’ve already established intent. Just like the database needed constraints, design tools needed direction.

What this experience taught me about building with AI

Going through all these steps I noticed a few patterns that go beyond individual tool choices. These are a few things I’m carrying forward:

1. AI doesn’t replace judgment. It makes judgment more important

The database deletion wasn’t an AI failure. It was a clarity failure. Once I added explicit constraints, the tools became more reliable.

2. Context boundaries matter

Separate conversations for separate concerns reduced drift and forced focus.

3. Model switching is a learned skill

Understanding when to use a lightweight model versus a heavy one came from repeated friction, not documentation.

4. Design still requires taste

AI can accelerate iteration, but you need to know what you’re aiming for. “Make it pretty” produces generic results. “Make it feel cozy and trustworthy” with examples gives you something to evaluate.

5. Shipping something real teaches more than demos ever could

Most AI tool examples live in a world where you can always start over. Production software doesn’t. That constraint forced honesty about where AI helps and where it doesn’t.

What this means for learning AI tools

I always believed developers do better when they learn the limitations of the tools they use when building software. Specially since development is no-longer my day job, this project became an outlet for experiment and trying new tools and it helped shape how I evaluate and talk about AI tools.

Demos have their place in my world, but nothing beats the actual experience of building something and learn by doing.

Building My Yarn Stash gave me a even clearer sense of where AI accelerates work and where it introduces risk. Not from reading about it, but from hitting the boundaries myself.

If you’re trying to find your footing with AI tools: build something real. Solve a problem you face often, try the new tools and find the flow that works for you.

Step away for a moment from the tutorials and courses and build your own project free of the constraints instructors purposely impose in order to teach and give students a good experience. Something with users, data you can’t lose, and decisions that compound over time.

You’ll learn more from one broken migration than from a hundred perfect prompts.

Field Notes: Hacktoberfest 2025, Week 5

Sat, 15 Nov 2025 05:00:00 +0000

After GitHub Universe, recovering from a nasty cold, and a lot of work, I know I’m a bit late but here it goes: Final week of Hacktoberfest 2025 report!

GitFichas

After the “big slow down”, we actually saw some more engagement by the community with 5 pull requests in Hacktoberfest’s last week:

5 PRs by the community
- 3 merged
- 2 open

I, on the other hand, got Copilot to work on a few issues 👀: 35 pull requests by AI, all merged. This meant great progress was made and that huge bump in the last days of October in the burn up chart below.

The gap between closed and open issues is still there. I still plan to finish migrating the hand-drawn cards to mermaid before the end of the year but I also want to reach the 100 cards published number, let’s see how it goes.

Here’s the distribution of pull requests worked on in the last week of Hacktoberfest:

Looking at the pull requests for the whole month of October, you can see that shift between a lot of translation pull requests in the beginning of the month to more migrations at the end of October in the chart below:

As far as issues go, the distribution is similar. Some PRs closed more than one issue and some PRs had no issues attached to them, so the numbers vary a bit between merged PRs and closed issues, but the distribution is similar on both:

Other projects

I went back to those PRs I left hanging and worked on them. And now I’m off to work on other stuff, especially some content I want to work on through the end of this year beginning of next one.

With this report we close a successful Hacktoberfest 2025. I was not expecting so many people interested in contributing to GitFichas, and I was very happy to review every pull request that came through.

I hope the folks contributing also had an amazing time as I did.

Happy hacking and see you next year 🎃

Hacktoberfest 2025: Diário de Campo, Semana 5

Sat, 15 Nov 2025 04:00:00 +0000

Depois do GitHub Universe, de me recuperar de uma gripe horrível, e de muito trabalho, eu sei que estou meio atrasada mas aqui vai: relatório da última semana da Hacktoberfest 2025!

GitFichas

Depois da “grande desaceleração”, a comunidade voltou a se engajar mais com 5 pull requests na última semana da Hacktoberfest:

5 PRs da comunidade
- 3 mergeados
- 2 abertos

Já eu, consegui colocar o Copilot pra trabalhar em algumas issues 👀: 35 pull requests feitos por IA, todos mergeados. Isso resultou num progresso incrível e naquele grande pico no final de outubro que você vê no gráfico burnup abaixo.

A diferença entre issues fechadas e abertas ainda continua lá. Minha meta ainda é terminar de migrar as fichas desenhadas à mão para mermaid antes do final do ano, mas também quero chegar nas 100 fichas publicadas, vamos ver o que vai dar.

Assim ficou a distribuição dos pull requests na última semana da Hacktoberfest:

Olhando pro mês de outubro como um todo, dá pra ver bem aquela mudança de foco: no começo do mês rolaram muitos pull requests de tradução, e no final foram mais migrações, como mostra o gráfico abaixo:

Sobre as issues, o padrão é parecido. Alguns PRs resolveram várias issues de uma vez e outros não estavam associados a nenhuma issue específica, então os números ficaram um pouco diferentes entre PRs mergeados e issues fechadas, mas a tendência geral é a mesma:

Outros projetos

Voltei naqueles PRs que tinha deixado pra lá e consegui finalizar eles. Agora vou focar em outras coisas, principalmente uns conteúdos que quero terminar durante o final desse ano e começo do ano novo.

E com esse relatório a gente encerra uma Hacktoberfest 2025 na minha opinião super bem-sucedida. Não imaginava que tanta gente ia se interessar em contribuir pro GitFichas, e adorei revisar cada pull request que apareceu por lá.

Espero que quem contribuiu também tenha curtido esse momento tanto quanto eu.

Espero te ver ano que vem para Hacktoberfest 2026 🎃

Field Notes: Hacktoberfest 2025, Week 4

Sun, 26 Oct 2025 05:00:00 +0000

We are so close to the end of Hacktoberfest I can almost smell it. With one week left to go let’s take a look into how last week went.

GitFichas

After the “big slow down”, this week continued the trend of lower amount of pull requests received with only 8 pull requests for last week:

8 PRs by the community
- 7 merged
- 1 closed

I didn’t make any pull requests to GitFichas as I was working on a big pull request for work I’ll love to share on next week’s report.

On other news, this weekend was the first time that GitFichas had no PRs open since the beginning of Hacktoberfest and to be honest this worked out great for me as I was spending most of my Saturday preparing to travel to GitHub Universe.

The gap between closed and open issues is still there, from my side, since my plan is to finish migrating the hand-drawn cards to mermaid before the end of the year, I plan to start tackling some of the open migration issues with the help of Copilot:

Migrate all English 🇺🇸 cards to Mermaid: 27 issues to go
Migrate all Portuguese 🇧🇷 cards to mermaid: 36 issues to go

Contributor Badges

Hacktoberfest is not over yet! You can still make your contributions and earn at least the 4 of the 6 badge levels:

level 0 is for registering to Hacktoberfest
levels 1 through 4 are for making the 4 pull requests while contributing to open source
level 5 is the supercontributor badge you get while completing 6 pull requests.

Level 0	Level 1
Level 2	Level 3
Level 4	Supercontributor

I also got the Plant a tree and 1 Badge Club, the first is for the tree planted when you get the shirt for completing 6 PRs, and the second is for anyone that has gotten a Hacktoberfest badge since 2022:

Plant a tree

1 Badge Club

I know this was a short one but that’s a wrap for week 4! See you soon for the final report on Hacktoberfest 2025. 🎃

Hacktoberfest 2025: Diário de Campo, Semana 4

Sun, 26 Oct 2025 04:00:00 +0000

Estamos tão perto do final da Hacktoberfest que já dá pra sentir o cheiro. Com menos de uma semana para o fim da Hacktoberfest, vamos dar uma olhada em como foi a semana passada.

GitFichas

Após a “grande desaceleração”, essa semana continuou a tendência com uma menor quantidade de pull requests recebidos: apenas 8 pull requests foram recebidos nessa semana que passou.

8 PRs da comunidade:
- 7 mergeados
- 1 fechado

Eu não fiz nenhum pull request para o GitFichas pois estava trabalhando num pull request gigante para o trabalho que pretendo compartilhar mais sobre em breve.

Por outro lado, este final de semana foi a primeira vez que o GitFichas não teve PRs abertos desde o começo da Hacktoberfest e para ser honesta, pra mim isso funcionou super bem, já que eu passei a maior parte do meu sábado me preparando para viajar para o GitHub Universe.

A lacuna entre issues fechadas e abertas ainda está lá, mas meu plano é terminar de migrar as fichas desenhadas à mão para mermaid antes do final do ano. Vou focar em algumas das issues de migração abertas com a ajuda do Copilot:

Migrar todos as fichas em inglês 🇺🇸 para Mermaid: 27 issues restantes
Migrar todos as fichas em português 🇧🇷 para mermaid: 36 issues restantes

Medalhas de contribuição

Vale salientar que a Hacktoberfest ainda não acabou! Você ainda pode fazer suas contribuições e conquistar 4 dos 6 níveis de medalhas:

nível 0 é por se registrar no Hacktoberfest
níveis 1 a 4 são para fazer os 4 pull requests contribuindo para open source
nível 5 é a medalha para pessoas supercontribuidoras que você ganha ao completar 6 pull requests.

Nível 0	Nível 1
Nível 2	Nível 3
Nível 4	Supercontribuidor

Também consegui as medalhas Plant a tree e 1 Badge Club, a primeira é pela árvore plantada quando você ganha a camiseta por completar 6 PRs, e a segunda é para qualquer pessoa que já tenha conseguido uma medalha Hacktoberfest desde 2022:

Plant a tree

1 Badge Club

Esse foi um relatório menorzinho que os dois ultimos, mas por hoje é só! Te vejo em breve para o relatório final do Hacktoberfest 2025. 🎃

Field Notes: Hacktoberfest 2025, Week 3

Mon, 20 Oct 2025 04:00:00 +0000

We crossed over the halfway point of Hacktoberfest 2025 and here is what happened in my little corner of the open source world. In this series we overview some stats for contributions I received and made over this month. This week, like the last, I mostly focused on GitFichas due to limited availability, but I also implemented some new features on my blog so let’s go into the contributions.

GitFichas

Like always, third week of Hacktoberfest symbolizes the big “slow down”, where the volume from contributions from the first few weeks dip after many folks complete their 4 or 6 pull requests. So after the high from last week, this week we had 30 pull requests:

23 PRs by the community
- 17 merged
- 5 closed
- 1 open

Interestingly enough I tried having copilot draft a PR and it actually, did a good job. I also merged 6 PRs myself which were 2 for documentation, 2 for corrections, and 2 for improvements.

The most exciting part for the week for me at least, was that on October 15th we reached the mark of over 100 issues closed. Which marks the milestone of more issues closed than open for GitFichas. 🎉

I also worked on improving descriptions for some issues that were open a long time ago.

As far as inviting people to contributing to your project, it is fundamental that you have both good descriptions and good titles since in the list of issues every contributor sees mostly the titles and tags. I did some automating to help make this easier on me and help me with maintenance tasks but I’ll write about that in a separate post later. 👀

Still on the issues subject this is the burn up chart since September 1st there’s still a gap but the trend is clear: the opening of issues is slowing down, and the closing of them is bridging the gap.

One final thing: someone decided to implement a search bar on GitFichas, there wasn’t an issue for this but it is something I definitely thought about having on the website.

A search function is not a tiny thing, especially if you don’t have a database for indexing the content. Nonetheless someone implemented it and I do believe it will help others find cards more easily! So another big win of open source! 🎉

The blog

On the blog side, I worked on three main things:

Series of posts
Subtitles for posts
New covers

Let’s dive in.

Series in a blog

Two weeks ago I implemented a series widget so anyone reading the posts can quickly jump to other posts in the same collection much like the “Related Articles” or “Recent Articles” widgets I already have.

Until Saturday it was impossible to link to a series, so I set on to fix that and create a way to link to a series so I could refer to series without linking out to an specific blog post.

To get series pages, I could think of a few ways to implement the behaviour:

Separate series into collections: I’ve created collections before, but in this case collections is not a great solution as it would separate the posts away from the rest of posts;
Manually create a page for each series: not scalable, that would create a bunch of other files for me to maintain;
Plugins: hear me out, plugins felt like the right way to go given the fact that I could write a ruby script to automatically generate pages but you can’t use custom plugins on GitHub Pages.

After some consideration, and talking to Copilot, I felt confident that writing a custom plugin was the way to go but since my blog was served through GitHub Pages I needed to find a different way to deploy the blog, and I was not about to commit the built site to GitHub.

Since I already use Netlify to preview the pull requests for both the blog and GitFichas, it felt like a natural step to migrate production deployment to Netlify as well. So I’d like to inform you all ladies and gentlemen, that I graduated from serving the production site from GitHub Pages to Netlify. I feel so much like a grown up dev. 🤣

With Copilot’s help I implemented the plugin and successfully migrated prod to Netlify, I’ll probably write a post on this later.

Here are some of the series:

Git Pro Tips: All about Git covering: conflicts, branches, rebase, and GitHub workflows.
Hacktoberfest 2025 Weekly: Weekly updates about Hacktoberfest 2025 on GitFichas and other projects.
MCP Mastery: All you need to know about Model Context Protocol (MCP).

These and all others are available in the series page.

Subtitles for posts

Another thing I always wanted to do was to have subtitles on some posts. This weekend I figured out it was time, and so after some Liquid magic and some CSS adjustments I’m happy to inform that I can now have posts with title and subtitles.

Just in time too for my fairy tale post.

New covers

If you are asking yourself “what fairy tale post?” well I also started to get a bit annoyed at the fact the covers in the blog were too repetitive lately since the last 14 posts had all the same cover.

So it was time to create a few more covers and put them to good use, I tell the story of it here in this other post, which I strongly encourage you to read because it is in the form of a fairy tale, but here’s the TL;DR: I noticed the repeated covers, opened an issue, and had copilot do the code adjustments.

Super contributor status

Finally this week I updated my Holopin profile to show off my Hacktoberfest “supercontributor” badge.

And shirt is already here too!

I prefer shirts with dark colors but this one feels special, since only 10,000 will be given away and this one has GitFichas written all over it. 😊

That’s a wrap for week 3! See you next week for Hacktoberfest 2025 week 4 report. 👻

Hacktoberfest 2025: Diário de Campo, Semana 3

Mon, 20 Oct 2025 04:00:00 +0000

Passamos da metade da Hacktoberfest 2025 e bora falar do que aconteceu por aqui no meu cantinho do mundo open source.

Nessa semana, mais uma vez com tempo limitado, foquei no GitFichas mas também implementei algumas funcionalidades novas no meu blog, então bora falar de contribuições.

GitFichas

Como sempre, a terceira semana do Hacktoberfest simboliza a grande “desaceleração”, onde o volume de contribuições das primeiras semanas diminui já que muitas pessoas já completaram seus 4 ou 6 pull requests. Então depois do pico da semana passada, esta semana tivemos 30 pull requests:

23 PRs da comunidade:
- 17 merged
- 5 fechados
- 1 aberto

Curiosamente eu coloquei o Copilot escrever um PR e ele até que fez um bom trabalho. Eu também fiz merge de 6 PRs meus: 2 com documentação, 2 com correções, e 2 com melhorias.

A parte mais empolgante da semana para mim pelo menos, foi que no dia 15 de outubro chegamos à marca de mais de 100 issues fechadas. O que marca o momento em que temos mais issues fechadas do que abertas no GitFichas. 🎉

Eu também trabalhei em melhorar descrições para algumas issues que estavam abertas há muito tempo.

Falando de convidar pessoas para contribuir com o seu projeto, é fundamental que você tenha tanto boas descrições quanto bons títulos, já que na lista de issues pessoas vêem principalmente os títulos e tags de cada issue.

Fiz também algumas automações para identificar essas issues que precisavam de ajuste mais facilmente e outras automações para me ajudar com tarefas de manutenção, mas vou escrever sobre isso em um post separado mais pra frente. 👀

Ainda no assunto das issues, aqui em baixo temos o gráfico burn up desde 1º de setembro ainda há um vão, mas a tendência é clara: a abertura de issues está desacelerando, e o fechamento delas está quase fechando o vão.

Uma última coisa: alguém decidiu implementar uma barra de pesquisa no GitFichas, não havia uma issue para isso mas é algo que eu definitivamente pensei em ter no site.

Uma função de busca não é uma coisa pequena, especialmente se você não tem um banco de dados para indexar o conteúdo. Mesmo assim alguém implementou uma forma de pesquisar fichas e eu acredito que vai ajudar outras pessoas a encontrarem fichas mais facilmente! Mais uma grande vitória do open source! 🎉

O blog

No lado do blog, trabalhei principalmente em três coisas:

Séries de posts
Subtítulos para posts
Novas capas

Bora lá.

Séries de posts no blog

Duas semanas atrás implementei um widget de séries para que alguém lendo os posts possa pular rapidamente para outros posts na mesma coleção, muito parecido com os widgets de “Artigos Relacionados” ou de “Artigos Recentes” que eu já tenho.

Até sábado era impossível linkar para uma série, então esse final de semana eu disse que estava na hora de corrigir isso. Principalmente para que eu pudesse compartilhar uma série sem linkar para um post específico que fizesse parte da série.

Eu queria ter uma página por série, e eu consegui pensar em algumas formas de implementar isso:

Separar séries em collections: Já criei coleções antes, mas neste caso collections não é uma boa solução pois separaria os posts do resto dos posts;
Criar manualmente uma página para cada série: não escalável, isso criaria um monte de outros arquivos para eu manter fora que toda nova série eu precisaria uma página nova, apenas não;
Plugins: veja bem, plugins pareciam o caminho certo a seguir dado o fato de que eu poderia escrever um script ruby para gerar páginas automaticamente, mas se o seu site é deployado pelo GitHub Pages, tenho más notícias: não se pode usar custom plugins no GitHub Pages.

Depois de algumas considerações, e conversando com o Copilot, me senti confiante de que escrever um plugin customizado era o caminho certo, mas como meu blog era servido através do GitHub Pages eu precisava encontrar uma forma diferente de fazer o deploy do blog, e eu não estava disposta a fazer commit do site buildado no GitHub.

Como eu já uso Netlify para preview dos pull requests tanto do blog quanto do GitFichas, pareceu um passo natural migrar o deployment de produção para o Netlify também. Então gostaria de informar vocês, senhoras e senhores, que agora eu sou uma dev que saiu do GitHub Pages para o Netlify para servir prod do meu site e eu me sinto como uma dev premium. 🤣

Com a ajuda do Copilot eu implementei o plugin e migrei com sucesso prod para Netlify, provavelmente vou escrever um post sobre isso em breve.

Aqui estão algumas das séries:

Dicas de Git: Tudo sobre Git cobrindo: conflitos, branches, rebase e fluxos GitHub.
Hacktoberfest 2025: Atualizações semanais sobre Hacktoberfest 2025 no GitFichas e outros projetos.
Dominando MCP: Tudo o que você precisa saber sobre Model Context Protocol (MCP).

Essas e todas as outras estão disponíveis na página de séries.

Subtítulos para posts

Outra coisa que sempre quis fazer: ter subtítulos em alguns posts. Este fim de semana decidi que era hora, e então depois de um pouco de magia Liquid e alguns ajustes CSS estou feliz em informar que agora posso ter posts com título e subtítulos.

Bem na hora para o meu post com um conto de fadas.

Novas capas

Se você está se perguntando “que post de conto de fadas?” bem, eu também comecei a ficar um pouco incomodada com o fato de que as capas no blog estavam muito repetitivas ultimamente, já que os últimos 14 posts tinham todos a mesma capa.

Então chegou a hora de criar algumas capas a mais e colocá-las em bom uso, eu conto a história aqui neste outro post, que eu encorajo fortemente você a ler porque está na forma de um conto de fadas, mas aqui está o TL;DR: notei as capas repetidas, abri uma issue, fiz o copilot fazer os ajustes de código e agora temos novas capas no ar.

Medalha de supercontributor

Finalmente esta semana atualizei meu perfil Holopin para mostrar minha badge de “supercontribuidora” do Hacktoberfest.

E a camiseta já chegou também!

Prefiro camisetas com cores escuras, mas tem um toque especial, já que apenas 10.000 serão distribuídas e essa em particular foi conquistada a base do GitFichas. 😊

Por hoje é só! Te vejo no próximo relatório semanal do Hacktoberfest 2025. 👻

The writer and the bot

Sun, 19 Oct 2025 05:00:00 +0000

Once upon a Friday morning, coffee in hand, the writer peered into the blog and found a tiny bug hiding between the posts.

Between mixing posts and capturing PRs, a bug had been created without the writer realizing it.

But this is not the tale of that bug, this tale is about a change made after the bug was dealt with when the writer and her faithful helper bot started their quest…

Something woke up the ick monster

For the last eight or so posts, the writer had forgotten to set a variable that routes articles to their language-specific pages.

This bug wasn’t huge, but it still annoyed the writer just the same: new posts appeared on the main mixed-language feed, but not on the English or Portuguese pages.

Noticing the issue the writer quickly cast away this tiny bug with the GitHub Mobile app and an equally tiny PR.

While reviewing the preview for the pull request, something else felt off. The cover images had started to feel a bit too generic for what the writer have been publishing recently around Preptember and Hacktoberfest.

All posts said “miscellaneous” and the result was that the writer found a baby ick for the covers she used and loved for such a long time.

The ick is a terrible monster that makes every writer (and developer) want to change their website. If left alone, the ick always grows into a terrible monster that only gets defeated by a complete website overhaul.

As the coffee started to wake the writer’s brain, an idea popped into her head:

it is time to brew a new cover image!

The writer normally cycles between a few covers, with the color scheme from the use on the blog and a cover saying “open source” felt descriptive and better aligned with the last few posts written.

Or so the writer thought…

Setting GitHub Copilot in motion

After creating, exporting the new cover, and uploading it to the CDN, the writer had all the ingredients to brew a new spell.

The writer opened an issue with the ingredients and the instructions to defeat the ick: Change cover image on open source related posts to the new cover image. And gave everything to the trusty robot by assigning it to GitHub Copilot.

When you assign an issue to your trusty robot, it will start to work right away creating a draft PR, saying that it is going to work on the issue and that it will update the PR while it progresses.

A few minutes later, Copilot updated the PR with a checklist of the steps it would take to make the proposed changes. It read like a neat spell scroll, with steps listed line by line.

The writer was actually surprised by finding out that 27 posts about open source existed. So much so that the writer thought the bot made a mistake and gathered wrong posts to update the cover.

Little did the writer know that the bot found posts from a long time ago…

Work done but minds changed

With the work actually done the little robot updated the pull request, put together an overview of the changes, and called the writer in for a review of the spell before it could be cast to production.

That’s how the writer confirmed that actually 27 posts were about open source:

8 about Preptember
4 about GitFichas
2 about pull requests
And incredible 13 about Hacktoberfest

The writer could feel the spell working and got really excited to see the preview of the posts with the new cover!

But the excitement didn’t last long…

The ick attacks again

When the page loaded the writer’s happiness went a little bit like this:

YAY NEW COVER… wait…

awww every single post open source now 😮‍💨

at least the new cover looks great ¯\_(ツ)_/¯

The writer quickly realized that this baby ick was strong and ready to fight.

Fearing the ick would get out of control pretty soon, the writer created two new covers to add to the spell: one for Hacktoberfest and one for Preptember posts.

Without delay the two new covers were added and with a comment the writer put the robot to work once again and waited.

Watching the work closely

To avoid anymore problems this time around, the writer also looked at the work while it was happening by casting the View session spell.

Viewing a session gives you a window to the little robot’s thinking. It let’s you observe all the steps the trusty robot is making while they are happening.

The happy ending

A few minutes later, Copilot finished implementing the changes and writer could look at preview again.

This time around the ick looked far away like it was weak. The variety helped keep the ick away. 😅

Sipping coffee, fixing bugs, and watching Copilot work gave the writer hope for an ick-less future. What started as a simple fix turned into a cover image overhaul.

By the time of the second cup of coffee, the pull request was merged and the spell had taken root. The Hacktoberfest posts now have their own cover, the Preptember ones have theirs, and the rest of the open source content has a fresh new look.

The ick is gone, replaced by covers that actually represent what the recent posts are about.

Sometimes the smallest changes make the biggest difference. Sometimes, all it takes is a cup of coffee, a robot assistant, and a little bit of magic.

And so, with a little bit of coffee and a helpful robot, the writer lived happily ever after, at least for now…

The end

Tiny side note: I find it extremely amusing when Copilot reacts with 👀 to the comments tagging it.

A escritora e o robô

Sun, 19 Oct 2025 04:00:00 +0000

Era uma vez numa manhã de sexta-feira que com café na mão a escritora olhou para o seu blog e encontrou um pequeno bug escondido entre os posts.

Entre misturar posts e capturar PRs, um bug havia sido criado sem a escritora perceber.

Mas este não é o conto daquele bug, este conto é sobre uma mudança feita depois que o bug foi resolvido quando a escritora e seu fiel ajudante robô começaram sua missão…

Algo acordou o monstro do rancinho

Nos últimos oito posts, a escritora havia esquecido de definir uma variável que direciona os artigos para suas páginas específicas de idioma.

Esse bug não era grande, mas mesmo assim incomodou a escritora: novos posts apareciam no feed principal que é bilíngue, mas não nas páginas espeçifícas de inglês ou de português.

Percebendo o problema, a escritora rapidamente se desfez desse pequeno bug com o GitHub Mobile e um PR igualmente pequeno.

Enquanto revisava a prévia do pull request, algo mais pareceu estranho. As imagens de capa tinham começado a parecer genéricas demais para o que a escritora vinha publicando recentemente sobre Preptember e Hacktoberfest.

Todos os posts diziam “variados” (miscellaneous) e o resultado foi que a escritora encontrou um bebê rancinho pelas capas que amou por tanto tempo.

O rancinho é um monstro terrível que faz toda escritora (e desenvolvedora) querer mudar seu site. Se deixado sozinho, o rancinho sempre cresce e se torna um monstro terrível que só é derrotado por uma refatoração completa do site.

Enquanto o café começava a despertar o cérebro da escritora, uma ideia surgiu:

é hora de preparar uma nova imagem de capa!

A escritora normalmente alterna entre algumas capas e uma capa dizendo “open source” parecia descritiva e mais alinhada com os últimos posts escritos.

Ou pelo menos, assim pensava a escritora…

Colocando o GitHub Copilot em ação

Depois de criar, exportar a nova capa e fazer upload para o CDN, a escritora tinha todos os ingredientes para preparar um novo feitiço.

A escritora abriu uma issue com os ingredientes e as instruções para derrotar o rancinho: Mudar a imagem de capa nos posts relacionados a open source para a nova imagem de capa. E deu tudo para o robô confiável atribuindo ao GitHub Copilot.

Quando você atribui uma issue ao seu robô, ele vai começar a trabalhar imediatamente criando um PR em rascunho, dizendo que vai trabalhar na issue e que vai atualizar o PR conforme progridir.

Alguns minutos depois, o Copilot atualizou o PR com uma lista de verificação dos passos que tomaria para fazer as mudanças propostas. Parecia um pergaminho dos antigos organizado, com os passos listados linha por linha.

A escritora ficou realmente surpresa ao descobrir que 27 posts sobre open source existiam. Tanto que a escritora pensou que o robô cometeu um erro e coletou os posts errados para atualizar a capa.

Mal sabia a escritora, que o robô encontrou posts de muito tempo atrás…

Trabalho feito mas mentes mudaram

Com o trabalho realmente feito, o pequeno robô atualizou o pull request, escreveu um relatório das mudanças, e chamou a escritora para uma revisão do feitiço antes que ele pudesse ser lançado para produção.

Foi assim que a escritora confirmou que realmente 27 posts eram sobre open source:

8 sobre Preptember
4 sobre GitFichas
2 sobre pull requests
E incríveis 13 sobre Hacktoberfest

A escritora podia sentir o feitiço funcionando e ficou muito animada para ver a prévia dos posts com a nova capa!

Mas a animação não durou muito…

O rancinho ataca novamente

Quando a página carregou, a felicidade da escritora durou pouco e foi mais ou menos assim:

AEEE CAPA NOVA… espera…

afff todo post agora é open source 😮‍💨

pelo menos a nova capa tá massa ¯\_(ツ)_/¯

A escritora rapidamente percebeu que esse bebê rancinho era forte e estava pronto para lutar.

Temendo que o rancinho saísse de controle muito em breve, a escritora criou duas novas capas para adicionar ao feitiço: uma para Hacktoberfest e uma para posts de Preptember.

Sem demora, as duas novas capas foram adicionadas e com um comentário a escritora colocou o robô para trabalhar mais uma vez.

Observando o trabalho de perto

Para evitar mais problemas desta vez, a escritora também olhou o trabalho enquanto estava acontecendo lançando o feitiço View session.

Visualizar uma sessão te dá uma janela para o pensamento do pequeno robô e te permite observar todos os passos que o robôzinho está fazendo enquanto eles estão acontecendo.

O final feliz

Alguns minutos depois, o Copilot terminou de implementar as mudanças e a escritora pôde olhar a prévia novamente.

Desta vez o rancinho parecia distante e fraco. A variedade ajuda a manter o rancinho longe. 😅

Tomando café, corrigindo bugs, e vendo o Copilot trabalhar deu à escritora esperança para um futuro sem rancinho.

Quando a xícara de café estava vazia, o pull request havia sido mergeado e o feitiço tinha criado raízes: Os posts do Hacktoberfest agora têm sua própria capa, os de Preptember têm a deles, e o resto do conteúdo de open source tem uma nova cara.

O rancinho se foi, substituído por capas que realmente representam sobre o que os posts recentes falam.

Às vezes as menores mudanças fazem a maior diferença. Às vezes, tudo que é preciso é uma xícara de café, um assistente robô, e um pouco de magia.

E assim, com uma xícara de café e um robô prestativo, a escritora viveu feliz para sempre. Bem pelo menos por enquanto…

Fim

Pequena observação: Acho extremamente divertido quando o Copilot reage com 👀 aos comentários que marcam ele.

Contribute to GitFichas

Tue, 14 Oct 2025 04:00:00 +0000

Looking for an open source project to contribute to? Let me tell you about GitFichas, a visual study cards project about Git in multiple languages.

What is GitFichas?

GitFichas creates visual study cards (fichas in Portuguese) that help developers understand Git concepts through diagrams and flowcharts. Think of it as flashcards for Git, but built with modern web technologies and designed to be accessible to developers worldwide.

The project supports multiple languages: Portuguese, English, Spanish, and more coming! It uses Mermaid diagrams to create beautiful and friendly study materials.

Real Impact

During the first 10 days of Hacktoberfest 2025, GitFichas saw incredible community engagement with over 80 total pull requests merged.

This isn’t just about numbers - this proves the community wants to make Git education better for everyone.

Why Your Contribution Matters

When you contribute to GitFichas, you’re not just adding code or content, you’re also helping other developers understand Git better. Every translation makes the project accessible to new communities. Every bug fix improves the learning experience. Every new study card helps someone grasp a complex concept.

Ready to Contribute?

Explore the project on GitHub: github.com/jtemporal/gitfichas
Check out the issues: Look for issues with labels that match your interests like bug or enhancement
Join the conversation: Comment on issues to ask questions or show interest in working on them

Then make your PR.

Set Up Your Environment

I suggest you use GitHub Codespaces but you can also run things locally if you prefer:

git clone https://github.com/jtemporal/gitfichas.git
cd gitfichas
./setup.sh  # One command sets up everything!

You Can Use AI to Help You

GitFichas embraces AI and there are GitHub Copilot instructions to help you:

Understand the codebase structure
Follow project conventions
Migrate cards from hand-drawn initial format to the current Mermaid format

Make Your Contribution

Whether it’s translating a study card, fixing a typo, or migrating a card, every contribution makes Git learning better for developers worldwide. Don’t forget to link the issue in your PR description and wait for me to review.

Types of Contributions We Love

These are some of the contributions we have issues for at the moment:

1. Translations

Translate existing study cards
Adapt Git terminology for different regions
Review and improve existing translations

If you speak other languages, GitFichas is also capable of supporting more languages, feel free to add your vote here on what should be the next languages we tackle.

2. Technical Contributions

Improve mobile responsiveness
Fix any bugs you find

3. Content Addition

Create new study cards for Git concepts and commands
Improve explanations in existing cards

Connect and Learn More

Repository: github.com/jtemporal/gitfichas
Live Site: gitfichas.com
Create a new Discussion

Ready to make Git learning better for developers worldwide? I’m looking forward to your pull request! 🚀

Contribua com o GitFichas

Tue, 14 Oct 2025 04:00:00 +0000

Procurando um projeto open source para contribuir? Deixa eu te contar sobre o GitFichas, um projeto de fichas de estudo visuais sobre Git em vários idiomas.

O que é o GitFichas?

O GitFichas cria fichas de estudo visuais que ajudam devs a entender conceitos do Git através de diagramas. Pense no GitFichas como flashcards de estudo sobre Git, mas construído com tecnologias web modernas e projetado para ser acessível a devs do mundo todo.

O projeto suporta vários idiomas: português, inglês, espanhol, e mais por vir! O GitFichas usa diagramas Mermaid para criar materiais de estudo bonitos e amigáveis.

Impacto Real

Durante os primeiros 10 dias do Hacktoberfest 2025, o GitFichas viu um engajamento incrível da comunidade com mais de 80 pull requests mergeados no total.

Isso não é só sobre números, isso prova que a comunidade quer tornar a educação sobre Git melhor para todos.

Por que sua contribuição importa

Quando você contribui para o GitFichas, você não está apenas adicionando código ou conteúdo, você também está ajudando outras pessoas a entenderem Git melhor. Cada tradução torna o projeto acessível a novas comunidades. Cada correção de bug melhora a experiência de aprendizado. Cada nova ficha de estudo ajuda alguém a compreender um conceito ou comando novo.

Bora contribuir?

Explore o projeto no GitHub: github.com/jtemporal/gitfichas
Confira as issues: Procure por issues com labels que correspondam aos seus interesses como bug ou enhancement
Participe da conversa: Comente nas issues e faça perguntas ou mostre interesse em trabalhar nelas

Depois faça seu PR.

Configure seu ambiente

Eu sugiro que você use o GitHub Codespaces, mas você também pode executar tudo localmente se preferir:

git clone https://github.com/jtemporal/gitfichas.git
cd gitfichas
./setup.sh  # Um comando configura tudo!

Você pode usar IA para te ajudar

O GitFichas incorpora IA e há instruções do GitHub Copilot para te ajudar a:

Entender a estrutura do código
Seguir as convenções do projeto
Migrar fichas do formato inicial desenhado à mão para o formato atual do Mermaid

Faça sua contribuição

Seja traduzindo uma ficha de estudo, corrigindo um erro de digitação, ou migrando uma ficha, toda contribuição torna o aprendizado de Git melhor para pessoas desenvolvedoras do mundo todo. Não se esqueça de linkar a issue na descrição do seu PR e aguarde a revisão.

Tipos de contribuições que amamos

Essas são algumas das contribuições para as quais temos issues no momento:

1. Traduções

Traduzir fichas de estudo existentes
Adaptar terminologia do Git para diferentes regiões
Revisar e melhorar traduções existentes

Se você fala outras linguagens, o GitFichas também é capaz de suportar mais idiomas, aproveita pra adicionar seu voto aqui sobre quais deveriam ser os próximos idiomas que devemos implementar.

2. Contribuições técnicas

Melhorar responsividade mobile
Corrigir qualquer bug que você encontrar

3. Adição de conteúdo

Criar novas fichas de estudo para conceitos e comandos do Git
Melhorar explicações em fichas existentes

Conecte-se e saiba mais

Repositório: github.com/jtemporal/gitfichas
Site ao vivo: gitfichas.com
Crie uma nova Discussion

Pronto para tornar o aprendizado de Git melhor para pessoas do mundo todo? Estou ansiosa pelo seu pull request! 🚀

Hacktoberfest 2025: Diário de Campo, Semana 2

Sun, 12 Oct 2025 05:00:00 +0000

Esta é a segunda semana do Hacktoberfest 2025! Para esta série de posts vamos revisar algumas estatísticas das contribuições que recebi e fiz durante este mês.

Esta semana me concentrei principalmente no GitFichas devido à minha disponibilidade limitada, sem mais delongas, vamos falar sobre as contribuições.

GitFichas

Esta é a primeira semana “completa” de outubro e o GitFichas recebeu 54 pull requests! Aqui está o detalhamento:

53 PRs feitos pela comunidade
- 48 mergeados
- 2 fechados
- 3 abertos

Esse é o detalhamento das contribuições:

Esta semana tive pouco tempo disponível para focar em PRs durante a semana e você pode ver no gráfico acima que a maioria das contribuições foi feita pela comunidade em todas as categorias.

Ao analisar os gráficos de insights no projeto GitFichas Hacktoberfest 2025, percebi que minhas contribuições da primeira semana que focaram em fazer correções, apareceram nos gráficos de PRs mas não nos gráficos relacionados a Issues, já que estava fazendo as correções eu mesma sem abrir as issues para rastreá-las.

Com o tempo limitado para trabalhar em PRs devido a algumas mudanças de prioridades no trabalho, ao invés de fazer as correções eu mesma, abri issues para cada correção. Isso me permitiu rastrear as mudanças para fazer no fim de semana e também dar uma chance para a comunidade trabalhar nelas também. O resultado dessa mudança de comportamento da minha parte pode ser visto no gráfico de distribuição abaixo:

Se você olhar o primeiro gráfico no post você também verá que a comunidade fez a maioria dos PRs desta semana.

Falando em fechar issues, aqui está o burn up para a semana passada até 11 de outubro:

Embora as issues tenham aumentado em número, também fechamos várias delas. Se o ritmo continuar assim, é provável que tenhamos a maioria das issues fechadas no final do mês. 🎉

Essa semana eu também fui mostrar o GitFichas na Open Source Friday Brasil lá no canal do YouTube do GitHub, deixei várias dicas sobre usar AI para projetos, acho que vale a pena assistir:

Segunda-feira é feriado para mim, então espero fazer algumas contribuições eu mesma já que não consegui fazer tantas quanto queria durante a semana.

É isso pra semana 2! Fiquem ligados para a atualização da próxima semana sobre o Hacktoberfest 2025. 🎃

Até jajá.

Field Notes: Hacktoberfest 2025, Week 2

Sun, 12 Oct 2025 04:00:00 +0000

This is the second week of Hacktoberfest 2025! For this series of posts we will overview some stats for contributions I received and made over this month. This week I mostly focused on GitFichas due to limited availability, without further ado, let’s talk about the contributions.

GitFichas

This is the first full week of October GitFichas received 54 pull requests! Here’s the breakdown:

53 PRs made by the community
- 48 merged
- 2 closed
- 3 open

Here’s the breakdown of the contributions:

This week I had very little available time to focus on PRs during the week and you can see on the above chart that most contributions were made by the community across the board.

While analyzing the insights charts in the GitFichas Hacktoberfest 2025 project, I noticed that my contributions from the first week that focused on making corrections, showed up in the PRs charts but not Issues-related charts since I was making the corrections myself without even opening the issues to track them.

This week unfortunately I had limited time to work on PRs myself due to some changing priorities at work. So instead of making the corrections myself I opened issues for every correction. This would allow me to track changes to make on the weekend and to give a chance to the community to work on them as well. The result from this change in behavior on my end can be seen in the distribution chart below:

If you look at the first chart in the blog post you’ll also see that the community made most of the PRs this week.

Speaking of closing issues, here’s the burn up for this past week until October 11th:

While issues increased in numbers, we also closed a bunch of them. If the rhythm continues like this, it is likely that we’ll have most issues closed at the end of the month. 🎉

Monday is a holiday for me so I expect to make a few contributions of my own that I couldn’t throughout the week.

That’s a wrap for week 2! Stay tuned for next week’s update around Hacktoberfest 2025. 🎃

See you in the next one.

Hacktoberfest 2025: Diário de Campo, Semana 1

Sun, 05 Oct 2025 05:00:00 +0000

Conseguimos! Após quatro semanas de preptember, o Hacktoberfest finalmente chegou e eu não poderia estar mais animada! Meu emoji mais usado esta semana foi 🎉 com certeza e posso prever que ele vai levar o troféu de mais usado do mês!

Nesta série de posts vou fazer um resumão das estatísticas de contribuições que recebi e fiz ao longo deste mês, então vamos nessa.

GitFichas

Nesta primeira meia-semana de outubro, o GitFichas recebeu 42 pull requests:

26 PRs feitos pela comunidade
- 18 merged
- 6 fechados
- 2 ainda abertos

Esse é o detalhamento das contribuições:

Minhas contribuições (16 PRs) focaram em melhorar a documentação ou fazer correções baseadas nos PRs recebidos. Notei que algum tipo de diferença de sistema operacional está rolando e para alguns contribuidores a geração de SVG tem truncado o texto independente de onde estão as quebras de linha.

O GitFichas também tem um projeto do GitHub que você pode acompanhar o andamento caso tenha curiosidade o projeto está aqui. A parte interessante é a página de insights onde você pode ver alguns gráficos como o abaixo.

Outros projetos

Entre revisar os PRs recebidos e fazer outros para manter a saúde do GitFichas acabei não investindo tanto tempo quanto gostaria em outros projetos.

Ainda adicionei 2 novos projetos na lista de projetos brasileiros: uvicorn e starlette ambos mantidos pelo Marcelo Trylesinski.

E finalmente implementei o widget de séries de posts aqui no blog para que você possa ver posts que fazem parte de uma série como a do Preptember e esta que começa agora.

Por hoje é só! Vamos ter ainda mais atualizações conforme o Hacktoberfest 2025 continua. 🎃

Field Notes: Hacktoberfest 2025, Week 1

Sun, 05 Oct 2025 04:00:00 +0000

We made it! After four weeks of preptember, Hacktoberfest is finally here and I couldn’t be more excited! My most used emoji this week was 🎉 for sure and I can foresee that this one will take the trophy for the month!

For this series of posts we will overview some stats for contributions I received and made over this month so let’s talk about the contributions.

GitFichas

In this first half week of October GitFichas received 42 pull requests! Here’s the breakdown:

26 PRs made by the community
- 18 merged
- 6 closed
- 2 unmerged

Here’s the breakdown of the contributions:

My contributions (16 PRs) focused on either improving documentation or make corrections based on the PRs received. I noticed some sort of OS difference is going on and for some contributors the SVG generation has been truncating the text no matter where the break lines are.

GitFichas also has a project you can follow along if you are curious you can check it here. The interesting part about it is the insights page where you can see some charts like the one below.

Other projects

Between reviewing the PRs and making other ones to keep the health of GitFichas I ended up not spending as much time as I would like on other projects.

I still added 2 new projects on the brazilian projects list: uvicorn and starlette both maintained by Marcelo Trylesinski.

And finally implemented the series widget here on the blog so you can see related posts that are part of a series like the one from Preptember and this one.

That’s a wrap for week 1! Stay tuned for more updates as Hacktoberfest 2025 continues. 🎃

Projetos Brasileiros para contribuir nesse #Hacktoberfest 2025

Tue, 30 Sep 2025 05:00:00 +0000

O mês da festa que celebra open source no mundo todo está chegando e a #Hacktoberfest 2025 está aqui!

Por aqui você confere desde 2017 essa lista curada especialmente para te ajudar a encontrar projetos brasileiros para contribuir!

Regras para entrar nessa lista

As regras para adicionar projetos nessa lista:

Ser um projeto criado/desenvolvido/mantido por pessoas brasileiras;
Precisa ser um projeto, não pode ser uma organização, caso tenha mais de um projeto da organização adicione uma entrada por projeto;
Ter pelo menos uma issue aberta;
Ser um repositório válido, ou seja, não arquivado.

Avisos para 2025

Antes de mais nada não esqueça de se registrar para a Hacktoberfest aqui.

Prêmios

Mais uma vez a Hacktoberfest irá premiar seus participantes com prêmios virtuais no formato de badges Holopin. Você consegue ver as minhas aqui por exemplo.

Além disso, esse ano as pessoas podem fazer de 4 a 6 pull requests, quem completar 6 PRs vai ganhar uma customização a mais na sua badge.

Camisetas: também teremos camisetas, porém serão apenas 10.000 camisetas para pessoas que completarem 6 PRs em projetos elegíveis. Também serão plantadas 10.000 árvores juntamente com as camisetas e uma badge correspondente.

Adicionando projetos nessa lista

Esse ano vamos manter a mesma forma de aumentar essa lista com mais projetos, como sempre, apenas abrindo um PR com o projeto. As instruções de como adicionar projetos tão aqui. Todo mundo segue ganhando <3.

Os projetos continuam separados pela linguagem principal para facilitar as buscas e também em ordem alfabética pela linguagem. 😉

Qualidade > Quantidade

Assim como em anos anteriores, qualidade é o mais importante então se liga que dois PRs inválidos resultará em desqualificação por período indeterminado!

Para um PR ser considerado inválido, ele deve ser marcado com as tags spam ou invalid. Então é bom tentar fazer PRs de qualidade!

Relembrando que para tornar seu PR válido para a hacktoberfest você precisa ter algumas coisas. PRs apenas contarão se:

O PR precisa ser aberto em Outubro (entre os dias 1 e 31);
O PR precisa acontecer num projeto que tem o tópico hacktoberfest ou ser marcado com o rótulo (label) hacktoberfest-accepted por um mantenedor ou ser aceito (merged) ou ser aprovado pelo processo de revisão (review).

Mais informações

Mais informações no site oficial (em inglês).

Você pode comprar a versão virtual do meu livro “O grande Microlivro de Git” na Amazon, Gumroad ou no Pix tanto em português quanto inglês.

Nesse outro artigo tem 5 Dicas Para Fazer o Seu Pull Request Brilhar ✨ e por último confira o GitFichas para aprender ainda mais sobre Git (que também está aceitando pull requests, fica a dica).

Happy Hacking! 🎉

Acesso rápido por linguagem

C#
C
CSS
Clojure
C++
Dart
Elixir
Go
Java
JavaScript
Julia
Kotlin
Lua
PHP
Perl
Python
Ruby
Rust
Scala
Shell
TypeScript
Variados - Repositórios sem linguagem específica ex.: blogs, documentações e dicionários

C#

C

CSS

Clojure

C++

Dart

Elixir

Go

Java

JavaScript

Julia

Kotlin

Lua

PHP

Perl

Python

Ruby

Rust

Scala

Shell

TypeScript

Variados

Quarto e último fim de semana de Preptember 2025: Planos mudam e tudo bem

Mon, 29 Sep 2025 06:00:00 +0000

O último fim de semana do preptember chegou! Achei que o fim de semana anterior foi diferente dos dois primeiros, mas este foi diferente de uma forma totalmente nova. Definitivamente superestimei meus níveis de energia voltando do Oktane e subestimei os efeitos do jet lag.

Resumo: Novas issues abertas no GitFichas e dois PRs “fáceis” preparando a curadoria de projetos brasileiros para contribuir na Hacktoberfest 2025. Um dos PRs quebrou produção, o outro consertou o problema.

Recapitulando

No fim de semana passado implementei 6 esquemas de cores para o GitFichas, trazendo de volta a variedade visual que tornava as fichas originais desenhadas à mão especiais. Também melhorei as instruções do GitHub Copilot para ajudar contribuidores a terem melhores experiências assistidas por IA durante a Hacktoberfest. Apesar de uma agenda mais corrida devido à preparação para o Oktane, consegui fechar múltiplas issues enquanto migrava fichas em português e inglês para o novo formato Mermaid.

Trabalho da semana passada

Entre trabalhar no estande da Auth0 for AI Agents e apresentar um workshop chamado “Auth-ing your GenAI” no Oktane, viajar cobrou seu preço. E eu nem comecei a falar sobre jet lag.

Viajo para a costa oeste dos Estados Unidos o suficiente para saber que sempre vou acordar muito cedo e ir dormir muito tarde porque é uma conferência e sempre há outra conversa que não quero perder. Resumindo: acabei dormindo menos do que deveria essa semana.

Dito isso, só fazia sentido que os planos para este fim de semana precisassem de algumas mudanças, principalmente porque precisava me recuperar da viagem antes de conseguir fazer algo útil. O único problema é que olhando para trás, percebi que provavelmente não descansei tanto quanto deveria antes de mexer em qualquer repositório. 😅

Para o GitFichas, foquei apenas em criar novas issues. Durante a semana, antes do café da manhã um dia, abri mais de 50 issues para traduções para o espanhol já que agora temos suporte ao idioma. Todas as issues de tradução têm a tag translation.

Com essas issues abertas, considero o GitFichas pronto para a Hacktoberfest. 🎉

Falando em estar pronto para a Hacktoberfest, todos os PRs que fiz esse final de semana foram no repositório deste blog:

PR #309: Moveu os projetos do ano passado para sua própria pasta e criou a pasta 2025;
PR #310: Contém a lista rascunho já que os repositórios, na hora de escrever isso, ainda precisam de revisão para que a lista possa ser publicada. Vou fazer isso logo depois de publicar este post;
PR #311: Re-adiciona as versões passadas da lista como suas próprias collections, que por sinal chamei de “groupings” (agrupamentos) em todos os commits que fiz porque não conseguia lembrar da palavra “collections” (coleções)… Falei que deveria ter descansado mais, num falei?. 👀

Como a lista começou

Um pouco de contexto se você que acabou de chegar aqui: desde 2017 com a ajuda da comunidade dev brasileira eu faço a curadoria de uma lista de projetos brasileiros de código aberto.

A lista começou no Medium e ficou lá pelas duas primeiras edições em 2017 e em 2018.

Como eu queria que a comunidade pudesse contribuir com a lista, decidi mover a lista para o GitHub em 2019 no meu próprio blog para facilitar para as pessoas contribuírem.

Mantendo a história

Uma coisa que me incomodava na forma como eu estava estruturando os dados para a lista do Hacktoberfest entre 2019 e 2024, era que todo ano eu sobrescrevia a lista.

Pra falar a verdade não era nada lá muito grave, o post da lista recebe visualizações principalmente no ano correspondente mesmo, mas ainda assim me incomodava, embora não o suficiente para consertar esse comportamento, pelo menos não até este ano.

Por algum motivo, senti que 2025 merecia uma representação histórica adequada da lista, e agora se você navegar pelas listas dos anos anteriores, vai conseguir ver como a lista mudou. Essas são todas as listas passadas:

Quebrando produção só um pouquinho

No meu cansaço cometi um pequeno erro.

Veja bem, a lista funcionava baseada em uma única coleção: _hacktoberfest_projects. Esta coleção então renderizava a lista no post com um código liquid que começava assim:

{% assign grouped = site.hacktoberfest_projects | group_by: "principal_language" %}

Eu copiei a lista original para a pasta _hacktoberfest_projects_2025 e para evitar confusão renomiei a pasta anterior para _hacktoberfest_projects_2024.

O pequeno problema disso: quando a pasta original de projetos não existia mais, o Jekyll não deu nenhum erro porém as versões anteriores da lista começaram a mostrar conteúdo vazio. Deveria haver uma lista de projetos antes da assinatura na imagem abaixo por exemplo.

Então o PR #309 silenciosamente quebrou a produção já que eu, é claro, fiz merge do PR esquecendo dos anos anteriores.

Então comecei a trabalhar neste post que você está lendo agora e queria dar o contexto das listas passadas, então percebi que as páginas não estavam mostrando o conteúdo de forma correta e foi assim que o PR #311 surgiu.

Consertando produção com um pouco de trabalho

Agora eu precisava escolher um caminho e consertar o problema que a minha eu cansada criou:

Pegar o conteúdo de _hacktoberfest_projects de antes do PR #309, e aplicar esse conteúdo para todas as listas antes de 2024 o que faria que elas ficassem todas iguais; ou
Pegar o conteúdo de cada ano e aplicar isso em um novo PR para que todas as listas tenham dados precisos para mostrar.

Se você leu até aqui, provavelmente já sabe o que eu fiz. 👀

Sim, escolhi a solução número 2.

Na minha cabeça, a forma fácil de fazer isso era:

Escolher um commit depois de cada Hacktoberfest para pegar a pasta de projetos;
Copiar a pasta e adicionar isso ao meu branch de trabalho.

Fácil né? O desafio se tornou encontrar um commit para cada período no qual eu pudesse “pular” para copiar a pasta. Então entrei na lista de commits no GitHub e usei o botão de data para filtrar os commits:

De lá escolhi um commit e pulei para ele:

git switch 73fb9b686218251be6f5b1770f0151150a664862 --detach

Então copiei a pasta e criei um stash com ela:

cp -r _hacktoberfest_projects _hacktoberfest_projects_2019
git add _hacktoberfest_projects_2019
git stash

Voltei para o branch de trabalho e apliquei as mudanças do stash:

git switch hacktoberfest-projects-history
git stash pop

Depois disso fiz as outras mudanças como atualizar os arquivos de configuração e posts anteriores e então finalmente fiz os commits necessários.

Como não consegui pensar em uma forma melhor de fazer isso, repeti esse mesmo processo mais quatro vezes. Caso você tenha curiosidade, esses são os outros commits para os quais mudei:

git switch d4550d0c7f7ee492c334706749475d2235caec16 --detach
git switch ad60ba9a1b950d521419e86cf5c7547b9b922827 --detach
git switch 874b8f53cbe52e5c1d3f3832921c5d38b542dda1 --detach
git switch d2fc775c9e02569b78a43391ab49330384ed26ab --detach

Provavelmente há uma forma mais fácil ou até mais inteligente de fazer isso, mas funcionou bem para a minha eu cansada de ontem e se tá funcionando você não mexe. Você pode ver todas as mudanças e commits no PR #311.

O que vem por aí

Outubro começa esta semana, então no próximo fim de semana vou focar nos meus primeiros PRs para o Hacktoberfest, estes são os que estão na lista de prioridade:

Issue #173 no GitFichas: Gerar uma imagem de preview para cada um dos cards para facilitar o compartilhamento;
PR #166 no repositório do PyLadiesCon;

E eu sei que o PR #166 não conta para este Hacktoberfest, mas vai desbloquear outras contribuições, por isso quero dedicar um tempo a ele.

Junte-se a mim

Espero que este post também te inspire a aprender quando você precisa descansar e ajustar seus planos, mesmo que eu não ache que fiz isso particularmente bem desta vez. 😅

Às vezes fazer uma pausa é tão importante quanto seguir em frente.

Se você está procurando um projeto low-code para contribuir, o GitFichas tem mais de 130 issues abertas agora. E se você precisar de ajuda com suas contribuições, me mande uma mensagem em algum lugar.

Não esqueça de se registrar para a Hacktoberfest.

Bom código! 🎉

Preptember 2025 week 4: Final week is here, plans change and that's fine

Mon, 29 Sep 2025 04:00:00 +0000

The last weekend of preptember is here! I thought the previous weekend was different from the first two, but this one was different in a whole new way. I definitely overestimated my energy levels coming back from Oktane and underestimated the jet-lag effects.

TLDR: New issues open in GitFichas and two “easy” PRs preparing the curated list of Brazilian open source projects for Hacktoberfest 2025. One broke production, the other fixed the problem.

Recap

Last weekend I implemented 6 color schemes for GitFichas, bringing back the visual variety that made the original hand-drawn cards special. I also improved the GitHub Copilot instructions to help contributors have better AI-assisted experiences during Hacktoberfest. Despite a busier schedule due to Oktane preparation, I managed to close multiple issues while migrating Portuguese and English cards to the new Mermaid format.

Past week’s work

Between staffing the Auth0 for AI Agents booth and presenting an awesome workshop called “Auth-ing your GenAI” at Oktane, traveling took its toll on me. And don’t even get me started on the jet lag.

I travel to the west coast enough to know I’ll always wake up way too early and go to bed too late because it’s a conference and there’s always another conversation I don’t want to miss. Long story short: I ended up sleeping less than I should have this week.

With that said, it only made sense that the plans for this weekend needed some changing, mainly because I needed to recover from the trip before I could make something useful. The only issue is that looking back, I noticed that I probably didn’t rest as much as I should have before touching any repo. 😅

For GitFichas, I only focused on creating new issues. During the week, before breakfast one day, I opened over 50 issues for translations into Spanish since we can now support the language. All translation issues have the translation tag.

With these issues open, I consider GitFichas ready for Hacktoberfest. 🎉

Speaking of being ready for Hacktoberfest, all PRs I made were on this blog’s repository:

PR #309: Moved the projects from last year into its own folder and created the 2025 folder;
PR #310: Holds the draft list since the repositories, at the time of writing this, still require review so the list can be published. I will get to it right after publishing this one;
PR #311: Re-adds the past versions of the list as their own collections, which by the way I called “groupings” in all commits I made because I couldn’t remember the word “collections”… I told you I should’ve rested more. 👀

How the list started

A little context if you are new here: since 2017 with the help of the Brazilian dev community I curate a list of Brazilian open source projects.

The list started on Medium and stayed there for the first two editions in 2017 and in 2018.

I ultimately wanted the community to be able to contribute to it, so I moved the list into GitHub in 2019 under my own blog to make it easy for folks to contribute to it.

Keeping the history

One thing that made me unhappy with the way I was structuring the data for the Hacktoberfest list between 2019 and 2024 was that every year I would overwrite the list.

Not too big of a deal if you ask me, the blog post mostly gets views in the corresponding year anyway, but it still bothered me, though not enough to fix it until this year.

For some reason, I felt 2025 deserved a proper historical representation of the list, and now if you navigate to the previous years’ lists, you’ll get to see how the list changed.

These are all the past lists:

Breaking prod just a little bit

In my tiredness I made a tiny mistake.

You see, the list worked based on a single collection: _hacktoberfest_projects. This collection would then render list on the post with a liquid code that started like this:

{% assign grouped = site.hacktoberfest_projects | group_by: "principal_language" %}

Then I copied the original list into a _hacktoberfest_projects_2025 folder and to avoid confusion moved the previous folder into _hacktoberfest_projects_2024.

The issue being: when the original projects folder no longer existed, Jekyll gave out zero errors and then previous versions of the list started to show empty content. There should be a list of projects before the signature on the image below.

So PR #309 silently broke production since I, of course, merged the PR forgetting about the past years.

I then started working on this blog post you are reading right now and wanted to give the context for past lists, so I noticed the broken pages and that is how PR #311 came about.

Fixing prod with some work

Now I had to pick a path and fix the problem of my own tired mind creation:

Pick the content from _hacktoberfest_projects from before PR #309, and apply that so all lists before 2024 would look the same; or
Pick the content from each past year and apply that in a new PR so all lists will have accurate data to show.

If you read until now, you can probably guess what I did. 👀

Yep, I picked solution number 2.

In my brain, the easy way to do this was to:

Pick a commit after each Hacktoberfest to grab the projects folder
Copy the folder and add that to my working branch

Easy enough… The challenge became finding a commit in that period of time I could “jump into” to copy the folder from. So I got into the commits list in GitHub and then used the date button to filter out the dates like this:

From there I picked a commit and jumped into it:

git switch 73fb9b686218251be6f5b1770f0151150a664862 --detach

Then copied the folder and created a stash with it:

cp -r _hacktoberfest_projects _hacktoberfest_projects_2019
git add _hacktoberfest_projects_2019
git stash

Then went back to the working branch and applied the changes from the stash:

git switch hacktoberfest-projects-history
git stash pop

After that I made the other changes like updating the config files and previous posts and then finally made the necessary commits. Because I couldn’t think of a better way to do this, I repeated that same process four more times.

In case you are curious these are the other commits I switched into:

git switch d4550d0c7f7ee492c334706749475d2235caec16 --detach
git switch ad60ba9a1b950d521419e86cf5c7547b9b922827 --detach
git switch 874b8f53cbe52e5c1d3f3832921c5d38b542dda1 --detach
git switch d2fc775c9e02569b78a43391ab49330384ed26ab --detach

There’s probably an easier or even a smarter way to do this but this worked well for yesterday’s tired me and if it works you don’t mess with it. You can see all the changes and commits in PR #311.

What’s next

October starts this week, so next weekend I’ll be focusing on my first PRs for Hacktoberfest, these are the ones I plan on working on myself to start:

Issue #173 in GitFichas: Generating a preview image for each of the cards to make them easy to share;
PR #166 in the PyLadiesCon repository;

And I know the PR #166 doesn’t count for this Hacktoberfest but it will unblock others from contributing hence why I want to spend some time with it.

Join me

I hope this post also inspires you to learn when you need to rest and adjust your plans accordingly, even though I don’t think I did that particularly well this time around.

Sometimes taking a pause is just as important as pushing forward.

If you are looking for a low-code project to contribute to, GitFichas has over 130 issues open right now. And if you need help with your contributions, drop me a note somewhere.

Don’t forget to register for Hacktoberfest.

Happy coding! 🎉

Terceiro fim de semana de Preptember 2025: Cores e IA no GitFichas

Mon, 22 Sep 2025 05:00:00 +0000

O final de semana três de Preptember chegou, mas este foi um pouco diferente dos finais de semana anteriores… Este fim de semana foi cheio de preparação para o Oktane já que vou apresentar um workshop por lá além de ajudar no estande da Auth0, então meu tempo foi mais limitado que o normal. Mesmo com tempo limitado ainda consegui fechar uma issue que estava na lista. 🎉🎉

TLDR: Um PR implementando os 6 esquemas de cores que apareciam nas fichas originais, além de algumas melhorias nas instruções do Copilot para melhores contribuições assistidas por IA.

Recapitulando

No fim de semana passado implementei suporte a múltiplos idiomas para o GitFichas com a ajuda do GitHub Copilot. O sistema agora é capaz de suportar qualquer idioma ao invés de apenas português e inglês, o que foi uma grande vitória para localização. Também fiz o Copilot revisar seu próprio trabalho pela primeira vez, o que foi uma experiência no mínimo curiosa, o Copilot até apontou documentação que precisava ser atualizada 👀

O que foi feito neste fim de semana

Apesar da agenda mais corrida que o normal, consegui trabalhar em uma funcionalidade importante e fechar algumas issues.

Implementando os 6 esquemas de cores

PR #209 fechou múltiplas issues de uma vez:

Issue #63: A issue principal para implementar diferentes esquemas de cores como eu costumava ter quando desenhava as fichas à mão;
Issues #115, #114, #113, #112, #110: Migração de fichas em português para formato Mermaid;
Issues #162, #161, #160, #158: Migração adicional de fichas em inglês.

A implementação dos esquemas de cores traz de volta a variedade visual que tornava as fichas originais desenhadas à mão especiais. Agora cada ficha terá um dos 6 temas de cores diferentes:

Azul claro
Verde escuro
Roxo claro
Rosa
Roxo e rosa
Verde claro

As cores são automaticamente atribuídas baseadas no número da ficha usando a operação módulo, então cada ficha tem uma aparência consistente, não importa quantas fichas tivermos.

Cada esquema de cores é feito por um par de cores para que possamos ter subtítulos e pré-títulos em cores diferentes da cor principal do título, como nas imagens abaixo. No topo, a ficha original baseada em imagem, na parte inferior, a nova ficha gerada com Mermaid:

Ao invés da cor única de antes:

Você pode conferir todos os pares de cores neste arquivo. Você também pode ter notado que agora temos a borda na parte do título da ficha também. 🎉

Preparando para a Hacktoberfest assistida por IA

Enquanto migrava as fichas, também aproveitei a oportunidade para melhorar as instruções do GitHub Copilot. Com ferramentas de IA se tornando parte do fluxo de desenvolvimento, quero ajudar as pessoas contribuidoras a terem a melhor experiência possível ao usar essas ferramentas para também tornar seus PRs para o GitFichas melhores.

As melhorias focam em:

Melhor orientação para geração de diagramas Mermaid
Instruções mais claras para a migração de fichas desenhadas à mão para Mermaid
Exemplos mais específicos de como lidar com casos extremos

Eu espero um uso massivo de ferramentas de IA durante este Hacktoberfest, então acertar essas instruções agora vai ajudar todo mundo a ter sucesso, incluindo eu mesma já que vou estar do lado recebendo as contribuições e reviso cada PR pessoalmente mesmo quando peço para o copilot revisar primeiro.

Usar IA para revisar PRs pode acelerar o processo de revisão já que a IA vai pegar detalhes que meus olhos humanos podem perder. Como mantenedora eu vou então poder revisar as mudanças sugeridas e adicioná-las antes de fazer o merge se fizer sentido.

O que vem por aí

Com apenas mais um fim de semana até outubro chegar, estou chegando perto dos preparativos finais do preptember. No próximo fim de semana vou focar em:

Issue #173 no GitFichas: Gerar uma imagem de preview para cada uma das fichas para torná-las fáceis de compartilhar;
PR #166 no repositório PyLadiesCon;
Abrir novas issues para traduções em espanhol e talvez até francês;
E finalmente, revisar e criar a lista de projetos open source brasileiros que faço todo ano.

GitFichas está quase pronto para a chegada do Hacktoberfest!

Preparação para o workshop do Oktane

Falando em estar ocupada, a maior parte deste fim de semana foi investida me preparando para minha viagem ao Oktane, não só fazendo uma revisão final e ensaios do workshop que vou apresentar mas também garantindo que as roupas estejam prontas para fazer as malas e sim ainda sigo minhas próprias dicas de viagem.

É sempre empolgante compartilhar conhecimento com a comunidade, mesmo quando isso significa menos tempo para projetos pessoais. Como developer advocate eu amo encontrar pessoas desenvolvedoras onde elas estão e tanto palestras quanto trabalho open source, ao meu ver, são partes importantes de retribuir para a comunidade.

Bora lá

Como sempre, se você está planejando contribuir com open source durante o Hacktoberfest, agora é a hora de começar a explorar projetos e se familiarizar com seus processos de contribuição.

Você sabia que a inscrição para o Hacktoberfest 2025 já está aberta? Você pode se inscrever agora mas vale lembrar que os pull requests só vão contar se feitos durante o mês de outubro. Eu já me inscrevi. 👇

Então vai se inscrever também!

GitFichas está esperando suas contribuições! E se você precisar de ajuda para começar sua jornada nesse Hacktoberfest, entre em contato através de qualquer um das redes sociais na web.

Preptember 2025 week 3: Color schemes and Copilot improvements in GitFichas

Mon, 22 Sep 2025 04:00:00 +0000

Weekend 3 of preptember is here and this one was a bit different from the previous weekends… This weekend was packed with preparation for Oktane where I’ll be presenting a workshop, so my time was more limited than usual. But I still managed to close an issue that was on the list. 🎉🎉

TLDR: One PR implementing 6 color schemes so cards can look a little bit different from each other, plus some improvements to the Copilot instructions for better AI-assisted contributions.

Recap

Last weekend I implemented multi-language support for GitFichas with GitHub Copilot’s help. The site is now able to support any number of languages instead of just Portuguese and English, which was a big win for localization. I also had Copilot review its own work for the first time, which was quite the experience specially when it called out documentation that needed updating 👀

This weekend’s work

Despite the busier than usual schedule as I was preparing for Oktane, this weekend a few issues were closed.

Implementing the 6 color schemes

PR #209 closed multiple issues at once:

Issue #63: This was the main goal for the weekend. Implementing different color schemes like I used to have when I was hand-drawing the cards;
Issues #115, #114, #113, #112, #110: Migrating some Portuguese cards to Mermaid format in order to show off the cycling colors;
Issues #162, #161, #160, #158: Additional English cards migration also to show off the new colors.

The color scheme implementation brings back the visual variety that made the original hand-drawn cards special. Now each card has one of 6 different color themes:

Light Blue
Dark Green
Light Purple
Pink/Rose
Purple and Pink
Light Green

The colors are automatically assigned based on the card number using the modulo operation, so each card gets a consistent appearance no matter how many builds we have.

Each color scheme is made by a color pair so we can have subtitles and pretitles in a different color from the main title color like the ones below, at the top the original image based card, at the bottom the new Mermaid-powered card:

Instead of the flat color from before:

You can check all the pairings in this file. You also may have noticed that we now have the border on the title portion of the card now as well. 🎉

Preparing for AI-assisted Hacktoberfest

While migrating the cards, I also took the opportunity to improve the GitHub Copilot instructions. With AI tools becoming part of any development flow, I want to make sure contributors have the best possible experience when using these tools to also make their PRs to GitFichas.

The improvements focus on:

Better guidance for Mermaid diagram generation
Clearer instructions for the migration from hand-drawn cards to Mermaid ones
More specific examples of how to handle edge cases

I’m expecting a massive use of AI tools during this year’s Hacktoberfest, so getting these instructions right now will help everyone succeed, including me since I’ll be on the receiving end of the contributions and I review every PR myself even when I ask copilot to review it first.

Using AI to review PRs can speed the review process as AI will catch details my human eyes might miss. As a maintainer I’ll then be able to review the suggested changes and add those in before merging if it makes sense.

What’s next

With only one weekend until October arrive, I’m getting close to the final preptember preparations. Next weekend I’ll be focusing on:

Issue #173 in GitFichas: Generating a preview image for each of the cards to make them easy to share;
PR #166 in the PyLadiesCon repository;
Open new issues for translations into Spanish and maybe French;
And finally, review and create the list of Brazilian open source projects.

GitFichas is almost ready for Hacktoberfest!

Oktane workshop prep

Speaking of being busy, most of this weekend was spent preparing for my trip to Oktane, not only doing a final review and rehearsals of the workshop I’m presenting but also making sure the clothes are ready for packing and yes I still follow my own traveling tips.

It’s always exciting to share knowledge with the community, even when it means less time for side projects. As a developer advocate, I love meeting developers where they are and both speaking at conferences and open source work are important parts of giving back to the community for me.

Join me

As always, if you’re planning to contribute to open source during Hacktoberfest, now’s the time to start exploring projects and getting familiar with their contribution processes.

Did you know that the registration for Hacktoberfest 2025 is already open? You can register now but it is worth reminding that the pull requests will only count during the month of October. I’m already registered. 👇

So go register too!

GitFichas is ready and waiting for your contributions! And if you need help getting started with your Hacktoberfest journey, reach out through any of my social profiles on the web.

Happy coding! 🎉

Segundo fim de semana de Preptember 2025: GitFichas trilingüe

Mon, 15 Sep 2025 05:00:00 +0000

Pois é, já estamos no meio de setembro e aqui está meu relatório da segunda semana do preptember!

TLDR: PR grande para fechar a issue de suporte a idiomas no GitFichas e mais alguns PRs menores.

Finalmente atualizei o suporte a idiomas com a ajuda do GitHub Copilot em modo Agent e agora o GitFichas é capaz de suportar múltiplos idiomas ao invés de apenas português e inglês, então uma grande vitória para localização.

Si hablas español… estamos procurando contribuições em traduções para espanhol. Se você fala outros idiomas eles também são bem-vindos!

Recapitulando

Na semana passada comecei o preptember corrigindo um problema grande no GitFichas onde os gráficos Mermaid não estavam renderizando corretamente no navegador. A solução foi mudar de renderização no lado do cliente para pré-gerar arquivos SVG usando a CLI do Mermaid.

Também adicionei várias funcionalidades novas incluindo um script de configuração com um comando só, instruções do GitHub Copilot para contribuidores, geração automática de SVG e documentação melhorada. O objetivo era preparar o GitFichas para o influxo de contribuições do Hacktoberfest tornando-o mais acolhedor e fácil de contribuir.

Issues fechadas e pull requests feitos

Esta é a lista do trabalho feito nesse final de semana:

Issue #204: Atualizar a seleção de idioma;
PR #205: Este PR implementou o suporte a múltiplos idiomas e fechou a issue acima 🎉
PR #207: que atualizou o conteúdo da página de contato em português e inglês;
PR #206: Corrigiu um pequeno erro de lógica introduzido em um PR de fim de semana anterior para a renderização mermaid no navegador.
PR #208: Ajustes de renderização de fichas

Senta que lá vem história…

Usando Copilot em modo Agent e vibe coding

Pela primeira vez eu fiz o Copilot não apenas fazer a maior parte do trabalho mas também revisando seu próprio trabalho em um PR.

Não sou muito fã de vibe coding, não consigo simplesmente apertar “Keep” para todas as mudanças que a IA faz e não pensar duas vezes antes de fazer commit. Minha cabeça não aceita isso.

Mas o mais próximo que chego de vibe coding é pedir para a IA fazer algo e depois revisar, dar feedback específico sobre o que não está funcionando e pedir para corrigir o que está quebrado. Esse tipo de processo funciona bem mas definitivamente não é tão rápido quanto aceitar cegamente qualquer output que eu receba.

Mesmo assim, os PRs que coloquei no ar esse final de semana me tomaram cerca de 6 horas de trabalho sem foco. Se eu tivesse sido mais focada, provavelmente teria levado 4 horas, mas é fim de semana né?!

Posso dizer com certeza absoluta que sem nenhuma ajuda de IA, entre escrever código novo, refatorar código pré-existente, testar, fazer preview de deployments, ajustes e casos de borda esquecidos, isso provavelmente me tomaria cerca de dois dias para finalizar.

Não só isso, provavelmente significaria que o deploy pra produção teria que esperar até o próximo fim de semana para ir ao ar já que eu gostaria de ter mais tempo para revisar meu próprio trabalho antes de fazer o merge do pull request.

Usando Copilot como revisor de pull requests

E falando de revisão, esta foi a primeira vez que tive o Copilot fazendo a revisão para mim e foi interessante para dizer o mínimo.

Ele chamou minha atenção para a documentação que esqueci de atualizar, assim como para o fato de que meu PR não seguia as diretrizes do projeto. 😂

Deixa eu explicar. Até agora o GitFichas tinha suporte apenas para duas linguagens faladas: português e inglês. E a forma como a localização estava implementada não permitia que outras traduções fossem facilmente adicionadas. Então parte da documentação do projeto deixava claro que o conteúdo do site estava apenas nessas duas linguagens iniciais.

Então definitivamente sorri quando o Copilot apontou que meu PR estava indo contra as próprias diretrizes do projeto de suportar apenas português e inglês.

Esse comentário serviu como um lembrete bem colocado para não apenas atualizar a documentação (o que fiz motivada por outro comentário similar) mas também as instruções do Copilot já que elas são usadas nas revisões além do chat no VS Code.

Próximos passos

A lista de issues para os próximos fins de semana é a seguinte:

Issue #173 no GitFichas: Gerar uma imagem de preview para cada um dos cards para facilitar o compartilhamento
Issue #63 no GitFichas: Criar temas diferentes para que cada card pareça um pouco diferente dos outros

Também planejo voltar aos pull requests que deixei de lado durante o ano.

Em particular o #166 no repositório do PyLadiesCon. Mariatta se você estiver lendo isso: sinto muito a demora para voltar a ele, no próximo fim de semana vou resolver os conflitos para podermos fazer o merge.

Nota à parte: Você viu sua lista de pull requests ultimamente? A minha parece que nunca chega a zero. 😂

Vamos juntos

Se você está pensando em contribuir para open source durante o Hacktoberfest, comece a procurar possíveis projetos para os quais quer contribuir. Faça uma lista de projetos, fork e clone os repos, confira os guias de contribuição e comece a se preparar porque outubro está quase aqui.

Como sempre, confira o GitFichas no GitHub e se precisar de ajuda com suas contribuições me mande uma mensagem em um dos muitos lugares sociais por aí! 🎉

Preptember 2025 week 2: GitFichas now supports multi-language

Mon, 15 Sep 2025 04:00:00 +0000

Yes, we’re already in the middle of September and here’s my week 2 preptember report!

TLDR: Big PR to close the language support issue on GitFichas and a couple of other minor PRs.

I finally updated the language support with the help of GitHub Copilot in agent mode and now GitFichas is capable of supporting multiple languages instead of just Portuguese and English, so big win for localization.

Si hablas español… we are looking for contributions in translations to Spanish. If you speak other languages they are also welcome!

Recap

Last week I kicked off preptember by fixing a major issue with GitFichas where Mermaid charts weren’t rendering properly in the browser. The solution was to switch from client-side rendering to pre-generating SVG files using the Mermaid CLI.

I also added several new features including a one-command setup script, GitHub Copilot instructions for contributors, automated SVG generation, and improved documentation. The goal was to prepare GitFichas for the influx of Hacktoberfest contributions by making it more welcoming and easier to contribute to.

Issues closed and pull requests merged this weekend

This is the list of work done:

Issue #204: Update the language selection;
PR #205: This PR implemented the multi-language support and closed the issue above 🎉
PR #207: which updated the content from the contact page in both Portuguese and English;
PR #206: Fixed a minor error in logic introduced in a previous weekend PR for the in browser mermaid rendering.
PR #208: Tiny rendering adjustments

Now story time…

Using Copilot and vibe coding for non-vibe-coders

For the first time I had Copilot not only do the bulk of the work but also review its own work in a PR.

I’m not much of a vibe coder, I can’t just simply say “Keep” to the changes AI makes and not bat an eye on it before committing. That’s just not me.

But the closest I get is to ask the AI to do something and then review it, then provide specific feedback on what is not working, and ask it to fix what is broken. That type of process works well but is definitely not as fast as just blindly accepting whatever output I get.

Nonetheless, the PRs I put in place this weekend took me about 6 hours of unfocused work. If I had been more focused, it probably would’ve taken me 4 hours, but it is a weekend after all.

But I can say with complete certainty that without any AI help, between writing new code, refactoring pre-existing code, testing, preview deployments, adjustments, and forgotten edge cases, this would probably take me about two days to get it done.

Not only that, it would probably mean that the production deployment would probably wait till next weekend to be deployed since I’d like to have more time to review my own work before shipping it.

Using Copilot to review pull requests

And speaking of review… This was the first time that I had Copilot do the review for me and it was interesting to say the least.

It called my attention to the documentation I forgot to update, as well to the fact that my PR did not follow the project guidelines. 😂

Let me explain. So far GitFichas had only support for two spoken languages: Portuguese and English. And the way the localization was implemented it didn’t allow for any other translations to be easily added. So part of the project documentation made it clear that the content on the website was only in those two initial languages.

So I definitely smirked when Copilot pointed out that my PR was going against the project’s own guidelines for only supporting Portuguese and English.

Anyways it served as a well-placed reminder to not only update the documentation (which I did prompted by another similar comment) but also the Copilot instructions as they are used in the reviews.

What’s Next

The list of issues for next weekends is the following:

Issue #173 in GitFichas: Generating a preview image for each of the cards to make them easy to share
Issue #63 in GitFichas: Creating different themes so that each card looks a little bit different from each other

I also plan on going back to pull requests I left unattended over the year.

In particular the #166 in the PyLadiesCon repository. Mariatta if you are reading this: I’m terribly sorry it took me this long to get back to it, next weekend I’ll get the conflicts resolved so we can merge it.

Side note: Have you seen your list of pull requests lately? Mine seems to never reach zero. 😂

Join me

If you are thinking about contributing to open source during Hacktoberfest, start working now on figuring out possible projects you want to contribute to. Make a list of them, fork and clone the repos, check out the contribution guides, and start getting ready because October is fast approaching.

As always, check out GitFichas on GitHub and if you need help figuring out your contributions send me a note in one of the many social places out there! 🎉

How to Configure the Auth0 MCP Server in VS Code for AI Assistant Integration

Mon, 08 Sep 2025 06:00:00 +0000

Primeiro fim de semana de preptember 2025

Mon, 08 Sep 2025 05:00:00 +0000

O Hacktoberfest está chegando, e durante este fim de semana decidi começar minhas tarefas de preptember. Então essa é a história da semana 1 do preptember.

O que é Preptember?

Para quem não conhece o termo, “Preptember” é o mês antes do Hacktoberfest onde quem mantém projetos preparam seus repositórios para as contribuições que outubro traz. É sobre configurar seus projetos para serem mais acolhedores e mais fáceis de contribuir.

GitFichas e Preptember

Desde que eu abri o código do GitFichas comecei a usar Mermaid para criar novas fichas de estudo, ele tinha um problema com a renderização adequada do conteúdo: os gráficos Mermaid às vezes falhavam ao renderizar corretamente no navegador no primeiro load da página, causando problemas de layout e tornando as fichas difíceis de ler. Então neste fim de semana o desafio foi corrigir esse problema.

Não importava o que eu fizesse no CSS da geração das fichas, por algum motivo o problema não deixava de existir. Então pareceu natural começar a gerar SVGs ao invés de renderizar gráficos Mermaid no carregamento da página. Essa abordagem gera os diagramas como arquivos SVG estáticos, eliminando completamente os problemas de renderização no lado do cliente.

Para gerar SVGs precisávamos de algumas atualizações na dinâmica de como geramos cada ficha de estudo usando o Mermaid CLI.

Novas funcionalidades

Como minha expectativa é usar esse hacktoberfest para terminar de migrar todas as fichas para a configuração Mermaid, algumas atualizações foram necessárias no repositório.

🚀 Configuração com Um Comando: Script de configuração para instalar todas as dependências necessárias, incluindo pacotes Node.js para o Mermaid CLI e Puppeteer para renderização de navegador headless.
🤖 Instruções do GitHub Copilot: Estamos afinal de contas na era da IA e espero que o Copilot nos ajude a fechar a maioria das issues abertas.
🎨 Geração de SVG Mermaid: Script para gerar SVG usando o Mermaid CLI para que possamos fazer tudo isso automaticamente.
📚 Documentação Melhorada: Atualizações nas diretrizes de contribuição e documentação para todas as novas partes móveis.

O que vem por aí

Com essa base sólida, estou animada para ver o que a comunidade vai construir durante o Hacktoberfest. As mais de 90 issues abertas ainda estão disponíveis e pessoalmente vou trabalhar em algumas das melhorias durante este mês para que o GitFichas esteja ainda melhor quando o Hacktoberfest chegar.

Algumas das issues que vou atacar nos próximos finais de semana são:

Issue #173: Gerar uma imagem de preview para cada ficha para facilitar o compartilhamento
Issue #63: Criar diferentes temas para que cada ficha pareça um pouco diferente um da outra
Issue #204: Atualizar a seleção de idioma

Espero conseguir trabalhar nessas issues durante os fins de semana daqui para frente. Elas serão desafiadoras mas estou confiante de que vão melhorar o GitFichas muito. E para ser honesta, talvez eu comece com o seletor de idioma primeiro já que fiz parte desse refactor no meu site. 😂

Vem comigo

O GitFichas sempre foi sobre aprendizado em comunidade, e agora o processo de contribuição combina ainda mais com esse espírito. Se você estava esperando o momento certo para contribuir com um projeto open source, ele chegou.

Confira o GitFichas no GitHub e vamos criar a melhor coleção de fichas de estudo sobre Git! 🎉

First weekend of preptember 2025

Mon, 08 Sep 2025 04:00:00 +0000

Hacktoberfest is just around the corner, and over this weekend I decided to start my preptember tasks. So this is the story of the week 1 of preptember.

What’s Preptember?

For those new to the term, “Preptember” is the month before Hacktoberfest where maintainers prepare their repositories for the influx of contributions that October brings. It’s about setting up your project to be as welcoming and easy to contribute to as possible.

GitFichas and Preptember

Since open-sourcing GitFichas and starting to use Mermaid to build new study cards, it had an issue with properly displaying content. The Mermaid charts would sometimes fail to render correctly in the browser, causing layout issues and making the cards hard to read. So this weekend the challenge was to fix that issue.

The problem was that no matter which way I worked on the CSS for the card generation it still couldn’t fix the issue. So it felt natural to start generating SVGs instead of rendering Mermaid charts on load. This approach pre-generates the diagrams as static SVG files, eliminating the client-side rendering issues entirely.

In order to generate SVGs we needed some updates to the dynamic on how we generate each study card using the Mermaid CLI.

New features

Since my expectation is to use this hacktoberfest to finish migrating all study cards to the Mermaid setup, some updates were required to the repository.

🚀 One-Command Setup: Setup script to install all necessary dependencies, including Node.js packages for the Mermaid CLI and Puppeteer for headless browser rendering.
🤖 GitHub Copilot Instructions: We are after all in the AI time and I expect that Copilot will help us closing most of the open issues.
🎨 Mermaid SVG Generation: Script for generating SVG using the Mermaid CLI so we can do all of that automatically.
📚 Improved Documentation: Updates to contribution guidelines and documentation to all new moving parts.

What’s Next

With the solid foundation, I’m excited to see what the community builds during Hacktoberfest. The 90+ open issues are still up for grabs and personally I’ll be working on some of the enhancements through this month so that GitFichas is even better by Hacktoberfest time.

Some of the ones I’ll be tackling next weekend will be:

Issue #173: Generating a preview image for each of the card so easy to share
Issue #63: Creating different themes so that each card looks a little bit different from each other
Issue #204: Update the language selection

I expect I can work on these over the weekends moving forward. These will be challenging but I’m confident that they will improve GitFichas a lot. And to be honest I might start with the language selector first. 😂

Join me

GitFichas has always been about community learning, and now the contribution process matches that spirit. If you’ve been waiting for the right moment to contribute to an open source project, this is it.

Check out GitFichas on GitHub and join me in creating the best collection of Git study cards on the internet! 🎉

Configurando um servidor MCP Python local no VS Code

Sun, 07 Sep 2025 04:00:00 +0000

Servidores MCP (Model Context Protocol) estendem assistentes de IA com capacidades customizadas e acesso a recursos. Embora usar um servidor MCP no Claude Desktop seja fantástico para pesquisa geral e descoberta de conteúdo, há ainda mais valor em integrar essas mesmas ferramentas diretamente no seu ambiente de desenvolvimento.

Como escrevo meus posts de blog em Markdown e os gerencio através do GitHub, ter o servidor MCP disponível direto no VS Code significa que posso buscar por conteúdo relacionado, verificar referências e manter consistência sem sair do meu editor.

Então vamos também configurar nosso MCP em uma IDE para melhorar nosso processo de escrita e edição.

Recapitulando

Em um post anterior criamos um servidor MCP com duas ferramentas:

search_posts: busca através de posts do blog usando SerpApi para encontrar conteúdo que corresponde a uma consulta específica
get_post_content: recupera o conteúdo completo em markdown de um post específico pelo título

Este MCP de busca e recuperação de conteúdo do blog nos permite usar nosso assistente de IA para rapidamente encontrar e acessar informações do nosso blog, facilitando referenciar trabalhos anteriores e manter consistência entre posts.

Naquele post anterior, construímos um servidor MCP Python que aproveita o SerpApi para buscas específicas no site e usa o padrão llms.txt para indexar e recuperar conteúdo completo dos posts. O servidor permite integração perfeita entre assistentes de IA e conteúdo do blog, transformando seu blog em uma base de conhecimento pesquisável.

Se você quer aprender mais sobre tool calling confira o vídeo abaixo ou este post no blog do trabalho (ambos em inglês).

Servidores MCP no VS Code

Se você navegar até a aba Extensions no VS Code, verá uma seção dedicada para servidores MCP. Esta integração traz o poder do Model Context Protocol diretamente para seu ambiente de desenvolvimento, permitindo que você aproveite ferramentas e capacidades customizadas enquanto programa, escreve ou gerencia seus projetos.

A extensão MCP para VS Code detecta automaticamente servidores configurados e fornece uma interface perfeita para interagir com eles através do GitHub Copilot Chat. Isso significa que você pode acessar suas ferramentas customizadas sem sair do seu editor, tornando seu fluxo de trabalho mais eficiente e integrado.

Pré-requisitos

Antes de começarmos, certifique-se de ter:

Python 3.8+ instalado no seu sistema
uv package manager (guia de instalação)
VS Code com a extensão GitHub Copilot habilitada
Uma chave SerpApi para funcionalidade de busca (obtenha uma aqui)

Configurar seu servidor local

Antes de configurar o servidor MCP no VS Code, você precisará configurar o projeto localmente. Aqui estão os passos:

Clone o repositório:

git clone https://github.com/jtemporal/blog-search-mcp-in-python.git
cd blog-search-mcp-in-python

Instale as dependências usando uv:
```
uv sync
```
Configure seu ambiente: Crie um arquivo .config baseado no .config.example com sua chave SerpAPI e URL do blog.
Teste o servidor:
```
uv run src/server.py
```

Uma vez que seu servidor esteja funcionando localmente, você tem tudo que precisa para integrá-lo com o VS Code.

Adicionando a configuração MCP

Para adicionar seu servidor MCP ao VS Code, pressione Cmd+Shift+P (Mac) ou Ctrl+Shift+P (Windows/Linux) para abrir a paleta de comandos, então digite “MCP” e selecione “MCP: Add Server” da lista. Isso abrirá o assistente de configuração MCP.

O primeiro passo é escolher a camada de transporte. Para nosso servidor Python local, selecione “stdio” como método de transporte. Isso permite que o VS Code se comunique com seu servidor através de fluxos de entrada/saída padrão.

Adicionando o comando para executar seu MCP

Em seguida, você precisará especificar o comando que o VS Code deve usar para iniciar seu servidor MCP. Como nosso servidor tem dependências externas (SerpAPI), precisamos incluí-las no comando.

Nota: O caminho exato para uv pode variar dependendo do seu método de instalação. Se você instalou via pip, pode estar em uma localização diferente. Você pode encontrar o caminho do seu uv executando which uv no seu terminal.

~/.local/bin/uv run --with google-search-results --with mcp[cli] mcp run ~/caminho/para/repositorio/blog-search-mcp-in-python/src/server.py

Certifique-se de substituir ~/caminho/para/repositorio/blog-search-mcp-in-python/ pelo caminho real para seu repositório clonado.

Após inserir o comando, dê ao seu servidor MCP um nome descritivo que ajudará você a identificá-lo na interface do VS Code.

Definir onde a configuração deve ser aplicada

O VS Code perguntará onde salvar a configuração MCP. Você pode escolher entre aplicá-la globalmente (para todos os workspaces) ou apenas para o workspace atual.

Seguindo o princípio do menor privilégio, é recomendado escolher “Workspace” ao invés de “Global”. Isso mantém a configuração limitada ao seu projeto atual e previne potenciais conflitos com outros projetos.

Isso criará uma pasta .vscode/ se ela não existir no seu repositório, e criará um arquivo mcp.json correspondente com a configuração. Deve ficar parecido com isso:

{
	"servers": {
		"jtemporal-blog-search": {
			"type": "stdio",
			"command": "~/.local/bin/uv",
			"args": [
				"run",
				"--with",
				"google-search-results",
				"--with",
				"mcp[cli]",
				"mcp",
				"run",
				"~/projects/blog-search-mcp-in-python/src/server.py"
			]
		}
	},
	"inputs": []
}

Executando ações MCP diretamente do mcp.json

Uma vez configurado, você não apenas verá o arquivo de configuração, mas o VS Code também mostrará um menu inline dentro do arquivo. Isso fornece acesso rápido às operações comuns do servidor MCP.

Se você selecionar o botão More... no menu inline, verá opções adicionais em um menu de diálogo que fornece operações mais avançadas para gerenciar seu servidor MCP.

Dicas de debugging

Se você selecionar “Show output” do menu do servidor MCP, será levado para a saída de log no painel inferior da janela do VS Code. Isso é inestimável para fazer debugging de problemas com seu servidor MCP.

Os logs mostrarão informações detalhadas sobre inicialização do servidor, chamadas de ferramentas e quaisquer erros que ocorram. Isso é particularmente útil quando desenvolvendo ou fazendo troubleshooting do seu servidor MCP.

Se você configurar seu servidor incorretamente (por exemplo, se esquecer parte das flags --with no comando), verá uma mensagem de erro diretamente na interface do arquivo de configuração:

Essas mensagens de erro inline facilitam identificar e corrigir problemas de configuração sem ter que procurar através de arquivos de log.

Dito isso, se você não souber qual é o erro, também pode acessar os arquivos de log indo para o painel inferior na aba Output e selecionando o nome do servidor no menu dropdown:

Encontrando seu servidor MCP

Agora volte para a aba Extensions e você deve ver seu servidor MCP listado na seção de servidores MCP assim:

A partir daqui, você pode investigar os detalhes do servidor, ver suas ferramentas disponíveis e até ajustar sua configuração se necessário. Isso fornece uma localização centralizada para gerenciar todos os seus servidores MCP dentro do VS Code.

Usando seu servidor MCP

Todo esse trabalho de configuração é ótimo, mas o objetivo real é poder buscar conteúdo do seu blog em um cenário de chat direto no VS Code. Vamos colocar nosso servidor MCP para trabalhar fazendo uma busca através do GitHub Copilot Chat:

A interface mostra a ferramenta que está pretendendo chamar (search_posts) bem como os parâmetros de entrada—neste caso, o tópico sobre o qual queremos encontrar posts do blog. Essa transparência ajuda você a entender exatamente o que a IA está fazendo em seu nome.

Agora tem um truque legal: normalmente você teria que pedir pelo conteúdo depois de obter os resultados da primeira chamada de ferramenta, mas se você estiver usando o GitHub Copilot no modo agente, o agente é realmente inteligente o suficiente para oferecer a execução de ferramentas adicionais para obter o conteúdo completo:

Desta vez mostra a função get_post_content sendo chamada, com a descrição docstring e os parâmetros de entrada para recuperar o conteúdo específico.

Finalmente, os resultados são exibidos no chat como qualquer outra interação de ferramenta seria:

Essa integração perfeita significa que você pode buscar seu blog, recuperar conteúdo e incorporá-lo ao seu trabalho atual sem nunca sair do VS Code.

Considerações de segurança

Ao executar servidores MCP locais, mantenha essas melhores práticas de segurança em mente:

Configuração a nível de workspace: Sempre escolha nível de workspace sobre configuração global para limitar exposição
Revise dependências: Certifique-se de confiar em todos os pacotes e dependências que seu servidor MCP usa
Acesso à rede: Esteja ciente de que servidores MCP podem fazer requisições de rede (como nossas chamadas SerpApi)
Acesso a arquivos: Servidores MCP têm acesso a arquivos dentro do seu escopo configurado

Aprendizados

Ter seu servidor MCP integrado diretamente no seu ambiente de desenvolvimento cria um fluxo de trabalho simplificado onde você pode buscar, referenciar e incorporar seu conteúdo existente sem mudança de contexto. Isso é particularmente valioso para criadores de conteúdo, escritores técnicos e pessoas desenvolvedoras que precisam manter consistência ao longo do seu trabalho.

Não importa qual IDE você está usando, lembre-se desses passos:

Configuração local: clone o repositório do seu servidor MCP e certifique-se de que todas as dependências estão propriamente instaladas usando uv sync
Configuração: use a extensão MCP do VS Code para configurar seu servidor com o comando apropriado, incluindo todas as flags e dependências necessárias
Gerenciamento de escopo: escolha configuração a nível de workspace sobre global para seguir melhores práticas de segurança
Debugging: aproveite os recursos de logging e relatório de erro integrados para fazer troubleshooting de problemas

A combinação de servidor MCP customizado com GitHub Copilot no modo agente ajudará você a manter seu estado de flow que como pessoas escrevem código é tudo que realmente queremos.

Agora só preciso descobrir a melhor abordagem para ter esse servidor sem ter que clonar um repositório e configurá-lo manualmente, 🤔 mas isso acontecerá em um post futuro.

Como criar um arquivo llms.txt no Jekyll e GitHub Pages

Sun, 31 Aug 2025 10:00:00 +0000

Você já quis deixar o conteúdo do seu blog mais acessível para sistemas de IA e LLMs (large language models)? Ou talvez você tenha se perguntado como fornecer uma versão “limpa” dos seus posts sem todos as tags do HTML?

O arquivo llms.txt é a solução. Ele fornece uma forma padronizada para sites exporem seu conteúdo para sistemas de IA. E se você está usando Jekyll com GitHub Pages, pode criar esse arquivo automaticamente com apenas algumas linhas e um template Liquid.

Se você acabou de começar a usar o Jekyll: ele é um gerador de sites estáticos escrito em Ruby que é perfeito para blogs especialmente quando usado no GitHub Pages. Você pode aprender mais sobre Jekyll e como começar a usa-lo neste outro post: Colocando um site no ar com Jekyll.

O que é o llms.txt

O arquivo llms.txt é um formato de texto simples projetado para tornar sites mais acessíveis para sistemas de IA e LLMs. Baseado na especificação do llmstxt.org, ele fornece uma forma padronizada de expor o conteúdo do seu site em um formato legível pelas IAs que tanto usamos hoje em dia.

A estrutura básica inclui:

Uma breve descrição do seu site
Informações importantes sobre seus projetos, serviços ou conteúdo
Links para páginas ou conteúdo importantes
Qualquer outra informação que você gostaria que sistemas de IA soubessem sobre seu site

Para um blog em Jekyll armazenado num repositório do GitHub, o llms.txt é perfeito para fornecer aos LLMs acesso direto aos seus posts em seu formato Markdown original, tornando mais fácil para a IA entender e referenciar seu conteúdo com precisão.

Criando um arquivo llms.txt

Criar um arquivo llms.txt para seu site Jekyll é relativamente simples. Você criará um novo arquivo na raiz do seu projeto Jekyll e usar Liquid para gerar automaticamente o conteúdo.

Esse é o passo a passo:

Criar o arquivo: No diretório raiz do seu repositóeion, crie um novo arquivo chamado llms.txt
Adicionar o template: Use o seguinte template como ponto de partida:

---
layout: null
---

# Feed LLM para jtemporal.com
_Gerado em: {{ site.time | date_to_rfc822 }}_


## Todos os posts
Os links abaixo levam você ao conteúdo Markdown original.

{% for post in site.posts %}- [{{ post.title }}](https://raw.githubusercontent.com/jtemporal/jtemporal.github.io/refs/heads/main/{{ post.path }})
{% endfor %}

Algumas coisas para prestar atenção:

layout: null garante que o arquivo seja gerado como texto puro, não HTML
{{ site.time | date_to_rfc822 }} adiciona um timestamp mostrando quando o arquivo foi gerado pela última vez
O loop {% for post in site.posts %} cria automaticamente uma lista de todos os seus posts do blog
{{ post.path }} dá o caminho relativo para o arquivo Markdown de cada post
O formato de URL do GitHub raw permite acesso direto ao Markdown fonte

O resultado gerado deve ser algo assim:

Adicionar llms.txt ao _config.yml

Na lista de includes no seu arquivo _config.yml adicione o llms.txt. Essa lista tem todos os arquivos que devem ser servidos com seu site uma vez que o build seja feito. A minha ficava assim antes:

# Include list
include: [.well-known, EnJtResume.pdf, folium]

E agora também tem o llms.txt no final do array:

# Include list
include: [.well-known, EnJtResume.pdf, folium, llms.txt]

Testando suas alterações

Antes de fazer o deploy das suas alterações, é uma boa ideia testá-las localmente:

Faça o build do seu site localmente:
```
bundle exec jekyll build
```
Sirva seu site:
```
bundle exec jekyll serve
```
Verifique seu arquivo llms.txt: Uma vez que seu site esteja rodando (geralmente em http://localhost:4000), navegue para http://localhost:4000/llms.txt para ver seu arquivo gerado.

Você deve ver um arquivo de texto puro com as informações do seu site e uma lista de todos os seus posts do blog com links para seu conteúdo Markdown raw no GitHub. Se tudo estiver funcionando, chegou a hora de fazer o deploy!

Recapitulando

Criar um arquivo llms.txt para seu site Jekyll é um processo simples de três passos:

Criar o arquivo: Adicione llms.txt ao diretório raiz do seu Jekyll com o template Liquid
Configurar o Jekyll: Adicione llms.txt à lista include no seu _config.yml
Buildar e fazer deploy: Seu arquivo estará disponível em seusite.com/llms.txt

Essa abordagem mantém automaticamente seu arquivo llms.txt atualizado conforme você adiciona novos posts do blog, e fornece aos sistemas de IA acesso direto ao seu conteúdo em seu formato Markdown original. É uma ótima forma de tornar seu blog Jekyll mais acessível para o ecossistema crescente de ferramentas e serviços de IA.

A melhor parte? Uma vez configurado, não requer manutenção alguma: o Jekyll cuida de tudo automaticamente quando você fizer um novo build do seu site!

Configure a Local Python MCP Server in VS Code

Sun, 31 Aug 2025 04:00:00 +0000

MCP (Model Context Protocol) servers extend AI assistants with custom capabilities and resource access. While using an MCP server in Claude Desktop is fantastic for general research and content discovery, there’s even more value in integrating these same tools directly into your development environment.

Since I write my blog posts in Markdown and manage them through GitHub, having the MCP server available right in VS Code means I can search for related content, fact-check references, and maintain consistency without leaving my editor.

So let’s also configure our MCP in an IDE to improve our writing and editing process.

Recap

In a previous blog post we created an MCP server with two tools:

search_posts: searches through blog posts using SerpAPI to find content matching a specific query
get_post_content: retrieves the full markdown content of a specific blog post by title

This blog search and content retrieval MCP allows us to use our AI assistant to quickly find and access information from our blog, making it easier to reference previous work and maintain consistency across posts.

In that previous post, we built a Python MCP server that leverages SerpAPI for site-specific searches and uses the llms.txt standard to index and retrieve full post content. The server enables seamless integration between AI assistants and blog content, turning your blog into a searchable knowledge base.

If you want to learn more about tool calling checkout the video below or this blog post.

MCP Servers in VS Code

If you navigate to the Extensions tab in VS Code, you’ll see a dedicated section for MCP servers. This integration brings the power of Model Context Protocol directly into your development environment, allowing you to leverage custom tools and capabilities while coding, writing, or managing your projects.

The MCP extension for VS Code automatically detects configured servers and provides a seamless interface for interacting with them through GitHub Copilot Chat. This means you can access your custom tools without leaving your editor, making your workflow more efficient and integrated.

Prerequisites

Before we begin, make sure you have:

Python 3.8+ installed on your system
uv package manager (installation guide)
VS Code with the GitHub Copilot extension enabled
A SerpAPI key for search functionality (get one here)

Set Up Your Local Server

Before configuring the MCP server in VS Code, you’ll need to set up the project locally. Here are the steps:

Clone the repository:

git clone https://github.com/jtemporal/blog-search-mcp-in-python.git
cd blog-search-mcp-in-python

Install dependencies using uv:
```
uv sync
```
Configure your environment: Create a .config file based on the .config.example with your SerpAPI key and blog URL.
Test the server:
```
uv run src/server.py
```

Once your server is working locally, you’re ready to integrate it with VS Code.

Adding the MCP Configuration

To add your MCP server to VS Code, press Cmd+Shift+P (Mac) or Ctrl+Shift+P (Windows/Linux) to open the command palette, then type “MCP” and select “MCP: Add Server” from the list. This will launch the MCP configuration wizard.

The first step is to choose the transport layer. For our local Python server, select “stdio” as the transport method. This allows VS Code to communicate with your server through standard input/output streams.

Adding the Command to Run Your MCP

Next, you’ll need to specify the command that VS Code should use to start your MCP server. Since our server has external dependencies (SerpAPI), we need to include them in the command.

Note: The exact path to uv may vary depending on your installation method. If you installed via pip, it might be in a different location. You can find your uv path by running which uv in your terminal.

~/.local/bin/uv run --with google-search-results --with mcp[cli] mcp run ~/path/to/repository/blog-search-mcp-in-python/src/server.py

Make sure to replace ~/path/to/repository/blog-search-mcp-in-python/ with the actual path to your cloned repository.

After entering the command, give your MCP server a descriptive name that will help you identify it in the VS Code interface.

Define Where the Configuration Should Be Applied

VS Code will ask you where to save the MCP configuration. You can choose between applying it globally (for all workspaces) or just for the current workspace.

Following the principle of least privilege, it’s recommended to pick “Workspace” instead of global. This keeps the configuration scoped to your current project and prevents potential conflicts with other projects.

This will create a .vscode/ folder if it doesn’t already exist in your repository, and create a corresponding mcp.json file with the configuration. It should look something like this:

{
	"servers": {
		"jtemporal-blog-search": {
			"type": "stdio",
			"command": "~/.local/bin/uv",
			"args": [
				"run",
				"--with",
				"google-search-results",
				"--with",
				"mcp[cli]",
				"mcp",
				"run",
				"~/projects/blog-search-mcp-in-python/src/server.py"
			]
		}
	},
	"inputs": []
}

Taking MCP Action Directly from mcp.json

Once configured, not only will you see the configuration file, but VS Code will also show you an inline menu within the file. This provides quick access to common MCP server operations.

If you select the More... button on the inline menu, you’ll see additional options in a dialog menu that provides more advanced operations for managing your MCP server.

Debugging Tips

If you select “Show output” from the MCP server menu, you’ll be taken to the log output in the lower panel of the VS Code window. This is invaluable for debugging issues with your MCP server.

The logs will show you detailed information about server startup, tool calls, and any errors that occur. This is particularly useful when developing or troubleshooting your MCP server.

If you improperly configure your server (for example, if you forget part of the --with flags in the command), you’ll see an error message directly in the configuration file interface:

These inline error messages make it easy to spot and fix configuration issues without having to dig through log files.

With that said, if you don’t know what the error is, you can also access the log files by going to the lower panel in the Output tab and selecting the name of the server in the dropdown menu:

Finding Your MCP Server

Now go back to the Extensions tab and you should see your MCP server listed in the MCP servers section like this:

From here, you can investigate the details of the server, view its available tools, and even adjust its configuration if necessary. This provides a centralized location to manage all your MCP servers within VS Code.

Using Your MCP Server

All of this setup work is great, but the real goal is to be able to search your blog content in a chat scenario right within VS Code. Let’s put our MCP server to work by doing a search through GitHub Copilot Chat:

The interface shows the tool it’s intending to call (search_posts) as well as the input parameters—in this case, the topic we want to find blog posts about. This transparency helps you understand exactly what the AI is doing on your behalf.

Now here’s a neat trick: normally you’d have to ask for the content after you get the results from the first tool call, but if you’re using GitHub Copilot in agent mode, the agent is actually smart enough to offer the execution of additional tools to obtain the full content:

This time it shows the get_post_content function being called, complete with the docstring description and the input parameters for retrieving the specific content.

Finally, the results are displayed in the chat just like any other tool interaction would be:

This seamless integration means you can search your blog, retrieve content, and incorporate it into your current work without ever leaving VS Code.

Security Considerations

When running local MCP servers, keep these security best practices in mind:

Workspace-level configuration: Always choose workspace-level over global configuration to limit exposure
Review dependencies: Ensure you trust all packages and dependencies your MCP server uses
Network access: Be aware that MCP servers can make network requests (like our SerpAPI calls)
File access: MCP servers have access to files within their configured scope

Learnings

Having your MCP server integrated directly in your development environment creates a streamlined workflow where you can search, reference, and incorporate your existing content without context switching. This is particularly valuable for content creators, technical writers, and developers who need to maintain consistency across their work.

No matter what IDE you’re using, remember these steps:

Local Setup: clone your MCP server repository and ensure all dependencies are properly installed using uv sync
Configuration: use the VS Code MCP extension to configure your server with the proper command, including all necessary flags and dependencies
Scope Management: choose workspace-level configuration over global to follow security best practices
Debugging: leverage the built-in logging and error reporting features to troubleshoot issues

The combination of custom MCP server with GitHub Copilot in agent mode will help you maintain your flow state which as developers is all we really want.

Now I just need to figure out the best approach to have this server without having to clone a repo and set it up manually, but that will happen on a later blog post.

How to create an llms.txt file in Jekyll and GitHub Pages

Fri, 29 Aug 2025 04:00:00 +0000

Have you ever wanted to make your blog content more accessible to AI systems and large language models? Or maybe you’ve wondered how to provide a clean, machine-readable version of your posts without the HTML clutter?

The llms.txt is the solution. It provides a standardized way for websites to expose their content to AI systems. And if you’re using Jekyll with GitHub Pages, you can create this file automatically with just a few lines of Liquid templating.

If you’re new to Jekyll, it’s a static site generator written in Ruby that’s perfect for blogs specially when used in GitHub Pages. You can learn more about Jekyll and how to get started in this other post: Publishing a website with Jekyll.

What is llms.txt

The llms.txt file is a simple text format designed to make websites more accessible to AI systems and large language models (LLMs). Based on the specification at llmstxt.org, it provides a standardized way to expose your site’s content in a machine-readable format.

The basic structure includes:

A brief description of your site
Key information about your projects, services, or content
Links to important pages or content
Any other information you’d like AI systems to know about your site

For a Jekyll blog, this is perfect for providing LLMs with direct access to your blog posts in their original Markdown format, making it easier for AI to understand and reference your content accurately.

Create an llms.txt

Creating an llms.txt file for your Jekyll site is straightforward. You’ll create a new file in the root of your Jekyll project that uses Liquid templating to automatically generate the content.

Here’s how to set it up step-by-step:

Create the file: In your Jekyll root directory, create a new file called llms.txt
Add the template: Use the following template as your starting point:

---
layout: null
---

# LLM Feed for jtemporal.com
_Generated: {{ site.time | date_to_rfc822 }}_


## All posts
The links below take you to the raw Markdown content.

{% for post in site.posts %}- [{{ post.title }}](https://raw.githubusercontent.com/jtemporal/jtemporal.github.io/refs/heads/main/{{ post.path }})
{% endfor %}

Some things to pay attention:

layout: null ensures the file is output as plain text, not HTML
{{ site.time | date_to_rfc822 }} adds a timestamp showing when the file was last generated
The loop {% for post in site.posts %} automatically creates a list of all your blog posts
{{ post.path }} gives the relative path to each post’s Markdown file
The GitHub raw URL format allows direct access to the source Markdown

Here’s what the generated file looks like on my site:

Add to _config.yml

Look for the includes list on your _config.yml file, that list has all files that should be served with your website once it is built. Mine looked like this before:

# Include list
include: [.well-known, EnJtResume.pdf, folium]

And now it also has the llms.txt at the end of the array:

# Include list
include: [.well-known, EnJtResume.pdf, folium, llms.txt]

Test your changes

Before deploying your changes, it’s a good idea to test them locally. Here’s how:

Build your site locally:
```
bundle exec jekyll build
```
Serve your site:
```
bundle exec jekyll serve
```
Check your llms.txt file: Once your site is running (usually at http://localhost:4000), navigate to http://localhost:4000/llms.txt to see your generated file.

You should see a plain text file with your site information and a list of all your blog posts with links to their raw Markdown content on GitHub. If everything looks good, you’re ready to deploy!

Recap

Creating an llms.txt file for your Jekyll site is a painless three-step process:

Create the file: Add llms.txt to your Jekyll root directory with the Liquid template
Configure Jekyll: Add llms.txt to the include list in your _config.yml
Build and deploy: Your file will be available at yoursite.com/llms.txt

This approach automatically keeps your llms.txt file up-to-date as you add new blog posts, and provides AI systems with direct access to your content in its original Markdown format. It’s a great way to make your Jekyll blog more accessible to the growing ecosystem of AI tools and services.

The best part? Once set up, it requires zero maintenance: Jekyll handles everything automatically when you build your site!

How to Build a Python MCP Server to Consult a Knowledge Base

Thu, 28 Aug 2025 04:00:00 +0000

Model Context Protocol (MCP) Spec Updates from June 2025: One Small Step for a Spec, One Giant Leap for Security

Thu, 26 Jun 2025 04:00:00 +0000

Creating a Travel Diary With Django

Sat, 05 Apr 2025 04:00:00 +0000

You started learning Django by creating a blog from the DG tutorial at a Django Girls event near you. This is the first python event you’ve been to and you fell in love with both the language and the community. Now you have your first application you want to learn how to do more and improve your skills.

This blog post narrates the process of implementing an interactive map and how to embed said map into Django website. You’ll learn how to create relationships between tables through foreign keys. You’ll also learn how to filter objects in the database using the Django ORM and create specific pages to show the filtered objects.

Note: You can also skip ahead to the section Storing Spacial Data if you already have the blog from Django Girls tutorial.

The code shown on this tutorial is also available in this GitHub repository.

Putting together the Django Girls Tutorial blog

You can go to the Django Girls Tutorial here to learn in more detail how to put together the blog but below you’ll see the steps I’ve taken with some minor edits of my own for simplicity sake.

Getting started: Set Up

Creating the python environment, installing Django, and creating the blog app:

python -m venv .env
source .env/bin/activate# On Windows: .env\Scripts\activate
pip install django
django-admin startproject travel_diaries .
python manage.py startapp blog

The first thing to note is that by default Django uses SQLite as the default database, you can check that by looking in travel_diaries/settings.py and looking for the DATABASES variable and you should see something like this:

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.sqlite3",
        "NAME": BASE_DIR / "db.sqlite3",
    }
}

After creating the blog app you should add it to the INSTALLED_APPS list in travel_diaries/settings.py:

INSTALLED_APPS = [
    # ...
    'blog',
]

I also updated the timezone and the language settings in the same file:

LANGUAGE_CODE = "en-ca"

TIME_ZONE = "America/Toronto"

Creating Superusers

One last thing to do before running the app: creating a user with admin powers.

To do so, you need to run the migrations already created by default when you start your project. This creates the basic structure Django needs to create users for accessing the /admin, is through the /admin that you can create blog posts.

python manage.py migrate
python manage.py createsuperuser

Then run the server:

python manage.py runserver

Now you can also access the admin page and login at http://127.0.0.1:8000/admin.

Modeling a Post

The only thing you can do at this point is manage and create users. Let’s change that.

For the purpose of this tutorial you’ll only have one user that is you, and you’ll be the author of the blog posts, so let’s move on to modeling a post. First create the blog app:

python manage.py startapp blog

Then add the following to blog/models.py

from django.db import models
from django.conf import settings
from django.utils import timezone

class Post(models.Model):
    author = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.PROTECT)
    title = models.CharField(max_length=200)
    content = models.TextField()
    created_at = models.DateTimeField(default=timezone.now)
    published_date = models.DateTimeField(blank=True, null=True)

    def publish(self):
        self.published_date = timezone.now()
        self.save()

    def __str__(self):
        return self.title

Note that, differently from the Django Girls Tutorial, here we are protecting authors upon deletion of blog posts by using on_delete=models.Protect, this avoids the author being deleted when a blog post is deleted.

Then remember to register your new model in the admin so you can see it in /admin and be able to create blog posts, to do so open blog/admin.py and update the file like so:

from django.contrib import admin
from .models import Post

admin.site.register(Post)

If you have the /admin page open just refresh it and you should see your Post model in there, if not run your server and login to see it.

Creating Posts

Before you can actually create a post you need to create the corresponding tables on the database, do that by running the two commands below:

python manage.py makemigrations
python manage.py migrate

The makemigrations command creates scripts to update the database called migrations, since this is a new model, the script will create a new table to store the data for each new post. Then the migrate command actually run the migrations and creates the tables and other updates.

Through the /admin interface you should be able to create your blog posts. Take some time to add a couple so you can have some data, this will be used later too.

Listing Blog Posts in a Page

Time to create HTML and CSS files so we can list our posts and render the posts beautifully.

Inside your blog/ folder, create a templates/ folder and then a blog/ folder inside templates;

Now create a base.html with the following code:

 {% load static %}
 <!DOCTYPE html>
 <head>
   <title>{% block title %}Travel Diaries{% endblock %}</title>
   <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css" integrity="sha384-QWTKZyjpPEjISv5WaRU9OFeRpok6YctnYmDr5pNlyT2bRjXh0JMhjY6hW+ALEwIH" crossorigin="anonymous">
   <link rel="stylesheet" href="{% static 'css/blog.css' %}">
 </head>
 <body>
   <header class="page-header">
   <div class="container">
     <h1><a href="/">Travel Diaries</a></h1>
   </div>
   </header><br><br>
   <main class="container">
     <div class="row">
       <div class="col">
       {% block content %}
       {% endblock %}
       </div>
     </div>
   </main>
 </body>
 </html>

This base template will hold all the bits of HTML you can reuse across all other pages that extend it.

Create also a post_list.html like so:

 {% extends 'blog/base.html' %}
    
 {% block content %}
   {% for post in posts %}
     <article>
       <h2><a href="{% url 'post_detail' pk=post.pk %}">{{ post.title }}</a> <small> • <time>published: {{ post.published_date }}</time></small></h2>
     </article>
   {% endfor %}
 {% endblock %}

Note: This post list is a bit different from that on the Django Girls tutorial as it only displays the Post title and publishing date.

And finally post_detail.html:

    
 {% extends 'blog/base.html' %}
    
 {% block content %}
   <article>
     <h2>{{ post.title }}</h2>
     <small><time>published: {{ post.published_date }}</time></small>
     <br><br>
   <p>{{ post.content | safe | linebreaks }}</p>
   </article>
 {% endblock %}
    

Note: This post detail is also a bit different from that on the Django Girls tutorial as it not only displays the Post content but also allow for rendering HTMLs that might be part of the post like the embedded code for a YouTube video for example.

Now you may have noticed the usage of a CSS file in the base.html, but you currently don’t have that file, so let’s us create it, create a static/ folder inside your blog app folder and in it a css/ folder containing a blog.css file with the following content:
```
 h1 a, h2 a {
     color: #c175ff;
 }
```
Make sure to change the color you see there as a hex code to one of your liking.
Now you need a view or better views to use these amazing templates. So update blog/views.py to this:
```
 from django.shortcuts import render, get_object_or_404
 from django.utils import timezone
 from .models import Post
    
 def post_list(request):
     posts = Post.objects.filter(published_date__lte=timezone.now()).order_by('-published_date')
     return render(request, 'blog/post_list.html', {"posts": posts})
    
 def post_detail(request, pk):
     post = get_object_or_404(Post, pk=pk)
     return render(request, 'blog/post_detail.html', {"post": post})
```
The post_list function will grab all posts you have order them by the publish date putting the most recent blog post first in the posts. This filter returns a QuerySet that gets injected into the page when the render() is called. You can think of this QuerySet as a list resulting of filtering the posts in the database.

The post_detail function on the other hand, is responsible for rendering a given post in its own page, it finds the post if it exists using its primary key and injects that through the render function.
To make use of the HTMLs and Views you need to update the URLs so your application know how to render the blog pages, so create the urls.py file within your blog app and update the blog/urls.py like this:
```
 from django.urls import path
 from . import views
    
 urlpatterns = [
     path('', views.post_list, name='post_list'),
     path('post/<int:pk>', views.post_detail, name='post_detail'),
 ]
```
The first pattern uses the post_list.html and corresponding homonyms view to render the list of posts while the second is responsible for generating a page for each individual post. Note that the post URL for an individual post follows a pattern like post/1 where the 1 is the primary key of a post in the database.

An improvement for a later date is to use the post slug for generating the URL as opposed to the primary key.

Now you can see a post like this:

Storing Spacial Data

Up until now it you had a recap of the Django Girls Tutorial with some tiny differences. If you want more details you can find it in the Django Girls Tutorial.

But let’s move to the fun parts! First things first, we need to make a decision: should you store the location as part of the post model itself or should you create a separate object to store the information? And if you separate things in different models, should you keep things in the same app or put things in a separate app entirely?

To facilitate re-usability, since you can have more than one blog post for a given location, maybe a place you visit quite often, is better to separate the location as its own model.

With the same mindset, we should be able to keep each module as specific to the part of the application it contains, it is a good practice to separate responsibilities into different apps, having a separate app also allows you to re-use this code in other projects, so that’s what we’ll do in this blog post.

Creating Map App

The app to hold the locations will be named Map and will host all logic for locations and the map generation. Splitting this allow you for example to reutilize the code at other applications with little refactor, and also for the map to exist almost independently from your blog. Let’s create a new app:

python manage.py startapp map

Then add that to your application by updating the travel_diaries/settings.py:

INSTALLED_APPS = [
# ... previous installed apps
    "django.contrib.staticfiles",
    "blog",
    "map",
]

Modeling a Location

In order to show locations both on the blog and on the map you need to be able store them so we need a model, update map/models.py like so:

from django.db import models

class Location(models.Model):
    name = models.CharField(max_length=100)
    latitude = models.DecimalField(max_digits=12, decimal_places=8, blank=True, null=True)
    longitude = models.DecimalField(max_digits=12, decimal_places=8, blank=True, null=True)

    def __str__(self):
        return self.name

Put simply a Location has a name and the coordinates to find it in a map (latitude and longitude).

Since you now have a model is a good time to create the corresponding table on your database, run:

python manage.py makemigrations
python manage.py migrate

Creating a Map

Now that you have a model you need to both add a view for it, and add it to the admin so you can create new locations. Let’s start with the basics: creating the view. Go to the map/views.py and add the following code:

import folium
from django.http import HttpResponse
from .models import Location

def map_page(request):
    center = (13.133932434766733, 16.103938729508073)
    folium_map = folium.Map(location=center, zoom_start=2)
    return HttpResponse(folium_map.get_root().render())

Let’s breakdown what is happening:

folium: is a library to that allows you to create maps in Python with Leafleet.js, you can check out the Folium documentation here or this other blog post I wrote to learn the Folium basics (translated with the help of Google from Portuguese - for now );
folium.Map: creates a map of the world far enough to see most of the world map;
folium_map.get_root().render(): exports the created map into an HTML as a string that can be passed to the view.

After updating the map/views.py install Folium like this:

pip install folium

Define the URL patterns for map app in the map/urls.py like this:

from django.urls import path
from . import views

urlpatterns = [
    path('', views.map_page, name='map'),
]

And add the map app to the application URLs in the travel_diaries/urls.py like this:

# ... pre-existing imports

urlpatterns = [
    path("admin/", admin.site.urls),
    path("", include("blog.urls")),
    path("map/", include("map.urls")),  # 👈 added code
]

With these alterations every time someone access /map endpoint on your site they will see the map created.

Double check your work: access http://127.0.0.1:8000/map to see the blank map.

That’s cool but too “basic” so let’s add some locations and pins to our map.

Creating Locations

Now that you have a view and a model make sure to register the model on the map/admin.py file in order to see locations in the admin UI:

from django.contrib import admin
from .models import Location

admin.site.register(Location)

If your server is running, refresh your page to see the update, if not, run your server and login to the admin panel in order to create locations.

Make sure to add a few that would correspond to each of your blog posts.

Adding Locations to Blog Posts

Now since you want to associate each blog post to a given location we need to adjust the blog post model and make some improvements to the HTML templates.

Let’s begin by updating the Post model in the blog/models.py you’ll add a new field called location and it will be a ForeignKey. This will create a link between your post in the Post table and location that exists in the Location table.

Since you want to be able to create blog posts that aren’t tied to a location, you’ll also want to make this field optional by using the parameters blank and null. This will also help since you want to put a default location or have to implement your own migration in order to fill the field in the database.

# other imports omitted
from map.models import Location  # 👈 new import

class Post(models.Model):
    # other fields omitted
    published_date = models.DateTimeField(blank=True, null=True)
    # 👇 new code
    location = models.ForeignKey(
        Location, related_name='place',
        blank=True, null=True,  # allow for blog posts without location
        on_delete=models.PROTECT  # keep location if a blog post gets deleted
    )
    # 👆 new code
    # omitted pre-existing code

Okay now let’s update the templates, start with the post_detail.html. Add the following after the closing </time> tag in the HTML:

{% if post.location %} • {{ post.location }}{% endif %}

This will render the location of a post in the post page if that blog post has a location filled in. Since the location is part of the post object as foreign key, you can still access it through the post object we pass in the render function of the post detail view.

Make sure to add some locations through the admin page and update the blog posts to have locations

Linking The Map in the Main Page

While you are editing templates might be a good time to link the Map in the footer of the base template. Open the base.html and add the code below after the closing of the </main> tag:

    <footer class="page-footer">
        <div class="container">
            <br>
            <p><a href="/map"> Map </a></p>
        </div>
    </footer>

Finally, you may have noticed that this hyperlink is rendering in that awful blue color so update the CSS file so that this hyper link also renders in your chosen color, replace the content of blog/static/css/blog.css with this:

h1 a, h2 a, p a {
    color: #c175ff;
}

This way you can see your map with the same color setting for all other links in your page like this:

Showing Locations on a Map

Okay now that you have locations you should be able to see them in the map, right? Wrong! Our map has no information to display yet, to change that you need to update the map view. Add this code to it:

# other imports omitted
from django.http import HttpResponse
from .models import Location

def map_page(request):
    center = (13.133932434766733, 16.103938729508073)
    folium_map = folium.Map(location=center, zoom_start=2)
    # 👇 new code
    locations = Location.objects.all()
    for location in locations:
        popup = f"{location.name}"
        folium.Marker(
            location=[location.latitude, location.longitude],
            popup=popup
        ).add_to(folium_map)
    # 👆 new code
    return HttpResponse(folium_map.get_root().render())

This extra code does the following:

Queries all the locations in the database with Location.objects.all();
Then iterates over the QuerySet of locations to add a folium.Marker using the name and coordinates for each location.

After adding some locations you should be able to access http://127.0.0.1:8000/map and see a map with the locations you created with their corresponding pins.

Creating Location Pages

Now this is all fun, let’s make it more complete. One fun thing to do using views is to generate pages based on the data you have stored in the database. So let’s create a new view to get a list of posts for a given location, add the code below on map/views.py:

# other imports omitted
from django.utils import timezone
from blog.models import Post

# other views omitted

def post_list_by_location(request, name):
    location = Location.objects.get(name__iexact=name)

    posts = Post.objects.filter(
        location=location, published_date__lte=timezone.now()
    ).order_by('-published_date')

    return render(
        request, 'map/post_list_by_location.html',
        {"posts": posts, "location": location}
    )

Lets breakdown the code:

Location.objects.get(name__iexact=name): filters location based on the name without caring for capitalization;
Then we get all the posts using Post.objects.filter passing the location from the previous step;
Finally we pass the posts and the location to the page rendered by the template map/post_list_by_location.html.

Speaking of template, now that we have a new view that actually uses templates create the templates folder to host the HTML that will be used by this view like this:

mkdir -p map/templates/map/

Then create a new template in the map/templates/map/ folder named post_list_by_location.html:

{% extends 'blog/base.html' %}

{% block content %}
    <h2>Posts in {{ location }}</h2><br>

    {% for post in posts %}
      <article>
        <h2><a href="{% url 'post_detail' pk=post.pk %}">{{ post.title }}</a> <small> • <time>published: {{ post.published_date }}</time></small></h2>
      </article>
    {% endfor %}
{% endblock %}

And to you can see the pages add the new URL patterns in map/urls.py:

# imports omitted

urlpatterns = [
    path('', views.map_page, name='map'),
    path('<name>', views.post_list_by_location),  # 👈 new code
]

The <name> ensures the part of the URL path that will contain the name of the location will be passed along to the view: for example accessing http://127.0.0.1:8000/map/london will render the corresponding London page with the collection of posts related to London.

Linking Location Pages in the Map

One final thing: might be fun to add a tiny preview map of the location on the page so lets update the view:

# pre-existing code
def post_list_by_location(request, name):
    location = Location.objects.get(name__iexact=name)

    # 👇 new code
    folium_map = folium.Map(
        location=[location.latitude, location.longitude],
        zoom_start=4, width=400, height=300
    )
    folium.Marker(
            location=[location.latitude, location.longitude],
            popup=location.name
        ).add_to(folium_map)

    location_map = folium_map._repr_html_()
    # 👆 new code

    posts = Post.objects.filter(
        location=location, published_date__lte=timezone.now()
    ).order_by('-published_date')

    return render(
        request, 'map/post_list_by_location.html',
        # 👇 updated code
        {"posts": posts, "location": location, "location_map": location_map}
        # 👆 updated code
    )

folium.Map: creates a map;
folium.Marker: adds the pin to map;
folium_map._repr_html_(): generates the HTML for the map;
then finally, "location_map": location_map we pass the HTML map to be injected into the page.

And now update the template HTML file map/templates/map/post_list_by_location.html like so:

{% extends 'blog/base.html' %}

{% block content %}
    <h2>Posts in {{ location }}</h2><br>
    <!-- 👇 new code -->
    <div class="row" style="width:50%">
        <center>
            {{ location_map | safe }}
        </center>
    </div><br>
    <!-- 👆 new code -->
    {% for post in posts %}
        <article>
            <h2><a href="{% url 'post_detail' pk=post.pk %}">{{ post.title }}</a> <small> • <time>published: {{ post.published_date }}</time></small></h2>
        </article>
    {% endfor %}
{% endblock %}

This update then render the map as a part of the page:

Now we need to add a link to this pages somewhere right? So let’s use our Map. Update the view that generate the markers on the map map/views.py like so:

def map_page(request):
    center = (13.133932434766733, 16.103938729508073)
    folium_map = folium.Map(location=center, zoom_start=2)
    locations = Location.objects.all()
    for location in locations:
        # 👇 updated code
        popup = f"""
        <a href="/map/{location.name}">{location.name}</a>
        """
        # 👆 updated code
        folium.Marker(
            location=[location.latitude, location.longitude],
            popup=popup
        ).add_to(folium_map)
    folium_map.save("map/templates/map/map.html")
    return render(request, "map/map.html")

And that is it, you are good to go! Go checkout the /map page and try clicking on the name of one of your locations:

Recap

Wow, that was a lot! You learned or remembered how to create a blog in the style of the Django Girls tutorial with some tiny differences to make the experience more personalized. Then you got to have fun and learn how to use Folium to generate maps and embed those maps in pages on your page.

On the Django side you saw how to use foreign keys to link your posts to locations and how filter posts based on the relationship they had with that location. And then you saw how to create specific pages with the filtered list of posts.

I hope you had as much fun reading as I had writing this, if you read until here I’d love to hear/read your questions so send me a message on Bluesky.

Before you go if you want to think of next steps for you to stretch your skills I recommend you trying both saving the map once a new location is added this way you can just render the map as opposed to querying the the database every time /map is accessed and creating a 404 page in case some tries to access locations that don’t exist.

Once again, the code shown on this tutorial is also available in this GitHub repository.

See ya on the next one.

RAG and Access Control: Where Do You Start?

Tue, 21 Jan 2025 04:00:00 +0000

Device Flow: Login em Dispositivos com Restrição de Entrada

Fri, 06 Dec 2024 03:00:00 +0000

Você já ouviu falar do fluxo de autorização de dispositivo (device flow)? Pode ser que você não tenha ouvido falar, mas é bem provável que você já tenha usado.

O device flow permite que você faça login em seus aplicativos em dispositivos com restrição de entrada, pense em dispositivos IoT ou smart TVs, por exemplo.

Ótimas aplicações permitem que o usuário continue o processo de login em um dispositivo mais confortável, ao invés de usar por exemplo o teclado virtual em uma SmartTV.

Se você está desenvolvendo aplicações que precisam desse tipo de conectividade, assista essa palestra para aprender o que é o fluxo de dispositivo, como ele funciona e, melhor ainda, vê-lo funcionando em uma aplicação que integra Python (usando FastAPI) e MicroPython.

Slides.

Code.

Assista:

FastAPI Authentication by Example

Thu, 05 Dec 2024 04:00:00 +0000

Apple Intelligence Clean Up: removendo objetos de fotos no iPhone

Sat, 09 Nov 2024 05:00:00 +0000

Estas duas fotos são a mesma foto.

Não acredita em mim? Eu sei, eu sei. À primeira vista, você pode pensar “uma foto é uma mesa com coisas de crochê e a outra é uma mesa vazia, não tem como serem a mesma foto”, mas a sua curiosidade pode começar a te incomodar e você passa a notar algumas coisas estranhas na segunda foto. Algumas sombras esquisitas e algumas linhas muito retas, quase retas demais, nos veios da madeira.

Bem, a resposta é que eu tirei a primeira foto e usei a Apple Intelligence para “limpar a mesa” com a funcionalidade “Clean Up” (limpar) dentro do aplicativo Photos. Continue lendo para saber um pouco mais sobre essa nova funcionalidade.

Apple Intelligence

Do meu ponto de vista, a Apple Intelligence é o aprendizado de máquina (machine learning ou ML) da Apple. Com o avanço da inteligência artificial (IA) e dos grandes modelos de linguagem (large language models ou LLMs), a Apple tinha resistido a usar a sigla “IA” e se mantinha usando aprendizado de máquina sempre que tinha alguma funcionalidade alimentada por algum tipo de algoritmo sequer parecido com IA.

Em uma jogada muito Apple, a empresa lançou a “Apple Intelligence”, e renomeou a IA que todos conhecemos para algo novo.

Sim, Apple, todos percebemos que você fez.

Agora com a Apple Intelligence, eles podem usar a sigla mais livremente. E, embora tenham lançado um novo telefone construído para IA, nenhuma funcionalidade da Apple Intelligence foi vista no iPhone 16 quando chegou às lojas em setembro de 2024.

Em outubro, com o iOS 18.1, começamos a receber algumas funcionalidades da Apple Intelligence e eu, como muitas outras pessoas, atualizei meus dispositivos Apple, o iPhone e iPad, para o iOS 18.1 para usar as primeiras funcionalidades da Apple Intelligence.

Testando Apple Intelligence no Photos

Conversando com um amigo, percebemos que ainda não tínhamos usado essas funcionalidades, então entrei em modo de aprendizado para descobrir exatamente quais eram os recursos e como eles poderiam se encaixar na minha vida.

De todas as novas funcionalidades, a que mais me chamou a atenção foi a “Clean Up” (limpeza) no aplicativo Photos.

Claro, remover objetos indesejados e até pessoas das fotos não é novidade, muitos telefones Android já têm essa funcionalidade há algum tempo, e softwares tradicionais de edição de fotos são ótimos nisso, mas este não é um post sobre os méritos de cada sistema operacional ou software de edição.

Se você me conhece, sabe que sempre tenho curiosidade sobre os limites das ferramentas e queria ver até onde eu poderia levar essa… Meu objetivo era “remover” um objeto por vez, salvar uma nova foto com o objeto removido e continuar assim até ter “uma mesa limpa”.

iPhone ou iPad?

Para as pessoas curiosas de plantão, aqui estão minhas especificações: Estou usando o iPhone 16 Pro Max com 256GB e o iPad Pro 13” M4 256GB lançado em 2024.

Começando no iPhone

Comecei pelo celular. Organizei as coisas na mesa, tirei a foto e sentei no sofá com o telefone na mão para remover o primeiro objeto.

Consegue notar a diferença? Olhe para o canto inferior direito. Parecia mágica quando, após um simples círculo, o objeto simplesmente desapareceu.

Salvei a edição, dupliquei a foto e parti para o segundo objeto: era hora de remover meu pequeno canivete no canto inferior esquerdo. Demorou um pouco mais que o primeiro para desaparecer, mas foi. No entanto, deixou uma “sombra”, então tive que circular a sombra também e esperar um pouco para que ela também sumisse.

Depois de duplicar a nova foto, o iPhone já estava oficialmente quente e começou a travar durante o processo de edição, então mudei para o iPad para continuar com a diversão.

Duas observações aqui:

Primeiro, quando o iPhone 16 foi lançado, a Apple disse que este iPhone foi construído para IA, mas este pequeno teste que fiz sugere que o iPhone 17 pode ser melhor nisso,
segundo, que duplicar fotos também salva todas as edições da foto anterior como uma edição, então você pode reverter uma foto duplicada de volta ao original, por exemplo.

Com isso em mente, eu simpatizo com as pessoas com iPhone 15 que vão querer usar este recurso extensivamente e espero que a Apple lance atualizações no futuro para resolver isso e alguns outros comportamentos estranhos que você verá abaixo.

Continuando no iPad

Considerando tudo, foi super divertido simplesmente circular o objeto que você quer remover, esperar alguns segundos e vê-lo fazer poof e simplesmente desaparecer.

Depois de “fazer desaparecer” um objeto, às vezes eu também tinha que lidar com algumas manchas escuras que sobravam, eu só precisava circular a área novamente para me livrar de quaisquer manchas escuras restantes (como mostrado no vídeo abaixo).

Como eu esperava, o iPad teve um desempenho melhor que o iPhone, não notei ele travando, embora a resposta da ferramenta tenha ficado mais lenta conforme fui avançando.

E quanto à temperatura, o iPad só ficou morno, mas sempre que eu chegava perto da tela podia sentir o calor emanando de leve.

Coisas estranhas começaram a acontecer

Depois que todos os objetos, exceto um, foram removidos individualmente, eu tinha um último desafio: remover o maior item de toda a foto: O livro de crochê e terminar com uma mesa vazia.

Mas o que parecia uma coisa simples depois de tudo que já tinha feito acabou sendo o momento em que as coisas estranhas começaram a acontecer. Eu me pergunto… Será que a Apple Intelligence, como qualquer outro modelo de IA, alucina?

Alucinação é um comportamento conhecido do aprendizado de máquina, especialmente em LLMs, e na minha opinião um dos mais perigosos. Uma alucinação em ML acontece quando um modelo produz uma resposta coerente, mas que é de fato incorreta.

Como não sei se podemos qualificar se a Apple Intelligence estava tendo uma alucinação aqui, especialmente porque não estamos interagindo textualmente, vou chamar tudo no reino dos resultados inesperados de “comportamento estranho”.

Apenas um “blur” para você

As duas primeiras tentativas de remover o livro não foram bem sucedidas. A ferramenta de limpeza parou de remover coisas completamente e começou a “borrar” as coisas em vez de remover objetos.

Depois de algumas tentativas fracassadas, uma delas você pode ver neste vídeo abaixo, eu finalmente consegui fazer o que queria e o livro foi removido. Note que isso exigiu um trabalho extra da minha parte, já que circular não estava tendo o resultado esperado.

Eu queria que houvesse uma maneira de dizer à ferramenta que ela fez a coisa errada e que deveria tentar novamente, como muitos LLMs baseados em texto, mas não existe tal maneira. Aqui você tem que esperar que a funcionalidade entenda o que você quer que ela faça. ¯\_(ツ)_/¯

Fantasmas de objetos

Ainda no espectro dos comportamentos estranhos, quando tentei pintar sobre a parte onde muitas das edições foram feitas anteriormente, apareceu o “recorte” dos objetos que haviam sido removidos previamente.

No final, deu tudo certo e consegui as fotos que você viu no início.

Limpeza é Cansativo, Até Mesmo Para IA

Outro detalhe importante é que essa foi uma tarefa que consumiu muita bateria. A edição em si não demorou muito, cada remoção de objeto levou apenas alguns segundos.

No entanto, eu podia ver a porcentagem da bateria diminuindo constantemente. Acredito que desde que comecei o processo de edição no iPad e até terminar, essa funcionalidae consumiu cerca de 20% da bateria disponível.

Já fiz algumas tarefas intensivas no iPad antes, como editar vídeos e desenhar digitalmente com várias camadas, mas nada chegou perto disso.

Também notei que o consumo começou a aumentar quanto mais edições eu acumulava em uma foto. Então, definitivamente não recomendaria usar isso quando depender apenas da bateria e não puder carregar seus dispositivos. Caso contrário, talvez seja bom ter um powerbank como esse.

O Resultado Final

Depois de conseguir todas as minhas fotos, só faltava uma coisinha: fazer este pequeno vídeo usando “apenas uma foto”.

Eu poderia simplesmente tirar todas as fotos em metade do tempo que levei para fazer toda a “limpeza” virtual? Claro que poderia. Mas qual seria a graça disso?

Recapitulando

Se você leu até aqui, pode estar se perguntando qual é a utilidade disso tudo. Bem, imagine que você tem uma alface no meio dos dentes, mas tirando isso a foto está perfeita, agora você pode simplesmente removê-la.

Um amigo me apontou que você também poderia remover pessoas que você não gosta mais de uma foto antiga ou alguém fazendo photobomb na sua foto legal de férias.

Em resumo, o novo recurso é útil, mas é importante estar ciente de suas limitações e peculiaridades, bem como do consumo de bateria.

Obrigada por ler.

Esse post contém links afiliados.

Apple Intelligence Clean Up: removing objects from iPhone photos

Sat, 09 Nov 2024 04:00:00 +0000

These two photos are the same photo.

Don’t believe me? I know, I know. At a glance, you might think “one is a desk with things another is and empty desk there’s no way these are the same photo”. But then you might give into curiosity and start to notice a few weird things about the second. Some weird shadows and some very straight lines, almost too straight, in the wood grain.

Well the answer is that I took the first photo, and used Apple Intelligence to clean up the desk (pun not intended) with the Clean Up feature within the Photos app. Read on to know a little bit more about this new functionality.

Apple Intelligence

As I see it, Apple Intelligence is Apple’s machine learning (ML). With the advancement of artificial intelligence (AI) and large language models (LLMs), Apple had been resistant to using the acronym “AI” and stuck to machine learning whenever they had any feature powered by some sort of algorithm resembling AI.

In a very Apple move, Apple launched “Apple Intelligence”, and rebranded the AI we all know to something new.

Yes, Apple, we all saw what you did there.

Now with Apple Intelligence, they can use the acronym more freely. And although they released a new phone built for AI, no Apple Intelligence features were seen on the iPhone 16 when it hit the stores back in September 2024.

In October with iOS 18.1 we started to get a few features from Apple Intelligence and I, like many others, updated my Apple gadgets, the iPhone and iPad, to iOS 18.1 in order to use the first few features from Apple Intelligence.

Testing out AI in Photos

Talking to a friend we noticed we did not use the features yet, so I went into learning mode to figure out what the features were exactly and see how they could fit in my life.

Out of all of them, the one that caught my eye was the “Clean Up” feature in the Photos app.

Sure, removing unwanted objects and even people from photos is nothing new, many android phones have had this functionality for a while now, and traditional photo editing software are great at it, but this is not a blog post on the merits of each operating system or editing software.

If you know me, you know I’m always curious about the limitations of tools and I wanted to see how far I could push this one… My goal was to “remove” one object at a time, save a new photo with the removed object, and continue on until I had a clean desk top.

iPhone or iPad?

For the curious ones here are my specs: I’m using the iPhone 16 Pro Max with 256GB and the iPad Pro 13” M4 256GB launched in 2024.

Starting on the iPhone

I started on my phone, laid out the things on the desk, took the photo, and sat down on the couch with my phone in hand to remove the first object.

Can you spot the difference? Look at the bottom right corner. It felt like magic when after a simple circle the thing just vanished.

I saved the edit, duplicated the photo and went on to the second object: it was time to remove my tiny army knife on the bottom left. It took a little while longer than the first one for it to disappear but it go way. But it left a “shadow”, so I had to also circle the shadow and wait a little while for it also vanish.

After duplicating the new photo, the iPhone was officially a bit hot and started freeze up in the editing process, so I moved on to the iPad to continue with the fun.

Two notes here:

First, when the iPhone 16 launched, Apple said that this iPhone was built for AI, but this tiny test I did suggest that the iPhone 17 might be better at it,
second, that duplicating photos also saves up all the edits from the past photo as an edit, so you can revert a duplicated photo back to the original for example.

With these in mind I sympathize with the folks with the iPhone 15 that will want to use this feature extensively and that I hope Apple releases updates in the future to address this and some other quirky behaviors you’ll see below.

Continuing on to the iPad

All things considered, it was super fun to simply circle the object you want to remove and wait a few seconds and it go poof and just vanish.

After “vanishing” an object sometimes I also had to address some dark spots left over, I just had to circle the area again to get rid of any leftover dark spots (like shown in the video below).

As I expected, the iPad performed better than the iPhone, I didn’t notice it freezing up although the tool responsiveness got slower the further I went.

And as far as temperature goes, the iPad only got warm, but whenever I got closer to the screen I could feel the warmth emanating from the iPad.

Then Some Weirdness Happened

After all objects but one were individually removed, I had a last challenge: to remove the biggest item of the whole photo. The objective was to go from the left to the right.

But what looked like a simple thing after everything I already done turned out to be the moment when the weird things started to happen. I wonder… Does Apple Intelligence, like any other AI models, hallucinate?

Hallucination is a known behavior of machine learning, especially in LLMs, and in my opinion one of the most dangerous ones. An hallucination in ML happens when a model produce a coherent response but that is in fact incorrect.

Since I don’t know if we can qualify if Apple Intelligence was having a hallucination here, especially since we are not interacting textually, I’ll call everything in the realm of unexpected results a “weird behavior”.

Just a blur for you

The first two attempts to remove the book did not go well. The clean up tool stopped removing things all together and started to “blur” things instead of removing objects.

After a few failed attempts (one of them you can see in this video below), I finally got to it to do what I wanted to do and the book was removed. Mind you that it required some extra work on my end since circling was not doing the job.

I wish there was a way for me to tell the tool that it did the wrong thing and to try again, like many text-based LLMs, but there’s no such way. Here you have to hope the feature understands what you want it to do. ¯\_(ツ)_/¯

There used to be something here

Still on the weird behaviour spectrum, when I tried to paint over the part where a lot of the editing was done before, it showed the “crop out” of the object that was removed previously.

Eventually it worked out and I managed to get the photos you saw in the beginning.

Cleaning Up is Tiresome, Even for AI

One other tidbit of information was this was a very battery-intensive task. Editing itself didn’t take long, each object removal took only a few seconds.

However, I could see my battery percentage go down very steadily. I believe since I started the editing process in the iPad until I finished editing, this feature consumed about 20% of the battery available.

I’ve done a few intensive tasks in the iPad before like editing videos and digital drawing with multiple layering, but nothing even got close to this.

I also noticed that it started to drop faster the more I accumulated edits in a photo. So I definitely would not recommend using this while relying solely on battery and unable to charge your devices. If not maybe buy a powerbank (this is one I like).

The end result

After getting all my photos there was only one tiny thing left to do this tiny video from “only one photo”.

Could I just take the bunch of photos in half the time it took me to do all the “cleaning up”? Sure I could. But what is the fun in that?

Recap

If you read until here you may be wondering why would this be useful at all? Well imagine you have a lettuce stuck in your teeth but otherwise the photo is perfect, now you can simply remove it.

A friend pointed out to me that you could also remove people you don’t like anymore from an old photo or someone photobombing your cool vacation photo too.

In short the new feature is useful but it is important to be aware of its limitations and quirks as well as the possible battery drain.

Thanks for reading.

This post contains affiliated links.

Fazendo pull requests com GitHub Codespaces e contribuindo com um projeto open source

Tue, 29 Oct 2024 05:00:00 +0000

Existem diversas formas de fazer pull requests. Nesse blog post você vai aprender a fazer um pull request na prática usando GitHub Codespaces e fazendo um pull request pro GitFichas.

O GitFichas

O GitFichas agora é um projeto open source e nesse momento está passando por uma migração que vai trazer várias melhorias. Para isso, toda ficha existente hoje precisa ser migrada para o novo formato usando Mermaid. Como o melhor jeito de aprender é praticando esse blog post vai te mostrar como fazer tudo na prática.

Vale lembrar que os passos daqui são apenas um jeito de fazer pull requests e na verdade a única recomendação é seguir o guia de contribuição de cada projeto geralmente encontrado no arquivo CONTRIBUTING.md, presente na maioria dos projetos de código aberto, o guia de contribuição do GitFichas pode ser encontrado aqui.

GitFichas e sua estrutura

Um pouco de contexto. Pra começar a contribuir é importante aprender sobre o projeto e a sua estrutura. No caso do GitFichas, existem dois tipos de fichas: fichas de comando ou fichas de conceito.

Comando: explica um comando como “git add -p” ou “git commit --allow-empty”;
Conceito: explica conceitos relacionados ao git, versionamento e assuntos correlatos, como “pull requests” e “conflitos”;

Cada tipo de ficha tem uma coleção de campos similar, mas com campos específicos de cada tipo. Esses campos que vão ser usados pelo mermaid para gerar a visualização. Todos os campos a serem usados para fichas estão no guia de contribuição.

Falando na estrutura de pastas e arquivos do repositório, fichas em português estão na pasta _posts/ e fichas em inglês elas ficam na pasta en/_posts.

Tanto as fichas em português quanto as fichas em inglês seguem o mesmo padrão de nomes <YYYY-MM-DD>-<NUMERO>.md e a data é usada para ordenação das fichas no site enquanto o número corresponde ao número da ficha.

De resto, os arquivos seguem o padrão de blogs escritos usando Jekyll, um gerador de site estáticos feito em Ruby. Sim, o GitFichas é em essência um blog, ele usa Liquid para fazer os templates que viram as páginas que você vê no site.

Além disso vale mencionar que o site é construído e servido pelo GitHub e você consegue ver uma pré-visualização das mudanças graças ao Netlify.

Requisitos

Você vai precisar de:

Uma conta no GitHub.

Sim, só isso. Se você souber git seguir o passo a passo vai ficar mais fácil, mas se você ainda está aprendendo git você ainda vai conseguir acompanhar o passo a passo.

Por onde começar

O projeto para contribuir você já tem e você já deu uma olhada no guia de contribuição. Agora você precisa escolher uma issue no repositório do GitFichas. Escolher uma issue vai te ajudar a identificar fichas que ainda não foram migradas para o novo formato além de saber qual nome dar para o seu branch.

Aqui vou usar a ficha #050 em inglês. A migração dessa ficha está anotada na issue #116.

Com a issue escolhida podemos começar a trabalhar. Os passos são:

Fazer um fork;
Criar um novo branch;
Iniciar o Codespace;
Fazer as alterações;
Conferir as mudanças rodando o site;
Submeter o pull request.

1. Faça um fork

Crie um fork do repositório na sua conta, você pode clicar nesse link aqui ou na interface do GitHub no repositório clique no botão “Fork”.

Lembre-se de clicar em “Create” na página seguinte para criar o seu fork.

Isso vai criar uma cópia do repositório original na sua conta o que vai te permitir fazer as suas contribuições já que um fork na usa conta vai te dar plenos poderes de edição.

2. Crie um novo branch

Depois de ter um fork é sempre importante criar novos branches, um para cada contribuição. Usar branches ao invés de trabalhar direto na main vai te permitir fazer múltiplas contribuições ao mesmo tempo.

O nome do seu branch deverá seguir aquilo descrito no guia de contribuição do repositório. No caso do GitFichas o padrão a ser seguido é <nome de usuário>-<issue ou descrição>.

Como a nossa issue é a #116 e o nome do meu usuário é jesstemporal o nome do branch ficou jesstemporal-fix-116.

Para criar o branch com esse nom, você clica no seletor de branches que indica o branch atual o main e deve digitar o nome do novo branch na caixa de pesquisa, isso irá mostrar o botão de criação com o nome que você digitou como mostrado na imagem acima.

3. Inicie o seu GitHub Codespace

Codespaces são ótimos pois você consegue um ambiente completo de desenvolvimento em poucos minutos, basta ter uma conexão com a internet. Outra vantagem é que Codespaces são efêmeros e te permite ter um ambiente completamente isolado sem você precisar instalar nada na sua máquina.

Clique em <> Code e na aba Codespaces clique no botão de criação como mostrado na imagem abaixo.

Isso deve abrir uma nova aba no seu navegador. Criar um novo Codespaces pode demorar alguns segundos, mas uma vez que esteja pronto para uso você deve ver algo similar a tela abaixo.

Chegou a hora de fazer as alterações.

4. Faça as alterações

Como vamos editar a ficha #050 em inglês ela se encontra em en/_posts/2023-08-04-050.md. Ao abrir o arquivo você conseguirá ver o conteúdo atual da ficha e começar a fazer as alreações.

O jeito mais fácil para saber que alterações fazer é olhar o que existe na ficha atual e copiar o conteúdo da página aos poucos seguindo os exemplos no guia de contribuição.

A ficha #050 desenhada aparece dessa forma na página:

Composição de uma ficha

Vamos entender o que compõe uma ficha:

Titulo: Part superior da ficha. Nesse caso “Pulling changes” títulos são compostos de 3 partes:
1. Pre-título: tudo escrito antes das letras quadradas, nesse caso não existe pre-título;
2. Principal: a parte principal do título, na ficha 50 é o “Pulling”;
3. Sub-título: tudo que vem depois da parte principal nesse caso “changes”;
Comando: O comando escrito em uma fonte cursiva, (essa parte só aparece em fichas do tipo comando);
Partes: as informações que explicam cada parte do comando. As partes são divididas em dois tipos:
1. Comando: Que é o comando em si, nesse caso pull;
2. Partes: Todas as informações depois do comando nesse caso remote e branch;
Informação: parte final que adiciona mais informações sobre um comando.

Preenchendo o novo conteúdo

Como essa ficha apresenta um comando, você precisa usar o exemplo de ficha de comando do CONTRIBUTING.md e preencher as informações de acordo como mostrado abaixo:

---
layout: post
pretitle:
title: Pulling
subtitle: changes
command: git pull remote branch
descriptors:
  - command: command to \ndowload changes
  - part1: repository from where\n to download changes
  - part2: branch to download\n changes from
info: usually both the remote and the branch can be omitted
author: "@jtemporal"
number: "050"
mermaid: true
translated: "/projects/050"
permalink: "/en/050"
lang: "en"
pv:
  url: "/en/049"
  title: "#049 git merge source target"
nt:
  url: "/en/051"
  title: "#051 git commit --allow-empty"
---

{% include mermaid-graphs.html %}

Note que foi necessário alterar as variáveis title, subtitle, command, descriptors e suas sub-variáveis, info, number. E adicionar mermaid: true.

As demais variáveis layout, translated, permalink, lang, pv e sub-variáveis, nt e sub-variáveis, vão ser as existentes no arquivo original e não precisam de alteração.

Por fim, é necessário substituir o conteúdo da ficha que vem depois do front-matter e colocar {% include mermaid-graphs.html %}. Essa linha vai garantir a apresentação da renderização do conteúdo que você acabou de preencher.

Dicas na migração de fichas:

Atente para quebras de linha, para que uma ficha fique legível talvez seja necessário fazer quebras de linha diferentes daquelas vistas nas fichas originais. Você vai poder conferir isso na próxima seção.
Cada ficha tem uma tabela com a descrição das partes, use essa tabela para facilitar a sua contribuição.

5. Rode o site e confira as mudanças

Como você está usando um novo Codespace você vai precisar instalar as dependências para então rodar o site. Comece instalando as dependências:

bundle install

Em seguida rode o site:

bundle exec jekyll s

Esse comando acima vai montar o site e te permitir conferir os ajustes que você acabou de fazer.

Quando o site estiver rodando, uma pop-up vai aparecer no canto inferior esquerdo do seu Codespaces perguntando se você quer abrir a visualização do site.

Clique Open in Browser isso vai abrir uma nova aba com o site que está rodando no seu Codespace. Navegue até a ficha que você alterou para ver as mudanças.

Depois de conferir que a ficha está renderizando corretamente e que as informações estão legíveis você pode fazer o seu pull request.

Note caso você tenha dificuldades em fazer a renderização da ficha e precisar de ajuda você sempre pode abrir uma issue para pedir ajuda ou um pull request com status “WIP” e descrever o problema que está encontrando. Isso segue a boa prática de receber feedback cedo e assim ajustar as suas contribuições de acordo.

6. Faça o pull request

Agora que está tudo nos conformes chegou a hora de mandar a contribuição.

Faça o commit das mudanças

Primeiro adicione as alterações em staging:

git add en/_posts/2023-08-04-050.md

Aqui é importante adicionar apenas o arquivo alterado. E agora faça o commit:

git commit -m "Migrates card 050"

Lembre-se de alterar a mensagem entre aspas para descrever as alterações que você está fazendo.

Faça o push do branch

Com o commit feito é necessário publicar as mudanças com o push, como é a primeira vez que estamos publicando mudanças precisamos fazer o setup do branch no upstream usando a opção -u :

git push -u origin jtemporal-fix-116

Quando o push for concluído, vai aparecer um link para fazer o pull request no próprio terminal.

Clique nele e, em seguida, clique no “Yes” no pop-up que pergunta se você quer abrir o pull request dentro do Codespaces usando a extensão para pull requests e issues.

Abra o pull request e aguarde

Isso vai abrir um menu lateral esquerdo onde você pode ajustar as informações do pull request como mostrado na imagem abaixo.

Você pode por exemplo adicionar uma descrição das mudanças e conectar o seu pull request à issue que ele resolve usando as palavras mágicas. Agora é a aguardar a revisão e merge. 🎉 🎉 🎉

Revisão de pull requests

Agora essa parte não depende só de você. Depois de submeter o seu pull request a pessoa ou pessoas que mantêm o projeto precisam revisar a sua contribuição. A partir de agora as coisas acontecem na página do repositório original onde o pull request existe.

Como uma útima checagem você pode utilizar o “Deploy Preview” para ver as alterações que fez dessa vez na pre-visualização gerada pelo Netlify. Ela não deve ser diferente daquela que você viu ao rodar o site mais cedo, mas é sempre bom dar uma conferida.

Outros projetos podem ou não ter ambientes de visualização semelhantes a esse. E agora entram as pessoas que mantém o projeto para fazer a revisão da sua contribuição.

Depois de revisar, mantenedores podem pedir alterações pra você ou fazer as alterações no seu pull request para poder fazer o merge. Fica com você a responsabilidade de conferir e fazer as alterações pedidas.

Uma vez que o pull request esteja de acordo com o esperado, mantenedores vão aprovar e fazer o merge e então as alterações devem ir ao ar no próximo build do site. No caso do GitFichas isso vai acontecer de forma automática pelo GitHub.

E é isso, parabéns você acabou de fazer a sua contribuição.

Recapitulando

Na maioria dos casos seguir o conjunto de passos descrito nesse blog post vai te ajudar a fazer contribuições de qualidade, então relembrando: Depois de escolher uma issue para trabalhar e se familiarizar com o guia de contribuição do projeto você precisa seguir os passos abaixo.

Fazer um fork;
Criar um novo branch;
Iniciar o Codespace;
Fazer as alterações;
Conferir as mudanças rodando o site;
Submeter o pull request.

Então é aguardar a revisão e aprovação do pull request. Vale lembrar que com grandes poderes vêm grandes responsabilidades e qualidade é mais importante que quantidade e embora esse pull request não tenha sido com código você agora tem as ferramentas para fazer contribuições de código ou não.

Agora que você já sabe contribuir aproveita pra dar uma lida neste outro post com “5 Dicas Para Fazer o Seu Pull Request Brilhar ✨”.

Learn to make pull requests using GitHub Codespaces and contribute to open source

Tue, 29 Oct 2024 04:00:00 +0000

There are several ways to make pull requests. In this blog post, you will learn how to make a pull request in practice using GitHub Codespaces and making a pull request to GitFichas.

GitFichas

GitFichas is now an open source project and is currently undergoing a migration that will bring several improvements. For this, every existing card needs to be migrated to the new format using Mermaid. As the best way to learn is by practicing, this blog post will show you how to do everything in practice.

It’s worth remembering that the steps here are just one way to make pull requests, and the only real recommendation is to follow the contribution guide for each project, usually found in the CONTRIBUTING.md file, present in most open-source projects. The contribution guide for GitFichas can be found here.

GitFichas and its structure

A bit of context first. To start contributing, it’s important to learn about the project and its structure. In the case of GitFichas, there are two types of cards: command cards or concept cards.

Command cards: explains a command like “git add -p” or “git commit --allow-empty”;
Concept cards: explains concepts related to git, versioning, and related topics, such as “pull requests” and “conflicts”;

Each type of card has a similar collection of fields, but with specific fields for each type. These fields will be used by mermaid to generate the visualization. All the fields to be used for cards are in the contribution guide.

Speaking of the repository’s folder and file structure, cards in Portuguese are in the _posts/ folder, and cards in English are in the en/_posts folder.

Both Portuguese and English cards follow the same naming pattern <YYYY-MM-DD>-<NUMBER>.md. The date is used for ordering the cards on the site while the number corresponds to, well, the card number.

Otherwise, the files follow the pattern of blogs written using Jekyll, a static site generator made in Ruby. Yes, GitFichas is essentially a blog, it uses Liquid for templating which turns into the pages you see on the site.

Additionally, it’s worth mentioning that the site is built and served by GitHub, and you can see a preview of the changes thanks to Netlify.

Requirements

You will need:

A GitHub account.

Yes, that’s it. If you know git, following the step-by-step will be easier, but if you are still learning git, you will still be able to follow along.

Where to Start

You already have the project to contribute to, and you’ve taken a look at the contribution guide. Now you need to choose an issue in the GitFichas repository. Choosing an issue will help you identify cards that have not yet been migrated to the new format and know what name to give your branch.

Here, I will use card #050 in English. The migration of this card is noted in issue #116.

With the issue chosen, we can start working. The steps are:

Fork the repository;
Create a new branch;
Start the Codespace;
Make the changes;
Check the changes by running the site;
Submit the pull request.

1. Fork the repository

Create a fork of the repository in your account, you can click this link here or in the GitHub interface on the repository, click the “Fork” button.

Remember to click “Create” on the next page to create your fork.

This will create a copy of the original repository in your account, allowing you to make your contributions since a fork in your account will give you full editing powers.

2. Create a new branch

After forking the repository, it’s always important to create new branches, one for each contribution. Using branches instead of working directly on main will allow you to make multiple contributions at the same time.

The name of your branch should follow what is described in the repository’s contribution guide. In the case of GitFichas, the pattern to follow is <username>-<issue or description>.

Since our issue is #116 and my username is jesstemporal, the branch name will be jesstemporal-fix-116.

To create the branch with this name, click on the branch selector that indicates the current branch main and type the name of the new branch in the search box. This will show the creation button with the name you typed, as shown in the image above.

3. Start your GitHub Codespace

Codespaces are great because you can get a complete development environment in just a few minutes, as long as you have an internet connection. Another advantage is that Codespaces are ephemeral and allow you to have a completely isolated environment without needing to install anything on your machine.

Click on <> Code and in the Codespaces tab, click the creation button as shown in the image below.

This should open a new tab in your browser. Creating a new Codespace may take a few seconds, but once it’s ready for use, you should see something similar to the screen below.

It’s time to make the changes.

4. Make the changes

Since we are editing card #050 in English, it is located in en/_posts/2023-08-04-050.md. When you open the file, you will be able to see the current content of the card and start making the changes.

The easiest way to know what changes to make is to look at what exists in the current card and copy the content from the page gradually, following the examples in the contribution guide.

Card #050 appears on the page as follows:

Composition of a card

Let’s understand what makes up a card:

Title: The top part of the card. In this case, “Pulling changes” titles are composed of 3 parts:
1. Pre-title: everything written before the square letters, in this case, there is no pre-title;
2. Main: the main part of the title, in card 50 it is “Pulling”;
3. Subtitle: everything that comes after the main part, in this case, “changes”;
Command: The command written in an italic font (this part only appears in command-type cards);
Parts: the information that explains each part of the command. The parts are divided into two types:
1. Command: Which is the command itself, in this case, pull;
2. Parts: All the information after the command, in this case, remote and branch;
Information: the final part that adds more information about a command.

Filling in the new content

Since this card presents a command, you need to use the command card example from CONTRIBUTING.md and fill in the information accordingly as shown below:

---
layout: post
pretitle:
title: Pulling
subtitle: changes
command: git pull remote branch
descriptors:
  - command: command to \ndowload changes
  - part1: repository from where\n to download changes
  - part2: branch to download\n changes from
info: usually both the remote and the branch can be omitted
author: "@jtemporal"
number: "050"
mermaid: true
translated: "/projects/050"
permalink: "/en/050"
lang: "en"
pv:
  url: "/en/049"
  title: "#049 git merge source target"
nt:
  url: "/en/051"
  title: "#051 git commit --allow-empty"
---

{% include mermaid-graphs.html %}

Note that it was necessary to change the variables title, subtitle, command, descriptors and their sub-variables, info, number. And add mermaid: true.

The other variables layout, translated, permalink, lang, pv and sub-variables, nt and sub-variables, will be the ones existing in the original file and do not need to be changed.

Finally, it is necessary to replace the content of the card that comes after the front matter and place {% include mermaid-graphs.html %}. This line will ensure the rendering of the content you just filled in.

Tips for migrating cards:

Pay attention to line breaks, for a card to be readable it may be necessary to make line breaks different from those seen in the original cards. You will be able to check this in the next section.
Each card has a table with the description of the parts, use this table to facilitate your contribution.

5. Run the site and check the changes

Since you are using a new Codespace, you will need to install the dependencies before running the site. Start by installing the dependencies:

bundle install

Next, run the site:

bundle exec jekyll s

This command will build the site and allow you to check the adjustments you just made.

When the site is running, a pop-up will appear in the lower-left corner of your Codespaces asking if you want to open the site preview.

Click Open in Browser to open a new tab with the site running in your Codespace. Navigate to the card you modified to see the changes.

After confirming that the card is rendering correctly and the information is readable, you can proceed with your pull request.

Note that if you have difficulties rendering the card and need help, you can always open an issue to ask for assistance or a pull request with “WIP” status and describe the problem you are encountering. This follows the best practice of getting early feedback and adjusting your contributions accordingly.

6. Submit the pull request

Now that everything is in order, it’s time to submit your contribution.

Commit the changes

First, add the changes to staging:

git add en/_posts/2023-08-04-050.md

Here it is important to add only the modified file. And now commit:

git commit -m "Migrates card 050"

Remember to change the message between quotes to describe the changes you are making.

Push the branch

With the commit done, it is necessary to publish the changes with the push. Since this is the first time we are publishing changes, we need to set up the branch on the upstream using the -u option:

git push -u origin jtemporal-fix-116

When the push is completed, a link to create the pull request will appear in the terminal itself.

Click on it and then click “Yes” on the pop-up that asks if you want to open the pull request within Codespaces using the pull requests and issues extension.

Open the pull request and wait

This will open a left sidebar where you can adjust the pull request information as shown in the image below.

You can, for example, add a description of the changes and connect your pull request to the issue it resolves using magic words. Now you just have to wait for the review and merge. 🎉 🎉 🎉

Pull requests review

Now this part does not depend only on you. After submitting your pull request, the person or people who maintain the project need to review your contribution. From now on, things happen on the original repository page where the pull request exists.

As a final check, you can use the “Deploy Preview” to see the changes you made this time in the preview generated by Netlify. It should not be different from what you saw when running the site earlier, but it is always good to double-check.

Other projects may or may not have similar preview environments. And now the project maintainers come in to review your contribution.

After reviewing, maintainers may request changes from you or make changes to your pull request to be able to merge. It is your responsibility to check and make the requested changes.

Once the pull request meets expectations, maintainers will approve and merge it, and then the changes should go live in the next site build. In the case of GitFichas, this will happen automatically via GitHub.

And that’s it, congratulations, you just made your contribution.

Recap

In most cases, following the set of steps described in this blog post will help you make quality contributions, so to recap: After choosing an issue to work on and familiarizing yourself with the project’s contribution guide, you need to follow the steps below.

Fork the repository;
Create a new branch;
Start the Codespace;
Make the changes;
Check the changes by running the site;
Submit the pull request.

Then, wait for the review and approval of the pull request. It is worth remembering that with great power comes great responsibility, and quality is more important than quantity. Although this pull request did not involve code, you now have the tools to make code or non-code contributions.

Now that you know how to contribute, take the opportunity to read this other post with “5 Tips to Make Your Pull Request Shine ✨”.

GitFichas agora é Open Source 🎉

Fri, 25 Oct 2024 05:00:00 +0000

Isso significa que se você está procurando um projeto para contribuir, você acabou de encontrar!

O que é GitFichas?

GitFichas é uma coleção de fichas de estudo sobre git. Foi inicialmente de código fechado e mantido somente por mim, principalmente devido ao fato de que eu desenhava cada uma das fichas à mão.

Depois de algum tempo, até criei fontes para facilitar o processo, mas ainda precisava pegar meu iPad e o aplicativo Procreate para transformar minhas anotações em uma imagem.

Eu sempre quis que o gitfichas fosse mais. Mais acessível, mais colaborativo, mais útil. E com mermaid eu acho que podemos conseguir isso.

GitFichas e acessibilidade

Eu dei o meu melhor para melhorar a legibilidade, ajustando o contraste das cores nas fichas. Também adicionei texto alternativo a todas as imagens, bem como uma tabela em cada página individual de cada ficha descrevendo cada parte de cada comando ou conceito.

Mas eu também queria ter um modo escuro, melhores opções de cores para diferentes habilidades visuais e, finalmente, também melhorar o resultado para leitores de tela. É aí que entra mermaid. Mermaid permite gerar fichas baseadas em texto que podem ser personalizados usando CSS e JS.

Essas mudanças também levarão um tempo para acontecer, mas agora são possíveis. ☺️

Por que agora virou open source?

Como diria o Zen do Python: “Agora é melhor do que nunca”.

Tenho trabalhado lentamente para descobrir a próxima versão já tem um tempo e finalmente descobri como customizar e estruturar os gráficos mermaid para que pareçam mais com a versão anterior que eu tinha para as fichas. Então aqui estamos.

Além de melhorar a acessibilidade, essa mudança tornará esse projeto mais parte da comunidade e permitirá melhorias mais rápidas e a publicação de mais fichas, podendo até mesmo ser um trampolim para a comunidade criar outros projetos como esse.

Como contribuir

Abri um pouco mais de 100 issues no repositório do GitFichas que falam sobre melhorias que precisam acontecer para completar a migração para fichas no modo mermaid ao invés de imagens. Você pode trabalhar em uma delas ou em vários delas. Você também pode contar pra sua galera sobre o projeto e convidar geral pra colaborar.

OU.

Você pode enviar uma nova ficha com um novo comando ou conceito. Posso te ajudar a revisar e refinar palavras se precisar. Basta abrir um issue e enviar seu PR, seguindo o guia de contribuição (em inglês) disponível no repositório.

Recapitulando

E do fundo do meu coração: embora já tenha passado um bom tempo desde que publiquei novas fichas, o GitFichas tem sido um dos meus projetos pessoais favoritos. Eu o criei para ajudar pessoas desenvolvedoras como você e eu que podem precisar de ajuda com comandos git de tempos em tempos.

Espero que tornar o GitFichas open source ajude ainda mais pessoas desenvolvedoras com Git. Dito isso, o GitFichas agora é de open source e estou ansiosa para sua contribuição no GitHub. 🎉

Reflections from a maintainer and contributor during Hacktoberfest - is open source struggling?

Wed, 23 Oct 2024 05:00:00 +0000

This is a submission for the 2024 Hacktoberfest Writing challenge: Contributor Experience

This is a submission for the 2024 Hacktoberfest Writing challenge: Maintainer Experience

Also available on dev.to here.

Since 2016, I curate a list of brazilian-maintained projects people can contribute to during hacktoberfest. The goal is to facilitate contributions from the brazilian dev community and also lower the entry barrier to the first open source contribution from Brazilians that might not speak english or don’t know where to start.

Contributing to open source can be a thrilling experience, opening the pull request, watch the review come through, improve what needs improving, discuss what could be discussed. I personally love all of that.

For a while now the list is maintained by the community. Folks will submit their projects for consideration and as long as they are maintained by Brazilians, valid (not archived), and have issues open, the project will be added to the list. No questions asked.

For me, hacktoberfest is only an excuse to give back to the community even if throughout the year I couldn’t do much. Unfortunately it is true, a lot of devs used to only focus on open source during hacktoberfest in order to win a shirt.

Years pass, priority changes, and hacktoberfest has not been the same. I’ve seen less and less projects looking for contributions in Brazil as well people looking to contribute.

But we are still out here.

I recently delivered a lightning talk at Python Brasil, the largest python event in Latin America. In 2 minutes I spoke about open source and Hacktoberfest. Announced that GitFichas, a collection of git study cards was going open source. And invited folks to participate in the contribution sprints that would happen the following day for a number of projects.

To my surprise, most of the people in the audience never heard of hacktoberfest before. And yes, I asked.

I feel that the hype changed. Most software built today relies on open source to exist. But with the changing world, or better yet, the changed world “after” COVID, where layoffs happen every year, money is tight, and uncertainties are plenty, folks don’t have the energy to make contributions. Their time is spent trying to make sure they can put food on the table.

I believe becoming contributor to a major project was a big goal for many pre-COVID, and it still might be, the thing is it’s not a high priority anymore. Because of this, open source seems be struggling, at least from the scope of Brazilian contributions that I can see.

Don’t get me wrong, a pull request merged is still one of my favorite accomplishments as a developer. Contributions can be big or small. Technical or not. But taking the time to get involved in a project feels like a luxury not many have.

Getting a shirt after 4 pull requests was the cherry on top of becoming a contributor. Without it how can you wear your PR to a conference and make a new friend using that as an ice breaker? Few will have the courage and curiosity to simply ask about open source and cool projects you’ve seen.

So am I wrong in believing open source is struggling? Am I wrong in saying that hacktoberfest contributions were focused on getting a free t-shirt? I don’t know, but I’d love to see more projects and contributors alike. Even if you are contributing only during hacktoberfest every year.

GitFichas is Now Open Source 🎉

Tue, 22 Oct 2024 05:00:00 +0000

This means if you are looking for a project to contribute to you’ve found it! And still in time for hacktoberfest too!

What is GitFichas or GitStudyCards?

GitFichas is a collection of study cards about git. It was first closed source and maintained solely by me, mainly due to the fact I would hand draw each of the cards.

After some time I even created fonts to facilitate the process but it still required me to grab my iPad and the Procreate app to turn my notes into an image.

I always wanted GitFichas to be more. More accessible, more collaborative, more helpful. And with mermaid I think we can achieve this.

GitFichas and Accessibility

I worked my best to improve readability of the cards, by adjusting contrast of the cards. Also added alt text to all images as well as table in each page for each individual card describing each part of each command or concept.

But I also wanted to have dark mode, better color options for varying visual abilities, and finally also improve the result for screen readers. That’s where mermaid comes in. It would generate a text-based cards that can be customized using CSS and JS.

These changes will also take a while to happen but now they are possible. ☺️

Why is it open source now?

As The Zen of Python would say ”Now is better than never.”

I’ve been slowly working on figuring out the next version for a while now and finally figured out how to customize and structure the mermaid charts to look more like the previous version I had for the cards. So here we are.

In addition to improving accessibility, this change will make this project more of the community and allow for faster improvements and more cards to be published and maybe even be stepping stone for the community to create other projects like this one.

How to help

I opened a little over 100 issues in the repo for GitFichas that talks about improvements that need to happen to complete the migration over to mermaid cards instead of images. You can work on one of them or multiple of them. You can also tell your friends about the project and invite them to collaborate.

OR.

You can submit a new card with a new command. I can help review and refine words if you need help with it, just open an issue and submit your PR, following contribution guide available in the repo.

Recap

On a more personal note: even though it has been a while since I published any new cards, GitFichas has been one of my favorite personal projects to work on. I created it to help developers like you and me that might need help with git commands from time to time.

It is my hope that open sourcing it will help even more developers with Git, with that said, GitFichas is now open source and I’m looking forward to your contribution on GitHub. 🎉

Hacktoberfest

Sat, 19 Oct 2024 00:00:00 +0000

Keynote - Python Brasil 2024

Thu, 17 Oct 2024 03:00:00 +0000

Slides.

Projetos Brasileiros para contribuir nesse #Hacktoberfest 2024

Wed, 02 Oct 2024 05:00:00 +0000

Edição atual da lista disponível aqui.

Ontem começou Outubro e mais uma vez o mês inteirinho de celebração de open source! A festa que todo entusiasta e pessoas mantenedoras de open source espera está aqui é hora de #Hacktoberfest.

Por aqui você confere desde 2017 essa lista curada especialmente para te ajudar a encontrar projetos brasileiros para contribuir!

Regras para entrar nessa lista

As regras para adicionar projetos nessa lista:

Ser um projeto criado/desenvolvido/mantido por pessoas brasileiras;
Precisa ser um projeto, não pode ser uma organização, caso tenha mais de um projeto da organização precisa ser um PR por projeto com uma entrada por projeto;
Ter pelo menos uma issue aberta;
Ser um repositório válido, ou seja, não arquivado.

Avisos para 2024

Prêmios

Esse ano a Hacktoberfest não terá camiseta, se o seu objetivo é ganhar camisetas esse evento não é para você. Os prêmios serão virtuais no formato de badges Holopin.

Adicionando projetos nessa lista

Os projetos continuam separados pela linguagem principal pra facilitar as buscas pra quem lê e também em ordem alfabética pela linguagem. 😉

Qualidade > Quantidade

Assim como em anos anteriores, qualidade é o mais importante então se liga que dois PRs inválidos resultará em desqualificação por período indeterminado!

Para um PR ser considerado inválido, ele deve ser marcado com as tags spam ou invalid. Então é bom tentar fazer PRs de qualidade!

Relembrando que para tornar seu PR válido para a hacktoberfest você precisa ter algumas coisas. PRs apenas contarão se:

O PR precisa ser aberto em Outubro (entre os dias 1 e 31);
O PR precisa acontecer num projeto que tem o tópico hacktoberfest ou ser marcado com o rótulo (label) hacktoberfest-accepted por um mantenedor ou ser aceito (merged) ou ser aprovado pelo processo de revisão (review).

Mais informações

Mais informações no site oficial (em inglês).

Meu livro “O grande Microlivro de Git” está com desconto 30% na Gumroad tanto em português quanto inglês. Se você preferir, ele também está disponível na Amazon (sem desconto).

Por último, nesse outro artigo tem 5 Dicas Para Fazer o Seu Pull Request Brilhar ✨ e pode ser útil.

Happy Hacking! 🎉

Acesso rápido por linguagem

C#
C
CSS
Clojure
C++
Elixir
Go
JavaScript
Julia
Kotlin
Lua
PHP
Perl
Python
Ruby
Rust
Scala
Shell
TypeScript
Variados - Repositórios sem linguagem específica ex.: blogs, documentações e dicionários

C#

C

CSS

Clojure

C++

Elixir

Go

JavaScript

Julia

Kotlin

Lua

PHP

Perl

Python

Ruby

Rust

Scala

Shell

TypeScript

Variados

Device Authorization Flow 101 - Logging in From Input Constrained Devices

Sun, 28 Jul 2024 03:00:00 +0000

Have you ever heard of device authorization flow? You may have not heard it but good chances are you already used it.

Device flow allows you to login to your applications on input constrained devices, think of IoT devices or smart TVs for example.

Great applications allow the user to continue the login process on a more comfortable device instead of using, for example, the virtual keyboard on a SmartTV.

If you are developing applications that need this type of connectivity come to this talk to learn what device flow actually is, how it works, and better yet, see it working in an application that integrates Python (using FastAPI) and Micropython.

This talk was presented at PyOhio 2024 and you can watch it below.

Slides.

Code.

Tutorial - Migrating a Web Application from Flask to FastAPI

Tue, 09 Jul 2024 03:00:00 +0000

Have you ever had to migrate code from one stack to another? Migrating stacks on an application can be a daunting task. The secret is to keep changes to a small size and watch out for blind copy-and-paste.

Join me in this tutorial to learn the key differences between FastAPI and Flask plus how these differences will affect your stack migration.

Learn by doing it: migrate a simple Flask application to FastAPI. Learn how templates work in each framework, how you can use routers to create more complex applications in both Flask and FastAPI, and finally some tips if you are considering migrating from one to the other and vice-versa.

After this tutorial, you will feel confident to start your stack migrations between these two frameworks.

This tutorial was made for EuroPython 2024.

Slides.

Code.

Notas sobre publicar meu primeiro e-book

Sun, 04 Feb 2024 10:00:00 +0000

Uma vez escrevi sobre meu processo de criação de conteúdo e ainda sigo as coisas que escrevi lá, mas agora, passando pelo processo de publicação do meu primeiro e-book “O Grande Microlivro de Git”, posso dizer que aprendi algumas coisas novas. Continue lendo para conhecer a minha aventura ao publicar meu primeiro e-book por conta própria.

Escrita que não funcionou

Escrever em si foi difícil. Nunca escrevi algo tão longo e devo dizer que não é tão longo quanto poderia ser. “O Grande Microlivro de Git” foi na verdade um respiro de ar fresco enquanto eu estava escrevendo outro livro ainda mais longo (ainda a ser publicado) e fiquei presa no temido “bloqueio de escritora”.

Então em julho 2023, cansada de não terminar de escrever algum dos dois livros que estava escrevendo, resolvi terminar um deles. Afinal um livro que está apenas ocupando espaço no meu computador não está ajudando (nem a mim mesma). Acredito fortemente em aprender fazendo, então esta também foi uma oportunidade de aprendizado, já que usei este livro como uma espécie de experimento.

Minha ideia era usar este livro não apenas para ajudar outras pessoas com Git, mas, no meu lado, para me livrar dos nós existentes no meu processo de escrita para um formato de conteúdo mais longo e descobrir como publicar esse tipo de trabalho. Ao publicar o primeiro livro, aprendi um processo que funciona para mim no mar de informações existente na internet.

Para escrever de fato, comecei a usar o Apple Pages. Essa ferramenta me permitiria escrever em qualquer lugar, mesmo offline, mas comecei a perceber que a ferramenta em si não era ideal para a maneira como gosto de escrever: escrever tudo que tava na cabeça sem pensar, limpeza, edição, revisão, revisão, revisão, publicação.

O Apple Pages não me permitiu avaliar o progresso em meu processo de escrita ou revisão. Imagine o seguinte: eu só foco nesse tipo de projeto no meu tempo livre, isso geralmente significa fins de semana. Confiar na memória para lembrar se revisei ou não uma seção era, na falta de melhores palavras: difícil. Então, depois de escrever muito e de uma pausa muito longa, mudei do Apple Pages para o Notion.

Usando o Notion como ferramenta de acompanhamento para escrita

Eu tenho usado o Notion pro meu blog e pro GitFichas há mais ou menos um ano, quando decidi mudar o livro para o Notion, eu estava muito familiarizada com o uso de bancos de dados para fazer o que queria: acompanhar meu progresso.

Mudar para o Notion também implicou em passar algumas horas em um determinado fim de semana:

Copiando todo o trabalho realizado anteriormente;
Estruturando o banco de dados com todos os campos que precisava.

Depois de um copia-e-cola maçante, eu poderia voltar às tarefas mais interessantes: escrever e revisar.

Mais importante ainda, depois que tudo estava no Notion, percebi que tinha feito mais trabalho do que pensava e estava muito perto de terminar o livro. E fui em frente, escrevendo as partes que faltavam. Também investi um tempo para recriar todas as imagens que já tinha.

Criando imagens padronizadas com Carbon

Veja, eu estava tirando capturas de tela do terminal em um computador, então passei a usar apenas meu iPad para escrever e o GitHub Codespaces para tirar captura de tela dos comandos no terminal, o que significava que nem todas as minhas imagens pareciam iguais e eu gosto de padrões, então recriar as imagens era o única solução.

Eu também queria remover quaisquer vieses de minhas próprias configurações, facilitar pra mim à ocultar informações sensíveis, como meu e-mail pessoal, e, finalmente, facilitar a criação de versões em outros idiomas. Depois de algumas tentativas com algumas ferramentas online, Carbon acabou sendo a escolhida.

Depois de mais uma sessão repetitiva de copia-e-cola, consegui gerar novamente todas as imagens usando Carbon. Não gosto de fazer trabalhos repetitivos, então para aproveitar ao máximo o uso do Carbon, também iniciei um segundo banco de dados no Notion, desta vez para salvar as imagens que acabei de fazer.

O Carbon é baseado em conteúdo, portanto, tudo em uma determinada imagem faz parte da URL dessa imagem; então, se você salvar essa URL, poderá recriar a imagem facilmente, caso seja necessário. No banco de dados de imagens salvei não só a referida imagem, mas também o texto presente em cada uma delas, e as URLs também.

Com todas as imagens que fiz no Carbon pude iniciar a primeira revisão. Revisar tudo pela primeira vez ainda no Notion o que me permitiu fazer algumas correções rápidas, especialmente usando a Notion AI para detectar alguns erros de digitação fáceis de corrigir e vírgulas faltantes. Em seguida, exportei a primeira versão de um PDF diretamente do Notion para começar uma revisão mais “séria”.

Revise três vezes e depois revise novamente

Se fosse em outra época, quando ainda usava papel e tinha uma impressora, provavelmente eu iria imprimir o primeiro PDF que gerei. Mas não dessa vez, eu nem tenho mais impressora nem papel por aí, então usei meu iPad e Apple Pencil para fazer o que faria normalmente - escrever em caneta vermelha correções - e comecei o processo de revisão.

Agora, lembre-se de que, embora eu tenha revisado o conteúdo do livro uma vez, a pessoa que começou a escrever este livro não é a pessoa que sou hoje. Gosto de pensar que nos últimos 2 anos minhas habilidades de comunicação melhoraram e estão melhores do que no início desta jornada, então fiz muitas melhorias.

E aí entra meu primeiro revisor: depois de muita tinta vermelha virtual, enviei um segundo PDF - com as correções feitas da primeira revisão - para meu marido Jairo “JJ” Jair. Isso gerou uma discussão sobre como melhorar a ordem na qual o conteúdo estava apresentado.

Este livro foi feito para parecer um dicionário. A pessoa leitora encontraria o comando desejado no índice, seguiria o hiperlink e leria sobre o comando. Isso é indicado no início do livro, mas por mais que se tente, é impossível controlar quem lê, as pessoas farão o que querem e provavelmente lerão o livro pelo menos uma vez em ordem.

Depois da revisão do meu marido, uma noite de descanso e muita conversa, nós descobrimos uma ordem que ambos concordamos que fazia sentido, mais ajustes foram feitos. Mais uma vez gerei um novo PDF e desta vez entrou em cena a segunda revisora: minha querida amiga Ana “Ceci” Cecília.

Com um senso de pontuação melhor do que eu, Ceci sempre encontra uma maneira de melhorar minha escrita com algumas edições. Como estava um pouco ansiosa para terminar o livro fiz as edições finais e exportei o PDF e ePubs finais… Pelo menos naquele dia…

Publicando um livro na Gumroad

Finalmente, segurando a primeira versão da obra finalizada, chegou a hora de colocá-la numa vitrine em algum lugar. Lembre-se que no início eu queria publicar o livro em uma plataforma que eu controlasse tanto quanto possível e, em segundo lugar, na Amazon.

Agora foi aqui que a diversão começou. “O Grande Microlivro de Git” foi publicado primeiramente em português com foco em ajudar pessoas desenvolvedoras brasileiras, então a Hotmart parecia fazer sentido já que tinha suporte Reais e métodos de pagamento amplamente utilizados como o Pix, embora ainda seja uma plataforma internacional.

A Hotmart era praticamente perfeita à primeira vista, até que li os termos de uso: Ela possuem cláusula de exclusividade, então ao utilizar qualquer um dos serviços da plataforma você aceita apenas vender seus produtos lá, e foi assim que desisti de usá-la.

Também não queria desenvolver toda a infraestrutura necessária, parecia exigir muito de mim para ter as integrações que queria, então escolhi outra plataforma para produtos digitais: Gumroad.

A Gumroad é internacional, permite que você venda seus produtos digitais com uma configuração mínima, tem uma taxa fixa sobre as vendas e nenhuma cláusula de exclusividade, dito isso, a Gumroad é perfeita para necessidades como as minhas.

Infelizmente a Gumroad não dá suporte à moeda brasileira e os mesmos métodos de pagamento que a Hotmart usa, o que eu sabia que provavelmente prejudicaria parte das minhas vendas, mas ainda assim era melhor que a Hotmart.

Criando uma página de livro no meu site

Inicialmente a ideia era a página ser como uma landing page principal para o livro e usar a Hotmart apenas para finalizar a compra e enviar os e-books nos formatos PDF e ePub para os clientes, então implementei uma página no meu próprio site que me permitiria adicionar o detalhes do livro e botão para o portal de pagamento.

A página em si é bem simples. Meu blog foi feito usando Jekyll, GitHub Pages e Netlify, então para criar uma nova página eu só tive que escrever um novo markdown, mas queria ter alguns botões e a capa do livro ao lado da sua descrição.

Então, depois de feito o markdown, também adicionei um pouco de CSS para deixar tudo bonito e pronto. Com a página feita, mesmo acabando por não usar a Hotmart e a Gumroad tendo uma página independente, resolvi manter a página do livro. Agora ele exibe os detalhes sobre o livro e botões para comprá-lo na Gumroad e na Amazon.

Editando um e-book para a loja Kindle

Durante minhas análises, algo que fiz foi enviar o ePub para meu próprio Kindle para ver como ele seria renderizado lá. Embora o ePub tenha funcionado bem em outros leitores de e-book, a conversão da Amazon não funcionou tão bem…

As imagens exportadas pelo Carbon eram PNG com fundo transparente e sombra, no Kindle elas apareciam com borda preta e as legendas também ficavam envolvidas na mesma borda preta impossibilitando a leitura.

Então, ao invés de usar o ePub para publicar na Amazon, o que resultaria na falha na conversão da imagem, baixei e instalei o Kindle Create, software da Amazon para criar manuscritos Kindle.

Existem basicamente dois layouts de livros para Kindle: os de layout digitalmente otimizados e os de layout fixo (reflowable e fixed, respectivamente). O problema é que, se você deseja que seu livro seja legível nos leitores Kindle mais comuns, você desejará um layout digitalmente otimizado e a forma de conseguir isso é usando o Kindle Create.

Pense no Kindle Create como uma versão limitada do Google Docs ou do Microsoft Word. Por exemplo, para o modo digitalmente otimizado você só pode ter títulos em nível de capítulo. Para livros técnicos, como o Microlivro, isso é um pouco chato porque os subtítulos não aparecem no índice gerado automaticamente.

Resumindo, depois de me acostumar com as funcionalidades limitadas de formatação de texto do Kindle Create, e também com a forma como você pode adicionar mais conteúdo a ele, é bem fácil obter o manuscrito, mas primeiro eu precisava cuidar de toda a situação das imagens.

Uma pequena desvantagem do Kindle Create é que ele só aceita imagens JPG ou JPEG, o que também quer dizer que eu precisava converter todas as imagens PNG em arquivos JPG para usá-las. Usei o FFmpeg para converter todos os arquivos com extensão .png em .jpg, deixei um script aqui. Depois de executar o script, converter todas as imagens e substituir imagens antigas mal convertidas no manuscrito, eu “apenas” tive que exportar o arquivo novamente e subir ele na Amazon.

Publicar um e-book na Amazon

Com o documento Kindle pronto, chegou a hora de criar um perfil no Kindle Direct Publishing (KDP). Isso é, adicionar informações sobre o livro, como nome da autora, capa, pessoa ilustradora e editora. Após a primeira parte dos metadados, você pode fazer o upload do manuscrito, então você poderá ver uma prévia de como o livro ficará em diferentes dispositivos.

Com todos os campos obrigatórios preenchidos, a última peça do quebra-cabeça é escolher um acordo de preço e royalties. Para o preço escolhi o mesmo valor da Gumroad, mas você ainda precisa escolher um modelo para royalties. Você pode escolher quanto a Amazon pagará por cada venda que você fizer e quanto a Amazon manterá. Hoje a Amazon tem duas opções no que diz respeito a royalties:

Royalties de 35%: todos os e-books, desde que você venda pelo mesmo preço de outras plataformas, tá tudo pronto pra usar;
Royalties de 70%: se você optar por participar do KDP Select, mas precisa concordar com a cláusula de exclusividade do KDP Select.

Depois de tudo isso, basta clicar no grande botão amarelo de publicação. Depois de clicar nesse botão, seu livro passará por duas etapas que podem levar até 72 horas cada: Revisão e Publicação. Para mim, as duas etapas foram concluídas em menos de duas horas no total. Após a publicação, seu livro passa a ter uma página que mostra os detalhes do livro e permite sua compra.

Reivindique seu livro

Depois que seu livro estiver no ar, é hora de reivindicá-lo, para isso você precisa criar um perfil na Central de Autores da Amazon. Este processo é bem parecido com a criação de um perfil em qualquer rede social, a única diferença principal é: antes de colocar seu livro em sua biblioteca, você precisa ter seu perfil aprovado.

O processo de aprovação é semelhante aos processos de Revisão e Publicação do livro, você envia os dados e aguarda. Assim que o seu perfil for aprovado, você receberá um e-mail e poderá adicionar o livro ao seu perfil, assim como adicionei os meus.

Recapitulando

As revisões, a loja na Gumroad, a criação de um perfil na Amazon, a formatação do livro para o Kindle, levaram cerca de 4 longos dias. Ou seja, dois finais de semana em que me concentrei exclusivamente em trabalhar no livro, desde o momento em que acordei até a hora de dormir, na maioria dos dias perto da meia-noite.

Narrar tudo isso aqui me fez perceber como foi uma jornada intensa, mas também como é bom finalmente ter descoberto todas essas etapas. Mal posso esperar para passar por isso de novo, espero que em breve, se não tiver nenhum bloqueio de escritora novamente.

Para você que leu até aqui, primeiro obrigada pela leitura, segundo parabéns, e terceiro: espero que isso possa trazer alguma clareza a todo o processo pra você e que agora você possa se sentir mais confiante para publicar seus livros, estou ansiosa para lê-los.

Dicas para migrar uma aplicação de Flask para FastAPI e vice-versa

Fri, 19 Jan 2024 15:00:00 +0000

Você está migrando do Flask para o FastAPI e enfrentando problemas? Neste post do blog, você aprenderá sobre alguns dos problemas que pode encontrar ao migrar uma aplicação web de Flask para FastAPI, e também como resolver tais problemas.

A aplicação web que deu início a tudo

Como devrel na Auth0, eu crio aplicações de exemplo que podem ser usadas para mostrar nosso produto. Por exemplo, eu utilizei uma aplicação de amostra construída com Flask, Jinja e Auth0 para criar uma demonstração para estandes patrocinados. Essa aplicação demonstra como Flask e Auth0 podem ser usados em conjunto para desenvolver aplicações web.

Essa aplicação é uma aplicação web típica, composta por um backend construído com Flask, um frontend feito com modelos Jinja e um pouco de CSS. Ela também é protegida com Auth0 para simplificar os processos de autenticação e autorização.

Enquanto eu estava codificando uma amostra de código para responder uma pergunta de uma pessoa desenvolvedora na web, surgiu um pensamento na minha cabeça: “Já que a Auth0 pode ser usada com qualquer framework, por que não criar uma versão da aplicação de exemplo usando FastAPI no backend em vez de Flask?”

Pensando no trabalho que eu faço, eu poderia usar a nova versão construída com FastAPI para escrever um guia que ajudaria pessoas desenvolvedoras a entender como proteger suas aplicações construídas em FastAPI usando o Auth0. Então, decidi usar o exemplo construído em Flask e migrar as coisas para uma aplicação feita em FastAPI. Para facilitar as coisas para mim, meu plano era:

Reutilizar o máximo possível da aplicação original construída com Flask:
1. Copiar templates e stylesheets como também qualquer JavaScript.
Ajustar qualquer coisa necessária do código em Flask para funcionar com FastAPI.

Esse era um plano simples. Apenas dois passos. “Quão difícil poderia ser?” Eu sei, eu sei, famosas últimas palavras. Então, assim que comecei a fazer a migração, percebi que haveria algumas coisas que eu precisaria ajustar para que a aplicação FastAPI funcionasse corretamente.

Abaixo você pode ver o que é necessário ajustar se você tiver uma aplicação semelhante que queira migrar de Flask para FastAPI.

Disclaimer: Since the authentication guide in FastAPI is not public yet, I have created two sample applications with all the code shown in the examples of this blog post. If you are interested in reviewing the code, both applications are available on GitHub. You can follow the links below:

Pequeno aviso: Como o guia de autenticação no FastAPI ainda não é público, criei dois exemplos de aplicações com todo o código mostrado nos exemplos deste post do blog. Se você quiser revisar o código, ambas aplicações estão disponíveis no GitHub. Você pode seguir os links abaixo:

Templates

Ambos Flask e FastAPI suportam templates usando Jinja, mas existem algumas diferenças em como usar templates.

O Flask identificará automaticamente os templates em seu projeto para que você possa usar o método render_template e o Flask procurará templates na pasta do seu projeto. Você até pode ter dois formatos: seja como um módulo onde o modelo está na sua pasta raiz ou como um pacote onde o modelo está dentro da pasta da sua aplicação.

Desde que você use uma pasta templates/, o Flask automaticamente irá reconhecê-la. Isso só varia se você estiver usando Blueprints, pois será necessário passar o caminho para as templates no blueprint que você criar.

No FastAPI, por outro lado, não só é necessário garantir a instalação do Jinja2 em seu ambiente, mas também é preciso informar ao FastAPI onde encontrar os templates. Dito isso, você pode colocar a pasta de templates em qualquer lugar, mas precisará instanciar uma variável de templates para que o FastAPI a reconheça, desta forma:

from fastapi.templating import Jinja2Templates

templates = Jinja2Templates(directory="templates")

Depois disso, você pode usar essa variável para renderizar o template para um determinado endpoint assim:

@app.get("/")
def home(request: Request):
    """
    Home endpoint
    """
    return templates.TemplateResponse("home.html")

Filtros no Jinja

Para modificar variáveis dentro de uma página você pode usar filtros no Jinja. Nas aplicações de exemplo, criei um filtro to_pretty_json para fazer o print “bonito” de um objeto JSON no na página de /profile. Essa função existe do mesmo jeito em ambos os projetos, porém a forma de disponibilizá-la para páginas é um pouco diferente em cada framework.

Nota: você vai perceber que ambos frameworks funcionarão de forma semelhante, mas os nomes das propriedades serão diferentes.

Já que o Flask automaticamente reconhece os templates, a aplicação Flask possui uma propriedade chamada jinja_env que corresponde ao ambiente do Jinja e que você pode editar usando o dicionário de filtros para criar novos filtros dessa forma:

app.jinja_env.filters['to_pretty_json'] = to_pretty_json

Você também pode usar o decorador de filtro para templates.

Como no FastAPI você precisa criar a variável de templates, você também usará essa variável para passar um novo filtro. A variável templates possui a propriedade env, que permite acessar o dicionário de filters, como você pode ver abaixo:

templates.env.filters['to_pretty_json'] = to_pretty_json

Pasta de arquivos estáticos

Assim como no caso dos templates, tanto Flask quanto FastAPI permitem agrupar os arquivos estáticos (CSS, JavaScript e imagens) na mesma pasta, mas mais uma vez existem algumas diferenças.

Flask suporta arquivos estáticos “de cara”, sem necessidade de configuração, você só precisa adicionar a pasta static/ ao seu projeto, e é isso, não é necessário nenhuma configuração extra para acessar arquivos estáticos a partir dos seus templates e páginas.

Para o FastAPI, assim como a pasta de templates, você precisa definir a localização dos arquivos estáticos usando a propriedade mount, que “acopla” a pasta de arquivos estáticos à sua aplicação, e a classe StaticFiles para inicializar local do diretório.

from fastapi.staticfiles import StaticFiles

app = FastAPI()

app.mount(
    "/static",
    StaticFiles(directory="static"),
    name="static"
)

Observe que essa forma de acoplar a pasta de arquivos estáticos à sua aplicação web cria uma aplicação independente e ela não será detectada pelo OpenAPI ou pela documentação, mas você ainda poderá usar coisas como a função url_for em seus templates.

Usando a função url_for nos templates

Templates em ambos Flask e FastAPI permitem que você defina programaticamente URLs para arquivos e endpoints usando a função url_for, mas como você pode esperar, os parâmetros diferem em cada framework.

Por exemplo, no Flask, para adicionar CSS em base.html, você passa o nome da pasta static, seguido do parâmetro chamado filename, contendo o nome do seu arquivo CSS.

<link href="{{ url_for('static', filename='style.css') }}" rel="stylesheet" />

Para o FastAPI, a funcionalidade da função url_for será a mesma, mas o parâmetro para o nome do arquivo é chamado de path.

<link href="{{ url_for('static', path='style.css') }}" rel="stylesheet" />

Sessões

Para aplicações web, normalmente se define uma forma de gerenciar sessões. Abaixo você pode ver como você pode interagir com uma sessão em cada framework. O exemplo mostrará como limpar uma sessão ao fazer logout.

No Flask, você pode acessar a sessão a partir do objeto session que pode ser importado do módulo flask, como você pode ver abaixo:

from flask import session

# ... blueprint definition

@webapp_bp.route("clear-session-example")
def session_clearing():
    """
    example on how to clear a session, often used in logout endpoints
    """
    session.clear()
    # ... continuação da lógica

Enquanto isso, no FastAPI, a sessão faz parte do objeto Request, você pode acessá-la passando a requisição como parte da função de endpoint e, em seguida, usando request.session, assim:

from fastapi import Request

# ... definição do router

@webapp_router.get("/profile")
def profile(request: Request):
    user_info = request.session['userinfo']
    # ... continução da lógica

Aplicações modulares: Blueprint e APIRouter

Para aplicações mais complexas, que normalmente incluem vários módulos dentro de uma aplicação, você precisará usar um roteador para poder ter uma separação entre as responsabilidades de endpoints. Para isso, você terá um Blueprint no Flask e um APIRouter no FastAPI.

Depois de criar o Blueprint ou APIRouter, você precisará registrá-los em na sua aplicação. Veja como fazer isso para ambos os frameworks a seguir.

O Blueprint precisará de mais algumas configurações, como o nome desse blueprint ('webapp'), bem como o nome de importação (__name__) e qualquer outra configuração necessária. Neste exemplo, passamos a pasta de templates para o webapp:

from flask import Flask, Blueprint

webapp_bp = Blueprint(
    'webapp', __name__, template_folder="templates"
)

app = Flask(__name__)

Uma vez que o blueprint é criado, você pode registrá-lo na aplicação. Isso ajuda a disponibilizar qualquer visualização/rota dentro do seu blueprint para o app. O registro é feito chamando o método register_blueprint do seu app e passando o blueprint da seguinte forma:

from flask import Flask

app = Flask(__name__)

app.register_blueprint(webapp_bp, url_prefix='/')

Para o FastAPI, o APIRouter funcionará de forma semelhante ao Blueprint no Flask, a diferença é que você não precisa passar nenhum nome, dê uma olhada:

from fastapi import APIRouter

webapp_router = APIRouter()

Em seguida, para registrar o roteador, você deve usar o método include_router do aplicação FastAPI app e passar o webapp_router da seguinte forma:

from fastapi import FastAPI

app = FastAPI()

app.include_router(webapp_router)

Usando url_for nos endpoints

Além dos templates, você pode usar o url_for em um endpoint para definir programaticamente o caminho para um determinado endpoint ou rota.

Para usar url_for no Flask, você precisa importar a função da biblioteca flask e, em seguida, passar o nome do endpoint. Se o seu endpoint estiver em outro módulo, lembre-se de passar também o nome desse módulo, assim:

from flask import redirect, url_for

# ... definição da blueprint

@webapp_bp.route("/redirect-example")
def redirect_example():

    return redirect(url_for("webapp.home"))

Enquanto isso, no FastAPI, o url_for é um método e vem da classe Request. Você precisa passar o nome do endpoint, se esse endpoint fizer parte da aplicação, mesmo que esteja em outro módulo, tudo funcionará a partir daí e não há necessidade de passar o nome do módulo como no Flask.

from fastapi import Request
from fastapi.responses import RedirectResponse

# ... router definition

@webapp_router.get("/redirect-example", dependencies=[Depends(ProtectedEndpoint)])
def redirect_example(request: Request):

    return RedirectResponse(url=request.url_for("profile"))

Recapitulando

Migrar frameworks em uma aplicação pode ser uma tarefa assustadora, especialmente se você não souber onde as coisas podem dar errado após copiar e colar o código. Mas se você souber onde as coisas serão diferentes, a migração será muito mais tranquila.

Aqui está uma versão resumida das coisas a serem observadas se você pretende migrar do Flask para o FastAPI e vice-versa:

O Flask irá detectar automaticamente os templates, mas o FastAPI precisa ser informado onde encontrar os templates usando a classe Jinja2Templates e passando o diretório dos templates.
O Flask utilizará a função render_template para renderizar páginas, enquanto o FastAPI utilizará TemplateResponse que vem da classe Jinja2Templates.
Para criar novos filtros no Flask, você usa a propriedade jinja_env, o FastAPI usará a propriedade env.
O Flask irá reconhecer automaticamente a pasta com arquivos estáticos, para o FastAPI você precisa “montar” a pasta e usar a classe StaticFiles.
As sessões são tratadas de forma diferente, para o Flask existe um objeto session, para o FastAPI o objeto session faz parte da classe Request.
Para aplicações mais complexas, você usa Blueprint no Flask para definir novas rotas, enquanto no FastAPI você terá uma estrutura semelhante chamada APIRouter. Lembre-se de registrar seu blueprint ou seu router com a aplicação.
Por fim, lembre-se de usar a função url_for com o parâmetro correto filename para o Flask e path para o FastAPI, lembre-se também que nos seus endpoints url_for existe como uma função autônoma no Flask, enquanto é um método da classe Request no FastAPI.

Caso você queira ver as aplicações em cada framework e comparar as diferenças por conta própria, aqui estão os repositórios no GitHub:

Finalmente, se você passou por um processo semelhante, quais outros problemas você enfrentou e como os resolveu? Eu adoraria saber mais sobre sua experiência, me envie uma mensagem em qualquer uma das minhas redes sociais.

Tips on migrating from Flask to FastAPI and vice-versa

Fri, 15 Dec 2023 00:00:00 +0000

Are you migrating from Flask to FastAPI and facing problems? In this blog post, you will learn about some of the issues that you may encounter when migrating a web application from Flask to FastAPI, as well as how to solve them.

The web app that started it all

As a developer advocate at Auth0, I build sample applications that can be used to showcase our product. For example, I used a sample app built with Flask, Jinja, and Auth0 to build a demo for sponsored booths. This demo application showcases how Flask and Auth0 can be used together to develop web applications.

This app is a typical web app, consisting of a backend built in Flask, a frontend made with Jinja templates, and some CSS. It is secured with Auth0 to simplify the authentication and authorization processes.

While writing some code to answer a question from a developer a thought popped into my mind: “Since Auth0 can be used with any framework, why not create a version of the sample app using FastAPI in the backend instead of Flask?”

Thinking of the work that I do, I could use the new version built with FastAPI to write a guide that would help developers understand how to protect their applications built in FastAPI using Auth0. So I decided to use the sample built in Flask and migrate things over to a FastAPI-powered app. To make things easier on me, my plan was:

Reuse as much as possible of the original app built with Flask:
1. Copy templates and styling as well as any JavaScript.
Adjust anything necessary for the Flask code to work the “FastAPI way”.

That was a simple plan. Only two steps. “How hard could it be?” I know, I know, famous last words. So once I started migrating things over, I realized there were a few things that I would need to adjust for the app in FastAPI to function properly.

Below you can see what you’ll also need to adjust if you have a similar application you want to migrate over from Flask to FastAPI.

Disclaimer: Since the authentication guide in FastAPI is not public yet, I have created two sample applications with all the code shown in the examples of this blog post. If you are interested in reviewing the code, both applications are available on GitHub. You can follow the links below:

Templates

Both Flask and FastAPI support templating using Jinja, but there are a few differences.

Flask will automatically identify templates in your project so you can use the render_template method and Flask will look for the template in your project folder. You can even have two formats: either as a module where the template is on your root folder or as a package where the template lives inside your application folder.

As long as you use a templates/ folder Flask will automatically pick up on it. This will only vary if you are using Blueprints because you will need to pass the path for the templates to the blueprint you create.

FastAPI on the other hand, not only you do have to make sure to install Jinja2 on your environment, but you also need to tell FastAPI where to find the templates. With that said you can put the templates folder anywhere, but you’ll need to instantiate a templates variable for FastAPI to pick up on it like so:

from fastapi.templating import Jinja2Templates

templates = Jinja2Templates(directory="templates")

After that, you can use that variable to render the template for a given endpoint like this:

@app.get("/")
def home(request: Request):
    """
    Home endpoint
    """
    return templates.TemplateResponse("home.html")

Jinja Filters

Filters in Jinja serve as a way to modify variables. In this sample app, we created a filter to_pretty_json to “pretty print” a JSON object into the /profile endpoint. Even though the function is the same on both projects, the way to pass it along to the templates is a little bit different in each framework.

Note: you are going to notice that both frameworks will work similarly but the property names will be different.

Since Flask automatically picks up the templates, the Flask instance has a property called jinja_env that corresponds to the Jinja environment and that you can edit using the filters dictionary to register new filter like so:

app.jinja_env.filters['to_pretty_json'] = to_pretty_json

You can also use the template filter decorator.

Since in FastAPI you had to instantiate the templates variable, you’ll also use that variable to pass along the new filter. The templates variable has the env property allowing you to access the filters dictionary as you can see below:

templates.env.filters['to_pretty_json'] = to_pretty_json

Static files folder

Much like templates, both Flask and FastAPI, allow you to bundle the static files (CSS, JavaScript, and images) under the same folder, but once again there are a few differences.

Flask supports static files out of the gate with no configuration needed, you only need to add the static/ folder to your project, and that’s it, you don’t need any extra configuration to access static files from your templates.

For FastAPI, much like the template folder, you need to set the location of the static file by using the mount property, which is also known as “mounting” the static files, and the StaticFiles class to instantiate the directory.

from fastapi.staticfiles import StaticFiles

app = FastAPI()

app.mount(
    "/static",
    StaticFiles(directory="static"),
    name="static"
)

Note that this way of creating the static files folder within the app creates an independent application and won’t be picked up by the OpenAPI or the docs but you’ll still be able to use things like the url_for function on your templates.

Using url_for function on the templates

Both templates on Flask and FastAPI will allow you to programmatically define URLs for files and endpoints using the url_for function, but as you can expect the parameters differ on each framework.

For example, in Flask, to add the style sheet on your base.html, you pass along the folder name static followed by the parameter named filename containing the name of your CSS file.

<link href="{{ url_for('static', filename='style.css') }}" rel="stylesheet" />

For FastAPI the functionality of the url_for function will be the same, but the parameter for the filename is called path:

<link href="{{ url_for('static', path='style.css') }}" rel="stylesheet" />

Sessions

For web applications, you usually have a way to manage sessions. Below you can see how you can interact with a session in each framework. The example will show how to clear a session when logging out.

In Flask, you can access the session from the session object that can be imported from the flask module as you can see below:

from flask import session

# ... blueprint definition

@webapp_bp.route("clear-session-example")
def session_clearing():
    """
    example on how to clear a session, often used in logout endpoints
    """
    session.clear()
    # ... rest of your logic

Meanwhile, in FastAPI the session is part of the Request object and it is rewritable, so you can for example add the session from an identity provider for example… You can access the session by passing the request as part of the endpoint function, and then using it request.session, like so:

from fastapi import Request

# ... router definition

@webapp_router.get("/profile")
def profile(request: Request):
    request.session = {"user": {"name": "sam",},}

    # ... rest of your profile endpoint logic

Modular applications: Blueprint and APIRouter

For more complex applications, which usually include multiple modules inside of an app, you’ll need to use a router so you can have some separation between responsibilities. For this, you will have a Blueprint in Flask and an APIRouter in FastAPI.

After creating the Blueprint or APIRouter you’ll need to register them with your app. Here’s what that looks like for both frameworks.

The Blueprint will need some more configuration like the name of that blueprint (’webapp’) as well as the import name (__name__) and any other configuration necessary, in this example, we passed along the template folder for the webapp:

from flask import Flask, Blueprint

webapp_bp = Blueprint(
    'webapp', __name__, template_folder="templates"
)

app = Flask(__name__)

Once the blueprint is created you can register it to your app. This helps make available any views/routes within your blueprint for your application. The registration occurs by calling the register_blueprint method from your app, and passing along the blueprint like so:

from flask import Flask

app = Flask(__name__)

app.register_blueprint(webapp_bp, url_prefix='/')

For FastAPI the APIRouter will function similarly to the Blueprint in Flask, the difference is that you don’t need to pass any names, take a look:

from fastapi import APIRouter

webapp_router = APIRouter()

Then to register the router you can use the method include_router from your FastAPI app, and pass along the webapp_router like this:

from fastapi import FastAPI

app = FastAPI()

app.include_router(webapp_router)

Using url_for in the endpoints

Other than in templates, you can use the url_for in an endpoint to programmatically define the path for a given endpoint/route.

For using url_for in Flask you gotta import the function from the flask library and then pass the name of the endpoint. If your endpoint is in another module, remember to pass along the name of that module as well like so:

from flask import redirect, url_for

# ... blueprint definition

@webapp_bp.route("/redirect-example")
def redirect_example():

    return redirect(url_for("webapp.home"))

Meanwhile, in FastAPI the url_for is a method and comes from the Request class. You need to pass along the endpoint name, if that endpoint is part of your app, even if it is in another module, everything will work from there and there’s no need to pass the module name as well.

from fastapi import Request
from fastapi.responses import RedirectResponse

# ... router definition

@webapp_router.get("/redirect-example", dependencies=[Depends(ProtectedEndpoint)])
def redirect_example(request: Request):

    return RedirectResponse(url=request.url_for("home"))

Recap

Migrating frameworks in an application can be a daunting task especially if you don’t know where things might go wrong after copying and pasting code. But if you know where things will differ the migration will go much more smoothly.

Here’s a short version of the things to keep an eye out for if you are going to migrate from Flask to FastAPI and vice-versa:

Flask will pick up templates automatically, but FastAPI needs to be told where to find the templates using the Jinja2Templates class and passing along the templates directory.
Flask will use the render_template function to render pages, whereas FastAPI will use TemplateResponse which comes from Jinja2Templates class.
To create new filters in Flask you use the jinja_env property, FastAPI will use the env property.
Flask will pick up the static folder automatically, for FastAPI you need to “mount” the folder and use the StaticFiles class.
Sessions are handled differently, for Flask there’s a session object, for FastAPI the session object is part of the Request class.
For more complex applications you use Blueprint in Flask to define new routes whereas in FastAPI you’ll have a similar structure called APIRouter. Remember to register your blueprint or your router with your app.
Finally, remember to use the url_for function with the correct parameter filename for Flask and path for FastAPI, and that in your endpoints url_for exists as a standalone function in Flask whereas it is a method from the Request class in FastAPI.

In case you want to see apps in each framework and compare the differences for yourself here are the repositories on GitHub:

Finally, if you went through a similar process what other problems did you face and how did you solve them? I’d love to know more about your experience, send me a message on any of my social profiles.

Heroku CLI login from the terminal with MFA enabled

Mon, 04 Dec 2023 09:01:00 +0000

Let’s say you already know how to use the iterative way to log in to Heroku via the terminal, but now you’ve activated multi-factor authentication (MFA) on your profile and a simple username and password won’t be enough to log in.

In this pro-tip you will learn how to use iterative mode with MFA.

Logging into Heroku using the terminal

Just to review, if you use the following command

heroku login -i

You can enter your username and password directly on the terminal to log in to Heroku without having to use a browser.

This feature is extremely useful when you are trying to log in to Heroku from a remote instance like GitHub Codespaces for example.

With MFA (multi-factor authentication) activated, just username and password won’t be enough as can be seen in the image above.

To follow up with the login process in these cases, an authorization token must be generated.

Setting up an authorization token to log in to the MFA-enabled endpoint

Log in to your Heroku dashboard and click on your photo, then select “Account Settings”, when the page loads choose the “Applications” tab or click on this link to go directly to the applications dashboard. Then scroll down to the section called “Authorizations”.

If you have never used Heroku authorization tokens before, this section will be empty, I already have some tokens as you can see in the image below.

Then click on ”Create Authorization”. A side menu will appear as you can see in the image below.

To create a new token, just give it a description and click on the “Create” button. In my case, I intend to use this token for a GitHub Codespaces, so I named it “Codespaces”.

Once created, the token will be shown on the screen so you can copy it. Oh and don’t worry, although I’m showing this token here (which you should never do) it no longer exists so no one can impersonate me.

Note that, optionally, it is possible to give an “expiration date” or better said, a period of time for this token to expire, it is even recommended to do so.

Using an authorization token to log in

Remember to copy the token, now to log in, just use the token instead of your password when logging in. Run the command heroku login -i again and pass your username and token as can be seen

Now just follow the traditional flow of using Heroku.

Recap

In this post, you learned:

How to log in to Heroku via command line with multi-factor authentication (MFA) enabled using an authorization token.
How to create an authorization token on Heroku.
That to log in with MFA activated, you need to copy the generated token and use it instead of the password when logging in via the command line.

Now you can continue logging into Heroku via command line even with MFA enabled!

7 lições que aprendi gravando e editando vídeos curtos

Sun, 03 Dec 2023 09:01:00 +0000

Como developer advocate, eu queria ficar mais confortável com a gravação e edição de vídeos. Neste post, compartilho algumas das lições que aprendi com essa experiência. Continue lendo para descobrir o que aprendi e como isso pode te ajudar na criação de seu próprio conteúdo em vídeo!

Por que gravar vídeos?

Percebi recentemente que agora tenho um nível de conforto muito bom com minha escrita, mas não tenho o mesmo nível de conforto quando preciso gravar algo.

Sendo uma developer advocate, às vezes vou precisar gravar vídeos, e estar confortável fazendo isso me ajudará a reduzir o estresse durante a gravação, gravando vídeos mais rápido e com menos erros, e talvez em algum momento no futuro eu até ame gravar tanto quanto eu adoro escrever.

Então o desafio é gravar o máximo de vídeos possível até o final do ano. Meu objetivo é gravar 3 vídeos curtos por semana sobre um assunto com o qual me sinto confortável, neste caso: git. Reaproveitar parte do conteúdo que já tenho do GitFichas e do O Grande Microlivro de Git ajudaria, para que eu não tivesse que criar muito conteúdo do zero.

Por que editar vídeos?

Não só gravar vídeos é muito importante para mim, como também queria me desafiar para aprender e me sentir confortável na edição de vídeos, principalmente aqueles que sou eu quem fala.

E você pode perguntar “Por que?” e para mim a resposta é simples: quero ajudar mais pessoas.

Embora escrever e ler sejam minhas formas preferidas de aprender, algumas pessoas desenvolvedoras preferem assistir vídeos. Tenho sonhado com o dia em que você poderá vir aqui no meu blog e ler algo ou assistir a um vídeo e aprender a mesma coisa. Você pode escolher a maneira que preferir aprender comigo.

Mas para que isso seja verdade preciso 1) gravar os vídeos e 2) editá-los. Talvez no futuro eu tenha uma equipe para editá-los para mim. Não sendo essa a minha realidade hoje, vou aprender a editar.

Lição 1: Vídeos de 60 segundos são um desafio

Para mim, vídeos de 60 segundos são um desafio que vem do meu gosto de misturar anedotas pessoais com o conteúdo técnico.

Acredito que sempre que você aprende algo novo com alguém você também está em busca de conexão, de se identificar com a pessoa com quem está aprendendo, e até mesmo de fazer com que um pouco da personalidade dessa pessoa apareça, Também percebo que um pouco da minha personalidade vai aparecer de outras maneiras, mesmo em tão pouco tempo.

Garantir que cada vídeo tenha menos de 60 segundos adiciona uma camada extra de desafio. Mesmo tendo começado com o TikTok em mente, pretendo postar os vídeos também no YouTube como um short. Infelizmente, os shorts precisam ter 60 segundos ou menos, daí o desafio adicional.

Lição 2: Não fale enquanto digita

Embora eu tenha a habilidade de dizer algo enquanto digito outra coisa, depois de editar os primeiros vídeos, percebi que não falar enquanto digito irá:

1) Aumentar a velocidade na edição: se eu errar fica mais fácil recortar sem ter que regravar todo o trecho ou ter que falar por cima da explicação depois;

2) Permitir fazer vídeos mais curtos: porque posso acelerar a parte do vídeo onde estou digitando e também recortá-la se quiser. Além disso, embora eu consiga falar e digitar, meu ritmo de fala muda e demoro um pouco mais dar obter a informação.

Lição 3: Aprender a editar vídeo é mais fácil com um resultado em mente

Ainda tenho um longo caminho a percorrer na edição de vídeos mas, editando vídeos curtos, consigo dividir o processo de aprendizagem em pequenos passos, até agora aprendi a:

1) Cortar um vídeo para cortar partes que não preciso;

2) Adicionar um destaque ao que estou falando, como uma seta ou linha embaixo de uma parte específica no texto texto;

3) Adicionar texto na tela;

4) Adicionar uma transição.

Espero aprender algumas outras coisas em breve, como remover o fundo se eu usar uma tela verde, legendar, adicionar efeitos para que as coisas pareçam mais engraçadas e assim por diante.

Lição 4: Paciência consigo mesma é fundamental

Estou editando as coisas no iMovie. 👀 não me julgue, ok? Eu estou começando agora.

No momento eu sei exatamente um atalho: aquele para dividir o vídeo. Gostaria de saber mais atalhos, pois sei que provavelmente tornarão a edição mais rápida, também sei que a memória muscular virá com o tempo.

Além de cometer menos erros ou saber exatamente como editar algo antes de começar, para não ter que desfazer algumas coisas porque não saíram como eu esperava.

Lição 5: Mesmo que as dimensões estejam corretas, telas diferentes mostrarão o vídeo de forma diferente

O iPhone 14 por exemplo “come” no topo do vídeo no TikTok e se a ilha dinâmica estiver ligada é ainda pior.

Um amigo também me mostrou uma captura de tela no telefone dele mostrando que havia uma barra embaixo que cobriria uma parte do vídeo (principalmente meu rosto agora), então levar isso em consideração será bom para evitar colocar informações em uma parte que não aparecerá.

Isso basicamente significa que preciso ajustar a configuração de gravação dos próximos vídeos para que ainda possa mostrar as coisas sem comprometer o conteúdo exibido.

Lição 6: Eu ainda não gosto do som da minha própria voz no vídeo

Provavelmente porque sou excessivamente crítica com meus próprios erros, não apenas em dizer a coisa errada, mas também em relação ao meu sotaque e à maneira como simplesmente não consigo pronunciar algumas palavras “corretamente”.

Então, estou me concentrando em parar de prestar atenção em alguns deles, especialmente durante a edição, tenho que me ajudar e não gravar as mesmas coisas repetidamente. Isso também diz muito sobre como ficar confortável ao editar e gravar vídeos.

7: A parte de alcance é difícil

Estou postando no meu perfil no TikTok, também no canal do YouTube do GitFichas como shorts e no perfil do Instagram do GitFichas como Reels, mas ainda não descobri “a maneira certa” de compartilhar isso em outras plataformas como o Twitter (X) , Mastodon, LinkedIn e Bluesky.

Devo postar links para outras plataformas sempre que compartilhar um novo vídeo ou devo compartilhar o vídeo lá também? Não sei a resposta para essa pergunta agora, mas se eu descobrir te aviso.

Recapitulando

Aqui está a versão resumida da lista de lições até agora:

Lição 1: Vídeos de 60 segundos são um desafio;
Lição 2: Não fale enquanto digita;
Lição 3: Aprender a editar vídeos é mais fácil quando se tem um resultado em mente;
Lição 4: Paciência consigo mesmo é fundamental;
Lição 5: Mesmo que as dimensões estejam corretas, telas diferentes mostrarão o vídeo de forma diferente;
Lição 6: Eu ainda não gosto do som da minha própria voz no vídeo;
Lição 7: A parte de alcance é difícil.

Não esqueça de se inscrever ou seguir:

Continuarei compartilhando essa jornada por aqui… Enquanto isso, eu ia adorar saber a sua opinião, passa pra mandar uma mensagem em alguma das minhas redes sociais. 😉

Login to Heroku from GitHub Codespaces

Sat, 02 Dec 2023 09:01:00 +0000

These days I was using GitHub CodeSpaces to deploy an application to Heroku and I came across a problem: How do I login to Heroku given that I don’t have access to a browser running on the same machine where I’m using the terminal?

If you keep reading this blog post, I will show you exactly how to solve this.

IP mismatch when logging in

You’ve just finished installing Heroku CLI and it’s time to log in. Then you run the following command:

heroku login

This command will give you a page that you can open in your browser and login. Typically you see this page here:

When you click on login, you can log into your account with your traditional method such as username and password, for example, and then your terminal will show that you have logged in successfully.

It’s kind of magical how this happens, right? However, if you are using GitHub Codespaces, you don’t have a browser to view this login page, and if you try to open that same page using the traditional method of copying the URL and pasting it in your browser, you will find a page with the “IP mismatch” message.

And now what? The secret is to use the iterative way to login from the command line.

Logging into Heroku using the terminal

For cases in which it is not possible to use the browser to see that familiar login screen, the solution is to login interactively. Just use the same command as before followed by the -ioption and then follow the instructions that will show up.

heroku login -i

After running the command above, you will see the user and password request as can be seen in the image below:

After entering your data and logging in, you can continue using Heroku via the CLI normally.

Recap

In this post, you learned:

How to login to Heroku from GitHub Codespaces.
How to resolve the “IP mismatch” error using the -i option when logging into Heroku via the command line.

I hope this post helps you login to Heroku from GitHub Codespaces.

Renaming files in Git: the right way (using git mv)

Fri, 01 Dec 2023 11:25:00 +0000

Have you ever tried to rename a file in your projects and had a hard time adding the adjustment to a commit? This doesn’t just happen to you. In this pro-tip you will learn how to rename your files in git projects correctly to avoid headaches.

The problem with renaming a file without using git

Let’s say you decided to rename a file and, for simplicity’s sake, you decide to do it in the folder interface itself (or using the mv command in the terminal). After that you want to commit the name change and when you run the command git status you come across this situation:

If you rename the file without using Git, Git “gets lost” and thinks that the original file was deleted and a new file was created as shown in the image above. Because of this behavior, you end up having to do two steps to commit the name change:

Add the deleted file;
Add the new file.

To make matters worse, it is not possible to add a “deleted” file without explicitly using the name of that file, which makes this whole process even more tedious, not to mention the weirdness of the phrase “add a deleted file”.

Let’s say you persevered, added the deleted file and added the new file and once again you run git status, and then git finally understands that it was a change in the file name, like so:

This is a relatively painless solution if you don’t need to do this often, but there is a better way.

Renaming files the right way in git

To begin, you need to resist the urge of renaming the file using the interface or the mv command alone and start using the command git mv. Using the same example as the case above, in which the file books.md was renamed to book.md, the command looks like this:

git mv books.md book.md

The result of using just one command is the following:

Rename the file;
Add the name change to staging.

After that you can follow the normal commit flow and commit this change.

Recap

Do not use the interface to rename files in your Git projects, use the git mv command to do this and add this staged change to a commit.

GitFichas

How to undo changes in a Git repository using git revert

Fri, 01 Dec 2023 00:00:00 +0000

There are a number of ways of undoing commits in this pro-tip you will learn how to use git revert to undo commits specially when they already been published.

What is git revert?

git revert is a command that will undo a change in a commit by performing two actions:

Using the changes in a commit or collection of commits, undo said changes;
And create a new commit with the reversed changes.

Why use git revert?

Changes in git repositories are made so often that some times you might need to adjust them or even remove them from your codebase completely.

Depending on your case, you could undo commits using git reset thus removing the changes. But using git reset is only good if you haven’t published the commits with a given alteration. For those cases where a commit with a given change is public, a better way to undo those changes is to use git revert.

This command is made specially to remove the changes of a commit or collection of commits by making a new commit literally reverting the changes.

How does git revert work?

Every change in git is a collection of differences between the previous state of a given file and the alterations you made what is also know as a patch. Ideally if you follow best practices, the alterations you made will be done in an atomic way and each atomic change will be part of a single commit.

After choosing the commits with the corresponding changes you want to reverse, you can give the hash of said commits to the revert function and let the revert do it’s magic much like pressing Ctrl+Z or Cmd+Z on your computer.

Using git revert in a repository

Last weekend was Black Friday and Cyber Monday weekend so I wanted to have a discount code for my book as part of the book page. To do so, I made a bunch of commits all in this Black Friday pull request:

The image above you can see the 4 commits I made as well as the four short version of the commit hashes. For simplicity sake I can copied those for hashes on GitHub. To undo each of this commit I can use a succession of git reverts passing along each commit like this:

git revert 59b322a
git revert 93c1c77
git revert 7f37472
git revert c37fb73

Every time you run one of these commands, your editor will open up with a pre-populated message about the reversal of the commit like so:

You can change this message if you want to but I tend to only keep it. Once you save the commit message, you’ll be able to check that the commit made has the correct changes.

And that’s it, now you can push your changes and make a new pull request undoing your previous work.

Recap

In this pro tip you learned that

git revert is a command that undoes changes in a commit by creating a new commit with the reversed changes.
git revert is useful when you have already published the commits you want to undo.
Each revert command creates a new commit that undoes the changes made in the specified commit.
You can revert multiple commits by running git revert for each commit in succession.

Now go forth and reverse changes in your repo.

Livestream Hacktoberfest - Contribuindo com Open Source

Sun, 05 Nov 2023 05:00:00 +0000

Em Outubro acontece o Hacktoberfest, festa anual de contribuição open source, embora em outubro role essa festa é possível contribuir com open source o ano todo.

Se você tem interesse em contribuir com open source e precisa de um guia em como fazer isso, eu e Morganna Giovanneli tomamos conta do canal do GitHub Brasil para falar de open source e fazer pull requests.

Alguns dos assuntos mencionados nessa livestream:

Projetos Open Source
GitHub Actions
A lista de projetos brasileiros para contribuição
Como fazer pull requests
Como revisar pull requests

Dá play no vídeo aqui em baixo pra conferir na íntegra. 👇

LiveStream

Let's Talk About JWT

Sun, 08 Oct 2023 03:00:00 +0000

Slides

Talk

Projetos Brasileiros para contribuir nesse #Hacktoberfest 2023

Sun, 01 Oct 2023 05:00:00 +0000

Edição atual da lista disponível aqui.

Então Outubro chega mais uma vez para a alegria de devs e entusiastas open source do mundo todo, e com ele o evento mais esperado chega em sua décima edição: #Hacktoberfest.

Desde 2017, essa lista vem pra te ajudar a fazer pull requests/merge requests e participar dessa festa que dura um mês completinho. Então aqui vai! Uma lista toda repleta de projetos brasileiros pra você contribuir nesse mês de Outubro!

Edições anteriores

2017, 2018, 2019, 2020, 2021, 2022.

Regras para entrar nessa lista

As regras do ano passado se mantem:

Ser um projeto criado/desenvolvido/mantido por pessoas brasileiras;
Precisa ser um projeto, não pode ser uma organização, caso tenha mais de um projeto da organização precisa ser um PR por projeto com uma entrada por projeto;
Ter pelo menos uma issue aberta.

Avisos para 2023

Prêmios

Esse ano a Hacktoberfest não terá mais a tradicional camiseta. Por questões logísticas os prêmios serão virtuais para as cinquenta mil pessoas a completar os 4 pull/merge requests em Outubro.

Adicionando projetos nessa lista

Os projetos continuam separados pela linguagem principal pra facilitar as buscas pra quem lê e também em ordem alfabética pela linguagem. 😉

Qualidade > Quantidade

Assim como em 2022, qualidade é o mais importante então se liga que dois PRs inválidos resultará em desqualificação por período indeterminado!

Para um PR ser considerado inválido, ele deve ser marcado com as tags spam ou invalid. Então é bom tentar fazer PRs de qualidade!

Relembrando que para tornar seu PR válido para a hacktoberfest você precisa ter algumas coisas. PRs apenas contarão se:

O PR precisa ser aberto em Outubro (entre os dias 1 e 31);
O PR precisa acontecer num projeto que tem o tópico hacktoberfest ou ser marcado com o rótulo (label) hacktoberfest-accepted por um mantenedor ou ser aceito (merged) ou ser aprovado pelo processo de revisão (review).

Mais informações

Mais informações no site oficial (em inglês).

Por último, nesse outro artigo tem 5 Dicas Para Fazer o Seu Pull Request Brilhar ✨ e pode ser útil.

Happy Hacking! 🎉

C#

C

CSS

Clojure

C++

Elixir

Go

JavaScript

Julia

Kotlin

Lua

PHP

Pearl

Python

Ruby

Rust

Scala

Shell

TypeScript

Variados

Using empty commits to rebuild GitHub Pages websites

Wed, 20 Sep 2023 10:10:00 +0000

Whether due to broken CSS or a change that seems to have had no effect, sometimes it is necessary to force a rebuild of a Jekyll website hosted on GitHub. Today’s pro tip explains one way to do this.

@jess.temporal Empty commits are awesome! That is, if you know how to make them #git #coding #softwareengineer #github #gittutorial #tutorial #techtok #technology ♬ Empty commit - Jess Temporal

What is GitHub Pages?

GitHub has a “service” for serving pages from repositories called GitHub Pages. This service allows you to create pages almost instantly from your repository and all you need is a markdown file like a project’s README.md and a basic configuration file.

This is possible because GitHub Pages uses Jekyll, an open source static website generator, to build websites. Among other features that I won’t talk about today, an extremely positive point of using these two tools to get your website up and running is that you don’t need to push a build of your website to GitHub every time you want to publish a change. GitHub itself takes care of building the website for you.

However, sometimes it is necessary to run the build process again and as this process happens on GitHub servers that we do not have access to, we need other ways to force the build.

Making an empty commit

One of the ways to force a rebuild and the way I use nowadays is to make an “empty” commit, that is, a commit that does not upload changes to any file in your directory.

Just go to the website directory (here I will use my website as an example):

$ cd jtemporal.github.io

and write a commit using the --allow-empty option:

~/jtemporal.github.io $ git commit --allow-empty -m "Forcing website rebuild"

or if you prefer to edit the commit message in the text editor:

~/jtemporal.github.io $ git commit --allow-empty

And that’s it. This is enough to force the build process again. Cool, right? 😜

Getting the last element of a list in Python

Mon, 11 Sep 2023 09:10:00 +0000

Python is known for making it easy to write beautiful, small code. Today’s pro tip is about how to get the last element of a list using this language \o/

You can watch below or continue reading:

Coming from other languages like Java or C to Python, it’s normal to bring a bit of an accent to your codes and want to do something more or less like this to get the last element of a list:

my_list = [1, 2, 3, 4, 5]
item_index = len(my_list) - 1
print(item_index)
# 4
last_one = my_list[item_index]
print(last_one)
# 5

Use the len() size function to get the length of the list and subtract 1 to get the index of the last element in that list. And that’s ok! It works. However, Python presents a more elegant way of doing this, see:

last_one = my_list[-1]
print(last_one)
# 5

Even though it may seem like this, it’s not magic! From the Python documentation:

If i or j is negative, the index is relative to the end of sequence s: len(s) + i or len(s) + j is substituted. But note that -0 is still 0.

In a simpler way, Raymond Hettinger explains in this tweet with code:

#python tip: How to support negative indexing:

def __getitem__(self, i):
if i < 0:
i += len(self)
if i < 0 or i >= len(self):
raise IndexError
...
— Raymond Hettinger (@raymondh) 20 de dezembro de 2017

The implementation is actually more complex than this, but what happens in general terms: the __getitem__ method is invoked when we call my_list[-1] receiving the list itself (self) and the negative index (i) then adds this index with the size of the list and returns the updated index value. Interestingly, this was the same thing I did on the first example but it is already implemented by default.

And a little detail, the same can be done for strings!

word = 'yes'
print(word[-1])
# s

Dope, right? Now just use negative index in your codes too 😉

Special thanks

To Mário Sérgio, Diego Ponciano and Paulo Haddad for some of the links in this post!

How to count characters of a property on Notion easily using formulas

Sun, 10 Sep 2023 15:10:00 +0000

In this pro tip I’m going to show you one of the features I’ve learned and have been using for a while: the use of formulas in the properties of a Notion document.

What are Notion Formulas?

In addition to the many more traditional types of Notion properties such as an option selector or a list of categories (tags), it is also possible to extend properties features using formulas.

Notion’s formulas allow you to make calculations or perform functions based on other properties from that document.

The coolest part of these formulas is that once implemented, the result will be automatically updated if you make any changes to the property used in the formula.

Why use formulas on Notion?

I recently started using Notion as a task organization system for GitFichas (git study cards) using Databases.

As each card is followed up by a tweet, I also like to draft the tweets in the same interface to be able to pre-schedule the release of new cards. One of the problems of using Notion for this is that it lacks the character count that exists on Twitter interface, that’s where Notion’s formulas came into my life.

How to create a formula-based property

I have a property called “Tweet” in the database that I use to keep track of GitFichas. It is in this property that I draft the tweet for each new card.

Notice in the image above that the character count is missing so let’s add it. First click on “Add a property” to add a new property and choose the type “∑ Formula” from the menu. Then you will see the property edit menu, like this:

You can give the property a name, something like “Tweet Size” by editing the field with the default value “Formula”. Then click on “Edit” to see the way of writing the formula itself.

In this menu you can either compose your formula by writing or selecting between functions, constants, operators and properties. To count characters you can write:

length(prop("Tweet"))

Click Save and exit the menu then you will see your new property with the corresponding character count.

I’ll leave it to you to play with changing the text and seeing the resulting value of the formula update automatically. 😉

Recap

Formulas on Notion are a powerful extensibility feature. You can use formulas in Database documents. Here’s a step-by-step guide on how to create a formula in a document:

Click on “Add property”;
Choose the option “∑ Formula”;
Name your formula in the “Formula” field;
Click on “Edit” to write the formula;
Write length(prop("Tweet")) in the field “Type a formula” (remember to adjust the field name);
Click on “Save”.

And that’s it, now it’s time to have fun editing the corresponding field and see the value change automatically.

Contando carácteres de uma propriedade no Notion usando fórmulas

Sun, 10 Sep 2023 09:01:00 +0000

Nessa colinha eu vou te mostrar umas das funcionalidades que aprendi pouco tempo atrás: o uso de fórmulas nas propriedades de um documento do Notion.

O que são fórmulas no Notion

Além dos diversos tipos mais tradicionais de propriedades do Notion como um seletor de opções ou uma lista de categorias (tags), também possível extender as funcionalidades das propriedades usando fórmulas.

As fórmulas do Notion te permite fazer cálculos ou executar funções com base em outras propriedades daquele documento.

A parte mais legal dessas fórmulas é que depois de implementada, o resultado será automaticamente atualizado caso você faça alguma alteração na propriedade usada na fórmula.

Para que usar fórmulas no Notion

Eu passei a usar o Notion a algum tempo atras como um sistema de organização de tarefas para o GitFichas com o uso das Databases.

Como cada ficha é acompanhada de um tweet eu gosto também de rascunhar os tweets na mesma interface para conseguir deixar a divulgação de fichas novas pré-agendadas. Um dos problemas de usar o Notion para isso, é que falta a contagem de carácteres presente na interface do Twitter, é aí que as fórmulas do Notion entraram na minha vida.

Como criar uma propriedade baseada em fórmula

Eu tenho uma propriedade chamada “Tweet” na base de dados que uso para fazer o acompanhamento do GitFichas. É nessa propriedade que rascunho o tweet de cada nova ficha.

Note na imagem acima que falta a contagem de carácteres então vamos adicioná-la. Primeiro clique em “Add a property” para adicionar uma propriedade nova e escolha o tipo “∑ Formula” no menu. Então você verá o menu de edição da propriedade, assim:

Você pode dar um nome pra a propriedade, algo como “Tweet Size” editando o campo com o valor padrão “Formula”. Depois clique em “Edit” para ver o modo de escrita da fórmula em si.

Nesse menu você pode tanto compor a sua fórmula escrevendo quanto selecionando entre funções, constantes, operadores e propriedades. Para fazer a contagem de carácteres você pode escrever:

length(prop("Tweet"))

Clique em Save e saia do menu então você verá a sua nova propriedade com a contagem de carácteres correspondente.

Eu vou deixar para você brincar de alterar o texto e ver o valor resultante da fórmula atualizar automaticamente. 😉

Recapitulando

Fórmulas no Notion são uma funcionalidade poderosa de extensibilidade. Você pode usar fórmulas em documentos das Databases. Aqui está o passo-a-passo de como criar uma fórmula em um documento:

Clique em “Add property”;
Escolha a opção “∑ Formula”;
Dê um nome para sua fórmula no campo “Formula”;
Clique em “Edit” para escrever a fórmula;
Escreva length(prop("Tweet")) no campo “Type a formula” (lembre-se de ajustar o nome do campo);
Clique em “Save”.

E pronto, agora é se divertir editando o campo corresponde e ver o valor alterar automaticamente.

Login no Heroku via linha de comando (CLI) com MFA ativado

Sat, 09 Sep 2023 09:01:00 +0000

Digamos que você já sabe usar a forma iterativa para fazer login no Heroku pelo terminal, mas agora você ativou a autenticação multi fator (MFA) no seu perfil e um simples usuário e senha não vai ser o suficiente para login.

Nessa colinha você vai aprender a usar o modo iterativo com MFA.

Só para revisar, se você usar o comando a seguir

heroku login -i

Você poderá informar o seu usuário e senha diretamente no terminal para executar o login no Heroku sem precisar usar um navegador.

Essa funcionalidade é extremamente util quando você está tentado fazer login no Heroku por uma instancia remota como o GitHub Codespaces por exemplo.

Com a MFA (autenticação multifator) ativada, só usuário e senha não vai bastar como pode ser visto na imagem acima.

Para dar continuidade ao processo de login nesses casos, é preciso gerar um token de autorização.

Faça login no seu dashboard do Heroku e clique na sua foto, então selecione “Account Settings”, quando a página carregar escolha a aba “Applications” ou clique nesse link para ir diretamente ao dashboard de aplicações. Em seguida, desça a página até a seção chamada Authorizations.

Se você nunca usou tokens de autorização do Heroku antes, essa seção estará vazia, eu já tenho alguns tokens como pode ver na imagem abaixo.

Então clique em Create Authorization. Um menu lateral aparecerá como pode ver na imagem abaixo.

Para criar novo token basta dar uma descrição e clicar no botão Create, no meu caso, pretendo usar esse token para um GitHub Codespaces por isso dei o nome de “Codespaces”.

Depois de criado, o token será mostrado na tela para que você possa copiá-lo. Ah e não se preocupe, embora eu esteja mostrando esse token aqui (coisa que você nunca deve fazer) ele já não existe mais então ninguém poderá se passar por mim.

Note que, opcionalmente, é possível dar uma “data de validade” ou melhor dizendo, um prazo de tempo para que esse token vença, inclusive é recomendado fazê-lo.

Lembre-se de copiar o token, agora para fazer o login basta o token no lugar da sua senha ao fazer login. Rode novamente o comando heroku login -i e passar o seu usuário e o token como pode ser observado

Agora basta seguir com o fluxo tradicional de uso do Heroku.

Recapitulando

Neste post, você aprendeu:

Como fazer login no Heroku via linha de comando com autenticação multifator (MFA) ativada usando um token de autorização.
Como criar um token de autorização no Heroku.
Que para fazer login com MFA ativado, é preciso copiar o token gerado e usar ele no lugar da senha ao fazer login via linha de comando.

Agora você pode seguir fazendo login no Heroku pela linha de comando mesmo com MFA ativado!

7 Lessons I learned from recording and editing short videos

Fri, 08 Sep 2023 09:01:00 +0000

As a developer advocate, I wanted to get more comfortable with recording and editing videos. In this post, I share some of the lessons I learned from this experience. Keep reading to find out what I learned and how it may help you with your own video content creation!

Why record videos?

I realized recently that I have a pretty good comfort level of comfort with my writing now, but I don’t have the same level of comfort when I need to record something.

Being a developer advocate, sometimes I’ll need to record videos, and being comfortable doing so will help me reduce stress when recording, recording videos faster with fewer mistakes, and maybe sometime in the future I’ll even love recording as much as I love writing.

So the challenge is to record as many videos as can until the end of the year. My goal is to record 3 short videos a week on a subject I’m comfortable with, in this case: git. Repurposing part of the content I already have from GitFichas and The Big Git Microbook would help so I wouldn’t have to create too much content from scratch.

Why edit videos?

Not only recording videos is a big deal for me, but I also wanted to challenge myself to learn and get comfortable at editing videos, particularly the ones I’m the person speaking.

And you may ask “Why though?” and for me the answer is simple: I want to help more people.

Although writing and reading are my preferred ways to learn, some developers prefer to watch videos instead. I’ve been dreaming of the day when you can come here to my blog and read something or watch a video and learn the same thing. You could choose the way you prefer to learn from me.

But for that to be true I need to 1) record the videos and 2) edit them. Maybe in the future, I’ll have a team to edit it for me. While that’s not my reality today, editing I shall learn.

Lesson 1: 60 seconds videos are a challenge

For me, 60 seconds videos are a challenge that comes from my liking to intertwine personal anecdotes with the technical content.

I believe whenever you learn something new from someone you are also looking for connection, to identify yourself with the person you are learning from, and even get a bit of their personality to come through, I also realize that some of my personality will show up in other ways even in such a short time.

Making sure every video is under 60 seconds adds an extra layer of challenge. Even though I started with TikTok in mind I plan to post the videos also on YouTube as a short. Unfortunately, shorts need to be 60 seconds or less hence the added challenge.

Lesson 2: Do not speak while typing

Although I have this skill of saying something while I type something else after editing the first few videos, I realized that not speaking while typing will:

1) Increase speed in editing: if I make a mistake is easier to cut out without having to re-record the whole section or having to voice over the explanation later;

2) Allow for shorter videos: because I can speed up the portion of the video where I’m typing as well as cut it out if I want to. Also even though I can speak and type my speech rhythm changes and it takes me a little longer to get the information out.

Lesson 3: Learning to edit video is easier with an outcome in mind

I still have a long way to go in editing videos but, by editing short videos I can layer the learning process with small steps, so far I learned to:

Split a video to cut out parts I don’t need;
Add a highlight to the thing I’m speaking about like an arrow or line under a particular part of a text;
Add text to the screen;
Add a transition between clips.

I hope to learn a few other things soon too like removing the background if I use a green screen, captioning, adding effects so things look funnier, and so on.

Lesson 4: Patience with yourself is key

I’m editing stuff on iMovie. 👀 don’t judge me okay? I’m new at this.

Right now I know exactly one shortcut: the one for splitting the video. I wish I knew more shortcuts as I know they will probably make editing faster, I also know that muscle memory will come with time.

As well as making fewer mistakes or knowing exactly how to edit something before I start so I don’t have to undo some things because they didn’t turn out as I expected them to.

Lesson 5: Even though the dimensions are right, different screens will show the video differently

The iPhone 14 for example “bites” into the top of the video on TikTok and if the dynamic island is on is even worse.

A friend also showed me a screenshot on his phone that there was a bar below that would cover a portion of the video (mainly my face now) so accounting for that will be good to avoid having information in a portion that won’t show up.

That basically means I need to adjust the recording setup for the next videos so I can still show things without compromising the content being shown.

Lesson 6: I still dislike the sound of my own voice on video

Probably because I’m overly critical of my own mistakes not only about saying the wrong thing but also about my accent and the way I just can’t pronounce some words “properly”.

So I’m focusing on tuning out a few of these, especially when editing, I have to help myself and not record the same stuff over and over again. This also speaks volumes about getting comfortable when editing and recording videos.

Lesson 7: The reach side is hard

I’m posting on my own profile on TikTok, also on GitFichas’ YouTube channel as shorts and on GitFichas’ Instagram profile as Reels, but haven’t figured out “the right way” to share these to other platforms like Twitter (X), Mastodon, LinkedIn, and Bluesky.

Should I post links to the other platforms every time I share a new video or should I share the video there as well? I do not know the answer to that question right now, but if I figure it out I’ll let you know.

Recap

So here’s the short version of the lesson list so far:

• Lesson 1: 60 seconds videos are a challenge;

• Lesson 2: Do not speak while typing;

• Lesson 3: Learning to edit video is easier with an outcome in mind;

• Lesson 4: Patience with yourself is key;

• Lesson 5: Even though the dimensions are right, different screens will show the video differently;

• Lesson 6: I still dislike the sound of my own voice on video;

• Lesson 7: The reach side is hard.

Make sure to subscribe or follow:

I’ll continue to share this journey here… In the meantime, would love to hear your thoughts. 😉

Login no Heroku a partir do GitHub Codespaces

Thu, 07 Sep 2023 09:01:00 +0000

Esses dias eu estava usando GitHub CodeSpaces pra fazer o deploy de uma aplicação pro Heroku e me deparei com um problema: Como fazer o login no Heroku dado que eu não tenho acesso a um navegador rodando na mesma máquina em que eu estou usando o terminal?

Se você continuar lendo esse blog post, eu vou te mostrar exatamente como resolver isso.

Você acabou de fazer a instalação do Heroku CLI e chegou a hora de fazer o login. Então você roda a o comando a seguir:

heroku login

Esse comando vai te dar uma página para que você possa abrir no navegador e fazer o login. Normalmente você vê essa página aqui:

Ao clicar em login, você pode entrar na sua conta com o seu método tradicional como usuário e senha por exemplo, e então o seu terminal vai mostrar que você fez login com sucesso.

Meio mágico como isso acontece né mesmo? Porém se você esta usando o GitHub Codespaces, você não tem um navegador para visualizar essa página de login, e se você tentar abrir aquela mesma página pelo método tradicional de copiar a URL e colocar ela no seu navegador, você vai encontrar uma página dizendo a mensagem de “IP mismatch”.

E agora? O segredo é usar a forma iterativa de login na linha de comando.

Para casos onde não é possível usar o navegador para ver a familiar tela de login, a solução é usar o login de forma interativa. Basta usar o mesmo comando de antes acompanhado da opção -i e então seguir as instruções que vão aparecer.

heroku login -i

Após rodar o comando acima, você vai ver o pedido usuário e senha como pode ser observado na imagem abaixo:

Depois de colocar os seus dados e efetuar o seu login, você poderá seguir com o seu uso do Heroku via CLI.

Recapitulando

Neste post, você aprendeu:

Como fazer o login no Heroku a partir do GitHub Codespaces.
Como resolver o erro de “IP mismatch” usando a opção -i ao fazer login no Heroku através da linha de comando.

Espero que este post te ajude a fazer login no Heroku dentro do GitHub Codespaces.

Renomeando arquivos no Git do jeito certo (usando git mv)

Sat, 19 Aug 2023 11:25:00 +0000

Você já tentou renomear um arquivo nos seus projetos e teve dificuldade adicionar o ajuste em um commit? Isso não acontece só com você. Nessa colinha você vai aprender a renomear os seus arquivos em projetos git da forma correta para evitar dores de cabeça.

O problema de renomear um arquivo sem usar o git

Vamos dizer que você decidiu renomear um arquivo e, por questão de simplicidade você decide fazer isso na interface de pasta mesmo (ou usando o comando mv no terminal). Depois disso você quer fazer o commit da alteração de nomes e ao rodar o git status você se depara com essa situação:

Se você renomeia o arquivo sem usar o Git, o Git “se perde” e acha que o arquivo original foi apagado e um arquivo novo foi criado como mostrado na imagem acima. Por causa desse comportamento, você acaba tendo que obrigatoriamente fazer dois passos para commitar a alteração no nome:

Adicionar o arquivo deletado;
Adicionar o arquivo novo.

Para piorar, não é possível adicionar um arquivo “deletado” sem usar explicitamente o nome desse arquivo, o que torna esse processo todo ainda mais tedioso, pra não mencionar a esquisitice da frase “adicionar um arquivo deletado”.

Vamos dizer que você perseverou, adicionou o arquivo deletado e adicionou o arquivo novo e mais uma vez você roda um git status, e ai o git entende que foi uma alteração no nome do arquivo, veja:

Essa é uma solução relativamente tranquila se você não precisa fazer isso com frequência, mas existe uma solução melhor.

Renomeando um arquivo no git do jeito certo

Para começar é necessário resistir ao impulso de renomear o arquivo usando a interface e passar a usar o comando git mv. Usando o mesmo exemplo do caso acima, onde renomeamos o arquivo books.md para book.md, o comando fica assim:

git mv books.md book.md

O resultado de usar apenas um comando é o seguinte:

Renomear o arquivo;
Adicionar a mudança de nome em staging.

Depois disso você pode seguir o fluxo normal de commits e fazer o commit dessa alteração.

Recapitulando

Não use a interface para renomear os arquivos nos seus projetos Git, use o comando git mv para fazer isso e já adicionar essa mudança em staging para um commit.

GitFichas

What tools do you use?

Sat, 19 Aug 2023 10:00:00 +0000

I heard this question a few times, so I decided to make a list.

In case you are building your own setup or trying to improve the one you already got, actually seeing how others do theirs might help.

The list is divided into the categories as follows:

Desk: Everything on my desk that I use on a daily basis like my keyboard, mouse, and so on;
Recording or Streaming: All material for recording videos and/or live-streaming, here you find my lighting, green screen, microphone, camera, and others;
Coding: my favorite tools for writing code including setup personalization scripts;
Apps and Software: Apps I use on my devices from password managers to writing tools;
Services: Platforms I use for imaging, domains, and others;
Travel: My preferred travel gear, since I’m on the road a lot, travel gear can make or break my traveling;
Storage: SSDs and flash drives for when I need to store files locally;
Decor: The little things you see in my background like funkos and LED panels.

Keep in mind that these lists will change over time as add or remove things from my daily use. Also friendly disclaimer: some of these links are affiliated which means I’ll get a small percentage if you buy the items using the links I shared, and in some instances you might get store credits as well!

Without further ado, here are the links:

Notes on self-publishing my first ebook

Wed, 16 Aug 2023 11:00:00 +0000

I once wrote about my content creation process and I still follow the things I wrote in there but now, going through the publishing process of my first ebook “The Big Git Microbook”, I can say I learned a few new things. Read through to understand learn about my adventure in self-publishing first ebook.

Writing that didn’t work

Writing itself was hard. I never wrote something so long and I gotta say this isn’t as long as it could be. “The Big Git Microbook” was actually a breath of fresh air as I was writing another longer book (still to be published) and got stuck with the dreaded “writer’s block”.

So this July, tired of not finishing any of the two books I was writing, I decided to finish one of them, after all, a book sitting in my computer somewhere isn’t helping anyone. I strongly believe in learn by doing, so this was also a learning opportunity since I used this book as an experiment of sorts.

My idea was to use this book not only to help others with Git but, on my side, to get rid of kinks in my writing process for longer content format and to figure out how to publish this type of work. By publishing the first book, I learned a process that works for me in the sea of information out there.

For the actual writing, I started using Apple Pages. That tool would allow me to write anywhere even offline, but I started noticing that the tool itself wasn’t ideal for the way I like to write: brain dump, clean up, edit, review, review, review, publish.

Apple Pages didn’t let me gauge the progress in my writing or review process. Consider this: I only focus on these types of projects on my free time, this usually means weekends. Relying on memory to remember whether or not I reviewed a section was, simply put, hard. So after writing a lot and a very long break, I moved from Apple Pages to Notion.

Using Notion as follow up tool for writing

I had been using Notion for my blog and gitfichas for the past year or so, by the time I decided to move the book to Notion I was very familiar to using databases to do what I wanted to do: track my progress.

Moving to Notion also meant that I spent a couple of hours one given weekend to:

Copy over all the work done before;
Structure the database with all the fields I needed.

After the tedious copying and pasting was done I could go back to the actual tasks: writing and reviewing.

More importantly, after everything was in notion I realized that, the first time around I had done more work than I thought and I was super close to finishing it. And forward I went, writing the pieces that were missing. I also took my time to recreate all images I already had.

Creating standardized images with Carbon

You see, I was taking screenshots from the terminal on a computer, then I converted into using only my iPad for writing and GitHub Codespaces for screenshooting commands on a terminal, that meant not all my images looked the same and I like patterns, so recreating the images was the only way to go.

I also wanted to remove any biases of my own configurations, make easier on me to hide sensitive information like my personal e-mail, and finally to make easier to create versions in other languages. After a few tries with a few online tools, Carbon ended up being the chosen one.

Another session of repetitive copying and pasting later, I managed to regenerate all images using Carbon. Now I don’t like doing repetitive work, so in order to take most advantage of using Carbon, I also started a second database in Notion, this time to save the images I just made.

Carbon is content based, so everything in a given image is actually part of the URL for that image, so if you save that URL you can recreate the image easily should the need arise. In the image database I not only saved said image, but the text present in each one of them, and also the URLs as well.

With all the images I had made in carbon I could start the first review. Reviewing everything for the first time still in notion allowed for some fast corrections especially using Notion AI to spot some easily fixable typos and missing commas. I then exported the first version of a PDF directly from Notion to start some “serious” reviewing.

Review three times, and then review again

Were this another other time, when I still used paper and had a printer, I would probably print out the first PDF I generated. But this is not that time, I don’t even own a printer or have paper lying around anymore, so I just used my iPad and Apple Pencil to do as I normally would and started the reviewing process.

Now mind you that even though I did review the content of the book once, the person that started writing this book is not the person I am today. I like to think that in past 2 years, my communication skills improved and that they are better than in the beginning of this journey, so I did a lot of improvements.

And here my first reviewer comes in: After a lot of virtual red ink, I sent a second PDF - with corrections made from the first review - to my husband Jairo “JJ” Jair. That sparkled a discussion around improving the order in which the content was presented.

This book was meant to look like dictionary. The reader would find the command they want in the table of contents, follow the hyperlink, and read about the command. This much is stated in the beginning of the book but try as one might, it is impossible to control readers, they will do what they want and probably read the book at least once in order.

After my husband’s review, a night of rest, and a lot of conversation we figured out a order that we both agreed made sense, more adjustments were made. Once again I generated a new PDF and this time, the second reviewer came into the picture: a dear friend Ana “Ceci” Cecília.

With a better sense for ponctuation than me, Ceci always find a way to improve my writing with a few edits. Because I was a little antsy to finish the book I did the final edits and exported the final PDF and ePubs… At least for that day…

Publishing a book on Gumroad

Finally, holding on to the first version of the finished work it was time to put a store front somewhere. Mind you that in the beginning I wanted to publish the book in a platform I control as much as possible and secondly on Amazon.

Now this is where the fun began. The “The Big Git Microbook” was first published in Portuguese with a focus on helping Brazilian developers, so Hotmart seemed to make sense since it had support to the country currency and widely used payment methods like Pix, while still being an international platform.

Hotmart was pretty much perfect at a first glance, until I read the terms of use: They have an exclusivity clause, so by using any of the platforms services, you accept to only sell your products there, and that’s how I gave up on using them.

I also didn’t want to develop the whole infrastructure, it seemed to required a lot of me to have the integrations I wanted so I picked another platform for digital products: Gumroad.

Gumroad is international, allows you sell your digital products there with minimal setup, has a flat rate over sales, and no exclusivity clause, with that said, Gumroad is kinda perfect for needs like mine.

Unfortunately Gumroad does not support the Brazilian currency and the same payment methods as Hotmart did, which I knew would probably hurt part of my sales, but it was still better than Hotmart.

Creating a book page on my website

Initially the idea was to have the page be the main landing page for the book and use Hotmart only to checkout and send the ebooks in PDF and ePub formats to customers, so I implemented a page on my own website that would allow me to add the book details and link to the payment gateway.

The page itself is pretty simple. My blog is built using Jekyll, GitHub Pages, and Netlify, so to create a new page I just had to write a new markdown but I wanted to have a few buttons and have the book cover next to it’s description.

So after the markdown was done I also added a little of CSS to make everything look pretty and everything was done. With the page in place, even though I ended up not using Hotmart and Gumroad having a standalone store front, I decided to keep the book page. Now it displays the details about the book and buttons to purchase the book on both Gumroad and Amazon.

Editing an ebook for the Kindle

During my reviews, one thing I did was send the ePub to my own kindle to see how it would render over there. Even though the ePub worked well on other e-readers, Amazon conversion kinda didn’t work as well…

The images, exported by Carbon were PNG with an transparent background and a shadow, in the kindle they showed up with a black border and the captions were also involved in the same black border making it impossible to read.

So instead of using the ePub to publish on Amazon, which would result in the failed image conversion, I downloaded and installed Kindle Create, Amazon’s software for creating Kindle manuscripts.

There are a mainly two layouts of books for kindle: reflowable and fixed. The catch is, if you want your book to be readable on the most common Kindle readers, you will want a reflowable layout and the way to get that is by using Kindle Create.

Think of Kindle Create as a limited version of Google Docs or Microsoft Word. For example, for reflowable you can only have chapter level headings. For technical books like the microbook that’s a little annoying because subheadings don’t appear in the automatically generated table of contents.

Long story short, after getting used to the limited text formatting functionalities in Kindle Create, as well as how you can add more content to it, it is pretty easy to get the manuscript, but first I needed to take care of the whole images situation.

A little draw back from Kindle Create is to only accepts JPG or JPEG images, which also meant that I needed to convert all PNG images into JPG files in order to use them. I just used FFmpeg to convert all files with .png extention into .jpg, there’s a script here. After running the script, converting all the images, and replacing old-poorly-converted-images in the manuscript I “only” had to export the file again and upload it to Amazon.

Publishing an ebook on Amazon

With the Kindle document ready, it was time to create a profile on Kindle Direct Publishing (KDP). That’s add the information about the book like the author name, cover, illustrator and editor information. After the first part of the metadata, you can upload the manuscript, then you’ll be able to see a preview on how the book will look like in different devices.

With all mandatory fields filled, the final piece of the puzzle is choosing a pricing and royalties agreement. For pricing I picked the same value as in Gumroad, but you still have to pick a model for royalties. You can choose how much Amazon will pay you out of every sale you make and how much amazon will keep. Today Amazon has two options as far as royalties are concerned:

35% royalties: all ebooks, as long as you sell at the same price as other platforms you are good to go;
70% royalties: if you chose to participate in KDP Select, but you have to agree with the exclusivity KDP select clause.

After all of that is just hit the big yellow publish button. Once you hit that button, your book will go through two steps that can take up to 72 hours each: Review and Publishing. For me, both of these were finished in under two hours total. After publishing is done, your book now has a page that show the book details and allows it to be purchased.

Claim your book as the Author

After your book is live, is time to claim it as the author, for that you need to create a profile Amazon’s Author Central. This process is very similar to creating a profile on any social media, only main difference is: before you can put your book under your library, you need to get you profile approved.

The approval process is similar to the Review and Publish processes for the book, you submit the data and wait. Once it is approved you’ll get an email and will be able to add the book into your profile like I added both of mine.

Recap

The reviews, store front on Gumroad, creating an Amazon profile, formatting the book for Kindle, took about 4 very long days. That is, two weekends when I solely focused on working in the book, from the moment I woke up to the moment I went bed, most days close to midnight.

Narrating all of that here made me realize what an intense journey this was, but as well how good it is to finally have figured out all of these steps. I can’t wait to go through that again, hopefully soon if I don’t get any writer’s block.

For you that read up to here, first thanks for reading, second congratulations, and third: I hope this could bring some clarity to the whole process for you and that now you can feel more confident into publishing your books, I’m looking forward to reading them.

Go with the flow

Mon, 13 Mar 2023 03:00:00 +0000

First international keynote ❤️

Tired of getting confused about concepts like authentication, authorization, access tokens, ID tokens, client credentials, OpenID Connect, and OAuth2.0? In this talk, you’ll learn how they come into play for the different scenarios so you never get confused again.

Unless you work implementing authorization and authentication flows on a daily basis, chances are that you don’t know the different types of flows your application could follow. In general, Pythonistas see every application as an API and there’s nothing wrong with that until you need to implement such flows on your application.

In this talk, you will see how an API differs from a regular web application. We will dive into the differences between implementing a simple protected API to a web app with a front-end, login, and logout. You’ll understand key concepts like access tokens, client credentials, OpenID Connect, OAuth2.0, and how they come into play for the different scenarios.

If you are tired of getting confused by all of these concepts, this talk is for you.

Slides.

Code.

You can watch it below:

Retrospectiva 2022: Um ano de aventuras

Fri, 16 Dec 2022 11:00:00 +0000

Em 2018 e em 2017 eu fiz retrospectivas públicas e, por algum motivo, não senti necessidade de fazer isso em entre 2019 e 2021, possivelmente por que dois desses anos foram de pandemia e eu tava só tentando sobreviver? Sim. 2022 chegou e com ele a reabertura do mundo. Esse ano tanta coisa aconteceu que acho que vale a pena a reflexão.

Vale salientar que a lista não tem uma ordem de importância.

Peguei COVID e não tive sintomas graves: Depois de dois anos dentro de casa, esse ano voltei a sair de casa a trabalho. Com isso novos cuidados passaram a fazer parte da rotina de viagem como por exemplo fazer auto-teste todos os dias da viagem e durante tres depois de chegar ema casa, levar mascaras na mala e assim por diante… Mesmo tomando todas as vacinas e cuidados possíveis, eu previa que iria pegar COVID eventualmente e aconteceu em junho desse ano! Ao contrario de muitos outros sobrevivi e me recuperei, porem foi uma das coisas mais preocupantes do meu ano.
Mudei de país: Há muito tempo eu queria viver fora do Brasil nem que fosse por um tempo, e com sorte, esse ano consegui fazer a mudanca para o Canada, a firma patrocinou o visto e em junho eu e mozao colocamos nossas vidas em duas malas e viemos morar em Toronto.
Fiz uma viagem internacional pela primeira vez em anos: Fazia muito tempo que eu não fazia viagens internacionais. Desde antes da pandemia não me sobrava grana para tanto e esse ano finalmente quebrei o jejum de conhecer novos paises e novas culturas, passei por mais de 15 aeroportos e 7 paises, em resumo… Foi um ano incrível.
Passei por 7 países e mais de 10 cidades: sim voce leu direito. Ja fazem quase dois anos que eu trabalho com developer relations e esse ano voltei a colocar o pé na estrada para encontrar pessoas desenvolvedoras onde elas estiverem. Isso me levou a voar alto e pousar em varias cidades em prol de compartilhar conhecimento e ver pessoas. Isso pra não falar nos eventos online que também rolaram nesse ano. Segue a lista de paises: 🇬🇧 🇮🇪 🇦🇺 🇩🇪 🇨🇦 🇺🇸 🇧🇷 .
Consegui andar mais de 18km em um único dia sem sofrer: No começo do ano com o início da volta a sair de casa, eu notei como 2 anos de pandemia foram detrimentais para minha saúde física. Eu não conseguia andar 100m sem precisar recuperar o fôlego. Então, comecei uma jornada de melhorar minha saúde. Voltei a me exercitar com foco de aproveitar os eventos sem ficar sofrendo e consegui chegar ao fim do ano tendo conseguido andar 18km num mesmo dia sem me sentir fadiga extrema ou precisando parar para recuperar o fôlego.
Fui convidada a fazer parte do programa GitHub Stars: Que eu gosto de git e GitHub não é novidade, mas eu nunca acreditei que o meu trabalho para ajudar pessoas a usarem essas duas ferramentas fosse me trazer tamanho reconhecimento. Tudo que eu tenho feito é para ajudar pessoas e foi muito gostoso receber esse convite.
Organizei o primeiro meetup no escritório: Veja bem, nem só de viagens vive a DevRel, depois de viajar um tantão, também consegui criar laços com algumas comunidades locais aqui por Toronto. Abri as portas do escritorio pro primeiro meetup presencial pós-pandemia do OWASP Toronto. Espero fazer mais disso ano que vem e já estou conversando com as PyLadies Toronto para me juntar ao capítulo.
Vi neve pela primeira vez: eu nunca tinha visto neve ao vivo antes, e esse ano consegui marcar essa atividade como feito. Ainda estou esperando a “neve de verdade” cair para que eu possa montar um boneco de neve e fazer um anjinho na neve, mas isso só deve rolar ano que vem.

E por aí? Quais foram as coisas legais que rolaram no seu ano?

My year in review: 2022, a year of adventures

Fri, 16 Dec 2022 11:00:00 +0000

In 2018 and 2017 I wrote public retrospectives, and for some reason I didn’t feel the need to do that in between 2019 and 2021, possibly because two of those years were pandemic years and I was just trying to survive? Yes. 2022 has arrived and with it the reopening of the world. So much has happened this year that I think it’s worth reflecting on.

Note that the list is not ranked in order of importance.

I caught COVID and had no serious symptoms: After two years indoors, this year I went out again for work. As a result, new precautions became part of my travel routine, such as doing self-tests every day during the trip and three days after arriving back home, carrying masks in my suitcase and so on… Even taking all possible vaccines and precautions, I predicted that I would eventually get COVID and it happened in June! Unlike many others, I survived and recovered, but it was one of the most worrisome things about my year.
I moved to another country: I had wanted to live outside Brazil for a long time, and luckily, this year I managed to move to Canada, the company I work for sponsored the visa and in June, me and bae put our whole lives in two suitcases and came to live in Toronto (if you are here I’d love to meet 😉).
I traveled internationally for the first time in years: I hadn’t traveled internationally in a long time. Since before the pandemic there wasn’t much spare money for traveling and this year I finally ended up getting to know new countries and new cultures, I went through more than 15 airports and 7 countries, long story short… It was an incredible year.
I’ve been to 7 countries and more than 10 cities: yes, you read that right. I’ve been working with developer relations for almost two years now and this year I was back on the road to meet developers wherever they were. This led me to fly high and land in several cities in order to share knowledge and connect with people. Not to mention the online events that also took place this year. Here’s the list of countries: 🇬🇧 🇮🇪 🇦🇺 🇩🇪 🇨🇦 🇺🇸 🇧🇷.
I managed to walk more than 18km in a single day without suffering: At the beginning of the year, with the start of going out after the high of the pandemic, I noticed how 2 years of pandemic had been detrimental to my physical health. I couldn’t walk 100m without needing to catch my breath. So, I started a journey of improving my health. I went back to exercising focusing on enjoying the events without suffering and reached the end of the year having managed to walk 18km in the same day without feeling extreme fatigue or needing to stop to catch my breath.
I was invited to be part of the GitHub Stars program: The fact that I like git and GitHub is nothing new, but I never believed that my work helping people to use these two tools would bring me such recognition. Everything I’ve been doing is to help people and it was really nice to receive this invitation.
I organized the first meetup at the office: You see, DevRel isn’t just about traveling, and after traveling a lot, I also managed to bond with some local communities here around Toronto. I opened the office doors for OWASP Toronto’s first post-pandemic in person meetup. I hope to do more of this next year and I’m already talking to PyLadies Toronto.
Saw snow for the first time: I had never seen snow in real life before, and this year I was able to mark this activity as done. I’m still waiting for the “real snow” to fall so I can build a snowman and make a snow angel, but that shouldn’t happen until next year.

What about you? What were the cool things that happened in your year?

3 tips you should know about GitHub Codespaces

Wed, 30 Nov 2022 15:10:00 +0000

GitHub Codespaces is a great tool for anyone who wants to write code on the go. Recently, GitHub announced that now all accounts have a free monthly quota of 60 hours to use GitHub Codespaces, so I wrote this blog post with the 3 golden tips in case you want to start using the tool.

Set up dotfiles to customize your experience

I really like to customize my terminal so that it shows the things I need/like. Most of these settings stay in a set of files popularly known as dotfiles these are those files that start with a . such as .zshrc and .bashrc.

It is also common to store such files on a GitHub repository named dotfiles, for example here is my collection of dotfiles. To enable the use of these files in your Codespaces, click on your photo in the upper right corner and choose Settings from the menu that appeared.

Once in the settings dashboard, find the Codespaces option on the left side menu in the Code, planning, and automation section and click on it.

This will take you to the Codespaces settings page and then the first section called Dotfiles will appear.

Now click on the checkbox to install the dotfiles automatically on Codespaces and if you have a repository called dotfiles GitHub will identify your corresponding repository and use it here.

Keep in mind that you can switch to another repository if you want. Finally, it is good to point out two things:

Changes in files in the dotfiles will only take effect after the creation of a new Codespace;
Codespaces doesn’t use SSH to run git actions so if you have settings for that in your dotfiles like I did you’re going to have problems (the solution is to remove that).

Use the Codespaces Management Dashboard

Now that you have 60 hours free per month to play with Codespaces, you might be tempted to create Codespaces for all your repositories, after all, in theory, you can do that, but it’s good to learn to keep a clean house too.

To make your work easier there is a page where you can see all the Codespaces you have and the status of each one as seen in the image above, just access github.com/codespaces. I also recommend you get into the habit of doing this regularly to help keep your free quota, well, free.

Learn how to use GitHub in the VS Code interface

Finally, the part that can take the most time: using GitHub integration in the VS Code interface. There is a VS Code extension called GitHub Pull Requests and Issues that basically allows you to do things like review pull requests and interact with issues directly on VS Code.

This will speed up your pull request review process because you don’t even have to switch tabs or leave your Codespace to interact.

Recap

These are the three fastest tips to implement that I can think of, in about 15 minutes you can set up and become familiar with each one. Remember:

Set up dotfiles to customize your experience;
Get to know the Codespaces management panel;
Learn how to use the GitHub integration in the VS Code interface.

3 dicas que você precisa saber sobre GitHub Codespaces

Wed, 30 Nov 2022 15:00:00 +0000

GitHub Codespaces é uma ferramenta ótima para quem quer escrever código em qualquer lugar. Recentemente o GitHub anunciou que agora todas as contas tem uma cota gratuita de 60h mensais para usar o GitHub Codespaces, por isso escrevi essa colinha com as 3 dicas de ouro caso você queira passar a usar a ferramenta.

Configure dotfiles para personalizar a sua experiência

Eu gosto muito de personalizar meu terminal para que ele mostre as coisas que eu preciso/gosto. A maioria dessas configurações mora num conjunto de arquivos popularmente conhecido como dotfiles esses são aqueles arquivos que começam com um . como .zshrc e .bashrc.

Também é comum armazenar tais arquivos dentro de um repositório no GitHub com o nome dotfiles, por exemplo aqui está a minha coleção de arquivos dotfiles. Para ativar o uso desses arquivos no seu Codespaces, clique na sua foto no canto superior direito e escolha Settings no menu que apareceu.

Uma vez no painel de configurações encontre a opção Codespaces no menu lateral esquerdo na seção Code, planning, and automation e clique nela.

Isso vai te levar para a página de configuração do Codespaces e logo aparece a primeira seção chamada Dotfiles.

Agora clique na caixa de seleção para instalar os dotfiles automaticamente nos Codespaces e, caso você tenha um repositório chamado dotfiles o GitHub irá identificar o seu repositório correspondente e usá-lo aqui.

Tenha em mente que você pode alterar para um outro repositório caso queira. Por fim, é bom salientar duas coisas:

Que mudanças nos arquivos presentes no dotfiles só entrarão em efeito na criação de um novo Codespace;
O Codespaces não usa SSH para executar as ações de git então se você tiver configurações em relação a isso no seus dotfiles como eu tinha você vai ter problemas (a solução é remover isso).

Use o painel de gerenciamento do Codespaces

Agora que você tem 60h gratuitas por mês para brincar com o Codespaces você sofrer a tentação de criar Codespaces para todos os seus repositório, afinal de contas, em tese, você pode fazer isso, mas é bom aprender a manter a casa limpa também.

Para facilitar o seu trabalho existe uma página que você consegue ver todos os Codespaces que você tem e o status de cada um como visto na imagem acima, basta acessar github.com/codespaces. Eu ainda recomendo você criar o hábito de fazer isso regularmente para ajudar a manter a sua cota gratuita livre.

Aprenda a usar o GitHub na interface do VS Code

Por fim a parte que pode demandar mais tempo: usar a integração do GitHub na interface do VS Code. Existe uma extensão do VS Code chamada GitHub Pull Requests and Issues que te permite basicamente fazer coisas como revisar pull requests e interagir com issues diretamente no VS Code.

Isso vai te trazer uma grande agilidade no seu processo de revisão de pull requests por que você nem precisa ficar trocando de aba ou sair do seu Codespace para interagir.

Recapitulando

Essas são três dicas mais rápidas de implementar que eu consigo pensar, em cerca de 15 minutos você consegue configurar e se familiarizar com cada uma delas. Lembre-se:

Configure dotfiles para personalizar a sua experiência;
Conheça o painel de gerenciamento do Codespaces;
Aprenda a usar a integração do GitHub na interface do VS Code.

7 useful tips for traveling with ease ✈️

Mon, 31 Oct 2022 09:01:00 +0000

Traveling can be daunting, especially if you have never felt comfortable doing it before. Here you can find my personal take on things that helped me get through over 15 airports in seven countries in a timely manner in the past year.

All these tips I learned on the go and figuring out what worked for me helped me get to my destination faster without feeling “that should be a better way of doing this”.

1. Check-in online if you can

This will help you save time at the airport because you won’t need to stay in line to check-in. Most airlines also have a fast drop-off for checked bags, which means you’ll spend less time standing at the airport before you go through security.

2. Pack like you mean it

Packing is an acquired skill. The more you do, the better you get at it. I like to have time for packing one day in advance since this gives me time to adjust if I remember anything I might have forgotten. I even have a checklist on Notion you can duplicate so you won’t forget to pack anything important.

No matter how long or short the trip, I usually travel with a carry-on suitcase and a backpack. This requires me to be very intentional about what I take with me. Here’s how I divide my things between the suitcase and the backpack:

In the backpack, I take:
1. All my electronics: gimbal, iPad, work computer, noise-canceling headphones, camera, power bank, and chargers
2. All liquids: Medicine, lotions, hair products
3. A sweater or hoodie, an extra pair of underwear, and a t-shirt
4. Passport, currency, jewelry, and cards
5. An empty water bottle
In the carry-on goes:
1. All my clothing: cardigans, underwear, a hairdryer bonnet for the curls;
2. Anything that doesn’t have a battery: tripods, swag, selfie stick, and flip-flops.

Before the airport

I started using packing cubes because they help me keep my clothes organized, especially when I have little time in between trips to wash everything. So whenever I’m packing to come home, I fit all my dirty clothes into one packing cube, so it is easy to find what I need to wash before the next trip.

Always do a weight test. A good rule of thumb is to try to lift the carry-on over your head to make sure you can lift it yourself. Flight attendants can always help you, but it is a good measure to ensure you can carry your own weight.

At the airport

Going through security at the airport, you’ll be asked to take out all liquids and large electronics from your bags. Keeping everything in one place will help you get cleared faster. Since you can’t take anything with over 100ml in the cabin, remember to empty your water bottle before getting in line. You can always find a water fountain to fill out again after you get cleared.

You may be requested to check your suitcase at the gate. It is a good idea to plan your packing around that possibility. Keeping all batteries with you is a good measure, so you don’t have to go around opening your suitcase on the airport floor to take stuff out.

3. Research how to get around at your destination

Research how to get around in the city you will be in. I always look for information on how easy it is to get around the city. This step helps me in two ways:

Reduces the anxiety of not knowing where I am, especially if I don’t speak the language.
Helps me prepare for any surprises that might arise, for example, strikes in public transportation.

For example, the first time I went to Ireland, I discovered that Uber and taxis are “difficult” over there. All Uber drivers are actually taxi drivers. You also need to leave earlier or schedule taxis in advance. They also use an app called Free Now, which requires you to confirm your profile by receiving an SMS.

Buses in Berlin can be a nightmare, but trains and trams work really well. Google will help you get around and pick the correct lines even if you don’t speak German. Another tip is to download the BVG app so you can buy tickets on the go, but pay attention to the ticket type and pick the correct starting point. There might be people checking your ticket in the tram/train car.

4. If you need to be connected at all times: eSIM is the way to go

If you need to be connected while away, buy and configure an eSIM before you go. I use an eSIM from Airalo. Airalo has a plethora of packages and works in a lot of countries. Because it is right there on your phone is easier than buying a new SIM every time, lowering the decision burden. Since they are digital, using an eSIM also generates less trash.

Another good thing, the data or mobile plan you pick may expire, but the eSIM itself doesn’t, so you only have to set up the eSIM once. I bought one global data eSIM that I can add more data to it whenever I need to travel again.

Just remember to set it up and know how to configure it before traveling since you’ll need a stable internet connection.

5. Be ready to take your shoes off

Be prepared to take your shoes off. This is one most of us forget. Depending on several factors, you may be asked to take your shoes off and put them through the X-ray machine. Avoid shoes that might get stuck or require a lot of effort to take out or put back on your feet.

6. No noise is better

Have a good pair of noise-canceling headphones. My favorite one so far is the Sony WH-1000XM3. I keep thinking about upgrading mine to a newer version of it. Still, this one serves me soooo well that I can not justify buying the new ones for myself just yet.

I bought the Sony WH-1000XM3 around 4 years ago. Out of its features, I like that the battery lasts a long time even after so long using it and that you can configure the noise-canceling level. There’s nothing fancier than not hearing the airplane noises during an 8h red eye.

7. Jet-Lag is real

Make sure to respect yourself. If you haven’t crossed timezones before, you might be hard on yourself and feel like “you should be enjoying this more,” but be mindful that our bodies need time to adjust to new routines and time zones.

For me takes about 5 days to completely adjust to a new timezone. That’s just how my body works. Even with me going to bed and getting out of bed at the correct time every day, I still feel tired or that I should be sleeping at odd hours. Exercising and having a plan for working or touristing helps fight it off, but if I can, I’ll take naps after lunch and extra long walks to tire myself before bed.

Recap

In short, here’s what you need to keep in mind:

🎟️ Check-in online if you can;
🧳 Pack like you mean it;
📱 Find a phone plan that works for you; eSIM is a great thing;
👟 Be prepared to take your shoes off;
🎧 Noise-canceling headphones are REALLY helpful;
🗺️ Check how to get around the city before you actually get there;
😴 Jet-Lag is real. Respect your body.

Before you go, I’d like to leave you with one bonus tip: take more pictures than you think you need. I always arrive home feeling like I could use more pictures or videos, even if I don’t post them.

7 dicas úteis para viajar com tranquilidade ✈️

Mon, 31 Oct 2022 09:01:00 +0000

Viajar pode ser assustador, especialmente se você nunca se sentiu confortável fazendo isso. Aqui você vai encontrar minha opinião pessoal sobre coisas que me ajudaram a passar por mais de 15 aeroportos em sete países em tempo hábil durante o ano passado.

Todas essas dicas eu aprendi durante as viagens e descobrir o que funcionava para mim me ajudou a chegar ao meu destino mais rápido sem sentir “que deveria haver uma maneira melhor de fazer isso”.

1. Faça seu check-in on-line se possível

Isso ajudará você a economizar tempo no aeroporto, pois não precisará ficar na fila para fazer o check-in. A maioria das companhias aéreas também tem uma fila de despacho rápido para malas despachadas, o que significa que você passará menos tempo no aeroporto antes de passar pela segurança.

2. Faça as malas com intenção

Fazer as malas é uma habilidade adquirida. Quanto mais você faz, melhor você fica nisso. Eu gosto de ter tempo para fazer as malas com um dia de antecedência, pois isso me dá tempo para ajustar se eu me lembrar de algo que possa ter esquecido. Eu até tenho um checklist no Notion que você pode duplicar para não esquecer de levar nada importante.

Não importa quão longa ou curta a viagem vai ser, eu costumo viajar com uma mala de mão e uma mochila. Isso exige que eu seja muito intencional sobre o que levo comigo. Eu divido minhas coisas entre a mala de mão e a mochila assim:

Na mochila, eu levo:
1. Todos os meus eletrônicos: gimbal, iPad, computador do trabalho, fone de ouvido com cancelamento de ruído, câmera, power bank e carregadores
2. Todos os líquidos: Remédios, loções, produtos para cabelo
3. Um casaco ou moletom, um par extra de roupas de baixo e uma camiseta
4. Passaporte, dinheiro, joias e cartões
5. Uma garrafa de água vazia
Na mala de mão, vão:
1. Todas as minhas roupas: casacos levinhos, roupas de baixo, touca difusora para os meus cachinhos;
2. Tudo que não tenha bateria: tripé, brindes da empresa, pau de selfie e chinelos.

Antes do aeroporto

Comecei a usar organizadores de mala porque me ajudam a manter minhas roupas organizadas, principalmente quando tenho pouco tempo entre as viagens para lavar tudo. Então, sempre que estou fazendo as malas para voltar para casa, coloco todas as minhas roupas sujas em um organizador só, para que seja fácil encontrar o que preciso lavar antes da próxima viagem.

Sempre faça um teste de peso da mala. Um bom parâmetro é tentar levantar a bagagem de mão sobre a cabeça para ter certeza de que você pode levantá-la sem ajuda. A equipe de pessoas comissárias de bordo sempre pode te ajudar, mas isso é uma boa medida para garantir que você consegue carregar seu próprio peso.

No aeroporto

Passando pela segurança do aeroporto, irão te solicitar que você retire todos os líquidos e eletrônicos maiores de suas malas. Manter tudo em um só lugar ajudará você a ficar livre mais rapidamente. Como você não pode levar nada com mais de 100ml no vôo, lembre-se de esvaziar sua garrafa de água antes de entrar na fila. Você sempre pode encontrar um bebedouro para encher a garrafa novamente depois que estiver na área de embarque.

Podem te pedir despachar sua mala de mão no portão. É uma boa ideia planejar a arrumação da sua mala em torno dessa possibilidade. Manter todas as baterias com você é uma boa medida para que você não precise abrir a sua mala no chão do aeroporto para tirar coisas.

3. Pesquise como vai se locomover no seu destino

Pesquise como se locomover na cidade em que você estará. Sempre procuro informações sobre o quão fácil é se locomover pela cidade. Esta etapa me ajuda de duas formas:

Reduz a ansiedade de não saber onde eu estou, especialmente se eu não falo o idioma nativo.
Ajuda a me preparar para quaisquer surpresas que possam surgir, como por exemplo, greves no transporte público.

Por exemplo, na primeira vez que fui à Irlanda, descobri que Uber e táxis são “difíceis” por lá. Todos os motoristas do Uber são, na verdade, motoristas de táxi. Você também precisa sair mais cedo ou agendar táxis com antecedência. Eles também usam um aplicativo chamado Free Now, que exige que você confirme seu perfil recebendo um SMS.

Os ônibus em Berlim podem ser um pesadelo, mas os trens e trams funcionam muito bem. O Google vai te ajudar a se locomover e escolher as linhas corretas, mesmo que você não fale alemão. Outra dica é baixar o aplicativo do BVG para comprar bilhetes na hora, mas preste atenção ao tipo de bilhete e escolha o ponto de partida correto. Pode haver pessoas verificando seu ele no vagão do trem/tram.

4. Se você precisar estar com conexão à internet o tempo todo: eSIM é pra você

Se você precisar de internet enquanto estiver fora do seu país, compre e configure um eSIM (cartão SIM eletrônico) antes de ir. Eu uso um eSIM da Airalo. A Airalo tem uma infinidade de pacotes e funciona em muitos países. Por já estar no seu celular, é mais fácil do que comprar um novo SIM toda vez, diminuindo a carga de decisão. Por serem digitais, o uso de um eSIM também gera menos lixo.

Outra coisa boa, o plano de dados ou celular que você escolher pode expirar, mas o eSIM em si não, então você só precisa configurar o eSIM uma vez. Comprei um eSIM de dados global que posso adicionar mais pacote de dados a ele sempre que precisar viajar novamente.

Apenas lembre-se de saber como configurá-lo antes de viajar, pois você vai precisar de uma conexão estável à Internet.

5. Se prepare para tirar os sapatos

Se prepare para tirar os sapatos. Este é algo que a maioria de nós esquece. Dependendo de vários fatores, você podem te pedir a tirar os sapatos e colocá-los na máquina de raio-X. Evite sapatos que possam ficar presos ou que exijam muito esforço para tirar ou calçar novamente.

6. Sem ruído é melhor

Tenha um bom par de fones de ouvido com cancelamento de ruído. Meu favorito até agora é o Sony WH-1000XM3. Eu continuo pensando em fazer um upgrade do meu para uma versão mais recente dele. Ainda assim, este me serve tãaaaao bem que ainda não consigo justificar a compra de um modelo novo para mim mesma.

Comprei o Sony WH-1000XM3 há cerca de 4 anos. Além dos seus recursos, gosto que a bateria dura muito tempo mesmo depois de tanto tempo de uso e que você pode configurar o nível de cancelamento de ruído. Não há nada mais chique do que não ouvir os ruídos do avião durante um voo noturno de 8h.

7. Jet-Lag é real

Certifique-se de se respeitar. Se você nunca cruzou fusos horários antes, você pode ficar se cobrando e sentir que “você deveria estar aproveitando mais isso”, porém lembre-se de que nossos corpos precisam de tempo para se ajustar a novas rotinas e fusos horários.

Para mim, leva cerca de 5 dias para se ajustar completamente a um novo fuso horário. É assim que meu corpo funciona. Mesmo comigo indo para a cama e levantando na hora certa todos os dias, ainda me sinto cansada ou que deveria estar dormindo em horários estranhos. Fazer exercícios e ter um plano para trabalhar ou turistar ajuda a combater esse sentimento, mas se eu puder, tiro sonecas depois do almoço e faço longas caminhadas para me cansar antes de dormir.

Recapitulando

Resumindo, aqui está o que você precisa manter em mente:

🎟️ Faça seu check-in on-line se possível;
🧳 Faça as malas com intenção;
📱 Encontre um plano de telefone que funcione para você; eSIM é ótimo pra isso;
👟 Se prepare para tirar os sapatos;
🎧 Fones de ouvido com cancelamento de ruído são REALMENTE úteis;
🗺️ Confira como se locomover pela cidade antes mesmo de chegar lá;
😴 Jet-Lag é real. Respeite seu corpo.

Antes de ir, gostaria de deixar uma dica bônus pra você: tire mais fotos do que você acha que precisa. Sempre chego em casa sentindo que poderia ter mais fotos ou vídeos, mesmo que não poste.

Projetos Brasileiros para contribuir nesse #Hacktoberfest 2022

Sat, 01 Oct 2022 05:00:00 +0000

Parece que esse ano passou num passe de mágica, Outubro já está aqui de novo e mais uma vez o evento mais esperado mundo open source: #Hacktoberfest.

Desde 2017 essa lista aqui acontece para te ajudar a fazer os seus pull requests/merge requests e participar dessa festa que dura um mes todo. Então aqui vai! Uma lista toda repleta de projetos brazileiros pra você contribuir nesse mês de Outubro!

Edições anteriores

2017, 2018, 2019, 2020, 2021.

Regras para entrar nessa lista

As regrinhas do ano passado se repetem:

Ser um projeto criado/desenvolvido/mantido por brasileiras(os);
Precisa ser um projeto, não pode ser uma organização, caso tenha mais de um projeto da organização precisa ser um PR por projeto com uma entrada por projeto
Ter pelo menos uma issue aberta.

Avisos para 2022

Os projetos continuam separados pela linguagem principal pra facilitar as buscas pra quem lê e também em ordem alfabética pela linguagem. 😉

Assim como em 2021, qualidade é o mais importante então se liga que dois PRs inválidos resultará em desqualificação por período indeterminado!

Para um PR ser considerado inválido, ele deve ser marcado com as tags spam ou invalid. Então é bom tentar fazer PRs de qualidade!

Relembrando que para tornar seu PR válido para a hacktoberfest você precisa ter algumas coisas. PRs apenas contarão se:

O PR precisa ser aberto em Outubro (entre os dias 1 e 31);
O PR preicisa acontecer num projeto que tem o tópico hacktoberfest ou ser marcado com o rótulo (label) hacktoberfest-accepted por um mantenedor ou ser aceito (merged) ou ser aprovado pelo processo de revisão (review).

Mais informações no site oficial (em inglês).

Por último, nesse outro artigo tem 5 Dicas Para Fazer o Seu Pull Request Brilhar ✨ e pode ser útil.

Happy Hacking! 🎉

C#

C

CSS

Clojure

C++

Elixir

Go

JavaScript

Julia

Kotlin

Lua

PHP

Pearl

Python

Ruby

Scala

Shell

TypeScript

Variados

How to create a new collection in MongoDB by joining two collections

Tue, 27 Sep 2022 08:00:00 +0000

If you use MongoDB, you probably understand all there’s to know about it, so I recommend you skip this blog post here, but if you are starting with MongoDB, see this blog post as a gentle introduction 😉.

Before starting

This blog post assumes you already have an account set up with MongoDB. Remember that if you don’t have one yet, you can create one for free here, and MongoDB has a free tier you can set up while creating your account.

You’ll be using the sample data from MongoDB to learn how to do an aggregation and create a new collection.

Getting acquainted with the data

In Mongo, a dataset is called a collection; think of it as a special spreadsheet. Whereas the records in a spreadsheet are lines, in MongoDB, a record is called a document. You’ll use the collection sample_mflix that contains movies, comments, users, etc.

Make a basic filter

Your objective is to create a collection containing all the comments each movie received in August 2002.

Start by going into the project’s database. My project is called “Project 0” and has the “Example” database comprising three databases and 15 collections.

Each project has a set of tabs, one of which is the “Collections” tab, where you can see the databases and the documents in each collection, as shown in the image above. From within the Collections tab, you can see the data and make simple queries if you want.

{date: {$gte:ISODate('2002-08-18')}}

For example, the query above shows every document with a date value later than August 18th, 2002.

Using queries like that is great to see the preliminary results of the collection you are trying to build. But to actually create the collection, we need to use aggregations.

Constructing the aggregation

Aggregations are one way you can build collections inside MongoDB, and there’s a tab for that, as shown in the image below.

To see the Aggregation tab, you need to click on the collection you want to investigate or use as the basis for your new collection. On the aggregation tab, you’ll see the pipeline builder. A pipeline is a set of steps; each step is called a stage; each stage does one thing and one thing only. You will do three stages:

Filter comments based on a date;
Add the movie’s details into each comment;
Output the results into a brand new collection.

Filter comments

To avoid dealing with unnecessary data, that is, data outside of your interest date window, the first thing you’ll want to do is find the comments in that particular period (August 2002).

On the drop-down menu for the first stage, select the $match operator; this operator will allow you to filter the records based on the date. Note that once you select the operator, Mongo will auto-populate the editable field with the standard structure for that operator.

Now you need to add the following code in the query section there:

Once that is done, you’ll see that the sample result will start displaying.

Now let’s break down each step of that operation, shall we?

Lines 1-4: Just comments, mainly to explain what the operator is. Note that MQL stands for MongoDB Query Language;
Lines 6 (date:): corresponds to the field you want to use to filter your date;
Line 7 ($gte:ISODate("2002-08-01")): this line uses the $gte operator to grab all dates after the date returned in ISODate format;
Line 8 ($lt:ISODate("2002-08-31")): this line uses the $lt operator to grab all dates before the date returned in ISODate format.

This operator result will be all the documents between August 1st and August 31st 2002.

Adding movie information to each comment

You’ll notice that the comments don’t have the movie information, but the movie identification number (ID) is present, as shown in the image below.

Including the movie information in the filtered comments you just got from the first stage is the second step of our aggregation. Click the “Add stage” button below the first stage to start working on adding the movie information to the collection using the $lookup operator.

The $lookup operator does a “left outer join”. Think of it as a “filtered join”. Based on the collection on the “left” (comments), select the documents on the “right” (movies) that match a given field in both, in this case, the movie id. This way, we don’t have to care about removing movies without comments, but all comments from the time window.

On the drop-down menu for the second stage, select the $lookup operator, as shown in the image above. Once again, Mongo will pre-fill the operator sample code, and you can update the code section with the code below.

Once more, let’s break down each step of that operation:

Lines 1-9: Just comments, mainly to explain what the operator is;
Line 11 (from: "movies",): Since the left side in the dashboard is the collection from which you are running the pipeline, this is where you define the “right” side of the join, so you chose the “movies” collection to add the movie information into the comments;
Line 12 (localField: "movie_id",): the field on the current collection (comments) that correspond to a field in the other (movies) collection;
Line 13 (foreignField: "_id",): the field on the other collection;
Line 14 (as: "movie_info"): the field name to add information in, note that the lookup will add the information as an array.

And you should see the results show up like in the image below.

All the data manipulation is done. Time to save the results and actually create your new collection.

Save the results

Once again, click the “Add stage” button to create a stage that outputs the result into a new collection, and on the drop-down menu for the third stage, select the $out operator.

Now update the code in the code field in the out section with the code below.

Let’s break down this part.

Lines 1-4: Just comments, mainly to explain what the operator is;
Line 5 ('augustmoviescomments'): is the name for the new collection;

After filling out the new collection’s name, you should click the “Save documents” button.

Once the collection is created (it might take a few seconds), you’ll see a message stating that documents were persisted in the collection and a “Go to collection” link that you should click.

Clicking the “Go to collection” link will open a new tab. If you do not want to see another tab, refresh the page, and you’ll see the augustmoviecomments show up on the left-hand side menu.

Now that your collection is ready, you can see the collection analytics data, like how many activities were logged and how much space that takes into our storage.

Recap

Now you know how to create collections by aggregating two other collections using pipelines. You also know:

Datasets in MongoDB are called collections;
One collection is a set of documents;
To create collections by joining other collections, you can use pipelines;
Pipelines are a set of steps called stages;
Each stage does only one thing.

Now you can explore what else to use pipelines for.

Let's talk about JWT

Sat, 30 Apr 2022 03:00:00 +0000

First talk at PyCon US was amazing. If you missed it or need a recap, here it is:

Como é se preparar para palestrar pela primeira vez num evento tech presencial

Sun, 24 Apr 2022 01:34:34 +0000

Se nada mais, compartilhar conhecimento é uma experiência feliz. Pense na primeira vez que você aprendeu a fazer algo. Que realmente aprendeu. Não foi incrível? Você não queria contar para todo mundo e ver a reação das pessoas quando vissem aquela coisa massa?

Eu sei que sim. Esse é o mesmo sentimento que tenho em mente quando estou criando um novo conteúdo, seja um artigo pro blog, um vídeo, um episódio de podcast ou uma nova palestra. É sempre a mesma coisa. Eu quero compartilhar essa coisa legal com qualquer pessoa que queira ouvir.

O problema é que, nos últimos dois anos, tenho falado para uma câmera. Eu tive que mudar a interação e as perguntas que eu normalmente fazia para o público ninguém poderia responder. Claro que tinha os chats, mas não era a mesma coisa, e tudo bem, mas sinto falta da troca. É como falar com o vazio e nunca obter uma resposta de volta.

Eu tinha esquecido como acontece a antecipação com a felicidade antes da viagem. Planejar a palestra, preparar a mala, fazer uma anotação mental para imprimir cartas de convite, pegar o passaporte e assim por diante.

Depois de dois anos, poderei fazer perguntas e ver a luz acender no rosto das pessoas quando elas chegarem a uma conclusão que desejam compartilhar.

Pela primeira vez em muito tempo, farei as perguntas e haverá pessoas lá para de fato responder. É ótimo saber que não estarei mais falando apenas para uma câmera.

Se você dá palestra em eventos, pode não sentir pronto ou pronta para voltar à estrada ainda, e tudo bem. Leve o seu tempo e não se apresse. É difícil mudar hábitos de dois anos.

Mas, à medida que o mundo entra em um ritmo pós-pandêmico de nova normalidade, lembre-se de como se sentiu quando você compartilhou aquela coisa legal com outros seres humanos. Se prenda nisso para quando quiser voltar à estrada. Tenho certeza que será ótimo.

What does getting ready for the first time speaking in person at a tech conference feels like

Sun, 24 Apr 2022 01:33:34 +0000

If nothing else, sharing knowledge is a joyful experience. Think of the first time you learned to do something. Really learned. Didn’t it feel amazing? Didn’t you want to tell everyone and see their reactions when they saw that cool thing?

I know I did. This is the same feeling I have in mind when I’m creating a new piece of content, be it a blog post, a video, a podcast episode, or a new talk. It is always the same. I want to share this cool thing with anyone that will listen.

The thing is, for the past two years, I’ve been talking to a camera. I had to change the interaction and questions to the crowd into questions that nobody could answer back. Sure there were chats, but it wasn’t the same thing, and that is okay, but I miss the exchange. It feels like talking to the void and never getting an answer back.

I had forgotten how the build-up of happiness goes right before the trip. Planning the talk, getting the suitcase ready, making a mental note to print invitation letters, grabbing the passport, and so on.

After two years, I’ll be able to ask questions and see the people’s faces light up when they arrive at a conclusion they want to share.

For the first time in forever, I’ll ask the questions, and there will be people there to actually answer. It feels great to know that I won’t be only talking to a camera anymore.

If you talk at events, you may not be ready to get back on the road just yet, and that’s okay. Take your time, and don’t rush it. It is hard to change two years’ worth of habits.

But as the world falls into a post-pandemic rhythm of new normalcy, remember what it felt like when you shared that cool thing with other humans. Hold on to that for when you are ready to get back on the road. I’m sure it will be great.

Vamos falar sobre JWT

Thu, 31 Mar 2022 03:00:00 +0000

Você consegue conferir a palestra na íntegra aqui:

Primeiro ano sendo uma Developer Advocate 🥑

Tue, 29 Mar 2022 09:01:00 +0000

Antes de trabalhar com DevRel, eu pagava as contas sendo uma cientista de dados. Hoje eu posso dizer que troquei a ciência de dados para trabalhar em developer relations com sucesso já que atingi a marca de 1 um ano trabalhando como Developer Advocate! 🎉

Eu no primeiro dia de trabalho oficial em Março de 2021

Por isso achei que seria interessante escrever sobre os aprendizados deste ano e compartilhar isso com você que está lendo. Um pequeno aviso: esse texto é um pouco longo, então sente-se confortavelmente. 😉

O que eu costumava fazer antes de ser contratada como uma Developer Advocate

Um pouquinho de história antes de mergulhar nos aprendizados já que, talvez você não me conheça ou saiba com o que eu trabalhava antes.

Há algum tempo, eu costumava trabalhar como cientista de dados. No primeiro emprego que tive, eu cheguei a apresentar mais de 13 palestras sobre o projeto em que eu trabalhava, chamado de Serenata. Incluindo uma palestra em Taiwan, tudo isso em menos de um ano. O Serenata, é um projeto de tecnologia cívica e de código aberto que dependia de nós, pessoas desenvolvedoras e cientistas de dados, para espalhar a palavra sobre esse projeto para que ele pudesse prosperar.

Eu apresentando sobre Rosie, AI do Serenata, num Meetup lá em 2017

Além de apresentar palestras em vários eventos e conhecer muitas pessoas, também criamos muito conteúdo técnico para tornar o projeto mais acessível para quem não tem o conhecimento para ler e entender código. Você pode conferir a página do projeto aqui.

Mais ou menos na mesma época, eu também criei com amigos o Pizza de Dados, o primeiro e mais querido podcast sobre ciência de dados do Brasil. Compartilhar conhecimento em vários formatos virou uma paixão. Eu amo dar palestras, ministrar tutoriais, falar com pessoas e ajudá-las.

Acontece que isso tudo é grande parte de ser uma developer advocate. Eu só não sabia disso naquela época. Veja bem, isso foi por volta de 2017, nós estamos agora em 2022, e developer relations ainda é algo muito novo no Brasil, então imagina como não era lá em 2017.

O que é Developer Relations ou Developer Advocacy?

Acho que a primeira pergunta que me fazem quando digo que sou uma developer advocate é “developer o quê?”. As pessoas geralmente não entendem logo de cara. Developer advocacy é algo tão novo que nem tem um nome oficial em Português, mas se vê sendo chamado de Evangelismo às vezes.

Por isso, não me surpreende quando as pessoas não entendem o que eu faço apenas dizendo o nome do meu cargo, mas com certa frequência rola um entendimento quando eu explico o que eu faço. Sempre rola um “ah, sim, combina com você”, especialmente se a pessoa conhece a minha participação nas comunidades de tecnologia.

Se você não sabe o que é DevRel, aqui está a breve descrição: Faço amizade com pessoas que desenvolvem para ajudá-las a entender tópicos complexos e trabalhar com mais eficiência. Agora, existem muitas maneiras de você alcançar esse objetivo, eu faço isso dando palestras, escrevendo artigos em blogs, vídeos, podcasts, etc.

Você pode estar se perguntando por que eu digo que “faço amizade”, certo? Bem, eu gosto de descrever dessa maneira porque as pessoas tendem a pedir ajuda a seus amigos e amigas, e esse é o meu objetivo maior, ser alguém que qualquer pessoa pode pedir ajuda, especialmente quando se fala de criar e manter software.

Palestras, tutoriais escritos, workshops, podcasts, vídeos e assim por diante, são apenas uma parte do processo de ser uma developer advocate. A parte que as pessoas costumam ver. Há também a outra parte, a parte em que você tem que fazer relatórios sobre eventos e iniciativas em que trabalhou. Você precisa testar novos recursos e fornecer feedback internamente. Você documenta os processos e ajuda a estruturar as formas de ajudar o negócio a ter sucesso. E tudo isso enquanto você passa parte ou a maior parte do seu tempo viajando para encontrar com as pessoas desenvolvedoras onde elas estiverem.

As relações com uma pessoa desenvolvedora são um tópico complicado se você pensar sobre isso. Você precisa ter muitas habilidades: habilidades técnicas, de comunicação e interpessoais, também senso de negócios, ser orientada a dados e ainda ser uma participante ativo de qualquer comunidade de tecnologia e colocar as pessoas em primeiro lugar. Isso me lembra esse tweet:

Developer advocacy is simple. You just need skills in engineering, marketing, business development, product management, content creation, and be a skilled communicator, both written and verbal. After that, the job really takes care of itself.
— Sean Falconer (@seanfalconer) February 4, 2022

Tradução livre: Developer advocacy é simples. Você só precisa de habilidades de engenharia, marketing, desenvolvimento de negócios, gerenciamento de produto, criação de conteúdo e ser uma pessoa habilidosa em comunicação, tanto na forma escrita, quanto na fala. Depois disso, o trabalho meio que rola sozinho.

Se você estiver considerando quais habilidades melhorar para se tornar DevRel, pense nas habilidades que mencionei neste artigo e tente desenvolvê-las no seu dia-a-dia. Acontece que a maioria dessas habilidades são úteis independentemente do seu papel e, quanto mais cedo você começar, mais fácil será a sua jornada para se tornar uma DevRel. 😉

Como eu decidi que DevRel era o que eu queria?

Além de palestrar em diversos eventos e conhecer várias pessoas enquanto eu trabalhava no Serenata, eu também criei muito conteúdo técnico sempre buscando fazer o projeto ser mais acessível para as pessoas que não tinham um conhecimento técnico para entender o código.

Depois de sair do Serenata, eu fiz questão de participar ativamente na comunidade Python, não importando onde eu estivesse trabalhando. Sempre que pude, dei palestras no meu tempo livre, mantive o meu blog e continuei gravando o Pizza de Dados.

Eu, Lele Portella e Ceci Vieira numa live stream

Em resumo, chegou um dia em que eu decidi que queria mudar o meu trabalho para que ele incluísse mais atividades de compartilhamento de conhecimento ao invés de só fazer isso no meu tempo livre. Com um pouco de sorte, na mesma época, a Auth0 estava tentando contratar uma pessoa developer advocate. Foi nesse momento que decidi agarrar a minha chance.

Antes de começar o processo seletivo, eu fiz o que eu sempre faço: pesquisa. Pesquisei mais a fundo o que queria dizer “ser DevRel” e aí numas sessões de pesquisa achei um ebook escrito por Sam Julien, naquela época, Head de DevRel na Auth0. O ebook chamava “Getting Started in Developer Relations”, e eu devorei o livro em menos de dois dias. Foi nessa hora que caiu a ficha: Eu já fiz isso antes… E eu amei fazer isso!

Como é o dia de uma Dev Advocate?

No lugar de falar sobre o meu dia, eu vou falar da minha semana por que eu acho que isso vai ilustrar melhor o que uma pessoa pode fazer na posição de DevRel.

Dia da semana	Atividades
Segunda	• Fazer a triagem dos pedidos de colaboração • Conferir as perguntas de pessoas embaixadoras • Praticar uma palestra que vou apresentar no dia seguinte e garantir que ajustes não são necessários
Terça	• Participar da reunião 1:1 com meu gerente direto • Participar da reunião 1:1 com um colega de outro time sobre uma iniciativa nova • Apresentar uma palestra num evento • Preparar o rascunho de uma palestra para uma chamada que acaba no fim da semana
Quarta	• Participar da reunião semanal do time • Documentar um processo novo • Escrever o rascunho de um novo vídeo que eu vou gravar • Revisar o trabalho da especialista de localização
Quinta	• Fazer análise de dados da newsletter enviada semana passada • Rascunhar um blog post que vai acompanhar o vídeo • Rascunhar uma amostra de código que vai ser usada no vídeo e no blog post
Sexta	• Participar da reunião semanal de alinhamento e novidades da empresa • Participar do happy hour semanal com os colegas de time • Revisar um blog post de um colega

Você pode fazer tudo que eu listei na semana acima e ainda ter uma agenda completamente diferente para semana seguinte, especialmente se você estiver viajando para participar de um evento presencial. Você ainda pode arrumar tempo para ajudar a comunidade em algo ou trabalhar em algum projeto pessoal.

Uma coisa eu garanto, isso tudo pode até parecer repetitivo - tudo que você faz é sempre sobre compartilhar conhecimento ou ajudar alguém -, mas nunca tem um momento sem graça.

Onde o time de DevRel se encontra em uma organização?

Pelo que andei vendo, existem três locais para encontrar o time de developer relations dentro de uma empresa:

Engenharia: como parte do time de engenharia de software
Marketing: como parte da organização de marketing
Produto: como parte de desenvolvimento de produto

Onde você encontra o time geralmente dita como o time é visto por outras pessoas na empresa: Se é um cargo técnico e se é compensado como tal. No caso da Auth0, o time de DevRel está sobre a organização de Developer Marketing debaixo do guarda-chuva de Marketing e é visto como um cargo técnico.

O que eu aprendi como cientista de dados e ainda uso diariamente?

Acima de tudo, trabalhar com ciência de dados me ajudou a desenvolver a habilidade de comunicar conceitos complexos com facilidade para qualquer audiência, habilidade que levo comigo em tudo que eu faço, mas além disso, existem outras habilidades que eu aprendi enquanto cientista de dados que uso diariamente. É importante ressaltar que algumas dessas habilidades se não todas elas podem ser desenvolvidas independentemente do seu trabalho. 😉

📆 Priorização

A pergunta que eu e meus colegas mais fazemos nas sessões de planejamentos sempre é: “O que vai trazer maior impacto pro que estamos tentando fazer?”. A cientista de dados que mora em mim sempre diz: Bem, depende do que estamos tentando otimizar, e por consequência me faz pensar em qual área queremos crescer. Qual a fundação que queremos construir para que possamos colher os frutos desse trabalho no futuro?

Pra ser sincera, essas perguntas se aplicam a qualquer trabalho de desenvolvimento de software também. A ciência de dados me ajudou a encontrar respostas baseadas em dados e observações do passado. Também me ajudou a definir um caminho saudável de crescimento com base nas informações disponíveis.

🗣 Habilidades de comunicação

A maior parte do que eu faço é: entender os pontos problemáticos e fornecer orientação para aliviar ou se livrar deles. Para fazer isso bem é necessário se comunicar e adaptar o estilo de comunicação baseado no público com quem se está falando.

Em um ano, você pode falar em mais de 10 eventos, todos eles com audiências contendo níveis variados de conhecimento, habilidades, stack favorita e muito mais. Você pode trabalhar em uma palestra para um evento mês que vem enquanto termina o material de um tutorial para um hackathon da semana que vem. Esses dois eventos requerem um formato diferente de comunicação e estruturação de conteúdo.

Eu tenho que escrever relatórios sobre os eventos e iniciativas que eu fiz ou contribui de tempos em tempos. Também preciso conversar com outros times na empresa para fornecer feedback em projetos e features. Comunicação está no centro de DevRel.

⏱ Time-boxing e criação de código de exemplo

Isso eu aprendi faz um tempão quando eu usava ciência de dados para aquele projeto Serenata e, acredite se quiser, eu ainda uso diariamente, especialmente para saber quando pedir ajuda. Por exemplo, eu tinha que implementar uma aplicação de exemplo para demonstrar uma feature de extensibilidade nova: Auth0 Actions.

Eu tinha um plano.

Eu queria fazer uma aplicação baseada em um dos tutoriais que temos no Blog da Auth0. Eu separei um tempo para trabalhar nisso: “Eu tenho 2 dias para para fazer isso funcionar e, se não funcionar, eu replanejarei”. Dois dias se passaram e adivinha? Não consegui fazer a amostra de código funcionar como eu queria. Eu percebi que tava complicando uma coisa que deveria ser simples: a parte de código que não tinha nada a ver com a feature.

A parte boa disso tudo, é que eu não tava sozinha nisso tudo. Chamei um colega de trabalho para conversar. A gente bolou um plano juntos para fazer a minha ideia dar certo usando uma aplicação beeeem mais simples e já pronta. O resultado dá pra ver aqui:

Time-boxing é uma técnica fundamental para me dar tempo de testar as coisas que eu to fazendo e saber quando pedir ajuda. Principalmente, me ajuda a ter tempo para redirecionar o meu plano caso seja necessário. Assim eu consigo ser efetiva em criar coisas novas em um tempo aceitável.

📈 Análise de dados básica

Uma pergunta constante em DevRel, não importando a empresa que você trabalha, é: “Como medimos sucesso?” E, às vezes, é bem difícil responder isso. É aí que um entendimento básico sobre dados se torna relevante.

Por exemplo, eu lidero e mantenho a newsletter para pessoas desenvolvedoras Zero Index. Ela sai mensalmente e contém uma coleção de conteúdo curado para pessoas desenvolvedoras — aliás se você quiser, dá pra assinar e conferir edições passadas aqui. Dá pra dizer que uma definição de sucesso para esse projeto seria enviar a newsletter para mais pessoas, mas eu vejo muito mais possibilidades além disso.

A gente quer enviar para mais devs, claro, mas queremos enviar informação que seja relevante, mas como você pode entender isso se você não sabe medir a relevância de uma informação? Provavelmente você vai trabalhar com pessoas que podem te ajudar a entender os dados, né?

Como eu ainda tenho o coração de cientista de dados, eu coloquei os músculos que desenvolvi durante anos e apliquei isso para tentar entender como as pessoas interagem com conteúdo que a gente compartilha. Fiz uns gráficos, e dei uma olhada na estrutura e como ela mudou ao longo do tempo. Tudo isso resultou em ideias de testes A/B que pudemos fazer com o intuito de melhorar a experiência de quem lê a newsletter.

Você pode deixar a ciência de dados, mas a ciência de dados nunca te deixa.

Então é verdade que de tempos em tempos eu ainda uso dados para entender o mundo à minha volta mesmo que isso não seja parte da descrição do meu trabalho. 😉

Coisas novas que tive que aprender

Veja bem, muitas coisas novas apareceram junto com a nova carreira especialmente no domínio de identidade, autenticação e autorização, que eram algo completamente novo para mim, além disso também surgiram coisas sobre criação de conteúdo para uma empresa e não para mim ou meus amigos.

Reaproveitar conteúdo

Uma coisa engraçada, quando estamos escrevendo código queremos usar o conceito DRY (don’t repeat yourself) de não ficar repetindo código, mas quando se fala de conteúdo, nós fazemos o oposto. Reaproveitar conteúdo é algo bom. Um artigo no blog pode virar um fio no twitter, uma palestra, um episódio de podcast, ou até mesmo um vídeo no YouTube.

Você precisa fazer o seu conteúdo “escalar” e distribuir esse conteúdo em plataformas variadas é uma forma de fazer isso, principalmente por que pessoas diferentes aprendem de jeitos diferentes. Por exemplo, algumas pessoas, como eu, preferem conteúdo escrito, outras preferem vídeo ou podcasts e assim por diante. Para você ser efetiva no seu trabalho você provavelmente vai fazer mais um formato ou se juntar com algum colega para que você faça um formato e essa outra pessoa cuide de outro formato.

Identidade, autorização e autenticação

Como eu trabalhei com ciência de dados na maior parte da minha vida profissional, os desafios ligados ao mundo da identidade não era algo que eu tinha contato, pelo menos não até eu entrar na Auth0. Identidade é difícil. É complexo e tem várias sutilezas que às vezes passam despercebidas até para pessoas desenvolvedoras mais experientes.

Vale salientar que identidade aqui não é o seu RG ou CNH mas sim quem você é no mundo da tecnologia, seus cadastros de usuário, seus acessos a sistemas e muito mais.

Vamos ser honestas, por causa de quão difícil identidade pode ser, autenticação e autorização são sempre uma preocupação secundária para muitas pessoas desenvolvedoras. Não é comum ter uma abordagem que lida com identidade primeiro - tenha em mente que isso deve mudar nos próximos anos.

A parte boa disso tudo, é que eu abraço os desafios trazidos por problemas e conceitos complexos. Eu gosto de entender essas coisas e destrinchá-las para tornar tudo isso mais fácil de absorver. Eu vejo isso como algo que eu fazia quando eu começava um cargo novo em ciência de dados: Eu estudava os dados e o negócio para entender os problemas que a empresa estava tentando resolver e começava a construir coisas a partir desse conhecimento.

Então eu não comecei a fazer de fato DevRel, mas também eu estava aprendendo coisas novas e complexas. Eu me divirto aprendendo conceitos como MFA e SSO dessa vez não só como usuária, mas também como desenvolvedora. Eu ainda estou longe de ser uma expert nesse novo domínio, mas eu estou adorando cada pedacinho dessa jornada de conhecimento.

Desenferrujando os conhecimentos sobre API e desenvolvimento web

Além da parte sobre identidade, tinha mais uma coisinha que eu precisei relembrar conceitos e sobre como fazer: APIs e aplicações web. Eu não só trabalhei com ciência de dados, mas também trabalhei uma parte do tempo como desenvolvedora web, então em algum ponto da minha carreira eu sabia sobre APIs e como construí-las.

A verdade é que, embora os modelos que eu costumava fazer deploy na AWS Sagemaker tivessem endpoints, já fazia um bom tempo que eu não desenvolvia APIs de verdade. Então eu tive que relembrar conceitos sobre RESTful, OpenAPI e outros verbos HTTP além de PUT, POST e GET.

Entregar conteúdo e não código

Se eu tivesse que dizer quanto tempo eu passo codando, acho que só chega a 10% do meu mês. Apesar de que eu ainda escrevo código de vez em quando — até JS eu escrevi outro dia — a quantidade hoje em dia é bem menor se comparado com a época que eu fazia análise de dados e criava modelos de machine learning.

Tenha em mente que isso não quer dizer que todas pessoas em DevRel são assim… Até mesmo no meu time temos developer advocates que escrevem muito mais código. A quantidade de código escrito vai depender das iniciativas que cada developer advocate cuida. Afinal de contas, nós ainda somos pessoas desenvolvedoras e mantemos sites como jwt.io ou webauthn.me, isso quer dizer que parte dos meus colegas passa mais tempo escrevendo código do que eu especialmente para manter essas iniciativas.

O meu foco não escrever código, mas sim ajudar pessoas e ensiná-las como implementar coisas nas suas aplicações. Eventualmente eu acabo escrevendo código para isso, afinal de contas eu estou ajudando a aumentar a adoção de um produto para devs, mas mais do que codar, a minha obrigação é entender como construir aplicações para ajudar outras pessoas a fazerem o mesmo.

Eu apresentando minha palestra sobre Auth0 no Developer Day 2021, clica aqui pra ver o video por completo

Agora, ao invés de resolver bugs, eu devo entregar um blog post que ensina como implementar fluxos de login/logout numa aplicação de página única em Python por exemplo. Isso não me impede de fazer contribuições para os SDKs da Auth0, isso só quer dizer que eu foco em outras coisas além do código.

No caso da Auth0 em particular, os códigos estão quase prontos. Nós temos uma biblioteca imensa amostras de codigo e quick-starts. Eu posso me apoiar em materiais feitos por pessoas que entendem muito desse novo domínio, e criar coisas novas com o foco em compartilhar conhecimento e, se eu conseguir fazer tudo isso ser divertido, ainda “ganho pontos extras”.

Empresas menores podem ter responsabilidades relacionadas a atividades para comunidades, como por exemplo gerenciar fóruns e comentários em redes sociais além de ter algum envolvimento com a parte de experiência da pessoa desenvolvedora (developer experience), vale salientar que isso não acontece na Auth0, nós temos times específicos focados em cada um desses meios, mas trabalhamos em conjunto para ajudar as pessoas que usam a gente.

Vale apontar que a forma que a Auth0 lida com DevRel eh bem madura e que isso nem sempre é o caso de outras empresas. Para esses casos menos maduros, eu consigo ver que pessoas de DevRel passariam mais tempo escrevendo código do que eu por exemplo.

A progressão de carreira

A parte boa de fazer DevRel num time bem estabelecido, entre outras coisas, é que a sua vida fica um pouco mais fácil quando você começa a pensar na sua progressão de carreira.

Na Auth0 temos a pessoa contribuidora individual (IC) esse caminho pode levar ao Staff Developer Advocate e Lead Developer Advocate, e também tem o que eu gosto de chamar de caminho da liderança, onde você consegue seguir para posições como Diretora de Developer Relations. É importante salientar que essas divisões não impedem as pessoas de virar gerente uma vez que elas são staff e vice-versa, mas esses caminhos estão lá para garantir que cada pessoa tem uma forma de se desenvolver e avançar na carreira.

Outras empresas podem ter progressões de carreira diferente da que descrevi. Essas posições também podem ser alteradas ou adaptadas com o crescimento do time. Quem sabe? Pode ser que um dia eu vire diretora de Developer Relations América Latina… As possibilidades são muitas.

Recapitulando

Esse ano foi muito divertido. Eu me sinto ainda mais criativa quando olho pro meu trabalho. Eu consigo ajudar pessoas. Deu pra perceber que eu amo o que eu faço? Criar conteúdo para ajudar outras pessoas é a minha missão de vida e é maravilhoso conseguir fazer isso no meu trabalho.

Mal posso esperar pra ver o que vai rolar daqui pra frente.

First year as a Developer Advocate 🥑

Tue, 29 Mar 2022 09:00:00 +0000

Before doing DevRel for a living, I used to pay the bills by being a data scientist. Today I can say that I successfully switched from being a Data Scientist to be a Developer Advocate for a whole year! 🎉

Me on the first day of work March, 2021

So I thought I share the learnings from this year with you. Also, full disclaimer, this will be a long one, so sit comfortably. 😉

What I used to do before being hired as Developer Advocate

A little history before we dive into the learnings since you may not know me or what I used to work with.

So a long time ago, I used to work as a data scientist. On the first job I ever had, I actually gave over 13 talks about the open-source civic tech project I was working on at the time called Serenata, including one talk in Taiwan and all of that in just one year. The project relied on us, the devs and data scientists, to spread the word about it so it could thrive.

Me presenting about Rosie, Serenata's AI, on a Meetup back in 2017

Besides talking at a number events and meeting many people, we would also create a lot of technical content to make the project more accessible to those without the technical knowledge to read and understand code. You can check out the page of the project right here.

Around the same time, I even created, with friends, a podcast about data science in Portuguese called Pizza de Dados. Sharing knowledge in various formats became a passion. I love to give talks, do workshops, and just talk to people and help in any way I can.

Turns out that this is a huge part of being a developer advocate. I just didn’t know it at the time. Notice this was around 2017, now it is 2022, and developer relations is still pretty new in Brazil, so imagine how it was back then.

What is Developer Relations or Developer Advocacy?

I think the first question I get asked when I say I’m a developer advocate is “developer what?”. People usually don’t get it. Developer advocacy is so new here that it doesn’t even have a name for it in Portuguese. So it isn’t surprising when people don’t get what I do by just stating my job title. What also happens is that they feel like they understand what it is once I explain it. Based on my community work some people usually are aware of, I get the “oh yeah, it suits you” comments.

If you also don’t understand what DevRel is, here’s the short description: I make friends with developers to help them understand complex topics and work more efficiently. Now, there are many ways you achieve that, I do it by giving talks, creating blog posts, videos, podcasts, etc.

You may be wondering why I say I make friends though, am I right? Well, that’s because people tend to ask their friends for help, and that is my utmost goal, be someone anyone can reach out to and ask for help, especially when coding is involved.

Talks, written tutorials, workshops, podcasts, videos, and so on are only part of the process of being an advocate. The part people usually see. There’s also the other part, the part where you have to do reporting on events and initiatives you worked on. You have to test out new features and provide feedback internally. You document processes internally and help structure ways to help the business succeed. And all of that while you spend some or most of your time traveling to reach developers where they are.

Developer relations is a complicated topic if you think about it. You have to have a lot of skills: technical, communication, and interpersonal skills, also business sense, be data-driven while still being an active participant of any tech community and putting people first. This reminds me of this tweet:

Developer advocacy is simple. You just need skills in engineering, marketing, business development, product management, content creation, and be a skilled communicator, both written and verbal. After that, the job really takes care of itself.
— Sean Falconer (@seanfalconer) February 4, 2022

If you are considering what skills to improve to become a DevRel, think of the ones I mention in this post and try to develop them along the way. Turns out that most of these skills can be used no matter what job you have, and if you start working on them earlier, it will make your path to become a DevRel a lot easier. 😉

And how did I decide DevRel was my thing?

Other than talking at many events and meeting a lot of people while working at Serenata, I would also create a lot of technical content seeking to make the project more accessible to those without the technical knowledge to read and understand code.

After moving on from Serenata, I made sure I was active in the Python community, no matter where I worked. In my spare time, I gave talks whenever possible, maintained my blog, and kept recording episodes for the Pizza de Dados podcast.

Me, Lele Portella and Ceci Vieira on a live stream

Long story short, some day I decided to change my day job to have more knowledge sharing instead of it just being a spare-time effort. Luckily around the same time, Auth0 was hiring a new developer advocate. So, I decided it was time to give it a chance.

Before the hiring process started, I did what I usually do: research. I researched what DevRel was, and guess what? Sam Julien, at the time, head of DevRel at Auth0, had an ebook called “Getting Started in Developer Relations”, which I read in two days, and that’s when I had that a-ha moment: I did this before… and loved it!

How is the day of a Dev Advocate?

Instead of speaking of my day, I’ll talk about my week as it draws a fuller picture of what one might do daily as a DevRel.

Day of the week	Activities
Monday	• Go through the collaboration requests • Check in with ambassadors questions • Practice a talk I’m giving the following day and make sure that no adjustments are required
Tuesday	• Attend the 1:1 meeting with my direct manager • Attend the 1:1 meeting with a colleague from another team about a new initiative • Give a talk at an event • Prepare a draft of a talk for a CFP I need to submit by the end of the week
Wednesday	• Attend the team weekly meeting • Write documentation for a new process • Draft video outline for the new video I need to record • Review the work of a localization specialist
Thursday	• Data analysis on the results for the newsletter that came out last week • Draft blog post that will accompany the video • Draft the sample code for the video and blog post
Friday	• Attend the company all hands meeting • Attend the team weekly happy hour • Review the blog post of a colleague

You might do all of that in a week and have a very different schedule for next week, especially when traveling to attend in-person events. You might even squeeze in some community work during your week or work on personal projects.

One thing I can guarantee, even if this may seem repetitive — it is always about sharing knowledge and helping someone out — there’s never a dull moment.

Where does the DevRel team land in an organization?

From what I’ve seen, there are three main locations in an organization for placing a developer relations team:

Engineering: as part of the software engineering team
Marketing: as part of the developer marketing organization
Product: as part of the product development

Where you find the team usually speaks to how the developer relations team is seen by other peers in the organization: Whether it is a technical role and if it is compensated as such. In Auth0’s case, the DevRel team is under the Developer Marketing umbrella, and it is seen as a technical role.

What I learned as a data scientist and I still use daily?

If anything, data science helped me develop the skills for communicating complex concepts with ease for any audience, something I keep close to my heart at all times. But other than that, I still have some skills I learned as a data scientist that I use daily. Is worth noting that some, if not all, of these skills can be developed in other jobs too. 😉

📆 Prioritization

The question my colleagues and I always ask ourselves every planning session is: “What will bring the most impact to what we are trying to accomplish?”. The data scientist in me always says: Well, it depends on what we are trying to optimize for, which always gets me thinking about the area we want to grow. What is the foundation we need to build to collect the fruits from it in the future?

These questions apply to any development role, to be honest. Data science taught me to find the answers based on data and observations from the past. It also taught me to define a healthy path to grow based on such information.

🗣 Communication skills

Most of what I do is understand pain points and provide guidance for easing or getting rid of them. To do this, you have to know how to communicate and adapt your communication based on the public.

In a year, you may speak at more the 10 events, all of them varying in audience skill level, knowledge, preferred stack, and so on. I may work on a talk content to present at next month’s event while finishing up a workshop for a sponsored hackathon that will be held next week. Both have very different formats of communication.

I have to write reports about the events and initiatives I did or contributed to from time to time. I need to reach out to other teams in the company to provide feedback on projects and features. So communication is at the core of DevRel.

⏱ Time-boxing and creating sample apps

This I learned way back in the day when I used to do data science for that open source project, and I still use it daily, especially to know when to ask for help. For example, I had to code a sample app to demonstrate the new feature: Auth0 Actions.

I had a plan.

I wanted to make an app based on one of the tutorials we have on the Auth0 Blog, and I set aside time for it: “I have two full days to get this working, and if it doesn’t work, I’ll get back to the drawing board”. Two days passed, and I couldn’t get it to work the way I wanted. I realized I was overcomplicating the sample application.

The good thing is, I was not alone in this. I discussed it with a colleague and we figured out a way to do the same thing in a simpler environment. You can check the result here:

Time-boxing is fundamental to make sure that I test things, know when to ask for help, and I have time to go into a different path when needed. It also helps me effectively test new things and create my sample apps in a timely manner.

📈 Basic data analysis

One constant question in DevRel, no matter what company you work for, is “How do we measure success?” And that is sometimes hard to answer. So having a basic understanding of data is important.

For example, I lead the Zero Index Developer Newsletter. It comes out once a month, and it contains curated content for developers — by the way, you can sign up for it here. You could say that one definition of success would be delivering the newsletter to more and more developers, but the way I see it is much more than that.

We want to reach more developers, sure, we also want to provide relevant information. So how would you do that if you don’t understand how to measure it? You probably would partner up with the data people in the company, right?

Still being a data scientist at heart, I decided to flex my data analysis muscles and try to understand how developers interact with the content we share. I did some basic visualizations, a few bar plots here and there, and took a look at the structural changes in the content. All of that put together gave ideas on doing some A/B testing to deliver more quality content to subscribers.

You may leave data science, but data science never leaves you.

So from time to time, I still take a look at data to make sense of the world around me. 😉

What were the new things I had to learn?

There were a lot of new things, especially in the business of identity, authorization, and authentication, which was brand new to me. But there was also a lot about creating content for a company and not for myself.

Repurposing content

Funny thing, as developers, we learn to apply the DRY (don’t repeat yourself) principle to our code, but when the goal is to share content, we do the opposite. It is good to repurpose content. A blog post can become a Twitter thread, a talk, a podcast episode, or even a video on YouTube.

You need to scale your content by distributing it on many platforms, mainly because different people learn in different ways. For example, some prefer written content, others prefer video, and so on. To be effective, you will probably do more than one format or partner up with colleagues so that one of them can take care of other formats.

Identity, authorization and authentication

Since I worked on data science most of my life, the challenges of the identity world weren’t something I was in contact with, at least not until I started working at Auth0. Identity is hard. It is complex and has various subtleties that sometimes eludes even seasoned developers.

Let’s be honest, because of how hard it is, authentication and authorization are usually an afterthought for most developers. We aren’t used to an identity-first approach — be aware that this may change in the coming years.

The good thing is that I welcome the challenge of those complex concepts. I like to understand them and break them down into digestible pieces of information. The way I see it, it is the same thing I used to do when I started a new data science job: I would study the data and the business, understand what problems the company was trying to solve, and build from there.

So not only I started doing DevRel, I was also learning new things, new complex things. I find it really fun to understand concepts like MFA and single sign-on now as a developer and not as just a user. I’m still far from being an expert in the field, but I’m enjoying every little bit of the learning journey.

Brush the dust off of the API and WebDev knowledge

Apart from identity, there was one other little thing I needed to remember how to do: APIs and web apps. Other than data science, I spent some time being a web developer, so I did, at some point, understand APIs and knew how to build them.

The truth is that even though the models I used to ship on AWS Sagemaker had endpoints in them, it had been some time since I really used or developed APIs. So I had to remind myself things like RESTful, OpenAPI, and what other HTTP methods there were other than PUT, POST, and GET.

Deliver content and not code

If I had to say, out of my daily responsibilities, only 10% of the time I spend coding. Even though I do still code from time to time — I even wrote some JS the other day — it is a lot less than when you have to deliver data analysis notebooks and machine learning models.

Even in my team, this is not the case to all of the dev advocates, some of us code a lot more depending on what initiatives they are involved with, we are still developers, and we maintain sites like jwt.io or webauthn.me, which means some of my colleagues spend more time coding than I do especially to maintain these initiatives.

The thing is, my goal isn’t to code but to teach people how to implement things on their applications. Eventually, I have to code. After all, it is a product for developers that I’m driving adoption, but more than coding, you have to understand how to build an application to help others do so.

Me presenting my first talk ever about Auth0 on 2021's Developer Day, click here for the video

So instead of regularly fixing bug, I might deliver a blog post that teaches developers how to implement login/logout flows in a single page application in Python, for example. This does not prevent me from making contributions to our SDKs, is just that I focus more on other things than just coding.

For Auth0 usage in particular, the coding is mostly done. We have a great library of code samples and quick-starts. It is like sitting on the shoulders of giants. I can build on top of what has been created to do new things while focusing on sharing knowledge, and if you can make it fun for the ones learning, you get extra points.

Smaller companies may also have responsibilities related to community tasks like managing forums and comments on social networks, as well as some involvement in developer experience, this is not my case at Auth0, we have different teams for each of these things, but we all work together to help our customers.

Is worth pointing out that Auth0 has a very seasoned approach to DevRel, which may not be the case for younger organizations. In this case, I foresee that all advocates would spend more time coding than I usually do.

The career path

The good thing about doing Developer Relations at a well-established team, among other things, is that it makes your life easier when you think of what you want to do in a growing career.

At Auth0 there is the individual contributor (IC) path that takes you up to the Staff Developer Advocate and Lead Developer Advocate, and there’s also what I like to call the leadership path, where you can follow the manager ladder and can take up to positions such as Director of Developer Relations. Is worth noting that these divisions do not prevent you from becoming a manager or an IC later, is just a guide so you can make sure you are developing yourself.

Other companies may have different career progression in their sights. These positions can be changed or adapted as the team grows. Some day I might be Director of Developer Relations Latin America. Who knows? The possibilities are endless.

Wrapping up

This has been an exciting year. I feel even more creative when I look at the work I do. I see that I can help people. I also love what I do at work. Creating content to help others has been my life’s mission, and it is awesome to do that for a living.

I can’t wait to see what the future holds.

Esquenta 2022 - Carreira: DevRel - Feministech 16.3

Mon, 28 Feb 2022 13:00:00 +0000

Quer saber o que é DevRel? O que quer dizer Developer Relations, Developer Advocacy ou Evangelism? E entender como eu vim parar nesse mundo novo?

Você confere tudo lá no esquenta da temporada nova do Feministech Podcast ou apertando o play ali em baixo 👇

Meu processo de criação de conteúdo

Sat, 12 Feb 2022 11:00:00 +0000

Eu tenho mantido um blog por alguns anos e, desde que, criar conteúdos passou a ser meu ganha pão, eu tenho pensado bastante sobre métodos de escrita.

Assim como programar bem, escrever bem, requer prática e dedicação. Depois de um certo tempo escrevendo, você passa a ter um sistema, uma coleção de passos que você sempre segue e aí você começa a pensar em como otimizar meu trabalho para obter resultados cada vez melhores e entregas de alto nível mais rápidas.

Esse texto é uma reflexão que eu estou fazendo sobre o meu “método de escrita”, que vale salientar é o mesmo método que uso para qualquer conteúdo que eu faço como palestras, vídeos e podcasts. Além disso, eu quero te mostrar de forma prática como você pode passar a escrever.

Por onde eu comecei

Bem, se você me acompanha pode saber que eu não era a melhor aluna de português e redação na escola e eu nunca quis ser escritora, mas o mundo dá voltas e cá estamos. Escrever virou um hábito, depois passou a ser um gosto e hoje, posso dizer, que eu adoro escrever.

Pra mim escrever é como eu organizo as minhas ideias, como eu entendo o mundo e os conceitos que eu estudo, como eu fixo informação. É parte tão integral do meu dia-a-dia de comunicação assíncrona que, se você tirar escrever de mim, eu provavelmente ficarei perdida.

Meu primeiro blog era um site que eu usava como caderno de notas, escolhi um tema e coloquei no ar. Ele era mais pra mim do que pra qualquer outra pessoa e, acima de tudo, o seu objetivo não era ser um blog. Ele era um site onde eu colocava anotações e aprendizados.

Acredito que o foco do meu primeiro site não ser o conteúdo, tirou de mim toda a pressão que vem com “e se as pessoas não lerem o que eu escrevo?” ou “e se as pessoas me julgarem?” ou ainda “e se eu cometer erros?”, me dando tempo e um lugar seguro para praticar a escrita em si.

Como o processo de escrita era relativamente custoso, já que eu tinha que recriar os markdowns que geravam os posts manualmente, e no boom inicial do Medium, eu passei um tempo escrevendo por lá, justamente pela facilidade de escrever em qualquer lugar.

Depois de um tempo o Medium começou a cobrar por leitura e bloquear pessoas com paywall. Foi então que eu decidi sair da plataforma e voltar a manter o conteúdo num lugar livre e que pessoas pudessem acessar sem pagar.

Depois de mais de um ano escrevendo nesse site eu decidi transformá-lo em um blog “content-first”. Um blog de verdade onde o foco era o conteúdo e que fosse melhor para pessoas encontrarem o que elas estavam procurando. A primeira coisa que eu fiz foi trocar de tema e passar usar cards para dar ênfase no conteúdo.

A prática leva a perfeição

Como falei antes, escrever é como programar, você precisa praticar diariamente, estudar, ler o material de outras pessoas para ver como elas enquadram seus assuntos, revisar o que fez e soltar para o mundo. Mas se você estiver começando agora isso pode parecer assustador e, muitas vezes, eu vejo pessoas focando nas coisas erradas.

Eu tenho quatro dicas para te dar, duas delas são “teóricas” e as outras duas são práticas, todas essas são para quem tá começando a querer escrever, ou criar a prática. Coloquei “teóricas” entre aspas, porque elas se referem mais a uma forma de enxergar o hábito da escrita do que uma ação em si.

Dicas teóricas:

Evite a otimização precoce e foque em escrever;
Tenha dois momentos diferentes: um para escrever e outro para editar;

Dicas práticas:

Anote o objetivo do texto antes de começar a escrever o conteúdo;
Depois do objetivo, escreva um esboço em tópicos;

Essas frases resumem bem cada dica, mas vamos passar por cada uma com mais carinho.

Evite a otimização precoce e foque em escrever

Se o seu objetivo é escrever, esse não é o momento de desenvolver o seu próprio blog, às vezes você quer usar o blog como um momento de estudo para aprender como usar um gerador de páginas estáticas novo, ou aquele framework que tá dando o que falar, e eu entendo essa vontade, de verdade, mas se você quer escrever, talvez usar o blog como espaço de aprendizado de uma nova tecnologia não seja uma boa ideia.

Nós, pessoas que desenvolvem, temos o péssimo hábito de querer implementar tudo do nosso jeito, de implementar uma versão melhor, mais completa, mais cheia de fru-fru, e esquecemos de focar no importante: a entrega de valor. Isso vale tanto, para código quanto para escrita de texto e, no caso do conteúdo, a entrega de valor é exatamente essa, o conteúdo.

Por exemplo, eu tenho usado muito o Notion para escrever rascunhos e outros projetos. Já vi outras pessoas também querem usar essa mesma ferramenta por que ela tem uma feature chamada Databases, que permite criar conteúdo de forma interconectada, mas será que você precisa mesmo usar databases agora? Talvez não, principalmente se você quer escrever.

Você pode retrucar falando: “Eu quero usar databases já para evitar retrabalho no futuro”. E aí eu te falo mais: Se você estivesse escrevendo código, que um dia, talvez, precise usar uma base de dados, você iria pensar em escrever a integração com base de dados agora? Gosto de acreditar que não. No máximo você estruturaria seu código para facilitar a refatoração no futuro, não é mesmo? Então, aplique o mesmo pensamento à sua escrita, facilite o seu lado até onde der, mas não se prenda ao que você vai precisar no futuro.

Se prender ao futuro te impede de focar no mais importante de entregar agora: criar a prática de escrever. Você pode escrever até no bloco de notas se você quiser, o importante é focar naquilo que você precisa de verdade.

Escreva em um momento e edite em outro

Para estarmos na mesma página, acho importante definir o que eu encaro como edição. Para mim, editar é ato de remover coisas desnecessárias, ajustar parágrafos e frases para que façam mais sentido e corrigir erros de digitação. Todas as atividades que envolvem melhorar o que já foi escrito. Isso só é possível depois que você tem algo na página.

Eu conheço pessoas que conseguem escrever e já irem editando o texto ao mesmo tempo. Isso não funciona para mim, eu preciso ter dois momentos separados, um para cada parte. Eu gosto de dizer que primeiro eu derrubo tudo que tô pensando na página e depois eu faço isso ficar bonito.

Todas as vezes que eu fiz os dois ao mesmo tempo, eu acabei desistindo de publicar o conteúdo ou até mesmo de terminar o artigo. Além disso, editar em um momento e escrever em outro, me ajuda a melhorar bastante os meus textos e terminar um texto num espaço mais curto de tempo.

Além de reduzir o tempo de criação de um artigo, fazer as coisas separadamente me ajuda também a chegar ao objetivo de todo conteúdo que eu faço: publicá-los para que eles possam ajudar alguém. Afinal, o texto existir apenas no meu computador não serve para nada além de ocupar espaço.

Já que estamos falando de edição, se você chegar na minha casa e eu estiver editando um texto, você vai me encontrar lendo ele em voz alta. Ler em voz alta me força a ler o conteúdo devagar, encontrar falhas nas explicações que pareciam claras no momento da escrita se torna mais fácil, assim como encontrar erros de digitação. Leia os seus textos em voz alta antes de publicá-los, confie em mim.

Comece pelo objetivo e retorne a ele sempre que preciso

Às vezes, eu tenho um problema de foco: de tempos em tempos me ataca uma vontade de querer abordar mais de uma coisa no mesmo texto. Para vencer esse problema de foco eu sempre começo anotando a introdução do texto no formato de um objetivo a ser alcançado:

Aprenda X conceito;
Veja como implementar Y;
Descubra como fazer Z.

Obviamente embalado com mais algumas palavras de contextualização e num formato de call-to-action para atrair a atenção de quem lê. O objetivo serve, ao meu ver, principalmente para duas coisas:

Do lado de quem lê: despertar interesse e dar clareza sobre o que vai ser abordado ou o problema a ser resolvido;
Do lado de quem escreve: guiar a sua escrita e te manter na linha evitando desfocar daquilo que você se propôs a resolver no texto.

Por isso, anotar o objetivo primeiro é de grande valia. Após terminar a escrita do rascunho, o primeiro check que eu faço é conferir se eu resolvi aquilo que eu propus no início do texto. Caso a resposta seja não, ou eu ajusto o texto para atingir o objetivo ou eu guardo a ideia inicial para um novo blog post e reescrevo a introdução para combinar com aquilo que eu realmente entreguei.

Uma revelação que me ocorreu também nesse processo é que os meus melhores artigos tem como objetivo uma pergunta muito clara a ser respondida. É uma verdade que, se você não puder pagar ferramentas ou fazer pesquisas para otimizar o seu texto, a melhor otimização que você pode fazer é responder apenas uma pergunta por artigo. Ao fazer isso, tanto quem lê quanto o Google, vão entender o que aquele artigo propõe.

Escreva um esboço em tópicos

Depois de escrever o foco do artigo, eu sempre tento organizar as minhas ideias, então eu anoto o que preciso escrever sem falta no formato de tópicos. Digamos que esses tópicos são a receita mínima, mas sem detalhes, que garante que eu respondi a pergunta inicial.

Geralmente, esses tópicos definem as seções do texto e muitas vezes eles viram os títulos e subtítulos de determinadas seções. Por exemplo, eu estou trabalhando em um material que fala sobre o uso de um CDN no GitFichas.

Eu escrevi os tópicos no formato das perguntas que eu faria para entender a justificativa de usar uma nova ferramenta num projeto. Comecei com o motivo de usar um CDN, passando pelo o que é e a sua relação com a velocidade de carregamento de uma página. Em seguida, eu pensei em falar sobre qual serviço eu escolhi como CDN. Depois conto como eu subi e organizei as imagens no CDN e finalizei com a parte de atualização de posts para usar as imagens de lá.

Se esse blog post do CDN fosse em um formato de tutorial (que ele não é hoje) ele provavelmente ainda teria uma seção de fechamento para rever os conceitos aprendidos ou para ressaltar pontos principais.

Escrever esses tópicos me ajuda a definir a estrutura inicial do texto e também a quebrar a tarefa que é escrever um artigo. Ao invés de pensar em escrever um artigo por completo, eu pode começo com apenas uma seção, posso fazer uma pausa, ir para outra e assim sucessivamente.

Depois de escrever os tópicos das seções mais importantes, eu listo também em formato de tópicos, os assuntos que vou abordar em cada seção. Pensar em tópicos antes de escrever o texto por completo pode ajudar também a encontrar falhas de estruturação e facilitar a adaptação antes de ter retrabalho para reescrever seções por completo, assim eu facilito a minha vida caso precise fazer alguma alteração maior logo de cara.

Conclusão

É importante lembrar que esse é o meu processo e ele funciona muito bem para mim embora tenha levado uns três anos pra eu ficar realmente feliz com ele.

Eu estou te contando que isso demorou uns três anos, não para te desestimular, mas para te garantir que, se encontrar esse método estiver demorando para você, tudo bem.

O mais importante é você encontrar o que funciona para você, o seu processo, no seu ritmo.

Recapitulando

Pra finalizar, eu aposto que você quer um resumo de tudo que você acabou de ler, não é mesmo? Aqui estão os pontos principais:

Evite a otimização precoce e foque em escrever;
Tenha dois momentos diferentes: um para escrever e outro para editar;
Anote o objetivo do texto antes de começar a escrever o conteúdo;
Escreva um esboço em tópicos.

Para finalizar, tente colocar em prática, pelo menos, uma das coisas que você aprendeu com esse texto o quanto antes, enquanto a memória está recente, assim a probabilidade de você fixar esse novo jeito de pensar é maior.

My content creation process

Sat, 12 Feb 2022 11:00:00 +0000

I’ve been blogging for a few years, and since creating content has become my bread and butter, I’ve been thinking a lot about writing methods.

Just like programming well, writing well takes practice and dedication. After some time writing, you have a system, a collection of steps that you always follow, and then you start thinking about how to optimize your work to get better results and faster high-level deliveries.

This text is a reflection I’m doing about my own “writing method”, which is worth noting is the same method I use for any content I produce such as talks, videos, and podcasts. Besides, I want to show you in a practical way how you can start writing.

Where I started

Well, if you follow me you may know that I was not the best language and writing student in school and I never wanted to be a writer, but the world turns and here we are. Writing became a habit, later it became something I liked to do. Today, I can say that I love writing.

For me, writing is how I organize my ideas, how I understand the world and the concepts I study, and how I get information into my head. It’s such a fundamental part of my day-to-day asynchronous communication that if you take the writing away from me, I’ll probably be lost.

My first blog was a website that I used as a notepad, I basically chose a theme and deployed it. It was more for me than for anyone else, and above all, its goal was not to be a blog. It was a website where I posted notes and learnings.

I believe that not having content as the focus of my first website took off all the pressure that comes with “what if people don’t read what I write?” or “what if people judge me?” or even “what if I make mistakes?”, which gave me time and a safe place to practice writing itself.

As the writing process was relatively costly, since I had to recreate the markdowns that generated the posts manually, and with the initial boom of Medium, I spent some time writing there, especially because it was easy to write anywhere.

After a while Medium started charging per reading and blocking people with a paywall. It was then that I decided to leave the platform and go back to keeping the content in a free place where people could access it without paying.

After more than a year of writing on this site, I decided to turn it into a “content-first” blog. A real blog where the focus was on content and that was better for people to find what they were looking for. The first thing I did was change the theme and also started using cards to emphasize the content.

Practice leads to perfection

As I said before, writing is like programming, you need to practice daily, study, read other people’s materials to see how they frame their subjects, review what you’ve done, and release it to the world. But if you’re just starting out this can seem daunting and I often see people focusing on the wrong things.

I have four tips to give you, two of them are “theoretical” and the other two are practical, all of these are for those who are starting to grow that writing needs, or that want to practice. I say “theoretical” - in quotation marks - because they refer more to a way of looking at the habit of writing than the habit itself.

Theoretical tips:

Avoid early optimization and focus on writing;
Have two different moments: one for writing and another one for editing;

Practical tips:

Write down the purpose of the text before starting to write the content;
After writing the purpose, write a bulleted outline;

These statements sum up each tip well, but let’s go through each one more carefully.

Avoid early optimization and focus on writing

If your goal is writing, this is not the time to develop your own blog. Sometimes you want to use the blog as a study moment to learn how to use a new static page generator, or that framework that sets tongues wagging, and I understand that desire, really, but if you want to write, maybe using the blog as a space for learning a new technology is not a good idea.

We, people who develop, have a bad habit of wanting to implement everything our way, of implementing a better, more complete, full-of-features version of something, and we forget to focus on what’s important: delivering value. This goes for both code and writing and, in the case of content, the delivery of value is exactly that, the content.

For example, I’ve been using Notion a lot for writing drafts and keeping track of other projects. I’ve seen other people also want to use this same tool because it has a feature called Databases, which allows you to create content in an interconnected way, but do you really need to use databases now? Maybe not, especially if you want to write.

You can argue by saying: “I want to use databases now to avoid rework in the future”. And then I’ll tell you more: If you were writing code, which one day, maybe, you need to use a database, would you think about writing the integration with a database now? I like to believe you wouldn’t. At most you would structure your code to make refactoring easier in the future, wouldn’t you? So, apply the same thinking to your writing, make it easier on yourself as much as you can, but don’t get caught up on what you might need in the future.

Holding on to the future prevents you from focusing on the most important thing to deliver now: creating the practice of writing. You can even write on a notepad if you want, the important thing is to focus on what you really need.

Write in a moment, and edit in another

To be on the same page, I think it’s important to define what I see as editing. For me, editing is the act of removing unnecessary things, adjusting paragraphs and sentences to make more sense, and correcting typos. All activities that involve improving what has already been written. This is only possible after you have something on the page.

I know people who can write and edit text at the same time. This doesn’t work for me, I need to have two separate moments, one for each part. I like to say that first I drop everything I’m thinking about on the page and then I make it look nice.

Every time I did both things at the same time, I ended up giving up on publishing the content or even finishing the article. Besides, editing at one time and writing at another helps me to improve my content a lot and finish a piece in a shorter time span.

In addition to reducing the time to create an article, doing things separately also helps me reach the goal of all the content I make: publishing them so they can help someone else. After all, the content existing only on my computer serves no purpose other than taking up space.

Since we’re on the subject of editing, if you come to my house and I’m editing a text, you’ll find me reading it out loud. Reading out loud forces me to read content slowly, so finding flaws in explanations that seemed clear at the time of writing becomes easier, as does finding typos. Read your texts aloud before publishing them, trust me.

Start with the purpose and return to it whenever needed

Sometimes I have a problem with focusing: from time to time I feel like I want to cover more than one thing in the same piece of content. To overcome this focus problem I always start by writing down the text intro in the format of a goal to be achieved:

Learn concept X;
See how to implement Y;
Find out how to do Z.

Obviously, that comes wrapped with a few more words of context and in a call-to-action format to grab the reader’s attention. The goal serves, in my view, mainly for two purposes:

On the side of the reader: spark interest and provide clarity about what will be addressed or the problem to be solved;
On the side of the writer: guide your writing and keep you in line, avoiding blurring the lines of the problem you set out to solve in the text.

Therefore, writing down the goal first is of great value. After finishing writing the draft, the first thing I do is check if I solved what I proposed at the beginning of the content. If the answer is no, either I adjust the content to achieve the goal or save the initial idea for a new blog post and rewrite the intro to match what I actually delivered.

A revelation that also occurred to me in this process is that my best articles aim at a very clear question to be answered. It’s true that if you can’t afford tools or research to optimize your text, the best optimization you can do is answer just one question per article. By doing this, both readers and Google will understand what that article proposes.

Write an outline in topics

After writing the main point of the article, I always try to organize my ideas, so I write down what I need to c without fail in topics. Let’s say these topics are the minimal recipe, but with no details, which ensures I’ve answered the initial question.

These topics usually define the sections of the text and they often become the headings and subheadings of certain sections. For example, I’m working on a material that talks about using a CDN in GitFichas.

I wrote the topics in the format of the questions I would ask to understand the reason for using a new tool in a project. I started with the reason for using a CDN, going through what it is and its relationship to the speed of a page load. Next, I thought I’d talk about which service I chose as a CDN. Then I’d tell you how I uploaded and organized the images on the CDN and finished with the update of the posts section to use the images from the CDN.

If this CDN blog post were in a tutorial format (which it is not today) it would likely still have a closing section to review concepts learned or to highlight key points.

Writing these topics helps me to define the initial structure of the text and also to break down the task of writing an article. Rather than thinking about writing an entire article, I might start with just one section, pause, move on to another, and so on.

After writing the topics of the most important sections, I also list in bullet points format the topics I will cover in each section. Thinking about topics before writing the entire text can also help to find structure flaws and facilitate adaptation before having to completely rewrite sections, so I make my life easier in case I need to make any major changes right away.

Conclusion

It’s important to remember that this is my process and it works really well for me although it took me about three years to get really happy with it.

I’m telling you that it took about three years, not to put you off, but to reassure you that if finding your method is taking a while, that’s okay.

The most important thing is that you find what works for you, your process, at your own pace.

Recap

Finally, I bet you want a summary of everything you just read, right? Here are the main points:

Avoid early optimization and focus on writing;
Have two different moments: one for writing and another for editing;
Write down the purpose of the text before starting to write the content;
Write an outline.

Finally, try to put into practice at least one of the things you learned from this text as soon as possible, while your memory is fresh, chances are that will incorporate this new way of thinking faster if you do so.

Entenda a diferença entre git stash pop e git stash apply

Sun, 06 Feb 2022 11:00:00 +0000

Você pode saber criar seus stashes, listar eles e tudo mais, mas na hora de voltar a usar o trabalho salvo em um stash sempre rola aquela dúvida: “apply ou pop? Eis a questão”. E essa dúvida é muito normal já que ambos tem um funcionamento parecido, ambos aplicam as mudanças guardadas em um stash.

Nessa colinha você vai ver quando usar um e quando usar o outro. 😉

O git stash apply

O apply aplica as mudanças de um stash no seu diretório de trabalho e mantém a entrada na lista de stashes. Por exemplo, considere que você tem a seguinte pilha de stashes:

E você quer aplicar as mudanças do primeiro stash o stash@{0}. Para isso, rode o comando:

git stash apply

O resultado esperado é encontrar as mudanças guardadas naquele stash no seu branch local:

E também encontrar aquelas mudanças ao listar os stashes:

imagem mostrando a lista de stashes como resultado do comando git stash list com dois stashes na lista

Note que o apply assim como o drop e o pop sem passar um índice irá usar a stash mais recente da pilha.

O git stash pop

O pop por sua vez, vai aplicar as mudanças de um stash à sua área de trabalho e remover aquele stash da pilha em seguida. O pop nada mais é do que um atalho para git stash apply seguido de git stash drop.

Por exemplo, levando em consideração a mesma lista de stashes anterior, e um ambiente de trabalho sem mudanças, você quer tirar da lista e aplicar as mudanças do primeiro stash o stash@{0}. Então você roda o comando:

git stash pop

O resultado esperado é encontrar as mudanças guardadas naquele stash no seu branch local, assim como no apply:

E, diferentemente do apply, ele já mostra que o stash correspondente foi removido da lista na mensagem de resultado. Se você rodar o git stash list não vai encontrar mais aquele stash na lista:

Quando usar apply e quando usar pop

Digamos que você queira reaproveitar as mudanças que você fez em outro lugar também, ou não tem certeza se você quer usar elas agora, então você pode usar a apply e caso não queira continuar com elas, usar o git reset HEAD para descartá-las, assim mantendo as mudanças armazenadas num stash para mais tarde.

Caso você tenha certeza que quer aplicar as mudanças use pop, assim além de aplicar as mudanças você mantém a lista de stash limpinha. Via de regra, eu prefiro sempre usar o pop e refazer o stash caso eu precise guardar as mudanças para mais tarde.

O importante é que agora você entende a diferença entre um e outro e não precisa mais ter medo do git stash.

GitFichas

Learn why the command git stash drop is useful

Sat, 05 Feb 2022 13:25:00 +0000

Need to clear the stash list and don’t know how? Don’t worry, in this pro tip you will learn how to “throw away” stashes that you no longer need using the command git stash drop. 😉

The usual git stash workflow

Usually, you probably use git stash to store changes that are temporary and not yet ready for a commit. This often happens when you need to interrupt work to fix a bug or something similar on another branch. So your workflow should look like this:

# work work work
git stash
# switch branches and do other deliveries
# go back to the initial branch
git stash pop

So far so good, but what happens when you store changes for another reason, like cleaning up the work environment? Eventually you’ll want to get rid of these changes to keep your work environment clean, right? This is where git stash drop comes in.

Discarding a stash

Old stashes can be a source of a lot of headache, yes conflicts, I’m talking about you, so it’s important to keep your stash list up to date. Suppose you currently have the following stash list:

You want to get rid of stash number 0 which contains the creation of arquivo-2.txt. To do this, run the following command:

git stash drop stash@{0}

You should see a message informing the stash has been removed:

Then you can double check the stash listing:

It’s worth mentioning that just like git stash pop, if you don’t pass the stash name to the command git stash drop, it will remove the most recent stash from the stack.

GitFichas | GitStudyCards

Hope these commands help you to remove stashes when needed.

Aprenda para que serve o comando git stash drop

Sat, 05 Feb 2022 13:25:00 +0000

Tá precisando limpar a lista de stashes e não sabe como? Não se preocupe, nessa colinha você vai aprender a “jogar fora” stashes que não precisa mais usando o comando git stash drop. 😉

O fluxo comum de uso do git stash

Comumente você provavelmente usa o git stash para armazenar mudanças temporárias e que ainda não estão prontas para um commit. Muitas vezes isso acontece quando você precisa interromper o trabalho para corrigir um bug ou algo similar em outra branch. Então o seu fluxo de trabalho deve ser algo semelhante a esse:

# trabalha trabalha trabalha
git stash
# muda de branch e faz outras entregas
# volta pro branch inicial
git stash pop

E até aí tudo bem, mas o que acontece quando você armazena mudanças por outro motivo, por exemplo, limpar o ambiente de trabalho? Eventualmente você vai querer se livrar dessas mudanças para manter a casa limpa não é mesmo? É nessa hora que entra o git stash drop.

Jogando fora um stash

Stashes antigos podem ser fonte de muita dor de cabeça, sim conflitos, eu estou falando de vocês, então é importante manter a lista de stashes sempre em dia. Suponha que atualmente você tem a lista a seguir de stashes:

Você quer se livrar do stash de número 0 que contém a criação do arquivo-2.txt. Para isso rode o comando a seguir:

git stash drop stash@{0}

Você deverá ver uma mensagem informando que o stash foi removido:

Em seguida, você pode conferir novamente a listagem de stashes:

Vale salientar que assim como o git stash pop, se você não passar o nome do stash para o comando git stash drop ele vai remover o stash mais recente da pilha.

GitFichas

Espero que esses comandos te ajudem a remover stashes quando necessário.

Using git stash: pop, apply, and drop

Sun, 23 Jan 2022 13:25:00 +0000

Switching branches during the middle of work is something that happens quite often, for example, when ”hotfixing” a bug in another branch while you’re implementing a task.

There are a few ways of stopping work, including making commits. My favorite way of doing that is using git stash and git stash pop. People often mix up how these work, along with the related git stash apply and git stash drop, so let’s sort all of them out. 😉

What is a stash

Stash can be seen as a bundle of the current, not-yet-committed changes that are saved locally on your computer in a stack. Each change bundle is called a stash.

When a stash is created, your directory reverts to a clean state, that is, with no changes to the files that are tracked by Git. This also means that new files, which have not yet been added in a commit, are not stashed.

Each stash receives a “name”, an index, in the format of stash@{<n>}, where "n" refers to a number corresponding to the stash position in the stash stack. This number always changes if more stashes are added to the stack, so the most recent stash is always stash@{0}.

Stacks are a common concept in programming, and this is important to understand the stash behavior, because, without indicating the stash index, the commands will follow the LIFO order (“last in, first out”), where the last stash, that is, the most recent stash to be added to the stack is removed first.

Saving a work in progress with a stash

So let’s say you are working on the branch tarefa that corresponds to the implementation of some feature, but now you need to go back to the main branch and solve a very important problem. To make it easier, we will not focus on problem solving. This is the current state of your work:

Now you need to save the work you’ve already done before going back to the branch main. To do so, use the following command:

git stash

This command is a shortcut to the full command, git stash push. Now that the stash is done, you will see an output similar to the following:

You can also see the stash you just made using the command git stash list to see the list of existing stashes:

Note in the image above that the stash listing always displays the stash index and a message. Now that your work is saved, you can seamlessly switch branches and resolve whatever you need to. It’s worth pointing out that stashes are not tied to a branch, so you will still be able to see your stash in the list even after switching branches.

Getting back to work with a pop

After you finish adjustments on the branch main, you can finally get back to working on that feature on branch tarefa. To “unstash” the stack and apply the changes you saved, use the following command:

git stash pop

pop will remove the most recent stash from the stack and apply the changes it contains, and you should see an output that looks like this:

Now you have everything you need to continue your work.

Keeping the stash with apply

What if you want your changes back but you would like to keep the stash around, maybe to apply it on more than one branch? That is what git stash apply is for. It works just like pop, except it does not remove the stash from the stack:

git stash apply

The short version: pop applies the stash and removes it, apply applies it and keeps it. Reach for apply when you are not sure you are done with those changes yet.

Cleaning up with drop

Since apply leaves the stash on the stack, at some point you will want to clear it out. Use git stash drop to remove the most recent stash without applying it:

git stash drop

You can also drop a specific stash by passing its index, for example git stash drop stash@{2} to remove the one at index two. And if you want to wipe every stash at once, git stash clear does that.

How to add a new file to a stash

As I said before, new files don’t get stashed. This happens because they don’t have previous tracking. For example, let’s say that while working on the branch tarefa, in addition to modifying the file arquivo-tarefa.txt, you’ve also created the file arquivo-2.txt, leaving you with the following result in your working directory:

If you try to stash these changes, you’ll see that the new file is still there, alive and kicking:

And then you might be wondering, since the stash command doesn’t take new files into account, how do we get around this behavior? And the good news is that there is a trick to adding new files to a stash: you need to add them to staging!

Then add the new file with git add and you’ll have something like this:

And if you run git stash again you will see that now your stash also saves the new file and as a result you have your working directory clean:

And since you know how to stash it and remove it from the list with git stash pop, you will see that the new file also comes back from the stash on staging:

And now you already know how to use git stash. 🎉

If a stash ever seems to vanish, or you lose work to a reset or rebase, the git reflog can help you recover it.

GitFichas | GitStudyCards

Hope these commands help you to stop the work you’ve done and get back to working on the changes.

Usando git stash: pop, apply e drop

Sun, 23 Jan 2022 13:25:00 +0000

Mudar de branches durante o meio de trabalho é algo que acontece com certa frequência, por exemplo, para resolver um bug fazendo um “hotfix” em um outro branch enquanto você está desenvolvendo uma tarefa.

Existem algumas formas de interromper o trabalho, incluindo fazer commits. A minha forma favorita é usando os comandos git stash e git stash pop. Muitas pessoas confundem o funcionamento desses dois comandos, assim como os relacionados git stash apply e git stash drop, então vamos esclarecer todos eles. 😉

O que é o stash

Stash pode ser visto com um empacotamento das mudanças atuais, que ainda não foram feitas o commit, que fica salvo localmente no seu computador numa pilha. Cada pacote de mudanças é chamado de stash.

Quando um stash é criado, o seu diretório volta a um estado limpo, ou seja, sem mudanças nos arquivos que são acompanhados pelo Git. Isso também quer dizer que arquivos novos, que ainda não foram adicionados em um commit, não são adicionados em stash.

Cada stash recebe um “nome”, um índice, no formato stash@{<n>}, onde "n" se refere a um número correspondente a localização do stash na pilha de stashes. Esse número sempre se altera se mais stashes forem adicionados a pilha, o stash mais recente sempre é o stash@{0}.

Pilhas, são um conceito comum em programação, e isso é importante para entender o comportamento do stash, pois, sem indicar o índice do stash, os comandos vão seguir a ordem LIFO (“last in, first out”), onde o último stash, ou seja, o stash mais recente, a ser adicionado na pilha é removido primeiro.

Guardando trabalho em progresso com stash

Então vamos dizer que você está trabalhando no branch tarefa que corresponde a implementação de uma feature qualquer, mas agora você precisa voltar para o branch main e resolver um problema muito importante, por questões de simplicidade não vamos focar na resolução de problemas. Esse é o estado corrente do seu trabalho:

Agora você precisa salvar o trabalho que você já fez antes de retornar ao branch main. Para isso use o comando a seguir:

git stash

Esse comando é um atalho para o comando completo, o git stash push. Agora que o stash foi feito, você vai ver um resultado semelhante ao seguinte:

Você também pode ver o stash que acabou de fazer usando o comando git stash list para ver a lista de stashes existentes:

Note na imagem acima que a listagem de stashes sempre apresenta o índice do stash e uma mensagem. Agora que o trabalho está salvo, você pode trocar de branch tranquilamente e resolver o que precisar. Vale salientar que stashes não são amarrados a um branch, então você ainda vai poder ver o seu stash na lista mesmo depois de trocar de branches.

Voltando a trabalhar com o pop

Depois de terminar os ajustes no branch main, você finalmente pode voltar a trabalhar naquela feature do branch tarefa. Para tirar o stash da pilha e aplicar as mudanças que você guardou, use o comando a seguir:

git stash pop

O pop vai remover o stash mais recente da pilha e aplicar as mudanças que ele contém, e você deve ver um resultado parecido com isso:

Agora você tem tudo que precisa pra continuar seu trabalho.

Mantendo o stash com apply

E se você quiser suas mudanças de volta, mas prefere manter o stash por aí, talvez para aplicar em mais de um branch? É para isso que serve o git stash apply. Ele funciona como o pop, só que não remove o stash da pilha:

git stash apply

Na versão curta: pop aplica o stash e remove ele, apply aplica e mantém. Use o apply quando você ainda não tem certeza de que terminou com aquelas mudanças.

Limpando com drop

Como o apply deixa o stash na pilha, em algum momento você vai querer limpar isso. Use git stash drop para remover o stash mais recente sem aplicá-lo:

git stash drop

Você também pode remover um stash específico passando o índice dele, por exemplo git stash drop stash@{2} para remover o que está no índice dois. E se quiser apagar todos os stashes de uma vez, git stash clear faz isso.

Como adicionar um arquivo novo à um stash

Como falei anteriormente, arquivos novos não entram num stash, isso acontece por que eles não possuem rastreamento anterior. Por exemplo, digamos que enquanto estivesse trabalhando no branch tarefa, você, além de modificar o arquivo arquivo-tarefa.txt, você tenha criado o arquivo arquivo-2.txt, de deixando com o resultado a seguir no seu diretório de trabalho:

Se você tentar fazer o stash dessas alterações, vai ver que o arquivo novo continua lá firme e forte:

E aí você deve estar se perguntando, já que o stash não leva em consideração arquivos novos, como a gente burla esse comportamento? E a boa notícia é que existe um truque para adicionar arquivos novos à um stash: você precisa adicionar eles em staging!

Então adicione o arquivo novo com git add e você terá uma situação assim:

E se você fizer novamente o git stash verá que agora seu stash guarda também o arquivo novo e como resultado você tem o seu diretório de trabalho limpo:

E já que você sabe aplicar um stash e remover ele da lista com o git stash pop, você vai ver que o arquivo novo também volta do stash em staging:

E agora você já sabe usar git stash. 🎉

Se um stash parecer ter sumido, ou você perder trabalho por causa de um reset ou rebase, o git reflog pode te ajudar a recuperar.

GitFichas

Espero que esses comandos te ajudem a interromper o trabalho feito e voltar a trabalhar nas mudanças.

Tips to improve your LinkedIn profile

Tue, 18 Jan 2022 23:00:00 +0000

You might be thinking about switching jobs and you may be wondering “How do I improve my profile on the networks most used by recruiters?” and you may already havheard things like “keep your resume up to date” and “create a portfolio” specially in tech.

I can give you more advice on how to improve your profile if I know better who you are and what you do, but with the tips below, you can do a few improvements by yourself, even if we don’t know each other, so here we go.

Let the world see your face

Let’s start with the photo. Not long ago, people used to put photos in CVs to help the person hiring to know who the person on the page was. I won’t go into the merits of this practice, but for LinkedIn, if you don’t have a photo, chances are two things will happen:

people won’t accept your connection request;
people recruiting let your profile pass along.

So, take the opportunity to put a nice picture of yourself on your profile. Some tips for choosing the photo:

Choose an updated photo. After two+ years of the pandemic, there are many people who have changed their appearance, let their hair or beard grow so provide a brand new photo, there’s nothing better than doing an interview and putting a face to the name of the person you will see on the video call;
Choose a photo that has only you in it, it’s fine if you crop part of a photo, but a photo of just you is ideal;
Leave the profile picture available for people to see even without a LinkedIn connection, there’s no point in posting a beautiful picture and not letting the network see it, right?;
When taking the picture, remember to have your face facing the camera, that picture showing only your profile or covering part of your face is fine for other networks but defeats the purpose, okay? The idea is to make it easier for people to recognize you.

Found a good photo? Let’s work on your professional background. 😉

Write an “about me” text

People like to hire other people they understand. The more clarity you can convey with your resume the better, no one will know your skills as well as you do and it’s up to you to talk about them. I know, this is hard for a lot of people, even I have a hard time doing this sometimes so practice it. Practice makes perfect.

You can start practicing talking about your past experiences by writing the “about me” field. Write about what motivates you and/or about the things you’ve done. It doesn’t have to be a long text, but following the school’s writing tips is a good thing: your text, even if it’s short, needs a beginning, a middle and an end.

There are those who say that you shouldn’t talk about what you did at work and that this text should have a more personal tone, in mine I spoke a little about both things because, for me, both go hand in hand. I’ll give you two examples:

My complete “about me” goes both on LinkedIn and on my GitHub page and on my website, you can have a sneak peek here;
In my CV I have a shorter version that I copy below:

I’m a technology enthusiast passionate about learning with more than four years experience in development and public speaking. I co-founded the first Brazilian podcast about data science, Pizza de Dados, to help improve data literacy in Portuguese. Currently, my work consists of assisting developers worldwide learn how they can leverage Auth0 to protect the identities of their users and their products.

The “recipe” I followed was: A little of what motivates me, a little of what I did, a project that I am proud of and maintain today, and finally what I’m currently doing. The most important thing is to have a “this is so you!” text and give the person interviewing a way to break the ice during the interview.

For every job you’ve had, you must have done something, right? So why not share what you’ve done and help the person recruiting understand your skills?

Another thing in favor of describing what you did in each job is that even though positions have similar names across multiples companies, the responsibilities of a said role vary from company to company, so explaining what you did at a previous company is fundamental.

A model I like to follow is:

Talk about your main responsibility or responsibilities if there is more than one;
Speak about results achieved;
And finish with the tools you used.

You already covered the first question recruiters ask: “What did you do in your previous job?” and moved on to a more interesting question: “tell me how you helped achieving those results…”, giving you more time to take advantage in an initial interview. And, most importantly, it will help your profile to appear in the recruiters’ daily searches for candidates.

Then you can ask “Wow, I can’t talk about the results I had due to NDAs, what now?” in this case, you don’t need to put this information in your text, try to write what is possible.

Adapt when necessary

If you have changed areas or positions, this task of describing what you did/do can be a little scary since the biggest concern is always: “my job has nothing to do with what I want to do, help”. At this time you will have to play the game of skills.

In the series “Who is afraid to become a data scientist?” (in Portuguese), Leticia Portella, Gustavo Coelho, and I talked about the main doubts from people wanting to switch careers to data science. We covered the “Am I going to make it?” phase, which is always followed by the “Is it really worth it to start working in a completely new area?”, and ends with “Why would they want to hire me?”

Today, after a few years of writing the posts for the series, I realized that although the focus was data science, the advice there is for everyone. And these advices are valid particularly in what I call the game of skills.

In this case, it is as important to relate what you do today with the skills expected for the future role, as it is to show that even if you still do not perform the future role, you have some of the expected skills. So, in addition to describing what you do, remember to mention that course, that technology that you used and that will be used in future positions.

Review it once, twice, even three times

It might seem silly or even obvious, but proofreading what you write is very important. Spelling, grammar and similar errors will hurt your credibility. You might be someone who doesn’t get carried away by these details, but it could be that the person reading your resume is exactly the type of person who judges based on these mistakes, so it’s better to be safe than sorry.

To avoid this type of problem, write the job description in softwares that make these corrections, for example, Google Docs. Also, and this is a personal tip, read what you’ve written out loud. Seriously out loud. You’ll be amazed at how many possible improvements you’ll get to your text just by reading it out loud. Trust me.

After that, send it to a friend and ask them if they understand what you meant. It might sound like it’s a lot, but I did it, my friends do it, and it works. A second person who doesn’t have the context bias that you have about something you’ve written will be much more effective in identifying if something is missing, that’s why teams that write, for example like the one I work at Auth0, have reviewers.

Have someone to inspire you

Last but not least, look at the resumes of other people who are actively working on their resumes.

Also look at the resumes of people who do what you want to do and how they present the information.

There’s nothing better than having someone to inspire and follow. This will help you shape how you can organize information effectively.

Wrapping up

Updating your resume can be a lot of work, especially if you don’t know what to do, so I hope that with these tips, this task will be easier for you and you will get a great job.

Finally, if you’re still not sure if these things you read here really work, I have a statement from a friend of mine to inspire you to tidy up your LinkedIn:

These LinkedIn tips from Jess are PERFECT <3 She gave me these tips when I was thinking about switching companies and thinking about going through some hiring processes just for practicing. Result: one day after starting to update my LinkedIn profile, I received an invitation to do a job interview. As I wanted to practice, I accepted, I loved the company and I’m there until now <3

Ana Dulce, Python Back-end developer | Tembici

Dicas para melhorar o seu perfil no LinkedIn

Tue, 18 Jan 2022 23:00:00 +0000

Você pode estar pensando em trocar de emprego ou de área e pode estar se perguntando “Como eu melhoro o meu perfil na rede mais utilizada por recrutadores?” e aí você possivelmente já pode ter ouvido coisas como “mantenha o seu currículo atualizado” e “crie um portfólio” principalmente em TI.

Eu consigo dar mais conselhos sobre como melhorar o perfil se souber melhor quem é você e o que você faz, mas as dicas a seguir, você consegue seguir sozinha ou sozinho, mesmo sem que a gente se conheça então vamos lá.

Bota a cara no mundo

Pra começar a foto, na época e nas profissões que precisam de currículos físicos, se coloca uma foto no currículo para ajudar a pessoa contratando a saber quem era a pessoa da folhinha, eu não vou entrar no mérito dessa prática, mas para o LinkedIn, se você não tem uma foto, grandes chances que duas coisas aconteçam:

pessoas não aceitem o seu pedido de conexão;
pessoas recrutando deixem o seu currículo passar.

Então, aproveita pra colocar uma foto bem legal você no seu perfil. Algumas dicas para escolher a foto:

Pegue uma foto atualizada. Depois de dois+ anos de pandemia, tem muita gente que mudou a aparência, deixou o cabelo crescer ou a barba então providencie uma foto novinha, nada melhor do que fazer entrevista e saber qual a pessoa você vai ver na videochamada;
Escolha uma foto que só tenha você nela, tudo bem se você cortar parte de uma foto, mas uma foto só com você é o ideal;
Deixe a foto de perfil disponível para pessoas mesmo sem conexão, não adianta colocar uma foto lindona e não deixar a rede ver né?;
Na hora de tirar a foto lembre de estar com o rosto virado para câmera, nada disso de foto de perfil ou cobrindo parte do rosto tá? A ideia é facilitar que te reconheçam mesmo.

Achou uma foto boa? Bora arrumar o histórico profissional. 😉

Escreva um texto de apresentação

Pessoas gostam de contratar outras pessoas que elas entendem, por isso eu quero dizer que, quanto mais clareza você puder passar com o seu currículo melhor, ninguém vai conhecer tão bem as suas habilidades quanto você e cabe a você falar delas. Eu sei, isso é difícil para muitas pessoas, eu inclusive tenho dificuldade de fazer isso às vezes então pratique, a prática leva a perfeição.

E você pode começar praticando por texto, no campo “sobre” escreva sobre o que te motiva e/ou sobre as coisas que você fez. Não precisa ser um texto longo, mas seguir as dicas de redação da escola é uma boa dica: o seu texto, mesmo que curto, precisa de um começo, um meio e um fim.

Há quem diga que você não deve falar sobre o que você fez no trabalho e que esse texto deve ter um tom mais pessoal, no meu eu falei um pouco das duas coisas até por que, pra mim, ambas andam de mãos dadas. Vou te dar dois exemplos:

O meu “sobre” completo vai tanto no LinkedIn quanto na minha página do GitHub e no meu site, você pode espiar eles aqui;
No meu currículo eu tenho uma versão mais curta que copio abaixo:

Eu sou uma entusiasta da tecnologia apaixonada por aprendizado com mais de quatro anos de experiência em desenvolvimento e falar em público. Eu co-criei o primeiro podcast brasileiro sobre ciência de dados, o Pizza de dados, para ajudar a aumentar a alfabetização em dados em Português. Atualmente, meu trabalho consiste ajudar pessoas desenvolvedoras mundialmente para que elas possam usar Auth0 para proteger as suas aplicações e as identidades de seus usuários.

A receita que eu segui foi: Um pouco do que me motiva, um pouco do que eu fiz, um projeto que me orgulho e mantenho hoje e pra finalizar o que eu faço hoje em dia. O mais importante é deixar o texto com a sua cara e dar a pessoa entrevistando uma forma de quebrar o gelo durante a entrevista.

Conte o que você fez e os resultados

Para cada emprego que você teve, você deve ter feito alguma coisa, certo? Então por que não falar o que você fez e ajudar a pessoa recrutando a entender as suas habilidades?

Outro ponto a favor de descrever o que você faz em cada emprego, é que por mais que cargos tenham nomes parecidos, em empresas diferentes as responsabilidades de um mesmo cargo variam, então explicar o que você fez é fundamental.

Um modelo que eu gosto de seguir é o seguinte:

Fale a sua principal responsabilidade ou responsabilidades se forem mais do que uma;
Conte o resultado disso;
E finalize com as ferramentas que você usou.

Assim, você já cobre a primeira pergunta que as pessoas recrutando fazem: “o que você fazia no seu cargo anterior?” e passa para uma pergunta mais interessante: “me conta como você ajudou a atingir aqueles resultados…”, te dando mais tempo pra aproveitar numa entrevista inicial. E, mais importante, vai ajudar o seu perfil a aparecer nas buscas de pessoas candidatas que são feitas diariamente.

Aí você pode perguntar “Nossa mas eu não posso falar dos resultados que eu tive por sigilo de negócio, e agora?” nesse caso não precisa colocar essa informação no seu texto, tente colocar o que for possível.

Adapte quando necessário

Se você tiver mudando de área ou de cargo, essa tarefa de descrever o que você fez/faz pode ser um pouco assustadora já que a maior preocupação sempre é: “o meu trabalho não tem a ver com o que eu quero fazer, socorro”. Nessa hora você vai ter que jogar o jogo das habilidades.

Na série “Quem tem medo de virar cientista de dados?”, eu, Leticia Portella e Gustavo Coelho, falamos das principais dúvidas sobre pessoas querendo trocar de carreira para a ciência de dados. Cobrimos a fase do “Será que eu vou conseguir?”, que sempre vem seguida da fase do “Vale a pena mesmo começar a trabalhar numa área totalmente nova para mim?”, e que finaliza com “Por que vão querer me contratar?”.

Hoje, depois de alguns anos que escrevemos os textos da série, me dei conta que embora o foco fosse ciência de dados, os conselhos ali servem para todo mundo. E esses conselhos são válidos principalmente no que eu chamo do jogo das habilidades.

Nesse caso, cabe tanto relacionar o que você faz hoje com as habilidades esperadas para o cargo futuro de forma sútil, quanto mostrar que mesmo não desempenhando o cargo futuro você tem parte das habilidades esperadas. Então, além de descrever o que faz, lembre-se de mencionar aquele curso, aquela tecnologia que você usou e que serão usados nos próximos cargos.

Revise uma, duas, ou até mesmo três vezes

Pode parecer bobagem ou até mesmo óbvio, mas revisar o que você escreve é muito importante. Erros de escrita, gramática e similares vão ferir a sua credibilidade. Você pode ser uma pessoa que não se deixa levar por esses detalhes, mas pode ser que a pessoa lendo seja exatamente o tipo de pessoa que julga com base nesses erros, então melhor prevenir do que remediar.

Para evitar esse tipo de problema, escreva a descrição do cargo em programas que façam essas correções como, por exemplo, o Google Docs. Além disso, e isso é uma dica pessoal, leia em voz alta o que você escreveu. Sério em voz alta. Você vai se surpreender com o tanto de possíveis melhorias que você vai conseguir no seu texto só de ler ele em voz alta. Confie em mim.

Depois disso, manda pra um amigo ou amiga e pede pra essa pessoa falar se entende o que você quis dizer. Parece muito, mas eu fiz isso, minhas amigas fazem isso, e funciona. Uma segunda pessoa que não está com o viés de contexto que você tem sobre algo que você escreveu, vai ser muito mais eficaz em identificar se está faltando algo, é por isso que times que escrita, por exemplo como o que eu trabalho na Auth0, tem revisores.

Tenha alguém para se inspirar

Por fim, mas não menos importante, olhe o currículo de outras pessoas que trabalham em seus currículos ativamente.

Olhe também o currículo de pessoas que fazem o que você quer fazer e como elas colocam as informações.

Nada melhor do que ter alguém para se inspirar e seguir. Isso vai te ajudar a moldar como você pode enquadrar as informações de forma efetiva.

Finalizando

Atualizar currículo pode ser trabalhoso principalmente se você não sabe o que fazer, então eu espero que com essas dicas, essa tarefa fique mais fácil para você e você consiga um emprego legal.

Pra finalizar, se você estiver na dúvida se essas coisas que você leu aqui realmente funcionam, eu tenho a declaração de uma amiga minha pra te inspirar a arrumar o seu LinkedIn:

Essas dicas de LinkedIn da Jess são PERFEITAS <3 Ela me deu essas dicas quando tava pensando em trocar de empresa e pensando fazer uns processos seletivos só pra treinar. Resultado: um dia depois de começar a atualizar o LinkedIn, recebi um convite pra fazer um processo seletivo. Como queria treinar, aceitei, amei a empresa e tô lá até agora <3 Ana Dulce, Desenvolvedora Python Back-end | Tembici

Introducing GitFichas!

Sun, 16 Jan 2022 15:44:33 +0000

I started a new project, and I want to tell you all about it! 👀

For some time now I’ve been helping anyone who needs help with Git. From what I’ve seen, most people use git commands on a daily basis without necessarily understanding them…

This is not a problem, especially if you are starting your journey with versioning, however, not understanding the commands can get you into trouble with Git (conflicts, I’m looking at you). And as much as Git helps us in the development process to track changes, conflicts and detached heads are annoying things to solve, especially if you don’t understand what you need to do, right?

In order to improve the lives of those who use Git, I started GitFichas. GitFichas is nothing more than a site that aggregates Git study cards, in its original form, it was intend as a friendly resource in Portuguese, and now it officially has its version in English. Each card is made to be the simplest possible way so anyone can understand each command or concept.

GitFicha number 008 talking about git add -p

The cards are images that explain commands or concepts that I use daily in Git. They even bring little-known or used tips, that when properly applied, they can really come in handy.

Every week a new card is released on Wednesday.

I post the cards on my profile on Twitter and LinkedIn, but you can enjoy and follow GitFichas on Instagram or subscribe to the GitFichas’ channel on Telegram.

And if you want to suggest a command or concept you’d like to see in the form of a card reply to this tweet below, and even though the tweet is in Portuguese is in Portuguese, don’t be shy and say hi. 👇

Perguntando pro meu TCC: Que comando #git você tem dificuldade mesmo rodando ele com frequência?
— Jessica Temporal (@jesstemporal) July 27, 2021

I’m saving the commands and questions that are sent to me in a queue to make new cards as soon as possible. 😉

Undoing the last commit and keeping the changes for a next commit

Sat, 15 Jan 2022 13:25:00 +0000

Undoing and redoing commits is part of everyday life, so it is important to understand the commands that help along the way. Sometimes people call this uncommitting: you want to undo the last commit but keep your changes so you can recommit them somewhere else. In this pro tip I will teach you two things:

Undo the last commit so you can keep the changes on staging;
Reuse the content of the undone commit to make a new commit.

With these two commands in your repertoire of Git commands, you will be way happier. 😉

Creating the scenario

I talked about the command git reset in this other pro tip. In a nutshell, it is a command that allows you to return to a previous state. The most basic use of this command is to use it to undo one or more of the most recent commits. With that, let’s assume you’re in the following situation (interestingly I went through this last Friday):

You committed to the wrong branch;
You haven’t pushed this new commit to the remote yet;
You want to undo this commit and redo it to the correct branch.

As an example, I have here a history of a project in which there are two commits: the initial commit on the main branch (d815be) and the second commit (5e8ae2) adding arquivo-1.txt that should be on another branch, see:

Now it’s time to undo our wrong commit.

Undoing the last commit while keeping the changes (git reset –soft)

Given this scenario, the first step is to use the command git reset. Maybe you don’t know that there is a flag that while undoing a commit with git reset, it allows you to keep the commit changes on staging and the commit message stored in a special variable that I’ll show you in a bit. That flag is --soft.

So we can create our command like this:

git reset HEAD^ --soft

The flag --soft indicates that you want to undo the commit subtly, in other words, keeping the changes. When running this command, you will not get any message, but the changes are on staging, which you can check with the command git status, and the result is as follows:

Now let’s redo the commit in the right place and reuse the message.

If you ever go further than a soft reset, say a git reset --hard, and lose work in the process, do not panic: the git reflog can usually bring it back.

Reusing the commit message

Now that you’ve undone the commit and you have the changes on staging, you can create the new branch and switch to it. I mentioned this previous command in this other pro tip just in case you want to check it out:

git switch -c add-arquivos-novos

With that, the long-awaited moment arrives! You probably already know that to make commits, you need to use the command git commit. As our reset was soft-like, the commit message was stored in the variable ORIG_HEAD, so to reuse it you should use the flag -C followed by the variable, like this:

git commit -C ORIG_HEAD

This flag -C literally means “reuse message”, and this is the result:

Finally, if you want to edit the message, you should use the flag -c in place of the current flag. This will give you the opportunity to adjust the previous message before finishing the commit.

GitFichas | GitStudyCards

Hope these commands help you to reuse the work done.

Desfazendo o último commit e mantendo as alterações para um próximo commit

Sat, 15 Jan 2022 13:25:00 +0000

Desfazer e refazer commits faz parte do dia a dia, então é importante entender os comandos que podem ajudar a gente nesse caminho. Às vezes isso é chamado de “descommitar”: você quer desfazer o último commit mas manter suas alterações para commitar de novo em outro lugar. Nessa colinha eu vou te ensinar a fazer duas coisas:

Desfazer o último commit de forma que você possa manter as alterações em staging;
Reaproveitar o conteúdo do commit desfeito para fazer um novo commit.

Com esses dois comandos no seu repertório de comandos Git você será muito mais feliz. 😉

Criando o cenário

Eu falei sobre o comando git reset nesta outra colinha, em resumo ele é um comando que permite retornar à um estado anterior. O uso mais básico deste comando é usá-lo para desfazer um ou mais commits dos mais recentes. Com isso, vamos supor que você está na seguinte situação (curiosamente eu passei por isso na última sexta):

Você fez um commit no branch incorreto;
Ainda não enviou esse novo commit para o remote;
Você quer desfazer esse commit e refazer-lo no branch correto.

Para exemplificar eu tenho aqui um histórico de um projeto em que temos dois commits: o commit inicial no branch main (d815be) e o segundo commit (5e8ae2) adicionando o arquivo-1.txt que deveria ser em outro branch, veja:

Agora chegou a hora de desfazer o nosso commit incorreto.

Desfazendo o último commit mantendo as alterações (git reset –soft)

Dado esse cenário, o primeiro passo é usar o comando git reset. Talvez você não saiba que existe uma flag que ao desfazer um commit com o git reset permite que você mantenha as alterações do commit em staging e a mensagem de commit guardada numa variável especial que vou te mostrar jájá, essa flag é a --soft.

Então podemos montar o nosso comando assim:

git reset HEAD^ --soft

A flag --soft indica que você quer desfazer o commit de forma mais sutil, ou seja, mantendo as alterações. Ao executar esse comando, você não receberá nenhuma mensagem, mas as alterações estão em staging, o que você pode conferir com o comando git status e o resultado é o seguinte:

Agora vamos refazer o commit no lugar certo e reaproveitar a mensagem.

Se você for além de um reset soft, digamos um git reset --hard, e perder trabalho no processo, não entre em pânico: o git reflog geralmente consegue trazer de volta.

Reaproveitando a mensagem de commit

Agora que você já desfez o commit e tem as alterações em staging, pode criar o novo branch e mudar pra ele, eu falei do comando anterior nesta outra colinha caso você queira conferir:

git switch -c add-arquivos-novos

Com isso, chega o momento tão esperado, provavelmente você já sabe que para fazer commits, precisa usar o comando git commit . Como nosso reset foi do tipo soft a mensagem do commit ficou armazenada na variável ORIG_HEAD, então para reaproveitá-la você deve usar a flag -C seguida da variável, assim:

git commit -C ORIG_HEAD

Essa flag -C quer dizer literalmente “reutilizar mensagem”, e esse é o resultado:

Por fim, se você quiser editar a mensagem, você deve usar a flag -c no lugar da flag atual, isso vai te dar a oportunidade de ajustar a mensagem anterior antes de terminar o commit.

GitFichas

Espero que esses comandos te ajudem a reaproveitar o trabalho feito.

Undoing the last commits using git reset

Fri, 14 Jan 2022 13:00:00 +0000

Since everything we do in git can be done in countless different ways, there are a few ways to get rid of commits. The most common way to undo one or more recent commits is using the command git reset that you’ll see in this pro tip.

What is the HEAD?

HEAD is a pointer that indicates which branch and commit you’re on. It is used frequently, and often without you even knowing it. For example, did you know the HEAD is used to switch branches?

What is git reset?

On the other hand, git reset is a command that restores a previous state of the HEAD. That’s why we use HEAD when undoing commits, to indicate which previous state you want to go back to.

For example, let’s suppose you have a state like the following:

If you want to undo the last commit B, you want to go back to the state of commit A.

Undoing the last commit

To undo the last commit made, you should use the following command:

git reset HEAD~1

Or the following command, which is a shortcut for the command above:

git reset HEAD^

Or even the following shortcut:

git reset HEAD~

These three commands mean:

Go back to the state before the last commit.

Note that when executing these commands, you will not see a message stating that the commit was undone, but if you run the command git status after executing any of these three commands you will see that files added and/or changes made went back to being marked as changes to be committed (added to a commit).

Suppose you have a history like the one in the following image, in which the last commit (48ccb8) adds the file called arquivo-4.txt:

And if you run any of the commands above, followed by a git status, you will see a result like this:

And you can see that arquivo-4.txt has returned to its previous state, which was waiting to be committed. And if you check the history again you will see that the commit 48ccb8 no longer appears.

You can now discard the changes or keep up with them and make a new commit.

Undoing the last three commits

Now that you know how to undo a commit, you can use the first command you’ve just seen and adapt it to undo more commits. To do so, just add the number of commits you want to undo after ~. Let’s take another look at our history, which now contains only four commits (since I already undid one):

Now let’s suppose I want to go back to the state of commit d815be which is the initial commit that added the README.md file. To do so it is necessary to undo three commits, so for that a suitable command is the following:

Agora vamos supor que eu quero voltar ao estado do commit d815be que é o commit inicial que adicionou o arquivo README.md. Para isso é necessário desfazer três commits, então para isso o comando indicado é este:

git reset HEAD~3

After executing this command and running git status once more, we have the three files that were added by the unmade commits:

Note that before running these commands I removed arquivo-4.txt as I won’t need it anymore. And looking into the history again we only see the initial commit:

Before finishing this pro tip I want to leave a recommendation: it is a good practice to avoid undoing commits that you have already pushed to prevent causing detached HEAD problems for other people working with you.

GitFichas ß| GitStudyCards

Below you can find some Git study cards to help you remember these commands and shortcuts:

Hope this pro tip helps you undo commits. 😉

Desfazendo os últimos commits usando git reset

Fri, 14 Jan 2022 13:00:00 +0000

Como tudo que fazemos em git pode ser feito de inúmeras formas diferentes, existem alguns jeitos de se livrar de commits, a forma mais comum de desfazer um ou mais commits recentes é usando o comando git reset que vou te mostrar nessa colinha.

O que é o HEAD?

O HEAD é um ponteiro que indica qual branch e commit você está. Ele é usado com frequência e muitas vezes sem você mesmo saber que ele é acessado para trocar de branches por exemplo.

O que é o git reset?

O git reset por sua vez é um comando que restaura um estado anterior do HEAD, por isso que usamos o HEAD ao desfazer commits, para indicar qual o estado anterior que você quer voltar.

Por exemplo suponha que você tem um estado como o a seguir:

Se você quer desfazer o último commit B você quer voltar ao estado do commit A.

Desfazendo o último commit

Para desfazer o último commit feito você deve usar o comando a seguir:

git reset HEAD~1

Ou o comando a seguir, que é um atalho para o comando acima:

git reset HEAD^

Ou até mesmo o atalho a seguir:

git reset HEAD~

Esses três comandos querem dizer o seguinte:

Volte ao estado anterior ao último commit.

Note que ao executar esses comandos, você não verá mensagem informando que o commit foi desfeito, mas se você rodar o comando git status após fazer algum desses três comandos verá que arquivos adicionados e/ou alterações feitas voltam a serem marcados como alterações a serem commitadas (adicionadas à um commit).

Veja, suponha que você tenha um histórico como o da imagem a seguir, onde o último commit (48ccb8) adiciona o arquivo chamado arquivo-4.txt:

E se você executar algum dos comandos acima seguido de um git status você verá um resultado assim:

E pode ver que o arquivo-4.txt voltou ao seu estado anterior que era esperando ser feito o commit. E se investigar o histórico novamente verá que o commit 48ccb8 não aparece mais.

Agora você pode descartar as alterações ou continuar com elas e fazer um novo commit.

Desfazendo os três últimos commits

Agora que você sabe desfazer um commit, você pode usar o primeiro comando que acabou de ver e adpatá-lo para desfazer mais commits, para isso basta adicionar a quantidade de commits que você quer desfazer depois do ~. Vamos olhar novamente o nosso histórico que agora contém apenas quatro os commits (pois já desfiz um):

git reset HEAD~3

Ao executá-lo e rodar mais uma vez o git status temos os três arquivos que foram adicionados pelos commits desfeitos:

Note que antes de executar esses comandos eu removi o arquivo-4.txt já que não vou precisar mais dele. E investigando novamente o histórico vemos apenas o commit inicial:

Antes de terminar a colinha eu quero deixar uma recomendação: é uma boa prática evitar desfazer commits que você já tenha feito push para evitar de causar problemas de detached HEAD para outras pessoas trabalhando junto com você.

GitFichas

Abaixo você encontra GitFichas pra te ajudar a lembrar desses comandos e atalhos:

Espero que essa colinha te ajude a desfazer commits. 😉

Criando um novo branch e mudando pra ele com apenas um comando

Sat, 01 Jan 2022 14:34:20 +0000

Criar um branch novo no Git é um daqueles comandos do dia a dia que você roda sem pensar, até perceber que está digitando dois comandos quando um bastaria. Toda vez que você cria um branch, também precisa mudar para ele antes de começar a commitar, e existe um atalho que faz as duas coisas de uma vez. Nessa colinha eu vou te mostrar a forma tradicional de criar um branch e depois o meu atalho favorito para criar um e mudar para ele em um único comando.

Formas tradicionais de criar um branch

No Git é possível criar um branch. E mudar para ele usando a sequência de comandos a seguir:

git branch ramo-1
git checkout ramo-1

Como você pode ver na imagem abaixo:

Ou até mesmo a sequência a seguir:

git branch ramo-2
git switch ramo-2

Também visível na imagem abaixo:

Atalhos para criar branches e trocar de branch ao mesmo tempo

Não tem nada errado com essas duas sequências de comandos mostradas anteriormente, mas existem dois atalhos para obter o mesmo resultado usando apenas um comando. O primeiro usando o git checkout seguido da flag -b:

git checkout -b ramo-3

Que você pode ver o resultado semelhante àquele mostrado no primeiro exemplo dessa colinha:

E se você preferir usar o comando git switch temos o seguinte atalho usando a flag -c:

git switch -c ramo-4

Também com resultado semelhante ao que vimos anteriormente:

Recapitulando

Para criar um branch novo e mudar para ele em um comando, você tem duas opções: git checkout -b nome-do-branch ou git switch -c nome-do-branch. Os dois criam o branch e te colocam nele na hora, para você começar a commitar. O caminho mais longo, git branch seguido de git checkout ou git switch, continua funcionando, mas o atalho economiza um passo toda vez.

Se você está organizando o seu fluxo no Git, talvez também goste de saber como atualizar um branch com git rebase e desfazer o último commit e reaproveitar a mensagem.

GitFichas

Abaixo você encontra duas GitFichas pra te ajudar a lembrar desses atalhos:

Agora você sabe dois atalhos para criar um branch e mudar pra ele. Qual desses você vai adotar?

Creating a new branch and switching to it with just one command

Sat, 01 Jan 2022 14:34:20 +0000

Creating a new branch in Git is one of those everyday commands you run without thinking, until you realize you have been typing two commands when one would do. Every time you create a branch you also need to switch to it before you start committing, and there is a shortcut that does both at once. In this pro tip I will show you the traditional way to create a branch, then my favorite shortcut to create one and switch to it in a single command.

Traditional ways to create a branch

In Git, it is possible to create a branch and switch to it using the following command sequence:

git branch branch-1
git checkout branch-1

As you can see in the image below:

Or even with the following sequence:

git branch branch-2
git switch branch-2

Also visible in the image bellow:

Shortcuts to create branches and switch branches at the same time

There’s nothing wrong with these two sequences of commands shown earlier, but there are two shortcuts to get the same result using just one command. The first using git checkout followed by the -b flag:

git checkout -b branch-3

You can see the similar result to the one shown in the first example of this blog post:

And if you prefer using the command git switch we have the following shortcut using the -c flag:

git switch -c branch-4

Also with a similar result to what we saw previously:

Recapping

To create a new branch and switch to it in one command, you have two options: git checkout -b branch-name or git switch -c branch-name. Both create the branch and move you onto it right away, so you can start committing. The longer way, git branch followed by git checkout or git switch, still works, but the shortcut saves you a step every time.

If you are tidying up your Git workflow, you might also like how to update a branch with git rebase and undoing the last commit and reusing the message.

GitFichas

Below you’ll find two GitFichas to help you remember these shortcuts:

Now you know two shortcuts to create a branch and change to it with only one command.

Updating a branch with git rebase

Thu, 30 Dec 2021 14:34:20 +0000

The command git rebase can be used to make various history adjustments, from rewriting the commit tree (and by doing that rewriting the history) to even pushing commits forward as if the branch were created in the future.

In this pro tip I will show you how to use git rebase to update a branch, bringing in the latest commits from main (or master) so your working branch is current.

Creating a example history

Suppose you have a project and you were working on a task on the branch task-2, meanwhile someone else was working on the branch task-1 that was merged into main and thus making the branch main more up-to-date as shown in the drawing below:

Similarly, the history graph should look like the image below:

Knowing that main is more up-to-date than your branch task-2 and following the good practice of always working with the most up-to-date project, you decide it’s time to update your working branch, which has the current history looking like this:

Updating your branch from main with git rebase

There are a few ways to update the current branch, one of them is using git merge and merging the most updated branch, in this case main, into the branch you want to update in this case task-2. The other way is using the rebase that I’m going to show you now.

There are two ways of using rebase to make this update, let’s see the first one which is being on the branch you want to update, so you need to go to the branch to be updated, in this case task-2 and use rebase indicating the branch that is the source of changes:

git checkout task-2
git rebase main

By running these commands you will see in your terminal the message saying that the update was done successfully “Successfully rebased and updated refs/heads/task-2.” as you can see in the following image:

The second way is independent of the current branch, this format is a shortcut for the two previous commands, just use rebase, pass the source branch of the changes followed by the target branch:

git rebase main task-2

This command should also show the same message as the previous image. Regardless of the way you choose to use rebase, your history should look something like the drawing below:

And the history graph should look like this:

Wrapping up

Wrapping up, we have an important thing to point out now that our branch is updated: the rebase will only happen without interruptions, as shown in this pro tip blog post, if there are no conflicts, otherwise the rebase will be suspended and the conflicts must be resolved before continuing.

Now you know how to update a branch using rebase, if you want more details about the command git rebase, I recommend reading its documentation. And if a rebase ever goes sideways and you lose a commit, the git reflog can help you get it back.

Below you can see the git study card that can help you remember the command git rebase to update a branch:

Atualizando um branch com git rebase

Thu, 30 Dec 2021 14:34:20 +0000

O comando git rebase pode ser usado para fazer vários ajustes de histórico, desde reescrever a árvore de commits, reescrevendo assim o histórico, até mesmo empurrar commits para um ponto mais a frente como se o branch fosse criado no futuro.

Nessa colinha vou te mostrar como usar git rebase para atualizar um branch, trazendo os commits mais recentes do main (ou master) para o seu branch de trabalho ficar em dia.

Criando um histórico de exemplo

Suponha que você tem um projeto e estava trabalhando numa tarefa no branch tarefa-2, enquanto isso outra pessoa estava trabalhando no branch tarefa-1 que foi feito o merge para o main e assim tornando o branch main mais atualizado como mostrado no desenho abaixo:

Similarmente, o grafo do histórico deverá se mostrar como a imagem abaixo:

Sabendo que o main está mais atualizado que o seu branch tarefa-2 e seguindo a boa prática de trabalhar sempre com o projeto mais atualizado, você decide que é hora de atualizar o seu branch de trabalho, que tem o histórico corrente assim:

Atualizando seu branch a partir do main com git rebase

Existem algumas formas de atualizar o branch atual, uma delas é usando o git merge e fazendo o merge do branch mais atualizado, nesse caso o main, no branch que você quer atualizar nesse caso o tarefa-2. A outra forma é usando o rebase que vou te mostrar agora.

Tem duas formas de usar o rebase para fazer essa atualização, vamos ver a primeira que é estando no branch que você quer atualizar, então você precisa ir pro branch a ser atualizado, nesse caso o tarefa-2 e usar o rebase indicando o branch de origem das mudanças:

git checkout tarefa-2
git rebase main

Ao executar esses comandos você verá no seu terminal a mensagem avisando que a atualização foi feita com sucesso “Successfully rebased and updated refs/heads/tarefa-2.” (ou “Rebase e atualização das refs/heads/tarefa-2 bem sucedida.” em tradução livre) como você pode ver na imagem a seguir:

A segunda forma é independente do branch corrente, esse formato é um atalho para os dois comandos anteriores, basta usar o rebase, passar o branch de origem das mudanças seguido do branch de destino:

git rebase main tarefa-2

Esse comando também deverá mostrar a mesma mensagem da imagem anterior. Independentemente da forma escolhida para usar o rebase, o seu histórico deverá ser algo semelhante ao desenho abaixo:

E o grafo de histórico deverá se mostrar assim:

Conclusão

Para finalizar temos uma coisa importante de notar agora que nosso branch está atualizado: o rebase só acontecerá sem interrupções, como mostrado nessa colinha, caso não existam conflitos, caso contrário o rebase será suspendido e os conflitos devem ser resolvidos antes de continuar.

Agora você sabe atualizar um branch usando o rebase, caso queira mais detalhes sobre o comando git rebase, recomendo a leitura da documentação do mesmo em português. E se um rebase der errado e você perder um commit, o git reflog pode te ajudar a recuperá-lo.

Abaixo você pode ver uma ficha que pode te ajudar a lembrar do comando git rebase para atualizar um branch:

Fixing the branch source with git rebase

Wed, 29 Dec 2021 14:40:00 +0000

In this pro tip I will show you how to use git rebase to fix the source of a given branch.

Creating a branch from an incorrect branch

Suppose you have two tasks to do in the next few weeks and you want to work on each task in a different branch.

So to work on task #1 you create a branch with that name from main.

Let’s say that during your implementation you got tired of messing with that problem and decided that it would be a good idea to change the context for a bit and start working on task 2.

For that you need to create a new branch also from main, however, without realizing it you ended up creating your branch from branch task-1:

And then, you started working and only realized the mistake later. After you commit to task-2 your history looks something like this:

If you look at your history graph you’ll see that it shows that the most recent commit (1078aa) on the branch task-2 depends on the commit made on the branch task-1 (a7f89a):

So we need to fix this.

Fixing the branch source

With this mistake in hand and since the implementations of each task are independent of each other you want to make this correction.

For this you must use git rebase followed by the flag --onto and the name of the three branches, the full command looks like this:

git rebase --onto main task-1 task-2

The result should look similar to the image below:

Now, having run the above command, your history becomes what it should have been from the beginning:

And if you check the history graph again, you’ll see that we only see the commits from task 2 in the corresponding branch:

Three important things to notice:

First, it is always necessary to give the names of the three branches involved to avoid missing commits;
Second, now branch task-2 has its source in the branch main;
And third, the hash of the commit on the branch task-2 is no longer 1078aa but b25a97 since the commit has changed.

With that now you know how to change or fix the source of a branch, if you want more details about the command git rebase, I recommend reading the command’s documentation.

Below you can see a card that can help you remember the command git rebase --onto:

Corrigindo a origem de um branch com git rebase

Wed, 29 Dec 2021 14:34:20 +0000

Nessa colinha vou te mostrar como usar git rebase pra corrigir a origem de um determinado branch.

Criando uma branch a partir de um branch incorreto

Suponha que você tem duas tarefas para fazer nas próximas semanas e que você quer trabalhar em cada tarefa em uma branch diferente.

Então para trabalhar na tarefa 1 você cria uma branch com esse nome a partir do main.

Digamos, que durante a sua implementação você cansou de mexer com aquele problema e decidiu que seria uma boa ideia mudar um pouco de contexto e iniciar a tarefa 2.

Para isso você precisa criar um novo branch também a partir do main, no entanto, sem se dar conta você acabou criando o seu branch a partir do branch tarefa-1:

E aí, começou a trabalhar e só se deu conta do erro mais tarde. Depois de fazer um commit no tarefa-2 o seu histórico parece algo assim:

Se você analisar o grafo do seu histórico pode ver que ele mostra que o commit mais recente (99247c) no branch tarefa-2 depende do commit feito no branch tarefa-1 (5873c2):

Então precisamos corrigir isso.

Corrigindo a origem do branch

Com esse erro nas mãos e como as implementações de cada tarefa é independente uma da outra você quer fazer essa correção.

Para isso você deve usar o git rebase seguido da flag --onto e o nome dos três branches, o comando por completo fica assim:

git rebase --onto main tarefa-1 tarefa-2

O resultado deverá ser semelhante a imagem abaixo:

Agora, tendo executado o comando acima, o seu histórico passa a ser o que deveria ser desde o princípio:

E se você conferir novamente o grafo do histórico, verá que apenas vemos os commits referentes a tarefa 2 no branch correspondente:

Três coisas são importantes de notar:

Primeiro, que é sempre necessário dar os nomes dos três branches envolvidos para evitar perder commits;
Segundo, que o agora o branch tarefa-2 tem sua origem no branch main;
E terceiro, que o hash do commit no branch tarefa-2 não é mais 99247c e sim 952dc3 já que o commit mudou.

Com isso agora você sabe alterar ou corrigir a origem de um branch, caso queira mais detalhes sobre o comando git rebase, recomendo a leitura da documentação do comando em português.

Abaixo você pode ver uma ficha que pode te ajudar a lembrar do comando git rebase --onto:

Solving conflicts in Git

Fri, 24 Dec 2021 20:55:59 +0000

Resolving conflicts can be an arduous and complicated task when it comes to git projects. In this article you will learn a foolproof step-by-step guide to resolving conflicts.

If you already know what conflicts are and just want to see the list of steps and commands to resolve a conflict, I suggest you skip to the conclusion by clicking here.

What is a conflict in git

When a project has multiple people working at the same time, it’s possible that two people need to make changes to the same piece of a file. When more than one person changes the same piece of a file on different branches, that’s when conflicts appear.

The conflict symbolizes that two or more changes happened to the same chunk of a file and git doesn’t know which of the changes to keep.

How a conflict is formed

In the image below we have a diagram that I have affectionately nicknamed the “conflict anatomy”. It shows the steps until a conflict is formed. It is worth mentioning that usually, during the project development cycle, changes are more significant and sometimes in greater quantity.

0 - In our project we have a README.md that was added by the initial commit in the repository. After creating this file, two changes need to be made to add some more information to the same file and two people will make this change;

1 - Each person then created a branch from main to work on their changes, these new branches were created more or less at the same time, that is, they have the same starting point;

2 - For some time each person works on their branch implementing their change, in this case, each person is adding the line “Person x was here.” in the README.md file where x is the person’s id;

3 - Person 1 makes a pull request and has this pull request approved and also merged into main;

4 - Person 2, on the other hand, makes the pull request to main, but this pull request cannot be merged because it has conflicts.

Creating a conflict on purpose

To demonstrate how this looks, I created a repository with a scenario similar to the one described in the previous section that you can find here. The initial file and the two branches, one for each person, were created from main, see:

Then I made the changes for each person. In the branch person1 I added the description “Person 1 was here!” in the last line of README.md and similarly I did the same process for the branch person2. So I opened both pull requests:

I reviewed and merged the person1’s PR:

And then I went back to person2’s PR and I could see the indication that the pull request contains a conflict, see:

And now with a brand new conflict in our hands, it’s time to resolve it.

Resolving a conflict in Git

Before starting it is important to note that this type of conflict is also possible to resolve through the GitHub interface, but the focus here is on the commands, so let’s go!

The first important thing is to decide on which branch to resolve the conflict, a rule that usually works is to resolve conflicts on the branch that presents the changes, in this case, this branch is person2, with that you must update your local repository, and this particular branch with adjustments from main, for that you can do:

git checkout person2
git pull origin main

This will bring the conflict to your local machine giving you a warning that there are conflicts, that you should resolve the conflict and commit the result:

If you open README.md in a code editor, you will notice that are markers indicated by successive greater than signs (>), less than signs (>) and equal signs (=), here is an example of the conflict shown in Vim:

It is also possible that you use VS Code that shows the conflict in a more friendly way as it visually marks, with different colors, each change of different source and still gives you options on how to resolve the conflict by accepting part of the changes, or both, or none of them:

To understand what each button presented by VS Code means, let’s dissect this representation format. A conflict can be divided into two parts:

Our changes: those on the current branch also called current changes;
Others’ changes: Those we brought to the local machine by doing git pull also called incoming changes.

In this format, each block is delimited by a greater or lesser sign up to the block of repeated equal signs, so for example in this case we have the following blocks.

The one with current changes:

<<<<<<< HEAD
Person 2 was here!
=======

And the one with the incoming changes:

=======
Person 1 was here!
>>>>>>> 3c20251a794ec572e2c3202017d843e2d8769843

Since we want to leave both changes we can just delete the lines with the markers and save the file, if you are using simpler editors. In VS Code we can press “Accept both changes” and continue with the following commands. After accepting all the changes, either manually or using the buttons in VS Code, you should have a file like this:

Remember to save the file. Then go back to the terminal, if you run the command git status you will see that the README.md file shows changes.

Now you can add this staging file with the following command:

git add README.md

And commit the changes in your preferred way. Note that when committing, if you use editors to write the commit message, it is possible that this message comes pre-populated as in the image below:

You can customize the message or leave it as is, and when you’re done committing, push those changes to GitHub with a git push:

Now if you reload the pull request page you should see that the conflict is resolved, check it out:

And we can finally merge this pull request! Victory! 🎉🎉

Wrapping up

You now understand how conflicts happen and you also know all the steps involved in resolving conflicts.

Here is the simple list of all commands and steps to resolve conflicts, remember to replace the <> notations accordingly:

git checkout <name of the branch in conflict>
git pull origin main
open the file in conflict and resolve it
save the file
git add <name of the altered file>
git commit
git push

I hope this article helps you resolve any git conflicts you may encounter going forward. 😉

Extra reading

Here are some more documentation and tips for you to learn about conflict resolution in git:

Resolvendo conflitos em Git

Fri, 24 Dec 2021 20:55:59 +0000

Resolver conflitos pode ser uma tarefa árdua e complicada quando se trata de projetos git. Nesse artigo você vai aprender um passo-a-passo infalível para resolver conflitos.

Caso você já saiba o que são conflitos e queira apenas ver a lista de passos e comandos para resolver um conflito sugiro que pule para a conclusão clicando aqui.

O que é um conflito em git

Quando um projeto tem várias pessoas trabalhando ao mesmo tempo, é possível que duas pessoas precisem fazer alterações no mesmo pedaço de um arquivo. Quando mais de uma pessoa altera o mesmo pedaço de um arquivo em branches diferentes é nesse momento que os conflitos aparecem.

O conflito simboliza que duas ou mais alterações aconteceram no mesmo pedaço de um arquivo e o git não sabe qual das alterações manter.

Como um conflito se forma

Na imagem abaixo temos um diagrama que eu carinhosamente apelidei de “anatomia de um conflito” que mostra os passos até que um conflito se forme. Vale salientar que normalmente, durante o ciclo de desenvolvimento de projetos, as alterações são maiores a por vezes em maior quantidade.

0 - No nosso projeto temos um README.md que foi adicionado pelo commit inicial no repositório. Depois da criação desse arquivo, duas alterações precisam ser feitas para adicionar mais algumas informações ao mesmo arquivo e duas pessoas vão fazer essa alteração;

1 - Cada pessoa então criou um branch a partir da main para trabalhar nas suas alterações, esses novos branches foram criados mais ou menos ao mesmo tempo, ou seja, eles possuem um mesmo ponto de partida;

2 - Durante algum tempo cada pessoa trabalha na sua branch implementando a sua alteração, que nesse caso é adicionar a linha “pessoa x esteve aqui!” no arquivo de README.md sendo x o identificador da pessoa;

3 - A pessoa 1 faz um pull request e tem esse pull request aprovado e seu merge na main;

4 - A pessoa 2 por sua vez, faz o seu pull request para main, só que esse pull request não pode ser feito merge pois apresenta conflitos.

Formando um conflito na prática

Para demonstrar como isso se apresenta, eu criei um repositório com um cenário parecido ao descrito na seção anterior que você pode encontrar aqui. O arquivo inicial foi criado e as duas branches, uma para cada pessoa, também já foram criadas a partir da main, veja:

Em seguida fiz as alterações para cada pessoa, no branch pessoa1 adicionei a descrição “Pessoa 1 esteve aqui!” na última linha do README.md e de forma similar fiz o mesmo processo para o branch pessoa2. Então, abri os dois pull requests:

Revisei e dei o merge no pull request da pessoa1:

E então voltei para o PR da pessoa2 e pude notar a indicação de que o pull request continha um conflito, veja:

E agora com o conflito quentinho em mãos é hora de resolvê-lo.

Resolvendo um conflito no Git

Antes de começar é importante notar que este tipo de conflito é possível resolver também pela interface do GitHub, mas o foco aqui são os comandos, então vamos lá!

A primeira coisa importante é decidir em qual branch resolver o conflito, uma regra que geralmente funciona é resolver os conflitos no branch que apresenta as alterações, neste caso, o branch em questão é o pessoa2, com isso você deve atualizar o seu repositório local, e este branch em particular com os ajustes da main, para isso faça:

git checkout pessoa2
git pull origin main

Isso irá trazer o conflito para a sua máquina te dando um aviso informando que existem conflitos, que você deve resolver o conflito e fazer um commit com o resultado:

Se você abrir o README.md num editor de código irá notar a presença de marcadores indicado por sucessivos sinais de maior que (>), sinais de menor que (>) e sinais de igual (=), aqui um exemplo do conflito mostrado no Vim:

Também é possível que você use o VS Code que mostra o conflito de uma forma mais amigável já que ele marca visualmente, com cores diferentes, cada mudança de origem diferente e ainda te d’a’ opções de como resolver o conflito aceitando parte das mudanças, ou as duas, ou nenhuma delas:

Para entender o que cada botão apresentado pelo VS Code quer dizer, vamos dissecar um pouco esse formato de representação. Um conflito pode ser dividido em duas partes:

As nossas alterações: aquelas que estão no branch corrente também chamadas de alterações atuais (current change);
As alterações dos outros: aquelas que trouxemos para a máquina local ao fazer git pull também chamadas de alterações que estão chegando ou de entrada (incoming changes).

Nesse formato, cada bloco é delimitado por um sinal de maior ou menor até o bloco de sinais de igual repetidos, então por exemplo nesse caso temos os seguintes blocos.

Aquele com as alterações atuais:

<<<<<<< HEAD
Pessoa 2 esteve aqui!
=======

E aquele com as alterações que estão chegando:

=======
Pessoa 1 esteve aqui!
>>>>>>> 3c20251a794ec572e2c3202017d843e2d8769843

Como queremos deixar ambas alterações, podemos apenas apagar as linhas com os marcadores salvar o arquivo, se você estiver usando editores mais simples. No VS Code podemos apertar em “Accept both changes” e continuar com os comandos a seguir. Após aceitar todas as mudanças, manualmente ou usando os botões no VS Code, você deve ter um arquivo assim:

Lembre-se de salvar o arquivo. Em seguida volte para o terminal, se você rodar o comando git status vai ver que o arquivo README.md se mostra com alterações.

Agora você pode adicionar esse arquivo em staging com o seguinte comando:

git add README.md

E fazer o commit das alterações da forma que preferir. Note que ao fazer o commit, se você usar editores para escrever a mensagem de commit, é possível que essa mensagem já venha pré-preenchida como na imagem abaixo:

Você pode personalizar a mensagem ou deixá-la como está e, ao terminar de fazer o commit, enviar essas alterações para o GitHub com um git push:

Agora se você recarregar a página do pull request deverá ver que o conflito foi resolvido, observe:

E podemos finalmente dar merge neste pull request! Vitória! 🎉🎉

Conclusão

Você agora entende como os conflitos se formam e também sabe todos os passos envolvidos em resolver conflitos.

Aqui está a lista simples de todos os comandos e passos para resolver conflitos, lembre de substituir as notações <> de acordo:

git checkout <nome do branch com conflito>
git pull origin main
abra o arquivo com conflito e os resolva
salve o arquivo
git add <nome do arquivo alterado>
git commit
git push

Espero que esse artigo te ajude a resolver os conflitos de git que você encontrar daqui pra frente. 😉

Leitura extra

Seguem mais umas dicas de documentações em português para você aprender sobre resolução de conflitos no git

Criando pastas vazias no git com o .gitkeep

Fri, 24 Dec 2021 14:34:20 +0000

Às vezes você precisa colocar uma pasta vazia no seu projeto no GitHub, mas tradicionalmente o git não faz acompanhamento de pastas vazias, e aí cai a dúvida: “como fazer uma pasta vazia aparecer no GitHub se o git não deixa?”

Não se preocupe, nessa colinha você vai ver como fazer isso usando um arquivo especial chamado .gitkeep.

Isso aconteceu comigo há alguns anos no projeto que eu trabalhava: uma das ferramentas open-source dependia da existência de uma pasta para fazer o download de dados de exemplo e o time decidiu que colocar uma conferência da existência da pasta ou criação dela no nosso código seria um exagero. Uma forma que vimos para garantir a existência da pasta foi usando o .gitkeep.

Ao colocar este arquivo numa pasta vazia, ele garante que o git vá adicionar essa pasta no seu sistema de versionamento e por ser um arquivo oculto, ele facilita a manutenção da estrutura de pastas sem atrapalhar o uso da pasta para outros fins.

Na imagem abaixo você vê um projeto chamado exemplo-pastas que já possui um arquivo README.md que já foi commitado e sem alterações acompanhadas pelo git, em seguida eu crio uma nova pasta chamada diretorio1 e ao fazer novamente o git status o git segue informando que não há mudanças no projeto.

Agora se criarmos o arquivo .gitkeep dentro do diretorio1 o git mostra que há a existência de um diretório a ser adicionado, veja:

Com isso você consegue ver o funcionamento do .gitkeep e caso queira ver na prática esse exemplo está disponível nesse repositório do GitHub.

Creating empty folders in git with .gitkeep

Fri, 24 Dec 2021 14:34:20 +0000

Sometimes you need to put an empty folder in your project on GitHub, but traditionally git doesn’t track empty folders, and then the question pops up: “how to make an empty folder appear on GitHub if git doesn’t allow it?”

Don’t worry about it, you’ll see on this pro tip how to do it using a special file called .gitkeep.

This happened to me a few years ago on the project I was working on: one of the open-source tools depended on the existence of a folder to download sample data and the team decided that putting a check on the folder’s existence or its creation in our code would be an overkill. One way we found to ensure the folder’s existence was using .gitkeep.

By placing this file in an empty folder, it ensures that git will add this folder to your versioning system and because it is a hidden file, it makes it easier to maintain the folder structure without getting in the way of using the folder for other purposes.

In the image below you have a project called exemplo-pastas that already has a README.md file that has already been committed and there are no changes tracked by git, then I create a new folder called diretorio1 and when running git status again git continues to inform that there are no changes to the project.

Now if we create the file .gitkeep inside diretorio1, git shows that there is a directory to be added, see:

With this you can see how .gitkeep works and if you want to see it in practice, this example is available in this GitHub repository.

Viajando Por o Uma API Segura com Flask

Tue, 12 Oct 2021 19:40:00 +0000

Palestra na Python Brasil 2021.

Venha ver como usar Python para construir um mapa para mostrar por onde você andou, colocar esse mapa no ar e, de quebra, aprender a proteger sua API escrita em Flask.

Os slides estão disponíveis aqui.

Assista o replay aqui em baixo 👇

5 Tips to Make Your Pull Request Shine ✨

Wed, 06 Oct 2021 01:15:06 +0000

October is hacktoberfest month and this should be the month where we put the most effort into contributing to open-source and helping more people contribute. So in this article you will learn five 5 golden tips to make your pull request ✨shine ✨. Let’s go!

Follow the project’s contribution guide

A maioria dos projetos open-source tem um conjunto de regras ou padrões que você deve seguir para contribuir, coisas como manter cobertura de testes, criar branches seguindo um certo padrão de nomeação, qual a língua oficial do projeto e de seus commits e até mesmo regras sobre intervalo de tempo com inatividade no qual passado esse períodos o pull requests sem atividade será fechado.

Following the project’s contribution guide will ensure a good path to having a successful pull request right from the start. Such guide is usually found in the CONTRIBUTING.md file on GitHub projects but sometimes the rules can also be described in the README.md file.

Now you might be asking yourself “What do I do if the project doesn’t have a contribution guide?” and this situation is quite common. So if there is no contribution guide what I usually do is look at some commits from the commit history to see how they are made and other pull requests that were made before mine to try to follow the same format.

Use branches in your fork

When forking a project to make a contribution, it is very common to make the mistake of making changes to the main branch and submitting the pull request.

Avoid doing that.

As much as you only plan on making just one pull request, you may be struck by inspiration and you may want to make a second pull request and then you’ve already compromised your main branch with changes from the first pull request, and any contribution from that point forward will contain the changes from the first pull request.

It is ideal to keep the main branch clean of changes this way you can keep it up to date with the main branch of the source repository. So make a good habit of separating your contributions into new branches.

Link the pull request to an issue

There are now, 9 keywords to link your pull request to an issue (if one exists). That’s right, nine! Using these words when making the pull request will make the life of those who maintain the project easier, since these words close the corresponding issue when the pull request is merged, and will also help people who are interested in contributing as they can see the pull request in progress, preventing two people from doing duplicate work.

This is the list of words:

close
closes
closed
fix
fixes
fixed
resolver
resolve
resolved

Any of these words can be used in two places:

In the pull request’s title;
In the pull request’s description.

You should use them as follows to resolve an issue:

fixes #42

Or as follows to resolve more than one issue:

fixes #42, fixes #44

If your pull request does not fully resolve an issue, you should still mention the issue number (by using the hashtag symbol) that is related to your pull request as this will make your pull request appear in the issue as a mention, but in this case you should not use the words above.

As a person who maintains some projects, it makes me very happy to see these words being used in pull requests. You can read more about all of this in GitHub’s documentation on the subject.

Give context to reviewers

Often people who maintain projects, as well as people who contribute to projects, do so in their spare time, that’s not their job. So it’s our duty to facilitate the contribution, both by writing well-described issues if you’re reporting a bug for example, and by well-describing the pull request you’re making. Let’s focus on the pull request that is the main topic of this article.

Nowadays it is very common to find projects that have a pull request template/model, this template seeks to standardize the questions needed to review that pull request and generate changelogs. So focus on what you need to fill in and remember that you can use markdown to style the content of the description and make it easier for people reviewing contributions to read.

Although nowadays many repositories have pull request templates, it could be the case that you are contributing to a project that doesn’t have one of these, so here is a list of topics for you to include in your pull request description:

What is the goal of this pull request?

Here you put that information of which issue (if it exists) is related to this pull request.
What changes were made to achieve this goal?

Code changes, documentation, data flow changes, and alike should come here. Use your commits to remember what you changed.
How to test if these changes really work?

Here you can use prints if it’s something visual, for example, or examples of using the new piece of code.
Possible improvements and other notes

A list of things that could be improved, but that are not the focus of the pull request, or that you don’t know how to solve and need help.

These four points will ensure that the person reviewing will have most if not all the information they need to review the pull request at the time the review takes place.

Wait for suggestions

After making your contribution, the reviewer may have suggestions for improvement or necessary adjustments to ensure the standardization of the code base. These suggestions might ask you to change part of the code, implement tests, or adjust the documentation.

Generally speaking, they come to help your pull request improve and to get your contribution accepted. The review process is always a learning moment, so it is important to have an open mind to receive suggestions and, if necessary, accept them.

Recap

Contributing to open-source is great because it can help all the people who use that project. And during hacktoberfest, for example, is a great time to exercise this skill, so be sure to follow the tips you’ve seen here to be even more successful with your pull requests.

5 Dicas Para Fazer o Seu Pull Request Brilhar ✨

Wed, 06 Oct 2021 01:15:06 +0000

Outubro é mês de hacktoberfest e esse deve ser o mês em que nós nos esforçamos mais para contribuir com open-source e ajudar a mais pessoas contribuírem. Então nesse artigo você vai aprender cinco 5 dicas de ouro para fazer o seu pull request ✨ brilhar ✨. Vamos lá!

Siga o guia de contribuição do projeto

Seguir o guia do projeto vai garantir um bom caminho para ter um pull request bem sucedido logo do começo, esse guia é geralmente encontrado no arquivo CONTRIBUTING.md nos projetos do GitHub mas por vezes as regras também podem estar descritas no arquivo README.md.

Agora você pode estar se perguntando “O que eu faço se o projeto não tiver um guia de contribuição?” e essa situação é bem comum. Então caso não exista um guia de contribuição o que eu faço geralmente é olhar alguns commits do histórico de commits para ver como eles são feitos e outros pull requests que foram feitos antes do meu para tentar seguir o mesmo formato.

Use branches no seu fork

Ao fazer um fork de um projeto para contribuir, é muito comum cairmos no erro de fazer alterações no branch principal e submeter o pull request.

Evite.

Por mais que você só planeje fazer apenas um pull request, pode ser que a inspiração role e você queira fazer um segundo pull request e aí você já comprometeu o seu branch principal com alterações do primeiro pull request e, qualquer contribuição a partir desse ponto vai conter as alterações do primeiro pull request.

Então o ideal é manter o branch principal limpo de alterações até para que você possa mantê-lo atualizado com o branch principal do repositório de origem. Então crie o bom hábito de separar suas contribuições em branches novas.

Relacione o pull request com uma issue

Existem hoje 9 palavras-chave para relacionar o seu pull request com uma issue (se ela existir). Isso mesmo, nove! Usar essas palavras ao fazer o pull request vai facilitar a vida de quem mantém o projeto, pois essas palavras fecham a issue correspondente ao rolar o merge do pull request, e também vai ajudar pessoas que estejam interessadas em contribuir pois elas podem ver o pull request em andamento evitando que duas pessoas façam trabalho duplicado.

Então essa é a lista de palavras:

close
closes
closed
fix
fixes
fixed
resolver
resolve
resolved

Essas palavras podem ser usadas em dois lugares:

No título do pull request;
Ou na descrição do pull request.

Você deve usá-las da seguinte forma para resolver uma issue:

fixes #42

Ou da forma a seguir para resolver mais de um issue:

fixes #42, fixes #44

Caso o seu pull request, não resolva uma issue por completo, você ainda deve mencionar o número da issue que tem relação com o seu pull request pois isso vai fazer que o seu pull request apareça na issue como uma menção, mas nesse caso não deve usar as palavras acima.

Como uma pessoa que mantem alguns projetos, me faz muito feliz ver essas palavras sendo usadas nos pull requests. Você pode ler mais sobre isso nessa documentação do próprio GitHub sobre o assunto.

Dê contexto para quem vai revisar

Muitas vezes as pessoas que mantêm projetos, assim como as pessoas que contribuem com projetos, fazem isso no seu tempo livre, ou seja, esse não é o trabalho delas. Então é nosso dever facilitar a contribuição, tanto ao escrever issues bem descritas se você estiver relatando um bug por exemplo, como descrever bem o pull request que você está fazendo. Vamos focar no pull request que é o foco deste artigo.

Hoje em dia é muito comum encontrar projetos que tenham um template/modelo de pull request, esse template busca padronizar as perguntas necessárias para a revisão daquele pull request e a geração de changelogs. Então foque no que você precisa preencher e lembre-se que é possível usar o markdown para estilizar o conteúdo da descrição e facilitar a leitura das pessoas que revisam as contribuições.

Embora hoje em dia vários repositórios tenham templates de pull request, pode ser que você está contribuindo para um projeto que não tem um desses, então aqui vai um lista de tópicos para você incluir na descrição do seu pull request:

Qual o objetivo desse pull request?

Aqui coloque aquela informação de qual issue (se ela existir) se relaciona com esse pull request.
Quais alterações foram feitas para atingir esse objetivo?

Alterações de código, documentação, mudanças de fluxo de dados e afins devem vir aqui. Use os seus commits para relembrar o que você mudou.
Como testar se essas mudanças realmente funcionam?

Aqui pode usar prints se for algo visual, por exemplo, ou exemplos de uso do pedaço de código novo.
Possíveis melhorias e outras anotações

Uma lista de coisas que poderiam ser melhoradas, mas que não são o foco do pull request, ou que você não sabe como resolver e precisa de ajuda.

Esses quatro pontos, vão garantir que a pessoa revisando vai ter todas informações que ela precisa para revisar o pull request no momento que a revisão for acontecer.

Aguarde as sugestões

Depois de fazer a sua contribuição a pessoa revisora pode ter sugestões de melhoria ou ajustes necessários para garantir a padronização da base de código. Essas sugestões podem pedir que você mude parte de código, implemente testes ou ajuste a documentação.

De um modo geral elas vêm para ajudar o seu pull request melhorar e para que a sua contribuição seja aceita. O processo de revisão é sempre um momento de aprendizado então é importante ter a mente aberta para receber sugestões e caso necessário acatá-las.

Recapitulando

Contribuir com open-source é ótimo pois pode ajudar todas as pessoas que usam aquele projeto. E durante o hacktoberfest, por exemplo, é um ótimo momento para exercitar essa habilidade, então não deixe de seguir as dicas que você viu aqui para ter ainda mais sucesso no seus pull requests.

Ah e último recadinho, se você estiver procurando por projetos brasileiros para contribuir aqui está a lista de 2021.

Projetos Brasileiros para fazer pull requests nesse #Hacktoberfest 2021

Fri, 01 Oct 2021 09:00:00 +0000

Edição atual da lista disponível aqui.

Outubro chegou e com ele chegou o #Hacktoberfest, todo ano tenho feito (às vezes com ajuda das amizades valeu demais @anaschwendler) a lista para que você possa contribuir durante o #Hacktoberfest.

E é chegado o momento da lista para esse ano! Então aqui vai! Uma lista toda repleta de projetos pra você contribuir nesse mês de Outubro!

Edições anteriores

Regras para entrar nessa lista

As regrinhas do ano passado se repetem:

Ser um projeto criado/desenvolvido/mantido por brasileiras(os);
Precisa ser um projeto, não pode ser uma organização, caso tenha mais de um projeto da organização precisa ser um PR por projeto com uma entrada por projeto
Ter pelo menos uma issue aberta.

Avisos para 2021

Assim como 2020 não foi fácil, 2021 também trouxe seus desafios, então é sempre bom lembrar que para apenas contribuir com o que pode! 😉

Os projetos continuam separados pela linguagem principal pra facilitar as buscas pra quem lê e também em ordem alfabética pela linguagem. 😉

ATUALIZAÇÃO IMPORTANTE:

"Acorda menina! Olha as novas regras! New Rules!" - Ana Maria Braga

O mais importante desse ano é que se você submeter dois PRs inválidos você sofrerá uma desqualificação por período indeterminado!

Para um PR ser considerado inválido, ele deve ser marcado com as tags spam ou invalid. Então é bom tentar fazer PRs de qualidade!

Relembrando que para tornar seu PR válido para a hacktoberfest você precisa ter algumas coisas. PRs apenas contarão se:

O repositório onde o PR foi aberto tem um tópico chamado hacktoberfest (esse site aqui tem esse tópico então qualquer PR não invalido já vai contar para o evento 😉)

O PR foi aberto em Outubro
OU o PR é adicionado (merged) ao projeto OU está com o rótulo (label) hacktoberfest-accepted por um mantenedor OU o PR foi aprovado.

Mais informações no site oficial (em inglês).

Por último, nesse outro artigo tem 5 Dicas Para Fazer o Seu Pull Request Brilhar ✨ e pode ser útil.

Happy Hacking! 🎉

C#

C

CSS

Clojure

C++

Elixir

Go

JavaScript

Julia

Kotlin

PHP

Pearl

Python

Ruby

Scala

Shell

Swift

TypeScript

Variados

Tips for Writing Great Technical Content

Fri, 17 Sep 2021 18:30:00 +0000

Hackmamba Content Hackathon happened in September 2021 and it started by having two days of workshops. One of them was about tips for writing technical content

The slides are available here.

And you watch it below 👇

Braincast 423

Wed, 08 Sep 2021 13:00:00 +0000

No Braincast 423, Carlos Merigo, Cris Dias, Jessica Temporal e Roberta Arcoverde discutem as mudanças trazidas no mundo do trabalho com as linguagens de programação e se perguntam: aprender a programar é tão importante assim?

Confira os detalhes no site do Braincast ou aperte o play ali em baixo 👇

Fechatag #40

Mon, 30 Aug 2021 13:00:00 +0000

Um papo com o Montanha, onde conversamos sobre a minha carreira, como foram estudos de faculdade, minhaa migração para ciência de dados com Python, meu relacionamento com a comunidade, diversos projetos paralelos e claro um pouco também dos meus hobbies como tricô!

Você confere tudo lá no canal do FechaTag ou apertando o play ali em baixo 👇

Traveling Through a Secure API with Python and Auth0

Tue, 24 Aug 2021 18:30:00 +0000

A talk given at the first joint even from Okta and Auth0 in 2021.

The slides are available here.

Watch it below 👇

Conheça o GitFichas!

Sat, 21 Aug 2021 15:44:33 +0000

Eu comecei um novo projeto, e decidi vir aqui te contar tudo sobre ele! 👀

Há algum tempo eu tenho ajudado qualquer pessoa que precise de ajuda com Git. Pelo que tenho visto, a maioria das pessoas usa os comandos git diariamente sem necessariamente entendê-los…

Isso não é um problema, principalmente se você está começando a sua jornada com versionamento, no entanto, não entender os comandos pode te levar a enrascadas com o Git (conflitos eu estou olhando pra vocês). E por mais que o Git nos ajude no processo de desenvolvimento a rastrear alterações, conflitos e detached heads são coisas chatas de resolver, principalmente se você não entende o que precisa fazer não é mesmo?

Com o objetivo de melhorar a vida de quem usa Git, eu comecei o GitFichas. O GitFichas nada mais é do que um site que agrega fichas de estudo sobre Git, tudo em bom português e da forma mais simples possível para que qualquer pessoa possa entender melhor cada comando ou conceito.

GitFicha número 008 falando sobre o git add -p

As fichas são imagens que explicam comandos ou conceitos que eu uso diariamente no Git e ainda trazem dicas pouco conhecidas ou utilizadas, mas que quando bem aplicadas são uma mão na roda.

Toda semana sai uma ficha nova na quarta-feira.

Eu publico as fichas no meu perfil no Twitter e no LinkedIn, mas você pode aproveitar e seguir o GitFichas no Instagram ou se inscrever no canal do GitFichas no Telegram.

E se você quiser sugerir um comando ou conceito para ver no formato de ficha, deixa o seu comentário ali em baixo ou responde esse tweet aqui 👇

Perguntando pro meu TCC: Que comando #git você tem dificuldade mesmo rodando ele com frequência?
— Jessica Temporal (@jesstemporal) July 27, 2021

Eu to colocando os comandos que me mandam na fila para fazer fichas 😉

[Live Stream] Como Montar tua Palestra para Python Brasil

Wed, 04 Aug 2021 18:00:00 +0000

Live no canal do PyLadies Brasil sobre como montar uma palestra para a Python Brasil.

Nesse espaço eu e a Leticia Portella demos várias dicas sobre como preparar e submeter palestras para a Python Brasil, mas as dicas podem ser usadas para qualquer evento. 😉

Assista na íntegra abaixo. 👇

RaphaCast: Second Season

Wed, 04 Aug 2021 13:00:00 +0000

I spoke about my trajectory in technology, how I started, how the Python community is fundamental part in everything I do, and finally how I joined Auth0 to be a developer advocate.

Listen in to get to know more about me 👇

Traveling through a secure API in Python

Fri, 30 Jul 2021 13:00:00 +0000

A talk given at the 2021 EuroPython.

The slides are available here.

And you can see more details in the talk page.

Introdução aos Módulos de Análise de Dados

Sat, 17 Jul 2021 03:00:00 +0000

O material do tutorial pode ser encontrado aqui.

Mais detalhes sobre o evento aqui.

Como Lidar com JWTs em Python

Fri, 02 Jul 2021 12:20:03 +0000

Os JSON Web Tokens, ou JWTs, estão em toda a Internet. Eles podem ser usados para rastrear bits de informação sobre um usuário de uma forma muito compacta ou em APIs para fins de autorização. Este artigo vai mostrar o que são os JSON Web Tokens e como criar JWTs no Python usando a biblioteca JWT mais popular: PyJWT. Você também vai descobrir como você pode assinar e verificar JWTs no Python usando algoritmos simétricos e algoritmos assimétricos.

Para continuar lendo esse artigo, clique no botão abaixo 👇

How to Handle JWTs in Python

Fri, 02 Jul 2021 12:20:03 +0000

JSON Web Tokens, or JWTs for short, are all over the web. They can be used to track bits of information about a user in a very compact way and can be used in APIs for authorization purposes. This post will cover what JSON Web Tokens are and how to create JWTs in Python using the most popular JWT library: PyJWT. We are also going to see how you can sign and verify JWTs in Python using asymmetric algorithms.

To keep reading this article, click on the button below 👇

Configuring and accessing your droplet via SSH

Mon, 31 May 2021 03:00:00 +0000

If you read my post on how to create your machine on the cloud with Digital Ocean, now you have a brand new cloud machine, yay you! But you still need to configure the access so you can SSH into it.

To configure the SSH access, you’ll have to log in to your machine using the root access for the first time. This may be a little tricky, and to do the first access, you’ll need to set up a new password because every system comes with one predefined root user and password.

The first thing you need to do is access the specific droplet page by clicking on your droplet in the droplets list, and you’ll see something like this:

After that, you’ll need to access the console for that droplet. The console is a terminal inside a browser window, and to access it click the Console button in the header:

Then you’ll see something like the image below in a new tab of your browser:

Since I couldn’t find the default password for my droplet, here’s what I did: I clicked the Access option on the left-side menu:

Once the page loads, you’ll see an option to Reset the root password and that’s exactly what we want:

Then you must click the Reset Root Password. You may be wondering, “What will happen if you click on this scary button?” and the first thing that will happen is that the droplet will restart. Second, a new root password will be created for you, and finally, the new password will be sent to you by e-mail so you can access your droplet via console. Here’s an example of said e-mail:

Now, with that password, you can go back to the droplet page and open up the console again, and you should input the information you have. The user for root in Ubuntu is root, and the password is the one you received by e-mail. After that, you can set up the new password for the root user:

Note: you’ll need to find the default root user for the OS of your choosing.

Now you are good to go!

Creating your own user

Okay, maybe you are doing just fine using the root user, but I like my terminal a cool colorful theme. So it’s time to create a user for myself. To do this, there are a few commands.

First, we need to choose your user name. For the lack of creativity, I chose jess to be my username, and you can use the command adduser to create a new user:

adduser jess

And once you run the command, you’ll be prompted to create a password. You may optionally add some extra information for the user:

Once you confirm all the information is correct, you can give your user sudo powers. Sudo powers will let you install things without having to access the root user. So to do this, you need to run the following:

usermod -aG sudo jess

Remember to adjust the command for your username. And now you are done setting up your user account. Congratz!

Configuring the droplet for access via SSH

Another thing that we might want to do is to access our user profile via SSH. Now let’s see what we need to do to be able to access your user.

My main goal with setting up this instance was so that I can code from my iPad. I bought an app called TexTastic, and it is a very complete app. Textastic has built-in the possibility to access via SSH, and it creates a terminal for you. I’ve been using it for quite some time, and it hasn’t failed me so far.

Okay, I’m blabbing a little bit. Let’s go back to the point at hand, accessing. Since I didn’t want to generate a new SSH-key pair, I copied the SSH I used for accessing the machine as root. When you add the SSH key as an authentication method while creating the droplet, it adds the public key to the authorized_keys file for the root user. To use the same key to access your user as the root user, you must copy this file to your user .ssh directory and adjust the ownership.

For the next couple of commands, I will move back and forth between my user jess and the root user. I’ll denote which user you should use to run the command by using parenthesis and the user name inside like (jess) or (root) before the command itself.

The first thing you must do is log in as your user:

(root) $ su jess

And you’ll probably be prompted to input the user password, then you can create the .ssh directory:

(jess) $ mkdir ~/.ssh

After that, you should go back to the root user and copy the authorized_keys file:

(jess) $ su root
(root) $ cp ~/.ssh/authorized_keys /home/jess/.ssh/

Then the final step, you must change the ownership of the file you just copied. If you don’t do this, you won’t be able to access your machine as your user.

(root) $ chown jess /home/jess/.ssh/authorized_keys

Go on! Have a little break 😉 You deserve it 👏

Configuring your machine to access the droplet via SSH

We are close, I promise! At this point, you have everything set up access your cloud machine. So let me teach you to find the information required to run your SSH command.

Once again, you need to go to the droplet-specific page. Right below the name of the droplet, you’ll see an ipv4 tag that contains an IP, that’s your domain:

And that’s it, all you need to do is open your terminal of choice and run the command like so:

$ ssh jess@159.203.72.53

And that would allow you to log right in because you set up the SSH keys and everything else.

Next steps

After all that is configured, I’ll probably do some tweaks to my setup to improve the way my terminal looks. Here are some things that you might like to do as well:

Install zshell
Adjust the VIM/emacs/nano configuration
Create a new pair of SSH keys to use with GitHub from the cloud instance

That’s it for today 😉

Configurar e acessar sua droplet via SSH

Mon, 31 May 2021 03:00:00 +0000

Se você leu meu tutorial sobre como criar sua máquina na nuvem com o Digital Ocean, agora você tem uma nova máquina na nuvem, yay você! Mas você ainda precisa configurar a máquina para poder acessaá-la via SSH.

Para configurar o acesso SSH, você precisará fazer o login na sua máquina usando o acesso root pela primeira vez. Isso pode ser um pouco complicado, e para fazer o primeiro acesso, você precisará definir uma nova senha, pois todo sistema vem com um usuário root e senha predefinidos.

A primeira coisa que você precisa fazer é acessar a página da droplet específica clicando na sua droplet na lista de droplets, e você verá algo assim:

Depois disso, você precisará acessar o console para essa droplet. O console é um terminal dentro de uma janela do navegador e para acessá-lo, clique no botão Console no cabeçalho:

Then you’ll see something like the image below in a new tab of your browser:

Como eu não consegui encontrar a senha padrão para o meu droplet, aqui está o que eu fiz: cliquei na opção Acesso no menu da esquerda:

Uma vez que a página carregar, você verá uma opção “Reset the root password” para redefinir a senha root e é exatamente o que queremos:

Então você deve clicar no botão Reset Root Password. Você pode estar se perguntando, “O que acontecerá se você clicar neste botão assustador?” e a primeira coisa que acontecerá é que a droplet será reiniciada. Em segundo lugar, uma nova senha root será criada para você e, por fim, a nova senha será enviada para você por e-mail para que você possa acessar seu droplet via console. Aqui está um exemplo de tal e-mail:

Agora, com essa senha, você pode voltar à página da droplet e abrir o console novamente e você deve inserir as informações que você tem. O usuário para root no Ubuntu é root e a senha é a que você recebeu por e-mail. Depois disso, você pode configurar a nova senha para o usuário root:

Nota: você precisará encontrar o usuário root padrão para o sistema operacional de sua escolha.

Agora você tem para começar!

Criar o seu próprio usuário

Tudo bem, talvez você esteja indo bem usando o usuário root, mas eu gosto do meu tema de terminal colorido. Então é hora de criar um usuário que me permita ter minhas customizações. Para fazer isso, existem alguns comandos.

Primeiro, precisamos escolher o seu nome de usuário. Por falta de criatividade, eu escolhi jess para ser meu nome de usuário, e você pode usar o comando adduser para criar um novo usuário:

adduser jess

E depois que você executar o comando, você será solicitado a criar uma senha. Você pode opcionalmente adicionar algumas informações extras para o usuário:

Uma vez que você confirme que todas as informações estão corretas, você pode dar ao seu usuário poderes sudo. Os poderes sudo permitirão que você instale coisas sem ter que acessar o usuário root. Então, para fazer isso, você precisa executar o comando seguinte:

usermod -aG sudo jess

Lembre-se de ajustar o comando para o seu nome de usuário. E agora você terminou de configurar sua conta de usuário. Parabéns!

Configurando a droplet para acesso via SSH

Outra coisa que podemos querer fazer é acessar o nosso perfil de usuário via SSH. Agora vamos ver o que precisamos configurar para poder acessar o seu usuário.

Meu principal objetivo ao configurar essa instância era para que eu pudesse codificar usando o meu iPad. Comprei um aplicativo chamado TexTastic, e é um aplicativo muito completo. O Textastic tem a possibilidade de acessar uma máquina via SSH, e ele cria um terminal para você. Eu estou usando esse app há bastante tempo, e até agora não me decepcionou.

Okay, estou divagando um pouco. Vamos voltar ao ponto em questão, acessar a máquina com SSH. Como eu não queria gerar um novo par de chaves SSH, copiei o SSH que usei para acessar a máquina como root. Quando você adiciona a chave SSH como um método de autenticação ao criar a droplet, ele adiciona a chave pública para o arquivo authorized_keys do usuário root. Para usar a mesma chave para acessar seu usuário como usuário root, você deve copiar este arquivo para o diretório .ssh do seu usuário e ajustar a propriedade do arquivo (ownership).

Para os próximos comandos, vou alternar entre o meu usuário jess e o usuário root. Eu indicarei qual usuário deve usar para executar o comando usando parênteses e o nome do usuário dentro, como (jess) ou (root) antes do próprio comando.

A primeira coisa que você deve fazer é fazer login como seu usuário:

(root) $ su jess

E você provavelmente precisará a inserir a senha do usuário. Depois disso você pode criar o diretório .ssh:

(jess) $ mkdir ~/.ssh

Depois disso, você deve voltar para o usuário root e copiar o arquivo authorized_keys:

(jess) $ su root
(root) $ cp ~/.ssh/authorized_keys /home/jess/.ssh/

Então, o último passo, você deve alterar a propriedade do arquivo que acabou de copiar. Se você não fizer isso, não será capaz de acessar sua máquina como seu usuário.

(root) $ chown jess /home/jess/.ssh/authorized_keys

Bora! Pode dar uma descansadinha 😉 Você merece 👏

Configurando sua máquina para acessar a droplet via SSH

Estamos perto, prometo! Neste ponto, você tem tudo configurado para acessar sua máquina na nuvem. Então, deixe-me ensinar a você a encontrar as informações necessárias para executar seu comando SSH.

Mais uma vez, você precisa ir para a página específica da droplet. Logo abaixo do nome da droplet, você verá uma etiqueta ipv4 que contém um IP, esse é o seu domínio:

E é isso, tudo o que você precisa fazer é abrir o seu terminal preferido e executar o comando assim:

$ ssh jess@159.203.72.53

E isso vai te permitir acessar diretamente a droplet porque você configurou as chaves SSH e tudo o mais.

Próximos passos

Depois que tudo estiver configurado, provavelmente farei alguns ajustes na minha configuração para melhorar a aparência do meu terminal. Aqui estão algumas coisas que você também pode querer de fazer:

Instalar o zshell
Ajustar a configuração do VIM/emacs/nano
Criar um novo par de chaves SSH para usar com o GitHub a partir da instância na nuvem.

É isso por hoje 😉

What's new in Flask 2.0

Fri, 21 May 2021 21:44:37 +0000

Flask is the most used framework for web development according to the Jetbrains Python Developers Survey from 2020, and in May of 2021, version 2.0.0 of Flask came out with 31 new changes. In this post, you’ll learn about some of those changes and the refactoring you might want to do to your code to take the most advantage of this new version.

To keep reading this article, click on the button below 👇

Getting to know Jessica Temporal, Sr. Developer Advocate @ Auth0

Thu, 29 Apr 2021 12:20:03 +0000

I believe everybody has had an “aha moment” in their lifetime. I want to tell you about 2 of those moments for me.

I also believe people mistake aha moments as something that happens out of nowhere, but when in reality, at least for me, those happen after much work.

Something just clicks, and things start falling into place. Before I can tell you about my aha moments, you need to know me a little bit.

To keep reading this article, click on the button below 👇

Criando a sua máquina na nuvem com Digital Ocean

Wed, 21 Apr 2021 22:48:25 +0000

Este post é um passo-a-passo sobre como criar uma instância de nuvem na Digital Ocean.

video da Michelle Obama dizendo 'Vamos Fazer isso!'

Conheça a Digital Ocean

A Digital Ocean (DO) oferece uma gama de soluções em computação em nuvem e a minha favorita é chamado de Droplet (ou gota em Português). Droplet é uma máquina virtual que você pode usar para praticamente qualquer coisa, e adoro usá-las como um computador poderoso quando tenho poder computacional limitado, coisa que falei sobre nesse outro artigo. Ainda assim, também é uma escolha muito legal para quem deseja codificar de qualquer lugar, até mesmo de dispositivos móveis como celulares e tablets.

Há uma grande variedade de sistemas operacionais para escolher e é bem simples para começar (apesar dos vários passos), então sempre que preciso de alguma computação em nuvem, penso na DO primeiro.

Crie uma droplet

A primeira coisa que você precisa fazer é criar sua conta na DO. Para fazer isso, você deve acessar o site deles e se inscrever por meio do formulário já disponível na página inicial:

Depois disso, a página recarregará e aparecerá o painel de controle onde você pode ver todas as soluções disponíveis. Clique na opção “Droplets” no menu à esquerda, e você deve ver na página uma lista de suas droplets atuais:

Como você pode ver na imagem acima, eu já tenho uma droplet lá chamada jtemporal e também posso criar uma nova clicando no botão “Create droplet” (Criar Droplet em tradução livre) que aparece em verde no canto superior esquerdo, e isso vai te levar pra uma página onde você pode escolher a configuração que você deseja para a sua droplet.

A primeira coisa que você precisa escolher é o sistema operacional:

Em seguida, você deve escolher um plano de pagamento:

Escolher a configuração correta é essencial. Atualmente, eu uso uma droplet principalmente para coisas como escrever e criar exemplos para postagens no blog. O plano básico com uma CPU compartilhada se encaixa perfeitamente para esse tipo de uso, mas talvez você precise de uma CPU dedicada se você precisar rodar algo mais pesado. Portanto, escolha com cuidado. Minha instância atual é do plano básico com uma CPU de 2 GB e disco de 50 GB, o que vai me custar dez dólares por mês.

O dólar tá caro eu sei, mas eu não vivo com uma droplet o tempo todo, eu sempre apago ela depois que termino a tarefa que tinha para fazer e crio uma nova quando eu precisar, com isso o custo fica em questão de centavos de dólares.

Depois de escolher a melhor configuração para o seu uso, você deve escolher se deseja “adicionar armazenamento em bloco” na seção Add block storage, imagine que este é o HD externo que você pode levar com você sempre que quiser. O armazenamento em bloco salva dados e é compartilhado entre as instâncias, mas observe que o armazenamento em bloco tem um custo extra, então você está com um orçamento apertado, tenha isso em mente. 😉

Depois de decidir qual plano usar e se deseja ou não ter armazenamento em bloco, você deve escolher uma região para sua instância. Isso significa que você deve decidir em qual lugar do mundo o data center que hospedará a sua máquina virtual está fisicamente localizado. Quanto mais próximos estiverem de você geograficamente, menor será o atraso na comunicação com a máquina. Escolhi a região de Nova York por ser a mais próxima de mim.

Cada região vem com uma rede VPC configurada para que você possa transferir facilmente dados e informações de uma instância para outra na mesma região. Você também pode adicionar redes VPC personalizadas, mas por enquanto, a que vem por padrão será suficiente.

Você também pode adicionar alguns complementos extras aos seus droplets, como monitoramento e disponibilidade de conexões IPv6. Eu não escolhi nenhum complemento, pois não preciso deles agora, mas escolha o que melhor se adaptar às suas necessidades.

Agora que você tem todas as configurações básicas para a sua instância configurada, você precisará definir uma maneira de acessá-la. É aqui que entram as chaves SSH. Já tenho minhas chaves SSH configuradas em minha conta e você pode ver na imagem abaixo que tenho algumas, então, para esta instância, escolhi a que estou usando atualmente que é a chave chamada textastic. Se preferir você pode também definir uma senha para o usuário root se selecionar Password, mas lembre-se de não repetir senhas e usar sempre um gerenciador de senhas para gerar senhas longas e randômicas (eu uso o LastPass).

Para finalizar, você precisa dar um nome à sua instância. Se você não quiser escolher um nome, a Digital Ocean gera um nome aleatório, como você pode ver abaixo:

Para a instância que vou usar diariamente, escolhi o “jtemporal” - o nome que normalmente uso para os “arrobas” nas redes sociais 🤣.

Existem mais 3 coisas que você terá de decidir: pode adicionar etiquetas (tags) à sua instância; isto pode ser uma ferramenta de organização útil se tiver muitos projetos em andamento e quiser agrupar instâncias com base em tópicos. Também pode criar projetos diferentes e selecionar o projeto que deseja aqui, e finalmente, é possível ativar backups. Eu não fiz nada disso, mas recomendo estudar cada um desses com base no seu caso de uso. Agora você está quase lá. Só precisa de clicar no grande botão verde que diz “Create Droplet”:

E sua instância será criada e começará a inicializar.

Quando você clicar no botão “Create Droplet”, verá a sua nova droplet na lista de droplets vinculadas à sua conta e pode ser necessário esperar alguns minutos enquanto ela termina de ser configurada. Quando a droplet estiver pronta, terá um ponto verde ao lado do nome, como a minha instância jtemporal tem na imagem acima, e então você pode acessá-la.

Parabéns! Você conseguiu! Você criou sua droplet com sucesso!

Neste próximo post, falo sobre como configurar a Droplet para que você possa realmente usá-la com SSH e tudo., depois da uma conferida 😉

Creating your machine on the cloud with Digital Ocean

Wed, 21 Apr 2021 22:48:25 +0000

This post is a step-by-step on how to create a cloud instance on Digital Ocean.

Get acquainted with Digital Ocean

So Digital Ocean (DO) provides a range of solutions in cloud computing. My favorite one is called Droplets. Droplets are a virtual machine that you can use for pretty much anything, and I love to use them as a powerful computer when I have limited power available. Still, it is also a pretty neat choice for those who want to code from anywhere, even from mobile devices.

There is a wide range of operating systems to chose from, and it is pretty straightforward to begin with, so whenever I need some cloud computing, I think of Digital Ocean as the first choice.

Create the droplet

The first thing you’ll need to do is create your account on DO. To do this, you must access their website and sign up using the form already available on the landing page:

After that, you’ll be taken to your dashboard, where you’ll see all the solutions available, and you should click on the Droplets option on the menu on the left-hand side, and this will take you to the page where you can see a list of your current droplets:

As you can see in the above image, I already have a droplet there called jtemporal and I can also create a new one by clicking the Create droplet button on the top left corner, and this will take you to a page where you can choose the configuration you want for your droplet.

The first thing you need to choose, is the operational system:

Then you have to pick a payment plan:

Choosing the right one for either of these choices is essential. Currently, I mostly use my droplet for things like writing and creating examples for blog posts. The basic plan with a shared CPU fits the bill perfectly, but maybe a dedicated CPU might be your thing if you need something more heavy-duty. So choose with care. My current instance is from the basic plan with a 2GB CPU and 50GB disk, which will cost me ten dollars a month.

After picking the best configuration for your use case, you have to choose whether you want to “Add block storage”, imagine this is the external HD that you can take with you whenever you travel. Block storage saves the data and shares it across instances or maybe takes it from one instance to another. But note that block storages cost extra, so if you are on a budget. Keep that in mind. 😉

After deciding which plan to use and whether or not you want to have block storage, you must choose a region for your instance; This means you have to decide where your machine’s data center is physically located. The closer they are to you geographically, the less delay you’ll have to deal with. I chose the New York region since it is the closest to me.

Each region comes with a VPC network configured, so you can seamlessly transfer data and information from one instance to another in the same region. You can add custom VPC networks too, but for now, the default will be enough.

You can also add some extra add-ons to your droplets, like monitoring and IPv6 connections availability. I didn’t choose any add-ons since I don’t need them right now but chose what best fits your needs.

Now that you have all the basic configuration for your instance set up, you’ll need to define a way to access it. This is where the SSH keys come in. I have my SSH keys already set up in my account, and you can see by the picture below that I have a couple, so for this instance, I picked the one I’m currently using that is named textastic.

To finalize, you need to give a name to your instance. If you don’t want to choose a name Digital Ocean generates a random name, as you can see below:

For the instance I’m going to use daily, I gave it a shorter name - jtemporal - the name I usually use for my handles on social media 🤣.

There are 3 more things you’ll need to decide on: you can add tags to your instance; this can be a helpful organizational tool if you have many projects going on and you want to group instances based on topics. You can also create different projects and select the project you want here, and finally, you can enable backups. I didn’t do any of this, but I truly recommend it. Now you are almost there. You only need to click the big green button that says Create Droplet:

and your instance will be created and will start to boot up:

Once you click the “Create Droplet” button, you’ll see your new droplet on the list of droplets linked to your account, and you might need to wait a couple minutes while it finishes booting up. Once the droplet is ready, it will have a green dot by the name like my instance jtemporal has in the above image, and then you can access it.

Congratulations! You did it! You created your droplet successfully!

In this next post I talk about how to configure the Droplet so you can actually use it with SSH and all, check it out 😉

My first AvocadoLabs live o/

Thu, 15 Apr 2021 14:00:00 +0000

Basically a meet and greet ;)

Details

Avocado Labs Community Hour

Video

Quais ferramentas focar para qualquer vaga em TI

Fri, 26 Mar 2021 18:28:34 +0000

A pergunta que eu mais recebo em particular nas minhas redes sociais é “Jessica estou precisando de um norte para direcionar meus estudos na área x, consegue me ajudar?”. Como ela acontece com certa frequência decidi tentar ajudar a respondê-la aqui.

Como todas os demais questionamentos na área de tecnologia, a resposta pra essa pergunta é: depende! E já pra começar com clichês, eu não vou te dar o peixe, eu vou te ensinar a pescar 😉

Neste artigo, vou usar como exemplo a área em que trabalhei muitos anos e que sempre é mencionada nos pedidos de ajuda que recebo: a Ciência de Dados, mas saiba que é possível abstrair essa lógica e aplicar os mesmos passos para outros tipos de cargos e áreas, principalmente em tecnologia.

Por mais que você queira trabalhar com ciência de dados, os requisitos para cientistas variam de empresa para empresa e não existe uma receita de bolo que vá servir para todo mundo, afinal de contas, como diz mainha: “Você não é todo mundo”. E por um lado isso é ótimo, pois te dá uma liberdade para trilhar um caminho diferente dos demais, mas ao mesmo tempo levanta a inevitável pergunta: “O que eu preciso focar/ter no meu currículo para ser considerada pra uma vaga?”.

E aí que entra o pulo do gato, se você não tem uma empresa dos sonhos em que você quer trabalhar, você vai precisar se organizar para um processo seletivo que não é unificado. Diferentemente de concurso ou vestibulares que os requisitos são conhecidos e expostos para todos, vagas de emprego e principalmente vagas para grandes empresas não são iguais só por que o cargo tem o mesmo nome. Inclusive, ouso dizer que dentro da mesma empresas, um mesmo cargo para times diferentes podem esperar de você capacidades diferentes, então vamos ver como descobrir um caminho no meio de um matagal.

Ler esse post e colocar ele em prática não vai te garantir um emprego, mas os passos que eu mostro aqui devem te ensinar a desenhar o seu currículo de forma que ele apresente as ferramentas mais interessantes dentre as milhares tecnologias pedidas pelas empresas. Pra isso você vai precisar de 3 coisas:

Acesso à internet
Uma conta no LinkedIn
Um software para planilhas

Se você está lendo esse post provavelmente você já está usando o item 1. Com uma base de usuários crescente eu imagino que você já possua sua conta no LinkedIn, caso você ainda não tenha uma conta no LinkedIn e não queira criar uma, você vai ter mais trabalho para coletar os dados que vamos precisar e, já aviso de antemão, que eu vou me apoiar bastante no uso do LinkedIn. Por fim, vamos usar um software de planilhas e aqui eu escolhi o Google Sheets, mas sinta-se a vontade para usar o software de sua preferência.

Coleta de dados

Eu gosto de encarar o primeiro passo como a coleta de dados, esses dados tem como objetivo responder uma pergunta bem clara “Qual conjunto de ferramentas e habilidades devo focar nos próximos meses para construir meu portfólio?”.

Para começar abra o LinkedIn, abaixo você a minha página inicial. Ao centro, você vê a caixa para começar um novo post e o comecinho de um post do Data Bootcamp que foi curtido por pessoas na minha rede. A esquerda você vê o meu perfil com algumas estatísticas, a direita sugestões de tópicos para seguir, mas o nosso foco vai ser na barra superior.

É na barra de mais acima da página que você encontra o campo de busca do LinkedIn, é nessa parte onde você deve inserir os termos de busca como por exemplo empresas que você tem interesse, tópicos/hashtags sobre assuntos para você acompanhar, ofertas de vagas disponíveis e pessoas para se conectar, tente me achar por exemplo, digite “Jessica Temporal” e aperte enter para ver se eu apareço na lista de pessoas sugeridas.

Outra parte interessante é a aba de “Jobs”. Nessa aba você tem uma pesquisa específica para vagas anunciadas na plataforma. Você pode fazer uma pesquisa tão ampla ou tão específica quanto queira, vamos ver como fazer isto a seguir. Além disso, também é possível criar notificações para uma busca, assim, novas vagas que surgirem com os filtros escolhidos chegam para você por e-mail.

Agora que você já conhece um pouco da interface vamos fazer a primeira busca, suponha que você quer ser cientista de dados, mas quer trabalhar na cidade de São Paulo. Na primeira caixa você deve preencher o cargo ou termo de pesquisa (não clique nas opções da lista que vai aparecer ainda) e na segunda caixa digite a cidade de interesse e clique em “Search” ou “Buscar” se o seu LinkedIn estiver em Português.

Ao clicar em buscar, a página irá recarregar e mostrar uma lista de vagas para aquela região, veja:

E se você notar, logo abaixo da barra de pesquisa, temos filtros. São esses filtros que vamos usar para achar dez vagas de cientista de dados para tentar responder a nossa pergunta inicial.

A primeira coisa que vou fazer vai ser escolher algumas empresas, para isso use o filtro “Company” ou “Empresa”, e vou selecionar algumas empresas, aqui selecionei apenas algumas empresas Brasileiras e depois de selecionar todas as que tenho interesse cliquei em “Show results” ou “Mostrar resultado”:

Depois de recarregar a página você vai ver uma lista filtrada de cargos disponíveis:

Cada vaga possui pelo menos 3 elementos:

Uma descrição da empresa;
Uma lista de responsabilidades para a vaga;
Uma lista de habilidades desejadas também chamada de requisitos.

É essa lista de habilidades que você vai precisar focar, abaixo você vê os requisitos para três vagas de cientista de dados para três empresas diferentes:

Requisitos da vaga "Cientista de Dados Júnior" no PicPay

Requisitos da vaga "Cientista de dados" no Itaú

Requisitos da vaga "Cientista de dados" no iFood

Como você pode notar, não existe um padrão de divisão ou organização das habilidades, cada empresa escreve essas informações da maneira que lhe é mais interessante.

Além de buscar por um termo e uma cidade, você deve ir refinando a sua busca, às vezes você precisará trocar um termo por outro para obter resultados mais interessantes, por exemplo, experimente procurar Data Scientist ao invés de Cientista de Dados. Algumas empresas mesmo sendo Brasileiras colocam seus cargos e anúncios de vaga em Inglês, por isso, pequenos ajustes de termos, podem te trazer mais vagas interessantes.

Organizando os dados coletados

Agora que você já tem uma coleção de vagas, chegou a hora de arregaçar as mangas e colocar as informações num formato fácil de identificar nossa jornada de estudo.

Para isso eu criei uma planilha onde colei as descrições das seções de requisitos de cada vaga que achei interessante. Eu coloquei uma coluna para cada informação: Título da vaga, empresa de onde peguei a vaga, os requisitos, as habilidades que são consideradas um diferencial e por fim o link da vaga. E organizando assim fica mais fácil do que passear entre 10 abas no navegador 😉

Essa é a minha base de informações, mas concorda que ainda não está fácil de visualizar as as habilidades mais importantes? Então vamos estruturar nossos dados. Para isso eu criei uma nova aba na minha planilha e fui manualmente criando uma coluna para cada empresa e transformando o texto em uma lista de habilidades, por exemplo, a vaga da Stone abaixo:

Requisitos da vaga "Data Scientists (Conta Stone)" na Stone

Virou essa coluna na minha planilha:

Note que eu também incluí as “habilidades desejáveis”, aquelas que apresentam um diferencial para a vaga, provavelmente essa ferramentas já são parte do conjunto da empresa e você vai encontrá-las no seu dia-a-dia.

Depois de transformar a descrição das vagas num dado colunar eu recomendo que você padronize algumas entradas, por exemplo, eu coloquei todas as letras em minúsculo e troquei alguns termos, por exemplo “versionamento de código” e “github” viraram apenas “git”, isso vai deixar as suas informações mais fáceis de agregar.

Respondendo a Pergunta

Agora para contar tudo isso nós vamos fazer uma tabela dinâmica ou pivot table. Para facilitar a criação dessa tabela, eu colei numa nova aba da planilha todas as habilidades de cada das empresas em uma única coluna, que chamei de “Habilidades” e fiquei com uma coluna de 99 linhas com repetições, veja as últimas linhas da minha coluna resultante:

Tendo feito isso você conseguirá criar uma tabela que vai apresentar a frequência de cada habilidade ou ferramenta no nosso conjunto de vagas. Para criar uma tabela dinâmica no Google Sheets você deve selecionar “Tabela dinâmica” no menu “Dados”:

Ao clicar em tabela dinâmica vai aparecer a janelinha abaixo na sua planilha, onde você pode ajustar o intervalo de dados, no meu caso, eu estou escolhendo todas as linhas da coluna A da aba “Habilidades” para criar a minha tabela. Eu também selecionei “inserir em nova página” para criar a tabela numa nova aba da planilha e evitar a sobrescrita da minha resultante.

E ao clicar em “Criar”, como esperado, uma nova aba aparece:

Note que a nossa tabela ainda está em branco. Isso acontece porque nós precisamos configurar os dados a serem calculados. Então clique numa célula da tabela para que o menu de edição da tabela dinâmica apareça:

Agora a primeira coisa que vamos fazer vai ser adicionar os termos disponíveis na minha aba de Habilidades como entradas da tabela dinâmica, para isso clique no adicionar da seção “Linhas” e selecione “Habilidades”:

Com isso os termos na nossa lista aparecem na tabela já sem repetição.

Agora você precisa adicionar a frequência de aparecimento de cada termo. Para adionar a frequência clique em “Adicionar” na seção de “Valores”, e escolha mais uma vez “Habilidades”, e para ficar mais interessante selecione “% do total geral” no campo “Mostrar como”:

Para finalizar, seria bom ordenar as habilidades pela frequência em que aparecem, já que imaginamos que as habilidades e ferramentas mais utilizadas vão aparecer mais vezes, então para ordenar, volte para seção “Linhas” e no campo “Classificar por” você vai poder escolher a coluna que contém as frequências que se chama “COUNTA de Habilidades” e automaticamente a tabela se organiza:

Pronto! Agora você tem uma lista das habilidades que precisa desenvolver e ferramentas que precisa aprender!

De acordo com o nosso pequeno conjunto de dados de 10 vagas de empresas Brasileiras que contratam a cientistas de dados, essas são as 15 ferramentas que você precisa ter no no seu currículo.

Recapitulando

Saber tudo isso é uma garantia de emprego na área? Não, mas estudar as ferramentas que você encotrar usando este passo-a-passo vai te ajudar a construir um portfólio bem prático de habilidades que as empresas estão procurando em pessoas para as suas vaga.

Um outro ponto chave se você está mudando de área ou de empresa, é criar um espaço onde você demonstra as suas habilidades. A Lele Portella tem uma palestra incrível de como fazer isso disponível no YouTube da Python Brasil, e eu recomendo que você leia esse artigo sobre ter um blog também da Lele.

Vale salientar que o conjunto de vagas deste artigo é pequeno pois tem apenas o objetivo de ensinar a fazer esse levantamento de informações. Eu recomendo que você faça uma coleta maior de dados antes de tirar conclusões.

Como você deve ter notado, é um trabalho bem manual e que poderíamos automatizar grande parte dele, mas isso é assunto pra outro artigo 😜

Por fim, espero que este artigo possa te ajudar a escolher um norte para chegar até o seu próximo emprego. Se tiver dúvidas deixa ali na caixinha de comentários no final do artigo 😉

Universo Python

Tue, 24 Nov 2020 13:00:00 +0000

Um encontro com Thaíssa Candelalla, Bruno Rocha, João Gabriel e eu para falar de muito Python!

Projetos Brasileiros para fazer pull requests nesse #Hacktoberfest 2020

Thu, 01 Oct 2020 09:00:00 +0000

Edição atual da lista disponível aqui.

Depois dos sucessos das listas de 2017, de 2018 e de 2019, esse é o QUARTO ano que estou fazendo a lista/curadoria de projetos brasileiros para contribuir no #Hacktoberfest (esse ano invadido pela @anaschwendler!!!!)

Então aqui vai! Uma lista toda repleta de projetos pra você contribuir nesse mês de Outubro!

Novamente temos regrinhas:

Ser um projeto criado/desenvolvido/mantido por brasileiras(os);
Ter pelo menos uma issue aberta.

Avisos para 2020

2020 não está sendo um ano fácil pra ninguém, apenas contribua com o que pode! S2

Esse ano vamos manter a mesma forma de aumentar essa lista com mais projetos, como sempre, apenas abrindo um PR com o projeto. As instruções de como adicionar projetos tá aqui. Todo mundo segue apenas ganhando <3.

Os projetos continuam separados pela linguagem principal pra facilitar as buscas pra quem lê e também em ordem alfabética pela linguagem. 😉

ATUALIZAÇÃO IMPORTANTE:

"Acorda menina! Olha as novas regras! New Rules!" - Ana Maria Braga

Aqui as regras seguem as mesmas, porém a regra para tornar seu PR válido para a hacktoberfest mudou!!!11

PRs apenas contarão se:

O repositório onde o PR foi aberto tem um tópico chamado hacktoberfest

O PR foi aberto em Outubro
OU o PR é adicionado(merged) ao projeto OU está com o rótulo(label) hacktoberfest-accepted por um mantenedor OU o PR foi aprovado.

Mais informações no site oficial (em inglês)

Happy Hacking!

C#

C

CSS

Clojure

C++

Elixir

Go

JavaScript

Julia

Kotlin

PHP

Pearl

Python

Ruby

Scala

Shell

Swift

TypeScript

Variados

ADVPL

Trabalhando remoto

Thu, 26 Mar 2020 14:55:46 +0000

Eu já trabalhei remotamente e presencialmente durante anos e posso dizer que criar novos hábitos e deixar para trás os antigos é a parte mais difícil de qualquer processo de adaptação. Infelizmente períodos de crise, como a pandemia que estamos vivendo agora, pedem que façamos mais esforços para continuarmos sendo pessoas producentes na medida do possível.

Não vou te dizer que existe uma receita mágica para montar o seu home office e trabalhar no modo de fúria de todos os dias, mas existem processos que podem te ajudar a cada dia que passa se encontrar mais confortável numa rotina nova. Então vou compartilhar aqui as dicas que sigo e me ajudam a trabalhar remotamente.

Rotina

Essa palavra é a chave para um home office bem aproveitado. Principalmente para pessoas que trabalham fora de casa, é comum quando estão em casa quererem curtir o sofá ou cama largadonas de pijama. Esse hábito é o que te faz mais lenta e tira sua mente do foco, seja ele trabalhar ou estudar ou até praticar um instrumento.

Eu não sou uma dessas pessoas que acorda pulando de alegria pelas manhãs, mas tento seguir a regra de acordar, tomar café e sair do pijama. Esse formato de início de dia me ajuda a colocar o meu corpo e cérebro na mentalidade correta para o trabalho. Talvez pra você o ritual matutino seja um pouco diferente e tudo bem, faça o que você preferir desde que você consiga estabelecer uma rotina e lembrando sempre que novos hábitos não se criam da noite pro dia.

Divisão de espaços

Antigamente, quanto eu trabalhava e dormia no mesmo quarto, eu tinha uma mesa onde eu trabalhava e cama onde dormia, e essa divisão, somada a rotina de sair do pijama, era a minha divisão espacial entre trabalho e lazer.

Hoje eu tenho a sorte de morar num apartamento com dois quartos onde um deles é o escritório e o outro o quarto em que durmo. Essa mudança de espaço também ajuda a colocar o cérebro no lugar, por mais incrível que pareça, ter uma divisão de ambientes entre trabalho e lazer dentro de casa ajuda imensamente o seu corpo a se comportar como se estivesse no trabalho. Mesmo que você não tenha dois cômodos como é o meu caso, faça a divisão da melhor forma possível. E dica de ergonomia: evite trabalhar do sofá, isso vai prejudicar a sua coluna e o seu pescoço.

Ter essa separação também vai te ajudar a parar de trabalhar no fim do seu dia. Quando se vai ao escritório, é fácil encerrar o trabalho, basta sair do escritório e ir pra casa, mas quando se trabalha de casa essa separação é mais difícil então é importante definir os limites tanto de horários para começar a trabalhar quanto para terminar o seu dia.

Faça pausas

Para mim é bem comum esquecer do tempo e ficar horas grudada no computador ajustando ETL e disparando treinos de modelos, principalmente se eu estiver bem focada. No fim do dia, quando faço isso por muitas horas seguidas, eu me sinto exausta e sem energias para curtir o mozão ou a minha série do momento. Uma coisa que aprendi para ajudar nesse ponto e evitar a exaustão é me forçar a fazer pausas algumas vezes no dia.

Levantar para um xixi, tomar um café, comer um biscoito ou até mesmo tomar água. Se você estivesse no escritório já faria tudo isso e ainda conversaria com colegas, então lembre-se de praticar pausas no seu dia. Quem sabe até aproveite para tomar um banho rápido depois daquela longa e tensa reunião. Lembre-se, você está trabalhando e o objetivo é fazer o dia render, fazer pausas ajuda o cérebro a descansar e ainda a trabalhar no plano de fundo naquele bug que você está tentando resolver há horas.

Use e abuse de videoconferências

Sabemos que ter uma comunicação efetiva entre pessoas e times já é uma tarefa difícil normalmente mesmo estando todas as pessoas trabalhando ao mesmo tempo uma do ladinho das outras, agora imagina mover essa conversa para ferramentas de texto?

Uma coisa nesses anos notei é que temos, em geral, uma comunicação por texto muito mais falha do que quando conversamos pessoalmente. Não damos contexto do que estamos falando, escrevemos sem pensar, enviamos mensagens sem revisar o que escrevemos antes de enviar, lemos o que nos foi enviado com pouca atenção e assumimos um tom geralmente errado no que a pessoa escreveu.

Por isso, e especialmente nesse momento, é uma ótima oportunidade para usar as ferramentas de videoconferência que existem por aí. A maioria das empresas já possuem ferramentas padrão para isso, mas vou deixar aqui algumas dicas caso esse seja um mundo totalmente novo para você:

Zoom.us: Aplicativo de videoconferência, na versão gratuita suporta chamadas com mais de duas pessoas durante 40 minutos, na versão paga a duração das chamadas é ilimitada;
hangouts.google.com: aplicativo web de videoconferência do Google, basta ter uma conta do Google para gerar as salas de videoconferência e enviar o link de convite para qualquer pessoa com limitação de 10 participantes por chamada;
Whereby.com (antigo appear.in): aplicativo web de videoconferência você pode criar a sua própria sala e bloquear ou permitir a entrada de novas pessoas, limitado a 4 pessoas por chamada na versão gratuita;
Discordapp.com: aplicativo de conferência por voz, você pode criar o seu canal e permitir a entrada de quantas pessoas quiser, muito usado para jogos, consome pouca banda e não possui limitações de pessoas nos canais de voz.

Mas lembre-se de registrar o que foi conversado por texto para as demais pessoas interessadas. Nesses momentos de formalização de conversas eu tento seguir três passos:

Contexto: o que foi discutido e qual a necessidade dessa conversa;
O que foi decidido: vamos agir de forma A, B ou C;
Responsabilidades: o que eu vou fazer e o que outras pessoas vão fazer.

Assim fica claro o que foi conversado, e os papeis de todas as pessoas na conversa.

Elimine distrações

Sabemos que não está fácil esquecer tudo que está acontecendo a nossa volta e focar no trabalho. Muitos de nós estão trabalhando de casa, em lugares com cadeiras ruins, mesas pequenas, em ambientes não silenciosos, com nossos filhos e filhas confinados em espaços pequenos e tendo que cuidar de nossos familiares, essas condições são bem menos do que ideais para trabalhar. E apenas falar “elimine distrações” não é o suficiente para magicamente fazer todas essas coisas desaparecerem.

Nesse momento, é importante lembrar que você não precisa estar focada e rendendo durante todas as horas do dia, talvez você consiga terminar a sua tarefa em menos tempo do que imagina. Nesses dias, onde o foco está ruim, eu me apego no método Pomodoro, para tentar ter alguns momentos de foco. Esse método consiste em períodos curtos de trabalho focado com intervalos curtos pré-definidos e quando eu não consigo concentrar em nada, geralmente o Pomodoro me salva e eu consigo terminar o dia com a sensação de fiz algo mesmo que esse algo seja um Pomodoro.

Tempo “livre”

Agora você não tem mais que ir para o escritório e isso vai ter dar um tempinho “de sobra” no seu dia e para mim essa é uma das maiores vantagens de trabalhar remotamente. Então, se puder, aproveite esse tempo disponível para fazer coisas novas, esse é um período muito bom para tirar a poeira daquele violão que você comprou e nunca aprendeu a tocar, de terminar aquele projeto de tricô, brincar mais com seus filhos e filhas, de praticar yoga na sala, ou até mesmo de fazer nada e curtir um seriado. O importante é lembrar de ter tempo de lazer mesmo que seja limitado às paredes de casa.

Por fim lembre-se de manter a segurança, evitar aglomerações e lavar bem as mãos com frequência. Vamos tentar manter o mínimo de sanidade nessa época difícil… E se você estiver precisando de companhia pra um cafézinho virtual manda um alô pra mim ou pra aquela amiga ou amigo e tenta fazer uma videoconf. Seres humanos gostam de viver em sociedade, então vamos nos apoiar mesmo que à distância 😉

Dicas e leituras extras

PS.: se souber algum material legal em Português manda que eu adiciono aqui 🙂

Working remotely

Thu, 26 Mar 2020 14:50:00 +0000

I have worked remotely and allocated for years now, and I can say that creating new habits and leaving old ones behind is the most challenging part of any adaptation process. Unfortunately, in periods of crisis, such as the pandemic we are experiencing right now, it is essential to make more efforts to remain as productive as possible.

I am not going to tell you that there is a magic recipe for setting up your home office and working in your everyday-beast-mode, but there are processes that can help you find yourself more comfortable in a new routine with each passing day. So I’m going to share here the tips I follow and help me work remotely.

Routine

Routine is the key to a well-executed home office. Especially for people who work outside their homes, it is common when they are at home to want to enjoy the couch or bed in pajamas. This habit is what slows you down and takes your mind off focus, whether it’s working or studying or even practicing an instrument.

I am not one of those people who wake up joy-jumping in the mornings, but I try to follow the rule of waking up, drinking coffee, and getting out of my pajamas. This early-day format helps me put my body and brain in the right mindset for the job. Maybe for you, the morning ritual is a little different, and that’s okay. Do what you prefer as long as you can establish a routine and always remembering that new habits are not created overnight.

Separation of spaces

In the past, when I worked and slept in the same room, I had a table where I worked and a bed where I slept, and this distinction, added to the routine of getting out of my pajamas, was my spatial division between work and leisure.

Today I am fortunate to live in an apartment with two rooms where one is the office and the other in which I sleep. This change in physical space also helps to put the brain in the correct mindset, as incredible as it may seem, having a division of environments between work and leisure at home helps your body to behave as if you were at work. Even if you don’t have two rooms like me, make the distinction as best as possible. And ergonomics tip: avoid working from the couch, this will damage your spine and your neck.

Having this separation will also help you to stop working at the end of your day. When you go to the office, it is easy to finish work, just leave the office and go home, but when working from home, this separation is even more difficult, so it is vital to define the limits of both hours to start work and to finish your day.

Take breaks

For me, it is quite common to forget about the clock and stay glued to the computer for hours adjusting ETLs and triggering model training, especially if I am “in the zone”. When I work for many hours in a row, I feel exhausted and without the energy to anything else afterward. One thing I learned that helps avoid exhaustion is to force myself to take breaks a few times a day.

Get up to have a coffee, do a bathroom break, eat a cookie, or even drink water. If you were in the office, you would do all this and probably talk to colleagues, so remember to practice breaks in your day at home too. Maybe even take a quick shower after that long and tense meeting. Remember, you are working, and the goal is to make the day pay off, taking breaks helps your brain to rest and still work in the background on that bug that you have been trying to solve for hours.

Videoconferencing for the win

We know that having effective communication between different people and teams is already a difficult task when we are all working at the same time side by side, now imagine moving this conversation to text tools?

One thing I noticed is that in all of these working years, is that in general, text communication is much more flawed than when we talk in person. We do not give context regarding what we are talking about. We write without thinking, we send messages without reviewing what we write before sending, we read what was sent to us with little attention, and we usually assume a wrong tone in what the person wrote.

So, and especially at this moment, it is an excellent opportunity to use the videoconferencing tools out there. Most companies already have standard tools for this, but here are some tips if videoconferencing is a whole new world for you:

Zoom.us: Videoconferencing application, in the free version, supports calls with more than two people for 40 minutes, in the paid version the duration of calls is unlimited;
hangouts.google.com: Google’s video conferencing web application, all you need is a Google account to generate the video conference rooms and send the invitation link to anyone with a limit of 10 participants per call;
Whereby.com (formerly appear.in): videoconferencing web application, you can create your own room and block or allow the entry of new people, limited to 4 people per call in the free version;
Discordapp.com: voice conferencing application, you can create your channel and allow as many people as you want to join, widely used for games, consumes little bandwidth, and has no amount of people limitation on voice channels.

Afterward, remember to record what was spoken by text to other interested parties. In these moments of formalizing conversations, I try to follow three steps:

Context: what was discussed and the need for this conversation;
What was decided: we will act in A, B or C way;
Responsibilities: what I’m going to do and what other people are going to do.

This makes it clear what was talked about, and the roles of everyone in the conversation are.

Eliminate distractions

We know that it is not easy to forget everything that is happening around us and focus on work. Many of us are working from home, in places with bad chairs, small tables, in noisy environments, with our children confined in small spaces and having to take care of our family, these conditions are far less than ideal for work. And just saying “eliminate distractions” is not enough to magically make all those things disappear.

At this point, it is necessary to remember that you do not need to be focused and performing during all hours of the day, you may be able to finish your task in less time than you think. In those days, when focusing is not happening, I stick to the Pomodoro method, to try to have some moments of focus. This method consists of short periods of focused work with short predefined intervals. When I can’t concentrate on anything, generally, the Pomodoro saves me, and I manage to end the day with the feeling that I did something even if that something is one Pomodoro.

“Free time”

Now you don’t have to go to the office anymore. There’s no commute time anymore, and this will give you a little time to spare in your day, and for me, this is one of the most significant advantages of working remotely. So, if you can, take the time available to do new things. This is a perfect time to dust off that guitar that you bought and never learned to play, to finish that knitting project, to play more with your kids, to practice yoga in the living room, or maybe to do nothing and enjoy that recently launched series. The important thing here is to have relaxation time, even if it is limited to the walls of the house.

Finally, remember to keep safe, avoid crowds, and wash your hands frequently. Let’s try to maintain the minimum sanity in this challenging time, shall we? And if you need a company for a virtual coffee, send me a hello or that friend or friend and try to make a videoconference. Human beings like to live in society, so we let’s support each other even at a distance 😉

Extra tips and readings

Zapier’s Guide to working remotely, there’s a lot of material on this page;
Toggl: Free timekeeping tool with timer for Pomodoro included.

PS .: if you know some material about remote work not listed here, put it in the comments below. 🙂

Fixing date error while running jekyll on macOS Catalina

Tue, 25 Feb 2020 10:00:00 +0000

If you were following the “Publishing your own website with Jekyll” on macOS Catalina, after running bundle install and bundle exec jekyll serve you may have run into this error:

The solution is quite simple although it may not be trivial if it is your first time doing this. In this pro-tip, I’ll show you how to fix this error so you can continue blogging 😉

If you run into this error it probably means that the Jekyll version you are using on your project may be incompatible with the ruby version in your machine, to fix that we will need to upgrade your project’s jekyll version.

First things first, remove the vendor generated in the previous bundle install, remember to adjust your vendor path accordingly:

$ rm -rf vendor/

After that, you’ll need to remove your Gemfile.lock, this file locks the version of your gems, and it is automatically generated by bundle when you install your gems. Since we want to update Jekyll’s version, this file will get in the way forbidding us from installing a higher version. So just go ahead and remove it:

$ rm Gemfile.lock

Now go to your Gemfile and upgrade the version to the new one. Fresh was running on Jekyll version 3.4.3 as you can see here, the most recent Jekyll version available is 4.0.0. To update the version open the Gemfile on your favorite editor, find the line where Jekyll version is set and update the version value, it should look like this afterward:

gem "jekyll", "4.0.0"

Now all you have to do is reinstall everything and run the Jekyll server:

$ bundle install
$ bundle exec jekyll serve

And you should see something like this on your terminal:

And now you are good to go! Happy blogging 🎉

Quem tem medo de virar cientista de dados (3/3)

Wed, 29 Jan 2020 12:00:37 +0000

Esse texto é a parte final da trilogia “Quem tem medo de virar cientista de dados?”

"Preciso de experiência para conseguir um trabalho, preciso de trabalho para conseguir experiência. — Uma história sem fim" — tradução livre.

Depois de ler sobre a fase do “Será que eu vou conseguir?” e a fase do “Vale a pena mesmo começar a trabalhar numa área totalmente nova para mim?”, começa a cair a ficha de que não é apenas o currículo matador com formação exemplar que vai te ajudar a achar aquela vaga de Cientista de Dados que parece ter sido feita sob medida para você. Mas, ainda assim você precisa mostrar que tem competência para estar naquele cargo e confiança para encarar os desafios de cabeça erguida! A dúvida que abala até o mais confiante dos especialistas, é ainda pior para quem está mudando de área: o famoso caso de “Com tanta gente brilhante aplicando para vaga, com anos de experiência, por que diabos vão querer me contratar?”.

Para continuar lendo, clica nesse botão aqui em baixo 👇

Who do you think of when asked for a referral?

Wed, 18 Dec 2019 07:00:00 +0000

You know qualified women. Why not appoint them?

Author note: Leia este artigo em Português clicando aqui.

This article was originally posted in Portuguese at the Code Like a Girl blog linked above.

PyLadies at PythonBrasil \[12\]

I’ve given several lectures during 2017, and it has become common for people to call me to and invite me to lecture on other events, to be a hackathon mentor, to organize events, and other things in the like. Sometimes my schedule doesn’t allow me to accept the invitations as I would like, and then these people ask me the crucial question: Could you appoint someone we could invite?

And then, I find myself scrolling through my contact list to find people who can fit the event proposal. Most of the time, the people I indicate are close to me. And that’s fine. The problem comes when ALL the indications I want to make are men. And look, there are plenty of extremely qualified women on my contact list (and Telegram groups).

I hadn’t given a second thought about this matter for a long time, and maybe you too may not have thought about it. After reading a lot, watching videos, and talking to people about inclusiveness, sexism, and diversity, the penny finally dropped: It’s not enough to indicate a woman, it’s also necessary to show that she is the one that has to be there.

Source

In this video posted by Mic on their Facebook page, Karen Sandler talks about sexism in the tech industry. In addition to mentioning the situations women that are attending IT events often encounter, she reports how women find it hard to consider themselves experts in their fields of work. Including herself. She was named for being a patent expert for an interview for the documentary Patent Absurdity. Instead of accepting to being interviewed, she wanted to pass the opportunity to “people who were, in fact, experts.”

Realizing this problem we women face, because yes I also go through this, I started doing two things:

I only recommend men if I spend two days non-stop looking for a qualified woman to indicate and not finding one (rare but happens ¯\_(ツ)_/¯);
Talk to the women I mentioned and prepare them: I appointed you because you are the best choice for this.

I used to tell the nominee I had appointed her, and just like Karen Sandler did when she was supposed to be interviewed for the first time, my nominees always wanted to pass along the opportunity along. Saying they “weren’t an expert” or “still having a lot to learn” or “having people more qualified for the job.”

Helping women who want to play a prominent role goes beyond appointing them. It involves helping them realize that they must be on that stage or in front of that camera to show what they have to offer. Refer a woman and help her see how capable she is.

A ciência de dados pode salvar um país

Sat, 23 Nov 2019 13:11:42 +0000

Mas só se você levantar o bumbum do sofá e começar a fazer sua parte

Usualmente cientistas de dados querem resolver problemas ou responder perguntas. Seja para encontrar a cura do câncer ou para combater a corrupção, dados passam por uma sequência parecida de passos antes de se tornarem parte da solução.

A ideia desse texto é explicar mostrando um caso prático (e famosinho) do uso da ciência de dados. Então, se você já manja de ciência de dados e tá precisando de inspiração pra projetos de estimação, se prepare para aprender coisas novas que você pode não saber sobre leis e dados. Esse texto também é pra você que ainda tá aprendendo e quer conhecer a dinâmica de um projeto de ciência de dados.

Fonte

O domínio

O começo de toda investigação de dados é sempre entender o domínio. Conhecer as “regras” que regem os dados. Conhecer também o dado e como ele se apresenta, ajuda os cientistas a saber que perguntas podem ser respondidas e as melhores formas de obter respostas.

Art. 5o É dever do Estado garantir o direito de acesso à informação, que será franqueada, mediante procedimentos objetivos e ágeis, de forma transparente, clara e em linguagem de fácil compreensão.

Existe uma lei que define que todos órgãos públicos brasileiros devem disponibilizar seus dados desde que isso não interfira na segurança nacional (e outras regrinhas mais). Mas de um modo geral, a Lei de Acesso à Informação ou LAI como é conhecida, foi um marco para a disponibilização de dados da administração pública e aumento do controle social.

Foi essa lei que ajudou por exemplo, os dados da Cota para exercício da atividade parlamentar (CEAP) a serem disponibilizados. A CEAP, por sua vez, consiste em valor mensal que os nossos deputados dispõem para serem reembolsados com gastos com um conjunto de coisas como alimentação, hotel, combustível, locação de carro, passagem aérea e outras coisas.

O ato de mesa que define a que se destina a CEAP é o conjunto das regras do jogo, então como parte do processo de compreender bem o seu domínio de trabalho, o time da Operação Serenata de Amor (OSA), projeto de ciência de dados feito por brasileiros para encontrar gastos irregulares nos reembolsos dos deputados, leu todo o ato de mesa em busca de maiores informações sobre como a CEAP funciona. Saber todas essas informações ajudou a construir o que seria o domínio de trabalho da Serenata.

Hoje os dados da CEAP estão sendo disponibilizados em quatro formatos CSV, XML, XLSX e JSON, separados em subconjuntos de anos (você pode encontrá-los aqui). Cada reembolso homologado pela câmara dos deputados é disponibilizado nesse conjunto de dados. Unir esses dados com o conhecimento das regras foi o que permitiu ao time da OSA conseguir encontrar gastos considerados irregulares que foram reembolsados.

Ferramentas

Mas para ser efetivo na nossa busca por irregularidades, precisamos de ferramentas. Uma das premissas da ciência é a reprodutibilidade e no caso da Serenata não é diferente, mas além disso, por se tratar de um projeto sobre accountability e também de auditoria das contas públicas, disponibilizar de forma amigável e transparente nossos achados foi um ponto importantíssimo.

Dessa forma, apenas colocar código no GitHub não era o suficiente e aí que entra nossa primeira ferramenta: Jupyter Notebooks. Com a possibilidade de misturar código e texto, os notebooks se tornam o perfeito caderno de laboratório. O GitHub, por sua vez, renderiza nossos queridos notebooks facilitando ainda mais o nosso trabalho de mostrar pro mundo todos testes de hipótese, todas análises exploratórias e todos treinamentos iniciais de modelos de machine learning.

Mas ainda precisamos de mais uma ferramenta para ajudar a preencher as páginas dos nossos notebooks, uma linguagem de programação e, nesse caso, a escolhida foi Python. Com uma comunidade cada dia maior, o Python científico vem sendo amplamente utilizado pelo mundo para ciência de dados, ela é também uma linguagem com uma baixa curva de aprendizado o que ajuda ainda mais na ideia de expor os achados.

Então, foi assim que o nosso time multidisciplinar escolheu as duas ferramentas principais de trabalho. Com o Jupyter nosso jornalista Pedro conseguia acompanhar o que time técnico estava fazendo e onde queríamos chegar. E não só ele, outras tantas pessoas interessadas em entender o que estávamos construindo, mas não possuíam o conhecimento técnico, também podiam ficar de olho no nosso trabalho.

Investigações preliminares

No dia 8 de setembro, um dia após o lançamento oficial do projeto, o Irio Musskopf escreveu num blog post para explicar a que se destinava a Operação:

Em pouco tempo, trabalhando em horas vagas … descobrimos mais de 20 casos no mínimo interessantes … tudo é aberto, tanto código quanto dados.

Todos esses achados começaram com análises exploratórias dos dados liberados pela CEAP e alguns cruzamentos iniciais feitos no início do projeto. É aqui que começa de fato a primeira parte de manipulação de dados.

Fonte

Lembra que eu falei que era importante entender os dados? Pois bem, essas análises iniciais ajudam a sedimentar o conhecimento do domínio, mas além disso, essas análises ajudam a mostrar caminhos possíveis de análise. Por exemplo, foi a partir dessas análises que hipóteses como “Velocidade viajada suspeita” e “Gasto com bebidas alcoólicas” surgiram.

Por exemplo, vocês sabiam que em 2015 um deputado pagou com dinheiro público algumas contas da sua própria campanha? Ou que em 2014 um deputado tomou uma cervejinha em Las Vegas, no restaurante do Gordon Ramsey, e colocou a cerveja na nossa conta? Ou ainda que em 2013 um deputado foi ressarcido depois de alugar um carro em uma empresa que, na verdade, era uma padaria? Isso sem falar que em 2011 um deputado almoçou 13 vezes no mesmo dia, pagando cada uma dessas refeições com dinheiro daquele mesmo bolso… o nosso.

Contou Eduardo Cuducos em um outro post sobre o projeto.

Limpeza

Além de ajudar a levantar hipóteses e conhecer os seus dados, as análises iniciais também vão servir para mostrar limpezas necessárias. Na maioria das vezes os dados não vem prontinhos, esse papel de preparação de dados, cai na aba do chapéu de engenharia de dados, e com um nome recente essa engenharia ainda está sendo descoberta pelas empresas. Então, cabe ao cientista muitas vezes trocar de chapéu para também preparar o dado para análise.

A limpeza não busca remover dados do dataset inicial, mas sim organizar os dados para melhorar o acesso aos mesmos, já ouviu falar em “tidy data”? O conceito se baseia no fato que um dado organizado facilita imensamente as análises a serem feitas e implementações de modelos.

No caso da Serenata, nosso dataset já era bem organizado, no entanto algumas melhorias estavam no pedido do dia. Para começar, apesar da CEAP ser idealizada para reembolsos, algumas vezes gastos como compra de passagens podem ser feitos diretamente pela Câmara dos Deputados ao invés do(a) deputado(a) fazer o gasto e pedir o reembolso. Esses gastos precisam ser identificados para que possa ocorrer a contabilidade correta deles.

Além disso, um gasto não precisa ser reembolsado numa parcela única, o que gera mais de um registro para o mesmo recibo, essas parcelas então precisam ser agregadas.

Por fim, com o objetivo de participar do movimento global que promove o aumento da accountability governamental, ficou decidido que todo o código do projeto, assim como análises e demais documentos técnicos iriam ser feitos em inglês. Isso fez com que ainda precisássemos incluir um passo de tradução dos dados para o inglês para que eles pudessem fazer sentindo para quem não fala português também.

Enriquecimento

Depois de limpar e organizar os dados, chegou a hora de torna-los ricos. A limpeza muitas vezes não é o suficiente para que possamos extrair informações interessantes dos dados.

Os dados da CEAP só trazem as informações dos reembolsos. Qualquer coisa além disso que você encontra hoje no serenata, foi fruto de um processo de enriquecimento.

A fase de enriquecimento funciona como injetar esteroides no seus dados. O objetivo é trazer informações extras para nosso conjunto de dados de trabalho e assim, agregar mais valor as análises e melhorar as decisões a serem tomadas.

Cada reembolso traz o CNPJ da empresa que emitiu a nota que foi reembolsada no escopo da CEAP. Sabendo disso, um dos primeiros enriquecimentos que pensamos em Serenata foi trazer os dados das empresas para o nosso conjunto de trabalho.

Dados sobre as empresas incluem informações como endereço e o quadro societário delas, ter à mão esses dados permite que façamos investigações sobre possíveis casos de nepotismo e investigar se pessoas estavam “em dois lugares ao mesmo tempo”.

Embora seja possível encontrar o endereço principal das empresas no conjunto dos dados liberados pela receita, lidar com endereços dentro do código leva a mais um passo de enriquecimento, já que é mais fácil calcular distâncias com latitude e longitude do que endereços como “Rua dos Bobos, n 0”. Foi aí, que com ajuda da API de Geocodificação do Google, conseguimos trazer a informação de latitude e longitude que alimenta nossos classificadores.

Teste de hipótese

Não basta ter dados, eles serem limpos e ricos, é preciso levantar hipóteses e validá-las. E é como dizem, uma hipótese validada vale mais que mil palavras… tá, o ditado não é bem esse, mas o processo de validar (ou não) as hipóteses pinta a imagem.

É importante lembrar que um dos muitos diferenciais da Serenata é que este foi um projeto feito num período de tempo bem curto se comparado com o tempo gasto em projetos mais “tradicionais”:

Nenhum projeto de data science é feito para durar apenas três meses. Existe um longo processo de análise de dados e estudo de métodos até ser desenvolvido algo concreto. Entretanto, como queríamos fazer o projeto acontecer, usamos nossos conhecimentos em métodos agéis (adquiridos com nossa experiência de desenvolvimento) e descobrimos que a melhor forma de adaptar o tempo que tínhamos era utilizando HDD (hyphothesis-driven development) junto a técnica timeboxing. Ou seja, eram levantadas hipóteses para serem desenvolvidas em um espaço de tempo pré-determinado.

Explicou Ana Schwendler num post sobre a validação de hipóteses da Serenata.

Depois das análises iniciais surgiram as hipóteses a serem estudadas e validadas, importante lembrar aqui, embora cientistas tenham uma forte indicação de hipóteses válidas com base em suas análises inicias, isso não quer dizer que as hipóteses sempre serão válidas, certo? Ter isso em mente sempre ao trabalhar com dados é importante pois os dados podem provar que estamos errados. É importante ser humilde e reconhecer isso ao invés de manipular os dados para que eles mostrem o que queremos.

Eu, robô

Finalmente depois de todo esse processo, depois de passar pela limpeza e enriquecimento dos dados, depois de encontrar as hipóteses válidas finalmente chegamos na parte que era o objetivo principal do projeto: uma inteligência artificial, a Rosie.

Ela basicamente condensa e automatiza todo esse processo de pegar os reembolsos e ver se eles se enquadram na definição de um gasto suspeito ou não.

Mas para isso acontecer a gente precisa estruturar todas as análises que foram feitas nos notebooks num formato mais estruturado e é aí que entra o scikit-learn, ou pelo menos o padrão que eles seguem 😄

No caso da Rosie, o que fazemos é transformar todo o passo a passo feito no notebook para a mesma estrutura que o scikit segue: implementando os métodos fit, predicte transform e, quando necessário, métodos auxiliares de acordo com a necessidade. A Ana Schwendler falou dessa parte mais técnica de como a Rosie usa aprendizado de máquina aqui nesse post.

Mas não é só isso, a Rosie também tem uma conta no Twitter, veja o que a Jout Jout fala sobre ela:

Video da JoutJout sobre política onde ela apresenta um montão de ferramentas para acompanhar o trabalho dos nossos políticos

Até a Rosie existir (e tuitar) muito dos nossos achados ficavam “presos” à pessoas que já estavam interessadas no assunto como jornalistas e pessoas que trabalham com dados abertos. Mas ao chegar no Twitter, a Rosie popularizou os achados que antes estavam nas mãos de poucos.

E aí? Bora salvar o mundo? Eu já coloquei minhas braçadeiras!

Fonte

Um xêro!

Estou usando um CMS e você deveria usar um também!

Sun, 06 Oct 2019 03:00:00 +0000

Essa colinha é mais um dica pra você que tem um site estático ou que está querendo migrar seu blog de ferramentas como medium.

Há alguns meses eu descobri um negócio chamado CMS, a sigla para Content Management System (sistema de gerenciamento de conteúdo em português), era algo que eu estava procurando a muito tempo e não sabia.

Vamos lá, se você já me conhece sabe que eu passei um tempo postando coisas no medium.com e hoje só faço isso quando estou escrevendo para publicações como a do Code Like a Girl, Data Bootcamp ou para a revista do Pizza de Dados. Fora esses casos que envolvem publicações, meus artigos, tutoriais e colinhas sempre estão em blogs estáticos como esse aqui que você está acessando.

Eu até ensinei como colocar sites no ar usando o GitHub Pages e o Jekyll nesse tutorial. Mas confesso que, se como eu, você não está perto do seu computador 100% das vezes que começa a escrever um novo artigo, visualizar seu site pode ser complicado. Quando não estou no computador, acabo editando muitos dos meus textos no tablet ou no celular e, por mais que eu adore editores de texto simples, ainda não dá pra fazer build de site estático pelo Android ou iOS.

E aí que entra o Forestry. É uma ferramenta para te ajudar a transpor essas barreiras mais técnicas. Então vamos ver isso com calma.

Problemas de hoje

Como falei existem uma série de fatores que atrapalham a publicação de novos artigos quando se tem um blog como o meu: um site estático, baseado em Markdown e que está hospedado no GitHub.

Escrever textos em Markdown

Eu passei muito tempo procurando um aplicativo que tivesse o mínimo de funcionalidades para escrever textos em markdown que tivesse duas features principais:

visualização desses textos num formato bonitinho como o pré-visualizar do GitHub por exemplo;
e, sincronização desses textos com algum serviço de nuvem para que eu pudesse acessar eles de qualquer lugar independentemente se estivesse com o aplicativo perto de mim ou não.

Até agora eu não encontrei um aplicativo gratuito para isso. E considerando que eu gosto de rascunhar meus textos no celular e tablet, a falta de uma ferramenta com essas características é bem limitante.

Pré-visualização do site

Quando estou escrevendo no meu computador eu já tenho os processos prontos, eu consigo escrever os artigos num editor de texto como o Remarkable direto na pasta do meu site e fazer um build do site na minha máquina para ver como ficará o artigo quando for publicado. No entanto, qualquer outro dispositivo que eu esteja usando como meu celular, torna impossível a tarefa de pré-visualização do site já que não tenho um ambiente de desenvolvimento nesse dispositivo.

Com as configurações que eu tinha até então, eu também não tinha um ambiente de staging, se você não sabe o que é isso, imagine que você tenha uma cópia do seu site no ar, essa cópia é separada do site real e serve para você fazer testes de alterações no seu site, desde alterações estruturais como mudanças de tema, até mesmo como um ambiente onde você pode ter uma pré-visualização online do seus artigos.

A falta do ambiente de staging me causa um trabalho a mais frequentemente. Depois de prontos, eu geralmente mando meus textos para amigos e amigas revisarem, para fazer isso eu acabo usando ferramentas de compartilhamento de documentos como o Google Drive ou até mesmo o medium com o texto em formato de rascunho o que não é ruim, mas é um passo a mais que inclui colocar o texto em mais uma plataforma para que possa ser visto.

Colocar novos textos no GitHub

Além de uma dificuldade em pré-visualizar e também de compartilhar rascunhos. Por fim, chega a pior de todas: fazer commits pelo celular. Embora eu já tenha feito isso, é uma experiência bem desagradável, o que por sua vez me impede de publicar novos textos se eu só tiver acesso ao meu celular. Entende o dilema?

Como o Forestry resolve tudo isso

Longe de ser uma bala de prata, a plataforma oferece um editor de textos amigável que mostra as formatações básicas elementares como títulos, hyperlinks, itálico e afins. Ainda te permite criar listas, inserir blocos de códigos e imagens no seu texto. É amigável para pequenas telas e aceita colar textos com formatação então, eu consigo escrever meus textos offline em um aplicativo de notas e depois criar o arquivo pelo navegador do próprio celular, da mesma forma ainda é possível publicar o texto depois de pronto.

O Forestry também te dá um ambiente de staging tornando possível fazer a pré-visualização dos textos em tempo real. Você consegue configurar a ferramenta para fazer o build do site com os textos em rascunho e também fazer a pré-visualização de cada texto individualmente.

Uma funcionalidade que eu uso bastante é a criação de templates para os tipos de artigo, onde você pode definir os campos do front-matter de cada tipo de texto que você normalmente escreve e assim evitar retrabalho. Essa funcionalidade me ajuda definindo campos obrigatórios como Título e subtítulo, dessa forma, eu não esqueço de nada importante e também definindo valores padrão para cada campo, como por exemplo a capa do artigo.

A funcionalidade de templates foi particularmente útil para criar os arquivos dos projetos da lista de hacktoberfest. Eu criei um template com os campos que precisava preencher de cada projeto e era só uma questão de copiar e colar cada informação no campo correspondente e salvar o arquivo.

Por fim, a propaganda do Forestry é que nem você nem sua equipe precisam saber fazer commits ou saber como funciona o git para gerenciar o conteúdo de um blog ou site. Isso mesmo, os commits acontecem atrás da ferramenta então, você pode desapegar das questões de desenvolvimento de focar em escrever. E sim, é possível ter equipes de até 4 pessoas para cada site, permitindo que pequenos times trabalhem colaborativamente num seu site.

Nem tudo são flores

Apesar de resolver meus problemas e me dar um lugar legal para trabalhar nos meus artigos, o Forestry ainda é uma ferramenta nova e em constante desenvolvimento. Por isso, algumas funcionalidades ainda possuem espaços para melhorias. Por exemplo, se você usa collections no Jekyll pode ter dificuldades de visualizar novas adições às suas coleções sem antes reiniciar o servidor de pré-visualizações.

Fazer a integração com um site já existente pode ser um pouco assustador principalmente se você nunca se aventurou com algo similar antes. Todas as documentações são em inglês e o editor de texto não possui suporte a alguns tipos de arquivos como por exemplo .scss. Eu descobri isso pedindo ajuda ao suporte já que a plataforma não importava esses arquivos e não aparecia um notificação clara do motivo.

Concluindo

Se você gosta de escrever em sites como o medium.com ou tem costume de usar algo como o wordpress e quer sair dessas plataformas, unir um gerador de sites estáticos como o Jekyll ou Hugo (as opções vão muito além dessas), com uma plataforma como Forestry pode ser o caminho mais suave para fazer essa transição.

Espero que esse relato te ajude a melhorar sua experiência de escrever.

Adicionando um novo projeto na lista da #Hacktoberfest

Sun, 29 Sep 2019 11:00:00 +0000

Nota da autora: As instruções a seguir foram criadas em 2019, mas a forma de atualizar a lista de projetos se manteve desde então. Então mesmo que você queira atualizar a lista desse ano os passos são os mesmos 😉

Vale salientar que esse ano a lista agora tem uma pasta dedicada chamada _hacktoberfest_projects_2025/. O blog post foi atualizado para usar a nova pasta.

A lista de projetos brasileiros para contribuir nesse Hacktoberfest de 2025 é gerada automaticamente usando algumas mágicas do Liquid . Então, vamos ver como podemos adicionar um novo projeto nessa lista por meio de um pull request?

É hora do show!

Materiais

Um navegador (eu vou usar o Firefox, mas você pode usar o que preferir);
Uma conta no GitHub;
Disposição.

Nota da autora: existem inúmeras formas de fazer esse pull request (PR), aqui eu vou ensinar um formato usando o navegador para que você possa fazer sua contribuição mesmo que você não tenha conhecimentos profundos de git. Se você já tem prática em contribuir com projetos no GitHub, pula direto para essa seção que tem uma lista de passos menos detalhada do PR que deve ser o suficiente pra você fazer a sua contribuição.

Abrindo o repositório do PR

Pra começar abra o repositório desse site aqui numa página do seu navegador.

Imagem mostrando o repositório deste site

Copiando o template

No repositório desse site, que você acabou de abrir, navegue até a pasta .github/ e copie o conteúdo do arquivo repo-owner+repo-name.md (eu recomendo que você use o modo Raw do arquivo para fazer essa cópia). Veja o gif a seguir com esse processo:

Esse arquivo é o template de informações necessárias para mostrar corretamente um projeto na lista.

Onde moram os projetos

Ainda no repositório desse site, vá até a pasta _hacktoberfest_projects_2025/, lá é onde moram os dados de todos os projetos que estão sendo mostrados na lista de 2025.

Na pasta _hacktoberfest_projects_2025/ temos muitas pastas, elas existem apenas por questões organizacionais, cada pasta tem o nome de uma linguagem, e o projeto que você quer adicionar deve ser acrescentado na pasta correspondente à linguagem principal do projeto.

Escolhendo um projeto para adicionar

Agora, numa nova página, abra o repositório que você quer adicionar na lista. Aqui vamos usar de exemplo o Guia do Cientista de Dados das Galáxias (Guia).

Imagem mostrando o repositório Guia do Cientista de Dados das Galáxias

Criando um arquivo para o projeto

O Guia é um projeto agnóstico de linguagem, afinal é apenas um grande conjunto de arquivos em markdown, sendo assim, vamos criar o arquivo do Guia na pasta Variados. Novamente na página do site, navegue até pasta _hacktoberfest_projects_2025/ e em seguida entre na pasta Variados. Para criar o arquivo clique em Create new file, em seguida cole o conteúdo que copiamos do arquivo repo-owner+repo-name.md no espaço de conteúdo, dê o nome do arquivo seguindo o padrão <nome-do-dono-do-repo>+<nome-nome-do-repo>.md.

Preenchendo as informações

Agora você pode preencher os dados do projeto no nosso arquivo, só precisamos de quatro informções:

O link do repositório (campo repo);
O link pra imagem de perfil da pessoa dona do repositório (campo image);
A descrição do repositório (campo description);
E a linguagem principal do repositório (campo principal_language).

Para tudo isso basta copiar essas informações na página do repositório e colar na linha de campo correspondente no nosso arquivo.

Abrindo o PR

Depois de preencher todos os campos necessários presentes no nosso arquivo, basta abrir o PR. Então apenas desça até a área de detalhes do commit, escreva uma mensagem descrevendo qual projeto você está adicionando, clique em Propose new file e siga para propor o PR clicando em Create Pull Request.

Possíveis problemas

Existem principalmente dois casos em que esse fluxo que eu descrevi até agora vai precisar de ajustes, mas não precisa se desesperar, eu explico eles abaixo.

Caso 1: quero adicionar uma linguagem nova

Caso o projeto que você queira adicionar na lista tenha uma linguagem principal diferente daquelas já disponíveis, você deverá criar uma nova pasta. Para fazer isso pela interface do GitHub no navegador, basta você escrever o nome da pasta no campo onde escrevemos o nome do arquivo seguido de uma barra (/), ao digitar a barra, o GitHub se encarregará de criar a pasta, veja:

No gif, eu crio a pasta chamada pasta2 e dentro dela crio o arquivo chamado meu-arquivo.md.

Caso 2: o projeto que eu quero adicionar não tem descrição

Nesse caso é mais fácil de resolver, basta colocar no campo description o conteudo No description assim como coloquei nesse projeto aqui:

Revisão dos passos

Então pra aquela galera que só precisa de uma explicação mais concisa aqui vai! São só três passos!

Crie um arquivo na pasta correspondente à linguagem principal do projeto que você quer adicionar, use o template disponível aqui e não se esqueça de nomear o arquivo seguindo a convenção <nome-perfil>+<nome-nome-do-repo>.md;
Preencha os campos com as informações do projeto que você quer adicionar;
Abra o PR.

Aguarde a revisão e aprovação!

Se você quiser fazer um PR e não tem projeto em mente, dá uma olhada nessa lista aqui.

From 0 to 17 thousand pageviews

Fri, 27 Sep 2019 13:00:00 +0000

Author note: Você pode ler este artigo em Português.

The first website I got online was a Django based one. It was on a workshop of the academic week of my undergraduate course Biomedical Informatics taught by Ribeirão Preto’s Python community. It was the first time I saw how to use Python, and it was my first deploy ever, with Heroku and all, but this is a story for another time.

Since then, my development skills have evolved. I’ve learned about new technologies, learned to contribute avidly to open-source. I can say that, overall, I’ve improved as a developer.

Between the first site I launched, and today, I learned a lot, and among the knowledge I acquired, I learned alternative ways to publish sites. Among all the methods I know how to publish sites, my favorite way to get websites up and running is using GitHub Pages. I even wrote a tutorial on this method (in Portuguese) to help anyone who knows GitHub and a little bit of git have a website online without fuss.

My site, my rules

The first version of jtemporal.com was never structured to be a blog, despite having a blog session where I wrote about technical content. Think of my site as a kind of online notepad, I wrote about techniques I was studying or applying at work. This little detail had a significant impact on access to the content I posted. When I decided to put this site up, I chose a theme by following these rules:

Cannot be a single page;
It cannot be primarily a blog;
It has to be beautiful and mobile-friendly.

After some hard searching, I found my first theme: Moon. It had all the features that I wanted. Cute, with some cool animations, wasn’t primarily a blog, although, as I said earlier, it had a space for blogging. It wasn’t single page, I don’t know why, but I don’t like single page sites ¯\_(ツ)_/¯. Moon met all my needs.

I liked, and still really like Moon. I find it a well-built theme, and during the first two years of having a website and a place to put my texts, I considerably increased the number of articles I wrote.

I developed a skill and discovered a willingness to write about technical content that I didn’t know I had, after all, I never wanted to be a writer, writing was never my forte at school and despite being an applied student and trying hard to write decent texts when necessary, didn’t find it easy.

Source

During the two years that I had Moon as my theme, I wrote a lot, studied further, and learned many new things. One of those things was how to place a tag to track hits on a site using Google Analytics. If you’ve never heard of Google Analytics, that’s fine, for now, just knowing it’s a Google toolkit to track how your customers interact with web solutions. One of the things you can do is follow the behavior of those who use your site. After starting to follow ups and downs in pageviews, I watched my site get nearly 8,000 hits in a month. And that’s ok. I didn’t expect to have 8 hits would guess the 8,000 😂

Image showing the number of website hits in October 2018

Writing became routine and part of my learning process. Then, during late 2018, I realized that my needs and focus for my site changed: instead of being a place I used as a notebook for the things I wrote, it became a place where I like to share content. Writing became my new usual.

New rules, a new site

Just as writing became part of my daily life, my site finally needed to change, after all, part of the rules that made me choose the first theme was no longer what I required. I needed a theme that focused on content.

Then I set off in search of a new theme. You may have noticed, but the tendency content-focused sites are to have card format, dev.to is like this, Medium is like that too, and so on. Naturally, when looking for a new theme, I found one with cards. The new chosen one was Cards by Webjeda. I liked the theme, although I could see some points that needed modifications to make it the way I wanted. With the new theme at hand, at the beginning of 2019, I made the transition between Moon and Cards.

Cards, cards everywhere

Because both themes are Jekyll, based on markdown, and both have the same pattern for creating paths for posts, the transition went smoothly. I also created the covers for each type of article to make the job easier; after all, I didn’t want to use random images, so I standardized the images to match the type of article.

Some of the covers I made for the articles

Finally, the time has come to put the new face of the site online. This step was also straightforward since my configuration is simple, changing the name of the repository on GitHub, and configuring the domain did the trick. New site on the air!

After changing the theme, as a data addict, I continued to watch my analytics closely, a month passed by, and I finally realized I forgot to put the tracking tag on the new site hehe.

Source

After realizing that I was missing the tag and correcting this small mistake, we returned to the usual programmation of analytics watching. And in August 2019, I broke a record! I reached more than 17,000 hits!

Image showing amount of site hits in August 2019

Of course, it wasn’t just the change of theme that led to the growth in site hits. The increase in articles on various subjects, the growth of the Pizza de Dados, the podcast I founded with my friends, and the improved SEO tags on the theme itself, may have contributed to the increase in hits.

However, this is the first time my site is a blog, where the first thing you see upon opening the page is my posts, they also have cover images, a missing detail in the previous theme. SEO is currently doing better on the theme itself, but Moon had a much more complete SEO (more tags implemented), which leads me to believe that the site format is, in fact, the most significant factor here. To be statistically sure of this feeling, I should have done some A/B testing for every change. But, I didn’t, so there is learning for the next change.

A reflection on this process

Going through this process of changing focus is normal. As needs change, so do the technology. And it is delicious to identify changes and have room for change to occur. In my case, this transformation happened gradually. I went from someone who had no interest in writing anything to someone who continually posts. I wrote on paid platforms and switched to free platforms looking to spread content without prohibitions caused by paywalls. My site has gone from being an online notepad to officially becoming a blog.

And it was good to see the growth over these 3 years:

Image showing the number of hits to the site between December 2016 and September 2019. You can see the valley caused by forgetting the analytics _tag_ there between January and June of 2019.

I do not believe that these numbers can be used to measure people, yet I consider this evolution to be a visible picture of the same changes I have experienced over the years, an evolution composed of ups and downs. And then finally arriving at a reward. Gosh, 17 thousand pageviews! Who would’ve guessed it?

Take away points

So let’s recap the learning points:

Choosing a theme that focuses on what you want to present makes all the difference in the interaction between users and your content;
If you like to keep track of what happens on your site don’t forget the analytics tag ;
If you have a website, learn a little SEO and if you use a plugin to assemble the SEO tags, learn how it works;
If you want to be statistically sure of the impact a change has on your site, do A/B testing.

De 0 a 17 mil pageviews

Fri, 27 Sep 2019 13:00:00 +0000

O primeiro website que eu coloquei no ar, era um site Django. Foi num tutorial da semana acadêmica do meu curso de graduação (Informática Biomédica) e foi ministrado pela comunidade Python de Ribeirão Preto. Foi a primeira vez que vi Python sendo usado de verdade e foi o meu primeiro deploy com direito a Heroku e tudo, mas esse causo fica pra outro momento.

Desde então, minhas habilidades de desenvolvimento evoluíram, eu conheci novas tecnologias, aprendi a contribuir avidamente com open-source dá pra dizer que, de um modo geral, melhorei como desenvolvedora.

Entre o primeiro site que coloquei no ar e hoje, aprendi muitas coisas, e, entre elas, conheci formas alternativas de publicar sites. Sendo que de todas formas que aprendi até hoje, a minha forma favorita de colocar sites no ar é usando o GitHub Pages. Inclusive, eu até escrevi um tutorial sobre essa forma de colocar sites no ar com intuito de ajudar qualquer pessoa conheça GitHub e um tiquinho de git a ter um site.

Meu site, minhas regras

A primeira versão do jtemporal.com nunca foi estruturada para ser um blog, apesar de ter uma sessão para artigos e ser lá onde escrevia sobre conteúdos técnicos. Pense que meu site era uma espécie de bloco de notas público, eu escrevia sobre coisas que estudava ou estava aplicando no trabalho. Esse pequeno detalhe teve um impacto gigante no acesso aos conteúdos que publiquei. Quando eu decidi colocar o esse site no ar, escolhi um tema seguindo as seguintes regras:

Não pode ser single page (página única);
Não pode ser primariamente um blog;
Tem que ser bonito e amigável para plataformas mobile.

Depois de procurar bastante achei o meu primeiro tema: o Moon. Era exatamente o que eu queria. Bonitinho, com umas animações legais, não era primariamente um blog, apesar de como disse anteriormente, ter um espaço para isso. Não era single page, não sei o motivo, mas não gosto de sites single page ¯\_(ツ)_/¯. O Moon supria todas minhas necessidades.

Eu gostei, e ainda gosto muito do Moon. Acho ele um tema bem feito e, durante os dois primeiros anos tendo um site e um lugar para colocar meus textos, eu aumentei consideravelmente a quantidade de artigos que escrevia.

Eu desenvolvi uma habilidade e descobri uma vontade de escrever sobre conteúdos técnicos que eu não sabia que tinha, afinal de contas eu nunca quis ser escritora, redação nunca foi meu forte na escola e, apesar de ser uma aluna aplicada e me esforçar bastante para escrever textos descentes quando necessário, não achava aquilo ali fácil.

Fonte

Bem, durante esses dois anos escrevi bastante, estudei mais ainda e aprendi inúmeras coisas. Uma dessas coisas foi como colocar uma tag para acompanhar os acessos ao meu site usando o Google Analytics. Se você nunca ouviu falar de Google Analytics, tudo bem, por agora basta saber que é um conjunto de ferramentas do Google para acompanhar como seus clientes fazem nas soluções web. E uma das coisas que dá pra fazer justamente é acompanhar o comportamento de quem usa o seu site. Depois de começar a seguir altos e baixos em acessos, assisti meu site ter cerca de 8 mil acessos no mês. E tudo bem… eu não esperava ter nem 8 acessos que dirá 8 mil 😂

Imagem mostrando a quantidade de acessos ao site em Outubro de 2018

Escrever se tornou algo normal e parte do meu processo de aprendizado. Então, durante o fim de 2018, percebi que minhas necessidades e foco para o meu site mudaram: ao invés de ser um lugar que eu usava como bloco de notas para as coisas que eu escrevia, se tornou um lugar onde eu gosto de compartilhar conteúdo. Escrever se tornou meu novo normal.

Novas regras, novo site

Assim como escrever passou fazer parte do meu dia a dia, meu site precisava finalmente passar por uma mudança, afinal de contas, parte das regras que me fizeram escolher o primeiro tema já não valiam mais. Eu precisava de um tema que o foco fosse o conteúdo.

Então parti em busca de um novo tema. Não sei se você já reparou, mas existe uma tendência de sites onde o foco é conteúdo terem formato de cartão, o dev.to é assim, o Medium é assim também e por aí vai… Nada mais natural que, ao procurar um tema, eu encontrasse um em formato de cartões. O escolhido da vez foi o Cards por Webjeda . Eu gostei do tema apesar de enxergar alguns pontos que precisavam de alteração pra deixar ele do jeito que eu queria. Com o novo tema escolhido, no começo desse 2019 fiz a transição entre o Moon e o Cards.

Cartões pra lá, cartões pra cá

Como ambos temas são Jekyll, baseados em markdown e como o mesmo padrão de criação de caminho para as postagens, a transição foi suave. Praticamente uma questão de copiar e colar os artigos de uma pasta para a outra. Também criei as artes para cada tipo de artigo para facilitar o trabalho, afinal não queria usar imagens aleatórias, por isso padronizei as imagens para corresponder ao tipo de artigo.

Algumas das capas que fiz para os artigos

Por fim, chegou a hora de colocar o site no ar. Esse passo também foi bem tranquilo já que a minha configuração é simples, bastava trocar no nome do repositório no GitHub, configurar o domínio e pow! Site novo no ar!

Depois de trocar de tema, como uma pessoa viciada em dados, eu continuei a assistir meu analytics de perto, isso é… menos no mês que esqueci de colocar a tag de rastreamento no site novo hehe

Fonte

Depois de perceber que estava sem a tag e corrigir esse pequeno erro, voltamos à programação normal de assistir o analytics. E no mês de Agosto bati um recorde! Cheguei a mais de 17mil acessos!

Imagem mostrando a quantidade de acessos ao site em Agosto de 2019

Claro que não foi só a alteração do tema que contribuiu para o crescimento nos acessos do site. O aumento de artigos de assuntos variados, o crescimento do Pizza de Dados podcast que fundei com meus amigos, e a melhoria nas tags de SEO do tema, foram pontos que podem ter contribuído para o aumento de acessos.

No entanto, essa é a primeira vez que o meu site é de fato um blog, onde a primeira coisa que você vê ao entrar são os meus textos, eles também tem imagens de capa, um detalhe faltante no tema anterior. O SEO atualmente está melhor em relação ao próprio tema, mas o Moon tinha um SEO muito mais completo (mais tags implementadas). O que me leva a crer que o formato do site de fato é o fator mais importante aqui. Para ter certeza estatística desse sentimento, eu deveria ter feito um teste A/B para cada alteração… Mas bem, não fiz então fica aí o aprendizado para a próxima.

Uma reflexão sobre esse processo

Passar por esse processo de mudança de foco é normal. Assim como a tecnologia se transforma, as necessidades também vão mudando. E é muito gostoso perceber e permitir que o ajuste necessário perante às mudanças ocorra. No meu caso elas aconteceram gradativamente. Passei de uma pessoa que não tinha interesse em escrever nada pra alguém que publica artigos constantemente. Escrevi em plataformas pagas e troquei para plataformas gratuitas procurando espalhar conteúdo sem proibições causadas por paywalls. Meu site deixou de ser um bloco de notas público para se tornar oficialmente um blog.

E foi bom ver o crescimento ao longo desses 3 anos:

Imagem mostrando a quantidade de acessos ao site entre Dezembro de 2016 e Setembro de 2019. Dá para notar o vale causado pelo esquecimento da _tag_ ali entre Janeiro e Junho de 2019.

Eu não acredito que esses tipos de número são uma régua de pessoas, mesmo assim considero que essa evolução é um retrato bem claro das mesmas mudanças que passei ao longo desses anos, uma evolução composta de altos e baixos. E finalmente chegando a uma recompensa. Puxa vida. 17 mil pageviews! Quem diria não é mesmo?

Principais pontos

Então vamos recapitular bem os pontos de aprendizado:

Escolher um tema que seja focado no que você quer apresentar, isso vai fazer toda diferença na interação entre os usuários e o seu conteúdo;
Se você gosta de acompanhar o que acontece nos seu site não se esqueça da tag de rastreio;
Se você tem um site, aprenda um pouco de SEO e se você usar um plugin para montar as tags de SEO, aprenda como ele funciona;
Se quiser ter certeza estatística do impacto que uma alteração tem no seu site faça testes A/B.

Projetos Brasileiros para fazer pull requests nesse #Hacktoberfest o retorno

Wed, 25 Sep 2019 09:00:00 +0000

Edição atual da lista disponível aqui.

Depois dos sucessos das listas de 2017 e de 2018, esse é o terceiro ano que estou fazendo a lista/curadoria de projetos brasileiros para contribuir no #Hacktoberfest.

Então a pedidos aqui vai! Uma lista toda repleta de projetos pra você contribuir nesse mês de Outubro!

Novamente temos regrinhas:

Ser um projeto criado/desenvolvido/mantido por brasileiras(os);
Ter pelo menos uma issue aberta.

Avisos para 2019

Pra começar, diferentemente do ano passado, Essa lista agora não está mais no Medium! Isso quer dizer que para ajudar ela a crescer você pode mandar o link do repositório ali nos comentários que eu coloco o projeto na lista oooouuu você pode aproveitar o espírito de contribuição e mandar um PR para essa página! O artigo com as instruções de como adicionar projetos tá aqui. Todo mundo ganha <3.

Os projetos continuam separados pela linguagem principal pra facilitar as buscas pra quem lê e também em ordem alfabética pela linguagem. 😉

Happy Hacking!

C#

C

CSS

Clojure

C++

Elixir

Go

JavaScript

Julia

Kotlin

PHP

Pearl

Python

Ruby

Scala

Shell

Swift

TypeScript

Variados

Outubro de contribuição open-source com o #Hacktoberfest

Wed, 25 Sep 2019 03:00:00 +0000

Já está quase acabando o mês de Setembro e com isso se inicia os preparativos pra festa do mundo open-source: o Hacktoberfest. A Digital Ocean liberou hoje (25/09/2019) o início do cadastramento para o Hacktoberfest na página oficial do evento. Ano passado, cerca de 46 mil camisetas foram enviadas para pessoas que contribuíram no mundo todo. Esse ano, as recompensas estão limitadas à 50 mil.

O Hacktoberfest

Esse ano, o evento é patrocinado pelo Dev.to e pela Digital Ocean, e é um evento que dura o mês inteiro e busca incentivar a participação em projetos open-source. Saber um pouquinho de código para participar é interessante, mas não se deixe intimidar, tem espaço para todos os níveis de conhecimento. E a melhor parte: qualquer pessoa que queira pode participar da sua própria casa!

Objetivos

Abrir quatro pull requests em qualquer repositório público no GitHub independente se esse projeto tem ou não issues marcadas com a label do evento. E não precisa ter seu pull request aceito para ele ser contabilizado — alguns pull requests demoram mesmo para serem revisados e aceitos — , mas imagina que legal ter contribuições aceitas? Todo mundo ganha!

Regras

Mais uma vez, cada um dos quatro pull requests precisam ser feitos entre os dias 1 e 31 de Outubro em qualquer fuso horário. E não vale fazer spam, pull requests marcados como spam vão te tirar da brincadeira.

Como participar

Você vai precisar ter uma conta no GitHub (vai lá! Faz a sua! É rapidinho 😉 ). Depois de ter a conta no GitHub, é necessário se cadastrar no evento para contabilizar cada uma das cinco contribuições. Você vai precisar também saber um mínimo de como funciona Git (vou deixar alguns links sobre isso lá no fim no artigo).

Premiação

Além de dar os primeiros passos nessa onda de contribuições, aprender com o feedback que receber no seu pull request e ajudar algum projeto legal, você pode ganhar uma camiseta linda! Como eu mencionei antes, esse ano as camisetas estão limitadas à 50 mil participantes então, não deixe suas contribuições pra última hora!

Projetos para mandar o seu PR

Então, pra te ajudar nessa linda missão de fazer seus quatro pull requests, aqui tem uma lista linda de projetos que são mantidos ou foram criados por pessoas desse Brasilzão. Essa lista é pra ser colaborativa! Passa lá pra ver mais detalhes de como isso vai funcionar.

Links úteis

Vou deixar aqui alguns links que podem ser úteis e te ajudar a iniciar no mundo de contribuições.

Contribuições

Leia o texto da Leticia Portella sobre como contribuir para um projeto sem escrever código. E, se inglês não for um problema, leia também o Open Source Guide sobre como contribuir, não importa se você é um veterano ou iniciante em contribuições.

Git

Para aprender Git, você pode seguir o curso de Git da codecademy ou o curso da CodeSchool, ambos muito bons. Git não é fácil, mas todo mundo pode aprender.

Hacktoberfest

Dá para conferir o que rolou na Hacktoberfest 2016 e na Hacktoberfest de 2017. Muito importante também, o site oficial do evento para mais informações.

Também dá para conferir quantos pull requests foram feitos depois de ter se cadastrado ;)

Como ser Cientista de Dados usando um computador da Xuxa?

Mon, 03 Jun 2019 12:00:00 +0000

A resposta simples: Nuvem! Vamos ver na prática como é viver com seus Jupyter Notebooks na nuvem? Vaaamoooss!!!

Uns dois anos atrás, enquanto eu estava trabalhando na Operação Serenata de Amor, meus colegas de trabalho costumavam dizer que eu tinha um computador da Xuxa ou algo tipo assim:

Fonte

Nada contra os computadores da Xuxa ou o Pense Bem, mas se você considerar que no trabalho com ciência de dados, machine learning, inteligência artificial e afins, nem o computador da Xuxa, nem o Pense Bem e, nem tão pouco 4GB de RAM, vão ser o suficiente para rodar tarefas que requerem grandes quantidades de dados em memória ao mesmo tempo.

Enquanto cientista de dados, a maior parte do trabalho envolve tarefas “pesadas”. Uma solução para resolver rapidamente a falta de capacidade de processamento do computador é o uso de uma máquina na nuvem.

Vantagens

Mas o que faz a nuvem tão diferente assim? E o que faz dela um lugar tão mágico?

Hoje, um dos maiores desafios de ciência de dados e mais especificamente da área de big data é conseguir processar uma quantidade enorme de dados em pouco tempo e sem gastar muito para isso. E, nessas horas, a nuvem é seu maior aliado.

Hoje, no Brasil, você não encontra um Notebook leve com uma configuração robusta, com mais do que 16GB de RAM e um SSD com mais do que 128GB, por menos de 7 mil reais. Desembolsar essa quantidade de dinheiro está além da realidade financeira da maioria das pessoas.

Data centers de gigantes da tecnologia, como Digital Ocean (DO), Amazon Web Services (AWS), Google Cloud e Azure, têm disponibilizado acesso de baixo custo a máquinas com capacidade de processamento maior que os tais notebooks de 7 mil reais. Além disso, uma conexão com pouca largura de banda é o suficiente para acessar sua máquina na nuvem e colocar os scripts para rodarem.

Essas máquinas disponíveis conseguem, em questão de poucas horas, executar processamentos que levariam dias ou mesmo não iriam rodar em computadores convencionais.

Desvantagens

Mas a nuvem não é só feita de vantagens, existem alguns pontos que ainda me incomodam ao usá-la. Por exemplo, todos as empresas que oferecem esse tipo de serviço com qualidade irrefutável são gringas e cobram em dólares. Ainda falta um serviço brasileiro que seja barato e confiável o suficiente para nos fazer trocar os serviços oferecidos pela DO e pela AWS por exemplo.

Ainda ouso dizer que, por mais que as máquinas sejam plug-and-play, é necessário que algumas pequenas configurações sejam realizadas para de fato garantir a usabilidade mínima, obrigando assim ao cientista de dados a ter mais de um chapéu e, nesse caso, assumir o chapéu SysAdmin da coisa.

Jupyter in the cloud with diamonds

Okay, mas vamos supor que você já tem sua máquina maravilha bonitinha lá no insira-aqui-seu-serviço-de-nuvem-favorito. E aí? Como fica o Jupyter Notebook?

A Ana Schwendler já falou aqui sobre como os cientistas do Serenata usam Jupyter Notebooks para explorar os dados e validar ou negar hipóteses. Normalmente, o notebook é rodado localmente na máquina de quem esteja programando, mas quando a pessoa começa a usar uma máquina na nuvem como rola esse processo?

Vivendo nas nuvens

Fonte

O jeito mais prático de acessar uma máquina na nuvem é via conexão SSH. O SSH é um protocolo que permite acessar máquinas remotamente de forma segura. Existem formas de estabelecer uma conexão SSH usando programas como o PuTTY e o MobaXterm, mas se você tiver acesso a um terminal, você também pode fazer isso usando um comando, passando seu usuário na máquina remota e o endereço (host) dessa máquina, algo assim:

ssh user@host

Mas o que é esse SSH finalmente e como ele funciona? Na prática, o SSH nada mais é que um jeito seguro de fazer login num computador que não está pertinho de você e ele funciona como uma chave e um cadeado. Quando você vai entrar em casa, normalmente você tem que destrancar o cadeado, e o SSH funciona exatamente da mesma forma, você tem um par de arquivos que são chamados de chave e cumprem o papel da chave e o cadeado de casa.

Aí, ao invés de fazer um login tradicional com usuário e senha, você pode usar o SSH para se conectar a sua máquina na nuvem. Basta que no servidor tenha o seu cadeado (chave pública) e que você tenha a chave (chave privada) na sua máquina local. Pra quem usa programas como os que falei anteriormente, esses programas se encarregam de gerenciar essas chaves para você.

Num servidor Linux, o lugar padrão para encontrar os cadeados é o arquivo authorized_keys dentro da pasta .ssh. O mais legal é que uma mesma máquina pode ter várias chaves públicas dentro desse arquivo assim, todo o time que precisar acessar aquela máquina consegue. Isso permite por exemplo, o compartilhamento de recursos entre os integrantes do time, barateando ainda mais os custos para rodar tarefas pesadas.

Hoje em dia, por trabalhar de um computador com o Windows, mas tendo familiaridade com o Linux — eu uso o Git Bash, um terminal Bash distribuído com a instalação do Git e muito útil ❤. Acessar a máquina na nuvem via linha de comando funciona pra mim, mas se você preferir usar programas, fique à vontade, o gosto é do freguês e você deve escolher aquilo que for mais confortável para você 😉. Daqui pra frente eu vou mostrar como usar o terminal para fazer o que a gente precisa. Então, para acessar uma máquina usando o terminal basta fazer o seguinte:

$ ssh jessicatemporal@34.66.48.61

e você tá lá nas nuvens 😉

Vamos entender o comando:

ssh: é o programa para estabelecer uma conexão SSH;
jessicatemporal: é o meu usuário de acesso na máquina lá na nuvem;
34.66.48.61: é o endereço de IP da máquina que estou querendo acessar (aqui estou mostrando pra você um IP fictício apenas para exemplificar, tá?).

Agora que você acessou a sua máquina você pode rodar o Jupyter Notebook:

$ jupyter notebook --no-browser

Note que eu passei um parâmetro a mais ali o--no-browser que serve para o Jupyter Notebook rodar sem abrir um navegador.

Vivendo de portais

Quando rodamos o Jupyter Notebook no nosso computador, um canal de comunicação é escolhido para que a gente possa visualizar nossos notebooks, esse canal é conhecido como porta e, na configuração padrão do Jupyter, é a 8888. Assim a gente consegue acessar no nosso navegador o caminho [https://localhost:8888](http://localost:8888) e rodar nossos notebooks certo?

Mas, agora o Jupyter não está rodando no seu computador local então, vamos usar a nossa conexão SSH para ligar uma das portas do nosso computador com a porta do servidor em que o Jupyter está rodando. Para isso, você usa o argumento -L que gera o que é conhecido como port forwarding. Seu acesso SSH ficaria mais ou menos assim:

$ ssh -L 8888:localhost:8080 jessicatemporal@34.66.48.61

Em termos não técnicos, o port forwarding funciona como um portal.

Fonte

Se você cria um portal para algum lugar consegue ver o que está acontecendo nesse lugar. Também é assim que a gente consegue estabelecer um canal de comunicação e saber o que está rolando no servidor, criando um túnel (portal) que liga a porta 8080 da minha máquina local a porta 8888 do servidor:

Com isso você consegue abrir no navegador do seu computador e acessar o https://localhost:8080 para ver seus notebooks:

Finalmente

Depois de colocar seu Jupyter para rodar na nuvem, e acessá-lo usando o túnel, a construção do notebook em si não muda muita coisa. Você irá continuar a fazer suas análises como normalmente faz, com a pequena diferença que agora você tem o poder da nuvem ao seu alcance.

Fonte

Agora vai lá e conquiste a nuvem você também! Xêro.

Dicas

Se quiser aprender mais sobre o SSH recomendo:

Ler o manual dele a medida que precisar;
Esse post que faz um curso rápido de SSH;
Esse infográfico de referência sobre o SSH;
Se você quiser rodar o Jupyter numa instância do Google Cloud esse post aqui tá guardado no coração.

Raspagem de dados sem escrever código

Wed, 08 May 2019 03:00:00 +0000

Isso mesmo: existem alguns tipos de dados que conseguimos raspar sem precisar da ajuda de uma linguagem de programação. E eu vou te mostrar como fazer isso! Para esse tutorial você vai precisar dos seguintes materiais:

Conhecimento básico de HTML (reconhecer a tag <table>);
Acesso a internet;
Seu navegador favorito;
Um site para coletar informação.

Pra continuar lendo esse tutorial, vai lá para a revista do Pizza 👇

Transformando um site feito em Jekyll em uma página de um site feito em Pelican

Sun, 28 Apr 2019 03:00:00 +0000

No post “Movendo um site construído com Jekyll para dentro de um site construído com Pelican” eu contei a jornada que foi mover o site do PyLadies BR Conf para dentro do site do PyLadies Brasil. Aqui vai o passo a passo final com comandos que usei tudo isso.

Nota da autora: Aqui ensino o passo a passo para novas edições do PyLadies BR Conf, mas os comandos podem ser ajustados para fazer a mesma coisa com outros sites.

Ingredientes

Um repositório do site conferência clonado e configurado
Um repositório do site oficial PyLadies Brasil clonado e configurado

Preparativos

No repositório da conferência, ajuste o arquivo _config.yml:

a variável base_url deve conter um valor seguindo o padrão /conf-X onde X indica a edição da conferência
a variável url deve conter o domínio https://brasil.pyladies.com

Você pode encontrar um _config.yml ajustado para a primeira edição da conferência aqui.

No repositório do site do PyLadies Brasil, ajuste o arquivo pelicanconf.py:

acrescente o nome da pasta nova na variável STATIC_PATHS seguindo o padrão /conf-X onde X indica a edição da conferência;
acrescente a cofiguração de metadata da pasta nova na variável EXTRA_PATH_METADATA seguindo o padrão 'conf-X': {'path': 'conf-X'} onde X indica a edição da conferência
Crie uma pasta vazia dentro da pasta content/ seguindo o padrão /conf-X onde X indica a edição da conferência

Você pode encontrar um pelicanconf.py ajustado para a primeira edição da conferência aqui.

Misturando ingredientes

A partir de agora todos os comandos vão ser referentes a pasta conf-1/ então, lembre-se de ajustar os comandos para a edição da conferência que estiver criando. No repositório da conferência, rode o comando para fazer build do site:

$ jekyll build

Isso deve gerar a pasta _site/. Agora copie o conteúdo da pasta _site/ para dentro da pasta da conferência que criamos:

$ cp -r conf/_site/* br-pyladies-pelican/content/conf-1/

Levando ao forno

Se tudo funcionou corretamente até aqui faça o build do site do PyLadies Brasil:

$ html serve

e confira se consegue acessar o site da conferência em: https://localhost:8000/conf-1

Servindo

Faça os commits das alterações e abra o pull request 😉

Você pode ver o pull request que eu fiz para a primeira edição aqui.

Xêro.

Movendo um site construído com Jekyll para dentro de um site construído com Pelican

Sun, 28 Apr 2019 03:00:00 +0000

Ano passado aconteceu a primeira edição do PyLadies BR Conf lá em Natal no Rio Grande do Norte. A edição desse ano vai acontecer na cidade de São Paulo e, com o início dos preparativos para a segunda edição, precisamos mover o site da edição passada para um novo lugar. Aqui vou contar a história de como isso aconteceu.

Nota da autora: Se você não tiver interesse na jornada que culminou em ter o site no ar, a receita de bolo com os comandos para chegar nesse resultado pode ser encontrada aqui. 😉

Contexto

Para começar os trabalhos você precisa saber que o site oficial do PyLadies Brasil é construído com um gerador de sites estáticos escrito em Python chamado Pelican. Eu particularmente não sou fã do Pelican, mas escolhas pessoais à parte, ele tem funcionado muito bem como o site da PyLadies até o momento.

Já o site do PyLadies BR Conf, foi feito usando um gerador de sites estáticos diferente: o Jekyll, que é feito em Ruby. Embora não seja feito em Python ele foi escolhido por vários motivos, um deles sendo a ampla biblioteca de templates prontos, o que facilitou o site da conferência de ser customizado e colocado no ar.

No entanto, agora que estamos organizando a segunda edição do evento, nos deparamos com a seguinte situação:

Queremos colocar o site da edição nova no ar aproveitando a versão antiga e ao mesmo tempo mantendo também a versão anterior no ar por motivos históricos.

Existia várias formas de tornar isso possível, cada uma delas com seus lados positivo e negativo, por exemplo, poderíamos criar um novo repositório para o site desse ano. Mas daqui alguns anos com várias edições do evento tendo acontecido teríamos uma quantidade infindável de repositórios sem atualizações. Com isso uma solução interessante seria colocar o site da primeira edição com uma página do site oficial do PyLadies, assim manteríamos o histórico do evento vivo.

Preparando o Pelican

No Pelican é costumeiro encontrar todos os arquivos de conteúdo dentro da pasta content/, é nela que encontramos um diretório chamado extra/ que contém arquivos estáticos como o robots.txt.

Esses arquivos estáticos e essa pasta extra/, assim como a pasta images/, precisam ser mapeados dentro de duas variáveis no pelicanconf.py. Essa variáveis fazem o controle de arquivos estáticos para que o Pelican, ao fazer o build do site, possa copiar esses arquivos para pasta de build. Inicialmente elas estavam assim:

Fonte

Então ao olhar para isso inferi que se eu colocasse um arquivo teste.html dentro da pasta content/extra/ e mapeasse ele dentro dessas variáveis, eu encontraria o arquivo teste.html ele estaria no site buildado. Então alterei as variáveis de controle acrescentando as configurações no mesmo padrão para o arquivo teste.html:

Normalmente, o Pelican tenta interpretar todos os arquivos dentro da pasta content/ e gerar um arquivo HTML de resultado. Por isso, tentei fazer o build do site com essas alterações encontrei o primeiro erro:

ERROR: Skipping teste.html: could not find information about 'NameError: title'

Algumas horas depois de muitas tentativas falhas e de vasculhar a internet para achar o que poderia resolver esse erro, eu encontrei essa issue no GitHub do Pelican onde a pessoa tinha tido o mesmo problema e encontrado a solução. O que me faltava para resolver o problema era adicionar a seguinte linha ao pelicanconf.py:

READERS = {'html': None}

A variável READERS serve para indicar parseadores de arquivos, ao criá-la com o valor acima, estamos dizendo para o Pelican não fazer o parse de arquivos HTML. Ufa, problema resolvido, tudo funcionando, o Pelican serviu o arquivo perfeitamente: consegui acessar localhost:8000/teste e ver o arquivo de teste.

Gerando o site da conferência localmente

Primeiro teste feito, chegou a hora de gerar o site localmente. Como eu falei ali em cima, o site da conferência foi feito em Jekyll, um dos motivos para isso era que o próprio GitHub se encarrega de fazer o build do site para colocar ele no ar. Isso é ótimo porém nos impede de ter acesso ao site buildado.

Então para termos os site buildado e colocar ele como uma página no site oficial eu rodei o build localmente. Eu fiz um tutorial bem detalhado de como rodar e colocar um site no ar com Jekyll, então não vou entrar detalhes da explicação de cada comando aqui, mas recomendo você passar lá pra ler depois caso queira entender melhor.

Pra começar eu já tinha o repositório do site da conferência clonado no meu computador e também já tinha instalado todas as bibliotecas que precisava pra construir o site, então eu alterei o arquivo _config.yml trocando os valores das chaves base_url e url assim:

baseurl: "/conf-1"
url: "https://brasil.pyladies.com"

Com essa alteração o site buildado vai estar configurado para ser servido a partir de https://brasil.pyladies.com/conf-1. Então, para fazer o build é só seguir o tradicional:

$ jekyll build

O comando build gera o site da conferência dentro da pasta _site e ficamos com uma estrutura assim:

Uma subpasta chamada assets/ com vários arquivos de script do site CSS, JavaScript, imagens e um arquivo index.html. É todo esse conteúdo que vamos copiar lá para o site oficial.

Movendo o site da conferência para dentro do site oficial

Agora que já temos o site da conferência eu voltei para a pasta do site oficial e criei dentro da pasta content/extra/ uma pasta chamada conf-1/ e copiei o conteúdo da pasta _site/ para conf-1/ assim:

Depois disso, atualizei o pelicanconf.py:

Ao tentar rodar o build do site oficial me deparei com o segundo erro: olhando para essas configurações assumi que se eu colocasse a pasta conf-1/ dentro de extra/ e adicionasse as configurações no STATIC_PATHS e no EXTRA_PATH_METADATA seguindo o mesmo padrão que já tinha visto, seria o suficiente apara acessar localhost:8000/conf-1 e ver o site da conferência, mas ledo engano meu.

Foi preciso mais algumas horas e outras tantas tentativas frustradas para descobrir, na base da tentativa e erro, que o Pelican não consegue lidar com subpastas da forma que eu esperava. Eu esperava que, com as configurações a estrutura de pastas acima, o Pelican criasse uma pasta conf-1/ no site oficial o que me mostraria o site da coferência em localhost:8000/conf-1, mas o que aconteceu foi que o site da conferência foi mostrado em localhost:8000/extra/conf-1.

Lendo esse post você pode até achar que é óbvio o caminho para resolver esse segundo erro, inclusive eu mesma achei que poderia ter resolvido mais rápido agora que estou escrevendo aqui, mas, para mim, o momento eureka aconteceu ao olhar com mais calma para o conteúdo da pasta output/ — pasta em que o Pelican normalmente faz o build de sites.

Com as configurações que eu fiz, dentro da pasta output/ eu encontrei uma pasta extra/ e essa pasta que continha a pasta conf-1/. Antes das minhas alterações essa pasta extra/ não era gerada no site buildado. Então, decidi colocar a pasta conf-1/ dentro de content/ e no mesmo nível que a pasta extra/ assim:

E também alterando o arquivo pelicanconf.py da seguinte forma:

Agora ao fazer o build do site oficial do PyLadies Brasil conseguimos ver a página da conferência como esperado. 🎉 🎉 EBAAA!!

Moral da história

Persista nas suas tentativas e mantenha a calma. Mas, ainda mais importante que isso, converse com amigos e amigas sobre o seu problema, isso pode te ajudar a enxergar novas possibilidades. Foi o que eu fiz e me ajudou a exergar a saída para o segundo erro. 😉

Agora que você já leu tudo recomendo ler também o post “Transformando um site feito em Jekyll em uma página de um site feito em Pelican” para ver o passo a passo sem erros para reproduzir o que contei aqui.

Xêro.

How to define the optimal number of clusters for KMeans

Sat, 13 Apr 2019 03:00:00 +0000

Leia esse texto em Português na Revista do Pizza.

One of the most famous methods to find clusters in data in an unsupervised way is using KMeans. But what do we do when we have absolutely no idea how many clusters the data is going to form? We can’t just guess.

Discovering the number of clusters is a challenge especially when we are dealing with unsupervised machine learning and clustering algorithms. To solve the issue of “how many clusters should I choose” there’s a method known as the Elbow Method.

The idea is pretty basic: define the optimal amount of clusters that can be found even though we don’t know the answer in advance. Seems like magic, doesn’t it? But I promise you it isn’t.

The code that I’m going to use from now on can be found in this GitHub repository.

So to begin, we need data! We will use the Iris dataset. There’s a genre of flowers called Iris, it is a group of around 300 flower species with different petal and sepal sizes. Biological curiosity aside, the dataset is used to demonstrate how machine learning and clustering algorithms work a lot. I mean A LOT!

This dataset holds 150 samples of three Iris species (Iris setosa, Iris virginica and Iris versicolor) that even though are very similar, are distinguishable using a model developed by the biologist and statistician Ronald Fisher.

This dataset is so widely used that data science libraries usually have it built-in so it can be used in demonstrations and examples. Let’s take a peek at the first lines of our dataset, to start we need to import it, I prefer the version that comes in the seaborn library:

    import seaborn as sns
    iris = sns.load_dataset('iris')

Glancing at the first 5 rows of our dataset you might ask me: “But Jess, the answers were are seeking is right there in the _species_ column, weren’t we going to do unsupervised clustering?”

First 5 rows of the Iris dataset, the result of the `iris.head()` command

Okay, yes! We have the answers in our dataset but for the purpose of this tutorial, we are going to forget that we already know the species of our samples and we are going to try to group them using KMeans.

KMeans

If you aren’t familiarized with KMeans yet, you must know that to use this method you’ll need to inform an initial amount of clusters before you start. Thinking of the version implemented in scikit-learn in particular, if you don’t inform an initial number of clusters by default it will try to find 8 distinct groups.

When we don’t know how many clusters our samples are going to form we need a way to validate what is being encountered instead of just guessing.

The elbow method

And that’s where the Elbow method comes into action. The idea is to run KMeans for many different amounts of clusters and say which one of those amounts is the optimal number of clusters. What usually happens is that as we increase the quantities of clusters the differences between clusters gets smaller while the differences between samples inside clusters increase as well. So the goal is to find a balance point in which the samples in a group are the most homogeneous possible and the clusters are the most different from one another.

Since KMeans calculates the distances between samples and the center of the cluster from which sample belongs, the ideal is that this distance is the smallest possible. Mathematically speaking we are searching for a number of groups that the within clusters sum of squares (wcss) is closest to 0, being zero the optimal result.

Using scikit-learn

Scikit-learn’s KMeans already calculates the wcss and its named inertia. There are two negative points to be considered when we talk about inertia:

Inertia is a metric that assumes that your clusters are convex and isotropic, which means that if your clusters have alongated or irregular shapes this is a bad metric;
Also, the inertia isn’t normalized, so if you have space with many dimensions you’ll probably face the “dimensionality curse” since the distances tend to get inflated in multidimensional spaces.

Now that you are aware of all that, let’s look at our data: we have only 4 dimensions - length and width of petals and sepals, let’s use the elbow with our data, shall we? I wrote a function that receives a dataset as input and calculates the KMeans for 19 different amounts of clusters ranging from 2 to 20 possible groups and finally returns a list with our wcss:

    def calculate_wcss(data):
        wcss = []
        for n in range(2, 21):
            kmeans = KMeans(n_clusters=n)
            kmeans.fit(X=data)
            wcss.append(kmeans.inertia_)
    
        return wcss

When we use the function written above to calculate the within clusters sum-of-squares for our Iris dataset and plot the result, we find a plot like this:

on the x axis: the number of clusters used in the KMeans, and on the y axis: the within clusters sum-of-squares

Each orange point is a cluster quantity, note that we start in two and go up to 20 clusters. And there where we might get the first doubt: Which of these points is exactly the optimal cluster amount? Is it the point a2 or a3 or even the a4?

May math save us all

What if I told you that there’s a mathematical formula to helps us out?

It turns out that the point that indicates the balance between greater homogeneity within the cluster and the greater difference between clusters is the point in the curve that is most distant of a line drawn between points a0 and a18. And guess what! There is a formula that calculates the distance between a point and a line! And it is this one below:

Formula that calculates the distance between a point and a line that passes through P0 and P1

Don’t be scared, in this case, P0 is our a0 and P1 is our a18:

on the x axis: the number of clusters used in the KMeans, and on the y axis: the within clusters sum-of-squares, the green line is the base line to calculate the distance

and the pair (x,y) represents the coordinates of any point that we might want to calculate the distance to the line. Let’s look at our elbow plot one more time:

on the x axis: the number of clusters used in the KMeans, and on the y axis: the within clusters sum-of-squares, the green line is the base line to calculate the distance

Suppose we want to calculate the distance between the point a1 and the line that passes through a0 and a18, here is the data we need:

Substituting the values above into the distance formula we have the following:

Math and Python, the power couple everyone loves

I imagine you agree with me when I say “No one deserves to calculate all of this by hand”. So let’s use a method for that. In short, we are just going to transcribe the formula that calculates the distance between a point and a line to code, the result is something like this:

The method optimal_number_of_clusters() takes a list containing the within clusters sum-of-squares for each number of clusters that we calculated using the calculate_wcss() method, and as a result, it gives back the optimal number of clusters. Now that we know how to calculate the optimal number of clusters we can finally use KMeans:

    import seaborn as sns
    
    from sklearn.cluster import KMeans
    
    
    # preparing our data
    iris = sns.load_dataset('iris')
    df = iris.drop('species', axis=1)
    
    # calculating the within clusters sum-of-squares for 19 cluster amounts
    sum_of_squares = calculate_wcss(df)
    
    # calculating the optimal number of clusters
    n = optimal_number_of_clusters(sum_of_squares)
    
    # running kmeans to our optimal number of clusters
    kmeans = KMeans(n_clusters=n)
    clusters = kmeans.fit_predict(df)

Comparing before and after

After clustering the data we should take a look at the statistical description of each cluster:

Statistical description grouped by cluster

Not bad if compared to the statistical description of the original data that I show below, right?

Statistical description grouped by species

Conclusion

Obviously, no clustering will be 100% accurate especially when we have clusters that present very similar characteristics. I particularly like the visual version of a good clusterization. Let’s put two petal features in the plot and color the points based on the cluster each sample was given and also based on the species they belong to:

We can see in the plot those 12 observations that “migrated” in classification could easily be a part of any of the two clusters.

Is also worth mentioning that the elbow method isn’t the only way to infer the optimal cluster amount. There’s also a method that uses, for instance, the silhouette coefficient. But today, that’s all folks.

xoxo and good clusterization.

Extra reading

The article comparing the Ward method and the K-mean in grouping milk producers (in portuguese). In the third topic, there’s a great explanation of clustering methods.
One article in Wikipedia that explains in great detail the method to calculate distances from where I copied the formula that I should earlier.
There are slides from Professor André Backes class on clustering (in Portuguese).
The code that I used in this post can be found in this GitHub repository.

Como definir o número de clusters para o seu KMeans

Wed, 10 Apr 2019 03:00:00 +0000

Um dos métodos mais famosinhos pra achar agrupamentos em dados de forma não supervisionada é utilizando o KMeans. Mas e quando você não tem ideia de quantos clusters seus dados possam formar, como faz?

Pra continuar lendo esse tutorial, vai lá para a revista do Pizza 👇

Ciência de dados pela democracia

Sat, 06 Apr 2019 03:00:00 +0000

Vídeo

Você pode assistir essa palestra aqui.

Evento

Women in Data Science 2019

Apresentação

Copying files into a container

Wed, 03 Apr 2019 14:00:00 +0000

Sometimes volumes do not work and you have to copy things into the container. Really! You must be wondering, “how does a technology that everyone uses, doesn’t work?!”.

Okay, okay, I know this is looking like those stories of “works on my machine” inverted. But let me explain, earlier this year I was working with a temporary computer. Unfortunately, I did not have administrator powers of that computer, which prevented me from doing certain things, including giving Docker permission to share volumes with the Windows file system.

Is worth mentioning that I only discovered how to copy files to a running container because windows have these permission issues.

So, let’s go!

Materials

For this little tutorial, you’ll need:

A running Docker container
A file to copy to said Docker containerr
Basic Docker knowledge

Finding out the container

Depending on how you started your container you won’t know its name, so let’s first check it out. Since I work with science and data analysis, it is very common to find myself with a Jupyter container running, this is the one I will use here. To get the name of the container we need to list the containers that are up:

In my case this command shows a result like this:

CONTAINER ID        IMAGE                          NAMES
11b8af1aeb43        jupyter/datascience-notebook   relaxed_hypatia

I explained how to assemble this command that only shows the ID of the container, the image being used and the name of the container in this other pro tip. With the result above we know that the container I’m interested in is called relaxed_hypatia

Finding out where to send the file

Well if, like me, you usually map volumes to share the data with your container you probably already know where to send the data. However, if you don’t do this or it is a new image that you are using for the first time, your mission is to find out where to send the files. Usually, this information is in the documentation of the image.

For Jupyter Project images, there is a traditional folder to map the volumes that this: /home/jovyan/work. I’ll send the file there if you are using a different image remember to replace that path, to the path of your container.

Finally copying the file

Now that you’ve figured out where to send the data file and the name of the container, it’s time to finally copy the file to the container. If you like play copying files back and forth through the terminal, you should have the custom of using the cp command. But if you don’t have the habit, cp (from copy) is Ctrl+C Ctrl+V from the terminal, it makes a copy of a file from somewhere to another place. For example, let’s assume I have the following situation:

folder1/                        folder2/
└── file_A.txt		

And that I want to copy file_A.txt to folder2 using the terminal. I could do the following:

cp folder1/file_A.txt folder2

And the result would be as follows:

folder1/                        folder2/
└── file_A.txt                  └── file_A.txt

And the same can be done with containers. Docker has its own cp version called docker cp that works in a way analogous to the terminal cp. With the small difference that the destination path is formed like this: container_name:destination/path. So let’s copy the dados.csv file into my relaxed_hypatia:

docker cp dados.csv relaxed_hypatia:/home/jovyan/work/dados.csv

Now I can see the data inside my container. As in my case I’m running a Jupyter container I can see this file there in the Jupyter interface:

Cool huh? You can follow the same philosophy to pull data from inside the container to your local machine, just reverse the order of the paths.

Final considerations

One very important thing to remember, containers are meant to be ephemeral, so make sure you keep a backup of your data. After all, after removing a container, you no longer have the ability to retrieve the data that was inside.

Another reason a friend recently taught me in favor of copying the data into the container is that keeping volumes up-to-date when your container does a lot of reading and writing is extremely costly. So if you have a large file that does not change, like a data file, or a process that does a lot of reading and writing, like a rails server, it’s worth considering whether to copy the files into the container or even make an image already with these files. Always remember to weigh the points in favor and points against volumes the next time you use containers.

That’s all folks! xoxo

Copiando arquivos para dentro do container

Wed, 03 Apr 2019 12:00:00 +0000

Às vezes volumes não funcionam e a gente precisa copiar coisas para dentro do container. É sério! Você deve estar se perguntando, “como uma tecnologia que todo mundo usa, não funciona?!”

Tá, tá… Eu sei que isso tá parecendo aquelas histórias de “funciona na minha máquina” invertido. Mas vou explicar, no começo do ano eu estava trabalhando com um computador provisório. Infelizmente, eu não tinha poderes de administrador desse computador, o que me impedia de fazer certas coisas, inclusive de dar permissão ao Docker para compartilhar volumes com o sistema de arquivos do Windows.

Ah sim, talvez seja importante mencionar que eu só descobri como copiar arquivos para dentro de container que tá rodando, pois o Windows tem todas essas paradas de permissão.

Então bora lá!

Materiais

Para essa colinha você vai precisar de:

Um container Docker rodando
Um arquivo que você quer copiar para dentro do Docker
Conhecimentos básicos de Docker

Descobrindo o container

Dependendo de como você inicie o seu container você não vai saber o nome dele, então vamos primeiro conferir isso. Como trabalho com ciência e análise de dados, é muito comum me encontrar com um container do Jupyter rodando, é esse que vou usar aqui. Para pegar o nome do container precisamos listar os containers que estão de pé:

Aqui no meu caso, temos um resultado assim:

CONTAINER ID        IMAGE                          NAMES
11b8af1aeb43        jupyter/datascience-notebook   relaxed_hypatia

Eu expliquei como montar esse comando que só mostra o ID do container, a imagem sendo usada e o nome do container nessa colinha aqui. Com isso sabemos que o meu container de interesse se chama relaxed_hypatia.

Descobrindo para onde mandar os dados

Bem se, como eu, você normalmente mapearia volumes para compartilhar os dados com seu container provavelmente já sabe para onde mandar os dados. No entanto, se você não faz isso ou é uma imagem nova que você está usando pela primeira vez, sua missão é descobrir para onde mandar os arquivos. Geralmente essa informação está na documentação da imagem.

No caso das imagens do Projeto Jupyter, existe uma pasta tradicional para mapear os volumes que essa: /home/jovyan/work. Vou mandar os dados pra lá, então quando você tiver rodando aí pro seu container, lembre-se de substituir esse caminho, para o caminho do seu container.

Finalmente copiando os dados

Agora que você já descobriu o lugar para onde quer mandar os dados e o nome do container, chegou a hora de finalmente colocar os dados lá no container. Se você brinca de copiar arquivos pra lá e pra cá pelo terminal, deve ter o costume de usar o comando cp. Mas caso não tenha, o cp (de copy) é o Ctrl+C Ctrl+V do terminal, ele faz um cópia de um arquivo em um lugar para outro lugar. Por exemplo, vamos supor que tenho a seguinte situação:

pasta1/						pasta2/
└── arquivo_A.txt			

E que eu quero copiar o arquivo_A.txt para a pasta2, tudo isso pelo terminal. Então eu poderia fazer apenas o seguinte:

cp pasta1/arquivo_A.txt pasta2

E o resultado disso seria:

pasta1/					pasta2/
└── arquivo_A.txt			└── arquivo_A.txt

E dá para fazer a mesma coisa com o container. O Docker tem a versão dele chamado docker cp que funciona de forma análoga ao cp do terminal. Com a pequena diferença que o caminho de destino é formado assim: nome_do_container:caminho/de/destino. Então vamos copiar o arquivo dados.csv para dentro do meu relaxed_hypatia:

docker cp dados.csv relaxed_hypatia:/home/jovyan/work/dados.csv

E aí eu consigo ver os meus dados lá dentro do meu container. Como no meu caso eu tô rodando um container do Jupyter eu consigo ver esse arquivo lá na minha interface:

Legal né? Você pode seguir a mesma filosofia para retirar dados de dentro do container para sua máquina local, basta inverter a ordem dos caminhos.

Considerações finais

Uma coisa muito importante de lembrar, containers foram feitos para serem efêmeros, então lembre-se de se certificar que esta mantendo um backup dos seus dados. Afinal, depois de removido um container não tem mais como recuperar os dados que estavam lá dentro.

Outro motivo que um amigo me ensinou recentemente a favor de copiar os dados para dentro do container é que manter volumes atualizados quando seu container faz muitos processos de leitura e escrita é extremamente custoso. Então, se você tem um arquivo grande que não muda, como um arquivo de dados, ou um processo que faz muita leitura e escrita, como um servidor rails, vale a pena considerar entre copiar os arquivos para dentro do container ou até mesmo fazer uma imagem ja com esses arquivos. Lembre-se sempre de pesar os pontos a favor e os pontos contra volumes na próxima vez que for usar containers.

Por hoje é só pessoal. Xêro!

Playing with Docker’s container listing

Sat, 16 Mar 2019 03:00:00 +0000

If you use Docker, probably the third command you learned was to list containers, but do you know that you can tailor the container listing to your needs? Well, the hint today is to show two tricks I use a lot:

List filtering;
List formatting.

Let’s take a look at these two cases with care.

Filtering the container list

I think the first “advanced” command I had to learn was filtering a set of containers. Soon after getting started with Docker it is very common to have a “dirty” environment, that is, to have many containers with exited status exited without being removed.

So I learned how to filter such containers by their status. Within the traditional container listing command (docker ps), there is a flag called --filter or -f. This flag allows you to indicate filters to be made, for example:

docker ps -a -f status=exited

The result of this command will be a list of containers that have stopped running, but have not been removed. As I’ve said before, it’s pretty easy to lose control and have lots of stale containers “dirtying” your environment. So listing those that aren’t running can be a helpful hand i removing them more easily. I like to use a command like this:

docker rm -v $(docker ps -a -q -f status=exited)

Passing the -q flag causes the docker ps result to only show the container IDs, putting this complete command inside $() results in us passing the list of IDs to the docker rm and thus removing all the containers stopped with only one command. And the flag -v there is just to have feedback of what is going on with the command, it will show the ID of each container being deleted.

Formating the containers list

In addition to removing the containers that are dirting up our environment, sometimes I need some information about some of the containers that are running. Normally when we use the docker ps we see information like container ID, the command you ran to start the container, the image being used and a lot of other things… But sometimes seeing all that information on the screen all at once can be an information overload.

That’s when the magic of formatting the docker ps result comes in handy. The flag --format is the show this time, it accepts a template Go . If you do not know Go templates, here’s a super quick and superficial explanation: used for creating static sites, a template go is a string that is “filled” with information that is stored in variables.

For example, the template:

That template could be filled with any name that was stored in the variable Name. To identify variables in templates you’ll need to find the word that is preceded by a dot and is inside double curly brackets. If you are interested in learning more about Go templates, I’d recommend you check out this article in the official documentation for more information.

To start our formatting we need to know where the information that shows up on the screen is stored and you can use the table bellow for that:

Information	Variable
`CONTAINER ID`	ID
`IMAGE`	Image
`COMMAND`	Command
`CREATED`	RunningFor
`STATUS`	Status
`PORTS`	Ports
`NAMES`	Names

In my case I usually look for the name, the image and the container ID’s so my command ends up being the following:

Will give me a result like this:

    CONTAINER ID        IMAGE                          NAMES
    11b8af1aeb43        jupyter/datascience-notebook   relaxed_hypatia

Cool Huh? So have you listed your containers today?

Brincando com a listagem de containers Docker

Sat, 16 Mar 2019 03:00:00 +0000

Se você usa Docker, provavelmente o terceiro comando que aprendeu foi listar eles, mas você sabe que dá pra tunar a listagem de containers?

Pois bem, a colinha de hoje é para mostrar dois truques que eu uso muito:

filtragem da lista;
formatação da lista.

Vamos ver esses dois casos com carinho.

Filtrando a lista de containers

Acho que o primeiro comando “mais avançado” que eu tive que fazer foi filtrar um conjunto de containers. Logo ao começar a mexer com Docker é muito comum ficar com o ambiente “sujo”, ou seja, ter muitos containers com status de exited parados sem serem removidos.

Por isso, eu aprendi a filtrar tais containers pelo status. Dentro do comando tradicional de listar containers (docker ps), existe uma flag chamada de --filter ou -f. Essa flag permite que você indique filtros a serem feitos, por exemplo:

docker ps -a -f status=exited

O resultado desse comando vai ser uma lista de containers que deixaram de executar, mas não foram removidos. Como eu falei antes, é bem fácil perder o controle e ter muitos containers parados “sujando” o seu ambiente. Então listar aqueles que não estão em execução pode ser uma mão na roda para remover eles mais facilmente. Eu gosto usar esse comando assim:

docker rm -v $(docker ps -a -q -f status=exited)

Passando a flag -q faz com que, o resultado do docker ps mostre apenas os IDs dos containers, colocando esse comando completo dentro do $() faz com que passemos a lista de IDs para o docker rm e assim removendo todos os containers parados com apenas um comando. Ah a flag -v ali é só pra ter um feedback do que está rolando com o comando, ele vai mostrar o ID de cada container que estiver sendo excluído.

Formatando a lista de containers

Além de remover os containers que ficam sujando nosso ambiente, às vezes eu preciso de algumas informações sobre algum dos containers que estão rodando. Normalmente quando usamos o docker ps vemos informações como ID do container, o comando que você rodou para iniciar ele, a imagem que está sendo usada e outras coisas mais… Mas às vezes ver todas essas informações na tela pode ser uma sobrecarga de informações.

Aí que entra a mágica de formatar o resultado do docker ps. A flag --format que comanda o show dessa vez. Ela aceita um template Go. Se você não conhece templates Go, aqui vai uma explicação super rápida e superficial: muito utilizados para criação de sites estáticos, um template é uma string que é “preenchida” com informações sendo guiada por variáveis.

Por exemplo, o template:

poderia ser preenchido com qualquer nome que estivesse contido na variável Name. Para identificar variáveis em templates basta encontrar a palavra precedida por um ponto e dentro de chaves duplas. Se quiser saber mais sobre templates Go da uma olhada nesse artigo do grupo de estudos que fala muito bem sobre o tema.

Então, pra começar cada uma das informações que aparecem na tela você pode chamar seguindo esse mapa:

Informação	Variável
`CONTAINER ID`	ID
`IMAGE`	Image
`COMMAND`	Command
`CREATED`	RunningFor
`Status`	Status
`PORTS`	Ports
`NAMES`	Names

Como eu geralmente só quero ver o nome, a imagem e o ID dos containers que estão rodando, meu comando acaba sendo esse:

Que me da um resultado assim:

    CONTAINER ID        IMAGE                          NAMES
    11b8af1aeb43        jupyter/datascience-notebook   relaxed_hypatia

Legal né? E aí, você já listou os seus containers hoje?

Diferenciando json.loads de json.load e uma pitada de BigQuery

Fri, 15 Mar 2019 03:00:00 +0000

Se você nunca entendeu a diferença entre json.loads() e json.load() chegou a hora de entender! Na colinha de hoje vamos aprender a diferenciar esse métodos deliciosos.

JSON

Se você chegou até aqui, provavelmente já sabe o que é o JSON. Mas caso não saiba, bora recapitular: O JSON (JavaScript Object Notation ou Notação de Objetos JavaScript) é um formato leve de troca de dados. É fácil de ler e escrever, o que ajuda a ser usado por humanos além de também ser fácil de ser criado e interpretado por máquinas.

Se você já usou APIs provavelmente trocou dados com elas usando este formato. A maioria das linguagens de programação moderna oferece suporte de alguma forma a JSON. No caso do Python, existe uma estrutura que é quase a mesma coisa que um objeto JSON: o dicionário.

Módulo JSON no Python

Além de uma estrutura de dados, Python também traz de fábrica um módulo para manipulação de JSONs. Para utilizar esse módulo basta fazer o seguinte:

import json

Dentre os vários métodos, existem dois que são o foco dessa colinha de hoje .loads() e .load() que apesar de muito semelhantes em resultado, são diferentes em modo de funcionamento.

Dados

Mas antes de começar, vamos pegar alguns dados. Esses dias eu tava dando uma olhada no BigQuery, que entre muitas coisas legais que a ferramenta permite fazer, também da acesso a uma enormidade de dados públicos. Dentre eles dados do GitHub. Muitos desses dados estão disponíveis via API do próprio GitHub, mas se quiser aprender a mexer no BigQuery, eles já disponibilizam os dados lá dentro pra gente:

Muito fofo né? Dá pra ver pela imagem acima que o conjunto de dados github_repos contém 9 tabelas. Dentre elas uma tabela chamada languages:

Essa tabela embora grande tem poucas colunas, apenas 4 para ser mais exata:

Com o BigQuery é possível exportar dados para a sua conta do Google Drive. E foi isso que eu fiz, primeiro eu selecionei 100 observacoes da tabela usando a consulta SQL abaixo:

SELECT * FROM `bigquery-public-data.github_repos.languages` LIMIT 100

E após a query ter sido executada eu cliquei na telinha do próprio BigQuery para exportar os resultados. Ao exportar esses dados o BigQuery cria uma pasta no seu Drive:

E dentro dessa pasta um arquivo com o mesmo nome de extensão .json. Eu baixei esse arquivo e renomeei ele para bq-github-languages.json só para ser um nome mais indicativo do dado que ele contém.

Se você abrir esse arquivo você vai notar uma coisa que pode ser curiosa: Ao invés de ter um único JSON, o arquivo traz na verdade vários JSONs separados - um JSON para cada observação da tabela e isso nos traz ao nosso primeiro método.

.load()

O json.load() recebe um algo que seja “readable” ou seja, qualquer estrutura Python que tenha o método .read() embutido. Podemos encontrar esse comportamento por exemplo, em arquivos.

Então, se o nosso arquivo tivesse um grande JSON contendo as nossas observações, poderíamos usar esse método assim:

with open('bq-github-languages.json') as file_data:
    data = json.load(file_data)

Se você tentar fazer isso para carregar os dados do nosso arquivo, você ira dar de cara com um erro:

JSONDecodeError: Extra data: line 2 column 1

O que faz total sentindo já que não temos apenas um JSON no nosso arquivo e sim uma coleção deles, não é mesmo? Isso gera a obrigação de ler cada linha do arquivo assim:

with open('bq-github-languages.json') as file_data:
    data = file_data.readlines()

E tudo bem, mas essa ação traz o seguinte resultado: no lugar de ter uma lista com vários dicionários, você acaba com uma lista de strings. E se a ideia era manipular esses dados, strings não são a estrutura de dados mais indicadas. O que nos leva ao próximo método,

.loads()

Eu costumava confundir muito o funcionamento dos dois métodos. Até que, recentemente, algo clicou. Quando você tem strings, você deve usar .loads(). Você pode usar a dica que vem do próprio nome: s de string.

Aí depois de ler o arquivo linha a linha com o .readlines() você pode passar item a item da sua lista de strings e transformar ela num dicionário:

for i, item in enumerate(data):
    data[i] = json.loads(item)

ou até mesmo usar list comprehensions pra isso:

data = [json.loads(d) for d in data]

E aí podemos ver o resultado disso, data[0] vai trazer algo parecido com isso:

{'repo_name': 'gopz4u/ready',
 'language': [{'name': 'C#', 'bytes': '27779'},
  {'name': 'C++', 'bytes': '28415'},
  {'name': 'CSS', 'bytes': '6475'},
  {'name': 'HTML', 'bytes': '34293'},
  {'name': 'Java', 'bytes': '117831'},
  {'name': 'JavaScript', 'bytes': '205287'},
  {'name': 'Objective-C', 'bytes': '118096'}]}

Massa né? Bem, por hoje é só!

Um passeio pelo backstage de um podcast

Wed, 13 Mar 2019 12:00:00 +0000

Em conversas, algumas pessoas já me falaram a seguinte frase:

Sempre quis fazer um podcast sobre insira-aqui-o-assunto-de-sua-preferência mas não sei nem por onde começar…

E a minha resposta é sempre a mesma: Eu te mostro como fizemos com o Pizza e se você quiser você pode tentar fazer o mesmo 😉

É um assunto tão recorrente que eu decidi escrever sobre e te inspirar a transformar o seu podcast em realidade \o/

Pra continuar lendo esse artigo cheião de dicas vai lá para a revista do Pizza 👇

Podcast backstage tour

Wed, 13 Mar 2019 12:00:00 +0000

Se preferir leia esse artigo em português.

After a year of Pizza de Dados, I’ll tell you what it’s like to have a podcast.

I had a few conversations where people share the following:

I’ve always wanted to create a podcast about insert-here-your-favorite-subject, but I don’t even know where to start…

To which my reply is always the same: I’ll tell you how we started doing Pizza de Dados, and maybe the process will help you get started. 😉

It’s such a recurring subject that I decided to write about it and inspire you to make your podcast dream a reality \o/

Source

The beginning

Assuming you already have an idea of what you want to talk about, the first question I would ask you would be: Do you have money to maintain infrastructure or, like us, want something that can be kept free of charge? This is one of the first questions because there are a lot of platforms for podcasters, and most of them are paid, or those with a free account are very limited.

If you’re looking for something 100% free and without limitation - at least for the first few episodes, here’s the pizza recipe (from bum tsss) we use:

* Archive.org: You’ll need to store your podcast audios somewhere that generates a direct download link. In our case archive.org was chosen since there are no storage limitations;

* A feed.xml: You see, one thing you’ll need to learn to have a podcast is that you need to have a file in XML format. This file is what we call the feed, and it will pose as a communication channel to let platforms and aggregators know that a new episode has come out, so you will need to host this file somewhere. In the case of Pizza, we created a site using a Jekyll template and hosted it on GitHub.

A website

We wanted to show the world what was being discussed and who was participating in each episode. To accomplish that, we made a site that would have a post for each episode and hosted it on GitHub. GitHub has a tool called GitHub Pages that is for anyone to put websites online (I made a post - in portuguese - on how to do it that you can check out).

Basically, the most widely used way to distribute podcasts today is by using Apple. Other than showing information from each episode, our website also had a crucial role in serving our feed.xml. Most Jekyll templates come with a standard feed, but you may need to make some adjustments.

For Apple to know that your podcast exists, you need to create an account on Podcasts Connect and submit the feed with the standards that Apple specifies. In our case, this submission process was a bit boring, as we need some interaction until the feed is 100% up to standard, but once the feed was ready and validated to Apple podcast specifications, we were prepared to distribute Pizza through there.

Before recording

Before we get to ~put the pizza in the oven~ we have to plan. Our podcast is mainly made of interviews in a friendly chat environment, but for that to happen, we prepare a lot.

The first step then is to choose a guest or guests to chat with us. We have a giant spreadsheet with names of people we want to bring to Pizza on a wide range of subjects within data science. It is from this spreadsheet that we mainly chose the people who come to talk to us. Next to each person’s name, we have a list of subjects that led to her/him being on the list.

Based on the person chosen and the subject in which she or he specializes in Leticia Portella, Gustavo Coelho, and I share several posts and articles internally until the recording date. We use this as a way to prepare and write “the agenda” of the day. The agenda itself is a relatively simple file with topics and questions of interest to us. We send it to our guests at least a week in advance so that 1) he or she can contribute with issues to be discussed and 2) can prepare on what is coming and feel as comfortable as possible while recording.

The agenda is not a rigid set of topics, we will not talk precisely about what is written on it, but it serves to prevent us from getting caught in moments of “we have nothing to talk about”. In most cases, the conversation flows naturally, and the agenda is hardly ever used.

An important point of preparation is also the alignment of schedules. Matching the busy schedule of 4 or 5 people is sometimes complicated, so we are prepared to record more than one episode a month. This ensures we have material to publish if none of the guests we had in mind can record with us on the date we had in mind.

Recordings

In the beginning, we tested two ways to record, the first was using a video conferencing program called Zoom, but Zoom’s free account limits conference time when you have more than 2 people in the room (one of the reasons for the first episode being one of the shortest). With time limitation being the screaming factor, we switched to YouTube. That’s right, the Pizza episodes are recorded on YouTube.

Source

Google used to have a tool called Hangouts On Air, which is now part of YouTube. Basically, it allows you to make a Hangouts call and (amazingly!) record it! These calls are associated with your YouTube channel, so we kinda became YouTubers.

Source

There are several types of calls on YouTube: public calls, which everyone subscribed to your channel will receive a notification when they start and can watch live; unlisted ones that people with a link can follow live if they wish, but channel subscribers will not receive notification (imagine a secret live conference); and private ones, which can be viewed by invitation only.

YouTube call creation screen

Today is exactly what we do, we create the private call on YouTube and send the call link to the guests, so we can record without anyone watching. 😋

After we finish recording, we use youtube-dl to download only call audio with the highest quality available. A word of caution: There are a few things that influence audio quality 1) microphones and 2) audio transmission. Audio that is transmitted via the internet, for example, as is our case, naturally loses some of its quality. That’s why we always download with the best quality possible. Microphones, on the other hand, can only be improved by buying high-quality microphones, often more expensive, so try to do your best to mitigate the lack of a good microphone by recording in a quiet place without echoes and background noise.

Edition

If you follow Pizza from the beginning, you know that we have evolved a lot in the last year, right? Today we have our own audio magician: Johnny (we love you Johnny ❤), but at first, it wasn’t always like this…

In the beginning, we did the editing ourselves. That consisted of cutting silences and language vices using a program called Audacity. It caters to many audio things from recording to editing and supports all operating systems we use.

Editing was by far the most massive task for us since we had zero knowledge of how to do it. This step took the time that we didn’t have to give, it was the task that most prevented the episode from being released at regular intervals. But we made it work. Finally, a few months into the podcast, we partnered with Data Bootcamp, and that allowed us to pay Johnny and free up our time to focus on other activities.

Making the post

Apart from editing, we still have to write the episode post. This is the second most massive task. We listen to the audio and write down every technical term and concept we mention, then look for reference links on said subject to add to the post.

After doing this task sometimes, we created a template that has the skeleton of a post, so we avoid rewriting the repeating sections like “Listen Now” and “People in this episode”, this template also helps us not to forget any parts that should appear on a typical post. 😉

YouTube episode

Did you know that in addition to using YouTube for recording, we also release Pizza episodes on YouTube? Each one is also rendered as a video. To do that we use two tools:

kdenlive: The most straightforward video editor I’ve found for Linux;
Canva: An online platform for making designs. You may have noticed that the Pizza arts have the “same face”, this happens because we use Canva to standardize our brand, there we save in our primary colors, the font we use, the Pizza icon and the images we use as templates for YouTube and other social networks.

Usually, the video rendering happens alongside posts write-ups since every post comes with an embed of the video uploaded to YouTube as an alternative platform for people to listen.

Uploading the material

Audio: Ready. Video: ready. Post: done. It’s time to put all of this on the platforms. Then we upload the audio to archive.org and the rendered video to YouTube and schedule it to the episode’s release date.

Pizza delivered

After all of this process is done, finally comes new episode release day. Remember, I said we created a page on GitHub? This page is like a blog, and each episode is a blog post.

So on the agreed release date, one of the 3 pizzaiolos would go to GitHub and create a pull request on the website project to finally air the new chapter. Pull request accepted, GitHub takes care of updating the site and officializing the release of the latest episode.

Final considerations

Of course, not every podcast is like this, and this is a dynamic that worked for us, recently we went through some changes, and you may have noticed that the new Pizza landing page no longer has the episodes posts. And that may also happen to you after the podcast takes flight, you will notice a natural evolution.

Oh, and one last thing, during this natural evolution process, we also launched a recurrent funding campaign that helps us pay for Johnny’s work, so if you like what we do, support our work (and Johnny’s 😜).

I would also like to thank all the listeners and friends who have been following and supporting Pizza. And for you who want to start your own podcast: I hope this post helps to clarify some of the ideas and how-tos.

Hugs and welcome to the podsphere.

Indo além no Schematics: Personalizando nossos modelos e validações

Wed, 13 Feb 2019 02:00:00 +0000

Não basta definir modelos e usar as validações que vem de fábrica, às vezes precisamos expandir essas validações para casos específicos do nosso domínio. Vamos ver como fazer isso nesse tutorial.

Pra continuar lendo esse tutorial, vai lá para a revista do Pizza 👇

Retrospectiva 2018: Você cresceu esse ano?

Sun, 30 Dec 2018 10:00:00 +0000

Eu tenho uma mania de achar que andei em círculos o ano inteiro e acabei no mesmo lugar que estava em dezembro do ano passado. Então assim como no ano passado decidi fazer uma retrospectiva rápida das coisas que aconteceram esse ano… Ano passado eu viajei bastante e esse ano eu quis ter mais equilíbrio na vida, conseguir focar em projetos mais perto de mim e em mim mesma. Então assim como no ano passado, vamos brincar de retrospectiva. A brincadeira é a seguinte:

Escolha um tema: O seu tema pode ser qualquer coisa, desde que você considere que ele tenha um peso importante no seu ano. Esse ano escolhi Projetos pessoais. Ah e se você não quiser escolher um tema só tudo bem também 😉
Cada coisa/momento que eu considero notável no meu ano entra na lista. Um momento notável é algo que ficou marcado de alguma forma quando alguém pergunta E aí como foi o ano?
Cada item da lista vai ter uma descriçãozinha com o motivo que torna aquele momento notável por exemplo: aprendi a tocar violão, e isso é notável pois eu comprei um violão fazem 3 anos e até agora tava pegando poeira;
O objetivo é perceber que, por mais difícil que o ano tenha sido pra você, você cresceu esse ano;

Então bora lá!

Um ano de Pizza: Completamos um ano do podcast mais queridinho no mundo de ciência de dados e fizemos um episódio esse mês pra falar como foi massa passar esse ano com as pessoas que escuta o Pizza.
Dei palestra num evento de marketing digital: Como no ano passado, dar palestras continuou sendo algo que eu gosto muito de fazer, esse ano o desafio foi um pouco diferente ao aceitar falar sobre serenata num evento que não estava no meu roteiro tradicional de eventos. O FireFestival é um evento anual organizado pela HotMart em Belo Horizonte e que esse ano decidiu trazer uma trilha com conteúdos mais técnicos além da tradicional trilha de marketing, e lá fui eu falar sobre ciência de dados e Serenata pra uma galera nova… Mas além de passar conhecimento, eu aprendi várias dicas que estamos aplicando no 🍕.
Dei meu primeiro Keynote e o segundo também: Bem, que eu dei algumas palestras esse ano não é novidade afinal, eu adoro fazer isso, no entanto além de falar num evento fora do tradicional pra mim, eu tive a honra de ser convidada pra ser keynote em não um, mas dois eventos da minha comunidade favorita ❤️ e lá fui eu ser keynote da Primeira PyLadiesBrConf e da Python Nordeste desse ano ao lado de pessoas incríveis que admiro muito!! Amor eterno a comunidade Python e as pessoas lindas que fizeram eventos maravilhosos mesmo em condições desfavoráveis, vocês são demais! Ano que vem a PythonNordeste vai ser na minha terra natal em Recife! Nos vemos lá ein?!
Ajudei a organizar a PythonSudeste: Python Sudeste evento regional e itinerante foi em São Paulo esse ano, e eu fiz parte do time maravilhoso que organizou o evento. Aos trancos e barrancos a PySE saiu e foi massa demais! Um beijo no coração de todos da org e principalmente da galera que topo estar em SP em plena páscoa pra prestigiar o evento! Ano que vem a PySE vai ser no Espírito Santo e já tem lugar.
Hacktoberfest: todo ano eu tento incentivar pessoas a participarem do hacktoberfest, ano passado eu fiz uma lista de projetos brasileiros que estavam precisando de contribuições, esse ano fiz uma lista nova e ainda fiz duas lives ensinando como fazer PRs uma comigo fazendo PR e outra com uma amiga incrível onde começamos desde a instalação do git na máquina dela até o PR. Ano que vem pretendo fazer mais isso durante o mês de outubro pra ajudar mais gente 😉.
Escrevi posts sobre estatística ~finalmente~: desde que eu e a Leticia Portella demos um tutorial na PyBR de 2017 sobre “Introdução aos Módulos de Análise de Dados” eu percebi que o mais difícil para pessoas que já programam e chegam ao mundo de ciência de dados é a parte estatística da coisa, e desde então que eu tenho vontade de explicar conceitos de estatística para pessoas. Esse fim de ano eu finalmente consegui escrever 3 blogposts (um deles já está no ar) com conteúdo de estatística descritiva! Então se você quiser aprender mais sobre isso ou relembrar conceitos fica de olho que mais posts estão por vir.
Consegui configurar o OBS no meu computador: não que eu queira ser YouTuber, mas algumas pessoas aprendem melhor vendo vídeos do que lendo conteúdo, então pra completar os posts sobre estatística eu vou também gravar uns vídeos explicando como fazer as coisas com exemplos práticos! Vai ser legal! 😎 Mas pra isso eu precisava conseguir gravar de uma forma satisfatória a tela do computador e aí eu consegui configurar o OBS, um software que permite gravar e fazer stream de video, yay!
Aprendi uma linguagem nova!: Eu não tinha me dado conta disso até que um amigo viu meu CV atualizado e disse “Eita, você aprendeu uma linguagem nova esse ano!” E eu fiquei “Puxa! Verdade!”. Trabalhando na Nuveo eu entrei em contato com a linguagem de programação Go, uma linguagem novinha criada pelo Google parecida com C e focada em performance. Como parte do produto Nuveo é escrito em Go, era de se esperar que mais cedo ou mais tarde eu aprendesse essa linguagem, com muita paciência e muita orientação do Cesar, posso dizer que terminei o ano sabendo Go. Ah e dica todas as quintas-feiras, às 22h tem encontro do grupo de estudos de Go que o Cesar organiza, então se você tá querendo aprender Go também aproveita e se junta a galera.
Escrevi uma feature do zero em Go no sistema da empresa: a maior prova que aprendi é que nos últimos meses do ano, além de dar manutenção na parte Python que eu trabalhava, também desenvolvi uma feature nova do zero em Go no sistema da Nuveo! Viva!!!
Roubei o Sudocast para a edição especial #OPodcastÉDelas: Esse ano foi a segunda edição do O Podcast é Delas uma iniciativa para trazer mais mulheres para a podosfera onde qualquer podcast pode participar. Aí os meninos do Sudocast toparam a ideia de que eu e umas amigas apresentassem a edição 11. Falamos de muitas coisas técnicas passa lá depois pra ouvir.
Ganhei uma bolsa de estudos da Udacity: Esse ano a Udacity em parceria com algumas empresas ofereceu muitas bolsas de estudo para ciência de dados, uma dessas bolsas foi concedida em parceria com a Bertelsmann, e eu fui uma das 15mil pessoas selecionadas para primeira fase de estudos. Infelizmente não passei para segunda fase que incluía ganhar cursar um Nanodegree da Udacity, mas ainda assim foram 3 meses de aprendizado muito legais!
Comecei um blog com um propósito e não terminei: Quando comecei os estudos da bolsa da Udacity decidi que, além de fazer minhas anotações, iria postar coisas sobre o que eu estava estudando num blog apenas para isso. Com o passar dos dias e com a loucura da vida, tive que abandonar o blog pois ele estava mais atrapalhando o meu andamento do que me ajudando a fixar as informações ¯(ツ)/¯. Mas tudo bem, os estudos me deram um guia de como fazer os posts sobre estatística pra revista do pizza \o/
Fui coordenadora de trilha no TDC SP: junto com o Pery Lemke e o Vitor De Mario coordenei a trilha de Go (linguagem que aprendi esse ano ❤️) na edição de São Paulo do TDC! Tivemos um equilíbrio muito bom entre homens e mulheres palestrando e ficamos muito orgulhos com o resultado do dia 😉
Dividi apê durante um mês com a Thais: Uma das belezas de trabalhar remotamente é que da pra fazer essas coisas, morar um mês numa cidade diferente, pra melhorar ainda mais morar um mês com uma mulher incrível foi uma daquelas experiências maravilhosas que a gente nem acredita que poderia rolar ❤️.
Notebooks de volta ao ar com ajuda de um amigo: ao fazer a transição para Open Knowledge Foundation, uma coisa que aconteceu foi que os notebooks da Serenata viraram uma tag dentro do GitHub dificultando o acesso a eles (já que para vê-los era necessário baixar e descompactar um arquivo .zip), para mim uma característica fundamentais da Serenata era a possibilidade de ser fonte de conhecimento em análise de dados através da disponibilização dos notebooks, então eu e o Rodolfo Viana que estávamos sentindo saudade dos notebooks, com a ajuda do Cuducos, colocamos os notebooks de volta no ar num repositório só pra eles 🎉🎉 e estamos mantendo esse projeto, então se quiser mandar mais contribuições estamos lá para ajudar 😉
Mudei de emprego: Ano novo vida nova de fato, fechei mais um ciclo de trabalho dessa vez, digo xau pra Nuveo, a jornada foi incrível, mas chegou ao fim. E voltando oficialmente a ser cientista de dados, digo olá para a Globo!!! Aahh e vou ser colega de trabalho do Rodolfo!!! Vai ser top!

Um ano de muitas emoções e por esse ano é só! Vamos ver ano que vem como vai ser…

Um abraço apertado e um cheiro 😘

PS.: e você que tá lendo isso, se eu te perguntasse o que você fez esse ano, o que você me diria? Se quiser contar sou toda ouvidos 😉

Frequência

Wed, 12 Dec 2018 02:00:00 +0000

A arte de contar observações

Aprenda o que são e como calcular frequências.

Pra continuar lendo esse artigo e aprender a calcular frequências, vai lá para a revista do Pizza 👇

Introdução ao Schematics: um guia para validar dados de um JSON

Tue, 20 Nov 2018 00:00:00 +0000

Garantir regras de negócio é uma questão primordial no mundo da programação. Essas regras também afloram na parte de dados quando precisamos garantir que estamos recebendo as informações necessárias e nos formatos esperados para alimentar nossas bases.

Quando esses dados vem de uma API no formato textual de um JSON, nosso software precisa garantir que o casting desse dado vai trazer formatos consistentes. Existem várias formas/bibliotecas para fazer isso em Python, uma delas é a Schematics.

Pra fazer o tutorial sobre o Schematics clica aqui nesse botão 👇

Subindo imagens docker pro dockerhub

Sat, 17 Nov 2018 08:00:00 +0000

Já achou mágico aquelas imagens pros containers docker que qualquer um pode usar e já pensou em fazer uma mas não sabe como? Vem que eu te ensino 😉

Pra começar você vai precisar de uma conta no Docker Hub é lá que todas todas as imagens para containers Docker vivem. Depois de criar sua continha lá, podemos passar para linha de comando e começar a usar a CLI do Docker.

Antes de fazer qualquer coisa precisamos de um projeto certo? O projeto que vamos usar aqui está neste repositório do GitHub. Ele consiste apenas em um script Python que faz a soma de dois números recebidos na linha de comando.

Agora que temos um projeto vamos começar pelo login, embora você não precise fazer login para fazer o build das suas imagens, uma vez feito o login você pode esquecer que ele existe:

docker login

Agora vamos fazer o build da nossa imagem:

docker build -t sum .

Aqui usamos o parâmetro -t para dar nome à nossa imagem. Depois de fazer o build podemos conferir a imagem na nossa lista de imagens disponíveis localmente:

docker images | grep sum

Agora que temos uma imagem pronta, vamos dar uma tag para ela e conferir se ela foi taggeada corretamente:

docker tag sum $(echo DOCKER_USERNAME)/sum

Basicamente é esse passo que nos permite divulgar nossas imagens. Então depois de dar uma tag para sua imagem. Chegou a hora de fazer o push (envio da imagem para o Docker Hub):

docker push $(echo DOCKER_USERNAME)/sum

e pronto. Agora a imagem foi enviada para o Docker Hub, tornando possível qualquer pessoa usar o docker pull para baixar a e usar a imagem:

docker pull jtemporal/sum && docker run --rm jtemporal/sum 4 2

Algo extra

Ficar fazendo esses passos todos na mão pode ser cansativo se você precisar subir muitas imagens e além disso, tudo que fazemos a mão pode estar propenso a erros. Então o caminho natural seria automatizar essas tarefas.

Existem várias formas de fazer isso, mas vamos aqui usar um script shell que chamei de push.sh para isso:

#!/bin/bash

if [ -z ${DOCKER_USERNAME} ]; then
    echo "Missing DOCKER_USERNAME variable!"
    exit 1
fi

error() {
    if [ $? != 0 ]; then
        echo "Error!"
        exit 122
    fi
}

build() {
    echo "=> Building ${1}"
    docker build -t ${1} .
    echo "=> Built ${1}"
}

tag() {
    echo "=> Tagging ${1}"
    docker tag ${1} $(echo $DOCKER_USERNAME)/${1}
    echo "=> Tagged ${1}"
}

push() {
    echo "=> Pushing ${1}"
    docker push $(echo $DOCKER_USERNAME)/${1}
    echo "=> Pushed ${1}"
}

build ${1}
error
tag ${1}
error
push ${1}
error
echo

exit 0

Nele reproduzi todos os passos que fizemos até aqui e para usar basta fazer:

./push.sh sum

Você pode ainda colocar esse script em uma ferramenta de entrega contínua e deixar a mágica acontecer.

Links

Os códigos e passos demonstrados aqui estão neste repositório do GitHub passa lá pra deixar uma ⭐️

Filas e mensagens pra que te quero

Mon, 05 Nov 2018 00:00:00 +0000

Um comparativo entre Kafka, RabbitMQ e NATS

A filosofia do micro serviço e de partes que funcionam independemente de um todo, mas vivem em constante comunicação, não é nada novo. Essa comunicação pode se dar de várias formas, umas mais onerosas que outras. Por isso, é importante escolher bem para garantir a resiliência e escalabilidade do seu software.

Pra continuar lendo esse comparativo clica aqui nesse botão 👇

Projetos Brasileiros para fazer pull requests nesse #Hacktoberfest versão 2018

Sun, 30 Sep 2018 03:00:00 +0000

Edição atual da lista disponível aqui.

Ano passado eu fiz uma lista de projetos brasileiros que estavam precisando de uma mãozinha e que qualquer pessoa poderia fazer um pull request.

Então esse ano vamos fazer isso de novo! Ebaaa! Regras

Novamente temos regrinhas:

Ser um projeto criado/desenvolvido por brasileiras(os);
Ter pelo menos uma issue aberta.

Pra ver projetos Brasileiros para contribuir clica aqui nesse botão 👇

Ciência de dados no mundo real com Serenata de Amor

Tue, 18 Sep 2018 03:00:00 +0000

Vídeo

Você pode assistir essa palestra aqui.

Evento

DevConf 2018

Apresentação

Post Mortem Python Sudeste 2018

Fri, 24 Aug 2018 05:00:00 +0000

Finalmente saiu o post mortem da Python Sudeste 2018. Lembrando que este relatório contém os fatos do meu ponto de vista e que eu tentei ser o mais fiel aos acontecimentos possível. Ele tá longo! Mas muita coisa aconteceu e todo mundo que tenha interesse merece saber ;)

Índice

Definições
- Iniciais
- Finais
Antes do Evento
- Local
  - Dificuldades
Organização
- Divisão de equipes
Palestras e tutoriais
Divulgação e artes
Ingressos
Patrocínios
Código de Conduta
Durante o evento
- Grupos de trabalho
Controle Financeiro
Após o evento
Conclusões

Definições

Aqui temos o queríamos da Python Sudeste de 2018 em linhas gerais. Estão definidas em duas partes: as iniciais, aquelas que idealizamos em um primeiro momento; e as finais, aquelas que realmente se deram. Durante a leitura deste post mortem, você encontrar uma narrativa de tudo que fizemos, tanto o que deu certo quanto o que deu errado e mais do que isso, o por que eu acho que deu certo ou errado.

Iniciais

Evento para 360 pessoas em São Paulo;
4 Keynotes;
Dois dias de evento em Abril (três dias caso conseguÍssemos local para receber workshops e tutoriais);
Trilha única.

Finais

Evento para 250 pessoas em São Paulo;
3 Keynotes;
Três dias de evento 30 e 31 de Março e 1 de Abril;
5 Trilhas: 3 de palestras e 2 de tutoriais durante todos os dias.

Antes do Evento

Local

A Python Sudeste de 2018 aconteceu na BandTec Digital School em São Paulo - SP.

Dificuldades

É a escolha do local que define o tom do evento e praticamente toda organização do evento se deu ao decidirmos um local para o mesmo mas, até conseguirmos fechar um local, tivemos algumas dificuldades e vou narrá-las a seguir. A saber, todos os locais prospectados estão disponíveis nesta planilha.

Guarulhos ou São Paulo capital

No começo das movimentações (mais ou menos em outubro) existia a defesa de Guarulhos como uma possibilidade por causa de prospecções iniciais do Bruno Rocha que encontrou um Hotel que atenderia bem as nossas expectativas, porém a maioria do grupo acordou que o evento deveria ocorrer na capital por diversos fatores: um ótimo sistema de transporte metroviário, grande diversidade de opções alimentares, o amplo leque de opções de fácil acesso para happy hours e a maior quantidade de possibilidade de locais para escolher.

A busca inicial e sua falha

A maior parte dos locais que acomodasse as cerca de 400 pessoas que tínhamos em mente cobrava um sinal de 10% (ou mais) do valor do aluguel para confirmar a reserva e nosso valor de caixa era um total de 0 reais. Nenhum possível patrocinador tinha sido confirmado. Nenhum local que não cobrasse aluguel (coworkings e afins) apresentava a capacidade para cerca de 400 pessoas tinha sido identificado para possível acordo. Isso arrefeceu o grupo inicial de voluntários com cerca de 30 pessoas.

Surgimento de um local: Microsoft

Em 15 de Dezembro, por intermédio do Mário Sérgio, a Microsoft entrou em contato com eventos Python que já tinham data aproximada para ocorrer, com interesse de se aproximar da comunidade e estreitar laços nessa nova fase da empresa. Finalmente em 26 de Dezembro chega um e-mail pedindo informações sobre os encontros ou eventos da comunidade em São Paulo. Eu, Jessica me responsabilizei por organizar o primeiro encontro do GruPy-SP no espaço de eventos da Microsoft, enquanto o Renne Rocha tomou conta da frente de viabilizar o possível patrocínio para a Python Sudeste ao enviar a carta de patrocínio do evento. Ao receber a proposta de patrocínio nos foi oferecido o auditório da Microsoft (uma vez que o local ainda não estava fechado) com capacidade para 250 pessoas.

Com essa possibilidade em mãos o time de voluntários voltou a se mover para viabilizar o acontecimento do evento a partir do dia 2 de Janeiro principalmente, pela pressão feita pela Microsoft para que o acontecimento do evento se desse no último final de semana de Março (31 de Março e 1º de Abril). Discutimos internamente e topamos o desafio de adiantar em aproximadamente 1 mês da data que tínhamos idealizado.

No dia 5 de Janeiro, enviei à Microsoft por WhatsApp os dados da APyB para escrita do contrato, uma vez que os meus e-mails anteriores não haviam sido recebidos.

No dia 18 de Janeiro, aconteceu o encontro do GruPy-SP na Microsoft. Esse encontro tinha como objetivo, levar a comunidade para dentro da Microsoft e também apresentar o espaço do evento para a organização. Neste mesmo encontro, apertamos as mãos de definimos a data oficial do evento 31 de Março e 1º de Abril e a Microsoft como patrocinadora do local.

Por volta do dia 15 de Fevereiro, depois de muita insistência de nossa parte por um contrato, em ligação com o Samuel, a Microsoft “deu pra trás”, com a ciência de que dia 30 de Maio era um feriado, a Microsoft ficou em dúvida sobre o sucesso do evento. Enquanto isso nós da organização e outras pessoas da comunidade já haviam comprado passagens então mudar a data não era uma opção viável.

Um novo local

Ainda no dia 15, Samuel e Renne, se movimentaram para ver a possibilidade do evento ocorrer inteiramente na BandTec, local que por intermédio do Danilo Belini estávamos vendo de receber nossos tutoriais e workshops no dia 30 de Março.

Nessa hora foi fundamental a participação do Danilo que conseguiu agilizar junto com o Renne e o Samuel, perante a BandTec e a IdWall o patrocínio do local.

No dia 26 de fevereiro foi assinado o contrato com ambas empresas e o novo local definido.

Nos 10 dias entre a troca efetiva do local passamos a reorganizar o formato do evento que agora seria em trilhas uma vez que a maior sala, passou a ter capacidade máxima de 65 pessoas.

Organização

Do grupo inicial com 30 pessoas presentes no Telegram, nós tínhamos um nível muito variado de níveis de comprometimento. Começou a ficar claro um grupo que estava sempre presente, nas reuniões e/ou nas participações assíncronas.

Divisão de equipes

Ainda em Outubro de 2017 numa reunião via Hangouts definimos as seguintes equipes de trabalho dentre os presentes:

Local: Samuka, Beatriz, Bruno, Rafael
Mídias: Jessica, João, Vinicius Mesel, Bruno, Erika
Patrocínio: Bernardo, Ciro, Carlos, Bruno
Orçamentos: Ciro, Paty, Fábio
Inscrições/Ingressos: Ciro, Renne
CDC: Jessica, Paty
Conteúdo, Trilhas, Keynotes, Call4papers: Beatriz, Carlos, Fábio, Vinicius Mesel
Brindes, Canecas, Camisetas: Erika, João

Como vou detalhar mais a frente, essas equipes sofreram algumas mudanças.

Comunicação Interna

Inicialmente um grupo foi criado no Telegram onde reunimos as 30 pessoas inciais. A medida que as conversas de busca de local e organização das demais frentes começaram a impedir uma conversa viável no Telegram passamos para o Slack.

Apesar de uma ótima ferramenta, o Slack coincidiu com o esfriamento orgânico da organização com a chegada das festas de final de ano e a falta de um local. O grupo do Telegram por sua vez foi reavivado efetivamente em Janeiro com a soma do aparecimento do local no dia 2 de Janeiro e o envio do pedido conjunto de Grant para PSF no dia 4 de Janeiro.

No fim o Slack foi abandonado do uso diário servindo apenas para formalizar as informações e fazer anúncios e discussões nos devidos canais e todas as demais comunicações passaram a serem feitas pelo Telegram.

Divisão de tarefas

Com a falha de comunicação mais clara, com a troca entre ferramentas de comunicação causando alguns colegas a se perderem no que estava sendo organizado e com o eventual ruído causado por um grupo muito grande onde poucos estavam de fato trabalhando. Surgiu a ideia de adotar uma nova forma de organização: Um núcleo central chamado de core e focado em desenrolar as pendências e um time satélite de voluntários com níveis mais leves de comprometimento. Todas pessoas que formaram a organização do evento concordaram em seguir o que chamamos de Guia de Contribuição da Organização.

O core

Com o levantamento das pessoas que estavam mais ativas no fim de Janeiro/começo de Fevereiro por meio de um formulário, identificamos entre nós mesmos um grupo de aproximadamente 12 pessoas que deveriam ser parte do time core, dessas 8 demonstraram interesse em se comprometer de acordo com o descrito nos deveres do Core no Guia de Contribuição da Organização. Mais tarde esse time de 8 seria incrementado com a participação de mais um.

O voluntariado

O grupo final de voluntários contou com 25 pessoas, das quais 22 estavam entre voluntários iniciais, e 9 dessas parte do Core, enquanto 3 pessoas foram adições tardias e valiosas para o andamento do evento.

Resultado da reorganização

Na prática, após essa divisão o Core se reorganizou para suprir as necessidades daquelas equipes iniciais, que passaram a ser organicamente as seguintes:

Local: Samuca, Renne, Danilo
Mídias: Jessica, Serrones, Rafael Henrique
Patrocínio: Renne, Carlos
CdC: Jessica, João
Orçamentos: João, Juan
Inscrições/Ingressos: Renne, Jessica e Samuca
Conteúdo, Trilhas, Keynotes, Call4papers: Rafael Henrique e Danilo
Brindes, Canecas, Camisetas: João, Juan e Carlos

Palestras e tutoriais

Chamada para palestras

No dia 24 de Janeiro abrimos a chamada para palestrantes que deveriam submeter suas palestras de forma anônima pela plataforma Speakerfight, onde tivemos 50 palestras submetidas.

Chamada para tutoriais

Eventualmente, abrimos também a chamada para tutoriais na mesma plataforma e tivemos 9 submissões.

Keynotes

Para a escolha de keynotes, todo o grupo reuniu uma lista de 24 pessoas que gostaríamos de convidar. Essa lista foi reduzida para 12 mediante votação em uma das nossas reuniões de onde saiu o primeiro nome e os demais convidados para keynotes foram escolhidos dentre esses por votação assíncrona via google forms.

Resultado final:

Paula Grangeiro
Cássio Botaro
Bernardo Fontes

Divulgação e artes

Basicamente a divulgação dos acontecimentos do evento foram feitas nas redes sociais Facebook, Twitter e Instagram com a ajuda da plataforma de postagem automática Hootsuite que na sua conta gratuita permite o agendamento de 30 postagens ao mesmo tempo.

Todas as artes foram feitas também numa plataforma gratuita chamada Canva. Para facilitar o trabalho nessa frente foi criada uma agenda de postagens e um grupo apelidado de “XOXO media” no telegram.

Ingressos

Os ingressos foram vendidos pela plataforma EventBrite e foram organizados da seguinte forma:

Lote 1 (promocional) Ada Lovelace: 58 ingressos à R$ 45,00
Lote 2 Grace Hopper: 85 ingressos à R$ 60,00
Lote 3 (último) Dorothy Vaughan: 13 ingressos à R$ 75,00

Ainda tínhamos mais dois lotes escondidos:

Lote Patrocinadores: 23 ingressos cortesia com acesso mediante código
Lote Organizadores: 31 ingressos à R$ 60,00

O primeiro anúncio das vendas dos ingressos se deu pela manhã do dia 2 de Março nas redes sociais do evento. O primeiro lote acabou tão rápido que arte deste lote nem conseguiu ir ao ar e já na hora do almoço fui anunciada o início das vendas do lote Grace Hopper. O último lote só foi anunciado seu início no dia 5 de março.

Ainda tivemos o seguinte problema: muito daqueles que enviaram propostas de palestras e tiveram suas palestras aprovadas, não conseguiram comprar seus ingressos, e assim completamos o que faltou com um outro lote escondido para os palestrantes.

Com o contrato do evento a taxa de serviço da plataforma ficou em 8% (a taxa não foi repassada aos participantes) e as vendas de ingresso somaram o valor de R$ 11.523,00.

Patrocínios

Patrocínio é uma etapa muito importante antes do evento, é por meio deles que vamos definir que tarefas vamos vamos fazer com certeza e quais das vontades teremos que deixar de lado.

Tivemos seis cotas de patrocínio:

Diamante
Platina
Ouro
Prata
Bronze
Believer

Cada cota está descrita na nossa carta de patrocínio e mais do que isso ainda disponibilizamos contatos de três pessoas da organização além do e-mail do evento.

Nem todos os patrocinadores apoiaram o evento com valores monetários, a IdWall em conjunto com a BandTec se responsabilizaram pelo valor referente ao aluguel do local por exemplo, assim essa verba nunca entrou no nosso fluxo de caixa.

Caso Microsoft

Sobre o Termo de condições, que é exigido na primeira etapa de cadastro do sistema de pagamentos da Microsoft, nos deparamos com a cláusula 20.a e 20.b que faz referência a seguros:

20. Seguro. a. O Fornecedor manterá as seguintes apólices de seguro e limites mínimos (ou limites equivalentes na moeda local aplicável): (i) limites de responsabilidade civil de US$ 1.000.000 (um milhão de dólares) por ocorrência para danos pessoais e/ou à propriedade (incluindo Seguro de Veículo), (ii) Responsabilidade do Empregador, com limites mínimos de US$ 500.000 por ocorrência e (iii) limites legais para qualquer requerimento judicial ou extrajudicial nos termos de qualquer Lei Americana sobre Doenças Ocupacionais ou Remuneração do Trabalhador aplicável ou outras leis ou regulamentos semelhantes que sejam aplicáveis a atos do Fornecedor e/ou de seus representantes, funcionários ou subcontratados segundo esta Ordem de Compra.

b. Se a cláusula sobre Mercadorias e Serviços desta Ordem de Compra der origem a responsabilidade Profissional/responsabilidade por erros e omissões, o Fornecedor, por sua conta, manterá uma cobertura de seguro para essa responsabilidade, com limites de, no mínimo, US$ 2.000.000 para cada requerimento judicial ou extrajudicial, ou os limites equivalentes na moeda local aplicável. O seguro incluirá cobertura por violação de direitos de propriedade de terceiros (por exemplo, direito autoral e marca comercial) se essa cobertura estiver disponível de forma comercialmente razoável. O Fornecedor manterá a cobertura da apólice ativa ou um período de relatório estendido, fornecendo uma cobertura para os requerimentos judiciais ou extrajudiciais apresentados e relatados à empresa de seguro em até 12 (doze) meses após o término ou a rescisão desta Ordem de Compra.

Essas cláusulas impossibilitaram que a organização do evento se sentisse confortável para assinar o contrato de patrocínio encerrando assim as conversas com a Microsoft.

Caso SciELO

Apesar do interesse em patrocinar o evento não foi possível finalizar esse patrocínio de forma bem sucedida, a SciELO precisava que o descritivo na nota emitida fosse “Patrocínio do Programa SciELO ao evento Python Sudeste, realizado na cidade de sp entre os dias 30 de março de 2018 e 01 de abril de 2018” no lugar de treinamento conforme estava. Como o sistema de emissão da NF-e não permite a edição do campo do descritivo (que já vem com opções pré-definidas) tivemos que cancelar esse patrocínio.

Caso Olist e iClinic

Ambas empresas já tinham fechado orçamento de patrocínio no fim do ano anterior. Para o evento acontecer em março/abril e essas empresas conseguirem incluir o evento no orçamento, seria legal já ter as cartas enviadas por volta de outubro/novembro.

Caso Cota Believer

Nossa ideia com essa cota era abarcar tanto empresas menores (com um caixa mais restrito) quanto pessoas físicas que quisessem ajudar o evento pagando mais que apenas seu ingresso. Ficou claro que se misturar PF e PJ não foi uma decisão sábia. Por exemplo, o pessoal da empresa Hub9 tinha caixa para essa cota, mas ficou com medo de que ela fosse algo apenas para freelancers.

Código de Conduta

A equipe do CdC teve dois momentos principais:

Pré-evento para a tradução do CdC para inglês; Durante o evento para disponibilidade de atuação em casos de ferimento do Código.

Na abertura do evento o código de conduta de foi lido em sua integridade e o time de resposta apresentado:

Jessica Temporal
Paty Morimoto
João Lugão

Durante o evento o time de resposta esteve disponível o tempo todo tanto para atuar como coringas no caso da falta de alguém da organização, quanto para atender possíveis casos de quebra do CdC. Essa foi a primeira Python Sudeste com uma equipe de resposta. Não houve casos de atuação da equipe.

Durante o evento

Grupos de trabalho

Nossa equipe de voluntários foi dividida para termos sempre alguém nas salas para dar suporte a palestrantes e ministradores de tutoriais e além disso, permitir um revezamento de pessoas para que todos pudessem descansar e/ou visitar outras palestras durante o evento. Sendo assim cada sala e/ou trabalho que a equipe estava responsável ficou conhecida como Missão. Como descrito na tabela a seguir:

Nome	Missão
Bruna Balthazar	ADA
Ciro	ADA
Eduardo Mendes	ADA
Jessica Temporal	CDC
João Lugão	CDC
Patricia	CDC
Juan Funez	Coringa
Samuka	Coringa
Beatriz	Credenciamento
Danilo Bellini	Credenciamento
Renne Rocha	Credenciamento
Gutem	Credenciamento
Erika Campos	DOROTHY
Fábio Serrão	DOROTHY
Yros Aguiar	DOROTHY
Alini	GRACE
Bruno Rocha	GRACE
Andre Pastore	GRACE
Carlos	GRACE
Marcio Mendonça	Tutoriais - KATHERINE
Rafael Henrique	Tutoriais - KATHERINE
Guto Maia	Tutoriais - MARY
Juliano Atanazio	Tutoriais - MARY

E mais detalhadamente essas eram as descrições das missões repassadas ao corpo de voluntários:

ADA, DOROTHY e GRACE: são as salas/trilhas de palestra, cada grupo de três pessoas deve se organizar para revezar para banheiros, assistir outras palestras, apresentar os palestrantes, encerrar as palestras e abrir para perguntas;

CDC: São as pessoas que vão cuidar das quebras de conduta e afins, devem estar livre para perambular pelas salas;

Coringas: Vão ser responsáveis por resolver as tretas se fazer os corres de última hora, além de ajudar a distribuir os lanches nos coffees;

Credenciamento: Devemos ter credenciamento todos os dias a partir das 8 am, e ajudar durante a distribuição dos lanches nos coffees;

Tutoriais: Como os tutoriais muitas vezes fluem sozinhos, é só garantir que os tutores estão bem assistidos com as tecnologias (tomadas, adaptadores e afins) e se revezar.

Controle Financeiro

Depois da entrada do primeiro patrocínio, sentimos a necessidade de usar algo mais prático para fazer o controle financeiro, então assinamos uma conta no Mobills que se mostrou muito vantajoso. Foi a partir dessa conta que exportamos to nosso fluxo de caixa. Uma versão mais amigável do fluxo está disponível neste link.

Mas em linhas gerais:

O evento se moveu principalmente com o pagamento de fornecedores do bolso dos organizadores, o que não é saudável para nenhum evento;
O primeiro influxo de caixa veio da Python Software Foundation, no valor exato de R$ 10899,46;
A última receita foi proveniente do Patrocinador Diamante Dielbold Nixdorf no valor de R$ 13.000,00;
O evento terminou com um saldo positivo de mais de 12 mil reais;
Deste saldo, a seguinte divisão será feita:
- 40% para PySE2018 no ES;
- 30% para PyLadiesConf;
- 30% para FlaskConf.

O saldo positivo foi retirado da conta da APyB e está em minha posse e eu ficarei responsável de fazer os repasses para as organizações dos eventos acima.

Após o evento

Doações

Parte da compra de kits e lanches sobraram e foram doadas para a Instituição Casa das Mães por intermédio do Samuca. Você que tá lendo pode ver os vídeos desse dia aqui.

Certificados

Os certificados foram emitidos e um validador foi construído e está disponibilizado no site deste ano graças ao Danilo Belini (PR #83).

Fotos

Nós pedimos ao querido Julio Melanda para fazer os cliques do evento e todas as fotos estão disponíveis aqui nesse link.

Fechamento do caixa

Foi feito por mim e o pessoal da APyB nesta semana com o objetivo de fazer o repasse da verba para os eventos Flask Conf BR, Python Sudeste 2018 e PyLadies Conf BR.

Escrita do post mortem

Comecei a escrever esse post mortem logo no fim do evento. Porém como a vida tem dessas ele foi deixado de lado por algum tempo até que agora consegui finalmente terminá-lo. Ele contém basicamente uma narrativa dos fatos de acordo com a minha memória e vivência dos mesmos.

Conclusões

A conclusão final do evento é a de que: Pessoas > Tecnologia.

Python Sudeste só aconteceu pois todos envolvidos estavam dispostos a doar seu tempo, paciência e vontade para o evento. A estrada até a conclusão foi cheia de obstáculos mas foi vencida em equipe. Então a dica para quem lê são as seguintes:

O mais importante feito é fechar um local para o evento e enquanto não houver um combinado por escrito assinado por ambas partes, o local não está garantido. Ainda assim, com contrato fechado pode acontecer de o local dar errado, mas é mais difícil.

É de suma importância ler com calma os contratos e questionar os pontos de dúvida, as letras miúdas podem trazer prejuízo aqueles organizando os eventos.

É importante ter uma rede de apoio: o time menor para execução é mais bem sucedido pois é mais fácil controlar quem faz o que e o andamento das coisas, no entanto um evento no porte da Python Sudeste e semelhantes deve contar com pessoas que vão participar em pontos chaves como voluntários, seja no dia do evento ajudando a montar o local ou fazendo a ponte entre mais um patrocinador e a organização.

Durante os meses de organização é comum as pessoas envolvidas terem suas prioridades alteradas, mas com transparência tudo pode desenrolar bem.

Gostaria de deixar um agradecimento especial aqui aos nossos patrocinadores, que acreditaram na gente para fazer o evento acontecer. Aos nossos colegas da APyB pelo apoio com burocracias. A todos palestrantes que aceitaram compartilhar conhecimento. A todos participantes que toparam se divertir e aprender. E principalmente a todos os voluntários que dormiram pouco todos os dias de evento e se desdobraram para fazer acontecer com um sorriso no rosto.

E no fim, mesmo com muita coisa errada no começo, provamos que tudo pode dar muito certo.

Abraços,

Jessica Temporal

Pegando o começo de uma string com Go ou Python

Wed, 16 May 2018 05:00:00 +0000

A colinha de hoje mostra como pegar o começo de uma string tanto em Go como em Python sem usar expressões regulares 🎉

Vamos supor que você tem a seguinte string: "Gopher" e você quer saber se ela começa com "Go" e também se começa com "C". Em Go:

package main

import (
	"fmt"
	"strings"
)

func main() {
	fmt.Println(strings.HasPrefix("Gopher", "Go"))
	fmt.Println(strings.HasPrefix("Gopher", "C"))
}

e em Python:

print('Gopher'.startswith('Go'))
print('Gopher'.startswith('C'))

Os dois exemplos vão printar “true” para a primeira e “false” para segunda em ambas linguagens.

Curiosamente, se você quiser saber se a sua string começa com "" (string vazia) ambas linguagens vão retornar “true” também.

Em go:

package main

import (
	"fmt"
	"strings"
)

func main() {
	fmt.Println(strings.HasPrefix("Gopher", ""))
}

Em Python:

print('Gopher'.startswith(''))

Importante saber disso para evitar ou cair propositalmente em casos de borda.

Massa né? Partiu aprender outras linguagens 😜

Agradecimentos

Principalmente ao Cesar que pacientemente tem me ensinado Go.

Instalando VPN no Windows

Fri, 11 May 2018 00:00:00 +0000

Além de mascarar IPs, a VPN tem me servido para resolver um bloqueio causado pela minha provedora de internet nova. No caso a porta 22 (porta utilizada pelo protocolo SSH para comunicação) está bloqueada, então ao rotear meu tráfego por um servidor diferente, esse impedimento some.

Pra continuar lendo sobre isso e aprender a configurar a VPN no Windows clica aqui nesse botão 👇

Ubuntu no Windows

Fri, 11 May 2018 00:00:00 +0000

Ultimamente eu tenho precisado testar alguns softwares que desenvolvemos na Nuveo no Windows e pra agilizar o desenvolvimento (pelo menos em partes) decidi que ter um bash à mão seria útil. No Windows 10 fazer isso é relativamente fácil e vou ensinar como aqui nesse post. Bora lá.

Pra continuar lendo sobre isso e aprender a usar o Ubuntu (e outras distribuições Linux) no Windows clica aqui nesse botão 👇

Usando o chaves SSH no Windows

Fri, 11 May 2018 00:00:00 +0000

Depois de ativar o Ubuntu no Windows qual o próximo passo? Definitivamente configurar o Git!

Pra continuar lendo sobre isso e aprender a configurar as chaves SSH no Windows clica aqui nesse botão 👇

Instalando Go no Windows

Fri, 11 May 2018 00:00:00 +0000

Pra galera que assim como eu precisa escrever e testar código Go no Windows, vou mostrar o passo-a-passo de como instalar o Go na sua máquina. Prometo que não vai nem doer!

Pra continuar lendo sobre isso e aprender a instalar e configurar o Go no Windows clica aqui nesse botão 👇

Deploying an API to Heroku

Sun, 15 Apr 2018 01:00:00 +0000

Deploys, where do they live? What do they eat? If you want to learn how to deploy something to Heroku you came to the right place!

What you will learn in this tutorial

How to create a Flask application to run on Heroku
How to deploy said app
A little bit of Git
A little bit of API consumption

Warnings: Of the two posts I used as a base to write this one, one of them was very outdated and the other, although recent, did not have instructions that correspond to the most recent version of Heroku, they are in the links section in case you want to read them.

Heroku who?

If you’ve made it this far, you probably already know what Heroku is, but for those who don’t know it, Heroku is a cloud platform that gives people “the fastest way to go from idea to URL” and without having headaches with the infrastructure part.

This platform provides a service that, based on a predefined structure of an application, manages to package that application and put it to run on a server in one of their data centers. Heroku accepts applications written in several languages, but today we are going to use Python.

Let’s code!

For this tutorial I made an API with the Python microframework called Flask. I won’t get into the details on how Flask works, but you can refer to the oficial documentation or look for one of the many tutorials available out there.

Our API

The API will only have one endpoint defined by / route. This endpoint can give two responses depending on the request you make. They are as follows:

Request	Response
GET without extra headers	Don’t panic!
GET with Authorization 42	the answer to life, the universe and everything

The code to do this is short and straight forward, take a look:

import os
from flask import Flask, jsonify, request


app = Flask(__name__)


@app.route('/')
def dont_panic():
    if request.headers.get('Authorization') == '42':
        return jsonify({"42": "The answer to life the universe and everything"})
    return jsonify({"message": "Don't panic!"})


if __name__ == "__main__":
    port = int(os.environ.get("PORT", 5000))
    app.run(host='0.0.0.0', port=port)

This code lives inside a file called dont_panic.py in my project codebase, but you can name it as you see fit. In addition, this code has a peculiarity: the last three lines, they are the configuration used when the Flask server is running on Heroku.

Pipfile

I mentioned at the beginning of this post that the base posts I used were somewhat outdated? Well, nowadays Heroku requires a Pipfile to prepare the environment in which our application will run. Pipfile will serve to install the Python libraries needed to run our application. And if like me, you don’t like using Pipenv you can create the file by hand, as I created mine below:

[[source]]

url = "https://pypi.python.org/simple"
verify_ssl = true

[packages]

Flask = "*"

[requires]

python_version = "3.6"

For the development enviroment, I like to use the good old requirements.txt which looks like this:

click == 6.7
Flask == 0.12.2
itsdangerous == 0.24
Jinja2 == 2.10
MarkupSafe == 1.0
Werkzeug == 0.14.1

Procfile

To run the API locally the command is as follows:

FLASK_APP=dont_panic.py flask run

As you won’t be inside the Heroku environment to input the command yourself to get your API up and running, you’ll need some sort of configuration to tell Heroku how to run your application. The file that holds the command that runs your app is called Procfile.

One important detail is that this file does not have an extension, depending on your operational system and your text editor, you need to be careful when saving this file to avoid some extention like .txt from appearing. Saving this file with an extention will cause a failure in your deployment.

For this application, Procfile will have only one line, which is the following:

web: python dont_panic.py

Okay, now what else?

Versioning

Since Heroku works with the Git versioning system, regardless of whether you host the code on GitHub or not, you’ll need to define a code versioning history.

So, after creating all these files, you need to add all of that to your Git tree. If you’re not a big fan of Git, you can do the following:

$ git init
$ git add .
$ git commit -m "creating the application"

This commands above will gather all files in the same commit, this is not a good practice and if you are interested in good practices and learning more about Git, there will extra links for that in the links session at the end of the post.

3, 2, 1… Deploy \o/

Now you have a choice: there are a few ways to send your code to Heroku. You can connect with GitHub or Dropbox or use the Heroku CLI. In this post I’ll will show you how to do it using the Heroku command line.

First of all you need to install Heroku CLI.

Logging in

After installing the CLI, you’ll need to login to your account

$ heroku login

This command will ask you to enter your Heroku account email and password:

Heroku CLI login screen

Note: I used the -i here because I’m running on a remote server, this will request user and password on the terminal instead of openning up a browser for the login

Next you need to create an app within Heroku to upload your code to.

Creating an application

Using the interface

It is possible to create an application through the website interface, where you will see the following screen:

You just need to input an unique name and then click the Create app button, that will take you directly to the deploy tab of the app especific page. I created the app called dontpanicapi, and if you scroll down you’ll see steps to upload and deploy your app:

As you can see the last command displays the remote we need to add to our repo, and basically you just have to run it, and you’ll be able to publish the code:

heroku git:remote -a dontpanicapi

The output for the command above show be something like this:

Using the terminal

But we can also create the application using the Heroku CLI. The good thing about using the CLI is that when creating the application, remote is created automatically:

heroku apps:create dontpanicapi

And that should output something like this:

One important thing here is that the name you choose for your application must be unique in Heroku, using the interface you’ll get imiate feedback whether the name you chose is available or not. This is important because the name of your application is used to create the Heroku subdomain. If you try to create an application with a name that is already being used, you see an output to the command above like this this:

If you don’t care about the name of your application, you can run the following command:

heroku create

And it will create an app with a random name:

After creating the application, you can take a peek at the Heroku dashboard in the applications area to see the list of your applications:

And finally deploy time!

After committing everything, logging in and creating your application on Heroku it’s deploy time!! 🎉🎉🎉

Deploying here means sending the application code to the server and running the process to get our API up on the Heroku instance.

Other contexts may bring variations and intermediate steps of the one I am presenting here, since as our application is simple and Heroku is made to help us get our applications up and running, the biggest job becomes the creation of the configuration files (which you know how to do now) 😉

Then, the command that will actually send the code to the server is:

git push heroku master

If command is successful you should see something like this outputed to the terminal:

One last though, you may need to ensure that your application has at least one dyno running with the following command:

heroku ps: scale web = 1

Dynos

Now you maybe asking yourself, what is a dyno? A dyno is a Linux Container, Heroku uses a container model that isolates your application and allows for easy scalability of the system. In other, less technical words: Take all the code and configuration files we’ve written so far and put them in a box and put them to run, that is a dyno.

Now to see if your API is actually working we can (in this case) open a browser and access https://dontpanicapi.herokuapp.com/ or use the command line to open app URL in the browser:

heroku open

If everything went well you will see something like this:

What happened was the following: when accessing the URL of the application in Heroku, the browser does a GET request for API with the standard header, that is, without an Authorization field.

We could achieve the same result by running the following command on the terminal:

curl -X GET -k -i 'https://dontpanicapi.herokuapp.com/'

That gives me this result:

Now as we know, this API of ours will have a different response if you pass the Authorization header with the value of 42, so let’s make the request:

curl -X GET -k -H 'Authorization: 42' \
    -i 'https://dontpanicapi.herokuapp.com/'

And checking out the result:

Can you pass the authorization header on the browser? You totally can! But I’ll explain how to do this that in another post/tutorial that I promise to link here when finish writing.

Pro tip: Log files

Let’s say that you have made a mistake in the process of configuring your application and, when deploying, Heroku warns you that it was unsuccessful attempt. In this case the first place to look for information about what went wrong is the logs.

A good system logs all actions performed. In this case, Heroku takes care of logging all the details for us, so let’s ask for the logs using the CLI. Here I still write the logs in a file to facilitate inspection, see:

heroku logs > out.log

Examples of lines you will find in one of these logs:

2021-02-15T00:56:46.708128+00:00 heroku[web.1]: Starting process with command `python dont_panic.py`
2021-02-15T00:56:50.825880+00:00 app[web.1]: * Serving Flask app "dont_panic" (lazy loading)
2021-02-15T00:56:50.825954+00:00 app[web.1]: * Environment: production
2021-02-15T00:56:50.826115+00:00 app[web.1]: WARNING: This is a development server. Do not use it in a production deployment.
2021-02-15T00:56:50.826237+00:00 app[web.1]: Use a production WSGI server instead.
2021-02-15T00:56:50.826326+00:00 app[web.1]: * Debug mode: off
2021-02-15T00:56:50.831184+00:00 app[web.1]: * Running on http://0.0.0.0:13487/ (Press CTRL+C to quit)
2021-02-15T00:56:51.000000+00:00 app[api]: Build succeeded
2021-02-15T00:56:51.851660+00:00 heroku[web.1]: State changed from starting to up
2021-02-15T00:58:45.102206+00:00 app[web.1]: 10.47.180.171 - - [15/Feb/2021 00:58:45] "GET / HTTP/1.1" 200 -
2021-02-15T00:58:45.103509+00:00 heroku[router]: at=info method=GET path="/" host=dontpanicapi.herokuapp.com request_id=9df2f453-77e4-4b63-94
30-c88e0a27206b fwd="186.209.20.97" dyno=web.1 connect=0ms service=7ms status=200 bytes=173 protocol=https

Now if someone says “Deploy the API!” you already know how to do it 😉

PS.: If you have questions or comments, leave them below or send me a message I promise to try to answer, the DMs that are always open

Fazendo deploy de uma API para o Heroku

Sun, 15 Apr 2018 00:00:00 +0000

Quer aprender a fazer deploy @? Vem que eu te ensino!

O que você vai encontrar nesse tutorial

Como criar uma aplicação Flask nos moldes do Heroku
Como fazer deploy
Um pouquinho de Git
Um pouquinho de consumo de API

Avisos: Dos dois posts que eu usei de base para escrever esse aqui, um deles era muiiiito antigo e o outro, apesar de recente, não tinha instruções que correspondem a versão mais atual do Heroku, eles estão na sessão de links para quem quiser lê-los.

Heroku quem?

Se você chegou até aqui, é provável que você já saiba o que o Heroku é, mas pra quem ainda não sabe, Heroku é uma plataforma na nuvem que permite que pessoas “transformem suas ideias o mais rápido possível em uma URL” e sem ter dores de cabeça com a parte de infraestrutura.

Essa plataforma provê um serviço que, a partir de uma estrutura pré-definida de uma aplicação, consegue empacotar essa aplicação e colocar ela pra rodar num servidor em um dos data centers deles. O Heroku aceita aplicações escritas em várias linguagens, mas hoje vamos usar Python

Resumo:

Partiu código!

Pra esse tutorial eu fiz uma API em um microframework Python chamado Flask. Não irei explicar em detalhes como o Flask funciona, mas se você quiser aprender sobre isso, o Bruno Rocha tem um conjunto de posts chamado “What the Flask” que explicam super bem e estão todos lá nos links.

Nossa API

Ela terá apenas um endpoint definido pelo /. Esse endpoint poderá dar duas respostas dependendo da requisição que você faça. São eles:

Requisição	Resultado
GET sem cabeçalhos (headers) extras	Não entre em pânico!
GET com Authorization 42	a resposta para a vida, o universo e tudo mais

O código pra fazer isso fica pequeninho, dá uma olhada:

import os
from flask import Flask, jsonify, request


app = Flask(__name__)

@app.route('/')
def nao_entre_em_panico():
    if request.headers.get('Authorization') == '42':
        return jsonify({"42": "a resposta para a vida, o universo e tudo mais"})
    return jsonify({"message": "Não entre em pânico!"})

if __name__ == "__main__":
    port = int(os.environ.get("PORT", 5000))
    app.run(host='0.0.0.0', port=port)

Esse código fica dentro de um arquivo chamado aqui de nao_entre_em_panico.py mas você pode nomear da forma que você achar melhor. Além disso, esse código tem uma peculiaride: as três linhas finais, elas servem para configurar o servidor Flask quando ele estiver rodando no Heroku.

Pipfile

Lembra que eu falei lá no começo que os posts base eram antigos? Pois bem, hoje o Heroku exige um Pipfile para preparar o ambiente em que a nossa aplicação vai rodar. O Pipfile vai servir para instalar as bibliotecas Python necessárias para rodar a nossa aplicação. Se você, assim como eu, não gosta de usar o Pipenv - desculpa Cássio - dá pra criar o arquivo na mão, como criei o meu abaixo:

[[source]]

url = "https://pypi.python.org/simple"
verify_ssl = true

[packages]

Flask = "*"

[requires]

python_version = "3.6"

Para desenvolver (preparar o ambiente local) eu gosto do bom e velho requirements.txt que fica assim:

click==6.7
Flask==0.12.2
itsdangerous==0.24
Jinja2==2.10
MarkupSafe==1.0
Werkzeug==0.14.1

Procfile

No nosso computador, para rodar (colocar de pé) a nossa API o comando é o seguinte:

FLASK_APP=nao_entre_em_panico.py flask run

Como não será você quem irá executar um comando pra colocar a API de pé, você vai precisar de um arquivo que vai dizer “Coloca a API de pé aí” para o Heroku, esse arquivo é o Procfile.

Uma atençãozinha especial para um detalhe: esse arquivo não possui extensão, dependendo do seu sistema operacional e seu editor de texto, na hora de salvaer esse arquivo pode aparecer uma extensão .txt nesse arquivo e isso vai causar uma falha no nosso deploy então, lembre-se de remover a extensão do arquivo caso ela apareça ;)

Para esta aplicação, o Procfile vai ter uma linha só que é a seguinte:

web: python nao_entre_em_panico.py

Tá beleza, e o que mais?

Versionamento

Como o Heroku funciona com o sistema de versionamento Git, independentemente de você hospedar ou não o código no GitHub, nós precisamos criar nosso histórico de versão para a aplicação.

Então, depois de criar todos esses arquivos aqui de cima, você precisa adicionar tudo isso na sua árvore Git. Se você não é lá muito fã de Git pode fazer o seguinte:

$ git init
$ git add .
$ git commit -m "criando a aplicação"

Essa sequência de comandos acima vai colocar todos os arquivos num mesmo commit, isso não é uma boa prática e caso esteja interessada(o) em boas práticas lá no fim do desse tutorial vai ter links sobre isso.

3, 2, 1… Deploy \o/

Agora você tem uma escolha: existem algumas formas de enviar o seu código para o Heroku. Você pode connectar com o GitHub ou com Dropbox ou ainda usar o Heroku CLI. Nesse post nós vamos fazer da última forma.

Então, pra começar você precisa instalar o Heroku CLI.

Começando pelo login:

$ heroku login

Esse comando vai te pedir para digitar e-mail e senha de acesso da sua conta no Heroku:

Tela de login da CLI do Heroku

Criando uma aplicação

Usando a interface

É possível criar uma aplicação pela interface do site, onde você vai ver a seguinte tela:

Depois disso você ainda precisa adicionar o remote do Heroku no nosso repositório:

heroku git:remote -a guiaapi

E olha como é a resposta desse comando:

Usando o terminal

Mas também podemos criar a aplicação usando a CLI do Heroku. O lado bom de usar a CLI é que ao criar a aplicação o remote é criado automaticamente:

heroku apps:create guiaapi

O que deve mostrar algo assim ó:

Pausa para mais um momento de atenção: desse jeito que eu mostrei aí em cima, a gente consegue nomear nossa aplicação dentro do Heroku, aí que entra uma “pegadinha”, o nome da minha aplicação tem que ser única dentro do Heroku, pois é o nome da aplicação que é usado para criar a URL dela, se você por acaso tentar criar uma aplicação com um nome já utilizado, a resposta para o comando acima vai ser esta:

Se o nome da sua aplicação não for algo importante, você pode executar o seguinte comando no lugar do comando anterior:

heroku create

Esse comando vai criar uma aplicação com um nome randomizado, por exemplo:

Depois de criada a aplicação, você pode dar uma espiada lá na dashboard do Heroku na área de aplicações para ver a lista das suas aplicações:

Finalmente fazendo o bendito deploy

Depois de commitar tudo, fazer login e criar a sua aplicação no Heroku chegou a hora do deploy.

A ação de fazer o deploy, aqui nesse contexto, significa enviar o código da aplicação para o servidor e rodar o processo para colocar nossa API de pé no servidor.

Outros contextos podem trazer variações e passos intermediários desse que estou apresentando, mas aqui como nossa aplicação é simples e o Heroku é feito para nos ajudar a colocar aplicações de pé, o maior trabalho se torna a criação dos arquivos de configuração (que já criamos) ;)

Então, o comando que vai executar o envio do código para o servidor é:

git push heroku master

Em caso de sucesso você deve ver algo parecido com isso:

Uma última configuração que pode ser necessária fazer é garantir que a nossa aplicação tem pelo menos um dyno rodando com o seguinte comando:

heroku ps:scale web=1

Dynos

E o que é um dyno? Em resumo um dyno é um Linux Container, o Heroku utiliza um modelo de container que isola a sua aplicação e possibilita a fácil escalabilidade do sistema. Em outras palavras menos técnicas: Pega todos os arquivos de código e configuração que escrevemos até agora e enfia num caixa e bota pra rodar, isso é um dyno.

Agora pra ver o resultado da sua API podemos (nesse caso) abrir um navegador e acessar https://guiaapi.herokuapp.com/ ou usar a linha de comando pra abrir a URL direto:

heroku open

Se deu tudo certo (e você usar o Firefox como navegador) você verá algo assim:

O que aconteceu foi o seguinte: ao acessar a URL da nossa aplicação no Heroku nós fizemos uma requisição GET pra API com o cabeçalho (header) padrão, ou seja, sem o campo Authorization. Que seria a mesma coisa que rodar no terminal, isso aqui em baixo:

curl -X GET -k -i 'https://guiaapi.herokuapp.com/'

Que me dá este resultado:

Como sabemos, essa nossa API vai ter uma resposta diferente se você passar o cabeçalho Authorization com o valor de 42, veja:

curl -X GET -k -H 'Authorization: 42' \
    -i 'https://guiaapi.herokuapp.com/'

Temos o seguinte resultado:

Dá pra passar o cabeçalho de autorização no navegador? Dá! mas vou deixar isso pra outro post/tutorial que eu prometo que linko aqui quando escrever.

Pro tip: Arquivos de log

Pode ser que você tenha cometido alguma falha no processo de configuração da sua aplicação e, na hora do deploy, o Heroku avise que ele foi mal-sucedido. Nesse caso o primeiro lugar para procurar informações do que deu errado são os logs.

Um bom sistema faz logs de todas as ações executadas. Nesse nosso caso, o Heroku se encarrega de logar todos os detalhes pra gente, então basta pedir esse log usando a CLI. Aqui eu ainda escrevo os logs num arquivo para facilitar a inspeção, veja:

heroku logs > out.log

Exemplos de linhas que você irá encontrar num desses logs:

...
2018-04-15T02:24:39.000000+00:00 app[api]: Build succeeded
2018-04-15T02:25:11.165813+00:00 heroku[web.1]: Starting process with command `python nao_entre_em_panico.py`
...
2018-04-15T02:52:20.075995+00:00 app[web.1]: 10.5.207.142 - - [15/Apr/2018 02:52:20] "GET / HTTP/1.1" 200 -

Agora se alguém falar “Faz um deploy ae!” você já sabe como ;)

Ps.: Se tiver dúvidas ou comenta ali em baixo ou me manda mensagem que eu tento responder, sem crise as DMs tão sempre abertas ;)

Brincando com o PostgreSQL

Sun, 08 Apr 2018 01:00:00 +0000

O que você vai encontrar nesse post

Como rodar um banco usando docker e docker-compose
Como rodar migrações nesse banco
Como interagir com esse banco por uma interface

Aviso inicial

Todo o código e estrutura que vou mostrar aqui está nesse repositório do GitHub.

Rodando o PostgreSQL no Docker

Pra começar você pode instalar o PostgreSQL na sua máquina seguindo as instruções do site oficial porém aqui vou mostrar como usar o Postgres dentro de um container Docker usando o Docker-Compose. Pra começar (se ainda não o fez) instale o Docker e o Docker-Compose TK na sua máquina. Depois disso, vamos precisar de um arquivo chamado docker-compose.yml contendo as seguintes linhas:

version: "3"
services:
  tad:
    image: postgres:9.6
    container_name: "postgres"
    environment:
      - POSTGRES_DB=tadpgweb
      - POSTGRES_USER=postgres
      - TZ=GMT
    volumes:
      - "./data/postgres:/var/lib/postgresql/data"
    ports:
      - 5432:5432

Vamos ver as configurações que esse arquivo traz:

Diretório de dados: quando esse container rodar vai existir um diretório data/ na sua pasta que irá ser mapeada para dentro do container e conterá todos os dados do PostgreSQL;
O nome do serviço: aqui chamado de tad;
A porta aberta: para que a gente acesse o banco precisamos mapear uma porta do container para a nossa máquina host. Por padrão vamos escolher a mesma porta que o PostgreSQL usaria se não estivesse rodando dentro do container;
O nome do banco: Aqui eu chamei o banco de tadpgweb;
Usuário do banco: no arquivo definimos o usuário do banco como sendo o postgres mesmo.

E agora para colocar nosso banco “de pé”, o seguinte comando num terminal bastará:

docker-compose up tad

Na primeira vez que rodamos esse comando, algumas coisas vão acontecer a começar pelo download da imagem do PostgreSQL na versão 9.6, a criação do diretório data/ para conter os dados do postgres e depois disso, a criação de um banco com as configurações do docker-compose.yml.

Migrações: de comer ou de passar no cabelo

Criar e apagar tabelas e colunas, entre outras alterações podem ser feitas por meio de migrações. Migrações não passam de arquivos que executam comandos no banco. Esses comandos podem ser de alteração nas estruturas do banco como criação e deleção de tabelas e colunas ou comandos de preenchimento de dados conhecidos como migrações de dados ou data migrations.

Aqui eu escrevi 4 migrações que vamos rodar e vou explicar uma a uma, então preparem-se para o curso curto e intensivo do básico de SQL ;P

A primeira migração, chamada de 001_create_table_up.sql e vai criar uma tabela clientes, com 3 colunas, a coluna id que é um sequencial que começa em um, a coluna nome que pode ter tamanho máximo de 250 caracteres e por último a coluna idade que aceita números, além disso essa migração também define que as colunas id e nome não podem ser nulas e a coluna id é chave primária da tabela clientes:

CREATE TABLE clientes (id serial NOT NULL, nome VARCHAR(250) NOT NULL, idade INTEGER, PRIMARY KEY (id));

Agora vamos supor que a tabela que criamos não precise de uma coluna idade, então criamos a migração 002_alter_table_up.sql para nos livrarmos dela:

ALTER TABLE clientes DROP COLUMN idade;

Além de não precisar da coluna nós vamos querer uma outra coluna chamada de endereco também com tamanho máximo de 250 caracteres, e foi o que fizemos na migração 003_alter_table_up.sql:

ALTER TABLE clientes ADD COLUMN endereco VARCHAR(250) NOT NULL;

E agora que temos uma estrutura pronta para armazenar dados vamos fazer umas inserções nessa linda tabela com a migração 004_data_migration_up.sql, essa migração cria três registros na tabela clientes fazendo INSERTS:

INSERT INTO clientes (nome, endereco) VALUES ('Umbrella Corporation', '545 S Birdneck RD STE 202B Virginia Beach, VA 23451');
INSERT INTO clientes (nome, endereco) VALUES ('OCP Omni Consumer Products', 'Delta City (formerly Detroit)');
INSERT INTO clientes (nome, endereco) VALUES ('Weyland-Yutani Corporation', 'Weyland-Yutani Corporation HQ, Tokyo');

Note que os nomes de todas as migrações terminam em up, isso por que, cada uma das migrações que você viu aqui, tem uma migração irmã que desfaz o que essa migração fez. Isso é uma boa prática de software ;)

Mas agora que nós temos essas migrações como aplicá-las ao nosso banco?

Primeiro vamos copiar as migrações pro lugar certo e depois “rodá-las” dentro do container:

sudo cp migrations/*up.sql data/postgres/
docker-compose exec tad psql -U postgres -d tadpgweb -1 -f /var/lib/postgresql/data/001_create_table_up.sql
docker-compose exec tad psql -U postgres -d tadpgweb -1 -f /var/lib/postgresql/data/002_alter_table_up.sql
docker-compose exec tad psql -U postgres -d tadpgweb -1 -f /var/lib/postgresql/data/003_alter_table_up.sql
docker-compose exec tad psql -U postgres -d tadpgweb -1 -f /var/lib/postgresql/data/004_data_migration_up.sql

A sintaxe SQL não é muito misteriosa, mas se você estiver um pouco enferrujada(o) existem vários materiais disponíveis por aí, dentre eles o material em português do Criar Web, o curso de SQL do codecademy e o tutorial de SQL do GeekForGeeks ambos em inglês.

Um cliente para interação com o banco

Existem muitos clientes/aplicações que podemos usar para interagir com um banco como o pgAdmin e a CLI psql. Quando rodamos nossas migrações usamos a PSQL para aplicar Além dessas, hoje vamos aprender a usar um cliente web chamado pgWeb.

Escrito em Go o pgweb é mais leve que as demais opções e permite fazer as operações mais básicas como aquelas das nossas 4 migrações. Primeiro instale da forma que preferir. Como eu tenho Go configurado no meu computador fui de go get mesmo:

go get github.com/sosedoff/pgweb

Agora para rodar basta pegar um terminal e rodar o seguinte comando:

pgweb

E o resultado será o seguinte:

Agora é só ir no seu navegador favorito e acessar http://localhost:8081/ e ver a telinha para conectar no banco:

Então é só preencher as lacunas:

e clicar em Connect para ser levado para a página:

Minhas coisas favoritas do pgweb

Apesar de não ser tão completo como um pgAdmin da vida, o pgweb traz todas as funções para um uso diário e rápido.

Execução de queries: `Query`

Com o pgweb dá até pra criar tabelas, mas dá também para fazer consultas mais simples como um SELECT e ver o resultado das consultas logo abaixo:

Além disso, a parte mais legal é inspecionar os detalhes de uma query clicando no botão Explain Query:

Inspeção de registros: `Rows`

Quer ver as linhas contidas em cada tabela? Clique na tabela no menu lateral esquerdo e clique na aba de Rows para mostrar os registros daquela tabela:

Uso de filtros: `Rows`

Ainda na aba Rows conseguimos ver e executar filtros simples como selecionar todas linhas que possuam id maior que 1 por exemplo:

Inspeção da estrutura da tabela: `Structure`

Para ver uma listagem completa da estrutura de cada tabela, novamente clique na tabela escolhida no menu à esquerda da tela e clique na aba Structure:

Histórico: `History`

Além disso, todas as ações que fizemos ficam registradas na aba de histórico History:

Legal né? Seja você iniciante em banco de dados procurando uma forma de colocar em prática os estudos ou alguém mais experiente fazendo testes pequenos e rápidos, taí uma forma alternativa de interagir com o banco ;)

Formatando código Go usando o próprio Go pra isso

Mon, 19 Mar 2018 05:00:00 +0000

Coisa linda de se ver é usar um formatador de código, principalmente quando você tem preguiça de ficar formatando coisas ou quando você está preocupada em aprender a sintaxe de uma nova linguagem e ainda não pegou o jeito com o estilo de código.

A colinha de hoje mostra como a linguagem de programação Go ajuda a formatar o código sem sofrimento.

Pra começar, é preciso entender que código bem formatado está na cultura da linguagem Go desde que ela nasceu, para os mais experientes isso nao passa de uma boa prática muito comum. Mas como fica isso na prática? Então vamos lá, vamos supor que você escreveu o seguinte código num arquivo chamado helloworld.go:

package main
import "fmt"
func main(){
fmt.Println("Hello world!")
}

Até aí tudo bem, esse código compila e se você fizer go run helloworld.go ele ainda escreve na tela o seu Hello World! porém, se você tivesse que mandar esse código para um projeto aberto, provavelmente pessoas revisando seu código iriam pedir para você formatá-lo melhor.

Existe um monte de ferramentas própria da linguagem para ajudar a pessoa que desenvolve, sendo uma delas o gofmt. Ele pode mostrar na tela a formatação indicada para um código fonte ou até mesmo formatar para você o código que você escreve. Para usar o gofmt basta passar o nome do arquivo para ele:

gofmt helloworld.go

Isso irá escrever na tela a versão formatada do seu código fonte. Existem algumas flags que você pode usar para mudar esse resultado. Por exemplo, a flag -d irá mostrar um diff do seu arquivo num formato idêntico ao git diffótimo para envio de patches.

Mas a flag/opção mais interessante é a -w que converte a impressão na tela para escrita em arquivo. Nesse caso, se você utilizar essa flag assim:

gofmt -w helloworld.go

Nada será printado na tela e o código formatado será escrito no seu arquivo fonte, então aquele código que eu mostrei no início, após a execucção com a flag -w fica assim:

package main

import "fmt"

func main() {
        fmt.Println("Hello World!")
}

Massa né? Agora não tem mais desculpa pra não formatar os códigos bonitinhos 😜

Agradecimentos

Principalmente ao Cesar que pacientemente tem me ensinado Go.

Gerando chaves das APIs do Google

Mon, 15 Jan 2018 01:00:00 +0000

Hoje em dia é sempre API isso ou API aquilo. APIs nada mais são do que uma forma de acessar dados e/ou serviços por meio de um programa. Mas pra acessar APIs como as do Google você vai precisar de uma chave. Esse tutorial de hoje vai ensinar você a criar uma chave do Google e ativar uma das APIs do Google para usá-la. Lembrando que os passo a seguir são para criação de chaves para uso próprio, chaves para aplicações web e outras aplicações pode ter passos diferentes ;)

Vamos lá!

Começando

Pra começar acesse o painel de desenvolvimento do Google. Ele deve ter uma carinha parecida com essa aqui:

Criando um projeto

Para criar uma ou mais chaves, você precisa ter um projeto. Toda e qualquer chave de API do Google precisa de um projeto para existis. Então vamos começar criando um desses. Clique em Criar projeto:

Depois em criar:

E então escolha um nome para o seu projeto e clique em criar:

Ao clicar em criar você voltará para o painel:

Notou como não tem mais o aviso de “está faltando projetos”?

Criando uma chave

Agora no menu a esquerda da tela clique em Credenciais

para acessar o painel de chaves.

É nessa parte que no futuro vão ser listadas todas as chaves que você gerou para aquele projeto. Agora clique no botão Criar credenciais bem no centro da tela:

Esse botão vai mostrar algumas opções, dentre elas a que nós queremos se chama “Chave de API”:

Ao clicar nela irá abrir uma janelinha com a sua chave (aqui editada por motivos de segurança):

Uma coisa que você vai querer fazer aqui é clicar no botão de copiar que aparece no final da chave de API (afinal você provavelmente ta criando a chave para usá-la). Depois é clicar em fechar para voltar para o painel de credenciais que agora tem uma lista de um item yaaayy \o/ e deve ser algo mais ou menos assim:

Ativando uma API

Agora o próximo passo é escolher uma API na biblioteca das APIs disponíveis. Comece escolhendo a opção Bibliotecas naquele menu lateral esquerdo:

Você pode passear pelas bibliotecas disponíveis nesse painel que irá aparecer:

Ou procurar por uma API específica, nesse caso a do YouTube:

Eu escolhi aqui a API de dados do youtube (a primeira da lista acima), e cliquei nela, o que me levou para a seguinte página:

Nessa página encontramos algumas informações sobre essa API, incluindo links para tutoriais de como utilizá-la. Mas o que nos interessa de verdade nessa página é clicar no botão de ativar:

Ao clicar em ativar, somos levados para o painel da API, é nesse painel que você acompanha várias métricas do uso dessa API.

The end

Sim, cabou já da pra usar :P

Perguntas

Posso usar uma chave só para várias APIs? Pode! Não vai dar problema nenhum. Afinal quem decide qual API usar é a sua aplicação/ seu programa ;)
Se eu posso usar a mesma chave pra várias APIs pra que eu vou criar outras? Vamos supor que você tem vários scripts/projetos/apps que fazem requisições para APIs do google, facilita um pouco a vida se você conseguir apagar uma chave de um app que você não quer que tenha acesso a API do google não é mesmo?
Posso mandar minha chave de API pra um coleguinha? Poder você pode, mas não deve né? Importante cuidar da segurança, já imaginou se esse coleguinha começa a fazer requisições sem controle pra API do google? A conta do cartão vai chegar alta no fim do mês.
Eu não preciso me cadastrar em nada? Não, acessando o console estando logado na sua conta do Gmail você já tem acesso a parte free das APIs.

Agradecimentos

Ao querido Cássio Botaro que deu essa ideia de tutorial <3

Comandos Docker

Sun, 14 Jan 2018 08:00:00 +0000

Se você lida com Docker diariamente é necessário saber alguns comandos. Se você for feito eu que esquece essas coisas, aqui vai uma colinha pra ajudar ;)

Listando

Imagens na sua máquina

Lista todas as imagens da sua máquina inclusive as penduradas (dangling)

$ docker images -a

Containers em execução

$ docker ps

Todos containers

E suas informações

$ docker ps -a

Apenas os IDs de todos os containers

$ docker ps -qa

Removendo

Um container que foi parado

$ docker rm ID

Todos containers que foram parados

$ docker rm $(docker ps -qa)

Uma imagem do sistema

Se a imagem nao estiver em uso, você pode removê-la usando o comando abaixo e a ID da imagem

$ docker rmi ID

Todas imagens do sistema

Remove TODAS as imagens Docker que não estiverem em uso da sua máquina. Use com cuidado!

Irá mostrar um erro caso alguma imagem esteja em uso.

$ docker rmi $(docker images -qa)

Todas imagens do sistema

Remove TODAS as imagens Docker que não estiverem em uso da sua máquina. Use com cuidado!

Irá ignorar imagens em uso uso.

$ docker system prune --all

Matando

Um ou mais containers

Basta passar uma lista de IDs para matar mais do que um container

$ docker kill ID

Alguns opções válidas de conhecer

-a

Maioria, se não todos, os comandos e subcomandos do Docker possuem uma opção -a que vem de all todos.

–rm

Mesma coisa coisa acontece com a opção --rm. Quando usada ela indica que o container deverá ser removido após sua execução

-q

Maioria, se não todos, os comandos e subcomandos do Docker possuem uma opção -q que lista apenas os IDs

Dependências de projetos Ruby: Gemfile

Sat, 13 Jan 2018 08:00:00 +0000

Depois de ensinar a colocar um site no ar usando o Jekyll. Vou responder uma pergunta que me fizeram: “Meu tema não tem uma Gemfile, e agora?” A colinha de hoje ensina o que fazer.

O que é uma Gemfile?

Bem antes de explicar o que é esse arquivo você precisa entender um pouquinho sobre projetos Ruby. Cada projeto, idependente da linguagem que você está usando, geralmente tem uma lista de dependências que são necessárias para esse projeto rodar. No caso de projetos Ruby, essa lista o gerenciamento de dependências é feito usando um sistema conhecido como Gemfile.

Cada pacote/biblioteca que você instala para ser usado pelo seu projeto é uma gem. Assim como o próprio Jekyll é uma gem, você pode precisar por exemplo de plugins Jekyll para fazer coisas coisas no seu site como paginar as postagens, incluir SEO e até construir automaticamente um feed XML. Para instalar e gerenciar tais plugins usa-se o Gemfile.

Meu tema não tem uma Gemfile

No tutorial eu usei o tema Fresh que já vem com uma Gemfile pronta. Mas e se eu escolher um tema sem uma Gemfile? Como que funciona?

Para começar, o comando bundle install não irá funcionar. Esse comando busca a Gemfile para instalar as gems do projeto. Da mesma forma também não funcionará o comando bundle exec jekyll serve.

Hoje eu vou ensinar como criar uma Gemfile, ou viver sem ela, para exemplificar os passos de hoje vou usar o tema Wall-E (linkei o meu fork do tema pois o original acabou de ganhar um PR com uma Gemfile hihi).

$ git clone git@github.com:jtemporal/Wall-E.git
$ cd Wall-E/

bundle install falhando

Se não da pra iniciar o servidor usando o bundle, a alternativa é fazê-lo usando o Jekyll purão mesmo:

$ jekyll serve

jekyll serve falhando

É nessa hora que você começa a perceber como seria legal ter uma Gemfile. Se você tem ela fica muito mais fácil começar a rodar o projeto. Pra resolver esse erro basta fazer os seguintes passos:

$ gem install jekyll-gist
$ jekyll serve

E acessar localhost:4000.

Uma forma de saber quais gems instalar antes de rodar o servidor é checar as gem necessárias para o tema no arquivo _config.yml na tag plugins:

plugins: [jekyll-gist]

A tag plugins traz a lista de gems necessárias para aquele projeto Jekyll.

Criando a sua Gemfile

Tá eu já sei rodar um projeto sem Gemfile e sei instalar as gems na mão, mas não quero ficar fazendo isso, então como que eu crio uma Gemfile?

Comece criando um arquivo chamado Gemfile no root do projeto:

$ touch Gemfile

Nesse arquivo você vai listar todas as dependências, inclusive o próprio Jekyll:

source "https://rubygems.org"

gem "jekyll"
gem "jekyll-gist"

Assim é só executar:

$ bundle install
$ bundle exec jekyll serve

E seguir fazendo os posts ;)

Ruby Project Dependencies: Gemfile

Sat, 13 Jan 2018 07:59:00 +0000

Author note: Leia este artigo em Português.

After teaching how to get your website online (in Portuguese) using Jekyll. I’m going to use today’s pro-tip to answer a question somebody asked me: “My theme doesn’t have a Gemfile, now what?”

What is a Gemfile?

Before explaining what this file is, you need to understand a little bit about Ruby projects. Usually, each project, independent of the language you are using, has a list of dependencies that are required for the said project to run. For Ruby projects, this dependency management list is made using a system known as Gemfile.

Each package/library you need install to run your project is called a gem. Just as Jekyll itself is a gem, you may need, for example, some plugins to add some features on your site such as paginating post lists, including SEO, and even automatically building an XML feed. To install and manage such plugins, we use a Gemfile.

My theme does not have a Gemfile

For the tutorial linked at the beginning of this post, I used the Fresh theme. It already comes with a Gemfile. But what if I had chosen a theme without a Gemfile?

For starters, the bundle install command would not work. This command uses the Gemfile to install the project required gems. Similarly, the bundle exec jekyll serve command won’t work either.

Let’s see how to create a Gemfile, or live without it, to exemplify today’s steps I will use the Wall-E theme (I linked the fork I made because after this post I made a pull request adding a Gemfile to the theme ¯\_(ツ)_/¯).

$ git clone git@github.com:jtemporal/Wall-E.git
$ cd Wall-E/

bundle install failing

If you can’t start the server using bundle, the alternative is to do it using pure Jekyll:

$ jekyll serve

jekyll serve failing

This is when you begin to realize how cool it would be to have a Gemfile. It is much easier to run the project when you have a dependency file. To fix this error, do the following steps:

$ gem install jekyll-gist
$ jekyll serve

Now you can access localhost:4000.

One way to know which gems are needed before running the server is to check the necessary gems for the theme in the _config.yml file in the plugins tag:

plugins: [jekyll-gist]

The plugins tag lists the gems needed for that Jekyll project.

Creating Your Gemfile

Now you know how to run a project without Gemfile, and you know how to install gems by hand, but doing this every time is annoying, so let’s create a Gemfile. Start by creating a file called Gemfile in the project root:

$ touch Gemfile

In this file you will list all dependencies, including Jekyll himself:

source "https://rubygems.org"

gem "jekyll"
gem "jekyll-gist"

Then you can do the following:

$ bundle install
$ bundle exec jekyll serve

All is set, and you enjoy your project 😉

Publishing your own website with Jekyll

Sun, 07 Jan 2018 10:00:00 +0000

In a pro tip, I talked about how using Jekyll is an excellent idea to get your site online. In this tutorial, we will deploy a website using GitHub, Jekyll, and the terminal.

Choosing a theme

The first step is to go to Jekyll Themes and choose a theme you like. For this tutorial, I choose Fresh, a blog theme, with not only the posts listing but also some extra pages like “About” and “Contact”. It’s responsive, which is a significant feature if you take into account that much content today is consumed via mobile devices. Take a look at Fresh’s Demo:

Preparing the environment

You’ll need to install (if you haven’t already) the following list of requirements:

Ruby
Jekyll
Git
Gem

Keep in mind that the next steps are tailored for my operating system (Elementary OS), so you may need to adapt those steps for your OS.

Edit: If you are following this tutorial on macOS Catalina, feel free to skip the installation steps below.

Installing our requirements:

$ sudo apt install git
$ sudo apt install ruby-full
$ sudo apt install rubygems       # ou rubygems-integration
$ gem install jekyll bundler

Why do we need all this?

git: We’ll use GitHub to host our site, and we need git to do that;
ruby-full: A more stable old version of Ruby. Since Jekyll is a Ruby-built tool, we need it installed on your computer for Jekyll to work;
rubygems: Just like Python’s pip and Node’s npm, there is gem for Ruby dependencies. It’s a package manager, and a necessary requirement it to install Jekyll and the other packages for Fresh to run;
jekyll: The static site generator;
bundler: Is the “inception” of packages, it is a package that controls other packages, it controls versions of packages and their dependencies on projects.

Downloading the theme

For those who are already used to Git, I think this part will be quite straightforward. The link to the repository is this one. For those who are not used the steps are these:

$ git clone https://github.com/artemsheludko/fresh.git

Note: Here, I prefer to clone on purpose, but for those who are more intimate with Git and its processes, you can go ahead and fork it. In this tutorial, I’m cloning it because sometimes, when opening a pull request, you might end up opening one to the original repository instead of your own copy. To avoid that, and make things easier for git beginners, let’s go with cloning.

Running the project

After cloning is time to run this, right?! The steps below will serve your site locally:

$ cd fresh
$ bundle install
$ bundle exec jekyll serve

Note: if by any chance you don’t have a Gemfile in the theme you picked, the bundle install step won’t work, I recommend you read this Gemfile pro-tip to understand a little bit more about Gemfiles and how to create your own.

Note 2: If you following this tutorial on macOS Catalina you may run into a Invalid date error, this pro-tip explains how to fix it.

Now go to your favorite browser and go to http://localhost:4000/fresh/. Cool, huh?! 🎉

All right, let’s understand what we just did:

bundle install: This command will look in your Gemfile and Gemfile.lock for package names and versions to install the necessary dependencies to run the project, that’s why if you don’t have a Gemfile this step doesn’t work;
bundle exec jekyll serve: This is the command runs the Jekyll server allowing you to see your site on your browser. Every time you run this command, the site is built.

To stop the server just hit Ctrl + c, you will need the server offline for the configuration steps.

Configuration file

Let’s start with the configuration. Most themes rely on the configuration file to “fill the blanks” on the site. This makes the templates easily adaptable; you just have to change the _config.yml to change things such as the site title, author, and so on.

Open the _config.yml file in your favorite editor, and let’s update it. To see changes to the site, whenever you change _config.yml, you’ll need to stop and restart the Jekyll server. Since the server relies on the configuration file to build everything, this is the only file that you need to restart the server every time you want to see the changes you made take place.

Profile Info

In this part goes the initial information:

The title (title): The name that appears when you open a tab in the browser;
Name (name): usually something descriptive of what your blog is about;
The description (description): which goes inside the HTML and when someone shares your blog is this description that appears, it also helps to put your site in search results like Google and DuckDuckGo;
The page (baseurl): From which link your site is served, the path to your home
The URL (url): This is where the domain goes, may it be the one that GitHub Pages makes available (username.github.io) or one that you will buy (as is my case here).

Edit this first block for something like this:

# Profile information
name: Contos # Tales
title: Um blog com Jekyll # a jekyll blog
description: >
    Uma coleção de contos
    # A collection of tales
permalink: ':title/'
baseurl: "/blogfresh" # the subpath of your site, e.g. /blog
url: "http://jtemporal.com" # the base hostname & protocol for your site, e.g. http://example.com

Rerun the bundle exec jekyll serve command. This time the site you need to access changed because we changed baseurl to /blogfresh. Now go to http://localhost:4000/blogfresh/ to see the changes. With these changes in _config.yml, the site should look something like this:

This is where the links to your social networks come from. The ones you don’t want to make available just don’t fill out. Let’s fill the values for the ones I want:

# Social
facebook: #Add your Facebook
twitter: #Add your Twitter
google-plus: #Add your Google+
github: @jtemporal

Unfortunately, this theme does not “hide” the buttons for social networks that do not have a valid username/link. I’ll write a post on how to do that soon.

Contact Form

If you want people to contact you through the site contact form, just uncomment them and put your email address in place of your-email@domain.com. Since I do not like receiving emails, I left it commented ¯\_(ツ)_/¯.

# Contact form
email: #your-email@domain.com

Comments

That’s a fun part, comments on your posts! If you don’t know Disqus yet, it’s a platform that helps increase engagement on your site. It allows people to comment on your blog in a relatively easy way. Create an account and place your identifier here:

# Comments
discus-identifier: jtemporal

After restarting the server for the configuration file changes to take effect, you should have an area that looks like the image below at the end of each post:

Pagination

This is where you define how many posts appear per page on your site:

Posts per page (paginate): how many blog posts appear on each page;
Page URL (paginate_path): This variable defines how the URLs of a specific page will be generated, for example, blog/page2/index.html.

# Paginate
paginate: 5
paginate_path: /page:num/

Build settings

Here you will not need to change anything, but it is good to understand what each of these things means, right?!

Markdown Renderer (markdown): Here, you can choose which Markdown renderer to use. The default is kramdown;
Gems needed for this theme (gems): here is a list of gems that need to be installed;
Exclude directories and files (exclude): These are files and directories to be disregarded when generating site pages;
Include files and directories (include): These are files and directories to consider when building site pages; if you want to serve a file, let’s say a PDF file, you must include it in this list.

# Build settings
markdown: kramdown
gems:
  - jekyll-feed
  - jekyll-paginate
exclude:
  - Gemfile
  - Gemfile.lock
include: [_pages]

When you finish fixing _config.yml, remember to commit the changes! Committing everything is a necessary step to guarantee that what you see on your computer is what everyone accessing your site on the internet is seeing. I will assume you’ll commit every step from now on 😉

Posts

Fresh, as well as all other themes available, provide examples of posts. The first thing you’ll notice when opening one of them in the text editor is that it has a kind of header known as Front Matter. We use the Front Matter to set values to things like the post title, date of publication, and so on.

Understanding the Front Matter

layout: Jekyll sees all blog pages as a blog post that it needs to render, including About, Contact and Home pages, so the layout tag is used to differentiate rendering, the options for fresh are: post or default;
title: The title of the post;
date: The date and time of publication following YYYY-MM-DD HH:MM:SS format. You can still set the time zone of the article using this field;
description: Each blog post can have a synopsis paragraph in the post listing. This is where this synopsis goes.

First post

Let’s create a new post from scratch and put it on the site. Create a file inside the _posts directory:

$ touch _posts/2018-01-07-hello-world.md

It is customary to use the pattern YYYY-MM-DD-post-name.md in file names. Remember that it is from the filename that the URLs will be generated for each post, so choose your file names carefully.

Open the file we just created, paste the following Front Matter and content:

---
layout: post
title:  "Olá mundo"
date:   2018-01-07 00:00:00
description: Primeiro blogpost
---

Olá mundo!

If the Jekyll server is not running, start it. If you already got the server running after you create and save the file, Jekyll will automatically generate the HTML of this new post. Go to the browser and reload the page. Et voilà!

Remember to commit this file.

Publishing the site

Well, since at the beginning of this tutorial, we did a git clone, all links from this repository are with the parent repository. What does that mean? Git repositories communicate with GitHub (or any other provider) through what we call a remote. I will not go into details of how remotes work in this post, but you can read more about it in the official Git documentation.

Here we will do some steps through the GitHub site, others in the terminal to make sure you can publish your code to the correct repository.

Terminal: First stage

The terminal commands happen in two phases, the first one here is to rename the remote from the original repository to upstream this is useful as you can use upstream to update your theme code.

$ git remote rename origin upstream

After that, we should open the GitHub interface on the browser.

GitHub

I’m considering you already have a GitHub account, if you don’t have an account, create one, it’s quick. For the following steps, I will show you two versions, one for those who already have a website published (like me) and one for those who are publishing a website for the first time. Follow the steps which best describe your setup.

My first website

Creating a new repository because this is your first site on GitHub, this repository needs to have a unique name following the pattern my-username.github.io:
Copy the instructions that come in the ...or push an existing repository from the command line:

I already have a website

For those who already have a website on GitHub, this new repository will be one page of your current site. For example, I have this site here http://jtemporal.com, and this new blog will become this page http://jtemporal.com/blogfresh. The same pattern repeats if you don’t have a custom domain, your site will look something like https://jtemporal/github.io/blogfresh. The steps:

Create a new repository: follow the image below, you do not need to configure anything else, and remember that here I gave the same name that is in my baseurl there in _config.yml:
Copy the instructions that come in the ...or push an existing repository from the command line area:

Terminal: Second stage

Now that we have a place to send the code, we go back to the terminal to complete the second stage of the terminal commands and send our code to GitHub to actually get the site online. Paste the commands you copied from the GitHub interface:

$ git remote add origin git@github.com:jtemporal/blogfresh.git
# ou: git remote add origin git@github.com:jtemporal/jtemporal.github.io.git
$ git push -u origin master

GitHub: The Return

After sending the code to GitHub, we need to configure the site through the GitHub interface! Let’s start by going to the repository Settings tab:

Scrolling down on the settings page, you’ll see the GitHub Pages section. It is this section that we use to publish the site:

When None is selected in the Source area, GitHub Pages is disabled. So let’s choose a branch to publish our website from, in this case, the branch will be the master itself:

And now click on Save:

And the result will look something like this:

Just access the site link in the blue notification, and that should take you to your site 😉

And now what? Well, now you can start writing other posts and committing them. Every commit/pull request to master will automagically execute the site build and deploy steps. Happy blogging! 🎉

Links and Considerations

There are other ways to install Ruby on your machine, find them listed in the Ruby documentation.
Bundler.
I used Git commands for SSH keys if you prefer you can use the same commands using HTTPS access, adjust accordingly. If you want to use SSH just like me you will need keys, these GitHub tutorials teach you how to generate and use them.

Colocando um site no ar com Jekyll

Sun, 07 Jan 2018 10:00:00 +0000

Numa colinha eu falei sobre como usar Jekyll é uma boa ideia para ter o seu site no ar vamos ao exemplo prático usando o terminal. O objetivo aqui é ter um site no ar, então vamos lá.

Escolhendo um tema

Vá até o Jekyll Themes e escolha um tema. Eu escolhi pra hoje o Fresh. Fresh é tema de um blog, com algumas páginas extras como “Sobre” e “Contato”. Além disso ele é responsivo, considerando que muito conteudo hoje é consumido pelos smartphones e tablets por aí essa é uma capacidade que queremos. Dá uma olhada na Demo do Fresh:

Preparando o ambiente

Precisaremos instalar (caso ainda não tenha) a seguinte listinha:

Ruby
Jekyll
Git
Gem

Os passos a seguir são para o meu sistema operacional (Elementary OS), tenha isso em mente quando for reproduzir os passos aqui, pois pode ser que tenha variações para o seu OS.

Vamos as intalações.

$ sudo apt install git
$ sudo apt install ruby-full
$ sudo apt install rubygems       # ou rubygems-integration
$ gem install jekyll bundler

Pra que tudo isso?

git: vamos precisar colocar o site no GitHub para servi-lo;
ruby-full: uma versão antiga mais estável do Ruby. Como Jekyll foi feita nessa lingaguem precisamos dela instalada no seu computador;
rubygems: Assim como o pip para Python e o npm para o mundo Node, existe o gem para ruby. Ele é um gerenciador de pacotes e ele que precisaremos para instalar jekyll e os demais pacotes para o Fresh;
jekyll: O pacote do momento;
bundler: No melhor esquema Inception o bundler é um pacote que controla outros pacotes, ele controla versões dos pacotes e suas dependências nos projetos.

Baixando o tema

Pra quem já tá acostumado com Git acho que essa parte vai ser tranquila. O link para o repositório é esse aqui. Pra quem não está acostumado os passos são esses:

$ git clone https://github.com/artemsheludko/fresh.git

Nota: Aqui eu preferi fazer um clone propositalmente, porém para aqueles mais íntimos do Git e de seus processos pode fazer um fork mesmo. Nesse caso escolhi o clone pois já vi (e já aconteceu comigo também) que ao tentar usar os bons hábitos de abrir pull requests na sua própria rotina de publicação, mandar o PR para o repositório original ao invés de fazer no seu mesmo.

Rodando o projeto

Depois de clonar é hora de colocar isso pra rodar né mesmo?! Então vamos lá, os passos abaixo vão deixar o seu site sendo servido localmente. Vamos a eles:

$ cd fresh
$ bundle install
$ bundle exec jekyll serve

Observação: se por acaso você não possui uma Gemfile no seu tema, os passos acima não vão funcionar, da uma lida aqui nessa colinha sobre a Gemfile pra entender um pouquinho mais sobre isso ;)

Agora vá até o seu navegador favorito e acesse http://localhost:4000/fresh/. Massa né?!

Muito bem, vamos entender o que acabamos de fazer:

bundle install: O bundle é um comando que vai procurar na sua Gemfile e a Gemfile.lock os nomes e versões dos pacotes para instalar as dependências necessárias para rodar projeto;
bundle exec jekyll serve: Esse aqui é o que faz o trabalho de ajustar o ambiente para rodar o servidor Jekyll. Além disso, toda vez que você roda esse comando é feito o build do site.

Para parar o servidor basta apertar Ctrl + c, você vai precisar disso para os próximos passos.

Arquivo de configuração

Vamos começar pela configuração pois, é no arquivo _config.yml que moram as informações como título do site, autor e por aí vai.

Abra o arquivo _config.yml no seu editor favorito e vamos alterar e entender ele aos pouquinhos. Para ver as alterações no site, sempre que você mudar o _config.yml você precisará parar e reiniciar o servidor do Jekyll.

Informações de perfil

Nessa parte vão as informações iniciais:

O título (title): que o nome que aparece quando você abre uma aba no navegador;
O nome (name): geralmente algo descritivo do que o seu blog vai abordar;
A descrição (description): que vai dentro do HTML e quando alguém compartilhar o seu blog é essa descrição que aparece, isso também ajuda a colocar o seu site nos resultados de buscas como Google e o DuckDuckGo;
A URL de base (baseurl): a partir de que link o seu site é servido, o caminho para a sua “home”
A URL (url): aqui é onde vai o domínio seja ele aquele que o GitHub Pages disponibiliza (username.github.io) ou um que você venha a comprar (como é o meu caso aqui).

Edite esse primeiro bloco para algo parecido com isso:

# Profile information
name: Contos
title: Um blog com Jekyll
description: >
    Uma coleção de contos
permalink: ':title/'
baseurl: "/blogfresh" # the subpath of your site, e.g. /blog
url: "http://jtemporal.com" # the base hostname & protocol for your site, e.g. http://example.com

Execute novamente o comando do servidor bundle exec jekyll serve. Dessa vez o site que você precisa acessar mudou pois mudamos o baseurl para /blogfresh. Agora acesse http://localhost:4000/blogfresh/ para ver as mudanças. Com essas alterações no _config.yml o site deve estar parecido com isso:

É aqui que vem os links para suas redes sociais. As que você não quiser deixar disponível basta não preencher. Eu vou ensinar como esconder os botões para as redes sociais que não tiverem um valor aqui em outro blog post, por enquanto vamos colocar apenas uma delas:

# Social
facebook: #Add your Facebook
twitter: #Add your Twitter
google-plus: #Add your Google+
github: @jtemporal

Infelizmente esse tema não “esconde” os botões para as redes sociais que não possuem um usuário/link válido.

Formulário de contato

Se você quiser que as pessoas entrem em contato com você pelo formulário de contato do site é só remover o comentário e colocar o seu e-mail no lugar de your-email@domain.com. Como eu não curto receber e-mail deixei comentado mesmo ¯\_(ツ)_/¯.

# Contact form
email: #your-email@domain.com

Comentários

Essa uma parte legal, comentários nos seus posts! Se você não conhece o Disqus ainda, ele nada mais é do que uma plataforma que ajuda a aumentar o envolvimento nos seus sites. Ele permite de forma relativamente fácil que pessoas comentem no seu blog. Crie uma conta e coloque o seu identficador aqui:

# Comments
discus-identifier: jtemporal

Após reiniciar o servidor para que as mudanças do arquivo de configuração façam efeito, você deve ter uma área paracida com a da imagem abaixo no fim de um post:

Paginação

É nessa seção que você define quantos posts aparecem por página no seu site:

Posts por página (paginate): quantos blog posts aparecem em cada página;
URL de uma página (paginate_path): essa variável define como vão ser geradas as URLs de uma página específica, por exemplo, blog/page2/index.html.

# Paginate
paginate: 5
paginate_path: /page:num/

Configurações de build

Aqui você não vai precisar mudar nada, mas é bom entender o que tá rolando né?!

Renderizador de markdown (markdown): aqui você pode escolher que renderizador de Markdown usar. O padrão é o kramdown;
Gems necessárias para esse tema (gems): aqui vai uma lista de gems que precisam ser instaladas;
Diretórios e arquivos para exclusão (exclude): esses são arquivos e diretórios para serem desconsiderados na hora de gerar as páginas do site;
Diretórios e arquivos para inclusão (include): esses são arquivos e diretórios para serem considerados na hora de gerar as páginas do site, se você quiser servir algum arquivo a partir do seu site você deve incluir ele nessa lista.

# Build settings
markdown: kramdown
gems:
  - jekyll-feed
  - jekyll-paginate
exclude:
  - Gemfile
  - Gemfile.lock
include: [_pages]

Ao terminar de arrumar o _config.yml lembre-se de commitar as mudanças! Vou assumir que você fez isso a cada passo daqui pra frente ;)

Posts

O Fresh, assim como todos os outros temas disponíveis trazem exemplos de posts. A primeira coisa eu você vai notar ao abrir um deles no editor de texto é que ele tem uma espécie de cabeçalho conhecido como Front Matter. Lá são definidos coisas como o layout do post, o título, a data de publicação e por aí vai…

Entendendo o Front Matter

layout: O Jekyll enxerga todas as páginas do blog como um blog post que ele precisa renderizar, inclusive as páginas About, Contact e Home então a tag layout é utilizada para diferenciar a renderização, as opções são: post ou default;
title: O título da postagem;
date: A data e hora da publicação no formato AAAA-MM-DD HH:MM:SS ainda é possível passar o fuso horário da publicação caso queira usando esse campo;
description: Cada blogpost pode ter um paragrafo de sinopse na listagem de posts. É aqui que essa sinopse vai.

Primeiro post

Vamos criar um post novo do zero e colocar no site. Crie um arquivo dentro do diretório _posts:

$ touch _posts/2018-01-07-ola-mundo.md

É costumeiro usar o padrão AAAA-MM-DD-nome-do-post.md nos nomes dos arquivos. Lembre-se que é apartir do nome do arquivo que vão ser geradas as URLs para cada post.

Abra o arquivo que acabamos de criar, cole o seguinte Front Matter e conteudo:

---
layout: post
title:  "Olá mundo"
date:   2018-01-07 00:00:00
description: Primeiro blogpost
---

Olá mundo!

Se o servidor Jekyll não estiver rodando, inicie ele. Se já estiver rodando ao criar e salvar o arquivo dê um tempinho para que ele possa gerar o HTML desse novo post. Vá até o navegador e recarregue a página. Et voilà!

Commite esse arquivo.

Publicando o site

Bom, como lá no começo fizemos um git clone todas as ligações desse repositório estão com o repositório inicial. Como assim? Os repositórios Git fazem comunicação com o GitHub (ou qualquer outra rede) por meio do que chamamos de remote. Não vou entrar em detalhes do funcionamento disso nesse post mas você pode ler mais sobre isso na documentação oficial do Git.

Aqui nós vamos fazer alguns passos, alguns deles pelo site do GitHub, outros no terminal mesmo.

Terminal: primeira fase

Os comandos do terminal acontecem em duas fases, a primeira é essa aqui que consiste em renomear o remote do repositório original para upstream isso é útil pois você pode utilizar o upstream para atualizar o código do seu tema.

$ git remote rename origin upstream

Depois disso vamos ao GitHub.

GitHub

Aqui, assumindo que você já possui uma conta no GitHub, caso não tenha é só criar, é rapidinho. Para os passos a seguir eu vou mostrar duas versões, uma para quem já tem um site publicado (como eu) e uma para quem está publicando um site pela primeira vez.

Meu primeiro site

Criar um repositório novo como esse é o seu primeiro site, esse repositório precisa ter um nome especial seguindo o padrão meu-nome-de-usuario.github.io:
Copiar as instruções que vem na área ...or push an existing repository from the command line:

Já tenho um site

Pra quem já tem um site no GitHub, esse novo site vai ser uma página do seu site atual. Por exemplo, eu tenho esse site aqui http://jtemporal.com e esse blog novo vai virar http://jtemporal.com/blog. O mesmo padrão se repete se você não tiver um domínio personalizado, seu site ficará algo tipo https://jtemporal/github.io/blogfresh. Vamos lá:

Criar um repositório novo: só seguir a imagem abaixo, você não precisa configurar mais nada, e lembrete que aqui eu dei o mesmo nome que está no meu url lá no _config.yml:
Copiar as instruções que vem na área ...or push an existing repository from the command line:

Terminal: segunda fase

A segunda fase do terminal consiste em mandar o nosso código para o GitHub e colocar o site no ar de fato. Vamos lá que tá quase:

$ git remote add origin git@github.com:jtemporal/blogfresh.git
# ou: git remote add origin git@github.com:jtemporal/jtemporal.github.io.git
$ git push -u origin master

GitHub: o retorno

Depois de mandar o código para o GitHub agora precisamos configurar o site, simbora! Vamos começar indo para aba de Settings do repositório:

Descendo nessa página de configurações encontramos a seção referente ao GitHub Pages. É essa seção que acaba publicando o site:

Quando selecionado None na área de Source, o GitHub Pages está desativado. Então vamos selecionar um ramo para publicar nosso site a partir dele, nesse caso o ramo será o master mesmo:

E agora clicar em Save:

E o resultado será algo parecido com:

É só acessar o link do site agora que deve estar lá bonitão ;)

E agora? Bem agora você pode começar a escrever outros posts e ir commitando eles. Todo commit/pull request para a master vai automagicamente executar os passos de build do site e deploy. Happy blogging!

Links e considerações

Existem outras formas de instalar o Ruby na sua máquina, encontre elas estão listadas na documentação do Ruby em português.
Bundler.
Eu usei os comandos do Git para chaves SSH, escolha pessoal minha, se preferir use os mesmos comandos utilizando o acesso via HTTPS. Caso queira utilizar o SSH assim como eu você vai precisar de chaves, esses tutoriais do GitHub em inglês ensina como gerá-las e utilizá-las.
Prometo fazer um post explicando como alterar o layout e outras coisas no tema em breve.

Escolhendo um tema Jekyll

Sun, 07 Jan 2018 08:00:00 +0000

Acho que a maioria dos desenvolvedores que decidem começar um blog encontra-se no dilema: Agora eu sei HTML e CSS e vou fazer o meu blog, ele vai ser super leve e acessível… e por aí começa a descida pela toca do coelho. Passados três meses o blog pode até estar pronto mas nada ainda foi publicado. Então a colinha de hoje vai pra você que quer colocar conteúdo na nuvem e não se apegar num primeiro momento nas decisões de código.

Eu devo ter dado essa dica e defendido essa escolha para muitas pessoas que querem começar um blog e não querem se prender as grandes plataformas. Então aqui vai pra você também: Use Jekyll.

Isso mesmo, uma ferramenta open source escrita em Ruby, Jekyll é capaz de transformar um monte de arquivos em um website estático pronto para publicação. Okay, okay a essa hora você já deve estar pensando que vai cair naquele dilema de novo de construir do zero mas não, vou te contar um dos motivos que gosto tanto do Jekyll: existe uma plataforma com uma coleção gigantesca de temas já prontos chamada Jekyll Themes.

Esse site aqui, saiu de um tema feito pelo Taylan Tatlı, o Moon. Existem temas para todos os gostos, a maioria deles com instruções passo-a-passo de como alterá-lo. Junte isso com o GitHub Pages e seu site estará no ar rapidinho.

Depois de ter colocado no ar você pode começar a fazer melhorias e/ou alterar o seu tema aos pouquinhos. Isso me ajudou no começo pode ser que seja o que você precisa também ;)

E aí, já escolheu o seu tema?

Choosing a Jekyll theme

Sun, 07 Jan 2018 08:00:00 +0000

I think most developers who decide to start a blog find themselves in a dilemma: I know HTML and CSS, and I can make my blog, it is going to be super light and fast… And so begins the descent into the rabbit hole. Three months later, the blog may be ready, but nothing was published. So today’s pro-tip goes to you who wants to put content out there and doesn’t want to get caught up in code decisions at first.

I must have given this tip and defended this choice to many people who want to start a blog and don’t want to stick to the big platforms. So here it goes for you too: Use Jekyll.

That’s right, an open-source tool written in Ruby, Jekyll can turn many text files into a static website ready for publication. Okay, okay by now, you might be thinking you’re going to fall into that dilemma of building from scratch again, but that’s not the case, one of the reasons I like Jekyll so much is that there’s a platform with a vast collection of ready-made themes called Jekyll themes.

The first version of this site here came out of a theme made by Taylan Tatlı called Moon. There are so many themes to choose from, that I bet you can find one that suits your needs; most of them with step-by-step instructions on how to customize the theme itself. Put this together with GitHub Pages, and your site will be up and running fast.

Once you have released your site, you can start making improvements and modifying your theme little by little. Using Jekyll and GitHub Pages helped me, in the beginning, and it may be what you need too ;)

So, have you chosen your theme?

Dependências de projetos Python: requirements.txt

Sat, 06 Jan 2018 08:00:00 +0000

Author note: You can read this post in English here.

Depois de uma conversa longa outro dia sobre dependências e reprodutibilidade de ambientes, decidi fazer essa colinha pra falar de um arquivo muito frequente nos projetos Python que vejo por aí: o requirements.txt.

Um passo comum da configuração de ambientes de desenvolvimento Python é fazer a instalação de dependências. Muitas vezes esse passo é executado da seguinte forma:

$ pip install -r requirements.txt

Mas o que é de fato esse arquivo? Segundo a documentação do pip sobre arquivos requirement:

“Requirements files” are files containing a list of items to be installed using pip install

Ou seja, esse arquivo nada mais é do que um arquivo de texto, contendo uma lista de itens/pacotes para serem instalados durante o pip install.

Vamos a um exemplo

Considerando esse requirements.txt aqui:

  -e git+https://github.com/jtemporal/caipyra.git@master#egg=caipyra
  seaborn==0.8.1
  pandas>=0.18.1
  serenata-toolbox

Temos várias informações importantes, vamos repassá-las linha a linha:

-e git+https://github.com/jtemporal/caipyra.git@master#egg=caipyra: Dessa forma conseguimos instalar pacotes Python que estejam disponíveis no GitHub mas não no PyPI. Essa é uma dica muito legal quando por exemplo, você precisa da versão em desenvolvimento de um biblioteca ou quando você prefere usar um fork no lugar da versão tradicional do pacote.
seaborn==0.8.1: No caso do seaborn, estamos instalando a versão 0.8.1. Fixar a versão dessa forma é interessante pois garante que o seu projeto vai sempre estar funcionando já que mudanças nos pacotes são indicadas pela alteração no número da versão.
pandas>=0.18.1: Da mesma forma que o sinal de == define uma versão específica a ser instalada, quando usamos o sinal de >= nessa lista estamos dizendo que queremos instalar qualquer versão da biblioteca, nesse caso o pandas, seja ela a versão 0.18.1 ou uma mais recente. Interessante nesse caso é notar que você pode definir um intervalo de versões, por exemplo, pandas>=0.15.0,<=0.18.1.
serenata-toolbox: Quando não específicamos uma versão, o pip sempre tentará instalar a versão mais recente do pacote especificado.

Criando seu requirements.txt

Um jeito simples de criar o seu próprio arquivo de depências é usando o comando pip freeze da seguinte forma:

$ pip freeze > requirements.txt

O comando pip freeze lista no terminal os pacotes Python instalados no seu ambiente já no formato que o pip install consegue entender, ao associá-lo com o operardor de redireção > você consegue escrever a mesma lista que aparece no terminal dentro do arquivo de texto.

Massa né? Agora é só criar arquivos de dependências para todos projetos 😜

Agradecimentos

Obrigada aos amigos que participaram da conversa sobre dependências e reproducibilidade de ambientes <3

Python project dependencies: requirements.txt

Sat, 06 Jan 2018 08:00:00 +0000

After a long conversation the other day about dependencies and environments reproducibility, I decided to make this post to talk about a very common file in Python projects that I see all around: the requirements.txt.

A common step in setting up Python development environments is to install dependencies. This step is often performed as follows:

$ pip install -r requirements.txt

But what is this file really? According to pip documentation on requirement files:

“Requirements files” are files containing a list of items to be installed using pip install

That is, this file is nothing more than a text file, containing a list of packages to be installed during pip install.

Let’s go to an example

Considering this requirements.txt here:

-e git+https://github.com/jtemporal/caipyra.git@master#egg=caipyra
seaborn==0.8.1
pandas>=0.18.1
serenata-toolbox

We have several important information, let’s go over it line by line:

-e git+https://github.com/jtemporal/caipyra.git@master#egg=caipyra: This way we were able to install Python packages that are available on GitHub but not on PyPI. This is a really cool tip when, for example, you need the development version of a library or when you prefer to use a fork instead of the traditional version of the package.
seaborn==0.8.1: We are installing version 0.8.1 of seaborn package. Fixing the version in this way is interesting because it ensures that your project will always be working since changes in the packages are indicated by the change in the version number.
pandas>=0.18.1: In the same way that the == sign defines a specific version to be installed, when we use the >= sign in this list, we are saying that we want to install a version of the library higher that is equals to 0.18.1 or higher than that. Interesting in this case is to note that you can define a range of versions, for example, pandas>=0.15.0, <=0.18.1.
serenata-toolbox: When we don’t specify a version, pip will always try to install the latest version available of the specified package.

Creating your requirements.txt

A simple way to create your own requirements file is to use the pip freeze command as follows:

$ pip freeze > requirements.txt

The command pip freeze lists the Python packages installed in your environment in the terminal already in the format that the pip install can understand, by associating it with the > redirection operator you can write the same list that appears in the terminal inside the text file.

Awesome right? Now just create dependency files for all projects 😜

Thanks

Thanks to friends who participated in the conversation about dependencies and environments reproducibility <3

Forçando o rebuild de sites Jekyll hospedados no GitHub

Wed, 03 Jan 2018 10:00:00 +0000

Seja por um CSS quebrado ou por uma mudança que parece não ter tido efeito, às vezes é necessário forçar o rebuild de um site Jekyll hospedado no GitHub. A colinha de hoje explica uma forma de fazer isso.

O GitHub possui um “serviço” para servir páginas a partir de repositórios chamado de GitHub Pages. Esse serviço permite que você crie páginas quase que instantaneamente a partir do seu repositório e tudo que você precisa é de um arquivo markdown como o README de um projeto e um arquivo de configuração básica.

Isso é possível pois o GitHub Pages usa o Jekyll, um gerador de site estático open source, para fazer o build de sites. Entre outras facilidades que não vou falar hoje, um ponto extremamente positivo de usar essas duas ferramentas para colocar o seu site no ar é que você não precisa “subir” para o GitHub um build do seu site toda vez que quiser publicar uma mudança, o próprio GitHub se encarrega do build para você.

Porém algumas vezes é necessário rodar o processo de build novamente e como esse processo acontece nos servidores do GitHub que nós não temos acesso, precisamos de outras formas de forçar o build.

Uma delas e a que eu uso hoje em dia é fazer um commit “vazio”, ou seja, um commit que não carrega mudanças em arquivo algum do seu diretório.

Basta ir para o diretório do site (aqui vou usar o do meu site como exemplo):

$ cd jtemporal.github.io

e escrever um commit usando a opção --allow-empty:

~/jtemporal.github.io $ git commit --allow-empty -m "Forçando o rebuild"

ou se preferir editar a mensagem do commit no editor de texto:

~/jtemporal.github.io $ git commit --allow-empty

E é isso. Isso é o suficiente para forçar o processo do build novamente. Massa né? 😜

Python e suas versões: pyenv parte 2

Tue, 02 Jan 2018 10:00:00 +0000

A colinha de hoje é inspirada nesse tweet aqui:

como ele funciona a respeito dos pacotes instalados via pip? tem um pip pra cada versão? os pacotes ficam disponíveis pra múltiplas versões?
— luciano ratamero (@lucianoratamero) 31 de dezembro de 2017

Então se você já instalou o pyenv e agora quer saber um pouqinho mais sobre como ele funciona assim como o Luciano, aqui vai…

O pip

Pra quem não sabe o que é o pip ele é a ferramenta recomendada para fazer a instalação de pacotes Python.

Onde vão as versões do pyenv

Dentro do diretório/pasta do pyenv temos um diretório chamado versions e é lá que moram as versões que você instala usando o comando pyenv install, na minha máquina eu tenho três versões do Python instaladas:

versions
├── 2.7.12
├── 3.3.0
└── 3.6.4

O pyenv e o pip

Cada nova versão do Python que você instala usando o pyenv vem com o seu próprio pip. Veja:

Listagem de pacotes instalados em cada versão

Agora, se você setar uma versão do Python usando pyenv e instalar um pacote usando o pip o que acontece? Esse pacote fica disponível para as demais versões?

Resposta rápida: Não, um pacote instalado numa versão não fica disponível noutra versão.

Vejamos, vamos usar de exemplo o pacote do Caipyra. Antes de instalá-lo temos:

Listagem de pacotes instalados em cada versão

Instalando o caipyra na versão 3.3.0:

Instalação do pacote Caipyra na versão 3.3.0

Listando novamente os pacotes instalados em cada versão:

Listagem de pacotes instalados em cada versão

E finalmente o teste para ver se o pacote fica disponível ou não para outras versões:

Rodando o import caipyra em todas as versões

Tanto na versão 2.7.12 quando na versão 3.6.4 Python grita ModuleNotFoundErrror, esse erro é característico quando o pacote não está instalado.

Massa né? Preparar, apontar, instalar pacotes diferentes em cada versão do Python 😜

Agradecimentos

Obrigada Luciano Ratamero pelas dúvidas que me deram a ideia desse outro post 😉

Pegando o último elemento de uma lista em Python

Mon, 01 Jan 2018 10:00:00 +0000

Python é conhecida por facilitar a escrita de códigos bonitos e pequenos. A colinha de hoje é sobre como pegar o último elemento de uma lista usando essa linguagem \o/

Vindo de outras linguagens como Java ou C para o Python é normal trazer um pouco de sotaque para os seus códigos e querer fazer algo mais ou menos assim para pegar o último elemento de uma lista:

lista = [1, 2, 3, 4, 5]
indice = len(lista) - 1
print(indice)
# 4
ultimo = lista[indice]
print(ultimo)
# 5

Usar a função de tamanho len() para pegar o comprimento da lista e subtrair 1 para obter o índice do último elemento daquela lista. E tudo bem! Isso funciona. Porém Python apresenta um jeito mais elegante de fazer isso, veja:

ultimo = lista[-1]
print(ultimo)
# 5

Apesar de parecer isso não é mágica não! Da documentação do Python:

If i or j is negative, the index is relative to the end of sequence s: len(s) + i or len(s) + j is substituted. But note that -0 is still 0.

De uma forma mais simples o Raymond Hettinger explica nesse tweet com código:

#python tip: How to support negative indexing:

def __getitem__(self, i):
if i < 0:
i += len(self)
if i < 0 or i >= len(self):
raise IndexError
...
— Raymond Hettinger (@raymondh) 20 de dezembro de 2017

A implementação de fato é mais complexa que essa, mas o que acontece em linhas gerais: o método __getitem__ é invocado quando fazemos a chamada lista[-1] recebendo a própria lista (self) e o índice negativo (i) então soma esse índice com o tamanho da lista e retornando o valor do índice atualizado. Curiosamente é o mesmo que fiz no primeiro exemplo porém já vem implementado de fábrica.

E detalhe, o mesmo pode ser feito para strings!

palavra = 'opaopa'
print(palavra[-1])
# a

Massa né? Agora é só usar índice negativo nos seus códigos também 😉

Agradecimentos

Mário Sérgio, Diego Ponciano e Paulo Haddad por alguns dos links nesse post!

Ambientes virtuais Python: venv

Sat, 30 Dec 2017 00:00:00 +0000

Depois de aprender que Python possui várias versões e aprender a instalar mais de uma delas com o pyenv, a colinha de hoje mostra um próximo passo: utilizar o venv para criar ambientes virtuais com o Python 3.

No lançamento da versão 3.3 foi anunciado o venv como novo módulo da linguagem. E na versão 3.6 o venv se torna a escolha oficial para criação de ambientes virtuais Python com o script do pyvenv se tornando deprecated.

História do surgimento do venv a parte, vamos aos finalmentes. Basta ter qualquer versão do Python apartir da 3.3 que os códigos abaixo devem funcionar ¯\_(ツ)_/¯.

Para criar um ambiente virtual:

$ python -m venv meuenv

E para ativar o ambiente:

$ source meuenv/bin/activate

Agora atenção para uma coisa: essa forma de criar ambientes virtuais não permite que você crie ambientes para outras versões que não aquela que você esteja usando.

$ python --version
# Python 3.3.0

Aqui eu estava usando o Python 3.3.0 então o myenv vai ter essa versão. Daí é que fica legal ter o pyenv instalado! Você só precisa trocar a versão para a que você quer e criar o ambiente. Veja:

$ python --version
# Python 3.3.0
$ pyenv local 3.6.4
$ python --version
# Python 3.6.4
$ python -m venv meuoutroenv
$ source meuoutroenv/bin/activate

Uma das vantagens de ter um módulo desses embutido na linguagem é não precisar instalar nada mais para conseguir criar ambientes virtuais. Pra galera evita instalar coisas extras no computador como eu isso é fantástico.

E agora só fazer pip install e começar com os códigos ☺️

Python virtual environments: venv

Sat, 30 Dec 2017 00:00:00 +0000

After learning that Python has several versions, and after learning how to install any of them using pyenv, today’s tip teaches you the next step: how to use venv to create virtual environments with Python 3.

At the launch of Python 3.3 venv was announced as a new language module, and in version 3.6, venv became the official choice for creating Python virtual environments with the deprecation of the pyenv script.

History of how venv came to life aside, let’s go to what matters. You can use any version equal to or higher than Python’s 3.3 that the commands below should work ¯\_(ツ)_/¯.

To create a virtual environment:

$ python -m venv myenv

To activate the environment:

$ source myenv/bin/activate

Now pay attention to one thing: this way of creating virtual environments doesn’t allow you to create environments to other Python versions than the one you are already using.

$ python --version
# Python 3.3.0

Here I was using Python 3.3.0, so my virtual env has that version. That’s when having pyenv installed is a good thing! You only have to use pyenv and switch to the version you want then create the environment. Take a look:

$ python --version
# Python 3.3.0
$ pyenv local 3.6.4
$ python --version
# Python 3.6.4
$ python -m venv meuoutroenv
$ source meuoutroenv/bin/activate

One of the advantages of having one module of this kind built-in the language is that you don’t need to install anything else to create your virtual environments. To the people that avoid installing things on the computer like myself, this is fantastic!

Now that you have your virtual environment created you can go ahead, pip install all things and start coding. ☺️

Python and its versions: pyenv

Fri, 29 Dec 2017 10:00:00 +0000

Author note: Você pode ler este artigo em Português.

One of the first things we learn in Python is that there is more than one version of the same language working side by side. That can bring a few problems and the inevitable question: “Which version should I choose?”. Today’s tip teaches you a way to install and manage many Python versions on your machine using pyenv 😉.

Amongst other things, the two best features of pyenv in my humble opinion are:

install new Python versions easily;
choose the global Python version.

To start you’ll need to install pyenv, here I’ll demonstrate one of several installation methods, but in the project’s readme file you can find other possibilities (and also operational system related details):

$ git clone https://github.com/pyenv/pyenv.git ~/.pyenv
$ echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
$ echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
$ exec "$SHELL"

After these easy steps, other versions of Python are an install away:

$ pyenv install 3.6.4

When in doubt of which version you can install, just use the install flag -l that it lists all versions available:Se estiver em dúvida quais versões você pode instalar só usar a flag -l do install que ele vai listar todas as disponíveis:

$ pyenv install -l

Cool huh? Now you can install Python versions like crazy 😂

And now, for the moment of truth, to configure the global version of Python, that is, to define which version of Python you will use when running Python, run the following command:

 $ pyenv global 3.6.4

So regardless of where you navigate on your terminal, the Python version running will be 3.6.4. This command is handy if all of your projects are in the same version. Another nice feature of pyenv is to define a local Python, let’s say for instance that a given project only runs on Python 3.5.3, so you need to install that version (as you learned previously) and then go to that project’s folder and use this command:

 $ pyenv local 3.5.3

So whenever you enter the said project folder, pyenv will “activate” the correct Python for your project.

No more pain when dealing with Python versions! 🎉

Python e suas versões: pyenv

Fri, 29 Dec 2017 10:00:00 +0000

Author note: You can read this post in English here.

Uma das primeiras coisas que aprendemos sobre Python é que existem mais de uma versão da mesma linguagem funcionando a todo vapor. Isso traz alguns problemas e a inevitável pergunta “Qual versão eu devo usar?”. A colinha de hoje mostra uma forma de instalar e manter o controle de várias versões do Python na sua máquina usando o pyenv 😉.

Entre outras coisas, as duas melhores features pyenv na minha humilde opinião são:

instalar novas versões do Python facilmente;
escolher a versão global do Python.

Pra começar você precisa instalar o pyenv, aqui eu vou mostrar um dos métodos de instalação, mas lá no readme do projeto tem outras (e também detalhes específicos de cada sistema operacional):

$ git clone https://github.com/pyenv/pyenv.git ~/.pyenv
$ echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
$ echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
$ exec "$SHELL"

Depois desse passo é bem facinho, as outras versões do Python estão a um install de distância:

$ pyenv install 3.6.4

Se estiver em dúvida quais versões você pode instalar só usar a flag -l do install que ele vai listar todas as disponíveis:

$ pyenv install -l

Massa né? Agora é só sair instalando versão adoidado 😂

E agora o momento da verdade, para configurar a versão global do Python, isto é, definir que versão do Python você vai usar quando colocar o Python pra rodar, use o seguinte comando:

$ pyenv global 3.6.4

Assim independente de qual lugar você navegar no seu terminal o Python que estará rodando será o 3.6.4. Isso é muito útil se todos os seus projetos estiverem na mesma versão. Outra funcionalidade legal do pyenv é definir um Python local, vamos supor que um determinado projeto só rode no Python 3.5.3 então basta você instalar essa versão (como você aprendeu ali em cima) e em seguida ir até a pasta desse projeto e usar este comando:

$ pyenv local 3.5.3

Assim sempre que você entrar nessa pasta o pyenv vai “ativar” o Python correto para o seu projeto.

Chega de sofrer com versões do Python! 🎉

Links

Você pode continuar a ler sobre o pyenv na Parte 2 desse texto.

Adicione cores ao compartilhar seu site

Wed, 27 Dec 2017 10:00:00 +0000

Você já notou que ao compartilhar um link na sua rede social favorita esses links carregam imagens para mostrar? Uma espécie de thumbnail do site?

Pois bem, hoje é amplamente utilizada em várias redes sociais, mas quem começou essa brincadeira foi o Facebook que implementou um negócio chamado The Open Graph protocol. Os objetos dentro do face, são colocados num grafo social (social graph) e são conhecidos como “objetos ricos” (rich objects). Isso que dizer, em poucas palavras, que cada objeto tem uma coleção de características que acrescentam informções a esses objetos.

E o Facebook queria que as páginas compartilhadas dentro dele pudessem carregar a mesma quantidade de informação e aí que entram meta tags. A ideia é usar meta tags para representar ricamente cada página da internet dentro de um grafo social.

Existem várias meta tags que podem ser utilizadas, mas na colinha de hoje vamos falar da og:image.

O site do Pizza De Dados

Essa semana passada, eu procurei deixar o site do Pizza de Dados mais amigável aos olhos e uma das coisas que eu quis mudar foi acrescentar a meta tag com a nossa logo 🍕

Antes ao compartilhar o site do Pizza tinhamos algo assim:

Nota como fica muito sem graça? Às vezes na tentativa de preencher as informações sobre a págica a rede social ainda pode acabar escolhendo uma imagem qualquer que exista na página e usá-la como “thumbnail”.

Então para alterar esse comportamento e adicionar um pouco de cor às nossas postagens seguindo o site oficial da OGP acrescentamos uma linha parecida com essa:

<meta property="og:image" content="http://ia.media-imdb.com/images/rock.jpg" />

no head do site. E 🌈automagicamene🌈 ao compartilhar o site do Pizza temos:

Tranquilo né? Agora é só usar no seu site tbm 😉

Add colors when sharing your website

Wed, 27 Dec 2017 10:00:00 +0000

Have you ever noticed that when you share a link on your favorite social network, these links load images to show? A kind of website thumbnail?

Well, today it is widely used on several social networks, but it was Facebook who started this game by implementing something called The Open Graph protocol. Objects within Facebook are placed in a social graph and are known as “rich objects.” This means, in short, that each object has a collection of characteristics that add information to these objects.

And Facebook wanted the pages shared within it to be able to load the same amount of information, and that’s where meta tags come in. The idea is to use meta tags to richly represent each internet page within a social graph.

There are several meta tags that can be used, but in today’s pro tip, we will talk about the og:image.

Pizza De Dados website

Last week, I tried to make the Pizza de Dados website more visually appealing, and one of the things I wanted to change was to add the meta tag with our 🍕 logo.

Before, when sharing the Pizza website, we had something like this:

Do you notice how it looks very dull? Sometimes, in an attempt to fill in the information about the page, the social network may still end up choosing any image that exists on the page and using it as a “thumbnail”.

So to change this behavior and add some color to our posts following the official OGP site, we need to add a line similar to this:

<meta property="og:image" content="http://ia.media-imdb.com/images/rock.jpg" />

in the website head. And 🌈automagically🌈 when sharing the Pizza website, we have:

Awesome, right? Now you can use it on your website too 😉.

Links

Open Graph protocol official website.

Retrospectiva 2017: Um momento de reflexão

Wed, 20 Dec 2017 10:00:00 +0000

Eu decidi fazer uma coisa nova esse fim de ano: analisar o meu crescimento e escrever isso em algum lugar. Uma visão geral dum ano tão carregado das coisas que fiz/deixei de fazer.

O principal motivo de anotar tudo isso por aqui é: Esse ano foi díficil.

A economia do país tava no ralo, a política é uma montanha sem fim de corrupção, o mundo parece que desandou um pouquinho esse ano. E durante o ano tive vários momentos em que me perguntei Pra que fazer isso que estou fazendo? Pode ser que nada dê certo. E mesmo que algo dê certo não vai durar tanto assim… Pois bem, a pior parte de passar por todo o sufuco que pode ter sido o seu 2017 foi justamente essa passar por todo o sufoco que foi 2017.

Agora é hora de refletir. Sim eu sei que soa igual clichê. Mas é hora de sentar e pensar Ufa, já passou então pega o histórico do GitHub, pega a agenda (virtual ou não), pega as DMs do Twitter e a lista dos e-mails e bora brincar de fazer uma retropesctiva.

A brincadeira é a seguinte:

Escolha um tema: O seu tema pode ser qualquer coisa, desde que você considere que ele tenha um peso importante no seu ano. O meu é Trabalho, seja ele voluntário não, que eu tenha me divertido fazendo ou não. Ah e se você não quiser escolher um tema só tudo bem também ;)
Cada coisa/momento que eu considero notável no meu ano entra na lista. Um momento notável é algo que ficou marcado de alguma forma quando algm pergunta E aí como foi o ano?
Cada item da lista vai ter uma descriçãozinha com o motivo que torna aquele momento notável por exemplo: aprendi a tocar violão, e isso é notável pois eu comprei um violão fazem 3 anos e até agora tava pegando poeira
O objetivo é perceber que, por mais díficil que o ano tenha sido pra você, você cresceu esse ano
No final de tudo isso, se você conseguir/quiser agradeça quem passou com você os momentos memoráveis e tire as suas conclusões talvez você queira melhorar algo, sei lá quando chegar na meta a gente dobra ela =P

Aqui vai a minha lista (e no fim minhas conclusões):

Montei um currículo que nunca enviei para ninguém: Sim, inicialmente o plano era enviar ele para empresas, mas a vida a contece e meia hora depois que ele estava oficialmente terminado eu recebi uma oferta de trabalho. O que me leva ao próximo ponto…
Disse sim para um desafio: Tendo acabado recentemente a faculdade e ainda sem diploma (ele chegaria um mês depois), no dia que terminei a primeira versão do meu CV, eu aceitei a oferta que o pessoal da Serenata me fez o que desencadearia uma série de eventos mucho loka que ainda me pergunto se foi real
Colei grau: E a maior parte da cerimônia eu chorei e pensei “Não posso cair, não posso cair, não posso cair”. Eu estava de salto.
Contribui com open source ativamente: Embora a maior parte das minhas contribuições fossem para a Serenata, isso me possibilitou abrir os horizontes e no hacktoberfest eu consegui contribuir com projetos novos. Tanto de amigos quanto internacionais.
Viajei pra Taiwan: Uma ilhazinha do outro lado do mundo que fala um dialeto de chinês diferente da China continental e eu fui pra lá. Sim minha gente jet-lag é muitíssimo real e assim que eu puder viajo pra lá de novo! O que eu fui fazer lá? Bem continua lendo…
Dei minha primeira palestra em inglês: Como muitas outras nesse ano o tema foi o mesmo: Sereanta. Mas como mudar é sempre bom, essa foi em Inglês lá em Taiwan para um evento de tecnologia cívica. Eu e a Ana submetemos a atividade e advinha?! Queríam ouvir o que a gente tinha pra dizer hpns
Aceitei um projeto novo: Serenata rola um revezamento do time, em Setembro eu me afastei para trabalhar num novo projeto na Data Science Brigade. Mais para o fim do projeto uma realização pessoal: dois anos depois de ter desistido de uma nova iniciação científica para fazer coisas diferentes das que já estava acostumada, finalmente fiz algo que me fez ter desistido da IC em primeiro lugar: juntar Python e R num mesmo projeto de análise de dados
Dei a primeira palestra na PythonBrasil: Bem massa cruzar meio mundo pra palestrar, mas o coraçãozinho bate mais forte quando é um evento querido. Então um ano depois da primeira Python Brasil (e dessa vez com os dois pés funcionais) fui lá pra Beagá falar sobre Serenata pela última vez no ano. Ainda não tem video mas quando tiver coloco o link aqui ;)
Me tornei parte da APyB: Nessa mesma PythonBrasil entre mil fitas e mil tretas, me candidatei para um cargo no Conselho Deliberativo da Associação Python Brasil. 9 pessoas votaram em mim (ainda não acredito nisso e muito obrigada a vocês).
Ministrei um workshop junto com uma amiga: Fato curioso: nunca quis ser professora, mas adoro ensinar as coisas que eu aprendi. Aí junto com a Letícia Portella que adora ensinar também já viu né? Saiu um workshop de ciência de dados… E tá no GitHub viu?!
Organizei um Django Girls a distância: Um dia eu tava de boa na lagoa e do nada no fim do dia eu já tava ajudando a organizar o Django Girls BH 2017. Claro que eu não tava nessa sozinha né?! Sem a Thaís Viana, a Paola Pacheco e a Marcilene nada disso seria possível. E ainda ouso dizer que o Igor Santos e o Cássio Botaro também foram super importantes em fazer o DG rolar.
Fundei um podcast com amigos: Eu que não sou de escutar podcast, topei a missão de fazer um com a Letícia Portella e com o Gustavo Coelho. O primeiro episódio foi super bem recebido com vários feedbacks positivos. Já liberamos o episódio 2 e já marcamos gravações de mais dois.
Disse xau para DSB e olá para a Nuveo: Engraçado que às vezes a gente acha que a nossa história vai durar bastante num certo caminho e aí, a vida chega e te da uma bofetada e te troca de rumo. E foi meio que assim que rolou essa mudança. E o que dizer desse rumo novo que mal começou mas já considero pacas?! Mal posso esperar pelo que vem pela frente.

Antes de anotar tudo isso aí em cima, eu não tinha percebido o tanto de coisa q eu fiz. E por mais legal que seja tudo isso, a coisa mais notável que me vem a cabeça quando eu penso em todos esses momentos memoráveis é que eu não estava sozinha.

A todos que compartilharam esses e outros momentos comigo (sim, eu sei que não citei todo mundo), foi um ano incrível e vocês que contribuiram pra que ele fosse assim!

Um abraço apertado e cheiro 😘

PS.: e você que tá lendo isso, se eu te perguntasse o que você fez esse ano, o que você me diria? Se quiser contar sou toda ouvidos 😉

Colocando pontos num mapa com Folium

Sun, 03 Dec 2017 10:00:00 +0000

Vamos supor que você está trabalhando com dados do mundo real. E nesses dados você tem as latitudes e longitudes de algumas entidades. E ainda mais, você quer colocar essas entidades num mapa e mostrar isso para as suas coleguinhas. Como fazer?

Bem, você tem algumas opções…

Colocar manualmente pontos no mapa usando o Google Maps, o que é até okay quando você tem 2 ou 3 entidades mas quando isso passa de 10 já fica meio chato né?!
Usar uma biblioteca/pacote de alguma linguagem de programação que faça isso. Particularmente minha opção favorita 💃🏻

Existem algumas bibliotecas disponíveis para isso, mas hoje vamos falar da Folium.

Folium

O propósito dessa biblioteca é unir o poder de manipulação de dados que Python possui com a força de visualização de mapas da biblioteca JavaScript Leaflet. A ideia aqui é tornar ainda mais fácil a missão de colocar pontos em um mapa.

Cadê o código?

Todo código que eu vou mostrar abaixo ta organizadinho neste diretório no GitHub, nele tem as instruções de preparação do ambiente tanto com docker quanto sem docker.

Instalação

Comece preparando o ambiente:

$ git clone https://github.com/jtemporal/intro-folium.git
$ cd intro-folium/

Com docker

Se você gosta da 🐳 :

$ docker-compose build

Sem docker

Se não é fã da 🐳:

$ pip install -r requirements.txt
$ pip install jupyter

Inciando

Depois disso, ainda no terminal:

Na versão 🐳:

$ docker-compose up jupy

ou sem docker:

$ jupyter notebook

Depois de rodar um dos comandos acima, você verá uma mensagem parecida com a seguinte no seu terminal:

Foto do terminal rodando o projeto com docker

A última linha indica o token de acesso, é só copiá-la e colocar no navegador para abrir o jupyter. Deve aparecer algo assim para você:

Foto do navegador rodando o jupyter

Se você rodar o notebook folium_intro.ipynb inteiro você vai obter os mesmos resultados que vou mostrar aqui. Além disso, se você clicar na imagem do mapas que vão vir a seguir, você vai ser levado para a página desses mesmos mapas o que vai de te deixar intergarir com eles 😉

Colocando a mão na massa

Começamos importando as bibliotecas necessárias e criando um mapa:

import pandas as pd
import folium

brasil = folium.Map(
    location=[-16.1237611, -59.9219642],    # Coordenadas retiradas do Google Maps
    zoom_start=4
)

O folium.Map() precisa apenas do parâmetro location para criar o seu mapa. Esse parâmetro recebe um par latitude-longitude que pode ser uma lista ou uma tupla. Aqui eu passei também um valor (4) para o parâmetro zoom_start, o padrão desse parâmentro é 10, mas um zoom de 10 não deixa o país inteiro na região do mapa por isso, o novo valor de 4. Ao chamar o mapa, temos:

brasil

Mapa clicável

Mas agora eu quero colocar pontos no mapa. Aqui vou usar de exemplo um conjunto de dados com geolocalização de empresas que apareceram nos reembolsos analisados pela Operação Serenata de Amor. No repositório intro-folium tem uma versão reduzida desse conjunto de dados. Então vamos começar lendo esses dados e colocando no mapa duas primeiras empresas:

empresas = pd.read_csv('empresas.xz')

empresa1 = empresas.iloc[0]
folium.Marker(
    location=[empresa1['latitude'], empresa1['longitude']],
).add_to(brasil)

empresa2 = empresas.iloc[1]
folium.Marker(
    location=[empresa2['latitude'], empresa2['longitude']],
).add_to(brasil)

O folium.Marker() coloca um “pin” de localização no mapa. Para isso ocorrer precisamos passar novamente a location e ainda indicar a qual mapa adicionar esse pin usando o metodo add_to(). Chamando nomavente o mapa, temos:

brasil

Mapa clicável

Resista a curiosidade de colocar todos as empresas num mapa. Com as mais de ciquenta mil empresas deste dataset, isso provavelmente irá travar o seu computador (travou o meu jupyter). Confie em mim, um mapa com todas as empresas do dataset fica assim:

Sabendo que mostrar a belezinha acima trava o computador, vamos então selecionar um estado apenas para mostrar:

empresas_pe = empresas[empresas['state'] == 'PE']

Para melhorar a visualização eu também iniciei um novo mapa, esse tem as coordenadas do estado de Pernambuco (meu estado de origem ❤️), veja:

pernambuco = folium.Map(
    location=[-8.3833569, -38.5757127],
    zoom_start=7
)

pernambuco

Mapa clicável

E colocando as empresas no mapa:

for _, empresa in empresas_pe.iterrows():
    folium.Marker(
        location=[empresa['latitude'], empresa['longitude']],
    ).add_to(pernambuco)

pernambuco

Mapa clicável

Aqui ja podemos notar uma coisa que vale análise: Apesar de no dataset, apresentarem o estado cadastrado como Pernambuco, encontramos duas empresas que sua latitude e longitude não estão dentro do limite do estado 🤔

Puxa, muito legal isso, mas meio sem graça né? Então vamos dar uma olhada em como colorir um pouco as coisas?

Vamos começar reduzindo ainda mais nossa quantidade de empresas. Selecionei as 110 empresas de Olinda ❤️, e coloquei elas no mapa:

empresas_olinda_pe = empresas[empresas['city'] == 'OLINDA']

olinda = folium.Map(
    location=[-7.9981267, -34.9082027],
    zoom_start=13
)

for _, empresa in empresas_olinda_pe.iterrows():
    folium.Marker(
        location=[empresa['latitude'], empresa['longitude']],
    ).add_to(olinda)

olinda

Mapa clicável

Depois escolhi alguns bairros dos 22 bairros com empresas para colorir criando um dicionário que mapeia o nome de um bairro para uma cor:

colors = {
 'AMPARO': 'pink',
 'GUADALUPE': 'blue',
 'CASA CAIADA': 'green',
 'PEIXINHOS': 'orange',
 'RIO DOCE': 'red',
 'BAIRRO NOVO': 'purple',
}

olinda = folium.Map(
    location=[-7.9981267, -34.9082027],
    zoom_start=13
)

for _, empresa in empresas_olinda_pe.iterrows():
    if empresa['neighborhood'] in colors.keys():
        folium.Marker(
            location=[empresa['latitude'], empresa['longitude']],
            icon=folium.Icon(color=colors[empresa['neighborhood']])
        ).add_to(olinda)

Aqui usamos um novo parâmetro do folium.Marker(), o icon que recebe um objeto do tipo folium.Icon e assim a coloração que queremos. Note que, antes de colocar os pontos no mapa, eu limpo o mapa de Olinda recriando esse objeto e assim, ao invés de colocar os pins coloridos por cima do mapa antigo com os pins azuis. Ainda mais um detalhe, esse tipo de marker (que parece um 📌) segue as cores do bootstrap, ou seja, é limitado, mas para esse exemplo serve:

olinda

Mapa clicável

Três coisinhas a mais

Mapas em páginas web

Você pode salvar seus mapas como páginas HTML usando o comando abaixo, basta identificar o mapa que quer salvar, usar o método .save() e passar um nome do arquivo como como parâmetro. Todas as páginas de mapas desse post foram geradas assim:

olinda.save('mapas_htmls/olinda_some_colored.html')

Informações extras num mapa

Também pode passar informações sobre a entidade que você está colocando no mapa usando o parâmetro popup. Assim ao clicar em um dos pins, um balão mostra alguma informação:

folium.Marker(
    location=[empresa['latitude'], empresa['longitude']],
    popup='sou uma empresa de Olinda',
    icon=folium.Icon(color=colors[empresa['neighborhood']])
).add_to(olinda)

Foto do balão de uma empresa após o clique

Um arco-iris

Como falei antes, o folium.Marker() possui cores limitadas, então se você precisar de mais cores, ou se você precisar colocar cores diferentes daquelas disponíveis, use ou o folium.CircleMarker() ou o folium.PolygonMarker(). Ambos aceitam hash de cores.

E aí, vai fazer uns mapas também? 😉

Curiosidades e dicas

Mapas (e dados) abertos

A Leaflet, e assim por consequência também o Folium, usa o OpenStreetMap para montar seus mapas. Os mapas da OpenStreetMap são abertos e construídos por uma comunidade de pessoas interessadas em manter/ajudar o projeto, por exemplo, se você encontrar algum erro em alguma parte do mapa você pode enviar correções. Recomendo dar uma olhadinha na Wiki do OpenStreetMap para mais informações.

`df.iloc[i]`

Forma de visualizar qualquer linha do dataframe como se fosse um print bonito, basta passar como i o índice da linha.

`df.iterrows()`

É muito útil para percorrer as linhas de um dataframe uma a uma. Esse método retorna sempre um índice e a linha correspondente.

A Lei de Benford e a beleza dos números

Thu, 23 Nov 2017 00:00:00 +0000

Conte o número de habitantes de cada cidade brasileira. Coloque isso numa tabela e me diga, quantas vezes cada número (de 1 a 9) se repete como primeiro dígito da contagem. Tá, nós temos 5570 municípios no Brasil, contar a frequência de cada primeiro dígito vai cansar então pode chutar vai, eu deixo. Me diz qual a probabilidade de encontrar o 1 como primeiro dígito? E qual a probabilidade de encontrar o 2 como primeiro dígito?

E se eu te dissesse que, ao contrário do que imaginamos, a distribuição de “primeiros digitos” não é a mesma para os algarismos de 1 a 9 😱😱😱 Pelo menos não num conjunto “natural” ou de números aleatórios.

Os primeiros dígitos num conjunto númerico

Okay, se o que a gente esperava não é verdade, então qual é a verdadeira distribuição?! Foi essa pergunta que Frank Benford ajudou a responder.

Frank Benford

Benford era um físico americano que pegou as observações iniciais de um astronomo Simon Newcomb, generalizou e aplicou para vários datasets provando a existência de um padrão diferente daquele que a gente pensava ali no começo do post.

A Lei

Também conhecida como a Lei dos Primeiros Dígitos, a Lei de Benford define que a probabilidade do primeiro dígito de um número segue uma função logaritímica que mostro abaixo:

\[P (d) = \log_{10} \left(1 + \frac{1}{d} \right)\]

A probabilidadade do primeiro dígito de um número ser $d$ é dada pelo $\log$ na base $10$ de $1 + \frac{1}{d}$. Por exemplo se tomarmos $d = 1$ e $d = 9$ temos:

\[P (1) = \log_{10} \left(1 + \frac{1}{1} \right) = \log_{10} \left(1+1\right) = \log_{10} 2 = 0.3010\] \[P (9) = \log_{10} \left(1 + \frac{1}{9} \right) = \log_{10} \left(1+0.11\right) = \log_{10} 1.11 = 0.0453\]

Com isso sabemos que, a probabilidade de termos um $1$ como primeiro dígito é seis vezes maior de encontrarmos um $9$ como primeiro dígito. Louco né?

Isso é muita matemática pra mim, cadê o código?

Vamos lá! Hoje vou usar R para demonstrar com código como funciona a Lei de Benford. O objetivo dos passos a seguir é crirar um script que gere automáticamente duas coisas:

o gráfico da análise de benford;
o gráfico para a frequência de cada um dos primeiros dígitos no nosso dataset.

Instalando

Comece instalando o R seguindo as instruções disponíveis no site oficial do projeto.

Depois no seu diretório de trabalho, crie um arquivo para instalar as dependências, você pode chamar esse arquivo do que quiser, aqui vou chamar de install_packages.R:

options(repos = subset(getCRANmirrors(), Country == "Brazil")$URL)
install.packages("benford.analysis")

O install_packages.R se encarrega de instalar o pacote benford.analysis que traz pronto um conjunto de funções para analisar os dados contra a distribuição de Benford. Para rodar fazemos:

$ Rscript install_packages.R

Rodando o script

Depois criei um arquivo que chamei de benfords_law.R que vai conter os próximos blocos de código.

Começamos importando/carregando o nosso pacote escolhido. Depois escolhi um dataset que vem com o pacote para esse exemplo (você pode carregar o seu próprio dataset se quiser). Nosso dataset contém o censo da População das Cidades dos Estados Unidos em 2009, veja:

require("benford.analysis")              # Carrega o pacote benford.analysis
data("census.2009")                      # Carrega o dataset 

A função principal desse pacote é a benford(), é ela que faz todos os cálculos em cima dos meus dados para validá-los de acordo com a Lei de Benford. Ela irá receber um array numérico e podemos dizer quantos primeiros dígitos queremos análisar usando o argumento number.of.digits, o padrão para esse argumento é 2, mas aqui vamos usar 1 por questões demonstrativas:

bfd <- benford(census.2009$pop.2009,     # Coluna com o censo por cidade em 2009
               number.of.digits = 1)     # Número de Primeiros Dígitos para analisar

O resultado do método benford() é uma lista. Essa lista possui oito dataframes contendo os resultados de várias contas e testes que vamos usar daqui pra frente. Algumas desses resultados são utilizados para plotar o gráfico principal da análise. E para plotar o gráfico temos o seguinte resultado:

plot(bfd)

Gráfico Original gerado pela função benford().

Agora, vamos reproduzir o primeiro gráfico separadamente. Esse primeiro gráfico traz alguns elementos interessantes:

Cada barra indica a frequência observada para cada primeiro dígito dentro do dataset;
A linha vermelha traça a frequência esperada de acordo com a distribuição de Benford;

Para reproduzir esse gráfico começamos utilizando a função para plotar um gráfico de barras barplot(). Passamos para ela as frequências calculadas pela função benford() para cada primeiro dígito que se encontram em bfd$bfd$data.dist.freq. Os demais atributos setados são para deixar o gráfico de barras mais próximo do gráfico original.

barplot(bfd$bfd$data.dist.freq,          # Valores de frequencia para cada barra
        names.arg = bfd$bfd$digits,      # Legenda de cada barra no eixo x
        col = "#A1DCF0",                 # Coloração das barras
        main = "Digits Distribution",    # Título principal
        xlab = "Digits",                 # Legenda eixo x
        ylab = "Freq",                   # Legenda eixo y
        ylim = range(0:6000),            # Limite no eixo y
        xlim = range(0:10),              # Limite no eixo x
        width = .85)                     # Largura da barra

Como gráficos em R são feitos por camadas, podemos adicionar a linha vermelha usando uma outra função chamada lines(). Essa função acrescenta uma nova camada em cima do gráfico plotado anteriormente criando uma linha. No gráfico original, a linha vermelha corresponde a frequência esperada de cada dígito de acordo com a distribuição de Benford e estão armazenadas em bfd$bfd$benford.dist.freq , então é só passar esse objeto para a função lines(), vejamos:

lines(x = bfd$bfd$benford.dist.freq,     # Pontos para formar a linha
      col = "red",                       # Cor da linha
      lwd=2.5,                           # Espessura da linha
      type="c")                          # Tipo da linha: tracejado

Gráfico de barras gerado utilizando barplot().

Nota com a linha vermelha quase sobrepõe o topo das barras de frequência?! Então da para perceber como o pacote benford.analysis ajuda bastante já que não é necessário fazer na mão todos esses cálculos. Esses são algumas funções básicas, você pode também realizar o teste de qui-quadrado em cima dos dados usando a distribuição de Benford e outras estatísticas.

Benford pra quê?

Tá, mas pra quê isso tudo isso é útil?

Conjuntos númericos que são “gerados naturalmente” ou que sofrem muitas transformações matemáticas como censo populacional, apuração de votações, valores de ações e estatísticas de acesso a sites, são exemplos de datasets que se aproximam da Lei de Benford.

Seres humanos tentando burlar números, muitas vezes desconhecem a Lei de Benford e assumem que os dígitos tem a mesma probabilidade de aparecer ou seguem algum outro padrão diferente do evidenciado por Benford.

Já se usou até a Lei de Benford para identificar diferenças entre frames de leitura de procariotos e eucariotos, mas seu uso mais comum é na identificação de fraudes principalmente em dataset contábeis 💰.

Leitura extra

Aqui tem uns links que andei lendo para ajudar na escrita desse post 💁

Todos os códigos estão nesse repo do GitHub lá também tem um exemplo bem simples de como gerar “fake data” 🙊
Blog post do Giga Matemática: Lei de Benford
Um blogpost (em inglês) sobre como plotar a lei de Benford sem o uso da biblioteca que usei nesse post: Benford’s Law Graphed in R
Vídeo (em inglês) sobre o uso da Lei de Benford para detecção de fraude financeira do Business Insider: How Forensic Accountants Use Benford’s Law To Detect Fraud
Blogpost (em inglês) do DataGenetics: Benford’s Law
Following Benford’s Law, or Looking Out for No. 1

Documenting history with Sphinx

Mon, 30 Oct 2017 11:00:00 +0000

Have you seen those beautiful library documentations around? For example, Bottery or Flask? They are all built with a Python library called Sphinx.

Sphinx was created to generate Python’s own documentation and is now widely used because it facilitates automated library documentation building. One cool thing you can do is use Sphinx to build a history of events as done in the Python Brasil’s Big Kahuna Manual.

With the goal of creating the same type of historical record for regional events, I started a repository for PythonSudeste and now also one for PyConAmazônia which, thanks to Nilo Menezes, has a complete post mortem of the organization made available to the community.

I’ll narrate here the steps I took hoping that more regional event organizers can make the same type of historical record of their events available.

Everything starts with a git repository

I started by adding two files:

requirements.txt: this contains the libraries we’ll use to generate the documentation
README.md: this contains information on how to run the project

The Sphinx project we’ll use here runs in a virtual environment with Python 3. I particularly like using virtualenv to create my environment:

virtualenv .env
source .env/bin/activate # may vary depending on your system

And to install the dependencies:

pip install -r requirements.txt

After installation, we start by running Sphinx’s quickstart:

sphinx-quickstart

This quickstart will ask you numerous questions about how to build your documentation. Some important points about these questions:

Running sphinx-quickstart you’ll need to answer things like “What’s the project name?”, “What’s the author’s name?” and “What’s the content language?”, so it’s important to answer each question carefully ;)
At some point in this questionnaire, the decision is made about separating build and source, and here’s the tip: If you’re going to put it on ReadTheDocs you do not need to commit the build \o/

At the end of this long questionnaire we just answered, you’ll find a ready-to-use structure:

build/

Initially empty, but when we run the build command it will get filled up ;P

source/

That’s where we’ll put all our files that will become pages of our project.

conf.py

The answers we gave during quickstart are stored inside this configuration file and it’s what sphinx uses to generate the .html files from the text files. Note here that Sphinx’s preferred extension is .rst for reStructuredText and I suspect they chose .rst because it’s an indentation-based writing form. 👀

index.rst

It’s from index.rst that Sphinx will build your documentation’s index.html. If you open the index.rst on GitHub you’ll see that it’s relatively simple:

This is the “factory version” of index.rst that is created when running quickstart. With it, you can already run an initial build of the site. To build the site we use make, which is responsible for finding the .rst files in the project directory and “translating” them to .html. Let’s see:

make html

After running the build without errors, the result on screen should look like this:

But Jessica, why build if you said above that ReadTheDocs doesn’t need it? It’s true, but the easiest way to check the result of your work is locally and for that you need the .html pages.

Another thing you’ll need is a way to view these pages. Of course you can just open the .html files in your favorite browser, but another option is to use a server. Servers were added as part of Python 3’s built-in http module and are very useful in cases like this. To start a server process just run:

python -m "http.server"

And using the browser access the path localhost:8000. While running the process from the project root as we did, you should see a listing of all files and directories in your browser:

Then just follow the path to the folder where the .html files are:

When clicking on html/, since it contains an index.html file, your browser will show the result of the build which looks something like this using the factory-generated index.rst:

Result of the first build with the factory index.rst

Content Introduction \o/

All these steps so far were to prepare our project to get to the part we really want. Let’s start by creating a content page called pyconamazonia2017.rst with just a title and create the connection between it and our index.rst.

When running the build we’ll get the following result:

build result for pyconamazonia.rst build result for index.rst

Changing the content of this index.rst a bit to add a cover for example we have:

Note: the image didn’t render here because the link only works within the project since it has a folder containing the image. After building, the page looks like this:

From there, just continue filling and connecting new pages in whatever way you find most interesting ;)

After all this you might think the default theme for the pages isn’t great and want to change it. Sphinx has several built-in themes but here we’ll use the ReadTheDocs theme. First, we start by adding it to requirements.txt:

requirements.txt with the ReadTheDocs theme

And then installing it like this:

(.env) $ pip install -r requirements.txt

Now we just need to change the theme variable value in the configuration file (conf.py) to use the ReadTheDocs theme:

html_theme = 'sphinx_rtd_theme'

And when building again, your home page will look like this:

Considerations

The PyConAmazônia memorial project was structured to receive the highest number of possible contributions. If you want to check out how this is going on GitHub 🎉

And a tip about .rst is to use this cheatsheet when you don’t know how to do something in restructured text 🙃

Now, the part about putting all this online is for the next post, that’s all folks ;)

Acknowledgments

Marco Rougeth and Silvia Benza for reviews.

Documentando a história com Sphinx

Mon, 30 Oct 2017 10:00:00 +0000

Sabe aquelas documentações bonitas de bibliotecas que você encontra por aí? Por exemplo, a documentação do Bottery ou a do Flask? Todas são construídas com uma biblioteca Python chamada Sphinx.

Sphinx foi criada para gerar a própria documentação do Python e hoje é muito utilizada por facilitar a construção automatizada de documentações de bibliotecas. Uma coisa legal que dá para fazer é utilizar Sphinx para construir um histórico de acontecimentos como é feito no Manual do Big Kahuna da Python Brasil.

Com o objetivo de fazer o mesmo tipo de histórico com eventos regionais comecei um repositório para a PythonSudeste e agora também um para PyConAmazônia que, graças ao Nilo Menezes, possui um post mortem da organização completo disponibilizado para a comunidade.

Vou narrar aqui os passos que fiz na esperança que mais organizadores de eventos regionais possam disponibilizar o mesmo tipo de levantamento histórico de seus eventos.

Tudo começa com repositório git

Comecei adicionando dois arquivos:

requirements.txt: esse contém as bibliotecas que vamos usar para gerar a documentação

requirements.txt

README.md: esse contém informações de como rodar o projeto O projeto Sphinx que vamos usar aqui roda num ambiente virtual com Python 3. Eu particularmente gosto de usar virtualenv para criar meu ambiente:

$ virtualenv .env
$ source .env/bin/activate # pode variar depedendo do seu sistema

E para instalar as dependencias:

(.env) $ pip install -r requirements.txt

Depois de instaladas, começamos rodando o quickstart do Sphinx:

(.env) $ sphinx-quickstart

Esse quickstart vai te fazer inúmeras perguntas de como montar a sua documentação. Eu copiei o output em um Gist para que você possa estudar o que responder para cada uma das perguntas e também para que veja as repostas que eu dei. Em sua maioria, eu segui com o padrão já oferecido pelo Sphinx. Alguns pontos importantes dessas perguntas:

Rodando o sphinx-quickstart você precisará responder coisas como “Qual o nome do projeto?”, “Qual o nome do autor?” e “Qual a língua do conteúdo?”, então é importante responder com calma cada uma das perguntas ;)
Em algum momento desse questionário é tomada a decisão sobre separar o build e o source e aqui a dica é: Se for colocar no ReadTheDocs não precisa commitar o build \o/ (mas eu vou falar disso melhor num outro post)

Ao final desse longo questionário que acabamos de responder, você vai encontrar uma estrutura pronta para ser usada:

build/

Inicialmente vazia, mas quando rodarmos o comando de construção do site lá vai ficar cheio de coisa ;P

source/

É lá que vamos colocar todos nossos arquivos que vão virar páginas do nosso projeto.

conf.py

As respostas que demos durante o quickstart ficam armazenadas dentro desse arquivo de configurações e é ele que o sphinx usa para gerar os arquivos .html a partir dos arquivos de texto. Aqui note que a extensão preferida do Sphinx é .rst de reStructuredText e desconfio que escolheram .rst por ser uma forma de escrita baseada em identação. 👀

index.rst

É a partir do index.rst que o Sphinx vai construir o index.html da sua documentação. Se você abrir o index.rst no GitHub você vai ver que ele é relativamente simples:

Essa é a “versão de fábrica” do index.rst que é criada ao rodar o quickstart. Com ela já é possível rodar um build inicial do site. Para fazer o build usamos o make, ele se encarrega de buscar no diretório do projeto os arquivos .rst e “traduzi-los” para .html. Vejamos:

(.env) $ make html

se rodar sem erros, o resultado na tela deve ser parecido com isso:

Mas Jessica, pra quê build se você mesma disse lá em cima que o ReadTheDocs não precisa dele? É verdade, mas o jeito mais fácil de verificar o resultado do seu trabalho é localmente e para isso você precisa ter as páginas .html.

Outra coisa que você vai precisar é uma forma de visualizar essas páginas, claro que você pode apenas abrir os arquivos .html no seu navegador favorito, mas outra opção é usar iniciar um server (servidor). Servidores foram adicionados como parte built-in do módulo http no Python 3 e são muito úteis em casos como esse. Para iniciar um processo servidor basta rodar:

(.env) $ python -m "http.server"

E usando o navegador acessar o caminho localhost:8000. Rodando o processo a partir do root do projeto como fizemos você deve ver uma listagem de todos arquivos e diretórios no seu navegador:

E aí é só seguir pelo caminho até a pasta onde estão os .html:

Ao clicar em html/, por conter um arquivo index.html, seu navegador irá mostrar o resultado do build que fica mais ou menos assim usando o index.rst gerado de fábrica:

Resultado do primeiro build com o index.rst de fábrica

Introdução de conteúdo \o/

Todos esses passos até agora foram para preparar nosso projeto para chegar na parte que realmente queremos. Vamos começar criando uma página de conteúdo chamada pyconamazonia2017.rst apenas com um título e criar a conexão entre ela e nosso index.rst, veja:

Ao rodar o build teremos o seguinte resultado:

resultado do build para pyconamazonia.rst resultado do build para index.rst

Mudando um pouco o conteudo desse index.rst para colocar uma capa por exemplo temos:

index.rst com link para imagem de capa

Nota: a imagem não renderizou aqui pois o link só faz sentido dentro do projeto já que este possui uma pasta que contém a imagem. Depois do build a página fica assim:

A partir daí é só continuar preenchendo e conectando novas páginas do jeito que achar mais interessante ;)

Depois de tudo isso você pode achar que o tema padrão para as páginas não tá legal e querer mudar. O Sphinx possui vários temas embutidos mas aqui vamos usar o tema do ReadTheDocs. Primeiro começamos adicionando ele ao requirements.txt:

requirements.txt com o tema do ReadTheDocs

E depois instalando da seguinte forma:

(.env) $ pip install -r requirements.txt

E agora fica só faltando alterar o valor da variável que indica o tema no arquivo de configuração (conf.py) para o tema do ReadTheDocs:

html_theme = ‘sphinx_rtd_theme’

E ao fazer novo build, a sua página inicial vai ter essa carinha:

Considerações

O projeto do memorial da PyCon Amazônia foi estruturado para receber o maior número de contribuições possíveis. Se quiser corre lá no GitHub pra ver como tá sendo isso 🎉

E uma dica sobre .rst é usar esse cheatsheet aqui quando não souber a forma de fazer algo em restructured text 🙃

Agora, a parte de deixar tudo isso online fica pro próximo post, por hoje é isso pessoal ;)

Agradecimentos

Marco Rougeth e Silvia Benza pelas revisões.

#SerenataDeAmor nesse Hacktoberfest

Mon, 02 Oct 2017 00:00:00 +0000

A Operação Serenata de Amor vive de contribuições, tanto financeiras quanto de código. Pensando nisso, passamos um tempinho escolhendo algumas issues para colocar a label do Hacktoberfest. Se você desenvolve a muito tempo ou começou agora, considere doar um pouquinho do seu tempo e cérebro esse mês para a Serenata.

Pra continuar lendo sobre isso, clica aqui nesse botão 👇

Projetos Brasileiros para fazer pull requests nesse Hacktoberfest

Mon, 02 Oct 2017 00:00:00 +0000

Edição atual da lista disponível aqui.

Se não sabe ainda o que é o Hacktoberfest da uma olhadinha nesse outro post que explico o que é e como participar. Pra quem já sabe e não faz ideia de quais projetos contribuir, aqui tem uma lista de alguns projetos que valem a pena dar uma mão ;)

Pra ver projetos Brasileiros para contribuir clica aqui nesse botão 👇

Ajude algum projeto, ganhe uma camiseta e dê o primeiro passo no mundo do código aberto

Mon, 02 Oct 2017 00:00:00 +0000

Esse texto é especialmente pra você que nunca contribuiu com algum projeto open source antes

Aah o mês de outubro…

O mês de outubro está chegando e para mim, ele fica marcado por duas coisas: a Python Brasil e pelas contribuições em projetos de código aberto. A Python Brasil é assunto para um outro post, hoje quero falar um pouquinho (mais) de open source.

Todo outubro, a Digital Ocean, empresa que provê infraestrutura para computação em nuvem, formaliza a sua parceria com o GitHub para realização do Hacktoberfest.

O Hacktoberfest

É um evento que dura o mês inteiro e busca incentivar a participação em projetos open source, então saber um pouquinho de código para participar é interessante, mas não se deixe intimidar, tem espaço para todos os níveis de conhecimento. E a melhor parte: qualquer pessoa que queira pode participar da sua própria casa!

Objetivos

Abrir quatro pull requests em qualquer repositório público no GitHub independente se esse projeto tem ou não issues marcadas com a label do evento. E não precisa ter seu pull request aceito para ele ser contabilizado — alguns pull requests demoram mesmo para serem revisados e aceitos —, mas imagina que legal ter contribuições aceitas? Todo mundo ganha!

Regras

Cada um dos quatro pull requests precisam ser feitos entre os dias 1 e 31 de outubro em qualquer fuso horário. E não vale fazer spam, pull requests marcados como spam vão te tirar da brincadeira.

Como participar

Você vai precisar ter uma conta no GitHub (vai lá! Faz a sua! É rapidinho 😉). Depois de ter a conta no GitHub, é necessário se cadastrar no evento para contabilizar cada uma das quatro contribuições. Você vai precisar também saber um mínimo de como funciona Git (vou deixar alguns links sobre isso lá no fim no artigo).

Premiação

Além de dar os primeiros passos nessa onda de contribuições, aprender com o feedback que receber no seu pull request e ajudar algum projeto legal, você ainda ganha uma camiseta linda! Isso mesmo, depois de um tempinho, vai chegar na sua casa uma linda camiseta para você mostrar pra todo mundo!

Fonte

Vou deixar aqui alguns links que podem ser úteis e te ajudar a perder o medo.

Contribuições

Recomendo fortemente ler o texto da Leticia Portella sobre como contribuir para um projeto sem escrever código. E, se inglês não for um problema, leia também o Open Source Guide sobre como contribuir, não importa se você é um veterano ou iniciante em contribuições.

Git

Para aprender Git, você pode seguir o curso de Git da codecademy ou o curso da CodeSchool, ambos muito bons. Git não é fácil, mas todo mundo pode aprender.

Hacktoberfest

Dá para conferir o que rolou na Hacktoberfest 2015 e na Hacktoberfest 2016. Muito importante também, o site oficial do evento para mais informações.

Também dá para conferir quantos pull requests foram feitos depois de ter se cadastrado 😉

Projetos para contribuir

Tá aqui a lista de projetos brasileiros que estão aceitando pull requests nesse mês de outubro. Happy hacking! 🎉

Originalmente postado no meu Medium.

Deploy automatizado para o PyPI usando Travis-CI

Thu, 28 Sep 2017 03:00:00 +0000

Como o Travis pode te ajudar a automatizar o lançamento de novas versões de um pacote Python para o Python Package Index.

Pessoas que escrevem bons códigos normalmente seguem a filosofia DRY (“don’t repeat yourself” ou não se repita). Além de fazer isso em código, muitas fazem o mesmo para tarefas que vão ter que ser repetidas com certa frequência: subir uma nova máquina virtual, configurar o ambiente de trabalho ou até mesmo o deploy de novas versões de código. Evitar repetições e automatizar processos se torna algo muito presente no nosso trabalho diário principalmente por ser uma das essências da computação.

Pra continuar lendo esse artigo e saber como funciona o deploy automatizado do Serenata Toolbox usando o Travis, corre lá para a revista do Serenata de Amor 👇

Em quem você pensa quando te pedem uma indicação?

Thu, 21 Sep 2017 03:00:00 +0000

Você conhece mulheres qualificadas. Por que não indicá-las?

Dei várias palestras ao longo deste ano e se tornou comum as pessoas me chamarem para combinar outras palestras, ser mentora em hackathons, organizar eventos e afins. Algumas vezes minha agenda não me permite aceitar os convites como eu gostaria e então essas pessoas me fazem a fatídica pergunta: Me indica alguém?

Pra continuar lendo esse artigo corre lá para a revista do Code Like a Girl 👇

9º Seminário Catarinense de Transparência e Controle

Tue, 29 Aug 2017 00:00:00 +0000

Da esquerda para direita: Pedro Vilanova, Jessica Temporal e Rodrigo De Bona

Palestra conjunta com o Pedro Vilanoca no 9º Seminário Catarinense de Transparência e Controle Social que rolou em Florianopólis à convite do Rodrigo De Bona.

Evento

9º Seminário Catarinense de Transparência e Controle Social

Apresentação

II Workshop Tecnologia para Transparência

Tue, 29 Aug 2017 00:00:00 +0000

Palestra conjunta com o Pedro Vilanoca no II Workshop Tecnologia para Transparência que rolou em Balneário Camboriú.

Evento

II Workshop Tecnologia para Transparência

Apresentação

Versionamento semântico: um passo além do Git

Mon, 14 Aug 2017 03:00:00 +0000

“No mundo de gerenciamento de software existe algo terrível conhecido como inferno das dependências (“dependency hell”). Quanto mais o sistema cresce, e mais pacotes são adicionados a ele, maior será a possibilidade de, um dia, você encontrar-se neste poço de desespero.” — Versionamento Semântico 2.0

Pacotes, sejam eles escritos em Python, Ruby ou JavaScript, além de terem seu código versionado por sistema como o git, podem possuir mais um nível de controle de versão: o versionamento semântico.

Pra continuar lendo esse artigo e saber como funciona o versionamento semântico, corre lá para a revista do Serenata de Amor 👇

Ciências de Dados com o Serenata de Amor: Pyladies SSA

Sat, 05 Aug 2017 00:00:00 +0000

Ciências de Dados com o Serenata de Amor

Evento

Encontro Pyladies SSA + GrupyBA

Apresentação

Serenata Toolbox no PyPI

Thu, 27 Jul 2017 03:00:00 +0000

Um roadmap para liberar um módulo no Python Package Index ;)

Eventualmente pessoas que desenvolvem software chegam num momento que possuem um projeto que pode ser empacotado e distribuído para a comunidade. Para quem programa em Python é comum rodar um pip install — semelhante ao gem install do Ruby e ao npm install do Node — e instalar módulos Python disponíveis no PyPI. Pra quem não conhece, o PyPI é a casa mais famosa de pacotes Python, o index de pacotes Python.

Pra continuar lendo esse artigo e saber como foi colocar a Serenata Toolbox no PyPI corre lá para a revista do Serenata de Amor 👇

Data Science for Business Weekend Maceió

Fri, 30 Jun 2017 00:00:00 +0000

Conheça o projeto Serenata de Amor, uma iniciativa de ciência de dados com código aberto e financiamento coletivo que construiu uma plataforma de inteligência artificial capaz de minerar e buscar discrepâncias na prestação de contas dos gastos de nossos deputados federais. Entenda como o projeto começou, como ele foi feito, os promissores resultados alcançados até o momento, quais são os próximos passos e como você pode nos ajudar a fiscalizar ainda mais os nossos representantes.

Evento

Data Science for Business Weekend - Maceió

Código

O código que mostrei estão todos disponiveis e se quiserem rodar o notebook localmente recomendo usar o Serenata Toolbox para fazer o fetch dos arquivos utilizados.

Apresentação

Meetup - Mecanismos de prevenção e combate a corrupção

Thu, 18 May 2017 00:00:00 +0000

Evento

Meetup: Mecanismos de prevenção e combate a corrupção

Apresentação

Comunidade Python e Rio de Janeiro

Wed, 10 May 2017 00:00:00 +0000

Uma história de amor

Uma frase que eu ouvi desde o primeiro dia que conheci parte da galera de Python em Ribeirão Preto e não demorei muito tempo pra entender:

Faça parte da comunidade.

Lembro como se fosse hoje o convite para a galera que deu o curso introdutório de Django e Python na semana acadêmica de Informática Biomédica que rolou em 2015. Por algum motivo, esse convite e 15 minutos de conversa durante o almoço já me cativaram. Essas pessoas que estavam ali passaram a ser pessoas que eu admiro e que tive prazer de até trabalhar durante um tempo. E posso com certeza dizer que, não vai ser a última vez que conhecer pessoas foi algo importante pra mim.

Foi a partir desse dia que descobri que programar não é ficar trancada com um computador 24h do meu dia e ser anti-social com as pessoas a minha volta. Que tão importante quanto escrever código é ouvir e dar feedback. Que aprender e ensinar muitas vezes estão de mãos dadas.

Essas coisas ninguém te fala.

São coisas que parece que todo mundo já sabe, mas você que tem que chegar a essa conclusão sozinha, no seu tempo e no seu jeitinho, porque isso te muda, e te muda de um jeito bom!

Python Sudeste 2017

Primeiro evento pós formar \o/

Dessa vez não tinha provas pra estudar e fazer logo depois da viagem. Não tinha matéria atrasada pra estudar correndo. Não tinha reunião de TCC. Tinha PRs no projeto do trabalho para fazer. Tinha código pra revisar e tinha também e-mails de trabalho pra responder.

Obrigações diferentes. Mas ainda assim, posso dizer que o clima de eventos da comunidade Python é sem igual e independe da realidade que cada um precisa voltar depois!

Conheci pedacinhos novos do Rio de Janeiro.

Curto Café: amor na xícara ❤️

Conheci novas pessoas e posso dizer que fiz novas amizades que vão durar pra sempre.

Colina PyLadies ❤ 4eva! Colina 4 x 1 PyBunker. Créditos a Silvia pela foto.

Conversei, comi e bebi bastante também. Se tem algo que essa galera faz bem além de codar são essas três coisas.

A conta mais barata do evento: Tinha pudim!

Teve praia…

… e também karaokê.

Teve Install Fest do Serenata na base do improviso.

Oh eu ali no fundo o/

E palestra relâmpago com perguntas e respostas do Serenata.

Eu e Eduardo Cuducos participando no Q&A de 5 minutos \o/

Sempre que tem Python tem também muito amor envolvido.

Deixo aqui registrado que a PySe2017 foi linda e que as definições de evento f*da foram atualizadas.

Mal posso esperar pra encontrar todo mundo nos próximos Caipyra, Python Brasil ou até mesmo na PySe2018 (já anota aí que vai ser em São Paulo). Estarei lá curtindo demais todo mundo em várias cidades desse Brasilzão.

Originalmente postado no meu Medium.

Sprint Operação Serenata de Amor

Fri, 28 Apr 2017 00:00:00 +0000

Install Fest do projeto para o sprint do final de semna

Evento

Sprint Florianópolis - Operação Serenata de Amor

6º Redes e-Gov

Fri, 28 Apr 2017 00:00:00 +0000

Apresentação do que a tecnologia da Operação Serenata de Amor faz, usando diversas base de dados, do governo ou privadas, mas todas públicas para fazer uma auditoria automatizada dos gastos da Cota para Exercício de Atividade Parlamentar. Debate com o público sobre fiscalização, respostas insatisfatórias dos órgãos públicos, e a moralidade dos gastos públicos.

Evento

6º Redes e-gov

4º Pyladies Floripa

Thu, 27 Apr 2017 00:00:00 +0000

Vídeo

Utilizando dados abertos para denunciar discrepâncias nas prestações de contas dos deputados federais.

Evento

4º PYLADIES FLORIPA

Apresentação

Workshop Mineração de Dados e Inteligência Artificial

Thu, 20 Apr 2017 00:00:00 +0000

Palestra conjunta com o Eduardo Cuducos no Workshop sobre Mineração de Dados e Inteligência Artificial da Receita Federal de Bauru.

Apresentação

Serenata pelo Brasil a fora

Mon, 10 Apr 2017 03:00:00 +0000

Durante o mês de março, estivemos presentes em vários eventos espalhados pelo Brasil e gostaríamos de contar um pouco mais sobre como foi cada um deles.

Março foi o quinto mês de trabalho da Operação Serenata de Amor. E além de todos os nossos esforços em data science e programação com a implementação de novos classificadores, coleta de novos dados e validação novas hipóteses — tudo isso feito em conjunto com uma linda comunidade de código aberto no GitHub — também tivemos a honra de participar de vários eventos.

Pra continuar lendo esse artigo e saber mais como foi o mês de março no Serenata corre lá para a revista do Serenata de Amor 👇

Hackathon da Saúde

Fri, 07 Apr 2017 00:00:00 +0000

Hackathon da Saúde

Cloud Girls Meetup

Tue, 04 Apr 2017 00:00:00 +0000

Utilizando dados abertos para denunciar discrepâncias nas prestações de contas dos deputados federais.

Evento

Cloud Girls Meetup

Apresentação

Big Data Meetup: Serenata de Amor

Wed, 29 Mar 2017 00:00:00 +0000

Utilizando dados abertos para denunciar discrepâncias nas prestações de contas dos deputados federais.

Evento

São Paulo Big Data Meetup (Março 2017)

Apresentação

Uma história de Pair Programming a longa distância

Sat, 11 Mar 2017 00:00:00 +0000

Pair programming, parear, escrever código em dupla. Quem escreve código, alguma vez na vida já pareou, e se não o fez ainda, provavelmente irá fazer isso em algum momento da vida. Para os estudantes da arte da programação que escrevem código em grupo, pair é uma técnica tão normal que muitas vezes nem percebem que estão fazendo.

Escrever código em par é bom por uma série de motivos, dentre eles gosto de destacar o aumento de produtividade e foco, oportunidade de aprendizado e também diversão. Desenvolver um programa ou um script a quatro mãos, é uma das experiências mais gostosas de ser programadora.

Trabalho remoto e programação a longa distância

Muitos podem achar que para parear é necessário estar na mesma sala que o seu par. Quem trabalha remotamente sabe o quanto isso não é necessariamente verdade.

Para um time de desenvolvedores que trabalha junto, programar a longa distância é mais uma das coisas fantásticas que programadores fazem e isso vem muitas vezes de mãos dadas com o trabalho remoto. No time da Serenata, podemos contabilizar horas e horas de telaselfselfs compartilhadas, sejam entre aqueles trabalhando na mesma cidade (Irio Musskopf e Ana Schwendler), ou entre aquelas trabalhando em estados diferentes (Eduardo Cuducos e eu).

Nós usamos os olhos dos colegas de trabalho como forma de escrever um código melhor e também como fonte milagrosa da dádiva do desempacamento. Usar a tecnologia à nosso favor na hora de programar é uma arte.

Quem pareia tem suas formas preferidas, eu vou falar uma das minhas. Programo e m Python, e no meu dia a dia uso:

O Ubuntu: meu sistema operacional oficial desde 2015;
O terminal do Ubuntu: meu companheiro para todas as horas;
VIM: o editor de texto dos viciados em telas pretas e atalhos de teclado;
tmux (e tmate): o multiplexador de terminais queridinho dos devs.

VIM

VIM é um editor de texto altamente configurável e focado em eficiência. Mas também é conhecido por não ser fácil de usar pois é uma ferr amenta que precisa ser aprendida antes de ser utilizada. A frase “não deixo de usar vim pois não sei como sair dele” é a piadinha mais comum de se ouvir pelas pessoas de tech.

Tela inicial do VIM

Para usar o VIM você precisa saber algumas coisas básicas:

Ele possui modos diferentes de uso: como o de inserção que serve para escrever e o modo de comando que usamos para informar ao vim comandos que queremos executar;
Os comandos do VIM são escritos, coisas como set number, para mostrar os núme ros da linha, set cc=80 (color column) mostra uma coluna no octagésimo caracter de todas linhas e wq (write and quit) para salvar o arquivo e sair do editor.

O VIM foi feito para que tudo que você queira fazer no editor possa ser feito s em remover as mãos do teclado.

tmux e tmate

Quem desenvolve usando o terminal às vezes se pega tendo que abrir mais de uma janela, por exemplo, se eu estiver rodando um web-app, eu provavelmente vou ter um terminal rodando um server, um outro com acesso ao código que estou editando , se forem tanto o html quanto o css isso já me dá três janelas abertas.

sessão tmate com vim, server, tree e ipython tudo rodando ao mesmo tempo

Para eliminar essa quantidade excessiva de janelas abertas, o tmux foi desenvolvido, ele é um multiplexador de terminais e permite que você tenha todos os arquivos e processos rodando e mostrando resultados na mesma tela. Com base no tmux, surgiu o tmate, que além de usar todas as maravilhas que o tmux tem, ele ainda abre um canal de comunicação seguro para que o seu mate (amigo) possa se conectar por meio de uma sessão s sh. E o melhor é que o seu mate não precisa nem estar num ambiente que provê ac esso ssh, lhe basta um navegador.

Uma vez aberto o canal iniciado com um simples tmate no seu terminal, você pode mandar o link de acesso para quem quiser e, caso o link enviado não seja o read -only, a pessoa do outro lado da conexão poderá programar no seu computador.

Assim como o VIM, tmux /tmate possui modos e atalhos de teclado para sua utiliz ação. E eu recomendo fortemente essa palestra do Marco Rougeth par a usar de referência com esses comandos.

Canal por voz

Junto ao editor de texto, que para essa estrutura funcionar precisa ser um que abra no terminal, e o terminal compartilhado, eu ainda uso algum canal por voz.

Já usei: Zoom, Hangouts, a ppear.in e Skype e nesse caso é muita questão de escolha pessoal, disponibilidade de banda e quanto cada um d esses influencia na capacidade de processamento do seu computador.

Essa é uma alternativa ao famoso screen share trazida pelos grandes programas d e video-conferência. No meu computador que traz uma capacidade de processamento limitada, VIM + tmate + Hangouts, tem se mostrado uma forma graciosa de trabalh ar a distância sem os tantos travamentos que já atrapalharam por diversas vezes.

Tendo à mão todas essas tecnologias e um pouquinho de treino, pair será um mome nto legal de muito código escrito a quatro mãos.

Obrigada ao grupy-rp por me apresentar e me treinar na arte do vim, tmux e pair programming; ao Marco muito obrigada por me apresentar tmate, tmuxp (um gerenciador de sessões do tmux) e outras mara vilhas como essas; ao Otávio obrigada pelas dicas e feedback; e ao time do Sere nata obrigada pelas oportunidades diárias de pair programming ❤ ❤ ❤

Serenata de Amor: Machine Learning Meetup

Thu, 09 Mar 2017 00:00:00 +0000

Na apresentação vamos falar o que é a Operação Serenata de Amor, como o time (e seus colaboradores) coleta e seleciona os dados para encontrar discrepâncias nos gastos dos deputados, como essas hipóteses são desenvolvidas, validadas e depois ensinadas para Rosie.

Evento

Machine Learning, Big Data e Engenharia Meetup

Apresentação

Meu medo de formulários

Thu, 09 Feb 2017 00:00:00 +0000

Hoje, entre um build e outro, preenchi mais um.

Vou começar contando uma história pra vocês — como faço quase sempre — era uma vez…

Numa terra muito, muito distante, o reino encantado onde todos eram seguros de si e não se questionavam. Mas num belo dia, o terrível Impostor atacou e lançou um feitiço que chamamos de Síndrome do Impostor e fez com que todos moradores do nosso belo reino se encherem de inseguranças e começarem a se sentir incapazes de fazer aquilo que são treinados (muito bem) para fazer.

Esse feitiço é traiçoeiro, ele não age sobre os habitantes do reino sempre. Ele vai agindo devagarinho e quando vemos… pá! Estamos duvidando das nossas habilidades. Saber que estamos sofrendo da síndrome é um começo mas não é uma solução permanente, e nós que somos acometidos por essa mazela, precisamos estar sempre atentos aos sintomas.

No meu caso particular, além de bugs nos meus códigos, uma coisa que faz a síndrome atacar com todas as forças, é a necessidade de preencher algum formulário.

Você pode pensar que ao terminar a faculdade as inseguranças, “Será que vou tirar nota boa nessa prova?”, “Será que eu consigo terminar esse trabalho a tempo?”, “Será que eu vou conseguir formar?” iriam se dissipar, mas na verdade, elas não dissipam. Muito pelo contrário. Elas evoluem. Agora, trabalhando, você tem que prestar contas à alguem além de você mesmo pelo código que faz.

E não só no trabalho, parte das coisas que gosto de fazer envolvem eventos de tecnologia por aí, seja organizando ou frequentando, se ninguém te exigir saber fazer as coisas, você se cobra. Alguns dos eventos que anotei na minha agenda pra esse ano, possuem formulários de participação, como por exemplo o Django Girls São Paulo que, para ser uma treinadora você tem que preencher um formulário.

É nessa hora, na hora que eu sei que tenho que falar de mim, do que eu sei que começa a atuar a dona síndrome… “Quem, em sã consciencia, vai me escolher pra ensinar alguma coisa pra alguem?”. E nessas horas que eu preciso parar e pensar feito a Camila fala nesse vídeo:

É aí que eu paro de pensar e me agarro na minha vontade de fazer alguma coisa. Eu quero ensinar, então vou lá e preencho o formulário do Django Girls São Paulo. Eu quero ir em algum evento, mas tô sem verba?! Então vou e preencho o fomulário de pedido de ajuda de custo.

Começar a fazer algo é díficil, mas para atingir o objetivo você precisa de fato começar em algum lugar. O querido Eduardo Cuducos, deu um exemplo perfeito nesse post aqui no blog dele, segundo ele, é um exemplo bobo, mas pra mim representa perfeitamente a lógica que estou seguindo:

O que você precisa para correr uma maratona? Precisa começar a correr. Claro que você não vai correr os 42km de uma maratona logo no primeiro dia. Mas vista um tênis, saia de casa e vá correr. Corra 2km, 3km… 10km que seja. Sem começar, sem correr o primeiro quilômetro, você nunca vai chegar na maratona.

Eu quero correr as minhas maratonas. Então comecei a correr. Só que pra mim as maratonas são os eventos, e o começo são os formulários.

“Pessoas magníficas que vão lá e fazem…”

Quero ser dessas pessoas que fazem. Posso não ser a mais indicada, posso falhar. Mas também posso dizer que fui lá e fiz.

O Django Girls São Paulo ainda está recebendo inscrições para treinadoras, e as inscrições para participantes já estão abertas! Se inscreve vai! ❤️

Postado originalmente no meu Medium.

Esfarelou, virou purpurina

Thu, 02 Feb 2017 00:00:00 +0000

Porque somos tão relutantes em sentir e expressar amor? Não sei vocês. Mas eu amo todos os dias.

Amo com a mesma intensidade do calor trazido pelos raios de sol que viajam por e milhares e milhares de km até chegar na terra e esquentar a pele daquela moça que passeia alegremente pelo parque num domingo de sol.

Ainda assim, sou relutante em dizer, àqueles que amo. Por que será? Por que impomos à nós mesmos e aos outros a prisão que é sentir e não expressar amor?

Passaram-se segundos, esses tornaram-se minutos que cresceram em horas. Essas viraram noites em claro e ainda não tenho resposta.

Dei um passo para trás. Mudei a pergunta: Que horas hoje vou dizer que te amo? Depois de me espreguiçar preguiçosamente na cama, abrir um olho e o sorriso largo?

Depois que você me disser bom dia enquanto se veste? Já sei! Depois que o maravilhoso cheiro de café invadir a sala, então o quarto e finalmente nossos pulmões. Não, ainda não me parece boa hora…

Só sei que falarei hoje.

Sou um espírito livre, mas meu coração age como se trouxesse uma bola de ferro amarrada à perna enquanto eu não expresso aquilo que ele guarda. A prisão imposta não é feita de quatro paredes, sem janelas ou portas mas parece que impossível sair.

Ao dizer que te amo, paredes se esfarelam levando junto a corrente que amarra a bola de aço. Esfarelaram, viraram purpurina e grudaram na gente pra fazer a gente brilhar.

Te amo e vou dizer toda vez que der vontade.

Você não precisa dizer de volta não. Sei o quanto foi difícil pra mim transformar em purpurina a corrente que impedia meu coração de voar e as paredes que impediam de sentir o sol esquentar a pele.

Sei que você me ama também.

Enquanto tu tá aí, nas tuas amarras, eu aproveito que as minhas se desfizeram e falo por nós. Quem sabe assim tu aprende a dizer também e se liberta.

Era só isso que queria dizer hoje.

Te amo.

Even core devs have hiccups ¯\_(ツ)_/¯

Wed, 01 Feb 2017 00:00:00 +0000

After a few months working on a open-source project sometimes I still find myself having trouble with some things. And that is okay! This time was with PostgreSQL.

As some of you know I work on a project called Serenata de Amor Operation. One of the tools we developed is called Jarbas. It is a web application with a Django backend using PostgreSQL for database. So the last time I configured and ran Jarbas was last year on a Linux computer it also was the first time I contributed for the project. Not much mystery there, but now I’m on a MacOS machine and things are a bit different.

So I started by installing PostgreSQL with brew (which I highly recommend). Homebrew makes the installation process pretty straightforward. The command line for it is:

$ brew install postgresql

You may think that’s it. Easy peasy. Then just go to Jarbas cloned repository and the first thing to do would be creating a .env file and then running the traditional Django command python manage.py migrate. And that’s where I got the first error:

$ python manage.py migrate
Traceback (most recent call last):
File “/Users/temporal/anaconda3/envs/jarbas/lib/python3.5/site-packages/django/db/backends/base/base.py”, line 213, in ensure_connection
self.connect()
File “/Users/temporal/anaconda3/envs/jarbas/lib/python3.5/site-packages/django/db/backends/base/base.py”, line 189, in connect
self.connection = self.get_new_connection(conn_params)
File “/Users/temporal/anaconda3/envs/jarbas/lib/python3.5/site-packages/django/db/backends/postgresql/base.py”, line 176, in get_new_connection
connection = Database.connect(**conn_params)
File “/Users/temporal/anaconda3/envs/jarbas/lib/python3.5/site-packages/psycopg2/__init__.py”, line 130, in connect
conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
psycopg2.OperationalError: could not connect to server: Connection refused
Is the server running on host “localhost” (::1) and accepting
TCP/IP connections on port 5432?
could not connect to server: Connection refused
Is the server running on host “localhost” (127.0.0.1) and accepting
TCP/IP connections on port 5432?

That’s when you ask yourself: Wait, what? What kind of error is that?

After a few minutes searching I came across this wonderful Stackoverflow thread. I’ll break it down for you: After you install PostgreSQL probably (like me), you’ll have to start the service and initialize a database for you to use. I won’t copy here the steps described on the thread but there you’ll see it gives you two choices at a given moment:

Either load the launch agent;
Start the agent.

I chose to start it since it was my first time doing this it was logical that this was a safe choice to go on.

After starting it, I needed to check whether it worked or not. You never now util you test it right? And to do so, we try to connect into PostgreSQL by doing this:

$ psql -d postgres

That only gave me a running Postgres client I still needed a database.

Jarbas app expect a database called jarbas. So that’s the name we give when creating the new database by doing:

$ createdb jarbas

As you might expect, that wasn’t enough once more. Tried again to run the migrate command and this happened: django.db.utils.OperationalError: FATAL: role "Jarbas" does not exist.

Don’t you just love dev life?!

Let’s create a Role then:

$ psql -d postgres
=> CREATE ROLE jarbas;

And once again got an error: django.db.utils.OperationalError: FATAL: role "jarbas" is not permitted to log in. Now we need to give the role permissions, why that didn’t cross my mind before?

$ psql -d postgres
=> ALTER ROLE jarbas LOGIN;

Again with the migrate command and voilà:

And then you get to the point where you might think: How the hell am I supposed to know if everything is working properly? Well, Jarbas has test suites so you might try to run tests and they will fail:

$ python manage.py test                                         
Creating test database for alias 'default'...
Got an error creating the test database: permission denied to create database

Type 'yes' if you would like to try deleting the test database 'test_jarbas', or 'no' to cancel: no
Tests cancelled.

You’ll need to make another modification on jarbas role to give it permissions to create a database:

$ psql -d postgres
=> ALTER ROLE jarbas CREATEDB;

After that, tests beautifully pass:

Até core devs tem atrapalhos ¯\_(ツ)_/¯

Wed, 01 Feb 2017 00:00:00 +0000

Depois de alguns meses trabalhando em projeto open-source eu ainda me encontro problemas com algumas coisas. E tudo bem! Dessa vez vou contar o causo do PostgreSQL.

Como alguns de vocês sabem, eu trabalho na Operação Serenata de Amor. Uma das ferramentas que nós desenvolvemos é chamada de Jarbas. Ele é uma aplicação web com backend em Django usando PostgreSQL para banco de dados. A última vez que eu configurei e rodei o Jarbas foi o ano passado e eu estava usando um computador com Linux. Sem muitos mistérios, essa também foi a primeira vez que contribui para o projeto. Mas agora, eu estou usando uma máquina MacOS e as coisas são um pouquinho diferente.

Eu comecei instalando o PostgreSQL usando brew (recomendo veementemente). Homebrew torna o processo de instalação relativamente simples. O comando para isso foi:

$ brew install postgresql

Você pode pensar que é apenas isso. Mamão com açúcar. Então é só ir para o repositório do Jarbas que você clonou e criar o arquivo de configuração de ambiente - .env - e rodar o tradicional comando do Django python manage.py migrate. E foi é aí que encontramos o primeiro erro:

$ python manage.py migrate
Traceback (most recent call last):
File “/Users/temporal/anaconda3/envs/jarbas/lib/python3.5/site-packages/django/db/backends/base/base.py”, line 213, in ensure_connection
self.connect()
File “/Users/temporal/anaconda3/envs/jarbas/lib/python3.5/site-packages/django/db/backends/base/base.py”, line 189, in connect
self.connection = self.get_new_connection(conn_params)
File “/Users/temporal/anaconda3/envs/jarbas/lib/python3.5/site-packages/django/db/backends/postgresql/base.py”, line 176, in get_new_connection
connection = Database.connect(**conn_params)
File “/Users/temporal/anaconda3/envs/jarbas/lib/python3.5/site-packages/psycopg2/__init__.py”, line 130, in connect
conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
psycopg2.OperationalError: could not connect to server: Connection refused
Is the server running on host “localhost” (::1) and accepting
TCP/IP connections on port 5432?
could not connect to server: Connection refused
Is the server running on host “localhost” (127.0.0.1) and accepting
TCP/IP connections on port 5432?

Esse é o momento em que você se pergunta: Pera, o quê? Que tipo de erro é esse?

Depois de alguns minutos procurando, eu encontrei essa maravilhosa conversa no Stackoverflow. Vou simplificar aqui: Depois de instalar o PostgreSQL você muito provavelmente (como eu) terá que iniciar o serviço e uma base de dados para você utilizar. Eu não vou repassar os passos descritos no stackoverflow aqui mas chega um ponto onde você terá duas opções:

Carregar o agente de inicialização;
Inicializar de fato o agente.

Como era minha primeira vez fazendo isso, eu achei que era um caminho mais lógico inicializar um novo agente.

Depois da inicialização, eu preciso checar se está funcionando ou não. Nunca se sabe até testar, num é mesmo? E para fazer isso, nós podemos conectar ao PostgreSQL:

$ psql -d postgres

Isso me deu apenas o Postgres rodando, eu ainda preciso de uma base de dados.

O app do Jarbas espera uma base chamada jarbas. Então vamos dar esse nome para nossa nova base de dados fazendo o seguinte:

$ createdb jarbas

Como você pode esperar, isso não foi o suficiente. Eu tentei rodar novamente o comando de migração e aí isso aconteceu: django.db.utils.OperationalError: FATAL: role "Jarbas" does not exist.

Aah como não amar a vida de dev?!

Então vamos criar um papel:

$ psql -d postgres
=> CREATE ROLE jarbas;

E de novo estourou um erro: django.db.utils.OperationalError: FATAL: role "jarbas" is not permitted to log in. O que falta agora é dar permissões para o papel , não sei como não pensei nisso antes…

$ psql -d postgres
=> ALTER ROLE jarbas LOGIN;

Agora rodando mais uma vez o comando de migração e voilà:

E aí chegamos no ponto onde podemos pensar: Como diabos vou saber se tá tudo funcionando como deveria? Bem, Jarbas tem suites de teste que você pode tentar rodar, aí elas vão falhar:

$ python manage.py test                                         
Creating test database for alias 'default'...
Got an error creating the test database: permission denied to create database

Type 'yes' if you would like to try deleting the test database 'test_jarbas', or 'no' to cancel: no
Tests cancelled.

Vamos precisar fazer outra modificação no papel jarbas e dar para esse papel a permissão para criar novos bancos de dados:

$ psql -d postgres
=> ALTER ROLE jarbas CREATEDB;

E aí, finalmente os testes passam lindamente:

The moving

Thu, 26 Jan 2017 00:00:00 +0000

A letter to my friends

I move a lot. At least a lot considering that most of the people I met lived in one city or maybe two. So far I moved to 7 cities. I lived in 11 houses. And I still haven’t figured out the whole “having friends that live far away” part.

I recently graduated and moved again. I’m four hours and a half car ride distant from most of my beloved friends and the city that I consider home. A part of me is missing. And don’t get me wrong. I love to move, I can box up a n entire house in one day and have it organized and ready to live in the next. The process of moving is quite easy for me. I would dare to say is cleansing and matches my internal disquietude.

And yet, the leaving your friends and changing the “Let’s go to the bar together” for “Call me so we can update each other on the news” is still annoying to say the least. My heart aches for the closeness. It aches for the “I’ll be over in ten, be ready!”. The tight, crush your ribs, leave you out of breath, heart warming hugs. It misses the Sunday afternoons on a city bench eating ice cream and talking about life.

And even though it was with a heavy heart that I left that town and friends, weight that makes my breathing difficult as write this, I would do it all over again. Because no one can take away the love we feel for the people that make our lives seem hole. But giving up the opportunity to meet other people that would make my heart grow further is something I’m not ready to do just yet.

Originally posted on my Medium.

O que 1024 caracteres não me deixaram falar

Mon, 23 Jan 2017 00:00:00 +0000

Enquanto eu estava preenchendo o formulário de apoio financeiro da PyCon, me deparei com a seguinte pergunta: Your Involvement (‘Seu Envolvimentor’ em tradução livre). Não era bem uma pergunta. Estava mais para um enunciado seguido de uma caixa de texto em branco, e logo embaixo de caixa em cinza claro a frase: “Descreva seu envolvimento em qualquer projeto open source ou em comunidades Python, locais ou internacionais”.

E eu pensei ‘Okay, eu entendi. Posso escrever isso!’. Consequentemente, fiz uma lista de todos os tópicos que eu fazia questão que aparecessem em minha resposta. E foi aí que eu notei.

Acredito que isso se chama bloqueio criativo. Exato, eu, supostamente, deveria falar de mim e do que eu gosto de fazer, mas eu não conseguia. Vai entender essas coisas, né? Então, eu dei respirei fundo. Andei um pouco pelo quarto. Respirei fundo mais uma vez. Ainda usei esse meio tempo para beber uma água.

E então, como mágica, as palavras surgiram. Mal sabia eu que aquela caixa tinha apenas 1024 caracteres, e eu acabei escrevendo 2782. Oops. Depois de colocar meu coração e alma nessa resposta, antes de diminuir-la a 995 caracteres, decidi que iria postar a versão inteira aqui. Então senta que lá vem história.

Eu faço parte de do grupo de usuários Python em Ribeirão Preto (uma cidade no Estado de São Paulo), mais conhecido como grupy-rp, desde o fim de 2015 quando os meninos que faziam parte desse grupo foram dar um mini-curso na semanaa semana acadêmica do meu curso. Era uma introdução a Python e Django com deploy de webapp simples para o Heroku.

A maior parte do Grupy-RP é composta por homens e mesmo assim eu continuei indo aos encontros e me tornei parte daquilo que eu gosto de chamar de família tech. Um dos meninos do grupo me apresentou ao PyLadies, um conceito que eu não fazia ideia da existência. Foi então que eu entrei em contato com as outras ladies espalhadas pelo Brasil. E foi assim que eu conheci a segunda coisa que eu mais amo sobre Python: um grupo de mulheres que trabalham juntas com uma ferramenta que amo.

O grupy-rp também organiza um evento local chamado Caipyra, e foi nesse evento que eu conheci alguns desenvolvedores(as) maravilhosos(as). Nessa mesma época, o mesmo amigo que me apresentou as PyLadies (que iriam trabalhar comigo para criar um novo grupo local) falou que tinha uma vaga aberta na startup que ele trabalhava para um estágio de desenvolvimento web com Python, e disse “Você tem que se candidatar!”. Depois de muita conversa e fazer e refazer o Tutorial das Django Girls, e eu comecei a gostar da ideia de me tornar uma webdev. E foi assim que eu me candidatei.

Entre outros candidatos, eu fui escolhida para trabalhar lá. Naquela época, eu já me sentia em casa. Já estava acostumada a ir a eventos menores, conversava sobre Python com as pessoas que eu conhecia e eu caí de cabeça em um estágio com o cara que eu considero um dos meus mentores. Foram sete meses intensos. Muitas dúvidas em relação a mim mesma e síndrome do impostor para lidar. Porém, hoje sei que todos os dias eu posso me tornar uma desenvolvedora melhor.

E ser uma desenvolvedora melhor também inclui ir a eventos e ensinar o que você sabe para outros então, quando surgiu a oportunidade de me tornar uma tutora no Django Girls, eu não pude deixar deixar escapar. Me inscrevi como instrutora do Django Girls que rolou durante a Python Brasil de 2016 e recebi uma resposta positiva alguns meses depois de fecharem as inscrições. Eu não podia me sentir mais amada.

Claro que para tudo isso acontecer eu precisei, e tive, incentivo dos meus amigos e mentores da comunidade Python. Essa comunidade linda que me aceitou de braços abertos e, quando a hora chegou, fez de tudo em seu poder para que eu não me sentisse excluída.

O modo que eu achei para retribuir todo esse amor que me foi dado é ajudar outros, sempre que possível eu sempre acho um tempo para contribuir com projetos open source como o site das PyLadies Brasil, ou como o projeto Serenata de Amor, o qual o grupy-rp organizou um fim de semana para contribuir, também postando o que eu aprendi num blog. E as vezes até incentivando os outros do mesmo jeito que eu fui incentivada.

Para Pam que leu isto enquanto estava sendo escrito pela primeira vez e me incentivou a publicá-lo; Para Pedro que sempre manda mensagens amigáveis para lembrar de terminar os textos como solicitado; Para Leticia que me encorajou a preencher o pedido de auxílio financeiro da PyCon; Para Marco meu amigo e mentor; E para Mari que é sempre muito paciente ao me dar feedback sobre minha escrita.

Edit: Agora eu oficialmente desenvolvedora e analista de dados full-time no Projeto Serenata de Amor e também me formei \o/

What I wanted to say but 1024 characters wouldn’t let me

Mon, 23 Jan 2017 00:00:00 +0000

As I was filling out PyCon’s financial aid form, I came across the following question: Your Involvement. It wasn’t really a question it was more of a statement followed by a white text box and in smaller faded letters this description “Describe your involvement in any open source projects or Python communities, local or international.”

I thought “Okay, now I get it. I can do that!”. So I listed all the topics I wanted to cover in my answer and then it hit me.

I believe that’s called writer’s block. Yep. I was supposed to talk about me, and what I like to do I simply couldn’t. Go figure. So I took a deep breath. Walked around the room a little. Took another deep breath. Drank some water.

And then, like magic, the words came. Little did I know that the white box had a 1024 character limit and I ended up writing 2782 oops. Well, after putting my heart into this answer I decided, before cutting it down to 995 characters, that I would post the complete answer here. So brace yourselves.

I am part of a Python users group in Ribeirao Preto (a city in Sao Paulo estate) known as grupy-rp since the end of 2015, when the guys from grupy-rp went to my course’s academic week to give a day long workshop. It was a introduction to Python and deploy of a simple Django webapp to Heroku.

The majority of grupy-rp is composed by men, but still I kept going to the meet ups and became part of what I like to call my tech family. One of the guys there introduced me to the PyLadies, concept that I was totally unaware of, so I got in touch with other ladies in Brazil. And then, I met the second thing I love most about Python, a group of women that work together with a tool that I loved.

grupy-rp also organizes a local Python event known as Caipyra it was at this event that I got to know some amazing developers. Around the same time, the same friend that introduced to me to some PyLadies (which would work with me to create a new PyLadies chapter) had an opening in the startup that he worked for a Python Web Development Intern and said ‘You have to apply!’ after a lot of talking and doing and re-doing Django Girls Tutorial the idea of becoming a webdev grew on me and I applied.

Among other candidates I was accepted to work there. At that time I already felt at home, I used to go to the minor events, I talked about Python with the people I know, and I landed an internship with a guy that I consider one of my mentors. It was some intense seven months, a lot of self doubt and impostor syndrome to deal with, but at the end I know today that I’m capable of being a better coder every day.

And becoming a better coder also includes going to events and teaching what you know to others, so once the opportunity to become a Django Girls Coach came up I couldn’t let it pass by. I applied to become a coach to the girls during PyCon Brazil last year, and got a positive response a few months after the applications closed. I could not feel more loved.

Of course for all that to happen I had major encouragements from my mentors and friends in the Python community. This beautiful community that accepted me with open arms. And when time came, made everything in it’s power so that I would not feel excluded.

The way I find to give back all love that has been given to me is to help others so whenever possible I find time to contribute with open source projects such as PyLadies Brazil website or Projeto Serenata de Amor, which grupy-rp organized a sprint weekend to contribute, or posting something that I learned in a blog, or helping others study and sometimes just encouraging others as much as I was encouraged.

To Pam that read this while I was writing it for the first time and encouraged me to post it; To Pedro that keeps sending me the friendly reminders to finish the posts as requested; To Letícia that encouraged me to apply to PyCon finaid; To Marco my friend and mentor; And to Mari that is always very patient when giving me feedback about my writing. ❤

Edit: Right now I’m part of the Projeto Serenata de Amor as a full time developer and data analyst and I also graduated \o/

Uma semana de Serenata de Amor

Mon, 16 Jan 2017 02:00:00 +0000

Alguns de vocês sabem que eu comecei a fazer parte do projeto Serenata de Amor essa semana. Projeto que tem como objetivo ajudar a combater a corrupção usando técnicas de machine learning e data science.

Por causa desse projeto e dessa participação algumas pessoas vieram falar comigo. Em particular uma menina super dedicada e interessada no mundo da tecnologia que conheci na python Brasil 12. Essa minha amiga me fez a seguinte pergunta:

Je como você fez pra superar as dificuldades de começar a trabalhar como desenvolvedora?

E foi isso que me deu a ideia de escrever esse post pra contar um pouquinho sobre como que foi essa semana…

Pra continuar lendo esse artigo e saber mais como foi isso de participar de um time maravilhoso lá para a revista do Serenata de Amor 👇

It's Alive

Thu, 13 Oct 2016 00:00:00 +0000

Finally I managed to get this thing going! After a few days trying to get this beautiful Jekyll template to work, and a lot of time in between theese days, I finally got it to work! \o/

Disclaimer

So yeah, I’m a pythonista and I love Python, but I still decided to have a personal page that is ruby based. First because, GitHub deploys Jekyll pages without having to build the site somewhere before uploading it like Pelican would have me do. And secondly, because I fell in love with this template, it is simple, markdown based, and it gave me an opportunity to learn a little bit more about Jekyll and Ruby.

Also, I’m brazilian, so just let me warn you in advance, most of my posts will be in portuguese, especially the ones with technical information. The main reason for that is that I have noticed that a lot of information about programming and software development is passed in english and this creates a barrier for students that have little to no knowledge of english and want to learn more about these subjects.

Other than that not much to say here…

See you soon ;)

We need to talk about R

Wed, 18 Nov 2015 03:00:00 +0000

Minha primeira palestra falando sobre R para o GruPy RP.