コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

Excelやスプレッドシートで関数エラーかどうかを判断するためのIFERROR

この関数のおかげでだいぶ便利になったよね的なメモ

Excel側のドキュメント

IFERROR 関数を使用して、数式のエラーをトラップし、処理することができます。 IFERROR は、数式がエラーと評価された場合に指定した値を返します。それ以外の場合は、数式の結果が返されます。 - IFERROR 関数 - Office サポート

何が便利か

例えば、A1の値をB1で割るようなケースがあったときに、A2が0や空セルだと計算が成り立たたず #DIV/0!

f:id:shinkufencer:20190903000914p:plain
割り切れないエラー

このような場合に IFERROR で囲んで、第一引数にエラーになる可能性のある式、第二引数にエラーになってしまった場合に出したい値を設定するとキレイに見せることができる

f:id:shinkufencer:20190903000941p:plain
エラーになるので、第二引数の値が表示されている

なおエラーに当たるかどうかは以下の定義

数式がエラー値と評価された場合に返す値を指定します。 次のエラーの種類はが評価されます: #N/A、#VALUE!、#REF!、#DIV/0!、#NUM!、#NAME?、#NULL!。

関連リンク

『builderscon tokyo 2019』の二日目に行ってきたよメモ

builderscon tokyo 2019 の二日目に行ってきたよメモです。一日目のメモはこちら

各発表の感想

※資料スライドは見つけたら貼ります。


OSS Security the hard way

感想

  • オープンソースという会社が提供するサービスとは違うものに対するセキュリティの考え方の話
  • Rubyレベルの大きなオープンソースにおいては影響も大きいし、周知範囲も難しいので、その点における大変な話を聞けてよかった
  • 「CVEが出たからと言ってすべてがすべて慌てる脆弱性ではない」「パスワードを使いまわしてはダメ」など自分の日頃の襟を正さねば…という話があった

関連リンク


JPQRによって変わる日本のQRコード決済

スライドリンクは見つけたら貼ります

感想

  • 一般的なキャッシュレス決済からQRコードの話、そしてQRコード決済の規格であるJPQRの話へ
  • 誤り訂正やカメラの位置関係を示す情報が結構な免責締めているんだな…と思いつつも情報量はそこそこあるという、デンソーウェーブの技術力。
  • Japan独自のものかと思いきや、ICカードの国際規格であるEMVQRコード仕様の拡張となっており、ちょっと安心感があった。
  • QRコード決済の仕組みがなんとなく分かれるいいセッションでした。

関連リンク


形式手法による分散システムの検証

感想

  • TLA+を使った形式手法の考え方の説明
  • TLA+はなかなかに書き方を身につけるのにスキルセットが必要そうだけど、考え方自体は普通に横展開可能な感じがした。
  • 分散システムで語られる「嘘をついたらどうするか?」みたいな話に関しても炙り出せるので、分散システムのセオリーとこういう網羅性を確かめるツールを組み合わせるとめちゃくちゃ堅牢なものができそうというワクワク感はあった

関連リンク


入門サービスメッシュ

感想

  • サービスメッシュという言葉がおぼろげに使っていたので、それを改めてインプットするために歴史込みでしれてとてもよかった
  • もともとはアプリのプラグイン形式だったが、そうではなくだんだん切り離して扱うProxyとなり、Proxyがどんどんいろんな機能が乗り…という流れを聞いてなるほどそうやってどんどん膨れて来たんだねという気持ちに
  • 今なんの問題があるからサービスメッシュを使うのか、を考えながら適応していく必要があるし、ただ部分適応も可能という話
  • サイドカーとかやるとどうしてもコンテナを集約する要素が必要になってくるのでその世界観に飛び込むのはちょい知識をならさないと大変そう…

関連リンク


RowLevelSecurityはマルチテナントの銀の弾丸になりうるのか

