会社としては、
という属性です。
入社してすぐの頃はバグが頻発していて、全体的に慌ただしい状況でした。この問題はずっと引きずっていて、当時に比べればかなりマシになってきているものの、まだ収束していません。入って一ヶ月ぐらいの頃に、社内会議で「全然テストしてないですよね?」という発言をした記憶があります。
原因としては、
といった要因でした。
サービス停止につながる致命的なバグもありました。春先にかけて、ユーザー数の多い企業が利用開始となり、利用者が増える月末にサービス停止が多発しました。主な原因としては、DB負荷です。参照系のAPIに関してはおよそ一ヶ月ほどで収束しました。平均レスポンスタイムは600-670ms程度から、5月以降から現在までは120-150ms程度で推移しています。更新系はまだ遅い場合があるものの、対処できてません。
10個以上のテーブルがjoinされている箇所がありました。preload
にして大体解決しました。
これもpreload
にして大体解決しました。
どちらにせよ、データ数が少ない状態でしかテストしておらず、100件程度のデータを入れればすぐにわかるような問題がずっと放置されていました。
あればあるだけデータを表示してしまう一覧画面がいくつかあり、1000件のデータが表示されるまで1分近く待つような状況もありました。致命的なところはページネーションするようにして解決しました。
あるテーブルのidをpluck
して、それを後続のSQLに渡していた箇所があり、それがスロークエリーを引き起こしていました。さらにスロークエリーのログに、そのSQLのwhere句にある長いidリストが大量に書き込まれてしまい、ログファイルを保管していたサーバーのディスク容量が圧迫され、停止するというのもありました。
pluck
からselect
に変えて、SQLを1つにまとめたあとはほとんどが普通のスロークエリーだったので、NewRelicでレスポンスの遅いAPIを見つけてチューニングしていきました。必要なindexが無かったもの・非効率なSQLなど、この辺はセオリー通りの対応です。
月末の利用者が多いというサービス特性があるにも関わらず、実質的に月末ちゃんと動かないサービスを提供してお金をもらうのは詐欺に近いものがあるなと思いました。対応が後手回ってしまっていたのも、手が回っていなかった事以上に、チームの作業限界を大幅に超過していた事に気が付かなかったのが根本的なヤバさかなと思いました。後述するPM不在のデメリットがもろに出ていたように思います。
どのレベルでもマネージメント能力のある人が一人もいません。それを象徴するような愚痴を聞くこともあります。そういった現状に課題を感じた開発メンバーが主体となり、秋ごろからはPMBOK勉強会が始まりました。
自分も一応参加してみて、基本的な知識が全くない状態で仕事をしている人が多いという事実が分かりました。自分の場合はSIer出身なので、上流から下流まで、多少なりとも開発に関わることは勉強したり、仕事で一通り使う機会があったためその基礎はあったと思っていますが、このあたりの知識の欠如が発覚してこれが仕事の仕方にも大きく影響しているように思いました。
一番ヤバいのは、炎上しているのにそれに気づける環境にないという事です。
以前にも、1on1ミーティングでこの辺りの必要性は話をしてみたものの、あまり理解されているようには思えません。スキル・知識がないことを非難するつもりは全くなくて、毎月5-10時間程度の勉強時間を確保すれば、より円滑な仕事ができるのに、そうしない・できない理由はなんなんだろうかというのが自分の問題意識です。
という可能性なのかなと思っていますが。日本人の場合、社会人になると本を読まない・勉強しないというのはすでによく知られた話のようで、2018年はそういった記事をちょくちょく見かけました。
入社以前から、朝会をやっていて、
をチームで共有しています。しかし、各自のタスクはその人自身しか把握していないため、先週言っていたタスクが終わっていないなど、進行中のタスクが多くなる状況が発生しています。
主にPRの指摘・修正が繰り返し発生している状態で、別の割り込みタスクが発生し、・・・というのが原因でした。カンバンの本を読むと、どこかのタイミングで作業調整をして、進行中のタスクを終わらせるというのが一般的な話のようです。
という話をしてみたものの、ユーザーからの問い合わせに対して、当日中に一次回答するという目標もあり、なかなか完遂するのは難しい状況です。
よく聞くプルリクエストがたまる問題も発生しました。各自が優先事項をもってタスクに取り組んでいますが、チームとしての優先事項が見えてないと、完了するPRが増えないという話です。開発者同士でレビューしているので、レビュワーも同様に開発タスクを持っていて、自身のタスクとレビューとどちらを優先するべきなのか、判断をつけられなくなっていました。
現状としては、自分が専任レビュワーになっているような状況です。一日中レビューしているので、全くPRがマージされないという状況はかなり減りましたが、それでも複数人からPRが来るので、変更点の多いPRだとなかなかレビューが進まないという課題が残っています。
秋ごろからは、Rails5へのバージョンアップも見据えて、自動テストを増やすべく、毎週木曜日がテストの日になりました。テストで有名な業界人である「らいおんさん」の写真を私がslackに貼りつつ、各自が「今日はxxのテストを書きます」と宣言してテストを書いていくスタイルです。
レビューをしていて、RSpecの使い方が分からないという人が多数だったため、esaにガイドラインを書きつつ啓蒙していきました。現在は主に2種類の自動テストを書いています。e2eテストは未着手なので、system spec/feature specはまだ対応できていません。
取り組みを始めて1ヶ月ほどで、メンバーの書くテストコードが劇的に良くなったと実感しています。木曜日という練習時間を確保したことで、テストコードを書くハードルが下がり、各自の案件のPRでもテストコードをちゃんと書けるようになりました。また、バグのあるコードを書いていても、しっかりテストが失敗したという状態になってきました。
サービス上、重要なクラスに対しての自動テストを増やすのが目的なので、個人的にはカバレッジxx%という目標はあまり意味があるとは思っていませんが、開発チームの目標としてはまだ30%台という状況です。
画面遷移を伴うシナリオテストなど、実際に手を動かして実施するテストも依然として必要ではあります。テストケースをどう記述するかで迷っている部分はありますが、あまりガッチリした操作・期待値を書くとメンテ辛そうという気がしています。テストケースをmdファイルに書いて、githubで見ながらテストできるといいかなと思ってます。
みたいな感じで。実際には不正データの場合にちゃんとエラーメッセージが出てくるかどうかとか、もうちょっと細かいことを書いていくと思います。
上で書いているように、直近の課題はスキルの底上げです。過去の失敗から反省すべきこと・これから達成したいことに対して、レベルと装備が足りていないという状況だからです。レビューの時間を増やしたのもその一環で、設計がまずいコードをどう改善するか理解してもらうという意図もありますし、テストの書き方を社内ドキュメントに書いたのもそういう目的です。
時間を確保して実際に行動するというのが大事なところで、テストに関しては実際に業務時間を割り当ててメンバーにやってもらったら意外なほど上手になったわけですし、スキルの習得に関して不得意なわけでもなく、やったらやった分効果が出てくるのかなと思っているところです。
自分が先頭に立ってやっている部分が大きいので、業務時間にコードを書く時間が全然なくなったという現実もあります。あと何ヶ月続けるんだろうかと考えると、この点に関しては不満ですね。正直な事を言えば、各自で「練習時間」を増やして欲しいですし。早く帰ってその時間を確保して欲しいですが、残業している人がかなり多く、組織としては残業しても全く構わないという方針なので、そう簡単に変わらないだろうなという諦めもあります。間違った方向に時間を使って失敗してきたように見えるので、どうなのかなと思っていますが。とはいえ、実業務で使っている技術にキャッチアップできていない状況を放置しても、大して良い事がないのは前職で経験しています。つまりこの辺りが現在のチームの最大速度になります。
現職まで1年半近く仕事をしてなかったため、入社してからはRailsの使い方を思い出すとか、昔読んだ技術書を読み返すとか、新しい事を覚えるのにあまり時間を使えなかったので、今年は少しずつ時間を取っていきたいです。
]]>元画像が別ファイルとして残っているので、ロスレスである必要もないし、ファイルサイズを抑えられる別のオプティマイザーを使う。
このタスクを実行すると、モバイル向けに小さめサイズの画像を生成できる。
一度最適化した画像は何度も最適化する必要はないし、最適化が完了した画像はS3などに保存しておいて、必要な時に取りに行く方がgulpの実行時間が減らせると思う。と考えると、defaultタスクからはimagesタスクを外しておいて、画像を追加した時だけimagesタスクを実行し、S3に保存するというのが良さそう。
S3に画像をアップロードすると、AWS Lambdaで画像を最適化して、S3に保存してくれる、というのが一番いい方法かもしれない。その場合、どのくらいのファイルサイズになるか、最適化オプションを調整したい時にはこのタスクが役に立つと思う。
]]>アマゾンのコメント欄を見ると、日本の筋トレ業界ではiHerbが人気らしい。
ベトナムで生活するようになってから、体調が非常に悪くなったこともあり、2年前から適度な有酸素運動を、1年半前から自重トレーニングを始め、今年7月に日本に帰国してからジムに通ってウェイトトレーニングを始めた。9月の記録を見返すと太ももが5cm以上太くなっている。2016年4月からは食事を全て見直して、体調は劇的に改善した。現在のBIG3の1rep maxはこの通り。
さて。日本で必要なサプリメントを買おうとすると、そもそも売ってないか、非常に値段が高い。筋トレといえばアメリカ。サプリメント大国なので、手頃な値段で筋トレ用サプリメントが販売されている。
bodybuilding.comでは海外シッピングにも対応しているのだが、送料が高い。重量や配送日数にもよるが、ちょっと重いものになると¥2,000以上はかかる。しかし、軽い商品であれば¥400程度に送料を抑えることができる(円安になってきたので、現時点では¥448になっている)。
具体的には、400gまでの商品を注文すると一番安い価格帯の送料が適用されるようだ。
プロテインやアミノ酸などのサプリメントを混ぜるのに欠かせないのがシェーカー。有名ブランドBlenderBottleの中で最大サイズのBlenderBottle Pro45をカートに入れてみた。
送料は¥448となっている。
Optimum Nutritionのクレアチン 300gをカートに入れてみた。
これも送料は¥448だった。
CellucorのAlpha Amino 30 servingsをカートに入れてみた。一杯で12.7gなので、重量は381gである。
送料は¥448。
PrimaForceのGlutaForm 400gをカートに入れてみた。
送料¥448。
Gaspari NutritionのAMINOLAST 420gをカートに入れてみた。
送料は¥1,804となった。
結果としては、400g以下の商品であればSuperSaverの送料を¥448に抑えることができることが分かった。アミノラストがギリギリアウトなのが悔しい。
Super Saverで注文すると、安い代わりに配送日数がかかる。何度か注文した結果、7-21日程度で配送された。届かなかったことは今のところ一度もない。クリスマスシーズンのせいか、PriorityとEconomyが異常に高い。
]]>gulpからlibsassを使うの記事に書いたのと同じタスクを使う。cssを書き出した後にbrowserSync.stream()
を入れておく。
{port: 9001}
にすると9001番ポートで設定用画面にアクセスできる。説明書によると、package.jsonに"scripts"フィールドを設定しておくと、npm run gulp
でnode_modules/.bin/gulpを実行できるようになる。
これで、npm run gulp serve
としておくと、勝手にコンパイル+自動リロードができるようになった。
npm install
だった。
npm update
すると、全パッケージが最新版に更新される(package.jsonで指定されているsemverでの最新版の事)npm update pkg
すると、指定したパッケージが最新版に更新されるnpm update
、npm update pkg
で更新するか、npm install pkg@version
で更新する。特殊な事情でsemverを変えたくない場合にnpm install
することになるんだと思う。
npmのバージョン。
npm install
サーバーにnpm-shrinkwrap.jsonを配付した後に実行するのは、npm install
である。npm update
すると、npm-shrinkwrap.jsonを無視して全パッケージを更新することになる。ここでは、別ディレクトリにnpm-shrinkwrap.jsonをコピーして試してみる。
npm update
するとバージョンを上げていないjqueryの最新版3.1.1がインストールされてしまった。元に戻す場合には、もう一度npm install
する。