先日のISUCONでは、Google Cloud Platform（以後GCP）のGoogle Compute Engine（以後GCE）が使われたわけですが、これが本当に便利だなーとおもったわけです。 cloud.google.com 初期登録のクレジットもあまっていますし*1、しばらくこれを仕事でも使うかな〜〜って思って使っていたら、これは大層便利だとおもったのでそのまとめです。私に対するカンペでもある。 しかし、GCPとかGCEとか全然名前がおぼえられない。Google…Compute…Cloud…、ちがう、それだとGCCだ…。 Google Compute Engine（GCE） はいわゆるEC2 GCEはいわゆるAWSのEC2です、EC2がわからない人は多分ここに来ないだろうから省略。違いは沢山ありますが、今回はgcloudコマンドの存在について書きたい。*2 AWS同様に、GC

なお, ファイルを残したまま追跡から逃れたいときは git rm --cached path/to/file でインデックスのみ削除し, .gitignore などで指定する. また, 誤って git rm してしまったときは git reset @~ path/to/file, git checkout path/to/file で回復する. ローカルでのみ追跡してほしくない場合 二つ方法がある. これらの違いは既に git 管理しているファイルをあえて無視したい - Qiitaに詳しい. 用途に依るが, assume-unchanged の変更は git reset --hard で死ぬので, 基本的には skip-worktree を使う. assume-unchanged 除外するとき

JavaScript のオブジェクトまず JavaScript のオブジェクトについです こんな感じですよね 配列は数字がキーになってるオブジェクトで 数字はプリミティブ値です また __proto__ を使ったプロトタイプチェーンがあります オブジェクト自身がそのキーを持っていない場合は __proto__ の先にあるオブジェクトを探します そこでもなければ またその先の __proto__ からとずっと繰り返しです オブジェクトをクローンする場合では __proto__ はたどる必要ないと思います クラスのような使い方するためのものでオブジェクト自身の値とはまた別物で 共通の値を入れるものでここをクローンするのはおかしな気がします 必要なら __proto__ の先を変更するだけでいいと思います ライトなコピー配列で slice を使うと参照は参照のままコピーします var frien

コマンドプロンプト起動時、自動的に文字コードをUTF-8にして日本語もちゃんと表示できるようにする方法コマンドプロンプトwindows7 Windows7 でのみ動作確認済。XPとかだとうまくいかないかもっぽぃらしい。 前提知識 コマンドプロンプトのデフォルト文字コードは Shift_JIS chcp コマンドで文字コードを変更できる ただし、文字コードを変更しただけでは日本語を表示できない 文字コードを変更しても、コマンドプロンプトを再起動するとデフォルトに戻ってしまう そのため、以下2ステップを行う必要がある 文字コードが UTF-8 のときに使用するフォントを、日本語対応のものにする コマンドプロンプト起動時、自動的に文字コードが UTF-8 になるよう設定する 実際の手順 Step:1 使用フォントを日本語対応のもの(MSゴシック)にする (*1) コマンドプロンプトを実行する プ

The Intuitive Vue Framework Nuxt を使って信頼ある次世代の Vue.js アプリケーションを構築する Web 開発をシンプルにかつパワフルにするオープンソースフレームワーク

JavaScript のオブジェクトはプロパティ（自身のプロパティを指す）の動的な「袋」です。 JavaScript のオブジェクトは、プロトタイプオブジェクトへのリンクを持っています。あるオブジェクトのプロパティにアクセスしようとすると、オブジェクトだけでなく、オブジェクトのプロトタイプ、プロトタイプのプロトタイプへと、一致する名前のプロパティが得られるか、プロトタイプチェーンの終端に到達するまで、プロパティの探索が行われます。 メモ: ECMAScript 標準に従い、 someObject.[[Prototype]] という表記を someObject のプロトタイプを示すのに使用しています。内部スロット [[Prototype]] には Object.getPrototypeOf() と Object.setPrototypeOf() 関数でアクセスすることができます。これは、標準

JavaScriptの「プロトタイプ入門」 JavaScriptはオブジェクト指向です。 クラスという概念はないため、 擬似的なクラスの表現を使ったパターンがあります。 ただ今回はそちらではなくプロトタイプベースの説明をします。 その前にコンストラクタについて知らない人はこちらへ。 JavaScriptのクラス？コンストラクタ？ プロトタイプって？ そもそもプロトタイプってなに？ 実は、、プロトタイプとは「オブジェクト」のことなんです。 そして感覚としては親だと思って大丈夫です。 親の能力は子にも受け継がれている。。的なニュアンスですね。 （まぁ意味合いはちがいますがw） prototypeプロパティ ここで新規に関数を生成してみましょう。 そうするとprototypeプロパティが自動で作成されます。 このように関数を生成した時点で、 proto.prototypeプロパティが自動で生成さ

Goでリバースプロキシを作ったものの、そもそもリバースプロキシが何なのか、何で必要なのか分からなかったのでまとめてみた。 主に [24時間365日] サーバ/インフラを支える技術 ‾スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) を勉強して、理解に必要そうなところだけ抽出した。 冗長化の必要性 冗長化とは、障害が発生しても予備の機材でシステムの機能を継続できるようにすること。 Webサービスでいえば、webサーバが１つ死んだり障害が発生したりしても、サービスには支障を出さずに運用を続行出来るようにすること。 システムを冗長化するとは、 障害を想定する 障害に備えて予備の機材を準備する 障害発生時に予備の機材に切り換えられる運用体勢を敷く ことをいう。 予備機材を導入して障害に備える 先の冗長化の方法にあるように、予備機材を導入する。 これでw

[12:34:23] Failed to load external module @babel/register [12:34:23] Requiring external module babel-register [12:34:28] Using gulpfile ~\dir1\dir2\sample\gulpfile.babel.js [12:34:28] Starting 'sass'... [12:34:28] Plumber found unhandled error: Error in plugin "gulp-sass" Message: src\sass\style.scss Error: File to import not found or unreadable: modules/**/*. on line 3 of src/scss/style.scss >> @

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community. Pick a username Email Address Password Sign up for GitHub By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails. Already on GitHub? Sign in to your account

理解しやすいよう、ステップに分けて解説。 babel を使い、ES2015 (ES6) で書く。 前準備 "project/" ディレクトリをルートとし、その中で作業する。 以下、最終的なファイル構成。 project/ ├ package.json ├ package.lock.json ├ gulpfile.babel.js ├ .babelrc ├ node_modules/ │ └ インストールした npm パッケージ群 ├ (style.css) // gulp の CSS タスクで style.scss から生成 └ src/ └ style.scss package.json の作成 (-y は全てyes設定) npm init -y ES6 → ES5 のトランスパイルに必要なパッケージをインストール npm install -D babel-core babel-pres

Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある

なんか色々おぼえ書き。だいたいweb制作関連。