ものは柴田さんの一緒でサイズ違い。(参考: Privaucks の覗き見防止フィルターを買った, おやこで干支つむ を買った - HsbtDiary(2017-04-19) )
最初は柴田さんが15インチにするから余った13インチのを借りようという話だったのだけど、タッチバーモデル(というかLate 2016)はベゼルを含めたディスプレイのサイズが一回り小さくなっているようで大きさがまったく合わなかった。
さて、実際つけてみてどうかというと、正面絡みてもディスプレイの品質が何段階か下がったような感じになってしまうのが残念。あとは、プレゼンのときはちょっと気をつけないといけないなぁと思ったり。
とはいえ、実際に外で開かざるおえないことはあるので、割り切ってやっていこう。
タイトルには「ほめる」とあるがそれだけではなく、相手を「認める」こと（本書のなかでは「アクノレッジメント」と言われている）によってより高い成果を出せるように導いていくという話。
コーチングの本としては特に目新しい内容ではなかったが、いくつか良いと思ったフレーズがあったので残しておく。
「自己説得」した行動は、「他己説得」された行動よりも現実化する可能性が高いといわれています。
コーチングとはという文脈の中での一文。自己説得を促すのがコーチングであるというのは納得。
「あなたがそこに存在していることに気が付いている」というメッセージのすべて、つまりアクノレッジメントが「生き残れるか？」という不安を払拭することにつがります。
自分や同僚やコミュニティの仲間を思い浮かべて色々考えることがあった。
ほめることは技術です。
恥ずかしさとかいろいろあるけど、技術だと言い切られると、学習して、実践すればよいと考えられるので良かった。
I（アイ） で承認するというのは、相手の行動、あるいは存在そのものが、相手に対してどのような影響を与えているのかを言葉にして伝えることを指します。
客観的に認めるよりも、主観で認めてあげることが相手に与える影響が大きいし、認めるほうも楽という感じ。たしかに。
向こうが投げたボールに対して、そのボールをすぐに返す、というのは相手に対するアクノレッジメントとなります。逆にボールをいつまでも返さないでいると、その程度にしか自分のことを思っていないのだと思われかねません。
はい…がんばります。
相談する、教えてもらうは、聞く側が「下」になりますから、年上の人にとっても受け取りやすいアクノレッジメントになります。
年上の部下を褒めることの難しさ（褒める側がどうしても上に感じさせるため）から、意見を求めることもアクノレッジメントなんだよという話。上下に関係なく、相手に合わせて使えるといいなと思った。
上司に対する不満の多くは〜つまり、本人の主観では業績は上げているし、それ相応の仕事をしているのにアクノレッジメントが少ないのはなぜなんだということです。
そうならないようにしていかないとな。
4月に入社した新卒7期生ランチに@june29と行ってきた。@june29と@hsbtと@udzuraと私の不思議な関係（？）や、その背景にあるコミュニティの話をしてたら、あっという間に1時間が経っていた。7期生の話をあまり聞けなかったので、次回はもっとみんなのことを聞きたいな。
いろいろなアクシデントを乗り越えて調整をしてくれた@endo_f181くん ありがとう！
部長と若者と一緒に庄やに行って一回休み。
最近色々あったので誘ってもらえて嬉しかったです。
帰り際にケンタロマグマとロベ大使が現れて庄やを制圧しようとする様子を横目に帰宅。お疲れ様でした。
勝手に名前にシンパシーを感じてるしゅー くりーむ(@syu_cream)さん | Twitterさんの本を読んだ。
技術書典にはいけなかったのでKindleで。(なんと今ならUnlimitedで読める！)
言語処理系の仕組みについての知識が皆無なので、前半はかなり難しかったし理解はできてない…。最後のGCの話は、最近なんとかRuby会議等でよくGCの話を聞くので「ほー」という感じで楽しむことはできた。
最後の「バイナリを手で描いてみましょう」は完全に振り切りモードでとっても素晴らしく、こういうことをちゃんと書ける人はすごいなぁと思うばかり。
奥さんがサンキューマートのポプテピピックコラボグッズが欲しいというのでお出かけ。
実は木曜にも行ってきたんだけど、そのときはなかったボールペン（？）が入荷しているという情報を入手したらしく、なんど2回目の訪問である…
土日にいったのは久しぶりだったけど、相変わらず人が多くて大変。ペットショップで100万超え(!?)の子猫を見たり、オムライスを食べたりして帰宅。おつかれさまでした。
本を読んだらまとめる癖をつけよう…その第一弾。
ストーリーには構造があるという話から始まる。
本書では、ストーリーの構造を「ナラティブアーク（導入からクライマックスまで盛り上げていき、最後に落とすという起伏を表現する曲線）」と、それに沿った「7つのフェーズ」に分類して説明している。
ナラティブアークに沿ってストーリーを作ることは、ストーリーに起伏をつけることになる。これによって、ユーザにプロダクトを強く印象づけることができるし、オチやエンディングを設計することでクリフハンガー（ユーザの気持ちが最高潮に高まったところから、一気に落とされて印象に残らない、あるいはネガティブな印象を残すこと）を避ける効果があるとのこと。身近なプロダクトで今すぐ考えたほうがいいと感じた。(参考: ピーク・エンドの法則 - Wikipedia )
また、筆者による実際の映画やプロダクトを分析した実例がたくさん載っているので、実際にやってみるときのイメージがつかみやすいのも良いと思う。
実際のプロダクト（特に既に世に出ているもの）のストーリーを収集し、マッピングしようと思うと超巨大なマップになってしまって、「そうだね。さて次は？」となってしまった経験はあるだろうか？（私はたくさんある…）
他の書籍でも様々な手法が提案されているが、本書では以下の3つに分類することを紹介しいている。
プロダクトのフェースや目的、あるいはチームの状況に合わせて、最初にユーザの心をつかむことに注力したいのか、ユーザのある特定の問題を解決してファンになってもらうことに注力したいのか、あるいはユーザも気づいていない潜在的な欲求を根本的に解決したいのか。どれに注力するのかが明確になっているのであれば、自分たちに必要な部分を同じフレームワークでマッピングすることができるのは、共通言語という意味でも勝ちがあるように思う。
プロダクトを使うユーザのエンゲージメントを獲得したいなら、デザインスべきはシステムはなく、人間の体験です。システムは複雑です。しかし人間の体験は1本の線です。体験は時間の流れに沿ってしか起こりません。
最後の章にある文章が印象に残っている。「複雑だから」「たくさんの機能があるから」という言葉に負けずに、ユーザの体験をデザインしなければいけないし、それは人それぞれではあるけど時系列に並ぶ一本の線になる。
毎年恒例のアレ。
今年はなぜか見学枠という謎の枠も用意されていて、いよいよほんとによくわからなくなってきた。
この時期になると偉い人が「練習」や「稽古」などの理由でいなくなることがあるが、それ以外は基本的に秘密裏に物事が進むので、ほんとに社内の人間は何も知らないまま当日を迎えることになる。
準備してた皆さんお疲れ様でした ＆ 楽しいひとときをありがとうございました。
以下記録や素材など。
ケンタロマグマの衣装を担当いたしました。(全身なかったので袖からこっそり) #ペパボ新卒 pic.twitter.com/e8OxaMpyQW
— MiG (@huiyeop) 2017年4月12日
自分のパート終わりました。
— 宇賀神wutang (@ugazin) 2017年4月12日
今日のために作った楽曲はこちらで公開してます。https://t.co/W8aGOmlksA#ペパボ新卒
このWeb日記にはsitemapを出力する機能が一切なかったので、 kjvarga/sitemap_generator を使ってsitemapを作るようにしていた。
URLを組み立てるために、DSLの中でhelperをincludeしたかったんだけどうまくいかなくて悩ましい。Rails力の低まりを感じる…
pragprogの積読がたまるいっぽうなので、少しずつ読んでいくという気持ちを高めて取り組み始めた。帰りの電車で「What Is RxJS?」あたりまで。
Callback、Promise、Event Emitterのそれぞれの課題と、Reactive Programmingはどういうアプローチなのかが整理されていて導入としてはとてもよかった。
で一回休み。
聞いていると、小学校低学年まではレベルに合った曲やパートで楽しく、小学校高学年までが背伸びしたい感じ、中学校まで続けてるとさすがにレベルが上って安定してる、という印象。
まだまだ続けたいそうなので、来年度も頑張ってほしいところ。
昨日のWeb日記で、ConoHaの母艦作りなおすのだるいという話を書いたら、同僚が VPS（ConoHa）を docker-machine で操作する - kumak1’s blog というのを書いてくれた。便利そう。
このWeb日記は kenchan/tdnm: tdnm is simple weblog tool という自作のRailsアプリで、さすがにそろそろhttps化しないと恥ずかしいのでついでにDocker化もしてみた。
RailsアプリのDocker化については、jokerさんのQiita が参考になると思う。
最初は開発環境もDockerにしようかと思っていたのだけど、Gemfile にpath指定したいときに困る＆Dockerの旨味がなくなると感じたので、開発はローカルでやることにした。(2017年をキャッチアップする 三種の神器 / ghq_gem-src_and_bundler // Speaker Deck)
本番環境のイメージについては、静的ファイルの扱いを一旦おいておいて、bundle installとrails assets:precompileをしたイメージを作ることにした。
ベースのイメージは ruby:2.4-alpine にして、必要な依存関係をとかをバシバシいれていく。
bundle install --deployment オプション便利bundle installとgccやmake等のインストールをワンラインでやるとイメージは小さくなるが、nativeビルドに失敗した時にやり直しに時間かかるというあたりが発見だろうか。
現時点で最終的なイメージが130MBくらい。
https化は docker で全自動 Let's encrypt - Qiita がめちゃくちゃ便利だった。
特に何も考えなくてもローカルでのオレオレ証明書での検証と、本番でのLet's encryptでの運用ができる。
一回ハマったのは、FORCE_RENEWオプションをつけたまま本番で何回かビルドしなおしたせいでLet's encrypt側の制限で証明書の取得が失敗するようになってしまったところ。たまたま過去のコンテナを雑に消したあとだったのでめっちゃ困った…結局、Railsを80番で直接出すことで1週間ほどをしのいだ。
ここはめっちゃ雑にやっている。dockerだけをインストールしたVMをConoHaに立てていて、その中に本番用のdocker-compose.ymlがある。
デプロイは、瞬断しても困らないのでイメージをpullしてrestartという感じ。
Docker Cloud使ってみたかったんだけど、母艦をArch Linuxで立ててしまったのでサポート外だと言われて使えなかった…Ubuntuで作り直そうかな…
まだ特に何もやってないので、今壊れると何日か分のWeb日記消失することになる。これから考える。
先月から少しずつDocker化、Ruby2.4化、https化を進めてみた。モダンな感じには程遠いが、実際自分で試してみると辛いポイントや工夫のしどころがわかって勉強になった。
昼前くらいに起きてお昼を食べて、息子が3時から公園で友達と約束しているからというので引率。
ポケモン交換をしたいとのことだったが、時間になっても友達はこなかったので別の子と1時間くらい遊んでおしまい。
公園行くだけだったら勝手に行かせてるんだけど、DS持っていくとなるとまだ心配なので一応ついていっている。他の家はこのあたりどうしてるのかなぁ。友達の家に持っていくなら全然気にしないけど、外だとちょっと心配。
星さん(@glover) と久しぶりにいろいろ話して、ECに来てから感じていた課題や、やらないことを決めようということについて、たぶん1時間くらい話していた。
見えるものが多くなると気が散ってしまうことが増えたり、自分のほうがうまくやれると思いこんで手を出してしまうことが多くなりがちなので、定期的にやってることや、続けるべきかどうかというのを見直さないといけない。
たくさん面白いお話が聞けてよかった。また、正攻法では難しいと感じていた機能やアプローチについてヒントを見つけられたので収穫がとっても多かった。
カラーミーショップのお客様は「インターネットで何かを売っている」という以上の共通点はないので、個別のカスタマイズというのはなかなか難しい。ただ、その課題と解決方法を抽象化して機能として提供することで、より多くの価値が生み出せるというのが、こういうサービスに関わっている醍醐味とも言えるだろう。
汎用的な機能と個別のカスタマイズ、これを両立できるようにアーキテクチャと機能を練っていく。やっていくしかない！
春は出会いと別れの季節。今後のご活躍をお祈り申し上げます！
庄やの二階の治安が壊滅していたし、終電ダッシュして辛かった…
コードは https://github.com/WordPress/WordPress/blob/96b2923e625606aa174f3a2dc845e5483571dccd/wp-includes/pluggable.php#L2158 のあたり。
なんてことはないシンプルな実装。random_passwordフィルターはコアでは登録されていないようなので、このfilterを加えるとパスワードの生成ロジックをいろいろいじれるっぽい。
ランダムなパスワードを雑に生成して、それと強度と一緒にユーザに提示するというのは確かによいロジックのように思った。ついついちゃんと文字種が入っているかとかチェックしたくなってしまうんだけど、強度を見せておけばバリデーション自体はゆるくしておいてもいいのかもな、と。
5Xに降ってきた。最近すこぶる調子が悪いので安定してくれるといいな。周りでは文鎮化してる人も増えてきたので毎日ドキドキしてる。
itopoidさんが盛り上がっている様子がよかった。中村氏の生活レベルの高さがやばい。京都行きたい。
メルカリのA/Bテストフレームワークの話( mercari/siberi-android: A/B testing library for Android )と、iPhoneは（？）振るとデバッグモードに入るというのが面白かった。モバイルアプリ全然わからんのでまずいなーと毎回聞きながら思う。
大江戸Ruby会議06 という素晴らしい会に参加してきたので感想等。
Docker時代の分散RSpec環境の作り方 // Speaker Deck
起床に微妙に失敗したので途中から。
jokerさんの新作の紹介。テストの分散実行は、以下の3点がポイントだと考えている。
それらの課題について、まずはDockerを前提とすることでポータビリティを確保。その上で、ECS・スポットインスタンス・S3をうまく利用することによって、分散ルールを単純にした上で妥当な金額の金で殴るという発想が面白かった。
My Open Source Journey // Speaker Deck
3月から恵比寿に住むC社のjuanitoさん。
自身がどのようにOSS開発とか関わってきたのかを踏まえて、4つのフェーズ（？）においてどのように振る舞うとよいか・何を気をつけるべきかというのがとても参考になった。
また仕事とOSSについて、オープンにできるところを見つけて積極的にやっていくことは価値があり、今の自分にも求められているところだなと強く感じたのでやっていこう。
shugo/oedo06: Slides for oedo06
(宇宙の均衡のために)Rubyでエディタを作っていて、プレゼンも自作エディタのプラグインという圧倒的な実装力を目の当たりに。
自分がほしいと思ったものをすぐに手を動かして作り、その過程でRubyの知らなかった機能を見つけたり、処理系への改善提案までやれるという、圧倒的で理想的な開発だなと強く感じた。
基調講演のsorahさんが産まれるまでのRubyの歴史を掘り起こすということだったが、初期のRubyの文法は今のものはかなり違っていたというのがとても興味深かった。
今の文法になった時期や、コミッタ陣がMLに現れた時期など、こういう機会でないと知ることができない歴史ばかりで大満足。
また、yuguiさんの以下のツイートはとても考えさせられた。
我々のソフトウェア考古学にはメールアーカイブは重要な道具だが、slackは次世代にそういったものを残してくれるようになるであろうか
— Yuki Yugui Sonoda (@yugui) 2017年3月20日
Rubyに型を入れるために「何を犠牲にするのか」というのを、理想の型システムから考えて落としところを見つけていく過程がとてもおもしろかった。
とても丁寧に説明してくださっていたので、自分でも型がちょっとわかった気になってしまった。
その中でも、「anyを導入した上で型を絶対に書かないということは、anyの広がりをとめることができない」という話は、それこそ言われればその通りなんだけどなるほど～と口に出しそうになってしまった。
esaとRubyistとわたし // Speaker Deck
pplog、いつもお世話になっています！
デザイナーとしてというよりは、PdMとしてとても大事なことがたくさん詰まっているように感じて、資料公開されたら社の人たちに配って歩きたい。
こういった改善が日々のRubyの速度改善を支えてると思うと「本当にありがとうございます」という気持ちが溢れてくる。
Rationalは日常的には使わない側の人なので、直接の恩恵は受けられないとのことだったが、改善のプロセスを含めて勉強になった。
超難問早押しクイズ大会。難しすぎるけど、コミッタ陣が唸る姿を眺めて楽しかったw
このために作ったシステムも面白そうだ。asakusarb/hayaoshi: 大江戸Ruby会議06の『フルタイムコミッター大戦』で使用した早押しクイズアプリ
thats-done-2017-03-20-oedork06-ujihisa - Google スライド
タイトルと導入の通りかなりのカオス。Cooking for Geeks と 発酵の技法 はやっぱり読まねばなと思った。
会場に thincaさん がいたそうなので、いつも一方的にお世話になっているとご挨拶したかった…次の機会に。
笹田さんのドヤリングタイム。
Cは全くかけないといってもいいので理解が追いつかないところがおおいけど、いつか少しはわかるようになりたいな。
内輪のノリの中にしっかりとしたメッセージがあって、内容だけじゃなくてそのスタイルにもとても感動した。
育成においては、「密度を上げて時間でなぐる」というのは本当にそのとおりだと強く感じたので、身近なところからはじめていこうと思った。
あと、マジで優秀な若者たちは本当にやばいという危機感が強く残った…
Keynote (Oedo RubyKaigi 06) // Speaker Deck
sorah氏の自慢話。rosylilly氏の話と合わせて聞くことで、ただの自慢ではなくて、正しく半生のふりかえりになったように思った。
インターネットを始める話、すごすぎて振り切られたけど応援していますｗ
生活発表会という大江戸Ruby会議のコンセプト（？）はとても最高で、いつも最高の発表が聞けてありがとうございます。
そう。生活の中でこれだけのことをやっている人たちがいるってのをたまに忘れてしまうことがあるので、自分も生活発表できるような生活をしていかないとなと参加する度に思う。
去年くらいからいろいろやって軸がなくなってきたり、なんか文章やコードを継続的に書くこともできていないので、このあたりで一回リセットしてやりなおしていくぞ！
毎回ですが、こんな素晴らしい会をひらいてくれているAsakusa.rbのみなさんありがとうございました！
ゲームで！ カードゲームで！ カプ・コケコ キャンペーン開催！ | ポケットモンスターオフィシャルサイト
息子と一緒にセブンイレブンにいって受け取ってきた。セブンスポット限定だと勘違いしていて、買い物の帰りというとくに買うものもない状態で入店してしばらく居座ってしまった。
開かずの間とは言わないけど、それなりに雑多なものを投げ込んでいる収納を整理して、いくつかメルカリに出したりしていた。
はじめて自分で買ったPC（Dynabook SSの最初の方のやつ）とか、Qiの充電器とかいろいろ。
無接点充電また盛り上がってこないかなぁ。
前回の記録がない…多分2ヶ月くらいかなぁ。
家でぐっさんの応援をしてから、今回は一人で行ってきた。来月改装があるらしく、息子はどうするかなぁという感じ。
去年の年末パーティーのくじ引きで当たったホームベーカリー が届いたのでパンを焼いている。
自宅でパン焼く場合、パン切り包丁や、パンを同じ厚さに切るための器具が必要ということで、それらはニトリで購入した。器具については、おそらく同じものがamazonでも売っていて、使い勝手については大体レビューにある通りの感想。
焼き立てのパンが家で食べれるの、思っていたよりもだいぶよい体験なのとでどんどん使っていこうと思う。
昨年のふりかえりは 2015ふりかえり の通り。 今年は目標については あけおめ | けんちゃんくんさんの Web日記 にあるように手帳に書いていました。
今年は年始から ハンドメイド・手作り作品の通販、販売 tetote(テトテ) の技術支援をやっていたけれど、初めてのPythonで苦労していたような記憶がうっすらとあります。 Railsだったらこうするってのがなかなかすっきり書けなくてもやもやしながら、そういう面はチャンスだったにも関わらず、コードの量も質も今ひとつでした。 Githubの芝は去年より白い…
9月に EC事業部のCTLに就任 してからは、まずはキャッチアップと組織作りで3ヶ月が終わってしまったような感覚です。(ある程度は技術面も手をだせてはいるけど…)
社内含めて8本。複数回やっているのもありますが、純粋な技術という面ではPHP BLTのみなのでもっとがんばりましょう。
2015~2016年はProduct Manager的な方々とお話させてもらう機会が沢山あったのですが、2017年は自分の今の職務により近いEngineering Managerの方と沢山話をしたいと思い、まずは場を作りました。
エンジニアリングマネージャー(とその周辺に関心がある人)が集まるSlackチームを作りました | けんちゃんくんさんの Web日記
現在、54名の方がjoinくださっています。来年はもっと盛り上げていきたいので、同じような職務を担っている方、興味のある方はjoin us!
今年は完璧やりきったという感覚が薄い1年だったので、来年はバーンとしたと言い切れるように頑張って行こうと思います。
今年一年お世話になった皆様、ありがとうございました。来年も引き続きよろしくお願いします。
