今まで自分で作ったものが十数個、仕事で5社ぐらいの redux を見てきたので、その結果思うところを書く。 前提として、自分はエコシステムに乗るという意味で今では redux 肯定派だが、redux それ自身が過剰に抱えている複雑さはもっと分解されるべきだ、という立場。 Redux がうまく設計されているとどうなるか 一貫した一つの設計論に従うので、考えることがなくなる 難しさが廃されるのではなく、難しい部分が一箇所に集中する。React Component の末端では、何も考えることがなくなる。状態管理という難しい部分を作る人と、末端のコンポーネントのデザインに注力する人を分けられる。 大規模になっても設計が破綻しにくい、というエンタープライズ向きな特性を持つ。が、その技術基盤は(静的)関数型由来の考えが多く、基礎設計や基盤理解にはハイスキルが要求され、需要と適用対象のミスマッチを感じる

はじめまして。アプリケーションエンジニアの中野です。 以前、MicroAdのデータ基盤の記事で紹介されていましたが、マイクロアドではデータ基盤刷新のタイミングでワークフロー管理ツールのDigdagを採用しました。 今回の記事では、Digdag採用の経緯やワークフローを作成する際に注意した点を紹介します。 Digdag採用の経緯 マイクロアドのDSP*1であるBLADEではBidRequestやImpression*2、Click、Conversion*3、その他BLADEから出力される様々なログやマイクロアドの他のプロダクトのログ、他社から提供されるデータなど、様々なデータを広告配信最適化の分析に活かしています。 これらのログを分析するバッチ処理は各々のジョブが複雑な依存関係を持っています。 これまではcronやJenkinsを用いてこれらの処理を行っていましたが コード管理が出来ていない

（「API仕様を書く（6）ー gRPC protoファイル（2） ー」からの続き） きちんとしたAPI仕様を書いていない場合、そのAPIのテストコードは当然のことながら、正常ケースだけだったり、不正なパラメータが渡されたときにどのように振る舞うかは実装のソースコードを見ないと分からなかったりします。さらに、「エラー翻訳」（「例外翻訳」）を行っていない実装は、いつのまにか返されるエラーが変わってしまっていることも起こり得ます。 おそらく多くの大学ではAPI仕様の書き方も含めてAPI設計の教育は行われていないと思います。そして、社会人となってから、個々のソフトウェアエンジニアがAPIの仕様をどの程度記述するかは、その人が属したソフトウェア開発組織の文化に影響を受けると思います。 私自身、gRPCを用いたソフトウェア開発では、前職のソラミツが初めてでした。そこでは、protoファイルには何も仕様

はじめにGCP のサービスにプログラムからアクセスするためには必ず認証・認可が必要ですが、以下のような様々なコマンドや概念が出てくるので少しとっつきにくい印象があります。 gcloud auth logingcloud auth application-default loginService AccountApplication Default Credentialsこれらの概念は認証・認可のベースとなっている OAuth2 の文脈で眺めてみると全体像が理解しやすくなるので、本記事でまとめてみたいと思います。 GCP での認証・認可GCP の認証・認可は一部(*)を除いて全て OAuth2 ベースでやり取りされています。(* API Key) OAuth2 は三者間の手続きです。 3-Legged OAuth2Client が Resource Owner の代わりに Resource

某社で自分が React/Redux + TypeScript などの講習をやってみた結果、TypeScript 入門用資料が必要だと思って書いたやつです。 このドキュメントのターゲット TypeScript で書かれたプロジェクトに参加する人 TypeScript を導入するために、その事前知識が必要な人 このドキュメントの読み方 ES2015 for Beginners ES2015 for ES5 Programmers ES Modules 非同期表現: Promise と async/await TypeScript エコシステム編 自分が React/Redux などの講習でいろいろやってみた結果、 ES2015 と TypeScript を同時に教えると、初学者は何がどの概念に由来するかの区別が出来ずに混乱します。なので、ES5 -> ES2015, ES2015 -> Ty

