生涯未熟

プログラミングをちょこちょこと。

buildersconに初参加してきたぞ!

というわけで、以前から気になっていたbuildersconに行ってきました。

どんなイベント?

builderscon.io

buildersconではトークに関して技術的な制約はありません。
特定のプログラミング言語や技術スタックによるくくりも設けません。
必要なのは技術者達に刺激を与えワクワクさせてくれるアイデアのみです。

という、何でもありの技術イベントですね。
開催前にCFPが募集され、運営様によって厳正に審査された選りすぐりの技術セッションが楽しめます!

会場は日吉にある慶應義塾大学です。
何気に今回初めて日吉に行きました・・・

こちらメインホール2Fからの素晴らしい眺め👀

f:id:syossan:20180907141651j:plain:w600

どうだったか?

詳しいセッションの感想などは社のブログに書くとして、builderscon全体のザクッとした感想をつらつら書いていきます。

運営様の素晴らしさ

どのカンファレンスも素晴らしい運営様によって支えられていますが、ご多分に漏れずbuildersconの運営様も素晴らしかったです!
今回の初参加にあたってチケット周りとか「あれ?これどうしたらいいんだろ?」って困ることが特に無かったくらい、運営様からのお知らせが公式Twitterアカウント等でされていました。
また、一点分からなかったところがあったのでTwitterで聞いてみたところ即レスポンスが返ってきたのは本当にありがたかったです!

また、途中腕時計を落としたのですがすぐにTwitterでアナウンスされており、それを見て取りに行くという一コマもありました。
ありがたやありがたや・・・🙇

天然のうまい棒

行った人は分かると思うのですが、参加者にはjollyjoesterさんからの天然のうまい棒が振る舞われました。

戦利品の天然のうまい棒(サラダ味・たこ焼き味)

f:id:syossan:20180908001331j:plain:w300

そしてjollyjoesterさんの後継者がいたので、お写真撮らせて頂きました。

f:id:syossan:20180907160426j:plain:w300

大学近くのお食事処

慶應義塾大学があるということで、近くにはお昼ご飯を食べるところが盛り沢山にあります。
最初はランチセッションを狙っていたのですが、人大杉状態でランチが売り切れてしまい泣く泣くお昼を求めに行きました。

近くに「普通部通り」というところがあり、ここには松屋などの有名チェーン店から多種多様な個人店がありました。
どこに行くか迷っていたのですが、「エンジニアなら寿司だろ!」というわけで幸甚寿司さんでお昼を食べることに。

関連ランキング:寿司 | 日吉駅

f:id:syossan:20180907115607j:plain:w300

あと、ご飯食べてると有名エンジニアたちが続々と集まってきて、皆さんビールを頼んでたのが印象的でした・・・🍺

満員スピード

ちょっと残念だったなー、と思ったのが各セッションで満員になるスピードがめちゃくちゃ早かったところですね。
セッション聞き終わって「次のセッション行くかー」と向かったら既に満員になってたり・・・
これはさすがに仕方ないな、とは思うのですが来年はもっと広い会場で開催されることを祈っております!

まとめ

そんなこんなで、色々あったのですが控えめに言って最高でした
懇親会やアフターパーティーに参加できなかったのは残念ですが、来年こそは参加するぞ!
というわけで、2日目も全力で楽しみます!

kafka2.0にした時にShopify/saramaでCRCエラーが出る件

皆さん、Goでkafkaやっとりますか?僕はバリバリ伝説な感じでバリバリやっとります。
というわけで、最近kafka2.0がリリースされましたね。
うちでも使うかと2.0にアップグレードしたんですが、見事にsaramaを使ったGo製のProducer/Consumerが死にました、南無。

突然の死

メッセージ受け取った瞬間、こんな感じで死にました。

2999-19-05T10:39:05.798+0900    error    Failed receive message    {"error": "kafka: error while consuming hoge/0: kafka: error decoding packet: CRC didn't match expected 0x0 got 0xe38a6876"}

あじゃぱ〜。
こりゃ2.0の速にsaramaがついていっておらんなとISSUEを掘りにいきました。

イッシュー

github.com

そうそうこれこれ。
wladhさんが見てくれて解説してくれてますね。

で、問題解決PRがこれ。

github.com

