Goのインターフェース抽象度を美しく保つ為の思考 - 好奇心に殺される。
Go Goのインターフェース抽象度を美しく保つ為の思考 Goで抽象化を適切に、そして美しく保つ為の自分の考えやTipsを紹介します。 Overview とある場面でGoのinterfaceが持つ振る舞いの抽象度について議論があり、今回はそれをアウトプットしておきます。Go初心者でinterfaceを使った設計に苦手意識を持つ人向けです。 目次 今回の目次です！下記について自分の考えをお話しします！ 振る舞いの抽象化の度合いを意識する 抽象度をどこまであげるか 引数や返り値から発生する「抽象化の漏れ」 抽象度をあげる為の統合 Getter/Setterと抽象度 それではいってみましょう！ 振る舞いの抽象化の度合いを意識する 振る舞いをinterfaceとして定義していくのがGoの抽象化ですが、そもそも 抽象化は度合いのある概念です 。この度合いを意識しないと適切なinterfaceの設計は困
プロジェクトのCIを20分弱早くした
はじめにこの時期だと ○○ Advent Calendar の N 日目です となりそうなんですが特に何もないです 担当しているプロジェクトの CI を早くする事が出来たので自慢したい備忘録の記事になります どのぐらい早くなったのかというと before after 20 分程度早くなりました CI が遅いと push してからテスト結果出るまで 20 分待たないといけないストレスはもちろんなんですが、 本番にリリースする際も CI を実行し、テストが成功してからコンテナのイメージを作成していたため、 本番で何か問題があった場合に修正してからリリースするまで 最低 20 分掛かかってしまうという状況でした (幸いにも急いでリリースしないといけない状況にはなりませんでしたが) やったこと の前にどんな事をして早くしたのを紹介する前に、開発/CI を行っている環境を説明します 担当しているアプ
kamipo TRADITIONALでは防げないINSERT IGNOREという名の化け物 | おそらくはそれさえも平凡な日々
インスパイア元→kamipo traditional (というかSTRICT_ALL_TABLES) では防げないMyISAMという名の化け物 タイトルが全てです。ピンときた方は読み進む必要はありません。 データがなかったらINSERTして欲しいけど既に入っている場合には何もして欲しくないみたいな処理をするときに、 INSERT IGNORE を使ってしまうことがありますが、 INSERT IGNORE はユニークキー制約違反だけじゃなくて、あらゆるエラーをIGNOREしてしまいます。つまりkamipo TRADITIONALすらIGNOREしてしまうのです。なので使わないほうが安全です。 様子です。 mysql> SET SESSION sql_mode='TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BY'; Query OK, 0
MySQL 一度DELETEしたuserと同じ名前のuserを登録しようとすると失敗する - 【はてな】ガットポンポコ
うーん。MySQLのバグなんだろうか、一度DELETEしたuserと同じ名前のuserを登録しようとすると失敗する。 やったことはこう。 DELETE 構文で user 'boss' を削除する。 mysql> DELETE FROM mysql.user WHERE user='boss' and host='localhost'; CREATE USER 構文で boss を再度作ろうとしたが、失敗。 mysql> CREATE USER 'boss'@'localhost' IDENTIFIED BY 'password'; ERROR 1396 (HY000): Operation CREATE USER failed for 'boss'@'localhost' MySQLクイック・リファレンスによると、 本来のユーザ削除はこうらしい。先にREVOKEをやらなかったからいけないの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
