雑記 - 静かなる名辞

ブログで直帰率が高いことは問題ではない。満足して帰っていれば

2019-07-18T05:22:10+09:00

はじめに

　ブログをある程度真面目に運営している人は、googleアナリティクスなんかを入れて色々な指標を日々確認していると思います。指標が悪いと、なんか問題があるのではないかと思いがちです。

　当ブログは直帰率が高いです。8割以上といったところです。でも、気にしていません。どうして気にしないのか？　気にする意味がないからです。

　いや、真面目な話、気にしていた時期もあったといえばあったんですよ。レイアウトの改善で1%くらい下がったかな？　ということをやっていた時期もありましたが、最近はきっぱり諦めました。それに伴って、他の要因*1でレイアウトをいじっているので、直帰率もきもち程度上昇気味です。振れ幅は数%ですけどね。

どうして直帰率が高いんだ！

　A:技術ブログだからさ

　あー、えーっと、この記事は「プログラミングの記事を書くかたわら、気晴らしで書いている運営報告系雑記記事」です。なので、検索から来た人の多くにとって、自分のブログには直接は当てはまらないと思います。ごめん。

　必要だと思うので技術ブログというブログの形態について説明しておくと、プログラミングをやる上でのお悩み解決に役立つような記事を中心に上げるブログです（勝手に定義）。「このコマンドの使い方がわからないなー」とか「書いて動かしたらこんなエラーが出た」とか、そんな動機でググった人がやってくるブログです。

　薄々感づいてきた人もいるかもしれませんが、当ブログにやってくる人のほとんどは別に当ブログを読みたい訳ではなくて、暇つぶしに読むブログを探しているとかでもなくて、単に自分の抱えている問題を解決したいだけです。私のブログが解決策を示せていれば、満足して直帰します。残念ながら解決につながらなかった場合も、直帰して他のサイトを読みに行きます。

　それでも1割くらいの人は直帰しないで回遊してくれていますが、それは3パターンくらいあって、

記事中に貼った内部リンク（関連する内容の記事へのリンク）を見てくれる
仕事中とかにあまりやる気がない状態でやってきて、仕事をしたくないので漫然と最新記事とか記事下の関連コンテツを回遊している（失礼）
「おぉ～このブログいろいろ書いてあるぅ～」と思ってくれてアーカイブやカテゴリページを総なめしている。ログを見ると、そんな感じで回遊している人が毎日1～2人はいそうな気がします。大変ありがたいです

　のいずれかだと思います。まあ、どれにしてもそんなに増えることは期待できない訳です。
（せいぜい記事中の内部リンクを増やすくらい。でも内部リンクを貼る必要のない記事に貼ってもしょうがないのだし）

　少し話が脱線しましたが、「知りたいことについてググる」「問題の解決策を探す」といったような、いわゆる『調べごと系』の検索ニーズに応えるというのは、技術ブログに限らず多くのブロガーの方が実践している方向性だと思います。すると何が起こるか？　ユーザは目的を達成してもしなくても帰っていきます。なので、直帰率は自ずと高くなる、ということです。

どのみち直帰する？

　もう少し上の現象について掘り下げて考えてみましょう。同じことを二回書きますが、整理すると以下の図式です。

ユーザが満足した（検索の目的を達成した）

　それ以上の用はないので直帰する。

ユーザが不満足だった（検索の目的を達成しなかった）

　このブログには見切りをつけて他に行く。

　この状況のユーザに対して、直帰されないためにブログ運営者から打てる手はほとんどありません。いくらコンテンツの質を上げようが、内部リンクを工夫しようが原理的にほぼ無理です。最初から「知りたいことが載っているページを探して、読んだら直帰する」つもりで来ている訳ですから。

　それでもウザいくらいに記事中に内部リンクを貼るとかすれば統計的に何%かのユーザは「釣られて」くれるかもしれませんが、そういうのは回遊の押し売りとでもいうべきもので、ブログの運営の仕方として望ましいものではないと思います。

　たとえばランディングページと大して関係のない記事に回遊させたとして、「なんで俺はこんなの読まされたんだろう」と当然思われるでしょう。そういう事態は避けるべきです。ただ、このあたりの塩梅はケースバイケースで、結果的にユーザに許容されるであろうという確信が持てれば「釣って」もいいと思います。「この記事を読みに来た人なら、絶対にこっちの記事も読んだ方が良い」みたいなのは適切な説明をつけてリンクしておくと良いでしょう。でも、そういう「釣って良い」ケースは限られるので、実際問題として個別の記事でそういう処置がとれるものはあったとしても、全体の直帰率に及ぼす影響はさほど大きくないでしょう。

　結論を言うと、「調べごと」系にフォーカスしたブログでは原理的に直帰率は改善できないはずです。高いなら高いままと考えた方が良いです。

だから、直帰率のこととか気にしなくていいと思うよ

　実際問題として、直帰率が低いとなにか問題があるのでしょうか？

　まあ、直帰率の1%の低下は大雑把にはPVを1%増やすかもしれませんが、雀の涙です。そして直帰率を1%下げるというのはけっこうたいへんです。これでPVを稼ごうと考えるより、先にやるべきことがたくさんあるでしょう*2。

　直帰率が高いとgoogleの評価が～という話もちらほら見かけますが、眉唾物だと思っています。少なくとも、公式にそれを肯定する情報はありません。

　参考：
サイト直帰率が高くてもGoogle順位には「影響ない」
ページの滞在時間はSEO順位に影響する？コンテンツの滞在時間と直帰率を改善する方法 | プロモニスタ

　だいいち、検索からサイトに飛んだ人をトラッキングする手段は、普通に考えたらないのではないでしょうか。googleアナリティクス（googleのアクセス解析ツール）を入れているサイトなら結果的には情報がgoogleに送信されますし、もしかしたらchromeになにか仕込まれているという可能性も皆無ではありませんが、そういったものを検索の評価に使うというのは現実的ではないように思います。

　あとは、ユーザ満足度やコンバージョンに結びつける話もありますが、ユーザ満足度に関しては上述の通り「満足しようがしまいが結果的に直帰する」ユーザがほとんどである以上、直帰率では測れません。コンバージョンも普通のブロガーには関係ないですよね。

　なので、直帰率は気にしなくて良いということです。

ユーザ満足度はgoogleアナリティクスでは測れない

　さて、ここまで読んできた人の中には、直帰率はユーザ満足度の指標なので改善するべき、という巷で喧伝されている説明を信じていたのに、という人もいるでしょう。もう直帰率はあてにならないと知ってしまった訳で、困りますよね。

　繰り返しになりますが、直帰率はユーザ満足度の指標ではありません。私の感覚では、満足した結果として直帰する、というユーザはかなりの割合を占めます。なので、他の方法で考えるしかありません。

　真っ先に思い浮かぶのは、平均ページ滞在時間でしょうか。でも、あれは直帰したユーザについては計測できない（というか0になる）という欠点を抱えています。駄目駄目ですね。それに、滞在時間が長ければ満足しているという発想にも無理があるでしょう。読みづらくて時間がかかっているのかもしれないし、別ウィンドウやタブで開いたまま放ったらかして他のページを見ている可能性も十分にあります。

　参考：
まだGAの「滞在時間」を信用してるの？計算の仕組みとその使い方を理解する［第15回］ | 衣袋教授の新・Googleアナリティクス入門講座 | Web担当者Forum

　この章のタイトル「ユーザ満足度はgoogleアナリティクスでは測れない」はちょっと過激にしてありますが、ブログに関して言うと当たらずといえども遠からずというのが私の肌感覚です。特に、ページごとに出てくる数字はPV以外「気休め」くらいに思った方が精神衛生上良いでしょう。

　では何で見るのがいいかというと、Search Consoleはある程度使えます。ページごとにどんなキーワードでユーザが来ているのかがわかるので、キーワード（検索意図）とページの内容がずれていたらたぶん満足度は低いだろうな、ということがわかるからです。これは改善に使えます。

　あとはやっぱり、自分で読んでみて読みやすいか、わかりやすいかといったあたりでしょう。

それでも直帰率を下げたい

　そんなに直帰率を下げることにこだわらなくていいという記事ですが、それでも下げたいのであれば。

サイドバーとかに面白いものを出して（人気記事ランキングとか）、そっちに飛ばす
無理のない範囲で内部リンクを貼って、関連記事への回遊を促す
記事を読み終えたらすぐに関連記事リストが出てくるように配置する

　の3点くらいでしょうか。数%～5%くらいはいけると思います。私はもう実践していませんが、こだわる方はどうぞ。

まとめ

　ということで、直帰率は下げなくても可です。直帰率は極論すれば、ブログにとっては「下げれば反比例してPVが増える以外、特に意味のない数字」と言っていいと思います。

　ブロガーの方は、直帰率が高いからユーザの不満度が高いのかなぁ～とか心配する暇があったら、せいぜいサチコ*3を見てキーワード最適化しましょう。

*1:ユーザビリティだったり広告最適化だったり

*2:数千記事、100万PVクラスのブログだと事情が違う可能性はあります。でも、そんな人は読んでないだろうし

*3:Search Console

記事の寿命から考える、1記事で1日に得るべきPVとブログの収益性

2019-07-15T07:30:42+09:00

はじめに

　当ブログは見ての通りたくさん広告を貼っていますが、こういうことをしていると「どれくらいPVを稼げば、記事を書く労力に対して儲けが割に合うのかなぁ」ということが気になってきます。そこで常日頃から考えていたことを軽く書いておきます。

　テーマは「1記事で1日にどれくらいPVを稼げていれば、割に合う広告収益が得られるのか」です。ぶっちゃけダーティーなカネの話ですが、ふんわりした感じで計算していきますのでご安心ください。

はじめに
未来永劫PVを稼げて広告を貼り続けられるなら、いつかはペイする
記事の寿命は3年程度
PVの単価を考えると1PV 0.15円くらい
記事に費やした労力をお金に換算すると平均437円くらい
437円を3年で稼ぐには一日3PV必要
ただし稼げるとは一言も言っていない
まとめ

未来永劫PVを稼げて広告を貼り続けられるなら、いつかはペイする

　たとえば1ヶ月に1円しか稼がない記事があったとして、1年で12円、10年で120円、100年で1200円の収益が入ります。1ヶ月に1円というのはとても低いハードルなので、たぶん（最低限の内容があれば）すごく適当に書いた記事でも達成できます。こういう方向性で努力するというのも一つの手です。100年待てるのなら。

　ふざけんな、そんな非現実的な想定してなんの役に立つんだ、と思われるかもしれませんが、「どれだけの期間で記事作成に支払った労力を回収したいのか」が重要、というのがミソです。

　また、「現実的にどれくらいの期間、収益を上げられるのか」も当然考慮するべきでしょう。100年の間にgoogleやはてながサービスを終了するかもしれないし、そもそも100年後の人類（人工知能の文明になってるかもしれないけど）の興味関心に沿った記事でなければ読まれないのですから。

記事の寿命は3年程度

　日頃から検索エンジンを使っている人であれば、だいたい数年以内に書かれたページが上位に出てくるということは実感していると思います。それ以前に同じテーマで書いた人がいないのかというとそういう訳ではなく、古い記事は検索ランキングを落とされます。何十位もさかのぼれば、古めのページも出てきたりします。

　「どれくらいの期間で投入した労力を回収するのか」をこれから自動的に決めることができます。というか、決めないといけません。

　今回は考察を簡単にするために、3年間は一定のアクセスを集めて、それ以後はアクセスが0になる、というモデルを想定しましょう。この想定はそんなに実情からかけ離れている訳ではなく、どちらかといえばやや保守的な想定です（実際には記事を公開してから数年が過ぎ、検索ランキングが落ちてもある程度のアクセスは入ってきます。でも、0とします）。

PVの単価を考えると1PV 0.15円くらい

　ダーティーな話題ですが、避けては通れない話題です。1PVあたりいくら稼げるのかという問題です。

　たとえばgoogleアドセンスで収益化するのなら、500PVくらいに1回は広告を踏む人がいて、30円とかが懐に入ります。アフィリエイトなら、PVに対する商品の売れる数の比率は数分の1とか未満になるけど、一回で懐に入る金額は安くても30円の10倍とかのはずです。

　なので、平均的に見ると1PVでいくら稼いでいる、という数字を計算できます。

　このブログはアドセンスしか貼っていませんが、実測値をぼんやりと書くと0.1円/PV以上はあるけど0.2PV/円はないかな、というくらいです。今回は0.15円/PVで考えます。これもどちらかといえば保守的な数字ですが、でもそんなに実情から乖離している訳ではありません。
（ただし、この数字はサイト・コンテンツの内容や、広告の貼り方などによってけっこうブレるので、あまり当てになりません。上の数字の半分の人も、倍以上の人もいます。適当に自分が使いたい数字を当てはめてください）

記事に費やした労力をお金に換算すると平均437円くらい

　これもまたダーティーな話題ですが、1記事を作るのに費やした労働コストを金銭換算します。

　計算は簡単な時給換算です。まず最低賃金を見ます。

https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/koyou_roudou/roudoukijun/minimumichiran/

　平成30年度の全国加重平均（ちゃんと書かれていませんが人口で加重平均しているのだと思います）が874円なので、この数字を採用します。最低賃金以下なら割に合わない、という単純な発想です。「俺は最低賃金じゃ働きたくない、せめてン円はほしい」という人は勝手に好きな数字を決めて計算してください。

　時給がわかったので、あとは1記事にどれくらいの時間を費やしたのかを考えます。これも記事の長さによっていくらでも変わってくる数字ですが、勝手に平均30分ということにします。ブログ記事を書くのに費やす時間の実情としては、そんなものでしょう。

　時給と労働時間が決まれば、1記事に投入されたコストがわかります。

　437円ですね。

437円を3年で稼ぐには一日3PV必要

　まず1日あたりに1記事が稼ぐべき金額を決めます。となります。

　更に0.15円/PVですから、となり、1日に3PV稼いでればまあまあ割に合うということになります。

　これはそんなに高いハードルではないので、お金目当てでやる人はクリアできるでしょう。ま、当ブログには一日3PVも稼いでいない記事いくらでもありますが。

ただし稼げるとは一言も言っていない

　ブログを書いてそこそこの儲けを出せる人は、たぶん他の方法で稼げば最低賃金よりは多くもらえることの方が多いと思うので、そういう意味では割に合わないでしょう。残業して働いた方が稼ぐ手段としてはマシです。

　また、「ブログ専業でも最低賃金くらいはもらえる」というのも無理があると思います。週40時間労働として、上の想定だと一週間に80記事上げることになります。どう考えても無茶です（そんなにネタがない）。まあ、3PV稼げればと割り切ってゴミ記事を量産してもいいですし、あるいはせめて1記事10PVくらいを目指して1記事に時間をかける方向性もあるかもしれませんが、それでも週30記事くらいなので普通の人には無理です。

　逆に、仕事や学業をしながら一日1記事くらい投稿するというペースだとざっくり言って専業フルタイムでやる1/10くらいの投稿頻度なので、稼ぎも月2万円未満くらいという数字になります。まあ、これもリアルな数字で、大半の「ブロガー」は月数万円くらい稼げていれば十分ペイしているのでそれで満足するべき、という結論になります。

　それだと色々寂しいので、もっと派手に稼ぎたいということで、仮に時給2000円を想定すると、1記事一日6PVくらい。3000円で10PVくらいです。この辺の数字の方が肌感覚に近く、「割に合う」と言っていいのはそれ以上の水準かもしれません。

　また、1PVの収益率はブレのある数字なので、倍かもしれないし半分かもしれない、という問題が現実としてはあります。「1PVで0.15円いけるやろ」と思ってやってみたら半分だった、というのは悲惨なので、気をつけてください。

　あとは、「丸一日かけて書いた渾身の力作がぜんぜんPV稼げない」とか「5分で上げたのが案外伸びた」みたいなのも考慮していません。あくまでも平均的な数字です。なので、記事単位での凹凸はありえます（ポジティブな凹凸は構いませんが、ネガティブな方向に向かうのは当然できるだけ減らすべきです。そう考えると長文力作記事はリスキーですね）。

まとめ

　色々と考えてみましたが、個人的にそこそこの発見だったのは「1記事あたり一日3PVあれば、時給換算で最低賃金超える」というあたりですね。思っていた水準はもっと上だったので、少し驚きました。でも、冷静に考えたらやっぱりもう少し上を狙わないと苦しい、という結論に達しました。

　1記事でどれくらいPVを稼いでいるべきなのか、という数字が出るとサイト運営の上でいい目安になるので、収益化してるブログを持っている人は考慮してもいいんじゃない？　と思います。みんな当たり前にやっていて意識すらしないということなのかもしれませんが、そういう観点で語っている人は意外と少ないので書いてみました。

　このブログを読んでいる人で、この情報が役に立つ人はあまりいないと思いますが、もしいたら何かの参考にしてください。役に立たなくても「ふーん、そういう世界なのね」と思って読んで頂けたなら私的には幸いです。

ブログのSearch Consoleでの平均CTRや平均掲載順位が下がるのはオッケー。クリック数と表示回数が大切

2019-07-14T04:31:16+09:00

はじめに

　当サイトは見て分かる通りの零細プログラミングブログです。大したアクセスを稼いでいないので、ぶっちゃけPVのこととか気にしても仕方ありません。考える暇があったら記事書いた方が良いというやつですね。

　が、実を言うと中の人は割と頻繁にアクセス解析したりSearch Consoleいじったりしています。放っときゃいいのにって？　それもそうなんですが、趣味なので・・・

　で、最近の傾向は、Search Consoleの平均CTR（検索に表示されたページがクリックされる確率）と平均掲載順位（検索に表示されたときに平均して何位に出てきたのかという数字）が落ち気味なことです。普通だったらサイトの集客力が落ちていると解釈されて大問題になるところですが、ここ一ヶ月くらいの当ブログのアクセスは絶好調でして、どれくらい絶好調かというと今年に入ってからアクセスがずっと下降傾向だったのが*1、一ヶ月で半年前の水準に戻りました。

　なんで平均掲載順位が落ちてCTRも下がってるのにアクセス増えるんや？　と思ってデータを軽く見てみたらけっこう面白い傾向が見えたので書き残しておきます。

　あ、あと、googleの規約上実データは一切出せないし、模擬データのグラフでも描こうかとも思いましたが面倒くさいので、この記事はひたすら言葉だけで説明します。予めご了承ください。

いろんなクエリに低い順位で引っかかるようになった

　ざっと見た感じだとそんな傾向です。具体的に書くと、一日500表示くらいのキーワードの8位とか9位で出てる記事がいくつもありました。この順位だといちおう1ページ目には出ますが、それでたくさんアクセスが集まる訳ではありません。上位の記事に吸い寄せられるからです。でも、一定数のユーザは順位の低い記事も見に来ます。

　正直わりと検索意図に合致していない記事が出ている感も否めないのですが、それでも（タイトルが若干煽り気味だったりするので）入ってくる人はそれなりにいます。500表示で6位以下、CTRが5%なら単純計算で一日25PVになります。このブログで一つの記事が稼ぐPVとしては十分な数字です*2。

　ということで、順位とCTRは下がってPVが増えるという状況が成立します。

検索に現れすらしなかった記事が評価されるようになった

　今年に入ってからは新しいドメインの評価が安定していなかったり、忙しくて更新頻度が落ちたりして、割とgoogleの評価が冷たかったので、新しく書いた記事はぜんぜん検索でヒットしてくれないような状況でした。それでもURL移転から半年以上がすぎ、ようやく安定してきたので、その時期に書いた記事がじわじわ検索で上がるようになってきました。

　そういう記事はまだ順位が安定しておらず、割と低めの位置にいます。まあでも、このパターンだと経験的には一年くらいかけて上がるような気がするので、今後に期待です。

上の下というポジションの記事が増えるとこうなる

　上の下というのは、検索1ページ目の下側1/3くらいの領域のことです。

　変な話、30位とかにランクインしてても検索3ページまで見る人はそんなにいない訳で、そもそも表示回数が少ないので、平均掲載順位へのインパクトはあまりない訳です。でも、1ページ目の下の方に出るようになると統計上は「表示」されるし、実際にはほとんどクリックされないのでCTRと平均掲載順位の指標は下がり気味になる可能性があります（元がある程度高ければの話。このブログは特定のキーワードで上位に出てPVを集めるという記事をいくつか抱えているので、そういう傾向になってしまいました）。

　もっと変な話すると、このロジックで行くと平均CTRだけ考えるなら10位より11位の方が有利です。で、google先生はおそらくCTRからフィードバックをかけて検索順位を調整していると思うので、もしかすると彼らのアルゴリズム次第では

2ページ目上位で有利に表示されていた記事の評価が上がって1ページ目下位に移動する
1ページ目では表示回数の割にクリックされないのでしばらくして評価が下がりまた2ページ目へ
以下ループ

　というパターンもあり得るかもしれません（さすがにある程度の補正はしてそうですが）。なんとなく10位くらいを基準にフラフラしてる記事とクエリの組み合わせがいくつかあるので、可能性としてはそれなりにありえる気がします。

クリック数と表示回数の絶対数は重要

　話がそれました。けっきょく何が言いたいのかというと、まず

平均CTRと平均掲載順位はあまり気にしても仕方ない

　ということです。というか、単純なこれの上下に一喜一憂する必要はないと思います。

　どちらかといえば重視するべきなのは、

表示回数
クリック数

　です。要は絶対的な検索流入（≒PV）だけ見ろってことです。位置はともかく表示されるようになればたぶんgoogle先生はサイトの評価を上げているし、それに伴って検索流入が拡大すれば悪いことはないのです。

　この逆パターン（PV減、平均掲載順位と平均CTR改善）があるのかどうかはわかりませんが、もしあったら要注意な感じです。

まとめ

　なんかとりとめのない感じになりましたが、考察してみました。

*1:独自ドメイン化したりいろいろやっちゃったせいだと思います。やむを得ない

*2:そんな美味しいのたくさんはないけど

ロジスティック回帰が線形分離不可能な分類問題を解けないことの説明

2019-07-07T03:36:21+09:00

はじめに

　ロジスティック回帰が線形分離不可能な分類問題を解けないことは有名な話です。だけど、「いや解けるだろ」「なんで解けないの？？？」と言われてしまうことがあるので*1、それができないことを説明しておこうと思います。

　なお、この記事はこちらの記事を参考にしています。

誤った図解から学ぶロジスティック回帰の性質 - ill-identified diary

　書きたいことは言い尽くされている感もあるので、こういう結論に至る過程を数式で書きます*2。

y=0.5を代入すればいい

　さて、説明変数、目的変数、パラメータ、などを適当に定めたとします。すると、ロジスティック回帰の予測式はこんなやつになります（は適当に学習できたとする）。

\begin{align}
\hat{y} = \frac{1}{1 +
\mathrm{e}^{-(\beta_0 + \sum_{i=1}^{n}\beta_i x_i)}
}
\end{align}

　書き方の流儀はいろいろあると思いますが（を使うとか）、今回は上の式で行きます。

　さて、今回は分離超平面の式に興味があるのでしたね。分離超平面ってどこ？　というと、のところです。なので、淡々と式を書き換えます。

\begin{align}
0.5 = \frac{1}{1 +
\mathrm{e}^{-(\beta_0 + \sum_{i=1}^{n}\beta_i x_i)}
}
\end{align}
　
　両辺を逆数にします。

\begin{align}
2 = 1 + \mathrm{e}^{-(\beta_0 + \sum_{i=1}^{n}\beta_i x_i)}
\end{align}

　とりあえず邪魔な1を反対側に移す。

\begin{align}
1 = \mathrm{e}^{-(\beta_0 + \sum_{i=1}^{n}\beta_i x_i)}
\end{align}

　両辺の対数を取る。

\begin{align}
0 = -(\beta_0 + \sum_{i=1}^{n}\beta_i x_i)
\end{align}

　マイナスは必要ないので消しましょう。

\begin{align}
0 = \beta_0 + \sum_{i=1}^{n}\beta_i x_i
\end{align}

　もうだいたい終わってる気もしますが、たとえばとして適当に式を変形します。

\begin{align}
\beta_0 + \beta_1 x_1 + \beta_2 x_2 = 0
\end{align}

　……はい、これは「直線の式」ですね。

　が増えると係数と変数が増えていきますが、いずれにせよ線形の式なのは間違いありません。とかみたいなのが出てくる余地はありません。

　「分離超平面」がかのような式で表わせる以上、線形分離不可能な分類問題は解けない、ということです。

非線形の問題も解く方法

　あくまでも「分離境界が線形にならないといけない」というだけなので、データを非線形変換して解けるような空間に写像すればできます。代表的な方法は多項式を使うことです（SVMの多項式カーネルなんかと同じですが、明示的に特徴量空間を計算するのが相違点です）。

　ということで、こちらの記事を御覧ください。どれくらい非線形でも行けるのかが書いてあります。

非線形がなんだ！ロジスティック回帰＋多項式でやってやる！ - 静かなる名辞

*1:……

*2:誰でも納得するから

コサイン距離は距離じゃないんだから、勘違いしないでよねっ！

2019-07-05T03:09:35+09:00

き、記事タイトルに意味なんてないんだからねっ！

　自然言語処理などでお馴染みのコサイン類似度。これを1から引いたものを「コサイン距離」と称している文献も散見されますが、この「コサイン距離」は距離としての性質を満たしません。

　それがどういうことなのかをこの記事で説明していきます。

コサイン類似度のことくらい自分で調べなさいっ！

　まず前提となるコサイン類似度については、親切に解説しているサイトが他にたくさんあるので、そちらに譲ります。

　たとえばここなどがいいでしょう。

コサイン類似度

　コサイン類似度はベクトル同士の類似度であり、要するに単なる内積（をノルムで正規化したもの）です。これは-1から1の区間を取ります。1なら「最も似ている（同じベクトル）」、-1なら「最も似ていない（反対向き）」という性質を持ちます。

　これを1から引くことで、0なら「最も似ている」、2なら「最も似ていない」に変換したものが「コサイン距離」です。

距離の定義を知らないの？　しょ、しょうがないから教えてあげるわ

　さて、距離という言葉というか概念は実は数学的にちゃんと定義できます。かいつまんで書くと、関数が以下の条件（距離の公理といいます）を満たすとき、その関数を距離関数あるいは距離と言えます。

\begin{align}
d(x,y) &>& 0\\
x&=&y\Leftrightarrow d(x, y) = 0\\
d(x, y) &=& d(y, x)\\
d(x, z) &\leq& d(x, y) + d(y, z)
\end{align}

