mosh + 公開鍵認証

遠くにあるサーバへsshでリモート接続して作業してると、たまにキー入力に対するレスポンスが悪くて悲しくなります。

 そんなときはmosh(mobile shell)を使うと少し悲しさが減ります。

便利機能や設定方法はgoogleに聞いてもらえればいいのですが、普段使っているsshの公開鍵認証の使い方が見当たらなかったので書いてみます。

→ こちらの~/.ssh/configの設定の方が普段使うには便利そう.

目的:

   ssh+公開鍵認証 を moshでも使いたい

方法:

mosh --ssh="ssh -p $(port) -i $(private_key)" user@host

補足:

  moshには"--ssh" オプションがあってmoshの中でsshセッションを開始するときに実行するコマンド名とオプションを渡せる様子です。

 ということで、普段こんなコマンドを叩いている人は、

ssh -p 3001 -i ~/.ssh/id_rsa user@hostname

  こんな感じに置き換えて、クライアント側で実行するといい感じです。

mosh --ssh ="ssh -p 3001 -i ~/.ssh/id_rsa" user@hostname

分かりやすいiOSアプリのリンクURLの作り方

日頃お世話になっているStackOverflowからのメモ。

元記事：How to link to apps on the app store

AppStoreで公開されているiOSアプリへのリンクURLを作る方法。

Company Name, Application NameからURLが作れるらしい。

• 特定のiOSアプリへのリンク先URL
• http://itunes.com/apps/#{appname}
• 特定のdeveloperが作っているiOSアプリのリストへのリンク先URL
• http://itunes.com/apps/#{companyname}
• 特定のdeveloper/iOSアプリへのリンク先URL
• http://itunes.com/apps/#{companyrname}/#{appname}

URLの先頭が"http://"のままだと、リンク先を開いたときにリダイレクトが入るらしい。

リダイレクトさせたくないときは、URLのスキーム部分を"itms-apps://"にする。

#{appname}, #{companyname}の部分は適宜入れ替えて使う感じの様子。


例) chrome appへのリンク先

• http://itunes.com/apps/googleinc/chrome
• itms-apps://itunes.com/apps/googleinc/chrome

メモ："Google, Inc." => "googleinc"、"Chrome" => "chrome"に変換されてます(ルールは下記参照)


ここの#{appname}, #{companyname}は以下のルールに従ってフォーマットする必要があるらしい。

1. whitespaceを削除
2. すべて小文字に
3. copyright(©), trademark(™), registered mark(®)は削除
4. "&"は"and"にすべて置換
5. 以下の記号は全部削除
   !¡"#$%'()*+,\-./:;<=>¿?@[\]^_`{|}~
6. Replace accented and other "decorated" characters (ü, å, etc.) with their elemental character (u, a, etc.)
   (最後の文はしんどかったのでそのまま。雰囲気で感じてください)

詳しくは、以下のサイトを。

Technical Q&A QA1633 Creating easy-to-read links to the App Store for your applications and company

Mr.Childrenの出したニューアルバムのTestCase

Mr.Childrenの出したニューアルバム「[(an imitation) blood orange]」の名前が(objective-c的に気持ち悪いので)動くかどうかTestCaseを書いてみた。


きちんと動いた。

「シェアする/共有する」という表現

まだまだ不勉強なのですが、個人的に感じている気持ちをメモしてみます。

最近いろんなサイトやアプリケーションで目にする「シェアする/共有する」といった表現が気持ち悪いなーと感じてます。


人が「すばらしい」と思う情報を見つけたときは、こんなフローがあるのではないかなと。

1. ユーザが何かの対象に対して抱いた感情とか気持ちが沸き上がり、
2. その気持ちから何かのアクションが生まれ、
3. そのアクションの結果がユーザのネットワークを通して周囲の人に伝播する。

「シェアする/共有する」は、「情報を周りの人に伝えることが目的の、感情や気持ちを表現しない単純な動作」という表現と感じてしまいます。
そのため、上記のフローの最初にある「人の感情や気持ち」が欠けてしまっている気がして、これが個人的に気持ち悪く感じている理由な気がしています。

そんな理由から、個人的にはfacebookのlikeやgoogle plusの+1、昔のdiggとかであったthumbs up/downとかの表現はすばらしいと思います。

「シェアする/共有する」は、コンテンツをいろんな人に伝えてほしい情報提供者側の気持ちが多く込められていて、ユーザ視点からの表現ではない気がします。

いろんなサイトで安易に「シェアする/共有する」操作を追加するのよりも、提供するコンテンツにあった感情も表現できるアクションをつけてあげるといいのではないでしょうか？

カスタムUIActivityのアイコン画像

iOS6でUIActivityViewControllerが追加されました。

