自分の常識が世間の常識である事を疑うという事

きつつき。
大量。
というか嘴の向きが逆。

さて、会社のトイレの話。
コスト削減の嵐が吹き荒れていますが、さすがにトイレットペーパーは常備されております。

が、このトイレペが自分に難しいテーマを突きつけてくるのです。

確かに、自らの常識が世間の常識であるとは思わない方が良い、という事は分かっています。

• 普通カレーにじゃがいも入れるよね？
• 普通寄せ鍋にウインナー入れるよね？
• 普通ズボンの左がポジションだよね？
• 普通道具とか使うよね？

等。(道具は使いません。念のため)

しかし、会社のトイレペですが、

縦に裂け易い

のです。横に切れ目を入れて無造作にひっぱると、ほぼ確実に縦方向に切れます。
新聞みたいな感じですね。

製造上、この方がコストが安いとかそんな理由なはずがありません。
これはユーザーの使用感を考慮した結果、こういう仕様になっていると考えるのが自然です。

自分は今の今まで、世間の9割、いや9割9分の人がトイレペは横に切って使う物だと思っていました。
どうやら、トイレットペーパーは縦に割いて使うのが主流みたいです。

というわけでトイレペを横に裂いて使う少数派の自分に、主流となる正しいトイレペの使い方を誰か教えてください。
よろしくお願いします。

子供向け(大人も可) 迷路ゲーム "KIDZ MAZE" 公開

調子に乗ってもう一つアプリ公開しました

迷路ゲーム KIDZ MAZE

です。

特徴は、このブログのどこかで見た画が使われてるって事でしょうか
タイトルから迷路から、ビットマップは全部、子供の絵をキャプったもので作りました

ザ・親バカアプリ第一弾と言えるでしょう

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にぶらさげまくってると破綻するって事になるので注意した方が良いですね。

てんやのなぞ

(絵と本文は関係あってこれはおれがてんやで天丼なす乗せを食べている所です。もちろんウソです)


てんやではいつもボーカルなしのカラオケがBGMでかかってる

逃亡編

(例によって絵と本文は関係ありません)
前編： herokuでform_tagの:remote => trueが動かない の続き

結論から行くと、なんとかなりました。
端的に言うと

: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を呼ぶようにすればＯＫ

<%= form_tag ("javascript: doPost(\"/sessions/\"") do %>

本当は、:remoteと完全に同じ挙動にするためには以下にしたかった

<%= form_tag ('#', :onsubmit => "doPost(\"/sessions/\"); return false;") do %>

でもやっぱり、form_tagが第二引数を取ってくれないので相変わらずエラーになるので逃げた。

逃げるが勝ち

ゲシュタルト崩壊

(絵と本文は関係ありません)

2012年に5σ、すなわち99.9999%以上の確度での存在が確認されたヒッグス粒子
当時一般にはまだ理解不能の発見と見なされていたこの発表であったが、この世紀の発見は2050年代に有害な副産物を生成しない新たなクリーンエネルギーの発明へとつながり、気がつけば2070年代には先進国も含め世界中にこのエネルギーは普及し、全人類がその恩恵に預かっていた
だが、一部の科学者達はその世界的な普及に比例するかのごとくある不安を増大させていた
それはヒッグス粒子発見という世紀の発表に沸くわずか3年前、無名の宇宙物理学者ゲシュタルトが発表したある論文、
エネルギーの崩壊に関する論文であった
簡単に要約すると、以下のような内容である
我々地球人は、今まで自然に存在するものをなんらかの反応でエネルギーに変換し、利用していた
宇宙規模で普遍的に存在する現象、つまり燃焼、移動、電磁気、ひいては核反応も含め、これらの方法で生成された場合は均衡を保っているエネルギーだが、それ以上の変換効率を持つエネルギー変換を行うことで、生成されたエネルギーはある条件下で連鎖的に崩壊するような現象を起こす、という既知の数学理論を元にしたある種の予想であった
当のゲシュタルトはその論文を発表して1年もなく学会から姿を消し、誰知らず失踪してしまう
そもそも学会にまともに扱われる事もなかったこの論文、多くの学者達には見向きもされなかったが、何か感ずるものがあった一部の学者達はこの論文を何度も検証した
しかし2070年代まで論理の破綻や反証事実が見つかる事はなく、あろうことかある若い数学助手によりこの予想は証明されてしまう
だがその事実すら学会にまともに扱われる事はなかった

