ただの雑記

おっさんエンジニアが適当に書き散らかしてます。

考えるには体力が必要/サーバーの電源を切るのは緊張する/Open-World assumption

考えるには体力が必要

リモートワークになり、普段は数百歩で週に2回ほど買い物に行くときで2千歩ぐらいしか歩かない生活なのに、珍しく出社したりモデルハウスを見に行ったりと1万歩前後歩くと、当日はもちろん次の日も体力的にしんどくて何もする気にならない。

もう少し普段から運動していかないとそのうち起きているだけで体力が足りなくなりそう。

サーバーの電源を切るのは緊張する

オフィスビルの法定停電の対応のために社内においているサーバーの電源を切る。管理担当は私だが、引き継いだサーバーで普段触っていないからよくわかっていないし、問題がおきたら治せないサーバー達。

ログインアカウントが無いとか色々トラブって、結局7台ぐらいのサーバーの電源を切る作業に2時間ぐらいかけた。

Open-World assumption

オントロジーを学ぶこととオントロジーをプログラミングすることを同時に達成するために、「Ontologies with Python: Programming OWL 2.0 Ontologies with Python and Owlready2」という本を読み始めている、

その中に次の様な一節があり、なんだかすごく印象に残った。

The ontology is based on the Open-World assumption: that is, anything that is not expressly prohibited is considered possible.

明示的に禁止していないことは可能性がある。

ビジネス著作権検定/杖道/オントロジー

ビジネス著作権検定の初級を受験した

会社で著作権の講習があり、その講習を受ける人はビジネス著作権検定の受験も推奨していたので受けてみた。

頒布とか貸与とか譲与みたいな何となくイメージが被るあたりとか、映画とかレコードとかの違いみたいなのに迷う。

杖道

杖の稽古をして筋肉の衰えを感じた。

4月頃に演武をするので、演武用の形を少し稽古したのだが表の鍔割りを稽古したところ、背筋に無理な力がかかって思わず「背筋が……足りないです」っていてしまう。 先輩が「背筋??」ってなった。

オントロジー

直近やってる研究のサーベイをするのに全くキーワードが思いついていなかったのだけれど、唐突にオントロジーにたどり着いた。

やりたい事は他分野だけど橋本らの「病理診断報告書作成のためのオントロジーを利用したテキスト入力支援」*1とかそれぽいなと思った、

まっずはオントロジーをプログラミングしてみるかと本を探したところ「Ontologies with Python: Programming OWL 2.0 Ontologies with Python and Owlready2」*2という本があったので読み進めてみようと思う。英語だから途中で諦めそうだけど。

*1:橋本泰一, W. TAM, 鷹合基行, 荒牧英治, 橋田浩一, and 宇於崎宏, “病理診断報告書作成のためのオントロジーを利用したテキスト入力支援,” in 言語処理学会 第17回年 次大会発表論文集, 2011, pp. 940–943.

*2: L. Jean-Baptiste, Ontologies with Python: Programming OWL 2.0 Ontologies with Python and Owlready2. Apress, 2020.

CTのデータを貰えば良かった/型を考えよう

CTのデータを貰えば良かった

先日、健康診断で要再検査となった項目の再検査でCTを受けた。

医者では無いのでCT画像をみたところで何も分かる訳ではないのだけど、見るのが楽しいのでいつも欲しいなと思っている。

教授とのMTGで、CTの画像とか欲しいんですよねーと言う話をしたら、そう言えば教授の指導教官は、なんかの検査データを貰って自分でプログラム書いて見てたらしい。

次回、CTとることがあればデータを貰おう。

型を考えよう

OpenAPI Document(YAML形式)の内容を弄るextensionを作ろうとTypescriptを弄ってる。

まずはVScodeで操作しているDocumentの現在行がschemeの要素かを知りたかったので、@stoplight/yamlパッケージを導入した。

@stoplight/yamlgetJsonPathForPositionを使うと現在位置までのプロパティを配列として受けとれるので、配列を走査すればschemeの要素かは分かる。

つぎに、現在行がtypeプロパティでかつstringになったについてを調べようとした。 先と同じように現在行を@stoplight/yamlパッケージのparseWithPointersを使うことでtype: stringであれば{type:"string"}というオブジェクトになるので、typeというプロパティがあるかと、typeの値がstringなのかを確認すれば良い。

