Tsuyoshin blog

所属団体とは関係なく、個人的なblog

コードレビュー時でもgitを使ってる

まえおき

自分の中でこんな課題を最近思っておりました。

  • レビュー依頼が来て、指摘が五月雨式になってしまって起票者を混乱させてしまった
  • コメントすべき内容に抜け漏れが出てしまって、LGTM出しときながら後からコメントつけてたりして起票者に迷惑をかけた

で、どうしたか

  1. change filesの数にもよるけど、基本localにcheckoutする
  2. 気になるところはgithubのdiffを見ながらlocalのfileにコメントを残す
  3. 色々見返しながら、コメントを修正しながら、一通りみる
  4. よしこれで見終わって、言いたい事を全部localのファイルにコメントしたら
  5. git diffする
  6. 自分がレビュー後に言いたい事がdiffで出てくる
  7. その内容をgithubにコメントを一気につける
  8. そうすると一度にちゃんと言いたい事が言えた
  9. 起票者にとっても一度に色々コメントを残してくれるので作業がしやすいはず!
  10. 最後にlocalのファイルの変更は破棄する

まとめ

  • もっと効率的な良い方法あるかまだ模索したい。
  • やっぱり、せっかくレビュアーアサインしてくれたから、より良いコードになるように寄与したいから労力かけてもしょーがないかとも感じてる

PHPカンファレンス福岡 2018に参加して

去年からコミュニティ活動を再開して少しでもコミュニティに還元して行くぞ!! と決めて今年は福岡にもきました。 そこで聞いたセッションを中心にメモ、感想、レポートをまとめておこうと思います

参加したカンファレンス

phpcon.fukuoka.jp

各セッション

ログの設計してますか?PSR3とログ設計の話初級

speakerdeck.com

そうですよね。そうですよね。って聞いていました。自分としては下記が気になった。

ログローテーションの話が少し出ていました。purgeに関してもセットで考えた方がより良いなと感じました。 purgeを考える事は単純あデータのライフサイクルだけでなくて、このログはどのくらい保存が必要なのかまでを深く考える必要があり、より良い設計に繋がると思っています。

どんな情報が含まれているログなのか、個人情報等が含まれるログなのか、どのくらい過去ログを持つ必要があるのか。トータルを考えられるきっかになるかなと思いました。

Event Sourcing,CQRS For PHP Application

speakerdeck.com

本格的な分散システムですね。すごいなーという印象。 大規模が予測される時にチャンレンジするものだと思われるけど、AWSGCPだけでの実現する方法とかって無いかなーと個人的に思っています。 それぞれのプロダクトの専門性があるし、エンジニアを採用もうまく行くとは限らないし、クラウドのマネージドでってゆう方が実現可能性が高いかも?と感じました。

AWSでこうやって設計して稼働させて見た的な事例をちょっと探している...

ロリポップ!マネージドクラウドを支えるコンテナ技術 / lolipop-mc-containers

speakerdeck.com

コンテナ周辺情報はあまり詳しく無いけど CRIU はちょっと興味深かったです。

CRIU

PHPerのためのよくわかるCPU脆弱性解説 / What's Spectra for PHPers

speakerdeck.com

今年の年始に騒がせていた事件をとてもわかりやすく解説してくれたセッションでした。この脆弱性って例えばロリポップのような お客さんのコードを預かる事業者になるとより笑い事出なくて、大変だったんじゃ無いかと思った。 当然詳しい事は言えないと思うのだが、懇親会とかでペパボ(ロリポップ)の人にしれっと聞いて見たらよかったな☺️

DDoS攻撃との終わりなき戦い/endless_battle_with_ddos_attack

speakerdeck.com

ワンコインDDOS攻撃と言っているぐらい、いろんな人が少しの悪意があればできてしまう時代。ブラックホールルーティングとか初めて知りました。 データセンター側でどんな対応しているかを知れて為になりました。

全体的な感想等

やはり技術カンファレンスはいいですね。もっと勉強しなきゃとか色々良い刺激をもらえる場であり、現地に行っていろんな人と交流できるのは楽しいです!! なぜか遠くの地へ行けば行くほど、経費かかってるし、目一杯吸収して帰らなきゃって思うのが良い作用になっているのかなと思いました。

最後に

自分もLTで少し参加させてもらいました

speakerdeck.com

GitHubSatelliteTokyo 2018に参加してみて

参加させてもらったイベント

githubsatellite.com

2日間にわたって開催したイベントでしたが、下記のリンクから全てのセッションが見れます。 感じた事などをピックアップして書いておこうと思います。

