2011年12月13日火曜日

shibuya_sp勉強会vol.1に行ってきた

shibuya_sp勉強会vol.1に参加してきました。
http://atnd.org/events/22758

iPhone,Androidといったモバイルアプリのごった煮勉強会です。

iOSアプリのUnitTest
iOSアプリケーションの Unit Test
View more presentations from Katsumi Kishikawa

iOS App Development Workflow Guideをまず読むのがおすすめ。
日本語版もでてます。
http://developer.apple.com/jp/devcenter/ios/library/documentation/Xcode/Conceptual/ios_development_workflow/#000-Introduction/introduction.html

UnitTestツールでは、OCUnitとGHUnitがあるが、GHUnitのほうがおすすめ。
OCUnitはXcodeに組み込まれているというメリットはありますが、GHUnitのほうが機能的に優れていてOCUnitで作ったテストケースも動かすことができるため、導入が少々面倒でも最初だけセッティングすればよいのでGHUnitのほうがおすすめとのことでした。

UI Automationについては使ってないということで、やはりUIはころころ変わるのでテストの自動化は難しいようです。

つりポンアプリ開発について
Tsuripon 20111213
View more presentations from Yusuke Kawabata

cocos2dを使った開発についてと高速化、最適化手法についての発表でした。

OCTOBAから見た人気Androidアプリの動向

Octoba presen 20111213_public

View more presentations from Yusuke Kawabata

OCTOBA.netでは評価時にアプリのパーミッションを見て安全性をまずチェックしているようです。Androidはいろいろできてしまうのでここのチェックは重要ですね。
人気のジャンルとしては、電話帳、時計、メールといった検索が多いようで、ユーザーは基本的な機能に満足していないみたいですね・・
0 件のコメント:
ラベル: , ,

2011年11月5日土曜日

Redmine1.1.2をubuntu10.04にインストール

手順を書こうと思ったのですが、ここに書いてあるやり方でばっちり完成してしまったので、このサイトを見るといいと思います。。

http://www.samontab.com/web/2011/04/how-to-install-redmine-1-1-2-on-ubuntu-server-10-04/

apt-get install red mineでもできますが、0.9とバージョンがかなり古いであまりおすすめできません。

ここでインストールしたのも1.1.2なので、次回はバージョンアップに挑戦してみます。
0 件のコメント:
ラベル: ,

2011年11月1日火曜日

GoogleDeveloperDay2011に参加してきた

去年のリベンジを果たしディベロッパーズクイズを無事突破して
GoogleDeveloperDay2011東京に参加してきました。

今年は、Android、HTML5、Google+の３本柱でした。
中でもHTML5のセッションは立ち見が出るなどかなり盛況でしたね。
HTML5のデモを見ているとそのうちほとんどのアプリはWebアプリ化するんじゃないかなと現実的に感じさせるほどにまでなってきているという印象を受けました。

AndroidはICS（Ice Cream Sandwich) はすごく進歩したなという印象です。
デザイン面ではるかにiPhoneに劣っていたのがかなり追いつくと共に
デザインのガイドラインもできつつあり、次第にUIの一貫性もでてくるのではないかと思います。逆に視覚障害者への対応や顔認証などAndroidのほうが先に行っているところなどもありiPhone VS Androidは面白くなってきています。


Googleの最新技術の紹介ということで知っている人は結構知っている一般的な内容も多く
技術的にはそれほど新たな知見はなかったですが、熱気はすごいです。
LTのレベルが異常に高かった・・


GoogleDeveloperDayではTシャツ、缶バッチ、ネックストラップなどいろいろもらえました！
3Dメガネの使い所はなんだったのだろう・・

また弁当や水、最後はビールやチューハイも配られるなどGoogleさん太っ腹。

基調講演の様子はこんな感じ

締めはGoogleの方やスタッフの人が集まって記念写真で終了
0 件のコメント:
ラベル: , , ,

2011年10月29日土曜日

GTUG Boot Camp 2011に参加してきた

GTUG Boot Camp 2011

Fragmentを使ってみよう
Fragment を使ってみよう
View more presentations from Yuki Anzai
ハンドセット向けのレイアウトとロジックを流用したり
Fragmentを使うと動的にActivityを追加削除入れ替えできる
つまりFragment使うと部品として再利用しやすくなる

ハンドセット向けでFragmentを使う意味はある？
ある。
各コンポーネントをFragment化することで、それぞれ使いまわせる
Activityのコードがすっきりする
例：iosched

縦横でレイアウトを変える場合にもつかえる。

同じActivityでレイアウトを変える場合（例：chrome to phone）
setCOntentViewだと前のViewの状態を保存されない
→Fragmentを使って置き換えて、Fragmentをバックスタックに保存すればいい

TabHostは3.2以降でduplicateになったのでFragmentにせざるを得ない

・Fragmentのいまいちなところ
完全修飾名でレイアウトXMLファイルに書かないといけない
グラフィカルエディタで表示できなかったり
Typoミスが発生する

・Fragment、View、Activityの使い分け
View カスタムView
描画とそのための最低限のロジック

Fragment　
View＋そのViewに関連するロジック（Viewの操作やViewに表示するデータの処理）

Activity
それ以外。ActivityとFragment間のデータの受け渡しなど

Handson WebView

HoneyCombのシミュレータは重くて使い物にはならんがICS(IceCreamSandwitch)はまだ使える。。

・ICS
ハードキー（メニューキーがきえた）がなくなった。
アプリのターゲットSDKが10以下だと、右のほうにソフトキーでメニューキーが増える。
HoneyComb以降はアクションバーのメニューを使う
GPUをつかってかなりなめらかな動きになっている
ホーム画面が使いやすくなった。（アプリをフォルダにまとめたりできる）
デバイスデフォルトのテーマを使って開発すべき。

API Demos（デフォルトでシミュレータにはいってるやつ）ででもが見れる

・WebView
標準ブラウザのソースオードを見ると参考になる

