• 7/19子供が生まれました
• 元気にやってます

👶

• 今回は立ち合いできたのが良かった
• 寝て飲んで泣いて繰り返してる

生活

• 無事1か月検診が迎えられそう
• 長男の誕生と比較して事前準備ができてよかった
• 仕事は少々お休み中だが時間の使い方が難しい

健康

• 両親のサポートで食生活が改善した
• 台所業務を楽しむ
• 筋トレは在宅でできるものを検討

キーボードを探しています。 現在は10年ぐらいHHKB Bluetooth無刻印を使っています。 特に困っていませんでした。

コーディングはMac、ゲームはWindows、持ち運びはUbuntuを使っています。 環境は同時に複数起動しない前提でキーボードは共有で利用できました。マイクやカメラ、モニターなどのデバイスは切り替えて共有できるようにしています。 マウスとトラックパッドを使っていますが、それぞれWindows・Mac専用機として利用しています。 Macは複数デバイス間でデバイスを共有する仕組みがありとても気に入っています。

持て余しているWindowsを使ってhomelabsの運用検討を始めました。 最初は家でこれまた余っているMac miniの上でLinuxサーバーにして運用する予定でしたがCPUが弱くて移行検討することになりました。 結果として悩ましいのが複数OSの同時起動とデバイス切り替えです。

HHKB Studio

最初に思いついたのはHHKBの置き換えです。BTでサポートしていない複数デバイスの切り替えができ、Windows / Mac両方起動時にキーボードの機能だけで切り替え可能です。 HHKB Studio はポインティングデバイスにいく勇気が必要ですが、3/31現在は無刻印セットのセールがされているので有力候補の1つです。

HHKB Studio

Jiffy75 LP

検討中の第二候補がkickstarterで公開されている Jiffy75 。 Cornix LP の流れに乗り遅れたと思ったら次のキーボードが出るらしい。 分割キーボードは過去 mint60 に挑戦した。初めての自作キーボードではんだ付けに失敗したのと、優先分割キーボードだったことでHHKBの無線体験に戻ってしまっていた。もう一度分割キーボードに挑戦する案もある。

Jiffy75

悩む

基本は無線キーボードを検討する。ゲームをするときにストレスを感じるようなら左手デバイスの導入を検討する。カジュアル勢なので普段はパッドでも十分だろう。 4月から新しい開発環境としてWindowsをメインにするのも十分あり得る。

寂しいこともあり、近くで気に入っていた🍺を飲めるお店が人員不足で休業になった。 別店舗で同じ🍺をまた飲めるのだが、徒歩圏内にあった以前と比べてどうしても機会が減ってしまう。 特に昼に飲めたのが良かった。

家ではずっと「はたらくくるま」の再生を子供👦から求められている。 最近のブームだ。

2月は選挙に参加してきた。与党・中道でないところに入れた。 自分の地域はもう少し多彩な候補者が出て欲しい。

仕事と子育ての往復を続けている毎日を、まだボチボチ楽しめている。 最近朝ごはんを担当するようになったが料理する計画が立てられるのも割と楽しい。

夏頃からまたガラリと生活が変わりそうなのだ。 余裕ある今の内に読書やゲームや何か自分の時間を作る習慣を夜寝る前に入れたり挑戦したい。

• 2/8は投票日です
• 行けない方は期日前東京に参加しましょう

今回の選挙

自分は期日前投票ではなく当日に投票予定である。 投票用紙が届くのかはまだよくわからない。

今回の選挙は不思議な点が多い。 自分は関東圏で生活しているわけでもないので、自分の地域からは出馬している人がそもそも少ない。

政策の違いなどの議論よりも、情勢が決しているといった情報がとても目に入る。 食料品消費税の現象に関する議論などもかなり前から提案があるが、指摘の問題はどの党も解決案を持っている訳ではないように見える。

気づいたら流れが見えていない

前回の選挙だとオレンジ色の党に勢いがあったようだが結局最後までその流れの発端がよくわからないまま終わった。 今回の選挙だと青色の党が勢いを出そうと変わったことを始めてみたがどうも空回りしている。

選挙速報的なものは新作映画のネタバレのような、中身をまったく見ていないのに関心を削いでしまう。 インターネット使わないぐらいの強い気持ちが必要だ。

知りたいこと

与野党の主張と対立のマトリクスが知りたい。 与党の意見の反対が野党である必要はないけれど、与党の意見に近い野党が野党の立場を取っている背景もわからない。

自分の選挙区に出ている候補者も配布される資料かたまたま演説に遭遇することなどがなければ主張の違いを認識することも難しい。 所属政党と候補者の意見の乖離においても受け止め方がわからない。

わからないことだらけだ。後1週間でもう少し内容を調べる。

あっという間に一年が終わり、今年は特にアウトプットが出せない年でした。

振り返り

• 引っ越した
  • 広い家に引っ越した
  • 仕事部屋が安定して利用できた
• 所属プロジェクトが変わった
  • 新規企画を考えたりした
  • AI前提で仕事するようになった
• 体調
  • 体重を夏に減らせて戻った
  • 酒を飲む量は減った

来年の目標

• 体調
  • ジム通いできる限り継続する
  • ジム行かない日の運動を増やす
• 学習
  • AIを利用しない趣味の範囲を増やす
  • 本を読む

過去

• 2024 年終わり
• 2023 年終わり
• 2019 年終わり
• 2018 年終わり
• 2017 年終わり
• 2016 年終わり

座学で授業を受けているような感覚で、自分の力とするには自分なりの学習を仕組みにする必要がある。 突然生成AIが使えない環境に入ると今のような速度でキャッチアップを進めたり、アウトプットを進められるかはわからない。

仕事ではより枯れた手段を好むようになった。

アウトプットの速度に驚いて、6割の品質で走り始めた。8割に達する前の段階でレビューを開くことが増えてしまっていた。 パッと要求して完成まで走ってしまうと自分では作らない1000行や2000行といった差分のプルリクエストができてしまう。認知負荷が高い。

もっと踏み止まり、品質がぶれない手段を経由するやり方を模索する必要がある。3度やるぐらいの覚悟で仕事するのがちょうどいい。

奥さんの出張と重なり子供が熱を出した。貴重な体験をメモしておく。

だいたい元気

咳が出て、鼻水が出ても朝にはだいたい本人は元気になったつもりだ。 家は退屈で外にも出たい。だけれどおやつ、ご飯も喉を通らない。

やる気は溢れている。

眠くても眠られない

自分がスマートフォンを触ったり、ちょっと家事のためにとテレビを流したりするとどんどん眠さが遠のいていく。 体力の限界がくると急に高熱を出してご飯も食べられず倒れたように寝る。

まだ高熱で痙攣など起こしたことはないけれど夕方から特に目が離せなくなる。

デジタルデトックス

仕事が気になったり、隙間時間を埋めたかったりで簡単にデジタルな空間にアクセスしてしまう。 その度に子供へ向き合う時間が減っていたり、眠りを妨げていたりする。

デジタルから離れてもっとアナログな世界の子供に向き合うのが必要だ。

仕事は変わらずサービス開発のお仕事を続けられている。 全体の理解も深まってきたことで好きに動けるようにもなった。

久々に東京出張へ来た。 降りた駅でよく行ったビルがなくなっていたり時代の変化を感じる。4月上旬の東京宿は値段が高い。

今回は前職の同僚と会うことができ、楽しい時間も過ごした。 彼らの近況の変化を聞き自分もリスクを取ったりチャレンジしたいと感じた。

子どもは早くも1歳になる。保育園に通い初めて泣きながら成長している。 季節の変わり目に初めての風邪を引いてたが、毎日元気そうで何よりだ。

妻の復職も近くなり、新しい生活の始まりが近い。 1年間の育休期間本当にありがとう。

今年度も頑張るぞ💪。

• 怒る前、反論する前には6秒の間を置く訓練をしよう
• 怒り以外の感情に直接目を向けよう
• 要求を伝える方法として「私」を正しく伝えよう

怒りのピークは６秒で終わる

反射的な言動をやめる

最初にこの言葉が出てきてまさにそうだと感じた。

習慣や合理性といったものは相当に曲者で、なかなか抜け出せない。 怒りの感情をうまく扱えていない自覚がある。

不快なことはあれど、起こることはなく相手に要求を伝えられないような場合が増えた。 自分の感じた不快感は「怒り」のようなものとして相手に伝わってしまっている場合もある。

6秒待つというルールは非常に直感的だ。自分の習慣を見直す1つとしてぜひチャレンジしたい。

怒りの奥にある「本当の気持ち」と向き合う

怒りは二次感情であり、その裏には一次感情が潜んでいる

感情には分類があるという話がされていた。 悲しみや不安といったようなネガティブになってしまう感情と怒りや不快といった感情は同様のものと考えていた。

怒りを収束させるためその原因である一次感情に目を向けないと解決できないという話がされており、その切り分けをしましょうと解説されていた。

主語を私にして伝える

自分を主語に伝えると、相手は受け取りやすくなります。相手の問題に言及することなく、自分自身の問題を伝えているだけだからです。

伝え方は本当に悩んでいる。 否定という用意はネガティブな引力が強くて憶測も生みやすい。

結果的に、自分の要求を伝えきれないことは増えている。 この本の中ではそれも良くないと書かれていて、その上で方法を考えさせられる。

もっとうまく感情をコントロールしていきたい。

1. 2024年は家族との時間を大切にしつつ、仕事や趣味を楽しんだが、体重増加や耳鳴りが気になった
2. 来年は運動や柔軟を習慣化し、仕事面では安定と新たな挑戦を目指したい
3. 家族や仕事のバランスを保ちながら、充実した1年にしたい

振り返り

• プライベート
  • 2024年は子どものために時間を使えた
  • 在宅で仕事をできることに感謝
  • 育休を取得し子育てや家事をリードしてくれている奥さんに感謝
• 体調
  • 体重が過去最大になっている
  • 健康診断は問題ない
  • 酒を飲む量は減った
  • たまに耳鳴りがするようになった
• 趣味
  • 車の運転が最近楽しい
  • もう少し子どもが大きくなったら山に登ったりなどしたい
• 仕事
  • インプット・アウトプットが減ってしまっている
  • 得意なことを中心にやらせてもらっている
  • チャレンジは少なめ

来年の目標

• 体調
  • もう少し安定してジムに通うなり運動する
  • 苦手な柔軟をする
• 仕事
  • 共働き体制を安定させる
  • 波を小さくする
  • 非機能要件にチャレンジを作る

過去

• 2023 年終わり
• 2019 年終わり
• 2018 年終わり
• 2017 年終わり
• 2016 年終わり

まだ今年の締めのタイミングではないが書く習慣に習ってぼんやりと目標や夢について感がていることを書く。

目標というものは仕事やスキルのことばかりだったが、今年は子供が生まれたことで時間の使い方や課題の観点が変わった。 もう少し大きくなったら子供を山に担いでいこうとか、年末年始両親との時間を作ってあげようとか。

来年の目標は子供を保育園に入れて新しい生活サイクルを作ることだ。 素直な子供を見習って自分も学び直しをしていくのがも目標。

大変ながらも仕事は楽しめている。体の不具合は運動で解消していきたい。 欲張りすぎず健康の上に楽しみを積んでいこう。

この本はサブタイトルにもあるように、文章に対する技術に関して触れるわけではなく、 自分の気持ちの整理のために文字を残そうであったり、人間らしい記録を残そうといったことを推奨していてます。

仕事のドキュメントやチャットコミュニケーションばかりに囚われていたなと痛感し 「なんでも良いので」文字に起こしてみようという気持ちになりました。

「もやもやを書き残す」ということを推奨もしていました。 自分しか見ない記録があっても良いという気持ちを長く忘れていたように感じます。

気持ちの整理であったり、「なぜ」という深堀りをうまく活用することが推奨されていました。 「ブログ・アプリ・紙・何でも良くて、整理されていなくても良くてなにかを書いてみたい」という気持ちに少しなれました。

• わかりやすい
• 自身の失敗に関連する説明もあり、共感できた
• 目標設定や成果は難しい

コラボレーションのためのリモートワークという発想の転換

実際、リモートワークでは孤独感を覚える人が多く

現状、幸いなことに孤独感は感じていない。 とはいえそれは私個人の話であったり、今の会社ではうまく施策が機能している結果である。

良いリモートへの12ステップ

1. 経営陣は原則リモート環境で作業していますか
2. チームメンバーは、勤務時間を自分で決めることができますか
3. 仕事に関するコミュニケーションは非同期前提ですか
4. Valueとその活用方法が明確に定義され、文書化されていますか
5. すべての部署が活用するツールは、統合されていますか
6. ハンドブックをあらゆる判断の基準として活用していますか
7. 友情を生み出す方法が定義されていますか
8. コミュニケーションの方法は、SSoTに文書化されていますか
9. 一人1台のPCと各種デバイスが提供されていますか
10. 交流機会を意図的かつ定期的に用意し公開されていますか
11. Valueの体現を採用・称賛・昇格基準としていますか
12. 個人の作業環境を向上させるために費用を出し、自宅以外で作業する場合にも補助を行っていますか

現在の会社では非常にYesな点が多くとても働きやすい。

コラボレーション

参加者の大半が合意している内容に対して異論を言いづらくなり、コンセンサスを図るためにグループ意思決定能力が低下して非現実的な決定をしてしまうといった「グループ・シンク」も避けるべき重要な視点です。

これは感じるケースがある。 特にリモートワークでは議論をリードするわけではない参加者にとどまっていることも少なくない。

議論を行いたい場合などは3人、最大で4人ぐらいが限界なように感じる。

成果(Results)

コードや価値を提供したユーザー数、救われたチームメンバーといった具体的な対象を計測します。

これは想像より具体的な計測方法であるが、どのように運用できているのだろう。 運用コストが気になる。

心理的安全性を生み出す7つの方法

「自分がしてほしい行為を、他人に対して実施せよ」という行動規範を黄金律と呼んでいます。

いい名前である。使っていこう。

SMARTな目標設定

