ども、初老丸です。 tl;dr Python で watchdog というモジュールが個人的にホットでこのモジュールを使って、ファイル作成を検知したら任意のアクションを起こすツールをサクッと作ってみたりしたが、よくよく調べてみると watchdog に同梱されている watchmedo というツールが既に存在しているので触ってみた。 https://pypi.python.org/pypi/watchdog http://pythonhosted.org/watchdog/ 試す 試した環境 $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION="Ubuntu 14.04.2 LTS" $ python -V Python 2.7.

Part2では、Airflowの基本的な使い方を学びました。Part3では、実際にパイプラインの実装に入っていきたいと思います。とはいえ一度に全部は作れないため、パートに分けて作成をしていきます。今回は、データ収集を担当するパートの一部を実装しようと思います。 Part3にて実装の範囲: データの取得処理具体的には、以下の処理のうち1~2を実装してみます。 EDINETから、決算関連文書のリストを取得するリストに掲載された文書をダウンロードして、ストレージに格納するダウンロードされた文書からテキストを抽出し、DBに格納する抽出したテキストから特徴量を計算し、ストレージに格納するEDINETは、企業の決算文書などを公開している金融庁のシステムです。最近APIで文書にアクセスできるようになったため、こちらを題材に使ってみたいと思います。 基本的には、ファイルダウンロード・テキスト抽出・特徴量抽

トラフィックの測定やファイルサーバのテストなど、希望する容量のダミーファイルが必要な場合がある。ここではddコマンドを利用したダミーファイル作成方法を紹介しよう。 # dd if=/dev/zero of=tempfile bs=1M count=10 読み込んだブロック数は 10+0 書き込んだブロック数は 10+0 # ls -l tempfile -rw-r--r--　　1 root　　root　　10485760 12月 11 18:59 tempfile 上記は、ファイル名「tempfile」で10MBのファイルを作成する指定例だ。ポイントは、「/dev/zero」として「\0」文字（null）を読み込み、ブロックサイズ（bs=）に小さすぎない適度なサイズを指定し、「count=」で作成するファイル容量を指定するという点だ。 ddコマンドは、ファイルを変換してコピーするものであり

If I install a new service then decide I don’t want that application anymore and delete it, the service is still listed in the output from systemctl as error. Where is this coming from and how can I remove them thoroughly?

秋山です。 Python 3.7.0が一昨日リリースされましたね！ What’s New In Python 3.7 — Python 3.7.0 documentation 何が変わったのかしらんということで、いろいろドキュメントを読んだり実際に試したりしてみましたが、ざっくり言うと型ヒント関係のアップデート、速度改善、asyncioの改善などがありました。 今回はPython 3.7.0で気になった新しい機能＆改善点を書いてみます。 ■型ヒント関連 型ヒント等のためにいろいろ整備されたっぽいです。 PEP 560 www.python.org __class_getitem__, __mro_entries__ が追加されました。今までメタクラスでやっていたクラスの添字処理のオーバーヘッドを減らせる(typingのimportが7倍速くなった！)＆メタクラスの競合やバグが危険なときがあ

概要 Airflowのタスクが失敗した際にSlackにメッセージを送るようにする。 トークン等はVariablesに保存して扱う。 バージョン情報 Python 3.6.7 apache-airflow==1.10.1 slackclient==1.3.0 導入 slackclientが必要になるので入れておく。 $ pip install slackclient Variablesの設定 下記あたりを参考にSlackのトークンを取得しておく。 https://api.slack.com/incoming-webhooks AirflowのWebサーバーを立ち上げる $ airflow webserver -p8080 Admin → Variablesを選択。 CreateタブからVariableを生成する。 公式ドキュメントによるとVariableのキー名がパスワードっぽいものについて

TL;DR GAEは… (Google App Engine)のレイテンシが思っていたより大きい Keepaliveヘッダーを無視する API サーバーとして利用するにはあまり向いていなさそう(感想) 経緯 既存のシステムの一部をAPIとして切り出そうという作業をしていました。 そこで目をつけたのがGCP(Google Cloud Platform)のGAE(Google App Engine)です。(楽だし) 他のシステムから呼ばれることもあってレスポンスタイムの要求がかなりシビアなので計測しておくことにしました。 計測対象のアプリ自体はただの echo server です。 環境 region: asia-northeast1 environment: standard language: go 計測 abコマンドを用いて計測しました。 $ ab -c 1 -n 100 <URL> .

