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してビルドしてインストール
アダプティブなGUIコンポーネントの考察
よくあるユースケースである、ヘッダーのハンバーガーメニューとドロワー。どうやって実装するのが良いでしょうか？ よくある実装としては、メニューとドロワーが置いてあるところの親のコンポーネントを置いて、ヘッダーのボタンが押されたコールバックを受け取り、ドロワーの表示フラグをオンにする、みたいな実装かと思います。明示的に関係を記述する、という感じ。 ですが、Angularではおそらく別の回答になります。Angularには暗黙的なインタラクションを可能にするAPIの数々があって、実際それを活用したコンポーネントなどもあるので、React/Vue/Mithrilとはちょっと違う世界が見える気がしたので、それを紹介します。 最近の主流のフロントエンドの世界観 まずは、Angularの話の前に、このエントリーの前提となる認識を合わせておきましょう。 最近は、フロントエンド界隈では、まずコンポーネントとい
Angularで、Angular Materialのテーマに対応するライブラリを作る
Angularを使う Angular Materialを使う Angular Materialにカスタムテーマを設定する アプリケーションと同一環境で動作するライブラリでAngular Materialのテーマを利用 あたりは記事がたくさんあるのですが、ライブラリを作る、そのライブラリでAngular Materialのテーマを利用する、あたりの情報が見当たらなかったので（日本語でも英語でも）、せっかくなのでまとめました。Angular v6で試しています。 Angularのcliはインストール済み、チュートリアルの最初ぐらいはやった、を前提にして進めますが、ここで紹介するテクニックは、TypeScriptを使い、何かしらのフレームワーク用のライブラリを開発する、テーマに対応するUIフレームワークを作る、CSS in JSを積極的に活用しつつ、UIフレームワークと外部ライブラリでテーマを合
チョットできる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つに絞っているところもあります。なお、これはこれから新規に学ぶ人が、過去のドキュメントやコードを見た時に古い情報を選別するためのまとめです。残念ながら、今時の書き方のみで構成された書籍などが存在しないからです。 たぶん明示的に書いていても読み飛ばす人はいると思いますが、すでに書いている人向けではありません。これから書くコードをこのスタイルにしていくのは別にいい
Dockerで最小のGoのイメージを作成する（cgo編） - Qiita
「最小のNode.jsのDockerイメージを目指すスレ」、「JavaでもDockerでマルチステージビルド」というエントリーでは、Node.jsとJavaを使ったアプリケーションのイメージをなるべく小さくするトライアルをしました。 今度はGoでやってみます。ただし、Pure Goで最小というのはすでに方法があって、scratchという何も含まれないイメージを元に、静的リンクしたバイナリを配置するという方法です。 Building Minimal Docker Containers for Go Applications Goを使う場合に、一部cgoで使われたパッケージを利用したいこともあるでしょうし、雑にコマンドラインを利用することもあるだろう、ということで、今回も、できることを減らさずに（やりたいことにしたがって細かく作戦を微調整する必要がない）、なるべく小さく、という方針でいきたいと
最小のNode.jsのDockerイメージを目指すスレ - Qiita
フューチャーアーキテクトアドベントカレンダーに投稿したサーバーサイドレンダリングの代替としてPrerenderを試してみたに引き続き、JS系？ウェブ系？なエントリーです。 ECSとかEKSとか出てきて、コンテナを使うと、一つの物理ホストで、複数のコンテナをさばいて効率を上げる、というのが簡単にできるようになってきました。そのため、Node.jsのアプリもDocker化して配りたいですよね？ 次のスライドを見ると、サイズが小さいほうが良いとされています。中には静的リンクが云々みたいなトリッキーな技もありますが、そこまでがんばらない＆黒魔術にならない程度でがんばる方向でサイズを小さくしてみたいと思います。 お前のDockerイメージはまだ重い💢💢💢 by stormcat24 STEP1: Alpine + 標準ライブラリのみ 小さいというAlpine Linuxを使ってみます。クールな
GraphQLは90%のウェブサービス開発者にはまだ時期尚早ではないか - Qiita
PySpa統合思念体です。チャットで話をしたことのまとめです。何人かで雑に話をしたことのまとめで、特定の誰かの発言というわけではなく、一種の怪文書です。 さて、GraphQLが世間を賑わせ始めています。Facebookが開発し、GitHubも機能提供をし始めました。GraphQLはRESTの未来か？みたいな論調もありますが、新しいものが出てくると既存のものをサンドバックにして「まだそんな古いの使ってやがるのかよwwwww」みたいな煽りをするのはもはやウェブ界隈の風物詩になっていますが、そういう信者発言をして「ああ、あいつまた踊らされてるな」「あいつ技術を見る目がないな」みたいに思われないように、少し冷静にGraphQLの立ち位置や、今後予想される流れについて考えてみます。 LSUDsとSSKDs WebAPI The Good Partsでも紹介されていた概念として、Netflix社のAP
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とか書いたら、ライブラリはグローバル空間に入っちゃいます。複数バージョン入れられません。そんなときに使うのが、この環境分離ツールです。最近はいろいろな言語がこれ
Go最後の秘宝「GUI」を探しに行く - Qiita
Golangができること、むしろ「得意」と言われるものはすでにたくさんあります。 クロスコンパイルが得意だし依存が少ないバイナリができるから、いろんな環境で使えるコマンドラインツールを書くにはGoがいいよ パフォーマンスが高いし文字列処理もやりやすいので、高速なAPIサーバが得意。gRPCでもHTTP/2でも Webアプリケーション・フレームワークも増えてきていてウェブサービス作れるよ ビルドシステムとパッケージマネージャ内蔵なので、gitから簡単にパッケージをダウンロードしてきたり、◯makeコマンドとか◯runtとか◯owerで消耗しなくて済む gopher.jsでJavaScriptにもなる 逆に今まであまり良い解がなくて、「Goにはちょっと不向きだね」と言われ続けていたのがGUIです。鳴り物入りで出てきたGXUIが開発が止まってしまい、それと同じぐらいにshinyというものが開発が
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("歩くよ") } インタフェースはメソッド宣言しかかけません。実装は書けません。でも、定義されたメソッドを持てば、それはすべて「これの仲間だ」という感
OracleとGoogleの判決文を斜め読む - Qiita
(7/7追記)僕は斜め読みだったんですが、もっときちんと読んだ上で解釈を書いてくれている方がいます。僕も時間をとって全文を読みたいとは思っていますが、まだ時間がかかりますし、yudaiさんの会社の方が妥当性は高いと思いますので、そちらをご参照ください↓ 朝っぱらから色々衝撃が走った第一四半期の最終日ですが、OracleとGoogleの裁判について、どのあたりが問題だったとされるのか気になるので判決文等を読んでみました。 経緯 2010年8月、OracleはGoogleを訴える。当初の争点は特許侵害 (publicKey1) 2012年4月、サンフランシスコ連邦地裁の法廷開始 2012年5月、Googleの特許侵害はないとの陪審評決。ただし、フェアユースは意見が別れる。 2012年6月: Oracle対GoogleのJava/Android訴訟、損害賠償金ゼロで合意。今回議論された37件のJ
Polymer 1.0の挙動変更の影響 - Qiita
Polymerの1.0がリリースされました。今回は、AndroidとAndroid Ware、IoTの比重が大きく、ブラウザ関連の発表が少ないGoogle I/Oでしたが、Polymer 1.0はその中の貴重な発表の1つでした。 Polymerとは何か？ Polymerはフレームワークではなく、さまざまな他のフレームワークの「下」で使える拡張可能なHTMLのレイヤーです。コンポーネントという言葉やコンポーネント的なものはMithril.jsやReact、Angular.jsさまざまなWebMVCで登場しますが、コンポーネント同士の互換性はありません。WebComponentsはコンテナ船のコンテナ的な、どこでも使えるコンポーネントを提供します(コンテナ船のメタファーはGoogle I/Oの説明から)。 1.0は0.5とくらべて、Chrome上で3倍、Safari上で4倍になっているとのこと
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
厨二病な名前のライブラリを集めるスレ - Qiita
ミスリル。クライアントサイドMVC。 http://mithril.js.org/ 参考: http://qiita.com/shibukawa/items/890d24874655439932ec エリクサー。Erlang VMで動く言語。 http://elixir-lang.org/ 参考: http://qiita.com/HirofumiTamori/items/0dfdbada30c7d8f183fd エスナ。PHPのサーバサイドMVCフレームワーク。 http://ethna.jp/doc/ ゴブリン。物理エンジン。 http://www.goblinphysics.com/ オーディン。ゲームエンジン。 https://odinge.codeplex.com/ タイタン。jQuery上のクライアントサイドMVC。 http://www.firerift.com/suppor
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
