へっぽこびんぼう野郎のnewbie日記

けろけーろ(´・ω・`)! #vZkt8fc6J

JSON-LDとはなにものか。その概要について(プログラマ側)

概要

JSON-LDでググるSEOの話ばっかり出てくるので、プログラマ視点で説明してみる

必要知識

JSON-LDとは

どう厳しくなったのか

次のように、データの意味まで考えて記述しないとエラーになるようになった。

エラーの様子はここで確認できる→ 構造化データ テストツール

↓は正常なやつ

<script type="application/ld+json">
{
  "@type": "Person",
  "name": "Yamada"
}
</script>

↓これはエラー

<script type="application/ld+json">
{
  "@type": 42,
  "name": "Yamada"
}
</script>

こうすることで、データの構造化(つまりデータの意味付け)が簡単になる。

ボキャブラ

データの構造化の規格のこと。

データの構造化っていってもみんな適当に自分の好きなように構造化できるので、じゃあそれ規格化しようということで偉い人がつくってくれた。

たとえばJSON-LDだけだと、 @type"Onigiri" って名前にしようっていうのもできるけど、それ他の人は毎回その構造はどういう構造なのかっていうのを見て考えないといけないから不便じゃね?統一したくね?ってこと

そうやって統一したものをボキャブラリという。日本語で言うと 語彙

ボキャブラリの1つに、 schema.org っていう規格がある。URLっぽくなってるのは、規格の名称をURLにしておくと何かと便利だからなってるっぽい。

基本的にボキャブラリの主流は schema.org っていうやつらしい。他はとりあえず必要無ければ知らなくていい。ぼくは知らん。

scheme じゃないことに注意。 eじゃなくてa

シンタックス

この場合のシンタックスというのは、構造化されたデータを書くときの、書き方のルールのこと。

JSON-LDシンタックスの1つ。

他にRDFa, microdataがある。どっちもHTMLのシンタックスを厳しくした版。

↓はmicrodataの例

<p itemscope>I’m going to the
  <span itemprop="name">Salter Cane</span>
gig next week. Excited!</p>

つらい。XMLHttpRequestのつらさよりつらい。

schema.orgjson-ldを組み合わせた書き方

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "Corporation",
  "name": "ぼくの会社",
  "telephone": "090-1234-5678",
  "url": "http://www.example.jp"
}
</script>

schema.org → 規格化されてるのでいちいち自分でどういう構造化すればいいか考えなくてよくて便利。

json-ldJSONシンタックスで構造化されたデータを書けるから便利。

そんなかんじ

まとめ

データの構造化
・ボキャブラリ
 ・schema.org
・シンタックス
 ・JSON-LD
 ・RDFa
 ・microdata

Django REST FrameworkでModelSerializer.to_representationが遅すぎる場合にやること(雑な調べ方)

APIのレスポンスタイムが2秒以上になってしまっていたので原因を発見するためにプロファイルしていた。

普段はどこが遅いのかを特定するときはline_profilerを使っているのだが、これにじゃっかん限界があって見にくくなっていたので、直接ライブラリのソースを読んで勝手に手を入れることにした。このline_profilerをDjangoで使用する方法についてはそのうち別記するつもり。

rest_frameworkのバージョンは3.3.3(ちょっと古い)

調べ方

rest_framework/fields.pyを直接編集する。

このへんにある、to_representationを触ってみる。ぼくの場合は今回SerializerMethodFieldが遅いことがわかっていたので↓のメソッドを次のように変更した。

    def to_representation(self, value):
        method = getattr(self.parent, self.method_name)
        return method(value)

 ↓

    def to_representation(self, value):
        import pickle, time
        loaded = pickle.load(open('repr.dump', 'rb'))
        parent_name = self.parent.__class__.__name__
        data = loaded.get((parent_name, self.method_name), {'count': 0, 'time': 0})

        start = time.time()
        method = getattr(self.parent, self.method_name)
        v = method(value)
        end = time.time()
        elapsed = end - start
        data['count'] += 1
        data['time'] += elapsed
        loaded[(parent_name, self.method_name)] = data
        pickle.dump(loaded, open('repr.dump', 'wb'))
        return v

こんな感じでプロファイルすると↓のようなデータが取得できる。

>>> import pickle
>>> from pprint import pprint
>>> sorted_data = sorted(pickle.load(open('repr.dump', 'rb')), lambda x: x[1]['time'])
>>> pprint(sorted_data)
[(('HomeReviewSerializer', 'get_type_name'),
  {'count': 1, 'time': 2.6464462280273438e-05}),
 (('HomeReviewSerializer', 'get_type'),
  {'count': 1, 'time': 4.1961669921875e-05}),
 (('OtherFunctionSerializer', 'get_admin_email'),
  {'count': 1, 'time': 5.412101745605469e-05}),
 (('HomePostSerializer', 'get_type_name'),
  {'count': 4, 'time': 8.440017700195312e-05}),
 (('HomePostSerializer', 'get_type'),
  {'count': 4, 'time': 0.00011730194091796875}),
 (('HomePointSerializer', 'get_type'),
  {'count': 4, 'time': 0.00012302398681640625}),
 (('HomePointSerializer', 'get_type_name'),
  {'count': 4, 'time': 0.00015425682067871094}),
 (('HomeCardCommentSerializer', 'get_type'),
  {'count': 6, 'time': 0.00028586387634277344}),
〜〜〜
〜〜〜

遅い箇所がわかって便利。 そのうちやり方を洗練させたらまたアップデートする。

基本的に、APIで返すときにrest_framework.reversereverseを使うと遅くなる印象がある。

1つ使うだけで0.03秒ほど遅くなる感じ。データベースにアクセスしているわけでもないのにこの遅さになるのはあんまり好ましくない。

バージョンをあげたら直るのだろうか……?

【追記】

べんりなKaeruProfilerなるものを作った。

github.com

$ pip install kaeruprofiler でインストールできる。使い方は example.py とソースをよんでほしい

まだ改良の余地あるのでバージョンは0.0.6

High Sierra(10.13) + iTerm2 + tmux(2.5)でコピペできない問題について

はじめに

調べても、バージョンがめちゃくちゃなのでつらかった。 とりあえずこれが現状最新(2017/10/04)

やりかた

$ brew install reattach-to-user-namespace pbcopy

でインストールする。なんかのラッパーらしい。

.tmux.conf に次のものを書く。

bind-key -Tcopy-mode-vi 'y' send -X copy-pipe "reattach-to-user-namespace pbcopy"
set-option -g default-command "reattach-to-user-namespace -l zsh"

上のやつは、viモードでy押したときにコピーできるかどうかのやつ

こうするとなおる。

なぜ直るかは知らない。詳しく調べたくない。

Resolving AttributeError: 'FlakesChecker' object has no attribute 'JOINEDSTR' on flake8

Error

Traceback (most recent call last):
  File "/root/.pyenv/versions/3.6.1/bin/flake8", line 11, in <module>
    sys.exit(main())
  File "/root/.pyenv/versions/3.6.1/lib/python3.6/site-packages/flake8/main.py", line 33, in main
    report = flake8_style.check_files()
  File "/root/.pyenv/versions/3.6.1/lib/python3.6/site-packages/flake8/engine.py", line 181, in check_files
    return self._retry_serial(self._styleguide.check_files, paths=paths)
  File "/root/.pyenv/versions/3.6.1/lib/python3.6/site-packages/flake8/engine.py", line 172, in _retry_serial
    return func(*args, **kwargs)
  File "/root/.pyenv/versions/3.6.1/lib/python3.6/site-packages/pep8.py", line 1840, in check_files
    self.input_dir(path)
  File "/root/.pyenv/versions/3.6.1/lib/python3.6/site-packages/pep8.py", line 1876, in input_dir
    runner(os.path.join(root, filename))
  File "/root/.pyenv/versions/3.6.1/lib/python3.6/site-packages/flake8/engine.py", line 126, in input_file
    return fchecker.check_all(expected=expected, line_offset=line_offset)
  File "/root/.pyenv/versions/3.6.1/lib/python3.6/site-packages/pep8.py", line 1574, in check_all
    self.check_ast()
  File "/root/.pyenv/versions/3.6.1/lib/python3.6/site-packages/pep8.py", line 1520, in check_ast
    checker = cls(tree, self.filename)
  File "/root/.pyenv/versions/3.6.1/lib/python3.6/site-packages/flake8/_pyflakes.py", line 62, in __init__
    withDoctest=withDoctest)
  File "/root/.pyenv/versions/3.6.1/lib/python3.6/site-packages/pyflakes/checker.py", line 295, in __init__
    self.runDeferred(self._deferredFunctions)
  File "/root/.pyenv/versions/3.6.1/lib/python3.6/site-packages/pyflakes/checker.py", line 332, in runDeferred
    handler()
  File "/root/.pyenv/versions/3.6.1/lib/python3.6/site-packages/pyflakes/checker.py", line 823, in runFunction
    self.handleNode(stmt, node)
  File "/root/.pyenv/versions/3.6.1/lib/python3.6/site-packages/pyflakes/checker.py", line 609, in handleNode
    handler(node)
  File "/root/.pyenv/versions/3.6.1/lib/python3.6/site-packages/pyflakes/checker.py", line 567, in handleChildren
    self.handleNode(node, tree)
  File "/root/.pyenv/versions/3.6.1/lib/python3.6/site-packages/pyflakes/checker.py", line 609, in handleNode
    handler(node)
  File "/root/.pyenv/versions/3.6.1/lib/python3.6/site-packages/pyflakes/checker.py", line 567, in handleChildren
    self.handleNode(node, tree)
  File "/root/.pyenv/versions/3.6.1/lib/python3.6/site-packages/pyflakes/checker.py", line 608, in handleNode
    handler = self.getNodeHandler(node.__class__)
  File "/root/.pyenv/versions/3.6.1/lib/python3.6/site-packages/pyflakes/checker.py", line 462, in getNodeHandler
    self._nodeHandlers[node_class] = handler = getattr(self, nodeType)
AttributeError: 'FlakesChecker' object has no attribute 'JOINEDSTR'

How to resolve

You probably use f"{foo}" syntax and older flake8. So update to latest flake8.

WiFi経由でネットに接続しようとしたときに、SSIDが見つからなかったのでやったこと(Windows)

現象

Mac OS Xからはアクセスポイントに接続できるのに、Windows10からだとそもそもアクセスポイント(SSID)が見つからない。
iPhoneKindleからは接続できるので、
おそらく Windows10・Windows10を入れているPCやネットワークインタフェース・ルータ 周りが問題だろうとあたりをつけていろいろと試した。

結果としてはうまく動き出した。

Windows10を入れているマシンはLazer Blade Stealth。

試したけどダメだったこと

  • Windows10 再起動
  • ルータ 再起動
  • Windows10でデバイスマネージャを開き、ネットワークアダプタを削除(削除しても再起動すれば再度インストールされる)

人によってはうまくいくと思う。

成功したこと

  • ルータで、WiFiのチャンネル設定を自動から1に変えてみた(電波の周波数をかえる)

所見

たぶん人によっては1では動かなくて3とかで動いたとかあると思う。このへんは電波干渉とかいろいろあるらしいのでよくわからない。とりあえずチャンネルは1か6か11にするといいみたい。
(チャンネルっていうのは、テレビやラジオのチャンネルとおなじで、周波数変えてるだけ)

Macとかではネットできるので、
電波は来てるけどノイズが酷くてLazer Bladeに入ってた受信機では検出できなかったとかそんな感じだろうか。
無線LANの子機買ってきてLazer Bladeにつけたらたぶん問題なくなりそう。

「どうやってわかりにくい文章に立ち向かうか」の備忘録(わかりにくい文章の読み方)

はじめに

世の中には大量のわかりにくい文章があって、そしてそれをどうしても読まなければいけないときがある。

にも関わらず、「わかりにくい文章」でググると、「わかりにくい文章はわかりにくいよね〜」「わかりにくい文章書くやつはダメなやつ!」「このようにわかりやすく書きましょう」という結論で閉じられていることが多い。

確かにそれはそうなんだが、それは自分が気をつけるもので、人に強要できるものではない。

そこで、その読み方を書いた。

わかりにくい文章

わかりにくい文章の特徴はおおむね以下のようだとぼくは勝手に思ってる。

  • 文の意味をいろんなふうに取れる
  • 論理展開・起承転結がおかしい
  • 「てにをは」等、助詞の使い方が間違っている
  • 知らない用語が前置きなく急に出現する
  • 文構造がマジキチ
  • 読み手のことをあまり考えていないオナニー文
  • 誤字脱字が激しい
  • 冗長
  • 余談・無関係な話が多い

この記事では、こういった特徴を持つ文章に対してぼくが実践している策略みたいなものをつらつらと書いていく。 自分用に備忘録として書いているので、そのうち気が向いたら更新するかもしれない。

「わからない」 と思っていることに気付く

文章を読んでいる際に、「よくわからない」といういや〜な感覚が襲ってきたら、「あ、自分、よくわかってないぞ!」ということを認知する。

実は、「わからない〜わからない〜」って言っているときは「自分、わかっていない!」ということに気づけていない。

こういうときは「つらい〜つらい〜」が先行していて、「わからない」とか言いつつもわかろうとしたいわけじゃなくて、つらい気持ちから脱出したいだけなのだ。

だから、もっと深呼吸して冷静な気持ちになって「お???わかってないのか!!!!!!!つらい!!」と前向きな気持ちでわからないことを認識するのがだいじ。

まず「わからない」ことが認知できないと、「自分がわかってないということすら知り得ない」状態に陥っていることになる。

認知することによって、「どうやら自分はこれがわからないらしい!」と客観的に評価することができる。

とりあえずわからなくても読み進めてみる

わからないなりに、とりあえず読み進めてみることは重要だ。

『「わからん」と思って投げ出そうとしたら、次の行に解説があった!』なんてこともある。

100%の理解をせず、とりあえず読み進めてみることで、体系的に知識を得ることができて、もう1度読んだときに理解できることもある。

なにがわからないのか分析してみる

わからないと思っている文章を分析してみる。

なぜ文の意味がわからないのか、どこの単語が意味不明なのか、文脈から判断してみるとか、そもそも文の構造がおかしいのかとか。

どこからわからなくなったのか戻ってみる

いまわからない原因は、いま表面化しただけであって、実際には、わからない箇所は「わかったと思いこんでいる箇所」だったという可能性すらある。

特に、「何がわからないかわからない」ようなときは、「わかったと思っているが実際はわかっていないこと」がある場合や「わからなくてもいいと判断して読み進めた」場合などに多い(個人的に)

一度立ち返って見てみると、「『わかってなかったんだ!』ということを知る」こともある。

筆者も実はそれほどわかってないことがある

いままで平易な文章だったのに、あるときから急激に難しくなった場合、筆者がごまかしを入れている場合もある。

この場合「筆者はそう考えているようだ」と考えて「筆者の考え方」を取り入れるようにシフトすると「わからないけどそうなんだね」となり、わからなくても読めるようになる。

わからないことがカバーされていなかったり省略されている

「なんでそうなるの?」と思ったことが、かなり核心をついていたり、難しいことだったために簡略化されていたり、本の中で情報が網羅されていなかったり、未解決問題だったりすることがある。

ものごとを簡単に説明するためにいろいろと詳細な情報を削った結果、若干不自然な部分が生まれることがある。

そういう部分に鋭い関心を抱くことはいいのだが、前に進めなくなるので「不思議だな」と考えたりするといい。

前提知識が足りていない

読むのに必要な知識が足りていないせいで、読むことが困難になっている。

読者のレベルを高く設定しているために、知識がないと読み進めることができない。

「何を前提知識として求められているのか」を調べる必要がある。

たいていの文章には、「何が前提知識なのか」は書かれていない。

たとえばこの記事は、最低でも中学3年生程度の読解力(特に漢字)を必要としているが、こう書かれるまでこういった暗黙的な前提知識は認知できない。

(ここまで読める人には『当然』の知識でも、ここまで読めない人にはこの記事自体が『難しい』知識である)

筆者を信用する

筆者を疑うと、その後すべての文章に対して疑心暗鬼になる。

いかに疑った場合でも、ひとまず筆者をリスペクトして、「筆者はそう考えていて、その考えを取り入れよう」とすることが肝要。

中にはそれでも酷い文章もあるが、とりあえず第一として、人を信用することが大事。

筆者がうんこすぎる

💩

わかりにくい文章への立ち向かい方の具体的な例1

たとえば以下の文章は、

どうにかして欲しい。お役所の文章は何故わかりにくいのか - エキレビ!(1/2)

にて、「わかりにくい」として引用されているのだが、実際には「わかりにくい」というよりも、「より具体的に説明するため、あるいはカッコよく見せるために専門用語を使用している」のだと思う。

インターネット黎明期の1996年に創業。日本で初めてISP向けにカード決済を利用した「RTSシステム」を開発して以来、電子商取引(EC)にフォーカスし、アプリケーションパッケージの開発、コンサルティングを行ってきた。特にECサイトのバックオフィスを支えるパッケージソフトの開発やライセンス事業、ソリューションに特化し高機能を実現。いわゆるデファクトスタンダード…

もちろんカタカナによって、じゃっかん曖昧にされている部分もあるとは思うし、「カタカナばかりでうさんくさい」と思う気持ちもわかるけど、

多くの人は「ISPRTSシステム?EC?アプリケーションパッケージ?バックオフィス?パッケージソフト?ライセンス事業?ソリューション?デファクトスタンダード?」と、文に意味不明な用語が含まれまくっているので、「わかりにくい」のだと思う。いわゆる前提知識が足りていない状態で、想定されている読者の範囲外だったというわけ。

ひょっとしたら「黎明期・カード決済・フォーカス・コンサルティング」等もわからない人がいるかもしれない。

ひとまずこういう文を見かけたら、知らない単語に印をつけてみる。

そうすると「あ、こんだけ知らないのか。それは読めないわ」となる。

わかりにくい文章への立ち向かい方の具体的な例2

これは「おはなしの記憶」という小学校受験に使われている問題らしい。(「話の記憶が苦手」を克服するには [小学校受験] All Aboutから引用)

森の動物たちがかけっこをするのであつまってきました。はじめにウサギさんがやってきました。2番目にゾウさんがきました。そのつぎにネズミさんがきました。最後にライオンさんがやってきて、「キツネさんとパンダさんはお腹をこわしてお家で寝ている」と言いました。

ブタさんが「ようい、どん!」と合図をすると残りの動物たちが走り出し、ウサギさん、ライオンさん、ゾウさんの順にゴールしました。ウサギさんが「ぼくライオンさんに勝てるとは思わなかったよ」と言ったので、みんなが笑いました

これを耳で聞いて、その後次のような問題を出されるようだ。

■絵を見てかけっこで走らなかった動物に○をつけましょう
■絵を見てかけっこで2番目にゴールした動物に△をつけましょう。

これは専門用語も何もない文章だけど、記憶したりイメージしたりできないと大人も普通に間違える文章だと思う。 しかもこれにアレンジを加えて、論理関係をイメージさせにくくしたり、初見の単語を多くすると、より難しくなる。

海の動物たちが競争をするために集合しました。はじめにイタチザメさんがやってきました。2番目にヒラシュモクザメさんがきました。そのつぎにマオナガさんがきました。最後にオンデンザメさんがやってきて、「ジンベイザメさんは腫瘍で、クロカジキさんは結核で死んでいる」と言いました。

シロナガスクジラさんが「ようい、どん!」と合図をすると残りの動物たちが走り出し、イタチザメさん、マオナガさん、ヒラシュモクザメさんの順にゴールしました。イタチザメさんが「ぼくマオナガさんに勝てるとは思わなかったよ」と言ったので、みんなが虚仮にしました

初見の単語が多いだけで、だいぶ難しくなったと思う。自分で書いておきながら読む気になれない。

ふつうの人はサメの種類なんてどうでもいいし、腫瘍や結核にも親近感はあまりないと思う。しかもそれは具体的にはなんなのか、どう違うのか、なかなか説明がしにくい。

なので、記憶がしにくく、結果的にわかりにくくなっているのだと思う。

これも「馴染み深い言葉」がないせいでわからなくなっているのだと考えて読めば、ただ読むのが億劫なだけで、わかりにくくはないはずだ。

わかりにくい文章への立ち向かい方の具体的な例3

次の文は、長すぎて分かりにくい文章は分ける :読みやすい文章 書き方のコツ | 書き方ができる人コムで例に挙げられている文だ。

人類がいかに進化した生き物であるかという問いには、これまであらゆる説明がされてきたが、まったく次元の違う説明をまとめようとしても、うまくまとまらないし、人類の遺伝子構造がどのような変化をたどってきたかが大切である。

これは実際わかりにくい。論理構造が曖昧だからだ。

綺麗に書くとこうなる。綺麗っていうか、ぼくが把握しやすいように文同士の接続を変えただけだけど。

人類がいかに進化した生き物であるかという問いにはこれまであらゆる説明がされてきたけど、そういうまったく次元の違う説明をまとめようとしてもうまくまとまらないし、やっぱり人類の遺伝子構造がどのような変化をたどってきたかの方が大切である。

こういうふうに自分が理解できるように言語を変換すれば、読みにくい文章でも読めるようになる。

わかりにくい文章への立ち向かい方の具体的な例4

次の文は文の種類とねじれ文が起こる仕組みからとったもので、これはねじれ文と呼ばれるらしい。

日本人にとって肉食の歴史は浅く、肉を食べると脂肪過多になり、また、砂糖や脂も摂りすぎており、肥満や生活習慣病を引き起こす原因になっています。
たんぱく質が多い食物は、牛肉、豚肉、鶏肉などの肉類、牛乳やチーズなどの乳製品、魚介類ではマグロやアジの開き、他の食品では大豆に多く含まれています。

これらの添削については、引用したサイトを見てほしいのだが、こういった文を見かけた際は、まず「論理展開が異常であること」を見抜いて、意味が通るように脳内で変更することが必要だ。(別に紙を使ってもいいけど)

「わからない!!」と唸っている間は、まず「文が異常であること」を見抜けていないことが多い。異常を検出して、そのあと正常に戻す作業が必要だ。

ちなみに、とりとめのない会話の中でこういう正常に戻す作業をしまくると人に嫌われるので注意。コミュニケーションと読解は違う。

わかりにくい文章への立ち向かい方の具体的な例5

これは量子暗号 - Wikipediaからの引用だ。さっきはじめて検索してみた。

量子暗号とは、通常は量子鍵配送のことを指す。完全な秘密通信は、伝送する情報の量と同じ長さの秘密鍵を送信者と受信者が共有することで初めて可能になる(ワンタイムパッドと呼ばれる方式を用いる)。この秘密鍵の共有を量子状態の特性によって実現し、通信路上の盗聴が検出できる。計算量的安全性でなく情報理論的安全性であることと、その実装の基礎が量子力学という物理学の基本法則に基づいていることが特徴である。なお、商用に広く用いられる公開鍵暗号は解読に計算時間が膨大にかかるだけ(計算量的安全性)であり、情報理論的に安全な秘密通信ではない。量子暗号は量子情報理論の、現在のところほぼ唯一の現実的な応用である。

これらを分解すると次のようになる。

  • 量子暗号は量子鍵配送のことを示す
  • 完全な秘密通信は秘密鍵を共有することで可能となる
  • 秘密鍵を「量子状態の特性」によって実現し、盗聴を検出できる
  • 計算量的安全性ではなく、情報理論的安全性であることが特徴
  • 情報理論的安全性の実装の基礎が、量子力学基本法則に基づいていることも特徴
  • 商用に広く用いられる公開鍵暗号は計算量的安全性(計算時間が多いだけ)である
  • 公開鍵暗号は、情報理論的には安全な秘密通信ではない。
  • 量子暗号は、量子情報理論の、唯一の現実的な応用

このようにすれば、「どこまでわかって、どこからわからないのか」が一目瞭然となり、「いまはわからなくてもいい箇所」まで浮き彫りにできる。

たとえば「量子鍵配送とはなにか?」と聞かれれば「量子暗号である」と答えても間違いではない。もしかすると厳密には違うのだろうが。

「どういうところが優れているのか?」と聞かれれば「公開鍵暗号よりも安全であるところ」と答えられる。

翻って、「量子状態の特性とはなにか?」「情報理論的安全性とはなにか?」「量子力学基本法則とはなにか?」と聞かれてもこの文からはわからない。

こういう「どこまでわかって、どこからわからないのか」という分解するプロセスが重要。

わかりにくい文章への立ち向かい方の具体的な例6

これはぼくが書いたオリジナルのクソ文章だ。

空で青いのにと言うが雨は降りませんが限りませんね。
特に山は天気からとても変わりやすかったのかも、朝快晴だけれども夕方からが土砂降りだろうことであります。
山登りするときがしっかりに対策はしながら、十分気がついてくれましょう。

ちなみにこれは「山登りするときは天気に気をつけましょう」という趣旨のものだ。

こういう文章は読む価値がないけれど、こんなのでも読まなければいけないときがある。

こういった文章では、細部に目をやると全然読めなくなる。助詞がめちゃくちゃ、文の繋がりとは何かを完全に無視したものである。

しかし助詞を無視することによって大意をつかむことができる。

  • 空 青い
  • 雨 降らない 限らない
  • 山 天気 変わりやすかった
  • 朝 快晴 夕方 土砂降り
  • 山登り とき しっかり 対策 十分

このように単語を羅列して、自分で助詞を補えば、完全に筆者の意図を汲み取れなくても、まあまあの理解を得ることができる。

これを踏まえてさきほどの文章を読むと、かなり読めるようになっているはずだ。

わかりにくい文章への立ち向かい方の具体的な例7

これもぼくのオリジナルの文だ。今度は助詞はしっかりあって機能しており、省くと逆にわけがわからなくなる文だ。

昨日僕は先生なんかが生徒にも教室だけで朝から本や雑誌などを読ませながら教えた授業の内容のみを妻へ息子と娘に家で最後くらいまで理解させるようにとしか言ってなかったのにやろうとすらしてくれなかったのでついに怒ってしまった。

こういった悪文も、やはり分解するに限る。

  • 昨日僕はついに怒ってしまった
  • (なぜか)妻へ息子と娘に家で最後くらいまで理解させるようにとしか言ってなかったのに、やろうとすらしてくれなかったから
  • (なにを理解させようとしたのか)先生なんかが生徒に教室だけで教えた授業の内容のみ【朝から本や雑誌などを読ませながら教えた】

まあこんな文を読まなければいけない状態が続くなら逃げた方が無難かもしれないけど、とにかく、酷い文でも気合さえあれば読めるのだ。

まとめ

基本的に「わからない」ことがあっても、「うーん! わからないなあ(´・ω・)?」と思うくらいのメンタルでいるといい。

「自分がわからないのはバカだからだ」のように考えてしまうのは、かなり早計と言わざるを得ない。

「わかろうとする」「いずれわかるものだ」「そのうちわかるだろ」「今は知識が足りていないからわからんのだ」「わかるわかる絶対わかる気持ちの問題だって」のように考えるのが良い。

「自分がわからないのはコイツがめちゃくちゃな説明をしているからだ」「自分がわからないのはコイツがマジキチだからだ」と考えたほうが精神衛生上とても良い。

それから「こんなものもわからないのかよwww」とか言ってくる輩は、だいたい性格がひん曲がっているので、そういうやつらにメンタルを吸い取られないようにする。だいたいそういうやつらも、しっかりとわかっているわけではない。

重要なのは「わかろうとする」ということで、「あきらめたらそこで試合終了だよ」とか「あきらめんなおまえ」とかそういう気持ちがだいじ。

上記の例も、結局のところ「頑張ってわかろうとした」「あきらめずに読もうとした」結果、わかるようになるのだ。

逆に「うわ、確かにこの例の文は読みにくいな……」とだけ思ってスルーした人にとっては、いまだよくわからないままだろう。

結果精神論なのだが、これは「あきらめなかった結果いいことあった」という訓練をひたすら積んでないとなかなか難しい。要は普段からさまざまな物事に対してあきらめないことがだいじ。

精神論だけじゃわかるわけもないので、ちゃんとわからないことを分析する。数学がわからないのに、分析を間違えて必死で歴史の勉強してもわかるようにはならない。

なぜわからないのか、なにが足りないのか、なにが邪魔しているのか、誰かに聞けばわかるのか、ひとまず保留するのか、ひたすら毎日考えるのか、いろんな手立てを試してみるとわかったりする。

まあまとめると「あきらめずにいろいろ考える」のが大事なわけで……大きく言うと身も蓋もない話だな(´・ω・`)

