nakamura244 blog

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

golangのxoを導入を決めてファイルの運用方法がいい感じになってきたので書いておく

はじめに

最近はgolangでアプリケーションを書いていてmodel周りにはxoというtoolを使ってmodelファイルを自動生成している

GitHub - xo/xo: Command line tool to generate idiomatic Go code for SQL databases supporting PostgreSQL, MySQL, SQLite, Oracle, and Microsoft SQL Server

自動生成されるモデル、自動生成用に使うテンプレートファイル、xo自体をどうやって管理運用しているかを残しておく

xo

xoを活用しているリポジトリではdepでvendor配下に利用するライブラリを管理している。そのノリでvendor配下にxoも入れようかと思ったけど、ロジックを実装する上では使う事の無いライブラリとなっている。

  1. ロジックを組むのに直接的に利用しないライブラリが、リポジトリのvendorにいる違和感。
  2. golang自体のバージョンを今後あげて行く上で依存するvendorを少しでもスリムにしときたい。

という理由からxoはグローバル領域にgetすることにした

自動生成されるファイル、自動生成用のtemplate

これらはgit管理化に置いてcommitしている

こんな感じ

./datasources/mysql
|-- driver.go
|-- driver_test.go
|-- models  // xoによって自動生成されたmodelはこのディレクトリに格納
|   |-- xxx.xo.go
|   |-- xxx.go
|   |-- xxx_test.go
|   `-- xo_db.xo.go
`-- xo
    `-- templates // globalにinstallしたxoのテンプレートファイル一式をここに格納(使っていないDBのtemplateも入れてしまっている)
        |-- xxx.go.tpl
  • xxx.xo.goというのがxoから自動生成されたファイル。(オプションでこのファイル名は変えれる)
    • これらのファイルには手動で変更を加える事は基本的になし
  • 自動生成されたxxx.xo.goのメソッドだけでは事足りない場合がある。その時は同じディレクトリ(=同じpackage内)にxxx.goファイルを追加してメソッドを追加している
    • ex:他のtableとjoinしてデータを取りたい時とかは自分で追加している
  • 自動生成に使うtemplateは随時都合が良いように変更・履歴を残したいのでgit管理下においた

tableスキーマに変更があった場合

xoを使ってxxx.xo.goファイルを再生成してプルリクをつくる

-> xxx.xo.goファイルだけのdiffのプルリクになる

自動生成されるメソッドの形式を変えたかったりする場合

テンプレートファイルを変更し、xoを使ってxxx.xo.goファイルを再生成してプルリクをつくる

-> templateファイルとxxx.xo.goファイルだけのdiffのプルリクになる

ちょっとだけ気になってる事

  • 特定のtableだけ対象にしてmodelファイルをgenerateできる用にしたいなーと思っている
  • xo自体のレポジトリ内でreleaseタグ運用を入れて欲しい
    • CONTRIBUTINGファイルを置いて欲しい

最後

自分が担当しているプロジェクトではちょっと合わなかった所は別でまとめるとして下記の所感

  • tableに対になるstructの定義とかが自動生成されるのはありがたい。
    • 毎回手動でやると間違った型定義しちゃう時あるし、tableスキーマが頻繁に変わるプロジェクトのフェーズだと特にありがたみを感じている
    • xoから生成されたメソッドでselectすれば、indexが効いたselectになるので無駄な地雷を踏むことがないので助かってる

コードレビュー時でも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とかイイっすね

さいご

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