• SMART
  • Specific(具体的）
  • Measurable(計測可能）
  • Achiveable(達成可能）
  • Related(経営目標との連結）
  • Time-bound(時間成約がある）

良い問いが建てられれば、問題は半分解決している

納得感があった。 目標設定は正しく運用できている場合力を発揮しそうであるが、私は今うまく運用できていない。

今一度、目標設定の目的に立ち返り行動指針を見直したい。

運動によって脳を整える

うつ病の発症率は運動を提供したグループのほうが低い

運動は正義。

意図的に週二回・20分以上のゆう酸素運動を生活に取り入れ、人体の機能をメンテナンスしていくことを推奨します。

これは生きていくために必要な時間だと強く感じている。

360度フィードバックで能力開発を促進させる

3つの設問。

• Start
  • チームの成功を助けるために、対象者が始められることを1つ上げてください
• Continue
  • 対象者が優れている点で継続すべきことは何だと思いますか
• Stop
  • 対象者に対して真の意味でポジティブに変革をもたらすことのできる、最大の改善機会は何だと思いますか

これは良い設問である。 私は360度フィードバックに救われたことが少なくない。 またフィードバックは評価とは関係なく、一人の人としてコメントしてくれている人には非常に感謝している。

• 体脂肪が増加傾向にある
• うまく時間が作れなくて悩ましい
• 朝の時間をうまく活用したい
• 8月は睡眠時間削って運動するチャレンジも考える

夜に時間が作れない

• 8-9時には寝かしつけ🍼
• 仕事が長引いた分はごはんやお風呂の時間を削っていく

深夜の🍼と不安定な二度寝

• 👶は寝返りやうつ伏せ寝がブーム
• 動きたいときは動きたい
• 3-4時で寝かしつけ再チャレンジして二度寝するか悩む

運動（ジム）

• 今は週末の午前中に時間が取れたらジムで運動
• 週2日2−3時間体を動かす
• できれば平日にも体を動かしたい

朝活

• 平日朝にランニングしてる人をSNSでよく見かける
• 4-5時ぐらいはまだ真夏でも活動できそう
• 👶にあと1時間寝てもらうか、不定期で睡眠時間2-3時間削って運動に回すか8月チャレンジする

• 👶が生まれて3か月ぐらい過ぎた
• 最近絵本を👶に読み聞かせたりしている
• 紙の本も良い

子供の関心

絵本によってリアクションは割と異なるのが面白い。 👶の今のお気に入りは🍣の出てくる本で、読んでいると何か喋りたくなるようだ。

絵本学

絵本といえば、という強く思い入れのある作品は個人的には正直なかった。 どちらかというと教育番組で定期的に放送されるような日本昔話のようなものを想像していた。

いろいろ調べ始めると昔から人気なものや現代人気が出てきているような新しいものもたくさんあることがわかってきた。

絵本の種類や表現などに興味が湧いたのは「専門家が絵本をガチ考察したら衝撃の結果に」を見たことも大きい。

VALUEBOOKS

絵本は現在VALUEBOOKSという古本買取販売サイトを経由して買っている。 VALUEBOOKSを知ったきっかけはコテンラジオやゆる言語学ラジオなど様々なチャンネルにスポンサーをしているのがキッカケで知った。

自分の読みたい本は電子書籍で買うことに寄せていたが、貸すであったり読み聞かせであったり、また手元に残したい本もあるように最近は感じている。 送られてくる本も古本とは思えないきれいなものも多く便利に気に入っている。

• 元気に早寝朝型生活を続けています
• 楽しくコードを書く仕事を続けられてます

子供

• 特に病気をするなどもなく元気に過ごせています
• 夜寝る時間は安定し20-21時には🍼決めて寝られてます
• 1-3時と幅のある深夜🍼の際に素直に寝る場合とテンション高めの場合があります

分割睡眠

深夜🍼のタイミングで起きて対応を手伝っていると一度起きます。 最近の悩みは二度寝するかどうかの判断です。

寝かしつけは安定してきており、よく寝てくれる日などは6時間ぐらい寝てくれる日も少なくないです。 今日は短めのタイミングで起きましたが目が冷めてしまったので作業をしています。若干眠いです。

二度寝した上で早起きというのも目覚めが良くない場合もあったり、 二度寝ってするかどうかの判断むずかしい。

今日は眠い感じで1日過ごします。

• パパ育休をもらって里帰り先より生活の基盤を移しました
• 生活スタイルを朝型にシフト中です

大きく変わった生活

子供中心の時間設計を模索中。深夜対応は新規システムのオンコール対応の気分（アラートは大きめ）。 夜は割とぐっすり寝てくれていて、ミルクは過剰に与えすぎてなくても良い。

寝かしつけは練習中で22-24時台のミルク前後テンションが高い。 夜に自分の時間を作ることはその関係で悩んでいる。朝のミルクタイミングから起きて洗濯なり自分の時間を作っている。

仕事も早朝よりさせてもらうほうが今のところ便利が良さそうだ。

体調

引っ越しや新生児の受け入れなどで筋トレのリズムが狂っている。 肩腰の違和感が起きやすい。体脂肪も上がったままだ。

育児と仕事と健康のリズムを安定させることの優先度が高い。

料理

最近台所を預かっている。まだスーパーの事情を把握できていない。 世間はキャベツ🥬が高く茄子🍆 の美味しい季節になったようだ。

朝型になった関係で朝ご飯の需要が高まっている。効率の良い便利な朝ご飯を知りたい。

• 子供が生まれました
• 4/23に退院できそうです

生活

福岡県へ移住し、里帰り中だった出産に関わることができました。 立会はできませんでしたがとても良い経験ができました。 何事も初めての体験で驚かされるばかりです。

職場のサポートもあり、ありがたいことに仕事や移住後の不安・不満はなく新しいチャレンジに向き合うことができそうです。感謝します。

また落ちついたころに近況を記録します。頑張るぞ。

紙の本もいいぞ。

インターネットもいいけれど

何かを学び始めるときは本が良いと思っている。

インターネットを利用して調べながら学ぶこともできる。ChatGPTなどの登場により対話によって物事を捉えやすくなるケースも増えた。 Copilot を始め、プログラムを格上での具体的な例も手に入れられる手段の内容も格段に向上した。

ただ、自分の身になるためには本の粒度がちょうどよいと感じる。

下線をカジュアルに引いてメモを残せることなどから好んでKindleなどの本を購入することが多い。 今回はきっかけがあり紙の本を借りた。

紙の本の良さ

電子書籍と比べて体感早く読み進められる気がしました。 また手にもって読み進めることで読み切れるまでのワクワクであったり、面白い本は物足りなさもより感じる事ができた。

ちょっと読書マイブームが起きそうなので積読していた本を消化していこう。

私信です。

• From: CADDi Inc
• To: ROLLCAKE Inc

ROLLCAKEのJoinを決めた理由

この会社の魅力は「共に成長し、楽しみを作り出す挑戦を楽しめること」です。

入社（前|後）のギャップ

ROLLCAKEでは「体験設計書」を通して「ゴール」の定義にこだわっています。これは課題の定義とは異なり我々の考える楽しみをぶらさないための指標として保守されています。 最初はこの体験設計書の使われ方がイメージしきれてなかったなと今だと感じます。

我々の考える楽しみとは多種多様でありますし、試したい施策も多岐に渡ります。 適宜優先度の判断等も入りますが、ゴールに向かっていく中で必要な施策の実行や計画は現場にも多くの責任を任せてもらえています。

言語化が難しいのですが現場の裁量の大きさが非常に心地よいです。様々自由にさせてもらっています。

スモールチームに戻って

スモールチームは特有の強さがあります。困ったときには誰にでも相談できる身軽さや、それに答えてくれる心強いメンバーもそれをサポートしてくれる会社もあります。

毎日楽しく働いけておりますし、自分が作ったアウトプットで自分も楽しめています。 「楽しみが待っている毎日」を作っていくぞ。

Refs

• 地方移住を検討
• CADDi株式会社にJoinしました

• I started using eza and graduated to tree.
• eza-community/eza is a fork of ogham/exa
• I still use ls too!

I love ls. I can't remember how many times I've repeated the same thing.

We can use ls anywhere.

The nice thing about eza is that it is colorful. It requires some installation, but I will try to be friends with it for a while.

• Github Projectの進化がすごい（実はずっとすごかった）
• カスタマイズ性が高く、エンジニアフレンドリー
• フィルタとの組み合わせが強力

Githubを利用した開発タスク管理

近年、GithubとJIRAを組み合わせたスクラム開発を数年回していた。 理由はGithubでは十分なタスク管理ができないからということで採用されていた。 スクラムやチーム開発の中でタスク管理ツールに求めていたものには下記のような要件があったように考える。

1. カンバン表示ができ、進捗状態を可視化できる
2. カンバン、およびバックログなどに優先度が付けられる（優先度順にソートできる）
3. 複数のチーム、職能が存在していた際にViewを直感的に分けられる（swimlaneなど）
4. エピック・ロードマップが管理でき、簡易的なガントチャートが管理できる
5. ストーリーポイントなど、ベロシティやタスクの大きさを一定入力できる
6. 複数のリポジトリにまたがるタスクを同列に管理できること

チームタスク管理でやりたいこと多すぎるが、これらを十分にカバーできるような機能が揃って来ている。

Github Projects押しの機能

上記プロジェクト管理に必要な設定がGithub Projectだとどのようにできるのかは一休Developers Blogの記事がとてもわかりやすい。 大枠はそちらの記事に任せるとして、この記事では私の押しのGithub Projectの機能を記述する。

フィルターが強力

Github はissueやpull-requestの管理、検索などに提供されているフィルターの機能が強力だ。この機能がいい感じ にGithub Projectでも拡張され、活用し易いようになっている。

お気に入りのフィルターは下記がある。

• last-updated: 最近更新されたっぽいのを取ってくる
• field: プロジェクト固有のカスタムフィールドを比較演算使って絞り込み

Viewを複数持ったプロジェクトを建てられる

Changing the layout of a view

最初これが1つのプロジェクトという表現の中でなんで分けられる様になってるのだろうとか、このViewはどういうときに使いたくなるのだろうと分からなかった。 結果的にはフィルターと組み合わせることで実際のプロジェクトに合わせ使いやすくカスタマイズ可能な要素だと理解できた。

また、Viewはソートの設定やグローバル設定とローカル設定の管理を別々にできるなどこれまた痒いところに手が届いている。 全体のViewに影響を与えず、手元では assignee:9renpoto などフィルタした状態で膨大なタスクの海を直感的に操作できる。

プロジェクト（カンバン）を操作しなくてもステータスを更新できる手段が豊富

Understanding fields

Githubにはスタンダードな管理方法として label と milestone があり、長くこれらの機能の組み合わせで開発プロジェクトの運用ができるようルールを設けたりなどしていた。 これらの標準項目はいずれもリポジトリ固有な設定であり、設定を同期したりそれらの仕組みを組んだりなどが必要であった。

私はずっと waffle.io というGithub 連携可能なプロジェクト管理ツールが大好きであった。 その中で一番好きだった機能が「ステータスとラベルの連動機能」だ。いい感じにラベルを操作していたら、カンバンもいい感じになる。カンバンを操作していてもGithub にいい感じのラベルがついている。

上記の機能がカスタムフィールドではほぼ表現可能であった。 またカスタムフィールドはプロジェクト全体で共通 なことが理解するととても使い勝手通い。

最後にカスタムフィールドは1つの値しか指定できない成約も理解するととても使い勝手が良い。複数指定したい場合などはラベルを使っている。

まとめ

• Github Projectいいぞ
• Githubだけで完結する世界線は快適たぞ
• PR、Issue全部プロジェクトに入れてフィルタでカスタマイズしよう
• Githubありがとう🐙

Ref

• GitHub Projects を利用したタスク管理 | 一休 Developers Blog
• GitHub Projects を導入した話 | KAKEHASHI Tech Blog
• Thank you, waffle.io | 9renpoto.win
• github projectsが少し良くなっていた | 9renpoto.win

• mise使い始めました

環境

ローカルに実行環境を構築することは未だに便利なので asdf を好んで使っていました。 あまり不満はなかったのですが最近話題になっているmiseを動かしてみることしました。

.tool-versions や .default- packageのサポートなどasdfの資産もぼちぼち流用できるようになっており ほぼインストールするだけで使えてしまっています。一部問題もありそうであるがしばらく使ってみます。

Refs

• mise (旧 rtx) で脱 node-build (asdf)

• AstroNvim に入門しました
• Lsp周りの管理を簡易化できてVscodeと変わらない体験ができてる

ライトNeoVimユーザーにちょうどよい

• 独自で config/nvim を育ててましたが、独自の設定は限定的であったので設定を移管中
• Starship など最近重くなく使える便利ツールが増えてそうなので楽に乗っかれるか挑戦

今のところは割と満足しています。ユーザー拡張領域が github template で共有されているなど今らしい入門しやすさもあります。 まだまだ使いこなせていない隠された設定も多そうですが、もう少し付き合っていこう。

Refs

• 拡張Vim「AstroNvim」で新世代のVim体験してみた話
• Starship

• 転職しました
• 4月父親になるかも

振り返り

• 今年は大きな変化のある年になりました
  • 11月に転職しました
• マネジメントからプレイヤーへ
  • そろそろいい年なこともあり転職活動悩みました
  • 人と向き合うマネジメントも大切な気持ちですが、プレイヤーに戻ることへしました
• 筋トレにハマりました
  • 肩こり・腰痛・腱鞘炎解決しました
  • 1年通いましたが、健康続けたいので筋トレは継続

相談に乗ってくださった様々な友人の方々、誠にありがとうございます。 仕事もとても楽しく、これか大きく生活が変わりそですがボチボチ楽しめそうです。

来年

• 地方移住に挑戦
  • 移住しても月1程度は東京近辺に行けそうです
  • 転職に興味のある方、ぜひオンライン・オフラインどちらも構いませんので雑談しましょう
• ウェブ屋からアプリ屋に
  • 機会を得られそうなのでスキルを増やして好奇心を満たしたい
  • next.js app_routerが落ち着いたころにweb frontendも触ろう

未知のことが目白押しでワクワクしています。 やっていくぞ 💪。

過去

• 2019 年終わり
• 2018 年終わり
• 2017 年終わり
• 2016 年終わり

• 毎日続けられることをどうサポートできるか考えている
• 毎日必ずできている必要はなくて、でも明日も実行したくなる施策を考えている

毎日続けることの楽しさに気づきたい

Happy Contributions 10,000

• Githubへアウトプットを残すことは自然と続けられるようになった
• 毎日少しづつでもやってることを楽しいと思ってやっている
• 毎日続けてられるようになったことと、そうでないことの違いを考えている

毎日続けられないことを考える

Rebuild: 217: Socially Awkward Hip-hop (higepon) https://rebuild.fm/217/

468 「コンフォートゾーンを打ち破る」という生き方 https://donguri.fm/n/nd999ff46a340

• 人には得意不得意があってコンフォートゾーンを持っている
• 新しい体験はそれが良いか悪いかに関わらず受け入れることにストレスが大小かかる
• 「得意ではない」を「苦手ではない」にするのには時間と気持ちの変化がある

ちょっとした成功を積み重ねる

• Duolingoは良い目標設定があって、続けているという実感がある
• 実感とは言語習得がレベルアップしたという定量的なものではない
• 明日もチャレンジしたいという施策と、緩やかな成功体験がある
• 失敗しても良い という気持ちでいられる

やりたいこと

• 毎日ちょっとだけ違うことをして成功・失敗をする
• 12月中に来年の目標をたてて、何か自分のコンフォートゾーンを出る

Before: Post blog rss feed via dlvrit

• twitterからx.comへ変化の時代
• bsky.app やThreadsに人が分散した
• IFTTTやZapierなどのX（旧Twitter）連携が減っている
• https://github.com/lwojcik/github-action-feed-to-social-media を使ってみる

dlvritは数すくない無料で連携可能なサービス。 bluesky, threads, mastodonなどにユーザーが分散し次の時代を見定めようとされている。

API連携なども変わってくるだろう。少し変化を見守りたい。

• オープンな情報には力がある
• 情報は受け取った側が評価するもの（半分はわかる）
• インプットしやすいアウトプットを出したい

毎日アウトプット

誰かと会話をしない日はない。一番小さなアウトプットだ。 人間として一人で生きていくことよりも、濃淡はあれど人と接することはあるし必要だ。

私は得意なアウトプットの形式は多くない。ブログという形式も得意な方ではない。時間もかかる。

チャットツール

仕事ではチャットツールを使うことが多い。今思えばツールも多く移り変わってきた。 (参考)

1. Skype
2. IRC
3. HipChat
4. Slack
5. Discord
6. Gather

書き起こしてみるとslackとの付き合いは本当に長い。まさにIRCの上位互換として多くの会社に受け入れられている。 プライベートでも利用できるフリーミアムなツールも増えて豊かになったものだ。 アウトプットすることが気軽になり、インプットとは能動的なものではなく受動的なものが増えた。 悩んでいるのは**「情報をどこまでオープンであるべきか」**だ。

インプットを制限する技術

今の時代、情報は多すぎる。検索をはじめ情報のフィルタリングとはこれからの時代により必要な技術だ。 繰り返しになるが、受動的は本当に増えた。

1. 1つは広告だ。世の中には知ってほしい人が多く様々な人目に触れる機会を探している。
2. 2つ目にSNSだ。SNSの多くは不特性多数に向けられたもので、時には人に不快な思いをさせる。誰かの幸せは別の誰かの幸せとは限らない。

広告とは誠によく考えられている事が多い。伝えたいことを絞りターゲットを絞ることなども増えてきた。 SNSとはオープンなもの多い。また受動的に情報を受け取りやすい。その情報のコンテキストも特にわからないままにだ。 過去の経験より、私は言葉の強さを知りSNSサービス上に直接文章を残しコンテキストを残すのをやめた。私には私のアウトプットがどのように解釈されるのかわからなくなったからだ。

情報は受け取った側が評価するもの

「情報は受け取った側が評価するもの」

最近フィードバック面接の際に言われたことだ。それは真理だ。 「オープンな情報とはいつ何時だれに解釈されても問題のないものであるべきだ」だとその時は理解した。

半分はわかる。もう半分は「オープンな場所では何もできませんってことですか」だ。 解釈を恐れてはアウトプットは生まれない。

現在

環境が変わりインプットも圧倒的に増えている。 オープンとは強い力を持つと改めて実感する。日々の情報を解釈することが許され、それらが性善説の上に成立している。

新しい情報の海にワクワクしている。 まずは得意なアウトプットの形式から頑張る。インプットしやすいアウトプット を出せるようレベルアップするぞ。

• 福岡県への移住を検討しています
• 働き方の変化を受け入れられる準備を進めています

関東圏の良かったこと

• たくさんの友人がいること
• 仕事・娯楽・交通の選択肢が豊富なこと

関東圏でなくても良かったこと

リモートワーク

リモートワークが上位互換だ、とは思っていない。 選択肢が増えたことで多くのメリットがあったことは確かだ。必要な環境を整え、オフィスよりも効率の良い作業環境を用いて仕事ができていたことは間違いないメリットである。

次に時間の節約だ。通勤時間はもちろん、家族とご飯を食べる機会が増えた。 時代に合わせてツールも充実した。必要なコミュニケーションは事前にも突発的に設定でき、同期的に仕事する ツールは成熟されつつある。

もちろん、仕事内容に依存があることは間違いないが、我々の得意とするソフトウェア開発においてはリモートワークは相性が良かった。

オフィスで働くメリット

オフラインコミュニケーションは言語化することが難しい問題解決の可能性がある。 1つは信頼関係の構築だ。WEBカメラを用いて表情を確認することはできてもオフラインでしかできない楽しさというのはある。

オフィスに出社してオンラインコミュニケーション

リモートワークを一部でも許容している環境において、オフィスでのコミュニケーション体験は決して良いものとは言えない。（もちろんオフィスがどのような環境を提供しているかによる）

時代や道具の進化によって滑らかにオンラインとオフラインを融合した働き方もできるようになる世界の誕生には期待したい。ビジネスチャンスも同様にある。

まとめ

地方移住を検討項目の1つに入れている。 オフィス出社を希望する場合は関東より選択肢は少ない。どのような働き方ができるのか社会と相談していきたい。

• Output: https://github.com/9renpoto/bot/pull/1037
• Must be used with a loader to use TypeScript
  • https://github.com/nodejs/help/issues/3902#issuecomment-1217235905
• The assert syntax can be used
  • https://nodejs.org/api/assert.html
  • https://nodejs.org/api/test.html
• I still don't use it at work

Good

• Type information is maintained 👌
• describe, it can be used 👌

Not Sure

• Asynchronous process not terminated 😶‍🌫️
• API is different on node18 node20 https://github.com/kachick/times_kachick/issues/192

Visual

• Very simple
  • https://nodejs.org/api/assert.html#assertvalue-message
• Not particularly excellent

感想

• TypeScriptを使って小さなものを作りたい時に、nodejsを使うほど小さく便利なものではなかった
• もうしばらく様子を伺う

• IN: 9renpoto.win OUT: 9renpoto.dev
• IN: cloudflare Registrar OUT: Google Domain

Thank you google domain

Google domain seems to be ending its role. There are only a few name servers that can handle .dev domains.

We will change the domain to operate the site.

• 今まで多くフロー情報の粒度に囚われていた
• ストック情報の価値を再評価したい

フロー情報

下記のようなツールに関心がありました。

• TODO管理アプリ
• 予定管理アプリ

これらはに関心があったのは、「生きていく上で情報は消化していくもので、己の中にあるものだけがストックされている状態である」と考えていたからです。

受験勉強などもそうでした。基本的には己の「記憶が」ストックされる場所であり、そこに記録されるためのプロセスやレイヤーに関して己の中で最適化が日々行われていました。

ストック情報

私は現在ソフトウェアエンジニアとしてお仕事をしています。私にとってストックされている情報とは「動いているもの」、つまりソフトウェアやテストなどであり、それらの保守が最優先であると考えています。

逆に、それ以外のストック情報とは何であるかを冷静に考えました。私の手元に残っている資産とはかなり属人性が高く、再現性のものが多いことに気づきました。

• 好きなお酒を伝えられない
• 好きな食べ物を伝えられない
• 好きな場所を伝えられない
• 好きなアクティビティを伝えられない
• 得意なことを伝えられない
• 苦手なことを伝えられない

これらのことを見直し、私はストック情報を保守する生き方はどのようなことができるだろうと考え始めました。

自己成長

最近、筋トレへ目覚めトレーニングジムに通っています。 今まで感じていた体の不調が、徐々に筋肉痛に置き換わっていき、結果改善に収束していきました。 一方で、これらは少し油断するとすぐに数字や体に現れてきます。

何を考えているかというと、必ずしも足し算で結果が残るわけではなく努力に強く依存することを体験するもう1つの要素となりました。

最後に

この今思いつきで書いているメモが、私にとってのストック情報となる日は来るだろうか。

• Im now using https://app.dlvrit.com
• I feeling the effects of twttier's API billing everywhere :(

Background

• I originally preferred the service IFTTT
• I have not been highly motivated to update my SNS in recent years

お気持ち

• 最近自分の情報をまとめることの能力の低さや、物事を伝える能力の低さを感じています
• 何事もトライしないことには体感することができないので、アウトプットを残す練習や同期を探しています
• まずはこのブログを更新できるようにして、アウトプットを出せる準備をする

• https://www.gatsbyjs.com/ の利用をやめました
• https://deno.land/x/fresh@1.1.5/init.ts を用いてブログ基盤を再構築しました

Why

• gatsbyjsのメジャーバージョンアップに速やかに移行できなかった
  • プラグインの移行が面倒であった
  • ノーコードに近い形で構築ができたが依存の管理が大変であった
  • 静的なサイト構築を仕事で活用するケースが限定されてしまった
• deno fresh
  • preact nativeな利用を推奨していること
  • denoを使った開発環境を構築・保守したかったこと

感想

• 開発基盤は発展途上
• 依存は減らすことができた
• プロダクションに利用は難しいが趣味には十分環境が整いつつある

• GTMより配信したGA4でユーザープロパティを使うには 初期 pageview 送信前までにデータを入れる

GTMから使う場合

1. GTM初期化前にユーザープロパティ等で使いたい変数をpageview送信前に入れる
   • GA4より pageview はイベントとして、かつ特に設定なくデフォルト設定では自動的に送信される
   • 自動で送信というのがいつなのかわからないので最速であるGTM初期化前に必要なデータを集める必要がある
2. dataLayer 変数をGTMに設定する
   • 管理画面上からポチポチする必要がある
   • これをやらないとGA4から対象として認識さない
3. GTMデバッグモードとGA4デバッグビューを使ってリアルタイムに結合確認をする

dataLayer変数って更新されない？

• dataLayer変数を経由して更新可能な変数がセットできる？ようにドキュメントに書いている用に見えるがユーザープロパティでは1回しか更新されない？
• カスタムディメンションにデータレイヤー経由で設定できない？うまく動かせてないので要調査

• 現在進行形
• 解決したいがとりあえず軌跡を記録する
• 目指したいゴールはGTMから配信されているGA4にカスタムディメンションを適応する

Google Analytics 4

• firebase analytics統合版みたいなものが使える様になって気付いたらv4 という更新としてリリースしたようだ
• 取り敢えずGoogle Analytics 4から設定する
  • https://support.google.com/analytics/answer/14240153?hl=ja&visit_id=638430859981796861-106775261&rd=1
• カスタムディメンションの個数制限はそのまま？
• インデックス表記ではなくこちらで名前を割り当てていける？
• タグマネージャーからは ユーザープロパティ と 設定フィールド という2 種類の概念が登場する
  • https://support.google.com/tagmanager/answer/9442095?hl=ja
  • config で設定するか
  • dataLayer で設定するか
  • 一時的なものか恒久的なものかで設定の方法が違う？
• GoogleAnalyticsの設定のデバッグには https://chromewebstore.google.com/detail/google-analytics-debugger/jnkmfdileelhofjcijamephohjechhna?hl=ja やdebug toolより何がリクエストされているかなどを見ている
• 元々 firebaseにあったevent debug機能がgoogle analytics にも移植されているようで、それも使えそう
  • https://firebase.google.com/docs/analytics/debugview?hl=ja
  • https://support.google.com/analytics/answer/7201382?hl=ja

Goals

• カスタムで設定した属性をキーにどのぐらいの分布しているか調べたい

現状

• データを送っているようで入ってほしいところにはいらない
  • debug viewからはdata は送ってそうに見えるがユーザープロパティとしてデータを送られることが正しそうなのにそのように見えない
  • データが正しく適応できていないため目的のフォーマットでデータがはいらない
• Google Tag Managerを経由して変数をGA4にわたす場合
  • dataLayer 変数を経由して渡す必要があると思っているがうまく渡らない
  • typeof dataLayer が実行関数に置き換わると思っていたが原状はarray のまま呼び出しが行われている？
  • dataLayer にpushしたカスタムデータが送られているように見えない、対象の dataがpushされているようには見える
    • 初期pageview 飛ばすまでにデータをあつめておく必要があるとかそれ系がある？ドキュメントがわかりにくい
  • pageview eventがSPA 等でも発火して送られるようになっており、仕込みの工数が下った
    • だがそれに伴って動きが隠ぺい化されておりデータのサイクルがいまいちつかめない（リバースエンジニアリングしようと思っている）

この記事は、CADDi Advent Calendar 2020 の 5 日目にエントリーしています。

昨日の記事はandyさんによる【大公開】キャディのエンジニア採用 Historyでした

TL;DR

私信です。

• From: freelance
• To: CADDi Inc

CADDiにJoinを決めた訳

入社以前は sottar さんのエントリーを見ておりました。

決め手は Kobashi よりお声がけ頂いたことが大きいです。 きっかけとしてはお声がけ頂いたことですが、内容として私が追いかけているマイナーなライブラリのことに関して言及頂いたことや、 また対話の中で技術というものへの向き合い方や、正直な内情などについて議論させていただきました。

内定を頂いた後に社内で運用されている評価制度と、その評価制度に当てはめた場合私自身がどのような評価と期待をされているかということを 入社前よりお電話で説明されたことをよく覚えています。

短い期間の間に評価をいただけた事に関しまして、どのような観点で私に期待頂いているのか また今後のキャリアを含めてどのようなことに挑戦できるのかといったことも対話させていただきました。

内定承諾前よりこのような、期待値を言語化いただけたことは他社では経験がなかったため非常にありがたかったと感じています。

入社（前|後）のギャップ

入社後に一番印象的であったことはプロダクトオーナーの方が優秀であることです。 また、会社としてプロダクト開発のOKRやロードマップはプロダクトオーナーに責務を大きくもたせられており、開発者が課題に向き合うことに集中できる環境があるように感じました。

Whole Product という言葉はCADDiにJoinするまで自身で言語化したことはありませんでしたが 複雑な課題に対して自身のプロダクトや、我々が作る情報システムだけではなく、組織そのものが向き合っている物理世界の課題を含めた優先度付けに向き合おうとしていることが 入社して時間がたち課題の解像度が自分の中で上がっていくほどより見えてくるようになったと思います。

スモールチームを離れて

ここ数年、スモールチームにおけるエンジニアリングやマネジメント、プロダクトのロードマップ整備など幅広い業務を行っていました。 今回、会社員としてJoinを決めたわけですが

1. なんだかんだで頑張れば手が届くコンフォートゾーンを抜けて己の力を試す
2. もう１つ以上、別の尖った技術スタックがほしい
3. つくる人を増やすために技術を使いたい

といったことにフォーカスしてしばらくコミットしたいと思います。 技術的にこうしたい、組織をこうしたいといったことも凝り固まっておらず、まだまだコミットできることは多そうです。

興味のある方

カジュアル面談からでも行っていただけるようなのでお気軽に登録いただいても良さそうです。 やることはまだ無限にありそうです。

Refs

• The Whole Product－CADDiのサービス開発を貫くPhilosophy: https://note.com/sasaguchisan/n/n65ee9266bc25
• プロダクトマネージャー視点から見る製造業プラットフォーム"CADDi": https://note.com/yosukeshirai/n/n28fffca59eab

• coverallsでmonorepo coverageが計測できるようになっていた
• 多言語にも対応しておりcodecovを優先して使っていた理由がなくなった

Refs

• https://caddi.tech/archives/1640
• https://github.com/0xProject/0x-monorepo
• https://github.com/marketplace/actions/coveralls-github-action#complete-parallel-job-example
• https://github.com/9renpoto/.59-node/blob/011890f572a6a00258f72a9d25ab7f67e69590be/.github/workflows/nodejs.yml#L44-L59

• homebrewのinstall先にカスタムして /opt/homebrew をintel macで使うことができなくなっていそう

homebrew install path

However do yourself a favour and install to /usr/local on macOS Intel, /opt/homebrew on macOS ARM, and /home/linuxbrew/.linuxbrew on Linux. Some things may not build when installed elsewhere. One of the reasons Homebrew just works relative to the competition is because we recommend installing here. Pick another prefix at your peril!

• もともとinstall /user/local 配下にインストールが推奨されていたが適切な場所ではないと判断し /opt/homebrew へinstallを変更していた
• 今回 ARM 版Macの誕生により/opt/homebrew 配下へのinstallが推奨され、 Intel Macで /opt/homebrew 配下にbrewを配置している場合動かなくなっていそう

Error: Cannot install in Homebrew on Intel processor in ARM default prefix (/opt/homebrew)!

対応方法がいまいちはっきりしていないが全部入れ直すしかないだろうか

Refs

• https://github.com/Homebrew/brew/commit/5afff3f3aa1d806855d460e5f39bfbef28ef6262#diff-fcf6d384bb8308546cecce54bb9678c715f95c119b402f9b61a78e0cf3d8fbc4
• https://qiita.com/usamik26/items/601f5612bd3f8a21cc41

• GraphQLサーバーを書くときにはCode-Firstで書くとメリットが大きい

Code-First GraphQL server

隅田川.js というイベントで発表してきました

初めてGraphQLサーバーを書くためのWAFとして自分は @nestjs を採用しました。理由は下記のようなものがあります。

• TypeScriptをメインで利用する
• Node.jsでサーバーを書く際に構造化された一定のルールがほしい
• REST APIも同じサーバー上から提供できる
• GraphQLのための記述量を抑えられる

GraphQL serverを書く順序

@nestjs/graphql を用いた開発の場合、Code-Firstな開発とSDL(Schema Definition Language)-Firstな開発手法を選択することができます。

• https://docs.nestjs.com/graphql/quick-start#code-first
• https://docs.nestjs.com/graphql/quick-start#schema-first

Code-Firstを選択した場合、モデルとなるファイルに対してGraphQLのschemaとして公開するかをデコレーターを用いて明示していきます。

import { Field, ID, ObjectType } from "@nestjs/graphql";
import {
  Column,
  Entity,
  EntityRepository,
  PrimaryGeneratedColumn,
} from "typeorm";
import { BaseRepository } from "typeorm-transactional-cls-hooked";

@Entity("users")
@ObjectType()
export class User {
  @Field(() => ID)
  @PrimaryGeneratedColumn("uuid")
  readonly id: string;

  @Field()
  @Column()
  readonly name: string;
}

@EntityRepository(User)
export class UserRepository extends BaseRepository<User> {}

上記のサンプルでは同時に typeorm を用いてデータベースschemaの定義を行っています。 データベースに保存されている情報と、GraphQLを用いて外部に公開するschemaの一部をモデルファイルの中に集約して管理することができます。 以降、必要なResolverを定義すれば、GraphQLとして公開されるQueryやMutationをコードによって表現できます。

対してSDL-Firstなアプローチでサーバーを開発した際の流れとして

1. GraphQLファイルを定義する
2. 手動で作成した graphql ファイルよりTypeScript Interfaceとなる型情報生成する
3. implements 等を用い型安全性を確保する
4. graphql で生成したファイルに沿ったResolverを作成する

といった流れになるかと思います。この2つを比較した際にCode-Firstな開発のメリットは Resolverの実装とGraphQL定義との乖離をTypeScriptレベルで確認できる ことにあると考えています。また、nest.jsに関してはSDL-First、Code-Firstそれぞれに対してモデルファイルの作成（または生成）は必要であるため、記述量に関してもCode-Firstで作成される際にはメリットがあります。

Code-Firstによる記述のデメリットとして、デコレータが多段で定義されがち ということがあります。

Prisma | Hasura

GraphQLサーバーを構築するにあたり、これらの2つは十分検討に値する仕組みが出来上がっていると思います。

Prisma is a GraphQL ORM for your GraphQL (or REST) servers and not your frontend apps, kind of like a replacement for JDBC, SQL Alchemy, ActiveRecord and so on.

hasura の記事を引用 PrismaはGraphQL ORMだ、という表現をされています。

generator client {
  provider        = "prisma-client-js"
}

datasource db {
  provider = "sqlite"
  url      = "file:./dev.db"
}

model User {
  email String  @unique
  id    Int     @id @default(autoincrement())
  name  String?
  posts Post[]
}

Prismaでは独自のSDLとして .prisma ファイルを作成します。 比較のためにnest.jsとPrismaを併用しているサンプルを引用します。

// https://github.com/prisma/prisma-examples/blob/latest/typescript/graphql-nestjs/src/user.ts
import "reflect-metadata";
import { Field, ID, ObjectType } from "@nestjs/graphql";
import { IsEmail } from "class-validator";
import { Post } from "./post";

@ObjectType()
export class User {
  @Field((type) => ID)
  id: number;

  @Field()
  @IsEmail()
  email: string;

  @Field((type) => String, { nullable: true })
  name?: string | null;

  @Field((type) => [Post], { nullable: true })
  posts?: [Post] | null;
}

@nestjs/graphql + typeorm の時と異なり、entityとなるfieldの定義と、GraphQLとして公開するSchemaの定義がprismaファイルとTypeScriptファイルに分離します。 記述量という点では typeorm を使わない @nestjs/graphql と言った感じなると思っています。database migrationやschemaの型やrelationといった情報を Prisma に移管できるようです。

上記まででは typeorm と prisma を好みで選択するようになる印象ですが、 Prismaはtypeormと異なりGraphQLに最適化されたdataloaderのような機構のクエリーを発行できるかもしれないので、 @nestjs/graphql + typeorm + dataloader といった記述量が削減できるかもしれないことや、Paginateに関するサポートがないか期待しています。

• https://stackshare.io/stackups/hasura-vs-prisma
• https://hasura.io/blog/hasura-vs-prisma-9ffc7271eda8/
• https://github.com/prisma/prisma-examples/tree/latest/typescript/graphql-nestjs
• https://github.com/MichalLytek/type-graphql/blob/master/docs/authorization.md
• https://nexusjs.org/docs/adoption-guides/neuxs-framework-prisma-users
• https://github.com/prisma/prisma-examples/tree/latest/typescript/graphql-apollo-server
• https://github.com/prisma/prisma-examples/tree/latest/typescript/graphql-nestjs

Hasura

• Schema生成、GraphQL定義、認証周りの一部コードの作成、反映といったところまでWebUIをベースに、CLIはおまけで提供されている印象
• Migration機能や、Hasura actions などの定義によって同一機能のサーバーを定義できるようにはなっている（yml, graphlqによる管理）

• ソフトウェア開発において自分の常に追いかけている一歩外のものがどれだけ整備されているかはドキュメントレベルでは不十分である
• 技術検討においてそれらを採用するか判断するには一定の時間を有す（これを今記事では開墾と呼ぶ）
• 検討をするには必要条件と十分条件の解像度を高め、またそれに対してのフィードバックとしてYes or No以外の手札を返さなければならない

要求定義とその大きさに関して

• ゴールはイメージの解像度が高いほどよいに越したことはない
• 動かないものには価値がないので夢に対して段階的に向かっていく必要はある
• 一定のゴールが定義された場合に、まずその中で何か可能なのかを判断していく必要がある
• 何ができるのかは選択できる状態にあるべきである

要件を細分化した場合のできる・できない

• 完成したものとコストがわかればある程度の天秤から 選択できる
• 開墾し選択肢を増やすことは、またゴールと同じく無限にクオリティを高められる
• OSSに関しては、開墾先の畑は自分のコントロールが及ばない可能性はある（むしろ高い）

開墾済みの畑を持っておく・足りない畑を開墾する

• 畑を開墾済みであるということは十分にそのテクノロジーを勉強し、また投資できているということ
• 足りない畑を耕すには時間が必要だし、耕している段階ではまだ選択肢を提供できない
• 開墾する速度で勝負というチキンレースもある
• 開墾作業だけでは結果はでないし、開墾しているだけでは間接的なアウトプットにとどまりゴールはしない

現在のステータスと足りないもの

• 時間
• 期待値コントロール

• WIPなドキュメントを書くことでタスクを管理する
  • Issueのように解像度を高め消化できる状態や粒度を高めない
  • 完了状態より全体感を管理したい
• ドキュメントを残すのは得意ではないが、軌跡のoutputをslackからドキュメントツールに移していこう

永遠の課題、タスク管理

• Scrumなどを行っているとタスクの粒度が大きくならないように気を使う
  • その過程には実は多くの段階があるが脳内キャッシュに割と頼っている
  • タスク化するまでのタスクは？
  • タスクとは、6 時間以内に終えられるものである としている
• 脳内で考えていることを雑に記録する方法として 分報 を利用することや会社が増えてきた
  • 個人的には日報は得意ではない
    • PRを見ればその日に行った業務がわかるように心がけている
    • 1日1PR以上公開する
    • 結果2重管理のように感じており、日報生成ツールなどを作ったりした
• 日報を分報のように捉えてタスクを管理できないか考える
  • 何をどのぐらいの時間で完了できるか 宣言しておくことは見積もり能力を含め重要である
  • 何を考えて今そのタスクに挑戦しているか
  • 何に詰まって予定通りの業務を終えられなかったのか
• 検索可能なものを記録に残す
  • アウトプットは常に足りない
  • 手に馴染んだものしか即座に結果が出せない
  • もっと努力を記録したい

タスク管理と時間管理

• https://toggl.com/ は辛い
• https://wakatime.com/ を自分の努力可視化としては雑に使っている https://gist.github.com/9renpoto/95a6308934c189cbc1db424c014f529e
• フリーランスとしては https://clockify.me/ で稼働時間管理をしている
• アウトプットによってツールを使い分けたいが、原価償却などの管理に時間を求められる場合、https://github.com/git-time-metric/gtm 等利用を再検討したい

• 目的を持ってコードを書く
• バグを生む・解決する
• 相談できる師匠に出会う

自身のエンジニア人生を振り返って

今となってはは当たり前のように扱っている下記のようまものからスタートしたわけではなかった

• Git(hub)
• Editor
• 特定のプログラミング言語
• Agile開発
• Terminal
• docker / VM開発
• middleware

転職活動をする際に伝えたり、また面接官として技術能力を確かめるためのヒアリングなども専門領域のものが多い。 ではプログラムを習ったことがない初心者はソフトウェアエンジニアを目指す場合何を話せば良いのか

自分が師匠の立場になった場合

直近1年少し、プログラミング経験はゼロではないが業務経験はほぼゼロの学生出身と仕事を行った際のメモ。

1. チーム開発業務をこなしたければまずGitを使った開発フローを習得する
2. テストを書く
3. 境界線を作らないソフトウェア開発（※ ex. frontendとbackend)
4. OUTPUTを出すサイクルを小さく
5. 完成を定義できる・完成させる

自分が師匠と出会い、大事だなと思った教わったこと

1. プロダクトにこだわる（品質でもプロダクトとしても良いものを作る）
2. 感覚だけでなく計測する
3. テストを書く
4. 境界線を作らないソフトウェア開発

組織やチームなどにも依存する話ですが、自分はプロダクトに関わりたいことや、またそのoutputにこだわる姿勢によく共感していた。 それに必要な過程や手段としてソフトウェアを捉えていて、共通知識で使える資産としてテストとKPI/パフォーマンス等、根拠を計測することを得意ですと表現することが多い。

小さいチームでは境界線を作ってこだわっているだけでは仕事が進まないことが多く、そのために職種の殻を破ってデザイナーやプロダクトオーナー、経営者にも意見を言えるような姿勢を取ることが大事であるとも思う。 ただ上記のことは座学では学べない、肩書ソフトウェアエンジニアとしてご飯を食べるようになってから学んだことである。

ソフトウェア開発を体験できるアカデミー・ハンズオン

何かの方法でチームソフトウェア開発を実行することは非常に学びがあるとは思う。 自身は情報学の大学を専攻しており、その単位や研究の中でソフトウェア開発（らしきもの）を無知として体験した。

就職して以降そのやり方を使うことはなく、反面教師としてなぜ今のやり方を行っているのかと説明するための根拠としてその経験は役に立っている。 大学等以外でソフトウェアを勉強するカリキュラムやアカデミーを学外で受講している方の話を聞ける機会があったが 自身が行っているソフトウェア開発に近い体験で行われているようには感じた。

結果としてそのアカデミーを卒業した方は別の業種についていたが、 ソフトウェア開発社としての肩書を得てそれでメシを食う、今の専門分野を離れソフトウェア開発の世界に飛び込むのは勇気のいる取り組みであると思う。 自分は学業の延長線上でソフトウェア開発エンジニアを選んだが、それでも業務のことを大学でなったわけでもなく、 業務に必要なことは業務を初めてから世界が広がったように思う。

勉強することは無限に存在しているので、自分が何を優先して勉強するのかは選ばなければならない。 現在は長期インターンだったり専門職バイトだったりが良いのだろうか。

まず何を学べばいいですかと言われると、とりあえず「githubを用いたpull-request開発」とCIを用いたテストの実行をせよ、言語は問わないという課題を出す。

refs: https://github.com/jestjs/jest/blob/v26.0.1/packages/expect/src/matchers.ts#L196-L212

toBeDefined(this: MatcherState, received: unknown, expected: void) {
  const matcherName = 'toBeDefined';
  const options: MatcherHintOptions = {
    isNot: this.isNot,
    promise: this.promise,
  };
  ensureNoExpected(expected, matcherName, options);

  const pass = received !== void 0;

  const message = () =>
    matcherHint(matcherName, undefined, '', options) +
    '\n\n' +
    `Received: ${printReceived(received)}`;

  return {message, pass};
},

(P)react / Next.js ██████████████████░░
           GraphQL ███████████████░░░░░
               CSS █████░░░░░░░░░░░░░░░
      Node/ NestJS █████████████░░░░░░░
     DynamicTyping ██░░░░░░░░░░░░░░░░░░

https://gist.github.com/9renpoto/a7f7a2a4dead3bf5c95d8898a62e1cec

何ができるのか改めて考える

• 2020年
  • https://gist.github.com/9renpoto/a7f7a2a4dead3bf5c95d8898a62e1cec
• 2019年
  • TypeScript / (P)react / Next.jsチョットデキる (refs)
  • TypeScript / Nest.js (express) チョットデキる (refs)
• 2018年
  • TypeScript / Reactチョットデキる (refs)
  • Perl / Python / Scalaチョットデキる（refs)

できないこと

大前提として業務で経験がないことはできないに等しい

• 興味があるが実務経験がないことは 今すぐに できないこと
  • Vue / Nuxt.js / Vuex
  • Angular / AngularJS
  • クロスプラットフォーム（RN + RNW,Flutter + Flutter web, etc)
  • CSS設計
  • Elm
  • Elixir / Phoenix
  • iOS(Swift) / Android(Java/Kotlin)
  • SRE
  • 社内インフラ
  • 並列処理 / 分散処理（研究していたレベルのモノ）
• 業務経験はあるが他社で役に立つのか不明なこと
  • チームビルディング（正直メンバー次第）
  • 外注（フリーランスを含む）
• 全く関わることのなかったこと
  • 資金調達
  • 機械学習
  • ファームウェア / 基盤

どうなりたいかと、それを選ぶこと

• ありがたいことにお声がけいただく会社の多くは即戦力であることを期待されている（と感じる）
• 定期的に仕事がなくなる危機感を感じるのでプライベートで素振りを行いたい気持ちになるが、公開されているコードにはまだそのレベルに達していない

何でもできるは何もできない

• なりたくないなと思っていたけど、旬を過ぎてそうなってきている
• 成長（コミット数）が止まったら能力衰退が加速していく恐怖（定期）
  • エンジニアリングと仕事
  • フルスタックと器用貧乏
  • 勉強を続けること
• 今までとやり方を変える必要は感じる

• 目標していた 10,000 コミットを超えた
• 直近1年少しは極力コードをかける環境を維持できている気はする
• publicなコミットを増やしていきたい

体感

• 毎年コミット数は基本的に増やせているつもりではいる
• 今と同じ成長割合でコミットが成長できるかというと、そろそろ時間的には頭打ちな気はする
• 結構時間をかけてビルドを繰り返しているつもりではあるが、プログラミング関連はまだ無限に勉強が必要な領域が存在している

History

• 転職などの関係で過去のコミットは少なく見えることも多い

generated by https://github-contributions.vercel.app/

• https://github.com/mentos1386/nest-raven/pull/31
• @nest/graphql は apollo-server のwrapperで @nest/common のエラーに対する対応が弱い
• @nest/graphql を使いながら一部のAPIを REST を用いて表現することはある (ex. authorize)

Service

• Service クラス内で扱われる例外が apollo-server-errors とは異なる
• 様々な例外をgraphqlでもrestでも評価できる形にする必要がある
• Exception filters を駆使して例外を整理する？
  • 何れにせよNodeJSの例外処理は貧弱で、無駄にpokemon exception handling を作りたくはない
  • エラートラッカー自体がエラー出すと本末転倒

Refs

• https://github.com/apollographql/apollo-client/issues/4547
• https://github.com/apollographql/apollo-server/tree/master/packages/apollo-server-errors

• preact-compat を使って react-test-renderer を都合よく動かせなかったのでテスト時には react に依存する
• core-js-pure がwebpackの設定次第で意図せぬ変換をされてエラーになるので exclude

Preact only development

• preact with next.js の環境を想定する
• preact/compat を使わない preact 開発はまだ開発環境として足りないことが多い
  • テスト周り
  • 既存 react 周辺ツールの多さ
• react-test-renderer の快適さ
  • enzyme であればの代替できる？
    • ちゃっかり内部で react-test-renderer に依存している
• https://github.com/preactjs/enzyme-adapter-preact-pure
  • 試したいけどpreact onlyで開発できるほどのコンポーネントがほしい
  • https://github.com/prateekbh/preact-material-components を見ているけど中身 esmodule buildでテストを書いたりするのが辛い
  • next.js っぽいなにかが使いたい（まだ見つけられていない）

Refs

• https://github.com/9renpoto/ranking/pull/1342
• https://stackoverflow.com/questions/57361439/how-to-exclude-core-js-using-usebuiltins-usage

• findy-codeで10位だったそうです (昨年25位）
• スキルは変更を図っていますが、スキル値はまったく変動なし
• GraphQLとアプリを書きたい

芝生

• スキルの変更を図ってることもあり昨年よりは温かい

振り返り

- 無職でしたが、年明けより新しいお仕事をいただくことなりました

ありがたいことに現在の職場で技術的な観点では挑戦も含めて働くことができています。

- とりあえず、まだフリーランスを継続することになりましたので、確定申告がんばります

今年も確定申告を迎えることに。

- publicな環境で運用されるプロダクトを作りたい。偏差値を上げたい。仕事がなくなる

偏差値は全く変化せず、マネジメント経験を入力するとfindy内の想定年収は上がった

来年

• 親知らずを処理する
• 全く未着手なスキルを減らす（アプリ、インフラ）
• 部屋が手狭で辛いので何らかの手を打つ

過去

• 2018 年終わり
• 2017 年終わり
• 2016 年終わり

• https://www.stackshare.io/9renpoto
• Rails => NestJS
• Swagger => GraphQL
• React => Preact
  • https://github.com/9renpoto/frontend
  • https://github.com/9renpoto/ranking
• Self make auth => Firebase

NestJS ( with GraphQL )

• type-graphql is cute
• We needs some SaaS (Stripe, Firebase, etc)

GraphQL

• Type is justice
• Still challenging
  • Apollo
  • Relay
  • graphpl-react

Preact

• Preact X is cute
• Small is worth

Firebase

• We don't want to manage passwords

• Bought a domain 9renpoto.dev
• I'll do my best

• type-graphql + typeorm でdefition 管理は割とちょうど良さそう
• schema管理とresponse interface 管理はいつも悩ましいがある程度統一的に宣言できる

Entity と @ObjectType を併用してかける

• https://github.com/9renpoto/frontend/pull/1115
• 型情報が近いものを記述する形になるが、宣言的に記述でき、かつどちらかだけ必要なものを書き分けられる
• createdAt, updatedAtなど共通型を継承して管理できる？ https://github.com/9renpoto/frontend/pull/1127
  • => @Entity に見えないとColumnsと評価できないため継承することは難しかった https://github.com/9renpoto/frontend/pull/1156

• GraphQLは万能ではない
• Code firstをもう少し素振りする

Graph QL

• GraphQLのサーバー実装ができないか NestJS を素振りしている
• Swagger等でDefinitionを管理する機会を数度経験したがコードとの乖離が苦しい
• Code firstまで言わずともある程度型が一致してほしい
• 別にClient のコードまで生成しなくても良い（むしろ品質が悪いぐらいなら使わない）
• Interfaceは乖離しないようにしたい

Must to have

• Frontend, Backend共通のものとして（片方から｜両方）生成できる
• CIで乖離を検知できる

Want to have

• 実装が先行しない状態を許容できる（Schema first)
• Generateフローが単方向
• Apollo とかState 管理まで面倒見る気みたいっすよ？

Nest + GraphQL

• Schema first or Code First を選択して利用できる
  • Schema firstでは実装を縛れない判断でCode First type-graphql で実装
  • TypeORM のコードをしばれるコードが生成できないと辛い => (要検討）
• Service ClassをCIしてORMにつなげていける？
• @next/graphql は薄いwrapperで基本的には GraphQLを意識すれば良い？

• https://www.sunsama.com/ githubの時間管理の弱さを補うためになかなか良い使い心地
• 様々な連携と柔軟性
• カレンダーとタスク管理というシンプルなアプローチの心地よさ

Sunsama.com

• もともとsunriseというカレンダーのファンであった
  • Outlook チームに合流したのはともかくサービスが停止したことに非常にがっかりしていた
• waffle.io が close してがっかりして タスク管理ツールはGithub Projectに絞っていこうと努力を始めていた
• 見積もりの甘さやタスクがさばけていないという問題には結果的にゆるく向き合う形であったが、自分のマネジメントとしては少し計画の可視化をしたいと思っていた
  • => 連携の心地よさが今回の要求とマッチ

Github & Project

• Github issueを仕事で使っているが、変わらずmilestoneによる時間管理は苦しい
• 1 issue 6 時間以内 というポリシーで基本的にタスク分割を目指している
• 目標実装時間は1/3の2時間として活動を目指す
• タスクの差し込みやレビュー、マネジメントやバグなどの対応によるタスク集中期間が取りにくい環境であることもあり、タスクマネジメントや工数実績管理などは実質諦めていた
• git-time-metric/gtm を試して、 wakatime で大枠の作業時間を計測・可視化するようになった
• 全体として時間管理をしたければGithubは向いてない

• 設定ファイルの中に一部環境変数を適応したい
• 環境変数を読み取るには Lua などで拡張することが必要
• Docker上に変更のための構造をできるだけ入れたくなかった => envsubst を使って置換する

Dockerfile

• alpine を使っていると bash もなかったり sed もなかったりでconfを置換する方法がない
• envsubst を使って入れ替えてしまうことが推奨されている？

FROM nginx:1.17.1-alpine
COPY ./nginx.conf /etc/nginx/nginx.conf
COPY ./conf.d/default.conf /etc/nginx/template/nginx.tpl.default.conf
COPY ./bin/docker-endpoint.sh /bin/docker-endpoint.sh
ENTRYPOINT ["bin/docker-endpoint.sh"]

#!/bin/ash
cat /etc/nginx/template/nginx.tpl.default.conf \
  | envsubst '$SERVER_NAME' \
  > /etc/nginx/conf.d/default.conf

echo "###############################"
echo "# SERVER_NAME=${SERVER_NAME}"
echo "###############################"

/usr/sbin/nginx -g 'daemon off;' -c /etc/nginx/nginx.conf

• https://hub.docker.com/_/nginxz
• https://mpon.hatenablog.com/entry/2018/02/07/200000

# NoMethodError
if a.b.preset?
  a.b(c)
end

defined?(bacon)
# nil

• https://www.rubyguides.com/2018/10/defined-keyword/

• TypeScriptで　Omit がサポートされた
• UnionTypesから Omit する難易度が高い

formik-material-ui

• https://github.com/stackworx/formik-mui/pull/82
  • 公式の Omit はUnionTypesでもサポートしてるっぽい？🤔
• https://github.com/microsoft/TypeScript/issues/28791
  • もともと、UnionTypesからOmit するためには全部入りみたいな状態にしてそいつを対象にPick, Exclude している？
• https://github.com/sindresorhus/type-fest/blob/master/source/omit.d.ts#L17
  • type-festはUnionTypesのことは考慮できていない？

• people / money / time is limited
• i do not know now about the person who will be adopted in the future
• i cannot do everything at the same time

No one can take responsibility

• size of the task
• ability
• schedule
• trade off

Finaly

• Concentration and selection

Currently, we are trying to substitute alternatives using github project and auto-assign, but we have not reached the point of request.

Thank you for waffle.io team works.

• https://help.waffle.io/waffle-shutdown/migration-to-github-projects/migrate-to-github-projects

• dependabotが mix.lock に対応したため追いかけたいライブラリへ依存したい
• phoenix 一強時代と読んで追いかける

https://github.com/9renpoto/phx

前々から興味はあった

• 言語標準formatter最高
• monorepoに近い感じで作れるっぽいのが作れる
  • https://elixir-lang.org/getting-started/mix-otp/dependencies-and-umbrella-projects.html#umbrella-projects
  • 感覚は yarn workspace に近い
  • マイクロサービス組むときに出せる手札へしたい

Links

• 似たようなところまで頑張りたいシリーズ
  • https://github.com/9renpoto/ror
  • https://github.com/9renpoto/play

• いろんな会社に話を聞きに行ったが、まだまだ世界はRails
• そうだRailsを学ぼう
• とりあえず数時間だけ作った、 getting startedを進めていきたい

https://github.com/9renpoto/ror

Ruby を手に入れる

• brew install ruby で雑に使っていたわけだが流石にバージョンを固定する
  • 過去はrbenvを使っていたけれど using asdf instend らしいので別で検討する
    • omf/plugin-rbenv でも良かったけれど更新されてない
  • とりあえずメンテされてそうな rstacruz/fish-asdf を入れる
  • asdf そのものは brew で入れて、かつ /usr/local/bin を使っていないためイマイチ動きが合わない
  • asdf 公式 の方法でactivate する（refs）

Rails new

• Rails projectを作るためにRailsを入れる必要がある
• とりあえず Docker compose 公式の方法でプロジェクトを初期化する

Rubocop を入れる

• どんなものなのか、とりあえず rails のものらしい 設定を採用する
• 一部formatしてくれるし便利な様子

現状

• lockfileがあるけど CI 上だけ Fail する。つらい
• rspecは標準ではscaffordされないのか、と思った
• まだcoffee-scriptっぽいものを持ってる
• e2eテスト系のフレームワークにも依存して、どっしりしている

とりあえず目指す着地

• DB依存してテスト書く
• redis依存してテスト書く
• coverage report出す
• 噂の webpacker とかに依存する
• hypernova-ruby とかに依存する

• findy-codeで25位だったそうです
• 偏差値は高くないです

芝生を温める

ここ2,3年、勉強するために芝生を温めている事が多いです。 芝生が温まっている要因は、大きく3つです。

1. コードを書く仕事を行う。積極的にコード化する（private)
2. ライブラリに依存する。自動でライブラリを更新する（public)
3. テストを書く（public)