↓関連しそうな記事 heppoko.hatenadiary.jp

↓関連しそうな別サイトの記事 http://ja.uncyclopedia.info/wiki/%E8%AA%AD%E3%81%BF%E3%81%AB%E3%81%8F%E3%81%84%E6%96%87%E7%AB%A0

誤ってVagrantfile以下の.vagrantなどのディレクトリなどを削除してしまった場合にすること

状況

  • 誤ってVagrantfileがあるディクレトリにある .vagrant ディレクトリを削除してしまった
  • Vagrantで立てたVirtualBoxVMは残っている
  • しかしアクセスできない
  • あたらしく $ vagrant up しようとすると
A customization command failed:

["modifyvm", :id, "--memory", "3072", "--cpus", "2", "--name", "KaeruOldVM", "--natdnshostresolver1", "on", "--natdnsproxy1", "on", "--vram", "16"]

The following error was experienced:

#<Vagrant::Errors::VBoxManageError: There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["modifyvm", "c766d472-87d1-4b37-b826-80fe035ad257", "--memory", "3072", "--cpus", "2", "--name", "KaeruOldVM", "--natdnshostresolver1", "on", "--natdnsproxy1", "on", "--vram", "16"]

Stderr: VBoxManage: error: Could not rename the directory '/Users/usrNeko/VirtualBox VMs/ansible_default_1500964641566_30491' to '/Users/usrNeko/VirtualBox VMs/KaeruOldVM' to save the settings file (VERR_ALREADY_EXISTS)
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component SessionMachine, interface IMachine, callee nsISupports
VBoxManage: error: Context: "SaveSettings()" at line 3052 of file VBoxManageModifyVM.cpp
>

