【Go言語】 webapp GO Part1 【Golang】 [無断転載禁止]©2ch.net
>>330 そう聞かれるとうまい答えが見つからぶ「オブジェクト指向っぽい設計」というアホな回答になってしまう そもそもインターフェイスとかいう概念がなかったので使いこなすのが難しい インターフェイスの何が嬉しいんだみたいな疑問が定期的にわいてくるんだが 動的言語だとダックタイピングだからインターフェースがないってことか。 インタフェースはまんまインターフェースだよ APIはアプリケーションインターフェースだろ。 つまりオブジェクト間で情報をやり取りするための決まり。 例えばfmt.Fprintfをみてみよう。 https://golang.org/pkg/fmt/#Fprintf 第一引数にはio.Writerを満たすインターフェースならなんでも突っ込める じゃあio.Writerインターフェースって何か? これはwriteメソッドを備えたもの 例えばhttpのレスポンスだったり、もちろんファイルだったり それらはとにかくwriteメソッドを実装しているだけなんだ。 自分で作ったオブジェクトもwiteメソッドさえ備えていれば突っ込める。 便利でしょ? 動的言語の場合だって if (typeof xxx.someMethod === ‘function’) みたいなコードを書いたりしたでしょ? こういうのを一々入れる必要がなくなる。 なぜならインターフェースの条件を満たさないオブジェクトを突っ込むとコンパイルエラーになるから。 心地の良い設計の基本はすべてを知らなくても実装できること。 例えばfmt.Fprintfの中の実装を知らなくても Writeメソッドを実装すればfmt.Printfが使えるでしょ。 そういう風に自作のオブジェクトも基本的にインターフェースを仲介して 各オブジェクトの詳細は知らなくても使えるようにする。 つまり疎結合にしてやる。 インタフェースは既存のクラスに手を入れられないのがつらみ C# みたいな this キーワードいれたりとか Haskell みたいなアドホック多相とかあれば別だけど 俺としてはgoaとか勧める。 あれはwebapiを設計してやるとgoのコードを生成する。 webapiの実装例として参考になるし、そのまま開発してもいいし。 なるほど色々ありがとう インターフェースの嬉しいところはなんとなく分かった。 ある型にたいして既存の関数やメソッドを使いたい→インターフェースを満たすようにメソッドを定義という感じの思考のプロセスでいいのかな? >>336 例えばテスト主体で考えてもらえればより便利さがわかると思う。 interfaceを満たすだけのダミーなら簡単に用意できるでしょ。 structを直接引数に取る形にすると本番のstructをテスト書く時に用意しなきゃいけなくなる。 この思考プロセスがやがてDIに結びついていくんだけども。 >>337 この話を聞いた上でちょっと色々コード眺めてみるわ 言わんとすることは分かったのであとは自分で書くときにすんなり使えるか… とにかく参考になったありがとう goにおける配列操作で目的の要素を取り出すのっていちいちループを回さないとだめ? 標準ライブラリになんかないかな メソッドのレシーバにnil pointerを渡して有用な場合ってどういうときなの? メソッド内でフィールドアクセスする際にpanicになったりして良いことない気がするんだが >>340 別にnilを渡せるのが有用とかいう話は無くて、単にポインタに対してメソッドを呼び出せるとレシーバーがnilになりうるけどどーすんの?って話でしょ 他言語ではメソッドは呼ばれずにNullPointerException的なのが飛ぶようになってるけど goの場合はメソッド側でnilに対処すれば呼び出し側はレシーバーがnilかどうかを気にしなくてもいいというメリットはある >>341 それメリットだとは思えないんだが nilに対処するコードを毎回書かなきゃならないのもダルいし忘れててもコンパイルできてしまって実行時にpanicするしで嬉しくなくね? gaeのdatastoreを勉強できるいい教材ないかな appEngine使ってる人いないのん? go1.8にも対応しつつあるし期待しとるよ goで配列の定義で []*T ってよく見るんですが []T でダメなんですかね? []*Tにするメリットを教えて下さい https://cloudplatform.googleblog.com/2017/09/introducing-managed-SSL-for-Google-App-Engine.html?m=1 ナニコレ GAE使えばSSL無料で使えるっていう意味? これはいいな >We’re excited to announce the beta release of managed SSL certificates at no charge for applications built on Google App Engine. コスト的にかなりいいよな ついでにドメインも無料化してくれないかな…(チラチラ) Googleが発行するクレカの特典とかでもいいから (Googleにはクレカ利用料の数%のインセンティブがあるからそれで賄える) Googleブランドのクレカが欲しいねん Let's encryptとGAEと自動更新スクリプトで無償SSLは既に実現できてた それを管理コンソールから簡単に設定出来るようにしたとか、そういうのかね? これでPaaSはGAE一択になったな 今までSSL証明書に払っていたお金をスケールアウト費用に回せるから コスパぶっちぎりで良い AWSも追従してくれ GAEはAWSと違ってサービスが成長しなければ、ずーっと無料で運営できるのが良いのだよ 失敗時のリスクが低いから挑戦しやすい ランニングコストがほぼ0円になれば、例え月10万PVしかないサービスでも停止せずに 次の新しいサービスを並列で増やして収益アップできる 月間10万PVのサービスを100個作れば1000万PV、月間150万円の収入が期待できる 資金力がない学生起業にぴったりだわ GAE/Go SE素晴らしいのに採用事例が一部の野心的な会社しかないんだよな DeNAとサイバーエージェント、メルカリ(の子会社)くらいしかない HTTPSじゃないとSEO不利だからこれは朗報 趣味サイトに年間1円も掛けたくない >>358 datastoreが使いづらいと言ってもgoコード側でスキーマ設定する感じだし joinできないからこそ結果的に使いやすいかもしれない dbの挙動もレプリカありきの挙動だとすれば納得できる いわゆるBtoBの受託開発だと帳票出力があるからjoinないとキツイが GAE/Goが想定してるのはBtoCのwebサービスだからjoinなくても何とかなる ページングもカーソル使って次へと戻るだけあればいい handlerのテストってどこまで厳密にやるべきなの? DBとのやりとりの部分とかは内部で使ってる関数をテストすればもんだいないから様々なパラメタに対して200を返せるかどうかだけでいいのでは?と思うんだけど >>363 バリデーションを網羅できてればいい気がする。 >>364 そのバリデーションってどこのことだろう…? 自分の中ではhandlerに対するテストなんかは裏側から取得してきたデータがどういうものかはあまり気にする必要がなくて入力と返ってきたデータの出力の仕方だけが関心点だと思ってるんだけどなかなかそういう記事とか見かけないんだよね postしたデータは、バリデーションせずにdbに、ぶち込んじゃうの? get系でも入力パラメーターのバリデーションあるよね。 >>366 そこでのバリデーションならちゃんとテストケースに含めるべきだと思う 一方でたとえばUsersテーブルからデータをとってくるためのgetUsers内でのバリデーションのようなものはテストケースをいちいち考慮したくないということが言いたかった golangで独自の仮想通貨を作るのって出来る? gethを改造すればいい感じ? go test とか go build, go install などのコマンドってどこに定義されてるの? ソースを読んでみたいんだけど見つからなくて困ってる ありがとう、cmdのinternalにあるの見逃してた >>370 最近はGOROOTもGOPATHも環境設定不要だから cd ${go env GOROOT}/src/cmd ってすべき ゲーム作るためにgo-gl/glfw使おうとしてmain関数作って実行しようとしたら、 build constraints exclude all Go files in C:\Users\ユーザ名\Desktop\glfw って出た。GOOS=windows, GOARCH=386で試したんだけど初心者すぎてわからん Ruby使いはwebデザイナあがりの意識高い系が多い(もちろんMac) PHP、Perl使いは大昔にHTMLタグを直打ちしてたHTMLコーダー出身のスパゲッティコードを量産していた老害と、その老害を上司に持つ可哀想な若者が多い Python使いは科学技術や情報工学系(自然言語処理、機械学習、深層学習等)のアカデミア出身者が多い Go使いは新進気鋭なBtoC系上場企業の社員が多い JavaはBtoB系受託IT土方が多い こういう印象あるわ この結果を受けてweb&スマホアプリのバックエンドはGoが主流になるんだろうな 当社ではGoエンジニア募集中です Goは日本語学習サイトを充実させたほうがいい PHPerがGoに移行するにはネットで検索>コードをコピペ この集合でwebアプリケーションが作れないとダメだからな >>374 単純に力ある人がGo使うようになってるだけだと思うんだよなあ 別にGoがすごいとかではなくそこそこ力ある人はRubyでもPythonでも予選突破できる インタプリタとコンパイラ言語で速度比較したらそりゃ Goのほうが有利だろ 省メモリ性やら単純な速度まで桁が違う 俺もうSPA前提でバックエンドにgoaを使うことでwebアプリ書いてるんだけど、いいよね。なんかgoaはマイクロサービス用のフレームワークと名乗ってるんだけど、別にマイクロサービス関係なしに使いたいんだけど。 つーかGAEで使ってるけど良い。 仕事でwebサービスをGoで書いてるけど、もっとGo使う会社増えないかなー Go使ってて転職したいと思う会社が無い >>380 Googleの基幹事業だしDonateで維持してるオープンソースコミュニティ発の言語よりは将来性あるんじゃね Youtubeのバックエンドで動いてるPythonコードをGolangに変換してパフォーマンス改善してるし その他にも色々とGolangで動いてるシステムがある また今の時期にGolangに目をつけてる会社は、経営陣(CTO等)に先見の明がある証拠だから伸びるだろう どうでもいいけどGolangって書き方に違和感ある。 Goかgolangじゃないの? C言語 Clang https://ja.wikipedia.org/wiki/Clang Go言語 Golang この伝統に則って大文字だぞ ○+langのlangはググラビリティを向上させるsuffixでしかない >>386 qiitaのタグだと Goかgolangだよね タグなんてユーザーが適当につけるものを論拠にされても gopherのみんなはGoのinterfaceについてはどう感じてる? 他の言語のinterfaceについて詳しくないんだけど、interfaceのもつメソッドを実装していれば満たしていることになるというのがどうも分かりなくくて辛い 明示的にこのinterfaceを満たしてますよみたいなのが欲しいのは修行が足りてない? >>392 type T struct{} var _ I = T{} でT型がinterface Iを満たすかチェックできる >>393 チェックできるかどうかというより何を満たしてるかパッと見でわからないという意味で辛い Goのinterface面白いと思うよ 何を満たしてるかぱっと見でわからないっていうのはinterfaceの使い方が良くないんだと思う 必要なメソッドを理解しないまま使おうとしてるからわからなくなるんじゃない? >>394 393でコンパイルエラーが出て何の実装が必要かわかるんだから、それで問題ない気がするんだけど。 >>395 面白いしJavaとかより柔軟だよね。 もっとinterfaceを拡張してプロパティとか演算子のシンタックスシュガーをもっと付けて欲しいとは思う。 多分上手く拡張できればジェネリクスに近い感じになると思うんだけど >>396 ? そもそもIの存在を知らないような場合にそういうコードでチェックできないと思うんだが TにReadメソッドが実装されてる→よく読み進めるとIにはReadメソッドをもつ→TはIを満たしてるという思考の流れが気持ち悪い >>398 考え方がおかしい。元々の質問は >> 明示的にこのinterfaceを満たしてますよみたいなのが欲しい という話だから当然inteface “I”の存在を知っている前提。 構造体Tを作っていてそいつにinterface Iの実装を行いたいという場合に type T struct{} var _ I = T{} とういう風に書くと実装条件を満たすかをコンパイルエラーでチェックできるから 確実に実装できる。 もしかして定義済みの型がどのinterfaceを実装してるのか明示してほしいってことか でもそれGoのinterfaceの考え方じゃないよ >>400 アンカーつけないとなんに対しての反論かわからんのだが。 interfaceの概念はべつにGo独自とかそういうもんじゃないし Goのinterfaceの考え方ってなんのことを指してるのかよくわからんな。 基本的にはJavaと変わらんでしょimplementsが不要ってだけ。 >>401 >>400 は>>391 ,394,398あたりへの憶測 他言語のinterfaceは、imprementsすることでその型が何であるのかを説明するためのもの Goのinterfaceはオブジェクトが必要な機能を備えているか調べるためのもの だから考え方が違う >>402 なんかフワッフワした言い回しすぎて何を説明したいのかがわからんな。 interfaceは、英単語の意味そのものだよ。つまりはメソッド名とパラメーターの並びと、返り値の型の組み合わせそのもの。 それ以上でもそれ以下でもない。 基本的には言語として共通の概念と言える。 goとそれ以外の言語の違いは 型(javaの場合はclass)がinterfaceを満たす条件が違うってだけ。 条件の違いは java: interfaceを明示的に指定する go: interfaceと同じメソッドを、実装する PHPerだらけだったうちの会社もとうとうGoの勢いを感じて次のプロジェクトで使うことになった ISUCONの結果が地味に効いてる 経営陣はAWSの課金が減ることを期待してるみたいだけど、はたしてどうなることやら 他人の書いたソースを読んでて特定のinterfaceの実際の実装を見たい場合 どの構造体や型をみればいいのか探すのが面倒なことはまれによくある > Goのinterfaceはオブジェクトが必要な機能を備えているか調べるためのもの これって公式にどっかに書いてあるの? というかGoにオブジェクトって概念あるか >>407 guruが対応してるから簡単に探せるで vscならcmd+f12で実装を探す >>409 うん 手元にcloneしたソースはguruで探すけど githubでソース眺めてる時とかがちょっと困る >>406 GAE/GoでgRPC使えるんだっけ? GAE/GoやるならStandardで使いたいんだよね GAE/Go SEとgRPCは色々と苦しい 代替案として挙げられるのはGAE/Goとgoaあたり? GAE/Go Standardでも gRPC は urlfetch でいけるんじゃないの? やったことないからわかんないけど >>410 doxygenみたくinterfaceのコードのところがリンクになってクリックすると 実装一覧が出るようにしてほしいってことね。 バックエンドはGAE/Goとgoa フロントエンドはReactとReactNative(またはVue.jsとWeex) この構成でwebアプリ、スマホアプリを作りたい こういう開発者向けにRailsチュートリアル並に詳細かつ丁寧に解説してあるネット文献 あるいはAmazonで買える技術書が欲しい >>416 お前は俺か。俺の場合はreact-nativeだけノータッチだけど goaのDSL覚えるくらいならproto3やったほうがいいよね goaのほうがgRPCより優れている点が思い浮かばない 普通にweb apiを簡単に作れてswaggerと連携って魅力じゃないので? goaはWebAPI作るのには便利だけどそれ以外のケースであまり融通が聞くとは言い難い そもそもWebAPIならどのフレームワークで作っても大差はない goaはGo言語で記述するDSLからGo言語の各種ソースコードを自動出力する gRPCは言語非依存のprotoファイル(IDL)から対応言語(Go言語以外のメジャーな言語に対応)の各種ソースコードを出力できる 汎用性が全然違う 企業目線だとgRPC選ぶのが多いんじゃないかな 実際にメルカリ、DeNA、CA、その他スマホアプリ大手のバックエンドはgRPCだし GAE/Go SEで何の苦労もなくgRPCが使えれば平和になれそう go-json-restはどうなん?正直これぐらいが一番好きなんだが >>422 いやいやwebapiならgoa一択だと思うんだけど。もちろんゼロから構築という前提でですが。 gRPCならprotoを覚えるとGoのサーバーサイドも自動生成って認識で合ってる?DBとのつなぎ込みの部分はどう書くの? goaやgRPCは「定義ファイル→ソースコード&ドキュメント生成」 go-json-restは直接ソース弄る系だからアプローチが全然違うな goaもgRPCもDBまわりのビジネスロジックは手書きです そこまで忖度はしてくれませんよ >>428 ですね。アホな質問しました。 goaだとフレームワークも含めた形でコード生成するんですが protoによるgRPCの場合はどうなのかなーと。例えばミドルウェアはサポートしてます? goaもv2でgRPCをサポートするっぽいんですが、protoでのサーバサイドGoコード生成がいい感じならお役ゴメンもあり得るんですかね。 自動生成されたサーバーのハンドラ部分を各種フレームワークに繋ぐだけ フレームワーク上のミドルウェアとも組み合わせることが出来る ちなみにちょっとググったらjsからgRPCは使えないみたいですね。 reactNativeからは使えるんですかね。 jsから使えないのは痛い read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる