「エッジケース」という言葉の使い所
主に境界値周りの検証を行うためのテストケースを「エッジケース」という。
これは文字通り境界であることからエッジケースという名前がついているが、
まれに"開発側が意図しない動作をユーザーが行うこと"を指して「今回はエッジケースのissueだったね」などという使い方をされる場合がある。
そのような めったに発生しないケースを英語で表現する場合は「コーナーケース」 を使うのがより意図に沿っていると思われる。
使う機会がありそうな〇〇ケースはざっくり以下のような感じ。
珍しいケース
| 特別扱い | special case |
| 境界付近 | edge case |
| 滅多に発生しない | corner case |
よくあるケース
| 一般的 | general case |
| 普通 | normal case |
ヒトはなぜ先延ばしをしてしまうのか
概要
| Title | Author | Detail | Link |
| ヒトはなぜ先延ばしをしてしまうのか | ピアーズ・スティール (著), 池村千秋 (翻訳) | 内容 （「BOOK」データベースより） 先延ばし研究10年超の世界的権威が、人類永遠の課題をユーモアたっぷりに解き明かす! 先延ばしするかしないかを決める「心の方程式」を初公開!方程式から導いた、克服のための13の行動プラン。 |
導入
下記のような問題が起きてしまう原因と対策
実行に移されないまま終わる決意。やる気が湧かずにうやむやになる目標。先送りされるダイエットに、提出日前夜に徹夜で仕上げるレポート。
あなたに期待して裏切られた人たちと、鏡に映る自分自身の失望の表情。ぐずぐず癖でみんなに迷惑をかけている家族や友人。
期日に遅れた公共料金の振り込みに、片付けをしないせいで散らかった家の中。無駄に過ぎていく時間、守られない予定、活かせなかったチャンス。
やりたいことや、やるべきことを実行できないのはほとんどの場合、先延ばし癖が原因
「先延ばし癖」と「怠け癖」は別
先延ばし癖の人はやるべきことを実行したいと考えており、
実際最後には実行するが実行するまでに苦労をすることが多い
典型的なパターン
職場で大きな仕事を任された。
最初は時間もたっぷりとあり、のんびりと仕事を進められる状態を楽しむが些細なことで気が散りはかどらない。
一日が終わるたびに「今日も仕事がはかどらなかった」という不安に苦しめられる状態が続く。
やがて期限が近づき、プレッシャーは増しているのに瑣末な用事ばかりやってしまう。(デスクの掃除、メールやチャットの未読処理、運動、料理...)
「今この用事を済ませているのは、後で本題の仕事にじっくり取り組む態勢づくりなんだ」と自分に言い聞かせ、そうこうしているうちに一日が終わり、また翌朝には逃避の一日が始まる。
不安を紛らわすためにニュースサイトをハシゴしたり、テレビやYoutubeのチャンネルをせわしなく切り替えたりといった逃避行動にますます深く没頭していく。
当初の確実に達成できるはずだった目標を放棄し、現状で達成できる最低レベルに目標を引き下げていく。
自己不信と罪悪感に苛まれ、切羽詰まった状況でついにやる気に火がついた時、目を見張るスピードで課題をやっつけ始める。
結果、一握りの幸運な人たちは火事場の馬鹿力で課題を完了できるが、大多数の人はガス欠を起こし不十分な結果を携えたまま期限を迎える。
先延ばしをする人のタイプ3種
1.どうせ失敗すると決めつけるタイプ
良い結果が得られる「期待」を持てず、手強い仕事に挑むという投資をすることができない
過去の経験から自分が何をやっても無駄だと学習してしまう「学習性無力感」を抱いている
→逃げ場のない部屋で電流を受け続けた犬は、逃げ場のある部屋で電流を流しても逃げずに電流が止まるまで耐え続けるようになる
2.タスクを退屈に感じてしまうタイプ
課題に「価値(楽しさ)」を感じられない
義務や責任を負うことを嫌がる
3.目の前の誘惑に勝てないタイプ
行動の基準がメリットの大小でもメリットを得られる確実性の大小でもなく「時間(タイミング)」
長く待たないと得られないご褒美より、すぐ手に入るご褒美を遥かに魅力的だと感じる
最も先延ばし癖との関連性が強いのがこの衝動性
対策
どうせ失敗すると決めつけるタイプ
成功の螺旋階段
興味のある事柄で自分の能力を少しでも高めるよう努力してみる。
その分野で成果を上げて自信が深まれば他の分野でも難しい課題に取り組めるようになる。
鼓舞される物語・仲間
共感できる要素のある成功者の伝記や映画を探してみる。
脳内コントラスティング法
実現したい理想の状態を具体的に思い浮かべた後、現在の自分の状態を対比する。
※理想の状態のみを思い浮かべて対比を行わないと単なる空想になり逆効果になりがち
失敗を計算に入れる
「10キロ痩せるつもりだったのに5キロしか痩せられなかった」
→目標を達成できなくても、進歩があったことを良しとする
先延ばし癖を自覚する
自分の無力さを認め、一度でも意思がくじけると自己コントロールが全て崩れると考えるようにする
→「たまにはいいか」を一切排除することで強いモチベーションを抱ける
タスクを退屈に感じてしまうタイプ
ゲーム感覚・目的意識
ポテトチップス工場のライン工
→有名人の顔に似た形のチップスを探すことに楽しみを見出す
延々とプールを往復する競泳選手
→サメに追いかけられていると想像する
目的を避けたいことではなく成し遂げたいことという視点で設定する
→「失敗したくない」ではなく「成功したい」と考える
エネルギー戦略
倦怠感や疲労感は先延ばしの理由になりやすい
→精神的なエネルギーの備蓄量に限界があることを認識して戦略的に割り振る
生産的な先延ばし
最重要課題より楽しく感じるが実行する必要のある副次的課題を探し、
最重要課題を先送りする代わりに副次的課題を処理するという「取引」を自分とする。
ご褒美効果
課題をやり遂げた後、自分にご褒美を与える
→仕事をやり遂げてご褒美を手にした時の喜びの感情が仕事にもさかのぼって投影される
不愉快な課題と楽しい課題やご褒美を抱き合わせる
→高級なコーヒーを自分にご褒美として与え、職場の書類作成に取り掛かる
目の前の誘惑に勝てないタイプ
プレコミットメント戦略
強力な誘惑をはねのける対策をあらかじめ講じておく。他人の協力も得て実行すればより効果的
→小説家のビクトル・ユゴー「執筆をはかどらせるため、書斎で全裸になって使用人に服を隠させた」
注意コントロール戦略
誘惑の対象を抽象的・象徴的に認識する
→ダイエット中にチョコやケーキを食べたくなった時はそれらの味や食感を思い浮かべるのではなく砂糖や脂肪の塊だと抽象的に考える
潜在感作法のテクニックを用いる
→誘惑の対象が不愉快なものというイメージを強化したり、誘惑に屈した場合に起こりうる恐ろしい結果を想像する
ゴールを設定する
長期的なメインのゴールを設定した後、それに至るまでの短期的なサブゴールに分割する
→まず取り掛かるモチベーションをいだくために超短期の「10分間ゴール」を設定する
例えば、本の読破がメインのゴールであれば最初の数ページを読むことをさしあたりのゴールとする
これを達成した後に長期目標に向けて行動し続けたいかを考える
まとめ
各行動パターンの共通点
未来のご褒美よりも現在のご褒美を過剰に重んじること(=衝動性)が先延ばしの原因
ハミング重みについて
LeetCode内でHamming weightという言葉が出てきたのでメモ。
概要
ハミング重みとは、シンボル列中の 0 以外のシンボルの個数である。典型的には、ビット列中の1の個数として使われる。(Wikipedia)
つまり、0以外の記号の個数がハミング重み。
e.g.
シンボル列が"10101"のとき、ハミング重みは 「3」となる。
btoa()およびatob()の代替
概要
btoa()およびatob()はMDNにおいて非推奨
ASCII文字列しか対応していないため引数に日本語を与えたりするとエラーになる
developer.mozilla.org
対策
input属性のフォームから受け取った値をエンコード/デコードして返すサンプル
as-is
import React, { useState } from 'react'; const [text, setText] = useState(''); const Encode = (e:any) => { setText(() => (btoa(e.target.value))); } const Decode = (e:any) => { setText(() => (atob(e.target.value))); }
to-be
Bufferを利用する形に変更
import React, { useState } from 'react'; import { Buffer } from 'buffer'; const [text, setText] = useState(''); const Encode = (e:any) => { setText(() => (Buffer.from(e.target.value).toString('base64'))); } const Decode = (e:any) => { setText(() => (Buffer.from(e.target.value, 'base64').toString('ascii'))); }
Macのターミナルを切り替える方法
現在使用しているシェルの確認
※$SHELLは大文字
$ echo $SHELL
使用できるシェルの確認
$ cat /etc/shells # List of acceptable shells for chpass(1). # Ftpd will not allow users to connect who are not using # one of these shells. /bin/bash /bin/csh /bin/dash /bin/ksh /bin/sh /bin/tcsh /bin/zsh /usr/local/bin/pwsh
Redux Style Guideのメモ
What's Redux Style Guide ?
Reduxを用いたアプリケーションのコードを書くにあたって公式が推奨する設計パターンや開発のベストプラクティス、アプローチの提案など。
ここでは優先度Aの全ルールと優先度B及び優先度Cの中から抜粋したルールを記載する。
原文：
redux.js.org
優先度の判断基準
優先度A：必須
優先度B：強く推奨
優先度C：推奨
必須のルール
| ルール | 優先度 |
|---|---|
| stateを直接書き換えない | A |
| reducerに副作用を持たせない | A |
| シリアライズできない値をstateやactionに入れない | A |
| storeは1アプリに対して一つだけ | A |
Actionに関するルール
| ルール | 優先度 |
|---|---|
| actionをsetterではなくイベントとしてモデリングする | B |
| actionの名前は意味を的確に表現したものにする | B |
| actionタイプ名を「ドメインモデル/イベント種別」のフォーマットで書く」 | C |
| actionをFSAに準拠させる | C |
| dispatchするactionは直に書かずaction creatorを使って生成する | C |
ツールやデザインパターンの使用に関するルール
| ルール | 優先度 |
|---|---|
| Reduxのロジックを書くときはRedux Toolkitを使う | B |
| イミュータブルな状態の更新にはImmerを使う | B |
| デバッグには Redux DevTool拡張を使う | B |
| ファイル構造には「Feature Folder」またはDucksパターンを使う | B |
その他設計に関するルール
| ルール | 優先度 |
|---|---|
| どの状態をどこに持たせるかは柔軟に考える | B |
| フォームの状態をReduxに入れない | C |
| 複雑なロジックはコンポーネントの外に追い出す | C |
| 非同期処理にはRedux Thunkを使う | C |
ファイル名についてるrcってなんだ
.bashrcとかの設定ファイルについてるrcってなんだろうと思って調べたのでメモ。
開発環境のRCとかは関係ないしなーと思っていたところRun Commandsの略らしい。
それがRunComに略され、最終的にrcとなったそうな。
ref. http://www.ne.jp/asahi/tao/elis/bitfaq/s001.html#1993.4
