All posts by Santex

Under The Sea

Our team member, Gabriela Chaves, tells us about her experience with scuba diving. She told us how it feels to be underwater and immersed in a dive with other species.

How did you become a scuba diver and how did this passion evolve for you?

I’ve loved water since my earliest memories, so the first time I traveled to the Caribbean, I had to try scuba diving which was “love at first dive”. In that same moment, I decided I was going to continue doing it and become certified in order to be able to expand the range of my experiences underwater.

What does scuba diving mean to you?

It’s the closest thing to discovering another world. It is as amazing as it is challenging. It’s a moment to be profoundly connected with myself and be fully aware of the moment. Being in a harsh environment makes it more exciting since I have to be able to overcome the difficulties that it implies.

What has been your most beautiful experience underwater?

One of my dearest experiences was diving at night in Puerto Vallarta. When one is diving in the dark you can only see what your flashlight is illuminating. It means that every time you sweep the area with your light, there can be a surprise. I found a sea turtle diving right next to me. They are so peaceful and watching them dive seems almost as if they are flying. It was an amazing experience to share that moment with the turtle.

With what marine species have you shared your diving experiences and which one has impacted you the most?

I have swam with a large variety of fish…octopuses, squids, sharks, sea lions, but the most impactful creatures so far have been the hammerhead sharks and especially manta rays. Such an odd twist of nature in their design!

Have you had any reckless experience or what risks have you encountered underwater?

Proper training is key in this activity to minimize the risks. I’ve had good training, excellent dive masters, and thankfully I’ve never had a bad situation. For example, while one is around sharks, you need to lay low, sit still, and wait for them to come to you.  Sharks are curious creatures and learning to read their behavior is really important to avoid any dangerous situation.

In your opinion, what would you consider to be the best destination for diving?

It depends on the type of experience you want to have. For example, the Caribbean and Galapagos are amazing places. I love “wreck diving” too, so any place with a sunken ship, plane or building will do as well.

What do you consider to be the benefits that one acquires when diving that could encourage other people to take an interest in this activity?

I’ve experienced two sides of it. On the one hand, it is almost a meditative moment. Being silent and fully connected to the present brings me much peace. On the other hand, I learned to push my limits, to conquer my fears. But of course, the main benefit is to dive in amazing places, meet all types of fantastic creatures you wouldn’t otherwise encounter and to experience nature in its wild state.

Cooking for fun

Our Santex Team Member, Juan Giacosa, tells us about his passion for cooking and preparing meals for his family and friends.

How old were you when you started cooking?

I don’t remember exactly. I know that I started to become more interested in cooking when  I was 17 and had to move to Cordoba.  At my family’s house, my mom was the cook, so I would only prepare food  if she was not around.

What motivated you to start cooking?

The need to feed myself haha. As I said, I was all by myself in Cordoba and  had to take on new responsibilities. As I enjoy eating a good meal, I decided to start doing some research about food preparation and recipes and gave it a try. That Was When I found out that It was not that complicated and decided to start cooking recipes that involved better and more complex techniques.

Have you studied or taken cooking courses?

No, I’ve never studied anything related to cooking in a “professional” way. Everything I know  Is due to practice and reading on web pages and cookbooks.

Do you have a dish that you like to prepare?

More than a dish, I really like to prepare and bake doughs…namely bread, pizza, pasta, croissants, etc. I also love roasting and grilling meat, and recently I’ve grown interest in using vegetables on my dishes.

What do you like most about cooking?

What I enjoy most about cooking is that it allows me to prepare delicious food for the people I love and see them enjoy it. There’s no greater satisfaction for me than knowing they like what I’ve prepared. For me, food is a way of showing appreciation and gratitude. It’s a way of saying “thank you” or “I love you”.

Do you cook only as a hobby or do you plan to carry out a project around the cuisine?

For the time being I only cook for friends, family or acquaintances.I plan on taking my chances in the field at some point in life. It could be managing a food store or opening my house to host culinary events for locals, strangers, friends and whoever finds out about it haha.

 

 

 

 

 

 

 

 

 

 

 

 

