サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
今年の「#文学」
proger.blog10.fc2.com
偉人と凡人の別は一言にして尽くすべきのみ。かれは人生を簡単にする者なり。これは人生を複雑にする者なり。 高山樗牛 ソフトウェア開発の現場では、成果物やプロセスの評価、見積もりのために様々なメトリクスを収集します。メトリクスと一口でいっても、プロダクトメトリクスから、プロセスメトリクス、リソースメトリクスなど様々ありますが、主要なものでは、生産性を示す指標としてソースコード行数をかかった工数でわったKSTEP/人月のようなものや、その他にも、ソースコード中のコメントの割合を示すコメント率、欠陥数をソースコード規模で割った欠陥密度(バグ密度)などなど、その多くがソースコードのステップ数、行数がベースになっています。 こういったメトリクスメトリクスを測るということ自体は、プロダクトやプロセスを客観的に眺めるために有用ではあるのですが、その特性を理解しておかないと間違った指標として使われることがあ
天災は忘れた頃にやって来る 寺田寅彦 組み込みLinuxにおけるメモリ確保のエラーハンドリングに関するお話。 Linuxにはmemory overcommit(オーバーコミット)と呼ばれる仕組みがあります。簡単にいうと、メモリ割り当ての段階では、仮想アドレス空間だけをわりあてて、実際に使われる段階で、実メモリを割り当てるというものです。メモリ割り当て時には、実メモリはまだ割り当てられないので、実際の物理メモリの容量以上のメモリ割当てが行われることを許されることになります。 実例を見た方が早いので、例えば以下の例。 #define BLK_NUM 100 #define BLK_SIZE (100 * 1000 * 1000) /* 100MB */ int main(int argc, char* argv[]) { int i; char* blk[BLK_NUM]; for (i =
眺めているうちに、いろいろ気づいてくる You can observe a lot just by watching. ジョセフ・マーフィー 組み込み系では、ターゲット端末にシリアル接続してコンソール経由で、ログとったり、デバッグしたり、あるいは設定したりということがよくあります。その時必要になるのが、シリアル接続用の端末プログラムです。WindowsだとTeraTerm、Linuxだとやっぱりminicomが定番でしょうか。Linuxでは、Qt4使ったcutecomも試してみましたが、個人的にはボタンがごちゃごちゃしてイマイチだったので、結局minicomに戻りました。 ということで、今回は、Linux(Ubuntu 14.04)のシリアル通信端末としてminicomを設定した時のメモです。以下記事を参考にさせて頂きました。 (参考)Ubuntuでminicom起動すると/dev/tty
まかせてはいるけれども、たえず頭の中で気になっている。そこでときに報告を求め、問題がある場合には、適切な助言や指示をしていく。それが経営者のあるべき姿だと思います。これは言いかえますと“まかせてまかせず”ということになると思います。まかせてまかせずというのは、文字どおり“まかせた”のであって、決して放り出したのではないということです。 前回単体テストに関する話を書いたのでその続きで。 単体テストという言葉の定義はプロジェクトによって様々ですが、もっとも多いのは”関数”を単位とするものかと思います。関数単位のテストでは正常系のテスト(関数が適切に使われた時のテスト)以外に、異常値を与えられた時のテストも行われます。例えば以下の例。 const char* month_name(int month) { const char* name[] = {"Jan", "Feb", "Mar", "A
ソフトウェア開発のモデルでV字モデルと言われるものがあります。要求分析から詳細設計・コーディングまでの上流工程に対して、それぞれの工程に対応するテスト工程によって、その成果物が検証されるようなモデルです。 単体テストは、いわゆる詳細設計に対応するテスト工程になっていますが、ソースコードレビューはどこにマッピングされるものでしょうか。コーディングの一環と見方もできますが、単体テストと同じく、実装完了したソースコードを対象とするものですので、単体テストと同じく、詳細設計に対応する検証工程と考えるのが普通かと思います。 では、単体テストとソースコードレビューはどちらか片方だけすればいいものでしょうか。以下で紹介されている内容がわかりやすかったのでご紹介したいと思います。 GAIO e-learning 3.3 ソースコードレビューとユニットテスト 日本システム株式会社 単体テスト設計のコツ ここ
Windowsでpythonという場合、cygwin pythonかWindows python(Python for Windows)の選択肢があります。自分の場合、shell作業との相性からcygwin版のpythonを使っていますが、目的によってはWindows pythonを使いたい時もあります。ということで、WIndows pythonとcygwinの組み合わせ時の注意点などをメモっておきます。 Cygwin terminalからWindows Pythonを使うための設定 alias設定 Windows Pythonの標準インストールであれば、python本体はC:\Python27\python.exeがインストールされると思います(Python2.7の場合)。基本は、cygwin版pythonを使うので、ここにはパスを通さず.bashrcあたりにaliasだけ用意しておきま
Linuxを使ってパケットキャプチャや、パケットロスや通信遅延といった通信環境のシミュレーションを簡易的に実施するという話です。 本格的な評価のための通信レミュレーションとなると、専用の機材を使わないと難しいこともありますが、簡易的な確認であれば、ノートPCに入れたLinuxだけでできるようにしておくと、特別な機材準備もいらないので、結構便利だったりします。メモもかねて残しておきます。 やりたいこと 有線ネットワーク上のパケットキャプチャ 通信の遅延や瞬断、パケットロスのレミュレーション 準備 virtualbox + UbuntuをインストールしたノートPC ※ ホストOSはなんでもいいと思いますが、試しているのはWindowsです。 また別にノートPCじゃないとだめってわけではないですが、持ち運んで使うという想定で USB-ether変換器 x 2個 ※ 私は以下のBUFFALOのUS
ノートPCを持ち歩いて使うと、IPアドレス設定等を場所や目的にしたがって切り替えたい時が結構あります。大抵は、DHCPで事足りるかもしれませんが、固定IPが必要なことも結構あったりします。ノートPCだと、イントラやインターネットに接続するという以外に、ちょっとした調査や解析のためにローカルなネットワークに接続したい時なんかもあるでしょう。 Linuxであれば、ifconfigの設定scriptを準備しておくというのが常套手段かもしれません。一方、Windowsの方は、あんまりなじみがないかもしれませんが、netshコマンドでコマンドラインからネットワークアダプタの設定ができます。GUIでももちろんできますが、Windowsのアダプタ設定は階層が深いし、なんとも使いにくい。。。そこそこ切替頻度が高いのなら、バッチファイル用意しておくことをおすすめします。 例えば、「ローカルネットワーク接続」
データベースやログのエクスポート時のフォーマットとしてよく使われるcsv。テキスト形式なのでエディタでも開けますが、Windows環境であればExcelで開いていると思います。Excelでcsv扱うのは、便利ではありますが、いろいろ不都合や不満点があります。 よくあるのは、次のようなもの。 書式が日付や数値に勝手に変換されてしまう。 セルの横幅を内容にあわせて調整したい。 大きな表の場合に、毎度オートフィルタとウィンドウ固定するのが面倒 例えば、以下のようなcsvを開こうとしたとします。 DATE,TIME,ID,ID2 2013/12/1,10:00:01,0-1,A 2013/12/20,12:20:00,1-1,01 2014/1/1,15:10:30,A-1,A1 これをExcelで開くと以下のような見え方になります。 特に、最初の書式変換がかなりやっかいです。単に表示の書式があっ
Windowsにgnupackを使ってCygwin環境をセットアップした時のメモです。 gnupackについては、emacsとあわせてアーカイブ展開するだけで、ある程度設定済の環境がすぐに使えるということで、手軽にCygwinを構築するには非常に便利です。とはいえ、いくつか設定等変更しておくと便利な部分もあるので、そのあたりのメモです。ベースとしては、gnupack_devel-11.00.exeを使っています。 apt-cygの修正 今現在最新の11.00だと、ちょっと前にCygwinダウンロードサーバ側の変更に追従できていないためにエラーになります。とりあえず修正必要なのは二点。 mirrorサイトのディレクトリパス変更へ追従 (でないと、apt-cyg updateでsetup.iniがnot foundになり失敗する) tar.xzへの対応 (元のapt-cygだとbzip2決め打
長らく放置状態にしていた物置を大掃除。すると出てくる出てくる、引越し以来開けていないダンボールや、二度と着ないであろう服、未だ読んでないものも含めた大量の本、長らく聞いていないCD。。。「いつかまた」と思って残してきたこれらの荷物達ですが、この状態では「いつか」も一生こないのはいい加減明白。思い切って「捨てる」「売る」「電子化」することを決めました。 大切な本は電子書籍化 電子化すべきか、残すべきか 掘り出されたダンボールの中身は、また読むかと思って残している書籍から、買ったものの一度も読んでいないもの、あるいは読み終わって処分していないものまで様々。不要なものは、捨てるか売るかするとして、問題は残しておきたい書籍達。紙の形はかさばるし、持ち歩くのも一苦労なので、ここはやっぱり電子化したい。とはいえ、自分で自炊環境揃えるのも大変ですので、前から気になっていた自炊代行サービスを利用することに
すぐれたジョークは、すぐれたアイデアに通じる。 本田宗一郎 実に久々の更新です。ちょっと古いネタになるんですが、Mashableの「The 10 Oddest Apple-Themed Products」という記事の中で、Apple好きならニヤリとさせられるような小物(大物もありますが)が紹介されていました。あとで調べてみると、日本で買えるものも結構あるようだったので、ここで少し紹介します。 500XL Giant Earbud Speakers iPodのシンボルとも言える真っ白なイヤホン。500倍スケールのイヤホン型のスピーカーです。以下の楽天ショップで購入できます。 500XL デスクトップスピーカー (インテリア マルキン家具) AirMail Manila Envelope MacBookの発表の時に、その薄さを伝えるために封筒から出して見せたというのは有名ですね。実用性の程
サンクコスト (sunk cost) という単語を耳にされたことはあるでしょうか。日本語では「埋没費用」と訳されます。Wikipediaを見ると、「事業に投下した資金のうち、事業の撤退・縮小を行ったとしても回収できない費用」と説明されています。マーケティング用語ですが、今回は、ソフトウェア開発におけるサンク・コストとその対応について少し考えます。 サンク・コストのわかりやすい例としてよく用いられるのが映画館の話です。これまた、Wikipediaからひっぱってきましょう。 ある映画のチケットが1800円であるとする。しかし映画が余りにもつまらない時、1800円払った映画を見るべきか、それとも映画館を出て残りの時間を有効に使うかが問題となる。 映画を見るのを止めた場合:チケット代1800円は失うが、上映時間を有効に使うことができる。 映画を見続けた場合:チケット代1800円に加え、約2時間(上
人気blog「分裂勘違い君劇場」の記事「中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな3つポイント」という記事が注目エントリになっています。ということで、ひさびさにコメントがてら投稿したいと思います。 分裂勘違い君劇場 中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな3つポイント あげられているのは、次の三つ。 「変数のスコープは狭いほど良い」と妄信する 「同じロジックのコードを2度以上書くな」と妄信する 「プログラミング言語を極めるのが大切」と妄信する いかにも議論を呼びそうな内容ですね :-)。既に多くのコメントが寄せられていますが、一言で言えばケースバイケースということにつきます。何にでも例外がありますからね。この辺、言うまでもなく「適切な」判断が一番なのですが、そうはいっても、初心者にとってその判断はなかなか難しい。そこ
設計レビューやソースコードレビューといったレビューは、ソフトウェアの品質確保だけでなく、開発者のスキル向上のためにも非常に有意義です。このレビューを有意義なものとするために心がけてべき最も重要なことのひとつが、 「自分の書いたソースコードや設計書に対して客観的であること」 です。簡単そうで、これがなかなか難しい。 人間、自分で作ったものは愛着が出ます。これはソースコードも同じ。エレガントなモデル設計やスマートなアルゴリズムに仕上がったものは誇らしいけど、混乱した設計や実装も、こんなはずじゃないんだ、分かっているんだとかばいたくなる。なので、人からつっこまれると、ついつい、ソースコードの味方をしてしまうことがあります。これは、ちょっと過保護で、ソースコード君のためにはなりません。 では、客観的な立場に立てているどうかはどうやったら分かるでしょうか。ひとつの方法は、「レビューの指摘に対して、ソ
昨日WBSでのサービス業におけるサービスのありかたについての特集がありました。サービスの基本は、お客様の視点に立ち、それを徹底して実践すること。それを実践している代表格がディズニーランドです。 WBSの中でもいくつか紹介されていたのですが、特に感心したのが、ディズニーランドの水飲み場の話。ディズニーランド内の水飲み場は、親用と子供用の二つがセットになっており、子供用のものは踏み台があるんだそうです。なぜ、そういう形をとっているかというと、親子で水を飲んだ後、ふと顔をあげた時に目線があうようにしているため。アイコンタクトを演出することで、水飲み場でさえもふれあいの機会に変えてしまうという発想には感動しました。ディズニーランドが、ユーザー体験をいかに大切に考えているかということを如実に表しています。 さて、その他、ディズニーランドには様々なこだわりが存在します。トリビアっぽい話ですが、少し紹介
年々仕事量が増えてきて、どんどん忙しさは増してくる。原因は、次々とふってくる仕事。こなしてもこなしても、空いたスペースに仕事が入ってくる。。。 私自身そうですが、業界問わずよくある話だと思います。仕事がもらえるのはありがたいとは言えるのですが、こんな時は、ついつい「やらされている」という意識をもってしまいがちです。既に十分すぎるほど忙しくて余裕がない時に、新たにたのまれた仕事などは特にそうでしょう。しかし、仕事に対する意識が「受身」になると、モチベーションもさがってしまいまい、効率も非常に落ちてしまいます。 「やらされている」という意識の裏には「こんな仕事やりたくないのに」という思いがあります。やりたくないのだからモチベーションなんてあがるはずもありません。しかし、同じ仕事でも、その時自分に余裕があれば、積極的にヘルプにまわることだってあるのではないでしょうか。例えば、人のデバッグ手伝うと
任天堂社長「ゲームの敵だったお母さんが買ってくれれば」 http://www.asahi.com/kansai/news/OSK200801030061.html 少し前の記事ですが、任天堂岩田社長がWiiやDSのヒットについて語ったインタビュー記事です。『誰からも嫌われない存在』をねらったDS、そして、『みんなで囲む』というスタイルを提案するWii。なるほど。。高い演算能力やグラフィック性能を進化させたPS3とは、本当に対照的です。 この対比を見るとやはりクリステンセン氏の「イノベーションのジレンマ」の話が頭をよぎります。「イノベーションのジレンマ」とは「顧客の意見に熱心に耳を傾け、新技術への投資を積極的に行い、常に高品質の製品やサービスを提供している業界トップの優良企業が、その優れた経営のために失敗を招き、トップの地位を失ってしまう。」そんな逆説的なコンセプトを論理的に解き明かしたベス
プログラミングにおける変数や関数、クラス設計の命名というのは、そのプログラムの可読性を左右する最も重要な要素のひとつです。変数名や関数名が適切であれば、プログラムの流れも読みやすいですし、バグがあっても見つけやすいものです。 さて、このような命名規則(命名規約)といったものは、大抵それ読む人間のために設定されます。コンパイラにとっては、変数名がoldUserNameだろうがounだろうがxだろうが、関係ありません。変数名は単なる記号です。 しかし、考えて見るとこれは非常にもったいない。人間が、変数名からエラーを発見できるということは、このルールを(広い意味での)コンパイラに教えてあげれば、同じようにエラーを発見してもらえるのではないでしょうか。 例えば以前に次のようなバグコードを見たことがあります。 .... len = strlen(name); strncpy(buf, name, s
最近はユニバーサルデザイン(UD)という言葉を良く耳にするようになりました。はてなキーワードの説明では、『ユニバーサル=普遍的な、全体の、という言葉が示しているように、「すべての人のためのデザイン」を意味し、年齢や障害の有無などにかかわらず、最初からできるだけ多くの人が利用可能であるようにデザインすること。』となってます。つまり、全ての人にやさしいデザインということになるでしょうか。 この「ユニバーサル」つまり「全ての人に」という部分は非常に重要な考え方だと思いますが、やはり人によって得手不得手がありますので、ものによっては、どうしてもこっちを立てればこっちがたたずといった状態になります。こうなると、どこを立てるか、つまり、どんな評価関数でもって最適化をかけるかということが重要になります。 さて、こんなことを書いているのは最近Gコードの構成についてなるほどーっと思ったのがきっかけです。 G
『現実の世界』というものは、多くの限度にまで、その集団の言語習慣の上に無意識的に形づくられているのである。 エドワード・サピア 『言語 - ことばの研究序説』サピア=ウォーフの仮説(The Sapir-Whorf Hypothesis)というものをご存知でしょうか。人が話す言語と、人の物事に対する考え方・理解の仕方には密接な関係があるという言語学分野における有名な仮説です。 有名な例として、虹の色数の話があります。日本では、7色が通例ですが、これは万国共通の認識ではなく、場所によっては8色であったり、6色であったりします。日本でも、緑色のことを「青」と呼ぶことがありますが、このように青と緑を区別しない言語圏では「青」と「緑」が区別されないので色数が減ることがあるそうです。 他の興味深い例としては、オーストラリアのある民族は、紙に書かれた矢印を「上下左右」ではなく「東西南北」で認識する数字を
技術の進歩は、人々の生活を便利にしますが、必ずしも豊かにするとは限りません。言い尽くされたことですが、「便利」=「満足」とはいかないためですが、今回は、はこのあたりについてちょっと考えて見ます。 きっかけは、「便利になるとストレスが上昇する」という不思議なジレンマ (Life is beautiful)という記事です。携帯電話などの普及で、いつでもどこでも連絡がとれる環境が整ってきたものの、かえって連絡がとれないという不満を感じる機会が増えているという話です。電車や、パソコンの起動時間などの対する待ち時間に対する感覚も同じような話で、以前よりはよくなっているはずが、使う人の感覚のほうがより「せっかち」になり、かえってストレスが増大しているというデータがあるようです。おそらく大半の人が思い当たるふしがあるのではないでしょうか。私の場合、実家の田舎に住んでいたころは、バスが2時間毎とかなので、
僕が生まれたこの島の唄を 僕はどれくらい知ってるんだろう トゥバラーマもデンサー節も 言葉の意味さえわからない でも誰より 誰よりも知っている 祝いの夜も 祭りの朝も 何処からか聞えてくるこの唄を cd, pwd, ls, rm, mv, ln, du, df, man, grep, cat, ps, dd, sed, .... UNIX系の代表的なコマンド(プログラム)達ですが、UNIX/LINUX系を使うプログラマやサーバ管理者以外の人から見ると、意味不明のアルファベット列ですよね。 さて、私も普段からお世話になっているこれらのコマンドですが、それぞれの名前の由来はと聞かれると、以外と知らないものです。または、知っていると思っていても、意外に間違っていたり、いろんな説があったり。。 例えば、スーパーユーザーになる時のコマンドsu。これも何の略かとか改めて考えたことはなかったのですが、以
私の場合、電車の中では読書、駅までの徒歩時間はipodが通勤時のお供になっています。本は通勤時間以外はほとんど読まないのですし、速読ができるわけでもないですが、積もり積もれば結構本は読んでる方かもしれません。 さて、ちょっと前に話題に、これを読んでおくと読書スピードが速くなる。自己啓発書編。ついでに知的生産編 (俺と100冊の成功本)という記事が話題になっていました。 こちらの著者の方は、ものすごい勢いで本を読まれていますが、そのコツというか理由のひとつが、 大抵の本には引用等で重複するところがある すでにその話を知っていれば、その部分は読み飛ばせる。 だから、多くの本で引用されるような書籍を押さえておくと、他の本も早く読める という話。確かに一理ありますね。 ということで、ここでは、自己啓発書の定番書籍として「人を動かす」「7つの習慣」「思考は現実化する」他数冊が紹介されています。これら
C/C++でbool型(ブール型/boolean型)を使用する時のお話です。 C言語は言語レベルでbool型(ブール型)をもっていません。しかし、プログラミング上、bool型を定義した方が可読性が良くなることもありますので、独自にtypedefでbool型を定義して使用されている方も多いと思います。C99(1999年に制定されたC言語の第2版)ではstdbool.hが導入され、その中で_Boolが定義されていますが、これが実際に使用されているのはあまり見かけません(そもそもC99仕様をフルに活用したコードを見かけることは少ないのですが)。 今回はこのように独自定義されたbool型、及び、処理系によって用意されたbool型を用いる時の注意点について説明します。 TRUE,FALSEの値 bool型を独自定義する場合、通常TRUEとFALSEもあわせて定義します。この時問題となるのが、それらに
前回unsignedでよく陥りがちなバグについて触れました。今回はその続編で、char型での落とし穴として、いわゆる符号拡張(sign extension)と暗黙の型変換(inplicit conversion)について説明します。 次のコードの問題点はわかるでしょうか? typedef char value_t; #define INVALID 0xff /* valがINVALIDなら0、それ以外で1を返す */ int check(value_t val) { switch (val) { case INVALID: return 0; default: return 1; } 一見問題なさそうに思えますが、実際このコードをコンパイルして、valにINVALID(0xff)を指定しても1が帰ってきます。なぜでしょう? C言語のswitch分では、比較値はint型として扱われます。よっ
すっかり暑くなってエアコンが恋しい季節になってきました。この季節になると、毎年話題にあがってくるのが省エネや環境問題、エコといった話。去年はクールビズがずいぶんとはやりました(私はもともとスーツ着る機会が少ないので、伝聞状態でしたが)。今年はどうなんでしょう。 さて、環境問題というと、少し前に「環境問題はなぜウソがまかり通るのか」という本が話題になっていました。関西のTV番組 たかじんのそこまで言って委員会でとりあげられたのがきっかけで、かなり売れたようです。その内容は、官主導のリサイクル運動が隠してきた非効率性と利益誘導の実態をあばくというもの。例えば、 地球が温暖化しても、海の水位は上昇しない 猛毒に仕立て上げられたダイオキシン 回収されたペットボトルはほとんどがリサイクルされていない 等など。実際に読んではいませんが、TVやレビュー記事なんかをみると衝撃の内容。聞いたことのある話もあ
実に久々の記事です (^^;)。今回はバグ修正のリスクについて書いてみます。 医療用語には「対症療法」と「原因療法」という言葉があります。表面的な症状の消失あるいは緩和を主目的とするのが「対症療法」、症状の原因となる疾患そのものを制御する治療が「原因療法」です。 完全回復や再発防止のためには原因療法が必要になりますが、事情によりそれがとれない時に対症療法がとられます。 対症療法を選択する理由はいくつかパターンがあります。そのひとつは、症状の原因が不明な場合。この場合、分かっているのは症状のみですから、対症療法以外すべがありません。原因はわかっていても有効な対策がわからない場合も同じです。風邪薬なんていうのはそうですね。 もうひとつのパターンは、原因療法に伴うコストやリスクが大きいた場合。手術をするにもお金がかかりすぎるとか、体力がもたないとかいう場合がそうです。その他、原因療法を施す前の応
「ファイルが添付されてませんが。。」 メールの添付忘れは嫌なものです。私も時々しでかしていましたが、最近特に連続したので、今更ながら対策を考え始めました (^^;)。 「添付ファイル忘れ・・・を防ぐために身につけたい習慣 | POP * POP」の記事にあるように忘れないような手順を習慣化するというのもあるでしょうが、やっぱりミスはあるのでそこはツールで防ぎたい。ということで、まず簡単に思いつくのは、メールの内容に「添付」等の文字列があるのに、添付ファイルがない場合、送信時に警告する方法。単純な話ですし、誰かが作ってそうです。 ということでちょこっとググると、やっぱりありました。方式もまさに前述の通り。考えることはみんな一緒ですね (^^)。 いろんなメーラ毎に用意されているようですので紹介しておきます。 Becky! 添付忘れ防止プラグイン for Becky!2 BkAppendFil
次のページ
このページを最初にブックマークしてみませんか?
『職業としてのプログラミング』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く