ただつらつらと日記が書かれていくようです。

カテゴリー: ITめいたこと (13ページ目 (31ページ中))

Amazon Cloud Driveのデスクトップアプリがなくなった。

ちょうど一年前くらいに「Amazon Cloud Driveが直らない…」って記事を書いて、Amazon Cloud Driveのデスクトップアプリを改善して欲しいなぁ…なんてことを書いて、しばらくほったらかしにしてて、ふと新しいバージョン出てるかなと思って調べてみたら、こうなっていた。

Cloud Driveデスクトップアプリについて

Cloud DriveデスクトップアプリをAmazon.co.jpからインストールすることはできなくなりました。すでにコンピュータへインストールされている場合は、引き続き、ファイル、写真およびビデオをCloud Driveにアップロードできます。Cloud Driveデスクトップアプリをアンインストールすると、再度インストールすることはできません。ウェブサイト上のCloud Driveで、ファイル、写真およびビデオをアップロードしてください。

まぁ、ブラウザを使ってアップロードできるんだから、そっちでやってくれということか。まぁ、最近、Webサイトもリニューアルしたみたいだしな。Amazonとしては、Webサイトに訪問してもらって、うっかりついで買いしてもらった方がメリットあるだろうし。

というわけで、まともに動かなかったAmazon Cloud Driveのデスクトップアプリはアンインストールすることになるだろうなぁと…。

LGのG2のカメラ

ドコモがオンラインショップで叩き売りしてたLGのG2…ドコモの型番だとL-01Fなんだけど、このカメラアプリがちょっとなぁ。

まぁ、夏の暑い日にズボンのポケット入れたまま歩いて、ポケットから引っ張り出して写真を撮ろうとしたら「高熱のためカメラが起動できません」みたいなメッセージが出てきてカメラが使えないのは120歩譲って許す(とはいえ、XperiaでもGalaxyでも、似たようなことしてたはずだけど、そんなメッセージを見たこともなければ、壊れたこともないんだけど、まぁ、保護機能だから壊れてからじゃ遅いと言われりゃ、そのとおり)

普通にカメラアプリで写真を撮って、カメラアプリ内のサムネイルまで作成されるのに、後から、その写真を探しても記録されてないってのは何とかならないのかなぁ…。

ふと、可能性として思いついたのは…。高解像度で撮って、さっさとカメラアプリを閉じちゃうから、写真データをストレージに書き込んでるうちに、アプリが落ちちゃってるのかもしれないけど、もしそうなら、それってどうにかなんないのかな(汗)

…とりあえず、切り分けか…

追記:
やはり、カメラアプリからストレージに写真が記録されなくなってしまうと、再起動かけないと記録できる状態に戻らないような雰囲気。そして、再起動かけると、撮った後、ぱぱっとカメラアプリからホームに戻っても写真は記録されてた。もしかすると、メインメモリの空き状況の影響とかあるんだろうか。うーむ

LinodeとかDigitalOceanとか。

Linodeのリージョンが東京にあることに気づいて、早速、アカウント作ってインスタンスを立ててみた。

Linode TokyoはどうやらKDDIのデータセンターにあるらしく、同じくKDDI系のCloud Coreのインスタンスにping打ってみたら2msくらいで返ってきた(笑)あと、千葉のフレッツ網からのpingも20msくらいでネットワーク的にはかなり快適。DigitalOceanの西海岸だと太平洋越えで100ms超えるし、同じくDigitalOceanのシンガポールも100ms超えてたことを考えると意外と悪くないかも。メモリーは1GBしかないけど、ストレージはSSDだし。

しかしまぁ、AWSとかGoogleのクラウドが細かくネットワークセキュリティに配慮した仕組みを備えている一方、LinodeやDigitalOceanみたいな、安い系のVPS屋さんの「細かいことは気にしない」系のインスタンスは、何個もインスタンスたてると大変かも知れないけど、ちょっと1小インスタンス立ててWordPressでも運用してみようかなみたいな用途には悪くないかもしれない。とりあえずVPCみたいな仕組みは大掛かり過ぎるし、インスタンスでiptablesも使えるわけだし。

