■答えは「電子商取引及び情報財取引等に関する準則」に書いてある 経済産業省は,ネットショッピングやデジタルコンテンツをめぐる法的問題について「電子商取引及び情報財取引等に関する準則(以下準則)」を発行しており,たいへん分かりやすいです。 準則「Ⅱ-2他人のホームページにリンクを張る場合の法律上の問題点」によると,基本的な考え方は以下のとおりです。 ・インターネット上において、会員等に限定することなく無償で公開した情報を第三者が利用することは、著作権等の権利の侵害にならない限り、原則自由 ・ただしリンク先の情報を ⅰ)不正に自らの利益を図る目的により利用した場合 ⅱ)リンク先に損害を加える目的により利用した場合 など特段の事情のある場合は例外的に不法行為責任が問われる可能性がある ■リンクを張っても原則として著作権法違反にはならない リンクを張ると,自サイト(リンク元サイト)内のURL等をク
今週のMackerelアップデートです URL外形監視を実験的機能としてリリースしました URL外形監視をリリースしました。実験的機能としてご利用いただけます。 指定したURLに対して、1分おきにステータスコードの監視を行い、4xx, 5xxのステータスコードを検知した際にアラートが通知されます。 これにより、内部のagentから送られてくるメトリックだけでなく、一般ユーザがアクセスする外部からの状態もあわせて監視することができるようになります。 本機能はトライアルプランか有料プランでのみご利用いただけます。 詳しくはヘルプをご覧ください。 mackerel.io また、実験的機能の利用方法についてはこちらのヘルプをご覧ください。 mackerel.io Mackerel開発チームでは、本機能の正式化に向けて開発を進めております。 開発の参考とさせていただきますので、ご意見・ご要望などフィ
tumblrみたいなやつのRoutingパターンtumblrみたいなやつ (そろそろ適当な名前を決めたくなってきた) をRuby on Railsを利用して実装するにあたって、主にRoutingの周りで考えたことについてまとめておく。他の人がWebアプリ書くときの参考になれば。 機能 tumblrみたいなやつには以下のような機能がある。 ログイン・ログアウト・サインアップ 記事の一覧・詳細・投稿・編集・削除 あるタグの付いた記事一覧 あるユーザの投稿した記事一覧 記事にスターを付ける・外す 記事にタグを付ける・外す 通知一覧 画像投稿 config/routes.rb Routingのコードはコピペするとこうなってる。 Rails.application.routes.draw do root to: "posts#index" get "/@:user_id" => "users#sho
最近流行りのショートURLサービスについて、 どういうロジックなのか興味をもっていたので、 探してみたところ、Base58という単語にいきつきました。 参考: flic.kr で使われている base58 のデコードを行う javascript のコードCommentsAdd Star Flickrの短縮URLをRubyで生成 要は、内部的にDBなどでデータを管理するときに、 IDとして数値を採番することはよくあると思うが、 それをもとに、IDの数値をそのまま文字列としてURLなどを作ると、 (ID=12345678901234567890だとする。長い。) http://example.com/ID/12345678901234567890 と、長くなってしまう。 そこで、可逆化エンコードであるbase58を使うと、 http://example.com/ID/uE87b9NPNGu と
Twitter, GitHub, Qiita などのように root/(username) でユーザーページをルーティングするところが増えてきている. このルーティングを採用し, help などのユーザー名を許可すると, root/help が奪われてしまう. そこで, 登録時に validate で, ある程度排除するのが習わしになっていると思うが, 急に root 直下に置きたいページが増えたときなどに取得されていると悲しいことになる. また, サブドメインを利用するサービスだと, api などをうっかり取られてしまうケースが後を絶たない. http://api.hatenablog.com/ みたいに取られることによる面白みもあるが, おおむねつらい. 実際, twitter では search アカウントが取られていて, TweetDeck では twitter.com/searc
昨日「URLに関する議論 -- なぜ僕はクエリパラメータを擁護、ときに推奨するのか」という記事を書きました。そこで出した簡単な事例は、足し算を要求するのに、/calc/add/2/3 みたいなURLを使うのはやめて /calc/add?x=2&y=3 とか /calc/?op=add&arg1=2&arg2=3 にしようぜ、というものです。 実際には、URLのパス部分が既に存在する実体を指すことを強要すると、PUTメソッドでファイルを作りたいときはどうすんだ? といった問題もあります。が、個別の問題を議論する前に、クエリーパラメータや拡張子を擁護する背景をもうちょい説明します。 内容: 合意と伝達は大変 XMLを使ってエンコードする方法 URLにエンコードする方法 とにかく手間を減らすには 名前やパスに情報を含ませること まとめ 合意と伝達は大変 僕は「合意と伝達」の問題に強い関心を持って
これApigee | Google Cloud Blogの勝手訳のつづき。ここらから、なかなかの割り切りを推奨していて、いよいよ「実用的REST」になってきた感じ。 関連づけを単純化する - 複雑なものは‘?’の下に一掃する このセクションでは、リソース間の関連と状態や属性のようなパラメーターとを取り扱うばあいの、APIのデザインの検討事項を探索します。 関連付け リソースはたいていいつでも他のリソースと関連しています。Web API でこれらの関連を表現する単純なやりかたとは、なんでしょうか? もういちど、「名詞は良い・動詞は悪い」でモデル化したAPI - そのAPIは犬 dog リソースでやりとりするものでした - をみてみましょう。思い出してください、/dogs と dogs/1234 という2つのベースURLがありました。 HTTP動詞をつかって、リソースとコレクションを操作しまし
「ハイパーリンクは何を繋ぐのか」と「ハイパーリンク設計をサーバーサイド設計に従属させるべきではない」では、既存の用語を使い、ある程度は現実っぽい例を出したりして説明をしました。 このようなスタイルの説明は諸刃の剣です。具体的で分かりやすく感じる反面、夾雑物〈きょうざつぶつ〉をイッパイ含んでいるので誤解と祖語齟齬のタネが満載。誤解と祖語齟齬を減らすには: 既存の用語を使わない。(新しい言葉を造るか、既存用語の意味をリセットしてから使う。) 抽象的な定式化をする。 当然に、これはこれで問題があるわけです。そもそも、聞き慣れない言葉を使い抽象的に語れば、興味を持つ人が誰もいなくなります(正確には、極端に少なくなる)。 まー、自分用のまとめと思って書いておきます。「ハイパーメディア・アプリケーションをどう捉えればいいのか」の後半で抽象的な定式化は書いておいたのですが、もう少し簡略化します。 前提と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く