　表題よりもっともっと複雑な状況にあるジャンルがある。そう、でも誰も知ることも無いし、他のジャンルに比べてものすごくおかしいのに、増田だけ一人で悩んで、そしてそのジャンルの人間は殆ど誰も助けてくれなかった。マナーもルールもはたまた規約すら滅茶苦茶なジャンル。そのジャンル内に居る人間はもう日和見主義しか残っていない。だからこそ誰も声を上げようとはしない。他ジャンルの人たちに聞いてみたら、そういうことはほとんどない、ありえないという回答を頂けた。ただ増田の周りだけの話かもしれない。匿名に頼って、誰かに尋ねてみたくなった。

　まず、Ａ×Ｂの「ＢＬオンリー」があった。そこで、規約上では「一種以上Ａ×Ｂの本さえあれば、他のＣＰやジャンルの本を置いてもいい」が、Ａ×Ｂ以外に「同じジャンルのＮＬのＡ×Ｃのカプ数種類（Ｒ１８の本もあり）」が置いてあったら。皆さんはどう思うだろうか。

　これをかいている増田自身しか、表面上気にも留めなかったのである。しかしながら数年前に同じオンリーが開かれた時は、Ｂ×Ａを持ち込んだ人間が叩かれていたのも見ていた。

つまり今の方がより過疎だからこそ誰も目を向けないということなのだろう。そう、それを持ち込んだ人自身については、いくらかやりとりをした。丁寧な対応でもあったため、そこまで追求はしないし、こちらも言い過ぎた自覚はある。通報するぞとまで言われたので匿名で話していても若干恐ろしくなるが、もう、このジャンルで活動を続けていくのがそもそも限界に達していて、活動をやめてもいいとすら思っているので、どうかその人には見逃してほしいと思う。

　問題は周りなのだ。そのジャンルそのものの問題なのだ。

　十数名が集まるアフターに参加したさい、主催の方（一度もサークル参加したことの無い人間）が言い放った言葉。「ユーリに負けないぞ」と、その参加している人間全員にえいえいおう、とさせたことが増田の中で心にわだかまっている。サークル参加を積極的にこの人数ですればいいんです！とも言われた。

　問題なのがその主催の友人が他カプを持ち込んだりした件についてだ。元々はＡ×Ｂの人間ではない人を、そのオンリーの参加人数が減っているから呼びかけているというのは、負けないぞという発言で容易に察することが出来る。サークル参加人数が少なく、次回開催されないかもしれないということを危惧しての行為だ。

　しかしこれは問題のはき違えだ。人が集まればそういう細かい問題にも誰かが注意したり、もっと騒ぎになっている筈だ。以前、松界隈で逆カプの人間が～などということが注目され、何万かＲＴされていたのを目撃した。それ以上の事が起きているにも関わらず、誰も目も向けない。気にも留めない。それはジャンル規模が縮小していることに他ならない。それに気がつかず、人気の「ユーリ」を持ち出して話をする、という行為が理解出来なかった。そもそもユーリにこのジャンルから数人が以降した際に、何もしていないのに悪口を書かれていることもあった。他ジャンルと比較する行為自体、Ａ×Ｂそのものに失礼で、余りにも無責任な発言と行為だ。

　そしてそれを主催の人も理解していることは明白だった。増田がそのアフター内容を全部メモに書いて載せようと思い（勿論皮肉も込めてだった）一応確認を取ったら止められた。本当にそのまま記載してもよかったことだったが、主催してくださったことには感謝していたので、それはしなかっただけの話だ。

　そして、他カプを持ち込んだ人間は他にもいた。しかしそれはその前述の人と友人で、増田とのやりとりを知っていたのだろう「他カプ本は机の下で頒布します」と告知があった。その人をＤさんと仮定しよう。そこでその別の友人のＦさんがリプライで「気にすることはない」そして空リプで「地雷で勝手にしね」という発言があった。そもそもＦさんはＡ×Ｂオンリーの人間を毛嫌いしている。Ａが棒にされていて～Ｂがなよなよ～など、Ａ×Ｂの人間の二次創作を批判している。

