1月のやっていきログ

先月は中盤くらいまでいいペースだったけど後半に体調不良で一気にペースダウンしてしまった。優先順位の設定とかやろうかな…。

昨年末、やっていくぞ!という思いを新たにしたところ、さっそくフラグを回収してしまいました。 どうしてこうなった…。

やったこと:

やり残していること:

できなかった原因:

1月中旬くらいまでは遅れ気味だがそこそこのペース配分でいろいろ進められていたと思っている。 問題はそれ以降から月末まで体調を崩し気味だったこと。

早く治そうと早めに寝たりしていたのだが一向に回復しなかったせいでインプットに当てる時間やアウトプットに当てる時間がほぼなくなってしまった。 それどころか完全に体調を崩して熱がでて何日も寝込んでしまった。

これによって大幅に計画が狂った。

リカバリー:

とりあえずまずはRailsチュートリアルを最優先でやっている。 これは1月中旬まではインプットが順調だったため、2月は多少インプットを減らしても挽回できそうだなと思っているから。 なのでやり残していることを「Railsチュートリアル写経」→「Go言語でチャットアプリ作る」→「テスト駆動開発読む&写経」で考えている。

テスト駆動開発Rubyでやっていきたいと思っているがGo言語でもいいかもしれない。

最後に

ゼノブレイド2が全然終わってくれなくて非常に時間的制約が厳しい。

合議制の話しからプロジェクトマネージャーとプロダクトマネージャーの違いに思いを馳せてた

合議制は駄目なシステムか?

medium.com

製品開発の目的は社内の人を満足させることではない

とあってここ最近似たようなことを考える機会があったのでかなり得心がいった。 合議制はある種リスクの分散を目的としてる節があるとぼくは感じていて、 その結果リスクを分散する代わりにあなたの意見も取り込みますよというスタンスにみえる。

結果、合議制で出来上がったものはどこかでみたことのあるようなもの、あるいは劣化版ということになりがちだ。

少なくともスタートアップやベンチャーのような企業やチームであれば合議制で同意をとっていくのは悪手だと思う。 そんなコンセンサスをとってどこにでもあるなにかを作るくらいなら「これしか出来ないがこれだけはどこの製品よりも尖ってる」製品を作るほうが生産的であると感じる。

傲慢であればよい?

じゃあ意見を聞かない傲慢なマネージャーになればいいのか?というとそれは極端すぎる例だと思っていて、 1人が持ち得る視野の広さは有限であり、またバイアスがかかっている。 それはバイアスに関しては属人性が高いので良い面もあり悪い面もあるという感じだが視野の広さという点では個人が持ち得る視点はどうやっても限界がある。

全てを見通す神の眼でも持ってるなら別だが、人類にはレベルキャップ解放されていないので神の眼は装備できない。 つまり、人海戦術でマネージャーにとっての考慮外を潰すのがベターとなる。

大企業などであれば凡庸な製品を作っても問題ない部分が存在する。 大多数の人間を満足させ得るプロダクトを作るとなると合議制で決まったような平凡だが堅実な製品が好まれることもあるだろう。 ただそれはブルーオーシャンだから許されるとも思っている。 レッドオーシャンになったときに同じことをしていても他社だって同じようなものを作るだろうからそことの差別化を図らないと遠からず追い抜かれて、時代遅れの産物になってしまう。

おうさまとさいしょう、あるいはしょうぐんのはなし

閑話休題。 そうして考えていたときにふと「プロダクトマネージャーは製品の絶対的な決定権を持っている役割でその分多くのリスクも抱えた存在なのではないか?」と思い至った。 いままでプロジェクトマネージャーとプロダクトマネージャーの具体的な違いがいまいちピンとこなかったのだが以下のような理解をしたところ少しだけ靄が晴れたように感じた。 全体としてはまだまだ理解が甘いと思っているが少しだけ理解できた気分になっている、今は少なくともこれでいいのかなと思う。

