メインビューとサブビューの座標の違い

メインビューでaddsubviewにてuiviewを追加して、ボタンを押したら別のビューが下からビョーンって出てくるようなものを考えていたが、座標の問題で困った。メインビューの座標とサブビューの座標はそれぞれ存在しているため、メインビューでタップしたポジションでサブビュー上のパーツを動かそうとしたら、当然おかしなことになる。このサブビューを下から少しだけ飛び出すような使い方だと座標の変換が多分必要になる。あと、サブビューのパーツを画面外のメインビューへ飛び越えるような使い方は、多分無理な予感。試してはないけれども、普通の感覚では不自然。

下からビューを飛び出してきてその上のパーツをいろいろ動かすのは、擬似的にすることにした。つまりビューだけ下から表示して、その上のパーツはメインビューにaddsubview()するということ。つまり見た目の上ではテクニカルなことをなんかやっているように見えるだけ。たいていの場合こういうのは設計が悪くて他にもっとスマートな解決方法があるはず。なんか無理やり実装してる感が出てきたら経験上よろしくない。後々のメンテナンス性が劣悪になったりとか。

Ubuntu ServerでBusyBoxとか出てフリーズ、起動できなくなった

mount: mounting /sys on /root/sys failed: No such file or directory
mount: mounting /proc on /root/proc failed: No such file or directory
Target filesystem doesn't have requested /sbin/init.
No init found. Try passing init = bootarg.

BusyBox v1.1.3 (Ubuntu 1:1.1.3-1ubuntu11) built-in shell (ash)
Enter 'help' for a list o built-in commands.

(initranfs)

エラーが出るまでは普通に稼働していたUbuntu Server12.04が突然フリーズして上記エラーを起動時に表示するようになり、そこから進まなくなった。No such file or directoryの部分を見て直感でこのエラーはかなりまずいかなと思ってググってみたら、LiveCDでfsckを実行すれば治るとかあったので、参考に自分もやってみることにした。まずはHDDが壊れていないことを祈って今取り付けているポンコツより高性能なマシンに載せかえる(intel atomという低スペcpuでサーバー稼働していて、復旧作業が長くなりそうな気がしたので)

で、載せ替えた後に念のためもう一度起動してみたところ、起動時にHDDのアクセスランプが長いこと点灯したままになってなかなか画面が表示されない現象が発生。しばらく待ってたら画面が表示されて、さっきとは違う画面が表示されて、一瞬だったから覚えていないがblockがなんとかあってfsckが実行されたような感じになった。(この時はまだLiveCDは挿入していない)

その後は、ログイン画面が表示されて前と変わらないように稼働できるようになった。まるでさっきのエラーがなかったかのように。かなり古いHDDを使っていたので壊れちゃったかなと完全にあきらめモードで作業していたが、実際にやったことといえばHDDを別の高性能なマシンに載せ替えて起動してみただけ。もしかしたら、HDDが熱暴走気味になっていて、交換作業中に冷めて正常になったという可能性も、なくはない。(排熱が十分とはいえないマシンを使っていたのは事実)

上記のBusyBoxというようなエラーが出た時、あまりごちゃごちゃいじらない方がいいかもしれない。一旦落ち着いて(あきらめモードで)、HDDの熱が冷めるのを待ってもう一度起動するなど気長にやる。どのみち完全に故障なら復旧作業はそれなりに時間がかかるのだから。

それにしてもfailed: No such file or directoryというエラー文は怖すぎる。サーバー管理者を絶望させるに十分なインパクトがある。

翌日

また不具合が起こった

fsck.ext4: bad magic number in super-block while trying to re-ope
e2fsck: io manager magic bad! 

こんどは上記のようなエラーが発生した。昨日はfsckっぽいものを走らせたら直ったから今回もfsckを実行してみようかと思ってコンソールに入力すると、

Error reading block **** (Attempt to read block from filesystem resulted in short read) while getting next inode from scan.  Ignore error? yes

Force rewrite? yes

