はてなブックマーク

リンク この記事は、次の記事と相互リンクです。 Visual Studio Code を外部エディタから開く。 - Qiita はじめに Visual Studio Code (VSCode) をIDEの外部エディタとして使用するだけでなく、VSCodeから他のエディタを使えたら、ツール間の連携がとれていいなと思ったので調べました。 かなりややこしく、かつ、他の方に役に立つと思うのでまとめておきます。 まだ調べきれていないことや、コマンド入力欄の正式な名前などがわからない所があるので、何かご存知の事あればコメントをください。 環境 環境はWindowsです。 VSCodeのインストールはされているという前提です。 コマンドラインで実行した現在(最新)のバージョンは次の通りです。 codeコマンドで起動できるのはかっこいいです。 概要 次の2つの方法があります。 tasks.json を利用

開発効率のために型チェックを望む JavaScript が動的型言語なので、静的型言語にしてしまえば開発効率があがる、というアイデアがあって、それは確かなことかとも思います。プログラムを書いていて、ある変数の型がよくわからなければ正確な処理を行わせるのって、難しいですよね。 確かに開発効率、あがると思います。 実際に自分も開発効率をあげています。しかし、型チェックは行っていますが、TypeScript や Flow とかは使っていません。 TypeScript や Flow が人気を得てきていますが、そこで行う型チェックは、素のJavaScriptにやらせてしまうこともできるので、導入前に検討してみるのもよいかもしれません。 チーム開発の場合には、型チェックを自前で行わないエンジニアにも型チェックを行ってもらうという意味で、TypeScript 等を導入する価値はたしかに大きくあると思いま

対象 Windows系の説明です。Macとほとんど同じです。 パス記号の記載などが違うかもです。 用語 npmとは node.js のパッケージマネージャーで、モジュールというかパッケージというか JavaScriptの便利ライブラリのインストールをコマンドで行えるもの。 node_modules フォルダ カレントディレクトリ配下にあり、カレントディレクトリにインストールされるモジュールの中身が配置されるフォルダ。 package.json カレントディレクトリ配置されるファイル。package.jsonにはインストールするモジュールを記入することができる。 このファイルがあるおかげで、node_modulesの中身はGitなどに登録しなくても開発環境の移行が容易になる。 package-lock.json カレントディレクトリ配置されるファイル。package.jsonでインストール指

はじめに ES2017にもなると、動かないブラウザもちらほら(IEとか)出てくるので、Babelで変換(コンパイル あるいは トランスパイル)してから動かすのが通常ですが、 npm インストールとか、webpackとか、環境つくりが少しめんどくさいです。npmスクリプトでやるのかとか、gulpか、とか、browser-syncに受け渡すにはどうするべきか、とか、とか、少しじゃなくて、だいぶめんどくさいですね。 どうせ数年もしたら、また違うパッケージャーとかタスクランナーとかが流行って、前のが廃れて使わなくなるんでしょう？ ならば、環境構築なんて無視してしまいましょう。 しかし、Babel変換は使いたい。 ということで、環境構築無しにBabel変換します。 HTMLだけで、babel変換します。 環境を整えなくても、CDN、つまりScriptタグにBabelをリンクすることで、Babelの機

Babelのコマンドラインと、Browserifyを使って、ES2015/ES2016/ES2017のJavaScriptが大体全部が、IE11でも動くようにして動作確認を行いました。 requireを1箇所つかうだけなので、Browserify じゃなくて WebPack でもいいと思うので、お得意な方はそちらで使ってください。 対象 Windows環境ですが、たぶん Macでも使えます。 ES2015/ES2016/ES2017 を Chrome と Firefox で動作確認する 2018/02/27現在の Win版Chrome と Firefox では、Babel変換しなくても全部動いてます。その動作確認を次のファイルによって行います。 index.htmlをブラウザで開くと、エラーもなく[test finish]とメッセージが表示されれば、動作確認完了です。 IE11では当然エラ

