エンティティ文字の一覧を表示します。全てのブラウザでこれらのエンティティ文字が使用できる訳ではありません。事前にチェックするようにしてください。 また、この一覧は全てのエンティティ文字を網羅しているわけではありません。代表的なものに限っています。 表示される文字名前での表現数値での表現説明
HTML / XHTMLで使用されるエンティティ文字一覧
エンティティ文字の一覧を表示します。全てのブラウザでこれらのエンティティ文字が使用できる訳ではありません。事前にチェックするようにしてください。 また、この一覧は全てのエンティティ文字を網羅しているわけではありません。代表的なものに限っています。 表示される文字名前での表現数値での表現説明
デバッグ方法論 - 設計と実装の狭間で。
吉岡さんが釣り糸を垂れているので、釣られてみるよ。 デバッグ方法論 と言っても、多分、僕の気力が続くのは、こんなトピックがあるよ、って事までかな。 細かい話が気になるって人達は、スターとか、ブクマとかで催促すると、 書く気になるかもしれないし、どっかの宴会で、続き喋れって言われれば喋るかもしれない。 前提として、Javaで書かれたコードをデバッグすると考えてクダサシ。 ある程度実行環境やコードの種類に依存しないデバッグの方法論ってのもあるんだろうけど、 僕が気付かないウチに、Javaに強く依存したデバッグの方法論を抱え込んでるって事もあるだし。 まず、デバッグと言う作業が、どの様な構造を持っていると、僕が理解しているか、書いてみる。 バグの定義 静的デバッグ 動的デバッグ フォースを感じる この4つだに。 ちなみに、コードを修正する事は、デバッグでは無いものとするよ。 それぞれは、作業手順
身勝手な「メール信者」ボクメツ大作戦！
メールを送れば「すぐに見てくれる」なんて勝手に思われても、受け取る側の都合だってある。隣の席からわざわざメールをしてくる内気な人もちょっと困る。今回は、そんな身勝手な「メール信者」に振り回されたお話。 友人Y子の誕生日。いつもよりもちょっぴり豪華な食事会で盛り上がった後、お酒に強くない（しかも飲んだら必ずクダを巻く）Y子が「もう1軒、いい？」と誘ってきた。 せっかくの誘いなので、わたしたちはとっておきのワインバーへと向かった。たわいもない話でひとしきり盛り上がった後、Y子が仕事の話を始めた。お、いよいよ本題ですね。仕事は楽しいとか、新しいプロジェクトに参加することになったとかいった話がひとおとおり済んだ後、急にY子の声のトーンが低くなった。 Y子 今日、午後から会議があったんだけど、わたし、知らなかったのよ。 わたし え？ どういうこと？ Y子 お昼休みがもうすぐ終わるって時に後輩がやって
多数のパスワードを効率よく作成する「Password Creator TypeB」
ネットワーク管理者の大切な仕事の1つにアカウント管理がある。たとえばActive Directoryを運用しているネットワークの場合，運用上のセキュリティ・ポリシーに適合するようにパスワード・ポリシーが設定しているケースが多いはずだ（Active Directoryにおけるデフォルトのパスワード・ポリシーについては，Microsoft社のTechnetの解説記事「ステップバイステップガイド：Windows Server 2003 Active Directoryにおける強力なパスワードポリシーの強制」などを参照されたい）。ネットワーク管理者にとっては，ユーザー・アカウントやインターネット・メールのアカウントを多数設定しなければならない，新入社員や人事異動の時期には気が重くなることもあるだろう。このようなときに，パスワード・ポリシーに適合するようなパスワードを多数作成するのは，骨の折れる仕事
Planning Poker - 祈れ、そして働け ～ Ora et labora
オブラブ冬合宿 2009で初体験したPlanning Pokerを、チームの計画ゲームで使ってみました。 Planning Pokerとは、数字が書かれたトランプのようなカードを使って、見積もりの合意を形成していく手法です。カードに書かれた数字は、ストーリーやタスクの相対規模を意味します。数字の組み合わせには幾つかのバリエーションがあるようですが、今回は？・０・１・２・３・５・８・１３・２０・４０・１００・∞を組み合わせた１３枚×４セットを作ってみました。 Planning Pokerの手順は以下の通りです。 一番簡単そうなタスクを選んで、その規模を１と仮定します。 つぎのタスクを選んで、３分間、そのタスクについて話し合います。 心の中で、そのタスクの規模を見積もります。基準となるのは、規模が１のタスクです。 いっせいの〜で、見積もった規模が書かれたカードを見せ合います。同じ数字のカードが
アジャイルな見積りと計画づくり - masayang's diary
安井さんから1月下旬に頂いた「アジャイルな見積りと計画づくり」。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者: Mike Cohn,マイクコーン,安井力,角谷信太郎出版社/メーカー: 毎日コミュニケーションズ発売日: 2009/01/29メディア: 単行本（ソフトカバー）購入: 74人 クリック: 764回この商品を含むブログ (226件) を見る なんと読むのに二ヶ月かかってしまった... 言い訳すると...印象に残った所に付箋をペタペタ貼っていたため。 大変遅れてしまって申し訳ないが、読後感想などを... 全般 これからAgileを始めたい人はもちろん、既にAgile開発に詳しいつもりの人も、「俺はウォーターフォールでいいんだ」という人にも是非読んでもらいたい本。 特に「進行基準」に興味ある人には強く推薦。 読んだ後は「見積りを精査します！」なんて
あなたの説明責任(Accountability)がなんぼのもんじゃ - masayang's diary
相変わらずのマイクロマネージメントな現場だらけで心が荒む日本出張。 が、よく見るとマイクロマネージメントには二種類あることがわかる。 「管理される側が力量不足なので、管理する側は細々と面倒みないといかん」 「管理する側の説明責任を取り繕うために、管理される側に対して細々指示を飛ばす」 今回問題にしたいのは、後者。 「私には説明責任がある。だから○○と△△と××しろ。」と部下に細々指示を出すのは簡単である。 だが、その説明責任とやらを遂行できない場合にどれくらいの損失が発生するというのだろう？ 降格・減給といった、認識可能な損失？ それとも、「こら！」と誰かに怒られるだけ？ あるいはプロジェクトがお取り潰しになる？ 説明責任を果たせない代償は様々だろう。 でも、その「代償」は「チーム全体の生産性」「部下のやる気」あるいは「部下が将来役立つ技術を学ぶための機会」を奪ってでも回避したいものなの？
ウノウラボ Unoh Labs: モテるエンジニアの7つの習慣
Keitaです。 モテたいという気持ちは、たとえ既婚でも何歳でも変わらない気持ちのはず。 ウノウのwikiには、3年前につくられた「もてる」というページがあります。 そこで弊社のエンジニアが脈々と受け継いだモテ技術の一部を披露したいと思います。 詳細は以下から 出会う箇所を増やす 最近ではSNSが流行らしいです。 同じ趣味の相手が見つかったりするかもしれません。 エンジニアだったら自分でSNS立てるといいかもしれませんね！ チャックを閉める 社会の窓的なものはきちんと占めましょう。 っていうか朝起きたときに鏡みて、寝癖と服装くらい確認しましょう。 あけていることで新たな展開があることは残念ながらありません。 髭や髪の毛はちゃんと整えましょう こちらも常識ですね！ フラグはきちんと立てましょう 「いつか一緒にいきましょう。」とかいってもいつかなんてきません。 日時を
Invention Works: 自分用Eclipseプラグイン一覧
◎ Outputz Plugin update http://yoshiori.org/project/outputzplugin/update/ ●Vi Plugin http://www.viplugin.com/viplugin/ update http://viplugin.com ●EasyExplorer(maven2を使うなら) http://easystruts.sourceforge.net/#easyexplore update http://easystruts.sourceforge.net/eclipse/updates/site.xml ●Implementers http://eclipse-tools.sourceforge.net/ update http://eclipse-tools.sourceforge.net/updates/ ●CheckSty
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Solaris Essentials - General Technical Questions - Solaris on x86
JavaScript + Ajax 実践サンプル集 - ホーム
データ構造の選定より重要なもの - 2009-04-02 - きしだのはてな
やっぱりデカすぎた - 宇宙行きたい