Please fix this customization and try again.

のようなエラーが出る

何がおこっているのか?

  • Vagrantは、通常 Vagrantfile.vagrant にある情報を見て動作するのだが、その .vagrant が消えてしまった。
  • .vagrant がないので、新たにVMを作ろうとした。
  • あたらしく作ろうとしたが、以前つくったVMと名前がダブっている。(VERR_ALREADY_EXISTS)
  • ダブっているのでRenameできなくてエラー

解決方法

注意

ホストマシンでのコマンドは % foo、ゲストマシンでのコマンドは $ fooで書きます

とりあえずsshでログインできるようにする

VirtualBoxVMは残っているので、まずVirtualBoxからログインする(パスワードは通常vagrantと入力すればログインできる)

$ cat ~/.ssh/authorized_keys で、以前の.vagrant下にあった秘密鍵と対応する公開鍵があるかどうか確認する。ないとおかしい。

もし対応する秘密鍵を既にもっているのなら、以下は不要なので、★★★の箇所まで移動してください。

公開鍵がわかったからといって、秘密鍵がわかるわけではないので、新しく鍵ペアを生成する。

ホストマシンで % ssh-keygen -t rsa をして、秘密鍵(id_rsa)と公開鍵(id_rsa.pub)を生成。

(※あたりまえだが、ゲストマシンでssh-keygenをしないこと。ゲストマシンでやると、秘密鍵を移動する必要が出てくる。公開鍵は別に誰かにバレても問題ではない。もちろんバレるよりかはバレない方がいいけど)