みたいな確認が膨大な量出てきた。なんかわからないがyesにするしかないよなぁ・・・と思いながらエンターキーを連打していてちょっと多すぎるからキャンセルしてやり直すかと画面みたら/varとか/etcとかのフォルダに対してdeleteとかrewriteとか実行してしまっていた。

で、再起動するも昨日のエラー画面のno such file or directoryが出て進まなくなった。→OSの再インストールを決断

私の致命的なミスは、昨日、幸運にもエラーから復旧できた時にHDD内の必要なデータをバックアップするなどの作業を怠ったこと。買ったばかりのHDDはともかく、古いHDD使ってて上記みたいなエラーが出だしたらもう交換の目安かもしれない。いや、すぐ交換すべき。この種エラーが出たらもう長くないと思ってHDDが生きている内にデータバックアップとリプレース作業を済ましておく(私が使っていたHDDはもう7,8年は使っていた)

busyboxのエラーが出たHDDその後、取り外してcrystaldiskinfoで調べてみた。健康状態は当然、注意の表示が出た。使用時間は51000時間で約6年間稼働している。もうこのHDDは引退。よく頑張ったと思う。

レイアウトの位置設定でframeで設定する場合とpositionで設定する場合の違い

iosのUIButtonの配置で気になったのでメモ。


var myButton: UIButton!

// Buttonを生成する.
myButton = UIButton()
        
// サイズを設定する.
myButton.frame = CGRectMake(0,0,200,40)

// ボタンの位置を指定する.
myButton.layer.position = CGPoint(x: self.view.frame.width/2, y:200)

ポジションの設定はCGRectMakeでサイズとポジションを設定する方法と、layer.positionにCGPointで設定する方法がある。この二つの違いは、ポジションの原点の位置が異なる模様。CGRectMakeで設定する場合は原点はビューの左上になり、上記の0,0というポジションなら画面の左上にピタリと配置されることになる。CGPointで設定した場合は、原点はビューの中心となり、CGPoint(x: 0, y:0)と設定すると画面左上に配置されるがビューの中心を基準に配置されるので右下4分の1だけ表示されることになる。

wordpressのパーマリンク設定で404になる問題

ワードプレスのパーマリンク設定をするとページ遷移先が404not foundになる場合。
チェックポイントは下記の3つ。

  • mod_rewriteの有効化
  • .htaccessの設置
  • 管理画面にてパーマリンクの設定・保存

でカスタム構造などのパーマリンクは使うことができるようになる。

私の場合はトップページはなんとか表示されたが(記事一覧は表示しなかった)、個別の記事のページを表示すると404エラーが表示されるという現象だった。mod_rewriteはウェブサーバーのapacheの設定で、レンタルサーバを利用している場合は大抵の場合は有効になっているので気にしなくていい。.htaccessファイルはパーマリンクの設定に不可欠なファイルで、内容はカスタム構造のリンクを変換するものになっている。このファイルをワードプレスの設置しているディレクトに置くことで有効になる。管理画面からパーマリンクの設定を実行すると.htaccessファイルは自動で作られる。対象ディレクトリに書き込み権限がない場合は自分でファイルを作成して置くか、権限を付与してから再度実行する。

mod_rewriteが有効化どうか確認するには、例えば下記のような内容に.htaccessを書き換えてみて、ページを表示してみたらヤフーのトップページが表示されるようならmod_rewriteは有効になっているといえる。

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteRule ^.*$ http://yahoo.co.jp [L]
</IfModule>

他には、.htaccessのファイル権限とかもあるが、特には気にすることはなく標準のファイル権限を設定しておけばいい。レンタルサーバの場合は上記の点をチェックしておけばおそらく表示されるようになる。それでも表示されない場合は、サーバの設定(バーチャルホストやリダイレクト設定)に問題がある可能性が高い。

自宅サーバの場合も大体同じだが、httpd.confファイルでバーチャルホストを設定したりしている場合には設定の仕方によっては上記だけでは表示出来ない場合もある(私がそれでかなりハマった)
で、その時はウェブサーバーのログを見る。ログなんかめったに見ない主義だったが、今回ばかりはログを見ることで原因がわかった。そもそも404エラーはアクセスしたアドレスにファイルが見つからないというエラーで、ログにはアクセスしたディレクトリとともに404エラーが確認できる。バーチャルホストの設定が間違っている場合はおかしなディレクトリにアクセスしようとしてだから404なのだということがわかる。

