« 2010年12月 | トップページ | 2011年2月 »

2011年1月の4件の投稿

2011/01/30

Excelをバージョン管理するための基礎知識

はじめに

Excel(.xls; Excel97-2003ブック形式)ファイルをSubversionなどのバージョン管理システム(VCS,RCSとも)で管理することはしばしば発生する状況であると思います。

私も以前からCVSやSubversion(SVN)でExcelファイルのバージョン管理を行っており、うまく動作していると考えていました。

しかし、Bazaar(BZR)を利用する機会があった際に従来と同様の使い方をすると正しく動作していないように見える事態が発生し、当時のことをまとめるために本エントリを起こしました。

今回試してみた環境は以下の通りです。

  • Windows7 x64
  • Excel2010
  • TortoiseSVN 1.6.12, Build 20536 - 64 Bit
  • bzr-2.2.2
  • Git-1.7.3.1-preview20101002
  • mercurial-1.7.3-1-x64

 

結論

最初に結論を書いておきます。以下の2点のうちいずれかの対応を採れば上記いずれのVCSでも正しく管理できるでしょう。

  • .xlsx形式でファイルを作成、管理する。
  • .xls形式を使用する場合、ファイルから個人情報を削除しておいたものをバージョン管理対象とする。

.xlsファイルから個人情報を削除する手順はExcelのバージョンによって異なりますが、Microsoftのサイトにまとまっています…と思ったらリンクに誤りがあったりで参考にならないので以下に記載します。

  • Excel2010
    ファイル > 情報 > 共有準備の問題のチェック > ドキュメントの検査 で「ドキュメントのプロパティと個人情報」を削除
  • Excel2007
    Microsoft Officeボタン > 配布準備 > ドキュメント検査 で「ドキュメントのプロパティと個人情報」を削除
  • Excel2003, Excel2002(XP), Excel2000
    ツール > オプション > セキュリティタブ > 「保存時にファイルのプロパティから個人情報を削除する」にチェック

(これ未満のバージョンや、MacのOffice2004もExcel2003と同様の手順のようですが、Microsoftのサイトでは見つけることができませんでした。)

私はExcel2010でしか試せていませんが、methaneさんがExcel2003でもうまくいくことを試していらっしゃいます。

 

上記ファイルをテンプレート(.xlt)にするなどして、新しいドキュメント作成時にはこれを用いることで、.xlsを正しくバージョン管理できるようになります。

 

問題点

Excelアプリケーションは、書き込み権限のある.xlsファイルを開くたび個人情報を更新するため、ユーザが明示的に保存を行わなくてもファイルが変更されてしまいます(.xlsx形式ではそのようなことはないようです。また当然と言えば当然ですが、OpenOffice.orgなどでは.xlsファイルを開いただけでファイルが更新されることもありません)。

つまり、.xlsファイルを開いただけでバージョン管理しているファイルと差異が出てしまい、本来行いたい管理ができなくなる、というのが.xlsファイルを扱う際の問題点といえます。

 

SVN(やCVS)ではこの問題が表面化することはまれでした(せいぜい、ファイルを開いている最中にstatusコマンドを実行すると変更が検知される程度で、これも保存せずに閉じると未編集状態に戻ってしまいます)。

これは、SVN(やCVS)は、ファイルのタイムスタンプが変わっていなければ未編集であるとみなしているためです。

 

前述の通り、Excelアプリケーションは保存を行わなくてもファイルを変更しますが、この際タイムスタンプを開く前の状態に書き戻します。この挙動のためバージョン管理システムはファイルが変更されていないと誤解する状況が生まれます。

(この問題は、よくSambaで共有しているExcelファイルを開いただけでタイムスタンプが変わってしまう、という問題で取り上げられます[参考]が、本来タイムスタンプが変わるのは正常だ、ということになります。)

 

一方、BZR,HG,GITは、ファイル自身の比較を行うため、タイムスタンプに騙されず、開いただけの.xlsファイルでも正しく「変更された」と判断します。このため、「SVN/CVSではうまくいっていたのにBZR/HG/GITだとダメだ」という状況になります。

(BZR,HG,GITもタイムスタンプで判断する場合があるので、騙される条件もあります。また、この3種を試したところ、BZRと他2種とでは騙される条件が若干異なるように見えました(BZRの方がより厳密?)。)

 

