GASを利用してMattermostにリマインダーメッセージを送信する
はじめに
コミュニティ内では有志でやっている輪読会があるが、公式で管理されているイベントではないので意外と忘れがちだった。
なので当日にリマインドができないか考え、またGASを使ったことがないなと思ってスクリプトを作ってみた。
（というより最近全然プログラミングしてない！Geek Outしなきゃという使命感に駆られたため、正直後者が目的になった...）
作成したスクリプト
送信したイメージは以下のような感じ
利用した技術
- Google Apps Script(GAS)
- スプレッドシート
- MattermostのIncoming Webhook
- ソース管理にClaspを利用
概要
シーケンス図は以下の通り（スクリプトだけ渡してGPTに作図してもらった）
sequenceDiagram
participant TimeTrigger as 時間ベースのトリガー
participant GAS as Google Apps Script
participant Spreadsheet as スプレッドシート
participant Mattermost as Mattermost
TimeTrigger->>GAS: 12:00~13:00にsendReminders()実行
GAS->>Spreadsheet: アクティブなスプレッドシートを取得
Spreadsheet-->>GAS: アクティブなスプレッドシートを返す
GAS->>Spreadsheet: "settings"シートのデータを取得
Spreadsheet-->>GAS: 設定データを返す
loop 各設定の確認
GAS->>Spreadsheet: 対象のシートデータを取得
Spreadsheet-->>GAS: シートのデータを返す
loop 各イベントの確認
GAS->>GAS: 日付の一致を確認
opt 日付が一致
GAS->>Mattermost: メッセージを送信
Mattermost-->>GAS: 受信確認
end
end
end
作ってみた感想
Slack appを作成したことのある人は正直1日で理解・作成できるクオリティだと思う。
他の人も見てる自身のtimesに送信するように作ったので、そういえば今日イベントだったと思い出すことに繋がっているといいな。
追加でやるなら
今回はとても小さい機能を作ったので、GASのコード自体Git管理する必要があったのか怪しいところではあるが、複数人で開発したりもっと大規模にやるならソースコード管理、TypeScript化、Jestなどのテストコード作成も視野に入るかと思う。
ただし、そこまで行くとGASでやる範囲を超えているのでは？という感覚もある。
最後に
Slackだと/remindコマンドで一発のところを、GASを使って丁寧に（？）やるとこんな感じという知見を得た。
参考
- Claspの使い方
- はてなブログへのMermaid記法の図の挿入方法
転職して3ヶ月が経ったのでふりかえり
はじめに
転職して3ヶ月が経ったので、雑にふりかえりをする。
こう、パブリックに出すので項目・表現は優しめ。気になったところとかは捕まえて聞いてくだせぇ。
よかったこと
- 初日に半日出社しただけで、それ以降はフルリモートなので出社のストレスはなし。前職だと会社にあるPCにRDP接続している都合上持ち回りでPCのお守りをするために出社していたのが解消。リモートについてはもう少し後述。
- 自身の実装した機能が4つ程度はリリース済み。全部で10PRくらい。サービス本体以外の関連サービスも改修・リリースの機会もあった。いずれも自動デプロイなのでストレスは少ない。
- 今まであまり触れてこなかったGCPやAWSといったインフラといった要素や、アプリケーションでも巨大なコードベースを調査・改修を加えていけているという少しずつ前進している感覚はある。
- 一応試用期間は終わったので、副業とかもしようと思えばではある。
課題
- 開発タスク以外の採用やその他のタスクは取り組めておらず。どこから手を付けたら、どこに掛け合えば？状態。
- フルリモート下のコミュニケーション問題。他のチーム、部署とはほぼコミュニケーションを取ることがない。また、チーム内・近いチームでも緊急度は低いが重要度は高いような課題に関するコミュニケーションが少ない気がする。
- デカめのtoCサービスなので、考慮が足りていないと性能面で一発でやられる。
- 本を読んだり、コミュニティで輪読会は楽しくやっているものの、手を動かす系の勉強が減少傾向にある。直近でも少しGASを齧ったくらいだしなぁという感じ。
やってみること
- オフライン・オンラインのコミュニティや勉強会への参加（最近は時間当たりでのやった感が得やすいのでオフライン熱は高め）
- いわゆるGeek Out。LLMも興味ある分野ではあるのでもっと触る機会を増やす。
最後に
スクール卒ということもありコミュニティを見れば同時期に転職した人（未経験多め）もいて、焦りも感じてしまうけど成長角度や自分がどれだけ伸びたかにフォーカスしていく。
プログラマー脳読了
初めに
今年発売された本の中でも評判の良い、プログラマー脳を読んでみた。 （というか周りで良いぞという声を聞いて積読の山から手を取った感じ）
結論としては、今まで言われ続けていたことのメカニズムを知った気持ちになって面白かった。
感想
リーダブルコードやプリンシプルオブプログラミングのような書籍では、極端に言ってしまうと命名やプログラミングするときにはこうすべしと原理が書いているが、「なぜそうしなければいけないんだっけ？」があまりわからない場合が多い。
そのため、オレが読めればそれでいいという状況や、原理主義的に全てXXXすべしと曲解をしてしまうパターンがあるかと思う。
本書ではプログラミングにおける諸問題に、認知科学や脳科学の結果を用いて、
- 人間の脳にとって読みやすさとは
- 認知負荷が高まっている状態とは
- 変数とはどんな役割をしている
- オンボーディング時の新人のツラミ
といった「なぜそうやってプログラミングすべきなのか」を考える材料を与えてくれている。
熟年のプログラマーは経験則的にわかっていることではありそうだが、実際に認知科学といったエビデンスがあると、本を読みつつなるほどなと納得・腹落ちした章は多かった。
そのほかのプラクティス
端的にキーワードだけ並べると、以下。
- 脳は長期記憶・短期記憶・ワーキングメモリの3つのプロセスを使い分けている
- コードは意味のある小さいチャンクであれば記憶できる量が増える
- メンタルモデル（メリットデメリット色んな側面が語られている）
- 変数は主に11種の役割がある
結構使えるプラクティスは多いが、最後の章にあったからか、意味波の話が良かったなと。（日本語にするとエセ科学っぽさはちょっとある）
意味波は抽象→具体→抽象という学習の流れを表している。
抽象：可変長引数は複数の引数を持つ
具体：引数を「*」で始めれば定義でき、全ての引数リストを受け入れる
というPythonの例を述べている。
このアンチパターンがわかりやすく、「抽象的な話かしない」「具体的な話しかしない」「抽象→具体は落とし込めているが最終的に抽象化していない」というもの。
コーディングする上では最後のアンチパターンが厄介で、陥ると重複まみれのコードになってしまう。
考えてみる
個人的にはRuby on Railsの経験が多いため、どんなものかをザッと考えてみる。 メリットとして以下のような感じ？
- 設定より規約(CoC)をコンセプトとしていて、長期記憶を頼っている
- 暫定性を持ち、粘性も低いため、走りながらコードを自由に変更できる
一方で逆もまた然り。
- 長期記憶でヒットしない、Rails Wayから外れたコード、一時的に書き散らかしてしまったコードが多くなってくると途端に認知負荷が増大する
- 変更は手軽だが整合性が取れなくなるのもまた早い。実行時までエラーを知ることはできない
というわけで大きなRailsアプリケーションなぜ辛い問題は色々な要因がありそうだが、認知負荷の観点からも説明できるところはありそうだと感じた。
速く小さなアプリケーションを作る分にはメリットが上手く効きそう。
こちらも
前にお世話になったところでもこの書籍について話しているので、手軽に分かった気になりたい方はこちらもどうぞ
【プログラミング】読むだけで学習効率が上がるオススメ書籍 - YouTube
話は変わって
この書籍に限らず、初級〜中級向けくらいの良書が最近は多く出始めているなという印象を受ける。
設計で言えば良いコード／悪いコードで学ぶ設計入門、昨今のソフトウェア開発について述べている現代版人月の神話のような人が増えても速くならないだとか。
よわよわエンジニアなので、難しい良書との橋渡しとして大変助かる、、、
以上。
デブスト行ってきた
はじめに
数ヶ月ぶりのブログ。 転職もしたので、3ヶ月くらいの節目で振り返りを書く（絶対やるんだぞ）
参加したイベント
これにオフライン参加してきた。今年30歳なので最初で最後だなという気持ちで申込をした。
感想
スピーカーの属性としては
- 代表取締役
- 未経験から業界チェンジ→受託→自社開発に行った人
- 新卒から5年くらいやって新規事業開発に取り組んだ人
- データサイエンティスト
などなど、20代ながらバックグラウンドや職種はさまざま。
いくつかのセッションではChatGPTなどのAI技術が自分達に取って代わるかについても触れられていた。そのアンサーとしては、
- テクニカルなスキルより陳腐化しにくいソフトスキルを磨こう。
- あくまでサジェストしてくれたり副操縦士なので、説明責任を持つ。
といったものだった。確かにそう。
あとは印象に残ったのは以下。
- 新規事業に携わってみて、テクニカルなスキルだけではなく、プロダクト・スキル・チームのトライアングルが大事だと感じた。
- キャリアを綿密に計画しても何が起こるか分からないので、計画的偶発性理論に従って楽しそうな方を選ぶ。
- 他人と比較するのではなく、過去の自分からどれだけ成長したか見る。
- スキルやキャリアはそれぞれ点で表され、それらの点を繋いだ集合体のようなもの。
- 健康が大事。（マネージャーもやっている30歳の言葉は深い）
これを40,50代の人が言っていればそれはそうですね、で終わるかもだけど、同世代のエンジニアが言ってるのはエモい。 自分もとかく新卒の頃は頑張っていた、ようにだけ見えて何もわかっていないまま健康に響くくらい働いたり、受け身で言われたことをやっていた節もあったので刺さった。
一方で10代→20代でそうだったように、30歳になったから自分のレベルがいきなり上がるということはなく、結局勉強し続けて成長するしかないんだと気付いた。 懇親会でもそれこそ色んな会社の色んな職種の人と話せたし、明日からも頑張る。
公開されている登壇資料リンク
Developers Boost 2023 基調講演「激動の時代を生き抜くためにU30が身につけるべきソフトスキル」 - Speaker Deck
今後のキャリアパス、どう描く？ 20代を振り返ってみてわかる、30代を意識したキャリア戦略 - Speaker Deck
Webアプリに生成系AIを組み込む
この記事is何
最近の趣味でやっていたことネタ。
最近ウェビナーを見てても各社すごくワクワクして取り組んでいると感じたし、バリエーションが無限に広がる〜と思ったので、個人的にもOpenAI APIを試してみた。
1発目としてはコンセプトや感想をまとめつつ、技術的な部分は別途記事を作成するかも。
諸注意
バーっと作ったものの紹介なので、細かいところの説明はしない。
作ったもの
タイトル：AIトークデッキ
※APIとPaasにFly.ioを利用しているため、利用料の関係で公開停止する可能性があります。
https://ai-talk-deck.fly.dev/ai-talk-deck.fly.dev
※はてブロだとOGPのサイズダメかも、、、
概要
誰かと話すときに話題がなくて、「今日の天気はいいですね、、、」「曇ってるけど、、、」みたいになる人向けのアプリ。
キーワードを与えると、それに関連した話題をAIが作成して5個程度示してくれる。
生成した話題の詳細画面のリンクを共有すると、動的なOGPが生成されるため、よくサービスとしてある〇〇箱、マシュマロと同じような感覚で共有できる。
↓イメージ
また、FigJamやチャットに無造作に貼り付けてカードとして使える点は個人的に良いんじゃないかなと思っている。
AI使って何が良いの？
今までは管理者が用意したデータをランダムで表示するなど、管理面が面倒だったが、LLMを利用すると理論上はほぼ無限に近いようなパターンを生成できる。（が、現状の実装だと似たようなパターンは多い）
ダミーデータ生成などでもChatGPTは利用されたりするので、「全部が全部それらしいデータを頭で考えるのは面倒」という人にこんな使い方もあるよという思考の手助けになれば。
あとは開発上の観点にはなるが、AIを割とファジーなAPIとして使えるので、APIが無いからアプリが作れないといったことを解消してくれそう。
（ただし、特定のAPIにのみ依存したアプリにしてはいけないという点は昨今のTwitterAPIの仕様変更などからも明らか）
開発の観点
今回の開発上のテーマは爆速開発＋テストを書く。
爆速開発に関して、MVP自体は作成開始当日には公開した。
それができたのはアプリ自体のサイズ感とやはりRailsだったからということが大きいと思う。モノリス最強！
さらに個人で契約していたGitHub Copilotを利用することで、Railsは決まった書き方が多いことからすぐにサジェストしてくれるし、テスト（RSpec）も瞬時に提案してくれる。
この辺りは最近のAIの恩恵を受けながら開発ができた（ので、この先もやめられないだろうなと、、）。
開発者としてはアプリを高速にデリバリできるので、ワクワクが止まらない。
まとめ
アイディアさえあれば、バリエーションの面（LLM）や開発速度の面（Copilot）でアプリを作るハードルはとても下がっているように感じる。
あとはやる気と時間次第。
なので一緒に作ろうぜ、アプリ。
アサーティブ・コミュニケーション読了
初めに
前回読んだアンガーマネジメントと関連して、今回はアサーティブコミュニケーションの書籍を読んだ。
感想
今回も前の書籍同様、アサーティブなコミュニケーションとは、というところから始まり、後半になるにつれて具体のケースなどに踏み込んでいた。
「攻撃的な自己表現」、「非主張的な自己表現」、「アサーティブな自己表現」の3種類あるということが書かれていた。
攻撃的な自己表現
- 相手を抑えて自分の言いたいことを通す自己表現
- コミュニケーションのゴールが勝つことになっている
- 「頼まれたことを(意図的に)すぐにやらない」「誰かの足を引っ張るようなことをしてチームを乱す」と言った「受身的攻撃」も含まれる。
非主張的な自己表現
- 自分を抑えて相手を立てる自己表現
- ネガティブな思い込み
- 過度にへりくだったり、自己防衛的な言い訳をする
アサーティブな自己主張
- お互いの主張や立場を大切にした表現
- 相手や自分を責めない、感情的にならない
- 「言わない」という選択肢もあり
自身の振る舞いを振り返ると非主張的な自己表現しがちだなと、、
また、本書で述べられていた個人のゴールは一旦ここに据えましょうということは、なるほどと頷いた。
× 「わたしがアサーティブに伝えたのだから、怒らずに気持ちよく受けとめるべきだ。相手もアサーティブに伝えてくるべきだ」 ○ 「自分は自分の伝えたいことを、相手にアサーティブに伝えることができた」
相手をコントロールするということが終着点ではなく、自身の振る舞いに閉じるので分離ができていると感じる。
最後に
この伝え方という分野は自身のメンタルもそうだが、他者への影響の仕方にも関わるので、習得できるようにトレーニングや他の本なども見てみたい。
アンガーマネジメント入門読了
初めに
Twitterで良い入門書という声を見かけて、自分が些細なことで怒ってることが多いなと思ったので以下の本を読んでみた。 Amazon.co.jp: アンガーマネジメント入門 (朝日文庫) eBook : 安藤 俊介: 本
- 影響を受けたつぶやき
簡単に感想
入門書として、とても良かった。
読む前は「ムカつくことがあったら5秒数えて深呼吸する」くらいのやり過ごし方しか知らなかったが、小手先的なテクニックというよりは怒りの発生するメカニズムから説明されたので、スッと入ったのだと思う。
簡単に、怒りが発生する順序は以下。
- ある出来事に遭遇する。
- 自分の中にあるコアビリーフ（個人が正しいと思っており、その人の中核にある信念や価値観のこと）によって出来事の意味づけを行う。
- 2.による意味づけを行った結果、許せない場合には怒る。
2.のコアビリーフというのが曲者で、一般論や定量的な数値などではなく、あくまでその人の主観。
この自身の中の考え方などが歪んでないかをアンガーログを取り、落ち着いた後に3コラムテクニックのようなものでふりかえりを行うという手法が紹介されている。
個人的にも簡単にアンガーログをつけ始めているが、頭の中からアウトプットすることでモヤモヤと抱えなくて済んでいる（気がする）。
多少なりとも客観的に見ることができ、怒りを感じた出来事に対してここは観点が分かれているなという分類などもできた。
あとは怒りを感じた時に、すぐに感情的になって行動を取らないようにする方法やそのまま言葉に出すのではなく、相手に受け取る余地を与える言い換えなどの技術なども載っており活用できるようになりたい。
最後に
認知行動療法などでも聞いた気がするが、自身の認知が歪んでないか、という観点は自分の頭の中から吐き出して、外から見ないと非常に難しいものだと思っている。
ひとまずは継続してアンガーログをつけるようにしたい。
また、最後の方にアサーティブコミュニケーションについての紹介もあったので、これについても入門書を読んでみようと思う。
