このラジオは駆け出しエンジニアの順平と先輩エンジニアの海地 範が送る駆け出しエンジニアを中級エンジニアにキャリアアップさせるラジオですということで今日はですね僕が最近触っている語言語の話をさせていただきたいなと思います語言語どういうイメージありますか

かっこいいかっこいいモダンモダンモダンなんかイケてる会社が使ってるそうなんだあと青い水色あーゴファー君水色ですねゴファー君って言うんですかあ違うゴファー君ねゴファー君あのネズミみたいなビーバーなんだえっとまあいろいろイメージあると思うんですけど語の特徴として一つあるのが書き方を一つの書き方を正解としている文化があるというかうん

Goってこうやって書けよっていうのが割と強制してくる言語だったりするんですけどGoってGoogleが作ってる言語だったりしますがそういうとこ学ぶとですね読みやすい欲しやすいコードってこうなんだっていうのが学べんじゃないかなと思ってなので今日はですねGoのいろいろある言語規則の中の命名

のみにフォーカスを当ててちょっとお話しさせていただきます日地日地ですよね日地これだけでもすごい語言語こんな雰囲気なんだなっていうのを感じてもらえるかなと思うので他の言語と比較しながらワイワイ話せればと思いますはいというので

聞き終わった後にね語言語書いたことなくても語言語ってこういう言語らしいよねって知ってる風に喋れるようになるっていうのを目指してお話させていただきますまず最初変数名一番ベータなところですね語言語では変数名はミックスキャップスっていうのでキャメルケースですね大文字始まりで小さくなる大文字と小文字を組み合わせて

単語の切れ目が大文字になってるみたいなそうですそうです書き方で書いていきますと他の言語とちょっと違うなと思ったところがですね当時語URLとかものを略した言葉はすべて大文字か小文字とするDBとかそうですそうですなんでなんでしょういい例

文語DBっていう変数名ありえないんですけどあるとしたらMが大文字でONGOが小文字でDBが大文字になります僕割と他の言語って当事語も別に関係なく小文字にするじゃないですかDは大文字でBは小文字みたいな見づらいなーって思っててなるほどね

これ揃えるの確かに見やすいかもって思ったりしてましたちなみにじゃあhttpクライアントみたいな変数があった時ってhttpは大文字でクライアントのcが大文字であとは小文字みたいな作用その通りですあとはパブリックな変数とプライベートな変数あると思うんですけどプライベートの変数は小文字スタートパブリックな変数は大文字スタートへー

っていう書き分けもしますねアッパーキャメルかロアキャメルかってことですかそうですそうですちなみに語の中のパブリックとプライベートって範囲はどういう範囲なんですかえーっと後で話していいはい後で話していいはいちょっとあの今喋ってないかつ他の言語にない概念出てきちゃうんでなるほどちょっと後で触れますはいはい

しっかりその命名がそういう風になってないっていうだけでエラー出たりするんでちゃんとエラーまで出るんだ変数名だけで使えないですそれはすごいなと思いました気合を意志を感じるそうそうそう感じるっすよねあともう一個すいませんいっぱい言ったらなんですけどエラーの変数名は絶対最後にエラーをつけてくださいERRそれともフルでエラーですね

それは変数というかクラスみたいなやつがあるんですけどそういうクラスの名前ですねちょっとすいませんややこしいこと言いました語ってですねオブジェクト思考言語じゃないんですねオブジェクト思考言語って俺が何を思って言ってるかというとクラスがあるかないかなと思ってるんですけど語にはクラスがないですないない

でもオブジェクト思考言語みたいな書き方ができます確かにそれはなんでかっていうとですね構造体っていうものがありますなんでそんな急にゴリゴリ日本語やねんと思ってるんですけど構造体何かというとクラスみたいなもんなんですけどクラスのなんていうんだオブジェクト

だけクラスってクラス自身が持ってる値とクラスが持ってるメソッドみたいなのあるじゃないですかそれ引っ込めると僕クラスだと思ってるんですけどクラスの中のメソッドがなくて何かの値バリューを持ってるだけのものを構造体で呼びます意味は分かりました構造体以外の単語が出てこないんですけどはい

オブジェクト思考をやっててもたまにそういうデータ作りますよねDTをDAO DTOみたいなあれってデータアクセスオブジェクトとデータトランスファーオブジェクトの2つに分けてどっちかが操作するやつでどっちかがデータだけを表すみたいな分け方するんですけどどっちだっけなトランスファーが全然覚えてないですどっちかどっちか忘れたんですけど

