よもやま話β版

よもやま話を書きます。内容はぺらぺら。自由に書く。

すばやく確認OKをもらうためのセルフレビュー

こんにちは、@beta_chelsea です。 ご縁ありまして、今年の秋頃からフィヨルドブートキャンプにメンターとして参加させていただいております。ということで、フィヨルドブートキャンプ Part 2 Advent Calendar 2020 - Adventarの記事を書きます。

昨日は メンター @u1tnk さんの 「失なわれた構造化プログラミング、そしてオブジェクト指向へ… 」、構造化プログラミングのお話でした。 ソースが実際に構造化されていく様子、実際に見ないとピンとこないことも多いかと思います。特にオブジェクト指向にお悩みの方はぜひご一読ください!

自分は「セルフレビュー 」をテーマにちょっと述べてみたいと思います。 フィヨルドブートキャンプは、メンターが生徒さんたちの書いた成果物(ソースコード)に「確認OK」を出すことで進めていくのですが、セルフレビューを活用することでそのサイクルがすばやくなるシーンもありそうだなと考えています。

TL;DR

「とにかく見直ししましょう!」ということを延々と述べます。

ルフレビュー is 何

「自分自身のアウトプットを自分自身でレビューをすること」を指して「セルフレビュー 」と呼んでいます。 なんとなく使っていた単語なのですが、一応Google先生に尋ねてみると自分と同じ解釈で使っている人もいるようで安心しました。試験にも出たことがあるようです。

基本情報技術者過去問題 平成25年春期 午後問6(プロジェクトマネジメント)|基本情報技術者試験.com

プログラミング担当者が単独で行うのがセルフレビューであり,プログラミング担当者ともう1名でペアを組んで行うのがペアレビューである。セルフレビューの終了後にペアレビューを行う。

自分以外の誰かにレビューをお願いする前のセルフレビューがうまく機能すると、ちょっとしたことで差し戻しを受けてしまうということがグッと減ると思います。また、レビューの内容としても、より本質的な議論に集中した濃いものになるでしょう。 フィヨルドブートキャンプでよく行われている「GitHubのPull Requestの機能を使ってレビューを受ける」シーンを考えつつ、セルフレビューのポイントを挙げてみたいと思います。

見直しする

Pull Requestを作ると、今回どんな変更を行ったのかをFiles changedのタブから確認することができます。

GitHubのPullRequestページのFiles changedのタブ
Files changedのタブ

レビューする人(以下「レビュアー」、フィヨルドブートキャンプではメンターが担当します)が主にチェックするのはこのFiles changedのタブの中身となります。この変更内容を、レビュアーにチェックを頼む前に自分自身で一通り眺めてみましょう。 結構、次のような気づきがあるケースが多いかなと思います。

  • Pull Requestの目的に関係のない変更が混じっていた
  • 意図しない半角スペースが混じっていた
  • typoがあった

作成者自身が見て気づくことは、そのままレビューをお願いすれば差し戻される要因になってきます。 レビュー依頼前にFiles changedを自分自身でも見直し、修正するクセをつけておくと、将来の自分の修正の手間も減らすことにつながります。

必要なら事前コメントを入れる

Pull Requestを見直していて「これはレビュアーに何かつつかれそうだけど、〇〇という事情があって、この実装になってしまった。仕方なかったんだよなぁ」と思うことが避けられない場合もあるでしょう。そんな時は、コメントを利用し「なぜこの実装をしたのか?」という事情を先んじて補足しておくのも一手です。先に補足があると、レビュアーからの「ここを〜〜のように書かなかったのは何故ですか?」という質問に答える手間が省略できて、さらにもっと重要な議論に早く移れるという利点もあります。

さらに見直しする(再レビュー依頼前)

例えば、「この変数はheartよりもstarという命名が適切です」というレビューがとあるファイルの10行目にコメントされたとします。10行目のheartという変数名をstarに修正し、改めて再レビューの依頼をした結果として、別のファイルの32行目にまったく同じレビューコメントをもらってしまった...みなさん一度はそういう経験がありませんか? こういったちょっと残念な事態の防止には、レビュアーから一度貰ったコメントが他の箇所にも適用されないかの「見直しセルフレビュー 」が効果的です。レビュアーは人間なので、Lintツールのように類似問題箇所を完璧に洗い出して各1行1行にコメントをつける...というのは残念ながら難しいでしょう。レビュアーの見落としを発見するくらいの気持ちで、改めてセルフレビューをやってみてください。他の箇所も同様に修正対応すべきか否か迷うケースの場合は、レビュアーと相談してみましょう。

