クレディセゾンでDXを進めてきた5年間を振り返る｜小野 和俊
はじめにクレディセゾンに来てちょうど５年が経ったので、これまでの取り組みをまとめてみようかと思う。書き進めていくうちにとても長くなってしまったので、1年につき3トピックに絞ってあとはカットした。それでも5年分なこともありかなり長くなったので、目次から各トピックに飛んでもらえればと思う。社内の関係者も読むかもしれず、「自分のやったことが載ってない！」と思うこともあるかもしれないが、内製開発案件だけでも53案件あり全部載せるととんでもない量になるので許してほしい。それから、振り返ってまとめると退職すると勘違いされるかもしれないけれど、退職するわけではありません！ 2019年：ゼロからのスタート1-1. 内製開発エンジニア募集を始める「日本のそれなりの規模の事業会社の中に、内製開発チームを立ち上げることはできるのだろうか？」 2019年3月、クレディセゾンに来たばかりの私にとってはこの質問への答
個人的Rails開発環境構築2024
新規でRailsプロジェクトを始める時の個人的な環境構築についてまとめる。前提とする条件等は下記。 規模: ~中規模 開発者数: 個人 利用シーン: PoC作成・スタートアップ立ち上げ・並の業務アプリ開発等 基本戦略 利用シーン的に「思い立ったらすぐアプリの開発ができる」という感じの運用がしたい。極力セットアップで悩みたくないから必要なミドルウェアなどは全部Dockerでインストールできるようにして立ち上げれば終わり、の環境を作る。その環境の中で色々とコマンドを叩いたり、rails newやrails gなどでRailsアプリを作成していく。 この辺のRailsの初期セットアップの手間を出来るだけ省きたいのでtemplateとなるリポジトリを作成し、そこからcloneしてくるだけでOKにする。 フロントエンドはReactなどを使わずをRails標準のerbとHotwireを軸に開発する。開
Rustでリレーショナルデータベースを自作したときの成果と反省と学び - Yoshisaurのメモ
はじめに この記事では、個人プロジェクトとしてRust言語でリレーショナルデータベースを開発した経験（もう五ヶ月も前...）について、その成果と反省、得た学びを共有します。 DBMSを自作した理由 自分がDBMSの自作に着手したのは、『Designing Data-Intensive Applications』という本の内容を深く理解するためでした。 この本は、データシステムの設計と運用において最も大切な「信頼性」、「拡張性」、「保守性」を保証する方法論を、豊富な文献を引用しつつ、理論と実践の橋渡しを巧みに行いながら、丁寧に説明している名著です。読んだことがない人は速攻購入してくだい。本当にいい本です。 この本は、データベースの内部構造に関する話も豊富に含まれていたので、「データベース自作してみようか...」という気持ちになりました。 Rustを採用した理由 データベースの実装のついでに、
自作RDBMSやろうぜ!
Skip to the content. 自作RDBMSやろうぜ! このサイトの目的 RDBMS（いわゆるリレーショナルデータベース）というものはプログラミング言語の処理系や、OSなどと同様に、世の中で広く使われているソフトウェアであるにも関わらず、いざ自作してみようと思うと日本語で記述されたサイトや書籍で、必要な情報・情報源がまとまったものがないことに気づきました そこで、叩き台として、本サイト管理人および数名のコミッタで開発している自作RDBMSである SamehadaDB が軌道に乗るまでの経験をベースに、自作RDBMSするための道筋をある程度整理して書き記してみました 各々の情報・情報源はあいかわらず多くが英語で記述されていますが、その点はご容赦下さい なお、本サイトは技術的な解説を提供するのではなく、適切と思われる情報・情報源をポイントするようなサイトとなることを想定しています
ナチュラルキーを主キーにしてはいけない - 設計者の発言
定期的に複合主キーの話題が盛り上がるのは楽しい。好きな話題なので便乗しよう。 「複合主キーを許すべきかどうか」の議論に関して私が理解できないのが、なぜか「ナチュラルキーを主キー（一次識別子）に含めてはいけない」という話とセットで語られがちな点だ。もちろん、ナチュラルキーを主キーに含めてはいけない。だめ、ゼッタイ。しかしこれは複合主キーの必要性とは無関係な議論であって、複合主キーを回避すべき理由にはならない。 ■ナチュラルキーと人工キー ナチュラルキーについて、公開中の販売管理システムのモデルで説明しよう。まず、商品マスタの主キーは「内部商品№」である。これは、追加されるたびに自動的に発番されてセットされる項目で、ユーザの目には触れない「人工キー」だ。「Row ID」と思ってもらえばいい。 [商品] 内部商品№、品名、{品番}、．．． いっぽうユーザの目に触れる項目は、「二次識別子」とされて
アンチパターン「成長する主キー」 - 設計者の発言
我ながらしつこいが、またまたテーブルの主キーに関する話題である。「複合主キー」を毛嫌いする開発者がいるとすれば、その根拠はおおむね２つある。「ID等の単独主キーにしておけば、主キーの仕様変更に振り回されない」、および「複合主キーにすると実装が煩雑になる」だ。それぞれについて反論しよう。なおこれらの他に「ナチュラルキーを主キーにすると値が変わったときに困るから、複合主キーはダメ」と説明されることがあるが、こちらは非論理的なので取り上げない（詳しくは「ナチュラルキーを主キーにしてはいけない」を参照）。 ■成長する主キー まず「ID等の単独主キーにしておけば、主キーの仕様変更に振り回されない」についてだが、この主張は一面的には正しい。じっさい私自身、複合主キーの仕様変更に振り回された思い出がある。 新人の頃、ある重要なテーブルを処理するアプリをプログラミングしていた。仕様書にしたがって検索すると
どのレイヤー（層）でトランザクションを実装すべきか
このように、層ごとに関心事の分離を行うことで、保守性の高い（変更容易性や再利用性等）アプリケーションを実現できます。 しかし、「トランザクション」においてはどうでしょうか。 トランザクションはビジネス領域においても、技術領域においても関心事がある内容です。 そういう曖昧なものは「ひとまず usecase 層に入れてしまえ」という方針になりがちです。 ですが、DB 固有の知識を usecase 層の関心事にしてしまっては、関心事の分離をするメリットが得られません。 そのため、関心事の分離を実現しつつトランザクション実装をする方法を模索してみました。 前提 1. クリーンアーキテクチャを採用している（オニオンアーキテクチャやレイヤードアーキテクチャも含む） そもそもビジネス知識と技術知識を分離していないアーキテクチャを採用している場合、メリットは得られません。 そのため、オニオンアーキテクチャ
その選択、ちょっと待った！NoSQLデータベースへ乗り換える前に検討すべき3つのポイント
最近、どうも安易に「NoSQLにすれば厄介なDB設計から開放される」と考えている人が多いように思えて仕方がない。だが待って欲しい。本当にNoSQLと呼ばれるデータベースを使えばアプリケーションの開発・運用の苦しみから逃れられるのだろうか。もちろん「そんなことは無い！！絶対にだ！！」と私は考える。今日はその理由について語ろうと思う。 トランザクション先日、リレーショナルデータベースにおけるDB設計についてセミナーで解説したばかりだが、リレーショナルデータベースにおけるデータの整合性は何もDB設計だけが担保しているわけではない。リレーショナルモデルと同じかそれ以上に欠かせないのがトランザクションだ。 トランザクションがあるおかげで、トランザクション終了後のステータスは「成功」か「失敗」の2つしかないということが保証される。すなわちオール・オア・ナッシングだ。もしトランザクションの途中で何らかの
ウォンテッドリーにおける推薦システム開発の流れ | Wantedly, Inc.
はじめにこんにちは、ウォンテッドリーの合田(@hakubishin3)です。私は推薦チームに所属していて、機械学習領域のテックリード兼プロダクトマネージャーとして会社訪問アプリ「Wantedly Visit」の推薦システムの開発・運用を携わっています。この記事では、ウォンテッドリーの推薦チームが実践している推薦システムの開発プロセスについて紹介します。 まず初めにお伝えすると、私たちの開発は広く実践されているプロダクト開発やデータ分析プロジェクトの流れと基本的に同じです。しかしながら、同じような流れでもその工程の中には、継続的な推薦システムの開発を通じて重視するようになった観点や改善を積み重ねてきた取り組み方が各所にあります。推薦システムを開発している人だけでなく、推薦以外の切り口でプロダクトやクライアントの課題解決に取り組まれている人にとっても、何かしらの参考になるかもしれません。是非ご
「Azure OpenAI Serviceリファレンスアーキテクチャ」活用の最初の一歩 リリースレベルのLLMアプリに必要な検討項目とは
真のサーバーレスアーキテクチャについて語り、最新のエッジコンピューティングや生成系AIのサーバーレス実装を学び、クラウドネイティブで高速な開発プラクティスと向き合う2日間「ServerlessDays Tokyo 2023」。ここで登壇したのは、日本マイクロソフト株式会社の坂部氏。LLMアプリ開発における、「Azure OpenAI Serviceリファレンスアーキテクチャ」の活用について発表しました。 登壇者の自己紹介とアジェンダ紹介 坂部広大氏：「Azure OpenAI Serviceリファレンスアーキテクチャからみる、本番システムレベルのLLMアプリに必要な検討項目の解説」というテーマで、日本マイクロソフトの坂部と申します。時間としては25分、お付き合いいただければと思います。それではよろしくお願いします。 （会場拍手） 「このセッションでわかることと、話さないこと」ですね。今回の
Azure アプリケーションの設計原則 | Microsoft Docs
次の設計原則に従って、アプリケーションのスケーラビリティを上げて、回復力や管理しやすさを強化します。 自動修復機能を設計します 。 分散システムでは、障害が発生します。 障害の発生に備えてアプリケーションの自動修復機能を設計します。 すべての要素を冗長にします 。 単一障害点をなくすようにアプリケーションに冗長性を組み込みます。 調整を最小限に抑えます 。 アプリケーション サービス間の調整を最小限に抑えてスケーラビリティを実現します。 スケール アウトするように設計します 。需要に応じて新規インスタンスを追加または削除し、水平方向に拡張できるようにアプリケーションを設計します。 制限に対処するようにパーティション化します 。 パーティション分割を使用して、データベース、ネットワーク、コンピューティングの制限に対処します。 操作に合わせて設計します 。 運用チームが必要なツールを得られるよ
Azure OpenAI Service リファレンスアーキテクチャからみる本番システムレベルの LLM アプリに必要な検討項目の解説 / From Azure OpenAI Reference Architecture to Production-Ready LLM Apps #serverlessdays #serverlesstokyo
ServerlessDays Tokyo 2023 で Azure OpenAI Service リファレンスアーキテクチャからみる、本番システムレベルの LLM アプリに必要な検討項目の解説 / From Azure OpenAI Reference Architecture to Production-Ready LLM Apps というタイトルで紹介しました HP: https://tokyo.serverlessdays.io/ Ticket: https://serverless.connpass.com/event/290640/ #serverlessdays #serverlesstokyo
僕は自分が思っていたほどは頭がよくなかった - しのごの録
Redditで話題になっていたポストを訳してみた。 僕は自分が思っていたほどは頭がよくなかったという高校生の独白にたいしてつけられたこのちょっと長めの返信がとても的確で示唆に富んでおり、多くの人のこころをつかんでいました。私自身、勇気づけられるというか身につまされるところがあり、忘れないために翻訳をしてみました。 まずは高校生の独白から。 僕は自分が思っていたほどは頭がよくなかった 僕はいま高校の最終学年で、次の６月に卒業する予定です。高校の成績は、いままでずっとAを取りつづけていましたが、去年始めてBをとってしまいました。もしそのBがなければ、卒業生総代に選ばれていたでしょう。 総代にふさわしいのは自分だ、つまりクラスで本当に一番頭がいいのは自分だと思いたいです。でもこの一年で、僕にそれほどの知性はないし、僕より頭のいい人はたくさんいるんだということを思い知らされました。 また僕は、自分
DXインターンの振り返り〜インフラ未経験からCNDT2020に登壇するまで〜 | Wantedly Engineer Blog
皆さんこんにちは 👋Wantedly DXチームインターンの森本です。 9月にインターンが終了してしまうので、最後にインターンの総括をしようと思います。(割と自分用です) 具体的には、インフラ未経験(本当に0)の状態から最終的にCNDT2020に登壇するまでで、学んだことおよび気をつけていたことなどを書きます。インターンのプロジェクト内容は本記事では割愛しますので、こちらをご確認ください。 Istioを使って「Fast, Dependency-Agnostic, Isolated」な開発体験を実現した話 | Wantedly Engineer Blog 皆さんこんにちは 👋Wantedly DXチームインターンの森本です。 今回は私がインターン課題として取り組んだ、 Istioを使って「Fast, Dependency-Agnostic, Isolated」な開発体験を実現した話 を紹
その Kubernetes は 効率的にマシンを活用できているか #CNDT2020_RJKT #CNDT2020_RJKT_B / CNDT2020 Rejekts
CNDT2020 Rejekts その Kubernetes は効率的にマシンを活用できているか / 坂部 広大
The History of Distributed Databases - Google, Amazon, Facebook など巨大企業による分散データベース技術の発展 | Wantedly Engineer Blog
こんにちは、Wantedly の Infrastructure Team で Engineer をしている南（@south37）です。 今日は、WANTEDLY TECH BOOK 5 から「巨大企業による分散データベース技術の発展」という章を抜粋して Blog にします。 「WANTEDLY TECH BOOK 1-7を一挙大公開」でも書いた通り、Wantedly では WANTEDLY TECH BOOK のうち最新版を除いた電子版を無料で配布する事にしました。Wantedly Engineer Blogでも過去記事の内容を順次公開予定であり、この Blog もその一環となっています。 Wantedly における Go 導入にまつわる技術背景 | Wantedly Engineer Blog （本記事は Go Conference 2019 Autumn にて無料配布した冊子『WANT
#srefm Production Readiness 会まとめ - ツナワタリマイライフ
はい。こちらのイベントのまとめをしていきます！ t.co 今回はゲストに @koudaiii さんと _a0i さんをお招きして、Application や Infrastructure / Platform の Production Readiness について語りました！ お二人を選んだ理由としては、坂部さんの場合は Production Ready に関するアウトプットがすでにあったということで、すぐに打診しました。aoi さんのほうはサイボウズさんとかどうだろうねということで思いついて声かけました！お二人とも快諾していただき感謝です。 期待とか chaspy の所感とか hackmd のほうにざーっと書いたやつ。 chaspy の所感 Production Readiness Checklist とても良いもので、やってよかった。 SRE の負担を最小限にしつつ、Developer
Istioを使って「Fast, Dependency-Agnostic, Isolated」な開発体験を実現した話 | Wantedly Engineer Blog
皆さんこんにちは 👋Wantedly DXチームインターンの森本です。 今回は私がインターン課題として取り組んだ、Istioを使って「Fast, Dependency-Agnostic, Isolated」な開発体験を実現した話を紹介します。 DXチームとはデラックスチームではありません。Developer eXperience チームです 😉社内の開発体験を向上させることを目標に頑張っています。詳しくはメンターの大坪さんの記事を御覧ください。 マイクロサービスWantedlyのアプリケーションは異なる役割を持った複数のサービスによって構成されています。これをマイクロサービスアーキテクチャと呼びます。サービスは、RubyでDBにアクセスしユーザー情報を管理するもの、Pythonで機械学習を行うもの、Goで通知を発行するものなど様々です。それぞれのサービスは、モバイルやブラウザおよび他の
これから、シゴトとどう生きる？ 8万人の意識調査から考える「#シゴトの未来」 | Wantedly, Inc.
緊急事態宣言が出されてから1ヶ月が経ちました。前触れもなく訪れた「withコロナ」の現実は、私たちと仕事との関係性を大きく変えつつあります。 未知のウイルスとの戦いという、人類史の重大局面のまっただ中で、働く人々はなにを感じ、そしてどこに向かおうとしているのでしょうか。その答えを探るために、ユーザーへのアンケートを行いました。 「withコロナ」の現実と、働き手の心境変化。今回のアンケートは、2020年4月1日から5月6日までの毎週、計5回にわたって行われました。投票/コメントにあたってはつながりアプリ「Wantedly People」のPoll機能を使用し、総計81,572人のユーザーから129,476票の回答を得ることができました。 揺れる働き方「withコロナ」の時代の変化をなにより象徴しているのが、在宅勤務の拡大。緊急事態宣言が公表される直前の週では22.6％だった在宅勤務の割合が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
キャッシュと向き合う、キャッシュと共に生きる / cache pattern