そういうイメージかなと思いました片方はメソッド持ってなくてデータ詰め込むだけのオブジェクトみたいな構造体はメソッド持たせられなくてデータだけ持たせられるみたいなイメージですかねそうですそうです本当になんで動きとしては構造体単体だとほぼディクショナリーみたいなハッシュディクショナリーみたいな動きをしますねTSの型とかってなんか

そうそうそうそうそんなイメージがTSのカタスほぼあれはなんかメソッド定義できたような気がするけどどうやって定義してましたっけ?ファンクションみたいなの書いてたと思う別で書くんですよね書き方ある?そう語も一緒ですそうなんだTS知ってる方はなんとなくTSに近しいものを想像しながら聞いてもらえればって感じですね先ほど言ってたパブリックとかプライベートのスコープの話なんですけどはい

その何でしょうね宣言されている変数って多分メソッドの中かパッケージの中パッケージはだからモジュール他の単語で言うとライブラリとかモジュールグローバルで宣言しているやつはそのモジュール内Goで言うとパッケージ内で使えるみたいなイメージになりますね構造体の中のメソッドで宣言していたらそのメソッドの中でしか呼べないみたいな

そういうよくあるスコープですよね今宣言しているところの外で呼べるか中でしか使えないかは似たようなものだと思います今変数の話からちょっと脱線してしまいましたがGoでは変数の命名こういう風にしないでねっていうのもスタイルガイドで細かく言ってたりしますポロポロ言っていくとまず変数名に関しては

参照されるスコープの変数の参照される範囲の広さによって変数名の長さを変えましょうと言ってますつまり最初に使い始めた変数をめっちゃ使いましてめちゃめちゃ後ろまで使えますぐらいだったらすごく詳しく書くべきだしその直後でしか使われないぐらいだったらめっちゃ短くしろよとめっちゃ理にかなってるなと思うんですけど確かになんか全部ちゃんと書こうとしてましたね

語ではすぐ使い切るやつは一文字でもいいとえマジかそう究極ですよただ一文字はあんまりないだから多分ポピュラーなのは一単語だったりするんですけどまあ二単語とかは使わないよねみたいなもちろんスコープがめっちゃ長かったら詳しくコンテキストまで入れ込むべき

という風に明記されているかというと分からないんですけど書かれているように僕には感じたのでスコープに応じて変数名を設定しましょうあとは入力の手間を省くためだけに文字をただ削除するなと省くなよと例えばサンドボックスをSBXみたいにするなみたいなこれよく言われですね略字あとはその一文字の変数名を付けるときには

その一文字の単語じゃなくて文字から何なのかが分かるときにしか使っちゃダメですとムズフォアで言うIあとは座標で言うXYうーん違った座標はちょっと際どいですね緯度とか経度とかにした方がいい場合とかもあるかもしれないラティチュードだったらLみたいなそうですラティチュードとロンギチュードなんでどっちもLなんですよLかいラトロンって書きますねどっちもLかいパイソンだと多分ラトロンって書きますね確かに

あとはさっき構造体に話しましたけど構造体からメソッドを生やしたい場合があってオブジェクト仕込みみたいな感じでその時って構造体を

関数に渡すんですよ関数を定義するときに引数渡すじゃないですか関数って引数の枠で枠とはまた別に構造体を渡す枠があるんですよレシーバーって言うんですけどその構造体を関数に渡して関数を定義するんですけどその渡したレシーバー書き方としてはPythonとかだとクラスのメソッド呼ぶときセルフドットなんとかって呼ぶんですけどJavaもそうなんですか

別の言語でもセルフドットなんとかで呼んでるなと思ったんですけどJavaじゃないかJavaは何もなく呼べたような気がするそういうことありそう確かに合言語の場合はクラスの中でクラスの持ってる値例えばユーザーだったらユーザードットネーム呼びたいことあるじゃないですかPythonとかだとユーザークラスのネーム呼ぶときはセルフドットネームって

クラスの中だと呼ぶんですけどGoだとuser.nameっていう呼び方するんですよ構造体をフルで言うというかたださっき言った通りGoでは変数名短くした方がいいよねっていう文化があるんでレシーバー名に関しては最低限ができてレシーバー呼び出すときにもう一文字にしろって言ってますなのでさっき言うユーザーをレシーバーとして受け取って関数の中でuser.name使いたい場合はu.nameって