感想

  • 設計でカバーしよう!となるような話を真っ向から技術でアプローチしたすごいチャレンジングな話
  • 心理的安全性を高めるためにできることを制約してしまうというのはとてもいいアプローチだなと思った。
  • 少ないメンバーながらちゃんとパフォーマンスチェックなどの検証をしっかりやる文化があって見習わねばならないなと思ったり。
  • 実際パフォーマンスには難が出たが、ちゃんと試して期待したものも得られているし、とても貴重な話を聞けた。

関連リンク


時を正しく扱うためのシステム設計

感想

  • 時間の話から期間を扱うときの注意点を語った話
  • 日本という土地にいると「サマータイム」や「同じ国内で違うタイムゾーン」という難敵に合うことがないのが救いだなと話を聞きながら改めて思う
  • 「翌月」のレギュレーションに関して真面目に考えることはなかったけど結構ここらへんはコンテキストによって変わりそうだし、ちゃんと設計しないとダメだなと思った。そういう意味では「25日締め」というのは経験値から練りだされた仕組み感がすごい
  • 途中で法律の話が出てきても正しく対処されていた登壇者さんすげーと思った。(その時は規定されている定義と違うという旨の質問だったが、繰り返しの期間に関しての言及は見当たらないという話だった)

関連リンク

全体を通しての感想

  • LTも含めて最後までとても良いカンファレンスでした。
  • 懇親会とかの感想は1日目分に書いたのですが、2日目は朝ちょっとはやく言って朝ごはんコーナーで朝ごはんを食べてました。下手なビジネスホテルより豪華だった…
  • スタッフの皆さんも参加者のみなさんもすごい動きがよくて「詰めてくださーい」みたいな呼びかけにはちゃんと詰めてくれるし、手際もよくて過ごしやすかったです。
  • 人に話せる面白い常識を蓄えて、来年はCFP出したいな…と思いました。
  • 全体的に泣く泣く見れなかったので録画でみたい…ってのはたくさんあったので録画公開が楽しみ。

『builderscon tokyo 2019』の一日目に行ってきたよメモ

builderscon tokyo 2019 の一日目に行ってきたよメモです

各発表の感想

※資料スライドは見つけたら貼ります。


対戦ゲームに学ぶ、フレームワークの設計技法とAIのアルゴリズム入門

感想

  • qsonaさんのバックグラウンドとそれをベースにした様々なゲームの「考え方」の作り方の話
  • 将棋とかは人工知能で考え方にも使えそうだなという感じ。
  • ゲームのルールを正しく定義していくことで矛盾が見えてくるというのはなるほどという感じ。
  • ゲーム木は人工無能にも使えそう、というかサウンドノベル式のチャットボットとかはこれと同じアプローチで色々簡便に作れるのではと思った
  • フレームワークのSimpleとEasyをこの流れで絡めてくるのはうまいなーと思って聞いてまいsた。

関連リンク


Mathematica崇めよBlank讃えよObject ~Free Wolfram Engineに向けて

スライドは下記ページから見れます

Mathematica崇めよBlank讃えよObject ~Free Wolfram Engineに向けて - builderscon tokyo 2019

感想

  • 計算処理であるMathematicaオブジェクト指向的なアプローチができることを説明していただいた
  • オブジェクト指向言語が兼ね備えている機構とはなんぞや、みたいな話しに触れた感じがある。
  • 全然Mathematica門外漢なので終始へーという感じ
  • 全然別件ですがOOPってウープって読むってことを知る

関連リンク


形式手法を使って、発見しにくいバグを一網打尽にしよう

感想

  • 形式手法に関してのかんたんな説明、そしてそれをプロダクトに導入できそうかという現在進行系のお話。
  • 形式手法、全然知らないので大枠の説明をもらってとっても参考になった。
  • 自然言語からモデリングにあてはめていくとその時点で矛盾に気づくことができるということだったので、自然言語から図表とかに起こすだけでも十分に効果は発揮できるのかもなとか思った…。

関連リンク


Ruby (off|with) the Rails

speakerdeck.com