これまでテキストや画像などなどに対するAction(iOS6でのUIActivity)をユーザに提示する簡単な方法としてUIActionSheetを使う方法がありましたが、それに変わる手段としてUIActivityViewControllerが追加されました。

アプリケーションでカスタムUIActivityを追加する方法も提供されており、
すでにCocoa ControlsでInstagramへshareするDMActivityInstagram for iOSが登録されているようです。(動作確認はしてないですが、カスタムActionが気になる人はコードを読んでみましょう)

ここでカスタムActionのアイコン画像について少し調べたのでメモ。

MailやTwitter、Facebookのアイコンのようにカラフルな透過領域のないアイコン画像を用意しても、白いグラデーションのかかったアイコンになってしまいます。

透過領域のないアイコンを使うと、塗りつぶされた感じに。

UIActivity Class Referenceにある activityImageメソッドの説明をよく読んでみると、いろいろと書かれてまして、試してみた結果としては以下が判りました。

iOS6で用意されているCopyするActionのアイコン

• アイコン画像の透過領域はマスクされて金網っぽい画像が表示される。
  (上のcopyアイコンでいうと、外枠と内側のファイルっぽいアイコンの間の領域)
• アイコン画像の色は無視されて単一色のグラデーションがかかった感じになる。
  (上のcopyアイコンでいうと、ファイルっぽいアイコンの色)

補足:アイコン画像はiphone用に43x43(86x86 for Retina Display)、ipad用に55x55(110x110 for Retina Display)がそれぞれ必要みたいです。

つまり、用意する画像ファイルは、「背景透過にしてアイコンを書いた画像」を用意するとcopyアイコンのようないい感じになるようです。(アイコンは何色で書いても、グラデーションのかかった単一色になるようです)

背景透過にアイコンを書いた画像だといい感じに。

とりあえず、今判った範囲ではMailやTwitter, Facebookと同じようなカラフルなアイコンは追加できない様子でした。

残念。

DashにiOS6のdocsetを追加する方法

DashというアプリにiOS6のdocsetを追加する方法

Dashについての説明は他の場所に譲るとして、
ここでは自分の環境で起きてたiOS6のdocsetがDashに追加できなかった件の対処方法をメモします。

0. 最初の状態

Xcode(4.5)をインストールした後でもPreferenceからみるとiOS6のドキュメントはインストールされた状態と表示されていました。

　　このときのiOS6のdocsetは以下のようなパスにあると表示されてました。

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Documentation/DocSets/com.apple.adc.documentation.AppleiOS6.0.iOSLibrary.docset

パスをみると判るように、Xcode.appのサンドボックス内にあるファイルになってます。
そのため、DashのPreferences->Docsetから"+"ボタンで表示されるfinderから選択できずに困っていました。

開発者さんに聞いたところ「finderでひらいてdocsetをダブルクリックすればいいよ」とのこと。

いろいろ試してfinderで開いてdocsetをダブルクリックしたり、itermからopenコマンドで開いてみたりしてみたのですが、「おかしなdocsetみたいだからダウンロードし直して試してみて」とDashからエラーダイアログが表示される状態でした。


1. 対処方法

XcodeのPreferenceの"Check for and install updates automatically"にチェックを入れると、iOS6のdocumentがアップデートされました。

アップデートが終わった後のiOS6のdocsetは以下の場所にパスが変わっていました。

/Users/<AccountName>/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.AppleiOS6.0.iOSLibrary.docset

その後でDashのPreferenceを開いてDocsetsタブの右下にあるリロードっぽいボタンを押します。

これでめでたく"iOS 6.0 Documentation Set"が追加されました。

OAuth2.0の行き着く先

今更感たっぷりなのだけど、OAuth2.0って1.0から何が変わったのか調べていたらこんな記事に行き着いた。

OAuth 2.0 and the Road to Hell (2012/07/26の記事)

OAuth2.0について少し調べた程度しか予備知識が無いので深い事はわからないのだけれど、上記記事の筆者(Eran Hammerさん)がOAuth2.0が曖昧でひどいものになってしまい手がつけられなくなってしまったため、諦めて手を引くとかいう話の様子。

「OAuth1.0でうまくやってるのならOAuth2.0にアップグレードすることに価値はないし、OAuth2.0を使うのなら信頼できるところのソースをつかってきちんと理解して使わないといけないよ。」とか。

(他に何があるのかは知らないけど) Web2.0と同じように、2.0がつくものはあまり良くない結果になるという事なんだろうか。

ちょっとがっかりだけど、気を取り直してOAuth 2.0の中身について勉強しないと。

[追記] 上記記事の続きがあったので追記

On Leaving OAuth

こちらも併せて読んでみるとおもしろそう。