Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 自分への戒め。タイトルは極端だが、本気でそう思っている。 ※ 本記事は Google Chrome での開発を否定するわけではありませんし、可能な限り色々な ブラウザ/バージョン/OS で動作確認するのがベストです。が、ブラウザの挙動に依存する Website を作っており、全てのブラウザで確認する余裕が無い場合、 Google Chrome ではなく別のブラウザで開発する方がバグが早期に発見できるのでは？という甘えも許されるのでは？という提言です。 概要 例えば、 Chromium をベースとするブラウザ（以下 Chrome） で普段

Git の Hook を扱う husky というライブラリがあり、大変お世話になっていた。が、 v5 が登場してから、設定変更を余儀なくされた。 v4 とは大きく異なる設計思想のため、私達は今まで書いていた設定ファイルを変え、 .husky ディレクトリを作成し、 husky のコマンドドキュメントを読んで、確認した。 正直 husky v5 のこの変更には失望した。もちろん正当な理由が合ったのだとは思うが、このようなツールの設定変更に時間を取られたくないと思った。このようなツールにはドキュメントが存在しないくらいの方がちょうどいいと思った。なんでこんな大きなドキュメントがあるのか不思議に思った。 なんか同僚の PC で pre-commit フックが動いてないっぽい。そんでコードがフォーマットされてなくてイライラする。 OSS にプルリクくれる人にも申し訳ない。 しかも husky の変

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

動機 【AWS】 Fargate CLI + Terraform で Docker コンテナを動かす簡単なチュートリアル というのを書いたんですが、下記の問題点を感じました。 Fargate CLI のインストールが若干手間。 Fargate CLI を使うと、 Terraform だけで完結しないため、一部ハードコーディングが必要になる。 Fargate CLI は冪等性が無い。 SSL 証明書や Route53 周りは Terraform で設定したいが、 Fargate CLI で設定した値の取得には結局 aws-cli を叩く必要がある。 Fargate CLI でも設定可能だが、事前に Route53 で設定とかしないとうまく動いてくれなかった記憶があり、結局あんま信頼できなかった よって、最近は Fargate CLI は使わずに、 インフラ構築は Terraform に全て任

AWS の ECS Fargate を使って本番環境を構築していますが、 Terraform だけだと環境構築が若干複雑になるのが悩みでした。 そこで、 Fargate CLI と Terraform を組み合わせると、非常にシンプルでいい感じになりました。 [追記] 最近は、 Fargate CLI をやめて素の AWS CLI でやっています。 完全自動構築を目指す場合、その方が確実だな思いました。詳しくは下記。 AWS Fargate サービスを Terraform で構築、 コマンドラインからデプロイ [/追記] デモ: https://github.com/acro5piano/terraform-fargate-example 概要 Terraform を使って、 AWS ECS に必要な基本的な環境を構築する Fargate CLI で Fargate のサービスやタスク定義

Yarn workspaces から Lerna に移行した時の知見です。 やや書きかけ項目です。 前提 とあるサービスを提供しており、モノレポで運用している。使用スタックは主に API の Ruby on Rails で GraphQL の API サーバーを構築し、そのフロントエンドを React/ReactNative で作成している。 もともとは別々のリポジトリだったが、提供サービスが増えてくるに従い、下記の問題点が出てきた。 CI/CD パイプラインを一々作成する必要があり、反映にも手間がかかる GraphQL の型定義やユーティリティ、細かいところでは Git の Hook など、再利用したいものがある GitHub への招待などが手間になる そこで、この記事を書く半年前くらいにリポジトリを統合し、モノレポになった。 Rails と それ以外 (TypeScript) でフォル

「辛かった」と書いていますが、実際にはまだ「辛い」です。 Apollo の導入を検討している方の参考になれば幸いです。 [追記 2021年4月] 本記事を書いた時点(2019年9月)では、私の Apollo Client の理解が浅かったのが原因でした。コメントで仰って下さっている通り queryWrite 等のキャッシュをちゃんと設定すれば、大半のケースでは問題が無いと思います。 ただ、 Apollo Client で辛いと感じている方がいるのは事実で、特にキャッシュの部分はこちらの記事でも言及されていました。 個人的には、現在は URQL で additionalTypenames をちゃんと使ってます。 Refetch を自動的に行ってくれるので最高です。 [/追記] 概要 React Native + TypeScript のプロジェクトで Apollo Client を使ってみた

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?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 海外のスタートアップのコーディング面接を受ける機会があったので、やっておけばよかったなーと思うことを忘れないようにメモっておく。 なお、まだ受かったかどうかの連絡は来ていないので、参考程度にして頂ければと思う。合否は追記したい。 （一応、 Qiita の方針に従うために、 React の説明入れた） 前提 ベルリンのスタートアップ React のちょっとした問題を出された この会社では1次面接は自己紹介で、2次面接がコーディング面接だった appear.in + Codepen で面接した 所要時間 1時間20分 （多分もっと早く終るは

