きょこみのーと

技術に関係ないほうのブログ

ISUCON8予選を突破しました!!!!!!!

k02というチームでISUCON8予選に参加し、予選を無事通過して本戦出場が確定しました。

感想と色々と良かった点や反省点をまとめようと思います。

やったこと

主にgolangの実装を改修を担当してた。

  • githubやgitまわりの設定
  • N+1の対応を何箇所か対応
  • reservationsテーブルでFOR UPDATEしてない箇所の対応
  • ORDER BY RAND() LIMIT 1してるやつをリストで取得して、golang側でシャッフルして1件選ぶ実装
  • 無駄にeventsやsheetsを取得してる箇所を修正
  • reservationsテーブルにuser_idのindexを追加
  • Adminのreportのsqlを @yasu が改善してくれてそれを組み込んだ

良かった点

  • 事前にk02用のkibelaを用意した
    • 当日の作業ログとかに埋もれてしまうpassやip、deployコマンドなどなどをslackを辿らずに調べられるようにするため
  • 横並びで全員外部モニタがある状態の会場を用意した
    • コミュニケーションコストを下げた
  • 序盤にちゃんとサービス触って理解する時間をとっていた
    • これによって途中で怪しい挙動してるときにrevertする決断が早かった
    • Lock周りの挙動がイメージしやすくなった
  • DataGripでER図をさっと作成していつでもデータの関連を見れるようにした
  • h2oはなんかパッと見そのままでも問題なさそうと @waniji が判断し、ひたすらDatabaseのチューニングに全力を注いだ
  • 流石に4回目だからか山賊してもスコア上がらないのはみんな理解してて冷静に状況判断できてたのかなと思いました
  • 去年は一発逆転でめちゃくちゃして結果Failしてたので、Failが発生しないように安定するのに注力できたのは良かった

kibe.la

f:id:kyokomi:20180918113212p:plain

反省点

  • チームの作業担当がふわっとしていて、後半までみんなウズウズしていた
  • nginxかなーと思って用意してたgoaccessとかが使えなかった
  • 自分以外がほとんどコードに手を付けられなかった(golang慣れしてて一か八かdeployを繰り返してた)
    • これは手元で動作する環境をさっさと用意しなかったのが一番の原因
  • sqlxの導入やちょっとしたリファクタリングができず終始しんどいコードを読んでた
    • これも手元で動作する環境さっさと用意すれば、悩みながらリファクタしていけて結果的にコスパ良かったと思う

以下とかもさっさとsqlx入れれば何回か実行エラーになってたタイムロスしたのを回避できたはず...

感想

今回は、飛び道具よりも愚直にSQLを改善したりindexを貼っていくのが大事な題材だったな〜と思いました。

普段仕事でやってるようなSQLをこねくり回して実行計画をみたりER図みたり、サービスの挙動としてあるべき姿をイメージしてみたいな感じでとても良かったです。

alfred-esa-workflowに検索結果から正規表現で文字列を抽出するコマンドを追加した

github.com

昔作ったこれに久しぶりに機能を追加しました。

何故作ったか?

日報に 良かったこと/悪かったこと/所感 などを毎日書いていて、2週間ごとの振り返りで漁ったりしてたんですが、いい感じに抽出したいな〜というモチベーションから機能追加しました。

使い方

※日報に記載した 悪かったこと の内容を抽出する例になってます

f:id:kyokomi:20180128175501p:plain

抽出した文字列(クリップボードにコピーされます)

## general/日報/2018/01/12/kyokomi
- ピザ食べすぎた...


## general/日報/2018/01/11/kyokomi
- とくになし


## general/日報/2018/01/10/kyokomi
- とくになし


## general/日報/2018/01/09/kyokomi
- 休み明けで体がまだなまっていて眠い... :zzz: 

....続く

設定変更方法

日報のテンプレートがウチは違うんだよな〜という方もご安心ください。