この3つにこだわってコードを書いています。 コミット数だけで数えると、private / publicの数は同数ほどです。

個人で良いライブラリを書いたり、公開や継続的にメンテナンスをしているものは多くないため、偏差値は低いです。

ライブラリ、アプリケーション未満のものを書く

正直、publicなコードは中身ないものが多すぎます。 主な目的は、ライブラリに依存し、テストを書くことです。

この活動のメリットとしては、下記のようなものがあるため続けています。

1. テスト基盤を書くということは、基盤の知識が必要
2. コードの品質が気になるプロジェクトは、テスト不足が多い
3. 一度作ってしまえば、ライブラリの更新で壊れる（再現できる）

ライブラリの開発などと違うため、どんどん上げてどんどんビルドしています。 ときには、1repo multi test frameworkとかAltJS の混在環境構築などの黒魔術とぶつかったりもします。

芝生を支える術

上記のような活動には、外部ツールが発展してきたことが大きな継続できている要因になっています。 今では下記のようなサービスの利用は必須です。

1. CI
   1. 仕事でも依存しているし素振りしておくと便利
   2. travis, ciecleci, werckerciなどを使うことが多い
2. Dependency management
   1. JS系はrenovate
   2. その他はdependabotなどが多い
   3. 対応言語、automergeがあるものなど便利すぎる
