00:02
みなさんお疲れ様です。12月13日の夕方5時半になりました。
DevRel Radioの92回目をやっていきたいと思います。
また残念ながらですね、録画放送になっているんですけれども、みなさんいかがお過ごしいでしょうか。
今日はですね、ラジオで、ポップキャストで聞いているとわからないと思うんですけど、ホテルでやってみます。
前回もホテルだったような気がしますかね。今回もホテルで、今日はですね、ここはカイロですね、エジプトのカイロの国際空港で、
こっちの時間は夜中の4時ですね。なんでそんな時間に起きているかというと、日本時間に合わせてですね、ちょっと体内時計をリセットしようかなというところで、
日本時間でいうと午前11時らしいですね。なので明日も同じような夜中の2時ぐらいに起きて、そこからずっと起き続けて、
飛行機に乗ったりすると多分いい感じになるんじゃないかなというふうに思います。
このカイロなんですけど、ネットワークめちゃくちゃ弱いんですよね。ホテルのネットワークすら弱いんですよね。
さっきここのホテルのネットワークで測って、770kbpsとか、もうなんか地獄のような遅さだったりするんですけど、モバイルの方は大丈夫ですね。
今回はアハモのやつを契約してきてるんですけど、そこのモバイルのネットワークで4Gとかになると20Mbpsぐらい出るんで、
そうすると安定して喋れるっていう感じになっています。そんな感じでオフレルラジオやっていくんですけれども、
カイロのちょっとした話をすると、当然エジプトだとピラミッドであったりとか、
スタンカーメンの黄金のマスクだったりとか、そのあたりは見たんですけど、正直一回見れば十分かなという感じですね。
今から6000年くらい前からピラミッドって存在していて、今も存在するわけで、別に来年来てようが、ピラミッドはピラミッドだったと思うので、
03:02
1回来れば多分十分なのかなと思いますね。多分2回来ることはないだろうなと。来るのが意外と大変っていうところと、
言葉がね、基本アラブ系で、ホテルとかの人は英語が喋れるぐらいな感じなので、結構言葉の問題があったりとかします。
あと交通事情が凄まじくて、何でしょうね。いくつか挙げると、まず信号がないと。全然信号ないと。
私が見たのがカイロの都市のど真ん中の一番トラフィック多いだろうなーみたいなところに一箇所だけ信号を見たんですよね。
それ以外どこでも信号ないので、縦横無尽に車が走りまくってたりとか、車線も全然守られてなくて、
3車線ぐらいの道路のところに6台ぐらい横に車が並んでるみたいな。ぎゅうぎゅう詰めな状態で、お互い場所取りを無理やりやりながら走るみたいな。
さらにその中を人が道路を渡るみたいな感じですね。すごいカオスな状態なんですよね。
あれを思うのは、インドはちょっと近い雰囲気でしたかね。
インドはちょっと近いけど、さらに運転の、3車線のところに6台並んでるみたいなのを見たことがなかったので、結構衝撃でしたね。
あとは、一方通行の道だと車が両側に停車しまくってるので、ほんと狭すぎて通るのすら大変とか、人が歩く隙間もなかったりとかするので、
この国に来てホテルに泊まり、歩いてどっかに行くっていうのは結構絶望的というかですね。
まあ、おっかなすぎてできないだろうなっていう雰囲気がありましたね。
インドはまだ歩けたんですけどね、この国は、エジプトは歩く気になれないですね。怖すぎて。
車ビュンビュン飛んでくるし、高速道路とか渡ってるおっさんとかいるし、ほんと現地の人ならではというか、渡りながらスマホとか見てる人とかいますしね。
バイク運転しながらスマホ見てる人もいるし、みんなスマホ見てるし、あんな状態で歩いてたら簡単に引かれるやろうとか思うんですけど。
そんな感じのですね、カオスな空間のインドに来てたんですけれども。
06:01
一回はですね、多分来てみるといいんじゃないかなと思いますね。
ピラミッドすごいし、ツタンカーメンの黄金のマスクすごいし、
多分来年、新しい博物館がオープンするんですよね。
名前なんだったかな、エジプトグレートミュージアムかな。
そんな名前のやつがオープンする予定になっているので、それができたらですね、来てみてもいいんじゃないかなと思いますね。
本当は私それが見たかったんですけど、11月にオープンするって言ってたのに延期されちゃったんですよね。
なので、今回は見れなくてですね。
でも、そっち側に移動する前の黄金のマスクとかは、エジプト工工学博物館だったかな、そっち側にあるので、
それは見れたんで満足かなっていう感じですね。
そんな感じのエジプトだったんですけれども、そんな回路からですね、今日はお届けしていこうと思います。
ということでですね、これを録画で放送しているときって、
いつもサイトとかを見せるのがちょっと難しかったりするので、
どうせ動画で見ている方向けにはなってしまうんですが、一緒にサイトを見ながらですね、やっていこうと思います。
はじめまして、よろしくお願いします。
今回の選択のことですと、
最初の被告はそのウェブ公開のほうでですね、
ですね パブリックキーさんからの 記事で GitHub CEO トーマス・ドムケ
氏が来日 いずれこの80パーセント はAIで生成されるようになると
予言という記事が書かれています これ 職業プログラマーというかエンジニア
の人からすると結構危機感がある 部分があるのかなと思うんですけ
けれども 実際 コーパイロットを 使っていると 本当に十分という
09:12
か コードがババッと生成される ようになるんで 自分で書く作業
っていうのは大幅に減っている っていうのを感じるところがある
んですよね このコーパイロット の仕組みって 結構エンジニアの
人からすると嫌われている部分 とかもあったりするんですけれども
GitHubの人に前に聞いたときには 何か分からないことがあって Google
で検索して Stack Overflow とかの記事 にたどり着いて そこに書かれている
コードをコピーして 自分のプログラム ファイルの中に書き込んで それを
改変するみたいになって よくやってる 作業かなと思うんですけれども
それを自動化しただけだよねって ことを言われて 確かにそう言われ
ればそうかみたいな感じではあるん ですよね それがさらに目的に合わせて
コードがいい感じに改変されて 生成されるんだったら それはそれで
便利だよなっていうのは確かに 分かるところはあるんですよね
そういうコーパイロットみたいな 仕組みがどんどん発展していく
と 本当に80パーセントのコード が生成されるようになるっていう
のが必ず間違ってはいないのかな という気はするんですよね すごい
質問だね そうするとノーコード ではないですけれども ノーコード
の発展版みたいな感じでやりたい ことを指定すれば それだけでコード
がババッと生成されちゃうような 未来が本当に現実になるのかな
というふうに思いますよね ここの コード生成って長い歴史のある
エンジニアの夢みたいな部分が あると思うんですよね 昔だったら
UMLとかもそうですし MDAでしたっけ Javaの考え方 Javaのスケルトン
コード生成したりするようなモデリング 技術とかあったと思うんですけれども
あれが喜ばれたのは やっぱり図を 作る部分っていうのは人が行って
こういう図を作っていれば スケルトン コードはけるよねっていうところ
を機械でやっているっていうだけ なので 結構人間をコントロール
できる部分が大きかったと思うん ですよね それに対してコーパイロット
とかって コメントで書く場合も そうですし コードを書いてエンター
を押したときに それまでのコード の内容から次の必要なメソッド
12:02
が作られたりとかするっていう 部分で ちょっと不気味の谷を感じる
部分もあるのかなっていう気は するんですよね その不気味の谷
の部分を受け入れちゃうと こんな いいサービスが他にないなみたい
に思っちゃうんですけれども 確かに エンジニアの仕事を奪いかねない
部分もあるのかなと思いますので なかなか我々としてはエンジニア
を応援したいという部分はあるん ですけれども 80パーセントのコード
が作られるようになってしまう と エンジニアの価値っていうのは
どこにあるのかっていうのを結構 見極めなきゃいけない部分も出て
くるのかなという気はしますね これに付随するような情報があった
んですが メモしてないかな メモしてないですね では 続いての話で こちら
はログミさんの記事ですね 親切 な人たちが言ってくるRubyはひな
Rubyなんか使わない 松本幸弘氏が ノイズを気にせず考えるRubyの価値
という記事が挙がっております こちらはRuby会議2022のキーノート
から取り上げられている記事なんですけ れども このRubyは死んだとかRuby
なんかもう使ってないっていう のは 本当 長く言われ続けてるよ
なっていう気はするんですよね それがキーノートの中でギャグ
として取り上げられちゃうぐらい ですね 言われ続けてるっていう
のがあるのかなという気がします ね 面白いのは 誰もRubyなんて使ってない
これは作った当初なんですけれども 私たちが使っているのはRだしPHP
だしPythonを使っていると Rubyなんか 使わないということを親切に教えて
くださる方がいらっしゃったん ですね それから これはずっと
続くんですけど Rubyにはキラーアプリ がないので Rubyの使用される領域
というのは限定的だと言われた こともありました それから これも
何年か前に言われたことなんですが お前はRubyを作るべきじゃなかった
と その代わりに今Rubyを開発している ために使われているリソースは
Perlに集約すべきだと Perlのほう がもっといい言語だし Perlに私たち
が注力したほうが世界がもっと いい場所になっていたはずだ
というふうに書かれてますね 別に Perlは悪い言語だと全然思わないん
15:03
ですけども 個人的にはPerlとRuby どっち使いたいって言われたら
Ruby選びますね Rubyのほうが書いて いて楽しい言語だなと思うので
これは宗教問題というかJavaが好きな 方もいればCシャープが好きな人
もいてRubyが好きな人もいるという ところかなと思うんですけども
Rubyを作ることで世界がより悪 くなったと言われているとか そんな
Pythonの意をかるユーザーにRubyは 死んだと言われるのはちょっと
不本意というのが書かれています Python自体の開発をしている人とか
にRubyは良くないって言われる のはいいんだけれども 単純なユーザー
とかに言われるとちょっとイライラ するということが書かれています
これも分からないでもないですよね Pythonを作ったわけでもないし Python
のツールを作ったわけでもない 人たちからただ単に自分がPython
を使っているから そしてPythonの 方がRubyより人気が高いからという
だけの理由でRubyは死んだと言われる のはちょっと不本意なわけでどちら
かというとそういう人たちに対して 虎の意をかる狐というようなイメージ
を感じてしまうと なんか分かりましたね Rubyの価値というところをいくつか
挙げているんですけれども まず 生産性の部分ですね プロダクティビティ
が高いというところと コミュニティ が強いと さらに喜びを感じるという
ところを挙げています 実際開発 していて楽しい言語というのを
目指してRubyは作られているので その意味ではそれはよく感じる
というところがあるかなという 気がしますね 柔軟性が 言語仕様
として柔軟性が非常に高いという ところもあって Railsみたいな言語
ワークも登場したりとかしている わけで 別にいろんな可能性があって
言語ワークシステムがあっていい じゃんというか思うところはない
んですけれども そんな感じの記事 がRubyさんに上がっておりました
後編はまだあって これは後日公開 されるそうです では続いて こちら
18:02
の日経さんの記事 プロステック さんの記事なんですけれども タイトル
は楽天グループがオンプレ回帰 を決断 パブリッククラウドから
IT基盤を戻す狙いという記事が 上がっております こちらは楽天
グループが持っているプライベート クラウド バンクラウドを拡充して
グループ企業の各種基盤が用いる IT基盤の統合を進めているということ
が書かれています 結構意外だった のが これまでAWSとかを活用していた
ということなんですよね 組み合わせ てというふうに書かれてるんですけ
れども 楽天ぐらいの規模だったら やっぱり自社クラウドのほうが
より一歩の費用対効果は大きいん じゃないのかなという気がするんですけど
今後はオンプレとちょっと違和感 がありますけれども 自社クラウド
に プライベートクラウドに移行 していくということですね これも
当然とは当然な気がしますよね 国内外でデータセンターを作っている
と こんな記事が上がっていて ある
程度の規模になってくると自社の 基盤を持っていくというのは分からない
でもないかなという気がします よね かなりパブリッククラウドを
使っていると金額的には高くつく のかなという気がしますね 昔
DropboxとかももともとAWSだった のを自社クラウドに移管したり
とかしてましたし 意外なのはNetflix は未だに多分AWSに使ってるんですよ
どれだけの動画配信をするとAWS に使ってるとすごい料金になり
そうな気がするんですけど 確か 未だに使ってるような気がします
ね ちなみに海外にいると日本の サイト見るのがめちゃくちゃ重たいんですよ
してほしいですよね Yahooはヨーロッパ 圏内だともう今見れなくなっている
ので 結構ニュース事情に疎くなって しまうという問題がありますね
次なんですけれども こちらは 日本人がTwitterの移行先を作らないのはなぜ
21:03
と ゼンリーの移行先を22歳が作った事実から考える という記事が上がっております
まあTwitterね いろいろ大変だな と思うんですけれども そういった
中で受け皿になるようなサービス というのが登場してもおかしくない
のに なかなか日本語出てこない というところが疑問視されています
あとゼンリーに関してはNowNowという アプリが登場したらしいですね
Twitterから移行先としてミキシンの名前が 食べたりあがったりという事が起きている
とかいうのが書いてあるんですけれども それでもなかなかTwitterがすごく衰退する
みたいな事が起きていないという事ですよね
TwitterLikeの日本初のサービスだったり したんですけれども その跡が出てこない
というところが 2007年 今から15年前ですかね
Twitterに変わるサービスを開発した時の コストやリスクが先に立ち コシが重くなっていたりとか
さらに 自分感がないと 自分ごとにできていない というところがあがって
24:20
カメラを止めてですね 音声だけで 録画する形にしてみました
これで大丈夫かな 録画ができても 撮りが一番辛いんですよね
という事で 続いての話に入っていくんですけれども
この話題もなかなかいいですね
ITエンジニアの修正 貰った服を嫌だと思って着まくるを踏まえると
Tシャツを配るのが一番の広告 これが欲しいというのが
トギャッターの記事にあがっております
意外とTシャツ着てくれる方 多いんですね ありがとうございます
というところですけれども プログラマー3人で餃子を食いに行ったら
1人はインディードって書かれていた フーディを着ていたし
もう1人はデプロイゲートって書かれた Tシャツを着ていたので
これはマジです という風に書かれてますね
特に適度に長袖やパーカーを 混ぜてくれると嬉しいです
長袖のTシャツは競合少ない割に 出番がめちゃくちゃ多いのでおすすめです
クソダサフォント クソダサ配置ほど よく着てもらえる印象
オシャレなやつではなくて ダサくて寒いやつは何か無限に着る
面白いですね
パーカー配ったらずっと着てると思いますね
パーカーだと春、秋、冬と着るので めちゃくちゃ宣伝期間が長くなる洋服ですね
Tシャツだと夏のパジャマになるだけですもんね これは何かわからないですね
他に使い倒したものとしてはですね
ふかふかタオル、メガネ拭き、企業のロゴ入りだけど 有名なアウトドアブランドのバックパック
Tシャツ、エコバッグ、リュック、靴下は観測したから あとはパンツのシート
あとはポーチはパジで使うことが判明したので 宣伝グッズにおすすめです
27:02
企業の皆さんにいいことを教えますと
差別化のためにポケットに企業ロゴが入った ジーンズを配ったら
エンジニアに重宝されますよと
相当ですよね
完全に費用対効果を考えてない感じですね
一方でノベルティの靴下は珍しいので 印象に残るという風に書かれています
うちのトムギフトで靴下を作っていますね
逆に奥さんの立場
エンジニアの旦那さんを持ちの奥さんの立場からですね
うちの夫半分くらいワードローブが どこかからもらってきたロゴ入りTシャツなので
せっかく頑張ってユニクロ化しようとしているので
本当にシャツ配るのやめてほしいと書いてあります
ユニクロ化するのはいいかと思う
マイクロソフトとかパーカーを着てきた人が買ったな
あれ欲しかったと書いていますね
意外とTシャツコスパいいんですね
個人的に起きないんですけれども
意外と配れば来てくれる人はいるということですね
あとはどうなんだろうな
クソ傘の方が来てもらえると書いてあるんですけど
皆さんどうですかね
カッコ悪いやつを配るのはどうなのかなと思う
考えたい
基準とも内容ですかね
面白いな
ネトリファイのTシャツはもらって
あれはよく着てますけど
でも外には着ないかな
あとギッカーブのフーディはよく着てますかね
あれは外でも着るな
カッコよくないんですよね
ちょっとあんまりっていう感じのTシャツが多いので
これ着ないかな
普段使いできるような
ちょっと落ち着いたデザインのものの方がいいかな
といった記事がありますので
30:07
ぜひ皆さんご参考にしていただければと思います
続いて
GMO APS
ファシリテーションで意識していること
という記事があります
GMO Ad Partnersのテックブログ
こちらが
ファシリテーションをしないと
いろんな課題感があるというところで
時間内に結論が出なかったり
話があちこちに飛んだり
意見の対立が起こったり
解決しないとか話さない人がいるとか
そういった課題がある中で
ファシリテーションを意識していないと
思いましたというところで
意識していることとしては
逆のことですよね
スタートとゴールを決める
参加者が何を言おうとしているのか
理解に努める
論点を広げてから絞り込む
腹落ち感を持ってもらう
最後にトゥールを明確にする
というところを挙げていますね
オンラインオフラインに関わらないとは思うんですけれども
オンラインの会議の方が
複合しやすいんですよね
別のことをついついやっちゃう感じがするので
そうすると
喋る人はめっちゃ喋ってるし
喋らない人は全く喋らないし
会議としての目的を
失いがちなのかなというのは感じます
ちゃんとスタートとゴールを決める
あとは一人が喋らないようにする
というところですかね
あんまり喋らせすぎると
全然関係ない話に入ったのか
そこは気をつける必要があるのかな
という気がしますね
やってみた
やってみて感じたことというのが書いてあるんですけれども
最初は頭がパニックで話せなくなりました
今でも実施していること
実施できていないことがあります
参考にした書籍ですね
2つありまして
ファシリテーターを伸ばし組織を変える
というのと
ファシリテーションの教科書という書籍を
参考にされているんですけれども
その書籍の内容も
まだまだやることが盛りだくされて
反復練習をして慣れていこうと思います
ミーティングで感じた課題点が解消したかというと
完全ではありませんが
少しずつ改善していると思います
33:01
参加者が言わんとしていることの道筋を作って
質問しやすくすることで
意見の幅が出ていると感じています
というふうに書かれていますね
結構この記事は短いかなと思うんですけれども
多分ミーティングで課題感を感じている人というのは
他にもたくさんいらっしゃるかなと思うので
学ぶべきところがあるかなと思うんですね
続いてですね
こちらはITメディアさんのニュースで
マイクロソフト版ディスコード
ツイッターチームズのコミュニティ正式提供
という記事が出ています
チームズをコミュニティで使うというところですよね
どうなんだろうな
イメージが結構ついちゃっているので
開発者のコミュニティだけじゃないので
ここで上がっているのは何でしたっけ
PTAの連絡網とか
バイノリグループの予定調整などの利用を想定している
そのカテゴリーとしてですね
スポーツ 青年組織 ビジネス ボランティア 近隣などの
テンプレートが並んでいるということなので
そういうことなんでしょうね
多分開発者のコミュニティは
もともとターゲット外というところがあるんだと思うんですけれども
こういうスポーツとかビジネスは分からないでもないですけど
青年組織とかの人たちが
これまでチームズを使ったことがある人がいるんですよね
使ったことがないとまずイメージが湧きづらいような気はするんですけどね
チームズが私は
お呼ばれして参加しているミーティングぐらいしかないんで
普段のチャットとか使ったことないんですけど
一つのアカウントで複数の組織にまたがって活動できるんですかね
多分それができるからこそ
ディスコードとかFacebookグループっていう
競合としての名前が挙がっていると思うんですけれども
スラックとはその部分が結構違う感じですよね
スラックは全部分かれているので
非常に面倒くさいっていう感じがするんですけど
こちらの場合は一つのアカウントで
多分複数のコミュニティにまたがって参加できるんじゃないかな
という気がしますね
36:01
できるものとしてはグループのチャットと
一つはファイルや画像の共有
共有カレンダーでイベントを調整できるというのが変わってますね
一応無料で利用できるということですね
ディスコードは結構インターフェースが難しいので
ITエンジニアとかゲーム系の人とかですかね
よほど情熱がないとなかなか操作するのが難しいのかなという気がするんで
多分Teamsでのコミュニティっていうのは
もうちょっと分かりやすいというか
ITリテラシーがそれほど高くない人でも
使いこなせるインターフェースになるのかなという風には思いますね
ディスコードのシェアを食うっていう話にはならないような気がしますね
ではですね 続いてのニュースで
こちらはですね
Libsenseさんのエンジニアブログで
プログラマーに送る分かりやすい文章を書くための技法というのが挙がってるんですけれども
なかなかハードルが高いというかですね
まず一つ目が英語を勉強しようというところが書かれてますね
日本語を書く際にですね
主語とか述語とかをきちんと意識するためにも英語を学ぶと
さらに助手を助手に敏感になろうというのが書いてあって
いわゆるテニオファですねを意識して書くことによって
分かりやすい文章になるというのが書かれてます
あとは語字脱字はプログラムにお任せしようと
いわゆるテキストリントですね
その辺りを使おうというのが書いてありますね
最後のところに英語を勉強しろとか助手に敏感になれとか
一朝一夕ではどうにもならないことをたくさんお伝えしてしまいましたと
しかしこれらの観点を頭の片隅に入れた上で
チャットでもドキュメントでもブログ記事でも
自分の書いた文章を公開前にもう一度見直してみることが大事なのかなと思う
というふうに書かれてますね
その参考になる文章なんですが
あれなんですよね
一文が長いんですよね
文節を区切った方が
読み手も書き手も理解しやすい文章になるのかなという気はします
39:03
それによって短いセンテンスであれば
一番最初の書き始めたところと一番最後の部分で
こんな矛盾が生じづらくなるのかなという気はします
英語を勉強しようだとなかなかハードルが高いなという気はします
大事なポイントは英語とか云々というのではなく
大事なポイントもあるかと思いますので
リブセンさんのエンジニアブログを見ていただければと思います
続いてこちらは
ヒータの記事ですね
エンジニアサイドに技術的塞や設計を説明するノウハウ
というのが書いてあるんですけれども
これは本当に難しいですよね
技術的塞って本当に2000年くらいからあり続けたキーワード
もしかしたらもっと前からあったキーワードだと思うんですけれども
エンジニアだったら分かれると思うんですよね
でもそのエンジニアじゃない人たちに
技術的塞って何なのっていうのを説明するのって
本当に難しい気がするんですよね
ちょっとした修正とかも本当に時間がかかるようになるので
例えばUIの部分をテンプレートに切り出して
そっち側デザイナーのチームで作業できるようにすると
ちょっとしたラベルの変更はすぐ完了するんですよね
それに対して結果としては同じように
UIがちょっと変わるだけっていう変更をシステムチームに投げると
めちゃくちゃ時間かかるみたいな
なんでデザインチームはこんな簡単にやってくれるの
なんでシステムチームだとめちゃくちゃ時間かかるの
話がたびたび出てくるので
そういった意味で
技術的塞の説明の仕方っていうのは
本当大事なのかなという気がしますよね
この記事で書かれているのは
伝え方
まず設計が解決する課題やメリットを伝えると
長年にわたる機能追加や回収により
システム構造が歪になってきています
このため開発速度を出そうにも出せず
全体的に鈍化してきています
42:00
開発速度の鈍化はすなわち開発コストの高騰です
バケツに穴が開いた状態です
継続的に利益が減衰してしまいます
この設計は開発速度の継続的な向上に寄与します
顧客が喜ぶ新機能を素早く開発できるようになります
いわゆるリファクタリングに近いのかなと思うんですけれども
この中でちょっと気になるとしたら
その設計にどれぐらいのコストがかかり
リファクタリングがもたらす利益はどれぐらいなのか
なかなか説明しづらいというところですよね
新しいリファクタリングを行ったとして
新しい機能がどれぐらい早く実装できるのかというのが
なかなか明文化はできないので
ここを理解してもらえないとリファクタリングに
どれぐらいのコストを費やしていいのかというのが
理解してもらいがたいのかなという気はするんですよね
設計がなぜ必要なのかというところで
一番最初はきれいにできていると
キャビネットなどの収納を想像してください
本や文房具やおもちゃそれぞれ収納場所が決まっていて
整理して正しく収納されていれば
例えばおもちゃを取り出したいといったときにはすぐに取り出せます
また文房具の収納を改善したいといった場合にも
楽に整理できます
ただぐちゃぐちゃになった場合
それがどんどんシステムの改修で
機能が増えたり置き場所が変わったりとか
関連性が変わったりとかして
ぐちゃぐちゃになってしまったらどうなりますかと
文房具を取り出したくても探すのが大変ですし
取り出そうとしてもぶつかって
おもちゃが壊れてしまうかもしれません
またハサミが紛れ込んでいようものなら
探している途中にうっかり手を切ってしまうかもしれません
システムの内部構造は今このように散らかった状態なのです
そうですね
エンギン屋としては分かりますよね
こういう説明にならざるを得ないのかな
というのは分かるんですけれども
この説明をされてエンギン屋じゃない人たちは
果たして納得してくれるんですかね
なかなか難しいですよね
そういった意味ではなるべく外部サービスを使ったりとかして
コアの部分をなるべく小さく保ち続けるというところが
45:00
必要なのかなとは思いますかね
こんな話がどこかにあったんだけどな
ここに落としていないかな
これもKiitaの記事で
マイクロサービスとトランザクションという記事になります
ここではゲームサーバーサービスというところで作っている
マイクロサービスの話なんですけれども
マイクロサービスでは必ず課題に上がってくるのが
トランザクションになるということが書いてあります
これはすごい分かるんですよね
いわゆるDaaSと呼ばれるようなものだったりとか
DaaSと呼ばれるデータベースサービスとかで
API提供してたりとかすると
必ずトランザクションの話が持ち上がるんですけれども
マイクロサービスとトランザクションは
本当に相性が悪い
ご結合なのにそれを網羅して動いてほしいみたいな話があるので
非常に相性が悪いというのは分かるんですよね
そのGS2というところでは
スタンプシートという形で
独自のトランザクションシステムを用意するということですね
この記事とか読んで思うのは
結局これは車輪の再発明に近いんですよね
もうマイクロサービスではなく
普通のデータベースとAPIサーバー
アプリケーションサーバーという形であれば
別にトランザクションは気にしなくてもいいというか
普通にできることだったりするので
その意味でマイクロサービスの良し悪しがあるのかなという気がするんですよね
どうなんですかね
実際バースとかのデブレルのサポートとかしているので
このトランザクション周りって常に言われるんですよね
トランザクションを必要としないような仕組みを
アプリケーション側で考えて実装するというのが最善策になるんですけど
それもなかなか理解してもらいがたい部分かなというところもあったりするので
どうしてもデータベースを普通に使ったことがある人だと
マイエスケールでトランザクションを発行してデータ変更して
最後コミットしたりロールバックしたりって当たり前にできていることなので
48:00
それがなんでHTTPのAPIベースになるとできなくなるんですかっていうのは
なかなか分かってもらいづらい部分かなという気はするんですよね
確かでもファイアベースでトランザクションサポートしているような気がするんですよね
ファイアストアはトランザクションをサポートしていると
大きく2つの要素があります
複数ドキュメントの一括書き込みとドキュメントのロック
この2つだけなのかな
この記事は去年の記事なので多分そんな大きく変わってないだろうな
そのぐらいですよね
複数ドキュメントの書き込みはそこはそんなに難しくないと思うんですよね
気になるとしたら注文のデータを書き込んで
その時の注文IDユニークなキーを別のところに書き込むみたいな
そういう前の結果を受けて次の結果にそのデータを反映する部分っていうのが
なかなか難しい部分なのかなっていう気がするんですよね
それができればベストだと思うんですけど
難しいですよね
ファイアベースってどのぐらいなのか
分からないでもない
マイクロサービスとトランザクションの相性は個人的に良くないなっていう気がするんで
なかなか難しいですよね
ベルカリさんとかかなりマイクロサービス化が進んでるんで
どの辺りどうやってるんですかね
注文されると1品物しかないので
複数の人が書き込んだときの入ったロックとか
必ずできないといけないんでなかなか大変です
商品が買われたってなると
その買われたユーザーの方の情報も更新されるし
買った方のユーザーの履歴にも追加されるみたいな感じが多分あったりするんで
そこのトランザクションとかこうやって実装してるんですかね
ではですねあと1つぐらいいけるかな
あとは今話題のTwitterですね
51:05
Twitterはいくつかあるんですけれども
まず1個目がTwitterがキューミーアカウント15億を削除しユーザー名を開放へと
長期間ログインなしの利用者は注意という記事が上がっております
実際かなり個人的にはいろんなTwitterアカウントを持っている気がするので
これやると昔のやつとか結構整理されそうかなという気はしますね
もちろんこのDevRelTokyoのアカウントとかは普通にログインしてるんで
これが消えるっていうことはないんですけれども
消えそうなやつ消えそうなやつ消えそうなやつなんだろうな
RGとか言うのがあるよくわかんない
クライアントのやつですけど多分消えるだろうな
クライアントさんもメンテナンスしてないので
でもそれぐらいかな1つ2つぐらいかな
消えそうな予感はするアカウントは
Twitterのアカウントってアカウント名変えられちゃうので
そうすると前の人が作った黒歴史も受け付ける可能性があるので
なかなか怖いですよね
一応検索してから使うようにした方がいいんじゃないかなという気はします
というところで今日のメインテーマですね
そちらに入っていきたいんですけれども
今日のメインテーマはコンテンツですね
先週行動であの後2件ぐらいいただいてたんですよね
すみませんね取り上げられればよかったんですけれども
録画放送というところもあって取り上げられなくてですね
また今日も多分もしかしたらこの後書いてくださるかもしれないですけれども
すみませんそちらもですね取り上げられないというところで
今日はですね1件だけいただいておりますので
そちらを取り上げていきたいと思います
ではですねデブレルネーム虫から来た馬面の男さんですね
いつもありがとうございます
虫から来た馬面の男はエンジニアの中途採用活動をしており
今年2022年は自社の魅力を外部のエンジニアに届けるコンテンツ作りという観点で
54:06
ブログの執筆に励みました
企業とエンジニアの間で良好な関係性を構築するデブレルは
採用活動にも適用できると考えております
自社の優秀なエンジニアをアピールしつつ
スキルアップなど成長機会やオフィスの雰囲気
働き方の自由度がある点などブログ作りをしました
日々の業務の中ではなかなかブログ執筆が進まないので
チームで執筆合宿を行ったりしました
合宿といっても実際には宿泊せず
1日缶詰になって執筆する活動です
執筆はGitHubを用いて行い
フィードバックは現場のエンジニアからもらいながらブラッシュアップしていきます
虫から来た馬面の男の所属会社は
エンジニア界隈では知名度が高いわけではありませんが
コツコツとコンテンツ作りに励んで
少しずつ認知を獲得していきたいと思っています
長くなりましたが以上ですというふうにいただいています
ありがとうございます
そうですね
日本だけではないと思うんですけれども
採用活動に対してDevRelの考え方は使えると思いますね
DevRelアジアだったかな
ロシアのピザ屋がなんでDevRelをやるのかみたいな話は
結局のところ優秀なエンジニアの
ハイアリングをつなげていきたいという考えでやられていたりするので
それと共通する部分はあるのかなという気はしますね
なかなかブログ執筆が進まないというところで
強制的に缶詰になれるような執筆合宿も行っていたということですね
これも必要ですよね
なかなかアドベントカレンダーとかもいい機会だと思うんですよね
強制的にアウトプットに参加しないといけないみたいな雰囲気があるので
そういった意味でいい機会なのかなというのは確かに感じるところがありますね
この中で気になる部分としては
今はリモートワークがとても増えているので
優秀なエンジニアをアピールしつつスキルアップなどの成長機会や
オフィスの雰囲気、働き方の自由などがある点をアピールするのが
なかなか難しくなっている部分があるのかなという気はするんですよね
特にオフィスの雰囲気ですかね
昔だったらかっこいいオフィスで働きたいというのが
結構プラスポイントだったかなと思うんですけど
今なかなかオフィスに出社すること自体を
57:00
良しとしない文化もあったりするので
ここの部分がなかなかハンドリング難しいのかなという気はしますね
自社の良さというのをどう出すかというのは
結構テクニックがいる部分なのかなという気がしますね
ありがとうございます
では本日のDevRelラジオの92回目ですね
これで終了していこうと思います
イベントのご案内で
まずDevRel Meetupが来週の月曜日あるんですが
全然集まっていなくてですね
ぜひぜひ来週の月曜日19日ですね
ご参加いただければと思います
やるのはパーポカラオケ大会をやろうと思っていますので
お時間ある方はですね
ご参加ぜひお願いいたしますと
あとはDevRel Japan Conferenceですね
こちらは3月の10日11日にやりますと
DevRelコイン横浜2023と同時開催となっておりますので
ぜひぜひそちらもご参加いただければと思います
というところで本日のですね
CFPプロポーザル今絶賛募集中なので
DevRel Japan Conferenceは日本語で大丈夫ですし
DevRelコイン横浜の方は英語のプロポーザルを
ぜひお送りいただければと思います
ということでですね
本日のDevRelラジオ92回目は終了していこうと思います
皆さんお聞きいただきありがとうございました
また来週はですね
多分日本からお送りできると思います
では皆さんまた来週お会いしましょう
さよなら
