ScoopでWindowsにおける開発環境構築を最適化しよう | さにあらず
はじめに#Windows には他の OS には無い致命的な問題が一つあった。そう、OS 標準のパッケージマネージャが無いことだ。 Windows10 ではPackageManagementという大変素晴らしい OS 標準のパッケージマネージャが搭載された。 これでコマンドラインだけで開発環境をガンガン作れるに違いない。そう考える人がいてもおかしくはない。正直、僕だってそう思いたい。 PackageManagement の問題点#僕は PackageManagement のアーキテクチャが難しすぎる事は大きな問題だと考えている。このエントリを是非読んで欲しい。 Introducing PackageManagement in Windows 10もうね、何でこんなに大変なことになってるのかと。 いや、歴史的経緯を鑑みつつ、OS に標準搭載されるパッケージマネージャが持つべき仕組みをキチンと備
Modern JavaScript概観、そしてElectronへ | さにあらず
この一か月分の学習成果を整理したリポジトリを作ったので、その成果についてまとめておく。 作ったサンプルプロジェクトだけを手軽に欲しければ、このリポジトリを clone してほしい。 taichi/js-boilerplatemaster ブランチには、ミニマムな JavaScript 開発環境がサンプルコード付きで入っているfrontend ブランチには、React/Redux/webpackなウェブアプリケーション用の開発環境が入っているデフォルトブランチにしてある electron ブランチには、frontend ブランチの内容に加えてElectronでアプリケーションを開発するための環境が入っているはじめに#最近の JavaScript について#僕は仕事として JavaScript を書いている訳ではないけども、この半年くらいの間にちょっとしたツールならいくつか作った。どちらも便利
go言語の名前空間について | さにあらず
package 宣言における名前付けのアプローチが、go と Java では考え方が随分違っていて面食らったので忘れないうちに書いておきます。 go 言語のテンプレート API#go 言語にはテンプレーティングする API が標準で二種類あります。 text/templatehtml/templateTemplate という struct がそこらじゅうで出てくるのですけども、何か混ざったような印象を受けるのです。 html/templateの API はtext/templateを利用して実装しているので、ある種の重複は当然あってしかるべきなのですけども、何か違和感がありました。 コードを引っ張りだしてみます。 text/template/template.go package template import ( "fmt" "reflect" "text/template/parse"
アセット的なアレを実行バイナリ内に入れる話。 | さにあらず
結論#go 言語でウェブアプリケーション書くなら、go-bindata使うべし。 はじめに#go で書いたサーバは一つのバイナリに全部入るからデプロイが楽だという話がありますけども、それは全部のコードを go で書いた時だけです。 ウェブアプリケーションでは、ユーザインターフェース用のテンプレートファイルなど、どうしても go のコードではないリソースが発生します。 例えばテンプレートをパーズする標準 API を見ると、こんな風になっています。 html/template#ParseFiles func ParseFiles(filenames ...string) (*Template, error) { return parseFiles(nil, filenames...)}コピー この API 構造はソースコードを配置しているディレクトリ構造が単純だと特に問題ないのですが、少し複雑
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
