Before committing code to the Subversion repository we always set the svn:ignore property on the directory to prevent some files and directories to be checked in. You would usually want to exclude the IDE project files and the target/ directory.
It's useful to put all the ignored files and directories into a file: .svnignore. Your .svnignore could look like:
Put the .svnignore file in the project folder and commit it to your repository so the ignored files are shared between committers.
Now reference the file with the -F option: $ svn propset svn:ignore -F .svnignore.
Of course I hope everyone has by now moved to git and uses .gitignore for this same purpose.
Midsummer is couple of days away and it's time to take a short break from work and enjoy the Summer nights and nature. And if you have time here is a short list of articles to read and videos from React Finland 2019 conference to watch.
Issue 42, 20.6.2019
Consulting or con-$ulting A theory on how Hertz’s inexperience in buying software — combined with Accenture’s incompetence to deliver it — flushed $32M+ down the drain. "The lack of transparency and technical expertise combined with the lack of ownership/responsibility was ultimately the reason why Hertz managed to blow tens of millions USD, instead of just a couple." Lessons learned: "If you are buying software for tens of millions, you must have an in-house technical expert as part of the software development process".
Be careful with CTE in PostgreSQL PostgreSQL doesn't inline common table expressions, WITH clause, it materializes it and thus is unable to utilize the index => expensive. Good to know if you're used to Oracle which doesn't materialize CTEs by default. (from walokra)
Can't Unsee "The devil is in the details". A game where your attention to details earns you a lot of coins. Fun game which teaches you some UX rules and attention to details. With 5780 coins I'm a beginner :/ (or need glasses :))
It feels fine on my phone "You literally can't afford desktop or iphone levels of JS if you're trying to make good web experiences for anyone but the world's richest users, and that likely means re-evaluating your toolchain."
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)
"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)
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.
Commit logical changesets (atomic commits)
Commit Early, Commit Often
Write Reasonable Commit Messages
Don't Commit Generated Sources
Don't Commit Half-Done Work
Test Before You Commit
Agree on a Workflow
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."
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."
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."
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.
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.
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.
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.
Refactoring, computer science concepts on day job, doing better code reviews, battling CSS and watching cat videos. That's Monthly notes for April. Not much so enjoy slowly :)
Issue 40, 4.2019
Refactoring.Guru Refactoring.Guru makes it easy for you to discover everything you need to know about refactoring, design patterns, SOLID principles and other smart programming topics.
CompSci and My Day Job Rob Conery talked at NDC Conference London 2019 about computer science concepts he used on his day job without actually knowing them. All of this changed as he put together the first two volumes of The Imposter's Handbook. He talks what he has learned and applied to the applications created on his day job. And gives you more tools under your belt to help you do your job better.
Code Review: How can we do it better? Fun Fun Function talks about how to become a better code reviewer and reviews some listeners sent code. General rules for pull requests: make everything readable by humans, title, description, commit comments and most important - your code. DRY KISS
"However, none of the [Formula One] teams used any of the big modern frameworks. They’re mostly WordPress & Drupal, with a lot of jQuery. It makes me feel like I’ve been in a bubble in terms of the technologies that make up the bulk of the web."
When we’re evaluating technologies for appropriateness, I hope that we will do so through the lens of what’s best for users, not what we feel compelled to use based on a gnawing sense of irrelevancy driven by the perceived popularity of newer technologies.
Code quality in software development projects is important and a good metric to follow. Code coverage, technical debt, vulnerabilities in dependencies and conforming to code style rules are couple of things you should follow. There are some de facto tools you can use to visualize things and one of them is SonarQube. Here's a short technical note of how to setup it on Kotlin project and visualize metrics from different tools.
Including what analysis SonarQube's default plugins provide we are also using Detekt for static source code analysis and OWASP Dependency-Check to detect publicly disclosed vulnerabilities contained within project dependencies.
Visualizing Kotlin project metrics on SonarQube
SonarQube is nice graphical tool to visualize different metrics of your project. Lately it has started to support also Kotlin with SonarKotlin plugin and sonar-kotlin plugin. From typical Java project you need some extra settings to get things working. It's also good to notice that the support for Kotlin isn't quite yet there and sonar-kotlin provides better information i.e. what comes to code coverage
Steps to integrate reporting to Sonar with maven build:
Add configuration in project pom.xml: Surefire, Failsafe, jaCoCo, Detekt, Dependency-Check
Run Sonar in Docker
Maven build with sonar:sonar option
Check Sonar dashboard
Configure Kotlin project
Configure your Kotlin project built with Maven to have test reporting and static analysis. We are using Surefire to run unit tests, Failsafe for integration tests and JaCoCo generates reports for e.g. SonarQube. See the full pom.xml from example project (coming soon).
Detekt static code analysis configuration as AntRun. There's also unofficial Maven plugin for Detekt. It's good to notice that there are some "false positive" findings on Detekt and you can either customize detekt rules or suppress findings if they are intentional such as @Suppress("MagicNumber").
Use the Kotlin plugin which comes with SonarQube (SonarKotlin) or install the sonar-kotlin plugin which shows information differently. If you want to use sonar-kotlin and are using the official Docker image for SonarQube then you've to first remove the SonarKotlin plugin.
You now have metrics on Sonar to show to stakeholders but what should you do with those numbers?
One use case is to set quality gates on SonarQube to check that a set of conditions must be met before project can be released into production. Ensuring code quality of "new" code while fixing existing ones is one good way to maintain a good codebase over time. The Quality Gate facilitates setting up rules for validating every new code added to the codebase on subsequent analysis. By default the rules are: coverage on new code < 80%; percentage of duplicated lines on new code > 3; maintainability, reliability or security rating is worse than A.
Spring is just around the corner with sun warming our souls and calling us to go outside. Here’s monthly notes for March with topics from software development rewrite stories to code quality and OWASP videos.
Issue 39, 22.03.2019
Lessons from 6 software rewrite stories Insightful rewrite stories of i.a. Netscape (Firefox), Basecamp, Visual Studio (VS Code) and FogBugz (Trello). "Functioning app should never, ever be rewritten from the ground up" is true. With a twist. Don't rebuild the exact product. Don't sunset. (from @walokra)
I ruin developers’ lives with my code reviews and I'm sorry Story of how a developer understood that "I don’t do code review for the business, I just like showing the rookies their place. My skills have finally started to pay off." And that the mentality should be "No big deal if the code’s not good, I can fix it myself it I need to. But I can’t fix the psyche of a guy broken by dozens of harsh reviews."
SE-Radio Episode 357: Adam Barr on Code Quality Software Engineerin Radio talked with Adam Barr, author of "Why Smart Engineers Write Bad Code" about code quality. How developers learn to program on their own; how that influences their thinking about code quality; what code quality is, how is can (or cannot) be measured and whether some programming languages are more prone to bad code. The discussion continues with a discussion on standardization. Why does our profession lack a professional certificate like doctors and engineers have?
The Anatomy of an AWS Key Leak to a Public Code Repository Many of us working with any cloud provider know that you should never ever commit access keys to a public github repo. Some really bad things can happen if you do. The writeup shows you a real case that happened last week. tl;dr; Exposed keys are quickly attacked. The concept of least privilege is important. AWS scrapes the API of all public github commits but doesn't automatically disable the key. To prevent keys leaking use tools like git-secrets or GitGuardian.
Password Managers: Under the Hood of Secrets Management Password managers allow the storage and retrieval of sensitive information from an encrypted database. The paper proposes security guarantees password managers should offer and examines the underlying workings of five popular password managers targeting the Windows 10 platform: 1Password 7, 1Password 4, Dashlane, KeePass, and LastPass. They found that in all password managers we examined, trivial secrets extraction was possible from a locked password manager, including the master password in some cases.
The Privateer is back for Season 2 Behind every top level athlete is a support team that helps them with everything from diet and exercise to product and equipment set up. When you're a Privateer it's up to you to fund your racing endeavours. Adam is back for another season of racing as The Privateer.
Sometimes there's a need to fork a git repository and continue development with your own additions. It's recommended to make pull request to upstream so that everyone could benefit of your changes but in some situations it's not possible or feasible. When continuing development in forked repo there's some questions which come to mind when starting. Here's some questions and answers I found useful when we forked a repository in Github and continued to develop it with our specific changes.
Repository name: new or fork?
If you're releasing your own package (to e.g. npm or mvn) from the forked repository with your additions then it's logical to also rename the repository to that package name.
If it's a npm package and you're using scoped packages then you could also keep the original repository name.
Keeping master and continuing developing on branch?
Using master is the sane thing to do. You can always sync your fork with an upstream repository. See: syncing a fork.
Generally you want to keep your local master branch as a close mirror of the upstream master and execute any work in feature branches (that might become pull requests later).
How you should do versioning?
Suppose that the original repository (origin) is still in active development and does new releases. How should you do versioning in your forked repository as you probably want to bring the changes done in the origin to your fork? And still maintain semantic versioning.
In short, semver doesn't support prepending or appending strings to version. So adding your tag to the version number from the origin which your version is following breaks the versioning. So, you can't use something like "firstname.lastname@example.org" or "1.0.0-your-org.1". This has been discussed i.a. semver #287. The suggestion was to use a build meta tag to encode the other version as shown in semver spec item-10. But the downside is that "Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence."
If you want to keep relation the original package version and follow semver then your options are short. The only option is to use build meta tag: e.g. "1.0.0+your-org.1".
It seems that when following semantic versioning your only option is to differ from origin version and continue as you go.
If you don't need to or want to follow semver you can track upstream version and mark your changes using similar markings as semver pre-releases: e.g. "1.0.0-your-org.1".
npm package: scoped or unscoped?
Using scoped packages is a good way to signal official packages for organizations. Example of using scoped packages can be seen from Storybook.
It's more of a preference and naming conventions of your packages. If you're using something like your-org-awesome-times-ahead-package and your-org-patch-the-world-package then using scoped packages seems redundant.
Who should be the author?
At least add yourself to contributors in package.json.
Forking only for patching npm library?
Don't fork, use patch-package which lets app authors instantly make and keep fixes to npm dependencies. Patches created by patch-package are automatically and gracefully applied when you use npm(>=5) or yarn. Now you don't need to wait around for pull requests to be merged and published. No more forking repos just to fix that one tiny thing preventing your app from working.
Warm weather and cold Northern winds just call for a warm mug of cacao and something to read by the fireplace. Here's monthly notes for February with topics from testing to software development project guidelines and from microservices to tips and tools. Also learning React App.
Issue 38, 19.02.2019
How to stop hating your tests I'm not a fan of extensive ui tests. I think they should be mostly about seeing that the whole system functions when all systems are integrated and functional. This talk makes a good case out of it. If you want to skip right to this subject, it starts around at 18:50 or so.
My Opinionated Setup for Web Projects "During the past few years, I have worked on multiple smaller and larger projects. In this blog post I explain my default project setup for a typical web frontend project."
Building Microservices: Designing fine-grained systems (pdf) "Distributed systems have become more fine-grained in the past 10 years, shifting from code-heavy monolithic applications to smaller, self-contained microservices. But developing these systems brings its own set of headaches. With lots of examples and practical advice, this book takes a holistic view of the topics that system architects and administrators must consider when building, managing, and evolving microservice architectures."
Microservices vs The World "In the last 5 years microservices have been pretty much the topic on every architectural conversation. The idea is great, small, independent, cohesive, services that can be implemented, tested, maintained and released individually without much impact on the rest of the system. Microservices are then the holy grail of architectures all positives and almost zero negatives. If that is the case, why in the last 2-3 years our holy grail is getting bad press? Some engineers even suggest that a monolith is better. How can a monolith be better? Well, it all comes down to pros and cons and how the business is structured."
Microservices architecture on paper sounds amazing but unless the business as a whole is not committed to it, then your department will end up with low morale, low productivity, and tones of code debt.
DockStation "Application for managing projects based on Docker. Instead of lots of CLI commands you can monitor, configure, and manage services and containers while using just a GUI." See running containers in histogram-type grapsh, monitor stats, connect with ssh to remote hosts, start/stop containers.
Scrolling inside Screen Disable the alternate text buffer in the xterm termcap info inside screen so that you can use the scroll bars (and mouse wheel) to scroll up and down.
~/.screenrc. # Enable mouse scrolling and scroll bar history scrolling termcapinfo xterm* ti@:te@
Learn React App The goal of this tutorial is to quickly get you off the ground with React concepts. This tutorial has hands-on exercises which I consider to be the most important part of this tutorial.