呼べるようにレシーバーを受けているところに定義してねって普通に引数の名前がそういう風に書けばってことですかそうそうそう引数じゃないんですけど引数みたいなもんでそうですそうですレシーバーをさっき言った構造体からひも付いている関数の中でレシーバーを宣言して何かするときはレシーバー名は一文字にしましょうなぜなら

レシーバーが詳しく名前書いてるんでレシーバー名構造体の名前ってちゃんと名前書いてるじゃないですかちゃんと名前書いててなおかつそれが関数の頭に宣言されてるんでもしこれを一文字に省略したとしても何言ってるか分かるよねっていう考え方でレシーバー名を関数の中で使うときは一文字にせよっていう風にスタイルガードで書いてたりしますなるほどやっぱりスコープ

変数のスコープってところがすごいポイントだなと思ってて 略した命名をするにしてもそれはどういう値なのかが絶対にわかるような状況じゃない限り短縮するんじゃねーぞと言ってるのがこの5のスタイルガイドなんだなということでちょっと読み取りました しかも今のなんかエディターとかって高機能だから大体変数名載せたら

多分レシーバーだから型が出てくるんでしょうね出てきます出てきますユーザーっていう構造体ですってそれですぐ見りゃ分かるのにそこにわざわざ名前長い名前長い名前長い名前をつけて読むの面倒くさくする意味ないよねみたいなそうですそうですなるほどなと変数名の切り口でした

でちょっともう何個か話せればなと思ってるんですけどもう次いきますね次がですねパッケージ名っていうところですパッケージはですねさっき言った通りPythonで言うモジュールRubyで言うと何ライブラリPHPで言うとこれちょうど昨日読んだんですけどPythonとかPHPに関して言うともうファイル自体がパッケージになり得るみたいな

感じらしいですそれは同じものを指してるんですかそのパッケージは多分なんでかっていうと一個のファイルの中で複数のファイルをインクルードして逆にそのファイル自体を公開しちゃったりできるじゃないですか他から使ったりできるじゃないですかそれが一個のパッケージになってるからファイル単位でなってることもあればディレクトリ単位でパッケージ作ってるケースもあるよねみたいな感じでしたそれも同じですね同じです同じです

いわゆるインポートとかする単位ですねインポートで伝わりますかねコードの中でLaravel使っている人はUseをイメージするといいかもしれないですねそのパッケージ名に関する命名もGoでは言われていてパッケージ名は小文字にしましょうそれはルールなんでそういうもんだって置いておいてもらってですね

パッケージ名からどのような用途になっているのかが分かるように命名しましょうという風に言っていてですねパッケージの中で複数のことをやるべきじゃないと宣言していて複数のことをやるんだったら分けろと分けるのはディレクトリを分けろと言っています分かりやすい例で言うとエンコーディングJSONとか多分どの言語にもあるじゃないですかGoの公式パッケージでもエンコーディングすらJSONというのがあるんですけど

エンコーディングっていうパッケージじゃないんですよエンコーディングJSONっていうパッケージなんですよエンコーディングはディレクトリでJSONがその下にいるなるほどなので他にもエンコーディングXMLが使えたりとかするんですけどなので自分でパッケージを作ってる時にエンコーディングJSONっていうパッケージだなこれ今作ってるのって思った時って単語2つじゃないですか単語2つの時はフォルダ分けろよって

なるほど複数の名詞を組み合わせたくなるような名前だったら黙ってホルダーを分けようぜっていうのがGoogleのスタイルガイドGoは違うGoogleじゃねえGo言語のスタイルガイドなるほどと思って確かにそれはそうかもって思いましたエンコーディングJSONの場合エンコーディングJSONしか今は作ってないかもしれないけど確かにエンコーディング何々って他にもいろいろあるなって思えるじゃないですか

なのでそういう時はパッケージを分けましょうというかディレクトリを分けるエンコーディングの中でさらに切って作るっていう面白いなんかそれってさ新しくパッケージ出てきた時にうわーってなるけど名前に着目すれば気づきやすいってことなんだそうそうこれ別にね今パッケージの話してますけどパッケージ以外にも言えますよね例えば普通にクラス設計する時もそうですしあと手元の

なるほどね