ワードプレスとはあまり関係がないがapacheのhttpd.confでバーチャルホストの設定をする場合、一致したものから順に振り分けるという仕様になっているらしい。一致したものからというのはファイルの上から順にということで、バーチャルホストホストの設定で一番上にアスタリスク(*)で設定した場合はそれ以降は読まれないということになる。

windows 7 service pack 1の更新プログラムを確認していますが終わらない

windows7 pro 32bitを新規インストールしてからwindows update をかけると、更新プログラムを確認しています・・・とゲージが現れて何時間経っても終わらない問題。

解決方法は、不明。待つしか無い。windows updateを実行してから電源管理のスリープとか電源を自動で切る設定をオフにして一晩つけっぱなしにしておく。さすがに翌朝までには対象のアップデート数がいくつかはわかるようになるのでそこからダウンロード、インストールという流れになる。

だが、またしてもインストールしています・・・という画面から進まないという現象が発生。更新プログラムがダウンロードしている状態なら、電源をシャットダウンをする操作でインストールへと進むことができる。

とりあえず時間がかかる。新規インストールの場合は更新プログラムの数が200個とかになるのでダウンロードとインストールで時間を取られて1~2時間では絶対に終わらない。焦らず慌てないでやるしかない。

中古車を現車確認せずに通販で注文してみた

車検切れと同時に車を手放すことになったのでこの機会にと思って中古車を通信販売で買ってみた。ちなみに私は車のことは全然詳しくない。今まで買ったこともない。運転はするがそれは家族の車をたまに使う程度。つまり初めて買う車を、インターネットの通信販売で、車の画像数枚確認して、年式とか走行距離とかプロフィールを確認して、あと適当に電話で店の人に車の状態(修復歴とか気になるところとか)を聞いてみて、それだけで中古車を買ってしまった。

中古車の買い方として現車確認も試乗もせずに買うのは絶対間違っているだろうが、こういう無謀な買い方をする人は意外といるんじゃないだろうか。例えば遠方の自動車屋さんで車を買う場合など。近所の車屋さんで売っている車の中から選ぶというのなら堅実だが、自分が好きな乗りたい車を選んでからそれはどこに売っているか・・・と検討すると現車確認できない程遠くにあるというケース。私の場合がそれだが。

車を通信販売で電話一本で購入する流れは以下のような感じ。普通車と軽自動車とでやりとりに違いが出るようだが、今回は中古の軽自動車を注文する場合。

  • 電話で買う意思を伝える。そのとき店の人に無保証ですよと釘をさされてちょっとビビる。
  • 住民票と免許証のコピーをその自動車屋に郵送で送る。
  • お金を支払う。内訳は車両代金と車検代と名義変更などの事務手数料と陸送代。
  • 車検や名義変更、陸送の手配などを店の人にやってもらう。
  • 車検終わって名義変更も終わってナンバーもつけてもらって陸送してもらって受け取る←今ここ

注文してから陸送で納車までの手続きは約2週間ほど。郵送で書類を送ったり名義変更をしたりとするのでどうしても時間がかかる。普通車の場合は車庫証明を取得したりともっと時間がかかるかもしれない。

車が来たら追記します。

車が来た

陸送にて注文した中古車が来た。ここで初めての現車確認になる。正直なところ、注文する前に現車確認していたら注文するかどうかためらうぐらいの状態だった。うーん、ひどいのが来たなぁ・・・が、第一印象。状態が悪いのは覚悟していたが、予想よりも3割増しで悪いような気がする。

