Let's start programming fun! - たのしくプログラミングをはじめよう!

Let's start programming fun! - たのしくプログラミングをはじめよう!
TypeScriptのコードでは、export {}; という記述を見かけることがあります。これはECMAScriptの構文ではあるものの、これが使われる背景にはTypeScript特有の事情があります。この記事では、export {}; がなぜ使われるのか、どのような効果があるのかを解説します。 export {}; とは この構文は、exportというキーワードから分かるように、モジュールに関連する構文です。 一般に、export { ... };という構文は、既存の変数をモジュールからエクスポートするために使われます。例えば、次のようなコードが考えられます。 const foo = 42; const bar = "hello"; const banana = "banana"; export { foo, bar as hello, banana as "🍌", }; 変数をエク
この記事は NIJIBOX Advent Calendar2019の13日目の投稿です。 #背景 何かしらのロジックを作る際に、仕様変更に強いコードを書きたいぞい!ってエンジニアだったら思いませんか。今の仕様なら動くけど、もし仕様が変わり、そのために関数全書き直しとかしんどみが深すぎます。今回はこのしんどみを少しでも回避できるように柔軟なコードを書くぞい!って記事です。 ページネーションコンポーネントを例にしますが、なぜページネーションなのかというと僕が最近業務でページネーションを作り、かつ仕様の変更に強いコードの大切さを実感したからです。 #そもそもページネーションとは ページネーション(pagination)とは、日本語で丁付け、ページ割りという意味で、Web制作においては、検索結果一覧など、内容の多いページを複数のWebページに分割し、各ページへのリンクを並べてアクセスしやすくするた
JavaScript での時刻操作に Moment.js ではなく Day.js を利用し続けている理由2020/09/21 昨日、拙作の Nuxt.js プラグインである @nuxtjs/dayjs の v1.2.0 をリリースしました。 このプラグイン自体は2019年3月に開発をはじめて、おおよそ一年半ほど管理してるのですが、それ以前から JavaScript での時刻操作では Day.js を使ってきました。 Moment.js のプロジェクト終了が告知され、時刻操作ライブラリに注目が集まっていることなので、今一度 Day.js の採用理由についてまとめてみます。 Day.js について iamkun によって開発されている時刻操作のライブラリです。Moment や date-fns などは Organization によって管理されていますが、時刻操作ライブラリとしては珍しく個人に
Sick of boring JavaScript newsletters?Bytes is a JavaScript newsletter you'll actually enjoy reading. Delivered every Monday, for free.
設定不要のビルドツール parcelというビルドツールが空前の勢いでGitHubスターを集めており、リリース数日で5000スターを超えています。今日だけでも1000スター以上増えており、Googleなどの有名企業リポジトリ以外でこのスピードで人気がでるのは異例です。 https://github.com/parcel-bundler/parcel https://parceljs.org/ 実際に試してみたところ、これはwebpack一強時代を終わらせるレベルの使いやすさだと確信しました。 作者はAdobeのエンジニアで、その他著名エンジニアも続々と参加している様子です。 webpack疲れ webpackが出た当初、webエンジニアはgulp/grunt疲れの状態だったことを覚えている方もいるかと思います。 webpackの統合された設定ファイルは、タスクランナーで逐次処理していたものを
2017-11-09「フロントエンド開発に再入門する」タスクフォースの進め方こんにちは。開発本部の宍戸です。 メドレーでは定期的に、テーマに沿って組織の技術的な底上げを行うための機会(タスクフォースと呼んでいます)を行っています。そのタスクフォースの1つとして先日、フロントエンド開発力のベースアップを目的としたタスクフォースを行いました。本記事では、その取組みについてご紹介したいと思います。 背景メドレーには現在 20 人弱のエンジニアが在籍しており、その約半数がサーバーサイド出身者です。また普段の開発においては、一つの機能をフロントからサーバーサイドまで一貫して一人が担当するケースが多くあります。サーバーサイド出身者のフロントエンド開発のスキルセットには多少ばらつきはあるものの、普段の開発業務ではレビュー等でそれぞれサポートしつつ開発を行っています。 しかし、フロントエンドの基礎的な部分
一年以上前の記事なので、コードが古いです。気をつけて読んでください。 PWAとは? 目的 技術スタック Service Worker PWAのview App Shell Content キャッシュ戦略 読み込みフロー Web App Manifest デザイン FirefoxとChromeしかService Workerないけどどうするの? ネットワーク 実装 ライブラリ webpack-offline 構成 ファイル ルーティング アセットのインストール API周り SSR 資料 さいごに そういえばPWAの実装したことがなかったなと思ったので少し触ってみた。 PWAとは? PWA(Progressive Web Apps) インストールが不要で、不安定なネットワークでも素早く起動し、プッシュ通知を可能にします。 また、ホーム画面にアイコンも表示でき、アプリと同様の扱いをすることが可能
本稿は、JavaScriptのテストについて最も重要な根拠、用語、ツール、アプローチなどの知識を身に着けることを目的とした簡略版ガイドブックです。本稿で検討する数々の側面に関する最新の秀逸な記事も紹介しつつ、私たちが経験的に得たことも多少付け加えたいと思います。 Facebookによるテスト用フレームワークであるJestのロゴをご覧ください。 見てお分かりのように、このフレームワークは「苦痛のない」JavaScriptのテストをスローガンに掲げています。しかし、 “次のように言う人” もいます。 苦痛のないテストなんてあり得ない。 実際、Facebookはこのスローガンを掲げるだけの素晴らしい理由があります。一般的にJSのデベロッパは Webサイトのテストにあまり満足していません 。JSのテストには制限があり、実装が難しく、低速である傾向があります。 一方、正しい戦略を立てて適切にツールを
この一か月分の学習成果を整理したリポジトリを作ったので、その成果についてまとめておく。 作ったサンプルプロジェクトだけを手軽に欲しければ、このリポジトリを clone してほしい。 taichi/js-boilerplate master ブランチには、ミニマムな JavaScript 開発環境がサンプルコード付きで入っている frontend ブランチには、React/Redux/webpackなウェブアプリケーション用の開発環境が入っている デフォルトブランチにしてある electron ブランチには、frontend ブランチの内容に加えてElectronでアプリケーションを開発するための環境が入っている はじめに 最近の JavaScript について 僕は仕事として JavaScript を書いている訳ではないけども、この半年くらいの間にちょっとしたツールならいくつか作った。
JS しか書いてないんだなって人は筋悪いものをありがたがっていたりする印象はある。しかし筋悪いものをありがたがるみたいなのはどこにでもいるので、JSがどうとかは直接は関係がないはずではあると思う。JSしか書いてない人とPHPしか書いてない人は似たようなもんで、単に広範囲の知識に興味がないだけな気がする。 それはともかく「これは筋悪そうだな」っていう感覚がどこからくるのかよくわかってないので、現時点で思いつく限り雑にメモしておく。 割の合わなさ 「これは何の問題を解決してるんだろう」と思ってドキュメント読んだりソース読んだりした結果、大したことを解決してなくて、その割に実装量が多いとか学習コストが高いと、筋悪いなあと思う。 フットプリントや学習コストに対して提供されるモノが「割に合わない」のは筋が悪く感じる。 将来性のなさ 「あ、これはただの流行だな」みたいな、5年後には消滅してるなというも
文字列のパースをする必要がある時、どんな文字列にでも何でもかんでも正規表現で処理しようとするエンジニアをたまに見かける。 正規表現は確かに文字列を扱うための強力な手段だが、万能ではない。正規表現の性質上、そもそもパースできない文法があるからだ。従ってそういうケースの時には正規表現ではなく別の方法を使ったほうが良い。正規表現を無理やり使っても、バグを埋め込んだり、メンテナンスが難しかったり、正しく文字列をパース出来なかったりで良いことはあまりない。 正規表現がパースできない文字列 正規表現が苦手とする文法で一番よく言われるのは、再帰的な構文を含む文法である。例えば、括弧つきの数式なんかがそうで、1+1 でも (1+1) でも ( (1+1) ) でも ( ( (1+1) ) ) でも ( ( ( ( 1+1) ) ) ) でも、という風にいくらでも入れ子にできる。正規表現では、こういった文字
�フレームワークを利用した�シングルページアプリケーションの制御 GMOインターネット次世代システム研究室の勉強会発表資料。 2015年12月作成。 案件対応期間は2015年4月-8月。
最近は SPA とか React といった話題が尽きないが、自分は結局 フロントエンド JavaScript は jQuery が最もいいと感じている。それはそれら SPA の JavaScript をいじった経験を踏まえての感想。 理由としては、「 やりたいことができにくい 」これに尽きる。 最新を追うということ 自分が最初にSPAを触ったのは AngularJS だった。なるほど、この ng-repeat や $route, $scope などを使えば、今までサーバサイドでやってたようなレンダリングが表側で制御できるようになる!と感動したものだった。この気持ち良さはきっとサーバーサイドでごにょごにょやっていた経験のある人ならなおさら感動するものだ。 さて、じゃあといって「次作るのは SPA のサービスにしよう!」と意気込んで初めて見たとする。それで作っただけで話題になるし、エンジニアと
この記事はJavaScript Advent Calender 2014の10日目の記事です。 altjs作りたいやろ 半年前にこんなLTをやった。未完成で放置するのは気持ち悪いので、この機会に完成させようと思った…んだけど、advent当日の時点でまだ完成してない。すまんな。ただ知見は多少溜まったので、基本的なaltjsの作り方と合わせて紹介しようと思う。 altjsってどうやって作んの? 方法は様々だけど、 文法をPEG(pegjs)で記述する ソースコードを、Parser APIで定義されるASTに変換するロジックを書く 変換されたASTを、escodegenでJavaScriptのコードにさらに変換する というのが今ならやりやすいと思う。結局ある構文をjsに変換するだけで、変換は既存のツールを使えるので、実はそんなに広い知識を要求せず、0から王道のコンパイラを作るみたいな壮大な話に
* ネタ元 Rubyのブロックつらい問題を解決する暗黙のブロックパラメータ - Qiita RubyPythonのブロックラムダつらい問題 Pythonでショートコードをしようとおもうと、時々こういうことが起きます。 map(lambda it: it.upper(), ['foo', 'bar', 'baz']) それぞれの要素に対してupcaseを適用する、ただそれだけのためにitを2回も記述しなければなりません。っていうかそもそもlambda:って読みにくいです。 Pythonはラムダをあまり使わない言語なのでこの様なコードを書く機会は少ないですが、それでもちょくちょく出番があり、やがてあなたは辟易するはずです。 <中略> 参考になる例として、ClojureやScalaでは暗黙のパラメータ(プレースホルダ)を導入することでこの問題を上手く解決しています。 <例は省略> やりましょう
本文には反映していませんが IE10で Error#stack が実装されました http://blogs.msdn.com/b/ie_ja/archive/2012/05/17/diagnosing-javascript-errors-with-error-stack.aspx JavaScript では例外が発生すると例外オブジェクトが生成されます。 この例外オブジェクトの仕様は標準化されておらず、各ブラウザで実装が異なります。 最新のブラウザで JavaScript の Error オブジェクトや Error から派生しているオブジェクトが持つ属性を調べてみました。 Safari Stable (Safari 5.1.1) try { throw new Error("hoge"); } catch (err) { var i, ary = []; for (i in err) {
僕がJavaScriptでライブラリを選定する際、迷ったら小さいものを使う。その理由について。 前提 前提として、枯れた環境で大きいフレームワークができるのは理解できるし、メリットも大きい。あるいは言語それ自身と区別できないぐらいに発達したフレームワークに依存するのも理解できる。RubyにとってのRailsとか、ErlangのOTPとか(いや、これは詳しくないけどそうなんだろうなっていう予想なんだけど)。 危険信号 今のJS界隈は動きが早すぎて、何に依存するのも危ない。とくにフレームワークと銘打たれたものは、でかすぎてどれも危険信号を放っている。 数年後、廃れてしまったフレームワークで開発し続けるのは、僕個人としてもあまり関わりたくないし、現場の離職リスクとして数字に出るだろうし、採用後の教育コストの問題になる。だいたいそういうものは元の設計者もいなくなるものだ。プロダクトの死を意味する。
2009年01月31日01:00 カテゴリLightweight LanguagesMath アルゴリズム - 同じ文字列のn回繰り返しをlog n回で作る方法 これなのですが.... 同じ文字列のn回繰り返しを作る最速の方法を探求してみた - muddy brown thang ちょっとした事情により、ある文字列のn回繰り返しを作る関数 (PHPでいうところのarray_repeat(), Perlで言うところの「"..." x n」、RubyやPythonで言うところの「"..." * n」) を高速に実装しなければならない状況に遭遇したのでベンチマークをとってみたところ、その結果がとても新鮮で驚いたので、これを共有しつつもダメ出ししてもらえないかなーと思って晒してみることに。 なぜかもっとシンプルな奴がなかったので。 以下、比較。初期値はIEにあわせてあります。Firefox/Saf
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く