2019年版: 脱Babel!フロント/JS開発をTypeScriptに移行するための環境整備マニュアル - Qiita
2019年版: 脱Babel!フロント/JS開発をTypeScriptに移行するための環境整備マニュアル環境構築TypeScriptライブラリReact TL;DR いろいろ書いていますが、一番書きたかったのは最初のライブラリと最後のReact Componentのプロジェクトの作り方ですね。ぱっとnpm installして、最初から型定義ファイルが入っていて、@typesを持っているライブラリを探したり、自分で.d.tsを書いたりしなくてもいい世界がやってきて欲しいな、という気持ちから書いています。 ここで紹介したTypeScript環境構築はすべて、自分用にYeomanのテンプレートとして作成したので、以下のジェネレータをインストールして選択したらそれでおしまいです。 @shibukawa/typescript (npmには公開していないので、checkoutしてビルドしてインストール
チョットできるGoプログラマーになるための詳解GoDoc - Qiita
上の2つがCLIで、下の2つがブラウザです。歴史的な経緯を見てみましょう。 〜1.1: go docはバンドルされているツールで、ソースもgo本体に同梱 1.2: go docは別のリポジトリにわけられてgodocになり、go本体から外れた 1.3: godocで-analysisオプションが追加 1.5: 新しい"go doc"コマンドがgo本体に同梱 1.11: godocがウェブだけになるため、go docを使えというアナウンスが出るように 1.12: godocが-httpだけをサポートしてCLIの機能は削除予定 1.13: godocのwebサーバーが同梱されなくなって手動でのインストールが必要に 1.13～: 既存のgodoc.orgから、go modのプロキシサーバーの情報をもとにドキュメントをホスティングするpkg.go.devが運用開始 わかりましたか？よくわかりませんよ
イマドキのJavaScriptの書き方2018
PySpa統合思念体です。これからJavaScriptを覚えるなら、「この書き方はもう覚えなくていい」（よりよい代替がある）というものを集めてみました。 ES6以降の難しさは、旧来の書き方にプラスが増えただけではなく、大量の「旧来の書き方は間違いを誘発しやすいから非推奨」というものを作り出した点にあります。5年前、10年前の本やウェブがあまり役に立たちません。なお、書き方が複数あるものは、好き嫌いは当然あると思いますが、あえて過激に1つに絞っているところもあります。なお、これはこれから新規に学ぶ人が、過去のドキュメントやコードを見た時に古い情報を選別するためのまとめです。残念ながら、今時の書き方のみで構成された書籍などが存在しないからです。 たぶん明示的に書いていても読み飛ばす人はいると思いますが、すでに書いている人向けではありません。これから書くコードをこのスタイルにしていくのは別にいい
JavaScriptはなぜトレンドが毎年変わると思われていたのか - Qiita
JavaScriptはなぜトレンドが毎年変わると思われていたのか JavaScriptのエンジニャーは口を開くたびに出てくるツール名が違う、いつも環境設定をしている、みたいな話をよく聞きます。実際、それを揶揄するようなエントリーが人気だったりします。 とはいえ、JavaScriptを実際に使い込んでいる人は別にそんなに大きな変化だと思っていない節があって、台風は外周部ほど風速が速い、みたいな印象を感じます。 カンブリア紀のJavaScript ウェブサイトをパカパカ動かすための言語でした。DHTMLです。FireBugが出る前のJavaScriptを開発していた人類は、念力デバッグを駆使していました。あるいはalert()。 三畳紀のJavaScript prototype.js、jQuery、Closure Compiler、YUI、mochikit、Ext.jsなどの時代。JavaSc
サーバーサイドレンダリング不要論 - Qiita
サーバーサイドレンダリング、Isomorphic、Universal JavaScriptなどの言葉をよく見かけます。なるほどね、良さそうだね、外部公開するサービスを書くことがあったら挑戦してみたいね、Mithrilにもisomorphic-mithrilってのをがんばっている人がいるし、みたいなことを漠然と思っていたのですが、最近ASCII.jpのシステムコールプログラミングの連載を書いていて、あらためてHTTPの仕様を見返してみて、逆にサーバーサイドレンダリングをしない方がいいのではないか、と思い始めました。 追記(23:30): サーバーサイドレンダリングと書いていますがUniversal JavaScriptみたいな凝ったビューの更新の意味です。 サーバーサイドレンダリングの欠点 サーバーサイドレンダリングのメリットとしてあげられるのは次の2点です。 検索エンジンのクローラー向け
Browserify/WebPack時と、node.jsの実行時で読み込むファイルを変える - Qiita
Browserifyを使うと、node.jsと同じような書き方ができて便利です。WebPackも人気ですよね。 ですが、node.jsとブラウザでは読み込ませるファイルを分けたいことがよくあります。各環境のロケールを取得するに、ブラウザだと navigator.language 変数をのぞくだけでOKです。デスクトップ環境とかサーバでは os-localeパッケージを使いたいですよね。でもos-localeパッケージをブラウザにバンドルしたくはないです。 それぞれ、次のようなファイルで同じAPIで関数を用意します。 const osLocale = require('os-locale'); module.exports = () => { return new Promise((resolve, reject) => { osLocale((err, locale) => { if (e
オレの最弱のES6開発環境 - Qiita
ブラウザのES6サポートが急速に良くなってきています。社内ツールとかElectronとか、ブラウザの普及率を気にしなくていい環境ならそろそろ使えるのではないかと思って調べたり試してみたりしています。 更新 https://caniuse.com/#search=es6 http://kangax.github.io/compat-table/es2016plus/ これを見るともうほぼ実装は完了していますね。Node.jsも対応していますし使えるブラウザが限定できるならもはや変換なんかしなくても大丈夫。注意点としては以下の2つ。 IE11は渋い ES6 modulesはまだまだ ソースをES6で書いて、結果もそのままES6という手抜き開発に使えるツールのメモです。手抜きなので、おそらく経年変化の影響はほとんどないはずです。対象としてはブラウザだったり、ElectronでのSPA開発です。
pyenvが必要かどうかフローチャート - Qiita
pyspaの統合思念体の渋川です。 「pyenv使いましょう！」系の記事、全部ゴミ — Yoshifumi YAMAGUCHI (@ymotongpoo) September 29, 2016 これはpyenvがダメではなくて、pyenvをとりあえずインストールしておきましょう記事がダメという意味だそうです。すでにとんぷーが5年前にこの問題について書いています。これを読んで分かる人には不要です。 この記事では「便利」と「必要」は分けて考えています。後者にフォーカスしています。 前提知識 Environment Isolation Tool(環境分離ツール)というカテゴリの開発補助ツールがあります。pip install Sphinxとか書いたら、ライブラリはグローバル空間に入っちゃいます。複数バージョン入れられません。そんなときに使うのが、この環境分離ツールです。最近はいろいろな言語がこれ
オブジェクト指向の欠点をカバーする努力 - Qiita
オブジェクト指向の問題点 インターネッツを良くするポエムというのは、「こういう問題に対して、こういうソリューションでカバーしてきたよ」をみんなでシェアすることだと思うので、ここに挙げられていることの一部に対して、オブジェクト指向界隈が今までこんな工夫をしてきたよとか、僕の目から見えている「技術発展の流れ」について書いてみようと思います。まあ僕も全ジャンルをまんべんなくやっているわけじゃないし、一部想像で補っている部分もあります。他にもあればぜひシェアしてください！ 上記のサイトで書かれている内容のうち、 オブジェクトのつながり具合が手続きでしか表現できない/知識表現が手続き側に偏っている 関係性が表現できない ユーザレベルでの部品化再利用に全然なっていない について取り扱います。 オブジェクトのつながり具合が手続きでしか表現できない/知識表現が手続き側に偏っている 元は2項目ですが、内容的
オブジェクト指向と20年戦ってわかったこと - Qiita
この記事の内容 オブジェクト指向と10年戦ってわかったこと Twitterやはてブコメントを見たら、「わかりやすかった」というコメントもあったのですが、どちらかというとネガティブ方面なコメントが多く目につきました。マサカリという用語で忌憚なく意見を言う風潮については別にいいんですが、「わかりにくい」「間違っている」「古い」みたいなコメントは何も生み出さないし、みんなでニコニコポエムを投稿しあうやさしいインターネッツになったらいいなって思ったので、僕もオブジェクト指向について投稿しようと思います。 何原則？ ３原則じゃなくて4では？みたいなコメントもあったのですが、別に3でも4でも5でも重要ではないかなって思います。この4原則の出どころがどこかは知らないですが、C++かSmalltalkあたり(このあたりの話を見かけたのはJava登場前だった気がする)をターゲットとしている気がします。Jav
最速という噂のFlatbuffersの速度のヒミツと、導入方法の紹介(Go) - Qiita
GoCon 2015 Winterでは、社内での取り組みとしてExcelのパースの時間のロスを避けるために、簡易データ構造を使ってMessagePack + LZ4で圧縮して高速化したことを紹介しました。それでも十分速くはなったのですが、LTで発表のあったシリアライズ系のライブラリのベンチマーク比較でFlatbuffersが最速だったので、ちょっと試してみました。 ↑のグラフは、こちらのベンチマークの結果をExcelでグラフにしてみたものです。Gobがダントツ遅かったのでそちらは振りきっています(Gobに合わせると他のものの比較がしにくくなるので範囲を狭めた)。GoConで発表した通り、今MessagePackを使っているのはデータのキャッシュです。作成に多少がかかっても、後の読み出しが速い方がトータルとしてはうれしい領域なので、Unmarshalが最速のFlatbuffersに俄然興味を
GolangのOpenGL事情(WebGLも含むよ) - Qiita
WebGLアドベントカレンダーでの投稿です。Golangのアドベントカレンダーはまた別に書きます。 最近、GolangでOpenGLを書いているのですが、GolangのOpenGL事情についての情報がまとまっているものがあまりなかったのでまとめてみます。 Golang用の各種OpenGL/WebGLライブラリ 由緒正しいライブラリgo-gl Golangには昔からOpenGLのAPIを提供するgithubのOrganizationがあります。go-glというコミュニティです。 昔からある多くのパッケージがここのライブラリを参照しています。OpenGLを管理する非営利団体のKhronosの提供するファイルを元にバインディングを生成しているため、安全確実な堅実なライブラリです。2.1以降の各OpenGL/OpenGL ESのバージョンに対応しています。また、OpenGLを使ったクロスプラットフ
オブジェクト指向言語としてGolangをやろうとするとハマること - Qiita
埋め込み(embedded)に要注意というお話です。あるいは、GolangもC++のようなゼロオーバーヘッドを目指していると考えれば腑に落ちるよね、的な。 Goはオブジェクト指向言語っぽく使うことができます。次のような機能を提供しています。 interfaceを使ったコーディング 埋め込み(embedded)を使った実装継承 インタフェースは次のような感じです。 // ポニーは歩ける type Pony interface { Walk() } // アースポニーも歩けるので、Ponyインタフェースに渡せる type EarthPony struct { } func (ep *EarthPony) Walk() { fmt.Println("歩くよ") } インタフェースはメソッド宣言しかかけません。実装は書けません。でも、定義されたメソッドを持てば、それはすべて「これの仲間だ」という感
最速MVCフレームワークMithril.jsの速度の秘密 - Qiita
Mithril 0.2が本日リリースされました。ちょっとURLが変わったり( http://mithril.js.org/ )、API名が一部(m.moduleがm.mount)変わっていたり、コンポーネント機能がコーディング規約レベルから、専用のサポートAPIが追加されたりしていますが、0.1系と大した差はなさそうです。 某node.js会長とはいろいろ社内で話をしたりしたのですが、各種ベンチマークでもトップクラス、平均的には最速のクライアントサイドMVCフレームワークという称号を持ちながら、国内ではまだまだ知られていないMithril。レンダリング速度は仮想DOMの代名詞となったReact.jsの5倍以上(ベンチマークによります)です。 ↓ホームページから転載 ちなみにこちらのベンチマークで計測すると、MithrilはReact.jsの10倍以上速い結果になるのですが、これはちょっと計
GolangのdiffMatchPatchライブラリで行単位diffをする - Qiita
diff-match-patch便利ですよね？ これで行単位のdiffを出そうと思ったんですが、APIのリストとにらめっこしてもわからなかったのですが、検索したら大本のGoogle謹製の方のWikiにあったので、実装のメモです。 import "github.com/sergi/go-diff/diffmatchpatch" func lineDiff(src1, src2 string) []diffmatchpatch.Diff { dmp := diffmatchpatch.New() a, b, c := dmp.DiffLinesToChars(src1, src2) diffs := dmp.DiffMain(a, b, false) result := dmp.DiffCharsToLines(diffs, c) fmt.Println(result) return resu
C言語的にJavaScriptを使う - Qiita
プログラミング言語は世の中にたくさんありますし、用途や好みによって自由に使えることが多いのですが、一部どうしても置き換えができない言語というものがあります。ブラウザやFlashマクロやPhotoshopマクロのJavaScript、Action Script、GPUのシェーダ言語、Visual Basic for Application、SQLなどなどです。それでもaltJSやORMなど、直接書かないという選択肢もあったりもしますが、どうしても直接書くほうが実行効率が良かったりチューニングが効いたりします。 JavaScriptを使ったコーディングを何年かやっていると、C言語で書かれたアルゴリズムをJavaScriptに移植しないといけない事態に遭遇する機会も増えてくると思いますので、それについて説明します。 整数型としてデータを扱う JavaScriptの言語仕様ではJavaScript
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
