Monthly Notes 41

Issue 41, 31.5.2019

Software development

Gitmoji
If not considering the issue on Bamboo with this (thread), Using Emojis in Git commit messages is a nice idea. There’s even cool emoji guide for your commit messages. Going to take this into use 😊 (from walokra)

Happy Friday, Don’t push to production?
Good thread of how you should treat your deploys to production. You should deploy often and have good CI/CD practices but the overall question isn’t black or white. “Nothing goes wrong until it does, and then you’d want your people available.”  “If you’re scared of pushing to production on Fridays, I recommend reassigning all your developer cycles off of feature development and onto your CI/CD process and observability tooling for as long as it takes to ✨fix that✨.” (from walokra)

Sleep quality and stress level matter and after 24 hours awake
“Your sleep quality and stress level matter far, far more than the languages you use or the practices you follow. Nothing else comes close”. Good notes of why sleeping and rest matters (thread) 😴 There’s always more work to do, take care of yourself first! (from walokra)

Software architecture

Why software architects fail – and what to do about it
Looks at some of the most common pitfalls that ensure you’ll come up with a disaster, and discusses how they can be avoided.

Cloud

High” levels of ☁️ spending at Lyft
Continuation on the Internet-discussion whether Lyft’s spending on AWS is too high and they could do better on-premises.

Frontend

TSLint in 2019
“Once we consider ESLint feature-complete w.r.t. TSLint, we will deprecate TSLint and help users migrate to ESLint”

User Experience

Printable A3 posters for Laws of UX
(from JonYablonski)

Something different

“Work starts from problems and learning starts from questions. Work is creating value and learning is creating knowledge. Both work and learning require the same things: interaction and engagement.” (from EskoKilpi)

Best Practices for Version Control in 8 steps

Using version control is an essential part of modern software development and using it efficiently should be part of every developer’s tool kit. Knowing the basic rules makes it even more useful. Here are some best practices that help you on your way.

tl; dr;

  1. Commit logical changesets (atomic commits)
  2. Commit Early, Commit Often
  3. Write Reasonable Commit Messages
  4. Don’t Commit Generated Sources
  5. Don’t Commit Half-Done Work
  6. Test Before You Commit
  7. Use Branches
  8. Agree on a Workflow
Simplified Git Flow
Simplified Git Flow (source: buildazure)

Commit logical changesets (atomic commits)

A commit should be a wrapper for related changes. Make sure your change reflects a single purpose: the fixing of a specific bug, the addition of a new feature, or some particular task. Small commits make it easier for other developers to understand the changes and roll them back if something went wrong.

Your commit will create a new revision number which can forever be used as a “name” for the change. You can mention this revision number in bug databases, or use it as an argument to merge should you want to undo the change or port it to another branch. Git makes it easy to create very granular commits.

So if you do many changes to multiple logical components at the same time, commit them in separate parts. That way it’s easier to follow changes and their history. So working with features A, B and C and fixing bugs 1, 2 and 3 should make at least 6 commits.

Commit Early , Commit Often

It is recommended to commit code to version control often which keeps your commits small and, again, helps you commit only related changes. It also allows you to share your code more frequently with others.

It’s easier for everyone to integrate changes regularly and avoid having merge conflicts. Having few large commits and sharing them rarely, in contrast, makes it hard to solve conflicts.

“If the code isn’t checked into source control, it doesn’t exist.”

Coding Horror

Write Reasonable Commit Messages

Always write some reasonable comment on your commit. It should be short and descriptive and tell what was changed and why.

Begin your message with a short summary of your changes (up to 50 characters as a guideline). Separate it from the following body by including a blank line.

It is also useful to add some prefix to your message like Fix or Add, depending on what kind of changes you did. Use the imperative, present tense (“change”, not “changed” or “changes”) to be consistent with generated messages from commands like git merge.

If fixing some bug or making some feature and it has a JIRA ticket, add the ticket identifier as a prefix.

For example: “Fix a few bugs in the interface. Added an ID field. Removed a couple unnecessary functions. Refactored the context check.” or “Fix bad allocations in image processing routines”.

