  |
はてなキーワード: iアプリとは
当方今年で35歳になるんだが、高校の時にプログラミングにハマってクラスの掲示板を作ったり英単語帳iアプリを作ってクラスメイトに使ってもらってた。
その時によく言っていたのが「自分はマニアであってもオタクじゃない」という言葉。容姿的には今でいうオタクファッションだったとはいえ普通の男子高校生だったので、たまに「オタクだから〜」みたいな自虐をしても「いやいや増田くんはオタクじゃないっしょ（笑）」という感じで、オタクという言葉のイメージはすごく悪い印象の言葉だったことを覚えている。
それが変わったのが大学時代にニコニコ動画が出てきた頃で、さらにそのクリエイターたちが活躍し出してから自分より若い年代では、オタクという言葉がステータスに変わっていった気がしている。
それでも自分は昔の感覚が抜けず、オタクは世間一般から隠れて生きるものだという刷り込みもあり、オタクっぽい言動をしたくない自分がいる。
この辺りの感覚は数年の差で違うと思うし、初めてインターネットに接した時期でも違ってくると思う。
10年超のプログラマやってるものだけど自分の成長過程を書いてみよう
タクシー配車アプリ「JapanTaxi」について、乗務員視点でどうなのか書いていく。東京（特に日本交通グループ）の話が中心なので、他の地域の方には申し訳ない。
anond:20180927184434 に書いたことは説明を省略しているので、こちらもどうぞ。
アプリ配車のシステムはお客様・乗務員いずれの視点からも導入当初より改善された。一方で、不心得な利用者には冷たくなった。
「全国タクシー（後のJapanTaxi）」が登場した当初は、お客様が配車を注文した後、【①アプリのサーバー】【②各社の配車サーバー】【③タクシーの車載器】、の順に情報が送られ、配車が行われていた。ただしこれではお客様にご迷惑をおかけするだけでなく、乗務員から無線室への苦情も多く寄せられる状況が続いていた。問題点は以下の通り。
この方式はタクシー車両ごとの設備改修を行う必要がないという利点こそあったが、トータルで見るとデメリットの方が大きかった。これらは労働組合がたびたび改善の要求を出していた。それだけでなく、旧来のシステムにアプリ配車まで対応させるというやり方では、後発のMOVやDiDiなどと競争できなかった。
そこで、アプリのサーバーと各車両が直接つながった、アプリ配車専用のシステム（を搭載したタブレット）が導入されることになる。ただしMOVやDiDiはこの時点で既にこの方式を導入しており、JapanTaxiは国内では先発だったのに結局出遅れたことになる。もっと言うと、Uberはアメリカで事業を開始した当初からこの方式だった。
アプリ加盟会社で1つのシステムを汎用的に利用でき、迅速に配車を決定できるというメリットがある。
2019年の1月に「JapanTaxi Driver's（以下ドライバーズ）」という乗務員向けのシステムが開発され、1年ほどかけて都内の日本交通グループ全車両に導入された。帝都自動車やイースタンモータース、また他県事業者などといった従来からのJapanTaxi加盟社でも導入が進んでいる。これで、注文から配車成立までを同じJapanTaxiサーバーで行う（＝各社の無線システムを通さず各車両に直接配車要請を行う）こととなり、先述した問題はかなり軽減された。（同時にGPS取得精度も改善され、逆から呼ばれることは少なくなった）
導入はJapanTaxi㈱が予めアプリをインストールしたAndroidタブレットを加盟各社に販売するという方式で、DiDi等も同じである。
JapanTaxiはUber方式では出遅れたが、後発の利を生かして「複数台に配車要請を行う」というシステムを取った。いずれの方式でも、コンピューターが最適と判断した1台を決めて配車要請を行うことには変わりないが、実際はその判断が正しくないこともあり、何らかの理由で配車要請が無視されることがある。こうなると、車両決定までの時間が延び、お客様にご迷惑をおかけしてしまう。何台かに配車要請をすればどれか1台は受けてくれる＝お客様視点での成立率はほぼ100%になる…という具合である。
これまでは【配車要請→了解→迎車進行】という流れだったが、ドライバーズの場合は【配車要請→了解→当選→迎車進行】となった。
車種よって違うが、ジャパンタクシーの場合は運転手から見て左に通常のカーナビ、右にドライバーズが設置されている。普段は通常のカーナビだが、配車要請が届くと通知音が鳴り、画面に大きく「了解」ボタンが表示される。ただし先述の通り複数台に同じ配車要請が届くため、一番早く了解ボタンを押した人が配車成立（＝当選）となる。了解しても当選しなければお客様の情報は確認できない。ドライバーズに送られてくるのはアプリからの即時注文のみで、電話注文や時間指定予約などは従来の配車システムで届く。
無視してもペナルティはないため、渋滞していたり右左折の途中でお迎えに上がれなさそうなときは他の車に任せるつもりで気軽に無視できるようになり、乗務員、お客様共に負担は軽減された（と思われる）。ちなみに当選数にかかわらず了解数が多いとインセンティブがあるが、割愛。
通知が届くのは、5～7分以内にお迎えに上がれそうな車のうち4台前後だが、繁華街など車両密度が高い地域では早押しに関係なく一番近い車に決まると噂されている。周辺台数が極端に少ないと、アプリ注文でも従来の配車システム（＝乗務員は原則無視できない）に回される。ドライバーズ経由で配車要請がかかっても全員無視すると、お客様にはもう一度アプリを操作して頂く必要がある。
何としてでも無線を取りたいがあまりに、ドライバーズタブレットに連打器を付けて早押しに勝とうとする人まで出て来たが、正式に禁止された。（連打器＝もともとスマホゲームでズルするために使うもので、SMATCH http://www.zaurus.jp/special/smatch/ が有名。）
事故ったとか、目の前に手を挙げている人がいるとかの他にも、色々ある。（注：アプリ注文も電話注文も「無線」です）
とはいえ、繁華街の無線は長距離利用も少なくないし、会社の方針を尊重する聖人、蓼食う虫になる人、クレーム万歳な人、色々いる。時間帯やその時その時で判断は変わってくる。私も歌舞伎町絡み以外は基本的に全て了解している。
以前の記事でも槍玉に挙げた「必着スマホ配車」は値上がりした。従来、時間を指定して注文する場合、追加料金はアプリ予約が420円（即時注文と同じ金額）、電話予約が840円となっていたが、今年の4月からアプリ予約でも840円となった。
アプリ予約が嫌われていた理由は以前も挙げたとおりだが、要は1乗車にかかる時間に対して営業収入が低く、かなり効率が悪かった。時間指定予約は20～30分前から車を拘束するのと、JapanTaxiアプリでは日本交通しか受け付けていなかったため（他社は合意が得られなかった）、朝は車が足りなくなることが多かった。しかも迎車料金込みで1500円を下回る利用も相当数あり、会社としても結構な損害になっていた。更に、これが嫌で朝は無線を無視する乗務員も多くなるという悪循環に陥っていた。
アプリ予約を840円にすることにより、即時注文への誘導を図る狙いがあったと思われる。即時注文であれば1乗車の拘束時間が減り、日本交通以外の車も呼べるため、キャパに余裕が出る。また、ある程度拘束時間に見合う金額となるため、無線を無視する人も減ると思われる。
もう一つは、お客様が予定時刻に現れなかった場合、これまでは連絡が取れなくても20分までは待つということになっていたが、これが10分に変更された。この話はJapanTaxiというより日本交通だけの話になるため、割愛。
これといったオチはない。
タクシーアプリも人口に膾炙してきたのか、導入当初のようなトラブルは減った。また、アプリの利用者は明らかに増えており、無理に都心の繁華街に居座らずとも、流しでは確実に乗らない郊外でも十分仕事が成り立つようになった。都心での営業が確かに最も儲かるが、狂客との遭遇、空車同士の競い合いも多く、心身がすり減らされる。かといってそれを避ければ生活が傾く訳だが、郊外におけるアプリ配車がその間のちょうどよい落とし所となってくれた。特に今般のコロナ騒ぎでも収入の下げ幅を抑えられているのは、郊外でアプリを利用してくださるお客様のおかげである。
こういうやり方はベテラン乗務員には嫌われがちだが、わざわざ港区に行って週一で癇癪持ちにエンカウントするのは私には無理なのでこうしている。このやり方を続けるには、お客様にまたJapanTaxiを利用していただく必要があるが、私に出来ることといえば、積極的に了解して配車不成立を減らし、お客様に不便な経験をさせないことと、そして接客や地理知識を磨くことである。これらの循環でお客様に喜んでいただければ私も安心するし、心身共に健康な状態でこの仕事を続けることができる。（了）
私、７＆ｉのアプリを使っていたのですが、PWを強制リセットされたために利用できなくなり、アプリを利用しなくなったものの一人です。
なぜ利用しなくなったのか？
本当は利用したかったんです。
ほぼ月一くらいですが、セブンイレブンでスキャンサービスを利用する際に、アプリを使っていて、自宅のスキャナが古く新しいPCに対応できなくなってからはずっと使っていました。
が。。突然のPWリセット。
ちなみにセブンペイでしたっけ？あれは利用したことがないです。登録してもいません。そもそも「それが何か？」をも把握しておらず、、、さらに、そもそも登録が必要だったのかもわかりません。
まず、なぜアプリを利用しなくなったのか？
＝＞ 理由としてはPWの再設定方法が分からなかったからではなく、PWが再設定できなかったからです。
１、PWの再設定に生年月日まで要求された。
真面目な人は自分の生年月日を正直に入力するのかもしれません。
しかし、個人情報が流出している事件・事故は枚挙に遑がありません。私、生年月日を正直に入力はしないですw。一応年度またぎの3月吉日か4月吉日で登録していますが、いかんせん永遠の18歳である私はいつこのアカウントを作成したかを覚えていませんw。。
それに、もしかしたら、別の誕生日を設定したかもしれませんw。もしかしたら利用規約に生年月日に嘘ついたら使わせないという文言が入っていたかもしれませんが。。。それを私が読んだと思うのか？
２、UUIDが取られていて、同一UUIDには一つのアカウントしか紐づけられない。
１、でダメだったのでじゃあ新しいアカウントを登録しようと思ったのですが…登録できなかった。。。
アカウントの乗っ取り防止という意味では強固な対策の一つかと思います。スマホが中古で流通し、それで登録できないとか、そういうケースへの対応はいくらでもできるので(引き継ぎ端末でのUUIDだけを参照するなど)ユーザーが多額の課金をするようなゲームアプリでは意味がある対応かもしれませんが。。。たかだか、コンビニのアプリ、どれだけユーザーの個性が必要だったのでしょう？スキャンサービスだって、ワンタイムトークンで対応できたでしょ？無駄に個人情報を収集して、他社に売らないまでも利用しようとしていたんじゃないでしょうか？
非常に強固な作りになっているアプリだと思いますが、too muchだとも思います、
わざわざ数千万〜数億払って広告出さなくてもどちらか解除すれば済む話です。というか、どんなに広告出してもUUID取られている時点で、アカウントを適当に登録したユーザーは２度と戻っては来れないですw！！！
これで多くのユーザーがiPhoneを乗り換えて、新しいUUIDを取得すれば、ワンチャンユーザーが戻ってくるかもしれません！！ワンワン！！
嗚呼悲しきsilent minority…。
文責：U2FsdGVkX192EVuo5bhwAb6WE/b8UTlZqRs5dbhgxSQcdAIvMJZyGeia2uRpbLjhr6DU/nKBQQcRg9uOzTRhtEuPIcNWZTAYwJlBa8Z3L2xeCBDeZpPqJAnljm28c2X3
JapanTaxi（全国タクシー）について書いた元エントリ（anond:20180927184434）に知らないうちに結構な反応があり、驚いている。要旨がよく分からないというコメントもあったが、要は「会社は乗務員に清貧を求めすぎだ」「アプリで無線配車の回数が増えた」ということである。字数制限で書けなかった。この記事は元エントリの補足が中心で、今伝えたい要旨はない。
乗務員一人だけの車内では、混雑時に無線が来る度に「おい！こんな無線よこすなよ！」「長距離だ！キャンセルするなよ！」という具合で阿鼻叫喚。しかし、短距離だろうが長距離だろうがお客様は皆、何らかの事情があって弊社のタクシーを利用していただいている。お客様と対面するときは、笑顔でやっている。サービス業にありがちなことだが、やはりあまり裏表があるのは望ましくない。
日本交通は、乗務員が心からの笑顔でお客様をお迎えできるような待遇を、乗務員にしていない。別にサービスを売りにしている訳でもない会社とあまり変わらない待遇である。これがよくないのだ、というのが私の意見である。
サービス業に限らず、どんな業界でも、上と現場の間で齟齬は起きているはずである。日本交通におけるそれが、無線配車と運転手の関係だ。もちろん私達もお客様のために必死。お互いが気遣い合って、一度一度の乗車を気持ちよく完了させられれば、もっとこの業界も良くなるはず。運転手にかかるストレスが少なくなれば、お客様が感じるストレスも減っていくかもしれない。
そこで、アプリをよく利用される皆様のために、双方のストレスを軽減できそうな裏ワザっぽいものを紹介する。注文の段階になると「場所詳細」というボタンが現れ、そこに色々書くことができるということは元の記事でも伝えたが、これを利用する。
実際にこのメニューを開くと「建物名」「付け場所」と出てくるが、別にそれ以外のことを書いても大丈夫である。ここでは、電話予約の際に無線センターがお客様から承った依頼を乗務員に伝える際の言い回しを紹介する。ただし、記入欄1つにつき、字数制限は15文字。
こういう時は「乗降時ドアサービス不要」もしくは略して「ＤＳ不要」と書くのがよい。全角なのがミソ。やり方は色々あるだろうが、自分がタクシーを呼ぶときは迎え先の欄に「車内待機」、目的地の欄に「ＤＳ不要」と書いている。
お客様が来るまで車外待機し、お客様の乗降時にドアを外から開け閉めするサービスは、日交のマニュアルで指定されている。これを社内では「ドアサービス」と呼んでいるが、実際は降車時にお客様が「中から開けてください」と言ってくれるのを期待している乗務員がほとんど。
アプリに表示されている時間はアテにならない。15分とか20分とか表示されていても、実際は行こうと思えば10分以内で行ける。そこで、「時間調整不要」「時間調整禁止！」と書くと、よほど混んでいない限りはアプリで表示された時刻より5～10分くらい早く来てくれる。乗務員にとっても、時間のロスが減るため、かなりありがたい要求である。
実際の所、指定された時間より早く来てもほとんどのお客様は指定された時間（もしくはそれより後）にしか出てこないため、乗務員はそこら辺を遠回りするか、コンビニに寄って飲み物を買ったり車内を片付けて時間調整をすることが多い。お客様の方からそれをせずにさっさと来てくれ！と言っていただければ、乗務員も喜んで急いで行く、という訳である。
配車のアルゴリズムがどうなっているかは知らないが、実感として自分がいる場所と同じ町内には呼ばれないことが多い。例えば、「新宿区新宿」を流している車には、「新宿区大久保」や「渋谷区代々木」からの配車依頼が飛んでくる。空車が少ない地域では100mも離れていない場所から呼ばれることもあるが、レアケース。
https://i.imgur.com/yGMi2rt.jpg
↑の画像でも分かる通り、情報ひとつはカギ括弧の中に収められ、全角カンマで区切られている。これを利用すれば、車載器に自然に反映されるようになる。もちろん、気にしない人は分かるように書いて頂ければそれで大丈夫。
例えば、「新井薬師前駅」に「南向き」で待機してもらい、かつ「ドアサービス不要」「時間調整不要」ということを伝えたいのであれば、2つある欄のそれぞれに
新井薬師前駅」，「南向き
と入力すれば、車載器には4つの情報が送信されてきたように見える。もちろん1つの枠につき15文字の制限は守る必要がある。
https://i.imgur.com/v49tBy5.jpg
アプリ配車だと伝えられる事項が限られるが、電話配車だと↑の画像のようなこともできる。
パターンは様々あるが、建物の色や入り方（バック入庫が必要な場合）、寝坊してしまったときの対処など、細かく注文したいときは、電話で無線センターのオペレーターに伝えた方がいい。どんなに長々とした要求でもしっかり車載器に届けてくれる。
たぶん新型車（ジャパンタクシー）に乗りたい人が多いと思われるが、アプリだと「黒タクのみ」「黒タク優先」となぜか「プリウス」の3種類しかない。これ以外の選択肢は電話でしか指定できない。
ちなみに前述の場所詳細欄に「ジャパンタクシー希望」と書いても意味はない。ジャパンタクシーを指定したい場合は、無線センターに電話で連絡することになる。自分も何度か電話予約のジャパンタクシー指定無線を受けたことがある。ワゴン車（エスクァイアかアルファード）も電話でしか指定できない。
荒技として、「ＪＰＮ ＴＡＸＩ以外は代車要請」と詳細欄に記入する方法もあるが、代車要請をするとアプリに正しく車両の位置が表示されなくなる（らしい）上、朝はいつまでも車が決まらなくなるため、要注意。代車要請とは車載器のメニューに表示されているボタンの名前で、その名の通りたらい回しされるものである。基本的には事故などどうしようもない状態の時に押すもので、何もないときに押すとその乗務員はクビになる。
何もしなくても無線は黒タクに多く回されるシステムになっているのだが、多少時間がかかってもいいから黒タクに来て欲しいというときは「黒タクのみ」「黒タク優先」のいずれかを選ぶ。車両そのものは色が違うだけで何か特別な設備があるということはないが、乗務員の質が違う。
日本交通を多く利用されるお客様はご存じだと思われるが、社内で基本的な研修とはまた別のサービス研修を受けた乗務員が黒色の車両、すなわち黒タクに乗ることができる。つまり、サービスレベルがより一層高く、ドライバーが新人であれこれ説明しなければいけないということもない…はずなのだが、黒タク資格を得られるかどうかは勤続年数よりも日頃の行いや本人の希望に依るため、乗務経験が1年程度の人が黒タクに乗っていることもある。
ちなみにジャパンタクシーは全て黒（紺）色の車体だが、行灯の「桜にN」の図柄が金色のものが黒タク扱いで、青色のものが黄色と同じ扱いである。つまり、黒は黒でも行灯が青のジャパンタクシーには新人が乗っている可能性があり、目的地を告げた瞬間に「大変申し訳ございません！新人でございます。道のご案内を…」と元気よく告げられるかもしれない。クラウンやセドリックは、黒タクでも行灯の図柄は青色。
別名「四社カラー」。日本交通グループ以外では、km（国際）、大和、帝都も同じ色。いわゆる普通のタクシーである。何も特別なものはない。前述の通り、ジャパンタクシーのうち青行灯の車両も黄タク扱いになる。これをわざわざ指定する理由はないが、無線センターに言えば指定できる。新人ならではのフレッシュさを味わいたい方はどうぞ。1年未満の乗務員は後ドア横に「新人」のステッカーを貼っている。
ちなみに、この車に乗っている乗務員が全員新人かというとそういうわけでもなく、黒タク資格を持っていても車両繰りの都合で黄タクに乗せられることがある。あとは、黒タクならではの縛りが面倒という乗務員は、何年勤務していようが会社から後押しされても固くなに黒タク資格を取らない。
この選択肢があるのがよく分からないが、たぶん一時期のプリウスブームに乗じた物だと思う。実は去年までいっぱいいたのだが、ジャパンタクシーが登場してから急激に台数が減り、グループ全体を見渡してもプリウスはほとんど残っていない。つまり、これを選ぶと高確率で配車に失敗する。自分が把握している限り、プリウスは三鷹営業所とグループ会社の東洋交通に数台ずつしか残っていない（いずれも黄タク）。同じくグループの春駒交通には黄色のプリウスαがいる。
ちなみにプリウスは四隅のサイズが無駄に大きいため、乗務員からの評判がすこぶる悪い。
別に、これでアプリを利用するお客様が萎縮する必要はない。乗務員に良い無線・悪い無線というカテゴライズをさせる会社が悪い。ぜひ、今後も通常通り使って頂いて欲しい。短距離でごめんなさい…と思う必要は別にない。実際は短距離の方が多いし、乗って頂けるだけでありがたいのだから。さすがに無線で410円とか570円は辛いけど。
どこからを長距離とするかは乗務員によっても違うが、4000円（10キロ）を越えると長い部類に入る。10000円を超えると「万収」と呼ばれ、営業所に帰ったあと他の乗務員に自慢できる。
お客様が来るまでにどうやって行こうかな～というのをじっくり考えられるため、心理的負担が少ない。無線のシステムはカーナビと連動しているため、新木場営業所の乗務員が二子玉川まで来て、そこで無線を拾ってしまっても、目的地が設定されていればワンタッチでカーナビをセットできるため、お客様に延々と道を聞き続けて手間をかけさせてしまうようなことはなくなる。短距離でも許せる。
別に長距離に限らず、空車で延々と走るハメになりそうな状況を埋めてくれればいいのである。いま流行のライドシェアの真髄もここにあるのではないだろうか。
例えば、23時頃に銀座から竹ノ塚までお客様にご乗車いただけたとする。比較的長距離なので嬉しい。しかし、0時を過ぎて竹ノ塚から都心への帰り道でお客様が手を挙げそうな場所はそうそうなく、下手すると上野かどこかまで10キロ以上空車のまま帰ることになる。これでは都心で1000円前後のお客様に何度も連続してご乗車いただいたのとあまり変わらない。（そんな時でもお客様を見つけるのがタクシードライバーの腕の見せ所ではあるけれども）
そんなときに西新井→千住と、千住→浅草の無線を立て続けに引くことができれば（そんなことは普通ないが）、それぞれ2000円も行かないかもしれないが、空走りの距離を減らすことができ、結果的に効率は上がる。なぜか世田谷区でよくある。
あくまで代表的な例であって、大泉以外にもこういう場所がたくさんあることは認知している。日交のタクシーは都心に集まるが、例えば世田谷区や目黒区は都心から直接乗り付けてくる人が多いため、アプリで呼ぶとそこから都心に帰ろうとする車が捕まることが多い。しかし、大泉を始めとする練馬区西部は都心からタクシーで乗り付けるとかなり高額になるため、そうでもない…ということである。
大泉近辺でタクシーが集まるのは吉祥寺だが、吉祥寺でも遠いし、あの辺はあの辺で忙しい。日交グループの車もそんなにいないため、JapanTaxiアプリだと捕まらない。
そもそも日本交通は乗務員に都心で営業することを勧めている（実際に都心で営業した方が売上はいい）ため、郊外ではJapanTaxiアプリではなく、東京ハイタク協会の「スマホdeタッくん」を使った方がいいかもしれない。日交は営業所が千住だろうが三鷹だろうが都心にガンガン出ていくが、中小は郊外ローカルで気ままにやる人が多いのが背景にある。
以前ある乗務員から聞いた話では、三鷹営業所では「世田谷番」を設定し、都心に出ずに世田谷区内を中心に営業する乗務員を日ごとに決めていたそうだ。これで需要が多いにもかかわらず日交の営業所がない世田谷区内の需要にもくまなく対応できいたが、営業補償があったかどうかは知らない。ただ、世田谷に営業所を置く飛鳥交通が東京無線から日交にのれん替えしたため、今はないと思われる。
底上げ給を設定してくれるのであれば、一日中郊外の特定地域に居座っていた方が乗務員にとっても気は楽である。都心のピリピリした雰囲気に巻き込まれず、営収を追う必要もそんなになくなり、駅まで・病院までの短距離乗車だって笑顔でこなせる。銀座の金持ちを狙うばかりがタクシーの社会的責任ではない。
配車アプリでUberの進出を防ぐという目標があり、それをタクシーを生業とする自社の社員に担ってもらうのであれば、こうでもして各地域まんべんなく配車が成立する確率を高め、より一層お客様に満足していただけるよう取り組むのが筋ではないか。
アプリを開発したJapanTaxi(株)は、日本交通の100%子会社で、アプリ以外にも無線システムや車載器、あるいはクレカ/電子マネー決済機を開発している会社である。どちらかというとITベンチャーの部類に入る。なぜこの会社が優先配車の980円をもらっていくのかは謎。アプリとお客様は悪くない。会社が悪い。
■初めに
■筆者について
にゃんこ大戦争で、タップジョイ（TapJoy）関係の無料ネコカン（※1）の受け取りが繰り返し実行（※2）される。
※2 発生トリガは複数り、タスクキル（アプリ再起動）で意図的に発生
iTune版「にゃんこ大戦争」Version 6.0.0 （配信日：2017年4月24日）
他プラットフォーム（Android、携帯版、3DS版、海外版）、他バージョンでは未発生
■不具合発生時期
Version 6.0.0の開発において、無料ネコカン関係の機能にデグレ（バグ）が発生
ただし、配信数日後から不具合顕在で、他トリガも存在と推測される。
＜推測１：サーバ説＞
無人管理状態に移行させるためのサーバ設定変更（TapJoy側・ポノス側のどちらかは不明）起因
サーバ設定ではなく、サーバからの配信データ（広告・インフォメーション（画面右上の○i）等）起因
② ネコカンに関する仕様に関し、会社間（ポノス・TapJoy）の情報共有が不十分
③ 社員休暇中のインシデント対応（特にインシデントレスポンス）が不十分
■今後の対処（例）
(1) 不具合事象抑制の暫定対処の実施。ネコカン増減関係の機能（ガチャ・統率力回復等）限定停止やサービス全体の一時停止など（緊急メンテ）
(2) 不具合解消バージョンの開発（Version 6.0.1）と配信。バージョンアップ実施はユーザ側選択となるので、6.0.0以前のバージョンは(1)による機能orサービス停止にてバージョンアップを促す。
(3) 不具合利用による意図的なネコカン増殖（線引きは11連×3回＝4,500ぐらいなど）実施ユーザに対してのBAN実施。BAN実施対象のうち、ロールバック同意者に対してロールバック実施（ロールバックデータを新規インストール＆データ引継機能）
(4) 不具合未発生ユーザへの不具合のお詫び実施（過去不具合以上が妥当、ネコカン30個×n倍 or プレチケ）
(5) 期間限定ネコカン7割引、プレチケ販売（数量上限3）、にゃんチケ販売（数量上限30）など、不具合のお詫び兼販売増の実施
(1)～(5)以外であっても、「傷口が広がるのを早期に止める」「ユーザの不公平感の軽減」「課金者のモチベーションダウンの抑制」「悪質行為への毅然とした対応」を希望
■最後に
長年楽しみ続けた「にゃんこ大戦争」が今回の件が「終わりの始まり」にはなってほしくありません。
ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。
今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。
「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。
タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー
面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。
Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。
かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日にリリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。
今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。
Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日にオラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」（The Network is the Computer）というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。
当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。
1996年の時点にこんな言語が登場したのですから革新的でした。
いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。
プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロード、テンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。
Wikipediaからピックアップすると1.1での大きな機能追加は
といったところです。当初よりJavaの内部文字コードはUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ！というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。
なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。
当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。
JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアのフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。
Microsoft Visual J++ もこの時代ですよ。
Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。
当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。
この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。
strictfpキーワードは浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。
リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassをロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。
1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。
初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。
JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードにコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。
あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。
Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつがMicrosoftだったわけですね。
Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルはMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの！と喧嘩になったわけです。当時のMicrosoftはブラウザまわりでも独自拡張がやりたい放題、標準規格？なにそれ美味しいの？みたいなスタンスをあちこちで見せていたものです。
結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。
JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。
Java SE とは別にこの時代に Java EEがリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。
2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットのサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的なユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。
企業で用いられる社内システムにもServletは多く採用されました。
理由はいろいろ挙げれると思うのですが
というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャはある意味では便利で簡単でした。
もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。
2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホ、ガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。
そこにdocomoのiアプリ、Jフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ！というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリはちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。
iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。
docomoはiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。
この賭場が、将来にAppleのiPhone, GoogleのAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoはSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。
話を2001年に戻しましょう。
Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。
Java Appletがブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。
Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。
端的に言えば入力値が数字かどうか？みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。
また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。
こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい！という要望があったわけです。Webシステム使いにくい！という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。
Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。
RIAの代表とされるのは
あたりです。三つ巴の戦い、どこに軍配が上がるのか！？と注目されましたが、勝利したのはHTML / JavaScriptでした。
Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。
RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントのひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。
しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。
1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。
Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。
言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。
Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。
Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日にオラクルに吸収合併されました。
Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。
やや戻って2007年にAndroidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。
Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。
このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。
久しぶりにMMORPGをやってみたくなって探してみた。
MMO歴は大昔にテイルズのオンラインゲーム(ウィーバーじゃないやつ、エターニア？)とか、友達に誘われてトリックスターをやってみたりとかしてた程度。
大体どのゲームでも、ある程度レベルを上げたら序盤のエリアや拠点付近に座り込んで人の往来を眺めたり、
街でわいわいみんながやってるのをちょっとはなれたところに座ってじーっとROMったり、
街中を散歩したり、たまに気が向いたらちょっと外に行ってレベル上げをしてみたり、なんとなくできた顔見知りと一緒に初心者のヘルプしたりする感じ。
話しかけられたら多少は返事するけど、別にそんなに熱心にチャットしたりはしない。ギルドとかにも別に入らない。
どうも、現実では煩わしかったり、病気になっちゃったくらいストレスの方が多くなる「人がいっぱいいてザワザワしてる状況」を、画面とウィンドウ越しに眺めるのが自分にはちょうど心地いいらしい。
そんなわけで去年からいくつか探して遊んでみている。iPad持ってるのでiOSとPC。
【iOS】
何にしても全部チャットが打ちづらいので、話しかけられたときに返事ができなくて申し訳ないからメインにしづらい。
・AVABELオンライン
アソビモの稼ぎ頭っぽいタイトル。
キャラクターがみんな頭身が高い、美男美女しかいないけど初期キャラメイク幅はiOSのMMOではそこそこある方だと思う。
でもなんかシルエットが似かよるせいか、どうやっても割とみんな同じに見える……、アバタ―ありきな感じだから別にいいけど。
割とドロップとかでもアバタ―がポンポン手に入るので楽しいし、無課金アバタ―なら結構安値で市場に売られているのでちょっとお金貯めたら買えたりする。
遠距離職でチクチクやってるだけでもなんとかボスとかは倒せるけど俺には結構難しい、罠とかのないモンハンみたいな気分。
人が多く、チャットはクレクレとギルド勧誘と中高生っぽい会話であふれていて活気がある。
転送装置の中で土下座したり灯台に登って焼き土下座したりして遊んでた。
23Fまでプレイしてちょこちょこ知り合いができてたけど、忙しくなったタイミングで一切触らなくなって、なんとなく復帰する気になれなくて凍結。
アソビモの割とあたらし目のヤツ。キャラクターの頭身が結構低い。MMOっぽさはかなりあると思う。
なんか俺にはゲームプレイが全体的に難しくて、バカスカビーム撃ってくる序盤のボスっぽいのを必死になって倒したあたりでリタイア。
・Klee～月ノ雫舞う街より～
頭身の低い人形みたいなキャラクターを着せ替えることに重点を置いてそうなゲーム。
クエストにいく度にダンジョン作って潜る系。ほんわかした雰囲気とトテトテ走るキャラクターの動きが可愛い。
あっという間に戦闘に飽きて完全な町人となる。バグを使って街の中で壁抜けして街灯の上に登ったりして遊んでた。
街灯の上で自キャラを躍らせたまま付近を歩き回る人々をただただ眺めて2時間過ごせる程度には居心地がよかったし、
時々絡んでくれる知り合いもできたけど、しばらく休んでる間に気が付いたら過疎がとんでもなくひどくなってた。
・オーダー＆カオス2：リデンプション
PC向けMMOっぽい感じのガチ感あふれるMMO、俺が触った時はチャットはハングルと英語が飛び交いまくりだった。
文字が小さかったり表示が消えるのが早かったりしておつかいすらなかなか満足にこなせない。
グラフィックもシステムも俺にはちょっと重すぎた。ただただ圧倒されてリタイア。
・イルーナ戦記
またアソビモ。古くはiアプリだったらしい歴史あるゲーム。グラフィックやUI等、全体的に時代を感じる荒さがある。
パーツによってはテクスチャ伸ばしまくって使ってるからドット見えてまっせ感。なんかハンゲームとかで昔こんなMMOなかったっけって思う。
髪型の選択肢から女性アバタ―偏重の姿勢が読み取れて面白い、性別に関係なく髪型を選べるので、ドリルツイン男子も作れる。キャラは4頭身ぐらい？
狩りは割と単調にペチコンペチコンオートでし続けるタイプ、もっとレベル上がったりジョブチェンジすればスキルとかもどんどん使うのかもしれない。
深夜に一人でドングリ追い回してたら親切な通りすがりの人が突然メールで謎の盾をくれて、その盾なしでは生きていけない体になった。
町の中央部は人が多いけど、分からない単語で何かの募集がかかっていたり取引を持ちかけていたりして、
まったり身内でチャットしてるような人たちは大体自分の世界(島？)に引きこもっている様子。
無心でモンスターを狩る作業が割と睡眠導入用にいいので今も時々起動している。
【PC】
進化しすぎていてとにかく難しい(というか俺がついていけない)ゲームが多い。
ちょっと頭身低めのキャラを動かす3DのMMORPG、かなりいろんなことをやって暮らしていける感じっぽかった。
自由度の高さがそのままチュートリアルのダルさになってしまっていて、
チュートリアル村を抜けた後割とすぐに何をすればいいかわからなくなってリタイア。
結構過疎ってる感じがした。
・ArchAge
なんかグラフィックとか綺麗系、獣人の男を選んだけどキャラクター作るのに3時間かかった。
敵が動かなくなるまでボッコボコに殴れば雑魚モンスターは大体倒せるけど、そこそこ淡白な戦闘に対してストーリー展開がなんか重い。
画面の情報量が多くて老いを感じる。選んだ鯖が悪かったのか、3日間ぐらいプレイしたけど動いている他プレイヤーを2人しか見掛けなかった。
・TERA
ファンタジーにかなり寄せた感じのMMORPG、いろんな見た目の種族がいるけど一部の職には特定の種族や性別でないとつけなかったりする。
Wikiを少し読んだら、初心者にはおすすめできないって書いてある職ばかりでアワワワってなった。
拠点が分散しているのかビギナーサーバーなのがダメなのか、ArchAgeほどではないけど人がいない。
最序盤のシナリオで何回も死にかける程度には戦闘が難しかった。ちょっとオーダー&カオスと似てるプレイ感。
かばんがいっぱいになった後、買い取ってくれる店がわからなくて1時間近くさまよった。
今のところ、このゲーム続けるか！っていうのにまだ出会っていない感じ。
まず探してみてびっくりしたのが、今のMMOが大体どれも3Dになってること。すげーな。
すげーんだけど俺にはちょっとしんどい。三人称視点のWASD移動なり仮想パッド移動なりがこんなにかったるいとは思わなかった。
自分と他人が1画面でテーンって並んでる感じのカメラ位置が落ち着くなーって思った時点で、
思いのほか自分がクォータービュー向きの人間だったことに気付いたけど、そんなこといっても世の中の流れはそうじゃないみたいだからしょうがない。
色々触ってみて、自分がMMOに求めるのは適度なガヤガヤ感(あんまり過疎ってない)と、
着せ替えたり装備を変えたりしたのが見た目に反映されて、ひとりで眺めて満足したり、入手した達成感を得られる程度のアバターの量。
できれば3Dでもめっちゃリアルなやつよりはちょっと等身が低めの方がいいのかもしれない。でも多分2Dの方が好きそうだ。
後は本格MMOみたいなやつがどれも難しく感じたので、あんまり戦闘重視じゃない方がいいかなー？とか、
ダンジョン生成して数人で潜るのがメインループになるゲームは、狩りを楽しめなくてあんまり向いてないっぽいなーといったところか。
Tree of Saviorっていうのが今年中に日本サービスインするって話なので期待しているのだけれど、それまで何をやろうかなー。
いっそラテールとかメイプルとかそういうのやってみた方がいいんだろうか？
なにかおススメとかあったら教えて欲しい。
スマートフォンが普及する前、いわゆるガラケーの時代にもアプリゲームは大量に制作された。
有名どころでは「チャリ走」か。
当時ケータイを持っていた学生はみんな休み時間にプレイしていた記憶がある。
現在でもスマホや3DSでシリーズが展開されているヒットタイトルらしい。
スマホゲーがゲームをダメにするとか何とかいう論調が出てくる以前からケータイでゲームをプレイしていた。
ケータイで遊びつつ、ちゃんとゲーム専用ハードでも遊んでいて、競合というか普通に共存していた時代だった。
当時ケータイのゲームに夢中になっていた学生たちは既にスマホに切り替えているし、たぶん古い機種も下取りしたり捨てちゃったりしてるだろう。
ということで現在、当時のケータイアプリのゲームをプレイ出来る環境ってのは意外と貴重だ。
ゲーム専用機はハードがあってソフトがあってというものなので10年経っても懐かしくプレイできるが、ケータイアプリは10年前のものなんて完全にレトロである。
関係ない話だが、AIがプロ棋士に勝ったってニュースがあった。
そこでふと思い出したのが、昔アプリゲームでむちゃんこ強いオセロゲームがあったなあということだ。
たしかauの「極小㌔バイト宣言！」ってサイトの「■□（リバーシ）」っていうアプリだったなあ、と。http://k-tai.impress.co.jp/cda/article/news_toppage/19027.html
「極小㌔バイト宣言！」ってのはエイデー二千という会社がauのBREWアプリで展開していたアプリゲームのサイトである。
ここのゲームは100円以下の激安で、なおかつ容量が数十キロバイト以下、シンプルでありながら奥の深い良ゲームを多くリリースしていた。
（当時アプリの容量や値段ってのは簡単に機種を変えられない学生にとってかなり重要だった。）
ローグライクゲームや卓球ゲームなど。卓球ゲームはオンライン対戦もあって結構熱かった記憶がある。
難易度は肇-HAJIME-、豪-TSUYOSHI-、遥-HARUKA-の三種類あったが、「遥」がむちゃくちゃ強い。
Yahoo!のオセロのオンライン対戦で上級者と戦わせてみてもまったく負けなかった。
このたかだか18KBのゲームがなぜこんなに強いのかと思ったものである。
当時は今のiOS、AndroidみたいなOSではなく、携帯会社によってアプリの種類が違っていたので、どこで契約しているかによって遊べるゲームの違いがあった。
auでしかリリースされていないとか、ドコモのiアプリにしかないとか。（機種によっても対応してるしてないがあった気がする）
だからゲームで携帯会社を選んだ人も意外といたのかもしれない。
BREWまとめ Wikiというサイトにレビューとかいろいろ載っていて懐かしく読んでしまった。
そうなんだよな。10年ほど前って普通にインターネットは普及してて2ちゃんねるとかでアプリゲームについて語り合ってたんだよな。
で、そうした語った形跡はネットに残っているのに、肝心のアプリゲーム自体は影も形も残っていない。
・・・逆じゃないか。
普通は片付けとかをしていて古いゲームが形となって出てきて、そこで昔楽しく遊んだ記憶がよみがえるものじゃないか。
なのに、当時の遊ばれていた記録は残っていて、ゲームは残っていないという。
現在はサービスというかおそらく会社自体無くなっているのでの極小キロバイト宣言ゲームはもう遊べない。
闇に葬られてしまった大量のアプリゲームは影も形もなくなって誰かの記憶にしか残っていない。
大体20年ぐらいクライアント側のアプリをずっと作ってきたおっさんだけど、ここ1年ほど前にサーバー側に移った。
今までずっとWindowsで作ってきたから、何もかも新しいことばかり。
LinuxとFreeBSDのどっちがいいかわからないから、CentOSとFreeBSDの両方で開発している。
Shellスクリプトもちょこっとわかるようになった。
今は主にErlangで０から開発した数十台に分散して動くサーバーを運用している。
言語を覚えるのは苦ではなくて色んな言語を使うことができるけど、OSはなんだか別な感じがする。
今日、FreeBSDのOpenSSLのアップデートをしたらサーバーに繋がらなくなって、なんかpsshとかも動かないし、もうわけわからなくて全部再インストールすることにした。
分からないなりにいろいろ頑張って実際にサーバーを運用しているけど、知識の足りなさを実感している。
俺はもう40代だから、やっぱり脳みそがだめなのかなぁ、とか思いながら今自棄酒飲んでいるところ。
今、第一線で活躍している人はだいたい何年ぐらいでまともに”使える”ようになったんだろうか？
教えてほしい。
それらも、Civilizationとか、PCのSLGみたいにメールでの通信対戦とかできれば面白かったろうに。
フリーのプログラマです。月収で200～1500万くらい。年収で3000万～１億くらい。都内のボロいワンルームの1Fに一人で住んでテレビも冷蔵庫も食器もない部屋で毎晩コードを書いているだけです。昼は寝ています。ごはんは隣のコンビニですましています。何かを選ぶ気力も無いです。使っているパソコンはThinkPad X30だけです。これで十分です。有料のソフトは秀丸があれば何もいりません。
欲しいものはなにもないです。行きたいところもないです。会いたい人もいないです。友達も仕事以外では誰もいないです。学生時代の大半はいじめられっこだったので、基本的に人は好きじゃないです。２ちゃんでスレを立ててもだいたい伸びないです。オンラインゲームも人と絡むのがすごい苦手ですぐやめました。惨事の彼女なんているわけないです。セックスは有料でしたことがありますけど、zipの同人誌を見てオナニーしてるほうが気持ちよくて、面倒くさくないと思ったのが感想です。恋をしたこともありますが、多くは色恋営業で、街で声をかけられて、数十万の絵を買わされたり、数千万の紙切れを買わされたりして、契約成立のあとは、一度も会ってくれない女の人に３人ほど恋をしました。一生虹でいいとおもいました。
コードを書くのだけは異常に速いと言われます。Webサイト構築でも、FlashでもAJAXでも、DSP開発でも、PGA/CPLD verilogでも、WindowsやMacでも、JavaでもAirでも、BREWやiアプリとかのケータイアプリでも、iPhoneやAndroidのアプリでも、PS2やPSPのコンソール機のゲーム開発でも、組み込みの独自OSの開発でも、ドライバ開発でも、カスタムCPUのコンパイラでも、なんでもこなしてきました。キモい38歳です。コードを書くだけがとりえです。それだけの人間なんだと毎日思っています。別に幸せでも不幸でもないです。ただ、やりたいこともないです。正直、明日にでも死にたいです。もう死んでいるかもしれません。みなさん、ありがとう。
これ↓
http://anond.hatelabo.jp/20081031194544
ドコモのP905iで、iアプリのjigブラウザFREEを使って書いた。
jigブラウザのFREE版は1日当たり10ページ(だったかな？)の閲覧制限があるので、お気に入りに増田のログインページを登録しておいて、iアプリ起動したらすぐにログインページに行けるようにしてます。
URLのコピペできないだろうからトラバするのは難しいだろうし、FREE版で1日10ページの制限なら、たいして連投もできないから、携帯から増田に日記を書けないわけでもない、ぐらいの感じです。