/hoge/app1/ /hoge/app2/child1/ __ini__.py hoge.py fuga.py /hoge/app2/child2/ というフォルダ構成で、app1とapp2はDjangoフレームワーク上で別アプリとして開発している。 この状態でhoge.pyでfuga.pyをimportするときは from child1.fuga import ~~ と記述しなければいけないのですが、普通にPycharmで記述していると「Unresolved reference~~」とWarningがでます。 その場合の対処方法 app2フォルダで右クリックをして「Mark Directory As」→「Source Root」を選択する。 Pythonの作法がよくわかってなくて詰まってたけど、なんとか解決してよかった。 参考にしたサイトはこちら↓ python - Unresolv

ApacheSparkで扱うobjectのSerializableの必要性について hiveやファイルからデータを読み込んだ直後値はRDD, Dataset, DataFrameになっていて、少ないデータに対して何回もfilter処理を行う必要がある場合に一旦collectして配列に変換しdriver内で処理したい場合もあると思うけど、データを読み込んだ際にnon-serializableなクラスに値をセットしていたらcollectで配列への変換時にエラーが発生したのでその際のメモ 例えば以下のようなjavaのクラスがあったとして、これをsparkで利用するとする public class IdsBean { private int id; public IdsBean(int id) { /* compiled code */ } public int getId() { /* comp

少し、オブジェクトのシリアライズ（直列化）とその影響について、調べる必要がありまして。 これまで、あまりシリアライズを使う、特にクラスの互換性的な面はあまり考慮しなかった（というか、シリアライズされたオブジェクトの授受は避けていた）のですが、ちょっと気にする必要が出てきました。実際に使用するかどうかは別ですが。 Javaのシリアライズの仕様は、こちらに記載があります。 Java オブジェクト直列化仕様 http://docs.oracle.com/javase/jp/6/platform/serialization/spec/serialTOC.html JDK 7版（英語） http://docs.oracle.com/javase/7/docs/platform/serialization/spec/serialTOC.html で、気になるところは、主にここですね。 直列化に影響する

Airflowで動的なワークフローを構成するために、SubDagOperatorとtrigger_dag APIを使ってみました。 課題 ある一連の処理を何らかのリストに対して行いたいという場合があります。 ただしそのリストは固定ではなく毎回変わるものとします。図に書くとこんな感じです。 |--> 処理1 for id1 --> 処理2 for id1 --> 処理3 for id1 |--> 処理1 for id2 --> 処理2 for id2 --> 処理3 for id2 idリスト取得 ---| : | : |--> 処理1 for idN --> 処理2 for idN --> 処理3 for idN このような処理フローをAirflowで構成するにはどうすれば良いのか？というのが本稿のテーマです。 以下、自分がやってみた方法を2つご紹介します。 方法1: SubDagOper

セキュリティ対策の役割分担全体像クラウドを利用する中で必要となるセキュリティに関する考え方をおさらいしてみましょう。データセンターを契約し、そこに物理的なサーバーを配置して IT システムを運用するという従来型のモデルではセキュリティに関する対策を全て自身で行う必要がありました。一方、クラウドを利用するとクラウドプロバイダー(Google Cloud Platform = GCP)とセキュリティ対策の役割分担を行う形となります。以下の図は役割分担をまとめたものとなります。 アカウント管理の課題GCP を利用する場合、ユーザーは Google 管理アカウント(Gmail, Gsuite, Cloud Identityなど)や 3rd party のアカウントを利用して GCP にアクセスします。GCP にアクセスした後は、アカウントに紐付いた権限内で GCP を操作します。ただし前出しました

Lv：19　Exp：21156 2017年12月より現職。インフラ担当としてIaC、Kubernetesを勉強していた。 2019年11月よりコンサルタントに転向。 好きな言語はJavascript。好きなGCPプロダクトはCloud Build。 好きなOCGカードは《超弩級砲塔列車グスタフ・マックス》。 はじめに: Cloud Nativeにとってのブラックボックス: SSHサービス 亀梨です。数ヶ月ぶりですかね。 さて、「IaaSしか触ったことない(オンプレミス？何それ)です」という「cloud native」が増えています。喜ばしいことではあります。 しかし、コンテナ開発が(知らないおじさんによって)叫ばれている昨今、「素のOSとは？素のミドルウェアとは？」という根本的な、根源的な知識の重要性はむしろ高まっています。 IaaSのゆりかごの上で、地表のオンプレネットワーク、オンプレ装