つまりプロダクトマネージャーとは王様なのだ、そしてプロジェクトマネージャーは宰相や将軍という役割なのだ。

王様が「ここ最近税収さがってるから農業改革するぞ!」と号令をかける ↓ 宰相や将軍がそれを受けて「税収下がってるのは川が氾濫しているから。じゃあ農業改革して税収増やすには治水工事だ!」と道筋立てていく。 ↓ それを元に官僚たちが詳細を詰めていく

こんな感じの理解であってるのかわからないがそうすると確かに2つの役割は明確に違うし、同じにしてはいけないということがわかる。

プロダクトマネージャーはプロダクトの成否まで含む全てのリスクを負い、何故それが必要なのかを示しつつ、進むべき目標を定める。 プロジェクトマネージャーはそのプロジェクトが円滑に回るためのリスクを負い、そのために必要なものを揃えていく

こう考えたところ、自分のなかで妙にしっくりときた。

まとめ

両方とも略称がPMだったり、いままでプロダクトマネージャーとプロジェクトマネージャーが(少なくとも明示された)仕事をしたことがなかったのでいまいち理解できていないなと思っていたが少し理解が進んだように思う。

大きなリスクを負うからこそ彼ら、彼女らは大きな報酬を得ているわけなんだけども、たまーにそのリスクを背負わず(背負えず?)にその席についている人がいると不信任決議案を出したくなるという気持ちにもなり「マネジメントとか人の評価って本当に難しいなー」という雑な締めくくりで終えたいと思う。 ここから先は藪蛇というか生半可な知識で足を踏み入れるとものすごい数のマサカリが飛んできそうだなーと思うので自粛しておく。

しがないラジオ sp 14の補完・補足

紹介:

sp.14a【ゲスト: lucca0show】楽しいコミットメントの始め方

shiganai.org

sp.14b【ゲスト: lucca0show】楽しい積ん読カンバン術

shiganai.org

ゲスト出演しました! …がいくつか話していて説明不足であったり、うまく説明できていないなと感じることがあったので補足話を書いておこうと思います。

好きなことを仕事に!だけでは難しい:

よく「好きなことで食べていく!」とかキャッチフレーズみますよね? ぼくは割りと好きなことを仕事で生活できていると思っているんですがゲーム業界で働いていたときに「ゲームが好きってだけだとこの業界で働き続けるのは難しいなー」と実感したということが伝えたかった主題です。

実際にゲーム業界で働く前は「好きのレベルが低いんじゃない?」という疑念が頭の片隅にあったのですが業界で働く内にその幻想は木っ端微塵に砕け散りました。 主に悪い方向で。

podcast内で補足してもらえましたが好きにもいろんな形があって、ゲームを作るのが好きなのか、作ったゲームを遊んでもらうのが好きなのか、ゲームをプレイするのが好きなのか…それぞれいろんな形の「好き」があります。 アニメや漫画、ゲームなどのエンターテイメント系はこれらの境目が曖昧なことが問題の1つだとぼくは考えていて、 そのときに「好き」だけではなく「楽しめる」という軸がないとうまくいかないのだと実体験から結論を出しました。

なんというかこの2つはどちらが上とかではなく車輪の両輪のようなものだと思っているというのが正直なところです。 「好き」という原動力が「楽しむ」というエンジンで加速エネルギーを得ていく…とでもいうのでしょうか? どちらかだけでは疲弊してしまい、人によっては好きが反転してしまうこともある…ということを伝えたかったのです。 説明ベタで申し訳ない。

Write Code EveryDayを4ヶ月してみた:

podcast中で語ろうと思ったままついつい忘れてしまったのですが実はぼくはいま現在毎日コードを書いているわけではないです。 というのも自分の課題として基礎的な技術力が不足しているという思いがあります。 その基礎的な技術力を向上させるためにはまず質の良いインプットが重要だと考えました。 ところが毎日ある程度とはいえコードを書いているとなかなかまとまった質の良いインプットを行うのが困難であるということに気づきました。

