はてなブックマーク

この記事は GraphQL Advent Calendar 2020 10 日目の記事です。 前回の記事は @mtsmfm さんの Swift 用 graphql-codegen plugin の graphql-codegen-swift-operations を作った でした。 はじめに PrismaはGraphQLを実装するためのクライアントライブラリ,ORM(Prisma1においてはGraphQLサーバ自体も含む)として広く知られていると思いますが、Prismaはversion2(以下、ただのPrismaと書いている箇所はPrisma2を指します)より、ORM部分に注力し、GraphQLとは直接関係ない方向に成長していく方向に舵を取っています。 (参考: https://www.prisma.io/blog/prisma-2-is-coming-soon-mwwfhevie993)

この記事はfreee Engineers Advent Calendar 2016の5日目です。 こんにちは、freeeのエンジニアの @joe-re です。 僕からはflowtypeによる、Fluxアーキテクチャへの型システムの導入についてお話しさせていただきます。 背景 Reactによるコンポーネント指向設計、Fluxによる単方向フローによって、僕たちは階層化されすぎているViewにおけるイベントの発行と購読、煩雑なDOM操作と状態管理から解放されました。 Fluxアーキテクチャにおいては、Component、ActionCreator、Storeがそれぞれの層で完全に分離されています。StoreはComponentの存在を知らないし、ComponentはStoreを購読するだけで中のロジックは一切知らないし、ActionCreatorはただの関数群です。 チーム開発の中でこの関係性を

背景 ひと昔前までフロント側build toolと言えば grunt が主流でしたが、今は gulp が主流になりました。 gulpは現在のところ3.9が最新ですが、水面下では4.0が準備中です。 4.0は久しぶりの major version release だけあって、結構な breaking changes が含まれる予定です。 4.0がいつリリースされるかは分かりませんが、 4.0 branch は用意されていて、そのほとんどの機能はもう動かすことができます。 本エントリではchangelogを見ながら、その機能を実際に試していって、どういったものか説明していこうと思います。 今回書いたコードはgithubにあげたので、もし試したい方がいればどうぞ。 資料 changelog API document バージョン $ ./node_modules/gulp/node_modules

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 僕が本格的にWebのエンジニアになったのは2014年頃からで、早いものでもう丸2年ほど経ってしまうことになります。 Webに転向してからは主にフロントエンドエンジニアとして勤務してきました。 よく言われることですが、最近のフロントエンドの趨勢は本当に早いです。 最初はキャッチアップに苦労したことを覚えています。 しかし段々と新しい何かを覚えることは苦でなくなり、今はこの流れに身を置くことが楽しいと思えるようになってきました。 激動の趨勢の中で、Webのフロントエンドエンジニアが口にするパラダイムは日ごとに変化しています。 この記事

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは、freeeでフロントエンドエンジニアをしている @joe_re です。 freee Engineers Advent Calendar 2015の4日目を書きます。 僕からはfreeeで現在進行中の革命について、フロントエンドのビルドプロセスを中心に書こうと思います。 革命 ってなんのこと？ というのはフロントエンドヤンキーこと @ymrl が 2日目で書いたので詳しくはそちらをご参照頂ければ幸いです。 背景 弊社ではRuby on Railsを主軸にしてWebサービスを作っています。 Railsは素晴らしいフレームワークで

背景 gulpでフロントエンドのビルドプロセスを組んでいるならSprocketsを通さなければ良い。 と言いたくても、なかなかそうすぐには完全移行はできず、ビルドしたものはapp/assets/配下に出力して最終的にはSprocketsさんにどうにかしてもらっている日々を過ごしています。 そんな中でscssのビルドをgulpに移行したのですが、Sprocketsでは.cssファイルではimage-urlやasset-urlなどのhelperメソッドが使えず、imageのasset_pathが解決できません。 とはいえ、せっかくフロント側でlibsass使ってビルドしたものを.scss拡張子に戻して、再びSprocketsのScss Processorにかけるなんてリソースの無駄すぎて嫌だ。(libsassに比べると、ruby-sass遅過ぎる。) じゃあ無理やり.css.erbに変換するか

小さいアプリケーションなら、styleは変更がある度に毎回フルビルドしてしまっても1sもかからないかもしれない。 しかし大きくなって、5s以上かかると非常に苦痛だ。 というわけで差分ビルドしたい。 Sassの差分ビルドで問題になること 差分ビルド自体は簡単で、gulp-cachedとかを使えば、前回と差分があるものだけをビルドできる。 なんだけど、その場合に問題になるのがsassの依存関係(@import)の解決だ。 単純に差分のあったファイルをビルドするだけだと、@import元を辿れない。 そうすると@import元のファイルが変更についてこない。 いや、でもnode-sassのwatchオプションって@import元辿ってるよな、あれってどうなってるんだ？？ と思って実装を見てみたら、sass-graphというnpmを使って辿っていた。 お、これ使えば差分ビルド時に依存関係の解決もで

はじめに react-railsという、ReactをAsset Pipelineに乗せて使えるようにしてくれるruby gemsがある。 この記事では、これを使用してReactの公式tutorialを進めていく。 公式のtutorialではサーバ側はすでに実装済みとして進んでいる。 今回はせっかくなのでtutorialを進める中でサーバ側も実装していくことにする。 ちなみに使ってみた個人的な感想としては、RailsのAsset Pipelineに乗せるならすごく順当かなー、という感じ。 browserifyを使いたい。bowerもオワコンと呼ばれてしまう。そんなこの時代。 Asset Pipelineは捨てたい感じがあるけど、既存のアプリケーションを徐々にReactコンポーネント化していく、みたいな時には良いと思う。 方針 きまぐれで、必要そうなところはReactの説明する。けど英訳とかは

軽く使ってみたら意外と好きになれそうだったので、メモ的に残しておきます。 初期設定〜vimモードを入れてみます。 設定 Atomをインストール Atom atomのシェルコマンドのインストール メニューよりAtom → Install Shell Commands vimプラグインのインストール atomではなく、Macのターミナルより下記コマンドを実行します。 apm install vim-mode Atomの再起動 escキー押下時に日本語入力をやめて英数入力にする インサートモードを抜けたときに日本語入力のままだと発狂しかねないので。 KeyRemap4MacBookを使用します。 vimでも同じ設定をしていたので、com.github.atomを追加するだけでした。 Misc $ Uninstallタブを選択し、Open private.xmlを押下。 XMLの編集 Change

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?