2018-10-31

Gridsomeを使ってみる【開発環境編】

技術記事

最近仕事でGraphQLを触る機会が多く、APIは全部GraphQLみたいにエンドポイント一つになってくれないかなーと思っていたら、こちらのようなパッケージが登場しました。現時点ではv0.2.5です。 https://gridsome.org/

Gridsomeとは

ざっくりと

GraphQLレイヤーを内包している(https://gridsome.org/docs/graphql)
外部API（WP REST APIとか）をGraphQLレイヤー向けに変換するのでAPIが使いやすい
vueファイル内で独自タグを採用している（<page-query>とか）ので、vueファイル内でGraphQLライクに情報を引っ張れる
JAMstackを目指していて、static site generatorになっている。（SSRにもできるらしいけど未確認）
graphiqlみたいな機能を搭載している
独自コンポーネントが存在する(https://gridsome.org/docs/link)
v1.0.0に向けて機能を足していっている途中。ロードマップ

開発するにはいろいろ足りない

vue-cliのエコシステムみたいなのがあればよかったんですが、それもないので自前で用意していきます。以下使用したパッケージと用途です。

パッケージ	用途
gridsome	Gridsomeの大元
gridsome/packages/source-wordpress	GridsomeでwordpressのAPIを使用するため
stylelint	stylelintを効かせる
stylelint-config-prettier	prettierとstylelintのバッティングルール回避
stylelint-config-recess-order	stylelintのルール拡張
stylelint-config-sass-guidelines	stylelintのルール拡張
eslint	eslintを効かせる
eslint-config-airbnb-base	eslintのルール拡張
eslint-plugin-vue	eslintのルール拡張
eslint-config-prettier	prettierとeslintのバッティングルール回避
eslint-plugin-prettier	eslint使用時にprettierも使用
commitizen	cz-cliでcommit commentを作る
fixpack	package.jsonのフォーマットをする
lint-staged	commit時にlintを適用させる
postcss-loader	postcssを使用するため
autoprefixer	ベンダープレフィックスを自動で効かせる
sass-loader	vueファイル内でsassを使用するため
node-sass	vueファイル内でsassを使用するため
sass-resources-loader	変数のimportとかの手間を省くため
npm-run-all	npm scriptの並列・直列処理のため
dotenv	環境によって値を変えたり、見せたくない値を設定するため

これらの中で使い方が迷いそうなもの設定例を見ていきます。
なお、著者のnode環境は以下のとおりです。

node: v10.11.0
npm: 6.4.1
yarn: 1.10.1
node管理ツール: ndenv

こちらのリポジトリで試行錯誤中です。
github.com

環境変数を異なる環境で使い分ける

Gridsomeでwordpressを使用するためにはgridsome.config.jsに以下のような記述をします。

{
      use: "@gridsome/source-wordpress",
      options: {
        baseUrl: "WEBSITE_URL",
        typeName: "WordPress",
        perPage: 100,
        concurrent: 10,
        routes: {
          post: "/:year/:month/:day/:slug",
          post_tag: "/tag/:slug"
        }
      }
    }

baseUrlにはwordpressのURLを記入します。
これが例えば開発環境ではhttp"//localhost:3000で、本番はhttp://www.example.comだったりすると、都度書き換えるのは面倒です。そのためdotenvを使用し、.envファイルを参照してGridsomeを起動させることにします。

// .env
VUE_APP_BASE_URL = http://exapmle.com

// gridsome.config.js
require("dotenv").config();
module.exports = {
  plugins: [
    {
      use: "@gridsome/source-wordpress",
      options: {
        baseUrl: process.env.VUE_APP_BASE_URL,
        typeName: "WordPress",
        perPage: 100,
        concurrent: 10,
        routes: {
          post: "/:year/:month/:day/:slug",
          post_tag: "/tag/:slug"
        }
      }
    }
  ]
};

これでbaseUrl: process.env.VUE_APP_BASE_URLは
baseUrl: 'http://exapmle.com',と同じになりました。

dotenvを使用する際には.envは.gitignoreでgit管理対象外にしましょう。

これでnpm scriptsにこのように書けば環境変数を使い分けることが可能になります。

"scripts": {
  "gs:build": "gridsome build",
  "build": "run-s env-production gs:build",
  "gs:develop": "gridsome develop",
  "develop:dev": "run-s env-develop gs:develop",
  "develop:prod": "run-s env-production gs:develop",
  "env-develop": "cp config/env/.env.develop ./.env",
  "env-production": "cp config/env/.env.production ./.env",
}

config/envに.env.developと.env.productionを作ったので、それらを適宜.envにコピーして使い分けます。

clientサイドでもprocess.envを使用したい

vue-cliにはこのような機能があるのですが、webpack.DefinePluginの機能で実現しているようです。
Gridsomeには標準ではこのような機能は搭載されていないので自力で搭載する必要があります。

config/env.jsというものを作成してみます。

let originEnv = require("dotenv").config();
originEnv = originEnv.parsed;

function middleware(value) {
  if (value === "true") return true;
  if (value === "false") return false;
  if (value === "0" || value === 0) return 0;
  return value || null;
}

exports.getEnvs = () => {
  let env = {};
  for (let key in originEnv) {
    if (originEnv[key]) {
      env["process.env." + key] = JSON.stringify(middleware(originEnv[key]));
    }
  }
  return env;
};

dotenvはプロジェクト直下にある.envを見ます。
その中身を取り出してオブジェクトに変換し、それぞれのキーのprefixをprocess.envにしました。

// .env
HOGE = hogehoge
FUGA = fugafuga

// env.jsを介すと
{
  process.env.HOGE: 'hogehoge',
  process.env.FUGA: 'fugafuga',
}

console.log(process.env.HOGE)
// => 'hogehoge'

.envからオブジェクトが作成できるようになったので、これをDefinePluginに設定します。

gridsome.config.jsはwebpack-chainを使えるので、このように書きます。

const path = require("path");
const { DefinePlugin } = require("webpack");
const env = require(path.join(__dirname, "/config/env.js"));

module.exports = {
  chainWebpack: config => {
    config.plugin("env").use(DefinePlugin, [env.getEnvs()]);
  }
};

これでvueファイル内であってもprocess.env.XXXXが使えるようになりました。

vueファイル内でscssが使いたい

これは

yarn add node-sass sass-loader -D

するだけで使えるようになります。

autoprefixerが使いたい

必要なパッケージをインストールし、プロジェクト直下にファイルを設置します。

yarn add postcss-loader autoprefixer -D

// .postcssrc

module.exports = {
  plugins: {
    autoprefixer: {}
  }
};

こちらもプロジェクト直下に設置しましょう。

.browserslistrc

> 1%
last 2 versions
not ie <= 8

以上です。

sassの変数をいろいろなところで使用したい

yarn add sass-resources-loader -D

const path = require("path");

module.exports = {
  chainWebpack: config => {
    const oneOfsMap = config.module.rule("scss").oneOfs.store;
    oneOfsMap.forEach(item => {
      item
        .use("sass-resources-loader")
        .loader("sass-resources-loader")
        .options({
          resources: [
            path.resolve(`${__dirname}/src/styles/`, "variables/importer.scss")
          ]
        })
        .end();
    });
  }
};

以上です。

Nuxtみたいにページ間遷移にtransition効かせたい

現状機能が搭載されていません。 v1.0で搭載される予定のようです。

We will support page transition in 1.0. Currently the whole page is unmounted when you change page
— Gridsome (@gridsome) October 28, 2018

とりあえずの対処法として

// layouts/Default.vue
<transition-group name="page" tag="main" appear>
    <div key="main">
        <slot></slot>
    </div>
</transition-group>



.page-enter-active,
.page-leave-active {
  transition: 0.4s;
}

.page-enter,
.page-leave-to {
  opacity: 0;
  transform: translateX(20px);
}

とすればいけますが。（1.0が待ち遠しい！！！）

感想

著者はnuxtはあまり触ったことはなく、職場でvue-cli@3を使用したプロダクトの開発をしているので、いろいろ設定がしんどかったです。
特にdotenvは手こずりました。
本記事がGridsomeを試す際の何らかの手助けになれば幸いです。

次回予告

Gridsomeを使ってみる【apiにクエリ発行編】として、実際にwordpressの記事を取得して表示させるまでを紹介したいと思います。

2018-09-13

Gitに心躍ったあの日、そして今

殴り書き思考メモ

TL;DL

angular の format と atom の emoji の組み合わせ最高
git config で commit 時に参照するファイルの設定が可能
でも Git の Commit Message はcommitizenを使いまわそう
commitlint で意図にそぐわない message フォーマットは排除しよう
抜け道は CI で防ごう
GUI ツールは知らん

commit message のフォーマットを意識しだした日

prefix

唐突に訪れたあの日。それは前職場にフロントエンドエンジニアの人が来たことだった。
その人は commit message に独特の書き方を使っていた。

docs(README.md): :memo: コマンドの説明追加

なんだこの記法・・・オラオラルールか？

ここで、気になる node package を彼が追加していた。generate-changelogというものであった。
CHANGELOG って web サービス作るときによく見るあれかという認識だった。
web サイト作るときにこんなの使わんよなぁと思いながら、好奇心が勝って一人で導入してみて捨てリポジトリで使ってみた。

breaking
build
ci
chore
docs
feat
fix
other
perf
refactor
revert
style
test

をプレフィックスに使うと、そのルールに従ってよしなに CHANGELOG を生成してくれるというものだった。なるほど、彼はこれを使いたいからこれ使ってただけかぁと一人で納得した。

じゃああの絵文字は？ってなった。

emoji

結構有名な記事だがこれを見つけて読んだ。
Emoji で楽しく綺麗なコミットを手に入れる | Goodpatch Blog
なにやらatom でも使われているらしい。
確かに見やすい。
🔥 とか絶対何か燃やした（消した）やん。これは僕も使いたいと思った。

作った format

なんやかんやあって、

git config --local commit.template ./path/to/hogehoge.txt

を使用することで、git messageで vim モードに移行する際、このファイルを参照しながら commit が書けるということで、以下のフォーマットを用意した。


# ==== Format ====
# prefix(scope): :emoji: Commit body...
#
# backlog task key

# ==== prefix ====
# fix: バグやタイポなどの修正
# feat: 新しい機能の追加
# refactor: リファクタリング
# style: スタイリングに関わる変更(css/sass)
# chore: 細務(ファイル整備、移動、削除、名前変更など)
# test: テストファイルに対する変更や修正
# docs: ドキュメントの加筆や修正
# breaking: 破壊的変更
# build: ビルド周りの設定(主にgulpやwebpack周り)
# ci: CIに関わる設定
# pref: パフォーマンスの改善
# revert: 削除や変更の取り消し
# other: その他

# ==== scope ====
# eslint | eslint の設定を変更
# stylelint | stylelint の設定を変更
# config | config.json を変更
# readme | README.md を変更
# gulp | gulp の設定を変更
# webpack | webpack の設定を変更
# html | htmlファイル変更
# php | phpファイル変更
# js | jsファイル変更

# ==== Emojis ====
# 🐛  :bug: バグの修正
# 🎉  :tada: 新機能の実装
# 👍  :+1: 機能改善
# 💊  :pill: 機能修正
# 💉  :syringe: linterの設定やエラー修正
# 🔥  :fire: 不要ファイルの削除
# 🚚  :truck: ファイル移動
# 📛  :name: ファイル名変更
# 📝  :memo: markdownファイルの変更
# 📑  :bookmark: タグ切り(リリース)
# 👮  :cop: 認証周り
# ✅  :white_check_mark: テストの作成
# 💚  :green_heart: テストの修正
# 🆙  :up: モジュールのバージョンアップ
# 👻  :ghost: 作業途中

# ==== 7つのルール ====
# 1. タイトルの後は1行空けて本文を書く
# 2. タイトルを50字以内におさめる
# 3. タイトルの文頭を大文字にする
# 4. タイトルの文末にピリオドを付けない
# 5. タイトルは命令形で記述する
# 6. 本文は1行あたり72字以内におさめる
# 7. 本文ではどのようにではなく何をとなぜを説明する
#
# 詳細は https://postd.cc/how-to-write-a-git-commit-message/

最初に二行改行しているのは、参照するときに見やすくするため。これを

git config --local commit.template ./gitmessage.txt

ってやって設定していた。
その他細かいことはREADME.mdに書いていた。（scope 増えたら txt ファイルに追記してねとか）
うーん、楽！！！便利！！！

この時アプリエンジニアの人に「選択式でできたら便利そう」って言われて、確かに・・・って思っていた。

commitizen との出会い

なんやかんやあって転職して、初めて出会ったのが、 commitizen。
これは対話型のコマンドに答えるだけで commit message が作れるというものだった。

おいおいおい。最高かよ。

ってなった。

しかも、commitizen を眺めている途中で、AngularJS Git Commit Message Conventionsというものを見つけ、あーあれ（generate-changelog）で使ってた prefix はこれに準拠していたのかーと知る。
これ使えばいいじゃんとテンションは上がった。しかし疑問が。

git は node 使わなくても commit できる・・・でも統一したいな？

GIT フックと NPM lifecycle

そこで、Git フックとcurrent lifecycle eventを調べた。

なるほど、フックさせればいいのか。
Git フックでコミットメッセージを監視して、違うとエラーにして突き返す方法もある。
が、僕は node でさくっと監視させる環境にしたい。

node を駆使して監視体制を作る

commit message 絶対統一させるマン - Speaker Deck

これで紹介しているが、リポジトリを作った。

husky で Git hook を簡略化した。

また、commitizen のフォーマットを日本語に変更するパッケージを改造して、emoji を追加できるようにした。

抜け道防ぐ

circleCI を設定し、CI 上で commitlint が走るので、

git commit --no-verify
node 入れずに git コマンド使う人

は、フォーマットが違うとエラーになる。
自力で頑張ってね、楽したかったら node でやってねシステムになっている。

commitizen への不満

今回自分でフォーマットを改造したのだが、これは、commitizen のフォーマットを日本語にしてくれる cz-conventional-changelog-jaを改造して自分で対話の項目（emoji）を増やしている。

もっと簡単にフォーマット拡張できるようにしたいなぁ

と思った。

調べてみるとこんなのがあった。 cz-customizable。使ってみたが、僕の想像と違ったし、インターフェースなんか難しかったしイケてなかった。

パッケージを自作

仕方がないなぁと思い、自分でパッケージ作ることにした。
cz-format-extension

まだ WIP だけど、使うことは可能（拡張不可能）。
これから rc ファイル作って、そこに json 形式で情報書いたら拡張できるようにしていくつもり。

ところで GUI で Git ポチポチしてる人は？

sourcetree とかのやつですかね？
git hook に引っ掛けることはできるかもしれないですが、めんどくさいので他の記事を参考に自分でやってみてください。

2018-08-01

20 人規模から 300 人規模の会社に転職して 1 ヶ月が経ちました

日常

最初の一ヶ月が経ったので振り返りと思ったことを書く

TL;DL

一ヶ月で何ができるようになったのか
- 雰囲気で vue を書いてるお
受託制作と自社開発は違う
- 自社開発は PDCA のスピードが違う
日曜日に落ち込まなくなった
- 月曜日嫌だ。会社嫌だとはなってない。
エンジニアの数が多い
- 色んな話を聞ける（タメになる）
- 相談もできる（タメになる）
社員多すぎて誰が誰だかわからない
髪の毛染めてサンダル出社してコアラのマーチ食べても無問題
評価がちゃんとしてる
- お金のことを考えながら仕事は辛いので助かる
トイレの消灯マジ勘弁

振り返り

この一ヶ月で何ができるようになったのか

バシバシ issue を投げてもらえる
先輩に教えてもらう
家でも vue の本や記事を見て手を動かしている

ので少しは分かるようになってきた。雰囲気で vue を書いているし触っている。
もっと早くコードの意図を読み取れるようになりたい。
新しい環境と新しい職種に追いつくので必死な一ヶ月だった。
まだまだこれから。

受託制作から自社開発に変わった

前職では約二年間 Web デザイナー（コーディング寄り）受託制作をしていたが、転職してからはフロントエンドエンジニアとして自社開発に変わった。 html,css,jQuery での Web 制作から Vue での自社開発に変わったということだ。
正直転職前までは自社開発はなんだかつまらなさそうと思っていた。
大変視野が狭い考えだったが、
「自社開発って同じプロダクトをずっといじくりまわすから知見溜まらなそうだし飽きそう」
と思っていた。

アホである。

実際は、

パフォーマンスを高めたいので高度な実装をすることになる => 勉強しないといけない
新たな施策を打つために既存のコードに追加の機能を実装する => 追加機能の詳細を把握しないといけない、既存のコードを読み解かないといけない
言語に新しい便利な機能が追加されたのでリファクタリングしてコードを簡潔にしたい => 勉強しないといけない
コンバージョンが良くないので改善しないといけない => アナリティクスを見て分析しないといけない
新しい言語のパフォーマンスが良いらしいので取り入れたい => 勉強しないといけない
etc...

勉強ばっかりだ。勉強好きな僕としては天国である。

だがここまでを見ると、受託で運用しているところと何が変わるのかと思う。
両者の違いはPDCA のスピードだろうか。

提案してそれをクライアントが納得してお金を出す約束をしてもらって開発するというのが受託であるならば、実装方法、構造や特徴を知り尽くした人たちでとにかくコンバージョンにつながるように短い期間でひたすら実装検証を繰り返すのが自社開発だと思っている。効果を見て、なければ戻して他のところを改修するし、あればどこに効果があったのか検証してさらに攻めるか他の部分を改修するかする。
実装しようか悩むならやってみて、様子見て考えようぜ精神が強いと思う。

今の所自社開発では面白さしか見出だせていない。
リファクタリングで容赦なくバキバキへし折っていくのとか面白い。

思ったこと

日曜日に落ち込まなくなった

「あぁ日曜日が終わる…会社か…」ってならなくなった。「あぁ日曜か。勉強はここまでにして寝るか。」ぐらい。

人が多いのでいろんな話が聞ける

今のところひよっこなので話についていけていないので、話の中で出てくる単語をググってる。
特に弊社では根拠を提示して「ここがこうだからこれが良い」ってのをよく聞く。
逆に「ここがこうだからこれはクソ」というのも聞く。
自分なりに考えてコードを書くが、プルリクで指摘が入ると「へぇ…ほぉ…」となる。
もっと強くて説得力がある根拠を持ってコードを書くのはできていないのでこれからである。

人が多いので色んな話ができる

同居人がフロントエンドエンジニアなので、ふたりともよくわかっていないことが出てきたりする。
そういうときに聞ける人がいるというのは強いと思った。
この前は async,await について自分がどこで間違えているのか指摘してもらえた。

社員多すぎて誰が何してるかよくわかってない

20 から 300 はいきなりびっくり人多すぎて、slack 来ても「なんの人なんやこの人…」ってなる。少しずつ慣れるけど、slack に 300 人いるの始めてだからびびった。

意外と許された

髪の毛をメッシュにした。なんなら緑色を入れている。
そこそこ大きい企業なのでなんかいわれるんじゃないかと思ったが、むしろ銀髪や紫にしていた時代を知っている人からは「まだチャンカツはそんなもんじゃない」と言われる。意外と冒険して良い企業で安心した。
前職の人には「大きい企業だからなんたらかんたら」と言われていたみたいだがそんなのなかった。
安心して髪の毛メッシュでサンダル出社してコアラのマーチを貪っている。

評価がちゃんとしてる

詳細は書けないが、評価制度はちゃんとしていて「おぉ」と思った。
スタートアップだった前職ではなぜか「今期は頑張る時期だから評価はせんぞ。耐えろ。」と言われてせっかく書いた評価シートをシカトされた。
自分の成果をお金という対価で受け取ることに謙遜なんかしたくないし、なんならお金のことを考えずに働きたいので、自分の向上心や成果を考慮して評価を決めてくれるところはすごいと思った。

トイレの照明が自動で消える

個室に入るときはめっちゃ動いて消灯回避

2018-07-30

転職したので自己紹介

日常

意味がわからないタイトルだがそのとおり。
転職を期にブログを始めてみる。

プロフィール
経歴
転職活動どうだった？
なんで転職を？
転職してどうなった？
転職してよかった？
今後どうなりたい？
最後に

プロフィール

チャンカツ@tyankatsu5（tyankatsu が取れんかったんや。twitter が提案してくれた 5 をそのまま使った。後悔はしている。）
福岡生まれ福岡育ち
ほうれん草大好き
趣味はギター（最近弾いてない）、コーディング、ネットの技術系記事読むこと
突然髪の毛紫とか銀にしだすぐらい思い切ったことをする

経歴

大学在学中マークアップに興味を持つ
- このとき精神疾患で暇な時間があったので没頭した
就職活動中に運命の出会いをする
- 元々やりたいと思っていたメンタルヘルスケアサービスをやっている会社を見つける（当時設立 1 年未満だった気がする）
- サービスの担当者にいきなりコンタクトとって skype する
- 「新卒は取ってないけどフロントエンドエンジニアが足りてないからなったら？」と言われ真に受ける
共通の知人を介して、前職（Web 受託のベンチャー）の広報兼人事の方と出会う
- コーディング、デザイン両方勉強したいということでデザイナーとして 1 ヶ月インターンシップ
インターンシップからバイトに昇格（？）する
- ~~たぶん腕を見込まれた~~
- 社内実技テストで当時の社員三人の内二人を抜かす（その人達すぐどっかいった・・・）
そのまま入社する
- 約 1 年激務をこなす
- 終電ギリギリまで仕事をやって、土日たまに来る仕事やって、空いた時間で勉強してみたいな毎日
「僕がやりたいのこれじゃねぇ」と目が覚めて転職活動する
- マークアップエンジニア寄りの Web デザイナーだけど・・・フロントエンドエンジニアになりたかったのでは？
- 社内に人いなさすぎて技術的な話つまらないな？
- 外部のコミュニティに入れてもらったら、なにやらすごい人達いっぱいいるな？
声をかけていただいた現在の会社（自社開発）にフロントエンドエンジニアとして入社
- Vue 絶賛触り放題
- エンジニアたくさん、皆技術に貪欲
- 社内環境最高

転職活動どうだった？

すぐ終わった。一社しか行ってないし、そこに行きたいと思っていた。

なんで転職を？

技術力を磨くのにこの環境じゃ道草だと思ったから。
元々会社を辞めようとしていた。
「もうここでやれるだけのことはすべてやってしまったので、次のステージに進まないといけない」という気持ちに駆られた。
インターン時代は技術なんて全然わからなかったが、sass、gulp、git などを触っていくうちに、
少しずつ「こうしたらいいんじゃないか？この技術取り入れたらパフォーマンス上がるんじゃないか？」という疑問のもと行動するようになった。

gulp@4
gulp の構成見直し
webpack@4
postCSS
prettier
linter(eslint,stylelint)
docker
構造化マークアップ
README テンプレート
git commit rule
コーディング規約
デザイン規約
社内で技術記事をめっちゃ書く

などなどやって社内の環境を整えたり知見を貯めてた。
でも受託なので運用の面を考えると、まだ多く扱える jQuery を使って生の HTML を書いているような状態だった。
技術的に今ひとつ踏み込めないので、つまらないと感じて独学で Vue を触り始めた。
進めていくと「あぁこういうのやっぱりやりたかったんだな」と思えてしまった。
と同時に、「今やってることって、フロントエンドエンジニアになるには道草なんじゃないか」と思うようになってしまった。
そして転職を考え出した。

転職してどうなった？

毎日楽しい
基本残業禁止という一日 8 時間の限られた中で、いかに自分のパフォーマンスを高めて仕事をするのかを考えながら仕事をするので、飽きない。
今日は眠いから午後から頭使わない系の作業をしようとかができる。
そんなことが許される割と自由な環境なのは魅力的。
エンジニアもたくさんいておもしろい。（まだひよっこで話についていけないのが辛いので勉強中。）
そして今 Vue で自社製品を開発しているので、いろんなソースコードを見て読み解きながら手を加えていくというのが楽しい。
19 時には家に帰れるという嬉しい環境なので、帰ったら仕事で得た事をもとに自分で Vue の環境周りをいじってみたり、アプリを作ってみたりと勉強している。

転職してよかった？

もちろん良かった。
周りの人間関係に恵まれていたし、決断してよかった。

今後どうなりたい？

福岡のフロントエンドエンジニア勢の中で名を挙げられるようになりたい。
3 年ぐらいで。
そしていつかメンタルヘルスケアのサービスにフロントエンドエンジニアとして開発に携わりたい。
そのために日々精進するつもり。

最後に

いろいろあったけど前職の人たちには感謝してる。
未経験でいろいろ経験させてもらった。
そしてその職場で外部の方だがメンターとして自分を育ててくれた師匠（今もお付き合いがある）には感謝しきれない。
僕にいろいろな世界を見せてくれたし、社外のイベントに誘ってもらったのも師匠のおかげ。
早くもっと成長して、師匠に恩返ししようと思ってる。