そこで意図的にインプットの質と量を担保するためにそれまで継続して書いていたコードを毎日書くのではなく、書けるときにだけ書くという方針に変更しました。 これはGithubの草を生やすことが主題になってしまっているように感じていたことも1つの理由です。 「イシューからはじめよ」でいうところの「犬の道」に自分が陥っていると感じたからです。 これはpodcast内でブログをただ書くだけでは難しい…といった発言にも共通している思いです。

結果はまだまだついてきていませんが、目的の部分がブレているとはまだ思っていないのでそのうちまた毎日コードを書く日々に戻ってくると思っています。 いまは充電期間のようなものだと考えて、しっかりと質の高い、あるいは高くなるようにインプットに専念したりしています。

ブログ執筆の話し、書いてるだけではうまくならない問題が難しすぎる:

この問題は多分ぼくにとってある種の転換点を迎えたからこそ発生しているのだと思っています。 昨年、期せずしてElastic Leadershipという書籍を紹介したところ変な形でバズることとなってしまいました。 そのときに「伝えたいことがしっかり伝わらない」という思いをしました。

ここが転換点だったのだろうと思います。 その瞬間からぼくは「ぼくだけのブログ」から「読者に伝えたいブログ」に変化していったのだと思います。 いわゆるコンテキストを共有している人からは好意的なコメントをいただきました。 一方、コンテキストが共有できていないと感じる方からは「コミットメント言語は日本人の文化にあわない、圧迫されてしまう」というコメントを沢山いただきました。

コミットメント言語は手段であって、目的ではないのですがそこがしっかりと伝えきれなかったなと今にしては思います。 バズっていたときは「それはチームの問題でコミットメント言語自体の問題ではない」と思っていたのですが コミットメント言語を手段として用いるその目的や目標をたしかに明確にしていなかったなと最近は考えることがあります。

先程もちらっと書きましたがそのことに気づいたとき「ぼくのブログを書くのはただ「犬の道」になってやしないだろうか?」という思いが頭をよぎりました。 そういう思いや考えから件の発言元である「ただ書くだけで上達するわけではないので難しい」という主旨にたどり着きます。

自分のスキルに不安があるので転職迷う問題:

概ね自分の考えはpodcastで語った通りなのですが一点だけうまく伝えられなかったと聞き直していた際に感じたことがあったので補足しておきます。 ぼくがpodcast内で「フリーランスを意識するほうがよい」という主旨の言葉を使っていますがこれは実際には正しくなく「自分の価値を常に意識する、そのための方法として転職やフリーランスを常日頃から意識すると良い」というのがぼくが考えていた思いに一番近い回答となります。

フリーランスになることそのものが重要なのではなく、「自分の価値を自分で見極め、知る」ことが肝要ということが伝えたかった全てです。 podcast内でも語っていますがぼくは自分の副業先の給与を時給換算でいただいています。 そして副業をしているときにふと自分の価値を客観視し、「ぼくの技術力はたったこれだけの価値しかないのだろうか?」と感じる結果となりました。

実際問題、副業先のスタートアップはそこまでお給与を支払えるわけではなく(フリーランスの人のほうがコミットメント率が高く重要だったとかの理由はある)ボク自身も契約当初はどれくらいコミットできるかわからなかったこともあり、納得の上で給与を決めたのですがそこには「これだけ高い給与もらって結果が出せなかったら怖いので低く見積もろう」という心理がありました。

結果から言うとそれは大きな間違いでぼくは自分の価値をもっと真剣に査定すべきだったのだと思います。 いまだにぼくは自分の価値の適正値がわからないです、ですがそれは自分の価値と向き合わないということと等価ではないとも思っています。

ぼくらは自身が持つ自由な時間を労働して成果を出すことで会社から給与をもらっています。 もちろん諸々の経費などは差し引かれているでしょうが、そこにはそれだけの価値があると会社に認められているわけです。 自分の価値を低く見積もるというのは自分自身を卑下して貶めているようなものだと最近は考えるようになりました。 その行いは自分と、自分の価値を認めてくれるひとたちに対して不義理で、あまりに失礼な行為ではないかとも思っています。