Git Basics: Pull Requests

By Agustin Aliaga – Developer at Santex

Git is a powerful version-control system designed to make software development collaboration easy. It can be used for personal (single contributor) repositories, but it really stands out in projects where multiple developers modify the same codebase every day. Multiple branching models can be adopted. However, in most cases, a Pull Request (PR) will be created when a bug fix or a new feature is ready to be merged into the main branch. The PR itself is an attempt to merge specific changes from one branch to another. Let’s explore the Pull Request workflow in detail.

PR Creation

Whenever a PR is created, the following good practices should be considered:

  • Adding a helpful description to the PR that answers the following questions: What is the requirement or bug? Is there a link to the issue (e.g. on JIRA)? How does your code fix it? Is there anything else the reviewer should take into consideration?
  • Making small, consistent and logical PRs: We want our PR to be merged as soon as possible. Imagine how hard it would be to review hundreds of file changes at the same time. If this happens, it is likely that the reviewer won’t even have the time to do it properly. So try to keep it simple and concise.
  • Making sure the PR’s metadata has been set. For example, by assigning the reviewer (to trigger a notification), setting the assignees, adding a label (if needed), etc.
  • Configuring the repo’s branching security settings to keep developers away from self-merging their PRs or pushing to a shared base branch. I recommend enforcing Github’s branching security settings. When a large team of devs is collaborating in the same repo, accidents may happen. A single miss click in a “merge” button can cause terrible headaches. Protecting important branches is something I’d advise most of the times.
  • Avoiding submissions that include unresolved conflicts. Fixing those conflicts shouldn’t be a reviewer’s responsibility. PR creators should dedicate time to solve them either by using Github’s conflict resolution tool (when it’s simple enough) or by using your favorite diff tool locally. You can achieve this by pulling the base branch and merging it into your feature branch. After you pushed it to the remote repo, the PR will automatically update.

Automated tests

If a Continuous Integration system (such as Jenkins, Travis, or CircleCI) is set up, a bunch of hooks can be configured to run unit tests on PR creation. This will allow the team to detect and catch bugs rapidly, as well as prevent conflictive code from being merged. This is a long topic that requires its own blog post, so I’ll just move on to the following stages.

Code Review

After everything related to the creation of the PR is dealt with and the CI tests passed, it is time for a code review. Projects tend to have tight deadlines, which sometimes makes code reviews seem like a waste of time by other team members or external agents. Ironically, code revisions actually help to increase productivity and reduce rework because we avoid bad practices in our code and share knowledge between contributors.

Some benefits of implementing code reviews are:

  • Less experienced devs get to learn from their mistakes.
  • Experienced developers consolidate their knowledge as they teach others.
  • A high-quality codebase is ensured.

Humility: a soft skill that matters

Sometimes, as work starts to accumulate and things get tense, some engineers tend to become less aware of their attitude towards their peers. It is always important to avoid egocentric behavior, listen to our co-workers, and moderate our communication when reviewing other people’s work. If we write a PR review in a disrespectful/arrogant manner, we could be damaging the team’s confidence and the work environment.

The “reviewer” role

Ideally, teams should implement peer reviews. This means that anyone should have the required experience and skills to review other’s code. In practice, collaborators regularly have different levels of experience on both the technology used for the project and the codebase itself, including its set-up, architecture, code styling, deployment, etc. In this case, experienced developers should be conducting the reviews and newer team members should be included progressively as they get comfortable with the project.

Merging the PR

After the PR was approved, it’s time to merge it. We have a couple of options to do so. Let’s explore them:

  • Create a Merge Commit (default): This option will merge all the commits from the feature branch plus a new merge commit. This is the safest way to perform the merge, since it is a “non-destructive” operation. The downside of using this option is that since it creates a merge commit to tying together the history of both branches, it pollutes your history tree with multiple “irrelevant commits”.
  • Squash and Merge: This option will “squash” all the commits into a single one. If the PR includes a lot of commits, this could be the way to go. It will make your history tree much cleaner and easier to read in your base branch. Nevertheless, you will lose granularity due to the bigger size of the resulting commit.
  • Rebase and Merge: The “rebase” operation is another way to combine commits from two different branches. This will put your feature branch commits on top of your base branch’s latest commit, and effectively rewrite the commit history. After this, it will perform a fast-forward merge, making it look like all the work was done on the base branch. This is extremely dangerous when the rewritten branch is public and shared with other team members. Generally, the rule of thumb is to keep rebasing operations for private-only branches.

