サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
TGS2024
mobileapplication.blog.fc2.com
前回の「オレオレ証明書を信頼のおけるSSL証明書にしてみる Vol.2」の続きです。 証明書の準備が出来たので、残るは設定とインストールだけになります。 今回は簡潔に設定方法を紹介します。 01. Apache or nginxへの証明書の設定 ここでは Apache と nginx について設定例を紹介します。 ■Apacheの場合 Apacheの場合、443のVirtualHostディレクティブ内へサーバのSSL証明書、サーバの秘密鍵、サーバのSSL証明書を署名した中間認証局の証明書の3つの情報を設定すればOKです。 具体的には以下のように設定します。 <VirtualHost _default_:443> (...省略...) SSLCertificateFile "/usr/local/ssl/private/server.crt" # サーバのSSL証明書 SSLCertific
なんだか今更かと思われる内容ですが、いわゆるSSLのオレオレ証明書を作成する上で中間証明書についてまで詳しく触れているサイトがネット上で少なかったので、(あるにはあるけど、実運用を考えると今ひとつ面倒な手順だったり…) 今更とはいえ敢えて書いてみることにしました。 (個人的解釈も交えているので多少間違っていたら指摘してください) まずSSL証明書についてですが、いわずとしれたSSL通信を行うために必要な証明書のことです。 このSSL証明書をサーバ上のApacheやnginxなどに設定することで、 SSLによる暗号化通信が行えるようになります。 サーバに設定するSSL証明書は、単に「サーバ証明書」とも呼ばれます。 さて、このサーバへ設定するSSL証明書とはそもそもどういうものなのでしょうか。 一般的にお金を払わないと発行されないものであるけど、オレオレ証明書という自己証明書を作ることもできる
Ruby界隈ではRubyのバージョン管理として rvm から rbenv へシフトしている方が多いかと思うのですが、 この rbenv には少し問題があり、 予めシェルのプロファイルに初期化処理を記述しておく必要があります。 この初期化処理が結構重いです。 初期化処理とはこれ。 eval "$(rbenv init -)" 環境にもよると思いますが、 私が普段利用しているMac+zsh環境では2、3秒掛かることが頻繁にあります。 (キャッシュのヒット率によっては一瞬で起動することもありますが) Linuxでは問題なかったので、Macだけかも知れません。 とはいえ、頻繁にサーバに接続するためにターミナルを立ち上げたり閉じたりを繰り返すので、 そのターミナルが起動するたびに2、3秒掛かってしまうと結構なストレスです。 とりあえず、この rbenv が何をやっているのか見てみました。 (echo
前回の「オレオレ証明書を信頼のおけるSSL証明書にしてみる Vol.1」の続きです。 今回は実際にオレオレルート認証局、オレオレ中間認証局、オレオレSSL証明書を作成する手順を紹介していきます。 01. OpenSSLを認証局作成先サーバへインストールする これがないと始まらないので、手短に説明します。 yumでインストールしてもいいし、ソースからインストールしても構いませんが、 今回はディレクトリのパスを共通化するためにソースからのインストールを紹介します。 cd /usr/local/src wget http://www.openssl.org/source/openssl-1.0.1e.tar.gz tar zxvf openssl-1.0.1e.tar.gz cd openssl-1.0.1e ./config --prefix=/usr/local --openssldir=/
今回は私が実際に社内でSubversionからGitへ移行したときの話をまとめてみました。 うちの社内でもGitに移行したい!と考えている人に、少しでも参考になればと思います。 Gitはもうすっかり世間に浸透してきており、 業界にいる人では利用していない人はいないだろうというくらい多くなって来ました。 しかし、残念なことに未だ日本のIT企業ではSubversionが主流です。 これはGit登場当時、クロスプラットフォームにおける日本語の扱いに問題があったこと、 またWindowsでの動作に不具合が多かったことなどの理由が挙げられます。 かくいう私も、当時はGitよりもWindows対応のしっかりしていたMercurialを推していました。 しかし、Gitもver.1.7.10以降は日本語問題を解決したのと、 Windowsへの対応も大分しっかりしてきたこともあり、 今ではGitを社内SCM
propertiesファイルはご存知の通り 日本語などのマルチバイト文字をUnicodeエスケープ形式で直接書き込むファイル形式です。 これにより、ASCII文字のみでUTF-8な文字を表現できるようになるため、 ファイル自体の文字コードは「ISO-8859-1」で記述するのが一般的になっています。 ↑このような感じでマルチバイト文字をUnicodeエスケープ形式で記述する マルチバイト文字をUnicodeエスケープ形式に変換するツール「native2ascii」がJDKに付属しており、Eclipseだと「プロパティエディタ」などのプラグインが自動で変換してくれます。 これは本来だと上記のようなUnicodeエスケープ形式で記述されているファイルを、日本語表示に戻して表示&編集することが出来、保存時には native2ascii で自動的に変換して保存するといった感じです。つまり、あたかも
AndroidアプリケーションはJavaで記述します。 Javaは非常に柔軟なプログラミングが可能な言語で、登場した当初はガベージコレクションの際に一時停止する遅い言語というイメージでしたが、今やHotSpotを利用するとC/C++よりも速くなる場合があるという、登場当初からは想像もつかなかった言語に成長しています。 前振りはさておき、そんなJavaという言語を利用してAndroidではアプリケーションを開発しますが、AndroidのJavaは他のプラットフォームにおけるJavaとは大きく異なる点があります。 01. static変数はキャッシュ以外の目的で利用してはいけない static変数はアプリケーションが起動してから終了するまで、 ずっと保持され続ける値というイメージがあるかと思います。 これを利用して、例えば予め重い画像処理においてカラーテーブルを作成して、 それをstatic変
Androidでは端末がメモリ不足になり、アプリがバックグラウンドにいる状態の場合、アクティビティのメンバ変数がクリアされてしまいます。 これはAndroidというものに長く触れている方であればご存知のことだと思います。しかし、そのクリアされるタイミングというものを端末によっては自発的に再現できなかったため、それを直に経験した人というのはさほど多くはありません。(端末によってはTask Killerを使うと再現可能) そのため、「どのようなときにメンバ変数がクリアされ、どのようなタイミングで復帰すればいいのか」ということを意識してコーディングしていなかった人が多いのでしょう。前回の static 変数がクリアされる問題と合わせて、こういった問題に対する対処がないことがAndroidアプリケーションの品質低下に繋がっていると考えられます。 では、具体的に対処法について説明していきます。 01
CocoaでiPhoneアプリやMacアプリ開発をしている方なら一度は耳にする単語であるCoreData。これは主にSQLiteをラップし、データとビューのつなぎ合わせを簡潔にすることを目的としたフレームワークライブラリです。(MVCでいうところのModelに当たる)。加えて、Xcodeにおいて標準でCoreDataのエンティティ(テーブル)の作成やリレーションシップの作成をGUI上で行えるようになっているため、一見すると使いやすい印象を受けます。 ところが、現実的にこのライブラリをiPhoneアプリ開発で利用する方はあまり多くないようです。何故利用されないのかといえば、CoreDataにRDBと同じ機能を求めて利用しようとする方が多いからだと考えられます。CoreDataは前述のとおり、MVCでいうところのModelに当たる機能を担うため、ビューやコントローラとも密接に関係するように作ら
AndroidはSQLite3に対応しており、(ただし、外部キー制約がサポートされていないバージョン) これを利用することでデータ管理の自由度が高まります。 Androidでは連想配列方式で手軽にデータ管理ができるプリファレンスというものがあるため、意外に使わないことも多いかも知れませんが、プリファレンスは大量のデータ管理には向いていないということと、RDBのようにトランザクション処理を行うことができないので、そのような管理を行いたい場合はやはりSQLiteを利用する必要が出てきます。 ただし、SQLiteは他のRDBと比べて非常に癖のあるシステムです。Oracle, MySQL, PostgreSQLと同じように使っていると大きくパフォーマンスに影響を及ぼす可能性が多々あります。 また、そもそもAndroidそのものがSQLiteは使いやすくしていません。JDBCで組んでいるのとそれほど
【2011/12/01 追記】 ADT 14.0.0 からライブラリプロジェクトを参照している場合、リソースIDが static final ではなく、ただの static として生成されるようになったので、そのようなプロジェクトの場合はアノテーションでXMLのリソースIDを指定できなくなりました。次回バージョンアップ時に対応致します。バージョンアップ後は、Frontier_android からO/Rマッピングツール部分を FrontierDao という別ライブラリとして分離します。(O/Rマッピング機能だけ利用する場合は、FrontierDao のみをインポートすれば使えるようになります) ------------------- 前回の続きで、実際にO/Rマッピングツールを作成していくことになるのですが、ここで私は「iBATIS (MyBATIS)」とほぼ同じ設計でO/Rマッピングツール
前回、Androidでは端末のメモリが不足するとstatic変数がクリアされたり、 Activityのメンバ変数がクリアされるという問題を紹介しました。 とはいえ、Object型変数であれば常に null になることを想定しなければならないとすると毎回 null チェックをしなければならないことになり、プログラムとしてもかなり可読性が悪いばかりか、不具合発生時に不具合を見逃す可能性も高くなります。 じゃあどうすればいい?ということになりますが、具体的な対処法の前に、まずはstatic変数がクリアされる理由について詳しく紹介します。 01. 端末がメモリ不足になってアプリを再アクティブにした場合、クラスロードから再度実行される 端末がメモリ不足になると、static変数やActivityのメンバ変数がクリアされると紹介しましたが、このとき、Javaとしてどのような動きをするかというと、クラス
FC2ブログが最近使いづらくなってきたのでブログをGithubへ移転しました。 よろしければブックマークの変更をお願い致します。 http://kkoudev.github.io 今回は私が実際に社内でSubversionからGitへ移行したときの話をまとめてみました。 うちの社内でもGitに移行したい!と考えている人に、少しでも参考になればと思います。 Gitはもうすっかり世間に浸透してきており、 業界にいる人では利用していない人はいないだろうというくらい多くなって来ました。 しかし、残念なことに未だ日本のIT企業ではSubversionが主流です。 これはGit登場当時、クロスプラットフォームにおける日本語の扱いに問題があったこと、 またWindowsでの動作に不具合が多かったことなどの理由が挙げられます。 かくいう私も、当時はGitよりもWindows対応のしっかりしていたMercu
iPhoneアプリにおけるメーラアプリは、実はあまり多くありません。(標準メーラと連携するアプリが殆どです) これには多少なりとも理由がありまして、その1つにメール機能をサポートするiOS用ライブラリが殆ど世の中に出ていないという理由があります。有名なところでは「MailCore」というライブラリがありますが、こちらは2009年で開発がストップしているのと、日本語には全く対応していないため日本人には利用できません。 →GitHubで現在も開発が続いているようです。こちらは日本語も可能なようですが、独特の使いにくさは残ったままのようです その他の理由としては、そもそも標準メーラで満足な人が多いことや、海外ではデコメの文化もないため、あまりこのあたりを気合入れて作っている人がいないという理由もあります。 このような背景があるため、iOSでSMTPやIMAPなどを実装することは非常に難しくなって
Mac OS XではFrameworkを作成することが出来ます。 そもそもMac OS XにおけるFrameworkとは何かというと、簡単にいえば「ヘッダやリソースなどをひとまとめにし、複数のバージョンを保持することが出来るライブラリ」といったところです。 システム内において複数のアプリケーションが共有して利用できる機能をライブラリ化しておくことで、各アプリケーションがその処理を個別に実装することなく、単にそのライブラリをロードして利用するだけでよくなるというのが大きな利点でしょう。 そのため、iOSのようにシステムに自作ライブラリを追加できないOSではあまり意味が無いように思われるのですが、このFrameworkという仕組みを利用すると、ヘッダファイルやリソースを一気にまとめることが出来るので、結果的にライブラリの管理がしやすくなりますし、Xcodeプロジェクトへのインポートもこのフレー
このページを最初にブックマークしてみませんか?
『(旧) 猫好きモバイルアプリケーション開発者記録』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く