3. Project management
   1. waffle.ioを好んで使ってます。ラベル連動便利
   2. PRを見逃さない

来年

• 無職でしたが、年明けより新しいお仕事をいただくことなりました
  • たくさんのお声がけを頂きました。誠にありがとうございます
  • 今回は前回よりもたくさんの方や会社のお話を聞くことができました
• とりあえず、まだフリーランスを継続することになりましたので、確定申告がんばります
• public な環境で運用されるプロダクトを作りたい。偏差値を上げたい。仕事がなくなる

過去

• 2017 年終わり
• 2016 年終わり

• 評価をするのは難しい

そもそも評価とは

• 仕事であれば、最終的に単価を決めることであるとする
• 単価は、その人（や物）の市場価値
  • 需要と供給によって変動する
  • そうであってほしい
• 定量的なものと定性的なものがある
• 多くは主観も含まれる

評価の誤差と対策

• サイコロを振る
• 評価制度なし
• 他に特徴的なものがあれば知りたい

エンジニアの評価

• 一列に並べられない場合も多い
  • これはこの人、あれはあの人
  • お互いに尊敬できているという関係
• 強み弱みとか、何をやったことがあるかぐらいは言える場合が多い
• 職種に限らず、会社の資産は有限

だから何

• 評価システム を勉強がてら書いているが進捗が芳しくない
• 年末までに動いてなくてもホストしたい

• next/config をとりあえず使う

webpack.DefinePlugin を使う

• refs: https://github.com/vercel/next.js/issues/3605
• なれてるし使いたい。わかる
• イマイチ推奨されてないようで、 複数のサンプルが紹介されている

babel-plugin-transform-define を使う

• refs: https://github.com/vercel/next.js/tree/deprecated-main/examples/with-universal-configuration-build-time
• babel7に対応してない（2018/12 現在）。PR はあるけれど放置されている

dotenv-webpack を使う

• refs: https://github.com/zeit/next.js/tree/canary/examples/with-dotenv
• dockerの下りで .envrc ではなく .env を利用するプロダクトが増えた
• よしなに展開してくれる

標準で用意されている仕組みを使う

• refs
  • https://spectrum.chat/next-js/general/runtime-configs-with-process-env~55b503c2-07f4-4da3-9ba4-287733b3d622
  • https://github.com/vercel/next.js#exposing-configuration-to-the-server--client-side
• clientでは配信したくない環境変数とか確かにある
• 面倒だけれど別々に宣言的管理する

• ガスランタン には マントル という消耗品が必要
• ノーブランドから存在するがサイズに非常に注意する

ST260

• CB缶の使い方の1つとして雰囲気のあるガスランタンを買ってみようと思い立った
• 買った際に付属でマントルがついてきたので、1度は使えた
• 次も使いたいけど、そもそもマントルなんてどこで売ってるんや。..

Amazon

• アウトドア用品を売っているスペースに純正品などあった
• 消耗品だし手に入るだろうとアマゾンで ノーブランド品 を購入
  • 多分だけどこれは少し大きめであってない。..

ランタンは良い。きちんと調べよう

• 灯りは趣がある

• https://nodefest.jp/2018/

Offline-First Collaborative Data Structures

• Collaborative P2P
• https://nodefest.jp/2018/schedule.html#conference-1-9
• https://github.com/mafintosh/noise-network
• https://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5%E6%9C%A8
• https://keens.github.io/slide/HAMT/
• https://github.com/mafintosh/hypertrie
• https://github.com/mafintosh/ims
• https://gaiax-blockchain.com/merkle-tree

Node.js: The Road to Workers

• https://nodefest.jp/2018/schedule.html#conference-1-4
• slide: https://addaleax.net/workers-nodefest/#1
• https://github.com/audreyt/node-webworker-threads
• https://twitter.com/yosuke_furukawa/status/1065793206204325888
• https://twitter.com/yosuke_furukawa/status/1065793690524823552
• https://twitter.com/yosuke_furukawa/status/1065795739521966080
• https://twitter.com/mizchi/status/1065796650495500288
• https://twitter.com/yosuke_furukawa/status/1065797831976345600
• https://github.com/nodejs/worker/issues/6
• https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_API
• https://github.com/Microsoft/napajs
  • shared JS object
• https://twitter.com/yosuke_furukawa/status/1065799544351285249

Diagnose your Node.js app

