NPM汚染、Node.js脆弱性の話の覚え書き
来年のSECCONに出そうなトピックだなぁと思ってメモしておく。こんなツイートが流れてきた。
えーっと、npm 汚染で vscode 拡張やばいらしいけど vscode-tanakh 直す必要があったら起こして下さい。
— mattn (@mattn_jp) November 27, 2018
文脈よく分からなくて、なんかあったっけ?と思ってNPM、汚染とかキーワードで調べたら2つほど話が出てきたから備忘録的に書いておく。新しい話としては、NPMのパッケージのメンテナが変わって、マルウェア版が仕込まれて配布されたという話。たしかにこれはなにも意識せずに取りこんじゃったりしそうで怖い。
“2018/11/27に判明したnpmパッケージ乗っ取りについて - Qiita” https://t.co/YMWxme24p5
— 認定ジャバ (@katzchang) November 27, 2018
npm経由でまたマルウェアが配布された。https://t.co/zQRYTIY1ZM
— 高梨陣平 (@jingbay) November 26, 2018
パッケージオーナーは知らない人にメンテナ権限を譲与。今では暗号通貨採掘が埋められた。npmサイドはマルウェア版を引き上げたが利用プロジェクトが対応する必要がある https://t.co/FRtZLWl9te
もう1つは、Javascript特有のPrototypeの脆弱性を突いた攻撃がありそうだとのこと。ざっくり調べると、JavascriptではPrototypeというものがあって、全てのオブジェクトの祖としてPrototypeがいる。これを上書きすることによってオブジェクトの振る舞いが変わってしまって意図せぬ挙動となるらしい。ちょっと前にPrototypeの仕様をふーん、と読んだばかりだったのでびっくりした。
この辺りの記事が分かりやすい。
DeNA QA Nightに行ってきました。 #dena_qa_night
いまから参加。#dena_qa_night
— かざいむ (@kazaimu_) 2018年11月27日
最近テストとは?品質とは?と思っていたのでDeNA QA Nightに行ってきた。そこそこ面白かった。QAの人たちのためのイベントといった印象だったのでどんぴしゃじゃなかったものの取り組み方や前提の話などに触れられたのが良かった。イベントはデバッグ工学研究所の松尾谷さんとDeNA品質管理部の河野さんが登壇。
松尾谷さん「テストの広さと深さ、どっちが大事?」
この話はQAが何を誰に対して保証すべきかという話でとてもスケールの大きな話だった。ソフトウェアのOSS化に伴い、OSSの品質を誰が負担しているのか。Webサービスの隆盛とともに、品質保証の役割が変わり、伸び盛りのサービスを下支えするものであると同時に、人気を博しているサービスが急落するリスクを避ける、リスク対策としての品質保証であるとのこと。このような観点からすると旧来型の品質保証を標準化したり、プロセス定義を行うようなプラクティスからは脱却すべきではないかとのこと。話が壮大でなるほどー、という感じ。
私は松尾谷さんの過去の発表資料が参考になった。
10年前の講演資料。コンパクトにまとまってて良い。https://t.co/pp4ZxuO46L#dena_qa_night
— かざいむ (@kazaimu_) 2018年11月27日
あと、この辺りのツイートのトピックも面白かったです。
現代のサービス型ビジネスで、品質のパトロンは誰か、お金を出してくれるのは誰か? #dena_qa_night
— na0ya (@__na0ya__) 2018年11月27日
松尾谷「情報そのものの質が問われる世界となっている。QAの本質は“良否の判断が出来ること”。
— あきやま🍠 (@akiyama924) 2018年11月27日
これまでは仕様(有則、禁則、無則)に対しての良否の判断で良かったが、今は同じものに対する市場の良否判定が短期間に変わる時代となってしまった。どうしたら良いか?」 #dena_qa_night
QAにおける仕様化の本質
— Fumikazu Fujiwara (@freddiefujiwara) 2018年11月27日
有則:定義されてる起こってほしいこと
禁則:定義されてる起こってほしくないこと
無則:仕様に書いてなくて無害な事
ほとんどの場合無則だらけ無則が無害な事まで確認すべき #dena_qa_night
特に、有則、禁則、無則という分類は考える補助線になる良い表現だなと思った。一緒に行ったJSTQB認定テスト技術者試験に合格したプロジェクトメンバーは聞いたことがあると言っていたので、この試験のシラバスを読むのもいいかも。
http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf
河野さん「DeNA品質管理部の概説と改善事例」
河野さんはDeNAに移って1年ほどだそうで、これまでの取り組みの紹介。こちらは現場の取り組みということでとても面白く聞くことができました。移ってきた当初は品質管理はそれぞれのサービス担当のチームがそれぞれの観点でテストを行っていて、プロセスや言葉の定義なども統一されていなかったそう。そこで、河野さんはPFD(Process Flow Diagram)という記法で、各チームのテストの立ち上げ、設計、実施、とそれらから得られる成果物などをフロー図に起こして業務の見える化をしたとのこと。そして、チーム間で共通するものを標準として定め、それだけでは不足する場合は任意で追加可能、不要な場合は理由を挙げて省略できるなどのルールを定めたとのこと。そして、作成した標準のテスト業務のプロセス定義の作業、成果物などの名前を統一した。
これにより得られる効果として2つほど挙げていた。1つは、リリース後の不具合発生時にテストプロセスのどこに問題があったか改善することができるようになる。もう1つは、テスト観点のベースラインを作る、データ収集、改善、などの次の施策のベースになるとのこと。
このようなボトムアップでの業務の標準化はとてもいい手法だと思った。暗黙知を形式知に出来るとともに、各チームが標準プロセスをお仕着せではなく、自分たちの標準として取り入れることができるし、標準で足りない部分や標準の要らない部分をはっきりと意識出来る。これは今後業務改善の取り組みをする際に使えるなと感じた。
プロセスフロー図のサンプルはこのサイトにありました。
久しぶりにNodeを動かしたらエラーが出た。バージョンアップした。
Vue.jsのオンラインコースに引き続き、テスティングのオンラインコースを受けてた。英語が嫌でなければこのサービストータルで30分くらいの動画のコースでまずはちょっと触ってみるのにはいいコースだと思う。Vue.js入門とか良い感じ。3,4個のコースが無料なのでちょっと手が空いた時に良いです。
で、受けてて、最初のテスト書いたからグリーンにするぞと思ってテストコード流したらエラー。
lesson3.js:2
class User {
^^^^^
SyntaxError: Block-scoped declarations (let, co
nst, function, class) not yet supported outside
strict mode
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:373:25)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Function.Module.runMain (module.js:441:10)
at startup (node.js:139:18)
at node.js:968:3
で、これはちょっとNodeが怪しいと思って、ググったらこのサイトを見つける。
あー、おんなじ感じ。手元のNode、npmのバージョンを確認してみた。
$ node --version
v4.4.7
$ npm --version
2.15.8
どうもバージョンが問題な気がする。このサイトではnodebrewを使ってバージョンアップ、他のサイトではnpmのnというのを使うというのを紹介していたりしていくつか試してみたけど、こんな感じのエラー。
Roaming\npm\node_modules\npm-windows-upgrade\node_modules\inquirer\lib\ui\prompt.js:3
var { defer, empty, from, of } = require('rxjs');
^
SyntaxError: Unexpected token {
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:373:25)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Module.require (module.js:353:17)
at require (internal/module.js:12:17)
at Object.<anonymous> (C:\Users\XXXX\AppData\Roaming\npm\node_modules\npm-windows-upgrade\node_modules\inquirer\
lib\inquirer.js:19:11)
at Module._compile (module.js:409:26)
at Object.Module._extensions..js (module.js:416:10)
ということで、素直に公式サイトからNodeの最新版をダウンロードしてインストールして解決しましたとさ、めでたしめでたし。
後輩SEとの勉強会(2018/11/17)制約と誓約 #docker入門
後輩SEからDockerを分かるようになりたいので勉強会のトピックにさせてほしいと提案があり、今日のテーマはDocker。以前、Swiftの案件でDockerを入れたそうで最近またDockerを記事とかで目にして知りたくなったんだとか。今振り返ると、もう少し良い説明があった気がするので再現でなく、ポイントを絞って掘り下げます。
制約と誓約
漫画ハンター×ハンターを知っている人なら分かると思いますが、Dockerはまさにこれ。Dockerでは普通のサーバなら出来るようなファイルシステムへのアクセスや、プロセス間の連携はできません。これはまさにコンテナ、箱に閉じ込められたようなものです。これが制約です。そして、開発者はお作法に従った開発を行います。これが誓約。こういう不自由さがあるゆえに、形の決まった箱、コンテナであるがゆえに、箱を載せる載せるOSは中身が何かを意識する必要はありません。どこに持って行ってもDocker上で動くことが保証されています。これがDocker、コンテナ技術で得られるメリットです。
と言っても、全く意識しなくていいかというとそうでもないかもしれない。以前、航空会社の貨物部門で働いてる友人から、貨物は積載量に応じてどのように配置するか計算しないといけないという話を聞いたことがあります。
コンテナ技術というのはとてもうまい例えで、少し前にコンテナ物語という本がはやってましたが、規格化して中身を意識しなくてもよくなるというのはすごいことですよね。
演習
今日はDockerを動かしてみるというのを目標にしていたので、Dockerをインストールして公式サイトのチュートリアルに従ってDockerでHello Worldをした。基本この手順でやると、ものの10分でDockerを動かしてみることができた。
Part 2:コンテナ — Docker-docs-ja 17.06.Beta ドキュメント
ただ、2か所ほどはまったのでメモ。
docker build でイメージを作る時にエラーが出る。
app.pyファイルに日本語のコメントがあるのだが、それがdocker buildでエラーになる。このコメント行を削除するとdocker buildは通るようになる。
localhost:4000でアクセスできない
これはどうも実行したDockerがIPをデフォルトでもっているらしく、そのIPにアクセスすると作ったページが表示される。このURL↓
話したこと
この資料の始めの方を見ながら話したけど、Dockerの必要性を理解するにはある程度企業やサービスでどうやってサーバを運用しているか知識が必要だと思った。
設計Nightに行ってきました。 #sekkei_n2018
先日設計Nightというトークイベントに行ってきました。これは元々、 @shinpei0213 さんがBuildersconで話した内容についてのスピンオフ企画。忘れてしまいそうなのでメモがてらアウトプット。まずは登壇者の方々の資料を貼る。
YouTubeに講演動画上がってました。
@moznion さんの発表資料
@magnolia_k_ は公開資料作成中らしいですが、確かにこの1枚に凝縮されてます。
今日の発表、ほぼこの一枚でもいいんだけどね#sekkei_n2018 pic.twitter.com/brQlsQLYD7
— magnoliak (@magnolia_k_) November 8, 2018
コードには How
— Takuto Wada (@t_wada) September 5, 2017
テストコードには What
コミットログには Why
コードコメントには Why not
を書こうという話をした
追記。資料公開されたようなので貼っておきます。
@sona さん
@moznion さん『ソフトウェア開発における「設計」と「パフォーマンス」の相互作用』
パフォーマンスを上げるための取り組みを垂直、水平、その他という切り口で分けていて分かりやすかった。スライド中に何度か「ゼニや」というえげつない言葉が出てくるが、ビジネスを見ろと言う大事な指摘だと思う。技術的負債という言葉と同じで、パフォーマンスもコストという物差しがあることで、妥当なラインを判断できるということを学んだ。まずはコストに見合わない「早すぎる最適化」をせずに、素直に設計する。インプレッションやユーザ体験、サーバの有効活用の観点から必要に応じて、パフォーマンスを向上させる設計を行う。設計のきれいさやパフォーマンスといったそのままでは比較できないものを「ゼニ」で判断するというとても面白い発表だった。
@magnolia_k_ さん『ドメイン知識の暗黙知を形式知にするためには』
仕事で業務システムを作っているので個人的には一番身近に感じたトピック。ドメイン知識がなぜ暗黙知になるのか、どうやったら形式知とできるのかについての発表。暗黙知を3つに分けてそれぞれになぜ形式知とならないかを説明されていた。事実は起きた時にいた人には当然のことになっているから明示的に共有しない。関係はある視点から見た時に浮き彫りになるものだから視点を持つことなしに明示化できない。原則はそもそも意識しない、例外は書ききれないから共有されない。これはとても納得感があった。関係を明示化する方法として、何かしらかのフレームワーク(例えばAs-Is、To-Beモデル)に当てはめてみることを提案されていてなるほどと思った。原則を形式知にする方法がちょっと記憶が飛んでる。
ここで思い出したのが、国際協力のファシリテーションの本。この本の考え方がヒントになるんじゃないかと思った。
途上国の人々との話し方―国際協力メタファシリテーションの手法
- 作者: 和田信明,中田豊一
- 出版社/メーカー: みずのわ出版
- 発売日: 2010/11
- メディア: 単行本
- 購入: 1人 クリック: 8回
- この商品を含むブログ (9件) を見る
『途上国の人々との話し方 国際協力メタファシリテーションの手法』
和田信明、中田豊一(2010年)
みずのわ出版
これは国際協力で、援助対象の地域の人に課題を聞き取る時のヒアリングについて書かれた本だ。いくつか引用やメモを紹介する。
「私」は、村人に「問題は何ですか」と、聞いてはいけなかったし、「原因はなぜですか」とも決して尋ねてはならなかった。
現実を構成する3要素:事実、観念・考え・意見、感情・情緒・気持ちすべての質問が次の3つのタイプに分けることが出来る1.「朝ご飯は何が好きですか」→好み=感覚、感情2.「朝ご飯はいつも何を食べますか」→思い込み、考え、意見3.「朝ご飯は今日は何を食べましたか」→事実WhyとHowを使った質問は現実を浮かび上がらせない事実質問に徹するということは、「観念」「概念」を尋ねる質問は控えるということ。こちらは事実を知りたくて質問しているのに、相手は、こちらに合わせて自分の考えを交えて答えることになり、やり取りに食い違いが生じる、つまり現実認識を共有できない、あるいは、思い込みと事実を区別しないままに、「思い込み」のほうを答えてしまう、という混乱を避けるということであった。
本当の原因を知りたいのであれば、「なぜ?どうして?」と当人に聞かないほうがいい。卑近な例でいえば、「先生、お腹が痛いんです」と言う患者に対して、医者が「どうしてですか?」と聞くはずがないということことだ。患者の自己分析など尋ねないで、医者は、「いつからですか?」「今朝は何か食べましたか?」という具合に問診、すなわち事実質問を重ねていくことを私たちはよく知っているではないか。課題分析を手助けするためには、問題そのものについても、こちらからは尋ねないのが対話型ファシリテーションの原則である。逆に、もし相手がこちらに聞いてほしい問題があるのであれば、必ず相手から語り始めるはずだ。だから、こちらは、何でもいいので、相手の周辺で目に付いた物の中から意味のありそうなものを選んで、「それは何ですか?」「何でできているのですか?」「いつ手に入れたのですか?」などと単純に聞き始めればよい、ということである。
ちょっとずれているかもしれないけど、、、。
@sona さん『マイクロサービスと設計原則 』
FiNCでのマイクロサービスの実践を設計原則に照らし合わせてどのようにマイクロサービスを構成するのが良いかについての発表。マイクロサービスやったことないので、こういう課題があるのかというのが、FiNCでの事例で具体的に分かってとても面白かった。基準の立て方で、方針や構成が変わるというのがとても面白い。「実装のDRY」ではなく「作業のDRY」を目指すというのが名言。
今気づいたけど(いまさら)、マイクロサービスこそDRYの理想の体現で、マイクロサービスで出てくるDRYにまつわる問題は、DRYの根本的な問題と言えると思う。発表では横断的な関心事をDRYでどう解決するか、視点によってDRYの切り口が変わるという問題をどう解決するかという本質的な話をされていた、と今さら気付いた。それぞれ、横断的な関心事は「実装のDRY」ではなく、「作業のDRY」を目指すことにより解決する、視点によってDRYの切り口が変わる場合は、それぞれを1つのビジネスとみなしてマイクロサービスを設計する。なるほど。
とても楽しいトークイベントでした。ありがとうございました!
青年海外協力隊応募用紙がITストラテジストとかの論文問題に似ているのでは?
もうすぐ秋期の青年海外協力隊の応募が締め切りということで協力隊に応募する予定の若手の友人から応募用紙の添削をお願いされました。いくつか指摘をして、自分でも出来てない内容があったので、投稿します。
青年海外協力隊の応募用紙に書く内容は、同期や、やりたいこと、自己PRなどです。具体的にどんな項目だったか忘れたので他のサイトから引用。
1-1. 参加動機と抱負 : 約260文字
1-2. ボランティア活動の意義、目的 : 約260文字
2-1. 職種選択理由 : 約260文字
2-2. 経験(実務等)、技術適合性(セールスポイント) : 約880字
2-3. 弱点 : 約190文字
2-4. 自己PR : 約240文字
3-1. 帰国ボランティアの心に残るエピソード : 約190文字
4-1. どのようなボランティア活動を行うのか : 約240文字
5-1. 帰国後、参加経験をどのように生かしたいか : 約245文字
【2018/10更新】青年海外協力隊 ~合格者の応募用紙の書き方~ - Toward ICT4D
ぼくが受けた時よりも全体的に書く分量が細分化されているようです。
友人の応募用紙を読んで挙げた指摘は以下の通り。
- 内容を具体的に記述する(トピックを詰め込み過ぎない)
- 読んでる人に採用したいと思わせる
- 聞かれたことに答える
- 分かる言葉を使う
で、指摘しているとこれってITストラテジストの対策本で言われていることと同じじゃないかという気がしてきました。上の点でそれぞれ説明していきます。
内容を具体的に記述する(トピックを詰め込み過ぎない)
問いのそれぞれが200文字から400文字程度なので、1つか2つの話を掘り下げると十分で、それ以上に書くと表面的な文章になるような気がしました。彼の場合は、「参加動機と抱負」で、最初のきっかけとなった出来事、その後の自分の就職、こういうことがやりたい、という内容が書いてあったのですが、字数の制約からか全部が1文だけになっていました。そこで、原体験、そこで感じた課題、それを解決するために協力隊でこういう活動がしたい、と書くことを提案しました。
また、「自己PR」では過去の活動について記述されていたものの、概要と学んだことが記述されていてやや表層的に感じました。そこで、活動で働きかけた人数、どのような手段で働きかけたか、どういった組織の人とやり取りしたかなどを記述するようアドバイスしました。
まさにこれはITストラテジストで言われることで、定量的、定性的に、1トピック400字くらいで記述することで記述に説得力が出るんじゃないかと思いました。
読んでる人に採用したいと思わせる
これについては、ちょうど先日聞いたポッドキャストで広木大地さんが面白いエピソードを紹介していました。これの真ん中くらいかな。広木さんは就職するにあたって就活対策本ではなく、人事業務の本を読んだそうです。というのは、みんな対策本を読んで面接に臨むので平均点以上をとるのは難しい。人事業務の本を読むと、最初の方の面接のでお話しする人事の方の記憶に残り、次の選考に進みやすいのではないかと考えたからだとか。(このポッドキャストおすすめです。マネージャーを考えている人はぜひ。)
友人の応募調書では「 帰国後、参加経験をどのように生かしたいか」で自分のスキルアップについてだけ書かれていました。個人的には正直で好感が持てます。ただ、これをJICAの人が読んで、ボランティアとして派遣したいかというとちょっと疑問が残ります。嘘を書けと言うのではなく、自分のスキルアップと日本社会への貢献が交差するポイントを書いてあるとJICAの人も安心して派遣できるんじゃないでしょうか。
これはちょっとITストラテジストで言うと自分の役割を意識した記述にするという点で共通すると思います。ITストラテジストは役職でいうとCTOやプロダクトマネージャーを想定しているんじゃないかなと思います。そこをはずれた記述は役割を踏まえてないと見なされると思います。
聞かれたことに答える
次に友人の応募用紙で気になったのが「参加動機と抱負」で、主な流れに関係のない自分の経歴が書かれていることでした。自分のことを正確に伝えようとしてそうなったんだと思います。正確なのは良いことですが、知らない人にはどうつながるか分からないので、文章が分かりにくくなると思います。
分かる言葉を使う
そして、最後に友人の文章で気になったのが、業界用語が多めだったことです。ITのお仕事では、上流工程、要件定義などの言葉はおなじみですが、他の業界の人にはそうでもないんじゃないかと感じました。むしろ、そこでお客さんに提供できる価値である、改善方法を一緒に考える、矛盾する要望を整理するなど具体的な話に落とし込んだ方がいいんじゃないかと思いました。
これもITストラテジストの論文に共通するような気がします。
と言うわけで、青年海外協力隊を考えている人は他の論文試験の対策本を読むといいかも、ITストラテジストを考えてる人は他の人の論文を読むと良いかも、と思った次第です。
2018年秋期ITストラテジスト受けてのふりかえり(午後)
午後1、2について速報の振り返りから。
午前2
— かざいむ (@HiramotoAkira) 2018年10月21日
初めましてのキーワードがいくつかあったが合格はしてそう
午後1
当てはまるものを抜き出す問題で、曖昧な表現してるのと具体的に書いてあるのがあって、うっかり目についた曖昧なのを答えそうになった。
午後2
予想の範囲内の問題。
書いて消し書いては消しが多かった。100字くらい不足で不戦敗
午前2
— かざいむ (@HiramotoAkira) 2018年10月21日
keep
知らないキーワードに絞って勉強した
経営学、戦略の本を読んだ
problem
マトリクスの縦軸・横軸を覚えてなかった
時間配分間違えそうだった
try
在庫、連結利益はひねりがないから覚える
新出キーワードを雑誌等で覚える
時間配分に気をつける
午後1
— かざいむ (@HiramotoAkira) 2018年10月21日
keep
問題は5分くらいで選ぶ
問題を先に見て、問題文のキーワードに印をつける
problem
答えを書き間違えた
try
各業種のシステムについて本を読む
答案は最後に読み上げる
午後2
— かざいむ (@HiramotoAkira) 2018年10月21日
keep
問題集の答案を読む
書くのに慣れる
problem
規定文字数に足りなかった→推敲で時間不足
文の前後関係を意識できてなかった
try
前後関係を連ねた図を書く(論文つらい)
埋める話、聞かれている話のレベル感を掴む→参考論文を分解する
ボキャブラリーを寄せていく
午後1
午後1については大きな課題はなかったように思うけど、来期受ける試験のため、改善点を補足。
業務知識の充填
今回受けたITストラテジストの問題では、業務知識を各分野一通り頭に入れておくと答えやすいと思った。システム化のポイントや課題となる点を抑えておくと、問題文を読んだときにそれを下敷きに理解できる気がする。セキュリティやデータベースは雑誌等で事例を補うのがよさそう。ITストラテジストは『業務知識がわかる本』とかを抑えておくとよいかも。来期受験を考えているPMはまだどうやって知識を補うのがよいか不明。
最近の技術動向の知識の補充
今回、午後1ではチャットボット、ブロックチェーンを題材にした問題が2題出題された。上で書いた基本的なポイントともに、雑誌等で導入事例とKPIを抑えておくとよさそう。特にITストラテジストで問われる定量的な情報、KPIは斜め読みしただけでは忘れてしまうので、メモとか取ったほうがいいかも。
午後2
これは去年からは少し前進したものの今回も文字数不足で敗退。課題は3つくらいある。
まずは書くスピード。書いている途中で、この話にはこの前提を書かないと、というのを思い出し、消して書いてとしていたため、書くスピードが遅かった。論文一度書いてみようと何度か思って挫折したけど、それよりかはロジックを組み立てる練習をしたほうが良かったかも。次回受ける際には、問題集の模範解答の論文をロジックで分解したり、過去問を解くときに、まずはマインドマップで回答を作ってみるなどしてみたい。
次に、問われる内容があいまいな質問でフリーズしていた。実際に今読み直してみると、ちゃんと問題文に方向付けがされている。これは問題文の読み込みが足りなかった。とともに、過去問でよく見る出題だと思うので、過去問を自分でも類型化して、どういう記述をするか方向付けを考えておくとよさそう。
そして、言葉のチョイスや例示の仕方で悩んで時間を失ってしまった。課題としては、書き上げる経験の不足があると思う。対策本の回答論文の設計書から実際の論文に起こす作業をやって、どういう表現がいいか意識して記述できるようにする。
とりあえず今日はみなさんお疲れさまでした。