この問題の解決策として、「結論」に記載した通り個人情報を削除し保存しないようにすることが挙げられます。一度.xlsファイルから個人情報を削除すると、次回以降ファイルを開いたり保存した場合でも個人情報が保存されることがなくなるようです。従って、そのファイルに対してはユーザが明示的に保存操作を行った場合にのみファイルが変更されるようになり、ユーザの想定通りバージョン管理ができるようになります。

 

参考

Google Reader Full Feedが遅い

Google ChromeのExtension “Google Reader Full Feed”を長い期間利用させてもらっているのですが、何か月前からかなり動作が重く、「ページ応答なし」のダイアログも頻繁に出るようになりました。

今までこの状態を放っておいたのですが、今回たまたま調べたところ、セキュリティ上の問題による対応で動作が重くなっているそうです。

というのが対応の元となるセキュリティリスクだそうです。クロスサイトスクリプティング(XSS)的なものだろう、というのは想像つくのですが、残念ながらちゃんとは理解できていません…

件のGoogle Reader Full Feedにおいては、ver.0.1.1Google Caja(参考), html-sanitizer.jsのhtml_sanitizeを利用することで対応されているようですが、どうやらこの処理がかなり重いようで、結果としてこのExtensionの動作もこれに引き摺られているようです。

(html_sanitizeを呼んでいるのは”Fetching full story : Done”というメッセージを出力した後のようですが、実際にGoogle Chromeが固まるのは”Fetching full story : ...”のメッセージ中なのが気になるところではありますが、ウィンドウへのメッセージ表示がメソッドコールと同期しないのはフレームワークの仕組み上よくあることなので、Google Chromeもそうなのでしょう、というところで納得しておきます)

 

実は最近、FirefoxのAddon “Google Reader Full Feed Mod”も利用するようになり、こちらは動作速いなあ、と思っていたのですが、こちらも一旦は上記の対応を入れたそうですが重いため取りやめたそうです。

どちらを選択するかはユーザ次第…というところでしょうか。

2011/01/03

[読書]彼女と二人で「C」体験!にあえてツッコむv2.0

 

副題は”絶頂ポリモーフィズム”。今回もストーリーにはなるべく触れないようにしていますが、終盤のギミックに関わっているのでネタバレありです。ちなみに前回はこちら

 

コンピュータ対戦プログラミングについてよくは知らないのですが、

  • プレイヤ(チーム)ごとに1つのクライアントがあって、自分のユニット(駒)に命令を出すために用いる。
  • それぞれのプレイヤの命令は1つのサーバに集められ、1ターンごとに各プレイヤの命令を集計し、結果をそれぞれのプレイヤに返す。

みたいな感じでしょうか。あと、

あたりを見ると、

  • プレイヤは命令を事前に設定された規約に従った文字列(プロトコル、あるいはもうちょっと明確にした「電文(業界用語)」と呼ぶのが適切ですかね)に変換した上でサーバに送る。

というのも共通的なものでしょうか。

上記3つのゲームでは、各プレイヤの操作するユニットは同性能ですが、本劇では基本性能もカスタマイズできるようなので、どちらかというとRobocodeみたなものをイメージするのが良さそうです。

 

さて本題です。

p.98

[前略]プログラムはワンステップずつ処理される。たった一行のコードで、すべての兵士オブジェクトに対し、そんな命令が下せるものなのか―。
この大会では、セミコロンまでの一処理を一ステップまで扱っている。たとえば、
int i;
i = 5;
これで二行。二ステップだ。

少し前(p.85)でも説明は出ていますが、ここではもう少し具体的な記述になっています。ソースコードそのものが性能に寄与するという点では、冒頭で挙げた実際のゲームいずれとも異なります。切れ負けルールのあるコンピュータ将棋なんかだと、演算性能の高いクライアントで参加する方が相対的に有利になりますが、このルールだと純粋にアルゴリズム勝負になります…かね。前後半合わせて600ターン(p.85参照)なので、かなり厳しいルールだと思います。

ここでのステップの説明はWikipediaの論理LOCにもう少し詳しく書かれています。サーバがステップを認識できるということは、クライアントからサーバに送信するデータは、冒頭に記載したような単純な命令文字列とは異なります。また、コンパイルエラーなどの場面も登場することから、劇中のC/C++は実世界同様(インタプリタ言語ではなく)コンパイラ言語ということがわかります。プレイヤプログラムはソースコードの状態でサーバへ送信し、サーバ上でデバッグ情報をつけて最適化なしでコンパイル・実行する、みたいな…?

 

p.218

