Title

Xcode4.3にしたらFileMargeが見つからない

↓ココにあります。
/Applications/Xcode.app/Contents/Applications/FileMerge.app

XcodeのメニューのOpen Developer Toolからも起動可能。

MacOSでも@2xのついたファイルのscaleが2.0になってしまう件

MacOSX(Lion)上で、NSImage – initWithContentsOfFileで画像ファイルを読み込んだ時、ファイル名に@2xがついているとNSImage.sizeの大きさが半分になっていることがある怪現象に遭遇しました。
ルールはわかりませんが、@2xがついていても半分にならないときもあり、すごい謎。

iOSで使うUIImageならば、@2xが付いているとRetina用画像ということで解像度倍なのですが、MacOSにはRetinaという概念はないはずなので@2xというファイル名で何かが変わるのは変だと思うのですが・・・。

なお、下記のようなコードでCGImageからサイズを取得すると正しいサイズが取得できます。

+ (NSSize)getImageSize:(NSImage*)image{
    CGImageRef cgImage = [image CGImageForProposedRect:nil context:nil hints:nil];
    NSSize imageSize;
	imageSize.width = CGImageGetWidth(cgImage);
	imageSize.height = CGImageGetHeight(cgImage);
    return imageSize;
}

という事はつまり、UIImageで言うところのscaleが2.0になっている、という事なのでしょうが、NSImageにはscaleプロパティが無いのでわかりません。

噂のRetinaMacOSXへの布石なのか、ただのバグなのか、はたまた僕の理解不足なのかわかりませんが、とにかく謎です。
分かる方いらっしゃいましたら教えて下さい。

環境はMacOS SDK 10.7,MacOS Lionです。

いろいろな日付の計算(曜日・日付・日本の祝日)

カレンダーを作るにあたって必要な以下の点を考察してみます。
特に祝日の計算は日付クラスなんかを使っても出来ないことが多いので頑張りが必要です。
・日付→任意の曜日
・月が何日までか
・日本の祝日、国民の休日にあたるかどうか

まず任意の日付の曜日を得る方法。
これは簡単。有名なツェラーの公式を使います。

if (y*366+m*31+d < 1582*366+10*31+15) return -1;
return (y + y/4 - y/100 + y/400 + (13*m+8)/5 + d) % 7;

次に任意の月の最後の日(=日数)を計算する方法。
2月以外は固定なので、要するに閏年の計算になります。
閏年を4年に1度と勘違いしている場合がありますが、それだけだと誤差が蓄積するので以下のルールになっています。
1.西暦が4で割り切れる年
2.ただし、100で割り切れる場合は例外
3.ただし、400で割り切れる場合は2のルールは適用しない

int last;
switch(m){
	case 1:last = 31;break;
	case 2:
		//うるう年の算出
		if(y % 4 ==0){
			if(y % 100 == 0) {
				if(y % 400 == 0){
					last=29;		
				}else{
					last=28;
				}
			}else{
				last=29;
			}
		}else{
			last=28;
		}
		break;
	case 3:last = 31;break;
	case 4:last = 30;break;
	case 5:last = 31;break;
	case 6:last = 30;break;
	case 7:last = 31;break;
	case 8:last = 31;break;
	case 9:last = 30;break;
	case 10:last = 31;break;
	case 11:last = 30;break;
	case 12:last = 31;break;
	default: return 0;
}
return last;

最後に祝日・休日の計算方法について
今後制定される祝日については予測のしようがないので仕方が無いとして、既に制定されている祝日について考えます。

日付が固定されている祝日は楽ですが、ハッピーマンデーや振り替え休日がありますので注意が必要です。
また2007年の法律改正により、振替休日のルールが若干複雑になっています。

また、春分・秋分の日については法令としては前年になるまで確定しませんが、天文学的な春分日・秋分日と違う日になることはまず無いと推測できるので、計算により導いてみます。

以下は春分と秋分日の近似計算です。西暦1851年~2150年の間で利用できます。

//春分(3月)
int GetVernalEquinoxDay()
{

	int y = m_Systime.wYear;
	int  d;
	if(y<1851) return -1;
	else if(y < 1900){
		d = (int)(19.8277 + 0.242194 * (double)(y-1980) - ((y-1983)/4));
	}else if(y < 1980){
		d = (int)(20.8357 + 0.242194 * (double)(y-1980) - ((y-1983)/4));
	}else if(y < 2100){
		d = (int)(20.8431 + 0.242194 * (double)(y-1980) - ((y-1980)/4));
	}else if(y < 2151){
		d = (int)(21.8510 + 0.242194 * (double)(y-1980) - ((y-1980)/4));
	}else return -1;
	return d;
}

