136 Matching Annotations
  1. Last 7 days
    1. フォルダー

      原文を尊重するべきですが、ディレクトリとフォルダーで表記ゆれがあるのが気になりました。

    2. 記載指定アル

      Typo 「記載してある」

    3. プロジェクトをクローンできます

      「プロジェクトはクローンすることができます」のほうが良いです。

    4. 状態間での

      「状態同士での」のほうがよいです。

  2. Jun 2024
    1. mainブランチマージ

      「mainブランチにマージ」

    2. 作成できます

      「作成することができます」

    3. ステータスを確認するのはよい考えです

      「ステータスを確認するとよいでしょう。」のほうがよいです。

    4. Gitがどのファイルを追跡する予定かが把握できます。

      「Gitが追跡する予定のファイルが把握できます。」のほうがよいです。

    5. ファイル名は最初にドット(.)をつけて拡張子はありません。

      「拡張子はなく、ファイル名は最初にドット(.)をつけます。」のほうがよいです。

    6. 最新の動作しているバージョン

      「動作している最新のバージョン」のほうがよいです。

    7. 心配が不要となる

      「心配がなくなる」のほうがよいです。

    1. そういった

      「そのような」のほうが書籍の文言としては適切に感じます。

    2. 別名

      エイリアスの方が一般的に感じます。

    3. このようなおかしい

      「このような、おかしな」

    4. 集まり

      原文ではsetとありますが、「集合」ではないでしょうか?

    1. print(current_number) Copy to clipboard

      前の行とインデントが1カラム異なって見えます。

    2. こういった場合に

      少しカジュアルなので「このような場合に」

    1. 3匹

      エイリアンの数え方が匹は違和感があります。3体のほうが自然ではないでしょうか。

    2. 集合のはずです

      「はず」は削除したほうが日本語として自然です。

    1. age = 12 if age < 4: price = 0 elif age < 18: price = 25 else: price = 40 print(f"入場料金は{price}円です。")

      値段がこのコードから100分の1になっており説明と一致していません。

    2. より大きい

      「超過」のほうが統一感があります。

    3. 不等性のテスト

      「等価性のテスト」と統一するなら「不等価性のテスト」

    4. car 変数

      個人的には「変数 car」という表現が一般的だと思います。

    1. ラバーダックデバッグ

      個人的には「ラバーダック・デバッグ」の表記の方が自然に感じます。

    1. クリーンで

      「さっぱりしており」という訳はいかがでしょう?

    2. 気をつけて

      ですますを揃えるなら「気をつけてください」

    1. この項では、Pythonのキーワードと組み込み関数の名前の一覧を示すので、変数名での使用を避けるべき名前を把握できます。

      組み込み関数と同じ名前を使用したい場合にはアンダースコアを追加した変数名を定義する方法があるという訳注もあると便利と感じましたが、余計かもしれません。

    2. Python 3.11.0

      3が強調されているのは意図してのことでしょうか?

    1. 既存の動作を損なったこと

      「既存の動作をしなくなったこと」のほうが自然です。

    2. テスト関数は自分自身では決して呼び出しません。

      「自分自身」という表現に違和感がありました。「テスト関数自体は」でしょうか?

    3. しないでください。しかし、

      「してはいけませんが、」など、ここは文をつなげた方が自然に読めます。

    4. よくデザインされた

      デザインよりも設計の方が自然かもしれません。

    1. 長方形のサイズを変更しようとしたときにPythonにエラーを発生させたい場合

      長方形のサイズを変更できないようにという意味だと思いますが少し表現がまわりくどいと感じました。

    2. といった

      「などの」

    3. 表す

      「示す」

    1. 手に負えない

      「解決できない」

    2. 起こります

      「発生します」の表現が一般的と感じます。

    3. favorite_language 変数には、後ろに余分な空白文字を含んだ文字列が値として関連付けられています❶。

      数字が後ろにあると読みにくいです。前に移動してほしいです。表現も「(数字)」として参照先と揃えてほしいです。

    4. 変数に関連付ける

      「変数で参照する」?関連付けるという日本語に違和感があります。

    5. 検討することは

      「考慮すること」

    6. 見てみます

      「確認します」のほうが表現として適切だと思います。

    7. 費やしたなら

      文脈を考えると「費やしてしまったなら」でしょうか?

    8. その変数名が

      「その変数名を」としたほうが文法として正しいと思います。

    1. この章の演習問題は、本質的な調査についてです。 第2章からは、学んだ内容に基づいて解くべき課題が出されます。

      「本質的な調査」の意味が読んでいてわかりませんでした。この問題は学んだ内容に基づいていないという表現と関連があるのでしょうか?

    2. ディレクトリー

      「インタープリター」を「インタープリタ」に修正する場合、こちらも「ディレクトリー」を「ディレクトリ」にしたほうが良いです。

    3. NN

      修正予定の箇所でしょうか?

    4. Install Certificates.command

      おそらくこれはファイル名であると思いますが、読んでいて確信が持てませんでした。

    5. 旧式のバージョン

      「古いバージョン」のほうが自然に感じます。

    6. 場合は

      「場合は」が連続しているので最初の「場合は」は削除したほうがよいです。

    7. 近代的な

      「モダンな」のほうが違和感が少ないです。

    8. 長い伝統

      「長年の伝統」としたほうが自然に感じます。

  3. May 2024
    1. バック倉ウインド

      Typo 「バックグラウンド」

    2. 番目のプロジェクト

      Typo 「3番目のプロジェクト」

    3. 2番目のプロジェクト(第4章から第6章)はデータの可視化を紹介します。

      「データの可視化を使用したプロジェクト」であることを伝えてほしいです。今の文ではプロジェクトの紹介なのか可視化の紹介なのかわかりません。

    4. 。 。

      Typo「。」

    5. 導入したい

      「紹介したい」のほうが意味がわかりやすいです。

    6. 『最短距離でゼロからしっかり学ぶ Python入門』

      第3版刊行に際しての序文ではタイトルが英語になっていました。日本語のタイトルか英語のタイトルのどちらかに統一したほうが良いです。

    1. ま。す

      Typo 「ます。」

    2. 気持ちになり、

      「気持ちになります。」のように文を区切ったほうが自然になります。

    3. 私の責任です

      「著者の責任です」のほうが一般的な表現だと思います。

    4. プロのインスピレーションにとって変わらない源泉となっています。

      適切な訳がわかりませんが日本語として違和感があります。

    5. No Starchには

      「No Starchの」

    6. 本書を

      「本書は」

    1. 助けを得る上

      「助けになる」が表現として自然だと思います。

    2. エイリアン侵略プロジェクト

      「侵略」よりも「インベーダー」のほうが一般的に感じます。

    1. {button-link}ディレクティブ、{button-ref}ディレクティブのオプション

      このセクションは公式ドキュメントを見ればよいと思います。

    1. ディレクティブのオプション

      このセクションは公式ドキュメントを見ればよいと思います。

    2. :open: オプションを付けると、ドロップダウンが開いた状態で表示されます。

      こういうオプションの説明はとても分かりやすいです。

    1. レスポンシブなドキュメントが作成できます。

      少し気になったのですが、レスポンシブルな部分は書籍ではどのように表現するのでしょうか?

    2. グリッド カード タブ ドロップダウン バッジ ボタン

      この部分に各セクションへのリンクを追加してほしいです。

    1. {card} ディレクティブの :link: リンクオプションを使うと、カード全体がクリック可能になり、クリックするとリンク先に移動します。

      こういう例は読んでいてとても楽しいです。

    2. {card}ディレクティブのオプション

      個人的にオプションを全て羅列する書き方は読みにくいです。オプションを全て確認するのであれば、公式のドキュメントを確認すればよいと思います。オプションの説明は最低限として、グリッドを使用した例の数を増やしてほしいです。

    1. {grid} ディレクティブのオプションは次のとおりです。

      デフォルトのないオプションがありますが、これらのオプションの値設定は必須でしょうか?

    1. 次に、 Listing 88 のコマンドを実行し、プロンプトに次の必要事項を入力します、 Select include_ci では 1 (github)にします。

      your_github_username などの説明は別途必要ですね。

    1. 数式の記述

      Mathjaxで表示されることとMathjaxとはなにかの説明があると良いなと思いました。

    2. ``` {eq}`geometric-brownian-motion` の確率微分方程式は伊藤の公式をもちいて次のように書き換えられる。 ```{math} :label: itos-lemma d\log{S_t} = \left(\mu-\frac{\sigma^2}{2}\right) \,dt + \sigma \,dB_t ```

      シンタックスが途中から緑になっているのが気になりました。

    1. reStructuredText

      reStructuredTextがわかる人は自分で使えることを確認できると思いますし、入門者は混乱するので省いたほうが良いと思います。

    2. Markdown(Github Flavoured Markdown)構文の表

      標準的なMarkdownの仕様とGFMは大きく異なると思いますが、JupyterBookでサポートしているのはGFMのマークダウンのみでしょうか?

    1. (admonition)

      タイトルでは括弧書きを省いたほうが見やすいです。

    1. ``` ```

      この表現だとブロックであることがわかりにくいです。

    2. マークアップ

      マークアップの説明が必要です。

    1. Sphinx

      Sphinxが何かわからない読者が多いと思います。

    1. インタラクティブな操作がブック上で行えます。

      どの範囲までの操作が行えるかより詳細に知りたいです。ipywidgetsの全操作が可能なのでしょうか?

    1. SymPyで生成した数式も糊付けできます。 Listing 64 では、SymPyで生成したオブジェクトを glue 関数で糊付けしています。

      SymPyのコードと文章を分離できるのは素晴らしいと思うのでその点をもっと強調しても良いと思います。

    2. 図を埋め込む場所に、 {glue:figure} ディレクティブ( Listing 63 )を記述することで、 Listing 62 で生成した図が埋め込めます。

      図を出力する際にコードが邪魔ということはよくあるのでこの有用さに共感できます。そのような、ユースケースの説明があるとより伝わりやすいと思います。

    3. ロールを使うと、文章中に糊付けされた変数を埋め込めます。

      なるほど便利ですね。何に使用するかを最初に書いていただけると読んでいて混乱しないです。

    4. 変数の糊付け

      この表現は一般的ではないと考えます。

    1. コードセルの出力を非表示にするには、コードセルに hide-output タグを追加します。

      コードセルの出力を非表示にするとどのような場合に便利か説明があると親切です。

    2. スクロール表示

      スクロール表示自体の長さは固定でしょうか?

    3. MyST Notebook

      MyST Notebookを単体で実行する方法があれば知りたいです。

    1. GitHubやReadTheDoscなどにデプロイする場合、

      「ブックの公開」のセクションへのリンクがあると便利です。

    2. {nb-exec-table} ディレクティブから、Notebookの実行結果の統計を確認できます。

      便利ですね!これはドキュメントのどこに書いても全てのNotebookの実行結果が出力されるのでしょうか?

    3. キャッシュを設定すると、Notebookの実行結果はローカルのデータベースに保存されます。これにより、同じコードを再実行した場合のリソースが削減できます。ブックのビルド時には次のように動作します。

      入門の範囲を超えているかもしれませんが、このキャッシュをGitHubActionsなどのCIで保存できるかを知りたいです。

    1. 本章では、Notebook形式のコンテンツにおいて、Notebookの実行やブックに出力される内容を制御する方法を解説します。 { requestKernel: true, binderOptions: { repo: "binder-examples/jupyter-stacks-datascience", ref: "master", }, codeMirrorConfig: { theme: "abcdef", mode: "python" }, kernelOptions: { name: "python3", path: "./notebook" }, predefinedOutput: true } kernelName = 'python3'

      他の見出し1でも共通ですが、この下にサブセクションの目次があると便利だと思います。

    1. 入力したコードを非表示にできます。

      入力したコードを非表示にすると何が便利なのか説明があると読んでいてイメージがしやすいです。

    1. Jupyter Bookでは、Notebook形式でサポートされているすべてのMarkdown構文をサポートしています。

      こちらも参照できるドキュメントのリンクがあれば親切です。

    1. MySTで記述したNotebook形式のコンテンツ#

      JupytextにはMyST形式からNotebookにする方法だけではなくPythonスクリプトからNotebookにする方法もあり個人的にはそちらがおすすめです。

    1. コンテンツ

      「コンテンツ」と「コンテンツファイル」で表記ゆれがあります。

    2. reStructuredText形式

      入門であればreStructuredTextの説明は混乱するので省いても良いかと思います。

    3. MyST(Markedly Structured Text)形式は、Markdown形式を拡張した機能をもっています。ディレクティブやロールを記述することで、reStructuredText形式と同等の表現力を有します。

      ディレクティブとロールについてここで詳しく説明してほしいです。

    4. コンテンツの種類

      コンテンツの種類の説明が目次の前にあるとわかりやすいと思います。

    1. この設定をすることで、 .github や .venv などの隠しファイルをビルド対象から除外できるようになります。

      設定しなくてもビルドはできるのか知りたいです。ビルド速度に影響があるか否かの情報もあると嬉しいです。

    2. に存在しない

      「に設定しない」という表現のほうがわかりやすいです。

    3. ディレクティブ

      ディレクティブの説明が必要だと思います。Sphinxのディレクティブについても言及があると背景がわかりやすくなると思います。

    4. Listing 22 options:エントリの設定

      Listing 21から変更した部分を強調表示していただきたいです。

    5. Listing 21 defaults:エントリの設定

      どのファイルの話なのかが読んでいて分からなくなりました。説明をお願いいたします。

    1. Listing 20 _toc.ymlファイルを生成

      コードブロックとファイルの内容の表記がどちらもListingなので両者を区別できるようにしてほしいです。

    2. 結果

      「結果ファイル」のほうがわかりやすい表現だと思います。ファイル名もあるとよりわかりやすいです。

    3. サンプルプロジェクトとして、 Listing 17 のようなディレクトリとファイルを用意します。

      ここまで作成したサンプルプロジェクトを使用しない理由がわからず読んでいてもやもやしました。前節までのサンプルを使用するか、理由を説明してほしいです。

    4. jupyter-book toc from-project コマンドを実行して、

      文章内に組み込むのではなくシェルのコードブロックで記述したほうが読んでいてわかりやすいです。

    5. file: : ローカルにあるテキストファイルのパスを _toc.yml ファイルからの相対パスで指定します。 glob: : glob モジュール [1] に従ったパターンを指定します。 url: : ウェブサイトのリンクを指定します。

      箇条書きにした方が見やすいです。

    6. ルートページ(最初のページ)

      「最初のページ(以降ルートページ)」という表現の方が分かりやすいと思います。

    7. ブックの構造は目次ファイルで決まります。目次ファイルは _toc.yml というYAMLファイルで作成し、このファイルに記述された順序や階層に従ってブックが作成されます。

      _toc.yml の公式ドキュメントへのリンクがあると親切だと思います。

    1. さまざまなコンテンツの作成

      「さまざまな」を削除しても情報量は変わらないので削除したほうがわかりやすいです。

    1. もう一度、「Content with notebooks」を確認します。コード実行時のエラーはなくなり、Matplotlibによるグラフが描画されています。

      JupyterBookを使用していて同様のエラーに遭遇して解決できずにいました。この解決方法の参考にされたブログなどはありますか?

    2. キャッシュ

      キャッシュが何なのかわからないです。

    3. ブラウザで開いて確認します。

      ブラウザはどのブラウザでも問題ないか知りたいです。

    4. 「first-book」という名前のプロジェクトでブックを作成します。

      「first-book」という名前は変更してもよいのか。変更してもよいなら変更した場合はどうなるのか知りたいです。

    1. _toc.yml ファイルに前節で作成したファイルを追加します( Listing 11 )。

      ファイルパスにはディレクトリを含むこともできると説明があると親切だと思います。

    1. 次のセルには、コードブロックにPythonのコードを記述します。

      もう少し内容のあるコードの方が理解しやすいです。

    2. コート

      すいません。気になってしまったのでTypo

    1. 次のファイル形式に対応しています。

      JupyTextを使用すると .py ファイルも対応させることができました。

    2. 次のような設定を行えます。

      設定の一覧を確認できるドキュメントのURLを知りたいです。

    3. YAML形式

      YAML形式の説明が必要な読者もいると思います。tkoyama010は必要ありません。

    1. はじめてのJupyter Book

      まずは、Jupyter Bookがどのようなツールなのかの説明がほしいです。