2019年3月アーカイブ

Amazonアフィリンク

The DevOpsハンドブックと同系の本、あっちが入門書的で、こっちが実践的な内容になっている。内容があまりに似てるんで、内容や感想は今回はパスして、印象に残った文を並べておくだけにしとく。

ページ9「1.5 ジェニファーのストーリー」より、「私の頑張りが、かえってシステムにあった欠陥を隠していたのだ。」
特定の人に依存しすぎてしる場合への対処法の1つですね、何がボトルネックなのかとそれへの対処能力を実際に担当者を長期休暇させて判断するの。まぁ一歩間違えればそのまま会社倒産ですが。

ページ20「3.4 ネットワークの時代」より、「システムの複雑化にともない、スキルや職種の専門文化が進んだ。」「このような流れは、企業版のバベルの塔を生み出した。」
情報を企業の外へ漏らさないようにする流れの行き着いた先として、情報を特定のチームから外へ出さないようにする圧力がかかる流れ、ですね。もしくは特殊技術にこだわりすぎて専門性が強い割にメンテコストがかかりすぎてペイできなくなっちゃう、など。

ページ23「3.6 アプリケーションとウェブの時代」より、「システムの安定性をリスクに晒すようなこともあった。」「システム変更は極度にリスクが高いという見方が強くなっていた。」
技術的負債の話とか、作り直しが発生しないから技術伝承が行われないとか、あたりかな。

ページ172「11.3.4 イベント」より、「故障したハードディスクの交換を担当者に支持するチケットの作成」
チケットベースでバグをトラッキングする話はさすがに馴染みがあるけど、ボットによるチケットの自動更新はあまり身近でなく、ましてや自動作成やら割り振りやらまでとなると、言われりゃわかるんだけど、個人的にはそこまで考えが及んだことがなかった。最近はAIブームの延長でRPAがやたら持ち上げられてるけど、キーボード・マウスのマクロのたぐいのは、自分自身へも含め、もっと啓蒙していかったほうがいいだろうなぁと思った。

ページ182「12.8.2 ツール選択におけるコンウェイの法則」より、「ソフトウェアは、それを開発したチームの構造や組織を反映した形で開発される」
これは本当に実感する。APIを定義する箇所やデータ・バッファの持ち方がまさにこれそのものという事例をよく見てきた。著者はチーム間のコミュニケーション不足だと述べているが、まぁ開発が大規模化する前では簡単な話じゃないなぁと思う。

ページ184「12.9.1 コミュニケーションに影響を与えるツール」より、「チームのメンバーには品質の高いヘッドフォンが行き渡るようにするべきだ。」
これまでにリモートワークやらWeb会議やらの経験がそれなりにあるけど、やっぱり直接会って会議するのに比べると格段の差がやはりある。この手ので事足りるようにするには、ある程度互いに気のしれた相手同士でないと厳しくて、「Web会議だけ」で済ますのは現状はやはり厳しいと思う。直接の対談がある前提で、その上で頻繁なコミュニケーションのために保管的に使うやり方が無難じゃないかな。そのときに高品質の機材の購入に躊躇するようでは問題外。YAMAHAのYVC-300はメジャーだけど、一見すると超高額に見えるこういうのでも十分ペイできる距離・交通費・時間を節約するくらいでないと。

ページ211「13.1.1 技術Xから、他社にあわせて技術Yに移行しなければいけない」より、「技術においてアップグレードは必須である。」「アップグレードが早すぎると、」「アップグレードが遅すぎると、」
これは本当にそう感じてきた。システム変更を嫌う、に似てるけど、いつまでたっても古いままだと技術的に時代の流れから取り残されてしまうんよね。必ずしも流れに乗らないといけない業界ばかりじゃないけど、流れに乗らないといけないのにそれができていないところの多いこと多いこと...っおっと思わずグチが出てしまった。