//秋分(9月)
int GetAutumnalEquinoxDay()
{

	int y = m_Systime.wYear;
	int  d;
	if(y<1851) return -1;
	else if(y < 1900){
		d = (int)(22.2588 + 0.242194 * (double)(y-1980) - ((y-1983)/4));
	}else if(y < 1980){
		d = (int)(23.2588 + 0.242194 * (double)(y-1980) - ((y-1983)/4));
	}else if(y < 2100){
		d = (int)(23.2488 + 0.242194 * (double)(y-1980) - ((y-1980)/4));
	}else if(y < 2151){
		d = (int)(24.2488 + 0.242194 * (double)(y-1980) - ((y-1980)/4));
	}else return -1;
	return d;
}

最後に祝日です。 現在と2007年の改定前の祝日を拾うようにしてみました。 これに加えて、振替休日を考慮する必要があります。 2007より前は日曜日に重なった場合は月曜日を休日に、 2007年以降は「その日後においてその日に最も近い「国民の祝日」でない日」が休日です。


int c = (d-1) / 7 + 1;
if(m==9)
	autumnalEquinoxDay =GetAutumnalEquinoxDay();
if(m==3)
	vernalEquinoxDay = GetVernalEquinoxDay();
if(m==1 && d==1){
	return DAY_NEWYEARSDAY;
}else if((y >= 1949 && y < 2000) &&  m==1 && d==15){
	//1949-1999 1月、15日
	return DAY_SEIJINNOHI;
}else if((y >= 2000) &&  m==1 && w==1 && c == 2){
	//2000~、1月、月曜日、第2
	return DAY_SEIJINNOHI;
}else if(y>= 1967 && m==2 && d==11){
	//1967~、2月、11日
	return DAY_KENKOKUKINENBI;
}else if(y>= 1949 && y<1989 && m==4 && d==29){
	//1949~1988、4月、29日
	return DAY_TENNOUTANJOBI;
}else if(y>=1989 && m==4 && d==29){
	if(y>=2007) return DAY_SHOWANOHI;
	//1989~、4月、29日
	return DAY_MIDORINOHI;
}else if(y>=1949 && m==5 && d==3){
	//1949~、5月、3日
	return DAY_KENPOUKINENBI;
}else if(y>=1986 && m==5 && d==4){
	if(y>=2007) return DAY_MIDORINOHI;
	//1986~、5月、4日
	return DAY_KOKUMINNOKYUJITU5;
}else if(y>=1949 && m==5 && d==5){
	//1949~、5月、5日
	return DAY_KODOMONOHI;
}else if(y>=1996  && y<2003  && m==7 && d==20){
	//1949~2002、7月、20日
	return DAY_UMINOHI;
}else if(y>=2003 && m==7 && w==1 &&c==3){
	//2003~、7月、月曜、第3
	return DAY_UMINOHI;
}else if(y>=1966  && y<2003  && m==9 && d==15){
	//1966~2002、9月、15日
	return DAY_KEIROUNOHI;
}else if(y>=2003 && m==9 && w==1 &&c==3){
	//2003~、9月、月曜、第3
	return DAY_KEIROUNOHI;
}else if(y>=1966  && y<2003  && m==10 && d==10){
	//1966~2002、10月、10日
	return DAY_TAIKUNOHI;
}else if(y>=2003 && m==10 && w==1 &&c==2){
	//2003~、10月、月曜、第2
	return DAY_TAIKUNOHI;
}else if(y>=1948 && m==11 && d==3){
	//1948~、11月、3日
	return DAY_BUNKANOHI;
}else if(y>=1948 && m==11 && d==23){
	//1948~、11月、23日
	return DAY_KINROUKANSYANOHI;
}else if(y>=1989 && m==12 && d==23){
	//1989~、11月、23日
	return DAY_TENNOUTANJOBI2;
}else if(y>=2003 && m==9 && GetNumOfWeek(d-1)==3 && w-1 == 1 
	&& (d+1)==m_AutumnalEquinoxDay){
	//2003~、9月、前日が第3月曜日、翌日が秋分の日
	return DAY_KOKUMINNOKYUJITU9;
}else if(m==3 && d==m_VernalEquinoxDay){
	//春分
	return DAY_SYUNBUNNOHI;
}else if(m==9 && d==autumnalEquinoxDay){
	//秋分
	return DAY_SYUUBUNNOHI;
}

ComicGlass 4.60Beta1

次バージョンでの対応予定