JavaとJavascriptを連携させるようなアプリだとICSで動かなくなる可能性がある。

・Handson　資料
https://docs.google.com/document/pub?id=1_T9PiCJCgMs1QdXPpdYcp7orOnRr1UU6qA5do_zsR2A

ノートPCをちゃんとセットアップしてなかったので、普通にeclipseのAndroidのビルドではまってしまって、ハンズオンどころではなかったりして、感想もくそもないのですが。
準備はちゃんとやっとけってことです。

はまったところ：eclipseのコンパイラの設定を1.5にする

Google+ APIの体験とHangoutsの紹介

説明資料
https://docs.google.com/presentation/d/1oDkvwodZmkBMeeInhkzDYbHKj7Ss2CoXvnU6OwpzcMQ/edit#slide=id.p

以下のAPIの仕様のリンクを見れば簡単にできそう。
https://developers.google.com/+/api/

一般公開されているのだけAPIで取得することができる。（取得のみ。postできない）

APIを使うにはまず登録が必要
https://code.google.com/apis/console/

Oauthの設定で気をつけるところ
Create an Oauth でunexpected error が出た場合はリロードすると治るっぽい。
２個ClientIDが作成された場合は長い方を必ず使う。

つかいやすいAPIでしたが、問題はやはり「取得」しかできす、しかも「一般公開」しているものというのが大きなネックです。

・Hangout

HangoutはGoogle+のビデオチャットの拡張ができるAPIで
今回のHandsonではあらかじめ用意されたアプリと連携させるというもので
ビデオにドロイド君の絵がオーバーレイされて、
自分がしゃべるとドロイド君の口がパクパクするというもので、
他にもいろいろ使えそうな感じがしました。
ただまだ開発者のみしか使えないもので、２人以上いないと動かなかったり
設定が面倒だったりとまだまだといったところもあり
0 件のコメント:
ラベル: , , ,

2011年10月23日日曜日

Scientific Linux 6.1でgit serverを立てる

