西村さんの雑記ログ

技術や趣味について色々。

台風19号

日記

台風19号がとりあえず通過しました。
自分の住んでいる建物自体には幸い被害は有りませんでしたが、徒歩数分の場所にある川が氾濫してしまい、川の近辺の住宅街はそれなりに浸水していたようです。
と言うことで忘備録として今日までの簡単なあれこれを書き残しておきます。

前日まで：～10/10

数日前から10/12～10/13頃に台風19号が関東を直撃することは予報が出ていました。
10/12～10/14は体育の日の3連休ということもあり、各種イベントの開催予定が組まれていました。
私としては10/13～10/14に東京ビッグサイトで行われる同人誌即売会イベント「COMIC CITY SPARK 14」の1日目に行く予定をたてており、開催がどうなるかTwitterで情報を追っていましたが、10/10に残念ながら中止の発表がされ、少し落胆していました。
私が「原作はもとより、同人誌の新刊が出たら買いたい！」となっているジャンルの一つ、「図書館戦争（図書館戦争 - Wikipedia）」はファンの中心層が女性であること、10月という月が主人公たちが最初の出会いを果たした、原作の中で重要な月であることも有り、COMIC CITY SPARKへの参加が中心となる方の多いジャンルです。
趣味用Twitterアカウントのリスト上では、分かっては居るけれどもと残念がる声、参加予定だったサークルさんによる、本イベントで頒布予定だった同人誌の通頒開始の前倒し等の話が飛び交っていました。

COMIC CITY SPARK 14 -day1-

前日：10/11

勢力を落とさないまま関東を直撃する見通しになった台風19号。
10/10頃からニュースやTwitterでは頻繁に「台風への備え方」、「避難について」等の話題が頻出していました。
私としては

  • 自宅がマンションの2Fである
  • マンションよりも避難所の方が大きな川に近く、浸水の可能性は高い

という判断から、「家にこもる」という判断を取りました。
自宅にこもるとなれば、食料の確保が必要です。普段の生活では土曜日に一週間分の食料や消耗品ををまとめ買いしているのですが、今回は直撃するのが土曜日ということで、金曜日の内にドラッグストアとスーパーへ行き、食料品と雑貨を買い込みました。
ドラッグストアはそれほどでもなかったのですが、スーパーはさすがに品切れが目立ちました。手軽に食べることの出来るパンや、水の2Lペットボトルはほとんど売り切れていました。
帰ってからは台風に備えてベランダのものを全て室内にしまいました。
Twitterで「窓に物が飛んできた時のため、養生テープを『米』の字に貼るとよい」という話を見ました。
私の部屋が角部屋なのですが、結露防止のシートを貼っているベランダ側はシートがそのまま飛散防止になるだろうと考え、ベランダ側でない方の窓に養生テープを貼ることに。
……が、ここで誤算がありました。なんと、タイミング悪く家に残っていた養生テープを途中で使い切ってしまいます。
要は幅のあるテープを貼って飛散防止をすれば良い、という事のようなので、別にあった透明テープで代用して貼ることにしました。
実家の母親からLINEのメッセージと取りそこねた着信が有ったので、折返し電話をしました。
「台風は大丈夫？」ということが主題だったようで、それなりに話をして終了。
夕食とお風呂、洗濯を済ませて、早めにPCをシャットダウンし、携帯電話を充電して念の為枕元に懐中電灯を置き、お酒とおつまみをお供にして、PS4で「The Witcher 3」をプレイして就寝。

当日：10/12

準備は万端……かどうかは分かりませんが、泣いても笑ってもこの備えで行くしかありません。
起きてから家の中を掃除し、買い込んだ食糧で後はずっと室内。私自身がインドア派なので、それ自体は苦痛ではありませんでした。
携帯電話からは数時間おきに防災エリアメール着信の 夜が本番であり、停電するかもしれないという話なので、夕方の早い時間にさっさと夕食をとり、お風呂と洗濯を済ませて携帯電話を充電し、21:00過ぎにはもう殆ど寝るだけ。
合間に妹から「台風来てるけど大丈夫？」とLINEが入り、メッセージのやり取りをしました。
いきなりの停電が怖いので、PCは早々にシャットダウン。外が激しい風雨に襲われる中、お酒とおつまみをお供にして、PS4で「The Witcher 3」をすることに。
真夜中を数時間過ぎた辺りから、少しずつ外の音が弱くなりました。スマートフォンで時々Twitterを見つつゲームに励み、相応に酔いもまわってきたので、ぼちぼち寝る時間かな、と就寝。

