BLOGakisuteが主に技術的なネタを書き溜めるブログです。挙動がローカルファイルとリモートファイルで変わるみたいですflash.net.Loaderを用いて、リモートサーバーからswfファイルをロードし、画面に表示するようなアプリを書いていたのですが、そのときふとしたことから以下のような問題に気づきました。仮に以下のような条件があるとします。main.swfとresource.swfがあって、main.swfはflash.net.Loaderクラスを用いてresource.swfをロードしてくるものとする。//ローカルファイルからロードロードしてきたswfは、以下のコードでloader.loaderInfo.contentから取り出して、MovieClipとして処理する。Loaderは破棄する。MovieClip;}ロードしてきたswf(以下resourceと呼称)には合計200フレームのタイムラインがあり、1から100フレーム目までにleftというラベルがついて左向きのデータが、101から200フレーム目までにrightというラベルがついて右向きのデータが格納されている。1から100フレーム目までに右向きのデータは存在しない。対象のファイルresource.swfを、ファイルシステムからロードしたときは、なんの問題もなくラベルleftとrightを入れ替えることができる。対象のファイルresource.swfを、httpでリモートサーバーからロードしたときは、leftとrightを入れ替えた瞬間に、resourceのアニメーションがバグる。stop()やgotoAndPlay()などの命令を無視した動きをする。ローカルファイルとリモートサーバー、どちらのresource.swfも完全に同一のファイル。ファイルサイズもタイムスタンプもsha1ハッシュも完全に一致。最初に見かけたときはAdobe焼き討ちじゃコラと思ったものです。■調査:取ってきたswfをdescribeTypeしてみる愚痴っても仕方がないので調査します。取ってきたswfに対して、flash.util.describeType()を実行し、オブジェクトダンプしたXMLを見てみます。するとローカルファイルから取ってきた場合とリモートサーバーから取ってきた場合で、以下のような違い(diff)がある事が分かりました。type="flash.display::MovieClip"/>diffなのでちょっとわかりにくいかもしれませんが、よく見ると以下のような差異があることが分かります。LOCALにはきちんとしたクラス名がついており、MovieClipのサブクラスになっているLOCALにはプロパティ情報がきちんと残されているREMOTEはタダのMovieClipクラスになっており、プロパティも一切無いつまり、全く同一のファイルをロードしているにもかかわらず、flash.net.Loaderは、ローカルファイルからロードするかリモートサーバーからロードするかによって生成するMovieClipオブジェクトを変化させているということがわかりました。してこのようなことをになっているのか少し考えてみたのですが、おそらくセキュリティ要件の問題ではないかと言う結論に至りました。いうのも見ての通り、ローカルファイルから読み込んだswfをdescribeTypeすると、クラス名としてファイル名とシンボル名がついてしまっていて、これを悪用することができるのではないかと危惧したのではと。■対応:しかしさらに泥沼クラス情報が欠落してMovieClipになってしまっているのが問題だとすれば、読み込まれる側のresource.swfのすべてのシンボルを「アクションスクリプトに書き出し」して、きちんとクラスとして定義すれば、問題が解決するのではないかと考えました。強制型変換に失敗しました。flash.net::URLLoader/onComplete()・・・bullshit。ジョブズがどうしてあんなにFlashを毛嫌いするのか分かった気がします(絶対違)。スタックトレースが出るようになってくれたので、なんとかなりそうです。さっきまではスタックトレースすら出さずに勝手にバグを出してくれやがってたので大変困っていました。これ読んで出直せ、Adobe。silently.■考察:どうしてこうなるのかさらに考えてみます。さっきのスタックトレースはロードに失敗してバグが発生している用に思われますが、実際にエラーを吐いているのはonLoadCompletedの中のgotoAndPlayです。ロードが完了した瞬間にgotoAndPlay("right")を実行しているのですが、そこでエラーが発生しているのです。ここでちょっと仮説を立ててみます。ロードが完了された瞬間のresourceのcurrentFrameは1、つまりleftである。このとき、right側のパーツは一切読み込まれていない(nullである)。gotoAndPlay("right")を実行すると、おそらくロードが完了しているMovieClip自身がタイムラインに従って101フレーム目以降の内部構造を補完しようとする。right側のパーツ(MovieClipとかShapeとか)をどっからか取ってきてセットし、left側のパーツをnullにセットしようとする。ここまでの動きはデバッガを使って確認できました。このとき、先ほどのflash.net.Loaderは完全な情報を持っていたのできちんとMovieClipを作ることができた(left側のパーツをセットできた)が、MovieClip自身にはその情報がないので、right側のパーツをセットしようとしてタダのMovieClipをrightArmクラスの変数にセットしようとし、キャストに失敗して落ちている。・・・長くてすみません><要するに、ローカルファイルからロードし生成されたMovieClipはデータを完全に保有しているのでMovieClip自身でnullフレームを埋めることができるが、リモートサーバーからロードしてきたswfから生成されたMovieClipは生成時にLoaderクラスによってデータを欠落させられているので、自力でnullフレームを埋めることができないのではないかと考えたのです。■解決策:外部ロードするswfは、絶対に空のフレームを作るなそこで以下のような対応をしてみました。leftラベルの箇所にもright側のパーツを配置する。見えては困るので、透明にして配置する。同様に、rightラベルの箇所にもleft側のパーツを配置する。nullフレームがないのでタイムラインがどのように動いても一度ロードされたデータが欠落することがない。従って問題なく動作する。この方法が功を奏し、見事に動作するようになりました!■というのを@moriyoshiさんから教えて貰いました。すみませんすみません><■1:gitのbranchは跡形もなく消せるほとんど常識ですが、以下のコマンドでgitのbranchは消せます。-Dこのコマンドを実行すれば、たとえHEADに対してマージされていなくてもそのままブランチを消すことができます。いうことで、ちょっとしたテストコードなどはブランチを切ってそこで実験し、後からブランチごとたたき落とす運用が可能です。余談ですが、gitのbranchはSubversionと使い勝手や実装が似ている感じがします。Subversionのbranchもタダのディレクトリコピーなので、好き勝手に作って消してが可能ですから。■2:Mercurialのbranchは基本消せない、「未使用」か「クローズ」にはできる問題はここから。Mercurialのbranchは、基本的に完全に跡形もなく削除することができません。マージしていないブランチがあるとpushの際に怒られます。そのため、ちょっとしたテストコードをブランチ切ってそこで作成し、いざいらなくなったので削除しようと思うとえらい大変なことになります。一応、ブランチを「クローズ」するコマンドを使うことで常用範囲内からは消す事が可能ですが、完全に情報が消えたわけではないのでリポジトリのサイズは小さくなりません。Mercurialでテストコードを管理しようと思うならば、branchを切るのではなくリポジトリごとcloneしてそちらでテストする運用にすればよいです。■3:Mercurialのbranchに数字で名前を付けてはならないgitと違ってMercurialのリビジョンには、簡便のため、リビジョンのハッシュIDの他にリビジョン番号が1番から採番されるようになっています。各種操作の際に、このリビジョン番号を代わりに指定して実行することが可能です。問題はbranchに数字の名前が付けられることで、もしbranchに数字の名前を付けてしまった場合、Mercurialはその数字をリビジョン番号として解釈してしまい、ブランチ名指定の処理ができなくなってしまいます。ブランチ255ではなくリビジョン番号255番に対してアップデートしようとする・・・ただそれだけなのですが、チケットシステムなどと連携しているとよくチケット名でブランチを切る事があると思いますので、そのような際にはticket255などという風に指定するほうがよいかと思います。なっているので、もっぱらhgばかり使っています。いうことで、いくつか覚えたhgネタ。Mercurialやgitに限らず、いかなるバージョン管理システムを使用していても、人間が使う以上運用中にミスが発生することは避けられません。今回はMercurial使用中に間違ったコミットやプッシュを行ってしまった際の対処法を調べてみました。G-Tools間違いを修正するためのコマンドは、大きく分けて以下の3つがあります。backoutまたコマンドを用いて修正する意外にも、ローカル作業する際に作業用リポジトリを別に作って、問題に気づいたらリポジトリごと削除するという運用もありますが、今回は説明を省きます。revert適用可能なのは「ローカルのリポジトリ上で、コミットをする前に問題に気づいたとき」。作業中にちょっと間違った際など、ファイル単位でコミット前の状態(parentの状態)に戻すことができ大変便利です。rollbackを使用します。rollback適用可能なのは「ローカルのリポジトリ上で、コミットをした直後に問題に気づいたとき」。直前の1回分だけ、commitを取り消すことができます。マージ作業だろうがなんだろうが跡形もなく消してくれるため、後から見ても痕跡がなく綺麗です。操作も簡単で安全なため、これが使用可能なときはこちらを使用すると便利です。一応、直前の1回だけならリモートの共有リポジトリへのpushも取り消すことができるのですが、これは後述の理由からお勧めしません。backoutを使って取り消すことになります。backout適用可能なのは「ローカルのリポジトリ上で、複数回コミットした後にに問題に気づいたとき」か、または「リモートの共有リポジトリにプッシュしてしまった後に問題に気づいたとき」。しようもなくなってしまったときの最後の手段がこれ。指定したリビジョンのcommitの内容を完全に打ち消す新しいリビジョンを作ってくれます。あとは、手動でこの自動で作られたリビジョンを元のリビジョンにmergeしてcommitすることで、いかなる問題であろうとも無理矢理打ち消す事が可能になります。間違ってプッシュしてしまった際に使用します。rollbackでも直前のpushを取り消すことが可能ですが、一度pushされてしまった内容はどこかの誰かのリポジトリにpullされてしまっている可能性があり、そうなると共有リポジトリだけをrollbackしても効果がありません。backoutで修正リビジョンを作りマージしたあと、再度共有リポジトリにpushすれば、他の誰かのリポジトリに問題が取り込まれてしまっていても次のpullで無事修正されます。Androidアプリエンジニアやってます。原因を調べるのにずいぶんと苦戦したので備忘録を作ります。調べたのですが、これよりよくまとまっているドキュメントを現状発見できませんでしたので、2019/06/08現在では上記のドキュメントを参照するのがベストだと思います。操作が優れているか否か」を評価点に挙げます。今回の記事は久しぶりの誰得記事です。こちらで紹介されている手法を用いるにはプライベートAPIを操作する必要があるため、おそらく審査に通りません。じこせきにんでお願いします。プロパティを使うことで簡単にアニメーションを実装させることができます。サンプルを書いてみます。Accessから秘密鍵を書き出すときに、「エラーが発生しました。項目を読み込めません。Accessのお世話になることが多いです。複数台のMacで開発を行っている場合は、証明書を認証するための秘密鍵を複数台のMacにインストールする必要があります。今年は2019年となりました。12月7日担当のakisuteです。最近フォント周りについて深く掘り下げる機会がありましたので、その際のメモを残しておこうと思います。地点では存在しないタイトルの通りですが一応補足しておきます。