References

 

THE BICYCLE DIARIES

We were talking to Leonel Romero about his magnificent experiences traveling by bicycle. He told us how his desire to cycle began and the places he has visited.

 

  • How did your interest in traveling begin?

I think I always had it. To visit new and unexplored places and meet new people have always been my favorite things.

Over time (and traveling), I began to understand that traveling is not just about getting away from your routine for a vacation. I know that vacations are the most common trip because most people do not have time or money, or don’t feel comfortable due to safety. Traveling is more a learning experience and an exchange of cultures,  that generates a deeper knowledge of oneself.

  • At what age did you start traveling and what inspired or pushed you to do it?

My first trips were on family vacations, always in Cordoba and sometimes to the Argentine coast or Mendoza to visit family.

As a cyclist or bicycle traveler, I started in 2015. I was 25 years old when I was in Europe for a trip organized by AVEIT, a student organization of the UTN of Córdoba that aims to do a study/tourism trip at the end of the engineering degree. I went to Croatia with a friend and went into a very large sports equipment shop and we bought everything necessary to start what would be my first “adventure”. That time we went from Croatia to Turkey by bike, passing through Montenegro, Bosnia, Albania, Greece, and Bulgaria.

  • Have you ever been in a dangerous situation during a trip?

In regards to security, I think the perception of danger depends on the person. You could be robbed in Cordoba or you could be in a “dangerous” place and nothing happens.

I was robbed twice in Colombia. The first time was an assault on the street in a very touristy place because of being careless. The second time a truck gave us a lift because we were in a very hot region and we did not want to keep going.  We put our bikes on top of the truck. After a while I saw a trainer up there: a guy of about 20 had climbed on top and was sitting there quietly. We continued traveling but were aware of our the unknown travel companion. After 5 minutes I saw him opening a bag so I told the driver and we stopped. The driver got out with a baseball bat and started screaming at the boy. The boy had nothing with him, not even a backpack, or our belongings, so we thought he hadn’t stolen anything and we let him go. He crossed the road in the middle of the field and a motorbike appeared that picked him up and they left.

The we realized, that he had thrown things onto the road and then collected them after. Luckily, we didn’t lose anything important.

  • Which places have you visited and which one did you like most

By bike, I have visited Croatia, Montenegro, Albania, Greece, Bulgaria, Turkey, Bolivia, Peru, Ecuador, and Colombia.

I can’t decide which one I like the most, everywhere has it’s benefits.

  • What advice would you give to someone who want to start traveling by bike?

Don’t be afraid or listen to what they say on TV. Just go out to fulfill your dreams. No matter how cliché it seems, people have to stop saying that they want to do something and just do it!

Becoming a Self-Taught Mechanic

Our team member Kenjy, enjoys working on cars. Here he tells us some things about his hobby.

How was the taste for automotive mechanics born?

I’ve always liked to see how things work out, it seems something mesmerizing to know how things work. Since I was a child, I loved to disassemble things to see what they had inside. I could not always reassemble them and when I did it, I did not always use all the pieces. When I finally had a car, It was the “maximum toy” because is very interesting to know how it works and how all the pieces harmonize with each other to be able to work, and also because I was always passionate about cars.

What do you usually do in cars?

I love that everything works properly and try new things, in a certain way to experiment. I have done several things in the limited of my experience and knowledge of mechanics that has been based on the same maintenance of the car, oil change, repair of air conditioning, electrical wiring, change of seats, modification of the interior panel, modification of the interior, brake maintenance, change of the cooling system, tuning, maintenance of the acceleration body, change of the lighting system; among other things. I know, it may sound boring and for many people, it is more a “job” or it is something that would leave someone else to do it or is what they usually do in any workshop, but for me, it is a hobby that relaxes me. I don’t know how to describe it, it just changes my mood 🙂 As much as cooking or building things.

