2024/06/15

第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT

第26回redmine.tokyo勉強会にスタッフとして参加してきた。
久しぶりに常連や新しく知り合った人たちと話して気づいたのは、多様な属性の人達が集まり多様なテーマで議論するのがコミュニティの醍醐味ではないか、と思った。
ラフな感想をメモ書き。

【参考】
第26回勉強会 - redmine.tokyo

2024/6/15 第26回勉強会 - redmine.tokyo #redmineT - Togetter [トゥギャッター]

プリザンター|OSSのノーコード・ローコード開発ツール

【1】勉強会の場所は、OSSツールPleasanterを運営しているインプリム様の会場を借りて開催した。
映像、音響も非常に良く、そのまま懇親会の会場で、宅配のピザ、缶ビールやジュースの買い込みもできて、バーのカウンターもあって盛り上がった。
インプリム様には快く会場を提供して頂き、非常に感謝いたします。

今回の勉強会で気づいた内容をメモしておく。

【2】OSSツールPleasanterは、C#で作られたノーコード・ローコードツール。
前回の勉強会で、Redmineと連携してチケット作成などの機能をデモされた。
個人的には、こういうノーコード・ローコードツールは日本人に向いていると思う。
理由は2つある。

1つ目は、データベース設計さえきちんと設計できれば、画面や帳票はプログラムレスで初心者でも開発できること。
つまり、いわゆるノーコードツールはデータベース設計が肝。

データの格納場所は後で安易に変更しづらいし、テーブルに依存した画面設計になるので、テーブル設計がぐちゃぐちゃだと画面そのものも使いづらくなる。
テーブル設計に業務フローやビジネスルールの制約条件を反映するように設計すれば、無駄なロジックを実装する手間も減るし、画面開発も楽になる。

幸いなことに、データベースモデリングの技術は枯れているし、渡辺幸三さんなどの本で優れたノウハウはあるので活用するだけでいい。

2つ目は、日本人は現場で生産性向上のためにプロセス改善、業務改善するやり方に非常に強いから。
以前のメーカーのQCサークルもそうだろうし、Redmineがこれだけ日本各地で使われているのは現場で気軽に使って業務改善するやり方が日本人の気性に向いているから。
よって、ノーコード・ローコードツールのように、業務改善に気軽に使える道具は日本人の気性に非常にマッチすると思う。

たぶん、戦略的にトップダウンで設計や標準化するよりも、現場で改善する方が日本人に向いているように経験的に感じる。
それが日本人の良い点でもあるし、日本人の弱点であるのかもしれない。

【3】@g_maedaさんの講演では、Redmine本の出版に合わせて20年近いRedmineの歴史を振り返っていた。
気になった点は、Redmineの弱点と、その裏返しとなるメリットの観点だ。

特に直近5年ほどは、Redmine本体の機能も枯れてきており、ドラスティックな機能追加はほとんどない。
つまり、Redmineは安定してしたツールであり、一方、少しずつ時代に遅れつつある面も否めないと思う。
backlogやJira、Asanaなどのツールに比べると、機能改善の速度はやはり違う。
その理由はいくつかあるだろう。

JPLを含む少人数の開発体制が変わっていないこと、UI/UXではシングルページアプリケーションのままで画面遷移や画面更新に手間がかかりやすいこと。
チケットトラッキング機能以外に大きな機能追加が行われていないこと。

アジャイルウェアさんも同様の問題意識を持っており、RedmineのUIや機能をドラスティックに変えにくいので自分たちでRedmineクローンを公開し、Redmine本家にバックポートしていく戦略を話されていた。
ウクライナ人開発者のRomanさんも、RedmineのUIを昨今のスマホ・タブレットを意識したテーマに変更してアピールしていた。

一方、LTでも懇親会でも議論されていたが、Redmineの古いUI/UXが逆にユーザに安心感があるメリットもある、と言う。
RedmineのUIは古いと言われるが、逆に15年近くほとんど変わっておらず、使い慣れている。
JiraのようにいきなりUIが変更されるとユーザも混乱しやすい。

