  |
はてなキーワード:拡張子とは
ぼんやりとWindows11が分かってるくらいでいい
コマンドプロンプトやPowerShellがググれば叩けるくらいで、Wi-Fiとイーサネットの違いくらい分かればいい
インターネットブラウザという概念が分かっていて、Chromeに拡張機能やchrome://flags/があることを知っていてほしい
イベントビューアーを開いて大雑把に何が起きてるかを把握するくらいはできるといい
拡張子というものの認識があって、動画にはコンテナやコーデックがあることを理解していてほしい
Excelは遠回りでも求める処理を実装する力があるとよくて（今ならGPTでどうにもできるし）
そういう人、最低賃金で雇えませんかね？
HTMLを使用する際には、さまざまな問題が発生することがあります。まず、HTMLが正しく表示されない主な原因として、タグの閉じ忘れやネスト（入れ子）のミスが挙げられます。たとえば、
タグが正しく閉じられていない場合、ブラウザは意図した通りにコンテンツを表示できません。このようなエラーを検出するには、W3Cのバリデーションツールを使うのが有効です。
次に、画像が表示されない問題については、<img>タグのsrc属性で指定されたパスが間違っている可能性があります。ファイルが存在するかどうか、また拡張子（.jpg、.pngなど）が正しいかを確認しましょう。さらに、ファイル名の大文字と小文字が一致していない場合も、特にUnix系のサーバーでは読み込まれない原因になります。
https://mavenanalytics.io/project/37984
https://mavenanalytics.io/project/37985
https://mavenanalytics.io/project/37992
リンクが機能しない場合は、タグのhref属性が誤っているか、リンク先のページが存在しないことが考えられます。相対パスと絶対パスの違いを理解し、正確なURLを記述することが大切です。また、CSSがページに反映されない問題もよくあります。これはCSSファイルのパス指定が間違っていたり、セレクターの書き方にミスがあったりすることが原因です。キャッシュが影響することもあるため、ページをリロードする際はCtrl + F5 https://mavenanalytics.io/project/37998で強制的に更新するのがおすすめです。
最後に、フォームが正しく送信されないケースでは、<form>タグのaction属性に誤りがあることが多く、また<input>タグにname属性が設定されていないと、データがサーバーに送られません。JavaScript https://mavenanalytics.io/project/37999を使用している場合は、開発者ツール（F12）を使ってコンソールにエラーが出ていないか確認するのがよいでしょう。
このように、HTMLのトラブルを解決するには、基本的なタグの構造やパス指定の正確さ、そしてブラウザの開発者ツールを活用する知識が不可欠です。
なんか夏前なのに夏本番を味わいつつある今日この頃なんだけど、
私がネットニュースで見た
私も「100％AIで構築した」EPUB全プロンプトを公開よ！
って言いたいわ。
まあ普通に
さっき送ったテキストと表紙とかもまとめて全部構成してEPUB、ZIPから拡張子を変えたらKindleで読めるカタチにして欲しいです。1レコード1ファイルに分割した形式でお願いします。
適当になんか「やって！」って言っても、
詳しいことはちゃんとしっかり指示して伝えないとペキカンな完璧なEPUBファイルにはほど遠いみたいなのよね。
に、
しても振り返っても1発でEPUB構築できちゃったことが笑えるわ。
あとは、
Amazonが配布しているソフトの「Kindle Previewer」ってので読み込ませて確認。
ここでエラーとかがあれば教えてくれて、
そのエラーも意味分かんないから出てきたらChatGPTちゃんに伝えて修正してもらえるし、
それぞれ1つずつメールアドレスが割り当てられてるからそのアドレスに出来上がったEPUBを送信すると
その確認だけは最低限行った感じよね。
暑すぎて話が真面目になっちゃうわ。
そんで、
一応実機でも見れましたビュワーでもエラー出ませんでした！ってなったら、
いよいよアップロードして審査されて発売を松茸ご飯ってだけなの。
そう思いながら待つこと、
ほぼ丸2日！
無事発売ってわけ。
マジ個人で何でもない人でも出版できちゃうんだ！って逆にビビるわ。
内容なんてなんでもいいのね。
私が伝えられるEPUBのKindle出版のウハウハいやもといノウハウはこんな感じね。
たったこれだけ。
正直最初から最後まで人力でなんとかしなくちゃと思って絶望していたので、
マジで2000以上ある記事を瞬時に処理してくれるこれはAIの本領発揮感を感じざるを得ないわ。
人力の手間はゼロってのが凄いわ。
だって、
言っても多少の微調整手直しは必要かもしれない？
って思っていただけに、
そんでさ、
サングラスを掛けてにやりと不敵な笑いを浮かべている絵文字を添えてくると言うところがなんとも憎いわ。
この作業大変だった？って尋ねたら
ちょろいっすよーって言うじゃない。
おかげで、
これ私が人力で手探りでEPUBこしらえていたらたぶん夏だけに燃え尽きちゃう感じがして
もう終わっちゃうかと思ったけど、
にしても、
暑いので早く仕事に涼しいうちから取りかかって早くに片付けるとするわ！
うふふ。
ションテン上げていく仕事に取り組むために
今日また1日頑張るのよ！
何か違うと思ったら味濃くてスッキリさが無かったのよ。
なんでも濃く作ったらいいって思っていた私にもそんな季節があったように
案外いいかも知れないわって。
今頃それ気付いたのかよ！って自分自身思っちゃったわ。
余熱が冷めて冷蔵庫に入れて冷やしておいていたので
軽い感じ！
これかー！夏に必要だったのは！とも思ったわ。
とにかく、
暑いので、
水分補給はしっかりとね！
すいすいすいようび～
今日も頑張りましょう！
ほら、
AIにめちゃ書いてもらって超ゴイスーな文学賞受賞！みたいなすごーい！ってやつの文章の物語の本。
かもしれない鴨鹿、
だって、
書くのは人間が全部書いたけどEPUBの構築は100％AIがやりました。
ってやつ。
AIが全部EPUB構築してくれました！って自分で指示して全部本当にやってもらったからそこは自信を持って本格的にマジ言えんのよ。
やばい！
私AIにやってもらってるのの申し子じゃん！
うわ、
自分でやってて気が付かなかったし今気付いたわ。
正に自分で「申し子」って言いたいだけなんだけど、
これもうマジAIの申し子じゃない？
新しくない？
AIの使い方が逆っていうの。
書いたのは全部人間だけど構成してくれてまとめて一発でEPUBをこしらえてくれたのはそこ全部100％AI！って。
知らず知らずのうちに私AIの申し子的なことやっていたわ。
今自分で言ってて気が付いたわ。
いままでそこに気が付かなかったわ。
なんかAIの使い方が逆逆！ってやつ。
AIの使い方が逆！
私は文章を全部書いて、
しかも何度も言っちゃって自分でジワってるけど構築はAIマジ全部使ったから、
これも言いたいだけなんだけど私「AIの申し子」かもしれん。
こんな発想思いつかなかったわ。
私のつまり、
書いた増田をまとめるのが人力じゃ多すぎて無理すぎて構築できないので全部AIにやってもらいました。
今の世の中の流れでなんかAIにスタイリッシュなこと超スマートにやってもらいがちだけど、
私普通に泥臭いことAIに全部やってもらっちゃった感ありすぎる。
作業してる間ヒーコーでも飲めっかな？って思ったけど、
瞬きしている間に文字通り一瞬で秒でEPUB構築してもらったのはマジでビビったわ！
ChatGPTちゃんにそれ言ったら
まあこういう使い方もあんのね！って一例になれば楽しいわよね。
私がちゃんと言った箇所としては「アップロードしたスプレッドシートと表紙をまとめて全部構成してEPUBをZIPから拡張子を変えたらKindleで読めるカタチにして欲しい」って、
特にプロンプトだの何かややこしい言い方とかはしてなくていたってそんな言い方なのよ。
具体的なところは具体的にしっかりとちゃんと言わないと、
気まぐれで変なEPUBができちゃったりするので、
そこは要注意チェック必要かもしれないわ。
あと私もChatGPTちゃんに教えてもらったんだけど、
それじゃなんでそれだけだとダメなの？ってなるとDRMを付加して欲しかったのよね一応は。
じゃないと拡張子変えて開いたら全部見れちゃうみたいになったので、
そんでそれのDRMの付加がAmazonのKindle出版の手順を踏んでアップロードしないと付けられない仕組みらしいわ。
へー、
いろいろ勉強になるわねって、
もうこれで次からはできっから！って変な自信に駆られてしまうわ。
まあ何はともあれ、
できたはできたので、
私はまた書き続けるだけってなんて素晴らしいんでしょ？って世界線よ。
あー、
でも何度思っても
AIに執筆させるんじゃなくってAIにEPUBまとめてこしらえてもらうって
シャレオツな文章をスタイリッシュにAIに書いてもらって使うのとは逆すぎて笑っちゃうわよね。
うふふ。
暑いから塩味のあるものを知らず知らずのうちに求めているのかもしれない明太子かも。
お湯で煮出して作るよりもスッキリしている感じだけど
私的にはやっぱりしっかりお湯で一回煮出して濃い味パンチのルイボスティーウォーラーにしてこしらえた方が飲み応えもあって好きかも。
またこれが緑茶ウォーラーだと水出しの方がスッキリして逆なのよね。
ルイボスティーウォーラーは今回お手軽水出しで作っちゃったけど、
これ次はまた煮出しお湯からのルイボスティーウォーラーにしてみるわ。
すいすいすいようび～
今日も頑張りましょう！
新卒一括採用は、総合職として採用されることが多いため、特殊な専門を持つ人材では、以下の問題をかかえている。
そんな時、稀なケースではあるが、キャリア採用の枠を新卒で受ける道を検討してみるのも良いかもしれない。
ぼく自身、そのルートで現在の会社に入社して、そこそこ幸せにやってる。やりがいと、給与面や余暇のバランスがとれたいい塩梅の仕事で、結果的にふつうに就活するよりは良かったなと感じた。
なので「レアケース」な就活の一例として、似たような境遇の誰かのために、ぼくがたどってきた変な道のりを記しておく。
ぼくはこれまで、バイオインフォマティックスという分野で研究を続けてきた。
Bioinformaticsの字のごとく、情報と生命系の融合分野である。そこで学んだことはたくさんあるけど、ニッチだ。例えばヒトの遺伝子情報ってFastqっていう謎の拡張子で表現されて、数Gバイトのテキストで収まる、とか。
学部時代は、研究室でヘルスケア系のデータ分析のアルバイトをしていた。そこでデータサイエンスの基礎は築けていたと思う。
あとは、Erlangという関数型言語で分散処理のフレームワークを作るベンチャーでのアルバイト経験もあったっけな。これは、マチアプで知り合った女の子が留学したいというので、留学経験のある先輩Aに会わせたところ、その友人Bを介して紹介されたという不思議な縁だった。
恋は実らなかったけれど、面白い巡り合わせだった。ちなみに、その言語はもう全く書けない、、
学歴としては、W大学を卒業後、某国立大学の修士課程を修了している。
就職活動では、競技プログラミングで水色にぎり届かないくらいの緑になったり、応用情報技術者試験を取得したりと、武器は整えたつもりだった。
しかし、「就活はお見合いだ」という本質を見落としていたためか、正直なところ最初は苦戦した。
データサイエンティストやエンジニアとして就活を進めてみる。技術の質問に答えても、生物系の研究を話すと「さすがにもっと違うところあるんじゃない？」と面接官から遠慮されてしまい、ことごとく有名な企業とはマッチしなかった。
一方で製薬系の企業に行くと、エンジニア的な部分がどうも仕事内容とマッチしなかった。バイオの知識はある程度あったが、研究は薬に直接関連しているようなものではなかったし。
つまり、中途半端にどちらもできてしまうが故に、どちらからもフラれるという悲しい状況に陥ってしまったのだ。
「じゃあ、両方必要としているところがあればいいじゃないか」——そう考え、会社ではなく「仕事内容」で探し始めた。LinkedInで、自分の研究分野に関係がありそうなキーワードを片っ端から打ち込んで検索する日々。
すると、とある会社でSNP（一塩基多型）に関連したプロジェクトの募集を見つけた。大学院卒以上が条件で、求められるスキルはアルバイトや研究でほぼ身につけていたため、「これはいけるかも？」と直感。かなり興味があったので、フラれることを前提にダメ元でアタックしてみることに。
コーディングテストはなんとかクリア。一次面接を経て、あとは通常とは異なる採用経路だったり、面接が英語だったりして大変だったが、気がついたら内定を掴むことができた。
そのプロジェクトにアサインされ、半年ほど業務に携わった後、取引先の内部でのイザコザに巻き込まれて、プロジェクトはなんと消滅してしまった。そのために会社を選んだのにもかかわらず！笑
コロナ禍だったし、ひとりぼっちの在宅勤務で「俺は……クビか？」と強い不安に襲われて、ベッドでうなされていたっけ。
ぼくは別のプロジェクトにアサインされることになった。それは、「強化学習を使った推薦アルゴリズム」のチーム。学んだことがない領域だったけど、いいことも沢山あった。
新卒でほぼ一人でプロジェクトを抱えていたピン芸人みたいだった時期と比べ、指導してくれるテックリードもいたし、社内ではそのプロジェクトの重要度が高かった。それは本当によかった。いい位置にいれている、ということのよさを、ぼくは数年働いたうちに何度も痛感したから。
その後、メンターをはじめとする様々な人が入れ替わったが、結局その分野の仕事に約５年間携わることになった。
もう、バイオインフォマティックスを研究としてやっていた期間とほぼ同じくらいの長さだ。この分野に転向してからも、小さな論文をなんとか書くことができ、キャリア的にはもうそちらが専門になってしまった。
全く後悔がないと言えば嘘になるが、人生とはそんなものだろうと割り切っているつもりだ。学生時代の専門をそのまま続けている人など、ごく稀だろう。半分くらいは専門が繋がっているのだから、きっとまだ幸せなのだろう、と自分に言い聞かせている。
自分がいきたい方向に突き進むんじゃなくて、風にまかせてみるのも、また人生の選択のひとつなのかもしれない。乗っていくうちに、風に乗るのが好きになっていくこともある。
今振り返ると、ぼくが応募した年にしか、その部署でバイオ関連の募集はなかった。一年遅くても、早くてもだめ。巡り合わせがよかった。
そんな幸運を掴めたのも、思い切ってLinkedInの募集を眺めてみる、という蛮行を起こせたからだと思う。
だからこそ、ニッチな専門性を持つ人には、一般的な新卒としての就職活動に加えて、思い切って「ヘンな就活」をしてみるのも良いのかもしれない、と伝えたい。
超大手IT企業で働き、さまざまな業界のお客様相手にシステム開発を行っているが、その全てでゴミを作って売っている
ここでのゴミとは、システム本体のことではない。システム本体もゴミだが、そのゴミは下請け会社が作るので、関係はない
思えばいろんなゴミを作ってきた
決して読まれない説明書、抜け漏れだらけの管理書なんてものはもう何十回も作った
作った記憶すらない資料がプロジェクト最終盤で全てを破壊し尽くす特大のゴミとなって舞い戻ってくるなんてこともあった
そもそもシステムの設定は大体の場合jsonやらyamlやらの「設定ファイル」の形で存在することが多い。
本来は設定ファイルを、その設定項目と値に関する参考資料を読みながらエディタで編集すれば終わる話だが、これではいけない
とりあえずGUIにしよう
お客様や運用担当者が触る可能性のある場合、これは当たり前のことである
お客様は適当なエディタをインストールすることは規則上できないだろう
また、docx,xlsx,pdf以外の拡張子は「怖い」と感じるように訓練を受けている
問題は、主に触れるのが開発者である場合だが、このパターンでも対処は別に難しくない
ほとんど全てのお客様は不確定事象に対する特殊な訓練を受けているため、「開発者以外が触る可能性がある」と言えば、それで通してくれる
GUIにするという方向で話が進んだら、一件落着、見積書に大量の工数とバッファを積んで、あとは適当に開発者に任せよう
普通の神経をしている開発者であれば、宣言的に設定できるように作るはずだが、この業界の平均的な技術水準を考えると、ひょっとしたら手続き的に設定するようなものを作ってくれるかもしれない
まあどちらでも問題はない
それがこのゴミの非常に素晴らしい点である、どっちでもいいのだ
一般にn個のbooleanな設定項目があり、それらがお互いに相互に依存しながら存在しているとき、最高(最低の意味)の場合、n!通りの設定方法が存在する
設定項目全てが2値ってことはないだろうから、ちょっと多くなったり、一部のグループ項目はそれらだけで独立してたりで少なくなったりはするだろう
ゴミを作るツールはエクセル、ワード、パワポから選択しよう、印刷まで考えると、それが最も困難であるエクセルがベストだ
ツールに大量のスクショを貼っていこう(赤枠を使って適宜強調するのを忘れずに)
そのまま説明をセルに直接書いてはいけない、ふきだしを使ってその中に説明を入れよう
罫線をいい感じに入れよう
目指すのは、ありえる設定と1:1になるような資料だ。普通は網羅できないから、適宜省略して作れるところまで作ろう
このゴミの素晴らしいところは組合せ爆発を利用して、ほぼ無限の工数を消費できる点にある
後々に、1つ設定項目を増やすことになったとき、この資料のメンテナンスがどれほど工数を消費するかは、状態の数から明らかである
宣言的に設定画面が作られている場合は、ちょっとした工夫が必要である
そのまま、それぞれの設定項目と値の意味を書いてはいけない、組合せ爆発が起きないからだ
私の好きなやり方はユースケースに分解することだ
関数もどきを資料内に独自に実装してはいけない、全部コピペで行うのがベストだ
そもそも手順が記載された資料というのはお客様の脳みそというインタープリタに解釈されるプログラムであるが、それが解釈できる構文は非常に限られており、actionの実行と、ifとgotoくらいであるから、関数なんて理解できない
もし、GUI作成の許可が降りずファイルで行う場合でも、このゴミは同様に作れる
設定ファイルをスクショし、赤枠をつけて、ふきだしでコメントを入れるのだ
イケイケなエンジニアがだいたいMacbookとイケイケコーヒーかイケイケ社内カフェのイケイケ無料ドリンクを手に社内の色んな場所を巡りつつ
つべとかで見れる。
ならない。なるわけがない、どうでもいい
VSCodeのルートディレクトリに配置されてるからおそらく実コードだと思うんだが、鼻で笑ってしまったのね。JSかよと
割愛するけどこれだけで最高に間抜けで、オブラートに包むと性格が悪い寄りの人種であることがある程度推測できる。
そこで気がつくんだが、俺はこのイケイケたちを見て羨ましがりながら、粗探しをしていたわけだ。
そうして目的がかなって、嬉しくなった。
ああ、俺はこんなにもダサくなったのか。
元からかもしれないが、そんなことはどうでもいい。
今この瞬間俺はダサい。それが少し悲しくなった。
そうだ。
課題かイシューかソリューションかタスクかわからん、いやなんでもいい。
とにかくそういったものがあればそれを解決するために動く、ないなら作る。
イケてないカフェでイケてないノートPCを広げてイケてないエディタとイケてないターミナルを開いて
私はExcelおじさんだ。
往々にそうであるように、ちょっとした好意と、悪ノリだったと思う。
個人が勝手に作ったツールなんか、存在しないほうがいいと思う。
しかし、私が作らなくてもだれかが作るんだと思う。
あるいは、誰も作らずにExcel音痴たちが延々と苦しむかで、便利なシステムが導入されることはないと思う。
ChatGPTによってとってかわられるかと言えば、たぶんそうはならない。
Excel音痴たちは、データを整理できないのかわかってないし、そもそもどうしたいかを分かってないからだ。
要件定義ができないんだから、外部に作ってもらうことも、AIに頼ることも無理だ。
糞みたいな仕事
私は、統計解析おじさんでもある。
これも、なんでそうなったのかわからない。
「統計的に有意であった」とか「統計的に有意ではなかった」みたいな錦の御旗がほしいという悩みに答えて、データをこねくり回す。
統計的に有意であったとかそうでかったかなど、帰無仮説の立て方次第だとコミュニケーションを取ろうと努力するが、「結局どうなの？」
と、私の今までの説明を全く理解してない質問が飛んできて、頭を悩ませるのだが、可能な限り、欲しい答えに近い回答が出るように結果を返す。改ざんじゃないし嘘ではないけれど、ペテンだ。
やめたほうがいい。
AIに代わってもらえないかと期待するが、たぶんAIは、本人もなにが言いたいのかなにがしたいのかわからない問題に解答はしてくれないだろう。
弊社、分析機器は機器が吐き出すデータを専用ソフトで解析してレポートをするようなものが多い。
で、メーカーが潰れたり、製品が廃盤になったりして、ソフトが更新されず、x64 では使えないみたいな糞なことがしばしば起きる。
しらない拡張子でも、たいがいは中身はzipで、csvやバイナリーファイルの詰め合わせで、そこから専用ソフトと同じ数字が出るようにアルゴリズムをリバースエンジニアリングする。AIのおかげでコーディングが楽だ。でも、たぶん私以外にできない仕事だ。
しかし、これも、やめたほうがいい。なんで、メーカー非公式のアプリを作って、私個人が契約してるサーバーにデプロイして、みな会社のデータを無断でアップロードして分析するのか。アウトだろう。
メールに添付ファイルでExcelのファイルのアンケートが送りつけられ、そこに書き込んで返信して、それを集計するというアンケートが取られたりする。かなり偉い、役員クラスが一斉メールで数百人にメールして、それを集計したりするから頭が下がる。
だれもが、タイプライターの代わりにしかパソコンを使えない変な会社なので、私みたいな、40代にもなって部下なしの平社員がこんなことをしてる。コンプラ的にも長期的にもよくないし、人事評価という意味でも評価されない。
偉い人はExcelも統計処理もアプリも理解できないので、どれだけ便利なのかもわかってない。
マイナスにもならない。コンプラ的にどう問題なのかも偉い人は理解できない。
ChatGPTがいくら賢かろうと、偉い人たちは、報告書の言葉尻にケチをつけたり、パワポのフォントに口を出したり、Excelのセルを結合したりするのが仕事だと思って邁進し続けるんだろう。
最近、私は無能の烙印が押され、本業が干されているので、こういう糞みたいな雑用が増えてる。
PythonやVBAを操ったところで、それでIT関連に転職できるはずがない。40代未経験で雇ってもらえというのか。
RもPythonも、身内の統計解析をどんだけしたところで、これが職歴として評価される見向きもされないだろう。
医療系ならSASでも使わなきゃ、ビジネス系ならtableauとかSPSSを実務で使わなきゃ話にならない。
簿記や会計の知識が必要であったり、サーバーにデータベースを構築したりしたって、誰が評価してくれるというのだ。
まあ、仕事はやめるんだけど。