参考
距離空間 - Wikipedia
第６回距離の公理：ねむねこ幻想郷：So-netブログ
 距離とは (キョリとは) [単語記事] - ニコニコ大百科

　数式で見ると難しく見えるかもしれませんが、この式はそれぞれ

距離は負にはならない（非負性）
同じ点同士の距離は0、距離が0の点は同じ点
x,yの間の距離について、距離を測る起点を逆にしても距離は変わらない（対称性）
x,zとまっすぐ行くときと比べて、yに寄り道すると必ずトータルの経路は長くなる（三角不等式）

　ということを言っているだけなので、概念的には簡単です。

　こういうものを満たすと距離と呼べる、ということですね。

　「コサイン距離」はどれを満たさないのでしょうか？

わからないの？　……ばか

　「コサイン距離」は2番目のと、4番目の三角不等式を満たしません。

　2番目を説明するのは簡単で、元のコサイン類似度はベクトル間の角度にしか興味を持たない性質があります。なので、たとえば二次元ベクトルととか、とは同じ距離になります。

　4番目については、反例を挙げてみましょう。

すごく単純な例

　特に凝ったことはしていません。この図において、単純なユークリッド距離を考えると、

A-B間, B-C間の距離：1
A-C間の距離：

　となり、こういうのが三角不等式を満たしている場合です。A-B-Cとたどる経路の長さは2になるので、A-Cとたどるより長い距離をたどることになります。

　では、「コサイン距離」では？　というと、

A-B間, B-C間の「コサイン距離」：約0.293
A-C間の距離：1

　となり、A-B-Cとたどることで約0.586になりますからA-Cと直接たどるより短い距離で行けてしまうことになります。つまり、三角不等式を満たさないので、「コサイン距離」は距離ではないということになります。

距離として扱うと困るのかって？　……困るに決まってるじゃないっ、わからずや！

　データ分析などで、距離を使うことを前提としている手法で「コサイン距離」を使うと、不都合なことが起きる可能性があります。

　みんなが大好きなirisのデータを多次元尺度構成法、MDSで可視化してみましょう。Pythonで書くとこうなります。

import matplotlib.pyplot as plt
from scipy.spatial.distance import pdist, squareform
from sklearn.datasets import load_iris
from sklearn.manifold import MDS

def main():
    iris = load_iris()

    A = squareform(pdist(iris.data, "euclidean"))
    mds = MDS(n_components=2, dissimilarity="precomputed",
              n_init=10, max_iter=500)
    X_2d = mds.fit_transform(A)

    for i, target in enumerate(iris.target_names):
        mask = iris.target == i
        plt.scatter(X_2d[mask,0], X_2d[mask,1], label=target)

    plt.xlim(X_2d[:,0].min() - 1, X_2d[:,0].max() + 1)
    plt.ylim(X_2d[:,1].min() - 1, X_2d[:,1].max() + 1)
    plt.title("MDS stress:{:.4f}".format(mds.stress_))
    plt.legend()
    plt.savefig("iris_euclidean_mds.png")
   
if __name__ == "__main__":
    main()

iris_euclidean_mds.png

　そんなに申し分はなさそうな結果ですね。

　「コサイン距離」でもやってみます。といっても、親切なことにscipyが「コサイン距離」を標準でサポートしているので、

    A = squareform(pdist(iris.data, "cosine"))

　とすれば一発でできます。あとはせいぜい出力ファイル名を変えておきます。
（plt.savefig("iris_cosine_mds.png")としました。）

scipy.spatial.distance.pdist — SciPy v1.3.0 Reference Guide

iris_cosine_mds.png

　なんかよくわからないことになりました。念のために中心付近にズームしてみます（plt.xlimとplt.ylimで調整）。

iris_cosine_mds_zoomed.png

　考えてみれば当然の結果で、コサイン類似度は-1から1のレンジを取ります。ということは、「コサイン距離」の最大値は2にしかならないのです。なので、遠い点が表現できなくなり、とても小さい範囲に押し込められます。

　また、「コサイン距離」では向きが同じで長さの違うベクトル同士を区別できません。昔作ったirisの主成分分析のバイプロットを持ってくると、

irisのバイプロット

【python】pythonで主成分分析のバイプロット - 静かなる名辞

　グループ間の差異は概ね第一主成分に、グループ内での差異は第二主成分にあらわれています。そして、第一主成分とほぼ同じ方向を向いている2つの変数、そうでもない2つの変数があることがわかります。

　品種が違うと各変数の相対的な比率が変わる反面、同じ品種同士では各変数の相対的な比率はさほど変わらない（全体的に大きかったり小さかったりという個体差があるだけ）と想定すれば、結果が一直線上に並ぶのもなんとなく理解できる気がします。

「じゃあどう呼べば良いのか」って？　そんなの自分で考えてよね！

　「コサイン距離」に変わる呼称方法ですが……

　ま、常識的に考えると、コサイン非類似度でいいのではないでしょうか。

わかったなら感謝しなさい。……え、ありがとう？　べ、べつに喜ばれても嬉しくなかんないんだからっ！

　安易に「コサイン距離」という言葉を使ってはいけないこと、また、距離として扱うと問題になるというか、イマイチな結果を招く可能性があることがこの記事でわかっていただけたら、嬉しいです。

　あと、ツンデレ風の章タイトルにしたことに対して今更ながら後悔の念を感じ始めているのですが（自分で見返してもかなり痛い）、下書きに放り込んで一晩寝たらたぶん投稿する勇気がなくなっていると思うので、蛮勇を奮ってこのまま後悔公開することにします。

AIでプログラマーが失業するとか、気にしなくていいと思うよ

2019-06-29T19:20:58+09:00

はじめに

　昨今のAIブームで、AIへの過剰な期待からか「プログラマー」が失業するのでは？　ということが囁かれるようになりつつあります。

人工知能によってプログラマーは失業する？AIに仕事を奪われる前にAIエンジニアになる？ | アトオシ
 プログラマーという職業は10年後にはなくなる？これからの10年をどう生きるか | フリーランスへの道しるべ

　正直「人目を引くために過激なこと言ってるだけだろ」という気もしなくはないのですが、この分野の末席で研究をやっている大学院生として*1コメントしておくことにします。

AIの定義は時代とともに移り変わる

　ある程度ご年配の方だと、「AI搭載でおいしく炊ける炊飯器」「AIが最適に制御するエアコン」といった製品が出てきた時代のことを覚えていると思います。今では「ただのマイコン制御じゃん」と思う訳ですが、それが当時最先端の「人工知能」でした。

　他にも、以下のような技術は少なくとも登場時点では「AI」とみなされていたはずです。もちろん、今ではそんなことを思う人は（ほとんど）いません。

プログラミング言語のコンパイラ
かな漢字変換
郵便番号の自動読み取り

　その時代の技術で実現できなかったもの、実用化されなかったものが「AI」と呼称されて残る、というシニカルな見方もあるくらいです。

人工知能の歴史 - Wikipedia
http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h28/pdf/n4200000.pdf

　特にプログラミングに関して言えば、簡潔に問題を解決できるよう、自動的に処理できる部分は自動的に処理させるという方向性の努力はずっと続けられてきています。だからこそ、素晴らしいオブジェクト指向プログラミングができたり、モダンな言語で型推論が使えたりする訳です。

「自動プログラミングとは、いつの時代もその当時のプログラマが使える言語より高水準の言語でプログラミングすることを意味する婉曲表現だった」
D. L. Parnas. "Software Aspects of Strategic Defense Systems." American Scientist. November 1985.
翻訳は　自動プログラミング - Wikipedia

　なので、一つの考え方は「今までどおりのことだから気にする必要はない」というものでしょう。

　だけど、プログラマーが失業する、という予見が世間を賑わせるようになったのは、今までの状況とは少し異なりそうです*2。

　もうひとつの考え方、つまり「ついに人間の能力に匹敵するAIができそうなので、これまで高度な知的職業とみなされてきたプログラマーが失業しかねない」という考え方が説得力を持つようになった、とみなすのが自然でしょう。そこで、これについて、もう少し色々な角度から考えてみます。

これつでに技術革新で消滅した職業

　1950年代とか大昔には、ソースコードは手書きしたりタイプライターで打ち込んだりして、キーパンチャという職業の人に渡していました。キーパンチャの人が何をするのかというと、渡されたコードをパンチカードに打ち込むのです。打ってもらったパンチカードをIBMなんかの汎用機のカードリーダに突っ込んで、プログラムを読み込ませていました*3。

　キーパンチャの人は、パンチカードが廃れた80年代に当然失業しています。やることはデータ入力なので、パンチカードが廃れても潰しは効いたと思いますが……

　もう少し一般的な例だと、昔は植字工という職業がありました。活字というのはもともと鉛で作られた字のスタンプのことで、それを並べて作った組版にインクを塗って紙に押し当てて印刷するのが活版印刷です。なので人の手で活字をケースから集めてきて並べないと印刷ができないという時代があったのですが、これもオフセット印刷などが普及したことで、職業としてはほぼ消滅しています。

　技術革新で消滅した職業というのは、他にもたくさん、いくらでもあります。そういう職業についていた人は一度は失業して、年配の方ならばそのまま現役引退されたかもしれませんし、まだ若ければ最終的には他分野に転職した人が多いと思います。

　プログラマーがこういう未来をたどる、という可能性について議論したい、ということなのでしょうね。

AIの水準はそのレベルに達しているか：まだ無理

　残念ながら、昨今の人工知能ブームで中心的な役割を果たした深層学習は、「人間のような高度な判断が行える」という域には達していません。「ある程度人間の判断を代替できる」「大量のデータに対して機械的に適用できる」といったあたりが関の山です。

　機械翻訳などがわかりやすいでしょう。最近の機械翻訳は深層学習の技術を取り入れていて、単純な文であればかなり正確に翻訳できます。左の文を現在のgoogle翻訳に入れると「
Modern machine translation incorporates deep learning techniques, so simple sentences can be translated fairly accurately.」と訳されますが、かなり文意の通じる訳文になっています。

　ただし、含意まで読み取るというところまでは実現できていないのが現状です。それに、専門用語やスラングなどを文脈に合わせて翻訳する、といった必要があるケースでは、かなり不満の残る結果しか得られません。

　「コンピュータはあいまいな情報を処理するのが苦手」ということは昔から言われていましたが、最近は「あいまいな情報からも適当に推論してしまう」というあたりまでは達しています。だけど、あいまいに見えても背後には案外しっかりした規則があって、人間にはそれがわかるけど機械にはわからない……というような状況では、あまり深層学習は役に立たないはずです。

　このあたりは技術の発展を待つ必要がありますが、とにかく大量のデータを突っ込んで、深層学習モデルで学習させて……という方向性で人間の判断を模せるレベルのものを作るのは、個人的には不可能だと思うし、AIの分野の人達もそういう方向性は目指していないのでは？

　何らかの技術的ブレークスルーがないと「もっと幅広い応用」は出てこないと思いますが、使えそうな技術の基礎研究はある程度出尽くしていて、その応用に力が注がれているのが現状です。もちろん深層学習の次世代（になるかもしれない）技術を研究してる人はたくさんいると思うんですが、現時点ですごく優秀で使えることがわかっているというものはありません。当然ですね。

プログラマーっていってもけっこう難しいことをしている

　プログラマーという職業の人達がどんな仕事をしているのかを考えてみましょう。機械が代替できるかどうかは、このあたりにかかっています。

　とりあえずどんなプログラムを書くにせよ、その前に要件定義とか仕様の決定とか設計文書の作成とかをやるというのが典型的なケースです。中には、そこまできっちりやらないでとりあえず試作してみて、お客さんの反応を見ながら正式な仕様を決定していくみたいな方針もあると思いますが、考えることが多くなりすぎるのでやめます。

　たとえば、こういうのを考えましょう。「プログラム設計」とかでググって適当に出てきたサイトからの引用です。

プログラム設計書の書き方の例
定数リスト
No｜名称｜値｜型｜クラス名｜ファイル名｜書式｜説明
1｜BOOK_LIMIT｜30｜int｜book｜testdayo.Java static final int BOOK_LIMIT｜収容できる本数の上限
関数定義
書式：boolean check_book_limit(int storage)
機能：収納したい本の数（storage）が収納の上限数（BOOK_LIMIT）内に収まるかを真偽値で返す
引数int strageの意味：収納したい本の数
戻り値：true：収納できる
戻り値：false：収納数が上限を超えるため収納できない
プログラム設計書とは？｜各設計書の違いと書き方 - Midworks

　おおすごい、ぜんぶ挙動が定義されてる……これなら機械処理できるんじゃね？　と誰でも思います。とりあえず、クラスは省略してpythonで書いてみましょう。

BOOK_LIMIT = 30

def boolean check_book_limit(storage):
    return storage <= BOOK_LIMIT

　上の「プログラム設計書」から下のコードくらいのものを生成できれば良い訳ですね。なるほど、楽勝だ……。20年くらい前にも同じようなことを考えた人たちがいて、やろうとしたのですが、あまりうまくいかなかったそうです。やっぱり、機能が複雑になったり、説明が曖昧だったり手抜きになったりすると破綻するのでしょう。

　思いつく問題点をとりあえず列挙してみると、

上の例だとしっかり書かれていて「収納の上限数内に収まるか」なので曖昧さはないけど、「以上」「未満」「より」とか出てくると途端にカオスになって曖昧さが紛れ込む。自然言語はそんなものです
とりあえず、自然言語だと解析が辛いから、曖昧さのない形式言語で書いておきたい→プログラミング言語で書くのと何が違うの？　という話に
そもそも、この粒度の仕様が作れるなら、仕様書書く代わりにプログラミングしても良いのでは……？（上の仕様からプログラムを書き起こすみたいな仕事は、AIに関係なく減っていくと思います）
現実に与えられる要求は「本が本棚に収まり切るかどうかチェックしたい」「ボタンを押すと画面が明るくなる」みたいなレベルのやつで、文脈とか背景知識があれば要求されている通りのものが作れるが、逆に機械にやらせようと思ったらそういう部分をぜんぶ打ち込まないといけない。つまり、へたにプログラムを打つより苦労する可能性がある
自動生成できてもパフォーマンスは保証してくれないことが多い。出てきたものがすごく遅かったとき、どうする？

　なかなか難しいですね。こういうところを解決できるのは人間だけです。いや、機械でも「ここ曖昧でよくわからんから教えてくれ」って人間にフィードバック返しながらやればできるのかもしれないけど、最初から人間が打ち込んだ方が楽なんじゃないかなぁ。

プログラマーを代替できる水準のAIが作れるなら、プログラマーに限らず色々な職業が消滅する

　こういう問題が解決して、適当に仕事を押し付ければ満足の行く結果を出してくれるAIが仮に作れたとしましょう。

　そういうAIは人間のプログラマーと同じ水準の仕事ができる訳ですが、こういうAIが作れるようになって失業するのは何もプログラマーに限られません。消える職業の方が多いでしょう。

　ことさらにプログラマーがどうの、という話をする前に、考えるべきことがたくさんある訳です。「プログラマーはAIに取って代わられるのか、じゃあなるのやめよう」と思って別業種に就職した就活生がいたとして、その職業が先にAIに取って代わられない保証はまったくないのです。

　だから、真に受けてプログラマーの将来だけ心配するのは馬鹿馬鹿しいし、真剣に考えるなら社会全体の問題です。

まとめ

　AIに関係なく言語や技術が廃れて「これまでやってきた仕事がなくなる」ことはこれまでにも頻繁にあったと思います。それはそれでなんとかしてきた訳で、当分はその延長線上で推移すると思うので、今までどおりなんとかなるでしょう。

　実際問題として20年先のこととかはわからないし、真面目に考えて人生設計に反映している人がどれだけいるんですか？　という話でもあります。だから、別に気にしなくていいんじゃないですかね。

*1:といっても、今の研究はデータサイエンス寄りで、この辺にはほとんど絡みませんが……

*2:前もあったよ！　といえば、それはまあその通りなのですが

*3:さも見てきたかのように書いていますが、実際に見たことはありません。こういうことをしていた世代の人は、古い人だともう鬼籍に入られている方も多いくらいでしょう

今あえて書く、目的別Pythonを使うメリット・デメリット

2019-06-26T23:53:52+09:00

はじめに

　ここ数年間、日本国内のPython事情は急速に変わったと思います。私が使い始めた4年前と比べても、ずいぶん垢抜けた感じになったというのが正直な感想です。

Python2からPython3への移行が（ようやく）進み、扱いやすくなった
ライブラリも良いものが増えたり、使いやすくなったりした
解説記事などもずいぶん増えて、やりやすくなった
古くからの用途であるデータサイエンス、機械学習に代わって、プログラミング初心者の勉強用言語として選択する人が増えた

　というあたりが実情でしょうか。Pythonの急拡大を支えたAIバブルには陰りが見えてきた感もなくはありませんが、Python自体は一定の地位を確保しつつある感じがして、蛇使い*1としては嬉しい限りです。

　こういう時期だからこそ、客観性を心がけつつ主観混じり的に見て「Pythonは良いのか、悪いのか」を少し書いておこうと思います。

　Python言語全般についてというのは漠然としすぎなので、用途別に書きます。長い記事なので、時間のあるときに興味のあるセクションだけお読みください。

はじめに
Web
いわゆる「アプリケーション」（スマホアプリ、PCのデスクトップアプリケーションなど）。あるいはゲームなど
スクレイピング・チャットbotなど
プログラミング初心者の学習用
データサイエンス・機械学習・深層学習・その他の科学技術計算分野
その他の考慮事項
まとめ

Web

　Webで使うのはあまり流行ってないし、正直（特に国内では）たぶん流行らない。以上。

　Pythonは要するに普通のLLなので、なかなかPythonならではのメリットというのは見出しづらいのが実情でしょう。この分野はPHPやNode.jsなどが強すぎるし、それ以外に強いやつもたくさんいるので*2、積極的にPythonを選ぶシチュエーションは正直思いつきません。少なくとも、Web開発を勉強したいという人が最初に勉強するべき言語ではないと思います。

　ちょっと擁護しておくとすれば、「それなりに良い（であろう）実用的なフレームワークは揃っている」「Pythonを使える人にとっては、書きやすい」という側面はあるので、いつのまにか蛇使いになっていたという人がWebを勉強したくなったときにはDjangoやFlaskが助けてくれることでしょう。ニッチな需要もいろいろあると思いますし、絶対ダメというほどでもありません。

　いずれにせよ、Pythonは「Web分野のトップランナー」という感じではないです。勝手な想像ですが、先頭集団の末尾くらいのポジションだと思います。扱いに困ります。

いわゆる「アプリケーション」（スマホアプリ、PCのデスクトップアプリケーションなど）。あるいはゲームなど

　スマホアプリははっきり言って論外。実用的なものを作る方法はほぼないと思います（まったくないとも言い切れないのが苦々しいところですが、あえてこう書きます）。

　デスクトップアプリケーションですが、作れなくはないです。しかし、もっと向いている言語がいろいろある（windows向けならC#あたりでいいでしょう）ので、Pythonでやろうというのはかなりの変人の選択です。

　やはりPythonはスクリプト言語なので、どうやって単一exeにして持っていくか（あるいは相手のPCにPythonをインストールさせるのか）というところで躓きます。単一exeにする場合、どうしても起動が遅いし容量がやたらでかくなる*3みたいな欠点があります。相手のPCにPythonをインストールさせれば問題は少ないのですが、そこまでしてPythonで動かしたいものって何？　という疑問が生じます。

　例外として、UNIX系でOSに組み込まれているPythonをあてにして動くツールというのは実際にたくさんありますし、作っても良いと言えます。ただ、あれはあれで良い面も悪い面もある文化なので、一概には言えない感じがしますが……そういうものを作ろうとする人はこの記事を読まないかな。

　総評としては、そういうものを作るにはデメリットが目立つ、ということになります。

スクレイピング・チャットbotなど

　この手の処理はどんな言語でもできるといえばできるのですが、最近はPythonの情報が多い気がするので、やりやすいと思います。こういうことを気楽にやるのに向いている気もします。
（ただし、それなりにプログラミング慣れしている人が相応の配慮の元行うのが前提です）

プログラミング初心者の学習用

　この章は特に主観的な面が強いので、そのつもりで読んでください。

　まず、私は「まずはC言語でプログラミングの基礎を理解しろ」という教育を受けたので、PythonみたいなLLから入ることには否定的です。すごく高級な言語なので、初心者は何やっているのかわからないと思います。そういう部分を丸暗記して、なんとなくで書き続ければ「Python」は書けるようにはなるかもしれませんが、「プログラミング」の勉強にはあまりならないような……

　というのは哲学的なことなので、もう少し現実寄りのことを書いておくと、

初心者向けの親切な教材やネット情報が少ない

　致命的

独自の構文みたいなのが多い

　内包表記とか。覚えてもPython以外で役に立たない、知らないとPythonを読めない

細かいハマリどころが割と多い

　インデントが狂ったりとかlist = [[]*3]*3とか。貴重な学習時間をつまらないことで潰したくないですよね

　とまあ、初心者向けの言語ではないので、おすすめしません。同じポジションならRubyとかの方がまだ良いかもしれない。

　そもそもGuidoがUNIXハッカー受けを狙ってクリスマスの暇つぶしに作った言語なので、初心者の学習用で使われるようになるというのは想定していなかったと思います。チュートリアルの冒頭を読めばわかるとおり、「玄人向け」です。

　Pythonが教育で使われているという事実はありますが、ちゃんと見てくれる先生のもとで限定された機能だけを使って学習していると思われます。このあたりに関してはまったく知識がないので憶測含みですが、おそらく基本的な演算とか制御構文、関数あたりの基本的な機能を使ってプログラミングの考え方に親しんでもらう、という趣旨の『教育』ではないでしょうか*4。

　なので、プログラミングの勉強の第一歩としてPythonを始めた/始めようとしている人は、よく考え直しましょう。とても気に入っているならやめる必要はないかもしれませんが、向いていないと思ったら他のものに切り替えた方が賢明なはずです。

データサイエンス・機械学習・深層学習・その他の科学技術計算分野

　とりあえずこの辺のジャンルをざっくりまとめてしまいましたが、当然これらはすべて別の分野です。なので、節を分けて説明します。

データサイエンス

　さて、データサイエンスと言っても漠然としていて何がなんだかという世界なのですが、とりあえず考慮するべきなのは以下くらいでしょうか。各項目同士でオーバーラップする部分もありますし、データサイエンスに含めるかどうか悩むものとかもありますが、あまり深く考えないでください。

探索的データ解析（可視化など）
統計処理・分析（検定、分散分析とか）
統計的モデリング（回帰や判別とかいろいろ……）
多変量解析（いろいろ……）
その他いろいろ……

　手持ちのデータに対してデータサイエンス的な分析を行いたいという場合、Pythonを積極的に選択するかどうかは悩むところです。この分野には強い競合がたくさんあります。当然Excelも選択肢になりますし、SPSSのようなリッチなソフトウェアもいろいろあります。立ち位置が近いものとしてはRがあります。あとは簡単な処理ならDB叩いてSQLでやっちゃうとか、いろいろ手はあります。

　Pythonの立場は、どれもできなくはないけど、最強ではないしどちらかといえば微妙……という感じではないでしょうか。Pythonで可視化しようとすると面倒くさいし、検定とか統計処理は少し一般的でないことをやろうとするとパッケージがなくて困ったりするし……

　たとえばRは統計系パッケージが充実しているとよく言われます。野良実装みたいなのまで含めればそらPythonにだってあるわ（PyPIにCRANの何倍登録されてると思ってるんじゃ）……と思ったりもするのですが、さすがに大人げないですね。

中堅以上の（ある程度大きな信頼できるチームでまともに開発・メンテナンスされていて、普及している）パッケージで、どれくらい色々な手法なんかが使えるのか

　という観点で見ると、たぶんRが勝るということだと思います。

　まあでも、pandasは強いしstatsmodelsもあるし、メジャーな手法のライブラリはなんだかんだで探せばあるし、というかマイナーなのでも探せばなんだかんだであったりはする。どマイナーなものは別に使えなくても困らないし、最悪必要になったら自分で書く。

　と割り切れば、Pythonのエコシステムですべてが完結します。同じことができるのはたぶんRだけなので、一騎打ちですね。

　あとは考慮するべきなのは好み、慣れ、使いたい手法のライブラリの対応状況、他の処理との兼ね合いくらいでしょうか。積極的に甲乙つける気にはなれないので、保留します。

　特定のことをやろうとするとPythonより良いツールはあるのですが、ぜんぶできるツールとしては最高かそれに準じる立ち位置なので、データサイエンスに向いていないということはまったくないと思います。

機械学習

　深層学習は別ジャンルなので、あくまでもコンベンショナルな機械学習の話です。

　基本的にはほぼデータサイエンス関連と同じ状況。強いて言えば、データサイエンス分野ほどにはRに負けていないか、むしろ勝っている気がします。scikit-learnのエコシステムが強いのと、流行っているのと、やっぱり（機械学習畑の人たちにとって）読み書きがしやすいからでしょう*5。

　使いやすいし、情報も多いので、機械学習やりたければPythonというのは良い選択だと思います。

深層学習

　Pythonは深層学習フレームワークのwrapperを叩く環境として、唯一無二の地位を占めています。この分野では最強です。

Q:C++から呼べばいいのでは？
A:いやです。

　が通用するので、この地位は揺らがないでしょう。

　私は正直ほとんど深層学習やったことがないのですが、ここが廃れると他もガタつくと思うので、蛇使い的には深層学習屋には頑張ってほしいなぁ、と思います。

その他科学技術計算

　面倒なのでひっくるめてしまいますが、いろいろありますよね。

画像処理

　OpenCVのwrapperとして使っている人を一定数見かけます。悪くない選択だと思います。ただ、あのエラーメッセージは普通のPythonユーザが読んでも何のことやらって感じなのでは？

音声処理

　ほとんど話題を見かけない。

自然言語処理

　自然言語処理の中にもいろいろあったり、最近はそもそも半ば深層学習に吸収されていたりといった感じですが、それはさておきPythonで自然言語処理というのはよく見かけます。

シミュレーションとか数値解析とかスパコンで走らせるようなやつ

　……この辺になると畑によってまちまちだと思いますが、さすがにコンパイル言語で書くのでは？