そして、Ｄさんはまた別の人と一緒にサークル参加する際、規約違反を犯していた。これは内容的に具体的には言えないが、スタッフに注意されるレベルのことであった。サークル参加する人間なら決してしない行為をしていたのにも関わらず、Ｄさんと一緒に参加した人々はＡ×Ｂの人たちへの嫌味ともとれるような表現を止めない。

　そして、これに腰を上げた人が居た。Ｂ×Ａ、逆カプの方だ。流石に、オンリーで他カプは別のジャンルだったら叩かれる要因になるのでは、そして表のアカウントでＡ×Ｂの人たちを悪く言うのはやめた方がいいと注意を軽くした。しかしその後、その他カプの人々からの返答は殆どなく、しばらく、異常なほどに無視されていた。それに耐えかねて、ブロック等処置を取れば、今度はその人々が、逆カプの方を叩き始めた。仲よくしていた筈なのに、裏垢にリプライしていた表垢の人が誹謗中傷で法律違反、警察に言えるレベルだ、とまで言い放っていた。逆カプの方はとうとうアカウントを消してしまい、数名しかその真実を知る由もなく、糾弾する声もなく、終わってしまった。

　増田もこれをかいていて、これが誹謗中傷だ、警察だ、と言われたら非常に困る。というか、そういうことをこういうやりとりで言えてしまうことが最早恐ろしくてならない。もうこのジャンルを正直辞めたい。イベントにも参加したくない。アカウントも消して何もかも無かったことにまでしたい。何度かそれをしようと試みたが、やっぱりＡ×Ｂが大好きでたまらない。今後も好きで居続けたい、という気持ち、他の方の二次創作を見ていたという気持ちとの葛藤で何とか続けている状態だ。

　他のジャンルだったならおかしいと声を上げる人が居たんだろうと心から思う。大事にしていたアカウントを消すと宣言してまで色々な事を言ったが、あまりにもジャンル内の人々に伝わらず、絶望しかない。というか、マシュマロで「悪意がある人達が居ます。でもその人たちも貴方も好きです。だから収まるまで貴方はアカウントを消した方がいい」という面白おかしいものまで入っていたから、誰が見ても悪意があるのだなということもわかる。

　正直に個人でやりとりしても、サークル参加したこともない、Ａ×Ｂをよく知らず、Ａ×他を目当てにしてイベントに参加する第三者に「頭がおかしい」と罵られたり、規約違反をしていた人に「自分でわからない範囲なのに掻き乱しているとかバカじゃないか」とも言われたり、尚且つ他言無用とお話したのに誰かに話が通っていたり。そんなことがたくさんあった。

　そしてこれが、もしそのジャンルで回ってきて「へえ、こんな話があったんだ、怖いな」などと言っている人がいたら、増田は鼻で笑う。何も知ろうとしない、平和で居ると勘違いした人しかいないジャンルなのだと、改めて認識させられるからである。

　本当に心の底から疲れ切った。この文章を何度も何度も頭の中で構築して、でもやめよう、書こう、と自問自答した。勿論通報等の言葉を恐れてのこと。時折見かける「好きな物を書いている人に文句を言うな」には前述で増田も当てはまってしまうことから、辛い気持ちになる。でもどうしようもなかった。誰も、本当に誰も、年齢が上だろうと何だろうと気がついてないからだ。

　このジャンルで他に駄目なことは。一般参加のグッズ配布、受注限定販売、アクリルスタンド販売など、色々本当にありすぎる。全部、全部ユーリで叩かれていることだ。それを、ユーリより人気がないからこそ適当に済んでいるそれに、どうして気がつかないのかがわからない。そもそも数年後にまた動きがあるからこそ、人が集まったら問題が浮き彫りになることも誰も危惧しない。

　Ａ×Ｂが好きじゃない人達が、Ａ×Ｂオンリーを荒らすような真似をしてばかりで、心が痛い。好きだったならもう少し理解できたんじゃないかと淡い期待も抱けたものだ。これは固定雑食云々ということですらないのだ。Ａ×Ｂに失礼な事をしないでほしかった。でも結果的に一番増田が失礼なのかもしれない。

