tanamonの稀に良く書く日記

KEEP CALM AND DRINK BEER

スマホでもポーズマニアックスのランダム・ポーズを使う

少し前に、ポーズマニアックスのランダム・ポーズを使った絵の練習法が話題になっていました。


余とお絵描きしようや~ #1 れんしゅう・理論編

どんな練習法か簡単に説明すると、最初にポーズマニアックスのポーズを1分程度じっと見続けて、それから目を閉じて脳内でそのポーズを再現させてみるというものです。

動画だと32:45あたりから。

これが面白かったので自分でもやってみたいと思ったのですが、ランダム・ポーズはFlashを使って実装されているので、今時のスマホでは使えないようです。

Flash、昔はちやほやされてたのに、ジョブズに嫌われたばっかりに今やすっかり不憫な子扱いだな……

で、簡易版を作った

やりたいのはただランダムにポーズを出したいというだけなので、スマホでも使えるブックマークレットを作りました。 なお、Flashはパソコンでも2020年末でサポート切れとなりおそらく各ブラウザで使えなくなると思われますが、これなら2021年以降も使えます。

jp.techcrunch.com

使い方

iPhoneの場合の準備。

  • まずブラウザで適当なページ(あとで書き換えるのでこの記事ページでもどこでも良い)をブックマーク登録します
  • 右のボタンを押す

  • ブックマークから編集を押して、上の名前欄を「ランダムポーズ」など好きな名前にして、下のアドレス欄を消してから先ほどコピーした文字列をペーストします

あとは登録したブックマークを開くとランダムでポーズページが開きます。

別のポーズにしたかったらもう一度ブックマークを開くだけです。

Androidの登録方法はよく知らないけど、まあ、似たようなやり方で登録できると思います。 わからなかったら、「ブックマークレット登録 Andoroid」あたりでググると出てきます。

制限

ポーズマニアックスのスマホ用ページを使ってるので、その制限があります。

  • アングルは自分で回す必要がある
  • 36アングル分勝手に画像を読み込む仕様なので、データ転送量が少し多い

技術的なこと

  • やってることはposeカテゴリスクレイピングして集めた記事番号からランダムで選んだページにジャンプしているだけ
  • 記事番号が微妙に歯抜けのため、全1127ポーズをそのまま配列に入れてるので長くなってる
  • パソコン版は40572 PICSとあるので40572 / 36 = 1127ポーズだと思われるが、poseカテゴリは1114ポーズなので13ポーズ足りない。他のカテゴリはアングル(1141)・性別(1132)・種別(1165)とどれも1127より多いので、ゴミが入ってそうだと思って少ないほうかつ名前がそれっぽいposeにした

Wordpressのログインパスワードを忘れてリセットメールも飛ばない時に何とかする方法

MySQLを直接いじれば何とかなるだろうと思い、やってみたら実際に何とかなった記録。
Wordpressのバージョンは3.6.1。

DB接続情報を調べる

ここら辺の情報も忘れちゃったうっかりさんは、wp-config.phpに直書きされているのでそれを見よう!

$ view wp-config.php
define('DB_NAME', 'wordpress');
define('DB_USER', 'wp_user');
define('DB_PASSWORD', 'wp_password');
$table_prefix = 'wp_';

MySQLのシェルを起動させる

$ mysql <DB_NAMEの値> -u <DB_USERの値> -p
Enter password: <DB_PASSWORDの値>

今のWPログインユーザーを調べる

ログイン情報のテーブル名は$table_prefix + usersなので、上記の場合のテーブル名はwp_usersになります。

mysql> select user_login, user_pass from wp_users;
+------------+----------------------------------+
| user_login | user_pass                        |
+------------+----------------------------------+
| site_admin | 5f4dcc3b5aa765d61d8327deb882cf99 |
+------------+----------------------------------+
1 row in set (0.00 sec)

以降の例ではsite_adminさんのパスワードを変えてみます。

パスワードを変更する

mysql> update wp_users set user_pass = md5('<新しいパスワード>') where user_login = '<変更するログインユーザー>';

パスワードを変えるにはmd5関数に新しいパスワードを渡し、whereのuser_loginに変更したいユーザーを入れるだけです。