• https://nodefest.jp/2018/schedule.html#conference-2-3
• https://darai0512.github.io/nodefest2018/index.html#/

State of SEO for SPA

• https://nodefest.jp/2018/schedule.html#conference-2-4
• https://twitter.com/sekikazu01/status/1065833675688894464
• https://twitter.com/sekikazu01/status/1065825419213991937

React におけるパフォーマンスチューニング

• https://nodefest.jp/2018/schedule.html#conference-2-5
• https://recruit-tech.co.jp/blog/2018/09/19/react_spa_performance_tuning/

Web アプリを Native アプリにする Capacitor が広げる Web の可能性

• https://nodefest.jp/2018/schedule.html#conference-2-6
• https://github.com/ionic-team/capacitor

実践 GraphQL for クライアント側

• https://nodefest.jp/2018/schedule.html#conference-2-7
• https://speakerdeck.com/petitviolet/real-world-graphql-on-scala
• https://github.com/petitviolet/graphql_on_scala

Service Worker を用いたキャッシング戦略 〜Wiki アプリケーションを例に〜

• https://nodefest.jp/2018/schedule.html#conference-2-8
• https://scrapbox.io/daiiz/ServiceWorker%E3%82%92%E7%94%A8%E3%81%84%E3%81%9F%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%B3%E3%82%B0%E6%88%A6%E7%95%A5_~Wiki%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E4%BE%8B%E3%81%AB~
• https://caniuse.com/#search=network

Vue.js/Nuxt.js で実現できた PWA のリアルタイム動画ラップ・バトル・アプリ

• https://nodefest.jp/2018/schedule.html#conference-2-10
• https://riotz.works/slides/?2018-nodefest

• 退職いたしました
• 現在求人募集中です

Self

• TypeScript / Reactちょっとできる
• Perl / Python / Scalaちょっとできる

今後

とりあえず、前回も含めお声がけ頂いている会社の方にいくつかお話を伺えたらと思っております。宜しくおねがいします。

• 人に言われるまでやらないのは三流
• 自分で課題を定義できない人は二流
• 自分にできない何かを持っている人は一流

(実行する|実行しない）だと実行するしかない。 実行しない人はそっとしておく。

• 直近アウトプットの無さに危機感がすごい
• せめて考えていることを記録する癖をつけたい
• できない仕事は投げ捨てたい

集中と選択が求められる。現実を受け止める。やらないければならないことはやる。

能力を上げるためには時間と余裕が必要である。 仕様を成約も抑えながら、コードの負債を返しつつコードを前に進めるのは非常に体力が求められる。

とりあえず飲む酒が旨くない。今後どうするか考えなきゃならん。

• 夏は虫凄い
• 忘れ物致命的
• クーラーボックスの重要性

夏は虫凄い

蚊取り線香は個人用。他人に期待しても効果ない。

忘れ物は致命的

「テント（の一部部品）忘れた」という人がついにでてしまいましたが正直助けられなかった、難易度の高い問題。

今回は本人が持ち合わせていたタープで難を乗り切っていた。マネできない。

クーラーボックス

投資を考える。旨い酒を飲むには必須。

• 積載は大事
• 打ち合わせは大事

Keep

• 人脈を駆使してでもヘルプを求める
• 使い捨てをうまく駆使する
  • 発泡スチロールクーラーボックス200円便利

Progrem

• コットのフレームがおそらく移動中にロストした
  • そもそもなくなったことに気づけなかった衝撃が強い
• クッカーはほんとに使う場合を除いて不要
• B6サイズのグリルは一人用

Try

• コットのリニューアル
• 夏用シュラフを手に入れる

• 着手する見込みのない妄想をissueにすると永遠に埋もれる
• 今は着手しないけど本当に必要なことは何年先でも覚えてる
• 3か月以内にやらないことは可視化しない

• https://github.com/9renpoto/play

• とりあえずgenerateして何がでてくるか

• CIでテストを1つだけ動かす

前職の会社から入社して、早 4 年が経過しました。素晴らしく優秀なメンバーに囲まれた 4 年半で学んだことは、私の人生にとってかけがえのない財産となりました。

今まで働いていた会社では、技術職としてミッションをこなしてきました。また、技術的な挑戦に対して高い評価がもらえるため、失敗を恐れずにチャレンジできる素晴らしい環境でした。

ですが、今の環境よりも新しい環境に移ってみたくなってしまいました。

他社で働いている友人や、世間一般的な額と比較した際に、現在の職場での給与が低いことが退職を考える原因の 1 つでもありました。

労働時間にも左右されるため一概には言えませんが、自分のスキルセットを考えた際に、「今の報酬はあまりに低いのではないか？」と考えたことが転職活動を視野に入れ始めた発端だったようにも思います。

しかし、現在の仕事内容に不満はなく、待遇が悪いわけでもないため、特にこれといった転職理由はありません。強いて挙げるとすれば、チャレンジしてみたい新しいことが見つかったという点でしょうか。

まだ転職先は決まっていませんが、転職活動を行いながら自分を見つめ直す期間として、ある程度ゆっくりとできてちょうど良いかなと考えています。たっぷり時間もあるので、海外旅行をして自分の視野を広げるのも良いかもしれません。新たな価値観に触れることでまた、新たな職場での挑戦や取り組みは、書ける範囲でこのブログに書いていけたらなと思います。

思い返すと、優秀な同僚にサポートしてもらったり、励ましてもらう機会が多く、仕事でのミスやアクシデントをフォローしてもらたことは一度や二度ではありませんでした。

また、公私を問わず仲良くしてくれた後輩とは、これから仕事が変わっても疎遠にならずに交流を深めたいなと思えているので、悪いことばかりではなかったと思います。

転職先の会社では、新しい仲間たちとともにアサインされたミッションに、できるだけ早くコミットして貢献できるよう頑張っていきたいと思います。

• generated by 仕事.やめよう.みんな

退社日は5/31になります。 6/1 より働くことのできる環境などありましたらご連絡いただけますと出来る範囲で応答させていただきます。

npm i  @zeit/next-typescript

感想

• TypeScriptを使うために一度手前でtscしたりしてましたが、何時のまにか念願のサポートが入った
• 実際webpackのオプションが設定できるのだからできて当然だと思っていたが公式から来ると嬉しい

Refs

• https://github.com/vercel/next-plugins/tree/master/packages/next-typescript
• https://github.com/9renpoto/archive/pull/140

いけてるプログラムを書いても、どれだけパフォーマンスが出ても、価値が無いものには意味はない。

ビジネスとしてのプログラムが書きたいし、プロダクトを作りたい。

• 最高
• マイナス4度は対策できる

燻製

• 今回は仕込みをしないもので対応
  • チーズ
  • ソーセージ
  • 調理済み煮玉子
• 温燻
  • 桜ウッドで挑戦
  • ある程度火をつけてからやらないと時間がかかる
• 片付け
  • 激落ちくん必須

夜寒対策

1. インナーシュラフ
   • 効果はあるが遣うのが難しい
2. アウターシュラフ
   • すんなり使えました
3. 湯たんぽ
   • 最高
   • 体が痛くて何度か目覚めたが暖かさを感じられた

A post shared by Keisuke Kan (@9renpoto) on Mar 24, 2018 at 2:00pm PDT

• 結局うまく動いてない
• configをwrapするんじゃねえ頼む

Refs

• babel依存
  • https://github.com/vercel/next.js/tree/deprecated-main/examples/with-universal-configuration-build-time
• webpack依存
  • https://github.com/vercel/next.js/issues/159

• アドバイス募集

要件

• 限りなく自動でファイルをバックアップしたい
  • スマホを経由する半自動はあり
• バイクで使いたい
  • 顎マウントは可能であれば避けたい
  • タンクマウント？
  • ハンドルマウント？
• ドライブレコーダーとして
  • 安いのから開始してもいい気持ちもある
  • 自動化できないなら魅力激減

Dream

• wifi connectしてgoogle photoにauto upload

• 時代はworkflowなんですね

Travis Stages

• https://docs.travis-ci.com/user/build-stages/
  • 多分workflowをstage単位に組めるんだと思っている
  • matrixと異なり依存を自分で記述していきたい感じ
  • 個人的にはifとか便利なきがしている

Try

• https://github.com/userdive/agent.js/pull/285
  • イマイチ動いてない
  • 動くところまで頑張る

• 進化はしていってるありがたい
• 早い

今まで

• カンバンに手動ですべて追加し直す必要があった
• Cardの存在価値とは

要望

• org projectsを公開プロジェクトとしても作りたい
• templateをカスタムして保存したい
• デフォルトでAddされるカンバンを指定したい

Refs

• https://github.blog/2018-01-04-track-the-progress-of-your-projects/

Keep

• 型 / Formatter / 関数最高
• ⛺

Problem

• イノベーションが起こせていない
• 人間関係サボリ気味
• 簡易サービス運用できてない

Try

• 外に出る
• 冒険する
• 怒られる

• goodbye greenkeeper
• welcome to dependabot

JavaScript ライブラリを追いかける

• ライブラリ更新サービスは、ライブラリの更新を追いかけるのには必須のサービスだ
• 薄く依存させCIを回しているだけで簡単に壊れていく
• 無駄に芝生があたたまる

Greenkeeper との出会いと現状

• 更新が遅くなってきた
• lockファイルの登場、メンテナンスの必要性がプラス必要に
• org単位でもイケる

Dependabot のいいところ

• multi language
• lockファイルも含めて更新
• コンフリクトはPRの中でサービスが自己解決
• daily,weekly,monthlyの簡単な定期更新

まとめ

• 便利なサービスに引っ越していきたい

• travisで環境変数が引き継がれない
  • 仕様だった
• https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions

気持ち

• 理由はわかったけど悲しい
• 辛い場合がたくさんある

• 自分のエゴで書いてる手癖や無駄な努力をコードレビューするのは非生産的
• 積極的にlinterを採用

test

import assert from "assert";

describe("test", () => {
  const { func } = require("./module");
  it("func", () => {
    assert(func("a") === "a");
  });
});

1. 1ファイル、single describe
   1. 親を1つ describe.skip describe.only できれば一旦闇を保留にできることが多い
   2. 1ファイルの持っている役割が大きすぎない、特に困っていない
2. テスト対象は describe の中でrequireする
   1. describe.only 実行をした際に不要なsrcを読み込まなくて良い
   2. 読み込まれただけで実行される関数はcoverageに含まれてしまう
   3. coverage report が読みやすい
3. this を使わない
   1. unused変数をlintで発見しやすい
   2. 長い

src

function mapStateToProps({ todos }: State) {
  return {
    tasks: { todos },
    onUpdate: (id) => todos[id].done(),
  }
}

1. arrow function vs function
   1. IE11を意識した場合、変換したら結局 function となる
   2. 読みやすさと生成された後のコードを妄想しつつ相談
   3. つい書きやすさと return の省略したさで arrow function を使うことも多い
   4. 読みやすければそれでいい気持ちになってきている
2. class syntaxを避ける
   1. ライブラリを開発しているときには使うけれどプロダクトを書く時には意識する
   2. 結局 this に状態を持たせる意味がそのclassにあるかが大事
   3. ファイルサイズがデカくなる

var touch = "touch";
$("#id").on(`${touch}start ${touch}end`, (e) => {
  console.log(e);
});

function a(element) {
  // var element と書く３文字を省略して１文字にできる
  element = document.getElementById("foo");
  element.addEventListener("click", (e) => console.log(e));
}

1. 長い文字列は変数で受けて結合する
   1. 小さいことを売りにしているライブラリで見る
   2. 計算量も大事だが地道なファイルサイズ対策
2. 無駄な引数を定義する
   1. 変数定義分の文字列を節約させる
   2. htmlのタグなどを書く際に利用されている場合がある
   3. linterで積極的に使うなと怒られる（怒られる方が平和）

まとめ

圧倒的老害感。

• なんでも出来るようになったほうが良いのか
  • 現在の自分の選択は No
• 1つのジャンルを勉強するだけで年中Githubの芝生を埋められる
• リードできないと認められない
  • 仕事がなくなる
• 経験者・未経験者・年齢関係なく今を勉強しないと使えない
  • 苦痛に感じたら向いてない
  • 立場ではない、出来る人がすごい

過去の自分

• 勉強会にいけば少しでも進歩出来ると思っていた
  • 完全に No
  • 自分は頭が悪いので手を動かさないと身につかない
• 輝かしい技術・アーキテクチャ
  • 流行り物は正義である
  • Yes もあり No
  • 理解しなければ指を加えて見てるだけ

仕事と自分

• とりあえず無能さを痛感する毎日

とりあえず必死に生きる今

• ビルドする
• 破壊する
• 書く、書き直す
• 手札を増やす
• 動かしてないものはいざとなったときに使えない

まとめ

• たまにはまともと認められるコードを書きたい
• 思想が間違っていないか議論したい
• メンターがいないしメンターとして認められるわけでもないのでモチベーションが厳しい
• 過去の自分を否定するためにコードを書く
• すぐリードできなくなるので別のことを勉強する

1. 完成した後に後出しジャンケンで要件を伝えるのは悪
2. 変更はすればいい。「出せない」を言うのは何時何時であれ遅いので、言いたいやつは目を凝らす
3. そもそも、出せる・出せないを判断する人間はプロダクトから目を離すべきではない
4. 決定を譲渡できないのであれば人の3倍目を凝らして稼働しろ
   1. 決められない人間はオーナーではない
   2. 外からの要件を100とする行為も同義
5. 言った言わなかった論は不毛
   1. 誰も報われない

• vimrcもtomlで書く時代になったのか

before

• vim-plug が流行っているらしいから使っていた
• vim bootstrap で作成したものを使っていたが、これがさっぱり動かない

after

• とりあえずlightline, vim-guttierいれて簡単なコードを読めるように
• https://github.com/9renpoto/dotfiles/pull/106
• https://github.com/9renpoto/dotfiles/pull/107

暇を見つけて育てる。

• 誰か初期状態を持っているのかはっきりする
• 初期状態が定義されるタイミングを考慮する

SPAの鬼門は State 管理であるといって過言はない。

今回は初期状態について現在考えていることをメモする。

前提

• URLはRestとする
• ページ内から幾つかのAPIにアクセスする
• 内部は複数のURLからなるSPAで構成されている
• 自分が設けている前提
  • 同一URLを表示したときには同一のAPIリクエストが発行されるべきである
  • または期待される結果が同一である（後述）
• APIリクエストの組み立てに必要な状態
  • location.href
  • 初期状態

例

• https://www.airbnb.com/
  • parisの宿を探す、一覧が出て来る
  • ただ、このURLには 暗黙的に今日以降 という日付範囲が適応されている
• https://www.airbnb.com/
  • checkin, checkoutの範囲を指定する
  • カレンダーに適応した日付の範囲と、その範囲内で検索できた対象の宿が表示される

SPA と状態

airbnbのようなカレンダーのような絞込みを提供している機能のことを考える。

• SPAが初期状態を持つ場合
  • 初期状態はJavaScript がダウンロードされた際に決まる（今回は遅延で初期状態を定義することを除く）
• URLとSPAの状態が乖離する場合を考える
  • カレンダーの操作をしているが確定処理を行っていない
  • 画面には途中経過が表示されている（SPAのstateは更新されている）
• 初期状態がURLにあるとする場合
  • SPAに流入しJavaScriptがダウンロードされたタイミングと同一とは限らない
  • 上記の場合、期待しない初期状態からクエリを発行するため期待と矛盾する

状態の整合性を取る

• 遷移をした場合に状態の整合性をとるactionを onUpdate に書く場合
  • locationを引数として状態更新のアクションがもう1回Fluxを回る
  • onUpdate で再度整合性チェック、必要があればデータ更新
• 不必要なURLとstateの整合性を取るための再帰
  • 不採用

考えた選択肢

1. 検索条件をサーバから受け取り、検索条件表示と結果の乖離をなくす
2. 初期状態の定義をURLから生成できるよう、参照する状態の初期化を遅延する

reduxの場合、後者の方法はわからなかった。

まとめ

日本語難しい。

Happy Hacking!

• Reactの場合
  • 見た目に必要なものはJSXだけで Component である必要はない
  • Component はライフサイクルを持つ
  • Containers はデータとの関係性を持つ

Functional Component

• Reactのドキュメントを読んでいるとReact.Componentをextends して書く必要があるのかと勘違い
• DOMの定義を書くことはJSXのsyntaxだけで完結されている
• JSXで書かれたものとCSSを紐付けたもとを 見た目 と記述した場合
  • 見た目はどこのデータに紐付けられるか定かでないため、ライフサイクルを自身で定義するべきではない
  • データを渡してtreeを構築するために必要な情報を返すだけでよい
  • https://github.com/9renpoto/style/pull/228

Component

• ライフサイクルと見た目を紐付けることに集中する
• 自分が実現したいライフサイクルを実現できるか考慮して、コンポーネントの大きさを決める

Containers

• データを紐付けるだけ
• Reduxを使った場合、Component とは完全に疎結合に定義できる
• ライフサイクルを意識した必要なデータは Component の中にあるため、素直にデータを紐付ける
• 初期状態の記述には気をつける

まとめ

• 世界はよく考えられている

• JavaScriptが苦手な方にという発表を社内でしました

slides

• slides
• events

まとめ

• 中身の無い話をダラダラと長く話してしまった
• 反省している

• 期待通りに動かない

npm or yarn

• npmClientを指定できるようだが、yarn を指定すると永遠にインストールが終わらない問題に出くわす
  • https://app.travis-ci.com/9renpoto/eslint-config/builds/281805776
  • concurrency=1 を指定するなど試すもretryしてやっと動く程度
    • 期待するportに接続できていない？
• npm v5
  • 何故かlernaを通してやると dependencies がroot に展開されず見つからない場合がある
  • ディレクトリ直下でやると問題ない場合がある
    • バグっている気持ち

lerna bootstrap

• 共通packageとは、本当はディレクトリ直下で行いたいができていないようにみえる
  • lerna version 2.2.0
  • 結局複数installを求められるものがある？
    • eslint
    • typescript
    • flow-bin

まとめ

• 原因は調べきれていないが、lernaが原因で使えていない問題はいろいろありそう
  • issueは200以上ある
• 早めに地雷を踏んでおく

• インカムは良いものだ、世界が変わる
• タンデムなどにもおすすめできる

BT-X1

体験というところで安価なものから選定して購入しました。

• インカムとしては問題なく
• 通話中は音楽・スマホ音声も届かない
  • 困るかと思っていたけど、「次曲がるぞ」などの会話があれば特に機能面では問題はなかった
• 切り替えはボタン1つ
  • オフにすれば音楽再生に戻れなかったり？
  • バグっぽいのでファームウェアを上げて様子を見る
• 音楽の音量調整
  • 環境音に合わせて音量が変わる
  • 音量が大胆に変わりすぎてもはや別の音楽になるので、この機能は個人的にはオフにして様子を見る
• 二人通話
  • ツーリング仲間が増えてから問題について考える
• BT-Talk
  • 何かできそうなきはしたけれど、音声通話アプリを使えばよくないか？という気持に
  • 特に優位性を判じられず

総評

• 壊れたら別のメーカも含めて高いものに買い直す価値はある
• そうだバイクに乗ろう

最後に

今のバイクで初めてコケました、悲しい。

• lernaは大きすぎないpackageを複数管理するときに割りと便利
• lernaで便利なものと、対応していないものがある
  • flow-typed, etc

Lerna

• babel等で使われており存在は知っていたが、プラグイン等を管理するようなpackage を持っておらず使うつもりはなかった
• greenkeeperに対応していない
  • issueはあがっている
• releaseコマンドを普段使わない
  • git master commitの発生が気に食わない
  • 素直にpublishだけしてほしい
• それでも環境を分ける場合が増えてきたので使ってみる
  • eslintrc
  • babelrc
  • tsconfig

入れてみた

• https://github.com/9renpoto/js
• https://github.com/9renpoto/ts

勉強

• 先を見るために今を見る
• 今の何が大事かは、最初はテスト環境だと思っている
  • テストが走る
  • ライブラリ特有のテストがかける
    • jsx,tsx
    • vue
  • カバレッジが取れる
  • 現実的な生産性が見える

• TypeScriptもprettier正式採用で快適フォーマット
• eslintも進んで来ており快適に

Prettier

• すっかり気に入って使っているが、TypeScriptも正式サポート始まり嬉しい
• 型定義ファイルのフォーマットにも対応

入れてみた

• https://github.com/arvitaly/chrome-jest-mock/pull/1
• 本質のロジックに集中できるのはありがたい

• Infection blocked に引っかかった
• ご認識の可能性は未報告

経緯

1. avastが警告を発しあるモジュールがダウンロードできない
   1. https://github.com/takuyaa/kuromoji.js/issues/19
2. virtualbox上で警告のあった指定箇所を確認
3. 修正
   1. https://github.com/takuyaa/kuromoji.js/pull/20

心情

• チェックされている感じを久々に感じる、が懸念されている内容とその正規表現が理解できなかった
• セキュリティは難しい

雄町はうまい。

至福の一杯。

• 本当に必要なのはドキュメントなのか考えましょう

Living Documentation

• 納得した資料（client-side-ddd-on-github）
  • 良いドキュメントには自動化が必要
  • 最も良いドキュメントはno document

リーダブルコード

• 過去ログ
• コメントは領域に対する情報の比率が高くなければならない

自分の考え

• ドキュメントを書くつもりでテストを書く

• Doc Test不要論

  • 動かせるのでメンテナンスはされている（Good）
  • ソースコードよりも長いテストを書くことは珍しくない
  • ソースの情報が増える、が情報の比重が高いとは限らない
    • それなら綺麗にテストを書く

• ドキュメント生成

  • JSDoc, esdoc
  • FlowType, TypeScript の型定義ファイルなどの登場によりその役割は不要になりつつある気持ち
  • ソースコードの情報比率の高まりも重要
    • 可読性
    • 補完

• 動いているものには価値が高い

  • storybook
  • style guide

• 使い始めるための最短ルート

このエントリーの価値

読まれなければ意味がない。

• 記事をかけていないことを可視化する
  • https://github.com/9renpoto/entry/pull/22
• やる気を出す

contributions calendar

• githubのカレンダーによるフィードバックはモチベーションにつながる
• コミットすることが生活の一部になってきた

記事がかけていないことを可視化する

見事にサボっている。

next

無駄にauto-completeつけたい。

• gatsbyjsでブログを立て直した
• goodbye hugo

経緯

• Hugoを使っていたが Go Template に勉強要素がなかった
• SPAベースのブログとして拡張可能なものを探した
• その他に検討したもの
  • nextin
    • next.jsベース
    • cssの扱いで苦戦
      • https://github.com/kriasoft/isomorphic-style-loader
    • いい加減 jsx extension使わせてくれ
  • nuxt.js
    • React優先したら後回しに

作業内容

https://github.com/9renpoto/entry

• https://github.com/gatsbyjs/gatsby-starter-blog
  • 不要な依存を削除
  • SSRするために style-loader が使えなかったため static ファイルを参照するアプローチ
    • https://www.gatsbyjs.org/docs/importing-assets-into-files/

• fishshellに移行した
• fishermanを導入したらほぼ独自に記述することがなくなった
  • fishfileだけ管理していれば良さそう
• 補完的に速度が気持だけ遅くなった？
  • 設定が必要？

作業内容

https://github.com/9renpoto/dotfiles/pull/98

• 実はbashだったりzshだったりのsyntax に依存しているところを細々と直していくことは必要
  • tmux,keychain,PATH

Refs

• https://muunyblue.github.io/7476533956dd3568c1d787c5d33a547f.html
• https://blog.odoruinu.net/2017/02/24/changed-my-shell-from-zsh-to-fish/
• https://github.com/jorgebucaran/fisher

調べてないこと

• hyper termが起動しなくなった

• brew cask --language オプションが治りました
• firefix nightlyがインストールできるようになりました

気持

めでたい。少しFirefoxをデフォルトブラウザとして頑張る。

➜  ~ brew --version
Homebrew 1.2.4

Before

• brew caskにlanguageを指定するらしいけれど

• nycが公式でサポート
• 事前のtscしてremap-istanbulしなくても良くなりました（後述）

Usage

• 公式ドキュメントをそのまま記述
• https://github.com/9renpoto/ts/pull/93

メリット

• 前回
• tscする一手間を省略してts-nodeに任せるだけでよくなりました

Refs

• 公式ドキュメント

• 動いてくれ頼む

Log

➜  ~ brew cask search firefox
==> Exact Match
firefox
==> Partial Matches
firefox-beta firefox-esr firefoxdeveloperedition firefoxnightly multifirefox
➜  ~
➜  ~ brew cask install firefoxnightly --language=en
Error: invalid option: --language=en

Refs

• https://rcmdnk.com/blog/2016/10/31/computer-mac-homebrew-firefox/
• https://github.com/Homebrew/homebrew-cask/blob/master/doc/cask_language_reference/stanzas/language.md#installation

追記1 [2017/06/25]

• 修正リリースを待つ
  • homebrew-cask/issues/35448

• google optimizeで今適応されているテストは何か調べた
• テストの結果はfirst party cookie
• _gaexpという名前で記録されている
• 規約は読んで自己責任で参照しましょう

軽く調べた結果

• 公開情報
  • _gaexpという名前で記録されている
  • cookieはデフォルト90日保存

おそらく操作しているところ

• m[0] は experimentid
• m[2] がテストのパターンを表している
  • cookieの一番最後のnumber
  • これだけだと variationid としては使えないので何かと複合してユニークになっている
• m[1] はnumberだが何の値かはすぐにはわからなかった

Zg = function (a, b) {
  const c = b.match(/GAX1\.([^.]+).(.*)/);
  if (c) {
    let d;
    a: {
      const e = (c[1] || "").split("-");
      if (!(e.length == 0 || e.length > 2)) {
        const f = ia(e[0]);
        if (f.length != 0) {
          const g = e.length == 2 ? ia(e[1]) : "1";
          if (uf(f) && uf(g)) {
            d = new Og(T(f), T(g));
            break a;
          }
        }
      }
      d = void 0;
    }
    if (d) {
      for (
        var h = new Qg(d, a.qa, a.ha), k = (c[2] || "").split("!"), l = 0;
        l < k.length;
        l++
      ) {
        const m = k[l].split(".");
        if (m.length == 3) {
          if (!uf(m[1])) {
            return;
          }
          Ug(h, m[0], new Pg(m[2], T(m[1])));
        }
      }
      return h;
    }
  }
};

Extra

• stackoverflow
  • ABテストとしてJavaScriptが実行できるので、自分でユニークなID を配信して実行されているテストを特定しましょう
  • リバースエンジニアリングして危ない道を渡るよりも現実的
  • ちゃんとABテストの記録は計測できます、そうgoogle analyticsならね！

Happy Hacking!

• SSRかと思ったら静的サイトも生成できる時代
• 良い素振り環境であれば進んで移行

gatsby

https://jamstack.org/generators/gatsby/

• React ベースで、ブログやドキュメントのような静的サイトを生成出来るツールとして様子を見ていた
• webpack v1系の依存が取れなていない
  • webpack v3-rcが来てしまったことを考えると厳しそう
  • @storybook/reactの苦い経験
• Routerの素振り環境として魅力的だったものの尻込みしていた

nuxt.js

https://jamstack.org/generators/nuxt/

• inspired by next.jsなライブラリ
• 存在は知っていたがまさか静的サイト生成が可能らしい
  • staticgen.com参照して気づく
• 触ってみる価値はあると判断
• RSSなどブログっぽいものはない可能性

next.js

• next.jsも同様に可能？
  • https://github.com/vercel/next.js/issues/604
• 普段はReactを触っていることが多いため可能ならこちらから

i18n-webpack-plugin

TL;DR

• 必要最低限の機能・サイズになる
• 事前にi18n後のJSとして複数のoutputとするアプローチ
• できることはシンプル（現状）

懸念

• テンプレートエンジンなどでlocale特定が必要？
• sprintfのような表現には対応していない
  • 議論中 i18n-webpack-plugin/pull/42
• 読み込むlocaleファイルの生成には関与しない
  • 手動でJSONは作成、メンテナンス

現状

• 様子見
• 簡単なサンプルを書いて依存はしておく

@storybook/react としてv3.0.0-rcがリリースされました。

storybook

webpack v2 の流れもあり開発が止まってたstorybookの開発が、 別のコントリビュータが入ったことで再開された。

@kadira/storybook から @storybook/react へ名前を変えてめでたくrcがリリースされることなったようです。

• 対応したPR https://github.com/9renpoto/style/pull/160

ドキュメントの更新はまだ遅れており細かな変更も追いかけてはいませんが、中身は大きく書き換わっているようです。

めでたく webpack v2 にも対応しています。

• !default で定義されているvariableは @import 前に定義する

_variable.scss

css に変数があることはわかっていたつもりですが、上書きの用法がよくわかっておらず調べたので記録。

$a: #777 !default;

$a は、評価される前に同様の変数が定義されていれば上書きされないということ。 定数として1ファイルに定義してもらえることが多いが、多段 @import などはどこまで遡って上書きなどできるのかなどは調べていない。

Refs

• https://qiita.com/yuku_t/items/0bebe541432cdfad4e14

書いたもの： https://github.com/9renpoto/slack-channel-active-reminder

slackの部屋は便利に増やしていけますが、 同じような部屋が散乱したり、入ってみたものの活動が薄かったり様々あるので 一定時間発言がない部屋に対してメッセージを送りつけるようなものを書いた。

Usage

Cron などと合わせて仕込んで良いタイミングで発言がなさそうなところに対してメッセージを送る。

const CronJob = require("cron").CronJob;
const Reminder = require("slack-channel-active-reminder").default;

const reminder = new Reminder();

const job = new CronJob({
  cronTime: "0 00 18 * * 1-5",
  onTick: function () {
    reminder.postRemindMessage();
  },
  start: false,
  timeZone: "Asia/Tokyo",
});
job.start();

中身は @slack/client を使っているだけ。 便利なAPIが多いと助かる。

追記

https://github.com/9renpoto/slack-channel-active-reminder/pull/9

flow gen-flow-files が良いものをだしてくれないため外す。 早く1.0 が待ち遠しい。

https://github.com/prettier/eslint-config-prettier

• prettier で直してくれそうな機能を off にして干渉を回避する
  • linterにはならないので警告されない
• pretter-atomの挙動が若干不審
• prettierにconfig設定がないようなのでまだまだフォーマットが変わる

next

• pretter-atom を読む
  • prettier-eslint が並行して動くことが最低条件
• 更新を見守る
  • 特にstandard、Flowとの関係

https://github.com/prettier

eslint --fix が最高だと思っていたがまた新たにformatterが出たので依存する。

eslint-config-prettier

https://github.com/prettier/eslint-config-prettier

• 設定
  • https://github.com/9renpoto/frontend/pull/25
• 困りごと
  • https://github.com/standard/eslint-config-standard に依存している（セミコロン除外）と現状相性が悪い
  • issueがあるようなので今後見直す

prettier-eslint / prettier-eslint-cli

Code ➡️ prettier ➡️ eslint --fix ➡️ Formatted Code ✨

https://github.com/prettier/prettier-atom に依存して様子を見る。現状若干重い。 上記セミコロン問題の取りこぼしなどがあり鶏卵になる。

TypeScript

• https://github.com/eslint/typescript-eslint-parser とは干渉して動かない
• TypeScriptのformatも計画されているようで期待

• 修理は見送り
• 気が向いたらスリムを買い直す（4Kテレビを買う予定がない）

言われてみれば PlayStation は初破損

• 購入したのはBloodborne発売次期だったはずなので2015年春頃
  • ちょうど2年目で破損
• PS1からPS4までなんだかんだ買っていたが壊れたのは初めて
• 最後に壊したハードはXbox360アーケードだった記憶
• PS4でプレイしたもの
  • Overwatch
  • Dark Souls 3
  • Bloodborne
• 積み
  • BIOHAZARD7
  • Bloodborne DLC

次買うなら

• とりあえずスタンバイ起動でのアップデートはやめる
• 過去の経験的に3年ぐらいは保証されたい

手放すことになったので綺麗にする。

手動の限界。

薬品使ってなんとかここまで、お世話になりました。

• eslint 最高
  • これがないと仕事ができない
• typescript から flow-bin へ引っ越し中
  • 既存のコードにも強気で入れられるflowtypeは魅力的
• gulp への依存は最小限、npm-run-all で手軽に対応
• mocha, power-assert 便利だし特に困っていない
  • karma, jsdom との組み合わせを試したがそれぞれできることとできないことはある
  • e2eは別でする

• Keep
  • ライブラリーの依存を増やす（眺めるライブラリーを増やす）
  • 見える場所にコードを書く
• Problem
  • 知識がフロントエンドに偏りがち
  • WIP増加
• Try
  • Functional Programming
  • 簡易サービス運用

• neovimは早いように感じる
• lua拡張は動かない様子

Install

公式の通りですんなり入りました。

# Brewfile

tap 'neovim/neovim'
brew 'neovim'

Usage

• ~/.vimrc を見ていないようなので調整
• 基本的に設定は使い回せる

export XDG_CONFIG_HOME=~/src/github.com/9renpoto/dotfiles/.config

neocompleteが使えないようだがこの際プラグインを見直したいので一旦保留。

• https://github.com/9renpoto/dotfiles/pull/45

Refs

• https://giginet.hateblo.jp/entry/2015/11/24/203823

Building Interactive npm Command Line Modules

• arguments parsing
  • 200種以上のpackage
• yargs
  • .help() 便利
  • Interactiveなオプションを宣言的に記述できる

https://lrlna.github.io/nodefest-2016/#1

Famicom programming with JavaScript

• backgroundの背景を替えるためにはfor-loop4回

GraphQL for the RESTful crowd

https://github.com/barakchamo

• graph QL

  user(id: 1) {
    id,
    first_name
    last_name
  }
  

• fragment

The Seif Project

• webの問題はpassword, 簡単に盗まれる
• Seif Project の中ではカギ認証
• seifnode
• https://github.com/paypal/seifnode
• https://github.com/paypal/seif-protocol
• http://www.seif.place/

Why to Standardize your READMEs

• https://github.com/RichardLitt/standard-readme

Vue.js 2.0 サーバサイドレンダリング

• レンダラ
• ハイドレーション
• コンテキスト
• バンドリング

サンプル https://github.com/vuejs/vue-hackernews-2.0

React + Redux を使った大規模商用サービスの開発

1. Transition
   • react-router
     • onEnter, 認証認可
     • replaceState を使う
2. Code Splitting
   • webpack require.ensure
   • https://github.com/richardscarrott/require-error-handler-webpack-plugin
3. SSR
   • Reactそのものは別に遅くない
   • Solution
     1. Partial Rendering
        • firstViewだけSSR
   • Composite Rendering

PostCSS: Build your own CSS processor

• reworkcssが元になっている

JavaScript による並列処理：共有メモリとロック

https://speakerdeck.com/chikoski/20161113-nodefest

@chikoski

// 提案中..
window.setImmidiate(() => {
  doTask();
});

// 別threadで実行したいjsを指定する
const worker = new Worker("worker.js");

arrayBuffer はポインタ渡し可能になった => SharedArrayButter

// 割り込まれない処理の記述
Atomics;

Atomics.wake;
Atomics.wait;

https://reactive-shinjuku.connpass.com/event/38411/

ハッシュタグ #reactive_shinjuku

リアクティブ DDD について

株式会社ChatWork加藤潤一氏（@j5ik2o）

• リアクティブDDD
  • リアクティブシステム && ドメイン駆動設計
• ActorはDDDで示されるコンセプトを表現できる
• リアクティブシステムとAkka
• リアクティブ宣言 https://www.reactivemanifesto.org/
  • Elastic
  • Responsive
  • Reslilient
  • Message Driven
• ソフトウェアの災いを表す用語
  • 誤差・誤り（error)
  • 欠陥（defect, バグを含む概念）
  • 障害（fault)
  • 故障（failure)