翌日見直しもおすすめ

Pull Requestを作ってレビューを依頼しようと思ったということは、「完成した!」と一度は考えたということでしょう。「完成した!」という気持ちを持っている状態から、セルフレビューで自分自身が見落としていた問題を看破することはなかなか難しいことです。ちょっと変更内容がややこしいものだったり、モヤっとした予感があるけどピンとこない、といった時は、あえてその日は寝かせておいて翌日の自分にレビューしてもらうという方法も効果的かなと思います。一旦実装から離れてから改めて見直すことで、過去の自分の「やらかし」を看破できたというケースを体験した人も少なからずいるのではないでしょうか。 緊急時は残念ながら使えない手段ですが、自分は普段できるだけ当日見直しは避けるようにしています。

レビュアーとして気をつけていること

上記で紹介したことは自分も日頃の仕事のなかで注意し、実践していることです。一方で、フィヨルドブートキャンプでは「レビュアー 」として活動しています。生徒さんをお待たせしてしまわないためにも、一発で伝わるレビューになればと思い、次のことに気を付けるようにしています。

他の箇所も再度見直しして欲しい時は一言添える

上記の「同じ内容を再レビュー」の予防として、似た問題がPull Request内に散見されることに気付けた場合は、その旨を一言コメントに添えるようにしています。ただし、似た問題があること自体を見落としていた...というケースもあったりするので、やはり再レビュー依頼前の見直しはオススメしていきたいです!

相手と語彙や認識を揃えていく

「アンダースコア」「アンスコ」「アンダーバー」、これらの語句は全て同一の _ を指しています。 もしやりとりの中で先に相手が特定の単語を使っていた場合、同じものを指すときは同じ表記でコメントするようにしています。もしくは、相手が伝えようとしていることについて複数の解釈がある場合は、解釈AとBについて書き出してみて、どちらでしょうか? と尋ねることで相手の考え方と自分の認識を揃えていきます。 うっかり認識がずれたままレビューを進めると、不幸な勘違いコントのような状況が出来上がってしまい、それが発覚するのはソースコードの修正結果が出てきてから...ということも残念ながら時々あるケースです。できるだけその確率を減らすため、語彙や認識がちょっとでもズレそうな要因を排除するようにしています。

指示語は出来るだけ減らし、主語をハッキリさせる

「この引数は使われていない」という言い方よりも「引数valueは使われていない」と伝える...といったように、何を対象としているかをよりハッキリ示せるような書き方を心がけています。 こちらも「認識のズレ」を出来るだけ無くそうとする方向性の試みです。 いわゆる「こそあど言葉」は認識がズレやすい要因になりがちなので、気付いたら書き直すようにしています。

おわりに

さて、気を付けていることを書き出してみたものの、毎度完璧にできているかというと、うーん、なかなか難しいものです...。 また、フィヨルドブートキャンプのメンターとしてのレビューは、自分で何らかの答えを見つけた時が一番学びになるとも考え、あえてフワッとしたイジワルな言い方をしてしまうときもあります。すみません!

まだ学生の時分、プログラマーという職業の人たちは大きな企業の半個室ブースにこもって、あんまり人と会わなくてもいいし、とにかくプログラムと見つめあっていればいいんだ、コミュニケーション苦手な自分にとっては最高の職業だ...と思ってたことが実はありました。ところがどっこい蓋を開けてみると、これほど精緻なコミュニケーションを求められる職もないのでは、そう感じるシーンがあらゆるところに発生していました。コミュニケーションをおろそかにしたまま進むと、成果物が顧客の本当に求めていたものから180度逆の方向性に仕上がっていた...なんて事態になりかねません。 より良いものを作っていくため、言葉を尽くして自分の考えを伝えるテクニックをまだまだ磨いていきたいと思います。また、その重要性をフィヨルドブートキャンプの生徒さんたちにも感じてもらえるようなレビューが出来るよう頑張ります。

2021年も引き続きよろしくお願いします!

オブジェクト指向を説明したくてMemoについて考えてみた

オブジェクト指向を説明しようとして、Memoについて考えてみた。(Ruby)