翌日：10/13

台風一過でカラっと晴れた青空。
午前中に母親から「川が氾濫したそうけど、大丈夫だった？」とLINEが入っていたのに寝ぼけ眼で返信して二度寝し、お昼頃に起きて朝昼兼用でご飯を食べ、DQウォークを兼ねて散歩へ。
住んでいるマンションの周りは散歩に出た時はもう、何事もなかったかのようになっていました。強いて言えば、道路に乾いた泥で車輪の跡がくっきりと残っていたことくらいでしょうか。
もう少し足を伸ばして多摩川の方まで歩くと、多摩川に近い住宅街ではあちこちで掃除の真っ最中。
いくつかの路地には「車両通行止め」の看板が立っていました。
そして多摩川へ。
水量自体は平時より少し多い位でしたが、水は泥の色に濁り、うねるような流れになっていました。
サイクリングロードにもなっている堤防を超えて階段を降り、川の近くまで行こうとすると、草地でないところはまだ湿った泥が積もっていました。
流石に普通の靴ではちょっと危ないかな、と思って引き返し、草地になっている場所まで行って階段を降りて川の近くへ。
川原の草はなぎ倒され、片付けられたのか、川原の何かに引っかかっているのか、所々に草の小山が出来ていました。
帰り道に少し遠周りをして行くと、小型の重機が道路を覆う泥をかき集めていました。
周辺の建物では恐らく床上まで浸水したのか、扉を開けて拭き掃除する姿、事務所の椅子を外へ出して掃除する様子も見られました。
途中で地下駐車場らしきものを設けているマンションの前を通りかかると、ホースを入れて排水している光景が。
土嚢や止水板の効果がないほどの浸水だったのか、はたまた設置しなかったのかは判別出来ませんが、どうも地下部分が浸水して水が溜まっていたようです。
そんなこんなで散歩を終えて帰宅。ベランダにしまっていたものを出し、窓に貼っていたテープを剥がし、このブログ記事を書きました。

第3回 転職透明化らぼに行ってきました

勉強会

2019/10/3（木）に行われた「第3回 転職透明化らぼ-レジュメチェック編」に行ってきましたので、概要と感想を忘備録として書いておきます。

目次

行ってみた理由

私自身が転職活動中で、企業の方がレジュメのどの部分を見ているか、というテーマに興味がそそられました。

概要

会場

yappli, inc.（株式会社ヤプリ）公式企業サイト｜モバイルテクノロジーで世の中をもっと便利に、もっと楽しくさん内のイベントスペースでした。
ちなみにアプリ開発・運用・分析をクラウドで実現するYappli（ヤプリ）こういったプロダクトをされている企業さんです。
プログラミングなしで、アプリの開発・運用・分析をクラウドプラットフォームから開発・運用出来るそう。
自社でアプリが必要だけど、エンジニアの手が回らなかったりそもそも居なかったり、フルスクラッチする程でもないけどSaaSで全部をするにはちょっと……といった所に刺さりそうなプロダクトですね。
イベントスペースは広くきれいで、高階層（ビルの41階！）にあるため、窓の外から見える夜景もとてもきれいでした。

ドリンク・フードスポンサー

イベントを支援してくださる企業の方からのドリンク・フードの差し入れがあり、イベント開始前に好きなものを取って、LTやパネルディスカッションを聞きながら、もしくは合間に飲食する形でした。
フードはピザとお寿司、ドリンクはビールとアップルジュースでした。 自分自身はタイミングを図りそこねてピザで済ませてしまいましたが、アップルジュースの瓶が背が低めの丸くて可愛らしいデザインだったのが印象的でした。

始まるまで

会場に入るとまずは受付。connpassの受付票を提示し、本日の名札をもらいました。
オープニングで話があったのですが、ネックストラップの色が参加者枠で分かれていて、求職者枠は青、採用担当枠は赤となっていました。
ひと目でどちら側での参加かが分かるので、分かりやすくて良いやり方だと感じました。
メモサイズの付箋とペンを受け取り、事前にパネラーの方へ質問してみたいことを書き、壇上に用意されたボードに貼っていくというものがありました。 こういう機会は恐らく人生でもそうないので、疑問というよりは悩み相談のような質問を書いてボードへ。
この質問については、LT後の休憩時間に参加者が「正」を書き込む形で投票し、後述するパネルディスカッションの時間に投票数の多いものから回答していただくというものでした。