ページ226「14.5.2 リリースサイクルの影響」より、「組込みソフトウェアは、更新の手順はもっと複雑で時間がかかる。」「Facebookに接続できなくなった人がよく緊急サービスに電話してきたが。」
サービスの重要度ももちろんだけど、待ってりゃメンテが終わって回復するWebシステムと、手動で削除・再インストール作業が必要になるパソコンと、待っててもダメなものはダメで二度と復旧しなくなる組み込みソフトウェア機器のリモートアップデートと、アップデートの気軽さとそれへの理解は人(というか業界というか)によって大きく異なるなぁと感じる。

ページ311「18.1.3 リモート勤務」より、「管理職は毎週80時間働いている人と単に働いているふりをしている人の違いを見分けられないのが現実だ。」
ソフトウェア開発はまぁそうなるよね。「管理職は」どころか、プログラマ同士であってもジャンルが異なると簡単じゃない。ホントどうすればいいんでしょうか。

※ 私自身があまり旅行慣れしていないので、この内容は初心者向けと思ってください。
※ 現在持ってるSIMの写真(eusim.jpg)

インターネットのおかげで見知らぬ地でもそれなりに生活しやすくなったものの、逆に言えばネットがなけりゃ旅行難民化してしまうわけで、そんなパスポート・クレカの次くらいに大事なネットアクセスの手段となるスマホ向けSIM事情について、私の経験をまとめておきます。

まずは無料WiFi。たとえSIMがあろうともやっぱり通信量は節約することになるため、無料で使えるWiFiは確実に確保しておきたい。特に空港とホテルで。最近は空港はだいたいが使いやすく提供してくれるのであまり困らない。が、ホテルのWiFiは要注意。入りが悪い、速度が出ない、そもそもつながらない、なんてのはホテルによってよくある。事前に調べておき、評判良くないとこは避けたほうが無難。

次にモバイル環境について。SIMロック解除やらSIMカードの設定すらに自信ない人はやはり、日本のキャリア(ドコモ・au・ソフトバンク)のローミングを高い金払ってでも使うのが無難。次点で、空港で借りられるモバイルルータだけど、これもおおむね1日1000円からだったり保険かけると更に高かったりで、なんだかんだであまり安くならなかったりする。複数人で使うときやら会社の経費で落とすときやらにとどめておいたほうが良い。

ようやくSIMについて。大手の日本の会社が出してる変なSIMやら海外トラベルSIMやらは、はっきり言って高くて通信量も少ないので、あまり考慮対象にならない。よほど複数のマイナーな国を転々とするときくらいしか役に立たないのではと思う。

そんなSIMをあえて買おうと思うくらいなら、Amazonなどで販売されてる各国の現地SIMを買うのが、手間暇と値段考えてコスパが良い。ヨーロッパは規制強化の影響で現地のSIMそのものを買えないことも多いけど、旅行者向けプリペイドSIMはそれなりにあって、値段も現地SIMとそう変わらなかったりする。UK Threeのもの、AIS(タイ)のFly2SIM、WeChat GO SIM(KPN版)、あたりが値段も入手性もよくて人気がある。ただマーケットプレイスで販売元が日本国外からモノを発送することもあるので、届くまでの日数には注意が必要。

もちろん、現地でSIMを買えるのならばそれに越したことはないが、店の場所や値段・時間、英語通じる店員なのかどうか、も考えておいたほうが良い。特にドイツだとテロ対策のための規制強化があり、店によっては旅行客に売ってくれなかったり、格安SIMだとアクティベートのためにビデオチャットさせられたり、敷居が高い。

また長期の場合は買ってからも大事で、Topup(チャージ)ができるのかどうかも気にしないといけない。特にヨーロッパのSIMは、クレジットカードでTopupできるように見えて、現地の国の住所で登録されたカードじゃないと払えない、なんてことが多い。じゃ旅行客はどうするかというと、ドイツだと、スーパーなどでpurchase用のやつがが売っててvcodeを入れる感じの模様。

