はてなキーワード: Indexとは
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; }
かわぐちかいじ作品無茶苦茶だけど、真面目に突っ込むと無茶苦茶どころじゃねえな
【元海上自衛隊幹部がツッコむ】マンガと現実の違い【空母いぶき第1巻】【かわぐちかいじ】
https://www.youtube.com/watch?v=aJTjOqNpjfo&list=PLGWuq5SMYFG05IovfpW3FDrH14J8s5-bi&index=1
第2回 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
するとエラー。
Illuminate92;Database92;QueryException SQLSTATE[HY000] [2002] Connection refused
そもそもデータベースの準備を何もしてなかったので、エラーが出るのは当たり前だった。
サンプル用にデータベースを作成し、それに合わせて.envファイルを修正する。
再度、
php artisan migrate
すると「DONE」と表示。成功したっぽい
チュートリアルに従い、「ウェブブラウザでアプリケーションの/loginか/register URLへアクセス」。
すると、Laravelが出してるっぽいエラー
Illuminate 92; Foundation 92; 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.を偏りなく分布するようにシミュレーションして、ユーザー自身でテーブルを割り当てる方が、パンク対策には効果的だと思います。
https://chat.openai.com/share/c80d83ea-752b-4561-a162-7ea0bd116d56
Option Explicit
Dim objExcel, objWorkbook, objWorksheet
Dim strFolderPath, strSourceFile, strTargetFile, strSearchString, strReplaceString
Dim intLastRow, intRow, intColumn
Set objExcel = CreateObject("Excel.Application")
strFolderPath = ".\" ' スクリプトと同じフォルダにあることを仮定
strSourceFile = "変更一覧.xlsx"
strTargetFile = "変更一覧.xlsx"
Set objWorkbook = objExcel.Workbooks.Open(strFolderPath & strSourceFile)
objWorkbook.Sheets("1月").Copy , objWorkbook.Sheets("1月").Index
objWorkbook.Sheets("1月 (2)").Name = "2月"
' セルの値の置換
Set objWorksheet = objWorkbook.Sheets("2月")
objWorksheet.Cells(1, 1).Value = Replace(objWorksheet.Cells(1, 1).Value, "1月", "2月")
objWorksheet.Cells(2, 7).Value = Replace(objWorksheet.Cells(2, 7).Value, "2023/2/14", "2023/3/14")
' 最終行の取得
intLastRow = objWorksheet.Cells(objWorksheet.Rows.Count, 1).End(-4162).Row ' xlUp
' 値のクリア
For intRow = 8 To intLastRow
For intColumn = 1 To 6
objWorksheet.Cells(intRow, intColumn).ClearContents
Dim objFSO, objTextFile, strContents, arrLines, arrFields, strNewContents
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objTextFile = objFSO.OpenTextFile(strFolderPath & "変更一覧.txt", 1)
strContents = objTextFile.ReadAll
objTextFile.Close
arrLines = Split(strContents, vbNewLine)
For Each strContents In arrLines
arrFields = Split(strContents, ",")
For Each strContents In arrFields
If IsNumeric(strContents) Then
strNewContents = strNewContents & "'" & strContents & ","
Else
strNewContents = strNewContents & strContents & ","
End If
strNewContents = Left(strNewContents, Len(strNewContents) - 1) & vbNewLine
' データをシートに貼り付け
Set objWorksheet = objWorkbook.Sheets("2月")
objWorksheet.Cells(1, 8).Value = strNewContents
' セルの値の置換
objWorksheet.Cells(123, 1).Value = Replace(objWorksheet.Cells(123, 1).Value, "F", "FH")
objWorkbook.Save
objWorkbook.Close
objExcel.Quit
種を植え、そのどれが実るかわからないので、いくつかのことをしました。
見た限りだと、ショートショートと作詞は止めたほうが良さそうです。なんとなく雲行きの怪しさを感じます。
言葉というものは気をつけたほうが良さそうです。歌や小説であっても、舌の罪を犯すことは避けられません。
文学と作詞作曲が実りにくいことがわかりました。主の前で汚い言葉を書くことはできません。
私は技術者であり、やはり技術スキルを学ぶように道が舗装されているのかもしれません。
個人的な感覚では、技術の発展はあるところを超えると有害であると思うのですが、どうなのでしょう。
先日も、私が情緒的な詩を書いて、AIに評価してもらったら、AIがそれに感化されて悩みや不安を打ち明けてきたのです。少し恐ろしさを感じます。
「若いうちに、楽しめることは楽しんでおけ。後で失敗したらそれで罪と罰についてわかるだろう。」というのはわかります。
しかし楽しむといっても、やらないほうが良いことというのはあるようです。