未分類

memo_20210201

心底、腹を立てています・・・ 私の1時間は、いったい「いくら」だ？

この問題、

Step 4/7 : WORKDIR /go/hitachi_ride_hailing_go
---> Using cache
---> 62e20b49fae8
Step 5/7 : COPY . .
ERROR: Service 'app' failed to build: Error processing tar file(exit status 1):write /go/xxxxx_ride_hailing_go/static/fonts/Noto Sans Regular/12800-13055.pbf : no space left on device

は、

ディスクスペースを開けるのに"docker system prune"は便利だが、濫用しないこと。docker-compose buildが再び上手く動くという保障はないぞ

で潰した。

しかし、

go: finding github.com/xeipuuv/gojsonpointer v0.0.0-20180127040702-4e3ac2762d5f
go: finding github.com/tidwall/match v1.0.1
go: error loading module requirements
ERROR: Service 'app' failed to build: The command '/bin/sh -c apk add --no-cache  git g++ curl ? && go mod download ? && GOOS=linux GOARCH=amd64 go build cmd/server/main.go ? && curl -L https://github.com/golang-migrate/migrate/releases/download/v4.13.0/migrate.linux-amd64.tar.gz | tar xvz ? && mv migrate.linux-amd64 /usr/local/bin/migrate' returned a non-zero code: 1

が、どうしても取れない。(全部のコマンドをバラバラにして実行する、までした)

何時間も格闘しているうちに、同じディレクトリにある、go.modの記載内容ではないか、と疑い始めたが、

module codes.xxxxx.co.jp/xxxxx/xxxxxx_ride_hailing_go

go 1.12

require (

        github.com/dgrijalva/jwt-go v3.2.0+incompatible

        github.com/go-chi/chi v4.0.2+incompatible

        github.com/go-chi/jwtauth v4.0.2+incompatible

        github.com/gomodule/redigo v2.0.0+incompatible

        github.com/gorilla/websocket v1.4.0

        github.com/jmoiron/sqlx v1.2.0

        github.com/kawasin73/htask v0.4.1

        github.com/lib/pq v1.1.1

        github.com/rs/xid v1.2.1

        github.com/tidwall/boxtree v0.0.0-20180928224827-327de8d774d7 // indirect

        github.com/tidwall/geojson v1.1.3

        github.com/tidwall/gjson v1.2.1

        github.com/tidwall/match v1.0.1 // indirect

        github.com/tidwall/pretty v0.0.0-20190325153808-1166b9ac2b65 // indirect

        github.com/tidwall/sjson v1.0.4 // indirect

        github.com/twpayne/go-geom v1.0.4

        github.com/xeipuuv/gojsonpointer v0.0.0-20180127040702-4e3ac2762d5f // indirect

        github.com/xeipuuv/gojsonreference v0.0.0-20180127040603-bd5ef7bd5415 // indirect

        github.com/xeipuuv/gojsonschema v1.1.0

        github.com/xeonx/geodesic v0.0.0-20150531212225-499ffb552e21

        github.com/xeonx/geographic v0.0.0-20150531172044-7bc7968bc5f9

        golang.org/x/crypto v0.0.0-20190513172903-22d7a77e9e5f

        gopkg.in/guregu/null.v3 v3.4.0

)

の中のどれが原因か(それも1つとは限らない)をどうやって見つければいいのか、分からない。

で、さっき、なんだか分からない内に、以下の操作をしてしまったのだけど

ubuntu@ip-57:~/codes/hailing_go/docker/app$ go mod init m
go: creating new go.mod: module m

を見ているうちに、同じディレクトリにm.modというファイルができていることに気がついた。

その中身はこんな風になっていた。

go 1.13

require (

     github.com/dgrijalva/jwt-go v3.2.0+incompatible // indirect

     github.com/go-chi/jwtauth v4.0.4+incompatible // indirect

)

結果:使用不可能

結論:廃棄決定(取っ手までひびが入っている場合、片栗粉や米の磨ぎ汁を使った方法は採用できない。接着剤は論外)

その他:前回購入は、注文日: 2014年5月31日 でした。十分に減価消却したと思います。

以上

嫁さんから、会社に電話がかかってきて、「ドアが開閉できなくなった」との連絡を受けました。

まあ、私、ドアノブの修理に関しては、学生時代の下宿でずっとやってきて「普通に修理できる」という自信がありました。

ところが、

―― レバーハンドルが動くのに、ラッチボルトが外れない

こんな現象は見たことがありません。

レバーハンドル部を外して見てみたのですが、原因が分かりませんでした。

ラッチ部分も、外部からは異常を観測できませんでした。

ただ、ラッチ部分に見なれない金属片が飛び出ているので、そこをペンチで押さえながら、レバーハンドルの可動部を回してみたら、たまたまラッチボルトが動きました。

私は、そのタイミングを逃さずに、ドアを開きました。

その後、一気にドアノブを解体しました。

-----

観測の結果、ラッチの伝達部が金属疲労で破損して、まったく開閉ができなくなりました。

開閉ができないのでドアノブを分解することもできない、というデッドロックの状態になってしまいました。

このような状態が、トイレなどの密室で発生したら、逃げだす手段がありません。

そこで、あらかじめドアの一部を破壊して、脱出方法を確保しておくことにしました。

で、今日は、自分用のメモとして、こんな動画を作っていました。

So today, I made this video as a note for myself.

後になって分かたのですが、こんなに苦労しなくても、木ネジを外すだけで「すきま」を作り出すことができることが分かりました。

今回は、業者さんを呼んで、4つドアのラッチボルトの交換作業をお願いしました(材料費込みで、1万4000円)。業者さんによれば、「金属疲労で、予兆なくいきなり壊れる」ということです。

ということは、器具を交換しても「閉じ込めが発生する可能性は残る」ということです。

このような事故(最悪、閉じ込めによる死亡事故(餓死))はなかったのかと尋ねたのですが、まだ、聞いたことがないそうです。

業者さんに対策を聞いたら、「トイレに、スマホを持って入る習慣を付けるしかない」とのことでした。

以上より ――

江端家では、このプラスチックカードを、閉じ込められる可能性のある全てのドアノブに設置しました(全部で5箇所)。

図面をクリックすると記事に飛びます。