This tutorial requires only a macOS device, the iPhone and the phone's power cord. If you have the iPhone paired to the macOS device through wi-fi, you don't need a power cord and can skip steps 1 and 2. This tutorial was based on macOS Ventura and it applies on older versions of macOS as well.

Steps

1. Connect the iPhone to an USB port of your macOS device.
2. If the iPhone asks for permission to trust the macOS device, grant it (assuming it's a device you trust).
3. Open the Finder app.
4. Go to the iPhone in the Locations section of the sidebar. It should open the device's page.
5. Click on the info section bellow the iPhone name on the top of the page until it displays the UDID.

You can copy the UDID by right clicking on it.

With this post you'll learn how to rewrite the whole history of a branch. In other words: undoing all commits but keeping their changes to be committed again.

Let's say you have four commits:

f7f3f6d Create FileA
310154e Update FileA with x
a5f4a0d Create FileB
421265e Update files A and B with Y and Z

But you want to rewrite the whole history to have just two:

Create file A with X and Y
Create file B with Z

Sure you can manipulate the tree of changes with the git rebase -i command (reference), but there is a more straightforward way of rewriting a branch: with git reset --soft .

Let's see how to use this command.

Doing a Soft Reset

Assuming you're branch was created from a branch named master, just run (running a git fetch originfirst is recommended):

$ git reset --soft origin/master

Now you're going to have all of your commits undone, but their changes will be kept as added to your stash. You can also use HEAD~4 instead of origin/master to undo the last four commits, for example.

So, running a git status should return something like

$ git status

On branch your_branch_name

Your branch is ahead of ‘origin/your_branch_name’ by X commits.

  (use “git push” to publish your local commits)

Changes to be committed:

  (use “git reset HEAD <file>…” to unstage)

modified: FileA
modified: FileB

Again, you can see that both FileA and FileB are added, but not commited. You can undo this by running git reset HEAD . (your changes will remain, don't worry).

Now you're free to rewrite your commit history as you want!

Disclaimer: if you already have pushed your changes to a remote repository, you're going to use git push --force to send the new changes to the repository. Proceed with caution!

You can check more posts about Git Basics below:

• Git Basics: Combining two (or more) commits into just one
• Git Basics: Adding more changes to your last commit
• Git Workflow Basics

Git Basics: Rewriting a branch's commit history from scratch was originally published in magnetis backstage on Medium, where people are continuing the conversation by highlighting and responding to this story.

Many companies around the globe are hiring remotely and this number is only increasing. A remote worker is an employee who does not need to commute to an office or any kind of central place of work.

I currently work at Magnetis Investments, on a team with around ten software developers. Most of them, as me, are fully remote and we live in states other than the one from our company’s headquarters.

As a remote web developer, I'm writing this post with a small introduction and some useful tips for those who are considering this alternative. This post is also for those who already are remote workers and seek for improvement in their routine or practices. Even though we're a team of developers, most of the concepts and tips bellow can work for any area.

Let's start with…

Some Pros and Cons

First of all, what do you have to keep in mind when considering going remote. There are way more topics on each subject and each person may consider different things as pros and cons.

Pros

One of the main advantages for working remotely is the lack of commuting. Spending a couple of hours daily on traffic can be a pain in the ass for most people.

The lack of geographical barriers also enables companies to hire good employees wherever they want.

The other way around is also totally true. Even if you don't live in a tech hub, you'll still be able to find a good job somewhere else without moving.

Cons

It demands more organization from both the company and the employees. People will have to take care of themselves and be trusted with this kind of responsibility.

Loneliness may also be a problem for some people and must be addressed by managers with some practices I'll describe in this post ;)

Productivity can also be another problem. Some people can underperform due the lack of "supervision" while other can work way too much which can lead to burnout in the future.

"Remote work isn't for me"

Well, maybe it isn't and there's nothing wrong with it :)

But keep in mind that a whole lot of people already does remote work but does not realize it. Outsourcing workers mostly do their jobs as remote workers for other companies. One of my previous jobs was as a outsource developer. Even though I was located in Brazil, my client's team was located both in other cities from Brazil as even in the USA (in a different time zone). To them, I was a remote worker.

But again: it's totally OK to not be interested in doing remote work.

What do you Have to Keep in Mind When Working Remotely

Since your team will be distributed (some times even across different time zones), most of your communication will be done through writing. Being clear and concise is essential. Online text chats like Slack and Hipchat will sometimes be your main work tool.

But keep in mind that just text can't solve all of our communication problems. People have different schedules and have to work their own demands. Don't expect everyone to be available all the time and try not to break someone's flow (which in a nutshell can be described as the mental state that people achieve when they're fully immersed in what they are doing).

Here are some tips on how both a team and an individual can be remote friendly.

What a Team Can do to be Remote Friendly

Again, the main goal here is to avoid wasting people's time. Most of the following tips aim to achieve that.

Documentation and Phase In

To achieve that, your team can start by having processes and any other type of flow "documented". This can make the phase in / on boarding of newcomers very easy while preventing someone to have to spend some time on repetitive tasks over and over again. A list of software used by your team, and the reasons behind, as well as a list of obligatory appointments everyone must attend is a good start.

