Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
![注目を集めるリアクティブプログラミング](https://cdn-ak-scissors.b.st-hatena.com/image/square/ae84da8ad454d9f147ee9b8b3d04e38c76d6581b/height=288;version=1;width=512/https%3A%2F%2Fcdn.infoq.com%2Fstatics_s2_20240530133300%2Fstyles%2Fstatic%2Fimages%2Flogo%2Flogo-big.jpg)
OAuth.ioは,80以上のOAuthプロバイダにインターフェースするAPIであり,サービスである。今回の記事では,共同創設者のMehdi Medjaoui氏とのインタビューを通じて,セキュリティやライセンスなどの詳細,今後の開発計画などについて紹介する。 OAuth.ioは,ユーザ認証やAPI認証のコード記述をシンプルにしようとする試みのひとつだ。開発者は異なるバージョンやプロトコル(1.0, 1.0a, 2.0)を実装した複数のOAuthプロバイダに対応しなくても,以下のスニペットに示すように,ひとつのAPIだけを使ってプログラムすればよい。 $('#fb-connect').click(function() { OAuth.initialize('YOUR_PUBLIC_KEY'); OAuth.popup('facebook', function(err, res) { if (
iOSアプリケーション開発会社の経営者であるDrew Crawford氏は、現在のモバイルWebアプリケーションが遅く、また、近い将来にその遅さが大幅に改善されると思えない理由を、ブログ記事(内容が充実しており、良く調査して書かれている)の中で明らかにした。 このブログ記事は、これより前に書かれた記事への追加記事である。前の記事で氏は、モバイルにおけるJavaScriptのパフォーマンスがデスクトップの10倍遅いことを指摘した。その記事は激しい批判を浴びたため、Drew氏はそれに答える形で、さらに詳細な内容の記事を記した。モバイルの貧弱なパフォーマンスと、それについての改善が見られない理由は、次の3つに分類される。 モバイルのARMプロセッサのスピードと、デスクトップのx86プロセッサのスピードとの違い JavaScriptエンジンのパフォーマンスの傾向 ガベージコレクションに関連する特定
ここではこのYogaの使い方をデモし、RESTシンタックスの使いやすさを保持しながら、Yogaがアプリケーションの性能を改善することを示します。 リソースのフィールドを定義する 次は典型的なRESTリクエストで、リソースのインスタンスを検索しています。これはUserリソースタイプに関連するすべてのフィールドを返します。 GET /user/1.json セキュリティや性能を考慮してあるユーザの名前とロケーションデータだけを取得するリクエストを生成したい場合はどうすればいいでしょう。この場合は、リクエストにセレクタを追加できます。 GET /user/1.json?selector=(id,name,city,state,country) 公開APIを公開するためには無制限にセレクトできる機能をエンドユーザに与えたくないかもしれません。これは、定義されたセレクタにエイリアスを付加することで達
1992年にWard Cunningham氏が、技術系ではないステークホルダにこの問題を伝えるために、初めて「技術的負債」というメタファを使いました。品質の低いコードと自動テストによるカバレッジがないことは、財務的負債と比較されます。このようなコードは、開発者だけでなく、すべてのステークホルダが負う財政的な重荷になり、将来的に利息が課される負債になります。元本額は、コードベースを将来簡単に変更できるようにリファクタリングするコストです。利息は、チームがよいコードではなく、汚いコードに取り組まなければならない場合に、将来支払う余分なコストです。 財務的負債とは違い、技術的負債は返済しなくてもよい負債です。時には、返済するのが無駄なこともあります。ある部分のコードを読んだり、変更したりすることはめったにないか、決して起こらないかもしれません。そのため、技術的負債も、どのくらい起きそうかを考慮す
ドメイン・モデルと開発に注力しないと"太ったサービス・レイヤ"と"ドメイン・モデル貧血症"によるアプリケーション・アーキテクチャになってしまいます。この場合、ファサード・クラス(通常はステートレス・セッション・ビーン)にどんどんビジネス・ロジックが溜まっていき、ドメイン・オブジェクトがgetter/setterからなる単なるデータの運び屋のようになってしまいます。このアプローチをとるとドメイン固有のビジネス・ロジックやルールが複数の異なるファサード・クラスに散在(時には重複)することになります。 "ドメイン・モデル貧血症"はたいていの場合、コストに見合いません。他の企業と比較して利点があるわけではなく、このアーキテクチャの下でビジネス要求の変化を実装するには開発と本番環境へのデプロイするのに時間がかかり過ぎます。 DDD実装プロジェクトにおけるいろいろなアーキテクチャや設計について見ていく
以前に有名となった「Apache vs Yawsのグラフ」(source)を見て、あなたもまたYawsを使うべきだと思ったでしょうか? 一見すると、そのグラフは、Yawsに対する信じられないくらい大きなスケーラビリティの優位性があるように見えます。Apacheが4000のパラレル接続でダウンしたのに対し、Yawsは80,000を超えるスケール能力を持っています。このグラフに対する反応は大きく二極化する傾向にあります。「これらのグラフは正確な方法で行われたものではなかった」あるいは「Apacheの設定ミスに違いない」というものと、それとは反対に「ワオ!Yawsを利用する価値がある」というものです。 Yawsの比較グラフを信じるかどうかに関係なく、Yaws(サイト・英語)は動的コンテンツを提供するための確かなWebサーバーです。Claes Wikstrom氏は、Yawsを「もう一つのWebサー
.NETで簡単な例を見てみましょう。 public Person : INotifyPropertyChanged { string firstName, lastName; public event NotifyPropertyChangedEventHandler PropertyChanged; protected void OnPropertyChanged(string propertyName) { if ( this.PropertyChanged != null ) { this.PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } } public string FirstName { get { return this.firstName; } set { this.firstName
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く