site_adminさんのパスワードを'new password'にする場合、

mysql> update wp_users set user_pass = md5('new password') where user_login = 'site_admin';

これでOKです。

実行後、user_passの欄が変更されていれば成功です。

mysql> select user_login, user_pass from wp_users;
+------------+----------------------------------+
| user_login | user_pass                        |
+------------+----------------------------------+
| site_admin | ac1ef17c2db40995e9fdd40b04a5a649 |
+------------+----------------------------------+
1 row in set (0.00 sec)

あとは、いつも通りにログインできるはずです。

おまけ(1)

Simple Login Lockdownプラグインを使っている場合、既に規定数以上ログインに失敗しているであろうので、一時的に無効にしておきましょう。
プラグイン内のlogin.phpファイルのinit関数の中身をコメントアウトすれば無効になります。

$ vi wp-content/plugins/simple-login-lockdown/inc/login.php
public static function init()
{
    //add_action('plugins_loaded', array(self::instance(), '_setup'));
}

※無事にログインできたら、忘れずに戻しておきましょう。

おまけ(2)

メールが飛ばないのはSMTPサーバーを動かしたく無かったからなのですが、WP Mail SMTPプラグインを入れて直接GMailなどの外部SMTPを使えばよさそうです。

[memo]UDID/UUID/UIIDなどとiOS6の新IDの違い

UなんとかIDみたいなのがいっぱいあって区別がつかないので少し整理してみた。


なんとかIDの種類。

UDID(Unique Device IDentifier)

(たぶん)Apple用語。
iOS端末の製造時に割り当てられる固有の識別コードで、値の変更はできない。
端末IDや端末固定IDと呼ばれるものと同じ。
iOS5からアプリからの取得が非推奨になった。

UUID(Universally Unique IDentifier)

RFC 4122で定義されている。
生成の度に値が変わり、理論上重複することがない。
実装的にはGUID(Globally Unique IDentifier)が有名。
iOS6からNSUUIDクラスを使って簡単に生成できるようになった。

UIID(Unique Installation IDentifier)

インストールごとに変わるという性質を持ったUUID。
そのため、アプリを複数回インストールするとその都度別の値になる。
アプリの初回起動時にUUIDを生成してストレージに保存しておくという実装が一般的かと思われる。

OpenUDID

GitHub - ylechelle/OpenUDID: [OpenUDID IS NOW DEPRECATED] Open source initiative for a universal and persistent UDID solution for iOS
iOS端末のUDIDへのアクセスが禁止されたことによる代替案らしい。
性質はUDIDとほぼ同じで、オプトアウトできる(= 拒否権を行使できる、要は利用者都合で値を再生成できる)。
実装はiOS/Android/Windows Phoneがあるが、オプトアウトはiOS版のみ可能。

SecureUDID

GitHub - crashlytics/secureudid: DEPRECATED - SecureUDID is an open-source sandboxed UDID solution aimed at solving the main privacy issues that caused Apple to deprecate UDIDs.
OpenUDIDがセキュアじゃない(特に複数ベンダー間で同一値を用いるところ)ため、代替案として作られたもの。
OpenUDIDと比べると、ベンダーごとに違う値が生成されるという点が異なる。
実装は今のところiOSのみ。

UIDevice.identifierForVendor

UDIDの代替としてiOS6から使える公式実装。
端末固定でベンダーごとに値が変わるので、性質的にはSecureUDIDに近い。
ターゲットをiOS6以降にできるなら、SecureUDIDの代わりにこちらを使った方がいい。

ASIdentifierManager.advertisingIdentifier

UDIDの代替としてiOS6から使える公式実装(その2)。
UIDevice.identifierForVendorとは違い、全ベンダー共通のためUDIDに近い。
ただし、UDIDと違い、オプトアウトできる。
(オプトアウトは設定アプリの情報>アドバタイズにある「Ad Trackingを制限」で設定)

特徴

で、それぞれ、どの程度一意性があるかをまとめてみるとこんな感じになった。