しかもちょうどそれあれっすねクリーンアーキテクチャにパッケージに関する原則みたいなやつ出てきたと思うんですけどなんでしたっけ結局言ってるのはソリッドをパッケージに当てはめたみたいなやつで一つのパッケージは一個のことを知ろうみたいな系のやつが結構あるんですよパッケージの原則にもそれにすごい忠実だなと思いましたね確かに確かに確かにそれはそうですねうん

それは確かに多分そういう学びをいろいろ抽出してGoogleの人の強いエンジニアがある程度ストロングスタイルで多分書いたのがGoのスタイル外だと思うのでそういうのも多分やっぱりDNAとして入ってるんでしょうねっていうのがすごいなんか読んでて楽しかったでパッケージ名も最後もう一個パッケージ名と関数名はドライ原則に従おうっていうのがあってですねどういうことかというと

例えばhttpサーバーを立てるメソッドみたいなのがあったとしてそれはhttpパッケージの中のメソッドだと思うんですけど命名としてhttp.httpserverという命名にするなとhttp.serverという命名にしようというので開発してるとやっぱパッケージ名とかってあんまり意識しないで開発することがあるかなと思うんですよただそれは使う側はどうやって呼び出すんだろう

っていうのを考えて命名することでドライにならないようにしましょうねとなるほどね確かになんですけどなるほどねと呼んでて思いましたねそれで言うとさ全然ゴーじゃないんですけど例えば結構よくある設計かなっていうのは

ディレクトリでサービスって切られててその中になんちゃらサービスがめちゃめちゃいっぱいあるみたいなあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるある

それが今度リポジトリにもユーザーリポジトリみたいなのがあったとしてリポジトリもリポジトリというディレクトリの中にユーザーリポジトリがありますよとこれを全部省略したときにサービスにユーザーがあってリポジトリにユーザーがあってしかもララベルとかRuby on Railsとかだったらモデルにもユーザーがあるみたいな同じファイル名めちゃめちゃ増える問題はあるなってちょっと聞いてて思いましたね

言語の世界観で言うと別にそれ良くないっていうのが考え方なんでしょうねなるほど別にフォルダは切られてるから混同しないでしょどっからインポートしてるか見れば分かるよねそうですそうです実際現場もそうなってるんで同じファイル名のファイルはあるんですけどそれはフォルダから通してみてこれが何なのかが分かるみたいな

ので整理されているイメージしかも大体ちゃんと作っていればレイヤー分かれているから1個のファイルに同じファイル名のやつを2個使いに行くことはあんまりないかそうですねっていうのがGoogleのスタイルガイドで書いててなるほどななんかすごい頼む感じてくれって気持ちなんですけどやっぱりその語言語のスタイルガイド

あんまりないですか他の言語でスタイルガイドみたいなのはコード規約はあるんですけどコード規約でもないんでこのスタイルガイドってそういうところからクリーンなコードとはクリーンなネーミングとはみたいなヒントがちょっとポロポロ落ちてるなっていう感じをすごい僕は受けながら読んでたりしてたんですよねじゃあ最後インターフェース名

さっきクラスねとか言ってたんですけどインターフェースあるんですねインターフェースありますインターフェースこれは想像の通りだと思うんですけど構造体さっき言った構造体クラスみたいなちぎやつねの上に置くやつインターフェース本当にオブジェクト思考で言うとインターフェース機能的にも似てるんですか機能的にも似てるちょっと違うんですけどインターフェース定義しますその

オブジケット思考言語だと継承をしてインターフェース継承してクラス定義するじゃないですかただGoには継承ないんですよじゃあどうやってインターフェースになってるか継承がないんでなんていうか分かんないけどインターフェースを実装してるか実装してるかって判断するかというと同じメソッドがあるか

インターフェースで多分どの言語もそうだと思うんですけどインターフェースってこのメソッド持っててねって定義するじゃないですかでGoはそのメソッド持ってればそのインターフェースを実装していることになりますでここがちょっとオブジェクト思考言語と違うところでGoにおけるインターフェースって一つのメソッドは複数のインターフェースを実装できます伝わります?ん?

僕の思うオブジェクト思考言語ってインターフェースの下にメソッドいると思うんですけどそのメソッド一つのインターフェースから継承しているというイメージがありますそれはまずあってますか複数もあります?複数のインターフェース持つことはできるかなできはしますけどあんまやんないフレームワークのソースコードとかでしかやってるの見たことないなるほどなるほどなるほど