LT

モデレーター（司会）はしがないラジオで知られるgami@『完全SIer脱出マニュアル』商業版発売中！ (@jumpei_ikegami) | Twitterさんでした。
トーク力が高いというのか、程よく参加者の肩の力を抜くような話が入り、するすると進めていくのは、大勢の前で話すことが苦手な自分としては「すごいな……」と感じました。

パネラーLT

LT1： 企業側が望んでいて、かつ準備がめんどくさくないレジュメの内容について考えた

面白法人カヤックで人事部長を務めていらっしゃる柴田史郎 (@4bata) | TwitterさんによるLT。
企業側からとしては、

  • レジュメを盛らないでほしい
  • 会社とのカルチャーマッチを知りたい

レジュメを書いていてよく悩む、「自分の評価」については

  • 他人からの評価コメント
  • 社内の評価

をコピペすると良いという話も。
こういう手法を使う場合は、社内/社外でそういう相手をいかに持っているかが重要そうですね。
業務的に客先常駐の割合が高かったりで、社内での交流度が低い会社や、人付き合いの苦手な方は、こういう評価を聞いてみるのは中々難しそうですが……

カルチャーマッチについては

の2面から。カルチャーマッチについて細分化すると、

  • 技能：スキルマッチ
  • 文化：会社の暗黙のルール
  • 役割：キャラ

といった面がある。
役割＝キャラについては、スキル以外の要素（趣味や物事のやり方といった面かな）、キャラの掘り下げとして他人からの推薦文を「誰からか」を明記して書くこと、
文化＝会社の暗黙のルールについては、自分の視点から、今の会社に入ってからどのようにして馴染んでいったのかを書くことが効果があるそう。

LT2： レジュメで技術力を表現しろと言われても。っていうか技術力って何？

クラウド名刺管理で知られるSansan株式会社のTakahashi, Takeru @Sansan (@tkrtkhsh) | TwitterさんによるLT。

レジュメとはなにか？

採用者はレジュメで何を知りたいか、どうしたいか

  • 技術力を知りたい
  • 面接の手間を省きたい、面接をスムーズにしたい

技術力とはなにか？

  • 課題を解決する
    • 企業によって課題の分布の広さが異なる
      • SIer：狭め
      • Web企業：広め
  • 経験と応用
  • 応用力

レジュメに書く技術力

  • 表現は変えられる
    • 技術の解像度を高くする
      • 担当プロジェクトで使った技術を詳細に書く
  • 経験を応用したエピソードを解像度高く書く
  • 概念と課題の解決

こう言われて、自分のやってきた経験を見ると、色々考えますね……

LT3：レジュメで何を見てもらえると思っていますか？

Retty株式会社 - Retty.Incのkosako (@aki85135) | TwitterさんによるLT。
本来の登壇者がインフルエンザでダウンしたため、急遽登壇することになったのだそう。ニュースでも今年はインフルエンザの流行が早いような様子が見えるのでそろそろ気をつけた方が良いのかもしれませんね。

立ち位置

  • マネジメント
  • プレイヤー
  • ポテンシャル

魅力に関してはアウトプットすると良い

レジュメにあるとより分かりやすくなるもの

  • スキルマップ
  • 考え方やスタンスについて

レジュメはどこまで見るか

  • 面接のフェーズによる
  • 懸念やチェックしたいポイントも見る
    • レジュメを書く側としては、そういうポイントに対して払拭できる材料を提供できるとよい

スキルマップはいい案で、試してみたいです。
懸念になるポイントは自分も抱えているので、払拭できる材料を提供したいですね……

スポンサーLT

LT1：フェアな世界でまっすぐな転職を

転職ドラフト｜ITエンジニアを年収・仕事内容つきで競争入札で知られる株式会社リブセンスのまさよふ (@masayofff) | TwitterさんによるLT。

強いレジュメとは？

  • あなたがいかに強敵（困難なプロジェクトや課題、新しい分野の技術）を倒したかが分かるレジュメ

アウトプットは残さず書く

  • 迷ったら全部書く
    • 何でも良い
    • 様々な経験
  • 野望ややりたいことについて、思いの丈を書く

LT2：ここが変だよ"ふつう"の採用