What brand and model of car did it cost you the most to build?

It is a very ambitious question. Not everyone let me play and experiment with their cars, much less I have the ability to assemble a whole car but let’s say I played with a Ford Escort Mk1, Toyota Corolla Diesel 2000 and Toyota Corolla 97 5ag. However, the car of my dreams is a Ford Mustang Boss 302 from 1979.

How much time do you dedicate to this hobby?

The time is dynamic, when it is necessary to do something or when it is just to relax. I would say that about 20 hours a month. Nowadays, responsibilities have increased and well, there is no longer as much time available as before.

What do you like the most when you built up a car?

The process, It passionate me the most. It’s like as a child you play with “cars”, and now, many years later, I’m still playing with them. It’s the feeling of pretending to play a mechanic that I love, building things. There is no target perse, there is no goal, it is only the time one uses; I enjoy it very much. It’s like when you love music and listen to many genres and many musical pieces, you do not have a target or a goal, you just enjoy the moment while doing it, it’s something like that.

Humor and Stand Up!

Our Santex Team Member, Andy Palacios, tells us about his experience doing Stand Up perfomances.

  • Why and how did you come up with the idea of doing stand-up?

I am always saying silly things, and many friends asked me to do or dedicate myself to putting together monologues of the stories that I told them. It was very common in my previous jobs to tell my colleagues something that had happened to me on the weekend and it made everyone laugh. Someone always says to me “Please Andy, dedicate yourself to this…leave the IT world!”. This tells me two things, either I am a very good humorist or I am a very bad QA hahaha.

  • What is humor to you?

Humor means so much to me. I find it really difficult to relate with someone without humor between us. But beyond that, it seems very important to me to be able to face difficult moments with humor. I’ve always said that no matter how difficult or ugly some moment in your life is, it will always become a good anecdote.  

  • Which are your favourite topics for the stand up shows?

Usually, I talk about things that happen to me, or that I see in my day to day life. Also I talk about things that happen to people that are close to me. Some people tell me an anecdote and in the show I exaggerate it or invent details which are a little more unusual.

What I don’t like is being rude, although sometimes I use it, it’s only so that the language sounds natural like when I talk to my friends. Also, I don’t like to attack anyone, I only try to talk about things that could happen to any of us.

  • Do you remember how your first show went? How did it go?

It was recent, in February…so I remember it really well! It was at the end of a Stand Up workshop that I did. The idea was that at the end of that workshop we would go to a bar and do the show. I was really excited, but never afraid or nervous. I visualized that nothing bad would come of it. The truth is that the experience exceeded my expectations.

  • What are the best and worst things that have happened to you on stage?

The best thing was the surprise I had when I realized that there were people who enjoyed what I was doing. The truth is that I still have very little experience to have had something really bad happen to me. The only thing I can say is that is very difficult to perform the show when half of the public is distracted and talks or makes noises.

  • Do you admire a comedian? Who and why?

Although I’ve seen very few live shows, I really like Fernando Sanjiao, Sebastian Weinraich, Luciano Mellera, Fernanda Mettili from Argentina. The best international performers are Aziz Ansari, Dane Cook, Iliza Shlesinger, among others.

Code documentation good practices

By Francisco Verastegui – Santex’ Technical Board Member

Code documentation is an important practice of the development process and it’s worth the effort in the long term as the application gets bigger and more complex, letting us save time and minimize the learning curve to understand the functionality of the API, libraries and applications. Here we explain 4 practices that we hope you embrace as part of your development process.

  1. Document your APIs in a simple and concise way

Libraries and APIs are made to be used by people that might not have time to read the code or just might not have access to it, so documentation should reflect your code objectives in a simple (easy to understand) and concise (focusing on the important facts) way.

  1. Keep your documentation code up-to-date