インスタンスが起動したら、とりあえずsshでルートログインさせる(rootパスワードを起動時にwebから入力させるのがLinodeで、DigitalOceanはメールで送られてくるんだったか)感じはなかなかドキドキしないでもないけど。

もし、初期ログインの後、ユーザーが適切に設定を変えられるのであれば、最初の導入時だけ雑なる感じになってしまうのもしょうがない…のかな(遠い目)

スマホ向けの動画をエンコードした。

今日、iPhone5で撮影したムービーファイルをもらったが、フルHDで撮影してあったので長さが90秒しかないにも関わらず、ファイルサイズが200MBあった(汗)その動画を撮影した人には、一緒に写っている人にシェアして欲しいと言われたけれど、このサイズで配布する必然性がほぼない(かつ、もらってもちょっと迷惑か)ような気がしたのでffmpegでサイズを小さくしてムービーのファイルサイズを縮小することにした。

とりあえず、普通にflvに変換してflowplayerを使ってWebで見られる状態にすることは出来たけど、PCでWebサイトを見てるときに動画を再生できるだけじゃなくて、スマホに動画をダウンロードしてネットワークに接続してなくても動画を再生したいというニーズがでてきて「スマホで見られる」mp4を作る必要がでてきたので試行錯誤してみた。

やったこと的には、mp4のプロファイルをbaselineにしてレベルを3.1にしてみた。一応、このレベルだと映像のビットレートがまぁまぁ高くても問題なさそうな気がするけど、ドコモのメディアプレーヤーではエラーが出て再生できなかった(汗)ので、ちょびちょびビットレートを下げていって、640×360って解像度の700k/sでエンコードしたら、ちょっと古いAndroidとかiPhone4でも再生できるmp4を作ることができた。

ちょうど、以下のようなコマンドでmp4を作った。

ffmpeg -i xxxxx.MOV -vcodec libx264 -ar 44100 -b:v 700k -aspect 16:9 -s 640×360 -profile:v baseline -level 3.1 xxxxxx.mp4

DigitalOceanでdroplet作ったらSwap追加

ちょっと検証しようと思うことがあって、久方ぶりにDigitalOceanでDropletを作ってみた。しかも、なぜだか分からないけど、CentOSのクリーンインストールをしてみることにした。で、初期設定からごそごそやってて、ふと思い出したのが、DigitalOceanでCentOSでDropletを立てた場合(他のUbuntuとかでも同じだと思うけど)、Swapが設定されていないということ。

ケチったdroplet(汗)を立てているのでメモリが少なく、起動してるプロセスがOOM Killerの餌食になる可能性が少なからず存在しているかなと。まぁ、大したことをやっているわけじゃないのでOOM Killerに落とされたところでどうってことはないけれど、多少のswapで回避できるならそっちが楽かもしれない。

というわけで、DigitalOceanのWebサイトにswapの作り方が載ってたのでメモ。Difficultyがbeginnerになっているけど、dropletを新しくセットアップするタイミングでしかやらないので忘れがち(汗)

How To Add Swap on CentOS 6:
https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-centos-6

OCNモバイルONEのIPアドレスを逆引きしたら。

どうでもいいことだけど、ひさびさにOCNのモバイルONEのSIMカードを指してるAndroidから確認くんでIPアドレスを確認して逆引きしてみたら、「pxxxxxx-omed01.osaka.ocn.ne.jp」になっていた。

いや、あのー、私は千葉にいてスマホをいじっているんだけど、インターネットに抜けているのは大阪なのか。しかしまぁ、無線部分のディレイが大きいから、東京でインターネットにつながってようが、大阪でインターネットにつながってようが、実質的にはあんまり差が無い気はするから、どっちでもいいことか。

OCNモバイルONEって、少し前は東京でインターネットにつながっていたような気がするんだけどなぁ、気のせいかな。いやはや。