Redmineはシングルページアプリケーションでないけれど、画面更新や画面遷移に必要な機能は分かりやすいし、操作に慣れると、勝手に変更される方が戸惑いやすい。
たとえば、汎用機やクラサバの頃のUIのように、画面にたくさんのボタンやテキストが左から順に並んでいて、キータッチで入力する方がやりやすい、と。

すなわち、RedmineのUIが古いと言われるデメリットは、換言すればUIが変更されておらず一貫性があるので、日本人の気性ではメリットの一つでもある。
そういう観点があると知ったのは面白かった。

【4】今日の勉強会で面白かった点は、Redmineという一つのツールで数多くのテーマで議論できる内容があることだ。
今日の講演では少なくとも5つの観点の事例があった。
情シス、プロジェクト管理、ITIL、性能チューニングによるインフラ運用、プラグイン開発やテーマ開発などのようなRuby開発の観点だ。

【4-1】@netazoneさんの講演では、メーカーの情報システム部門の立場から、人事・総務・営業などのバックエンドの業務をチケット化することで、タスク管理の漏れをなくし、作業の経験や反省点を次回の作業に改善するようにナレッジ化していた。
つまり、会社のバックエンド業務を一括管理してナレッジ化するために、情報システム部門がRedmineを効率的に利用して業務改善している事例だった。

【4-2】@madowindowさんのディスカッションでは、プロマネやPMOの立場から、WBSの管理や策定方法、プロジェクト運営でリスクを感じる兆候の管理、たとえば、進捗90%症候群、頑張ります発言などを話されていた。
つまり、RedmineをSIerのプロジェクト管理に適用するやり方になる。

また、@ta_ke_chan_ さんのLTでは、工場での工数管理にRedmineを利用されていた。
つまり、プロジェクト管理のうち、労務管理やコスト管理、原価管理に適用した事例になる。

【4-3】岩崎さんの会社のRedmineプラグインの話は、ITILの観点で、障害チケットをツールが自動起票して漏れなく一括管理し、電話応答する機能まで実装されていた。
つまり、ITILのようなサービス運用やヘルプデスク管理の観点で、Redmineを効率的に利用して業務改善する事例だった。

【4-4】@akahaneさんの事例では、島津製作所の計測機器に関する事業部でRedmineを全面展開し、Redmine単体1つだけで日々の業務を全て管理されている。
その時に、約3千ユーザ、数十万チケットをRedmineでスムーズに運用するために、RubyのJITコンパイラによる高速化、アプリサーバやDBMSなどの性能チューニングを施して、Redmineがバージョンアップしても高速化を実現していた。

この講演の肝は、Redmineにプラグインを入れないだけでなく、Redmine本体には一切手を入れず、Redmineの外側のインフラ基盤だけで性能チューニングを図ることで、高速化を実現していることだ。
つまり、Redmineに関する知識だけでなく、ApacheやDBMS、VM、通信帯域などのインフラ基盤の技術も必要であることを示唆している。
こういう高度なインフラ基盤の知識が必要な理由は、システム計監査やBCP対策で非常に厳しいビジネス要求に対応する必要があったからだ。
RubyやRailsの開発経験だけでなく、インフラ基盤の経験も相当必要なので、かなり高度な運用内容になっている。

【4-5】ウクライナ人のRedmine開発者Romanさんの事例では、自社で開発されているRedmineテーマやプラグインを紹介されていた。
彼のLinkedInのプロフィールを見ると、開発者の経験が豊富であり、Redmineについてかなり知識を持っているのだろうと思う。
また、@mattaniさんの事例では、Gemの依存性に関する知見の話だった。
彼らの講演は、RubyやRails開発などのテーマに属する。

【5】以上のように、たった半日の勉強会に過ぎないのに、Redmineに関するテーマとして全く別々の5つの内容が議論されていた。
どれか1つのテーマなら詳しい人は参加者でも多数いると思うが、これら5つのテーマを全て理解している人は、今日の参加者では非常に少ないのではないだろうか。

だからこそ、他の人の事例を聞くことで、自分たちが経験していない事例を聞いて参考にできて、盛り上がる要素の一つになったのではないか、と思う。