Update your documentation each time you change your code – especially if business rules are affected. Software evolves over time, and so does the code. Therefore it’s important not to start documenting too early in the stages of the code because you might be forced to change it a lot of times.

  1. Focus on the ‘Why’ not the ‘How’

The main idea of this principle is: “Your code documentation should explain the ‘Why’ and your code the ‘How’”.

Good source code can be self-explanatory, but we should give it meaning. So we shouldn’t repeat the how. The following examples explain the same method with different code documentation approaches. The examples are in Java, but we are able to apply these concepts to any other programming language as well.

Example 1

In this case, the code documentation (JavaDoc) just explains the ‘How.’ The context isn’t clear, and neither are the business rules that are the reason of the creation of the method. Basically, the documentation is providing the same information that we could get reading the code.

Example 2

In this example, the method’s JavaDoc focuses on the ‘Why,’ explaining the context and the business rules that support it. It is also important to explain the business reason behind an exception that the method might throw.

Detailed explanation

“When we are editing a recurring series”: This is the context – whether to include it or not will depend on if it is a business-related method or just an ‘isolated’ method like the ones we can find in a utility class (reused by different parts of our code).

“we have to enforce the rule that recurring {@link Order}s can’t exceed a period of more than 24 hours”: This is the main part providing the ‘Why’ because it explains a business rule and the main reason for creating the method. A method can explain, or be supported by, more than one business rule.

“If the remove TIME portion is less than the install TIME portion, then it is safe to assume that the remove date has rolled onto the next day (e.g. June 1st 7PM -TO- June 2nd 3AM, is still a 24 hour period)”: Business rule considerations are important to have a good understanding of the method behavior. To include it or not will depend on the complexity and conditions of the rule we are trying to code.

@throws OrderEditException

– if the order was already deleted by a different user: Explanation of the reason (Why) the method is throwing a specific type of exception. It is recommended to do this for any application business exception.

It is important to realize that it is perfectly possible to understand the meaning and the business implications of the method just by reading the code documentation. This is a key concept for APIs that are public and designed to be reused throughout different projects and applications.

  1. Don’t document trivial code

Avoid documenting getter or setter method (unless it does something business-related), so remove it from your IDE’s auto-generated code template. Avoid documenting simple procedures perfectly explained in reading the code. For example:

As you can, see doing this only makes code harder to read.

Coder + Gamer

Mario Luna tells Santex how creating video games is the perfect combination of all of the things that he loves.

Tell us how you first got interested in developing video games?

Video games have almost alway been part of my life. When I was 9 years, the idea of creating a video game came to me. I was looking for some programs that could help me create a game, and I found some good tools, but didn’t know how to use them.

Later, when I was 14, I started to learn video and image editing. Then, I studied 3D editing and music composition. At the age of 17, I knew that I wanted to dedicate my life to some of these skills, but I couldn’t decide between them. The only place where all of those aspects converge is in video games. I went back to the beginning, but this time with more knowledge than before. I learned to program on my own and noticed that I liked it above all the other skills I’d learned. Since then, I have been slowly investigating the process of developing video games.

Today, at the age of 20, I am in the last year of my degree as a computer analyst with the intention of dedicating myself fully to video game development once I graduate.

What were your favorite games in the past? Was there one in particular that will call your attention the most and inspired you to start developing video games?

It’s impossible to choose only one, or even a few video games! I loved so many, but my favorite genre is FPS (First Person Shooter). Ones that I can mention are Call of Duty 4, Half-Life, Serious Sam 2, Counter-Strike, Left 4 Dead, among others. I also liked strategy games a lot, like Commandos, Age of Empires and Age of Mythology. Many of them I played in multiplayer with friends when I was younger.

A game that drew my attention was Bionic Commando when I was 9 years old. It’s an FPS with a mechanic that allows you to fly through the cities (or rather swing). When I played it, I wanted to be able to create a game with esthetic and/or similar mechanics and it led me to research how to do it. I think that thanks to that game, I love post-apocalyptic esthetics in video games or movies.

What do you like most as a player? As a developer?

As a player, I love a good story as well as a great narrative. I think that although it isn’t everything, a big part of the experience when playing is being able to tell a story that can distract you from the real world and immerse yourself in the game, creating the abstract of a great adventure.

