AndroidアプリでUNIX timeを取得

○手っ取り早いけど、厳密な処理には向いていないやり方

Androidアプリ中でUNIXtimeを取得しようとするとき、たいていのサイトで

long utc = System.currentTimeMillis();

と、書いてあります。

それでも確かに間違いないんですが……これは端末で設定されている時間をもとに取得しているので、ユーザーさんが端末の時間設定をいじっちゃうと正しい時間が取得できないわけです。

アプリでunixtimeを使うのは、課金システムやゲームのポイントで不正を防ぐときによく使うので、これだと非常にマズいです。

 

 

○じゃあどうするの?

WEB通信して取得してきましょう!

まずは、↓のURLにアクセスしてみてください。

※このURLを使用するときのお願い

http://web.gucci1208.com/api/unixtime.php

白紙のページにただ1行、unixtimeらしき文字列が表示されたと思います。

 

1

ぽつーん

 

このPHPページはすごく単純で、unixtimeをPHP関数で取得してecho表示しているだけです。

※このURLを使用するときのお願い

<!--?php
// 現在のUnixタイムが表示されます
$unix_time = time();

echo $unix_time;
?-->

このページにAndroidアプリ上からアクセスして、正しいunixtimeを取得してきます!

 

 

○AndroidアプリでWEBからUNIXTIME取得

やり方はとても簡単で、↓のメソッドを呼び出せば、unixtimeの文字列が返ってきます。

気を付けるのは、このメソッドをメインスレッドで呼び出すとandroid.os.networkonmainthreadexceptionで落ちちゃうので、そこだけ注意してください。

※このURLを使用するときのお願い

public static String ReturnResultPosta() {
	String result = "";

	HttpGet request = new HttpGet("http://web.gucci1208.com/api/unixtime.php");

	HttpResponse httpResponse = null;
	try {
		httpResponse = new DefaultHttpClient().execute(request);
	} catch (Exception e) {
		Log.d("HttpSampleActivity", "Error Execute:" + e);

		//ここに来ちゃったら正常にとれていないので
		return "";
	}

	int status = httpResponse.getStatusLine().getStatusCode();

	if (HttpStatus.SC_OK == status) {
		try {
			ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
			httpResponse.getEntity().writeTo(outputStream);
			result = outputStream.toString();
		} catch (Exception e) {
			Log.d("HttpSampleActivity", "Error");
		}
	} else {
		Log.d("HttpSampleActivity", "Status" + status);
	}
	return result;
}

これで(ほぼ)正しいunixtimeを取得できます!!

 

※このURLを使用するときのお願い)

このURLは誰でも使用できるように公開していますが、開発時のみ利用してください。

正式サービス開始時にはご自分のサーバーを使ってくださいね。

大量のアクセスは想定していないので……お願いしますm(__)m

それでもこのページが原因で高負荷がかかってしまうときは、URLを変更したり、ページを非公開にします。

Eclipseでレイアウトが表示されない

Eclipseでレイアウトxmlを組んでいるときに、Graphical Layoutが表示されないなんてことありませんか?

Graphical Layoutタブに切り替えても、

RenderPreView

内部エラーが発生しました。
After scene creation, #init() must be called

と表示されてしまって、一部の画面しか反映されない現象です。

1

こんな感じで。

これを修正するのは簡単で、APIのレベルを変更すればすぐに直ります!

右上の「Android version to use when rendering layouts in Eclipse」の項目をクリックして、19から18に落として、しばらくロード完了を待てば反映されます。そうすると、きちんと全ての画面にエミュレート結果が表示されるはずですよ!

3

右上をクリックして……

4

18にすると直る!

Amimoto AMI 網元『から』別のサーバーにwordpressを移転するとき2

さて、いよいよ新しいサーバーへコンテンツを映していきます。

その前に確認。

新しいサーバーでwordpressは起動していますか?

wordpressの管理画面まで遷移できる程度には構築を済ませておいてください。そのやり方についてはこの記事では解説しません。

wp-config.phpを新しいサーバーの環境に合わせる

前の記事の最後の方でオマケのようにちょろっと書いた、網元から落としてきたファイルを編集します。

新しいサーバーのwordpressを構築したときに、データベースを作成したと思います。まずは、そちらの設定を確認しましょう。

vi /var/www/html/XXX(wordpressを設置したディレクトリ名)/wp-config.php

そうすると、

~略~

// ** MySQL 設定 - この情報はホスティング先から入手してください。 ** //
/** WordPress のためのデータベース名 */
define('DB_NAME', '○○○');   ←おそらくインスタンスIDと一緒