斜め読みするとkafka2.0から導入されたメッセージチャンクのダウンコンバートのせいでオフセットがズレてデコードエラーになったっぽいですね、知らんけど。

メッセージチャンクについてはこの辺の記事が関連。

KIP-283: Efficient Memory Usage for Down-Conversion - Apache Kafka - Apache Software Foundation

解決

なので、とりあえずこのPRを適応すれば動くようになります。
今の所、最新のmaster branchには突っ込まれているので適宜追従しておきましょう。

「Docker/Kubernetes 実践コンテナ開発入門」はコンテナ初心者に最高の本だった

今回ありがたくも初心者枠として「Docker/Kubernetes 実践コンテナ開発入門」のレビューをさせて頂きました!
著者のstormcat24さん、このような素晴らしい書籍に関わらせて頂きありがとうございます🙇

というわけで、本書をご恵贈頂きましたので初心者目線での感想を・・・

どんな本なの?

端的に言うと「知識0から本番環境でコンテナ運用出来るレベルまで引っ張ってくれる」という初心者にとっては神のような本です。

Dockerの歴史などの基礎知識から始まり、Dockerコンテナの操作の仕方、Docker Composeでの複数コンテナの協調動作。
Docker Swarmを使ったアプリケーションの構築、そして皆大好きKubernetesへ・・・ etc...
といった、なかなかボリューミーな構成なのですが、読者のwhyに関してとても丁寧な説明がされており、ボリュームを感じさせないほどスラスラと読むことが出来ました。

あと、とても多くの筆者のコラムが載っており、これがまた非常に良かったです。
初心者の方は是非全て読んで、本筋の知識+αを身に着けるといいかも。
個人的には「Dockerフレンドリなプロダクトばかりじゃない」のコラムをオススメしたいです。
このコラムの内容は是非、君の目で確かめてくれ!

嬉しかったところ

1つ目は、実際にサンプルアプリケーションをコンテナで構築していくスタイルだった、というところです。
文章のみの説明だと「りろんはしってる」状態になって、現場での活かし方があまり分からないという状況になってしまいがちですが、実践的な例をガンガン手を動かして構築していく進行なので、覚えたことを実戦投入しやすく感じました。

2つ目は、会社でコンテナ化を推進しているところなのですがオンプレミスということもあり、「EKSやGKEのようにポイッとk8s対応するのは難しいかなー」と思っていました。
しかし、本書でkubesprayを使ったオンプレミスでのk8sクラスタの構築方法も解説されていて「あっ、オンプレミスでも全然イケるんだ」と気付きになりました。この辺はあまりインターネット上に出てこないような情報だったので、とてもありがたかったです。

コンテナやっていこうな

コンテナ界隈は進化のスピードが早く、この本の内容ももしかしたら1年後には殆どの内容が陳腐化する、という状況も起こるかもしれません。
しかし今読むことで「現在における最新のコンテナ知識」を手に入れ、今後のコンテナ界隈を追従出来るという"楔"を打ち込むことが出来ます。
なので、「DockerとかKubernetsとかよく分からんから勉強するのは後でいいや」とか「インターネット上で色んな情報がアウトプットされていてどう学べばいいか分からない・・・」という人は是非本書で一歩ずつ正しいコンテナ知識を身に着けてみましょう!!

皆、コンテナやっていこうな!

さいごに

著者のstormcat24さんが「本書の裏テーマは、「この本を読めばAbemaTVや筆者の担当するFRESH LIVEやでやっていけるようになる」です。」と仰っていたように、実際の現場で使える知識が満載の本で、控えめに言っても最高でした!
「この本を片手に会社のコンテナ化をどんどん進めていくぞ!」という気持ちにもなれました。

あと、同じくレビューをやっていらっしゃったmponさんの感想が物凄く詳細に書かれていて凄いので、ここまで読んでくださった方は是非読んでみてください!

www.mpon.me

Sparkにおける不正なCSV読み込みへの立ち向かい方

Apache Sparkを使い、あるデータをHDFSCSVとして保存し、保存したCSVから読み込んだデータをDBに格納するということを想定して、もし不正なCSVファイルが紛れ込んでいたらどうする?ということを考えていく。

状況

この疑問が生じた発端となった不正なCSVを見ていきたい。

"商品A","この商品は
素晴らしい商品
です","使ってみたけど
確かに素晴らしかった
です!"
"商品B","この商品は
\"駄目\"
です","使ってみたけど
確かに\"駄目\"
でした!"