尽く書を信ずれば即ち書無きに如かず 《孟子『尽心下』より》 イントロダクション 「最も理想的なオブジェクト指向を実現しているプログラミング言語は何か？」と問われたとき、君は何と答えるだろうか？ C++、Java、C#。君がそうだと思っているのは表面だけで、たぶん何もわかっていないのだろう。無知であることを知っているのであれば、無知のまま過ごした方が幸せなときもある。 Simula、Smalltalk、Ruby。君は本質をいくらか知っているようだから、引き返すなら今のうちだろう。深淵を覗けば、君もまた怪物にならざるを得ない。 JavaScript、Python、Go。君が真剣にそう答えるなら、私とは異なる真理に辿り着けたのだろう。君と私のどちらかが正しいのではない、どちらも常に正しく、どちらも常に間違っている。 Erlang、Elixir。君は既に答えを知っているようだから、この記事は全く以

Last week at Vue.js London I gave a brief sneak peek of what’s coming in the next major version of Vue. This post provides an in-depth overview of the plan. Why a new major version?Vue 2.0 was released exactly two years ago (how time flies!). During this period, the core has remained backwards compatible with five minor releases. We’ve accumulated a number of ideas that would bring improvements, b

ジョブキューイングシステムをどうするかでチームのリーダーとやりあって考えたことがあるのでまとめておく。 Rails で使うジョブキューイングシステムの技術選定で、リーダーは Amazon SQS 推し（レガシーシステムで SQS を使っている）、自分は Sidekiq 推しだった。前職時代に Sidekiq を使ってトラブルに遭遇したことはなかったし、とても簡単に使えるので Sidekiq で十分だと思っていた。 Sidekiq は GitHub でのスター数は 9000 オーバーで、 Rails の ActiveJob バックエンドとしては事実上のデファクトスタンダードだといえると思う。ググれば情報がいっぱい出てくるし、チームメンバーもリーダー以外は全員 Sidekiq の使用経験があった。 GitHub - sidekiq/sidekiq: Simple, efficient back

当社の規定により満60歳で定年退職をした。長いようで短かった会社員生活も一区切りだ。自分のプログラマとしての会社員生活を振り返ってみる。無駄に長いし結論はないのでお忙しい人は飛ばして欲しい。 9月末なのでブログ界隈では退職エントリーがそこかしこに書かれると思うが、その中で自分の退職エントリーを連ねることにどれほどの意味があろうか。もちろんないのだが、それでも多くの書き手の年齢を考えると満60歳定年退職というところに若干の希少価値を見出せなくもない。 1984年に大学院修了して以来、プログラマとしてのキャリアを重ねてきた。大学時代の同期でプログラマとして就職したものは皆無だ。当時、工学部の同期はメーカーに就職するのがほとんどで、大手家電メーカー、自動車メーカー、電力会社などなど、当時の誰でも名前を知っている人気企業に就職するものが大半だった。 その中で、日本ディジタルイクイップメント（DEC

ServerlessConf Tokyo 2018 の登壇資料です。 https://gs2.io/