Show Alfred Preferencesを開いて、以下のRun scriptの引数を変更してください。

f:id:kyokomi:20180128180233p:plain

f:id:kyokomi:20180128175612p:plain

./alfred-esa-workflow regexp 以降の引数は、以下の内容になります。

  • ユーザ名(必須): "{query}"
  • 検索キーワード(必須): "日報"
  • 検索結果から文字列を抽出する正規表現(必須): "# 悪かったこと([\s\S]*)# 所感"
  • 抽出結果のprefixにつけた文字列: "## "

カスタマイズ

基本的に自分の振り返り用なのでいちいち引数に自分のusername設定するのめんどいという方は、こんな感じに改造すればさらに便利になります。

f:id:kyokomi:20180128180949p:plain

f:id:kyokomi:20180128181002p:plain

おわり

ちなみに制御が面倒だったので1回のGETリクエストで取得できるデフォルトの件数(20件)しか取得しないようになってます。

需要があったら改修しますのでご連絡もしくはPullRequestお待ちしてます( ^ω^)

なんとなくEthereum入門してERC20トークンをテストネットに作成するまでやった雑メモ

ちょっと調査する機会があったので、自分メモ的な感じで残しておく。

ブロックチェーンやEthereumについての概要

ざっとこの本を読んで、コマンドとか写経しながら実際にローカル環境で試してなんとなく理解した。 セキュリティ周りの事例の話とかも結構してくれて大変なんだな...というのを実感できて良かった。

ERC20トークンについてなど

ざっとインターネットで独自トークンの発行をするにはどうしたらいいんだろう?とググってたら Ethereum Advent Calendar 2017 - Qiita にたどり着いた。

とりあえず25日分をざーっと読むとみんなERC20トークン作っててなるほど〜って感じだった。

主に参考になった記事はこちら

tech.pepabo.com

qiita.com

truffleがすごい便利だった

普通にプログラミング経験者だったらこれで何も考えずにERC20トークンをつくるところまでいけそうだな〜と思った。(その後困りそうだけど)

Migrationの挙動がよくわからなかった...(T_T)

一回目のmigrateはうまくいくけど、tokenの量とか変更して二回目のmigrateするとなんかエラーになる... 理由は正直わからんかった... -resetとかすればうまくいくけど、migrateに期待してる挙動はそうじゃないので困った。(誰か知ってる人がいたら教えてください...)

./node_modules/.bin/truffle migrate --network ropsten
cricket rib insane siege quote scorpion slot seven dynamic motor innocent kind
Using network 'ropsten'.

TypeError: Cannot read property 'call' of undefined
    at /xxxxxxx/node_modules/truffle/build/cli.bundled.js:176221:50
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)

SolidityのIDEについて

Remixが一番よさそう? Remix - Solidity IDE

安定のInteliJ IDEA pluginもある様子だけど補完とかがうまいこと効かなかった... (設定かな?) Intellij-Solidity :: JetBrains Plugin Repository

go-ethereumで適当なCLIツール作ってtransactionを呼び出す

この辺を参考にした.

github.com

lotz84.hatenablog.com

コード自体はすぐにgenerateして簡単に実行できた。gasの設定をちゃんとしないと結構実行に失敗する。

GAE/Goにdeployしようとしたけど、どうやらcgoを一部利用している様子でdeployに失敗した。(残念)

github.com/ethereum/go-ethereum/crypto/secp256k1 とかだった気がする

セキュリティについてとか

必読っぽい: https://github.com/ConsenSys/smart-contract-best-practices

日本語訳がある...圧倒的感謝...!: https://github.com/sot528/smart-contract-best-practices/blob/master/README-ja.md

まとめ

なんかすごく色々な方々のお陰で参入の障壁は下がってきてるけど、セキュリティとかまともに運用してる事例がまだまだ足りてなさそう?

その辺を「やっていくぞ!」って人じゃないと本格的な参入は難しそうですね(KONAMI) という印象でした。