Another thing that I like is the atmosphere of a game. It is not the same to make a horror game with strong light and shades of pink everywhere as it is a dark setting in an abandoned place where the player does not know where the danger might come from.

As a developer, I like the fact that I can tell a story by letting the player experience it as something that he, by himself, performs, and not as something told or seen, such as in a book or a movie.

Are you working on any gaming projects currently? If so, what?

I am currently doing the sketches and beginnings of a clone of the old Arkanoid. Long ago, I liked the series of mobile games called Block Breaker. I was a little disappointed when I found out that there are no titles for the most current platforms. That’s why I want to develop my own version of the game as a tribute. It’s a small project, but it’s pretty good to start with. This would be the first game I develop by myself, which I hope to see finished completely.

It is something new in a certain sense because so far, my experience has not gone much further than simple prototypes, so I am excited about being able to call this a game made on my own.

How long do you take to develop a video game? Is one person required?

A video game is composed of: programming, 2D digital art, sound effects, music, 3D, animations, script, lighting, conceptual art, level design, post-processing effects, platform and OS configuration, optimization, marketing, licenses, patents, publications, etc.

A person can do all this on their own, but it depends on several factors, such as the person’s ability, the size of the project, the budget among others. Some projects can take years and others only months, but as a rule, one person cannot or should not take charge of a project alone, because the benefits of being surrounded by a team are many.

To conclude, what do you think would be the biggest challenge when developing video games?

Almost since its inception, the video game industry has never stopped growing. Today there are hundreds of free tools available to developers, which has led in recent years to the creation of thousands of “indie” video game companies. These video games don’t depend on a big distributor like EA Games to position themselves, because with some marketing strategies and distributors like Google play or Steam, they can be published at a very low cost.

The massification of video games is good because it provides a greater amount of games on the market, but on the other hand, it prevents games that deserve greater recognition from being seen and judged as they should.

The biggest challenge for any new software developer is to ensure that their video game is seen and played by a large number of people, including competitors. The success that it has depends largely on this, because a game that does not become known, even if it’s a great title, is considered a failure. There are ways to counteract this, such as showing the video game to the community during its development phases, to determine how much expectation or “hype” the game has, as well as feedback on what features people would like to see in the game.

Marketing strategies are usually forgotten by independent developers, but they are very important for the positioning of a title in the industry.

 

Good committing

By Jose Torres – iOS Developer at Santex

People in software development know there are a ton of difficulties a team faces when working on software projects. That’s why best practices were introduced as a way of preventing  common problems that software teams eventually face. Best practices cover many aspects, from the environment setup to the way we write code and produce deliverables. Unfortunately, one aspect usually forgotten or underestimated is the handle of the repository. This usually happens when the team is small – if you are the only member on the team, you are prone to get disorganized. This can dangerously hide other potential issues usually faced when the team grows and you find yourself in complicated situations or flows. As the team increases its size, a lack of good practices will reveal itself and problems will surface.

As engineers, we should understand the importance of doing things right. It shouldn’t matter that our current context shields us from facing complex situations. We have to be prepared for when the context changes and things start to scale. It happens often that engineers have this feeling of “things are working fine,” so therefore the context is “that should mean we are doing things well,right?” Not facing issues in the moment is not a guarantee that things are being done right.

There are many areas of good practices surrounding Software Configuration Management. Let’s focus on some of the best practices when committing code.

When committing code, we are introducing new code changes to our code base. In distributed version control systems, this is done first in our local repository and then the code is applied (“pushed”) to the central repository. There are multiple approaches on how to handle the branching model of a repository, but we will focus only about the committing. It is basically a general rule that a commit in code should reflect an atomic change. This means that it can only be applied entirely, never partially. And, of course, it should not break the build. All build routines and tests should run successfully.

When committing code, we also have to include a commit message. This message is meant to give more information about the code changes that have been introduced. Such a message will last through eternity, and it is our duty to use it wisely.

Image 1: Sample git log

Limit your commit first line (title) up to 50 characters

