我々は様々なサービスやデバイスを通じて、デジタルリソースに対してコメントなどの付加的な情報を日々付与しています。ウェブサイトにはソーシャルブックマークサービスを経由してコメントが大量につけられていますし、Flickr、Youtube、ニコニコ動画などのWebサービスが抱えるリソースに対して大量のコメントが付与されています。Twiiter、FacebookなどのSNSはリソースに対する付加的な情報の付与に特化したサービスといってもよいかもしれません。昨今の電子書籍ビューワーでは、ハイライトやコメントの付与する機能は当然のように備えていますし、電子書籍プラットフォームでは「ソーシャルリーリング」という名前のアノテーションサービスが提供されています。 どのサービスもあるリソースに対する付加的な情報を他のユーザーや他のデバイスと共有することを目的としています。しかし、残念ながら共有できるのは、プラ
W3C and IDPF: Better Together? Dave Cramer May, 18th, 2016 この文書は W3C and IDPF: Better Together? https://medium.com/@dauwhe/w3c-and-idpf-better-together-c92988674444#.f01vyjaqo の日本語訳です。 Many people have offered their perspectives on the potential merger between W3C and IDPF that was announced last week. Peter Brantley is optimistic, hoping that a meeting of minds between books and the web can real
電書ラボEPUB制作仕様のβ版です。 https://docs.google.com/spreadsheets/d/1pFgzkJC6l6hF-BVxBGsQUh61yksVRSaNDdJNcWwGNmI/pubhtml ●更新履歴 2016.07.28 β0.99 2014.11.26 β0.9 2014.07.10 β0.8 2014.05.08 β0.6 ●主な対象 電書ラボEPUB制作仕様は、主に電子書籍書店で販売するためのEPUBファイル制作の仕様としています。 ですからこの電書ラボEPUB制作仕様を利用してもらいたい、主な対象は出版社です。 なかでも、独自にEPUB仕様を作っていない出版社に利用してほしいと考えて作りました。 また、制作会社にも、出版社と仕様を相談する際のたたき台として利用してもらえたらと思います。 従来、出版社が印刷所や組版所に原稿と一緒に渡す組版仕様書の電子
「電書協 EPUB 3 制作ガイド ver.1.1.3」追加サンプルファイルを公開します 2015.11.12 電書協加盟社のための一般書のEPUB 3を制作する際のガイド「電書協EPUB 3制作ガイド ver.1.1.3」に対応した、新しい追加サンプルファイルを公開します。 このサンプルファイルは、「電書協EPUB 3制作ガイド ver.1.1.3」に沿って作られたEPUB 3の電子書籍が、実際のRS（リーダーシステム）でどのように見えるかを確認するためのものです。 したがって、このファイルは、RSでの表示の正解を定めるものではありません。あくまでも、「電書協EPUB 3制作ガイド ver1.1.3」と、その付録であるCSSセットを利用して指定したときの表示を確認するためのサンプル集です。 表示方法の共有や、RSの表示に関して話し合う際の参考資料としてご活用ください。 ■表示確認用サンプ
EPUBフォーマットへの移行が進む日本の電子書籍市場において、電書協の制作ガイドは指針の一つとしての役割を果たしてきましたが、現状ではまだ、制作した一つのEPUBファイルをすべての電子書籍ストアに納品出来る状況にはなっていません。 そこで、KADOKAWAグループの作品を電子書籍（EPUB形式）として、より柔軟かつ円滑に流通させることを目的に、電書協の制作ガイドをベースに「KADOKAWA-EPUB 制作仕様」を策定致しました。 日本の電子書籍ストア各社が提供するビューワーでの版面再現性を考慮した制作仕様となっておりますので、KADOKAWAグループ作品のみならず広くその内容を日本の出版社や制作会社の皆様にご活用頂きたく、ここに公開させて頂きます。 電書協EPUB3制作ガイドCSSの流用による可搬性の確保（Portability） グローバル／ローカル分離仕様による汎用性の強化（Flexi
みなさん，Docker使ってますか？ 開発環境に導入する話はよく聞きますが，本番Dockerで運用してますか？ 本番をDockerにする上で障壁になりそうなホットデプロイ． 普段，コンテナではなくインスタンス上で直接サービスを動かしている限り，そこまで苦労はしていないんじゃないだろうか． たとえば，Railsであればunicornなどは，graceful restartに対応している． そのため，デプロイの際にサービスを止めずにデプロイすることができるのは，当たり前のことに思える． しかし，Dockerとなると，ポートという障壁が出てきて，一筋縄ではいかない． ECSのような楽な解決方法がある一方で，Docker swarmを使うようなシーンでは，やはり一筋縄ではいかないのではないだろうか． お題 本番にDockerを導入するにあたり，以下のような環境を前提として試していた． 中に入れるの
SREチームの@cubicdaiyaです。今回はDockerとMakeを利用したメルカリの自作RPMパッケージのビルド環境について紹介します。 メルカリの自作RPMパッケージ事情とVagrant、そしてDocker メルカリの開発およびプロダクション環境では現在CentOS6と7を利用しており、随時CentOS7へ移行中です。そのため、自作RPMパッケージをビルドする際はCentOS6と7向けにそれぞれビルドしています。ビルドしたパッケージはyumリポジトリサーバにアップロードした後、必要に応じてyumでインストール、Ansibleのplaybook化を行います。 RPMパッケージの作成はSREチームのメンバーが行っており、各自のローカルマシン上において make {パッケージ名} を実行するだけでCentOS6と7向けのRPMパッケージをビルドできる環境をDockerで構築しています。
fluentdのrequire_ack_response設定は、やっぱり必須設定だと再認識したときの検証メモAWSFluentd 1.検証背景 参考記事 Fluentd v0.12のAt-least-once Semanticsを試す fluentdでログが欠損する可能性を考える などで、fluentd v0.12を使ったときに、「require_ack_responseを必ず設定しておくように」というノウハウは、大分浸透するようになったと思われる。 ただ、fluentdを運用する中で、require_ack_responseの設定漏れに気付かず、受信側のfluentdをreloadしてしまうケースも考えられる。 ということで、実際の運用下でこの設定がどれぐらいの効果を発揮するのかを検証してみた。 2.検証環境 2-1.構成図 図にするほどでもないが、fluentdの送信側と受信側のEC2
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