チームにさらなるコラボレーションを | 株式会社ヌーラボ(Nulab inc.)のAngela @ ぬ (@posi0202) | TwitterさんによるLT。
ヌーラボさんに関しては、balcklogの企業だったのと、本社が福岡なのをここで知ってびっくりしました。
backlogは自分では使ったことが無いけれど、テック系の情報収集をしていると時々耳にするツールですし、福岡は過去に住んでいたことがあるので親近感がわきました。
ヌーラボさんは拠点が日本だけでなく、海外にもあり、サービスによっては日本よりも海外のユーザーが多いものもあるのだそう。
海外拠点があるというのは、東アジアが近くて九州支店の多い地域だからか、福岡に拠点を置く企業には時々ありますね。

日本における「ふつう」の採用としては、

  • 年齢
  • 学歴

をレジュメに書くことがありますが、この辺りは国によっては聞くことが出来ないそうです。
自分の記憶では、アメリカは確か年齢・性別・顔写真は法律で禁止だと見た記憶がありますので、そこまで事細かに聞くのは日本だけでは……と思います。

採用側としては、

  • 採用したい人物像に合うか

が重要。
例えばヌーラボさんだと、

  • ユーザーの多様化
    →色んな人が欲しい

のだそうで。 後は、

  • 経験年数に対するスキル

が分かるのも重要。

休憩

LTからパネルディスカッションの間に10分程休憩が入りました。
この間に、イベント開始前に壇上のボードに貼られた質問票について、パネラーに答えてもらいたい質問に「正」の字を書き込む形で投票。

パネルディスカッション

壇上のボードに貼られた質問票から、投票数の多い順にパネラーの方々に答えてもらう形式で進みました。

自己PRについて

  • 強みを書く
  • ネガティブなことは書かない
  • プラスアルファの要素
  • 若手はプライベートな取り組みや熱意について書くと良い

質の良い人の集まる施策はあるか

  • 転職ドラフト
  • 新しいツール
    • アンテナの高い人が来る

GitHubはどこまで見るか

  • 見ない、見てもどの言語をやっているか程度
  • 「この人はいいな！」と思ったら見る

驚いたレジュメ

  • 破天荒すぎる経歴
    • 10代で起業、後に放浪してたとか、中々すごい生き様。
  • 5ページ中の4ページが自分の人生のポエムだった
  • 自分の会社の社員が検索で出てきてしまった
    • 意外とありそう……

シニア層エンジニア（CTO）などの探し方

  • なにかのタイミングで自分の会社のことを思い出してもらえるか
    • あらかじめコンタクトをとっておく
    • 実際に会ってみる、情報交換する
    • 雑談ベースでも良いので会ってみる

こってりしたレジュメはありか

  • 濃い内容なら意外と通る
  • ポイントは文章で伝わるようにはっきりさせる

レジュメでアピール出来るようなものが無い

  • 応用力、技術の解像度
  • いずれ役に立つ知見や経験を書く
  • 他の人から聞く、第三者（転職エージェントなど）からのフィードバック

コーディング面接で見るもの

  • 設計、パフォーマンスチューニング
  • どれくらい解けているか、読みやすさ、保守性
  • 基礎力、設計、考え方
  • 課題にどうアプローチするか、ディスカッションできるか

ポートフォリオの評価ポイント

  • 余り参考にはならない
  • バイタリティを見れる
  • 新しい方が良い
  • ブログなどの、普遍的で継続的なアウトプットは見る

未経験で活躍した人の共通項

  • 引きこもりだった
    • でも引きこもりながら色々作ってたのだそう
  • 変人
    • コミュニケーションは通りにくいが、突き抜けたところのある人
  • 少ない経験でどれだけ学べるかが重要
  • 変人・奇人
    • スイッチが入ると凄まじい人
  • 質問できる人
  • プライドが高すぎない人

懇親会

最後に20分ほどの懇親会が設けられました。
パックマンルール（懇親会でもっと広まってほしいパックマンルール - Qiita）により、輪ができても一箇所は空いているのであちこちに入りやすい感じでした。
懇親会で聞いた良いことは

  • レジュメで迷ったら、エージェントに見てもらうと良い
  • 知ってる技術があるなら、アウトプットしておくと良い

ですね。
エージェントはIT系に強い所にも聞いてみるのが良さそうかなと思いました。

感想

普段滅多に聞くことのできない、テック系企業の採用側からの視点を聞くことが出来たのは新鮮でした。