一意性の範囲 UDID UUID UIID OpenUDID SecureUDID IDFV ASID 電話番号 MACアドレス
永久一意性*1 ×*2
IDを利用する度 ×
再インストール × ×
同V複数アプリ間 × ×
複数ベンダー間 × × × ×
機種変更 × × × × × × × ×
複数機種利用 × × × × × × × × ×
利用者の変更*3 × × × × × × ×

(比較のために他の一意情報である電話番号とMACアドレスを入れてみました)
○ = 値が変わらない、× = 値が変わる


こうして一覧にすると、

  • UDIDとMACアドレスは、他人の手に渡った後も同一IDとなってしまう(かなりキケン)
  • 電話番号は、将来的に他人と紐付けてしまう可能性があるため、そもそも一意かという点で微妙(キケン)
  • OpenUDIDは、IDが漏洩すると利用者の意図しない範囲までの情報が紐づけ可能となる(キケン)

ということがわかる。これらは一意性を保つための情報としては不適切じゃないかと思う。

ここらへんの危険物を避けた上で、残りものを用途別に見ていくと、

UUID

端末内の一意な名称(テンポラリなファイル名など)を区別するために使う。
ただしサーバが介在する場合は、サーバ側でUUID相当のものを発行した方がいいと思う。
(ちなみに、ありがちな{年月日時分秒}.pngみたいなのは、端末時刻をユーザが変更できる環境では一意になるとはいえないため、UUIDを用いること)

UIID

ユーザ認証を持たずにユーザを特定して、サーバとの通信を行うような場合に使う。
アプリ間で共通のIDを持つ必要性がない場合はこれを使うのがよい。
(基本的に意図せぬ範囲にIDが公開されないように、共通性は抑えておいたほうがよいため)

SecureUDID

複数のアプリを提供しているベンダーが、ユーザを特定するためにUDIDの代わりとして使う。
iOS5以前の環境でも利用したい場合のみ、iOS6以降だけならUIDevice.identifierForVendorを使う。

UIDevice.identifierForVendor

複数のアプリを提供しているベンダーが、ユーザを特定するためにUDIDの代わりとして使う。
(使い勝手がいいということで)今後はこれが主流になるかと*4

ASIdentifierManager.advertisingIdentifier

iAdのような広告提供用ライブラリ内で使うなど、かなり特殊用途だと思う。
オプトアウトできるとはいえ、普通の開発者は手を出さないほうがいいかと。


なお、これらのIDでカバーされていない領域の機種変更・複数機種利用は、ここら辺はOAuthなどのアクセストークンと組み合わせて繋げておくべきところだと思う。

*1:同じIDが今後も含め二度と振られないという(理論上ほぼ完全な)一意性を持つかどうか

*2:たしか携帯電話番号は解約してしばらく経つと同じ番号が振られたはず

*3:中古屋さんに売ったり、友人に譲渡したりというような想定

*4:個人的にはこれ単体で一意とするのではなくUIIDと併用するようにして、必要最低限のものだけ持つように実装してほしい

[memo]Xcodeエラー切り分け

よく出る、

clang failed with exit code 255
A signed resource has been added, modified, or deleted.
コード上絶対に間違っていない箇所なのにビルドエラーになっている
Step実行時にソース行と一致しなかったり、Breakpointが変なところで効いたりする

あたりの現象の話。


これに限らずXcodeを使っていてさっきまで動いていたのに急に摩訶不思議な動きをした場合は、以下のことをやる。

1.もう一度Buildする

exit code 255とかはこれでうまくいくことが多い(なんで?)

2.CleanしてからBuildする

これで直るとうれしい。

3. 一度プロジェクトを閉じた上で、Window > Organizerから該当プロジェクトのDervied Dataを削除する

これで直ることが多いので、最近は2.を飛ばしてる。

4. OSを再起動する

たまにこれで直ることがある。


ここまでやって直らない場合は、Xcodeの問題というより自分でいじった部分の問題っぽいので、あれこれ切り分ける。
たとえば、人からもらったプロジェクトの場合は、相手のXcodeのバージョンを聞いて自分の方が古かったらアップデートすると動いたりとかする。


なんにせよ、もうちょっと安定して動いてくれないですかねー。