浅野直樹の学習日記

この画面は、簡易表示です

浅野直樹

リチャード・M・ストールマン『フリーソフトウェアと自由な社会 ―Richard M. Stallmanエッセイ集』の内容へのリンク

リチャード・M・ストールマン『フリーソフトウェアと自由な社会 ―Richard M. Stallmanエッセイ集』は今読んでもおもしろいので、リチャード・M・ストールマン『フリーソフトウェアと自由な社会 ―Richard M. Stallmanエッセイ集』(アスキー、2003)の本文テキストとPDF公開でご案内しましたように、その本体の内容をHTMLとPDFで公開しました。

HTML目次

PDFファイル

実は英語の原著では第3版まで出ています。以下のWikipediaからすべての版をダウンロードできます。

Free Software, Free Society – Wikipedia

そこで、本の目次と対応させる形で、GNUオペレーティング・システムと自由ソフトウェア運動で公開されている内容へのリンクを作りました。

日本語に訳されているものはタイトルを日本語に、そうでないものはタイトルを英語にしてあります。

日本語ネイティブとしては日本語で読めるほうがありがたいですし、英語のものはPDFファイルで読めはしますが章ごとに分かれていたほうが便宜なので、下記のようにまとめました。

 

1.第1版

Editor’s Note

A Note on Software

Topic Guide

Introduction

1 GNUプロジェクト

2 GNU宣言

3 Free Software Definition(自由ソフトウェアとは?に発展的に解消?)

4 ソフトウェアに所有者がいてはならない理由

5 名前が何であろうか?

6 Why “Free Software” is Better than “Open Source”なぜ、オープンソースは自由ソフトウェアの的を外すのかに置き換え)

7 Releasing Free Software if You Work at a University

8 自由ソフトウェアの販売

9 自由ソフトウェアが自由な文書を必要とする理由

10 Free Software Song

11 読む権利

12 Misinterpreting Copyright—A Series of Errors

13 Science Must ‘Push’ Copyright Aside

14 コピーレフトって何?

15 コピーレフト: 実際的な理想主義

16 The Danger of Software Patents

17 Can You Trust Your Computer?

18 Why Software Should Be Free

19 Copyright and Globalization in the Age of Computer Networks

20 Free Software: Freedom and Cooperation

21 避けるべき言葉 (あるいは注意深く使う)、含みがあるかまぎらわしいので

GNU一般公衆ライセンス

GNU劣等一般公衆ライセンス

GNU自由文書ライセンス

