flat7th

* 日々のメモ

* 日々のメモ2023 | * 日々のメモ2022 | * 日々のメモ2021 | * 日々のメモ2015 | * 日々のメモ2014 | * 日々のメモ2013 | * 日々のメモ2012 | * 日々のメモ2011 | * 日々のメモ2010 | * 日々のメモ2009 | * 日々のメモ2008 | * 日々のメモ2007 | * 日々のメモ2006 | * 日々のメモ2005 | * 日々のメモ2004

2024-02-06

2月ですね。雪の後って部屋が明るくて、それはいいです。でも寒いのはつらいね。
もういくつ寝ると…確定申告。
人生の出来事を一つづつ。自分も時間に沿って進む。
方向は「沿う」のだけど、なぜだか対数目盛りである気がするよ。
置いてかれる。老いて枯れる?ワハハ

* 日々のメモ
real name: memo/20240206

2024-01-22

これからは oss の イベントループ を使おう、という独り言。




ネットワーク上で何らかの通信を行うプログラムを作る時には、…なんていうと今どきはあらゆるプログラムが通信を行うので全部になってしまうのだけど。

通信するプログラムを作るときには実装の基本方式がいろいろあって、プログラマはそういう「実装方式」を自分で列挙して、試して(つまり作っては壊してを繰り返し)、自分なりの一番好きな方式を選択する必要があると思う。でも、なかなかの作業量になるので、重い腰が動かないもの。なので、人生を通して特定の「案件」で経験することで、そういった試行、試作、思考、選択を行っていくものなのだと思う。

自分には、「ブロッキングソケットでselectによる多重」方式、でとても成功した経験が複数ある。それ以外の方式、大量のスレッドを作る方式や、非同期ソケットの方式、には逆に失敗した経験の記憶が張り付いていて、「言葉にできないが避けたい気持ち」を持っている。それが良いのか悪いのか、今となってはよくわからない。

自分は select を使うメインループライブラリや、 epoll を使ってメインループを書いたことがある。成功した。
Windows (.net) で動く、非同期ソケット方式のメインループも書いたことがある。やりきったけどその後消えた。
Java で動く、スレッド多重方式の通信処理を書いたこともある。これも、消えた。
それらは、案件で作ったコードで、顧客企業の持ち物 なので、一般公開はできない。そもそも手元にもない。
メインループライブラリ上でアプリを書くノウハウも、基本概念は使えるけど、細かい話は流用、応用できない。

だから、これからは メインループまで自分が書くのではなく、他の人が書いた 公開されているメインループを使って仕事をしようと思ったことであるよ。




「ブロッキングソケットでselectによる多重」方式が好き:
libev が良いと思う。
libevent の version2 が良い。(include <event2/event.h>)

「ノンブロッキングソケット」方式は嫌い:
libuv は、自分は好きじゃない。
POSIX だけでなく Windows のソケットライブラリと親和性を高めるには必要だけど。

ソケット以外の観点でも、Windows はプログラマにやたらと要求が多くて、嫌い。OSの設計や基本ポリシーが洗練されていれば、プログラマが個々に悩まなくて済むことが、いちいち引っかかる。Windows の、そういうところが嫌い。なので、Windowsと共通化するためだけに必要で、余計な複雑性を持ち込む libuv は、好きじゃない。





面白そうなページを見つけたので後で読みたい。
と言って読まないことも多いのだけどさ。


* 日々のメモ
real name: memo/20240122

2023-12-25

vscode で ${HOME}直下の ドット始まり名フォルダだけ隠したい

わからん。

設定
 files.exclude

以下を足すと、すべてのドット始まりが消える
   **/.*

以下を足すと、OpenFolder で開いた直下のドット始まりが消える、ように見える
   /.*

これでなんとかやり過ごす。

* 日々のメモ
real name: memo/20231225

2023-12-21

bashの数値計算でゼロがアタマに付いていると8進数になる件




bash の
$(( 20 + 1 )) で計算ができて expr 20 + 1 コマンドとだいたい同じだが、
アタマにゼロが付いていると、8進数として解釈されて、意図した結果とは異なってしまう。

[keizo@fedora _KNOW-HOW]$ echo $(( 020 + 1 ))
17