とはいえ、スキルがないと自分の価値を認めにくいのも真理です。 だからこそフリーランスや転職のように他人から見た評価を参考にするのが良いとぼくは思っているのです。 いまの自分のスキルセットはどのくらいの市場価値なのか?を意識することは十分価値があるし、またもし転職することになった際にも話のネタになります。 転職するしないは関係なく、自分の給与が実力に対して適切に評価されていない場合1つの提示する資料にもなります。

転職サービス側からすると迷惑千万な行為だと思いますが、市場価値を知るために転職サービスに登録しておくのは割りとコストパフォーマンスのよい施策でないかなと思っています。

出演してどうだった?

概ねいいたいことは言えたかなと感じています。 ビブリオバトルについては語れなかったので次回出演するか、自分のpodcastでやろうと思ってます 反省すべき点は多々あるのですがパーソナリティのお二方に助けていただいて非常によい体験をすることが出来たと思っています。

どうしても対話というベースや技術系の話しではないため、議論的というか話しが盛り上がってしまい時間が長くなってしまったのがpodcastというものの難しさを改めて実感しました。

どうしても1人だとうまく掘り下げられない内容もパーソナリティーの方がいるといい感じにまとめてくれたり、思わぬ方向からの意見をいただいて改めて考えるきっかけになるなと感じました。

ぼくはネット弁慶の割に打たれ弱いので基本的にあまりエゴサをしないようにしているのですがついつい誘惑に負けてしまいTwitter上で検索してしまいました。 いろんな意見やぼくの意見の補足、共感、反論諸々読んでいて自分の発した一言が与える影響がこんなにあるのかと新鮮な驚きを得ています。 そして改めて自分のためのpodcastをやっていこうと思いを新たにしました。

いつになるかはわからないけども自分の中でこのくらいの時期に行いたいなという獏っとした思いがあるのでリリースしたらTwitterやブログで報告させてもらおうと思います。 あと、今回ヘッドフォンから自分の声が聞こえてきたり、思った以上に早口だったのでしがないラジオにリベンジしたいですね!

プロを目指す人のためのRuby入門

2017年中に読了する予定だったがゼノブレイド2やってたら諸々あって2週間遅れで読了した。

対象:

本著の冒頭でも語られている通りプログラミングの未経験者がこの本を読了するのはかなり根気がいることだろうと思う。 プログラミング初級者(初心者でない)が次のステップへ行こうとするときに読むべき本であると感じた。 一方で手元にあって困ることがない本だとも実感した。 他の言語である程度プログラムを書くことが出来る、あるいは最低限if文、for/while文、関数がわかる人が対象としてボリュームゾーンであるように思う。

感想:

結論からいってしまうと個人、というよりは業務でRubyを扱うことがあるなら1冊教育用途で置いていてよい書籍だ。

本著を手に取るきっかけとなったのが目次の例題が非常に適切なレベルで設定されているように感じたからだが結果振り返ってみるとそれは正しかったように思う。 4章の繰り返し制御や配列、ブロックなどの概念や使い方ハマりどころは以前Railsでアプリを作っていた際に「よくわかっていないがサンプルとして書かれている通りにかけば動く」というものを十分に解決してくれたし、5章のハッシュやシンボルを理解するも大いに不勉強な知識を補完してくれた。 ぼくの今までの主言語がPHPだったこともあり、なにがRubyとその他の言語で違うのか?が書かれているのは非常にわかりやすく、またハマりどころを事前に教えてもらえたと実感している。

クロージャーの振る舞いの違いやサンプルコードでなく実務でよく見かけるような書かれ方をしたコードの説明などがされており、まさしく入門として正しい1冊だと感じた。

