OmniAICreator/Qiita-1.07M huggingface dataset:
fieldにresolverを当てて擬似的にqueryをネストする

## はじめに
GraphQLの利点として「必要なデータを一括取得できる」という点があると思います。
RESTfulなAPIとの違いという意味も含めて、
今回はqueryを組み合わせて依存関係にあるデータを一括取得する方法を書きたいと思います。

あくまで設計指針という内容なので、具体的な環境構築方法は趣旨からはずれるため割愛します。

## 使うもの
- 言語: Ruby2.7
- Gem: graphql-ruby, graphql-rails

# やりたいこと
例えば以下の2つのqueryを同時に呼びたいとします

```graphql
{
  customer(name: "hoge") {
    id
  }
}

{
  invoice(customerId: 1, status: "open") {
    price
  }
}
```

ですが、customerIdを知るにはcustomer queryを叩かなければならないため、
愚直にやるとcustomer queryを叩いてcustomerIdを取得してからinvoice queryを叩く必要があると思います。

なら以下のようにすればいいと思うかもしれません。

```graphql
{
  customer(name: "hoge") {
    id
    invoice(status: "open") {
      price
    }
  }
}
```

しかし、これだと「customerIdを知っている状態でinvoice queryを単体で呼びたい時」に困ります。
せっかくcustomerIdを知っている状態でcustomer queryを呼ぶとOver-fetchingになりますよね。
そのため、queryはqueryで残したいと思います。

## 解決策

以下のようにcustomer queryの**invoice field**にcustomerIdを渡すことでqueryをネストしたようにできます。

```graphql
{
  customer(name: "hoge") {
    id
    name
    # invoice queryと同じ
    invoice(customerId: null, status: "open") {
      price
    }
  }
}

# query単体でも叩ける
{
  invoice(customerId: 1, status: "open") {
    price
  }
}
```

## メリット
このようにすることで、queryをそのままobject typeのfieldに充てることができます。
具体的にはこの後の実装を見ていただきたいです。

## 実装の具体例
今回はgraphql-rubyを使用します。
query typeは以下のように定義します。

```types/query_type.rb
module Types
  class QueryType < Types::BaseObject
    field :customer, resolver: Resolvers::CustomerResolver
    field :invoice, resolver: Resolvers::InvoiceResolver
  end
end
```

graphql-rubyでは基本的にresolverをクラス単位で作成します。

```resolvers/customer_resolver.rb
module Resolvers
  class CustomerResolver < BaseResolver
    type Types::Object::CustomerType, null: true

    def resolve(name:)
      Customer.find_by(name: name)
    end
  end
end
```

ここでCustomerTypeのinvoice fieldにもresolverを充てます。

```types/object/customer_type.rb
module Types::Object
  class CustomerType < Types::BaseObject
    field :id, ID, null: false
    field :name, String, null: false
    # queryと同じように定義できる
    field :invoice , resolver: Resolvers::InvoiceResolver
  end
end
```

InvoiceResolverはというと
object(Customerインスタンス)からinvoiceをたどることも
引数のcustomer_idからinvoiceを取得することもできるようにします。

```resolvers/invoice_resolver.rb
module Resolvers
  class InvoiceResolver < BaseResolver
    type Types::Object::InvoiceType, null: true
		
    argument :customer_id, ID, required: false
    argument :status, String, required: true

    def resolve(customer_id:, status:)
      raise ArgumentError if object.nil? && product_id.nil?

      # 引数の有無で判定
      customer_id ? Invoice.find_by(customer_id: customer_id) : object.invoice
    end
  end
end
```

## まとめ
これでqueryとqueryをネストできているはずです。
このようにquery同士も組み合わせることができるところがGraphQLの魅力かと思いました。
リクエストを一つにまとめることもできますし、customer_idのように一度保持した値から単体でクエリを叩いて必要な分だけ取得するというNot Over-fetchingなところが強力ですね。
技術の詰め込み方


