MakerFaireに行ってきました！
MakerFaireとは
MakerFaireとは、個人や企業が作ったものをそれぞれ持ちよってみせあう地上最大の展示会です。MakerFaireの目的はコミュニティを、楽しませ、情報を提供し、結びつけ、より大きくすることにあります。
今年で8回目のMakerFaireは世界各地で行われていて、サンテマオ、デトロイトといろんな場所で行われています。
なにをしてきたか
そんな大きな展示会に自分はなにをしにいったのかというと、自分はFourBeat(下写真)の出展者のお手伝いにいってきました。
FourBeatの詳細説明に関しての詳しい詳細はここをご覧ください。
気になった展示品
自分は主たる目的はお手伝いにいったのですが、他の展示品を見る時間も沢山あったためその中でも自分が気になった展示品を3つ紹介していきたいとおもいます。
-
ミクのデスクトップライブステージ
-
３Dプリント飛行
-
oscilloclock
ミクのデスクトップライブステージ
ipadでプロジェクションマッピングアプリを開発し、それをモバイルプロジェクトに映し出すことができるものを作っていました。映し出す素材はダンボールと網戸です。簡単に入手できる素材のため自宅でミクちゃんが楽しめてしまうというものです。
前々から、プロジェクタを使って立体的に映写する技術というものにすごく興味をもっていました。それをプロジェクタ1台だけでここまでのことをしてしまうということに感動しました。
気に入った理由として上記のようなものもあるのですが、一番引かれた理由はただ単純に自分がボカロが好きだからです。自分の好きなボカロアイドルがすぐそこでおどってくれるなんてこれほどの幸せはないですよね！ぜひ、おうちに欲しいです！
３Dプリンタ飛行体
上の写真のようにかわいい飛行体を３Dプリンタを使って作っているチームです。こいつが空をとんでる様子が上左写真にあるのですが、すっごくおちそうなんですけど必死ではばたいていてそれが超かわいいんですよ。
まぁ、そこだけでも気に入った理由としてはでかいのですが、ここのチームはこれをつくることが本業ではなく３Dプリンタを使うとこういうことができるよっていうのを広めたり、相談したりするチームなのです。
３Dプリンタについてはどういうことができるのかというのを全然把握してなかったのですが、こういった作品をみて３Dプリンタには無限の可能性があることがわかりました。３Dプリンタで作った製品も素晴らしいし、アピールの仕方もすごくおもしろかったので気に入りました。
oscilloclock
最後に紹介するチームの製品が個人的には今回の展示会の中で一番おしゃれだなーとおもいました。これは昔のオシロスコープに使われていたブラウン管を再利用して、時計を作ったものです。コンセプトは昔のレトロな感じと外観のモダンな感じの融合だそうです。
ブラウン管の種類を選ぶことによって残光を残すこともできるとのことです。開発者はこの製品に溺愛していて、説明もとっても熱弁してくれました。ちょっとひきましたが、この製品のよさがひしひしと伝わってきて、かつ、おしゃれだったので今回の展示会のなかでかなり印象に残っています。
全体としての感想
他にも人力で空をとぶ飛行機やツイートした内容を泡で表示してくれるなどユニークな展示品が沢山ありました。
僕は最近、AndroidアプリとかWebサービスといった画面だけでのプロダクトしか作っていなかったため、画面だけのプロダクトでなくリアルでも楽しめる展示品が沢山あり、画面ではできないこと、ハードがからまないと出来ないことなどがわかりとても刺激を受けました。
出展者に共通して言えるのはみなさんとても楽しそうに自分たちの製品を紹介・開発していることですかね。「どう？すごい？たのしいよね？」みたいな感じで自分が対して 興味のないものでも必死に説明してくれたり、ここはこういう風につくったんですよみたいな感じで自分が作りたいものを作って、それに全力の愛(？)を注いで、いてそういう「ものつくり」精神みたいなものがひしひしと伝 わってきました。
ものつくりをする一人として、何歳になっても「ものつくり」のたのしさはわすれてはいけないなと強くおもいました。
Twitter BootStrap をつかってみた
Twitter BootStrapとはなにか
Twitter BootStrapとはかっこいいWebサイトをつくるためのCSSフレームワークです。かっこいいボタンやかっこいいプルダウンメニューを０から作っていくのはとても大変です。それを簡単に作れるようにしてくれたのが「Twitter BootStrap」です。Twitter BootStrapを使うと下の図のようなちょっといけてるデザインを簡単に作成することができます。
Twitter BootStrapの特徴
特徴１ マルチデバイス対応
「Twitter BootStrap」では、どんなデバイスでも同じように見えるようになっています。デバイスの種類は大きく4つに分かれています。また、TwitterBootStrapではこのデバイス間の対応もできます。
- スマートフォンのような小さいデバイス（<768px）
- 小さめのタブレットデバイス（768px～992px）
- 普通のタブレットデバイス（992x～1200px）
- パソコンなどの大きい画面（>1200）
特徴２ 様々な機能
CSSだけでなく、JavaScriptやJQueryといった様々な機能が提供されています。下のような機能が簡単に使用することができます。
- モーダルデザイン
- ドロップダウンメニュー
- アラート
- ボタンデザイン
- ナビゲーション
- フォームデザイン
特徴３ 無料の素材も豊富
自分のようにデザインやアイコンをつくるのにまったくセンスがない人でも使えるようにたくさんのアイコンが提供されています。
特徴４ リファレンスが豊富
これは自分が他のBootStrapなどを触ったことないため特徴にはカテゴリされないかもしれないのですが、Twitter BootStrapはリファレンスがしっかりしてるように感じます。下図はDropDownメニューのリファレンスです。サンプルと使用法、図にはないのですがサンプルコード、オプションなども表示してくれます。そのため、機能の動きも直感的でわかりやすいし、サンプルソースもあるため流用しやすいので効率的にプログラムをかけると想います。
実際につかってみました
HTMLをつかってログイン画面作ってみた
まずはHTMLだけをつかって以下のようなログイン画面をつくりました。これだけだとちょっと味気ないですよね。これをTwitter BootStrapをつかってデザインしてみます。
Twitter BootStrapをつかってキレイにしてみました。
上のログイン画面をTwitter BootStrapを使ってデザインしてみました。結果は下の画面のようにちょっとおっしゃれな感じになりました。
まとめ
Twitter BootStrapの紹介をしてきました。簡単に使えてしかもかっこいいデザインができるので、デザインは苦手だなっていう人には良いツールになるとおもいます。
上記の二つのプログラムのソースを知りたい方はこちら↓
ViewPagerをつかってみた。
ViewPagerをつかって下のような画面をつくってみました。
これの使い方および注意を書いていきます。
使い方
xmlファイルへの定義
ViewPagerの定義は以下のようになります。
スワイプして遷移する画面を２つ定義します。
< res/layout/activity_name.xml>
< res/layout/activity_event.xml>
javaファイルへの定義
PageAdapterを実装したカスタムクラスをつくります。下にそれぞれ最低限必要なメソッドとその説明を書きます。
- isViewFromObject()
ObjectにViewがはいってるかどうか判断する - getCount()
ViewPager に登録する全アイテム数を返す。 - instantiateItem()
アイテムを追加するときに呼ばれる。このメソッド内で View をコンテナに追加する。 - destroyItem()
アイテムを削除するときに呼ばれる。このメソッド内で View の削除をおこなう。
instantiateItem()の中に遷移する画面の設定を行います。
使用上の注意
- instantiateItemメソッドの返り値を適当にしてしまうと動かなくなる。
- 表示されるレイアウトの順番はpagesに格納されているレイアウト順である。
補足
今回は画面すべてをページ送りしましたが下のようなレイアウトにすることで赤枠の部分を固定し、青枠のところだけページ送りすることができます。
ソースはこちら
リファクタリングのスヽメ
リファクタリングについて自分の理解があまかったため、どういうものかを説明し、実際におこなってみたので、その報告をしようとおもいます。
リファクタリングとは
リファクタリングとは プログラムの外部的振る舞い（動作）を変えることなく、内部構造としてのソースコードを変更することである。理解や修正がしやすいように整える目的で行われる。
リファクタリングのメリット・デメリット
では、リファクタリングのメリットはなんなのでしょう。リファクタリングするとなにがよくなるのでしょうか
- コードがよみすくなる
- バグをみつけやすくなる
- 機能追加をいれやすくなる
- 理解しやすい
- バグがへる
一見、いいことずくしのようにみえますが以下のようなデメリットもあります。
- コードをいじるため、あらたなバグがおこってしまう可能性がある
- わりと時間がかかる
個人的な感想ですが、慣れてないと時間を沢山費やしてしまう。
リファクタリングすべきコードとは？
リファクタリングの定義は分かったのですが、実際にどういうコードをリファクタリングするべきなのでしょうか。リファクタリングが必要なコードのことを「コードの臭い」といいます。以下はWikipediaに記載されている一例です。
- 重複したコード
同一あるいは同様のコードが複数箇所に存在 - 長すぎるメソッド
メソッド、関数、手続きが長くなりすぎている - 巨大なクラス
大きくなりすぎたクラス - 機能の横恋慕
他クラスのメソッドを過度に用いるクラス - 不適切な関係
他のクラスの実装の詳細に依存しているクラス - 相続拒否
基底クラスの規約が尊重されない形でのメソッドオーバーライド - 怠け者クラス
行うことが少なすぎるクラス - 重複メソッド
同一あるいは同様のメソッドが複数箇所に存在 - 不自然なクラス
簡潔な設計で十分なところに、過剰に複雑なデザインパターンの使用を強制する - 不適切な関係
クラス間の結合度が高く、privateがなくなる - コメント
コメントは多いが、よい説明になっていない
実際にリファクタリングしてみた
ここまで、リファクタリングの定義とコードの臭いについて述べてきたのですが、とりあえずやってみました。コードは自分が先日開発したアプリのソースの一部を実際にリファクタリングをしてみました。
リファクタリングした箇所を具体的に示していきます。
重複した変数を一つに
下のように似たような変数が沢山ならんでいるのですがそれをまとめました。Listを使ったら大分キレイになりました。
before
after
類似した初期化処理を一つに
先ほど変数をまとめたため変数の初期化も以下のようにループでまわせるようになりました。
before
after
重複した処理・メソッドをひとまとめに
先ほど変数をまとめたため管理が楽になりました。そのため似たような処理・メソッドををひとまとめにしました。
before
プログラム１(リファクタリング前)
プログラム２(リファクタリング前)
プログラム３(リファクタリング前)
after
プログラム１(リファクタリング後)
プログラム２(リファクタリング後)
プログラム３(リファクタリング後)
最後に全体のプログラムを以下にしめします。
まとめ
今回は自分のコードを用いてリファクタリングをしてみました。そしたらなんと500行だったプログラムが350行くらいまで縮小できました。それだけ無駄がおおかったということですね。もっとうまくリファクタリングできるとおもうのですが、自分ができる精一杯のことは出来た気がします。
最後に、実際にリファクタリングを行い学んだことを並べます。
- プログラムがみやすくなった
- リファクタリング中はこまめに実行すべき
- 機能を追加しやすい形になった
今まで混沌していた部分をキレイにしたことによって新しい機能を追加しても他のところを変更せずに追加できるようになった - 重複してきてるなーと感じたらリファクタリング
今回、一通りプログラムを完成させてから行ったため時間がとてもかかるため、段階的にリファクタリングをかけていくと効率もアップするとおもわれます。
ここまで、記事をよんでくださったみなさま、リファクタリングにかんしてもっとこうしたらいいんでねーのっていうのがあったら、面倒だとはおもいますがご指摘いただければ幸いです。
android起動までのプロセス
10月19日に行われた「Android起動周りのノウハウ」という勉強会に参加してきました。主な内容は、Android端末の電源をいれ、HOME画面が表示されるまでのプロセスの流れとかそのへんの話でした。しかし、ほとんど内容を理解することができなかったので、自分なりに調べたのでまとめます。
Androidが起動するまでの概略
まず、電源をONにしてからAndroidのホーム画面が表示されるまでの内部動きを下の図におおまかにあらわした。その下の図はAndroidのレイヤー構成です。今回はAndroidの起動プロセスを重視するのでBootloader、kernelについてはあまり深く説明しません。
Bootloader
Bootloaderとはカーネルから独立した特別なプログラムで、初期メモリの設定とカーネルをRAMにロードするために使用されます。簡単な流れを以下に示します。
kernel
kernelでは割り込みコントローラを初期化し、メモリ保護、キャッシュ及びスケジューリングを設定します。また、図2の一番下にあるようなドライバを読み込みます。
最後にKernelはinitプロセスをルートファイルシステムから調べて初期ユーザ空間プロセスとして起動します。
android
いよいよAndroidの起動プロセスを追っていくのですが、項目が多いので下のような順序で追っていきます。androidのソースコードはここにあります。
- initプロセスとは
- Zygoteの実行
- BootComplete
initプロセスとは
initとはLinux Kernelが最初に実行するプロセスである。initには大きくdeamon処理とboot処理の二つがある。
deamon処理
/dev以下のデバイスファイルの生成と削除,システムプロパティの書き込み処理などの処理をおこなう。
boot処理
/dev, /proc, /sys をマウントした後に/init.rc のスクリプトを読み込んで実行する。init.rcには4つの特徴がある。
アクション
アクションはコマンドのシーケンスで名づけられます。アクションはトリガを持っています。アクションは以下のような書式で定義されます。アクションが定義されるとaction_listというキューに格納されます。
on <triger>
<command>
コマンド
androidで使えるコマンドが定義されています。下は一部抜粋したものです。
サービス
サービスはInitが起動そして、（オプション）サービスが終了したときに再起動するプログラムです。下は、serviceの定義と一例です。サービスが定義されるとservice_listというキューに格納されます。
service <name> <pathname> [ <argument> ]*
<option>
オプション
オプションは、サービスへの修飾子です。オプションはInitがサービスをいつ、どのように実行するかに影響を与えます。ここでは省かしていただきます。
zygote
initプロセスの最後にaction_listとservice_listを順々に実行してきます。そうすろとzygoteというサービスを実行されます。
zygoteとは Android プログラムの実行に必要なダイナミックリンクライブラリと Java のクラスライブラリをロードした状態で待機する常駐プロセスである 。
Androidではアプリケーションや多くのその他のプログラムはJavaで記述されています。これらのプログラムはDalvikVMという仮想マシン上で動きます。
このzygoteが実行されるとそのプロセス上でsystem_serverというプロセスを実行します。このプロセスではActiveManegerなどのフレームワークを読み込みます。
その中のActivityManagerが起動時に読み込むアプリをロードし、それを実行すると無事HOME画面が表示されます(下の図参照)。
まとめ
後半は駆け足になってしまいましたが、電源ボタンをおしてから、HOME画面が表示されるまでの流れをおってきました。
自分で調べて内部のことがとてもわかり、勉強になりました。それでもまだまだ、詳しいことはわからなくて、ソースを追うことも書くことも難しいと思いますが、こういう世界なんだなっていうのはわかった気がします。
zygoteとかDalvikVMとかに関してはここだけでも記事がかけてしまいそうなくらい情報量が多い話なのでここらへんをいじらなければならないときがきたら、また書こうとおもいます。
ubuntu13.10がリリースされました。
ubuntu13.10が10月17日にリリースされましたので、早速アップデートしましたのでそれについて書いていきたいと思います。
ubuntu13.10のコンセプト
机面環境の Unity 7 がubuntu14.10までにUbuntu Touch 対面体を基にした新しい「集中型の」対面体で置き換えられる予定があるらしいです。
そのため、今回のubuntu13.10では新機能を付け加えていくことには重点をおかず、既存の機能を磨いていくというのがコンセプトらしいです。
じゃあ、何が変わったのか
- Unity 7が導入されたことにより、起動や動作が早くなった。
-
keyboard appletという新機能がつき、言語の変更、キー配置、キーボードレイアウトが間単に変更できるようになりました。
あと、アイコンがちょくちょく変わってたりするくらいです。
ではお待ちかね、ubuntu13.10の目玉新機能の紹介です。
smart scope
smart scopeとはダッシュから使える意味解釈型の Web 検索機能のことです。
たとえばダッシュで「Tokyo」って調べると下の写真のように東京の天気、位置、駅情報、wikipediaなどといろいろなツールで検索してくれます。
詳細画面は下のような感じになり、詳細をみることができます。
まとめ
全体としてあまり、よくなったな！と言う感じを受けないのが正直な意見です。smartScopeに関してはダッシュで検索出来るのは便利だなと思いましたが、たぶん使うことはあんまりないとおもいます。
APIとライブラリの違い
今回は前々からあいまいに理解していたAPIとライブラリの違いを説明していこうとおもいます。
言葉の定義とそれぞれのイメージ図
アプリケーション・プログラミング・インターフェース(Application Programming Interface)の略。OS(基本ソフト)やアプリケーションソフト、あるいはウェブアプリケーションが、自ら持つ機能の一部を外部のアプリケーション(ソフトやウェブサービス)から簡単に利用できるようにするインターフェース。ここで言うインターフェースとは、機能の呼び出し手順や記述方法などを定めた仕様を指す
ライブラリとは(IT用語辞典より)
らいぶらりとは、プログラム言語において、ある特定の機能を持つプログラムを定型化して、他のプログラムが引用できる状態にしたものを、複数集めてまとめたファイルのことである。
なんとなくわかったのですが、とりあえず、自分の理解を絵にしてみました。
上の図がライブラリのイメージ図で、下の図がAPIのイメージ図です。
まとめ
APIとライブラリはどちらも便利な機能を呼び出すという意味では同じです。
しかし、APIとライブラリはそれぞれ下のような特徴をもっています
この二つより
呼び出す機能が何に属しているかによってAPIかライブラリかの判別ができるのではないでしょうか。
