はてなキーワード: リファレンスとは
プログラミングができるわけでもない一般人だが書かれている内容はだいたい分かった。
なぜ「数字」にこだわるのかも分からないし唐突に現れたサンプルプログラムも意図が分からない。
ドレミファソラシは「261、293、329、349、391、440、493」
可視光の波長
コンピュータのディスプレイは波長ではなくRGBで表現されるので分かりづらい。
そんなよく分からないLEDを使わずともフルカラーLEDがある。
たとえにマイナーな電子部品(?)が登場すると逆に分かりづらい。
それから縦30x横30のLEDから縦70x横70のLEDまでに内接する円の内部(x^2+y^2≦40)がすべて色001であれば、赤い円ができる。
このあたりはよく分からない。
(「点と円の当たり判定」を各座標ごとに実行)
めちゃくちゃ強い電気
なんかすごそう(小並感)。
ハイレベルとローレベルでなくアナログ値になるということなのだろうか?
それはたぶん現代人ならみんな知ってると思う。
どの文字コードのことを言っているのか分からないので集中できない。
(ためしにASCIIコードを調べてみたがAは65だった。また小文字にするとき足す値は32)
かなりシンプルになることが多い。
一般的には適当なrandomモジュールのようなものを利用するのではないか?
(ついでに実用的かを考えるなら曲数が60以上あったときのことが気になる)
今の仕事でも、既存のマクロでエラー出たときに原因箇所を調べたりするのは出来るけど、そこから何を直したら直るのかわかんない。
フローチャートを作れるのなら元増田に必要なのは「ポケットリファレンス」とか「逆引き~」とかいう類の本ではないだろうか?
(普通に考えればさすがに知っているだろうが念のため)
https://anond.hatelabo.jp/20190328015628
この人が本物かどうかと聞かれたら、私は多分本物だろうと答える。多少フェイクは入れてるだろうけど。
なぜなら、少し似ているからだ。私と。
まあうちは普通のサラリーマン家庭なので、ブランドの話はよく分からないし、小学校は公立だし、大学は家から通える国立にしたけれど。でも、同じように御三家と呼ばれる女子校を出たものとして、その屈折した感情はある程度自分のものとして理解できる。彼女と同じ学校かは分からないが、多少の校風の違いはあろうとも御三家か、同偏差値帯の私立中の生徒の傾向は大まかに同じと言って良いと思う。彼彼女らを私立中に出荷するための生産拠点は等しくSAPIX、日能研等の大手中学受験塾だからだ。大手中学受験塾は大体3年間で2,300万円かかる。それぐらいの学費を払え、かつ子供の学習をサポート出来る家庭というのはおおよそ似通ったものになるのは想像に難くない。と、いうか大体似ていた。レアケースがあることも否定はしないけど。
私は医学部志望では無かったのでその辺の事情には明るくないが、医学部を目指す子はやはり親が医者のケースが圧倒的に多かったように思う。そして、医者になるという目的があるからか、中学の頃から鉄やSEGに通って着実に受験に備えていた子が多かった。これは素直に尊敬してた。まあそれと同時に、塾で医系数学とかの授業を取ったりする過程で、この人の周りが更に私立中高一貫医学部志望医者家庭へと純化されていってたんじゃないかなとは思う。
それはさておき、単純に私が少し似ているなと思った部分についてつらつら書きたい。
まずバイトについて。この部分でひょっとしたら他校かなとも思った。周りにバイトをする高校生は誰も居なかったのは同じだが、そもそも高校生がバイトをするという概念が現実感を伴っていなかったので、バイト禁止だったかどうかも分からない。禁止じゃ無かったとしても多分そんなに歓迎されなかっただろう。親も親でバイトするぐらいなら塾に行ってくれた方がいいと考えている人の方が多いのは確実だ。
次に、暗黙のルールについて。確かに、即物的なというか、実際の生活に関わる色々な数字は、同じ学校の生徒であるという点で=にされて不可視化されていたと思う。でも認知されていなかった訳でもなくて、ベールに覆われたように大まかには認識していたが、敢えて可視化しようとしなかっただけだろう。これは学校の態度の影響もあるかもしれない。私の知る限りでは、御三家には一斉に模試を受けて学校が偏差値を管理したり、成績を壁に貼りだしたりして、生徒同士の差を意識させる学校は無かった筈。加えて、これはこれで問題だと思うが、うちの学校では少なくない教師が受験だとか偏差値だとかをまるでハリポタの「ヴォルデモート卿」と同じような、ゾッとする単語として捉えていた。
最後に自己認識と世間一般との差について。これは同じような環境で成長した人達と接していると、気付かないし、別に気付かなくても生きていける。でも、自分と違った環境で育った他者と接する時に切実な問題として浮かび上がってくる。私も、世間ではエリートコースと呼ばれるだろう経歴にはなったが、別に自分のことは頭が良いとは思ってない。小学校の頃も塾では一番上のクラスの下の方で、中高では結局真ん中より上の成績を取れなかった。ずっと自分より上を見上げるばかりだった。
だから、大学で地方出身の「まっすぐ」育って来たんだろうなぁと感じられる子の万能感には相容れないものを感じる。万能感は自分の人生で真っ先に失われたものの1つだからかな。
あと、自己認識がどうであれ周りからは期待されちゃったりするからそのギャップが正直キツいというのはあるんじゃない。
まあ長文並び立てたけど単純にそれなと思っただけ。最初は共感した所だけ書いて去ろうと思ったけど思うところがあり過ぎて長くなってしまった。多分元記事の人はちゃんとガス抜きできる人だからしっかりとした医者になれると思うよ。
・STL標準講座
・Effective C++
・Modern Effective C++
・Effective STL
15年かけC++を独学した。
ずっと一人で努力し、風呂、トイレ、布団の中でも勉強し、プログラムを書いた。
基本情報処理、ソフトウェア開発者試験、ネットワークスペシャリストとデータベーススペシャリストを取得した。
しかし、正社員はもとより、時給2000円の派遣プログラマも時給1200円のアルバイトもスキル不足で何十社受けても一社も採用されない。
とはいえ、面接官のレベルは「STLなんて初めて聞いた」「gccて何かの会社?」
「C++の企画書(誤字ではない)を書いてる人なんてのがいるの?」
「じょーほーしょりしけんてのがあるの?外国の話?」
独身で、一切を我慢して娯楽を全く体験しないまま40歳になってしまった。IT業界の人間すべてが恨めしい。
貯金100万もなく、素人が書いたプログラムに対して手順書のとおりにマウスを操作してエクセルにテスト結果を書くだけの仕事ばかりしている。
https://twitter.com/crd_tweet/status/1075996340809719808
https://twitter.com/Sakai_Sampo/status/1075996738756866049
ま〜〜〜〜〜〜〜〜〜〜〜〜〜〜た出たよSFファンの「えっ!? この作品を知らない人がいるなんて!?」マウンティングが。腐臭がする。そういう態度とるくらいなんだからSF老害おじさんにおかれましては日本古典近代戦前文学は言うまでもなく英米仏西伊独南米東欧文学の名作は当然読んでるしアニメ漫画ゲームの有名処は全部触れてるんですよね? どんな人でも絶対に「あの有名どころを読んでいない」なんてこと当然あるに決まってるだろ。SFの業界人がSFの有名どころを読んでなかったらそうも言われても仕方ないかもしれないが、共同リファレンスみたいな一般市民が普通の司書さんに質問した程度の案件でなんだその態度は。大体そもそも多読が可能かどうかって個人個人の特性によることが大きいから名作を全部おさえるみたいなのってできるひととできないにとが明確に分かれるだろ。SF語るのに1000冊読んでいる必要はないって口では言いながらこういう事例ですぐマウンティングしてくるからSF老害は信用ならねえんだよ死ね。
iPhone XSとPixel 3が発表されて、どっちも高いなぁ、ヤベェなぁと僕は思うんだけど、「スマホが高くなったのではない、日本が貧しくなったのだ」という意見をよく見かける。
2011年の段階で、iPhone 4Sの64GBモデルが67,200円。一番安い16GBモデルが46,080円。
64GBモデルで比較するとiPhone XSが121,824円(税込)だから、7年で1.8倍高くなっている。
外国では、7年前に6万7千円を支払ったのと同じ金銭感覚で12万円を出せるってこと?
っていう結論を書くために、過去のiPhone、Googleのスマートフォンの価格を調べてみた。
過去どれだけ安いかが知りたかっただけなので、全部は調べていない。
64GB 121,824円
256GB 140,184円
512GB 165,024円
64GB 134,784円
256GB 153,144円
512GB 177,984円
16GB 46,080円
32GB 57,600円
64GB 67,200円
16GB 70,200円~72,576円 (docomo 72,576円 au 70,200円 SoftBank 70,080円)
32GB 79,920円~82,944円 (docomo 82,944円 au 79,920円 SoftBank 80,400円)
64GB 90,720円~93,312円 (docomo 93,312円 au 90,720円 SoftBank 90,720円)
2011年 67,200円
2011年にはiPhoneは安くて46,080円で手に入っていたので、最低スペックしか買わない貧乏人にとっては3倍近い価格になっており、超高く感じられる。
64GB 95,000円
128GB 107,000円
64GB 119,000円
128GB 131,000円
16GB 39,800円
32GB 44,800円
32GB 59,300円
64GB 63,400円
32GB 74,800円
64GB 80,800円
Googleのスマートフォンも、まず2013年~2015年で、32GBで比較して、
と高くなっており、2015年~2018年も、64GBでの比較で、
と価格が約1.5倍になっている。
Nexus 5は軽い気持ちで買ったけど、もはや遊び半分で買うには高すぎる。
リファレンス機は遊びじゃない。
http://b.hatena.ne.jp/entry/s/co3k.org/blog/why-do-you-use-jwt-for-session
と厳しい叱責を受けたため、無能の見識を書いてみた。
「聞くは一時の恥、聞かぬは一生の恥」のとおり、
せっかくの機会のため、びしばしセキュリティに関する認識の甘さを指摘してほしい所存
作ったシステムではexpは約1時間でやってしまいました(機密保持契約違反を恐れ多少ぼかしております)
確認している間に1時間はかかるからいいやと思ってしまっていた
師はきっとJWT生成直後3秒でユーザーが
と気づいて通報
そして師が2秒で
「これは、セッションハイジャックだ!」
と検知してセッション遮断、秒速で一億円の被害が出るところを阻止する前提なのではないかと推測している
これは確かにJWTだと厳しそうだ
セッションを任意に切れることに意味はないのでは、と思えてきたが、浅はかだろうか
(師はログインを即座に検知してセッションを切れるから問題ないのか)
とにかくアカウントロック機能を作れば上記の懸念全てにきれいに対応できそうに見えている
この理屈だと例えば.envに書くような他のkeyも定期的な交換が必要に見える
これはまずい、自分の今までの見識の甘さを思い知らされた
keyは初回に設定したのみで、定期的な交換を勧める文が見つからない
私の検索力不足なのかと思ったが、もしかして彼らもこの危険性に気付いていないのではないか
JWTはhash化してつないでいる前提で
解読時間は下記を参考に、計算はwindows10の電卓アプリを用いて手動で行った
https://ja.wikipedia.org/wiki/%E7%B7%8F%E5%BD%93%E3%81%9F%E3%82%8A%E6%94%BB%E6%92%83
英数字大文字小文字で約60の時は10桁で20万年と書いているが
現代の解析技術は20万倍は速度が出ると仮定して1年として計算する
日本語に直すと60京4661兆7600億年かかる計算となった
実際にはこれが6.0466176e+17倍されさらに3600倍されつまりどういうことだ
そもそも師は何年で交換したら安全と書いていないが、何年なら安全という意見だったのだろうか
私の理解ではとかくuser_idのみ必要なら意味がないと思っていたため落ち込んでいる
まず、IDとpassを内蔵するネイティブアプリに対するapiサーバでの実装経験しかないこと
JWTが切れたら都度IDとpassを投げる方向でリフレッシュトークンは実装しなかったことを告白しておく
そのためapiサーバで上記前提で用いた場合に考えたことを書く
webアプリのJWT実装経験はないので、そちらの論は差し控えさせていただく
では危険で
JWT送信→セッション(cookie形式?)送信切り替え→セッションからuser_id取得
とりあえず思いついたのは下記だった
tokenはheaderにbearerで付けユーザーID(あるいはそれに代わる特定可能な識別子)が含まれる
httpsで通信するのでパケットキャプチャによる傍受は不可能と思っていた
(httpで通信するのはJWTとかcookieとか関係なく傍受できるため考慮しない)
0に何をかけても0なので、何回送っても解読されないならJWTを何回送っても問題ない
というかJWTが抜けるなら同様にheaderに付けるcookieでも抜けると思うので
JWTだからといって危険性に差はない、という論拠により安全性は変わらないという個人的結論になった
※余談だが、たまに送る回数が少ない方が安全という
攻撃者がアプリに保存されたJWTが取得できるならIDもpassも同じ方法で抜けそうに見えた
(厳密には保存場所が違ったかもしれんが実装依存なので同一とする)
その前提のため、わざわざ
JWT送信→セッション(cookie形式?)送信→セッションからuser_id取得
で接続しても、おそらくcookie形式で送れる何かもJWTらと同じ方法で抜かれると思われる
つまりcookieだろうがJWTだろうがアプリから直接情報が抜かれる危険性には変わりがないという結論になった
つまりcookieだろうがjwtだろうがidとpasswordの組だろうが同じ危険性で抜かれる可能性があり、いずれでも同じことができるなら
JWT→user_id
でいいじゃん、わざわざcookieと同様の形式を間に挟むの無駄じゃん、となりコメントの発言に至った
ここまで書いて、常にJWTにsession_idを含めておいて送ることを意図されていた可能性にも気づいたが
セッションにするメリットとして唯一思いついているのは任意にサーバ側でセッションを切れることだが
それを指していたのであろうか
余談だが、ブコメの雰囲気に日和って「ユーザーIDのみ入れ」(そもそもJWTを自然に作れば入るのだが)
というセッションストア的にJWTに他の情報を入れると入れない時に比べて危険性があがることに同意したような記載をしてしまったが
結局JWTが奪えたら中身に関係なくbearerとしてセットして接続するだけなので
正直JWTを使った時点でついでにセッションストアのように使おうが使わまいがセキュリティ的にそこまで変わらないのでは、と思っている
強いて上げるならセッションに保存している内容が分かる可能性があり、サーバー内部の実装が推測できる危険があるくらいだろうか
でも暗号化したらよいのでは、と思った
expを適切に設定しつつ、必要ならアカウントロック機能を入れる
(アカウントロック機能はJWTに関係なく被害の増加を抑えられる可能性がある)
少なくともapiサーバ→ネイティブアプリに関して、セッションIDを含めても危険性は変わらない
正直webアプリでも大して変わらんのでは、と思っているのは内緒である
土日祝日なしのシフト制だが22時帰宅の毎日で技術に対する興味が薄れて労働マシーン化していた。
そんな時に Leaflet という面白そうなモノを見つけたWeb地図のためのJavaScriptライブラリらしい。
学生の頃にちょこちょこ記録していた美味しいお店リストや忙しくなる前に遊んでたMMOのデータを元にそのライブラリを使ってwebコテンツを作りたくなった。
15年ぶりに「とほほのJavaScriptリファレンス」を見た、今はさっと読んでいる段階だ、IT業界のSIerの下請けの事務処理や保守や問い合わせの対応マシーン化していた
自分にはプログラミング言語を触れたのは15年ぶりだった・・・まったくわからないが読んでいて楽しい。
この感覚は学生の頃によくあったが社会に出たらいつの間にか忘れて早く帰ることしか頭になかった。
有給や休日での代休は取ると元請けから睨まれ最悪、自分を含めた現場の技術者を外すして別の技術者に入れ替えるよう命じられるため休むことができなかったが久しぶりに取った土日の連休に
Leaflet と言うものを見てwebコテンツを作りたいなーと思ったときに頭の中で誰かが「もっと休もう、休んで自分のやりたいことを伸ばす時間を作ろう」という言葉を自分に掛けた。
休まないのは経営者ぐらいでいい労働者はもっと休むべきだ、今日で休日は終わり明日から忙しい日がまた始まる。
Leaflet と言うJavaScriptライブラリを使って作りたいものが出来たのだから、きっとこれは何かのチャンスに違いない。
たとえばC#など.NET系のリファレンスはMSDNで読むことができる。
RubyだってHaskellだってScalaだって、公式サイトにガイドぐらい置いてある。
Oracle、DB2、MySQL、PostgreSQL、SQLite、AccessなどSQLが実装されたDBMSは様々にあるが、どれを取っても仕様が違う。
皆が標準SQLに従っていてその上で適当に増設している程度ならよいが、もはや誰も標準SQLに従う気が無い。
根幹的に必要な機能があったりなかったりするから、あるDBMSで書けるようになったからと言ってSQLを覚えたとは言えない。
これと上記1とのせいで、何かググった時に特定のDBMSでしか解決法にならないものが大量に出てくる。
最近のプログラミング言語は大抵、雑に書いたってコンパイラが適当に最適化してくれる。
同じ結果を生むような二つのコードは、よほど下手くそに書かない限りは同じような実行速度になる。
SQLもオプティマイザが最適化はするが、ほぼ同じような二つのコードで速度が全く変わったりする。
そのため実行計画というオプティマイザの中間言語のようなものを読んであげて、
より速い中間言語が生成されるようSQLをチューニングし直さなければならない。
これでは何をやっているのかわからない。
有名なサイトでは、初心者が必死で書いたような可愛らしいSQLを「それでは遅すぎるんじゃ」とけちょんけちょんにけなし、
なんかシンプルなのだけれどよくわからない文法を一杯使って実行速度を高めたのを「正解」としていたりする。
しかもその文法、ググってもろくな解説が無かったり、特定のDBMSに依存してたりと使えないオチ。
上手い人はSQLを綺麗に書く。だけど、その綺麗さの基準が人によって違う。
エディタが単なるメモ帳でしかないようなDBMSも多いから、インデントの文字数さえ個々人に任される。
インデントは2文字か4文字か。SELECTで改行するかしないか。カンマは列の後ろか、前か。
いろいろなサイトに色々なことが書いてあったけれど、全部違うこと言ってた。
つまり各々綺麗に書ければいいやということであり、読むほうも宗教が違ってもまあ綺麗なら読めるから困りはしない。
何かの解決法をググるたびに違うスタイルだからどう書いていいのかわからない。
結局なんかいろいろな上手い人のスタイルをツギハギした新たなスタイルが世に誕生してしまうのだ。
吾輩は無職である。職はまだ無い。どこで無職になったか、とんと見当けんとうがつかぬ。
何でも薄暗いじめじめした所で手斧を投げられていた事だけは記憶している。
しかもあとで聞くとそれは増田という人間中で一番獰悪な種族であったそうだ。
・・・・
まぁ、前置きの冗談はこの辺までとして、前々から作りたいな思っていた
Webサービスを中々時間が取れず作るのを諦めていたのだけど、
僕自身、プログラミングを生業とする職業では無く、学生時代も特にプログラミングついて何か
始めたのが昨年末の大晦日ちょい前なので、約5ヶ月掛かり、当初想定していた期間より
かなりの時間が掛かってしまい、反省点等含めその辺の事を書けたらなと思います。
■やりたい事(実装した事)
・ゲームユーザー同士を繋げるマッチングサイト(出会い系ではないよ。)
・タグをつける
構成を書いた方が良いと思うので
以下になります。
■構成
--------------------------------------------
FW:Flask 1.0.2
ORM:SQLAlchemy 1.2.7
その他ツール等:Let's Encrypt/fail2ban/等々
--------------------------------------------
ほぼ、既存のベーシックなサーバーサイド側の制御のみです。(jsで非同期通信はしてます)
変えるのもなと思い、取り敢えず上記です。
■選定理由
Railsの名前を良く聞くのでRuby on Rails触ったのですが、
Railsには馴染めなかった(扱えなかった)ので
何かマイクロFWの方が良いのだろうと、Sinatraいこうか思いましたが
Railsの印象が強く残った為、Rubyは止めてPythonに移りました。
今度は初っ端からマイクロFWが良いだろうとFlaskのサンプルを試すと
比較的プログラミング初学者でも扱いやすく覚える事も少ないので、PythonとFlask
の組み合わせで決定。
(気軽にプログラムを書け、自分がイメージしている処理や制御を素直に実現できる点が
書いていて気持ちが良いです。まぁ分からない所も有りますが、そう思わせてくれる点
が良いです。モチベーション的に)
NginxとuWSGIの組み合わせはFlaskで検索すると一番でてくるのでこれに決定。
SQLite3 はマイクロFWだから軽めのDBでたぶん大丈夫だと思ったのでこれに決定
■開発概要
・まずPythonの開発環境を整えようとなり、WindowsにVagrantをインストールして
仮想マシンの環境構築。ゲストOSの中にPyenv等を入れPython環境構築
・上記構築後に取り敢えず小さなサンプルから作ろうとなり、簡単なCRUDをFlaskで行える様にしました。
これができた時は嬉しかったです
・上記が出来てから、本番の開発に移りCRUDをベースにひたすら肉付けていく
→ユーザー登録機能作成/ログイン機能作成/ユーザー情報表示/編集機能/チケット作成/及び編集/バリデーション
・細かいViewの調整とスマホ用のViewも作成(レスポンシブルでは無いので)
・本番用のさくらVPSに環境構築とセキュリティ用のツール導入とLet's Encryptでhttps化
■悩んだ点/反省点
・悩んだのがタグ機能周りになるとどうすればよいか、かなり悩みました。
結論を言うとToxi法を使用しましたのですがここにたどり着き、理解するのに結構時間がとられました。
また、実装したらしたで、今度はそのタグ機能を検索するとなると検索ワードが1つとは限らないので
クエリーを動的に生成する必要が有り、これも実装するのにかなり時間が掛かりました。
SQL文だけならば比較的すぐに検索でヒットしますが、それをSQLAlchemyでどう実現すれば良いか分からず
かなり時間が掛かりました。DB設計やSQLAlchemyの文法に自信は無いですねぇ。。
・1次情報のリファレンスからは情報得ることがほとんど出来ず(たまにはできたが)、
Stack OverflowとQiitaと個人ブログが無ければこのサイトできなかったので
■総評
・5ヶ月と時間が掛かりまた反省点も多々有るが、とりあえずサービス公開まで
もっていけた事が嬉しいです。ただただ嬉しい。
・FlaskとSQLAlchemyの情報が日本語が少ないので公式リファレンスとStack Overflowを
行ったり来たりしたおかげで英語アレルギーがそこまで無くなった。
■成果物
オンラインゲーマー向け(e-sports)のマッチングサイトになります。
名前が安直で小学生が5秒で考えたような名前ですが、安直で気に入っています。
作った理由は、僕はBF1が好きなのでオペレーションキャンペーンと言うモードを
やろうとしたのですが、時間帯が悪いのか過疎なか分からないが全然マッチングしないのですよ。
やりたいのにマッチングしないので出来ないどうしよう、と。
また、昔セールでFarCry3をかなり昔に購入した時(既に4が発売済み)にCO-OPモードが全然マッチしない事が有り
旬が過ぎたオンラインゲームは中々マッチしなくてほぼシングルモードしか出来ない事は割とあると思うんです。
今だとBF4もかなり人数がいない状態なので特定マップのみとか。
なのでオンラインゲームでマルチプレイやCo-opで人を集めたい時、PUBGやFORTNITE等バトロワゲームのスクワッドを
募集する時、オンラインゲームの大会(e-sports)を開きたい時に利用して貰えると嬉しいです。
主に想定ユーザーと考えているのは、FPS/TPS/RTS/MOBA等のPCゲーマーをメインに考えていますがCS機やTCGでも
使って貰えると嬉しいです。
あとViewがレスポンシブでは無く、PC用とスマホ用しかなくタブレット用の中サイズのViewが無いのでご了承下さい。
遊んでも良いよという奇特な方がいましたら当該サイト内でコメント頂けると幸いです
・BF1(PC版)
それでは長々とありがとうございました。
・・・・
日月を切り落し、天地を粉韲して不可思議の無職に入る。吾輩は死ぬ。
ありがたいありがたい。
http://www.yomiuri.co.jp/national/20180413-OYT1T50003.html
この件ね。
http://b.hatena.ne.jp/entry/www.yomiuri.co.jp/national/20180413-OYT1T50003.html
yujilabo 年度末になると補助金の満額まで使い切らないと翌年度の補助金が減額されたりもするため、ただちに必要でない機器や薬剤を購入して保管していたりすることはよくあると思う。無駄なので仕組みのテコ入れが望まれる
timetrain 予算が無いのが最大の原因だろうな・・
例によってはてなブックマークの論調はこんなんなんだけど、 https://kaken.nii.ac.jp/ja/grant/KAKENHI-PROJECT-15H05528/ こちらから科研費の交付状況を見て頂きたい。年 500 万という予算が妥当かどうかは置くとして
リファレンスシステムとしてレーザライダーに加えて、光学カメラと高精度カメラを導入した。レーダで2次元立体構造再構処理した結果と、レーザライダー、光学カメラ、高精度カメラで画像処理した結果を比較評価をすることで、提案手法の有効性を詳細に評価できるようになった。
お前そのカメラ買って即売っぱらっとるやんけ。ようするにこいつ研究成果においても嘘ついてるんですよ。どうにもならん、クソオブクソ。予算不足とかどうとかそういう話以前。小保方みたいなもんですよこんなん。
公式HPではそこで書いたことが全て公式の発言になってしまうことから、
「こうやって作るべき」といった公式の中でも意見が分かれる議論には言及できず、
どうしても事実だけを淡々とまとめるリファレンスのような内容に偏ったりと、
(どちらかというと公式より同じ利用側の立場から教えてもらえる書籍の方が入りやすい)
それ以外のネットの誰が書いてるかわからない無料の情報は間違ってる場合も多い。
ネットの仕組み上、正確な情報より、読み手が面白いと思ったものが
Stack Overflow レベルになると間違いは少ないとは思うけど、
日本の Qiita とかで話題になってる技術記事はひどい内容のをよく見かけるね。
(反論してる人が少ないのは読み手が間違いに気づいてないのか、批判は失礼だと思ってるのか)
一方、書籍はその分野である程度評価されている人しか出版の話にならないので
最低限の内容の正確性は保証されていたり、
そもそも金を取るので読みやすさとかに配慮されていることが多い。
また書籍一冊分の分量からしても技術の全体像が体系化されて説明されるので
まぁ、最新情報が手に入りにくかったり、読者の最大公約数を取るので
高度やマニアックな内容に触れにくかったりという側面はあるね。
要は、それぞれ一長一短あるんだから、賢く使い分けるのがよいと思う。
俺からしたら、両方のいいとこ取りをすればいいのに、