AnnictのAndroidアプリをKotlinでつくった

Kotlinの入門がてら作ったのですが、リリースに至るまでの流れとか利用してるライブラリとかの話しをしようかなと思います。

play.google.com

ざっくり以下の話しをしようと思います。

  • 作ったものについて
  • 開発期間について
  • Kotlinについて
  • 利用したライブラリなどについて
  • CIについて
  • タスク管理について

作ったものについて

f:id:kyokomi:20180110223121p:plain

画面はこんな感じで普通にRecylerViewでのリスト表示です。 今回は、Android Architecture ComponentsPagingLibraryを使ってかなり楽できました。(またあとで説明します)

このアプリの自分の用途について

毎クール30作品とか全部見てると時間がいくらあっても足りないので、 視聴中アニメでモチベーションが低くなってる作品のステータスを(見てる -> 一時中断 -> 視聴中止)にちゃんと更新したかった。 というモチベーションで作りました。

どのアニメ観ようかな〜とかの用途ではなく、観てる前提で自分は何を観るきなくしているのか?や自分が次に観るべきアニメはどれなんだというのを把握して確実に消化していく用途です。

ちなみに視聴時の自分ルールはこんな感じ

  • 今期で3話以上未視聴が溜まったら一時中断にする
  • 一時中断にしたものはクールの終わったときに振り返って見るかどうか?を他の人のレビューなどを参考に決める
  • ここで見ないを選択した場合は、視聴中止にする

アプリ利用の前提条件

  • Annictを結構使ってるユーザー
  • 大体今期やってるアニメを把握してる
  • Annictのチャンネル登録をちゃんと設定している
  • まとめて視聴したりせず、毎日今期アニメを消化しつづけているアニメ好き

「今期はこれだ!」みたいな1点読みとかしないで、ほぼ毎クール7割近くの作品の数話を観て徐々に観る作品を削っていく感じの人だと尚良い

開発期間について

最初に12/2くらいに開発をスタートして、最低限の機能を1日〜2日くらいで作ってちょこっとバグ直したりしてたのが12月前半。
年末までちょこちょこ触って、1/4〜1/8で一気に仕上げました。

12中旬くらいの時点でそこそこ動いてたので、わりと毎日個人的に使ってドッグフーディングできてたのは結構モチベーションにつながってよかった。 後は「やるぞ!」って気持ちと一気にやる時間があるのがやっぱり大事ですね。

f:id:kyokomi:20180110223819p:plain

f:id:kyokomi:20180110223058p:plain

f:id:kyokomi:20180110223050p:plain

Kotlinについて

Kotlinについてですが、とにかく書きやすくてコード書いてて気持ちよかったなぁ〜という感じでした。事前に以下の書籍を読んでいたので、ひとまずほとんど困らず開発できました。 ただ、もっとうまく書けたのかな〜とか思いながら書いたコードが結構あるので、今後もリファクタリングしていければと思います。

Kotlinイン・アクション

Kotlinイン・アクション

Kotlinスタートブック -新しいAndroidプログラミング

Kotlinスタートブック -新しいAndroidプログラミング

利用したライブラリなどについて

PagingLibraryについて

今回特に役立ったこちらについてもうちょっと説明。 とは言え、以下の図を見るのが一番早いw

https://developer.android.com/images/topic/libraries/architecture/paging-threading.gif 画像引用元: https://developer.android.com/topic/libraries/architecture/paging.html

今回で言うとRoom経由でSQLiteのデータがそのままRecyclerViewのリストに対応している感じになってます。 例えば、新しいデータをInsertすると参照しているRecyclerViewはハンドリングするコード等書かずにPagingLibrary内で notifyItemInserted(position) を呼び出してくれます。Deleteした場合は同様に notifyItemRemoved(position) ですね。