カバーに「Railsをやる前に、Rubyを知ろう」という一語があるが自分が如何にRubyを知ることなく、極端な言い方をしてしまえば「舐めていた」かを直視することとなった。 まだまだyieldやProc、それにシンボル。 そしてなによりもクラスのPublic/Private/Protectedの概念はまだまだ自分のなかにしっかりと根づいていないと感じている。

そうそう、本著ではRubyらしいコードの書き方が乗っていることがある。 Rubyにはいくつもの書き方や実装の仕方があり、独学の初心者や初級者は相談する相手がいないことが多いため、どの実装を選択するのがベターかわからず戸惑うこともあると思う。 会社であれば先輩社員や詳しいひとにレビューをお願いすればいいが、独学ではなかなか難しい。 全体的な総量としては少ないが本著にはその点について言及されているところが何箇所かあり、そうすることの意図も非常に明確に書かれている。 今後迷ったときにどれを選べばいいのかの判断基準になりそうだと感じた。

もしあなたが他言語のプログラミング経験はあるが、Railsを覚えたいと思うのなら最初に手にとって読む1冊として最適だろう。 恐らく幾つかの内容についてRuby独特の解釈で戸惑うことや思考が追いつかないことがあると思うが、それがRubyという世界の流儀なのだろうと思う。 今後の目標としては以前挫折したRailsチュートリアルやPerfect Ruby on Railsなどを写経していわゆる「Rubyらしい」書き方を身に着けていこうと思っている。

2018年の抱負

今週のお題「2018年の抱負」

まだ第1週なのでセーフだろうという自分ルールを適用したい。

具体的には3つ。

英語のアウトプットをする

インプットは最悪1人でも出来るけど喋るのは1人じゃ無理なので英会話教室でも行ってみようと思ってる。 そこでまず苦手意識を克服することを目標、目的は外国人に喋りかけられてもネガティブに感じなくなるようにする。 流暢に喋れなくてもいいし、単語が出てこなくてもいいけど今のぼくは伝えることに対して非常に腰が引けている状態なのでまずはそこの意識改革が大事だと思う。

あと最近感じたことなのだけどアジア圏の人が英語で話しかけられても身構えることが少ない(ネイティブでなければ)のだけど白人黒人だと身構える事が多いのは多分意識の問題でここを乗り越えれることができたらある程度喋れるようになりそうだなと思ったりなんかした。

英語をやっていくぞ!

インプットの量と質を保つ

実質的には昨年末からだけど積ん読をカンバンで管理する、ということを行っている。 量に関してはこれで担保がほぼされているので質をどうやって保つか?が今年の課題だと考えている。 読むだけでは身につかないのでなにかしらの改善策が必要、そこを考えて是正していく。

欧米(イタリア)に旅行する

ぼくは小学生の頃にグアムにいったきり外国にいったことがない。 ところがイタリア、特にヴェネツイアには行きたいと常々思っていたが実行していないし結婚したりすることが今後あるかもしれない(特にいまそのような予定も相手もいないが) ということでやるぞ!と宣言することで自分を追い込もうと思う。 ちょうど?妹夫婦がドイツにいるのでついでに挨拶してこれたらいいなと思う。

できれば夏くらいが理想。

あれ?Podcastは???

これはすでにやることが決まっている決定事項なので抱負ではない。

以上。 とりあえず旅行はスケジュールやらパスポートやら事前に用意する必要があるので早め早めに対応していこうと思う。

しがないラジオにゲスト出演しました

去年末のAdvent Calendarに参加していたしがないラジオにゲスト出演しました。 収録日は2017/12/30、大晦日ではない! ちなみにすでに公開されているep30は31日大晦日に収録されているとのことです。

shiganai.org

出演した経緯はこちら↓

2018年にぼくもpodcastやってみようかなーとか思ってたらまさかの2017年中にPodcastにゲスト出演することになってました。 ……どうしてこうなった。

以下、初めてのPodcast収録を経た反省点や振り返りなどをば。

結論:

まずは結論から。 ぼくの準備不足が目立ったなーというのが実感としてまずあります。

