See how a minor change to your commit message style can make you a better programmer.

Format: <type>(<scope>): <subject>

where <scope> is optional.

Example
feat: add hat wobble
^--^  ^------------^
|     |
|     +-> Summary in present tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.

More Examples:

• feat: new feature for the user, not a new feature for build script
• fix: bug fix for the user, not a fix to a build script
• docs: changes to the documentation
• style: formatting, missing semi colons, etc; no production code change
• refactor: refactoring production code, eg. renaming a variable
• test: adding missing tests, refactoring tests; no production code change
• chore: updating grunt tasks etc; no production code change

Adapted from http://www.possibility.com/Cpp/CppCodingStandard.html and NetBSD's style guidelines.

Researchers at the University of Tokyo were expecting to create a strong magnetic field, but they got a lot more than they were bargaining for.

Line-breaking algorithms take a paragraph's-worth of words, and split the words into line-lengthed chunks. The two algorithms many programmer's know of are:

• The greedy algorithm; and,
• The Knuth-Plass algorithm (the 'latex one').

Most programmers "know" the following three facts:

• Knuth-Plass produces the 'best' line breaks;
• Knuth-Plass is a quadratic algorithm; and,
• Knuth-Plass uses dynamic programming and is impossible for mere mortals to code.

While we happen to agree with (1), we will demonstrate that (2) and (3) are, respectively, not true, and unnecessarily obscure. In fact, the Knuth-Plass algorithm---even in its most naive implementation---is strongly dominated by a light-weight linear run-time, and the implementation of the core algorithm is remarkably straightforward.

Across the world, urban intersections are being slowly transformed from grim, car-oriented hazards to bright and pedestrian-friendly spaces, with help from the Bloomberg Philanthropies Initiative for Global Road Safety.

I had an email problem. My inbox was always full of emails. I was very slow in responding to personal emails. How slow? Ask my friends. It wasn't unusual for them to receive an email response from me over a year after they sent the email as I played catchup.

I get too much email. Most of us do. The situation was out of control, and had been that way for years. I remember the good old days in the 90's when, for the first few years of my email experience, almost all emails were personal, and a joy to engage in. I wanted that experience back. I wanted receiving someone's email to lighten up my day. I didn't want it to be surrounded by non-personal junk email.

I recently built a small agent-based model using Python and wanted to visualize the model in action. But as much as Python is an ideal tool for scientific computation (numpy, scipy, matplotlib), it's not as good for dynamic visualization (pygame?).

You know what's a very mature and flexible tool for drawing graphics? The DOM! For simple graphics you can use HTML and CSS; for more complicated stuff you can use Canvas, SVG, or WebGL

I’ve been programming for 15 years now. Recently our industry’s lack of care for efficiency, simplicity, and excellence started really getting to me, to the point of me getting depressed by my own career and the IT in general.

Modern cars work, let’s say for the sake of argument, at 98% of what’s physically possible with the current engine design. Modern buildings use just enough material to fulfill their function and stay safe under the given conditions. All planes converged to the optimal size/form/load and basically look the same.

Only in software, it’s fine if a program runs at 1% or even 0.01% of the possible performance. Everybody just seems to be ok with it. People are often even proud about how much inefficient it is, as in “why should we worry, computers are fast enough”...

Introduction Have you ever wondered how Netflix suggests movies to you based on the movies you have already watched? Or how does an e-commerce websites display options such as "Frequently Bought Together"? They may look relatively simple options but behind the scenes, a complex statistical algorithm executes in order to

At the North America edition of the 2018
Linux Security Summit (LSS NA), which was held in late August in Vancouver,
Canada, Kees Cook gave a presentation on some of the dangers that come with
programs written in C. In particular, of course, the Linux kernel is
mostly written in C, which means that the security of our systems rests on
a somewhat dangerous foundation. But there are things that can be done to
help firm things up by "Making C Less Dangerous" as the title
of his talk suggested.

Donkey Car trained with Double Deep Q Learning (DDQN) in Unity Simulator.

From the very start, we made very conscious engineering and product decisions to keep Discord well suited for voice chat while playing…

Choosing a programming language for a project is a compromise over what you what you need, what you have, what you know and what you like. This post is just my thought process when selecting the implementation language for packnback.

What we need

• High performance, we will hopefully be dealing with large volumes of data.
• High security, the whole purpose is to protect data from attackers.
• Stability, software needs to be usable well into the future.
• Simplicity, the less complicated something is, the less that can go wrong.
• Popularity, this is mainly to help with marketing, libraries and community support.
• High bus factor, will sudden unexpected events destroy the language prospects.
• Fun, something we enjoy using or evaluating.

Four small lessons for better development in any language

Let me preface this with an apology: this is a technology love story, and as such, it’s long, rambling, sentimental and personal. Also befitting a love story, it has a When Harry Met Sally feel to it, in that its origins are inauspicious…

A developer's guide about how to share code between Android and iOS with Kotlin Multiplatform.

To highlight uncertain norms in authorship, John P. A. Ioannidis, Richard Klavans and Kevin W. Boyack identified the most prolific scientists of recent years.

Isolation, anxiety, and depression in the remote workplace and what we’re doing about it