2024-01-11

DELL U4021QWでthunderbolt経由での入力が認識されない

2年ほどDELL U4021QWを使っている。

画面が広くthunderboltだけで給電と画面出力がされるのでケーブル1本で済みデスクがスッキリしてQoLが高かった。

しかし最近給電はされるが画面出力ができなくなった。

代わりにNo Thunderbolt (90w) signal from your device.と出るだけだった。

自宅にthunderboltに対応した別のDELL製モニターがあったのでU4021QWと同じPC同じケーブルで繋いだところ正常に画面出力された。

U4021QWが悪いことは判明したが修理費用も馬鹿にならなそうだな〜と思いつつ、エラーメッセージで調べたら同じ苦しみを受けてる人がたくさんいることがわかった。

そのうちの一つで解決が出来たので紹介する。

www.dell.com

Turn the U4021QW off

Disconnect every USB peripheral device from the U4021QW

Disconnect every cable (including power cable) from the U4021QW

Press and hold in the U4021QW power button for 8 seconds

Reconnect the power cable to the U4021QW

Reconnect ONLY the Thunderbolt 4/USB-C active cable to the U4021QW

Connect the other end of the Thunderbolt 4/USB-C active cable to the already turned on Laptop

Turn the U4021QW on. What happens?

日本語訳をすると、

U4021QWの電源を落とす
全てのUSBデバイスをU4021QWから外す
全てのケーブル(電源ケーブルを含む)をU4021QWから外す
U4021QWの電源ボタンを8秒間押し続ける
電源ケーブルをU4021QWに繋げる
Thunderbolt 4/USB-CケーブルをU4021QWに繋げる
Thunderbolt 4/USB-Cケーブルに起動済みのPCを繋げる
U4021QWの電源をつける。どうなった？

dell monitor 8 secondsとかで検索するとmonitor resetと出てくるのでおそらく工場出荷状態にリセットしてるんだろう。 (日本語では見つからなかったので確証なし)

同じエラーで苦しんでる人がいたらぜひお試しを。

2023-12-07

いい加減 slack 通知のJSON構造を知りたい(覚えたくない)

slack apiの使い方は大体CIの完了通知をするくらいなのだが、少しリッチにしようと思うと途端に手が止まってしまう。

curl -X POST -d @data.json https://hooks.slack.com/services/xxx/xxx/xxx

このjsonの構造を一生覚えられる気がしないのでリンク集をまとめる

とりあえずjson構造はここを見れば良い。 channelはチャンネル名(IDでなくても)でok

api.slack.com

blocksでさらにおしゃれな通知にしたかったらblock kit builderを利用する

app.slack.com

2018-11-23

あるパスからの相対パスを絶対パスで欲しい場合のやり方を間違っていた話

ruby

TL;DR

File.expand_path(File.join(Rails.root, "./my_config/hogehoge"))
=> "/Users/yoan/dev/src/github.com/myoan/rails_test/my_config/hogehoge"

とずっと書いていましたが、

File.expand_path("./my_config/hogehoge", Rails.root)
=> "/Users/yoan/dev/src/github.com/myoan/rails_test/my_config/hogehoge"

と書くほうがシンプルでした

挙動を調べる

リファレンスによると、

expand_path(path, default_dir = '.') -> String[permalink][rdoc]

(中略)

    [PARAM] path:
        パスを表す文字列を指定します。
    [PARAM] default_dir:
        path が相対パスであれば default_dir を基準に展開されます。

と書かれています。

相対パスなので第一引数のパスに対する比較対象が必要で、第二引数がその対象になります。そして、第二引数が省略された場合は今いるパスが対象になります。

したがって、

File.expand_path("../hoge")は今いるパスから"../hoge"移動した絶対パスを返す
File.expand_path("../hoge", "/tmp")は/tmpから"../hoge"移動した絶対パスを返す
- つまり /hoge
File.expand_path("./my_config/hogehoge", Rails.root)はRails.rootから"./my_config/hogehoge"移動した絶対パスを返す
- つまり Rails.root/my_config/hogehoge

そもそもの問題

