はとのーと

エジソンノート(アイデア、思い付き、メモ)として使っています。誰かの役に立つかもしれないので公開しています。

メモ 2020-08

目次:

2020-08-26

並行 (Concurrent) と並列 (Parallel) の違い

並列(Parallel)と並行(Concurrent)の違いについて - Togetter

Wikipedia並行計算並列計算

上記 Togetter のコメントや Wikipedia などから考えると次のような違いがあるようです。

  • 並列 (Parallel): 物理的に同時に処理する
  • 並行 (Concurrent): 結果として同時に処理しているように見える (内部では並列動作かもしれないし、時分割かもしれない)

2020-08-27

O(n) は計算量を表す

O(n) は ランダウの記号(Wikipedia) で「オー」または「ビッグオー」と呼ばれます。

「入力サイズ n が増加するにつれて実行時間が n に比例して増加する」ことを O(n) と表し、「入力サイズ n が増加するにつれて実行時間が n の 2 乗に比例して増加する」ことを O(n2) と表します。

参照: [初心者向け] プログラムの計算量を求める方法 - Qiita

2020-08-31

Windowsシンボリックリンクとジャンクションとハードリンクの違い

Windowsのシンボリックリンクとジャンクションとハードリンクの違い:Tech TIPS - @IT

  • ハードリンク (mklink /h) はユーザ権限で作れるが見た目でリンクかどうか(後から)判断できない。
  • ジャンクション (mklink /j) はユーザ権限で作れる。ショートカット矢印がつく。
  • シンボリックリンク (mklink) は管理者権限が必要でネット上の共有フォルダへもリンクできる。ショートカット矢印がつく。

メモ 2020-07

目次:

2020-07-17

viのナビゲーションキーがHJKLなのはADM3AのHJKLキーに矢印が書かれていたため

ダム端末ADM3AにRaspberry Piを内蔵してLinuxマシンにした人を発見しました。 ADM3A自体を改造したわけではなくRS232C端子にRaspberry Piを接続したようです。

ADM3A – ancient dumb terminal | adcurtin

ここに次のような記述がありました。

This terminal is where the HJKL navigation keys in vi come from (vi was written on one and those keys have arrows on them on its keyboard). It’s also where the ~ = home directory in unix comes from as well, the ~ key is also the home key.

(↓適当な翻訳)

この端末はviのHJKLナビゲーションキーの出どころです(viはこの端末で書かれ、この端末のキーボードのそれらのキー上には矢印があります)。 この端末はUNIXチルダ(~)=ホームディレクトリの出どころでもあり、~キーはHOMEキーでもあります。

ADM3Aのキーボードの画像がありました (画像は The HERE IS key | Dave Cheney より)。

https://dave.cheney.net/wp-content/uploads/2017/08/Screen-Shot-2017-08-21-at-14.15.25-1024x420.png

また、ADM3Aのキーについて書かれているページ (上記ページの日本語訳的なページ) を発見しました。

テキストエディタ「vi」の開発に使われた端末「ADM3A」には現代のキーボードにはない「HERE IS」というキーがあった - GIGAZINE

画像と記事から、確かにHJKLキーの上に矢印が刻印されており、またチルダ(~)はHOMEと同じキーに書かれています。

2020-07-27

RESTfulアプリ設計のステップ、DOM Scriptingの3原則

RESTful Web アプリの設計レビューの話

www.slideshare.net

  • RESTfulアプリ設計のステップ
    1. 対象となるデータを認識する
    2. 対象となるデータをリソースに分ける
    3. リソースにURLで名前を付ける
    4. リソースに対して統一インターフェイスのサブセットを提供する(GET/POST/PUT/DELETEをマッピング)
    5. クライアントから受信する表現(Representation)を(一つ以上)設計する
    6. クライアントに送信する表現を(一つ以上)設計する
    7. ハイパーメディアリンクとフォームを使用して、このリソースを既存のリソースに統合する (接続性=Connectednessを高める)
    8. 正常系を考える(適切なリクエストがあったとき何が起こるべきか)
    9. 例外条件を考える(不適切なリクエストがあったとき何が起こるべきか)
  • URLに動詞が含まれていないか
  • URLが無理な構造になっていないか
  • URLの意味と意志
    • 例: http://example.com/blog/entries?page=3&lang=ja
    • ?の前までがリソースの意味
    • ?の後がクライアントの意志
      • ?以降を取り去っても意味は変わらない
  • CRUDの重力に引かれていないか
    • 第3正規形のテーブルと1:1のrouteがあるのは粒度が細かすぎる
    • リソースの粒度/視点(つまりはURL)とデータベースの粒度/視点の違いを解釈してしかるべく結びつけるのがControllerの仕事
  • あまり非同期処理に頼らない
    • DOM Scriptingの原則に従う (※)
    • RESTfulなサーバとリッチjsという設計に倒しすぎるとUXや保守性が低下する可能性があるので注意