Redmineというたった一つのOSSツールに過ぎないのに、多様なテーマが存在しているということは、Redmineはまだまだ今後も発展できる余地がたくさん残されているのだろうと思う。

【6】最後にウクライナ人開発者のRomanさんのショート動画を紹介させてもらった。

Romanさんを知ったきっかけは、LinkedInで彼から僕に問い合わせがあり、LycheeやRedmica、hosting Redmineをやっている企業とコンタクトを取って日本市場に出たい、とのことだった。
Romanさんは自分の会社でRedmineテーマやプラグインを自社開発しており、それを日本市場で販売したい、そのために手を組める日本企業を探していたようだった。
僕は、@_maedaさんと川端さんを紹介した時に、redmine.tokyoで動画で紹介してはどうかと提案したら、彼が快諾してくて、この企画が実現した。

実際は、彼の動画が届くのは勉強会の1週間前でかなり直前になった。
彼から、5月末からウクライナでは電気が不安定で、動画を作るのに時間がかかってしまって申し訳ないと話された。
その話を聞いたとき、ニュースでちょうど、戦争で発電所などのインフラ設備にミサイル攻撃などがあって大変な時期だった、という話を思い出した。
彼の環境は、非常に大変だけれど、そんな中で、オープンソースのツールRedmineに関わって開発に取り組んでいる。
僕らとは違う環境でRedmineという共通のツールに興味を持っている彼に何となく共感したい気持ちがあった。
僕自身ができること、貢献できることは分からないけれど、コミュニティで共有することで何か連帯できればいいなと思っている。

【7】今日の勉強会では、常連だけでなく、新しく知り合った人たちとたくさん話ができた。
常連だけが盛り上がるのではなく、新しく参加した人たちとオフラインの場で一緒に経験を共有することで、より一層結束も強くなる。

Pleasanterの人たちも、こういうユーザコミュニティを作りたいんですよ、と言っていた。
Pleasanterはノーコードツールなので、パートナーと呼ばれる開発者兼利用者と強い関係がある。
それをベースにビジネス展開できている。
しかし、今のPleasanterコミュニティはビジネス色が強いと思われてしまうデメリットを感じている。
だからこそ、利用者自身がコミュニティを立ち上げて盛り上げてくれるやり方を模索している、と。
そんな話を聞きながら、思ったことは2つある。

1つ目は、Redmineコミュニティが長続きしているのは、熱狂的な利用ユーザがいて、Redmineコミッタやプラグイン開発者、Redmineプラグインやサービスを提供するベンダーの間で、活発な互恵関係があることだろう。
利用ユーザが困った問題があれば、利用ユーザはコミッタに聞いたり、Ruby開発者にプラグインの要望を出したり、有償プラグインではこんな機能がほしいなどを投げかけて、問題解決のメリットを得る。
一方、コミッタやプラグイン開発者、Redmineベンダーは、利用ユーザのニーズを直接聞きだすことができ、それをRedmine本体やプラグインの改善に役立てられるし、有償プラグインや有償サービスによりビジネス化できるメリットを得る。
そういうお互いにWin-Winの関係が成り立っているからだろう。

それは意図して作られた関係ではない。
最初は、利用ユーザがコミッタに声をかけよう、プラグイン開発者に来てもらおう、ベンダーにも来てもらおう、という程度から始まった。
そこから、数多くのやり取りを経て、お互いに信頼関係を築くことができて、あの人なら失礼な行為や不利益な行為はしないだろうという安心感が作れている。
そういう長期的な信頼関係が作れたからこそ、コミュニティが長持ちしているのだろう。

もう一つは、Redmineに関するテーマが多様であることだ。
そして、Redmineの利用ユーザや開発者も日本各地にいて多様性があることだ。
今日の勉強会でも、北海道、京都、大阪、福岡から参加者がいた。
さらにウクライナの開発者も動画を送ってくれた。
多様な属性を持つユーザが集まることで、予期しない化学反応が起きて、より熱狂的になれる。
熱狂的な楽しい経験を一緒に共有し、それを何度も続けていくこで、信頼関係を築いていく。
信頼関係がコミュニティを支えてくれる。
そういう体験がコミュニティ運営の醍醐味だろうと思う。

