Home > アーカイブ > 2010-05

2010-05

iPadでPHP開発ができるか試してみた

この記事の所要時間: 439

ついにiPadが日本でも発売になりました。早速入手できたので色々と触ってみました。

使ってみた印象としては「大きくなったiPhone」ですね。操作はiPhoneまんまなのですが、A4プロセッサのおかげか軽快に動作します。またソフトキーボードがかなり改良されていて特に日本語についてはPCのキーボードっぽく入力できます。

とはいえ、やはりMacBookほど多機能ではないので、立ち位置としては見た目どおりiPhone以上MacBook未満という印象です。

そんなiPadで購入前に気になっていたのが、「iPadで開発ができるか?」という点です。もしこれができるなら MacBookは事務所に置いてまま外出先や家ではiPadでこなせるのではと企んでいました。

そこでiPadでPHPが書けるか試してみました。

キーボード

ソフトウェアキーボード

冒頭でも触れたとおり、iPad搭載のソフトウェアキーボードはiPhoneのものと比べると格段に良くなっています。画面拡大によりキーピッチがひろがったおかげで英字だけならPCのキーボード感覚で入力できます。

ただ数字や記号を入力しようとするとキーボード画面の切り替えが必要となります。この切り替えが結構手間でした。

さらに物理的にキーに触れるわけではないのでミスタイプが多くなりがちです。(これは慣れもありますが)

外付けキーボード(App Wireless Keyboard)

ソフトウェアキーボードの欠点を解消すべくBluethoothで接続できるApple Wireless Keyboard (US) MC184LL/Aを購入しました。

さすがにPC用のキーボードだけあって、入力の不満は一切なくなりました。

欠点を一点挙げるなら外付けキーボードだと画面から手が離れるので、画面をタップしたい時やアプリを切り替えたい時に、手を画面まで持っていかないといけないことですね。PCでもマウスを触るのでキーボードから手が離れるのですが、マウスと画面では手を動かす距離が異なるのと、command+tab のようにキーボードだけで画面を切り替えることができないので、そこは慣れが必要です。

あと細かいことですが、キーバインドの変更ができないので、「A」の左のcaps lockをctrlに変更できないのも気になりますね。おかげでCTRLのつもりでcaps lockを押してしまいイラっとなることがしばしばあります><

とはいえ、やはり外付けキーボードの入力のしやすさは格段に良く、ソースコードを書く事自体は何とかなりそうです。

開発環境

ソースコードを書く事ができても実行する環境が無いと開発できません。

iPad自体にPHPの実行環境をインストールできれば一番良いのですが、残念ながらそれはできません。そこでSSHでサーバにログインして開発する方法を試してみました。

iSSH for iPad

SSHクライアントアプリです。

パスワード認証だけでなく公開鍵認証も可能な優れものものです。

ssh-keygenによりキーペアを生成することができ、生成した公開鍵をメールで送信する機能もあります(サーバ側で公開鍵を設定する必要があるので、これは地味に便利)。もちろん既にある秘密鍵をインポートする機能もあります。

そんなiSSHのiPad版ということで期待が膨らみます。早速iPadからサーバにログインしてみました。

バッチリログインできています。もちろんlsやfreeなどコマンドも動作しています。

ログインしてしまえばこっちのものです。次にvimでCakePHPのソースを開いてみました。

おおーいけますね。もちろんカーソル操作も編集もできます。

ただ少しばかり編集しだすと壁にぶちあたりました。

なんとiSSHでは外付けキーボードから、ESC、CTRL、TAB、といった特殊キーが入力できないのです。

画面上部には特殊キーが入力できるようにボタンが用意されているのですが、画面をタップする必要があり、毎回それをやるのはかなり面倒です。うーん、これはツライ。。。

CTRLやTABがキーボードから入力できないのはシェル上でも同じで、CTRLを使った操作や TABによる補完なども毎度画面をタップする必要があります。

ちなみに他のアプリではTABやCTRLが効くので、これはiSSHの問題ですね。

他にも日本語表示が若干おかしい、パフォーマンスが遅いなどの問題点があります。このあたりも実際に開発するなら厳しいところですね。

[「iSSH for iPad」をiTunes Storeで開く ]

現状では厳しいかと

試してみた感想としては、入力するという行為については、外付けキーボードを使えばかなりいけます。実はこのエントリの原文はiPadで書いているのですが、日本語をがしがし書いていく分にはそれほど問題ありません。

あとはSSH環境の問題で、現状はサーバにログインした後に面倒な操作を強いられます。もちろん緊急時にサーバに入ってメンテするくらいは問題ないのですが、エディタを起動してバリバリソースを書くというにはまだ厳しいですね。

ただ、これはあくまで現時点での話で、今後はアプリが改善されるかもしれませんし、別のアプリがが登場するかもしれません。さらにiPadのOSも新バージョンが秋に登場する予定です。

そう遠くない時期にiPadで開発ができる日が来ることを期待したいです。

Amazonからメール送信制限に関するEC2 Account Notificationが来た

この記事の所要時間: 437

とあるイベントで使うWebシステムでEC2を使ってたところ、Amazonからメール送信制限に関する通知が来たという話です。

このイベントでは、短時間で多くのリクエストを捌かないといけないので、あらかじめWebサーバを何台か立てて準備していました。さらに想定を超える負荷に備えて、増設用AMIも作成して、すぐに増設できる体制にしていました。もちろん増設のリハーサルもやりました。

そして、イベントが始まります。

