りまりまだんの本拠地

プリキュアを応援しつつ、技術的なこととかを色々かくぞ

『WANTEDLY TECHBOOK 2』を読みました

めっちゃ表紙がキラッキラでした。会社ももっと輝くといいですね(適当なフォロー)。

本の情報(敬称略)

  • サークル名:Wantedly執筆部
  • ページ数:80p

f:id:MofuMofu:20170422165435j:plain:w300

とにかくキラッキラだと言いたい。光の反射率半端ない(褒めている)。

概要

ビジネス用SNSサービスWantedlyで有名なWantedly株式会社のエンジニアさんがWantedlyのバックエンドで使われている技術について語った本です。なんだかめっちゃくどいですね。1

GithubDockerに関する内容が半分以上を占めていました。あとはWantedly Peopleで使われている機械学習データの使用ポイントや学習方法について言及されている章もありました。

Docker部分はコンテナ利用の思想・開発環境としてDockerを使用する際のメンテの勘所・kubernetesを利用したアプリケーション実行環境の構築・アプリケーションデプロイなどがメインでした。

最初kubernetesがなんのことがわからなかったので自分でちょっと調べました。Dockerなどコンテナ技術をグルーピングし、管理・監視・ネットワーク系設定の管理ができるOSSなんだそうです。ちなみに開発元は天下のGoogle先生です。今はいろんな会社も開発に参画しているようです。今後主流になりそう。

Githubの部分はissueの切り方・会議記録をissueで管理するなど、開発者のコミュニケーションの場としていかにGithubを有効に使うためのTipsが記載されていました。

issueやタスクの進捗はチェックボックスを用いて細かく管理するなど、みんなに優しく開発を進めるためのTipsが多く、参考になりました。

感想

自分の周りはSVN管理が主体なんで、やっぱりGithub便利だよなあーと思いました

というのはさておき、まずはエンジニア全体のレベルが高いという印象を受けました。GithubやDockerなど、最近(なのか?)の技術ベースかつ、機能に合わせて最適な技術を選択・運用している時点でエンジニアのレベルの高さを感じます。

サービス構築のための技術選定で自社の得意なものしか扱わない、むしろ自社フレームワークOnlyとかあるあるですが、この本を読む限りWantedlyはそうでもないのかなと思いました。

印象的だった部分

Wantedlyの開発ルールみたいなのが第1章で紹介されてて、全部めっちゃ面白いなと思ったのですが、特にこのルールが気になりました。

ログをファイル出力ではなく、STDOUTにしましょう

本番環境もSTDOUTになってるんだろうか。ただし、その前で開発/本番(環境)一致がポリシーと紹介されていたので可能性は高いと思います。
障害発生時のトラブルシュートするときとかどうするのか気になりました。自分がDockerを本格的に使ったことがないので勘所がないだけなのか。

でも、ただ無意味にログファイルを垂れ流しておいてリソースを圧迫するくらいであれば潔くそんなものは持たないという考えもありかなと思いました。

本の内容以外で

やっぱりWeb系企業だとGithubとDockerとかバリバリ使っていく感じなんですね。エンタープライズ企業でDockerメインのところってどのくらいあるんでしょう。

バージョン管理とかもSVNとGit、どちらが多く使われているのか統計を取ってみたら面白そうです。さすがに今はGitメインなんじゃないかと思っていますが…。


  1. 企業HPなので一応URLリンクは貼りません。ただのチキンですが。興味があればGoogle先生から辿っていただくのがよろしいかと思います。

『できる同人誌即売会レジ構築』を読みました

同人誌即売会につきものの、売り上げ管理が面倒問題はレジを導入すれば解決するのかもしれない。と思いました。

本の情報(敬称略)

  • 執筆者:聖やきょう
  • サークル名:日本同人誌コード管理センター
  • ページ数:22p
    f:id:MofuMofu:20170416162430j:plain:w200

概要

同人誌即売会でレジを使うために必要な備品・機器(レシート用プリンターやバーコードリーダーなど)・準備方法・運用結果をまとめて記載している本

感想

まえがきの中で、次のように記載がありました。
突然ですが、筆者は算数が苦手です。
暗算が苦手です。単純な足し算引き算と九九程度なら何とかできますが、繰り上がりとか繰り下がりとか桁を跨いだ計算とかになるときに極端に混乱します。

超同意です。3桁の掛け算がスラスラできる人が信じられません。
というのはさておき、苦手な部分は科学の力に任せて自分のやるべきことに集中しようという姿勢がいいなと思いました。ITのあるべき姿ってこういうものなんだろうな、とか思いを馳せてしまいました。個人の努力でどうにもならないことってありますよね。

同人誌の売り上げは良く正の字で管理しているイメージですが、この本を参考にレジを導入してしまえば集計時間が半分くらいになりそうです。
本にもあるように、在庫の棚卸し時間を執筆に充てることができるのはすごくプラスだと思います。

レジまでとはいかなくても、在庫管理アプリを導入するだけでも楽になりそう。次の機会があれば何かしら導入してみたいです。机の上のスペースと相談ですが。

