45歳のアメリカ人のソフトウェア開発者クリス・ダンシーは、様々なセンサー、デバイス、アプリなどを使い、自らの活動と自己の置かれた環境のリアルタイムのデータを集めている。 700ものシステムのモニターが彼の全ての挙動をモニターすることで、「人類で一番数値化された男」は、自分のことを以前よりよく知るようになったという。 「この4年間は全てのデバイスあらゆる技術を駆使して生活してきた。そしてそれらをシングル・オンライン・プラットフォームに流し込んだ。そこで自分の生命活動のすべてのことがわかるようになってきた。私はこれを”インナー・ネット”と名付けた。」クリスはそう語る。 この画像を大きなサイズで見る クリスは面白がって各種モニターに繋がれていただけではなく、データをきちんと役立てた。自分の挙動と食べる習慣を常にモニターした結果、彼は体重を45kgも落とすことができた。「今はもう何を飲み何を食べれ

そもそも何故16GBを選ぶのか 最初に、16GBのiPadを選ぶ理由をお話しします。 単純な話ですが、安いからに他なりません。容量が大きくなれば、それだけ値段が高くなります。16GBと32GBだと、1万円もの差が開くんです。 「容量が倍になって、差額が1万円だけ」というのを、安いと感じるか高いと感じるかは人それぞれです。ですが、1万円というのは決して安くありません。その分を節約して、他のアクセサリーに回した方が、私にとっては有意義なのです。 それでは本題へ。私のiPadの使用状況、つまりデータの専有状況と運用方法についてご紹介します。 データ容量が大きくなる要因アプリ データ容量が大きくなるのには原因があります。つまり、容量が大きくなりがちなデータというのがあるのです。 例えば一般的に、以下のようなデータは容量が大きく、iPadの容量を圧迫する原因になります。 ・カメラロール（写真・動画）

オブジェクト指向という言葉には オブジェクト指向分析(OOA) オブジェクト指向設計(OOD) オブジェクト指向プログラミング(OOP) の三つの意味があります。 オブジェクト指向初心者泣かせです。 ここではオブジェクト指向設計を説明します。 ソフトウェアの設計 ソフトウェアの設計には二つの側面があります。 作成するソフトウェアの共通部分を探し出しモジュール化する 作成するソフトウェアが将来変更される部分を抽象化し変更しやすくする 一つ目のモジュール化は構造化設計からある手法です。 オブジェクト指向設計で特に取り上げる点はありません。 ここでは二つ目の将来の変更のために抽象化することに重点を当てます。 オブジェクト指向設計 オブジェクト指向設計とは多態を実装する部分を決めることです。 多態とはオブジェクト指向言語を活用した次のものです。 変更可能な点に抽象クラス*1 （オブジェクト指向言語

仕事で Rails を使ったサービスを担当し始めて約1ヶ月半、Ruby と Rails にもだいぶ慣れてきたので、ここまでどうやって勉強してきたか書いておこうと思います。いや、まだ初心者もいいところなのですが、そのうち忘れてしまって今しか書けなそうなので、書いておきます。 とはいえ、こういう情報は時間の経過と共に意味のないものになってしまいがちなので、なるべく時間に左右されない本質的なことを織り交ぜながら書いていきたいと思います。 irb(main):002:0> Date.new(2014,4,4) - Date.new(2014,2,19) => (44/1) 当時の知識 パーフェクト Ruby を途中まで読んだ Ruby on Rails Tutorial の Chapter 4 Rails-flavored Ruby をやっていた という程度。 パーフェクトRuby (PERFEC

※価格やクーポンは掲載時のものです。最新情報はリンク先で確認してくださいm(__)m ツイッターやってます。こちらでも特価情報を更新します。 Follow @joujaku_banchou とくダネ！で放送されたみたいですね この番組、bモバイルの株価のために組まれたような気がする それと、テレビに出てくる地方の方はどうも、訛りがすくない 実はオイラ、広島出身なだけど、どう見てもとくダネ！に出てくる人は広島県民では無い 父と母はバリバリの広島弁 オイラも家族と話す時は広島弁になるけんの が、テレビの人。。。 標準語？ 。。。。 思えばオイラの乞食ルーツは、ケータイ番長や古事記に生きるのPiroさんだったりする おふた方のブログを見て育ちました テレビ見た後、先月末キタムラでいっそいで契約したSO04E回線5回線を持って、ソフトバンク平塚へ コンテンツ入れてもらいCBもらう iPhone5s

ソフトウェア開発の品質・効率向上に欠かせないレビュー。しかし、やり方を間違えているために、かえって逆効果になっているケースが多い。本連載ではソフトウェアレビュー研究の第一人者、森崎修司氏が豊富な現場経験と研究成果を基にレビュー成功のポイントを分かりやすくリアルに解き明かす。 なぜレビューがうまくいかないのか？ ソフトウェア開発の品質・効率向上が求められている今、ソフトウェアレビュー（以下、レビュー）の重要性はますます高まっています。商用開発では「要件定義」「設計書」「ソースコード」「テスト計画」「運用手順書」などを対象としたレビューが行われていますし、オープンソースソフトウェアのプロジェクトでも、ソースコードリポジトリへのチェックインの前にソースコードレビューを推奨したり、義務付けたりしています。 しかし、レビューは自由度の高い活動です。レビュー会議では本質的な欠陥や問題を指摘しても、欠陥

Webページの制作に携わったことがあるならCSSも扱ったことがあるだろう。当初は小さかったCSSファイルも、デザインの変更や調整を続けるうちに、どんどん大きくなっていき、簡単には全体を見渡すことができなくなる。既存のデザインが崩れたりパラメータ間の調整を取るため、既存のCSSには手を加えずに新しいスタイルを追加していくことになるため、ファイルはどんどん大きくなっていく。 こうした状況はCSSファイルのメンテナンスという観点からはあまり好ましいものとはいえない。編集を繰り返していくうちに、すでに使われなくなっているスタイルもあるだろう。そうしたスタイルはできれば削除した方が、ファイルの中身の見通しがよくなる。そんな場合に活用できるツールがThe David Walsh Blogの記事「uncss: Find Unused CSS」において紹介された。 紹介されているツールは「uncss」とい