Vue + TypeScriptにおける.vueファイルの型定義をexportしたい

shims-vue.d.tsについて

Vue + TypeScriptでプロジェクトを作ると以下のようなshims-vue.d.tsをどこかに置くと思います.

declare module '*.vue' {
  import Vue from 'vue'
  export default Vue
}

github.com

この型定義はすべての.vueファイルに対しての定義であり,個々の.vueファイルの細かい型(propsdataなど)については定義していません. 個々の.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オプションでパスを指定する必要はない.

参考

stackoverflow.com

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には環境変数を設定する機能が用意されており,CLIfirebase functions:config:set someservice.key="THE API KEY" someservice.id="THE CLIENT ID" というようにして設定できる. この設定はFunction側からはfunctions.config().someservice.keyfunctions.config().someservice.idという形でアクセスできる. また,現在の環境変数の取得はCLIfirebase functions:config:getと実行することでJSON形式で受け取れる.

詳しいことは Environment Configuration  |  Firebase を参考.

ファイルの文字コードの確認と変換

いつもやり方を忘れて調べるのが面倒なのでメモ

nkfのインストー

Homebrewとかで

文字コードの確認

file -I ./*

or

nkf -g ./*

文字コードの変換

文字コードUTF-8,改行モードをLFに変換.

nkf --overwrite -wLu ./*