【Rails】deviseで用意したログインAPIを叩いた際、見知らぬパラメータが渡っていた
RailsにてGem deviseで認証機能を実装した際、ログイン時のpostで謎のパラメータが渡る問題に直面。
その解決法をメモします。
謎のパラメータが渡る
ログインするためのAPIを叩いたところ、エラーがかえってきました。
Processing by DeviseTokenAuth::SessionsController#create as HTML
Parameters: {"email"=>"test1@example.com", "password"=>"[FILTERED]", "session"=>{"email"=>"test1@example.com", "password"=>"[FILTERED]"}}
Unpermitted parameter: :session
原因はUnpermitted parameter: :sessionにあると。
しかしAPIを叩く際にsessisonという名のパラメータは渡していません・・・。
Railsの仕様だった
こちらの記事に答えが書いてありました。 paramsとwrap_parameters
コントローラのparamsには、"user"というキーが自動的に付きます（値がラップされます）。これが、ActionController::ParamsWrapperの機能です。
ひえーなるほど。
つまり今回はSessionsControllerなので、sessionでラップされたパラメータも自動で用意されていたというわけです。
脱線しますがストロングパラメータを下記のように書けるのはこの機能のおかげだったのですね。
def user_params params.require(:user).permit(:name, :email) end
解決方法
独自のSessionsControllerを用意する
deviseのSessionsControllerを継承した独自のコントローラーを用意。
その際にwrap_parameters format: []を差し込むことで、パラメータにsessionが入らなくなります。
class Api::V1::Auth::SessionsController < DeviseTokenAuth::SessionsController wrap_parameters format: [] end
ルーティングの修正
先ほど作成したコントローラーが呼ばれるように、routes.rbを修正。
Rails.application.routes.draw do mount_devise_token_auth_for 'User', at: 'api/v1/auth', controllers: { registrations: 'api/v1/auth/registrations', sessions: 'api/v1/auth/sessions' #追加 } end
これでsessionというパラメータが入ることなく、emailとpasswordでログインできました。
ZennとはてなブログをGit管理することにした
エンジニアにとって記事を書くということは日常茶飯事だと思うのですが、みなさまはどのように管理されているでしょうか。
私はmarkdownエディタ（Obsidian）で下書きし、ブラウザ上のエディタにコピペして投稿していました。
先日同僚のテックリードと雑談したところこんなお言葉をいただきました。
「自分はZenn cliを使っていて、自動で投稿されるようにしています。」
「Github Actionsでtextlintを走らせて、自動で文章の校正をしています。」
この記事は、なにそれイケてる!!と思いその環境を導入した話です。
Zennとはてなブログの使い分け
技術的な話以外のことを書きたいときははてなブログを利用しています。
そのためどうせならどちらも管理したいな..というのを目指しましたが、結局はてなブログに関してはvscodeの拡張に頼ることにしました。
ZennをGithubで管理する
この環境でブログを投稿するまでの流れは下記の通りです。
1. ブランチを切る 2. コマンドでファイル作成 3. 記述 4. git add して commit して push 5. PRを作成するとtextlintが走り自動で文章チェックが入る 6. 通ればmainブランチにマージ 7. 自動でZennに投稿される
Zenn CLIの導入とGithub連携
ZennにはZenn CLIが用意されており、ローカルで作成・編集・プレビューを行なうことができます。
さらにGithubと連携することでmainブランチ（設定可）に差分があると自動で投稿してくれます！
Zenn CLI
Github連携
コマンドでファイル名にハッシュを含む新しい記事を生成。
npx zenn new:article
また下記コマンドで、Zennでどう見えるのかをローカル環境で確認できます。
npx zenn preview
Github Actionsでlinterを走らせる
次にlinterの設定。
textlintというツールがあり、走らせることで書いた文章を自動でチェックしてくれます。
SmartHRが校正ルールプリセットのnpmパッケージを出しており、なんかよさそうだ！と思ったのでこちらを使用しました。
https://www.npmjs.com/package/textlint-rule-preset-smarthr
またtextlintはtextlint-rule-prhという表記揺れを防ぐ設定を行なうこともできます。
こちらもSmartHRで用意されているものを使用しました。
https://github.com/kufu/textlint-rule-preset-smarthr/tree/main/dict
reviewdogを使う
textlintの実行結果のログをみてその位置を追うのは辛いので、PRに自動でコメントがつくようにreviewdogを使用。
便利すぎ。
https://github.com/reviewdog/reviewdog
実際に自動投稿してみる
まずはテストで「。」がない文章を投稿してみます。
すると
しっかり自動でレビューが入りました。
これを修正してマージすると・・・
投稿されている！
これは未公開の記事ですが、CLIで生成されるファイルのメタ情報にpublished: trueを指定すると公開記事になります。
--- title: "github連携テスト" emoji: "🐈" type: "tech" topics: [] published: false # <-これ ---
vscodeの拡張
Zenn Editorという拡張も導入しました。
書きながらとなりにプレビューを置けるので非常に便利です。
https://marketplace.visualstudio.com/items?itemName=negokaz.zenn-editor
はてなブログを管理する
次にはてなブログです。
githubと連携するにはpush-to-hatenablogを使うとよさそうでした。
https://github.com/mm0202/push-to-hatenablog
ただDockerを利用する必要がありそうで、そこまででもないんだよな〜という感じがあり、使用を断念。
vscodeの拡張で投稿できる
hatenabloggerという拡張があり、これを使うことでvscode上から投稿できるとのこと！
設定もお手軽なのでこちらを利用することにしました。
https://uraway.hatenablog.com/entry/2018/12/12/001545
textlintをpre-commitで実行する
(こちらの項で設定しているhuskyはreviewdogの良さを消してしまうため使用しないことにしました。もし使ってみたい場合は参考にしてください。)
はてなブログの場合、Zennと投稿までの流れが変わります。
1. ブランチを切る 2. .mdファイル作成 3. 記述 4. git add して commit して push <- もはやしなくてもいい 5. vscodeのコマンドパレットで投稿
vscode上で完結するため、「CIが通ったらマージして~」というフローがありません。 なんならgitで管理する意味を少し失いそうです。（笑）
そこでhuskyを使用し、commit時に自動でtextlintを走らせるようにしました。
投稿するのは必ずcommitしてからという自分ルールを決めて・・・。
パッケージをインストールします。
yarn add -D husky lint-staged
.huskyディレクトリ作成。
yarn husky install
package.json
articles/*.mdはzenn、hatena/*.mdがはてなブログの記事です。
"scripts": { "lint": "textlint 'articles/*.md', 'hatena/*.md'", "lint:fix": "textlint --fix 'articles/*.md', 'hatena/*.md'", "prepare": "husky install" }, "lint-staged": { "*.{md}": [ "yarn lint" ] }
.husky/pre-commitを作成。
yarn husky add .husky/pre-commit "yarn lint-staged"
これでcommit時にtextlintが実行されるようになりました。
ちなみにこの記事を書き終えたときに実行されたものです。
めちゃくちゃ怒ってくれました。
yarn run v1.22.4
$ /Users/shibuya.kyohei/work2/zenn-docs/node_modules/.bin/lint-staged
✔ Preparing lint-staged...
⚠ Running tasks for staged files...
❯ package.json — 2 files
❯ *.md — 1 file
✖ yarn lint [FAILED]
↓ Skipped because of errors from tasks. [SKIPPED]
✔ Reverting to original state because of errors...
✔ Cleaning up temporary files...
✖ yarn lint:
error Command failed with exit code 1.
$ textlint 'articles/*.md', 'hatena/*.md' /Users/shibuya.kyohei/work2/zenn-docs/hatena/management_article_by_github.md
/Users/shibuya.kyohei/work2/zenn-docs/hatena/management_article_by_github.md
3:38 error 文末が"。"で終わっていません。 smarthr/ja-no-mixed-period
9:9 ✓ error ！！ => !! smarthr/prh-rules
12:16 ✓ error ひらがなで表記したほうが読みやすい形式名詞: 時 => とき smarthr/ja-keishikimeishi
33:43 ✓ error 行う => 行なう
「行なう」を使用する smarthr/prh-rules
38:30 error 文末が"。"で終わっていません。 smarthr/ja-no-mixed-period
42:23 ✓ error 【dict2】 "することができます"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict2 smarthr/ja-no-redundant-expression
53:41 error 【dict5】 "設定を行う"は冗長な表現です。"設定する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5 smarthr/ja-no-redundant-expression
53:44 ✓ error 行う => 行なう
「行なう」を使用する smarthr/prh-rules
65:18 error 文末が"。"で終わっていません。 smarthr/ja-no-mixed-period
94:44 ✓ error 【dict2】 "することができると"は冗長な表現です。"することが"を省き簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict2 smarthr/ja-no-redundant-expression
118:11 error 文末が"。"で終わっていません。 smarthr/ja-no-mixed-period
122:14 error 文末が"。"で終わっていません。 smarthr/ja-no-mixed-period
141:20 error 文末が"。"で終わっていません。 smarthr/ja-no-mixed-period
✖ 13 problems (13 errors, 0 warnings)
✓ 6 fixable problems.
Try to run: $ textlint --fix [file]
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
husky - pre-commit hook exited with code 1 (error)
修正してcommitが通れば、あとはコマンドパレットからHatenablogger: Post or Updateを選択して投稿します。
ちなみにエラー文のフォーマットは好きなように変更でき、下記のようにして指摘箇所が見やすくなります。
textlint -f pretty-error 'articles/*.md', 'hatena/*.md'
git管理する意味ある？という懸念
vscodeで完結するのでgit管理する意味がないように一瞬思いました。
ターミナルでyarn lintを実行すれば同じです。
ただ私が使用するデバイスが複数あり、同期したい気持ちもありました。
そういった意味だとgithubに置いておけばpullするだけで環境が同期できて便利になります。
振り返り
「記事を書く環境がなんかモダンぽい！」という自己満もあるのですが、総じて良かったなと感じたことが２点あります。
下書きという概念がなくなった
今まではWEBエディタでチェックして細かい修正があればその場対で修正していたため、下書きと実際の内容に差分が発生しており、あまりObsidianに記事を残す意味が感じられませんでした。
今回の方法だとvscodeで修正したものが本番のものと同じになるので余計なファイルが存在しなくなります。
vscodeで書く理由ができた
特にvscodeでmarkdownを書く理由はなく、これまでいくつかのmarkdownツールを触ってきました。
しかしZenn Editor、hatenabloggerの存在がvscodeと他のツールを差別化する起因となり、ここに落ち着くことができました。
また改良を重ねるかもしれませんが、いい体験になることが期待できます。
あとGithubに草も生えるしなんかいいよね。
追記
最終的にlinterの実行はhuskyを使わずにすべてreviewdogに任せることにしました。
自動でレビューされた内容をvscodeの拡張、GitHub Pull Requests and Issuesを使って修正時に怒られている箇所を特定しやすくしています。
リモート会議におけるホスピタリティ
一昨年に株式会社diddyworksに入社後、今でもパートナーとしてお世話になっているオフィスに一ヶ月間在籍しました。
その後仙台に戻り、リモートワークについての学びや知見が得られたので今更ですが書き留めておきます。
※ここでのリモート会議は全員がリモート参加ではなく、一部のメンバーがリモートだった場合を指します。
リモート参加で気になったこと
私は３つのことが気になりました。
- リモート参加が少数派になると会話の入り方が難しい
- 全員の声が均等に聞こえない（これが結構辛い）
- マイクが声を拾っていないが、その状況が現場側に伝わっていない。（多くは機材トラブル。会議は始まっている...ということも）
当然ですがこれらはリモート側にしか分からない状況です。
現場側は最初の確認さえできていれば疎通がとれているものとして会議を進めるため、声をあげないと改善されることはありません。
どうすればいいか
何らかの手段を利用して、現場側に教えてあげれば大体解決するかと思います。
現場側は会議の質を高めるために必ず対処してくれることでしょう。
一番の問題
というのは当たり前の話で、一番の問題はリモート側が声をあげることに対して心理的ハードルが高い場合があるということ。
実際私一人だけがリモート参加だった時はなかなか言い出せず、内容があまり聞き取れない状態だったことがあります。
またリモート側の会話（入り込み）の少なさも目立つようになりました。
発言前に「いいですか？」と割り込めば大体聞いてくれる
私は逆の立場も経験していますが、リモート側の発言は貴重に感じるような気がしています。
会話に入りづらい状況下で割ってでも話したいことがあると感じるからかもしれません。
ラグで現場の会話と被ることも懸念されるかもしれませんが、気にせずどんどん割り込んでいきましょう。
きっと現場はリモート側の意見を求めているはずです。
またカメラはできればオンをお勧めします！
ノンバーバルコミュニケーション（非言語コミュニケーション）という言葉があるくらい、表情には意思を伝える力があるそうです。
ところがカメラがオフだと現場の人間も話しかけるのが億劫です。
リモートの人数が増えるほどオフ率は高くなりがちかと思いますが、できる限りオンにしておきましょう。
現場側は？
状況にも寄りけりですがこまめな意思確認をおすすめします。
リモートへの意思確認は後手にまわることが多いのですが、ある程度話した後に「○○さんはどうですか？」と聞かれても大体は「はい、それで大丈夫です。」という返答になります。
会議で心理的なリスクが少ないのはほぼ間違いなく現場側かと思うので、積極的にリモート側と会話する機会を作ると良いと感じました。
双方が協力しないとリモート会議は成り立たない
どちらか一方が改善するのではなく、互いにホスピタリティを持って臨まない限り良い会議は実現しないと考えています。 ちなみに前述で気になったことを並べましたが、私の場合は都度現場の方から確認があり、その度に改善していただきました。
diddyworksの取り組み
弊社は社員の９割が宮城県民ですが、メンバーの一人、佐野さん（@snyt45）は宮﨑県からのフルリモートワークです。
そして彼自身リモートワークをより良いモノにしようと動いていて、最近ではGoogle Meet内でslackのカスタム絵文字を投稿できるchrome拡張を開発していました！
現場も意思確認がとれやすく、誰かがスタンプしたら自分も押したくなってしまう相乗効果もあって本当に素晴らしい拡張機能です👏
（現在は一部のユーザーのみ使用できます）
こうした働きかけは会社に大きな影響を与えたと思いますし、現場側の自分たちも常に改善に向けた動きをしていく必要があります。
最後に
弊社diddyworksはこれまでずっとリモートワークを実践している会社です。
そのためリモート会議の在り方の追求や、バーチャルオフィスの使用・改善を日々行っています。
現在エンジニアの募集を精力的に行っていますので、そんな弊社を少しでも気になってくださいましたら下記リンクの採用ページをご確認ください！
ほんとお気軽に応募してください！お待ちしています！
約一ヶ月、ほぼ毎日p5.jsの記事を書き続けた感想
毎年大盛況のQiitaアドベントカレンダーですが、今年は自分でカレンダーを立ち上げました。
その名もp5.js Advent Calendar 2021。この記事はその25日目、最終日の記事です。
約一ヶ月間、毎日p5.jsを触ってみた感想。他の言語とざっくり比べてどうだったかを書きました。
p5.jsを一ヶ月さわってみて
これまでいろいろと挫折してきました
私はこれまでクリエイティブコーディングをとにかく触りだけやってきました。
Quartz Composer、Processing、TouchDesigner・・・。
全て中途半端で投げ出してしまいました。
Processingはコードがほぼ読めない時代に触り、ほぼ何も分からない状態で終了。
TouchDesignerも本腰を入れてやろうと思ったのですが、なんたるかを掴むことができず挫折。
しかし元々表現を形にすることは好きで、なにしよっかなーと考えた結果手を出したのがThree.js。
しかしまさかの環境構築で燃え尽きてしまいました。（笑）
TouchDesignerもそうですが、どんなものでも描画するときには必ずScene、Mesh、Cameraなど必要なものが多いのです。
甘ちゃんですがお手軽さはそこになく、だったらTouchDesignerでよかったのでは...とだんだん気持ちが離れてしまいました。
p5.jsに出会う
それでもThree.jsを諦めず、本屋さんで参考書を探すことに。
そこで見つけたのがGenerative Design with p5.jsという本でした。 冒頭数ページのアートに心を奪われてしまい、即購入。p5.jsをやってみることに。
驚くほどシンプル
本業でJavaScriptを書いているので言語のお作法がある程度分かるというのもあるのですが、とにかくスラスラと頭に入ってきました。
p5はsetup関数でcanvasを作り、draw関数で描画するというとてもシンプルな構造です。 お手軽さも十分なため、いろんな関数をどんどん試して遊ぶことができました。
Processingがだんだん読めるようになる
p5.jsはProcessingをJavaScriptで書けるように移植されたもの。
そのため用意されている関数がほぼ同じです。
twitter界隈では#つぶやきProcessing というハッシュタグがあり、コードと描画されたものを添付してツイートしています。
#つぶやきProcessing
— Koma Tebe (@KomaTebe) 2021年12月24日
t=0,draw=n=>{for(t||createCanvas(W=500,W,WEBGL,S=stroke),background(0),rotateY(.1*t),translate(0,-100),i=0;i<W;i+=2)S(0,q=100*sin(i/33+t)+150,0),x=i/2*cos(z=i/15),z=i/2*sin(z),line(0,i,0,x,i/.6,z),S(q),point(x,i/.9,z),line(0,-44,0,x/6,33*sin(i)-44,z/6);t-=.05} pic.twitter.com/aJhgeJHRUj
コードをみて「この関数を使って表現してるのかー」というのがなんとなく分かります。
このコミュニティを知れたこと、Processingが少し読めるようになったことは嬉しい誤算でした。
3Dの描画も簡単
アドベントカレンダーの中でもp5.jsで3Dモデルを描いてみるという記事を書きましたが、
Three.jsに比べて描画までのスピードが圧倒的に違いました。
その分Three.jsやTouchDesignerのほうができることは多いみたいですが、とっかかりとしては間違いなくp5を推せます！
クリエイティブコーディングの入り口はp5.jsをおすすめします
これが一ヶ月さわってきた結論です。 もちろんjava経験者の方はProcessingが良いと思います。
この期間で
- クリエイティブコーディングってこういうものなんだ。
- 数学がこういうところで使われるんだ。
- こういう仕組みで描画されているものが動いて見えるんだ。
という基礎的なことを体系的に学ぶことができました。
ただ入り口だからと言って決して出来ることが少ないわけではありません。 あくまでクリエイティブコーディングの入りとして最適だと思った、ということを言いたく、 そこからの可能性は無限大です！！
次の章はアドベントカレンダーの感想になるので、あまりp5は関係ありません。 興味がある方は読んでみてください。
おもむろに始まったほぼ一人アドベントカレンダー
今年の11月下旬、Qiitaアドベントカレンダーの熱気が徐々に増す中、「カレンダーになんか投稿してみよっかな」という軽い気持ちで「p5.js アドベントカレンダー」を探しました。
そしたらそのカレンダーがないではありませんか！
これはチャンスだと思い、p5.js Advent Calendar 2021を作成しました。
作った時は
「え、俺がライブラリ名を冠したカレンダー作っていいの？」
「恐れ多いわー！」
など、ドキドキワクワクでした。
しかし一向に参加者が現れません。
twitterでも呼びかけましたが増えません。
違う意味でドキドキワクワクとなってしまいました。
毎日１記事を書く辛さ
きつかったです。まず記事のストックが一切ない。ネタもない。日々記事を書く人間でもない。
p5.js初心者で、レベルが高い知見についても書けないのが正直なところでした。
ということで初学者が学んでいく様を記事にしていくしかなく、 結果的にほとんどの記事が「関数まとめ」というタイトルになりました。
また記事を書く中で技術の壁にぶつかった時は焦りを感じました。
例えばp5.jsの関数まとめ part.10 sin()では数学のsin, cos（サイン、コサイン） を利用します。
私は数学から逃げてきた人間のため「ほんとに分からん！」状態。
しかし毎日が締め切りです。 プログラミングに一切関与しない数学に関する記事やYouTubeで勉強し、夜中3時くらいまで粘って記事を書いていました。 その記憶を残すためにクリエイティブコーディングのためにsin, cosを学ぶという記事を書いたのも良い思い出です。
余談ですが、このとき「あれ？数学学ぶのが苦じゃない。むしろ面白い。」と思えたことに驚きました。 中学生の頃数学が嫌いすぎて「学ぶ必要あるんか」と泣いたこともあるくらいの私が。 奇跡的な気づきをありがとうp5（Processing）。
参加者現る！
大体10日目くらいになった頃、なんと参加者が！ おこがましいですが初めて友達ができた、そんな感覚でした。
参加してくださったのはyoutoyさんとdeconbatchさん。 クリエイティブコーディングの分野ではすでに活躍されている方々で、 deconbatchさんのブログ、deconbatch's Land of 1000 Creative Codings.は私も読んだことがありました。
このお二人に参加していただけて本当に光栄で嬉しかったです。
ありがとうございました！
投稿していただいた記事はこちら↓
youtoyさん
【p5.js 2021】Magenta.js の MusicVAE を使った音作りを試す（p5.js Web Editor上で扱う）
【p5.js 2021（2つ目）】 Leap Motion（leap.js）を p5.js Web Editor上（JavaScript）で扱う
deconbatchさん
p5.js の createGraphics() がメモリを放してくれない！
Twitterのタイムラインが変わってきた
カレンダーの記事が公開されると必ずTwitterで「○日目の記事です！」と投稿していたのですが、そのうちProcessingを触っているであろう方からいいねしていただき、フォローし、、、 を繰り返していたらいつのまにかタイムラインが#つぶやきProcessingみたいになっていました（笑）
好きが高じていくとSNSの環境も変わっていくんだなぁとしみじみ。
記事に追われる毎日だったので私も#つぶやきProcessingしたい...
確実にレベルアップしている実感
アドベントカレンダーも後半に差し掛かった頃でしょうか。 リファレンスのコードを読むのも一苦労だったのが、「読める、読めるぞ！」みたいになっていました。
仕事では初見でも大体の動きを追えるのですが、p5(Processing)が持つ関数は別世界の動きをします。
map()ときたら配列操作と思うじゃないですか。全然違うんですね・・。
そのため関数の動きを一個一個調べないと、リファレンスすら読めない状態でした。
ですがここで関数まとめをしていたことが役に立ちました。
記事を書くにつれていつのまにか基礎のようなものが出来上がっていたのです。
よく勉強はアウトプットが大事！ と言いますが、これほど実感した体験はありませんでした。
まとめ
アドベントカレンダーをほぼ一人でというのはなかなか厳しいものがあります。
しかし25日前の私と今の私でp5の知識量は大きく変わりました。
クリエイティブコーディング初学者の一番重くて辛いところをこの25日間で超えられたのではと感じています。
2回目ですがアウトプットは本当に大事！
あとはまだ知らない関数を掘って、自分が表現したいことを楽しく描画するのみです！
またp5を勉強し始めた頃、NFTが大変盛り上がっていることを知りました。
クリエイターの未来が明るくなるいいニュースですね👏
自分も成長したらいつか参入してみたいなと考えています。
最後に
Processing Advent Calendarというものがありまして、こちらは毎年盛り上がりを見せているようです！
いいなぁ、来年はここにも投稿できるように頑張ろう。
adventar.org
コマンド一発で音声の入出力を変更できるようにした
いつもbluetoothイヤホンとMacを接続して仕事をしており、 電池がなくなったら直挿しのイヤホンに切り替えています。
そのたびに設定 > サウンドを開いてあーだこーだするのが面倒だったので 一発で変更できないかを調べたところ、switchaudio-osxを利用した記事が結構みつかったので試してみました。
インストール
Homebrewを利用してインストールします。
brew install switchaudio-os
音声出力一覧
SwitchAudioSource -aで使用可能なデバイスが一覧表示されるので、ここから使用したいものを選びます。
SOUNDPEATS TrueAir2 Capture Inactive 外部マイク MacBook Proのマイク SOUNDPEATS TrueAir2 DELL S2421HS RDT231WLM 外部ヘッドフォン MacBook Proのスピーカー
出力先を変更する
たったこれだけで
SwitchAudioSource -s 外部ヘッドフォン => output audio device set to "外部ヘッドフォン"
かわった！ 設定 > サウンド を見ても変わっていることが確認できました。
エイリアスをはる
# sound # !brew install switchaudio-osx! alias sci='SwitchAudioSource -s 外部ヘッドフォン' alias scb="SwitchAudioSource -s 'SOUNDPEATS TrueAir2'"
これでsciと叩けば外部ヘッドフォンに出力先が変わるように！ scbはbluetoothに切り替える用です。
ただこれだと入力先が変わらなかったので、関数にして処理を足しました。
# sound
# !brew install switchaudio-osx!
function sci() {
SwitchAudioSource -s 外部ヘッドフォン;
SwitchAudioSource -t input -s 外部マイク;
}
function scb() {
SwitchAudioSource -s 'SOUNDPEATS TrueAir2';
SwitchAudioSource -t input -s 'SOUNDPEATS TrueAir2';
}
alias sci='sci'
alias scb='scb'
-sはデフォルトで出力先を変えるようになっているので、 入力先を変えるには -t(type) で input を指定してあげる必要がある。
$ scb => output audio device set to "SOUNDPEATS TrueAir2" => input audio device set to "SOUNDPEATS TrueAir2"
いい感じ。
会社でブログを書き始めて四半期が経過した
在籍する会社、diddyworksの中で ブログ書いてこーぜ！いえーい！ ってなってから早３ヶ月が経過したので、やってみてどうだったかをまとめます。
ブログページはこちら。
ブログの発端
パートナーでお世話になっている会社さんや、ブログの執筆活動を行う会社に憧れがありました。 ちょうど3ヶ月前に弊社では開発チームっぽいものができつつあり、今だ！な勢いで打診し、やることに。
仙台発のスタートアップは関東に比べたら少ないし、もっとアピールして会社の知名度だったり、開発チームのブランディングになればと思いました。 そして採用活動へのアプローチも。
やってみたら
目標は大体一人３記事（１ヶ月１記事）、継続して書いていこーとスタートしました。
そして１ヶ月で２記事、３記事と書き上げる猛者が現れます。 そんなにネタが。てかすごい・・。記事を書くことがすごく得意なメンバーがいるという発見がありました。 しかもこれが一人とかじゃないからまたすごい。
逆になかなかペースが上がらないも人もいます。 その一人、弊社CIOの阿部に「あなたにとってブログとは？」と聞いたところ、
「今まで書いたことがないもの、または自己表現」
という回答がありました。深いですね。
またCEOの三浦も記事を書くペースが上がらず、 週一回の定例では「書いてっから！」とジョークを飛ばしていました。 その三浦にもさきほどの質問をしたところ、
「深すぎて言語化に時間がかかる」
言葉では表現しきれない思いがこのブログプロジェクトに詰まっているのですね。
やり始めだからかもしれませんが、ペースが人によって大きく開きました。 ただ開いたからどうということはなく、会社のOKRなので全員で達成していくスタンスです。
何が良かったか
- 思い、考えを記事化することで財産が増えた感がある
- 記事化したことって頭に積まれるし、見返すときも他の記事を見返す感覚とちょっと違う
- 記事に対して社外からのアクションがあった
- 社内の人の考えを知ることができる <- これが結構いい
４つ目はいいな〜と思いました。 技術系の記事を書いている人ならばその人が興味のある技術や「やってみた」を知ることができます。 （それが結構な知識になったりする）
またインタビュー記事で知れるその人の側面やバックグラウンドが面白い。 リードエンジニアの記事なんかは開発に対しての熱さがむんむん伝わります。
今後
まだまだブランディングに一役かっているとか採用活動に直結しているという実感はありませんが、 良いサイクルで実行できていて、密かなモチベーションアップになっていると思います。 社内コンテンツが増えたことによって会話も増えたかな。
まずは引き続き継続していきたい所存です。
ちなみにdiddyworksのHPはこちらです。 チラ見してください！
デジタルデトックス
最近こんなことがありました。
奥さんに寝る前デジタルデトックスすれば朝方になるかもだし、パソコン触るの夜中じゃなくて朝の仕事前にしよって言われて試したら目覚まし無しで6:30起床に成功している。
— Kyohei Shibuya (@TENTEN11055) 2021年9月13日
夜中よりも作業時間確保できているすごい。
私は根っからの夜型人間でして、いつも奥さんと娘が寝た後、一人自室で2時とか3時までPCをカタカタしていました。 ただ翌日の寝起きが悪いのなんので辛い。
そんなときに奥さんからデジタルデトックスの進めを受けました。 ちなみに奥さんは美容師なのに脳とか神経とか骨格とかを勉強している人でして。
寝る前にブルーライトを見ないようにするだけで、 目の奥にあるなんとかっていう神経がetc（忘れてしまった…） といった感じで説明を受け、寝る前2時間くらいから携帯やPCを触らないようにしました。
さらに焚き火の音なんか流しちゃったりして、副交感神経をいい感じにして快眠状態に持っていきます。
そしたらツイートの通りで、目覚めもよく、なんかこう気分がいいのです。 思った以上に効果があり、実践する価値ありでございます。
と言いつつこれを書いているのは1時42分。 次の日が休みの時は触るのOKにしました。 明日は寝起き悪いの確定です。
