An internship project report. Of sorts.

Some days ago I wrote about how and why I had my internship project changed after just a few weeks. I also should also have written about what I had accomplished, so far, and how have I adjusted the plan for the next portion of the internship. (Which, by the way, has achieved its 8th week. Time. It flies.)

The internship’s timeline, so far

(and progress/deliveries)

December 8th – Internship starts

  • First two weeks: explore, probe, discover.
  • Also during this phase, I created basic Suricata-verify tests for Modbus protocol, but since such tests only really work when the protocol has json logging also implemented in Suricata, it turned out those tests weren’t very useful.
  • I learned about a python script in Suricata which helps with creating same basic code structure for when one wants to implement a new protocol in Suricata: setup-app-layer.py – this won’t help too much if you’re still new to the whole thing, but gives you some idea of what should exist, including functions to integrate Rust code with the underlying Suricata engine, which is running in C. I’ve submitted a Pull Request with that and some small added contributions for a Modbus protocol in Rust, but then we found out there were duplicated efforts on this.

December 24th – Project halt // In-between projects tasks

  • While I waited for a new project to be defined, I worked with adding unittests to some SMB records parsers. I had a pull request approved for the ones written for the NBSS records: PR #5692
    • (This meant studying both codebase and protocols to some extent, so I knew what I was doing)

December 30th – New project announced

  • Even though I had to write a timeline for my original project as part of my application for Outreachy, when I began my internship I started to feel that I was missing having pre-defined checkpoints and deliverables, to help me materialize the bigger task I had at hand. For this new project this was something I wanted to change, so I wrote a somewhat high level outline/timeline for it, which you can check here.
  • During my studies, I was afraid I would end up missing some of the many message types the PostgreSQL FE/BE protocol has, so I compiled all PostgreSQL protocol messages in a spreadsheet, to help me better visualize them. (I also wanted to draw a finite-state machine for it, but haven’t managed to, yet).
  • I’ve began writing the nom parsers for a basic startup message (which shares its structure with a few other message types, as well), and submitted a draft PR.

Outreachy community

  • In parallel with my internship efforts, I’ve been trying to help with spreading the word of Outreachy, so more people – specially Brazilians, since I’m from there – may get to know it and, hopefully, want to take part in it. I have helped in organizing a live about Outreachy and Google Summer of Code internships, and it was made possible by Canal Peixe Babel (a YouTube channel focused on making science more popular and accessible, hosted by two awesome Brazilian women: Camila Laranjeira and Vivi Mota). It aired on January 19th, and featured as speakers Anna e só, currently an Outreachy organizer, and herself a former intern; Clarissa Borges, alum from both Outreachy and Google summer of Code, and myself.

Challenges & Adapting

Rust and its nom parsers have been a special “obstacle” in this internship. When I chose this project, I had no previous experience with any of that. But the project listed prior Rust knowledge as desirable, so I believed I could do it.

Rust: laughs in still unparsed bytes

I quickly found out that I had underestimated the whole task, as Suricata in itself is also quite complex, and implementing a network protocol requires fairly specialized knowledge.

In order to keep advancing with the project and try to ensure I’d still be able to learn with this experience, I have proposed a new approach to it, in an attempt to break it down to an even more basic first version: I’ve proposed to have a proof of concept, first, using a depth-first approach. This means I’ll take the first phase of the PostgreSQL FE/BE protocol, the startup phase, and try to implement it in Suricata from end to end — the nom parsers, then integrating these with the tool, and making it recognize this bit. Once I succeed with this, I’ll move on to adding more message types and subprotocols.

Where do I stand?

Sounds good, right? But while it does help in making this slightly overwhelming task have some more achievable milestones, I’ve once again found myself feeling stuck, after the initial progress. There’s a “jump” between writing the nom parsers and actually making sense of how to use parsers to handle the packets and the network stream which I haven’t been quite able to cross, yet.

Even though now I am more familiar with the tools, the protocol and the codebase (and even that great python script), I still can’t quite wrap my head around the whole thing well enough to move forward. And when I feel I can, Rust gets in the way. :D:

But I want to get good at this. I want to be able to achieve something with this internship, and give something back to this community that has welcomed me so well. So, with that in mind, and always reminding what my fellow Outreachy Sumera has written about persevering, last week I took a few steps back and tried to focus on more basic studying – network protocols, Rust, Rust and network protocols…

I feel bad for observing my pace go once again so slow when there’s so little time left. However, if I spend time trying to figure out things by brute-force, although it may work out in the end, my understanding of what is going on may end up being too fragile, and I want to avoid that.

I also feel bad for having halted on the project journals. It seems that whenever I get stuck, I have a hard time writing about it. Likely because I don’t feel I have anything new to add. I have decided to try to have shorter journal entries, so I won’t feel I am spending too much time on that, because – surprise!, due to my lack of progress, I tend not to want to stop to write. I have failed on that this past week, and that’s why I have decided to start this one with this blog post.

