後輩SEとの勉強会(2018/09/22)
今日のトピックは2つほど、だったけど途中から良い疑問が湧いて理解が深まった!
- Three.js
- プログラミング言語の分類
- 上からの疑問
Three.js
彼は今Three.jsというブラウザ上でアニメーションを表示できるライブラリで作品を作っているらしい。WebGLというコンピュータ上で3Dアニメーションを表示する機能を手軽に利用できるライブラリ。特徴としてはThree.jsはCPUではなくGPUを使うので早いのだとか。
Chromeでしか見れないかもしれないけどこのサイトは小さなかけらが舞っていてずっと見てられる。これはいい。
プログラミング言語の分類
あと、自分の勉強も兼ねてプログラミング言語の種類を整理しているんだとか。で、教えてもらったのがこのサイト。言語間の影響が視覚化されてる。これは面白い。
実行の方法で分けると、コンパイル方式、インタプリタ方式に分けられる。
コンパイル方式はプログラムを機械語に変換して実行するプログラム。C言語のプログラムをコンパイルして、Windowsで実行可能なexeを作るのがそれ。
この方式はコンピュータ上で直接実行されるため、処理速度が速いが変換する手間がかかるのと、環境ごとに実行ファイルを作らないといけない。
一方のインタプリタ方式は処理のタイミングでプログラムを解析して実行する。プログラムでPHPやJavascriptでちょっと触ってブラウザ上ですぐ確かめられるのがそれ。
この方式はPHPやブラウザがプログラムを解析して都度実行しているため、処理速度は遅いが、簡単に確認することができ、環境問わずに動く。
その合いの子というのが、JavaやC#などの実行環境上で動作する言語。
これらは、プログラムを中間言語に一度変換し、それをJVMや.NET Frameworkなどの実行環境が解析して実行される。インタプリタ方式よりかは早いけど、コンパイル方式は遅い。でも、環境変わっても動く(はず)、といったいいとこどりを目指した位置付け。
全般的にコンパイル方式はメモリの確保、解放など低レベルの操作が出来るけど、インタプリタ方式ではあまりやらない気がする。と、ここで彼が良い疑問を出してきた。
WebGLでGPU使うというのはスクリプト言語なのにどういうこと?
たしかに、Three.jsはJavascriptだからインタプリタ方式だと思うけど、GPUを使っているらしい。これってどうやって呼び出しているんだろう。
で、調べた。
まず、CPUとGPUの違いは左脳と右脳の違いといった感じらしい。CPUはアルゴリズムの処理が早い。一方でGPUはざっくりの処理が早い。この辺りはAidemyのブログが分かりやすい。GPUは仕事早いけど雑、CPUは仕事出来るけど真面目すぎる。で、これまではGPUはCPUの処理した結果を画面に表示するのに使われていた。それが、CPUの計算量が頭打ちになったころにNvidiaがCPUの代わりにGPUを使う方法を提案してGPUが大流行りし出したとか。それが、雑な仕事でしくじってるところを見つけて直すというもの。これで、計算量の多い機械学習とかでもGPUが使われるようになった。
で、WebGLといっても描画に元々GPU使うんじゃないのと思ったけど、それはちょっと違うらしい。伝統的なやり方でアニメーションを描くと、CPUで計算して、画面に再描画するからCPUに負荷がかかる。それを、GPUレイヤー(このあたりよく分かってない)を使うと、描画済みの絵を動かしていることになるから、絵が移動しても再描画という扱いにならず、スムーズなアニメーションが表示できるらしい。このサイトのGPU使うパターンと使わないパターンが試せる。
ここまで来て、その違いは分かったけど、仕組みがよう分からんとなった。普通に書いて実行したら、CPU呼ばれるだけでは?と思ってしまった。で、また調べたら意外とIBMのサイトが仕組みに踏み込んで説明していて分かりやすい。ブラウザから、OSのドライバを呼び、GPUで処理されるから、CPUに負荷はかからないみたい。
この辺りから、WebGLの入門は↓のサイトである程度カバーしていていい。
最後に、実はJavascriptにはいくつか実行エンジンがあって、実行時にコンパイルを行うJIT Compilerを採用しているものが多いとのこと。最近は一概にXXだからスクリプト方式、XXだからコンパイル方式とは言えないのですね、、、。
XP祭り2018に行ってきました。
アジャイル開発の1つ、エクストリームプログラミングのイベント、XP祭りに参加します。#XPJUG
— かざいむ (@HiramotoAkira) 2018年9月8日
ということで、XPのイベント、XP祭り2018に行ってきました。
前からフォローしていたt_wadaさんのツイートで知って、申し込んだけどこういうイベントは初参加。でもアットホームな感じで参加して良かった。
基調講演はt_wadaさんで、テスト駆動開発の過去、現在、未来について。t_wadaさんの訳書、『テスト駆動開発』の付録Cをもっと掘り下げた内容のもの。そのうち資料を公開してくださるとのことでした。以下、意訳でまとめるとこんな感じでした。
開発を安心して推し進めるためのテストという理念から始まったテスト駆動開発は、途中で設計を改善する役割を強調するモック派を生み、さらにXPの理想である、ユーザーとの協働を追い求める振る舞い駆動開発(BDD)を生んだ。そして、ルールに固執する立場の人々や誤った理解によってテストをするための道具になり下がってしまった。それを受けてDHHが有名なエッセイ「TDDは死んだ。テスティングよ栄えよ」を書き、TDDの精神は失われてしまったことを宣言した。TDDの精神は失われてしまったがその道具立ては残っている。これからだ。
t_wadaさんの、現状に対する複雑な気持ちと、TDDのこれからへの希望を感じる決意表明のような講演でした。
私としては以下がお持ち帰り(takeaway)の学びでした。
講演の参考資料の本の山。
2019/1/19 追記
講演の資料が公開されていたのでアップします。
ツイート見返したら他にも学びがあったんだった。
TestingとCheckingを分ける。
— かざいむ (@kazaimu_) 2018年9月8日
テスト駆動開発でやっているのはChecking。#XPJUG
テストを書いたときに引っかかりを覚えて設計を改善していきたい。
— かざいむ (@kazaimu_) 2018年9月8日
モックは良い設計を導くための補助線。#XPJUG
午後は、@yattomさんの心理的安全性ゲームのワークショップに参加しました。心理的安全性はGoogleなどで、チームの生産性を高くするために必要な環境として最近注目されている考えです。参加前は安心して発言出来ることがチームの生産性を上げるという理解でいましたがワークショップではもう少し深い理解が出来たように思います。
ワークショップは5、6人のチームで@yattomさんが作ったカードゲームをするという形で進みました。まずは自分たちがどんなチームかを定義します。カードは大きく2種類。1.トラブルカード、2.発言カード。1人がトラブルカード(例:アポをすっぽかしちゃった!)を引いて、それに対して、他のメンバーが手持ちの発言カード(例:大丈夫、またはわたしは関係ない、など)の中から一つを選んで場に出します。で、それを受けてトラブルを起こした人は発言全体を受けてどう感じたか当てはまるマス目におはじきを置くというものです。
1回やった後で、自分たちはどんなチームかを振り返り、発言カードを選び直してもう1度同じようにゲームを行います。これはやってみると、なるほどと思うこともあるのでぜひやってみてもらいたいです。私のお持ち帰りの学び(takeaway)はこんなところでした。
- チームによってどういう価値観を重視するかは異なる
私たちのチームはラオスにオフショア開発しているチームと定義したので、一緒に頑張る、安心して話せるというのが挑戦よりもより大事な価値観だと考えました。 - プラスとマイナスの発言があるとゼロにはならない。どちらかというとマイナスに引きずられる。プラスだけだと空気は何倍にも良くなる。
これはうちのチームでの傾向でしたが、マイナスの発言カードがあると、他の人がプラスの発言カードでも前向きになりにくく、逆に、プラスの発言カードだけだと相乗効果でとてもプラスになりました。
1回目のゲームの様子。おはじきは少な目。
次の時間は川鯉光起さんの副業についてのワークショップでした。長期的なキャリアは一度脇において、今のスキルや得意なこと、興味があることから副業として何ができるか考えようというものでした。後半ではお互いのスキルの共有を行い、他の人がどんなことに興味があるのか、どういうスキルがあるのか見て回りました。
このワークショップのお持ち帰り(takeaway)はこんな感じです。
もっと色々出来る気がしてたけど書き出すとあれれ、な感じに。
次の時間は短い講演を挟みました。すみません、ちょっと疲れてあまり集中して聞いてなかったです、、、。
その次の時間のこの日最後に参加したワークショップは森一樹さんの振り返りを振り返るというワークショップで、グループに分かれてこれまで参加したプロジェクトなどの反省会についての反省を行いました。どんな環境、メンバー、時間帯、進め方が盛り上がったか、次やる時にはどんなことをやったらいいかなどのアイデアを共有しました。講師の方の進め方も分かりやすく、メンバーにも恵まれとても楽しくアイデアの共有ができました。
このワークショップのお持ち帰り(takeaway)はこんな感じです。
- 振り返りは事前の準備(メンバー、環境など)、進め方、終わった後など色々と改善のポイントがある。
- 自分は当日の進め方に考えがいきがちだけど、お菓子を食べながら、ギャグをいいながらなど影響する要素はたくさんある。
- 対話を行うのか、議論を行うのかで進め方は変わってくるかも。
- 話をゆっくり聞いてもらいたい人もいるのでゆとりある環境でやる。
森一樹さんからブログについてフィードバックもらえたので下に貼り付けておきます。なるほど!ありがとうございます。
"話をゆっくり聞いてもらいたい人もいるのでゆとりある環境でやる。"
— びば(森のフレンズ)/技術書典6 ふりかえり読本 学び編 (@viva_tweet_x) 2018年9月9日
ゆっくり自分のペースで話をする、というグランドルールを全員で合意出来ているとなおよいですね!そのためには十分な時間や、リラックスできる空間も必要です。 https://t.co/bqbwKkKIe7
"対話を行うのか、議論を行うのかで進め方は変わってくるかも。"
— びば(森のフレンズ)/技術書典6 ふりかえり読本 学び編 (@viva_tweet_x) 2018年9月9日
基本的には対話ベースのほうがよいと思っています。意思決定をする場ではないので、対話でアイデアを広げ、深めていきます。全員が対話を意識するためのアイスブレイクを入れるだけでも、効果があります。#ふりかえり
記事書いた直後にテーマの近いツイートが流れてきたので XP祭りとは関係ないけど貼っておきます。
会議は「対話」と「議論」の時間を分離するだけでまとまる。主語が自分で感情を共有する「対話」と主語がプロジェクトでこのプロジェクトの成功の方法を考える「議論」の時間を明確に分けるとスムーズ。対話と議論を同時間でやると主語も目的も違うのでまとまらない。
— 秋好陽介@ランサーズ (@AkiyoshiYosuke) 2018年9月12日
ほんと色々と楽しかったし、もう少し反芻したい経験をしました。
ありがとうございました!
営業の方に言われた言葉
Photo by Kyle Johnson on Unsplash
常駐先の営業さんに今のプロジェクトの後の案件が決まっていないのでそれもあってこんこんと、ややきつめに諭されました。
調べればわかること(プログラミング)は何かを生み出しているわけではない。
ちょっとこれは分かる気持ち半分、いやいや、と思う気持ち半分でした。自分のことをエンジニアとはっきり割り切るなら聞き流せばいいけど、自分が動いて仕事を作り出していきたいならちょっとしっかり受け止めないといけないなと思わされた。
あなたのことを知らない人のところに行って、その場で仕事を任せたいと思えるのか?知らないお客さんのところに、どんな会社かもわからないようなところのおじさんが来て、仕事お願いしたいと思う?普通は大きい会社の若い人にお願いするよ。頼む方から考えてみて。
私が仕事を取って来れるのは、相手に付加価値を提供しているから。普通なら、要件を詰めてからSIerに発注するけど、私がその役割を果たしているから私に相談する。あなたはどんな付加価値を提供している?
初対面でそう思わせるような付加価値を提供しないと。あなたは今日の打ち合わせで輝いてた?
これもたしかにそう。開発会社なんていくつもあるけど、その中で自分たちに頼みたいと思ってもらえるにはどうしたらいいか。何かしらかの付加価値がないと選んでもらえない。そして、仕事のとれるエンジニアになるには打ち合わせでもお客さんにお願いしたいと思ってもらえるようにならないと。
夢を追うなら他人のふんどしで相撲を取るな。夢のためなら他人に乗っかるな。今の動きは行き当たりばったりにしか見えない。
今日言われたことでこれが一番きつかった。海外プロジェクトの話が来るまで待ち、それまでは国内案件でつなぐと言うのが会社のスタンス。9月末の派遣法の改正前に海外案件が始まるんじゃないかと思ってて、それまでの間の予定だったけど、海外案件はいつになっても出てこず、それに派遣法の改正や案件の谷間がかぶって、次の案件がなくなってしまった。少し先にまた海外案件があるんじゃないかと思ってるけど、自分たちで動きを作っているわけじゃない。そう、自分でコントロールできない部分が多すぎる。夢を追うなら自分でコントロールできる部分に働きかけないといけない。
あと10年したらあなたは50歳になっちゃうよ。今のままの仕事を続けられるの?SE、コーディングは50歳以降になると依頼されなくなっちゃうよ。今いいなという仕事をやっていると、将来やりたい仕事が出来ないよ。将来と今はつながっているけど、今の延長のままでは将来やりたいことにつながらないよ。
これもきつかった。たしかに、今のままじゃ将来なりたいものにはなれない。将来を軸に今を考えないといけないんだと思う。チャンスを待っていったん望むような案件に入れても、それが続けられるようにするにはどうしたらいいか。
本当にきつい。
でも、ありがたい。
2018/09/09追記
ソフトウェアエンジニアとして取り得る対策はこんなかんじかなぁ。
8月後半気になったツイート
作るもの・作ったものの設計をドキュメント化するときには、「なぜそうするか」「なぜこうはしないか」の理由と問題の背景、それを補助する実験・実測値が一番大事で、設計そのものの詳細を微に入り細に入り記述しておいてもドキュメントとして大して価値がない…、というのは定期的に言っていきたい
— Dai MIKURUBE (@dmikurube) 2018年8月31日
「研究開発で成果が出ない原因は、技術的な作法に則って思考を言語化できていないから」という内容を簡単にまとめてみました!
— 藤田肇☘️研究開発で成果を上げる方法を書きます (@fujitahajime) 2018年8月31日
意外と知られていないのですが、たくさんのエンジニア・研究者に接した経験から黄金フォーマットを使うのが鉄板です。 pic.twitter.com/UAfR7bSU6R
ソフトウェア開発入門の記事が書けました!書くの時間かかった…
— はやぶさ (@Cpp_Learning) 2018年8月31日
『物体追跡カメラ開発』を題材に以下のことが一通り学べます
・開発プロセス
・設計
・実装
ソフトウェア開発について学びたい!という多くの人に読んでもらいたいので、RTお願いします!https://t.co/b0yhMEILKe
凄く分かりやすいステキな回答。AIに仕事を奪われるとか心配する前に、日本の教育はこういうところを変えていくこと考えた方が良いような気がする / “帰国子女の娘がクラスで浮いた存在に… 鴻上尚史が答えた戦略とは? (1/7) 〈d…” https://t.co/wa1DMhllLt
— からあげ (@karaage0703) August 23, 2018
モダンなJava開発ガイド (2018年版) https://t.co/4ypoDSSiuv
— 水島宏太(ですます調) (@kmizu) August 25, 2018
Kotlinに関しては、こういうアドバイスをしなけりゃいけない環境で使うのがいいのだろうか、ちょっと疑問がある(Scalaにも言えるけど、Javaを既にこういう風に運用してるとこじゃないとKotlin導入うまくいかないような気がしている)。
これが英語学習の王道だと思う。私はTOEICのリスニングが満点なのだが、SEX AND THE CITYを英語字幕で繰り返し見ていたことが要因だったと思う。今なら「SUITS」をお勧めするんだけど、難しいようなら「BREADING BAD」でもOK。繰り返し見るのが重要なので、繰り返し見られるコンテンツ選びも同様に重要 https://t.co/YtvJ3qUyuE
— Yu Fujisawa (@venturemar) August 24, 2018
「アウトプットは毎日少しずつでもやる」など、第二言語習得の理論に基づいた勉強法をまとめた記事です。スポーツと同じで、最初にセオリー理解するの大事なんですよね。習得の速度全然違うので。 https://t.co/8ky5SI6cRO
— とくさん (@nori76) August 28, 2018
河合隼雄は日本を「母性」社会だと論じたけど、ここにまとめたように、確かに日本人は男女問わず、仕事の上司や組織に自分を包み込む「母性」を求めがちだな、とは他国と比較して思う。ここでは「べき論」は意味なくて、それを前提にどう組織設計するかが大事かなと。https://t.co/XVzUnqztiF
— とくさん (@nori76) August 27, 2018
7月中旬からPythonと機械学習でいろんなものに手をだしてきたけど、一番お金が節約できて近道ができる勉強方法は以下の通り。
— edash (@edash18) August 27,2018
1⃣Progateで基本を抑える
2⃣松尾研の資料を練習問題含め全部コードにする
3⃣Kaggleで興味のある問題のKernelsを写経
競技プログラミングとか、html&CSS遠回りしすぎた。
めちゃ良い資料
— ばんくし (@vaaaaanquish) August 19, 2018
社会人向け講座「データ分析者養成コース」
機械学習技術とその数理基盤 https://t.co/8Dvf2Xr8KO
後輩SEとの勉強会(2018/08/25)
今回の情報共有。
ディレクトリサービスとは
ドメイン参加したPCでサーバにアクセスしたらフォルダが開けなかった。グループに入ってなかったとか言われて、その設定をした後はログイン出来た。これってどういうことですか?
ディレクトリサービスへの理解が必要です。ディレクトリサービスとはユーザーの認証、サーバーへの権限を管理する機能。パソコン1台だと特に必要ないけど、コンピュータが増えてくると、特定の場所でファイルを管理したり、ユーザーを部門などのグループ単位で分けて管理したくなる。この機能を提供するのがディレクトリサービス。ユーザーについては名前、ID、メールアドレス、パスワードなど色々な情報を管理できる。また複数のユーザーをまとめたグループがある。また、コンピュータも同様に管理される。
コンピュータのフォルダとグループの組み合わせでお望みの管理ができる。
このディレクトリサービスにはMicrosoftのActive DirectoryとApacheのApache Directoryがある。
Welcome to Apache Directory — Apache Directory
このディレクトリサービスは人事システムとデータ連携をしたりする。夜間バッチとか。
シングルサインオンについて
このディレクトリサービスにちょっと関係するのが、シングルサインオン。シングルサインオンとは企業内では運用されている複数の業務システムに同じアカウントでログイン出来るようにする機能のこと。会社のニーズとしては、パスワードの適正運用やユーザーの利便性の向上のために導入する。Active Directory+Windowサーバーであれば、パソコンに1度ログインすればそのまま各業務システムにログインできる。Active Directory以外でもシングルサインオンは可能。構成によってエージェント型、プロキシ型などと呼ばれる。エージェント型は、業務システムに対して認証した結果を返す。プロキシ型はユーザーのPCと業務システムとの間に入って、ユーザーに代わって各業務システムにログインする。詳しくはこのサイトに。
プロキシについて
このプロキシという言葉は元々英語の代理という意味。代理戦争はproxy war とか言う。企業などで、パソコンを使い始めるときにプロキシの設定を、、、と言われる時のあれ。これは、インターネットへの接続を中継する機能。これがあると、ユーザーがどこに繋いでいるか確認できたり、変なサイトに繋ぐのを防いだりすることができる。
テストについて
後輩の知り合いが仕事で使っているツールについて。その彼は仕事としてサイトのテストをしているんだとか。テストで使うツールというのがOWASP ZAPというツール。これのツールはクライアントとサーバの間でプロキシとして動く。クライアントで一通り操作すると、経由しているOWASP ZAPにURLやクエリストリング、リクエストボディなどをトレースして、その情報を元に色々なリクエストを投げて脆弱性を探すとのこと。ちなみに、EasyBuggyという脆弱性を勉強できる、穴だらけのWebアプリを使うとOWASP ZAPの力を把握できます。
そういえば、サーバーのテストツール、監視ツールもあるね。
Apache JMeter - Apache JMeter™
サーバーを監視するツールとして、Zabbix
Blenderについて
3D動画、画像作成ソフト。これは最近はやってて、美大卒の人が使ってたりするらしい。ベクター画像を作れる。ただちょっと手間がかかる。手書きのラフスケッチを取り込んでそれをトレースする。そして、ちょっと回転して、ポリゴンの頂点を置いていく。ツールになれるのが時間がかかるみたい。
そういえばUnityのAssetですごいのが流れてた。こんなのが使えたらもうこれだけで作品。
クロスプラットフォームフレームワーク
少し調べているのが、デスクトップアプリ開発フレームワークのElectron。Javascript+HTML5で作って、Mac、Windowsのデスクトップアプリとしてビルドできるらしい。これでJavascriptのライブラリを使ったデスクトップアプリを作れるかなと。
『エンジニアリング組織論への招待』 部分最適化とその解消方法、またはシステム思考について
先日読み終わった『エンジニアリング組織論への招待』だが、めくるごとに納得することがある。
今日は、意見の対立の解消方法について書かれた部分を紹介する。たぶん本書を読んでもらった方が分かりやすいが、読んだことない人への紹介をこめて。
例えば、短期間の売上アップの施策Aと、顧客満足をあげる施策Bがある。ありがちなのは営業の人がAを主張し、UX担当の人がBを主張する。そして、両方やるお金はない。ここでは、「売り上げのため」、「ユーザーのため」という意見が交わることなく議論が物別れに終わる。
そこで筆者は同じモノサシで測れるような視点を持ち込むことを提案する。ここでは長期的な売り上げの推移を基準にして、AとCのどちらが有効であるか売上予測から判断できるようになり、その結果、どちらを選ぶべきか合意することができる。
ここで、筆者が重視しているのが、要素に分解するだけでは見えない物事の流れがある。道路が混むからバイパスを作ったらそこに入ろうとする車のせいで余計に混むとか、売り上げをあげようと少ない人数で営業を頑張ったらフォローがおろそかになり、苦労の割りに売り上げが上がらなかったとか。
そういう想定外の結果を理解するための枠組みとしてシステム思考がある。この動画とかが分かりやすいのかも。自分には上手く使えないから自分と環境の違う人に図を描きながら話を聞いてもらうといいのかも。ちょっとやってみよう。