00:06
こんばんは、Yokohama North AM第7回です。
Yokohama North AMは、中年エンジニアがウェブテック系のキーワードをネタにして雑談をするポッドキャストです。
ホスト役は、自称フルサイクルエンジニアのハンハン1978です。
本日のお相手は、あの赤瀬さんです。
こんばんは、赤瀬です。よろしくお願いします。
よろしくお願いします。
初っ端から事故ったのかと思いました。
あれ、音が飛んでるな。
聞こえない?
多分ね、音が一瞬大きくなりすぎて、マイクがキャンセルしたんじゃないか。
だから普通にしゃべれば多分大丈夫です。
大丈夫かな。
よろしくお願いします。
赤瀬さんですね。待望のゲストが来てくれました。
待望かな。
適当に。
適当にって言うと、ゲストにすごく失礼だなって思ったけど。
キャスティングを。
申し訳ありません。
出現でした。
あれですね。知らない方に言うと、
赤瀬さんと言うと、なんだろうな。
やっぱりあれなんですかね。
福岡のPHP界隈の。
になるんですかね。
として有名なのかな。
職業としてはバックエンドエンジニアですよね。
そうですね。ウェブアプリケーションエンジニアでバックエンドのコードを書いてる感じですね。
ウェブアプリケーションに関わる業務は大体やってる感じかな。
インフラとかヒードルウェアのセットアップとか。
あと普通にクライアントさんとコミュニケーションしたりとか。
そうですね。
あとフロントエンドとスマホアプリだけはできないですね。
それはいわゆる今のフロントエンドですよね。
そうそう。今のフロントエンドですね。
現代のフロントエンド。
現代のフロントエンドね。
現代のになってから割と長いですけどね。
長いんですけど、本当に追いつくのをやめた方がいいんじゃないかと思って。
どうだろうな。でも爪は引っ掛けておきたいなっていうのはありますね。
そうなんですよね。
バックエンドエンジニア人生ですかね。
僕も達章博士さんの話聞いたことあるけど、もともとSIでしたっけ。
03:04
そうですね。SIで5,6年いて。
SIにいたら先がないなと思って。
なるほど。
ちょうどウェブなんかも来てて。
Javaが盛り上がっている頃だったですね。SIの中でも。
SIのあれですよね。
ストラッツとかがバカーンって。
それが絵が出ないくらいですね。
エディターで言うとあれですよ。
エクリプス?
そうそう。エクリプスが出始めた頃ですね。
そう。なんかこのフォットキャストでも一回言ったかもしれないけど。
あれですよね。Java WorldとかLinux Worldとかが雑誌としては出てて。
Javaすごく人気でしたよね。
そこからPHPをやり始めて、最初に触ったPHPなんだったっけと思い出してたんですけど、PHP4でしたね。
3ではなく4なんですね。
4でしたね。
チャクータのサイトでダウンロードシステムを僕が引き継いで運用とかしてました。
なんかありましたね、あの頃。
なんか大変でしたよ。
Apacheでチャクータのダウンロード配信をするモジュールみたいなのがあって。
つらかったのが、この機種ではダウンロード再生できるけどこの機種ではできないみたいなのがあって。
どうしようもない。
サーバーサイドのコードではどうしようもないみたいな。
柄系ですよね。
けどクレームは来るみたいなやつがありましたね。
あれお金払ってるとめちゃめちゃクレーム来るんですよ。
来ますよ300円ぐらいで。
来る来る。
すごい来ますよね。
当時割と笑い話で言ってたのが、1000円2000円だとあんまクレーム来ないって言ってて、50円100円だとめちゃめちゃ来るって言われてて。
そうなんだ。
みんなで苦笑いしてたの覚えてます。
面白かったけどつらかったのもまあまあありますね。
これあれですよね。
博士さん、僕あれです。
ツイッターのアカウントでもわかるように1978年生まれなんで今ちょうど42ぐらい。
この世代の人たちって多分SIから入ってる人多いんですよね。
そうでしょうね。
多いと思います。
いわゆるITバブルの頃ですよね。
そうですね、就職活動でホームページから申し込むのが始まったぐらいの世代じゃないですかね。
06:01
グルナビーみたいなやつですよね。
会社のホームページにリクルートページができ始めたぐらいですよ。
あれですよね、氷河期ですよね。
で、SIだけなぜかめちゃめちゃ求人があるみたいな、なんかそういう時だった気がする。
僕の周りもみんなこぞってSEになってた。
大手の就職説明会に行って、これは受からんなって思った記憶がありますね。
めちゃくちゃ多くて。
人が。
人が。
その頃も赤崎さんって九州に。
実家長崎で就職で福岡に出てきたんですよ。
なるほどなるほど。
長崎ってその仕事が、IT系の仕事ないわけじゃないですけど、少ないので。
少なそうですね。
とある一企業の下請けだったり、一企業の関連企業のSI部門みたいな感じなんで。
なるほど。
でも福岡がやっぱ九州の中では一番こう。
そうですね。
そうですよね。博多駅の周辺すごいですもんね。発展して。
そんな感じですね。
あとは趣味で勉強会コミュニティを少々。
勉強会っていつ頃からやってました?
覚えてないな。
何歳ぐらいとか。
覚えてない。
多分SIの頃やってないでしょ。
やってないやってない。やってないですね。
僕覚えてんの、29とかそのぐらいの時に、レールズとかでめちゃめちゃ勉強会とかが起こってたような、発生してたような気がするんですよね。
で、なんか勉強会ブームみたいなのになってて。
僕、福岡で最初に盛り上がってた頃の次の世代なんですよ、僕。
なるほど。
アーリーアダプターの次ぐらいですかね。
アーリーアダプターの人たちとたまたま仲良くなって。
僕が最初あたりに参加した勉強会で。
で、そこで人との繋がりができて、広がったみたいなのがありますね。
そういう意味だと僕らの世代は割とラッキーっていう言い方になるのかな。
勉強会がなかった頃だから、そこから始まってたから、今よりもずっとハードルは低いような気がしますね。
09:06
今はだいぶ参加しやすいと思いますね。
参加しやすいけど、その中に入り込みづらいというか、微妙に。
僕らも作るところからだったので、勉強会を。
でも、割とめちゃくちゃな勉強会あったの覚えてるから。
行ったはいいけど、誰もいないとか。
住所間違ってて、ビール入れないとか。
なんかありましたね、最初の頃。
fukuoka.phpの第1回は2012年らしいです。
2012年。
ってことは、じゃあ30代前半ぐらいですかね。
ですね、そうですね。
でも早い方ですね、割と。
ですかね。
と思いますよ。
今は本当、毎日毎週勉強会ない日ないんじゃないかっていうくらいやってますもんね。
こんなになると思ってなかったけどね。
こんなになるんですね。
最初の頃は月に1回ぐらい割と注目の勉強会とかあって、それを追うみたいなのができたけど、今は諦めでしょ。
果て部で上がってきたスライド読むぐらいでいいやって。
というバックエンドエンジニアのおじさんですね。
僕もですけど。
そうですね。
同世代なんで、割とシンパシーというか、なんとなく分かり合えるところがありますね。
そうですね。
上の世代があんまりいないっていうね。
通ってる道は間違えど、なんとなく雰囲気は分かるみたいな。
そうそう。
で、あれじゃないですか、後輩は結構いるじゃないですか、もう。
勉強会とか行くと、不安なんですよとかって言ってくるじゃないですか。
うるせえ、お前俺もすげえ不安なんだよと思いながら。
そんなことないでしょ。
って思いながら相談に乗るっていう。
言わないけど。
言わないけど、お前より俺の方が不安だぞって思いながら。
ロールモデルいないしみたいな。
そうね。
そうなんですよ。
なので、今日はよろしくお願いします、ありがとうございます。
12:01
こんな言われても。
お忙しい中。
いやもう何言ってんすか、めちゃめちゃ腰が低いじゃないですか、僕は。
はい。
もうね、普段お尻すぎてて、何言ってんだと思って。
いや、そんなことないですよ。
大概的にはいい人。
うん、そうだね。
大概的には。
ちなみに僕とあかせさんは、最初はカンファレンスでうっすらと知り合って。
そうですね。
同僚になったっていう感じですね。
最初はすげえ怖い人だと思ってたんで。
そうなの?
うん、もう絶対怖いと思ってた。
あの人絶対俺のこと嫌いだなと思ってた。
怖くないでしょ。
近づかないようにしようと。
しっといなあ。
いやそうです。
たぶんね、あかせさんはちょっと人見知りだと思うんですよ。
いやめちゃめちゃ人見知りですよ。
うん、だからだと思うんですけど。
仲良くなればね。
で、今日のそうですね、
WebTech系の話を。
そうですね、Tech系の話をしましょう。
そう、そうなんですよ。
ちょっとね、雑談が過ぎるなと思って僕反省して。
雑談楽しいのよ、だって。
話さないじゃんってさ。
そう、そう。
仕事でZoomとかやると、だってね、仕事の話しするからね。
当たり前だけど。
雑談に飢えてるんです?
そう、みんなね、雑談に。とにかく僕雑談にすっごい飢えてて。
そう、なんでPodcast始めちゃいました。
で、あかせさんが話したいというのが、コードレビューの話ってよくやってたじゃないですか。
ん?
コードレビューの話って、なんか気になるんですか?
気になるっていうか、なんか僕、コードレビューなんかするのも、されるのも僕すごい苦手で。
あー、確かに。
なんか多分僕と同じような、なんか苦しんでる人いるんじゃないかなと思うんですけど。
めちゃくちゃ気にしいでしたよね、確かに。
いやー、もうめちゃくちゃ気にしいでね。
いや、結構ね、僕レビュー書くときって、その、おさほじゃないけど、もちろん激しい言葉は使わないし。
いや、変わりましたよね。
え、何が?
あの、多分、あの本読んでからだと思いますよ。
あー、そうですね。あの本読んで、指摘の仕方はだいぶ変わりましたね。
フィロソフィーオブソフトウェアデザインか。
フィロソフィーを読んだ以降の指摘の仕方はずいぶん変わりましたよね。
15:04
それはめちゃめちゃ感じるかなと思う。
ただ、口調とか全体的な方針は変わってないけど、根拠みたいなのは、本に求めるようになりましたね。
そうそう、なんかこういう根拠があるからこうしてくださいみたいな。
前まではね、なんとなくこれ嫌だからやめてほしいなみたいなのがあったときにうまく言えなくて困ってたんですよね。
なんか、あー、あの、俺これ嫌いだなーみたいなやつをうまく言語化できてなくて。
っていうのはありますね。
原職じゃないけど、前経験してすごい嫌だったのが、
なんか、なんだろう、本当にただただ否定みたいな。
なにこのコード意味がわからないみたいなのが普通にあったんですよ。
意味がわからないのはわかるけど、
じゃあなんでそう思ったのかを書かないと修正のしようがないし、
なんていうか、うまく伝えることができないですけど。
いやまあ要するにテキストコミュニケーションが苦手な人がいるんですよね、レビューで。
あと僕すごく気にしてやってるんですけど、レビューのときに点々って書かないようにするっていうのをやってるんですよ。
これはちょっと点々みたいな。
この書き方は点々みたいな。
まあ割とあってそれって。
何か伝えようとしてくれてることはわかるけど、どうしてもネガティブな印象になってしまうんですね。
受ける側は、レビューを受ける側は。
多分そんな気はないんでしょうけど。
であれば、もうちょっと具体性のある指摘を書いて、指針になるようなコメントがあるとすごく双方にとっていいんじゃないかなって僕は思う。
記号があるじゃないですか。
レビューのときにマストとかマストは必ず修正してほしくて、IMOはin my opinionだから僕はこう思うけど別にこのままでもいいみたいな。
ある時からその存在を知って結構IMOを使ったんですよね。
in my opinion。
だからその赤田さんが今さっき言ってた点々の代わりの結構ずるい言い方なんだけど、俺はこれ好きじゃないけどまあいいよみたいなのにin my opinion使えちゃうんですよ。
18:05
でもこれ100発100中レビューされた方はそれ直すんですよね。IMOって書かれてると。
そうなんですよ。
IMO直すんですよ。
IMO直すよね。だからIMOダメだなと思って。
あれ何ら効果ないなと思いますね。
あれはダメだなと思って。本当にIMO、本当に直してほしいやつ以外は実際は何にも言わない方がいいんだなっていうのは最近思ってますね。
でもなんか気持ちは伝えたいんだよなっていうのはあって。そこいつもすごい悶々としてる。
なんかなんだろうな、シンタックスレベルじゃなくてなんだろうな、タブとかエースとかさ、もうエディターコンフィグでいいじゃん。
そういうのが目についてしまうことがプロリクに上がってきた時にどう対処していいものか。
いやまあ相手によりますけどね。
そこはプロジェクトの三角時にエディターコンフィグっていうのがあってだねっていうのを説明して設定してもらうっていうのはやっぱりちゃんとやらないとダメなんだろうなって僕は思いましたね。
相手にやるかな。
大変なんだよ。
大変だけどね。
これはやらなきゃ後でめんどくさいことになるっていうのはやっぱり事前にちゃんとやっておかないといけないんだろうなと。
でも何度言ってもCRLF入れてくる人いるじゃないですか。
いるね。
いるよね。
もうなんか、うーんってなるんですよね。本質的じゃねえって思いながら。
本質的じゃないのをレビューの指摘をしたくないですよね。
だからオール向きルールみたいなのってきっとあって、最低限レベルのやつが。
でもそれがなかなか難しいじゃない。
それが伝わらない人にどうするかっていうのがね。
エディターコンフィグの存在を伝えてもエディターコンフィグを使ってくれないとか。
僕もよくやるけど、すごいたくさんループ書いちゃうとかさ。
あるわけじゃないですか。
そういうのとはちょっとレベルが違うと思うんだよな。
エディターコンフィグで済む話と、もう一歩進んでさっき言ったループがたくさんとか。
21:01
アルゴリズムの話ですよね。
同じ変数何回も使い回していっぱい書き換えるとか。
でもやると壊れちゃうじゃないですか。
PHPだとやらないよねみたいなのもいくつかあるじゃないですか。
ありますね。
PHPでこれ、書き方的には合ってるんだけど、バグを見やすい書き方みたいなのってあるじゃないですか。
ありますね。
その次のレベルのところをどう伝えていくかみたいなのは難しいな。
そうですね。
でもコードレビューは本来はそれをやる場ですよね。
アルゴリズムだとか、全体の書き方ですよね。
コードの統一感、統一性とか、プロジェクトの今までの成り立ちから考えてこのコンテキストを沿ってるかとか。
あまりにも早熟なリファクタリングをしてないかとか。
そういうもう少し高いコンテキストの話をしたいところにタブと空白が入ってくるとちょっと困る。
レビューはレビューのここが前みたいなのもきっとあって。
僕さっき言ったけどレビューに打たれ弱いので。
赤田さんは弱すぎますよ。
伝えてたかったけど結構気を使って。
一回IMOか何かで入れたやつですごい気にしてたのがあったからその次のレビューでものすごくさらに細かくしたんだけどそれでも気にしてたから。
一回読めたよね。
一回あれ多分急いでたのかな。
かもしれない。
それでちょっとね、すごく余裕がない状態だったんですよね。
でも言わないのはないよなとも思うから。
レビュー側はかかざるを得ないんだけど、でもこれ言ったらまたちょっとおかしくなっちゃうかなとか。
自分に仲悪くなりたくないとかそういうレベルでの話は全然思わないんですけど仕事だし。
僕も分かってはいるんだけど。
分かってはいるんだけどとはいえみたいなのもあって。
レビュー側はレビュー側で気にしてるんですよ。
気にされちゃったって思うと結構フタになるっていうのはある。
僕はどっちかっていうとものすごく指摘されたい人なんで、何指摘されても全然なんとも思わないんですけど。
24:00
僕は逆に指摘するときに相手が気にしないかなっていうのを気にしちゃいますね。
そっちのが僕にとっては精神的に負担かな。
だからなんかどっちもあるのかなって。
だから自分はその言われる側の気持ちが分かりすぎるぐらい分かるので。
最初に言ったように点々を書かないとか。
いやもう絶対書かないですね。だって嫌だもん。
でもあれでしょ。日本語で言うとなどって書かないみたいなやつでしょ。
曖昧な言い回しを避ける。含みを避ける。
ただ散々言ってあれだけどレビュー体制はある程度あった方がいいなと思う。
レビューは絶対必要ですね。これ100%必要。
いや体制って仕組みの話ではなくて。
耐える方ね。
受ける側はその体制があった方がいいと思う。
自分はなさすぎるのが分かってるのでちょっとこれは良くないなと思って。
これちょっと聞いてみたいんですけどそのレビュー体制ないっていう状態で。
でもレビューいっぱいしてたじゃないですか。レビュー員になることもたくさんあったと思うしレビュワーになることもたくさんあります。
レビューの中でレビュー体制っていうのは向上していたんですか。それともやっぱ無理だわって感じなんですか。
向上してなくはないけど、そもそもやっぱりメンタルはそんなに強い方じゃないので。
レビューはこういうものだからって思わないとやれないんですよ。
なるほどね。でもそれは聞けて良かったです。
その辺はどこまでフォローするかっていう話はあるけど、そういうのを考えた仕組み作りをしていかないと
その人の持つ性質によってレビューっていうものの負担度が変わってくるっていうことになっちゃうから、それは避けた方がいいですよね。なるべく。
あともう一個あって、エンジニアだったら一つのプルギクを少し小さくしようとすると思うんですよね。
一つのイシューを課題、一つのイシューを解決しようとするプルギクはなるべく小さくしようとして、レビューしやすいような状態で渡すと思うんですけど
これなんとなくエンジニアだったら分かってて、なるべくそういう風にすると思うんだけど
エンジニア以外のメンバーのプルギクも見なきゃいけないことが多々あるじゃないですか。
あります。
これなかなか伝えてもなかなか守ってもらえないし、あとイシューを切るのがエンジニアではなくてディレクターの場合があって
27:01
ディレクターって一つのイシューに複数の課題を書きがちで、それをタスクして巨大なコーダーに渡す作業依頼することってあるじゃないですか。
ってなった時に巨大なプルギクになりがちで、リリースしづらいものが生まれることがある。
これどうしたもんかなってずっと思ってるけど答えがない。
まず第一に言っておかなければいけないのが、僕は割とデカいプルギク作ることがあるんで、何も言えねえなっていうのがちょっと一個も。
僕もあります。あるけど、エンジニアは影響度とか、これはこういうプルギクで、これこれこういう課題とこれとこれとこれを解決しようとしてるみたいな説明をちゃんと書くじゃないですか。
何が起こるかわかって作ってますね。
それが説明ができるんだけど、そうじゃない場合があって、なんかすごい巨大で、実はこれも修正して、あれも修正して、こっそりこれも直してますみたいなプルギクのレビューが回ってきて、これは何を見たらいいんだみたいな。
機能がA、B、Cあった時に、Aのプルギク、Bのプルギク、Cのプルギクじゃなくて、A、B、C全部入ってますみたいな。
僕らが多分本当に欲しいのは、機能Aのかつ画面1だけとか画面2だけとかになってるのが本当は好ましいんだけどみたいな。
その単位でリリースできるんですよ。でもなんとか機能みたいな巨大な一周になってて、終了条件がでかいやつ。
そうなんですよね。
これをどう伝えるべきかみたいな。
これってでも結構コンテキストが、コンテキストって深いっていうのかな、でかいと言うべきなのかな。
またレビューとは違う話なんですよね。
リリースしたことがありますかとか、Gitでマージとかコンフリクトの解決とかをする人ですかとか、そういった知識もないと、
ちっちゃくしようっていう、そもそも動機があんまりないだろうなと思うんですよね。
だって目の前のブランチにボコボコボコボコミッテして考える。楽っちゃ楽じゃないですか。
そうですね。
これは伝えづらいなーって思いますね。
でもずっと大変じゃないですか。
ずっと大変、ずっと大変。
これって。
小さいトラックだからね。
考えてました。
これはでも根本を言うのであれば、一周を分割、まずはしなきゃいけないっていうのが。
30:02
だけどエンジニア以外がその一周を作ることがあるじゃない。
だから手が回ってないときとかね。
雑な、雑なって言ったら悪いな。
ちゃんと仕事を進めようとして進めてくれてるんだけど。
まあでもロングライフブランチにいいことは一個もないんで。
そうですね。めっちゃ苦労したこの前。死ぬかと思ってた。
なんかそれが本当にその人だけが作業してればいいんだけど、なんかちっちゃい修正とかが横から入ったりしてて。
途中でリリースしたいことが多々あって。
どうしたらいいんだこいつって。
マージコミットとかが変に入ってたりとか、途中でこの人訳もわからずプルしたなみたいな。
大変だったよ。本当に。本当つらかったんだよ。
大変ね。でもあれですよ、僕サブバージョンの頃からずっとそういうのを解決する職人をやってたんで。
僕もやってた。
まあしょうがねえかなと。
リリース職人もやってた。
コンフリクト解決職人とリリース職人ね。
一社に一人は必ずいないと困る。
まあコードレビューの話はそんなところですな。
まあそうですね。だから啓蒙活動をしていくしかない。
久しぶりに見たんだけどすごくいいスライドがあって。
僕結構何回も見直すんだけど。
挫折しないレッドマインっていうスライド知ってます?
これ見たことない。後で参考であげますけど。
これすごいいいスライドだなと思ってて。
僕はレッドマインはよく挫折してましたよ。
別にこれレッドマインの話なんだけど。
インストールの話じゃないですか。
違う違う。
チケット管理システムの使い方みたいな。
そうそうそうそう。
なるほど。
これすごくいいんですよこのスライド。
これでも啓蒙活動。
一周の話があってですね。
流度が大きいとダメとか。
複数の課題が書かれてるとか。
終了条件が不明確っていう三大条件が書かれてて。
あーなるほど。
これはやっちゃダメだよっていうのを頭に入れておくとすごく良いなと思って。
これあれじゃないですか。
会社のスラッグに放流しとこうかな。
僕何回も放流してるけど見られたことないよ多分。
じゃあダメじゃん。
何度もスライドの切り抜きをしてはっつけたことがあるよ。
33:05
難しいんだよだから啓蒙活動って。
どうしたらいいんですかね。
結局そうすると
共産主義みたいな統制を取っていくみたいな方向の考え方にするか。
それともある程度はそういうこともあるさと。
許容するか。
中にいる人がそこはヨシナに毎回毎回同じことを言ってしまうかもしれないけど
こうしようねみたいな。
難しいんですよ。
でも僕はもう最近の流行りは
IMOはもう使うのやめようっていうぐらいですかね。
ああいうずるいのもうやめようと。
僕のレビューで気分悪くした人もいるんだろうなと思っていつも反省してます。
いやいやすごく真っ当なというか素敵ですよ。
ありがとうございます。
良くなってますよ修正された構造は。
アクションか Qual moisturizerのものが絶対好きですよ。
ホッキーさっきでも言ったけど
【松田】本当ですかじゃあ
嬉しいですね。
ロリポップって俺なんか、あ、すごく今、全然関係ないこと思い出しちゃった。なんでもないです。ごめんなさい。
なんか僕ほら、よく富所さんに言われるけど、
常に自信がない方なので。
確かに。負けた絶対。
自分の実力に対して自信がなさすぎるので、たまにね、0から1にこうやっとかないと不安になるんですよ。
でなんかこう、自分、あ、物作れるんだぞっていうこう、自信をつけとかないとメルトダウンしちゃうんで。
久しぶりに作った感じです。
厄介なんだからもう。
そう、厄介なのよ。
でも、僕も割とそうですよ。やっぱ自分で何か作ってないと、引き出しがね、全然ないから。
っていう感じがいつもありますね。
すごい簡単なやつですけどね。
いやー大事ですよ。テキスト付けとくの。
36:00
まあまあララベル使って、簡単なクラウドです。
でウェブアプリ作って、いつぐらいからやったかな。5月の末ぐらいから6月の1週目ぐらいまで。
だいたい2週間ぐらい作ったんですけど。
で動かすとこは、マネクラ、ロリポップマネージドクラウドを使って、
で、前ちょっと触ってましたけど、GitHub Actionsでデプロイをするようにして。
で、
割と最近のスタックで。
そうそう。
仕事だとあれですもんね、追加開発が多くなっちゃうから、01のフェーズをやらないことが多いですよね。
そうじゃないですか。
今稼働してるウェブアプリケーションに対して何か所修正をするみたいなのがまあまあ多いので、
まっさらな状態から作るっていうのはまあまあいいなと思って。
じゃあロリポップで、ロリポップってコンテナそのまま動かしたんでしたっけ?
いやなんかロリポップ上、マネージドクラウド上で独自のコンテナ環境があるっぽい。
あ、PHPのこれかな。
スターターオンクラウド。
どうだったかな。
またあるいはそれぞれのクラウドサービスでちょっとずつ違うから、それもやってみないとって感じで。
そうそうそうそう。
で、これマネクラってあれなんですよ。
PHP Conference福岡のサイトを動かしてて。
うんうんうん。
で、静的ページしか載っけたことなかったんで、初めてPHPを動かしたんですよ。
それも試してみたかったので、ちょうどいい機会だったなと思って。
そうですね、まあなんか自分でプロトタイプとかを簡単に作れる環境とかの引き出しを増やしとくと、
仕様の詰めとかの話してる時に若干自信がついてるから、やっぱいいですよね。
ちょっと気になったのがベッセル?
ベッセル、うん。
ベッセルってララベルのDockerのやつ?
そうですそうです。ララベルのDocker環境ですね。
もともとDocker使ってなくて、ほんとすぐ動かしたらいいかなと思って、
PHP Parts and ServeでとSQLiteでやってたんですよ。
39:04
ダメじゃないですか。
いやもうなんか、動くし。
いや動くけど。
いいかなと思って。
ダメダメダメダメ。
まあまあ最後ら辺までこれでやってたんですよ。
さすがにDockerに変えようと思って、ただなんか1から準備するのめんどくせえなと思ってたんですよね。
で、ベッセルを押し込んで、非常に簡単に移行できました。
このベッセルは何なんだろう。ベッセル自体は誰かがメン…
あ、なんだこりゃ。
Composer Requireって書いてある。
これ結局あれですね、Docker Composeで複数のDockerコンテナくっつけてて、
それを吉野にララベルが動くっていう風になってる。
ベッセルイニットとかってやるとコンポーザー…
アーティストです。
Docker Compose YAMLとかが作られるみたいな、そういうイメージなのかな。
なんか薄いラッパーなんですかね、じゃあ、Docker Compose。
そうですそうです。
そんな感じか。
そっちでよくやってる、メイクと全く一緒ですよ。
あーなるほど。
全く一緒です。
で、ベッセルアーチさんとかやると、アーチさんコマンドが動く。
えーやだ嫌いそれ。
メイクでやってんじゃん。
いやでも、めんどくさいな、また新しいの覚えるの。
ベッセルコンポーザーとか。
メイク入ってるもん。
でもこれコンポーザーリクワイヤーするからコマンド入るのか。
あーそういう感じね。
分かりました分かりました。
前にさ、だいぶ前にやってた、うちでやってたサービスでさ、
カード配るやつ。
あーカード配るやつ。
カード配るやつやったじゃん。
カード配るやつがありましたね。
あれのDocker Composeに非常に近しい構成ですね。
非常に近しい。
かなり軽微なというか。
うん、ですです。
ララベルを動かすための最低限みたいな。
ほんとそうです。だからなんかララDockみたいに何でもかんでもじゃなくて。
いやもうあえて言わなかったのに言っちゃうからもう。
別に言い悪いだって言ってないじゃん。
ごめんなさい、何でもないです。
僕ララDockの悪口なんかそこ賢で言ってたから。
ほら、私も悪口言ってないよ。
42:05
あるじゃんと思って使ってみたら、なんだこのでかいのは誰が作ったのってすごい怒ってたから。
こってらの意味ねえじゃねえか。
最小構成みたいな感じです。
デフォルトでセッションがレディースになるぐらい。
ぽいですね、レディースって書いてあった。
別に使わなくてもいいんですよ。
Node.jsもちゃんと入るんだ。
入る入る入ってる。
だからフロントとか、ほら今最近セットじゃないですか。
だからNPMはすぐ叩けるようになってる。
じゃあ下手なことするんだったら、こっちで最新セットで作っといたほうが。
これまあまあいいですよ。
僕そんな嫌じゃない。
筋がいいかもしれないですね。
割と手間なんですよ。
こいつのDockerファイルとか読むと自分でも作れるようになると思いますよ。
確かに。
そんな変な感じではないです。
Dockerコンポーズのボイラープレートみたいな、そういう感じのイメージでいれば。
これはでもいいこと聞きましたね。
ちょっとやってみようかな。
僕も独自でDockerコンポーズとかを練り上げてたから、人のやつをあんま見てないんですよね。
人がどうやってるのかって見たくって。
自分で作りたくなりますしね。
ていうかね、僕始めたことなかったんですよ。
誰もやってる人いなくて。
あんまやってる人いなくて参考にできなくて。
そのまま来ちゃったから、今は実際には多分もっと簡単でやりやすい方法とかあると思うから、
そういうの見たいなって思ってたんで。
こいつのDockerコンポーズを見ると、
Lalaveで使う.envのMySQLの環境変数を拾って、
接続情報として使うみたいなのが書いてあるんでしょう。
ちょっと良さそう。
良さそうですよ。
みたいなことを5月末から6月の頭までやってます。
いいですね。やっぱり個人開発をしたおかげでVesselを知り…
そうそう、Vesselとか知り得なかったからね、これやってないと。
そのおかげで僕もちょっと興味が湧くと。
またLaladockの2番センジ太郎ぐらいですごく最初ディスってました。ごめんなさい。
頭の中で。
GitHub Actionsで前よりもちょっと詳しくなったかな。
GitHub Actions。
単純にSCPデプロイだけだったけど、前は。
ちゃんとLalaveのデプロイ時にやることをどうやったらできるかみたいなのがちょっとわかったんで。
45:00
そうですね。
いいのはマネクラってSSHできるので、もうなんか最強みたいな感じですよ。
SSHで繋いでしまえさえすれば後はどうにでもみたいな。
最近でもあれかな。社内でちょっと話したのが、サークルCIがうちは多いけど、
CIはGitHub Actionsで回して、リリース周りはコードパイプラインか。
AWSだからうちは。そっちに寄せてってサークルCIの依存を下げたほうが多分楽だよねみたいな話はしてるから。
割とサークルCIももうあれなんで。秘伝のたれなんで。
GitHub Actionsとかに負荷を分散していったほうがきっと頭はよろしいなとは思いますね。
GitHub Actionsはなんか自分で書いたほうがいいっすね。
人が作ったActionsは使うべきじゃないと思うし。
ちょっとそれはわかるな。
業務だと特にですね。
Dockerファイルとかもそうですけど。
もうですよ。
VagrantBoxとかもそうでしょ。
いやもうそうそう。それと一緒の感覚じゃないですか。
お前どこの誰だかが作ったのかもわかんないBoxよく使うなみたいなのありますよね。
公式か自分が作ったやつかじゃないとちょっと良くないと思う。
そうですね。ちょっとそれありますね。
そういうのを固定しとかないと本当に危険ですよ。
それはそうですね。
中身をちゃんと見て。
だからあれか。参照リンクにGitHub Actionsのヘルプが入ってる。
そうっすね。
ちゃんと出るんだ。
僕あれだけどロケールを英語にしてるけど日本語で出る。
それはリンクが日本語だった。
JARのリンクを貼ってるからです。
英語用名ってちゃんと注釈入ってるの。えらいな。
最新を見たかった。
上のほうに書いてあるんですね。
多分この辺卒がないよな。
ちゃんとこういうところまでお金が回ってる感じがする。
という個人開発のお話。
そしてなんともう50分。50分経ってますよ。すごいでしょ。
本当だ。
今日もうとっておきの最後のトピックがあるじゃないですか。
最後なんだっけ。
今年のフェチコンはオンラインだよってやつですね。
そうっすね。どうなるんでしょうね。
わかんないな。
これさ。
48:02
何?
言ったことじゃなくて。
そうですね。
どうなるかが非常に楽しみですね。
多分中の人。
多分聞いてくれる人の中には中の人が何名かいらっしゃるかもしれないんですけど。
この放送。
どうするんだろうなって。
そうですね。
割とこのコロナ体制になってからリモートをみんなでするようになって。
勉強会がオンラインになったじゃないですか。
何個か参加してて思うのは。
大変ですよね。
僕ね。まだ参加したことないんですよ。
ないんですか。これさ。絶対参加したほうがいいですよ。
ですよね。
リアルに体験したほうがいいと思う。
まだ体験したことがなくて。どういう風な運営の仕方をしてるかをまだ知らないんですよ。
配信元の人たちのテクニックにもよると思うんですけど。
僕の勝手なイメージなんですけど。
僕はPHPカンファレンスの東京が初めてLTしたやつなんで。
結構思い入れがあって。
ベチコンのLTって一番大きいホールでやるじゃないですか。
ものすごいいっぱい目の前に人がいるんですよ。
あのライブ感ってオンラインでは多分無理じゃないですか。
そうですね。あの緊張感やばいですよね。
あれはオンラインでは多分経験できない話で。
オンラインでどういう風にああいう体験を作るべきなのかどうかも含めて。
どうしたらいいんだろうなっていうのはすごい興味があるというか。
前ツイッターで書いたことがあって。
オフラインのイベントって本当に巡り合わせみたいな出会いがあって。
ありますね。
ツイートよく見てますとか。
あとなんだろうな。
実はあの人が僕の奥さんなんですよ。
その奥さんと実はよく知ってるとか。
そういう偶然の出会いみたいなのがまあまああるじゃないですか。
ありますね。
51:02
そういうのが無くなると思うので。
無くなるもしくはものすごく小さくなるか薄くなるかっていうのは確実ですね。
そういう面がやっぱ非常に良いなと思ってる方なので。
ただこのオンラインの流れっていうのは全く避けれないし。
きっと今後は全部オンラインになるんだろうなって思ってたりもするし。
ただちょっと一つ思ってるのが。
思ってるというかちょっと気にかかったのがツイッターでちょっと見かけたんですけど。
今後は全部オンラインでいいじゃんみたいなのを見かけてしまい。
いやーそれは。
ちょっとうって思ったんですよね。
多分それは参加する側のみしか経験したことない方の意見だとは思うんだけど。
前からオンラインだけでいいと思ってたんだよみたいなのは見て複雑だなと思いました。
今年ペチパー会議ギリギリでできたじゃないですか。
あのペチパー会議でトレーディングカード的なものが参加者全員作って、
それで交換するみたいなのをやって。
あれこれすごいなめちゃくちゃいいなとか思ってたんですけど。
オンラインは絶対できないじゃないですか。
あれがなくて全部オンラインでいいじゃないかって言われちゃうと。
なんかそれはやっぱりちょっと違うんだよなって思うんですよね。
でもオンラインは避けられないけど、じゃあどうするのみたいな。
答えがないので。
答えないよね。
やっぱほら、いつもツイッター見てますと、
あと顔とアイコンがようやく一致しましたってオフラインじゃないと味わえないじゃないですか。
味わえないです。
あれすごいいいんですよね。
リアルにちょっとこの人と喋ってみたいっていう人いらっしゃるじゃないですか。
オフラインだと勇気はすごいいるけど、
接点を持つチャンスはあるんですよね。
そっからなんかよくわからないぐらいのレベルで仲良くなってる人とかいるじゃないですか。
54:03
いますね。
オフラインでもできるのかな。
ツイッターであれですかね、うざがらみとかするみたいな、そういうこと。
なんかちょっとそれ違うなと思う。
今までの流れだと最初にオフラインでの出会いがあった後、
ツイッターとかでの絡みで膨らんでいくみたいなのがあるような気がしていて、
その逆ってできるんですかっていうのはちょっと感じるところでありますね。
できるのかもしれないし、できないのかもしれない。
まだ知らないだけかもしれないですね。
知らないだけかもしれない。
オンラインはオンラインで今後解決策が出てくるかもしれないし。
割とみんなクラスター使ってるじゃないですか。
クラスターってARのやつですっけ。
そう、ARのやつ。
あれ僕ダメなんですよ。めちゃくちゃ読むんで。
3回ぐらいやって1回酔って、ちょっと今怖い感じ。
終わった後、30分ぐらい参加して、その後2時間ぐらい動けなくなっちゃったんですよ。
気持ち悪くて。
うん気持ち悪くて。
これは慣れるのかなどうなのかなってちょっと怖かったですね。
僕初めてなんだけど、明日スパティアルチャット。
スパティアルチャット。
座席の概念があるチャットで飲み会しようって言ってます。
座席の概念がある。
うん座席。
Zoomでもみんなフラットじゃないですか。
そうですね。
全員一斉に繋がってる感じじゃないですか。離れた席っていう概念がある。
チャットのシステムがあるらしく。
あ、チャットなんですねでも。
うん。
音声ありだと思うんですよ。
音声。
あーちょっと面白いな。面白そう。
画面上に物理的な位置がある。
物理的な位置があるんですね。画面上に。
そうそうそうそう。
えーちょっと面白そうですねスパティアルチャット。
うん。
まあでもこういうのの多分試行錯誤していくんでしょうね。
そう修練淘汰されていくんじゃないですか。
そうですよねスパティアルチャット面白そうだなとは思ったけどこれ100人規模は無理ですもんね多分。
57:04
アイコンで埋まりすぎちゃいそう。
どうするんだろう。
どうするんだろうっていうか何とかやっていくしかないんだろうな。
とりあえず1年延期したけどさ。
なんかしら。
PHPカンファレンス福岡ですか。
福岡福岡。
なんかしらこう模索をしないといけないだろうなってちょっと思うところですね。
そうですね。
今だって開催ってめちゃめちゃ怖いでしょ。実際に物理でやろうってなったら。
もし出た場合に保健所の連絡とかどうしたらいいんだろうねみたいなことを気にしなきゃいけないんで。
そうですよねそういうリスク考えるとできなくなっちゃう。
どこから来たみたいな人の追跡ができる状態にしとかないと僕らはそういう責任が出てくるので。
でなると。
受験から参加された人でみたいな追わなきゃいけないと思うんですよ。それ報告しないといけないと思うんで。
嫌だなそれ。
無観客カンファレンスみたいな。
アカウント名だけしか聞かず支払ってもらってたところをちゃんと連絡先と本名を抑えなきゃいけないだろうなってちょっと思ってて。
ちゃんとするんだったらですね。
もしくはトラッキングのアプリを必ず入れてもらうとかですよね。
それも聞いただけで今後しばらくカンファレンスねえなってちょっと思っちゃいますね。
でほらやっぱそう参加してもらうときには参加登録してもらうときにはことが起こったときにしかるべきところに個人情報を連絡しますよみたいなオプトインを多分しないとダメだろうなと思う。
いや絶対必須ですね。
でも参加する側からするとそういうオプトインがない状態でカンファレンス開くってなったらそれだけで不信感になっちゃうし。
そうでそんなところで叩かれたりしそうじゃないですか。
叩かれそう。
いやだから難しいなあと思って。
むずいですね。
次物理的なカンファレンスいつ開かれるんだろうってちょっと思っちゃいました今。
日々考えてるんだけどこれはなかなか難しい課題だなって思ってます。
なのでとにかくね割と最近やってるオンラインの勉強会実際にね絶対行った方がいいと思います。
そうですね僕参加してみます。
あのめちゃくちゃね事故りますよ。
1:00:00
あのもう数回事故は見かけたので。
配信をやっている主催側のネットワークは問題ないんだけどみたいな。
登壇者の線が細いとかありますよね。
そう登壇者の線が細いっていうパターン。
あとはなんかZoomでシェアしようとしたけどシェアがなかなかできないって言って。
シェアも事故りそう。
うんシェアも事前に何回か練習しないと事故りそうでしょ。
なんかさあのコンフィデンシャルなやつをさ。
そうそうそうそう。
あっとかやりそうっすよね。
やると思う絶対あると思う。
うんスラックで変なポップ上がると思うし。
変なメンションとか全画面をシェアとかしてたりするとやばいっすよね。
あり得ると思いますよ。
あり得ると思いますよ。
うんというかもう見かけたし。
それ。
MacのLINEアプリとか入れてたら地獄っぽい。
うん確かに。
考えただけであるでしょ。
僕だってこれ今配信してるやつも本当に全部のソーシャル系とかを必ずアプリ落とすとか
それ全部手順に入れないと怖くてできないから。
主催者はやってくれるけどそれをスピーカーまで全部にちゃんと徹底させられるかっては割と難しそうね。
そうですね。
なんかその辺もプラクティスができてきそうな気がするけど。
はい。
って感じでなんと1時間が経ってしまうんです。
はい。
なのでそうですね。
まとめると何ですかね。
いつもの2人なんで喋りすぎますね。
そうですね。
喋りやすいなと思って喋ってました。
知ってる人って喋りやすいなってすごい気づかなくていいし。
Zoomで喋ってるやつをさ配信してるだけですよね。
そうそうそう。
いつも。
そう。変わんない変わんない。
そこのちょっと軸をWebTech系のキーワードっていう風にするっていう。
これもまだ配信7回目なんでまだまだ模索をしてます。
はい。
なのでまたゲストの依頼をするかもしれませんがその時は。
はい。分かりました。
ぜひ。
じゃあ。
終了の儀に移りますね。
はい。
今週も放送をお聞きいただきありがとうございます。
番組のフィードバックや要望はハッシュタグ横浜のセームをつけてツイートしてください。
本日のお相手は赤瀬さんでした。ありがとうございました。
ありがとうございました。
1:03:01
横浜のセーム。