今回の話をベースに自分のことを振り返ってみると

  • 技術の解像度の高さ
    • 担当していたプロジェクトで、自分が使っているかに関わらず、使われていた技術は思い出す限り書いている
  • 経験と応用力
    • 実務面であまり出来ていない記憶がある
    • 理由：プロジェクトにばらつきがあり、現プロジェクトで直前のプロジェクトの経験が即活かせるとは限らなかった、類似のプロジェクトにアサインされるまで別のプロジェクトで期間が空き、経験をそのときに応用出来なかった
    • Try：節目（何ヶ月毎や、プロジェクトが変わる時等）に経験や感想等をアウトプットしておく（ブログでも個人の日記でも）
  • いずれ役に立つ知見や経験
    • 経験してきたプロジェクトのばらつきにも関連するのですが、.NETのWindowsアプリケーションからWebバックエンド、フロントエンド専任のいないプロジェクトだったので軽くフロントエンド周り（HTML, CSS, Javascript）、果てはPL/SQLまでやったことはあるので、妙に広さはある感じです。
  • 何でも書き出す
    • 別記事でまとめて書きたい

WEBエンジニア勉強会 #14に行ってきた話

プログラミング 勉強会

今回は１ヶ月ほど前の話で、「WEBエンジニア勉強会 #14」に行ってきた話です。
当日はノートに走り書き+箇条書きで記録を取ったので、それを参考に当日の感想を箇条書きで起こしています。

web-engineer-meetup.connpass.com

行ってみた理由

個人的に最近PythonでWebフレームワークを触っているのですが、LT一覧に「GAEによるPythonWEBアプリケーションの高速開発 (10分)」というものを見つけ、気になったので思い切って参加してきました。

LT

前座を含め、計8件のLTがありました。 内容的には設計的な話からインフラまで、WEB開発に関わるものなら何でもありです。 普段プログラミング、それも客先常駐を中心にしていると、中々触れることのない分野もあり、かなり刺激的でした。

前座LT：人工肉を食べよう

普段は前座枠までLTが埋まるそうですが、今回は埋まらなかったということで、主催者のOSCA (@engineer_osca) | Twitterさんによる「人工肉」についてのLTでした。
試食まで用意するという、中々熱の入ったLTでした。

  • 畜産、特に牛の肥育は温暖化ガスを大量に排出する→環境問題
  • 環境問題に配慮し、肉ではなく、大豆を用いた人工肉を使ったファストフードの紹介

私事ですが、生まれ育ったところが畜産と農業の盛んな土地なので、「大豆を用いた人工肉」は畜産の大変さを軽減する手段の一つで、かつ移行も出来る手段なのではと感じました。
（とはいえ、地元に関しては放牧による草原の維持と、草原が観光資源であり、独自の生態圏を維持しているという面もあるので、一律に畜産を否定できないのも本心ですが……）

LT1：何故マイクロサービスにするんだっけ？

今回の会場スポンサー、株式会社カサレアルの多田さん（Masatoshi Tada (@suke_masa) | Twitter）によるマイクロサービスに関するLT。
カサレアルはエンジニアの研修を行う会社で、マイクロサービスに関する研修もあるのだそう。

  • マイクロサービスとはどういうものか
    • 従来のシステム（モノリシック）に対する対義語
    • 複数のサービスが連携し合う
      • モノリシックは一つのサービスで全ての機能を持つ（密結合）
      • マイクロサービスは疎結合なサービス思考アーキテクチャ
        • あるサービスの変更が他のサービスに影響しないのが理想
  • 何故マイクロサービスにするんだっけ？
    • 儲かる機能をマイクロサービス化する
    • モノリシックなサービスの欠点：頻繁な変更に弱い
      • 1つの機能を変更すると考えると……
        • 再デプロイに手間がかかる
        • 変更時の影響範囲の大きさ
      • 頻繁な変更が不要なら、無理にマイクロサービス化する必要はない
    • マイクロサービス：頻繁な変更が可能
      • 1つの機能を変更すると考えると……
        • 再デプロイの手間が少ない
          • 1つの機能を担当するサービスだけを止めて再デプロイすることが可能
        • 変更時の影響範囲が少ない
  • マイクロサービスは「そうできるように作るのが重要」
  • メリット・デメリット
    • サービス毎に自由な言語やフレームワークを使用できる
      • メリットかと言われると「？」
        • 保守が大変
  • 気をつけること
    • 障害率UP
      • ダウン時の自動再起動
    • ネットワークを挟む
    • 障害が伝播する
    • 技術的難易度のUP
    • 金銭面はコストUP
  • どこで分割するか？
  • テストは重要

LT2：失敗から知るAWSサーバレス

