補足：2021年6月 結構昔に書いた記事ですが、今でもたまにアクセスがある（ありがとうございます）ようなので使命感に駆られて追記。 本編の冒頭にもあるように、これは2018年の記事です。なので色々と書いてますが、2021年の人間の立場からTypeScriptの導入について申すのであれば一言です。 使いましょう。 もはや「TypeScriptを使う理由」とか言ってる時代はとっくの昔に終わっています（Elmとかそういう、他の型付きAltを使いたいなら別ですが）。 もちろんstrict mode一択ですからね。 当時は採用云々とか書いてましたが、逆にいまTypeScript書けるかどうかってのはフロントエンドエンジニア採用の足切りラインとしてちょうどいいくらい（書けるってのが程度かにもよりますけど）だとおもいます。 好き嫌いはともかく、TypeScriptを使えないエンジニアを雇ってもフロントエ

前職を辞めてフリーランスになって3ヶ月がたったので振り返ってみる。 とりあえず楽しい 前職は前職で好きなサービスだったので、辞めるという選択をするにあたっては悩んだものだが、今は非常に楽しく過ごしており、(少し残念ながら)辞めて良かったなと思っている。 決して前の生活が楽しくないわけではなかったが、今はより楽しい。昔から簡単な日記というか日々のログを残しているのだが、明らかに辞めてからの毎日が充実している。 何が楽しいかをもう少し書いてみる。 コードを書くのが楽しい コードを書いてるのが楽しく、ここ3ヶ月の平日朝夜や休日は基本的にずっとコードを書いたり本を読んだりしている。 ここ最近触れた技術のキーワードを雑に並べると、nuxt, react, atomic design, storybook, web component, web animation, netlify, firebase

この記事はJX通信社Advent Calendar＆GraphQL Advent Calendarの1日目です。 JX通信社でNewsDigestというアプリを開発しているyamitzkyです。 NewsDigest では、アプリから利用する API に GraphQL を利用 しています。本番での利用を始めてからちょうど１年を過ぎました。 JX 通信社ではプログラミング言語として Python が使われることが多く、この GraphQL API も Python で作ってサーバーレス環境(AWS Lambda)にデプロイ していました。しかし、Lambda では要件が合わなくなってしまったため、現在では Amazon ECS で作った Docker クラスタ内で動いています。また、非サーバーレス化に合わせて、パフォーマンス要件を満たすために Go でのリプレイスを行いました。 この マイ

DDD的なことを今後進めていく上で、自分として課題としている論点をまとめてみた。あくまで私の現時点での理解度を前提に、そこでの個人的課題感を取り纏めてみたものなので、不足や誤りや過剰が多々あるだろうがご容赦を。そして、アドベントカレンダーの初日、続く議論の礎となり、3人の賢者24人の荒ぶる者によってベツレヘムの星が見出されることをただ願うのである。 ◇ あらまし DDDのいわゆる戦略の言う“広義のドメイン”と、戦術パターンにおける“狭義のドメイン”。この二つの用語は、実のところ「異なる境界付けられたコンテキストに属する語彙」として扱った方がよいのではないか？ 参照系と更新系は、その本質として非対称性があって、参照系向けの新たな戦術パターンが必要なのではないか？ 「コンテキスト」は、強く分離する上位階層から緩く分離する下位層まで、多段階の階層構造に在ると捉えるべきではないか？ （「3.」を前

