hatunina’s blog

メモと日記です

19年前期触った技術

新しい技術何か触ったっけという日記です。新しく触ったやつは赤字です。

やってたこと

主に不正検知(機械学習ベース)やユーザーログ取得のPoC、TeradataやHadoopからデータ抽出・集計をやりました。

触った技術

  • Python
    機械学習やデータ抽出、集計などで使った。PyCharmに課金してサーバのコードをいじるぐらいしか新しいことはやっていない。JupyterLabを使い始めたけど特に拡張も入れていない。

  • PHP
    既存コードがPHPだったので以下のオライリー本を読みながらPythonに移植したりした。最低限の基本文法を詰め込んだのみで既にほとんど覚えていない。

www.oreilly.co.jp

  • Java
    SpringBootとThymeleafで社内ツールを作るのに使った。後期はこの業務がメインになりそう。 SpringBootは昔使っていたので以下の本を読んで思い出した。テストもちゃんと書いているのでJUnitも勉強した。

books.rakuten.co.jp

gihyo.jp

  • JavaScript
    PoCにちょっと使っただけ。過去の知識で乗り越えた。

  • Teradata
    Teradata StudioだったりPythonからSQLを投げまくった。方言がちょっとあるくらいで文法自体は特につまづくことはなかった(と思う)。Window関数もちゃんと使ったりした。 テーブルや各カラムの定義を把握するのが大変だった。

  • Hive
    HiveQLを使ってデータを抽出したり集計したりした。既存のクエリをちょっと修正して投げるということが多くまだ雰囲気で使っていることが多い。後期はHadoopからちゃんと勉強したい。

  • Tableau
    データ集計の結果や機械学習の本番デプロイ後の精度やFalsePositiveを可視化するのにちょっと使った。ちゃんとガッツリ使う機会がないと中々覚えられなさそう。

触った技術(業務外)

  • PyTorch
    以下二つのコンペで使った。本も何個か読んだけど多いので割愛。自然言語処理と画像というほぼ未経験の分野で銀メダルが取れたのでよかった。

www.kaggle.com

www.kaggle.com

  • Swift
    社内ハッカソンでアプリ作成に使った。ハッカソンに参加するなら触ったことのない技術を使いたくてチャレンジ。実装したい処理と関数がほぼそのまま紐づいているのが新鮮だった。

www.socym.co.jp

感想

ちょっと知ってるとか既存の知識の拡大で使えるみたいな技術が多かった。ゼロから始めたのはPHPとSwiftぐらいかも。新しく触ったしそこそこわかるぜみたいな技術を1年の中で最低1つは増やしていきたい。後期が終わる頃にはHadoop周りとPyTorchをそこそこわかるぜと言えるようになっていたい。

接続先サーバによってTerminalの背景を変える

概要

devやproductionごとにTerminalの背景を変えることで作業ミスを防ぎたい

環境

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.14.4
BuildVersion:   18E226

手順

  1. 接続先サーバによってTerminalの背景を変えるシェルスクリプトを書く
    1.1. 接続先サーバによって指定する背景を設定する
    1.2. 指定した背景はAppleScriptで変更可能 -> AppleScriptは/usr/bin/osascriptで実行可能
  2. 作成したシェルスクリプトsshコマンドのエイリアスに設定する

シェルスクリプト

#!/bin/bash


# Terminalの背景を変える関数
 set_profile() {
 /usr/bin/osascript -e "tell application \"Terminal\" to set current settings of first window to settings set \"$1\""
 }


# 接続先によって背景を指定する。SSHを終了するとHomebrew背景に戻る。
if [[ "$@" == *dev* ]]; then
 set_profile "Red Sands"
 ssh $@
 set_profile "Homebrew"
 elif [[ "$@" == *production* ]]; then
 set_profile "Ocean"
 ssh $@
 set_profile "Homebrew"
 else
 ssh $@
 fi

エイリアス

~/.bash_profile に追記

alias ssh="/usr/local/bin/ssh-change-theme"

確認

変更を適用

$ source ~/.bash_profile

sshしてみて確認する。

$ ssh hoge.dev.huga.co.jp

f:id:hatunina:20190707003732p:plain

$ ssh hoge.production.huga.co,jp

f:id:hatunina:20190707003807p:plain

参考

labs.septeni.co.jp maku77.github.io

絶対プロキシ突破するマン!(Win10, 認証あり, pip)

オラァ!!!!!

set HTTP_PROXY=http://user_name:passward@proxyserver:8080
set HTTPS_PROXY=http://user_name:passward@proxyserver:8080

