Hey! Welcome to another edition of This Week in #dev, a series of posts where we bring some of the most interesting Slack conversations to the public. Today we’ll talk about randomness, shell commands, flaky tests, and TypeScript. Stick around!
Running shell commands in Ruby
You can return standard output from system commands executed in Ruby by wrapping them in backticks, as shown by Steve Polito:
# Calling system will return true, false or nil.
system("pgrep ruby")
# 76532
# => true
# Using a backtick returns the standard output.
`pgrep ruby`
# => "76532\n"
Thiago Silva points out that you can use $? to check the exit status of the
last command:
`echo oops && exit 99` #=> "oops\n"
$?.exitstatus #=> 99
If you require the English library, you can use $CHILD_STATUS instead of
$?. It adds a few other aliases, if you’re interested.
`echo oops && exit 99` #=> "oops\n"
$CHILD_STATUS.success? #=> false
random.org
Matheus Richard learned about https://www.random.org, a “true number generator”. The randomness comes from atmospheric noise, which for many purposes, it’s claimed to be better than the pseudo-random number algorithms typically used in computer programs.
If pseudo-random is enough for you, Neil Carvalho brings up /dev/random and
/dev/urandom, that have entropy sources from some hardware events, among
others. Also, here’s our guide on randomization.
Do you have flaky system tests?
Richard Newman shares an article about how to deal with flaky system tests in
Rails. Tip: sleeping is not the answer.
Taking the most out of TypeScript
If you’re coming from a dynamically-typed language to TypeScript, Stephen Hanson has some tips for you:
It’s essential that you use an editor that has TypeScript tooling (i.e. that runs a TypeScript language server). You should be able to see TypeScript errors inline, hover over variables to see what type they are, and get auto-completion as you access properties on objects. If your editor does not have this tooling, then TypeScript is serving little value for you, and it will be a frustrating experience identifying errors only when you manually compile the code. VS Code has all this built-in by default.
To understand why the page loads fine but TypeScript errors, it helps to see how TypeScript works. TypeScript types are there to help the development experience. When your code is compiled, the types are completely stripped away, and the result is regular JavaScript. The types are not present at all at run-time. Changing a type will not break or fix your app. The TypeScript errors you get are there for the developer but don’t affect the end result.
He also indicates a caveat for point two: “I think some apps are set up so that compiling to JavaScript fails if there are type errors, but that is not the norm.”
Matheus Richard adds that you can make the compiler stricter to catch more potential errors.
Thanks
This edition was brought to you by Matheus Richard, Neil Carvalho, Richard Newman, Stephen Hanson, Steve Polito, and Thiago Silva. Thanks to all contributors! 🎉