Google SpreadSheet はとても便利にWebのデータ取得ができます。 どのようにやるのかまとめておきます。 Importxml は不要 セルの中身に、=Importxml を記載してワークシート関数を使ったやり方で手軽にデータ取得できますが、そのやり方ではすぐに限界がきます。 一番の問題点は、低速すぎることです。シートを開いたときに全件読みにいくので、すぐに遅くなって実用的じゃなくなります。 また、他の問題点としては、細かな制御ができないこと、です。 軽く何か試しに動かすなら Importxml を使うのもいいのですが、実用的なものを作ろうとすると限界があります。 ですので、SpreadSheet のマクロとして使える Google Apps Script(GAS) と呼ばれる、JavaScript を使ってデータを取得します。 このあたりは、Excelのワークシート関数を使

これって、可読性低くないかなあ。 正規表現リテラルをしらなければ文字列が指定されているのかどうなのかもわからないし、縦棒がorを表すのも知っておかないといけないし、 ？？？何このドットテストって？？？って気分になる。 appleやbananaを文字列変数に置き換えようとすると、途端にコード書き換えなきゃなんないわけで.... というのは世代の違いかも かもねかーもね、そーぅかーもね。 正規表現ネイティブ世代にはすぐにわかるのかもねー。 そうかもしれないので、可読性が高いとか低いってのは、主観的なものなわけで、万人が同意するレベルの可読性の高い低いというものはあるだろうけど、万人が同意するレベルではない、可読性の高い低いというのも、あるわけだろうね。 ということで、ラッピングします。 ということで、世代の違いを超えて最も可読性を高くするために、自作関数 contains を作ります。 あ、名

はじめに どんな言語でもテストコードは簡単につくれます。 [JavaScript テストコード]で検索すると、テストフレームワークの使い方がでてきて 「いままでテスト書くの嫌だったけど、この際、まなんでみた。」 「簡単で良かった。」 みたいな、xUnitの使い方。みたいなことが書かれていて、少し"ん？"と感じます。 なぜかというと、テストってのは、テストフレームワークを使わなきゃできませーん。という勘違いしている人が非常に多いように感じるからです。テストを書いている人の、10人中8人は、その勘違いしています。(体感) aUnitでも、bUnitでも、cUnitでも、dUnitでも、eUnitでも、fUnitでも、 JUnitでも、NUnitでも、xUnitでも、QUnitでも、ともかくなんのテストフレームワークでもいいですけど、そんなものはどれでもいいんです。 どれもやっていることの本質は

元記事 以前こちらの記事で、requireで書ける node.js や browserify に対応し かつ、素のHTMLでのscriptタグリンクでも動作するような モジュールの書き方をまとめました。 JavaScriptの名前空間とモジュール分割方法 require(node.js/browserify) HTMLScriptタグ WSH フル対応 - Qiita モジュールを作成する場合は、このようにしておいた方が、様々な環境用に提供できる汎用的なライブラリにできます。 ただ、これは呼び出し側では、HTMLのscriptタグを使う場合には、グローバル唯一の名前空間を使うという、やり方でした。 require のない環境でも require を使えるようにする 今回は require のない環境でも require 使えるようにして、モジュール側の汎用性だけではなく、モジュールを使用す

この記事は、JavaScript全置換(正規表現使わない)の速度比較 - Qiita の続きです。 続き 先の記事のコメント欄で、@mpywさんに、教えていただきました。 コストとしては，漠然としたイメージですが 機械語レベルでのループ処理: 1 正規表現のコンパイル処理: 10 VM・インタプリタレベルでのループ処理: 100 のような感じで考えていいと思います。コンパイラ系では 普通にループ処理を書く → 1 正規表現を書く → 1+10=11 となるため前者のほうが速く，VM・インタプリタ系では 普通にループ処理を書く → 100 正規表現を書く → 1+10=11 となるため後者のほうが速いイメージでしょうか。 まぢかよ！正規表現の方がはやいなんて！！！びっくりだぜ！ ということで、積極的に正規表現を使っていくことにしました。 あ、嘘です。可読性が低いので、正規表現使いたくないです