つまり、SQLite側のデータをどう更新するかを意識するだけでViewにはいい感じに反映してくれるという感じで最高でした。 もちろんLiveDataなので、画面回転時などにActivityが再生成されてもちゃんとobserveするコードが再度呼び出されてクラッシュするようなことも無くかなり楽でした。

ただ、かなりレールに乗ってる感はあるのでちょっとレールを外れるようなことをしようとすると、SQLiteに変なデータを突っ込んで無理やりViewHolderの処理でハンドリングして〜みたいな感じしかできなさそうな点などある程度諦めが必要かもしれません。

が、めっちゃ開発は楽になったので今後も使っていきたいと思います!

CIについて

www.bitrise.io

今回、Bitriseを初めて使いました。とにかく最高でした。 過去にWerckerやCircleCIでAndroidのbuildをしていたときに比べてやることが全然無くて、殆どがWebコンソール上で完結してとにかく最高でした。 keytoolの管理等もいつも悩まされていたのを管理してくれたりGooglePlayStoreへUploadするstepも用意されていたりなど助かりました。

CircleCIやwerckerだとたまに謎のメモリ不足?とかのbuild失敗があったのですが、それも発生しなくなった気がします。

タスク管理について

Zenhubを使ってやりました。ポイントの見積もりは結構雑だったんですが、 サクッと終わらせられる粒度にタスクを分割してたのでまあまあいい感じだった気がします。

f:id:kyokomi:20180110231734p:plain

タスクの一部を抜粋したものがこちらです。最初にばーっと10タスクつくら作って優先度決めて開発を進めていくうちにドンドンタスクを追加して、その都度優先度を変えてみたいな感じでガンガンやってました。

f:id:kyokomi:20180110231925p:plain

今後

ひとまず細かいバグ修正を優先していこうと思います。 現状AnnictのWeb側で設定する前提になっているチャンネル設定とか視聴状況の変更とかもアプリ内で出来るように〜とかも気が向いたらやるかもしれません。

バグ報告とかお気軽にお待ちしておりますので〜何卒お手柔らかに〜

2017年振り返り(技術編)

2018年を振り返るとき用にメモ書きを残すことにした。

Go

インフラまわり

  • 仕事はAWS使ってたので、この一年大体普通のWebアプリケーション作る分には、1から運用までやれる気がする
    • ただ、ecsとか自分が使い慣れてるものを使うに限る...
  • GCPはほとんど触ってない
  • FirebaseAuthは仕事で使ってたので結構ハマりどころとかわかる
    • Twitterの認証がなんか結構地雷なので辛かった
    • メールのtemplateとかも痒いところに手がとどかない感じだった
    • 昔に作ったProjectのメールtemplateを日本語に変更できないとかあったな
    • export機能がないので別のサービスに移行するのが困難
  • FirebaseAuthで痛い目にあったので、Auth0を使うようにした
    • 色々なProviderに対応してて結構いい感じだった
    • そこまで悪い点はないけど、tokyoリージョンないのでオーストラリアにしてたというくらい?
    • 将来の規模感とかちゃんと考えて、auth0使うのはありかも
    • 認証時のCallbackをjavascriptでいじったりできる機能があったのは感動した
  • terraformは、前半は結構触ってた
    • terraform最高かよって気持ち
    • 大体AWSコンソール上で手で作っていい感じだったらterraformで組んでみるという流れ
    • 大体terraform公式のドキュメントみたら分かるのでなんとかはなる
    • count周りを乱用してapplyしないとこのcountが解決できないんだけどapplyが失敗するみたいなデッドロック状態でハマったことがある
    • 最近は、自分よりガッツリterraform見れる人が現れて任せてしまってサボり気味

