shimajima-eiji/gas

READMEはmaster以外更新されないので、本リンクかBranchを切り替えること

ご案内：スカウターの皆様

• ポートフォリオ（日程調整フォームを含む）
• 2023年度版: 一般公開用履歴書
• [作成中] 2023年度版: 一般公開用経歴書

画像クリックでスライドページを拡大

スライド全文

活動記録と分析

• 1年に1回、だいたい1,2ヶ月を目処に大幅アップデートしています
  （来年度の求人のご相談対応や確定申告などの書類整備、Qiitaアドベントカレンダー記事のバックアップ等）
  • ディスカッションやWikiの更新がコントリビューションに反映されないのが悩みです…
• 静的サイトホスティングのため、SSGでビルドしたHTML/CSS/JavaScriptが多いので言語比率があまり参考になりません。
  • CI/CDを主にShellScriptとPythonで作っています。
  • テストオートメーションツールや研修教材はJavaで作っています。
  • 2023年最近のドキュメント・ナレッジ管理をDocsifyとSlidevに移行しており、教材開発も行っている関係でmarkdownファイルが多くなっています。
    • 教材開発のCMSはWordPress、microCMS、adiaryを使用しており、APIをコールして取得したjsonからmarkdownファイルを生成してPDFに変換しています。

README(GitHub就活・転職プロジェクト)

色々なページを作っていたのですが、情報が多いと逆に見るのがしんどくなるという悲しい状況に苛まれたので、

• 非IT事業者向け（官公庁など）
• IT事業の人事・スカウト向け
• 現場エンジニア・ハッカソンメンバー向け

上記に該当する方向けにページを考えています。
2023年も引き続きGitHub転職プロジェクトに力を入れていきます。

コンタクトについて

様々なエージェントサイトに登録しておりますので、そちらをご活用ください。

その他技術情報(スライド内より抜粋)

ページリンク	概要
ポートフォリオ：サイトトップ	自前のポートフォリオサイトです。最近は手抜き気味…。
ポートフォリオ：外部サイト	外部ポートフォリオサイトです。アカウントがなくても見れます。こちらの方が更新が早いです。
すべての作品一覧	作成したプログラムやブログサイト向けのソースコード、または作品のうち公開できるものを置いています。
Github：転職プロジェクト	こういう活動やってます、というのを一覧できるようにしました。進捗管理にも使っています。
Webサービス	すぐに使えるサービスです。主にJavaScriptで作成しています。
Webサービス（ソースコード）	上記サービスのソースコードを置いています。
開発環境	エンジニアの方向けに、私の開発環境を公開しています。

[GitHub就活・転職プロジェクト: 開発者向け] リポジトリルール

クリック・タップで展開

最終更新: 2023/08/24: GitHubリポジトリルールをver2023.08.24に刷新

古いルールで運用しているリポジトリもありますので、全てがこの通りではありません。

プレフィックス運用ルールの注意点

リポジトリが多くなると管理が大変なので、原則としてリポジトリはプレフィックスで管理して運用する方法を提案します。
ただし、プレフィックス運用をすると複数のGitHub Pagesをリポジトリ運用する際に、パス内にプレフィックスが含まれてしまうため、必要な場合はプレフィックスルールをオリジナルにしてください。

オープンリポジトリ

原則として「タグ名_リポジトリ名」のように、接続の意味を持つスペース的用法はハイフンを使用しています。

• 例：GitHub Pages = Dev_GitHub-Pages

名前順検索で使用する事を想定するため、私だけが使用する事を想定したものについてはリポジトリ名を「」から始めています。
たとえば、過去にGASリポジトリは検索順の都合から「--」で始めていましたが、GASリポジトリ数が増えてきたので「」に差し替えています。

タグ名一覧 ※本アカウントにおいて、タグ名が存在しないリポジトリは「本リポジトリ」と「GitHub Pagesルートリポジトリ」以外は暗黙的にOldと同列の扱いです。
実際に運用する場合はご自身のルールを設定・周知するか事前にリポジトリを対応しておくとよいでしょう。

タグ名	概要
Hosting_	GitHub Pagesをはじめホスティング用ファイル群
Old_	分類に困った古いリポジトリ群。いずれ何とかしたいと思っていますが、方針を決めるのに時間がかかります…
Recruit_	採用人事・エージェントスカウト向け情報

プライベートリポジトリ

原則としてツール毎に最適化したプレフィクスと運用状態を可視化できるようにしています。
過去に運用状態をブランチ管理していたところ、無料プランではブランチのプロテクトルールが適用されず直接pushできてしまう問題が発生したため、開発と運用のリポジトリを分けて運用する事で解消しています。
これにより、リポジトリをforkして共同開発を行いたい場合に、セキュアな情報を階層的に分けての管理を実現できます。
別リポジトリの運用である以上、手間が掛かる事は避けられませんがリスクマネジメントの観点で見ると悪くないんじゃないかと思っています。