Goは複数のインターフェースを実装することはまあまああるなるほどなぜならGoのインターフェースの命名規則これちょっと面白くてERを後ろにつけるERを後ろにつけるペチパーみたいなインターフェースマンFmt.stringerとかio.leaderとか

これはでもただ全部そういうわけじゃないんですけど一つのメソッドのみを持つインターフェースがERを後ろにつけましょうっていう命名規則がありますそうなんだでGoの中でのクリーンなコードってさっき言った通りio.readerっていうインターフェースがあってio.writerっていうインターフェースがあってでそれを実際に読んだり書いたりするメソッドはリーダーとライターからリーダーとライターのインターフェースを実装したメソッドなるほど

みたいな形にするっていうのがもちろん複数メソッドを実装することもできるんですけどERっていうのをわざわざ用意してるってことはそういう風な作りにしたら縁ちゃうっていうのがGoのスタンスなんだろうなと思っててここでもクリーンアーキテクチャが出てきますねインターフェース分離の原則インターフェース分離の原則ってそういうことだったんだインターフェースを分けて

要は関係ないインターフェースを継承しないようにしようみたいなそうですね確かに無駄なものになりますからねクリーンアーキテクチャの考え結構強い言語の思想としてただ一つのことをうまくやるっていうところもここに現れてるなという風にすごい感じますねしかもこのERって付ける命名ってすごいプレッシャーかかるなと思ってて実装する人からすると

これはだってこれをやるものですって言わなきゃいけないんですよねそうねそんぐらい明確にインターフェースを定義しないとこのERって斜めにつけられないんでなんとかマネージャーとか作ったらボコボコにされそう確かに確かになんとかマネージャーしかもERつけるのってメソッド一つだけ持ってる時なんですごいふわっとしたメソッド持ってるんでしょうねなんとかマネージみたいなね条件分岐して何すんねんってね

確かにそれはあのボコボコにされます条件分岐してフラグ渡したらリーダーになってフラグ渡さなかったらライターになるやばいですそれやばいできちゃいますねできちゃうよねそんなことしたら夢にゴーファー君出てきますねマジで赤いゴーファー君になる髪赤くなって髪ちぎられます指とかあの顔にね怖いはいまあというのですごいなんか

ERつけるのすごい独特だなと思ってちょっと紹介させていただきました全部さらったわけじゃないんですけど変数名とパッケージ名インターフェース名っていうのでちょっとGoの命名規則見てきたんですけどなんかGoの尖り感というかいやそうね尖ってるなクリーンな命名とかクリーンなプログラムってこういうことやろっていうのがすごい感じれるようなものになっててでGoってスタイルガイド

3種類あって僕今ちょっとスタイルガイドってひっくり返って言っちゃってるんですけど絶対にやれよっていうのがスタイルガイドでこれコードレビューするやつはこれ読んどけよっていうウェルアーキテクティットみたいなのがあってであとはめちゃめちゃゴーノックコード好きなやつこれ読んでなっていう3レベルに分かれてる今喋ってたのは2レベルまでの話だったりするんですけど日本語版もあってこれ有志の人が多分

和訳してくれてるのかながあるので読みやすいですしあと普通にドキュメントとして楽しいですこういう風にやってねって書いてるのは

それこそね今命名っていうめっちゃ限定のお話ししましたけど他の言語にも適用できそうな何かはあったんじゃないかなと思ってて例えばスコープの話とかは全言語通用するんじゃないと思いますただちょっと一文字にするっていうのはちょっと尖ってるんでそれはやめた方がいいかなと思うんですけど急に持ち出すのはね一単語ぐらいでというのはあるのでそういう

達人プログラマーとかでも異なるパラダイムの言語を学ぶことでより良いコードが書けるようになるよっていうのはあったと思うんですけど書けるようにならない書けるようになるまでいかないにしろそういう一部分のスタイルガイドとか読むのも結構不安な勉強になるんだなというのが今回読んでみて思った気づきだったりしたので引き続きインプットして単物に対して共有できるのがあれば尖った見方で

今回かなり尖ってるんで 変数だけなんで確かになー

今日はね語言語の異文化感を感じるっていうところで変数名を話させていただきましたありがとうございますすごい異文化だったわ僕これをスタイルガイド見ててすごい思ったんですけどのりさんと1月にシンガポリ行ったじゃないですか海外の法律旅行前ガイド読んでる気分だってなるほどねシンガポールって例えばガム噛んでると殺されるいや言い過ぎだわ罰金100万