印象的だった部分

個人でレシート、出せるんですね。POSレジとか大型の機械じゃないと出せないと思っていました。

こちらが実際に出して頂いたレシートです。印刷には少し時間がかかりますが、普通のレシートと同じ(もしくはもっと綺麗)です。

f:id:MofuMofu:20170416162325j:plain:w200

レシートに記載する内容は会計用アプリで決めておき、印刷は簡易的なプリンターが行うスタイルでした。片手で持てるので持ち運びも楽なんだそうです。

本の内容以外で

プリンターとかバーコードリーダーとか、オークションやリース品を用いて購入できるそうです。自宅でネットワーク機器を運用する人がヤフオクとかでL3スイッチ買ったりするのは聞いたことがありますが…オークションって色々なものが出回ってるんですね。

『isdn 同人誌にバーコードを書こう』を読みました

技術書典2でたくさん同人誌を買いました。積ん読になる前に全部読んで、感想文でも残してみようかと思います。

本の情報(敬称略)

  • 執筆者:聖やきょう
  • サークル名:日本同人誌コード管理センター
  • ページ数:8p

f:id:MofuMofu:20170415133232j:plain:w200

概要

同人誌にバーコードを記載することを想定し、日本のバーコード規格(線の長さや配置の決まりなど)・Windowsを用いたバーコード生成方法が記載されています。

感想

バーコードって自分で作れるんだというところにまず驚きました。バーコード作るのってなんか特殊なところで一括生成して、みんなに配ってるのかと勝手に思っていたので、自家生成できることにロマンを感じます。

本にはWindows用ソフトの紹介のみでしたが、調べてみるとMac用のバーコード作成アプリはもちろん、Webアプリでも生成できるものがあるみたいです。

“バーコード作成"・"Macとかで検索するとたくさん出てきます。

印象的だった部分

バーコードの配置図が載っていたのですが、各バーコードの長さ以外にもバーコードとバーコードの間隔にも決められたミリ分の隙間が必要なのには驚きました。
バーコードを置く場所が決められてるのはなんとなく分かりますが、バーコードのISDNコードは何ミリ開けるとか知らなかったです。

思わず商用の本をいくつか出して比べてみましたが、同じところに印刷されている気がします。
よく考えられてるものです。
あと、雑誌と書籍でバーコードの種類?規格?配置方法?って違うんですね。
今まで気にしたことなかったのですが、改めてじっくりみると配置が別なんですよね。

…というよりもどーやってこれらの情報まで辿り着いたのかが一番気になる。

はじめにの中で、
製品パッケージに印刷するバーコードの部分だけを専門に製版する会社が存在するなど、専門的な知識も求められるのも事実である。
と書いてありましたが、本当にその通りだと思います。職人芸の極みすら感じました。

本の内容以外で

これは完全に蛇足かつ本とは関係ないのですが、コピー本って印刷会社で作成できるの初めて知りました(オンデマンド・オフセットだけかと思ってた情弱)。

技術書典2 もふもふちゃんの戦い履歴

都内でインフラエンジニアをやってるもふもふといいます。
普段はオンプレ環境の構築とかセキュリティ基盤の構築とかやってます。(最近AWS始めました。泣きたい。)

4/9(日)に開催された技術書典2にて、
『ログと情報をレッツ・ラ・まぜまぜ!~ELK Stack で作るBI環境~』
を頒布しました。頒布に至るまでの経過と反省を書き残しておこうと思います。

1月初旬くらい:もふもふちゃん、技術書典2の存在を知る

「今年もあるらしーよー」と話しているのを聞いたくらいでした。
去年の技術書典は行こうとしたら入場制限がかかってて諦めてしまったので、今年は行きたいなーくらいでした。

1月中旬くらい:もふもふちゃん、『技術書典2 技術書の作り方勉強会』に参加を決意する

技術書典2 技術書の作り方勉強会 ~執筆環境をワイワイはなそう~ の存在を知りました。
技術書の作り方とかそうそう聞けないので、参加してみることにしました。
自分でもできそうだったら本を作ってみようかなと思ったくらいでした。

2月5日:もふもふちゃん、技術書の作り方勉強会に参加する

Re:VIEWという便利な言語と運命的な出会いができました。本当にありがとうございます。
即売会とはなんぞやから、本の体裁や入稿方法まで一通り網羅していて分かりやすかったので技術書を書いてみたい人は機会があれば参加したほうがいいと思います。

勉強会はツイッターのハッシュタグ#技術書展で盛り上げてねって話だったので、めっちゃつぶやきまくってました。
あとサイボウズオフィスが綺麗すぎてただの観光客になってました。

2ヶ月後に自分ごとになるとも知らず、調子に乗ってツイートしている↓

ちなみに、帰ったら気が変わらないうちに印刷所へ申し込みまでやってしまいました。
内容は業務でも使っていた、Elasticsearch+Kibana+LogstashでKibanaのDashboardを作ってログ分析をする、というものにしました。
どれも日本語の情報が少ないのと、最新版は体系的にまとまっている情報が公式ドキュメント(英語)しかなく、自分の手元に体系だったものが欲しかったからです。