But be careful to not end up with a team too "cold" on newcomers. It's always a nice thing to spend some time and talk with them, specially if this is their first experience being remote. It must be clear to them that your team is open to answer any questions they may have.

Some Notifications are Welcome

As I mentioned, remote workers spend most a good chunk of their day on text chats. For some teams, it may be useful to have some automatic notifications on, to prevent people from having to do the same thing twice (doing the action AND notifying about it). For software developers, for example, it's useful to have a notification every time a new release is made available to their users of if someone found out a critical issue in their code.

You only have to be careful to not flood everyone with each and every type of notification possible. Too much noise can prevent people from focusing or even to paying attention to notifications at all, which can lead too important stuff to going unnoticed.

Make a Good Use of your Means of Communication

Sometimes, only text chats aren't enough. More detailed explanations or long discussions can often be done way more efficiently on online calls in services such as Google Hangouts, Skype and others (Slack, for instance now has this feature built in).

Other important topic on this matter is always try to involve in a conversation the least amount of people needed. If the subject is not from the interest of someone, they should not be involved. Again, this is to prevent people from going out of their "flow".

I have a whole post about means of communication, so take a look if you're interested.

Some Meetings are Okay

Having a short daily meeting to where people describe what they have worked on the previous day is a good way of achieving two good things:

1- Keep everyone on the team on the same page

2- Increase the notion of team

Make sure that those meetings are short and in a good time for everyone. In the middle of the morning or the afternoon are not usually good times for meetings since they can break people's concentration during an important task.

Screenshare and Pair Programming

This is a practice where usually two developers work together to solve a problem. Remotely, it can be done through screensharing tools, which allow your "pair" to see and sometimes even interact with your desktop while having a voice chat at the same time.

It's an excellent practice to promote knowledge sharing and reducing the feeling of loneliness.

Some chat clients like Slack have a built-in screenshare tool. Google hangouts also has this feature (even though it takes much more of your CPU). Screenhero is another great alternative and personally my favorite (but at the time I'm writing this, it's only accepting new users by invitation of current users).

When screensharing, one good thing to do is to disable notifications to keep up your privacy. Apps like Muzzle for macOS (their site is just great) can automaticaly disable notifications when a screenshare tool is on. Using different a different desktop area for work can also help.

But be careful: too much pair programming (like any other type of meeting, actually), can be very tiresome. Ensure that people have time to rest between work sessions. Some people like to use the Pomodoro Technique or other variations on it.

Don't Go Full BIG BROTHER on Your Team

Some companies that allow remote work do that under very strict conditions. They require their employees to install software to monitor stuff like keyboard activity, webcam and microphone, OS processes and others to ensure that their employees were being "productive". Time spent away from the computer (like bathroom breaks) are discounted from the employees paycheck.

I should not have to say that it’s very stressful to work under strict vigilance.

If you're a manager and you're trying to implement remote work for your team, keep in mind that tools like that are not well-seen by many. Trust your teammates and avoid this kind of stuff at all costs.

And if you're looking for a remote job opportunity, be sure to know if the companies you're applying to implement these types of policies.

And now, some tips for individuals on a remote team.

What You Can do to be Remote Friendly

Here the goal is to keep everyone aware of what you're doing.

Make clear to everyone whether you're available for chatting / questions or not. Slack, for instance, has a great status feature where you can easily describe what you're doing in the moment. But just to be clear, try not to annoy anyone in the process. Not everyone needs to know RIGHT ON THE SPOT that you're having lunch.

Having a routine can also help your teammates to be aware that they can or can't count on you for something in the moment.

With that in mind, remember that people have their work to do an they usually can't reply instantaneously.

Also, giving as much details as possible is always a nice thing to have. It'll prevent your teammates to have to ask you from something that was not clear and enable them to work more independently (if they work on a different time schedule than you, for example). Writing more, providing links, examples and related information will take you a little more time, but can prevent much more time waste in the future.

Take Care of Your Health

As I mentioned earlier, home office can be very tricky in terms of productivity.

Be sure to have a clear division between work and free time. When your workday is over, closing your chats, email client and any other thing that reminds you of work can help with this. Some may take this to a next level having an specific spot in their house just for working. Having different desktop areas can also help.

Snoozing notifications is also a great thing to do. It's hard to forget about work when you're constantly being reminded that something is happening there.

This is the type of issue that can, with time, lead to burnout and sometimes leave serious scars on one's mental health. But hey, this is something that already happens even with non-remote workers!

TL;DR

• Remote work can be a good opportunity if one can't stand commuting or the place you live doesn't match your career goals
• But has its challenges, specially regarding organization and trust
• A team has to make good use of the means of communication available, always allowing people to have time to do their work uninterrupted
• An individual must keep people aware of what they're doing and remember that their teammates also have work do it
• And always remember to keep work and free time very apart.

Not all of those tips may work for you or your team, and that's just fine. Everyone has a different workflow, after all.

If you're interested in more tips about remote work, this short video from Mozilla and the book Remote: Office Not Required and can be a good start.

