You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
リントツールをインストールしても使わなければ意味がない。 というわけで人的なリント忘れを未然に防ぐためにも、huskey と lint-staged と 各種リントツールを組み合わせてコミット前に自動的にリントが行われる環境を作りましょう。リントエラー時にコミットを弾くことによって git 上のコードの品質を保つことができます。 環境 husky 1.1.0 lint-staged 7.3.0 git hooks の設定を package.json などからできるようにしてくれるツールです。 生の git hooks だとチーム内で共有とかがしにくいですが、husky を使って設定を package.json などに書けば簡単に共有できます。 pre-commit フックを使うことが多いと思いますが、クライアントサイドのフックであればすべてサポートしているみたいです。 ステージングしたファ
こんにちは、Qiitaに初めて投稿するG4RDSと申します。 一年半前からWebを触り始めて、最近はVue.js/Nuxt.jsを使ってFirebaseをバックにWebサービスを作るのを趣味にしています。 今年度が大学一年生です。 今回、メッセージをお菓子のイラストと一緒にTwitterのリプライやDMで贈れる「chocotto」というサービスをリリースしました。 これが僕が作ったWebサービス二作目です。 サービス開始しました! chocottoは無料で使えるギフトメッセージサービスです💌 メッセージをチョコなどのお菓子のイラストと一緒に贈れます🍪 もうすぐバレンタイン🍫 遠くてチョコを渡せない人にも、chocottoで想いを届けてみませんか?#chocottohttps://t.co/J3ONNEpKwu — chocotto (@chocotto_co) 2019年2月11日
はじめまして。yamaimo (@yarnaimodev) です。Qiita 初投稿...というかネット上にちゃんとした記事を上げるの自体初めてな気がします。 1998 年生まれで、プログラミングとか Web デザインは独学で 3 年ぐらいやってます。TypeScript / Firebase / Node.js / React あたりが特に好きです。 この前 coliss で紹介された Can't Unsee を試してみたら 1 回目が 7,630 点、2 回目が 7,930 点でした。1 小規模ですが Mastodon インスタンスを管理してます。あと Helix キーボード をこの前組み立てた2んですがキー配列を変えたのがなかなか覚えられなくて死んでます。 開発環境は基本的に WSL + Hyper + fish shell と VSCode です。 今回 Puppeteer を使っ
gulp 4.0 が正式リリースされましたが、v3 から v4 へのバージョンアップに伴い実施されたいくつかの修正が原因で、v3 環境で使用していた gulpfile.js ファイルがそのままでは正常に動作しなくなりました。v4 移行のために行った gulpfile.js ファイルの修正点をまとめます。 つい先日ですが、gulp 4.0 が正式リリースされ、本記事執筆現在、npm install gulp すると gulp 4.0.0 がインストールされるようになっています(今まではプレリリース扱いということで、npm install gulp@next と指定しなければ 4.0 はインストールされませんでした)。 Version 4.0 Now Default - gulpjs gulp changelog - gulpjs/gulp そこで早速ですが、試しにテスト環境作って gulp
IS19er / seccamp 2012 卒業生のつばめです。本稿は ISer Advent Calendar 2018 と セキュリティキャンプ 修了生進捗 #seccamp OB/OG Advent Calendar 2018 の 7 日目として書かれた記事です。今年 2018 年に発表された論文 (Smith et al., 2018) をきっかけに, Browsing History Sniffing 周辺を軽く眺めてみながら, 「Web の複雑さとの付き合い方」を少し考えてみたいと思います。 TL;DR Browsing History は個人の趣味嗜好を表すだけでなく, fingerprint としても機能し得る存在です。その重要性から, それを盗み見るための Sniffing 手法も多くが考案されてきましたし, 対策法についても検討・実装が重ねられてきました。しかし近年提案
まえがき 本記事は進化を続けるフロントエンド界隈の思想を大まかに紹介するものです。 「自分で問題を作って自分で解決する自作自演を繰り返している」というような批判をたまにうけるフロントエンド界隈ですが、 それぞれの技術はもちろん何らかの課題を解決するために生まれてきたものであり、 それらの課題と解決策を知り、フロントエンドがどのような方向に進もうとしているのかを認識しておくことは 流行のReactやVue.jsを活用していく上でも地味ながらも確かに役に立つことだと思います。 対象読者 ReactやVue.jsなどを使って現在流行のフロントエンド開発を始める方で 各ライブラリのGetting Startedを読んでHello World程度まで済ませたぐらいの方を想定しています。 この記事では抽象的な思想を中心に扱います。 なのでこの記事を読んであとにリポジトリに即一行コードが増えるような実践
もう人生で何個目かわからない markdown エディタ作った。が、今回のは結構気に入っている。 https://markdown-buffer.netlify.com/ で遊べる。 用途としては、GitHub か Qiita か はてなブログかわからないが、なにか書こうと思ったときに、どのサービスも中途半端に重いので、とりあえずのバッファが必要、という感じで作った。なので速度重視。 ブラウザのストレージで永続化してる。オフラインで動く。できるだけエディタとしてはスコープを大きくせず、単に編集バッファ(textarea)でしかない、というのを意識している。 結構頑張って作り込んでしまった https://nedi.app が色々肥大化してしまっていて入力時にラグを感じるので、編集体験を見つめ直す自戒もある。 機能 数式対応 コードハイライト対応 バックグラウンドで自動保存 改行を br に
一休.com レストランは今年の 7 月 18 日、スマートフォン向け検索ページのリニューアルを行いました。このエントリーでは、その中身について少し紹介させていただきます。 検索ページの課題 一休.com レストランではスマートフォン向け検索ページに対して「遅い」という課題意識がありました。これは技術面で少しブレイクダウンすると; パーソナライズドを含む複雑な処理を行っているため、サーバーサイド処理が重い。 UI 上無駄な遅延処理を行っているため、クライアントサイドの描画が遅い。 というサーバー側とクライアント側両方の課題がありました。クライアントサイドの「無駄な遅延処理」というのは; 検索結果取得が REST API 化されているにも関わず、再検索の度にページリロードを行い、サーバーサイドの描画からやり直している。 という実装に問題がありました。下図がリニューアル前のページ描画の様子です
2018年9月22日(土)にJSer.info 400回記念イベントを開催しました。 無事JSer.info 400回記念イベントを行うことができました! JSer.info 400回記念イベント - connpass 2018年9月22日(土)に JSer.info 400回目記念イベントを開催します - JSer.info JSer.info 400回記念イベント - Togetter 今回は「憶測しないで議論しよう」というテーマで開催しました。 このテーマについてはJSer.info 400回記念イベントというスライドでも話をしていますが、参加者全員が何か得られるものがあればいいなというPositive Sumの考え方で設定しました。 参加して何か得られたものがあれば幸いです。 本日はご参加いただきありがとうございました! Special Thanks 会場: @koba04 サイボ
とても個人的な話ですが、ここ最近で自分自身のプライバシー意識の高まりを感じて、ブラウザの設定を見直す機会がありました。見直したのはCookieの設定で、許可したドメインにしかCookieを記憶しないようにしました。設定変更によるある程度の不便は覚悟していました。とはいえ、ま〜せいぜい、初回アクセスの時のモーダルが何度も出るようになるとか、ログインできなくなるとか、そのくらいかなと思っていました。 しかし実際は、悪い意味で期待を裏切られることになりました。 Cookieが無効なだけで、“全く”動かなくなってしまうウェブサイトやウェブアプリが、本当にたくさんあることに気づいたのです。 全く動かなくなってしまう原因は単純(後述)だったのですが、ちょっとした対処で簡単に直せることなのに、サイト全体が一切使い物にならなくなってて、もったいない!! と思いました。 フロントエンドの想定外 ウェブサイト
{{getAnalysisToolsText()}} Yamllint TSLint tfsec SwiftLint stylelint StyleCop ShellCheck Scalastyle RuboCop Revive Pylint pycodestyle PSScriptAnalyzer PHP_CodeSniffer TSQLLint lintr HLint Brakeman bundler-audit Checkstyle CodeNarc CoffeeLint Linter for Dart CppLint Detekt ESLint Flawfinder Vet Hadolint CSSLint Bandit .NET assembly informer Duplication checker
Discussion 1. CommonJS は tree shaking されない ※追記、修正あり すべてのモジュールバンドラーが、 import { isEqual } from 'lodash'; を tree shaking できませんでした。これは、 CommonJS は静的に解析することができない困難または不可能(2018/06/15 修正)なためです。 例えば、 ES Modules の import, export に対応する CommonJS の require、 exports は、それぞれ以下のように動的に書くことが許容されています。 require const fooOrBar = require(Math.random() < 0.5 ? 'foo' : 'bar'); exports for(const name of ['foo', 'bar']) { ex
【F8報告会】LiveRailとFacebook SDKのNative Ad対応の意味/株式会社トーチライト 三原 敬太様
こんにちは。アソビュー株式会社でフロントエンドのテックリードをしている井上です。 先週会社の同僚と行ったボルダリングでダメージを受けた手にむち打ち、今日も狩りに出るためコントローラーを握りしめる日々です。 今回Webアプリケーションの表示速度高速化について書きたいと思います。 最近は特に日経電子版やdev.toなどの先端事例が話題になったり、SEO観点での重要性の高まりやPWA、AMPなど高速化にも関連する新しい技術や手法などWebサイトのパフォーマンスは注目度が高いトピックだと思います。 弊社でもUXやSEOの重要な要素として表示速度については目標値を設けて取り組んで行こうとしています。 直近数ヶ月でもasoview!のサイトを対象にいくつか取り組みをしたのでその内容について軽く触れられればと思います。 取り組む前の状況 私は昨年の11月にジョインしたのですが、弊社のビジネスの中心となっ
メリット – メリットはこちらに詳しいので省略します。 注:複数人で原稿を書いていたので、全体としては個別に好きなツールで書き、Google Docsに貼り付けて全員で修正したあと、InDesignでレイアウトするという流れでした。 デメリット – ESCキーが物理キーではないマシンで執筆すると完璧な絶望を味わえます Google Docs の印刷サイズの問題が致命的で、cm単位でサイズを変更できないので詰みます。吉海の場合は印刷所の方からサイズに関しての連絡があってからこの問題が発覚しました。最終的には印刷所の方にPDFの原稿のサイズを修正していただくことで解決をしました。次の原稿は吉海もRe:VIEWを使おうと思っています。 本の印刷について 技術書典4では日光企画さんとねこのしっぽさんがバックアップ印刷所で、これらの印刷所を使うと印刷した書籍を会場に直接搬入してもらえました。 吉海と
ややお気持ち多め。 前置き 最近の個人的な考えとして、React 書く人は ReactNative 側にスキルを寄せたほうが良いのではないか、と思っている。 ReactNative の需要の高まりは凄い。最初はプロトタイピング採用だったのが、徐々にプロダクションに出始めている。今年末には新規プロジェクトの10~20%は ReactNative になるんじゃないか?という感すらある。 僕はデスクトップのブラウザは好きだけども、残念ながら、世の中の趨勢はモバイル側にある。その上でフロントエンドにロックインすることをリスクに感じている。PWAのアプリケーションも来そうではあるが、直近の需要を賄うためにやはりReactNativeに習熟しておきたい。 大事なのは、「考え方として」 ReactNative に軸足を移したほうが色々といいということだ。 Web は基本的に動きが少ない。見栄えをよくした
javascriptの開発では、sassやtypescriptなどのコンパイル、minifyやautoprefixerでの最適化、依存関係を解決しbundleするなど多様な工程があるので、属人化・職人依存を避けるためにタスクランナーでの自動化が昔から当たり前に行われています。 webpackはこの手のツールのデファクトです。webpackはタスクの自動化支援ではなく、なんでもjsにまとめるという仕事をうまくやる事に特化しています。gulpやbrowserifyで行なっていたようなタスクの自動化はnpm scriptで十分やん、という割り切りを感じます。 なんでもjsで扱えるようにするので、cssや画像やhtmlもjs内にロードでき、設定が煩雑になりにくくなります。 webpackのloaderという仕組みがjsへの組み込みや最適化をうまくやってくれるのですが、どういうものか検証していきまし
react-routerのハッシュリンクとスムーススクロール React Router を使っているプロジェクトで、できれば「ハッシュリンクを踏んだ時に、対象位置までスクロールしたい」というのがあり、少し調べていた。そもそも React Router はハッシュリンクが正しく機能しないという不具合があったり、既に公開されているライブラリでは機能を満たせない、メンテナンスが不安、コードがアレ…等等、スクラッチで書くところから始まった。 react-router-hashlink React Router の <Link> コンポーネント をラップして、ハッシュリンクに対応したのが 1000ch/react-router-hashlink である。 import { HashLink } from 'react-router-hashlink'; function render() { ret
先日、Facebookは 膨大なプルリクエスト をReactにマージして、既存のビルドシステムを Rollup ベースのシステムに移行しました。 その結果 、 何人もの人々 から「なぜwebpackではなくRollupを選んだのか」という質問が寄せられました。 これは、もっともな疑問でしょう。 webpack は、近年JavaScriptコミュニティで最も評価されているツールの1つです。毎月のダウンロード数は何百万件にもおよび、何万個ものウェブサイトやアプリケーションに使用されています。巨大なエコシステムがあり、コントリビュータも多くいます。さらにオープンソースプロジェクトとしては珍しく、 かなりの寄付金 が集まっています。 それに比べるとRollupは小規模です。しかしReact以外にも、Vue、Ember、Preact、D3、Three.js、Momentなど、数々の有名なライブラリに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く