Monthly notes 39

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

Software development

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.”

Code quality

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?

Syntax podcast talked about code quality tooling and tidying up code.
Hasty treat – Tidying up code
Hasty treat – Code quality tooling
Hasty treat – Code quality tooling part 2

Security

OWASP AppSec California 2019 presentation videos
46 videos of knowledge and experiences about secure systems and secure development methodologies.

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.

Learning

30 seconds of interviews
Quick questions of web development.

AI and Machine Learning

AI Thinks Rachel Maddow Is A Man (and this is a problem for all of us)
A data-driven review of AI bias in production systems.

Something different

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.


Best Practices of forking git repository and continuing development

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 “1.0.0@your-org.0.1” 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.

This post was originally published on Gofore Group blog at 11.2.2019.