問題は取得できるのがobjectなので、typeと言うプロパティが定義されているかは未定義なので、typeの値を参照するようなコードを書いていると警告がでる。

将来のことも考えるとそろそろ、型をちゃんと考える必要がでてきた。

杖の稽古と予算執行

久しぶりに杖の稽古をする

忙しくて、全然稽古に言っていなかったのだが今日は見学の人も来ると言うので稽古にいった。

見学の人は先輩が応対して、ちょっと前から稽古に参加している人の練習に付き合う。

基本全然できてないんだけど、心穏やかに教えることができていたので、なんでかなーと思ったが、自分の弟子じゃ無いからだろうなって思った。自分の弟子では無いので変な気負いがなくちょっと良くなれば素直に良いね!って言えるんだと思った。 (なお、自分の弟子などいない)

4月だったか先輩の知り合いの大会で演武をすることになっているので、最後に少し合わせる。久しぶりに古流をすると全く順番が思い出せなくて恥ずかしい……

今年こそ奥入したいと思っているけどもっと稽古しないと難しそうだ。

予算執行

大学から研究費を貰っているので、使う必要がある。 元々、学会の年会費や学会への参加費用として申請していたのだが、そもそも学会の年会費やデジタルライブラリのサブスクリプションには使えず、学会参加も昨今オンラインのためそもそも旅費が不要……学会参加の数千円ぐらいに使えるけど自腹で払ってた結果、そこそこ予算が余っている。

MacBook Airを買おうかと思ったが、納期未定で年度内に納品できない恐れがあると言われて諦める。(予算は年度内に使わないと行けないが、納品後に支払になるので年度内に納品されないと払えない)

ならばと、ThinkPadを見積もったがこれも納期が怪しい。生協の人を通して注文するのだが生協の人曰くAppleレノボなんかの外資系はキャンセルは厳しいけど、提示する納期はいい加減なので、年度内納品の場合流通在庫品か、マウスコンピュータとかの納期が安定しているところが良いとのこと。

そこでマウスコンピュータで見積を作って発注ができた。予算が後数千円多ければ満足なスペックにできたけど、予算の関係で若干スペックは妥協した。まぁ私の研究は今のところそんなにスペック使わんから大丈夫だろうって感じ。

後は納品後の書類仕事だがこっちもちょっと一苦労しそう。

怪しい契約と頑張れない日々

怪しい契約

不動産サイトで条件付き土地として掲載されていた土地に、参考プランで費用見積を出して貰って、モデルハウスを見ながらコストについて聞く。

売買代金には外構費などものっているらしく、大きく費用は変わらなさそう。

問題は、仲介手数料が建物代も含んでいる額なんですよね。

どう考えても大阪府のサイトとかでトラブル事例として載せているパターン。

www.pref.osaka.lg.jp

当然、担当者からは特に説明がないので仕方が無く「建物が無い段階では建物についての売買契約できないんじゃないですか?このままで言って円満に引き渡せれば良いんですけど、トラブったときに私から不適切な契約だったとか言われませんか?」と契約の怪しい箇所を伝えてみた。

当然担当者の方は有識者なので、そうですね不味いですねって感じで回答してくる。上司に言って普通の土地だけの契約に出来ると思います。という回答だけど60万ぐらい手数料へるし、なんか他の部分で気づかないように増されそうでなんかちょっとなぁってお気持ちになる。

頑張れない日々

研究の一環でVS CodeのExtensionを作るのだが、全然進んでいない……

PoCのPoCを少し書いた。

dateと打ち込むと現在時刻を補完するようにしてみた。

class Completion {
  public performCompletion(
    document: vscode.TextDocument,
    position: vscode.Position
  ): any {
    var result = [];
    var lineText = document.lineAt(position.line).text.trim();
    if (lineText === "date") {
      var date = new Date();

      var newValue = date.toString();
      var newItem = new vscode.CompletionItem(
        "date",
        vscode.CompletionItemKind.Value
      );
      newItem.insertText = " " + newValue;
      newItem.range = new vscode.Range(position, position);
      result.push(newItem);
    }
    return result;
  }

  dispose() {}
}

不動産の内覧をする

今日は不動産の内覧をした。