この記事は[Ateam Hikkoshi samurai Inc.× Ateam Connect Inc. Advent Calendar 2021](https://qiita.com/advent-calendar/2021/hikkoshizamurai-connect) 9日目の記事です。

## はじめに

こんにちは、@ysysysysと申します。
**「引越し侍　ネット見積もりサービス」** というサービスを 11 月にリリースいたしました。

https://hikkoshizamurai.jp/moving

本アドベントカレンダーの [1日目](https://qiita.com/sho-hata/items/054c77392cc61bc2f3ac)、[2日目](https://qiita.com/anneau/items/3936c954690a28c51c8f)でバックエンド・フロントエンドそれぞれの技術について、@sho-hata さんと@anneau さんが紹介してくれておりますので是非ご覧ください！

さて、今回のプロダクトでは、個人的に未経験の技術/サービスを多分に採用しております。

バックエンドでは

- GraphQL
- [Hasura](https://hasura.io/)
- Firebase

フロントエンドでは

- TypeScript
- React/Next
- [Nx](https://nx.dev/)

などなどです。
これらは開発に入る前までは、ちょっと触ったことがある、名前くらいは聞いたことがある、程度の技術でした。

にもかかわらず、**バックエンド・フロントエンドの垣根なく開発をすることになった**ので早急に**コードレビューで指摘されてない程度**に技術レベルを上げる必要が出てきました。

本記事では、未知の技術を短期間でそこそこの水準まで使えるようにするため、自分なりの技術への向かい方をご紹介できればと思います。

## 基本的なスタンス

先も述べたように、今回の未知の技術に対する基本的なスタンスは、「**そこそこ水準**まで持っていければ御の字」です。技術の習得そのものが目的ではなく、本来の目的は**プロダクトの成功**であることを見失わないようにします。

その上で、

- できるだけ最適なプラクティスをとれる
- 技術的負債の発生を最小限にとどめる
- 隙あらば、ある特定の分野に関してメンバーの中で一番詳しくなる

ことができれば十分であると考えました。

## 新しい技術との向き合い方

### 自分の知っている技術との比較

手っ取り早く未知の技術を使えるようになるには、自分が既に知っている技術と比べるのが効果的です。

その上で必要となってくるのが引き出しの数です。

当たり前ですが、全く知らないことに対しては歯が立たないので、常に自分の引き出しの数を増やしていく姿勢は重要です。

今回のプロダクトではフロント側でTypeScriptを用いています。
静的型付け言語である程度身についていたのはGo言語だったので、それと比較しながら理解を進めました。

ただ、同じ用語でも違う概念のものがあるなど、油断はしてはいけません。


## 以前の技術と比べて結局「何が良くなったのか」に焦点を当てる
これは意識の問題ですが、新しい技術が、以前の技術と比べて何が良くなったのか、に着目すると理解が早まります。

例えば、GraphQLに関して、同じくWebAPIの規格であるRESTと比べてどのような点が有利になったのかについて着目し情報を集めると、その柔軟性・スキーマ・型定義による効率化、などがメリットなのだと分かるでしょう。

技術のルールや文法を、そのメリットを意識して考えてみると理解が早まります。

GraphQL繋がりで、[Fragment](https://www.apollographql.com/docs/react/data/fragments/)という概念が登場します。

初めてFragmentに接した時、*全くちんぷんかんで心が折れそうになりました*。
ですが、Fragmentを用いてコンポーネント内で取得するデータの定義ができることで、**再利用性の向上・オーバーフェッチ、アンダーフェッチの発生防止**などのメリットが享受できることを意識すると、ルールやお作法がなんとなく腹落ちしてとっつきやすくなりました。


## まぁとりあえず動かす
何はともあれささっと環境を作ってやっちゃいましょう。
興味の薄い分野に対しては腰が重いこともあるでしょうが、それでも何かしらお尻を叩かれざるを得ないように仕向けてみるのがいいです。

私の場合初めてReactにふれるにあたって、知人のWebサイトをReactで構築するお手伝いをしました（無報酬です💰）。

自分で勉強用にプロダクトを作る、でもいいのですが、やはり誰かの役に立つものを作れるのが一番です。

また、**自分ではない誰かが仕様を決めてくれる**のも技術習得に効きます。
（自分が決めるとどうしても楽な方に流れちゃうので、、）


## 強い人におんぶに抱っこ
これは環境によって左右されるかと思いますが、身近に強い人がいらっしゃるなら存分に頼りましょう。
幸い弊社では、各方面に明るい方々が多数いらっしゃいました。
先人のお知恵をどんどん吸収するのが結局のところ一番の近道だと感じます。

## 最後に
つらつらと当たり前に近いことを書いてきましたが、最後に最も重要なのは**苦手意識をもたない**ことだと思います。私はもっぱらRailsをメインにしてバックエンドを主軸にしてきましたが、今回はがっつりフロント側も触っています。

あまり支障なくフロントの知識も吸収できているのは、苦手意識を持たず、一旦やってみる精神を持てていること大きいのかなと。

結局は**気の持ちよう**というエンジニアらしからぬ結論に至ったところで筆をおきたいと思います。

## 明日は
明日は@acc1ioさんがJavaScriptについて記事を書いてくださります！
お楽しみに！！
VULNCON CTF 2021 WriteUp（適宜更新中）

# 概要

本記事は、先日行われたVULNCON CTF 2021のWriteUpとなります。

結果は130/187th, 10points、Welcome問題しか解けませんでした････

解けた問題については自分の解答を、解けなかった問題に関しては自分なりの解答への道筋を記載しておきます。

# 環境
Windows + Kalilinux
プログラムはすべてPython3

# 解けた問題
## Misc
### Sanity Check

```
Here's your flag : VULNCON{g00d_luck_4nd_Have_fun}
```

Welcome問題。
このCTFでのフラグの形式は`VULNCON{g00d_luck_4nd_Have_fun}`

# 解けなかった問題
## Crypt
## Misc
### 
## Pwn
## Reverse
### 
## Web

# 所感

# 他の方々のWriteUp
https://nandynarwhals.org/vulncon-ctf-2021/

https://ctftime.org/event/1469/tasks/
非同期に使われるPub/SubモデルのPush方式とPull方式ってどう違うの？

## SubscriptionからSubscriberへのメッセージ伝達の方法は2つ

- Push方式
- Pull方式

ほとんどのメッセージキューでは、メッセージの取得に、プッシュオプションおよびプルオプションの両方を利用できます。

例えば、AWSのSQSやGCPのCloud Pub/Subとかがそうですね。

こういった、メッセージング方式をPub/Sub Messaging
といいます。
参考：https://aws.amazon.com/jp/pub-sub-messaging/

### Push方式

1. PublisherがMessageをPublishします。
2. Message QueueがPOSTリクエストをSubscriberに対して送ります。

というのが、Push方式で、SubscriberはHTTPエンドポイントを提供するのが一般的です。

### Pull方式

1. PublisherがMessageをPublishします。
2. SubscriberがGETリクエストをSubscriptionに対して送ります。

というのが、Pull方式で、Subscriberはwokerプロセスとして、メッセージキューに対してリクエストを定期的に送るというのが一般的です。

## どっちがいいの？

どちらがいいかは要件によりますが、キーワードは「**時間的疎結合**」だと思っています。

そもそも、非同期の処理を使っているということは、アプリケーションコードが論理的には、直接別のプロセスに依存しないようになっていると思います。

ところが、Push方式の場合は、時間的密結合になります。
Pull方式の場合は時間的疎結合になります。

時間的密結合というのは、PublisherがMessageをPublishする瞬間にSubscriberがActiveであることに依存するかどうかです。

Push方式であれば、受け取り手がいなくなり、メッセージは棄却されます。（不整合を防ぐために幾つかの工夫は可能。例えば、リトライ。または、デッドレターキューを利用する方法）
Pull方式であれば、SubscriberがActiveになった時にMessageは Consumeされるので、時間的に疎結合にすることができます。

その分、時間効率がいいのは、Push方式です。
[ TypeScript ] 型アサーションについて 〜 TypeScript の as の正体 〜

## このシリーズの概要

これまで、業務やプライベートで Typescript を書いてきました👇 （例） しかし

https://qiita.com/ryosuketter/items/8dd8eb7c761abea8626c

なんとなく書いてきたので、キチンと理解する目的で書こうと思い、気になる単位ごとにまとめてアウトプットしようと思いました。

今回書くのは「型アサーション」についてです。

## 型アサーションについて

TypeScriptには型の指定の方法が様々ありますが、今回は型アサーション(Type Assertion)について書いていきます。

型アサーションとは、推論された型や、既に型定義済みの変数の型を上書きします。別の型を定義できてしまうのですね。。

なんでも上書きできるわけではなくて、型の互換性があることが前提です。

実際に見てみましょう。

```ts
const data = {} // 空のオブジェクトだと型推論される
data.foo = 1 // エラーが起こる
```

![スクリーンショット 2021-12-08 23.44.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/14191/626edb56-607a-e0f3-d632-d4de3cace8d8.png)

勝手に型推論されて、代入ができなくて困るシーンがあったなら、型アサーション(Type Assertion)を用いるチャンスです。

```ts
interface testType {
  foo: number;
}

const data = {} as testType;
data.foo = 1;
```

これでコンパイルエラーは出なくなります。

左辺（この場合は`data`）に型アノテーションするのではなく、右辺`{}`に対して型アノテーションする方法もあるのですね。

## 型アサーションを使う際に注意すること

型アサーションは便利ですが、型推論を書き換えてしまいます。そうなると、エラーを起こしそうな記述をしてもコンパイラが指摘してくれない可能性があり、ランタイムエラーを起こす可能性があります。

### 例えば

```ts
interface testType {
  foo: number;
}

const data: testType = {} // Property 'foo' is missing in type '{}' but required in type 'testType'.
```

プロパティ`foo`の追加忘れているよ。という指摘をしてくれます。

しかし、型アサーションの場合は指摘をしてくれません。

```ts
interface testType {
  foo: number;
}

const data = {} as testType;
```

ランタイムエラーを起こす可能性を感じませんか？:fearful:

なので、一時的な使用に限った方が良さそうだなと感じました。

もし、型アサーションの有効性を感じられるケースが分かれば加筆したいと思います！

読者の方でいい例をご存知の方がいらっしゃれば、ぜひ教えてください！

以上です。

## 参考

https://typescript-jp.gitbook.io/deep-dive/type-system/type-assertion

## アウトプット100本ノック実施中

https://qiita.com/ryosuketter/items/713474dbd009870e4103
多言語対応をしようとして諦めた話

この記事は [驚異のFANZA女優検索](https://fanza-actress-bust-search.azurewebsites.net) Advent Calendar 2021 の 9 日目の記事です。

# 多言語対応を諦めた話
今日は実装した話ではなくて、実装しようとして諦めた話。諦めた機能は日本語、英語、中国語、韓国語を切り替えられるような実装を考えていた。いわゆる多言語対応だ。

# 作ろうとしたきっかけ
自分のサービスを作って、Qiitaで記事を書いたら軽くバズった。ということはもしかしたら同じ内容を英語で書いたらまた英語圏の人の間で流行るかもしれない（流行らないかもしれない）と思った。日本語でQiitaで書いた記事なら、英語圏だと[Medium](https://medium.com/)がいいかな。。その後ふと、日本のアダルトって英語圏よりむしろアジア圏の方が人気があるという話をどこかで聞いたなと思った。確か蒼井そらが中国で人気があるとか。そうなると英語よりも中国か。あと韓国は近いから良いかなと思った。中国や韓国でブログ書くなら何処だろうと思った。韓国は[NAVER blog](https://m.blog.naver.com)。中国はちょっと調べただけじゃ良く分からなかったけれど[微博(weibo)](https://weibo.com/login.php)かな？

# 日本語、英語以外普通に作れるのかすら分かってない
ただ、Mediumは兎も角、NAVERや微博はルールが分からない。先ずfabsabsfabsabsという名前で作っても良いのだろうか？韓国や中国は英字の名前でブログを書くのはありなのか。例えば調べて他にも英字の名前の人が居たとしても、それがその国でどう受け取られるか分からない。そういえば韓国は本名が普通だとか見たような気もする。また本当に本名で作りたくなった時に、今回登録しちゃっているともう作れないかもしれない。そうなると気軽に試すのもちょっと怖くなる。ましてや最近は電話のSMS認証とかあるけれど1回こっきりの場合もあるしなとか。色々不明なことが多い。

# Azure Translator
で、もし日本語以外でブログを書くことになるならサービス自体も言語対応をしておいた方が良いんじゃないかと思って、4ヶ国語対応を考えた。問題は翻訳なので、調べたら[Azure Translator](https://azure.microsoft.com/ja-jp/services/cognitive-services/translator/#overview)というのがあった。100以上の言語に対応しているので4ヶ国語対応が上手くいったらさらに足しても良いかなと思った。毎月 200 万文字は無料なので、その枠で使えるなら、かなりいい感じかもしれない。最近の機械翻訳であればかなりの精度のはずだけど、ただ韓国語とか中国語はどの程度なのかそれすら分かってないし、正直自分のスキルでは手直しなど全く出来る気がしない。ん－。

# サイトのリソースを試しに翻訳
とりあえず選択した言語でそれっぽくなればクオリティは二の次で良いやと思った。兎にも角にも試してみた。自分のサービスのトップページを見た場合、まず女優名が並んでいる。となると最初は女優名の翻訳と思って、Azure Translatorを走らせてみた。ア行から始まる女優名は「アイ、Ai、あい、亜衣、AI」だ。

|  日本語  |  英語  |  中国語(簡体字)  |  中国語(繁体字)  |  韓国語  |
| ---- | ---- | ---- | ---- | ---- |
|アイ|eye|眼|眼|눈|
|Ai|Ai|Ai|Ai|아이 (주)|
|あい|yes|爱|愛|예|
|亜衣|Ai|亚衣|亞衣|아이 (주)|
|AI|AI|AI|AI|AI|

んー、ん、うーん。「アイ」は英語で「eye」か。。なるほど。うーん。「Ai」は英語で「Ai」、「あい」は英語で「yes」。。。

まあでも特殊な名前だしなと思ってさらに何人かやってみた。

|  日本語  |  英語  |  中国語(簡体字)  |  中国語(繁体字)  |  韓国語  |
| ---- | ---- | ---- | ---- | ---- |
|愛あいり|Ai Airi|爱爱|愛愛|아이 아이아이|
|あいあおい|Aioi|爱啊，嘿|愛啊，嘿|아이오이|
|藍色しあん|Indigo Shian|蓝色的|藍色的|인디고 시안|
|藍色なぎ|Indigo Nagi|蓝绿色鳗|藍綠色鰻|인디고 나기|
|藍色りりか|Indigo-colored Lyaka|猩红里卡|猩紅裡卡|인디고 컬러 라이아카|

「藍色しあん」が「Indigo Shiana」。そうか。Indigoか。さらに「藍色りりか」は「Indigo-colored Lyaka」か。うーん。。IndigoとIndigo-coloredの違いも分からん。。さらに言うと英語ならおかしいことぐらいは気づけるが、正直中国語、韓国語なんておかしいかどうかすらさっぱり分からない。でも愛あいりで爱爱や愛愛は多分違うよね？ここで名前の翻訳って普通の翻訳よりも難しいのかと初めて気づいた。大体女優名は芸名が多いし、当て字的な名前の人も多い。当て字を正しく翻訳するのは殆ど無理なのではと思った。

# Azure Translatorでローマ字を正しく作れるか
この時点で大分諦めモードではあったが、とりあえずせめて英語は正しくローマ字にしてくれないかと思って色々試した。例えば女優名はひらがなも分かっているので、ひらがなで翻訳すればローマ字にならないかとか。ひらがながが駄目ならひらがなでかつ1文字ずつ翻訳するとか。その後も色々考えたが、結局どの方法でも結局正しいローマ字はならなかった。あと作品タイトルになるとさらに難しいのではないかなと思った。なんせアダルト、伏せ字が多い。そんなのいい感じの翻訳は無理だろうと思った。結局女優名と作品タイトルがこのレベルの駄目翻訳にしかならない時点で多言語版を作ったところで全く意味が分からないことが書いてある変なサイトに見えるだろう。。と思った。

#もしそれでもやるなら
もしやるならお金を使って正式に翻訳を出すしかないかな。ただ、そこまでして多言語対応を作るつもりは今の所なかった。後はいわゆるWikipedia方式で、不特定多数の力を借りるしかないと思った。ページに編集機能を付けて、明らかにおかしい所を直せる機能。これをユーザーにやってもらう。ただ実際にやるとなると色々考えることは多い。ログインはどうするか？2人が別々のものを正解と言った場合は？わりと簡単な話ではない。。

# まとめ
ということで多言語対応は一旦諦めた。今日で新機能話はおしまい。明日からは既に実装しているサービスの解説の話に変わっていく。そろそろ事前に書いていたストックが無くなってきた。。
Dockerでrootとuserを切り替えてコンテナに入る

# はじめに
基本的にDockerコンテナを起動し，コンテナ内に入るとrootになる．
この状態でファイル作成をすると所有権がrootになり，扱いが面倒になる．
一方，コンテナ内にuserで入ることも可能だが，apt updateなどの操作が出来なくなってしまう．
Dockerfileでうまいこと調整すればよいのかもしれないが，今回はコマンドだけで完結する内容を書き残す．

# できること
基本的にuser権限でコンテナに入ることができるようになり，root権限が必要なときは適宜切り替えることができる．

## 実行環境
OS: Ubuntu 20.04 LTS

## 1. Dockerコンテナを起動し，userで入る
以下の記事のうまくいく方法2を参考にした．
[dockerでvolumeをマウントしたときのファイルのowner問題](https://qiita.com/yohm/items/047b2e68d008ebb0f001)
こちらの記事から対象となるコマンドを引用する．

>```:ホスト
docker run -it -v /etc/group:/etc/group:ro -v /etc/passwd:/etc/passwd:ro -u $(id -u $USER):$(id -g $USER) ubuntu bash
```

実行すると，userでコンテナ内に入っていることが確認できる．
![user.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/472706/ce00d42f-e255-5ffc-5d5a-63407d7490d7.png)




## 2. コンテナからデタッチ
コンテナに入っている状態で以下のショートカットを入力．

```:コンテナ
[control-P] [control-Q]
```

## 3. rootでコンテナ内に入る
Docker execで起動してあるコンテナにrootとして入る．

```:ホスト
$ docker exec -u 0 -it container_name bash
```

実行すると，rootでコンテナ内に入っていることが確認できる．
![root.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/472706/209b73f1-6db7-6462-b0e2-9c77c92fe15d.png)


## おまけ
またuserでコンテナ内に入りたいときはアタッチすればよい．

```:ホスト
$ docker attach [ContainerID or ContainerName]
```

# まとめ
- Dockerコンテナにrootとuserを切り替えて入る方法を紹介した．
- Dockerfileの設定が面倒くさいと感じるのであれば，この方法はちょうど良いかもしれない．

# 参考サイト
[Dockerコンテナからのデタッチ](https://tech.withsin.net/2015/09/30/docker-container-detach/)
[dockerでvolumeをマウントしたときのファイルのowner問題](https://qiita.com/yohm/items/047b2e68d008ebb0f001)
[Root password inside a Docker container](https://stackoverflow.com/questions/28721699/root-password-inside-a-docker-container)
Redmineでコーヒーの焙煎記録を管理したいと考えている件

# はじめに

珈琲焙煎人兼エンジニアのamarelo（アマレロ）と申します。久々にQiitaで記事を書きます。

私は普段コーヒー豆を焙煎した記録を一度紙に書いて、Excelにも記録しています。
しかし、何かと手間なので、もっと素早く記録ができ、過去の焙煎記録を見返しやすくしたいと考えています。ただ、Webアプリを作れる能力は足りないし・・・と思っていましたが、ふと、

**Redmineで記録してみようか？**

と考え始めました。3か月くらい前にも一度思い立ってTweetしましたが、ほとんど進捗していません。今の想定を一度書き出して今後少しでも進捗させるキッカケにしたいと思い、記事を書こうと思った次第です。

# なぜRedmineにしたのか？

**Redmineを勉強する機会を作りたい**ってのが大きな理由です。
今、業務でRedmine導入を検討していますが、Redmineを焙煎管理に使えば、Redmine管理の勉強、カスタマイズの勉強もでき、趣味も仕事も学びが深くなりそうだなと思ったためです。

# サーバ管理するか？クラウドサービスを使うか？

サーバ管理観点でも勉強したいため、サーバ構築して使うことを目標にしたいと思います。
いろいろカスタマイズして自分好みの使いやすさを目指したいです。
ただ、環境構築できるまでに時間がかかっても良くないため、ひとまず出来るところをPlanio（無料プラン）でやってみようと思いました。

### Planioとは？

Redmineベースのクラウドプロジェクト管理システムです。
日本では、ファーエンドテクノロジー様が認定パートナーとなっています。

https://plan.io/ja/

https://planio.farend.jp/

# プロジェクト構成（ざっくりと）

Planioの無料プランだと作成できるプロジェクトは１つです。なので、プロジェクトを１つ作って、チケットは以下に関するトラッカーで分類しようと思います。

1.コーヒーの焙煎記録
2.焙煎したい生豆の記録
3.飲んだコーヒーの記録
4.焙煎室メンテの記録・備忘録

せっかくなので、焙煎の記録だけでなく、コーヒーに関する記録はとにかく残したいと思っています。焙煎室のメンテ記録や備忘録なども残したいと思います。

### 焙煎したい生豆の記録

自分は焙煎を生業としていませんが、焙煎したい豆は山ほどあります。
どこかに記録しておかないと忘れてしまうし、焙煎したいときにできなくなってしまう。
なので、いずれ焙煎してみたいと思った豆は記録しておけるようにしたいです。

### 飲んだコーヒーの記録

様々な豆、様々なお店でコーヒーを飲みますが、キッチリと記録しているかといったらそうではありません。いつでも記録はしておきたいし、ふと見返したいときに手元にある状態にしておきたいなと思いました。

# チケット入力

基本自分が使うだけですが、入力項目は最低限にしたいと思っています。
また、楽に入力できるように入れられるカスタマイズは色々試してみたいと思っています。
トラッカーごとに記録する情報が様々なので、かなりカスタマイズしがいがありそうですし、カスタムフィールドもたくさん作ることになりそうですｗ

# 最後に

今日のところは今後の希望を書いただけで、Redmineに関する知見や技術ネタありませんでしたが、最後まで読んでいただきありがとうございました。とにかく使ってみた結果を今後どこかでアウトプットできればなぁと思っています！！
AndroidXのSnaphostで遊んでみる

こんにちは
最近Widgetにハマっているどすこいです

先日のAndroid Dev Summitで大きなアップデートがあったWidget

https://blog.kyash.co/entry/2021/11/19/125319

僕はせっかちなのでalpha版になる前から遊びたいのです
早く遊びたいなぁと思ってたらSnapshot版で遊ぶ方法を見つけたので紹介します

## 遊び方
全てはここに詰まってます

https://androidx.dev/

```build.gradle
allprojects {
    repositories {
        google()
        jcenter()
        maven { url 'https://androidx.dev/snapshots/builds/[buildId]/artifacts/repository' }　//　この一文を追加
    } 
}
```

buildIdはこちらに載っています
一番上のものが最新なので一番上のものを使うといいと思います
https://androidx.dev/snapshots/builds

あとは簡単です
僕はWidgetで遊びたいので最新のbuildIdから
repository/androidx/glance/glance-appwidgetの欄のmaven-metadata.xmlを探して開いてみると

```xml
<metadata>
  <groupId>androidx.glance</groupId>
  <artifactId>glance-appwidget</artifactId>
  <versioning>
    <latest>1.0.0-SNAPSHOT</latest>
    <versions>
      <version>1.0.0-SNAPSHOT</version>
    </versions>
    <lastUpdated>20211208132101</lastUpdated>
  </versioning>
</metadata>
```

こんなものがあるので任意のプロジェクトのbuild.gradleに

```build.gradle
implementation 'androidx.glance.glance-appwidget:1.0.0-SNAPSHOT'
```

と追加するだけです。

あとは楽しむだけです！！

### 注意
snapshot版なのでおそらく破壊的変更は何度も起きると思います。
耐えられない方はお控えください。
Node.jsを使ってMongoDBに対するコネクションを使い回す方法

# はじめに
個人的な開発を行う中でNode.jsとMongoDBを使ってAPIを作成する機会がありました。
そこで私なりに作成した、一度作成したコネクションを使い回す方法を備忘録として残します。

# 実装内容
MongoDBのコネクション作成処理はシングルトンクラスで実装しました。

```Javascript:mongo.js
const { MongoClient } = require("mongodb");
const user = "ユーザー";
const password = "パスワード";
const dbName = "DBの名前";
const uri = "URL";
const client = new MongoClient(uri, {
  useNewUrlParser: true,
  useUnifiedTopology: true
});

class Mongodb {
  constructor() {
    this.db = null;
  }

  async get() {
    // 一度もインスタンス生成されていない場合のみDB接続情報取得
    if (this.db === null) {
      await client
        .connect()
        .then(() => {
          console.log("接続成功");
          this.db = client.db(dbName);
        })
        .catch(error => {
          throw error;
        });
    }
    return this.db;
  }
}

module.exports = new Mongodb();
```

以下のようにmongo.jsのgetメソッドをコールします。

```Javascript:apis.js
const dbConnection = require("シングルトンクラスのパス");

exports.findOne = function(req, res) {
  const db = dbConnection.get();
  res.end("呼べたよ");
};

exports.findAll = function(req, res) {
  const db = dbConnection.get();
  res.end("呼べたよ");
};
```

# おわりに
今思えば大したことではないですが、結構時間がかかってしまいました。
同じようなことで悩んでいる方の参考になれば幸いです。

# 参考
[Setting up singleton connection with node.js and mongo](https://stackoverflow.com/questions/24547357/setting-up-singleton-connection-with-node-js-and-mongo)
Google カレンダーに社外の人から招待された Google Meet の URL を設定する

センシンロボティクスではドローンなどの機器を扱う場合以外はリモート勤務となっており、Google Meet を利用することが多いです。

予定された社内会議に参加するにはカレンダーの予定に設定されている
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58490/f1fe227d-348d-bcfc-f7a5-3c30b193ceb1.png)
ボタンをクリックするだけで会議に参加できます。便利ですね。
ただ、社外の方から Google Meet に招待された場合、予定の説明欄に URL が書いてあったり、
会議の時間になって慌ててメールや Slack を探してしまう人も多いのでないでしょうか？(自分です)

実は Google カレンダーに設定した Google Meet の URL (会議ID) は編集することができます。

1. Google Meet のビデオ会議を追加
1. 会議の詳細を表示
1. 会議IDを編集
1. 保存
![input-meet-id.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58490/99983f61-ae17-d02c-1906-27de4beb1470.gif)

これで社外の人から招待された会議にも `Google Meet に参加する` ボタンからスマートに参加できますね。
プロジェクトの課題管理に Backlog を導入した話。

# はじめに

こちらは [Backlog Advent Calendar 2021](https://adventar.org/calendars/6325) 8日目の記事です。
ギリギリの投稿でごめんなさい！

今回は、新しく参画したプロジェクトに Backlog を導入した時のことについて振り返ります。

# 記事を書くきっかけ

私自身の Backlog 歴は5～6年ほど。
出会うきっかけとなったプロジェクトでは、顧客も関連ベンダーも利用していて、プロジェクトのコミュニケーションの中心には必ず Backlog がありました。

今年の秋頃、私は久しぶりにプロジェクトの異動があり、すでに稼働しているサイトの運用保守案件にアサインされました。

異動して最初にカルチャーショックを受けたのが、課題管理。
エクセル（Google スプレッドシート）で行われていて、数百件近くあり、メンテナンスはされておらず、日々課題は増え、どの課題がどういう状態なのか、プロジェクトの誰も分からない状態になっていました。

これはいかん！という事で、すぐに顧客に相談して Backlog の運用を開始しました。

# プロジェクトに Backlog を導入する
## 最初にやったこと
Backlog を運用するための前準備として、次のことを実施しました。

### エクセルの課題管理表の棚卸
エクセルの課題管理表は完全に廃止することにし、重複やクローズ忘れ、取り下げなどの課題を整理しました。
この時点で半分くらいまで課題の件数を減らしました。

### エクセルから課題を転記する
エクセルから Backlog への転記は手動で行いましたが、もっと楽な方法があったかもしれません。

### 運用ルールを決める
前のプロジェクトでは運用ルールが定まっておらず、課題の立て方やステータス管理がバラバラでした。
故に、いわゆる「ゾンビチケット」が大量に発生していたのが反省点でした。

運用ルールは細かく決め過ぎると破綻するため、最低限守ってほしいことだけ決めて、Wikiに記載しました。

以下は、どのプロジェクトでも私が大切にしている Backlog の基本原則です。

```
ひとつの課題に複数のテーマを持ち込まない
件名・詳細は、後から誰が見ても分かりやすい内容にする（細かくなくて良いが、抽象的な表現などは避ける）
完了条件を明確にする
```

### 関係者を招待する
ここは特に工夫したことはありませんが、各社の窓口（最初に担当者にする人）は明確にし、運用ルールとしてWikiに書いておくようにしました。

### Backlog の利用を習慣付ける
Backlog に限らず、新しいツールの導入で苦労するのが「利用を習慣付ける」ということ。
従来は Slack のスレッド上のやりとりで済ませていたり、エクセルの課題管理表を使い続ける人もいたので「これから課題管理はBacklogを使ってね！」とプロジェクト内に啓蒙し続けました。

＜啓蒙活動の例＞
・Slack にコメントされた課題を Backlog に転記して「続きはここでやりとりしてね」と連絡。
・まずは自分が積極的に Backlog を使って（会議のアジェンダなども）、周りを強制的に巻き込んでいく。

やはり最初は使い慣れていないこともあり、Backlog の運用が盛り上がらなかったのですが、あきらめず地道に啓蒙していくことで、少しずつ浸透していきました。
今では「Backlogで課題管理しよう」という意識がプロジェクト全体に根付きつつあると感じています。

## 導入して良かったこと

- 課題を定量的に把握できるようになった
- 結論の他、やりとりの内容も含めて、情報をきちんと残すことができるようになった
- プロジェクト内のコミュニケーションが活発になった
- 課題の「種別」や「状態」の種類を統一できる

特に大きなメリットとして感じるのは、課題の定量把握と、情報のスタッキングです。
エクセル時代は課題が更新されていない・ステータスなどが統一されていないといった理由から正しく状況を把握するのが困難になっていました。そこが改善されただけでも大きな進歩です。

## 改善したいこと

- 課題のテンプレートがないので、内容の粒度などにバラつきがある
- 最初に転記した課題の件数が多すぎて、どれから手を付ければ良いか分からない（現在棚卸中）
- Wikiを活用しきれていない（今は運用ルールしか書いてない）

他にも色々と改善したい点があるので、ひとつずつ取り組んでいけたらと思います。

# まとめ
プロジェクトに Backlog を導入して2か月ほど経過しましたが、少しずつ運用が形になってきました。
引き続き啓蒙活動を続けながら、プロジェクトの課題管理やコミュニケーションをもっと良いものにしていきたいです。

もう少しきちんと成果が見えてきたら、Backlog の導入や運用に悩んでいる方向けに、
いつかの [JBUG](https://jbug.connpass.com/) のイベントで発表してみたいと思います。
よく使うgitコマンドまとめ

###よく使うgitコマンド
```◆git init```
gitファイルを作成。

```◆git add .```
```◆git add パス名/ファイル名```
ファイルやディレクトリをインデックスに追加するために使うコマンド。
gitにあげたくないものは、git ignoreするので大抵は全指定を意味するピリオド「.」を使う。

```◆git status```
リポジトリの状態を確認するために使うコマンド。

```◆git diff```
gitのコミット前のコードとの変更点を見ることができる。

```◆git commit```
```◆git commit -m 'コミットメッセージ'```
```◆git commit --amend -m '修正したコミットメッセージ'```
追加・変更したファイルをGitに登録するためのコマンド。
-mのオプションを使うと、そこに直接コミットメッセージが書ける。
--amendオプションをつければ、直前のコミットメッセージを修正することができる。

```◆git push origin　ブランチ名```
```◆git push origin head```
ローカルリポジトリにあるファイルからリモートリポジトリへと移動する作業を行う。
ブランチ名を指定してやれば、そこにプッシュされ、何も書かなければ、今いるブランチにプッシュされる。


```◆git branch```
ローカルブランチ一覧。

```◆git branch –d ブランチ名```
ブランチの削除。

```◆git branch -r```
リモートブランチ一覧。

```◆git checkout -b ブランチ名```
ブランチの作成と切替を行うことが出来る。

```◆git branch/switch 切り替えたいブランチ名```
ブランチの切り替え。

```◆git branch -v```
各ブランチの先頭コミットIDとメッセージを表示。

```◆git branch -vv```
追跡リモートブランチの名前表示。

```◆git branch -a```
リモートにあるブランチを確認し、欲しいリモートブランチを探す。


```◆git clone URL```
既存のリモートリポジトリをローカルに落とすために使うコマンド。
GitHubに公開されているリポジトリを自分のPCへ落とすときに使う。

```◆git pull origin ブランチ名``` 
リモートブランチの変更を取り込むために使うコマンド。リモートリポジトリにあるブランチ名を選択して、プロダクトをローカル落としてくる事ができる。pullはfetchとmergeの合わせ技。


###参考記事
[機能だけで覚える基本的なGitコマンド　〜ほぼほぼ作業順〜](https://qiita.com/Nedward/items/12b6b86a39795aa5201b)
AWSにおけるterraform管理の勘所

Plannning-Venue Advent Calendar 2021の3日目です。

https://adventar.org/calendars/7174

terraformでAWSリソースを作成、管理して来た中での所感です。
何でもかんでも管理しようとすると結構めんどくさいことがあるのである程度の線引はあってもいいかな？という記事です。
その中でいくつか紹介していきたいと思います。

# タグ

作ったは良いけど誰か(言及しないけど...)がタグを追加するわ消すわでtfファイルと整合性が取れなくなることが日常茶飯事でした。
都度importしても良いですが、物によってはタグ自体を管理しないという選択もアリです。

ignore_changes = "管理したくない対象"
といった書き方をしてあげれば、リソースに変更があってもterraformさんが無視してくれます。

```
  lifecycle {
    ignore_changes = [tags]
  }
```

# Lambda@Edge

CloudFontと併用するサービスですね。
basic認証を掛けたりX-Frame-Optionsヘッダを追加するあたりが定番でしょうか。

Lambda@Edgeをterraformで作成すること自体は特に問題ない(後ろ便利まである)のですが　、削除になると話が変わってきます。
結論から書くとdestroy一回では来てくれません。そもそも作成したLambda@Edgeを削除するなんてそうそう無かったりしますが...

destroyしようとするとこのように怒られます。

```
Error: error deleting Lambda Function (basic): InvalidParameterValueException: Lambda was unable to delete arn:aws:lambda:us-east-1:****:function:basic:2 because it is a replicated function. Please see our documentation for Deleting Lambda@Edge Functions and Replicas.
{
  RespMetadata: {
    StatusCode: 400,
    RequestID: "39cac4e5-f28d-4160-ad76-********"
  },
  Message_: "Lambda was unable to delete arn:aws:lambda:us-east-1:****:function:basic:2 because it is a replicated function. Please see our documentation for Deleting Lambda@Edge Functions and Replicas."
}
```

原因としてはエッジロケーションに実行する関数のレプリカが存在しているからです。
レプリカがCloudFrontから外れたタイミングで削除依頼が出され、実際に削除されるまでに結構時間がかかるようです。

https://aws.amazon.com/jp/lambda/edge/

https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-delete-replicas.html

ということで一回destroyして、エラー吐かれた後しばらく待ってからもう一回destroyといった手順が必要になります。

# Storage Gateway

詳細は以下の記事にまとめているのでざっくり書きますが、
Storage Gateway用のインスタンスがprivate subnetにある場合、
storage gatewayとして使用するためにアクティベートキーを取得するためにtfファイル群を２つ用意してapplyを2回叩く必要があります。

https://qiita.com/instant_baby/items/9cb44db98e93a93cce93

# Route53とACM

そもそもインフラをコードで書く(Infrastructure as Code)メリットはその再現性にあります。
また、コードを書く時間とコストが発生します。

Route53やACMをterraformで作成しようとすると結構沢山のコードを書く必要があります。

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/acm_certificate

全部terraaformで管理する必然性があるのであれば致し方なしですが、この２つはコードを作成するその時間に対してGUIでの作業量が非常に少ないので
これらはterraformで管理するか否かの線引がいるかなと感じています。

実際、私はこの２つに関してはほぼterraformで管理していません。
(一度作成してみましたが、これわざわざterraform化しなくても...といった状況になった事がありました)

# リソース沢山一気に作るツールとして使う

個人的にはこの用途で使用することが一番多いです。
検証用の環境をVPCからEC2その他RDSやらS3と、テンプレ化しておけばいつでもapply一発で検証環境が立ち上がります。

検証が終わったらdestroyしてしまえば良いので不要リソースの消し忘れで余計なコストがかかる心配も無しです。

また、似たようなリソースを沢山作成する場合、aws cliコマンドを使ってスクリプト回すよりも利便性が高い場合もあります。
先日Storage GatewayのVMインスタンス移行をしましたが、事前に検証環境でクライアントと同じ環境をterraformで作成し。
それをクライアント環境向けにkey/sec等々帳尻合わせをして当日は一発apply、動作確認してハイ終了。ダウンタイムを大幅に短縮することが出来ました。

このような感じで、terraformにおけるInfrastructure as Codeとしての恩恵はstateの管理だけではないということですね。

# まとめ

terraformは超便利!!だけど何でもかんでもterraform化すればいいってわけでもないよという記事でした。
フリーランス月報会の今年のまとめ

## 今年も終わりです

どうもえいやです。

最近はフリーランスでずっとブロックチェーン業界のWEBサービスアプリをつくる仕事をしています。

また、[8月から開業しているシェアハウス](https://www.aya-eiya.work/house)の経営もなんとか頑張っている感じです。

さて、早いもので今年ももうそろそろ終わりそうですね。ついては、毎月開催している[フリーランスエンジニア月報会](https://fmrm.connpass.com/)の年末版を、去年に続いて今年も開催する予定です。

https://fmrm.connpass.com/event/233660/

去年の8月、新しくできたギークハウスを盛り上げるイベントを色々と計画中にコロナ禍が始まってしまい、しょうがなくイベントの場をオンラインにうつしたことをきっかけに始まったこちらの会。

足掛け約1年半に渡ってたまに主催が忘れて遅れたり、参加者同士が雑談しておしまい、という感じになったりしつつも大抵はきちんと開催の体を保ちつつやってきました。

常連の方々をはじめ、これまでの会にご参加いただいた方々に感謝申し上げます。

## 今年の話題

会の趣旨が雑談なので、ほとんどがとりとめのない会話なのですが、以下にもっととりとめなくこういう話題ではなしていたというまとめをつらつらと書いていきたいと思います。

### 新年から春先

今年の初めには、M1　MBAを手に入れて色々と環境を作ったりなどしていたため、そちらの話題が多かったです。
また、このころの仕事では、フードデリバリー事業のお手伝いでモバイル向けアプリをFlutterで作ったりしていたので、その話題も多かったですね。
Dart + Flutterに関しては、個人的にはわりと気に入った技術となったので、[コミュニティでも割と色々な質問を受け付けて頑張っていた](https://discord.gg/AHPTCbpNcv)印象です。

最近は今のお仕事がちょっと忙しくってコミュニティを見に行けていないのですが、またFlutterは仕事で触ってみたいですし、その時にはまたコミュニティでの質問などに答えていきたいですね。

あと、フリーランスなので確定申告や税制についても年始の話題に登りやすかったです。この辺は、[うちで開催しているもくもく会](https://ay-house01.connpass.com/)でもたまに話題になります。

### 春から初夏

春から初夏にかけては、これといって注目度が高い話題がありませんでしたが、コロナやワクチンの状況についてはよく話していた印象です。先行きが不透明ななか、ギークハウスをはじめとしたシェアハウスは相当な危機に陥り、残念ながらたくさんの家が消えていきました。

大きな話題がなかったもので、主催の方から出したのが、そのころによく目につくようになってきた「3ヶ月でエンジニア」しかもフリーランスに、みたいなのってどうなの？という話でした。

ギークハウスには昔からエンジニアを目指す若者や30代から目指す、みたいな人も実際によく来ていたし、なんだったら本当に3ヶ月くらいでエンジニアに育て上げていた実績もあるので、不可能ではないはずです。

しかしながら、それはもともと適性がある方が、それなりに熟達したエンジニアに導かれて、本人も努力して、エンジニアになっている例でしかないので、広告のようなキラキラした印象ノセられてくる方々ってのはちょっと心配だなぁというのが今も引き続き受けている印象ですね。

インターネット上で無料か安価に手に入る学習素材はかなり進化しているので、IT技術者を目指すのは楽になっているかもしれないな、という意見もあり、まぁ、それは確かに？と思うところもあります。本気でやる人にとってはいい環境になってきているのは事実なので、変な広告やらサロンやらにひっかからず頑張って欲しいところです。

### 夏から初秋

夏、8月からはこの会の主催であるぼくが、新しくシェアハウスを始めましたので、その話題が多くなりました。それと、長年管理人を務めたギークハウス新丸子についても、新しい管理人と同時に統合されるギークハウス蒲田の住人を迎えて新体制になるため、そちらの状況についてもよく話題にしました。

ほくの運営下では、生活環境としてできる限りシンプルな生活を作っていくのが中心だったのですが、新しい管理では3Dプリンターなどをたくさん並べて色々なことにチャレンジするというのが特色となり、家の様子もだいぶ変わったようですね。

ほくが新しく始めたシェアハウスでは住人が0人のところから始めていたので、空きスペースを[レンタルスペース](https://www.instabase.jp/owners/8543911892)として運用していたりしたので、そちらの話も多少していました。

### 秋から冬

このころもあまり大きな話題はなく、定例の雑談では参加者が経営層の技術者として関わっていくなかで仕事や人材との向き合い方とか、そういう話をよくしていました。

主催が金融関係の業務をしているので、昨今勢いをつけている後払い決済サービスについての話題もありました。なかなかに地獄が待っていそうで怖いよね、ぬるめのリボ払いかな？みたいな印象で話をしていました。

## これからの月報会

とくに辞める理由もないので、来年もゆるく続けていこうと思います。

とはいえ、今年の後半は、主催の仕事が忙しかったりしたこともありややマンネリ化してきたというのも正直なところです。なにかやり方や話題の出し方を変えたりとかはしようかなと考えています。

絶対参加した方がいいよ！とかいう感じではないのですが、それなりに楽しくやっているつもりの会なので、ご興味があればご参加ください。

https://fmrm.connpass.com/
誕生日を祝ってもらって嬉しかった話

この記事は [ゆめみ Advent Calendar 2021](https://qiita.com/advent-calendar/2021/yumemi) の 8 日目の記事です。

# はじめに

ゆめみとはパートナーとして関わっています。（業務委託契約となります）
ゆめみでは Slack にメンバーの誕生日を祝う bot がいて、誕生日になるとお知らせのメッセージがポストされ、そのメッセージに他のメンバーがスタンプをつけて祝うという仕組みがあります。

12月7日、昨日のことですが、その日は私の誕生日でした。
そのことにチームメンバーが気にかけてくれ、誕生日のお知らせが流れないことから、原因を探って、祝ってもらい嬉しかったというお話です。
この出来事の一連のフローが仕組みとして素晴らしいと感じたのと、自己組織化において必要な要素が詰まっていると思い言語化してみる記事です。

# 起きたこと

## 祝われるまでに起こったこと
1. 誕生日なのに bot からお知らせが流れてこないことにチームメンバーが気づく
2. 社内SNSに生年月日を登録でき、これが未登録だったことがわかる
3. 社内SNSの生年月日の変更権限を持つチームに変更を依頼する
4. 今日誕生日なので bot 開発担当に追加で流してもらうことを依頼する
5. 社内SNSが更新され、誕生日を祝う bot からお祝いしてもらう

## 祝われたあとに起こったこと
- 同じようなパートナーに対して生年月日を任意で登録できるように個人情報回収の提案が行われる

# 自己組織化において必要な要素

- 意思決定が個々に行われている
- 問題の特定から関連するチームの特定が行われる
- 関係者への依頼が Slack で完結している
- 問題解決後に改善案が提案される

## 意思決定が個々に行われている

このため、動きがとても速く感じました。
11:08 に気づいてもらって、12:12に対応が完了していました。

## 問題の特定から関連するチームの特定が行われる

この部分に関しては、今回気づいてくれたメンバーの強力なレファレンス能力あってのものでした。個人に依存しないように、このメンバーが気づいてくれたようなレファレンス bot ができるともっと良いでしょう。
今回のケースでは、このメンバーのレファレンス能力がないと、流れないねーで終わっていた可能性は大いにあります。
もう少し掘り下げると、関連するチームの特定が可能だったのは、適切な責務においてチーム分割が行われているのも特定を容易にするチーム設計だったのではと思いました。
今回のケースに限らず、こういうことならこのチームかなという委譲がよく発生していると感じます。

## 関係者への依頼が Slack で完結している

まず Slack のチャネル設計がチーム設計に沿っていて、 Slack 上なので当たり前ですが、チャネル間でシームレスに連絡を取り合うことができ、背景の共有や依頼がスムーズに行われました。
自己組織化の要素に Slack という特定のサービスが加わるのは違和感がありますが、現在のリモートワークを基本とする組織体制においては、 Slack でなくても良いですが、マルチチャネルのテキストコミュニケーションサービスは必須だと感じています。

## 問題解決後に改善案が提案される

このような改善案が個々の意思決定において提案されるので、チームを起点とした変化が自発的に起こり、自己組織化として機能していると感じました。


# 余談

以前、新規サービスを企画するときに「誕生日を絡めて」と言われました。

## サービスにおけるバースデイ指向

生年月日を登録するサービスは、誕生日や誕生月に絡んだ仕組みを取り入れることが広く行われています。

- 誕生日を登録するゲームは、ゲームのキャラクタがプレイヤを祝ってくれます
- お店やECサイトでは、誕生月にバースデイクーポン等を発行してくれます
- Twitter では風船が飛びます

会社もこれらサービスと同様に生年月日を扱う一つのサービスとして捉えると、これに絡んだ仕組みを取り入れると離脱率が減るという傾向があるかもしれません。

### サービスにおけるバースデイとは

サービスにおいてはそのサービスに登録した日を記念日として、バースデイ扱いにし、1周年だったりを祝うというのもあります。人によっては、誕生日を登録することに抵抗があることもあります。そのサービスと関わった期間を祝ってもらえるのは、サービスに密接したイベントとしてより思いが強くなると考えます。
STM32L010とMbedでI2Cスレーブの受信文字をシリアル出力(受信)(STM32L010F4P6)


x Mbed2リビジョン125


目的
I2Cスレーブのテスト



参考


https://os.mbed.com/users/okini3939/notebook/i2cslave_jp/





![o_con137.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/840352/ce5f4c72-196e-dd38-b3af-ecfa4ecf3d58.jpeg)





```c++


#include "mbed.h"

//GPIOの初期化
DigitalOut myled(PA_4);//LED1

//シリアルの初期化
RawSerial pc(PA_2, PA_3); //010

//I2Cの初期化
I2CSlave slave(PA_10, PA_9); //010

//メイン関数
int main()
{

    char buf[10]; //I2Cバッファー

    //I2Cスレーブのアドレスの設定
    slave.address(0x80);

    //無限ループ
    while(1) {

        //I2Cの状態の読み出し(ポーリング)
        while (slave.receive() != I2CSlave::WriteAddressed) {}


        buf[0] = 0;//バッファーのクリア

        //I2Cスレーブの受信バッファーを読み取る
        slave.read(buf, 1);

        myled = 1;//LEDの点灯 debug

        //I2Cスレーブの受信データの表示
        pc.putc(buf[0]);

        //I2Cスレーブの受信データの表示 debug
        //pc.printf("\tRead A: %x\r\n", buf[0]);
        
        myled = 0;//LEDの消灯 debug


    }//while

}//main

//容量削減
void error(const char* format, ...) {}





```
[備忘録][自分晒し] Qiitaを書く時にいつも忘れるアレコレを紹介します

（本稿は思い出したら随時追記しているので、同じ事をお悩みの方はストックしておいてもらえると、ご自身で書く時に探しやすくなると思います。）

たぶん結構な数の人が困ってるんじゃなかろうか、という話をまとめただけです。

## 絵文字
公式の案内

https://help.qiita.com/ja/articles/qiita-emoji

公式の案内にもある、利用可能な絵文字一覧

https://www.webfx.com/tools/emoji-cheat-sheet/

絵文字の使い方は分かっても、どの絵文字だっけ？というのをよく忘れます。

## 折りたたみ
いつも「Qiita 折りたたみ」で検索するので面倒くさいですよね。

https://qiita.com/matagawa/items/31e26e9cd53c3e61ae07

```
<details><summary>すごく長い文章とかプログラムとか</summary><div>

```python
print('Hello world!')
```　

</div></details>
```

これを入れると、

<details><summary>すごく長い文章とかプログラムとか</summary><div>

```python
print('Hello world!')
```

</div></details>

となります。

## note
```
::: note
warnとalertがある。:::noteの後に何も書かないとこれ。
:::
```

::: note
warnとalertがある。:::noteの後に何も書かないとこれ。
:::

色がついて見栄えがいいですね。
うまく活用できれば、白文字だらけ（拡張機能の入れ方によってはダークモードの方）の空間を読みやすく強調できると思います。

## 注釈記法
これも「Qiita 注釈」とかでググるワード。

https://blog.qiita.com/105484781374-2/

```
本文中に次のような文字列を記述することで脚注を表現できます。[^1]

[^1]: 脚注の注釈内容は、このように記述します。
```

私は最後に

```
### 注釈
```

で締めがちです。
Qiitaだと動的に目次を作ってくれるのが嬉しいですね。
こんな感じに見えます[^1]
[^1]: 【こんな感じに見えます】注釈コメントがここに出てきます。上のリンク文字をマウスオーバーすると内容が出てくるんですが、スマホとかで見てると結局なんの注釈コメントか忘れるので、ヒントになるキーワードを一番最初に入れるようにしています。

#### わかりにくい補足
あまり気にしないんですが、注釈コメントはこんな感じで書いてます。

<details><summary>以下がぞ（クリックで展開）</summary><div>

---

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/122800/758328c5-884d-98ff-d24c-cbb8fa5de8ec.png)

---

以上がぞ

</div></details>

この通り、本文中だとすぐそこにあるんですが、プレビューで見た通り、実際の見え方は異なるので注意が必要です。
なので、注釈のh3タグが一番下に来るように記事を書いているんですね。

## 小ネタ
### 見出しのデザイン
私は見出しをh2(`##`)で始めるようにしています。
h3(`###`)だと見出し下の罫線がないので、話の区切りではない印象があります。
明示的に別の内容だと強調したい時は`---`あるいは`***`で区切る事ができます。
（この例だと「がぞ」～「がぞ」の上下に入れてます。

h1(`#`)で始めると、ひとつ下の段落の話がしたい時も区切り線になるのでやむなし、という感覚です。
SEOの話をするなら、同じセクション内にh1タグが複数あるのは良くない、という事なんでしょうか。[^2]
[^2]: 【SEOにおける同一section内にある複数のh1タグ】要出典

h1から始めたにせよ、h2から始めたにせよ目次で見たときには分からないですね。

### 記事タイトルにプレフィックスをつけて探しやすくする

[ご自身のストック一覧を見てほしい](https://qiita.com/stock)んですが、記事を書く時に他の方が書いた記事を参考にする時があると思います。
が、ストックには自分用メモが残せないため、あの書き方はどこにあったっけ？と悩むことはありませんか？
この記事を書き起こしたのも、まさに↑があってしまったから書いているのですが:sweat_smile:

せめて自分が書いた記事をストックして後で読み返せるようにしておく場合は、なんでストックしたのか、タイトルのどこかに埋め込んでしまうという手もアリかもしれません。

### Qiitaのダークモード
ありますかね？
手前味噌で何とかやってますが、正直微妙。。

## その他参考
以下をストックしておくのが確実です。私もストックしてます。（そして、埋もれてしまっています :sweat_smile: ）

https://qiita.com/Qiita/items/c686397e4a0f4f11683d

## 追記中
思い出したら更新していきます。
更新したら通知を出しますので、ストックしておいてもらえると「こんなテクニックもあるんだ！」という気付きになるかと思います。

## 読了後いいね！をお願いします。
view数に対して、どれだけの方が最後まで読んでもらっているか知りたいので、善意のお力添えをいただけると嬉しいです。

### 注釈
Storybook6.4からstoriesの指定に{}が使えなくなった件

## 背景

storybookのバージョンを6.4にupdateした時に、ビルド自体は問題なかったが実際に開いて確認してみると`Couldn't find any stories in your Storybook.`のエラーが出ていたので調査しました。

実際以下のようにstoriesを設定していました。

```js:.storybook/main.js
module.exports = {
  stories: ['../{components,pages}/**/*.stories.tsx'],
  ・・・
}
```

## 結論

storybook6.4からglobの判定がmicromatchというやつからpicomatchというのに変更になり、{}による展開が不可になったようです。なのでstoriesの配列にそれぞれ分けて記載すれば動作するようになります。

```js:.storybook/main.js
module.exports = {
  stories: ['../components/**/*.stories.tsx','../pages/**/*.stories.tsx'],
  ・・・
}
```

ドキュメントもしれっと6.3⇨6.4でmicromatchからpicomatchに変更されています。

https://storybook.js.org/docs/react/configure/overview#configure-story-loading

## 参考

https://github.com/storybookjs/storybook/pull/16522

https://github.com/micromatch/picomatch#braces

https://www.gnu.org/software/bash/manual/html_node/Brace-Expansion.html
ffmpeg でUSBカメラの映像を録画しつつ ffplay でモニターする

# USBカメラのリストを出す
以下のコマンドで、デバイス名が `"USB2.0 UVC PC Camera"` であることがわかる。

```
> ffmpeg -hide_banner -list_devices true -f dshow -i nul
[dshow @ 000001c74c0f9180] DirectShow video devices (some may be both video and audio devices)
[dshow @ 000001c74c0f9180]  "USB2.0 UVC PC Camera"
[dshow @ 000001c74c0f9180]     Alternative name "@device_pnp_\\?\usb#vid_a16f&pid_0304&mi_00#7&37e7878e&2&0000#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\global"
[dshow @ 000001c74c0f9180] DirectShow audio devices
[dshow @ 000001c74c0f9180] Could not enumerate audio only devices (or none found).
nul: Immediate exit requested
```

# 出力フォーマットのリストを出す
対応した pixel_format=yuyv422、サイズが 640x480 であることがわかる。

```
>ffmpeg -hide_banner -list_options true -f dshow -i video="USB2.0 UVC PC Camera"
[dshow @ 000002615cb890c0] DirectShow video device options (from video devices)
[dshow @ 000002615cb890c0]  Pin "繧ｭ繝｣繝励メ繝｣" (alternative pin name "0")
[dshow @ 000002615cb890c0]   pixel_format=yuyv422  min s=640x480 fps=25 max s=640x480 fps=25
[dshow @ 000002615cb890c0]   pixel_format=yuyv422  min s=640x480 fps=25 max s=640x480 fps=25
[dshow @ 000002615cb890c0]   pixel_format=yuyv422  min s=160x120 fps=25 max s=160x120 fps=25
[dshow @ 000002615cb890c0]   pixel_format=yuyv422  min s=160x120 fps=25 max s=160x120 fps=25
[dshow @ 000002615cb890c0]   pixel_format=yuyv422  min s=176x144 fps=25 max s=176x144 fps=25
[dshow @ 000002615cb890c0]   pixel_format=yuyv422  min s=176x144 fps=25 max s=176x144 fps=25
[dshow @ 000002615cb890c0]   pixel_format=yuyv422  min s=320x240 fps=25 max s=320x240 fps=25
[dshow @ 000002615cb890c0]   pixel_format=yuyv422  min s=320x240 fps=25 max s=320x240 fps=25
[dshow @ 000002615cb890c0]   pixel_format=yuyv422  min s=352x288 fps=25 max s=352x288 fps=25
[dshow @ 000002615cb890c0]   pixel_format=yuyv422  min s=352x288 fps=25 max s=352x288 fps=25
[dshow @ 000002615cb890c0]   pixel_format=yuyv422  min s=640x480 fps=25 max s=640x480 fps=25
[dshow @ 000002615cb890c0]   pixel_format=yuyv422  min s=640x480 fps=25 max s=640x480 fps=25
video=USB2.0 UVC PC Camera: Immediate exit requested
```

# ffplay で表示する
表示するだけなら特に意識しなくてもいい。
出力フォーマットは、上で取得したリストの一番上のものが選ばれる？

```
ffplay -f dshow -i video="USB2.0 UVC PC Camera"
```

# ffmpeg で録画する
ffmpeg の出力先を動画ファイルにするだけ。

```
ffmpeg -f dshow -i video="USB2.0 UVC PC Camera" video.mp4
```

# ffmpeg でUSBカメラの映像を録画しつつ ffplay でモニターする
`-filter_complex` の `split` フィルターを使う。
ffmpeg から `rawvideo` フォーマットでパイプに出力し、ffplay でパイプを入力とする。
`-f rawvideo` は生データなので、ffplay には `-f rawvideo` に加えてビデオサイズ `-video_size` とフォーマット `-pixel_format` を教えないといけない。リアルタイムに表示しているだけなので `-framerate` は不要。

```
ffmpeg -hide_banner -y -f dshow -i video="USB2.0 UVC PC Camera" -filter_complex split[v1][v2] -map [v1] video.mp4 -map [v2] -f rawvideo - | ffplay -hide_banner -f rawvideo -video_size 640x480 -pixel_format yuyv422 -
```
FabGLとOrange-ESPerで5 V、3.3 V両対応VGAシステムコンソール


#はじめに
　USB-TTLやVGAシステムコンソール[^1]の多くは、信号の送受信の際の電圧が固定されています。電圧の高いものから電圧の低いものに信号が流れると、受信側の機器が壊れることがあります。シリアル端子の対応する電圧を、双方の機器で確認して、配線する必要があります。
　USB-TTTLアダプタには、ジャンパピンで3.3 Vと5Vを切り替えることができるものもありますが、安価に入手可能なVGAシステムコンソールには、電圧固定のものが多いようです。3.3 Vと5Vのどちらでも接続可能なVGAシステムコンソールがあると、接続時に、VGAシステムコンソールに接続する機器の信号の電圧のみに注意するだけになり、作業工程を減らすことが可能となります。

[^1]:  https://ja.wikipedia.org/wiki/コンソール 

#FabGL
　2019年、Fabrizio Di Vittorio氏により、ESP32用のディスプレイ制御とグラフィックのライブラリである、FabGLライブラリが公開されました[^2]。

http://www.fabglib.org

　このライブラリを用いると、ESP32で、VGAディスプレイへの出力、PS/2マウスおよびPS/2キーボードからの入力、音声出力が可能になります。ESP32にVGA、PS/2ポートを接続したボードが作者により公開されています。


https://www.tindie.com/products/fabgl/fabgl-terminal/


https://www.tindie.com/products/fabgl/fabgl-esp32-33v-board-16mb-flash-4-mb-psram/

これらのボードを購入して作者を支援するのが良いのですが、残念ながら、このボードは3.3 Vでの信号の入出力のみを行うので、本目的には、適合していません。

[^2]: https://github.com/fdivitto/FabGL

#Orange-ESPer
　日本で購入可能なFabGLに対応したボードに、Orange-ESPerがあります[^3]。

https://store.shopping.yahoo.co.jp/orangepicoshop/pico-k-030.html#


　購入時のこのボードでは、信号の送受信は3.3 Vでのみ行えますが、部品を追加することにより、5 Vでの信号の送受信も可能となります。
　追加する部品は、2個の2N7000、2個の10 kΩ、2個の2x1のピンヘッダ、2個の2×1のジャンパピン、1個の6x1のピンヘッダです。これらの部品を取り付ける箇所は基板上に用意されています。


[^3]: http://www.picosoft.co.jp/ESP32/index.html



#スケッチ書き込みの際の注意
　今回の用途には、「AnsiTerminal.ino」をArduinoIDEを使って書き込む必要があります。その際に注意が必要です。
　5 V、3.3 V両対応Orange-ESPerにスケッチを書き込もうとすると、エラーが出て書き込めません。2個のジャンパピンを外すと、問題なくスケッチが書き込めますが、書き込みのたびに外すのは不便です。
　IOポートのTXDをGNDに、あるいはUART1のTXDをGNDにつなぐと、問題なく書き込むことができます。写真の例では、UART1のTXDとGNDをつないでいます。

![IMG_20211208_2246042.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/693019/8ee99ccf-8e12-ef72-7727-cf11adcc4d53.jpeg)

#TXとRXへの接続
　5 Vを使う時はUART1のTXとRXを、3.3 Vを使う時はIOのTXとRXを使用して、他の機器と接続します。
DMSを使ったAurora MysqlからApache Kafka(MSK)へのフルロードを高速化する

# DMSのフルロードを高速化する

DMSを使ったAurora MysqlからApache Kafka(MSK)への移行タスクの速度が遅く、対策した結果の備忘録です

## Kafkaへの移行タスクはデータ転送が遅く時間がかかる

DB、Kafkaともリソースに余裕があっても 19.4 レコード/秒 くらいの速度感です
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1056504/4fb5fb60-2f5b-e4e4-9df1-ac7f4c58e6bb.png)

## 移行タスクを並列起動して対応

Aurora Mysqlソースはparallel-loadオプションが利用できないため、移行タスク作成時に指定できるテーブルマッピングのソースフィルタで対象レコードを分割し、移行タスク自体を並列起動します
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1056504/81bc299b-2441-b584-93ca-0f6a72af7934.png)

4タスク起動してみました
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1056504/f632819b-79bd-4537-83ad-63b5534ba0d9.png)

タスク単体での速度は変わりませんが、並列で動作しているので全体での処理件数は増加しています
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1056504/cd5d5963-3963-3bd3-a5a5-e65d96b71018.png)

## デメリット

- DMS以外がボトルネックの場合は速度が変わりません
- 当然ですが、処理順序はバラバラになります
- 並列接続しているのでソースDBの負荷は増えます

# 採用PR
弊社で一緒に働く仲間を募集しています。
全てのオタクを幸せにしたい方、是非ご覧ください！

https://hrmos.co/pages/vivion/jobs/0000191
平均489rpsが来るEEW APIについて

これは[地震情報アプリ界隈 Advent Calendar 2021](https://adventar.org/calendars/6729)の9日目の記事です。

緊急地震速報をJSON形式で提供するAPIついてと今後についてほんの少し（既知）書かせていただきます。

## 概要

[svir.jp](https://svir.jp)（現在API URLは非公開）にて、緊急地震速報を2017年12月11日から提供しています。

提供開始数年は、アクセス量が低調（50rps未満）でしたが、2020年あたりからアクセス量が急増しその対策や利用者への依頼などを行いました。

これはその雑記となります。

また、このAPIは閉鎖予定（2022年08月01日）で有料サービス（開始日未定）に移行する計画を立てています。

## 大量のリクエスト

件のAPIがあるサーバーのリクエスト・トラフィック量の推移を下記に添付します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311703/e88f302a-45cf-3f9b-fcc4-eac27c04e7bf.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311703/2af92841-d88c-cfed-e6bd-0844273886c7.png)


これを、コア2・メモリ2GBのVPS 1台で捌いています。

CPU使用率は60%以下とrpsに対しては低調です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311703/3cda4efa-6cee-3e4b-15ab-51906df3e34b.png)

処理する内容によりけりですが、案外いけます。

### 対策

増えるリクエストとトラフィックに対応するため、以下のようなことを実施しました。

* マルチコアでAPIサーバーを処理する
* 利用者にgz処理の追加のお願い
* Nginxの設定見直し
* KTLSを有効化する

#### マルチスレッドでAPIサーバーを処理する

マルチスレッドでAPIを処理するようする以前はPHP-fpmで逐一処理していました。
こちらもリクエストをマルチで捌いてくれはするのですが、メモリやCPUリソースが余計に消費しており、増大するリクエストには対応できなくなりつつありました。

PHPからNode.jsへの乗り換えを行い、マルチスレッドで捌けるHTTP-Serverを作成しました、思ったより簡単でしたね。
レスポンスはユーザーによって変わらないのでデータを整形したらメモリに保存し、要求があったら返答しています。

実施した当時はCPU使用率が少し下がり、メモリ使用率がかなり改善した記憶があります（かなり前で資料が紛失しています・・・）。

#### 利用者にgz処理の追加のお願い

CPUやメモリなどのリソース問題の他に、通信帯域を消費し通信ができなくなることがあります。
大きな地震で、緊急地震速報（警報）が発表されるとそれだけレスポンスサイズが大きくなります（圧縮なしで2倍以上）。

HTTPリクエストの圧縮通信を行わない実装（言語標準ライブラリを使用しているなど）している利用者へ、圧縮通信実装のお願いと更新を促しレスポンスサイズが大きくなっても急激に通信帯域を消費することを回避しました。

#### Nginxの設定見直し

Nginxの設定に誤りがあると、パフォーマンスがかなり落ちCPUリソースを余計に消費します。

worker_processesと、events内のworker_connectionsの設定を見直したところ、パフォーマンスが大幅に改善しました。

設定は以下のようにしました。

```nginx
worker_processes auto;
worker_rlimit_nofile 85000;

events {
    worker_connections 4096;
    multi_accept on;
    use epoll;
}
```

worker_rlimit_nofile はディスクリプリンタの値の設定です。

ディスクリプタを変更するときはOS全体で扱える数を超えないようにする必要があります。確認方法は以下になります。

```shell
$ cat /proc/sys/fs/file-max
182027
```

ここでは半分以下の値を設定しています。


worker_connectionsは、Nginxで同時で処理できるコネクション数を指定します。
指定できる値はディスクリプタの値以上を設定することが出来ないので、変更する必要があります。
制限に余裕をもって、worker_rlimit_nofileの約20分の一の値にしています。

##### 2021/12/09 15:00 追記
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311703/f30b4643-4ac0-0600-f6a8-8ab4d6f585d5.png)

どうやら4096でも同時接続上限に達しているようなのでその倍、worker_connectionsを8192で様子を見ています。


#### KTLSを有効化する

OpenSSL 3.0.0、Nginx 1.21.4 から使える機能として、TLSの処理をKernelにほとんど一任しメモリやCPUリソースの移動を抑え、パフォーマンスを向上させるものです。

CPU使用率が数パーセント改善しました。

詳細は[Improving NGINX Performance with Kernel TLS and SSL_sendfile()](https://www.nginx.com/blog/improving-nginx-performance-with-kernel-tls/)を参照してください。

## 今後について
このAPIは、初めに書いた通り2022年08月01日に閉鎖となるものです。

有償API化については、決定次第私の[Twitter @soshi1822](https://twitter.com/soshi1822)などでお知らせしますのでよろしくお願いします。

### 小話

緊急地震速報のAPI有償化をするにあたり、気象業務支援センターから直接取得する方式を採用します。
とある人にNTT IP-VPN Arcstar Universal Oneを契約してもらい、「JMAソケット付きTCP/IP」を引っ張る予定です。

初期投資もそれなりにかかるので、少しでも応援してくれるっていう人はぜひ使ってください（月1650円）。

## 終わりに

APIの提供を通じて、大量に来るリクエストの扱い方やその対策など普段ではできない体験ができました。
今でも、ここまでリクエスト量が来るとは思わず日々驚愕しています。

以上、ありがとうございました。
デコレータを使用してみる mshmura

### 目的
- デコレータの使用に慣れること

### 内容
関数実行前にメンバーかどうかを判断し、メッセージを切り替える。


```login_decorator.py
member_list = ["高橋","田中","井上"]

def check_decorator(func):
    def check_member(name):
        print(f"==={name}さんの会員チェック開始===")
        if name in member_list:
            func(name)
        else:
            print(f"{name}さん、会員登録してください")
        print(f"==={name}さんの会員チェック終了===")
    return check_member
    
@check_decorator
def greeting(name):
    print(f"{name}さん、ようこそ")

# 関数実行
greeting("田中")
greeting("佐々木")

```

実行結果

```
===田中さんの会員チェック開始===
田中さん、ようこそ
===田中さんの会員チェック終了===  
===佐々木さんの会員チェック開始===
佐々木さん、会員登録してください  
===佐々木さんの会員チェック終了===

```
Arduinoの勉強　第9弾：LED (１) - 点灯・制御

# #LEDの点灯・制御
##はじめに
ハードウェアの勉強のためにArduinoを復習も兼ねて参考教材に沿って，勉強する．細かな部分の理解までして，自在に扱えるようになることが目的である．その第9弾として，「LEDの点灯・制御」を扱う．

## LEDの種類
LEDはその形状や発色，発光などの要素により多くの種類がある．ここでは，一部を以下に示す．
![slide1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/951300/2935d2c4-b05d-b832-9d4c-320c31e8822c.png)

## LEDの選択
LEDを選択するにあたり，いくつかの要素がある．ここで，光度と電気的特性について簡単に示す．
![slide2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/951300/930f8b67-0ef0-15ce-16a3-15fa115d3bed.png)
おまけとして，光度の例を以下に示しておく．

|例|光度|
|:-:|:-:|
|太陽|$3.150\times10^{27} cd$|
|月|$6.400\times10^{15} cd$|
|蛍光灯ランプ（40W）|$3.70\times10^{2} cd$|
|白熱電球（100W）|$1.20\times10^{2} cd$|
|ろうそく|$9.0\times10^{-1} cd$|

## LEDの動作原理
![video1.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/951300/ce6abf47-eae6-b7f9-8516-3b7ab248d634.gif)
![video2.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/951300/da220020-87f0-e2cb-f5ae-63256f4cf28e.gif)
![video3.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/951300/f39b4a11-8093-c498-3290-51d5752da463.gif)

##### 注意
逆に電源を接続してもLED自体は壊れはしないので，つなぎ直せば，点灯する．
**ただし，逆に接続した際に大きな電圧をかけるとLEDが壊れる（絶縁破壊）**
どの程度の電圧に耐えられるかはデータシートなどに「**逆耐圧**」として記載されている．

## LEDの回路と抵抗の求め方
以下にLEDを点灯させるための回路を示す．ただし，ここでの回路はデジタル出力をHighにした時に点灯するようになっている．もちろん，LEDのアノード（+側）を5Vに接続し，カソード（-側）をデジタル入出力ピンに接続することで，デジタル出力をLowにして点灯することも可能である．（カソード側での制御）
<img width="300" alt="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/951300/df826694-4da9-040f-78f7-eac4d5d3c17d.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/951300/df826694-4da9-040f-78f7-eac4d5d3c17d.png">

以下では，LEDを点灯させるために必要な抵抗の値を求める方法を見ていく．
### LED 1つ（直列）
![slide4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/951300/ab287700-e74b-1403-1f2f-c0137c63ecf4.png)

### LED 2つ（直列）
![slide5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/951300/1aed1ed3-595d-6219-9ec9-3114ba2ae90e.png)

### LED 2つ（並列）
![slide6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/951300/23cf897f-89c7-1f85-b1da-7ecff141b2b4.png)

LEDを複数接続するにあたり，電源供給のために**トランジスタを利用するなどの工夫が必要**となる．

## 感想
ここまでLEDについて勉強したのは初めてである．LEDくらいなら全て知っているつもりだったが，そうではなかったようだ．そもそも光る原理を厳密に説明することもできなかった．正孔と電子が再結合し，そのときのエネルギーが光として放出する．これを知ることで，なぜ逆接続して電気が流れないのかも非常によく理解できた．また，逆接続により，必ずしも絶縁機能が働くとは限らず，大きな電圧をかけてしまうことで壊れてしまうかもしれないということも知れてよかった．
個人的に，一番収穫だと思ったのは，なぜトランジスタを利用する必要があるのかということを知れたことである．

## 参考文献
- 電子部品ごとの制御を学べる！Arduino電子工作実践講座 改訂第2版 福田和宏 著 ソーテック社
Vuexのインストール

## 内容
Vue3でVuexを導入する手順。
Viteで作成しているアプリケーションに、npmで途中から導入するときの手順。
[「Vite」を使用してVueプロジェクトを立ち上げる](https://qiita.com/tarian/items/f7b444aebb97a41a8478)

## 目次
- [Vuexのインストール](#Vuexのインストール)
- [store.jsにスクリプトを記述する](#store.jsにスクリプトを記述する)
- [storeをアプリケーションに組み込む](#storeをアプリケーションに組み込む)
- [App.vueを修正（コンポーネントを読み込む）](#App.vueを修正（コンポーネントを読み込む）)
- [storeの値を取得して画面に表示する](#storeの値を取得して画面に表示する)
- [画面確認](#画面確認)


## Vuexのインストール

Vue3に対応するVuexは、Ver.4以降。

```bash
npm install vuex@next
```

## store.jsにスクリプトを記述する

プロジェクト直下にstore.jsを作成

```js:/store.js
import { createStore } from 'vuex' // VuexのパッケージからcreateStore という関数をインポート

export const store = createStore({ // createStoreの引数にストアに関する情報をまとめたオブジェクトを指定
  state() {  // stateは、ストアに保管する値を用意しておくもの。コンポーネントのdataに相当するようなイメージ
    return { // このオブジェクトの中に、storeで利用する値をまとめておく
      message: 'This is store data.'
    }
  }
})
```

## storeをアプリケーションに組み込む

```js:main.js
import { createApp } from 'vue'
import App from './App.vue'
import './index.css'
import { store } from './store.js' // storeをインポート

createApp(App).use(store).mount('#app') // アプリケーションに組み込み
```

## App.vueを修正（コンポーネントを読み込む）

```vue:App.vue
<template>
  <div id="app">
    <HelloWorld />
  </div>
</template>

<script>
import HelloWorld from './components/HelloWorld.vue'

export default {
  name: 'App',
  components: {
    HelloWorld
  }
}
</script>
```

## storeの値を取得して画面に表示する

```vue:HelloWorld.vue
<template>
  <div class="alert alert-primary">
    <h1>{{ data.title }}</h1>
    <!-- $storeはstoreに保存している値のオブジェクト。$store.state.値 でアクセスできる -->
    <p class="mt-3 h5">{{ $store.state.message }}</p>
  </div>
</template>

<script>
import { ref, reactive } from 'vue'

export default {
  setup(props) {
    const data = reactive({
      title: 'Vuex',
    })
    return {
      data
    }
  }
}
</script>
```

## 画面確認

```bash
npm run dev # 開発中ですでにサーバーが立ち上がっている場合は、⌃cで一度停止して再立ち上げする
```
Firebase Authentication のログインプロバイダが設定できない時の対処法

# 対象のエラー
原因不明ですが，Firebase Authを使って `メール/パスワード`による認証を有効にしようとしたところ， `「メール/パスワードの変更中にエラーが発生しました」` といったエラーが発生しました．
![スクリーンショット 2021-12-08 22.41.42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/412378/301bf1a4-503a-801e-0c40-4b9955823698.png)


# 解決策
色々調査をしたところ，どうやらchromeをシークレットモードで起動すると良いとのこと．
再びFirebaseのコンソール画面から同様の操作を行うと，無事エラーが発生することなく終了．
![スクリーンショット 2021-12-08 22.41.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/412378/8d2e40b3-18cb-09d8-b848-50e449ee7f0a.png)

一体なんだったんだ．．．

# 結言
振り返って考えると，chromeの拡張機能が悪さをしていたのかもと．．．
変な拡張機能は入れないのが吉ですね．
エンジニアに転職して1週間

こんにちはnishioです(*^^*)

12月からエンジニアとしてのスタートを切り、1週間が経ちました。毎日忙しくなってきて、充実した日々を過ごしております。
厳しいことを言われたこともありましたが、そこには立派なエンジニアに育てたい上司の思いがあるのだと思い努力している最中です。

#1週間やったこと
* カレンダーアプリ作成
    * フローチャート図を作成
    * 作成したフローチャートをエクセルで清書
    * 清書したフローチャートをもとにコーディング 
 
* GitHub
    * ブランチ作成
    * コミット
    * プルリクエスト作成
    * マージ

* スッキリわかるJavaの入門の学習
    * 変数宣言および代入
    * 配列の宣言
    * 演算子
    * オペランド
    * ScannerクラスおよびRandomクラス
    * if文
    * switch文
    * for文
    * メソッドの定義
    * オーバーロード
    * 仮引数、実引数とは
    * 戻り値
    * クラスの分割
    * パッケージ
    * パッケージを含むクラスの実行方法

# 1週間たった感想
テックキャンプに通ってた時期は、何か見たことがあるなぐらいの理解度で済んだものの、未経験で無くなってからは空でスラスラといえるぐらいまで覚える必要になってきて負担を感じました。
さらにはクラスとメソッドの違いを知る、スペルや読み方は正しく、言葉遣いを正確にする、インデントを揃えて綺麗なコードにする等この1週間で思い知らされました。一人前のエンジニアにはまだほど遠いですが一歩ずつ歩んでいき、どんどん吸収していきたいです(^▽^)/