memo.

カテゴリー: Diary

  • TimeRexを試してみた

    企業ユーザ向けの「調整さん」のTimeRexを試してみた。Freeプランで試しているので、検証していないものもあり。

    https://timerex.net/

    使い始める前に簡単に権限まわりや運営を調べてみた。

    • Googleアカウントでログインし、Googleカレンダーの連携が必要。または、Microsoftアカウントでログイン。カレンダー連携のため。
    • カレンダーに対する権限が強く、アプリ上からは連携していないカレンダーの予定も参照できる権限になっている。
    • 運営会社は、リクルートからのスピンオフして作られたベンチャー。ISMS認証は取得している（https://isms.jp/lst/ind/CR_IS_x0020_733830.html）

    Googleカレンダーへのアクセス権限が強力なのが気になるが、実際に使ってみると・・・

    • スケジュール調整用のカレンダーを別に作成して、連携させると、そのカレンダーに入っていない予定の場所は、すべて空きとして、表示される。
    • スケジュール調整用のURLには、アクセス制限なし。ずっと公開される。1回だけの予定調整用のURLも作れるが、ベースのURLは公開されたまま。ここはちょっと怖い。
    • Freeプランだと、1対多の調整はできない。1対1のみ。
    • 視覚的には、スケジュール表示のため、わかりやすい。「調整さん」に比べれば。
    • 予定がウェブ上から入力されると、通知あり。
    • 予定が入ると、設定画面で指定したカレンダーに予定が自動的に入れられる。このときの予定を入力したユーザは自分になる（これもあり、権限強めなのかも）。
    • 予定がキャンセルされても通知あり。カレンダー上の予定も消える。
    • TimeRex上で、日程調整カレンダーのカレンダーは、用途毎か月毎のように小さい単位にして、使い終わったものは消すのがよい。そうしないと日程調整カレンダーが同じURLで表示され続けるため。

    気が付いたところは、こんな感じだ。3人以上の調整には有料プランが必要。ビジネス用途として、ちゃんと調整するには有料プランにする必要あり。1対1の調整が多ければ、フリープランでも困らないのかもしれないが。

    「調整さん」との比較だと、TimeRexの方がインターフェースもイマドキでよい。同じ使い方をしようと思うと、有料プランが必要なので、簡単な予定調整ならば、「調整さん」だろう。

  • 2022年のヨドバシの福袋　SimフリーiPhoneの夢

    珍しくというか、初めてヨドバシカメラの福袋が当たった。悩んだ末、当たったSimフリーiPhoneの夢を購入した。

    福袋の中身は、iPhone12 Pro 128GBモデルのパシフィックブルー。13 Proが出たので、12 Proは販売終息のモデルだ。Proなので、写真やらなんやらとストレージを使うモデルなのに、128GBはサイズとして小さい。オプションのようなアクセサリーもない。iPhoneだけだ。256GBがよかった。2022年のヨドバシの福袋はハズレだ。昔はもっとよいものが入っていたような気がする。

  • 2021年の仕事納め

    感覚的には2021年はとても早く過ぎていった気がする。2021年の仕事納めが終わった。

    思い返してみると、いろいろとあった。感覚的には、2020年の延長という感じで、2021年という感じがしなかった。たぶん、オリンピックをやっていた所為なのだろう。仕事も波乱万丈だった。去年の今頃では、想像もしていなかったことが多かった。いいことというよりも、辛い一年だった気がする。いろいろと引きずっているので、来年も余波で、そこそこひどいことにはなるだろうけど、今年のようなことにはならないだろう。

    来年は、いい一年で、いい仕事ができる環境であってほしいものだ。

  • Google WorkspaceのGoogle Driveの不適切コンテンツの検査が開始された

    Googleが企業向けGoogle WorkspaceのGoogle Drive上（共有ドライブも）にあるコンテンツのポリシー監査を行い、不適切コンテンツが制限される

    https://workspaceupdates-ja.googleblog.com/2021/12/google_21.html

    これにより、制限が適用されたファイルの名前の横にはフラグが表示され、共有ができなくなるほか、一般公開（共有）も停止されるようなった。一般公開（共有）が停止されると、リンクを知っているユーザーもそのファイルにアクセスできなくなる。この状態になったファイルのオーナーには、違反の詳細と、審査をリクエストする方法が記載されたメールが届く。不適切コンテンツではない場合は、審査のリクエストを行って、ファイルの回復処理が必要とのこと。

    Googleのポリシーを見ると、Google Drive上にあるファイルで、下記のようなものが対象になる。（https://support.google.com/docs/answer/148505）

    • 児童の性的虐待と搾取
    • 危険行為、違法行為
    • ハラスメント、いじめ、脅迫
    • 悪意のある表現
    • なりすましと不実表示
    • マルウェアおよび同様の悪質なコンテンツ

    などなど。

    Googleなので、機械的に検査されていくはずなので、日本語の場合、ヘイト的な内容の解釈によっては検査にかかる可能性は否定できない。

    この手の規制は、コンテンツプロバイダの仕事なのでやることはわかるのだが、公開されているウェブの書き込み内容でもなく、企業向けのストレージも対象なのは恐ろしい。クラウドサービス（クラウドストレージ）を利用する以上は、諦めて従うしかないのだが。そのうち、オンプレミス回帰や重要なデータは、オフラインで手渡しのような形に戻るのではないかと考えてしまう。

  • 鴨川シーワールドにいってきた

    先々週末に、数年ぶりに鴨川シーワールドにいってきた。

    ずっと行こうとは思っていたもののCOVID-19下で入場制限されていたり、休んでいたり、不要不急の外出自粛だったりと、行きにくい状態だった。オミクロン型が入ってくる前にいけてよかった。

    鴨川シーワールドは激混みではないけれど、人はいっぱいいた。ショーが主体なので、どうしても、混雑しやすい。子供が飽きるというのもあって、ちゃんとショーをみれたのはイルカショーだけだった。シャチのショーは見れなかったけれど、練習中のシャチのジャンプだったり泳ぎはゆったりと見ることができた。

    本当に久しぶりにいったけれど、楽しかった。シャチが見れるところは少ないので、シーワールドが生き残ってくれて本当によかった。

  • 迷惑メール確定

    “rain_dream_5654@docomo.ne.jp”という連絡先に登録されていないところから、SMSが届いた。とても怪しいので、名乗ってくるまで放置したところ、同じような時間帯にメールがくる。それで、検索エンジンで調べてみたところ、同じメールアドレスからメールを受けている人が多数いた。よほど、同級生が多いフィッシングアカウントのようだ。

    日付をみると、去年くらいから出回っているようで。それから、季節性のものっぽい印象を受けた。年末のこの手のものがきそうな時期を狙っているようだ。

  • 暴風雨の音がうるさくて寝不足

    昨夜の暴風雨がすごくて、特に風のうなる音がうるさくて、寝不足。荒れた天気だったので、早めに寝たのだが、夜中に風の音と揺れで起きてしまった。とりあえず、何もなかったが、自然の力には驚かされた夜だった。

  • お名前.comのVPSメンテナンスにハメられた話

    お名前.comのVPSを利用しているのだが、ここ数ヶ月でメンテナンスが多発している。VPSの基盤を入れ替えているためのようだが、このメンテナンスがなかなかひどい。

    最初のメンテナンスで、平日の日中に長時間の停止が発生した。そのあとは、VPSに接続できなかったりすることが多発していた。とても、パフォーマンスが悪く、ひどい有様だった。

    そして昨日に行われた緊急メンテナンスも、ひどかった。当然のように日中に行われているし、停止時間は30分で再起動が発生するという告知はあった。サーバとの疎通が切れてから、数時間がたっても、疎通がとれない。メンテナンス時間の間なので、待つしかない。メンテナンスの終わりの時間になっても、VPSとの疎通はとれず。管理コンソールから確認すると、OSは起動していた。だが、ネットワークに繋がっていない状態だった。それで確認すると、DHCPでアドレスが取れない場合があるとのこと。とりあえず、OSを再起動したが状況は変わらなかった。

    １つ１つ、OSの状況を確認していくと、ネットワークインターフェース（NIC）の認識されている名前が変わっていることを発見した。そんなことは、通知には書いていなかった。NICが変わっているので、ネットワークの設定が有効にならず、ネットワークから切り離されていた。VPSの管理画面をみても、NICのことは書かれていない。仕方無いので、NICのem0を消して、ifconfigで表示されたvtnet3に対して、割り振られているIPアドレスの設定をした。これで、VPSがネットワークに接続できるようになった。

    結局、ダウンタイムは6時間以上になった。メンテナンスにしても、サーバOSを扱っているわけで、このメンテナンスはひどい。お名前.comのVPSは品質悪い。別のVPSに乗り換えることも検討しないといけないと感じた。

  • Log4Jの脆弱性はNHKニュースでも取り上げられたのね。

    Log4Jの脆弱性（Log4Shell）は、NHKニュースのおはよう日本で取り上げられたようだ。

    https://www3.nhk.or.jp/news/html/20211214/k10013387051000.html

    これをみて、慌てて指示を出す会社の上層部とか多そうだ。日頃は関心のない層がみることで、いい方向で変わるといいのだけど。逆に現場をせめて、愛想つかされて、技術者が退職するというパターンもありえそうだが。

  • 新しくインストールしたUbuntuでNginxが起動しない

    新しくUbuntuをインストールして、NginxやPHPをインストールした。Nginxを起動させようとしたところ、エラーで起動せず。

    zen@dev:/etc/nginx/sites-available$ sudo service nginx start
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xe" for details.
zen@dev:/etc/nginx/sites-available$
zen@dev:/etc/nginx/sites-available$ sudo systemctl status nginx.service
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset:>
     Active: failed (Result: exit-code) since Wed 2021-11-17 16:13:11 JST; 2min>
       Docs: man:nginx(8)
    Process: 294747 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_pro>
    Process: 294758 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; >