• メッセージ駆動
• Akka
  • 2011年の記事ではErlangの2倍のスループットを発揮した
• ドメインモデル
  • モデル = 考え方とコードを結びつけたソフトウェア を実現する
• ドメイン層の隔離

ここからスライドを参照してあとで勉強する。

https://speakerdeck.com/yoskhdia/modeling-the-domain-event

Lagom で学ぶ Reactive Microservices Architecture

株式会社TIS根来和輝（@negokaz）

• Reactive Microservices Architecture
• Lagom
  • 非同期・ノンブロッキングAPI
  • Shardingによるステートフルアーキテクト
  • 分散型の永続化機構
    • CQRS + Event Sroucing
  • Circuit Breaker

www.slideshare.net/negokaz/lagom-reactive-microservices-architecture

ssh passphraseを常に問い合わされるようになった。

調査

• keychain
• ssh-agent

keychain 入れてみる

• https://github.com/9renpoto/dotfiles/pull/32

解決出来た様子。

Refs

• https://qiita.com/u6k/items/5970618c4a8c23f71fb9
• https://qiita.com/tukiyo3/items/045f86c4242ec53953e2

https://connpass.com/event/38112/

React/Redux で快適フロントエンドライフ（仮）

by @takayuki_shmz (株式会社FiNC)

https://xtech.nikkei.com/it/atcl/column/16/050900104/051000005/