このような形の商品名・説明・レビューで構成されているMultiLine CSVである。
これはどのように不正かというと、2つ目のレコードの \" が災いして以下のように崩れてしまうのである。

f:id:syossan:20180811020435p:plain

このような不正なCSVをSparkのDataFrameに乗せて処理をしてしまうと、愚直に崩れた状態で読み込んでしまうので様々な問題を引き起こしてしまう。

どう立ち向かうか?

FASTFAIL

SparkでのCSV読み込み時にはoptionを設定することが出来るが、 FAILFAST Mode で動くようにoption設定するのが一つの方法だ。
Modeには3種類あり、

  • PERMISSIVE(default): 全ての行を走査する。欠落したセルにはnullを入れ、余分なセルは無視という挙動を行う
  • DROPMALFORMED: 想定より少ないセル数の行の削除、またスキーマと一致しないセル内容の削除を行う
  • FAILFAST: 不正行が見つかった場合にRuntimeExceptionを返す

という内容になっている。

FAILFAST Modeで動かしておき、もしRuntimeExceptionが発生した場合はCSVの確認を行う、という方法もひとつ。

escape + quote options

しかし、上記の方法では読み込み時に不正なCSVを検知するだけなのであまり意味がない。
そこで、 escape optionと quote optionを使って正しいCSVファイルに直すという方法がある。

この問題のCSVが何故不正なのか?といった点を掘り下げていくと、ダブルクオーテーションをエスケープするにはダブルクオーテーションを使わなくてはいけないという仕様がRFCに記載されており、 \" を使ったCSVは本来 "" というCSVになるのが正しい形である。

RFC 4180 - Common Format and MIME Type for Comma-Separated Values (CSV) Files

If double-quotes are used to enclose fields, then a double-quote appearing inside a field must be escaped by preceding it with another double quote

そこで、CSVの書き込み時と読み込み時に escapequote のoptionを仕様に合わせた形に設定していきたい。

一例として以下のようにやってみる。

  • CSV書き込み
df.write
    .options(
        Map(
            "escape" -> "\"",
            "quote" -> "\""
        )
    )
    .mode(SaveMode.Append)
    .csv("hdfs://hoge:8082")
  • CSV読み込み
spark.read
    .format("org.apache.spark.csv")
    .options(Map(
        "escape" -> "\"",
        "quote" -> "\"",
        "multiLine" -> "true"
    ))
    .schema(schema)
    .csv(
        "hdfs://hoge:8082/*.csv"
    )

このような感じで書き込み時と読み込み時に適切な形になるようオプションで明示的に指定してあげると上手く動きます。
SparkでCSVを扱う際にはくれぐれも気を付けましょう。

ランサーズ開発ランチにお邪魔してきた!

f:id:syossan:20180711115427j:plain

クラウドソーシングで超有名なランサーズさんが、開発ランチという面白いイベントをやっていたのでカツ丼食べたくてブログ枠として参加してまいりました!!

lancers-engineer.connpass.com

ランサーズ開発ランチ(Lunchers)について

このイベントはランサーズさんが開催している勉強会で、一ヶ月に1~2回というスパンで開かれております。
はてなのa_knowさんやオミカレのそーだいさんなど、著名な方々がゲストで招かれている素晴らしい勉強会です!

engineer.blog.lancers.jp

ブログ枠だと最高に美味しいトンカツが食べれるので皆さん参加しましょう!!!!

f:id:syossan:20180711120000j:plain

kakakakakkuさんによるお話

今回のランサーズ開発ランチのゲストは、

kakakakakku.hatenablog.com

の記事で1000ブクマを超える反響を呼んだkakakakakkuさんによる「プロジェクトの成功を支える ZenHub と モブプログラミング」でした!

僭越ながら、お話を聞いて個人的に「オッ」と思ったところを書き出していきます。

f:id:syossan:20180711120853j:plain

Backlogsにあるタスクにメンバーを割り当てない

手の空いた人が優先順位の高いタスクからサッと着手出来るように、Backlogsのタスクにメンバーは割り当てないようにする。
スキルがミスマッチの場合でも、時間がかかってもいいので着手するようにする。