Cloud hosting providers, like Amazon AWS, makes it easy to build and scale your infrastructure. But if you are in a fast growing startup you know that balancing performance and cost can be complex and time-consuming. There are many layers of the stack that can be adjusted and lots of decisions: Optimisations in application code.Caching, which itself has lots of options (HTTP, page, action, fragmen

ヘルスケアのプラットフォームを運営する株式会社FiNC Technologies（以下、FiNC）。ジムの人気トレーナーだった溝口勇児氏が「より多くの人にヘルスケアを広めたい」という想いで2012年の4月に会社を設立しました。2017年3月にオープンしたヘルスケアアプリ「FiNC」は、既に400万ダウンロードを突破し、ユーザーから高い評価を得てたちまち大きな話題に。ほかにも、美や健康に関連した商品を販売するECモール「FiNCモール」の展開や、実店舗のパーソナルジム、エステも都内に5店舗出店するなど、ヘルスケア業界に新しい在り方を提案しています。 FiNCの事業の根幹となるのが、やはりアプリ開発。総勢約50名という大所帯の技術開発部は、全員が会議の議事録などを共有するためのドキュメンテーションとして、このほどScrapboxを導入しました。 これまでさまざまなドキュメンテーションツールを使

Node学園祭2018「貢献できるOSSの見つけ方 -完結編-」 https://nodefest.jp/2018/schedule.html#conference-2-9 紹介しているアプリケーションはこちら https://github.com/ohbarye/goofi https:…

builderscon2017の発表資料です。 https://builderscon.io/tokyo/2017/session/182ba13a-ccd5-4ddd-9565-c4e20df1d871

ある程度アプリケーションの規模が大きくなってくると、ある変更がどこまでの影響範囲だと思っているのかがコミュニケーションにおいて重要

Chrome Dev Summit に初参加しました！色々トピックとして気になったものを紹介してます。後直接 Addy Osmani とか Paul Irish とかに聞く機会があったので、色々ついでに聞いてきました。 Chrome DevRel teams create a Chrome cake #ChromeDevSummit [pic.twitter.com/5u6VPZ0oHb](http://pic.twitter.com/5u6VPZ0oHb)— Yosuke FURUKAWA (@yosuke_furukawa) November 12, 2018 Chrome も 10 周年なんですよねー。感慨深い。 1日目は「現在のChromeでできること、やってること」という感じで、ケーススタディやツールチェインの話が多めでした。 2日目は「未来のChromeでできること、今後やるべ

ソフトウェアエンジニアリングと一見関わりはなさそうで、しかしチームで成果を出す過程においてとても重要だと筆者が考えているコンセプト、 "Working Out Loud" について書いてみます。 日本語の記事がほとんど見当たらないのであまり知られている言葉ではないかもしれません。 対象読者 以下に興味や関心を持つ方を対象読者として想定しています。 チーム開発におけるコラボレーション手法 チーム開発者としての振る舞い方 テックリードやスペシャリストの育成 が、本心ではチーム開発する全ての方に届いてほしいです。 まえがき ある夜に同僚の@ujihisaと近場ないし遠方のEngineering ManagerやVPofEの皆さんと話す機会があり、その折にふと筆者がこぼしたのが 「開発などの日常の業務において自分がやっている以下の思考様式が大変便利なので、この考え方を最近入社したメンバーにもインス

先日設計Nightというトークイベントに行ってきました。これは元々、 @shinpei0213 さんがBuildersconで話した内容についてのスピンオフ企画。忘れてしまいそうなのでメモがてらアウトプット。まずは登壇者の方々の資料を貼る。 nekogata.hatenablog.com YouTubeに講演動画上がってました。 @moznion さんの発表資料 speakerdeck.com @magnolia_k_ は公開資料作成中らしいですが、確かにこの1枚に凝縮されてます。 今日の発表、ほぼこの一枚でもいいんだけどね#sekkei_n2018 pic.twitter.com/brQlsQLYD7 — magnoliak (@magnolia_k_) November 8, 2018 コードには How テストコードには What コミットログには Why コードコメントには Why

Vue Fes Japan 2018 Reject Conference で話しました #vuefes_reject https://vuejs-meetup.connpass.com/event/97557/

MIAUは、2018年11月9日（金）に開催された文化庁第18期文化審議会法制・基本問題小委員会（第4回）で静止画ダウンロード規制についてヒアリングを受け、意見を述べました。 内容は以下の通りです。 平成30年11月7日 一般社団法人インターネットユーザー協会 静止画ダウンロード規制への考え方 当会は静止画ダウンロードの違法化に反対する。理由は下記のとおりである。 まず、静止画ダウンロードに関する規制を考えるならば、その議論の前提となる立法事実を整理する必要がある。「漫画村」に代表される大規模な海賊版サイトが社会的な問題となり、これに如何に対応するかという議論であったことは記憶に新しい。しかし、静止画のダウンロードを違法化することは、手法として誤りである。 問題となっているサイトはブラウザを使って画像を表示させているに過ぎず、閲覧者は「法的な意味でのダウンロード行為」を行っていない。つまり

マイクロサービスの設計に対して、どう設計原則を使うのか、という話をしました。本稿では、資料中のいくつかの点に補足したいと思います。 SRP (単一責任原則)単一責任原則原則について、提唱者である Robert C. Martin 氏が2014年にさらに考察している記事を紹介しました ( The Single Responsibility Principle )。 この中では、変更する理由は「人」であるということに強くフォーカスされています。この考え方は、マイクロサービスの現実の問題に非常にマッチするため、今回取り上げました。ただ、筆者個人の考えではつねにこの「人」にフォーカスするのが常に現実の問題を解決するのに役立つかは疑問で、場合によっては受け取り方には注意が必要かなと思います。単一責任原則は、この追記がなくても長く大事にされてきたものです。 マイクロサービスの統合マイクロサービスをどう

サーバー間 GraphQL と webmock-graphql の話 / server-to-server graphql and webmock-graphql

主にUI設計やプログラミングのAPI設計について、「わかりやすい」というのは主観的で合意が取れないのでクソという話。 定量的な指標が示されてない そもそも趣味が合わない場合はそこで終わり 〜の本来意図された機能が隠れてしまっている ↑によって隠れてしまった機能を呼び出すのが、最終的にコストが掛かる 何が言いたいかと言うと、「指標の伴わない変更に意味はない」「APIの呼び方を変える程度のラッパーライブラリやヘルパーには、特に意味がない」ということです。 ここからプログラミングの話に絞りますが、特にショートハンドしたいだけの場合、ショートハンドするAPIの実装は、必ず本来の機能を呼び出す脱出ハッチも必要となります。 よく練られていない「わかりやすさ」は、次第にこの脱出ハッチを使うことを要求するようになり、結果として捨てられることになります。この破棄までの過程は、結果的に「技術的負債」と表現され

AWS Dev Day Tokyo 2018についてAWS Dev Day Tokyo 2018 は、2018/10/29（月）から11/2(金）まで1週間にわたり開催されたイベントで、アプリケーションデベロッパーのために世界主要都市で開催される、テクノロジーカンファレンスです。クラウド上でのアプリ開発における最新のテクノロジーとトレンドを、40 本のテクニカルセッション、10 コース以上のテクニカルハンズオンや、そのほかの様々な企画を通じてキャッチアップできるラーニングイベントです。 今回は最終日の11/2（金）に行われたMicroservicesに関するテクニカルセッションの1コマとして “Micro Frontends”（マイクロフロントエンド） をテーマに登壇させて頂きました。 登壇について発表については当日の資料を公開しているので以下から御覧ください。 Micro Fronten