また、僕がブログにRedmineのアイデアをたくさん書き散らした記事について、すごく参考になったと話してくれた人もいて、非常に励みになった。
その人曰く、Redmineでこんな使い方もできる、あんな使い方もできる、という記事がたくさんあって皆読んでいるから、勉強会で盛り上がるのではないか、と話してくれた。
僕自身は強いミッションや使命感もなく、ただアイデアを書き残して公開しないとなかなか寝れなかったというだけだったのだが、そういう人がいてくれて非常に勇気づけられた。

僕自身は、OSSツールのチケット管理ツールRedmineとモデリングツールastahの2つにこだわりを持っている。
この2つのツールを使ったテーマは今後も考えていきたいと思う。

| | コメント (0)

2024/05/06

「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する

システムアーキテクチャ構築の原理」を読んでる。
平鍋さんの記事「『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita」を読み直して、理解が深まった。
平鍋さんの記事に触発されたので、理解できたことをラフなメモ。
間違っていたら後で直す。

【参考】
『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita

「システムアーキテクチャ構築の原理」の感想: プログラマの思索

【1】「システムアーキテクチャ構築の原理」を読んでいて分かりにくかったことは、ビュー、ビューポイント、パースペクティブという概念が出てきて混乱したこと。
これらの言葉は何を表しているのか、具体的に理解できていなかった。

平鍋さんの記事「『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita」では、概念モデルでまとめてくれているので理解しやすかった。

【2】図4-3.コンテクストにおけるパースペクティブが「システムアーキテクチャ構築の原理」のメッセージを全て表している。
平鍋さんの解説が分かりやすい。

43

(引用抜粋 開始)
「非機能要件がシステムのアーキテクチャに影響を与える」という観点を本書は、この言説を徹底的に解説したもの。

非機能要件に限らず、横断的な視点を「パースペクティブ」として捉えている

実際にアーキテクチャを記述しようとすると、1つの文書ではとっても複雑で巨大な説明になる。「ステークホルダー」の「関心事」毎に分割するために、「ビュー」と「ビューポイント」を導入する

「パースペクティブ」は、従来の言葉で近いものとして「非機能要求」「横断的関心事」がある。本書ではこの「ビューポイント」と「パースペクティブ」のカタログを作っています。
(引用抜粋 開始)

【3】図15-1.ビュー間の関係では、ビューを開発や運用の観点で分解している。
この図は、システム開発とシステム保守で分割すれば理解しやすい。
今ならDevOpsだから、開発も運用も一体化しているだろう。

151

【4】図7-3.アーキテクチャ定義のプロセスは、「システムアーキテクチャ構築の原理」が提唱している、アーキテクチャを定義し評価するプロセス。
アーキテクチャ設計の中で、特に非機能要件を含めた横断的関心事をいかにアーキテクチャに盛り込むのか、を考えた一連のプロセスになる。
プロセスの流れは、アーキテクチャ要素や横断的関心事を段階的詳細化して組み立てたあとにアーキテクチャを評価するので、違和感はない。

73

【5】「システムアーキテクチャ構築の原理」では上記3つの図が本書のメッセージになると思う。
本書のやり方を各システム、各案件にテーラリングして設計、実装する必要があるから、本書は、アーキテクチャ設計のメタ概念、メタプロセスの解説書みたいな感触を持っている。

【6】「システムアーキテクチャ構築の原理」の副題「ITアーキテクトが持つべき3つの思考」が指す「3つ」とは、「ステークホルダー」「ビューポイント」「パースペクティブ」と最初に書かれている。

その意図は、ステークホルダーの横断的関心事、特に非機能要求をユーザ観点のビューポイント、システム観点のパースペクティブで分解して組み立てて、トレードオフを考慮したアーキテクチャを設計すること、を意味していると考える。

他にも気づいた他内容があれば書いていく。

| | コメント (0)

「システムアーキテクチャ構築の原理」の感想

システムアーキテクチャ構築の原理」を読む機会があったので感想をラフなメモ書き。

【参考】
「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する: プログラマの思索

