読者です 読者をやめる 読者になる 読者になる

開発時かリリース時か判別する

Android

アプリ情報が格納されているクラスを利用して、デバッグかどうか(リリースかどうか)を判別する。


クラスApplicationInfoの中に、アプリの利用状況に応じて値が変動する、変数flagsというものがあるので、

  /**
     * Flags associated with the application.  Any combination of
     * {@link #FLAG_SYSTEM}, {@link #FLAG_DEBUGGABLE}, {@link #FLAG_HAS_CODE},
     * {@link #FLAG_PERSISTENT}, {@link #FLAG_FACTORY_TEST}, and
     * {@link #FLAG_ALLOW_TASK_REPARENTING}
     * {@link #FLAG_ALLOW_CLEAR_USER_DATA}, {@link #FLAG_UPDATED_SYSTEM_APP},
     * {@link #FLAG_TEST_ONLY}, {@link #FLAG_SUPPORTS_SMALL_SCREENS},
     * {@link #FLAG_SUPPORTS_NORMAL_SCREENS},
     * {@link #FLAG_SUPPORTS_LARGE_SCREENS}, {@link #FLAG_SUPPORTS_XLARGE_SCREENS},
     * {@link #FLAG_RESIZEABLE_FOR_SCREENS},
     * {@link #FLAG_SUPPORTS_SCREEN_DENSITIES}, {@link #FLAG_VM_SAFE_MODE},
     * {@link #FLAG_INSTALLED}, {@link #FLAG_IS_GAME}.
     */
    public int flags = 0;
    ・・・
    /**
     * Value for {@link #flags}: set to true if this application would like to
     * allow debugging of its
     * code, even when installed on a non-development system.  Comes
     * from {@link android.R.styleable#AndroidManifestApplication_debuggable
     * android:debuggable} of the <application> tag.
     */
    public static final int FLAG_DEBUGGABLE = 1<<1;



こんな感じで、開発用とリリース用で処理を振り分けることができる

Context appCon = getApplicationContext();
PackageManager pm = appCon.getPackageManager();
ApplicationInfo info = pm.getApplicationInfo(appCon.getPackageName(), PackageManager.GET_META_DATA);

if ((info.flags & ApplicationInfo.FLAG_DEBUGGABLE) == ApplicationInfo.FLAG_DEBUGGABLE) {
	// 開発時(デバッグモード)
}
else {
	// リリース時
}



参考
https://developer.android.com/reference/android/content/pm/PackageManager.html
http://mousouprogrammer.blogspot.jp/2012/12/androidapplication.html
http://d.hatena.ne.jp/yu4u/20140629/1404057778
http://hascha.blogspot.jp/2012/04/google-play.html

申請までの流れ

Android

古いAndroidアプリ(Eclipseで作成とか)をバージョンアップして申請する際の流れを。

0. GooglePlayDeveloperへの登録

省略

1. 「AndroidManifest.xml」の修正

android:versionCode」「android:versionName」の値を更新する。
外部ツールの認証を開発用とリリース用で分けているのであれば、リリース用のAPIキーに差し替える(GoogleMapsAPIのキーとか)。
そもそも、プログラム側で判断する仕組みをつくっておけという話ではある。

2. apkファイルの作成及び動作確認

apkファイルとは、Androidアプリのプログラム、設定、画像、開発者の署名などが入ったファイルのことです。これがあれば、Androidでアプリを実行することができます。



(apkファイルは作成済みという体で)該当プロジェクトを右クリック[Androidツール][署名アプリケーション・パッケージのエクスポート]を選択する。
表示されるウィンドウにしたがって、Keystore(デジタル署名)のパスとかパスワードとかエイリアスを設定する(同じ内容の署名で作成したapkファイルでないとアップロードできないため、Keystoreとかパスワード等の管理は適切に行う)。
最後に、apkファイルの出力先を指定する(出力先のパスに日本語が含まれているとエラーが出るので)。
実機をPCに接続してADT側に認識されていることを確認したら(該当アプリインストール済み)、apkファイルの出力先でコマンドプロンプトを立ち上げ、「adb install -r ~.apk」を実行する。
実機にapkファイルが読み込まれ、アプリが起動したら動作確認を行う。

3. アプリの申請

