2011-11-26

Androidデザインに関するアレコレ



最近、Lexues Academy というアプリ開発塾(?)で専属講師的な感じでアプリ開発を教えています。で、その一貫で外部講演がときどき開かれるのですが、先週と今週の外部講演で聞いたデザインの話が結構面白かったです。先週はAndroid女子部部長の @yanorin さんが講演され、今日はAndroid女子部副部長の @yanzm さんのお話をされました。(写真は @yanzm さんの講演の1コマ)

両名ともデザインに関するお話をしていましたが、僕的に特に面白かったのは、デザインするときに役立つツールの話です。覚えてる限りですが、話全体を通して、次のツールが取りあげられていたと思います。順不同。



他、参考図書など(覚えてる限り):
  • アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
  • アジャイルサムライ
  • Designing Interface
  • Non-Designer's Design Book
*ちなみに、当日 @yanzm さんが使った資料(集)はこちらから。

留学中にデザインの授業を取ってから、デザインの勉強を継続的に行うようになったのですが、ツールに関する知識はあんまりなく、留学中も Adobe 以外はあんまり触らなかったので、こういった話は結構新鮮で興奮します。

皆さんのご参考にもなれば幸い。

2011-11-17

Quick Start for Public Key Authentication on SSH



今までのプロジェクトの遺産で、別に公開しても良さそうな簡単な技術の話は公開しましょうねキャンペーン実施中。今回は、SSHの公開鍵設定の話。仕組みとかは原理とかは全部端折ってます。


以下、SSHの公開鍵設定についてのお話。
=======================

ここではSSHの公開鍵設定を原理などを省いて説明します。
Linux/OSXなどのUNIX系のみで有効な説明ですが、Windowsユーザの方はPuTTYのオプション
であるのでググれば説明があると思います。


1. 鍵をつくる
--------------
まず、公開鍵と秘密鍵のペアを作ります。

 $ ssh-keygen

オプションがいろいろありますが、詳細はmanしてください。
色々聞かれますが、基本全部デフォルトのままでいいのでエンター押してください。
パスワードが必要なら入力してください。

すると~/.ssh以下にid_rsaとid_rsa.pubというファイルができます。
id_rsaが秘密鍵、id_rsa.pubが公開鍵です。


2. 公開鍵をサーバーに置く
---------------------------
これは任意の方法で行なってください。

 $ scp ~/.ssh/id_rsa.pub 112.233.445.566:~/id_rsa.pub

など。

# 112.233.445.566 はお手持ちのサーバのIPアドレスに脳内変換して下さい。


3. 公開鍵をキーチェーンに追加する
------------------------------------
~/.sshの下にあるauthorized_keysに公開鍵を追加します。
サーバ上での自分がログインするユーザのホームディレクトリ以下の.sshです。

 $ ssh 112.233.445.566
 $ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys

以上です。

ちなみに、2. 3. は初回であれば

 $ scp ~/.ssh/id_rsa.pub 112.233.445.566:~/.ssh/authorized_keys

のようにひとつのステップで省略できます。

また、~/.ssh/configを以下のように設定しておくと楽です。
(べつにシェルの履歴で簡単に辿れますが)

$ /Users/yasulab/.ssh% cat config 
  Host hogehoge
      Compression yes
      Hostname 112.233.445.566
      User yasulab

$ /Users/yasulab/% ssh hogehoge

この~/.ssh/configの設定により、以降、hogehoge サーバにパスワード無しでログイン出来るようになります。

以上、SSHの公開鍵設定についてのお話でした。


2011-11-16

IDEO訪問記を又聞きしてみた。



シリコンバレーにあるIDEO本社に行ってきた友達の話を聞いてきました。2010年2月に書いたメモで、元々はSorarierというプロジェクトのメンバー向け情報だったんですが、公開した方が世のため人のためだと思ったので、公開します。ご参考まで。

以下、僕がインタビューして聞いた話のメモを記します。
#1 といっても、1年前ですが...
#2 メモなので、箇条書きがかなり多いです。雰囲気を感じt(ry

[Index]
- Brainstormingについて
- 参考文献

[Brainstormingについて]
Brainstormingのプロセス:
- 1. Listen
- 2. Learn
- 3. Envision

1. Listen
- ユーザインタビューについて