『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita

アーキテクチャ構築の原理 第2版を読んだ - 勘と経験と読経

【0】「システムアーキテクチャ構築の原理」は最新版の第2版もある。
僕は確か、デブサミ2010の時に会場で購入した記憶があり、第1版を持っている。
その時から興味のある部分だけかいつまんで読んでいたので、全部を通して読んでいなかったので、輪読するのは良かった。

システムアーキテクチャ構築の原理」を読んで興味を持った部分はいくつかある。

【1】1つ目は、2008年の初版でありながら、マイクロサービスやサービス志向のアーキテクチャ設計を目指していること。
機能的ビュー、情報ビュー、並行性ビューなどのソフトウェア構造のアーキテクチャ設計の観点は、業務システム設計と微妙に違うな、と感じていたが、実際はクラウドベースのマイクロサービス設計を目指しているのだろう。
実際、並行性ビューでは、昔のバッチ処理設計よりもイベント駆動の並列性アーキテクチャに力点をおいている。
たとえば、REST APIやAdapter・Facadeパターンのようなアーキテクチャ設計を念頭に置いて実装しようとしている。

そう考えると、マイクロサービス設計における新たな設計思想はまだ含まれておらず、荒削りな内容を感じるが、文章の背後にある著者の思い、こういうことを言いたいのではないか、を推測しながら読むと理解できるのでは、と感じる。

【2】2つ目は、ATAMという非機能要件の設計技法を解説してくれている点だ。

データベースコンサルタントのノウハウちょい見せ アーキテクチャをレビューする方法(ATAM)

ATAMはシナリオベースで非機能要件を評価する設計技法。
僕の理解では、システムのアーキテクチャの特に非機能要件を品質特性ごとに分類し詳細化して、それをシナリオに落とす。
そのシナリオを優先度付けして、シナリオベースにアーキテクチャを評価して整合性を取ったり、システム設計を明確化する。

利点は、非機能要件をアーキテクチャとして評価する技法として、シナリオベースを用いているので、アジャイル開発をやっている人には取り組みやすいと思う。
デメリットは、CMMIを作ったSEIがATAMを提唱しているので、重たいプロセスになりがちで、テーラリングが必須であり、プロマネによってばらつきが出やすいこと。

ATAMに関する日本語書籍は「システムアーキテクチャ構築の原理」と「間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価 (Software Design plus)ぐらいしかないので、貴重だと思う。

データベースコンサルタントのノウハウちょい見せ 書評「間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価」

【3】3つ目は、2009年頃の書籍なので、UMLをベースとした設計を念頭に置いていること。
機能的ビューではコンポーネント図、情報的ビューではER図やDFDや概念クラス図、並列性ビューではステートマシン図を使うと良いと説明されている。
このあたりの意見は僕も同意するが、注意点はいくつかあると思う。

コンポーネント図は「アジャイルソフトウェア開発の奥義」でも重要視されている。
機能を1つのコンポーネントとみなし、コンポーネント間のインターフェイスを重視する設計は重要だと思う。
一方、コンポーネント図だけでは表現しきれない仕様や要件があり、不十分と感じる。

その点は「システムアーキテクチャ構築の原理」でも、メッセージングのやり取りは記述できないので補足説明や別の図が必要と書かれている。

並列性ビューに出てくるステートマシン図は、より詳しく書いていくと結局、詳細設計レベルになってしまう。
アーキテクチャ設計ではRFPに出てくる要件レベルまでで留めたいので、粒度を揃えるのが難しい場合が多いだろう。

【4】「システムアーキテクチャ構築の原理」を読んでいて思い出すのは、2000年代にソフトウェア・プロダクトラインが流行した頃に読んだ「 実践ソフトウェアアーキテクチャ」に出てくる一節だ。

そのボタンを押したら何が起きるのですか?~アーキテクチャは利害関係者のコミュニケーション手段: プログラマの思索

実践ソフトウェアアーキテクチャの解説記事: プログラマの思索