　まあ、強いライブラリ（か、そのwrapper）がある分野では使えます。あとは、numpyやscipyがあるので、気楽にアルゴリズムを書いてみるのには便利です。

その他の考慮事項

　目的別にはだいたいこれくらい挙げれば良いような気がしますが*6、他に考えるべきことをいくつかあげます。

言語仕様など

　Pythonの構文とプログラミングモデルは綺麗だと思います。私個人の感想です。

　公式でPEP8というコーディング規約まで定めて、スタイルの一貫性を重視しているのも良いところです。ただ、さすがに「誰が書いても同じようなコード」は実現できていないのが現状だと思いますが*7。それでも、そういうポリシーを掲げるというのは立派なことだと思います。

　純粋なプログラミング言語として好きになれるようなものである、ということです。LISPに通じるものがあります（でも、そういう言語はPython以外にもあるでしょう）。

インターネット情報

　かつて（私が学び始めた頃）は、Python関係で検索すると、Python2時代の（2008年くらいの）黴の生えたような「はてなダイアリー」の記事が出てきたりして、げんなりさせられました。

　最近はそういうことはずいぶん減って、新しくて質の高い情報がよく出てくるようになったと思います。要するに流行ったおかげなのですが、情報がなく、古くて困るということは今はあまりないと思います。

　あと、（順番おかしいですが）それなりにちゃんと日本語に翻訳された公式ドキュメントもあります。日本語で出てこないときでも、英語では何かしら出てくるので、最悪google翻訳に通したりして読めば問題が解決するのもいいところです。

　さすがにJavaとかとは比べられませんが、ある程度の検索スキルがあれば情報がなくて困るということはそう滅多にはないと思います。

環境構築の容易さ

　Pythonは環境構築が難しいとおっしゃる方は一定数いますね。でも、たとえばWindowsなら公式からインストーラを落としてきて入れるだけです。UNIX系も基本的にはパッケージマネージャで入れるだけです。

　にも関わらず「難しい」印象になってしまうのは、

「他バージョンのpip叩いちゃった問題」がつきまとう
anacondaのせい

　慣れてない人が使うとかえってトラブルの原因になる

pyenvのせい

　同上。

　あたりの事情が絡んでいる気がします。

　たぶんこの手の操作（環境構築）に慣れている人にとっては簡単だし、慣れていないと難しいはずで、でもそれはどんな言語でもたぶん同じなので、Python固有のデメリットというほどでもないかなぁ、というのが率直な感想です。ただし、IDEのインストーラを走らせればすべてが完了するような言語と比べると、自分でやることが増える分難しいというのは真実かもしれません。

まとめ

　書いていて思ったのですが、無条件でPythonがファーストチョイスと言えるのは深層学習を気楽にやりたいときくらいですね。統計・機械学習などでもかなりファーストチョイスに近い位置にはいますが、Rとカチ合います。それ以外の用途だと、やはりデメリットの方が多い気がします。

　よく言われていることですが、Pythonは汎用のLL言語で、気楽に書けてオールマイティに色々使えるのが強みです。それに情報工学・計算機科学系のあれこれが乗っかっているので最強に見えます。Rには、この言語でなんでもできるという汎用性は（こう言い切っちゃうとR好きの人に怒られるかもしれないけど）ありません。

　こういう特性を理解して使いこなせれば素晴らしい言語ですし、漫然と勉強しても活用することは難しいのかもしれません。メリットを活かした使い方をしよう、ということですね。

# ところで、メリット・デメリットって銘打ったのに、箇条書きでメリットとデメリットをそれぞれまとめるという、よくある書き方をするのを忘れた……まあいいか。

*1:Pythonユーザのことです、念の為

*2:Web向けで高パフォーマンスのコンパイル言語で書きやすいってコンセプトだけで一体いくつあるんだよ、とか

*3:インタプリタ一式持っていくので……

*4:違うよ！　こんな感じだよ！　というご指摘があれば大歓迎です

*5:でもcaret見るとscikit-learnよりいろんなモデルに対応してていいなぁとか思ったりするんですが

*6:この辺が漏れてるよ！　というご指摘は大歓迎です

*7:たとえば具体的に言うと、iterable周りで選択肢が多すぎて書き手の個性が出まくる

はてなブログで自動生成されるゴミページをnoindexにする

2019-06-23T21:01:06+09:00

　はてなブログを利用していると、様々なページが自動生成されます。よくあるのは?pageのようなURLパラメータの付いた、よくわからないページでしょうか。
（アーカイブの絡みで出ているのがわかることもありますし、完全によくわからないけど存在するページというのもあります）

　世の中には、こういったページが大量に存在するとSEO上よくない、という都市伝説があります。本当か嘘かはわかりませんが、どのみち気分的に良くないのは確かなので、こんなJavaScriptを書いてみました。

<script type="text/javascript">
<!--
var noindex_regexp = /\?page=|\?q=/;
if( noindex_regexp.test(location.href)) {
	var head = document.getElementsByTagName("head")[0];
	var meta = document.createElement("meta");
	meta.setAttribute("name","robots");
	meta.setAttribute("content","noindex");
	head.appendChild(meta);}
//-->
</script>

　JavaScriptに詳しい方が見たら笑われるようなコードかもしれませんが、ご容赦ください。とにかくこれで、pageとqのURLパラメータがURLに含まれていれば、動的にheadにnoindexを設定できます。

　これはどこに入れても機能します。少しでも読み込み速度を上げる観点からすると、デザイン設定画面からフッタに入れると良いでしょう（おまじない程度ですが）。

　この状態で一ヶ月くらい運用しましたが、googleのクローラはちゃんとJavaScriptをレンダリングしてくれるようで、確かにSearch Consoleを見ると狙ったようなページがnoindexになっています。なお、特段のSEO上の効果は今のところ実感できていませんが、デメリットも特になさそうなので設定しておいても良いのではないでしょうか。

teratailでのプログラミング初心者の質問の仕方

2019-06-22T23:50:31+09:00

はじめに

　teratailはプログラミングで生じた疑問を投稿すると、他のユーザーに回答してもらえる、便利でプログラミング初心者の方にとってはとても心強い味方になり得るサービスです。

　一方で、「使い方がわからない」「どんな質問をすればいいの？」「こんな内容で投稿していいのか不安」という人も多いと思います。また、中には「質問したけど回答がつかなかった」「質問に低評価がついて心が折れた」「コメント欄で文句を言われた」という人もいることでしょう。

　そこで、プログラミング初心者の方向けに「どんな風にteratailを使えばいいのか」を軽くまとめておきます。

　なお、少し自己紹介しておくと私は普段回答者としてteratailを利用しており、teratailのPythonタグで総合一位を持っています（2019年6月2日現在）。

私のプロフィールページ

　思わず回答したくなるような素晴らしい質問も、思わず回答したくなくなる駄目質問も数えきれないほど見てきたので、以下の内容もそれほど間違ったことは書いていないつもりです。回答する側の立場として、こうしてくれたら嬉しいな！　ということを書きますので、ご一読いただければと思います。

　また、teratailの公式のヘルプページもできれば質問する前に読んでおいてください。

ヘルプ｜teratail（テラテイル）

　特に、「質問するときのヒント」は必見です。質問する方全員がこれを読んでくれていたら、と思うときがたまにあります。

質問するときのヒント｜teratail（テラテイル）

　この記事も、基本的にはこれらの記述に準拠した上で、回答者として日頃から思っていることを織り交ぜて書いています。ヘルプと重複する部分も多いので、時間のない人はこの記事を読まないで公式のヘルプだけ読んでいただくというのも一つの選択です。ただ、回答している人たちの考えていることを知りたいな、という人は、以下を読んでいただければスムーズなコミュニケーションにつながると思います。

どんなところなの？

　この記事を読んでいる人は、あまりteratailというサービスについて詳しくないと思うので、大まかな概要を先に説明します。

　が、この記事を読み進める前に、まずは

3分でわかるteratail｜teratail（テラテイル）

　を一読してみてください。基本的な前提はこれで把握していただいて、補足的なことを中心にこの記事で書いていこうというつもりです。

　……さて、読んでいただけたでしょうか。では、説明してまいります。

どれくらい流行ってるの？

　日本語圏のプログラミングQ&Aサービスでは、かなり活発に動いているところだと思います。一日に数百件程度は質問が投稿され、9割には回答がついています。

　他のQ&Aサービスとしてはスタック・オーバーフローもありますし、Qiitaで聞く、あるいはヤフー知恵袋や2ch,、Twitterで聞くという手もありますが、総合的な回答の得られやすさではteratailはかなり上位に位置するでしょう。

そもそも初心者が質問していいの？

　こういう疑問を持っている人も多いと思います。ページタイトルにも思いっきり「ITエンジニア特化型Q&Aサイト」って書いてありますし、現時点でITエンジニアではない人間が使って構わないのか？　と思う人も多いですよね。

　確かに、運営がITエンジニア特化をうたっていることは事実です。ついでにいえば、少し前までは「思考するエンジニアのためのQAプラットフォーム」と銘打っていました。おそらく、本来目指していた方向性はそういうものだったのでしょう。

　しかし、だからといって非エンジニアはお断り状態なのかというと、それも違います。実際にプログラミングに不慣れとおぼしき方の質問も多いですし、そういった質問にも親切な回答がつくことが多いです。ついでに言えば、私も現役のエンジニアではなく、学生の身分のまま一年以上回答していますが、それが問題になったことはありません。

　割と敷居の低いサイトですし、初心者質問であっても丁寧なものであれば歓迎されている、というのが私の個人的な肌感覚です。なので、プログラミング初心者の方でも遠慮せずに使って良いと思います。

なんでも聞いていいの？

　プログラミングに直接関連することであれば、基本的には何を聞いても構いません。

　ただしある程度は制約があって、無条件でおすすめできるのは「エラーが出た」「思い通りに動かない」「こう書いてみたけど、あまりにも冗長なので書き換えたい。そのやり方がわからない」といったあたりまでです。要するに、コードを書いていて行き詰まったことを聞きましょう。

　「おすすめの書籍を教えてください」「プログラミングを勉強したいけど、おすすめのスクールは？」「エンジニアとしてのキャリアの積み方」みたいな質問はあまり推奨されていませんし、荒れる傾向にあります。

　自分の聞きたいことがそういったジャンルに該当するかも、と思う人は、投稿する前に下記のページを一読していただいた上で、投稿するかどうかを判断していただければ良いと思います。

推奨していない質問｜teratail（テラテイル）

　また、最短距離で解決したい場合は、teratailで質問するより良い方法がある場合があります。たとえば、マイナーなライブラリを使っていてそのバグっぽい挙動に悩まされたら、teratailで聞くよりは、そのライブラリのgithubのページを探してissueを投げた方が良いです。開発に使っている製品のサポートセンターがある場合は、そちらに先に問い合わせましょう。一般的なteratailユーザにとって回答が難しい質問は、そういったところを案内されて終わるパターンもあります。

気軽に質問していいの？

　これについては、「気軽に」の程度が人によって大きく異なるので一概に言えません。

　ですが、できれば質問する前に自力で解決する努力をしてほしい、というのが全回答者ユーザの総意だと思います。で、いろいろ試行錯誤したこと、調べたことを質問文に具体的に書いてくれるのが理想的です。

　「タイプミスですね」とか「そのエラーで検索すると一番上にヒットする対処で解決しますね」みたいなのもたまにありますが、こういうのは時間の無駄ですし、虚しいです。

　それと、質問する人の中には、teratailで短時間で疑問が解決したのに味を占めて、毎日のように「ちょっと考えればわかるだろ、それ」という質問を出すようになる人もいます。これは当然ながら迷惑ですし、自身の成長にも繋がりません。節度を守って利用しましょう。

回答者はなんでわざわざ回答してるの？

　これ、謎ですよね。私もよくわかりません。2400件以上答えてるのに。

　もちろん人助けをしたいというのが基本的な動機でしょう。ボランティアです。また、回答する人も昔は初心者でいろいろな人に助けてもらった訳だし、インターネットの情報は今でも日々使っているでしょうから、恩返し的な意味で回答している、という側面もあるでしょう。

　また、teratailでは色々な技術的な話題が交わされます。回答者をやっていると勉強になるのは事実です。私がはじめた理由はこれでした。

　teratailで高い順位・スコアを誇っていれば転職などで活用できるという側面もありますが、これについてはあまり話が表に出てこないのでなんとも言えない面があります。でもまあ、そのためだけにやっている人というのもいないでしょう（自作のアプリケーションやWebサイトを作ったり、OSSで貢献した方が効率は良いでしょう）。

　あるいは、知識自慢とか、マウントの取り合いのつもりなのかもしれません。そういう人も中にはいると思います。いわゆる「教えたがり君」ですね。

https://ja.uncyclopedia.info/wiki/%E6%95%99%E3%81%88%E3%81%9F%E3%81%8C%E3%82%8A%E5%90%9B

　それか、単なる暇つぶしとか娯楽、と答える人もいるかもしれません。

　……とまあ、いろいろな人がいると思います。（わざわざ節を立てて論じておいてなんですが）、いちいち考えるのは無駄ですので、気にしないほうが良いです。

　建前上は善意で回答しているということになっています。建前は尊重した方が安全なコミュニケーションが取れます。

使う上でのマナー

　さて、できれば「これくらいは守ってほしい」というマナーについて書いておきます。と言ってもそんなに押し付けがましいことを書くつもりはなく、質問者と回答者が快く、スムーズに問題を解決するための「マナー」です。

　一般的なネチケット、Q&Aサイトの利用方法は当然守ることを前提としています。その上で、特にteratail特有の事情について書いておきます。

　ここでいうマナーとは私が勝手に決めたものではなく、おおむね以下に準拠します。
質問するときのヒント｜teratail（テラテイル）
推奨していない質問｜teratail（テラテイル）

質問する前に自力で解決できないか頑張る

　基本的なことですが、質問する前にできるだけ自分で解決するように試みてほしいです。

　ここで言っているのは、

タイプミスしていないか確認する
言語やライブラリの公式マニュアルを見て使い方が間違っていないか確認する
エラーメッセージが出たらそれで検索して、出てくるサイトを読む。英語のサイトが出てくるかもしれないが、google翻訳を使ってでも読む

　というレベルの内容です。また、可能な範囲でできるだけデバッグしてください。
（そういう努力の形跡が見られない質問が多すぎて、私が個人的に疲弊していることの裏返しでもあります。）

　実は、本当にどうしようもない質問だと5分くらいで解決したりすることもあるのですが、そういうのは質問者も回答者も互いに虚しいし、無益です。質問する人にとっては自力で解決するスキルが鍛えられませんし、回答する人はあまりにそういうのが多いと疲れます。

　行き詰まったら1時間は頑張ってみて、どうしても駄目なら10分くらいはかけて丁寧に質問を書く、というのが個人的にはいい塩梅だと思います。

最低限Markdownを使いこなす

　teratailはMarkdownに対応しています。Markdownという言葉を初めて聞いた人も多いと思いますが、これは「特定の書き方をすると、綺麗な見栄えに変換されて投稿される」という機能です。

　Markdownはとても多機能なので、完璧に使いこなす必要はありません。ただでさえプログラミングの勉強で忙しいのに、Markdownの使い方まで学ぶ暇はないという人もいるでしょう。

　ただし、teratailのシステムの仕様上、残念ながらMarkdownをまったく知らない人は「そもそもまともに質問できない」可能性が高いです。そういうシステムなので仕方ありません。

　以下に示す最低限のものは覚えて使ってください。数分で読み終えて理解できるはずですし、それで質問する側も回答する側も気分よく利用できるのですから、知っておいて損はありません。

コードはコードブロックの中に入れる

　回答者にとって、質問者に守ってほしいであろうマナーNo.1です。

　プログラムを直接質問に書くと、とても見づらい表示になってしまいます。

コードブロックを使わなかった例

　インデントが潰れてしまうのと、# から始まるコメント行が見出しのMarkdownとして解釈されてしまうのが主な問題点です。他にも、Markdownとして解釈され得る記法があれば、そのまま表示されないことがよくあります（たとえばPythonの__init__などは斜体（イタリック）として解釈されます）。

　こういうコード部分はコードブロックを使ってください。

コードブロックを使った例

　コード部分の上下に```と書くだけです（キーボードが日本語配列なら半角モードでShift+@で入力できると思います）。なお、開始の```と終了の```は、基本的にはそれだけで一行になるようにしてください。余計な文字やスペースを入れるとうまく表示されないことがあります（後述の言語名は例外です）。

　手で打ち込むのが面倒くさい場合は、質問入力画面の<code>ボタンを押せば挿入できます。こちらでコードブロックを挿入してから間にペーストするか（繰り返しますが改行に注意）、先にコードを貼り付けてからコード部分を選択して<code>ボタンを押してください。

　なお、上側の```の右側には言語の名前を入力できます。<code>ボタンで挿入した場合は、「ここに言語を入力」というテキストがデフォルトで入っていると思います。これについては、そのままでも、単に消しても構いません。また、これを消して代わりにpythonとか、C、Javaといった言語名を書けばそれに応じてシンタックスハイライトが付きます。

　また、コードの他にも「エラーメッセージ」「CSVデータ」などもコードブロックの中に入れることをおすすめします。やはりそうしないと見づらくなるからです。

「文章中のコード」機能を使う

　こちらは上のコードブロックに比べると使う頻度が低いですが、``で囲むと行の中にコードを挿入できます。変数名や関数名などで使ってもいいでしょう。

　また、変数や関数などの名前がMarkdownとして解釈されてしまってうまく書けないというときは、この機能を使う必要があります。

「文章中のコード」機能の使用例

見出しや水平線など

　これらは上のコードブロックと比べるとそれほど重要ではありませんが、必要に応じて活用してください。

見出しと水平線の例

Markdown総評

　とにかく、コードブロックだけは使ってくれ、というのが回答者の総意です。使われていない質問には修正依頼（後述）が飛ぶことも多いです。

　また、せっかくMarkdownを使っていても、残念ながら失敗してうまく表示されていない質問もたまに見かけます。そのあたりは、プレビューを見ながら調整しましょう。

　よりMarkdownについて詳しく知りたい場合は、

対応しているMarkdownの機能を知りたい | ヘルプ | teratail（テラテイル）

　を参照してください。

状況を再現できるだけの情報を示す

　質問文の状況が再現できない、という質問も多いです。

　回答する人は、何十行もある長いコードを先頭から読んで、頭の中で動作を追いかけている訳ではありません。とりあえず手元の環境でコードを実行し、エラーやバグに関係ありそうな箇所を中心に見ています。なので、エラーになった・思い通りにならなかった状況が再現できないコードはとても困ります。

　どういう点に注意するといいのかというと、だいたい以下の点です。

OS, 言語, 開発環境, ライブラリなどのバージョンは明記する

　これは最低限守ってほしいところです。だけど、これがなくても解決できる質問はあるし、逆にこれだけではぜんぜん情報が足りない質問もあります。ケースバイケースです。

コードは可能ならエラー原因箇所だけ抜き出して、そのままコピペすれば実行可能な状態で貼り付ける。難しければ、全体を示す

　状況を再現できるミニマムなコードを掲載するのが一番ですが、それが難しい場合は実行可能な状態にして貼ってください。エラーが出ている関数のコードだけ、といった方法で載せる方がよくいますが、検証が難しくなります。

入出力のあるコードの場合は、それを載せる。入出力データが必要なら貼る

　CSVを読み込んで動かすコードなのに、入力のCSVが示されていないというのが、一番よくある困ったパターンです。また、CSVはテキストエディタで開き、コピペする形で「テキスト」として貼り付けてください（エクセルのスクリーンショットなどを載せる人もいますが、とても扱いづらいです）。ただし、著作権の都合や機密情報が含まれているなどで掲載が難しい場合は、同様の状況を再現できるダミーデータを示すようにします。また、データ量が多い場合などは外部のアップローダー等にアップしてリンクを貼る形で掲載します。

コード、エラーメッセージは省略せずに示す

　上の内容とも被りますが、コードやエラーメッセージを省略される方がよくいます。エラーが出た行だけ、エラーメッセージの最後の一行だけ、とか。

　コードは問題の本質を残した上でできるだけ短くしていただくのが理想的です。難しければ、実際に書いていて詰まったコードをそのまま載せても構いません。読むのが大変になりますが、省略されてエラー原因箇所がわからなくなるよりは助かります。

　また、エラーメッセージは必ず「全文」示してください。最後の一行だけ載せる人もよくいますが、検証が難しくなります。エラーメッセージにはエラー原因の詳細な情報が含まれているので、できれば全部見たいのです。

　なお、コードやエラーメッセージに、ユーザ名、APIのID&キーなど、公開したくない・してはいけない情報が載っている場合があります。そういった部分は、貼り付ける前に必要に応じて一括置換して頂いても構いません。

できるだけ情報を整理する

　情報を整理してください。読みづらい質問は回答もつきづらいです。

　と大雑把に書いてしまいましたが、こんなこと言われてもと思う方が大半でしょう。私もこう言われたら困惑すると思います。

　どんな情報が必要なのかはケースバイケースですが、

必要なことが伝わって
簡潔で
わかりやすくい

　質問は、そうではない質問より良いに決まっています。だから、文章構成とかにはそれなりに気を使ってください。回答する人もやっている作業ですから、同程度の労力は割いていただくのが妥当だと思います。

　コードをコピペするだけして30秒くらいで投稿したんだろうな、という質問もみかけますが、見ていて悲しくなります。どうせ投稿してから30分くらいは回答が来ない可能性の方が高いです。投稿を急ぐよりは、質問内容を充実させた方が良い結果を産みます。

　ものによっては、質問を整理している間にひらめいて問題が解決したりします。

質問タイトルに気を配る

　質問タイトルはできるだけ検索性を意識してつけましょう。ひどいのだと「Python エラー」みたいなタイトルで投稿している人が、実際にたくさんいます。タイトルを見て何の質問だかわからない、という質問を増やさないでください。

　どうしても良いタイトルが思いつかなかったら、エラーが出ている場合はエラーメッセージをタイトルにしてしまうというのが奥の手です。エラーメッセージがあれば問題を特定することはできるし、エラーで検索する人はたくさんいます。でも、これは積極的におすすめはしません。

質問した後の対応

　Q&Aサイトは質問して終わり、ではなく、当然ながら質問した後が本番です。予想もしなかったような回答がつくこともありますし、回答するには情報が足りないから追記してくれ、というリクエストが来ることもあります。

たまにはチェックする

　基本的に、回答などがつけば登録したメールアドレスに連絡が行くはずです。また、teratailのサイト上でも通知が出ます。

　半日おきくらいにはチェックするようにしてください。あまり長時間スルーされると回答者も気になります。

　たまに質問しっぱなしでその後一切の音沙汰がない人もいますが、なんのために質問したのだろうと思ってしまいます。もしかしたら自己解決しているのかもしれませんし、回答だけ見て「なるほど」と思って放置しているのかもしれませんが、自分で投稿した質問は自分の責任で適切な状態に保ってください。ベストアンサーにふさわしい回答がついて問題が解決したらベストアンサーに選ぶ、自己解決できたら自分で回答を付けて自己解決という扱いでクローズする。ということです。

追記・修正依頼がついたとき

　teratailには質問に対して追記・修正などを依頼する機能があります。ここについたコメントは回答ではありません。

追記・修正依頼欄

　大抵は「これを試してみてくれ」「こういう情報がないと回答しづらいので、追記してくれ」といったコメントが付くと思います。そういった場合は、（新たに何かを実行する必要があれば実行して結果を確認したあとに）質問を編集して情報を追加してください。

　追記・修正依頼欄での返信で情報を追加される方もいますが、この欄はデフォルトでは折り畳まれていて、多くのユーザの目には触れません。あくまで質問の修正で対応するのがベストです。
（質問の修正だけでも通知を飛ばせますが、「質問文に追記しました」といったコメントをこちらに書いていただいても構いません。そうしなくても特に問題はありません。）

　また、teratailには評価という機能があり、あまりにひどい質問・回答には「低評価」がつきます。普通に使っていればそうそうお目にかかれないものですが、もしついてしまったら自分の投稿を省みて、直せる部分があれば直しましょう。たまに嫌がらせ的につくこともあるので、省みても悪い点が見当たらなければスルーしても大丈夫です。

解決したら質問をクローズする

　適切な回答がついて疑問・行き詰まりが解消したら、ベストアンサーを選んで質問を閉じてください。

　また、質問してから自己解決した、修正依頼欄のやり取りで解決してしまった、というケースもたまにあります。こういう場合は、自分で回答を付けてベストアンサーにし、自己解決としてクローズする機能がありますので、それを使ってください。自己解決にする場合は、問題を解決するための情報を自分でつける回答に含め、後から検索などでたどり着いた人が困惑しないようにします。

質問は自分ひとりのためにあるものではない

　ここまで読んできた人は、なんかこいつ面倒くさいこと言っているなーと思ったと思います。自分で読み返してみてもそう思っているので、正常です。

　「わからないことを聞きたいだけなのに、なんでこんな面倒くさいことをしないといけないの」と当然思われるはずですが、teratailはインターネット上のサービスです。あなたの投稿した質問が無事に解決すれば、将来において同じような問題を抱えている人の役に立つかもしれません。具体的に言うと、google検索で引っかかります。

　だから、後から見る人の役に立つようにしよう、という発想が大切です。要するに、質問というのはちょっとしたレポートみたいなものなのです。

　だけど、後から見る人まで意識した質問をする、ということができる人は実際問題として少ないし、そういう人はこの記事を読まなくても良いでしょう。初心者にはかなり高いハードルなので、そこまでの条件は万全に満たせていなくてもいいかな、と個人的には思っています（たまたま役立てば結果オーライ、程度）。

　最低限越えないといけないハードルは、teratailのコミュニティのメンバー全員にとって多少は有益な投稿である、ということだと思います。つまり、回答した人が最終的に「わざわざ回答してよかった」「自分の投稿が役に立ったみたいでよかった」と思えるような質問をする、というあたりです。互いに気分よく使える、というのは大切なことですから。

　そのために何が必要か？　というと、けっきょくは常識的な丁寧さ、誠実さだと思います。陳腐な言葉で説教じみていて恐縮なのですが、そういうことが伝わるかどうかが「駄目質問」と「ちゃんとした質問」の分かれ目かな、と思います。

まとめ

　teratailで一年以上回答を続けた人間として、どんな質問が嬉しいのか、逆にどんな質問だと回答する気が失せるのか、ということを考えながら書いてみました。見直してみたら公式のヘルプをほぼなぞった内容になってしまった感もあり、少し落胆しています（というか、公式のが異常によく出来ている。ちゃんと読みましょう）。