例えば メモアプリで 1つのメモをMemo、全てのメモのまとまりをMemoListとして管理するときは、次のように表現できそう。 Memoは通し番号(id)と内容(content)を持っているものとし、MemoListはそれらを取りまとめる役割を担っている。

class Memo
    attr_accessor :id, :content
    def initialize(id, content)
        @id = id
        @content = content
    end
end

class MemoList
    def initialize
        @memos = []
    end
    
    def add(memo)
        @memos << memo
    end
    
    def find(id)
        @memos.find {|memo| memo.id == id }
    end
end

memo_list = MemoList.new
memo_list.add(Memo.new(1, "1番目のメモ"))
memo_list.add(Memo.new(2, "2番目のメモ"))
memo_list.add(Memo.new(3, "3番目のメモ"))

third_memo = memo_list.find(3)
third_memo.content #=> "3番目のメモ"

オブジェクト化しておくことで、メモに対する機能を増やしたいときは、class Memo にメソッドを生やすとさっと実現できる。 例えば memoの文字数を知る機能をつけたい時は、次のようにすると memo.length を使えるようになる。

class Memo
    # ...省略...
    def length
        @content.length
    end
end

他に、全てのメモの文字数の合計を把握したいとき、それはMemoListの仕事と考えて次のようにしてみた。

class MemoList
    # ...省略...
    def all_length
        @memos.sum {|memo| memo.length }
    end
end

こんな感じで、〇〇をやりたいときは誰(どの"モノ")にやらせるのか考えつつ機能を生やす。 今回のイメージとしては、次のような感覚で考えていた。

  • Memo → ペラ1枚の紙としての "モノ"
  • MemoList → 紙束としてまとまった "モノ" (ブロックメモとして売ってるね)

他にも動物とかで継承の考え方を示してみたいけど、一旦また今度にしよう。

File.stat('testfile').mode の戻り値について調べた

戻り値が何を意味するのか調べた備忘録。 前提として対象ファイルのパーミッションについて知るためにこのメソッドが使えそうということが把握できている状態である。

mode の値は8進数

https://docs.ruby-lang.org/en/2.7.0/File/Stat.html#method-i-mode

File.chmod(0644, "testfile")   #=> 1
s = File.stat("testfile")
sprintf("%o", s.mode)          #=> "100644"

まず sprintf("%o", s.mode) とあるので、 s.mode の戻り値は8進数にして確認すれば良さそうということがわかる。

mode はどんな情報を持つか

次にこの mode の8進数から何を読み取ればいいのか確認する。

Returns an integer representing the permission bits of stat. The meaning of the bits is platform dependent; on Unix systems, see stat(2).

このように書かれているのでUnixのstat(2)あたりを目標にわかりやすい資料を探してみる。

http://www.coins.tsukuba.ac.jp/~yas/coins/syspro-2002/2002-06-17/

モードが8進数で 0100644 (C言語の文法で、0から始まる数は、8進 数)であることから、ファイルの型(普通のファイルかディレクトリかという 情報)を調べることができる。

ここに乗っていた図がとてもわかりやすかった。 自分の理解を足してさらに噛み砕くとこんな感じの解釈になった。

modeの8進数と2進数の変換

ということで 100644 の上2桁で型の情報、下3桁でパーミッションの情報を表していると読み取れる。

型の情報の定義の確認

0100644の上位4ビット、つまり、0170000と AND (C言語のでは、 &演算子)をとった結果は 0100000 となる。この値は、普通のファ イル(regular file)を意味する。

ANDを取るというのは、2進数のとき同じ桁がどちらも1だった場合1にする、ということなので上位ビットのみ取り出すという意味合いになります。

ANDと16進数表現

そして <sys/stat.h> の表記は 0x8000 となっていて、16進数8000を表すので regular file を表すということを把握できる。

#define S_IFREG         0x8000  /* regular */

おまけ

  • 8進数を表現するとき、先頭に0がつく。 0100644
  • 16進数を表現するとき、先頭に0xがつく。0x8000

参考

ググらないと生きていけない脳みそだ...webの世界ありがとう。

Kaigi on Rails で発表しました(2020/10/03)

Kaigi on Rails で発表させていただきました!

speakerdeck.com

こういった大きなイベントに発表の機会をいただけてビビりながらも初めての動画投稿にトライしました。 Timetableが公開されたとき「すごい発表者の皆様の中に混じってしまった...」と冷や汗が凄かったです。

Kaigi on Rails 自体が第1回ということもあり、どういう方向性になるのかなと思っていたのですが、熟練の方から初学者の方まで楽しめる内容がバランスよく詰まった素敵な会だったと感じました。 そのバランスの中で、自分は初学者の方向けのコンテンツ比重として役目を果たせていれば良いなと思います。 自分があんまりDockerとかモダンなインフラ構成を履修できていないので、ちょっと紹介内容が古かったかなというあたりは反省です...。 あと、いらすとやさんの汎用性が凄かった。レールの素材を見つけてから「ほぼ全部いらすとやさんでいこう」と決めました。ありがとういらすとやさん...!

www.irasutoya.com

また、動画の事前投稿だったので当日は集中して発表を聞くことができました。 Rails開発をする上で「えっそんなことできるの!?」と行った発見の発掘ができたり、Railsからちょっと離れているけどいちエンジニアとして大事な話も押さえることができ、憧れは止まらないし止めちゃいけないなと改めて思えたり...、とても素敵な8時間でした。

準備してくださった運営のみなさま、発表者のみなさま、聞いてくださったみなさまありがとうございました! & お疲れ様でした!

f:id:beta_chelsea:20201003210759j:plain
駅員さんの帽子 ¥1,600

上記はとりあえず採択が決まった日にポチった帽子です。そこそこウケてて買った甲斐がありました。やったね。

Googleグループメールアドレスから送信したい時の設定

Googleグループメールアドレスを使って送信させたいとき、SMTPサーバーの設定を求められて困ったので備忘録。 なんか探したけど見つからなかったので。

その1. Googleグループ(のメールアドレス)を作る

作ったとする。 また、この中にちゃんと送信させたい人をメンバーに入れておく。 ちゃんとGoogleグループ宛に送信されたメールが届くことを確認しておくと吉。

その2. Gmailの設定を開く

設定 > アカウントとインポート > 名前: (Gmailを使用して他のメールアドレスからメールを送信します) そう、送信したいんですよ。と思いながら「他のメールアドレスを追加」を選択。

その3. ダイアログが開くので設定

別のメールアドレスの情報を入力してください。

名前: の項目にはその送信者として表示したい名前を記入する。
メールアドレス: の項目にはGoogleグループメールアドレスを設定する。
エイリアス として扱います。」は以下のヘルプを良く読んで決める。
https://support.google.com/a/answer/1710338

SMTPサーバー経由でメールを送信します。

(ドメイン名)のSMTPサーバー経由でメールが送信されるように設定します。と言われるので下記のように埋める。

SMTPサーバー: smtp.gmail.com
ポート : 587
ユーザー名: 今設定しようとしているgmailアドレス(Googleグループに登録したもの)
パスワード: そのgmailアドレスアカウントのパスワード
TLSを使用(推奨)をラジオボタンON

この時、例えばユーザー名には自分のgmailアドレスを入力しようとしていて、二段階認証していた場合、 パスワードに入力するのはログインパスワードではなく「アプリパスワード」のため注意。 アプリパスワードについては以下のヘルプを良く読む。

https://support.google.com/accounts/answer/185833?hl=ja

その4. 認証コードを受け取って入力して完了

上記手順を終えると、認証コードを入れろと言われるが、すでにグループアドレスに追加されていれば認証コードは届くはずなので、それを入れる。 無事自分のgmailからグループメールアドレスをfrom扱いにして送信できる。

やったね。おしまい。

できるだけ身軽になりたかった(サブマシンとしてのSurfaceGo)

愛用しているMacBookProが、 「バッテリーの交換修理のアラートがでる」 「tのキーのツメが割れて打てない時がある」 「そもそもキーボード交換修理プログラムの対象モデル」 という問題揃い踏み状態となっていた。 幸いAppleCareの期間内でもあったので、2020の年始に修理に出すことにした。 しかしながらバリバリ仕事で使っているものなので、修理中、トラブルシューティングに対して無防備になるのは避けたい。

そこで、以前買っていたSurfaceGoをサブマシンとしてしたてて、しばらくの間はこれで乗り切れるようにした。 また、簡易の対処マシンとして、お出かけの際に重宝できるだろうという目論見もあった。

