Lifehacker Code: Texter (Windows)
Windows only: Text substitution app Texter saves you countless keystrokes by replacing abbreviations with commonly used phrases you define. Unlike software-specific text replacement features, Texter runs in the Windows system tray and works in any application you're typing in. Texter can also set return-to markers for your cursor and insert clipboard contents into your replacement text, in additio
侍ズム | Samuraism - JavaMail / Google Apps for Domain を使って GMail からメール送信
部活とか研究室同期とかの連絡に使っている自前掲示板があります。 書き込みをすると購読者にメールで通知をしてくれるお利口さんなのですが、去年の７月からどうも DoCoMo の携帯電話にメールが届いたり届かなかったりとどうも不安定です。 localhost に置いてある James から送信しているメールが送信者名を偽装したスパムと思われているようです。 スパムを受信するのが嫌で 25 番を塞いでいる(サーバ管理者としてあまりに安直です。はい、ごめんなさい)のも心証が悪いのかもしれません。 というわけで以前申請してあったGoogle Apps for Domainの GMail を使うことにしました。 Google Apps for Domain自分のドメインで GMail などのツールを利用できるサービスです。 GMail は Web インターフェースだけでなく普通に smtp サーバからも
質問を受ける態度 (翔ソフトウェア (Sho's) Fujiwo の日記)
先日米国で幾つかの技術系セッションに参加したのだが、その折に感じたことを書いてみる。 日本で技術系のセッションに参加すると、聴衆は結構皆行儀が良いというか、大人しくきちんと話を聴いている。 ただし余り反応もなく、話に関心があるのかないのか、賛同しているのかどうかが、比較的分かりづらい (他人のことは言えないのだが)。 反応なくじっと聴いているので、うけなかったのかと思うと、事後のアンケート結果が割と良かったりする。 それに対して、米国のセッションでは、全然雰囲気が違う。聴衆のセッション中の反応が実に豊かだ。賛同の声を上げたり、途中で拍手したり、ジェスチャーで表現したり、質問したり、ちゃちゃを入れたり、頷いたり。 また、ジョークが当然のように入り、聴衆はきちんとジョークに反応する。 どうやら、聴衆の方にもセッション自体の価値を上げる責任がある、と考えているようなのだ。 特に感じたのが、よく質
厚生労動省、デスマーチ予防法を今国会に提出 | スラド
デスマーチプロジェクトの増加によりIT技術者の疾病増加、体力低下、精神錯乱などが社会的問題となっているが、厚生労動省はそれを打開すべくデスマーチ防止法案を国会に提出したとのことである。デスマーチ予防法は、デスマーチスケールでDおよびEと判定されたプロジェクトの管理責任者を懲役を含む刑事罰を課すようにできる他、情報サービス企業に対して「デスマーチ保険」への加入を義務付けるもの。デスマーチ保険では、 データセンター勤務での過度な冷却による凍傷、徹夜用のカップラーメンと栄養ドリンクの過度な購入、ストレス過多な状態でのキータッチによる負傷等の損害が幅広くカバーされる。デスマーチの度合いを計るデスマーチスケールを判定できるのは国家資格のデスマーチ判定士保有者だけであるが、 厚生労動省では今年度から５カ年をかけて1万人のデスマーチ判定士を育成する方針とのことである。(注：エイプリルフール)
BMUF (Big Modeling Up Front)＝上流設計のインチキを斬る - masayang's diary
DDJのCounteracting the False Arguments for Big Modeling Up Front (BMUF)という記事が面白い。BMUFは、日本語なら「上流設計」だろうね。SI屋の自称上流設計エンジニアがやってる、アレだ。[*1] この記事を書いているのはScott Ambler。Refactoring Database著者だ。例によって無断適当意訳。読みやすくするために原文よりも段落を増やした。 上流設計(BMUF)にまつわる嘘を斬る 自分は１９８０年代から数々のプロジェクトで上流設計をしてきたし、様々な手法をみてきた。 そして、うまく行った事例よりは、うまくいかなかった事例の方が多いと言えるね。プロジェクトは明らかに失敗しつつあるのに、上流設計は順調に進んでいる、という現象を誰よりも多く見てきた、ということも言っておこう。 まだあるよ。上流設計担当の人た
Martin Fowler's Bliki in Japanese - 朝会のパターン：立ってるだけじゃないよ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
ソフトウェア開発者のための推薦図書
Code Complete 2 [ Code Complete第2版―完全なプログラミングを目指して (上・下) ] スティーブ・マコネルのCode Completeはソフトウェア開発者のための｢楽しい料理｣本だ。この本を読むということは、自分の仕事を楽しんでいるということであり、自分のすることに真剣であるということであり、もっと向上したいと思っているということなのだ。Code Completeの中で、スティーブは平均的なプログラマが読む 技術書は年に1冊に満たないと指摘している。この本を読んでいるという時点で、あなたはおそらく周りにいる開発者たちの90%と違う行動を取っていることになる。それもいい方向にだ。 私はこの本がすごく好きで、ここから自分のWebサイトの名前(Coding Horror)を取ったくらいだ。この本ではやるべきでない悪い例には"coding horror"アイコンで印
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
IBM Developer
TheServerSide | Your Java Community discussing server side development
O'Reilly Media - Technology and Business Training
IBM Developer