同じ名前のメソッドを、他のクラスと被ってなお、いくつでも作成できる。むしろ、同じ意味を持つものなら、同じ名前を付けるべき―。
多態性(ポリモーフィズム)。
それが保証されているC++言語だからこそ、やりえた作戦だ。

なんかグローバル関数とメンバ関数の対比、ひいてはCとC++の対比のような表現になっていますがそれはともかく。

劇中では、多態性を利用して、一方のクラスインスタンスを他方のクラスインスタンスに見せかけています。

C++などの静的型付け言語(p.123参照)での多態性は、一般的には共通の基底クラスへアップキャストすることで実現します。しかし、ここでは、それぞれのクラスが共通の基底クラスを持たず、単純に同名の関数を持っているだけです。従って、これは継承による多態性の実現ではなく、ダックタイピングによる多態性の実現です。

  • C++でダックタイピングを行おうとした場合、あらかじめ型がわかっていないとコンパイルできない(リフレクションを備えている言語であればこの限りではありませんが…)。継承によって多態性を実現していたとしても、共通の基底クラスは相手チームローカルな情報であって自チームには知らされていないため、この場合も判断は不可能でしょう。
  • ダックタイピングとは、Wikipediaにあるとおり、歩かせてみて鳴かせてみて初めてアヒルとわかるものであり、行動を起こす前(劇中の表現を用いると相手が反応する前、すなわちこちらが攻撃行動をとる前)にアヒルであると判断することは不可能です。

ちなみに、戦況を映すスクリーン上では、異なるクラスのインスタンスであるユニットはそれぞれ別物であると認識できています(p.214参照)ので、サーバへは実行時型情報のようなものを通知するようになっているのかもしれません。

 

p.231

『0x335afc』
[中略]
「”デマゴゴス”の本体アドレスですっ!」
[中略]
一騎の”ヘタイロイ”が、何もないマスに向かって突撃する。[後略]

普通に考えると、アドレス、というのはフィールドの座標のことでしょうか。かなり広大なフィールドに思えますが、0番地から始まっているとは限りませんし、冒頭に示した高専プログラミングコンテスト募集要項中「フィールドのセル番号」にあるように、無効番地がある可能性もありますね。

 

p.32

“『第二十二回プログラミング甲子園』、開会式を行います―”

p.151

「あたしの意見じゃないわよ」
「誰だよ」
「坂本龍馬」

「二十二回」「坂本龍馬」というのは第21回高専プログラミングコンテストへのオマージュでしょうか。

p.118

int nAction = nGetAction();

if (nAction == OPARATION_ATTAK)

