ちょっぴりDiveDeepするAWSの時間 AWS Dev Day 2023 Tokyo 延長戦 実践データ移行 〜はてなダイアリーや魔法のiらんどの事例と共に〜
MySQLではレプリケーションがよく利用されます。また、アプリケーションは負荷分散のために、ソースだけでなくレプリカを参照系として利用することも多いです。しかし、レプリケーションは遅延するリスクがあります。そのため、アプリケーションは高負荷やロングトランザクションによる想定外の遅延が起こることを考慮して、設計や実装を検討しなければなりません。 MySQLでは遅延レプリケーションをサポートしています。遅延レプリケーションとは、ソースよりもレプリカへの適用を指定した時間だけ意図的に遅らせることができる仕組みです。ステートメント単位ではなく、トランザクション単位で遅延を発生させます。ソースへのトランザクション実行から指定した時間後に、レプリカに対してそのトランザクションを適用することになります。トランザクション内の各ステートメントは待機時間なく実行されます。 今回はこの遅延レプリケーションの設定
2024-02-09 で GitHub に入社して丸 3 年経った。入社日は 2021-02-09 だった。 (これは 2024-03-06 に書いている) 3 年目はあまり良い一年ではなかった。年末年始は US テック業界にレイオフの嵐が吹き荒れ、GitHub でも 2 月にレイオフが行われた。比較的仲がよかったエンジニアも対象になり、数少ない「つて」がなくなった。春以降は同僚が育児休暇に入り(これはとても良いことだ)、仕事量が増えてオーバーワーク気味になった。勤怠の記録を振り返ると実稼働時間(残業)が顕著に増えたわけではないが、週末も翌週の仕事のことが頭から離れなかったり(まあそれは昔から割とそうだが)、仕事中も息つく暇なく次から次へと問い合わせをこなす感じで余裕がなかった。秋には状況が改善したが、知らずのうちにストレスを溜め込んでいたようで、職場に関連して思慮の浅さからくる失敗をして
はじめに 自分がIT業界に携わって5年ほどが経過しました。 この5年間、SIerからフリーランスエンジニアに転身し、様々なプロジェクトに参加する中で、数々の失敗と成功を経験しました。特に心構えやマインドの部分で多くを学ぶことができました。 未熟だった自分を振り返って、今では改善できた点が多くあると思います。同じ失敗を繰り返さないように、自分の経験が少しでも役立てば幸いです。 また、気付きを与えてくれた方々にこの場を借りて感謝します。 感謝を忘れない 進捗報告やコードレビュー、質問対応など、感謝の気持ちを忘れないようにしています。感謝は、コミュニケーションを円滑にし、相手の意欲を引き出す力があると思います。 たとえば、昔の自分はバグ報告を受けるとろくに文章も読まず「影響範囲は? 再現する条件は? 原因は? 解決策は?」などと質問攻めにしてしまっていました。 報告しただけなのに色んなことを聞か
オーバーエンジニアリングしてしまうという悩みがあって困っている、そのうち必要になるのではないかという気持ちになって無駄に抽象化して頑健にしてしまう。じゃあ素朴にやればいいのかというと、例えばDBスキーマみたいな要素は素朴になってはならないという難しさもある— Windymelt💀(めるくん)🚀❤️🔥 (@windymelt) 2024年9月12日 上のツイートを見かけたので、自分は何を心がけているか書いてみる。 結論 プロダクト方針的に起こりそうな未来を想像する 想像した未来が起こったとして、どのような実装になりうるかをざっくり考える その上で、その未来が起こったときに「詰む」ことがなさそうな一番シンプルな設計にする 前提: あらゆる未来の変更に強い抽象化はない 設計を考えていて複数案を出すと、結局トレードオフが存在することがわかる。案Aを選択すると、こっちの未来には対応しやすいが
こんにちは。ニコニコ共通バックエンド開発担当の小野塚です。 2024年8月8日から順次「フォロー新着」機能がリリースされましたので、技術的な側面についてこれまでの歴史やニコニコに特徴的な点を含めご紹介したいと思います。 フォロー新着とは フォロー新着とは、フォローしているユーザー、チャンネル(入会しているチャンネルを含む)、マイリストの更新情報をまとめて新着順にタイムラインとして見られる機能です。 2024年9月リリース予定で開発を進めていましたが、前身であるニコレポのシステムがサイバー攻撃によってダウンしたため、代替として急遽前倒しでリリースされました。[1] フォロー新着システムに至るまでの歴史 今回のフォロー新着のために開発したシステムは、ニコレポ時代から数えると3つ目のタイムラインシステムとなります。 以前のシステムについて公開されている情報も無いようですので、これを機に簡単に紹介
これはなに ども、レバテック開発部のもりたです。 今回はMySQLでのスロークエリログについて調査してまとめました。 スロークエリログといえば古くからパフォーマンスチューニングの力強い味方といったふうに語られることも多いですが、最近はクラウドで使える便利なツールも生まれています。この記事ではスロークエリログの一般的な使い方を紹介するとともに、他のツールとの比較や、どんな場面でスロークエリログが役に立つのか、また役に立たない場合はどんなツールを利用することができるのかについてまとめました。 足りないところなどあればおおいにマサカリ投げていただけると幸いです。 記事の流れ 記事の流れ この記事はそこそこ長いので、初めに記事の流れを解説します。適宜読み飛ばしてください。 なぜスロークエリログなのか ここではそもそもスロークエリログをなぜ確認したいのかみたいなところを説明します スロークエリログの
5年ぶりの投稿です 5年の間に結婚(事実婚だけど)して息子が生まれ、あと5日で一歳になろうとしているので、これからの0歳児パパママのためになる文章を書こうと思い立ちました 自分たちが実施してよかったこと、やっておけばよかったこと、買ってよかったもの、いらなかったものなど書いていきます ポリシー 写真とビデオは品質良くたくさん撮ろう カメラについて 保育園大好き 1. パパ友ママ友ができた 2. 社交的になった気がする 3. 親たちも社会とのつながりが持てる 夫婦で飲みに行きたい 赤ちゃんから離れる時間が必要 赤ちゃんと旅行に行くには 病院の心得 授乳 tips 睡眠 tips 離乳食 tips お風呂 tips 洗濯 tips おむつ tips 乗り物系 tips 移動系 tips 赤ちゃんスペース tips 0歳児の育児の大変さ 自分の心境の変化 すでに0歳児が恋しい お下がりがありがた
MySQLやPostgreSQLといったRDBMSからデータを引いてくるとき、扱うデータの規模によっては、1000件ずつLIMITをかけて順に引いていくということがある。 以前slow queryが出たらよくやっていたのを思い出して、ふとこのあたりってどういう根拠があってやっているのだっけ、自分が知っている他に効能があったりするのかな、と思ってSlackに書き込んだところ、同僚の id:onk に教えていただいた。その内容に加えて軽く調べた内容をまとめてみる。 Web系の話です。みなさまの知見がありましたら教えてください。 TL;DR 刺さる*1から 刺さったら困るから あたりまえ 詳細 もともとSlackに書いた原文は以下の通り(MySQL前提で書いているけどPostgresといった他のRDBMSにも適用できる話。): DB引くとき、Perl時代(?)によく1000件単位でchunkin
2021年9月にSmartHRへ入社して、丸3年が経ちました。 hase0831.hatenablog.jp 入社したときはマネージャー直下の1人目ディレクターだったのが、あれよあれよという間に組織は拡大。所属していたコミュニケーションデザイングループも組織改編により、「ブランディング統括本部」として生まれ変わりました。 note.com ちなみにわたしの社員番号は500番。今となっては1,000人を超える大所帯になったSmartHRですが、まだまだカオスで、やることは山積みです。これは言い換えれば、関わりしろがめちゃくちゃある状態なのですが、そういえば仕事についてはしばらく書いてなかったな〜と思っていたときに、以下のTweetを発見しました。 入社エントリと退職エントリよりも、3年とか5年いてこれからもやってくぜっていう在籍エントリ読みたい。自分はそっちの方が興味ある。 — あいぽん/米
この記事は統計検定準 1 級の合格体験記であり、テスト内容の解説記事ではありません。また、この記事での試験に対する勉強の仕方や受験者の属性には一般性が担保されないので、一個人の個人的な見解として解釈してください。 はじめに 今回は統計検定準 1 級に一発で合格できたので、勉強方法・テストの所感をレポートします!最近は増えてきましたが、CBT 形式の準 1 級の体験記は少ないかなと思ったので 1 つの参考になれば嬉しいです! ステータス 経歴: 東京大学理科 2 類 → 工学部マテリアル工学専攻 → 大学院工学系研究科マテリアル工学専攻 (物性に関する研究) 仕事: 株式会社くふうカンパニーで DS をさせてもらってます 統計の勉強経験: 1S の基礎統計のみでほとんど覚えていないので、知識ほぼゼロの状態でした 数学: 東大理系の平均ぐらいだが、大学からはあまり勉強していませんでした (だい
コードレビュー開発者ガイド はじめに コードレビューとは、コードの作成者以外の人がコードを調べるプロセスです。 Google ではコードとプロダクトの品質を維持するためにコードレビューを実施しています。 このドキュメントは Google のコードレビューのプロセスとポリシーに関する正規の解説です。 このページでは私達のコードレビュープロセスを概観します。このガイドはさらに二つのドキュメントに分けられます。 コードレビューの仕方: コードレビュアーのための詳細なガイド CL 作成者のガイド: CL をレビューしてもらう開発者のための詳細なガイド コードレビュアーはどんな観点でレビューすべきか? コードレビューは次の観点で見るべきです。 設計: コードはうまく設計され、そのシステムにとって適切か? 機能性: コードは作成者の意図通りに動作するか?ユーザーにとってコードの挙動は適切か? 複雑さ:
コードレビューの仕方 このセクションでは、長年の経験に基づいて、コードレビューをする最良の方法に関するいろいろな推奨事項を説明しています。 各ページをひとまとめにすると一つの完全なドキュメントになりますが、便宜上、多くのセクションに分割しています。 全部を読む必要はありませんが、多数の感想によれば、ドキュメントを通読するのが個人としてもチームとしても非常に有益です。 コードレビューの基準 コードレビューの観点 レビューで CL を閲覧する コードレビューのスピード コードレビューコメントの書き方 コードレビュー中の取り下げに対応する CL 作成者のガイドも参考にしてください。こちらは CL をコードレビューしてもらう側の開発者のための詳細なガイドです。
はじめに 技術評論社様より発刊されているSoftware Designの2024年5月号より「レガシーシステム攻略のプロセス」と題した全8回の連載が始まりました。 ZOZOTOWNリプレイスプロジェクトで採用したマイクロサービス化のアプローチでは、安全かつ整合性のとれたデータ移行が必須となりました。第4回では、このマスタDBの移行について紹介します。 目次 はじめに 目次 はじめに マスタDB移行 マスタDB移行について 要件と課題 テーブル構成を再設計したうえでデータ移行を実施する ダウンタイムなしでデータ移行を実施する 方針 異なるDBおよびデータスキーマ間で移行を実施するためEmbulkを使用する ダブルライトをリリースし、データ移行中に発生するDBへの書き込みを両DBにアトミックに実施する データを一時DBに格納し、一時DBから移行先DBにデータを移行する BulkloadとBac
本を読みたいのについスマホを眺めてしまう。仕事や家事、育児に追われて積読が増えていく——。「読書」にまつわるそんな悩みを抱えてはいないでしょうか。 文芸評論家として活躍する三宅香帆さんも、会社員時代は「本が読めなくなった」といいます。そんな当時の経験をSNSで発信したところ、多くの共感の声が集まり、2024年4月には『なぜ働いていると本が読めなくなるのか』を出版しました。 今回は、仕事に家事・育児と目まぐるしい毎日の中で、読書を楽しむヒントをうかがいました。 働いていると本が読めなくなるのは、普通のこと 本が大好きな三宅さんも、多忙な会社員時代に本が読めなくなったとのこと。改めて、当時の状況を教えていただけますか。 三宅香帆さん(以下、三宅):仕事に関係のある本は読めても、好きだったはずの古典文学や海外文学などが読めなくなりました。仕事はすごく楽しくて充実していた一方で、本を読む時間が取れ
はじめに こんにちは、オシロ株式会社でリードエンジニアとして働いているにっく(webuilder240)と申します。オシロでは自社プロダクトとしてコミュニティ専用オウンドプラットフォーム「OSIRO」を提供していますが、私は2015年の開発開始から一人目エンジニアとして携わり、技術選定の意思決定を行ってきました。 今回は、そのなかでもRuby on Railsを選択した理由、 その学習に役立つOSSアプリケーションについて紹介したいと思います。この記事を読むことで、Railsの選定理由や実践的な学習方法について理解を深めていただければと思います。 はじめに Ruby on Railsの選択理由 開発に必要な便利機能がはじめからそろっていた 可読性・コードの美しさ 選び続けている理由 RailsのコードリーディングにおすすめなOSS Mastodon forem Writebook 最後に
2024-08-30E2Eテストの信頼性と向き合ってMagicPodのヘルススコアが100に達した話こんにちは、医療プラットフォーム本部 プロダクト開発室 QA グループ所属の小島大周 (@Daishu) です。2022 年 4 月に QA エンジニアとしてメドレーに入社しました。主に "クラウド診療支援システム CLINICS" のプロダクト開発における QA と、E2E テスト自動化を担当しています。 今回は、MagicPod という自動テストツールに半年間向き合い、テスト内容と結果の信頼性を高める改善を行った話をさせていただきます。 ※ 自動テストツール全般に共通する話なので、自動テストに携わっている方々にご覧いただけると大変嬉しいです。 MagicPod弊社は E2E テストの自動化に対して MagicPod というツールを採用しています。MagicPod の詳細は割愛しますが、導
仕事のひとつとして、技術組織におけるタレントマネジメントに取り組んでおり、勉強したことを簡単にまとめておく。 タレントマネジメントと一口に言っても、その類型にはいろいろとあり、マッキンゼーの"War for Talent"が書籍も出版されていてよく知られている。これは、簡単に説明すると、社員を成果の発揮度でA, B, Cに位置づけ、組織をAの人材で充足し、Cはなるべく数を減らす、という戦略をとる。選別の要素の強いマネジメント手法であり、あまり日本型の人事管理には馴染まない。そもそも、組織のすべてをA人材で満たす必要はあるのか、A人材のみで充足するためのコストに見合うのか、といった議論もある。 マッキンゼーの"War for Talent"は選別的なアプローチであり、逆に人材すべてをタレントとみなすマネジメントは、包摂アプローチと分類される。 他にもタレントマネジメントの類型はいろいろとある
2024年9月14日紙版発売 2024年9月14日電子版発売 ミック 著 A5判/432ページ 定価3,520円(本体3,200円+税10%) ISBN 978-4-297-14405-0 Gihyo Direct Amazon 楽天ブックス 丸善ジュンク堂書店 ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo honto 本書のサポートページサンプルファイルのダウンロードや正誤表など この本の概要 2011~2012年に『Web+DB Press』誌上で連載された「SQL緊急救命室」の書籍化です。病院を舞台としてダメなSQL文が毎回持ち込まれて,どこが非効率なのか,どこが間違っているのかをコミカルな対話形式で議論しながら効率的で正しいSQL文の書き方を学びます。中級者向けのSQL解説書は内容が難しく読者にと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く