JavaScriptのconstは値を変更できないわけではない
JavaScriptの勉強会に参加しようしようと思っていながら、3回目までは所用とモチベーションあがらず問題で参加できず。
4回目から参加することにしました。
ということで参加できなかった回の復習をしていたら、こんな例文が。
const obj = {name: 'Taro', age: 10}
obj['name'] = 'Jiro' // nameを書き換え
console.log(obj) // 出力結果 {name: "Jiro", age: 10}
あれ、定数なのに変更できるの？
constとは
まずはJavaScriptのconstを正確に理解しましょう。
このサイトがとてもわかりやすいので、ほとんどここで理解しました。
const 宣言は、値への読み取り専用の参照を作ります。 その値が不変ということではなく、その変数識別子が再代入できないというだけです。 たとえば、定数がオブジェクトのコンテンツの場合、オブジェクトのコンテンツ(例 その引数)自体は変更可能です。
const宣言は「値を変えられない変数を作る」なのではなく「値に読み取り専用の参照を作る」ということです。 constで制限しているのはアドレスを変更すること、つまり再代入や再宣言ができないということになります。
結局どういうことなの？
といっても文章だけで理解できなかったので、上記サイトの「例」であがっているコードと意味を理解するために図を書いてみました。
イメージ図なので細かいところはあってないかもしれませんが、自分が理解できたのでよしとします。
つまり"const 宣言は、値への読み取り専用の参照を作ります。"というのは"constで宣言した変数の矢印の向きを変えるようなことはできない"ということだと理解しました。
まとめ
前述のとおりconstは再代入や再宣言はできませんが、値が上書きできないわけではないです。
参考
今回の内容を理解するのに、以下の記事もとても役立ちました。
子供が成長すると「育てながら仕事する」は楽になるのか
この記事は子育てエンジニア Advent Calendar 2019 - Adventarの15日目の記事です。
前日の記事はこちらです。
ワーキングマザー暦12年のエンジニアです。
おかげ様で子供も成長し手をかけてあげることもだんだん少なくなりました。
ですが12年目の今、「子供の成長＝子育てが楽になる」ではないなぁということを改めて感じる日々です。
家族構成
- 私（40代）シングルマザーエンジニア。
- 長女（16歳、高２）。嵐にすべてを捧げるJK。細か事は気にしないがA型。推しメンは大野君。
- 次女（13歳、中１）。バスケ部と塾で忙しいめの生活。おそろしくズボラだがA型。オンとオフで差が激しいBitみたいな子。
旦那さんはいませんので３人暮らしです。
物理的なサポートは減った
「ご飯を食べさせる」「お風呂に入れる」「着替えを手伝う」「幼稚園へお迎えにいく」など、子供が一人でできないことの補助をする機会はほぼなくなりました。
が、塾や部活やバイトの送迎なんかは今でも頻繁に出番があります。
天気が悪かったり朝早かったり荷物が多い時は出番が増えます。あとはやはり女子なので帰りが22時をすぎるような時は迎えに行きます。
ごはんを食べさせることはありませんが、高校生なので毎日お弁当を作らないとならないです。
かかるお金は増えた
成長とともにかかるお金はガンガン増えます。
部活（ユニフォーム、バッシュ、練習試合の交通費）、お小遣い、学習塾、習い事・・・。
もちろんごはんの量も増えますし、欲しがるものもいちいち高価になってきます。
中学、高校になり制服も一式揃えると10万近くかかりましたね。
あと旅行もすっかり大人3名分かかるようになってしまいました。自分の中ではまだ子供なんですが世間では立派な大人として扱われています。
多感な時期を迎える
中学生、高校生といえばもう自分の意志で考えて行動しますから、忘れ物しようが時間に遅れようが基本的に自己責任です。
親が「あれしなさい」「これしちゃダメ」と口を出すことはほぼなくなりました。
ただ、小さな子供のように自分の喜怒哀楽を全面に出してくれなくなってくるので、何を考えているのか汲み取るのが少し難しくなります。
放置することと信じて任せることは違うので、親としてもそこを履き違えないように気をつけています。
姉妹であっても"個"であることを感じる
姉妹であっても気持ちの表現するタイミングや方法が違うなぁと感じます。そのへんが顕著にあらわれてきます。
長女はあまり抱え込まず、「ありがとう」「ごめんなさい」などの気持ちもストレートに伝えるタイプです。普段からわりと会話が多いので、親としてもいい意味でわかりやすく助かっています。
一方次女は自分の気持ちを言葉にするのが苦手で「ちょっと何考えているかわからない」と感じることが多いです。
だけど母の日や誕生日には必ず手紙とプレゼントをくれ、そこには感謝の気持ちがたくさん綴られていたりします。「言葉で伝えるのが苦手なだけで普段からいろんなことを感じている」というのが次女なんです。
さいごに
子供の成長とともに子育てが楽になったとは全然思いませんが、子供へのサポートの仕方が「できないことの補助」ではなく「子供の自立を見守る」へシフトしてきているなぁと感じています。
BacklogのリモートリポジトリにSSH接続をする（PuTTY形式のキーを作成）
SauceTreeを利用してBacklogのリモートリポジトリとSSHで接続したいと思い、OpenSSHでキーペアを作成して登録したところうまく動きませんでした。Windowsだから？Backlogだから？
SSH接続設定｜サルでもわかるGit入門【プロジェクト管理ツールBacklog】を見たところ「Windowsの場合はPuTTYで」みたいなことが書いてあるので、 ここはこだわりは捨てPuTTYで鍵を作ることにしました。
ちょうどSauceTreeからPuTTY形式のSSHキーを作成できるのでそれで作成しましたが、ちょっとわかりづらいポイントもあったのでPuTTY形式でのSSHキー作成手順を残しておきます。
PuTTY Keyを作成
「SSHキーの作成/インポート」を選択
[Generate]をクリック。マウスをグルグルするエリアがあるので、そこで適当にマウスをグルグルするとキーの作成が進む。 「このマウスをグルグルする」のが最初わからなくて全然キーの作成が進まず、ここで最初につまづいた。 よく見たらちゃんと書いてあります。英語で。
キーができます。パスフレーズの入力は必須ではないですが必要であれば入力します。
[Save public key]ボタンをクリックして公開鍵を保存、[Save private key]ボタンをクリックして秘密鍵を保存します。
SauceTreeにプライベートキーを登録する
あれ、何も起こらない？と思いましたね？すごいわかりづらいんですけどWindowsのタスクバーを確認するとちゃんと起動されています。これがわかりづらくてちょいハマりしました。
で、アイコンをダブルクリックして起動します。
3.[Add key]をクリックして先ほど保存した秘密鍵（.ppk）を選択します。
Backlogにパブリックキーを登録する
1.Backlogの[個人設定]-[SSH公開鍵]をクリック。先ほど保存した公開鍵(.pub)ファイルをテキストで開き、文字列をコピペします。
メモは任意で記入して登録をクリックすると[登録されたSSH公開鍵]欄に追加されます。
以上で、SauceTree上でBacklogのリポジトリとやりとりができるようになりました。
参考
他の気持ちはさておき、感謝だけは伝えたほうがいいよ
と思う出来事があったので、技術エントリーじゃないですけど書いておきます。
「出会いと別れの時期」といえば3月4月を連想することが多いと思いますが、私のまわりでは今がそのタイミングだったりします。
先日も海外に転勤になる友達の壮行会で集まったら、集まったメンバーの中に今秋東京へ行くことが決まった人がいました。かくいう私も7月で今の職場を退職し、8月から新しい場所で働くことが決まっています。
「みんな変化するんだなぁ。」
誰かがそんなことをつぶやいてました。そう、みんな変化するんだ。
自分の退職について進んで人に話しはしませんでした。隠してはいなかったので聞かれたら素直に答えてましたが。
これについて特に理由はありませんが、しいていうなら「有名でもなんでもないただのSEが辞めることをあえて自分から触れ回る必要もないのでは」と思ったからです。
知らなくて誰も困らないでしょうし、時が来ればみんな自然に知るでしょうし、という気持ちです。
そして最終出社日が近づくにつれ除々に周知されていくわけですが、思いがけなく色々な方にお言葉をかけていただきました。その時に、
感謝の気持ちを伝えてもらうということはこんなにも嬉しいことなんだな
というのを感じました。
最後だからこそなのか、最後じゃない日々の中では伝えそびれてしまうような感謝、期待、さびしさ、応援の入り混じった言葉をたくさんかけていただきました。
逆に言うと、こういうふうに思っていてくれてたんだなぁ、こんなふうに自分は役に立っていたんだなぁというのを、最後になるこのタイミングまであまり実感することなく過ごしてきたということになります。
これに関してはすごくもったいない気持ちがあり、自分の働きが誰かの役に立てているんだということを日々感じながら過ごせていたとしたら、自分の選択はまた変わっていたかもしれません。
これまで私も照れくさい気持ちがあったり、私からの感謝なんてそもそも欲しがってないのではという自虐的な想いもあったりで感謝を人に伝えるということを積極的にしてきませんでした。
ただ、「自分が誰の役に立っているのか」「なにかに貢献できているのか」というのが仕事に対するモチベーションの維持や自分の存在意義を確かめるきっかけになり得るとしても、それを自分ひとりで実感することはあまりにも難しく、だからこそ誰かからかけてもらう言葉が大切なんだと思います。
なにより、私自身そういう言葉をかけてもらい心から嬉しかったし、自分一人では感じることのできない気持ちに気づかせてもらうことができました。
と同時に、もう少し日常的に実感できていたらなぁという後悔もあります。
もしも、誰かに対する感謝の気持ちを日々持っていながらもなんとなく伝えられていない人がいれば、然るべきタイミングで伝えるのではなく普段から伝えてあげてほしいなぁと思いました。
その人が近くにいるうちに。
TDDBC札幌2019を開催しました
6/15(土)はt_wadaさんをお迎えして札幌で8年ぶりのTDDBCでした。
当日はわざわざ仙台からi_takehiroさんがお手伝いで来てくださり、t_wadaさんの基調講演&ライブコーディング、そしてi_takehiroさん名物(？)レビューのマサカリが炸裂するというめちゃくちゃエモいイベントでした。
当日様子はnemorineがtogetterにまとめてくれましたので、こちらをご覧いただければ会場のアツい感じが伝わるかと思います。
本イベントのメイン担当のKO_SHO14もブログにまとめてくれていますのでこちらもご覧ください。
ちょっと余韻に浸っている間に他の参加者の方達がぞくぞくと参加レポートを書いてくれていて、しかもすごくよくまとまっているものばかりですので、私の方はちょっとした感想とスタッフとしての裏話を書こうと思います。
お弁当
お弁当付きのイベントだったので私はお弁当係りでした。
幕の内かちらし二段弁当からお選びいただける感じにしました（幕の内は撮るの忘れました）。
実物は写真でみるより小ぶりです。スタッフ集合時間に遅刻して朝ごはんを食べずに参加した私としてはもう少し大きかったらよかったかなぁ。この後パン１つ食べました。
午前中は基調講演だったこともあり参加者どうしで自己紹介したり会話するきっかけがまだないままお弁当タイムへ突入だったので、ちょっと静かなランチタイムとなりました。
基調講演
ざっくりなタイムテーブルを説明すると、午前はTDDの基調講演+ライブコーディング、午後はペアによるTDD体験でした。
基調講演ではこちらにそってt_wadaさんからわかりやすい説明をしていただいたあとに、実際のTDDをライブコーディングで見せていただきました。
私は、事前にTDDについて調べた時に「要件や説明文をTODOリスト化する」というところが一番悩みそうだったのですがいくつかコツを掴むことができました。
- テストが大変そうなところ、やりたくなさそうなところを後ろに回して、テストをしたら効果がありそうなところを残すようにしてわける。
- ただし書きがある場合は、そこから基本の動作を読み解くことができる。
- リスト化していくときは、表記揺れがないように言葉や言い回しも揃えていくと良い。
- 重要なところはテストしやすくし、テストしにくいところには大事なロジックを置かない。
- TODOリストは最初からパーフェクトに作らなくてよい。うまくTODOリスト化できていないとテストや実装で手が止まるが、手が止まるのは考え抜けていないということなので、そうなったらまたTODOリストに戻ってくればいい。
この辺の大事なことは時と共に忘れてしまいそうだったのでしっかり動画に収めました。
ワーク
午後のワークで、私はRuby+ Test-Unitで整数の閉区間のお題に挑戦しました。
実際にやってみてめちゃくちゃ感じたのは「TDDはやらずして習得できない」ということです。TDD習得したいと思っている人はTDD本読むだけではなくてほんとやったほうがよくわかります。*1
私も実際ここに来るまでは間違って覚えていたことがたくさんありました。
自分の場合は、どうしてもRed（失敗するテストを書く）からrefactoring（動くきれいなコード）に飛びがちで、green（失敗するテストを通すためのプロダクトコードを書く）が抜けそうになりました。私だけではなくテストを書く習慣がない人はけっこう同じ感じだったんじゃないかなーと思います。
あとはred⇒green⇒refactoringをまわす速さというかリズム感みたいなものはやってみないとわからない部分だなぁと感じました。
たとえばred⇒greenにする時に、greenにするためのプロダクトコードがうまく書けない(このテストをgreenにしようとすると他のテストが死ぬ)とか、red⇒greenまでが適当すぎてrefactoringでやたら時間かかるとか、そういうリズムは書いて詰まって初めて「ああ、テストコードの構成がよくないんだな」とか「名前適当すぎてこのテストとあのテストの区別がわからん」とかが見えてくるという感じでした。
ワークの後はいくつかのペアからピックアップして公開レビューをするのですが、ここでi_takehiroの鋭いマサカリが炸裂します。
llanowar19jは「おっしゃる通りです」を10回以上連呼してた気がします。
私はまだヒヨコすぎてマサカリを受けたら即死だと思いますが、指摘がすごく的確だったのでこういったレビューを受けることができるというのも良い機会だなと思いました。
スタンドのスタンド
nemorineのこのひとことからすべては始まりました。
デザインは私、企画と製作はnemorineで作ったスタンドのスタンドがこちらです。
なん……だと……！？#tddbc #agilesapporo pic.twitter.com/H9o6BrKjBD
— Takuto Wada (@t_wada) 2019年6月15日
likeが今でも伸び続けていて1000を超えました！ ベルトはよく見たらTDDになっていることにみなさんお気づきでしょうか。
みなさん会場に入る前に写真を撮ってSNSにあげてくれたり、t_wadaさんとの記念撮影に使ってくれたりしたので作ってよかったなと思いました。
スタンドのスタンドの裏話
まずはボツ案。
口を開けて吠えているのはt_wadaさんのスタンドっぽくないということで却下。なるほど。
最終的に大きく投影したときに、バランスが悪くならないようにちゃんと6等身を意識するよう気をつけました。
ちなみに当初案では体毛が生えてましたが、最終的には脱毛しました。
実際に現場で完成版をみると手直ししたいところがたくさんありますが、まあまあ満足です。*2
まとめ
プログラマの三大美徳の気持ちをもっと持とうと思いました。*3
動作するきれいなコードはあらゆる意味で価値があり、だけといきなりやるのは難しい。まずは動作するコード、それからきれいなコードへ。そしてそれを一度にやろうとせず１つずつ倒すことが大切だなぁと思いました。
文章からテストを起こす(文章がテストを駆動する)とか
失敗するテストを通すためのプロダクトコードを書く(テストが開発を駆動する)とか
テストが書けなくて手が止まったらTODOリストに戻る(テストがテストを駆動する)とか
greenのテストが意図せずredになったらテストを見直す(開発がテストを駆動する)
みたいに相互的に作用していて、この開発方法がテスト駆動開発と呼ばれる理由が腑に落ちた気がします。
逆にテストを先に書いても、キレイな動くコードを書くことに貢献できていないのならただのテストファーストでTDDではないということかな。
まぁちょっとまとめが雑ですが私としては学びがたくさんあってよかったです。
参加してくださったみなさんにも同じように感じてもらえていたら嬉しいです。
もしブログを見てアジャイル札幌のイベントに興味を持ちましたらぜひ来てください！
*2:最終的にはふんどしっぽいところにt_wadaさんのサインを入れていただきました。
イラスト #1
趣味でちょっとしたイラストを書いたりしていて、これは札幌スクラムトゥギャザーリングを開催したときに書いたものです。
まずイベントの案内ポスター。 ポスターといってもA4の小さい貼りもので、参加者が迷わずに会場までこれるための案内に使うやつです。
イラストの人物は@kawagutiさんです。 この頃はまだ面識がなかったのでネットの写真を見ながら書きましたが、あれから何度もお会いしているので今ならもっといい感じに書けるのになぁという気持ちです。
もうひとつは紙粘土ワークをやった時にスクラムマスターがつける腕章。
手前から
- スープカレー
- 羊（ラム）
- トラ
- 寿司
です。トラ以外は北海道らしさを添えてみました。トラは、前日にトラを書く用事があって手が覚えていたのでさっと書いただけです。
イベント開始直前のお仕事だったので10分位で書きました。
これからも時々、書いたイラストを公開していこうと思います。
TDDの基本
20019/6/15(土)に札幌では8年ぶりのTDD Boot Camp(TDDBC)が開催されます。
8年前のTDDBCには私も参加していたはずなのですが、そのときはまだTDDについて全然理解していなかったのと、その後TDDを実践する機会がゼロだったので、ほぼすべてを忘れてしまいました。
というわけでTDDの基本から。
@t_wadaさんの［動画で解説］和田卓人の“テスト駆動開発”講座全20回分の内容を自分なりにまとめました。
この動画おすすめです。@t_wadaさん以外の観点も入っていたりコメントでリアルツッコミが入ったりしていて面白いし、入門としてはすごくいいんじゃないかなー。
第12回目までがTDDの入門的な内容になっているのでそこまでをまとめました。
テスト駆動開発（TDD）
アジャイル開発宣言に携わったうちの1人であるKent Beckが考案したプログラム開発手法の一種。 以下の３つの基本ステップを１サイクルとして、繰り返しながらコードをより良くしていく方法。
「最初にテストを１つ書き、次にそのテストがグリーンになるような最低限のコードを実装する」ということは、言いかえるとテストがあってコードが生まれるということ。
すなわちテストが開発を駆動していくから、テスト駆動開発という。
１つのテストに対してこの3つのステップを回し、それが終わったら次のテストを書き…を繰り返しながらコードをより良くしていく。
ここで注意したいのは最初からいくつもテストを書かないということ。
「小さい単位で確実にそしてスピーディーに、レッド⇒グリーン⇒リファクタリングを積みかさねる」というのがとても大事。
小さく早くステップを実行することで、息を吸うようにテストコードを書き、息を吐くようにプロダクトコードを書く。「テストがあって開発が駆動する」というのを習慣にするということを目指す。
そのためにはこの１つずつテストを書くというのがとても大事。
"テスト"という言葉の定義
"テスト"という言葉には、実は以下のように目的によって複数の意味合いに分かれている場合が多い。が、そもそもこの分類を意識していない場合使い分けられていない。 ここで"テスト"という言葉の分類と、TDDにおける"テスト"とはなにかを考える。
Developer Testing
開発者が開発者（未来の自分も含む）やチームのために行うテストで、自分で書いたコードを自分でテストする。
こうすることですばやくフィードバックを得られ、その結果コード、しいては開発全体がより良いものになっていく。
単体テストや結合テストはDeveloper Testingに属する。
Customer Testing
お客様側からみたときにその機能が要件を満たしている／満たしていないを判断するためのテスト。 このテストが通らなければ、お客様側から見たときに「機能は完成していない」という判断になる。 テストが通らない = 受け入れることはできないというのが明確なので、進捗や受け入れ状態が明確になる。
受け入れテストはCustomer Testingに属する。
QA Testing
品質管理、品質保証を目的としたテスト。 上２つは機能に対するテストであるのに対し、QA Testingでは非機能の観点でのテストも含まれる。 「機能」という単位に限らず、システム全体としての品質を保証するためのテスト。
非機能テストはQA Testingに属する。
TDDで指し示す"テスト"はDeveloper Testingである。
TDDをどうやって学んでいけばいいか
@t_wadaさんのおすすめの学び方。
1.写経。おすすめ本は、 テスト駆動開発や『WEB+DB PRESS Vol.35』『WEB+DB PRESS Vol.37』*1。
2.セミナーとか経験者とのペアプロやレビュー。たとえばテストを書くリズムとかサイクルとか、そういった写経ではわからないことが体感できる。
サイクルをどうまわせばよいか
1. 受け入れテストを書く
最初にやるのは「自分のための受け入れテスト」を書くこと。（=大きいテスト）
プログラムレベルのテストを考えるのではなく、「もしこの機能ができあがったとしたらこういうことができてほしい（=ToBe）」という外側の視点から書く。ブラックボックスに近い。
テスティングフレームワークを使って行う。この時点ではプログラムは存在しないので当然レッドになる。
2. 大きいテストを満たすタスクを洗い出す
大きな機能を実現するために必要な内部の設計行っていく。1. の受け入れ条件を満たすために必要となる小さな機能をタスク(箇条書き)にしていく。
3. 小さな機能に対し3ステップを実施する
先に「大きな機能の受け入れテスト」という大きい視点で考え、それを実現するための小さなタスクを考えて、そのテストを１つずつ書く。（=小さいテスト） これを繰り返す形でテスト駆動していく。
言い換えると「小さいテストをグリーンにする」を積み上げることで、最初はレッドだった大きいテストをグリーンにするということを目指す。
テストの資産価値
動画を最後まで読んでいくとこの「テストの資産価値」について考えておくことはとても大事なことなんだと感じたので、まとめる。
「小さいテストがグリーンになることの総和＝大きいテストがグリーンになる」は前述のとおりだが、ここで問題。 仕様変更などによって小さいテストが１つでもレッドになると＝大きいテストがレッドになるということであり、あまりにテストの単位を小さくしてしまうとすぐ真っ赤なテストになってしまう。
そうなった場合に小さなテストを１つ１つ直していく必要があるのか？（これはけっこう現場あるあるだなぁ。）
考え方としては、まず小さなテストが赤くなった理由を考える。
- 仕様変更によって、もうこのテストが存在する意味がないのであれば外す。
- 仕様変更によって、テストの内容を変更する必要があるのであれば、テストをメンテナンスしてグリーンにする。
いきなり「赤くなった小さいテストをどうするか」に注目するのではなく、仕様変更後の大きいテストの受け入れテストを満たすために小さなテストはどうなっているべきかを考える。
その上で、価値のなくなった小さいテストを外し、必要な小さいテストをグリーンにすることで、仕様変更後の大きいテストをメンテナンスしていく感じ。
どうもうまく説明できない。けどすごく大事な気がする。
リファクタリングをどこまでやるか
目安としては2つある。1つは「重複がなくなるまで」。これはDRY（Don't repeat yourself）に基づくもの。 次の目安は「開発者の不安がなくまるまで」。例えばコードを書いていてここがモヤっとするとか、この名前がしっくりこないなどの不安に対してリファクタリングを行う。
リファクタリングそのものはお客様にとって機能を提供するものではなく、お客様への価値は変わらないため、やめどきを決めておくことが大切である。*2
*1:Vol.35とVol.37はもう販売していないがWEB+DB PRESS総集編[Vol.1~102] にまとめられている
*2:「開発者にリファクタリングさせたらいつまでもやり続けるため永遠にプロダクトが完成しない」と言われるほど、開発者は無限にリファクタリングしたがります。