Android

  • 仕事でiOSアプリをちょっとつくっていた時期があって、Androidもやるかも?と思って復習してた
  • 個人アプリをkotlinで書き直したり
  • クリーンアーキテクチャ推しだったんだけど、最近はAndroid Architecture Componentsで書いてる
    • Paging Libraryとかがすごすぎるんだけど、ちょっと変わったことやろうとするとSQLiteのデータをいじらないといけなくて... う〜んってことがあった
    • RecyclerViewの最後まで行ったときに続きを取得するクルクル表示のViewとかを差し込みたいときなど
    • LiveDataで取得している箇所が、SQLiteのデータを更新したら反映されるというはマジ最高だなと思った(KONAMI
  • やっぱAndroid開発は楽しいな〜というのを思い出したり
  • 最初の会社辞めたときにAndroid開発がしたいので!って言ってたなというのを思い出した
  • 次の会社はGoが書きたいので!って言って辞めたきもする( ^ω^)
  • Kotlinが結構いい感じなので2018年もやっていきたい

Unity

  • 前半は結構触ってた
  • 2Dで放置ゲーをクライアントを作ってた(またエターなった)
  • VR周りの開発は正直数学の知識が足りなくてしんどかった
  • 普通にuGUIとかでUI組んでC#API叩くコード書いて〜みたいなのは普通に出来るレベルにはなった
  • とはいえ2Dの開発ばっかりしててもと思って、3DのSRPGを作ってたいた時期もあった(6〜7月)
  • またエターナってしまったようだな(やる気はあるんです...!)
  • 今年は触る機会あるかな〜?わからん...

iOS

  • やるぞやるぞ!!って思ってたらやることなく終わった
  • 縁が無い

Kotlin

  • 12月くらいからServerSideKotlin書き始めた
  • とりあえずSpringBootで入門中(まあなんでもいい)
  • herokuでもいいんだけどGAEが好きなのでGAE/Kotlinで動かしながら色々触ってるレベル
    • なんかよくわかってないけど、GAE/Kotlinやってる人がググってもあまり情報でてこないので適当にblogに書いていくつもり
    • HelloWorldまでして終わってる人は沢山みた

個人タスク管理

  • Trello -> Asana -> Zenhubという激しい入れわかりだった
  • 一旦zenhubで落ち着いている
  • 欠点をあげるとprivateのtaskを管理しているので、Githubの草が無駄に増えてしまう点(githubとシームレスにという利点でもあるのだが)
  • 個人の生産性をバーンダウンチャートで可視化できるのは結構良い
  • ちなみに先月はこんな感じ f:id:kyokomi:20180104232219p:plain
  • iceboxに1ヶ月以上先にやりそうなタスクをいれる、backlogに今月やる予定のものを雰囲気でポイント見積もりしていれる
    • 読書とか個人開発とか
    • 読書はぶ厚めの本の場合(1日で読めないもの)は章単位でタスクに分割したりしてる(こんな感じ) f:id:kyokomi:20180104232516p:plain
    • 〜を買うみたいな買い物系とか一瞬終わる系はtodoistで管理している(個人生産性という観点でいれるようにしている)
  • boradの機能とepicという概念が今のところ重要
  • githubの上に乗っかってるのデータの持ち方やもっさりしてるところはデメリットではある
  • 最強のタスク管理ツールは未だに探してる...

最強のメモ帳

  • 最強のMarkdownツールが沢山合った記憶...
  • 結局Evernoteを廃止してinkdropに落ち着いている
  • 月額払うのを決めた(11月くらい?)。そろそろ年間契約にしてもいいかもしれない
  • まあEvernoteでも良かったんだけどやっぱMarkfownで書きたいという欲が強がね...
  • あとEvernoteで長文書くとめっちゃもっさりしてた時期があってストレスだった
  • Inkdropは作者がすごいスピードでレスくれたりバリバリ開発してくれてるので枯れるまでは使い続けそう(枯れたらどうなん...というのはわからない)

2017年を振り返る

今年もTwitterを遡って振り返ってる。そのため、いろいろなイベントを取りこぼしてるはず。

1月〜5月

  • ひたすらcluster.のロンチに向けて仕事してた気がする
  • 5月にロンチしたが、初回のイベント人多すぎて爆死した panora.tokyo

6〜7月

8月

9月

10月〜11月

12月

アニメ

  • 劇場版なのはさんを観た:
    • 観てる時にあれ、これ収集つくのか?とか思ってたら2部構成だったときの顔してた
  • 劇場版プリヤを観た:
    • 思ってた以上にプリズマシロウだったけど良かった
  • 劇場版Fate/stay night[Heaven's Feel]を観た:
    • ひたすら最高だった。原作またプレイしたくなったけど我慢する

ゲーム(クリアしたもののみ)

まとめ

  • 毎年、国士無双和了してる気がするので来年も実績解除するぞ
  • 個人Webサービスは結局作れなかった...個人開発のゲームもロンチできなかった...
  • Goは結構相変わらず書いてた
  • ドメイン知識以外のところで迷わなくなって開発速度Upを感じた
  • Kotlinを一応覚えた。書いてて結構気持ち良いので来年もやっていく
  • 仕事とのバランスをうまく保ててるようでバランス悪かったような気がした(メリハリがイマイチだったような?)
  • 仕事で必要なスキルや知識が技術面よりも組織とか開発体制みたいなところに寄ってる気がしてなんかモヤモヤ
  • 技術のステ振りとか何やっていくかとか今後何やりたいのかとかちゃんと考えていかないとな〜と思った

毎週テキサス・ホールデムをやってエンジニア力を鍛える弊社の紹介

これはCluster,Inc. Advent Calendar 2017の第10日目の記事です。

弊社の会社紹介しようかなと思います。 弊社VRの会社なんですが、社内では毎週テキサス・ホールデムのポーカーをやっています。(全然VR関係ないです 😇)

IVSのピッチコンテストLaunch Padというイベントで優勝して 本当に叶うAmazonウィッシュリスト というのがAmazonさんより贈呈されて、僕がポーカーやりたいなーと思ってポーカーテーブルをいれたらめっちゃ社内で流行って大満足という感じです 😄

他にもボドゲがいっぱい

これがIVSのイベントの記事です

jp.techcrunch.com

テキサス・ホールデムとは?

テキサス・ホールデム(Texas hold 'em)はポーカーの一種。各プレイヤーごとに配られる2枚の手札と、コミュニティ・カードと呼ばれる全プレイヤー共通のカード(最大5枚)を組み合わせてプレーする。アメリカ合衆国のカジノにおいては最もポピュラーなゲームのひとつである。通常は2人から10人で行われる。

Wikipediaより引用

社内の様子など

f:id:kyokomi:20171130030307j:plainf:id:kyokomi:20171208180933j:plain

  • 大体週1で開催されてる(毎週木曜の20:00くらいから23:00くらいまでやってる)
  • 前職でお世話になった@axrossさんが外部講師(?)として時々きてくれる(結構頻度高)
  • 社外の人も口コミというか、社員の友人的な感じで参加して結構ワイワイやってる
  • ポーカーは論理や確率に基づいたプレイが大事で、ポーカーが上手い人はエンジニアとしての仕事の進め方とか判断力を鍛えられている気がする(そんな気がする)
  • 主に上達目的でリングゲームをやっているがたまに気分転換にトーナメントをやったりしてる
  • ポーカー道あたりで用語を抑えたあとにフィル・ゴードン本(緑)を買って読むメンバーが結構多い(そろそろ会社の本棚に置いてもいいのでは感)あとはひたすら遊んでる
  • 社員13人中9人くらいポーカーやっててVRの会社のはずなんだけど、ポーカーの会社みたいになってる現状

フィル・ゴードンのポーカー攻略法 入門編 カジノブックシリーズ

フィル・ゴードンのポーカー攻略法 入門編 カジノブックシリーズ

弊社でポーカーで遊びたーいという方がいたら気軽にお声がけください!