Lycolog

確認環境

やり方

ppa:git-core/ppaリポジトリを追加するといける

sudo add-apt-repository ppa:git-core/ppa
sudo apt update -y
sudo apt upgrade -y
sudo apt install git

参考

• “Ubuntu Git Maintainers” team (launchpad.net)

• 特定ブランチ以外を全部消す
• マージコミットをリバートする
• コミット間のハッシュを見る

特定ブランチ以外を全部消す

Git 2.25.1で確認

# マージされてないのは残す
git branch -d $(git branch | grep -vP <PCRE pattern>)
# 強制削除
git branch -D $(git branch | grep -vP <PCRE pattern>)

参考：git-branch - List, create, or delete branches (git-scm.com)

マージコミットをリバートする

Git 2.25.1で確認。基本-m 1で問題ないと思われる

git revert -m 1 <commit>

参考：git-revert - Revert some existing commits (git-scm.com)

コミット間のハッシュを見る

Git 2.25.1で確認

# 新しい順
git log --pretty=format:'%H' <commit>..<commit>
# 古い順
git log --pretty=format:'%H' <commit>..<commit> --reverse

参考：git-log - Show commit logs (git-scm.com)

TypeScriptで関数を書いているときに戻り値の型を書くケースがあるが、個人的にはあれは基本書かないほうがいいと思っているので、その理由を書いていく。

コード記述が冗長になる

まず型を書くと記述が冗長になる。以下のコードを見ると戻り値型が長く読みづらく、書くのも面倒だ。まずこんな長い命名をやめたほうが…というのはあれど、現実問題として長い命名は存在するので仕方ない。

export const getCampanyAndDepartmentAndEmployeeFromPrefectureCode = (
  param: VeryveryLoooongestParamTypeNaming,
): VeryveryLoooongestReturnTypeNaming => {
  return param.db.con.execQuery(
    "SELECT * FROM foo WHERE id = :?",
    param.dbParam.foo.id,
  );
};

しかし以下であれば戻り値型がない分すっきりしていて見やすいし、書く手間も掛からない。更に型推論によって正しい型が返るので理想的だ。

export const getCampanyAndDepartmentAndEmployeeFromPrefectureCode = (
  param: VeryveryLoooongestParamTypeNaming,
) => {
  return param.db.con.execQuery(
    "SELECT * FROM foo WHERE id = :?",
    param.dbParam.foo.id,
  );
};

実装と異なる戻り値型を暗黙的に記述できる

例えば以下のように書けば戻り値の型は'foo' | 'not foo'となり、常に正しい型が返る。

export const foo = (isFoo: boolean) => {
  return isFoo ? 'foo' : 'not foo';
};

しかし以下のように戻り値の型を定義すると実装上存在しない'bar'が返る。これは実装時に無用な混乱を生む。一般的にこのようなケースは仕様削除やリファクタなどで生まれることがあると思うが、そういうメンテ漏れにもなるので書かないほうが安全だといえる。

export const foo2 = (isFoo: boolean): 'foo' | 'not foo' | 'bar' => {
  return isFoo ? 'foo' : 'not foo';
};

他にも次のケースでは戻り値がstringとなり、何が返ってくるのかが実装を見ないと解らなくなる。特に理由がないなら書かないほうがよい。

// 'foo' | 'not foo'になるはずだがstring扱いになる
export const foo3 = (isFoo: boolean): string => {
  return isFoo ? 'foo' : 'not foo';
};

型記述が混乱する

ここは基本的に前項の内容と重複する内容となる。

例えば次の二つの実装は同じだが、戻り値の型だけが異なる。こういう実装が混在すると実装の一貫性が失われ無用な混乱を生むので、指定しないほうが望ましい。

const IndexPage = (): JSX.Element => {
  return (
    <Layout title={'Hello Next.js'}>
      <>
        <h1>Hello Next.js 👋</h1>
      </>
    </Layout>
  );
};

const IndexPage2 = (): ReactElement => {
  return (
    <Layout title={'Hello Next.js'}>
      <>
        <h1>Hello Next.js 👋</h1>
      </>
    </Layout>
  );
};

書いてもよいと思うケース

例えば依存関係を持たせたい時など、インターフェースとして型を共通化したい場合は書いてもよいと思う。これはどこでそれを使うのかが自明になるからだ。改修時にも型によって関連処理が見出しやすくなるので意識しやすくなる。

export const createPostMessage = (
  channel: string,
  username: string,
  message: string,
): PostMessage => {
  return {
    channel,
    username,
    message,
  };
};

export const postMessage = async (param: PostMessage) => {
  try {
    return await fetch('https://example.com/api/postMessage', param);
  } catch (err) {
    return err;
  }
};

但しこのようなケースではUnit Testを書いて、実装された戻り値型を満たす値が返ることを確認するのが望ましい。

戻り値型を書かないことによるデメリット

TypeScriptの公式リポジトリによると、型推論の速度に悪影響を及ぼすとあるので、型推論の速度が落ちるという点だ。

