GitLabのIssue運用で悩んでいること

本文書の目的 完全にポエムです。悩みを書き連ねただけです。 GitLabでもGitHubでも同じことになるのではないかと思います。 この文書に有用な情報は含まれません。 前提条件 SIer テスト担当者が存在する 顧客とGitLabを共有できない(ので別の不具合管理表Excelがある) お約束事項 プルリクエスト(以下PR。GitLabではマージリクエストだが通りが良いのでPRと呼ぶ) 運用 基本的な運用フローとして、 バグ発生→Issue作成→担当者修正→テスト担当者テスト→リリース ソースコードの修正フローは 開発者ブランチ→PR→developmentにマージ→社内検証環境[...

キーボードを選ぶ時の観点

こんなにあるキーボード選びの観点 Twitterに書いては消し書いては消しするとアレなので書いてみる キー配列 日本語 or 英語 Windowsキー有無 マクロキー有無 テンキー有無 やじるしキーの配列が逆T字必須 or どうでもいい CTRLキーの位置 方式 メカニカル メンブレン バックスプリング パンタグラフ 接続 有線 無線(USB) 無線(BlueTooth) 刻印 印字方法...

API設計をしたときにしくじったこと

API設計をしたときにしくじったこと 今、関わっているWebアプリケーションのAPIを設計する際に しくじったことを列挙していくポエムです。 しくじり1 応答メッセージの基本形を決めずに作っちゃった APIを使うクライアントも自分で作る状態だったので、とりあえず 行き当たりばったりで進めていった結果、共通のお作法が存在しない状態に なってしまった。 しくじり2 HTTP応答コードだけでエラーを表そうとしてしまった 大抵は、応答コードだけでなんとかなります。ただし、更新時のバリデーション エラーなど、何がどうエラーだったのかを返そうとすると、応答コードだけでは 全然足りません。そして、エラーの返し方を共通化しておかないと、APIによって エラー発生時の応答が変わってしまい、クライアントを作る人が悲惨です。...