反省点は後述していますがなによりも喋るのがあまりにも聞き苦しくなってしまったこと、この1点につきます。 これは今回の収録が少々イレギュラーな収録の仕方をしてしまったために起こったことなのですが 収録中に「ああこの回は聞きにくい!というフィードバックが来てしまうだろうなあ…」と話しながら考えていたのを覚えています。 大変申し訳ない気持ちと次回があればリベンジしたいという気持ちです。

次回は自己紹介を5分で終わらせて本編にTech系ネタ、真の本編であるAfter Showでキモオタトークをやっていきたいですね! というわけでリスナー諸氏に対しましては大変お耳汚しをしてしまう回となってしまいましたが 次回リベンジの機会をいただければと思います、なにとぞ〜。

振り返り:

パーソナリティつよい!!!問題

まず良かった点のなかでもやはりここに言及せねば!と思ったのがパーソナリティーのお二人の会話術が巧みだったことでしょう。 普段聞いているpodcast上でのお二人の掛け合いそのままで進行したこともあり、開始直前は緊張していたものの割りと話し始めるとエンジンが徐々にかかってストレスなく話し始めれたのが印象に残ってます。 さすがに1年に渡ってPodcastをやってきただけのことがあるな!という印象を持ちました。

パーソナリティーのやっていきちからがすごい

経緯をみてもわかる通り、お二人のフットワークの軽さ、回転の速さはさすが!と思わざるを得ませんでした。 お誘いいただくことがなければぼくはゲスト出演することはなかったんじゃないかなーと思います。 ちょうどPodcastやってみたい!と自身でも思っていたのでタイミング良く声をかけてもらったかなという感じです。

直接フィードバック

気恥ずかしい面もありますが @zucky_17 さんからブログのエントリに関するフィードバックを直接いただくことができたのは非常に良かったです。 これはpodcastだから、というわけではないのかもしれませんがなんというか自分がコンプレックスだと思っていたことが誰かにとっての楽しむ一助になっていたといえばかしこまりすぎていますが ぼくの文章を楽しんでくれたというフィードバックを対面で言ってもらえたのが嬉しくて「ブログ書いててよかったなー」と思いました。 元々ボクはどちらかというと自分のためにブログを書いていた人間だったので純粋に喜ばしい出来事を胸に秘めて2017年を締めることが出来ました。

パーソナリティーのお二人がよく「フィードバックまってまーす!」と仰ってますが本当の意味であの言葉の深さというか怖さと楽しさを実感することが出来ました。 是非とも皆さん、フィードバックをお待ちしております。 ……ぼくの出演回に関して言うならできるだけマサカリ風味は避けていただけると嬉しいかなって。

音声メディアならではの振り返り

pupupopo88.hatenablog.com

軽い気持ちで #しがないラジオ に出演したら畑に埋まりたくなったお話でも書かれていましたが取り返しがつかないメディアだなというのを実感しました。 ブログは書いてから構成を変えたり、文章の言い回しや補足を簡単に添削できます。 その点において文章というのは非常に凶悪なアドバンテージを要しています。 ところが音声メディア、あるいは動画メディアというのはこの補足部分などの編集が出来ません。 多少の修正を書けることは出来ますが基本的に自明のことだろうと省略してしまったことや説明を省いてしまったがために本来の意味を捻じ曲げてしまいかねない表現をしてしまった箇所がいくつかあったなと収録後に反省しました。

これはエピソードが公開されてから補足点としてまた別に書き出したいと思います。 というかそうしないとうまく意図が伝えられていないと思います。

声の大きさ問題

↑の音声メディアならでは問題と若干かぶるのですが声の大きさというのが今回Podcastに出演して一番困ったというかどうすれば正解なのか?がわからず、結局最後までわからないまま完走してしまいました。

このあたりは数をこなす内に自分の声は音声が拾いにくい、拾いやすいなどの感覚値が定まるのかなーと思いました。 最悪編集とかでもどうにかなるのかもしれないですが、あまりこういう部分で編集はしたくない(ライブ感が薄れてしまう)と個人的に思っているので今回収録にあたり公開されたエピソードを聞いてみて改めて振り返りたいと思います。

