2017年10月6日『まぼろしのJS勉強会 #1 「ナウいJSの書き方・考え方」』にて発表した資料です。 https://maboroshi.connpass.com/event/66502/ #mbrs_js_study
2017年10月6日『まぼろしのJS勉強会 #1 「ナウいJSの書き方・考え方」』にて発表した資料です。 https://maboroshi.connpass.com/event/66502/ #mbrs_js_study
こんにちは。 Creator’s Noteには、初登場になるプロダクト開発部の火村(ひむら) a.k.a @eielh です。 弊社では業務効率化やBOT作成のためにGoogle Apps Scriptが使われています。 私はまったく携わっていないので、実はよく知りません。 最近までGoogle Apps Script自体も使ったことありませんでした。 社内でよく使われているものを知らないのはもったいないです。 プライベートでも使い道がたくさんありそうです。 そんなわけで勉強してみることにしました。 しかし、普通に始めるのも面白くありません。 せっかくなので、Flowを導入しながら、始めることにしました。 ということで、今回はFlowを使ってGoogle Apps Scriptのコードをチェックする方法を紹介します。 Flowとは チャットワークAPIのクライアントライブラリを利用した例
タイトルから何を言ってるのか意味わからない気がするので順を追って解説。 スライド版: ECMAScript 6 Draft Hisotry Repo 2015-05-07現在、ES6の仕様はApril 14, 2015 Rev 38 Final Draftが公開されています。 Rev38とわかるようにドラフトは38回ぐらい更新されていて、ちょっとづつ追記されたり変更されたりして結構な変更履歴があります。 Growing #ECMAScript 2015(ES6) Drafts :) pic.twitter.com/tV60cjdmM8 — azu (@azu_re) May 3, 2015 これだけ長い間(4年ぐらい?)やってるとある時点では正しかったかもしれないけど、最終版では違うものになってるという挙動があったりします。 例えば、class構文で以下のようにして定義したmethod()
Intro 長いこと議論になっていた ES Modules の Node における扱いに一応の決着が付き、 .mjs という拡張子が採択された。 この拡張子の意味と、今後ブラウザと合わせて Universal JS を実装していく上での作法が見えてきたことになる。 合わせてエコシステムが対応していくことで、長年の夢だった JS のモジュール化を進めていくことができるだろう。 ES Modules 徐々に揃いつつある ES Modules(ESM) の仕様は TC39 で行われており、その仕様については主に以下のような部分になる。 import や export と行った構文 module 内はデフォルト strict mode module でスコープを閉じる module 内の this は undefined etc 逆に以下は TC39 での策定範囲外となる どう Module を読
Intro XHR から fetch() に積極的に移行しづらかった最大のミッシングピースとして、中断できないという問題があった。 これは、 fetch() が選んだ Promise ベースのインタフェースにおいて、キャンセルをどうするかという議論と絡み、長く決着が付かずにいた問題である。 最近、やっと話が前進したので、ここまでの経過を解説する。 Fetch のミッシングピース fetch() は、ブラウザが発行するリクエストと、取得するレスポンスを扱う低レベルなインタフェースとして策定が始まった。 DOM の API が Promise ベースに移行しつつある流れを汲み、 fetch() もまた Promise を返す関数一発スタイルになった。 クラスからインスタンスを生成しメソッドを呼ぶ XHR スタイルでは、インスタンスを再利用した場合の挙動などを含め、オブジェクトのライフサイクルを
本稿は、JavaScriptのテストについて最も重要な根拠、用語、ツール、アプローチなどの知識を身に着けることを目的とした簡略版ガイドブックです。本稿で検討する数々の側面に関する最新の秀逸な記事も紹介しつつ、私たちが経験的に得たことも多少付け加えたいと思います。 Facebookによるテスト用フレームワークであるJestのロゴをご覧ください。 見てお分かりのように、このフレームワークは「苦痛のない」JavaScriptのテストをスローガンに掲げています。しかし、 “次のように言う人” もいます。 苦痛のないテストなんてあり得ない。 実際、Facebookはこのスローガンを掲げるだけの素晴らしい理由があります。一般的にJSのデベロッパは Webサイトのテストにあまり満足していません 。JSのテストには制限があり、実装が難しく、低速である傾向があります。 一方、正しい戦略を立てて適切にツールを
KibelaのフロントエンドをES2015からTypeScriptに絶賛移行中です。 www.typescriptlang.org で、なぜ flow じゃないくてTSなのかって話です。 flow vs typescriptである理由は、どちらもJSのスーパーセットをうたう静的型付きのaltJSだからです。この時代にあえてaltJSを導入する理由としては静的型があるというのが必須で、かつ学習コストを考えるとJSのスーパーセットであるのが望ましいでしょう。 言語仕様 言語仕様の点から言うと、決定的な差はないと思っています。 メリットもだいたい同じで 生産性: エディタの補完をJSよりも賢くできるので、より少ない脳のワーキングメモリでコードを書ける 堅牢性: コンパイル時に(=多くのケースではエディタで)typoなどの間違いを検出できるのでバグを減らせる 学習コスト: JSをベースにしており、
このドキュメントの目的 自分は趣味でFlowをずっと使っていて、またプロダクションでも今まで3プロジェクトほどにFlowを導入した。その知見。 「Flow は便利そうだけど、怖い」「いれてみたら色々ハマったからクソ」「わからん、なにもかも…」という人に対し、自分がいままで出くわしたパターンや、聞かれた疑問について、メジャーな解法を提示する。 なぜFlowを導入するか Babel から段階的に導入することが出来る React の JSX にも推論を入れることができる 部分的に適用できる ASTがES準拠であり、ESLintなどがツールが使える(TSは独自AST) それ自身ランタイムに全く影響はないので落とすのも簡単 実際にはReactと一緒に使うのが、エコシステムもユースケースも揃っていて、一番効果を発揮するだろう。それか、小さい npm モジュールを自分で書くとき。 型のメリット/デメリッ
JavaScriptのデバッグに苦労しているなら、Nodeのデバッガーを試してみてはどうでしょうか。Visual Studio Codeならさらに手軽です。 袋小路です! 何時間も費やしていろいろ試してみたけれどもうまくいきません。コードをじっと吟味してもエラーになりそうなところはありません。2、3回ロジックを見直して、何度も実行しています。単体テストも助けにはならず、同じく失敗してしまいます。もはやどうしていいか分からず、虚空を見つめたくなります。ひとり闇の中にいるように感じて、だんだん腹が立ってきます。 こんなときの自然な反応は、コードの品質を落とし、邪魔なものを全部捨て去ることです。コードのあちこちにprintをちりばめて、なにかうまくいくことを祈るわけです。これでは暗闇で的を狙うようなもので、望み薄なことが分かるでしょう。 よくある話だと感じたのではないでしょうか。今までに数行以上
anond.hatelabo.jp nida3001.hatenablog.com 上記のブログに刺激されて私もフロントエンドというかJavaScriptに対する思いを綴ったポエムをば。しかし、なんか書くのダルいので、大分大雑把にかくぞ。 さて、さっそく結論を述べよう。今のフレームワーク論争やらに対する解決策はVanillaJSを使うってことである。 フロントエンドSPAのフレームワークについて まず、今のほとんどのフレームワークが使えないってのはそのとおりである。その話してみよう。その理由は、「フロントエンド」 ってのは一括りにできないからである。「ハッカーと画家」のとある言葉をアレンジして言えば「フロントエンドはユーラシア大陸のようなものである」。フロントエンドが関わる範囲が大きすぎるのである。ヨーロッパもあればアジアもあれば中東もあるという感じである。 範囲が大きすぎて、フレームワー
JavaScriptを使うことが当たり前になったいま、HTMLだけでなくJavaScriptを書くときにもアクセシビリティに配慮する必要があります。 JavaScriptコンポーネントのアクセシビリティを高め、ユーザーがWebサイトやWebアプリをより快適に使用できるようにするためのコツを紹介します。 以前の記事『Writing HTML with accessibility in mind(アクセシビリティに配慮したHTMLを書く)』で、どうしてWebアクセシビリティについて考えるようになったのか、また、どのように学んだのか説明しました。そして、マークアップを改善して、Webサイトのアクセシビリティを高めるためのコツを紹介しました。中には基礎的な内容も含まれていますが、どれも価値のあるものです。こうしたコツをすべてまとめると、フロントエンド開発において特に重要な2つの不文律ができあがりま
SnippetsLabにいつも使う関数まとめるついでにQiitaにもメモっとく。 汎用関数 Htmlタグを除去 /** * Htmlタグを除去 * @param {string} str Htmlタグが含まれた文字列(<h1>サンプル文字列</h1>) * @returns {string} Htmlタグ除去された文字列(サンプル文字列) */ const removeHtmlTag = function (str) { return String(str).replace(/<("[^"]*"|'[^']*'|[^'">])*>/g, ''); }; /** * URLをパースしてGET値のオブジェクトにする * @returns {{}} GET値のオブジェクトです。 */ const purseQuery = function () { const result = {}; cons
eeGeo eeGeoは、「グランド・セフト・オート」や「レミングス」などのクリエイティブディレクターであったイアン ヘザーリントン氏が2010年9月に設立した3D地図を提供する会社です。 日本では、NTTドコモがライセンス供与を受け、屋内3Dマップの提供などを行っています。 今のところ、日本では3Dで表示できる地域がないのですが、ゲーム業界のノウハウを用いた地図サービスとして個人的に期待しています。 登録すれば個人ユーザーでもAPIを使用することができるので、紹介がてらサンプルを載せておきます。 Web版サンプル example 公式サイトに登録し、ダッシュボードから「Create new app」ボタンをクリックして「API Token」を取得してください。 スタイルシートとライブラリを読み込みます。 <link href="https://cdnjs.cloudflare.com/a
えいる/ひむひむさんをゲストに迎えて、9月に広島で開催されるRubyKaigi 2017やReduxについて話しました。 Show notes RubyKaigi 2017の話 RubyKaigi 2017 あのRubyKaigi(本体)がなんと広島開催決定!!! 2017年9月18日(月・祝)から20日(水) 日本 Ruby 会議 2007 ドリンククアップ, drinkup Hiroshima.rb Rebuild Akira Matsuda (a_matsuda) さんのRebuild出演回一覧 宮島, 厳島神社 こいわし (カタクチイワシ - Wikipedia) 参考: 広島おいしい地魚情報 - 広島県ホームページ CGI - Common Gateway Interface Rackのわしのpull requestとそのマージされた様子 (自慢) そのコミット (Fix sem
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く