生成されたid_rsa.pub というファイル名をauthorized_keys に変更し、ゲストマシンの ~/.ssh/ 下に置く。 この段階ではホストマシンから接続できないと思うので、たとえばGithub等に公開鍵をあげておいて、ゲストマシンから $ git clone https://あなたのレポジトリ などのようにするのがオススメ。

うまくゲストマシンに ~/.ssh/authorized_keys として配置できたら、

$ chmod 600 ~/.ssh/authorized_keys

その後、 % vagrant ssh-config で出てくる

★★★

Host default
  HostName 127.0.0.1
  User vagrant
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile ~/.vagrant/machines/default/virtualbox/private_key
  IdentitiesOnly yes
  LogLevel FATAL
  ForwardAgent yes

の情報に、秘密鍵を紐付ける。

% mv ~/id_rsa ~/.vagrant/machines/default/virtualbox/private_key

のようにして、秘密鍵の情報を置き換えてやる。 % vagrant ssh-config 自体は動かないかもしれない。

これで接続できるようになった。

あとは~/.ssh/config に↑の情報を登録すれば、% ssh default でログインでき、[vagrant]$のようになるはず( ‘ω’)

バーチャルマシンへの向き先を以前のものに変更する

ログインできるようになったからといってもまだ解決はしていない。 今あるVagrantfileで生成されている.vagrantディレクトリには、バーチャルマシンの情報があるが、その情報が、新しいバーチャルマシンになっている。 これを既存のものに変更する。

% VBoxManage list vms すると、VirtualBoxでのバーチャルマシンの一覧が出る。 VBoxManageVirtualBoxをコントロールするコマンド。 このIdとかVboxManage コマンドをもとにVagrantはバーチャルマシンを管理・変更している。

↓さっきのエラー画面にもそう書いてある。

["modifyvm", :id, "--memory", "3072", "--cpus", "2", "--name", "KaeruOldVM", "--natdnshostresolver1", "on", "--natdnsproxy1", "on", "--vram", "16"]

The following error was experienced:

#<Vagrant::Errors::VBoxManageError: There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

ここで出てきた以前のバーチャルマシンのIDを、 % ~/.vagrant/machines/default/virtualbox/id に書き込む。 ちなみに書き込む前のidは、あたらしく作ったバーチャルマシンのIDになっているはず。

書き込み後、% vagrant reload でリロードする。 たぶんこれで動く。

わざわざ再プロビジョニングしなくてよくなって便利( ‘ω’)

今回特にググらなかったけど、解決した後でググったら結構いっぱい解決策あってびっくりした。