AWSでのメール配信入門：Amazon SESの使い方と認証設定のポイント
Amazon SES でメールを操作する 近年、メールの送信は以前と比べて難易度が上がっています。 神奈川県公立高校ネット出願システムでGmailが使えないというトラブルやGmailガイドラインの適用開始は記憶に新しいかと思います。 本記事ではAmazon SES(Amazon Simple Email Service)でのメールの送受信の方法について簡単に説明します。 メール送信者の一般的ガイドライン スパムメールやフィッシング詐欺の増加やセキュリティ強化の必要性から、最近ではメール送信に厳格なガイドラインが設けられています。 例えばGoogleは以下のようなメール送信者のガイドラインを発表しています。 このガイドラインでは「すべての送信者」と「1 日あたり 5,000 件以上のメールを送信する場合」に分けてガイドラインが定義されています。 この「1 日あたり 5,000 件以上のメール
RDBしか知らない奴がBigQueryを触ってみた
RDBしか知らない奴がBigQueryを触ってみた RDBしか知らない奴がBigQueryを触った際のメモ メモなので正確性はない。 基本的に公式ページとGoogle BigQuery:The Definitive Guideを参考にしている。 手っ取り早く要点を掴む本としてはGoogle BigQuery:The Definitive Guideが一番マシに感じた。 しかしながら、2019年11月発売 2020年6月に最終更新なため、それ以降の情報は入っていない。 一旦本に目を通してReleaseノートで重要そうなものを閲覧するのが良さそう。 随時更新予定(型の話はまとめておいた方が良さそうなのであとでかく） ML関係については実験コストが高いので保留。 基本的なこと BigQueryはデータ分析に使用する。 トランザクションはあることはあるが、それが主目的ではないので、RDBではできる
AWSを使用したアプリケーションのローカルテスト
AWSを使用したアプリケーションのテスト方法 AWSを使用しているアプリケーションの開発時に問題となるのは、どのようにテストを実施するかという問題が発生します。 この時の選択肢は次の通りとなります。 単体テスト時にAWSのモックを作成してテストを行う AWS上にテスト用の環境を用意してテスト時に接続してテストを行う LocalStackを使用してローカルにAWSサービスのエミュレーターを動かしてテストする 単体テスト時にAWSのモックを作成してテストを行う 単体テスト時にモックアップする方法はテストに都合のいいデータを返せるため容易にテストが行えます。 モックの作成に手間がかかりますし、思い込みでモックを作成してバグを作成する場合もありますが、Motoなどを用いることでこれらの問題は軽減できるでしょう。 ただし、あくまで単体テストでしか使用できません。例えば複数プロセスを連携するようなテス
SQLパーサーを使用してみた
はじめに この記事ではいくつかのプログラミング言語でSQLパーサーを利用する方法について解説します。 SQLパーサーを使用することでSQLクエリを構成要素に分割したり、構文解析したり、クエリの改変・整形が可能になります。 具体的には以下のようなことが行えるようになります。 SQLクエリのフォーマッタ：SQLパーサーを使用してSQLクエリの整形を行います。一定のルールでSQLを整形することで可読性を向上させることができます。 クエリの検証：SQLパーサーを利用して実際にSQLを実行せずに構文的にSQLが正しいかを検証できます。 テーブルやカラムの調査：SQLパーサーを利用することで、クエリの構成要素を取得できます。これにより、使用しているテーブルやカラムの調査が容易になります。これは障害発生時の影響調査において活用できます。 クエリの改変：SQLパーサーを利用して元のクエリを一部改変して新し
設計書・仕様書のレビュー方法を定めたJIS規格登場 チェック体制を標準化しやすく
経済産業省は11月22日、システム開発時に使う設計書・仕様書などの「作業生産物」のレビュー工程についてJIS規格を制定したと発表した。仕様書などの見直し方や観点などを規格化し、ソフトウェアの品質向上や開発の効率化を促す。 「JIS X 20246」は、設計書・仕様書の見直し作業を「計画作業」「レビューの立ち上げ」「個々人のレビュー」「要検討項目の共有および分析」「修正作業および報告作業」の順に整理し、実行するべきタスクや手順を規定するもの。システム開発や試験、保守などの場面で作るあらゆる仕様書に適用可能。 レビューの曖昧さをなくすため、「目的」「役割」などのレビューの観点10種、「執筆者確認」「同僚との机上確認」などのレビュー手法9種を定めた。JIS制定により、組織や個人のノウハウに依存することなく一定水準のレビューができるようになり、ソフトウェアなどの制作物の品質向上につながるとしている
PythonでPDFのレイアウトを維持したまま翻訳してみる - Qiita
はじめに PDFを機械翻訳する方法は色々ありますが、レイアウトを維持して翻訳をするという意味ではDocTranslatorが使いやすいです。 しかしながら、サイズの制限があるらしく、PDF32000_2008.pdfなどは翻訳に失敗してしまいます。 今回はレイアウトを崩さずに翻訳する方法を考えてみます。 なお、結論からいうと、今回説明する方法は面倒くさいので、別の方法でいいなら別の方法をお勧めします。 PDFに注釈として訳を埋め込む DocTranslatorのように本文にレイアウトを崩さずに訳を埋め込めるならば、いいのですが、色々うまくいかなと予測できるので、注釈として訳を埋め込むことにします。 たとえば、PDF32000_2008.pdfを翻訳した場合の結果は以下の通りになります。 http://needtec.sakura.ne.jp/doc/tmp/output.pdf ※Adob
新型コロナウイルス感染症の感染拡大を踏まえたオンライン診療のPDFデータを利用してみた - Qiita
はじめに 新型コロナウイルス感染症の感染拡大を踏まえたオンライン診療の対応機関一覧リストが以下に公開されています。 これを用いて、近所のオンライン診療の対応機関がどんな感じになっているか取り出す処理を作成してみます。 これにより政府の提供するPDFのデータを使用することができるかも合わせて検討してみます。 成果物 https://needtec.sakura.ne.jp/yakusyopdf/ https://github.com/mima3/yakusyopdf 経度と緯度を入力して検索すると・・・ 近くの病院の一覧が表示されるので、行をクリックします。 すると地図に詳細情報が表示されます。 説明 処理の流れ (1)新型コロナウイルス感染症の感染拡大を踏まえたオンライン診療の対応機関一覧リストのホームページからPDFを取得します。 (2)PDFからテーブル情報を抜き出してJSONに変換し
NMeCabで形態素解析してみよう - Qiita
ちょっと形態素解析でもしてみるか と思いたちまして。 今回はC#で書く必要があったので、.NetでMeCabを参照する方法を調べていたら、 MeCabの.Netでの実装したその名もNMeCabってライブラリがあったので早速使ってみました。 NMeCabは、オープンソース形態素解析エンジンMeCabの解析処理部分を、.NETライブラリとして移植したものです。 オリジナル版MeCabと同じ辞書を使用し、同じ解析結果を得ることができます。 純粋なC#言語で作成されており、ラッパーではないため、インストールがシンプルで、高速性と安定性にも優れています。 とのこと。 辞書は同じなので結果はオリジナルとほぼ変わらないと考えて良さそうです。 ダウンロード 上記NMeCabの公式サイトより最新版がダウンロード可能です。 中身を見てみる ダウンロードしたファイルを解凍すると、このような構造のフォルダが現れま
TwitterAPI search/tweetsでURL検索時のドキュメントに掲載されていない仕様 - Qiita
expanded_urlでなくbit.lyのリダイレクト先のURLが検索対象となっています。 まとめ TwitterAPI1.1のsearch/tweetsでは短縮URLは検索対象でなく、リダイレクト先のURLが検索対象になっている。 投稿時のURLがbit.lyなどの短縮URLであってもbit.lyのリダイレクト先のURLが検索対象になっている。 ※ t.coは、除外されているかなと予想はしていましたが、bit.lyまで展開されているのには驚きました。 特定のブログ記事の反応など、このURLはTwitterでどれくらいつぶやかれているのだろうと検索するときは、単純にオリジナルの長いURLで検索すれば全ての一致を取得出来るとういことですね。 注釈 TwitterAPI1.0では検証してませんが、ここの仕様は同じかなと予想。 更に(3つ以上)短縮URLを介しているものは試してません… Web
Jenkinsのシェルの実行について - Qiita
で実行される(コンソール出力にも出てる) オプション-x：シェルスクリプト内で実際に実行されたコマンドを表示する オプション-e：0でない終了コードを返した時点でスクリプトがexitする 「シェルの実行」のシェルのオプションのカスタマイズについて 「シェルの実行」で先頭に以下のように記述しておくとオプションを付けない状態で実行出来る
ShellScript でもテストを書こう with shUnit2 - Qiita
APP_ROOT |- a.sh `- test/ |- run.sh |- a.txt |- a-expected.txt `- shunit2 という構成になっているとします．a.sh を実行すると test/a.txt の内容が変わって test/a-expected.txt と一致することをテストしたいとします．このとき test/run.sh は以下のようになりました． #! /bin/sh TEST_DIR=`dirname $0` setUp() { PREV_DIR=$PWD cd $TEST_DIR cp a.txt a.txt.bk } tearDown() { if [ -f a.txt.bk ]; then mv a.txt.bk a.txt fi cd $PREV_DIR } testA() { ../a.sh diff a.txt a-expected.txt
QiitaでGoogleアナリティクスを利用する手順 - Qiita
QiitaではGoogleアナリティクスのトラッキングコードを埋め込むことができます。 トラッキングコードを埋め込むことで、自分の投稿やマイページなどがどの程度見られているかを把握することができるようになります。 この記事では、Googleアナリティクスでトラッキングコードを取得して、それをQiitaに登録し、確認するまでの手順を解説します。 1. (事前準備)Googleのアカウントを持っていない場合は作る Google アカウントの作成からGoogleのアカウントを作成します。 2. 新しいアカウントを作る ログインしたら、Googleアナリティクス へアクセスし、「無料で設定」リンクよりアカウントを作成してください。 アカウント名はお好きな名前を入力してください。 プロパティ名は**「Qiita」を入力します。レポートのタイムゾーンは「日本」、通貨は「日本円」**を選択します。 詳細
gitのpush.defaultに関するノウハウ - Qiita
gitのpush.defaultの設定に関して、他人のを設定してあげることもあり、毎回迷うのでまとめました。 push.defaultは、今まではmatchingというのがデフォルトでしたが、Git2.0からsimpleっていうのがデフォルトになります。なので、何らかの設定をしないと、以下の様な警告が出たりします。 warning: push.default is unset; its implicit value is changing in Git 2.0 from 'matching' to 'simple'. To squelch this message and maintain the current behavior after the default changes, use: git config --global push.default matching To squ
gitolite: ライトユースなリモートgitリポジトリを作る - Qiita
はじめに github以外でリモートのgitリポジトリを作りたくなったことはないだろうか？自分のローカルのソースを会社や研究室の誰かと共有したくなったとき、でもメインのリポジトリはsubversionで運用されていてgitのはない。対して、githubで有料なプライベートgitリポジトリを持つほどではない。そんなリクエストを持つライトユースなgitリポジトリをgitoliteで作る方法を紹介します。 ※なお、ここではクライアントはLinux, Mac OS X、サーバはubuntuで作業する前提で話を進めます。Windowsでも作業内容自体は変わらないと思いますが、コマンドラインベースには進めないと思うので、割愛します。 インストール方法 セットアップには、クライアントパソコン（自分のパソコン）でやる作業と、リポジトリをおくサーバサイドのパソコンでやる作業の２つがあります。 下準備：クライ
TestLink の XML-RPC を拡張する - Qiita
最新のTestLink は REST API があるらしいですが、今回は XML-RPC の話を。 前準備 XML-RPC で外部からアクセスするにはまず、API アクセスキー を取得する必要がありますので config.inc.php 内の $tlCfg->api->enabled を TRUE にします。 その後で TestLink の アカウント設定 にアクセスすると API アクセスキー を生成するボタンが 表示されているので、押します。すると、API アクセスキーが表示されますので、それをメモっときます。 ruby で XML-RPC 次に、XML-RPCでアクセスするために、コードを書きます。 ruby だと 以下のような感じでアクセスできます。もし、他言語で書きたい場合、testlink/lib/api/sample_clients 下に java や php のサンプルがあ
TestLink の REST API を触ってみた - Qiita
数日前に TestLink の XML-RPC についての記事を書かしてもらいましたが、 現状のTestLinkにあるREST もどんな状況なのかな？ というのが気になったので、触ってみました。 結論 結論から言うと、まだまだ業務に使用できるほどの機能は実装されていない という感じです。 逆に、今のうちにゴリゴリ実装して、pull リクエストでも投げてみたら 取り込んでもらえる可能性大ってところでしょうか。 やったこと REST API ソースチェック REST API のソースは TestLinkディレクトリから lib/api/rest/v1 と辿った先にある tlRestApi.class.php がそれです。 その中のコンストラクタの中に使える api の一覧があります。 私の環境では以下の通りでした。 Type API 内容 Api Key の指定
Qiitaのテーブルの書き方についてまとめた - Qiita
セルの両端の空白は削除される。 セル同士の結合は不可。 ヘッダ行 主に、列の名前を表示する。 文字列は全て太字で表示される。 ヘッダ行の列数によって、テーブルの列数が決まる。 アラインメント行 「左寄せ」「右寄せ」「センタリング」を設定する。 列ごとの設定であり、セルごとにアラインメントを設定することは不可能。 テーブルには表示されない。 左寄せ --- (または:--) 右寄せ --: センタリング :-: 最低3文字必要。ハイフンはいくらでも延ばしてよい。 使用可能な文字は「:」「-」の2種のみである。(削除されるが、前後に空白も可能) 他の文字が混入していた場合、テーブルと認識されない。 ただし、テーブルに表示されていない列であれば好きに書いてよい。 アラインメント行の列数は、ヘッダ行の列数以上必要。 それ未満の場合、テーブルとして認識されない。 多ければ表示が省略される。 データ行
Git で複数のリポジトリをまとめたり、逆に切り出したりする - Qiita
~/repo1/subdir に ~/repo2 を入れる あるリポジトリのサブディレクトリに別のリポジトリの中身を入れたいとき。たとえば、あるリポジトリのサブディレクトリを切り出して別のリポジトリとして管理しているものを、元のリポジトリに合流させたいとき。 cd ~/repo1 git remote add repo2 ~/repo2 git fetch repo2 # サブディレクトリの内容に repo2 の内容をマージする # （repo2 と内容が似ているサブディレクトリを自動で判別） git merge -s subtree repo2/master # ↑でうまくいかないときにはパスを指定する↓ git merge -X subtree=subdir repo2/master # そもそも ~/repo1/subdir が存在しないときには↓ git read-tree --p
Review Board に差分を投稿する時の tips (特にgit) - Qiita
Review Board 上に差分を投稿するのは RBTools というコマンド群を別途入れてやることになります。 git のグローバル設定に Review Board を設定 git config --global reviewboard.url http://localhost/reviewboard/ rbt post リポジトリ上で rbt post -o とすれば、HEADと作業ブランチのリモート（なければmaster）との差分を投稿します。投稿するとレビューIDが取られて、チケット的に管理されます。オプション-oで投稿したリクエストをそのままブラウザで開く。 前までpost-reviewだったんですが、最近だとrbt postになったっぽい？ -rで差分を更新する 先に投稿した差分を修正した場合、その差分を更新できます。 Review Board では投稿した差分の世代管理がさ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RedmineとGithubの連携 - Qiita
