jQueryは1個の要素と複数個の要素を同じように書かせる - fsubal
#フロントエンド #設計 #JavaScript 「1個の要素と複数個の要素を同じように書かせる」というのが実は jQuery の特徴の一つだと思っている。 document.querySelector() や querySelectorAll が出現して以降 jQuery の必要性はほとんどなくなったと言われる。 実際にこんなサイトもあるし https://youmightnotneedjquery.com/ これは実際その通り 一方、jQuery で書かれたコードを querySelector や querySelectorAll に移行しようとしたら苦しかったという経験をした人は多そう。 上のコードが下のようになる。 code:javascript $('.foo').on('click', e => { // ... }) Array.from(document.querySele
React ステート管理 比較考察 - uhyo/blog
こんにちは。Reactの話題の中でもかなりの部分を占めるのがステート管理、さらに言えば各種のステート管理ライブラリです。今さらながら、Reactにおけるステート管理の手法やいくつかのステート管理ライブラリを比較考察して記事にまとめました。 useState + バケツリレーReactにおける基本的なステート管理はuseStateです。ひとつのコンポーネント内で完結するようなステートならばuseStateは非常に適しており、他の選択肢はほぼ無いと言っても構わないでしょう。 ステートをアプリケーションの広範囲で使いたい場合が問題です。次の画像に例示されるように、分岐したコンポーネントツリーの末端のコンポーネント（使用者）で同じステートを参照したい場合を考えます。 useStateと組み合わせる場合、もっとも原始的な方法はpropsのバケツリレーによるものです。propsは親コンポーネントから子
React17におけるuseEffectの破壊的変更を理解する
しばらく前、React 17 RCが発表されました。現行のReact 16に比べて、いくつかの破壊的変更がある一方、新機能が何もないというのが特徴です。Reactチームとしては、新機能が無いとはいえ、破壊的変更も少なくなっておりなるべく16から17へのアップデートを行なってほしいという考えのようです。 この記事では、React 17における破壊的変更のうち、useEffectのクリーンアップのタイミングに関する変更を取り上げます（以下は公式サイトから引用）。 In React 17, the effect cleanup function also runs asynchronously — for example, if the component is unmounting, the cleanup will run after the screen has been updated.
【2Captcha】Python+Seleniumで『reCAPTCHA』を突破する方法
2Captchaとは 2Captcha公式ページ ロシアの会社が開発したreCAPTCHAを突破するためのプラットフォームです。 通常であれば、プログラムからreCAPTCHAにチェックをいれることは、ほぼ不可能レベルだと言われています。 では、なぜ2Captchaを使うだけで、可能なのでしょうか。 2Captchaの仕組み 2Captchaの仕組みを簡単に説明すると、reCAPTCHAのチェックボタンをネット上の『Worker』と呼ばれている人達に代わりに押してもらっているイメージです。 PythonのSeleniumで説明すると、プログラムの実行中にWorkerの誰かがリアルタイムで解錠した結果を2Captcha経由で受け取ると言ったところでしょう。 なので、2Captchaはプログラムで解錠しているように見えるけど、実際は人力…みたいなオチです。 使用方法 2Captchaを使うため
2019年になってもまだjQueryを使用している理由
現在、jQueryを使用している人、そしてjQueryを取り去ろうとしている人がいると思います。jQueryの使用に対する一つの考え方を紹介します。 Why I'm still using jQuery in 2019 by Martin Tournoij 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は元サイト様のライセンスの元、翻訳しています。 2019年になってもまだjQueryを使用しているのはなぜですか Hacker News での議論 多くの人が「普通のJavaScriptを使えば、jQueryは必要ない」と主張しています。私は多くを必要としないので、jQueryを必要としませんが、確かに便利です。 You might not need jQueryのようなページでは、jQueryを捨てるのは簡単だというアイデアを売り込もうとしていますが、逆にこのページの最初の例
マイクロソフト、Google、W3C、Mozillaらが協力。それぞれのWebブラウザのドキュメントをMozillaサイトに一本化。あちこちのWebサイトを見て回らなくても済むように
マイクロソフト、Google、W3C、Mozillaらが協力。それぞれのWebブラウザのドキュメントをMozillaサイトに一本化。あちこちのWebサイトを見て回らなくても済むように Mozillaは、マイクロソフト、Google、W3C、サムスンなどと協力して、それぞれのブラウザなどに対応した技術解説のドキュメントを一本化し、Mozilla Developer Networkの「MDN web docs」にまとめて掲載する取り組みを開始したと発表しました。 Webブラウザに関するHTMLやCSS、APIなどの機能の解説は、そのWebブラウザを開発するベンダのWebサイト、例えばマイクロソフトならMSDN（Microsoft Develpers Network）、GoogleならChromeのWebサイト、MozillaならMDN（Mozilla Developer Network）のWe
LivePhotosKit JS | Apple Developer Documentation
Play Live Photos on the web.
Polyfill のあり方と Web の進化と協調するためのガイドライン | blog.jxck.io
Intro W3C の TAG から、主にブラウザ API の Polyfill に関するドキュメントが公開された。 Polyfills and the evolution of the Web Polyfill は便利な一方で、時として標準化の妨げになってしまう場合があるため、それを避けるために、 Polyfill 実装者、利用者、仕様策定者などが、どう振る舞うべきかという趣旨である。 今回はこの内容を元に、 Web の進化と協調する Polyfill のあり方について、主に「実装者」がどうすべきかに着目し記す。 Web における Breaking Change Breaking Change は、簡単に言えば 後方互換を失うことで既存のものが壊れる可能性がある変更 のことを表す。 そして、 Web における Breaking Change (Break the Web)、具体的には W
ep22 AMP | mozaic.fm
Theme 第 22 回のテーマは AMP(Accelerated Mobile Pages) です。 今回は @ymotongpoo さんをお迎えして、 AMP の登場背景やそこから見える今の Web の問題点、導入や普及、今後の展望などをふまえ、 AMP が登場した意味、そして AMP が Web にもたらす影響などを通して 「今何がおこっているのか」と「これからどうなっていくのか」を議論しました。 Show Note Why AMP is Fast ampproject.org ampproject/amphtml github Waht is AMP? Why AMP is fast Publishers using AMP HTML AMP Cache AMP Cache AMP Cache Update Ping Format AMP Validator Chrome Dev
oEmbed APIの使い方まとめ！URLから埋め込みHTMLタグを作ろう！
oEmbedとは、埋め込み用コードを取得するためのシステム、統一規格です。TwitterやYoutube、Vimeoなどといった世界的に有名なwebサービスの各々がこのoEmbedの規格を採用しています。 統一規格ってどういうこと？統一規格があることで、web開発者はoEmbedの仕様だけを知っておけば、「個別に各サービスの仕様を調べる」といった学習コストをかけることなく、様々なサービスの埋め込み用コンテンツを利用することができるわけです。 2014年9月には日本で人気のブログサービスはてなブログが、このoEmbedの規格を採用して、ブログ記事の埋め込み用コードを取得するAPIを公開しました。採用するサービスが増えれば増えるほど、web開発者にとって好ましい環境が整っていくというわけですね。
HTMLでWeb APIをつくる - Qiita
シングルページアプリケーションやモバイルアプリなどの普及により、サーバサイドではJSONを出力するWeb APIの必要性が高くなってきています。みなさんはどのようにWeb APIを作っているでしょうか。 JSONはビュー RailsでJSON APIを定義する時、素のままでやろうとすると コントーラでto_jsonを呼んだり、モデルにas_jsonを定義したりすることになるかと思います。 モデルに書くとAPIによって出力内容を変えたい場合にとても苦労します。 API数が増えれば増えるほどモデルが複雑になっていきます。 APIレスポンスとしてのJSONはコントローラやモデルに書くべきでしょうか？ ビューに書いた方が自然ではないでしょうか？ これはRailsでの話ですが、Railsに限らず、フレームワークを使ってWeb APIを作るときに一般的にあてはまることだと思います。 変化に強い、再利用
Webサービスの埋め込み用HTMLを手軽に取得するためのWebAPI『QuoteIt』を作りました - みずぴー日記
# この記事は名古屋クリスマスハッカソン2011で書いてます。メリークリスマス! GistとかTwitterとかの最近のWebサービスは他のページに埋め込めるようになっていますね。ただ、サービスごとに埋め込むためのHTMLコードが違うので、いちいち調べるのが面倒ですよね。 そこで各種Webサービスの埋め込み用HTMLを統一的に取得できるWebAPI『QuoteIt』を作りました。しかも、誰でも引用元を簡単に追加することができます。 http://quoteit.heroku.com/ 使い方 URLを指定すると、埋め込み用のHTMLを取得できます。 例えば、 http://twitpic.com/73wiodを埋め込みたい場合は、 http://quoteit.heroku.com/clip.html?u=http%3A%2F%2Ftwitpic.com%2F73wiod にアクセスするこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
REST API endpoints for Markdown - GitHub Docs
cybozu developer network
json-pagetitle