slackをきれいにしたい
はじめに
今まで私が参加してきたプロジェクトではslackを初めて使うという人が多く，そしてそのような場合，よくslackが雑然として見にくくなっていた．文句ばかり言っていてもしょうがないので私が普段持っている指針をここで纏めておこうと思ったのが今回の記事の発端である．
この記事の目的としては，私自身が一度自分の指針を文章化したかったこと，今後何らかのプロジェクトでメンバーにslackの使い方などを示す時に使えるようなものにしたいといった感じである．slackをある程度使ったことがあることを前提に話を進める．
一応，今回示すのは私なりの運用ルールであって公式のものではなく，また人によっては違う使い方の方が良いという人もいるであろうことをはじめに断っておく．加えて，slackを使用する上での基本的な概念(チャンネルやスレッドなど)はここで説明することはない．
チャンネルの分け方について
slackのチャンネルはデフォルトであるgeneral，randomの他に自分たちで追加していくという形式であるが，それらの使い方についてある程度の指標が必要であると思う．
general
generalへの投稿は基本的に，プロジェクト全体に関わることかつプロジェクトのメンバー全員に関係がある必要がある．加えて，長期的に重要性がある投稿であることが好ましい．
これらを守って運用することで，generalは全てのメンバーが必ず確認しなければいけないチャンネル，重要な情報を確認する時にまず確認すべきチャンネルとして機能することができる．
random
randomへの投稿は基本的に，重要性の低いこと，雑談等の雑多な内容となる．また，短期的に必要な会話などもここで行う場合がある．
randomを確認する時はそれほど気を張らずに流し読みする程度で良い．randomに重要な連絡を流されて気付かなかった時は流した当人が悪い．
その他のチャンネル
一部のメンバーにのみ関係があること，もしくは長期的に会話や連絡が発生しそうな内容がある時，チャンネルを新しく作成する必要がある．
内容の重要性が低くても新しくチャンネルを作ることに問題は無いが，あまりにチャンネルが増えすぎると使いづらさに繋がるので注意が必要である．使わなくなったチャンネルをこまめに消していくことも必要となる．
チャンネルが増えると，目的のチャンネルを探すのに時間がかかってしまう場合がある．この問題への対策として，全てのチャンネルの前にその重要性や内容に応じて番号を振るという方法がある．例えば，一番左の番号を重要性，次の番号を内容として，
00-general，01-チーム内連絡，10-random
というように番号を振るとする．これによって，チャンネル一覧におけるチャンネル名を任意の順番に並べることができ，チャンネルが探しやすくなる．
これまでのまとめ
- generalに投稿するのはプロジェクト全体に関わる，かつメンバー全員に関係がある長期的に重要なこと
- randomに投稿するのは重要性の低いことや雑談，短期的に必要な連絡など
- 一部のメンバーに関わることや長期的に話す必要がある内容がある時，新しくチャンネルを作る
- チャンネルの名前には整理用に番号を振ると良い
投稿について
さて，slackの投稿のやり方についても色々と注意しておきたいことがある．
文章はなるべく短めに
例えばいくつかの項目について連絡を受ける時，全て文章で伝えられるのと箇条書きでで伝えられるのでは圧倒的に後者が見やすい．それと同じように，slackを見やすくするためには，1つ1つの投稿をなるべく短くして全体的に整理することが重要である．
どうしても文章が長くなってしまう場合には，
投稿する内容について説明した短い文章を投稿→そのスレッドに詳細を投稿
といった方法を取ると良い．
写真やファイル，URLの投稿時は必ず説明を
時々何も言わずに写真やファイルだけ投稿する人がいるが，受け取り側としては通知から内容を把握できないという問題が発生する．
加えて，検索に引っかかりづらいことから後から見返せないということも問題である．
以上の理由から，直接会話している時にこれらが必要になって投稿するといった場合においても説明を加えて欲しい．
また，複数個写真やファイルを投稿する時は先程のようにスレッドに投稿しておくとチャンネルが必要以上に汚くならずに済む．
返信は絶対にスレッドに
なぜスレッド機能があるのにチャンネルで返信する人がいるのか......訳がわからない...LINE気分でslackを使っているのか...？
スレッドで返信しないと次のような問題が起きる．
- 先程から言っている通り，チャンネルに無駄な投稿が増えて汚くなる
- その話題に関係ない人にも無駄に通知が行って迷惑
- 後から見返した時に話の繋がりを把握しづらい
スレッドで返信しない人はひたすらに反省してほしい．
重要なのは，1トピックにつき投稿1つを心懸けることである．
しかし，会話していてどうしてもチャンネルにも投稿したい時があると思う．そのような時は，スレッドで返信する時にチャンネルにも投稿できる機能があるので活用してほしい．
メンション機能は適切に
@channel，@everyoneなどのメンション機能をあまり多用しすぎると，通知を見なくなる人が現れて本当に重要な連絡が見逃される可能性がある．
逆に，@名前といった，個人に対するメンションは投稿の内容が明確になり，メンション通知も当人のみに行くので気軽に使って欲しい．
リアクションはこまめに
slackのリアクションは強いて言えば，例えば投稿が既読であることなど，返信するほどでも無いが相手に何かを伝えたい時に用いる．
リアクションをこまめにすることで投稿者としても不安がなくなって良い．
ただ，基本はリアクションは通知が行かないため，状況によっては「了解です」などの返信をすることも必要となってくる．
投稿のリンクを利用する
slackの投稿にはそれぞれにリンクがあり，例えば他の投稿で引用する時などにそのリンクを貼ることでポップアップさせることができる．
これは違うチャンネルの投稿でも可能であるため，チャンネル外のメンバーにも伝えたい内容が発生した時などにも共有に使える．
その他
太字，斜体，引用タグ等々，その他様々な機能があるので，これらを適切に利用することで見やすい投稿ができる．
これまでのまとめ
- 文章は短く，整理して投稿する
- どうしても文章が長くなる場合にはスレッドに詳細を書く
- 写真やファイル，URLを貼る時には説明を
- 複数個写真やファイルを貼る時はスレッドを活用する
- 返信は絶対にスレッドに書く
- 返信をチャンネルにも投稿したい時には，スレッドを使いつつチャンネルにも投稿できる機能を使う
- 全体メンションは適切に
- 個人メンションは気軽に
- リアクションはこまめに，但し必ず相手に伝わってほしい時は返信を用いる
- 他の投稿を引用する時はリンクを用いる
- 太字など投稿が見やすくなる工夫をする
DMについて
私もよく使ってしまうが，DMはあまり使わない方が良い．
slackにおける会話でなるべくDMを避けることで
- プロジェクト全体における情報の共有が促進される
- 第三者が意見を出せる環境ができるので問題解決の糸口が見えることがある
等のメリットが得られる．
というか，DM多用する人がいるとそれだけで連絡が行き届かなくなってプロジェクトの運営が回りづらくなるので本当にやめてほしい(切実)．
もちろん，他メンバーに聞かれたくない会話など，必要な時はDMは使うべきである．
おわりに
今回書いた内容をプロジェクトメンバー全員が守ってslackを運用していけば，きっとストレスフリーなslackができるはずである...きっと...．
どうかこの記事を読んだ皆様もこの期に自分のslackの使い方を見返してみて欲しい．
FRCのロボットを作り始める前に知っておくと少し幸せになれること①
始めに
この記事は私が2018年、2019年にFRC(First Robotics Competition)に参加してみて「これ最初に知りたかった...」と思ったようなことを備忘録的に適当に列挙していくだけの記事である(FRCについての説明はしないので大会の内容について知りたい人は適当にググってほしい)。
私は主にハードの開発を行っていたのでハード関連の事しか書けないのはご了承頂きたい。
また、これは私の経験に基づいており、情報が古くなっている可能性があることも始めに断っておく。
尚、①とあるのは次の記事を書くモチベを保つためであり、②を書くかどうかは未定である。
大会側から貰えるロボット部品について
大会側からはFIRST Choiceで2回、Kit of Partsで1回部品を貰うことができる。
FIRST Choiceについて
https://www.firstinspires.org/sites/default/files/uploads/frc/2020FIRSTChoiceProcess.pdf
FIRST Choiceとは、ざっくり言うと用意された部品リストの中から自分たちが欲しいもののリストを優先度順に作り、それを元に抽選で部品が送られてくる、といったシステムである(部品のCostなど細かいルールは省く)。
これの何が問題かというと、第1回のFIRST Choiceはルール発表前に行われる(11月後半～12月とか)ので、微妙に大会準備に忙しい時に突っ込まれる上、割と時間がかかる。
かなり重要な部品も貰うことができるのでPriority list は日程をきちんと確認し余裕を持って作成すべきということを頭に入れておいてほしい。
また、人気の部品はPriorityを高めにしても抽選に外れて貰えないし、人気の無い部品は最下位に入れてても来る。そういうものだと思って割り切って考えよう...。
ちなみに私のおすすめはmotor controllerです。
Kit of Partsについて
https://www.firstinspires.org/robotics/frc/kit-of-parts
その年のルールが発表されてシーズンが始まると、大会からKit of Parts(しばしばKOPと略される)というロボット部品のセットが送られてくる。
特に初めて参加するチームにとってはマイコン、配電盤等々等々重要な部品のセットとなる。
さて、他にアメリカで部品を買うときにも言えることだが、KOPも恐らくアメリカから発送するのでルール発表から1~2週間くらいかかって届く。遅い...。
そのため、シーズンが始まってから1~2週間は物理的に虚無なのでちゃんとやることを決めて日程を組んで無駄にしないように対策しておいた方が良いと思う。
また、KOPの中身は届いたら全て確認した方が良い。不備の確認もそうだが、部品ショップの割引クーポンなども入っていることがある。
BOMについて
BOMはロボットに使った部品をリスト化して全体にかかったコストを明確にするための書類であり、大会に出場する際に提出しなければいけない。
これは最初期の段階である程度作り始めることを強くお勧めする。
私はそれをサボった結果2019シーズンの最後の方はずっとリストを作っていた。技術系のリーダーだったはずなんだが...不思議だなぁ...。
リスト化をサボっているとうっかりロボットにかかったコストが規定をオーバーしていたりとろくな事がないので(実体験)、これは本当にやっておいた方が良い。
ちなみにKOPなどの部品はロボットにかかったコストに加算されなかったりするので、そこは注意してルールを読んでほしい。私は一部の部品をKOPのものと入れ替えたりすることでコストオーバーを防いだりした。がんばった。
部品購入について
FRCは使える部品が指定されていることが多く、しかも日本では買えないものばかりの地獄なのでショップを把握して計画的に購入しよう。
基本的にどのショップも全然届かないし送料が高い。
Andymark
大体の部品はここで買える。他社製品のものはいいとして、Andymark製のもの(アルミフレームやギアボックスなど)は曲げが適当だったり説明書がガバガバだったり色々雑で実にAmericanなので注意。
VEX Robotics
Andymarkよりちょっと高級で割と使いやすいものが売っている。私が参加したシーズンではこことAndymarkしか使わなかった。
ストアをアメリカやオーストラリアなどに切り替えることができ、切り替えるとなかった在庫が出現したりする。あとどこかのストアは日本に発送できなかったので注意(どこだっけ...)。
REV Robotics
売っているものが他と同じなので特に利用したことはない。chromeでuBlockが動いているとブロックされてサイトがとても見にくくなる。
CTR Electronics
同じく利用したことはない。部品のデータシートなどが他に比べて豊富な気がするのでそれでよく使う。
ヤードポンド法
アメリカの大会なので永遠にヤードポンド法が付き纏ってくる。ルールもインチとポンドで書いてあるし(隣にメートルなどで補足されていることが多いが)、部品もヤードポンド法基準だし、他チームにはヤードポンド法を基準に会話しないと伝わらない。
最悪なので覚悟しよう。あとインチのねじ穴に普通のねじを入れようとするのはやめよう。私はそれでモーターのタップを破壊した。
Chief Delphi
チーフデルファイと読むらしい。FRCの電子掲示板である。
これは本当に役に立つ。わからないところを適当にここで調べてみると大抵誰かがスレを立てていて誰かが話している。
本当に何でもある。ルールの解釈やプログラムの話など、自分のチームが開発した技術の説明やどうでもいい雑談まで、様々な話がされている。
チーム間の交流が盛んで様々な情報がオープンなFRCの良さがここにあると私は思う。
ということで活用しよう。正直このブログを見るくらいならchief delphiを見て。
ロボットのバンパー
ロボットにバンパーをつけるのは毎年変わらないルールであり、バンパーには色々と規定がある。
バンパーは毎試合激しくぶつかるため丈夫に、付け替えが多いため取り外ししやすいものにしなければいけないが、それが難しい。また、チーム番号をつけるのも難しい(未だにどうやってやるのが正解かわからない)。
色んなチームが色んな方法で作成しているので調べてほしい。chief delphiにも沢山スレが立っている。
バンパーの作成は後回しになりがちだが、どう作るかをはじめから話し合っておいた方が良いと思う。
結論
長くなってきたので一旦ここで終わりにする。
結論としてchief delphiを見れば良い気がする。chief delphiを見ればなんとかなる。FRC興味ない人が見ても多分楽しいからchief delphiを見よう。
ボルト穴のサイズ宗教
ボルト穴
ボルト穴、ねじ穴、バカ穴、取付穴、貫通穴、、、、、、
これくらい言えば大体何の話をしているのか分かったと思うが、
「部品同士をボルトを使って固定する際に開ける穴」の話をしたいと思う。
そもそも、どれが正式な呼び方なのかはわからないし、個々によって微妙に意味が違う気もするがとりあえず今回はボルト穴で通そう。
なお、これから語ることはほとんどソース無しに語っているので間違っていても許してほしい。そして指摘してほしい。
ボルト穴のサイズには宗派が存在したのか
ボルト穴のサイズには宗派が存在したらしい。
この話の事の発端は先日の私のツイートを見てもらえばわかると思う。
M3のボルト穴はΦ3.2が常識だと思っていた私にとって寝耳に水の話であった訳だ。寝耳に水は言い過ぎたかもしれない。しかし驚いたことに違いはない。
驚いたのでアンケートも取ったりした。
母数が少ないので割合で判断することはできないが、少なくとも私のフォロワーの中の3人はΦ3.5で開けているらしい。マジか、、、
よく考えてみればどこかに明記されてるところも見たことないしこれは宗教戦争に発展か..........？
ちゃんと調べろ
そうやって安直に宗教戦争に発展させるのがよくないのです。いやほんとに。
ツイッターでワーワー騒いでいたら、素晴らしい先輩がJIS規格にあったぞとリプしてくださった。持つべきものは良き先輩である。
実際のJISのPDFは持ってくることができないので気になる人は勝手に調べてほしい。下にJIS規格を元にした資料のリンクを貼っておく。
https://www.iwata-fa.jp/html/technicaldata/tec_other_10.pdf
見てもらえばわかる通り、M3ボルト用の穴の規格は1級がΦ3.2、2級がΦ3.4、3級がΦ3.6と記されている。ここでいう1級2級3級はiso273-1979の中にあるfine、medium、coarseの事だぜって書いてあったけどイマイチよくわからない。まあ品質みたいなところだろう。
とりあえず、JIS規格こそが全て！やはり精度が一番高い1級の規格に従っている私達が正義なのだ！！！
だから待て
この流れ飽きたとか言わないでほしい。
さて、JIS規格だけ見つけて満足せずにもっと色々調べてみようではないか。
https://www.nbk1560.com/resources/other/article/technical-22-dimensions-of-holes-for-hexagon-socket-cap-screws/?SelectedLanguage=ja-JP
鍋屋バイテック・・・Φ3.4
http://www.mitsubishicarbide.net/contents/mmc/ja/html/product/technical_information/information/hexagon_socket.html
三菱マテリアル・・・Φ3.4
http://www.al-plus.jp/service/al_box/a_data/h_size/index.html
Alumi-Plus・・・Φ3.2
http://www.mekatoro.net/digianaecatalog/kg-stockgear/Book/kg-stockgear-P0535.pdf
メカトロネット・・・Φ3.4
http://www.tokyo-sekkei.com/HP%20tokyo-sekkei/01_JIS_NEJI/01_jis_sun_zu_hyou_htm/jis_kiri_neji_zu_sun_hyo/dh2_ana_1-68_zu_sun_hyo.htm
東京設計センター・・・Φ3.4
https://cp.misumi.jp/tech/tech2.html
MISUMI・・・Φ3.5
父親（？）・・・Φ3.2~3.5
あっあれ、、、、、、おかしいな、、、、、、割と有名企業の中でも値がまちまちだ、、、、、、、というかΦ3.4が優勢、、、、？
ボルト穴をどう使う？
話は少し変わるが、はじめに載せたツイートは普通にサークルの先輩に捕捉され、「加工精度と加工速度との兼ね合いから、ボルトの固定のみによる位置決めを避ける設計にして最低限の固定だけしている（意訳）」という答えを頂いた。
、、、少し極端な例を出そう。その辺にあったHAKKOのはんだごての画像を下に貼る。
ここに使われているボルトは、当然割れ目で分かれる２つの外装を固定する役割を持っているわけだが、果たしてこのボルト穴にギリギリの精度が必要だろうか？
この２つの外装は、接点に多少の凹凸があり、嵌め込むことができるようになっているだろうことは容易に想像できる。
だとすれば、ボルト穴がボルトの径ギリギリになっていなくても問題なく固定できるはずでは？
そもそもボルトの役割は回転軸と平行な方向の固定であって垂直方向の固定はあくまでついでであり、それに頼るのはあまり良くないように思える。
先ほどの例は少し極端だが、要は垂直方向の固定は別で補えばボルト穴の精度はほぼ関係ないはずである。
嵌め込み式にせずとも、他の２方向にもボルトを付け足せば良い話だ。
邪推
1つ前の話に戻るが、様々な企業のボルト穴のサイズの基準を調べた結果、Φ3.4がかなり優勢であった話。
結局その理由はこれにあったのではないか。ボルトの回転軸に垂直な方向の固定は普通の製品にとってあまり必要ではないからJIS規格でいう2級のサイズを主に扱っているのでは...なんて邪推をしてみる。
精度出さなくていいならコスト削減にもなるし。
真相はその道の人に聞いてみないとわからない。誰か教えてください。
結局宗教では？
いやでも私が作ろうとしてるの競技用ロボットだし。製品なんて関係ないし（without 身も蓋）。
実際ボルト穴のサイズを大きくすることの利点は加工精度が悪くても使えるってことだけであり、加工精度さえよければサイズが小さくても何ら問題はないはずである。
むしろ全方向の固定ができるんだからお得じゃん。
剛性も高くなるじゃん。
無駄に違う方向の固定用のボルト増やす必要もないじゃん。
ということで私はΦ3.2の方が好きです。
しかし、Φ3.4でもΦ3.5でも全く問題ない。結局のところ人の好き嫌い、宗教の問題。
というのが今回の結論だ。
うーーーんなんだか不完全燃焼感が否めない。
何か合理的な説明ができる人がいればぜひぜひコメントしてほしい。
よろしくお願いします、、、、、、、。
Ubuntuがまた起動しない
起きたこと
またubuntuが起動しなくなった。どうして、、、どうして、、、。
実験
そもそも今回はクリーンインストールして数日しか経っていない。容量不足とかそういう問題でもないわけだ。
さて、前回同様recovery modeを開き、
resume(通常の起動を再開)を選択するとなぜか普通に起動した。
???
どうして、、、どうして、、、。
どうやらrecovery mode経由でないと起動しないらしい。正直今回は何が起こっているかわけがわからない。
解決
唐突だが解決した。
ubuntuが起動しない問題でggるといくつかwaylandを無効にすると起動したという記述を見るので、試した所起動した。
具体的には、/etc/gdm3/custom.conf内の、#WaylandEnable=falseという記述のコメントアウトを外すと解決した。
recovery mode経由だと起動した原因は結局よくわからない。もう少し調べてみるか、、、。
Ubuntuが起動しない
起きたこと
再起動時に特に予兆もなくUbuntuが起動しなくなった。
原因
結論から言うと、Ubuntuに割り振ったパーティションの容量が一杯になっていた。
再起動前に大量のデータをダウンロードした訳でもなかったのだが、、、。
結論に至った経緯
boot画面までは起動したので、Advanced options for Ubuntuから
recovery modeを開き、
以下の画面からsystem-summaryを選択すると、
次のような情報が得られた。
/dev/sda6の部分が100%使われている。言わずもがなここはUbuntu用の領域である。結局のところ容量が足りていなかった訳である。くどいようだがそこまで一気にデータを増やすような行いをした記憶はない。←再起動前数日PCをつけっぱなしだったのがlogを膨れ上がらせる原因になったのか、、、？
さて、先程の画面に戻りrootを選択すると、root権限でコマンドが使えるようになる。そこでduコマンド等々を使って色々調べた所、/var/log/syslogが約50Gほどの容量になっていた。ログファイルでこれほどの大きさになるものなのだろうか、、、。
対策
暫定的な対策としてコマンドラインからいらないディレクトリを適当に消去し20Gくらい開放すると、問題なく起動した。結局その後色々あり、クリーンインストールしたのだが
また、Ubuntuのインストール時にパーティションで区切る際に、システム領域とデータ領域を分割すれば起動しない問題は発生しないように思われる。
あとはそもそもUbuntuに割り振る領域を増やしておくことも必要か。