Laravel と組み合わせて、 GraphQL サーバーを本番運用しています。 Lighthouse というライブラリを使うと、手軽に構築することができました。そのときに溜めた知見です。 結論 Laravel + GraphQL は、 Laravel の柔軟性と GraphQL の堅牢性がいい感じにマッチしている Laravel で GraphQL やるなら、 Lighthouse 良い Schema をダンプしてチームでシェアするといい感じになる GraphQL を現実世界で使う GraphQL を使う動機としては、下記があると思います。 型安全な Web API を作りたい 入出力を明確にしたい フロントとサーバー間の仕様書を、動いているコードから明確に作りたい ただ、障壁となってくるのが 既存のサービスのロジックを使いまわしたい 徐々に移行したい。三ヶ月かかります、みたいなのはきつ

Mint という、 SPA のための新しいフレームワークがあり、まとめてみた。 2018/07/25 現在では、 Alpha Stage である。 いつかちゃんと使ってみたい。 特徴 SPA に特化している 一つのファイル (モジュール) に、 HTML / CSS / JS を書く React + CSS Module っぽいかも Store をデフォルトでサポート ルーティングもデフォルトでサポート 関数型っぽい書き方のサポート Pipe 構文 Case 式 静的な型（ record と呼んでいる）サポート Crystal で書かれており、JSに依存していないっぽい？ package.json の代わりに mint.json 依存が少ない 全て Built In なので、 なんとかloader みたいな概念が無いっぽい パッケージマネージャなどの拡張はこれからのよう 例 HTML を出

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

ZEIT が作っている Micro という Node.js のフレームワークがあり、使いやすそう。 ZEIT は、かの Next.js を作っていて、 Mongoose を作った人や socket.io を作った人が所属しており、とても信頼できる。 ちなみに、 ZEIT は Now という、 Node.js （及び Dockerized されたもの）を動かせる、サーバーレスのサービスもやっている。 ZEIT(時) と Now(今) という世界観が良いですね。 初動が早くて、快適だった。 [追記] 何かに Micro 8 と書いてあって、最初、そういう名前のフレームワークと思ったのですが、実際は 8 はバージョン名で、 Micro のようです。また現行バージョンは9でした。 多分これ https://zeit.co/blog/micro-8 [/追記] Features README の F

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? dev.to を見ていたら、 #impostorsyndrome というタグがあり、 #shecoded でもけっこうみんな Impostor Syndrome に苦しんでいたという記述がありました。 調べてみたら、 Impostor Syndrome （詐欺師症候群） に陥っている方は多いんじゃないかと思い、というか自分がまさに当てはまった気がしたので、エンジニアの視点でまとめてみます。 Impostor Syndrome とは wikipedia によると インポスター症候群またはインポスター・シンドローム(英: Impostor

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

Metabase、まじでイケてる。 1日で、Re:Dashから乗り換えました。 Metabaseとは OSSのデータ可視化ツール。Re:Dashとかと同じ類。 AWSとかに乗せて、誰もが見れるダッシュボードを作ったりする時に使うと、俺かっけーってなります。 スクリーンショット 実際に社内で運用している様子をモザイク付きでお見せします。 毎日みているダッシュボード。これの4倍くらいの数値見てる。 ダッシュボードの編集。マウスで簡単に位置や大きさの変更ができる。 クエリビルダー的なやつがあり、グルーピングとか超絶便利。SQL書けない人でも、単一テーブルとかだったら余裕かと。 グラフ化も簡単。 SQLでのクエリ編集画面。ちゃんと補完してくれる。 Metabaseの良い所 見た目が格好いい。 インストールが簡単。 openjdk-8-jdk入れて、jarファイル置くだけ。 豊富なデータソースに対応

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?

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?

先日、フロントサイドのバリデーションにはvalidatorjsが便利という記事を拝見し、現在作っているシステムで使ってみようとしたのですが、挫折しました。 理由としては、複雑なフロントを作ろうとしているためで、下記の要件を満たす必要がありました。 1:n のデータで、ユーザーが追加できる要素がある (例: 複数メールアドレス登録) ページローティング直後はバリデーションしない ユーザーがインプット開始時に、 入力中の要素のみ バリデーション フォームを送信する直前に 全ての要素 に対してバリデーション エラーのある要素は赤くする エラーのある 要素の直後 に、 「メールアドレスは必須項目です。」などというメッセージを表示 バリデーションのルールは一箇所にまとめたい。入力中と送信時でほぼ使いまわしたい。 そこで見つけたのが VeeValidate です。 素晴らしかったので使い方を書いておき

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?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Laravel 5.4 と Vue.js 2.2 と JWTAuth で、ログインできる SPA なTODOアプリを作ってみました。 結構本気で作りました。 Laravel + Vue.js はかなり作りやすく、サーバーサイドの処理が少ない＆分かりやすいので楽しかったです。 自分の記憶の定着を上げるため、チュートリアルを書きます。 JS初心者なので、おかしいところとかベストじゃないところが多々あると思いますので ご指摘頂けたら嬉しいです！ 作ったもの ソースコード デモサイト 目次 四部作です。 はじめに ← 今ここ 基本的な概念の説明

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

Docker を使って開発環境を作ると、手軽に自動化できて便利なのだが、 Docker コマンドをいちいち発行するのが面倒になる。 例) php artisan serve => docker-compose exec web php artisan serve rails s => docker-compose exec web rails s alias dc='docker-compose' としても、まだ長い。 そこで、 Docker を使っているプロジェクトについては、下記の様な構成にした。 project-root/ |-- bin | |-- composer | |-- gulp | |-- node | |-- npm | |-- php | `-- yarn |-- docker | |-- nodejs | `-- web |-- artisan |-- compos

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