オライリー・ジャパンのePUBフォーマットを支える制作システム
オライリー・ジャパンから先日発表されたプレスリリース「ePUBフォーマットによる電子書籍のラインナップを開始します」にあるとおり、弊社トップスタジオはオライリー・ジャパンとの共同事業として、ePUBフォーマットでの電子書籍の制作を開始しました。 トップスタジオではこのePUBフォーマット電子書籍の出版候補の選定、翻訳、編集、そしてePUB制作までに関わっています。本稿では、このePUBの制作プロセスを支えるシステムにフォーカスを当て、その仕組みについて紹介します。 フリーソフトウェア/オープンソースソフトウェアの集合体としてのシステム ePUBの作成にはいろいろな手法がありますが、制作を支えるシステムを構築する上で最も重視したのは、できる限り自動化し、手作業による調整を最小限にするということでした。そのため、このシステムでは原稿を常に最新マスターデータとしてそこから一方向にePUBを作成す
CouchDBとMongoDBの使い分け - モジログ
CouchDBとMongoDBをしばらく使ってみて、その使い分けのポイントがわかってきたような気がするので、ちょっと書いてみたい。 CouchDBとMongoDBは、広く「NoSQL」と総称されている非SQL型データベースのうち、「ドキュメントデータベース」と呼ばれるカテゴリを代表する２つだ。ドキュメントデータベースとは、かんたんにいうと、JSONデータ（＝ドキュメント）をそのままデータベースに保存できるというもので、従来のRDBのような「スキーマ」がない。複数のテーブルを結合（join）するという使い方をせず、一意キーの指定や比較的単純なクエリーでJSONデータを取り出す。 ここでは詳しい話には踏み込まず、２つのデータベースの違いを私の主観で、ごく大雑把にまとめてみる。 まず、それぞれの強みを私の印象で３つずつ書くと、こんな感じだ。 CouchDBの強み： １）優れた管理画面「Futon
グーグルのバグ予測アルゴリズムを実装したツール「bugspots」、オープンソースで公開
ソースコードのなかでバグが多いのは、より高頻度に、かつ最近になって集中的に直している部分。これが、グーグルで採用された「バグ予測アルゴリズム」であることを、先月の記事「グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している」で紹介しました。 そのバグ予測アルゴリズムを実装したツール「bugspots」がオープンソースとして公開されています。 gitのレポジトリを分析 bugspotsはRubyで記述されており、gitのレポジトリから履歴を読み込んで分析し、どのモジュールにバグが含まれている確率が高いかを示してくれます。 以下のようにインストールして実行（説明ページから引用）。 $> gem install bugspots $> git bugspots /path/to/repo $> git bugspots . # (in current git directory)
gitをテキトーに使って生産性を向上したユースケース - 西尾泰和のはてなダイアリー
バージョン管理とかgitとかが「おおげさでめんどくさいもの」だと思う人は多い。でも、それは生産性向上のチャンスを逃していると思う。特に業務として多人数で開発している人たちの「変更前にはまずトピックブランチ」というやり方が、それはそれでよい方法なんだけど、いかにもめんどくさそうで尻込みさせてしまうのではないか。 先日の日曜日に、テキトーなgitの使い方をして、とても役に立ったのでユースケースとして報告しておこう。ただし、若干特殊な環境なのでここでやった方法が直接そのまま皆さんの所で使えるとは限らないが。 まず環境の説明。プロジェクトは「次の日曜日、新感覚シューティングゲームを展示します」で紹介している、テーブル型ディスプレイで動くシューティングゲーム。メインは @tokoroten で、ソースコードをバリバリ変更している。土曜日にとりあえず動くところまでは行った。改善点は山積みだ。使える時間
ずっと無料で使えるPaaS型クラウドのまとめ。2011年版
PHPの実行環境をPaaS型クラウドとして提供している「PHP fog」はブログで、いままで6カ月だった無料サービスの利用期間を、永久に無料のままにすると発表しました。しかも3つのアプリケーションまで無料にするとのこと。 もちろん無料で使えるリソースの範囲はそれほど大きくありませんが、PHPアプリケーションを自由にデプロイできるため、例えばWordpressを入れて自由にブログを運営する、といったことができるはず。 実はPHP fogだけでなくPaaS型クラウドでは無料でずっと利用できるコースを設定しているサービスがいくつもあります。この機会にまとめてみました。 PHP fog まずはそのPHP fog。名前の通りPHPの実行環境をクラウド上で提供します。MySQLデータベースもあらかじめ用意されており、WordPress、Drupal、Sugar CRM、Joomlaといった有名どころの
fladdict » iPhoneアプリ審査での111の禁止項目（意訳）
ついに明らかになった、iPhoneアプリのリジェクト基準条項。 Engadetが公開したPDFをベースに、リアルタイムに更新中。 とりあえずリアルタイムに翻訳を作成中。 おもいっきり意訳なので、間違いの指摘や突っ込みはコメント欄かTwitterでお願いします。 ＜このリストは、2010年9月10日現在のものです。また意訳なので、気になる条文は原典をチェックすること。＞ 2. 機能 2.1: クラッシュするアプリはリジェクト。 2.2: バグのあるアプリはリジェクト。 2.3: 開発者の申請したものと違うアプリはリジェクト。 2.4: アプリの紹介文にない隠し機能を持つアプリはリジェクト。 2.5: 非公開のAPIを用いたアプリはリジェクト。 2.6: サンドボックス外のデータを読み書きするアプリはリジェクト 2.7: 実行コードを外部からダウンロードするアプリはリジェクト 2.8: 他の実
NSView と UIView
こんにちは、iOS/Mac アプリ開発担当の宮本です。 最近は、Sleipnir Mobile for iPhone と Sleipnir for Mac を開発しています。 Sleipnir for Mac の開発では、UIKit と AppKit の違いに苦戦しています。 出てくるクラス名も接頭辞が違うだけのものが多いので、ほとんど変わらないと思っていたのですが、ふたを開けてみると全くの別物でした。 今回は、その中でベースのビューとなるクラス NSView と UIView の違いについて紹介します。 これから Mac アプリを開発する方は参考にしてみてください。 ■ NSView には見た目に関するプロパティが全然ない NSView のクラスリファレンスを見るとビックリするぐらい UIView にあるプロパティがありません。最初、backgroundColor がないのには驚きました
少人数開発に役立つ5つのまとめ
if ( $blog == " Webエンジニアのためのライフハック " ) { print " 1-byte.jp "; } ホーム1-byte.jpとは 書いてるヒトは ここ2ヶ月間で気になる記事がたくさん上がっていました。 特に少人数チームにおける開発に関する記事です。 昨日、書き上げた”1年間の技術的負債を返すために読んだ3冊の本“にある通り、お知らせメールでは1年間の技術的負債を返そうとしています。 そのためには今まで曖昧だった箇所を浮き彫りにし、改善する必要があります。 また、せっかくなので新しいモノも取り入れたい。 こうしたことを考えながらの2ヶ月だったので、自然と目に止まった記事が3つありました。 スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ 複数人(2-3人)でウェブサービスを開発するコツ A successful Git branching m
前向きなヒューマンエラー対策をしよう。 - Sacrificed & Exploited
SIerが仕切っている開発現場でありがちなのが、何かミスを犯すと、そのミスを防止するようにすごく手間がかかるチェックが追加されて、開発効率とモチベーションが下がるというダメなパターン。 たとえば、「今年度は申請書(EXCELシート)書いて上司の判子もらわないと svn commit すらできない職場で仕事することになりました。 - SiroKuro Page」とか。 これはプロセスマネジメントでもなんでもない、管理ごっこだ。管理したつもりになって自己満足しているに過ぎない！！ プロセスをマネジメントしたければプロセスを削れ: DESIGN IT! w/LOVE では、次のように述べられている。 プロセスマネジメントにありがちな間違いのひとつに、ミスを減らそうとして、そのチェックをするプロセスを増やしてしまうということがある。 もちろん、すべての場合にそれが間違いというわけではない。 そのチ
jquery-mockjax 使えよ色々と捗るぞ - present
jQuery や Backbone.js で UI を開発していて面倒なのが、サーバー側の API を呼び出す部分の実装です。呼び出したい API が既に実装されていないと、細かいところまで作り込めません。 あと、上手く動かなかったときも面倒です。原因がクライアント側ならすぐ直せますが、サーバー側だった場合、サーバー側のコードを修正して、テストまでしないといけません。効率悪いですよね。 できれば、クライアント側の開発はクライアント側だけで完結したい。さらに欲を言えば、最終的にサーバー側の API を呼び出すように修正するとき、出来るだけ少ない修正で済むようにしたい。 API 呼び出しを抽象化してダミーの処理と差し替えたり、jQuery.ajax を上書きしたり、色々工夫して最後に行き着いたのが『jquery-mockjax』。 appendto/jquery-mockjax · GitHu
最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― ＠IT
2007/07/05 日本情報システム・ユーザー協会（JUAS）は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「（短
るびま
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
自分流 View Controllerの作り方 その1
その2はこちら 以前勉強会の際に発表した View Controller の作り方のメモをまとめてみました。あくまでメモなので中身はうまくまとまっていませんが、何かのご参考になればと思います。 通信が絡んでくると、たいていの人がやりがちな問題（実例） API通信のレスポンスを処理するコードがViewControllerの中に入っている API通信が3種類必要で、Aを実行したあとにBとCを実行しなければならないとか ABCのレスポンスJSONのパースまでViewControllerでやっている というかAPIの呼び出しの組み立てだとかURLの指定だとか自体がIBActionの中に入っていたりする API通信だけじゃなくてIn App Purchaseなどでも同様の事例が見られる それに対する対応策。そもそもなぜこのような問題が発生するのか？ Outletの生成・更新・レイアウトが分離されてい
SVN's svn:externals to GIT's Submodule for Rails Plugins - Panther Software
Why Git? Do you manage your Rails Plugins via svn:externals? Thinking of switching to Git but are concerned that Git lacks a direct equivalent of svn:externals? In this article I present a work-around or even IMHO a better solution than SVN's.Please note that I have posted a follow-up article, which presents a working solution using Git sub-projects to overcome the git-cat-file bad file error whe
CVS/Subversionを使ったバージョン管理（前編：バージョン管理の基礎） | OSDN Magazine
ソフトウェアを開発する際、ソースコードや各種リソースの管理に役立つのがバージョン管理システムだ。バージョン管理システムはソースコード管理システムなどとも呼ばれ、大規模な開発を行う際には必須と言っても過言ではない。また、大規模な開発だけでなく小規模な開発や個人による開発においても、ファイルの変更履歴の記録やバックアップといった用途に活用できる。 本特集ではバージョン管理システムの基本的な考え方や用語を解説するとともに、オープンソースソフトウェア/フリーソフトウェア開発において多く利用されているバージョン管理システムである、SubversionおよびCVSを使ったバージョン管理方法について説明する。前編となる本記事では、まずバージョン管理システムの基本的な考え方と、用語について解説する。 バージョン管理システムのメリット バージョン管理システムとは、その名のとおりプログラムのソースコードや各種
頭の中にプログラムを入れる
Paul Graham / 青木靖 訳 2007年8月 いいプログラマは、自分のコードに集中しているとき、それを頭の中に保持しておくことができる。数学者が取り組んでいる問題を頭の中に入れているのといっしょだ。数学者は学校で子供たちが習っているように、紙の上で問題の解いているわけではない。彼らは多くの部分を頭の中でやっているのだ。問題の領域をよく把握しようと努めることで、普通の人が記憶にある育った家の中を歩き回れるように、数学者は頭の中で問題空間を歩き回ることができる。最高の状態で行われるプログラミングもそうだ。プログラムの全体を頭の中に入れたなら、それを思い通りに操れるようになる。 これはプロジェクトのはじめにおいては特に価値がある。それはプログラムを作り始めるときに最も重要なことが、やっていることを変えられるということだからだ。単に問題の解き方を変えるという ことではなく、解いている問題
Capistrano 実践Tips集
ChefとCapistranoの境界線 (Chef Casual Talks Vol.1) #eytokyo #opschef_jaMasahiro NAKAYAMA
信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はRDBやフレームワークを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止」と「固定長DB」だ。 ありえない。 とはいえ、正直に言えば「またか、、、」という感想でもある。 RDBを知らないレガシーな人たちが設計したDBではよくありがちな設計だからだ。 と僕は早々にこの文化と戦って、絶対に覆してやろうと考えてた。 過去の経験上それはたやすいハズだった。 しかし、この文化と戦うこと3ヶ月間。 屈した。初めて屈した。いや、屈したというよりは理解した。 大規模コンシューマ向けサービスのRDBという
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rubyistよ、irbを捨ててPryを使おう | Webシステム開発／教育ソリューションのタイムインターメディア
http://dl.dropbox.com/u/7748830/pixiv.plist