Not like this: “Fixed some bugs.”

The body of your message should provide detailed answers to the following questions: What was the motivation for the change? How does it differ from the previous implementation?

“If the changes you made are not important enough to comment on, they probably are not worth committing either.”

loop label

Don’t Commit Generated Sources

Don’t commit files which are generated dynamically or which are user dependent. Like target folder or IDEA’s .iml files or Eclipse’s .settings and .project files. They change depending what the user likes and don’t relate to project’s code.

Also project’s binary files and Javadocs are files that don’t belong to version control.

Don’t Commit Half-Done Work

You should only commit code when it’s completed. Split the feature’s implementation into logical chunks and remember to commit early and often. Use branches or consider using Git’s Stash feature if you need a clean working copy (to check out a branch, pull in changes, etc.).

On the other hand you should never leave the office without commiting your changes.

“It’s better to have a broken build in your working repository than a working build on your broken hard drive.”

loop label

Test Before You Commit

You should only commit code which is tested and passes tests. And this includes code formatting with linters. Write tests and run tests to make sure the feature or bug fix really is completed and has no side effects (as far as one can tell).

Having your code tested is even more important when it comes to pushing / sharing your code with others.

Use Branches

Branching is one of Git’s most powerful features – and this is not by accident: quick and easy branching was a central requirement from day one. Branches are the perfect tool to help you avoid mixing up different lines of development.

You should use branches extensively in your development workflows: for new features, bug fixes and ideas.

Agree on a Workflow

Git lets you pick from a lot of different workflows: long-running branches, topic branches, merge or rebase, git-flow.

Which one you choose depends on a couple of factors: your project, your overall development and deployment workflows and (maybe most importantly) on your and your teammates’ personal preferences. However you choose to work, just make sure to agree on a common workflow that everyone follows.

Atlassian has done good article of comparing workflows to suit your needs and covers centralized, feature Branch, gitflow and forking workflows.

Summary

Using version control is usually and fortunately an acknowledged best practice and part of software development. By using even couple of the above practices makes working with the code much more pleasant. Adopting at least “Commit logical changesets” and “Reasonable Commit Messages” helps a lot.

Restore single table from full MySQL database dump

Playing with data in databases is sometimes tricky but when you get down to it it’s just couple of lines on the command line. Sometime ago we switched from Piwik PRO to Matomo and of course we wanted to migrate logs. We couldn’t just use the full MySQL / MariaDB database dump and go with it as table names and the schema was different (Piwik PRO 3.1.1. -> Matomo 3.5.1). In short we needed to export couple of tables and rename them to match new instance similarly as discussed in Stack Overflow.

There’s a VisitExport plugin for Piwik/Matomo which lets you export and import log tables with PHP and JSON files but it didn’t seem usable approach for our use case with tables being 500 MB or so.

The more practical solution was to simply create a dump of the tables we wished to restore separately.

1. Dump specific table of the database

mysqldump -u 'user' -p'password' database mytable > mytable.sql

And as I was playing with Docker

docker exec mariadb-container bash -c 'mysqldump -uroot -p$MYSQL_ROOT_PASSWORD database mytable' > ./database_dump_mytable_`date +%F`.sql

2. Change the table name before importing

sed -e 's/`mytable`/`mytable_restored`/g' mytable.sql > mytable_restored.sql

3. Import the new table

mysql -u [user] -p'password' database < mytable_restored.sql

And with Docker

docker exec mariadb-container mysql -uroot -p'password' database < ./database_dump_mytable_`date +%F`.sql

Or you can dump the whole database and use sed to extract the tables having a prefix or a suffix

1. Dump the database

mysqldump -u 'user' -p'password' database > dump.sql

2. Extract table

sed -n -e '/DROP TABLE.*`mytable`/,/UNLOCK TABLES/p' dump.sql > mytable.sql

3. Change the table name before importing

sed -n -e 's/`mytable`/`mytable_restored`/g' mytable.sql > mytable_restored.sql

3. Import the new table

mysql -u [user] -p'password' database < mytable_restored.sql

And with good luck you have now exported single table from full MySQL / MariaDB database dump.