はてなブックマーク

SQSをイベントソースとするLambdaに同時実行数の制限をつけた場合どのような動きになるのか確認した。 Lambdaの同時実行数について AWS Lambda開発者ガイド 『Lambda 関数の同時実行数の管理』 によると 同時実行数とは、ある時点で関数が処理しているリクエストの数を指します。 とある。 この同時実行数には、 AWSから課されるアカウント(かつリージョン)単位の同時実行数の制限 ユーザが任意で関数単位に課す同時実行数の制限 の二つの制限がある。 後者は予約された同時実行数と呼ばれ、アカウント単位の同時実行数を関数毎にどう分け合うかというリソース配分としての意味の他、Lambdaの下流にいるリソースへのアクセス数を制限し過負荷から保護するため用途でも使用される。 同時実行数を超えた場合、関数の呼び出しは行われずスロットリングによるエラーが返される。 SQS + Lambda

『macOS Mojaveのキーリピートで困った話』 の対応策としてalacrittyに乗り換えてみる。 インストール Alacritty本体 brew cask経由でインストールできるものの、後述のmanやfishの補完、terminfoを入れたい場合には別途ソースが必要になる。 今回はこれらも含めてインストールしたいのでいっそのことソースからビルドしてインストールすることにした。 Manual Installationに従って実施。 リポジトリからソースを取得。

Dockerコンテナからコンテナを操作するのは特殊なユースケースで縁遠い存在と思いきや、アプリケーションをコンテナ化しそれをコンテナベースのCIで扱おうとすると割と直ぐに直面することになったのでメモ。 コンテナ内でコンテナを操作する主立ったやり方には DinD(Docker in Docker) DooD(Docker outside of Docker) の二つがある。 またコンテナのビルドに限定すればDockerに依存せず独立してコンテナイメージをビルドするDaemon-less Image Builderを使う方法もある。 DinD 概要 Docker in Docker。 Dockerインストール済みのコンテナを使用しコンテナ内でホストとは別にDockerデーモンを動かす方法。 DockerのprivilegedフラグのコントリビュータでありDinDの走りとなったの docker:

macOS上のtmuxはpbcopyとpbpasteによるクリップボード共有がうまくできない問題があり、これを解消するためにreattach-to-user-namespaceを併用していたが、tmux 2.6ではreattach-to-user-namespaceがなくてもクリップボード共有ができるようになっていた。 # --------------------------------------------------------------------------- # Clipboard # --------------------------------------------------------------------------- # Vim binding bind-key -T copy-mode-vi v send-keys -X begin-selection b

Clojureの開発でCIDERが使いたくてSpacemacsに入門したのだが、それより前にGolangを書く必要が出てきたのでコードを書く環境を整える。

Karabiner-ElementsをアップデートするとKeyRepeatタブが消えていた。 https://github.com/tekezo/Karabiner-Elements/issues/551 Apple does not provide a way to change the key repeat rate of keyboard devices. Thus, the key repeat configuration was vanished. ということで今後はdefaultsコマンドで設定することになりそう。 現在値は以下で確認

つい先日、Apple Watchにはヘルプモードなるものがある事を知った。 これは主に駅改札窓口で精算や入出場記録の修正を駅員さんにお願いする際に利用する。 ヘルプモードになったApple Watchは手首から外しロック状態になっても１分間はApple Payが利用可能であるため、 この状態でApple Watchを駅員さんに渡し処理をお願いするという寸法だ。 ここで一つ疑問が湧く。 Apple Watchを使い始めて半年以上が経つが、今まで幾度となく改札窓口で駅員さんにお世話になっている。 当初は付けたまま腕を伸ばし処理してもらっていたが、ある時駅員さんに外した状態でも処理できる事を教えてもらいそれ以降は外したApple Watchを手渡して処理してもらっている。ヘルプモードの存在を知らずただ単にApple Watchを外して駅員さんに手渡していたのだ。 これを機に何故ヘルプモードではな

エディタはVim派だけどClojureの開発でCIDERを使ってみたいという動機から唐突に Spacemacs へ入門してみる。 まずはインストールと基本的な使い方をメモ。 インストール SpacemacsのドキュメントmacOS向けの前提条件とインストールガイドを読みながらインストールを実施。 emacs-plus emacs-plus は homebrewのEmacs formulaeを元にしたformulaeでSpacemacsを利用するための前提となるEmacs本体とその他必要なライブラリをインストールする。