　要約して言えば、

質問する前に数十分程度は自分で頑張れ
質問するなら再現性を確保しろ
体裁を整えろ
投稿したからには責任を持て

　という感じでしょうか。これらは、プログラミング初心者の方でも注意を払えば十分実行できる程度のことだと思います。もちろん、ちゃんとやろうとすると手間は増えるのですが、その手間のおかげでいい回答がつくこともある（ちゃんと丁寧に投稿している質問者には普通は好感が持たれる）ので、損にはならないと思います。ぜひ実行してください。

　最後に、もしかしたらこの記事を読んだ方とteratailでお会いすることがあるかもしれません。そのときは、よろしくおねがいします。

技術ブログを書く意味について考えてみる。250記事目なので。

2019-06-21T22:02:11+09:00

はじめに

　当ブログが250記事に達したので、振り返りを書こうと思いました。

　といっても別に書くこともそれほどないので、ついでにこれから技術ブログを書こうと思っている人向けに、「なんのために書くのか」「書く意味あるのか」みたいなふわふわした話についても少し触れようと思います。たまにはいいやと思って。

　なお、ここでいう「技術ブログ」は「主にプログラミングなどをテーマとした、ノウハウや問題解決手順などを中心に記載しているブログ」のことです。機械工学とかで書いても技術ブログは技術ブログに違いないと思うのですが、あまり見かけないし、私もそれについて語れる知識はないので除外します。

当ブログの歴史

2016年12月

　血迷って始める。

2017年 3月

　飽きて放置。

2018年 1月

　久しぶりにログインしたら想像よりはるかにPVが伸びていた（平日で200PVくらい）。
　書きたいネタがいくつか出てきたので、あと過去記事を「まとも」な内容に直す必要を感じたので、再開。

2018年 4月

　あと数倍程度アクセスが伸びれば、広告で小遣いが稼げることに気づく（この時点で平日一日700PV程度）。

2018年10～11月

　独自ドメインにしてグーグルの広告を首尾よく張り始める。

2018年12月～2019年2月

　大学生の卒研追い込み特需などでアクセスが最盛期をむかえる。最高で一日2900PVくらい。

2019年 3月～

　特需の終焉、グーグル検索のアルゴリズムアップデート、遅れてやってきた独自ドメイン化の副作用などによりPVが減少（平日一日1500PV前後）。
　やる気にむらが出てきて、一気にまとめて更新したり、数週間触らなかったりするようになる。

2019年 6月～

　なんだかんだで平日の平均PVが2000強くらいまで回復したので、もう少し頑張ることにした（というかする。19日にもなって書く6月最初の記事がこれという時点で、察してください）。

感想

　割と気まぐれと成り行きで更新しているブログなので、あまり大げさな感慨みたいなものはないのですが、とりあえずやっていてよかったと思います。ブログのネタにするべく色々なことに挑戦して勉強できた側面もあるし、大した額ではないとはいえ広告でお金が降ってくるのもありがたい話です。

　大半の記事は去年くらいに書いたのですが、今見返すと「なんでこんながむしゃらにやっていたんだろう」という感じもします。そのときはそうするのが楽しかったから、としか言いようがないのだと思いますが、へんな感じです。

技術ブログを書く意味

　積極的に肯定できない感触。

勉強になるとか転職活動に活かせるとかそういうメリットは結果論的に言えるだけで確実なことは言えないし、
やるならqiitaとかでやった方が孤独感がなくて楽しいはずだし*1、
広告？　そんな儲かる訳ないじゃん（趣味をやると費やした時間の1/3くらいのコストがお金として戻ってくるくらいの感覚）

　じゃあなんでやるのかという話になりますが、

プログラミングの神に「私の真実の教えを述べ伝えよ」と言われた

　これはあり得る。私は神に会ったことないけど。

世間に役立つ情報を提供しようという功名心、あるいは親切心

　長年やっている人はそういうところに帰着する可能性が高いと思います。

　功名心はわかりやすいと思いますが、親切心というのはべつに善行を積むのがどうこうという訳ではなく、普段からインターネットの情報に助けられている側面はたくさんあるので、フリーライドするのではなく多少は世界に貢献もしておこうということだと思います。そういう意味では、やりがいのある仕事をしている人はブログをやる可能性が低いかもしれません（仕事で世界に貢献できるので、わざわざインターネット社会に貢献しなくてもいい）。

　まあ、やる意味なんてよくわからないね、というのが率直なところです。タイトルを先に決めてから書いてるから、大した内容が思いつかなかった。ごめんなさい。

250記事書いてきて思う技術ブログをやる上で気をつけた方が良いこと

　このままだと内容が薄い記事になりそうだったので、一章追加しました。思いついた雑多なことを淡々と書いていきます。もし参考になれば幸いです。

読む人がいるか、読んだ人の役に立つのかも考える

　誰も読まない記事はあっても仕方ないし、読んでも役に立たない記事はゴミです。

　自分が詰まったところとか、自分にとってわかりづらかったところとかを書いて、同じようなことで問題を抱えている人がたどり着けるような検索性を確保しておく必要があります。記事のタイトル、本文、エラーの載せ方など、それなりにいろいろ気を配る必要があります（検索して1ページ目に出てくるサイトを手本にすればいい）。

どれぐらいニッチなテーマで書くのかを考える

　技術ブログに関しては、

需要がたくさんあって、だけどみんなが同じようなネタのページをたくさんを書いているテーマ
需要は少ないけど確実にあって、でもほとんど誰も書いていないテーマ

　の2つあると思っています。もちろん「需要がある割に書かれていないテーマ」は美味しいし「需要がないわりにたくさん書かれているテーマ」はまずい訳ですが、インターネットの無料記事といえども何らかの需給曲線があってある程度は均衡しているはずです。

　前者は初心者向けの入門サイトとか、著名言語・ライブラリの解説などが当てはまります。後者はニッチな言語だったりライブラリ、環境なんかに関する記事や、一つのエラーメッセージに絞って説明するといった記事です。

　で、みんなが書いているのと同じような内容を自分で書いても誰も幸せにならない可能性が高いので、普通は後者の方を狙った方が良いでしょう。

　ただし、以下の2点には注意してください。

需要がたくさんあるジャンルで書いて、SEOとか頑張ってgoogle検索で上位表示されるようになると、アクセスが山ほど来ます。

　適切な処置を取るとお金に変換できます（広告貼っても良いし、フリーランスの人なら営業に使っても良いし）。でも効率よくやるのは難しい。

ニッチすぎるジャンルだと心が折れたりします。残念ながら、書き手には「一週間に1PVしかアクセスを集めない記事」の価値は認識できない可能性が高いです。

　毎週1人を確実に救っているとしてもです。だから、割り切ってまとまった需要のある記事（毎日アクセスがある程度には）を書くのも大切です。

収益化するのかしないのかも（そういう邪念が頭をよぎってしまった人は）考える

　最初から収益度外視でやる人は考えなくて良いのですが、お金儲けを検討している人は気にしてください。

　まず、本業は絶対無理です*2。副業としても、割には合わないというか他に良い方法がある可能性が高いです。あくまで趣味をやると多少お金がもらえるという認識で取り組んでください。

　で、独自ドメインで運営すると広告を貼って収益を生めます。私ははてなブログでブログを作ってしまいましたが、あとあとのことを考えるとwordpressかなにかで作った方がメリットがたくさんあることでしょう。

　逆にはてなとかのサブドメイン（無料で作れるブログ）でやっている限り、広告を貼ってお金を稼ぐのはかなり難しいし（各ASPが独自ドメインでないと登録しづらい仕様なので）、qiitaで投稿するなら最初から諦めることになります。

　ただし、あまりにアクセスが少ないと収益を得ようと思っても旨味が少なすぎて無意味というか無理なので（ドメイン代＋サーバ代で赤字とか）、ある程度は考える必要があります。

　平均して1記事1日あたり10PVくらい稼げていれば、それなりに意味のある金額が生まれてくるかもしれません。200記事書けば、googleアドセンスでやるとして、毎月1万円くらい振り込まれてくることでしょう（ちなみに、googleアドセンスでは月間の儲けが8000円未満だと支払いが翌月に繰り越されます。翌月分と合わせても8000円未満なら合わせて翌々月に繰り越されます。だから、毎月支払いが生じるくらいを最低ラインとして考えないと、心が折れると思います）。

　広告についてはこちらも御覧ください。

プログラミングのブログにアドセンスを貼る話 - 静かなる名辞

飽きたり心が折れたりしたら放置する

　ぜったい更新しなきゃいけないというものではないので、やる気がなくなったらブログを残したまま放置しておくといいと思います。

　放置している間にPVが10倍くらいになることもたまにありますし、気が向いたらまた書けば良いです。そういうものです。

まとめ

　なんだかとりとめのない記事になってしまいましたが、これは突き詰めて言えば一般化して語れる「技術ブログを書く意味」なんてものはないのだ、ということを表しているように思います。だから、あなたが書きたければ書けばよいし、書きたくなければ書かなくてよいでしょう。

　でも、検索とかからこの記事にたどり着いた人は書こうと思っている可能性が高いはずなので、とりあえず気楽に立ち上げてみて様子を見れば良いと思います。飽きたらやめればいいわけですから。

　日本のIT技術力に対する日本語web圏の貢献は、当然ながら大きいものがあると思っています。日本語のインターネットで言及がない技術はなかなか広まりづらいのが実態ではないでしょうか。

　なので、みなさんも頑張ってください。応援しています。

*1:逆に無駄に人と絡むのが苦痛、という人にはブログが向いています

*2:試算しても、5000記事以上書けばなんとか食えるかな？　というレベルです。そんなに書ける技術力があるなら、普通に働けばいいのに

emacsでpythonを書くための設定　2019年版

2019-05-15T23:59:45+09:00

概要

　emacsライトユーザーの私が、新規環境にemacs25を導入してpythonを書くにあたってやった設定を書いておきます。目的はpythonを書くことだけです。

　前提として、以下の記事のように環境を作っています（読まなくてもなんとかなります）。

Ubuntu 18.04 LTSにvenvでミニマムなPython3.7仮想環境を構築 - 静かなる名辞

　あれこれやってもそこまで快適にならないので、flymakeとjediの設定をやっただけです。

インデントの設定

　以前のinit.elからそのまま引き継ぎましたが、要らんかも。

(add-hook 'python-mode-hook
  (lambda () (setq python-indent-offset 4)))

pyflakes・flymakeを入れる

　これは入れないとはかどらないので入れました。

　まずpython側で、仮想環境をactivateした状態でpyflakesを入れます。

$ pip install pyflakes

　flymakeはemacsにデフォルトで入っていますが、設定が要ります。