Let’s see how it goes. I am still learning. Must not forget that…

Leave a comment
by Juliana on 25/01/2021  •  Permalink
Posted in Outreachy, Project Journals
Tagged , , , ,

Posted by Juliana on 25/01/2021

https://jufajardini.wordpress.com/2021/01/25/an-internship-project-report-of-sorts/

Restart! Changing projects “midway”

One thing that we must keep in mind is that project goals and timelines, as outlined before a project starts, usually require lots of adaptations, once they start. That may happen due to previously unknown requisites, needed effort badly estimated, an unforeseen need for the team to acquire new tools or knowledge… the list goes on.

This is a strong truth for software projects, due to their less concrete nature, and one of the reasons why Agile methodologies and approaches are so common (or at least desired) among developers and companies who want to be efficient: they offer a variety of tools for trying to understand and decide scope in more accurate manners, and they heavily focus on adapting course of action in response to inevitable (or desirable) changes.

…

It is somewhat easy to describe generic truths like the above. They are vague enough not to be about you personally, and make you sound knowledgeable. It is not so easy to accept the fact that this will happen to your project. And may be even harder to realize it midway, whilst you deal with the inner (and maybe outer) pressure to get things done and be productive. It still happens, nonetheless. And the newer we are to a project, team, technology… the higher the chances that we’ll see ourselves in such a situation.

Now, add Open Source to the equation. While the projects have tools to help them manage contributions to their codebase — new and planned features or bugs, and who is doing what, the nature of the setup is more susceptible to scenarios where two people from the community are working on the same issue, totally unaware of their mutual and/or concurrent efforts. Can you see the potential for this to bring radical changes to one’s schedules and plans?

…

I was halfway trough my third week of internship, working on the project to convert the Modbus Protocol, which Suricata already supports in C, to Rust. That was the plan. After much struggle, I had just submitted my first PR, and was working on my mentors’ feedback to it, when, next day, I am notified of updates on my task, in Suricata’s page.

The Suricata team uses Redmine to track its tasks, bugs, features. If one wants to contribute to the project, they’d go there, create an account (in case they didn’t have one), reach out to the team via the specific issue they’re interested in working on, and, once approved to, assign the task to themselves, so that everyone knows it is taken, and, well, things can be properly tracked, considering it’s a distributed project team, with external members from the community also helping.

But sometimes that workflow doesn’t go so smoothly. When I checked my task, I found out that there were other people working on it, as well. And they were at a more advanced stage. All of that was discovered because of my PR, it seems. This made them reach out and mention their work, which should have a deliver in less than a month. Realizing the implications of this, I went to my mentors. Turns out it’s not so uncommon for open source projects, and had even happened before with Outreachy internships. They would have to come up with another task altogether for me to work with.

In the meanwhile, they suggested some more punctual things I could work with: writing unit tests for some existing parsers in Rust. That would keep me busy, while still steering my learning and experience towards the overall direction of my next project, so that change wouldn’t affect my pace so drastically. With mixed feelings for having to let go of plans and studies, but also glad that not that much time had passed yet, I moved on, and was even able to have a PR accepted during this interlude. (yay!)

A week later, they announced their new plans for me: adding support for the PostgreSQL protocol to Suricata. This would be a new feature — from scratch –, and in Rust, so it shared some, and diverged some, from my initial project. Now I had a lot to adapt, as I wasn’t simply adjusting goals and expectations within the same set of tasks. In many aspects, it would be a total start over – with some 9 weeks left.

What happens when you have great mentors, backed up by an awesome initiative? They pay attention to these things. At least, that’s what I felt, when I checked my new overall task. It still offers plenty of room for my learning and development, while also taking into account: my current level (which they can now gauge better); what I have already learnt in these past weeks with them; what time we still have left.

And what happens next? Well, that was already shared here, when I began a journal for this new project.

3 Comments
by Juliana on 15/01/2021  •  Permalink
Posted in Outreachy
Tagged , , ,

Posted by Juliana on 15/01/2021

https://jufajardini.wordpress.com/2021/01/15/restart-changing-projects-midway/

Days 4 and 5 – Keep walking. And some struggling.

/* Yesterday I obviously didn’t manage to post. So today we’ll have a condensed entry. */

So, PR submitted. What then? So far, when I submit a PR for a project/task with still a lot of unknowns, it goes with lots of questions. This happened this last time as well: I wasn’t sure about some of the decisions I had made in the code, because I didn’t find them elegant, for instance; and I wasn’t sure if the way I had written the tests for the checks they had asked was good, or covered enough cases.