　はてなを使うのは初めてなので、一人称を増田、にしてしまったが、これが浅はかな行為なのかすらわからない。支離滅裂、浅い知識で何もかも台なしにしてしまうかもしれない。でももう、本当に誰かに聞いてほしかった。このジャンルを特定出来る人がいたとして、増田のアカウントに凸して悪意を言われたら、即座にジャンルから撤退しようと思っている。

　そもそもここに記載出来ない、もっともっとよくない事実がある。それを向こうの人たちは好き勝手話しているかもしれないのに、自分は匿名でも言えないことも苦しい。

　話を聞いてくださったり、陰で助けてくださった方にもご迷惑をかけるかもしれない、本当に申し訳ないです。

Permalink | 記事への反応(0) | 00:57

2018-11-12

■「言われなかった」ってクレームほど的外れはものはないよな

内容によるけど、サービスの説明だなんだかんだと事細かに全て言うわけがない。

なぜならそんなに言っていてもお客様も覚えられないからだ。

（だから規約だなんだかんだと文章で書いたりする）

言われなかったって、聞かなかったじゃんとも

逆に言えるわけでもあるので、

聞かないってことは感心が低いとも言えるだろうでしょ。

まあその場合「こっちはプロじゃないからそんなの普通知らないという」逃げ口上をお客さんは持っているので

説明責任だけを追求されることになる。

となると説明するわけだがお客さんの方に感心がなければ大抵意味がない。

説明不足というのはだいたい得てして難しいのだ。

わかりやすく伝えるには簡略化する必要があり、

簡略化したところにクレームが発生しがちなので詰む。

これはサービスという自身の構造的な欠陥なのではないかと思う。

（なぜなら同じ説明しようとすると知識がイコールになる必要があるので、

サービス自体が回りづらくなる）

結局のところ、この手のクレームはだいたい詰むようになっている。

なんか上手な返し方とかないのかな。知りたい。

具体的な業務でいうと、

普段なら美容院や理容院、病院とか、オーダーメイドなサービスのところ、あとはサービスセンター窓口か。

BtoBなら広告代理店や制作系とかか。

もちろんはこれは一例でどんな業務でもあることだと思う。

もう少し互いに寄り添えばいいだけなのになと思う。

全ては忙しい日本がいけないんだと思う。

忙しいから他人や周囲に興味を持ちづらくなる。

肉体だけで考えようとするからそうなるんだよ。

Permalink | 記事への反応(1) | 19:33

■anond:20181112010150

規約守らないやつを即垢バンしてたらそうなったんだろ

Permalink | 記事への反応(1) | 01:04

2018-11-07

■いわゆる徴用工問題

はてなブログで規約違反行為をしまくって運営から警告喰らったときに「そもそもお前の規約は不当だから無効だ。よって規約を守る義務は俺にはないし、規約違反を理由に運営が俺のアカウントを停止するなど絶対に許されない」と言い出すようなもんだ

Permalink | 記事への反応(0) | 14:26

■anond:20181107113501

ジャッポネ土人らはお気持ちで通報してくるから、お気持ちか規約に則った通報なのかを判断するのに4ヶ月かかるんじゃね。

Permalink | 記事への反応(0) | 11:37

2018-11-05

■[NHK] 平成31年 2月 から、お金のない学生さんは某協会 放送 受信料 免除！

そう言えば、9月頭にこれも言っとったな。

これまで散々脅迫しておいて、ぶっちゃけ、いまさらやわ。

んなの、少なく見積もっても、30年も遅いわ。

2018年【9月10日】

「日本放送協会放送受信規約および放送受信料免除基準の一部変更について」

http://www.nhk.or.jp/pr/keiei/otherpress/pdf/20180910.pdf

以下、抜粋。

