タグ

lifeHackに関するfacetのブックマーク (6)

  • 件名だけで用件を終わらせる「EOM」とは : ライフハッカー[日本版], 仕事も生活も上手くこなすライフハック情報満載のブログ・メディア

    昨日、ブラッドさんが書いたメールはとてもシンプルなものでした。それは件名に「ブラッドは午前9時半にいます。よろしく。EOM」というもの。すぐに「EOMってどういう意味?」と返事が返ってきたそうで、それに対する答えは「End of message(メッセージの終わり)という意味さ。これならわざわざメールを開く必要も、返信する必要もなくなる。今回はメールを開いて、返信をしてもらったから二度手間になったね」というもの。同僚たちには「面白い!」と、この話を冗談だと思ってオフィスのみんなに転送したそうですが、ブラッドさんは、大真面目。「一度EOMのテクニックを覚えたら、メールにかける時間も手間も減ります。そのうえ、確実に、自分の伝えたいことが伝わり、時間も節約できますよ」とのこと。詳しい理由は次の8つ。 EOMは、メール受信者の時間節約になります。 件名のところだけに用件を入れ、EOMで終わりにする

    件名だけで用件を終わらせる「EOM」とは : ライフハッカー[日本版], 仕事も生活も上手くこなすライフハック情報満載のブログ・メディア
    facet
    facet 2008/10/14
    :via >< ((←amachangではない)) EOM
  • 本のサイズ比較をAmazon APIで - Liner Note

    Amazon APIを使って書籍のサイズ比較をしてみる要約:Amazon APIを使って書籍のサイズ比較をしてみる3分LifeHacking:「通販でを買ったら予想より大きかった」を解決する - ITmedia Biz.ID の大きさを比較するWindowsのソフトウェアがあるよという話。 amazon api使ってwebで実装すると面白そう。というコメントもあるし、「それCSSでできるよ!」と思ったので作ろうと思ったんだけど、どこかにしまった記憶を引っ張り出してみれば、CSSで使える絶対単位というのはどの環境でも同じサイズで表示されるわけではない、つまり絶対単位じゃないんですよね。 サーバサイド言語あるいはJavascriptか何かでユーザの出力解像度(DPI)と表示解像度(1024×768とか)と画面サイズ(cm単位)が取れればなんとかなるんでしょうが、そんなことができるというのは

    facet
    facet 2008/02/12
    5.5cm。重さ[*]
  • 第3回 日常的な学習について | gihyo.jp

    日常的な学習の方法 日常的な学習はプログラマにとって不可欠な活動です。ソフトウェアの世界には次々と新しい流行が登場しますし、基礎的な事柄だけでもマスターしておきたいことは山ほどあります。今回は日常的な学習の方法について、私のパターンに照らし合わせて考察してみたいと思います。 ブログ ブログは学習というよりは情報収集に適したメディアです。ブログの記事は、だいたい小粒で、1つの記事で内容が完結しています。ほかの人がどんなことに興味を持っているかわかるのも、流行を知るといった点でプラスです。とはいうものの、ブログで得られる情報の大半は、断片的な雑多なノウハウであるため、長期的に役立つような知識のかたまりはほとんど残りません。 雑誌 プログラムを書いている最中に「今すぐ知りたい」といった類いのピンポイントの情報(たとえば、Perlで文字コードを変換するにはどうすればいいんだっけ、とか)は、Webを

    第3回 日常的な学習について | gihyo.jp
    facet
    facet 2007/09/17
    続けるコツ:「1回で理解できなくてもOK」「だらだらやってもOK」「間隔を空けても気にしない」「「今さら」でも気にしない」(Better late than never)「刺激を受けすぎない」// 「猛スピードで流行に振り回されるオレ」www
  • PC

    パソコンの断・捨・離 いいことずくめのアプリ断捨離、不要なサブスクや悪意あるアプリも排除 2024.03.15

    PC
    facet
    facet 2007/09/11
    「予定に関連する情報をとにかくその説明欄にコピーアンドペーストする。そうして、予定にひも付いた情報を一元管理してしまう」という方法。
  • 2004-11-29

    今日はペアプロしているときから体調がおかしいと感じていたけれど、家に帰ったら体にジンマシンが出てる。やはり... また「アジャイルソフトウェア開発の奥義」からです。 だが、ドキュメントは簡潔で、要を得たものでなければならない。この場合「簡潔」というのは、せいぜい12〜24ページということで、「要を得た」とは、システム設計については包括的な論理的説明のみにとどめ、システムの構造についてはトップレベルについてのみの記述する(sic)、ということだ。 12〜24ページというのが妙にリアルです。 「Martinのドキュメントに関する第一法則」を紹介しよう。 重要で差し迫った必要のあるドキュメント以外は作成しない。 読書会では「重要で差し迫った必要」とはなんだろうという話になりました。私たちにとってはリリースがそれです。書くのはエンドユーザ向けのドキュメント等です。 『アジャイルソフトウェア開発の奥

    2004-11-29
    facet
    facet 2006/04/12
    そうか!
  • Happiness Leads to Success - LifeHack

    facet
    facet 2006/01/05
    ふむ。//Happiness Is A Warm Gun~←関係ないが
  • 1