{

この定数”OPARATION_ATTAK”は大会主催者が提供しているライブラリで定義しているものでしょうか。これも同コンテスト決勝戦 procon21-08.wmv の映像13分ごろ「異常ではない」のオマージュですね(補足しておくと、実際のプロコンの方はバグだったようです(同映像42分ごろ))。他ではp.231,p.258で英字の誤字を見つけました。

 

 

One More Thing:

「彼女と二人で」の英語表現が”by she and two people”(p.4参照)になってますが、これって多態的にヤバくないでしょうか…

(追記: これはexcite翻訳(powered by BizLingo)の仕業ですね)

最終回 SEの年収(2011年版)

 

2011年版と銘打ちながら、追加した情報は2009年のものなのですが。

2010年版は書いていないので、2009年版の続編になります。

所属年数 税引前給与(万円)
1 306
2 452
3 512
4 665
5 687
6 700
7 504
(8) (341)

 

salary2011

 

何点か補足を。

以前記載した通り、2009年途中で離職したため、7年目の年収は1年フルのものではありません。転職サイト/転職エージェントに申告する際に試算した最終年の年収相当は確か755万円だったと思いますので、年換算すると6年目を超えています。

タイトルに「最終回」としているのは、私自身が会社員ではなくなったため、blogに記録する役割は終わったかな、と判断したためです。

8年目のものは、参考として、昨年後半よりフリーランスとして活動した際の売り上げ(年商であって年収相当ではありません)を記載しています。年収と比較するものどうかと思いますが、開業月以降を年換算すると取り敢えずは7年目を超えることができました(取らぬ狸の…)。

 

以前転職活動を行っていたとき、面接官から「なぜblogで年収を公表しているのか」という質問を受けたことがあります。確かに、読み返すと意図が明確では無いかな、と思い、当時の回答を記載しておきます。

Web上では、SIer/SE/プログラマというような職業はいわゆるブラックとしてかなり悪いイメージがついてしまっているのではないかと思います。しかし、実際は必ずしもそうではない、ということを簡潔に守秘義務に抵触しない形で説明できるものはないかと考え、年収の公表という形に至りました。なぜブラックのイメージが付くと問題なのかというと、優秀な人材が入ってこなくなり、結果として、私の所属していたプロジェクトや、私自身が次のステージに進めなくなると危惧していたからです。

ついでにもう少し前職の情報を。

  • 私自身は博士前期課程修了(修士卒)の新卒入社。情報工学系。
  • 所属先はPublickeyさんの分類でいうと”SIer/システム開発”に属します。世間一般で言うとユーザー系情報システム子会社…になるんでしょうか。
  • 残業時間はかなり抑え目に申告していましたので、聞くところによると同期の年収はもうちょっと高かった…?

 

そんなわけで、現在フリーランスとして活動しております。お仕事のお誘いなどありましたら、本ページ右上にメールリンクなどありますので声をかけて頂ければと思います。

それでは、今年一年も宜しくお願い致します。

« 2010年12月 | トップページ | 2011年2月 »

other sites

  • follow us in feedly
  • github
  • stackoverflow

ソフトウェアエンジニアとして影響を受けた書籍

  • Christain Bauer: HIBERNATE イン アクション

    Christain Bauer: HIBERNATE イン アクション
    理論と実践が双方とも素晴らしい製品であるHibernate。本書はそのプロダクトを書名に冠していますが、Hibernateを使うつもりがなく、ORマッピングの解説書として読むにしても十分な良書です。Second EditionとしてJava Persistence With Hibernateという書籍も出版されていますが、残念ながら現在のところ 和訳はされていません。-インアクションは2.xの、Java Persistence-は3.1の頃のものなので、最新版とはちょっと違うところもあることに注意。 (★★★★★)

  • アンドリュー・S・タネンバウム: 分散システム 原理とパラダイム 第2版

    アンドリュー・S・タネンバウム: 分散システム 原理とパラダイム 第2版
    クライアント/サーバシステムを構築する上で必要となる知識が総論されてます。Web技術者も、フレームワーク部分を開発するのであれば必読。 (★★★★★)

  • Joel Spolsky∥著: ジョエル・オン・ソフトウェア

    Joel Spolsky∥著: ジョエル・オン・ソフトウェア
    前述の書籍「ソフトウエア開発プロフェッショナル」をより砕いたもの、という感じでしょうか。 前書きではプログラマでなくSE向けの本のように書かれているが、プログラマが読んでも面白い本であると思われます。 SEになった新人(あるいはそういう会社に入る/入りたての人)にとっては、これからどういったことが仕事を遂行していく上で起こりえるのか、どのように考えて行なっていけばいいのか決定する助けになると思います。 元は″Joel on Software″というブログの記事で、web上でも一部日本語で読めます。 http://japanese.joelonsoftware.com/ (★★★)

  • ドナルド・C・ゴース,ジェラルド・M・ワインバーグ: ライト、ついてますか

    ドナルド・C・ゴース,ジェラルド・M・ワインバーグ: ライト、ついてますか
    問題解決(一昔前のの流行語で言うところの『ソリューション』)能力は、システムエンジニアのスキルとして備えるべきもののうちのひとつです。しかし、これは難しい。学校で出されるテストと違い、唯一の、(問題提出者が想定している)解を求めるだけが「問題解決」では無いからです。そもそも、何が問題なのか、それは本当に問題なのか、それは本当に解決すべき問題なのか、その問題解決方法は正しいのか、などを解決しなければ、「その解は正しいのか」に辿りつくことができません。この本の最も良いところのひとつは、本があまり厚くないこと。すぐに読めるし、何回も読み返す気になるでしょう。 (★★★★★)

  • スティーブ・マコネル: ソフトウエア開発プロフェッショナル

    スティーブ・マコネル: ソフトウエア開発プロフェッショナル
    コードコンプリートで有名なスティーブマコネルの著書。新人SEに読んで欲しい。個人として業界の中でどうあるべきか、組織としてどうあるべきか、SEのプロ意識とは?SEの心構え概論、といったところでしょうか。また、業界における資格の重要性についても説かれています。この業界では資格が特に軽んじられる傾向がありますが、この傾向はどんな弊害をもたらすのか、将来的にこの業界は資格に対してどのような姿勢で臨んでいくべきなのか。日経BP社では(他の出版社もだが)最近、似たような類いのあまり面白くない書籍が乱出版されていますが、この本は別格だと思うので安心して購入して欲しいと思います。 (★★★★★)

無料ブログはココログ