nicklockwood

It's Impossible

I have reluctantly come to accept that it is impossible to create a "perfect" programming language. Every language is domain-specific in some sense, and many of the criteria that make a language good for one purpose are fundamentally in opposition to qualities that are good for another.

A classic example would be "scripting" languages versus "embedded" languages.

Good qualities in a scripting language are:

• Dynamic typing (no need to specify types, or cast between them)

abevoelker

{
    "Id": "Policy1234",
    "Statement": [
        {
            "Sid": "Stmt1234",
            "Action": [
                "s3:GetObject"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:s3:::foo/*",

staltz

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

---

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

---

subfuzion

There are certain files created by particular editors, IDEs, operating systems, etc., that do not belong in a repository. But adding system-specific files to the repo's .gitignore is considered a poor practice. This file should only exclude files and directories that are a part of the package that should not be versioned (such as the node_modules directory) as well as files that are generated (and regenerated) as artifacts of a build process.

All other files should be in your own global gitignore file:

• Create a file called .gitignore in your home directory and add any filepath patterns you want to ignore.
• Tell git where your global gitignore file is.

Note: The specific name and path you choose aren't important as long as you configure git to find it, as shown below. You could substitute .config/git/ignore for .gitignore in your home directory, if you prefer.

steipete

# The trick is to link the DeviceSupport folder from the beta to the stable version.
# sudo needed if you run the Mac App Store version. Always download the dmg instead... you'll thank me later :)

# Support iOS 15 devices (Xcode 13.0) with Xcode 12.5:
sudo ln -s /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/15.0 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport

# Then restart Xcode and reconnect your devices. You will need to do that for every beta of future iOS versions

# (A similar approach works for older versions too, just change the version number after DeviceSupport)

ashfurrow

Apps to install from macOS App Store:

• Pastebot
• GIF Brewery
• Slack
• Keynote/Pages/Numbers
• 1Password
• OmniFocus 3
• Airmail 3
• iA Writer

alloy

First grep the heroku logs for the message that will state that the debugger service has started:

$ heroku logs -t --app=[APP_ID] | grep 'Debugger listening on'

Then in another shell enable the debugger service of the Node process by connecting through SSH and sending the process SIGUSR1:

$ heroku ps:exec --app=[APP_ID]

kelset

4 years as a React Native OSS maintainer: a retrospective

Why writing this, and why now? In January 2018 I started my journey as a maintainer of the React Native (RN) open source repo — it is the longest role I’ve ever kept going in my professional career, in a way — and I think now, at the 4 years mark, it is a very good time for me to pause, and force myself to think about how things have changed since then.

How did I become a maintainer? After a big burnout with react-navigation that led me to learn how to correctly interact with Open Source Software (OSS), I was starting to interact with OSS again by being a good citizen in the RN repository. Seeing me constantly in the issue section, trying to help out, led some Facebook (FB) engineers to decide to ask me to join the OSS repo with write access, so that I could be more proactive in helping its maintenance… and here we are.

Even so, I was never an em