[amazonjs asin=”B014GZEPPK” locale=”JP” title=”【Amazon.co.jp限定】 IIJmio SIMカード ウェルカムパック microSIM 版 フラストレーションフリーパッケージ (FFP) IM-B095″]

シンガポールにはオーストラリアより東京の方が近かった。

まぁ、物理的な距離を考えると、そんなことはあり得ないけど、先日借りた、DigitalOceanのシンガポールリージョンにあるVPSから、PHPのソースコードをダウンロードしてみた。PHPのソースは世界中のサーバでホスティングされているし、容量もめちゃくyちゃ大きいわけでもないし、そんなに小さいわけでもないので、試してみるにはイイ感じということで。

ダウンロードさせてもらったのは、以下の3つのサーバ。本来なら、何回か試してみるべきなんだろうけど1回だけ試してみた(ので、たまたま、向こうのサーバの負荷が高かったりしたら影響を受けてるな)で、wgetで表示される、平均スループットも書いておきますよ、と。

  • jp2.php.net(snotch)@日本:4.46M/s
  • at1.php.net(Goodie Domain Service)@オーストラリア:261K/s
  • us1.php.net(NEXCESS.NET)@アメリカ:2.74M/s

うーむ、シンガポールからはオーストラリアは遠いんだなぁ、と思ったが、結局は海底ケーブルがどれだけ這っているかってところに依存してるから、物理的な距離はあんまり関係ないんだろうな。いやはや。

てか、Googleはオーストラリアでドメイン管理事業やってるのかっ!と思ったら、Googleじゃなくて、Goodieだった(汗)

あ、facebookが落ちてる。

あ、facebookが落ちてるなぁ。意外とfacebookのsorry page見るのは初めてかも。いろんなサイトに貼ってある、facebookのボタン(…うちのサイトのfabookボタンが妙な感じだ…)も軒並みアレな感じ。facebook、大規模な攻撃でも受けたのかな。

facebookが落ちている。

facebookが落ちている。

ap-northeast-1bが復活してる

もう見飽き始めている、AWSのマネジメントコンソールを今日も眺めていたら、しばらく消えていたはずの「ap-northeast-1b」ってAZが復活しているのが見えた。まぁ、さすがにap-northeast-1aとap-northeast-1cって構成も不自然だしなぁ。

ま、きっと、東京リージョンは3AZ体制で運用するんだろうな。

m1.smallのswap領域にエフェメラルストレージ。

EC2でm1.smallなインスタンスを起動してみた(本当はm3.mediumがいいんだけど、予算が足りない…。m3.smallとか用意してくれないだろうかって無理か)。AmazonLinuxを使ってたら、swapをどうするか心配しなくていいんだろうけど、やはりお金がない状況下なのでCentOS6を選択。

そしたら、swapが存在しない。EBSの上にファイルを作ってswapにしてもいいけど、データの出し入れで課金されるタイプのストレージを使ってたら(ま、たいした金額にはならないような気はするけど)、なかなか切ないことになりそうだけど、インスタンスストアというか、エフェメラルストレージを使ってswap領域を作ることにした。

…とはいえ、インスタンスストアを起動時に割り当てておいて、後は、/etc/rc.d/rc.localに対して、

mkswap /dev/xvdf
swapon /dev/xvdf

を追記しただけなんだけど。そしたら、m1.smallは、エフェメラルストレージとして160GBのHDDのストレージが使えるので、160GBのスワップ領域ができた(汗)なんかでかい。

起動時に/dev/xvdfに対してext4あたりのファイルシステムを作って、そこにファイルを置いて、それをswapに使ってもいいような気がしたのでちょっと試してみた。HDDの160GBの領域にファイルシステムを構築するのに時間がかかるのが…ちょっとなぁ。再起動がかかった後、(ファイルシステム作ってて)立ち上がってくるのに時間かかるのが実に微妙。うーむ。

«過去の 投稿 新しい 投稿 »