以下、普段と違いプログラミングの話題があまり出てこない、あくまで個人が育児休暇取った話を書くだけなのでご注意(?)ください。 最後の方に少しだけプログラミングの話出てきます。 まず時系列での大まかな流れ 2月後半に生まれる ↓ 妻の入院中は数日休んで、病院通ったり役所行くなどする ↓ 3月いっぱいまでは働く(妻はそのあいだ妻の実家) ↓ 4月から半年間育児休暇 ↓ 9月いっぱいまで休みで、10月から復帰予定 (ｲﾏｺｺ という感じです。 そもそも育児休暇とは？とか、そのあいだのお金のこととか、ググればいくらでも正確なわかりやすいサイト出てくるはずなので、詳細に説明はしませんが、簡単に書くと 国が決めてる制度なので、原理的には会社によらず、一定の条件(一定期間勤務してるなど)を満たしていれば、男女関係なく1年くらい取れる(細かいことはもっと色々ありますが) その間の給料は"会社からは"出ない

libuv/core.c at v1.x · libuv/libuv Cross-platform asynchronous I/O. Contribute to libuv/libuv development by creating an account on Git... タスク タスクは、同期タスクと非同期タスクの 2 種類存在します。 setTimeout(() => console.log(1)); setImmediate(() => console.log(2)); process.nextTick(() => console.log(3)); Promise.resolve().then(() => console.log(4)); (() => console.log(5))(); 同期タスク (() => console.log(5))(); 非同期タスク setTim

受託の仕事がひと段落したので、現実逃避がてら内容が古い・良くない社内図書の整理を行っていた。整理しながら「そういえば基礎教養部分の社員教育カリキュラムがまったく準備できてないなぁ」と思い、社内図書をベースに教育用に課す本を考えてみた。 以前から「日本語作文能力が足りない～」と言ってきていたのだが、それに対しての現時点の暫定解がこれかなぁと思っている。 世界一やさしい課題解決の授業 世界一やさしい問題解決の授業―自分で考え、行動する力が身につくposted with amazlet at 18.09.25渡辺 健介 ダイヤモンド社 売り上げランキング: 402 Amazon.co.jpで詳細を見る とりあえず最初に読む本。ごく当たり前の話がサクっと書いてあるが、意識がないと全く身についてない話でもある。 読むだけなら数時間（読むのが早い人であれば、30分もあれば読める）、演習もやるなら1日～

JWTを使うことは難しい？ こんにちは、かとじゅん(@j5ik2o)です。最近、JWTに関する以下のブログが話題です*1。 どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ - co3k.org このブログで言及されているのは、JWTをセッションの保存先に選ぶことで「何が問題なの？」に書かれているリスクがあるよ、という話*2。確かにいくつか検討することがありますね。 auth0.hatenablog.com auth0の中の人？よくわからないけど、反論的なブログエントリが公開されています。この記事では、指摘の問題が起こらないように設計するのはあたり前では？という意見みたいです。まぁごもっともではないでしょうか。 私も技術そのものというより、要件に合わせて技術を組み合わせる設計の問題だと思っています。加えて、JWTを利用することはそんなに難しいことかという疑問があった

9月22日：ドメイン喪失から3年半……daruyanagi.net がもどってきました（もう水素水を売ってるヤツだなんて言わせない！！ 2015年4月：daruyanagi.net を失う blog.daruyanagi.jp daruyanagi.net のドメイン更新手続きを失念していて、所有権を失う。当時、このドメインは Value-Domain で管理してもらってたのだけど、「お金をチャージして更新手数料を払う」というちょっとめんどくさいシステムだった。クレジットカードがなかった高校生時代、XREA サーバーでお世話になってたころはそれがありがたかったのだけど、この時はさすがにちょっと Value-Domain を呪った……クレカで自動更新できたらよかったのに！*1　通知メールがスパム扱いされていて、完全に気付かなかった。 他にもドメインはもっていたのだけど、daruyanagi.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

以前「転職ドラフトで1000万円超えのオファーを2度貰ったエンジニアが「評価された理由」と「正社員で働く意味」について考えてみました。」という記事を書いたのですが、転職ドラフトと同様な「年収確約型のエンジニアスカウトサービス」としてmoffersというものがあります。 転職ドラフトがここ最近非常に盛り上がっているのに対してmoffersはかなり知名度が低いのですが、現在開催中のmoffersで、転職ドラフトでも頂いたことのない「年収1200万円」という高額オファーを頂きましたので、若いエンジニアの方たち(特にバックエンド系の方たち)の今後のキャリアプランのご参考になればということで、moffersに登録している業務経歴をそのままのフォーマットで公開したいと思います。 ちなみにmoffersでは下記のような感じでオファーが届きます。(黒塗りですみません) 業務経歴1：【Kotlin/Vert

ビッグデータ処理データベースを分類し、2018/9時点で最新のプロダクトを紹介しています。Read less