  |
はてなキーワード: エラーとは
iphoneのバッテリー交換が2018年12月まで3200円でできるということで、WEBで予約してappleの正規サービスプロバイダに持ち込みました。
予約せずに来店している人も多数です。
受付して30分ほどで返却できるというので、時間をつぶして引き取りに行ったところ、エラーがでたので初期化するとのこと。そして、初期化しても直らない場合は、本体を有償か無償で交換することになる可能性があるとのこと。え、今まで普通に使えていたのに有償交換ってあるんだ・・・
嫌な予感が・・・・
また、初期化するのに時間がかかるというので、しばらくして再び来店
本日、使うのであれば有償で本体を交換します。appleのサポートセンターに問い合わせたいが、日曜は休みなので明日の対応となり、数万円払って有償交換か無償交換かはappleが判断するとのこと。←いまココ
ちなみに、持って行った時の状態で返却はできないのか聞いてみたけど、現状では通話もインターネットの閲覧もできない状態なので返却しても何もできないと言われました。
今まで何の支障もなくiphoneを使用できたのに、バッテリー交換をしようと思って持って行ったら1日iphoneが使えなくなりました。1日使えないだけでも相当ストレス、支障ありありなのですが、これで有償交換だったら最悪だなぁ。
さて、明日、どうなるか。
続きは後日書きます。
前回に続いて、今回もオブジェクト指向プログラミング（OOP）の基本的な仕組みを見ていこう。
OOPに関係してる#18から#24までのうち、後半の#22から#24までを一緒に見てみよう！
クラスベースのOOPでオブジェクトを使う場合、普通は「クラスからインスタンス（オブジェクトの具体的な実体）を作ってから使う」と説明した。
実は、newでいちいちインスタンスを作らなくても、クラスのメンバー（プロパティーやメソッド）を直接呼び出して使える仕組みも用意されている。
それが「static」（静的）という仕組みだ。
「静的」（static）という言葉は、「動的」（dynamic）の対義語になっている。
newでインスタンスをポンポン作っていくのが「動的」なら、new無しでコッソリとメンバーを呼び出すのが「静的」というかんじ？
PHPでは、インスタンスを作らなくても、直接（静的に）呼び出せるメンバーには「static」という目印を付けておく、という文法になってる。
さらに、
それではstaticなメンバーを入れたクラスを定義してみよう。
// プロパティー：インスタンス変数（staticなし。newした後じゃないと使えない）
public $name;
// プロパティー：静的変数（staticあり。newなしでいきなり使える）
public static $count;
}
文法的には「static」という印を付けるか、付けないかの違いしかない。簡単だ！
次は、staticなメンバーの呼び出し方を見てみよう。
ちょっと待った！「演算子」という言葉は初めて出てきたね？意味を確認しておこう。
1+2は3になる等、対象（1とか2とかの数値データ）を操作（＝演算）して、3という結果を得られる。
「::」はスコープ定義演算子とか、ダブルコロンと呼ばれている。PHPマニュアルでは以下のように説明されている。
静的メンバーを呼び出す専用の記号として「::」という演算子（記号）が用意されている、というわけだ。
つまり、「::」という演算子を使うことで、静的メンバーを操作できる。
それでは、「::」を使って、静的メンバーを呼び出してみよう。
// プロパティー：インスタンス変数（staticなし。newした後じゃないと使えない）
public $name;
// プロパティー：静的変数（staticあり。newなしでいきなり使える）
public static $count;
}
// new無しでいきなり使える！
User::$count = 1; // 1を代入する。
実行すると
「PHP Fatal error: Uncaught Error: Access to undeclared static property: User::$name」
というエラーメッセージが表示された。
「staticなプロパティーとして定義されてないから、アクセスできないよ！」と怒られた～～～（涙）
staticじゃないメンバーには、ちゃんとnewしてインスタンスを作ってからアクセスしないと、使えないんですね。（面倒）
オブジェクトのメンバー（プロパティー、メソッド）に、オブジェクトの中のメンバーがアクセスするとき、
という使い分けになってる。単にこれはPHPの文法なので、特に悩む余地はない。
// 普通のプロパティー：インスタンス変数（staticなし。newした後じゃないと使えない）
public $name; // ←この$nameをこの下にあるをhello()から使いたい
public function hello() {
echo "Hello, " . $this->name; // this->で指定する
}
}
$this->nameで、オブジェクト（この場合はインスタンス）内の$nameにアクセスできる。
// staticなプロパティー：静的変数（staticあり。newなしでいきなり使える）
public static $name; // ←この$nameをこの下にあるをhello()から使いたい
// staticなメソッド
public static function hello() {
echo "Hello, " . self::$name; // self::で指定する
}
}
// new無しでいきなり使える！
self::$nameで、オブジェクト（この場合はクラス）内の静的な（staticな）$nameにアクセスできる。
「this」とか「self」とか、いちいち使い分けていて面倒くさいなーと思うだろう。
なんでこんなことをやってるか？というと「スコープ」という仕組みが関係してる。
ドットインストールのPHP入門でも、#16でちょっとスコープについて説明してあった。
「スコープ」（scope, 可視範囲）は、元々は潜水艦に付いてる望遠鏡（潜望鏡）のこと。
プログラミングでは、あるデータ（変数とか）がどこまで見えるか、覗けるか、という範囲のことを「スコープ」と呼んでる。
変数や関数がどの範囲まで有効なのか、使えるのかは、その変数や関数のスコープで決まっている。
Wikipediaで「スコープ」の説明を見ると、ゴチャゴチャ書いてあるけど、要するにスコープには、広い範囲や狭い範囲があるってこと。
thisやselfをわざわざ使い分けているのは、範囲を指し示すときに、
それとも
thisを使ってたら、「ああ、newしてインスタンスを作らないと使えないんだな」と分かる。（インスタンスの中の話）
staticとselfを使ってたら、「newしないで、静的に使えってことだな」と分かる。（クラスの中の話）
太郎の$nameとか、花子の$nameとか、インスタンスの場合は、各インスタンスのメンバーは、明確に分かれていて、両者が混ざることはない＝別々のスコープになってる。
クラスの静的メンバーは、そのクラスに1個しかないので、そのクラスをnewしないで（インスタンス無しで直接呼出したときは）、いろんなところから呼び出されても、共通の中身になってしまう＝スコープが1個、同じスコープになってる。
インスタンス変数とクラスの静的変数は別物なので、thisとselfで使い分けてる、というわけだな！
ここまで読むと「staticって面倒くさいやつだな！なくてもいいじゃん！」と思っただろう。その通り！
staticは使わなくて済むなら、なるべく使わない方がいい。
「static 欠点」で検索してもらえば、staticを使った場合の問題点が紹介されている。
どうしてもstaticじゃないと実現できないこと、staticの方が便利な場合だけ、staticを使うようにしよう。
（参考）PHPのstaticの使い方
具象クラス（今まで勉強してきた普通のクラス）だけではなく、「抽象クラス」という特殊なクラスを作る仕組みも用意されている。
抽象クラスは、継承してその子クラスを作るとき、「必ずこのメソッドを自分で作れよ！」などと強制できる。
つまり、クラスの利用方法（継承とか）について、プログラマーに指示を出せる働きがある。
抽象クラスの特徴として、具象クラス（通常のクラス）との違いを挙げます。
抽象メソッドとは、実際の処理を自身にではなく子クラスに記述させるためのメソッドです。
この抽象メソッドを記述できることが、抽象クラスの最大の特徴です。
抽象クラスを継承したクラスは、この抽象メソッドを必ず「オーバーライド」しなければなりません。（オーバーライドしないとコンパイルエラーとなります。）
OOPの継承には、「単一継承」と「多重継承」という種類がある。
普通は、「単一継承」といって、親クラスから子クラスを継承して作るとき、親クラスは1個だけしか指定できない。（１：１）
クラスA、クラスB、クラスCの３つを親クラスとして、クラスZという子クラスを継承して作る仕組みは、「多重継承」という。多重継承が可能な場合、子クラスは複数の親クラスを持てる。（多：１）
PHPやJavaでは、多重継承ができない代わりに、「インターフェース」という仕組みが用意されている。
インターフェースを使うと、多重継承と似たようなことができる。
↑ここにクラスとインターフェースの相違点がまとめられてたので、参考にしてみてください。
interface sayHi {
public function sayHi();
}
public function sayHello();
}
class User implements sayHi, sayHello {
public function sayHi() {
echo "hi!";
}
public function sayHello() {
}
}
$taro = new User; // コンストラクターに渡す初期データがない場合「new User();」みたいに「()」を付けなくてもOK
$taro->sayHi(); // hi!
#22から#24までを見て、PHPのOOPの基本的な仕組み～使える機能について見てきました。
PHPには、他にもいろんなOOPで使える機能が用意されています。
Javaなど他のプログラム言語には、PHPにはないOOPの機能も用意されています。
オブジェクトを利用するときの仕組みとして、いろんな方法が考えられてます。
使う機会があれば調べてみましょう。
ここまでで、やっとOOPの基本的な仕組み、用意されている機能やテクニックを学びました。
次回は、なぜこんなOOPの仕組みが考え出されたのか？どうやってOOPを活用していくのか？を見ていきましょう。
anond:20181015215004 未経験からのプログラマーなんだが全然分からない
anond:20181016015826 増田式プログラマー養成講座 その１ パソコンの用意
anond:20181016164341 増田式プログラマー養成講座 その２ プログラム＝データ＋処理、プログラム言語の種類
anond:20181016180059 増田式プログラマー養成講座 その３ 構造化プログラミングの基本（順次、反復、分岐）
anond:20181016193144 増田式プログラマー養成講座 その４ 子ども向け教材「Scratch」で構造化プログラミングの練習
anond:20181017161003 増田式プログラマー養成講座 その５ オブジェクトとは何か？
anond:20181017191404 増田式プログラマー養成講座 その６ OOPの種類、PHPの準備
anond:20181019181549 増田式プログラマー養成講座 その７ OOPの仕組み（前半）
anond:20181020230044 増田式プログラマー養成講座 その８ OOPの仕組み（後半）
イケイケ新卒のサーバーサイドエンジニアのお客さんが作ってくれるAPIの仕様がクソすぎて辛い。
お前さ、UIとかちょっとは考えたことある？ていうか画面デザイン資料みてくれたよね？っていうレスポンスなんだ。
例えば画像が並んでいるようなコンポーネントがあったとする。で、画像の種類がAとBの2タイプあるとき
[{
type: A,
image: {
source: https://~~
},
},
{
type:B,
source:{
original: {
Horizontal: https://~~
},
}]
っていうのを平気でだしてくる。いやそうじゃなくてどうせpタグとimgタグに入れんだから同じ形式でほしいんだが。ていうかHorizontalってなに。
しかしなぜだか伝わらない。なぜだ。
しかも「自分はデザインについては本をたくさん読んでいるし学校でも習って知ってますから」といってUIの話を全く聞いてくれない。
SPAのときのAPI設計もクソで、注文の内容を送って受理されたら進行のステータスが変わるのだが
「内容送って成功したら、次のステータスをフロントで計算してパラメータで入れて別のAPI叩いてください。内容受け取るやつとステータス変えるのと２つ作っとくんで」
みたいなのが出てくる。電話口でいやそうじゃなくて、、、といっても聞いてもらえない
「あ〜、たしかに〜それは全く考えてないですw」と言われた時。なんとかしてくれ。
今日「ま〜〇〇社の〇夫さんは通信のこと全然わかってないみたいなんでwwwフロントエンドエンジニアとはとても呼べたもんじゃないですね〜ww」と上司にいっているのを聞いてしまった。
我が大学には、Web上で学校側に気軽に質問や意見ができるサービスがある。加えて、病気の欠席については病気の期間等の基準を満たしてさえいれば、欠席扱いにはせず、病欠のとなる制度もある。
病気と診断されてはいるものの、基準を満たしているか不安であった。また、女性特有で個人差が大きい病気のため、教授個人に断るとなると、認めない男性教授や生理痛の軽い女性教授もいて欠席となってしまうかもしれない、学校側の承認があったほうが良いと考えた私は、質問サービスで尋ねてみた。
「月経困難症及び月経前症候群と診断されており、生理前後の〜日間講義に出ることが難しかったのですが、病欠の基準は満たしていますか？」
えっ？生理ってNGワードなの？それとも通信エラーによるバグ？
一応「月経」に変えてみるか。
「月経困難症及び月経前症候群と診断されており、月経前後の〜日間講義に出ることが難しかったのですが、病欠の基準は満たしていますか？」
「持病があり、〜日間講義に出ることが難しかったのですが、病欠の基準は満たしていますか？」
某有名女子大学が、心が女性であれば入学を認める。と公表し、世間を良い意味でざわつかせ、ジェンダーの悩みは広く周知されてきたのだと思っていた。
きっと同じく生理痛で悩む先輩方も、同じ質問をして、同じく理解されないことに苦悩したはずだ。
私がひどく悩み苦しんできた「生理」は、この大学では下品な言葉にカテゴライズされるようだ。
思わず涙が溢れ、この大学に嫌気がさした。大学ってもっと、考えが広くて、年齢性別問わず学びを認める場ではなかったのだろうか。
男尊女卑が昔より無くなったとは言え、壁はまだ厚いようだ。
意見フォームに「生理や月経が禁止ワードに設定されているのは明らかにおかしい。性別差別の一種である。」と書き込もうかと思ったが、次に表示される文字はわかりきっていた。
日本がもっと、性や病気の悩みに寛容な国になるために、私も少しでも広げ理解される為の活動をしたい。
寧ろ今の時代はどのLL言語でも静的解析型付け必須とかだけどな。
それではさっそく、一番簡単な手続型プログラミング言語の使い方を学んでみよう。
「構造化プログラミング」でGoogle画像検索すると、分かりやすそうな図があった。
買物を例に挙げて、「順次」「反復」「分岐」の３つの動作を使ってみよう。
このように構造化プログラミングは、人間の動作と同じだ。やることをズラズラ書いていけばいいだけだ。
「最低限これだけはないとダメ」という項目を箇条書きにしておこう。
買物プログラムなら、
などが必要だろう。
単純なプログラムだと処理が少ないので混乱しないが、複雑なプログラムだと処理が多くて混乱するだろう。
あらかじめ、処理を図に書き出しておくと混乱せずに済む。その図が「フローチャート図」だ。（フローチャート図の書き方は自分で分かりやすい説明を検索してみてくれ。説明省略）
実務では納品時の成果物としてフローチャート図の提出を求めらていなければ、面倒なので作る必要はない。自分のための図なら、ノートにチャチャっと落書き程度に流れ図を描けば十分だろう。
フローチャート図を基にして、実際のコードを書く前に、人間の言葉で「疑似コード」を書いてみよう。
擬似コード（pseudocode）とは、アルゴリズムなどを、架空の非常に高水準なプログラミング言語（擬似言語）で記述したものである。
例
番号と注文で取引をする
else
エラーを表示する
end if
個人的に最良だと思う方法は、プロジェクトの各パートにおいてなにが求められるのかを具体的に書き出すことです。
このとき、まだコードを書かずに言葉だけで記述するのがカギです。
pseudocodeなら構文を気にすることなく、プロジェクトの動作だけに思考を集中できます。
カウントダウン時計の場合なら、書き出した内容は次のようになるでしょう。
要するに「擬似コード」とは、人間に意味が分かる言葉でコードっぽいものをあらかじめ書いておき、後でそれを具体的なプログラムコードに書き換えていく方法だ。
いちいち面倒だけど、最初慣れないうちは、こうすれば間違えにくいだろう。
擬似コードと似た方法として「文芸的プログラミング」という方法もある。
面倒なので実務では使わないが、このような補助的手段もある、と紹介しておく。
Javaと関係する点で考えると、Javaには「アノテーション」（注釈）という機能がある。
プログラムに「注釈」となる記述をちょこっと書いておくと、プログラムの動作について細かな指示が出せる機能だ。（学習が進んでから、後で「Java アノテーション」を検索して学んでみよう）
次回は、子ども向けプログラミング教材「Scratch」を使って、実際に構造化プログラミングの３つの動作を練習してみよう。
anond:20181015215004 未経験からのプログラマーなんだが全然分からない
anond:20181016015826 増田式プログラマー養成講座 その１ パソコンの用意
anond:20181016164341 増田式プログラマー養成講座 その２ プログラム＝データ＋処理、プログラム言語の種類
anond:20181016180059 増田式プログラマー養成講座 その３ 構造化プログラミングの基本（順次、反復、分岐）
anond:20181016193144 増田式プログラマー養成講座 その４ 子ども向け教材「Scratch」で構造化プログラミングの練習
anond:20181017161003 増田式プログラマー養成講座 その５ オブジェクトとは何か？
anond:20181017191404 増田式プログラマー養成講座 その６ OOPの種類、PHPの準備
anond:20181019181549 増田式プログラマー養成講座 その７ OOPの仕組み（前半）
anond:20181020230044 増田式プログラマー養成講座 その８ OOPの仕組み（後半）
とりあえず、声をあげてたほうが良いと思うよ。
要は、アラートをあげていましたよ、ってことね。
期日に成果物が全くありません、っていう状況だけは、絶対に避けたほうが良い。後で問題が発生した時に、責任問題になる。
上司に相談して、それでダメなのが現状なんだろうけど、全体にチャットツールなりメーリングリストなりで、相談する。
もしくは、さらに上の人間に対して、現状こうなので自分を放置したままだと炎上しますよ、と伝えておく、とかかな。
あたりかな。完全に自分視点なので、元増田には合わないかもしれない。
あと、質問の時は出来る範囲でいいんで、ちょっと（10～15分くらい）調べて、自分なりに答えなり推測なりを出したうえで、
『〇〇が分かりません。△△△を調べました。自分は□□□だと考えています』みたいな感じで聞いてくれると、自分だと教えやすい。
最後に、頑張らないこと。無理をしないこと。自分を責めないこと。他の人も言ってるけど、自分もその仕事先が悪いと思う。
実証重視の方々にとっては「物語」の代表に見えるであろう精神分析系の心理療法も、ちゃんと効果が確認されるようになってきたたことです。
それこそ､そのエビデンス(論文)でも提示されればいいんじゃないですかね｡
この辺りのこと?
Jonathan Shedler,"The efficacy of psychodynamic psychotherapy."(American Psychologist 2010)
Falk Leichsenring,Sven Rabung,"Effectiveness of Long-term Psychodynamic Psychotherapy: A Meta-analysis"(JAMA 2008)
精神分析医のフィーリス曰く(1)､フロイト派のセラピーはビクトリア時代の人たちには､うまく機能していたが20世紀半ば以降､人々の｢性格の鎧｣の質が変わり､セラピーはうまく機能せずに行き詰まって失敗することが多かった｡
フロイト派の精神分析法は､｢幼少期の体験が成人してからの人格の基礎となる｣というものが骨子の一つ(2)だが､そのことに大打撃を与える調査が出てきた｡1990年代にマシュマロ実験の文献を詳しく調べたマーティン・セリグマンは、幼年期のできごとが成人してからの人格に影響を与えるということは、ひどい心的外傷や栄養失調があった場合にはありうるかもしれないが、それ以外では有力な証拠がほとんどないと結論づけている(3)。子供時代と成人してからの性質に、ごくわずかな相関は認められるが、それは主に遺伝的（生まれつきの）性質、つまり概して明るいとか気難しいといった性質の反映として説明できるという。
また心理学者のバウマイスター一同がフロイトの提唱する理論的メカニズムの数々を現代の文献と付き合わせて検証したところ､最も最悪な理論が昇華説だということが判明した(4)｡そもそも昇華説には根拠がない上､事実はその逆だと考えられる理由が多いからだ｡
もちろん､フロイトの理論は示唆的で興味深いものが多いし､余談だが｢快感原則の彼岸｣については現代思想の中ではかなり重要な位置づけになっている｡ラカンも執拗にこの論文にこだわるわけだしね｡
それに､フロイトの批判をしたバウマイスターは､フロイトの提唱する説でエネルギーが重要な位置に置かれていることに敬意を表して､フロイトが使っていた自己を指す言葉｢自我(エゴ)｣を使って､｢自我消耗｣という言葉を｢人の思考や感情や行動を規制する能力が減る現象｣に名付けた｡自我消耗に関しては､後に脳波記録検査法(EEG)で脳内の前帯状皮質におけるスパイク発火(エラー関連陰性電位)が対応する脳機能であることが確認された(5)｡
著名な心理学者であるスティーブン・ピンカーは､ 今回で言えば｢人生全体｣｢物語の蓄積｣｢人生の深み｣といったことで､科学の基本的研究方略である「単純化(simplify)」を退けようとしていることに苦言を呈している(6)。 研究の対象をとなる複雑な現象をいろいろなレベルに単純化し、いろいろなレベルごとに 解明していくことを拒んで、複雑な現象をありのままに理解しようとしていたのでは研究はいつまでたっても現状に停滞したままになる。単純化を嫌って、複雑な現象を複雑なままで捉えようとする人文系学問に多く見られるのこうした研究方略を、ピンカーは完全な正確さを求めて「原寸大の地図」 を作った愚かな地図職人を描いたホルヘ・ルイス・ボルヘス(Jorge Luis Borges)の寓話で批判している｡
現代心理学の始まりがブント(Wilhelm Wundt: 1832-1920)のライプチヒ大学での心理学実験室創設とされるように、そのスタートから科学を目指したものだった(7)｡ 人文学の科学化と言っても、物理学や化学の実験を導入するのではなく､心理学の実験手法や神経科学の実験手法(EEG､fMRIなど)を取り入れればいいのである。また､国際的な科学的心理学の学会APS(Association for Psychological Science)の会長だったカシオッポはこうした点に注目し､心理学が科学と他の文系の学問とのハブとなるべきであると主張している(8)。
個人的には､人生全体からの人間理解やフロイト理論の人間理解よりも､人類史からの人間理解(進化心理学)(9)や神経科学からの人間理解の方(10)がより多くのことと整合性が有ると思うし､｢物語｣を一切考慮しないで休職者の約53%を予測したリシテア(11)といったことの研究に心理学がより一層取り組んでいくことを願ってるわ｡
▼出典
(1)Allen Wheelis,"The Quest for ldentity"(New York: Norton,1958).
(2)Sigmund Freud,"Drei Abhandlungen zur Sexualtheorie(『性理論三篇』)"(1905)
(3)M.E.P.Seligman,"What You Can Change and What You Can't :The Complete Guide to Succesful Self-Improvement"(New York:Alfred A.Knopf,1993).
(4)Roy F. Baumeister,Karen Dale,Kristin L. Sommer,"Freudian Defense Mechanisms and Empirical Findings in Modern SocialPsychology: Reaction Formation, Projection, Displacement, Undoing, Isolation, Sublimation, and Denial"(Journal of Personality,1998)
(5)Michael Inzlicht,Jennifer N. Gutsell,"Running on Empty: Neural Signals for Self-Control Failure",(Psychological Science 2007)
(6)Pinker, S."Science Is Not Your Enemy: An impassioned plea to neglected novelists, embattled professors, and tenure-less historians." (New Republic, 2013)
(7)Bringmann, W. G., Bringmann, N. J., & Ungerer, G. A."The establishment of Wundt's laboratory: An archival and documentary study." (W. G. Bringmann, & R. D. Tweney (Eds.), Wundt studies: A centennial collection (pp. 123-157). Toronto: Hogrefe. 1980)
(8)John Cacioppo,"Psychology is a Hub Science"(Observer 2007)
(9)Martin Daly, Margo Wilson,"How evolutionary thinking inspires and disciplines psychological hypotheses." Pp. 15-22 in XT Wang & YJ Su, eds., Thus spake evolutionary psychologists.(Peking University Press,2011)
(10)一例を挙げれば､心の理論(Theory of mind)における神経科学の役割とか｡サイモン・バロン＝コーエンが有名だろうが､研究は色々有りすぎて挙げきれない｡
(11)HR テクノロジーで、人や組織のパフォーマンスの最大化を図る 「リシテア/AI 分析」サービスを販売開始(https://www.hitachi-solutions.co.jp/company/press/news/2016/1201.pdf)
最近プログラミングを少しだけ興味を持って触っているんだけど、そもそも勉強を真面目に取り組んだことがなくて正直挫折しそうだ。
エラーが出てエラー文を検索すると、多くの記事がでてきていて、中には自分と同じ初学者の人もいて、大変助かっているんだけど、
ああいうブログみたいなものって全くの無学でも書いて良いものなの？
そういうブログでは得てして自分の読んだ本の記録とかメモも掲載されていることが多いけど、自分は本を読んだ時にメモしたいとか
感じたことがなくてどういう基準でやっているのかもあまりわからない。
私の中の勉強方法は所謂「黒板のノートを取る」ぐらいで終わっているのだけれど、みんなはどうやって勉強しているのか
参考にしたいから教えてください。
コトノハ〇×(http://kotonoha.cc/)の連投行為、無断転載行為に関して、複垢連投オヤジから最も個人攻撃を受けてきた被害者のひとりである私が考察していく。
も併せて閲覧願いたい。
「複垢連投オヤジ」に関するいきさつや、複垢連投オヤジが投稿したコトやコメントでの滅茶苦茶な理論や言い分については上記で言及、解説している。
複垢連投オヤジ以外にも以前から連投行為をはたらくユーザーは居て問題視されていたことはしばしばあったが、その人達の共通点は、人に共感することよりも自分の記事(コト)を投稿することが主体となっていることである。本来のコトノハへの関わり方は投稿ではなく様々なコトへの回答や共感が基本であり、投稿は既出のコトに無い話題に関して語りたい場合に行うというのが基本であるが、それがわからない人には中々難しいことである。しかし、それを守るために「30コトに回答するまでは投稿できない」、「自分のコトへの回答数が十分でないならば新しいコトを投稿できない (詳細な基準は非公表)」といった仕様になっているが、それに抵触してエラーが出ても何も感じないのだろうか？
ここで、不定期に誰かが投稿するコトとして、「Postは1人1日1回までにしましょう」というものがある。これは、連投や多数の投稿を行うユーザーに関してコトノハの趣旨を再認識してもらうためのものであるが、そのようなユーザーには中々聞き入れてもらえないようである。
そもそも連投を行うユーザーの目的は、投稿することが目的になっている、誰よりも早く投稿しなければ気が済まないなどであるように思える。
複垢連投オヤジの最近の連投は、上記の他の連投を行うユーザーと同じ理由も勿論考えられるが、他のユーザーの投稿を下に下げる目的があると捉えられる。特に、自分(複垢連投オヤジ)にとって不快、不利益な内容のコトが投稿された時、それに対する反論コトや羅列の連投コトが大量に投稿されることが多いからである。複垢連投オヤジにとって連投ネタは何でもよいようである。
複垢連投オヤジは、以前は他人のコトに回答していたことがあったが、最近はほとんど回答していない。他人のコトやトピックに関して言及したい場合は、自ら同一か類似のコトの投稿を行っている。現在は検索(Search)機能が機能していないため行えないが、本来コトノハはコトを投稿する前に類似のコトがないか検索して重複確認することがルールとなっている。勿論、確認出来ず重複するのは仕方なく誰でもあることだが、態と重複させるのは明らかなルール、マナー違反である。
SNSを利用していて、ここまで他人に関心が無く共感力に欠けるユーザーは珍しいと思う。寧ろ、何のためにSNSを利用しているのかと不思議に思う。
複垢連投オヤジによる無断転載行為が行われるようになって以来、多くの方から頂くアドバイスであり、クローズにすれば無断転載が起こることは一切考えられない。特に、私と同年代の若者の場合、クローズにして内輪(親しい仲間内)での交流を主としている人も多い。しかし、私の活動スタイルからして、本名での活動を基本とし、クローズにしたくないというのが本音であり、その理由としてボランティアや一人旅等の諸活動が言える。
ボランティアや一人旅、またスポーツや音楽、起業等も含めた個人での諸活動を主としている人の多くはSNSはオープンで活動しており、活動をきっかけに興味がある人と友達関係を結び、活動や交流の輪を広げていくことが多い。オープンをすることで探しやすく、また近い活動をしている人とも繋がりやすいのは大きなメリットである。特に、友達承認申請やフォローする場合も、投稿内容が分かることで安心できる。私もこのメリットが大きく、オープンでの活動を基本としており、本名や学歴等もその理由により記載してきた。
このオープンかクローズかはリアルでの活動も大きく関連していると思う。クローズの人たちは基本的に内輪を好む人が多い。私は中堅の大きな大学であるため、ボランティアや委員会でも私の大学のメンバーは多かったが、活動先では他大学、他団体のメンバーも多く居たのに呆れることに同じ大学のメンバー同士でしか交流していない人が多かった。他大学からは「〇〇大学仲良いね」と言われていたが半分は嫌味に聞こえていた。しかし、私は真逆で今も昔も主に他のメンバーとの交流が多かった。ボランティアは同じ大学でも一度切りのメンバーが多かったが、他団体と交流することの方が貴重な機会であることは間違いない。
今まで本名で活動してきて不都合な点は全く無く、5ちゃんねる(旧2ちゃんねる)に晒されたり、外部機関へ通報されたり等の経験は無い。要するに、そのままで問題無かったのだ。しかしながら、複垢連投オヤジが登場するようになって初めて晒し等の迷惑行為を受けるようになった。私は不謹慎な投稿や一方的な誹謗中傷、暴言等の迷惑行為や、犯罪自慢(所謂「バカッター」行為)や犯行予告等の違法行為をした覚えは一切ない。複垢連投オヤジの私怨での一方的な嫌がらせ目的である。それにより初めて対策せざるを得なくなった。
は100％複垢連投オヤジ、只一人のせい(為に行っている対策)である。
～作成中～
初日：
先週納車されたバイクで意気揚々と初ツーリング。海辺の道をかっ飛ばしてたら白バイに捕まって速度違反で切符を切られてしまい、完全にやる気を失った。
2日目：
たまには運動しないと、と思って久しぶりに水泳をやってみたら水中で足がつっておぼれそうになり、完全にやる気を失った。
最終日：
研究に使ってる代々秘伝のソースコード(FORTRAN77)をfortran90に書き直す作業をした。10万行くらいあるのでperlで必要そうなところガッと変換したらコンパイルエラーだらけで結局かなりの部分を手作業で直す羽目になり、完全にやる気を失った。
なんか今回の連休は災難続きだったけど、そんなことはお構いなしに週明けはきます。がんばっていきまっしょい！
私が囲碁を学んだ過程を基に、どのようにして最低限囲碁を成り立たせれるレベルにまで向かうのかを書いてみたい。
囲碁はルールと実際の対局での手筋の間に、深くて暗い谷があるのではないかと思う。
ルールをどれだけ読んだとしても、対局時にどのような手を打つべきかを、ルールは論理的に教えてくれない。
なのでルールを知っているのは前提だけれども、わからないなりに対局をこなすしかないような気がする。
うちではじいちゃんに教えてもらったのだけれど（正確にはじいちゃんが撮りためたNHKの囲碁番組ビデオでルールを学んだ）
じいちゃんはルールや定石などについては何も教えず、ただただ「対局しよう」とだけ言って、私はわけわからんなりに囲碁を打っていた。
たまに「それはいい手やな」と言ってくれるのが嬉しかったのはよく覚えている。
囲碁では置いた石でより多くの陣地を囲むことが必要だが、交互に同じ数の手を打っていく以上
より広い陣地をより手を抜いて確保することが必要になる。
ルールとしては単純な話ではあるが（常人では）ルールの延長からどのような手をうつべきか知ることはとても難しく、
試行錯誤の末にあの手はよかった、あれはまずかったと身をもって知ることがまず最初の一歩ではないかと思う。
例えば走り幅跳びの飛距離を伸ばしたいとしても、物理法則から足の動かし方を考えることはしないだろう。それと同じ話。
陣地をより少ない手で確保するため手を抜くことも大切なのだが、囲碁は対戦競技であり相手を攻撃することができる。
（相手の石を全て囲うことで、石を取ることができる）
数が多ければいい、というわけではないが、基本的には数の多さは強さに繋がる。（石の厚み、というのはこの強さに関係している）
うまく手を抜くことで、石は広い範囲を覆うことができるが、手を抜いた石は弱い。
下手をすると、手を抜いた石は相手の攻撃に耐えきれず、すべて相手に奪われてしまう。
囲碁をより広い家を建てたものが勝利するゲームと考えると、プレイヤーが序盤で外壁の塗装に手数をかけることは良い戦略ではなく、
まずは空き地に家の基礎となる柱を立てて家の骨格を築いていくべきだろう。囲碁は碁盤という限られたスペースで戦う。
あなたが1軒の家の外壁を固めている間に、相手が3軒分の基礎を固めてしまっているならば、もうそこで勝負はもう決まっているだろう。
どこまで手を抜けるか？というさじ加減が重要で結局は実践の中でしか身につかないのかと思う。
その強さが話題になったAIが強いのも、結局膨大なトライエラーを経ているから。
これらの勘所をまとめたものが「定石」と呼ばれる。どのように打つことが効率的であるかは、すでにある程度定型化されている。
囲碁のとっかかりがつかめない人に向けて書いたつもりではあるが、何か分からないようなそんな記事になった。
また質問があれば答えたい。
私が囲碁を学んだ過程を基に、どのようにして最低限囲碁を成り立たせれるレベルにまで向かうのかを書いてみたい。
囲碁はルールと実際の対局での手筋の間に、深くて暗い谷があるのではないかと思う。
ルールをどれだけ読んだとしても、対局時にどのような手を打つべきかを、ルールは論理的に教えてくれない。
なのでルールを知っているのは前提だけれども、わからないなりに対局をこなすしかないような気がする。
うちではじいちゃんに教えてもらったのだけれど（正確にはじいちゃんが撮りためたNHKの囲碁番組ビデオでルールを学んだ）
じいちゃんはルールや定石などについては何も教えず、ただただ「対局しよう」とだけ言って、私はわけわからんなりに囲碁を打っていた。
たまに「それはいい手やな」と言ってくれるのが嬉しかったのはよく覚えている。
囲碁では置いた石でより多くの陣地を囲むことが必要だが、交互に同じ数の手を打っていく以上
より広い陣地をより手を抜いて確保することが必要になる。
ルールとしては単純な話ではあるが（常人では）ルールの延長からどのような手をうつべきか知ることはとても難しく、
試行錯誤の末にあの手はよかった、あれはまずかったと身をもって知ることがまず最初の一歩ではないかと思う。
例えば走り幅跳びの飛距離を伸ばしたいとしても、物理法則から足の動かし方を考えることはしないだろう。それと同じ話。
陣地をより少ない手で確保するため手を抜くことも大切なのだが、囲碁は対戦競技であり相手を攻撃することができる。
（相手の石を全て囲うことで、石を取ることができる）
数が多ければいい、というわけではないが、基本的には数の多さは強さに繋がる。（石の厚み、というのはこの強さに関係している）
うまく手を抜くことで、石は広い範囲を覆うことができるが、手を抜いた石は弱い。
下手をすると、手を抜いた石は相手の攻撃に耐えきれず、すべて相手に奪われてしまう。
囲碁をより広い家を建てたものが勝利するゲームと考えると、プレイヤーが序盤で外壁の塗装に手数をかけることは良い戦略ではなく、
まずは空き地に家の基礎となる柱を立てて家の骨格を築いていくべきだろう。囲碁は碁盤という限られたスペースで戦う。
あなたが1軒の家の外壁を固めている間に、相手が3軒分の基礎を固めてしまっているならば、もうそこで勝負はもう決まっているだろう。
どこまで手を抜けるか？というさじ加減が重要で結局は実践の中でしか身につかないのかと思う。
その強さが話題になったAIが強いのも、結局膨大なトライエラーを経ているから。
これらの勘所をまとめたものが「定石」と呼ばれる。どのように打つことが効率的であるかは、すでにある程度定型化されている。
囲碁のとっかかりがつかめない人に向けて書いたつもりではあるが、何か分からないようなそんな記事になった。
また質問があれば答えたい。