①奨学金受給対象などの学生への免除（施行日：平成３１年２月１日）
　親元などから離れて暮らす学生（生計をともにする方がいない学生を含む。）のうち、次のいずれかの要件に該当する学生を全額免除の対象とします。
○奨学金受給対象の学生
○授業料免除対象の学生
○市町村民税非課税世帯の学生
○公的扶助受給世帯の学生

参考：総務省報道資料平成30年9月10日日本放送協会放送受信料免除基準の変更の認可 http://www.soumu.go.jp/menu_news/s-news/02ryutsu07_04000199.html

↑でも、この免除申請（登録）はマジでやめとけ（になるはず）！　正確には、某協会に申請する書類内容に依存する。

なぜやめておくべきか、それは自分で考えて、気付いてください。

Permalink | 記事への反応(1) | 13:00

2018-11-04

■増田式プログラマー 養成講座　その17　Web アプリの骨組み

前回は、Web アプリの完成見本を先に見てみました。

今回は、Web アプリを作る途中の過程を見て、作る雰囲気を一緒に味わってみましょう。

フレームワークの使用 ルール＝「設定より規約」＝手抜きをする仕組み

最近のフレームワークは、「設定より規約」（CoC、convention over configuration）という発想で作られている。

フレームワークの規約（使用ルール）に従うと、プログラマーは作業量が減って、楽ができる。

（参考）設定より規約 - Wikipedia https://ja.wikipedia.org/wiki/%E8%A8%AD%E5%AE%9A%E3%82%88%E3%82%8A%E8%A6%8F%E7%B4%84

設定より規約（convention over configuration）とは、開発者の決定すべきことを減少させ、単純にするが柔軟性は失わせないというソフトウェア設計パラダイム。
使用しているツールが実装した規約が開発者の望む動作と一致していれば、設定ファイルを書く必要もない。実装規約と望みの動作が違っている場合、必要な動作を設定しなければならない。
　
最近のフレームワークは「設定より規約」アプローチを採用しているものが多い。
例えば、Ruby on Rails、Kohana、Grails、Grok、Zend Framework、CakePHP、Symfony などがある。

CodeIgniterの使用 ルール

CodeIgniterの使用ルールは、マニュアルやチュートリアルで確認できる。

（参考）アプリケーションフローチャート — CodeIgniter ドキュメント https://codeigniter.jp/user_guide/3/overview/appflow.html

↑このページの「アプリケーションフローチャート」を見てみよう。

一番左の「index.php」が、Web アプリの入口になっている。（エントリーポイント、フロントコントローラーパターン等ともいう）
左から2番目の上段「Routing」で、URLに応じて、仕事の振り分け先を決定する。（ディスパッチ、マッピング、ルーティング等ともいう）
左から4番目の「Application Controller」で、具体的な処理の指示を出す。
1. Application Controllerは、「Model」に必要なデータを用意させる。
2. Application Controllerは、「View」に表示用の画面を作らせる。
3. Application Controllerが、index.phpに表示用の画面を渡す。
表示用の画面（最終的な処理の結果）を受け取った「index.php」は、ユーザー（ブラウザー）に画面を渡す。

このうち、プログラマーが作って用意するのは、基本的に「Application Controller」と「Model」と「View」の3カ所だ。（その他の部分も必要に応じて作る）
フレームワークによっては、自動的にModelやViewのひな形を作ってくれる「スキャフォールディング」（Scaffolding）という機能も用意されている。

それでは、CodeIgniterでプログラマーが用意する部分のM（Model）とV（View）とC（Application Controller）を、骨組みから作ってみよう。

事前準備として、前々回と前回のWeb アプリ完成見本を用意するところまでやっておこう。

anond:20181101225335　増田式プログラマー養成講座　その15　Web アプリの完成見本
anond:20181101230220　増田式プログラマー養成講座　その16　Web アプリの完成見本（続き）

スケルトンとは？

スケルトン - Wikipedia https://ja.wikipedia.org/wiki/%E3%82%B9%E3%82%B1%E3%83%AB%E3%83%88%E3%83%B3

