Discover and read the best of Twitter Threads about #electronjs
Most recents (2)
I'm about to buy a new MacBook Pro 13" with the famous Apple M1 SoC.
Let's see how ready it is for developers.
A thread ⤵️
Legend: 🔴 = not working, 🟢 = working
#AppleSiliconM1
Let's see how ready it is for developers.
A thread ⤵️
Legend: 🔴 = not working, 🟢 = working
#AppleSiliconM1
🟢 Rust is working!
`aarch64-apple-darwin` is part of the Tier 2 platforms, doc.rust-lang.org/nightly/rustc/….
See the PR, github.com/rust-lang/rust….
#AppleSiliconM1 #rustlang
`aarch64-apple-darwin` is part of the Tier 2 platforms, doc.rust-lang.org/nightly/rustc/….
See the PR, github.com/rust-lang/rust….
#AppleSiliconM1 #rustlang
In my #TDD trainings, I sometimes say that I do not test code that is "too simple to break"; Code where:
1. The chance of the code breaking is very low
2. *If* the code breaks, we would see immediately
What do I mean by that? A thread... 1/
1. The chance of the code breaking is very low
2. *If* the code breaks, we would see immediately
What do I mean by that? A thread... 1/
I wrote the following Typescript code running in #electronjs:
const { dialog, } = remote
const filePath = dialog.showSaveDialogSync({...})
if(filePath) {
fs.writeFileSync(...)
}
The code is very hard to test, but I'm OK with that, b/c it fulfills the above criteria. 2/
const { dialog, } = remote
const filePath = dialog.showSaveDialogSync({...})
if(filePath) {
fs.writeFileSync(...)
}
The code is very hard to test, but I'm OK with that, b/c it fulfills the above criteria. 2/
Before I go into why the code is "too simple to break"... Why is it hard to test?
Well, "dialog" (and even "remote") is not available during unit testing. And even if it was, it would open a dialog that I'd have to remote-control. Not cool in a test. 3/
Well, "dialog" (and even "remote") is not available during unit testing. And even if it was, it would open a dialog that I'd have to remote-control. Not cool in a test. 3/