反省点:

全体的に反省点が多いのですがその中でも特に「これはよくなかったなー」と感じたものをピックアップしました。 もしPodcastをやろう!あるいはゲスト出演することになったぜ!というかたは煮るなり焼くなり好きにしてくだされ。

snob問題

ぼくのことです。 「知識・教養をひけらかす見栄張りの気取り屋(Wikipedia引用)」という実にインターネッツインターネッツした性格をぼくはしていると自覚しておりいくつかのトピックにおいてその手の発言をしてしまっています。 これは現実問題としてあまりよくない、とは思っているのですが如何せんなかなか直すのが難航している問題でもあり、 リスナーの方が不快に感じるかもしれないという点や自分のコンテンツでもない場所でこの手の発言をしてしまうというのはよくなかったなと思っています。

小馬鹿にしたような発言があったらこのゲストはドラえもんに出てくるスネ夫みたいな嫌なやつなんだなと脳内変換してください。 だいたいあってます。 次回ゲスト出演時には気をつけたいと思います。

要点をまとめる能力が欲しい問題

元々ぼくは文章を書くのも喋るのも苦手でして、いわゆる「要点をまとめる」ことが出来ないタイプの人間です。 「要は〜」って言いながら全然要約出来てない人が身近にいますよね?ぼくはそのタイプです。

なので喋りながら考えていることが常であり、その結果伝えたかったことがズレてしまう。 あるいはその逆で聞く側のことを一切考えずに自分の主張だけを誇示してしまう傾向があります。

そのあたりかなりパーソナリティーのお二人には助けていただいたなと感じています。 特にgamiさんは普段からそのスキルを遺憾なく発揮されていて安心感がありました。 そのおかげもあってあまり緊張せずに喋ることが出来たなと思っています、ありがとう!

ヘッドフォンの準備不足問題

まず、今回 @zucky_17 さんが帰省されるタイミングでわざわざ京都に立ち寄っていただいての収録となった、通常の録音回と異なる方法で録音したというのが大きなポイントだったと思っています。

普段からヘッドフォンは使用しているので用意していたのですが、ぼくのMacBook ProをHigh Sierraにしたせいかここ最近BlueToothバイスへの接続が微妙な感じになっていることを忘れてBoseノイズキャンセリングヘッドフォンを持参してしまいました。 結果からいうと(今回は)問題なく接続できたため事なきを得ましたが、ここ最近微妙な接続状況だったことを認識していたのについつい無線式のヘッドフォンを持っていってしまい収録当日に慌ててしまいました。 事前に有線と無線両方を持っていくようにしたほうが良かったなと感じました。

次回からはiPhoneについている付属のイヤフォンを持っていくようにしたいと思います。 無線系のデバイスは接続トラブルがあったときのことを考えて有線式を予め用意するなどしたほうが無難ですね。 どちらをメインで使うのか?はさておきトラブルシューティングとしてあるほうがよいですね。

会場&Wifi問題

年末年始だったこともあり、軒並み会議室のレンタルやコワーキングスペースがお休み状態に……。 安定した回線と長時間話していても大丈夫な会場を用意するのは重要だなと感じました。 当初2時間もしゃべれないだろうと高をくくっていたのですが、トイレ休憩を少し挟んだだけでほぼ4時間くらいぶっ通しで喋ってました。 これはかなり想定外でした、もし貸会議室などを使う場合は延長できるかどうかを事前に確かめたほうがいいでしょう。

さらっと終わらせられなかった問題:

いくつかのトピックでShow Noteに「○○についてさらっと語る」とか書いてたのにめっちゃ語ってたり、ネタ枠として話すことがなくなったら話そうと思ってたトピックがめちゃくちゃ長くなってしまったりと想定外のことが多々発生しました。