・表紙を手動生成したときにiPad Retina解像度にならない問題を修正
・ファイル一覧で「削除」ボタンを表示中、かってにボタンが非表示になってしまうことがある不具合を修正
・Webブラウザビューを若干変更(アップルの審査対策・・・Webブラウザ内蔵してフルアクセスができると+17にしないといけないため。通ったり突然通らなかったりでよくわからない)
・バックアップの復元中に落ちてしまうことがある問題を修正
 発生条件:バックアップするフィアルの総パス超が一定以下(9文字)以下だと発生

accelerometer:didAccelerate:がDeprecatedになっている

加速度センサを使うアプリを新たに作っています。
ふとドキュメントを見たら、accelerometer:didAccelerate:が、(Deprecated in iOS 5.0.)になっていました。

代替は手段はどうするんだろうって悩んだのでメモ。

    motionManager_ = [[CMMotionManager alloc] init];
    motionManager_.accelerometerUpdateInterval = 1.0/60.0;

    NSOperationQueue *currentQueue = [NSOperationQueue currentQueue];
    accelerationValueFirst_ = YES;

    [motionManager_ startAccelerometerUpdatesToQueue:currentQueue
            withHandler:^(CMAccelerometerData *accelerometerData, NSError *error)
    {
        CMAcceleration acceleration = accelerometerData.acceleration;

        UIAccelerationValue x = acceleration.x;
        UIAccelerationValue y = acceleration.y;
        UIAccelerationValue z = acceleration.z;
        //お好きな処理
	}

ブロックを使う方法が推奨されているようです。
・・・と思いきやbeginAnimations:context:はDeprecatedになっていませんね。

CMMotionManagerはiOS4.0から利用できるようです。

どこでもドア

夢の道具に文句つけても仕方ないのだけれど、「どこでもドアがあったらなぁ」と想像して楽しむときに、どうしても「こういう場合どうなるんだ?」と疑問になってしまう。

一番最初に気づく問題は「気圧差」。
ドアを開けた先の世界とは気圧差があり、ドアを開けた瞬間突風で吹き飛ばされるのでは? というもの。
ドアには見えないバリアみたいなのがあって、気圧差は保ったまま人間だけが通過できる、と解決案を示せないことはないが、それはそれで、あらゆる物理量の微分値が無限大になるような境界面が存在するのか、それとも緩やかに変化させる緩衝帯があるのか、いろいろと新たな疑問点がわいてくる。未来の科学でうまいこと調整しているのだろうか。

もう少し想像してみると、「位置エネルギー」が心配になってくる。
質量・エネルギー量保存の法則はおそらく宇宙の大原則で覆らない。
高い位置と低い位置をどこでもドアで繋いだら永久機関が出来てしまう。
この問題はエネルギーの増減をどこでもドア側で吸収するような仕組みがあると考えるのが妥当だろう。
どんなエネルギー源で動作しているのか不明だが、低い位置から高い位置にどこでもドアを通じて物質が移動したとき、どこでもドアは何かしらのエネルギー(電気とか)を多く消費する。
位置エネルギーが問題になるならば、重力や電界や磁界のエネルギー差も当然あるわけだが、これも同様にどこでもドアが調整する。

このような事からドアがエネルギーを消費することがわかる。
どこでもドアを通過している途中にエネルギー切れ(電池切れ)等が発生した場合、どのような安全対策が施されているのかについても興味が尽きない。

もう一つ心配なのが、地上で使う限り、どこでもドア自体が常に移動していることである。
相対性理論によると、絶対的静止系は存在しない。よってどこでもドアが移動しているかどうかは特に関係ないのだが、ドアを開けた先と現在地に相対速度差がある場合は話が別である。さらに、地上に置かれた物は、重力と遠心力、地表からの反力が釣り合った状態で円運動をしている。つねに複雑な相対速度差がどこでもドアのこちら側とあちら側には存在する。
相対速度差があるということは時間の流れに差があるということだ。
例えば、ドアのあちら側とこちら側で原子の振動数が見かけ上、変わる。
人間などが通過するとき、その体を構成する原子が、原子や分子としての構造を保ったままどうやって通過しているのか気になるところである。
ここもSF的発想が必要だ。例えば質量を無効にする装置が搭載されているとか、別次元の平面宇宙のようなものを通過するだとか。

いろいろ考えてみたが、おそらく他にもある。
どこでもドアを実現するには、工学的問題の前に机上で解決しなければならないパラドックスが多数存在する。

家庭内ネットワーク

引越ししました。

よって、LAN配線もまったく構成が変わったわけですが、今まで使えていた機器が不調に陥ったりしました。
どうも特定の機器との間で相性が悪い模様。

具体的には持っていた無線LANアクセスポイントと、GIGABYTEのM/Bに乗っている(例のカニのマークのついた)オンラインイーサポートを繋ぐとリンクアップはするものの、パケットロストが多発します。
pingは通ったり通らなかったり・・。
Windowsのファイル共有でファイルをコピーすると、小さいファイルならOK,大きなファイルだとエラー、のような困った状況。

そろそろ買い替え時かもしれません。
SSIDの_nomap付けなきゃ。

日本語の乱れ

自分もいい歳なので、本当の若者(自分は30超えてるのに気分だけは幼い)のカルチャーについていけないと感じることは多くあります。
でも平均よりは理解出来る方だと思ってたりします(たぶん大勢の30代がそう思ってます)

特に中学、高校くらいになるともはや異世界の人です。
「こんにちゎ ゎたしは㊥①デス」「ヶドぃくら仲仔の先輩でも敬語ゎ使ぅョォ」みたいな新発明の文章を見ると反射的に拒否感を示す人がいます。
そして説教し始めます。そして嫌がられます。

でも考えてみれば40代の人だって10代の頃には丸文字とか書いてたじゃないですか。

仕事の場では「見える化」とか造語が流行ってますし、意外とみんな乱れてます。

生ゴミ処理機購入補助費申請してみた(ダメかも)

各自治体では生ゴミ処理機の購入に補助を出している事が多いです。
ゴミ焼却場の建設が難しく維持費もかかるための施策だと思います。

そういう理由か、財源の理由かはわかりませんが、自治体によって補助費にかなり開きがあり、0円(補助制度なし)もあれば、東京都千代田区などでは30,000円が補助されるようです。

さて、生ごみ処理機を購入することになったので我が家でも補助費申請をしてみました。
現在名古屋市在住で、補助費は8,000円のようです。

まず名古屋市リサイクル推進センターに申請します。
6月1日〜1月18日まで250件まで先着順ということでしたが、申請自体は無事受理されました。整理番号からして全然250件に達していない感じ。
購入したのはPanasonicのMS-N53という製品で実売5万円前後です。

さて、ここまでは簡単だったのですが、この先が厄介。
添付書類として領収証の原本と保証書のコピーが要求されます。
それは合理的に考えて仕方ないのですが、領収証の形式に細かい指定があり、
・生ごみ処理機単一の領収証であること
・宛名が入っていること
・品名が入っていること
・担当者印があること
などなど。

この領収証の規定がとても厄介。
実店舗であれば簡単なのですが、Amazonとかよりも10,000円以上高く、補助使わない方がお得という現実。
ネットショップだと銀行振込みか代引のところが多く、どちらの場合も領収証は普通発行してくれません。(明細を領収証にしてくださいというスタンス)
Amazonのようにカード払いなどで領収証を発行してくれるところもあるのですが、「担当者印」というのが結構厄介で、社印しか入っていない領収証がけっこうあります。(プリンタで打ち出して社印を押したもの。Amazonに至ってはそれもなし)。

どこまで領収証の形式が厳密でないといけないかは不明ですが、たかだか8,000円の補助のためにわざわざ高いところで買うのも・・・と思い、結局最安で楽チンなAmazon.co.jpで注文しました。
領収証の形式は全然ダメですが、購入は証明できるんだし、これで申請してみます。

せっかく8,000円補助費出すことにしているのに、補助費を確実に貰うためには数千円も高い値段で買わざるを得ないというのは釈然としません。
千代田区みたいに30,000円くらい補助してくれるならいいんですが。

1日にかけるプログラムの行数

登大遊さんは1日に10,000行のソースコードを書けるらしい。

当然ながら作ろうとするプログラムの性質によってこの値は全然変わるんだろうけど、それにしても10,000行というのは信じがたいほどの速度だと思う。
行数増やすだけなら簡単だけど、この人がそんなトロいコード書いてるわけはないだろう。

自分はどのくらい書いているのかな、とここ最近書いた物を見て見るとたぶん平均したら1日あたり数百行くらい。
iOSのプログラミングなんてバッドノウハウの塊だし、そもそもモバイルデバイスのGUIコーディングには時間がかかる。

一方で設計段階で動作が100%仕様が確定でき、GUIのような感性に左右される部分が無いネットワークプログラミングなどはもう少し早く書ける。
以前簡易的に作ったPOP3サーバは1日(たぶん8時間くらい)で作ったが、だいたい3,000行(ステップ)くらい。
これ以上高速には出来ないと思う。

というわけで、たぶん僕の限界は最高パフォーマンス(相当無理して)で3,000行/日くらい、普段は500行/日くらい。
やっぱ10,000行はすごい。

そもそも丸一日コーディングとか滅多に出来ないんですよね。疲れちゃって。

カレンダー

2024年11月
 123
45678910
11121314151617
18192021222324
252627282930  

▲Pagetop