Nov 17 16:13:08 dev systemd[1]: Starting A high performance web serve>
Nov 17 16:13:08 dev nginx[294758]: nginx: [emerg] bind() to 0.0.0.0:8>
Nov 17 16:13:09 dev nginx[294758]: nginx: [emerg] bind() to 0.0.0.0:8>
Nov 17 16:13:09 dev nginx[294758]: nginx: [emerg] bind() to 0.0.0.0:8>
Nov 17 16:13:10 dev nginx[294758]: nginx: [emerg] bind() to 0.0.0.0:8>
Nov 17 16:13:10 dev nginx[294758]: nginx: [emerg] bind() to 0.0.0.0:8>
Nov 17 16:13:11 dev nginx[294758]: nginx: [emerg] still could not bin>
Nov 17 16:13:11 dev systemd[1]: nginx.service: Control process exited>
Nov 17 16:13:11 dev systemd[1]: nginx.service: Failed with result 'ex>
Nov 17 16:13:11 dev systemd[1]: Failed to start A high performance we>
zen@dev:/etc/nginx/sites-available$

    エラーを見ると、ポートのバインドに失敗している。もしやと思って調べると、Apacheがいて、ポート80で起動していた。Apacheを終了させると、無事にNginxを起動させることができた。

    aptでいろいろとインストールしていると、いつのまにかapache がいて邪魔をする。初歩的なミスだけど、よくやらかす。