コロナが流行ってから仕事がリモートワークになったのと、同居している親が家にいることが増えた結果、仕事用の部屋が欲しくなった。

引っ越しを検討したところ一部屋増やすことによって増える家賃負担を考えると、中古の戸建てを買った方がいいんじゃ無いかと考えて昨年からひっそりと資料請求していたのですが、今月になり急に不動産屋から最近どうですか?と連絡があり適当に応答していると内覧を進められたので内覧してきた。

どうせ内覧するならと、他の気になる物件にもまとめて資料請求したら、各社から電話かかってきて「なんか想像した不動産営業っぽい!」となった。

なので、今日は内覧したメモ日記。

内覧

今日は3件見た。以下見た順。

中古住宅A

3階建て中古住宅なのに新築ぐらいの価格。 旗竿地なのかな?竿の部分に車停められるけど車停めたら出入り窮屈そう。

良かった

  • 間取りは希望通り
  • 風呂広かった(ミストサウナという存在をはじめてしる)
  • 室内綺麗
  • クローゼットで買い
  • 自転車を濡らさずに保管できそう
  • ベランダも十分な広さ

良く無かった

  • 駅徒歩13分
  • 直前にリフォーム(壁紙とか)してるのでその分が販売価格にのってる
    • 見た目綺麗だけど、逆に不具合あっても……って気持ちが若干
  • 1階がくらい(前方の家が邪魔)

新築 A

3階建てお値段は先に見た中古と同じ。 奥まった所にある。

良かった

  • 割と小さい間取りでもいいなって思えた。
  • 南側道路で一階も明るい

良く無かった

  • 斜線制限で3階の天井が低いところがある
    • 家具家電の置き場所に制約が出る
  • 駅徒歩12分
  • ベランダが少し狭い

新築 B

3階建てお値段は先に見たものより少し安い

良かった

  • 部屋の広さがちょうど良い

良く無かった

  • 斜線制限で3階の天井が低いところがある
  • 西側の採光とかちょっと夕方まぶしそう
  • 駅徒歩12分
  • 私道で砂利道

まとめ

3件ほど同じような間取りを続けて見たが、斜線制限で天井が低くなっている家は家具などの配置に制限がでるので難しい。

駅徒歩12分ぐらいなら歩けるなという気分になってきたのは良かった。

ただ、帯に短したすきに長しな所はどうしてもでるので、どうせ我慢をするなら注文住宅の方がいい気がしている。そして1件ちょうど良いのを見つけてしまった。

ただ、ローンできる部分以外に現金が必要な部分をどうしようと思ってる。現金の手持ちが少なくてどうしたものかと考えている。 家を買うのに必要な現金も無いし、なんなら新居に用意する家具家電を買う金も無い……

良いOpenAPI Documentについて考えている

今週は「良い」OpenAPI Documentについて考えている。

「良い」というのはどういうことなのかが分かっていない。

例えば細野ら*1はOpenAPI Documentとその実装にずれがあることをあげている。

本来的には仕様書であるOpenAPI Documentと実装がずれているのであれば、実装誤りのはずですが、現実的には実装が正でOpenAPI Documentの定義が誤りということが多いように思う。

つまりこのような状態にあるOpenAPI Documentとは「良く無い」OpenAPI Documentなのだろうと思う。 悪い理由は言いやすいけど、逆に良いOpenAPI Documentととなると悩む。

教授のアドバイスもあり古い論文に目を通そうとBoehmの「Verifying and Validating Software Requirements and Design Specifications」*2を読んでる。

タイトルの時点でVerificationとValidationの違いは難しいなと。

Boehmは「IEEE Standard Glossary of Software Engineering Terminology」の定義を引用しつつ以下のような質問で定義している。

  • Verification. "Am I building the product right?"
  • Validation. "Am I building the right product?"

そう考えると良い仕様書はcorrectな仕様書で、良い仕様書かをVerificationによって確認できるんだろうか。

*1:M. Hosono, H. Washizaki, Y. Fukazawa, and K. Honda, “An Empirical Study on the Reliability of the Web API Document,” in 2018 25th Asia-Pacific Software Engineering Conference (APSEC), 2018, pp. 715–716.

*2:[1] B. W. Boehm, “Verifying and Validating Software Requirements and Design Specifications,” IEEE Software, vol. 1, no. 1, pp. 75–88, Jan. 1984.