/** MySQL データベースのユーザー名 */
define('DB_USER', '△△△');

/** MySQL データベースのパスワード */
define('DB_PASSWORD', '□□□');

/** MySQL のホスト名 */
define('DB_HOST', '◇◇◇');

/** データベースのテーブルを作成する際のデータベースの文字セット */
define('DB_CHARSET', 'utf8');

/** データベースの照合順序 (ほとんどの場合変更する必要はありません) */
define('DB_COLLATE', '');

~略~

網元の方のwp-config.phpとは、’DB_NAME’や’DB_USER’など、いくつかの項目の値が異なっているかと思います。
ここでは、落としてきた網元の方のwp-config.phpを編集して、新しいサーバーの設定に合わせましょう。

○wordpress全ファイルをアップロード

新しいサーバーに先ほど編集した網元のwordpress全ファイルをアップロードします。上書きしちゃって構いません。

○新データベースに旧データベースのデータを読み込ませる。

前回の記事で、網元データベースを全出力したdump.sqlを作成しました。

次は、そのdump.sqlを新データベースに読み込ませます。

新サーバーにphpMyAdminはインストールしていますか? その場合は、コンソールから一発でインポートできます。

インストールしていない場合も、そこまで難しくありません。

dump.sqlをサーバーにアップして、

$ mysql -u root ○○○(データベース名) &lt; dump.sql

を実行するだけです。

○お疲れ様でした!

これでwordpressのサーバー移行は完了です!

サーバー作業に慣れていない人にとっては抵抗感がある作業かもしれませんが、一度やりきると、二回目以降は驚くほどスムーズにできるようになっているものです。

それでは!

Amimoto AMI 網元『から』別のサーバーにwordpressを移転するとき1

とあるサイトを構築するのに、amazon web service EC2のインスタンスを借りて、網元を利用して作成していました。しかし、その後の調査でコスト比較するとvpsを借りた方がいいのではないか、と思うに至り、網元『から』vpsにwordpressサイトを丸ごと移動することになったのです。

この、”から“を強調するのは、『どこか別のサイトから網元へ』サーバー移行するやり方は、ググればいくらでも出てくるのですが、逆のパターンは全く見つからなかったためです。

作業が終わった今になって考えてみると、網元『から』だろうが、網元『へ』だろうが、wordpressのサーバー移行なんてやることはすごくシンプルで、手順さえ解ればスムーズに行くはずなのですが、サーバーに関する知識不足への不安や苦手意識を持っていた自分ではものすごく時間がかかってしまいました。

wordpressのサーバー移行に必要な作業は、結局のところ

・データベースの移行

・ファイルのコピー

のたった2つだけです。

問題は、網元がwordpressを簡単に始められるようにカスタマイズされすぎて、nginxの設定やインスタンスの全体像がつかみづらくなっていることです。

○データベースの移行

サーバー移行のためには、Wordpressのデータが保存されているデータベースをいったん全保存してローカルに落とさなくてはなりません。調べてみると、全保存する方法として、どの記事でも「phpMyAdminを使って……」と出てきます。

しかし、網元ではphpMyAdminはデフォルトで無効になっていて、それを有効にしようとするとまたごちゃごちゃとした作業をしなくてはなりません。(自分はここでいったんつまずいて、ものすごくハマッてしまいました。先輩のサーバーエンジニアさんに協力してもらいました)

参考:
AWS・網元でphpMyAdminを使う方法 – 技術部追い剥ぎペンギン
たった1分!AWS + 網元で phpMyadmin を使えるようにする方法
道はなくても進むのだ。: Amazon EC2 (Amazon Linux) での phpMyAdmin インストールと設定
Amazon EC2にphpMyAdminをインストールした後の作業メモ

上2つのリンクでは、網元にもとから入っているphpMyAdminを有効にする方法を
下2つのリンクでは、新規にインストールする方法を、解説しています。

結論から言うと、どれも全て上手くいきませんでした。結局、網元でphpMyAdminが表示されることは一度もなかったです。

nginxの設定や、ディレクトリ構成など、網元導入時に自動的に決められた部分が多く、解析するのも一苦労でした。

○phpMyAdminなんていらない!

ここで、最初の目的を考えてみると、「Wordpressサーバー移行をするため」に、「データベースの全データをローカルに落とす」でした。
よく考えると、別にphpMyAdminなんて必要なくて、ターミナルのコマンドでできちゃうのです。
phpMyAdminがあれば確かに解りやすく簡単にできるようになりますが、そのために時間がかかってしまっては本末転倒です。