悪かった点

  • 車内のタバコの臭い
  • マフラーの騒音
  • モールの劣化
  • 可動すべきところの故障
  • 画像で確認できなかった部分に相当なカスタマイズが施されていた
  • パワーウインドウの動きが左右で違いなんか怪しい。運転席側の窓ガラスの一部が溶けてた
  • 車体の継ぎ目にあるゴム素材のモールは大体劣化および欠損していた
  • ビニールテープで雨漏り対策されてた(は?)
  • 洗濯バサミが落っこちてた(は?)
  • その他いろいろ

良かった点

  • 古い年式の車だったがエアコンは生きてた
  • 一応エンジンかかって自走できた(車検通ってきたから当たり前かもしれないが)
  • シートの破れは覚悟していたが奇跡的になかった

値段なりの車が届いたというのが客観的な現実だろうと思う。店の人が現状渡し、無保証ですと言った理由が
よく分かる気がした(現状渡しは承知だったが煙草の灰皿に吸い殻が残ったままだったのはさすがに閉口した)。それプラス現車確認を怠ったことによるいくつもの不安要素。現車確認せずに電話一本で中古車を購入した結果は悪いところばかりだが、自分が欲しいと思った車種の車が手に入ったという一点は達成できたので意外と満足感はある。これが自分の興味のない車種で買った理由が安かっただけというのなら最悪だったが。

return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));

xcodeでクラッシュする場合の話。

return UIApplicationMain をキャッチしてマウスカーソルを合わせるとEXC_BAD_ACCESSとだけ出る。コンソールログには何も出ていない。ゆえにどこで何が原因かということがまるでわからない。私の場合は特に処理の重いルーチンで発生していて、クラッシュの再現性もできなく不規則的に発生するので困難を極めた。それでもバグを取り除かなければならないのでまず手始めにやることはログの情報量を増やすことから始める。Edit SchemeからDiagnosticsタブでデバッグ時のオプションを選択できるようになっているので、そこからログに関係する項目にチェックしてコンソールに表示される情報を増やす。Loggingの項目のどれでもいいが例えばLog Dynamic Linker API Usageにチェックを入れて実行してみたところ変数名とその値がログに表示されるようになる。とりあえずその状態でデバッグをしてみることにする。クラッシュの再現性は不規則であったが、ログを確認してみると特定の関数内の変数に関わるところでクラッシュしているというのがわかった。クラッシュの原因は厳密にはわからないもののどこでクラッシュが発生しているかという関数の場所はログに表示される変数名から特定することができた。結局原因はプロパティ変数にアクセスする際のささいなミスだったんだけれども。

原因不明のEXC_BAD_ACCESSがでるクラッシュでもデバッグオプションでログの情報量を増やせば怪しい箇所を特定することができる。クラッシュした時に原因となる箇所がログに表示されれば一番いいのだけれど、表示されない場合もあるのでそういう場合は実行中にログを流し続ける設定にしてクラッシュしたらその直前のログをチェックして場所を限定する、という具合にやると厄介なバグでも修正できるかもしれない。

デバッグのオプション設定

Memory Management

Enable Malloc Scribble
Enable Malloc Guard Edges
Enable Guard Malloc
Enable Zonbie Objects

Runtime Sanitization

Enable Address Sanitizer Requires recompilation

Logging

Distributed Objects
Malloc Stack
Log Dynamic Linker API Usage
Log Library Loads

Dubugger

Stop on Debugger() and DebugStr()

スーパーロボット対戦F・完結編 精神検索

精神コマンドから該当するパイロットを一覧する

脱力
ボス、レミー、ミヤマ=アスフィー、レディ、ミオ
激励
さやか、ジュン、メリー、ベス、ハルル、沙羅、タシロ艦長、チャム、マーベル、エレ、シーラ、リリス、アム、ロザミィ、エマ、ファ、エル、イーノ、セシリー、レイン、シュバルツ、テュッティ、リューネ
再動
ギジェ、エレ、リリス、リィナ、リアル系副主人公
復活
シーラ、クリス
クリス、セシリー
補給
メリー、ちずる、ギャリソン、キャオ、カツ、レイン、サフィーネ
自爆
ボス、バーニィ、ヒイロ(とその他省略)

チャーハンをうまく作るコツ