ネタ枠はまだしも、サラッと話すところに時間がかかってしまっていたのは反省ポイントとして結構大きいかなと思っています。 「リスナーはそんなくだらないこと求めてないだろー、というかぼくならさっさと切り上げて欲しいって思う。」とか収録後の電車で1人凹んでました。 このあたりもうちょっと会話力というかサラッと終わらせれるようになりたいですね。 そう考えると #rebuildfm や #ajitofm のすごさがよくわかります。

まとめ:

いろいろ書いてますがまだ公開されていないということもありますし あまり書いてしまうとネタバレしてしまうのでこのあたりで止めておきます。

一応ep.30 楽しい2018年の強気な目標でぼくがゲスト出演することに言及しているのでこれくらいなら書いても大丈夫かなーという線を攻めつつ、ネタバレしない程度に抑えました。

エピソードが公開されたら各トピックの補足を書いて一区切りとしようかなと思います。

webdesign-manga.com

湊川さんが書かれている通り、ひょんなことから憧れのPodcast出演を果たしてしまいました。 どうやらこのエントリからゲストが出演決定しているという話しをTwitterPodcast内でお聞きしたので割りと期待しています。 個人的には「お、世界のMatzがしがないラジオ参戦か!」と勝手な妄想をたくましくしているので皆さんも期待して待っていましょう。 (実際に誰が出るとか本当に知らないのでなんでも言えてしまうメソッド)

Kyoto.rb Meetup 20171216

kyotorb.doorkeeper.jp

初参加してきました。

目的:

  • Rubyの理解度をあげる

目標:

  • 1章の写経を完了
  • 2章の写経を完了

LT発表:

SFCをむやみに使うべきではない in Rails(Single File Component)

発表者: shantti_y さん

HTML/CSS/JavaScriptがvueファイル内で完結している状態。 影響がそのコンポーネントに閉じ込められるのがいい。 LTを英語でしていてかっこよかった。

プロRuby

文字列の比較:

↓がよくわからない、文字に当てられている番号で比較している?という質問を参加者のかたにしてみた。

'a' < 'b' # true わかる
'a' < 'A' # false わからない
'a' > 'A' # もっとわからない

'abc' < 'def'  # true  わかる
'abc' < 'ab'   # false ?アスキーコードの合計値で比較しているわけでもない?
'abc' < 'abcd' # true  ???もしかして文字列の長さか?

'あいうえお' < 'かきくけこ' # true

プロRuby本にはさらっと書かれて説明がなかったのでこういうときコミュニティーで聞けるひとがいるのは心強いですね。

アスキーコードで比較されているんじゃないかな?

とのことだったのでググってみた。

Ruby リファレンス <, <=, >, >= (String)

文字列の順序は、バイト列の単純な比較によります。"α" < "あ"は、文字コードUTF-8なら結果はtrueShift_JISならfalseになります。

とあるのでバイト列での比較になっていた。 でもこんなトリッキーなコード書くことがあるのだろうか?

多分だがこの比較が発生し得るコードがレビューで来たらぼくならリジェクトすると思う。 少なくとも動作の予測が立ちにくいので別の実装を求めるか完全比較以外はリジェクトするかな。 入力される値がある程度決まっているなら配列とかに持たせてチェックさせる…みたいな実装する。

反省点:

いろいろ雑談やLTに対するコードの指摘などなどを行っていたらすぐに時間がなくなってしまったので 目標だった2章の写経完了まではいけていない。 もっと集中すべきだったか…。

追記:

著者の id:JunichiIto さんからフィードバックを受けていたのですがブログ側に反映し忘れていたので追記です(いまさら)

qiita.com

こちらの記事で捕捉されている内容が解答なのですが最終的にチェリー本を全て読了したあとでこのブログの内容を読み返したところ 気づくきっかけのようなものがチェリー本のなかにありました(具体的にどこのページだったかは忘れた) なのでとりあえずわからなかったところはメモして一読するのをオススメします。 そのうえでまだわからなかったらブログとかに書くとRubyチョットデキルひとたちが心優しく教えてくれると思います!