; これも昔どこかからコピペして使っている秘伝のタレ・・・
(setq flymake-allowed-file-name-masks '())
(add-hook 'find-file-hook 'flymake-find-file-hook)
(when (load "flymake" t)
  (defun flymake-pyflakes-init ()
    (let* ((temp-file (flymake-init-create-temp-buffer-copy
                       'flymake-create-temp-inplace))
           (local-file (file-relative-name
                        temp-file
                        (file-name-directory buffer-file-name))))
      (list "ほげほげ/bin/pyflakesの絶対パスを書く"  (list local-file))))
  (add-to-list 'flymake-allowed-file-name-masks
               '("\\.py\\'" flymake-pyflakes-init)))
; show message on mini-buffer
(defun flymake-show-help ()
  (when (get-char-property (point) 'flymake-overlay)
    (let ((help (get-char-property (point) 'help-echo)))
      (if help (message "%s" help)))))
(add-hook 'post-command-hook 'flymake-show-help)

; デフォルトだと赤波線になって見づらかったんで直した
; 参考：https://suer.hatenablog.com/entry/20090307/1236403449
(custom-set-faces
  '(flymake-errline 
     ((((class color)) 
       (:foreground "red" :bold t :underline t))))
  '(flymake-warnline 
     ((((class color)) 
       (:foreground "red" :bold t :underline t))))); :background "white")))))

　これだけで使えるはずです。.pyを開けば効くようになります。

jediを入れる

　コード補完のない環境で書いていた期間も割と長く、なければないでやれることは実感として知っていたので入れるかどうか迷いましたが、せっかくなので入れることにしました。

　一応公式のマニュアルの通りにやればだいたいうまく行くはずですが、一回失敗してel-getから導入しなおしたら治ったみたいなこともあったので、割とハマりやすいと思います。要注意です（つーか正直emacsが面倒くさい。pythonに比べれば）。

Jedi.el - Python auto-completion for Emacs — Emacs Jedi 0.2.0alpha2 documentation

　とりあえず、el-getが動くようにしておきましょう。

M-x el-get-install RET jedi RET

　これを打ったら（しばらく時間はかかるけど）そのうちぜんぶ導入終わったというメッセージがミニバッファに出てきますので、その後にinit.elを編集します。

(require 'jedi)
(add-hook 'python-mode-hook 'jedi:setup)
(setq jedi:complete-on-dot t)

　で、残念なことにjediはこれだけでは使えず、サーバなるものをpython側に入れないといけません。

　とりあえず、

$ pip install jedi

　するんですが（当然仮想環境で）、そもそもvenvで仮想環境を組んでいるのでどうしたものか（どう連携させるか）と考え込んでしまいました。virtualenvのやり方は調べると出てくるんですが、venvの場合はググってもよくわかりません。ドキュメントを読んでもさっぱり。

　思案した結果、「まあいいや、ダメ元でやろう」とpython仮想環境にvirtualenvを導入し（依存があるらしい。他にepcとかも要求されますが、jediと一緒に入ったような気もする）、仮想環境をactivateしたターミナルからemacsを立ち上げて、

M-x jedi:install-server RET

　してみました。そしたらぜんぶ良い感じにやってくれました。警戒して以下のような2行も書いてみたりしたのですが、けっきょくなくてもそこそこちゃんと動いたので消すかどうか迷い中。

(setq jedi:server-command
      (list "仮想環境をactivateした状態のwhich pythonの結果" "ほげほげ/lib/python3.7/site-packages/jediepcserver.pyみたいなの"))

　ただし、この2行がないと「仮想環境をactivateしたターミルから立ち上げないとちゃんと動かない」状態になります。それはそれで良いような気もするし、不便といえば不便。まあ、仕組みがよくわからないので触っていません。

まとめ

　終わってみれば大したことやってないのですが、正直けっこう苦労しました。

　ライトユーザーにはけっこう難しいですが、とにかく環境は揃ったのでがんばります。

UbuntuのFirefoxでWebページが英語で表示されるのを直す

2019-05-14T19:51:22+09:00

　UbuntuにはデフォルトでFirefoxが入っているので、特別な理由がなければこれを使う人が多いと思います。しかし、ネットを見ているとたまに英語で表示されてしまうページがあることに気づいたりします。

　これはFirefoxが「こいつは英語ユーザだ」という情報を渡してくれているからで、設定をいじれば簡単に変えられます。なお、先にUbuntu自体を日本語化する必要があるはずです（最初から日本語化されたもので入れた場合どうなるかは検証していません。この設定すら要らないかも）。

　方法

about:preferencesを開く
言語設定(O)...を開く
日本語を追加して最優先にする

　これだけです。

　だいぶ快適さが変わるので、やっておくといいと思います。

Ubuntu 18.04 LTSにvenvでミニマムなPython3.7仮想環境を構築

2019-05-05T00:33:11+09:00

概要

　まっさらなパソコンを開発環境として立ち上げることになり、表題の通りのことをやる必要があったのでまとめておきます。

　venvを使うつもりなので、作業量としては少ないはずです。

Python3.7の導入

　Ubuntu 18.04はデフォルトでpython2が導入されています。また、python3もありますが、バージョンは3.6です。

　3.7くらいを使いたいので、必要そうなものをすべて突っ込んでおきます。

　とりあえず以下をターミナルから実行（ぶっちゃけ必要なものの抜けとかはあるかもしれません。気づいたら反映します）。

$ sudo apt install tk-dev python3.7 python3.7-dev python3.7-tk python3.7-distutils python3.7-venv

　pipはget-pip.pyを落としてきて入れます。

$ curl -kL https://bootstrap.pypa.io/get-pip.py | sudo python3.7

　あと、wheelくらいは入れておくか。

$ sudo python3.7 -m pip install wheel

venvで仮想環境を構築

　なにも考えずにやるとトラブりやすいので、注意が必要です。とりあえずドキュメントの上半分くらいを全部見ておいてください。

venv --- 仮想環境の作成 — Python 3.7.3 ドキュメント

　コマンドとしては、これでやってみます。

$ mkdir ~/.venvs
$ python3.7 -m venv --copies  ~/.venvs/e371

　--copiesは強く推奨します（詳しく書きたくないけど、昔--symlinksにしてひどい目に遭いました）。お名前とかはお好みで。この記事ではこれで説明しますが、自分が決めた名前に合わせて書き換えてください。

　できていることを確認します。

$ source ~/.venvs/e371/bin/activate # (e371)のような文字列がプロンプトの先頭に付けばOK
$ python # python3.7が立ち上がればOK
$ pip show pip # さっきのインストール先のpipが見つかればOK
$ deactivate # 抜けられればOK

　そしたら.bashrcとかに以下を書きます。

alias ve37="source ~/.venvs/e371/bin/activate"

　保存した後にsource ~/.bashrcなどで読み込み、ve37コマンドで仮想環境が有効になれば問題ありません。

パッケージの導入

　各自行ってください。

まとめ

　venvで仮想環境を組んでみました。とても簡単で余計なツールなどを入れる必要もなく、だいたい無難に作れるのがいいところです。

もう参照の値渡しとは（無条件では）言わせない

2019-04-26T05:33:59+09:00

　注意：この記事では「参照の値渡し」がどういうものか、という点については説明しません。あくまで「参照の値渡し」を理解している方が対象読者です。

概要

　「参照の値渡し」という言葉がありますが、この言葉に関してはずっとモヤモヤ感を抱いていました。

　某所での議論を通じて、自分の考えがある程度まとまったので、記録しておきます。

　結論を先に要約すると、

「参照の値渡し」は無条件で使える言葉ではない。むしろこの言葉が独り歩きするのであれば、かなり問題があると考える
個人的には「共有渡し（call by sharing）」というネーミングを推す

　です。

　それぞれの理由について以下で述べます。

概要
「参照の値渡し」の問題点
共有渡しを推してみる
「参照の値渡し」を使っていいとき
まとめ
関連記事

「参照の値渡し」の問題点

　これはもともと「参照渡し」と「参照の値渡し」を混同して使うな！　という文脈で流行りだした言葉なのだと思うのですが、呼び方として「参照の値渡し」が良いとは思えない理由がたくさんあります。

　幾つか挙げます。

「参照の値」が定義されていない言語では使うべきではない

　「参照の値渡し」という言葉を好んで使う方は、おそらく「参照値」というものがあり、それを値渡ししている……というイメージを明確に持っています。というか、ぶっちゃけ「参照値＝メモリ番地」というイメージまではっきり持っているでしょう。

　ただし、メモリ番地どうこうというのは（相対的に見て）低水準の話です。よって、高級言語、特にLLのようなものでは、メモリ番地をプログラマから直接見る手段がないようなものが幾らでもあります。

　ワーストケースでは、言語仕様上で「参照の値」の定義が存在しておらず、実装に委ねられている、ということがあり得ます。そういうケースでは当然「参照の値渡し」とは書けない。そもそも内部的に「参照の値渡し」である保証すらない（同様の動作の実装方法は「参照の値渡し」に限らないかもしれない）。

　逆に、「参照の値」が定義されている言語ではこの問題はありません。たとえば、この話題に関して検索すると割と上の方に出てくるJavaに関する記事*1では、この点が明確です。

Java で「参照 (references)」といったら「参照値 (reference values)」という「値」のことです。
もう参照渡しとは言わせない - Qiita

　「参照の値渡し」に関して言えば、Javaはかなり有利な立ち位置にいると言えます。・・・というか、Javaの人たちは「参照の値渡し→参照値の値渡し→そもそも値渡しである」という話の方に向かってしまう場合があります（上の記事もそうです）。こうみなすと、プリミティブ型にしろ参照型にしろ値渡しという一つの方法で扱われると言えるのですっきりするのです。

　問題は、このように「値渡し」とみなしても、特に良いことのないばかりか悪いことまで出てくる言語もたくさんある、ということです。

　私の好きなpythonはその代表格で、

すべての変数は参照型、というかオブジェクト

　→「参照の値渡し」の部分は裏側に引っ込んでしまうので、あえて値渡しと呼称してもメリットはない

当たり前だが「参照値」なんて定義されていないし、プログラムから触る手段もない

　→実際は（少なくともCPythonでは）変数表のdictのvalueのポインタがそれに相当する。ただし、pythonのレイヤでは完全に見えない

　という事情があります。なので、pythonで「参照の値渡し」という言葉を使うインセンティブはありません。

「参照」と「値渡し」を理解していないとわからない

　「参照の値渡し」という言葉の残念な点は、それが「参照」と「値渡し」という概念に依存していることです。どちらも重要な概念で、しかも初心者のつまづきポイントです。

　つまり、「ヤツらに参照渡しと参照の値渡しを区別してほしい！」と思っている対象の「ヤツら」はそもそも「参照」も「値渡し」もちゃんと理解していない可能性が相応にある、ということです。ということは、「参照の値渡し」も理解してくれませんよね。

　また、一例として、これまでまったくプログラミングをやったことがない人とか、小学生とかにpythonを教えることを考えてみましょう。

　「参照」は理解してもらうしかないでしょう。すべての変数が参照型である以上、やむを得ません。でも、「値渡し」は上述した通りpythonのレイヤでは意識する必要がないので、教える必要はありません*2。しかし、「値渡し」を教えないと問題が発生します。「参照の値渡し」は引数の渡り方という超重要なトピックなので必ず教える必要があり、そのためには「値渡し」を教えないといけない・・・なにかが破綻しています。純粋に「参照の値渡し」という言葉が悪いのです。

そもそも言葉が抽象化されていない

　もっとも根本的な問題です。「参照の値渡し」は何も抽象化していない言葉です。「参照値が値渡しされる」と言っているのと同じですから。

　これは、「値渡し」と言う代わりに「実引数の値がコールスタックにpushされて・・・」と言うのと同じことです。単に動作を説明しているだけです。

　モジュール化して適切な名前を付け、ブラックボックスにして抽象化し、使いやすくする、というのはプログラミングにおいては極めて重要なことです。これを否定する人はいないでしょう。なのに、そういう大切な原則が守られていない言葉なのです。

　この言葉に対して私が個人的に抱いているモヤモヤ感も、けっきょくその辺りに起因する気がします。「名前」が「動作の説明」になってはいけません。

共有渡しを推してみる

　上で述べた通り、「参照の値渡し」はまずい点の多い言葉です。ただし、この言葉を使わないのであれば、代わる候補を探す必要があります。

　ということで、共有渡しを推します。

オブジェクトが（あるいはメモリ領域が）関数の間で共有される、という現象を捉える上で自然な言葉。
上述した「参照の値渡し」の問題がない。
英語圏ではもともと「call by sharing」が「参照の値渡し」とほぼ同じ意味で使われており、ならばこれの訳語を使うのが自然*3。

　特に異論はないと思います。「共有渡し」唯一の難点は日本語圏ではまったく流行っていないことですが、どうせ「参照の値渡し」もリアルでは通じないことの方が多いでしょうから、大きな問題ではないでしょう。

「参照の値渡し」を使っていいとき

　この記事でこれまで述べてきた通り、「参照の値渡し」という言葉にはかなり問題があります。なので、使用場面は本来は極限されるべきであると考えます。

参照値が定義されている言語で、
共有渡しより通じやすい可能性があり、
共有渡しより文脈上適当と考えられ、
その他の他の候補と比べて適切であると認められる場合*4

　上で挙げたJavaの例などはこれに当てはまる可能性があります。ただし、この場合も、「（一般名詞の）『参照の値渡し』と呼ばれる動作です」と言うよりは、「参照値が値渡しされます」と説明的に書いた方がはるかに親切でわかりやすいことに留意してください。

　つまり、理想論を言えば使途はかなり限定されるべきであろう（＝ほぼ使われるべきではない）、ということです。

　ただし純粋に呼び方の問題でしかないので、理想論を押し通したところで、得られるメリットはほとんどありません。それが最大の難点です。「まあ細かい齟齬はあるかもしれないけど、『参照の値渡し』でも別にいいんじゃない？」と言われたら何も言い返せません。正しくはないと思うけど、自分の思う正しさを押し付ける蛮勇を振るうのは大変です。ぶっちゃけいまいち積極的になれません（という気分がタイトルにもにじみ出ているのを感じ取っていただければ）。

　この記事を読んだ上で、いろいろな理由で「それでも私は『参照の値渡し』と呼ぶ」と決意する方がいれば、私から言うことは特にありません。あくまでもこれは消極的な提言であるとご理解ください。できれば共有渡し派が増えてくれると嬉しいのですが・・・

　けっきょく、この記事にしてもこういう思いを共有してくれる人に向けて書いているだけなのです。（なんつーオチだ）

まとめ

　「参照の値渡し」という言葉は考えれば考えるほどケチがつけられるので、やっぱり問題含みだと思う。

　（昔書いたものなので、今見ると拙い部分もあります。この記事のアップに伴って多少修正しましたが、私自身100%内容に満足している訳ではないことはご理解ください。）
共有渡しと参照の値渡しと - 静かなる名辞

*1:タイトルのパクり元・・・

*2:もちろんプログラミングを続けるのであれば、いずれ理解する必要が生じるでしょうけど

*3:callとpassは英語でもどちらでも良いものらしいので、問題にはなりません

*4:たとえば「ポインタ渡し」や「アドレス渡し」という言葉もあり、Cであればこちらを使った方が良いと思われます

はてなブログの独自ドメイン化でカバレッジが切り替わらないときの対処

2019-04-16T17:04:42+09:00

はじめに

　去年の秋頃、このブログを独自ドメイン化しましたが、今年に入ってもSearch Console上で古いサイトのインデックス・カバレッジが大量（数百件とか）に残ったままでした。

　思いついた方法を試したところ、さほど重要でないページ数件*1を残してカバレッジをすべて新URLに移動できました。

前提

　サイトの移転に際して、googleは以下の手順を踏むことを推奨しています。

サイトを移転する
0.サイト移転に関する基本情報を確認します。手順の概要とユーザーや掲載順位に与える影響について確認しておきます。HTTP から HTTPS へ移転する場合は、HTTPS に関するおすすめの方法を確認してください。
1.新しいサイトを準備して、十分にテストします。
2.現在の URL から対応する新しい形式への URL マッピングを準備します。
3.元の URL から新しい URL にリダイレクトするようサーバーを設定して、サイト移転を開始します。
4.元の URL と新しい URL 両方のトラフィックを観察します。
概要: URL の変更を伴うサイト移転 - Search Console ヘルプ

　これだけだとはてなブログProの契約でやってくれる移転処置とSearch Consoleから行う手続きだけでぱっと見大丈夫なのですが、ヘルプページをよく読み込んだ結果、以下の記述を発見しました。

移転先のサイトについては、元の URL と新しい URL を含む、事前に用意した 2 つのサイトマップを送信します。このようにすると、Google のクローラが元の URL から新しい URL へのリダイレクトを検出しやすくなり、サイトの移転がスムーズに進むようになります。
3. サイト移転を開始する - Search Console ヘルプ

　あー、元のURLと新しいURLを含んだサイトマップ？　そんなものが必要なんですね。

　しばらく考え込んだ結果、「googleのクローラが旧URLのクロールを試みる→301リダイレクトを検出→インデックスを切り替える」という流れで処理されるのだろう、と察しました。

　移転後、旧URLへのクロールは一日10未満という数字が続いていました。毎日10ページ処理してくれればそれでもいずれ切り替わることが期待されますが、外部リンクから来ているクローラだったりすると同じページしかクロールしてくれない訳で、クロールされなかったページは切り替わらないわな・・・。

対処

　はてなブログではサイトマップを編集できません（重要）。また、なぜか不具合があり、そもそも通常の状態でもいまいち正常に機能していなかったりする（googleがうまく読み込んでくれない）のがはてなのサイトマップです。改善してほしいのですが。

　サイトマップを頼るわけには行かないので、他の方法で旧URLをクロールさせます。理屈の上ではどうやってもいいはずです。

方法1：Fetch as Googleを使う

　Fetch as Googleを使って旧URLにクローラを巡回させます。・・・と書いておいて恐縮ですが、Fetch as GoogleというツールはSearch Consoleのバージョンアップに従って消滅しています。今はURL検査ツールというもので代替できます。

　とにかく、これらを使えば任意のページをクロールさせる（厳密にはクロールしてくれ、とお願いする）ことが可能です。ということで、何ページか送信してみたところ、それなりに効果があるような雰囲気を感じました。

　ただ、何百件もちまちま送信するのは大変ですし、やりすぎると自動操作を疑われるのか、画面上で操作できなくなる（やろうとしてもエラーになる）問題があります。数件だけ残ってしまったというのならともかく、普通の状況では使いづらいかと。

方法2：旧URLのカバレッジで表示されるページすべてへのリンクをサイト内に張る

　googleのクローラーはリンクを辿ってくれますから、理屈の上ではクロールしてほしいURLへのリンクを張ったページを作ってそのページをクロールさせれば、リンク先も見てくれます。

　ただし、この方法は若干ハイリスクです。リンクだけ載せまくったページなんて作ったらスパム認定されかねません。更に、このブログではGoogle Adsenseも使ってしまっているため、そちらの規約との兼ね合いも考慮する必要があります。

　・・・ということで、プロフィールページの下部に載せておきました。他にコンテンツのあるページならなんとか許してもらえるでしょう。

　やり方としては、まずSearch Consoleで旧URLのインデックス・カバレッジを開き、有効なURL一覧をダウンロードします。

ダウンロードボタンは右の下矢印

　csvで落とせるので、適当にいじってwebリンクになるようにします。私はリンクテキストをURLとしたaタグに変換したりするスクリプトを書きました（3行くらい。URLをそのまま貼ってもだいたいリンクが自動挿入されるのだが、一部パラメータなどがうまく認識されない）。できたらそのまま、好きなページに貼り付けます。

　この方法を取ったところ、次の日くらいにSearch Console上のクロールの統計情報で旧URLが猛烈にクロールされていることが確認でき、数日後には旧URLのサイトで登録されていたページが新URLのカバレッジに移動しました。成功です。

　ちなみに、プロフィールページ下部のリンクは、その後一週間ほど様子を見たあと削除しました。

懸念

　Search Console上ではすでにほとんどのページが移転できているのですが、なぜか旧URLに一定の検索流入が残っています。google検索で適当なキーワードを入れて確認した感じ、一部のページは旧URLのまま表示されてしまっているようです。

　これがキャッシュなどが一時的に残っていることによる効果なのか、変則的なことをしたせいで問題が発生しているのかは不明。

　ちなみに、これをやった直後は検索流入が1割ほど減りました。回復傾向にありますが、元の水準まで回復するかはなんとも言えない状況です。

　また、それなりのリスクもあり、上手くいく保証もないので、この記事を読んだ方は安易に試さないでください。旧URLのままでも実害は少ないですし、しばらく待てば自然に切り替わる可能性もあります。ただ、数ヶ月待っても駄目なときはこれを試す価値はあるかもしれません。

まとめ

　この方法で私のサイトの場合はうまくいきました、という報告です。一般的に使えるテクニックかどうかはまた別だと思いますが、１つの事例として参考にしてください。

追記

　切り替わらないページが多いため、旧サイトの「除外」に含まれる「クロール済み - インデックス未登録」など他の項目も載せたところ、多くのページの検索表示が新URLに切り替わりました（まだカバレッジレポートには反映されていません。3週間も止まったままなのです・・・）。

　カバレッジの表示件数と実際に有効なページ数は一致しないケースがあるようです。「ページにリダイレクトがあります」以外は疑った方が良いでしょう。

追記2

　その後経過を観察して何度か同様の措置を行い、結果的にはほぼすべてのページのインデックスを切り替えることができました（一部ゴミみたいな自動ページが旧ドメインのままだが、実害もないので無視）。

　ただし、この方法はあまりおすすめできない面があります。googleのペナルティを受ける確率が0ではないこと、新ドメインにカバレッジが切り替わっても検索順位の低下をもたらすだけで、あまり短期的なメリットがないからです（ただし新ドメインのドメインパワー向上にはつながるので、長い目で見ればメリットはあるかもしれない）。自然に切り替わるのを待った方が良いかもしれません。

*1:なぜ残ったのかは不明だが、実害もないので放置

TechAcademyのその後

2019-04-15T14:59:20+09:00

はじめに

　以前このような記事を書きました。

TechAcademyがteratailの質問・回答を盗用していた件 - 静かなる名辞
 TechAcademy盗用事件公式発表と深まる疑念 - 静かなる名辞

　TechAcademyに問い合わせたところまでで終わっていましたが、その後すこし私生活がバタバタしていたので、ブログを更新する暇がありませんでした。少し落ち着いてきたので、その後の流れをまとめます。

　まあ、動きらしい動きはないんですが・・・。

メール

　TechAcademyが「お知らせ」を出した後、私は彼らに対してメールによる問い合わせを行いました。先の記事にも書きましたが、再掲します（下に要約を載せるので読まなくて構いません）。

キラメックス株式会社様
貴社のオウンドメディアに対して、指摘のブログ記事を投稿したはやたかという者です。差し出し元の証明のため、このメールの文面は送信と同時に私のブログにて公開しますので、ご確認ください。
https://www.haya-programming.com/
今回の騒動を受けて、貴社の行った発表（https://www.kiramex.com/news/info/2019/5c98d89a6d027a17770002ea/）を拝見させていただきました。残念ながらこちらの内容は、少なくとも私にとっては不満の残るものでした。この発表を読んだ多くのteratailユーザ、貴社サービス利用者も同じ思いを抱いていると確信しています。よって、以下の問い合わせに応じていただきたく思います。
まず、以下の疑問にお答えください。
・TechAcademyマガジンの盗用疑惑は数ヶ月前からインターネット上で囁かれており、その度に記事削除の対応が行われていた。より早い段階から把握していた社員もいたはずであり、どうしてこれほど対応が遅れたのか。
・そもそも（仮に盗用がなかったとしても）「質問の存在を捏造して掲載する」という行為自体がTechAcademyマガジンのユーザ・読者を裏切る行為である。この点については社内でどれだけの人間が認識していたのか。問題とは思わなかったのか。
また、次のような要望があります。これについてはTechAcademyのサービスに関わる問題なので、ユーザではない私から申し上げるのも恐縮だと思いますが、あえて貴社のユーザを代弁する形で書かせていただきます。
上でも述べましたが、今回の件については、「そもそも実際に寄せられたものではない架空の質問と回答を創作し、実際にTechAcademyに対して寄せられた質問であると偽って掲載し、企業の宣伝等に用いるという行為自体に深刻な倫理的・コンプライアンス的な問題がある」と考えています。貴社の発表では、これについてどう考えているのかが読み取れませんでした。
また、キラメックス株式会社のお知らせページでの公表は、必ずしも多くの貴社サービスのユーザに触れるものではありません。しかし、貴社の行われた行為はそれらのユーザを裏切ったものであり、自社のユーザに対して謝罪する姿勢がなければ、このことを知ったユーザは「TechAcademyは信用できるサービスではない」という印象を抱くでしょう。
よって、以下の2点について要望します。
・まず「架空の質問・回答を『実際に寄せられた』ものとして掲載したこと」について立場をはっきりさせるような声明を出すこと。
・TechAcademyのページやTechAcademyマガジンのページ、SNS等にも声明を出し、今回の件について周知を図るとともに、謝罪する姿勢を示すこと。
何卒よろしくおねがいします。

　要約すると、まず

発表しなかった範囲で確実に対応を行っていた件
そもそもユーザから質問があったという事実から捏造してた件

　についての経緯と責任の所在を明示するよう求め、

捏造の件についても声明を出すこと
会社サイト以外の多くのユーザが閲覧するサイト（TechAcademyやTechAcademyマガジン、SNS等）での周知

　を要望しました。

　2019/03/26にメールを送りましたが、現時点で返信はなく、要望が聞き入れられた形跡もないため、スルーされた形です。

　少し言い訳させてもらうと、これはいずれもタダでは済まない痛みを伴う要望であり（外部に対して責任を示すこと、売上に直結するような周知を行うこと）、聞き入れられるかどうかはメールを出した時点でも、楽観的に見て五分五分くらいだと考えていました。スルーされたことに驚きはありませんが、少し悲しいと言えば悲しいところです。

　＠TechAcademy社員の皆さん　もし見ていたら、今からでも良いのでメールに返信して、要望も可能な範囲でいいので検討してください。よろしくおねがいします。

キラメックスの「お知らせ」第二弾

　キラメックスは自社サイトで、ひっそりとお知らせ第二弾を発表しています。

弊社オウンドメディアの運営体制に関して（2019年4月9日） | キラメックス株式会社

　なぜ出したのかは不明。私がああいうメールを送って、確実に把握しているであろう状況でも、頑なに企業サイトにだけ掲載する根性って・・・

　「今後の対応方針等」と「既存コンテンツへの校閲等」の2つが主な内容となっています。まあ、かいつまんで見ていきます。前文等は必要ないので省略しています。

1．今後の対応方針等
(1) 今後の対応方針
（内容が少ないので省略）
(2) 今後問題を発生させない仕組み作り
今回のような問題を今後発生させないために、運営体制を強化し、事前に問題が発生することを防ぐような仕組みを構築し、強化して参ります。具体的には、以下のような対応を実施して参ります。
・記事製作ガイドラインの改訂
・コンテンツ作成フローの見直し
・コンテンツ作成フローにおける編集員による複数名での記事内容確認体制の徹底
・情報流用をチェックする第三者事業者提供のツール導入を含めた、第三者によるコンテンツの確認体制の新設
・運営体制強化のためのオウンドメディア編集者増員
・コンテンツ管理およびチェックプロセスの強化
・社内規程の改訂による厳罰化
(3) 情報取り扱いリテラシーに関する意識改革
今後、今回のような問題を発生させないためには、問題の発生を防ぐ仕組み作りとともに、実際に運営に携わる弊社社員および関係者の意識改革が不可欠だと考えております。そのため、弊社社員および協業する弊社関係者に対し、情報取り扱いリテラシー教育を実施し、それを徹底して参ります。
また、弊社におけるガイドラインおよびポリシーが適切に遵守されているかどうかをチェックすべく、コンテンツに関わる社員および関係者に対し、弊社ガイドラインおよびポリシーに対する理解度チェックを行って参ります。

　そのまま読んで面白いものはありません。ぱっと見ありきたりな内容です。まあ、こういうのは言うは易しの典型なので、頑張って実行してくださいとしか思えません。

　そう思いつつ、「『編集者増員』ってこれまでどれだけ貧弱な体制で編集やってたんねん」と思って「techacademyマガジン編集」とか何気なくgoogle先生に聞いてみたら、3番目くらいに答えが出てきてしまいました。

元受講生から、新卒第1号入社。TechAcademyマガジン編集長の小嶋が3年目を前に思うこと KiRAMEX TALK｜小嶋大貴 | キラメックス株式会社

　1992年生の新卒を入社後いきなり編集長にしてるぅ

　たぶん、実質的に、すべて彼一人の実績（やらかし）の可能性が高い、ってことですよね。なんとなくすべてを理解してしまったような気持ちになりました。

　ちょっとブログが書けたりする若者を新卒採用で捕まえてきて、一人でオウンドメディア運営を任せる構図かぁ・・・

　念のために書いておきますが、編集長の彼個人を責める意図は私にはまったくありません。個人の責任に帰してしまえば、集団の非を問えなくなります。あくまでも会社組織の責任であり、こういう人事采配を行ったキラメックスに対しては憤りを感じますが、編集長個人はきっと限られたリソースと能力の中で善戦したのでしょう。まだ将来のある方ですし、今回の件を反省し、今後は健全なWebメディアの運営に尽力していただければと思います。

　とても「駄目な例」なので、メディア運営に携わっている皆さんは反面教師にすると良いと思います。会社の看板です。イメージ下がるような看板は出さない方がマシです。

　この件はこれ以上特に言うことはありませんが、他にもキラメックスは既存コンテンツへのチェックを行ったとしています。

2．既存コンテンツに対する校閲等
今回の問題を受けまして、弊社において、2,000記事以上の弊社既存コンテンツ全てに対する再校閲を実施いたしました。また、流用記事を作成した外部エンジニアおよび外部ライターに対しては、2019年3月25日付けのお知らせのとおり、既に業務依頼を停止いたしました。

　ほーん。

　たとえばこれ。

Pythonのimportメソッドの使い方【初心者向け】 | TechAcademyマガジン
 （どうせ修正されるので魚拓）

　import「文」でしょ？

7.11. import 文 | 7. 単純文 (simple statement) — Python 3.7.3 ドキュメント

　技術記事の校閲なんて、技術のわかる人がチェックしないと駄目です。理系の専門書を出す出版社では、そのためにわざわざ理工系出身者を採用していたりするくらいです。

　こういうのはまともな編集者（それこそトップクラスのエンジニアとして働ける実力のある人間）を置かないとどうにもならないと思います。そういう人はメンターには結構いても、正社員にはほとんどいないという構図なのでしょう。某侍とかと同じ体質です。

　ほんと、こういうのなんとかしろよ、と思うのですが。初心者が困惑するような記事をネットにばらまくのは害悪です。せめてコメント欄を開けておいて、第三者が気軽に指摘してくれるような仕組みにしないと。

本ブログの今後の対応

　私は今回の件については直接の利害関係は一切ないただの第三者なのですが、なにしろこれを含めて3記事も書いてしまったので、何も言わずに平常運転に戻すのもなんだか変な感じがします。そこで、ここで今後の対応について示しておきます。

今後この件についての記事は書きません。

　100%ないとは言い切れませんが、たぶん書かないと思います。

　もし何かあれば、必要と認められる範囲で既存記事を加筆します。ただし、匿名掲示板やSNS等はすでにリアルタイムでヲチしていないため、はっきり言って状況を把握しきれません。最新情報等は期待しないでください。

ヘッダでの周知は継続します。

　この事件が発生して以来、本ブログのヘッダ部に関連記事へのリンクを貼っていますが、これは無期限で継続します。ただし、「TechAcademyがマガジン・SNS等での周知を行えば」解除します。また、運営上の都合でサイドバー等他の場所に移動する可能性も皆無ではありませんが、少なくとも目立つ位置には貼り続ける予定です。

　本ブログには初心者の方もたくさん来られていて、プログラミングスクールの受講を考えている方、すでに受講されている方もいると思います。私にネットのIT界隈を大炎上させるような影響力はありませんが、せめて見に来てくれた方に対しては判断材料を提供しよう、という考えです。

まとめ

　今後、TechAcademyが健全に運営され、teratailユーザのような第三者、そして受講者の方々に不利益がないことを願います。

TechAcademy盗用事件　公式発表と深まる疑念

2019-03-26T09:34:33+09:00

これまでの経緯

　TechAcademyマガジンで、teratailの質問・回答の盗用疑惑があり、前回の記事で取り上げました。

TechAcademyがteratailの質問・回答を盗用していた件 - 静かなる名辞

　私が書いたその記事はTwitterやはてブ経由で拡散して多くの方に見ていただき、TechAcademyマガジンの運営上の問題が多くのインターネットユーザに共有されました。それを受けてか、昨日teratail運営、TechAcademy運営からそれぞれ公式のアナウンスがありました。

【ご報告】teratailのQ&Aと類似したコンテンツが他メディアに掲載されていた件に関して、先方よりリリースが出されました。https://t.co/wBe9wWjlpi
— teratail【テラテイル】 (@teratail) 2019年3月25日

弊社運営のオウンドメディアへのご指摘について（2019年3月25日） | キラメックス株式会社

　TechAcademyの一方的な盗用であったことが確認された形です。とはいえ、これですべて腑に落ちたかというと幾つか疑念が残ってしまったので、それについて書いておきます。

teratail運営側の説明

　teratail運営側の説明している内容をまとめると、

TechAcademy運営が勝手にやったことである。

　という一点です。また、ユーザの投稿を活用する際は適切な周知を行う（teratail運営承認のもとで今回のように勝手に不当利用されることはないので安心してほしい）としています。

なおteratailがこれまで他メディアに対して、コンテンツ使用に関するライセンス等を行なったことはありません。
今後、仮にユーザー様の投稿を活用した活動を行う場合でも、ユーザー様が認識できる方法で事前にお知らせをいたします。

　よってteratail運営はこの件に関しては100%白であることが確定しました。

　一方、teratail運営は、

teratailの保有する権利の侵害に対する、損害賠償請求などを含めた対応
今後はこれ以上追求しないのか

　といった点については明らかにしていません。まだ検討中という可能性もありますし、大きな実害を被った訳ではないこと、運営会社同士には（TechAcademyの受講生の就職を斡旋するといった）ある程度の友好関係があることを考えると、これ以上ことを荒立てるつもりはなく、穏便に済ませるつもりなのかもしれません。まあ、これらに関しては運営会社同士で勝手にやってくれれば良いので、私からとやかく言うことはありません。

　ということで、とりあえず私個人としてはteratailを当分は使い続けるつもりです。運営側に黒い要素がなくて少しだけ安心しました。

TechAcademy運営側の説明

　TechAcademyを運営するキラメックス株式会社は、会社のホームページ上のお知らせで声明を発表しました。

弊社運営のオウンドメディアへのご指摘について（2019年3月25日） | キラメックス株式会社

　基本的に盗用した事実は認めているのですが、読んでみた感想はというと、頷ける部分もあるものの全体としては「んんん？」です。死体蹴りっぽくなっちゃいますが、いちいちツッコミを入れてみます。

『■ご指摘に対する時系列の対応について』について

　キラメックス株式会社の発表によると、今回の件の「時系列の対応」は以下の通りです。彼らの発表を元に一部要約・編集して掲載します。

・2019年3月20日23時
　はてなブログ「saitouena」にて質問と回答の盗用に関する上記のご指摘が公開される*1
・2019年3月20日23時
　ブログの内容をもとに該当記事の精査を行うため、ご指摘の記事を含めて35件の一時削除を実施
・2019年3月22日9時
　はてなブログ「静かなる名辞」にて質問と回答の盗用に関するご指摘が公開される*2
・2019年3月22日18時
　代表取締役社長を筆頭に調査チームを組成し、過去の記事について精査。問題のある記事を一斉削除。
（以下は元の記述を踏まえて私が付け加えたものです）
・日時不明（22日か25日）
　teratail運営に対して直接伺い謝罪。
・2019年3月25日
　Webサイトに報告*3

　私のブログをきっかけに調査チームを立ち上げたのですか・・・ちなみに3月22日時点では件の記事はせいぜい150PV程度しか集めていません（土日に伸びて現在は累計2500PVほどです）。金曜日中にtwitterで投稿された方はいましたが（ブログ読者の方や私の知り合いが主）、それを察知したとしたら恐るべきエゴサ力とでも言うべきでしょうか。

　ということは置いておいて、この時系列表を見て浮かぶ疑問点は以下の3つです。

2019年3月20日以前にもSNSや匿名掲示板で散発的に話題にされていて、記事削除の対応もsaitouenaさんが取り上げる以前に行われていた。少なくとも数ヶ月前から、一部の記事に問題があることを把握している社員（ないし少なくとも記事を削除する権限のある人間）がいたことになる。それについての説明はなし。
「精査を行うために一時削除」とあるが、もみ消しと捉えられても仕方ないのでは。
それでも精査していたとしたら、2019年3月20日にsaitouenaさんが言及してから、22日に私が言及するまで丸一日以上あったのに、何をしていたのか。見れば一発で分かる問題であり、最速で動けば21日に調査チーム結成、当日中に状況把握と記事削除を済ませ、22日にはteratail運営への謝罪と公式発表というスケジュールでやれたはず。

　はっきり言って、21日頃まではもみ消す方向で動いていたけど、（私のブログが中途半端にバズったせいもあって）もみ消しきれないと悟った結果が22日以降の動きなのでは？　というのが「時系列の対応」を見て思った率直な感想です。あるいは、権限のある上層部が状況を把握していなかったということかもしれませんが。

　グダグダ書いていて自分でも嫌になってきましたが、こんな感じであげつらっていくつもりです。

『■今回の問題とその原因』について

　TechAcademy運営側は、以下のように書いています。長いですが全文引用します（読み飛ばしてください）。

■今回の問題とその原因
TechAcademyマガジンでは2018年4月から2018年7月まで、TechAcademyマガジンの読者などからプログラミングを学習する上でぶつかりやすい疑問や質問を集め、それに対して現役エンジニアが回答するコンテンツ「実際のエンジニアが回答するシリーズ」を公開していました。
このコンテンツ制作作業の中で、一部記事では学習者の声から疑問を持ちやすいキーワードを社内編集部が設定し、それに関連した質問案作成を外部ライターに依頼、それを社内の編集チームが確認のうえで、ライターがコンテンツ投稿まで行っていました。また、回答に関しては、現役エンジニアが質問をピックアップし、記事の投稿を行っていました。
そして、この時期公開したコンテンツのなかに、今回問題となりましたteratailの内容がそのまま使用されていた記事がありました。
この問題が起きた原因として、協力を依頼した外部のライター・エンジニアの一部メンバーに著作権などに関する意識が不十分な方がいたこと、外部の方に執筆頂いたTechAcademyマガジンの記事は全て弊社で編集を行なっておりましたが、それらのコンテンツに対する著作権保護に準じた弊社内での記事の流用チェックが十分に機能していなかったことが挙げられます。

　(゜ロ゜)。。。

　5回くらい読み直して、ようやく何を言っているのかおぼろげにわかってきました。わかりやすくイラストで説明します。

　まず、外面的な記事の体裁はこうでした。

外面的な体裁

　この通りやっていれば、何ら問題なかったでしょう。でも実際はこうでした。

実際

　・・・これ現実的ですかね？　質問と回答は独立に作られているということらしいですが。。。

　どちらも同じteratailのページからコピペされているケースも多々あった訳で、単純に一人でぜんぶコピペしたんじゃ？　という気がします。まあ、この通りだとしたら、

質問者役コピペライター：「コピペで質問作ったろ！」
回答者役コピペライター：「おっ、この質問teratailからのコピペだ！　回答もコピペしたろ！」

　という素晴らしい共同作業があった訳ですね。

　あと、さらっと流していますが、

一部記事では学習者の声から疑問を持ちやすいキーワードを社内編集部が設定し、それに関連した質問案作成を外部ライターに依頼

　とありますが、そうやって作成した記事を「現役エンジニアが回答」と偽って発表している時点で言い逃れできませんから。それに、実際にTechAcademyに寄せられた質問なんてそもそもあったのでしょうか？　現時点でTechAcademyマガジンのサイトで「現役エンジニアが回答」のようなキーワードで検索をかけてみたら1記事もヒットしなかったので（リンクテキスト等除く）、この形式の記事はすべて削除されてしまった訳です。そもそもすべてが「なんちゃって寄せられた質問」だったのでは？　という疑惑があります。

　まあ、どうやって記事を作っていたのかは正直どうでも良いです。それよりこの節の全体に言えますが、TechAcademy側がどこまでコピペに関与したのか、まったく把握していなかったのかある程度はわかっていたのか、どのタイミングで把握してどう動いたのか、等、肝心な部分の説明がぼかされています。文字通り受け取るなら外部の人間が勝手にやって20日～22日に把握したたという主張のようですが、信じがたい点がいくつもあります。そのせいで、納得の行く説明にはなっていない感があります。

　個人的には、本当に外部の人が勝手にやらかしてチェックをすり抜けてしまったのなら、もっとスムーズに対応できたでしょ、という気がしています。数ヶ月前から散発的に話題になっていた訳ですし、運営はそれを把握していた*4でしょうから、その時点で動くべきだった。動けなかったのは、よほど重大な責任が内部にあったのでは？　という気しかしません。

『■今後の対策』について

　キラメックスは以下のように述べています。

他サイトなどからの著作物の流用がないように、下記対策を徹底し、誠意をもって運営に努めて参ります。
1）協業する外部ライター・エンジニアへの情報取り扱いリテラシー教育の徹底
2）運営体制強化のための社内のTechAcademyマガジンの編集者増員
3）情報流用をチェックする第三者事業者提供のツール導入
4）当該の流用を行った外部エンジニア・ライターへの業務依頼の停止

　いや、上でも書いたけど「現役エンジニアが回答」と偽って発表している時点で、単純な著作権侵害の問題ではありませんからね？

　外部に責任を押し付けたいようですが、運営体質そのものを変えないと駄目だと思う。

そもそも論

　この発表は、「キラメックス株式会社のお知らせページ」に掲載すべきものだったのでしょうか？

　はっきり言って、誰が読むんだという感じです。「祭り」に乗っかった人たちに読んでもらえれば良く、できるだけこの事実が広がらないようにしようという魂胆が透けて見えます。同様の声明はTechAcademyのトップページやTechAcademyマガジンには今の所掲載されていません。Facebook, Twitter等のSNSでの発信もなし。

　もちろんteratailのユーザや運営に対する謝罪も大切だとは思いますが、それよりも謝罪しないといけないのは、彼らが裏切ったTechAcademyマガジンの読者、TechAcademyのユーザに対してではないでしょうか。私から言うのはどうなのかという面もありますが、はっきり言ってどうかと思います。

ひどかったので問い合わせる

　ここまで読んでいただいた方には理解していただけたと思いますが、キラメックス株式会社の対応は少なくとも私にとって不満の残るものでした。ということで、以下の文面でキラメックス株式会社に対して問い合わせを行いました。

キラメックス株式会社様
貴社のオウンドメディアに対して、指摘のブログ記事を投稿したはやたかという者です。差し出し元の証明のため、このメールの文面は送信と同時に私のブログにて公開しますので、ご確認ください。
https://www.haya-programming.com/
今回の騒動を受けて、貴社の行った発表（https://www.kiramex.com/news/info/2019/5c98d89a6d027a17770002ea/）を拝見させていただきました。残念ながらこちらの内容は、少なくとも私にとっては不満の残るものでした。この発表を読んだ多くのteratailユーザ、貴社サービス利用者も同じ思いを抱いていると確信しています。よって、以下の問い合わせに応じていただきたく思います。
まず、以下の疑問にお答えください。
・TechAcademyマガジンの盗用疑惑は数ヶ月前からインターネット上で囁かれており、その度に記事削除の対応が行われていた。より早い段階から把握していた社員もいたはずであり、どうしてこれほど対応が遅れたのか。
・そもそも（仮に盗用がなかったとしても）「質問の存在を捏造して掲載する」という行為自体がTechAcademyマガジンのユーザ・読者を裏切る行為である。この点については社内でどれだけの人間が認識していたのか。問題とは思わなかったのか。
また、次のような要望があります。これについてはTechAcademyのサービスに関わる問題なので、ユーザではない私から申し上げるのも恐縮だと思いますが、あえて貴社のユーザを代弁する形で書かせていただきます。
上でも述べましたが、今回の件については、「そもそも実際に寄せられたものではない架空の質問と回答を創作し、実際にTechAcademyに対して寄せられた質問であると偽って掲載し、企業の宣伝等に用いるという行為自体に深刻な倫理的・コンプライアンス的な問題がある」と考えています。貴社の発表では、これについてどう考えているのかが読み取れませんでした。
また、キラメックス株式会社のお知らせページでの公表は、必ずしも多くの貴社サービスのユーザに触れるものではありません。しかし、貴社の行われた行為はそれらのユーザを裏切ったものであり、自社のユーザに対して謝罪する姿勢がなければ、このことを知ったユーザは「TechAcademyは信用できるサービスではない」という印象を抱くでしょう。
よって、以下の2点について要望します。
・まず「架空の質問・回答を『実際に寄せられた』ものとして掲載したこと」について立場をはっきりさせるような声明を出すこと。
・TechAcademyのページやTechAcademyマガジンのページ、SNS等にも声明を出し、今回の件について周知を図るとともに、謝罪する姿勢を示すこと。
何卒よろしくおねがいします。

まとめ

　とりあえず進展はあったけど、まだ腑に落ちないという感じです。私としては、腑に落ちるまでやってくれ、と思います。

　とりあえず以上です。新たな動き等があればこの記事に追記していきます。

続報

　けっきょくもう1記事書きました。

TechAcademyのその後 - 静かなる名辞

*1:https://evalcat.hatenablog.com/entry/2019/03/20/234322

*2:https://www.haya-programming.com/entry/2019/03/22/092150

*3:https://www.kiramex.com/news/info/2019/5c98d89a6d027a17770002ea/

*4:話題に上がった記事を削除するといった動きはかなり以前からありました。たとえばhttps://medaka.5ch.net/test/read.cgi/prog/1549938681/611など

TechAcademyがteratailの質問・回答を盗用していた件

2019-03-22T09:21:50+09:00

編集履歴

2019/03/22 朝

　投稿。その後数回微調整。

2019/03/22 夜

　タイトルと内容を全面的に改稿。

現時点で確証がない部分について表現・内容を修正
情報を追加

2019/03/23 朝

追記

2019/03/25

teratailへの問い合わせ結果を掲載

　「ライセンスしていない」とのことです。

それに伴ってタイトルおよび内容を調整

2019/03/25　深夜

teratail運営とTechAcademy運営からそれぞれ公式のアナウンスがありました。

なおteratailがこれまで他メディアに対して、コンテンツ使用に関するライセンス等を行なったことはありません。
今後、仮にユーザー様の投稿を活用した活動を行う場合でも、ユーザー様が認識できる方法で事前にお知らせをいたします。
— teratail【テラテイル】 (@teratail) 2019年3月25日

弊社運営のオウンドメディアへのご指摘について（2019年3月25日） | キラメックス株式会社

　これらを踏まえた続報記事を公開しました。

TechAcademy盗用事件公式発表と深まる疑念 - 静かなる名辞

　また、この記事の内容は古い情報に準拠しています。いずれ更新していくと思いますが、現時点では手を付けられていません。最新の情報を知りたい方は、続報記事もあわせて御覧ください。

はじめに

　私はteratailというQAサイトで回答をしていて、pythonカテゴリ総合一位だったりします。あちこちのサイトを見ていたら、TechAcademyというプログラミングスクールのマガジンページがteratailの質問と回答を盗用しているかも？　という話を見つけました。図々しいと思いながらも情報をまとめておきますので、読者の皆さんはなにかの参考にでも役立ててください。

先人たちのまとめ

　こちらのブログ記事などが概要を掴むのに良いと思います。

techacademyがteratailの質問を転載して記事を作っている - saitouena

　5ちゃんねるのteratailヲチスレでも取り上げられているので（現在進行形）、とりあえずリンクを貼っておきます。

teratailもりあがっtail? 26問目

　要約すると、

「TechAcademyマガジン」というオウンドメディアで、主に「TechAcademyに実際に寄せられた質問に現役エンジニアのメンターが回答しました。」という体裁の記事にteratailからの転載と思われる投稿が多数（少なくとも2桁、下手したらそれ以上）ある。
有志の作成した「転載記事リスト」には特定のメンターの名前（複数人。実名なのかどうか、そもそも実在する人物なのかは不明）が多く上がる。
TechAcademy側は「Twitterや匿名掲示板などで取り上げられた」記事を削除して対応中。

　という感じです。

一例

　こんな感じです。この問題が盛り上がり始めた、最初期のツイートで取り上げられたものです。なお、TechAcademyの元記事は消えていたのでWeb魚拓です。

techacademyのこの記事、https://t.co/7iXdPqkAJD
teratailの質問・回答をまるまるパクッてる。https://t.co/ju0NI1oztG

パクリ側の方、日付は2017/8/11って書いてあるけど、作業ファイルの登録日付は2018年5月だし嘘だと分かる。
— kuracom (@kuracom) 2019年2月27日

【魚拓】curlコマンドをJavaScriptのAjaxで実行する方法とは【メンターが回答】 | TechAcademyマガジン
 jQuery - curlコマンドをjqueryのajaxで実行する方法｜teratail

　見ていただければわかる通り、出典として元の質問を示す訳でもなければ（まあ「TechAcademyに寄せられた」という体裁なので示せないのですが）、内容を書き換えて誤魔化すといった小手先の芸もありません。コードはもちろん、質問・回答の文言もほぼそのままコピペです。良識を疑うとかそれ以前に、「なんでこれで問題にならないと思ったの？」というのが率直な感想です。

　こういうのがン十件あり、深刻な事態を伺わせます。

法律上はどうなるのか

　ふと「teratailの規約が緩すぎて法律上何ら問題ない」ということになったら大変だと思い*1、teratailの規約を調べました。

第9条（権利帰属）
3.登録ユーザーは、投稿データについて、当社に対し、世界的、非独占的、無償、サブライセンス可能かつ譲渡可能な使用、複製、編集、改編、掲載、転載、公衆送信、上映、展示、提供、販売、譲渡、貸与、翻訳、翻案、配布などができる権利および二次的著作物に関する現著作権者の権利（著作権法２１条ないし２８条の権利をいい、商用利用を含む）に関するライセンスを付与します。
利用規約｜teratail（テラテイル）

　基本的には健全な内容でした。teratailのユーザはteratailの運営会社に対して諸権利をライセンスしている、という立場です。

　よって、

teratail運営がTechAcademy運営に対して、こういう使い方が可能になるライセンスを付与したのであればセーフ
それ以外は法的にアウト

　という状況であると考えられます。ユーザがライセンスを付与しているのはteratailの運営会社に対してであって、それに関係ない事例に対しては通常の場合と同じ扱いになるからです。

　なお、こういう使い方をされるのを承知でteratail運営がデータの権利を渡した確率は蓋然的には限りなく0に近いと考えられます。あまりにも酷い使われ方であり、これを承諾したのであればteratail運営の信用問題にも発展しかねません。・・・が、その可能性も皆無ではないため、初稿の時点でこの記事に多くあった「断定的な表現」は後から修正しています（2019/03/22夜時点*2 *3）。

　※この件についてteratailに対して問い合わせを行っていましたが、2019/03/25に返信があり、ライセンスは行っていないとのことでした。

　よって、TechAcademyが合法的（？）にライセンスを得て掲載していた可能性はなくなりました。

　また、「TechAcademyに実際に寄せられた質問に現役エンジニアのメンターが回答しました。」という記載は著作権以外の問題も発生させます。teratailの質問・回答をコピペしてつくったQ&A記事の質問が実際にTechAcademyに寄せられている訳はないので、実態より多くの質問が寄せられている、と誤認させていることになります。これは一種の誇大広告「みたいなもの」でしょう。「こんなに賑わっているプログラミングスクールなら安心して勉強できる」と思って入会する人がいれば詐欺「のようなもの」です。ただ、私に法律関連の知識はないので、これがどの程度深刻なものかは正直なところわかりません。あくまでも参考として書いておきます。

そもそもTechAcademyとは何ぞや

　プログラミングスクールです。「最短○○でエンジニアに！」のような広告などをよく目にすると思います。

　スクールとしての評判は、ググって出てくるページなどを読んでください。実際に自分が体験した訳でもありませんし、これ以上述べることはしません。

　また、ありがちなことですが、この運営会社は営業活動の一貫としてオウンドメディアを運営し、Web記事も発信しています。「スーツを着たイケメンのお兄さんと女子大生風の女の子のアイコンがセリフでしゃべるページ」と言えば、検索で引っかかった記憶がある方も大勢いると思います。

　で、こういう盗用？なんて真似をしている会社はどんなところなのでしょうか？　去年に大炎上した侍エンジニア塾の場合、元中の人によれば「設立が新しく、資本規模も小さい会社」であり、いろいろな杜撰さも同情に値するかどうかは別として「わからんではない」という面がありました。

古巣の侍エンジニア塾（株式会社侍）の炎上について思うこと【2018/10/23追記】 - INODEVLOG

　ということで、運営会社のページです。重要そうなところだけ抜粋しています。

会社名　キラメックス株式会社
事業内容　プログラミング教育事業
設立　2009年2月2日
資本金　4,800万円（資本準備金を含む）
親会社　ユナイテッド株式会社（東京証券取引所マザーズ市場）
運営会社 | TechAcademy [テックアカデミー]

　歴史はそれなり（10年）にあるようです。

　ふーん、マザーズ上場企業が親会社ですか。立派な会社なのかな？　と思ってしまいますが、どうやら完全に子会社化されたのは近年のようです。

ユナイテッド株式会社によるキラメックス株式会社の完全子会社化について（2016年2月3日） | キラメックス株式会社

　それ以前に資本関係があったのかどうかまでは調査不足で不明です。とはいえ、問題の記事は子会社化されてから出てきたものが多くを占める訳で、けっきょく「上場企業（の子会社）がこんな杜撰な真似をしている」という構図には変わりはありません。こういうのってコンプラ的に一発アウトだと思うんですが、どうなんでしょうね。

なぜ人は間違えるのか（なんでこんなことになってしまうのか）

　ここまでの説明でも、あまりにも酷い状況なのは皆さんにおわかりいただけたと思うのですが、「どうしてこんなことするの？」という疑問を持った方も大勢おられることでしょう。簡単にですが私が説明できる範囲で大雑把な背景を説明します（正確を心がけますが、憶測も含みます）。

　基本的に、まともな記事を供給する、というのはけっこうお金がかかります。「エンジニア」として食っていける実力のある人が一時間とか二時間かけて記事を書いたら、時給ン千円以上ですから相当なコストになります。ASCII.jpとかならそれでやっているかもしれませんが（まあ彼らも彼らで厳しいだろうけど）、ほとんどのところはコストを捻出できないでしょう。更に、オウンドメディアの場合は「安いコストで宣伝に寄与してくれればいい」程度に思われていて、それほど予算を割かれていないといった状況が容易に想像できます。

　なので、多くのIT系オウンドメディアは給料の安い自社社員（当然専門的な技術力はない）に書かせるか、クラウドソーシングなどで安く書いてくれる人を探して書かせるか、インターンにやらせるか、といった運営方法を取っていると思います。結果、qiitaの殴り書きよりひどいクオリティのオウンドメディア記事が量産されてしまう訳です。

　では、今回の件は、TechAcademyがクラウドソーシングとかで雇った人が暴走しちゃった？

　その可能性はほぼない、と個人的には考えます。普通、ライターにそこまでの裁量権はないからです。ああいう記事をライターの方が作ってしまうとしたら、「teratailの質問をTechAcademyに寄せられた質問として転載してほしい」という依頼を受けた、というケース以外まったく考えられません。

　頼まれもしないのにこっそりやってバレたら、次の仕事はなくなります。ヘタしたら「企業イメージを損なった」って訴えられかねない。

　だって、確実に真っ黒で法律違反な行為ですよ？　ライターの裁量でできる訳がない。

　また、「インターネットで囁かれ始めてからの対応が『記事の削除』だった」という話もあり、限りなくTechAcademy本体*4が黒と言う他ありません。

　ではどの辺まで黒いか？　以下はすべて憶測になりますが、常識的な遵法意識とリスク感覚を持つ（であろう）上位の経営陣が最初からすべて把握していた、というのは考えづらい状況です。どちらかといえば、担当者数名くらいが暴走してこうなったような気がします、というかそれくらいが自然に思えます。

　いずれにせよまともな会社のやることとしては悪質すぎるし、企業イメージへの悪影響も大きいので、上の憶測が正しい場合、もしこれ以上オオゴトになれば担当者は誰かしら処分されるんじゃない？　と見ています。あーあ、、、、

他にもがばいよ！

　さすがに盗用と比べると霞んで見えますが、クオリティは低いです。

ソースコード
n = 1
 n+=1
 print (n)
https://techacademy.jp/magazine/18190

　そのままコピペしました。きっと真似して書いた人は「IndentationError: unexpected indent」に悩まされるでしょう。

　推して知るべし・・・

今後の展開

とりあえずTechAcademyは事実関係を認めて謝罪した方が良いと思います。ライセンスの件についてはイマイチはっきりしませんが、アクセスしたユーザに嘘をついた（teratailのコピペをTechAcademyに寄せられた質問と回答として紹介した）ことは事実です。「なかったこと」にするには遅すぎます（最初から遅すぎるのだが）。逆に、本格的に炎上する前に傷を閉じられれば、相対的に浅く済む可能性もあります。
teratail運営はできれば早急にこの件についての立場を示すべき。「ああいう使い方をされるのを承知で売っていた疑惑」が少しでも残っている限り、ちょっと安心して使い続けることができません。

　→2019/03/25に問い合わせの結果が来て、「ライセンスしていない」とのことでした。今後の対応は協議中とのことです。
　詳細は記事末尾の追記を御覧ください。

　以下の2つは、権利の不当な侵害があったとした場合ですが、

権利侵害の不当利益返還請求とかは、個人で考える気には正直なれません。~~理論的にはできるだろうけど、手間に見合った額が取れるかと言うととても微妙な気しかしない。~~そもそもteratailの投稿で投稿者が直接経済的な利益を得ている訳ではなく、ユーザから不当利益返還請求は難しいのでは？　という考えに傾いています。teratail運営はTechAcademyの記事にPVが流れた分の損失を被っているので、できるかもしれないけど。
teratailの運営は、不当に権利を侵害されたのであればなんか言ってみるのはありだと思います。ただ、teratailの運営会社のレバレジーズ（本業は人材アウトソーシングや転職支援などです）と、TechAcademy側にはそれなりの取引関係があることを考慮すると、最終的に「穏便に済ませる」といった判断に落ち着くのではないでしょうか。さすがに「今後も野放し」というのは、一teratailユーザとしては支持できないところなので、ほどほどの落とし所を探ってほしいのですが。

　おまけ。

この記事のアクセスが伸びる（伸びて）

今後の予防策

　プログラミングスクールや、オウンドメディア系のIT記事などが世間を騒がせた事例は去年幾つかありました。

侍エンジニア塾とAidemyの杜撰さから学ぶべきこと - Qiita

　さすがにここまで続くと構造的な問題があるとしか言えません。予防策を書きます。

　とりあえず一般ユーザーに対しては、以下くらいしか言えることがありません。

オウンドメディア系記事は検索で出てきても信用しない。はっきり言ってクオリティの平均値は個人のブログ以下ですし、オウンドメディアによくある初心者向け的な内容であれば、書籍やチュートリアルを読んだ方がわかりやすくて正確な知識がつきます。
プログラミングスクールは・・・まあ、どうしても必要なら評判とか見て選んでください。オンライン学習なら書籍＋progateとかやっすいサービスでも（優秀な人は）できると思うので、そういうのを検討するのもありです。また、オンラインスクール系よりは昔ながらの「専門学校」などの方が安定はしているでしょう。

　IT企業などの経営者の方が読んでいたらとしたら、私から伝えたいことは

半端な気持ちで自社メディア、あるいは教育事業を運営できると思うな

　の一言ですね。まともにやるなら、相当のコストを覚悟してください。それで運営して黒字にならないなら、やるべきではないと思います。

　また、すでにそういう自社メディア、事業を抱えてしまっている企業の方がもしいたら、

いますぐ相当のコストを投入して、品質に問題がないかチェックし、問題があれば修正する

　のがおすすめです。潜在的な破壊力はすでに証明されていますから、もはや時限爆弾みたいなものです。炎上するまで放置するより、先になんとか処理した方が賢明だと思います。

まとめ

　とにかくひどい。そういう感想しかありません。なんかあれこれ論評するまでもない。

　とりあえず、関係者の皆さんには「まともに」対処してほしいところですね。

2019/03/23　追記

　現時点では、これに関係する記事がほとんど削除されているようです。このまま幕引きを図るつもりだと思われます。

　今後の動向をチェックし続け、何かあれば編集します。また、この件についてteratailの運営にも問い合わせているので、そちらの進展もいずれご報告します。

2019/03/25　追記

　teratail運営への問い合わせで返信が得られたので、許可を得てこちらに掲載します。

　要約を先に書いておくと、

teratailからのライセンスは行っていない
今後の対応は協議中

　とのことです。

　私が問い合わせた内容。

送信日時： 2019/03/22 20:09:52
タイトル： TechAcademyに投稿されたteratailの投稿と酷似した記事について
本文：
お世話になっています。表題の件について伺いたいことがあります。
TechAcademyというサービスのオウンドメディア上において、teratailの質問・回答と酷似した内容が投稿されているということがインターネット上で話題になっております。
この件について以下の点について確認したいと思います。
1.　これはレバレジーズが正式に権利をライセンスしたものか
2.a.　1.について、そうであれば、妥当なものと判断し、今後対応も行わないというこか
2.b.　1.について、そうでなければ、現時点で今後の対応は検討しているか
（2.aと2.bは当てはまる方だけ回答していただければ構いません）
3.　利用規約第9条（権利帰属）から、ライセンスされたものであれば各ユーザはTechAcademyの運営会社について関連する権利を主張できない反面、そうでなければ原理的には通常通り権利侵害を申し立てられると理解しているが、それで正しいか
また、このメールと返信の公開の可否についてもお伺いしたいと思います。
お忙しいとは思いますが、何卒よろしくおねがいします。

　返信。

いつもご利用ありがとうございます。teratailサポートチームです。
この度は、お問い合わせありがとうございます。
お問い合わせいただいた件について、teratail側から記事使用のライセンス等は行っておりません。
teratailがユーザー様の投稿を活用した活動を行う場合は、ユーザー様が認識できる方法でお知らせをさせていただきます。
今後の対応については、現在協議中です。
ユーザー様に安心してご利用いただけるサービス運営に努力してまいります。
こちらの返信内容については、そのまま公開していただいて差し支えありません。
今後もteratailをよろしくお願いいたします。

　何はともあれ、teratailからライセンスはしていないとのことで、ほっとしました。

　今後は、

teratail運営の（公式発表、TechAcademy側への措置などを含めた）対応
TechAcademy側の対応

　に注目が集まりそうです。

2019/03/26　追記

　25日の夜に動きがありました。

　以降は続報記事で扱います。

TechAcademy盗用事件公式発表と深まる疑念 - 静かなる名辞

2019/04/15　続報

　その後動きはほとんどなかったのですが、続報とまとめです。

TechAcademyのその後 - 静かなる名辞

*1:私がteratailを使い続けるかどうかも考え直さないといけなくなります

*2:なお、それまでにこの記事が集めたPVは本ブログの一日の総PVの1割未満であり、集めたはてブやtwitterのシェアも片手で数えられる程度で、現時点で世間にさほど大きな影響を及ぼしてはいないことを付記しておきます

*3:また、この件については私からteratail運営に問い合わせを行っています。結果が返ってくれば追記しますが、あまり期待しないでください

*4:あるいはメディア運営をまるごと別会社に委託しているとか、そういう可能性もあるかもしれませんが、考慮しません

multiprocessing.Poolがやたらメモリを消費するときの対策

2018-12-28T20:35:55+09:00

概要

　multiprocessing.Poolは原理的にプロセスをforkさせるので、メインプロセスに大きなデータが残っているとそれが丸々コピーされてメモリ領域を食います。

　グローバル関数限定ですが、initializerを使って必要ないデータを消すことができます。また、Poolを作るタイミングを工夫することでそもそも大きいデータが子プロセスに引き継がれないようにすることができます。

前提状況の説明

　以下のようなコードです。

import subprocess
from multiprocessing import Pool

import numpy as np

a = np.arange(10**7)

def f():
    subprocess.run("ps -aux | grep [m]emory_test", shell=True)

p = Pool(1)
p.apply(f)
p.close()
p.terminate()
print(a.shape)

　見るからにメモリをドカ食いしそうな10**7のnumpy配列を確保しています。実行すると、以下のようになります。

username      7407 44.0  1.2 543952 100056 pts/0   Sl+  20:25   0:00 python memory_test.py
username      7411  0.0  1.1 347344 94640 pts/0    S+   20:25   0:00 python memory_test.py
(10000000,)

　もし子プロセスで走らせたいのがaを使わない処理なら、無駄に大容量のメモリを食っていることになります。

対策1：initializerで消す

実験

　以下のようなコードを書いてみます。

import subprocess
from multiprocessing import Pool

import numpy as np

a = np.arange(10**7)

def f():
    subprocess.run("ps -aux | grep [m]emory_test", shell=True)

def initializer():
    del globals()["a"]

p = Pool(1, initializer=initializer)
p.apply(f)
p.close()
p.terminate()
print(a.shape)  # ちゃんといることの確認

username      7427  0.0  1.2 543948 100112 pts/0   Sl+  20:26   0:00 python memory_test.py
username      7431  0.0  0.2 269212 16548 pts/0    S+   20:26   0:00 python memory_test.py
(10000000,)

　だいぶ改善しました。

本末転倒というか・・・

　まあ、見ての通りエレガントな方法ではありません。また、globals()は書き換えられてもlocals()は書き換えられないので、ローカル変数には効きません。

　そこで2番目の対策を考えます。

対策2：早めにPoolを作る

説明

　上のコードでaが作られる以前にPoolを作れば、その時点でforkするのでメモリどか食い現象は回避できます。

　こんな感じですね。

import subprocess
from multiprocessing import Pool

import numpy as np

def f():
    subprocess.run("ps -aux | grep [m]emory_test", shell=True)

p = Pool(1)
a = np.arange(10**7)

p.apply(f)
p.close()
p.terminate()
print(a.shape)

username      7525  0.0  1.2 543952 100116 pts/0   Sl+  20:31   0:00 python memory_test.py
username      7529  0.0  0.2 269216 16512 pts/0    S+   20:31   0:00 python memory_test.py
(10000000,)

　initializerで消すのと同等の効果がありますが、こちらだとローカル変数でも大丈夫です。また、グローバル変数をdelする方法だと、initializerが走るまでの一瞬の間は無駄なデータがメモリを消費する訳で、そういう面でもこちらの方が有利だと思います。

まとめ

　早めに（重いデータがメモリに読み込まれる前に）forkしておくのが基本ですが、どうしても駄目なときは削除も試してみましょう。

追記

　プロセスの開始方法に"spawn"を指定することでも可能だとコメントでご指摘をいただきました。

spawn
親プロセスは新たに python インタープリタープロセスを開始します。子プロセスはプロセスオブジェクトの run() メソッドの実行に必要なリソースのみ継承します。特に、親プロセスからの不要なファイル記述子とハンドルは継承されません。この方式を使用したプロセスの開始は fork や forkserver に比べ遅くなります。
Unix と Windows で利用可能。Windows でのデフォルト。
17.2. multiprocessing — プロセスベースの並列処理 — Python 3.6.5 ドキュメント

　multiprocessing.get_context('spawn')とすると、multiprocessingモジュールと同じAPIを持つオブジェクトが返り、これからPoolを作ることで解決できます。これを利用しても良さそうです。

【python】numbaを使ってライフゲームを書いてみた

2018-12-15T17:31:45+09:00

概要

　ライフゲームを書きました。

　素のpythonだと何をやっても激遅だったので、numbaで高速化しました。

方針

　まず実装の方針を決めます。主要な関数としては以下のものがあればできると思いました。

update_cell

　1セルの状態を更新する

update_field

　フィールド全体を更新する

main

　メインループ、描画など

　最初からnumbaを使ってみるつもりでしたが、numbaは割と制約が多いので、基本的にpython的なコードにするとJITコンパイルに失敗します。それを意識してコーディングしました。
（nopython=Trueオプションを付けてコンパイルできる状態でないと、まったく速くなりません。みなさんも注意してください）

実装の説明

　実装の詳細について説明します。

グローバル変数

　グローバル変数として以下の2つを定義しました。

field_w = 200
field_h = 200

　フィールドのサイズはグローバル変数で書いておいた方が楽だろう、という判断です。なお、とりあえず200*200を指定していますが、私のマシンでは600*600くらいまでは1ステップ1秒未満で計算できます。見てて楽しいのはもっと小さいフィールドですが。

get_ijlst関数

　ライフゲームを書こうとしたとき、誰もが思うのは「周囲8セルの座標を出すのが面倒くさい」ということでしょう。(i, j+1), (i, j-1), (i+1, j+1),...みたいにやっていけば良いことはわかりますが、フィールドからのはみ出しなどを考慮すると大変そうです。

　そこで、その部分を簡略化するべく関数を1つ作りました。

@nb.jit(nopython=True)
def get_ijlst(x, limit):
    ret = []
    if 0 < x:
        ret.append(x-1)
    if x < limit-1:
        ret.append(x+1)
    ret.append(x)
    return ret

　基本的には[x-1, x+1, x]のlistを返しますが、0 <= x < limitの範囲に収まらない要素は返り値のlistの中に含めないような処理をするための関数です。なお、これは次に説明するupdate_cell関数から呼ぶため、jitコンパイルしています。

update_cell関数

　先にコードを示します。

@nb.jit(nopython=True)
def cell_update(i, j, field, out):
    i_lst = get_ijlst(i, field_h)
    j_lst = get_ijlst(j, field_w)

    s = 0
    for ni in i_lst:
        for nj in j_lst:
            s += field[ni, nj]
    s -= field[i,j]

    if s < 2:
        out[i,j] = 0
    elif s == 2:
        out[i,j] = field[i,j]
    elif s == 3:
        out[i,j] = 1
    elif s >= 4:
        out[i,j] = 0
    else:
        raise Exception

　座標値のi,jとnumpy配列のfield, outを受け取り、fieldに従って計算した次の状態をoutに書き込みます。

　上のforループのあたりのコードは周囲8マスの総和の計算ですが、実は中心の(i,j)の値もループ対象にして総和を格納する変数sに加算し、後から中心の値をsから引いています。ループの中にifなどを入れて判定するより処理速度的に安上がりだろうという判断です。

　その下にあるif文はライフゲームのルールを実装しています。周囲8マスの総和をsとおくと、

sが2未満なら死（過疎）
sが2なら元と同じ値
sが3なら誕生する。元の生死にかかわらず1
sが4以上なら死（過密）

　と表せます。なお、これ以外のパターンはルール上ありえないので、万が一へんな値が来たときに備えてelse節で例外を投げています（限りなくデバッグ用に近い）。

update_field関数

　こちらはシンプルです。

def update_field(pair_lst):
    for i in range(field_h):
        for j in range(field_w):
            cell_update(i, j, pair_lst[0], pair_lst[1])
    pair_lst.append(pair_lst.pop(0))

　工夫したのはpair_lstでしょうか。これは同じサイズ（shape=(field_h, field_w)）の2つのnumpy配列を要素に持つlistを受け取ることを想定しています。このlistは呼び出し元（main）で定義します。

　最後の行が何をしているのか、初見では理解できないと思いますが、

>>> lst = [0,1]
>>> lst.append(lst.pop(0))
>>> lst
[1, 0]

　このように値を入れ替えられるというアイデアです。つまり、2つの配列を最初に作り、ずっと同じ2つを新旧を入れ替えながら使うということです。これによりオーバーヘッドの削減を狙っています。

main

　必要な配列を定義し、更新・描画のループを回しているだけです。手抜きによりmatplotlibでアニメーション描画しています。

def main():
    field = (np.random.random(size=(field_h, field_w)) > 0.9).astype(np.int16)
    out = np.zeros(shape=(field_h, field_w)).astype(np.int16)
    pair_lst = [field, out]

    img = plt.imshow(field)
    for i in range(1000):
        update_field(pair_lst)
        img.set_data(pair_lst[0])
        plt.pause(0.001)

コード全文

　コードの全体を以下に示します。

import numpy as np
import numba as nb
import matplotlib.pyplot as plt

field_w = 40
field_h = 60

@nb.jit(nopython=True)
def get_ijlst(x, limit):
    ret = []
    if 0 < x:
        ret.append(x-1)
    if x < limit-1:
        ret.append(x+1)
    ret.append(x)
    return ret

@nb.jit(nopython=True)
def update_cell(i, j, field, out):
    i_lst = get_ijlst(i, field_h)
    j_lst = get_ijlst(j, field_w)

    s = 0
    for ni in i_lst:
        for nj in j_lst:
            s += field[ni, nj]
    s -= field[i,j]

    if s < 2:
        out[i,j] = 0
    elif s == 2:
        out[i,j] = field[i,j]
    elif s == 3:
        out[i,j] = 1
    elif s >= 4:
        out[i,j] = 0
    else:
        raise Exception

def update_field(pair_lst):
    for i in range(field_h):
        for j in range(field_w):
            update_cell(i, j, pair_lst[0], pair_lst[1])
    pair_lst.append(pair_lst.pop(0))

def main():
    field = (np.random.random(size=(field_h, field_w)) > 0.9).astype(np.int16)
    out = np.zeros(shape=(field_h, field_w)).astype(np.int16)
    pair_lst = [field, out]

    img = plt.imshow(field)
    for i in range(1000):
        update_field(pair_lst)
        img.set_data(pair_lst[0])
        plt.pause(0.001)

if __name__ == "__main__":
    main()

計測

　描画処理をコメントアウトし、JITコンパイルを付けたときと外したときで200*200のフィールドを20ステップ進めるのにかかる時間を計測してみました。

JITコンパイルなし

　8.8秒

JITコンパイルあり

　1.4秒

　6倍強の高速化が達成されました。・・・ってちょっと微妙ですね。威張るほどでもない。

　numbaの型指定をしていないからかもしれないし、そもそもこんなものという可能性もあります。

画像

　50*50のフィールドで、グライダーが生まれたタイミングを見計らって一枚スクショしてみました。

結果

　色合いが変なのはcmapをデフォルトのまま変えていないからです。

　動いているのが見たい方は、コードをコピペして手元環境で実行してください。

まとめ

　案外シンプルに書けたし、numbaでの高速化を試す良い機会にもなったと思います。

追記

　CUIでも実行できるようにしました。

【python】ターミナル上でCUIでライフゲーム - 静かなる名辞

追記2

　最近numbaの正しい使い方を知りました。

www.haya-programming.com

　この知見を活かして型の情報を書いてみました。２つに分けていた関数は大した処理ではないのでまとめました。

@nb.jit("void(i8, i8, i2[:, :], i2[:, :])", nopython=True)
def update_cell(i, j, field, out):
    i_lst = [i]
    j_lst = [j]
    if 0 < i:
        i_lst.append(i-1)
    if 0 < j:
        j_lst.append(j-1)
    if i < field_h:
        i_lst.append(i+1)
    if j < field_w:
        j_lst.append(j+1)
        
    s = 0
    for ni in i_lst:
        for nj in j_lst:
            s += field[ni, nj]
    s -= field[i,j]

    if s < 2:
        out[i,j] = 0
    elif s == 2:
        out[i,j] = field[i,j]
    elif s == 3:
        out[i,j] = 1
    elif s >= 4:
        out[i,j] = 0
    else:
        raise Exception

　元のコードでは1.4秒（ライブラリのアップデートにも関わらずほとんど変わらなかった）かかっていたものが、0.9秒に高速化されました。

　こうなるともう少し速くならないかと思うのが人情で、こっちもJITコンパイルすることにします。

@nb.jit("void(i2[:, :], i2[:, :])", nopython=True)
def update_field(a, b):
    for i in range(field_h):
        for j in range(field_w):
            update_cell(i, j, a, b)

　呼び出し側はこうします。

def main():
    field = (np.random.random(size=(field_h, field_w)) > 0.9).astype(np.int16)
    out = np.zeros(shape=(field_h, field_w)).astype(np.int16)
    pair_lst = [field, out]

    t1 = time.time()
    # img = plt.imshow(field)
    for i in range(20):
        update_field(*pair_lst)
        pair_lst.append(pair_lst.pop(0))
        # img.set_data(pair_lst[0])
        # plt.pause(0.001)
    t2 = time.time()
    print(t2- t1)

　0.4秒に高速化されました。こんな感じで速くなるので、なかなか大したものだと思いました。

プログラミングのブログにアドセンスを貼る話

2018-12-02T09:53:48+09:00

はじめに

　一ヶ月ほど前から当ブログはGoogle Adsenseを導入しています*1。

　このブログはいわゆる「技術ブログ」と呼ばれるようなプログラミングのブログですが、プログラミング関連のジャンルでアドセンスを貼った場合の収益性についてはネット上にもあまり情報がありませんでした。なので貼る前は「びっくりするほど儲からなかったらどうしよう」などと思っていたのですが、とりあえずそれに関しては杞憂かな、という水準では稼げそうです。

　ご報告を兼ねて、内実をレポートします。

　なお、規約の絡みでPVや収益などの指標の具体的な数字は公表できません。あしからず。以下に出てくる数字は、有効数字一桁くらいのアバウトなものだと思ってください。基本的にボカして書いています。

このブログのPVと収益性

　まずこのブログの一日のPVですが、先月の数字を平均すると一日2000 PV弱くらいです。記事数はこの記事で183記事目で、1記事あたり10 PV強が得られていることになります。

　アドセンスの収益性の指標としては、ページRPMというものがあります。これは1000 PVで得られる収益のことです。これを1000で割れば収益[円]/閲覧数[PV]になるので、こちらで示します。当ブログでは0.2円/PV前後です。

　なので、アバウトですが一日400円弱ほど儲かるかなぁ、という収益性になっています。一ヶ月では一万円くらいです。これをしょぼいと見るか、小遣い稼ぎとしては優秀と見るかは、人によって分かれると思います。

収益の傾向

　プログラミングのブログというジャンルには、幾つかの特色があるようです。世間で言われているアドセンスとは、ちょっと違う傾向が見えました。

ユーザのほとんどはPCからアクセス

　アクセスの9割はPCからです。プログラミングをしながら調べごとをして当ブログにたどり着く方が多いと思うので、当たり前だと思います。

　このおかげで、PC向けに最適化すればとりあえず問題なく収益があがります。

　SEOとかアフィリエイトのサイトには、「現在はモバイルからのアクセスがほとんどなので、サイドバー広告は効果が少ない」なんて書いてあるところが幾らでもありますが、当ブログではサイドバー広告は立派な主力です。

　モバイル向けに最適化しようとすると、入れるのが面倒な上に本格的に邪魔な記事中広告を主力にせざるを得ないと思うので、これは嬉しい傾向です。サイトのユーザビリティを大きく損なわずにアドセンスで稼げます。
（余談ですが、一番稼いでくれるのはブログの一番上にでかでかと貼ってあるヘッダ広告です。印象は最悪なんだろうけど、全収益の2/5くらいをはじき出しています）

低いクリック率とそこそこのクリック単価

　よく巷のサイトには「ITスキルの高いユーザが多いサイトは広告のクリック率が下がる」などと書いてありますが、その理論で行くとプログラミングのジャンルのユーザなんてITスキル最強みたいなものですからクリック率は低いはずです。このブログも案の定というか、0.1%という「低い」クリック率をはじき出しています（平均で0.3%、本格的なアフィサイトであれば1%くらいは行くそうです）。

　それでも、クリックが「0ではない」というのは励みになる要素で、まあ何千人も来ていれば一定の確率で広告をクリックする人はいるということでしょう。

　「そんなにクリック率が低くて儲かるのかよ」と思う方もいると思いますが、広告単価が高いものが多いっぽく、なんとか補えます。恐らく、単価が高めの転職系、学習系、IT製品系などが表示されていることの結果だと思います。

　アドセンスのクリック単価の平均は30～40円くらいらしいですが、当ブログはその倍は軽く叩き出しています。

　なので、最終的にはクリック率の低さと広告単価の高さが相殺しあって、世間並みにはカネになってるのかな？　という印象です。

準主力のCPM

　アドセンスというと、普通はクリック単価広告の印象が強いと思いますが、実はCPMというインプレッション単価型の広告（広告の表示で収益が発生する/広告主からすると表示される回数にお金を払う）も存在します。

　なんか、軽く調べた感じだと、普通のサイトではCPM型の総収益比は2割未満らしいのですが……何しろ上述の通りのクリック率なので、このブログではCPMも準主力くらいには稼いでくれます。日によって変動はありますが、一日の収益の1/3～1/2くらいは稼いでくれていると思います。インプレッション収益も、クリック単価型と遜色ありません。むしろ日によっては上回ることすらあります。

　CPM型の広告は、PVに比例して着実に収益が伸びていきます。サイト運営者からすれば運次第な要素のあるクリック単価型広告とは違い、十数分おきに確認するたびに（確認してどうするんだ、って話ですが）コツコツ1円ずつ収益が積み上がっていくので、心に優しい広告です。

割に合うの？

　これについて知りたい方も多いと思いますが、結論から言えばたぶん仕事としては割に合わないです。ある程度効率的に運営できたとしても、時給500円くらいだと思います（記事を書く労力、維持管理する労力を適当に時間換算すれば、自ずと結論はでます）。

　ただし、ブログ運営は「趣味」ですから、そう考えると「趣味」をやるだけで、

時給500円稼げる
さやかながら我が国のITの発展に貢献できる（かもしれない）

　なので、皆さんも（書くネタがあれば）プログラミングとか技術系のブログを作ってみてください*2。

結論

　儲かるかというと微妙なのですが、稼げないというほどでもないという程度には稼げます。

　強弁すれば小遣い稼ぎにはちょうど良いと見れなくもありませんが、積極的に人におすすめはしません。でも、このブログを完全放置しても月1万円になるので*3、私は貼り続けます。そんなところです。

*1:邪魔と思われている読者の方も当然おられるかと思いますが、私の小遣いに直結する問題なので、生暖かい目で見守っていただければなぁ、と思います。

*2:でもものすごく流行っちゃって、広告の需給が悪化して単価下がったりすると（私が）困るので、この記事を読んで「プログラミングのブログを始めてみようかな」と思い立つ人は2人か3人いればそれで良いです

*3:ただし1万円をずっと維持できる訳ではないことに注意。プログラミングの記事なんて、数年もすれば検索順位下落・トレンドの移り変わりで読まれなくなることでしょう

C言語でshellの多段パイプを実装

2018-11-08T18:53:49+09:00

はじめに

　学校の課題でCでshellもどきを書きました。

　今後、同じ目にあう人のために、「shellの多段パイプをどうやって実装したら良いのか」を記事としてまとめておきます。

はじめに
パイプの概要
使用する関数
パイプの実装方針
コード
改良した方が良い点
まとめ
参考にしたサイト

パイプの概要

　shellのパイプとは……という話はさすがに要らないと思いますが、以下のような機能があります。なお、下記サンプルの実行時に、カレントディレクトリに今回の記事で紹介するCのコードtest.cを置いてあるとします（内容については後述します）。

$ cat test.c | head | grep char
char *cmd1[] = {"cat", "test.c", NULL};
char *cmd2[] = {"head", NULL};
char *cmd3[] = {"grep", "char", NULL};
char **cmds[] = {cmd1, cmd2, cmd3};

　「cat test.c」はtest.cの内容を標準出力に吐き出します。が、今回はその出力はパイプによって「head」に繋がれます。「head」は入力の先頭10行を出力するコマンドです。その出力も「grep char」の入力に繋がれて、先頭10行の中でcharにマッチする行だけが出てきます。

　C言語のコードでこれと同じものが動くことが今回の目標です。

使用する関数

　shellのパイプ機能を実装するために最低限必要な関数を示します。なお、上の例のtest.cで察した方もおられるかと思いますが、コマンドの入力やパースは今回省略し、あくまで「実行するとパイプでコマンドをつないで一回動作するプログラム」を作ります。

　更に、エラー処理等も省略し、コードを極力シンプルな形になるまで削ぎ落としてあります。ヘッダファイルは「unistd.h」だけincludeすればコンパイルできます。使う関数はたった6種類です。

　以下に使用する関数の簡単な説明を記述します。あくまでも簡単な説明なので、ちゃんとした説明が必要ならmanなどを読んでください。

int pipe(int pipefd[2])

　名前無しパイプを生成します。pipefdは配列のアドレスを渡し、ファイルディスクリプタを受け取ります。pipefd[1]にデータを書き込むとpipefd[0]から読み出せます。

int close(int fd)

　引数に渡されたファイルディスクリプタを閉じます。

　パイプをうまく機能させようと思うと、必要のないファイルディスクリプタは片っ端から閉じておく必要があります。無駄に開いている読み出し口や書き込み口があると、入力が終わってもEOFが返されません。するとパイプで繋がれたプログラムが終了しないので、いつまでも待ち続ける羽目になります。必要なものだけ開いた状態にするのが鉄則です。

int dup2(int oldfd, int newfd)

　newfdをoldfdのコピーとして作成します。

　と急に言われても何をするのかよくわかりませんが、上で説明したpipe()でパイプを作っておいたとして、

dup2(pipefd[1], 1);

　で標準出力をパイプの書き込み口に繋ぐことができ、同様に

dup2(pipefd[0], 0);

　とすれば標準入力をパイプの読み出し口に繋ぐことができる、ということだけ覚えておけば、今回は十分です。

pid_t fork(void)

　プロセスをforkします。返り値はpid_tという型ですが、これはただの整数型です。forkが成功した場合、pid_tが0なら子プロセス、0以外（実際には子プロセスのPID）なら親プロセスです。失敗すると-1が返ります。

pid_t wait(int *status)

　子プロセスが返るのを待ちます。成功した場合、返り値は子プロセスのPIDで、statusに終了情報が格納されます。

int execvp(const char file, char const argv[])

　コマンドを実行します。第一引数はコマンドの文字列、第二引数は引数の配列でNULL終端とする必要があります。

　要するに、

char *cmd1[] = {"ls", NULL};

　と定義しておけば、

execvp(cmd1[0], cmd1);

　でlsが実行できます。

パイプの実装方針

　さて、シェルのパイプを作ることを考えます。ここで考え込んでもあまり良いアイデアは浮かんでこないので、とりあえず実際のコマンドを見ます。

$ cat test.c | head | grep char

　では3つのコマンドを2つのパイプで繋いでいます。要するにコマンド数-1のパイプを作れば良い訳です。

　ということは、パイプを配列で管理するのかな？　と一瞬思いますが、それでも確かにできるのですが、ちょっと煩雑そうです。

　もう少し簡単にする方法はないでしょうか？　あります。再帰を使います。

　まずメインのプロセスからforkして、パイプを作り、更にforkします。親はstdinをパイプに繋いで右端（右から0番目）のコマンドの実行、子はstdoutをパイプに繋いで更にパイプを作ってforkして、今度は親になった先程の子が右端から1番目のコマンドを実行、子はまたforkしてパイプを作り……と繰り返していって、左端のコマンドに達したら単に実行して終わりです。この手続きは再帰的に行えます。

　「なぜ素直に左端からforkしないの？」と疑問を持つ方もいると思いますが、実は左から始めてもパイプそのものはできます。ただし、execしてしまうとプロセスの制御は呼び出し元に戻ってきません。execの中でexitされると思ってください。

　なので、左端からforkすると左端のコマンドが終了した段階でメインプロセス側のwaitが返り、他のコマンドがまだ実行途中であっても制御が戻ってしまいます。実際にやるとわかりますが、出力の途中でプロンプトが出てきたりして、ちょっと不格好な結果になります。右端からforkすれば、右端のコマンドは最後に終了するので、確実にメインプロセス側でコマンドの終了を検知できます。左端からforkする方法でこの問題を回避しようとすると、何らかの制御手段を追加する必要があります。

　左端からやろうと右端からやろうと、execしてしまう以上、途中では親が子をwaitできないことに違いはありません。ゾンビにならないの？　と思うかもしれませんが、この場合は最終的に親が死ぬので、initが引き取ってくれてゾンビになりません。大本の親だけ回収しておけば、それほど気にする必要はありません。

　説明だけ読んでいてもどうなっているのかよくわからないと思うので、図にしてみました。

パイプ実行時のforkの流れ

　この図は上から下に実行されていると思ってください。分岐はfork、合流はwaitでプロセスを看取っていることを示します。分岐の左側がforkの親で、右側が子です。

　cmd3はメインプロセスが看取ります。省略していますが、cmd1とcmd2はcmd3が看取られた後にinitが看取ります。

コード

　実際に書いたコードを以下に示します。上の説明はこのコードを書いてから起こしたものなので、ここまでの内容を読んだ方であれば簡単に理解できると思います。50行ちょっとなので読みやすいはずです。

test.c

#include <unistd.h>

char *cmd1[] = {"cat", "test.c", NULL};
char *cmd2[] = {"head", NULL};
char *cmd3[] = {"grep", "char", NULL};
char **cmds[] = {cmd1, cmd2, cmd3};
int cmd_n = 3;

void dopipes(i) {
  pid_t ret;
  int pp[2] = {};
  if (i == cmd_n - 1) {
    // 左端なら単にexecvp
    execvp(cmds[0][0], cmds[0]);
  }
  else {
    // 左端以外ならpipeしてforkして親が実行、子が再帰
    pipe(pp);
    ret = fork();

    if (ret == 0) {
      // 子プロセスならパイプをstdoutにdup2してdopipes(i+1)で再帰し、
      // 次のforkで親になった側が右からi+1番目のコマンドを実行
      close(pp[0]);
      dup2(pp[1], 1);
      close(pp[1]);
      
      dopipes(i+1);
    }
    else {
      // 親プロセスならパイプをstdinにdup2して、
      // 右からi番目のコマンドを実行
      close(pp[1]);
      dup2(pp[0], 0);
      close(pp[0]);
      
      execvp(cmds[cmd_n-i-1][0], cmds[cmd_n-i-1]);
    }
  }  
}

int main(void) {
  pid_t ret;
  
  ret = fork();
  if (ret == 0)
    dopipes(0);
  else
    wait(NULL);

  return 0;
}

　コンパイルして実行すると（実行ファイルはソースコードと同一ディレクトリに置いてください）、

char *cmd1[] = {"cat", "test.c", NULL};
char *cmd2[] = {"head", NULL};
char *cmd3[] = {"grep", "char", NULL};
char **cmds[] = {cmd1, cmd2, cmd3};

　と最初のshellから打ち込んだパイプコマンドと同じ結果が出力されます。

改良した方が良い点

　とりあえず、システムコールは失敗することもあり得るので、ちゃんとエラー処理しましょう。この記事ではわかりやすさを重視してすべて端折っていますが、

　あとはdup2に関してですが、

// stdoutにdup2
close(pp[0]);
dup2(pp[1], 1);
close(pp[1]);

// ------

// stdinにdup2
close(pp[1]);
dup2(pp[0], 0);
close(pp[0]);

　dup2の際にnewfdが開いていれば勝手に閉じられます。これに失敗する可能性があり、その場合エラー情報は握りつぶされます。なので、stdinとstdoutも明示的に閉じてエラー処理をした方が良いとされます。

まとめ

　これでパイプを実装しないといけなくなっても大丈夫！

参考にしたサイト

シェルの多段パイプを自作してみる | 慶應義塾大学ロボット技術研究会
　こちらは配列で管理する方法でパイプを実装しています。

linux上で動くシェルを自作しています。多段階のパイプを実装方法を教... - Yahoo!知恵袋
　結構ヒントになりました。ここの回答をコードに起こしたようなものでした。

pythonのスコープは静的に決まる。だから・・・

2018-11-01T05:30:22+09:00

概要

　少し疑問に思うことがあったので、書き留めておきます。

概要
前提
確認したかったことと結果
まとめ

前提

　まず以下のようなコードについて考えます。

>>> def f():
...     print(a)
... 
>>> a = "hoge"
>>> f()
hoge

　ここでf()の中のprint()でaを参照しています。aはローカルスコープで定義されていないため、外のスコープ（この場合はグローバルスコープ）にあるのだろうとpythonインタプリタは判断します。

　そのため、f()を呼ぶとグローバルスコープで定義したaがprint(a)で出てきます。

　ここまでは特に疑問はないと思います。次にこれについて考えます（上から続けて実行します）。

>>> def f():
...     print(a)
...     a = "fuga"
...     print(a)
... 
>>> f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in f
UnboundLocalError: local variable 'a' referenced before assignment

　f()の中でaに対する代入を行うと、aはローカル変数とみなされます。位置は関係なく、スコープは定義時に静的に確定します。なので、UnboundLocalErrorというエラーが発生します。

　これは有名な話で、公式ドキュメントのFAQにも載っています。pythonプログラマなら知っていないといけないことです。

プログラミング FAQ — Python 3.6.5 ドキュメント

　ここまでが前提です。

確認したかったことと結果

　こんな関数定義ではどうなるのか。

>>> def f():
...     print(a)
...     if False:
...         a = "fuga"
...     print(a)
...

　原則どおりならスコープは静的に確定しますが、なんとなく違う結果になるという期待も抱かせます。

　結果。

>>> f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in f
UnboundLocalError: local variable 'a' referenced before assignment

　変わらないのだった。

まとめ

　「とにかく関数の中で代入されていればローカルスコープ」という原則が何よりも優先される、ということを再確認できました。

アドレス変更のおしらせ

2018-10-16T15:34:37+09:00

　本日、本ブログを独自ドメイン化しました。それに伴い、アドレスが変更になりました。

旧URL

　https://hayataka2049.hatenablog.jp/

新URL

　https://www.haya-programming.com/

　旧URLからも301リダイレクトされますが、ブックマーク登録等はお早めの更新をおねがいします。

　今後共よろしくおねがいします。

pythonで変数のswap（入れ替え）について考えて検討してみた

2018-09-19T19:58:28+09:00

はじめに

　変数の入れ替えは、C言語の教科書などにも書いてある古典的な話題です。

　一番古典的な方法では、こうやります。

>>> a = 10
>>> b = 20
>>> a
10
>>> b
20
>>> tmp = a
>>> a = b
>>> b = tmp
>>> a
20
>>> b
10

　ただ、このコードは……あまり書きたくないですね。

pythonではエレガントに書ける

　pythonの代入文にはイカれた機能があり、こういうものを綺麗に書けます。

>>> a = 10
>>> b = 20
>>> b,a = a,b
>>> a
20
>>> b
10

　参考：

タプル+シーケンスアンパックとして解釈できるか？

　この記事の本題なのですが、これはタプル＋シーケンスアンパックとして解釈できるのでしょうか？

　構文的に考えると、まず右辺はtupleを作っているはずです。

なお、タプルを作るのはカンマであり、丸括弧ではありません。丸括弧は省略可能ですが、空のタプルの場合や構文上の曖昧さを避けるのに必要な時は例外です。例えば、 f(a, b, c) は三引数の関数呼び出しですが、f( (a, b, c) ) は 3-タプルを唯一の引数とする関数の呼び出しです。
4. 組み込み型 — Python 3.6.5 ドキュメント

　左辺はシーケンスアンパックとして解釈できそうです。

　ということで、これはtuple+sequence unpackなはずなので、バイトコードを読んでみましょう。

>>> def f():
...     a,b = b,a
... 
>>> import dis
>>> dis.dis(f)
  2           0 LOAD_FAST                0 (b)
              3 LOAD_FAST                1 (a)
              6 ROT_TWO
              7 STORE_FAST               1 (a)
             10 STORE_FAST               0 (b)
             13 LOAD_CONST               0 (None)
             16 RETURN_VALUE

　解説はここに。なお、言うまでもなくCPython前提です。また、私が2018年9月現在使っている処理系はpython3.5.1です（いい加減更新しろよ・・・）。

32.12. dis — Python バイトコードの逆アセンブラ — Python 3.6.5 ドキュメント

　関係あるものだけ引用します。

LOAD_FAST

　ローカルな co_varnames[var_num] への参照をスタックにプッシュします。

STORE_FAST

　TOS をローカルな co_varnames[var_num] の中に保存します

ROT_TWO

　スタックの先頭の 2 つの要素を入れ替えます。

　あれ、もしかしてtuple+sequence unpackではない？

検証

　まず、こうしてみる。

>>> def f():
...     a,b = (b,a)
... 
>>> dis.dis(f)
  2           0 LOAD_FAST                0 (b)
              3 LOAD_FAST                1 (a)
              6 ROT_TWO
              7 STORE_FAST               1 (a)
             10 STORE_FAST               0 (b)
             13 LOAD_CONST               0 (None)
             16 RETURN_VALUE

　あまり関係なさそう。

　入れ替える個数を3つにしてみる。

>>> def f():
...     a,b,c = c,b,a
... 
>>> dis.dis(f)
  2           0 LOAD_FAST                0 (c)
              3 LOAD_FAST                1 (b)
              6 LOAD_FAST                2 (a)
              9 ROT_THREE
             10 ROT_TWO
             11 STORE_FAST               2 (a)
             14 STORE_FAST               1 (b)
             17 STORE_FAST               0 (c)
             20 LOAD_CONST               0 (None)
             23 RETURN_VALUE

　なんかROT_THREEまで出てきて凄まじいけど、タプル生成→シーケンスアンパックされている様子はない。

　4つに。

>>> def f():
...     a,b,c,d = d,c,b,a
... 
>>> dis.dis(f)
  2           0 LOAD_FAST                0 (d)
              3 LOAD_FAST                1 (c)
              6 LOAD_FAST                2 (b)
              9 LOAD_FAST                3 (a)
             12 BUILD_TUPLE              4
             15 UNPACK_SEQUENCE          4
             18 STORE_FAST               3 (a)
             21 STORE_FAST               2 (b)
             24 STORE_FAST               1 (c)
             27 STORE_FAST               0 (d)
             30 LOAD_CONST               0 (None)
             33 RETURN_VALUE

　やっと狙ったものが出てきました。BUILD_TUPLE, UNPACK_SEQUENCEが該当する命令です。

考察

　tupleオブジェクトの生成はそれなりにオーバーヘッドを伴うはずである。

　CPythonインタプリタはこのようなswap代入に対して、3つまではスタックを用いた高速な処理を行うよう最適化されている。

　4つ以上ある場合は（たぶん最適化を実装するのが面倒くさいので）tupleにしてシーケンスアンパックで処理する。

まとめ

　うっかり「シーケンスアンパックと考えることができます」とか言えない。まあ、どのみち結果は変わらないのだが。

　ちょっとすっきりしないけど、最適化してくれてるんだね、みたいな話。

オブジェクト指向の教育にPythonが向いていると思うこれだけの理由

2018-06-27T06:12:49+09:00

はじめに

　オブジェクト指向は今となっては常識である。

　常識であるがゆえに、いかに初心者にわかりやすく教えるかが課題になる。

　世の中でオブジェクト指向の「教材」として使われている言語は、

Java
Ruby

　の二択くらいだと思う。が、あえて僕はPythonを推してみるよ、という記事。ぶっちゃけポエム。

　内容は、Javaでオブジェクト指向を理解するのはしんどいし、RubyとPythonだと僅差でPythonが勝つんじゃないかなぁ、という主張。以下で理由を書いていくよ。

はじめに
Pythonが向いていると思う理由
向いていない理由も一応書く
まとめ

Pythonが向いていると思う理由

理由1：すべてがオブジェクト

　すべてがオブジェクト。これは重要なことである。

　オブジェクトとオブジェクト以外で異なる扱いをしなければならない、プリミティブ型のある言語でオブジェクト指向の教育をするなんて、正気の沙汰ではない。初心者はintと配列ばっかり使う訳だしさ。

　なので、Javaはぶっちゃけ論外だと思う。Ruby使いの人は「ならPythonとRubyは互角だ」と言いたくなるかもしれないけど、Rubyには関数が第一級オブジェクトではないという弱点があり、「すべてがオブジェクト」ははっきり言って誇大広告である。

　関数オブジェクトが自然に使えないと困るのかって？　まあ、そんなに困らないかもしれない。でも「関数オブジェクト」は理解しておいた方が、オブジェクト指向がよくわかるようになると思わない？（上級者向けすぎるか）

理由2：仕様がスリムで綺麗。書きやすい

　Javaにはまず、publicやらprivateやらある。interfaceというわかりづらい概念もある。静的型付けなのも相まって、メソッドの宣言なんかカオス。public static void mainはどう考えても初心者向けではない*1。

　Rubyは、なんかブロックとかいうよくわからないものがあるね。あと、メソッド呼び出しのカッコを省略できるとか。教育上あんまりよくないと思います。

　Pythonにはそういう問題はない。

理由3：self

　Pythonのselfはよく批判されるけど、なんだかんだでわかりやすい。

a.hoge("fuga")

　は

type(a).hoge(a, "fuga")

　と実質的に等価というルールがあることを理解すれば、後は不自然な点はなにもない。インスタンスの外側ではaとして見えているものは、内側ではselfとして見えていると考えれば良いということで、自然な発想でコードを書いていくことができる。

　selfを省略する言語はこれがないので、クラス変数とインスタンス変数の区別を付けるだけでも一苦労だし、ローカル変数まで混ざってくると本格的に訳がわからなくなる（から、EclipseでJavaを書くとぜんぶ違う色で見せてくれる）。

理由4：普通にプログラミングしているだけでオブジェクト指向への理解が深まる

　Python初心者はlistをよく使う。そうするとappendやextendが出てくる。これはもうメソッドだ。

　関数の引数に渡したリストにappendするとリストの中身が変わるけど、intだと足し算しても変わらない。mutableなオブジェクトとimmutableなオブジェクトの違いを理解するだろうし、オブジェクトは変数に束縛されているだけというオブジェクト指向の基本的なモデル*2への理解も深まる。

　list.sort()とsorted(list)の違いを理解すれば、破壊的なメソッドには注意しないといけないこともわかる。

　だから、「オブジェクト指向の勉強のためにJavaを半年学んだ人」と「ただ単にプログラミングの勉強として半年Pythonを学んだ人」だと、オブジェクト指向に対する理解度は同程度か、ヘタしたら後者のほうが勝るくらいになっているかもしれない。

　まあ、これに関してはたぶんRubyも互角。

理由5：書いてて楽しい

　タイプ数も少ないし、なんかPythonはパズルみたいな技巧的な面があるし、書いてて楽しい。

向いていない理由も一応書く

　ダメな理由もなんか色々あるといえばあるような気もする。

罠が多い

　Pythonはシンプルなクセに罠が多い言語だと思う（「文字コード」とか「test.py作っただけでまともに動かない」とか「IndentationError」とか）。

　エラーメッセージも、わからないときはとことんわからないのが出るし。

　初心者のうちは、よくわからないところで詰む。そして初心者は自己解決できない。

　罠は回避するように教育していくとかで軽減は可能。ただ、本質的じゃない問題で初心者を悩ませるのもなんだかなぁという気がする。

そういうコンセプトの解説記事とかが少ない。あっても古い

　困るよね。

しょせんスクリプト言語

　カプセル化はないし、ポリモーフィズムの実現方法もすごく簡単（メソッド作るだけ！）。ので、Pythonやってから他の言語のオブジェクト指向を理解しようとすると、追加の学習コストがかかる。

独自の風習

　避けては通れないけど避けなかったところで得るものの少ないデコレータとか、

　初心者を惑わす内包表記とかジェネレータとか、

　やればやるほど実感するtuple周りのキモさとか*3、

　これどうなんだ、と思う側面はたくさんあります。

windowsとそんなに相性がよくない

　最近はマシにはなりましたが、まだまだハマると思います。linux環境でやれとなるといきなり敷居が高くなります。

でもまあ、

　なんだかんだで学習コストの低さ、とっつきやすさでは、総合的には初心者向けのわかりやすい言語と言っても別に構わないくらいだとは思うよ（震え声）。

まとめ

　Pythonのオブジェクト指向はわかりやすいよね、最初からこれで教えてもらえたらなぁ。Python良いよね！　って気持ちの記事です。

　特に内容に責任は持たないが、意見等はご自由にどうぞ。

*1:「そんなのIDEが補完してくれるから良いんだよ！」という意見が当然あると思うが、それをやると馬鹿の一つ覚えのようにIDEの補完と修正任せでコードを書こうとする奴が続出するのでダメだ

*2:異論はあるだろうけど

*3:tupleは丸括弧によって作られるのではない、カンマによって作られるのである

共有渡しと参照の値渡しと

2018-06-19T18:16:57+09:00

はじめに

　関数やメソッドに引数を渡す方法は、一般的には

値渡し
参照渡し

　の2通りがあると認知されている。

　ところで、『参照の値渡し』という言葉も（ほぼ日本語Web圏限定で）存在する。これは「いわゆる『参照渡し』は参照自体を書き換えるんじゃなくて、参照する対象を変えるだけだから、そう呼んだ方が適当だよ！」という思想に基づくもの、だと思う。

　このページを見るとわかりやすい。

キミの言語は参照渡しできる？ - Qiita

　つまり、こういうことができたら『参照渡し』で

a = "hoge"
b = "fuga"
swap(a, b)
print(a, b)  # => fuga, hoge

　できなかったら「キミの言語は『参照渡し』できないよ、キミが『参照渡し』だと思っているのは『参照の値渡し』だよ！」ということか。言いたいことはわかる。

　上のリンクにはC言語で「参照渡し」をやる方法としてこういう例が載っている。

#include <stdio.h>

void swap(char *a, char *b){
  char tmp;
  tmp = *a;
  *a = *b;
  *b = tmp;
}

int main(void){
  char x = 'A', y = 'B';
  swap(&x, &y);
  printf("%c\n", x);
  printf("%c\n", y);
  return 0;
}

　ちなみに、こっちの「参照渡し」は歴史が古く、少なくともFORTRANからあるっぽい。というか、FORTRANはデフォルトですべて参照渡し。

subroutine f(x)
  integer x
  x = 42
end subroutine

program main
  integer a
  a = 3
  print *, a
  call f(a)
  print *, a
end program

!           3
!          42

　C言語とかに慣れた目には奇異に映るけど、よくよく考えてみるとメモリ番地だけ渡せばいいので効率的だし（まあ実際にどういう実装なのかまでは確認していないけど）、多少注意していればプログラムも書きやすいので、これはこれで合理的だと思う。

　話が逸れた。参照の値渡しでは、こういう「参照渡し」チックな動作はできない。pythonの例。

def swap(a, b):
    a, b = b, a

a = 10
b = 20
swap(a, b)

　pythonの変数はすべてJavaなどでいうところの参照型ではあるのだけど、swapの中のa,bは単なるswap関数のローカル変数であって、呼び出し元のa, bの参照するものを書き換えたりはしない。受け取っているのは「参照の値」であって、「参照の値を格納している変数への参照」ではない。

　参照型の「真の」参照渡しについては、以下のCの例を考えてみるとわかりやすい。

#include <stdio.h>

void swap(char **a, char **b){
  char *tmp;
  tmp = *a;
  *a = *b;
  *b = tmp;
}

int main(void){
  char x = 'A', y = 'B';
  char *xptr, *yptr;
  xptr = &x;
  yptr = &y;
  swap(&xptr, &yptr);
  printf("%c\n", *xptr);
  printf("%c\n", *yptr);
  return 0;
}

　xptr, yptrのアドレスを渡す訳ですね。pythonではこれはできない（というか、そもそも変数の概念そのものが違うけど）。で、こういうものを称して参照の値渡し、とする。

共有渡しについて考える

　さて、『参照の値渡し』とよく似た概念として、『共有渡し』がある。

　ちなみに、日本語wikipediaの「引数」ページには『共有渡し』は存在しない代わり参照の値渡しがあり、英語版wikipediaの「Evaluation strategy」ページには『Call by sharing』*1はあって参照の値渡しはない。なんだかなぁ。

引数 - Wikipedia
Evaluation strategy - Wikipedia

　『共有渡し』が何者かというと、これは英語版wikipediaのページを読むのがわかりやすいのだが、一行引用してくると

also referred to as call by object or call by object-sharing

　ということであり、つまりは関数（メソッド）の呼び出し元と呼び出し先で同じオブジェクトを「共有」する方法である。

　僕のようなpython使いにとっては「それ普通じゃね？」なのだが、確かに値渡しとも『参照渡し』とも（何を示す言葉かは不問として）異なる概念と言われればそんな気はする。この言葉は、1974年、CLUという初期のオブジェクト指向言語とともに生み出された言葉だそうな。

　これに関連して、こんな議論もある。comp.lang.python　*2の昔の議論らしい。pythonの呼び出しモデルは『Call by sharing』だと結論が着いている感じ。

Call By Object

　なんか、同じものを呼ぶ名前がいっぱいある。

The most accurate description is CLU’s “call by object” or “call by sharing“. Or, if you prefer, “call by object reference“.

　こんなに呼び方が多いのはちょっと酷いんだが、“call by object reference“あたりだと言いたいことはよく伝わってくる。

どっちが良いのか

　べつに『参照の値渡し』≒『共有渡し』とみなしても良いのだが、言葉のニュアンスは違うし、他にも考えるべきことがあって「どっちを使うか、あるいはどっちでも良いのか」という問題には答えを出しづらいと思うのだ・・・。

使える言語と使えない言語がそれぞれ違う

　『参照の値渡し』は『参照の値』が定義されない言語では使うべきではないと思う。また逆に、C言語に対して『共有渡し』を使うのにはなんとなく躊躇する。メモリ領域を共有しているには違いないけど、なんかもう少し低レイヤな感じなので。

あくまでも値渡し＋参照渡し的な世界観で説明しようとする『参照の値渡し』と、オブジェクトが呼び出し元・先で「共有」されるという現象を重視する『共有渡し』

　同じ現象でも見方が違うのだと思う。

　この違いは意外と効いてきて、前者の立場を取るとJavaは「基本的に値渡し。プリミティブ型はそのまま値で渡るが、それ以外はアドレスの値が渡る」と値渡し的な世界観で説明できるが、後者の立場を取ると「プリミティブ型の値渡し、配列の『参照の値渡し』、オブジェクトの『共有渡し』の折衷」という苦しい説明にせざるを得ないと思う（配列に対して『共有渡し』の言葉を使うことを許すなら、真ん中は削れるけど）。Java使いの人たちが「Javaは値渡し！」と主張したがるのは、つまるところそういうことだろう*3。

　逆にpythonやrubyのような「すべてがオブジェクト」な言語では、プリミティブ型やら何やらのことは考える必要はなく、また言語仕様の表面で参照の値（要するにアドレス）が見えてくる訳でもないので、『共有渡し』の方がすっきりすると思う。

認知度とか言葉としての良し悪し

　なんか、どっちもどっちという気がする。
　単純な好みの問題だと思うけど強いて選ぶとすれば、国際的に（一応は）通用するであろうこと、言葉の良し悪しについて議論の余地が少ない*4ことから、共有渡しの方が筋は良さそう

　まあ、個人的には『共有渡し』の方がスッキリするし、好きです。でも、『参照の値渡し』が絶対に駄目かというと・・・難しいです。呼び方の問題は厄介。

まとめ

　ややこしくない（動作としてはよくわかる）けど、ややこしい（名前がうまく決められない）話だよね。

続き

　某所でこの問題が再燃していたので、続きを書いた。

www.haya-programming.com

*1:念のため書いておくと、「渡し」に対応するのは「Pass by」、「Call by」は「呼び出し」に対応するのだが、どちらにせよ意味は大して変わらないのでどちらで訳しても問題はない。この記事では日本語圏で一般的な「渡し」で統一している

*2:筆者はこれが何なのかはよくわからないが

*3:個人的には「Cみたいに明示的にアドレス渡す訳でもないのに値渡しって呼ぶのは逆説的でわかりづらいよ」と思うのだが、そのコストに勝るメリットがあるとする考えなのだろう

*4:というか議論になっていない程度に流行っていないだけかも・・・

VMware Playerでキャッシュを削除して仮想ディスクの容量を空ける（linux）

2018-05-29T21:54:52+09:00

　VMware Playerはホストとゲスト間で、ドラッグ・アンド・ドロップやコピ・アンド・ペーストによってファイルを移動できる。

　便利な機能なのでつい頻繁に使ってしまうが、これは腹立たしいことにゲストの仮想ディスク上にキャッシュを生成する。

　そしてこのキャッシュはなぜか勝手に消えてくれないので、気がつくとかなりディスク容量を圧迫してたりする。

　その消し方を備忘録としてメモ。

~/.cache/vmware/drag_and_drop/をまるごと消す

　以上。他にやることは特にない。

　僕が使っているのはubuntuだけど、たぶんlinux系なら何でも同じ場所にあるんだと思う（未確認）。もしかしたらVMware Playerのバージョンによっては場所が違うとかあるかもしれないけど、そのときはvmwareって名前の付いたディレクトリを検索すれば出てくると思う。

　放って置くとどんどん大きくなるので、たまに消してあげよう。これは仮想ディスクがいっぱいになっちゃった！　というとき、とりあえず容量を空ける方法としても役に立つ。

有意水準5%の論文が100本あったら

2018-05-12T17:49:59+09:00

　この記事は思いついたままに書いたポエム。

　有意水準5%とは、その判断（主張）の妥当性が95%である、ということを意味する。

　よって、有意水準5%で検定したら、100回に5回は第1種の過誤を犯す。

　有意水準5%の論文が100本あったら、（いちおうすべての論文が正しいプロセスを踏んでいると仮定しても）うち5本は間違っている。

　恐らく現実の論文はそんなに酷いことにはなっていないと思う（ただし、100本あったらそもそもプロセスが正しくないものは一定数入ってくるだろうけど）。これがどういうことなのかというと、

そもそも5%なんて甘い有意水準は使っていない（これはあると思うけど、とりあえず無視することにする）
最初からある程度有力な仮説を立てて検証しているので、95%に「仮説の妥当性」がかかってくると考えられる（ちょっと異論もあるかもしれないが、「ある仮説を妥当だと思って検証し、けっきょく妥当ではなかったという事象の可能性」を考えるとけっきょく効いてくると思われる）
論文に発表した以外にも色々実験をしたりして、妥当性を判断している。一回検定しただけ、というのは考えづらい（逆に言えば、再現が難しい話（世の中から取ってきた統計量をそのまま使うような奴）だと5%は割とそのまま5%かもしれないので、注意が必要）

　恐らくこのような事情が絡んでくるので、有意水準5%の妥当性は実際には98%とか99%とか、それぐらいには信頼できるように（個人的には）思える*1。

*1:だからって98%とか99%でも割ときつい水準だと思うので、これ以上緩める理由はないと思うが

【python】# coding: utf-8はもうやめる

2018-04-23T16:31:59+09:00

　pythonのプログラムは先頭行（あるいはシェバンの次の二行目）でファイルの文字コードを指定することができます。エンコーディング宣言といいます。

　こんなのとか

# coding: UTF-8

　こういうのもありますね。これはemacsに自動認識させるための書式らしい*1。

# -*- coding: utf-8 -*-

　これをずっと書いてたんだけど、PEP8を読んでいたらこんな記述に気づきました。

ASCII (Python 2) や UTF-8 (Python 3) を使用しているファイルにはエンコーディング宣言を入れるべきではありません。

はじめに — pep8-ja 1.0 ドキュメント

　えぇぇぇぇ！？　と思ったんだけど、何回読み直しても「デフォルトエンコーディング使うならエンコーディング宣言は書くなよ！」と書いてあるようにしか読めない。

　デフォルトエンコーディングを使うなら不要なのは知っていたけど、コーディング規約で非推奨にされてたのですね・・・。

　ということで、「PEP8に準拠しろよ！」というのはpython使いの常識なので（本当か？）、そして私はpython3しか書かないので、個人的には今後コーディング宣言は使わないことにしました。シェバンも必要に迫られない限りは書かない人間なので、今後私のプログラムは一行目からimportで始まることに。・・・ちょっと寂しい気もするけど、すっきりはする。

　「入れるべきではない」とまで言い切っているのは少し不思議な感じはするけど、不要なものをわざわざ書けというよりは良いのかもしれませんね。

*1:そのくせemacs使いの僕は面倒くさくて上ので済ませてきたんだけど

雑記 - 静かなる名辞

ブログで直帰率が高いことは問題ではない。満足して帰っていれば

はじめに

どうして直帰率が高いんだ！

どのみち直帰する？

だから、直帰率のこととか気にしなくていいと思うよ

ユーザ満足度はgoogleアナリティクスでは測れない

それでも直帰率を下げたい

まとめ

記事の寿命から考える、1記事で1日に得るべきPVとブログの収益性

はじめに

未来永劫PVを稼げて広告を貼り続けられるなら、いつかはペイする

記事の寿命は3年程度

PVの単価を考えると1PV 0.15円くらい

記事に費やした労力をお金に換算すると平均437円くらい

437円を3年で稼ぐには一日3PV必要

ただし稼げるとは一言も言っていない

まとめ

ブログのSearch Consoleでの平均CTRや平均掲載順位が下がるのはオッケー。クリック数と表示回数が大切

はじめに

いろんなクエリに低い順位で引っかかるようになった

検索に現れすらしなかった記事が評価されるようになった

上の下というポジションの記事が増えるとこうなる

クリック数と表示回数の絶対数は重要

まとめ

ロジスティック回帰が線形分離不可能な分類問題を解けないことの説明

はじめに

y=0.5を代入すればいい

非線形の問題も解く方法

コサイン距離は距離じゃないんだから、勘違いしないでよねっ！

き、記事タイトルに意味なんてないんだからねっ！

コサイン類似度のことくらい自分で調べなさいっ！

距離の定義を知らないの？ しょ、しょうがないから教えてあげるわ

わからないの？ ……ばか

距離として扱うと困るのかって？ ……困るに決まってるじゃないっ、わからずや！

「じゃあどう呼べば良いのか」って？ そんなの自分で考えてよね！

わかったなら感謝しなさい。……え、ありがとう？ べ、べつに喜ばれても嬉しくなかんないんだからっ！

AIでプログラマーが失業するとか、気にしなくていいと思うよ

はじめに

AIの定義は時代とともに移り変わる

これつでに技術革新で消滅した職業

AIの水準はそのレベルに達しているか：まだ無理

プログラマーっていってもけっこう難しいことをしている

プログラマーを代替できる水準のAIが作れるなら、プログラマーに限らず色々な職業が消滅する

まとめ

今あえて書く、目的別Pythonを使うメリット・デメリット

はじめに

Web

いわゆる「アプリケーション」（スマホアプリ、PCのデスクトップアプリケーションなど）。あるいはゲームなど

スクレイピング・チャットbotなど

プログラミング初心者の学習用

データサイエンス・機械学習・深層学習・その他の科学技術計算分野

データサイエンス

機械学習

深層学習

その他科学技術計算

画像処理

音声処理

自然言語処理

シミュレーションとか数値解析とかスパコンで走らせるようなやつ

その他の考慮事項

言語仕様など

インターネット情報

環境構築の容易さ

まとめ

はてなブログで自動生成されるゴミページをnoindexにする

teratailでのプログラミング初心者の質問の仕方

はじめに

どんなところなの？

どれくらい流行ってるの？

そもそも初心者が質問していいの？

なんでも聞いていいの？

気軽に質問していいの？

回答者はなんでわざわざ回答してるの？

使う上でのマナー

質問する前に自力で解決できないか頑張る

最低限Markdownを使いこなす

コードはコードブロックの中に入れる

「文章中のコード」機能を使う

見出しや水平線など

距離の定義を知らないの？　しょ、しょうがないから教えてあげるわ

わからないの？　……ばか

距離として扱うと困るのかって？　……困るに決まってるじゃないっ、わからずや！

「じゃあどう呼べば良いのか」って？　そんなの自分で考えてよね！

わかったなら感謝しなさい。……え、ありがとう？　べ、べつに喜ばれても嬉しくなかんないんだからっ！

emacsでpythonを書くための設定　2019年版

TechAcademy盗用事件　公式発表と深まる疑念

『■ご指摘に対する時系列の対応について』について

『■今回の問題とその原因』について

『■今後の対策』について