GitLabのマージリクエストをSonarQube Scannerで静的コード解析し結果をマージリクエストのコメントとして投稿するためのメモ。 マージリクエストの作成から解析結果のコメント投稿までの動作概要は以下。 開発者がGitLab上でマージリクエストを作成 GitLabのWebhookでJenkinsの自動レビュージョブを起動 自動レビュージョブがSonarQubeサーバから必要な情報を取得する 自動レビュージョブが静的コード解析を実施 自動レビュージョブが解析結果をGitLabへ投稿 設定作業の流れ Jenkinsの設定 GitLab Plugのインストール 自動レビュージョブの作成 GitLabの設定 ユーザの作成とグループへの追加 Webhookの追加 SonarQubeの設定 GitLab Pluginのイントールと設定 Jenkins プラグインの追加 GitLab側からの

なんとなく新しいshellに手を出してみたくなった。fishを触ってみたところ良さそうだったので移住のためのメモを作成。 fishの特徴 fish (Friendly Interactive SHell)は分かり易さ・ユーザフレンドリーに重きを置いた敷居の低さと実用性の両方を兼ね備えたシェル。 以下のような特徴がある。 オートサジェスチョン 履歴と補完機能によるオートサジェスチョン。 入力中の文字列に対してパス、コマンドオプション、履歴を元にサジェストされる。 24bitカラーのサポート True color(1677万色)をサポート。 シンプルでクリーンなスクリプト構文 モダンなスクリプト構文。 manページを元にしたコマンド補完 manページから補完設定を自動生成するため個別の補完設定なしで補完が有効になる。 充実したドキュメント 分かり易いドキュメントが充実している。シェル上から h

Slackの設定 chabonzeを動かすためにSlack側で必要な設定を行う。 Botユーザの登録 chabonzeをSlack Botユーザとして登録する。 https://my.slack.com/services/new/bot Username ボット名を指定する。 例：chabo Add Bot Integeration で登録。 API Tokenはchabonzeの起動パラメータとして必要となるのでメモしておく。 Save Integration で保存。 Twitter Integration Slack標準のTwitter Integrationにはメッセージ内にツイートのURLがあると内容を展開して表示する機能がある。 今回Slack上にツイートの内容を表示するためにこの機能を利用する。 https://my.slack.com/apps からtwitterで検索し、

fzfはパイプ経由で候補リストが渡されなかった場合、カレントディレクトリ配下のファイル一覧が候補リストとなる。 ファイル一覧の作成にはfindコマンドが使用されるが環境変数 FZF_DEFAULT_COMMAND を設定することで任意のfind代替コマンドを利用することができる。 今回は$XDG_CONFIG_HOME/fish/conf.d/fzf.fish を作成、以下のように設定し、 ripgrepを利用 隠しファイルも対象 .git配下を無視 gitignoreに定義済みの対象を無視 シンボリックリンクを追う とした。 fzfコマンドを利用する ファインダーの操作 fzfコマンドを実行すると候補リスト選択、絞り込みのためのファインダーが表示される。 ファインダーの操作方法は以下の通り。 CTRL-C CTRL-G ESC のいずれで終了。 CTRL-P CTRL-K のいずれかで上

打刻システムの構築(前編)からの続き。 前編にてSNSを基点に打刻情報をGoogleスプレッドシートへ書き込むところまでが完成した。 後編ではSNSの前面にAPI GatewayとCloudFrontを配置し実際にIFTTTアプリから打刻APIを呼び出せるようにする。 API Gateway API GatewayをSNSの前面に配置。以下の役割を担う。 REST APIの呼び出しをトピックへのパブリッシュに変換する APIキー、使用量プラン等によるAPI呼び出しのスロットリング 打刻API用ポリシーの作成 API GatewayからSNSへパブリッシュするためのポリシーを作成する。 AWS マネージメントコンソールから IAM を開き ポリシー から ポリシーの作成 Policy Generatorで以下を作成。 効果 許可 AWSサービス Amazon SNS アクション Publis