One thing about having three mentors, from different parts of the world, is that there is a big window to get answers. Since I had the PR and the questions, I got a lot of feedback. Some things were more straightforward, like “look into failed checks from GitHub and tidy up my code”. Others had things I didn’t know what they were, and then I had to look them up, and there we go learning something new. All in all, the questions opened the door to some exchange about protocol message format; best ways to deal with the parsing of information when you may not know its length; some other technical aspects which I felt I could mostly follow, and on occasion make some contribution, from my studies. And, of course, all that brings more unknowns.

A thing that can make me stale a little is when I get “offered” what feel to me like two different approaches. It may be because one feedback is more practical and taking into account how to progress the code I already have at hand, while the other is looking at a bigger picture. And then I spend some time trying to figure out where I should go from there on, or how should I tackle that apparent uncertainty. This happened this past couple of days, and I could notice it was affecting my focus and pace. I also spent more time than I thought I would at things that at first seemed simpler, and then – oh, well, I have to put some more thought on how to really test this input. And I have to re-read things a lot, to realize they’re two different things. Or the contrary: they’re two different ways of talking about the same stuff, only bringing another perspective. Understanding and realizing these goes with the learning process, I guess.

…

In the middle of feeling a bit lost with all that, yesterday we also had an Outreachy chat about Open Source events and conferences. It featured organizers, interns for this round, alumni for past rounds, and mentors. I took the opportunity to “change airs” a bit (and enjoy the sun from my window). There is such a variety of events one can attend when willing to learn, meet other people, or getting to know a community. From the ones mentioned there, I got particularly interested in the unconferences, for their style; and MozFest, for everything, basically. The chat also made me long for the SuriCon 2021, SuriCon is the yearly event for the Suricata community. Next one will happen this year in Boston, October, from 20 to 22. I really hope to be able to go, and get the chance to meet face to face with the people I’ll be talking to almost on a daily basis for this whole internship, and with whom I wish I’ll get to contribute for hopefully even longer than these three months…

…

…And back. I decided that I would tackle what looked like the most objective and specific aspects of the feedback, incorporate them into a new PR, and then spend more time on the other challenges and questions that emerged, with the suggestions made.

This PR should have a new unit test, for invalid inputs. I was given one example of possible invalid data, and a possible way of twisting data to make it wrong: by trying to take into account when fields are “off by one” – when a specific data has it’s size wrong by one byte – as my mentors say that is something that commonly generates TCP errors. I spent a good time yesterday thinking of other possibilities for invalid input; how to check those in the test; and what would my code generate, so the test could make sense.

Even though I believed I could do it, I didn’t manage to submit a new PR yesterday. So I decided to do that this morning, so that I could take that out of my mind, and move on to aaalll the rest that there is to be done.

Still, the day didn’t seem to progress and flow, and my mind wasn’t cooperating. So I went back to protocol study, as there are many aspects yet to understand about it. That way, I knew I would be doing something useful, even though I wasn’t feeling able to code or to design any code at the moment. I went to theory + practice, by reading more of the documentation (now all the different messages types this protocol has) and comparing it with actual data from PCAPs – files that show network traffic captures – showcasing our famous PostgreSQL. The image shows part of a Startup message – the very first message sent by the Frontend (client) to the Backend (server), when opening a new connection with a given database.

What checking a PCAP (using Wireshark) looks like: data streams, labels, some protocols.

I always enjoy doing this: trying to dig examples for what I am reading with real packets. And I now know and understand Postgre on the wire yet a bit more. /o/

By late afternoon, I got another PR review. More things to learn; opportunities for writting better code; and a mindset to keep: acknowledging that (and what) I don’t know, and keeping an open mind, are among the ingredients to make the best out of this journey. I hope to be able to find good ways to keep communicating, so things will keep moving forward.

Leave a comment
by Juliana on 06/01/2021  •  Permalink
Posted in Outreachy, Project Journals
Tagged , , , , , ,

Posted by Juliana on 06/01/2021

https://jufajardini.wordpress.com/2021/01/06/days-4-and-5-keep-walking-and-some-struggling/

Day 3 – First PR

/* A PR, in GitHub terminology, is a Pull Request, or, in other words, when you submit a piece of work – usually, code, or documentation – to the project maintainers, so they can review and approve, make suggestions, ask for fixings… */

So I had mentioned already that this time, instead of spending a lot of time before submitting some work to judgement, I would take a maybe more agile approach, and try to deliver earlier, fail faster, and learn and improve quicker.

