Google Docsの箇条書きのインデントを調整するGoogle Apps Script
背景
Google Docsでは段落スタイルから見出しごとに指定したスタイルを適用できます。しかし,2020/12現在,「箇条書き」や「番号付きリスト」にはスタイルを指定できないため,インデントはrulerで個別に調整しなければなりません。
そこで省力化のために,Google Apps Scriptを用いて,インデントを自動設定するスクリプトを書きました。
適用例
Before
After
上の例はDropbox paperを模したインデント幅にしています。私的にはAfterが読みやすいですが,ここらへんの好みは人に依ると思います。インデント幅はスクリプトの変数から任意に設定可能です。
ソースコード
使い方や関数の説明などはソースコードの次に記載しています。
function onOpen() { const ui = DocumentApp.getUi() .createMenu('MyScript') .addItem('Indent adjustment', 'indent') .addToUi(); } function indent() { // Definition of rules // <levelDistance*(level+1)>●<stringDistance>level 0 const levelDistance = 21.0; const stringDistance = 16.0; const rules = []; for (let i = 0; i < 9; i++) { //Max lavel : 8 (Definition of Google Documents) indentStart = (i + 1) * levelDistance; indentFirstLine = indentStart - stringDistance; rules.push([indentStart, indentFirstLine]); } const document = DocumentApp.getActiveDocument(); const body = document.getBody(); const listItems = body.getListItems(); for (const listItem of listItems) { const level = listItem.getNestingLevel(); const rule = rules[level]; listItem.setIndentStart(rule[0]); listItem.setIndentFirstLine(rule[1]); } }
- 使い方
- Google Docsのメニューバーで
ツール
>スクリプトエディタ
を開き,以下をコピペ - ページを再読み込み
-
MyScript
>Indent adjustment
を実行するとドキュメント内の「箇条書き」,「番号付きリスト」のインデントが変更される
- Google Docsのメニューバーで
- 簡単な説明
- onOpen関数: メニューバーに
MyScript
>Indent adjustment
を追加 - indent関数: アクティブドキュメント内の「箇条書き」,「番号付きリスト」のインデントを変更
- onOpen関数: メニューバーに
- 設定
- indent関数の
levelDistance
とstringDistance
にてインデント幅を設定可能 - 変数の意味
<levelDistance*(level+1)>●<stringDistance>level 0
- indent関数の
残課題
- Glyph(箇条書きの黒丸)が文字に対して大きすぎるため小さくしたい
- 他Documentへの適用
SRE Lounge #9
- 日時: 2019.05.29
- URL: https://sre-lounge.connpass.com/event/129214/
- 特徴:
- 複数社のSREプラクティスが知れる
- 双方向コミュニケーション。質疑応答を行う
DIPのSRE活動とこれから
Speaker: bayashi_okさん@dip
- システム開発部、SREチームリーダー
SREまでの道のり
- まずAnsibleでインフラを自動化
- 問題:
- ツール(git, ansible)の使い方がわからない
- コード化するメリットがわからない
- 問題に気づいていない。気づいていないから学べない。よくわからないから変えたくない
- 解決策:
- コード化するメリットを伝える
- 作業効率を意識させる
- 他社事例の紹介でメンバの安心感を伝える
- ツールの伝え方を何度もレクチャー。1回だけだとわかってくれない。なじみのある言葉で説明
- 効果が高いところから導入
- 承認フローの確立(課長がマージ)
- 問題:
- 次にログ可視化
- 問題:
- アラートには出ない不具合が多い。原因は以下3個
- 隣の部署のしごとがわからない
- 問題の重要性に気づいていない
- 対応する意味がわからない
- 解決策:
- 互いにメリットがあることを説明
- 問題:
- 次に速度改善の命令が上から来た。Googleが遅いほど直帰率が下がるよう仕様を変えたため
- 内容はこちら
- 画像最適化(Fastly利用)
- 初期速度が70%改善。応募率が14%上昇
- 転送量24%削減(画像最適化のため)
- モバイルサイトUXレポートで想像評価No1、サイト速度No2に
- まとめ
- コミュニケーション大事
- 最高の設計と実装はお互いの尊重する雰囲気の基で関心が一つになったときに生まれる
- ツールの導入は草の根活動と強権のどっちで進めた
- 草の根。もともと自動化したいと皆が思っていた
- 時系列分析はしている?速度とか
- 現在は短期ログのみ可視化している。今後はBigQueryを考えている
- セキュリティは
- これから
タップルSREの軌跡と描く未来
- Speaker: 袴田類さん@マッチングエージェント
- DevOpsチームが解散したときの反省
- 反省に基づく変更
- 足元課題をSLOに定義
- 事業成長に貢献できるシステムの理想状態を定義
- SREチームだけだと難しい。エンジニアリーダーや経営層、経営ボードと協力
- このため、信頼性担保には振り切れていない
- SLO: 2個用意
- オンボーディング
- アーキテクチャ図を常に作っている。新メンバーがアーキを俯瞰できる
- draw.ioで管理
- 障害対応
- セキュリティ対策
- 緊急度が低いが重要性の高いリスクは管理しないとやらない
- リスクアセスメントで可視化し、時間があるときにつぶしていく
- ロードマップ: SLP、マイクロサービス、不具合発生の最小化、不具合の影響削減
- 事業成長に寄り添っていきたい
- SREのマインドセット: セキュアベース(ロッククライマーの命綱を握っていてくれる人)になる
- 安心感を作り、組織にチャレンジをさせる
- QA
- リスクスコアの決め方は?
- 障害の大きさ(問い合わせ件数)で決めている。しきい値でスコアを分類している
- 足元課題と中長期課題の割合は?
- 足元課題をできる限りSLOにまとめ、それを達成できている間は中長期課題を実施
- リスクスコアの管理方法は?
- gitlabのIssueで管理し、datadogで可視化(gitlabのラベルを紐づけている)
- 障害対応を皆ができるようになるための工夫は?
- ローテーションにすることで責任感を持たせる
エムスリーはどのようにしてSREを始めたか
- Speaker: tshoheさん@M3
- M3のSRE第一号
- ansible, terraform, ログ監視など
- M3は医師向けのニュースサイト、質疑応答サイト。65人
- SRE
- 昨年の11月にできた
- 6人。リーダー1人、メンバー4人、xx1人
- 初期状態
- アプリの品質改善の判断が曖昧。エンジニアが主観で実施。
- SLOを決めるところから始めた
- 小さく初めて範囲を広げるアプリーチが良い。
- 主要サービスからスタート
- SLI
- 稼働率: ヘルスチェック。200がかえるかどうか
- レスポンスタイム: サーバサイドのレスポンスタイムのみ
- 最初はあまり頑張らない
- 計測
- DC内のNagios, NodePing(外からURLを叩くサービス)を使っている
- Elasticsearchに保存。すでに一部データが入っていたため。
- 最近はDataDogの利用も増やしている。terraformで管理できるため便利
- RTはFluentdで収集。長期保存するためサンプリングしている。
- SLOの決め方
- 性能要件が決まっていれば採用。月間稼働率99.9%
- RTは98-99%ileが1s未満
- The Site Reliability Workbookを参考にクラス分けしようとしている
- 月1のページで見直し。本来は毎週だが人がユニットに分かれているためコストが大きい
- 可視化
- Kibanaを仕様
- SLO一覧ページからリンク
- オンプレ環境はGrafanaも使っている
- アラート設定
- Elasticsearchからpacentile aggretationをバッチで計算
- アラートの値が難しい
- SLOを超過したらJIRAにチケット + Slack通知
- 担当者は優先度を上げて改善。短期解決が困難な場合は条件緩和などの救済措置
- まとめ: SLOの監視ができるようになった
- 今後:
- 告知
- SRE Session2を開催
- 対話型