OmniAICreator/Qiita-1.07M huggingface dataset:
Regional Scrum Gathering Tokyo 2021 Day 1 「A ScrumMaster Way - #ScrumMasterWay の歩き方」  

2021/01/06に開催されたRegional Scrum Gathering Tokyo 2021での発表です。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14636/a-scrummaster-way-scrummasterway
 
# チーム参加してきました
 
[aslead Agile](https://aslead.nri.co.jp/solution/aslead_agile.html) のチーム「[オキザリス](https://speakerdeck.com/viva_tweet_x/huesudeyong-qi-wode-taxin-gui-timugashi-yan-wozao-rifan-sitejin-nizhi-rumadefalsewu-yu?slide=3)」にて参加してきました。
チーム7人で参加して、その場で実況しつつ、記事も作っています。

## ScrumMasterWayとは？

3段階に分類される。

- レベル１「私のチーム」：チームレベルでファシリテーション、コーチを行う。
- レベル２「人間関係」：チームを超えて、高い視点で見る。POへのアドバイスや他チーム同士の会話を促すなど。システム的な視点
- レベル３「システム全体」：包括的な、いまいる世界を俯瞰する世界。その中で、アジャイルの原則に基づいて組織全体のレベルを引き上げる。

## 私のScrumMasterWay

ケーススタディ紹介。

### レベル１でやったこと
本を読む、組織に導入する（苦労した）、自分のチームでとにかくやっている。

まずは自分がSMとしてふるまってみる。しかしそれで精いっぱい。正解を求めながらやっていた。原則が身についていないため、問題がなぜ起こるのか？頭を悩ませながら取り組んでいた。もともと開発メンバーだったため、PO等は開発チームに邪魔をしてくる存在、のように捉えていた部分もあり反省している。

### レベル２でやったこと
スケーリング（LeSS導入）、PO・ステークホルダー支援、組織内の他チーム支援、組織外のチーム支援（副業）。

原則に対して理解が深まってきた。個別の問題がつながりシステムとして見れるようになった。守破離の「破」の段階。

### レベル３(今ここ)

「トップをなくす」組織変更から1年…
チームによって自己管理レベルがばらばら。チームをまたいだ情報共有や問題解決が機能していなかった。
そこで、まずS@Sを学んでEATやってみたが不発。
エスカレーション体制がうまく作れず、問題を調査しても「ありません」の回答のみだったが、メンバーの声を1on1など通して聞き問題を熟考。
ふりかえりの中で「新体制は顧客価値最大化につながっているのか？」という話題が出た。そこをキーに今は活動している。

## 道は続く

全チームが顧客価値最大化に向けて、主体的に取り組む状態を目指している。
また、プロダクト横断の戦略もレベルアップさせる。
スクラムマスターのコミュニティも大事にしたい。

# 感想

スクラムマスターとしての歩みの、整然かつ赤裸々なトークでした。スクラム初心者でも、（もちろん地道な積み重ねは欠かせませんが）このように頑張れば道が開けそう！という希望を見せてもらえる内容でした。
RSGT2021 ワークショップ参加レポート：Bilingual cross-cultural discussion：How to accelerate the adoption of agile and scrum in Japan? （Day1 13:00～14:40）

# はじめに
このページは、RSGT2021で参加したワークショップのレポートを書いたものです
https://2021.scrumgatheringtokyo.org/


# このワークショップの概要
【タイトル】
Bilingual cross-cultural discussion 日本人と外国人のディスカッション： How to accelerate the adoption of agile and scrum in Japan? 日本でのアジャイルとスクラムの導入をどう加速すれば良いか？
Day1 13:00～14:40

【Confgineのセッションページ】
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14867/bilingual-cross-cultural-discussion-how-to-accelerate-the-adoption-of-agile-and-scrum-in-japan

# 感想などのピックアップ
### 【感想】
 - 参加者がみな、すっとmiroに適用してる！すでに慣れてる！
 - 日本特有と思ってても、意外と外国でも同じシチュエーションがあるみたい
 - 日本だからと悲観的になる必要はないのかもしれない

# やったこと

参加者約２５名
外国人の人も5名程度？

２グループに分かれ、テーマに沿ってディスカッションして、共有をする
最初２回は日本人と外国人
３回目は混合
でディスカッションした


### 1.日本におけるアジャイル・スクラム開発の導入に際し、最も大変だったことは何か
・参加者みんなでmiroに書く
・日本っぽいもの、をフォーカスさせていく
・ラベル付け


### 2.日本特有の難しさ
このあたりに集約されそう
・学校教育
・我慢する美学
・プロフェッショナリズム
・コードを書ける人が少ない。下請け丸投げ問題

プロダクトオーナーからの要求をそのまま受け取る問題
Why？
・これまでのやりとりの歴史
・消極的

これが、マネジメントスタイルと合致してしまうと、
「いいからやれ！」的なスタンスになってしまう…

＜日本以外からの参加者＞
新人を信用しない、ってのは日本だけの話ではない。
→へ～、そうなんだ！


### 3.日本において、どうすればいい？
（我々のディスカッションのサマリ）
・マネジメント層が変わるべき！
→となると、どうやってマネジャのマインドセットを変えるのか？という問題になる
　小さな成功例を示す。（これが最も説得力がある！？）
　じゃあ、成功をどのように定義するか？
　　→数字で示せる、計測可能な指標を作ることが重要
　　 かつ、マネジメントが興味を示す指標であることも大切！
※例えば、日本のマネジメント層は、「バグチケットが減った」という数字に興味があるのか？もしかすると、バグチケットが減ったことで起こる何かの変化の方が興味があるのでは？そういうことまで考えたほうがよさそう

・マネジャがほかの国などに１年程度行く。体験が一番効果がある！

（もう一方のチームのサマリ）
スイスの保険会社の方の事例。伝統的な開発スタイルである。
　・スクラムの勉強、社内コミュニティとか作った
　・カンバン作った
　どういう地道な活動をしていた
　→おぉ！このあたりは一緒だ！

国の特徴なの？
人の特徴なの？
会社の文化なの？


～おわり～
macでのアプリインストール時に「ほかのインストールが完了するまでお待ちください...」と表示されて処理が進まない

# 環境
macOS Big Sur
ver. 11.0.1 

# 症状
アプリをインストールしようとした際に、以下のように「ほかのインストールが完了するまでお待ちください...」と表示されて処理が進まない。困った😅
いつまでたっても処理は進まず、強制終了を試してみても解決できず。。。😭

![インストール (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/612915/1a1fa75e-b7c9-aaaa-d634-e7752ad5ce26.png)

# 解決策
ターミナルで以下のコマンドを実行します。

``` 
sudo killall -1 installd
```

実行中のインストーラも終了されますが、再度インストーラを実行すると正常に処理が進むようになります❗️（＾Ｏ＾☆♪
vs codeのコードの折りたたみと展開


- `cmd + (k 0)` 全て折りたたむ　→数字を変えると深さを変えれる
- `cmd + (k j)` 全て展開
- `cmd + (k [)` 今いるブロックを折りたたむ
- `cmd + (k ])` 今いるブロックを開く
Gradle - Cannot Find POM Files when Building

When I upgraded Gradle from 4.3 to 6.7.1, it stopped download libraries without POM files during building.


From Gradle [User Guide](https://docs.gradle.org/current/userguide/upgrading_version_5.html#maven_or_ivy_repositories_are_no_longer_queried_for_artifacts_without_metadata_by_default) Wrote.

```
Maven or Ivy repositories are no longer queried for artifacts without metadata by default
If Gradle fails to locate the metadata file (.pom or ivy.xml) of a module in a repository defined in the repositories { } section, it now assumes that the module does not exist in that repository.

For dynamic versions, the maven-metadata.xml for the corresponding module needs to be present in a Maven repository.

Previously, Gradle would also look for a default artifact (.jar). This behavior often caused a large number of unnecessary requests when using multiple repositories that slowed builds down.
```

We need to add the below to solve.

```
repositories {
    maven {
        url "http://repo.mycompany.com/repo"
        metadataSources {
            mavenPom()
            artifact()
        }
    }
}
```


https://discuss.gradle.org/t/how-to-fetch-maven-artifact-without-pom-file-in-gradle-6-0/33836/2
https://docs.gradle.org/current/userguide/upgrading_version_5.html#maven_or_ivy_repositories_are_no_longer_queried_for_artifacts_without_metadata_by_default
https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:supported_metadata_sources
QuTiPでブロッホ球を描くと歪む

# 内容
* 単なる作業メモです
* QuTiPでブロッホ球を書いたときに歪んでレンダリングされたので、それの対応をまとめます。


また、他の量子コンピュータ関係の他の記事は、下記で紹介しています。

https://qiita.com/shnchr/items/41fa7fd1284d74007a7c

# 問題
* QuTiPでブロッホ球をレンダリングするとアスペクト比が変で歪む

```python
from qutip import Bloch
b = Bloch()
b.add_vectors([0,0,1])
b.show()
```
<img width=500 src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/183826/8094201b-b01c-a876-35a7-c89e7cb04c7a.png">

# 解決策
* **matplotlib 3.3.0の仕様変更による影響の様で、matplotlibのダウングレードで治る。** [^1]

> This seems new to Matplotlib 3.3.0. Probably due to the following change:
>   Axes3D no longer distorts the 3D plot to match the 2D aspect ratio

* 手元の環境では、**3.2.0**にダウングレートしたら解消した。

```bash
$ conda install matplotlib=3.2.0
```

<img width=500 src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/183826/703ca34a-0b0b-be54-06ba-fc07ed3b5bfe.png">

やはり、ブロッホ球は丸いほうが落ち着く。以上。

[^1]: [Bloch sphere distortion on Jupyter Lab #1329](https://github.com/qutip/qutip/issues/1329)
Regional Scrum Gathering Tokyo 2021 Day 1 「スクラムをスケールするとはどういうことか？」

2021/01/06に開催されたRegional Scrum Gathering Tokyo 2021での発表です。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14622

# チーム参加してきました

[aslead Agile](https://aslead.nri.co.jp/solution/aslead_agile.html) のチーム「[オキザリス](https://speakerdeck.com/viva_tweet_x/huesudeyong-qi-wode-taxin-gui-timugashi-yan-wozao-rifan-sitejin-nizhi-rumadefalsewu-yu?slide=3)」にて参加してきました。
チーム7人で参加して、その場で実況しつつ、記事も作っています。

# スケールの話

スケール＝大きさの尺度
スケールというとすぐ大規模に結びつけがち。
大きいことってどういうこと？

# スケーリングの手法

SAFe, Scrum@Scaleなどが多数。

- SAFe
- LeSS Huge
- Scrum@Scale
- Spotify Model

大規模でスクラムやるって考えると、上層部がこれをもってくる

- Nexus
シンプル。スクラムに近い。

**じゃあ、どこから始めたらいいの？**

# なぜスケーリングする必要があるの？

数を増やすことで目的の達成が容易になるのか？
数を増やすことで、経済的に合理的になる場合にのみスケーリングする

**ここまでのアジャイルのFWはは開発側・提供側の絵しかない**
スケールしたいものはなに？

- 人
- プロダクト
- 顧客満足
- 金
- 世界平和

結局人を増やすけど、プロダクトインクリメントは増えない。
次にプロダクトインク路面とを増やすと顧客もお金も離れていく。

結局ここまでの例は**膨張しているだけ**

実はすでにアジャイルマニフェストの原則に書いてある
**シンプルさ**
「最大限やらずに済ます技術」は必須。

ソフトウェアエンジニアが目的を理解せずに実装しようとする
→コピペプログラミングする。（これっていいの？）
**じゃあ組織もコピペする？**

自然界でのコピペ→ビスマスの結晶、ロマネスコ（ブロッコリー）

じゃあ組織はどうやってスケールする？
Alejandro Aravenaのハーフハウス

Before: 

![before.png](https://e00-elmundo.uecdn.es/assets/multimedia/imagenes/2016/01/13/14526965990528.jpg)

After:

![after.png](https://s03.s3c.es/imag/_v0/665x400/2/e/6/Quinta_Monroy_Actualidad.jpg)

## 差はどこから来るの？

- クネビンフレームワーク
- スクラムの主な適用領域
	- 複雑な問題から煩雑な問題により分ける

**カスタマーオブセッション**

顧客に価値を提供するならば、会社のカタチを変えることもいとわない

# 小さなチーム

- 意思決定の遅延を最小にする
- 顧客価値にこだわる（手段を選ばない）
- チーム間の相互学習を促す（地検の素早い共有によって、遅延をさらに減らす
	- あのチームでできることを、このチームでもできるようにする

# 事例は？

- アジャイル・コミュニティ
- オープンソース・コミュニティ

知識をすぐに共有する。

# 依存関係

- 同期的に依存しないようにする
- 非同期に助けを求められるようにする

# スケーリングを考える前に

あなたの組織に、よいスクラムチームが複数いないのであれば、まず良いスクラムチームを育てるところから始めましょう。

# その次に、組織の学習を支援しましょう

- うまくいっているやり方を盗みやすくする
- 良いスクラムチームたちが、チームの学びを組織に伝えやすい環境を用意しましょうしましょう
- 学習構造に基づいて、学習のネットワーク構造が成長を助けましょう
- 時間はかかります、粘り強く

# まとめ

- スクラムのスケーリングは、
  - まず組織内の学習の相互移転を促すところから
  - 個々のチームは可能な限り小さいままを保つ（判断のレイテンシを小さく）
- スケールフリーネットワークは生成するもの。生成を支援はできる。
- どのスケーリングフレームワークを使うか考えるのは、それからで遅くない。
- 顧客満足・金・世界平和をスケールしたい

# QA
- スケールしろという圧力がある
    - やりたいことが多くてチームが増えるならばいいと思う
    - １つのプロダクトに対してチームが増えるというのは要注意。顧客価値が見えていない可能性がある。


# 感想

- 意思決定の遅延を最小にすることで、スピーディに業務を行うことができ、その結果より多くの価値を生む出すことができる。これはビジネスの本質だと思った。
- 組織の学習移転の仕組みをいかに作るか。これが肝だけど、なかなか理解・な得してもらうのも難しい。チームオキザリスが、その模範になっていきたいと思う
- たしかに意思決定は遅延が大きくなりがち
コロナ禍に某プログラミングスクールに通って人生学んだ話

# この記事について
題の通りコロナ禍にプログラミングスクールに通って転職までした私が、思ったこと、学んだことを中心に綴っていく記事になります。

この記事を見て、**「プログラミングスクールに通うべきか」**を考えていただければと思います。

# 私について
・20代前半
・前職は接客業
・学歴は誇れるものではない
・元々C言語は少し触っていた
・何なら独学でHTML&CSSを使いLPを作ったこともある

# なんでプログラミングスクールに通ったの？

以下の理由より通うことを決めました。

①**「効率よく学習をしたいから」**
②**「スクールのコネを使って良いところに行きたいから」**

結果これらの希望は叶ったのかというと、**叶っていません。**

以下よりこれらについて掘り下げていこうと思います。

## ①「効率よく学習をしたいから」

これは、

**・独自のカリキュラムで分かりやすい。**

**・メンターにすぐ質問できる。**

このようなことを期待していました。
　　
　　

### 独自のカリキュラムで分かりやすい。

カリキュラムが分かりやすいなんてことは一切なく、いわゆる普通のHTML&CSS→Ruby流れで組まれていました。（そりゃそうよね）

何なら更新が継続的に行われておらずスクールに問い合わせて「あ、すみません😅　更新されてないですねこれ😅　ちょっと自分で調べてやってみてください😂」なんてこともあって、（独自のカリキュラムってこうゆうことなんダァ。新鮮だなぁ。）と思いました。

### メンターにすぐ質問できる

オンラインということもあってか、すぐ質問できました。

いや、**質問はできました。**

そこまでは良かったのですが、その後の回答が、的確にできる方があまりおらず。

質問をしても

👨🏻‍💻「自分ではわからないので他のメンターに問い合わせるのでお待ちください・・・」

👨🏻‍💻「本当に調べました？」

と高圧的に来る方も居てメンタル的に辛いなぁとなる部分も多かったです。

もちろん、エンジニア以前に人として「**質問をする際は自分で調べて行動を起こして、わからなければ質問する**」というのが大事だと思うのですが、これもまた人として（高圧的に接するのはどうなの・・・😢）と思っていました。


## ②「スクールのコネを使って良いところに行きたいから」

私は、自分のやりたいことがwebエンジニア（フロントエンド）でしか果たせないこともあり、Webエンジニアを目指していました。

しかし、転職担当の方との一番最初の面談で言われたセリフはこれ。
　　
　　
👨🏻‍💻**「Web系は難しいので、まずはSESに入り2〜3年経験を積んだ後にWeb系に行くようにしましょう！」**
　　
👨🏻‍💻「いや、コロナ禍ということもあり、フリーランスの方も市場に多い状態です。なので(ry」

🐶「ええ・・・」

しかし私は諦めきれず、担当の方と何度も面談し、志望理由を何度も説明しました。
だが、結局担当の方の反応は変わらず。

　　
最終的には、某論破の方ように

👨🏻‍💻「それって、SESでもできますよね？」

と言われました・・・
　　

ご想像の通り、紹介され続けたのは、希望とは真反対のC言語やJavaを使うような企業ばかり。

私が作成したポートフォリオ（以下、PF）のレベルが低かったのもあるかと思いますが、これはかなり希望と違い、学習している時以上に辛かったです。


# 良いところなかったの？


このままでは「おいおい、ただの愚痴やんけ」と思われてしまうような記事ですね。

もちろん良いところもありました。

**①「スケジュール管理をしてくれる」**

**②「人脈が広がる」**

## ①「スケジュール管理をしてくれる」

👨🏻‍💻「〇〇日までにこれをしましょう！」

等のスケジュール管理は、独学では管理しづらい人には向いているのかなと思いました。

## ②「人脈が広がる」

「4月生」のように月ごとの区切りがあり80人ほどいるのですが、その中で数人と深い関係になり、人脈が広がったのかなと思います。


# 結局

自分の考えていたメリットが全て潰れてしまい、私にとってはあまり意味のない投資だったと思います。

いや、20代前半で**「今後は、このようなスクールに通わずに独学でいろいろ学ぼう！」**と学べたの良い経験だったのかもしれないですね。
[GitHub Desktop] 過去の履歴に戻す方法 (スクショ付)

今回laravelでmodelやマイグレーションをした際にとんでもないミスをしたのでGitHub Desktop を使って過去の履歴に戻す方法を備忘録として投稿します。

###はじめに
全てPushした状態にした状態で始めて下さい

###投稿者の環境
1. MacBook Pro (13-inch, 2019, Two Thunderbolt 3 ports)
2. macOS Big Sur バージョン11.0.1


### ステップ 1
1. 戻したいコミットにカーソルを合わせて右クリックする
2. Copy SHAをクリックするとコミット履歴番号を取得できます
![“スクリーンショット” 2021-01-05 20.39.11.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/698439/d10330b8-423e-e6d4-40e9-195062b894aa.jpeg)

### ステップ 2
Repository⇨Open in Terminalでターミナルを開く
![“スクリーンショット” 2021-01-05 20.43.08.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/698439/148b0b27-032a-82da-e245-d1e86d5f1cdf.jpeg)

### ステップ 3
するとターミナルが開くので、そこに下記のコマンドを入力します。
xxxxxの部分は先ほどコピーしたSHAをペーストしてください。
実行をするとそのコミットに戻ることができます

```
ターミナルにて
git reset --hard xxxxx(xxxxxにSHAをコピペ)
```
![“スクリーンショット” 2021-01-05 20.44.42.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/698439/9d90fd99-099f-4b16-b96a-805b28eef0a8.jpeg)


改めてGitHub Desktopの便利さに気づきました。また、ブランチでちゃんと分けてなおかつ細かくPushしたので助かりました💦
Regional Scrum Gathering Tokyo 2021 Day 1 「セキュリティとアジャイル開発のいい関係について考える / Security and Agile Development」

# Regional Scrum Gathering Tokyo 2021 Day 1 「セキュリティとアジャイル開発のいい関係について考える / Security and Agile Development」

2021/01/06に開催されたRegional Scrum Gathering Tokyo 2021での発表です。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14639/security-and-agile-development

# チーム参加してきました

[aslead Agile](https://aslead.nri.co.jp/solution/aslead_agile.html) のチーム「[オキザリス](https://speakerdeck.com/viva_tweet_x/huesudeyong-qi-wode-taxin-gui-timugashi-yan-wozao-rifan-sitejin-nizhi-rumadefalsewu-yu?slide=3)」にて参加してきました。
チーム7人で参加して、その場で実況しつつ、記事も作っています。

# 今日お話しすること
1. セキュリティとアジャイルが仲良くなるためのコツ
2. 実際にやっていることの紹介

# セキュリティチームも開発チームも目標は同じ
- セキュリティの向上
- 機能の追加

# 仲が悪くなる原因は何か

- チェックリストをパスするように上から目線で言われる
  - 例）情報セキュリティ管理/監査基準
  - 例）チェックリスト

- チェックリストは絶対的？
  - チェックリストは盲目的に従うものではない
  - 対応を要する項目を発見し、取捨選択するもの

# いい関係へのコツ
- 「絶対的」思考
  - セキュリティ担当者はこちらが多い 
- 「相対的」思考
  - アジャイルプラクティショナーはこちら
- 「絶対的」思考から「相対的」思考に引き込む

# 職場での実践例
## カードゲームを使ったシフトレフトの実現
- シフトレフト
  - 設計→実装→システム運用・保守
  - 設計の段階でセキュリティ対応を行う
- STRIDE による脅威分析
  - 6つの観点からセキュリティ的な脅威をあぶり出す
  - STRIDE分析用カードゲーム
    - 日本語版作って、無償公開中！
    - https://qiita.com/makoto-iguchi/items/485cf71c3d5f8d178818

## セキュリティタスクを正しくスプリントバックログに積む
- これが結構難しい
  - セキュリティタスクは後回しにされがち問題
- 価値を高めるものから積む
- セキュリティタスクを積めていないということは価値を高められていないということ？
  - プロダクトの弱点（脆弱性）を修正するためのタスク
  - 脆弱性＝爆弾と考えてみると
    - プロダクトに爆弾がついていても爆発しなければ問題ないが、爆発すると価値は一気に吹き飛ぶ

## ということで
プロダクト価値を高めるために効率よく実装タスクを積んでいく
爆弾処理バックログは爆発したらやばそうなものから適宜処理していく

- MVP with MBP
  - MBP：まあ爆発してもプロダクト死なないだろう
  - プロダクトバックログ同様、定期的に爆弾処理バックログのリファイメントを実施することで対応

- 爆弾が溜まりすぎた例：Zoom
  - 新機能開発を90日間停止
  - セキュリティ/プライバシー問題に集中

# 感想
セキュリティ対策後回しにされがち問題、すごく共感しました。
セキュリティ問題に一気に最後に対処したり、最初からやらなければならないとなると大変なので、MBPを考えて対応すればよいという考え方は良いなと思いました。
「STRIDE分析用カード」日本語版も有り難く使わせていただこうと思います！
Regional Scrum Gathering Tokyo 2021 Day 1 「全社で大規模スクラム(LeSS)移行して1年間」Retty執行役員が全て答えます」  


2021/01/06に開催されたRegional Scrum Gathering Tokyo 2021での発表です。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14722/less1retty
 
# チーム参加してきました
 
[aslead Agile](https://aslead.nri.co.jp/solution/aslead_agile.html) のチーム「[オキザリス](https://speakerdeck.com/viva_tweet_x/huesudeyong-qi-wode-taxin-gui-timugashi-yan-wozao-rifan-sitejin-nizhi-rumadefalsewu-yu?slide=3)」にて参加してきました。
チーム7人で参加して、その場で実況しつつ、記事も作っています。
 
## LeSSについて
たくさんのチームでスクラムするには？のフレームワーク。スクラムのルールをそのまま適応。Rettyで導入している。そのうえで起きた問題やその解決などの経験談が、今日のテーマ。
 
## Q&Aコーナー
 
下記のテーマを軸に自由にQ&Aする形式でした。
 
### 導入の動機・検討
組織の立て直し時に、開発体制の問題に気が付いた。当時、プロダクトオーナーが複数いて、それぞれの領域でわかれて作業していた。最初はうまくいっていたが、サービスの成熟につれ領域がかにばるように。各チームにとって優先順位が違うため、調整に苦労した。調整が調整を呼ぶ状態。全社として、本当にやりたいことができているか？という疑問が出てきた。まずはバックログを1つにしよう、という話からスタートし、LeSSにたどり着いた。また経営層へのコスト対効果の説得については、課題を整理・分析し、何を解決したいかを深堀りして丁寧に説明した。どれほど開発進むか？利益増えるか？を、できる限り数値で示した。
 
### 導入の始まり
すべてのチームから始めるのではなく、1,2チームから始めた。効果が出てくると、皆信頼してくれるように。また、うわさで「なんか体制変わるらしい」と広がってしまうのは不安を煽るため、皆で話す場を設定したり1on1したりと、信頼を得る努力をした。
 
### 導入の道のり
メンバーから、今後の体制やキャリアの不安も見受けられたが、きちんと会話することで取り除いていった。方針をまず打ち出し、徹底的にフォローするが、それでも合わないのならしょうがない。若手に、御用聞きの立場ではなく「成果を出すこと」が使命だとわかってもらうのに苦労したこともある。バックログの中で、皆の合意をとるための課題を押し上げるのも大事。開発メンバーには、スプリント計画やレビューのイベントに出席してもらい、スプリントで開発するものの共有に努めた。営業メンバーはあまりLeSSに沿った動きをしてもらうことはなかったが、スプリントレビューで成果を共有したり、スプリントゴールをしっかり理解してもらった。
従来は、チームごとにイテレーションのサイクルや成果物の形など全然違っていてお互いの内容把握が難しかった。チーム間のコミュニケーションは、うまい人に属人的に頼っていた。しかしLeSSで統一することで解決した。
大規模だからこその難しさは、あまりなかった。各チームでいいところどりをしながら、自然と広まっていった。ふりかえりを各チームしっかり行うことを徹底していたからこそ、各チームへのノウハウ共有がスムーズだった。
 
### 導入の成果
プロダクトに対しての優先順位のつけ方が変わった。週一でみんなでバックログを作るようになった。エンジニアのが取り組む課題は、最初から細分化せずに1つのバックログにまとめたうえで、各チームに分散させていくように。
プロダクト全体のことを考えながらストーリーを考えることを念頭にした。またチーム編成など、体制はLeSSのカギとなる部分のため入念に話し合っていた。
 
### 頂きを目指す
　アウトプットはちゃんと出るようになったが、まだまだ伸びしろある。どう伸ばすか、のはっきりした解をまだ持っていない。うまくビジネスとつなげていくためにがんばる。
 


# 感想

大変興味深い、大規模スクラムの導入の裏話でした。Discordでの質問も大盛り上がりで、皆さんの興味の大きさが垣間見れました。
1つのサービスを複数チームで作り上げる（しかも今回のお話は、Rettyという非常にユーザ規模の大きいサービス）のは一筋縄にはいかないことと思いますが、うまくLeSSというフレームワークを取り入れ変革を遂げた、お手本のようなお話でした！
【Rails】シングルテーブル継承を使って、テーブルの数を削減する【STI】

#シングルテーブル継承（単一テーブル継承、STI）とは
シングルテーブル継承（以下、STI）は、単一の継承階層に所属するクラス群を、ただひとつのテーブルを使って永続化する手法です。

言葉だけでは伝わリにくいので、下図を御覧ください。

![スクリーンショット 2021-01-05 18.49.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/680641/d3974cd0-ab5f-573b-734f-2136a0937078.png)

Postsテーブル（スーパークラス）が、サブクラスに継承する形になります。
しかし、注意点が2点あります。

* **Books,Clothes,Goodsテーブルは実際には存在しない。**
* **個々のデータは全てスーパークラスのテーブルに保存されます。この場合はPostsテーブル。**

それでは、STIはどういう場面で使えばいいのでしょうか。

#STI継承しないと中間テーブルが再生産が起きる
私はSTIの存在を知らずにアプリを作っており、下図のようになってしまいました。

![スクリーンショット 2021-01-05 18.34.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/680641/8d2b635d-7097-5db6-62ce-0d966087bb63.png)

・・・。

PostsテーブルとしてはBooksとClothesとGoodsの記事を作りたかったのですが。。。

それぞれのテーブルを作ってしまうことで、それぞれの中間テーブル（ここでは、Comments,Likes,Picksテーブル）が再生産が起きてます。

機能自体はできましたが、ゴチャゴチャしすぎて保守的には最悪ですね・・・。
何より新機能をつける度に3つテーブルを用意する必要があり、骨が折れます😅

そこで！STIを使い、Postsクラスをサブクラスに継承させました！
以下の通りです。

![スクリーンショット 2021-01-06 13.40.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/680641/b1aa8afc-0665-2c8c-a24f-738c613332ca.png)

めっちゃスッキリしましたね！
（画像にはBooks,Clothes,Goodsはテーブルとして書いてありませんが、継承させています。）
これで保守がしやすく、新機能もつけやすくなりました！


#やり方（結論）
###1. スーパークラスを作る

`rails g model post`でマイグレーションファイルを作成し、テーブルの設定をします。

```ruby:migrate/〇〇_create_posts.rb
class CreatePosts < ActiveRecord::Migration[6.0]
  def change
    create_table :posts do |t|
      t.references :user,foreign_key: true

      #省略

      t.string :type #typeカラムを作成します！
      t.timestamps
    end
  end
end
```
ここで注意したいことは、**typeカラム**を作成することです。
この中に継承先のクラス名が入り、管理されます。

###2. それぞれのクラスを作成し、スーパークラスを継承させる

先程のファイルをマイグレーションしてできたモデルファイルを編集したものです。

 ```ruby:models/post.rb
class Post < ApplicationRecord
  belongs_to :user
  
  #省略

end
```

それでは`rails g model book --parent=Post`でbookモデルを作成します。
`--parent=PARENT`オプションを使うことで、マイグレーションファイルを生成せずに済みます。

```ruby:models/book.rb
class Book < Post
  #こうすることでスーパークラスのアソシエーションやバリデーションが引き継がれます。
end
```

完成です！


ちなみに！
この状態でBookモデルを保存すると、Postsテーブルのtypeカラムに"Book"が代入された状態で,Postsテーブルに保存されます。

```ruby
Book.create(title: "本です",.......)
```

以上でSTIのやり方は終わりです。
最後まで読んで頂きありがとうございました！

#参考
Railsガイド
https://railsguides.jp/association_basics.html

[Rails] STI（単一テーブル継承）とメタプログラミングでDRY
https://qiita.com/kidach1/items/789c2e7aebbcfbd2583e
MATLAB bench on MBA (M1 2020)

# Result

![スクリーンショット 2021-01-06 12.57.45.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/105692/2bf6641f-27ca-fb20-8d02-6a989f9c2eb9.png)

![スクリーンショット 2021-01-06 12.57.49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/105692/ad2c4cf3-3285-c073-88ce-8184b5585e12.png)

# Environment
R2020b(9.9.0)
Rosetta 2

# Reference
https://www.mathworks.com/help/matlab/ref/bench.html
Regional Scrum Gathering Tokyo 2021 Day 1 「「全社で大規模スクラム(LeSS)移行して1年間」Retty執行役員が全て答えます」

# Regional Scrum Gathering Tokyo 2021 Day 1 「「全社で大規模スクラム(LeSS)移行して1年間」Retty執行役員が全て答えます」
 
2021/01/06に開催されたRegional Scrum Gathering Tokyo 2021での発表です。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14722/less1retty
 
# チーム参加してきました
 
[aslead Agile](https://aslead.nri.co.jp/solution/aslead_agile.html) のチーム「[オキザリス](https://speakerdeck.com/viva_tweet_x/huesudeyong-qi-wode-taxin-gui-timugashi-yan-wozao-rifan-sitejin-nizhi-rumadefalsewu-yu?slide=3)」にて参加してきました。
チーム7人で参加して、その場で実況しつつ、記事も作っています。

# Retty紹介
実名型グルメサイト「Retty」を運用。
エンドユーザにHappyを届ける。

# QA
### 導入の検討はどのように進めましたか？
- 導入はトップから。
- 当時POのような人が複数人いたが、それぞれの領域で作業していた。
- はじめはそれでもうまくいっていたが、プロダクトが大きくなってきたときに問題が発生してきた。
    - 優先順位がチームごとに違うため、調整に時間がかかってしまう
    - 優先順が何が正しいのか判断がつかなくなってくる
    - これらを解決するために試行錯誤の結果、LeSS
- チームごとに縄張り意識があった
    - Webから基盤への依頼など、調整先の基盤でも調整が行われる。「調整の調整」が始まる。
    - 優先順が統一されていないために起こる問題
    - 優先順を統一する方法を模索した結果、LeSS


#### 導入にあたり執行役員などにどのように持って行ったのか？
   - スムーズではあった
   - 課題を整理。その課題に対してどうしたいかを資料にまとめて説明した。
       - 課題の整理と分析
       - 他社事例
       - 経営インパクト。その施策により売り上げはどうなるか、など。

#### もともといたPOはどうなったのか？反発は？
   - マネージャが工数を持ち、エンジニアがいる。という構図であった。
   - マネージャからは工数をはがし、エンジニアに工数を持たせるようにした、。
   - マネージャからは反発はもちろんあったが、小さく始めて成果がでていることを確認し、広げていくようにした。
   - 不安があったら話す場を設けて、不安を解消するように気を付けた。

#### 現場のエンジニアへも同じように不安を聞いて解消するアプローチをとったのか？
   - YES
   - 将来のキャリアをどうするか、などの話は多かった
   - 何回も話をしながらムリなく変化していけるようにした
   - 方針に合わず退職した社員はいる。フォローはするがどうしても会わない場合には仕方ないと割り切る
   - 若手の総合職はエンジニアのタスクを細かく見る御用聞きのようになっていた。それは評価にならないというのを伝えていった。意識が変わるまでは半年以上かかった。
 
#### サポート・営業・管理職などエンジニア以外はLeSSではどのような位置づけになりますか？
   - スプリントレビューなどに極力出席してもらい、プロダクトの情報を共有。週一の全社会議でスプリントゴールを共有。LeSSと共同で動いてもらう位置づけ
   - こうすることでどんな成果があったのか？
       - 成果物をそこで共有することで、いままでだとイテレーションのサイクル、成果物のフォーマットなど、チームごとに異なっていてよくわからない状況だったが、情報が共有されているため合わせることができるようになった。

#### LeSSを導入すると規模が大きくなるため意思決定が難しくなるイメージがある。大規模ならではの難しさはあったか？
   - 各チームでイテレーションのサイクルに乗っ取っていれば好きにやってよいというスタンス。あまり難しさは感じなかった
   - KPTでよさそうなものがあれば、自然と広まっている感覚
   - うまくいっているチームがあれば見学に行ったり、メンバーを派遣してみたり
   - ふりかえりを大事にしていた
  
#### チームの切り方
- きもになる部分ではある
- やるぞと思ってからやり始めるまでの準備期間は？
    - 頭の中で2～3か月、計半年くらいの準備期間だった
- 最初は１チームで通常のスクラム。そこでうまくいったら２チーム、３チームと増やしていった。

#### 現在の状況
- 大規模開発はできるようになりアウトプットはでるようになった。
- ただ、成果として十分に発揮できているかというとまだノビシロがあると感じている。
- 開発とプロダクトチームが分かれたことで、ビジネスとしての距離が少しと行ったと感じており、この部分を近づけたいというのが悩みどころ。
 


# 感想
実際にLeSSを導入している方々の体験談はとても貴重でした。
今回のお話では体制を変えるにあたった旧体制のキーマン（工数を持っているマネージャ）に対してどう接し、どう変化したのかを伺いましたが、やはり反発は出るもの。それをどうフォローしていくかが如何に重要かということを学びました。
今後大規模開発となりLeSSを導入する際には今回の体験談が大いに役に立つのではないかと思います。貴重なお話をありがとうございました。
※途中音声トラブルがありお聞きすることができない部分があったのが残念です。
プログラマの基礎の基礎、記号の読み方

# 導入
プログラマに限らず、記号の名前がわからなかったりして困ること、ありますよね。
ということでASCIIコード表にある記号の読み方をまとめました。
Google検索するときとかに便利だと思います。

## 記号の読み方一覧
|  ASCIIコード | 16進数 | 記号 | 呼び方1 | 呼び方2 | 日本語 | 俗称（一例） |
| :---: | :---: | :---: | :---: | :---: | :---: | :---: |
|  33 | 0x21 | **!** | **エクスクラメーションマーク** |  | 感嘆符 | びっくり |
|  34 | 0x22 | **"** | **クォーテーションマーク** |  | (二重)引用符 | ちょんちょん |
|  35 | 0x23 | **#** | **ナンバーサイン** |  | 番号記号、井桁 | シャープ |
|  36 | 0x24 | **$** | **ダラーサイン** | ドル | ドル記号、ペソ記号 | ドルマーク |
|  37 | 0x25 | **%** | **パーセント** |  |  | パー |
|  38 | 0x26 | **&** | **アンパサンド** | アンド |  |  |
|  39 | 0x27 | **'** | **アポストロフィ** | プライム |  | ダッシュ |
|  40 | 0x28 | **(** | **オープンパーレンセシス** |  | (丸)括弧、開き括弧 | かっこ |
|  41 | 0x29 | **)** | **クローズパーレンセシス** |  | 閉じ(丸)括弧 | かっこ閉じ |
|  42 | 0x2a | **&#x2A;** | **アスタリスク** |  | 星印 |  |
|  43 | 0x2b | **+** | **プラス** |  | 正符号、加算記号 | 足す |
|  44 | 0x2c | **,** | **カンマ** | コンマ |  | ちょん |
|  45 | 0x2d | **-** | **ハイフン** | マイナス | 負符号、減算記号 | 引く |
|  46 | 0x2e | **.** | **ピリオド** | ドット | 終止符 | 点 |
|  47 | 0x2f | **/** | **スラッシュ** | ソリダス | 斜線 |  |
|  58 | 0x3a | **:** | **コロン** |  |  |  |
|  59 | 0x3b | **;** | **セミコロン** |  |  |  |
|  60 | 0x3c | **<** | **レスザン** |  | 小なり、不等号 |  |
|  61 | 0x3d | **=** | **イコールズサイン** | イコール | 等号 | は（注：「わ」と発音する） |
|  62 | 0x3e | **>** | **グレーターザン** |  | 大なり、不等号 |  |
|  63 | 0x3f | **?** | **クエスチョンマーク** |  | 疑問符 | はてな |
|  64 | 0x40 | **@** | **アットマーク** | アット | 単価記号 |  |
|  91 | 0x5b | **[** | **オープニングブラケット** |  | (開き)角括弧 | (開き)大括弧 |
|  92 | 0x5c | **&#x5C;** | **バックスラッシュ** | スロッシュ | 逆斜線 |  |
|  92 | 0x5c | **¥** | **円** |  | 円記号 |  |
|  93 | 0x5d | **]** | **クロージングブラケット** |  | 閉じ角括弧 | 閉じ大括弧 |
|  94 | 0x5e | **^** | **サーカムフレックス** | ハット |  | キャレット |
|  95 | 0x5f | **&#x5F;** | **アンダーライン** | アンダースコア | 下線 |  |
|  96 | 0x60 | **`** | **グレイブアクセント** | アクサングラーブ |  |  |
|  123 | 0x7b | **{** | **オープニングブレース** | カール | (開き)波括弧 | (開き)中括弧 |
|  124 | 0x7c | **&#x7C;** | **バーチカルライン** | バーチカルバー | 縦線 | バー、縦棒 |
|  125 | 0x7d | **}** | **クロージングブレース** |  | 閉じ波括弧 | 閉じ中括弧 |
|  126 | 0x7e | **~** | **チルダ** |  | 波線符号 | にょろ |

##出典

ASCII記号 (半角記号) の読み方と出し方 - Mimir Yokohama
https://www.mimir.yokohama/useful/0031-ascii-sym.html

約物 - Wikipedia
https://ja.wikipedia.org/wiki/%E7%B4%84%E7%89%A9

キーの文字の呼び方 - 実用文書のまとめ方
https://www.nakanihon.co.jp/gijyutsu/Shimada/bunsyo/Chap040102.htm
Vimの基本操作～メモ～

vimに入門しよう！ということでメモ程度に基本操作を残しておきます。

#基本コマンド#
まずは

```terminal
$ vim
```
にてvimを起動する。
この状態はノーマルモードなので、文字を入力することはできません。

|コマンド     | 内容
|:-----------|------------:
| i          | インサートモードへ切り替える（カーソル位置の左側に追加する）
| a          | インサートモードに切り替える(カーソル位置の右に追加する)
| :q         | vimを終了する
| :q!        | ファイルを保存せずに終了する      
| :w         | ファイルを上書き保存する      
| h          | 左へ移動      
| j          | 下へ移動      
| k          | 上へ移動  
| l          | 右へ移動
| k          | 上へ移動  
| x          | カーソル位置の文字を削除する（カーソルが一つ右へ移動）
| w          | 前方（右）に単語１つ分移動する
| b          | 後方（左）に単語１つ分移動する
| W          | スペース区切りで前方（右）に単語１つ分移動する
| B          | スペース区切りで後方（左）に単語１つ分移動する
| 0          | 行頭に移動
| $          | 行末に移動




もっとvimに慣れたいなあ
Go言語-基本❶

# 基本❶
プログラミング基本からGoの理解を文字におこして行こうと思います！

### 文字列とは
```go
package main
func main(){
  println("Hello, Go")
}
```
""(ダブルクォーテーション)で囲んでいないとエラーが発生する

### 出力の命令
```go
package main
func main(){
  println("Hello, Go")
}

//コンソール
Hello, Go
```
printlnというのは、Goが用意している「命令」の1つ

「コンソールにprintln()の中のものを出力せよ」という命令
→コンピュータが文字列をコンソールに出力

### プログラムの構成
```go
package main
func main(){
  println("Hello, Go")
}
```
Goのコードのファイルは、パッケージ定義部や関数定義部によって構成

ここでは「package main」と書かれたファイルの、main関数の{ }の中に命令を書くと
それが順に実行される

### 数値を使う
```go
package main
func main(){
  println(1)
  println(1 + 1)
  println(1 - 2)
  println("1 - 2")
}

//コンソール
1
2
-1
1 - 2
```
数値は文字列と違いダブルクォーテーションで囲まない

### 演算を行う
```go
package main
func main(){
  println(2 * 5) //掛け算
  println(6 / 2) //割り算
  println(9 % 2) //余りを出す
}

//コンソール
10
3
1
```
このような演算に用いる記号を「演算子」
演算子の種類はプログラミング言語によって異なる

### 文字列の連結
```go
package main
func main(){
  println("Hi" + "Go")
  println("1" + "2")
}

//コンソール
Hi,Go
12
```
文字列に対して「+」を使用すると1つの文字列にする

### 変数とは
データ（値）をいれておく箱
箱（変数）には名前（変数名）がついていて名前を用いて変数から値を取り出せる

### 変数とデータ型
```go
var number int 
//number(変数名)、int(データ型)
```
```go
var number string　
//number(変数名)、string(データ型)
```
変数を利用するには、まず変数を定義
「var 変数名 データ型」

コンピュータに変数を作ることを指示

### データ型

```go
"Hello, Go" //文字列(string型)
3 //整数(int型)
```
文字列や数値は「データ型」と呼ばれる

### 変数を使う

```go
package main
func main(){
  var n int //変数nの定義
  n = 100 //変数nに100を入れる(代入する)命令
  println(n) //nを使用し100を出力
}

//コンソール
100
```
「=」は、変数という箱に値を入れるための記号

### 定義と代入

```go
package main
func main(){
  var n int = 100
  println(n) 
}

//コンソール
100
```
「var n int = 100」と書けば、変数の定義と代入を同時に行える

```go
package main

func main() {
    var message string = "Hello, 世界" //変数messageを定義して代入
    println(message)
}
```

### 変数の値の更新

```go
package main
func main(){
  var n int = 100
  println(n)
  n = 200
  println(n)
}

//コンソール
100
200
```
変数は何度でも上書きできる

### データ型の省略

```go
package main
func main(){
  var n = 100
  println(n)
}

//コンソール
100
```
「var n int = 100」のように、変数定義と値の代入を同時に行う場合
データ型の指定を省略できる

Goがint型であることを代入される値から判断しているから

### 変数定義の省略

```go
package main
func main(){
  n := 100
  println(n)
}

//コンソール
100
```
「var n int = 100」と同じ意味
「:=」であることに注意

### printlnの便利な書き方
```go
package main
func main(){
  a := 100
  b := 200
  println(a,b)
}

//コンソール
100 200
```
printlnの()内に変数aとbをコンマで区切って並べて書けば
2つの値を同時に出力できる

コンマは出力されず、スペースで区切られて1行で表示

[Go言語-基本❷はこちら](https://qiita.com/coxcoa/items/55e126bcbf67cf7505bc)
Regional Scrum Gathering Tokyo 2021 Day 1 参加レポート「Rethink Scrum from Japanese cultural perspective」

# Regional Scrum Gathering Tokyo 2021 Day 1 「Rethink Scrum from Japanese cultural perspective」

2021/01/06に開催されたRegional Scrum Gathering Tokyo 2021での発表です。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14910/rethink-scrum-from-a-japanese-cultural-perspective

# チーム参加してきました

[aslead Agile](https://aslead.nri.co.jp/solution/aslead_agile.html) のチーム「[オキザリス](https://speakerdeck.com/viva_tweet_x/huesudeyong-qi-wode-taxin-gui-timugashi-yan-wozao-rifan-sitejin-nizhi-rumadefalsewu-yu?slide=3)」にて参加してきました。
チーム7人で参加して、その場で実況しつつ、記事も作っています。
この記事では、お話をきいたうえで筆者が感じたことをまとめていきたいと思います。


# どんなセッション？
スクラムについて、日本の「文化的側面」から考え直してみよう、というセッションでした。

- スクラムって、日本からも海外からも同じように見えてるものなの？
- どうしてスクラムって難しいの？
- スクラムやるときってどんなリーダーが必要なの？

という3つのポイントについてお話されていました。
自分の感想を交えながら、順番にどんなお話だったかをご紹介します。


## Q. スクラムって、日本からも他の国からも同じように見えてるものなの？
**A. いいえ、見えてません。**
「場の文化」から見るスクラム、「個の文化」から見るスクラムという見え方の違いがあります。
スクラムの起源は「場の文化」にあるものの、「個の文化」のために標準化されているからです。

ここで日本と他の国の文化的側面の違いについてお話されてました。
### 「場の文化」と「個の文化」のちがい
- 「場の文化」
    - 共感でつながっている。
    - 言葉そのものを解釈するとき、その裏にある意図などもふまえて解釈する。
- 「個の文化」
    - ルールでつながっている。
    - 言葉そのものを解釈するとき、そのまま言葉通り解釈する。

場の文化を好む人が「なんでこう言ったのに（必要だと察してあれもこれも）やらないのか」という意識を持つ一方で、個の文化を持つ人が「いわれたことやってるのになんで不満そうなんだ？」と感じてしまう、という例を聞くと「あ～確かに...」と納得がいきますよね。

## Q. どうしてスクラムって難しいの？
**A. 場の文化のもとで起きる組織的窒息がスクラムの妨げになっちゃうから**

### 「組織的窒息」とは？
空気の支配、年功序列、学習棄却の失敗の結果として生まれてしまう組織の状態。

- 空気の支配：空気が場全体を支配した結果、だれも責任をとれないことが意思決定されてしまう。場と空気の相互作用で、同調圧力や過程重視思考が生まれる状態。
- 年功序列：能力ベースの評価基準を取り入れられないから、スキルが高い人の才能を活かせなかったり、ポジションを守ろうとしてしまう状態。
- 学習棄却の失敗：一度成功体験をもつと、その手法にとらわれすぎてしまう状態。例えばウォーターフォールで一度成功体験を積んでいるので、それがうまくいかなくなったときに棄却して新しい方法を取り入れるのが難しくなってしまう。

この結果、問題が起きても口に出せない、相手の年次によって態度を変える、前例のないことに拒否反応が出る、といった状態になってしまいます。

楽天ではこういった側面を打破するべく「コミュニケーションの英語化」を取り入れたとのこと。

## スクラムやるときってどんなリーダーが必要なの？
**A. 技術と経験＋共感力（場の文化）を持ち合わせている人が理想**
とはいえ、全てを兼ね備えている人材はめったにいなく、、

- 進め方はスクラムマスターが
- 内容はプロダクトオーナーが

それぞれ管理するという進め方があるね、というお話でした

### トヨタの例
ここでトヨタの製品開発チームにおけるチーフエンジニアの例が紹介されていました。

- チーフエンジニアとは？コンセプトの創造、デザイン、設計、品質管理など、あらゆるプロセスの責任者
- チーフエンジニアは製品開発プロセスに携わる立場。高いスキルがあれば誰でもなれるものではない


# まとめ
- スクラムの起源と場の文化、組織的窒息からの脱出、そして場の文化とスクラムのリーダーシップについてのお話
- 日本は場の文化を好むものの、どんどん個の文化へと変化しているとき
- 場の文化の良さを活かしながら、両方を取り入れられていけるとよい


# 感想
今回は英語でのセッションだったのでドキドキだったんですが、
とても聞き取りやすい・わかりやすいお話で楽しく聞くことができました。
「個」と「場」の文化の違いを的確に言語化されていて、例を聞きながらより理解を深められたなと思います。
そしてなにより、楽天の英語化のお話がとても印象的でした。
英語でお仕事されている話は知っていたのですが、その裏に「組織的窒息からの脱却」という目的があったんだなと。。
とても勉強になるプレゼンでした。
Regional Scrum Gathering Tokyo 2021 Day 1 「組織がアジャイルになっていく道を歩んだ時、「少しだけうまくやれたこと」と「うまくやれなかったこと」」


2021/01/06に開催されたRegional Scrum Gathering Tokyo 2021での発表です。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14620

当日参加してのメモや感想を備忘として書いています。
スライドのフレーズを引用しつつそれぞれの言葉に対して感じたことや、最後に全体を通しての感想を記載します。

講演資料は[こちら](https://speakerdeck.com/player/ff965f934cc24627bc193cbce5886159?feature=oembed)をご覧ください。
※厳密には発表で用いられたスライドとは内容が異なるようです。


## 組織にスクラムを持ち込んで起きたこと

- １チーム→４チームといった次第に徐々に広げていった
    - 「まずやってみよう」が個人、チーム、組織で当たり前になったとのこと。
    - この意識はスクラムを実践すると徐々に身についてくるものだと思います。
- 組織をプロダクトとしてみる考え方をするようになった
    - 検証のタイミングと"後戻りの条件ポイントを決めておく"ことで、「その場しのぎ」の対応ではなく、「（計画通り後戻りする）という安心感につながると思いました。

## 経営を通して学んだこと
- 相談から入ることで余白を作る
    - なにか決めたものをトップダウンで落とすだけでなく、「これどう思う？どう見える？」という対話の時間を作るのは、メンバー視点でも安心感につながると思います。
- 他者が乗ってくるまで待つ
    - その時々で状況は変わるものなので、我慢強く伝え続けることも必要だと感じました。
    - また、なにか期待するのであれば、相手の状況や考えに配慮するということかなと思いました。


# 感想
「やり方」と「あり方」はぜんぜん違うものだと感じました。
個人的にはやり方起点であり方が変わることもあると思っています。
ただ、経営のような人と人がたくさん絡み合う複雑なモノでは、反発が起こったり難しいのだと思いました。

発表の中にあった、「WhatではなくWhyに目を向ける」というのは、なにか価値を届けるときだけでなく、組織運営においても役立つ視点だと感じました。
また、「これまでの積み重ねに敬意を払う」というのは、過去関係してきた人々に敬意を払うこういだと思います。
先人達への感謝はわすれず、されど過去にとらわれない考え方をすることが、変な反発を受けずにうまく変換い適応していく考え方なのだと思います。
RSGT2021 セッションメモ ～組織がアジャイルになっていく道を歩んだ時、「少しだけうまくやれたこと」と「うまくやれなかったこと」～

RSGT(https://2021.scrumgatheringtokyo.org)
で自身が参加したセッションのメモ&ふりかえりです。
ふりかえりの手法は、びばさんが配信しているPodcastである、ふりかえりAM ep.4(カンファレンス用のふりかえりをする例)で紹介されていたFun Done Learnを参考にしています。
# 概要

- 中村洋さん

- Day1(2021/1/6) 13:00～

- ScrumやXPなどを用いて、みなさんのチームがアジャイルになっていっているとします。

  そのチームの活動がプロダクトを構築することが主なら、次はプロダクトをより使い続けてもらえるプロダクトづくりができるチームを目指してもいいかもしれません。

  その時には開発をする役割以外にも、ユーザーのことを知る活動、ユーザーに買ってもらう活動、ユーザーのサポートをする活動など様々な活動が必要になります。そしてその活動を担う人達やチームと連携して動く(少し大きな)チームになる必要があります。

  このようなチームがうまく機能する要素の1つに「組織がアジャイルな価値観や考え方、それに根ざした活動ができているか？」というのがあります。
  もし1つ、2つのチームしかアジャイルな価値観や考え方を持っていなければ、このようなチームはうまく機能しないかもしれません。

  このセッションでは、組織がアジャイルな価値観や考え方、それに根ざした活動をうまくできるようになるために取り組んできた事例をお話します。
  組織の中の一員としてやっていた(昔の)事例、ギルドワークスの現場コーチとして様々な現場を外から支援していた事例をお話できればと思います。

  みなさんの組織がアジャイルになっていくヒントになればと考えています。

# 気になったことメモ

- 今日の話は中村さんの経験と中村さんから見た組織の話

- 相手のことを知ってる？(経営者とか役員とか、名前だけ知ってたりしない？)
- 相手の状況をコントロールすることはできない

- 上手くいかなかった話
  - あり方ではなくて、やり方にこだわった
    - やることは熱狂できた
    - 経営陣は表と裏がある。悪い話ではない。経営陣は自分たちよりも複雑なコンテキストにいる
    - 上手くいっていることもあるはず
    - これまでのやり方にも経緯がある
    - Whyや背景に注目しよう
- 上手くいった話
  - 組織をプロダクトとしてみる
    - 組織全体としてまずはやってみようという発想になった
      - プロダクトに対しては直ぐに実験してみようとなりやすい。でも組織ではそうなりにくい。そこで、組織もプロダクトだと考えるようにしてみた。
    - 方向性(ビジョン、プロダクトの方向性があった。深さはバラバラだったがそれでも良い)と自律性(方向性に向けてそれぞれがどういう道のりを辿るか)のバランスが大切。
    - 相談から入ることで余白を作る。
      - (NG) 「こうします」「こうした方がいいです」
      - (OK) 「こうしたいんだけどどう思う？」「自分はこう見えているんだけどどう思う？」
    - 他者が相談に乗ってくるまで待つ。
      - 視点や伝え方を変えて、自分の思っていることを伝え続ける。相手の興味がこっち側に来るまで待つ
  - 新経営陣の下で組織開発
    - 現場で何をしているのか見る。レポートに頼らない。
    - 現場でやっていることを経営陣にも導入してみる
      - ふりかえりやってみよう
      - 1週間のイテレーションで回してみよう
    - チームから組織へ
    - 価値観が広がった
    - 経営者がRSGTに参加している
- 中村さんの学び
  - 実際にやってみよう
  - "分かり合えない"前提で話し合う。
  - 継続的に対話する
    - 1回で決まらなくてもいい、分かり合えなくてもいい、という気持ちになるので凄い楽

# 楽しかったこと
- 中村さんの落ち着く話し方
- 中村さんが複数の現場で経験してきたリアルな体験を聞けた
- 新経営陣の下で組織開発、の話についてはデブサミで物語の続きが聴ける

# やったこと
- アウトプットを意識しながら話を聞いた
- 自身の現場や自身のコンテキストに置き換えながら中村さんの話を聞いた

# 学び
- 気長に待つという力が自分には足りない。焦って動いてしまっている
- 余白を残した相談, 話し方というのは一方的なコミュニケーションを防ぐこともできるし是非取り入れたい
- チームメンバー以外とも継続的に対話をする時間を設けることの必要性を実感した
- 組織に対してもプロダクトと同じように、小さい変化を継続して続けていくことが大切
  - オブジェクト指向をはじめ、システム開発の考え方を組織にも取り入れると効果がある気がした

# 参考文献
- Fearless Change
- 他者と働く
- 学習する組織
jQueryとネイティブJavaScriptでスムーススクロール

webサイトにはかならずと言っていいほど実装されるスムーススクロール。
わたしもJavaScriptを勉強した当初真っ先に調べたコードでした。

そんなスムーススクロールを今回はjQuery版とJavaScript版のコード、どちらも書いていこうと思います。

どちらも**前提にHTMLファイルにてリンク先はid付与**しています

#jQueryでスムーススクロール
```javascript
$(function () {
// 対象となるセレクターを取得し、クリックイベントに無記名関数を代入
    $('a[href^="#"]').click(function () {
// href属性の属性値を取得
        let href = $(this).attr('href');
// 取得した属性値から飛び先のセレクターを取得（三項演算子をつかってます）
        let target = $(href == '#' || href == '' ? 'html' : href);
// 飛び先の位置を取得
        let pos = target.offset().top;
// bodyとhtmlにanimationプロパティを付ける
        $('body,html').animate({
            scrollTop: pos
        }, 400, 'swing');

        return false;
    });
});
```

1. $('a[href^="#"]')で"#"からはじまるaタグをすべて取得します。
2. クリックされた、$('a[href^="#"]')のhref属性の値を取得します。
3. 三項演算子（条件式 ? true : false）をつかって飛び先のセレクターを取得し、変数targetに代入します。
4. offset()メソッドを使用し、targetのtopからの位置を取得し変数posに代入します。
5. bodyとhtmlにanimationプロパティを付けて完成！

#JavaScriptでスムーススクロール

```javascript
const a = document.querySelectorAll('a[href^="#"]');

for (let i = 0; i < a.length; i++) {
  a[i].addEventListener("click", (e) => {
    e.preventDefault();
    let href = a[i].getAttribute("href");
    let target = document.getElementById(href.replace("#", ""));
// 要素の上端のY座標を取得
    const rect = target.getBoundingClientRect();
// 現在のスクロール値を取得
    const set = window.pageYOffset || document.documentElement.scrollTop;
    const pos = rect.top + set;
    window.scrollTo({
      top: pos,
      behavior: "smooth",
    });
  });
}
```

手順としては同じです。
違うとすれば、
`const rect = target.getBoundingClientRect();
    const set = window.pageYOffset || document.documentElement.scrollTop;
    const pos = rect.top + set;`
の部分ですね。

getBoundingClientRect()はwindow上の座標の位置を返します。
rect.topで要素の上端のY座標を取得しています。

` const set = window.pageYOffset || document.documentElement.scrollTop;`
ではwindow.pageYOffsetがtrue(値あり)の場合、変数setに代入されますが
window.pageYOffsetに対応していないブラウザ用に後者のルート要素（html要素）のscrollTopを用意しています。

最終的な移動量はrect.topに現在のスクロール量を足したものとなります。
そうでないと、現在スクロールしている分だけ移動量が足りずスクロールが止まってしまいます。

あとはヘッダーの長さなどいろいろと各仕様に合わせて移動量を調整してもいいですね。

#まとめ
個人的にはなるべくJavaScriptで書きたいですが、コードが短くなるjQueryはやっぱり魅力的ですね。
また、座標関係のメソッドやプロパティは基準値が色々あるので理解を深めていきたいです。
Homebrew メモ

最近、アンインストールして入れなおす機会があった
よく耳にするので記事に残そうと思う

##Homebrewとは
>macOSオペレーティングシステム上のパッケージ管理システムのひとつである。
同じくmacOSのためのMacPortsやFinkと同様の目的と機能を備え、
利用が広がりつつある。
LinuxのDebianのAPTに似た使用感である。Max Howellによって開発された

引用:wikipedia

あまりわからないので詳しくわかりやすく

一言で言えば**パッケージ管理システム**のこと
Rubyで作られたシステムのこと

最初でダウンロードしておけば、後々楽になる

###パッケージ管理とは
「○○ってソフト使いたいんだけど」
「おっけー！インストールするね！
あ、それを使うには△△も必要だから一緒にインストールしておくね」


てな感じでアプリケーションの依存関係を自動でおこなってくれる

手作業で管理するのは大変出し、限界がある

####パッケージとは
実行ファイルや設定ファイル、ライブラリなどを
**一つのファイルとしてまとめているもの**を**パッケージ**と呼ぶ

パッケージ管理システムとは
このパッケージの`インストール`(`アンインストール`)作業を一元的管理するもの

#参考記事
https://www.braveryk7.com/homebrew/
https://qiita.com/omega999/items/6f65217b81ad3fffe7e6
dotenvはもう古い！最新Nuxtの環境変数管理方法

## はじめに

Nuxtで環境変数管理でdotenvのインストール方法どうだたっけと思い調べていると[Moving from @nuxtjs/dotenv to runtime config](https://ja.nuxtjs.org/blog/moving-from-nuxtjs-dotenv-to-runtime-config/)という記事に出会いました。

要約すると、Nuxtv2.13以降なら、`@nuxtjs/dotenv`から`runtimeConfig`に移行しようということ。

dotenvをわざわざあとからインストールしなくてもNuxtの標準機能で使えるのは嬉しい。

## 実際にやってみる

### 1. 環境変数をRuntimeConfigに定義

使い方は簡単。
これまで通り、`.env`ファイルを作成し、`nuxt.config.js`に`publicRuntimeConfig`と`privateRuntimeConfig`を定義するだけ。

```:.env
BASE_URL=http://localhost:8000
API_URL=http://localhost:8888
SECRET_KEY=test
```

```javascript:nuxt.config.js
export default {
  publicRuntimeConfig: {
    baseURL: process.env.BASE_URL || 'http://locahost:3000',
    apiURL: process.env.API_URL || 'http://localhost:3333',
  },
  privateRuntimeConfig: {
    secret: process.env.SECRET_KEY,
  }
}
```

### 2. 環境変数を使う

- `$config`のグローバルに定義されます。なのでどこからでも呼び出し可能。

```javascript:plugins/axios.js
export default function ({ $config }) {
 consle.log($config.baseURL)
}
```

## runtimeConfigの種類

- publicRuntimeConfigとprivateRuntimeConfigが定義できます。
- privateとpublicという言葉どおりではありますが、`public`は、フロントエンド公開しても良い変数。`private`はフロントエンドに公開してはいけないものという使い分けになります。
- 上記の使い分けから`spa`モードの場合、`privateRuntimeConfig`は使用できません。


## まとめ

- dotenvは使わない、runtimeConfigに移行する
- `.env`ファイルや環境変数の管理方針（.gitignoreしてGitHub等に公開しない）などは変わらず、使い方が変わっただけ。
Dangerで "Cannot find a merge base between danger_base and danger_head" というエラーになったら

GitHub ActionsでDangerを動かしてPRのチェックをしているんですが、あるとき、`Cannot find a merge base between danger_base and danger_head.`というエラーが起こるようになったので、その解決策を共有します。

## ログの全文はこちら

```
/opt/hostedtoolcache/Ruby/2.7.2/x64/lib/ruby/gems/2.7.0/gems/danger-8.2.1/lib/danger/scm_source/git_repo.rb:138:in `find_merge_base': Cannot find a merge base between danger_base and danger_head. If you are using shallow clone/fetch, try increasing the --depth (RuntimeError)
	from /opt/hostedtoolcache/Ruby/2.7.2/x64/lib/ruby/gems/2.7.0/gems/danger-8.2.1/lib/danger/scm_source/git_repo.rb:22:in `diff_for_folder'
	from /opt/hostedtoolcache/Ruby/2.7.2/x64/lib/ruby/gems/2.7.0/gems/danger-8.2.1/lib/danger/danger_core/dangerfile.rb:270:in `setup_for_running'
	from /opt/hostedtoolcache/Ruby/2.7.2/x64/lib/ruby/gems/2.7.0/gems/danger-8.2.1/lib/danger/danger_core/dangerfile.rb:280:in `run'
	from /opt/hostedtoolcache/Ruby/2.7.2/x64/lib/ruby/gems/2.7.0/gems/danger-8.2.1/lib/danger/danger_core/executor.rb:29:in `run'
	from /opt/hostedtoolcache/Ruby/2.7.2/x64/lib/ruby/gems/2.7.0/gems/danger-8.2.1/lib/danger/commands/runner.rb:73:in `run'
	from /opt/hostedtoolcache/Ruby/2.7.2/x64/lib/ruby/gems/2.7.0/gems/claide-1.0.3/lib/claide/command.rb:334:in `run'
	from /opt/hostedtoolcache/Ruby/2.7.2/x64/lib/ruby/gems/2.7.0/gems/danger-8.2.1/bin/danger:5:in `<top (required)>'
	from /opt/hostedtoolcache/Ruby/2.7.2/x64/bin/danger:23:in `load'
	from /opt/hostedtoolcache/Ruby/2.7.2/x64/bin/danger:23:in `<main>'
Error: Process completed with exit code 1.
```

## 発生タイミング

作業中のブランチを最新のメインブランチでリベースをしてpushしたタイミングでした。

## 原因

ログにこのような記載がありますが、

> If you are using shallow clone/fetch, try increasing the --depth (RuntimeError)

内容としては、shallow cloneを使っていたら、depthの増やしてねということです。

### shallow cloneとは

通常git cloneすると、commitの履歴やtagなど全てcheckoutしますが、それだとcloneに時間ががかかり、最新のだけcheckoutすれば十分な場合、shallow cloneを使い、checkoutのボリュームを減らすことができます。
shallow cloneのパラメータが `--depth`で、1であれば、最新1commitだけを取得するようになります。

```sh
git clone --depth 1 <repository>
```

環境はGitHub Actionsで構築しており、以下のようなWorkflowを組んでいました。

```yml
name: Danger

on:
  [ pull_request ]

jobs:
  run_danger:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - name: Setup Ruby
      uses: actions/setup-ruby@v1
      with:
        ruby-version: '2.x'

    - name: Setup Danger
      run: |
        gem install danger

    - name: Run Danger
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: danger
```

`actions/checkout@v2` でcloneしたときに、履歴が取れてないことが原因だと思い、 https://github.com/actions/checkout で仕様を確認してみると、案の定、

```yml
# Number of commits to fetch. 0 indicates all history for all branches and tags.
# Default: 1
fetch-depth: ''
```

と、デフォルトは1となっていました。

## 解決策

`fetch-depth: 0` を指定して、無事エラーが解消できました。

```yml
- uses: actions/checkout@v2
  with:
    fetch-depth: 0
```
【JavaScript】エラー：Uncaught ReferenceError: Pace is not defined at

#【JavaScript】エラー：Uncaught ReferenceError: Pace is not defined at

###使用環境
* XAMPP 8.0 (PHP 8.0)
* windows10

##背景
websiteを作成中に処理を共通化したらクリックイベントが発動しなくなった。あるページでは問題ないのに違うページでは動かない！なぜ？

##エラー
エラー：Uncaught ReferenceError: Pace is not defined at

LoadingのライブラリPaceを使用していたため、それにまつわるエラーだということは分かった。

##原因
外部JSファイルを読み込む順番だった。
外部JS→jQueryファイル→Paceファイルの順にファイルを読み込んでおり、Paceに関連する処理をJSファイルの1番上に持ってきていたため、JSファイルを読み込んだときに、Paceに関する処理がわからない！と怒られていた模様。

##解決方法
外部JSファイルの読み込み順をLoading(Pace)ファイル→jQueryファイル→JSファイルの順番としたところ解決。
【Unity】UI ToolkitのPointerEventBase<T>のpositionは何を指すのか？

ドラッグアンドドロップを実装をするとき、**タップまたはクリックした座標が必要**になります。

今回は**登録したイベント**からタップした座標を取得するという事を`UI Toolkit`でやっていきます。

## PointerEventBase\<T\>のおさらい

**PointerEventBase\<T\>**とは何か？
UI Toolkitで使用されるPointerHOGEHOGEというイベントクラスの親クラスです。

- PointerDownEvent
- PointerMoveEvent
- PointerUpEvent

例えばドラッグアンドドロップを実装する上で使用される上記のクラスは**PointerEventBase\<T\>を継承**しています。[^1]

[^1]: イベントは他にも存在します



## PointerEventBase\<T\>のpositionプロパティが何を指すのか

ここからが本題です。

```cs
/// <summary>
/// Gets the pointer position in the Screen or World coordinate system.
/// </summary>
public Vector3 position { get; protected set; }
```
送られたイベントのpositionプロパティは、コメントアウトにある通りスクリーンまたはワールド座標に変換した座標が帰ってきます。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328771/bc9bee43-8936-b1b3-fdbb-97d17c562672.png" width=450 />
図の用な感じで左上が(0,0)、右下が(maxX, maxY)という事になります。

## maxXとmaxYは何？

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328771/a12286b8-5bad-b7dd-00ca-46e101556dbe.png" width=450 />

`UIDocument`が参照している`PanelSettings`。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328771/a2252c57-7756-9d23-c059-05352b210503.png" width=450 />

`ReferenceResolution`の値が画面右下部分の座標になります。

## まとめ

- PointerEventBase\<T\>のpositionはタップした**スクリーン上の座標**の事
- スクリーンのサイズはPanel Settingsの**ReferenceResolution**である

![D&D.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328771/c68ac50d-0777-325c-9c97-18c8a19538d9.gif)

これでドラッグアンドドロップは実装できそうですね。
【5分で読める】Webエンジニアを目指すのに最低限知っておきたい単語集【超基礎】


# 私について
2020年4月より某プログラミングスクールに通い、卒業後フロントエンジニアとして働いている20代です。

この記事は、自分がスクールに通い得たもの・思った事を中心に「独学でweb系エンジニアを目指す方の手助けになれば」と思い作成しております。


# はじめに
この記事では、webエンジニアを目指す時に知っておきたい単語集ということで様々な単語をまとめております。
実際に、私も未経験からエンジニアを目指し学習を始めたものの、知らない単語に囲まれ少し心が折れかけたこともあるので同じような方の問題解決ができればなぁと思います。

また、初学者の方に伝わりやすいよう、かなり噛み砕いておりますので当記事にて100%理解できるとは思わないように！
あくまで、雰囲気掴みとして読んでみてください！☺️

## ［エンジニア編］
#### バックエンドエンジニア
→アプリケーションの中身の部分（機能）を作る人。例:Twitterの会員登録機能、いいね機能、ブックマーク機能

#### フロントエンドエンジニア
→HP等のUI/UX（ボタンの位置等見た目）を作り上げるエンジニア。デザイナーさんから言われたものを作り上げる。

#### webデザイナー
→HP等の色とかボタンの位置、デザインを考える人

## ［プログラミング言語編］
※横にあるのは難易度だよ。★が多いほど難しいよ✌🏻

#### HTML ★☆☆☆☆
→これがweb系エンジニアの基礎と言っても過言ではないと思う。HPの『仕組みを作る』言語。例えば、この文字は大きくして、この位置に写真を配置してという感じ。

#### CSS ★★☆☆☆
→よく「HTML&CSS」って感じで一緒にされることが多い言語。これはHTMLで作り上げたものを『装飾する』言語。装飾ってのは、例えば色をつけたりするもの。ボタンの色は赤で〜、お問合せフォームの色は緑で〜とかとか。デザインの言語とも言えるかも！

#### JavaScript ★★★★☆
→HPの『動きをつける』言語。動きってのは、ローディング画面とか、ボタンを押したらふわっと横に移動したりとか、よく『アニメーション』とも言われるもの。

#### Vue.js ★★★☆☆
→『JavaScriptのフレームワーク』。
フレームワークってのは、簡単に言うとその言語を強化する役割のもの。よく使われるアニメーションは簡単に出せるようになってたり、JavaScriptだけじゃめんどくさい仕組みを簡単に作れるようになってたりする感じ。

#### Ruby ★★★☆☆
→バックエンドエンジニア（アプリの仕組み作ったりするエンジニア）を目指すなら一番おすすめの言語。日本人が作った言語ってこともあってすごくわかりやすく、学習しやすく、参考記事も多い！（自分もここから始めた）

#### Ruby on Rails ★★★★☆
→Rubyのフレームワーク。同じ感じでRubyを強化するものという感じかな。

## ［職種］
#### web系
→いわゆるwebを作成する時に使用する言語を主とするエンジニア。htmlcss、JavaScript等

#### sler
→ 設計、開発、運用・保守・管理までを一括請負する情報通信企業です。まぁ全てを請け負う企業ですね。

#### 客先常駐
→エンジニアの力を必要としている企業に行き、業務を行うこと。

##### [番外編]どれがいいとかいうあの不毛な議論
→よく目にするのは「web系はキラキラで楽しそう！」とか「客先駐在はブラック！」とかありますが、結論自分のやりたいことを叶えられるなら客先駐在でもいいと思います。そのような記事はあくまで参考する程度にしましょう。（そもそもネットに「この職場よかったわ〜！！」とか書く人あんまりいないですしね。）

# おわりに
【超基礎】ということで本当に最低限の単語を説明させていただきました。
初学者のためになればなぁと思います！😇
じゃんけんゲーム

ランダム関数の小数点以下を切り捨て、整数にする→``Math.floor``

```js
var cphand = Math.random() * 3
```
これを

```js
var cphand = Math.floor(Math.random() * 3)
```

とすることで「0，1，2」のみにする。

###フォームのvalueを受ける

```js
var myhand = document.getElementById('myhand').value
```
>https://itsakura.com/js-selectbox

条件分岐
myhandとcphandを9回比較する。

参考サイト>https://myx.skr.jp/game0.html
http://www.ics.kagoshima-u.ac.jp/edu/katuyoukiso/vc/step4.html
簡単に作れるDockerベースのPasS - Dokkuを使いこなすための設定とプラグイン

簡単にPaaSを作れる[Dokku](http://dokku.viewdocs.io/dokku/)を日常業務に、趣味にと便利に使っています。こんなことできないかな？と思って調べると、大抵はプラグインがあったりします（感謝。ただ、英語なのと情報がまとまっていないので、よく使っている設定をまとめました。

※構築はここでは書きません

## サイト名が一致しない場合にエラーを返したい

デフォルトではサーバー名が一致しない場合には、一番最初にデプロイしたサイトが表示されるようです。予期しないサイトが見えると良く無いのでエラーを返すのが適切です。

/etc/nginx/conf.d/00-default-vhost.conf　を以下のように作成し、nginxをリスタートします。

```:/etc/nginx/conf.d/00-default-vhost.conf:
server {
    listen 80 default_server;
    listen [::]:80 default_server;

    server_name _;
    access_log off;
    return 410;
}
```
http://dokku.viewdocs.io/dokku/configuration/nginx/#default-site

### 注意:

```/etc/nginx/sites-enabled/default```にページを返す設定がデフォルトで入っている場合があり、その場合には上記設定を行うと設定エラーになりますので```/etc/nginx/sites-enabled/default```の設定を削除するか、上記のように410を返すように変更してください。

## developブランチをデプロイしたい

通常はデプロイされるのはmasterブランチなので、git pushでmasterに上書きする方法もありますが、app毎に以下のコマンドでブランチを変更できます。

```dokku git:set myapp deploy-branch develop```

http://dokku.viewdocs.io/dokku/deployment/methods/git/#changing-the-deploy-branch

## ホストの領域をコンテナにマウントしたい

ログ領域やイメージなど、ホスト側領域をコンテナにマウントしたい場合は以下になります。

```dokku storage:mount myapp host-dir:container-dir```

http://dokku.viewdocs.io/dokku/advanced-usage/persistent-storage/

## dockerイメージサイズを小さくしたい

標準ではBuildPackになっており、何も考えずにデプロイできますが、1.5GBくらいのイメージになります。サイトが多くなるとディスクを圧迫します。

Dockerfileを作れば、alpineやslim系イメージを使う事ができます。

http://dokku.viewdocs.io/dokku/deployment/methods/dockerfiles/

この時、Port Mappingを手動でする必要がある場合があります。

http://dokku.viewdocs.io/dokku/networking/port-management/

## CIで自動デプロイしたい

GitLabの場合は以下のエントリーを参照ください。

[GitLab CIでDokkuに自動deployする](https://qiita.com/bellx2/items/42f0ac08abf6df4a2b45)

# plug-ins

使うと便利なプラグインの紹介です。

## BASIC認証をかけたい

テストサイトなど、簡単に認証をかけたい場合に便利です。

dokku-http-auth
https://github.com/dokku/dokku-http-auth

```sudo dokku plugin:install https://github.com/dokku/dokku-http-auth.git```

## SSL化したい

Let's Encrypt
https://github.com/dokku/dokku-letsencrypt

さくっとSSLを使う場合はこれですね。自動的にSSL化 & auto-renewもしてくれます。

```sudo dokku plugin:install https://github.com/dokku/dokku-letsencrypt.git```

## hostnameをコンテナIDでなく、ホスト名にしたい

デフォルトではhostname=コンテナIDになってしまいます。インストールすると、特に設定不要でホストのホスト名がコンテナに渡されます。

dokku-hostname 
https://github.com/michaelshobbs/dokku-hostname

```sudo dokku plugin:install https://github.com/michaelshobbs/dokku-hostname.git dokku-hostname```
M1搭載Macでprocessingのカメラが使えるか検証

#はじめに
M1 Macが届いたので、色々動作チェックをしたいと思います。
まず一番気になるprocessingのカメラ動作から

#実行環境
2021.01.06
MacBook Air M1/16GB

Processing 3.5.4
Processing 3.5.3
video 2.0 (GStreamer-based video library)
OpenCV for Processing 0.5.4

#結果
カメラを使用するサンプルが動くようになりました。

#手順
processing 3.5.4をインストール後、videoライブラリをインストールして、サンプルからカメラの動作チェックをしましたが動きませんでした。OpenCVライブラリをインストールしてみましたが、こちらのカメラサンプルも動きませんでした。具体的には、ウィンドウは何も表示されず、processingのコンソールにも何もエラーっぽいものは出ません。無反応です。


Processing 3.5.3をインストール（3.5.4は消さずに）して、openCVライブラリのサンプルを動かしたら、
BaseSrc: [avfvideosrc0] : Device video access permission has just been denied
と２行表示され、動きませんでした。後で直そうと思い次へ進みました。


Processing 3.5.3でvideoライブラリのサンプルを動かしたら、今度は動きました。カメラが立ち上がるまで、やや時間がかかったので、もしかしたら、最初に3.5.4で動かなかったのは、起動が待ちきれずに、閉じてしまっただけかもしれません。openCVのサンプルを実行し直したら今度は、動きました。原因はわかりませんが、動くようになりました。


Processing 3.5.4に戻り、videoライブラリのサンプルopenCVのサンプル共に、動くことを確認しました。動かなかった原因がモヤモヤしますが、M1のmacでも、processingのカメラプログラミングはできるようなので、一安心です。


途中１回システムアップデート(11.0->11.1)で再起動したので、影響しているかもしれません。
Range オブジェクトを #each や #map で回すときは無限ループに注意する

なんか特定の条件でサーバが重くなるなぁ、と思ったら無限ループでした。

## 注意すべきコード

以下のようなループは無限ループとなる可能性があるので注意

```ruby
(0..max).each do |i|
  # 何か処理
end
```

## なぜ?

Range クラスの仕様で終端が省略されている or nil の場合の Range オブジェクトは「終端なしのRangeオブジェクト」となる。

> An “endless range” represents a semi-infinite range. Literal  notation for an endless range is:
>
```ruby
(1..)
# or similarly
(1...)
```
Which is equivalent to
>
```ruby
(1..nil)  # or similarly (1...nil)
Range.new(1, nil) # or Range.new(1, nil, true)
```
https://docs.ruby-lang.org/en/2.6.0/Range.html

よって、前述のコードでは `max` が `nil` となる場合、無限ループとなる。

## じゃあどうしたら?

以下のように `#upto()` のループに置き換える

```ruby
0.upto(max) do |i|
  # 何か処理
end
```

`max` に `nil` が入る余地を無くすというのも手ですが、そもそも無限ループしない書き方にしたい。

`upto` に `nil` を渡すと例外が発生するので、少なくとも無限ループすることはあり得ない。
composer require実行時につまずいたエラー

## laravelでAuthを導入しようと下記コマンドを実行

```
composer require laravel/ui:2.2
```
### すると下記エラーが出る

```
Fatal error: Allowed memory size of 1610612736 bytes exhausted (tried to allocate 4096 bytes) in phar:///usr/local/bin/composer/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52
Check https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors for more info on how to handle out of memory errors
```

どうやらメモリーが足りず実行できないよう。
laravel/uiに限らずcomposer requireを実行しようとするとこうなる。

## 解決方法

```
COMPOSER_MEMORY_LIMIT=-1 composer　〇〇
```

これで一時的にメモリを確保できるようだ。