2月26日:もふもふちゃん、もくもく執筆レビュー会に参加して道が開ける

2/5の勉強会で技術書典2 もくもく執筆レビュー会 ~進捗はそこにあるか~
あるかもと案内があったので、connpassのイベント公開後に申し込みをしました。
参加したときは結構行き詰まってしまっており、構想は考えたけど目次が半分と中身の文章がちょこっとくらいしかものがありませんでした。

前日に構成をバッサリ変更する

この勉強会での1番の収穫はまずは目次を書きましょう。次に文章を一気に完成させましょう というアドバイスです。

技術検証も本文も構成も…とやってしまうと支離滅裂になってしまうのと、何より先に構成を固めてしまえば中身を埋める作業になるからとのことでした。

100%同意です。

3月4日:もふもふちゃん、技術検証を始めるが沼にはまる

本文は2月中に書き終えることができたので、見直しした後で技術検証に入ることにしました。 今回はその時点で1番最新のバージョンを使って、全て1から技術検証を行いました。
しかし、Twitter連携を絡めた内容にする予定でしたが一向にうまくいきませんでした。
正直言って、1日やってダメだったら簡単なものに切り替えるべきでした。

今回はElasticsearch+Logstash+Kibanaを用いたBIチックな使い方を紹介したかったので、そこさえ守れてればネタはなんでも良いわけです。
っていうか自分がはまってたら他の人もはまるよな、ということでもっと簡単なデータを取り込むことにしました。合わせて本文も半分近く書き直しました。

徹夜とかはしなかったのですが、間に合うかどうかわからないハラハラ感は心臓によろしくないなと思いました。余裕を持った検証計画を立てましょうということですね。

3月16日:もふもふちゃん、レビューをお願いする

なんとか本文を書き上げて、Tex環境も泣きながら構築して1ビルドしたので本文をレビューしてもらいました。
本文は印刷してお渡しして、レビュー内容はGithubにissueチケットを切ってもらいました。

泣きながらTexをダウンロードする

レビューしてもらうと「自分のただのポエムではなかろうか」とかいう不安が「見てもらってるのだから大丈夫!」という自信に変わります。何より初見の人が文章を読んで分かりにくい部分に気づくことができるのでおすすめです。

レビューしてもらえる人がいなくても、自分で時間をあけて読み直してみるだけでだいぶクオリティが変わると思います。

3月19日:もふもふちゃん、入稿する

表紙は早割で入稿しました。Kibanaグラフをどうしてもカラーで見せたかったので裏表紙にグラフを組み込む荒技を使いました。
めんどくさかったとか言ってないし!
ちなみに印刷会社の人から、「黒色が表と裏違います」とか電話がかかってきてびびりました。プロはすごい。

本文はギリギリまで粘って見直しとかを行い、入稿しました。

3月31日:もふもふちゃんの手元に本が届く

今回は直接搬入ではなく、自宅に送ってもらいました。60p100冊だったので受け取ったときは腰が抜けるほど重かったです。宅急便屋さんには頭が上がりません。

4月9日:もふもふちゃん、技術書典2に参加したら商業化しようと言われてビビる

え-30の超未来工房さんブースに委託させてもらう形で頒布を行いました。

表紙は書いてある内容を文字として起こしておいたほうが中身を説明しなくてもわかってもらいやすくて親切なのかなと思いました。それかちゃんと事前に宣伝しておくかですね。

あと、もくもく執筆レビュー会でお世話になった編集の方にも本を購入いただき「商業化しませんか」と会場でお声がけいただきました。
企画は進行中なので頑張ります。多分出版は7月くらいになると思います。
正直エイプリルフールかと思ってしまいました。すみません。

まとめ

とにかく思ったのは、本を書いてよかったということです。
「エンジニアはアウトプットしましょ」とかよく言いますが、LTよりもブログとかよりも本を書くという行為が1番自分のためになると思います。

やっぱり本を読んでもらう人にきちんと伝えるためには構成も、サンプルコードも読みやすさに神経を使う必要があります。それに人に伝えようとすると自分の苦手なところを認識することができるなと思いました。

また体系だって説明することになるため、点の知識しかないのか、面として身についているのかを判断する基準にもなります。これは結構効果でかいと思います。

あと、技術書典2で「Kibana使って見たいんですけどハードルが高くて」とか「Kibana5(最新版)の情報、日本語が少ないんです」という人が多くて2 みんな同じことで悩んでるもんだと思いました。

まあとにかく、迷ってる人がいたら自分の好きな技術を伝えたい!という思いを込めて 本を書くのはとても楽しいよと言いたいです。
次があったら今度は個人で参加してみようと思います。冬コミも申し込みしてみようかな。


  1. 2日これで溶けました。Tex環境は沼が深いので、早めに構築してテストしたほうがいいです。

  2. Elastic社の人は日本語の本を出すことを考えてもいいと思います。みんな待ってるぞ!