  |
はてなキーワード: インターフェースとは
バニラ・エアの件、論点が増えすぎてうやむやになって終わりそうだったので、論点をいくつかに分類した上で私が思う問題点について書いてみます。
長いので結論だけ先にまとめておくと、車椅子利用者のみが自主的な事前連絡を求められていることはバリアフリーでなく、より確実なバリアフリーを目指すために航空会社がシステムの側で対応すべきということです。
ちなみに私は健常者ですが、中学の時にこのエントリと同じような趣旨で卒業レポートを書いたり大学で車椅子利用者向けのインターフェースについて勉強したりしていたので、どちらかと言うと車椅子利用者側の意見になっているかもしれません。
今回の騒動で話題になった記事は http://b.hatena.ne.jp/topic/300611893821289425 が割とよくまとまっています（おそらく自動生成ではありますが）。これらのエントリを見ると、論点は大きく4つに分けられます。
本エントリでは4つめについて主に述べたいのですが、一応私の立場の表明がてら他の3つについても軽く触れておきます。長くて読むのが面倒だという方は飛ばして次のセクションを読んで下さい。
その場の対応についてはバニラ・エア側も謝罪・対応しており、搭乗拒否したことが問題である点については多くの方が同意するところでしょう。「バニラ・エア車いす利用者搭乗拒否に対するDPI日本会議声明 : DPI 日本会議」でも、やはり搭乗拒否についてが問題として指摘されています。
「LCCに車椅子利用者対応を期待するのは過剰サービスだ」という批判も中にはあるようですが、これは障害者差別解消法でいうところの差別にあたります。コストの理由だけで搭乗拒否することは「合理的な理由」であるとは言えないでしょう。
報道の仕方については、やや見出しが過剰にセンセーショナルであったことは否めないように思います。
「【ラジオ書き起こし】荻上チキ×木島英登×石川准「誰もが暮らしやすいバリアフリー社会を実現するためには何が必要なのか（2017/06/29 TBSラジオより）- "シュプレヒコールを歌え" 」に、「あの、私は、階段を這って上ったことは、僕にとっては屈辱でも何でもなくて。 」とあります。つまり這って上る事自体は木島氏も問題視していません。
一方で最初に話題となった記事のタイトルは「車いす客にタラップはい上がらせる バニラ・エアが謝罪」でした（今は修正されたようです）。このタイトルからは「はい上がらせ」たことが問題であったようにとれる点で、そもそも論点がずれていたと言えます。結果として話題となったのは良いかもしれませんが、論点のずれによって初期の議論が迷走し、木島氏へのバッシングなども引き起こしてしまったのではないかと感じています。
3つ目の木島氏の人格についてですが、私はあまり問題であるとは思っていません。「プロ障害者」という批判があるようですが、当事者として声を上げられるのは当然当事者だけです。「 なぜ声をあげた障害者がバッシングを受けるのか？バニラ・エア問題、本当の争点はどこにある 」にもある通り、「声を上げた」ことは他の車椅子利用者の方にとっても救いとなるのではないかと考えています。
一方で「本来必要とされている事前連絡をしなかった」という非が木島氏にあることはたしかで、この一点のために個人の責任を問われているところがあります。しかしながら、事前連絡が必要であることそれ自体に問題があるのではないでしょうか？すなわち、搭乗拒否が差別であることだけでなく、事前連絡の必要性もまた差別であり解消されるべきものであるということも、今回の件から考えるべきではないでしょうか？これについては次のセクションで詳細に述べたいと思います。
木島氏への批判の理由として、「本来必要とされている事前連絡をしていない」ことがあるようです。今回のケースでは連絡していても搭乗を拒否されていただけであろうことを考えると、この批判は当たらないようにも感じます。しかし一方で、木島氏は普段から事前連絡をしていないようなので、そのことを問題視する方がいるのも理解は出来ます。
特に「車いすで飛行機に乗る時は | いすみ鉄道 社長ブログ」によって、航空会社側の安全管理上の都合が多くの人の知るところになって以降、その傾向が強いようです。
この航空会社側の都合とは、車椅子利用者の方があると事前に分かっていれば対応できるのだから事前連絡をして欲しい、ということのようです。対応できる事自体は素晴らしいのですが、この考えには飛躍があります。その飛躍とは、「航空会社が事前に把握するための負担を、乗客である車椅子利用者が負わさせられている」という点です。
少し話は逸れますが、他のケースとの比較を通じてこの問題点について考えてみましょう。
機内食についての事前連絡の必要性に関して、ベジタリアンや信教、健康上の理由から、マイノリティでも事前に連絡しているという意見がありました。バニラエアで確認してみると、機内食としてベジタリアン用の食事は予約時に選択できるようになっています。バニラ・エアのグループ会社であるANAで確認してみると、さらに多くの種類の食事が選べるようです。
小さなお子さんがいる場合も航空会社は把握する必要があります。この場合も、システムが利用者の誕生日を入力させることによって航空会社は把握することが出来ます。
すなわちこれらの2例では、マイノリティの存在を把握するための仕組みがシステムの中で事前に準備されているということです。
話を戻して、車椅子利用者についてはどうでしょうか？ANAでは「おからだの不自由なかたへの空の旅へのお手伝い｜ANA 」にあるように、事前に電話で連絡する必要があります。今回問題となっているバニラ・エアではFAXまたはフォームからの連絡が必要です（「お手伝いが必要なお客様｜ご利用ガイド | バニラエア Vanilla Air」）。すなわち、航空会社がシステムとして主体的に車椅子利用者の存在を把握しようとするのではなく、車椅子利用者の方から航空会社に自己主張をするという構図になってしまっています。
もちろん食のマイノリティや幼児に比べて車椅子利用者は少ないという数の問題はあるでしょう。しかし、だからといってその存在を例外として扱って良いわけではなく、存在するのが当然と見なして対応するべきです。マイノリティについて事前に把握する必要があるならば、そのコストは利用者側でなく航空会社側が負担すべきではないでしょうか。実際「障害者への差別的な対応しないよう航空会社に指示へ 国交省 | NHKニュース」でも、「搭乗前に乗客に聞きとる」という航空会社の主体的な行動が要請されています（この記事に対して、やはり木島氏は事前連絡すべきだったとする意見があるようですが、それには前述した飛躍があります）。
一方で、電話で連絡すれば搭乗がスムーズになるというのは、搭乗できないよりは遥かにマシでもあります。それ故この対応を「差別である」と切り捨てることもできません。
つまり重要なことは、「ある行動が差別であるかどうかは0/1で決まるものではなく、比較可能なものである」ということです。今回のような「比較的差別的」な状態は、「比較的バリアフリー」を継続的に目指すことで解決されると私は考えています。
差別が0/1で決まるものではないという話をしましたが、それは「バリアフリー」についても同様です。事前連絡をすれば搭乗できることは、全く搭乗できない場合よりはバリアフリーであるといえます。しかし同時に、事前連絡せずに搭乗できる場合よりはバリアフリーではありません。本当にバリアフリーな社会が目指すべきなのはこの、「事前連絡せずに搭乗できる」という状態でしょう。
１つのバリアフリーな手段が用意されていることだけをもって「バリアフリーだ」と言い張るのは簡単です。しかし、それによって既存のバリアフリー施設の問題点や改善点が見えなくなってしまうという新たな障壁もあります。そのような「なんちゃってバリアフリー」の状態に甘んじることなく、全てのバリアがない「真のバリアフリー」を目指すことが、社会全体としては必要とされています。
もちろん「真のバリアフリー」は理想論であり、全てのバリアを一度に完全になくすことは現実的に不可能です。だからこそ、一つのバリアフリー施策を実施するだけでバリアフリーになったとするのではなく、既存のバリアフリー施策で足りないところを改善しながら一歩一歩「真のバリアフリー」を目指していくことが必要となります。この、漸近的に解消していくプロセスこそが合理的な配慮である、と私は考えています。
今回のバニラエアの場合は、例えば予約時にモビリティ上の特記事項があるか否かのチェックボックスを用意すれば、航空会社は車椅子利用者の利用を把握できる上、ユーザーの手間もそれほど変わらないでしょう。その上で航空会社がどのように対応するか、主体的に決めることも可能になります。多くの種類のマイノリティが存在する中でどれに対応するのかという問題はありますが、サポートする範囲を少しずつ広げながら、差別を減らしていけるはずです。
差別やバリアフリーを0/1で捉えるのではなく、連続的に改善していける社会になればいいなと思います。長い文章でしたが、読んでくださった方ありがとうございました。私より中立的な立場の方からのコメントや、車椅子利用者の方のコメントが頂ければ嬉しいです。
栗田穣崇Shigetaka Kurita @sigekun 1時間1時間前
その他
ドワンゴがマストドンに貴重なエンジニアリソースを割いてニコニコをないがしろにしているように思われているようですが、マストドンは静画チームを中心としたエンジニア数名の取り組みで、ニコニコのバージョンアップには全く影響ありません。
という発言
いやいやお前らニコニコ静画だってまったく仕事できてないだろうが
使いにくいインターフェースは
他のアプリで見てみろ
あたりまえだよ、それでユーザーは読む読まない決めてんだよ
そのサムネをお前らニコニコ静画はずっと汚いままで放置しやがって
どういうことだ
むっちゃよかった
誰だよ金かかってるだけとか言ってたヤツ
攻殻機動隊知らない人が見たらあれかもだが
攻殻っぽいギミックとアクションだけ豪華にみせときゃいいんでしょ、みたいのとは全然違った
シナリオが押井と神山から（アライズはみてないからわからない）いろんな要素とシーン持ってきて初見でもわかりやすいようなオリジナル加えてうまく料理してあるしテンポもよかった
少佐とバトーの関係も見てて気持ちいい（ファックサインとかボートのやりとりとか）
あとバトーの犬とかコンピューターの丸いインターフェースとか細かいところもよくできてたし
ネオサイタマレベルのやりすぎネオン風景とシャフトアニメみたいな謎建物空間の対比も面白かった
###残念だったところ
▪社長。アホなので出てくると画面がアホになる
▪武の滑舌
今の37〜40歳ぐらいのベンチャーやらスタートアップやらWeb系やらの技術者の書くコードがやばい気がする。
それが外注とかフリーとかじゃなく、役職付いている人とか役員だったりする。
コピペしたり入り組んだ関数（メソッド）を書いたりとか・・・。
抽象的な考え方とか、参照透過性とか、100%適応できないまでにしても少し考えてかけないものなのだろうか・・・。
そういう基礎的な部分の技術をまとめた技術書籍がない（もしくは流行っていない）のも原因なのかな。
Javaのオブジェクト指向からRuby on Rails時代に移行していった時代に生きていた人たちなのかな？
色々と今まで学んできたことの基盤が崩れ一気にレガシー化した感覚が強く、新しいものに手を出したがるくせがあるんじゃないかと疑ってしまう。
新しい技術を学んでも、思考を変えずに使っていたら何も変わらねぇっすよ。ゴミを今の技術で再構築するだけ。
GRASPとかSOLID原則とか、できればDDDとか関数型の考えとかを勉強して欲しい・・・。
まあ別に上記知らなくても、構造化プログラミングとか、クラスとはなんぞやとか、関心事をなるべく分離していくようなコーディングとか・・・。そういうのが欲しいです。
リーダブルコードも局所的な事を書いている気がするし、もっと大局的な技術リテラシーを・・・。
てかコレが技術的負債かー。ちょっと直すだけでもすげーめんどくさいし、やる気全然起きないし、なんならリファクタしてから修正していきたい気持ちになる。。。
DB設計もなーーー、なんでNOT NULL制約付けないかなー。もちろんテストなんて書くわけもなく。
創業期なら頑張るって感じだけど、中規模になってきたベンチャーとかだと気合い入れて全て変えてやるぜぐらいのポジションで入らないと環境変わらないだろうし、いわいるプログラマーで入るなら面接時に匂いを察知して回避したほうが良い気がするお。まぁでも入社時のやる気なら変えれるのかな・・・。もはや業務量増えてマンネリ化した状態の今は全くやる気しねぇ。すべての開発を止めて、テストコードを書きながらリファクタしていく、ってならやる。
そしたら今後何か頼まれても工数減るので「いっすよやりますよー」といいやすいし「もっと短く出来ないの？」みたいな地味なストレスがなくなるのでまぁ色々ハッピーなんじゃないのかな。（てめえのゴミ直すのに工数かかるんだよといいたくなる）
的な、ゴミと一緒に働けねぇ、みたいな問題を解決するためにマイクロサービスで開発するのありかもね。ゴミレガシーはラップして、臭いものに蓋をしてまあ許せるインターフェースだけ公開して使わせて欲しい。（驚くほど上から目線）コードレビューですり合わせられるようなレベル感ではなく、でかいゴミ山があり、そいつがゴミ山を整理する気がないならそうするのが折衷案なんじゃないでしょうか。
「サービスを作ってきたコードだから感謝して」って実際その現場になるとあまり思えないものなんだな。サービスをスケールさせられないこの足元作ったやつまじ、考え直してもらわんと対して売上立たず終わるから期待持たせるだけだぞ、みたいな。これがクソ稼いでいるサービスとかだったら別なんだろうなぁ・・・。
http://blogos.com/article/212112/
----------------------------
僕はLINEを愛してる。
愛してるがゆえにLINEをどんどん駄目にするLINEの経営層が許せない。
はっきり言うが、彼らのやってることはグダグダだ。他社のチャット系サービスが成長してる中、LINEが初めてユーザー数が減少したと言うがそれは当然だ。
説明しよう。
----------------------------
多分に自己愛と思い込みの強い著者が、アプリってのはこうグロースさせるもんなんだからそれをやれてないお前ら間違っている
と一方的に断じているもので、共感できるところは各タブに名前が入っていないことくらいのぶっちゃけ大して価値のない記事であった。
そもそもニュース領域はtwitterと違い、LINE株式会社側にLivedoor由来の編集チームがいてリソースが確保されている点、すでにLINENEWSという
基盤が存在している点で突然何の前触れもなくニュースを始めた日本のtwitterとはわけが違うだろう。
さらに噴飯ものはタイムラインについての評価で、まず誰も見ていないと断じているが、
リサーチベースではこんなものも出ている（http://gaiax-socialmedialab.jp/post-1891/）
大体、広告事業としてのLINE ADS Platformは、このタイムラインをベースにしたインフィードアドが中心であり、それで十分にマネタイズできている
ということは、タイムラインが一定使われていて、広告インプが一定以上発生していることの証左だろう。
つまり、この著者自体が、自分の見ている物事からしか評価・判断のできない典型的な「マーケティング知らない人間」なのだろう。
何をしてきた方かは存じ上げないが、いわゆるユーザーグロースのみをマーケティングであると思い込んでいるIT野郎。
LINEのニュースタブは、すでにユーザーが一定以上グロースしている国内のLINEユーザーに対してより多くの広告インプを発生させるためのレベニューグロース
としての側面が強いわけで、それも含めてマーケティングであるのだから、十分LINEの現場も、経営陣もマーケティングを、経営を理解していると言っていいだろう。
あ、後ユーザー数が減少と書いているけど、これはニュースタブを追加していない国についての話であって、そもそもの前提からしてもうめちゃくちゃ。調べずに書いてる感満載。
だからこそ失望したのが、これなわけで。僕もLINEを愛しているけど、これはマジでないんじゃないか。
http://jp.techcrunch.com/2017/03/02/line-clova/
----------------------------
スペイン・バルセロナで開催中のモバイルカンファレンス「Mobile World Congress（MWC） 2017」。そのキーノートにも登壇したLINEが3月2日、クラウドAIプラットフォーム「Clova（クローバ）」を発表した。
今後はClovaを搭載したアプリ「Clova App」を提供するほか、初の自社デバイスとなるスマートスピーカー「WAVE（ウェーブ）」を今夏にも日本と韓国で発売する予定だ。
今冬にはスマートディスプレイ「FACE（フェース）」の提供も控えるという。
----------------------------
要はAmazon Echoとか、Google Homeとか、スマートスピーカー領域（というか、音声会話をベースにしたインターフェース領域）に打って出るというわけだ。
これは一面ではすごく合理的に見える。つまりチャットサービスとしてユーザー間、ユーザーと企業間でのコミュニケーションのインフラを提供しているLINEが、textingから音声を介した
コミュニケーションインフラに舵を切るということ。事業の成長の向く先としてわかりやすい。
が。これ。マジで間違いなくうまくいかない。頓挫する。てかこれこそ、挑戦の美名に酔いしれてマーケティングを忘れた経営判断だろ、と思う。
音声インターフェイスの要は、自然言語処理であり、発話された音声を正確に理解する技術にあるはずだ。
この点、AmazonとGoogleは基本的に「英語」という話者が圧倒的に多い言語に優先して開発を進めればよかった。現に英語の自然言語処理はめちゃくちゃ進んでいる。
しかし、LINEは違う。英語圏ではまったく使われていないサービスなのだ。それどころか、LINEが浸透している主要国は日本、台湾、タイ、インドネシアの4カ国である。
サービスを普及させるためには、地の利を生かすほかない。そういう意味で英語圏は端から勝負しようがない。一方中華圏、圧倒的人口を誇るメインランドにはWeChatという
であるからして、浸透している主要4カ国で普及させる、という選択肢にせざるを得ないだろう。しかし、この4カ国ぶっちゃけ日本とインドネシアしか1億を越える人口の国はない。
その上、GDPベースで考えてもスマートスピーカーが短期的に人口に膾炙するほど普及させられるマーケットは日本と台湾しかない。
さらにさらに、R&Dの視点からいって、4カ国それぞれの言語にあわせて自然言語処理を一定水準まで高めるには、英語1つに絞って開発するのと比較して単純に4倍のコストと労力がかかる。
典型的な、労多くして実り少ない状況なわけだ。
どう考えても八方塞だ。
コミュニケーションプラットフォームである以上「言語」は避けて通れない問題。これを攻略する方法は正直、僕にはわからない。
だからもはやLINEは、チャットサービスとして浸透している国の中で、その土台の上で、ニュースタブとかその他もろもろで、
きちんとレベニューグロースを続けるのであれば、ぜんぜん負け続けることなんてないのになーと僕は思います。
事実、世界でこんなに儲けているメッセージングアプリはないのだから、その時点で十分世界で勝ってんじゃん、と思うわけで。
GmailやOutlookのようなウェブメールサービスを利用すれば、すべてのデバイスで簡単にメールアクセスとモバイルアプリを提供できますが、それらのメールサービスはあなたのデスクトップでの動作を保証するでしょうか？
今は、多くの人が複数のメールアカウントを持っている。これらのアカウントが異なるプロバイダを使用している場合は、一度に複数のブラウザタブを開く必要があります
便利な場所にすべてのメッセージを集約するだけでなく、優れた電子メールクライアントは、暗号化やカレンダー、RSSフィード、VoIPアプリケーションとの統合などの機能を追加できます。
デスクトップクライアントはメールをローカルに保存することもできるため、オフラインのときにアーカイブされたメッセージにアクセスしたり、貴重なバックアップを提供することができます。
さまざまな電子メールプロバイダと統合されたチャットをサポートする最高の電子メールクライアント
eM Clientは10年近く前から始まっています。その長い開発により、Windows用の最高の電子メールクライアントに発展することができたんや。
無料版は非営利目的の使用と2つの電子メールアカウントに限定されますが、それ以外の場合は有料版とおんなじ。
eM Clientには、Gmail、Exchange、iCloudおよびOutlook.com、タッチコントロール、高速検索、統合カレンダーおよび連絡先のサポートが含まれてん。JabberやGoogle Chatなどの一般的な標準をサポートする統合されたチャットアプリもあり、Outlookのような重量のあるアプリには良い選択肢ですわ。
あなたのメッセージを補う機能が満載されたすばらしいメールクライアント
Mailbird Liteは単なる電子メールアプリではなく、スケジューリング、チャット、ファイル同期、チームワークのためのアプリケーションを追加できるコミュニケーションプラットフォーム全体です。
Mailbirdをダウンロードした後は、Proバージョンの30日間試用版に対処されます。このバージョンは、月末にアップグレードしないことを選択した場合、限定版Light Editionにダウングレードされます。フリー・クライアントには時間制限はありません。
無料のユーザーは、速読、電子メールのスヌーズ、添付ファイルのクイックプレビューなどの機能を忘れていますが、Mailbird Liteは依然として優れた選択肢です。最大3つの電子メールアカウントをサポートし、スピードに合わせて最適化され、起動時に最適です。
セットアップは簡単です。電子メールの詳細を入力すると、Mailbird Liteは必要なPOPまたはIMAPの設定を自動的に見つけ、メッセージのインポートを開始します。あなたのFacebookアカウントに接続することができるので、あなたの連絡先のプロフィール写真であなたの受信トレイを活性化し、Whatsapp、Googleカレンダー、無料のタスクマネージャMoo.do、teamworking app Asanaにリンクすることもできます。
Claws Mailのシンプルなインターフェースは、より自信を持ったユーザーに適した強力な電子メールツールです
Claws Mailは使いにくくはありませんが、独自のメールフィルタリングに耐え、無制限の電子メールアカウントをサポートしたい経験豊富なユーザーに最適です。
ここの他のクライアントとは異なり、ClawsはユーザーにPOP3 / IMAP設定を手動で設定する必要があります。 Gmailを使用している場合は、Googleアカウントの設定を調整して、安全性の低いアプリケーションのアクセスを許可する必要があります。
古くは現代の電子メールクライアントでは、HTMLメッセージを送信するオプションはありません.Clawはプレーンテキストのみですが、不要な機能を省略することで、Clawは驚異的なスピードで動作します。その検索機能は特に優れており、プラグイン経由でも拡張できます。
それは最も美しい電子メールアプリケーションではありませんが、Clawsはあなたがスタイルを超えて物質を評価するならば、素晴らしい自由選択です。定期的に更新されているため、バグはすぐに除かれます。
すべてのデバイスでメールを管理するためのワンタイム設定の無料メールクライアント
Inkyの無料版はWindows、Mac OS X、およびAndroidで利用でき、ワンタイム設定は3つのプラットフォームすべてで使用するのに最適なメールクライアントになります！
電子メールクライアントをダウンロードしてインストールしたら、Inkyアカウントを作成するよう求められます。これにより、すべての電子メールアドレスがリンクされ、POPおよびIMAP設定を設定することなく、Inkyがインストールされた任意のデバイスからアクセスできるんです！
一度登録すればセットアップは簡単カンタン♪ 各アカウントのユーザー名とパスワードを入力すると、残りの部分をInkyが処理してくれちゃう。
日常的に使用されるInkyは優れた自動タグ機能、メッセージタイプ（個人、定期購読、ソーシャル、ノートなど）のインテリジェントなフィルタリング、デバイス間の非常に高速な検索とクラウド同期でわんだふるん♪。
Windows 7以降を使用していて、特定のメッセージやスレッドを見つけようと多くの時間を費やしている場合、Inkyは膨大な時間を節約できちゃうの！
優れたOperaウェブブラウザの背後にあるチームからの柔軟なオープンソース電子メールクライアント
Operaの開発者は、電子メールを常に優れたブラウザの重要な機能とみなし、無料の電子メールクライアントであるOpera Mailの開発に多大な努力を払ってきました。
その機能には、メッセージテンプレート（特に業務用に便利）、メッセージのフィルタリングとソート、タイプ別のメッセージソート、さまざまなカスタマイズオプションがあります。
クライアントはRSSフィードもインポートするので、Feedlyや欠けているGoogleリーダーなどのWebアプリケーションの代わりになります。
Mozillaから期待されるように、たくさんの機能があり、無料の拡張機能を利用することもできます
Firefoxと同様に、無料の電子メールクライアントThunderbirdはMozilla Foundationによって作成されました（しかし、2つの開発はそれ以来分離されています）。 ウェブブラウザと同様に、その機能は、サードパーティのアドオンの膨大な範囲で拡張され、強化されます。
優れたビルトイン機能には、電子メールには大きすぎるファイルと、電子メールと一緒にRSSニュースフィードを読む機能があります。
セットアップは簡単です。 ほとんどの現代の電子メールクライアントと同じように、必要なのはあなたのユーザー名とパスワードだけで、Thunderbirdは残りのものを処理します。
Windows Live Mailは、Windows 8および10のMailアプリケーションに取って代わられた2012年に最後に更新されました。ただし、Live Mailの比較的昔ながらの外観にもかかわらず、2つのプログラムはほぼ同じです。
Windows Live Mailは、私たちを含む多くの電子メールユーザーがより現代的ですが、最小限のデザインを好む3ペインのレイアウトを提供します。 RSSとクラウドベースの電子メールとPOP3をサポートし、添付ファイルを送信したり、複数のアカウントで作業したりすることが容易になります。
マイクロソフトのやり方が気に入っても、ウルトラスリムなWindows 10アプリケーションがあまりにも制限されているのを見つけたら、従来のWindows Live Mailは賢明な選択肢です。
*
http://anond.hatelabo.jp/20170106223846
今の中高生から20代前半の奴らは、「2ちゃんねる」という言葉すら知らない奴がマジで多い。
「2ちゃんねる知ってる」という奴は、2ちゃんねるまとめブログのことを指していて、「2ちゃんねる」という掲示板があることは知らない。
本家本元の2ちゃんねるを見せても、その前時代的なインターフェースに「なにこれ？どうやって見るの？」って感じ。書き込み方もわからない。
2ちゃんねるは、マジでオッサンしか利用してないんだなというのを実感した。
最近は2ちゃんねる知らないどころか、ニコニコ動画知らないってやつが増えてきた。
カラオケ行って履歴を見ればほぼ初音ミクの曲で埋まっていたのに
最近はカラオケの履歴で初音ミクの名前を見ることは無くなった。
こないだ高3の女の子と会話したら、「私アニメオタクなんですー」って言うから
「ニコニコ動画見てるの？」って聞いたら「なんですかそれ？」って言われて、
「初音ミク好きなの？」って聞いたら「ボカロとかもうオワコンです。ダサいです。」って言われた。
もちろんスペシャリストがきちんとわかった上でOracleを使ってる案件は大丈夫なんだろうが、中小規模案件でOracle使ってるのにろくなのがない。
・データベースは当然のごとく正規化されてない。昔はされていたのかもしれない。
・使用されていない予約されたカラムの山。必須でない情報でもカラムを作るのでテーブルがどんどん肥大化していく。
・謎のインデックスが大量にあるが、パフォーマンス上本当に必要なインデックスはない。
・ストアドプロシージャが秘伝のタレ化。そのせいでOracleから抜けられない。
Oracleを使うとDB設計者の脳は破壊されるのだろうか。脳が破壊されているからOracleを使うのだろうか。
http://altavista.hateblo.jp/entry/2016/12/10/003830
実際両方やってたらシャドバがハースストーンをパクったかどうかなんて恥ずかしくて声に出せないレベルなんだが、どうやらわかってない連中がいるので。
なお、ハースストーンはMTGをパクったが、それはカードゲームという概念をパクったという意味であり、各種システムをパクったシャドバとは同列に扱わない。
偉大なるMTGが編み出したマナ・色マナの概念は豊かなゲームプレイの元とはなるが、土地事故であぼーんの元でもある。
ハースストーンでは毎ターン1マナずつマナが自動で増加し、10マナまで増え続ける事で序盤の小競り合いから10ターン目付近で巨大クリーチャー（または呪文）により決着をつけるという分かりやすいゲーム展開を生み出した。
各プレイヤーのターン中、対戦相手は操作によって盤面に干渉する手段は無い。お互いのやり取りを楽しむという意味では攻撃指定・防御指定・妨害呪文等を行使できればプレイの幅は広がるが、どうしても対戦時間の延長につながる。思い切って防御側は何も行動できない仕様となっている。
各ターンの持ち時間が比較的少なく、時間切れが迫るとアニメーションによって、切羽つまった感じとなる。
シャドバ＝ターン終了ボタンが爆発？
これはそのまんま。
(追記:同じカードの中でもレアなキラカードがある。キラカードは性能は全く変わらないが他のカードが止め絵なのに対し、髪がなびいたりヨダレが垂れたり部分的なアニメーション演出がされている。)
ハースストーンやってたらシャドバのチュートリアルは不要なほど同じ。ほんと同じ。ボタンの配置や操作性とかもうほんとまじで。恥ずかしくないの？
シャドバにアリーナなんて無くても良さそうだがわざわざつけた。
途中で書いてて飽きて来たけど、やってたらわかるとしか言い様がないほどパクってる。
シャドバの開発者はハースストーンをどう和風に再構築するか？をベースに開発したのは間違いない。（ハースストーンはMTGを再構築したのでは無く、デジタルカードゲームを再構築した。）
結果として、分かりやすいインターフェース・ダイナミックな試合展開（ランダム性を意図的に排除し、強コンボによる爽快な戦い）＋ログインボーナス・萌絵等、良いゲームとなっているが、シャドバがハースストーンのインターフェースを丸パクリしたこととそれはまた別の話。
ヒーローはあくまで「戦士・プリースト（感謝します）」といった職業を代表したキャラクターでしか無く、課金して別の名前・顔・セリフに変更できる（着せかえなので性能は同一）。
敗北するとヒーローが爆発する。
ヒーロの顔を選択すると周囲180度に漫画のようにセリフアイコンが表示され、それを選択すると「挨拶・感謝・煽り（感謝します）・反省」等のシンプルなセリフを表示可能。
カードを出したとき、カードが攻撃を受けたとき・死亡した等に、音声セリフなどが流れゲーム展開を盛り上げる（誰か怪我人はいませんか？）。
ダブって不要となったカードを使って、カードを生成出来る。コモンからレジェンドまで、生成出来ない限定カードは一切無い。
ゲーム場の背景は戦場だったりダンジョンだったり、賑やかしとしてモンスターや森などが動いている。
言っとくけどシャドバはシャドバでいいところ沢山あるからね。
よう、新入り。10年前の俺を見ているようだな。
俺も設計がやりたくてメーカーへ入ったら真っ先にテストをやらされた口だ。
すごくつまらない仕事で、毎日が憂鬱だった。だが今から思えば得るものも多かった。
そんな俺からお前に日々の仕事を楽しくする2つのアイデアを贈る。耳の穴かっぽじってよく聞けよ。
電気回路が外部の他の回路とつながる部分。Input/Output。略してI/O。
ここの評価は奥が深い。回路の中でも電源と並んでアナログ要素が非常に大きい箇所。
電子系の学科で習った回路理論が現実世界とリンクしていることが実感できるだろう。
さらに最近のGHzを超えるような高速インターフェースの評価ができるようになればいうことなし。
得難い人材として重宝されることは間違いないだろう。
経験を生かしてI/O周りの回路設計者に転身することも可能だ!
製品試験に使うロジックテスタのマニュアルは読んでみただろうか?
そこにはテスタの動作ブロック図が載っていたりしないだろうか?
そのブロック図から自分でテスタを作ることはできないだろうか?
頭の中だけでもいいから、Raspberry piのような組み込みPCと秋月で売っている汎用ロジックICで同じようなものは作れないか考えてみよう。
http://ascii.jp/elem/000/001/206/1206225/
ルンバがすごいのは表情だ。
掃除を始めるときは「ティルー↑トゥルル！」といって頑張るぞーという雰囲気の音を出す。
掃除が終わってドックに戻った時は「トゥルルテッテレー！」と喜ぶような。
ルンバがすごいのはロボットらしい感情表現を足したことだと思う。
愛玩目的でない、作業ロボットに表情を付け加えることで、すっと生活の中に入ってくる感じがする。
実際にルンバが壊れた時は、カスタマーセンターに「ウチのルンバくんを直してやってください」というようなまるで家族の一員のような扱いの問い合わせが来るそうだ。
表情のパターンは多くないが、それで十分。
ロボットらしい愛嬌を持ちながら掃除してくれるルンバにだから、たまに段差に落ちて動けなくなってたりしても許せる。
そういうインターフェースを（意図的か否かは置いておいて）作ったことがすごいと思う。
newしてから渡せば良いと思うよ。
いちいちクラスに分ける理由は、こういう感じで、クラス内の変数にアクセスすれば、画面事の表示とかが簡単に出来る的な？
// Javaの書き方しらん、インターフェースを実装することを定義したい
public class EventHoge : View.OnClickListener {
//画面事の名称
// Javaの書き方しらん、インターフェースのメソッドを実装することを定義したい
public void View.OnClickListener.onClick(View v) {
AlertDialog.Builder dlg;
dlg = new AlertDialog.Builder(MainActivity.this);
dlg.setTitle("画面の名前：" + ViewName); // 画面名称が表示されるイメージ
dlg.setMessage("Hello, サンプル!");
dlg.show();
//＜ーー
}
}
// Androidなにも知らんけど、元増田がボタンにイベントを書く処理が書いてあるクラスのことが言いたい
// そのメソッド
final Button button = new Button(this);
button.setText("ダイアログの表示");
View.OnClickListener ocl = new EventHoge();
ocl.ViewName = "画面その一";
button.setOnClickListener(ocl);
}
}
こんな感じにすれば、画面が二つあって、
その画面の名称を表示するようなボタンを、二つメソッドをコピペして作らなくていい的な？
サンプルは、出来るだけとっちらかさないよう、匿名クラスとか使って、サンプルで紹介したいところ「だけ」を書くんだよね。
だから、そのサンプルがどういう意味かをちゃんと読み取って、自分ならこう書くとか、こう書けるか？ とかを考えてこそ勉強だと思うよ？
今回のレイだと「View.OnClickListener」っていうインターフェイスを実装したクラスを、setOnClickListenerすればいいってことさえわかれば、
匿名クラス？（っていうのかな？ ちょっと用語はよくしらん、クラス定義を使い回さず、その場だけのクラス定義を書く書き方）とかを使わずに、
どういうふうに応用ができるか？ とか頑張れ！
頑張れ！
頑張れ！
はああああああ。
おれはビールを飲む！
うーん？
いや、なんか、通じてないな。
もうちょいサンプル詳しく書くから、サンプルのどこがわからないか言ってくれ。
// Javaの書き方しらん、インターフェースを実装することを定義したい
public class EventHoge : View.OnClickListener {
// Javaの書き方しらん、インターフェースのメソッドを実装することを定義したい
public void View.OnClickListener.onClick(View v) {
AlertDialog.Builder dlg;
dlg = new AlertDialog.Builder(MainActivity.this);
dlg.setTitle("サンプル");
dlg.setMessage("Hello, サンプル!");
dlg.show();
//＜ーー
}
}
// Androidなにも知らんけど、元増田がボタンにイベントを書く処理が書いてあるクラスのことが言いたい
// そのメソッド
final Button button = new Button(this);
button.setText("ダイアログの表示");
button.setOnClickListener(new EventHoge());
}
}
こうやって、クラス分けて書けば、外とか中とか、全く関係なくなるじゃん。
元増田のサンプルだと、メインの中でインターフェースを実装したクラスの実装を書いてるから、中とか外とかがあるんじゃないのか？
自分でクラスとして定義して、そっちで実装すれば、メインは紐づけるだけでよくなって、仮引数？の中で実装しなくてもすむじゃん。
よくわからん。
中が嫌なら外でかきゃいいじゃん。
// Javaの書き方しらん、インターフェースを実装することを定義したい
public class Hoge : View.OnClickListener {
// Javaの書き方しらん、インターフェースのメソッドを実装することを定義したい
public void View.OnClickListener.onClick(View v) {
AlertDialog.Builder dlg;
dlg = new AlertDialog.Builder(MainActivity.this);
dlg.setTitle("サンプル");
dlg.setMessage("Hello, サンプル!");
dlg.show();
//＜ーー
}
}
// メインスレッド的なところ
final Button button = new Button(this);
button.setText("ダイアログの表示");
button.setOnClickListener(new Hoge());
こう書けば、中で書かなくて良い気がするけど、駄目なの？
なんか、インターフェースだから引数の中ってのが意味わからん。
どう関係してるの？