(※)ここに「DOM Scriptingの原則に従う」と書かれています。 DOM Scriptingの原則とは一体何でしょう?

DOM Scripting ことはじめ

www.slideshare.net

このスライドによると以下のように書かれています。

DOM Scripting 3原則:

  • Progressive Enhancement
    • 段階的強化
    • Structureに段階的にPresentation(CSS)、Behavior(JavaScript)を追加する
  • Graceful Degradation
    • 表示機能的に劣る(もしくは意図的にJS OFFにしている)ブラウザでも、できるだけそれに合わせた形でアクセシビリティを保つこと
  • Unobtrusive JavaScript
    • HTML(Structure)の中にJavaScript(Behavior)を記述しないスタイル

Activity Based Datamodelについてのメモ

ABD (Activity Based Datamodel) についてのメモです。

  • 1 Seasar Conference 2006 Spring © The Seasar Foundation and the others all rights reserved. EJB3 時代の ERD レッスン ~ Activity Based Datamodel
    • 大元になったSeasar Conference 2006のスライド
    • システムより前に業務プロセスがある
    • DBはシステムの一部であり、ユーザにとって大切なのはUI
    • UIの操作にはシナリオがあり、シナリオに沿って動いた結果がDBに入る
      • 予定を立てた結果 → 予定データ
      • 計画を立てた結果 → 計画データ
    • 製品を販売する場合:
      • 受注した結果 → 受注記録
        ↓ 梱包依頼
      • 梱包した結果 → 梱包記録
        ↓ 出荷依頼
      • 出荷した結果 → 出荷記録
    • 業務と対になるのがイベント系、それ以外はリソース系
    • イベント
      • 「○○する」と言える、「○○日」がある
      • 受注する、受注日 = OK
      • 顧客する、顧客日 = NG
    • リソース
      • 「○○名」と言える
      • 顧客名 = OK
      • 受注名 = NG
    • 「○○する」「○○名」の両方言えないものは属性
      • 数量する、数量名 = NG
    • 必要項目は出力(帳票)から決める
      • 出力に必要な項目がDBにないと駄目
      • 出力に必要な項目を入力画面に作る必要がある
    • イベント系とは交差エンティティである
    • そもそもコッドのリレーショナル理論では:
      • ドメイン: それぞれの列が取り得る値の集合、重複なし
      • リレーション: ドメインの値を組み合わせたもの
    • ドメインをテーブルと考えると、リレーションはドメインテーブルの外部キー(FK)を集めたもの
    • リソースとリソースを結ぶとき、リソースにFKを入れると多対多だけ特殊になってしまう
    • 本来はリソースとリソースを結ぶ「何か」があり、それが抜け落ちていると考える
    • 例えばリソース「顧客」とリソース「商品」の間には「販売」という関係がある
    • 関係を表す交差エンティティで結ぶ
    • 交差エンティティはFKと属性と、それ自身のIDを格納する
    • IRE (Inter Relational Entity)
      • Activityを表す交差エンティティ
      • FactにはFKを入れない
      • IREは同じタイミングで使うFactをFKとして参照する
  • Seasar Conference 2006 Spring (5) - 世界線航跡蔵
    • リソース系はFactを記録する
    • イベント系はActivityを記録する
    • 従来のモデリングであればリソース系のEntityに含まれているようなFKを全部抜き出して、それをイベント系として再定義してしまう。リソース系にはFKは含まれなくなる
    • 「リソース系はFKを持たない」「いくつかのリソース系の間を結ぶ関係がイベント系。FKの集合体(+ID)がイベント系」と考えてしまえば、悩む余地って殆んど無くなる
    • ABDはアジャイルで変更に強いDB設計
  • RailsとABDとCRUDとワークフロー - moroの日記
    • ABDでは仕事とはリソース系とイベント系に何らかの関係を発生させること
    • お客(リソース)と商品(リソース)の間に購入・入金といったイベントが発生する
    • 仕事をする=イベントを発生させる=イベントテーブルにCRUDする
    • Ruby会議でDavidが言った「MemberがGroupから抜けるのはMembershipがdropされる」とマッチする
    • ある仕事を終えたコアイベントが次に行われるべき仕事を定めるのが業務フロー
    • 個別の仕事と業務フローは別々に記述できるようにする
      • →業務フローに変更があっても個別の仕事は変更しなくてよい
  • 気楽に生こうか: データベース設計手法
    • 『楽々ERDレッスン』はABDのテキストとして使える