感想

  • Ruby on Railsの正体と向き合い方からの発展話題として、強力なActiveRecordとそれら周辺の機能を乗りこなすには、ということのアイデアの紹介
  • RailsActiveRecordとDBと密結合、さらにViewとも強くつながっているが故に様々な破滅が発生するので、それに対しての対応策という形の紹介でどれも頭を縦にふるしか無い話題だった。
  • APIだったらFormオブジェクトじゃないからCommandでしょ!っていうのはすごく理解できるんだけど、現場に同じ考えを持ち込むと「commandパターンと勘違いするから…」みたいなことになるのでぐぬぬってなる…。
  • ちゃんと原理原則を理解して、RailsのEasyな部分をわかって戦うにはすごい正しい話。自分もこうしたい!と思いつつも習熟度の違うメンバーをこの認識まで揃えていくのはなかなかに骨が折れそう。
  • おそらく従来からRailsと歩いて来た人たちとは違う切り口のアプローチだと思うし、この道は一つの道としてとても良い話だった。スライドが公開されたら読み直したい

関連リンク


PWAゲームを開発しネイティブアプリ化までした中での課題と対策

感想

  • すべてのコードがクライアントに明らかになってしまう、というJavaScriptでどうやって立ち向かうかの話
  • 完全な隠蔽はできないのでどれだけ複雑にするかに注力している感じだった。そしてとても泥臭い作業であり、大変だなと思わされた…。
  • 画像アセットが価値を持つというビジネスなので、以下にしてビジネス資産を守るかということが大事だが、そこがパフォーマンスも伴ってとなると色々考えることが多いし、それの貴重な経験談を聞けてとてもよかった。

関連リンク


ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ

a-suenami.hatenablog.com

感想

  • アプリケーションの事業側の内容をSoR、それぞれの利用ユーザーをSoEと考え取り組んでいくというアプローチの説明。
  • 欲求はビジネス側とユーザー側で異なるという切り口から攻めるのはなるほどなーとただただうなずくばかり。
  • モデルは問題によって変わる、というのを地図で例えて「地球儀」「メルカトル図法」は解決したい問題が違うから表現が違う、という話でよりいいたとえをもらった。
  • モデルやデータを中心に考えていくとこの考え方はすごくいい考え方だと思っていて、変え難いが割とビジネスの路線が固く決まっているモデルはSoRとして扱うあたりはかなり正しいアプローチだと思えた。
  • 逆に固まっていないものはSoE的なアプローチを踏むべきだということにもつながるのでモデル組成の基準としてはなるほどなと思える部分が多かった。
  • ただ内部の利用ユーザーも別アプリケーションに分けるアプローチをとるとRailsでつくったりするとパッサパサのRailsになっちゃうな…とか思った。SoRにRails使うのはおよしなさいということなのかもしれないが

関連リンク


一日目の感想

  • 一日目は設計について考えさせられるセッションばかり攻めて聞きました。
  • qsonaさんが形式手法的な話とフレームワークに触れ、しんぺいさんのRailsの話、穂高さんの形式手法の話とつながったのでちょっと学びの連鎖みたいなものがあって良かった。
  • 懇親会がすごく豪華でフードもドリンクもとても美味しかったです(諸事情で100%楽しめなかったし、もうちょっといろいろな人と会話すべきだった…反省が活きてないヤツ)
  • 懇親会のケータリングシステム、どんどん補充していくタイプだったので人の流れがいい感じにできててよかった
  • 全体的な感想は2日目分で改めて…。

f:id:shinkufencer:20190901021147j:plain
オリジナルカクテル一覧、空きっ腹で飲んだら、翌日頭がマカレルアラートでした…

ファイルパスをbashでかんたんに取るときは dirname を使うとかんたんに取得できる

$0とあわせての話

環境

$ bash --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18)
Copyright (C) 2007 Free Software Foundation, Inc.

事例

例えば "/hoge/huga/example/text.txt" が渡されたときに "/hoge/huga/example/ を取得したい場合

下記のようにかける

