はてなブックマーク

Contentful is not a CMS, Contentful is content infrastructure. Webサイトがシンプルで見やすい。 ものは言いような気もするけれど、CMSではなくContent Infrastructureらしい。 ドキュメントも見やすくて素敵。 https://www.contentful.com 無料で使える範囲と制限 https://www.contentful.com/pricing/ アカウントの作成時に、MICRO SPACEというものをひとつ割り当ててもらえます。個人で使う分にはMICRO SPACEで事足りそうなので、かなり気前がいい印象です。 24個のコンテンツタイプ 5000個のレコード 10人のユーザー 1つのロール（ユーザー権限） 2つの環境（master/stagingとか） 2つのロケール（多言語対応） ※ 2018

AWSとCircleCIの力を借りて、Nuxt.jsで作った静的サイトの運用をできるかぎり自動化した話です。 3ヶ月ほど前からCIのサービスを使うようになり、入門記事はたくさんあって助かったのですが、具体的にどんな感じで使っているかの情報が少なかったので記事にしました。 もしかしたら、CIの使い方が間違っているかもしれないので、そのときは優しくコメントをいただけたら嬉しいです。 できあがった流れ 毎朝10時にLambdaを起こしてデータの更新を行い、静的ファイルを再生成してからデプロイする流れになっています。 対象のサイト ざっくりAWSという、AWSの料金を日本円でざっくり計算できるサイトです。 Nuxt.jsで作成したものを、静的サイトとして生成して、AWSのS3にホスティングしています。 計算に必要なAWSの価格や為替は、毎朝10時に取得したものをS3にJSONで保存し、そのJSON

nuxt generateの機能は、静的サイト生成とか、単に静的生成といわれることが多いですが、文中で多用するのがツラいので、より短く「SSG(Static Site Generation)」で統一しています。 Nuxt.jsにおけるビルドの選択肢 Nuxt.jsでは、SPA・SSR・SSGの中から、好きなものを選んで開発できます。 初期設定ではSSRで動作するようになっていますが、流れとして自然なのでSPAから順に利点と欠点をまとめました。それぞれのビルドを行うため設定は、ドキュメントにわかりやすく書いてあるので、そちらでご確認ください。 サーバーサイドレンダリング - Nuxt.js SPA（Single Page Application） 利点 実装しやすい サーバーの準備が楽 欠点 初期表示が遅い SEOに不安がある OGをページごとに設定できない SPAは、最もシンプルに実装でき

Vue.jsとNuxt.jsを使っていて、どっちのドキュメントを見ればいいんだ？ってなったときのために機能を整理する。 開発に慣れてきたら迷うことはないと思いますが、Vue.jsをさわるのが初めてでNuxt.jsを採用した場合、どっちのドキュメントを見ればよいかわからずに、さまよってしまう事があるかもしれません（自分がそうでした）。そんなときのための、長ったらしいメモです。 この記事を書いている時点では、Vue.jsが2.5、Nuxt.jsが1.2です。 ドキュメントの歩き方 まずはガイドで概要を把握して、細かいことが気になったらAPIをあたります。 Vue.jsでの開発がはじめてであれば、本格的に書き始める前に、スタイルガイドを見ておくと、手戻りが少なくなるかもしれません。 ガイド フレームワークの使い方がわかりやすく書かれています。 はじめにから順に読んでいって、大体こんなことができる

Nuxt.jsのドキュメントのFAQに、AWSのS3へのデプロイの記述がなかったので、CircleCIでテスト&ビルドをしたあとで、デプロイするまでの手順をまとめました。はじめてのCIだったので、なにか変なところがあったらコメントかどこかでご指摘をお願いします。 CIのサービスに何を選ぶか 最初はいくつかのサービスを比較しようと思ったのですが、面倒になってしまったので、名前がグッと来たCircleCIにしました。使ってみて難しそうだったら別のものを試そうと考えていましたが、余計な心配でした。 対象のリポジトリ/目指すかたち こんな感じでテストを走らせて、ビルドして、AWSにデプロイするまでを自動化したい。 https://github.com/noplan1989/aws-rough CircleCI入門 はじめてのCircleCIだったので、ドキュメントを眺めるところからはじめました。

JavaScriptのイベント、ややこしいですよね。 名前が似ているものや、使い方にクセがあるものもあり、簡単なようで実装に手間どることが多いです。なので、よく使うイベントの概要をざっくりまとめ、それぞれの実行タイミングとイベントオブジェクトをコンソールで確認できるサイトを作りました。 忘れたときに調べればいいだけの話なので、わざわざサイトを作る必要はなかったのですが、イベントを眺めるのが好きな人に見ていただけたら嬉しいです。 JavaScriptのイベントをたくさん見られるサイト ひたすらaddEventListenerしていたら、イベントに愛着が湧いたので、イベントの実装でハマりそうなところをまとめています。 なぜイベントを使うのか マウスなどはイベントじゃないと値が取得できませんが、頑張ればイベントを使わずとも実装できるものもあります。たとえば、テキストボックスの変更を知りたいだけで

WHATWGのHTML Living Standardと、W3CのHTML5.2を見比べつつ、たまにMDNをながめながら書いていますが、少し感情的な部分も混じっています。 <article>と<section> A section forms part of something else. An article is its own thing. But how does one know which is which? Mostly the real answer is "it depends on author intent" 4.3.12.1 Article or section? | HTML Standard 実装する人の意図によるよ！ってそれを言っちゃおしまいですよ。気持ちはわかるけども。 <article> in principle, independently distri

