エンジニア的なネタを毎週書くブログ

東京でWebサービスの開発をしています 【英語版やってみました】http://taichiw-e.hatenablog.com/

Windowsでsshしてターミナル作業してるときに「テロン」「テロン」ってうるさい音を消す

基本的にオフィスではPCの音は全消ししてたので、いままでは気にしてなかったのですが、
世の中はすっかり在宅勤務時代。

同僚の方とZoomなどでつないで、時にはサーバに入って作業している状況をシェアすることも増えました。
そのときに… tabキーで補完をするたびに「テロン♪」「テロン♪」 ってうるさーーーーい!!


ググってもググっても ぴったりなものが見つからなかったのですが*1……


やっと見つけました!
infotech.hateblo.jp

「一般の警告音」をオフにすることによって、止められました-!

*1:Bash on Windowsでビープ音を消す というのは見つかるのだが、これで止められるのはローカルでターミナル作業しているときだけで、サーバ上だとダメポ

SRE Lounge #12 に参加しました!

やったこと

こちらに参加しました!
sre-lounge.connpass.com

今回は、オンライン参加でハードルが低かったこともあり、運用に近いところをやってくれている、これからやろうとしてくれているメンバー2人を誘って一緒に参加しました。
セッション中は、Twitterでワーワーいうのもやってたんですが、同時に、社内のMS Teamsで、セッションの内容を自分たちの事例に置き換えながら雑談する、というのも並行してやってました。

分かったこと

  • NewRelicのブログすごい。ボリュームが凄くて読みきれないけど、リンクとして残しておきたい…のでメモ。

あとは要所要所「なるほど!」とか「そうだよね!」ってのがあったのですが、twitter.com
自分が門外漢だからなのかな、いまいち消化しきれませんでした。

それよりも、途中途中、
自分たちの部署の事例に置き換えながら、3人で雑談してたのがなかなか楽しかったです。
「この3人で話すのか」っていう、ちょっとレアな組み合わせだったのもあって新鮮でした。

部署内のパブリックなチャネル*1で会話していたので、このやりとりが、誰かの目には止まってたかも。

次にやること

常々、みんながもっともっと自主的に勉強するエンジニアを組織を作りたい、勉強会とかバンバン行ってほしい…と思いつつ、
自身が背中を見せられていない不言不実行状態が続いておりました。
そういった意味で、今日はとても楽しい時間でした。
特に都内はまだまだオンラインでの勉強会が続くかな…?と思いますので、
積極的に周りのメンバーを誘って、また他の勉強会に参加し、部署内に雰囲気を作っていきたいと思います。

*1:勉強会などについて語る専用のチャネルです

守備には3種類あると思った

今、自分の中では世紀の発見をしたくらいのキモチになってまして、忘れないように書きとめておこうと思います。
多分後で読み返したら「なにを当たり前のことを言ってるんだ」って感じだと思うんですけど。

その昔書いたこの記事のように、サッカーだったり剣道だったり、時々野球だったりをイメージしてるんですが、団体競技でも個人競技でも何かしら攻防のある、お好みのスポーツをイメージしてもらえれば意味は通じる…と思います。多分。
ログイン - はてな(仕事の話です)剣道とサッカーと交渉ごとって似ていると思うんですよ - エンジニア的なネタを毎週書くブログ

さて、その上でタイトルに書いたとおり、「守備には3種類ある」のだと思い至りました。
1. 相手の攻撃を止める守備
2. 相手の攻撃を止めた上で攻撃に転じる守備
3. 相手をコントロールし、相手の攻撃の幅を狭めることによって行う守備

1. 相手の攻撃を止める守備

サッカーであればとりあえずシュートを止めるとか。自陣内で相手からボールを奪うとか。
剣道であれば打ってきた面をとりあえず竹刀で受けるとか。
相手がポイントを取ろうとしてきた攻撃をなにかの方法で防いで、失点を0にする、最も直接的な守備です。

2. 相手の攻撃を止めた上で攻撃に転じる守備

1.で相手の攻撃を止めた上で、その機を逃さずに攻撃に転じることです。狭義では「守備」ではないかもしれませんが、
相手に攻撃を仕掛ける → 相手が守りに転じる → 相手の攻撃の機会を奪う
となり、結果的に相手に攻撃させない、広義での「守備」となります。
スポーツで言えばカウンターが相当すると思います。

3. 相手をコントロールし、相手の攻撃の幅を狭めることによって行う守備

1.は相手の攻撃に対して応じた動き、2.はそこで終わらずにそこから攻撃に転じることによって相手の攻撃機会を減らすアクションでした。
3.は、よりこちらから働きかけていく守備です。
右サイドを固めておくことで左側へ誘導する…といったことです。

システムの「運用」も同じ!

ここまで、一体何の話が始まったんだ!? という内容をお送りしてまいりました。
システムの開発/運用における「守備」とも言える運用においても、同様に3つの守備 が定義できると思います。

1. 相手の攻撃を止める守備

とにかく被害を出さないアクションです。
トラブルが発生しているのであれば復旧する、バグがあるなら直してリリースする、期日までに終えないとサービスに問題がある作業があるのであれば終える。
などです。
流通など、実際のサービスへの影響が起きない、または置きても小さくて済めば成功と言えると思います。

2. 相手の攻撃を止めた上で攻撃に転じる守備

1.で被害を出さなかった上で、1で起こるような問題の原因を潰しに行くようなアクションがこちらです。
手順がまとまっていないオペレーションが原因でトラブルが起きやすいので再発防止のために手順書をちゃんと書く とか
SQLに不慣れなメンバーが多くてバグが多いのでSQLを勉強してもらう とか
何か能動的なアクションを起こすことによって、これまで発生している問題を潰しに行くのが2です。
一見、次の3.のようにも感じますが、
何か悪いコトがまず起こり、発生した問題に対応するなにか施策を行う
というアクションですので、2.です。