# ファイル名をdemo.shとする
filepath='/hoge/huga/example/text.txt'
echo $(dirname $filepath)
$ sh demo.sh 
/hoge/huga/example

関連リンク

bashを使ってスクリプト内でファイルパスをを知りたい場合は$0を使うと取れる

あー、なるほどと思ったのでメモ

書き方

$0 とするだけ

下記のようなシェル

dirs=$0
echo "$dirs !!!"

を実行するとこんな感じ

$ sh fileout.sh 
fileout.sh !!!

パスを変えたりすると以下の感じ

$ sh hoge/fileout.sh 
hoge/fileout.sh !!!

注意点

あくまでも $0 は 引数のゼロ番目を示すものなので、指定したファイルのパスが出るだけ、絶対パスなどを取る仕組みではないので注意

参考リンク

sidekiqの終わらせ方

公式のwikiより、イマイチ意味が理解できてなかったので再整理も込めて。

出典元

Signals · mperham/sidekiq Wiki · GitHub

止め方

新たなプロセスの受付を止める

TSTP のシグナルを送る

$ ps -ef | grep sidekiq
779199931 22540 18659   0  9:28PM ttys013    0:12.68 sidekiq 5.0.0 hoge_app [0 of 25 busy]
779199931 22657 19356   0  9:28PM ttys014    0:00.00 grep sidekiq

# シグナルを送る
$ kill -TSTP 22540

# プロセスがstoppingになる
$ ps -ef | grep sidekiq
779199931 22540 18659   0  9:28PM ttys013    0:13.78 sidekiq 5.0.0 hoge_app [0 of 25 busy] stopping
779199931 22786 19356   0  9:30PM ttys014    0:00.00 grep sidekiq

sidekiqそのもののプロセスを終了する

TERM のシグナルを送る。

$ kill -TERM 22540
$ ps -ef | grep sidekiq
779199931 22846 19356   0  9:31PM ttys014    0:00.00 grep sidekiq

関連リンク

sidekiq を安全に止める - Qiita

UNIX/Linuxシステムにおけるシグナルとkillコマンドに関してざっくりまとめる

ド基礎を見直そうというたぐいのもの

プロセスとシグナル

Unix/Linuxシステムではプロセスという単位でシステムが動いている。そのプロセスは外からシグナルという形で情報を受け取ることができる

シグナルの使い所

シグナルは他のプロセスから飛んでくるものであり、有る種の信号のようなものである。

シグナルの送り方

一般的にシグナルは kill コマンドを使って送信できる

kill {{ハイフンをつけてシグナル番号、もしくはシグナルの文字列}} {{プロセスID}}

SIGINT のシグナルを 2098 のプロセスに送りたい場合は以下

kill -INT 2098

仮にオプション表記を除くと -TERM を指定した場合と同じ振る舞いになる。

シグナルの一覧

シグナルの一覧は kill -l コマンドで確認ができる

$ kill -l
 1) SIGHUP   2) SIGINT   3) SIGQUIT  4) SIGILL
 5) SIGTRAP  6) SIGABRT  7) SIGEMT   8) SIGFPE
 9) SIGKILL 10) SIGBUS  11) SIGSEGV 12) SIGSYS
13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGURG
17) SIGSTOP 18) SIGTSTP 19) SIGCONT 20) SIGCHLD
21) SIGTTIN 22) SIGTTOU 23) SIGIO   24) SIGXCPU
25) SIGXFSZ 26) SIGVTALRM   27) SIGPROF 28) SIGWINCH
29) SIGINFO 30) SIGUSR1 31) SIGUSR2

この数字、もしくはSIGを覗いた文字列を - でオプション指定すると指定のコールが送られる。

振る舞いに関してはそれぞれで上書きが可能なので、一概にコレがこういう動作であるというのは言えないが基本は同じ意味で扱われる。

killコマンドでよく使われる 9)SIGKILL は意味が変わることは少ない。

参考

Working With Unix Processes (English Edition)

Working With Unix Processes (English Edition)