expr は微妙に違うらしい。

[keizo@fedora _KNOW-HOW]$ expr 020 + 1
21

アタマに 基数# をつけて 10#020 とすれば、10進数の20、として認識される。

[keizo@fedora _KNOW-HOW]$ echo $(( 10#020 + 1 ))
21






* 日々のメモ
real name: memo/20231221

2023-12-11

私から、全世界のIT業の方たちへ、本気で問いかけます。

Linuxを基本OSとしてインストールし開発をして、仮想環境でWindowsをインストールしてOfficeソフトを動かすようにしませんか?
なぜそれができないんですか?

* 日々のメモ
real name: memo/20231211

2023-11-11

Fedora 29 の emacs 29.1 で起動時にWarning が大量に出力される

暫定対処
.emacs に以下を記載

(setq comp-async-report-warnings-errors nil)

参考
https://www.reddit.com/r/emacs/comments/15noucl/291_how_can_i_resolve_these_warning_at_launch/

* 日々のメモ
real name: memo/20231111

2023-11-01

問題


Fedora38
Rhythmbox で DLNAサーバ上のファイルを再生したい。

解決


  • 以下をインストールする
    • dleyna-connector-dbus

  • Rhythmbox のプラグイン設定で以下を有効化する
    • Griloメディアブラウザー


操作ログ


[keizo@fedora ~]$ dnf list --installed |grep -e 'dleyna' -e 'grilo'
dleyna.x86_64 0.8.3-1.fc38 @updates
dleyna-renderer.x86_64 0.8.3-1.fc38 @updates
dleyna-server.x86_64 0.8.3-1.fc38 @updates
grilo.x86_64 0.3.16-1.fc38 @updates
grilo-plugins.x86_64 0.3.16-1.fc38 @updates
[keizo@fedora ~]$ dnf search --all dleyna grilo
メタデータの期限切れの最終確認: 5 days, 0:21:26 時間前の 2023年10月27日 16時14分22秒 に実施しました。
========================================== 名前 & 説明 & URL 一致: dleyna ===========================================
dleyna.x86_64 : Services and D-Bus APIs for UPnP access
dleyna.i686 : Services and D-Bus APIs for UPnP access
=========================================== 名前 & 説明 & URL 一致: grilo ===========================================
grilo.x86_64 : Content discovery framework
grilo.i686 : Content discovery framework
======================================= 名前 & 概要 & 説明 & URL 一致: dleyna =======================================
dleyna-connector-dbus.x86_64 : D-Bus connector for dLeyna services
dleyna-devel.i686 : Development files for the dLeyna components
dleyna-devel.x86_64 : Development files for the dLeyna components
======================================= 名前 & 概要 & 説明 & URL 一致: grilo ========================================
grilo-devel.i686 : Libraries/include files for Grilo framework
grilo-devel.x86_64 : Libraries/include files for Grilo framework
grilo-plugins.x86_64 : Plugins for the Grilo framework
grilo-plugins.i686 : Plugins for the Grilo framework
============================================== 名前 & URL 一致: dleyna ==============================================
dleyna-renderer.x86_64 : Service for interacting with Digital Media Renderers
dleyna-server.x86_64 : Service for interacting with Digital Media Servers
[keizo@fedora ~]$
[keizo@fedora ~]$
[keizo@fedora ~]$ sudo dnf install dleyna-connector-dbus
[sudo] keizo のパスワード:
Fedora 38 - x86_64 - Updates 5.9 kB/s | 5.4 kB 00:00
Fedora 38 - x86_64 - Updates 1.5 MB/s | 2.5 MB 00:01
Fedora Modular 38 - x86_64 - Updates 11 kB/s | 5.2 kB 00:00
RPM Fusion for Fedora 38 - Free tainted 7.4 kB/s | 10 kB 00:01
依存関係が解決しました。
=====================================================================================================================
パッケージ アーキテクチャー バージョン リポジトリー サイズ
=====================================================================================================================
インストール:
dleyna-connector-dbus x86_64 0.8.3-1.fc38 updates 14 k

トランザクションの概要
=====================================================================================================================
インストール 1 パッケージ

ダウンロードサイズの合計: 14 k
インストール後のサイズ: 20 k
これでよろしいですか? [y/N]: y
パッケージのダウンロード:
dleyna-connector-dbus-0.8.3-1.fc38.x86_64.rpm 127 kB/s | 14 kB 00:00
---------------------------------------------------------------------------------------------------------------------
合計 38 kB/s | 14 kB 00:00
トランザクションの確認を実行中
トランザクションの確認に成功しました。
トランザクションのテストを実行中
トランザクションのテストに成功しました。
トランザクションを実行中
準備 : 1/1
インストール中 : dleyna-connector-dbus-0.8.3-1.fc38.x86_64 1/1
scriptletの実行中: dleyna-connector-dbus-0.8.3-1.fc38.x86_64 1/1
検証 : dleyna-connector-dbus-0.8.3-1.fc38.x86_64 1/1

インストール済み:
dleyna-connector-dbus-0.8.3-1.fc38.x86_64

完了しました!
[keizo@fedora ~]$


RPM Fusion


https://docs.fedoraproject.org/en-US/quick-docs/rpmfusion-setup/


* 日々のメモ
real name: memo/20231101

2023-10-25

うちの親も、もう次の免許更新が非現実的。自分が近くに住むのか、どうするのか。地域交通の課題解決を考えないといかん。

過疎地・準過疎地向けに ハイエースバンだけを運用する、乗り合いタクシーとバスの中間みたいな交通ってできないだろうか。


コース運行の予定はするけど、スマホアプリから走行リクエストが1件以上入ってる便だけ走る。
コースが超たくさんあって、1コースは出発点から終点まで30分以内で組む。
なので、原則としては 便がスタートする時刻の 30分前に「乗ろう」と決断すれば、リクエストして乗れる。

ただしドライバーと車を、リクエストの100%に答えられるように備えるのは無駄・ムラ・無理になるので
統計的に最適な数を用意する、しかない。そうすると、リクエストにこたえきれないことが必ず生じる。どうするか。うーむ。


NFCというかタッチ式の装置を全装備。もし、前の1本がたまたま来て乗ってしまったら、後ろを走っている本来の便には自動で1人分のキャンセルを通知。

顧客1人ごとの乗車リクエストを管理できるITシステム(データ量、データ処理速度)と
インフラストラクチャー通信速度(電波通信帯域)、通信の確実性が必要。


* 日々のメモ
real name: memo/20231025

2023-10-24

[あの三省堂から、オタク用語辞典「大限界」登場 今の若者が使う1600用語を収録]
https://www.itmedia.co.jp/news/articles/2310/24/news136.html

だそうです。「口から音源」でワロタ

* 日々のメモ
real name: memo/20231024

2023-10-17

php7 から php8 に移行したのをきっかけに、phpまわりいじっています。

あるphpソフトウェアで、「効果のないデストラクタ(風の処理)の定義と呼び出しが全面に渡って存在していた」のを削除しました。

この例、プログラミングのアンチパターンの一つ、「オブジェクト指向(などその時代に目新しい作法)を無条件に良いものと勘違いする」の、具体例の一つだと思う。

プログラミングの作法というか様式というか、良いとされる書き方や、良いとされるプロジェクト運用手順が、時代ごとにいろいろあります。
でも、自分の頭でそれがなぜ必要なのか、どう良いのか、考えないとソフトウェアは良くならないです。

直せるときには、直す。

* 日々のメモ
real name: memo/20231017

2023-10-03

アツい人の話を読むと、自分の心にアツい想いが蘇って来る気がします。

まだ、10章のうち3章ですけど。

個を動かす 新浪剛史 ローソン作り直しの10年
池田信太朗
日経BP
https://www.amazon.co.jp/dp/482227408X
(ステルスマーケティングじゃないです。自分は図書館で借りましたし)



ご本人の著書ではない研究本なので、ややキャラクターが誇張された記載もあるのだろうな、とは思います。
でも、だからこそなのか、読み応えあります。


この本と直接は関係ないのですが、先日、今までとは別の「人の集まり」…というか、音楽イベントに参加したところ。
今までの交友関係とはだいぶ違う、ナイスで素敵な方々(男性も、女性も、多数)と知り合うことができてですね。
自分の心がなんというか、とてもすがすがしい気分になったのです。

自分の近くに素敵な人がいると、自分も前向きになれる。
アツい本を読むと、自分もアツくなれる。

その逆もあり、で「逆」にも2種類あり。
後ろ向きな人といると自分も後ろ向きになるし、
自分こそが後ろ向きな人で、周りの人を暗くしていたかもしれない。

前向いて生きよう。
どうせ100年もすりゃ死ぬけどさ。それは今じゃないと、その瞬間まで思い込んでおきゃいいよ。
その瞬間が来たら、しれっと「えー、びっくりしたよーwwww」って、わざとらしく派手に驚いてやりゃいいさ。

* 日々のメモ



2023-10-11 読了。

後半、まとめの方向がちょっと分からない点もありました。

1章から6章はアツい話集。
7章あたりからの「システム」の話があり、コンピュータシステム屋としての自分は これこそ一番 真剣に読むべき所なのかもですが、
このへんから「お勉強」感が強くなってきてページが進まなくなりました。
最後に向かって、「個々の店」「個々の顧客」に着目点を集めていき、
最終的には 新浪さんという「個人」の記事でおしまい。

読み物として前半のアツい話が面白かったかな、と。

と書いてから、タイトルが「を動かす」だったことに気づきました。
なるほど。店も、従業員も、顧客も、経営者も、個を見ていこうぜ、というまとめなのね。



追記 10/17
ふと、うがった見方が頭に浮かんだ。もしや、著者 池田さん は「セブンに対して経営論を意見している」のだろうか?
(新浪さんが、ではなく、池田さんが、ですよ)
real name: memo/20231003

2023-09-29

日常の言葉は弁別できる範囲で省略される訳ですが

音楽で「パート」とだけ言うと、
  • 声部のパートと
  • 曲構成のパートで

タテヨコが違う概念が同じ語になって、紛らわしいですね。部品のパーツの単数形か。そりゃそうだ。

ケータイは
  • 携帯型無線電話基地局なのか
  • 携帯型対戦車ミサイルなのか

問題と類似です。リビングルームで「ありゃ?ケータイないぞ?」はほのぼのした話題ですけど、状況によっては「おい!ケータイないぞ!」は死活問題です。

パートさんは
  • パートタイムワーカーなのか
  • パートタイムラバーなのか。

この場合「主婦のパートさん」と主体を付加しても曖昧性は解消せず、後者かもしれないですよね。

あれだ。高校の英語の授業で教わった知識ですが、古い英語圏文化では男性が女性に求婚するものだという性差意識があって、男性をLover(愛する人)と言って女性をLove(愛される人)と呼ぶそうなので、ワンダー先生の曲で言う パートタイムLover は、男性を指すのでしょうね。ああ、でも主婦は主夫と音が同じなので「主夫のパートさん」は後者かも。面倒くせぇ…
おっと、

ワンダー先生は
  • スティービー・ワンダーさんなのか
  • 風呂水ワンダーなのか。

「ワンダー先生、いいよね」という語りかけは一体何を意味するのか。場合によっては、対戦格闘ゲームの2択状況並に身構える必要があるのではないか。えっと、分からないかもですがテレビゲームの話でジャンケンみたいなものです。そして、状況に備えて日々練習しておく必要があるのではないだろうか。ガガガッ。シュターン!(`・ω・´)シャキーン


受け取る側の文脈認識を意識して、意識齟齬のない様に言葉を使って行きたいです。

* 日々のメモ
real name: memo/20230929

2023-09-28

直流の電圧変換回路(DC/DCコンバータ)を勉強中ですが挫折気味です。

それはそれで。本を読んでいて改めて思ったこととして、電気回路って、配置思考的というか、位置関係思考的なところがあるなぁ、と。

ソフトウェア設計も、電気回路の設計みたいに、カタマリの配置で特性が生じたり、何々方式と名付けがなされたり、そうならんものだろうか。

ギター演奏の上達過程にて、コードフォームを「図形的に」暗記することで思考がショートカットできる、という時期があります。まぁ、そこから少し進むと、そういうショートカットでは進めなくなって、基礎からやり直すという再学習行為が何度も必要になるのですが…。でも図形思考で上達する時期があるのは、間違いないし、その思考方法はもっと上達した段階でも、全く無駄にはならないです。

で、ソフトウェアにもそういった「図形的な」思考で、組み上がったロジックの出来が良いとか悪いとかの判断を、一部ショートカットできる、ような方法があるのでは?と思って探しているのです。ずっと。クラスの役割とトポロジカルな配置に名前を付けて、ソフトウェアの「デザインパターン」と呼んだ時期がありましたけど、なんかあの話って結局は滑って終わった感があります。当初期待された壮大なゴールに着地できなかった。
ソフトウェアのプリミティブ要素とは、何と何だろうか、という研究が、足りていない気がするんです。それがいわゆるGoF本だと、OOP言語のクラス。ダイクストラの構造化プログラミング論だと {順列 | 条件分岐 | 繰り返し} でしたっけ。

でもそのもうちょっと中間あたりのサイズで、「ソフトウェアの構成要素はコレとコレとコレだ」っていい感じに抽出したもので、図形的に考えることが上達の助けになるようなもの、って無いですか?という話。


* 日々のメモ
real name: memo/20230928

2023-09-27

2023-09-27

尊敬するハッカーさん、 shi3z さんのnote記事。勉強になります。内容も、記事の構成も。

「アイデアに価値はない」https://note.com/shi3zblog/n/n0a9f468f6fc5





《生成AIが流行して、昔の知り合いとか、取引先とかから唐突に「アイデアがあるんだけど聞いてくれ」と言われることが増えてきた。まず大前提として、僕にアイデアを話すのはやめてほしい。時間の無駄だ。》


(pythonスクリプトで単語をランダムに並べるだけで、「アイデアのような文」はいくらでも作れる、という実例。物量の例示の意味もある。)


《どれだけいいアイデアであったとしても、それ単体ではなんの意味もなさない。(中略)大事なのは(中略)「なぜ自分がやるのか」というナラティブ【物語】である。》

《たとえば「自分はいじめにあっていて、⚪︎⚪︎だけが救いだった。だから⚪︎⚪︎をやりたい」みたいなナラティブ【物語】は、強烈だがネガティブであり、ネガティブな感情をベースとした事業計画は応援しにくい。仮に本当にそうだとしても、説明するとすれば、「自分は昔から⚪︎⚪︎が好きだった」のほうがずっといい。

ただ、「⚪︎⚪︎が好きだった」というのはあまりにも陳腐で、どれくらい好きだったか、どのくらいその分野に詳しいのか、人に負けないポイントはどこなのか、といった点が大事になる。》


《どんなアイデアがあろうとも、形にできなければ、それは寝言と同じだ。》




思いついただけのアイデアには価値はなく、実現することが大事、という話だと思います。
その本題とはちょっとズレて、上記「転」のところが心にとまりました。


音楽の趣味をやっていて、いろんな方のステージを見ます。
ステージというか、歌の歌詞で何を歌っているか、とか。

音楽でも感じることとして、ネガティブな感情はとても強い動機になって、強烈な力を持ちます。

でも、SF映画スターウォーズの「暗黒面」と同じで、ネガティブな強さは、自分自身を蝕むんです。
それに、ネガティブな感情のそのままでは、誰かに聴いて頂く歌として、成立しない気がします。

ネガティブな感情を、どうやって前向きな力に軌道修正したか、の【物語】が、大事である気がしています。

自分もまだまだ、できていないですけど。


* 日々のメモ
real name: memo/20230927

2023-09-19

こんばんは。

ニュースキャスターが、ニュース番組冒頭で「おはようございます」とか「こんばんは」とか、挨拶語を話すようになって久しいですね。
昔はなかった習慣ですよね。

その昔、マクドナルドで「いらっしゃいませ今日はー」との挨拶に違和感を感じていた私、なのですが。
このところは、テレビに挨拶を返すようになってきました。もう完全にオッサンというか老人です。
そして何故か、ニュースキャスターの「こんばんは」に対して、「わんわんお」と返したくなるのです。衝動的に。



「わんわん」は犬の鳴き声(吠え声)の擬音語ですね。またそれに由来して幼児語として犬そのものを意味したりもしますね。

2ch(今は5ch)などのネットオタクの巣窟にて、語の意味がかろうじて分かる程度にカナを1文字足したり、長音を挟んだり、変な所を音便化して言葉を崩す、という謎の文化があります。

猫→ネッコ
犬→イッヌ
兄→アッニ
姉→アッネ
おっぱい→オパーイ
セックス→セクース

などです。もしかしたら、性的な語など、人間がタブー視する語に対し、直接表現する事をやんわり避けようとする意図も、あったのかも知れません。



「わんわんお」というのもおそらくその様な「ネットオタク語」の一種なのでしょう。加えて推測するに、「犬の、飼い主に対する親愛の感情が溢れて興奮しているさま」を表現するために、犬のセリフ表現として「わんわんお!わんわんお!」等と使うのだと思います。

この「わんわんお!」が私の脳に焼き付いており、更に高齢男性特有の「異様にダジャレ好きになる」性質が発露しているためと思われるのですが、

ニュースキャスターが夜のニュース番組冒頭で
「こんばんは」
と挨拶をすると、自分の中の会話エンジンが働いて
「わんわんお」
と返したくなるのです。

「こんばんは」
「わんわんお」

実際の対面のコミュニケーションで行ったらきっと、奇異な目で見られるか、「はぁ?」という困惑の反応が起きる事でしょう。

なのですが、私の脳内では 自然なやり取りとして
「こんばんは」に
「わんわんお」を
返したくなるのです。実際に返しています。

はあ。困ったもんです。



昨今のAIというか「機械学習の機械」は、"A"という語の後に"B"という語が続く可能性が高いとか低い、とかの計算をべらぼうな数で行っている、などと言われます。
脳の神経細胞、ニューロンの活性化が連鎖する様を模したのが始まりで、今はもうちょっと工夫しているのだそうです。

この「連続性」の学習が、私の脳内で、壊れてきているのかも、しれません。こんばんは。わんわんお。



今どきの、GPUをフル活用するAIなど、私にはもう実装する力がありませんが…

私は駆け出しの頃、
「Webページの内容を読み、カテゴリを疑似統計的に判定する」
アルゴリズムを考案して実装し、納品したことがあります。

というか、私の独立第一号の仕事が、それでした。
「カテゴリ判定するようなプログラムを作れないか」と友人から相談され、うーん、できると思う、と作り始めました。


判定したいカテゴリに何があるかは、人間が決めます。
・スポーツ
・政治
・エロ
・グルメ
など。カテゴリ数は固定です。この場合4つです。実際には友人が選んだ5つのカテゴリだった気がします。

ここから私の考案でした。

そのカテゴリごとに学習対象のWebページを複数選んで、

特徴単語として
・3文字以上の漢字の連続
・4文字以上のカタカナの連続
を抽出し、特徴単語の頻度分布表を作ります。

カテゴリ1個に対し、単語の頻度分布表が1個できます。


次に、任意のWebページのカテゴリを判定します。

判定したい Webページにも同様の単語抽出を行い、
予め学習していた全カテゴリ(4つ)のヒストグラムと、判定対象のWebページのヒストグラムをかけ合わせます。

かけ合わせた値の合計を求めます(積分値みたいなもの…という解釈でした)。
この値が一番高い「カテゴリ」を、該当Webページのカテゴリと判定します。



これを、コトバの通りの順に処理するよう組むと遅いので、読んでいるWebページをパイプで判定プロセスに流すと
単語抽出と全カテゴリのスコア計算を随時行い、全部通したらもう答えが出る、ようにしました。



実際には、当初思ったようなデータ(きれいな波型のようなヒストグラム)は得られなくて。
横軸に単語を並べると ゼロ ゼロ ゼロ ... ばかりが続く後に イチ がまれにある、ようなデータでしたが。
へー、と思う程度に判定できていました。

当時、ネット回線速度が遅いこともあって、CPU処理速度に対し通信の待ち時間が長く、
ページを読み終わると即座に判定値が得られるようなプログラムになりました。



オッサンの脳がダジャレでイカれているという話と、
過去に作ったプログラムを懐かしむ話。
でした。


* 日々のメモ
real name: memo/20230919
次の15件 >>