Open Source ⚙️🤓

Learning journal — Week 12 takeaways

by Mayra Lucero García Ramírez


This is the fourth week of the open-source phase. Like the other weeks, I experimented with some struggles and, a lot of learning.

As I’ve been writing in sections I will continue with this organization. Thanks for reading.

Issues and pull requests ⚙️🤓🖥

Like I have been mentioning, one of my initial pull request was on hold and might be closed. This week the pull request and the issue were closed because the author of the issue did not respond. The collaborators thank me and invite me to pick another issue (I might do it).

This week I have been working on 3 pull requests:

The first, in Assertj-core, as I mentioned last week, was on hold to be partially approved so I could continue working. This week feedback was given and I finish the changes, it is under review.

The other two pull-requests are for the same project. Through the phase I have searched for different projects and JS/Java implementations so I can learn from them. These two related-issues are one from the Backend (Java-Spring Boot) and one for the Frontend (JS/React).

How I was trying to contribute ⚙️

For the Assertj-core issue, I overloaded and test methods for AbstractByteArrayAssert, and AbstractShortArrayAssert to this library of unit testing. The issue main goal is to allow to use boxed arrays with the primitives of Java: byte, short, int, long, float, double, char, String. This week, I worked on the byte and short array assert and my pull request is under review. The pull request of last week with Char has already been merged 😃.

For the openDesk the issues are a little different. As I mentioned I tried to search for issue that was a little out of what I always practiced.

1.- For the Site Added event to queue issue, I did a lot of research. The issue was not difficult, but I have not much experience with neither Spring Boot nor RabbitMQ (message broker). The main goal for this issue was to add messages to a fanout from one of the microservices that at some point other microservice (the desk) listen to it. There was a tutorial provided with more o less the information they wanted to be implemented.

This one took me time because I had to investigate how RabbitMQ worked. As a tutorial was provided, I decided to do the previous ones in order to understood what was I doing. I fail the first time, nothing worked. I took a break and try again, WORKED! 👍🏽🤓. I did three tutorials before starting to work and after I started to work I encounter other difficulties with annotations like @Profile and @Autowired. I will explain my findings on them in the new knowledge section. This one was also merged 💪🏼.

2.-For the second issue, it is front-end page, no functionality provided but a page that must work on desktop and mobile according to given specifications in figma. I have not finished this one yet. I did a draft pull-request, and it is partially merged because one of the collaborators review it before I finished it. I talked to him and I will open another one when it is completely ready.

Positive or negative results ✅

I think this week was mostly positive. I keep an eye on my not yet merge pull requests in case any change is needed. After I finish the second issue of OpenDesk I will look for other issues to work on this week.

New knowledge🗒

This section is a little long this week, I think I have learned a lot so, I will try to give you an overview.

  • From the collaborations
  • JS
  • Java

From the collaborations

Especially from the RabbitMQ issue, I learned about this broker and how it manages messages, also that has different ways to do it. With a single queue, or with several ones with a fanout. I also learned how to implement the queue a message but also listen to them. Even though this part was finally not required by the issue, as another one with Kubernetes will take this part, I also learn about this.


I have been continuing with the Pluralsight free courses of JS ( I am in 9 day streak).

I learn and re-learned how to do a REST Api in Javascript, this remember me a lot of things from the last phase, when we construct the Back-end on NodeJs and I got to understand a little better some things that we implemented.

I understood the difference between JS on the browsers and JS in Node

  • downloaded from the web vs loaded from local files
  • untrusted and restricted vs trusted and privileged
  • limited to the user — server compromised

I also took a look at the JS security best practices and see some considerations that, as developers, we should consider to avoid vulnerabilities.

Some safe coding patterns are

  • Avoid unsafe functions (like eval)
  • Validate input
  • Sanitize data
  • Grand minimum privileges

Also that some of the vulnerabilities come from the characteristics of JS like the dynamic types, dynamic code execution and the prototypal inheritance.

This kind of vulnerabilities can be prevented with strict comparisons and restrict access to the __proto__

  • Prototypal inheritance is how inheritance is managed in JS

Furthermore, I learned about modules, their advantages and the different kind of exports, named, default and the aggregation of the modules. I decided to take this subject for my phase blogpost 🤓💡.

Finally I learned about Cypress, a testing End-to-End framework. To be honest, before discovering this framework I was not sure what End-to-End means. Well, it means it tests the full flow of an application as an end-user.

I wrote some tests to know how it works, and I learned about the parent command (like visit) and the child commands (like click). I found it amusing 👀 as the test runs you can watch how fields are being filled and buttons are being clicked.


For the java part, I have been completing the Java developer track in JetBrains Academy. I have had the opportunity to return to the basics.

  • the memory (stack and heap)
  • reference types
  • conversions
  • primitives
  • exceptions and exception handling
  • constructors
  • objects
  • access modifiers

And so on and so forth, the initial section have 60 topics, I have been reading and doing the exercises.

Finally, about Spring Boot I discover this

  • @Profile this annotation essentially is used when active profiles are used in the application. if something (p.e. configuration) is marked with it, it will only exist if the profile is passed when the execution starts.
  • @Autowired, this one I have researched, in the questions at the beginning of the phase. I just did not know how the profile affect it.

Let me explain what happened. I was trying to autowired some bean that where in a configuration file

public class SomeConfig {

Usually beans marked with @Configuration, @Component, @Controller ,@Service ,@repository o @RestController, etc. are created first. So the autowired can find the classes when need it.

The thing I didn’t know and discover later is that if the profile is not passed and Beans are part of the configuration, they will not be created (obviously 😅), and if they were autowired in some part, they won’t be found, and the app crashes 😨🔦.

Final thoughts

This week was different, with a different process while collaboration, I enjoyed this week. I think I learned a lot this week and I look forward to continuing learning🤓. I am planning to also get back to the basics of JS this week.

Thanks for reading.😁.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


Hi everyone I am Lucero Garcia 🇲🇽. DEV 🖥🤓. I also translate articles to Articulos en español in