Security researchers say they have observed what they believe is a takedown of the notorious Mozi botnet that infiltrated more than a million Internet of Things devices worldwide. In research shared w
![Node.jsとJSが合併の意向を共同発表――JavaScriptコミュニティーの統合を図る | TechCrunch Japan](https://cdn-ak-scissors.b.st-hatena.com/image/square/92584d6251feb0822f349cf0211361b2833c9939/height=288;version=1;width=512/https%3A%2F%2Ftechcrunch.com%2Fwp-content%2Fuploads%2F2018%2F04%2Ftc-logo-2018-square-reverse2x.png)
しがないラジオのgamiです。 JavaScript界隈では有名な、オライリーのサイ本こと『JavaScript 第6版』という鈍器、もとい書籍を読みました。 JavaScript 第6版 作者: David Flanagan,村上列出版社/メーカー: オライリージャパン発売日: 2012/08/10メディア: 大型本購入: 12人 クリック: 252回この商品を含むブログ (18件) を見る 2012年に発行された、約800ページもある、かなり内容の多い本です。 僕は本を読むときにesaに要約しながら読み進めるのですが、サイ本のまとめesaは全体で「約1万行」という修行みたいな分量になっていました。 サイ本、3年越しくらいでやっと読み終わったあああああ!!!esaにまとめながら読んでたけど、コードも含めて約23万字、1万行の分量になっててesaが悲鳴あげてたw今度感想ブログ書く。多くの人
現場のES201x と未来のアーキテクチャ - インサイドフロントエンド2
NaN === NaN は false NaN、つまりは Not a Number 同士の同値比較が false になるのは、よく JavaScript とかで罠だと言われていますが、罠でもなんでもないです。 false が返るという仕様です。仕様の経緯を追うとすぐに『 IEEE754 という浮動小数点の標準規格で決められているから』、という理由がヒットします。 では IEEE754 ではなんで NaN == NaN を false にしようという話になったのか、というのを調べてみました。 今回はそういう歴史の話です。 IEEE754 現在のプログラミング言語の処理系の多くが採用している浮動小数点の標準規格です。 この標準規格は以下のことを定義している。 - 基本形式: 二進および十進の浮動小数点数データの集合。有限な数(符号付ゼロと非正規化数を含む)、無限、特殊な「数ではない」値(NaN
この記事はJavaScriptの入門書として書いているjs-primerのthisに関する部分をベースにしています。 またjs-primerでは書けなかった現在時点(2018年1月1日)でのブラウザの挙動についてを加えたものです。 次の場所にjs-primer版(書籍版)のthisについての解説があります。 この記事と違って実際にコードを実行しながら読めるので、学習ソースとしては書籍版を推奨します。 書籍版: 関数とthis · JavaScriptの入門書 #jsprimer また、バグ報告やPRも直接リポジトリにして問題ありません。 asciidwango/js-primer: JavaScriptの入門書 おかしい場所を選択した状態で右下にある”Bug Report”ボタンを押せば、簡単にtypoとかのバグを報告できます。(PRでも歓迎) 前置きはこの辺までで、ここから本編。 この記
The JS Testing ConferenceAssert(js) is a conference for JavaScript developers focused on testing. From TDD techniques and process to JS testing tools and frameworks, both UI and Node.js. Watch the talks As developers we know that automated testing helps us write better code, build more reliable products, and keep our development velocity consistently high. As JavaScript developers we also know tha
PySpa統合思念体です。これからJavaScriptを覚えるなら、「この書き方はもう覚えなくていい」(よりよい代替がある)というものを集めてみました。 ES6以降の難しさは、旧来の書き方にプラスが増えただけではなく、大量の「旧来の書き方は間違いを誘発しやすいから非推奨」というものを作り出した点にあります。5年前、10年前の本やウェブがあまり役に立たちません。なお、書き方が複数あるものは、好き嫌いは当然あると思いますが、あえて過激に1つに絞っているところもあります。なお、これはこれから新規に学ぶ人が、過去のドキュメントやコードを見た時に古い情報を選別するためのまとめです。残念ながら、今時の書き方のみで構成された書籍などが存在しないからです。 たぶん明示的に書いていても読み飛ばす人はいると思いますが、すでに書いている人向けではありません。これから書くコードをこのスタイルにしていくのは別にいい
ページ上でずっと動いているsetTimeout、setInterval、requestAnimationFrameを見つけてパフォーマンス改善する 複雑なウェブアプリケーションになってくると、1つのページで複数のTimerなどを回すことがあります。 例えば、Twitterのようなアプリならば、ポーリングで更新するためにsetInvervalのようなタイマーを回します。 また、ゲームなどCanvasで描画を行うアプリケーションならば、メインループをrequestAnimationFrameで回します。 このように色々なタイマー系がありますが、アプリが多機能になっていくと色々なタイマーが同時に動くようになっていきます。 特に問題がなりやすいのが表示中だけタイマーを回すコンポーネントです。 よくあるのが次のようなmount時にtimerを開始して、unmount時にtimerを停止するコンポーネ
オブジェクトとReactのProps向けのShallow(浅い) equalライブラリを書きました。 Shallow Equalは対象のオブジェクトのプロパティをそれぞれ1段だけ比較することを言います。 ものすごく単純に書くならば次のようなことをするライブラリです。 const object = {}, targetObject = {}; const isEqualed = !Object.keys(object).some(key => { return object[key] !== targetObject[key]; }); const { shallowEqual } = require("shallow-equal-object"); shallowEqual({ a: 1, b: 2 }, { a: 1, b: 2 }); // => true shallowEqual({
ゲームなどのコンテンツにおいて、「当たり判定」から逃れることはできません。オブジェクトとオブジェクトが衝突したかどうかという判定は、インタラクティブコンテンツにおいて最も重要な部分になるからです。 当たり判定の実装自体は難しくありません。ですが、素朴な実装ですと、対象となるオブジェクトが大量である場合に、十分なパフォーマンスが出ません。これはオブジェクトの多い、現代的なゲームでしたり、弾幕シューティングなどを作るときに大きな障害となります。 この記事では、大量のオブジェクトの当たり判定を処理する、効率的な方法について紹介します。 まずは素朴に実装してみる 当たり判定の処理を語るには、ある程度ゲームの骨組みのようなものが必要になってきます。もちろんクラスなどを使わないベタ書きでもよいのですが、大変読みにくくなってしまいます。ですので、今回は、まず簡易的なゲームエンジンのようなものを作って、そ
この記事は一休.com Advent Calenrad 2017の2日目です。 宿泊事業本部フロントエンドエンジニアの宇都宮です。 一休.comの宿泊予約サービス(以下、一休)では、以下のようなスタックでWebフロントエンドの開発を行っています。 言語:ES 2017 ライブラリ・フレームワーク:古いところはjQuery、新しいところはVue.js ビルドパイプライン:Webpack + Babel 一休では、主要導線のE2Eテストは整備されています*1。一方、フロントエンド(JavaScript)のユニットテストは発展途上といったところです。 本記事では、一休のJSユニットテスト環境の変遷と現状について紹介します。 AVA 2017年4月の時点で、一休のJSユニットテスト環境は以下のような状況でした。 テスティングフレームワーク:AVA Babelでビルドされているコード:1,000行程
ゲームジャム(Game Jam)にはさまざまな形があるが,その多くは24〜48時間という短時間でゲームをゼロから完成させることを目指す。だがその一方で,1か月という余裕のあるスケジュールでゲームの完成を目指すゲームジャムも存在する――ただしコードが合計で13KBを超えてはならないという,別の縛りがそこにある。はたして,この特殊なゲームジャムによって,参加者はどのような知見が得られるのだろうか? Game Industry Conferenceでの講演の模様をお届けしたい。 短時間(24〜48時間)でゲームを作る「ゲームジャム」というイベントは,全世界で一斉に開催するグローバルゲームジャムを筆頭に,さまざまな団体(あるいは企業内)で行われている。 そして,これまで多くの場合,「ゲームジャムがもたらすメリット」について語られてきたが,その一方で「ゲームジャムが持つ問題点」も,少しずつ開発者の間
$200K 1 10th birthday 4 abusive ads 1 abusive notifications 2 accessibility 3 ad blockers 1 ad blocking 2 advanced capabilities 1 android 2 anti abuse 1 anti-deception 1 background periodic sync 1 badging 1 benchmarks 1 beta 83 better ads standards 1 billing 1 birthday 4 blink 2 browser 2 browser interoperability 1 bundles 1 capabilities 6 capable web 1 cds 1 cds18 2 cds2018 1 chrome 35 chrome 81
インプレスR&D 最新JavaScript開発~ES2017対応モダンプログラミング 著者:佐々木 俊介 ECMAScript2017によるJavaScript開発の最新動向を学ぶ! 【技術書典シリーズ第一弾!ECMAScript2017の最新チュートリアルガイド!】 本書は新世代のJavascriptであるES2017のチュートリアルガイドです。Node.jsなどに見られるようにWebサービス開発に於ける共通言語となっているJavascriptの中でも標準的な仕様であるECMAScript2017によるプログラミング手法を基礎から学習することができます。 本書は技術系同人誌即売会「技術書典2」で頒布された書籍を底本とし、加筆・修正を行ったものです。
相談内容 既存の管理ツールを新しく作り直すために新しいJSフレームワーク/言語使いたいのですが、何を選んだらよいでしょうか? ここで選んだものは今後新しく作る時にも使用していく予定のため、学習コストよりメンテナンスしやすいものを選びたいと考えています。 利用者は社内外で特定の権限を持った人のみであるため、サーバサイドレンダリングはしない予定です。 言語は型があるものを利用したいのですが、TypeScriptとFlowのどちらがよろしいでしょうか? 時間に余裕があれば、テストフレームワークやビルドツールについてもお聞きしたいです。 現在のページ/チーム jQueryなどで書かれている部分が多いですが、変更を加えることが難しくメンテナンスコストが高いです。 サーバサイドをやってる人が片手間で書くJavaScriptといった状況です。 今回新規で数ページを追加する必要があるため、何を利用すれば良
こんにちは丸山@h13i32maruです。 僕は2015年からESDoc*1というJavaScript向けのドキュメンテーションツールを開発しています。 https://esdoc.org https://github.com/esdoc/esdoc Star 最初のリリースから2年、昨日ようやくv1.0をリリースできました🎉 いやー、ここまで長かったです。今ではRxJSやSketchAPIなど、様々なツールで使用されています。 この2年間、ESDocは2つのゴールを目指して開発してきました。 ドキュメントの作成・メンテナンスを快適にする(ドキュメントを書くの楽しい!という状態) ソフトウェアの使い方を簡単に理解できるドキュメントを作成する(ソースコード読まなくても大丈夫!という状態) この2つを満たすためにESDocは色々な機能を提供しています。 今日はそれらの機能の中でも(多分)モダ
If your JavaScript is a mess, frameworks can only do so much to help. No matter what framework, "compiles-to-JS" language, or library you use, bugs and performance concerns will always be an issue if the underlying quality of your JavaScript is poor. With this hands-on guide, you’ll learn how test and refactor your existing code to help reduce complexity, improve readability, and gain confidence i
Intro XHR から fetch() に積極的に移行しづらかった最大のミッシングピースとして、中断できないという問題があった。 これは、 fetch() が選んだ Promise ベースのインタフェースにおいて、キャンセルをどうするかという議論と絡み、長く決着が付かずにいた問題である。 最近、やっと話が前進したので、ここまでの経過を解説する。 Fetch のミッシングピース fetch() は、ブラウザが発行するリクエストと、取得するレスポンスを扱う低レベルなインタフェースとして策定が始まった。 DOM の API が Promise ベースに移行しつつある流れを汲み、 fetch() もまた Promise を返す関数一発スタイルになった。 クラスからインスタンスを生成しメソッドを呼ぶ XHR スタイルでは、インスタンスを再利用した場合の挙動などを含め、オブジェクトのライフサイクルを
A close superset of ES7 with JSX and Flow, built with Babel. Designed to make programmers a little more productive. Item({ item, isActive, onClick }) => className = if isActive: 'active' else: 'inactive' <li onClick={onClick} className={className}> {item} </li> class List extends React.Component: activateItem(itemId): void => if this.state.activeItem == itemId: this.setState({ activeItem: null })
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く