Poem

A collection of 3 posts

5月 29, 2017

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

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

3月 18, 2016

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

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

3月 17, 2016

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

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