とかだっけガムだけめっちゃ高いめっちゃ高いんですよそれ異文化で罰せられるんですよでこのGOのスタイルガイドって守らないと罰せられるんですよ多分GOのプロジェクトでそうだね

行動レビューとかでズタズタにされるんですよね痛い目は見るんですよ自分はまあ確かにそうでだからこのゴーズのスタイルガードを見てる時にシンガポールの旅行行く前のなんか注意事項みたいなサイトを読んでる気分になっていやーわかるわなんかうっかりさなんかあの電車とかで水飲んじゃダメなんですよシンガポールねそうとかなんかやっちゃいそうだなみたいなね気抜くとシンガポール特に罰金大国ですからねうんうん

普通にやることを普通に禁止されてたりしますからねでもそれによってものすごい綺麗な街になってたんでゴーはだからシンガポールですね笑

そのメタファーあるんだキットプロジェクトがすごいクリーンになってると思う確かに確かにそうですね確かにシンガポールみたいなそうだからゴーアシンガポールなるほどルール結構強いそうこれ終わりだねパイソンはね自由な感じなんでねあそうね治安悪いんで治安悪いって言われてるはずですよね確かパイソンってねそうなんだPHPも負けない負けないなと対そういう言語ですねPHPもね手軽に何でもとりあえず動くうん

できるみたいな法律緩めの国はやっぱ治安悪いそうだねこういうとこから世界情勢って見えてくるそうです今度言語とマッピングしようか国

誰に需要あるそれキャッチーですねエピソードタイトルゴーはシンガポールこのエピソードキャッチーですよそうねゴーはシンガポールゴーの変数変数命名じゃないゴーのスタイルガード読んでたらゴーはシンガポールだったっていうゴーイズシンガポール気になる意味わかんない気になるなでもそうなのですごい多分

順平とか特にまだまだいろんなプロジェクトノリさんもですけど点々とするっていう意味では順平多分点々とすることはあると思うんで別言語言った瞬間になんか空気感変わっておもろいだろうなとは思うねうんはいちょっと最近実はGOを触ってて学んだことのごく一部ちょっとお話しさせていただきましたがまあちょっと間違えてることあるかもなんでその時は優しく言ってください何卒おなしゃすやらなきゃなGOも

去年の目標だったんでゴーサワルできなかったんですけどただ取り返しました去年か今年は取り返しましたよかったじゃあお便りいきますラジオネーム筋トレエンジニアさん筋トレエンジニアさんおー

いますよね筋トレエンジニアのいるなんかなんて言うんでしょうツイッターでもちょいちょい見ません?筋トレエンジニアの人ツイッターでも見るしコンパスでもなんかそういうイベント見るあったあったあったあるよね結構定期的にやってると思うノリさんいなかったか多分2人かしさんと自分だけだった裏の話なんですけどノリさん先週前回の収録の時来なかったんですけどでじゅんぺいとコンパスのイベント見てて

朝かな朝トレ朝筋トレエンジニア黙々会みたいなのがあってそのコミュニティを運営してるのがなんかすごい筋肉激推しの筋肉激推し黙々会もタイムスケジュールが切られてるんですけど途中でトレーニングタバタ式トレーニング休憩みたいなスクワットとか確かあったんですよ

筋トレはいいですからね途中のリフレッシュにめちゃくちゃいい筋トレエンジニアさん置いていっちゃった感想を読みますねいつも楽しく聞かせていただいてます2月からウェブエンジニアとして働いている33歳男です先輩チャットGPTなど生成AIとの付き合い方を最近よく考えますというのも最近

先日社内で業の勉強会がありチャットGPTに聞かずにGoogle検索のみで課題をやってみようという内容でしたがその際にチャットGPTなしでわからないことを調べるとすごく難しく感じましたこのままチャットGPTに頼りすぎると自分で課題解決する力が衰えていくんじゃないかと不安になってしまいましたお三方そういった悩みはありますかお話を聞いてみたいですという感じです

なるほどなるほどいやでもそうだよねチャットGPTネイティブの人っていう言い方ってわかんないけどだからするとGoogle検索多分めっちゃむずいですよねむずい絶対僕も最近新しい言語特に僕Vueとか今まであんま触ってなかったんでVueでやりたいこととかがどうやってやるんだろうってなった時にチャットGPT使ってやり方調べて

チャットGPTというかワープAIというのを使っているんですけど僕はやり方が出てきてその書き方が何なのかというのを質問した後に裏付けでドキュメントを見るように分かる分かるこれやったらすごい解決早いなと思ったんですけどその裏付け取れないまま成長したら怖いなというのがあったので新人に教えるときはAI使いたくないなというのはめっちゃ思ってましたねなるほどね個人的には

別に使っていいんじゃないかと思っててそれはだってそんなこと言ったらGoogle検索使ってるのもダメですよ多分ね伝わります?言ってみリバースエンジニアリングしろってことですかねかもしれないしあとは本図書館行けよってかもしれないですね時代の変化とともに出てきたツールなんで多分それは使いこなしてなんぼ使いこなし方をむしろ学ぶべき多分もっと上手く使えるかもしれないチャットGPTひょっとしたらね

ググり方もコツあるじゃないですか多分GPTも一緒だと思うんですよ使い方それこそのりさんで言うエビデンス見るべきだと思ってて僕もそれはそのチャットGPTが正確なこと言わないことがあるからでもそのエビデンス見るって別にチャットGPTの使い方じゃないですかなんかチャットGPTって言い過ぎか生成AIなのでなんかそのうまく使うやり方はまあ

研修で教えていけたらいいのかもしれないですしなんならこの筋トレエンジニアさん別にチャットGPTを使って課題解決する力があればいいんじゃない使えないことない現場によってはあるんですけどもちろんチャットGPTを使いこなして課題解決するっていうのはさっき言ってたエビデンスを見に行くのも含まれている含まれているそこがなかったらやっぱ

成長なかなか厳しいですよね課題解決力それこそあんま育たないですよねと思うんですよ僕もそこセットならいいかなっていう気がしますこれ現代でそういうの使えない現場ってどのくらいあるんですかね結構ありますよね多分そんなことないですかえーわかんないな結構使ってそう逆にまあだいぶ増えてきたんじゃないのかなって気はそうなんだまあなんか

最近コパイロット使い始めて業務でクソ便利で何が便利かってコードをリコメントしてくれるのはもちろん便利なんですけどそれ以上に既存のコードの説明してくれるのが最高に便利でこのモデルって何やってるのとかこのアプリって何やってるのとかそんなレベルで聞くんだリポジトリ単位で全部読み込んでくれるんですげえ

あとそのKubernetesのYAMLとかねそういうのを聞いて答えてくれるのがめっちゃ便利で今のプロジェクトの理解を進めやすいという意味で多分そういうのって使えないとだいぶ効率落ちるからただどこでも使えるわけじゃないんでもちろんそれって本当に多分プロジェクトの秘密感による頭悪い単語ですけどなくてもできないとダメだなっていうのはそういうのに対しては思いますけどね

検索とかについては別にGPTありきでいいんじゃない思考力はでもなくさないようにしてほしいなってのはすごいあって現代って便利なものがいっぱい登場したことによって運動不足に陥ってる人がいっぱいあるじゃないですかそういうのの知的バージョンが起きそうだなっていう確かにそれこそ01をGPTにやらせるのかGPTと一重にするのかみたいな

使い方ですよね本当にだから使い方脳死で入れて脳死でやるじゃダメでなんだろうねホマってやる力というか思考力ですねあんまり頼りすぎるの良くないというか食品添加物みたいなものなのかもしれないな

食品添加物があることによって安くて美味しいものを食べれると思うんですけどそればっかり食ってると体に良くないみたいなのがあると思うんですけどチャットも効率よく開発するためのサポートとして使うのはいいけどそれに一辺倒に頼りすぎて自分の思考力を衰えさせてしまったらちょっとそれはもともともないんじゃないかみたいなのがあるよねそうですね

それってなんか外から見てて指摘してくれたりするのかな自分で気づくしかないですよね多分それむずいですねまあでも意識多分この筋トレエンジニアさんは言ってるぐらいなんで自分でそんなに意識してやれてるかなとは思うんですけどあと筋トレしてるから大丈夫じゃないかなそういえば筋トレしてんだ筋トレしてないのかもしれないけどね筋トレエンジニアって言っといてしてないのかもしれないですけど確かに筋トレしてれば

だってね筋トレもね器具いっぱいありますけどあれもね適当に使うのじゃダメでここに効いてるって意識してるから筋トレできるんだよねその原理原則便利なものに騙されない力マッチョはだって全員そういう本質見てますからあとやっぱ運動が脳を最強に鍛えてるらしいんでそれは僕もそう思いますなので付き合い方っていうと思考力

