@MiraiNagato 同じ事考えてた
不謹慎かもしれぬが、そういうときにSuicaにどんな値が書き込まれるのかに興味がある系男子がこちらになります
一度読んだカードのデータを保存しておいて随時表示できるような機構を提供しようとしたら、どんなUIがありえるだろうか
震源は深さが590kmか。凄い深いな。マントル内部ではないか。
M8.5ってのはマジなのか。 しかも震源が深さ100kmとか。 この深さでこの規模って聞いたことがないな。前代未聞では。
今日は撮ってないけど、いつもどおり、タンドール料理のほかにチリポークが付いている。 中華料理の影響受けまくりの炒めもの。
トマトなスウプ、とても美味しいです。 トマトが苦手な人にもオススメ。健康にもいいし。
てうどよい乗合自動車が無かつたため、店まで歩いてゐる。 大変腹が減つてゐる。
メニューはだいたい定番で、奇抜なものはあんまりない。 ディナーのセットメニューも撮影したはずだけど見当たらないから今日撮ってこよう
とりあえず処理が大幅に書き換わって、どんなバグが練り込まれたか分からん。とりあえず新しく入手したカードも含めてとっかえひっかえ読み込ませて、いろいろバグ出しと修正は終えた気分。
カラムーチョのあと、「すっぱムーチョ」「あまムーチョ」まで登場している。 からみは味ではないが、酸味と甘味は基本味のうちの二つ。基本味をストレートにやるならば「しょっぱムーチョ」(塩味)と「にがムーチョ」(苦味)も必要では？とても売れそうにはないが… そもそも「ムーチョ」って何だ
ミドリムシって、どう考えてもこういうものを連想する。 google.co.jp/search?hl=ja&s…
電子マネー付きの会員カードみたいのは、どちらをメインにするべきなのだろうか
全てのカード種類を平等に扱うのはやはりおかしくて、メインとなるもの、サブとなるものがあるから、ArrayListはやり過ぎて、やはり配列っぽくした方が現実的だな。[0] がメイン、[1以上]がサブ的な管理方法。
大阪(big slope)から目黒(eye black)に行こうとすると、new幹線で品川(goods river)まで行って、そこからmountain hand lineに乗り換えれば良いらしい。
某はあらゆる事態を想定しすぎてさっそく開発が中断している。 まともに作ろうとすると億円単位の予算が必要と分かった。
メイン、サブ、あたりで複数の番号を持てるようにするかな。次善の策だがたぶんこのくらいで充分だろう。
考えられる方法としては、カード種類を表わす内部的な値(enum)、名称（String)等をクラスにして、これをArrayListとかで管理するのがあらゆる事態に対応できる最良の方法だろうとは思うが、そこまでマルチユースなカードは今のところないし過剰な実装に思う。
1枚のカードに複数機能があることを前提として、カードの種類を表わすあたりを配列にして管理したほうがよいのだろうか。すっごい面倒そうだなぁ
スマホの歩数計機能によると、昨日は15906歩も歩いたらしい。歩きすぎ。