もし型推論の速度が非常に遅いと感じた場合は書いてみてもよいと思うが、公式でも以下のように案内があり、和訳すると「型推論は非常に便利なので、これを普遍的に行う必要はありませんが、コードの遅いセクションを特定した場合に試してみると便利です。」とあるので、余程複雑なことをしていない限り不要だとは思うし、そんな複雑な型を返すような処理は必要がなければ書かないほうがいいだろう。

Type inference is very convenient, so there's no need to do this universally - however, it can be a useful thing to try if you've identified a slow section of your code.

少なくとも私は実務上、型推論の速度に困ったことがないのと、tscでビルドすることも稀であるため、ビルドに影響することもない。よって基本書いていない。

開発時に一々rootが持ってるフォルダを触るのが嫌でホームディレクトリ配下で作業したいというのは往々にしてあるので、それを楽にやる方法。

以下のようにnginxのルートディレクトリに適当なパスを切り、パーミッションを777にした上でシンボリックリンクを張ればよい。

sudo mkdir /var/www/html/hoge
sudo chmod 777 /var/www/html/hoge
ln -s /var/www/html/hoge hoge

ホームディレクトリをnginx設定のrootとして指定すると上手く行かなかったので、そのアプローチは諦めた。（755指定してても読みに行けない、777ならいけると思うがそれは避けたい）

皆さんは神戸市と聞くと何を思い浮かべるだろうか？
都会、おしゃれ、洋食、港町、1000万ドルの夜景、六甲山、色々あるだろう。

実は神戸市は農林業や水産業、畜産業も盛んであり割と大抵の食材を手に入れることができる。米は勿論のこと、ゴーヤーやドラゴンフルーツさえ手に入れることが可能だ。水産品としてはわかめや海苔、瀬戸内の魚介類などもあるし、畜産としては牛肉や豚肉だってある。そういう部分もあり、神戸市は食都神戸と名乗っている。

私はここ数年、地産地消に興味があり、つい最近ほぼほぼ神戸市産素材で味噌汁が作れるのではないか？ということに気がついたのだ。

まず神戸市産の味噌、北神みそがあり、これは神戸市産の米と大豆で出来ている。流石に使われている塩は神戸市産ではないが、兵庫県にゆかりのあるものが使用されている。

以下の写真は産直市的なイベントで購入した北神みそだ。イベントで買ったのでパンフレットと謎のチラシが入っていた。

豆腐についても神戸市内の豆腐業者が兵庫県産大豆と神戸の水を使って作っているものがある。この豆腐は兵庫県が認定するひょうご推奨ブランドに指定されている。認定には兵庫県に対するこだわりが多分に求められ、審査基準は結構厳しい。

他の具材についても、わかめ、大根、サツマイモ、しいたけは神戸産があるので、これは作れそうな気がしてくる。
玉ねぎだけは淡路島が近いこともあり、見たことがないのだが、なんとこれもあるらしい。

味噌汁の出汁についてはいりこ、昆布、鰹節は恐らく神戸市産がないのでちりめんじゃこで拵えようと思う。いりこは探せば可能性はゼロではないと思うのだが、漁港の直売所で売られていたものは大分県産のカタクチイワシを神戸市でいりこに加工したものだったので、希望は薄いだろう。

以下の写真はこないだ作った神戸市度の高い味噌汁である。だしの素は使わずにいりこからだしを取って作っているのがこだわりだ。

原材料はいりこ（原産地大分県、加工地神戸市）、味噌（神戸市北区産）、葉付き大根（神戸市西区産）、さつまいも（神戸市西区産）、玉ねぎ（淡路島産）、菌床しいたけ（加古川市産）、わかめ（三重県産）と、結構神戸市産を取り入れられたと思う。そこに外れても県内産、そこを外れても何とか関西地方の品で揃えられた。

実はしいたけも前日まで神戸市北区産があったのだが、味噌汁にすることを忘れて前の夜に焼いて食べてしまい、急遽調達したので市内産が手に入らなかったのだ。それでも一応県産品には拘れたので良かったと思う。わかめについては買いに行ったら売り切れていて入手自体が叶わなかった。

因みに味噌汁を作ったりだしを取るのはこれが二度目であるが、まずまずの出来だった。初めてはこれの二日前にガザミで出汁を取って作ったが、それもまぁまぁよかった。これは二回目の味噌汁なので更に上手くできた。正直上出来といってもいいレベルだ。そんな大変美味しいわけではないが、インスタント味噌汁よりは間違いなく旨いといえる仕上がりだ。

最後に神戸市産の味噌と、豆腐について私が現地で確認した販売所を書いておく。

北神みそ 販売所

兵庫の地豆腐 販売所

神戸市産の野菜が買えるところ

ライフにもあるにはあるが、無難なのは商店街の八百屋に行くことだと思う。ただこれでも取り扱いは限られるので、色んな野菜が欲しい場合に便利なところを紹介する。

一つは先ほど紹介した道の駅 神戸フルーツ・フラワーパーク大沢なのだが、もう一か所ある。