障害から学ぶクラウドの正しい歩き方について考える - そーだいなるらくがき帳
AWSで大きな障害が発生したこの機会に、自分がクラウドと正しく付き合っていくために必要なことを考える。 piyolog.hatenadiary.jp ちなみに稼働率 99.99% くらいを目指していくために必要な事を考える。 必要な稼働率を見極める 今回は 99.99% くらいを目指すと言ったが、実際に自分たちにとってどのくらいの稼働率を目指すか？ということはとてもとても大切だ。 幸い、今回自分は影響がなかったが、本当に完璧か？と言われるとそうではない。 まず弊社の場合、マルチリージョンではないので東京リージョンが落ちたら落ちる。 これを許容できない場合に99.99%を目指せるか？というと正直厳しい。 しかしサイトの規模はそんなに大きくないのでデータサイズも現実的に転送出来る範囲で、コンポーネントも少なく、TerraformやAnsibleによって再構築しやすい状態は整っている。 そのため
フレームワークは素晴らしいけど抽象化した箇所は忘れないでねって話をします - そーだいなるらくがき帳
Laravelカンファレンスでの登壇資料です。 conference2019.laravel.jp ガッツリ、データベースの話とかPerformanceの話でロックとか内部構造の話してもいいかなって思ったけどLaravelのカンファレンスなので表題の事をテーマに資料を作りました。 この辺の話は知ってる人からすると知ってる話なので先に資料を見てから話を聴くSession決めるのがオススメです。 内容自体はフレームワークを使ってたらハマりがちなRDBMSのボトルネックについてざっくりまとめました。 30分で話するにはテーマが大きいのでこのセッションで気になることとか、その他知りたいことがあれば当日気軽にご質問ください。 Ask the Speakerでも良いし、ロビーで普通に話掛けていただいてもいいし、Twitterでも構いません。 JOINのアルゴリズムは id:ikkitang1211 の
Webサービスを支えるモニタリング - そーだいなるらくがき帳
って話をPHPカンファレンス仙台でします。 そこでいつもどおり事前に資料を共有します。 ここに書いてる通り、モニタリングを始めたい人、悩んでる人は入門監視を読んでほしいです。 私がこのCfPを出す前は発売されると知らず、登壇直前に発売されるという登壇者殺しのタイミングでしたが、登壇前に買って読んで本当に良かったです。 スライドにもあるのですがパターンであったり、数値の見方だったり、私がMackerelのCREの時に学んだこと、自分たちの監視を見直す為に必要なことは書いてあります。 本当は前回からもう少し進んで登壇内容はデザインパターンだったり、アーキテクチャの監視の話だったりを話すつもりだったのだけど、それは入門監視を読めば解決するので具体例を出すことにしました。 これくらいなら自分たちも始めれるのでは？みたいな気持ちにアプリケーションエンジニアがなってくれることがゴールです。 私自身、こ
適切な問題と文化がサービスを育てる - そーだいなるらくがき帳
って話をPHPカンファレンス2018でしてきます（1時間後に過去形になります って話をPHPカンファレンス2018でしてきました。 2018/12/16時点で動画とFAQの内容を追記しています。 phpcon.php.gr.jp 当日の登壇資料はこちら。 当日の動画です www.youtube.com ※ 5:41:20 くらいからが僕の動画です。 ※3ヶ月以内を目処にセッション毎に割ってくれるみたいです 内容補足 Webサービスは成長と共に変化していくので、つまりは変化に強いチームというのは重要になります。 では変化に強いチームとはどうやってつくるのか？って話が今回のテーマです。 チームビルディングってとても重要なのは周知の事実だけど、じゃあどうやって？って言うHow toは意外と語られません。 それは「答えが無い」ってのもありますが、プレイヤー目線とマネージャ目線（経営者も含む）で大き
MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳
結論 何がいいたいかといいますと0000-00-00 00:00:00があるとORMも死ぬし、DBマイグレーションツールも死ぬし、そもそもMySQLからポスグレにデータを持っていくこともFDWをすることも出来なくて死ぬのじゃ。— そーだい@初代ALF (@soudai1025) 2018年4月25日 色々困るので使わない。 理由 以下に理由を述べる SQL標準ではない 正論で殴った場合。 0000-00-00 00:00:00の仕様が難しい 0000-00-00 00:00:00 はMySQLの独自な仕様で NOT NULL制約のカラムではNULLと等価であり、NULLではない という仕様がある。 "NOT NULL として宣言された DATE および DATETIME カラムでは、次のようなステートメントを使用することで、特殊な日付 '0000-00-00' を検索できます"https:
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
Github projectsが実際に使えるレベルになっていたのでみんな使っていいと思う - そーだいなるらくがき帳
GithubのカンバンツールであるGithub Projectsはリリースされて1年以上経っている（2018/04/10現在） 僕が当時、使えるかなって思って試した感想は下記の人とほとんど同じような感想だった。 qiita.com 以下、引用。 projectページ内でissueを作成することができないことも率直に不便を感じた :thought_balloon: issueをcloseしたり、PRがmergeされたら自動でclosedのカラムへ移動してほしい。 「自分の担当issueのみ進捗管理したい」などのニーズは容易に想定できるので、projects内のフィルタリング機能がほしい 上記に対して改善しているポイントを述べていく。 Projectsの中で作ったカードをissueに登録できる 該当のカラムの中でカードを作ることが出来る。 これはissueとは別の独立した存在でissueには登
エンドポイントの監視 ~ mackerel-plugin-jsonを読み解く - そーだいなるらくがき帳
この記事は Mackerel プラグインアドベントカレンダー(全部CRE） の24日目です。 qiita.com soudai.hatenablog.com それでは24日目は mackerel-plugin-json です。 mackerel-plugin-jsonはその名のとおり、JSONを可視化するプラグインです。 github.com 2020/12/02 追記 めちゃめちゃ便利なmackerel-plugin-jsonも進化していて、下記に出てくる多くの問題点が解決しています。 インストール カウンター値の計算 header付与によるセキュリティ これらを解決した機能の説明についてはこちらをご参照ください。 cohalz.co インストールと設定手順 mackerel-plugin-jsonのインストールですがmackerel-plugin-jsonは公式パッケージに同梱されてい
誰と一緒に働くかってめっちゃ大事って話 - そーだいなるらくがき帳
表題の件を吉祥寺.pmの懇親会で話をしてきた。 吉祥寺.pmについて kichijojipm.connpass.com なお、吉祥寺.pmのPはPostgreSQL、MはMySQLと伺ったのでいつも通り、@yoku0825 さんとキャッキャウフフしてDBについて話をしてきた。 github.com 細かいことは #kichijojipm のハッシュタグを追いかけてくれるといいですがまぁ15分の話なので大した話はしてないです。強いていえば中国地方DB勉強会って最高のDBの勉強会があるよって話しました。 dbstudychugoku.github.io 本題 はい、前置きが長くなりましたがめっちゃ楽しかった吉祥寺.pmですが更に懇親会でもホント色んな人と話が出来て最高でした。その中で表題の事について色々考えたり話をしたりしたのでメモを残します。 例えば僕がはてなを選んだ理由には id:Song
敢えてアウェーで戦う事に意味があるって話 - そーだいなるらくがき帳
YAPC::Kansaiで id:takesako さんからすごくいい話を聞いたのでみんなにおすそ分け。 yapcjapan.org スピーカー控室。 多分10:00くらいの1時間、みんなセッションを見に行ってて竹迫さんと二人っきりになりました。 竹迫さん Yoshinori (y0sh1) (@takesako) | Twitter 発端 僕はSECCONの人として竹迫さんの事を一方的に知っていて今回のゲストスピーカーのしかも基調講演ですし「うぉー二人っきりだ！どうしよ！！」ってドキドキの中、同郷をネタに話かけました。すると竹迫さんは柔らかく応えてくれました！ その中で色々と地元トークをしてる中で僕が「僕は今回東京に引っ越して右も左もわからないんですよね。今日もPerlのイベントで僕は普段からPerl書かないし、すごくアウェー感あります。」とボヤきました。そこで竹迫さんは「それめっちゃチ
早くチームにマッチするために気をつけてる事 - そーだいなるらくがき帳
新入社員として1週間が過ぎた。 ブルックスの法則的に考えても私はまだチームにとって生産性をマイナスさせる存在でしかない。 ブルックスの法則 - Wikipedia だからいち早くチームにとって必要な存在になる必要があるし、そのために気をつけてる事をメモする。 これを見て「もっとコレした方がいいよ」ってアドバイス、逆に「それは不要だよ」ってアドバイスを期待してる。 チームやプロダクトを好きになる これはとても大切なことだ。 嫌いな人とは仲良くできないし、嫌いなプロダクトは育てれない。 もし、コレを読んでる人が職場のチームもプロダクトも嫌いなら転職した方がいい。 ただ好きの反対は無関心なので無関心の場合は条件付きでやっていけると思う。 この辺の話は主旨が変わるのでまた別の機会があれば話したい。 コミュニケーションについて 新しいチームに合流してまず一番大事なのはコミュニケーションコスト。 自分
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
