So, any recommendations for a sturdy iPhone case you’ve used?
I’m mostly concerned with not cracking the screen again, so bulkier options are fine. Ideally, I wouldn’t have to worry about breaking another phone like this again.
So, any recommendations for a sturdy iPhone case you’ve used?
I’m mostly concerned with not cracking the screen again, so bulkier options are fine. Ideally, I wouldn’t have to worry about breaking another phone like this again.
Broke another phone.
Captain’s log, 02/06/19, 17:05 up 19 days
It’s been eight days since the symbol selector gave out. Communication degraded. Haven’t found another way to fix it yet. The rest of the machine seems stable enough not to have to reboot, so I’ll be stuck like this for a while longer.
Gah, kids and their $
’s and \s
’s! But you’re right, that’s obviously the better option! 🏌️
Are you just getting started with Vim-substitution-based editing? Don’t worry; the book has your back! This absolute classic is the first substitution I always reach for first. Never remove trailing whitespace manually again!
:%s/ \+\n/\r/
Shoutout to @hexpm’s instructions to revert a release in the notification e-mail you receive after publishing a new package version, for making me immediately realize I published from the wrong branch. Thanks, @sprsmpl!
The Emoji & Symbols selector stopped opening a couple of days ago (both ^+⌘+Space and via Edit › Emoji & Symbols). Relaunching the Finder didn’t work, and I’m refusing to reboot my machine unless something else breaks.
Yes, it does make a lot of sense. I know how to push to a differently named branch, but it takes me a while to connect the dots, specifically when pushing to Heroku. 🤷
Deploying a branch that’s not called master
to Heroku (or pushing to a different branch name on remote in general)? Remembering to prefix the remote’s branch name with the local one might save you some confusion.
$ git push heroku my_branch:master
Where heroku
is the remote, my_branch
is the local branch name, and master
is the remote branch name. Hopefully, I’ll get it right on the first try too, one day.
Yes, and it’s great! But do you do anything on your end to prevent e-mail clients from clicking links to preview, and accidentally unsubscribing from the list? I’ve never heard of that happening, so I’m curious if you actively prevent it.
https://twitter.com/
I thought it was so if your email client preview opens links it won't accidentally unsubscribe you? Confirmation click is okay IMHO, but typing in email is bad, logging in is bad etc. Just unsubscribe me darnit!
— Josh Taylor (@joshtaylor) June 26, 2019
Hadn’t thought of that one. Just checked, and Mailchimp immediately unsubscribes without asking for confirmation.
do you use any tricks to prevent e-mail clients from automatically clicking your unsubscribe buttons, or isn’t that required? :)
This. Also, don’t require logging in (you can figure out the e-mail address), and don’t ask which types of marketing e-mails they’d like to unsubscribe from. Unless, of course, if your app sends notifications the user actually signed up for.
https://twitter.com/
Hi internet companies! 👋 It's pretty simple: no one clicks on those barely visible 'Unsubscribe from these emails' buttons accidentally. So there's absolutely no need for a confirmation screen. Either it's a one click experience or I will report you as spam 🛑🛑🛑
— Antek Piéchnik (@antekpiechnik) June 26, 2019
It’s time for three-piece-instrumental-rock-bands weekly! This week, @adamyeats suggests Covet’s 2018 album; effloresce. 🎸
https://twitter.com/adamyeats/status/1141722949457719296
Our air conditioning unit is overheated. 🌡️🔥
The more I discuss my Go board LiveView article series with others, the more I feel like I’m actually accidentally writing a book.
$ git log master..part-2 --reverse --pretty=format:%b | wc
291 1465 9982
The almost-finished outline for part two is now close 1500 words in git commit messages. 😅
Mornin’! 🍹
“🌞 Sun With Face. A yellow sun with a kind, smiling face. Not your typical smiling sun with big grin and sunglasses.” #notyourtypicalsun
DM-ed!
Of course! See you tomorrow! 👋
“rand()
is your friend.” #euruko2019
“If Ruby dies, my family will die.” #euruko2019
Obligatory “I’m on a boat” update. 🚢 #euruko2019
Assuming a technical article, split up the work between building a prototype that illustrates your point and gathering the facts, and writing the story.
Keeping those steps separate keeps me from editing the first part before I’m sure where I’m heading. Related: https://twitter.com/jkreeftmeijer/status/1141768367029796864
My current article series is based around writing an example application. As an experiment, I’m writing most of the draft in ~250-word commit messages in the example repository.
To get a very rough outline for the first article, I printed the commit message bodies to a markdown file in reverse.
$ git log --reverse --pretty=format:%b > draft.md
The outline was a good starting point to write the story. It felt more efficient, as the work was split between prototyping and explaining code, and writing and editing an article. Plus, the example repository now has well-groomed commits and good explanations of all changes. 🙌