■Parse.Cloud.useMasterKeyを呼び出すことで特権ユーザー権限になれる
Cloud Code上でACLによるアクセス制限を無視して現在のrequest.userとは関係なしにデータを操作したいということが多々あるかと思います。そのような場合は以下のようにリクエスト処理の先頭でParse.Cloud.useMasterKeyメソッドを呼び出してください。useMasterKeyの効果は呼び出された瞬間からリクエストが終了するまで有効です。
2013年5月2日木曜日
Parse.com の Cloud Code ハマりどころ
Parse.comのCloud Codeを触っていてハマった点や気づきにくい仕様を列挙させて頂きます。
useMasterKeyの効果は呼び出された瞬間からリクエストが終了するまで有効です。
useMasterKeyの効果は呼び出された瞬間からリクエストが終了するまで有効です。
Parse.com使ってみた
いまさらですがBaaS (Backend as a Service) が来てるらしいですので、とりあえずParse.comに手を出してみました。
■良かった所
- クライアント側の実装が楽で安定しています。デバッグログも充実しており、Parseが原因でクラッシュするということもなく、特に悩まされるところはありませんでした。
- 料金がとにかく安いです。個人で使うぶんには全く問題ないかなと思います。
■イマイチだった所
- サーバーがUSなせいもあってそれほどレスポンスはよくありません。
- セキュリティモデルをまじめに構築しようとするとかなり面倒くさいです。
- Cloud Codeに山ほどハマりどころがあります。詳しくは別記事で。
- バッチ（定期実行）に相当するものがありません。自宅のPCをから毎晩のタスクを定期実行するとかそういう悲しい方法で回避するしかありません。
- Dev版と製品版で同じバックエンドを使うことになるので、公開したアプリの継続開発が面倒そうです。これは違う名前で開発版アプリを作ることで回避することができます。
- 料金。エンタープライズで使うときの料金体系が不明瞭で、「連絡してね」の一言で済まされているため不安が残ります。
- データの可搬性。一応Exportオプションは用意されていますが形式が独自形式のJSONなので自前で手元のDBなどへのImportツールを作る必要があり結構面倒だと思います。手軽にExcelやCSVでExportするオプションがほしいです。
■まとめ
プロトタイピングや小規模なアプリには良いと思います。ただしデータ可搬性をまじめに考えるのであればRESTful APIを使う必要があり、そうなってくるとせっかくよくできているクライアント側実装のほとんどが無駄になるため微妙に感じられます。Cloud Codeはハマリどころが多いのがまず問題ですが、わかってしまえば問題ないと思います。
2013年3月24日日曜日
Unity でソースコードに書いたリテラル文字列の文字コードを調べてみた
Unity3.5.6においてソースコード上にリテラル文字列として日本語を置いた時、時々ログ出力が上手くいかないことがあるということがわかり、ちょっと調べてみました。するとリテラル文字列を置いたソースコードの種類に応じて文字コードが違うということがわかりました。
最終的にJSファイルに全ての日本語リテラルをまとめて回避しましたが、そもそも日本語リテラルは使わず国際化文言ファイルみたいなものを別途用意しておいたほうが筋が良いと思います。iOSならLocalizable.stringsがありますしね。
- C# (.cs) はUTF-16
- JS (.js) はUTF-8
- Boo (.boo) は不明
- ネイティブのiOSはUTF-8
最終的にJSファイルに全ての日本語リテラルをまとめて回避しましたが、そもそも日本語リテラルは使わず国際化文言ファイルみたいなものを別途用意しておいたほうが筋が良いと思います。iOSならLocalizable.stringsがありますしね。
2013年1月20日日曜日
SLComposeViewControllerでFacebook投稿する際に投稿が失敗してしまう問題
iOS 6.0より追加されたSocial.frameworkは大変お手軽に使用できて、ユーザーさんも毎回毎回素性の知れないアプリに対してTwitter/Facebookログインをし直すという手間と危険性から開放される便利な代物ですが、ちょっとした落とし穴を見つけたのでご紹介します。
SLComposeViewControllerを使っている時に、同じ文面でもTwitterには正常に投稿できるがFacebookには投稿に失敗してしまうというケースが発生することがあります。画面にはただ「Facebookに投稿できません」とアラートが表示されるだけですし、SLComposeViewControllerは投稿失敗時のerrorに対してコールバックblockもdelegateも存在しないので原因を調べることもできません。
実機のコンソールログを見てみると以下の様なエラーになっています。
対策としてaddURL:しようとしているURLのschemeがnilまたは空文字列だったらaddURL:しないとすればOKです。しかしTwitterでは通るのにFacebookだけ通らないのはなんだか納得いかない・・・＞＜
SLComposeViewControllerを使っている時に、同じ文面でもTwitterには正常に投稿できるがFacebookには投稿に失敗してしまうというケースが発生することがあります。画面にはただ「Facebookに投稿できません」とアラートが表示されるだけですし、SLComposeViewControllerは投稿失敗時のerrorに対してコールバックblockもdelegateも存在しないので原因を調べることもできません。
実機のコンソールログを見てみると以下の様なエラーになっています。
Jan 8 11:01:25 akisute-no-iPhone sociald[6444]SLComposeViewControllerが裏で使用しているsocialdのSLDFacebookPostUploadクラスがエラーを吐いています。一見しただけだとOAuthExceptionとか書いてあって認証系のエラーかと勘違いしてしまいそうですが、実はこれSLComposeViewControllerのaddURL:メソッドに「空の」NSURLインスタンスを渡した時に発生するエラーです。以下のコードで簡単に実験することができます。: 2013-01-08 11:01:25.665|sociald|0x1fd65e70: Request status was 400 Jan 8 11:01:25 akisute-no-iPhone sociald[6444] : 2013-01-08 11:01:25.668|sociald|0x1fd65e70: SLDFacebookPostUpload: The response indicates an error Parameters: {type = immutable dict, count = 1, entries => 2 : {contents = "error"} = {type = immutable dict, count = 3, entries => 0 : {contents = "message"} = {contents = "(#100) The parameter link is required"} 1 : {contents = "type"} = {contents = "OAuthException"} 2 : {contents = "code"} = {value = +100, type = kCFNumberSInt64Type} } } . HTTP status 0
対策としてaddURL:しようとしているURLのschemeがnilまたは空文字列だったらaddURL:しないとすればOKです。しかしTwitterでは通るのにFacebookだけ通らないのはなんだか納得いかない・・・＞＜
エンジニアサポートCROSS 2013で発表してきました
先日ニフティさんが主催されたエンジニアサポートCROSS 2013におじゃまさせていただきました。このエンジニアサポートCROSSは年に１回、去年から開催されているらしいのですが、なんといっても大手企業さんが主催ということで
で、このエンジニアサポートCROSSにはアンカンファレンス枠があって、参加者が自由気軽にその場でプレゼンを行う事ができる場がありましたので、せっかくだからということで私も発表させて頂きました。
内容については先日リリースしましたダンゴルのサーバサイド側の裏話です。といってもスライド見れば分かる程度のものです。
来年は正規のスピーカー枠で参加したいです＞＜
- 参加者がとにかく豪華
- プレモル飲み放題ケンタッキー食べ放題という夢の様な環境
- それでいてきちんとWeb系/Make系コミュニティのギークっぽい雰囲気のカンファレンスになっている、スーツではない
で、このエンジニアサポートCROSSにはアンカンファレンス枠があって、参加者が自由気軽にその場でプレゼンを行う事ができる場がありましたので、せっかくだからということで私も発表させて頂きました。
内容については先日リリースしましたダンゴルのサーバサイド側の裏話です。といってもスライド見れば分かる程度のものです。
来年は正規のスピーカー枠で参加したいです＞＜
2012年12月3日月曜日
Unity Asset Server でブランチ切ったりタグつけたりする方法
弊社のUnityプロジェクトではUnity Asset Serverを使ってソースコードやアセットの管理を行なっているのですが、以前ブログに書いた通りこのUnity Asset Serverさんは標準でブランチもなければタグもサポートしていないというCVS以下の素敵なシロモノです。しかしながらやはり開発のニーズ上、継続的に開発するためにはブランチやタグが必要になってきます。そこでUnity Asset Serverを使っていかにしてブランチやタグを運用するかという方法を考えてやってみましたので共有いたします。
■基本方針
基本方針は要するにSVNのやり方をパクります。すなわち、
さてリポジトリのコピーですが、一応Unity Asset Serverではリポジトリのコピーの作成が可能になっています。
こちらをクリックしてリポジトリをコピーしてください。注意点としてはこのリポジトリコピーは他のユーザーが一人でもAsset Serverに接続しているとコピーが出来ないので、社内に呼びかけて全員のUnityをシャットダウンするなり何なりしてください。誰が接続しているか特定したい場合はUnity Asset Serverが動いているサーバで
■タグを付けたい
これは簡単です。Asset Serverに接続して、タグが付けたいバージョンがヒストリの先頭にある状態で、先述したリポジトリのコピーを行います。あとはコピーしたリポジトリに触らないようにすればタグの完成です。
注意点として、タグが付けたいバージョンがヒストリの奥のほうにあると基本的には綺麗にタグが切れません。そのようなコミットをする前にタグを切ってください。
■ブランチを切りたい
これもまだ簡単です。Asset Serverに接続して、ブランチの根っこにしたいバージョンがヒストリの先頭にある状態で、先述したリポジトリのコピーを行います。あとはこちらのリポジトリに作業者全員が接続先を切り替えて、新しいコミットを重ねていけば良いです。
注意点として、タグと同様に例によってバージョンがヒストリの奥のほうにあると綺麗にブランチが切れず苦労することになりますので、コミットの重ね方には最新の注意を払う必要があります。
それから各作業者がブランチを切り替える際の手順にも注意する必要があります。
■ブランチをリベースしたい
ここからがちょっとした地獄の始まりです。まずはリベースから。例として1.0.1ブランチのブランチ元である1.0.0をリベースする手順を示します。
■ブランチをマージしたい
ブランチのマージは単にリベースの逆をやるだけです。例として1.0.1ブランチをmasterにマージする手順を示します。
■基本方針
基本方針は要するにSVNのやり方をパクります。すなわち、
- タグやブランチはリポジトリのコピーとして表現する
- リベースやマージは気合でなんとかする
さてリポジトリのコピーですが、一応Unity Asset Serverではリポジトリのコピーの作成が可能になっています。
こちらをクリックしてリポジトリをコピーしてください。注意点としてはこのリポジトリコピーは他のユーザーが一人でもAsset Serverに接続しているとコピーが出来ないので、社内に呼びかけて全員のUnityをシャットダウンするなり何なりしてください。誰が接続しているか特定したい場合はUnity Asset Serverが動いているサーバで
ps aux | grep unityとか叩けばなんとなくわかります。
■タグを付けたい
これは簡単です。Asset Serverに接続して、タグが付けたいバージョンがヒストリの先頭にある状態で、先述したリポジトリのコピーを行います。あとはコピーしたリポジトリに触らないようにすればタグの完成です。
注意点として、タグが付けたいバージョンがヒストリの奥のほうにあると基本的には綺麗にタグが切れません。そのようなコミットをする前にタグを切ってください。
■ブランチを切りたい
これもまだ簡単です。Asset Serverに接続して、ブランチの根っこにしたいバージョンがヒストリの先頭にある状態で、先述したリポジトリのコピーを行います。あとはこちらのリポジトリに作業者全員が接続先を切り替えて、新しいコミットを重ねていけば良いです。
注意点として、タグと同様に例によってバージョンがヒストリの奥のほうにあると綺麗にブランチが切れず苦労することになりますので、コミットの重ね方には最新の注意を払う必要があります。
それから各作業者がブランチを切り替える際の手順にも注意する必要があります。
- Asset Serverに接続してdisplayを選択。
- 新しいブランチとなるリポジトリを選択してconnect。
- リポジトリの切り替えが終わったらupdateを行う。
- マージするかどうか聞かれたら、ブランチの切り替えなので、すべてDiscard my changesを選択すること。
■ブランチをリベースしたい
ここからがちょっとした地獄の始まりです。まずはリベースから。例として1.0.1ブランチのブランチ元である1.0.0をリベースする手順を示します。
- Asset Serverに接続して、リベース元となるブランチ (1.0.0) にconnect。
- リポジトリの切り替えが終わったらupdateを行う。
- マージするかどうか聞かれたら、ブランチの切り替えなので、すべてDiscard my changesを選択すること。
- Asset Serverに接続して、リベース先となるブランチ (1.0.1) にconnect。
- リポジトリの切り替えが終わったらupdateを行う。
- マージするかどうか聞かれたら、リベース元のコードをすべて新しい接続先のブランチに上書きしたいという処理になるので、ソースコードとシェーダーコードについてはMergeを、その他のシーン、プレファブ、テクスチャ、モデル、音などはすべてIgnore server changesを選択する。
- このままだとなぜかコードは変更されているのに変更差分をUnityが認識しない悲しい状態になるので、メニューからAssets > Reimport allを選択して変更差分をUnityに認識させる。
- マージに失敗したコードおよびシーン、プレファブ、テクスチャ、モデル、音などを手でマージする。
- コミットして完了。
■ブランチをマージしたい
ブランチのマージは単にリベースの逆をやるだけです。例として1.0.1ブランチをmasterにマージする手順を示します。
- Asset Serverに接続して、マージ元となるブランチ (1.0.1) にconnect。
- リポジトリの切り替えが終わったらupdateを行う。
- マージするかどうか聞かれたら、ブランチの切り替えなので、すべてDiscard my changesを選択すること。
- Asset Serverに接続して、マージ先となるブランチ (master) にconnect。
- リポジトリの切り替えが終わったらupdateを行う。
- マージするかどうか聞かれたら、マージ元のコードをすべて新しい接続先のブランチに上書きしたいという処理になるので、ソースコードとシェーダーコードについてはMergeを、その他のシーン、プレファブ、テクスチャやモデルや音などはすべてIgnore server changesを選択する。
- このままだとなぜかコードは変更されているのに変更差分をUnityが認識しない悲しい状態になるので、メニューからAssets > Reimport allを選択して変更差分をUnityに認識させる。
- マージに失敗したコードおよびシーン、プレファブ、テクスチャ、モデル、音などを手でマージする。
- コミットして完了。
2012年12月1日土曜日
PySpa アドベントカレンダー 1日目 〜バカとPythonと芳泉閣〜
PySpaアドベントカレンダーというイベントに参加してみたところ、僭越ながら初日を努めさせていただくことになりました＞＜ ということで本日は技術ネタではなくてPySpaというイベントとともに自分の職歴でも振り返ってみようと思います。
■そもそもPySpaってなんぞや
vの人という主犯格が定期開催している温泉旅館に泊まるイベントです。名前に反して実はPythonは全然関係ないです。詳細は以下のページとか見てみてください。
https://github.com/pyspa/pyspa
http://voluntas.hatenablog.com/entry/20081024/1218125470
基本的にvの人の知り合いばかりで固定PySpaメンバーと言えるメンバーがいるのですが、昔からいた人が仕事の都合とかで疎遠になると新しい人が定期的にやってきて全体が保たれているという感じの不思議な輪が形成されているのが特徴ではないかと思っています。後、全員やたら技術力があります。
■SIer時代（2008~2009年）
最初に参加したのが2008年に開催された第4回です。記憶が曖昧なのですが、確かTwitterだか何だかで参加者を探していたところに無理やり飛び込んだのがきっかけです。よくやった当時の自分。当時は新卒入社したSIerの会社でJavaを書いていて、Pythonって面白そうだなーとか考えて手を出していたころだったのでPythonの勉強会のノリで参加してました。あとそういえばiPhone 3Gを発売日当日に買い、Apple信者生活を開始しました。
第4回の記録
http://akisute.com/2008/10/4python-1.html
うん、今見たら恥ずかしくて死にたい。といっても年中後から振り返ったら恥ずかしくて死にたいようなことしかしてない気がするので今更気にしたら負けです。次行きます。次。
第5回からは完全にiPhone開発ばっかです。あとこの一年で随分PySpaのノリを理解した感じを文体から感じ取れます。
第5回の記録
http://akisute.com/2009/06/5-python.html
この期間は自分の基礎となる技術や興味を見つけることができた貴重な時期でした。最も向上心がありバックグラウンドもない新人時代を非常に有意義に過ごすことができたのではないかとおもいます。あと、今現在わずかに残っているのみとなった社会人として必要な常識などは全てこの時期に身につけさせていただきました＞＜ 本当にありがとうございました＞＜
■Web屋時代（2010年~2011年）
2009年末に新卒入社したSIerの会社を退職してビープラウドに転職しました。転職理由はもはや覚えていないのですが、確かこのままこの会社にいてはスキルアップにならない！よりよい環境へ移るべきだ！などという意識の高い社二病精神か何かが原因だった気がします。
このへんから面倒になったせいかPySpaメンバーの内輪みたいな感じになったせいもあるのかブログへの参加記録が途絶えてしまっていますが、PySpa自体には二年間毎回かかすことなく参加しておりました。というのもPySpa自体がビープラウドの非公式社外リクルートイベントみたいな感じになっていた関係上、半数近くの社員がPySpaに参加する時があったりしたからです。
例えば今回のアドベントカレンダー参加メンバーだと
あたりがPySpa経由で雇用されたビープラウド社員だったりします。
第6, 7, 8, 9, 10と参加してきたPySpaですが、10回でいったん定期開催を締めようというvの人の考えで第10回を最後にしばらく開催が途絶えてしまいました。そのかわり定期開催する文化はPyFesへと引き継がれていきました。
この期間は良い意味でも悪い意味でも自分のアイデンティティが確立された期間でした。何か捨ててはいけないたぐいの常識を投げ捨ててしまった変わりに職業iOSプログラマとしてのキャリアが確立された感じでしょうか。あとは仕事でひどく失敗した時期でもありました。前職SIer時代では失敗ができるような機会はなかったのですが、ビープラウドでは数回ひどく失敗してご迷惑をお掛けしたことがありました。ほんとスミマセン＞＜ お陰様で人類としての社会常識はなくなりましたがプロとして仕事を進める常識は多少身につきました＞＜
■ゲーム屋時代（2012年~）
2012年の2月にビープラウドを退職して変なゲーム会社に転職して以来、しばらくご無沙汰していたPySpaですが、今年の10/26に開催されたのでふらっと参加してきました。
感想、みんな年食い過ぎ。
高齢化の並はPySpaにも押し寄せているのかいないのかわからんのですが、第4回第5回の頃の大学生のきゃっきゃうふふ的ノリはかなり鳴りを潜め、仕事の話をしたりだとかが増えたり徹夜組が全滅して朝早起きになってたりお菓子の減りが悪くなってたりと随所におっさん臭がしてきております。ピンチです＞＜ まぁ時間の流れというのはそういうものなのかなぁと私自身おっさん的に思っております。
この期間は自分のこれまでの集大成であるような気がしています。子供の頃にハマりまくっていたゲームへの愛情と、SIer/Web屋時代に培ったサーバ側技術と、iPhoneリリースからやってきたiOS開発の集大成という感じです。そして随分と責任ある立場をまかされるようになってしまった気がします。うーん年だ。このあとどうしよう。とりあえず今しばらくはゲームが最高に面白いのでゲームをやろうと思ってます。
余談ですがうちらのゲームもうすぐリリースらしいです。一応宣伝。
http://www.donpy.net/appinfo/18791.html
■まとめ
こうして振り返ると私の仕事人生はiPhoneとPySpaとともに歩んできたんだなぁと思います。iPhoneは私に夢中になって開発できる何かをくれましたし、PySpaは私にスキルと人脈と情熱をくれました。この２つがあったからこそここまでやってこれたんだなぁと思っています。これからもまぁそんな感じで適当にやっていきます。
最後になりましたけれども、PySpaを毎年開催してくださっているvの人と、今回のアドベントカレンダーを企画していただいたとんぷーさん、どうもありがとうございます！
それでは明日はshkumagaiさんよろしくおねがいしまーす！
■そもそもPySpaってなんぞや
vの人という主犯格が定期開催している温泉旅館に泊まるイベントです。名前に反して実はPythonは全然関係ないです。詳細は以下のページとか見てみてください。
https://github.com/pyspa/pyspa
http://voluntas.hatenablog.com/entry/20081024/1218125470
基本的にvの人の知り合いばかりで固定PySpaメンバーと言えるメンバーがいるのですが、昔からいた人が仕事の都合とかで疎遠になると新しい人が定期的にやってきて全体が保たれているという感じの不思議な輪が形成されているのが特徴ではないかと思っています。後、全員やたら技術力があります。
■SIer時代（2008~2009年）
最初に参加したのが2008年に開催された第4回です。記憶が曖昧なのですが、確かTwitterだか何だかで参加者を探していたところに無理やり飛び込んだのがきっかけです。よくやった当時の自分。当時は新卒入社したSIerの会社でJavaを書いていて、Pythonって面白そうだなーとか考えて手を出していたころだったのでPythonの勉強会のノリで参加してました。あとそういえばiPhone 3Gを発売日当日に買い、Apple信者生活を開始しました。
第4回の記録
http://akisute.com/2008/10/4python-1.html
うん、今見たら恥ずかしくて死にたい。といっても年中後から振り返ったら恥ずかしくて死にたいようなことしかしてない気がするので今更気にしたら負けです。次行きます。次。
第5回からは完全にiPhone開発ばっかです。あとこの一年で随分PySpaのノリを理解した感じを文体から感じ取れます。
第5回の記録
http://akisute.com/2009/06/5-python.html
この期間は自分の基礎となる技術や興味を見つけることができた貴重な時期でした。最も向上心がありバックグラウンドもない新人時代を非常に有意義に過ごすことができたのではないかとおもいます。あと、今現在わずかに残っているのみとなった社会人として必要な常識などは全てこの時期に身につけさせていただきました＞＜ 本当にありがとうございました＞＜
■Web屋時代（2010年~2011年）
2009年末に新卒入社したSIerの会社を退職してビープラウドに転職しました。転職理由はもはや覚えていないのですが、確かこのままこの会社にいてはスキルアップにならない！よりよい環境へ移るべきだ！などという意識の高い社二病精神か何かが原因だった気がします。
このへんから面倒になったせいかPySpaメンバーの内輪みたいな感じになったせいもあるのかブログへの参加記録が途絶えてしまっていますが、PySpa自体には二年間毎回かかすことなく参加しておりました。というのもPySpa自体がビープラウドの非公式社外リクルートイベントみたいな感じになっていた関係上、半数近くの社員がPySpaに参加する時があったりしたからです。
例えば今回のアドベントカレンダー参加メンバーだと
12/1 akisutesama 12/3 tokibito 12/4 torufurukawa 12/8 shimizukawa
あたりがPySpa経由で雇用されたビープラウド社員だったりします。
第6, 7, 8, 9, 10と参加してきたPySpaですが、10回でいったん定期開催を締めようというvの人の考えで第10回を最後にしばらく開催が途絶えてしまいました。そのかわり定期開催する文化はPyFesへと引き継がれていきました。
この期間は良い意味でも悪い意味でも自分のアイデンティティが確立された期間でした。何か捨ててはいけないたぐいの常識を投げ捨ててしまった変わりに職業iOSプログラマとしてのキャリアが確立された感じでしょうか。あとは仕事でひどく失敗した時期でもありました。前職SIer時代では失敗ができるような機会はなかったのですが、ビープラウドでは数回ひどく失敗してご迷惑をお掛けしたことがありました。ほんとスミマセン＞＜ お陰様で人類としての社会常識はなくなりましたがプロとして仕事を進める常識は多少身につきました＞＜
■ゲーム屋時代（2012年~）
2012年の2月にビープラウドを退職して変なゲーム会社に転職して以来、しばらくご無沙汰していたPySpaですが、今年の10/26に開催されたのでふらっと参加してきました。
感想、みんな年食い過ぎ。
高齢化の並はPySpaにも押し寄せているのかいないのかわからんのですが、第4回第5回の頃の大学生のきゃっきゃうふふ的ノリはかなり鳴りを潜め、仕事の話をしたりだとかが増えたり徹夜組が全滅して朝早起きになってたりお菓子の減りが悪くなってたりと随所におっさん臭がしてきております。ピンチです＞＜ まぁ時間の流れというのはそういうものなのかなぁと私自身おっさん的に思っております。
この期間は自分のこれまでの集大成であるような気がしています。子供の頃にハマりまくっていたゲームへの愛情と、SIer/Web屋時代に培ったサーバ側技術と、iPhoneリリースからやってきたiOS開発の集大成という感じです。そして随分と責任ある立場をまかされるようになってしまった気がします。うーん年だ。このあとどうしよう。とりあえず今しばらくはゲームが最高に面白いのでゲームをやろうと思ってます。
余談ですがうちらのゲームもうすぐリリースらしいです。一応宣伝。
http://www.donpy.net/appinfo/18791.html
■まとめ
こうして振り返ると私の仕事人生はiPhoneとPySpaとともに歩んできたんだなぁと思います。iPhoneは私に夢中になって開発できる何かをくれましたし、PySpaは私にスキルと人脈と情熱をくれました。この２つがあったからこそここまでやってこれたんだなぁと思っています。これからもまぁそんな感じで適当にやっていきます。
最後になりましたけれども、PySpaを毎年開催してくださっているvの人と、今回のアドベントカレンダーを企画していただいたとんぷーさん、どうもありがとうございます！
それでは明日はshkumagaiさんよろしくおねがいしまーす！
登録:
投稿 (Atom)