ついにこの時を迎えてしまった。 不満はない。しかし、居心地のよいHelm.elとお別れをしなければならないのかと思うと小指の古傷がうずいて仕方がない。私を引き止めようとしているのだろうか、まるで考えなおせといわんばかりに。 だが、私の小指はもう…...。 …...いや。 ああ、少し昔話をしよう。 私はその昔、Emacsを最高に使いこなせるようにと小指の修行をしていた。もうずいぶん昔の話だ。 2,3年ぐらい前だ。 なぜそのような修行をしていたのかというと最高の小指を用意するためである。もちろん、最高のEmacsに応えるために。 iPadやiPhoneは小指だけで操作し、かの松尾象山も躊躇したという片手小指逆立ち、小指ピンポンダッシュ、アマゾンの奥地にて小指を餌に見立てたピラニア小指一本釣りなど、様々な修行をしてきた。 なかでも特に困難を極め、私の小指もこれまでかと覚悟した修行がひとつあって、
結構みかけます。はみコですね。はみコ。動詞にすればはみコると言います。清志郎風に言えばはみコってるかーいです。どうでもいいです。 pre { white-space: pre-wrap; word-wrap: break-word; } スタイルシートでpreに設定しておくと折り返します。だいたいの主要なブラウザで有効かと。firefoxやoperaでの古いバージョンはベンダー接頭辞を使うけど確かfirefox2.0とかopera9あたりの話だからいらないんじゃないかな。というかこのあたりはダイアリー側のデザインで最初から設定してあればいいのにね。 overflow:autoでも良いけど個人的にはスクロール無しで折り返しが好きです。横スクロールは面倒な気がして。あとword-breakプロパティはいらないはず。って確認したら私は入れてた。IE5.5あたりで有効だったから入れたんだっけかな?
ブログ(プログラマの思索)で日々質の高いエントリを投稿しているあきぴーさんの執筆ということで心待ちにしていたが、期待を裏切らない内容だった。やはり実践を伴った主張には説得力がある。 プログラマの思索 IT業界に身をおいて、1日の労働後、心に溜まった疑問を一つずつ点検してみる。 ... チケット駆動開発の効用は、何といってもトレーサビリティ(追跡可能性)の確保だろう。 ソースの変更と変更理由の結束の保証。一度でも開発を経験した人なら、これがどれだけ大きな価値をもつか説明は不要だろう。顧客の「いつどんな理由でこの変更をしたのですか?」という問い合わせにマネージャは即答でき、開発者はコメントが書かれていることを祈りながら過去のソースコードを追う必要がなくなるわけだから。 問題は導入コストだろう。この書籍で実現されていることには憧憬すら覚えたが、アプリケーションは無償でも学習コストは非常に高いと感
SpringやSeasar2などの軽量なフレームワークが登場し、POJO、DI、AOPという考え方が今ではすっかり浸透してきているのかと思いきや、ぜんぜんそんなことはないみたいです。客先でも(主に社内での)実績最優先という考え方から、最近のOSSフレームワークには手を出さず、日本の大手SIer謹製のフレームワークを採用したり、自社フレームワークを採用したりするケースが意外に多いですね。そういう場合によくありがちなのが、プログラマーのスキルによらずに作れるようにするという目的から、無意味な規約を強制するケースです。 実際、今日ある国産ベンダーのフレームワークを採用したシステムの設計書に記載されているクラス一覧を見ていて無駄がいかに多いかということに驚いてしまいました。たとえば、ユーザー一覧を検索するという処理でSeamならエンティティクラス、画面、JPQLがあれば実装完了なのですが、そのフレ
TwitterでドコモからGmailに音符の絵文字メールを送ると「うんこ」に変換されるとの情報を聞き、「またまた、そりゃないでしょ?」って思って検証してみました。 ドコモの携帯で確認したところ音符はいくつか有るみたいなので「絵文字の音符」「絵文字の音符3つバージョン」「絵文字じゃない通常フォントの音符」の3つとも書いて送ってみました。 結果はこちら 問題なくちゃんとドコモで表示したものと同じものが表示されました。「Googleは絵文字をUnicodeに取り入れようとして動いていたりするし、そんな誤変換しないよな?デマだったか?もしかして釣られた?」と思ったのですが念のため、iPhoneでGmailを表示してみました。 結果はこちら うんこ!!うんこ出ました!! iPhoneでGmailのメールを見ると変換されるみたいです。「絵文字の音符3つバージョン」もチューリップに変わってます。ドコモか
プロジェクト一覧からも分かりますが、TPTPを利用することで単体テスト、結合テスト、性能テストなどにおいて同じGUIインターフェイスを通したテストを実現することができます。このため、いくつかの異なるテストツールを複合的に使用するよりも、テストの効率化が容易であるといったところが優れているツールです。 TPTPは、さまざまなテスト機能を提供していますが、その中でも今回は「Testing Tools」プロジェクトが提供するJUnitテストコードの作成・実行に注目しながら解説していきます。 特徴 TPTPによるJUnitテストコードの作成・実行における特徴は以下になります。 ・GUIエディタでのテストスイートの編集・管理 テストエディタと呼ばれるGUIエディタを通してテストクラスおよびテストスイートの編集・管理が可能です。TPTPを利用したテストコードの生成では、テストコードを実行するために必要
せっかくなので JavaBlackさん つながりで。 プログラマーになるには - カレーなる辛口Javaな転職日記 http://d.hatena.ne.jp/moto_maka/20101128/1290886142 わたし的には、Webの(blogの)記事とかで、「もっと知りたいなら」「正確には」とハイパーリンクが貼ってあって、その先が何故か Amazonで、リンクを踏む度に家に技術書が増えていく・・・というパターンかな。 結果、床が抜けそうですし、万年貧乏だったり。高いですよね技術書って。 * * * C++ の必読本は簡単にいえば C++ in-Depth シリーズ全部なのですが、それはプログラミング言語的に普通のことではなく、 C++ がおかしい、ということは忘れてはいけないと思います。 冊数的にこれだけ読まないとダメというのは絶対おかしいですけど、どの本も実際に身になり肉になっ
私が、なぜオブ本書評で前橋さんの講義「疑りぶかいあなたのためのオブジェクト指向再入門」を OOP じゃない、と言った問題について、神様なんて信じない僕らのために さんで議論になっています。 関数はひとつしかない事が問題なの? - 神様なんて信じない僕らのために 続・関数はひとつしかないことが問題なのか? - 神様なんて信じない僕らのために 複数個を前提とした設計はオブジェクト指向で綺麗な設計か? - 神様なんて信じない僕らのために で、最後のの、前橋さんのコメントを読んで、思ったこと/言いたいことが出て来てムズムズしてしまいました。あぁ、あたしんちに書いてくれたらうれしかったのに。で、Isoparametricさんちの コメント欄にいろいろ書きかけたのですが、例によって肥大化してしまったですし、ちょっとヒトのウチで場外乱闘はどうかな?、と思い直して自宅にてエントリーをば。 ひとつめ、 抽象
やはり、多くの人からいろいろなコメントをいただくと、意外な発見がありおもしろいです。 プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して のブクマのコメントに 何か、主語がないから理解が難しい読み物 というのがありました。私の文章の拙さをまずは反省しなくてはなりません。ただ、普段から日本語を話したり、文章を書いたりする際にはあまり意識していなかったのですが、よくよく考えてみると日本語の文章で「主語」と呼ばれるものがなんとなく省略されることも多いように思えてきました。中学校の国語の授業では「は」や「が」という助詞がついた言葉が主語であると習ったと記憶しているのですが、実際に、文中で明示的にそのような文節が表れない現れないことが多いように思います。 そこで「日本語 主語」で検索してみたら、非常に興味深い記事がいくつか見つかりました。 http://www.geo
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して で以下のようなコメントをいただきました。 アプリケーションのアーキテクトという役割についてちょっと理解が曖昧だったのがこのエントリ読んでだいぶスッキリした。今度の開発系の勉強会のネタにとりあげようかな アーキテクトの働き方の参考に。 そもそもオブジェクト指向を本当に理解していてプログラミングも得意なアーキテクトがどれくらい居るのやら。 全体の設計がちゃんと推敲されていて、きちんと疎結合が達成されているなら、後の修正にも耐えられる。 アーキテクトが何をどこまで責任持つのか、という認識が整合されてないんじゃないの 現代的アーキテクトの仕事 このようなコメントから、「アーキテクト」という仕事の内容については、実はよくわからないと考えている方が多いように感じられます。実は、私自身も「アーキテクトという役割で仕事をす
半年前に爆発的に盛り上がったネタで今更ですが、 実はオブジェクト指向ってしっくりこないんです!:気分はstatic!:エンジニアライフ について。多態性(ポリモーフィズム)やGoFのデザインパターンなどの常識を知らない筆者が、C#でpublic staticメソッドを使えば*1インスタンス化が不要などと知ったかぶりの口調で説明したところ、コメント欄やその他のブログで爆発的に議論(多くは反論)が巻き起こったという、伝説的な内容の記事です。多くの方が既にコメントしているので、ここでは筆者の無知や態度については繰り返し言及しないことにします。ユーザー企業のIS部門という業界のピラミッド構造のかなり上の方に属する立場のSEにはこの程度の見識しか持たない人もいるのか、井の中の蛙の技術者とはこのようなものなのかという事実をあらためて世に知らしめたという意味で、(炎上した多数のコメントも含めて)非常に貴
S式の呪縛 http://www.dwheeler.com/readable/sweet-expressions.html やっぱS式suck! 頭の固いロートルLisperどもよ、俺がLispの美しい代替構文を考えてやったぜ。完全S式コンパチだが中置式もインデントも使えるぜ。ヨロシク。 http://chrisdone.com/posts/2010-11-25-lisk-lisp-haskell.html Haskellクール! だけど構文がsuck! インデントセンシティブで綺麗になるのはサンプルコードだけさ。実世界のコードはどうせぐちゃぐちゃになるんだし。S式にすれば曖昧さ無くなるしマクロも使えるし良いことずくめだね! 中身はHaskell、構文はS式、これ最強! Tags: Programming, Lisp, Haskell Othello (2010/12/01 15:12:5
秋山さんが執筆された「ソフトウェアテスト技法ドリル―テスト設計の考え方と実際」を読んでみた。 テストケース作成技法がとても実践的で、しかもフリーのツールを色々説明していて役立ちそうな感触を持った。 感想をメモ。 【元ネタ1】 【感想】ソフトウェアテスト技法ドリル/秋山浩一 - Software Quality Topics. ソフトウェアテストの勉強室: ソフトウェアテスト 本棚3 「ソフトウェアテスト技法ドリル―テスト設計の考え方と実際」は、テストケース作成技法を初心者~中級者レベルに向けて書かれていると思われる。 同値分析、境界値分析の使い方から原因結果グラフ、HAYST法、ペアワイズ法など各種の技法が説明されている。 僕が興味を惹いたのは、原因結果グラフからデシジョンテーブルを生成するツールCEGTestと、ペアワイズ法によって組み合わせを生成するツールPictMasterの説明がと
ツールをいくら使いこなせたとしても、開発がスムーズでなかったり、システムの品質が良くない時もある。 下記の記事を読んで考えた事をメモ。 【元ネタ】 テストツールとテスト設計意識: ソフトウェアテストの勉強室 状態の洗い出しへHAYST法かpairwise法の適用: ソフトウェアテストの勉強室 TestLink Home TestLinkを使いこなせば、大人数でのテスト作業を効率化できる。 でも、それだけではシステムの品質は保証できない。 TestLinkを運用してみて、テストケース作成の技術がとても重要だと体で感じた。 いくらテストしても、テストケースでカバーしていない仕様は、結局バグの温床になる。 かと言って、テストケースをたくさん作っても、テストが納期までに終わらない。 リスクベースドテストでは、プロダクトリスクの高い機能やバグを先にテストするが、それだけでも不十分。 もう一段階上のテ
Redmineのトラッカーやステータスの付け方の記事があったのでメモ。 【元ネタ】 Redmine チケットのトラッカーとステータス項目の意味と設定 - developer (引用) * トラッカー o ドキュメント + ドキュメント書き。 o 調査・検証 + 調査、検証、研究など。 o 機能 + 機能の追加や変更など。 o 不具合/バグ + バグや不具合登録する。 o 要望 + ユーザーからの要望。 + 後で「機能」や「バグ」に変化する可能性がある。 o サポート + ユーザーからの問い合わせは、とりあえず登録。 + 後で「要望」や「バグ」に変化する可能性がある。 o 障害 + なんらかの障害が発生したら、とりあえず登録。 + このチケットに関連した「不具合/バグ」のチケットが後から追加される可能性あり。 o 環境 + 環境構築・環境整備や設定変更など。 o アイデア + アイデアを登録
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く