day1のライブ配信

www.youtube.com

感想やら

githubの機能に関する部分

  • githubの機能を改めて追ってみると知らない機能がちょこちょこあったなと感じました。
  • 特にchecks apiは気になった。circleci対応は現在開発中とのこと
  • github上のタスクボード(projects機能)の所も前からちょっと気になってたけど個人的な課題は下記
    • 少しサービスが成長すれば、数個のリポジトリが作られる
    • チームとってのissueを解決するには複数のリポジトリが関連することが多い。(単一リポジトリだけで解決ができない)
    • projects機能でカードからissueを発行すると(もしくはカードのままでも良い)、特定のリポジトリのissueに属する事になる
      • 本来的には特定のリポジトリに生えるissueではないなーと違和感を覚える
    • issueだけを使うリポジトリを作成する
    • 結局タスク管理は別のツールを活用する
    • この辺はask the githubコーナーでもっとぶつけてみるべきだった。反省💦

LT関連

時間の関係上、会場で聞けず動画で見直しました

  • wantedlyさんのエンジニア以外のメンバーもgithubに入れてしまい、全社的に活用しているのはすごいなと感じた。
    • 一方で時たま数時間レベルで不安定になることがあるgithubの問題を全社的に影響を受けてしまうのはどうなんだろう?そのあたり何か対応されているのだろうか?聞いて見たい
  • 柴山さんまたLTされていた。イベントでよく会うw

day2のライブ配信

www.youtube.com

感想やら

  • 青山学院大学の古橋さんのgithubの活用例は現代ならではで、自分が学生だった頃を思い出すとすごい世の中だなと思った。
    • githubどうこうより、オープンにして見える化して改善をメインにする所を学生時代から体験できるって羨ましいですね
    • 学生さんの感想とか聞きたい!! twitterのアカウントとかわからないかな...
  • セゾン情報システムさんのお話は、SIerさんでも活用が広がっているのは良いですね (OSS精神的な良い部分の布教が少しでも広がる事は良い事だと思います)

最後

Ask the githubにもっと粘って行けばよかった。セッションは後日動画参照できるんだからと割り切りすればよかった...

PHPerKaigi 2018に参加メモ

はじめに

参加させてもらったカンファレンスは

phperkaigi.jp

まず最初に感動した事は運営スタッフのおもてなしでした。とても感動しました。 おかけで楽しい且つ有益な時間を過ごせたと思っております🙇🏻

聞かせてもらったセッションの中でいくつかメモをこのしておきます

トーク

PHP と SAPI と ZendEngine3 と

www.slideshare.net

PHP5~7系において内部でどのように動いているかをわかりやすく聞けて良かってです。普段気にすることが少ないのでこういった機会はありがたかったです。 自分でも内部を見てみようと思わせてもらったトークでした🙇🏻

SOLIDの原則ってどんなふうに使うの? by hidenorigoto

speakerdeck.com

ベストトーク賞にも輝いたもので何と言ってもとってもわかりやすいなーという感想があります。自分も新人の時にこんな感じで教えて欲しかったなーと思いました

その他

あとはtrack Bで行われていた各種の相談会で色々なエンジニアと話をさせてもらったのがとても良かったです。Kaigi=コミュニケーション です!というのがまさにtrack Bだったと思います。

ほとんどこちらにいた気もします😅

最後に自分のLT

speakerdeck.com

みなさまお疲れ様でした。良い刺激を頂いたカンファレンスでした。自分も精進します💪🏽

PHP勉強会でLTしてきた

勉強会

phpstudy.doorkeeper.jp

LTの資料

speakerdeck.com

今回文字にして資料に残すと捉えられ方によっては誤解が生まれてしまうなぁーと思ってたのであえて文字にはせずにLT時に口頭発表した

なので資料だけだとあまり、内容がわからないかも

このLTで一番何を伝えたかったで言うと...

ダメな実装の生みの親は自分なので、必要以上に言い訳せずに先頭にたって修正していきます!!

その時の背景や事情が必要だったりすれば正確に伝えるけど、必要以上に自分から話さないようにしている。老害っぽくなっちゃうし。

デブサミ2018を参加しての振り返り

2日間にわたって行われていたデブサミ2018に参加させてもらったのでその時のメモだったり、考えた事などを残しておこうと思います

参加したカンファレンス

event.shoeisha.jp

その中で参加させてもらったセッションは下記

リモートワークは難しい - それでもぼくらは歯をくいしばってやっていく