スキルがミスマッチの場合でも〜、というのが個人的には刺さりました。
マネージャーが機能している場合、プロジェクトを円滑に終わらせるためにも事前にメンバーのスキルセットに合ったタスクの割り振りをやってしまいがちです。
しかし、それではメンバーのスキルセットの質や幅がいつまで経っても向上しないままなので、タスクにかかる時間を多少目を瞑ってもやらせる、ということなのでしょう。

途中、kakakakakkuさんが「サービス自体には興味がない。プロジェクトの達成とメンバーの成長に興味がある。」と仰っていたことを含んで考えると、感慨深いものがあります。

優先度警察

kakakakakkuさんが受け持つプロジェクトでは「優先度」という言葉は禁句らしいです。
というのも、「優先度」ではなく「優先順位」という言葉を使って欲しい、という気持ちから。

優先度だとありきたりな「高・中・低」で分けられてしまいます。
しかし、優先順位だと明確に「1, 2 3」とやるべきことの順番を決めることができます。
例えば、Aさんがタスクを取ろうとBacklogsを見た時に、優先度・高と優先度・高のタスクが同時に存在した場合にどちらを先にやるか悩んでしまいますよね。
そういったことが無いように、優先順位の一番高いものから着手できるよう「優先順位」という考え方を大事にしているとのことです。

質問タイム:前半

  • ZenHubはどこがオススメポイント? → 画面の見やすさ、Githubに紐付いた機能、Epic機能
  • Epicに紐付いた仕様はどう管理しているの? → 仕様書をGoogleドライブで管理してEpicにリンクを貼る
  • 優先順位がビジネスに左右される場合は? → 基本左右されないようにする。Doingに入ったものは変えない。Backlogs内だとバンバン変える。
  • Reviewingからなかなか進まない場合は? → 口頭・対面でレビュー進めるように言う(Doingより優先してやって!など)。WIP制限がReviewingを進めるという効果もある。1~3日の粒度のタスクなのでPRレビューもそんなにかからないはず。
  • ラベルの付け方は? → 全体、仕様、フロント、バック(Ruby etc)、デザイン etc...。スキルマップと照らし合わせて、ラベルを分ける。
  • 今後必要なんだけど今できないみたいなタスクは(技術検証とか)? → Backlogsに積んでおくといい。やるんだったら3日で終わるように調整する。
  • Reviewingの数は制限あるの? → ない。レビューが詰まるようならやる価値はある。

スウォーミングの考え方

タスクとメンバーの関係性を1:1から1:nと考える。
あるタスクに異様に時間がかかっている状況が発生した場合、手が空いたメンバーがそのタスクに関わるようにする。
その考え方の延長線上にあるものが「モブプログラミング」である。
スキルセット関係なく関わるようにすることで、個々のメンバーの強みが他のメンバーの強みとなっていく→強みの伝搬。

モブリリース

今回のお話の中で、この考え方が凄い良いなぁ〜と聞いておりました。
どういうものかというと、属人化しやすいリリース作業をモブプログラミングのように皆の前で行うことで、リリース作業の理解を広めるというもの。
手順書を作り、それを見ながらリリースするという方法もあるのですが、それよりもリリースのプロセスを可視化された状態で見て学んだ方がいいとのこと。
実際に人がやっている手順を見ることで、自分がやる時に安心して出来ますし、その場で「何故それをするのか?」といった質問も出来ますし、良い取り組みですよね。

質問タイム:後半

  • あるタスクが困窮していて、皆で助けにいった際にタスク全体のスケジュールが遅れる場合はどうする? → スケジュールを伸ばす。ビジネス側に文句を言われても無視する。
  • モブプログラミング開催の周期は? → 毎日やってるところもあるが、kakakakakkuさんのところは週1回。教育・息抜きのイベントのような扱い。モブリリースは頻繁にやっている。スキルマップと照らし合わせて、スキル的に難がある人が多い場合は、慣れてきたプロジェクト後半にモブプロを開始する場合もある。

まとめ

プロジェクトマネージャーという職を経験したことのない未熟な私にとっては、非常にタメになるお話の連続でめちゃくちゃ勉強になりました!
今回のお話の中で得た知識を、少しでも現場で活かせることが出来るよう頑張ります・・・!

ランサーズ開発ランチでは今後もドンドン魅力的なゲストを呼んで開催されるとのことなので、界隈の最先端にいる方のお話を聞きたい方は是非チェックしましょう!!