メモ:
- IDEOでは、ユーザインタビューは定性評価と定量評価を以下のように使い分ける。
-- 1. 定性評価: 右下図(縦軸=ユーザ数, 横軸=ヘビーorライトユーザ)の両極端を5人ほどインタビューする
--- 一般的なユーザは「なんとなく」使っているだけ。
--- ある製品を絶対に使わないと決めている人や、使い倒している人は、確固な意志を持っていることが多い。
---- 定性評価では、この意志が参考になる。
-- 2. 定量評価: 大体500人程度を目安ににアンケートを取る。

2. Learn
- 2.1 Post Itの方式で、1.の結果からアイデアを出す。壁にペタペタ貼る
-- このとき、意識的に絵を書くようにする。
#次の図は文字が多いので悪い例。


-- 2.2 出たアイデアをGroupingする

2.3 各Theme毎に再度アイデアを出す。

2.4 再度Groupingをする。(以後、Groupingとアイデア拡張を繰り返す。)

Point:
経験的に、繰り返しの回数(横軸)とアイデアの質(縦軸)は、ルート関数っぽい。「何回繰り返すか?」が重要。

3. Envision
- 良いアイデアが出たら、早速プロトタイプを作成する。ここではスピード感が大事。
-- プロトタイプの作成を通して、未知の問題を洗い出す

4. /* ...時間がなかったのでEnvisionまでのプロセスしか聞いてない... */ 
NOTE: これ以降のプロセスやより詳しいプロセスについては、次の参考文献「Change by Design」に書かれているとのこと。


[参考文献]
-- Tim Brown (著) 
-- 2010年4月に日本語訳が出るとの噂。

2011-11-14

Sinatra + SQLite3 + Hamlで画像アップロードしてみた。



最近、Sinatraを使いたい衝動に駆られたので色々とSinatraで遊んでます。とりあえず画像をいじりたい+データベースを使いたい、ってことで Sinatraでファイルをアップロードさせる方法 と SinatraからDataMapperを使う を参考にしながら、Sinatra DB Demo with Images を作ってみました。動作イメージが分かりやすいようにモデルはtwitter-likeにしてます。で、DBの中身が分かりやすいようにtableでサクッと区切って表示したりなどやってます。こんな感じです。jQueryとかCSSとかは使ってないので、見栄えはあまり良くないです。


なんとなく、フォームを使ったPOSTメソッド以外にも、GETメソッドを使ったPostも出来るようにしてみました。何故実装したかは不明。悪い実装例(?)。使い方は、'/create'にアクセスするだけですが、RESTful的にはこういう風なGETの使い方はやっちゃいけないかと思います。

'/create' にアクセスして、


その後、ルートディレクトリに戻ると、こんな感じでちゃんとDBにデータが入っていることが確認出来ます。


ちなみに、データベースの中身をいじってデバッグしたいときなんかは、 Lita というデスクトップアプリケーションが便利でした。こんな感じで編集出来ます。


おまけ程度の情報ですが、EmacsでHamlを使いたいときはHaml-modeが便利かもです。設定はこんな感じで。indent-tabs-mode nilを入れないと、Hamlがカオスな反応をするので注意。

(add-hook 'haml-mode-hook
  '(lambda ()
     (setq indent-tabs-mode nil)
       (define-key haml-mode-map "\C-m" 'newline-and-indent)))

以上、Sinatra DB Demo w/ Imagesの概説でした。参考になれば幸い。
とりあえず今後は、DELETEとPOSTメソッドを実装して、なんちゃってRESTfulを作ってみたいかも。

yasulab/simple-db-demo-with-img - GitHub
https://github.com/yasulab/sinatra-db-demo-with-img


2011-11-04

第1回 fluxflex meetup in Tokyoで発表して思ったこととかアレやコレや



はい、今さらなお話です。勢いで "imasara"というタグを付けてしまったぐらいに今さらなお話です。でも、数百人の前で発表する機会なんてあんまり経験して来なかったので、せっかくなので当日までのアレコレや、言い訳や、その後の後日談などを思い出しながら書いてみます。

約1ヶ月前、第1回 fluxflex meetup in Tokyo というイベントがありまして、そこで「GitHub Importを使った fluxflex へのデプロイ例」という内容を発表してきました。元々は、一般参加者として参加するつもりでした。だったんですが、Simple Timekeeper という、fluxflex上で動いているサービスが、幸運にも fluxflex の中の人の目に止まったようです。それで、DMで僕の方に発表の誘いが来て、そして、発表に至ったという感じです。

言い訳をさせて下さい。僕はアイデアが思いついたら可能な限り早く作るのが好きな人間です。だって良いアイデアを思いついたら、早く動いてる姿が見たいじゃないですか。Simple Timekeeper も例に漏れず5時間ぐらいで作ったサービスです。なので、中身を見ると「body bgcolor="black"」とか書いてあるぐらいのウ◯コードとなっています。しかしまぁ、「まずは発表資料を用意するのが優先だ」と考え、というか今さら書き直す時間もなく、気力も無く、クソ◯スのまま発表に至りました。本当はもっとキレイに書けるよ!だからそんな目で見ないで!

ところで、僕はずっと fluxflex のことを「auto-scaling」を推している PaaS だと思っていましたが、いつの間にか軽量なウェブサービス開発者をターゲットにした PaaS にPivot(?)したみたいですね。僕の思い込みかもしれないので、実際のところは今度会った時にでも聞こうかなーと思っていますが、少なくとも僕からしてみたら最高のpivotです。というのも、僕は軽量なウェブサービスをたくさん作ってたくさん失敗するタイプの人間なので、もうアレですね。最高です。「ずっとこの路線で行ってくれたら‥」と密かに願っています。「Pivotしたのかなー」と思った背景は色々とありますが、詳細は後日 Okinawa.rb で発表した fluxflex meetup survey にて。地域Rubyの会で最もRubyの話をしない人間とは僕のことです。



僕はシンプルなウェブサービスやアプリがもっともっと増えたら良いなーと思っています。それには、僕がZen信者だからとか、そもそも個人でスゴいウェブサービスを作る技術が無いからとか、色々な理由があります。ですが、最大の理由は、スゴいモノじゃなくても、数万ラインのモノじゃなくても、多くのユーザに使ってもらえるイイモノはたくさんあると信じているからです。ホイッスル on Androidを実際に作ってみて、「あ、やっぱいけるじゃん」と確信しました。

でも、僕自身そうでしたが、頭ではそう思っていても、実際にそうするのは、若干の度胸が必要です。だって、まず、失敗することが多い。作っても誰も見てくれないとかザラです。公に自分の失敗を晒すのは、やはり若干の覚悟が必要です。

しかも、ウ◯コードになりやすい。まぁこれは僕だけの特別な傾向かもしれませんが、少なくとも僕ぐらいのスキルでは、ウ◯コード量産機になる度胸が必要だと思います。ウン◯ードでしかも誰も使ってくれないときなんかは、もう完全に涙目ですよ。



「もっとキレイに書け」とか「汚いコードを書くヤツは(ry」みたいな風潮を僕は感じます。企業で、大勢で書くモノを作るときは全く持ってその通りだと思います。でも、個人や小さいチームでモノを作るとき、本当にそうなんでしょうか。あのGoogleですら初期バージョンのコードは酷いモノだったそうです。それなら、凡人の僕が書くコードなんて酷くて当たり前な気がします。なんていうんですかね、フリーミアムが「Freeと1円以上のときは法則が違う」と主張したように、個人や少人数でモノを作るときと、企業や大勢でモノを作るときの法則は違うような気がします。気がするだけです。証拠も何もありません。

「証拠が無いなら作っちゃおう」。そういうのは実験して確かめればいいですよね。ということで、週末ものづくり講座ってのを実際に開いてみました。どうなんですかね。モノ作りと同じで、一般的には失敗する確率の方が多そうです。ですがまぁ、そこらへん色々試してみて、結果を見てみて、その後じっくり考えることにします。

まさか fluxflex の話からモノ作りの話に飛ぶとは僕自身思いませんでしたが、とりあえずここらへんに着地して終わりにしようと思います。

そんじゃーn(ry





追記:

最近「自分のアタマで考えよう」という本を読んだので、久々に自分のアタマで考えて文章にしてみたんですが、本書でも述べられているように、最初はろくなもんにならないっすね。コード書くのに失敗したり文章書くのに失敗したり、失敗から離れられない今日この頃です。でもまぁ、「失敗しろ」って主張しているようなもんなので、主張してる僕が失敗しないことには始まらないっすね。