flat7th

* 日々のメモ

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

2024-03-06

生きる。それは、確定申告。
カムチャツカの若者も、確定申告。

我泣きぬれて、確定申告。

雨止みを待ちながら、確定申告。

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

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 39 の emacs 29.1 で起動時にWarning が大量に出力される

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

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

参考
reddit:29.1 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
次の15件 >>