2018/12/29 気になった記事まとめ
今年はいろいろありましたが、無事に仕事納めを迎えましたね。来年もgdgdだらりと生きていきたいと思いますこんばんわ。
ブロックチェーンはオフチェーンじゃないとつらいぞよ(´・ω・`)
ブロックチェーンでのサービスの作り方の用語解説のようですね。
以前、有料の勉強会でSolidity使ってEthereumのコントラクト書いた事あるんですが、ブロックチェーンで保存される変数、そうでない変数みたいな使い分けが面倒だった記憶があります(´・ω・`)
記事でも触れられてますが、一度デプロイすると原則修正できないです。バグが有っても修正できない_(:3」∠)_
設計やテストをしっかりやって、完全な状態で出さないと行けないので、実際にやるときは注意する必要があります。開発者用のネットワークがあり、そこでお試しできるのが救いですかねー。
個人的に触ってて一番たいへんだったのは、トランザクションの完了が遅いところ。一般的なWEBアプリ的なものを全部ブロックチェーンでやろうとすると、まともに処理できないアプリが生まれてしまうので、本当にブロックチェーンを適用すべき場所を見極める必要があります。
いろいろと運用の癖や課題もあります。以下は結構参考になりそうです。
GraphQLでのアップロード
以前、諦めて普通にRestで処理するようにした記憶が(´・ω・`)
最近、弊社でもGraphQL採用のMicroservice増え始めたんですが、運良くReadしかないのあんまり困っていませんでした。ファイルアップロードするときの良い知見
そういえばあったよTracePoint
これまであまり使い方わからなくて触れてなかったんですが、ブレークポイントを気軽に貼るやりかたいいですね。
いちいちbinding.pry埋め込んでましたよ(´・ω・`) これがあれば動的に差し込めるので、「あ、ここブレークポイント貼って動かしたいな」と思ったときにさっと晴れると、いちいちコード書き直す必要もなく楽に調査できそうですね。
Transient Heapについては、ずいぶんピーキーだなぁという印象。
theap で一度に確保できる領域は 2KB に制限しています。このサイズに何か根拠があったわけではなく、当てずっぽうです。もしサイズを超える場合は、最初から malloc() して、theap を利用しないようにします。
Railsで普通に使っていると、2KB以内で収まるものってあんまりない気がします。それこそ使い捨ての変数くらいで、一番生成されるんじゃないかと思われるActiveRecordモデルのインスタンスだとほぼ確実に超えそうですし...
うまく付き合う方法を模索してきたいですね(｀･ω･´)
開発用DockerでのDBの初期設定について考える
最近、本腰入れて個人開発はじめました。 ちょっと今のブログが使い勝手よくないんで、CMS付きのブログサービスを作ろうかと(｀･ω･´)
さて、今の時代開発環境を構築するにはDockerという便利なものがあります。 諸々の初期設定が出来合いで用意されているので、開発着手までが以前より素早く行えるようになります。いい時代ですね。
さて、今回はCMS付きブログサービスをつくるのでDBは必須です。まあMysqlになりますかね。
もし需要あってサービスインする場合でも、即AWSAuroraに載せられるので楽に運用できますし。
さて、それでは開発を、といったところですが、Database作ったり、アクセスユーザー用のGrant発行したりといった細かな作業する必要あるんですよね(´・ω・`) 今回はDockerつかってScrap＆Buildが繰り返されるので、毎回この作業するの面倒です。
mysqlに関して言えば、公式イメージを使うことで、コンテナ側の/docker-entrypoint-initdb.d以下ファイルを読み込んで、初期設定できる機能があります。
https://hub.docker.com/_/mysql/
この説明の中に、Initializing a fresh instanceの項がありますが、そこに
When a container is started for the first time
とあり、containerの最初の起動時に一度だけ呼ばれるようです。実行できるのは
で、これを用いればDB作ってユーザー権限付与して、SQL dumpから初期データ作成等できますね(｀･ω･´)
実際に呼び出されるタイミングは、
で、この、docker-entrypoint.shはDockerfileの
mysql/Dockerfile at 696fc899126ae00771b5d87bdadae836e704ae7d · docker-library/mysql · GitHub
で呼ばれています。つまり、イメージをビルドしたタイミングで呼んでくれるので、containerの最初の起動時に一度だけの動きをしてくれるみたいですね。良く出来てて、とてもいい(｀･ω･´)
実はMongoDBも使おうと思って調べてたんですが、こちらにも同じような仕組みがあって、
https://hub.docker.com/_/mongo/
This variable allows you to specify the name of a database to be used for creation scripts in /docker-entrypoint-initdb.d/*.js (see Initializing a fresh instance below). MongoDB is fundamentally designed for "create on first use", so if you do not insert data with your JavaScript files, then no database is created.
こちらはjsで実装する形になりますが、同じように初期化処理が実現できるようです。
2018/12/27 気になった記事まとめ
年末、忘年会シーズン真っ只中ですね。 酒あんまり飲まないように言われてるんですが、この時期だとどうしても酒量増えちゃいますね。自重自重。
最近のAuthenticationの動きがわかるやつ
こういう基準があるので、自分や自社でサービスやるときは準拠しておいた方がよさそうですね。 多要素認証にもいろんな決まり事があるのを初めて知りました。再認証の有効期限とか特に。
パスワードの定期変更が推奨されなくなったり、秘密の質問が完全廃止されたりと、これまで当たり前のように使われていたものが推奨されなくなってますね。これまでそれ使っていたサービスは認証の置き換えを考えることが必要になってくると思うんですが、そんな昔のサービスだと認証関わった人が辞めてたりするので、大変そうだなーと思います(´・ω・`)
楽しむための働き方
勉強と趣味と仕事が全て両立できる仕事なんてあれば、人生とても豊かに過ごせそうです。 出勤嫌がったり、難しい仕事を避けがちな仕事と比較して、ソフトウェアを含む全てのエンジニアは、趣味と学習を両立できる希少な仕事だと思います。自分の趣味等と合致していれば苦もなくやっていけますよね(｀･ω･´)
学んだことを発信し続けていれば、それがメリットとなる企業から声かかったり、自分から企画持ち込みしたり、それが巡り巡って面白い仕事が回ってくる。いいですね。
おちんぎんを増やす技術 - 無気力生活 (ノ ´ω｀)ノ ~゜ でも書いたんですが、経験少なくても飛び込んでいってスキルを得る話に近いような印象です。スキルを得てやれることを増やし、さらに新しいことを学んで、それを必要とする会社に売り込みかける。面白い仕事を得るためにはそれをできるだけの能力を示さないといけない。重要なことですね。
この話読んでいて、これちゃんと考えなきゃいけないなーと思ったのは、自分のポジショニングですかね。どんな技術に強くて何ができるのか。仕事ではバックエンド触ったり、フロント書いたり、Unity書いたり、データ基盤触ったり、開発フローの構築したり、ゲームプランナーやったりしたんですが、特にこれが強いってやつが見つかってないんですよ(´・ω・`)
自分が将来どんなことをやりたいかを明確にして、それに関するアウトプットをしていくこと。そこ頑張らないな、と思います。
文化が異なる人と全く同一認識を持つのは難しい
東京は本格的な冬の寒さが訪れ、株価の下落も合わせて心身ともに寒い今日このごろです_(:3」∠)_ ガッツリ損食らってるので、今年はおとなしく損益通算処理したいと思います。ああ無情。
転職した会社が比較的体質の古めな企業で、テック全く理解してない人と話すことが増えたんですが、かなりしんどさを感じてます(´・ω・`)本来であれば一言で言えることを何度も呼ばれて説明しなくてはならず、それでも理解してもらえないのでとても大変です。AWSのカスタマーアグリメントを共有しても「事業者はどの会社ですか？」とか聞かれるのはちょっと....
同じ会社の中ですが部署職種によって文化が異なり、前提知識も異なるのは理解してるんですけどねー(´・ω・`)なるべく技術触れて無くてもわかるような説明をする努力が足らんのか、なんなのか。
人はその環境によって考えは変わる
とあるように、我々人間がなにかを認識するとき、同じものを見ても各々が異なる解釈をしてしまいがちです(´・ω・`) その人が持っている知識、触れている文化、これまで生きてきた環境によって異なり、みなが同じ認識を持つことは大変難しい。
最近英語のヒアリング練習を兼ねて字幕付きTED動画を見ることがあるんですが、この話は、人が触れている文化によって人間の認知が異なることを説明されています。
紹介されている色の見分け方の話ですが、英語ではBlueと青を一つで表すのに対し、ロシア語では細かな青の色違いでも名前があるそうです。青色でも区別した色名がある。
仮に、ロシア人とデパートのハンカチ売り場にいると仮定しましょう。そこでロシア人に「青のハンカチを選んで」とお願いした場合、この時お互いに同じ彩度・明度の青色が浮かぶでしょうか？おそらく無理だと思います。相手にとって青色の選択肢は多く、単に青と言われた場合頭に多くの選択肢が浮かぶでしょう。同じ認識を持つことは難しいです。
同じ文化や国であっても、生まれの年代が違えば、言葉一つとっても各々で異なる認識が生まれます。例えば、『携帯電話』という言葉から、20代の若者世代と、60代のシニア世代で浮かぶものは同じでしょうか？きっと最初に浮かぶものは違うと思います。生まれの年代が違うだけも同じ認識を得ることは難しい。
では、どのように考えるべきか
単に言葉を与えるだけでは、同じ認識に至ることはありません。お互いが持っている認識のズレを合わせて行く以外方法がないと思います。しかしいくら説明しても擦り合わないこともままあります。このようなとき、どのような打ち手を考えるべきなんでしょうか？
エンジニアの知的生産術という本を読んでいます。
エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)
- 作者: 西尾泰和
- 出版社/メーカー: 技術評論社
- 発売日: 2018/08/10
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
この本の第六章に抽象概念を引き出す『Clean Language』、『Symbolic Modeling』といった手法が説明されています。相手が何を考えているか引き出すために、以下の5つの質問を定式化したそうです。
①そのXはどんな種類のXですか？
②そのXについて、ほかに何がありますか？
③そのXはどこにありますか？
④そのXはどのあたりにありますか？
⑤そのXは何のようですか？
その時の状況に応じて問いかけの言葉は変わるとのことですが、このような質問を繰り返して、その抽象的な認識を言葉によって可視化します。その過程で必要条件や意図が引き出され最終的にお互いが近しい認識を持つことができると理解しました。
冒頭のAWSわからない問題に対しても
- 相手は今どんな認識を持っているのか？
- それは自分の認識とどれだけ乖離があるのか？
- 相手がわからないことはなにか？
- 相手は、それを知ることで何を得たいのか？
- 本当に相手が知ることで、問題は解決するのか？
といった問を提示することで、お互いの認識のどこが合っていて、どうなっていないのかが見えてきます。
問いかけを行うことで情報が精査され、お互いが理解できる落とし所まで持っていける。人と共通の認識を持つためには歩み寄り引き出すことが大切だと感じました。
まとめ
対話を諦めず、相手のわからないことに寄り添ってあげると良いんだろうなぁ(´・ω・`) 私の努力不足でした、残念。というオチです_(:3」∠)_
golangのディレクトリ構成について悩む
今年もあと僅かで終わる今日このごろですが、ようやく本腰上げてGoでバックエンド書き始めようとしました。
しかし早速ハマるディレクトリ設計_(:3」∠)_ 本来Goは＄GOPATH配下で開発を進めます。しかし、今回はフロントエンド側のコードも含めてgithub上でgit管理したいのでこんな構成にしたい。
/ ├ docker/ ├ app/ └ front/
appというのがGoのAPI実装ですね。
参考書や、https://golang.org/doc/code.html を見る限り＄GOPATH/github.com配下に管理されるべきなのですが、Go以外のコードが含まれているのに$GOPATH配下にあるの気持ち悪いなーと思うんです(´・ω・`)とはいえ、$GOPATH以外で開発しようとするとライブラリ周りの部分で面倒そうな対応が必要そうな予感がして面倒だな、と。
さて、この構成どうしたものか。
いろいろ考えたんですが、一番良いのは開発をdocker上に乗っけて、依存関係をdepで解決させることでした。上記でやりたかった構成を適用すると、ざっくりこんな配置になります。
/
├ docker/
│ - app/
│ └ (今回はイメージそのまま使うのでcomposeへ)
│ - docker-compse.yml
├ app/
│ - code ....
└ front/
- code ...
- node_modules
golangのイメージをベースにこんなdocker-composeを書きます。
version: '3'
services:
app:
image: 'golang:latest'
volumes:
- 'data:/go'
- '../app/.:/go'
ports:
- "8080:8080"
command: 'go run main.go'
volumes:
data:
driver: 'local'
main.goについては、https://qiita.com/macoshita/items/827ae5ac245b94ed4b4c を参考に、8080ポートで待ち受けるやつを適用に書いて動作確認が完了。
docker上の/goに、appディレクトリをマウントして上げれば希望のことが実現できました。
- 作者: 松木雅幸,mattn,藤原俊一郎,中島大一,牧大輔,鈴木健太,稲葉貴洋
- 出版社/メーカー: 技術評論社
- 発売日: 2016/09/09
- メディア: 大型本
- この商品を含むブログ (4件) を見る
2018/12/23 気になった記事まとめ
気づけば毎日ブログ書きを続けて14日。なんとか継続できてますが、油断すると下記忘れそうな状態です_(:3」∠)_
一ヶ月間継続できれば、習慣化できる...のか？
静かに生き始めると人生まさに終わった感あり(´・ω・`)こわい
今年８月くらいの昔の記事ですが、なぜかはてブで上がってますね。
企業が最新のテクノロジーをビジネスに活用しようとする時の重要な課題は、社内にどれだけ技術を理解して動かせる人がいるかということ。だからこそ、どんどん自分で動いていくことが有効ですね。
昨日書いたおちんぎんを上げる技術にも、それとなりに書いた話なのですが『問題に挑戦する機会』を得て、『会社の問題を解決できる力』を身につける。
会社の問題にもいろいろありますが、この記事の例だと最新のテクノロジをビジネスに活用することが挙げられています。 それができる人であれば、目立つし、それに関わる仕事が多く舞い込んでくるようになります。自分の選んだやりたい仕事をやり続けられる日々は最高だと思います(｀･ω･´)
耐障害性の設計は忘れがちですが
これまでいろいろと開発してきたんですが、割と『障害が起きたときにどう動かすべきなのか？』を意識されているシステム、特にtoCでお金が絡まないサービスにおいてはおざなりになります(´・ω・`)
特にMicroserviceを適用する場合、そのAPI自身も外部のAPIに通信して処理を行うことになります。ここで同期処理を行っていた場合で、外部のAPIで何らかの障害が発生してレスポンスを返せない状況下にあるとそれに引き摺られて一緒に死にます。
非同期通信を使用することで、サービス間の疎結合を保ち自律性を維持することができます。
(私個人が考えた)一言で表すと、「他のサービス死んでても、自サービスは正常に処理を完了できる」です。例えば外部処理をキューに詰める処理だけして後で問い合わせるなり、この記事のようにPub/Subを使うなりの方法を用いて、外部APIの呼び出しもとAPIもまとめて死ぬことを防ぐことが重要です。
前職でモバイルゲームの開発をやっていました。イベントの開始時大量のアクセスが来てUnicornが詰まることがあり、対策を考えていました。そこでExponential Backoffとリトライを使おうとしたことがあります。
まあ結局はAPPサーバーを増台してUnicornのワーカー数を増やすことで決着したので結局利用しなかったのですが、こういうやり方を知っておくだけでも有益だと思います。
昔jQueryだけでSPAやってました_(꒪ཀ꒪」∠)_
https://www.m3tech.blog/entry/js_3_point
シングルページアプリケーションのHTMLゲーム。やってた時期は今からだと5-6年くらい前ですかね...。
当時はまだReact.jsがOSSになっておらず、jQueryなり軽量jQuery的なものが幅を効かせていた時代でした。 データを扱う層、画面を描画する層を分離することがとても大事。この記事にも書かれていますね。
その時担当していたHTMLゲームでは、なにか操作して画面の表示を切り替える際、まずAPIリクエストでそのページでアクセスされる可能性の高い情報を一括で引いてました。例えば装備一覧画面なら、所持しているすべてのデータをJSON形式で受け取ります。
処理の流れを雑に列挙すると、
- 今の条件で表示するデータを1ページ分取得し、内部のHashに保存しておく
- 1以外のデータの取得をリクエストしておく。
- 2の処理を行っている間、1で取得したデータとテンプレートからDOMオブジェクトを生成し、ページ中のコンポーネントを丸々入れ替える
- 2でリクエストしたレスポンスを内部のHashに詰める
で、ここで重要なのは、データの取得と描画処理を分離することです。絶対にxHttpRequest.onreadystatechange でレスポンス受け取った中で描画しないことを心がけてます。
- 予め、データ用のModelオブジェクトに受け取ったデータを詰めておく
- Modelオブジェクトのデータから、コンポーネントに表示するためのDOMオブジェクトを、テンプレートとデータから生成(当時はhttps://ejs.co/使ってました)
- ページ中のComponent要素の直下を、2で生成したDOMオブジェクトで差し替え
データを元に描画するDOMを構築しそれで置き換えるだけ。楽。(｀･ω･´) 一番メリット大きかったのは開発が非常に楽だった点ですね。画面を表示したままデータを取得する処理だけ実行してサーバー側の実装変更に追従したり、逆にフロント側の条件分岐を確認するためにデータ書き換えて、renderメソッドだけ実行する。ちょっとした変更をすぐ試せるので効率が良かった記憶があります。
今になって思えば(程度の差こそあれ)Reactに似てるんですよね(｀･ω･´) 実はReact等無くても実現できるので、ものすごく小規模なら自前で書いたほうが楽かもしれませんよ。
おちんぎんを増やす技術
12月、年末ですね。今年もあと数日で終わりです。個人的にも2018年はしばらくITエンジニアから離れてたり転職したりで慌ただしい一年でしたヾ(:3ﾉｼヾ)ﾉｼ
12月といえば、賞与の査定が出たり、目標設定フィードバックで昇給などがあった人もいるかもしれません。賞与もらってから転職しようとしている方も、もしかしたらいるかも知れませんね(｀･ω･´)
さて、今日は給与と仕事の話でもしようかと思います。おちんぎん、増やしたいですよね？増えなくてもいいという人は居ないと思います。
今日はおちんぎんの増やし方をポエムします(｀･ω･´) あくまで社会人10年程度の中堅くらいのITエンジニアのほざきですので世間とは乖離している点があるかもしれません。ということを前置きとして。
「もらってる給与が少ないから頑張らない」
私Twitterで情報収集すること多いのですが、たまーに上記のニュアンスに近いことがRTで流れてくることがあります。 まあ気持ちも分かります。給与少ないのに仕事が増えてもやる気なんて出ない。人間、報酬に見合わない働きをするのは嫌ですからねー(´･ω･`)
毎月の給与という短期的な面の話をすると、給与分の働きしかしないこと自体悪いことではないです。使用者との労働契約に基づき、労務を提供してその分の賃金をもらう。労働者の権利ですよね。
『短期的な面』と書きました。私個人的な考えとして、「もらってる給与が少ないから頑張らない」は勿体ないことをしているなー、と感じます。もらっている給与以上の仕事をするのは、毎月給与をもらうという面では損です。
しかし、給与以上の仕事をし続けることで大きな利益が手に入ります。それは『問題解決の経験値』です。
給与はどうやって決定されるのか
さて、ここで少し頭を切り替えましょう。一つ考えてみてください。給与はどうやって決定されているでしょうか？
すごく単純でみんなが知っている当たり前の話なのでサクッと進めますが、企業はその人が持っている能力にお金を払います。
では、その能力とは何でしょうか？もちろん業種や企業の大きさにより答えが変わる話なので、明確にこれだ！という答えはありません。
ただ、共通するのは『会社の問題を解決できる力』です。雑に言われる課題解決能力ですね。例えば、新規顧客を開拓するのがめちゃくちゃ旨い営業の方であれば既存顧客の売上が低迷している企業が欲しがりますし、例えば、我々ITエンジニアであればシステムの高速化・低コストを考慮した設計ができる人や、障害の調査復旧が早い人。といった会社が困っている問題を解決できる能力です。
もちろん、こんなスーパーな話だけではなく、検算が正確で絶対に数字間違わない、という人から見れば小さな能力でも企業が欲しがっている能力と一致していれば、それは課題解決能力として扱われます。
『問題解決の経験値』を得るためにやるべきこと
「もらってる給与が少ないから頑張らない」を貫き続けるとどうなるんでしょうか？
1番大きな問題は『問題に挑戦する機会が与えられないこと』です。振られた仕事だけを適度にゆったりこなしていく。会社としては契約どおりの仕事やってもらってるし、やりたがっているわけでもないのであれば、その手の仕事を与えることはありません。会社の問題を解決する仕事なので、解決に導ける人に渡すものですからねー。
(´・ω・`)まあ黒いところだと無理やり与えるなんてことありますけど(黒い企業出身者で、仕事出来ない人あんまり見ないのと関連あるかも)
企業は、会社の問題を解決できる能力にお金を払います。その経験を積めない以上、いくら長く勤めていても給与が大きく上がることはありません。(年数千円の昇給くらいはあるかもしれませんが)
冒頭で勿体無いと感じているのはこれが理由です。自分で自分の給与が上がらない選択肢を取っている。「もらっている給与が少ないから頑張らない」は給与を上げるために必要な経験を積み難いため、結果いつまで経っても給与が増えていきません。
こう考えてみると「もらってる給与が少ないから頑張らない」は、実は「頑張らなかったからもらってる給与がすくない」で因果関係が逆転しているのかもしれません。
結局どうすればいいのさ？
常にもらっている給料分のより多くの仕事をやることを意識しましょう(｀･ω･´) あ、もちろん同僚の仕事が終わらないから手伝う系の仕事はなるべく避けることをオススメします。得るものが小さすぎるので。
いえね、恩はうれるんですけどおちんぎんアップに繋がるかは運絡みです。(昔は手伝うタスクも喜んでやってたんですがあんまり感謝されないし、そのうち当たり前になるし、手伝った相手の手柄にされたりして自分のメリット薄かったので)
先輩や上司の”自分があまり経験したことないけど手伝える”ものを狙いましょう。給与は据え置きかもしれませんが、自分のやれることが増えていく。そうなると『問題に挑戦する機会』が与えられます。
そこで得た『問題解決の経験値』を武器に給与交渉するなり、転職の材料にするなり。その能力を欲しがる企業に対して売りつけられる自分の能力として使えるようにするのが大事(｀･ω･´)
終わりに
実は私も最初給与少なくてですね、18で東京に出て来た時は手取り10万前半くらいで大変苦労しました(´・ω・`)
最初の会社に7年居て最初の5年位、もらっている給与分の仕事しかやれてなかったんですよね。結果25でも手取りは18万くらいで、残業代で生活する日々でした。6年めくらいから意識してやれることを増やしていくために、開発のテスト環境を整備したりセキュリティインシデントの社内共有等やってみたりしたんですよね。
そんな感じでやれることを増やし、率先してやったことないことに飛び込むことを続けた結果、今があるわけです。 こんなポエムを書いておいて、めちゃくちゃ高給なわけではないんですが、東京来た時と比較して今は3倍以上のおちんぎんをもらえています。大変ありがたいことです。
普段「もらってる給与が少ないから頑張らない」と思いがちな方。これ効きますよ！！高いおちんぎんをGETするためにぜひチャレンジしていただければと思います(｀･ω･´)ゞ
あと、こんな話をしていると「年功序列で上がっていくから程々に働く」という論も出て来るんですよねー。こちらもうまく回っているうちは良いのですが、それなりに問題がある選択です。今日は長くなったのでまた次回にその話はしたいと思います。
