かれこれ 5 年くらい趣味開発で npm-scripts を書き続けている。長年書き続けているとノウハウが蓄積されてきて、「こう書くとスッキリする」「迷いがなくなる」「後から拡張したくなった時に、簡単に拡張できる」みたいな書き方が身についてきた。自分の型、あるいは手癖のようなものだと思う。 せっかくなので、id:mizdra の今の npm-scripts を書く時の手癖を書き連ねてみる。 基本形 { "scripts": { "build": "webpack --mode production", "dev": "webpack-dev-server --mode development", "lint": "eslint .", "test": "jest" } } 一番シンプルな npm-scripts を書く時のパターン。以下の 4 つの script を登録している。 buil
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? できあがったクソゲー できあがったブツ(音が出るので注意) https://teradonburi.github.io/santa/index.html 避けゲーです。始める前に事の経緯を読むとクソゲーを倍楽しめると思います。 ちなみに技術的にすごいものはあまりないかもしれません・・・ どちらかというと限られた時間内に自分の持てる能力で実現するにはどうしたらよいかというのを試行錯誤したことを書きました。 タイトル画面はそれっぽい感じにしました・・・ 事の経緯 JSフレームワーク(またはライブラリ)× ビアバッシュ 初心者勉強会にて最速で
初めまして! インターンの長瀬です。普段はWebフロントエンド関連の業務をしています。 今回は、私がApollo GraphQLを使ってWebサービスを開発してみて感じたこと・考えたことを共有します。前半では開発での知見を活かし、GraphQL APIをRESTful APIと比較しながら紹介していきますので、GraphQLなんて使ったことがないよ! という方もお楽しみいただけるかと思います。 tl;dr WebサービスをApollo GraphQLで開発した サービスにおいて、特に複雑なグラフ構造のデータモデル等はなかったが、型定義の自動生成や単一エンドポイントなどの点でGraphQLを使う意義があったと感じた Apollo GraphQLはブラウザ拡張やapollo-codegenなどの開発支援も充実しており、快適に開発ができた GraphQL, Apollo GraphQLについて
この記事は旧バージョンのエディタについてのものになります。 現在は進化した新バージョンがリリースされています。 前の記事で、noteがHTML5のcontenteditableを利用している事、そしてそのままではとても使えない事を書きました。それをどうにか使えるようにしているのがエディタなわけですが、今回はそのエディタの成り立ちや、どういう開発をしてきたのか、といった事を書こうと思います。 noteエディタの歴史私が開発担当している現行(201810現在)のエディタ(初版201704リリース)は、実はnoteのサービスローンチ時まで遡って数えると、3代目になります。 初代 弊社CTOのkonpyuが、突貫で作り上げた…と聞いています。 曰く、「すぐに引っ込めた」との事。note自体のローンチに向けた開発も多忙な中にあって、エディタに人員を割り当てて実装する、というのはなかなか難しかったので
Angular などの JavaScript フレームワークは大規模向けに設計されており、標準で多くのエコシステムが組み込まれています。 React は単なる View ライブラリです。そのため View ライブラリを補完するためのエコシステムの選択が必須となります。 エコシステムを自由に組み合わせて開発者とプロジェクトに応じた理想的なフレームワークを作成する必要があるわけです。 これは、小規模アプリケーションから大規模アプリケーションまでの様々な要件やニーズに対応できる柔軟性が高いことを意味していますが、エコシステムを選択するためのコストが必要となります。 下記では、筆者が最低限、導入を検討する余地があると考える主要な React のエコシステムとその簡単な概要を記載しています。 筆者の独断と偏見で選択したエコシステムであることを考慮してお読みいただきたいです。 既知のエコシステム (ほ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? お知らせ(2020/08/25 追記) Udemy で「webpack 最速入門(10,800 円 -> 2,000 円)という講座を公開しました。 本来の価格は10,800円ですが、上記リンクからアクセスすると2,400円で購入できます。 どんな内容? webpack を利用したフロントエンド開発環境が構築できるようになる、ハンズオン形式の講座です。 詳細は上記のリンクのプレビュー動画で詳しく説明しています。 記事との内容の違い 記事の内容に、以下の内容や特徴が追加された感じです。 実務で利用できる開発環境を徐々に構築していくので、記
For Yarn 2+ docs and migration guide, see yarnpkg.com. Posted May 12, 2017 by Maël Nison Last year was a great time for Javascript newcomers! A lot of starter-kit projects were published, refined, and some of them eventually went on to offer command line tools dedicated to make project creation easier. One such example is create-react-app, but most frameworks have their own tools, with various fla
新ブログに移行しました。 blog.andoshin11.me
AWS Amplifyとは? 本記事はServerless Advent Calendar 2017の13日目の記事です。よろしくお願いします。 AWS Amplifyは、2017年11月に公開されたAWSを利用するWebアプリケーション向けのJavaScriptライブラリです。サインアップやサインイン、MFA、追跡またはメトリクスの分析、コンテンツ管理、またはサーバーレスAPI統合などの実装が容易にできるように設計されています。 AWS Amplify は、クラウドサービスをスケーラブルかつ保護された方法で使用して一般的なアクションを実行するクライアント開発者に、宣言型インターフェイスを提供するように設計されています。これらの新機能を使用して、開発者は JavaScript アプリケーションを作成して一般的な抽象化を使用したベストプラクティスをプログラムによって適用し、最終的に開発サイク
By Harsh Makadia Just like how people are excited about updating their mobile apps and OS, developers should also be excited to update their frameworks. The new version of the different frameworks come with new features and tricks out of the box. Below are some of the good features you should consider when migrating your existing app to React 16 from React 15. Time to say Goodbye React15 ? Error H
Webフロントエンド パフォーマンス改善ハンドブック このパフォーマンス改善ハンドブックでは、ウェブアプリケーションにおけるフロントエンドのパフォーマンス改善について扱っています。 ダウンロード版 埋め込み動画を再生できないなど一部制限がありますが、ダウンロード版を配布しています。 PDF版 EPUB版 MOBI版 目的 このハンドブックでは過去に行った改善の事例を中心に紹介しています。 そのため、現在の最適な解決方法を提案するものではありません。 また、アプリケーションによっても最適な解決方法は異なります。 今回の事例ではViewライブラリにReactを使い映像再生プレイヤーなどある程度複雑な機能を持ったウェブアプリケーションのフロントを扱います。 具体的にはニコニコ生放送(以下「生放送」)で行った事例を中心に書かれています。 開発と平行して行われていたため、React 15から16の間
autoscale: true Webpagetestから始める継続的 パフォーマンス改善 ページロードタイム編 :hourglass: 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info Create: textlint, Almin アジェンダ パフォーマンス改善は指標を決めて行わないと迷子になる パフォーマンス改善を行うには継続的な計測を行う 今回はページロードについて、ランタイムは範囲外 パフォーマンス改善のアプローチ 継続的なパフォーマンス計測とリグレッションの検知 ^ 目的はパフォーマンス改善には計測が必要という事実を知ること ^ パフォーマンス計測は継続的に行う必要がある ^ パフォーマンス改善は何を目的、指標にして改善するかを決めないと迷子になる ^ 目的をもって継続的にパフォーマンス改善を行い
スタディスト開発部、フロントエンド担当の小宮山です。走ることが楽しくなりすぎてフルマラソン完走が当面の目標です。 今回は私達が進めているUIリニューアルプロジェクトにおける、フロントエンド設計の心臓部についてご紹介したいと思います。盛り上がりつつあるものの、まだまだ実践的な情報が少ないVue界隈に少しでも貢献できましたら幸いです。 画面駆動Vuexの頃プロジェクト始動当時は私含め大規模プロダクトにVuex(さらにその他Flux状態管理も)を導入して開発を進める経験も知見もほぼない状況でした。 そして開発していく画面デザインの大枠は出揃っている状態だったので、計画も実装も画面単位で区切って進みだしていきます。 こうした状況でVuexのstoreはどのような方針で実装されていくか。正確に表現するなら、特に方針なく実装していくとどうなるか。画面ファーストで、画面から使いやすく、画面ごとに専用なs
こんにちは。フロントエンドエンジニアのaxrossです。この記事では、弊社のサービス「Kaizen Ad」で行った "i18n" (国際化) の取り組みについて紹介したいと思います。 Kaizen Adでは、サービス提供を行う地域として日本とアメリカを同時に見据えて開発をしてきました。そのため、プロジェクト発足当初から意識して開発を始め、(クローズドな) ファーストローンチの2週間後にはこの記事で紹介するようなi18nを取り入れています。 i18nとは "Internationalization" の略で、単語の最初の文字 "I" と 単語の最後の文字 "N" との間に18文字あることからこのように略されます。 i18nをどのように考えるか? まずは、Kaizen Adを国際化するにあたって考えたことについて話したいと思います。大きく分けて2つの点をチームで徹底して意識しながら開発を進めま
こんにちは。いかがコーディングお過ごしでしょうか。 私は今更ながら最近GraphQLで遊び出し、そしてApollo Clientに出会いました。 ワクワクしました。「これは想像以上に既存のフロントエンドの設計・実装を変えるものだぞ!」と感じました。 「Apollo ClientってGraphQLクライアントでしょ?GraphQLエンドポイントない俺には関係ないな。」と思ったそこのあなた、それだけじゃないんですApollo Clientは!!!!! 本記事では「Apollo Clientとはなんぞや」という話と「なぜ私がApollo Clientを布教したいのか」という点について語ります。実は最初は実装含めたチュートリアルを書いていたのですが長くなり過ぎたため記事を二つに分けました。この記事はどちらかと言うと概念系の話が多めで、片方にApollo Client + Reactのチュートリアル
qiita.com ⬆️大体これを読めばわかるけど使用した関数や細かいメモを。 今回自分で使ったのはcall, fork, put, take, selectの五つ。 call: promiseの終了を待つ。引数にはpromiseを返す関数を入れる。 fork: 別のタスクの開始。 function*から始まる非同期関数を引数にとる。 put: actionをdispatchする。 take: action、イベントの発生を待つ。actionを待つけど引数に取るのはactionの関数ではなくてaction.typeとなる文字列。 select: stateからデータを取り出す。stateを引数にとる関数を引数にとる。 importするときは、 import { call, fork, put, take, select } from 'redux-saga/effects' のように書く。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く