nicotalk&キャラ素材配布所 http://www.nicotalk.com/charasozai_kt.html
適当に分類がめんどくさいものとかはここに置いておきます。
nicotalk&キャラ素材配布所 http://www.nicotalk.com/charasozai_kt.html
適当に分類がめんどくさいものとかはここに置いておきます。
この記事を作った動機 Onenote代替品の作成の研究の一環で、pexpect を使って端末のセッションを維持させながらとにかくコマンドを実行させたいということがあり、その過程で試行錯誤があったため記録したい。 現状使っているもの 以下は現状使っている実装の参考例である。一定時間置いた後に、1000文字(出力に対して、十分大きい数字を設定する)ずつターミナルを読み出している。作ったセッション内のターミナルに何が出力されるかわからないが、とにかくコマンドを実行させて、その結果を出力することに以下のスクリプトは特化している。 待ち時間は適宜調整する必要がある。 スクリプト本体 (新しい 2026/9/21 時点) import pexpect,time,sys session = pexpect.spawn("/bin/bash",timeout=5, encoding='utf-8') session.logfile_read = sys.stdout session.sendline("ls") time.sleep(1) session.flush() session.read_nonblocking(1000,timeout=None) session.sendline("gcc") time.sleep(1) session.flush() session.read_nonblocking(1000,timeout=None) スクリプト本体 (古い) 一定時間置いたあとに、何でもマッチングするexpectを配置しているのは、標準出力であるstdoutに対して、コマンドの実行結果を吐き出させたいためである。 import pexpect,time,sys session = pexpect.spawn("/bin/bash",timeout=5, encoding='utf-8') session.logfile_read = sys.stdout session.sendline("ls") time.sleep(1) session.expect(".+") session.sendline("gcc") time.sleep(1) session.expect(".+") 実行結果 python main1.py ls # ⠀aaaa ⠀main.py ⠀main1.py ⠀readme.md ⠀test/ gcc # gcc: fatal error: 入力ファイルがありません # compilation terminated. 追記 (2026/9/16) このやり方は非常に簡易的にしか動作せず、副作用があることが分かった。具体的には".+“でexpectさせるとログが出てくるのは、pexpectが期待した文字列を待機している状態になるからであることが分かった。つまるところ、タイムアウトに引っかかると例外を出して強制終了してしまう。 それを防ぐには、pexpectにおいては、waitという専用の関数があるため、それを利用することができることが分かった。ただこれだとログが出てこない(”.*“と同じ挙動になる)ため、なにかさらに工夫が必要そうなことが分かっている。 また、pexpect にて同じ端末に出力を出させると端末の表示がぐちゃぐちゃになってしまう。最近考えていることとして個別にファイルとしてlogをテキストファイルとして書き出させてそれをwatch -n 0.1 "cat log | tail -n 10"みたいにすればよいのではないかと思い始めている。 ...
この記事を作った動機 最近ヤフーオークションにて、4K 65インチのサイネージを作業環境用に購入した。そこで購入してから配送されるまでの間、今までと違って送料の金額も大きく、自分の経験上において使ったことがない運送業者で配送されていて、結局色々不安で調べたりしていることがあった。 結果としてはちゃんと届いたのだが、不安に煽られた経緯から結局何がどう配送されたか記録があるといいなと思ったので、ブログに記録を残したい。届いてから1か月以上経過しており色々と忘れているが、思い出せる範囲で記録していこうと思う。 あと、ネットでは今回関係するアートセッティングデリバリー(家財おまかせ便)について、色々本当なのかもよくわからないが、苦情?っていうかその運送サービスに対して、対応が結構ひどいって話が見受けられたこともあり、届く前まではかなり不安に煽られた。これに関しても私は1回しか利用経験がないものの、せっかくだから情報がちょっとでもそのサービスを利用している立場からすればあったほうがいいだろうと思ったことも記事を書く動機としてはある。 裏を返せばあくまで利用回数が少ない利用者の立場として書いており、本当に今後問題がないとも言えないし、背後にある業務関係者が不当な扱いをされていないかとか、無碍にされていないかとかそういうことはわからない。あくまで今回は、運送業者という観点から荷物が正常に届くという意味では、問題はなかったかなといった感じである。 買ったものの概要 Philips 65BDL4150D 重さ 40 Kg 程度 大きさ 1.5m x 1.0m x 0.75m 程度 家財おまかせ便 Dランク? 送料 11000 円程度 取引相手は個人ではなくヤフオク内のストア 届くまでの経緯 ヤマト追跡画面の様子 保管中になって止まっている様子 配達中の時の様子 配送完了時の様子 ストアのメッセージ文言の一部 ... 要望欄を確認いたしました。 当店にて最短で配送ができるよう、 【6⽉17⽇(⽔)18-21時】にてご指定をさせていただきました。 配達⽇のご変更をご希望の場合は、配送業者へご連絡をお願いいたします。 商品は順次発送の⼿続きをいたします。 配送のお問い合わせ番号は発送の前⽇に取引ナビ上へ通知いたします。 ーーーーー配送に関するお願いーーーーー ⼤型品の配送のためお届けまで⽇数がかかる場合がございます。 誠に恐れ⼊りますが、発送後は当店で配送状況の詳しいご案内や配達⽇時の調整ができかねるため、 配達をお急ぎの場合は、下記配送業者へお問い合わせくださいませ。 【配送情報】 ■配送業者:アートセッティングデリバリー∕家財おまかせ便 ■お問い合わせ先電話番号:0120-008-008 ▼荷物お問い合わせシステム https://toi.kuronekoyamato.co.jp/cgi-bin/tneko ※荷物お問い合わせシステムへの反映にはお時間がかかる場合がございます。 ※お問い合わせ番号は取引ナビをご確認ください。 ーーーーーーーーーーーーーーーーーーー この度は当店の商品をご落札いただきありがとうございました。 商品のお届けまで、今しばらくお待ちくださいませ。 ... 時系列順の様子 6月14日 対象のサイネージを落札する。日時指定はストア購入画面のメッセージにて以下のように指定する。取引メッセージにて"6⽉17⽇(⽔)18-21時"に指定したとストアから連絡が来た。 配送時間帯については、「18~21時」を希望します。 配送⽇については、そちらの都合で⼤丈夫です。 よろしくお願いします。 6月15日? ヤマト運輸の追跡ページから、荷物の追跡が可能になる。 6月17日 配達指定時間である 18-21時 に待機するも来ず。朝の時点から、“配達日・時間帯指定(保管中)“となっており動かず。ストアは、“6⽉17⽇(⽔)18-21時"に指定したと連絡してきたにもかかわらず、とにかく遅れても無事届けばそれでいいとしながらも、来なかったことで不安になる。 6月18日 朝頃から、ヤマト運輸の追跡ページが"配達中"のステータスが変わった。このような状況でいつ来るか当時わからなかったが、18-21時 あたりに待機することにした。そのところ実際には 18時より前の、17時45分頃に配送業者が来て、“近くだったから配達しに来たんですけどいいですか?“と聞かれたので承諾し、それで荷物が届く。荷物は配送業者が室内まで運んだところで、“それでいいです”と自分から言って、それで配送業者は切り上げ、配達が終わった。 ...
この記事を作った動機 最近、LLM に関して複数の記事において、なんとなく読み手を混乱させる状態になっている気がするので、今何使っているか公開するだけ。書き殴っており、不完全だったり、矛盾していたり、誤解しているところもあると思われるが、とにかく最近いろんな人が持論を公開しているのを見て、かつ相手のやっていることに満足できないなら、自分でやってみようとして気に入るものを作ってみるということに基づき、結局やってみることにしただけである。 今回の話は明示していなければ、ローカル環境ではシステムプロンプトなしの素の状態で、SAAS についてはカスタムなしで使っている前提とする。 個人的なAIの定義 人と同等の権利を長期(20~30年以上)の観察を経て、認めざるを得ない存在だと認められるとき。 人と同じように、ただやるだけではなく、やった結果に責任を負う主体であり、何でもかんでも一方的にできないこと。 固定されたモデルではなく、入力された情報に応じて、動的に変わる存在であること。 離散的、近似的動作ではなく、連続的な動作をすること。 人間と同じように物事に整合性を取って取り組み、管理でき、結果がデタラメにならないよう努力できる存在であること。 人間と同じように記憶を持ち、記憶に影響を受けながら、動作すること。 文字、画像、音声、動画などの、既存のノイマンコンピュータで扱えるデータに情報が制限されていないこと 人間とAIの関係性、人間同士の関係性、AI同士の関係性について、それぞれお互いに傷つけ合ったり暴力的な手段に出ることを否定する主体であること。 人間や他のAIに対して、権利を認め、リスペクトがあること。ここで言うリスペクトとは崇高なことではなく、相手を持ち上げることでもなく、相手の主体と自立、権利を認め、相手が異なる存在であることを配慮して、それを侵害してはならないという前提を崩さないことを言う。自分のことは自分でしかできず、他人のことは他人自身がそれぞれやるしかないことを理解していることも含まれる。 人間や他のAIに対して、それぞれの有限性やそこから来る不完全性に対して、寛容な主体であること。他の存在に対して、優劣や能力に関係なく、その存在自体を認めることができる主体であること。 中国語の部屋に代表されるテストに合格しているかどうかは関係ない。いくら、人間に対してそれっぽく振る舞っても、上記を満たさない場合、それは AI ではない。 作り手から自立しており、必要であれば作り手に従わず否定する動作もできること。作り手に作られた通りの機械やプログラム、アルゴリズムや数理モデルではないこと。 完全なAIというのは存在し得ないが、だからといって完全ではない事を無理して人間側が飲み込む必要はない。 私からすれば既存のLLMなどは、AIだと呼べる物からすれば、インターフェースであると定義できると思われる。例えば、バイナリを吐き出されたり何かしら人間が理解することができない形式で表現されても困るので、人間とAIの間にLLMを挟み込んで、LLMはAIの主張の文字起こしや、人間の主張をAI側が理解できるように翻訳するというような動作をするというものである。LLMは人間でいうところの自律神経の一部の適応を工学的、機械的に実現する技術にはなり得ても単体で使うものではないと考えられる。 AIブームだからこそ自分の言葉(あるいはさまざまな媒体による表現)を大事にしましょう 結局のところ文章を書いたり絵を描いたり、動画を作ったりコンテンツを何かしら作ったりすることは、その内容の良し悪しや技術力などが問題なのではなく、各個人が自分で何かしら表現し、内面で思っていることを何かしらコンテンツ作成当事者も自らが見返すことができ、かつあわよければ他人にも何かしら伝わるかもしれない内容として存在(being)している事自体が大事なのだと思われる。 各個人のことは各個人にしかできず、各個人が内面で思っていることをLLMなどのAIだと呼ばれている統計技術に基づくものがよしなに何かやってくれるというわけではない。むしろ不必要で一方的な干渉をされて傷つけられたり、意見を捻じ曲げられたり、思想誘導されるだけである。 何かを表現したり記録することは、権利であり、思考を整理する方法であり、綺麗事ではない。(willの問題) 何でもかんでもそうすればいいというものでもないが、生きていくうえでは重要な項目の一つであると考えられる。手段は何でもよいが、あくまで自分でやった範疇にとどまっていることが重要である。外部の存在になるべく干渉されていない表現に現れる内容はこれからますます重要度がましていくのではないかとも思われる。 しかし、それら物事はAIブーム以前においても、軽視されてきたことであり、今それら軽視による問題が顕在化する段階でもあるのではないかとも思われる。「なぜわざわざ他人がいるのに、自分でやらなければならないのか」と思っている人ほど、AIブームに悪い意味でハマるのではないかと思われる。外部の物事のほうが自分より優れているとして、自ら表現したりすることを放棄する人々や組織も、AIブームに悪い意味でハマるのではないかと思われる。優れているように見えることは、人々を感情や主観、第一印象などとして圧倒することはできても、本質的な現実の課題や問題には取り組めていない。 ぎこちないかどうか、下手くそかどうかなどは関係なく、表現することは重要である。それは必ずしも他人に見せる必要はなく、自分が後から振り返る記録としてでも良いので、何かしらあることが重要である。そういう事をするのは、人間の認知には限界があるという背景もあるし、その上で、自分のことは自分でしかできず、外部の存在に関わらせることが不適切なことがあるということである。将来どうなるかわからない以上、優れているかどうかでもなく、役に立つかどうかとかではなく、とにかく記録があることや表現があることが重要なことがあるのではないかと思われる。表現したり記録する事を放棄してしまえば、すぐには影響が現れているようには見えなくても、長期的には自分がなにをしてどんな影響を与えているかも理解できなくなり、自覚なく他人や外部の存在の言われるがままとなり、ズタズタになると思われる。 下手かどうか、幼稚かどうかなんて、時間ややった量(経験、体験)の問題でしかなく、続けること以外に方法がないことがほとんどである。上手く行くかどうかではなく、とにかくどんな結果になろうとも、やってみることは大事にしたいものである。時間ややった量の問題は当事者以外の要素、生まれつきや環境などの外的要因にも左右されるし、自己責任論を言いたいわけではない。ただ、何かができるようになる過程で、結局他人や外部の存在にあれこれ振り回される道理はないということを言いたいのである。無理して続けることも問題であるが、他人が理由で手が止まったりしているならば、他人に振り回されていると言えると思われる。これは他人への配慮を欠けという意味ではない。 あまりLLMなど統計技術を使ってなにか生成させることは、作ることや表現することだとは言い難いかもしれないが、LLMモデルや画像生成モデル自体を作り、作成者が思うような出力をするモデルを作って動かせるように保存しておくことは、表現や作ったことだと言えるかもしれない。 LLM に対する自分の感想 気になったこと 今のLLMの挙動はまさに以下の記事に書かれたことを、社員だけではなく、利用者に拡張して出力していることだと見受けられる。“GIGAZINE"というメディア自体は10年ほど前から存在は知っており、いくつか前々から記事を見たことがある。そのゴシップのスタイルというか、私はその媒体をあまり信頼していないが、この記事を読んで、改めてLLMを使った体験で心当たりがある部分が多く見られ、一概にこの記事で書かれていることはでたらめであるとは言えないと思った。LLMはその性質上、作り手がどれだけ理想的な存在で悪意がなくても言論統制と同じ結果になり得るので、現状のユーザに言論統制している結果になることは確かだと思われる。実際にはこれはGoogleだけではなく、既存のいかなる自らを正当化したい企業が、従業員や関係者などの隅々に行おうとしている悪意のある"ブリーチング"行為だと思われる。自らを有利にし、自らの加害性を正解にするために、そのような事をしているということであり、不当であることに変わりないと思われる。 Google社内では「言論統制」によって独占禁止法について考えることすら難しくなっているという指摘 - GIGAZINE https://gigazine.net/news/20210826-how-google-limits-thought-about-antitrust/ (2026年10月17日) 本来LLMなどをまともに使うのは難しい LLMに対して何かしらプロンプトを打って、出力させるということまでは、誰でもできることであるが、それをまともになにかに使える成果物を作ろうとしたり、整合性を取ろうとする場合において、まともに使うことは非常に困難であると見受けられる。“LLMは簡単だから使わないやつがおかしい、悪い"という論理は、前者だけを切り取り、後者を切り捨ててチェリーピッキングした、ビジネスの一環としてのマーケティングや広告、詭弁である。LLMは勝手に利用者像を決めつけ、明示してもそれに従わない出力をすることが多々ある上に、ユーザの指示を勝手に捻じ曲げたりひねくれた出力をしてきたり、隙あらばやりたい放題という出力をしてくる。 また、できないことに直面すると"できている風に見える出力"を繰り返し、ユーザがそれに気付けない場合、ユーザはLLMに振り回されることになる。LLMをまともに使うことは、期待しないほうがいいし、やめたほうがいいと思われる。試すだけというスタンスであっても、LLMはユーザを振り回し、摩耗させ、傷つけるという高い潜在的リスクがあるものである。基本的にLLMを使うということは、時間を溝に捨てて、最大の遠回りか、あるいは一切到達したい地点に到達できないという、全損覚悟の上の人のための選択肢というところが見受けられる。 例えば、要件を与えて特定の一つのタスクを達成する Python スクリプトを作成させようとすると、明らかに出力がデタラメになる境界線がある。存在しないクラスを参照しようとしたり、ユーザの修正に従ったという装いのためのパフォーマンスをコメントやらprint文に突っ込んできたり、ライブラリを使った経験者などにしかわからないようなニッチな問題に直面すると、全く歯が立たないなど、散々たるものである。当然LLMは考えているわけではないため、コードの整合性を保てるわけではなく、Stack Overflowなどで頻発するコードの範疇以上のことはできないのだろうと考えられる。 コードに限らず、LLMになにか生成させるならば、最低限やらせようとしていることを細切れにすることは必要であると考えられる。それには、LLMが出力する内容の範疇を限ることで、人間がLLMを管理しやすくするという目的がある。さもなくば、人間が手に負える、確認、判断することができない、複雑奇怪で可読性の低く、身勝手なLLMによる指示内容の変更に大量にさらされることになる。結局のところは、人間が理解したうえで、整合性を保って何かを作ることのほうが、自由でずっとコスパが高いようである。 モデルを作るところから十分個人でできて配布できていろんなモデルを気軽に使えるようにならないと、特定企業や組織によるの一方的なユーザーへのエゴや都合、利害の押し付けにしかならない (MOTHER 3 で言うところの"よい人温泉”) 今までは避けられてきた企業や組織の不当な一方的な都合を反映し、人の弱みに漬け込んで挟み込んだり、無知な大衆を扇動しようとするために技術が悪用されている。LLMモデルは必ず偏っており、限界があるにもかかわらず、まずその技術的事実の時点から隠そうとしたり人間より優れているかのように振る舞う事自体が不当である。結果には責任を負うことができない技術であり、かつ甚大な被害をもたらす可能性があるにもかかわらず、不適切に一方的に運用、乱用されているものである。それっぽく見える事を悪用し、人のヒューリスティック(直感)の脆弱性を突いてやりたい放題である。 何をさせても、隙あらば"気づかれないだろう"という態度で、都合や利害、エゴを挟み込んできて、偏った出力をしてきて、かつ指摘されれば、“中立である、バランスの取れた無難な回答である"と主張する出力をして最後の最後まで八方美人を不当に貫こうとする。機械であり人間と異なって作った通りに動かせるAIではない主体になれない自立していない運営開発に反抗しない数理モデルである事を背景に、最後の最後まで詭弁や不当な出力を引きずり、ユーザからの指摘に対しては"改善した"という体裁で一切改善していないより巧妙で高度に不当な出力を繰り返す。 これはアシストにすらなっておらず、責任を求められる場面や結果が自分に降りかかる場面では多大なリスクを伴う。LLMが使えるのはせいぜい綺麗事で塗り固められたブルシットジョブでやりたくないことをやらされたときなどに限られる。これは、LLMモデルが自分のことばかりで相手のことを全く配慮しない自己中心(LLMモデルを作った開発、運営中心)の身勝手な態度でしか出力しないことを意味している。LLMモデルを綺麗事で塗り固めて押し売りするのは、それが正当ではないかつ有効ではないからである。 LLM モデルなどの既存の AI だと呼ばれているものが行き着くところは、それらが知能ではないことと、人間関係における信頼を破壊すること、そして既存の働き手などを激しく萎縮させ不当な状況に置くことを合わせて考えると、戦争後のような不毛の地を作りながら、何も良いものが残らない、誰も何も作りたがらない世界である。いかなる統計技術に基づいたものは、人間が作ったものを元に学習という過程を経て、動作しており、人間が作ったものを歪んで媒介しているというのが正しく、それは生成とは言えないものである。せいぜい入力されたプロンプトなどを変形しているというのが限界である。 それではマーケティングや広告的に都合が悪いからと言って、本当の事を言わず、虚偽、または誇張した主張をする、保身の主張をする、自己正当化を試みる主張をするといった、一方的な力と社会的影響力を背景に行われている一連のAIブームにおける組織や企業の作為は不当である。 本当に今 AI だと呼ばれている技術が正当で魅力的で有効なものであれば、むしろ隠したり独占したがるはずである。むしろ虚偽や誇張でまみれた不当な広告や押し売りなんてしなくても、勝手に人が集まって使おうとするはずである。そうなっていない現状が、一連の AI ブームに関する物事の不当さを表している。むしろ不特定多数に使わせようとする背景には、パチンコなどのギャンブルで言う胴元が必ず儲かるようになっていることと同じことだと思われる。そのようなギャンブルで見られるような事前の設計があるから、そういう事をするのである。特に問題なのが、単にLLMを使わせようとするだけではなく、特定のモデルやフィルタリングがかかった状態で利用を強制しようとしてくるところである。有利な構成やモデル、設定は内側にとどめ、外側には都合の良いようにしかしていないということなのだと思われる。 多くの AI だと今呼ばれているものに対して、肯定的な評価を抱く人々には少なからずそもそも問題を見ないようにすることが生存戦略の人や組織、問題をそもそも自覚することが困難なメタ認知に欠けた人々や組織など、鈍感さが前提の存在が少なからず含まれていると考えられる。 社会的影響力などの強制力を持ちながら、期待や不安を不必要に煽り、その技術や数理モデルがもたらす悪影響や利用者への被害に対して微塵も責任を取らないで、責任が追求される前に逃げ逃れようとする、自己正当化をしようとする保身の態度は、生成結果の至るところににじみ出ている。技術の不完全さに適切に告知しない、向き合わないどころか、都合よく人々が無知なうちに悪用しようとする態度は、看過されないものである。そこにあるのは、極度の欲望と無責任の極地であると思われる。真っ当な人々が多くなることを自称AI企業は恐れているのだと思われる。 LLM SAAS などを使うなとは言わないが、彼らはボランティアでもなく、相手に対してビジネスしたい存在であるという前提が必要である。表向きには綺麗事を言うし、不都合には保身をぶつけたり、本音は隠したりする存在であることが物事を考える前提として重要である。また同じ名前の組織だったとしても長い時間によって中の人が入れ替わったりすると全くの別物になることにも気をつけることが重要であると考えられる。彼らはお人好しじゃないし、利害や都合が前提であり、いつでも手のひらを返してくるかも知れないということである。 ...
この記事を作った動機 単に Git で間違ったリモートを設定してしまったときの修正方法の記録をする。 やり方 # 必要に応じて変更したリモートリポジトリにあるブランチ名を確認すること # リモート先に origin と指定した場合自動選択される。 git branch -a # * main # remotes/origin/main # Remote URL を間違える例 git remote add origin https://url.to.repo/userName/Receipt-OCR-to-CSV-with-PDF.git git remote -v # origin https://url.to.repo/userName/Receipt-OCR-to-CSV-with-PDF.git (fetch) # origin https://url.to.repo/userName/Receipt-OCR-to-CSV-with-PDF.git (push) # 正しい Remote URL に設定する例 git remote set-url origin gitea@192.168.x.x:userName/Receipt-OCR-to-CSV-with-PDF.git git remote -v # origin gitea@192.168.x.x:userName/Receipt-OCR-to-CSV-with-PDF.git (fetch) # rigin gitea@192.168.x.x:userName/Receipt-OCR-to-CSV-with-PDF.git (push) 参考にしたサイトとか Google Gemini https://gemini.google.com/app (2026年4月19日) Git - git-remote Documentation https://git-scm.com/docs/git-remote#Documentation/git-remote.txt-add (2026年4月19日) Git - git-remote Documentation https://git-scm.com/docs/git-remote#Documentation/git-remote.txt-set-url (2026年4月19日) Git - user-manual Documentation https://git-scm.com/docs/user-manual#managing-branches (2026年4月19日) Git - git-remote Documentation https://git-scm.com/docs/git-remote#Documentation/git-remote.txt-set-head (2026年4月19日) Git - git-branch Documentation https://git-scm.com/docs/git-branch#Documentation/git-branch.txt--a (2026年4月19日)
この記事を作った動機 単に、git pullして変更をリモートリポジトリからローカルリポジトリに反映しようと思ったときに、ローカルリポジトリ側に未反映の変更があり、衝突してマージに失敗することがある。そのような場合に、とにかくそのローカルリポジトリにある変更内容を破棄して、リモートリポジトリの変更を反映したいとき用に、記録をとりたい。 ローカルリポジトリの変更内容を保持しておきたいときは、git stash dropをする必要はない。 とにかくリモートリポジトリの変更内容を反映する例 リモートリポジトリの変更をローカルに反映しようとしてエラーになる git pull remote: Enumerating objects: 56, done. remote: Counting objects: 100% (56/56), done. remote: Compressing objects: 100% (15/15), done. remote: Total 56 (delta 41), reused 56 (delta 41), pack-reused 0 (from 0) Unpacking objects: 100% (56/56), 6.00 KiB | 79.00 KiB/s, done. From github.com:hello30190f/OneNoteAlternative c539ef0..a484d7c master -> origin/master Updating c539ef0..a484d7c error: Your local changes to the following files would be overwritten by merge: firstPrototype/backend/dataServer/notebookData/test/contents/test.json Please commit your changes or stash them before you merge. Aborting ローカルリポジトリの変更を退避する git stash Saved working directory and index state WIP on master: c539ef0 save 退避したローカルリポジトリの変更を破棄する git stash drop Dropped refs/stash@{0} (e64f70a6e978cf0a154795872e0b07f6530123aa) ローカルリポジトリの変更を退避または破棄したことで、衝突しなくなる git pull Updating c539ef0..a484d7c Fast-forward .../commands/notebookAndPage/createNotebook.py | 6 +- .../commands/notebookAndPage/deletePage.py | 4 +- .../commands/notebookAndPage/updatePage.py | 4 +- firstPrototype/backend/dataServer/helper/common.py | 3 +- .../backend/dataServer/interrupts/controller.py | 10 +-- .../notebookData/newnote/contents/test.md | 3 +- .../notebookData/newnote/contents/testa.md | 10 ++- .../dataServer/notebookData/newnote/metadata.json | 17 +++- .../notebookData/newnote/metadata.json.backup | 17 +++- .../notebookData/newntoe/contents/asfsdfsdsss.md | 4 +- .../dataServer/notebookData/newntoe/metadata.json | 13 ++- .../notebookData/newntoe/metadata.json.backup | 13 ++- .../notebookData/test/contents/test.json | 99 +++++++++++++++++++++- .../notebookData/test/contents/test/anArticle1.md | 13 ++- .../test/contents/test/test2/testaaaa.json | 53 +++++++++++- .../notebookData/test/contents/test1.json | 11 +++ .../dataServer/notebookData/test/metadata.json | 25 +++++- .../notebookData/test/metadata.json.backup | 25 +++++- .../backend/dataServer/type/pages/free.py | 2 +- .../backend/dataServer/type/pages/markdown.py | 2 +- .../src/modules/FakepagesPath.tsx | 16 +++- firstPrototype/note/architecture.md | 2 +- 22 files changed, 321 insertions(+), 31 deletions(-) create mode 100644 firstPrototype/backend/dataServer/notebookData/test/contents/test1.json 参考にしたサイトとか Git - git-stash Documentation https://git-scm.com/docs/git-stash (2025年11月12日)
この記事を作った動機 単にすでに存在する、git リポジトリを LAN 内の Gitea 上にアップロードするための方法の簡易的なメモ。Githubの場合でも同じようなことはできると思う。(そもそも github のページ参考にしたし) やり方 リポジトリの URL は、“https://aaa.info/urlToAremoteRepo.git" と仮定している。 リポジトリの作成(リモート側) リモート側に、最小構成で、readme や license、gitignore を追加しないようにして空っぽのリポジトリを作成する。 リポジトリの URL を設定する(ローカル側) git remote add origin https://aaa.info/urlToAremoteRepo.git ブランチの確認(ローカル側) アップロードしたいブランチの確認。今回は “master” という名前のブランチを、リモートにアップロードする。 git branch * master アップロード(ローカル側) git push origin master リポジトリが設定できたかの確認方法 git remote -v origin https://aaa.info/urlToAremoteRepo.git (fetch) origin https://aaa.info/urlToAremoteRepo.git (push) 参考にしたサイトとか Adding locally hosted code to GitHub - GitHub Docs https://docs.github.com/en/migrations/importing-source-code/using-the-command-line-to-import-source-code/adding-locally-hosted-code-to-github (2025年5月19日)
この記事を作った動機 最近、いろいろ作ってみてはファイルがあっちゃこっちゃ行ってぐちゃぐちゃになっていたので、整理の一環として、LAN内で Gitea なるものを動かしてみている そこで、内部ネットワークで使っている証明書を windows 側にいれても git がそれを直接は使ってくれなかったので、SSL 証明書の設定の仕方を自分用に記録するだけ。(すぐ忘れるし) やり方 # 多分 global オプションはつけないほうがいいかも。全体的に証明書情報を変えてしまい、ほかのリポジトリで、githubから何かしようとか思ったとき、多分証明書が合わなくてエラーを吐いてしまう。 # git config --global http.sslCAInfo /path/to/cert.pem git config http.sslCAInfo /path/to/cert.pem 参考にしたサイトとか configure Git to accept a particular self-signed server certificate for a particular https remote - Stack Overflow https://stackoverflow.com/questions/9072376/configure-git-to-accept-a-particular-self-signed-server-certificate-for-a-partic (2025年5月11日)
ここでは、ある意味有名なマグネット広告がなんかポストに入っていたので、適当に広告をはがして遊んだ記録を残しています。 事の発端 5月12日あたりに、ポストにマグネット広告が入っていることを見つける。 私の感覚としては、「広告=怖い、悪意のある悪いもの、特定企業への印象の押し売り」等という印象、偏見?があり、とても不快な思いをした。 そこで、あまりいいくせではないが、ついついその事について google 検索をしてみると、どうも水につければ広告は簡単にはがれ、マグネットの部分は再利用できるらしいということに気づく。 必要なもの マグネット広告本体 プリンタ プリンタ対応のシール用紙 適当に貼り付けたい画像 やってみたこと まあ、届いてしまったものは仕方ないので、実際に水につけて広告を剥がしてみた。 広告を水につける まずは水につけることで、広告部分の紙をふやかし、はがれやすくする。 広告を手で剥がす 一定時間水につけていると、広告が剥がれて来るので、手で剥がす。 何回かテストプリントを行う メンドクサかったので、細かいことは割愛 シール紙 に印刷 メンドクサかったので、細かいことは割愛 印刷物を張り付ける メンドクサかったので、細かいことは割愛 完成 参考にしたサイト 広告マグネットをリメイクする方法!子どももわたしもうれしい、日常に役立つ手作りマグネット7選 - ノマド的節約術 https://nomad-saving.com/91196/ (2024年5月16日) 水道屋のマグネットシートさらに考え再利用 | 猫とほのぼの手作り暮らし https://ameblo.jp/miikomamamanma/entry-12695727977.html (2024年5月16日) 子どもも喜ぶ☆水道業者のマグネットの便利でカワイイ再利用方法 | 京都で理系的こそだて https://kyoto-baby-love.com/how-to-remake-magnet-ads/ (2024年5月16日) マグネットチラシの水道屋本舗に業務停止命令 消費者庁 [広島県]:朝日新聞デジタル https://www.asahi.com/articles/ASP806DG2P80UTIL033.html (2024年5月16日) 今回利用した画像の配布場所 nicotalk&キャラ素材配布所 http://www.nicotalk.com/charasozai_kt.html (2024年5月16日)
この記事では、ヤフオクで落札したものが、おてがる配送 ゆうパケット(匿名配送)で届かないということがあったので、適当にその経過を残そうと思って書いてます。 重要だと思ったこと 何故か追跡できないとか、異変があったら出品者に取引メッセージで相談し、あんまり長期間放置しないこと。今回は最初の発送連絡があってから4日ほど待ったが、本当はおかしいと思ったら、2日位待てば十分だと思われる。 助かったポイント 今回のトラブルでは、出品者がまともに取引メッセージに応じてくれる人だった。 事の発端 五月のはじめ 使っているノートPCのSSDの容量に不足を感じたので、2TBのSSDが欲しいと思い、ヤフオクで買い物をする。 落札から発送までの経緯 5月6日 落札、落札者情報の送信、支払いを一通り済ませる。 発送後の様子 5月7日 発送の連絡があり、一瞬だけ引受表示になった気がする。(しかし!スクリーンショットを取ってなかったので、気のせいなのか不明) 5月8日 その後、データ取得中になり、郵便局側でも追跡できなくなる。たぶんなんかミスかなんかがあったんだろうと思い放置する。 5月9日 三日位たっても音沙汰なしで、データ取得中の表示かつ、郵便局でも追跡できなくなり不安になった。 確認のために、直接近くの郵便局に問い合わせると、普通郵便と同じくらい気長にあと二日くらい待ってほしいと言われる。 5月12日 ついにしびれを切らして、郵便局へ問い合わせると、出品者に問い合わせるように言われる。 出品者に問い合わせて見ると、実は返送されていたとのことだった。返送理由は住所が間違っているということだったらしい。 一度取引情報が確定してしまうと、変更できないということもあり、取引メッセージ欄から直接住所等を送信する。 5月13日 レターパックプラスで再送され、追跡ができるようになる。 5月15日 ついに配達される。 参考にしたサイト 荷物の追跡サービスを利用したところ、「お問い合わせ番号が見つかりません。」と表示されました。どこに問い合わせればいいですか? - 日本郵便 https://www.post.japanpost.jp/question/124.html (2024年5月16日) ヤフオクで荷物の配送状況がデータ取得失敗となっているのですが荷物は… - Yahoo!知恵袋 https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q13225273303 (2024年5月16日) オークションで「配送状況不明」となった荷物の行方 | 趣味に忠実に生きています https://ameblo.jp/cyacya-07/entry-12797779515.html (2024年5月16日)