アクセスがボチボチ来始めました。リソースにはまだまだ余裕があるので順調に捌いてくれています。とりあえず無難な立ち上がりだなと、ひと安心したところにメールが一通。

EC2 Account Notification

Dear EC2 Customer,
You recently reached a limit on the volume of email you were able to send out of SMTP port 25 on your instance:

Instance ID: i-xxxxxxxx
* IP Address: XXX.XXX.XXX.XXX
* Start date: 2010-NN-NN NN:NN +0000
……

うん?メールの送信制限?何これ?

たしかにメール送信は行っていますが、1hで数十通程度です。しかも一気に送るというよりバラバラと送信しています。この程度で制限がくるとは思わなかったのですが、イベント中に送信を止められるとシャレにならないので、すぐにメールに記載されたフォームからメール送信制限解除申請を送りました。

Request to Remove Email Sending Limitations – Amazon Web Services

本文の内容でググってみると同じようなメールが来た人は何人か見つかったのですが、解決したという内容は見あたりませんでした。中には実際に Port25 をblockされて、仕方なく外部のメールサーバに別ポートで接続してメールを送信している人もいました。

その時点では送信はできていたので、イベントが終わるまではとにかく持ってくれという心境でした。

何とか回避策を

制限解除申請をしたものの、ぼーと待っていても仕方が無いので取れる策をということであれこれやってみました。

まず、送られてきたメールにはインスタンスIDとIPが記載されていたので、別インスタンスとIPなら回避できるかもと思い、作成しておいたAMIから新しいインスタンスを起動しました。さらにElastic IPで別IPを発行しました。これはもともと高負荷時にスケールアウトすることを想定していたのですんなりと準備できました。

ここでふと、もしかするとアカウントを停止させられるかも、という考えが頭をよぎりました。もしそうなると何台増設していても意味がありません。

実際にそうなるかは分かりませんが、とにかく止められないので、新たなアカウントを発行することにしました。てきぱきと登録をこなして、スケールアウト用AMIの共有設定を行い、なんとかLB+Web+DBの構成を構築しました。

あらかじめDNSのTTLは短めにしておいたので、もしアカウントを停止された時はDNSを書き換えて別アカウントの構成にアクセスを向けます。

この間もサービスとしては問題無く稼働していました。

Amazonからメールが

あれこれやっているとAmazonからメールが来ました。

内容は「申請を受け付けた」「2営業日以内に回答するよ」といったもの。2営業日以内って!とか思いつつ、とにかく回避策をひたすら準備。

サーバログ(主にmaillog)と睨めっこしながらイベントが無事終わるのを待ちます。inboundもoutboundも変なエラーは無く順調に稼働しています。自分でもサイトにアクセスして試してみますが問題ありません。とにかく無事に終わってくれ。。。

乗り切った!

結局、blockされることなく無事にイベントは乗り切ることができました。やれやれ。

再びAmazonからメールが

無難にイベントが終わって、ひと息ついていた頃に再びAmazonからメールが来ました。

内容は「制限を解除した」とのこと。

本文には申請したインスタンス、IPに対する制限を解除しただけなく、アカウントに紐付く全てのインスタンス、IPに対する制限を解除した、と書かれていました。

対応は2営業日以内と書かれていたのですが、申請から数時間で対応してもらえたのは驚きでした。

イベントはこの日限りで翌日にはサーバを停止する予定だったのですが、今後の利用のためにElastic IPで割り振ったIPだけは残しておくことにします。

EC2からメールを送る際は念のため申請を

イベント中に来たAmazonからのNotificationには本当に焦りました。

それほど多くのメールを送ったわけではなく、どういった基準でこの通知が来るかは分かりません。イベント前のテストでは問題無かったので、閾値は低いものの一定時間中に一定数を外部に送信すると通知される仕組みなのかもしれません。

とにかく、ここぞの時にblockされるとシャレにならないので、EC2から数多くのメール配信を行うなら、あらかじめ制限解除申請をするなり、別環境を用意するなり準備をしておいた方が良いでしょうね。

Support System <engineer@twitter.com>からのメールに注意

この記事の所要時間: 132

Twitter Status – Reports of Fake Twitter Emails」で勧告されているフィッシングメールが来ました。

送信元アドレスは「Support System <engineer@twitter.com>」、件名は「Twitter Message #22」となっています。

本文はHTMLメールとなっており、いかにもTwitterぽいデザインです(以下、画像)。

Twitter Supportからメッセージが来ている旨が書かれていて、その下のリンク(赤枠)へのクリックを促すようになっています。

一見、リンク先はtwitter.comに見えるのですが、実はこのリンク先は別サイトになっています。

このリンク部分のソースが以下です。見事にtymhosting.comという別サイトへのリンクとなっています。

<a href="http://tymhosting.com/microsoft.html">http://twitter.com/account/message/XXXXX-XXXX</a>

本家を騙ったフィッシングメールにご注意を

このメール凝ってますね。送信元アドレスといい、本文デザインといい、本文のリンクといい、思わずクリックしそうになります。

冒頭のTwitter Statusでもあるとおり、Twitterからこういった内容のメールを送ることは無いとのことなので、もしメールが来てもスルーするようにしましょう。

さらに「New Spam Attack Abusing Amazon, Apple, Twitter Email Notification | Symantec Connect」を見ると、AmazonやApple Storeからのメールを騙ったものも来るようです。お気をつけを。

Home > アーカイブ > 2010-05

検索
フィード
メタ情報

Return to page top