GooglePlayDeveloperにて該当アプリの設定画面を開き、アプリの説明(概要、キャプチャ等)、価格と販売/配布地域を更新したうえで、apkファイルをアップロードする。

smarty(FuelPHP)でphpタグを利用する

php js

やりたいこと
http://doop-web.com/blog/archives/1182


クラスView_Smarty(fuel/packages/parser/classes/view/smarty.php)のメソッドparserの下記1行

<?phpclass View_Smarty extends \View
{public static function parser()
   {static::$_parser = new Smarty(); // !!!

を下記2行に置き換える

<?phpstatic::$_parser = new \SmartyBC();
   static::$_parser->php_handling = \Smarty::PHP_ALLOW;



これで、smartyファイルの中でphpタグが使える

<script type="text/javascript" src="/assets/js/app/sample.js?date={php} echo date('YmdHis', filemtime('./assets/js/app/sample.js')); {/php}"></script>



参考
http://qiita.com/kobake@github/items/f4205eec641336a571af

スクロール追尾の何かしらをつくる

js

やりたいこととしては、スクロール追尾ボタンをつくりたい


そこで...sticky
https://github.com/garand/sticky

When the target element is about to be hidden, the plugin will add the class className to it (and to a wrapper added as its parent), set it to position: fixed and calculate its new top, based on the element's height, the page height and the topSpacing and bottomSpacing options.



結果、こんな感じで

<script src="/assets/plugins/jquery/jquery.min.js"></script>
<script src="/assets/plugins/garand-sticky/jquery.sticky.js"></script>
<a href="javascript:void(0)" id="sticky_button">ボタン</a>
$(document).ready(function() {
	$("#sticky_button").sticky({ 
		zIndex: 1000, // 重なってしまわぬよう 
		center: true
	});
});



ちなみにボタンはcss
CSSだけで作るアイコン付きボタンの作り方 : アシアルブログ

少し修正して利用
例えば、以下の機能はブラウザによって利用できないので...

background-image: -webkit-linear-gradient(top, #FC0, #F60);

こうするとか

background: linear-gradient(#1D62F0, #05FBFF);



こんなものもあるのか...
CSSのposition:stickyがすごく便利 | q-Az

FuelでAjaxを使う

php js

Ajaxでリクエストを投げて、FuelPHPのコントローラで処理する。

フロント

var res_json = $.ajax({
	type          : 'post',
	url           : '/result/fetch.json',
	data          : JSON.stringify(post_data), // POSTするJSONデータ
	contentType   : 'application/json',
	dataType      : 'json',
	processData   : false,
	async         : false,
	cache         : false,
	scriptCharset : 'utf-8',
	// 成功
	success: function(json_data) {
		return json_data;
	},
	// 失敗
	error: function() {
	},
	// 完了時
	complete: function() {
	}
}).responseText;

var res_obj = $.parseJSON(res_json);
var result = res_obj.result;


戻り値を利用する場合は、$.ajax()の返り値であるXMLHttpRequestオブジェクトを変換する。
responseTextメソッドで文字列にして、$.parseJSONでパースする運びとなる。

Ajaxについては下記を確認
http://semooh.jp/jquery/api/ajax/jQuery.ajax/options/

サーバ

<?php

/**
 * WebAPIとして機能する
 *
 */
class Controller_Result extends Controller_Rest
{
   /**
    * /result/fetch.json
    *
    */
    public function post_fetch()
    {
        $res = self::fetch_response();

        return $this->response($res, 200);
    }

    private static function fetch_response()
    {
	// レスポンスを取得するための何かしら
	Input::json();
	...
    }
}


JSONXMLなどの形式でデータを返したい場合は、RestControllerを使う。
fuel/app/classes/controllerディレクトリ内にクラスを作成し、Controller_Rest クラスを継承する。

リクエストURLの末尾によって、コントローラが返すデータが自動整形される。
例えば、/result/fetch.jsonの場合はJSONデータが返される。

RestControllerについては下記を確認
http://atmarkplant-dj.blogspot.jp/2012/10/fuel-php-ajax.html
http://blog.a-way-out.net/blog/2015/03/24/jquery-post-json-fuelphp/
http://qiita.com/kotarella1110/items/1c6c35d71c9175b0d264#rest-%E3%82%B3%E3%83%B3%E3%83%88%E3%83%AD%E3%83%BC%E3%83%A9%E3%81%A8%E3%81%AF

パイプで並列処理

Linux

はじめに

Software Design 2012年8月号」の「開眼シェルスクリプト」の焼き直し。
Webにあるので一読することを勧める。
https://blog.ueda.asia/?page_id=4520

パイプにつなげたコマンドは...

並列稼働する(複数のCPUをなるたけ休まず働かせようとする
複数のCPUが、パイプで連結された各コマンドの動作/停止を高速に切り替えることで、
加工データをバケツリレー形式で前から後ろへ送っていく。

並列化されていることは、以下のようにして確認できる。

● timeコマンドの結果、「user > real」となっている(1個のCPUでは「実際に掛かった待ち時間」よりもCPU時間の方が長くなることはない、
基本的に「user + sys = real」
※正確な処理時間を測る場合は、繰り返し計測を行い、統計情報(平均値とばらつきの傾向等)を求める必要がある

● topコマンドの結果、対象コマンド(パイプより連結された複数のコマンド)のCPU使用率が100%を超えている
(例えば、計150%であれば、1.5個分のCPUを使用しているといえる

ちなみに、より多くのコマンドをつないでも、パフォーマンスは落ちるどころか、むしろ改善する(CPUが多いほど顕著
CPUの数に応じて効果の度合いは変動するものの、コマンドを細かく分割するほうが、時間当たりの処理量が増える。

並列化の限界

パイプでつながれたコマンドが、各CPUを休まず働かせることができるのは、データが滞りなく流れている時のみ。
言い換えると、次の2つの状況は...
● パイプ前のコマンドがデータを送ってこない場合
● パイプ後のコマンドがデータの受け取りに手間取っている場合

事例として次のようなものが挙げられる。

● 負荷にばらつきがある場合、一番負荷の高いコマンドの処理時間以上に処理が早く終わることはない
例えば、grepの検索結果をawkで処理する(grepの処理するデータ量がawkの処理するデータ量よりも多い)場合、
grep側の処理が終わるのを待つ必要がある。
ただ、1個のCPUであっても、細かい時間間隔で各コマンドの動作/停止が切り替わることに変わりはないため、
処理を分割しパイプにつなげることで、負荷の高いコマンドの終了を待っている間にCPUを効率的に使うことはできる

● データをブロックするコマンドがある場合、そのコマンドがボトルネックになる
例えば、sortコマンドは全データを読み込まないと結果を出力できないため、
sortコマンドをパイプでつなげた場合、sortが終わるまで後続の処理は実行されない
対応としては、sortコマンドの位置をできるだけ後ろに回す、またはsortコマンドの処理するデータ量を減らすことで処理効率を上げる

日々をやっていくということ

エッセイ

日々をやっていくこと以上に重要なことが見つからない。

何処まで行っても、そこには日々がある。
何者になっても、それは日々と共にある。
例えば、理想としている状態があったとして、現時点から見えるのはある最適化された瞬間だけであって、
その背後に待ち構えている日々を見通すことは難しい、というかできない。
道を知っていることと、その道を歩くことは異なる。

生物的な恒常機能やルサンチマン的な論理を盾に、現状維持に固執しろということではない。
変化を受け入れないということは、先細り途絶える道を選択したことを意味する。

ただ、一喜一憂に振り回されたり、歪んた熱意に突き動かされて物事に取り組むことのツケに無意識でいることは、あまりに無防備であると思う。
見えない敵と戦って疲弊し、疲弊することでさらに敵を増やして...不毛過ぎて笑えない。

ではどうするべきなのか。

取っ掛りとして行うべきは、変化することを良しとしたうえで、長期的かつ多角的に物事を捉えようとする姿勢が何より大切だと認識することだと思う。
ここで大切なのは、あらゆる出来事に高尚な意味付けをすることではなくて、その姿勢自体が持つ価値を理解すること。

前に、「物事は絶対的ではなく相対的に捉えることが大切」と書いたけど、それはただの言葉であって、その意味を定期的に確認することが大切なのかなと。

継続していくために楽しくやっていく努力。
物事をより良く捉えられる状態でいるための工夫。

少しずつ広がりを見せていくイメージを常として、奥深くに根付いている間違いを抜いていく。