And if you have any other tips or questions, be sure to leave them in the comments :)

Thanks for the reading!

Remote Work: Introduction and Tips was originally published in magnetis backstage on Medium, where people are continuing the conversation by highlighting and responding to this story.

Como o próprio título diz, esse post é uma continuação desse outro. Agora vamos falar um pouco sobre alguns conhecimentos mais avançados que são um diferencial no momento de uma contratação.

A intenção aqui é estimular uma pesquisa mais avançada sobre cada um dos tópicos. Definir tudo em detalhes aqui deixaria esse texto muito longo.

Vamos lá!

Testes Automatizados

— Como você sabe que o seu código tá funcionando?

— Eu rodo e testo

— Beleza, mas e quando você faz uma funcionalidade nova?

— Testo ela e as funcionalidades anteriores.

— Mas e se você tiver 100 funcionalidades?

— Aí complica um pouco, né?

De fato, complica mesmo.

Todas as linguagens de programação comerciais atuais possuem algum framework de testes automatizados. Esses testes podem ser rodados com um simples comando e realizam uma série de procedimentos e checagens (definidos pelo desenvolvedor) de maneira autônoma, podendo até mesmo simular as ações do usuário navegador, por exemplo.

Testes automatizados te dão uma segurança maior no seu código e, principalmente, que ele não quebra o que já estava pronto antes. Para grandes aplicações, é praticamente inviável realizar um checkup manual completo em todas as funcionalidades antes do lançamento de uma nova versão para o cliente.

Ter conhecimento sobre os conceitos de testes unitários e de testes de integração também é fundamental. Essa resposta no Stack Overflow dá uma boa definição.

Para cada linguagem/framework geralmente existe mais de um framework de testes. Procure um pouco sobre cada um e estude aquele que mais se adequa ao seu gosto e necessidades :)

O Básico de REST

REST é um "estilo arquitetural" usado para comunicação entre aplicações na web. O conceito é bem mais denso que isso, mas o suficiente para você se virar gira em torno de conhecer e saber usar corretamente as operações que envolvem os verbos HTTP: GET, POST, PUT/PATCH e DELETE.

Quando você acessa uma página de qualquer site, seu navegador por padrão envia uma requisição contendo um desses verbos (e somente um por vez).

Por exemplo, ao simplesmente acessar www.google.com.br, seu browser manda para esse endereço algo como "ei, me manda essa página aê". Ele quer receber algo, logo, o verbo enviado é um GET (como a tradução sugere).

Agora para casos em que você submete uma informação nova (como um formulário de cadastro, um novo status no facebook ou algo do tipo), seu navegador envia uma requisição contendo o verbo POST.

Já em casos onde você atualiza um recurso já existente (como, por exemplo, uma redefinição de senha ou alteração de dados cadastrais), o verbo PUT (ou PATCH) é enviado.

A diferença entre os dois verbos é que PUT envia todas as informações sobre o recurso que está sendo atualizado (no exemplo da redefinição de senha, seria enviada tanto a senha quanto os demais dados do usuário, mesmo não sendo necessários para essa mudança), enquanto PATCH envia somente a informação atualizada (ou seja, somente a senha no caso do exemplo). Em geral cada framework para web utiliza um desses verbos por padrão, então fique de olho.

E o caso do HTTP DELETE, como o nome sugere, é utilizado em casos onde um recurso está sendo excluído de uma aplicação.

"Tá, mas pra que eu preciso saber disso?"

Ao desenvolver uma aplicação web, você vai ter que se atentar a fazer com que seu código siga esse estilo arquitetural de maneira correta. Ou seja, não inventar de usar o verbo DELETE pra designar a ação de atualizar um recurso, por exemplo.

Um caso muito frequente é de aplicações que usam POST erroneamente para todas as ações. Você já deve ter notado isso em páginas que toda vez que você dá um refresh ou então um voltar, seu navegador pergunta: "Você deseja enviar seu formulário novamente?". E nessas horas você pensa: "Mas peraí, eu não enviei formulário nenhum…". Pois é, você acha que não enviou, mas foi o que o seu navegador fez por debaixo dos panos pra gambiarra contida na página funcionar.

Sendo assim, faça sua aplicação manter um comportamento que faça sentido semanticamente com relação aos verbos HTTP.

O Básico de Organização de Código

Se você está usando um framework para desenvolver sua aplicação, terá que seguir um mínimo esquema de organização/padrão estabelecido por ele.

A maioria dos frameworks web, por exemplo, segue o padrão de projeto MVC (Model-View-Controller). Ele por exemplo estabelece que sua aplicação possui componentes para acesso de dados (Models), para a apresentação de informação (Views) e para a manipulação de requisições e retorno ao usuário (Controllers).

Dito isso, note que não faz sentido usarmos um componente de View para acessar o banco de dados da sua aplicação diretamente. Ou que um Model retorne HTML, por exemplo. Para quem está começando, essas razões podem não ser tão claras, mas como esse não é o objetivo do post, deixo essa parte como "tarefa de casa" :P

