Laravelでの開発を例に考える、SimpleとEasyの違い - Part1
2019年2月16日、PHPのフレームワークであるLaravelをメインテーマに据えた技術カンファレンス「Laravel JP Conference2019」が開催されました。「Laravel JP」を冠したイベントとして日本初開催となる今回。数多くのLaravelユーザーが参加し、知見を共有します。プレゼンテーション「SimpleとEasyは違う」に登壇したのは、株式会社クラシコム廣瀬健氏。講演資料はこちら SimpleとEasyは違う 廣瀬健氏（以下、廣瀬）：株式会社クラシコムの廣瀬と申します。よろしくお願いします。 （会場拍手） ありがとうございます。入社が一昨年の12月なので、ちょうど1年経ったくらいですね。前職まではRailsをやってて、クラシコムに入ってからLaravelを触るようになりました。 会社のエンジニアのブログでRailsとLaravelの比較記事を書いたり、あとさっ
キャッシュを活用するために必要な知識と勘所 - そーだいなるらくがき帳
どうもキャッシュバスターズ、 id:Soudai です。 Cache（以下、キャッシュ）は特定の場面に置いて劇的な効果を発揮し、様々な問題を解決する反面、新たなコンポートやミドルウェアが追加され、複雑性が上がり、運用のレベルが上がるため、扱いに注意する必要があります。 キャッシュを活用することで、パフォーマンスの改善や負荷軽減が行われ、コンピュータリソースの最適化によるサーバコストの削減や、レスポンスの改善によるユーザエクスペリエンスの改善がされます。 反面、その劇的な効果に毒され安易に多用すると、サービスが強くキャッシュに依存してしまい、非常に壊れやすくなり、運用が難しくなってしまいます。これをWeb界隈では「キャッシュは麻薬」と比喩されて、戒められてきました。 そのためキャッシュを使わずにサービスが運用できるのであれば使わないに越したことはないのですが、ある一定以上の規模になった際にコ
Webシステムにおいて「画像や帳票等のファイルはDBへ格納すべきなの？」を調べてみた（ファントムファイル） - Qiita
Webシステムにおいて「画像や帳票等のファイルはDBへ格納すべきなの？」を調べてみた（ファントムファイル）oracleWeb この記事は、 JPOUG Advent Calendar 2023 24日目の記事です。 23日目は multilayer さんの記事『OCIのLanding Zoneについて調べてみた！』でした。 想定読者 ファントムファイルについてよく知らない、帳票の扱い方をあまり考えたことがない人 イントロダクション 皆さん、世の中のWebシステムで利用される画像や帳票ファイルがどこに保存されているかご存知でしょうか？ 帳票や大きな画像ファイルなどを扱う際、大きく分けて２つの設計方針があります。 ・DBに直接保存する ・DB外部に保存し、パスなどをDBに保存する オライリーのSQLアンチパターンの、”ファントムファイル”という章にはこのあたりのことが書いています。 [Amaz
開発者が知るべきキャッシュ設計でよく遭遇する問題
はじめに 分散システムの設計および開発において、キャッシュはパフォーマンス向上のための非常に重要な要素です。頻繁にアクセスされるデータをキャッシュすることで、アクセス速度が遅いデータベースへのアクセスを削減し、データへの迅速なアクセスを可能にします。これにより、システムの全体的な効率とパフォーマンスが向上します。 しかし、キャッシュは慎重に設計しないとむしろパフォーマンス上のデメリットになるケースが存在します。 この記事ではよく遭遇するキャッシュ設計の問題とその回避策について解説します。 Cache penetration DBに存在しない値を検索したときに、DBから返された空の結果をキャッシュしない場合に発生するシナリオです。 このシナリオではDBに存在しない値を繰り返し検索することにより、その値がキャッシュされていないため検索ごとにDBへのアクセスが必要になってしまいます。 存在しない
コードや設計で「シンプル」が良いのはわかるが実際にどうすれば良いだろう？｜牛尾 剛
先日、IaC (Infrastructure as Code) のコードを書いている時に自分が体験したシンプルさの威力の体験と、どうやったら「シンプル」に設計・コーディングができるか？ということについて調べてみたので整理したい。 「はじめて」の人に敗北 先日、私がSLA Site というアプリのデプロイスクリプトを terraform で書いていた時のこと。この Site は内部で機能に何か問題が起きた時にお客さんより先に気づくための仕組みで、私は、Azure Functions の VNet インテグレーション、Managed Indentity、KeyVault Reference といった機能が正常に動作さするか確認するためのアプリを作っていた。 Azure Functions は対応する Event Source の数が多いため、私は、沢山のサイトを作り、Vnet インテグレーショ
なぜソーシャルログインの際にemailをキーにして参照するのか
ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2023 の 初日の記事です。 こちら、参加者を募集中です！気軽に参加してみてください！してくれよ！はよ！ なんの話か ちょっと想定以上に反応をいただいたこちらの記事について、ちょっとだけ補足をしたいと思います。 なんの話か詳しく 自分のはてブのコメントをつけたポストにもたくさん反応いただきました。 実際、海外のサービスはメアドをキーにして参照してるところも多く これはサービスのDBのUserテーブルがemailをプライマリキーにしているという話ではありません(が、そう思われた方からDMが来ました)。 最初にパスワード認証やメールでリンクを送信して認証させる仕組みを実装している状態から、ソーシャルログインを実装しようとする際に "email" をキーにした参照をすることがあるんよ
メールアドレスをキーにしてID連携を行う設計の危うさ｜ritou
ritouです。このしずかなインターネットにおける初投稿です。 おそらく、このしずかなインターネットのID連携では次のような設計になっていま「した」。問い合わせをさせていただき、対応いただきました。 これまでもQiitaなどで同様の実装例が紹介されていた際にはコメントさせていただいていたものですので、アンチパターンの紹介記事として読んでいただければと思います。 「Googleアカウントでログイン」ではじめると、ユーザーが作成され、Googleから受け取ったメールアドレス([email protected])が設定される 次回から「Googleアカウントでログイン」をすると、Googleから受け取ったメールアドレスでユーザーを参照 試しに、次のような流れで動作を確認してみます。 「Googleアカウントでログイン」でアカウント作成([email protected]) 「メールアドレス変更」
ITエンジニア向けのトレンド情報 | Forkwell Press （フォークウェルプレス）
「良い設計は悪い設計より変更が楽で安全である」これが『現場で役立つシステム設計の原則』の根底にある考え方です。 ・変更容易性はどんな効果を生み出すのか ・どうやれば変更を楽に安全にできるのか 最近の技術動向に触れながら説明します。 オブジェクト指向プログラミングの考え方の変化、クラウドベースの分散処理の進展、ドメイン駆動設計の広がりなどを取り上げます。 良い設計と悪い設計の違い 良い設計 → 変更が楽で安全 悪い設計 → 変更が厄介で危険 設計を評価する一番のポイントは「変更容易性」です。 だからといって、目の前のソフトウェアのあらゆる箇所を実際に変更してみて良し悪しの評価をすることってできないですよね。では、どうするのかというと「不吉な臭い」を察知することです。悪い設計のコードには「不吉な臭い」があります。これは実際に変更をしなくても、コードを見て判断できます。（後ほど詳しく解説します。
構成図を描く際に気をつけていること - NRIネットコムBlog
こんにちは、越川です。 皆さんは構成図を描く機会ありますか？ 僕の場合、内部のメンバーやお客様との議論の場で、構成図を描いて図解ベースで説明することが多いです。実際に描いてみると色々と考慮すべき点が多く、今回は自分なりに普段意識している点を言語化してみようと思います。 なぜ構成図を描くのか 構成図を描く際に意識している３つのこと 1. 導線 2. 引き算思考 1. 主役を決める 2. 読者を想定する 3. 高さや大きさを揃える さいごに なぜ構成図を描くのか 構成図のメリットは相手に伝えたいことをシンプルに伝えられる点だと思います。文章で書くと沢山書かなければいけないことが構成図を使うとスムーズに相手に伝わります。例えば、以下の文章を読んでみて下さい。 ユーザーはDNS登録されたFQDNへHTTPSアクセスする CloudFrontはBehaviorに指定されたALBにHTTPSリクエスト
クックパッドの検索反映時間を 1/288 にしたシステム改修 - クックパッド開発者ブログ
こんにちは。レシピ事業部の新井（@SpicyCoffee）です。 クックパッドではこれまで、レシピを投稿してから検索結果に反映されるまで最長で 24 時間程度の時間がかかっていました。今回、この時間を 5 分程度、最長でも 10 分程度に短縮することに成功しました。本記事では、プロジェクトオーナーの立場で関わった私が代表してその開発について紹介します。 プロジェクトの目的と数値目標 本プロジェクトでは上記の「レシピを投稿してから検索結果に反映されるまでの時間短縮」が目的とされました。しかし、時間短縮といっても現状 24 時間であるものを "1 時間" にするのか、"1 分" にするのか、"1 秒" にするのかでは話が全然違います。この数値目標は設計を始めとした後の意思決定に大きく影響を与えるため、しっかりとした意図を持った状態で明確に定めておく必要がありました。 そこで、私とプロダクトオー
Instagramはどうやって3人のエンジニアで1400万人にサービスを提供できるシステムを組み上げたのか
Instagramは2010年10月にサービスを開始後、2011年12月までのわずか1年間で1400万人に利用されるほど巨大なサービスに成長しました。こうしたスケールに対応できるシステムを組み上げたのはたった3人のエンジニアだったとのことで、どのように少人数でスケールするシステムを組み上げたのかについて、エキスパートエンジニアのレオナルド・クリードさんが解説しています。 How Instagram scaled to 14 million users with only 3 engineers https://engineercodex.substack.com/p/how-instagram-scaled-to-14-million レオナルド・クリードさんは、Instagramが3人のエンジニアで安定して巨大なサービスを提供できた理由として、下記の3つの原則を守ったからだと述べています
ソフトウェア設計・アーキテクチャの学び方 - Qiita
はじめに この記事はHow to Learn Software Design and Architecture | The Full-stack Software Design & Architecture Mapを翻訳したものです。 翻訳がおかしい箇所などあればご指摘頂けるとありがたいです。 元記事の著者: Khalil Stemmler(@stemmlerjs) 設計、アーキテクチャ、フロントエンド、ブロックチェーンに興味ある方是非Twitter(@show_clements)フォローしていただけると嬉しいです！ 設計に関する記事 ソフトウェアデザインとアーキテクチャは、DevOpsやUXデザインのように、コンピューティングの領域の中でも独自の研究分野となっています。ここでは、クリーンコードからマイクロカーネルまで、ソフトウェアデザインとアーキテクチャの幅広さを説明するマップを紹介しま
APIトークン認証の論理設計
SPAやモバイルアプリから利用するAPIを開発する際の、トークン認証のお話です。 どの認証ライブラリを使うべきという話ではなく、トークン認証の論理的な設計について考察します。 私自身も結論が出ていないので、色んな意見が聞けると嬉しいです。 出発点 ユーザテーブルにアクセストークンを持つのが最も安直な発想だと思います。 ログイン成功時にアクセストークンを発行し、該当ユーザレコードにセット。 同時に有効期限もセットします。 認証時には、アクセストークンが存在し有効期限内であれば、認証を通過させ、 そうでなければ認証失敗とします。 ログアウト時には、該当ユーザレコードのアクセストークンを空にします。 発行日時を持ち、システム内に定義された有効期間をもとに、認証時に計算する方法もあると思います。 Laravel Sanctum 等はそういう実装です（しかもデフォルトでは有効期限なし）。 有効かどう
今さら聞けないログの基本と設計指針 - Qiita
ログの出力場所 ログは、開発者や運用担当者が見つけやすい箇所に出力することを原則としましょう。ファイルに出力する場合は、logディレクトリなどを作成しておくことをお勧めします。基本的に、出力先は以下の4つが想定されます。 ・ファイルに出力する コンソール外で起動するアプリケーションに使用される方法です。 ・標準出力 コンソールから起動するアプリケーションで使用されます。途中経過などを出力するための出力方法です。 ・外部ログ管理ツールのファイルに出力 外部のログ管理ツールを用いることが可能な場合は、専用のログ記録場所に出力することを推奨しています。 ・外部システムへ出力 開発者・運用者の作業やコミュニケーションを円滑に行うために、Slackなどのチャットツールに出力するケースもあります。ただし、稼働率に注意する必要があり過度なログの出力は控えるようにしましょう。 基本的に、外部ログ管理システ
同時接続数30万超のチャットサービスのメッセージ配信基盤をRedis Pub/SubからRedis Streamsにした話
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog Overview 30万を超える同時接続数を持つチャットサービスにおいて、リアルタイムでメッセージの受信などのイベントを配信するメッセージブローカーとして、私たちはRedis ClusterのPub/Subを使用していました。 私たちのサービスでは、ユーザー数の増加に伴い、Redis Clusterのシャード数を増やすことでクラスターの性能を向上させてきました。しかし、Redis ClusterのPub/Subでは、シャード数の増加に伴ってネットワーク帯域が圧迫される問題が生じ、これ以上シャードを追加することができない状況になりました。 この課題を解決するために、メッセージブローカーをRedis Pub/SubからRedis
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
状態設計から「なんとなく」を無くそう
24時間365日動き続けるデータシステムの設計手法 : 「データ指向アプリケーションデザイン」実践編
失敗から学ぶAPIファースト / API first learning from failure
マイクロサービスにおけるBFFアーキテクチャでのモジュラモノリスの導入
Goで実装された高速な
仮想待合室サーバの実装と詳解
