2018/12/30 あと1日で今年が終わるので振り返ってみる
早いもので今年もあと1日です。ここ数年で一番動きがあった一年だったと思いますな(´・ω・`)日本の中のことでもそうですし、私個人のことでもそうです。
今年はいろいろと環境が変わったりする一年でした。4年務めた会社をやめたり、今までやったことないEC系の会社に転職したり。入社してすぐリプレース開発にJoinして炎上と戦ったりと、新鮮な経験ができました。
後は、まあ住宅ローン背負ってしまったり( ﾟдﾟ)数千万が一瞬で口座を移動するあのヤバさを実感するなど。今後どう生きていくべきか改めて考える時期に来たのだと感じてます。
話は変わるんですが、今月の頭くらいから毎日ブログを更新する日課を課してきました。これまで気が向いたときにしか書いてなかったんですが、今後の人生考える上でアウトプットすることに慣れる必要があるんじゃないか？と最近特に感じてたんですよね。
度々、「今度は頑張って更新していくぞ！」とやる気を出したのですが続かず。なんとかいい文章を書こうという気負いも合ったかと思います。(8月-10月あたりの迷走っぷりはそのせいもある)
継続する意志を持って、まずはやってみる。それだけで20日ほど継続できる事実があるわけでして、やはり『やってみる』ことは大事。この学びがあるだけでも、来年はより成長できる一年になるんじゃないかな？と思います。
来年は今年以上に結果を出す一年にしたいです(｀･ω･´) 会社以外の成果をきちっと出して、自分の武器としていく。来年はそれを目指して生きていこうと考えています。
どんな一年になったか、来年の今頃改めて振り返る際に、期待以上の一年になったと感じられれば最高ですね。
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等無くても実現できるので、ものすごく小規模なら自前で書いたほうが楽かもしれませんよ。
