若者から学ぶISUCONの正しい歩き方 - 本戦に参加してきました - そーだいなるらくがき帳
ISUCON10 本選、終了いたしました。ご参加いただきありがとうございました！各賞の受賞者や全スコア、利用言語などは来週あらためてブログで公開しますが当日の日程を終えました。運営チームと、ご協力いただいた並行チームの皆さんで1枚！応援していただいた皆さんもありがとうございました。 #isucon pic.twitter.com/qNJuMIbcJ0— ISUCON公式 (@isucon_official) 2020年10月3日 予選落ちのチームの中から並列チームとして、本戦の問題を配信用に解く人として参加してきました。 予選と同様に過去の問題作成者の id:kamipo と 優勝経験者の id:sugyan とisucon愛枠ってことで id:Soudai の3人で出てきました。 github.com ISUCON10 本選結果は以下の通りです！ おめでとうございます🎉 第1位 tak
障害対応時にまずはissueを作ると良い - そーだいなるらくがき帳
先日のAmazon SQSの障害には色々と肝を冷やした人も多いのではないでしょうか。 classmethod.jp 今回のようなケースとは別に障害は大小あれど、みなさん日々戦っていることだと思います。 障害対応はエンジニアの花形であるものの、サービスに対する知識やソフトウェアの知識など経験と技術の両方が必要です。 そのため、どうしてもトラブルシューティングはエースエンジニアなどの一部の人に依存してしまう…などの問題が発生しがちです。 そこで今日は私の経験から障害対応のいろはを書いて行きたいと思います。 今回のスコープの外 実際に障害時の具体的な対応、例えば障害切り分けやRDBMSのボトルネックの探し方などの話はしません。 まずissueを作ると良い 本題です。 トラブルを認知したらまずはissueを作りましょう。 issueを作るときはtemplateが事前に設定されていると便利です。 g
2020年の抱負とお知らせ - そーだいなるらくがき帳
2020年も始まりました。 2019年、色んなチャレンジを通じて成長を感じる反面、 35歳定年説を考えたりする程度には 心技体の限界を感じたりもしました。 しかし周囲の叱咤激励や自分自身を振り返ってみる *1 と、結果的に小さくまとまってしまい、爆発的な成長に必要な大きなチャレンジが出来てないという結論になりました。 これは弊社の恵まれた環境や東京と言う立地、コミュニティの方々の多くの支援を受けている現状の縁によるものが大きく、感謝しても感謝しきれないほどありがたいことなのだけど、そこに甘えるにはまだ早いなと考えています。 だからこそ2020年は自分自身の積み重ねたモノを一度リセットするくらいの覚悟で大きなチャレンジをして行きます。 そこで今日はその大きなチャレンジを抱負として明記し、宣言の力によって前に進む覚悟を決めたいと思います。 今北産業で頼む そうだ、大学に行こう オミカレを退職
予選敗退から学ぶISUCONの正しい歩き方 - そーだいなるらくがき帳
34位でフィニッシュ。 isucon.net 棄権を合わせると予選突破に200イスコインちょっと足りなかった。 ハイスコアは9850だっただけにあと1つなにかできれば予選を突破できてたことになる。 当日の流れは id:sugyan さんが用意してくれてるのでそっちを読んでほしい。 memo.sugyan.com ここからはただただ、自分に対する反省をまとめる。 主な担当であるインフラについての反省 準備したつもりでも準備不足だった。 複数台構成、普段RDSやALBに甘えている弊害が出て、Nginxやアプリケーションの複数台構成のやり方を知っているが普段していないので詰まったって感じ。具体的にはMySQLに接続できなくて時間をかけた。 あとnginxのチューニング、特にルーティングで配信をまとめるみたいなところもかなり時間をかけてしまった。 普段、S3とCFにURLをすれば良いって感じで生き
文系でもプログラマになれるのか - そーだいなるらくがき帳
ブログについたコメントに対する自分なりの考えを書く。 soudai.hatenablog.com 私は文系の大学生ですが、プログラミング興味を持ちプログラマになりたいと考えています。 とても難しい事は理解していますが、プログラマに就職するのは やはり難しいでしょうか？ もし可能性があるとしたら、就職先の探しかたや見分け方などの ことを教えてください？ お願いします。 文系でもプログラマを始めとするソフトウェアエンジニアになれるか？の答えは なれる。 例えば自分の周りでも id:daiksy さんとか @shinpei0213 さんは文系出身のソフトウェアエンジニアだしプログラミングしている。 もっと言えば自分自身、高卒エンジニアなので学歴がネックでプログラマになれないということは無い。 だがソフトウェアサイエンスをしっかりと学んだ人からするとスタートラインは後ろである、という事実はあるし、
初心者をプログラマーにできるかどうか - そーだいなるらくがき帳
blog.3qe.us これを読んだ感想文を書く。 結論、大量生産は無理やろとは思う。 少なくとも、「プロ」としてお金をもらって高品質なソフトウェアを0から書けるようになるにはセンスが必要だ。 そもそもそのレベルには私もなっていない。 ただ今あるモノになんとなく機能を追加するレベルに引き上げる術はもっとあると思う。 経験則でなんとなくその例をあげる。 ペアプロ OJTに近いとも言えるし、一番わかりやすい。 ここでペアプロはハローワールドまでの環境構築や実装までを各要素を説明しながらやることを指す。 まずはメンター側が目の前で順番にやってみる。 で次にメンティに同じことをさせる。 そうすると絶対詰まる。 Error: variable 'a' is undefined, line 24 こういうエラーが出るとまず英語を目の前で読む。 で理由を順番に説明して24行目を一緒に読む。 根気よく教え
適切な問題と文化がサービスを育てる - そーだいなるらくがき帳
って話をPHPカンファレンス2018でしてきます（1時間後に過去形になります って話をPHPカンファレンス2018でしてきました。 2018/12/16時点で動画とFAQの内容を追記しています。 phpcon.php.gr.jp 当日の登壇資料はこちら。 当日の動画です www.youtube.com ※ 5:41:20 くらいからが僕の動画です。 ※3ヶ月以内を目処にセッション毎に割ってくれるみたいです 内容補足 Webサービスは成長と共に変化していくので、つまりは変化に強いチームというのは重要になります。 では変化に強いチームとはどうやってつくるのか？って話が今回のテーマです。 チームビルディングってとても重要なのは周知の事実だけど、じゃあどうやって？って言うHow toは意外と語られません。 それは「答えが無い」ってのもありますが、プレイヤー目線とマネージャ目線（経営者も含む）で大き
CTOを始めて半年経ったので振り返る - そーだいなるらくがき帳
4月からオミカレに戻ってきて半年たった。 ちょうど今月が期末だしこの半年を振り返る。 soudai.hatenablog.com party-calendar.net 4月 CTOになった（1年と3ヶ月ぶり 2度目) オミカレを離れている間の事をキャッチアップするのに心血を注ぐ感じだった。 1年ぶりに読んだプロダクトコードは機能もコードも1年で随分育つというか驚きのレベルだった。 「男子三日会わざれば刮目して見よ」というがプロダクトコードも同じである。 変更点と新たに生まれた課題点の整理をするためにかなり時間を使った。 それと並行して運用フローの見直しであったり、体制変更に伴うツールの選定、移行などをやった一ヶ月だった。 その結果、課題はかなり整理できてこの半年～1年で何をやるかを整理できた。 前職でJOIN直後はやりたい放題するチャンスと学んだので4月の後半からはドラスティックな運用フロ
正しいデータは正しい設計に宿る - そーだいなるらくがき帳
って話をbuilderscon 2018でします。 builderscon.io 当日利用する資料はこちら。 speakerdeck.com 私のセッションはbuildersconの最終セッション。 皆さん素晴らしいセッションが並ぶ中で選択肢に迷ってる方も居ると思います。 だから先に公開しておきますのでこれをご覧になって、他のセッションに行くというのも有りだと思います。 あと事前に去年のトークを見てくれると当日はより理解が深まると思います。 同じ話を2回しても皆さんにとって勿体無いのでリファクタリングの細かい前提の話は当日はしません。 soudai.hatenablog.com 動画はこちら。 www.youtube.com これを見て、面白そうだなって思ったらぜひ、遊びに来てください。 僕が知ってるRDB設計、そしてRDBの歩み方を全てお伝えします。 あなたの新しい道の一歩目をご用意しま
RDBMSのモニタリングについて - そーだいなるらくがき帳
dbstudychugoku.github.io 中身の薄い資料で登壇してきた。 speakerdeck.com 具体的な内容が知りたい人は末尾に関連リンクをまとめたのでそっちを見て欲しい。 資料には書いてないけど伝えたかったことをまとめる。 RDBMSの監視の勘所 RDBMSがどれくらいのトランザクションを捌けるかというのが大切な要素の一つ。 単純な処理が多くてキャパオーバーになったとき、多くの場合はインスタンスのサイズを上げるなどのスケールアップで対応できる。 これは費用対効果の高いケースが多く、有効な手段だ。 しかし ロックが原因の場合 はスケールアップしても問題が解決しないことが多い。 例えばバッチ処理で長時間テーブルロックを取り、それが起因でパフォーマンスが問題になっているときは単純なスケールアップで問題は解決しない。 よく見られる処理例は次のようなケース。 トランザクションを開
DBリファクタリングをやっているって話 - そーだいなるらくがき帳
言語の勉強会でその言語の話をしない人ランキング堂々の第一位、そーだいです（当社比 控えめに言っても最高な毎度おなじみ #kichijojipm で今日LTする話の補足です。 kichijojipm.connpass.com speakerdeck.com タイトルは出落ちです。 全然最強じゃなくて頑張ってやってるよって話です。 資料がかなり薄いので補足します。 DBリファクタリングについて 26Pは現状です。 MySQLって書いてますが本番はAurora1を使っています。 以降、このDBを 現行DB と呼びます。 ここではオミカレとみんなの婚活はWebサービス名です。 つまり2つのサービスから現行DBを見ていますし、機能によっては現行DBの同じテーブルを参照・更新・削除などを行います。 この2つ以外にも社内システムなどでこの現行DBは利用されており、メインのテーブルを変更すると影響範囲が広
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
DBリファクタリングの勘所と所感 - そーだいなるらくがき帳
表題についてそーだいなる見解を書き残します。 今年の夏に id:koemu さんにbuilderconの懇親会で下記のような話をいただいていました。 懇親会で、DB側ばかりでなくプログラム側でも適切なドメインモデルの設計ができていれば、リファクタリング時の影響範囲がさらに小さくできるのでは？という話をしたところ、この辺りはアンサーブログを書いてくれるかもしれないってことなので期待しています！！！ www.koemu.com 忘れてないんですよ！しっかり覚えています。 結論 仰る通りだと思うし、適切なドメインモデルはRDBに限らずデータストア層のリファクタリングの負担を大きく減らすと思います。 ここから先は僕なりの考え方を書きます。 実は似たような話を PHPの現場 っていうポッドキャストでも触れています。 php-genba.shin1x1.com システムの柔軟性 勿論、コードの綺麗さや
PostgreSQLの内部構造と監視の話 - そーだいなるらくがき帳
Geeks Who DrinkとPostgreSQL Conference Japan 2017での資料です。 nulab.connpass.com PostgreSQL Conference Japan 2017 (2017-11-03) | 日本PostgreSQLユーザ会 詳しく知りたい人は下記の本がおすすめです。 ただし注意点は9.3相当なのでプロセスの仕組みがちょっと違います。 待望の新刊出ました！10系ベースなのでぜひ読んでみてください。 ※2018/10/07 追記 読み応えのある内容になったかなと思います。レベル感で言えばOSS DB Goldの試験出る範囲です。特に内部構造は覚えて置いて損は無いでしょう。 speakerdeck.com 内部構造の中で取り扱っていないところにAUTOVACUUM、TOASTとレプリケーションがあります。AUTOVACUUMはPostgre
Apache2(httpd)の監視 ~ mackerel-plugin-apache2を読み解く - そーだいなるらくがき帳
この記事は Mackerel プラグインアドベントカレンダー(全部CRE） の2日目です。 qiita.com soudai.hatenablog.com それでは2日目は mackerel-plugin-apache2 です。 ここではApacheの細かい説明は割愛します。 mackerel-plugin-apache2はWebServerとして広く使われているApache2専用のpluginです。 こちらは README.md にも書いてある通り、 server-status を可視化してくれるプラグインで簡単に導入することができます。 github.com インストールと設定手順 本プラグインはプラグイン集として提供しているパッケージの mackerel-agent-plugins に含まれています。 インストール先は /usr/bin/mackerel-plugin-apache2
Webサービスは振る舞いをモニタリングするべきって話 - そーだいなるらくがき帳
って話を明日のPHPカンファレンスでする予定でした。 PHPカンファレンス、私用のため私の登壇をキャンセルします。楽しみにされてた皆様、大変申し訳ありません。当日登壇予定だった内容はブログに細かく詳細まで記載して公開します。この度は皆様、ご迷惑をおかけします。 #phpcon2017 https://t.co/qgHogswYeI— そーだい@初代ALF (@soudai1025) 2017年10月6日 ここにあるとおり、雨の影響により、子供の運動会が延期になり、PHPカンファレンスと被ってしまいました。そこで色々悩んでいたところ、スタッフの方が気を利かせて連絡を先にくださり、キャンセルさせていただくことにしました。正直年に1度のお祭ですし、会いたい人も沢山いるイベントですから断腸の思いでした。しかも僕は今年各地のPHPカンファレンスに出れなかったので会えていないPHPerの方が多く居ます
RDBアンチパターン リファクタリングについて話をしてベストスピーカー賞を取ってきた #builderscon - そーだいなるらくがき帳
Builderscon 2017で登壇してきました。 builderscon.io 登壇資料はこちらです。 今回も僕が超絶リスペクトしてる id:t-wada さんと そこそこリスペクトしてる 空前絶後のォォ！！！！超絶怒涛にリスペクトしている上司の id:onishi さんの名言を引用させてもらいました。これはテストコードやモニタリングで品質が見える化されますが「見える化されるだけでは問題は解決しない」という本質をお伝えしています。我々はエンジニアなので技術で問題を解決していくわけですし、問題を解決するためには手を動かすしかありません。ですのでまさに今の現場を改善していくのはあなた自身です。 あとは今年、話をしてきたデータベースリファクタリングの総集編って感じです。ホントは実例のRDBアンチパターンを元にリファクタリングしていきたかったんだけど60分では短すぎて「続編に期待」みたいなレベ
香川大学の学生向けにソフトウェアエンジニアの生存戦略について話をしました - そーだいなるらくがき帳
7/21に香川大学で講演させていただきました。そーだいさんと言えばRDBでしょ！？みたいな感じで先にタイトルが決まった感じですがRDB全然関係ない感じになりました。 僕が超絶リスペクトしてる id:t-wada さんとそこそこリスペクトしてる上司の id:onishi さんの名言を引用させてもらいました。僕はこの2つの言葉が10年戦えるエンジニアの核心をついてると思っています。 つまり 技術は螺旋なので継続的な知識の更新は必須 手を動かす（一歩目を踏み出す）者が未来を作る という2点を踏まえた上でエンジニアにはそれぞれ得手不得手があるわけです。この得手不得手を理解して自分がどのフェーズを戦場として戦うか？って話をしました。この話は前もブログに話をした内容です。 soudai.hatenablog.com そこで僕の経験談としてDBを交えて話をしました。 サービスを作るのが特に好きなタイプで
エンジニアの信頼を得るには良質なアウトプットが必要な話 - そーだいなるらくがき帳
先日、僕が大好きでリスペクトしてるソフトウェアエンジニアさんたちと意見交換会（呑み会）中にソフトウェアエンジニアの信用と信頼について話題になったのでメモ。 僕が「このソフトウェアエンジニアは信用できる」っていうのはどういう指標がありますか？って質問した時に出た意見としては コードに対して何らかの貢献をしている 新規プロダクトの開発など OSSのメンテナンスなど（パッチを送るなど） 自分の持つプロダクトに対する反応など が出てきた。 これらのような「良質なアウトプット」を定期的に行う頻度も大事だよねという感じ。 なるほど、確かにって思ったのだけど更にその中で良質なアウトプットとは何かという話題になった。 ソフトウェアエンジニアの属性 ソフトウェアエンジニアには得手不得手がある。 言語だったりレイヤーだったりで好き嫌いも含めて得手不得手がある。 更にもっと言えば「プロダクトの成長段階」でも得手
今こそ知りたい、2大OSSデータベースのMySQLとPostgreSQLの違いについて話をしてきた - そーだいなるらくがき帳
去年書いたSoftwareDesignを題材にお話してください！って言われたので話してきました。 下の特集記事は１年経った今も現役で読める内容なので興味がある人はぜひ読んでみてください。 またRDBアンチパターンという連載をしていますのでこちらもあわせてご確認くださいっ！ gihyo.jp そして当日の資料はこちらです。 SoftwareDesignにしっかりとMySQLとPostgreSQLの違いについては触れているのでそこでは触れていない、ハマりどころや初めて両方のDBを知ったと言う人向けのカジュアルは部分を攻めました。 またDBだけの勉強会ですので普段説明するようなところは省略し、できるだけ経験談やコアの話に注力したつもりです。 このへんは資料に含まれて居ないので当日居た人たちだけの特典ですね！！ ということで実は今月は登壇3週連続だったのですが一段落しました。 来週はAWS Sum
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