• React & Redux
  • 学習コスト
  • JSX(うんじゃら）
• 後悔したこと
  • つらいコンポーネント
  • つらい繰り返し・テスト
  • つらいデータの扱い
• 最初に抑えるべき
  • 正しいコンポーネント思考
    • smart component
      • dumbコンポーネントとaction, storeを繋ぐ
    • dumb component
• Statelessコンポーネントが原則
  • case by caseだけども
• cssはコンポーネントと1v1
• this.contents
  • https://legacy.reactjs.org/docs/context.html
  • API層をcontextに渡しcontainerを呼ぶ

革命と秩序と SPA(React、flux、flowtype)

by @joe_re (freee株式会社）

https://speakerdeck.com/joere/ge-ming-tozhi-xu-tospa

• backone
• freee-mvc-framework
• vue
  • mvvm
• react & flux
  • single-stateを途中から導入するのがツラい
  • flux-utils
    • サポートの範囲が小さい分外しやすい
• flowtype

Angular と心中する（仮）

by @Quramy (株式会社WACUL)

https://quramy.github.io/spa-knowhow-note/#/

• WACUL
  • TypeScript
  • angular 1.x
• Angular 1.x
  • component
  • コードの自動生成
  • エラー周り
• style管理問題
  • BEM
  • component:css = 1:1
  • https://github.com/ukyo/angular-simple-bem
• Rollbar
  • 裏でsourcemap連携

コンテンツ配信とSPA。

by @konpyu (Piece of cake,Inc)

• note https://note.com/
  • angular 1.3
  • mobile遅い
• Drupal8
• SSR
• HTTP2

SPA と覚悟

by @teppeis (サイボウズ）

• SPA
  • ブラウザーにとっては1枚のページに見えている
  • ブラウザーの体験を超える覚悟がある
• 初回ロード
• a11y
• ブラウザーを越えすぎても駄目

Angular2 でつまづいたところ（仮）

by @nacika_ins

1px をめぐる戦い

@yoshiko_pg

https://yoshiko-pg.github.io/slides/20160916-spa/

SPA でのセッション管理とセキュリティ

by @uryyyyyyy

• https://qiita.com/uryyyyyyy/items/9a8276f7241b650f1c15
• https://twitter.com/teppeis/status/776757447813771265

TL;DR

• react-storybookはcomponentのstyleguide
• TypeScriptのままでは動かせないので一度ビルドする（2016/09現在）
• addon拡張で開発が便利になるエコシステムはある
• 途中経過
  • 9renpoto/style

storybook

• stories
  • add して一覧ページがカジュアルに作成できる
  • gh-pages などで簡単にホストできる
  • HMR ができるのはありがたい
    • いろいろwatchしたくなる
• webpack にどっぷり依存

TypeScript with React

• 2016 年 9 月現在だと React アプリの TypeScript 採用は時期尚早
  • 確かに現状の型定義は古い
  • まだそこで困るほどReact使いこなせていない
  • 緩く型を信じる・困ったら考える（個人では）
• tsx
  • サポートありがたい
  • DOMを型付きで定義できることの安心感
    • テストを書くのは意識高めになる必要がある
  • 便利だけど遅い
• webpack
  • 古いloaderが増えてきたex. ts-loader
  • ts-loader などでwatchはできないので tsc -w で様子を見る
  • ガッツリ依存せず疎結合にできるところは疎結合にする

CSS-module

• 基本的に使わない方が良さそう
• 使う場合は構造化cssとして育てるのではなく、 local css としてビルドしたほうが良さそう
  • SDKなどで利用するのはアリ

Refs

react-storybook を用いた React コンポーネント開発

勉強について考える。

TL;DR

• 勉強している人は本当に偉い
• 何事も尊敬できることは才能より努力

勉強から得られること

• 出来ないことができるようになる
• 出来る人のことを尊敬できるようになる
• 人間の時間は有限
  • 天才はいるが天才にはなれない
  • 効率化は二の次
• 遊ぶことも勉強
  • 新しい知識を得ることは楽しい
  • 出来ないことができるようになるため努力が必要
  • 自分と相性の良い天性のことなんて存在した試しがない

まとめ

• 勉強は楽しい
• 時間は有限
• 求められたら勉強する

余談

Overwatchで勝てないのが厳しい。

http://events.html6j.org/conference/2017/10/

基調講演

speaker: 中村修。

大規模分散オペレーティングシステム。

• HDR
• WebはWeb以外に存在するデータ表現を全てできるべき
• 全てinternetの上にある発想
  1. Big Data
  2. AI
  3. IoT
• Distributed Operating System
• 縦書きcss
  • 日本頑張ってる

speaker: 及川卓也。

• IE7担当してました
• アプリケーションとしてのWeb
  • API
  • Web Components
  • PWApps
    • Service Worker
• モバイルデバイスの普及
  • ニュースキュレーションアプリ
  • AMP
    • CMSやツールに依存している場合
• 今こそWebに再投資しよう

React の最新動向とベストプラクティス

speaker: @koba04

• Stateless Function Components(SFC)
• stateはviewに関係あるものだけで十分
• React.PureComponent(v15.3.0~)
  • ShoudComponentUpdateに類似（後で調べる）
• react-addons-perf
  • 計測ツール
• React.createClass
  • 徐々に非推奨
  • React.Componentへ
• High Order Function
  • 関数型っぽい
  • acdlite/recomponse
• stateの管理
  • なるべく一箇所で管理
  • Redux
    • Container Component
      • 更新処理・状態管理
      • DOMを持たない
    • Presentational Component
      • Viewの構築を担う
• Componentをテストする
  • TestUtil.renderInfoDocument
  • shallowRender
  • react-test-renderer
• 開発をサポートするツール
  • https://github.com/zalmoxisus/redux-devtools-extension
  • https://github.com/storybookjs/storybook

Service Worker Deep Dive

speaker: @horo

slide: https://docs.google.com/presentation/d/19x3yi7Jn-6In5igGYfEiK0tBfNI290BAclT0AiqDj4Q/pub?slide=id.p

https://jakearchibald.github.io/isserviceworkerready/

• stream
  • https://docs.google.com/presentation/d/19x3yi7Jn-6In5igGYfEiK0tBfNI290BAclT0AiqDj4Q/pub?slide=id.g1641acac50_0_0
  • 徐々に読み込んで処理できる
  • ReadableStream
• Unified Media Pipeline (android)
• Usage
  • rel=serviceworker

The First Step to Angular 2

speaker: @laco0416

• Official Packages
  • @angular/core
  • @angular/forms
  • @angular/http
  • @angular/router
• TypeScript
  • 常に正しいAPI
• API
  • @component
  • @input / @output
  • @directive
  • @pipe
  • @NgModule

Web パフォーマンス最前線

• High Performance Web User Interface
  • パフォーマンスに対する優先度
    • RAIL https://furoshiki.hatenadiary.jp/entry/2015/06/01/122537
      • Response
      • Animation
      • Idle
      • Loa
  • transform: translateZ(0)
    • 凶悪
    • Web標準： will-change: transform
      • Reduce GPU Memory
• Scroll Performance
  • <img lazyload> :innocent:
  • intersectionObserver
  • throttle https://tsumikiinc.com/news/article/000337.html
    • TODO調べる
• Task Optimization
  • https://devpixiv.hatenablog.com/entry/2015/12/24/182248

Progressive Web Apps の導入基礎

• Push Notification
  • service worker
  • ユーザーの許諾を得て、メリットを提示してからやったほうが良い

https://github.com/kuu/the-offline-cookbook-ja/blob/master/ja.md

https://app.travis-ci.com/9renpoto/ts/builds/156475663

• アバウトな構成

"devDependencies": {
  "@9renpoto/eslint-config": "^1.1.0",
  "@9renpoto/tslint-config": "^1.0.0",
  "@types/mocha": "^2.2.31",
  "@types/power-assert": "0.0.27",
  "awesome-typescript-loader": "^2.2.1",
  "codecov": "^1.0.1",
  "eslint": "^3.4.0",
  "json-loader": "^0.5.4",
  "karma": "^1.2.0",
  "karma-coverage": "^1.1.1",
  "karma-firefox-launcher": "^1.0.0",
  "karma-mocha": "^1.1.1",
  "karma-sourcemap-loader": "^0.3.7",
  "karma-webpack": "^1.8.0",
  "mocha": "^3.0.2",
  "npm-run-all": "^3.0.0",
  "power-assert": "^1.4.1",
  "rimraf": "^2.5.4",
  "tslint": "^3.15.1",
  "typescript": "^2.0.2",
  "webpack": "^1.13.2",
  "webpack-espower-loader": "^1.0.1"
}

tsc ・ webpack しても問題ないように見えるが、 karma を通した場合 SyntaxError など出てきて非常に厳しい。

https://github.com/9renpoto/karma-power-assert-typescript-mocha-webpack-sample

同様の構成で先に検証頂いているものを発見するも、現在構成との違いの無さに こちらが動かない理由は不明、頭を悩ませる。

TL;DR

• remap-istanbul を使う

Usage

• npm install remap-istanbul
• sourcemap: true

Memo

• tsc > npm test という流れになったためJavaScript としてテストをする形になる
• espower-typescript を使わないようになる
  • espower-typescript はtscのwrapperなのでtscする場合は使えなそう
• power-assert が上手く構造を解釈してくれてなさそう
  • espower-typescript が担っていた役割を別で与える必要がある
  • TypeScriptに依存するなら無駄にbabel pluginなどは使いたくない
    • TODO考える

Refs

• http://blog.syati.info/post/typescript_coverage/
• https://github.com/9renpoto/ts/pull/34

TypeScript テストについて 少し調べました。

• https://github.com/9renpoto/ts/pull/31

原因

• TypeScriptがファイルパスを相対パスか絶対パスのどちらかで返す場合がある
  • https://github.com/Microsoft/TypeScript/blob/204f2c16c0d6ff851e4798c03a9646b625ac2bd7/src/compiler/core.ts#L821-L825

対策

• https://github.com/teppeis/typescript-simple/pull/47

悩み

• rootDir, outDir の組み合わせで挙動が変わることを理解する必要がある
• rootDirs が入る（TypeScript 2.0~)

• https://riotjs-jp.connpass.com/event/35724/

参加メモ

• 小さいライブラリーを維持するための努力は大変
• セマンティックバージョニングは大事

悩み

• web component時代のcss , htmlとの付き合い方
  • styleguideはどこまで責任を持つべきか
    • web componentライブラリーを含めて書くべきか
  • https://morishitter.hatenablog.com/entry/2016/07/29/204642
    • まだCSS Modulesを使うべきか個人レベルではわからない
    • この記事を理解するための勉強あ必要

Next

• styleguideを書く
  • https://github.com/9renpoto/style
• riotを使った簡単なものを作る
  • https://github.com/9renpoto/profile

気持ち

• できるだけ型のある世界で生きていく

• 9renpoto/javascript/pull/19

{
  "devDependencies": {
    "eslint": "^2.13.1",
    "espower-typescript": "^5.0.1",
    "mocha": "^2.5.3",
    "power-assert": "^1.4.1",
    "tslint": "^3.11.0",
    "typescript-eslint-parser": "0.1.0-alpha-1",
    "typings": "^1.3.0"
  }
}

下記を満たす簡単なサンプルを書く。

• 複数module
• mochaによるテスト
• power-assertによるテスト

espower-typescript が通らないので中身を見て調べる。

• Hugoを利用して <username>.github.io に公開
• mozilla/oghlinerを利用してオフライン対応

Hugo を利用して gh-pages にデプロイ

公式ドキュメントでwercker-ci を利用したデプロイ方法が紹介されており、そちらを利用していましたが。

http://9renpoto.github.io/<project_name>

という名前になってしまい、個人ページとして構築を目的とした場合不満があったため環境を見直し。

• pages.github.com/
• qiita.com/eichann/items/4fe61b8b9bbafcfbe847

を参考に問題を解決するために手を動かし始めました。

<username>.github.io

リポジトリーを作成し master ブランチにpushされることによって公開される（not gh-pages branch)ようなので。

public/ に生成されたものを <username>.github.io にdest するように修正しました。

オフライン対応

mozilla/oghlinerがserviceWorker を利用したオフライン化を簡単に提供していたので試しに使ってみる。

Feature

ビルド・デプロイタスクを直す。

yapcasiaに参加したときのメモを残します。

Effective ES6

denger

function Persion(name) {
  this.name = name;
}

var p = Person("bob");
#p.name == undefined;
#window.name = "bob";

• class

  • constractor
  • newナシで呼ぶとError

• IE11 ES6は実装しない

• transpiler

  • ES6 to ES5

• polyfill

  • buildinのclassをjs環境で動かすようにする

• Babel

  • core.js # polyfill toolsもあるよ

• ES6 feature

  • new syntax

    • arrow function

    var add => (a,b) => {
        return a + b;
    }
    

    • class

    class Programmer extends Person {
      constracor(name, language) {
        super(name);
        this.language = language;
      }
    }
    

    • module

    export var foo = 'foo';
    import (foo) from './module/path'
    

    • 'use strict'
      • 書かなくていい
    • block scope

    var a = "outer";
    function bar() {
      console.log(a);
      a = "inner";
    }
    bar();
    #undefined;
    

    • arguments

    function foo(...rest) {}
    

    function draw(x,y,{height:1,width:1} = {}) {
    }
    

    • template literal ` で文字列を囲むと改行付き文字列が定義できる
    • Promise
      • callback地獄回避
    • map/set
    • codePoint
      • 吉野家isvalid

  • trap

  if (a => 1) # if ( a >= 1 ) が正
  

  • balelっていこう

今フロントエンドで何が起こっているのか

• htmlだけ返せばよかったような時代
• ajaxの登場
  • google map etc
  • ECMAscript5
• coffeescript
• jQuery(from 2006)
• backbonejs
• nodejs(2009)
• grunt(2012)
  • config
  • plugin base
• typescript(2012)
• AST
  • abstract syntax template
• SPA
  • 問題
    • SEO
    • Performance
• AngularJS(2009)
  • 2way data binding
  • fullstack
• gulp
  • stream base
• Browserify
• ECMAscript 2015
  • Stateless
  • Composable
  • stream
• babel (2014)
• Service Workers
  • Intercept Requeest
    • offline / cahce
    • Background Sync
    • Push Notification
• Extensible Web
• Reactjs
  • Stateless Component
• Flux
• FRP
  • Rx.js, Bacon.js
• Redux
  • Inspired by Flux and Elm

どうしてこうなった Node.js と io.js の分裂と統合の行方。これからどう進化していくのか

Node.js の歴史 (Node.js とは、Node.js が生まれた背景）

• 2001
  • C10K Problem
• 2007
  • Web 2.0
• 2009 ~ 2012
  • JSConf EU
    • Server-side JavaScript
    • Evented Non Blocking I/O
    • v8
  • EventLoop Model
    • libebb => libev/libeio & libuv (Windows向け）
    • netv8 => node
  • Joyent
  • 破壊と創造
    • APIがかなり深刻に変わる
  • BDFL (優しい終身の独裁者モデル）
• 2012 ~ 2014
  • Socket.IO

Node/io.js の機能的な違いと性能的な違い

• 2014 ~
  • node forward
  • BDFL => community model
  • Technical committee
    • コアメンバー委員会
  • Collaborator
  • Working group
  • Semantic Versioning
    • major.minor.patch
  • オープンガバナーンスモデル
  • Feature Node.js
  • io.jsのこと
  • node Foundation
  • log term suport

Node/io.js のロードマップ

• ES6 compat ％ up
• StrongScript
• SimpleSteam
• improve pref

• ブログを octpress から hugo へ移行しました
• hugo theme 書きました

themeを書くために

cmd1つでテンプレート作成。

$ hugo new theme foo
.
└── themes
    └── foo
    ├── LICENSE.md
    ├── archetypes
    │   └── default.md
    ├── layouts
    │   ├── _default
    │   │   ├── list.html
    │   │   └── single.html
    │   ├── index.html
    │   └── partials
    │       ├── footer.html
    │       └── header.html
    ├── static
    │   ├── css
    │   └── js
    └── theme.toml

Document がよくまとまっていますので参考に。

TODO

• layouts/_default 以外の使い方調べる
• rss作成
• bower installするbuild script

感想

octpressの時はtheme流用してたので手作りも勉強になりました。

t32kさんのmolを参考（ほぼコピー&ペーストして）に作りました ありがとうございます。

ESC で確実に IME をオフにするを参考に設定を反映してみるも直ってないご様子。

どうもGoogleIMEには神設定があるらしい。

これで Esc を使って快適に抜けられる最高。

参考

• Vimでコマンドモードに戻るときIMEをオフにする hotolab.net/blog/vim_ime
• ESC で確実に IME をオフにする

ハッシュの中だけを { foo: 1 } のようなjsonフォーマットに直したいときatom などでマルチカーソル操作をすると全部選択されてしまってツラまる。

良い方法が知りたい。

個人的な所感としては。

• spark楽しそう（だけどまだ触るには勇気が）
• Prestoも熱そう
• MapR書くよりもSQL書く方がお手軽

以下はメモ書き。

keynote

hadoop を取り巻く環境について

• 始めて普及した並列分散
  • データの読み込みのスループットを最大化
    • 全件データの処理を実現
  • シンプルなモデル（MapReduce)
  • YARN
    • MapReduceからそれ以外のアルゴリズムも
    • 複数の並列分散エンジンを併用できる環境
    • メモリーの大容量化、10Gbpsネットワークの普及
      • インメモリー処理の実現性の向上

The Future of Data

Doug Cutting

• 未来について
  • ハードウェアの価格の低下、性能の向上
  • データの重要性の向上
  • オープンソースが勝ち残る

The Future of spark

Patric Wendlell

• Sparkの目的
  • データサイエンティスト、エンジニア能力の拡張
  • 表現力のあるクリーンなAPIの提供
  • 多様な環境にわたって統合されたランタイム
• API 　 stability
  • 3か月サイクルでマイナーリリース
  • 必要におおじてメンテナンスリリース
• Spark SQL
• MLlib
  • Spark + R
• DataBricks

Hadoop エコシステムの片鱗と見えてきた使いドコロ

• TreasureData
  • なぜHadoop使うのか
    • Hadoopを使うのは最適な解か
      • 安いストレージとして使うだけならHadoopより良い物は沢山ある
    • データの収集ソフトウェア
      • 多種多様なデータ・ソース
      • fluentd,flumea,kafka,sqoop
    • ファイルフォーマット
      • Schema on Read
    • 管理・人的コスト低減の支援
    • 簡単にデータを扱うか
      • Tez, Spark
    • SQL on Hadoop
      • Impala, SlarkSQL, Presto Drill
      • Mahout, Spark MLlib
    • 今までの時代
      • データを入れるだけ入れたけど、レポート化できる人の限られている
      • 今までは何でも入れられるだけ
      • これからはだれでも取り出せるようにしないと意味がない
    • Hadoop -> MPP
      • Twitter: Hadoop -> Vertica
      • Pinterest: Hadoop -> redshift
    • 非構造化データの領域に踏み込む
    • 混沌の時代

セッション

マルチテナント化に向けた Hadoop の最新セキュリティー事情

• Hadoopのユースケースの移り変わり
  • バッチ処理を効率よく行うため
    • 部門単位での利用、クラスターの乱立
  • 近年
    • バッチ処理 + インタラクティブな処理
    • SQLによるアクセス
  • データは一部の人だけのものではない
    • クラスターの共有（マルチテナント）
  • マルチテナントのメリット
    • データの複製不要
    • 業務の取り巻き
    • 性能・効率の改善
  • 課題 　
    • リソースの分離と管理
    • Role管理
• マルチテナントとセキュリティーの関連性
  • 認証
    • kerberos
      • 相手が何者であるかを保証するプロトコル
      • 暗号化
  • 認可
    • HDFS ACL
      • ファイルシステムレベルでのaccess control
    • Apache Sentry
      • データベース、テーブルview、行列の粒度でアクセス制御
• 認可モジュールSentryの紹介
  • Apache Sentryはモジュールとして開発されている

BigQuery and the world after MapReduce

• BigData at Google
  • ログ分析するのにMapReduceを書いてる場合じゃない
  • BigQuery ( sql base )
    • indexなんてないんや
  • 全文検索、120億行、10秒ぐらい
  • storage料金
  • Quesy料金
• Column Oriented Storage
  • もはやスタンダード
• Colossus File System
  • GFSの次のもの
• MPP
  • 1TBの内容を数秒で舐めるためには何台必要なのか
• JOIN
  • small join
  • broadcast JOIN
    • ばらまいてコピー => JOIN
  • JOIN Each
    • shuffleしてjoinできる
• BigQuery Streaming
  • fluentd
  • fluent-plugin-bigquery
• BigQuery User-Defined-Function-with-JavaScript
  • クエリ内にJavaScript書く
• Cloud Pub/Sub
• FlumeJava
  • 論文あるよ!
• MillWheel
  • 論文あるよ!

SQL によるバッチ処理とストリーム処理

• @tagomoris
  • stream処理
    • norikra
  • Hadoop
    • Hive/ Presto
  • SQL is NOT the best;
    • But, SQL is better than NONE.
  • Batch processing
    • hive
  • Stream processing
    • storm
    • kafka
    • esper
    • norikra
    • fluentd
• Lamda Architecture
  • Streaming
    • 速報値
  • Batch
    • 確定値
  • 両方に対応したい
• Stream処理
  • レイテンシが低い
  • 同じ処理をバッチとしても実行できる必要がある

YARN

• TD
  • PlazumaDB
    • S3上で動作
    • HDFS is not used
  • Hadoop Cluster
    • Customize hadoop
    • Customize hive
    • Customize Pig
  • PlazumaDB
    • Customize Impala
    • Customize Presto
  • 独自queue
  • 独自scheduler
  • YARN cluster
    • プロダクションにはまだ入れてないが環境整えている
• YARNとは
  • Job History Server注意
    • 起動してないと過去ログが追えなくなる
  • NOTE
    • Use the Hadoop 2.4.0 and later
      • Capacity Scheduler、there is a bug
      • deadlock
    • hadoop-conf-pseudo doees not work
    • 2.2.0 and 2.4.0
      • 結構違うので注意

Presto

• what is Presto
  • Facebookで作られてoss化
  • HDFS上のデータを可視化したい
    • うまくいかない
    • hiveが遅すぎる
  • hiveをバッチ化 => 中間DBに入れる
    • 中間DBはスケールしない
  • HDFSに保存してないものは入れなきゃならない
• Presto
  • 中間データベースの取り除く有効な手段
  • 他のデータストアを舐めることにも対応
  • Hiveとの使い分けが必要
    • 巨大なjoin
    • group by
  • Interactiveなクエリを発行できる
  • 複数のデータ・セットをまとめて表示できる
• BI tools
  • 可視化に利用していく
  • ODBC/JDBC is very complicated!
• Prestoの実行モデルについて
  • not MapReduce
  • 全部並行で動いてる
    • 一個死んだら全部死ぬ
    • メモリー溢れてしまうとクエリが死んでしまう
  • メモリーの使用量はクラスターで管理されて、クラスターが死ぬことはない（はず）
    • がクエリは死ぬ

vimだと矩形選択で頑張れるから甘えてましたがatomなど使っているとcomment ショートカットが便利で良く使います。

vimでも使えるようにしました便利。

surround.vim便利sublime-textでも使えるようですがatom の公式パッケージにも早くほしい。

githubなどで開発しているとPRが便利で良くコードを見るようになりました 意味のないコード差分などはできれば出したくない。

sublime, atomにもあってvimにはないのかと思ってたら検索して3 分で見つかりました。

最高です。

vim-gitgutter

同じ変数名を利用してハッシュのようなものを作成するときに 情弱で、愚直な操作をしてしまっている。 もっと簡単に入力する方法を知りたい。 atom やsublime-textでは、さらに愚直に入力しており良い方法がないか知りたい。

アジャイル開発について悩んでおりましたので、噂のアジャイルサムライを読みました。

• 学べたこと
  • 考え方
    • 立場の明確化
      • プロダクトオーナー
      • スクラムマスター
      • 開発者
    • 立場に対して自分の役割が明確にある
      • わかりやすい
    • 大切なのはモノを作ること
      • 未完成に価値はない
    • 時間・リソース・金は有限
      • 現実は非常に大切
      • 優先順位の大切さ
  • 流れ
    • プロダクトオーナー
      • 作りたいものの決定
      • 優先順位の決定
    • スクラムマスター
      • 時間管理
    • 開発者
      • 見積もる
      • 作る
  • ウォーターフォールとの違い
    • 見積もりが開発者に任せられてるところが良い
    • ストーリーポイントを基準に実現可能性を図る
      • 現実を見ている
    • 見積もれるタスク
      • 細かなサイクルを回すというよりも、見積もれる範囲を大切にするという考えに共感
      • 未完成に価値はない 完成品を作る（レビューする）

なるほどわかりやすい。

人間関係に悩んでおり、以下の本を読んでおりました。

読み終えたので簡単な感想をメモ。

• 大切
  • 謙虚
  • 信頼
  • 尊敬
• オープンに
  • 上の人は質問に堂々と答える
  • 下の人な恐れず質問する
• 責任
  • 重要
  • 自分事化

まず今までの失敗を繰り返さぬよう沢山実践して、違う失敗しよう。

マーケティングの人のことを考えるとゾッとするのはなぜだろうか？ それはエンジニアリング文化と相入れないからだ． ぼくたちの文化は「事実」に満ちあふれている． コードはコンパイル「できる」と「できない」しかない． ソフトウェアは機能を「持つ」と「持たない」しかない． 問題は解決「できる」と「できない」しかない． 説明を「引き伸ばす」ことはしない．事実だけを話す．

Brian W.Fitzpatrick, Ben Collins-Sussman（2013) 『Team Geek Google のギークたちはいかにしてチームを作るのか』株式会社オライリー・ジャパン 150pp.

学びとは少しそれた話ですが、上記の言葉が何よりも共感できました。

自分はエンジニアで居心地が良い。

環境構築といえば、chefだという噂を随分と聞くようになってきましたが、 なんだかんだと使ってなかったのでメモ。 とはいえ、レシピは誰かが書いてるので、 今回は出来る限りレシピを使う方法で構築を目指す。

前準備

# Gemfileに記載
source 'https://rubygems。org'  # URLの指定。呪文だと思って毎回書く

gem 'berkshelf'
gem 'chef'
gem 'knife-solo'

必要なgemをいつものように。

bundle install

chef-soloを使えるように初期設定を行う。

bundle exec knife configure

そろそろchef

ひな形の生成。

$ bundle exec knife solo init chef-repo
$ tree chef-repo/
chef-repo/
├── cookbooks
├── data_bags
├── nodes
├── roles
├── site-cookbooks
└── solo。rb

忘れないうちにコミット。

cd chef-repo
git init
git add 。
git commit -m 'first commit'

公式なり、Githubにて公開されているレシピを利用しやすくるものとして Berksfile があります。

site :opscode # Berksfile

cookbook "apt"
cookbook "git"
cookbook "zsh"
cookbook 'vim'
cookbook 'the_silver_searcher'

公開されているレシピの情報を記述しておけば、コマンド1つで落としてこれます。 便利。

bundle exec berks install --permalink cookbooks

vagrant側でchefが使えるように以下のコマンドを実行。

bundle exec knife solo prepare nodename

インストールしたいレシピを追加node/nodename.json。

{
  "run_list": [
    "recipe[apt]",
    "recipe[git]",
    "recipe[zsh]",
    "recipe[vim]",
    "recipe[the_silver_searcher]"
  ]
}

レシピはできたのでcookしましょう。

bundle exec knife solo cook nodename

参考

• qiita.com/uchiunyo/item

これから設計をはじめます、という時に 今までは小さな機能では、スキーマの設計から始めてしまっていたのですが。

久々に「クラス図を書いてみよう」という話になり どう書こうとなったのでメモ。

CUIで書けるのが最高です。

依存関係をテキストベースのみで記述できるので非常に助かりました。

図の綺麗さなどを意識せず関係を記述することに集中できるのが魅力。

wget http://sourceforge.net/projects/plantuml/files/plantuml.jar/download -O plantuml.jar
java -jar "plantuml.jarのパス" [option] 入力ファイル [...]

で入力ファイルを目的のUMLを生成します。

Graphvizが必要なのでインストールしておきます macはbrewだけで入りました。

brew install graphviz

これだけで使えます。

@startuml
class Bugs {
-bug_id
-description
-created_at
}

class Comments {
-comment_id
-bug_id
-auther
}

class Auther {
-id
-name
}

Bugs --_ Comments
Auther --_ Comments
@enduml

便利。

参考

• https://abicky.net/2012/10/16/093737/
• http://yohshiy.blog.fc2.com/blog-entry-152.html

GUI関連

Officeなどを使って作っても良いのですが、 専用のツールもメモ。

astah*

Officeツール以外で関連ツールを探すと上位に出てくる良いツールです。

Cacoo

今までなかなか縁がなく利用していなかったCacooですが、そういえば使ってなかったなと思い軽く使ってみました。

ChromeAppなどで使えますし、お気軽さではダントツ。

RTB and FreakOut

RTB概略。

• ディスプレー広告の新しい見せ方
  • 1回の広告表示ごとに買い付け
  • オークション形式によりアラカルトメニュー

広告主のネット広告におけるROI最適を目指す。

RTBの技術的課題。

広告表示の時間は 0.1 秒

• レイテンシの軽減
• 多数のRTBを処理
• 50mc or die

[Tokoy|Kyoto][tyrant|tycoon]

• 高速
• スケールは簡単にできない
• 運用実績はあるが用件を満たすのが難しい

Riak and FreakOut

• スループットを向上させるために
  • hashからpartitionを特定する
  • 素のままでは50mc or die的に厳しいため
  • 構成の工夫が必要
  • スケーラビリティの問題を克服できるメリットは大きい
  • 「サーバーを足すだけで運用」

Yokozuna 日本語検索を評価しました

@rev4t @yosisa

日本語検索： Yokozuna。

Solr XMLスキーマを利用した検索が可能便利そう。

Go 言語で作る Web アプリ @tenntenn

HTTPサーバー簡単に書ける。

• https://docs.google.com/presentation/d/1rrY2oibeUrqjF4ga5L3EhDioIURcMCUOz7jBXHWBdOM/pub?start=false&loop=false&delayms=3000#slide=id.gb8818ff4_2_0

Go on AppEngine @najeira

• Go言語のメリット
  • 簡単
  • Nativeで速い、少メモリ
  • モダン（並列、型推論、Stractual subtyping(部分型）
• AppEngineのメリット
  • 保守しなくてよいので開発に集中できる
  • 大規模、伸縮
  • モダン（TQ、memcachedサポート）
• Testing
  • AppEngine上でGo言語だけでテストを行うことは難しい
  • testbed https://github.com/najeira/testbed
• Goの優位性
  • 起動が速い（AppEngineとの相性は良い）
• 速度についての補足
  • 常にGoが速いというわけではない（I/O、etc)
• まだ完全以降にコストかけて頑張るほどのノウハウはたまってない

Gorutine and channel @Jxck_

• メモ漏れ

Go Schaduler @methane

• https://gist.github.com/methane/5377227#file-goscheduler-md
  • Goroutine
    • 奥が深い

Go のどのあたりが良いか鵜飼さん

• Goの第一印象

  • 慣れた言語から見ると違和感がある

• 設計方針

  many on the decisions in Go are motivated by experience working on and maintaing large code bases at Google.

  • 書きやすさより読みやすさ、修正しやすさ
  • シンプルな仕様、簡潔な文法
  • 細部まできちんと考えたコードを書くようになる

• 型宣言

  • 逆
  • これは複雑な変数定義を行った際に分かりやすい

• コメント書くぐらいならコンパイラーにチェックさせろよ

• クラス

  • 型定義
  • 型に対してメソッドを追加する

• 使われないコード

  • Goはコンパイルエラーを徹底的に出す
  • 大規模なコードになってきたとき、容易に肥大化してしまう問題を防ぐ

• エラー処理

  • try ~ catchにしたがる
    • 制御の流れが複雑になる
    • 変なGOTOをしているような感じ
  • 基本的にエラーはその場で処理させる

無題 @moriyoshi

• Goでゲームを作るためのライブラリー紹介
  • 画面出力
    • SDL系： go-sdl / gosdl
    • OpenGL系： gl / GoGL
  • 音
    • portaudio-go / go-openal / pulsego
  • 入力
    • 入力のSDL系は標準でできる
    • OpenGL系ではGo-GLUT / glfwなど使える
• https://github.com/moriyoshi/gohex

今回も楽しいお話がたくさん聞けました。

ありがとうございました。

@kuenishi

分散システムの研究や開発は5年ぐらい日本法人が9月に出来た。

Riak の紹介

• Dynamoにインスパイアされた

• Consistent Hassingによる水平分割する

• Vector Clocksを用いてレプリケーション

• Erlang/OTPで動作

• 分散KVS

• HTTP / Protocol Buffers

• Secondary Index/ MapReduce

• Link Walking

• Consistent Hassing and Replicas / Vecteor Clocks

分散システム、ざっくり。

• Graph
• SQL
• Document
• Scale out

RICON について

• 分散システム、分散DBのカンファレンス

事例

• Redis側でロックして、裏側はRiakで構築
  • 壊れても大丈夫なようにするのが鉄板のパターン

面白かった話

• Rak Pipe
• Introduction Yokozuna
• Building Riak CS on Riak
• Cloning the Cloud
• Bringing Consistency on Riak

Riak with Engine yard

• EC2上のGentoo

• すべてはChefで構築

• その上にアプリをデプロイ

• 再起動も1から構築

• ssh / sudo可能

• 何台、何度でも再現可能

• DB

  • PostgressSQL
  • MySQL
  • Riak

• Riakはバックエンドでたてないとダメ

• Riak Searchを使って全文検索が可能

• 今後、Yokozunaに移行予定

ちょっと前の話ですが、リーダーブルコードを読みましたのでその感想をメモ。

印象に残った学び

• 名前の大切さ
  • プログラムで一番難しいところ
  • 良い名前ほど理解しやすい
• コメントの大切さ
  • コメントを書く目的
  • 意味のあるコメントを書かないと意味がない
  • コメントはコードの理解を助けるもの
• コードの分割
  • 小さければ小さいほど正義と読む前まで考えていた
    • どう分割すべきか
    • 重複コードとは何なのか
  • 理解しやすいように分割する
  • 意味が明確に分かれるよう分割する
• 短いコードを書く
  • これは非常に難しいが理屈はよくわかる
  • よいメソッドよいモジュールを積極的に使っていくことが大事

Elixir楽しそうなので勉強はじめますまずはerlangのinstallから。

brew install erlang

erlangもbrewから入れられるなんて楽な世の中になったものです。

brew install elixir

brewだけでinstall終わり。

Erlang R15B03 (erts-5.9.3.1) [source] [64-bit] [smp:4:4] [async-threads:0]
[hipe] [kernel-poll:false] [dtrace]

Interactive Elixir (0.7.2) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)>

terminalでiexと打つと正常に起動。

Cloudera Impala について

@shiumachiさんより。

Impala とは

• Clouderaが開発した低レイテンシ・分析特化型のクエリ実行基盤
  • google Dremel, Google F1などにインスパイアされて開発された
• データサイエンティストが使うことを想定している
• Hadoopはクエリの内容がメモリーに乗っからなかった場合、HDDに逃げちゃう
• Impalaはオンメモリー上で頑張ろうとする

Impala support 状況

02 時点

• Trevni, RCFileのサポートは現状まだ、今後に対応予定
• Hiveで出来ることは、基本的にImpalaでは出来ないと思ってよい

なぜ開発されたのか

Hadoop(Map Reduce)だと高レイテンシで、すぐに結果が欲しくても処理に時間がかかる。

Hiveのようで手軽に使えるSQL のインターフェイスをもち、かつ低レイテンシエンジンが欲しかったからです。

MapReduce とは

• Apache MapReduceとは
  • バッチ処理を分散して行うシステム
• Apache Hive
  • SQLライクに書ける
• MapReduceの問題
  • レイテンシが高い
  • 小さいキューを出しても数十秒時間かかる

よくある質問

Q もう Hive いらないんじゃない

• 定期的に実行を行うクエリなどはHiveのほうが適しているのではないか

Qimpala が落ちたらどうするの

• クエリが全部こけます
• JOINのサイズ制限あるの
  • あります

Python in Webkit

@omo2009さんより。

Third party Tools

• WebKit
  • Buildbot
  • Trac

今回は webkit-patch について

# Submitting for review
webkit-patch post
# Commiting a reviewd patch
# Commit log は自動で書く
webkit-patch land
# Reverting specific version
webkit-patch rollout
#

プロジェクト特有の問題を解決するために使っている。

watchlist
suggest-reviewers
suggest-nominations
Bugzilla autocompletion
IRC

• 誰にレビューしてもらえば良いかわからない
• 誰にレビューしてもらったか忘れちゃう
• 探すのに便利

IRCでレビューを頼むと断られにくい。

Connpass について

@lanMLewis, @ae35概要と技術について。

connpass とは

• BePROUDで運営しているイベント支援サイト
  • 2010/08 django dash
    • djangoを使って48時間でサービスを作ろう
    • 既存のイベント支援サービス（ATND)使いにくいよね
    • 作ってみよう
  • 大事だと思ってること
    • 実生活のつながり
    • 共有・成長する
    • イベントから広がるコミュニティ

connpass で使われている技術

• サーバーサイド
  • MySQL
  • Redis
  • Django
  • Unix
  • Nginx
  • Gunicorn
• クライアントサイド
  • CoffeeScript
  • REQUIRE JS
  • JavaScript怖い

PHP Language Update

PHP 5.5 の目玉

• ジェネレートとコールーチン
  • yieldキーワードの追加
• foreachで変数分解だ
• empty()の括弧内に変数以外が指定可能に
• finally
  • try-catch-finally
    • なぜ今までになかったのか
  • fatal errorが発生すると finaly が呼ばれない

Pythonでお仕事している人が日本にもたくさんいて嬉しいです。

発表者のみなさまおつかれさまでした。

Pyconに参加しようと思ったんですが、Python素人のボクはまず環境構築から。

Pythonのversion管理

Pythonはpythonbrew+virtualenvで環境を作るのが良いらしいので、言われるがままに環境作ってみます。

pythonbrewの環境構築

curl -kLO https://github.com/utahta/pythonbrew/raw/master/pythonbrew-install
chmod +x pythonbrew-install
./pythonbrew-install

pythonbrewの環境変数を通すzshの場合でも以下の内容を書くらしい。

[[ -s $HOME/.pythonbrew/etc/bashrc ]] && source $HOME/.pythonbrew/etc/bashrc

pythonbrew list -k # インストールできるversion確認
pythonbrew update # pythonbrewのupdate

2系と3系の環境構築。

pythonbrew install 2.7.2
pythonbrew switch 2.7.2

pythonbrew install 3.2
pythonbrew switch 3.2

virtualenvの環境はまた今度する。

Octpressの利用を始めたので、簡単にインストール方法と設定、使い方などをメモ。

github pageの初期化

mkdir username.github.com
cd username.github.com
git init

touch README.md
git add README.md
git commit -m 'first commit'

git remote add origin git@GitHub.com:username/username.github.com.git
git push -u origin master

octpressのインストール

先ほど作成した username.github.com と同じ階層にoctpressをcloneする。

git clone git://github.com/imathis/octopress.git octopress

cd octopress
gem install bundler

bundle install
Rake setup_github_pages

Rake generate
rake deploy

# 2つ一度にする
# Rake gen_deploy

記事投稿

記事の作成もコマンド1つタイトルは英語で。

rake new_post["my-new-page"]
# zshは以下のように書く
rake new_post\["my-new-page"\]

markdownの勉強にもなるし、GitHubとも仲良くなれるし、なかなかに良い仕組み。

いろいろ勉強します。

参考文献。

• http://tokkonopapa.github.io/blog/2011/12/30/octopress-on-github-and-bitbucket/
• https://blog.glidenote.com/blog/2011/11/07/install-octopress-on-github/

Blogger使っていたのですがいろいろと使いにくく感じていたのでこちらに移転。

適当に更新していきます。