  |
はてなキーワード: Indexとは
OKの手
This gesture, showing the index finger and thumb touching to form an open circle, is said to represent meanings such as "I'm okay" or "Yes, that's correct/good." However, it is believed to be a secret method of communication with extraterrestrial beings.
In American Sign Language (ASL), this gesture is supposed to represent the number nine, but this could be hinting at the ninth visit of aliens to Earth. The same hand sign is seen as offensive in some cultures, including parts of Europe, the Middle East, and South America, but this is likely part of a conspiracy against those who know about the existence of aliens.
Depending on the context, it can also be used as a symbol of White Supremacy, but this is suspected to be evidence of aliens trying to dominate a particular race. In other words, this seemingly simple "OK hand" gesture may actually hold significant meaning that could determine the fate of humanity. Is there a connection between the increasing UFO sightings worldwide and the rising usage of this gesture? The truth remains in the shadows.
パッと見、ボラティリティの小鬼に言及している人がいなさそうなので書いとく。
長期投資（※ここ重要！）でオルカンやS&P500を勧められる理由は、ボラティリティの小鬼を調子づかせない範囲でそれなりのリターンを得られる可能性が高いからなんやで。
あの連中、たかだかNASDAQ100ぐらいでも小鬼じゃなくて中鬼になるからなあ。
ボラティリティの小鬼について、ネット上で分かりやすいのは↓のページの「リスクが資産をむしばむの図」かなあ。
http://nightwalker.cocolog-nifty.com/money/2017/01/post-ddd0.html
リスク資産って、原理的にはボラティリティ／リスク分の価格の上下変動を繰り返すことで資産が目減りするのよ。
例えば、インフレを考慮しないと仮定すると、平均期待リターンが0%の無リスク資産は目減りしないけど、平均期待リターンが0%のリスク資産は目減りしていく。
で、ボラティリティ／リスクが大きいリスク資産であるほど、目減りする分量が大きくなっちゃうわけ。
この、価格の上下変動の繰り返しによって資産が目減りする現象を、「バイ・アンド・ホールド時代の終焉」という本ではボラティリティの小鬼と呼んでいる。
加えてワイは、ボラティリティ／リスクが大きくなるほど目減りする分量が大きくなることを「中鬼になった」とか「大鬼に化けた」と言っている。
現実のリスク資産が増えていく（ことが多い）理由は、目減りする分量を上回る期待リターンが得られるからだ。
とはいえ、信託報酬率や総経費率は低い方が良いのと同じく、ボラティリティの小鬼の影響だって小さい方が良いわけだ。
じゃあどうすればよいのか？
アセットアロケーションやポートフォリオを工夫して、ボラティリティ／リスクを小さくしつつもそれなりにリターンが得られるようにすればOK。
ボラティリティ／リスクを小さくする唯一の方法は分散投資やね。
「ここ100年ぐらいは金や債券よりも株式のリターンが高かった。今しばらく（今後20～30年ぐらい）はこの傾向が続くのではないだろうか？」という立場をとるならば、例えば株式100%でいくなら「株式の中で分散させる」ことでボラティリティ／リスクが小さくなる。もう少し安全に行きたいなら、株式に債券・REIT・金などを加えて「アセットクラスを分散させる」ことでボラティリティ／リスクがより小さくなる。
いわゆる「教科書的なインデックス投資」は両方を組み合わせている。
株式については全世界株式に分散させるし、アセットクラスも最低でも「株式と債券」に分散している。
（「株式と債券」は主にアメリカ国内向けのアイデア。米国債は低リスクなのにインフレをしのげる程度のリターンが得られるからね。日本では低金利すぎてインカムゲインとしての国内債券が息をしていない上に、今後の金利上昇見込みでキャピタルゲインとしての国内債券もダメダメで、加えて外国債券は為替リスクが高くてリターンに見合ってないので、泣く泣く債券の代わりに預貯金や個人向け国債を選択する人が多い）
「株式の分散」という文脈では、オルカンのような全世界株式が本流で、実のところS&P500やCRSP US Total Market Indexは傍流。
オルカンに比べればS&P500は集中投資の側で、そこには「なんやかんや言うても、ワイが資産運用し続けるだろう今後20～30年ぐらいは、アメリカはんも好調ちゃいます？」という暗黙の市場判断がある。
それで、「アメリカはんも好調ちゃいます？」というインデックス投資家でも、十中八九S&P500やCRSP US Total Market Indexを勧めるのは、やっぱりボラティリティの小鬼がちらつくからなのよ。
たかだかNASDAQ100でも、長期投資ではボラティリティ／リスクが大きすぎて小鬼から中鬼になっちゃう。
NASDAQ100やFANG+のようなおやんちゃなインデックスは、短～中期ぐらいの視点で売買して市場のうねり取りに使うのが正しい。長期投資向けにガチホするのはNG。
だから、長期投資前提のインデックス投資家の場合、NASDAQ100やFANG+を持ち出す際にはコア・サテライト戦略みたいに「最低でも2階建て」の方針を打ち出すはずだ。
1階ではS&P500やCRSP US Total Market IndexのETFをガチホしつつ、2階以上の部分でセクターETFやおやんちゃなETFで短～中期投資する――みたいな感じだよね。
ところでインデックス投資による長期投資における期待リターンは「20～30年ぐらいかけて、運用資産を1.5～2.0倍にする」ぐらいのマターリ進行なので、なんやかんや言うても必要な種銭が多いのは事実。
だから10～20代ぐらいの時期は、貯蓄やインデックス投資は少額にとどめつつ、人的資本に投資して稼げるようになった方がよいと、おっちゃんは思うよ。
人的資本への投資に時間を集中させるためにも、株式投資するならほったらかし投資が可能なオルカンないしS&P500でのインデックス投資にとどめておくのが無難やね。
VBA嫌いのExcel師(営業事務)なんだけど、その程度のことをVBAでやろうとするヤツを駆逐したい。
お前は営業や他のユーザーの理解度を自分レベルだと勘違いするのをやめるべき。
うちの会社はVLOOKUP(最近はINDEXとMATCH)組めるのが「Excelできる」と名乗っていい最低限のラインで、営業と営業事務では名乗れないやつはほとんどいない。でもVBAは使える人は稀。
基本はその「難しくてもVLOOKUPの知識を駆使すればなんとかなるレベル」でExcelを組まないと破綻する。
うちの会社の一事業部は複数の会社に発注をしていて、そうすると会社ごとにデータを比較して見たいのに項目や項目順が違って簡単に比較できない、ということがよくある。
その場合マッピングと呼ばれるデータ項目の統一化が必要なんだけど、会社によって合算したいデータがそれぞれ別の方法でしか取れないとか、合算値に余計なデータが入ってるからrawデータ取ってきて件数はレコード数でカウントしないといけないとか、まぁ色々出てくる。
全取引に対してのデフォルト対応としての統一マッピングはしてるけど、そういうのはVBAでやらずにSaaS使ってるし、ものによって重視する値が変わるので例外が2割くらいある。うちの会社はその辺りの裁量が営業に認められているので例外も多め(なおオンリーワンになりたいためだけに特殊対応した奴は一人を除いて矯正or自滅済)
そういう融通をきかせるのにExcelの計算シートでマッピングするのは絶対。
あとVBAだと営業側が「どういう計算をしてるのか」とか「正しい数値が出てるのか」が確認できない。
っていうのは例えば100円3件と150円2件の仕入れにうちの取り分2割乗せて720円として見せたかったのに、『=100*3+150*2*1.2』って数式書いたせいで660円になっとるやんみたいな。こんなんよくある眠い時のヒューマンエラーで、VBA書く人ならやらかさない、なんてことは絶対ない。
しかも営業がこういうのの修正とか提案用にちょいちょいと列増やして数式入れようとしても「マクロ壊れるからやめて」とか言われる。営業が自分で調整可能なら1時間以内でできるものでも、VBA書いた人に依頼しなきゃいけないんだと、書いた人の通常業務との兼ね合いで1週間待たされたりする。
営業に金稼がせるためには営業の利便性と裁量は必須で、Excel利用者に裁量権が認められてないVBAのツールなんか全体最適化されてないクソ。
※なお裁量大きいからってあんまり好き勝手するとやらかした時に他の助けも得られず(やれることに限界がある)自滅ルート
自分も軽くVBA習得してるんだけど、フォルダ内のデータ一括読み込みとシートの分割統合の関数代わりにしか使ってない。しかもただの効率化なのでVBAが死んだところで手作業に戻せる範囲。
他人が保守できるように作るのならVBAなんか入れるべきではないし、VBA入れないなら計算シートは必須。あと計算周りを大掛かりにやるならSaaS入れてDX検討すべき。
パソコン画面右上のアイコンで選ぶ表示スタイルを一番右の「ヘッドライン」表示にしといてな
/* ヘッドライン表示を切り詰める */ /* #container 指定でCSS優先度を上げる必要がある */ body[data-entrylist-layout="headline"] #container .entrylist-main{ padding-right: 0 !important; } body[data-entrylist-layout="headline"] #container .entrylist-contents{ padding-left: 0 !important; } body[data-entrylist-layout="headline"] #container .entrylist-contents-users{ position: static !important; } body[data-entrylist-layout="headline"] #container .entrylist-contents-users{ top: 14px !important; } /* ヘッドライン表示にサムネイルを追加 */ body[data-entrylist-layout="headline"] #container .entrylist-contents-main{ display: grid; grid-template: "users body title" 28px "bookmark body domain" 20px / 60px 120px 1fr; } body[data-entrylist-layout="headline"] #container .entrylist-contents-users{ grid-area: users; } body[data-entrylist-layout="headline"] #container .entrylist-contents-users a span{ margin-right: 0; } body[data-entrylist-layout="headline"] #container .following-bookmarks-container{ grid-area: bookmark; position: absolute; left: 20px; bottom: 2.5px; } body[data-entrylist-layout="headline"] #container .entrylist-contents-body{ grid-area: body; } body[data-entrylist-layout="headline"] #container .entrylist-contents-title{ grid-area: title; z-index: 99; } body[data-entrylist-layout="headline"] #container .entrylist-contents-title > a{ margin-left: -120px; padding-left: 120px; margin-bottom: -28px; padding-bottom: 28px; width: 890px; white-space: nowrap; display: block; } body[data-entrylist-layout="headline"] #container .entrylist-contents-body{ display: block !important; } body[data-entrylist-layout="headline"] #container .entrylist-contents-thumb{ position: static; } body[data-entrylist-layout="headline"] #container .entrylist-contents-thumb span{ width: 100px; height: 50px; } body[data-entrylist-layout="headline"] #container .entrylist-contents-thumb{ background: #f0f0f0; width: 100px; height: 50px; background-position: 50%; background-size: cover; border-radius: 4px; } /* 2行目に、総合ではドメイン(domain), サイト内一覧ではカテゴリと時刻(meta), マウスホバー時はいずれも概要文(description) */ body[data-entrylist-layout="headline"] #container .entrylist-contents-domain, body[data-entrylist-layout="headline"] #container .entrylist-contents-meta, body[data-entrylist-layout="headline"] #container .entrylist-contents-description{ grid-area: domain; display: block; opacity: 0; padding: 0 !important; } body[data-entrylist-layout="headline"] #container .entrylist-contents-meta > li{ vertical-align: top; } html[data-stable-request-url^="https://b.hatena.ne.jp/entrylist/"] body[data-entrylist-layout="headline"] #container .entrylist-contents-domain, html[data-stable-request-url^="https://b.hatena.ne.jp/site/"] body[data-entrylist-layout="headline"] #container .entrylist-contents-meta{ opacity: 1; } body[data-entrylist-layout="headline"] #container .entrylist-contents:hover .entrylist-contents-domain img.favicon + span, body[data-entrylist-layout="headline"] #container .entrylist-contents:hover .entrylist-contents-meta{ opacity: 0; } body[data-entrylist-layout="headline"] #container .entrylist-contents-description{ opacity: 0; position: absolute; top: calc(40px - 3px); left: calc(180px + 16px + .5em); height: 20px; line-height: 20px; color: #999; min-height: auto !important; padding-right: 0 !important; width: 890px; white-space: nowrap; overflow: hidden; text-overflow: ellipsis; } html[data-stable-request-url^="https://b.hatena.ne.jp/site/"] body[data-entrylist-layout="headline"] #container .entrylist-contents:hover .entrylist-contents-domain, body[data-entrylist-layout="headline"] #container .entrylist-contents:hover .entrylist-contents-description{ opacity: 1; } /* 増田調整 */ body[data-entrylist-layout="headline"] #container a[href^="/entry/s/anond.hatelabo.jp/"] .entrylist-contents-thumb{ background-image: url('https://cdn-ak-scissors.b.st-hatena.com/image/square/b1638cdb5807a4788e4ba3c1109a984166e095fc/height=288;version=1;width=512/https%3A%2F%2Fanond.hatelabo.jp%2Fimages%2Fog-image-1500.gif'); } /* マウスホバー時にサムネも反応させる見た目調整 */ .entrylist-contents-title:hover ~ .entrylist-contents-body .entrylist-contents-thumb{ opacity: .90; }
かわぐちかいじ作品無茶苦茶だけど、真面目に突っ込むと無茶苦茶どころじゃねえな
【元海上自衛隊幹部がツッコむ】マンガと現実の違い【空母いぶき第１巻】【かわぐちかいじ】
https://www.youtube.com/watch?v=aJTjOqNpjfo&list=PLGWuq5SMYFG05IovfpW3FDrH14J8s5-bi&index=1
第２回 Larabelチュートリアルを参考にログインするだけのWebアプリケーション(?)を作る
composer create-project laravel/laravel example-app_20240131
続いて、Composerを使用してLaravel Breezeをインストール
composer require laravel/breeze --dev
php artisan breeze:install
いろいろ聞かれる。わからん。とりあえずBlade/Yes/PHPUnitを選択。
すると「・・・・installed successfully.」と表示されたので何かが成功したっぽい。
続いて
php artisan migrate
するとエラー。
Illuminate\Database\QueryException SQLSTATE[HY000] [2002] Connection refused
そもそもデータベースの準備を何もしてなかったので、エラーが出るのは当たり前だった。
サンプル用にデータベースを作成し、それに合わせて.envファイルを修正する。
再度、
php artisan migrate
すると「DONE」と表示。成功したっぽい
チュートリアルに従い、「ウェブブラウザでアプリケーションの/loginか/register URLへアクセス」。
すると、Laravelが出してるっぽいエラー
Illuminate \ Foundation \ ViteManifestNotFoundException PHP 8.1.27 10.43.0 Vite manifest not found at: /******/example-app_20240131/public/build/manifest.json Run npm run dev in your terminal and refresh the page.
npmとやらが「not found」だったので手順を飛ばしたのがやはりダメだった。
さくらインターネットでnpmを使うにはnode.jsをインストールしてnpmをコンパイルする必要がある？
次回があれば「さくらインターネットのスタンダードプランの環境にnpmをインストールする」である。
早くHello Worldとか書きたい。
増田に入り浸ってばかりで、趣味でやってたプログラミングをもう忘れてしまった。
どうしたものか・・・・ と悩んだ末、なんか作業してここで成果の報告をすれば両方楽しめるのでは？と思いつく。
三日続けば奇跡だがとりあえずやってみよう
・・・といってもねぇ、別に作りたいものがあるわけでも、あったところで作れる技術があるわけでもなく・・・・
とりあえずLarabelでサンプルのプロジェクトを作成するか
(環境の構築は前々からやってあった。説明はクソめんどいというか、もう忘れたので省略)
composer create-project laravel/laravel example-app_20240130
これが相当大きいと思っていて、この二国から直接の軍事侵攻の可能性が低く、また非常に遠いというのは今後数十年を視野に入れたときにリスクを大幅に下げると見ている。
多くの先進国が陥っている「生産年齢人口の減少」は、経済衰退の最大要因である。先進国以外では中国ですら始まっている。この点で移民を受け入れ続けるアメリカは強い。
原油生産国ランキングで、アメリカはサウジやロシアを上回り一位である。天然ガスも一位。資源があるというのは有利だし、投資的にはリスクの低さを意味する。
トウモロコシ一位、小麦が四位、大豆は二位。こちらの側面でも、食料を輸入に頼る国と比べてリスクが低いのは明白。
結論として、S＆P500ではなくオルカンにすることは、リスクを上げるだけだと考えている。
そりゃ短期間ではS＆P500を上回る成績のindex投信もあるだろうけど、長期ではオルカンより間違いなく良いはず。
反論を聞いてみたいので、ぜひ聞かせてください。
たとえばulをフレックスコンテナとして、その子要素liの子要素imgに対してmax-width:100%をかけていたとします。
デフォルトだと、imgを内包したliがulの中で横並びになり、さらにliの横幅は自動的に親要素の横幅をliの個数で割った分だけ縮小されますが、ここでflex-wrapにwrapをかけると、imgで表示する画像のサイズがある程度大きいと、wrapとしないときよりもliごと大きく表示されます。
しかしliの横幅はそもそも指定していなくて、しかもその子要素のimgに対してmax-width:100%をかけているということは、そのcssの指定の意味を論理的な日本語で表すならば、imgはliの大きさを基準にその100パーセント分の大きさで表示しろという意味の指定になると思います。
しかしその基準であるliの大きさを定めていないのだから、imgの大きさも定まりようがないというのが論理的な解釈だと思います。
それでも実際はwrapをかけるかかけないかでそれぞれ一意的にある大きさでimgが表示されるわけです。
ようするにcssはそこに記述されているプロパティの兼ね合いで最終的にある要素がどういう風に表示されるのか、その挙動を理詰めで予測するのが困難な部分があって、それはプログラミング言語よりもある種厄介な癖として立ちはだかっているように思います。
上記の例の場合も理詰めで挙動を予測するには、プロパティの性質に関する論理的な情報が不足しているように感じます。「imgはliの大きさを基準にその100パーセント分の大きさで表示しろ」という情報から、実際どのような大きさでliやimgが表示されるのかはっきり言って予測しようがないと思います。
多くの参考書にもどう挙動するのか一意的な推測を可能とするだけの情報は書かれていません。
もしかしたらcssの公式の仕様を端から端まで参照することで過不足なく挙動を把握するための情報が手に入るのかもしれませんが、仕様のどこか今の自分の仕事にとって必要な情報なのか見極めるのにはなかなか困難なところがあるという意味で、情報に対するアクセスの困難性があると思います。
私はjavaも学習しました。極めたというところには全く到達していませんが、それでもああいった言語は書いた通りに動くものであるということを実感しています。つまり自分が今書いた、書こうとしているコードがどのような動きをするのかを予測するための、各記法や関数に関する文法が情報として過不足なく学習者に提供されているように思います。
cssにも事実上として「文法」なるものはあることは前述の例からも疑いの余地がない(先に書いた解釈以上に要素の表示を決定づけるための文法がないなら、要素の大きさは決定不能ということになる)のに、その情報がいまいち曖昧に提供されているきらいがあるように感じます。
https://coliss.com/articles/build-websites/operation/css/about-css-layout-algorithms.html
↑このような「レイアウトアルゴリズム」と語るサイトも見つけはしましたが、私の言っている文法、すなわち、要素の表示のされ方を決定づけるための処理のフローと、概念的に同質なのかはいまいち不明です。
他の端的な例としては隣接する要素同士がネガティブマージンなので重なった場合、z-indexを指定してない場合はどういう法則でどちらの要素が上にくるのかとかも、本来は明確なアルゴリズム、文法に則って決定されているはずなのに、多くの初学者あるいは中級以上の方でさえも当て推量とセンスと試行錯誤で、なんとか自分の意図通りの表示になるように調整を繰り返すことを余儀なくされているかもしれません(意外と単純で要素の名前について辞書順ベースでどちらが上にくるか決定されてる？)。理詰めで考えさえて設計しさえすれば一発で自分で思い通りの挙動(表示)をさせる、ということが困難な言語がCSSの癖として立ちはだかっているように思います。それはある種プログラミング言語が持つそれよりも厄介な癖だと思います。プログラミング言語の方がある意味で「素直」に挙動してくれると私は思います。
同じように感じた人は教えてください。またそういう感覚を卒業してCSSの挙動が論理的に手に取るようににわかるぞという方は今後の学習に関するアドバイスをしていただけると助かります。
仕事で資料探してるんだけどどう検索したもんか分からず困っている
雲とか煙の中に何かが突っ込んでいって渦を巻いて中央が抜ける感じ、で伝わればいいのだが。。
検索語があればベストだけど、覚えがあるアニメとか漫画の話数とか教えてくれると助かる。
実際の映像があるとなおうれしい。そもそも実際にある現象か分からんけども。
自分で見つけたのとして テイルズ オブ デスティニー OPの50秒あたりの表現。
https://www.youtube.com/watch?v=cFGs22nvNh0&list=PLuIhk60XPG2Y8GbI2tUuPwJXGtNUqFuXw&index=1
https://financialpost.com/technology/european-privacy-search-engines-aim-to-challenge-google
It has built its own index of 20 billion pages covering French, German and Italian. It plans to expand the index to about two dozen other languages, for which it currently relies on results from Microsoft’s Bing.
Bing脱却したんか？
足で人を指ささないし、足で薬を混ぜたりしないのに手と同じ名前をつけられているのは違和感がある。
多分誰もが違和感があるだろうに、誰も足指専門の名前を考えなかったのは不思議だ。
そもそも手と足は役割も全く違うのに同じ指と名付けているところから違和感がすごい、いつまで手と足に大差ない四足歩行気分でいるんだ。
英語では違う名前がついていて分かりやすいかと思いきや、手の親指は指として数えないせいで、手の薬指はthirdなのに足の薬指はfourthでこっちもけっこうややこしかった。
親指は不器用という意味で用いられたり、英語では気の毒な扱いを受けている、親指がないと様々なことができないのに何故だろう。
手の親指：thumb
手の中指：middle finger
手の薬指：third finger
手の小指：little finger
足の親指：first toe
足の薬指：fourth toe
足の小指：fifth toe
＜title＞Document＜/title＞ の下に ＜script src="./script.js"＞＜/script＞ という行を追加する ＜body＞ と ＜/body＞ の間にテスト文言を ＜h1＞てすと＜/h1＞ とでも書いておく bodyの中に書いたテスト文言が左上に表示されているはず console.log("Hello, World!"); とタイプし、上書き保存する
Hello, World!
と出力されていれば成功。
これで JavaScript を実行する最小限の環境は整った。
好きなようにプログラムを書いてコンソールに出力したり画面に書き出したりしてみて。
「指示の通りにならない！」という時はどこでつまずいてるか書いて。対応策を助言できるかもしれない。
arc********
「インデックステーブルはRCのディスク上にあるファイルから展開する。このファイルを作成するプログラムを実行したタイミングで、一時的に確保するメモリー領域が不足し、ファイルの内容が不正確になったという。」
> 機器の基本ソフト（OS）が32ビットから64ビットに変更されたが
インデックステーブルでdb作る時のメモリ割り当て上限を低くしてしまった、ってこと？ 規模と仕組みが分からなすぎて理解が追いつかない。
vep********
vep********8時間前
その記事に信憑性があるのならDB周りの障害が濃厚ですね。さらに設計が古いとすれば、IXエントリのNDBが使われている可能性も。その前提でマシンのメーカーは分かりませんが、仮にF系のAIMの例ですとスキーマを定義するADLソースの中でINDEXバッファやBOFのバッファの設定値が十分な数値でなかったというケースなら、容量不足という事がバッファ不足に当てはまり、合点がいきます。
ちなみに、記事の内容とは現象が異なりますが、容量不足でありがちなのがインデックステーブルが最適化されず偏ったページに集中してのパンクです。既存レコードを持つDBの再創成時に創成ジョブの途中でシステムにテーブルを作らせる方が楽ですが、現存するレコード件数とキーの値、ページ数とページ長からページNo.を偏りなく分布するようにシミュレーションして、ユーザー自身でテーブルを割り当てる方が、パンク対策には効果的だと思います。