固めのご飯を用意する
極端な事を言えば、おかゆ並みの柔らかいご飯ではどんなに上手い人でもパラパラなチャーハンはできない。固めに炊くか、冷やご飯や冷凍ごはんなどを用意して水分を飛ばして固めにする。
コンロの火力を強くしすぎない
チャーハンは火力とスピードが大事、と上手い人は口を揃えて言うが初心者には高火力をコントロールすることもスピーディに鍋振りする技術もないため失敗する原因になる。調理中も鍋から煙がモクモクと出ているようなら熱くなりすぎている。無理して高火力で調理しようとするとご飯を炒めてパラパラにほぐす前に焦げてしまってダマになりベタッとした仕上がりになってしまう。鍋を温めるまでは高火力で、その後は強火〜中火ぐらいで初心者のうちは慣れるようにする。調理時間の目安はコンロの火力全開で調理する場合は最大でも2分以内に仕上げないと焦げる。
仕上げに酒を振る
水分を飛ばしてパラパラするのがチャーハンだがやりすぎるとパサパサになってしまうことも。仕上げに日本酒を振ることでふっくら仕上げることができる。

鉄フライパンとテフロンフライパン調理結果に違いは出るか

2年前くらいから使用している鉄フライパン(クレープパン)でお好み焼きをまた最近焼き始めたところ、以前に比べて味がやたらと美味しく感じられるようになった。もちろん気のせいかもしれないが。前から作っていたのだけれど、この材料とこの材料を混ぜて焼いたらこんなのができて味も大体こんな感じだろうなと予想の範囲内のものができていたので驚きもなく特に美味しいと感じることもなかった。その後しばらく振りにまた鉄フライパンでお好み焼きでも作ってみようかと作ったところ、予想外に美味しくできてしまったのでテフロンフライパンでも同じように作れるかどうか試してみた。

作ったお好み焼きの具材は、

  • お好み焼きの粉
  • キャベツ
  • 卵1個
  • 薄切り豚バラ肉2枚
  • お好み焼きソース
  • マヨネーズ
  • 粉末かつお削り節

というお好み焼きを作る最低限のものを使った。作り方は説明するまでもないがキャベツをスライサーで2mmの薄さに切ってお好み焼きの粉を水で溶いたものに卵と一緒にいれて混ぜる。あとはフライパンを温めてサラダ油を引いてさっき作った生地を流し込んで上に豚バラ肉を上に載せて焼く。弱火から中火で2分焼いたら裏返して3分~4分焼いて、また裏返して2分焼いてソース・マヨネーズ・かつお削り節をかけて出来上がり。

同じ材料と同じ手順で調理して、鉄フライパンとテフロンフライパンでそれほど違いはでないんじゃないかと思っていたが、個人的な感想だが鉄フライパンで作ったほうが美味しいと思える結果になった。使ったフライパンはテフロンフライパンの方はどこにでも売っている980円くらいのもので鉄フライパンはデバイヤーのクレープパン 20cm

食べた時の食感に違いが大きく、鉄フライパンで作った時はいわゆる外はカリッと中はふわっとしたものに作れる。テフロンフライパンで作った方はそれに比べて若干固く感じられた。

この鉄フライパン固有の特徴でクレープパンという仕様であるため縁が浅く出来ていて、料理が出来上がったらそのまま鍋敷きにでも置けばお皿がわりにも使えて、板厚約2mmで冷めにくいのでお好み焼きを温かいまま食べられるというメリットもある。

鉄フライパンは使い込めば油馴染みがよくなってきて料理がやりやすくなる・・・というようなことがあるらしいが、2年近く使っている私の鉄フライパンにもそういう変化が起こったのかもしれない(傷だらけだけど使い込んでいるわけではないが)

結局、お好み焼きがテフロンより鉄フライパンで美味しく作れた原因はあまりよくわからない。気の長い話だが2年ぐらい鉄フライパンを我慢して使いこめば理屈じゃなくて自然とお好み焼きが美味しく焼けるようになるのかもしれない(ドラゴンボールの超聖水的な意味で)