gas's Issues

snippetsのマイクロ化

現在、１プロジェクトにすべての機能を集約しているため、これを廃止する。
ケースバイケースに分離して使わないと管理コスト（特にセキュリティ）が肥大化してしまう。

[task]「スケジュール申請フォーム」ブランチから「スニペット」ブランチへ寄せる

スケジュール申請フォーム

結構骨が折れるかもしれない

[slackapp] botではなくappとの連携

おそらくslackapp側を開発する必要がある

[snippets] DateUtilをMomentJSに依存しているのに、取得方法を丸投げしている

これがMomentJSではなくなったら、DateUtilをMomentJSのように振る舞わせる必要がある。

[events2SNS] 勉強会の参加履歴を残すためAPIを提供する

このように、過去の参加情報が消えていくので、これを残したい。

[connpass2slack] post時の文字数制限に対応する

[event2sns] イベントトリガー

[connpass2slack] 申込期間を過ぎたものを取得しない

connpassAPI仕様では取れないので、クローラーを動かす必要がある
https://connpass.com/about/api/

[GAS][Github運用, 経歴更新2022]煩雑なブランチを分散・リポジトリ管理に移行する

Githubの仕様を考えると、同一リポジトリで別ブランチに分けて整備していく、というやり方はアンチパターンなので、リポジトリ名をプレフィックスで管理する方法を検討する
結果的に、リポジトリ一覧画面が汚染されるが仕方がない。

経緯

v4ではこれを嫌って、このリポジトリにブランチ管理を進めていたがコントリビューションに反映されずGithub就職・転職活動の観点では良い結果にならなかったため、現状のv4を差し替える必要が出てきている

https://github.com/shimajima-eiji/GAS/branches

[snippets] 管理体系をスプレッドシートに移管する

[snippets] dictの値が書き換わってしまう

funtion() {
  const s = new snippets.SpreadSheet();
 
 s.getSheet('other sheet id');
  Logger.log(s.dict());
  new snippets.getProperties();
  Logger.log(s.dict());
}

で再現できる。
IDはgetActiveのものだった。

[task] GASリポジトリを集約

管理しきれないのでブランチに移行する

• https://github.com/shimajima-eiji/GAS_line2slack
• https://github.com/shimajima-eiji/GAS_slack2line
• https://github.com/shimajima-eiji/api_portal

[connpass2SNS] exclude_addressをspreadsheetに

メッセージが日本語なのが気に入らない
検索条件はプロパティにしてしまうか？

スプレッドシートをAPIで返す

新しいプロジェクトとして作成すべきか

[connlass2SNS] 共通処理っぽい範囲を集約する

getEventsとgetWeekで似たような事をやっているので、これをなんとかできないか？

[snippets] 日付を文字で入れた時に対応する

#16 勉強会の参加履歴を残すためviewを提供する

同じ作りでいける、gas2vueが使える

[snippets.doGet] リスト内に不要な\がある

[event2SNS] connpass以外にも対応させる

新しくatnd.gsとかtechplay.gsを作ってそっちで管理する

GASのプロパティ管理

各プロジェクトで同一の内容を扱うことがある。
共通化を図るのはスプレッドシートなどでも可能だが、どうせならmicroCMSで管理できるのが理想。

RSSフィードをLINEに流す（IFTTTやmyThingsなど回数制限に引っかからないもの）

SlackAppのRSSを経由してLINEに流すのが理想的。ロギングできるし

メールを受け取ったら各所に転送する

とりあえずはLINEとSlackに送る。
返信もLINEとSlackでできるようにしたい

[snippets] slackからの検索機能に対応する

実装は簡単。
呼び出しはエイリアスでもoutgoingでも。

問題は、どうやって検索UIをslackで実装するか。

[snippets] プロパティをスプレッドシートで管理する

探すのが面倒くさくなってきた

[V2] マイクロなプロトタイプを実装

• #18
• #27
• #28

[snippets] getpropertyを制御

検索で一意のキーを取得し、固定値で制御したい。
たとえば、property.[key]（これを決め打ち） で任意のvalueを得る

[snippets] 受信管理でバリデーション

不正な文字列を送ったりするだろうなので、これを厳密に弾く

[urlfetch] エラーキャッチとロギング

それぞれの場所で制御しているので、オプションを生成させてfetchをsnippetsで実行させる

connpass2line gcalendarAPIで配信する

今日参加するイベントが取れない
connpass.icsをどうやって取るか