modelにはそのまま相対パスを、rspecにはRails.rootとjoinした形で書いていました

### rb

def my_path
  mkdir_if_not_exist(File.expand_path("../my_config/hogehoge"))
  File.expand_path("../my_config/hogehoge")
end

### spec

describe do
  it { is_expected(my_path).to eq File.expand_path(File.join(Rails.root, '../my_config/hogehoge'))" }
end

テストではディレクトリを作ってほしくないためFakeFSを導入したところエラーが出たところが始まりでした

expected: "/Users/yoan/dev/src/github.com/rails-test/my_config/hogehoge"
     got: "/my_conofig/hogehoge"

FakeFS.expand_pathを調べたところ

def self.expand_path(file_name, dir_string = FileSystem.current_dir.to_s)
  RealFile.expand_path(file_name, RealFile.expand_path(dir_string, Dir.pwd))
end

となっており、第二引数に"/"が渡されていました

つまりルートディレクトリからの絶対パスを返していたため、gotの結果が帰ってきたというわけでした。

参考

http://maeharin.hatenablog.com/entry/20130104/p1

2018-07-29

サーキュレーターを購入した話

あらまし

新居に引っ越しはじめての夏

1LDKでリビングにエアコンがあり、作業部屋を兼ねた寝室にはエアコンがありません

帰宅後すぐにエアコンをフル稼働して一気に寝室まで冷ましたいのですが、嫁がリビングにいるときは叶いません

結果、自分が汗だくになりながら作業することが多く、快適な作業環境とは言い難いです

リビングの冷気を効率的に寝室に送り込むためにサーキュレーターを買ってみることにしました

サーキュレーターとは

そもそも扇風機との違いがわからず、改めてまとめてみました

扇風機
- 目的
  - 人に風を直接当てること
- 特徴
  - 静音性が高い
  - 風量は少なめ
  - 風は広がりやすい
  - 首振り・タイマーなどの風を当て続けない機能
サーキュレーター
- 目的
  - 室内の空気を循環させること
- 特徴
  - 風量が多い
  - 風をまっすぐ届ける
  - ものにもよるが
    - 首振り・タイマーがない
    - 静音性が低い

自分の要望

続いて自分の環境や要望をまとめます

爆音で音楽流れていても寝れる人間なので静音性はそこまで高くなくても良いです

ですが、かなりの汗っかきのため、風量は十分あってほしいと考えました

環境
- 1LDK 20畳
- リビング12畳 + 寝室8畳
要望(上に行くほど重要)
- リビングの冷たい空気を寝室に運びたい
  - 暑がりですぐに涼しくしてほしいのでパワーは十分なものがいいです
- Nature Remoでエアコンと同時に起動させたい
  - 最寄り駅についたらエアコンを点けるよう設定しているのですが、合わせてサーキュレーターも点いて欲しいです
  - そのため、リモコンが付随しているものがいいです
- 手入れがしやすい(嫁が)
- 静かである

条件に合うサーキュレーター

アイリスオーヤマ・アイ 18畳

https://www.irisplaza.co.jp/index.php?KB=SHOSAI&SID=H273516Fwww.irisplaza.co.jp

価格: 8,542円

良い

安い
工具無しでカバーが取り外せる

悪い

18畳が不安
可動域が少ない
- 左右: -45° ~ 45°
- 上下: 0° ~ 75°
人気商品で発送が遅れている模様
- (後述しますが2017/07/28現在、amazonからは遅延なく買えるようです)

balmuda・GreenFan Cirq

www.balmuda.com

価格: 19,200円

良い

工具無しでカバーが取り外せる
デザインがかっこいい
ブランド

悪い

風量の強弱が4段階しかない

vornado・6303DC-JP

https://vornado.jp/products_item/6303DC-JP_5303DC-JPvornado.jp 価格: 25,289円

良い

100段階の強弱
ブランド
首を振らず、風を室内に循環させるという説明がわかりやすかった

悪い

カバーを外すのにネジが必要
値段
- 25,289円

購入したもの

vornadeと非常に悩みましたが、balmudaのGreenFanCirqにしました

理由としては、

強弱は多少荒くてもよい
手入れがしやすい
デザインが良い
早く届いてほしい

となります。

結果として、最近は暑さも収まってきましたのでアイリスオーヤマを待っても良いかと思いました

さらにこのブログを書いている途中、アイリスオーヤマ・アイのamazonを見たところ3日以内に届くとのことでした。。 (自分はアイリスオーヤマのページしか見ておりませんでした)

学び: 製品ページだけでなく、amazon等もみて比較・検討する

おまけ

サーキュレーター以外に検討したこと

エアコンを買う
- 高い
- 大家への連絡や工事もあり大事になる
シーリングファン
- おしゃれ
- 天井の剛性があるか調べる必要がある
- 大家への連絡が必須
扇風機
- 親しみもあるし、安いので検討していた
- 嫁がエアコンをあまり使いたがらない
- が、あの酷暑でエアコンを使う条約を締結。サーキュレーターに移った

パナソニック・創風機Q

panasonic.jp

リモコンがないので候補から外したんだけど、気になった機能が「1/f ゆらぎ」という機能

信州の蓼科高原に吹く風を計測し、風速や強弱のリズムなど緻密なデータを採取・分析、長時間当たっても心地の良い風を実現

子供の頃よく茅野で遊んでいた人間としては一度体感してみたいw

2014-09-09

既存のシステムに新しいものを追加する時のプラクティス

既存のシステムがあり、そこになにかしらを追加する場合にどういった対処が良いのかという事に関して。正直、結論は当たり前の事なので、初心者のメモ帳と思ってください。

結論

インターフェースは変更しない(利用者に変更があったことを意識させない)
代わりにモデルやスキーマを変更する

あらまし

社内で運用しているシステムに対して、新しいツールを作成することになった。

しかし、今までも似たようなデータを取っており、その資産も利用したい。

今までの利用者は今までのもの、もしくはlogin時にupdateして利用する。

これから利用する人は新しいものを利用する。

最初にこのツールを利用するのが、今までのデータだけが対象だったため、私はツールに2つのインターフェースを用意しようと考えていた。

./do_something --use_old_data
./do_something --use_new_data

イメージとしてはこんな感じ。

だけど、この場合修正が多く、運用する上で適さないことを実感した。

というのも以下の点が途中から浮かんだから。

ほとんどのユーザの移行が終了したら、--user_old_dataは利用しない
- ツールの追加作業の後、オプションの削除作業を行わなければならない
- そのときに自分の書いたコードを安全にかつ確実に素早く削除できるかわからなかった(経験上、1日はかかると感じた)
このツールを利用する人は内部のデータ構造をよく知らない
- オプションの違いを利用者に理解させる必要がある(私が周知を徹底させる必要がある)

内部データを知ってるから2つのオプションが存在する事もわかるけど、利用者はそんなんわからないし、半年後、一年後の自分がそれを思い出すまでにどれくらいかかるか、と考えるとこのまま進めたくはなかった。

そこで考えたのが、

新しいスキーマを作成する
既存のスキーマから新しいものに移行するスクリプトを作る
新しいシステムでは新しいスキーマしか利用しない

という方法。これの利点は、

移行スクリプトは1度走らせるだけなので、運用する必要がない
オプションは必要ない(インターフェースがはっきりする)
ツールに最適化された情報がスキーマにあるので、探索が楽(速度向上)

などが期待できること。

書けば書くほど、単純な結論でしたw

2014-08-10

ubuntuでrbenvを使ってrubyをインストールする

自分用。特に真新しい事はないです。

もろもろインストール

sudo apt-get update
sudo apt-get install python-software-properties
sudo apt-get -y update
sudo apt-get -y install curl
curl https://raw.githubusercontent.com/fesplugas/rbenv-installer/master/bin/rbenv-installer | bash

.bashrcにrbenvのpathを追加

vi ~/.bashrc
export RBENV_ROOT="${HOME}/.rbenv"
if [ -d "${RBENV_ROOT}" ]; then
  export PATH="${RBENV_ROOT}/bin:${PATH}"
  eval "$(rbenv init -)"
fi

libsslのインストールとかで一旦再起動

source ~/.bashrc
rbenv bootstrap-ubuntu-12-04
sudo shutdown -r now

自分の入れたいrubyのバージョンを入れる

rbenv install 2.1.0-rc1
rbenv rehash
rbenv global 2.1.0-rc1

確認

which ruby # $HOME/.rbenv/shims/rubyになっているか確認
vagrant@laputa:~$ ruby -v # 2.1.0になっているか確認

2014-07-31

LDAPのsudoers, env_keepではまった

あらまし

githubのprivate repositoryをchefから参照したくて、rootユーザにssh-agentの鍵を持たせるようにしようとしたところ、LDAPの設定ではまった。

結論

LDAPのコンフィグパーサでエンバグした模様。

env_keep+="HOGE SSH_AUTH_SOCK"と記述した場合、後ろのダブルクォートも合わせたSSH_AUTH_SOCK"という環境変数として見なされた。

env_keep+="HOGE SSH_AUTH_SOCK "と行末にスペースを入れて解決。

内容

通常、SSH_AUTH_SOCKがrootでも参照出来ない場合は以下のような結果になる。

(なお、macではなぜか参照できる)

$ sh -c 'ssh-add -l'
2048 11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11 /Users/yoan/.ssh/id_rsa (RSA)
$ sudo sh -c 'ssh-add -l'
Could not open a connection to your authentication agent.

まず、LDAPでenv_keepが使える事から以下の用に記述した。

Defaults env_keep+="LC_ALL LC_TIME SSH_AUTH_SOCK"

この状態でssh-addを行って、rootでも参照出来る事を期待したけどうまく行かなかった。

$sudo sudo -V
...
正当性の確認を行う環境変数:
    TERM"
    LINGUAS
    LC_*
    LANGUAGE
    LANG
    COLORTERM
削除する環境変数:
    RUBYOPT
    RUBYLIB
...
    "IFS
保護する環境変数:
    SSH_AUTH_SOCK"
    LC_ALL
    LC_TIME
...
        "COLORS

env_keepがダブルクォートの中でスペースを区切り文字にして複数の環境変数を指定できることから、SSH_AUTH_SOCK"と"COLORSのダブルクォートは保護する環境変数郡を1つの配列にまとめて、後ろから表示していると予想。

なお、/etc/sudoresではこれで正常に動作する。

色々試してみると、LC_ALLは確かに参照できる。

Defaults env_keep+="LC_ALL LC_TIME HOGE SSH_AUTH_SOCK"

と環境変数HOGEを追加して試してみると、HOGEは参照されるが、SSH_AUTH_SOCKは参照できない。

もしかして、と順番を入れ替える。

Defaults env_keep+="LC_ALL LC_TIME SSH_AUTH_SOCK HOGE"

すると見事に参照された。

$ sh -c 'ssh-add -l'
2048 11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11 /Users/yoan/.ssh/id_rsa (RSA)
$ sudo sh -c 'ssh-add -l'
2048 11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11 /Users/yoan/.ssh/id_rsa (RSA)

このとき、sudo sudo -Vの結果のSSH_AUTH_SOCK"が(末尾のダブルクォートを含め)そのまま1つの環境変数として認識されているのだと判明。

Defaults env_keep+="LC_ALL LC_TIME SSH_AUTH_SOCK "

とSSH_AUTH_SOCKの後ろにスペースを入れてみると、

$sudo sudo -V
...
保護する環境変数:
        "
    SSH_AUTH_SOCK
    LC_ALL
    LC_TIME
...
        "COLORS

と表記が変わり、SSH_AUTH_SOCKが無事にrootでも参照された。

まとめ

LDAPのコンフィグにはバグがあり、環境変数の保護が出来ない場合がある
- そんなときは、行末にスペースをいれる
rootの状態でsudo -Vをすると参照できる環境変数一覧が見えるってことも初めて知った
sudo -llはenv_keep+=という形で閲覧できるので、このオプションも便利

蛇足

坂の上の雲をやっと読み終わりました。

次は何にしようか考え中。