(本の形で出版されている、リチャード・M・ストールマン『フリーソフトウェアと自由な社会 ―Richard M. Stallmanエッセイ集』(アスキー、2003)では、すべての内容が日本語に訳されています。この記事の冒頭にHTMLとPDFでのリンクを貼っています。訳文が異なるので、読み比べてみるとおもしろいかもしれません。

 

2.第2版

Foreword

Preface to the Second Edition

1 Free Software Definition(自由ソフトウェアとは?に発展的に解消?)

2 GNUプロジェクト

3 最初の声明

4 GNU宣言

5 ソフトウェアに所有者がいてはならない理由

6 Why Software Should Be Free

7 なぜ学校で自由ソフトウェアだけを使うべきか

8 Releasing Free Software if You Work at a University

9 自由ソフトウェアが自由な文書を必要とする理由

10 自由ソフトウェアの販売

11 Free Software Song

12 名前が何であろうか?

13 自由および不自由なソフトウェアの分類

14 なぜ、オープンソースは自由ソフトウェアの的を外すのか

15 「知的財産」ですって? それは魅惑的な蜃気楼です

16 避けるべき言葉 (あるいは注意深く使う)、含みがあるかまぎらわしいので

17 読む権利

18 Misinterpreting Copyright—A Series of Errors

19 Science Must ‘Push’ Copyright Aside

20 Freedom—or Copyright自由 — それとも著作権? (古いバージョン)

21 コピーレフトって何?

22 コピーレフト: 実際的な理想主義

23 Anatomy of a Trivial Patent

24 Software Patents and Literary Patents

25 The Danger of Software Patents

26 Microsoft’s New Monopoly

27 Introduction to the Licenses

28 GNU一般公衆ライセンス

29 GPLv3にアップグレードする理由

30 GNU劣等一般公衆ライセンス

31 GNU自由文書ライセンス

32 Can You Trust Your Computer?

33 そのサーバはいったい誰にサーブするのか?

34 Free but Shackled: The Java Trap

35 JavaScriptの罠

36 Xウィンドウ・システムの罠

37 The Problem Is Software Controlled by Its Developer

38 We Can Put an End to Word Attachments

39 Thank You, Larry McVoy

40 Computing “Progress”: Good and Bad

41 破滅的な折衷案を避ける

42 Overcoming Social Inertia

43 Freedom or Power?

Appendix A: A Note on Software

Appendix B: “free software”という用語の各言語訳

(3, 7, 13, 14, 15, 20, 23, 24, 25, 26, 27, 29, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43はこの版で新出)

 

3.第3版

Foreword to the Third Edition

Foreword to the First Edition

Preface

1 自由ソフトウェアとは?

2 GNUプロジェクト

3 最初の声明

4 自由ソフトウェアはいまやさらに重要だ

5 なぜ学校で自由ソフトウェアだけを使うべきか

6 政府が自由ソフトウェアを奨励するために使える方策

7 自由ソフトウェアが自由な文書を必要とする理由

8 自由ソフトウェアの販売

9 Free Hardware and Free Hardware Designs

10 Applying the Free Software Criteria

11 名前が何であろうか?

12 LinuxとGNUシステム

13 自由および不自由なソフトウェアの分類

14 なぜ、オープンソースは自由ソフトウェアの的を外すのか

15 「知的財産」ですって? それは魅惑的な蜃気楼です

16 Why Call It the Swindle?

17 避けるべき言葉 (あるいは注意深く使う)、含みがあるかまぎらわしいので

18 読む権利

19 Misinterpreting Copyright—A Series of Errors

20 Science Must Push Copyright Aside

21 Copyright vs. Community in the Age of Computer Networks

22 Software Patents and Literary Patents

23 The Danger of Software Patents

24 Giving the Software Field Protection from Patents

25 Introduction to the Licenses

26 あなた自身の作品にライセンスを選択する方法

27 Xウィンドウ・システムの罠

28 Programs Must Not Limit the Freedom to Run Them

29 コピーレフトって何?

30 Why Copyleft?

31 コピーレフト: 実際的な理想主義

32 GNU一般公衆ライセンス

33 GPLv3にアップグレードする理由

34 GNU劣等一般公衆ライセンス

35 GNU自由文書ライセンス

36 On Selling Exceptions to the GNU GPL

37 Can You Trust Your Computer?

38 JavaScriptの罠

39 Releasing Free Software if You Work at a University

40 Nonfree DRM’d Games on GNU/Linux: Good or Bad?

41 The Danger of E-Books

42 E-books Must Increase Our Freedom, Not Decrease It

43 そのサーバはいったい誰にサーブするのか?

44 破滅的な折衷案を避ける

45 Overcoming Social Inertia

46 Freedom or Power?

47 Imperfection Is Not the Same as Oppression

48 民主主義はどれくらい監視に耐え得るか?

A: A Note on Software

B: “free software”という用語の各言語訳

C: Free Software Song

(4, 6, 9, 10, 12, 16, 21, 24, 26, 28, 30, 36, 40, 41, 42, 47, 48はこの版で新出)

 

本に収録されていない小論や講演などがまだまだたくさんありますので、興味のある方は小論と論説 – GNUプロジェクト – フリーソフトウェアファウンデーションなどをご参照ください。



e-Gov 法令検索からダウンロードした条文htmlファイルに条文ごとのidを付与する

記事タイトルの通りマニアックな内容ですが、誰かの役に立つかもしれないので、やり方を公開します。

 

1.問題意識

私は、司法試験短答過去問ウェブアプリを作成しておりまして、事前に条文のhtmlファイルを準備し、参考条文をクリックするとその条文が画面右に表示されるようにしています。

(詳しくは司法試験短答式過去問演習サイトの解説を作り始めましたをご覧ください)

 

ページ内リンクを活用してこれを実現しています。

一年ほど前にe-Gov 法令検索から条文のhtmlファイルを取得したときは、例えば第百九十九条なら、「id=”Mp-At_199″」のようなidがhtml内に付されていました。

最近久しぶりにe-Gov 法令検索から条文のhtmlファイルを取得したところ、形式が変わっていました。

これまでは現に表示しているページをhtmlとして保存していましたが、現在はいろいろな形式でダウンロードできるように用意されていて、その中にはHTML形式もありました。

それをダウンロードするときれいなhtmlファイルで、これはありがたいと思いました。

しかし一つ問題がありまして、条文ごとに「id=”Mp-At_199″」のようなidが付されておらず、軒並み「id=””」となっていたのです。

これが私の問題意識です。

 

2.やり方

結論を最初に示します。

import re

def convert_kansuuji_to_arabic_number(kansuuji):
    # 結果として返すアラビア数字の文字列を初期化
    arabic_number = ''
    # 一〜九の変換表
    convert_table = str.maketrans("一二三四五六七八九", "123456789")
    # 単位の処理
    unit_under_thousand = {"十": 1, "百": 2, "千": 3}
    unit_over_thousand = {"万": 4, "億": 8, "兆": 12, "京": 16}
    # 基準となる単位の初期化
    base_unit = 0
    # 一の位から処理していくために逆順にする
    reversed_kansuuji = list(reversed(kansuuji))
    for i, character in enumerate(reversed_kansuuji):
        # 十、百、千の場合
        if character in unit_under_thousand.keys():
            # unit_under_thousandの値に基準となる単位を加えた桁数でゼロパディング
            arabic_number = arabic_number.zfill(unit_under_thousand[character] + base_unit)
            # ループの最後(先頭の文字)か、次のループ(一つ前の文字)が単位を表す文字ならば、1を前に付け加える
            if i == len(reversed_kansuuji) - 1 or reversed_kansuuji[i+1] in unit_under_thousand or reversed_kansuuji[i+1] in unit_over_thousand:
                arabic_number = '1' + arabic_number
        # 万、億、兆、京の場合
        elif character in unit_over_thousand.keys():
            # unit_over_thousandの値の桁数でゼロパディング
            arabic_number = arabic_number.zfill(unit_over_thousand[character])
            # 基準となる単位を更新
            base_unit = unit_over_thousand[character] 
        # 一〜九の場合
        else:
            # 一〜九の変換表を用いて変換した数字を前に付け加える
            arabic_number = character.translate(convert_table) + arabic_number

    return arabic_number


# 第○○条の部分にマッチさせ、○○という漢数字をキャプチャするパターン
pattern = re.compile(r'第(.*)条')

# e-Govからダウンロードした条文htmlファイルの読み込み
with open('./140AC0000000045_20230713_505AC0000000066.html') as reader:
    # 読み込んだhtmlファイルを一行ずつ保存するリストの初期化
    output_line_list = []
    for i, line in enumerate(reader):
        # 読み込んだ行をリストに追加
        output_line_list.append(line)
        # 「第○○条」の部分にマッチさせる
        result = pattern.search(line)
        # 第○○条の部分にマッチした場合
        if result:
            # ○○という漢数字をアラビア数字に変換
            arabic_joubun_number = convert_kansuuji_to_arabic_number(result.group(1))
            # マッチした行の一つ前の行の「id=""」を「id="Mp-At_199"」のように変換
            output_line_list[i-1] = output_line_list[i-1].replace('id=""', f'id="Mp-At_{arabic_joubun_number}"')

# 保存したリストの書き出し
with open('kei.html', 'w') as writer:
    for output_line in output_line_list:
        writer.write(output_line)

print('done')

細かくコメントを書き入れていますから、読めばある程度わかると思います。

前半は漢数字をアラビア数字に変換するための関数です。

pythonで漢数字をアラビア数字に変換するスクリプトで詳しく説明しました。

条文で万を超えることはないでしょうから、ここまで厳密な変換スクリプトは不要ですが、せっかくなので作ってみました。

 

後半がメインの処理です。

e-Govからダウンロードした条文htmlファイルを一行ずつ読み込み、「第○○条」という部分にマッチしたら、その一つ前の行に「id=”Mp-At_199″」のような形でその数字のidを付与するという処理です。

 

これでやりたいことができました。

 



pythonで漢数字をアラビア数字に変換するスクリプト

pythonで漢数字をアラビア数字に変換しようとしたら、意外に苦戦したので、今後のために記録を残しておきます。

そのようなスクリプトはすでに誰かが書いているだろうと思い、実際検索したらいくつかヒットしたのですが、どれも私にはすぐに理解できず(よほど時間に追われているのでない限り自分が理解できないプログラムは使いたくないです)、自分で数時間かけて作り出しました。

既存のプログラムの中で一番参考にしたのは、Pythonで最もシンプルに文章中の漢数字を数字に変換する方法とプログラム #Python3 – Qiitaです。

ただ、私はそのプログラムをすっきりとは理解できなかったので、引数に漢数字部分だけを渡すという制限を設け、異なる視点から実装しました。

先に結論を示します。


def convert_kansuuji_to_arabic_number(kansuuji):
    # 結果として返すアラビア数字の文字列を初期化
    arabic_number = ''
    # 一〜九の変換表
    convert_table = str.maketrans("一二三四五六七八九", "123456789")
    # 単位の処理
    unit_under_thousand = {"十": 1, "百": 2, "千": 3}
    unit_over_thousand = {"万": 4, "億": 8, "兆": 12, "京": 16}
    # 基準となる単位の初期化
    base_unit = 0
    # 一の位から処理していくために逆順にする
    reversed_kansuuji = list(reversed(kansuuji))
    for i, character in enumerate(reversed_kansuuji):
        # 十、百、千の場合
        if character in unit_under_thousand.keys():
            # unit_under_thousandの値に基準となる単位を加えた桁数でゼロパディング
            arabic_number = arabic_number.zfill(unit_under_thousand[character] + base_unit)
            # ループの最後(先頭の文字)か、次のループ(一つ前の文字)が単位を表す文字ならば、1を前に付け加える
            if i == len(reversed_kansuuji) - 1 or reversed_kansuuji[i+1] in unit_under_thousand or reversed_kansuuji[i+1] in unit_over_thousand:
                arabic_number = '1' + arabic_number
        # 万、億、兆、京の場合
        elif character in unit_over_thousand.keys():
            # unit_over_thousandの値の桁数でゼロパディング
            arabic_number = arabic_number.zfill(unit_over_thousand[character])
            # 基準となる単位を更新
            base_unit = unit_over_thousand[character] 
        # 一〜九の場合
        else:
            # 一〜九の変換表を用いて変換した数字を前に付け加える
            arabic_number = character.translate(convert_table) + arabic_number

    return arabic_number
    
# 実験
test1 = convert_kansuuji_to_arabic_number('五千京二百三十億八百六十五')
test2 = convert_kansuuji_to_arabic_number('千二十三')
test3 = convert_kansuuji_to_arabic_number('百十')

print(test1)
print(test2)
print(test3)

かなり細かくコメントを付けたので、上記のコードとコメントを読むだけで理解できるかもしれませんが、考え方を述べます。

一気に処理しようとするとややこしく感じられたので、一の位から(漢数字表記をしたときに右の文字から)一文字ずつループで処理するという見通しを立てました。

一〜九は1〜9の数字に変換するだけです。

「二万五千四百二十三」などのように、すべての桁に一〜九の漢数字が入っているなら、十、百、千、万といった単位を表す漢数字を消すだけで完成です。

しかし、「千二十三」のように飛んでいる位があると、それではうまくいきません。

この例の「千」なら23ではなく023になるように、適切な桁数でゼロパディングすればいいですね。

問題は、「五千京二百三十億八百六十五」のような大きい数字の場合、「八百六十五」の「十」と「二百三十億」の「十」の桁数が違うことです。

言い換えると、十、百、千は何度も登場することがありますが、万、億、兆、京は一度しか登場しません。

このように、単位を表す漢数字を、千以下のものと千より大きいものとに区別できます。

「八百六十五」の「十」を1桁だとすると、「二百三十億」の「十」は9桁です。

万、億、兆、京を処理するたびに、基準となる単位を4, 8, 12, 16と設定すればよいと気づきました。

あとは「千二十三」が023、「百十」が00となってしまうように、単位を表す漢数字の処理で1が抜けてしまうという問題に対処すれば完成です。

この問題は、一番上の位が単位を表す漢数字である場合か、「百十」のように単位を表す漢数字が連続する場合に発生します。

そこで、コード内のコメントにもありますように、ループの最後(先頭の文字)か、次のループ(一つ前の文字)が単位を表す文字ならば、1を前に付け加えるという処理を書きました。

これが私にとって理解しやすい考え方です。

壱弐参なども変換したければ変換表に加えればいいですし、京より上の単位にも対応したければ「”垓”: 20」のように単位を追加すればいいです。

よろしければ上記のコードと考え方をご活用ください。

 

 



リチャード・M・ストールマン『フリーソフトウェアと自由な社会 ―Richard M. Stallmanエッセイ集』(アスキー、2003)の本文テキストとPDF公開

リチャード・M・ストールマン『フリーソフトウェアと自由な社会 ―Richard M. Stallmanエッセイ集』(アスキー、2003)は今読んでもおもしろいのですが、入手しづらいため、その本体の内容を、HTMLとPDFで公開します。

HTML目次

PDFファイル

原文の著作権はフリーソフトウェア財団(Free Software Foundation, Inc.)、翻訳の著作権はアスキー(ASCII)にありますが、変更を加えずそのまま公開することは許可されています。

それが本書で主張されているフリーソフトウェアの理念です(ソフトウェアと文書(ドキュメント)では細かい違いはありますが、大本となる理念は共通しています)。

複製して公開する許可がされているかどうかわからなかった表紙の写真と訳者あとがきは割愛しています。

自由にご活用ください。



私の業務効率化ツールとの付き合い方

Slack、Notion、GitHub、G Suiteなど、さまざまな業務効率化を使うことになり、これらの業務効率化ツールとどのように付き合っていけばよいかを整理したく、この記事を書きました。

 

業務効率化との付き合い方は、年代や働き方によって大きく異なると思いますが、この記事では一つのリアルな例を提供します。

 

個人史を振り返り、現在の姿をまとめ、概念整理をします。

 

1.個人史

(1)高校卒業まで(〜2001年)

私は1982年生まれでして、初めて電子メールを使ったのが2001年に高校を卒業する直前のことでした。今で言うガラケーのキャリアメールです。クラスメートとメールアドレスを交換し、その日は夜遅くまでやり取りしたことを覚えています。

思い出話はさておき、メールを最も原始的な業務効率化ツールに位置づけるとして、それ以前にツールを使ったことはないということになります。

現代でしたら、中学生や高校生でも日々の学習に業務効率化ツールを使うことがあるでしょうから、時代によって規定される部分が大きいです。もっとも、私は、当時の紙に手書きをするノートでさえ、極力作らないタイプでした。できるだけツールに頼らず自分の脳内で完結させたいという志向を一貫して持っています。

(2)大学時代(2001年〜2013年)

私は長く大学(大学院)に在籍しておりまして、2001年〜2013年の間を指します。

2001年に大学に入ってから初めてパソコン(PC)を本格的に使いました。それまでは中学校の技術家庭科の授業で意味もわからずパソコンを触った記憶が薄っすらあるくらいです。

エンジニア職にある者としては遅いパソコンデビューですけれども、少し上の先輩は卒論を手書きしていたほどですから、一般人としては平均的な姿かなと思います。私の記憶が正しければ、「京都大学 織田信長」というワードでインターネット検索をしてヒットした件数が1件や2件だったと2001年頃に何かに書かれていたので、それくらいの時代だと想像してください。

思い出話が過ぎました。業務効率化ツールに話を戻します。といっても相変わらず使っていたのはメールくらいです。パソコンで使うメールとしては、最初gooメールを使い、のちにGmailに移行して、現在まで使い続けています。私は今でもGmailを業務効率化ツールの主力として使っていますから、若い頃に身に着けた習慣を変えるのが難しいのかもしれません。

2013年までにメール以外の業務効率化ツールを使っていた記憶はありません。パソコンは日常的に使うようになっていたので、フォルダを階層別に整理して、塾で担当している生徒ごとに教材を格納するといった形でタスク管理をしていた記憶はあります。

TwitterやFacebookといったSNSが流行り始めた頃に試してみましたが、長続きしませんでした。その頃から現在に至るまで使い続けている人もたくさんいますから、SNSをどう使うかは個人の趣味嗜好によるのかなと思います。

(3)近年(2013年〜2024年)

この約10年でさまざまな業務効率化ツールに出会いました。塾やエンジニア関係その他いろいろな仕事をするようになったという個人的な事情と、各種ツールが登場したという時代がマッチしたのでしょう。

私はできるだけ脳内で完結させたい派であり、紙のスケジュール帳でさえ長らく使っていませんでした。複数の仕事を掛け持ちするようになり、また若い頃のように何でも覚えられないようになって、渋々紙のスケジュール帳を2013年の少し前に導入していました。

紙のスケジュール帳からGoogle カレンダーに切り替えたのは2014年12月です。これはGoogle カレンダー上に記録が残っているのではっきりしています。

LINEも2012年〜2013年あたりに使い始めました。プライベートに近いやり取りで使うことが多いです。

Slackは2018年に使い始めました。エンジニア関係の仕事をしている人から教えてもらいました。

GitHubを使い始めたのは2020年です。エンジニア的な仕事を本格的にするようになって導入しました。

Notionはごく最近登録しました。それがこの記事を書くことになったきっかけです。

kintone、Zoom、Chatworkなども、業務上で求められて使ったことがあります。

 

2.現在の姿

自分から主体的に使うのは、メール(Gmail)とスケジューラー(Google カレンダー)だけです。

メールはなるべく早く返信するようにして、返信し終えたりそもそも返信の必要がなかったりするメールはアーカイブして受信トレイから見えないようにしています。

そうすると、受信トレイが、返信対応しなければならない案件などのタスク管理を兼ねられます。

Slack、Notion、GitHubなどもメール通知に対応していますから、メールに一元化することができます。

メールという仕組みは一つの会社に依存しているわけではありませんし、共通のインターフェイスとして優れていると思っています。

世代のせいかメールが万能ツールだと思っている節が私にはありますが、月のカレンダーというビジュアルで予定を把握したいという思いも他方であり、スケジューラーはメールと別に利用しています。

締切があるようなタスクはスケジューラーのほうに書き込んで管理しています。

受信メールが起点とならない事柄については、Gmailの下書きかGoogle カレンダーにメモするようにしています。スマホからでも簡単に入力できますしね。

そうするとインターネット上に保存されるので消えてしまうことが基本的にありませんし、クロスデバイスで参照できますので。

ついでに言いますと、インターネットの閲覧にはGoogle Chromeを使っておりまして、GmailとGoogle カレンダーのタブを常時開いています。

翻訳、決算作業、資格試験対策、業務用の連絡ツールなど、その時々で取り組んでいることに関するリンクをGoogle Chromeのブックマークバーの見えやすい場所に配置して、作業の取っ掛かりのハードルを少しでも下げるようにしています。

プログラミングのコードを本格的に書く場合はGitHubを使います。バージョン管理に優れていますし、デプロイでも使うことになりますから。

あとは取引相手が求めるままのツールを使います。

これが2024年現在の私の完成形です。

 

3.概念整理

業務効率化ツールとして必要となる機能を挙げると、コミュニケーション、スケジューラー、タスク管理、メモあたりになるでしょう。

コミュニケーションは相手があってのことですから、相手の希望するツールを使うという側面が大きいです。

スケジューラーも多くのツールで使うことができ、個人的にはできれば使いたくないのですが、たくさんの仕事を掛け持ちしているとそういうわけにもいきません。毎日決まった会社に出勤するという仕事であれば、スケジューラーを使わなくても何とかなるかもしれないと想像はします。

タスク管理は複雑なツールを使うくらいならさっさと片付けたほうがよい、時間がかかるものであれば少しずつ終わらせたいと思ってしまうので、基本的に使いません。私は、コミュニケーションやスケジューラーと紐つけて管理しています。

メモはおよそどのようなツールでも使える機能でしょう。そして、個人的には、極力メモは取りたくない派です。大事なことは脳内に入れたほうが早いです。忘れてしまうようなことは大事ではないと言いたいところです(仕事上の細かい数字などはメモに取ります)。

調べたことや考えたことをこうした記事にまとめるのも、そうすることで荷を下ろしてすっきりさせて、次の新しいことに取り組めるようにするという目的があったりします。

先に述べた現在の完成形を概念的に分解すると、このようになります。

とにかくシンプルにすっきりさせたいという思いが強いです。

 

 

 

 




top