○網元で使用していたデータベースの設定を確認する

まずは実際に網元で使用していたデータベースの名前やパスワードを調べます。
ターミナルでログインして、

vi /var/www/vhosts/○-○○○○○○○○(インスタンスID)/wp-config.php

とコマンドを打つと、

~略~

// ** MySQL 設定 - この情報はホスティング先から入手してください。 ** //
/** WordPress のためのデータベース名 */
define('DB_NAME', '○○○');   ←おそらくインスタンスIDと一緒

/** MySQL データベースのユーザー名 */
define('DB_USER', '△△△');

/** MySQL データベースのパスワード */
define('DB_PASSWORD', '□□□');

/** MySQL のホスト名 */
define('DB_HOST', '◇◇◇');

/** データベースのテーブルを作成する際のデータベースの文字セット */
define('DB_CHARSET', 'utf8');

/** データベースの照合順序 (ほとんどの場合変更する必要はありません) */
define('DB_COLLATE', '');

~略~

という感じの設定が確認できます。

○網元のデータベースを出力しダウンロード

ここで確認した情報をもとに、

mysqldump -u root ○○○(データベース名) > dump.sql

と打ち込むと、データベースの全データを出力することができます。
そして、出力されたdump.sqlファイルをローカルに落としてきてください。
これで網元のデータベースをバックアップすることができました。

○wordpressの全ファイルをダウンロード

これはそのまま

/var/www/vhosts/○-○○○○○○○○(インスタンスID)/

以下のファイルを全てダウンロードしてくるだけなので問題ないはずです。

以上で、Amazon EC2の方でやる作業は全て終了です。

その2に続きます。

『ロジカル・シンキング―論理的な思考と構成のスキル』 まとめと感想

『ロジカル・シンキング―論理的な思考と構成のスキル』照屋 華子(著), 岡田 恵子(著)

を読みました。

以下、まとめです。

このまとめは本を持っている前提のものです。


第一部 書いたり話したりする前に

人に何かを伝えるときには、必ず”課題(テーマ)”と”相手に期待する反応”を確認する

【第1章】相手に伝えるということ

1.受けてのことを気にするあまり、「にわか読心術師」になってないか?

2.相手に伝えるべきメッセージとは

・課題(テーマ)が明快であること :”課題”

・相手に期待する反応が明らかであること :”相手に期待する反応”

・その課題に対して必要な要素を満たしていること :”答え”

◆確認 -> 文書を書いているとき、会議の最中、常に”課題(テーマ)”を意識する

◆確認 -> 事前にプランを練って、目指すゴール地点(”期待する反応”)を引き出す

☆”期待する反応”とは?

(1)相手に理解してもらう

(2)意見や助言や判断などをフィードバックしてもらう

(3)行動してもらう

3.何を言えば”答え”になるのか

・課題に対してイエスかノーか、あるいはどのような意見があるか

・その結論の根拠に納得感があるか

・結論がアクションの場合、具体的なやり方が示されているか

4.なぜ相手に”答え”が伝わらないのか

◆確認->結論が伝わらないとき

落とし穴① 自分の言いたいことの要約になっている

落とし穴② 「状況によって」「場合によって」を使っている

◆確認->根拠が伝わらないとき

落とし穴① 「Aが必要だ、なぜならAがないからだ」となっている

落とし穴② 「それは事実か? それとも判断、仮設ですか?」と思わせている

落とし穴③ 「前提条件や判断基準」「言わずもがな」「当たり前」と思っている

◆確認->方法が伝わらないとき

落とし穴① 自社だけでなく他社でも通用するやり方、10年前でも10年後でも通用するやり方を提案している

落とし穴② 修飾語を使いすぎている

【第2章】説得力の無い”答え”に共通する欠陥

1.話の重複・漏れ・ずれ

2.話のとび

第ニ部 論理的に思考を整理する技術

・”MECE(ミッシー)”

・”So What? / Why So?”

【第3章】重複・漏れ・ずれを防ぐ”MECE”(マッキンゼー社で使われている)

“MECE”:「ある事柄を重なりなく、しかも漏れのない部分の集合体として捉えること」

->ある情報を全体集合として、部分集合に分けて考える

->”答え”の「全体」と、それがどのような「部分」から構成されているのか考える

MECEタイプ1

完全に要素分解できるタイプ

ex)年齢、性別、地域

MECEタイプ2

MECE切り口を持っているタイプ[知っていれば重複・漏れの心配がない]