Vale lembrar que para cada padrão/modelo arquitetural diferente, existem diferentes formas de organizar o código da sua aplicação e responsabilidades. Dessa forma, sempre se pergunte se aquilo que você está implementando no momento realmente deve estar ali e procure referências na web com as melhores práticas para o framework de sua escolha.

Formatos de Troca de Mensagem entre Aplicações

É muito provável que você em algum momento da sua carreira tenha que desenvolver alguma integração entre sua aplicação e uma externa, ou até mesmo entre duas aplicações de sua própria autoria (exemplo: um aplicativo mobile e um servidor seu).

Atualmente a maior parte das aplicações utiliza o formato JSON para essa tarefa. Antes, XML era o formato mais adotado. Essa padronização é independente de tecnologia, permitindo que aplicações implementadas em linguagens ou frameworks completamente distintos possam trocar grandes volumes de informação através de um "idioma comum".

Para entender um pouco sobre JSON, recomendo a leitura dessa documentação sobre como sua API deve responder a chamadas desse tipo. Certamente a linguagem de programação de sua preferência possui alguma biblioteca que implementa o formato.

Lembre-se de sempre se aprofundar nos assuntos que foram mencionados aqui, sempre colocando em prática cada aprendizado sejam em projetos pessoais ou de algum emprego/estágio/bolsa :)

That actually just tell if your app is running or not. But imagine your databases connections are in a bad shape… This route may not even be affected by it and it will provide you a false positive.

This post describes some tips on how to improve your health endpoints, regardless the language/framework you use.

Return a JSON with your health data

Only sending a 'ok' or 'not ok' may not be totally useful for whoever consumes your endpoint. Instead, you can return a JSON with every status of the checks you do, being more precise on what's going on with your app.

Assuming you'll do the checks mentioned in this post, this can be an example of the response of your endpoint:

Also, remember to properly set the HTTP status of the response to match your application status (200 when everything is ok and a 503 when things are in a bad shape).

Check your DB connections

Whether you use PostgreSQL, MongoDB or any other database, one important thing to check is if your DB is alive and well or if your connections are getting a timeout.

MongoDB, for instance, has a ping command that is able to check if your connection is alive. Remember to wrap this call in a timeout block like this example:

With this check, you can ensure your DB is responding in time.

EDIT 12/20/2016:

As Marco Singer pointed in the comments:

Since you’re calling the databases in this health endpoint I would like to suggest to use a rate limit on it or, at very least, make this endpoint availiable just for internal apps since you’re openning a door for external callers put your system down calling this endpoint several times.

Please be very careful to who you’ll be exposing those endpoints or remember to use a good strategy to prevent attacks to your DB.

END OF EDIT 12/20/2016

Check your Redis connection

This is extremely important if you use any background job processing tool like Sidekiq, which uses Redis to manage its data.

Redis has the same ping command I mentioned for MongoDB, but in this case it returns the string "PONG".

With this you'll be able to make sure your app is ready to process your background jobs.

And about it…

Check the latency of the queues of your background jobs

This check can provide you an insight of your workers: if you have jobs getting stuck for some unusual and bizarre reason.

The mentioned Sidekiq offers you some very handy methods for checking the latency of any queue:

Which can be included in the response of your endpoint:

What about your health endpoint? What do you check? Leave a comment :)

If you are interested in more posts about monitoring, you can check this post about two simple monitoring tools for your app.

With this simple Ruby stack, you'll be able to get live alerts whenever your apps (or the services you depend upon) are in a bad shape.

This stack can be used for example to trigger a Kill Switch mechanism in your app: When your app receives the The Nurse's request into some endpoint, it stops some critical/automatic procedure to keep going.

This can be extremely useful when dealing with a microservice architecture or when you app depends on external services.

This stack can be also be used as a way to keep tracking of your apps outages (it saves every one it registers).

It can easily be deployed in Heroku with almost zero configuration!

Tag along to know how those apps work, why are they useful and how you can deploy your own instance.

Sickbay

What does it do?

Sickbay is a small and simple sinatra app with an endpoint that returns the HTTP status of a bunch of URLs in a single JSON response. It does that by sending a GET request to each URL received.

$ curl -X GET 'http://localhost:9292?google=http://www.google.com.br&bing=http://www.bing.com'

{
  "google": "200",
  "bing": "200"
}

Here's a link for a live demo. And this here returns you a link for the HTTP code of a both Google and Bing.

Why you should use it?

Sickbay can be used to monitor a bunch of health routes at once. With the status you've received, you can act accordingly. And that's exactly what The Nurse can do for you.

Configuration and Deploy

Just push it to Heroku. Simple as that.

For more details on the implementation of Sickbay, please check the GitHub repository of the project.

The Nurse

What does it do?

The Nurse is a small rails app that can alert whoever you want when your apps are in a bad shape. It uses Sickbay for health checking.

How does it work?

1. You can register the apps you want to be monitored (with Name, URL to be checked and the HTTP statuses that indicate your app is fine).
2. Every X minutes (completely up to you) The Nurse checks your apps
3. If N of last Y requests (again, completely up to you) returns a status code different from the one you expect, The Nurse sends a POST request containing the name of the service, its URL and the last Y HTTP codes received. This POST will be sent to whoever URL you want.

