Author: t.yoshihara

  • Go + Echo で WithInternal/SetInternal を使うとエラーレスポンスのカスタマイズがうまくいかないことがある

    Go + Echo で WithInternal/SetInternal を使うとエラーレスポンスのカスタマイズがうまくいかないことがある

    Go 言語の Web アプリケーションフレームワークである Echo に関する小ネタです。 執筆時点 (2024/10/01) での Echo フレームワークのバージョンは v4.12.0 です。将来のバージョンでは挙動が変わる可能性があるのでご了承ください。 先にまとめ 前提知識1:NewHTTPError() 関数によるエラーレスポンスの返却 Echo では echo.NewHTTPError() 関数を用いてエラーレスポンスを返却することができます。 echo.NewHTTPError() 関数の第二引数に “エラーメッセージ” のような文字列を渡した場合、デフォルトでは {“message”: “エラーメッセージ”} というようなレスポンスボディが返却されます。 文字列の代わりに構造体を渡すことで、レスポンスボディを自由にカスタマイズすることも可能です。 echo.NewHTTPError() 関数の戻り値の型は *echo.HTTPError で、この型は error インターフェースを実装しています。そのため error 型の変数や戻り値として扱うことができます。 前提知識2:WithInternal()/SetInternal() メソッドによる内部エラー情報の設定 *echo.HTTPError.WithInternal()/SetInternal() メソッドを用いることで、echo.NewHTTPError() 関数などで作成した *echo.HTTPError に内部で発生したエラー情報を付与することができます。 この内部エラー情報はレスポンスボディには含まれませんが、サーバーのエラーログ等に出力させることができます。 前提知識3:Bind() メソッドによるリクエストのバインド echo.Context.Bind() メソッドを用いることで、リクエストのクエリ/パスパラメータ、ヘッダー、リクエストボディを構造体にバインドすることができます。 本題 ここからが本題です。 以上のようなコードで作成したサーバーに対して、以下のようにリクエストを送信するとどのようなレスポンスが返却されるでしょうか。 リクエストボディは意図的に不正な形式(”age” が数字でない)にしています。 実際に送信してみると以下のようなレスポンスが返却されます。 {“error_code”:1,”reason”:”リクエストが不正です”}…

  • GORM + PostgreSQL で double precision を使う場合は float8 を指定すると良さそう

    GORM + PostgreSQL で double precision を使う場合は float8 を指定すると良さそう

    GORM で PostgreSQL を利用する場合の小ネタです。 執筆時点 (2024/04/06) での GORM のバージョンは v1.25.9、GORM PostgreSQL Driver のバージョンは v1.5.7 です。将来のバージョンでは挙動が変わる可能性があるのでご了承ください。 先にまとめ 準備 以下のような compose.yaml ファイルを用意して、Docker Compose で PostgreSQL を起動できるようにしておきます。 本題 GORM で float64 型のフィールドを持つモデルを定義して AutoMigrate すると、PostgreSQL 上では decimal (numeric) 型のカラムを持ったテーブルが作成されます。 実行してみます。 ログを見ると、確かに decimal 型のカラムを持ったテーブルが作成されていることがわかります。 しかし、場合によっては decimal ではなく PostgreSQL の倍精度浮動小数点データ型 (double precision) で格納したいこともあると思います。 そこで、gorm:”type:double precision” を指定してみます。 ログを見ると、今度は double precision 型のカラムを持ったテーブルが作成されていることがわかります。 しかし、この状態でもう一度…

  • HTML + JavaScript でテトリスもどきを作る

    HTML + JavaScript でテトリスもどきを作る

    HTML + JavaScript でテトリスもどきを作ってみると意外と簡単にできて結構楽しい

  • [Python] aws-requests-auth で Lambda から IAM 認証つきの API を簡単に叩く

    [Python] aws-requests-auth で Lambda から IAM 認証つきの API を簡単に叩く

    AWS Lambda から IAM 認証のかかった API を呼び出したいという場合があります。 この場合、Lambda に適切な IAM ロール(ポリシー)を付与し、かつ API 呼び出し時に署名を行う必要があります。 Python では、aws-requests-auth というライブラリを使用すると簡単に署名を行うことができます。 API の準備 IAM 認証のかかった API を用意します。リージョンは ap-northeast-1 と仮定します。 今回は GET /hoge を叩くと {“message”: “hoge”} が返ってくるように設定しました。 この API に IAM 認証をかけ、デプロイしておきます。 ステージ名は api としました。 黒く塗りつぶしている箇所は API ID です。 Lambda 関数の作成 API を呼び出す Lambda 関数を作成します。 ロールには基本的なポリシーに加え、以下のようなポリシーを設定します。 Resource は arn:aws:execute-api:(リージョン):(アカウントID):(API ID)/(ステージ)/(メソッド)/(リソースパス) のような形式で指定します。…

  • アジャイル開発に入門する2020――今すぐ読みたい3冊を紹介

    アジャイル開発に入門する2020――今すぐ読みたい3冊を紹介

    PC を新調して今更 Minecraft を始めました、開発3年目くらいの吉原です。サーバー構築の記事(一つ前の記事参照)助かります!!! 俺はソロだが…… ブログぜんぜん書いてないから書けって言われたので書きました! これが所謂ブログ書けハラスメント通称ブロハラというものでしょうか……(これは冗談ですが、どうしたらもっとブログが活発になるかは考えた方がよいかもしれません)。 アジャイル開発 さて、皆さんは「アジャイル開発」を知っているでしょうか? 当たり前、という人もいれば、聞いたことはある、くらいの人もいるかと思います。 今年の3月に IPA からアジャイル開発版「情報システム・モデル取引・契約書」が出たり、アジャイルに関する日本語の書籍も多く出版されてきているように、日本においてもアジャイル開発は徐々に広まってきている、或いは広まるための土台は作られてきているのかなと感じています。 ですが、弊ラボでは正直なところ未だアジャイルという概念はあまり浸透していません。私も去年くらいまでは「アジャイルって何?」側の人でした。そのため、もしかしたらアジャイルについて全く知らない人や、誤解している人もいるかもしれません。そしてこれは推測に過ぎませんが、同じような状況にいる人も多いのではないかと思います。 私がアジャイル開発に興味を持ったのは、プロジェクトが思うように進まず、どうしたらソフトウェア開発・システム開発が「うまくいく」のか調べていたときでした。 最初は要件定義や設計など、上流工程のフェーズがしっかりできていないことが問題だと考えました。そのため、要件定義や設計に関する多くの書籍やブログ記事などを読みました。(余談ですが、私が特に興味を惹かれたのは「ドメイン駆動設計」でした。これについてもそのうち紹介できたらなと思います。)そのうちいくつかの本や記事は、「アジャイル」という単語に触れていました。これは一体なんなのだろうと思い、次第にアジャイルに関する書籍やブログ記事も読むようになりました。 これは正解でした。少なくとも、アジャイル開発に関する書籍やブログ記事を読むことは、私にとってとてもエキサイティングでした。勿論『人月の神話』や多くの人々によって語られているように、銀の弾丸はありません(少なくとも今のところあるとは思われません)。しかし、アジャイルには、これなら本当にソフトウェア開発・システム開発が「うまくいく」かもしれない、そう思わせてくれるものがありました。アジャイルは、それ自体もそうですが、大きな思考の転換を齎してくれたことが最大の魅力だったのかもしれません。 弊ラボでもアジャイルを「よりよい開発」に役立てて行きたい! そんな思いから、本や記事を読むだけでなく、実践に繋げていこうと考えています。 今回、去年〜今年にかけて出版されたアジャイル初心者向けの書籍を3冊ほど読んでみたので、社内への布教も兼ねて紹介してみようと思います。「アジャイルって本当に役に立つの?」という人も、或いは「アジャイルはじめました!」という人にもおすすめできる3冊になっていると思います! 『みんなでアジャイル――変化に対応できる顧客中心組織のつくりかた』(オライリー・ジャパン) アジャイルを、原則(なぜ)とプラクティス(どうやって)が互いに連携した「ムーブメント」として捉え、道を踏み外さぬように(或いは道を踏み外してもすぐに戻れるように)アジャイルの旅を手引きしてくれる入門書です。 本書ではまず「顧客から始める」「早期から頻繁にコラボレーション(協働)する」「不確実性を計画する」といった3つの原則を紹介していきます。本書の良いところは、プラクティスや実践方法も紹介しつつ、常にこの原則に立ち戻ることの重要性を理解させてくれるところです。これにより、例えばアジャイルプラクティスにただ表面的に従っているだけで成果に繋がらない、というような状態に陥ることを避けることができるというのです。 また、「そもそもなぜアジャイルを採用しようとしているのか?」「チームや組織のゴールは何なのか?」といった難しい質問に答えることの重要性にも気付かされます。 今の所アジャイルの入門書としては第一に薦めたい本です。「みんなで」とある通り、開発者やマネージャーだけでなく、セールスやマーケティング、顧客など、どんな人にも薦められる本となっています。しかし多少意味をとりにくい部分などもあるため、読みにくい場合は他の本を読んでから再挑戦してもよいかもしれません。 見た目的にも分厚い本ではないので、取っ付き易いのではないかと思います! (届いたときは思ったより薄くて驚き、その中身を読んでその内容の濃さに再度驚きました) 『レガシーコードからの脱却――ソフトウェアの寿命を延ばし価値を高める9つのプラクティス』(オライリー・ジャパン) 本書は「IT エンジニア本大賞 2020」にも選ばれた本であり、目を通した方も多いのではないでしょうか。タイトルにこそアジャイルとはありませんが、「レガシーコード」に対処するための選択肢としてアジャイルソフトウェア開発を取り扱っています。 前半では「レガシーコード危機」と題して、「100 億ドル単位の損失」などといったショッキングなデータを持ち出し、ソフトウェア開発を「何かが間違っている」「素人業界」と辛辣に批評しています。しかし、そんな中でも成功しているプロジェクトはあり、賢人たちによる新しいアイデアによってソフトウェア業界は正しい方向に動き始めているとします。 後半では副題にもある通り、レガシーコードに対処する、或いは最初からレガシーコードを作り出さないための9つのプラクティスをその原則とともに紹介しています(原則とプラクティスが不可分なのは先に述べたとおりです!)。プラクティスは、多くがアジャイルやエクストリーム・プログラミング (XP) に由来するものです。 本書は比較的技術プラクティスを重視する姿勢が感じられます(勿論、原則を理解していなければならない、ということは再三再四注意されます)。原則なきプラクティスはうまくいきませんが、原則だけでプラクティスがなくてもまたうまくいきません。先の『みんなでアジャイル』と合わせて読むことで、原則とプラクティスの両面からアプローチできるのではないかと思います。 なお本書では「ウォーターフォールはレガシーコードを作り出し拡散する」などと批判しつつも、ウォーターフォールのような開発であろうが、或いはどんな方法論を使用していようが、これらのプラクティス(エクストリーム・プログラミングのプラクティス)は役に立つと述べています。アジャイルに必ずしも興味がなかったとしても、本書を読むことで多くの発見ができるでしょう。 読み物としても面白い本ですが、その分やや記述が冗長で纏まりがないと感じられることもあるかもしれません。また、プラクティスが理解しにくい、読みにくいと感じたら、そのプラクティスに特化した書籍を読んでみることをおすすめします。最初の数プラクティス(「やり方より先に目的、理由、誰のためかを伝える」「小さなバッチで作る」等)はアジャイル由来の部分が大きいため、『アジャイルサムライ』(オーム社)などを読んでみるとよいかと思われます。 『SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発』(翔泳社) 本書は 2013 年に発売された同名の本の改訂版です。私は改定前の方を読んでしまい、この増補改訂版は読んでいないため(すみません!)、以下は改定前のものについての話となります。 本書はアジャイルのフレームワークの1つであるスクラムを中心に解説した本です。最大の特徴は漫画仕立てで読みやすいことです! かつ、これ1冊でスクラム開発を始めるために必要な知識が一通り揃うようになっています。 アジャイルについてはなんとなくわかってきた(?)けど実際にどのように進めようか、と思ったとき、まずはスクラムに挑戦してみるということもあると思います。その時に是非チームで、或いは周りの人々も巻き込んで一読したい本です。 改定前のものを読む限りでは構成は大きく「基礎編」と「実践編」に分かれていて、「実践編」部分をレファレンス的に使うのは少し難しいかなと感じました。その場合は『エッセンシャル スクラム』(翔泳社)などをおすすめします。改訂版ではスクラムのルール変更に対応する等全面的に見直しを行っているとのことなので、改訂版も是非読んでみたいと思います! まとめ 在宅勤務をしていたとき VTuber(バーチャル Youtuber)の面白さに気づき、特に最近はホロライブの動画をよく見ていました(決してサボっていたわけではなく、通勤時間等が浮いたためです。本当です!)。そして、視聴数やチャットの流れる速度がえげつない VTuber を見るたびに、私もたくさんの人に本物の価値提供をしていきたいと思うようになりました。アジャイルへの入門がその一歩になればと思っています。 会津ラボでは本物の価値を提供したい人を募集しています。 (なぜかアプリケーションプログラマの募集が多いですが、システムの設計開発やアジャイル・DevOps…

  • AWS Lambda で Python みたいな関数型言語 Coconut を動かすぞ!!!!!!!(非カスタムランタイム)

    AWS Lambda で Python みたいな関数型言語 Coconut を動かすぞ!!!!!!!(非カスタムランタイム)

    みなさんはじめまして!!!!!!!!!!!! 会津ラボで主にバックエンドの開発を担当している吉原です。他にブロックチェーン等もやってます。好きな言語は Haskell、趣味はクイズゲームです。以後お見知りおきを。 ※ ちなみに弊社には吉の字がつくバックエンド担当が2人おり、度々間違われます。当ブログをご覧になる場合はご留意ください。 さて、今日(注:執筆開始時点)はお盆です。 ……お盆も働いていたやつらだ。面構えが違う。 というのは冗談で、お盆休みをずらして取得しているため、その代わりに出勤しています。こういったことができる所も会津ラボの魅力の1つかなと思います。 閑話休題。 みなさん、Haskell してますか? え? Haskell って何? いますぐすごい H 本(Miran Lipovača『すごい Haskell たのしく学ぼう!』 オーム社)を読んでください。 Haskell は一般的に関数型言語と呼ばれるプログラミング言語の1つです。その中でも強い静的型付けの純粋関数型言語といったようなものになります。要するにつよい。 でもお仕事で Haskell を書くことはほぼありません。 なんでや! こんなにかわいいのに…… みんな、Haskell、書こう。 ……嘆いていても仕方ありません。じゃあ普段はどんな言語を使っているかといいますと、最近は主に Python とか JavaScript です。 みなさん、JS 好きですか? ……誤解を招きそうなのでもう一度。JavaScript 好きですか? ……なるほど。まあ私も JavaScript よりは Python の方が好きです。Python はいいですよね。シンプルで読み書きしやすいし、あとロゴがかわいい(重要)。 でもずっと Python を書いていると、ついこう思ってしまいませんか? もっと関数型したい…… Python はラムダ式やイテレータを始め、一般的に関数型プログラミングと呼ばれるスタイルにおいて有用な機能を多く持っています。 でも……もっと関数型の力が欲しくないか……? もっと軽率に関数合成したり、部分適用したり、パイプでつなげたり、パターンマッチしたり、あわよくば代数的データ型を使ったりしたくないか……? そこで登場するのが Coconut というプログラミング言語です。 Coconut http://coconut-lang.org/…