default

Posted by & filed under 開発.


開発部 川野です。Sencha Touch 2 の Tips 第二弾ということで、今回は、Sencha Touch アプリの見た目をカスタマイズする方法について取り上げてみたいと思います。

Problem:

Solution:

Sencha Touch の SCSS ファイルに、カスタマイズ用の変数を追加してコンパイルすることで、オリジナルテーマの CSS を作ることができます。

今回は、Google+ 風な配色を意識したテーマをアプリに適用してみたいと思います。
作成した SCSS は以下。

// Overwrites global css variables.
$base-color: #000;
$active-color: #E3E3E3;
$page-bg-color: #fff;
$base-gradient: 'flat';
$font-family: 'sans-serif';
$button-radius: .2em;
$list-bg-color: #fff;
$list-color: #666;

// Include Sencha Touch's styles.
@import 'sencha-touch/default/all';
@include sencha-panel;
@include sencha-buttons;
@include sencha-sheet;
@include sencha-picker;
@include sencha-tabs;
@include sencha-toolbar;
@include sencha-toolbar-forms;
@include sencha-indexbar;
@include sencha-list;
@include sencha-layout;
@include sencha-carousel;
@include sencha-form;
@include sencha-msgbox;
@include sencha-loading-spinner;
@include pictos-iconmask('list');