The app also registers an entry in your DB for each health check. This way you can easily go back in time and check how was your app at any given time.

Why you should use it?

With The Nurse you can monitor your whole stack at any rate you need and act accordingly when things are going south.

Configuration and Deploy

You can customize:

• The URLs you want to monitor
• The URL of your Sickbay instance
• The frequency of the checks
• How many fails in the last N requests are enough to trigger a warning (N is also up to you).
• Who should be warned when an outage happens (we call it Doctor (get it??))

Your Doctor should be able to receive and deal with the following request:

{
  "service_name": "TheFailingService",
  "service_url": "www.this_service_failed.com/health",
  "codes": ["200", "500", "500"]
}

To check what the environment variables are responsible for each setting, please check the Configuring the app section of the repo.

To deploy the app to Heroku, you'll need at least one paid dyno, since the free plans only support up to two (and we have three components: the server, Sidekiq and Clockwork). Also remember to properly config a Redis to Go addon.

All health checks are stored into Statuses entries. Feel free to run the SQL or active record queries you like to fetch whatever data you want.

Example:

2.3.1 :013 > Service.first.statuses

Service Load (0.3ms)  SELECT  "services".* FROM "services" ORDER BY "services"."id" ASC LIMIT $1  [["LIMIT", 1]]

Status Load (40.5ms)  SELECT "statuses".* FROM "statuses" WHERE "statuses"."service_id" = $1  [["service_id", 1]]

=> #<ActiveRecord::Associations::CollectionProxy [#<Status id: 1, code: 200, service_id: 1, created_at: "2016-11-29 19:25:31", updated_at: "2016-11-29 19:25:31">, #<Status id: 3, code: 200, service_id: 1, created_at: "2016-11-30 17:04:08", updated_at: "2016-11-30 17:04:08">, #<Status id: 6, code: 200, service_id: 1, created_at: "2016-11-30 17:04:59", updated_at: "2016-11-30 17:04:59">, #<Status id: 9, code: 200, service_id: 1, created_at: "2016-11-30 17:05:58", updated_at: "2016-11-30 17:05:58">, #<Status id: 12, code: 200, service_id: 1, created_at: "2016-11-30 17:06:59", updated_at: "2016-11-30 17:06:59">]>

You can do the same for outages:

2.3.1 :012 > Service.first.outages

Service Load (0.3ms) SELECT “services”.* FROM “services” ORDER BY “services”.”id” ASC LIMIT $1 [[“LIMIT”, 1]]

Outage Load (0.3ms) SELECT “outages”.* FROM “outages” WHERE “outages”.”service_id” = $1 [[“service_id”, 1]]

=> #<ActiveRecord::Associations::CollectionProxy [#<Outage id: 1, service_id: 1, codes: [500, 500, 500], created_at: “2016–12–02 15:11:52”, updated_at: “2016–12–02 15:11:52”>]>

We have plans to add a web interface and endpoints to fetch this data, don't worry.

For more details on the implementation, please check the GitHub repository of the project.

Next Steps

There’s still a lot to be done. Here are some features planned for The Nurse:

• Web interface with the live status of each registered service
• Web interface for managing (creating, editing, deleting, etc) services
• Endpoints for fetching service statuses and outages
• Support for reading data from multiple Sickbay instances at once (for multi-zone purposes)

Feel free to contribute with a PR on both projects :)

Enjoyed the idea? Plan to use this stack? Have any suggestions? Feel free to leave a comment!

This post is a summary of some of my modus operandi when dealing with stuff that requires discipline or that you're obliged to deal against your will.

These tips may not work for you, and that's completely fine! Each person's mind works in a certain way.

Let's start!

Get rid of useless distractions on social media

Disclaimer: I'm not saying that you need to go completely offline when you're working on something important (although that works for some people).

My point here is simple: we see a lot of shit on internet these days. You probably have like 300 friends on Facebook and 90% of them spends their days posting fake news, bad photos of their ugly faces, dated memes and political crap.

This kind of stuff is only a waste of your time and sanity.

You don't need to unfriend people who does this. Simply go to their profile and unfollow them (you can also do that straight from a post of the person). Doing so will not stop being friends with them in the network.

The same can be achieved with the "mute" function of twitter.

With Facebook, I also went a step further: I got this amazing browser extension that simply hides any of those "John Doe commented on this" and "Jane Doe was mentioned on this" from your newsfeed. Seriously, I don't need to get every crappy post the mother of some friend of mine on my screen just 'cause she mentioned him in a cat photo.

At the time I published this post, this extension is available for both Chrome and Safari (but there’s probably a similar one for other browsers). Unfortunately, I don’t know any alternative for mobile (if you do so, please leave a comment!).

Another great tip is to mute chat groups that are too noisy or that you are a member “just because” (and this also includes work chat groups).

After this, your social media experience will be a lot cleaner and less stressfull :)

Create a routine

This is a hard one, but give it a change. It's something that works amazingly well to make you do stuff that you're not exactly excited to do, like go to the gym or work on your thesis for college.

At first, it's a struggle to get motivated to do that task but, with time, you'll don't need to "find" that motivation everyday since your mind will simply think "ok, now it's that time of the day when I have to do X".