ふだん受託でWebサイトを作っている人には、動的がWordPressで、静的がMovable Typeというのがしっくりくると思いますが、それぞれ一長一短あります。 やり方によっては、WordPressで静的にファイルを生成したり、Movable Typeを動的に使ったりもできますがそこには触れない方向で。 パフォーマンスだけをみれば、シンプルにHTMLを返す静的に軍配が上がりますが、コンテンツを更新する度にファイルを再生成する必要があるので手間がかかります。また、アクセスされる度に内容が変わるサイトなどは、そもそも静的に向かないので、どんなサイトにも対応できるわけではありません。 さらにnuxt generateで生成、CDNでホストされたEコマースのウェブアプリケーションを考えてみましょう。このアプリケーションは商品が在庫切れもしくは再入荷されるたびに再生成されます。ユーザーがアプリケ

Help us understand the problem. What are the problem?

AWSの料金、ややこしいですよね。 サービスの選択肢が多く構成が柔軟なおかけで、さまざまな要件をカバーできるのは嬉しいのだけど、そのぶん料金体系がややこしいので、やるせない気持ちになります。 この気持ちはなんだろう、この気持ちはなんだろう、と自問しているうちに春になってしまったので、AWSの料金を「ざっくり」計算できるサイトを作り始めました。 ざっくりAWS 公式ツールの存在 Simple Monthly CalculatorというAWSの料金を計算できる公式のツールがあるのですが、悲しいことに名前ほどシンプルではありません。 正確な料金を算出するために入力項目が多いのは仕方がないとは思うのですが、サイトを開いたときの威圧感がすごいので、もう少しさっぱりできないかという気持ちがありました。 なので、公式ツールの敷居が高いと感じる自分のような人向けに、料金を「ざっくり」計算できるサイトを作り

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Webデザインの本などで、「架空のカフェのサイトを作ってみよう！」みたいなフワフワしたチュートリアルはよくありますが、実際のサイトができあがっていく様をあまり見たことがないなと思い、LPの制作と並行して記事を書きました。 工程のすべてを書くのはつらいので、ハマった所や気をつけた所、後ろめたかった所を中心にまとめています。見苦しい所が多々あると思うので、そのときはそっと目を閉じてください。 ※ 記事にする許可は先方からいただいています LPとは ランディングページ。ユーザーが訪れる最初のページという意味らしいのだけど、商品の魅力を訴求する

ハイパーテキストをマークアップするのがHTMLなら、グラフィックをマークアップするのがSVGです。簡単なコードであれば形をイメージできるうえに、JavaScriptから手軽に操作できます。 WebGLを含むCanvasは、できる事の幅でいえばSVGよりもはるかに上ですし、ベジェ曲線も用意されていますが、線を引くだけなら大げさな気がします。あとレスポンシブ対応が地味にめんどくさい。サクサク動くゲームとか、ゴリゴリ動くリッチなサイトをCanvasで作れる人はすごくすごいと思います。 そんなこんなで、今回はSVGを使います。 Vue.jsとSVG SVGの実体はXMLなので、HTMLのようにVue.jsから操作できます。ベジェ曲線に必要な座標を変数として定義しておいて、それをリアルタイムで変更できるようにすれば、いい感じのベジェ曲線がVue.jsとSVGで実現できそうです。高まります。 実装 プ

LaravelでWebSocketを試す機会があったので、使い方を忘れないために、「まぐろ」の数だけ「マグロ」を返すチャットをデモで作成しました。 デモはこちらから 寿司が食べたくなりますね。 LaravelでWebSocket LaravelでWebSocketを実装するには、Pusherという外部サービスを使う方法と、socket.io+RedisのPUB/SUBで、WebSocketの部分をブリッジしてあげる方法が用意されています。 WebSocketまわりをLaravelの外に切り離すことで、ビジネスロジックに集中できるんだね。すごーい。 みたいな説明がちらほらあったのですが、PusherやRedisを知らない身としてはピンとこなかったので、そこらへんを補足しながらやっていきます。今回はsocket.io+Redisで実装することにしました。 Laravel5.5 Broadcas

高速化したサイト PHPで以前に作ったWebサイトを、 リニューアルついでにReact+Node.jsで書き直して、高速化を試みた一部始終です。 まとめ ファイルを圧縮して、gzipとHTTP/2で通信を最適化した後に、キャッシュを活用し、アニメーションを追加すれば、満足のいくスピードになる。 重たいWebフォントを読み込んですみません駆動開発。 対象のサイト 邦画の予告を、朝まで という名前の、文字通り邦画の予告をひたすら観られるサイトです。 たまには邦画も悪くないですよ。 課題の把握 ・初期表示にやたら時間がかかる ・ページ遷移の待ち時間が長く感じる ・ページ遷移時にバコってなる違和感 React+Node.jsでリニューアルした後、初期表示の遅さなどが原因で、体感的に遅くなってしまったのが高速化のきっかけです。 高速化の軸 ユーザーを第一に考えます。最終目標は、特定の端末でのサイトの

ブラウザの上をマグロに泳いでもらいたいと思ったとき、 気持ちよさそうに動いてもらえるのはどんな実装なのか。 CSSとJSのアニメーションライブラリを比較して選んでいきたいと思います。 CSSかJSを選ぶ基準 軽いアニメーションならCSS ホバーや要素のフェードイン・アウト、単純な移動や回転の場合は、 CSSのtransitionかanimationでやったほうが、 実装が楽なうえに動作が軽い場合が多いです。（特にスマホで） 複雑なアニメーションならJS 複雑なアニメーションが必要なときや、 タイムラインに沿ったアニメーションを実装する場合などには、 JSで書いたほうが柔軟性が高く、読みやすいです。 マグロのアニメーションは？ マグロのアニメーションを実装する場合、 そういった定石は通用しないので、感覚的にマグロが活き活きしているように思えるものを選択していく必要があります。 比較方法 すべ