そうですねなんかあのアンプとして使うのがいいんじゃないですか加速機というかやっぱ01じゃなくて自分の思考を加速させるためのもの

ラバーダックプログラミングってあるじゃないですか自分のやったことに対して机の脇にあるゴムのアヒルちゃんに向かって話しかけることで自分の思考の穴を見つけるみたいなそういうやり方があるんですけどラバーダックプログラミングできるんですよねシャットGPTってねすんごいいい感じに会話してくれるんですそれでなるほどなるほど

そっかだからそういう意味だと答えを求めるために使っちゃいけないのかもしれないあーいいこと言うねいいこと言いますね間違いないかも答えを求めちゃダメかもそうだよねうん

ヒントもらいに行くみたいな気持ちというかそうですねいやー使っちゃうことあるなわかる答えから逆算ちゃんと逆算しなきゃいけない答えが来たときはそれこそエラーがバーって出てエラーがバーってコピーしてパッてせいせいやに貼り付けてこのエラーの内容を教えてくださいみたいなのはダメってことですよね俺もそれはいいんじゃないって思っちゃった自分で読む

じゃなくて理解してエラーのだから日本語を要約違う文章を要約してもらうってことでしょ要約というかどうやったらエラー解消しますかみたいな聞き方は良くないと思う確かに翻訳ぐらいならまだ俺翻訳ぐらいならまだいいと思うでそっからなんだろうこのエラーが出てるなって言ってどういう風な仮説を自分で持ってこう思うけどどう?って聞いてみるのとかは別にいいのかもなと思う

あとやっぱ人に喋れるかどうかって結局大事なんだなって思うかもしれない例えばその人がAI育ちで育ったとして後輩に聞かれた時になんか分かんないけどこれで動くんだよねっていう回答でいいのかどうかというかあーむずそうですね確かに今はありえないと思ってるんですけどそれはありえないっていうのはダメやろそれはっていう意味で社会が変わったらどうなんだろうでもAIで出るからいいんだよ

そう怖いですよねでもまあそれなんかシンギュラリティ後ですねシンギュラリティ後AIが人間を超えた後の世界ですねでもまあそれまではそうじゃダメですねでも確かにそういう世の中あり得るんだなって今のりさんの話聞いてて思ってちょっと震えましたわ世にも奇妙な物語みたい怖いやあるな全然あり得ると思うあり得ると思うわ

用法用量はほなほとに守ってって感じじゃないですか間違いないデジタルデトックスみたいな感じでAIデトックスする機関とか作ってもいいかもしれないですねあー面白いですね確かにうわーすげーいろんなことできなくなりそうめっちゃ時間かかるうぜーってなりそうコード書くときとか確かにクッソ早いですからね参考になりましたかねちょっとは

ぜひうまく予報よりを守って思考力を取れないように使うのはいいのはおっしゃる通りなので筋トレエンジニアさんのね筋トレしてるから大丈夫っていうのと質問投げてきてくれてるってことはきっとそこに何かしらの違和感を感じてると思うんで間違いないね引き続き筋トレ頑張ってください頑張ってくださいでは締めますハッシュタグひまじんプログラマーでSNSでフィードバック募集してますので

そうですねクリーニングの関する情報お待ちしてますもしくはここ鍛えてますとかでもいいですね好きな種目デッドリフトですみたいなねデッドリフトいいですね

あとは説明欄からGoogleフォームで番組のお便り要望質問を募集してますのでお気軽にお願いいたしますお願いしますお願いします最近ハマってることとか教えてください急に急に困っちゃうことあるかもな困っちゃうことあるかもしれない最近このアイスにハマってますみたいなそれは欲しい欲しいよねそれは欲しいわ熱くなりますからねそうなんですあとは各種Botcastプラットフォームでのフォロー高評価お待ちしてますのでそうですねもう

順平推しだよって人順平推しだよって人は高評価してくださいそうですね俺推しじゃなかったら低評価なんでそっちの割合を大きくしちゃったんだろうね人数的な意味でね評価しないよりいいってことよねなるほどねはいお願いしますではまた次回バイバイ日本のエンジニアは使うアプリが多すぎる

事実、ヒマプロの使用アプリ平均数38.6個レイキャストならアプリの即起動過去のコピー履歴を引き出せるウィンドウのリサイズなどこれ一つで作業効率アップしかも料金無料今すぐレイキャストで検索