実践ソフトウェアアーキテクチャ」では、政府のある委員会の2日間に渡る討議の中で、新人のアーキテクトが、政府が作ろうとしているシステムのアーキテクチャをコンサル独自の記法でモデルを描いて委員会の参加者に説明していたところ、委員会の参加者たちは何が問題なのかに初めて気づいた。
そして、委員会の参加者たちは、新人のアーキテクトの説明を途中で止めさせて、システムのアーキテクチャの問題点を活発に議論し始めたという一節だ。
これが意味しているのは、アーキテクトの役割とは、システムのアーキテクチャ設計に関する最終責任者ではなく、各利害関係者の間でシステム要件のトレードオフを考慮させる調停者であることだ。

つまり、アーキテクトの役割はシステム要件を決めることではなく、システム要件のトレードオフを色んなステークホルダーに説明して理解させて、最終的な意思決定を引き出す調停者として振る舞うべきだ、ということ。
この一節は僕が一番好きなところでもある。

システムアーキテクチャ構築の原理」では、アーキテクトがすべてのパースペクティブやビューポイントを理解している全能の神のように思えてしまうが、実際はそうではなく、アカウンタビリティを持つ調停者という観点で捉えると理解しやすいと考える。

気づいた点はまた書き留めていく。

| | コメント (0)

2024/04/21

物理学の各分野の基本思想

最近、物理学の各分野の本を片っ端から読んでいる。
こういう基本的な考え方が分かっていないから、ずっとつまずいていたんだな、と気付きがあった。
自分の気づきをラフにメモしておく。
間違っていたら後で直す。

【参考】
物理学の基本思想とは何なのか: プログラマの思索

【1】電磁気学の基本思想は、マクスウェル方程式の理解にある。
マクスウェル方程式は4つあるけれど、微分形式で表現される法則はわかりにくい。
∇、rot、divなどが出てきて混乱する。
よくわかる電磁気学」「ゼロから学ぶ電磁気学」なども良い本なのだろうが、僕には直観的でなくて受け付けにくかった。

むしろ「高校数学でわかるマクスウェル方程式」で説明されている通り、積分形式でマクスウェル方程式を表現するほうが直観的で理解しやすい。
線積分、面積分が出てくるので慣れも必要だが、微小な線分、面積、体積に対し電流や電場、磁場がどのように変化するか、をぐるっと合計して、最終的に積分すれば、マクスウェル方程式が出てくる。
微分形式は、積分形式のマクスウェル方程式を微小な空間で考えるだけで十分。

マクスウェル方程式が分かれば、ローレンツ力や特殊相対性理論との関係性も計算して導くことができる。
高校数学でわかる相対性理論」で説明してくれている。

【2】解析力学の基本思想は、ラグランジアンとハミルトニアンの理解にある。
特にハミルトニアンが重要。
ハミルトニアンの正準方程式、そして、最終的にはハミルトン・ヤコビの方程式まで出せればいい。
ゼロから学ぶ解析力学」「よくわかる解析力学」を読んで納得した。

【3】流体力学の基本思想では、流線と圧力(揚力)を複素関数で表すことにある。
速度ポテンシャル、流れ関数のいずれも偏微分すれば速度が出てくる。
そこから、オイラーの定理、ベルヌーイの定理、ジッタジェーコフスキーの定理が出てくる。
はじめての解析学 微分、積分から量子力学まで」では、流体力学では流線と圧力の2つの変数を複素関数として表現することで、障害物の流線を表現でき、最終的に飛行機の翼と空気の流れを計算するという流れになる。
高校数学でわかる流体力学 ベルヌーイの定理から翼に働く揚力まで」では、障害物のある流速から揚力が生まれる説明を計算式と一緒に丁寧に説明してくれているので理解しやすい。

【4】量子力学の基本思想は、シュレディンガー方程式の理解にある。
電子の位置を知りたいが、実際は確率でしか分からない。
位置を把握する確率は、確率密度関数で決まる。
確率密度関数は波動関数で表現される。
波動関数はシュレディンガー方程式から導かれる。
はじめての解析学 微分、積分から量子力学まで」では、そういう流れが基本にあって、ハミルトニアンやポアソン括弧、演算子の量子化、飛び飛びのエネルギーが出てくると説明してくれている。
ゼロから学ぶ量子力学 普及版 量子世界への、はじめの一歩」ではその説明をお約束として前提としている。
はじめての解析学 微分、積分から量子力学まで」では、量子力学を解析学が最終的に定式化する説明として、最終的に、シュレディンガー方程式とヒルベルト空間が1対1に対応すること、物理量がエルミート作用素に1対1に対応することを説明してくれている。
ただし、量子力学は奥が深いので、これだけでは不十分。
よくわかる量子力学」で最終的に習得が必要かなと思う。