ex)3C/4C、マーケティングの4P、組織の7S

MECEによるグルーピング

ちらばった情報をMECEな切り口によってグループ分けすることで理解しやすくする

重複・漏れ・ずれがないような切り口でないといけない

【第4章】話の飛びをなくす

“So What?” =>結局どういうことなのか?

“Why So?” =>なぜそう言えるのか?or具体的にはどういうことか?

[MECEによってグルーピングされたいくつか情報があり、A・B・Cという結論に達した]

□┓
□╋"So What?"┓
□┫ 			┣A
□╋"Why So?"	┛
□┛
□┓
□╋"So What?"┓
□┫			┣B
□╋"Why So?" ┛
□┛

□┓
□╋"So What?"┓
□┫			┣C
□╋"Why So?" ┛
□┛

[A・B・Cという情報から、Xという結論に達した]

A 	┓
	┣"So What?" ┓
B 	┫			┣X
	┣"Why So?"	┛
C 	┛

“So What?/Why So?” タイプ1:観察    提示した事実を全体集合として要約/結果を要素分解して検証

“So What?/Why So?” タイプ2:洞察    どのようなアクションをすべきか、などの仮説を立てる/どのような影響があるか、などの違う種類の情報を引き出す

第三部 論理的に構成する技術

“MECE”と”So What?/Why So?”を使って「部品」を「論理」に組み立てる

【第5章】「論理」とは?

結論と根拠、あるいは結論と方法が、結論を頂点に、縦方向には”So What?/Why So?”の関係で階層をなし、横方向には”MECE”に関係づけられたもの

○満たすべき3つの要件

要件1:結論が”課題(テーマ)”の”答え”になっている

要件2:縦方向に結論を頂点として、”So What?/Why So?”の関係が成り立つ

要件3:横方向に同一階層の要素が”MECE”な関係にある

○論理はコンパクトなほうが良い

◆確認    ->    縦方向にどこまで階層化するか    =>    相手がどこまで”Why So?”してくるか想定してレベルづけする

◆確認    ->    横方向にどこまで分解するか        =>    多くても4つか5つ。相手に解りやすく全体像を提示するのが目的だから

【第6章】論理パターンをマスターする

1.並列型

縦方向に”So What?/Why So?”の関係で階層化

横方向に”MECE”で複数の構造化

“MECE”のグルーピングによっては、結論が同じでも複数の階層を成すこともある

◆適用ケース -> 課題やテーマに対して十分な理解度や興味を期待できない相手に、全体像を説明したいとき

◆適用ケース -> 決定事項の連絡や確認など、結論に関して議論の余地がない内容を、全体像を説明したいとき

◆適用ケース -> 自分の思考や検討の広がりに、重複・漏れ・ずれがないことを強調して、相手を説得したいとき

2.解説型

縦方向に”So What?/Why So?”の関係で階層化

※横方向は常に「事実」「判断基準」「判断内容」の3つの要素で構造化

◆留意点 -> 「事実」が正しいこと(ここが主観的だと説得が難しくなる)

◆留意点 -> 「判断基準」が明示され、かつ妥当な内容であること

◆適用ケース -> 客観的な事実で共通認識を作り、自分の結論の妥当性を強調したいとき

◆適用ケース -> 自分の考えに、意見や助言をもらいたいとき

◆適用ケース -> 複数の代替案から、選択した代替案の妥当性を証明したいとき

【第7章】論理パターンを使いこなす

◆1つの課題に答えるとき -> 全体の論旨を解説型で組み、各論を並列型で組むという組み合わせ※(図7-1が間違っている?)

◆2つの課題に同時に答えるとき ->

(何をするべきか?)    (どう進めるか?)

・根拠並列型        +    方法並列型

・根拠解説型        +    方法並列型

・根拠並列型        +    方法解説型

・根拠解説型        +    方法解説型


感想としては、現状で最も役に立ちそうな内容は第一部かなと思いました。

あと、6章の解説型を覚えておこうかと。

エンジニアとして働いていて、他者との関わり合いで一番多いパターンが、「この機能を実現するために、どんな技術を利用して、どれくらい時間がかかるか」を説明するとき。

その場合、プログラミングの分野においては、「最も適した実装方法」という一種の”答え”が決まっていることがほとんどで、いかにその”答え”が妥当であるかを解説することになります。

当然、相手はプログラミングの知識を持っていないので、いかに解りやすく説明するか、いつも苦心しておりました。

今回の学びで、よりよいコミュニケーションをもてればいいなと考えています。

Top