Vue + TypeScriptにおける.vueファイルの型定義をexportしたい
shims-vue.d.ts
について
Vue + TypeScriptでプロジェクトを作ると以下のようなshims-vue.d.ts
をどこかに置くと思います.
declare module '*.vue' { import Vue from 'vue' export default Vue }
この型定義はすべての.vue
ファイルに対しての定義であり,個々の.vue
ファイルの細かい型(props
やdata
など)については定義していません.
個々の.vue
ファイルの型定義を同一ファイル内で利用する場合には問題ないですが,外部のファイルで利用する場合(ユニットテストなど)では不十分です.
解決策
.d.ts
を以下のような方針で定義するといいと思います.
Foo.d.ts
import Vue from 'vue' export interface Data { ... } export interface Methods { ... } export interface Computed { ... } export interface Props { ... } export type Component = Vue & Data & Methods & Computed & Props
Foo.vue
import Vue from 'vue' export default Vue.extend<Data, Methods, Computed, Props>({ ... })
Foo.test.ts
jest + vue-test-utils
import {shallowMount} from '@vue/test-utils' import Foo, {Component} from './Foo' test('', () => { const wrapper = shallowMount<Component>(Foo) ... })
mysqlが起動できない
ググって出てきた方法を何種類か試して,それでも起動できないときに見て.
$ mysql.server start Starting MySQL ... ERROR! The server quit without updating PID file (/usr/local/var/mysql/****.local.pid).
$ sudo /usr/local/bin/mysqld_safe mysqld_safe Logging to '/usr/local/var/mysql/****.local.err'. mysqld_safe Starting mysqld daemon with databases from /usr/local/var/mysql mysqld_safe mysqld from pid file /usr/local/var/mysql/****.local.pid ended
/usr/local/var/mysql/****.local.err
のエラーログを見てみると
[ERROR] Can't start server : Bind on unix socket: Address already in use [ERROR] Do you already have another mysqld server running on socket: /tmp/mysql.sock ? [ERROR] Aborting
既にポートが使われていると書いてあるのでlsof
コマンドでmysqlで使うポート(デフォルトで3306)を確かめる.
$ sudo lsof -i :3306 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME com.docke 2349 ****** 15u IPv6 0x5666ed45501eb94d 0t0 TCP *:mysql (LISTEN)
Dockerが3306ポートを使っていた...!
解決方法
Dockerを終了させる
macOSでclangを使おうとしたら標準のヘッダーファイルがないと言われた
問題
例えば,
#include <stdio.h> int main() { printf("HelloWorld\n"); return 0; }
のようなコードをclangでコンパイルをしようとしたら
HelloWorld.c:1:10: fatal error: 'stdio.h' file not found #include <stdio.h> ^~~~~~~~~ 1 error generated.
というようなエラーが出た.
原因
stdio.h
がないということなので,標準ライブラリのヘッダーが正しく設定されてないと考えられる.
そこでclangの-I
オプションで/usr/include
,または/usr/local/include
を指定しようとしたところ,そもそもヘッダーファイルが存在しないということがわかった.
解決策
以下のコマンドでXcode Command Line Toolsをインストールすればよい.
xcode-select --install
この方法を用いた場合,コンパイル時にclangの-I
オプションでパスを指定する必要はない.
参考
Pythonのデバッグにつかえるもの
pdb
gdbみたいなもの
import pdb; pdb.set_trace()
あとはドキュメントを適宜見る.
numpyのarrayの出力が全部みたいとき
numpyの出力が…で省略される場合があるので以下のようにするといい.
np.set_printoptions(threshold=np.nan)
他のオプションはドキュメントをみる.
VSCodeのスニペットに登録する
以下のように登録すると便利.
{ "debugger": { "prefix": "debugger", "body": [ "import pdb; pdb.set_trace()" ], "description": "debugger" }, "npprint": { "prefix": "npprint", "body": [ "np.set_printoptions(threshold=np.nan)" ], "description": "npprint" } }
JSON Schemaの仕様を読んだ
自分でまとめると理解が進むと誰かが言っていたので自分なりにまとめる. 読んだのはJSON Scheme Coreの部分.
Instance
JSON SchemaではデータモデルをInstanceと呼ばれるもので表す.Instanceには以下の6つの基本型を持つ.
- null
- boolean
- object
- array
- number
- string
基本的にはJSと同じ.データの型という理解で問題ない気がする.
root schemaとsubschemas
名前から想像できる通り,root schemaはトップレベルのschema,subschemasはroot schemaにネストされたschemaである.
JSON Schemaの拡張
新たにmeta-schemasを作って拡張したいときは"$schema"キーワードを使う.
“$schema"キーワード
“$schema"の値にはJSON schemaのどのバージョンを使うかを示す正規化したURIを記述する. ”$schema"はroot schemaに記述する.
“$ref"キーワード
“$ref"キーワードはschemaの参照に使われる. また,自身を参照することで再帰的な構造を記述することも可能.(ただし,無限ループを作ってはならない) オブジェクトのプロパティに”$ref"がある場合は"$ref"の参照であると解釈する. このときの"$ref"の値はURIである. 以下は理解できなかったのでそのまま持ってきた.
All other properties in a “$ref” object MUST be ignored.
“$id"キーワード
schemaのURIを定義するもの.
root schemaに"$id"プロパティを入れるのが行儀がいい.このときの値は一意に定まるようなもの( e.g. "http://example.com/root.json"
)にする.
subschemasには相対的に定まるもの(e.g. #foo
と指定した時はhttp://example.com/root.json#foo
と解決される.)を"$id"プロパティの値に入れる.
他の例はJSON Schema: A Media Type for Describing JSON Documentsを見て.
内部参照
“$id"キーワードと”$ref"キーワードを使うことで内部参照ができる.例は JSON Schema: A Media Type for Describing JSON Documents を見て.
JSON schemaで使えるキーワード
以下をみればよい.
Firebaseでハマったこと
注意
ベータ版の機能を使っている部分があるので機能が変わっていることもある.
CloudFunctionsとHostingを一緒に使うときのURLの管理
通常,CloudFunctionsのFunctionをデプロイした時にアクセスするURLはhttps://us-central1-<your-project-id>.cloudfunctions.net
.
HostingでデプロイしたコンテンツにアクセスするときのURLはhttps://<your-project-id>.firebaseapp.com
となっている.
例えば,hoge
というFunctionを定義した場合はhttps://us-central1-<your-project-id>.cloudfunctions.net/hoge
にアクセスすることで実行できるが,
https://<your-project-id>.firebaseapp.com/hoge
にアクセスして実行できる方が便利である.
そのためにはfirebase.json
を以下のように書けばよい.
// firebase.json { "hosting": { "public": "public", // ホストするディレクトリ "rewrites": [ { "source": "/hoge", // https://<your-project-id>.firebaseapp.com/hoge "function": "hoge" // https://us-central1-<your-project-id>.cloudfunctions.net/hoge } ] } }
詳しいことは Serve Dynamic Content with Cloud Functions | Firebase を参考.
CloudFunctionsでAPIキーを使いたいとき
APIキーなどの外部に漏らしてはいけない情報を扱うときにハードコーディングすることはなるべく避けたい(GitHubなどでソースコードをPublicに管理している場合は絶対にやってはいけない).
CloudFunctionsには環境変数を設定する機能が用意されており,CLIで
firebase functions:config:set someservice.key="THE API KEY" someservice.id="THE CLIENT ID"
というようにして設定できる.
この設定はFunction側からはfunctions.config().someservice.key
,functions.config().someservice.id
という形でアクセスできる.
また,現在の環境変数の取得はCLIでfirebase functions:config:get
と実行することでJSON形式で受け取れる.
詳しいことは Environment Configuration | Firebase を参考.