スケルトン（skeleton, 骨格）とは動物や人間の骨格。
コンピュータのプログラムコードの骨格部分。プログラムコード作成では、初期段階でスケルトンを作成し、その後で詳細部分を肉付けしていく。

Application Controllerの骨組み

まずは、MVCのCの骨組みを作ろう。

Controllerは、ユーザーからのリクエストを受け付けて、ModelやViewに指示を出す監督です。

（参考）コントローラ — CodeIgniter ドキュメント https://codeigniter.jp/user_guide/3/general/controllers.html

設置フォルダ：　C:\xampp\htdocs\waf\application\controllers
設置ファイル：　Welcome.php

上記フォルダの中に「Welcome.php」というファイルを作る。（デフォルトであるはずなので、それを使ってOK）

CodeIgniterのルールで、Application Controllerを置く場所は「application/controllers」というフォルダになっている。

CodeIgniterのルールで、一番最初に呼び出されるApplication Controllerは「Welcome.php」というファイルになっている。

→これは「C:\xampp\htdocs\waf\application\config\routes.php」という設定ファイルで決められている。

$route['default_controller'] = 'welcome'; // 別の名前にすれば変えられる。

「Welcome.php」の中身を以下にように変更する。

<?php
defined('BASEPATH') or exit('No direct script access allowed');
　
class Welcome extends CI_Controller
{
　// 初期画面
　public function index()
　{
　　echo "Here is index()";
　}
　// 更新画面
　public function update()
　{
　　echo "Here is update()";
　}
　// 削除画面
　public function delete()
　{
　　echo "Here is delete()";
　}
}

これがチャットのApplication Controllerとして動作する最小限の内容＝骨格だ。

継承

class Welcome extends CI_Controller

という行に注目してみよう。

CodeIgniterで用意されてる「CI_Controller」クラスを継承して、プログラマーが「Welcome」クラスを作ってる。

継承によって、フレームワークが用意してる様々な機能をWelcomeクラス内で使えるようになる。

URL（リクエスト）とControllerの対応（マッピング）のルール

「Welcome」クラスの中に、「index()」「update()」「delete()」という３つのメソッドを用意した。

CodeIgniterのURLは、Action Controllerのクラス名やメソッド名とひもづけられている。

（参考）CodeIgniter の URL — CodeIgniter ドキュメント https://codeigniter.jp/user_guide/3/general/urls.html

今回作るWeb アプリだと、

「http://localhost/waf/クラス名/メソッド名」

という対応関係になっている。

（例）

http://localhost/waf/　　　　　　　　→Welcomeクラスのindex()メソッドが呼び出される。

http://localhost/waf/welcome/index 　→Welcomeクラスのindex()メソッドが呼び出される。

http://localhost/waf/welcome/update　→Welcomeクラスのupdate()メソッドが呼び出される。

http://localhost/waf/welcome/delete　→Welcomeクラスのdelete()メソッドが呼び出される。

Viewの骨組み

次にMVCのVの骨組みを作ろう。

ビューは、表示する画面の部分です。HTMLでWebページの構造を書きます。

（参考）ビュー — CodeIgniter ドキュメント https://codeigniter.jp/user_guide/3/general/views.html

設置フォルダ：　C:\xampp\htdocs\waf\application\views
設置ファイル：
- welcome_index.php　＝トップページの画面
- chat_update.php　　＝投稿を更新する画面
- chat_delete.php　　＝投稿を削除する画面

welcome_index.phpの編集

以下の内容にして保存する。

<?php defined('BASEPATH') OR exit('No direct script access allowed'); ?>
<!DOCTYPE html>
<html>
　<head>
　　<meta charset="utf-8">
　　<title>増田チャット</title>
　　<base href="<?php echo base_url(); ?>">
　</head>
　<body>
　　<h1>増田チャット</h1>
　　<h2>新規投稿</h2>
　</body>
</html>

chat_update.phpの編集

以下の内容にして保存する。

<?php defined('BASEPATH') or exit('No direct script access allowed');?>
<!DOCTYPE html>
<html>
　<head>
　　<meta charset="utf-8">
　　<title>増田チャット</title>
　　<base href="<?php echo base_url(); ?>">
　</head>
　<body>
　　<h1>増田チャット</h1>
　　<h2>編集</h2>
　</body>
</html>

