jOOQ と Flyway で立ち向かう、自社サービスの保守運用 #jjug_ccc #ccc_ab1
2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。
これまでに、(主に)Amazon Redshiftで活用出来るGUIツールとして『Intellij IDEA Ultimate Edition』や『Aginity』等を紹介して来ましたが、Intellij IDEAを開発しているJetBrain社から別種のDB関連ツールが開発されているという情報を先日知りました。 Amazon RedshiftのMac OS X向けGUIツールとして『Intellij IDEA Ultimate Edition』のDatabase Toolsを使う | Developers.IO Redshift専用 Windows GUIツール『Aginity Workbench for Amazon Redshift』が便利かもしれない件 | Developers.IO それがこの『0xDBE』と呼ばれるものになります。アナウンス自体は1年以上前からなされていた様で、
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
オープンセミナー2015@香川の登壇資料です。 http://connpass.com/event/15646/
やばい本を見つけてしまった。 最近、Kindle Voyageを買って、初めて電子書籍デビューすることになったんだが、何か面白い本ないかなーと思って、Amazonをふらついていたら、とてつもなくやばそうなスメルがする本を見つけてしまった。 その名も「Fuzoku実践入門」 http://www.amazon.co.jp/gp/product/B00P4X25HO 俺の家にもにいっぱいある、何かひじょ〜に見覚えのある表紙。 一見すると、Fuzokuというプログラミング言語か、ソフトウェア、あるいはウェブテクノロジーがあるではないかと思わせんばかりの風貌。 しかし、そんな言語もソフトもサービスもない。いや、ある意味、サービスはあるのか。 これどうみてもアレだよ、技術◯論社のWEB+DB ピー(自主規制)シリーズだよ。 とまぁ、同人パロディ的なノリの本で、普通なら華麗にスルーするところなのだが、
どうも、プラットフォームDivでエンジニアをやっている Wataru です。 最近3人目の子供が産まれて、産後自宅勤務をさせてくれた弊社はとてもいい会社だと思います。出産予定のあるエンジニアのかたは是非弊社に転職を。 さて、今回はRedisの紹介をさせて頂きたいと思います。 Redisってすごくマイナーなわけではないのですが、めちゃくちゃ便利なのにあまり注目されていないなーという印象があるので、これを機会に是非使ってみてもらえると嬉しいです。 Redisって何?Redisとは「remote dictionary server」から名前が付けられたオープンソースのkey-valueデータストアです。 MemcacheDB等のKVSとの最大の違いは、格納するバリューがデータ構造というところです。 つまり、リスト・セット・ハッシュなどのデータ構造で格納できるのでバリューに対してアトミックな操作が
はじめに なぜPythonを選ぶか かなり独断と偏見が入っていますが、 シンプルな言語セット 某言語のように、呪文のように短く書けることが命ではない。 それでいて、書くコード量は少なく、すっきりしている。 某言語のように、記号を多用しない。 コードを書いている間Shiftキーを押しっぱなしにならない。 学習コストが低い。 言語セットとしての文法は、わりと平易で、直感で理解できる。 難しい書き方は、後から覚えればよい。 文法書を読むのは、後からでいいでしょう。まずこの講座をやってみましょう。 Djangoフレームワークや、各種Pythonパッケージのソースを読んでも、 言語仕様を駆使した難しい書き回しは少ない。 メンテナーでなくても意外と読める。 なぜDjangoを選ぶか Pythonで作られたフルスタック・フレームワークであるということ。 必要なものはすべて揃っている。 テンプレートはあれ
それほどDBに詳しくないアプリエンジニアが何かトラブった時にすぐさま行動して問題把握できるようになる情報を列挙しておきます。 開発時、障害時の対処療法やちょっとした定期監視方法などを対象にしています。 抜本的な対策などはインフラエンジニアさんにお任せしたほうがいいと思います。 DBはいろんな意味でこわいんでできれば触りたくないです>< 事前確認 MySQLサーバーのシステム設定値を確認しておく 以下のようにサーバーのシステム設定値を確認できます。 mysql> SHOW GLOBAL VARIABLES; # ワイルドカード(%)を用いた絞り込み mysql> SHOW GLOBAL VARIABLES LIKE 'performance_schema%'
想定していること † MySQL5.0 MySQLがすでに稼動中。レプリケーションの設定はしていない 今回MySQLをもう一台増やして2台構成とし、master、slaveの構成にする ※今回と状況が異なる場合は、MySQLのリファレンスマニュアルを読むといいです。 ↑ 1. レプリケーション用ユーザを作成する † レプリケーション用ユーザを作成する 作成するユーザーはスレーブがマスタのバイナリ ログを読み込むときに接続するユーザーとなる。 既存のユーザーでもレプリケーションは可能だが、ユーザ名とパスワードが master.info ファイル内にテキストで保存されるため、安全のためレプリケーションプロセスにだけ権限があるユーザを作成する 設定例(マスタのほうに設定) 192.168.23.0/24 内のネットワークで許可 ユーザー名:repl パスワード:slavepass mysql >
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く