yu.eguchi (@pal_of_pome) | Twitterさんによる、AWSサーバレスでの失敗に関するLT。
お客様の要請でAWSサーバレスを用いたS3への画像アップロード機能のあるシステム構築を行った際、色んな制限に引っかかったのだそう。

  • AWS、EC2を自分で管理しない場合
    • ペイロード上限
      • API Gateway：10MBのペイロード上限
      • Lambda Function：6MBのペイロード上限
      • 回避策
      • フロントエンドでサイズチェックを行う
      • フロントエンドから直接S3に上げるような設計にする
        • APIではS3アップロード用の署名付きURLを返す
    • タイムアウト
      • Lambda Function：3秒～15分まで設定可能
      • API Gateway：50ms～29秒まで設定可能
      • したがって、全体で最大29秒以内に処理を完了しなければならない
      • 回避策
        • キューに退避する（Amazon SQSなど）
        • Lambda Functionを更に呼び出す
        • Step Functionsを使う
  • そのシステムは本当にサーバレスが必要か？
  • 公式ドキュメントは大事

LT3：愛されるダッシュボード

池田寿司 (@ikedaosushi) | Twitterさんによる、ダッシュボード機能開発に関するLT。
LT一覧からは分かりませんでしたが、Pythonによる開発ですね。
現場～開発のギャップを減らすため、Jupyter Hubを使って、関係者間でダッシュボードのサンプルを共有して動く状態を見れるようにしたのだそう。

  • ダッシュボードが使われなくなる
    • 見たいデータじゃない！
      • 正しいデータ
    • 可視化の方法が違う！
      • 正しい可視化
  • 使われるダッシュボードにするには
    • イテレーションが必要
      • ビジネスサイドとの距離感
      • Jupyter Hubの導入
        • マルチユーザで使えるJypyter Notebook
          • Jupyter Notebook
            • Pythonの対話環境
            • ブラウザ経由で使える
        • ダッシュボードのNoteBookを作成し、共有
          • ダッシュボードのデモが出来るようになった
          • 現場の方で条件を変えて確認することも可能になった
        • 十分にイテレーションを回した後、Dockerでリリース

LT4：アジャイル好きのウォーターフォールとの使い方

たけき (@takeki1967) | Twitterさんによる、ウォーターフォールの中でどうアジャイル的手法を使うかについてのLT。
裁量があることが前提条件のようですが、ウォーターフォールの中にアジャイル的なやり方を一部埋め込むことは可能で、やると中々便利になるという話。
ウォーターフォールは色んな思い出がありますね……（遠い目）
手作業で細かいチェックをするという作業が苦手な面があるので、個人的にはユニットテストや自動テストがある環境が好きです。

speakerdeck.com

  • Ruby On Rails

  • SchemaSpy

    • ER図、デフォルト仕様の出力ができる
      • HTML形式での出力が可能
    • Dockerイメージあり
    • Railsオプションあり
    • JDBCが動くDBで使用可能
    • 副産物：DBコメントからl18nメッセージリソースを生成

  • RSpec+PICT

    • PICT
      • ケースの組み合わせ出力
    • RSpec
      • 予めテスト項目だけを書いておく

  • 辛い作業を楽しい作業で置き換える

LT5：mdx-deck v3 and code-surfer v3

Naturalclar(Jesse K.) (@natural_clar) | Twitterさんによる、React hooks apiを使ったスライド作成モジュール「mdx-deck」とコード表示モジュール「code-surfer」に関するLT。
Reactはバリバリ触ったことは無いですが、色々出来てワクワクしますね。

  • mdx-deck v3
    • スライド作成
    • Markdownが使える
    • hooks api
      • useSteps
        • 1枚のスライドで色んな動きができる
      • useDeck
      • useKeyboard
      • useSwipe
  • code-surfer v3
    • 8/30時点ではα版
    • コードをきれいに見せることが出来る
    • Diffを表示することが出来る
      • 変更点にズームインすることが出来る
    • Presentation Code
      • カンペの表示ができる
    • 注意点
      • v1からの移行は変更点が多い

LT6：GAEによるPythonアプリケーションの高速開発