そして207x年、ゲシュタルトの予言したエネルギー崩壊は現実のものとなる

超エネルギー消費社会となった207x年、突如エネルギーの供給源が消える事が何を意味するか
文明とはかくも脆く崩壊するものなのか・・・


ごめんなさい。ゲシュタルト崩壊って言葉が厨二ワードっぽいんでつい

ゲシュタルト崩壊ってのは、ある単語（「あ」とか「家」とか）ずっとそれ見たり書いたりしてると、「あ」ってこんなんだっけ？「家」ってこんな文字だっけ？これなんだっけ？みたいなちょっと混乱して変な感じになる現象の事です。

ふつー

名前負けー

リンクはんのもかったるいんで適当にWikipediaで検索してください

っていうのは冷たいんで ほらよ
やさしいな俺

ソフトエンジニア？マネージャー？

(絵と本文は関係ありません）

自分はいわゆるソフトエンジニアです。フリーではなく会社に所属しています。

若手時代はオブジェクト指向やらデザインパターンやらを勉強しつつガリガリ設計、実装を行い、その辺の経験を一通りしたあとはリーディング、外部管理、仕様管理、というような(恐らく)非常に典型的なキャリアを通ってきました

で、今、次にどこに進むべきかという事を考えています

タイミング的にはマネージメントの方向に進んでいくというキャリアが会社的には妥当なんだと思います

ただ、流れといえばそうなんでしょうが、十ウン年磨いたスキルをあっさり捨ててマネージメントという新たなスキルを一から磨く、というのは本来ならば大きなチャレンジであり、決断が必要です。自分の強みも理解せずにただ流れに乗るようにそっちに転向しても溺れますよね普通・・・
そもそもエンジニアになったのも、ソフトが自分の強みだと思ったからですし

またこれはうちの会社だけの特徴なのかもしれませんが、いわゆるマネージメントの人数が多すぎるように思います。一方でソフトに直接関わらない人達が増え、組織としての技術力が右肩下がりとなり、それに伴って自身のスキルも鈍ってきているように感じます

という事もあり、こんな状況下でマネージメントの方向に進むのって会社ありきという印象をどうしても持ってしまいます。これから時代、個人のスキルを常に磨いていないとほんと路頭に迷いかねません

という事もあり、今は迷いつつもやはり今まで磨いてきたスキルを軸足にして、エンジニアとしてスキルアップしていく方が良いんじゃないかと思っています

まあ海外への大量の技術流出が進んでいる昨今、高いコストの日本でエンジニアを続けるのも茨の道なんですけどね・・・でもやっぱり何も無いところから何かを作る技術は日本はまだトップレベルですし、そういう所でがんばるしかないかなと思っています

よくキャリアは山登りに例えられます

なんでもかんでもというのは無理で、登る山を決めたら少しづつ着実に上を目指す、という姿勢が似てるって事なんでしょうかね

今の自分は山の中腹まで登ってきて、上を見たらなんか角度が急になってるー
しかも一方で他の(今までとは違う雰囲気の)山の麓へのリフト乗り場があるー

という場所に来ているようです

急勾配そうですが、まだこのまま今の山を登り続けようと思っている、という感じです

では、今後さらに急になる山をどうやって登り続けるのか？というあたりはまた後日のネタに

Androidアプリ開発小ネタ

(絵と本文に関係はありません）
ちなみに「これ、羊なの」だ、そうです


さて、Androidアプリの世界では

• 無償版。Free。機能制限 and 広告有り
• 有償版。Full機能 and 広告無し

というのは結構定番ですよね

今回は、アプリ開発の観点から、上記をスマートに実現する方法を考えます

(ググっても良いやり方が買いてあるブログ、サイトが見つけられなかったので・・・)

通常、これらのアプリは別アプリとしてMarketに置かれています

よってPackageとしては別になります

そのため物理的に一つのソースコード(.javaファイル)を共通して持つ事はできません。Javaは実装毎に自分がどのパッケージに含まれるのか明記が必要だからです(という理解です)

一方、有償、無償、双方に共通の機能は共通の(ひとつの)実装にしたいと普通は考えます

Java、Android開発の経験が浅かった事もあり、また実質開発終了していたため、以前は真面目に考えずコピーして済ませてしまいました

今回はまだ公開前という事あり、ちゃんと考えてみました

ちなみに現時点ではまだ机上検討レベルで未確認です

実装してみて課題や解法見えたら、またここに追記したいと思っています

ポイントは継承です(今考えるとすげー普通)

その1

1. 有償版(広告無し)を実装
2. 無償版は有償版のMainActivityを継承 (importで有償版のパッケージを指定する事で可能になるはず)
3. 無償版Activityで広告viewの追加およびlistener回りの処理を追加。また機能制限されているものは蓋をする(この仕組みは有償版に入れておく必要あり)

その2

1. 無償版(広告有り)を実装
2. その1同様、有償版は無償版のActivityを継承する
3. 有償版のActivityでは広告表示を停止する。また必要な追加機能等をactivateする(同じく無償版は有償版限定機能も実装しておき、蓋をしておく必要がある)

ただし上記その1、その2では親クラスとなるActivity(およびパッケージ)が、本来そのパッケージには関係の無い機能を(蓋をするなりして)有しているという事になり、デザイン上はあまり好ましく無さそうです(まあ、個人開発のレベルでは問題にならないと思いますが)

よって、理想的には

1. 無償、有償で共通な機能をcommon packageで実装する
2. 無償、有償それぞれがcommon packageを継承したactivityを作成
3. 無償、有償それぞれにそれぞれ必要な機能を追加する

ですね。common packageはいわゆる.apkを生成する必要はなく、未公開という事になります。

まずはこれで今作ってるやつ実装してみます

改竄

というわけで早速、前回の絵を加工してみた

と、言ってもスキャナで取り込んだ際に裏のページがうっすら入り込んじゃっているのが気になったので、消してみただけ

編集はGIMPです

あらかじめ宣言しておきますが、GIMPなんてド素人です。インストールして一ヶ月経ったかそこらです。勉強中です

もっといい方法、定番のやり方があるかもしれませんね

1.　[ツール]>[色域を選択]で背景色（ノートの白の部分）を選択、[しきい値]を変えて写り混んだ色は選択され、絵の部分は丸々非選択になる（線の中に選択領域が入り込まない）、という辺りをさぐる

2. [選択]>[選択領域を反転]してから[選択]>[クイックマスクモード]でモード変更、背景部分(絵じゃない部分)をピンクに塗っていく

3. 納得いくクイックマスクが作成できたら、[選択]>[クイックマスクモード]でクイックマスクモードを終了し、ここで[選択]＞[チャンネルに保存]しておく(念のため)

4. 再び[選択]>[選択領域を反転]、[編集]>[切り抜き] (or [コピー])、[編集]>[貼り付け]として絵をフローティングレイヤ化。そしてレイヤーダイアログで[新規レイヤーの作成]を実行、フローティングレイヤ化した絵を別のレイヤーに移す

5. レイヤーダイアログでオリジナルの絵があったレイヤの左側の目のマークを消し、レイヤを不可視化。これで編集画面上は元の絵が透明領域の中に書かれている状態になる

6. レイヤーダイアログ上で、別レイヤー化した絵の直下で[新規レイヤーの作成]を実行し「背景」と名前付ける。一旦全面透明で作成。

7. レイヤーダイアログでオリジナルの絵を一時的に可視状態にし、[ツール]>[スポイト]で背景色としたい色（裏のページの色が入り込んでない部分）の色を吸い出す。でオリジナルの絵はまた不可視に戻す

8. [ツール]>[塗りつぶし]を使い、吸い出した色で「背景」レイヤを全部塗りつぶし

で、裏のページの映り込みは消せました。

手順で書くと一見複雑に見えますが、やってる事は結構シンプルです。

もうちょっと自然にやるには、8で背景レイヤを単色塗り潰しにせずに、再度写り込みが無いようにまっしろの紙をスキャンしてその画像を背景レイヤに使用する、という手もありますね。

っていうかそもそも、もっと良い方法ないのか？？？

子供の絵

ブログを始めようと思ったきっかけの一つがこれ

3歳なりたてのうちの長男はらくがきちょうでお絵描きするのが好きです

ちょっと前までただのぐちゃぐちゃだったのが、最近はけっこう印象的で面白い絵を書くようになってきました

でもらくがきちょうがいっぱいになるとママはけっこうあっさり捨てちゃうんですよね

ちょっと思い出的にもったいないなぁと

で、キャプる事を思い付きました

だったらいっそネットに上げちゃおうと考えた結果、一番良い形式はブログかなぁという事でブログを立ち上げる事を考え始めました

(冷静に考えるとキャプチャ作業かったるいし、モチベーションにもなるかなと)

GIMPの加工素材にも使えそうだな