http://event.shoeisha.jp/devsumi/20180215/session/1631/

speakerdeck.com

思ったところ

体調不良だから自宅勤務はやめた方がいい

これは確かにそうだなと思った。体調悪いけど自宅なら小一時間であれば仕事できるのでやろうというのは自分も経験がある。

だけど、体調悪い中でやった仕事を振り返ると、真っ当な判断をしていない事が多々あった。

出社できないぐらい体調不良なら休んでしっかり直してから仕事をやるべきだなと。

体調不良とリモートワークは別問題という事をしっかり理解しないといけないですね。

リモートワークで使う道具にはお金かける

リモートでMTGするたびに画質や音質のストレスを感じながらやるのはシンドイので同意

対面 > テレビ通話 > 音声通話 > テキスト

上記のように情報量減って行く事は確かだけど、テキストにする事で一度頭の中で考えた事などが整理されたり

改めて考えて直してみたら間違いに気付けたりという効果もあるのでこの辺も考慮した使い分けが大切だなと思った

GitHubの開発フローにおけるサポートエンジニアの役割

http://event.shoeisha.jp/devsumi/20180215/session/1640/

speakerdeck.com

思ったところ

Githubの内情とかあまり聞いた事なかったので聞けて良かった

サポートエンジニアの主業務は当然顧客のサポート業務だけど、issueの3割はサポートエンジニア起票のものだったり

PRの4割近くがサポートエンジニアからのだったりと結構驚いた。

もはやサポートエンジニアの業務内容を定義し直すか、サポートエンジニア起票のissueをこなす開発エンジニアを置いても良いんじゃないかと思った。

夢は正夢〜「野球エンジニア」になるまでの歩み

http://event.shoeisha.jp/devsumi/20180215/session/1625/

speakerdeck.com

思ったところ

このセッションでは、なんか人生の変え方というような話で違った視点で楽しかった。 こういう方の話を聞くと、自身のキャリアの見直すきっかけになったり、自分の今やっている事の小ささを身にしみたり、刺激になった。

The Amazon Way~Amazonのソフトウェア開発~

http://event.shoeisha.jp/devsumi/20180215/session/1672/

思ったところ

先にプレスリリースから書く話、Two Pizza Teamの話等々はよくある話だったけど、

オンコールも含めほぼ全てTwo Pizza Teamで行うのでOps専用のチームは存在しない。と

Two Pizza Teamにできる限りの権限が与えられているが採用というところだけは、他のチームのメンバーがインタビューアに入ってもらったり

入る人材の高水準は保つように工夫している様子。

カルチャー | AWS Japan Recruitment

こういうのは定期的に更新されて外の人を含め誰もが見れるのは良い文化だなーと感じた

Empty chairとか5whysとかEveryday is still day oneとかイイっすね

さいご

そんなかんだで良いお話を聞けて良かったです。&自分もこれからもっと精進していかなければと感じれた日でした。💪🏽

PHP Way #1 勉強会に参加して自らのプロダクトでPHPを選んだ経緯を振り返る

参加した勉強会

base.connpass.com

はじめに

ようやく自分自身にエンジニアとしての精神的な余裕ができてきたのでコミュニティ活動を再開するんだ!と思ったけど

PHPでカジュアルに参加できる勉強会とか少ないなーと感じてた。

そんな中、いつものように会社でtwitterを眺めてたらこの勉強会を発見し、近いし参加させてもらいました。

本題

一応自分もスタートアップからサービスを開発をしてきました。当然最初の技術選定やらはしていて、そこでメイン言語をPHPにした経緯や当時の狙いみたいなところを振り返ってみようと思います

序章

2013年5月1日に今の所属している会社は設立され、その年の5月下旬か6月ぐらいにjoinした。

株式会社マクアケ

そこの会社で立ち上げるサービスに関して決められていたのは

  1. その年の6月中にサービスのティザーサイトをオープンさせる。
  2. その2ヵ月後ぐらいにサービスオープンさせるぞ!!😱...いけるのかぁ😰

その時いたエンジニアは私ともう一人でトータル2人。あとは業務委託として数名きてもらって一気に作るという感じだった

サービス自体は当時全く認知度が無かったクラウドファンディング。 まぁ技術的な視点でみると仕組みはEC+アルファのような感じでした

提供デバイスはとりあえずPCのブラウザ版をターゲット。のちにすぐにスマホのブラウザ版もターゲット

まぁよくあるwebですね

www.makuake.com

↑このサービスの立ち上げでした

