長時間労働、マルチタスク、先延ばし...巷にはびこる生産性の誤解を科学で解く | ライフハッカー・ジャパン
「デスクの乱れは心の乱れ」「勤務時間を増やせば、もう少し生産的になれる」......。そんな、生産性にまつわる話を耳にしたことはありませんか？ もしかしたらあなたは、意味もわからぬままそれを実践して、時間を無駄にしていることもあるかもしれません。そこで、生産性に関する一般的な認識を取り上げ、それぞれに科学的な裏付けがあるのかを検証したいと思います。ライフハッカーでは、以前にも生産性の神話を取り上げました。数々の研究結果を用いて、それらの神話をひとつひとつつぶしていったのです。今回も同じアプローチを使って、それぞれの神話を反証する科学を紹介します。よりスマートに働くためのヒントも併記しておりますので、ご参考にしていただければ。 神話1：長時間働けばたくさんの仕事をこなせる この神話の根底には、「勤務時間を長くするほど、より多くのことができる」というロジックがあります。学生時代の徹夜や会社員の
CoffeeScriptを使う理由 - Qiita
function Person() { this.name = "takashi"; this.age = 20; }; Person.prototype.echo = function () { return "Hello " + this.name + " !!"; }; コンストラクタ、メソッドを書いただけで、コード量が増えてきましたね。 毎回クラス名とprototypeと書く必要があります。 めげてきましたか？ 私はめげてます。 次は継承してみましょう。 function inherits(ctor, superCtor) { ctor.super = superCtor; ctor.prototype = Object.create(superCtor.prototype, { constructor: { value: ctor, enumerable: false, writ
/usr/local とは何なのか - 破棄されたブログ
ご用心: この記事を鵜呑みにせず、末尾に記載された一次ソースを確認してください。 ソースからソフトウェアをビルドしてインストールするときに使う /usr/local ディレクトリだけど、/opt ディレクトリとの住み分けとか、 そもそも標準はどうなっているのかとか、まともに知らんかったので Filesystem Hierarchy Standard を確認してみた。 /usr/local は何をすべきところなのか？ 他のホストと共有されない 既存のシステムの破壊防止 FHS 準拠のソフトウェアをインストールする /usr/local ディレクトリ下自体が FHS 準拠になる /usr/local ディレクトリは、システム管理者がソフトウェアをローカルにインストールするために用いる。 /usr/local ディレクトリとして隔離されるため、同名のファイル名で既存のファイルを上書きするなどして
CDから取り込んだ曲もiCloudへ--アップル、日本でも「iTunes Match」開始
アップルは5月2日、音楽クラウドサービス「iTunes Match」を日本でもスタートした。米国では2011年からスタートしている。 iTunes Matchを使うと、iTunes Storeで購入した楽曲はもちろん、CDから読み込んだ楽曲やiTunes Store以外で購入した楽曲も含めて、PC上の音楽コレクション全体をiCloudに保存できる。iPhoneやiPad、Windows PCやMac、Apple TVなどからiCloudにアクセスすればいつでもどこでも、自分の持っている音楽コレクションすべてを楽しめるようになる。 最大の特長は、iTunes Storeで購入していない楽曲にも対応していることだ。この前買ったCDの曲がPCにはあるが、iPhoneに入っていない、という時でもオンラインでいつでもどこでもストリーミング再生できる。もちろんiCloudからiPhoneに保存して、オ
いまどきの技術本執筆環境 – 「Chef実践入門」
全国1000万人のInfrastructure as Code職人とImmutable Infrastructure芸人のみなさん、こんにちわ！ すでに各所で言及されています通り、「Chef実践入門 ~コードによるインフラ構築の自動化 」が技術評論社から出版されます。 Chefを解説する書籍としては澤登さん、樋口さんによるChef活用ガイドに続く2冊めの書籍となり併せて読めばもはやChef入門を通りこしてChefマニアになれるのではないかという陣容です。 (2冊の書籍が異なるキャラクターで被る部分があまりないのは高度な情報伝達の賜物です。) ネット上やイベントで走り続けている情報を今ひとつ追い切れない方や使い始めた方にとって便利な一冊となるように、なるべく漏れのない構成を心がけています。 自分の担当した「第8章 Chefをより活用するための注意点」と巻末のチートシートについては公式ドキュメ
GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー
少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。 最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分たちで環境を構築しなくてもクラウドに任せることができる。KAIZEN では CircleCI を積極的に使っている。 これらの CI as a Service は基本的に GitHub と連携するこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