【5】特殊相対性理論の基本思想は、ローレンツ変換に対し、従来の古典力学の見方とアインシュタインの見方が決定的に異なる点を理解することにある。
ゼロから学ぶ相対性理論」では、ローレンツ収縮の話は古典力学の観点からも出てくるが、アインシュタインの考え方が独創的である点を丁寧に説明してくれている。
また、ミンコフスキー空間の考え方も独特だが、「ゼロから学ぶ相対性理論」では、ローレンツ変換後の座標をへしゃげる(回転させる・少しだけ潰す)という比喩が理解しやすかった。

【6】統計力学の基本思想は、温度・圧力・熱量のようなマクロな物理量とアボカドロ数もの膨大な数の分子の運動を結びつける時にエントロピーが橋渡しする点にある。
ボルツマンの定理がエントロピーと場合の数を橋渡しする。
高校数学でわかるボルツマンの原理―熱力学と統計力学を理解しよう」「ゼロから学ぶ統計力学」の説明が丁寧だった。

【7】物理学の本を読んでみて面白いと気づいた点は、複雑な自然現象を単純なモデルとして構築した後、局所的な変化から微分形式を導き、最終的に公式や物理量を導出すること。
単純なモデルと局所的な変化から微分形式、つまり微分方程式を導く箇所は物理屋特有の直観的な考え方がある。
自然現象はこうあるべきだ、という考え方に基づく。
そして、得られた公式や物理量に対し、単なる数式や数値と思わず、物理的にどんな意味を持つのか、を徹底的に考える所が面白い。
そこに物理屋特有の発想がある。

一方、得られた公式や物理量は理論に過ぎず、実験や観測によって最終的には証明される。
理論と実験・観測のアウフヘーベンによって物理学の体系や基礎づけられて強化されるわけだ。
直感と厳密な計算、根気強い実験という相反する能力が要求されている点が面白いと思った。

| | コメント (0)

Redmineで持ち株管理する事例

Redmineで持ち株管理するツイートを見かけたのでメモ。
単純に面白いなと思った。

Redmineのチケットにそれぞれの持ち株の情報を記載し、ステータスごとにチケットパネルでカンバン風に表示している。
ステータスは、候補、買付注文中、保有中、売却注文中がある。
おそらく、株の候補をリストアップし、ネット証券などで買付し、保有して、配当をもらいながら、最後に売却するという流れなのだろう。

メリットは、ステータスごとに持ち株の状況がわかること。
だが、実際はこれだけは使いづらいだろう。
現在のそれぞれの持ち株の運用損益や評価金額、すべての持ち株のサマリ情報も表示したい。
また、持ち株の運用損益や評価金額の履歴も表示させたい。

すると、ネット証券のAPIを使って持ち株の最新情報を日次で取得し、持ち株チケットに紐づけて、履歴情報を持たせるような仕組みが欲しくなる。
結局、ネット証券会社のアプリの簡易版みたいな機能が欲しくなってくるだろう。
つまり、Redmineのプラグインでそういう仕組みを作りたくなってくるだろう。

ここで、Redmineのチケットは、かんばんやワークフローのようにステータス管理させたい「フロー」の概念と、情報を資産として蓄積させたい「ストック」の概念の2つを持つ。
今回の持ち株の事例は、チケットをストックとして扱う事例に相当するだろう。

チケットはデータでとプロセスの二面性を持つ #redmine: プログラマの思索

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索

こういうアイデアは面白いなと思った。
ちょっとしたデータ管理にRedmineを使ってみる事例は色々集めてみる。


| | コメント (0)

«物理学の基本思想とは何なのか