This is one of the most common suggestions, but it is still forgotten. The first line is treated as the title of the commit. This means it should be brief and concise. It must be no longer than 50 characters, and ideally should not be too short either. This characters length may not be a hard limit, but having it in mind ensures that the author thinks for a moment on how to concisely describe the commit. This helps to get quick contextual information when navigating through the git history and ensures that all clients will display the commit info properly.

Consider a blank line before the description

In order for Git to differentiate the title from the body of a commit, a blank line must be added. Of course, this is only required if we want to add a description. Whether a description is needed or not is up to the author. However, it is a good practice to include a description that adds an explanation of the changes introduced and also some contextual information, like a related ticket number or link.

Include a link related to the issue on Bitbucket/GitHub/JIRA/etc

This is related to the previous suggestion. It is important to have a reference to the source of the request, so we can have more context of the change overall. This should not be part of the title of the commit, but rather part of the description with the full link. If it is a bug fix, requirement, enhancement, etc., most of these are tracked with software development tools that assign them a unique identifier which makes it easier to track development. On one hand, it helps each commit in the repository to have a full reference. On the other hand, it gives visibility to external tools about when, by whom and in which branches the changes are applied.

Write the message using present tense/imperative mode

Finally, the golden rule of committing: all the writing must be done using an imperative mode like [FIX] and not using past tense like [FIXED].

Define a template

Having all of the previous considerations in mind, the team should define a template. After discussing what should be included in the ticket as the description and syntax of the titles, your team will have a clear idea of how they should commit code. Here is a sample I use for my current project:

Image 2: Sample of a git commit structure

All of these good practices will be useful in many situations that software teams often face.

Help during the review process

When doing code reviews, we have to check all of the new code that is introduced. Having a clean commit history with descriptive titles and useful messages helps to understand the reason behind the changes. Also, as the reviewer will have access to the description with a link to an external tool, he/she is able to understand the full context of the change.

Help when handling merge/rebase operations

This is my favorite. Every time we have to deal with rebase operations it is extremely useful to have a clean commit history. This helps to make sure you are moving the right code changes from one branch to another. Without this information, it will be almost impossible to do without having assistance from the original author, which as we know may be impossible sometimes.

Help when writing release notes

At the moment of preparing the release notes, a clean commit history is useful so we can see all changes that are part of our release branch (or any branch we are using to prepare a release).

Help during maintenance

Finally, one of the most important reasons for having a clean commit history is so that we can understand changes that were introduced a long time ago. Often as software engineers, we are in a situation of not understanding why a specific change was made or why a piece of code was originally introduced. A well written commit will bring together all of this information, and will give important insight for the new authors to avoid having side effects when performing a change.

Image 3: Sample of a rebase operation for moving code between branches

There are really a ton of recommendations and conventions for good committing. These were just some of them! These are the ones I think are the most basic and need-to-know, and are based on the official Git Man page1.

Let me know if you have any others you would like to add or suggest.

Links:

– [1] https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-commit.html#_discussion

Music that Moves You

Maria Alejandra Diaz tells us about her experience playing the cello in her homeland of Venezuela, and the hopes she has for the future in her new home, Peru.

What made you decide to study music? Was it a personal decision or something your parents made you do?

Honestly, ever since I was little I’ve been very interested in the fine arts. First it was ballet and contemporary dance. Later I took up painting. Now that I’m an adult, I’ve entered the world of what is known in Venezuela – and internationally – as  “El Sistema,” which was founded by maestro Jose Antonio Abreu. His main objective has been to broaden the horizons – culturally and musically – of the country and get the youth interested in music.

My parents were always the first ones to support me in any initiative I may have had surrounding my curiosity for the fine arts. They supported me in developing other skills not just related to academia, although the decision was always mine to pursue such activities. They encouraged me to stick with such activities and not just abandon them further down the road.

Why the cello and not something else? Did you ever consider pursuing other instruments as well?

At first, I was most interested in the violin. My dad took me to see the Children’s Orchestra of Tachira, which is the province of Venezuela where I’m from, so that I could get a better idea of what instruments caught my attention. From that moment on, I decided I wanted to learn to play the violin.