To make sure you're following the routine you stablished, a good thing to do is…

Add reminders for everything

Let's face it: you probably has a lot of things to do and you can probably list me a hole bunch of them. But do you actually remember that you have to do X when you actually need to do it?

Even if you spend your hole day facing a clock, you'll still have that moments of "damn, I should've done X thirty minutes ago!".

And that's why I add a reminder for almost everything. Need to talk with someone about some topic? There's a reminder for that. Gotta pay some bill? There's a reminder for that. And so on and so forth.

For managing reminders, I use the native Reminders app from macOS since it supports natural language input. So I can easly add a reminder like "Remember to buy milk tomorrow at 8pm" and ta-da! There's a reminder for that™. The "easiness" of adding new reminders is a killer feature and encourages you to use the app instead of thinking "nah, it's too hard to add this simple reminder".

Other good options are Google Keep and Google Calendar/Agenda. They're pretty straightforward and available on a whole bunch of platforms.

With e-mails, I usually use the snooze feature that some e-mail clients today have. With this, I can reeschedule e-mails to disappear from my inbox until the time I should really deal with them, ensuring that I'll not let that important e-mail opened at my inbox forever and forgotten. Inbox by Google and Polymail support this feature.

With this in mind, you'll not waste your time wondering "hmmm, I think I forgot something…" and certainly not actually forgetting something!

Deal with quick and/or small stuff as soon as possible

This one is kind of a philosophy and comes from a whole bunch of self-organizing books but hey, it actually is a good tip!

Assuming you have a whole bunch of things to do in your "pile" of things to do, deal with the ones you can deal in two to five minutes as soon as you have time.

This way you'll certainly not forget about them (they're so small that you'll probably not even care to add a reminder for it if you're in a lazy mood). You also won't carry the burden of having to deal with them for the rest of your day (you know, sometimes you just remember that you have to reply THAT e-mail and think: "oh shit, THAT e-mail. Oh man, I hate myself").

Face it and deal with small shit right away. You'll thank yourself later.

Perhaps all of those tips won't work for you, but at least give them a try. The ones who do work will sure make you hate yourself way less when you have to pay the price of your procrastination and lazyness.

Do you have any tips or variations of the ones I mentioned? Leave a comment :)

This post is an extraction of a subsection of this git workflow tutorial (with a few additions). If you are interested in learning more about the workflow used by many teams around the world, check it out!

This post explains one simple way to combine two commits with the power of git™.

I assume you are working on a branch alone to avoid messing around with your teammates' work. Remember: shared branches are usually very hard to maintain.

Let's get to the point!

You have a commit history like this one (older commits on top):

f7f3f6d create file_a class and methods
310154e improve SomeOtherClass code
a5f4a0d update changelog
a412dbb fix typo on file_a

But hey, notice that on commit a412dbb you’re fixing something that you just added on this pull-request (on the first commit, to be exact)… It would be nicer to have both the creation and the fix of file_a on only one commit!

To achieve that, you can use this awesome feature of git: git interactive rebase.

So we need to merge the first commit (f7f3f6d with the last one a412dbb). And that’s when the interactive rebase tools comes in hand.

$ (some_branch) git rebase -i origin/master

The origin/master param is our start point. This basically is telling git: “hey, we want to change the history since the last commit origin/master”, otherwise known as… your branch!

You can also use HEAD~4 as a param, which works like: “hey, we want to change the history since 4 commits behind the current one”. The official docs has more details on this.

After executing the command, this file will show up (probably on the vi/vim editor. Check this cheatsheet if you don’t know how to use it):

pick f7f3f6d create file_a class and methods
pick 310154e improve SomeOtherClass code
pick a5f4a0d update changelog
pick a412dbb fix typo on file_a

# Rebase 710f0f8..a412dbb onto 710f0f8
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

Now we just need to follow the instructions written there! We want to combine commits f7f3f6d and a412dbb. So we must reorder the lines to be like this:

pick f7f3f6d create file_a class and methods
pick a412dbb fix typo on file_a
pick 310154e improve SomeOtherClass code
pick a5f4a0d update changelog

And we change the pick label on the a412dbb commit to a fixup (or f), to tell git: “hey, we want to combine this guy with the one above it”:

pick f7f3f6d create file_a class and methods
fixup a412dbb fix typo on file_a
pick 310154e improve SomeOtherClass code
pick a5f4a0d update changelog

Save your file and bang! Here’s your new commit history:

b7c3f33 create file_a class and methods
1b24ae9 improve SomeOtherClass code
d5ffad3 updates changelog

(yeah, the hash of all commits changed due the rewrite of the history).

If you already pushed your branch to remote, remember to use -f next time you push, since you’ve rewritten the your commit history:

$ (some_branch) git push -f origin some_branch

Be warned: pushing with -f is a very dangerous thing. Proceed with caution and always be sure that you’re pushing to the right branch.

And there you go!

Remember: NEVER rewrite the commit history of public branches (like master). This will truly mess your teammates work.

To combine three or more commits into just one, just edit your file to be like this:

pick f7f3f6d this is my first commit
fixup a412dbb this commit will be added to the first one
fixup 310154e and this commit too
fixup a5f4a0d and also this one

All the commits you want to combine into the first one are with the fixup tag.

And you're good to go :)

If you want to simply add a few more changes to your last commit only, it's even easier. Check this post.

Stuff like splitting a commit into different ones and some other crazy ways to change your history are described in the official git documentation.

Happy gitting!

With this post you'll learn how to modify your last commit, adding (or removing) some changes. You can also follow this tutorial to learn how to edit your last commit message.

I assume you are working on a branch alone to avoid messing around with your teammates’ work. Remember: shared branches are usually very hard to maintain.

So you have a commit history like this one (older commits on top):

f7f3f6d create file_a class and methods
310154e improve SomeOtherClass code
a5f4a0d update changelog file

But you forgot to add just a single line on the changelog file you mentioned on the commit a5f4a0d :(

You could simply commit it and have a history like this:

f7f3f6d create file_a class and methods
310154e improve SomeOtherClass code
a5f4a0d update changelog file
a4gx124 add missing line to changelog

But that’s just not good for your history (it’s just a change on a change you already did). The best case scenario here is to have both changes in a single commit.

And you can achieve that with the simply amazing amend command!

Just remember: do not commit any of the changes you want to add to your last commit before doing these steps!

The Basic of the Amend Command

Just add the modified file(s):

$ (some_branch) git add changelog.md

And amend it:

$ (some_branch) git commit --amend

After executing the command, this file will show up (probably on vi/vim. check this cheatsheet if you don't know how to use it):

update changelog file

# Please enter the commit message for your changes. Lines starting

# with ‘#’ will be ignored, and an empty message aborts the commit.

#

# Author: John Doe <john@doe.com>

# Date: Thu Apr 21 22:40:30 2016 -0300

#

# On branch some_branch

# Your branch is up-to-date with ‘origin/some_branch’.

#

# Changes to be committed:

# modified: changelog.md

Here you can edit your commit message. Do as you wish and then save the file. If you don’t want to change the message, just save the file without changing it.

Now the changes you did on the last commit and after it will be in the same commit!

Amending a Commit Without Changing Its Message

If you don’t want to change your commit message, you can run the amend command with the no-edit flag, like this:

$ (some_branch) git commit --amend --no-edit

You’ll not be "redirected" a file to edit the commit message and that’s it!

Pushing an Amended Commit

If you haven’t pushed the last commit yet to your remote, a single push is enough. Otherwise, you’ll have to push using the -f option since you’ve rewritten your commit history:

$ (some_branch) git push -f origin some_branch

Be warned: pushing with -f is a very dangerous thing. Proceed with caution and always be sure that you’re pushing to the right branch.

Remember: NEVER rewrite the commit history of public branches (like master). This will truly mess your teammates work.

Bonus 1: Just Editing a Commit Message

To just edit a commit message (without adding new changes to your last commit), just run the amend command without adding changes. Simple as that!

Bonus 2: Editing a Commit Without Opening a File

Of course there would be a command for that! Just run:

$ (some_branch) git commit --amend -m "Your new commit message"

And there you go!

If you wanna learn how to use Git with teams, you should check this other post ;)

Happy gitting!

You probably know how to use Git on a daily basis. But knowing how to commit, push and pull isn't enough to really work with software development.

It doesn't matter if you use GitHub, Bitbucket, GitLab or Stash, one thing is true: you must follow a code review process to ensure your code has minimum quality standard.

This post will provide you a quick guide on how to use a “open source” workflow in your projects. As the name implies, it's the same workflow used on a whole bunch of open source projects out there.

Among the benefits of this workflow are the fact that your work is completely isolated from everyone else's and also the reduction of error going to production.

But hey: use what works best for your team. Some variations on this process are welcome as long as they improve your team's productivity.

Working on Branches

Git allows you to work on branches. According to the git documentation:

Branching means you diverge from the main line of development and continue to do work without messing with that main line.

In short, branches isolate the code you are currently working from the code your teammates are working. It's kinda a "parallel universe", or timeline.

To create a new branch, you just need to use the git checkout -b <branch_name> command:

$ (master) git checkout -b my_new_branch

> Switched to a new branch 'my_new_branch'

Once in a new branch, the workflow is the same. Create commits for your changes and push them to your repo (but not to master):

[...] some commits [...]

$ (my_new_branch) git push origin my_new_branch

The command above tells git: “hey dude, upload my local work (commits) on my_new_branch to the same branch on this remote (origin). If there is no my_new_branch there, create it”. If you want your work to be uploaded to a different branch on your remote (other than my_new_branch), just use the command like this:

$ (my_new_branch) git push origin my_new_branch:my_branch_on_remote

Ok, back on track. Now to move back to your master branch (or any other branch), you just need to use the git checkout command without the -b param:

$ (my_new_branch) git checkout master

> Switched to branch ‘master’

$ (master) git checkout my_new_branch

> Switched to branch ‘my_new_branch’

You can have more than one person working on the same branch as you, but that's not recommended. With one person per branch everyone can make their mess without worrying about disturbing someone else's work (like writing code that temporary breaks some part of the application, for example).

But someday you'll need to integrate your brand new feature back to your master right?

Code review

Instead of merging your branch back to master right away, a good practice of software development is to request your new code to be reviewed by other team members before.

This tends to increase the code quality of your app, since more people will take a look at it, spotting improvements and even small bugs before it reaches production.

For beginners, this is an awesome way to learn new stuff from more experienced developers.

But how to get people to review your code? Ask them to pull your branch and look into every commit by hand? No way!

Most (if not all of) Git online repository services have a nice feature that makes code review be very easy.

Pull Requests

A pull request (or a merge request, if you use GitLab) can be defined as:

Pull requests let you tell others about changes you’ve pushed to a repository on GitHub. Once a pull request is sent, interested parties can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary.

source: GitHub help: Using pull requests

It's basically a way to allow your teammates to review the code of your branch on the web interface of your repo. It allows them to make comments about the code that is about to be merged to the master.

You can learn how to create and mantain a pull request here (the same link I mentioned above). Each other service follows the same pattern, so there's no mystery involved.

Even after opening a pull request, you're still able to push new commits to your branch. You can use that to get early reviews of your code and keep working on some other part while people review what you've already uploaded.

And hey: remember to review your own pull request before asking for reviews of your teammates. You'll spot a lot of small things you didn't notice (style issues, typos, etc) and will allow your colleagues to focus on what really matters.

But again, your code isn't on the master branch yet, right? Hold on, we're almost there!

Refactoring/ Fixing Stuff

If your teammates asks for reasonable changes in your code, you'll have to do it (for the sake of code quality). Let's take a look on a scenario that happens very often: adding new changes to a past commit.

So, this is your file_a.example (yeah, the typo is on purpose):

[...]

some_cool_function

some_coler_function

[...]

And this is your commit history (older commits on top):

f7f3f6d create file_a class and methods
310154e improve SomeOtherClass code
a5f4a0d update changelog

Someone points out that your some_coler_function has a typo on its name and now you have to fix it.

You update the file and commit the fix. And now here's your new commit history:

f7f3f6d create file_a class and methods
310154e improve SomeOtherClass code
a5f4a0d update changelog
a412dbb fix typo on file_a

But hey, you're fixing something that you just added on this pull-request (on the first commit, to be exact)… It would be nicer to have both the creation and the fix of file_a on only one commit, right?

Git is such a wonderful tool and has this killer command that allows us to change previously stablished commits: git interactive rebase.

So we need to merge the first commit (f7f3f6d with the last one a412dbb). And that's when the interactive rebase tools comes in hand.

$ (some_branch) git rebase -i origin/master

The origin/master param is our start point. This basically is telling git: "hey, we want to change the history since the last commit origin/master", otherwise known as… your branch!

You can also use HEAD~4 as a param, which works like: “hey, we want to change the history since 4 commits behind the current one”. The official docs has more details on this.

After executing the command, this will be your screen:

pick f7f3f6d create file_a class and methods
pick 310154e improve SomeOtherClass code
pick a5f4a0d update changelog
pick a412dbb fix typo on file_a

# Rebase 710f0f8..a412dbb onto 710f0f8
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

Now we just need to follow the instructions written there! We want to combine commits f7f3f6d and a412dbb. So we must reorder the lines to be like this:

pick f7f3f6d create file_a class and methods
pick a412dbb fix typo on file_a
pick 310154e improve SomeOtherClass code
pick a5f4a0d update changelog

And we change the pick label on the a412dbb commit to a fixup (or f), to tell git: "hey, we want to combine this guy with the one above it":

pick f7f3f6d create file_a class and methods
fixup a412dbb fix typo on file_a
pick 310154e improve SomeOtherClass code
pick a5f4a0d update changelog

Save your file and bang! Here's your new commit history:

b7c3f33 create file_a class and methods
1b24ae9 improve SomeOtherClass code
d5ffad3 updates changelog

(yeah, the hash of all commits changed due the rewrite of the history).

If you already pushed your branch to remote, remember to use -f next time you push, since you've rewritten your commit history:

$ (some_branch) git push -f origin some_branch

Be warned: pushing with -f is a very dangerous thing. Proceed with caution and always be sure that you're pushing to the right branch.

And there you go!

Stuff like splitting a commit into different ones and some other crazy ways to change your history are described in the official git documentation.

Remember: NEVER rewrite the commit history of public branches (like master). This will truly mess your teammates work.

Finally, it's time to…

Integrating your code

Teams usually establish a minimum amount of reviews to get a pull request merged. Once you get the enough numbers of eyes on your code, designate someone to merge it! You can also merge yourself, but that's not the usual on most teams.

And that's it! Your code is now on your master branch, ready to ship to production.

Now you know how to use the workflow followed by thousands of teams of software development around the world!

With this workflow, you prevent people from stepping on each others toes while working and ensure that the code that goes to production has been approved by a minimum number of developers.

If you are in a team that doesn't follow this pattern, propose this change to them. The benefits are crystal clear and the effort to achieve that is close to zero.

Happy gitting!