どんな感じに仕立てたのか、備忘録として記録しておく。 ただ、仕立てる決意をしたのが秋で、一気に仕上げたのが最近なので、その間に対応した細かい設定を忘れてしまった...。 いつの間にかgit-bash.exeが入っていたけど、どんな経緯で入れたのか覚えていない...。

Dropboxに.kdbxのファイルを置いておく

まず自分の生活に欠かせないのがパスワード管理ツール。 二段階認証しているとはいえ、Githubへのログインにもまずパスワードが必要となる。 自分はKeePassXを使っているので、.kdbxのファイルをDropboxに入れておき、MacBookPro/SurfaceGo どちらからでも参照できるようにした。片方使っているときは.lockが追加されたり削除されたりの通知が出てくるので、うっかりlockしたまま片方のPCを閉じてしまったりしないように一応気を付けた。

Railsが動く環境を整える

RailsGirlsのページが一番詳しいと自分は思っている。都度メンテナンスもされているのでありがたい。 https://railsgirls.jp/install#setup_for_windows

開発周辺の状況

git clone ができない

betachelsea@pcname:/mnt/c/projects$ git clone git@github.com:betachelsea/piyopiyo
Cloning into 'piyopiyo'...
Warning: Permanently added the RSA host key for IP address 'xxx.xxx.xxx.xxx' to the list of known hosts.
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

SurfaceGoにまだ鍵を準備していなかった!

ref: GitHubでssh接続する手順~公開鍵・秘密鍵の生成から~ - Qiita
ref: SSH keyを4096bitで作成する - Qiita

$ ssh-keygen -t rsa -b 4096
$ cat ~/.ssh/id_rsa.pub

表示された鍵を https://github.com/settings/keys に登録すると、git cloneができるようになった。

任意のRubyをいれる

すでにRailsGirlsのチュートリアルでrbenv, Rubyは入っていたが、最新化して任意のバージョンをいれられるようにした。

# rbenv 最新化
$ cd ~/.rbenv
$ git pull

# ruby-buildも新しくする
$ cd ~/.rbenv/plugin/ruby-build
$ git pull

$ rbenv install 2.6.5

$ rbenv versions
* 2.6.3 (set by /home/betachelsea/.rbenv/version)
  2.6.5

bundlerを入れる

Rubyを入れたばかりだとbundlerもないのでまずbundler入れる。

$ gem install bundler

# もしバージョン指定が必要なら(Gemfile.lockの都合とか)
$ gem install bundler -v 2.0.2

環境変数を設定

必要なものがあれば ~/.bashrc に書いておく。

$ vim ~/.bashrc

export SECRET_TOKEN="xxxx...."

再読み込みも忘れずに。

$ source ~/.bashrc

postgresql をインストール

posgresqlを動かせるようにする。
ref: Ubuntu16.04にPostgreSQLをインストール - Qiita
ref: PostgreSQL 11.1をUbuntu 18.04へインストールし、外部から接続する - Symfoware

$ sudo apt-get update
$ sudo apt-get install postgresql

psql コマンドが動かない

betachelsea@pcname:~$ psql
psql: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

ref: PostgreSQL で psql コマンド を実行したら could not connect to database postgres: could not connect to server: No such file or directory と出る場合 - 約束の地
上記記事を参考にしてclusterをスタートさせてみる。

$ pg_ctlcluster 10 main start

betachelsea@pcname:~$ psql
psql: FATAL:  role "betachelsea" does not exist
# FATALではあるが、通ってはいるのでOK

接続用DBユーザ作成

betachelsea@pcname:~$ sudo su - postgres

# config/database.ymlに書いておいてあるusernameとパスワードのユーザを作る。

postgres@pcname:~$ createuser -d -U postgres -P dbuser
Enter password for new role: パスワードを入力
Enter it again: パスワードを入力

# ユーザーが追加された。

postgres@pcname:~$ psql
psql (10.10 (Ubuntu 10.10-0ubuntu0.18.04.1))
Type "help" for help.

postgres=# \du
                                   List of roles
 Role name |                         Attributes                         | Member of
-----------+------------------------------------------------------------+-----------
 dbuser    | Create DB                                                  | {}
 postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS | {}

rake db:create でDB作成

デフォルトではDBへの接続はPeer認証になっていて、ログインユーザからの $bundle exec rake db:create は失敗してしまう。 そのため、pg_hba.conf を変更する。