// Define 'app' button colors.
@include sencha-button-ui('app', #D14836, 'flat');
.x-button-app .x-button-label { color: #fff; }

この SCSS から作った CSS を適用すると、以下のような見た目のアプリが、

それっぽい雰囲気を醸し出すアプリに変わります。

– サンプルページ
# WebKit系のブラウザ(Chrome, Safari)もしくはスマートフォンでのアクセスをお願いします _o_
http://recipe2.senchafy.com/

ツールバーの左にあるアイコンをタップすると、テーマのリストが出るので、そこで「G++」を選択すると、見た目が切り替わります。

Discussion:

Sencha Touch は、テーマを開発者がカスタマイズできるよう、上書き可能なグローバル変数をいくつか提供しています。

今回の例では、base-color、active-color、page-bg-color など、8つのグローバル変数を上書きしています。それぞれの変数の仕様については、開発用ドキュメントに説明があります。
http://docs.sencha.com/touch/2-0/#!/api/Global_CSS

SCSS ファイルの30行目では、「app」という名称のボタンテーマを作っています。これは、Sencha Touch が提供するミックスイン(※CSS の定義を作る関数のようなもの。詳しくは Sass の公式サイトなどでご確認下さい)を利用しています。ミックスインもグローバル変数と同じく、仕様は開発者ドキュメントに記載されています。

仕様を確認する必要はありますが、デフォルトの SCSS ファイルにたった数行追加するだけで、見た目を大きくカスタマイズできるのは、大変便利ですね!
とはいえ、痒いところに手が届くほどいろんなオプションがある訳ではないので、細かい調整は、別途、SCSS(もしくは CSS)を書いて補完することになります。

See Also:

– サンプルプログラム
# サンプルページのコード一式です
https://github.com/kawanoshinobu/sencha-touch-2-recipes/tree/master/recipe2

– Sencha の開発者によるテーマ作成の説明動画
http://vimeo.com/36917216


関連文書:

Posted by & filed under 開発.


トーキョーギークスタイル(TGS)を始めるので何か話して欲しいと頼まれました。コードリーディングについて話してきたのでセミナー資料の原稿を公開します。

実は過去に話したプレゼンを一部再利用しています。最近、上から目線キャラの川野さんに見られたら、ワンパターンと揶揄されそうです。気にしません。プレゼン資料を再利用できるのは年の功です。

もう一回TGSでセミナーをする予定です。From PoEAA To Play(Framework)の予定です。


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under 開発.


今年からPython3をちゃんと始めると決めていたのに、一ヶ月以上、何もしていないへたれです。去年のAdvent Calendarに参加しておきながら、このていたらくありません。と言うことで、これが日本人のPython3のコードです。

[もっと読む…]


関連文書:

recipe1

Posted by & filed under 開発.


開発部 川野です。

昨年10月にプレビュー版が公開された Sencha Touch 2 ですが、先週、ついにベータ版がリリースされました。ベータ版になって、仕様もだいたい固まったはず! ということで、これから定期的に、開発者向けのちょっとした Tips をポストしていこうと思います。

# 記事の形式は Python Cookbook にインスパイアされました :P

Problem:

Solution:

フレームワークが提供するルート機能を利用します:

Ext.define('recipe.controller.SampleController', {
  extend: 'Ext.app.Controller',
  config: {
    refs: {
      tabPanel : 'tabpanel'
    },
    control: {
      tabPanel: {
        activeitemchange: 'onActiveItemChange'
      }
    },
    routes: {
      // Regular expression "page/([% a-zA-Z0-9-\_\s,]+)" will be generated.
      'page/:season': 'onRoute',     
    }
  },

  onRoute: function (season) {
    var tabPanel = this.getTabPanel(),
        target = tabPanel.down('container[title=' + season + ']');
    tabPanel.setActiveItem(target);
  },

  onActiveItemChange: function (self, newItem) {
    window.location.hash = 'page/' + newItem.config.title;
  }
});

Discussion:

Sencha Touch の画面遷移は、別のドキュメントに移動する訳ではないので、URLが変更されません。そのため、WEBページを閲覧する時のようにブラウザの「戻る」ボタンを使うことができなくなっています。また同様の理由により、ブラウザをリロードした際、画面が初期状態に戻ってしまいます。そこで、実装側で何らかの対応を行ってあげる必要が出てきます。

ルート機能は、URL のハッシュフラグメントとコントローラのアクション(メソッド)をマッピングする機能です。ハッシュフラグメントは、 www.example.com/index.html#hogehoge の #hogehoge の部分ですね。この値が変更されると、ブラウザは hashchange イベントを発火します。Sencha Touch では、このイベントをキャプチャして、ハッシュフラグメントにマッチするコントローラのアクションを実行します。

上記の例では、コントローラクラスで行っている page/:season という定義から、page/([%a-zA-Z0-9-\_\s,]+) という正規表現を生成し、ハッシュフラグメントがこの正規表現にマッチする場合、onRoute アクションを実行します。例えば、#page/123 や #page/hogehoge などがマッチする対象のハッシュフラグメントになります。

「:」は特別な意味を持っていて、「:」をつけたトークンは、アクションのパラメータ値となります。サンプルでは、:season の位置にある値を onRoute アクションのパラメータとして受け渡して、対象ページを表示する処理に利用しています。

ルート機能を使うことで、ブラウザの「戻る」ボタン(&「進む」ボタン)、ページのリロード表示をエミュレートできる、という算段です。

See Also:

– サンプルページ
# WebKit系のブラウザ(Chrome, Safari)もしくはスマートフォンでのアクセスをお願いします _o_
http://recipe1.senchafy.com/#page/spring

– サンプルプログラム
https://github.com/kawanoshinobu/sencha-touch-2-recipes/tree/master/recipe1

– Sencha Touch 2 公式ドキュメント
# さらに詳しい情報が掲載されています
http://docs.sencha.com/touch/2-0/#!/guide/history_support


関連文書:

Posted by & filed under , 開発.


WEB+DB PRESS Vol.66の特集3が「クックパッド 開発ノウハウ大公開」でした。他社がどのようなソフトウェア開発プロセスを確立あるいは試行しているのか、どんな開発者文化を醸成しているのかに関心があるので、興味深く読みました。読んだ感想は、クックパッドは良い開発者文化を醸成しているようで素晴らしい、です。なんと言うか、利用者視点の文化が醸成されているようです。

もちろん書かれたものと真実が一致していると信じるほどウブではありません。かつて、アリエルも開発プロセス(主に品質管理)の記事を書いたことがあります。もし社内の人がこれを読んだら、こんな良いことばかりでもないだろうと思うかもしれません。ぼくもそう思います。

そもそも世の中にあふれる「言語化して語られる開発プロセス」と「開発現場の現実」にはギャップがあります。現場の本当の根深い問題の多くは語られません。

開発プロセスの良い面あるいは悪い面でも解決できた話は、広く大勢に敷衍するので語ることができます。一方、解決不能な悪い話は特定の少数個人に依存する傾向があるため語りにくい話になります。少なくとも雑誌記事で特定個人を名指しした批判は普通できません。たとえ個人を特定できないとしても、特定個人の事例を書いて何か意味があるのかと自問すると、意味なしと結論づけざるをえません。こうして現実と記事にはギャップが生まれます。そして皮肉なことに、解決できない特定個人の問題こそが現場で本当に根深い問題であったりします。

そんな深読みはさておき、森本さんがアリエルの開発プロセスについて記事を書いてくれました。ぼくが書くより客観的な記事になっていると思います。少し褒めすぎかと思いますが、言語化して語られる開発プロセスとはそういうものなのです。

「その資料、公開しても良いです。公開するしないの判断は任せます」が謎コメント扱いされたので真意を補足します。普通、この手の社内について語る資料はデフォルトで社外秘になりがちです。このため、まず社外秘のラベルを外す意思表示をしました。とは言え、他人が作ったものを公開しろと強制するのは変な話です。著作物をどうするかは著作者が決めることで他人がとやかく指図するものではないからです。このため、資料を公開するか否かに意見を差し挟みません、という意思表示をしました。自分の中では筋が通っているつもりですが、発話すると謎コメントになったようです。伝えるのは難しいものです。


関連文書:

  • 関連文書は見つからんがな

boogie

Posted by & filed under いろいろ.


少し前から会社でT丸さんがこれみよがしにブギーボードを使い始めました。ちらちらとみんなに見せつけます。良いモノだとは決して言いません。ただ黙って見せつけるだけです。そんなに良いモノなら少し使わせてください、と頭を下げる羽目になりました。

そして数日使っています。

書き心地はなかなかのものです。しかし不満もあります。画面が狭い点です。何かメモを書いていると、もっと書くスペースが欲しくなります。最新のブギーボードはデータ保存機能があるようですが、T丸さんのブギーボードは旧式なので保存機能はありません。書いて消す、これだけの機能です。書くスペースがなくなると消すしかありません。一時的にページを取っておきたくても手段がありません。永続的な保存機能を欲しいとは思いませんが(一時的な書き物と割り切っているので必要は感じません)、数ページ分の書きスペースを欲しいと思った時の手段がないのは辛い部分です。

結論として、利便性は紙とペンに軍配が上がります。それでも、ちょっとしたミーティングの時には使えそうです。紙とペンよりやる気がありそうに見えるからです(たぶん)。

ブギーボードの一番のユースケースは、使っているのを見せつける使い方です。そう、T丸さんは意地が悪くて見せつけていたのではなく、ブギーボードのもっとも正しい使い方をしていたのでした。


関連文書:

  • 関連文書は見つからんがな

cppbook

Posted by & filed under .


ストラウストラップのプログラミング入門を読みました。

C++作者のストラウストラップ先生(以下、先生)の書いた本です。分厚いです。写真を撮るとこんな感じです。HTCのアンドロイド端末と同じぐらいの幅です。

先生の書いた本なので是非読むべきです、と言いたいところですが、この分厚さを万人には勧められません。人生の優先順位は各自それぞれだからです。全部を読めない人のために、優先的に読むべき箇所を決めるために各章の個人的主観を書きます。

用語集

本の巻末1093ページから始まる用語集は立ち読みでも読む価値があります。8ページなのですぐに読めます。一例を抜粋します。

  • 型: オブジェクトにおいて有効な値および演算を定義するもの
  • 値: 型に基づいて解釈されるメモリ内のビットの集合
  • 演算: 関数や演算子など、何らかのアクションを実行できるもの
  • 関数: プログラムの別の場所から呼び出せる名前付きのコードの単位。計算の論理的な単位

人によっては上記を読んで、(特に関数の説明に)C++固有で意味を限定しすぎていると感じる人もいるかもしれません。しかし、こういう基本的な用語を(異論はあれど)きちんと定義してくれる本は意外にありません。その点で貴重です。かつ先生の定義なので、困った時に使えます。

Javaのジェネリック型は知っていても、「ジェネリックプログラミングとは?」と聞かれて答えられない人は、本屋に行って用語集だけでも立ち読みするとよいでしょう。ちなみに用語集の中で一番面白いのは「パラダイム」の説明です。どんな説明かは読んでのお楽しみです。

第0章

短いですし読む価値があります。心に残る一言を抜粋します。

たとえば、プログラムでミスを犯すのがいかに簡単で、それらを修正するのがいかに難しいかを学ぶまでは、ソフトウェア開発手法の真価を見きわめることはできない。

第1章

あまりにどうでもいい一般論なので読まなくてもいいでしょう。一言でまとめると、ソフトウェア開発は現代社会で重要です。

第2章

Hello, World!のタイトルの章です。自分には不要でした。C++のコードを見たことのない人には意味があるかもしれませんが、その人にとって本書が意味があるか不明です。

第3章

「オブジェクト、型、値」のタイトルです。同じような話をパーフェクトJavaで書きました。パーフェクトJavaを執筆前に本書を読んでいなくて良かったです(もし先に読んでしまっていたら、パクリみたいに思えて却って書きづらかったからです)。

第4章

前章に引き続き、C++の基本的な言語機能の説明が続きます。C++の構文を知らない人や忘れている人は読むと良いでしょう。

第5章

エラー処理の話です。

第6章

第7章

時間のない人に、本書の中で読むべき章を選べと言われたら、第6章を挙げます。第7章は内容的に続きなので興味があれば読み進めるとよいでしょう。構文解析(パーサ)の説明です。if文やwhile文など言語の基本構文の説明の次がいきなり構文解析です。先生にとっては普通の展開なのでしょう。

この章を勧める理由は、内容が難しいからあるいは高度だからではありません。とても説明が平易だからです。電卓プログラム(ありがちですが)を題材にして、何度も間違いコードを出しながら少しずつ正解に導きます。一例を挙げると以下の文法に対して

次のようなコード例を挙げます。

このコードにはバグがあり、ここから更に2回書き直しをします。コードを見て、すぐに間違いに気づく人に本書は不要です。どこに間違いがあるか見当もつかないなら、本書第5章から3章分を読む価値があります。

第8章

再び、C++の基本に説明が戻ります。変数や関数などの説明です。参照の話など、この章もパーフェクトJavaと説明が被ります。つくづく執筆前に読まなくて良かったと思います。

プログラミング初学者であれば読んで損はありません。経験者には自明の話が続くかもしれません。

第9章

クラスの話です。C++を使う予定のない人でも、教養としてC++のクラスの言語機能は知っておいたほうがよいでしょう。本章から心に残る一言を抜粋します。

さらに調べているうちに、複雑すぎるために前の単純な解決策よりも悪いものを思い付いてしまう、ということになるかもしれない。これは最善は善の敵(ボルテール)の1つの真意である。

第10章

第11章

ファイル操作まわりの説明です。C++をきちんと勉強したい人は読むべきです。教養としてC++を学んでいる人は必要になるまで読まなくてもいいでしょう。

第12章

第13章

第14章

第15章

第16章

5章を割いてGUIプログラミングの説明です。しかもマイナーなFLTKです。

ぼく自身は世代的にX Window Systemのプログラミングもやりましたし、Windowsプログラミングもしました。GUIプログラミングの経験が自分のプログラミングの学習の助けになったことは否定しません。しかし、今プログラミングの勉強を始めた人にGUIプログラミングを勧める気はなるかと問われると迷います。とは言え、Webアプリのプログラミングしか知らないと大事な何かを欠いたままではないかという懸念があるのも事実です。どうなんでしょう。よく分かりません。でもFLTKはないよな、と思います。せめてAndroidプログラミングだろうと思います。

第14章に仮想関数の内部実装のvtblの話がこそっと差し挟まれます。vtblという単語を聞いたことのない人には、ポリモーフィズムの仕組みを知る上で読むと面白いかもしれません。

第17章

第18章

ポインタと参照の話です。K&R2を読んでいる気分になるほど原理原則の話です。この章の内容を理解しているJavaプログラマと、していないJavaプログラマでは、同じJavaプログラマと呼ばれていても別次元の存在です。

第19章

テンプレートとジェネリックプログラミングの話です。たとえJavaのジェネリック型しか使わない人でも、C++のテンプレートを知っておいて損はありません。

第20章

第21章

前章の続きですが、STLの各論に入ります。自分の好きなプログラミング言語のコレクション型と比較しながら読むと興味深いと思います。各論なので、必要になった時にリファレンス的に読むのでもいいと思います。

第22章

趣が変わりプログラミング言語の歴史を語る章になります。有名人の写真を眺めるために読みます。アタック25の最後で「この人物の名は?」「Alexander Stepanov」「その通り!」のやりとりをいつかするために読む必要があります。

第23章

テキスト処理と題して正規表現の説明などがあります。正規表現は大事ですが、C++本で読む必要は感じません。

第24章

数値の章です。配列、行列、複素数などです。必要な人は読むと良いでしょう。

第25章

「組み込みシステムプログラミング」と題して、雑多な話題が散りばめられています。

C++でコレクションを共変にできる話題がさらっと触れられています。共変にできるというのは、Array_refを不変のArray_refとして扱えるという意味です(CircleがShapeを継承している場合の話です。ここでの「不変」はinvariantの意味ではなくimmutableの意味です)。Javaで言えばListオブジェクトをList型の変数に代入できるか否かの話です。Javaではできませんし、C++でも普通はできません。C++で細工をすれば共変にできる話です。難しくて使う気になれませんが。

第26章

ソフトウェアテストの話です。C++本に必要なのかと思いたくなりますがそれを口に出してはいけません。

第27章

最後にC言語の話です。落ち着きます。Cは単純で美しい。一番好きです。ごめんなさいストラウストラップ先生、C++より好きです。


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under 開発.


ちまちま作っていたwebsocketのpythonのクライアントライブラリをアップデートしました。バージョンは0.5ですね。以前サポートしてたプロトコルのバージョンは、echo.websocket.orgで使えなくなってしまっていたので、古いプロトコルのコードはごっそり消しました。今回はRFC6455になったhybi13だけをサポートしています。いや、サポートしているつもり。

[続きを読む…]


関連文書:

Posted by & filed under 開発.


自信のないタイトルは1年前に「2011年には流石にリリースされると思います」と書いてしまった反省からです。

リリースに関わっているわけでもないのに根拠のない予言をするものではありません。更にさかのぼること3年前には、Apache2.4カウントダウン?のタイトルで記事を書いています。もはや狼少年状態です。

Apache2.4の新機能の中で意外にフィーチャーされていませんが、個人的な注目はevent MPM(とAsynchronous support)です。いわゆる非同期I/O動作のイベントドリブンなmpmです。非同期I/Oのイベントドリブンと聞くと、nginxと同じ動作?と思う人もいるかもしれませんが、動作モデルは異なります。

Apacheを知っている人は、event mpmがバージョン2.2から存在するのを知っているかもしれません。バージョン2.2では実験的(experimental)mpmでしたが、バージョン2.4でexperimentalが取れました。それどころかUnix系ではデフォルトmpmになりました(経緯としては、一度、simpleと呼ばれる類似の非同期I/Oベースのmpmが作成されデフォルトになって、その後、event mpmに集約されました)。

event mpmの前提知識として、v2.2のデフォルトのworker mpmの動作を知っておいたほうが良いのですが、その辺は3年前の記事を参考にしてください。この記事のsimple mpmの説明の大枠はevent mpmにも当てはまります。

event mpmはマルチプロセスにもできますが、まずは単一プロセスの前提で説明します。

event mpmには単一のリスナスレッドと複数のワーカースレッドが存在します。リスナスレッドのエントリポイントはlistener_thread()です。listener_thread()はネットワーク待ちのイベントループです。イベントループはapr_pollset_poll()でブロックします(タイマーありのブロック)。apr_pollset_poll()はOSに応じてepoll_wait(2)やpoll(2)やselect(2)の呼び出しにつながります。

このapr_pollset_poll()で、accept(2)待ちのソケット(いわゆるlistenソケット)とaccept(2)が返したソケット(いわゆるconnectionソケット。以下接続ソケット)の両方を監視します。コードの骨格は次になります。

クライアントから接続を受け付けると、listenソケットに対してaccept(2)処理をします。accept(2)が返した接続ソケットをapr_pollset_poll()の監視対象にします。クライアントからHTTPリクエストが飛んでくると、この接続ソケットがreadableとしてapr_pollset_poll()から返ります。最初のステートはCONN_STATE_CHECK_REQUEST_LINE_READABLEなので、リクエスト行の読み込みをします(上記コード抜粋を参照)。リクエスト行読み込みの処理など、実際のHTTP処理はリスナスレッドではなくワーカースレッドが行います。リスナスレッドは読み込み可能になった接続ソケットを内部的なキューに入れるだけで実処理はしません。

ワーカースレッドのエントリポイントはworker_thread()です。コードの骨格は次のように単純です。キューにソケットが突っ込まれるまでブロックします。言うまでもありませんが、ブロック中にCPUは消費しません。

process_socket()はソケットのステートに応じたHTTP処理をします。細かい部分を無視すれば、リクエスト行の読み込み、リクエストヘッダの読み込み、リクエストボディの読み込み、レスポンス出力の4段階のステート遷移です。HTTP接続がkeep-aliveであれば、レスポンス出力後に次のリクエスト行読み込みにステート遷移します。

worker mpmの場合、このステート遷移の間、ワーカースレッドがひとつのHTTP処理、つまりひとつのクライアントに占有されます。event mpmの場合、ワーカースレッドは占有されないので、複数のHTTP接続を並行的に処理できます。

こうなるとHTTP処理中のソケット読み書きがブロッキングかノンブロッキングかが気になります。答えを書くと、リクエスト行の読み込みとレスポンス書き出しはノンブロッキング、リクエストヘッダとリクエストボディの読み込みはブロッキングです。つまり、クライアントが遅かったり(これはあまりない)、ネットワークが遅かったり(これはありそう)、悪意的に小さなバイト列を散発的に送りつけるリクエストがあると、ワーカースレッドがリクエストの読み込みでブロックする可能性があります。要はワーカースレッドが占有されます。これが問題になる場合はRequestReadTimeoutディレクティブのタイムアウトを短くするのが防衛策になります。

Apacheが非同期I/Oベースになると、nginxとの性能比較が気になります。個人的見解ですがApacheがnginx同等のスループット性能には達しないだろうと思っています。誰かがベンチマーク比較していないか探しましたが見つかりませんでした。Apache2.2時の比較でボロ負け結果は見つかりますが。

比較のためにnginxの動作を簡単に説明すると、単一スレッドがリスナとワーカーの役割を兼ねて、かつすべてのソケット読み書き処理がノンブロッキングになるアーキテクチャです(acceptすらaccpet4でノンブロッキングにする徹底さです。accept可能になったソケットがブロックしうるのかは知りませんが)。こういう言い方はUnixはLinuxみたいなものですと言うみたいで一部の人を不快にさせそうですが、要はNode.jsと同じアーキテクチャです。

event mpmのApacheはworker mpmより平行性が上がったとは言え、依然としてワーカースレッドの数が平行性の制約であることに変わりありません。ワーカースレッドの数を増やすには次のふたつの方法があります。

  • プロセス当たりのワーカースレッドを増やす
  • プロセスを増やす

プロセス当たりのワーカースレッドの数は32bit OSではメモリの制約で通常1000のオーダーです(OSにも依ります。Linuxのデフォルトはスレッドひとつに仮想メモリ2Mバイト割り当てるのでスレッド数1000のオーダーでプロセスの仮想メモリが2Gバイトのオーダーになります)。64bit OSであればこの辺の制約が外れるので、スレッド数のオーダーを上げられます。スレッド数のオーダーを上げた時はスレッド間のタスク切り替えのコストが課題になります。この課題は10年前ぐらいから言われていて、その後、カーネル側の改良のニュースなども時々聞いた記憶もあるので(最近の動向はウォッチしていません)、もしかした1万スレッドぐらい余裕な世界になっているかもしれません。

後者のプロセスを増やすのはApache的には保守的な手段です。一見、問題ないようですが、複数プロセスが同じポートのソケットに一斉にaccept(2)かけた時の性能問題を昔(いつだったか思い出せないぐらい大昔)見た記憶があります。こちらも凄腕のカーネルハッカーたちが解決済みの問題かもしれません。

他のApache2.4の新機能の解説は気が向いたらやります。


関連文書:

  • 関連文書は見つからんがな