Later, I auditioned for the Youth Orchestra Foundation “Luis Gilberto Mendoza” which was the base from which El Sistema operated. They evaluated aptitude for rhythm and solfege which is the fundamental basis for every musician. They loan out instruments and let you use their facilities until you can raise enough money to buy your own instrument.

When they asked me which instrument I wanted to play, they told me that there were no violins available to loan out, and they only had cellos and trumpets available. Of course, the trumpet was never to my liking, with the mouthpieces and parting of the lips and everything, and therefore I stayed with the cello, which was the best decision I could have made. It is an instrument with a unique sound and accompaniment and is – according to expert opinions – the sound that most resembles the human voice.

Are there musicians in your family?

My great-grandfather, on my mom’s side, had an orchestra called “Filo Rodríguez y Su Orquesta” in the 1940s. He was a trumpeter and the director. One of his sister’s was also an opera singer in a circus in Italy during the same time. My mother played piano, my father participated in the Christmas masses in choirs and playing, and my sister is an opera singer (Mezzo-soprano).

How old were you when you performed at your first recital? Where was it?

They usually recommend that you start studying music at an early age, not only because it’s common knowledge that children pick up new skills more easily, but above all because of the muscle memory that comes with studying string instruments (violin, viola, cello, bass). Starting early helps your fingers develop accordingly. For example, for the case of the violin, it is best that players have thin, not so large fingers. In my case, I started at 14 years old, and I had my debut 3 months after starting at the Pre-Children’s Orchestra in San Cristóbal – Táchira State.  This was, of course, very ironic because of my age, but it was the group that It started at the same time that I entered “the system” and it was for ages 8 to 12. There was already a Children’s Orchestra, so we could not call ourselves the same thing or play the same pieces as them because of the level of difficulty .

Then I moved quickly to the Children’s Orchestra and then to the Youth Orchestra. It was in the latter that I had the opportunity to play as a guest on 2 occasions with the Simón Bolívar Symphony Orchestra of Táchira. A year and a half later, I formally joined that orchestra.

With the Simón Bolívar Orchestra, I had the opportunity to be a soloist and play with musicians of international renown – such as violist Frank Di Polo, pianist Arnaldo Pizzolante, and guitarist Alirio Díaz, among others.

Who are some musicians (past or present) that you admire?

Among the musicians that I admire most are Jacqueline du Pré and Yo-Yo Ma. With rock, I like Apocalyptica, which is a symphonic metal band formed by 4 cellists graduated from a classical music academy called Sibelius. In the beginning, they covered Metallica songs which then made them famous. Also, 2cellos is a duo of Croatian cellists who make versions of songs by Michael Jackson, Guns and Roses, Jimi Hendrix, and more. It’s really fun to listen to them.

How much time do you dedicate to practicing cello?

In Venezuela, I devoted every afternoon to studying and practicing cello. The Foundation had an academic center where they teach classes in rhythm, theory and solfege, harmony and then classes related to each specific instrument taught by a professional – usually members of the Simón Bolívar Orchestra. All of these classes were distributed throughout the week.

In addition to the classes, there were also rehearsals with the Orchestra, which were everyday, Monday through Friday from 6pm to 9 or 10 at night, depending on the difficulty of the work and the time needed to rehearse. If they were complicated pieces to execute, each leader who was a kind of representative of the group of musicians for a particular instrument, would host additional workshops to go in depth and see the synchronization, harmony, solos, and tuning.

It really was a full-time commitment. But when you like what you do, you’re not aware of how much time it takes.

Do you have plans for the future with regard to music?

Since I moved to Peru, I have not been able to continue with music because when I left the country, I didn’t know where I was going to settle down. Also because of economic issues, I had to sell my cello in Venezuela to help my mother with medical treatment. I’ve been checking with friends who still belong to El Sistema to find out if there are organizations like the ones there which can help me with loaning a cello while I save to buy my own, and also where I could resume my classes. In the near future, I hope to belong to another orchestra and continue enjoying this most beautiful form of art.