ref: PostgreSQLのDBに接続しようとしたら、エラーで接続できない
ref: PostgreSQLのPeer認証と他の認証方法への変更 | Web Memorandum
ref: [Ubuntu 16.04] PostgreSQLのリモート接続設定 - Qiita
ref: [備忘録]WSL(Ubuntu)でPostgresを試す - Qiita

betachelsea@pcname:~$ sudo vi /etc/postgresql/10/main/pg_hba.conf

# "local" is for Unix domain socket connections only
local   all             all                                     peer

# ↓ 次のように変更

local   all             all                                     md5


# 再起動する
betachelsea@pcname:~$ sudo service postgresql restart
 * Restarting PostgreSQL 10 database server                [ OK ]

改めてdbをつくってmigrationする

betachelsea@pcname:/mnt/c/projects/piyopiyo$ bundle exec rails db:create
betachelsea@pcname:/mnt/c/projects/piyopiyo$ bundle exec rails db:migrate

Redisいれる

$ rails s して localhost:3000 にアクセスしてみると、次のエラーが出た。

This results in IO::EINPROGRESSWaitWritable Operation now in progress - connect(2) would block

ref: Ruby on Rails: Operation now in progress - connect(2) would block - Stack Overflow
ref: redis - System has not been booted with systemd as init system (PID 1). Can't operate - Stack Overflow

そういえばRedisを使っていた。

$ sudo apt install redis-server
$ sudo service redis-server start

bundle install のエラーはapt-getで解決

結構世の中にはbrew(Homebrew)でinstallして解決とか書かれているが、あれはMacOSのパッケージマネージャーなので、apt-getで対応する。 ほかにはリポジトリによって多種多様だと思うので、各自頑張るしかなさそう。 まずエラーを読んでググればとりあえずなんとかなる。

サーバにsshできるようにしておく

必要なサーバにsshできるように設定しておく。 sshしたいサーバを事前にリストアップして設定、疎通確認しておくのが肝要。

deployが権限的にできない

capistranoでデプロイしようとしたところ、Could not open a connection to your authentication agent. と出て出来なかった。 ssh-add するといいらしい。次の記事を参考にして解決した。

ref: ssh-addできなかったときへの対処 - Qiita

$ eval `ssh-agent`
$ ssh-add ~/.ssh/id_rsa

MacBookProを修理に出す

無事、SurfaceGoでなんとかいつも通り仕事ができるだろうという感触を得られたため、AppleStoreに予約をして修理をお願いした。 年末年始、工場が動いていないので結局修理期間は平日に食い込むことになった。 また、AppleCareに加入してなければ¥53,000の修理費がかかったようだ。入っててよかったAppleCare...。

  • 12月30日(日) 昼頃に修理依頼、預ける
  • 1月4日(土) Apple修理センターに到着(メールが届く)
  • 1月5日(日) 修理開始の連絡メールが届く
  • 1月6日(月) 製品をお渡しする準備ができましたのメールが届く、引き取りに向かう

実質2~3日での修理だった。年末年始じゃなくて平日金曜とかに出した方がよかったのかもしれない...。 何はともあれ無事仕事の相棒は戻ってきたし、簡易お出かけの軽いSurfaceGoの整備もできた。

よかったよかった。 2020年もやっていくぞ。

RailsGirlsTokyo 12th コーチ参加&LT

2019/08/02-03 の日程で開催された RailsGirlsTokyo 12th にコーチ参加させていただきました! 初コーチということで、しどろもどろになりつつも、Girlsのみなさんの第一歩を少しでもお手伝いできたかなと思うと嬉しい気持ちでいっぱいです。 Girls、コーチ、スタッフのみなさん、ありがとうございました! 参加に誘ってくださったオーガナイザーのらいむさんにも大感謝です。 回数を重ねることでコーチ力(?)が上がるらしいので、ぜひまた参加したいです。

また、LT枠があったと聞いて勢いで発表させていただきました。 ただ自分がRailsRubyについてうんぬんを語れるほどの知識量に自身がなく、また今回の主役はプログラミングの扉口に立ったばかりであるGirlsのみなさんということで、プログラミングするに欠かせない「パソコン」をテーマにしました。

speakerdeck.com

実は資料づくりのときに一番頑張ったのがノートパソコンの歴史調べだったんですが、時間の関係で結局スキップしたので、興味ある方は眺めて懐かしんでください :) Girlsのみなさんの「次の一台」選びのときにまたほんのりと思い出していただければ幸いです!