自分向けにローカルにあるJSをhttps経由で配布したいが、自分であれこれ設定するのはだるい。ngrokというのがあるらしいので使ったらすぐできた。
ngrok は登録が必要で、登録するとコマンドのインストールや設定を促される。そのあと以下を実行するとよい
ngrok http 8000 -bind-tls=true
内容も瞬時に反映されるので便利 ちなみに手元のサーバはファイル配信のみなのでWebServer for Chromeを使った。
これが本来の用途っぽい?
雰囲気でPromiseを使っていたが、雰囲気でTypeScriptを使い始め、雰囲気でasync/awaitを使い始めたが、よくわからないままだったので簡単に自分向けにまとめておく。 間違えていたら教えてほしい。ちなみにTSのtargetはes6
Promiseが返るようになるという認識
Promise.resolve()
を返すかそのまま値を返すとよい。
Promise.resolve()
が必要ないならわざわざラップして返す必要はなさそう。
const t = async () => { return Promise.resolve("ok") }; async function main() { await t().then(console.log); console.log("finish") } main();
const t = async () => { return "ok" }; async function main() { await t().then(console.log); console.log("finish") } main();
const t = async () => { // returnしなくても次に進む }; async function main() { await t().then(console.log); console.log("finish") } main();
Promise.reject()
を返すかthrowすればエラーが起きたことを知らせることが出来る。
try-catchを利用するので、エラーが起きた場合はthrowするのがわかりが良い気がする。
const t = async () => { return Promise.reject(new Error("error!")) }; async function main() { try { await t().then(console.log); } catch (error) { console.log("catch error", error) } finally { console.log("finish") } } main();
const t = async () => { throw new Error("error!") }; async function main() { try { await t().then(console.log); } catch (error) { console.log("catch error", error) } finally { console.log("finish") } } main();
また以下のようにthrowしただけであってもPromiseのcatchを使うことが可能である。 catchした場合は、try-catchのcatchには入らず、通常処理に戻る
const t = async () => { throw new Error("error!") }; async function main() { try { await t().catch(console.log) console.log("age") // 実行される } catch (error) { console.log("catch error", error) } finally { console.log("finish") } } main();
errorはなにも返さなくてもよい。
例えば Promise.reject()
に何も渡さない場合catchされた error
は undefined になる。エラーが起きたわけではないけど、なんらかの理由でこれ以上処理を進めたくない場合などに使うらしい。なるほど(Promiseのテクニック??)
const t = async () => { return Promise.reject(); }; async function main() { try { await t() console.log("age") // 実行されない } catch (error) { console.log("catch error", error) } finally { console.log("finish") } } main();
個人的にはそれをやるならそれ用のエラーを作ったほうが明確でよいと思ったが好みかもしれない。
class AbortError extends Error { } const t = async () => { return Promise.reject(new AbortError("ほげほげだからAbortだよ")); }; async function main() { try { await t() console.log("age") } catch (error) { if (error.constructor === AbortError) { console.log(error.message) return } console.log("catch error", error) } finally { console.log("finish") } } main();
form.submit()
するんじゃなくてfetchを使う必要があったのでやり方調べたらFromDataなるものがあった。便利
const form = document.querySelector("#form1"); form.querySelector(`input[name="hoge"]`).value = "hoge"; const data = new FormData(form); fetch("...", { "credentials":"include", "headers":{ "accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8", "accept-language":"ja-JP,ja;q=0.9,en-US;q=0.8,en;q=0.7", "cache-control":"max-age=0", "content-type":"application/x-www-form-urlencoded", "upgrade-insecure-requests":"1" }, "body": data, "method":"POST", "mode":"cors" }).then(res => res.text()).then(body => { // はい })
FormData オブジェクトの利用 - ウェブデベロッパーガイド | MDN
FormData - Web API | MDN
Spotifyを課金して使っていたけど、Youtube Musicを使ってみようと思って使い始めた。が、結局Spotifyに戻った。apple musicも課金してるけど、Android版の出来があんまよくなくてアプリが落ちたりするので最近あんま使ってない。
あるのかもしれないけど、どこにあるのかわからなかった。見ることがないので別になくてもいいけど。
仕事中に聞くことが多いし、通勤時間も徒歩を除くと3分くらいなので見ることがない。
家に帰ってきて「OK Google, 音楽かけて」というとSpotifyと連携している場合はスマホで流していた曲が流れる(気がする)
Youtube musicは連動せず違う曲が流れる。またSpotifyはPCからChromecast経由で流せるけど、Youtube musicは流せない。
Google Play musicだとまたちょっと違うかも。
MVを音源にしている曲がある。動画を見ていないのに突然話し始められるとびっくりする。星野源とか。
たぶん、他のサブスクリプションでは曲自体がないので便利に感じる人もいそう。例えば花譜 - YouTubeとか聞けるのは便利
前から気になっていたものの、カーテンを手動で開けれなくなるのは厳しいなあと思っていたら手動で開けれるようになっていたので買ってみた。
結構気に入ってる。
めざましカーテン mornin’ plus(モーニンプラス) スマホ連動型カーテン自動開閉機 太陽の光でスッキリ目覚める 新機種 MN-C02 2018年度グッドデザイン賞受賞
左右ともに開くタイプのカーテンの左側につけている。
朝起きるのがめちゃくちゃ苦手なんだけど結構スッと起きれるようになった。
具体的には前までは8時半から15分毎にアラームを鳴らして9時半にやっとこさ体を起こせる状態になるという感じだったけど、今は7時半にカーテンが開いて8時半のアラームで体を起こせる状態になるという感じ。寝る時間は変わらず3時とか4時です(もっと早く寝なさい)
カーテンを開けるときに音がうるさかったらやだなーと思ってたんだけど、動作パワーを弱めに設定すると気にならなくなった。
手動でカーテンを開け閉めできる設定にしていると自動で開け閉めする時にホイールを昇降するのだけど、その音が結構うるさい。
昇降するときのパワーは設定できないのだろうか?と思って調べたらあった。一番小さくしてもあんま変わらない気がする…
最初電池をいれても電源が入らず「不良品か…?」と思って触ってたら、電池がうまくハマってなくて電池が入る面を下に向けると電池が落ちてしまう状態だった。
電池の接点部品(-)が潰れてるようだったので、それを開けたら電池が入るようになったが少し心配
モーニンプラス関係ないけど、モーニンプラスの最強パワーでやっても開けなかった。
公式サポートには、磁石にテープを貼るとよいって書かれてるので、マスキングテープ貼ってみたら外れるようになった。
NO HARD WORK!: 無駄ゼロで結果を出すぼくらの働き方
NO HARD WORK! 読んでる。よくある福利厚生は社員を会社の外に出すのではなく社内に留めるようにすることが多く、僕らの福利厚生は残業せずにラップトップを閉じるきっかけになるものばかりだぜって書かれててナルホドってなった。
— ひさいち (@hisaichi5518) February 13, 2019
NO HARD WORKに「あなたの行動が文化になるのだ。だから、いい行いをすること」と書かれていたんですが、本当にその通りだなと思います
— ひさいち (@hisaichi5518) February 14, 2019
NO HARD WORKの模倣者という章で「競合にアイディアやデザインがパクられてもそれが人生さ!」って書かれててよかった。
— ひさいち (@hisaichi5518) February 20, 2019
今働いてる会社と考え方が共通する部分は結構あった気がする。まったく違うところもあったけど。サクッと読めてよかった。
2014年に新卒向けに発表した資料が未だに評判がよい。間違ったことは言ってないと思うし、新卒向けに話したので新卒にとってまだ良い資料なのだろう
ただ資料を作ってから5年が経ち、働いてる会社も変わって僕自身は少し違うコードレビューをするようになってきた。言ってしまえば、今はがんばってない。いや、がんばってないって言うと悪く受け取られそうなのだけど、ちょうどいい塩梅のがんばらなさがよいと思っている。前やっていたようにコミットを全部見ることはなく、今は「後戻りしにくいことを見つけること」にコードレビューの目的を絞っている。
後戻りしにくいとは、例えば設計の話で設計は決めてしまうとコードを大きく書き直す必要があって大変。だから、そこはよく話してから実装していくし指摘される。
逆に言えば後戻りできるならそれで良くて細かい指摘はしない。実際、コードを書いてるときにこうしたほうがよいなと思ったら直すし、僕のコードも他の誰かや自分自身に直されているところはある。
昔は頑張ってなるべくコメントしてたりしたけど、最近は「細かいところに時間をかけすぎるより他に大事なことってあるよね」となった。
レビューを頑張らないとコードの治安が悪くなっていくかと思いきや治安がいいように思う。またマージまでのスピードも早く毎週なにかしらの検証が行えてる。(もちろん実装が早いのもある)
自画自賛だけど毎週新しい検証のリリースしてるのマジえらい
— ishkawa (@_ishkawa) February 13, 2019
がんばりすぎないコードレビューは全てのチームで出来るかというとそうではないと思っていて、今のチームだからうまく出来ていると思う。というわけで、そういうチームで働くことに興味がある人はTwitterのDMか株式会社10X - 採用応募フォーム経由でご連絡ください。