CentOSのアップデートが最近遅いので
ScientificLinux6.1を使ってGit Serverを立ててみた。(UbuntuでもOKでした）

ざっと調べたところ gitosisとgitoliteというのが２つあったが、前者のほうは開発が止まっているようだったのでgitoliteを使うことにした。

必要な環境
・クライアント(MacかLinuxが楽。Windowsのやり方はここでは紹介していません）
・サーバー(Linux系だったらだいたいOKだと思います）

事前準備
・クライアント、サーバー共にgitをインストールしておく

以下手順（サーバー側とクライアント側の作業があるので気をつけてください）

サーバー


まず gitolite　という名前でユーザを作成。GUI(system->administration->Users and Groups)を使って
やると簡単にできます。
コマンドでやる場合は,
> useradd gitolite
> passwd gitolite


あとsshのキー保存用のディレクトリを作っておきます
> su gitolite
> mkdir ~/.ssh

クライアント


> ssh-keygen -t rsa
でsshのキーを作成します。
保存場所や名前はデフォルトでよいです。パスワードは任意。


この結果 ~/.ssh/以下に id_rsa, id_rsa.pubが生成されます。
前者が秘密鍵で後者が共通鍵です。
ここで名前を変えておきます。 {user_name}は自由に決めてください。
> mv id_rsa {user_name}
> mv id_rsa.pub {user_name}.pub


次に共通鍵をサーバーに保存します。{server_name}はサーバーのホスト名かipアドレス。
> scp ~/.ssh/{user_name}.pub gitolite@{server_name}:/home/gitolite/.ssh


(connection refused ではじかれた場合はサーバー側のsshdが動いていないか設定がおかしいかなのでなおす)


sshでログインできるか確認
> ssh gitolite@{server_name}
ここで特に
The authenticity of host can't be established ...などと出なければOKです。

サーバー


> su gitolite
> cp ~/.ssh/{user_name}.pub /tmp
> cd ~
> git clone git://github.com/sitaramc/gitolite
> cd gitolite
> src/gl-system-install
> vi ~/.bashrc
PATH="$PATH":/home/gitolite/bin
を追加
> source ~/.bashrc
> gl-setup /tmp/{user_name}.pub
hit-enterでENTERキーを押すとviが起動するので:qでぬける。

クライアント


> cd ~/.ssh
> touch config
> vi config
以下の内容をconfigファイルに記載{server_name},{user_name}は前記と同じにする。
host gitolite
       user gitolite
       hostname {server_name}
       port 22
       identityfile ~/.ssh/{user_name}


gitolite-adminの設定用のディレクトリを保存するディレクトリ（任意）に移動します。


> cd ~/{WORK_DIR}
> git clone gitolite:gitolite-admin


これで何事も無くダウンロードできたらほぼ問題ないと思います。
ちなみに、私はここで以下のエラーでかなり手こずりましたが、この手順でやれば出ませんでした。
fatal:gitolite-admin.git does not appear to be a git repository


git clone gitolite@{server_name}:repositories/gitolite-adminとやると一見うまくいったように見えますが、pushができなくなるので無駄です。


上記エラーではまった場合のチェックポイント
・サーバー：/home/gitolite/.ssh/authorized_keysの中身を確認。
　⇒command="/home/gitolite/bin/gl-auth-command {user_name} ではじまってるか？なかったら最初からやりなおしてみる。。他に変なのがまじってたら消す。
・サーバー：/home/gitolite/.gitolite/keydirに{user_name}.pubがはいってるか？


一応pushできるか確認


> cd gitolite-admin
> touch README
> git add .
> git commit -m "add README file"
> git push

以上で最初の設定は完了です。
0 件のコメント:
ラベル:

2011年10月22日土曜日

Scrum Gathering Tokyo2011に参加してきた

Scrum Gathering Tokyo2011(Day2)に参加してきました。

といっても丸一日ScrumBootCampに参加したので他のセッションは全然見れませんでしたが。

Scrum Boot Camp

丸一日かけてScrumとはなんぞやという座学と実際にワークショップを体験して学ぶといったものでした。
４人〜５人のチームにわかれてワークショップは行いました。

・スプリント体験（チーム）
 まず午前の部では トランプを使ったもので、ものすごく短いスプリントを繰り返してゴールを達成する過程を体験するといったもので、これをやることにより気づいたことは非常に多く、今回やった中で一番よかったです。
会社でもすぐにできそうなので是非やってみたいエクササイズでした。

・プロダクトバックログの作成（個人）
家の掃除を題材にプロダクトバックログをつくるエクササイズ。
順序付けとどこまで必須なのかよく理解できました。

・見積もり（個人）
紙飛行機の作成、こよりの作成、トランプの並び替えの時間を見積もって、そして実際やってみるというエクササイズ。
全然見積とはあいません。

・見積もり（チーム）
今度は似たようなことをチームで見積もり。
個人でやるよりも安心感や確かさがあがる気がしました。

・見積もり（チーム）
今度はポイントを使って相対的な見積もりをするといったエクササイズ。
こちらは実際にせーのでポイントを各自がカードで出すことで楽しく見積もりができるだけでなく、ポイントが違った場合に、なぜそう見積もったのかということをチーム全体で共有することができ、これまでの見積もりよりも、より全員がゴールのための品質や手順などの共通認識がとれたように思えました。これもかなりよかった。

・スプリントの過ごし方（チーム）
ひらがなの表を手書きでメンバーの数×２個作成するという協業作業のエクササイズで、数名利き手と逆の手で書くという制約があり、余裕のあるメンバーが手助けしてこなすといった内容でした。

どれも座学だけでなく、実際にやってみることで気づいたり、納得したりすることが多く、やっぱり何事もやってみることが重要だと感じました。
アジャイルで開発を始める前に是非やっておくべき内容だと思います。

以下当日のスライド
Summary of Scrum Guide

Agile Estimating and Planning in your drawing paper
Ways and Means of Spending Your Sprints
0 件のコメント:
ラベル: ,

2011年10月15日土曜日

第四回　Jenkins勉強会に参加してきた

第四回Jenkins勉強会に参加してきました。
今回はC++,C#ということで自分も使っていることもありかなりタイムリーネタでした。

マルチ構成プロジェクト

クロスコンパイルなどを使って複数の環境向けにデプロイする場合に使える
失敗したときに全部やり直すとものすごい時間がかかるので、MatrixReloadedプラグインを使うと失敗したものだけ再実行することができる。

Jenkins+αで開発環境がみるみるよくなる Visual C++ 編
Jenkinsstudy#4kokawa
View more presentations from Takashi Kokawa
・MSBuild
MSBuildを使う場合は、MSBuild自体は.NET frameworkないに入っているのでビルドマシンにVisual Studioをインストールする必要はない。

・WarningPlugin
WarningPluginは結構便利。途中から始める場合はすべての警告に対応するというよりも新たに発生したものを潰すために使ったほうがいいかも。設定もいろいろできる。

・UIの自動テスト
起動〜終了だけでもやると効果がある
UI操作自動化ツールとしては、AutoItやSikuliというのがある

・静的解析
Cppcheck Pluginくらい。C++だと無料なのはあまりいいのはない

・実装漏れ検知
Task Scanner Plugin。ソースコード内のto do などの文字列を発見してくれる。

・コーディングルールチェック
cpplint。google C++ Guidelineに沿ったチェックをしてくれる
violations PluginでJenkinsで実行できる。

・メトリクス
CCCC。使ってみたけどあまり使いものにはならなかった（誰も見ない）
Sonar。（C,C#はPluginで対応している）

・ドキュメント
Doxgen

・コラボレーションツール
Jenkinsからチケットを発行
コミット→条件判定（Python）→チケット発行　というようにしてやってる

輪るビングドラム.NET
輪るビングドラム.NET
View more presentations from bleis tift
・Role Strategy Plugin

・すべてのビルドをひとつのビルドマシンでやるのはよくない
・何も無いところ（クリーンな環境）からビルドすべき。でも毎回は時間かかりすぎてできないのでデイリービルドのみでやるとかする
・TFSよりJenkinsのほうが設定は楽。全部VisualStudioで完結させたいならTFS

Jenkins実装入門目次チラ見せしちゃいます
Jenkins実践入門目次チラ見せしちゃいます
View more presentations from Lino
・おすすめのPlugin = Job Config History Plugin
だれがいつ設定をいじったのかHistoryでわかる

Jenkinsの使い方だけでなくtips的なものも載っているようで
初心者からよく使っている人まで使えそうな本みたいです。

参考資料
CI超入門：Jenkinsのすすめ

Video streaming by Ustream


C#　大阪Jenkins勉強会のC#の資料
Net なプロジェクトでも jenkins を使ってみた
View more presentations from odashinsuke
Jenkins The Definitive Guide
http://www.wakaleo.com/download-jenkins-the-definitive-guide
0 件のコメント:
ラベル: ,

2011年9月3日土曜日

XP祭りに参加してきた

XP祭りに初参加してきました。
http://xpjug.com/xpx/

いろいろと参加型のワークショップがあり、当日に紙に名前を書いて参加というかたちでした。
午後からなので余裕だと思っていたら遅刻してしまい、ワークショップはひとつだけ参加でしたorz

scrumはじめの一歩というワークショップに参加しました。

折り紙を使って紙ヒコーキをできるだけ多くつくるという作業を
10分×4回のスプリントでやるといったものでした。
scrumの講義だけでなく、実際に短い時間で体感できてとても面白かったです。
会社とかでもすぐにできそうなものなので、試してみたいなーと思います。

資料は以下です。
2011年 XP祭り Scrumはじめの一歩 #xpjug
View more presentations from Ryuzee YOSHIBA

講師の@ryuzeeさんのブログ
http://www.ryuzee.com/contents/blog/4225

よく見たら自分もちらっと写ってた！
0 件のコメント:
ラベル: ,

2011年8月28日日曜日

実践的UserExperienceワークショップに行ってきた

Lean UXの一日ワークショップに参加してきました。
http://peatix.com/event/760

お値段は22,000円と自腹としては結構しましたが、あのJanice Fraser氏のワークショップを日本で受けれると考えるとむしろ超お得。
Ux for lean startups london
View more presentations from Janice Fraser

↓日本語資料
Tokyo 1 day (日本語)
View more presentations from Janice Fraser


LeanStartupとは商品開発におけるアジャイルといった印象を受けました。
最小限のチーム編成（プロダクトマネージャー、デザイナー、エンジニア）を１チームとして、アイデアの発想、開発、検証を短いサイクルで回してユーザーとともに製品をつくりあげるという過程はまさにアジャイルで、ソフトウェア開発から産まれた手法が、顧客開発に応用されているところがおもしろいと感じました。

これまでの製品開発は企画が決めたものをウォーターフォールで作るものが主流ですが、こういった開発が主流となってくるかもしれないですね。そうなると日本的な稟議書書いて下請けがつくるといったITゼネコン的なところは壊滅するでしょうね・・

とはいっても、LeanUX的な開発は定性的な評価が多く、いかにユーザーに質問するかや、どのような人に対して評価するかなどかなり経験を積んで行かないと難しいと思われるところも非常に多いため、どの企業でもすぐにできるというものではないと思います。
早く取り入れ、ユーザーに対する姿勢を正し、多くの経験を積み重ねたところがよいユーザーエクスペリエンスを産み出していくのではと思います。
0 件のコメント:
ラベル: , ,

2011年8月20日土曜日

LLPlanetsに参加してきた

Lightweight Language Planets 2011に参加してきました。
http://ll.jus.or.jp/2011/

LLといいつつタイムテーブルの通りJavascript一色といった感じでした。
Node.jsやCoffeeScriptも流行ってるし当然といえば当然なのかも。

タイムテーブル
10:30-10:40 開会宣言＋場内注意事項説明
10:40-10:50 IPv6ハッカソン紹介
10:50-12:20 メタプログラミングの光と闇
12:20-13:50 昼休み
13:50-14:35 基調講演
14:35-14:50 休憩
14:50-16:20 Node.jsとは何だったのか
16:20-16:50 夕休み
16:50-18:20 JavaScript八面六臂
18:20-18:35 休憩
18:35-19:05 IPv6ハッカソン成果報告
19:05-20:10 Lightning Talk
20:10-20:20 抽選会＋閉会宣言


・メタプログラミングの光と闇
メタプログラミングってなんぞという状態で聞いたのですが、マクロみたいなものでメタプログラミングなものやDSLちっくなものって意外と身近にいろいろあるなと感じました。
話の結論としては、メタプログラミングとかDSLとかつくらずに普通に書け！ということでしたがｗ


・基調講演
malaさんのお話はとても面白かった。配信されていたら必見。本人は顔出しNGなので無理かもですが・・。Javascriptは必須だなと感じました。
また、Webページの脆弱性を指摘すると寿司を食えたりするらしいですw

他メモ
・Javascriptを自動生成するな
・HTML5でクライアント側でできることが増えたからクライアントでしかできないことを採用せよ

・Node.jsとはなんだったのか
Node.jsはJavascriptをサーバーサイドでも使いたいだけだろとか思ってましたが、イベントループとノンブロッキングI/Oのサーバーを構築するのに最適な言語だったということで大きな誤解でした。
他にもイベントループを採用しているフレームワークは色々あったみたいですが、JavascriptみたいにノンブロッキングI/O環境を創りだすのは難しかったみたいであまり普及しなかったみたいですね。
シングルスレッドなのがあれですが、この先どう普及していくのか。
Node.jsはC++で書かれているみたいなので自分でも何か作ったりできるかも？！

・Javascript八面六臂
以下メモ
・ECMA262の第三版の仕様はほぼ使えるとおもってよい
・bit,byte操作はむずかしい
・複数人でやるとスタイルがばらばらになる
・コールバック地獄になりやすい。特にオフラインアプリ
・Workerに押しこめばコールバックしなくてすむ
・エラー処理がしにくい
・Promiseなどのライブラリを使うことである程度解決する
・エディタの昨日を使いつつ慣れる
・非同期I/Oはきをつけないといけない
・直列的に書けるライブラリをつかうといい（jsRefer)
・ボトムアップで書いたほうがJSっぽい
・複数人でやる場合はクラスのほうがいいかも
・ecmaではクラスを取り入れる提案もあがってたりする
・プロトタイプベースでクラスでやりたいことはできるはず
・クラスベースでやらなければならない理由はないのでは
・webstormがeclipseやnetbeansよりもつかいやすかった
・どれもgitがそれなりにつかえる
・記述の自由さがネック
・規約とテスト方法を決めとく
・対話型モジュールで学ぶのがよい
・prototype.jsはコードリーディングにはよい。（使うのは・・）


Javascriptばっかりでしたが結構面白かったです。
今後は他のLLも頑張ってほしいですね。
0 件のコメント:
ラベル: ,

2011年8月15日月曜日

Google Motorolaのモバイル部門買収の真意は

いや、まさかのGoogleのMotorolaのモバイル部門買収。

Google Buys Motorola For $12.5 Billion, Says “Android Will Stay Open”
http://techcrunch.com/2011/08/15/breaking-google-buys-motorola-for-12-5-billion/

Google acquiring Motorola Mobility
http://www.engadget.com/2011/08/15/google-acquiring-motorola-mobility/

Supercharging Android: Google to Acquire Motorola Mobility

GoogleがOSだけでなくデバイスを手に入れ、Appleと同じ土俵にたった！とも見えなくもないのですが、個人的にはタイミング的にどうもそうではなく、WindowsPhoneに対する敵対的買収にみえて、えげつない買収だなぁと。。

MicrosoftがNokiaと同様に触手を伸ばしていて双方のメリットが合致してうまくいくのではと外野から見ていた矢先にこれですよ。

一番やられた！と思っているのはMicrosoftでしょうね。。
WindowsPhoneは結構期待していたんですが、抑えられると厳しいですよね。
前途多難なWindowsPhoneですがこの先どうなるでしょうか
0 件のコメント:
ラベル: , ,

2011年8月7日日曜日

Mac OS X 10.7 Lion と MagicTracpad

Mac OS X 10.7 Lionでジェスチャー入力がかなりパワーアップしたので
それにあわせて、これまでのMagicMouseからMagicTracpadに置き換えました。

結論としてはLionではMagicTracpadが断然良い！

ただし操作に慣れるのにちょっと時間を要しましたが、軽いタッチで操作できるのでとても楽ちんです。
よく使う操作について紹介しておきます。

MagicTracpadの操作方法(Mac OS X 10.7 Lion)
（トラックパッドの設定で全部ONにした場合です）

・スクロール・・・２本指で上下にスライド
・右クリック・・・２本指でタップ
・画面の拡大縮小※・・・controlキーを押しながら、２本指で上下にスライド
・アプリの全画面表示・・・アプリのWindowの右上をタップ
・アプリの全画面表示解除・・・escキーを押す
・アプリ内の表示の拡大縮小・・・２本指でピンチ
・文字列のコピー・・・３本指でスワイプして文字をなぞる⇒２本指でタップしコピーを選択
・ドラック・・・３本指でスワイプ
・ミッションコントロールの表示・・・４本指で上にスライド（非表示は下にスライド）
・LaunchPadの表示・・・3本指でピンチ（4本か5本でやったほうが反応がいいです）

あまり使わないもの

・調べる・・・3本指でダブルタップ
・スマートズーム・・・2本指でダブルタップ
・回転・・・2本指で回転
・ページめくり・・・2本指で左右スクロール
・全画面表示アプリ切り替え・・・4本指で左右にスクロール

マルチタッチジェスチャー
http://www.apple.com/jp/macosx/whats-new/gestures.html


例のスクロールの方向がデフォルトで逆になった件ですが、MagicTracpadを使うとこっちのほうが自然な感じがしてきましたので、デフォルト設定がオススメです。

※画面の拡大縮小の設定方法
　システム環境設定⇒ユニバーサルアクセス⇒ズーム機能：入にチェック
0 件のコメント:
ラベル: ,

Startup meet Designレポ

OpenNetworkLabとStartupTokyo主催の講演に参加してきました。

「Startup Meets Design」

Ustream


Video streaming by Ustream
Design for Startups
感想

私がアプリを作りはじめて感じたのはデザインの重要性です。
デザインという言葉は日本人にとっては「デザイン＝意匠（見た目）」と思いがちですが、「デザイン＝設計」という意味でのデザインがとても重要だと思います。

似たようなコンセプトのサービスやアプリケーションは多数存在し、これらと差別化していくにはデザインで差別化していくことが必要となります。
そのためにはアジャイルプロセスの中にデザイナーを組み込むことと、エンジニアと一体となって開発していくことが重要だと感じました。
また、エンジニアもデザインを理解し、自分でもある程度はデザインできなるようにならなければいけないなと感じました。
今日の参加者にはエンジニアが多数参加していて、エンジニアの関心も高いように感じます。

海外でもUXデザイナーの需要はとても高いようですので、是非身につけたいスキルだと思いました。

メモ

・デザインで差別化する
・全プロセスにデザイナーを入れる
・ブレストはプロダクトマネージャー、デザイナー、エンジニアでやるのがいい
・UIはスピードが最優先（探さない、書かない、溜めない）
・早ければいいわけでもない
・UXはどうやって学べば良い？
⇒本は古典だが「だれのためのデザイン」は読んだほうがいい
⇒似たようなサービスのUIを比べてみるといい
⇒実際にユーザーに声に出して使ってもらうといい
⇒あとはトライアンドエラーで学んでいくしかない

その他

QuoraのデザイナーのchibicodeさんのFacebookに色々とデザイン関連の情報を載せてくれていてとてもよいです。

Janice Fracerのプレゼン資料
http://www.slideshare.net/clevergirl/presentations

0 件のコメント:
ラベル: ,

2011年8月3日水曜日

Twitterが、Ruby on RailsからJavaVMへ移行する理由

Twitterが、Ruby on RailsからJavaVMへ移行する理由 
http://www.publickey1.jp/blog/11/twitterruby_on_railsjavavm.html

twitterでも結構話題になっていますが、非常に興味深い内容です。

twitterがRailsで実装されてたってことも知らなかったので驚きました、Railsでもこれだけのトラフィックに耐えれるんですね。
やはりいくらパワフルなサーバーでもRubyのようなインタープリタだと限界があるのかな。
RubyのGCはよく遅いと耳にしますが、twitterでも独自にいじってたみたいですし、Railsは立ち上げには楽かもしれませんが、サービスが大きくなってくるとJVMとかに以降していく必要があるというのはよいノウハウとして今後参考になるかもしれないですね。
0 件のコメント:
ラベル:

2011年7月27日水曜日

WindowsPhone 日本で発売開始

au、国内初のWindows Phone 7.5スマートフォン
http://av.watch.impress.co.jp/docs/news/20110727_463225.html

ようやく日本でも秋から発売になります。
Androidは比較的消去法的に選ばれているのではないかと思っていますが、
WindowsPhoneはもっと積極的な理由で使われそうな、とてもかっこよく、つかいやすそうで、iPhoneのあからさまなパクりでもなく、MSが満を持して出してきたよくできたスマートフォンだと思います。
私も含めWindowsという名をきいただけで、うっと拒否反応を示す人もいるかもしれませんが、見ればわかりますが、デザインなど一新されているので期待がもてそうです。

WindowsPhoneではAndroidで問題だったマーケットの問題や、デバイスの規格がバラバラでアプリが動かなかったり見た目が崩れたりする問題などにうまく対処されており、アプリの数さえそろってくれば、正直Androidはかなりやばいのではないかと思います。

あとはデバイスのメーカーがどれだけWindowsPhoneを載せるかにかかっているのではないでしょうか。

結構Androidはオープンソースそのままだとほぼ使い物にならず、各メーカーが独自に手を加える必要があり、製品としてよいものをだそうとするとかなりの力が必要となります。
その点WindowsPhoneがどうなのかはわからないですが、たぶんAndroidに比べると断然楽だと思うのでメーカーもさっさと手のかかるAndroidから手をひいてWindowsPhoneにいくという決断を下すということも十分考えられそうな気が。

Androidは開発者のおもちゃとしては最高ですが、残念ながら今がピークなのではと個人的に思ってたりします。そのうちPCのOSと同様にMS対Appleの構造になるのではないかな。
0 件のコメント:
ラベル: ,

2011年7月23日土曜日

ABC2011Summer レポ

ABC2011Summerに参加してきました。

Android Bazaar and Conference 2011 Summer
http://www.android-group.jp/abc2011s/

感想

回を重ねるごとに熱が帯びてきている感じのABC。
午前の基調講演は見に行かず、ちょっと遅めに行ってバザールを見て、午後からカンファレンスに参加してきました。

前回は、基調講演⇒カンファレンスという流れでフルでカンファレンスに参加していたら、全然バザールが見れなかった反省を踏まえてちょっと変えてみましたが、結構空いててよかったです。
また、カンファレンスも前回の時点で結構立ち見も多かったので、今回はデザインセッションに絞ってずっと居座る作戦で成功しました。が、他のも見たかったな・・

あと懇親会にも参加して、他のエンジニアの皆様と交流することができ、色々と情報を収集することができ有意義な時間でした。当方人見知りなので結構疲れますが、頑張って出るべきですね。話のネタとして名刺と自作アプリとかは必要だなと思いました。

以下デザインセッションのメモ。

メモ

・Google I/O 2010で紹介されたデザインパターンを参考にするとよい

・AndroidとiPhoneでは全然UIが違う。iPhoneは左上に閉じるボタンがあったりと作法が違う
・Android UI Designe Patternは以下のようなものがある
詳細はこちらを参照（http://dl.google.com/googleio/2010/android-android-ui-design-patterns.pdf）

  1. dash board
  2. action bar
  3. search bar
  4. quick action
  5. companion widget

・Googleが作っただけあってこれらのデザインはwebの設計思想に近い
・HoneyCombではaction barをフレームワークでサポートするなど組み込まれてきている
・日本と欧米では操作の仕方が結構違う（日本では片手が多いが海外は両手だったり）

・スマートフォンを自分以外の人がどのように使っているのか考える必要がある
・単に画面を小さくしたのではだめ
・スマートフォンらしさ：コンテンツに集中。　iPhoneらしさ：迷わず使える
・コンテンツとコンテキストを再整理する。
・プロトタイプをつくるには、ステンシルやcacuuなどのツールを使うのもよい
・keynotopia(http://keynotopia.com/)というツールも便利

・横スクロースしない、横幅にフィット
・Landscapeだと見やすくなるが情報量が減る
・LandscapeとPortraitでレイアウトを変える。
・ひとつのソースでレイアウトを手間がかかる。
・ボタンは44pixel以上必要
・今後はレスポンシブWebデザインで１ソースでマルチデバイス対応が多くなりそう
・現状のサイトをスマートフォン対応するよりも最初からスマートフォンを意識したデザインにしておくとよい

・Androidの解像度は大きく分けて４種類ある
・ボタンなどは9patchを使うことで解像度の変化に対応できる
・draw 9patchとうツールがSDKに入っている（ただし使いにくい）

リンク

丸山先生の基調講演資料

0 件のコメント:
ラベル: ,

2011年7月21日木曜日

Mac OS X 10.7 Lionインストール

Mac OS X 10.7 Lionがついにリリースされたので早速入れてみました。

Mac App StoreからLionはダウンロード。
かなり大きいファイルなので一晩寝かして起きたらダウンロード完了していました。

インストールは約３０分程度であっさりOSのアップデートできました。

大きく影響があったのはやはりマウスのスクロールの前後が逆になったことで
マジックマウスだと微妙なのでシステム環境設定で「スクロールの方向」のチェックボックスをOFFにして解除しました。
Lionでは色々とマルチタッチ操作が追加されているようなのでマジックトラックパッドを注文しました。

あとはExposeがMissionControlに置き換わった感じで、ちょっと慣れるのに時間がかかりそう。

またXcodeを使っている方が気をつけなければならないのは、Xcode4.1にアップデートしないとXcodeが立ち上がりすらしないという点です。
たぶんLionにしてからでないと4.1はダウンロードできないので、ダウンロード時間を考慮してかなり時間に余裕を持ってやらないと、Xcodeが使えずに困ってしまうという事態が起こってしまいますので要注意です。

私の場合は特にトラブルは発生せずにXcodeのアップデートはできましたが、たまにitunesを立ち上げてもいないのに、itunesを落とせとか言われる方もいるようで、そう言った方はアクティビティモニタを起動して、itunes Helperのプロセスを終了させればいいみたいです。

0 件のコメント:
ラベル: , ,

2011年7月13日水曜日

2011年 目標の中間経過

今年の目標としてこんなのを立てていました。
http://yanayblog.blogspot.com/2011/01/2011.html


早くも半年経過したところで振り返ってみます。

  1. 読んだ本の感想を書く
    • △：半分くらいは書いたかなぁ・・というところです。。技術書メインにしていたのでちょっと書き難かったのもありますが、反省して後半は書いていこうと思います。
  2. ソフトウェアの名著を月一冊読む
    • ☓：優先度を下げて実用的なのを読んでいたので１冊しか読めてません！これも反省。。
  3. Python＋JavaScriptで実用的なプログラムを作る
    • △：正直Webプログラミングは全然やってません。その代わりにiPhoneアプリを一個作って現在自分でテスト中です。
  4. TOEIC700以上
    • ◯：695点だったのでクリアできそうな予感
  5. セミナー、勉強会に10回以上参加
    • ◯：８回
読書がちょっと放置気味だったので後半は少し巻き返せたらと思います。
３の目標はiOSアプリをAppStoreにリリースするに変更ということで頑張りたいです。
0 件のコメント:
ラベル:

2011年6月29日水曜日

Googleからどどーん

Google+
http://gplusproject.appspot.com/static/ja.html
Googleの新たなSNSって感じで結構満を持して出したって感じがします。
Facebookとの違いはFacebookは友達にはすべて平等に公開ですが、
Google+では「サークル」という概念がありその中でのコミュニケーションといった感じでしょうか。
GoogleのSNSはダメというジンクスと、Facebookの牙城を切り崩せるのかというところがポイントですね。

Swiffy
http://googlecode.blogspot.com/2011/06/swiffy-convert-swf-files-to-html5.html
FlashをHTML5に変換するサービスです。
どこまで完成度が高いのかはGoogle labなのでよくわかりませんが、
Flashの終焉も刻々と近付いている感じがします。

Google Developer Day 2011 Japan
http://googledevjp.blogspot.com/2011/06/google-developer-day-2011-japan.html
GDD2011が11月1日＠パシフィコ横浜で開催されます。
今年も参加するにはクイズに正解しないといけないみたいなのでがんばらないとです。
0 件のコメント:
ラベル: , ,

2011年6月19日日曜日

Objective-Cで気をつけるべき点

C++やJavaからObjective-Cを使うにあたって間違いやすい点や異なる点です。

同じオブジェクト指向言語といっても、言語によって慣習や考え方はかなり異なることがあります。
他の言語の慣習や考え方を持ち込むのは可読性を損ねるだけでなく、一貫性も損ねることとなるので言語の考え方や慣習はきちんと学ぶべきだと思います。


インスタンス変数はデフォルトはprotected
@privateを使うことでprivateにすることができます。publicも同様にできますが、カプセル化を阻害するのでもちろん推奨されていません。


メソッドはすべてpublic
ヘッダーファイルでプロトタイプ宣言してなくても、メッセージを送ると呼び出せますので、.mファイル側にだけ宣言していたとしてもprivateになったわけではありません。
Objective-C 2.0(iOS)であればクラスエクステンションを使うことで、ヘッダーファイルのほうにプロトタイプ宣言をしなくて済むのとクラスエクステンションを見るとどれがprivateメソッドなのか判定することができます。
privateメソッドに接頭語を付けて見分けるというのも合わせて使ったほうがいいかもしれません。
Extensions(The Objective-C Programming Language)

propertyのデフォルトはatomic
propertyはデフォルトはatomicになっているので無駄に排他制御がかかり性能に影響します。排他不要の場合はnonatomicを必ず書きましょう。

initでインスタンス変数はすべて0で初期化される
Javaと同様に初期化が自動でされるので、C++のようにコンストラクタで0で初期化する必要はありません。
Allocating and Initializing Objects(The Objective-C Programming Language)

nilのオブジェクトにメッセージを送っても無視されるだけでクラッシュはしない
C++のようにクラッシュ回避という意味でのnilチェックは不要です。nilチェックは通常ケースのハンドリングで使います。
Sending message to nil(The Objective-C Programming Language)

BOOLのYESは1とは限らないので、if文内での判定には使わないようにする。
BOOLはunsigned charと同じなので1以外の数が返ってくる恐れもあります。 == YES は避けたほうがよいです。

NSString,NSColor,NSURLはretainではなくcopyを使う
NSStringなどといった value objectsとよばれるオブジェクトにはcopyをつかったほうがよいそうです。
copyとして保持したり返したりするので不変であることが保証できるからのようです。
Value Objects and Copying(Memory Management Programming Guide)

string = value;
と
self.string = value;
は別物
全者は単なる代入ですが、後者はpropertyによって作られたアクセッサを使っています。後者だとpropertyの宣言によってただの代入だったりretainやcopyされたり排他がかかったりと動作が異なります。

delegateはretainしない
巡回参照による無限ループにはまらないようにdelegateはretainせず、参照だけを保持する。
Weak References to Objects(Memory Management Programming Guide)

メソッド名に接頭語は使わない。
doやdoesをつけるのも意味的な問題で推奨されていません。getも付けないのが慣習です。
General Rules(Coding Guidelines for Cocoa)

引数にキーワードをつける。
キーワードなしでもメソッドの宣言はできますが、キーワードをつける。
General Rules(Coding Guidelines for Cocoa)

プライベートメソッドは独自の接頭語をつけたほうがよい
知らないうちにオーバーライドしてしまうことを防ぐためと、プライベートメソッドを見分けやすくするために、接頭語をつける。ただしアンダーバーはAppleが使っているので独自のものを用意する。例えばBF_addObjectなど
Private Methods(Coding Guidelines for Cocoa)
Typographic Conventions(Coding Guidelines for Cocoa)

#defineは使わずenumもしくはconstを使う
C++と同じで#defineだとプリプロセッサで数値に置き換えられてしまうので、enum,constを使う。
Other types of constants(Coding Guidelines for Cocoa)

通常ケースのハンドリングでは例外は使わない。
JavaではFileNotFoundなど通常のハンドリングにも例外を使いますが、Objective-Cでは、配列外アクセスなどクラッシュするような場合など本当に例外な場合にのみ使います。
そのため、例外はテストなどのデバッグ期間でしか発生しないものでなければなりません。
Exceptions and Errors(Coding Guidelines for Cocoa)

名前空間はない
C++やJavaのように名前空間はありません。NSとか接頭語がついているのもそのためです。

ヘッダーファイルでの2重インクルードの防止は不要
CやC++ではヘッダーファイルの2重インクルードを避けるために#ifdefをヘッダーファイルにつけるのが慣習ですが、Objective-Cでは#importを使えば不要です。


余談ですが、Googleのガイドラインを見るとかなりがっちり決まってたので驚きました。
Objective-Cはフリーダムにかける方だと思うので複数人での開発であれば、Googleのように厳密に決めてやったほうがいいと思います。しかし、性能などとのトレードオフもあるので他のガイドラインをまるパクりではなく、プロジェクトにあったものを選択して採用すべきです。

参考資料
Cording Guidelines for Cocoa
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html

The Objective-C Programming Language
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html

Memory Management Programming Guide


Google Objective-C スタイルガイド(日本語訳)
0 件のコメント:
ラベル: ,

2011年6月13日月曜日

HPとRIMのタブレット

webOS,BlackBerryと新たなプラットフォームを要したタブレットがいよいよ登場。

HP、PalmのwebOS搭載タブレット「HP TouchPad」を7月に発売http://www.itmedia.co.jp/news/articles/1106/10/news020.html

RIM、タブレット端末「BlackBerry PlayBook」を世界展開、16カ国・地域で発売へhttp://itpro.nikkeibp.co.jp/article/NEWS/20110613/361295/

これでタブレットの役者はほぼ揃いました。
Windowsはかなり遅れをとってますね・・

といってもただ出揃っただけで、やはりどれもiPadを照準としてつくっていたのは明らかで
残念ながらiPad2が出てしまった今では、比較すると見劣り感がいなめなく、かなり不利な状況ではないでしょうか。
0 件のコメント:
ラベル: ,

Objective-Cの性能・フットプリント

Objectiv-CではC++と比べて、開発者が楽になるようにいくつか仕組みが入っています。
それを効果的に使うことによって開発の生産性をあげることが可能ですが、よく知らずにつかっていると、性能を劣化させたり、フットプリントが大きくなり無駄に大きいアプリになってしまう恐れがあります。

このような問題が発生しやすいポイントについて記載します。

プロパティ
Objective-Cでは、アクセッサ、いわゆるただ値をインスタンス変数に読み書きするだけのGet/Setメソッドを開発者が記載する手間を省くのを手助けしてくれます。
それがプロパティです。

・プロパティを使わない場合

@interface ClassA : NSObject {
    NSArray* array;
}
- (NSArray*)getArray;
- (void)setArray:(NSArray*)inArray;
@end

@implementation ClassA
- (NSArray*)getArray
{
    return array;
}

- (void)setArray:(NSArray*)inArray
{
    if ( array != inArray ) {
        [array release];
        array = [inArray retain];
}
}
@end

・プロパティを使った場合

@interface ClassA : NSObject {
    NSArray* array;
}
@property (nonatomic, retain) NSArray* array;
@end
@implementation ClassA
@synthesize array;
@end

という風に見れば一目ですが、プロパティのほうが書くコーディングの量が全然違ってきますし、retainとかcopyとか指定すればそのとおりに実現してくれるので大変楽なので使ったほうがよいです。

しかし、プログラムの書く量が少ないからといって、プログラム自体(実行ファイル)が小さくなるわけではありません。
プロパティを使ったとしても実際にコンパイルすると、プロパティを使わない場合と同等の量の実行ファイルが生成されることになります。

逆にGet/Setの片方しか使わない場合は、プロパティを使わないほうが小さいプログラムとなります。
ですので、なんでもかんでもインスタンス変数をプロパティにしてしまうのはプログラムサイズとしてはよくありません。

また、性能面でも少し影響がでる場合があります。

自分のクラスのインスタンス変数にアクセスする場合、以下の２パターンあります。
(arrayはプロパティとして宣言されてる場合です）

・①

array = [NSArray new];
・②

self.array=[NSArray new];


①と②は、C++をやっていた人にはこれは同じに見えますが、これは別物です。

①は単純な代入ですが、②はアクセッサをつかって代入をしています。
プロパティでassignだったら結果は同じですが、retainなどをしていると②のほうはretainされます。

ですので、retainするために、②を使うのは正しいですが、単に代入するのに②を使うと①に比べて関数を呼び出す分だけオーバーヘッドが生じます。

ひとつひとつではたいしたオーバーヘッドではありませんが、大きいプログラムとなると小さな積み重ねも大きくなることもあるので、そのことを理解しておく必要はあると思います。

Autorelease
つぎにAutoreleaseです。
Autoreleaseはガベージコレクション（GC）みたいで楽なイメージがするかもしれませんが、もちろんGCとは全然違います。

最も気にすべき違いはメモリを開放するタイミングです。

GCは実装によって様々あるので、特に触れませんが、Objective-CのAutoreleaseがメモリを開放するタイミングは、GUIからのイベントを受け取る実行ループでAutoreleaseプールがあるので、一回の実行ループ毎にAutoreleaseプールは開放されます。

つまりひとつのイベント処理が止まるまでAutoreleaseしたメモリは消されずにひたすら溜まりっぱなしということになります。
ですので、ひとつのイベント処理でメモリを大量に使うようなプログラムでAutoreleaseばっかり使っているとメモリ不足になる危険性があります。

これを回避するにはAutoreleaseの使用をできるだけ避けてreleaseで開放するか、独自のAutoreleaseプールを作成して、それを適宜開放するかです。

Autoreleaseは使わざるを得ない場合もあり、完全に回避することは難しいので、両方使うのが望ましいと思います。

-----------------------------------------------------------------------------------------------------------
嘘とか間違いなど指摘していただけると幸いです。

Objective-Cの理解に役立つ本

Objective-Cの言語の本はこれしか読んだことがないので・・。

0 件のコメント:
ラベル: ,
登録: 投稿 (Atom)