RailsやらAndroidやら不穏な話を最近してましたが、久々にアプリ公開しました
ごくごくシンプルなチャットアプリ A Simple Table Talk
です。
特徴はとにかくシンプルな事?文字だけのチャットです。
他?
・・・考えときます。
2012年12月23日日曜日
2012年12月17日月曜日
AndroidでSingletonパターンをやりたい
謎の何か。
さて、下記の記事、android開発では基本らしいのですが知らない人はびっくりするんじゃないでしょうか?
http://mobileapplication.blog.fc2.com/blog-entry-2.html
http://mobileapplication.blog.fc2.com/blog-entry-3.html
端的に言うとAndroidではメモリ不足等の場合に、生存中のActivityのメンバ変数が勝手に開放される場合がある、って事ですね。
自分も知らなかったのですが…
Androidアプリを開発したての頃に頻発してた原因不明の例外はこれだったみたいです。
でもまあ、良く見りゃちゃんとDeveloper's Guideにも載ってます。
http://developer.android.com/guide/components/activities.html#SavingActivityState
読んでねぇ。
もちろんそこまで読んでねぇ。
最初に言って欲しいわそれは。
そもそも普通にソフト勉強してくと「変数は値が保証される」って半ば無意識に前提にしちゃうと思うんですが、正直その前提というか価値観が崩れる衝撃でした。おおげさ?
しかしメンバ変数についてはユーザーにコールバックという形で通知が来るので百歩譲って良しとしましょう。(その対応として分かりきった手続きを毎回アプリ設計者に実装させる意図はよく分かりませんが・・・)
しかしstaticに至ってはいつ消去されるかすら分からない模様。
ざ、斬新すぎじゃよ?
これの意味する所は、AndroidアプリでSingletonパターンは使えないって事ですよねそうですよね違いますかね?
Androidアプリでは、オブジェクトの生存を保証するものはActivity、という事だと言えそうです。つまり設計上Sigletonなインスタンスが存在するのであれば、それは常にrunningなActivityから参照されている(かつ適切にonSaveInstanceState()/onRestoreInstanceState()されている)必要があるわけです。
もはやSingleton"パターン"ではないですね…
なお、詳細はDeveloper's Guideを見てもらうのが良いのですが、メンバ変数の退避はBundleインスタンスに対して保存する形を取っています。つまり、基本型(intとか配列とか。Stringも基本みたいなもので)か、ParcelableもしくはSerializableなクラスでないといけません。好き勝手にオリジナリティー溢れるクラスやら作りまくってActivityにぶらさげまくってると破綻するって事になるので注意した方が良いですね。
2012年11月20日火曜日
AndroidでJSON取得
取得できるものがJSON ArrayなのかJSONなのか分かった上で切り替えれば良いのですが、一つの内部関数なんかで処理しちゃいたい場合事ありますよね?(強引)
その場合、下記のような関数を使う事で
Arrayだった場合 : そのままJSONArrayとして取得
Objectだった場合 : 要素として一つだけJSONObjectが含まれたJSONArray
それ以外 : 要素0のJSONArray
として一括でArrayとして扱えます。
その場合、下記のような関数を使う事で
Arrayだった場合 : そのままJSONArrayとして取得
Objectだった場合 : 要素として一つだけJSONObjectが含まれたJSONArray
それ以外 : 要素0のJSONArray
として一括でArrayとして扱えます。
private JSONArray convertJSONArray(String jsonString) {
JSONArray ret=null;
try {
ret = new JSONArray(jsonString);
Log.d(TAG, "convertJSONArray : Array");
Log.d(TAG, "convertJSONArray : ret = "+ ret.toString());
return ret;
} catch (JSONException e) {
ret = new JSONArray();
try {
JSONObject json = new JSONObject(jsonString);
ret.put(json);
Log.d(TAG, "convertJSONArray : Object");
} catch (Exception e1) {
Log.d(TAG, "convertJSONArray : Fails");
}
Log.d(TAG, "convertJSONArray : ret = "+ ret.toString());
return ret;
}
}
まあえばって公開するほどのコードでも無いんですが、いちいちArrayとObjectを切り替えるのがコード上面倒だったもんで、ちょっと悩みました。
なのでせっかくなんで公開しておきます。
2012年10月15日月曜日
2012年10月4日木曜日
逃亡編
(例によって絵と本文は関係ありません)
前編: herokuでform_tagの:remote => trueが動かない の続き
結論から行くと、なんとかなりました。
端的に言うと
はい。逃げました。
そ、Solutionが多数用意されているというのもRailsの柔軟性の高さですね。
とかなんとか。
具体的には
view/layoutで参照されているlayout(一般的にはapplication.html.erb)に下記を定義
<% form_tag ... %>~<% end %>中に
で、あとは、form_tagのactionから上記のdoPostを呼ぶようにすればOK
結論から行くと、なんとかなりました。
端的に言うと
:remoteの代りにformのactionでjQueryを使用してajaxを実行
です。はい。逃げました。
そ、Solutionが多数用意されているというのもRailsの柔軟性の高さですね。
とかなんとか。
具体的には
view/layoutで参照されているlayout(一般的にはapplication.html.erb)に下記を定義
var doPost = function (url) {
$.ajax({
url: url,
type: "post",
data: "comment="+$("#comment").val(),
dataType: "script"});
};
$("#comment")はjQueryによるSelectorです。<% form_tag ... %>~<% end %>中に
<%= text_field_tag :comment %>があれば、id="class"で上記のSelectorは正しく動く、はず。
で、あとは、form_tagのactionから上記のdoPostを呼ぶようにすればOK
<%= form_tag ("javascript: doPost(\"/sessions/\"") do %>
本当は、:remoteと完全に同じ挙動にするためには以下にしたかった<%= form_tag ('#', :onsubmit => "doPost(\"/sessions/\"); return false;") do %>
でもやっぱり、form_tagが第二引数を取ってくれないので相変わらずエラーになるので逃げた。逃げるが勝ち
2012年9月14日金曜日
てんやのTips
ご存じみんな大好き「てんや」のTips紹介
企画、期間限定物はちょっと割高なので天丼をベースにカスタマイズするのが基本です。
おれの基本は天丼+お好みナス乗せ。560円。
また、定食にすると、天汁で食べた後、テーブルにある天丼のタレで小天丼も楽しめておトクです。
しかし定食にすると650円・・・ ま、迷うんじゃよ。
企画、期間限定物はちょっと割高なので天丼をベースにカスタマイズするのが基本です。
おれの基本は天丼+お好みナス乗せ。560円。
また、定食にすると、天汁で食べた後、テーブルにある天丼のタレで小天丼も楽しめておトクです。
しかし定食にすると650円・・・ ま、迷うんじゃよ。
2012年9月13日木曜日
herokuでform_tagの:remote => trueが動かない
(絵と本文はちょっとだけ関係あります。無力感とか)
更新していない間、色々ありまして今はRuby on Railsをherokuで動かしてます
・・・何があったんじゃろか?
で一個どうしても解決できない問題があるのでここに挙げておこうと思います
[現象]
以下のhelperがherokuで正しく動作しない(実行時エラー)<%= form_tag ('/sessions', :remote => true) do %>
ローカルのrails上では正しく動作している[エラーの詳細]
% heroku logs
:
2012-09-11T03:50:31+00:00 app[web.1]: ActionView::Template::Error (/app/app/views/tables/_form.html.erb:1: syntax error, unexpected ',', expecting ')'
2012-09-11T03:50:31+00:00 app[web.1]: ...nd= form_tag ('/sessions', :remote => true) do @output_...
2012-09-11T03:50:31+00:00 app[web.1]: ... ^
:
要は第二引数が有ることがダメだと言っているみたい。一方ローカルでは期待通り下記のように変換され、正しくリクエストが発行できる
<form accept-charset="UTF-8" action="/sessions" data-remote="true" method="post">
[分かっている事]
% bundle status % heroku run bundle statusの差分は以下の通り。後者は意図通りなので実質bundlerのみ。これはhelperの動作とは関係ないはず・・・
11c11 < * bundler (1.1.5) --- > * bundler (1.2.0) 28a29 > * pg (0.14.1) 41d41 < * sqlite3 (1.3.6)
ちなみにheroku側のGemはこんな感じ。Railsは3.2.8なので問題ないはず・・・
* actionmailer (3.2.8) * actionpack (3.2.8) * activemodel (3.2.8) * activerecord (3.2.8) * activeresource (3.2.8) * activesupport (3.2.8) * arel (3.0.2) * bcrypt-ruby (3.0.1) * builder (3.0.0) * bundler (1.2.0) * coffee-rails (3.2.2) * coffee-script (2.2.0) * coffee-script-source (1.3.3) * commonjs (0.2.6) * erubis (2.7.0) * execjs (1.4.0) * hike (1.2.1) * i18n (0.6.1) * journey (1.0.4) * jquery-rails (2.1.1) * json (1.7.5) * less (2.2.1) * less-rails (2.2.3) * libv8 (3.3.10.4) * mail (2.4.4) * mime-types (1.19) * multi_json (1.3.6) * pg (0.14.1) * polyglot (0.3.3) * rack (1.4.1) * rack-cache (1.2) * rack-ssl (1.3.2) * rack-test (0.6.1) * rails (3.2.8) * railties (3.2.8) * rake (0.9.2.2) * rdoc (3.12) * sass (3.2.1) * sass-rails (3.2.5) * sprockets (2.1.3) * therubyracer (0.10.2) * thor (0.16.0) * tilt (1.3.3) * treetop (1.4.10) * twitter-bootstrap-rails (2.1.3) * tzinfo (0.3.33) * uglifier (1.3.0)
・・・全然分かりません。
じ、次回は解決編じゃぜ?!
2012年8月11日土曜日
ubuntuとかtomcatとかJDBCとかの小ネタ
諸事情によりubuntuでtomcatやらscreenやらJDBCやらいじることになり、その時のメモを公開しまス
ubuntuではssh接続環境下では、screenは単純には動作しないようです。(12.04LTS)
ncurses-termのインストールが必要になります
これでssh接続下でscreenが実行可能になります
ncurses-termについては特別な設定は不要です
もちろん、.screenrcは適切に作成できている等はできているという前提です
その後、ブラウザから
http://localhost:8080
にアクセスしてインストール成功の画面が出ても、tomcat7の場合は下記を入れないとそれぞれのリンクから先に進めません
というかなぜかこれが書いてある所があまりないようなのでここに記載
ただ、servletの場合、javacのclasspathにdriverのパスを指定してもムダです。コンパイルは通るのでブラウザ経由でServletにアクセスはできますが、driverのinstanceを生成するコードが実行されると、そんなクラス知らない、という例外が発生します
ここでは一般のjavaファイルを実行する場合を考えましょう。この場合何らかの外部パッケージを使用している場合は
と、JVMに必要なjarファイルのパスを知らせます。これと同じ事でServletの場合は同様にtomcatがcom.mysql.jdbc.Driver.jarにアクセスできないといけません
という事で、正解は必要なファイルをWEB-INF/libに入れる、です
これも書いてある所が意外とすんなり見つからなかったのでここに記載
なお、Ubuntuの場合はSymbolic Linkでも機能します
って見ますが、これは基本的に動的なクラス名からインスタンスを生成する時に使う方法です
たとえば、
っていう感じの事をしたい時に使う手法です
ちなみに、本com.mysql.jdbc.Driverはimportができないようですが、importできないイコールnewできない、ではありません
importは
を
という様にパッケージ名を省略できるようにするための仕組みです
ubuntuでssh経由のscreenを使用する
ubuntuではssh接続環境下では、screenは単純には動作しないようです。(12.04LTS)
ncurses-termのインストールが必要になります
$ apt-get screen install $ apt-get ncurses-term install
これでssh接続下でscreenが実行可能になります
ncurses-termについては特別な設定は不要です
もちろん、.screenrcは適切に作成できている等はできているという前提です
tomcat7の導入
諸々のサイトでは普通に下記で良いとありますが$ apt-get tomcat7 install
その後、ブラウザから
http://localhost:8080
にアクセスしてインストール成功の画面が出ても、tomcat7の場合は下記を入れないとそれぞれのリンクから先に進めません
というかなぜかこれが書いてある所があまりないようなのでここに記載
$ apt-get install tomcat7-admin $ apt-get install tomcat7-docs $ apt-get install tomcat7-examples
tomcatからMySQLへのアクセス
そこら中に説明がありますが、tomcat等からjdbc経由でMySQLにアクセスするためにdriver(com.mysql.jdbc.Driver.jar)が必要ですただ、servletの場合、javacのclasspathにdriverのパスを指定してもムダです。コンパイルは通るのでブラウザ経由でServletにアクセスはできますが、driverのinstanceを生成するコードが実行されると、そんなクラス知らない、という例外が発生します
ここでは一般のjavaファイルを実行する場合を考えましょう。この場合何らかの外部パッケージを使用している場合は
$ java ~.java -classpath ~.jar
と、JVMに必要なjarファイルのパスを知らせます。これと同じ事でServletの場合は同様にtomcatがcom.mysql.jdbc.Driver.jarにアクセスできないといけません
という事で、正解は必要なファイルをWEB-INF/libに入れる、です
これも書いてある所が意外とすんなり見つからなかったのでここに記載
なお、Ubuntuの場合はSymbolic Linkでも機能します
JDBCのMySQL用DriverのInstance生成
この方法自体はあちこちで説明されています。そこでは呪文のようにClass.forName("com.mysql.jdbc.Driver").newInstance();
って見ますが、これは基本的に動的なクラス名からインスタンスを生成する時に使う方法です
たとえば、
String className = request.getParameter("class");
Class.forName(new String (className)).newInstance();
っていう感じの事をしたい時に使う手法です
本来、このMySQLドライバのインスタンス生成を行うケースではクラス名は分かっているので
っていうお馴染みの方法でOK
new com.mysql.jdbc.Driver();
っていうお馴染みの方法でOK
こちらもなぜかこの事が書いてあるサイトが無いのでムダな抵抗でここに書いておきます
ちなみに、本com.mysql.jdbc.Driverはimportができないようですが、importできないイコールnewできない、ではありません
importは
new java.util.List();
を
new List();
という様にパッケージ名を省略できるようにするための仕組みです
2012年7月25日水曜日
ソフト開発スキルだけでは何も作れない?
すっかり行かなくなってしまった合コンですが、下記みたいなパターンが定番でした
女の子「何やってるんですかぁ~?」
自分「んぁー、TV?作ってるって感じ?」
女の子「えー、TV、なんか流れてくる感じの組み立てるの?」
自分「いやー、そーいうんじゃなくてソフト作ってます」
女の子「ソフト?」
っていうのがメンドくさくてしまいにはマジメに説明しなくなりましたが、まあ一般的にはソフトって何?っていう人はまだ多いでしょう(うちの嫁とか)
ソフトの事は分かる、という一般的でない人でも、ソフトの定義ってこういうのが主だと思います
まあ業態により色々あると思いますが、ソフト関係者が想像されるのはこの辺なんじゃないでしょうか
という事を踏まえ、先の記事のようにこれからソフトスキルを軸足にして伸ばすべきスキルって何だろう、と考えた時に気づきました
「ソフト開発スキルだけじゃ一人じゃまともなもんなんも作れなくね?」
何らかの組み込みであろうが、PCやスマホのアプリ、はたまたクラウドアプリであろうが、何かしらユーザーを相手に機能するためには、ソフトに加え必ず
の二つが必要になります
まあ絵にするほどのもんでもありませんが。
これって当たり前だと思っている人もいるんだと思いますが、自分的にはちょっとした発見でした。
ソフト関係者でこれを意識している方は意外と少ないんじゃないかなー?
次はこれにしようかなと
これで「データベースを有効活用しつつ、グラフィックデザインもシャレオツでUIも解りやすい」ナイスアプリが一人でも作れるようになって副収入がっぽがぽだぜ日本の発展に貢献したいとオモイマス
女の子「何やってるんですかぁ~?」
自分「んぁー、TV?作ってるって感じ?」
女の子「えー、TV、なんか流れてくる感じの組み立てるの?」
自分「いやー、そーいうんじゃなくてソフト作ってます」
女の子「ソフト?」
っていうのがメンドくさくてしまいにはマジメに説明しなくなりましたが、まあ一般的にはソフトって何?っていう人はまだ多いでしょう(うちの嫁とか)
ソフトの事は分かる、という一般的でない人でも、ソフトの定義ってこういうのが主だと思います
- プログラム言語に精通している(C言語とかJavaとかperlとか)
- フローチャートとかオブジェクト指向とか
- デザインパターンとかUMLとか
- 仕様定義とか要件定義とか
- 大規模開発とか構成管理ツールとかバグトラッキングツールとか
- ウォーターフォールとかアジャイルとか
- サーバとかクライアントとか
という事を踏まえ、先の記事のようにこれからソフトスキルを軸足にして伸ばすべきスキルって何だろう、と考えた時に気づきました
「ソフト開発スキルだけじゃ一人じゃまともなもんなんも作れなくね?」
何らかの組み込みであろうが、PCやスマホのアプリ、はたまたクラウドアプリであろうが、何かしらユーザーを相手に機能するためには、ソフトに加え必ず
- UIデザイン
- データそのものとデータ管理方法
これって当たり前だと思っている人もいるんだと思いますが、自分的にはちょっとした発見でした。
ソフト関係者でこれを意識している方は意外と少ないんじゃないかなー?
という事もあり、簡単なアイコンくらいなら作成できるようになろう、という事でGIMPの勉強をはじめた、という経緯です。
また、UIやデータハンドリングを考える上で参考になるかなぁという事で、情報デザインの勉強で下記の本を読んだりしています
2012年7月12日木曜日
ゲシュタルト崩壊
(絵と本文は関係ありません)
2012年に5σ、すなわち99.9999%以上の確度での存在が確認されたヒッグス粒子
当時一般にはまだ理解不能の発見と見なされていたこの発表であったが、この世紀の発見は2050年代に有害な副産物を生成しない新たなクリーンエネルギーの発明へとつながり、気がつけば2070年代には先進国も含め世界中にこのエネルギーは普及し、全人類がその恩恵に預かっていた
だが、一部の科学者達はその世界的な普及に比例するかのごとくある不安を増大させていた
それはヒッグス粒子発見という世紀の発表に沸くわずか3年前、無名の宇宙物理学者ゲシュタルトが発表したある論文、
エネルギーの崩壊に関する論文であった
簡単に要約すると、以下のような内容である
我々地球人は、今まで自然に存在するものをなんらかの反応でエネルギーに変換し、利用していた
宇宙規模で普遍的に存在する現象、つまり燃焼、移動、電磁気、ひいては核反応も含め、これらの方法で生成された場合は均衡を保っているエネルギーだが、それ以上の変換効率を持つエネルギー変換を行うことで、生成されたエネルギーはある条件下で連鎖的に崩壊するような現象を起こす、という既知の数学理論を元にしたある種の予想であった
当のゲシュタルトはその論文を発表して1年もなく学会から姿を消し、誰知らず失踪してしまう
そもそも学会にまともに扱われる事もなかったこの論文、多くの学者達には見向きもされなかったが、何か感ずるものがあった一部の学者達はこの論文を何度も検証した
しかし2070年代まで論理の破綻や反証事実が見つかる事はなく、あろうことかある若い数学助手によりこの予想は証明されてしまう
だがその事実すら学会にまともに扱われる事はなかった
そして207x年、ゲシュタルトの予言したエネルギー崩壊は現実のものとなる
超エネルギー消費社会となった207x年、突如エネルギーの供給源が消える事が何を意味するか
文明とはかくも脆く崩壊するものなのか・・・
ごめんなさい。ゲシュタルト崩壊って言葉が厨二ワードっぽいんでつい
ゲシュタルト崩壊ってのは、ある単語(「あ」とか「家」とか)ずっとそれ見たり書いたりしてると、「あ」ってこんなんだっけ?「家」ってこんな文字だっけ?これなんだっけ?みたいなちょっと混乱して変な感じになる現象の事です。
ふつー
名前負けー
リンクはんのもかったるいんで適当にWikipediaで検索してください
っていうのは冷たいんで ほらよ
やさしいな俺
2012年に5σ、すなわち99.9999%以上の確度での存在が確認されたヒッグス粒子
当時一般にはまだ理解不能の発見と見なされていたこの発表であったが、この世紀の発見は2050年代に有害な副産物を生成しない新たなクリーンエネルギーの発明へとつながり、気がつけば2070年代には先進国も含め世界中にこのエネルギーは普及し、全人類がその恩恵に預かっていた
だが、一部の科学者達はその世界的な普及に比例するかのごとくある不安を増大させていた
それはヒッグス粒子発見という世紀の発表に沸くわずか3年前、無名の宇宙物理学者ゲシュタルトが発表したある論文、
エネルギーの崩壊に関する論文であった
簡単に要約すると、以下のような内容である
我々地球人は、今まで自然に存在するものをなんらかの反応でエネルギーに変換し、利用していた
宇宙規模で普遍的に存在する現象、つまり燃焼、移動、電磁気、ひいては核反応も含め、これらの方法で生成された場合は均衡を保っているエネルギーだが、それ以上の変換効率を持つエネルギー変換を行うことで、生成されたエネルギーはある条件下で連鎖的に崩壊するような現象を起こす、という既知の数学理論を元にしたある種の予想であった
当のゲシュタルトはその論文を発表して1年もなく学会から姿を消し、誰知らず失踪してしまう
そもそも学会にまともに扱われる事もなかったこの論文、多くの学者達には見向きもされなかったが、何か感ずるものがあった一部の学者達はこの論文を何度も検証した
しかし2070年代まで論理の破綻や反証事実が見つかる事はなく、あろうことかある若い数学助手によりこの予想は証明されてしまう
だがその事実すら学会にまともに扱われる事はなかった
そして207x年、ゲシュタルトの予言したエネルギー崩壊は現実のものとなる
超エネルギー消費社会となった207x年、突如エネルギーの供給源が消える事が何を意味するか
文明とはかくも脆く崩壊するものなのか・・・
ごめんなさい。ゲシュタルト崩壊って言葉が厨二ワードっぽいんでつい
ゲシュタルト崩壊ってのは、ある単語(「あ」とか「家」とか)ずっとそれ見たり書いたりしてると、「あ」ってこんなんだっけ?「家」ってこんな文字だっけ?これなんだっけ?みたいなちょっと混乱して変な感じになる現象の事です。
ふつー
名前負けー
リンクはんのもかったるいんで適当にWikipediaで検索してください
っていうのは冷たいんで ほらよ
やさしいな俺
2012年7月6日金曜日
転機
というわけで仕事で悩んでいたり、不幸もあったのですが、今の自分のような状況を「転機」というという事を同期から聞きました
で、本を紹介されたので備忘がてら記載しておきます
トランジション―人生の転機
なるほどねー。転機すか
聞いた事あるわ
トランジション―人生の転機
なるほどねー。転機すか
聞いた事あるわ
2012年7月3日火曜日
ソフトエンジニア?マネージャー?
(絵と本文は関係ありません)
自分はいわゆるソフトエンジニアです。フリーではなく会社に所属しています。
若手時代はオブジェクト指向やらデザインパターンやらを勉強しつつガリガリ設計、実装を行い、その辺の経験を一通りしたあとはリーディング、外部管理、仕様管理、というような(恐らく)非常に典型的なキャリアを通ってきました
で、今、次にどこに進むべきかという事を考えています
タイミング的にはマネージメントの方向に進んでいくというキャリアが会社的には妥当なんだと思います
ただ、流れといえばそうなんでしょうが、十ウン年磨いたスキルをあっさり捨ててマネージメントという新たなスキルを一から磨く、というのは本来ならば大きなチャレンジであり、決断が必要です。自分の強みも理解せずにただ流れに乗るようにそっちに転向しても溺れますよね普通・・・
そもそもエンジニアになったのも、ソフトが自分の強みだと思ったからですし
またこれはうちの会社だけの特徴なのかもしれませんが、いわゆるマネージメントの人数が多すぎるように思います。一方でソフトに直接関わらない人達が増え、組織としての技術力が右肩下がりとなり、それに伴って自身のスキルも鈍ってきているように感じます
という事もあり、こんな状況下でマネージメントの方向に進むのって会社ありきという印象をどうしても持ってしまいます。これから時代、個人のスキルを常に磨いていないとほんと路頭に迷いかねません
という事もあり、今は迷いつつもやはり今まで磨いてきたスキルを軸足にして、エンジニアとしてスキルアップしていく方が良いんじゃないかと思っています
まあ海外への大量の技術流出が進んでいる昨今、高いコストの日本でエンジニアを続けるのも茨の道なんですけどね・・・でもやっぱり何も無いところから何かを作る技術は日本はまだトップレベルですし、そういう所でがんばるしかないかなと思っています
よくキャリアは山登りに例えられます
なんでもかんでもというのは無理で、登る山を決めたら少しづつ着実に上を目指す、という姿勢が似てるって事なんでしょうかね
今の自分は山の中腹まで登ってきて、上を見たらなんか角度が急になってるー
しかも一方で他の(今までとは違う雰囲気の)山の麓へのリフト乗り場があるー
という場所に来ているようです
急勾配そうですが、まだこのまま今の山を登り続けようと思っている、という感じです
では、今後さらに急になる山をどうやって登り続けるのか?というあたりはまた後日のネタに
2012年6月28日木曜日
変換行列についての考察
さて、敬愛するタモさんは「おっぱい星人」です
他にもネット上ではやれ巨乳が良いだの、ちょいぽちゃが好きだだの、くびれ命だの、女性の体型に関する議論(というか単なるカミングアウト)は枚挙に暇がありません
ちょいブス萌え、とか言われても知らんがな
今回はこの事について考えてみたいと思います
まず、女性の体型は多くのパラメータで表現されるとします。つまり、女性の体型は多次元行列で表現する事ができると考えます
今回はこの事について考えてみたいと思います
まず、女性の体型は多くのパラメータで表現されるとします。つまり、女性の体型は多次元行列で表現する事ができると考えます
つまり「おっぱいのサイズ」や「くびれの程度」「おしりのサイズ」「身長」「体重」…という直行するいくつかの1次元パラメータを集めた多次元の行列、と定義するわけです
そして、見る側の「萌え」だの「好き」だのは女性の体型を表わすそれぞれのパラメータに対して、どのパラメータをどれだけ重視するか、という情報を集めたものと考えられます。
そして、見る側の「萌え」だの「好き」だのは女性の体型を表わすそれぞれのパラメータに対して、どのパラメータをどれだけ重視するか、という情報を集めたものと考えられます。
ここでは女性の体型の各パラメータをどれだけ重視するかを1次元のスカラー値で表現する事を考えます
そしてこの1次元のスカラー値を並べたものが、まさに見る側の「個人の好み」を表現する変換行列となる、というわけです
つまり、ここではある女性の体型を表わす多次元行列を、見る側の好みを基準としたスコアにする事ができる変換行列こそが、「個人の好み」や「~星人」と定義できる、と考えるわけです
行列、というと難しいものを想像されてしまうかもしれませんが、今回は出力は点数、スコアという1次元のスカラー値です。よってこの「個人の好み」を表わす行列というのは、女性の体型を表わす各パラメータそれぞれについて、その個人がどれだけそれぞれのパラメータを重視するか、という重み付けの係数を並べただけのものとなるはずです。
まだ分かりづらいと思いますので詳しく見ていきましょう。入力となる女性の体型パラメータ列($W$)を例として下記のように定義します
$W_0 = $ おっぱいのサイズ
$W_1 = $ くびれ具合
$W_2 = $ おしりのサイズ
$W_3 = $ 身長
$W_4 = $ 太さ
$W_5 = $ 顔のレベル
$W_6 = $ 肌の色
まだ分かりづらいと思いますので詳しく見ていきましょう。入力となる女性の体型パラメータ列($W$)を例として下記のように定義します
$W_0 = $ おっぱいのサイズ
$W_1 = $ くびれ具合
$W_2 = $ おしりのサイズ
$W_3 = $ 身長
$W_4 = $ 太さ
$W_5 = $ 顔のレベル
$W_6 = $ 肌の色
W = \left(
\begin{array}{c}
W_0\\
W_1\\
W_2\\
W_3\\
W_4\\
W_5\\
W_6\\
\end{array}
\right)
\end{eqnarray}
実際は乳首の形、等もっと多くのパラメータが存在するはずですが、ここでは簡略化のため上記の7つに絞ります
これに対し「個人の好み」を表わす変換行列$F$は、上記の$W_0$~$W_6$それぞれをどれだけ重視するかを当てはめていけば作る事ができます。例えば自分の場合
$F_0 = -0.2$
$F_1 = 0.8$
$F_2 = 0.1$
$F_3 = -1.0$
$F_4 = -0.6$
$F_5 = 1.0$
$F_6 = 0.8$
\begin{eqnarray}
F = \left[
\begin{array}{ccccccc}
F_0 & F_1 & F_2 & F_3 & F_4 & F_5 & F_6 \\
\end{array}
\right]
\end{eqnarray}
と表現できます
この結果
FW = S
\end{equation}
という形でスコア$S$が算出できる、という事になるわけです
詳しく見ていきましょう
まず、$F_0$ですがおっぱいのサイズをどれだけ重視するかです。ここでは-(マイナス)の係数となっています。つまりこれは「おっぱいが大きい方がスコア下がる」「重みは0.2なので大きくても問題ない」という事です
ただ、ここは難しい問題を含んでいます。
かの有名な「バスト占いのうた」でもCカップこそが「最も限りなく正解に近い」とされています。
また、エロ男爵こと沢村一樹さんはおっぱいで重視するポイントとして「味」と回答されています(出展)
よって上記例を考えると、本来は単純にサイズが大きければ$W_0$が大きい、という関係にはなりません
ですが、本考察上は$W_0$は小さい程微乳、大きい程巨乳、という単純なマッピングとします。
(規格外の巨乳を考慮し、大きい方に対してレンジは規定しません)
このように単純化する理由ですが、まず係数が0.2である事からご想像いただけるかもしれませんが、正直おっぱいのサイズあまり気にしてないからです
でも大きいのはちょっと怖い
自分に自信が無い証拠です
次の$F_1$は0.8とそれなりに大きな値となっています
「くびれは無いとイヤだなー」という感覚ですね
ただ、後述の$W_3$、$W_5$、$W_6$とは同程度もしくは低い重み付けですので、例えば「くびれの女王」とかいう中吊りにつられて雑誌買って見たら、顔とかが好みじゃなくてがっかり、とかは有り得るという意味です
がっかりした事がある、とは言っていません
ここ重要です
次の$F_2$は0.1です。これは正直どうでも良い、というレベルですね。ここで注意していただきたいのは、この0.1という数字は「小さい方が良い」ではありません。実際に計算していただくと分かるのですが、この$F_2$の小ささは最終的に算出されるスコアに対する$W_2$の影響度が低い、という事を意味しています。
よって大小があまり気にならない、という意味になるわけです
でもデカいとミニワンピとかがかわいく見えるのは否定しません
ここも重要です
で、$F_3$はマイナス-1.0です。$F$行列全体の中では$F_5$と並んで一番大きな絶対値を持っています。つまり重視する、という事です
しかし値は-(マイナス)です。これは重視の方向が逆、つまり身長が高い程スコアが下がる、という事を意味しています
いわゆるミニ萌え
具体的には矢口
次の$F_4$ですが、0.6と低くもなく高くもなく、という感じですね。これはごく平均的な感覚とお考えください。つまり「普通にデブはイヤ」というレベルです
だとこれは-1.0じゃないのか?と思われるかもしれませんが、前述の通り値の大きさは$F$の中で相対的にどれだけ重視するか、という事を意味しています。つまりちょっと太めでも、$W_1$、$W_3$、$W_5$、$W_6$が高い(もしくは低い)ならばスコアに対して「太さ」が与える影響は相対的に低くなるわけです
なのでそんなにダイエットダイエットって言わなくて良いです
普通が一番
そしてついに$F_5$で1.0が出ました
これも$W_0$と同様、難しい問題を含んでいます。そもそも人間の顔の作りは多くのパラメータを含んでいます。目、鼻、口各パーツの位置、大きさ、形、また顔全体のサイズ、形・・・
詳細は改めてまた考察したいと思いますが、今回は例えば1万人に点数付けをしてもらった平均点、くらいに考えてください。一般論としての美人、ブス、というパラメータという感覚です。ここでは単純に美人ほど$W_5$の値は高くなる、と定義しています
というわけで顔、大事
体型良くても顔でがっかりというのはグラビアの世界では良くある罠です
特に巨乳ブーム以降、その傾向が顕著になってきた気がします
気をつけましょう
最後に$F_6$ですが、これも意外と単純ではありません
特に巨乳ブーム以降、その傾向が顕著になってきた気がします
気をつけましょう
最後に$F_6$ですが、これも意外と単純ではありません
ここでの$F_6=0.8$というのは、「なるべく色白が良いなー」というニュアンスです
この場合、$W_6$が大きい程、肌の色は白い、という意味です
んじゃ焼けた肌が好き、というのはどう表現するか?がポイントになります
この場合、$W_6$が大きい程、肌の色は白い、という意味です
んじゃ焼けた肌が好き、というのはどう表現するか?がポイントになります
$W_6=0$が真っ黒と定義するとどうなるでしょうか?
ちょっと計算していただくと分かりますが、この場合$W_6=0$の真っ黒ギャルに対しては$F_6$をどういじろうがスコアに対して影響を与える事ができないという事になってしまう事が分かります
これは俺はどーでも良い事ですが黒ギャル好きは納得しないでしょう。
これは俺はどーでも良い事ですが黒ギャル好きは納得しないでしょう。
よって、この$W_6$は例外的に$W_6=0$を平均的な薄ピンクとし、マイナス方向を色黒、プラス方向を色白、と定義します。これによりギャル好きはマイナス値の$F_6$を持つ事で表現できます
まあでもやっぱ色白だよねー
上記はシンプルな例ですが、これで好みを表わす行列$F$ができました
文中で触れている通り、特におっぱいと顔については課題が残るものの、女性の体型およびそれに対応した個人の好みを行列で表現し、女性の体型に対する見る側のスコアを算出するという理論の可能性が示されたと思います
・・・なんの話でしたっけ?
・・・まあ、要は色白ミニでクビレもちゃんとある美人が好きって言いたかっただけだわ
1行で済んだわチキショウ
2012年6月23日土曜日
Androidアプリ開発小ネタ
(絵と本文に関係はありません)
ちなみに「これ、羊なの」だ、そうです
さて、Androidアプリの世界では
- 無償版。Free。機能制限 and 広告有り
- 有償版。Full機能 and 広告無し
というのは結構定番ですよね
今回は、アプリ開発の観点から、上記をスマートに実現する方法を考えます
(ググっても良いやり方が買いてあるブログ、サイトが見つけられなかったので・・・)
通常、これらのアプリは別アプリとしてMarketに置かれています
よってPackageとしては別になります
そのため物理的に一つのソースコード(.javaファイル)を共通して持つ事はできません。Javaは実装毎に自分がどのパッケージに含まれるのか明記が必要だからです(という理解です)
一方、有償、無償、双方に共通の機能は共通の(ひとつの)実装にしたいと普通は考えます
Java、Android開発の経験が浅かった事もあり、また実質開発終了していたため、以前は真面目に考えずコピーして済ませてしまいました
今回はまだ公開前という事あり、ちゃんと考えてみました
ちなみに現時点ではまだ机上検討レベルで未確認です
実装してみて課題や解法見えたら、またここに追記したいと思っています
ポイントは継承です(今考えるとすげー普通)
その1
- 有償版(広告無し)を実装
- 無償版は有償版のMainActivityを継承 (importで有償版のパッケージを指定する事で可能になるはず)
- 無償版Activityで広告viewの追加およびlistener回りの処理を追加。また機能制限されているものは蓋をする(この仕組みは有償版に入れておく必要あり)
その2
- 無償版(広告有り)を実装
- その1同様、有償版は無償版のActivityを継承する
- 有償版のActivityでは広告表示を停止する。また必要な追加機能等をactivateする(同じく無償版は有償版限定機能も実装しておき、蓋をしておく必要がある)
ただし上記その1、その2では親クラスとなるActivity(およびパッケージ)が、本来そのパッケージには関係の無い機能を(蓋をするなりして)有しているという事になり、デザイン上はあまり好ましく無さそうです(まあ、個人開発のレベルでは問題にならないと思いますが)
よって、理想的には
- 無償、有償で共通な機能をcommon packageで実装する
- 無償、有償それぞれがcommon packageを継承したactivityを作成
- 無償、有償それぞれにそれぞれ必要な機能を追加する
ですね。common packageはいわゆる.apkを生成する必要はなく、未公開という事になります。
まずはこれで今作ってるやつ実装してみます
2012年6月20日水曜日
怒涛の英語
と言えばみすず学苑
仕事が終わり、とぼとぼと駅に向かう。ホームに立つと、しばらくして同じように疲れきった人々を乗せた電車が到着する。無表情で降車する他の乗客達。そして自らも電車に乗り込む。運よくドア際には人が立っていない。そこに立とう。壁にもたれかかりぐったりする。スマホをいじる気力もない。そして発車音が鳴りしばらくしてドアが閉まる---
みすず学苑新しいのキターーーー
一時期トラウマレベルのTV CMをやってましたね
ツッコみ所が多すぎて、正直不安になるレベル
塾としてこのスタイルは集客力があるのだろうか・・・おれならかわいいおにゃの子がCM出てる塾選ぶなぁとか(早○田塾とか)
というわけで自分はこの広告、CMを目にした時に冷静さを保つ事ができないのですが、ちょっと前に読んだどこかの記事に「色んな人が出てくるが、怒涛の英語と言っておきながら英語を母国語にしている人が全然出てこない」的なすげー冷静な分析があって、その発言をされた方の冷静さに感服した記憶があります。おれヤマトタケルが毎回居る事くらいしか分からん
さすがにTV CMは見なくなってしまいましたが、車内広告はまだ健在ですね
みすず学苑新しいのキターーーー
今や癒しです。
ってみすず学苑なんて他のブログでも触れてる人多そうだな(怖いから検索しないけど)
2012年6月19日火曜日
改竄
というわけで早速、前回の絵を加工してみた
と、言ってもスキャナで取り込んだ際に裏のページがうっすら入り込んじゃっているのが気になったので、消してみただけ
編集はGIMPです
あらかじめ宣言しておきますが、GIMPなんてド素人です。インストールして一ヶ月経ったかそこらです。勉強中です
もっといい方法、定番のやり方があるかもしれませんね
1. [ツール]>[色域を選択]で背景色(ノートの白の部分)を選択、[しきい値]を変えて写り混んだ色は選択され、絵の部分は丸々非選択になる(線の中に選択領域が入り込まない)、という辺りをさぐる
2. [選択]>[選択領域を反転]してから[選択]>[クイックマスクモード]でモード変更、背景部分(絵じゃない部分)をピンクに塗っていく
3. 納得いくクイックマスクが作成できたら、[選択]>[クイックマスクモード]でクイックマスクモードを終了し、ここで[選択]>[チャンネルに保存]しておく(念のため)
4. 再び[選択]>[選択領域を反転]、[編集]>[切り抜き] (or [コピー])、[編集]>[貼り付け]として絵をフローティングレイヤ化。そしてレイヤーダイアログで[新規レイヤーの作成]を実行、フローティングレイヤ化した絵を別のレイヤーに移す
5. レイヤーダイアログでオリジナルの絵があったレイヤの左側の目のマークを消し、レイヤを不可視化。これで編集画面上は元の絵が透明領域の中に書かれている状態になる
6. レイヤーダイアログ上で、別レイヤー化した絵の直下で[新規レイヤーの作成]を実行し「背景」と名前付ける。一旦全面透明で作成。
7. レイヤーダイアログでオリジナルの絵を一時的に可視状態にし、[ツール]>[スポイト]で背景色としたい色(裏のページの色が入り込んでない部分)の色を吸い出す。でオリジナルの絵はまた不可視に戻す
8. [ツール]>[塗りつぶし]を使い、吸い出した色で「背景」レイヤを全部塗りつぶし
で、裏のページの映り込みは消せました。
手順で書くと一見複雑に見えますが、やってる事は結構シンプルです。
もうちょっと自然にやるには、8で背景レイヤを単色塗り潰しにせずに、再度写り込みが無いようにまっしろの紙をスキャンしてその画像を背景レイヤに使用する、という手もありますね。
っていうかそもそも、もっと良い方法ないのか???
2012年6月17日日曜日
子供の絵
ブログを始めようと思ったきっかけの一つがこれ
3歳なりたてのうちの長男はらくがきちょうでお絵描きするのが好きです
ちょっと前までただのぐちゃぐちゃだったのが、最近はけっこう印象的で面白い絵を書くようになってきました
でもらくがきちょうがいっぱいになるとママはけっこうあっさり捨てちゃうんですよね
ちょっと思い出的にもったいないなぁと
で、キャプる事を思い付きました
だったらいっそネットに上げちゃおうと考えた結果、一番良い形式はブログかなぁという事でブログを立ち上げる事を考え始めました
(冷静に考えるとキャプチャ作業かったるいし、モチベーションにもなるかなと)
GIMPの加工素材にも使えそうだな
はじまりはじまり
2012年は人生の事を考えざるを得ない出来事が色々ありまして、唐突ですがブログを始める事にしました
どういう論理の展開でブログ開設となったのかは今後の記事で少しづつ明らかになります(予定)
・・・テーマは特に考えていません。自分の興味ある事、思ってる事なんかをつらつらと書いていくスタイルを考えています
ざっと挙げると
- ソフト開発。アンドロイドアプリとか
- お絵描き。GIMPとか
- 単に気になっているモノとか
- まじめな話。どういったスキルをどのように磨くべきか・・・
- おもしろネタ
- シモ。ソフトエッチ、セクシーまで。ドエロは禁止
あとはこのブログがどういうわけか多くの方から注目され、副収入がっぽりになればみなさまの心を豊かにする事ができれば幸いです
ではまた
登録:
コメント (Atom)