3. 相手をコントロールし、相手の攻撃の幅を狭めることによって行う守備

では3.は何かというと、そもそもまだ発生していない問題を察知し、先に潰しに行く というアクションです。
例えば、

  • トラフィック増に伴って検索処理の性能劣化が見られるので、システム増強しておくことでトラブルを未然に防ぐ

など、まだ問題の形にすらなっていない種を発見し、潰しにかかるのがこちらです。

Windows10にOracleをインストールしようとしたらありがちな罠にハマった

Oracle18cのWindows用のZipを落としてきて、解答して、
setup.exe
を管理者権限で実行するんだけど、一瞬だけウインドウが表示されたあと、すぐに消えてしまう現象が発生。

ググると同じお悩みの人は多い。
質問サイトを読んでいると…

"Remove all the spaces in the name of directory"
community.oracle.com

ビンゴ! "Program Files" の下でやろうとしてたのが原因でした。
ありがち。
https://community.oracle.com/thread/4175173

f:id:taichiw:20200209125846p:plain
※ダウンロードも時間かかったけど、セットアップがまた長い…

古いプログラムからも学ぶことがある…と思う。

機会がありまして、宮大工・西岡常一さんの聞き書き、「木のいのち木のこころ」を読んでいます。

宮大工として過去の建造物の解体修理をしていると、過去の職人の仕事が見えてくるそうです。
建築から1300年以上経ってもなお現存する、法隆寺の建築仕事の素晴らしさ。
一方、そこから時代が下った、室町や江戸時代に建てられた寺社を見ると、便利な道具が発明されたことや、華美な装飾やコストカット、早い完成が求められたことなどを背景に質が悪化している、ということが見えるそうです。


そんな文章を読んでいるうち、まったくもって1300年という歴史はありませんが、「古いプログラム」に思いを馳せてみるのもいいかなぁと思いました。
…ということで、「『10年くらい前のソースを読んでうわって思った』5年くらい前の私」の話です。


当時私が担当していたアプリケーションの一部に、「Java1.4以前に書かれたんだなぁ」というソースコードが残っていました。
現在のビルド環境、動作環境は最新のJDKが使われていますが、ソースの書き方が「ジェネリクスがなかった時代」の書き方なんですね。

特に当時衝撃だったのが、
・クラスやメソッド名に意味がない。abb101, abb102, みたいなメソッド名が並んでる
・メソッドでコレクションを引数として受け取る場合は、配列。ListやMapを引数に取らない
の二点でした。

当時は、「何この古臭い書き方…」「理解できない」「ク○コード」くらいにしか思っていませんでした。しかし、改めて思い返してみると、今でも通用する設計上重要なエッセンスが含まれてるんです。


クラス名やメソッド名が読めない、意味不明なものである、ということは、別でこれらの一覧を定義した仕様書があった*1ということです。
仕様書があろうがなかろうが、読める名前にしたほうがいいのは間違いありません。
しかし、きちんと初めにメソッドを定義してからコーディングに入るという考え方自体は、TDDなどにも見られるように今も重要な考え方だと思います。


一方、引数を配列で取る、というのは当時のJavaの言語仕様の範囲内でなるべく問題を起こさないためのテクニックだったようです。キャリアの長い先輩エンジニアから以前、教えていただきました。
Java5でジェネリクスが導入される以前のJavaでは、ListやMapなどのコレクションの要素の「型(クラス)」を明示的に宣言する方法がありませんでした。
そのため、コレクションへの要素の追加時と要素の取り出し時で異なるクラスを使ってもコンパイルエラーにはならず、実行時に例外が投げられたり、予測しない挙動をする、という危険がありました。
これを防ぐため、メソッド間でコレクションを引き渡す場合、型の定義が可能な配列にあえて変換して引き渡すことで実行時エラーを回避する、というテクニックがあったそうです。

今の時代に置き換えますと、さすがにJavaのメソッド呼び出しでこういう事は起きないと思うのですが、Web APIの呼び出しで見られるような話ですね。
最近(…とは言え数年前か)は、RESTでは型が定義しづらいからgRPCなどのRPCを使って、プログラム内で型定義をする という話もあるようです。


プログラム言語やフレームワークはどんどん進歩していますが、保守性が高い、読みやすいコードの要素というのは昔から変わっていないと思います。
ときには「ふっっっるい」ソースコードを読んで、当時の人の考えに思いを馳せてみるのもおもしろいかもしれません。

*1:どこかには現存しているのかもしれませんが、私は在処を知りません

自組織内でアドベントカレンダーやってみました

今の自部署が7月にできて半年弱。
当時、新しいプロダクトに不慣れだった各メンバーも、随分と慣れてきました。

…ということで、ちょうど12月だし、お互いここ半年で学んだことを共有しあってみようぜ! ということでアドベントカレンダーを部署内でやってみました。
f:id:taichiw:20191202202834p:plain
誰も乗ってくれなかったらどうしよう… と思ったのですが、埋まりきってはいないものの、とりあえずライターがそこそこ集まってくれて、ホッと胸をなでおろしているところです。
(さすがにいきなり始めると本当に誰も来てくれない恐れがあったので、事前に角度高そうなメンバーに興味あるかどうかは聞いてました…が、それ以外の人達も集まってきてくれて嬉しい限り!)

直近、今週の金曜日が埋まってないので誰か引きずり込まないとなー!