しまかぜsoft (@shimakaze_soft) | Twitterさんによる、Google App Engine(GAE)でのPythonアプリケーション開発に関するLT。
個人ではPython+Djangoを触っているのでタイムリーな話でした。
GAEだとデプロイは簡単ですが、色々制約や難点がありそうですね。

  • GAE
    • StandardとFlexible
      • Standard
        • ローカル書き込み：不可
        • SSH接続：不可
        • 起動が早い
      • Flexible
        • ローカル書き込み：可能
        • SSH接続：可能
        • Dockerfileによるカスタマイズ
    • yamlで各種設定を行う
    • メリット
      • nginxは不要
      • デフォルトでgunicorn設定済み
      • requirements.txtを自動参照してモジュールを設定してくれる
    • デメリット
      • デプロイは遅め
      • GAE内でドメインは1つしか持てない
      • WebSocket未対応
      • 価格はやや高め

LT7：How Can They Know That? A Study of Factors Affecting the Creepiness of Recommendations

Yuya Matsumura (@yu__ya4) | Twitterさんによる、推薦システムに対する感情（驚きと不信感）の海外論文に関するLT。
なおスライドは当日仕上げだったそう。
推薦システムはAmazonを始め色んなサイトにありますが、サイトの取り扱うものによって的確な推薦が驚きか不信感かで分かれることがあるそうで。
センシティブな内容（健康等）を取り扱うサイトほど、的確な推薦は「なんでこのサイトはこんなことまで知ってるんだ？」とネガティブに感じることがあり、
逆にホテルや映画などの娯楽よりになると「これだ！」「こんなのもあるのか」とポジティブな感情に寄っていく傾向があるという話。
では、サイト側としてはどう信用してもらうかというと、透明性、説明性、ユーザーによる設定が可能という辺りがポイントらしい。

英語ですが、元の論文はhttps://interactivesystems.info/system/pdfs/907/original/RecSys-19.pdfかな。

  • RecSys
    • 推薦システムについての会議、トップカンファレンス
  • 推薦システムに対するCreepinessの調査
    • Creepiness：ネガティブな感情
    • 高すぎるRecommendはユーザーの不信感を招く
    • 要因・影響
      • 感情測定尺度による調査：複雑な感情の調査
    • 性格によるCreepiness
      • 曖昧さへの不快感を感じるか
        • 不快感を感じるほどCreepiness耐性が高い
    • システムとCreepiness
    • ユーザへの影響
      • conversionの低下
      • 信頼の低下
        • 信頼してもらうにはどうするか
          • 透明性
          • 説明性
          • ユーザーによる設定が出来ること

感想

体力的に平日が夜遅いのはキツイなと感じ始めた年齢なので、金曜日夜開催だったのは大きかったです。
前述しましたが、普段関わらない分野の話を聞くことも出来て色々と刺激がありました。
機会があればまた行ってみたいと思います。

技術書典7に行ってきました。

プログラミング

昨日行われた、技術系同人誌即売会の「技術書典7」に一般参加者として行ってきました。

techbookfest.org

そして、イベント終了後は非公式アフターにも参加させていただきました。

techbook-and-ethanol.connpass.com

初参加の上、一般参加者が非公式アフターに飛び込むというのは無茶も良いところですが、同人誌という形で技術書を書かれている方々の生き生きとした様に元気をもらいました。

行ってみた理由

なんで行ってみたか？【技術書典7編】

まずは私的なことを説明しますと、元々客先常駐のプログラマだったのですが、色々あって1月から休業し、7月末をもって会社都合と言う形で前職を退職しています。
休業になった時、自分自身に原因が有るとは言え、当時の所属会社と職業に対するモチベーションは地の底でした。
休業の間、会社から与えられた課題をこなしつつ、以下のようなことをやっていました。

  1. 当時はまだ同人誌版だった「完全SIer脱出マニュアル」(Amazon CAPTCHA)やその他のモチベーション周りに関する本を読む
  2. 技術系podcastを聴き始める
  3. 技術用のtwitterを開始

Yui Nishimura (@y_nishimura_tec) | Twittertwitter.com

技術用のtwitterなので、趣味用のtwitterでフォローしていた技術系の方の他に、「しがないラジオ」を聴きつつ、ゲストとして出演された方を中心にフォローしていきました。
ついでに、ゲスト出演された方のpodcastもiTunesやGoogleポッドキャストで聴き始め、更にゲスト出演された方のpodcastと芋づる式に増えていき、今では結構な購読数になっています。
そうして情報を収集する中で、「技術書典」というイベントの存在を知り、9月に行われることも知ります。
前日まで散々行くか迷ったのですが、「行きたいものは行けるときに行っておかないと損だ」という思い切りで一般参加で行ってみることにしました。

技術同人誌と自分

