2010/02/11
文字列リテラルの連結
■ Rubyって文字リテラルを二つ連続で書くと連結されるの? 知らんかった。おかげでバグの理由がわからず悩んだよ。 ["hoge" "fuga"] => ["hogefuga"]
□ @emeitch C/C++もそうですね
■ @fistfvck なんと。これは誰にとって嬉しい仕様なんですかね?
■ 文字リテラル連結はpythonでもできる。perlやjavascript(spidermonkey)ではできなかった。ほとんどではないけど、いくつかの言語処理系ではできるので、それなりに一般的な文法なんだなぁ。
■ あ、scheme(gauche)でも当然できなかったよ。まぁ、Lisp系言語でやられたら困るんだけど。
いくつかメリットを考えてみた。
- 文字列リテラル中に(無視される)改行+インデントが自由に入れられない言語では、長ーい
リテラルを書こうとするとソースの横幅が伸びちゃう。ソースを80カラムに
納めたくて、かつ実行時に文字列連結をやりたくない場合に、
リテラル連結があれば自由に改行してかつインデントを揃えることができる。
const char *long_string = "Lorem ipsum dolor sit amet, consectetur adipisicing " "elit, sed do eiusmod tempor incididunt ut labore " "et dolore magna aliqua. Ut enim ad minim veniam, " "quis nostrud exercitation ullamco laboris nisi ut " "aliquip ex ea commodo consequat.";(Cで'\'を入れてつなげた場合、2行目以降がインデントできない (空白文字がリテラルに 入っちゃう)。 - マクロが貧弱で、マクロ内で文字列連結処理ができない場合。
#define DEFGREETING(var) \ const char *var = "Hello, " #var "." DEFGREETING(Shiro);
- もともと、連接する式が文字列の連結演算ってセマンティクスになってる場合 (そういう言語があった気がするけど忘れちゃった。) リテラルでなくても文字列を生成する式を並べておけば、実行時に連結される。 たまたまそれが全部リテラルであった場合は、 最適化として実行前に連結されるってだけ。
第一点について。 Schemeの場合、無視される改行+インデントはR6RSで書けるようになった (Gaucheも対応済)。
(define *long-string*
"Lorem ipsum dolor sit amet, consectetur adipisicing \
elit, sed do eiusmod tempor incididunt ut labore \
et dolore magna aliqua. Ut enim ad minim veniam, \
quis nostrud exercitation ullamco laboris nisi ut \
aliquip ex ea commodo consequat.")
CommonLispの場合、案外文字列リテラルの機能は貧弱なんだけど、 format使うと無視される改行+インデントを埋め込める。まともな処理系なら これは単なるリテラルに展開されるはず。
(defparameter *long-string*
(format nil
"Lorem ipsum dolor sit amet, consectetur adipisicing ~
elit, sed do eiusmod tempor incididunt ut labore ~
et dolore magna aliqua. Ut enim ad minim veniam, ~
quis nostrud exercitation ullamco laboris nisi ut ~
aliquip ex ea commodo consequat."))
ただこのCLの方法は、このformatフォームを別のリテラル (quoteされた リスト内とか)に自由に入れられないという欠点がある。`(... ,(format ...) ...) とかすればできなくはないけれど、透明でないのがいやな感じ。 マクロを利用してリテラル同士をくっつけるという解も同じ欠点がある。 (透明でない、とは、それまで単なるクオートされたリテラルだった 構造の一部をこの形式に置き換えた時に、その場所のローカルな変更だけでなく リテラルの外側にあるクオートも変更しないとだめ、ということ)。
第二点についてはLisp/Schemeではマクロ展開時に好きなだけ 文字列連結できるので問題ではない。
第三点については、Lisp/Schemeの文法と両立しない。
なのでLisp/Schemeに取り込むメリットはないけれど、言語の機能によっては メリットがあるだろう、と思う。実際C/C++では自分もよく利用するし。
Tag: Programming
2010/02/07
らむ太と変身
最近のらむ太は戦隊ヒーローものとか合体変身ロボットものに夢中で、 毎日毎日、各種仮面ライダーとかシンケンジャーとかレスキューファイアーとか スパイダーマンとかトランスフォーマーなどに変身し、 大人には見えない敵と戦うのに大忙しである。
ところでらむ太世界においては、何故か長ズボンを履いてないと 変身できないことになっているらしい。より正確には膝が隠れる長さでないと 駄目らしい。短いのを履かせようとすると
「『ひざかくれる』はく〜」
と泣いて嫌がる。
それでも洗濯の都合でどうしても短パンを履かなければならない時は、
「へんしんできなくなった…」
と言って見るからに落ち込んでいる。
しばらくして静かになったので覗いてみると、 熱心に仮面ライダーのベルトだのレスキューファイアーの剣みたいのだのを 作っていて、次の変身に備えているのであった。
Tag: 生活
2010/02/01
プログラマもいろいろ
業務の一環として文章を書く人が全て文筆家ではないように、 コードを書く人をひとくくりに「プログラマ」とまとめることに 無理があるのかも。
「日々の学習や訓練と仕事が切り離せない」というのがこの話の要点のひとつだが、これはプログラマに限らず、デザイナーや建築家、文筆業、料理人、役者など、「プロフェッショナル」と呼ばれる専門的な職業のほとんどにあてはまるだろう。
今やってる仕事にはフリーランスのソフトウェアコンサルタント (という肩書きのノマド的プログラマ)が数人参加してて私もその一人。 こんな具合に、あるプロジェクトに向けて専門家をえいやと集めて 短期集中でものを作るのは、確かに映画製作とか芝居のプロデュース公演に似ている。
地理的にヨーロッパ、米国両海岸、ハワイと分散してるため、 テレカンファレンスのために朝5:30に起きるのは億劫だけど、 仕事自体はやりやすい。みんな自律的に自分の役割を見つけたり 調整したりすることに慣れてるので。そのへんも映画や芝居の感覚と似ている。 (そういえば、業界界隈では一過性のプロジェクトのことを"gig"と言うことがある。 "I was in Boston that summer for a Lisp gig." とか。)
ただコンピュータソフトウェアは、映画や芝居と違って継続的に手をかける必要があり、 「できました、はい解散」というだけでは済まない。 一発もののソフトウェア (ビデオゲームとか) でもなければ、 誰かが製品やサービスのライフサイクルを見届ける必要があり、 その誰かはやっぱりプログラミングが出来ないとならないだろう。
つまり「特定の技術の専門家としてのプログラマ」ばかりがプログラマではない。 ある製品なりサービスなりを組み上げて手をかけて行くのが仕事で、 その手段としてプログラムをしている、というプログラマもいるはずだ。 現実には後者の方が圧倒的に多いだろう。 役者や文筆業に例えられる「技能でもって独り立ちしているプロ」というのは 前者のプログラマにはよく当てはまるけれど、 後者のプログラマに当てはめても良いものだろうか。
例えが微妙だけれど、法学部を出ても弁護士になる人もいれば企業の法務部に 勤める人もいる。どちらも法律を扱うけれど、仕事で求められることも キャリアパスもかなり違う。一般的には別の職業とみなされるんじゃなかろうか。 同様に、共通するのはプログラムを書くということだけで、 仕事内容もキャリアパスも異なる別の職業が、今は「プログラマ」といっしょくたに されているのかもしれない。
(追記2010/02/03 01:31:17 UTC): このエントリでは「プログラマ」と呼ばれる人々のうち、 特定の技術を武器にプロジェクトを渡り歩くノマド的プログラマというカテゴリを 設定してみたが、そうではないプログラマ ("後者のプログラマ") にも 様々な業態が考えられるのでひとくくりにできるものではない。ノマド的 プログラマに含まれないプログラマとしては、例えば以下のような カテゴリがあり得るだろう。
- いわゆる日本の「システム・エンジニア」で、 システムデザインやインテグレーションと同時にコードも書く人。
- Web2.0系のトッププログラマだけれど、 特定の技術そのものの追求よりはサービスの提供にコミットする人。
- プログラミング専業じゃないけれど、職場の効率化のために Excelのマクロとかイントラネットのcgiを書いてる人。
このうち、「Web2.0系のトッププログラマ」については 24x7で努力が求められる「独り立ちするプロフェッショナル」という パスがあるかもしれない。ただ、そのキャリアパスはどっちかというと 「技術もわかるプロデューサ」的なポジション (肩書きはVP of Technologyとか CTO) につながるもので、プログラミング技術を提供して渡り歩く ノマド的プログラマとは若干違うものになると思う。
3番目のカテゴリについては、現在ではこういう「片手間プログラミング」が 正当な業務の一環として扱われてないきらいがあると思うのだけれど、 「高レイヤでプログラムを書くこと」が「論理的な文章を書くこと」くらいまで 一般的なリテラシーとみなされる時代が来れば、 「業務の一環としてプログラム書いてます」ってのが普通になってくるだろうし、 そうなると業務システムの開発も、システムインテグレータが全部作るんじゃなくて、 ユーザ側で書ける人がカスタマイズに参加する形になってくかもしれない。
ともかく、「プログラムを業務の一環として書く人」のうち、 プロフェッショナルとして公私別無く研鑽を積まなくちゃならないって人は 特定のキャリアパスを目指す一部の人たちだけだろう、というのが要点。 今現在、そうなってない (将来独り立ちする技術者になるつもりは無いのに、 四六時中学習することを求められる) のは、コンピュータエンジニアリングが 未成熟だからだ。これについては項を改めて書くかもしれない。
Tag: Career
2010/01/31
発言する必要がないなら出なくて良い
渡辺千賀さんの仕事のプロになりたかったら - 会議でわからないことがあったら、その場で必ず聞く。これは徹底して欲しいあるですよ。を受けてのこの記事を読んで：
でも、アメリカだと、他の方に敬意を示して喋らないでいると・・・バカだと思われます。それか、使えないヤツだと思われます。次から、きっと、会議には呼ばれなくなるでしょう。
発言して、議論に何かバリューを与えられるからこそ、会議に呼ばれます。何も発言しないんだったら、そんな人、会議に呼ぶ必要はない、となります。
だから、会議では発言し、存在感を示す必要があります。そうしないと、会議に呼ばれなくなるので。
「呼ばれなくなる」と言うと切り捨てられるみたいで怖ろしげだけど、 会議というものは全体が回る限りにおいては少なければ少ないほど良いので、 発言する必要が本当に無いのなら、呼ばれなくなる前にこちらから 「意味が無いので次から出なくていいですか。」と言えば良いのである。 実際、「とりあえず関係ありそうな人集めてみましたミーティング第一回」の後で、 「Do I need to attend further? It seems that I'm no use here.」 みたいに断って出なくなる人、普通にいる。 会社としても会議するためじゃなく業務を遂行するために雇ってるわけだし、 本人としても無駄な時間を取られずに仕事に集中できるわけだし、損する人はいない。
というのはまあ上のエントリの著者の意図とは違うツッコミなんだけど、 でも根本は同じだと思うんだよね。アメリカは何も、ごりごり自己主張しないと 蹴落とされるサバイバル世界ってわけじゃなくて (まあ主張しなきゃならない 時には主張しないとまずいけど)、自分がやるべきことやらなくちゃ ならないこと、相手がやるべきことやらなくちゃならないこと、どちらも尊重したら、 無駄な会議に時間を使わないっていうのは自然な帰結のひとつだってだけ。 この論理のフレームでは「発言して議論に貢献する」とか、 「わかるまで質問して完全に理解する」ことこそが、参加者全員への敬意の 表明になるわけだ。
なので、「こんなこと聞いたら失礼なんじゃないか、邪魔なんじゃないか」と 思っていたら、フレームをいちど掛け替えてみるといい。聞かないことが失礼に あたるのだとね。
さて、それを頭で理解したとしても、いざ発言したい何かが頭の隅にひらめいた時、 そこからうまい具合に質問にまとめてうまいタイミングで発言する、 というのは難しい。会議で発言するというのは身体動作を伴うアクションであって、 キャッチボールや球技のパスと同様、練習しないとうまくできないものなのだ。 (頭の中でヴァーチャルに発言してみるだけじゃだめ。 イメージトレーニングはリアルのトレーニングが伴ってこそ役に立つ。)
学生さんなら、練習の機会はたくさんある。私の大学院時代、毎週一回、 専攻の院生(修士、博士)必修の輪講というのがあったのだけれど、 修士の途中くらいから、毎回必ず一回何か質問すると決めて実行していた。 これはすばらしい練習効果があるのでここ読んでる学生さんはやってみると良い。 何より、質問するつもりで聞いてると集中して聞ける。 (もちろん、参加者全員が質問する時間は普通はないので、やったもん勝ちである。 今でも学生の気質が変わらなければ、多分質問時間は余りまくっているはずなので、 先着2-3名の余裕はあるだろう。それ以上質問が出るようなことになったら それは大学院輪講としても大変結構なことであるので、運営の方で うまい方法を考えるだろうから(当て方を工夫するとか)、心配しなくてよい。)
仕事をしてる人でも、まあ社運を賭けた製品の戦略ミーティング、みたいに 緊迫した場面じゃさすがに練習はできないだろうけれど、もっとゆるい ミーティングはあるはずなので、その場を練習に使うといいと思う。 ただ、気の置けない仲間内、っていうのはだめ。 たまに、質問に立ったはいいがだらだらとまとまりのない話をしだす人が いるけれど、そういうのに対して「要するに質問は何?」というツッコミが 入るような場じゃないと練習にならない。突っ込まれることは落第点を もらうことではなく、キャッチボールのボールを投げてくれたってことだから、 受け取って次に活かせばいい。
Tag: Career
2010/01/31
それはプロデューサの仕事では
で、たけくまさんのエントリ
で、「落とし前機関としての出版社」という話になっているのだけど、私が出版社を必要だなと思う理由はもう1つある。それは、
書け圧力
としてだ。
[...(中略)...]
「金になる」ってのも大事で、これはつまり「売れそうなもの」という意味だ。自分が知っていることであっても、自分で書きたいと思わなければ書くことはない。でも、世間でそういった需要があるということがわかれば、「金のため」とゆー理由で書ける。とゆーか、自分の持っている知識の需要なんてのは、自分ではよくわからなかったりする。「こんな本書けません？」とか聞かれると、「あー、それ何とかなるかも」と考えることが出来る。
誰に何を作らせたら需要があるかを見極めて、 その誰かに製作を依頼し、その進捗を管理するっていうのは 映画や演劇や音楽やゲームではプロデューサと呼ばれる役割だと思う。
それで出来上がった作品を宣伝して流通に乗っけるのが パブリッシャー。
プロデューサはパブリッシャーから来ることもあるけれど、 必ずしもそうでなくてもいい。映画やゲームではプロデュース 機能を提供する主体(プロダクション)とパブリッシャーは別々のことも多いのでは。
プロダクションとパブリッシャーが分かれている場合、 一般消費者の目に触れるのはパブリッシャーの方で、 従って何か消費者との間に問題が生じた時に表に立つのも後者。
出版社が文字通りパブリッシャーとしての役割を担うとすれば たけくまさんのエントリのように防波堤、あるいは落とし前機関としての 役割は残るだろう。けれども、制作体制が分業化してゆくとすれば、 「書け圧力」を担うのは出版社とは 独立したプロデューサだとかプロダクションに なってゆくってことはあるんじゃないかなあ。 編集者っていうのもそのカテゴリに入って行くのだと思う。
Tag: ものつくり
Comments (4)