chat_delete.phpの編集

以下の内容にして保存する。

<?php defined('BASEPATH') or exit('No direct script access allowed');?>
<!DOCTYPE html>
<html>
　<head>
　　<meta charset="utf-8">
　　<title>増田チャット</title>
　　<base href="<?php echo base_url(); ?>">
　</head>
　<body>
　　<h1>増田チャット</h1>
　　<h2>削除</h2>
　</body>
</html>

View ファイルの追加に合わせて、Controllerも一部変更します。

Welcome.phpの編集

<?php
defined('BASEPATH') or exit('No direct script access allowed');
　
class Welcome extends CI_Controller
{
　public function __construct()
　{
　　parent::__construct();
　　$this->load->helper('url');
　}
　
　// 初期画面
　public function index()
　{
　　$this->load->view('welcome_index');
　}
　
　// 更新画面
　public function update()
　{
　　$this->load->view('chat_update');
　}
　
　// 削除画面
　public function delete()
　{
　　$this->load->view('chat_delete');
　}
}

（変更点の説明）

コンストラクターの追加

コンストラクター「__construct()」は、クラスからインスタンスが作られるとき、自動的に実行されるメソッドだ。コンストラクターは、初期化＝最初にやっておくべき下準備を書いておく。

$this->load->helper('url');

CodeIgniterには、リンクの表示を補助する「URL ヘルパー」という機能が用意されている。

上記のように書くとURL ヘルパーを呼び出して、使えるようになる。

（参考）ヘルパー関数 — CodeIgniter ドキュメント https://codeigniter.jp/user_guide/3/general/helpers.html

各View ファイルの以下の行でURL ヘルパーを使っている。＝「base_url()」という関数がURL ヘルパーの１つ。

<base href="<?php echo base_url(); ?>">

ビュー読み込みメソッドの追加

$this->load->view('welcome_index');

というメソッドによって、View ファイルの「welcome_index.php」を呼び出し、画面を出力します。

これでMVCのCとVの骨組みができた。

今の段階でWeb ブラウザーで各ページを表示させると、各View ファイルの中身が表示される。

Modelの骨組み

次にMVCのMの骨組みを作ろう。

モデルは、具体的な処理内容（ロジック）を書いて、データを読み書きする部分です。

データベースを操作するSQL文もモデルに書きます。

（参考）モデル — CodeIgniter ドキュメント https://codeigniter.jp/user_guide/3/general/models.html

設置フォルダ：　C:\xampp\htdocs\waf\application\models
設置ファイル：　Chat_model.php

上記フォルダの中に「Chat_model.php」というファイルを作り、以下の内容にして保存する。

<?php
defined('BASEPATH') or exit('No direct script access allowed');
　
class Chat_model extends CI_Model
{
　public function __construct()
　{
　　parent::__construct();
　　$this->load->database();
　}
}

CodeIgniterで用意されてる「CI_Model」クラスを継承して、プログラマーが「Chat_model」クラスを作ってる。

「Chat_model」クラスのコンストラクターには、以下のように書いている。

$this->load->database();

これは、データベースを使用する準備だ。

（参考）データベース Quick Start: コードの例文 — CodeIgniter ドキュメント https://codeigniter.jp/user_guide/3/database/examples.html

Modelの追加に合わせて、さらにControllerも一部変更します。

Welcome.phpの編集

<?php
defined('BASEPATH') or exit('No direct script access allowed');
　
class Welcome extends CI_Controller
{
　public function __construct()
　{
　　parent::__construct();
　　$this->load->model('chat_model');
　　$this->load->helper('url');
　}
　
　// 初期画面
　public function index()
　{
　　$this->load->view('welcome_index');
　}
　
　// 更新画面
　public function update()
　{
　　$this->load->view('chat_update');
　}
　
　// 削除画面
　public function delete()
　{
　　$this->load->view('chat_delete');
　}
}