タグ

2009年5月11日のブックマーク (32件)

  • みうらじゅん氏が結婚!bird第2子妊娠 - 芸能 - SANSPO.COM

    女性R&B歌手、bird(33)が人気イラストレーター、みうらじゅん氏(51)と入籍していたことが7日、分かった。birdの所属事務所がサンケイスポーツの取材に「時期は把握していないが、入籍していることは事実」と明かした。 また、第2子を妊娠中で現在妊娠6カ月であることも判明。同事務所は「体調を見ながら産後も仕事を続けていく予定です」と話している。 関係者によると、2人は数年前に仕事を通じて知り合い、同じ京都出身ということもあって意気投合。親密交際に発展した。05年11月にはbirdが妊娠したことを自身のHPで電撃発表し、06年1月に長男を出産。その際に「相手の男性や結婚の有無は控えたい」とつづっていたが、同年11月に週刊誌でみうら氏との不倫の末の出産だったことが報じられた。 07年春にはみうら氏が前離婚。だが2人は籍を入れずにパートナーという形でこれまで共同生活を送っており、関係者は

  • PHPとjQueryで動く軽快で使いやすいTODOアプリ「myTinyTodo」:phpspot開発日誌

    myTinyTodo homepage PHPとjQueryで動く軽快で使いやすいTODOアプリ「myTinyTodo」。 次のようなUIで、「Add」ボタンを押せばajaxで画面遷移なしにTODOを追加できます。 ちょっとした自分用のTODOリストを構築したい場合にサクッと設置できて便利そうです。 チェックボックスにチェックを入れると、線が引かれ、終わったことが分かりやすくなっています。 更に、上図で「はやくおわらせる」と書いてあるような、TODOに対するノート機能なんかもついています。 関連エントリ 1ファイルのみでDB不要のTODO管理ツール「Todo.php」 RememberTheMilkと同期するiPhoneアプリ「Appigo Todo」 PHP+Ajaxな快速TODOツール ターミナルでTODO管理する:todo.sh タイマーで時間を計れるTODOツール『SlimTime

  • IDEA * IDEA

    ドットインストール代表のライフハックブログ

    IDEA * IDEA
  • きれいなソースコードを書くために必要な、たったひとつの単純な事 - よくわかりません

    「構造のきれいなプログラムを書けるようになるためにはどうすればいいのか?」という質問を受けたので、「はて?どうしているだろうか?」と考えてみました。あ、形式知にきちんとなっているようなテクニックみたいなもんじゃなくて、モノローグなので、あまり凝ったものは期待しないように。 http://blog.shibu.jp/article/28983162.html 自分なりにもっと凝縮版を。渋川さんが言っている事全体もその通りとは思うけど*1、もっと簡単で、しかも射程が広い、と自分が思っている事。 渋川さんはちょろっと触れてるだけだけど、自分はこれが最も基的で汎用的、かつ、ソースをきれいにする原動力となる上にバグをも減らしてコードの汎用性まであげる、コーディングのエンジンみたいなものと思ってる。それは、 「すべてに正しい名前を付けて、そして、正しい名前であることを維持する」という鉄の意志 クラス

    きれいなソースコードを書くために必要な、たったひとつの単純な事 - よくわかりません
  • RedmineとTracの機能比較 - プログラマの思索

    RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱ExcelRedmineアジャイル開発を楽々管理 - @IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。

    RedmineとTracの機能比較 - プログラマの思索
  • [2ch] モテナイ女性のための雑誌「mojo」が凄い!

    2ちゃんねる「もてない女(仮)」こと、通称「喪女板」。彼氏・夫がいない事をブツブツ言うようなジメジメした雰囲気はなく、明るく・楽しく・悲しく・哀しく、モテナイことについて前向きに話し合っている板だ。 そんな喪女板に ・喪女雑誌「mojo」第2号 というスレッドを発見。モテナイ女性が、モテナイ女性のために作られた雑誌案だ。 以下ちょっと内容を見てみると… 784 :彼氏いない歴774年:2008/05/08(木) 21:42:36 id:i3o3CX/v 「mojo」6月号 ★梅雨だ!だ!みんなでを癒し合おう号 ☆みんな同じだよ、大丈夫!喪女の日常大特集 ・毒喪の私服公開(後悔)スペシャル! ほとんどしまむらかUNIQLO ・これぞ喪女! 厳選・喪女と思われるブロガーの秀逸ブログ紹介 ・毒喪座談会 〜彼氏ってまじでみんなどうやって作ってるんだ〜 ・どうせモテないし犬やと戯れようぜ! 安

  • インデントを愛せ - 書評 - みんなのPython - ひがやすを技術ブログ

    著者より献御礼。 みんなのPython 改訂版 作者: 柴田淳出版社/メーカー: ソフトバンククリエイティブ発売日: 2009/04/11メディア: 単行購入: 23人 クリック: 572回この商品を含むブログ (84件) を見る はっきりいって、Pythonを学ぶというより、プログラミングを学ぶとしても読んで欲しい。プログラミングを学ぶために必要な項目が、きちんと整理されている。もちろん、Pythonの真髄であるインデントの書き方についてもしっかり学ぶことができる。 目次 第01章 プログラミング言語Python 第02章 変数と組み込み型 第03章 条件分岐とループ 第04章 関数 第05章 組み込み型を使いこなす 第06章 ファイル処理 第07章 華麗で短いプログラミング 第08章 クラスとオブジェクト指向開発 第09章 クラスの継承と高度なオブジェクト指向機能 第10章 例

    インデントを愛せ - 書評 - みんなのPython - ひがやすを技術ブログ
  • “確実な記録”こそが、品質・コストに貢献する

    “形だけ”になりがちなソフトウェアレビュー 近年、ソフトウェアレビューに対する認知はますます向上しつつあります。例えば商用開発なら、「要件定義」「設計書」「ソースコード」「テスト計画」「運用手順書」などを対象としたレビューが実施されていますし、オープンソースソフトウェアのプロジェクトなら、ソースコードリポジトリへのチェックインの前にソースコードレビューを推奨したり、義務付けたりしています。 その背景として挙げられるのは、ビジネスや社会におけるITの重要性が高まっていることでしょう。われわれの日常にこれだけITが浸透しているいま、ソフトウェアの品質は、システムの運用に大きな影響を及ぼします。その品質が低下すれば、ビジネスなら機会損失や収益悪化、社会的信用の失墜につながりますし、社会インフラなら公共交通機関などのサービスがストップすることも起こり得ます。ソフトウェアレビューの認知度が向上してい

    “確実な記録”こそが、品質・コストに貢献する
    kanetann
    kanetann 2009/05/11
  • fastladder · GitHub

    Dismiss Grow your team on GitHub GitHub is home to over 50 million developers working together. Join them to grow your own development teams, manage permissions, and collaborate on projects. Sign up

    fastladder · GitHub
  • oDesk

    Find the right freelancer or agency for your project on the world’s largest hiring platform connecting savvy businesses and professional freelancers.

    oDesk
  • TechCrunch | Startup and Technology News

    William A. Anders, the astronaut behind perhaps the single most iconic photo of our planet, has died at the age of 90. On Friday morning, Anders was piloting a small…

    TechCrunch | Startup and Technology News
  • ねぎ姉さん

    ねぎ姉さん negineesan Copyright 2017 Doom Kobayashi mi wile pakala e ijo ali. [negineesan] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 9x 95 96 97 98 99 100 101 102 103 104 105

  • http://twittermeigen.tumblr.com/post/66728981/tily

  • http://twittermeigen.tumblr.com/post/66940292/jikishi

  • http://twittermeigen.tumblr.com/post/67644257/harsch

  • http://twittermeigen.tumblr.com/post/67957072/bulkneets

  • http://twittermeigen.tumblr.com/post/84364202/suvene

  • 第24回XPJUGユーザ会『アジャイルな見積りと計画づくり』開催のお知らせ - 角谷HTML化計画(2009-03-23)

    ■1 第24回XPJUGユーザ会『アジャイルな見積りと計画づくり』開催のお知らせ めでたく6刷が決定した『アジャイルプラクティス』の出版記念だった昨年の第20回XPJUGユーザ会以来の、id:papanda0806プロデュース(だと思う)で私がしゃべるXPJUGユーザ会が開催されます。 今回のネタは、いまだに重版のかからない『アジャイルな見積りと計画づくり』(まだ初刷買えます)について。 一緒に翻訳した安井さんが「陽の巻」、私が「陰の巻」です。安井さんが「図」の話をするので、私は「地」の話をするつもり。Ustream.tvの予定はありません。録画はしてくれるみたい。今週の金曜日、3/27の19:00から浜松町というか竹芝のTIS社でお会いしましょう。 http://tinyurl.com/xpjug24th ↑のリダイレクト先のGoogle SpreadSheet 第24回XPユーザ会 

  • すぐ、その場で修正できる確認画面 (ユーザビリティ実践メモ)

    ECサイトの購入フォームや、会員サービスの入会申し込みフォームでは、ユーザが名前や住所など多くの項目を入力しなければなりません。

  • FAQの隠れた役割 (ユーザビリティ実践メモ)

    ユーザから頻繁に問い合わせを受ける質問に対応するため、多くのサイトでは、「Q&A」や「よくあるご質問」といったFAQ(Frequently Asked Questions)コンテンツを用意しています。 今回はFAQを効果的に活用する見せ方について考えていきます。 FAQはユーザが持つ疑問の解決につながりますが、ユーザはサイトを利用するなかで、FAQをそれほど意識して探しにはいかないことに注意が必要です。 では、FAQはページのどこに配置するのがよいでしょうか。 ヘッダーエリアか、左右のナビゲーションにFAQのリンクが配置されているパターンを思い浮かべる方が多いでしょう。(図1) ユーザは、コンテンツエリアを中心に見ていくため、意識的に探さないとFAQがあることに気付きません。 サイトの共通要素として、問い合わせなどと同様、どのページにも同じ位置に配置すべきですが、それに加えて、コンテンツを

  • ユーザがつい読んでしまう表現方法とは? (ユーザビリティ実践メモ)

    これまで実践メモでは、ウェブライティングの基礎など、ユーザにとって読みやすい文章表現についていくつか考察してきました。 ウェブライティングの記事一覧 今回は、訴求ポイントをFAQ形式で表現することで、ユーザに内容まで読まれやすくする方法をご紹介します。 このサービスでは、ただ子どもを預かるだけでなく、子どもの発達を考えたサービスを行っています。しかし、こうしたこだわりの説明文をコンパクトにすることは難しく、見出しでも曖昧な表現になってしまいがちです。 このページの場合、改善前はユーザは見出し以下の文章まで読まず、独自のサービスを訴求できませんでした。 そこで、特長の説明をQA形式にしたところ、ユーザは文章部分まで読むようになり、他社と違うサービス内容を理解するようになりました。 こういった、QA形式の文章がよく読まれるという行動は、弊社のユーザ行動観察調査の中で多く確認されています。 この

  • フォームにおける「進む」ボタンと「戻る」ボタン。どのように配置する? (ユーザビリティ実践メモ)

    これまで実践メモではフォームを設計する際に注意すべき点をいくつかご紹介してきました。 フォーム設計についての記事一覧 今回はフォームによく出現する「進む(次へ)ボタン」と「戻るボタン」を配置する際に気をつける点を纏めました。 ウェブサイトにおいては「進む(次へ)」ボタンなど前進するものを右側に、「戻る」ボタンなど後退するものを左側に置くことが一般的になっています。 ユーザは多くのサイトを利用している中でこの配置に慣れていますので、配置が逆になっていると次へ進むつもりがうっかり「戻るボタン」を押してしまうことになりかねません。最悪の場合、これまで入力したものがクリアされてしまい、入力を一からやり直すはめになります。 そういう訳ですから、フォームのボタンを配置する際は「進む(次へ)」ボタンを右側に、 「戻る」ボタンを左側へと一般的な慣習に従う方がユーザに対して親切と言えるでしょう。 2.「

  • 左ナビと右ナビはどっちが良い? (ユーザビリティ実践メモ)

    ウェブサイトを設計する際に、ナビゲーションメニューを左右のどちらに設置するかで悩んだ経験はありませんか? 弊社でウェブサイトを設計する際には、「コンテンツ」と「ナビゲーションによる誘導」のいずれが大事かによって設置位置を判断しています。 ■ナビゲーションによる誘導が重要な場合はナビゲーションを左に 例えばアマゾンなどの巨大ECサイトではナビゲーションによる誘導が重要であるため、ナビゲーションが画面から切れてしまうことのないよう、左側にナビゲーション設置しています。 上記のほかの考え方として、ユーザがそのサイトと同時に利用する競合サイトと同じ位置にナビゲーションを設置する、という考え方もあります(ユーザの慣れや先入観に配慮する)。 ナビゲーション設置時には「コンテンツ」と「誘導」のいずれが大事なのかによって設置位置を調整するようにしましょう。

  • 「ちら見せ」は逆効果? (ユーザビリティ実践メモ)

    コンテンツへの興味を喚起するためにその内容を一部露出させる、いわゆる「ちら見せ」施策を実施しているサイトも多いかと思います。今回は、その「ちら見せ」施策が逆効果となるケースについて考えます。 ところが、弊社でそのサイトのユーザ行動観察調査を行うと、ユーザはクチコミの最初の数行を数件読んだだけで満足し、会員登録することなくサイトを離脱する、という行動が頻発しました。 これでは逆効果です。 一般的に、クチコミや体験談を調べているユーザは、対象物・対象分野についての知識が少なく(時には不安も感じており)、「概要を把握したい」と思っています。そのため、クチコミを数件見渡して雰囲気を掴むとそれで満足してしまうのです。 このように「ちら見せ」が機能しづらい場合、どのようにすれば良いでしょうか。 有効な方法の一つは、ユーザに会員登録のメリットを体験してもらうことです。例えば、仮登録のような中間ステップを

  • 『どうして仕事を断らないのだろうか』

    悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 仕事を頼まれたら断れない人がいる。傍から見ていて出来そうもないと思うような仕事でも引き受けてしまう。つい横から口を挟みたくなるが、人が「出来る」と言っているのに、他人が「出来ないだろう」などと言うのも失礼だと思い、黙っている。しかし、案の定、期限が来ても仕事は終わっていない。 もちろん、何らかの理由で仕事が遅れるようなことはよくある。そういう場合は、可能な限り早く「出来そうにない」と言うのが誠実な対応である。しかし、期限が来るまで黙っていて、当日になってから「出来てません」などと言う人もいる。そういう人に限って、「明日までにやります」などと言うが、やはり出来ないのだ。 そう

    『どうして仕事を断らないのだろうか』
  • 『ハンガリアン記法』

    変数などの名前を付ける時のコーディングルールに、ハンガリアン記法(ハンガリー記法)と呼ばれるものがある。簡単に言えば、名前の先頭に「型」などを表す文字列(プリフィックス)をつけるというものである。 かつて Microsoft が好んで採用しており、 Visual C/C++ (MFC) を使ったWindows プログラミングの仕事が多かった私の会社では、社内ルールとしても採用されている。 というわけで、私も、ハンガリアン記法で多くのコードを書いてきたのだが、あるとき、Joel Spolsky 氏の「間違ったコードは間違って見えるようにする 」という記事を読んでショックを受けた。 それまで私が書いてきたハンガリアン記法というのは、MFC でやっているように、変数名に「型(type)」を表すプリフィックスを付けるものだった。しかし、それは「システムハンガリアン」と呼ばれ、来のハンガリアン記法

    『ハンガリアン記法』
  • mizzy.org : 紫色の何かを口に押し付けている…

    紫色の何かを口に押し付けている… 2 Posted by Gosuke Miyashita Thu, 14 Jun 2007 04:02:00 GMT 会社に紫色のブツがあったので。 この写真は DPL(Dr.Pepper License) により保護されています。ドクターペッパー1おごってくれれば、自由に使ってもらって構いません。(ライセンス発案者は id:tokuhirom さんと id:hirose31 さん)

  • UML::Class::Simple で Catalyst のクラス継承図を描いてみた

    UML::Class::Simple ってモジュールがあります。このモジュールを使うと既存のプログラムを解析してクラス図を作成することができます。業務で仕様書を書く必要がでた場合、もしくは Catalyst のようなフレームワークをより深く知りたくなったときなどに大いに役立つモジュールです。 http://search.cpan.org/~agent/UML-Class-Simple/lib/UML/Class/Simple.pm UML::Class::Simple is a Perl CPAN module that generates UML class diagrams (PNG format, GIF format, XMI format, or dot source) automatically from Perl 5 source or Perl 5 runtime. Per

  • ビートルズの歌詞等を解析できるツール – ビートルズではGoodといえばMorning – 秋元

    IBMのビジュアライゼーション(可視化)に関する実験サイトmany eyesが公開している、Phrase Netというブラウザツールがあります。 そのツールにビートルズの歌詞を放り込んで解析させた人の結果が以下のようなもの。 「ビートルズの曲の歌詞では」、ストロベリーといえばフィールズだし、ヘイといえばバンガローでビルだし、ロンリーなのはピープルな傾向にある、というのがわかるわけです。 “yellow submarine”のようにスペースでつながっている単語を解析すると上記のようになりますし、”rock and roll”のようなandでつながれた関係、”pepper’s lonely”, “top of slide”, “sees the sun”などいくつかの英語での単語のつながり方に応じて、どんなフレーズが多用されているのかを見ることができます。(その場で操作しながら見られるバージョ

  • いつも同じ角度でしか写真に写らない人 – 秋元

    写真映りを気にしてる人って、カメラを向けるといつも同じ顔する人、いますよね。それが徹底するとこんなことになってしまうようで。 リンク先ではこの手の人を5人集めてます。3人目はご存知パリス・ヒルトンですが、たしかにこの人もいつも同じポーズ、同じ角度かも。 via Izismile.com

  • tokuhirom blog

    Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at

  • tokuhirom blog

    Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at