Following that idea, I set as today’s goal to submit a basic initial code. As Jason had suggested – and somewhat close to what I had tried to plan -, I went for a data structure to represent one type of message the PostgreSQL has, called the Startup Message (the one sent when a client/frontend wants to start a new connection with the database server/backend). Along with it, I wrote a very basic parser (which at OISF they call nom parsers, because of the nom Rust library) to identify on the data stream (a sequence of bits, roughly) that said message packet, and a few key values (the length of that bit stream that I should be reading; the protocol version – since there are, as of now, three version -, and pre-parse the data containing the real information about the new connection, which, as mandatory fields, are user and database name (which client is trying to access). And, to properly finish this small set, a unit test for the parsing function.

Easier written than done. I came up with all sorts of bumps along the way – from not knowing why Rust wasn’t compiling nor running my test, to why I was getting type mismatches to how should I represent and call this data structure? Having set up my mind that I would deliver something was important, for that didn’t allow me to waste too much time wondering about my questions, and to decide to decide on something, and list whatever I wanted to ask, so I could do so alongside with my PR. The fact that one can submit a draft PR also helps, because that makes it clear that you know your code is not ready, and you want/need feedback. Perfect for where I stand.

As I was finishing writing down my questions, after coming up with a first acceptable, running code version, Tharushi, my internship colleague, showed up, and we had a call in which we tried to explain to each other what were our projects about. We felt that could be important not just so we could know what the other is actually doing – well, a bit better, at least -, but, moreover, it could help us in thinking what is important to understand about our projects and the tools “surrounding” them, so we can introduce and explain what we are working with to a broader audience who doesn’t know what Suricata, Suricata-verify, and all that is about.

I finished my working day submitting the aforementioned draft PR and sending a few questions and thoughts to my mentors, so they can know where I stand.

Tomorrow we have an Outreachy chat, with mentors, interns, alumni… Those are inspiring and exciting opportunities to learn, share, and get to know more of projects and all those awesome people who are part of this round and this beautiful initiative.

And I will also try and write that post in which I explain what my project – and Suricata – is, in more depth. But if you are too eager and curious, Vagisha Gupita, a previous intern at OISF, wrote an excellent introduction here.

/* I am happy to be here… 🙂 */

Leave a comment
by Juliana on 04/01/2021  •  Permalink
Posted in Outreachy, Project Journals
Tagged , , ,

Posted by Juliana on 04/01/2021

https://jufajardini.wordpress.com/2021/01/04/day-3-first-pr/

Day 2 – Organizing things: project overview

As I’ve mentioned in yesterday’s post, I finished work with a feeling that I needed to write down some sort of plan or guiding path, to get a clear idea of what would my next steps be, and to make sure I would have some milestones and early deliveries set. I know from recent past experiences how I can feel even more overwhelmed when feeling lost, so want to prevent that as much as possible. I also want to help myself in the task of keeping a good pace, since changing projects leaves me with less time for this new one.

Ok, on the one hand, implementing basic support for the PostgreSQL frontend/backend protocol by means of a basic parser feels fairly less complex than the task of Converting the Modbus protocol from C to Rust, in Suricata, but on the other hand, this is still a returnship, and I have to learn a lot of things basically from scratch, so two months, give it or take, don’t feel like a lot.

So I took today for finishing the initial approach to understanding how this protocol works, and then reserved some time to think of how could I break down the major task into easier to approach and visualize steps and milestones. I wanted to do this, to introduce some deliveries along the way – well, the first ones, at least, as the whole journey isn’t that clear yet to me -, and, with that, ensure earlier code/PRs/feedback.

I used part of the protocol structure; along with what I’ve learned from writing unit tests to some record parsers in Suricata; and the overview suggested for my previous project (the modbus one) as background knowledge, and came up with 12 steps, not overly detailed, although listing at least one or two deliveries wherever I felt I knew what should happen there. This also made me revisit the issue that represents my project in Suricata’s backlog on redmine — which is a good thing when we’re getting acquainted with a new project or task, as we tend to understand different aspects of it as we do so.

When I was finished, I shared that plan with my mentors, explaining my motivations and what I was planning to do different from last time. This opened space for Jason, who probably was around because it’s still early in the day for him, to share how he starts new protocol tasks, sometimes, and why/when using some tools that Suricata and Rust/Cargo have will be useful, and he how he does it. I complemented my notes with that, and felt somewhat happy to realize that what I had in mind, or some of the things I did, resonate with what he was telling me.

I compared what I had achieved today with yesterday’s quick plan for today. Not bad. I mean, I want to be MORE productive and DO MORE and PROGRESS FASTER. I know. But I had set some expectations for what I felt was important for me to achieve today, and I managed to do that, I made sure to communicate with my mentors to so they where I stand. And I’ve learned some new things. It is fair to understand that this wasn’t a bad day. One must to understand to accept and acknowledge their progresses. And notice when it’s happening. This is not only healthier, but will help with motivation and with telling anxiety and impostor syndrome to STAY AWAY. (Because, yes, this morning I did have to fight those, and it takes a lot of breathing to keep moving while they’re saying bad things.)

It was late afternoon where I am, and it’s New Year’s Eve and/or holidays season, so Shivani and Victor, who are further in time compared to myself and Jason, were already celebrating and spending quality time with their special ones. Yay for that, we all deserve it… I headed to write this not-so-short journey/journal entry. And now I’ll call it a day. Let’s keep moving…

1 Comment
by Juliana on 31/12/2020  •  Permalink
Posted in Outreachy, Project Journals

Posted by Juliana on 31/12/2020

https://jufajardini.wordpress.com/2020/12/31/day-2-organizing-things-project-overview/

Day 1 – Getting to know the protocol

So today Victor Julien, another of my great mentors, told me that for my new project (I’ll explain on a following/future post what happened to the original plan) I would be working with adding support to PostgreSQL protocol in Suricata. It is currently not supported, so, differently from the task for the Modbus protocol, where I was going to somewhat convert what already exists in C to Rust, in this case it is Rust from scratch.

After submitting a short PR for a previous task I’d been working with, while I waited for them to decide on what my project would be, I dived into protocol studying.

PostgreSQL’s Frontend/Backend protocol, as they call it, is really well documented, with lots of information, and also written in an accessible way. I have gotten an initial understanding of types of messages and message flow, which were nicely complemented by a presentation of the protocol (that was presented at one of the community’s conferences) and some pcaps also provided by mentors (Jason Ish, my third mentor, offered a quite didactic one ❤ ).

I did my best to keep investigating, and at the end of the day I feel somewhat comfortable about this new protocol – which undoubtedly is also helped by the fact that I have spent the past three weeks already working with Suricata, communication protocols, and Rust.

As I don’t want to feel overwhelmed by this project, nor do I wanted to spend too long before sharing with my mentors what I’ll come up with, have decided that tomorrow I will take a step back from studying (now that I know somewhat that I have in my hands), and plan some milestones and PRs, as well as what is the very basic I need to get started with the code for this first task, which is to write a basic parser for the protocol.

And that summarizes this day, which is the second of my fourth week, but, at the same time, feels a bit like the very beginning – although with a lot more confidence, and way less overwhelming anxiety. Let’s keep going!

2 Comments
by Juliana on 30/12/2020  •  Permalink
Posted in Outreachy, Project Journals
Tagged , , ,

Posted by Juliana on 30/12/2020

https://jufajardini.wordpress.com/2020/12/30/day-1-getting-to-know-the-protocol/

Oh, the struggles… – part 1

Outreachy organizers timely ask us to write a blog post about something we have been struggling with, on our third week of internship. This shows that they definitely know the deal, because… Talk about being stuck.

I have felt lost, stuck and struggling so many times in these two weeks that I could just as well say that this is the overall feeling for this second week. During the first days, everything was new, and I had enough organizing, planning and documentation/codebase reading to do as to not feel overwhelmed by the fear of being stuck or lost.

As we advanced through the second week, though, and I kept feeling that I had no idea how to get started with “getting some real job done”, deep, old and strong fears intensified. Am I any good at this? Did they choose the right person? Oh my globs what am I even doing here. They will certainly know that I don’t know anything. I don’t even know how to organize my thoughts so as to ask something and get out of this mess.

Stuck? Where? Who? I’m just chilling.

Thankfully, as I’ve mentioned, Outreachy organizers know the drill. They’ve been doing this for years, so for this third/second week, they propose some tasks to mentors and interns which revolve around: sharing experiences of being stuck with something, for mentors; and, from our part, reaching out to mentors to ask them to talk more about such experiences, and to ask for help if we’re stuck for too long (and too long means: if you’re stuck for more than two hours. Got the message? You, who have been feeling like a fraud, and suppressing the urge to hide, instead of talking to them and explaining what you’ve done, and how, and what didn’t work, or, even… To simply tell them you don’t know where to look at, to start with. — You, me).

With that in mind, and reminding myself countless times that this is meant to be a learning exercise — that’s what internships are for, as well, after all –, I asked my wonderful mentor Shivani Bhardwaj if she could do some screen sharing with me and the other intern at OISF (hiya Tharushi Jayasekara!), so we could do some shadowing or whatever she thought would be useful.

Despite all the voices in my head that kept telling me that my mentors are too busy and have lots of other things to do, Shivani welcomed the idea right away and proposed for us to meet the next day, if that worked for us. We found a mid-ground that worked for the three of us (since there’s a 5:30 hours time difference from Portugal to Índia and Sri Lanka, right now), and I felt happy and relived for being able to ask for help.

Shivani asked if there were any specific topics we’d like to see, and the next morning we had a moment to learn a bit more about Suricata and OISF, and a few tips and hints that could help us along while working with Suricata codebase but also to get to know with whom we were sort of working with – which felt great, I always like to know there are real people behind the screen…

This story doesn’t end here, because I know there will be way more moments like these[1]. But also because this was just the first step. Sometimes we’re so not used to accept that we may not know something, and so used to environments that will judge us for “not being there” already, that we struggle with the very fact that we are struggling, and the major obstacle ceases to be whatever error or lack of knowledge we might be facing, and becomes our internal judge. That feels still like the biggest lesson I have yet to learn. But I’ll keep trying.

A few things that I’m trying to keep in mind:

  • In this internship (as in life), I won’t know everything from the start. And I will meet people more experienced than me. It’s not healthy and it doesn’t make any sense to compare my current state with theirs[2], especially if I’ll do that in a judgemental way. I’m here to learn. That means, tah-dah, that I won’t know everything. I need an open mind, and courage, to keep trying, to look from different angles, and to know when to shout out for help, and how. That open mind will also help me to learn with the more experienced than myself, instead of worrying that I’m not like them.
  • Our mentors have decided to take part in the Outreachy program. That means that they have accepted to welcome to their team people who may need help and support, because… they are there to contribute to a project, true, but also to learn. This is out mentors’ journey as well, so, ok, they are busy people. However, they have accepted that, at least for three months, we are part of their tasks, as to say. So, we should not worry too much and build complicated walls. We talk, we show that we are trying. We do our part. And take the great opportunity to learn from and with them. 🙂
  • Baby steps.

And like that, we keep on moving. See you on part 2! 😛

[1] As very well put by Joey Salazar, another intern for this round.

[2] Two other interns for this round, Wala Awad and Sumera Priyadarsini, have shared good thoughts on that, somehow, too.

4 Comments
by Juliana on 18/12/2020  •  Permalink
Posted in Outreachy
Tagged , , , ,

Posted by Juliana on 18/12/2020

https://jufajardini.wordpress.com/2020/12/18/oh-the-struggles-part-1/

Olá, eu sou uma estagiária do Outreachy :D

(Esta é uma versão em português do post introdutório sobre o Outreachy, que publiquei aqui no dia 01/12)

Siiiiiimmm. É isso mesmo. Junto com outras 53 pessoas de vários países, eu fui aceita para uma vaga de estágio na rodada de Dezembro-Março do programa Outreachy, para trabalhar na Open Information Security Foundation, com um projeto para Converter protocolos do Suricata de C para Rust.

Se você já me conhece, é provável que não saiba nada destas palavras aí de cima. E se você acaba de chegar neste blog, é possível que saiba algo sobre elas, mas nada sobre mim. Esta é a razão deste post. Uma apresentação sobre mim e um pouco sobre a iniciatíva incrível que é o Outreachy, e o projeto com o qual vou estar trabalhando nos próximos três meses (spoiler: vou acabar deixando estas partes para outros posts).

Começando do começo: meu nome é Juliana. Sou brasileira, e atualmente vivo em Portugal. Aqui, trabalhei principalmente em call centers (ou contact centers), a despeito de minhas experiências anteriores no Brasil com desenvolvimento de software, startups (desenvolvimento de clientes) e revisão e tradução. Vivendo… a vida padrão de imigrante.

No Brasil, vivi a maior parte de minha vida em Salvador/BA. Lá, me graduei Bacharela em Sistemas de Informação em 2014, e mesmo antes de me formar, eu já tentava usar minhas habilidades e o trabalho como formas de, de algum modo, dar algo em troca pelas oportunidades que tive, e ajudar a transformar o mundo em um lugar melhor, de um modo geral. Com isto em mente, eu trabalhei com inovação e startups; na Secretaria de Ciência, Tecnologia e Inovação do Estado da Bahia (em um projeto bastante ambicioso para facilitar o acesso a computadores e à internet a comunidades pobres ao redor daquele estado enorme); com um grupo de 4 mulheres mara, para tentar contribuir para inspirar jovens mulheres a perceberem que também podem ter um papel ativo na tecnologia, não apenas como consumidoras, mas também como criadoras, makers, desenvolvedoras (essa iniciativa linda se chama OxenTI Menina, e eu cresci e cresço muito com elas)…

Entre as várias coisas ou características que considero importantes, penso que três valores centrais para mim são Comunidade, Contribuir e Compartilhar (e, aparentemente, aliterar 😛 ).

Comunidade é chave, pois acredito que não estamos sozinhos neste mundo, como dito no Rei Leão – ou com a Filosofia Ubuntu: estamos todos conectados, eu sou porque você é. Eu cresço, quando faço parte de uma comunidade fortalecida e acolhedora. Eu valorizo e respeito isso, e desejo contribuir com as comunidades das quais faço parte – seja a comunidade no trabalho; minha família estendida; o mundo no qual vivemos, com toda a diversidade que nele há – eu quero ajudar para que o ambiente no qual me insiro seja melhor para todas as pessoas, e eu tento contribuir ativamente para isso, com ações grandes ou pequenas. E, para mim, compartilhar está diretamente ligado a tudo isso. Quando compartilhamos – conhecimento, histórias, boas risadas, comida, um abraço, as oportunidades que temos – fortalecemos nossas comunidades. E nos tornamos mais fortes. Todas e todos têm mais chances de ter experiências melhores e/ou mais legais.

Para mim, o Outreachy pareceu uma oportunidade excelente de, de algum modo, exercitar tais valores, ao mesmo tempo em que tento me aproximar de outros temas que são centrais para mim: inclusão e diversidade. De um ponto de vista mais pessoa, esta oportunidade também significa ter a chance de estudar e voltar a atualizar minhas habilidades de desenvolvedora, para melhorar minhas chances de encontrar um trabalho bom e com sentido para mim, ao mesmo tempo em que faço coisas interessantes e, com sorte, encontro e convivo com pessoas também interessantes e agradáveis. E como eu acredito em compartilhar, também entendo a importância do software livre, e… bueno, se podemos ter a oportunidade de estar em uma iniciativa que busca fortalecer e dar espaço a tantos valores importantes, devemos tentar, certo?

A verdade é que… eu não sou muito boa acreditando em mim e no meu potencial, e já fazia um certo tempo desde que eu tinha trabalhado pra valer com programação. Por isso, preciso dizer quão grata me sinto por ter tido algumas pessoas que foram minhas mentoras nos bastidores, e me ajudaram tanto a não desistir mesmo antes de tentar, e a acreditar que, sim, eu podia fazer parte da comunidade da Outreachy, quanto com questões mais técnicas do processo Seletivo: José Grimaldo; uma das fundadoras do myolab; e algumas outras figuras foram essenciais para evitar que eu deixasse de acreditar que poderia fazer isso. Como eu mencionei antes – não estamos sozinhos. Estas são algumas das conexões de minha “comunidade pessoal” que me ajudam a avançar.

Que este estágio no Outreachy possa contribuir com minha autoconfiança, para que eu possa ajudar outras pessoas a chegar mais longe. Yay!

Leave a comment
by Juliana on 06/12/2020  •  Permalink
Posted in Outreachy
Tagged ,

Posted by Juliana on 06/12/2020

https://jufajardini.wordpress.com/2020/12/06/ola-eu-sou-uma-estagiaria-do-outreachy-d/

Hi, I’m an Outreachy Intern :D

Yessss. You’ve read that right. Together with other 53 people from several countries, I was accepted for an internship for the Outreachy December-March round, to work with the Open Information Security Foundation, on their Suricata project “Convert protocol from C to Rust”.

If you know me, chances are that you are not familiar with most of those words. If you just arrived here, you may know those, but probably have no idea of who I am. That’s why I’m writing this post – to introduce myself and also to talk a bit about Outreachy awesome initiative, and the project I’ll be working on for the next three months (spoiler alert: more details about Outreachy, their application process, and my internship project will be left to separate posts).

First things first: my name is Juliana. I am a Brazilian, currently living in Portugal. Here, I have mostly worked at contact centres, regardless of my previous experiences with software development, startups (customer development) and translation/proof reading. Just… living the immigrant life.

In Brazil, I lived most of my life in Salvador/BA. There, I graduated as an Information Systems Bachelor in 2014, and even before that I was already trying to use my skills and work as a means to somehow give some retribution for the opportunities I have had, and help to shape the world to a better place, in broader terms. With that in mind, I have worked with entrepreneurship and startups; at the Bahia’s State Secretariat for Science, Technology and Innovation (in quite ambitious project to bring access to computers and internet to impoverished communities throughout most of that enormous state); with a group of four (including myself) great women who try to contribute to inspire young women into understanding they can also have an active role in technology, not just as consumers, but also as creators, makers, developers (this dear initiative is called OxenTI Menina and I grow and learn a lot with them).

Among the many things or treats important to me, I think that three core values are Community, Contribution, and Sharing.

Community is key, for I believe we are not alone in this world, as seen in the Lion King – or with the Ubuntu philosophy: we are all connected, I am because you are. I grow, when I am part of a welcoming, strong community. I value and respect that, and want to contribute to the communities I’m a part of, be that within my work community, my extended family, the world we live in, with all the diversity that there is within – I want to help the environment where I am to be better to everyone, and I try to actively contribute to that, be it with small or bigger actions. And to me, sharing is directly connected to that. When we share – knowledge, stories, a good laugh, food, a hug, the opportunities we have – we strengthen our communities. And we become stronger. Everyone gets the chance of having a better experience or cooler opportunities.

To me, Outreachy seemed like an awesome opportunity to exercise somehow those values, while getting closer to other topics that are key to me: inclusion and diversity. From a more personal perspective, it also meant having the chance to study and get back on track with my developer skills, in order to improve my chances of finding a good, meaningful job, while doing cool stuff, with hopefully cool and interesting people. As I believe in sharing, I also understand the importance of free software, and… if you get the chance to be in an initiative supporting so many important values, well, you have to try, right?

Well… I am not very good at believing in myself and my potential, and it had been a while since I had really worked with software. Therefore, I really want to say how grateful I am to have had some “background” mentors/advisors who helped either in not giving up before trying and understanding that, yes, I could be a part of Outreachy community, or with more technical aspects of the Application process: José Grimaldo; one of myiolab.com founders and some others were a strong point to prevent me from stopping believing that I could do that. As I said – we are not alone. They are my “personal community” that help me go further.

May this Outreachy improve my confidence, so I can help other people reach more. Yay!

1 Comment
by Juliana on 01/12/2020  •  Permalink
Posted in Outreachy
Tagged

Posted by Juliana on 01/12/2020

https://jufajardini.wordpress.com/2020/12/01/hi-im-an-outreachy-intern-d/

UX Writing: entendendo mais o que é microcopy

Como alguém que sabe o quão comum é esquecermos ou ignorarmos expressões excelentes que temos em nossa língua nativa e só adotarmos o termo em outra língua (geralmente “”dominante””), e sabendo do impacto que barreiras linguísticas podem causar, tanto no sentido da exclusão quanto invisibilização, quero encontrar formas mais brasileiras de apresentar este conteúdo, como a excelente adaptação de elevator pitch para discurso de baleiro, que a Monique Evelle faz, ao invés de simplesmente traduzir para discurso de elevador, ou o toró de ideias, para brainstorming, que vejo algumas pessoas além dela própria usando, e que não só traduzem palavras, mas aproximam a mensagem da gente…

Ainda estou tentando pensar em uma forma de traduzir microcopy, embora o termo seja largamente utilizado tanto em materiais do Brasil quanto de Portugal.

Enquanto não encontro, sigo nas leituras e aprendizados sobre ux writing. Traduzindo e compartilhando alguns trechos do minicurso sobre microcopy e ux writing (do UX Writing Hub):

“Microcopy é o texto que usamos para planejar interfaces de usuário e criar produtos cativantes. Isso inclui o texto usado em formulários, mensagens de erro e assim por diante.”

“Pense nisso como o texto na interface de usuário cujo propósito é guiá-lo durante o uso do produto e ajudá-lo a interagir com ele. Uma grande porcentagem do microcopy que você criar estará diretamente ligada a ações que os usuários deveriam executar, tais como:

  • recepção e integração de um novo usuário e orientações gerais sobre o produto;
  • levar usuários a adquirir ou subscrever novos produtos da marca;
  • encorajar usuários a realizar uma ação [por exemplo, cadastrar-se, ou comprar algo];
  • guiar os usuários através da execução de uma determinada ação ou tarefa;
  • oferecer respostas e informações adequadas para informar os resultados de uma ação realizada [pode ser um texto que diga “obrigada! enviamos um e-mail de confirmação do seu cadastro” ou algo como – “ainda estamos processando a informação, isso pode levar alguns minutos”, ou qualquer outra coisa relevante para o contexto].”

No goodmicrocopy, postagens curtas com exemplos de produtos reais explicam porque se trata de uma boa prática, e qual a característica mais marcante, em apenas poucas frases, tipo:

  • Good microcopy sets expectations – um bom microcopy media expectativas
  • Good microcopy speaks the user’s language – bom microcopy fala a linguagem dos usuários
  • Good microcopy is timely and relevant – bom microcopy aparece na hora certa, e tem conteúdo relevante
Um dos exemplos do goodmicrocopy: Good microcopy is casual yet clear – bom microcopy é informal, mas informativo. Fonte: https://goodmicrocopy.com/post/179232491414/when-youre-signing-up-for-a-new-service-like

Microcopy – tiny words with huge impact, pequenas palavras com um impacto enorme, também traz alguns exemplos, explicando sua relevância e resumindo pontos-chave, como por exemplo (com algumas adaptações minhas):

  • microcopy deve atacar as principais preocupações dos usuários (e.g., medo de spam, custos associados, uso de dados pessoais)
  • ao exibir mensagens de erro, ou qualquer mensagem, buscar falar com o usuário como uma pessoa faria, em um tom conversacional, e usando termos simples (mas informativos) para questões mais técnicas

Além disso, sugerem este post com 15 exemplos maravilhosos de microcopy – 15 marvellous microcopy examples (and how they improve UX), de Nikki Guilliland, que traz 15 ótimos exemplos reais de microcopy, para ajudar a materializar a coisa em nossa cabeça e nos ajudar a entender outro ponto importante citado em quase todos os materiais: microcopy é uma ótima forma de as marcas demonstrarem e consolidarem sua identidade e personalidade junto a seus usuários.

Leave a comment
by Juliana on 17/08/2020  •  Permalink
Posted in Usabilidade, UX Writing
Tagged , , ,

Posted by Juliana on 17/08/2020

https://jufajardini.wordpress.com/2020/08/17/ux-writing-entendendo-mais-o-que-e-microcopy/

« Older Posts