費用は自分持ちでもいいから、会社側で一括した名刺のデザインとレイアウトがあって、名前だけ業者に伝えれば一週間後くらいに届くっていう普通の名刺システムになってくれないかなぁ*1。人によって名刺の出来具合がさっぱり違うんですけど。それはロゴの管理とかそういった観点からも望ましくはあるまい。updateこちらをCVSに追従させてみました。設定変わってるので、もしかすると所々エラーになってるかもしれません。教えていただければ幸いです(これは一応更新のテスト投稿)。プラグイン周りの実装がずいぶんしっかりしててびっくり。楽しくやってるのでまぁよし。アップデートに伴うエラー発生などでずいぶん時間がかかってしまい、気が付いたらもうこんな時間。寝るべきか起きておくべきか...。夜が大変になるから寝ておくか。:フォントを作るにはお金と時間、そして大変な手間と労力がかかるそのため、本来購入して使うものである無料なのが異常と考えるべきそれを無料で配布されているのは、個人作者の場合は好意に他ならないフォント会社の場合は、宣伝や試用といった意味合いも含まれるフォントの場合は「フリー」という言葉は即ち「無料」という意味に成り下がってしまうのでしょうか?プログラム・アプリケーションなどのソフトウェアでこのような話をされると多少の違和感を感じるのに、フォントだとそれらしく聞こえてしまいますね。個人が好意で作ったからフリー(無料)なんでしょうか。他ならないんでしょうか。今はフリーウェアなんて言い方をせずにオープンソースとかオープンウェアといったほうがピンと来るのですが。一世代前に議論され終わったような話のような気がするのですが、とあるフォント系のメールマガジンで上記サイトが紹介されてて「え、今さら?」という感じがしたもので。当時流行った議論として「ディープリンクの可否」というのがありましたが、そちらは認めつつも「フリーウェア=個人の好意」としているあたりのギャップに違和感があるんでしょうか。(追記)たぶん違和感の根本的な原因は、根拠を精神論に求めていて、恩着せがましいところにあるんでしょう。そもそも「フォントは有料なのが当たり前」というのには賛同しかねる。「こちとらフォントが生業なんでい」と言われれば「あぁそうなんだ」と思うのに、「フォント作るのには金かかるのにそれをタダで恵んでやっている」という恩着せのようなものを感じるからなんでしょうかね。翻って、オープンソースなどが今のところうまく機能しているようにみえるのは、様々な開発のバックグラウンドはあれ、妥協点として「フリーはフリー。好きなように使え」としか言っていないことなんだろう。GNUライセンスなどの唯一の強制は「フリーはフリーとして使え、オープンソースなものを使ったらその派生プロダクトもオープンソースにしろ」っていうことだけであって、オープンソースとは関係のない金銭面での強要をしていないからなんだろう。時計の長針と短針は、12時にちょうどピッタリと重なります。次にピッタリと重なるのは何時でしょう。引用]まぁ12時間に11回...というのは発見的手法による部分が大きいような気がするので、ここは順当に。なるような時刻に、長針と短針は重なる、ということになる。12時の次は1時5分27秒2727...に長針と短針が重なるらしい。算数的には上の式でOKなんでしょうが、実際の時計を考えてみると、27秒2727...という循環小数で表現されるような時刻が表現されることはありません。スムーズ秒針タイプではない従来の時計であれば秒単位でチクタクと動くので、5分27秒から5分28秒に切り替わる瞬間に一瞬で追い越すことになります。時[6n/1.1]分[(6n/1.1-[6n/1.1])*60+1-δ]秒と答えるべきかもしれません。毎秒に長針と短針が一瞬で位置を変えるとしたら、12時の次に長針と短針が重なるのは24時(≒0時)ということになります。引用元の「エレガントな解法」にはこういう考察までを含めても良いでしょう。パズル的に考えれば12時間に11回重なるから...という「一見エレガントっぽい解法」を思いつきますが、「12時間に11回重なる」という仮定がそもそも正しいかどうか検証しないまま計算を始めて、結局解法がキレイすぎるのに満足してしまう人が多いから「実際には重ならないじゃん」というバグにぶつかるかもしれません。あとは、「12時間に12回重なるんじゃないの?」とか疑問を持ち始めると困るねぇ、とか。いう問題は、愚直な方法かもしれませんが、いったんシンプルな方法で考えたほうが、いろいろ可能性を考えられるような気がします。余談ですが、書いててアキレスと亀を思い出した。実は長針と短針って永遠に重ならないんじゃ...?(追記)要するに、あとから簡単に検証できるような(=説明が容易な)思考のプロセスを日頃から心がけないとデバッグが大変になるし、与えられた条件にぴったりな無駄のない解法を追い求めすぎると「ちょっとした変更」に耐えきれないロジックになりやすいと思います。ソース中のコメントを読んでも頭をひねらないと理解できないようなパズルのようなプログラムをたまに見かけますが、それはやっぱり自分の趣味で作るものならともかく、仕事やオープンソースなど複数人で仕事をする上では避けるべきでしょう。多少の動作効率の悪さを犠牲にしてでも簡素さによる開発効率の向上をとったほうが良いと思うのです。(追記2)調子に乗って問題2も同じアプローチをやってみる。サイコロを2個、順番に投げることにします。1つ目のサイコロの目の方が2つ目のサイコロの目より大きい確率を求めてください。引用]これは言葉で説明するのは面倒なので、実際にCっぽく。EXIT_SUCCESS;}これも基本は愚直に。確かに単純な計算より効率は悪い。その代わり、絶対に漏れがない。確率計算を正しく理解してなくても、これなら間違いようがない。いうのがプログラマ的エレガンスだと思うんですがね。ちなみにプログラマ的テクニックであれば、賽子オブジェクトを作ったりとか、モンテカルロ的手法とか、Mathematicaみたいなのを一から作ってみるとかまぁいろいろ思いつくのですが、今回求められているのはエレガンスですからね。[数学的で、わかりやすい、一番良い回答だと思います。時間と分で2つ変数を定義する発想が目からウロコでした。このサイトの管理人の高校時代の先輩です。[コメントありがとうございます。