エンターテイメント業界におけるAWS活用事例AWS Black Belt Techシリーズ 2015 Amazon Elastic Block Store (EBS)Amazon Web Services Japan
これから設計を学ぶ君に贈る一冊 #君に贈る102冊目の名著 - Create a new world
こちらの翔泳社さんの本 100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊 作者: デブサミ運営事務局,SEshop.com編集部出版社/メーカー: 翔泳社発売日: 2012/02/22メディア: 単行本（ソフトカバー）購入: 18人 クリック: 537回この商品を含むブログ (38件) を見るを読んでて、自分もちょっと書評を書きたいなぁと思ったので書いてみます。 今回の書評はこちら。 ユースケース入門―ユーザマニュアルからプログラムを作る (Object Technology Series) 作者: ダグローゼンバーグ,ケンドールスコット,Doug Rosenberg,Kendall Scott,長瀬嘉秀,今野睦,テクノロジックアート出版社/メーカー: ピアソンエデュケーション発売日: 2001/11メディア: 単行本購入: 1人 クリック: 38回この商品を含むブログ
複数のリソースに一度にアクセスしたいときのURL設計 - ぶろぐ。@はてな
「RESTとRailsスタイル]」のときに、@shu_0115さんから「複数同時に書き込みたいときはどうするか」という質問がありました。これは実用上はなかなか重要な点だと思うので、少しまとめます。 親子関係のリソースを更新 例えば /users/123 と /users/123/profile を両方変更したいなど。 この場合は、親に対するリクエスト PUT /users/123だけですませるのが一般的です。POSTでユーザを新規作成するときも、自動的に子のリソースが作られたとみなしますよね。 複数のMemberリソースを更新 例えば /posts/1 /posts/2 /posts/3 の3つの投稿に同時に「rest」タグをつける、というUIがあるかもしれません。 この場合、とくにアトミックな必要はないので、Ajaxでリクエストを3回送ってもかまわないのですが、3個ならまだしも10個など
デブサミ2012で大規模JS開発について発表してきました - yo_waka's blog
「Developers Summit 2012 - 10年後も世界で通じるエンジニアであるために」で発表してきました。 デブサミ2012 kintoneの表と裏 - 表編 View more presentations from yo_waka イマドキのJSの話とかではなくて、UIをJSで作る際の設計ノウハウみたいな話にしたので、つまらなかったら申し訳ないなと思ってたのだけど、終わったあとも何人か質問しにきてくれた方がいたのでホッとしました。 10年後も・・というテーマとして、激しく進化するJSの最新動向に左右されず使えるネタを選んだつもりではあります。 普段からJSでもパフォーマンス意識して設計してる方には当たり前のことばかりだったかも。 jQueryは甘えってのは書いてみたかっただけですすいません。。 けど、適材適所というかSinatraで100画面近くあるようなWebアプリは作らな
RailsのURL設計を考えてみる(6) 設計の選択肢 - ぶろぐ。@はてな
今回は直接Railsとは関係ないのですが、先日こういうページを見つけました。 http://redrata.com/restful-uri-design/ これは2009年に書かれたもののようですが、URL設計に関する重要な考え方がいろいろ書かれています。 その中に、このブログのシリーズの(4) スラッシュと「持っている」関係や(5) Railsのリソースパターンの前段階になるような“Choosing a URI schemes for resource hierarchies”という話があったので、かいつまんで紹介したいと思います。 リソースの階層に対して、どういうURLを設計するか？ 前提として、設計するWebサイトには、conversation（会話）というリソースが複数あり、それぞれのリソースはユニークなIDで区別されるとします。（IDは数字とは限らない識別子） /conversa
pixivポップボードのキャッシュの仕組みとFacebookのUIの話
pixivポップボードのキャッシュの仕組みとFacebookのUIの話 こんにちは。JavaScript Advent Calendar 2011 オレ標準コース18日目の@ykskです。 先日pixivにポップボードという通知機能がリリースされました。自分がお気に入りユーザーに追加されたり、投稿したイラストがブックマークされたりした時にヘッダーに未読件数などのお知らせを表示します。僕は直接機能を実装していたわけではないのですが、リリース直後に起こった負荷の問題でJSを書きました。今日はその話をします。主にUIの話です！ え！ リリース直後、定期的に未読数の更新をAjaxで行っていた部分の負荷が急激に上がりました。ページロード時にHTMLに未読数を埋め込んだあと、2分ごとに未読数取得APIへリクエストするという処理です。 ポップボードはヘッダーに出るため、ほぼ全てのページでこの処理が入りま
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
人間のために分かりやすい実用的なURLを設計する方法
URL Design [ad#ad-2] 下記は各ポイントを意訳したものです。 はじめに URLを設計する理由 トップレベルのセクションは重要 URL構造を増強する方法 クエリの文字列 URLにはASCIIを URLは検索エンジンのためにではない URLは合意 全てがURLを持っているべき リンクはリンクらしく 再利用できないURL 素晴らしいURLの例 おわりに はじめに あなたは、URLの構造を設計するのに時間をかけるべきです。この記事を読んだ後で、あなたに一つだけ覚えておいてほしいことは、URLの構造を設計するのに時間をかける、ということです。 URLデザインは簡単ではなく、正しい解決方法があると言うことはできません。しかしそれは、他のデザインと同じです。良いURLデザインがあり、良くないURLデザインがあり、そしてその中間もあります。 しかし、それは素晴らしいURLデザインを作るこ
iPhone 開発規約まとめ
あんまり iOS 上での開発規約とか見かけないので、試しに私が今個人/会社で使っている開発規約を公開してみることにしました。 ■設計 設計は所謂 MVC と呼ばれる設計モデルを採用します。ただし、厳密な MVC というわけではなく、以下のような区分になっています。Model Core Data を使用します。通常 MVC での Model というと業務ロジック等を含めた業務モデル一般すべてを含むのですが、私の場合は特に Core Data の NSManagedObject を Model として扱い、 Model 単体のみで完結するロジックのみを Model に記述します。たとえば、Core Data から対象の Model とその関連 Model 取得Model の新規作成新規作成時、更新時に自動的に Model のプロパティを更新するModel のプロパティの値を元に幾何学計算をした
メソッド設計で守るべき10個のルール - A Day In The Life
以前メソッド設計の原則に関する記事を書きましたが 質問をすることで答えは変更されない原則 メソッドの引数はオペランドのみにする原則 それ以前にメソッド設計する上で最低限守った方がよいルールをまとめてみました。 プロパティをメソッドの戻り値代わりに使ってはいけない ファンクションメソッドでプロパティの値を変更してはいけない プロパティをリターンしない インスタンス変数やプロパティをメソッドの引数に渡さない 参照渡の引数をリターンしてはいけない 例外処理を GoTo 文の代わりに使ってはいけない 理由なく id 型をメソッドの戻り値にしない 特定メソッドの呼びだしが前提になったメソッドを作ってはいけない パブリックメソッドからパブリックメソッドを呼ばない プライベートメソッドからパブリックメソッドを呼ばない 以下その詳細です。 プロパティをメソッドの戻り値代わりに使ってはいけない メソッドが呼
法と技術とクローラと私 - 最速転職研究会
こんにちは、趣味や業務で大手ポータルサイトのサービスで稼働しているいくつかのクローラの開発とメンテナンスを行っているmalaです。 さて先日、岡崎市立中央図書館Webサイトをクロールしていた人が逮捕、勾留、実名報道されるという事件がありました。 関連URL: http://librahack.jp/ 電話してみた的な話 http://www.nantoka.com/~kei/diary/?20100622S1 http://blog.rocaz.net/2010/06/945.html http://blog.rocaz.net/2010/07/951.html この件につきまして法的なことはともかくとして技術者視点での私見を書きたいと思います。法的なことは差し置いて書きますが、それは法的なことを軽んじているわけではなく、法律の制定やら運用やらは、その法律によって影響が出る全ての人々の常識
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
中規模向けJS設計