大枠を決めた

まずはインフラはその頃からAWSが出始めてきてグループ社内でも使われ始めたのもあってAWSで良いんじゃないかという感じになりました。最初からインフラエンジニアというポジションで誰か来てもらう余裕なんて無いし

AWSはこれはこれで中々大変でしたが、今回はちょっと本題からずれるので置いておく

サーバサイドアプリケーション側のメイン言語はLL言語ってだけ決めた。webですし、何よりも改善スピードを重視したいという事もあった

会社には新規事業をどんどん立ち上げる文化がありますが、同時に決められた期間内に黒字にならないとクローズというルールがあります。 自分も実際にクローズを経験しました😨

LLの中でどれにしようか悩んだ

一応言語のその当時の印象やら評価をざっくりした

振り返り、まとめる下記のような感じだったと思います

言語 振り返りコメント
perl 今更perlで作るのもなぁー。そもそもperlで人が集まるのかなぁ。コードの書き方が色々ありすぎて統一感なくなりそう
python たぶんDjangoになるだろうなぁー。個人的にはこの組み合わせは好きだし良いけど、人材確保無理じゃない?めっちゃ苦労しそう。今でさえデータ分析系が流行っているのでpython周辺のコードをいじるエンジニアは増えているようだけど
ruby 当時2.0系に上がったぐらいでまだそこまでのスピードがない印象。でもrailsが盛り上がりつつあるのか?!
PHP 5.4 or 5.3あたりで、当時ソーシャルゲームが流行り始めて、PHPで作っていく組織が多くあった。PHPerいっぱいの印象

最終的に

結局は多くのクローズする事業を目の当たりにしてきて(当事者になるとツライです)、期限内に黒字化達成をする為に爆速で開発ができる事を最優先に考えた

そこから逆算すると自分たちのスキルセットと外部でお願いするエンジニアの確保のしやすさが重要。

自分含め2人いた創業エンジニアの今までのLL言語の経験でいうとperl,python,PHPだった。自分は直近python。もうひとりのエンジニアはPHPだった。

そうするとpython or PHP

それに外部からのエンジニアの確保のしやすさを考えると(当時だと) -> PHPですね🎉🎉🎉

フレームワーク選び

これは個人的な思考もありますが、軽量なフレームワークがいい!というのがありました。

その観点でいうと当時だとCodeIgniter

だけど、ちょうどその頃ライセンス問題が話題になっていて(のちに解決されていたのですが)、そのあたりからFuelPHPがこれから来るのではないかと信じて思い切って選択しました

その後、来たかどうかは...

まとめ1

  • 実はこの検討する時間が2、3日に考えて決めたんだよなー...
    • まぁちょっとあまりにも時間がなさすぎるというか、無理があるすぎると言うか...これがスタートアップなんでしょうかね...
  • PHPを選択した背景を4年前を思い出しながら書いたけど、4年前ってまだ20代じゃないか。色々知識が足らず未熟な選択も多分にあったと思う
  • ただ、時間は流れ、適材適所で言語を複数使いながらサービスを作り上げるのは今の主流なので今ではPHPだけではない
  • コードは常に書き換わるものなのでそういった循環のサイクルを回す事のが重要な気がしている
  • もちろんこれからもPHPも書くし、用途に合わせて別の言語も書くし、継続してアウトプットして少しでも良い情報を還元できればと思いっている

まとめ2

自分で言うのもなんですが、サービス立ち上げから無事に4年すぎ、そこそこまで立ち上がったと思うので当時の技術選択を用いてサービスの立ち上げは成功したんじゃなかろうかと思っています。🎉🎉🎉

以上、php wayを機に得た振り返り機会でした

おまけ

  • 勉強会の最後のパネルディスカッションでどういったエンジニアを採用したいかという話があった。
  • 自分も同意ですが、サービスに対してコミットしてくれて、サービスの成長・改善を第一に考えてくれるエンジニアを採用したい(もちろんプラスで技術力高い人)と。
  • でも現実問題としてサービスの成長やアクセルを踏み込むべきタイミングは待ってくれなくて、いつまでにどのくらいのエンジニアを増やして開発を加速させなきゃいけないというような時はある。理想ばかり言ってられなくなる
  • 妥協ではないけど、どこかで区切りというかラインを下げつつ事を先に進めなきゃいけないんだよなぁー。という現実とのギャップの苦しみはないですか?的な質問を懇親会でしたかったけど、ちょっと本業で急遽予定が入ってしまい、渋々先に上がってしまった