1. DevRel/Radio
  2. DevRel/Radio #91 〜今年の思..
2022-12-07 59:47

DevRel/Radio #91 〜今年の思い出(コード編)〜

00:03
皆さんお疲れ様です。夕方5時半になりました。DevRel Radioの、今日は91回目ですね。やっていきたいと思います。
多分今は12月6日なんですけれども、私が海外にいる関係で、この時間はDevRelコンプラ波の2022でスポンサートークがあるんですけれども、
それの登壇待ちをしているぐらいなのかなというところですね。
さっき見た感じだと時差が7時間だったかな。7時間だったかな。嘘かもしれない。確か8時間だったかもしれない。
8時間ですかね。8時間あるので、5時半、17時半ってことは、9時半ですかね。
9時半ぐらいなんで、多分11時ぐらいから確か5分ぐらいのスポンサートークのはずなので、それの準備をしている頃じゃないかなと思います。
なので、あんまりちょっと余裕なさそうなんで、今回は録画にしてみます。
ということで、DevRel Radioなんですけれども、こちらはDevRel Meetup in Tokyoというコミュニティでやっているネットラジオになります。
毎週火曜日の夕方5時半から1時間やっているんですけれども、DevRelに関することだったりとか、
イベントのご案内とか、皆さんからのテーマに合わせたコメントなどを共有したりとかしています。
今日のメインテーマが、今年の思い出コード編というふうになっているんですけれども、ご意見がなかったんですよね。
いつもだったらですね、意見ないんでぜひ今のうちにくださいって言えるんですけれども、
いかんせん、これ録画なので、録画なので集めようがないというところですね。
なのでどうしようかな、結構答えづらい質問だったのかなという気もするので、
全力でスルーするか、それとももう一周これをやるかというところなんですけれども、
もともとうちで提唱しているDevRelの4Cっていうキーワードがあって、
03:01
コードコンテンツ、コミュニケーション、あとコンダクターというところで、
12月の4周でちょうどいいなと思っていたので、
多分コードをもう1回やっちゃうと1個あぶれちゃうので、やらないほうがいいのかなと思っております。
ということで、今日はですね、DevRelのニュース中心になるかなと思うんですけれども、
まずDevRelのほうですね、DevRel Meetup in Tokyoは、
DevRelっていうのは開発者、自分たちのサービスと外部の開発者との良好な関係性を築くためのマーケティング手法というところで、
DevRelに関する知見をですね、共有したり相互にコミュニケーションしたりするのがDevRel Meetup in Tokyoとなっております。
毎月イベントをやってるんですけれども、今月はですね、本当は明日12月7日なんですけれども、
これも全く続きません。私が日本にいないということで、今度は19日ですね。
19日にやろうかなと思っております。
ちょっと忘年会的なシーズンでもあるんですけれども、予定してますので、ぜひ参加いただけると嬉しいです。
ということで、あとはDevRel Meetupのツイッターアカウントですね。
アットマークDevRel Tokyoというアカウントでやっております。
Facebookも同じアカウント名ですね。
Twitterの方はハッシュタグ、シャープDevRelJPというのでやっていますので、ぜひフォローなり、いいねなりいただけると嬉しいです。
そんなところかな。
あとは公式サイトですね。DevRel.Tokyoというサイトがありますので、そこからイベント情報をチェックしたりとか、
あとは公式のスラックの方に参加することもできますので、ぜひご利用くださいというところになります。
ということでですね、近況から言うとですね、
今日、プラハに着きましたと。
日本時間の日曜日の夜10時、11時くらいですかね、出発して、そこから片ある航空でイスタンブールに行って、
イスタンブールでトランジットがあって、チェコのプラハというところですね。
そちらに着いて、そこからバスと電車に乗り継いで、中心街の方に行ってですね、お昼食べて、それからホテルに来たというところになります。
このプラハという地域自体はですね、今年の夏にも来たんですよね。
06:02
夏にヨーロッパ、知り合いをコミュニケーション求めてですね、いろんなところに行ったんですけど、
その時の2番目に行ったところから、一番最初オーストリア行ってその後プラハだったんで、
その時はオーストリアのウィーンというところからプラハまで電車で行ったんですけど、
それ多分4時間ぐらいだったかな、行ったんですけど、今回は飛行機なんで、
イスタンブールからプラハまで3時間ぐらいですかね、多分。
全然速さ違いますよね。やっぱり飛行機楽だなっていう気がしましたね。
結構隣の人がでかい人で、みっちりしながら揺られてたんですけど、
それはありつつも、飛行機の方がやっぱり速くて楽ですね。
イスタンブールは2回目っていうところもあるんで、電車とかバスとかの乗り方は随分慣れているというか、
全然問題なく移動できるんですけれども、言うても1日チケットみたいなのがあって、
いくらだったかな、そんなしないですね。
多分120通貨単位よくわからないですけど、チェコなんとかみたいな、
そんなようなCKZって書くやつあったかな、そんな通貨単位があるんですけど、
それで120くらいのやつですね。
5円くらい、その1CKZっていう単位がだいたい5円くらいなんで、
120円ってことは600円くらいですかね。
600円くらいで1日24時間、電車乗り放題、バス乗り放題、
路面電車とか乗り放題みたいなそんな感じのチケットがあるんですけど、
それ買っちゃうのが一番楽かなっていうところですね。
もうちょっと安い30分のプランとか90分のプランとかもあるんですけど、
ツアリストはそっちの方が楽かなと思ってそれ買っちゃってますね。
それ買っちゃえば移動はすごく簡単で、
Googleマップで調べれば行き方とかちゃんと出してくれるんですごく楽です。
そんなプラさんの街で今クリスマスマーケットがやってるらしいんですけれども、
どうもあんまりこんな感じには見受けられなかったんですよね。
お昼を食べたところの目の前あたりがそういうクリスマスマーケットやってるはずの場所なんですけど、
あんまりそんな感じはしなくて、
この後スポンサーとかスピーカーを交えたディナーがあるんで、
09:03
そこがもしそっちのクリスマスマーケットの方だったらまたちょっと夜見てみようかなと思ってます。
ただクリスマスのコスプレしてる人たちがいて、
レストランに時々入ってきてみんなで写真撮ったりとかしてたんですけど、
女の人2人は天使の格好をしてたんですよね。
男の人1人がキリスト教の司祭というか、
サンタクロースじゃないんですよね。
サンタクロースになる前の聖人としての人みたいな感じの格好の人がいたりとか、
鎖すごいつけて尻尾長くて全身真っ黒みたいな、
そういうキャラのコスプレした4人組ですね。
それが街中を結構徘徊してて、みんなが写真撮ったりしてたんで、
多分クリスマスに関係したキャラなんだろうなと思ったんですけど、
全然そういうのは全然よくわかんないっていう感じでしたね。
そんな感じでとりあえず1日目なんですけれども、
明日からカンファレンスですね。
明日初日でうちのスポンサートークとかもあって、
明後日もカンファレンスというところですね。
そんな感じの2日間カンファレンス予定となっております。
デブレルコンプラ2022ですね。
このホテルに泊まってる人がデブレルコンに行くっていう人で、
声かけられてわからなかったんですよね、誰だか。
あれスピーカーなのって聞いたら、
いや、ちょっと数週間前に行こうと決めたから今回はアテンディーなんだよねって言って、
ただオンラインの時にスピーカーだったって言ったんですよね。
それがデブレルコンのディープダイブとかの話なのか、
それともデブレルコンオンラインでやった時、全体でやった時の話なのか、
はたまたデブレルコン東京の2021の話なのかみたいな、
ちょっとそれがあやふやなんですけれども、
一人同じホテルに泊まっていたというのが発覚しました。
12:00
自分のカンファレンスじゃなかったらいいんだけどなって思ったりしたんですけど、
よくよく考えると、向こうがこっちを知ってるってことは、
自分のカンファレンスだったんじゃないだろうかって、
それなのに名前とか全然分かってないっていうのは、
すごい申し訳ない気持ちになるんですけれども、
そんな方もいらっしゃいましたね。
明日からカンファレンスは普通に楽しもうかなと思っております。
ということで、さっきもお伝えした通り、
今日のメインテーマのほうは特にレスポンスがなかったんで、
ニュース周りですね。
その辺りをいくつか紹介していこうかなと思うんですけれども、
まず最初がAWSのリイベントがやっていて、
やっていてというか一応もう終わってですね、
日本にみんな参加者の方戻られてるんですけれども、
その中での発表で面白そうだったのがですね、
これはパブリックキーさんの記事で、
AWSのSIR世界一に日本のクラスメソッドが選出と、
アジア太平洋ではアイレットが選出と、
クラウド専門のSIRがリードする、
クラウドのSIRビジネスという記事が上がっております。
クラスメソッドさんおめでとうございますというところなんですけれども、
このAWSパートナーというところで、
すごく日本が躍進しているというところですかね。
これの元記事のほうを見るとですね、
クラスメソッドさんはSIパートナーズオブザイヤーというので、
名前が挙がってますね。
他に挙がっているところとしては、
スラロムという会社ですね。
ここはスラロムとこれか。
シアトルに本社を持つグローバルコンサルティングファームのスラロムというのが挙がってますね。
コンサルティングということですね。
コンサルティングをやりながら、
多分開発もやっているというところかなと思うんですけれども、
あと挙がっているのが、
中国もありますね。
ちょっと読めないんですけれども、
15:01
あとはラテンアメリカ系としてはコンパスUOLとか、
エミアではリプライという会社は挙がっていますね。
このSIというジャンル、
SIパートナーオブザイヤーというところで選出もされているので、
きちんと認知されてきているのかなという気がしますね。
DXとか内製化みたいな文脈でいくと、
そういうSIは任せにしないで、
システムをインハウスで開発していきましょうみたいな感じの流れは、
確かにあるんですけれども、
そんな中でもこういうクラウドインテグレーターという存在ですね、
そのあたりが注目を集めていくというのは、
なかなか面白いトレンドになるんじゃないかなと思うんですよね。
これがもしもっと認知されるようになっていくと、
日本がいろんな世界で活躍できる要因になってくるのかもしれないなという気はするんですよね。
ちなみにクラスメソッドさんとかで言うと、
開発をまるっと全部受託するというよりは、
お客様と一緒に伴奏して開発を進めていくタイプのSIというお話を聞いたことがあるので、
そういった意味では、
旧来型の開発とか運用まで含めて全部受けますみたいな感じではないんですよね。
そういう伴奏型のSIとかは、
今後ますます伸びてくると面白いかなという気がしております。
クラスメソッドさん、アイレットさんおめでとうございます。
続いて、こちらは記事としては、
AI for ProRequestという新しいGitHubの機能ですね。
どんどんAI化していくというか、
総数の変更点をAIで見つけて、
それでProRequestを書いてくれるんじゃないかなという気がするんですよね。
PRBotHowって書くと、
PRBotが何が変更されているかみたいなものもきちんと記述してくれて、
18:00
さらにPRBotSuggestって書くと、
変更されているところもちゃんと書くし、
ちゃんとファイル一覧作りつつ、
それがどのコミットで変更されているかみたいなものとかも、
リンク付きでちゃんと出してくれると。
そういうことね。
どのぐらい人が書いてくれた的にやるのかなと思ったら、
そういうのも確かにあると思うんですけれども、
きちんと変更されたファイルであったりとか、
変更点とかにちゃんとリンクを付けてくれるっていうのがあるみたいですね。
これは面白いですね。
ディスクライブとかやってもちゃんと書いてくれたりとかしますね。
適当なプリクのメッセージとか、
受ける方もレビューする側もすごく大変だと思うんで、
確かにこれ結構便利そうな気がしますね。
どんどん機械学習のプログラミングに関する機械学習分野って、
広がってきてるなっていう気がしますね。
ということで、続いてなんですけれども、
こちらはKiitaの記事ですね。
エンジニアのやる気をそぐ会議術というのがですね、
これはNUCOっていう会社なのかな。
NUCOってことはないかな。
読み方が書いてないな。
読み方書いてないのでわからないんですけど、
NUCOは猫のマークですね。
猫にかけてNUCOだと思うんですけど、
AI機械学習を利用したシステム開発やコンサルティングセミナーなどを
行っている会社さんらしいんですけれども、
そこの会社さんのですね、
アドベントカレンダーの記事というところで、
NUCOアドベントカレンダーの中でですね、
やる気をそぐ会議術と、
これは明らかに反面教師ですよね。
こういうことをやると、
エンジニアのやる気がなくなっちゃうよというところで、
こういうのをやらないようにしましょうというところだと思うんですけれども、
その中でですね、入門編と応用編というのが上がってますね。
まず入門編、会議に参加する人数を増やす。
人海戦術は会議においても有効である。物量に勝る暴力なし。
21:06
会議の参加者が多ければ多いほどエンジニアに、
これって俺いなくてもいいんじゃと思わせることができ、
徐々にマジックポイントを削る効果が期待できると。
確かに確かに。大抵でも10人は用意。
オンライン、オフラインももちろんですけど、
オンラインで10人の会議とかも、もはや意味ないですよねって思いますよね。
あくまでもこのテクニックの肝は、
本当は開発のタスクに当てられた時間を無駄にしてしまった感を、
エンジニアに与えることであるということが書いてありますね。
さらに念のため読んでみる。これも簡単にできるテクニック。
これもやだね。何々さん、とりあえずほにゃらラビのミーティング、
参加してもらっていい?とりあえずっていうのが嫌ですね。
知ったことがあってもいいですよね。
さらに内容を事前に伝えない。これもだめですね。
何日から打ち合わせの時間をもらえるとだけ伝える。
何のために時間を取られたかわからない。
エンジニアにはストレスが生じる。
事前に何を準備すればいいかわからないし、
そもそも本当に自分が参加すべき会議なのかもわからない。
招待不明の何かに貴重な限られた業務時間を奪われるという
感覚が不快であることは想像に難くない。
この時、何の件ですかとエンジニアに尋ねられても
絶対に詳細を話してはいけない。これはひどい。
これは本当にひどいですね。
さらに多めに時間を抑える。
理想は2時間以上加工できるといい。
こんな会議屋ですね。
1日1回の会議で2時間とかも本当に腹立ちますよね。
1時間でも嫌になりますからね。
昔のオフラインの会議ってよくわかんないですけど
必ず1時間会議室を抑えてたと思うんですよね。
あれ本当に無意味だよなと思ってたんですけど
なぜか1時間抑えるんですよね。
1時間抑えると1時間使い切らなきゃいけないって思う人が出始めて
会議が全体的に無駄な時間になっていくっていう気がするんですよね。
あれもオンラインになっても
うちの場合初見のお客さんとかだと30分とかにしてますし
何だったらもう15分でもいいんじゃないみたいな感じで
打ち切れるときはどんどん打ち切っちゃうような感じなんですけど
24:03
普通のお客さんのクライアントのミーティングとかでも
早めに打ち切れそうだったら早めに終わらせちゃうみたいな方が
お互いにとってもいいのかなと思って
普通に1時間とかやらずに終わったりするんですけど
例えばウェビナーとかオンラインのイベントとかあったときに
なぜか30分前からその件に関して打ち合わせをする時間を設けるとかですね
いやいやそんないらなくねみたいな
そこで話すことをドキュメントにしてとか
チャットで共有すればいいんじゃないかなみたいな気がするんですけど
なぜかオンライン会議好きの人が一定数いるんですよね
あれもまたつらいなっていうところがあって
個人的にはなるべくお断りしようっていうところでやってるんですけど
そうですね
某ウェビナーの会社
ウェビナーを専門で今やってる会社さんとか
本当オンライン会議好きなんですよね
何かあると会議しましょうみたいな感じで送ってきて
いやいや全然興味ないんでいいですって感じで
もうメールすら返さないみたいな感じになってるんですけど
そういう会社さんとかあったりしますね
応用編ですね今までのは基本編というところで
何度も同じ説明をさせると
確かに何度も繰り返し
すみません今の説明もう一回してもらってもいいですかと聞くのは簡単だと
しかし同じミーティングの中で何度も同じ質問をしてしまうと
頭の悪いやつに見えてしまうと
それは損だと
これ何でしょうね
普通にやってても頭悪いなこいつって思いますけど
今回ご紹介するのはもっとロングスパンで行うテクニックであると
エンジニアに技術的な質問を投げかけると
ここってどういう処理になってるんでしたっけというような質問でいいと
その場では分かったように振る舞う
この時本当に分かっていなくてもいい
何なら本当に分からなかったらもう一度聞いてもいい
その会議はそのまま終えると
またすみませんこの間説明してもらったと思うんですが
ここの処理どうなってるのかもう一度教えてもらってもいいですかと聞くということですね
これは何でしょうね
エンジニア側にも問題があるかなと思うんで
ドキュメントにしておくっていうのはまず大事ですよね
あと会議を録画しておいたほうがいいですね
27:00
この間説明したことであったら
そもそも動画のURL見直せばいいんじゃないっていうところがありますし
ちゃんと議事録をつけるようにしておけばですね
こういったくだらないところは回避できるかなという気はしますね
あとはどう考えてもいらない資料を作らせる
これ本当ひどいですね嫌がらせですね
これはひどい
事前に資料を配った上で当日資料を読み上げる
これね実際いますよねこういう方
本当に意味ないじゃんって思うんですけどいますよね
読むだけだったら別にその人が読む必要ないって思いますけどね
そしてあとはコマ切れに会議を設定すると
スイッチングコストですかね
やっぱり集中を急がれるような感じでやられると
それはそれで嫌かなっていう気はしますかね
1時間ごとぐらい分けて会議を設定するみたいな
まとめのところに書いてあるんですけれども
これはあくまでもネタですよというところですね
これはアンチパターンであって
これを反面教師としてやるというところになるかなと思います
というふうに書いてあります
これ本当にこうポエムもいいところなんで
ヒータンに載せてていい記事なのかちょっと怪しい気もするんですけれども
そんな記事が上がってますね
ちょっとタテグのコメントとかどうなってるんだろうな
叩かれそうな気がするんですけど
デブのコメントで
一番人気のコメントは
昼時に設定されるのも嫌だなと
勝手にランチミーティング開催して
俺の昼休み奪うなよって
ネタとはいえ会社の名前を出している記事で
コロンビアとかの権利関係がまずそうな画像を使うのも
エンジニアのやる気そぎそうですけどとか
よくこれで応募フォームへの誘導できるなとか
これあれですね
ちょっと全体的に会社にとってはネガティブな印象になっちゃってるような気がしますね
30:05
私もこれを見て
この会社がいい会社には思えないかなと思いますかね
このあたりは注意した方がいいと思いますね
では続いてですね
こちらはメタバース関連なんですけれども
mog.liveさんの記事ですね
VTuberとメタバースに革命とモバイルモーションキャプチャー
もコピー
最速体験レポート
多分もコピーでいいと思うんですけれども
ソニーさんが作ったモバイルモーションキャプチャーデバイスですね
多分6つバンドを付けると
両足両腕あと腰頭に装着して
それだけでモーションがキャプチャーできるようになると
昔は映画とかだとあれですよね
すごく広いスタジオで
それこそ全身スーツみたいなのを着て
それでモーションをキャプチャーしてたと思うんですけれども
それのもっと簡易版というか
多分補足は全部機械学習でやってるのかなっていう気がするんですけれども
それを使うことでモーションキャプチャーができるようになると
実際これ率直な感想を述べると
めちゃくちゃ精度がいいの一言につきますと
担当者のハツラツとした動きが
アバターに見事に反映されていましたという風に書いてありますね
下手すれば専用スタジオで収録しているのかと
ミマゴーレベル
すごいですね
さらに体験会場をぐるぐる一頭一周したり
客の果てには部屋から出て猛ダッシュしたりしても
動きをしっかり検知できているほどですと
トラッキング範囲は無限かと
頻繁するほどの自由な動きが
アバターへしっかり反映されていましたと書かれてますね
さらにVRチャットと連携することもできるということですね
この場合オキラスでやっているんですけれども
メタクエスト2単体でのフルトラッキングが
しっかりと成立しているというところも
驚きが隠せませんと書いてありますね
面白いですよね
33:00
このデバイス結構いろいろ可能性があるのかなと思っていて
こういうVRチャットみたいなものもそうですし
VTuberみたいなものも多分ありますし
いろんな使い方ができるのかなと思ってますね
結構高いんですかね
価格は約5万円
そんな高くないですよね
バンスとかやるっていうレベルじゃなくても
こういうVTuber系の人とかは
あるんじゃないかなという気がしますね
外でも屋内でもどこでもモーションキャプチャー
これはどうなんでしょうね
多分アプリと連携する形なんで
そこの通信とかキャプチャーする人とか
必ず現れるんじゃないかなという気がしますね
ソニーが提供するコピーレシーバープラグインを用いれば
リアルタイムにUnityやモーションビルダーなどの
外部ソフトウェアに送信可能
このプラグインがあるんですね
Unityと連携することができると
あとモーションビルダーですかね
この辺りを多分解析すれば
いろんなソフトウェアで使える可能性ありそうですね
いろいろ可能性広がりそうな気がしますね
次がこれもちょっと面白いんで
これはポクツナカンというIDの方のブログ
ポクツナカンというサイトなんですけれども
そちらのブログの方で
なぜ今もGoogle App Engineを選ぶのかという記事が書かれています
みんななぜかクラウドランに行ってしまうと
確かにクラウドランの方が新しくて
公式に露出が多いし
GAEはランニングページからの言及も消えているので無理はない
Googleクラウド的にもあんまり使ってほしくない雰囲気が漂っている
これはひどいこれはひどいですね
でもそれでも使っているというところで
なんで使っているのかっていうのを紹介してくれてますね
App EngineはGCP最初からあるサービスで
36:02
今年で14年目になるらしいということですね
確かにGoogleのクラウドサービスで
ほんと一番最初に出たのってこのApp Engineですよね
一番最初はPythonだけでしたっけね
多分Pythonだけですよね
その後Javaも対応したのかな
最初からJavaもあったのかな
ちょっと忘れちゃいましたけど
Javaが動くようになって
その時にJRuby使っているRuby on RailsをApp Engineで動かすみたいなのが
ちょっと流行ったというか
注目を集めたりとかした覚えはあるんですけれども
今ってどうなっているんですかね
Googleにしては珍しいですよね
14年もやっているサービスって
彼らだったら2,3年で諦めてやめそうなもんですけど
まだにやっているというところですね
言語としては現在はNode.js, Java, Ruby, C Sharp, Python
またはPHPのアプリケーション構築ができると
十分ですよね
これだけの言語を対応してくれれば
どうなんですかね
昔は結構いろいろ癖があったかなという気はするんですけど
今はどうなんだろうな
だいたいヘロクと同じぐらいの雰囲気で使えるんですかね
何ができて何ができないのかっていうのが
ちょっと分かりづらいところはあるんですけれども
それでも14年間続いているということですね
ここで書かれているのが
静的なファイルを配れる
エッジキャッシュが使えるという利点が書かれています
GAEでは静的ファイルのパスをapp.yamlに指定することで
静的ファイルをGoogleのエッジサーバーでキャッシュさせつつ配れる
というふうに書いてありますね
さらにアイデンティティアウェアプロキシーが
ロードバランシングなしに使えるということも書いてありますね
そうなんですね
確かに昔GAEでアプリケーション作ったときに
Google認証を簡単に使えるみたいなのがあったような気がしますね
39:00
管理画面や社内用アプリケーションを作る際に
よく利用するっていうことが書いてありますね
さらに今はApp Engineにロックインされないと
これ知らなかったですね
昔はローカルの開発時にDevOpsコアップサーバーとかいう
よくわからんスクリプトを使う必要があったり
外部にHTTPリクエストを送るのに専用のURLフェッジライブラリを使う必要があったり
ライブラリを自由に入れられないので
自分でアップロードしてインポートパスを通したりする必要があった
ロックインされるし開発体験が良くなかった
昔GAEを触ったことがある人のGAEに対する悪印象は
だいたいこの辺りから来ていると思う
でもセカンドジェネレーションになって
これらの制約はなくなった
普通に書いたWebアプリケーションはそのまま動く
ファーストジェネレーションは独自のサンドボックスで
ユーザーアプリケーションを分離していたのと
ユーザー認証からデータストアタスクQまで付いた
オールインワンのアプリケーション実行環境として提供されていたのもあって
専用ライブラリ使ってねとしていたのだと思う
ただ現在のセカンドジェネレーションは
それらGAEにバンドロスされていたサービスは
各Googleクラウドプロダクトを利用して実装する形になった
App Engine特有の実装も不要になり
脱出も良い つまり安心して使えます
そうなんですね これはいいですね
Googleさんのサービスなのでね
いつ何時どうなるかちょっと分からないところもあったりするんで
別の選択肢がちゃんと用意できるというのは
いいとこですかね
この記事の中にあるの面白いのが
ランタイム選択フローチャートっていうのがあってですね
どういう時にGAEを使うのかみたいなのが書いてあるんですけれども
大半のユースケースではApp Engineにたどり着かないということですね
まずHTTP系であるのは当然というところですね
さらにKubernetesが必要
または設定によるハードウェアが必要かどうか
ノーの場合ですね それは不要ですと
Kubernetesいらないよっていう場合は
42:01
SAMLanguage and System Libraryはそれも必要じゃないよと
サポートされている言語が限定的ではあるんですけれども
そこに当てはまる場合は
We need to deployment
これはちょっと分からないんですけれども
それによってデプロイメントしたいものが
アプリケーションだった場合にApp Engineがいいんじゃないみたいな感じで
かなり奥深い選択肢になっちゃってるっていう感じではあるんですよね
確かにクラウドファンクションかApp Engineかみたいなところで
選ぶかどうかというところが分かれていると
結構複雑ですね
どういう時に選ぶべきかっていうのが分かりづらいかもしれないですね
この方の場合はまずGAEで動かせないか検討して
言語がサポートされていないとか
追加で何かインストールしないといけないみたいな
例えばイメージマジックがいるとかっていう場合は
クラウドランを選択しているということですね
そういうのがなければ
App Engineを採用していくということですね
過去にはやや複雑化してきたクラウドファンクションを
GAEに置き換えたりもしたと
GAEはゼロ台までダウンスケールできるし
起動も早いし新しいバージョンをリリースする際に
段階的にトラフィックを移したり
前のバージョンに戻したりも楽ちんと
クラウドランもいいんだけれども
クラウドファンクションでできていた程度のものの
イメージを管理したくないという判断もあったと
クラウドファンクションジェネレーション2は
側だけで中身はクラウドランなので
今ならクラウドランを選択するかなと書いてあります
GAEはプロトタイプの開発にも向いていますということですね
こういう選択肢をきちんと明朗に書いてくれる記事って
結構貴重だと思うんですよね
特にAWSもそうだと思いますし
GCPも選択肢がいろいろあって
どういう時にどういうのを選べばいいんだろうみたいなのが
本当に分かりづらくなっていると思うんですよね
何でもファースにしようとか
マイクロサービスにすればいいじゃんみたいな流れがあるかなと思うんですけど
前にGitHubがマイクロサービス化したのが
結構いろいろ間違いだった部分もあるみたいなことも
言っていたりとかした記事もありましたし
じゃあモノリシックにやるんだったら
45:01
それどこで管理するのがいいのかとか
アプリケーションの課題感っていろいろあると思うんで
こういう意見が出されるととてもいいなと思いますね
そんな記事が上がっておりました
そんなGitHubでちょっとやらかしちゃったのが
これはITメディアさんの記事ですね
ソースコードを書くのは単純作業
GitHub日本法人の記事が物議と
橋本の大和運輸
誤解を与えてしまったという記事が上がっております
元々の記事が
今修正はされてるんですけれども
元々の記事は
これからはアーキテクチャのデザインや
GitHubを活用したソースコードのガバナンス
標準化が実行可能なメンバーによる
コアな開発は内製化し
ソースコードを書くなど
単純な作業は外部に委託するなど
柔軟な対応が必要です
ここの部分ですね
この部分のソースコードを書くなど
単純な作業はっていうところが
引っかかったということですね
それがですね
本当に言いたかったことではないということですね
山田運輸に取材したところ
当社としてはソースコードを書く作業が
単純作業とは決して考えていないし
そういった趣旨で発言をしたわけではないと
記事間にあたり一部の発言内容が正確に伝わらず
結果的に誤解を与えてしまったということですね
ここの修正の部分なんですけれども
今後はアーキテクチャのデザインや
GitHubを活用したソースコードのガバナンス
標準化が実行可能なメンバーによる
コアな開発は内製化しつつ
短期的にリソースが足りない場合は
外部に委託するなど
柔軟な対応が必要になります
というふうに書かれてますね
元々の内容と比較すると
ソースコードのガバナンスとか標準化が
実行できるメンバーによる
コアな開発は内製化します
ただその後のソースコードを書くなど
48:01
というのは確かに
ちょっとおかしいっちゃおかしいですよね
元々コアな開発は内製化する
というふうに書いてあるわけで
その後のソースコードを書くというのは
当然コアな開発も含まれる
出来どころではあるので
これは多分インタビューを受けて
書いたテクニカルライターの
知識不足だったと思うんですけれども
ただそれをGitHubに載せちゃダメですよね
GitHub側のチェックが
ちょっと甘かったかなという気がしますかね
これに対しても
多分マツダで色々書かれてたみたいなんですけれども
エンジニア寄りのはずのGitHubが
こういう記事を平気で上げてしまうのが不審感
Twitterもそうだけど
結局日本法人はキラキラ営業&広報部門でしかないのかな
みたいなどうなんでしょうね
どうなんでしょうね
ちょっと内情までは分からないですけど
GitHubは多分サポート部門が
サポート部門 営業部門 広報部門
確かにそのあたりくらいな雰囲気はありますかね
あんまりコミュニティとか
エンジニアサイドのことをやってる方って
中にいらっしゃるのかしらっていうところはありますかね
確かにな
これは言い得てみようなところですかね
Twitterはどうなんでしょうね
やっぱり開発部門になると
大体サンフランシスコ側にいるような雰囲気はあるとは思うんですけれども
日本法人にもそこにソフトウェアエンジニアいたとは思うんですけどね
最近Twitterすごく大割れというか
全然働いてねえみたいな
そんなよく分からないイメージで投げられてましたよね
どうなっちゃうんだろうな
すごくひがみとは言わないですけど
実際そんなことはないとは思うんですけどね
すごく腹の疑いをかけられてるような雰囲気は感じますかね
ちなみに今日あれなんですよね
51:01
今私がこれやっているとき
収録してる時間がちょうど日本とクロアチェア戦やってるんですよね
もう終わったのかな
どうなんだろうな
前半だけ見てたんですよね
前半だけ見てて
何分ぐらい
40分ぐらいですかね
日本が1対0で勝っていたと思うんですけど
サッカー日本代表っていうハッシュタグなのかな
86分に選手を入れ替えたみたいですね
でも延長戦を考えてって書いてあるんで
もしかして同点に追いつかれたんですかね
同点に追いつかれてますね
そんな決勝リーグ簡単にはいかないですよね
これもアベマって海外からも見れるみたいな情報があったんで
普通に見ようとしたらエラーになっちゃって
ただそのエラーメッセージが今混んでますんでダメですみたいな
エラーメッセージだったんですけど
VPNで通すと見れたんで
多分エラーメッセージの問題なのかなっていう気がしましたね
ちなみに全然関係ないんですけど
ストリームアドがちょっと前からUI日本語化されていて
日本語を選択するとちゃんと書くパーツが日本語になるんですけど
配信しながらこのスタジオを抜けようとするとアラートが出るんですね
日本語の時には配信を終了しますがよろしいですかって出るんですね
例えば管理者が何人か入ってて
一人の管理者が抜けようとするとそのアラートが出るんで
そうすると怖くて抜けれないんです
マジかよって思ってたんですけど
54:01
それを英語版にすると
ただスタジオ抜けますかみたいな確認メッセージだけなんです
抜けますかと終了しますかって全然意味が違うんですけど
完全に超互約してるなと思って
本当は抜けて全然大丈夫ですね
別に誰か一人いれば配信はずっと続けられますし問題はないんですけど
日本語の場合は配信終了しますかって出ちゃうんで
誰も抜けれなくなるっていうそういうのをやってたりしますね
アベマも多分違うメッセージなんでしょうね
システムエラーじゃなくて多分海外からアクセスした場合のエラーになっているだけだと思うんですよね
最後かな
もう一件くらい面白そうなのが
これもリインベントに起因するものだと思うんですけど
AWS上で開発チームのための環境意識を提供するAmazonコードカタリストを発表しましたというふうに書かれてますね
パブリックキーさんの記事なんですけれども
開発周りの環境整備がどんどん重くなっており
これが開発のスピードを落としていると指摘がありました
このペンをどうやって取り除くかというところでAmazonコードカタリストを発表した
このサービスはクラウド上にチーム開発のための必要な環境意識を迅速に構築提供するサービスです
初期設定としてブループリントと呼ばれるソースコードのリポジトリ
開発対象のフレームワークやライブラリー
初期コードやテンプレートなどがチームのために用意され
Web IDEとしてデフォルトでCloud9が利用可能です
現時点で標準として用意されているフレームワークは
アングラ、リアクト、ビュー
IDEはCloud9の代わりにVisual Studio Codeとか
IntelliJ、ゴーランド、PyCharmを利用可能と
クラウド上でビルドテストデプロイを行うCICDパイプラインを簡単に定義できると
チームでのタスクやイシュー進捗などの管理を行うダッシュボードも用意されていると
コードカタリストでデフォルトで提供されますが
既存のサービス、JiraやSlack、GitHubなどと組み合わせて利用することもできると
一応フリーティアもあると書かれてますね
こういう意識を最初から用意するサービスも多分あるかなと思うんですけれども
57:03
あらかじめ個々の細かい流度でサービスを用意しておいて
記録をまとめて一括で実行できるようにするみたいなところで
AWSというのはうまいやり方だなと思いますね
アンプリファイとかも同じですよね
やってることはAWSとかクラウドフロントとか他の
あとDynamoDBとかですかね
その辺りのサービスを一気に環境構築をバババってやってくれるみたいな感じだと思うんですけど
そういった感じで細かいものをガチャっと集めて
パッケージにしてくれるっていう感じですね
一個のパッケージ提供してそれを細かくしていくって
なかなか大変な感じかなと思うんですけれども
その逆っていうやり方ですよね
面白いやり方だなと思いますし
課金とかもそれぞれの個々でかかってくるんで
うまくやれば多分AWSのサービスを使う価値が生まれるかなと思うんですけど
さっきのエコシステム的にクラウド9を使わない選択肢とかも
用意しておかなきゃいけないんで
自分たちのサービスだけじゃないところまで
どこまではみ出していいかっていうのを定義するのが
なかなか難しいなというところですね
ということで今日はニュース周りいろいろ紹介していったんですけれども
最後にイベントですね
DevRelCon Yokohama 2023は3月10日、11日に横浜で開催しますと
チケットもオンセールなのでぜひ買っていただけると嬉しいですと
CFPですね
CFPは日本語に関してはDevRelJapan 2023の方に関しては
12月15日なのであと9日ぐらいですね
終了になりますのでぜひ皆さんのプロポーザルをお待ちしていますと
DevRelConの方は今月末まで募集していますので
そちらもぜひ送ってみてくださいというところですね
ということで今日のDevRelラジオ91回目ですね
こちらは終了していこうと思います
また来週は海外からお届けになると思いますが
ぜひ聞いてください
ではまた皆さん来週お会いしましょう
さよなら
59:47

コメント

スクロール