pip --trusted-host files.pythonhosted.org --trusted-host pypi.org install hoge

user_nameにメールアドレス等が使われている場合、アットマークはhoge%40hoge.comのように%40を使うことでエスケープできます。
また、プロキシの設定だけではCERTIFICATE_VERIFY_FAILEDが発生することがあり--trusted-hostオプションをつけています。

参考

github.com

AWS Step FunctionsでTaskにParametersを設定してAWS Lambdaで読み込む

Parameters周りの話があまり見当たらなかったのでまとめました。

やりたいこと

AWS Step FunctionsとAWS LambdaでETLっぽいことをしたい!
初期パラメータはPassで渡し後ろのTaskでもパラメータを渡したい!

想定

下図のようなステートマシンを想定します。 select_taskでDB(RDS)からデータをセレクトしそれをinsert_taskでインサートします。
このとき、select_taskではParamsSettingsで設定した接続情報を使い、insert_taskではParametersで設定した接続情報を使うことにします。 f:id:hatunina:20190116215747p:plain

ステートマシンの定義

定義は下記のようになります。

{
  "Comment": "ETLフロー",
  "StartAt": "ParamsSetting",
  "States": {
    "ParamsSetting": {
      "Type": "Pass",
      "Result": {
        "rds_host": "host_1",
        "user_name": "user_1",
        "password": "password_1",
        "db_name": "db_1"
      },
      "ResultPath": "$.initial_params",
      "Next": "select_task"
    },
    "select_task": {
      "Type": "Task",
      "Resource": "Lambdaのリソース_1",
      "InputPath": "$",
      "ResultPath": "$.select_result",
      "OutputPath": "$",
      "Next": "insert_task"
    },
    "insert_task": {
      "Type": "Task",
      "Resource": "Lambdaのリソース_2",
      "InputPath": "$",
      "ResultPath": "$",
      "Parameters": {
        "rds_host": "host_2",
        "user_name": "user_2",
        "password": "password_2",
        "db_name": "db_2",
        "select_result.$": "$.select_result"
      },
    "End": true
    }
  }
}

DB接続城はキーバリュー形式でそのまま書くことができますが、select_taskの結果を参照するためには$を用います。
"select_result.$": "$.select_result"という部分ですが、キー部分にも$を含めないとバリューが変数として見なされず文字列としてTaskへ渡されてしまうので要注意です。

AWS Lambda関数

ステートマシンで定義した二つの関数です。

# select_task

def lambda_handler(event, context):
    rds_host = event['initial_params']['rds_host']
    user_name = event['initial_params']['user_name']
    password = event['initial_params']['password']
    db_name = event['initial_params']['db_name']

    # DBからデータをSELECTする処理
    # 結果をselect_dataへ格納

    response = {
        'select_data': select_data
    }
# insert_task

def lambda_handler(event, context):
    rds_host = event['rds_host']
    user_name = event['user_name']
    password = event['password']
    db_name = event['db_name']

    select_data = event['select_result']['select_data']

    # DBへINSERT処理

Parametersで設定した値はeventに格納されておりそのままのキーで読み込むことができます。
またevent['select_result']['select_data']でステートマシンで定義したキーで前のTaskの結果を読み込むことができます。

まとめ

Parametersで新しく設定する値自体は単純に読み込むことが可能ですが、前のTaskの結果を参照する場合には$を使う必要があるので要注意です。

参考

xp-cloud.jp

No space left on deviceが発生した時の対処

自分用メモです。

OSはUbunts 18.04 LTSです。

状況

GCEでkaggle APIでデータをダウンロードしていたら No space left on device と表示されエラー

対処1

おそらくディスク容量に空きがないと思われるので df -h で容量を確認する。
そして、容量を圧迫しているファイル・ディレクトリを適当に削除する。 今回は使っていたインスタンスが10Gしか容量がなかったため余分なファイル・ディレクトリ削除で解決した。

対処2

今回は該当しなかったけど、ついでに調べたのでまとめておきます。
ディスクが空いているのに No space left on device が発生する場合はinodeが枯渇している可能性あり。
inodeは df -i で確認する。
枯渇している場合は下記コマンドでどのディレクトリがinodeを使用しているか調査し不要なファイル・ディレクトリを削除する。

# 現在のディレクトリを調査
for i in `pwd`; do echo $i; find $i |wc -l; done

参考

inodeとは/inode消費が多いディレクトリの確認 – たぐたぐねっと

www.ivankuznetsov.com