In these two books, the authors of four dozen open source applications explain how their software is structured, and why. What are each program's major components? How do they interact? And what did their builders learn during their development? In answering these questions, the contributors to these books provide unique insights into how they think.

If you are a junior developer, and want to learn how your more experienced colleagues think, these books are the place to start. If you are an intermediate or senior developer, and want to see how your peers have solved hard design problems, these books can help you too.

Elixir receives two awards.
Its resiliency, functional-first approach, and amazing ecosystem makes it the Best Language for Building Web APIs.
OTP and the actor model make Elixir the Best Language for Building Concurrent and Distributed Software. Unlike its imperative cousin Go, software written in Elixir can scale horizontally to thousands of servers, and comes with fault tolerance out-of-the-box.

OpenType lets you replace characters based on context

I started out being extremely confused about what OpenType even is. I still don’t know much, but I learned that you can write extremely simple OpenType rules to change how a font looks, and you don’t even have to really understand anything about fonts.

Here’s an example rule:

sub a' b by other_a;
What sub a' b by other_a; means is: If an a glyph is before a b, then replace the a with the glyph other_a.

The best way to think about Go is to think about all the things that it doesn't have.

• Go doesn’t have a virtual machine or an LLVM-based compiler.
• Go doesn’t have exceptions.
• Go doesn’t have user-defined implementation inheritance.
• Go doesn’t have overloading for functions, methods, or operators.
• Go doesn’t have immutables.
• Go doesn’t have enumerations.
• Go doesn’t have generics.
• And Go hasn’t added any major features since Go 1 was released in 2012.

The one exciting thing that Go has is built-in concurrency support via goroutines, channels, and select. However, it is based on ideas from CSP, communicating sequential processes, which was first described in 1978.

I started preparing for Google interviews using HackerRank and its Interview Preparation Kit. I highly recommend it -- it's really close to what happened at the interview.

For starters, non-typists are almost invisible. They don't leave a footprint in our online community.

When you talk to them 1-on-1, sure, they seem smart. They usually are smart. But non-typists only ever contribute a sentence or two to any online design discussion, or style-guide thread, or outright flamewar, so their online presence is limited.

If you are a programmer, or an IT professional working with computers in any capacity, you need to learn to type! I don't know how to put it any more clearly than that. If you refuse to take the time, then you're... you're... an adjective interjection adjective noun, exclamation.

Also https://repl.it/

The underlying concept of design patterns has been around in the software engineering industry since the very beginning, but they weren’t really so formalised. Design Patterns: Elements Of Reusable Object-Oriented Software written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides — the famous Gang of Four (GoF)—was instrumental in pushing the formalised concept of design patterns in software engineering. Now, design patterns are an essential part of software development and have been so for a long time.

How to develop a Makefile

They key to successfully writing a Makefile is to just write down the commands you need at the moment. Ran a new command? Put it in the Makefile. Over time, the Makefile will grow to include even those rare commands you rarely run and can’t remember what they were. Patters with emerge, and these will help guide the prerequisites that may otherwise not be obvious.

I post multiple choice JavaScript questions on my Instagram stories, which I'll also post here! Last updated: December 24th

From basic to advanced: test how well you know JavaScript, refresh your knowledge a bit, or prepare for your coding interview! muscle rocket I update this repo regularly with new questions. I added the answers in the collapsed sections below the questions, simply click on them to expand it. It's just for fun, good luck! heart

Problem: Concise description of problem behavior

Steps to reproduce problem:

1. First step
2. Second step
3. Third and subsequent steps, as necessary

Desired or expected behavior:

• What I wanted to happen

Observed behavior:

• What actually happened, including the full details of any error messages

Perl -> Python 2

The 10:1 rule of writing and programming

Good software and good writing requires that every line has been rewritten, on average, at least 10 times.

First, it looks like similar 10:1 rules show up in film, journalism, music, and photography! How cool is that?

What is TDD?
TDD stands for Test Driven Development. The process is simple:

1. Before you write implementation code, write some code that proves that the implementation works or fails. Watch the test fail before moving to the next step (this is how we know that a passing test is not a false positive — how we test our tests).
2. Write the implementation code and watch the test pass.
3. Refactor if needed. You should feel confident refactoring your code now that you have a test to tell you if you’ve broken something.

For the past 12 years, I have been on both sides of the Front End Interview table. Sadly though, the emphasis is always put on Javascript during those rounds and the two other important languages - HTML and CSS - are not usually given the same weight.

The 5 principles of REST
Contract first approach / Uniform Resource identifiers
Statelessness
Client-Server model
Caching
Layered architecture

Recently at work I had to speed up a Perl script that processed files. Perl can spawn multiple processes with the fork function, but things can go awry unless you manage the subprocesses correctly. I adding forking to the script and was able to improve the script’s throughput rate nearly 10x, but it took me a few attempts to get it right. In this article I’m going to show you how to use fork safely and avoid some common mistakes.

Option 3: preserve local time, using UTC as derived data to be recomputed

Spoiler alert: this is my preferred option.

In this approach, the information that the conference organizer supplied (“9am on July 10th 2022”) is preserved and never changed. There is additional information in the entry that is changed when the time zone database is updated: the converted UTC instant. We can also preserve the version of the time zone rules used for that computation, as a way of allowing the process of updating entries to be restarted after a failure without starting from scratch, but it’s not strictly required. (It’s also probably useful as diagnostic information, too.)

The UTC instant is only stored at all for convenience. Having a UTC representation makes it easier to provide total orderings of when things happen, and also to compute the time between “right now” and the given instant, for the countdown timer.

But there is a good standard UNIX tool. By standard I mean it actually has robust documentation, that many forgot. Or never learned? I’m talking about make. More accurately, this article focuses on GNU make. It’s available on macOS, Windows, Linux and most other operating systems.