EU圏内では協定により、域内ではRoamingしても値段も通信量もトータルで落ちるようになっていて、簡単に入手できるSIMであったり安いプランであったりするものを持っておくと非常に便利。特にUK ThreeのSIMは通話なしデータオンリーだけど非常に安いSIMを日本Amazonで買えるのでオススメ。イギリス以外では4G(LTE)入らないけど。Topupはイギリス国内発行のクレカじゃないといけないけど。

WeChat Go SIM(KPN版)は、LTE入るし値段もそこそこでよいんだけど、WeChatアプリの中のミニプログラムからTopup可能なもののSIMの有効期限が15日/30日からは伸ばせないみたいで、ちょっと常用はできなさそう。

ウクライナに行った影響で現地のKyivstarのSIMも入手した。さすがというか、身分証明などもいっさいなしで購入でき、500円くらいで4GB/28日使えたり、LTEも普通に使えたり、3Dセキュア対応のクレカからTopupできたり、EU圏と比べると信じられないくらい快適。Roamingもそれほど高くはなくて、1日150円ほどでEU主要国で使えたり。(クリミア半島の問題(2014年)の対ロシア情勢の影響で通貨が急落したため割安)。クレカない人向けに、ウクライナの市内のそこら中にあるATMのような機械で電話番号指定して現金からTopupできる。でも手数料高かった、8%くらい取られてたはず。

最後に、Google翻訳アプリ便利。文字から、音声入力から、カメラ入力から、スクリーンショットから、の翻訳がかなりの数の言語から可能。翻訳先を日本語じゃなくて英語にすると、カメラ入力からライブで翻訳してくれたりなど。ホントGoogle様々な海外出張でした。...ん？もう行かなくていいよね？

※ 他の会社のSIMも試せたら追記していく予定。

● DoS攻撃対策
iptablesレベルでもDoS攻撃やらSYN Floodやらの対策ってできるもんなのね、こっち方面はほとんど知らなかった。
個人開発でも最低限やっておくべきインフラレベルでのセキュリティ対策 - Qiita
https://qiita.com/uichi/items/c34536b66101e9440cf2
俺史上最強のiptablesをさらす - Qiita
https://qiita.com/suin/items/5c4e21fa284497782f71

● gdbのeval
gdbのdumpとevalを使えばPythonなしgdbでもいろいろできるもんなのね。また一つMakefileの組み込みshell並みの複雑怪奇な記述を書いてしまいそう。
Memory dump formatted like xxd from gdb - Stack Overflow
https://stackoverflow.com/questions/9233095/memory-dump-formatted-like-xxd-from-gdb/34485939

● 割り込み
CONFIG_IRQ_FORCED_THREADINGが有効だと、cmdlineにthreadirqsを足せば割り込みスレッド化(SCHED_FIFOの50)にできる。RTパッチ当てないと無理だと思っていた。
IRQ全般について、割り込み、hardirq、 softirq、あたりを説明した資料。わかりやすい、さすがGoogle、Googleは神、Googleさえあればいい、Google以外全部沈没。
http://she-devel.com/Chaiken_ELCE2016.pdf (PDF注意)
日本語だと下記が詳しかった。
softirq 処理はいつ行われるか

● SquashfsとOOM Killer
Squashfsをメインにしたスワップなし環境でOOM Killerが発動するとそのままハングする問題、各地で報告が上がってる。
http://lkml.iu.edu/hypermail/linux/kernel/1501.2/03899.html
http://lkml.iu.edu/hypermail/linux/kernel/1112.2/03009.html
https://www.spinics.net/lists/newbies/msg59591.html
だいたいが「OOM Killerだから何があっても仕方ない」と半ばあきらめているようだが、これ、どう考えてもバグだと思うんだけど。
kernel/fs/squashfs/cache.cのsquashfs_cache_get()でwait_event()を使っているので、SIGKILL送られても起きない、SIGKILL送った側は送られたやつが終了してメモリ解放するのを期待して待つ、結果ライブロックする。
どうせこんなしょうもない箇所で権利もクソもないから、パッチ公開してもいいよね？＞関係者