元々結構なオタクで、九州の前々職から転職するときに関東に出てきたのも、「コミケに行きたい」、「twitter上でお知り合いになった方と会ってみたい」という欲望ドリブン的な部分がありました。
もちろんコミケに一般参加で行き始め、技術同人誌も手に取っていたのですが、割と積ん読になっていました。

なんで行ってみたか？【非公式アフター編】

技術用のtwitter上に告知が流れて来て、LTの「読者を置き去りにする技術」、「なぜ『綿を育てて布を作る』を書いたのか」が気になってはいましたが、これも前日まで散々悩みました。
「売り子/一般参加者枠」という枠はありましたが、一般参加で初参加でそう繋がりもない身で飛び込むのは結構思い切りが要りました。
こっちも結論的には「行きたいものは行けるときに行っておかないと損だ」という思い切りでした。

感想

技術書典7

今回600スペース以上という、オンリー系の同人誌即売会でも結構な規模で、11:00～13:00まではチケット事前購入制、13:00～17:00は無料入場という形でした。
私が行ったのは無料入場となった14:00過ぎですが、それでも入り口の設けられた2Fの建物外周に並び、更に2F会場内の待機列でしばらく待ち、20～30分ほどかかりました。
それはそれとして、様々な技術系同人誌とそれを求める人たちが一堂に会する様は見ていても壮観でした。
プログラミング、インフラ、設計、SQL等、システム開発に関する本が多数を占めますが、中には「綿を育てて布を作る」、「衛星を打ち上げる」、「キーボード」等、システム開発以外の技術に関する本もあります。
流行系としては、VR/AR、Vtuberに関する技術で出展されている方もいらっしゃいました。
そういうワードに興味を抱いたならば、一見してみる価値は十分にあります。
コミケに行ったことのある人に言うならば、コミケの技術系の島を更に拡大したものというと非常に分かりやすいでしょうか。
「都合が合わない」「地方だから行けない」という方も安心してください。多くのサークルさんが、boothや各種同人誌通販サイトにて通販を行っています。
電子版での通販も相当数あります。電子版だと、場所を取らず、売り切れを心配することも無いので非常に楽です。
boothや技術書典の後払いで活躍しますので、PayPalを使われていない方はアカウントを取得して銀行口座を連携しておくと重宝します。
サークル主さんのtwitterやブログ等を見ると新刊や通販を告知されていますので、まずは気になる技術やプログラミング言語でtwitter検索をかけて調べて見るのが良いと思います。

非公式アフター

半数以上がサークル参加者と売り子さんで、非常ににぎやかな会でした。 LTでは前述した「綿を育てて布を作る」同人誌を書かれたAωR@技術書典7[せ31D(ホールD)]、11/23銭けっと@大阪、C97？ (@atelier_wu) | Twitterさんによる「どうして『綿を育てて布を作る本』を書いたのか」という話や、「AWSなのに、エモい」を書かれたかろてん＠AWSなのに、エモい。 (@carotene4035) | Twitterによる読者を置き去りにする技術 - Speaker Deckなど、様々なLTが行われました。
予定されたLTの終了後は、希望した人がスライドなしで数分ずつ語る、インスタントLTのような物が行われていました。
こちらも、「電子グッズを作ろうとして基盤を注文したら、ミスで裏側のパターン配線がされていなくてポシャった」、「今回の頒布数と売上数を大公開して結果発表」等、中々面白い話を聞くことが出来ました。

私自身、二次創作同人誌を買うほどのオタクでも有るので、「2000円を超えると売れにくくなる」と話されていたのは割と納得感のようなものがありました。
二次創作で小説本を多く買っていますが、特にページ数の増えた小説本の値付けにはtwitter上で毎回誰かが悩んでいます。割とマイナージャンルを覗くこともあり、好きなジャンルであればお値段はいくらでも来いと言いたいところですが、現実問題として1000円か1500円を超え始めた辺りから購入されにくくなる様子です。
技術書に関しては、一般に出版されている本の価格も比較的高めであることから、即決で手を出しにくくなる価格の境界線がやや上がり、2000円あたりになっているのでは無いかと推察しています。

戦利品

最近触っているのがPythonのWebアプリケーション系であることもあって、Pythonに関する本、モチベーション方面に関する本、あとはtwitterでフォローしている方の本で気になった本をポンポンと10000円ちょっと買った感じです。

f:id:y_nishimura_728:20190923192405j:plain
技術書典7の戦利品（A5本）
f:id:y_nishimura_728:20190923192511j:plain
技術書典の戦利品（B5本）