社会人教育にはめったに出てこない、新人に教えたい便利なスキルを列挙。
・EXCEL VBA
・UNIX/Linux シェルスクリプト
・Ant
・VBScript/JScript
2009年9月26日土曜日
iPhoneのAPNs
最近仕事でiPhoneを使った業務システムの開発を行った。
社内PCからiPhoneへ向けたメッセージを送信するのに、
apple社のAPNs(Apple Push Notification service)を使用したので、
覚えたことをメモ。
・APNs番号について
APNs番号とは、iPhoneのデバイスIDとアプリケーションのBundleIdentifierが紐付けられた、端末を一意に特定するための番号。半角英数で64文字。
APNs番号の作成タイミング:iPhoneアプリからappleAPNsサーバに初回アクセスに行ったとき、appleAPNsサーバで発行し、iPhoneアプリに戻してくる。
・プロビジョニングプロファイルとプロバイダ証明書について
プロビジョニングプロファイルは、開発用(Development)と商用(Production)が存在する。
それぞれ違いはあるが、注意すべきは、Productionが有効になっている場合、Developmentは無効になるということ。つまり、Production登録したあとは、iPhoneアプリに食わせるプロビジョニングプロファイルも、プロバイダサーバに置く証明書(pemファイル)も、Production版の証明書をキーチェーンからExportして使用しなければならない。
おそらく、APNsサーバ内で制御しているのだろう、APNsのテスト機(gateway.sandbox.push.apple.com)へアクセスしても、反応してくれなくなる。
参考:
iPhoneアプリで稼げるのか:PushNotificationの実装方法
Push Notification 用フレームワーク
社内PCからiPhoneへ向けたメッセージを送信するのに、
apple社のAPNs(Apple Push Notification service)を使用したので、
覚えたことをメモ。
・APNs番号について
APNs番号とは、iPhoneのデバイスIDとアプリケーションのBundleIdentifierが紐付けられた、端末を一意に特定するための番号。半角英数で64文字。
APNs番号の作成タイミング:iPhoneアプリからappleAPNsサーバに初回アクセスに行ったとき、appleAPNsサーバで発行し、iPhoneアプリに戻してくる。
・プロビジョニングプロファイルとプロバイダ証明書について
プロビジョニングプロファイルは、開発用(Development)と商用(Production)が存在する。
それぞれ違いはあるが、注意すべきは、Productionが有効になっている場合、Developmentは無効になるということ。つまり、Production登録したあとは、iPhoneアプリに食わせるプロビジョニングプロファイルも、プロバイダサーバに置く証明書(pemファイル)も、Production版の証明書をキーチェーンからExportして使用しなければならない。
おそらく、APNsサーバ内で制御しているのだろう、APNsのテスト機(gateway.sandbox.push.apple.com)へアクセスしても、反応してくれなくなる。
参考:
iPhoneアプリで稼げるのか:PushNotificationの実装方法
Push Notification 用フレームワーク
Antの基礎
最近Antでのビルド環境を構築しているので、覚えたことをメモ。
・環境変数を取得する
・ビルドバージョンファイルを自動生成
こうすると、バージョンファイルが存在しない場合は生成し、存在する場合はビルド番号を1足してくれる。作成するアーカイブに取り込むようにする。
・他のビルドファイルを取り込む
まさにjavaのextendsのように、ビルドファイルも取り込むことができる。
参考:
公式ドキュメント
Hidedama's Ant Memo
・環境変数を取得する
<property environment="env"/>
<path id="ENV.TARGET">
<fileset dir="${env.libpath}" includes="*.jar"/>
</path>
・ビルドバージョンファイルを自動生成
<buildnumber file="src/build_version.properties"/>
こうすると、バージョンファイルが存在しない場合は生成し、存在する場合はビルド番号を1足してくれる。作成するアーカイブに取り込むようにする。
・他のビルドファイルを取り込む
まさにjavaのextendsのように、ビルドファイルも取り込むことができる。
<import file="../common_build.xml"/>取り込んだビルドファイルに定義しているターゲットでも、自分のターゲット名を同じにすればオーバーライドできる。
参考:
公式ドキュメント
Hidedama's Ant Memo
教訓 ライブラリ・ソース管理
仕事をしていて感じたこと、トラブルプロジェクトでの経験を生かして、
ここに教訓を書いておく。
ライブラリ・ソース管理
大規模開発において、必ずトラブルが発生するライブラリ・ソース管理。
開発するに当たって相当の工数を取られてしまうのが現状だと思われる。
管理を簡素化するためにいくつか覚書。
(1)ディレクトリ構造を同一にする
開発を行うメンバーは、開発に関する全てのディレクトリ構造を同一にする。
(2)ソース管理はバージョン管理ソフトを使用する
ソース管理は、フォルダを分けて「old」「new」などやるのは時間と手間の無駄。
バージョン管理ソフトを導入する。
VSS(Visual Source Safe)やCVS、SVN(Subversion)など。
CVSとSVNはフリーなので、導入が楽かもしれない。
VSSはファイルベースの管理ソフトなので、サーバが不要。ネットワークフォルダとクライアントソフトがあればOK。
SVNはサーバソフトとクライアントソフトが必要で、通常SVNといわれているのはサーバソフトのこと。SVNクライアントでは、TortoiseSVN(トータスSVN)がWindowsシェル統合で使いやすい。
(3)プロジェクトファイルを共有する
EclipseやVisualStudioなど、統合開発環境(IDE)のプロジェクトは必ず共有し、全メンバーで同一のものを使用する。
IDEのプロジェクトファイルには、様々な設定(例えばjavaの開発ならクラスパスや参照ライブラリの設定)が入っているため、各メンバーでバラバラの設定を持ってしまうと、ソースを新しくすると動かなくなる、などの事態が発生する。当然プロジェクトファイルもバージョン管理する。
(4)ビルド・メイク環境を一つにする
プログラムのビルド・メイクは、必ず一つの環境とし、バージョン情報を付加する。
ここに教訓を書いておく。
ライブラリ・ソース管理
大規模開発において、必ずトラブルが発生するライブラリ・ソース管理。
開発するに当たって相当の工数を取られてしまうのが現状だと思われる。
管理を簡素化するためにいくつか覚書。
(1)ディレクトリ構造を同一にする
開発を行うメンバーは、開発に関する全てのディレクトリ構造を同一にする。
(2)ソース管理はバージョン管理ソフトを使用する
ソース管理は、フォルダを分けて「old」「new」などやるのは時間と手間の無駄。
バージョン管理ソフトを導入する。
VSS(Visual Source Safe)やCVS、SVN(Subversion)など。
CVSとSVNはフリーなので、導入が楽かもしれない。
VSSはファイルベースの管理ソフトなので、サーバが不要。ネットワークフォルダとクライアントソフトがあればOK。
SVNはサーバソフトとクライアントソフトが必要で、通常SVNといわれているのはサーバソフトのこと。SVNクライアントでは、TortoiseSVN(トータスSVN)がWindowsシェル統合で使いやすい。
(3)プロジェクトファイルを共有する
EclipseやVisualStudioなど、統合開発環境(IDE)のプロジェクトは必ず共有し、全メンバーで同一のものを使用する。
IDEのプロジェクトファイルには、様々な設定(例えばjavaの開発ならクラスパスや参照ライブラリの設定)が入っているため、各メンバーでバラバラの設定を持ってしまうと、ソースを新しくすると動かなくなる、などの事態が発生する。当然プロジェクトファイルもバージョン管理する。
(4)ビルド・メイク環境を一つにする
プログラムのビルド・メイクは、必ず一つの環境とし、バージョン情報を付加する。
教訓 外国人SE
仕事をしていて感じたこと、トラブルプロジェクトでの経験を生かして、
ここに教訓を書いておく。
外国人SE
原価低減のため、外国人SEを投入することが多い。
まぁ結局高くつくことが多いわけだが、それは指示を与える日本人の問題。
外国人SEの方が技術レベルが高いことが多く、
使いようによってはうまくいくはず。(うまくいったのを見たことないが)
(1)資料を作らせるときは、枠を予め決めておく
外国人SEに資料を作らせる際、「こうこうこういう資料を作れ」という指示はNG。
こちらでほしい資料を作ってくれることなど絶対にない。(日本人でも無理だと思う)
そのため、例えばエクセルの一覧を作らせる場合は、予め枠、つまりカラム名を全て書き、
「そのカラムには何を書くのか」という説明をつけて渡す。
そして、「このエクセルの空白を埋めろ」という指示を出す。
また、文章での資料などがほしい場合、章立てを予め作っておく。
そして、あるならサンプルを渡す。サンプルがなければ、「この章にはこういうことを書く」という説明をつける。
(2)日本語での会話は信じない
日本に仕事をしている外国人SEの中には、流暢に日本語を話せる人もいる。
しかし、その人は日本人ではない。
日本の文化として、「阿吽の呼吸」や「暗黙の了解」などがあるが、
その人には通用しない。
外国人SEに限ったことではないが、こちらには当然のことが、外国人には当然でないことがほとんどである。
もしコミュニケーションをとるなら、メモやメールなど、文章・図にまとめさせるほうが良い。
会話よりまだましだ。
(3)慣習を教え込む
外国人SEの中には日本のシステム開発での慣習を理解している人もいる。
例えば、本番サーバに気軽にアクセスしないことや、勝手にテストモジュールを入れ替えたりしない、など。
だが、外国人SEの下にいる(まさに母国語しか話せない人たち)プログラマは守ってくれない。
やってしまう人がいる場合、すぐさま注意し、やってはいけないことを理解させる。
ここに教訓を書いておく。
外国人SE
原価低減のため、外国人SEを投入することが多い。
まぁ結局高くつくことが多いわけだが、それは指示を与える日本人の問題。
外国人SEの方が技術レベルが高いことが多く、
使いようによってはうまくいくはず。(うまくいったのを見たことないが)
(1)資料を作らせるときは、枠を予め決めておく
外国人SEに資料を作らせる際、「こうこうこういう資料を作れ」という指示はNG。
こちらでほしい資料を作ってくれることなど絶対にない。(日本人でも無理だと思う)
そのため、例えばエクセルの一覧を作らせる場合は、予め枠、つまりカラム名を全て書き、
「そのカラムには何を書くのか」という説明をつけて渡す。
そして、「このエクセルの空白を埋めろ」という指示を出す。
また、文章での資料などがほしい場合、章立てを予め作っておく。
そして、あるならサンプルを渡す。サンプルがなければ、「この章にはこういうことを書く」という説明をつける。
(2)日本語での会話は信じない
日本に仕事をしている外国人SEの中には、流暢に日本語を話せる人もいる。
しかし、その人は日本人ではない。
日本の文化として、「阿吽の呼吸」や「暗黙の了解」などがあるが、
その人には通用しない。
外国人SEに限ったことではないが、こちらには当然のことが、外国人には当然でないことがほとんどである。
もしコミュニケーションをとるなら、メモやメールなど、文章・図にまとめさせるほうが良い。
会話よりまだましだ。
(3)慣習を教え込む
外国人SEの中には日本のシステム開発での慣習を理解している人もいる。
例えば、本番サーバに気軽にアクセスしないことや、勝手にテストモジュールを入れ替えたりしない、など。
だが、外国人SEの下にいる(まさに母国語しか話せない人たち)プログラマは守ってくれない。
やってしまう人がいる場合、すぐさま注意し、やってはいけないことを理解させる。
教訓 開発環境を整える
仕事をしていて感じたこと、トラブルプロジェクトでの経験を生かして、
ここに教訓を書いておく。
開発環境を整える
トラブルプロジェクトの場合は特にだが、急にメンバーを増員することが多い。
急に人が増えたところで、開発環境についての資料がないと、無駄に終わることが多い。それだけならまだしも、開発当初からのメンバーが質問攻めに合うこと必至。
そんなときのために、環境資料を必ず先にまとめておく。
(1)テスト機の情報を一覧にまとめる。
論理サーバ名、ホスト名、IPアドレス、リモート接続プロトコル、OSログインユーザ、パスワード、注意点など。
(2)各テスト機の起動・停止など、システム操作の手順を処理フローと一覧にまとめる。
例)
(3)作成したアプリケーションが出力するログのパスを一覧にする。
(4)アプリケーションのテストにログインが必要な場合、ユーザ一覧を作成する。
その際、そのユーザを誰が(どのチームが)使用するかを明確にする。
ここに教訓を書いておく。
開発環境を整える
トラブルプロジェクトの場合は特にだが、急にメンバーを増員することが多い。
急に人が増えたところで、開発環境についての資料がないと、無駄に終わることが多い。それだけならまだしも、開発当初からのメンバーが質問攻めに合うこと必至。
そんなときのために、環境資料を必ず先にまとめておく。
(1)テスト機の情報を一覧にまとめる。
論理サーバ名、ホスト名、IPアドレス、リモート接続プロトコル、OSログインユーザ、パスワード、注意点など。
(2)各テスト機の起動・停止など、システム操作の手順を処理フローと一覧にまとめる。
例)
(3)作成したアプリケーションが出力するログのパスを一覧にする。
(4)アプリケーションのテストにログインが必要な場合、ユーザ一覧を作成する。
その際、そのユーザを誰が(どのチームが)使用するかを明確にする。
登録:
投稿 (Atom)