from 30

30歳からwebエンジニアになったけど、思ったよりも苦しいので、その苦闘の記録をば

Chromeでユーザーを分けてマルチアカウント切替を管理する

経緯

個人の開発とは違って、仕事でAWSを使う時は複数アカウント管理が必須だと思います。

Servereless Daysなんかでマイクロサービスの話を聞くと、マイクロサービスごとにアカウント区切るのがいいみたいな意見も聞きます。

うちの場合は、ステージごとにアカウントを区切っています。

  • 開発・ステージ・本番
  • ソースコードとパイプラインを管理するマネージ

と言った感じで4つくらいになります。

それぞれのアカウントへのアクセス方法については、それぞれのアカウントにユーザーを作って、OneloginでSAMLフェデレーションして管理しています。

で、地味に困ることといえばアカウントを切り替えると、現在表示されているブラウザ内の他のAWS関連ページも全てリロードが必要になることです。

そんな時に有効なのがchromeで別ユーザーを作ることです。

方法

いたって単純なのですが、

f:id:kohski:20201117082721p:plain

chromeを開いたら、「ユーザー」メニューを開いてユーザーを追加するだけです。

アイコンを変更したり、名前を変更したりするのも有効ですね。

で、普段のユーザーより語順が若い名前をつけるとchromeの起動時にそれがデフォルトっぽく開いてしまうので注意が必要です。

あとは、一瞥してすぐにどのユーザーかわかるようにしたいと思います。

そういう時はchrome拡張のテーマを使って背景色を有効にするのがいいと思います。(本番環境のシェルのプロプトや背景色をかえるみたいに)

ここから入手可能です。

私は赤系で色の濃さで開発・ステージ・本番というふうに分けています。 (もっときれいにグラデーションになればいいのですが、デフォルトがこれしかなくて。。。)

f:id:kohski:20201117083246p:plain

まとめ

簡単ですが、以上です。

クロスアカウントでいろいろ確認しなきゃいけないときって、結構繊細な作業していたりすると思うので、

こうして視認性上げておくのって地味に大切だなと思った次第です。

ではでは〜

Linuxサーバーとしてラズパイを使ってみる。

経緯

普段の仕事ではLambdaを書いたり、CI/CDを構築したりって感じのことをやっています。

特にCodeBuildでbuildspec.yamlを書くときに感じるのですが、もう少しLinuxについての知識がほしいなと思います。

ということで、ラズパイをLinuxマシンとして使ってみようと思って買ってみました。

まあ、EC2とかでもいいんですけど、ゆくゆくIoTとか、ネットワークとかの検証マシンとして使おうと思っています。

買ったもの

www.amazon.co.jp

amazonで全部入りのキットを書いました。 本当に簡単でした。

組立て

youtube に基本的な組み立て方法が載っていますが本当に簡単です。

f:id:kohski:20201108101642j:plain

ヒートシンク貼り付け
② ファンとりつけ
③ ファンを基盤に接続

f:id:kohski:20201108101710j:plain ④ SDカードを挿す

って感じで終了です。 付属のドライバーで全て作業完了します。

本来はOSのイメージをダウンロードしたりする必要があるようですが、今回購入したキットだとmicroSDカードにraspbianというlinuxディストリビューションがインストール済みです。

で、あとはディスプレイ、キーボード、マウスを接続。

そのあと、電源を入れて初期セットアップしていきます。

設定はGUIでもできるので本当に簡単に進められます。

やったこと

  • 自宅の無線LANルータに接続
  • SSH接続を許可して手元のmacからSSH接続を確認
  • nginxを入れてwebサーバーとして立ち上げ、ひとまずネットワーク内から接続確認
  • sambaをインストールして、共有ファイルサーバーとしてセットアップ

という当たりを試しました。

感想

まだまだ本当に初歩的なものですが、実機でいろいろ設定してみると理解が深まるものです。

いろいろ検証を進めていきたいです。

gitでbranch迷子になったcommitをbranchに紐づける。

経緯

最近、新入りの派遣さんのサポートが多い。

自分のタスクに久々に戻ったら、なんだか前回作業が中途半端な状態で終わっていたみたいで、テストが通らない。。。

"TEMP"というコミットメッセージになっているし、一つ戻ってテスト通るかみてみるか。。。

$ git checkout <一つ前のcommit id>

<ここでまた呼び出し ... >
<「ああ、これは...こうこう...」>
<自席に戻る>

よし作業再開じゃ!

そして、起きたこと

そして、作業をそのまま進めて、よしorigin/devの変更をマージして、プルリク出すか!

あれ、見慣れぬメッセージが...

Warning: you are leaving 6 commits behind, not connected to
any of your branches:

  95b7500 fix: schema
  c40061a fix: tests
 ... and 2 more.

どうやら今のブランチにこれらのコミットが紐づいていないらしい。

さて、どうしたものか。。。

やっぱりエラーメッセージをよく読む

If you want to keep them by creating a new branch, this may be a good time
to do so with:

 git branch <new-branch-name> 95b7500

ということで、この通りコマンドを打って本来のブランチにマージしてことなきをえました。

まとめ

なんかgitなんて習うより、慣れろだと思ってけっこうラフに使ってしまっていますが、

たまに見慣れぬメッセージが出ると怖いですよね。

commitさえしていれば、あとはreflogして、google先生に聞けばなんとかなるってのが経験則的には体感できているものの、

もう少ししっかりと学ばねばならないなと思いました。。。

ubuntu on dockerでC言語のbuildができるように環境整備

経緯

アルゴリズムとデータ構造を学ぶために、C/C++をいじっていたら、

もっと低いレイヤーまで見て行って、最終的に0と1の世界まで実感できるようになりたいと考えるようになった。(絵に描いたような脱線である)

私の普段の仕事において、プログラムを動かすのは開発時は自分のmacの上でだし、本番はだいたいlambdaである。

でもいうなれば、lambdaだって世界のどこかにあるLinuxサーバーの上で動いているdocker環境なのだ。

と考えれば、ここいらで視野を広げる意味でもLinuxに思いを馳せてみるのもいいかもしれない。

読んでみる書籍

『ふつうのLinuxプログラミング 第2版 Linuxの仕組みから学べるgccプログラミングの王道 』(青木峰郎著) を読んでみようと思う。

冒頭でできるだけ実機で動かして ... というような表記があるが、当面はmac osでいけるだろと思っていたが、

linuxの学習においては、けっこうシステムコールやらライブラリやらでrootあたりのディレクトリ構造が重要だったりするみたい。

ということで、ひとまずはubuntu on dockerで環境設定してみたのでそのメモをば。(dockerでもなお、いきづまるようならそのとき考える)

前提

やったこと

1. Dockerfileを書く

今いるディレクトリをdocker上のワーキングディレクトリにする前提。

他のディレクトリを連携したい場合は、ADD のところを書き換える。

FROM ubuntu:latest
RUN mkdir /work_dir
ADD ./ /work_dir
WORKDIR /work_dir

RUN apt-get update
RUN apt-get -y install sudo && \
    sudo apt-get -y install build-essential && \
    sudo apt-get -y install vim && \
    sudo apt-get -y install man

2. Docker Imageをbuildする

Dockerfileがあるディレクトリをカレントディレクトリにする。

$ docker build -t ubuntu_practice .

もろもろのインストールが終わると、以下のようにSuccessfully builtの表示が出るのでimage id をメモ

f:id:kohski:20201105093011p:plain

3. docker runする

ローカルでvscodeでファイルを更新して、gccのbuildだけubuntuでやりたいという甘え(vimとか使わない的な)なので、ローカルのディレクトリをマウントして起動します。

$ docker run -it -v <host側のフルパス>:/work_dir <image_id> bash

一応、gcc -vコマンドでinstallがうまく行っているか確認

終わりに

これでいったんubuntuっぽい環境を立てることができたので限界まで進めてみます。

elasticsearchのdateでepoch_secondを使用する

経緯

普段はpythonを使用している。 日付関連は基本的にtimestampを使用している。 pythonのdatetimeモジュールにおけるtimestampは秒単位(10桁)になっている。

一方でelasticsearchのtype: dateはmillisecになっている。 elasticsearchにindexするときに、日付データを1000倍にする。取り出す時に1000分の1にするという方法もあるけど間違えそう。

また、検索についてはisoformatを使って柔軟に処理したいというニーズもある。

ということで、 - データ投入ではtimestampを使用 - クエリではtimestampもisoformatも柔軟に対応できる そんな方法はないと悩んだ次第である。

解決策

formatを使用して解決した。 以下はmappingsの抜粋。

"created_at": {
  "type": "date",
  "format": "epoch_second||date_optional_time"
}

formatは||を指定することで複数指定可能である。 今回は - epoch_second(millisecondsではなくて) - date_optional_time を登録してみた。

以下は投入データとクエリの例 とりあえずやりたいことはできている。

PUT /test/_doc/1
{
  "created_at": 1577876400 //10桁timestampで投入可
}

GET /test/_search
{
  "query": {
    "range": {
      "created_at": {
        "from": "2020-01-01T20:00:00" //フルisoformat
      }
    }
  }
}
GET /test/_search
{
  "query": {
    "range": {
      "created_at": {
        "from": "2020-01-01T20:00:00.000" //millisecまで込みのフルisoformat
      }
    }
  }
}
GET /test/_search
{
  "query": {
    "range": {
      "created_at": {
        "from": "2020-01-01T20" // 欠落しててもOK
      }
    }
  }
}
GET /test/_search
{
  "query": {
    "range": {
      "created_at": {
        "from": 1599999999, // 10桁timestamp
        "to": 1600000001
      }
    }
  }
}

最後に

日付関連はめんどくさい。

【小ネタ】エディタで正規表現をつかって一括でcamelCaseをsnake_caseに変換する

経緯

顧客のRDBをDynamoDBに入るようにモデリングしなおして、データマイグレーションを行っている。

当社のDBのattributeはスネークケース(単語と単語をアンダースコアで結ぶ。例:snake_case)を使用しているが、顧客のDBやソースコードはキャメルケース(先頭単語は小文字で単語と単語の切れ目は大文字にして区別。例: camelCase)を使用している。

ドキュメント作成段階においては、頻繁に書き換えが起きているのだがエディタで一括変換が簡単にできるのがわかったので記しておく。

方法

f:id:kohski:20201031081521p:plain f:id:kohski:20201031081532p:plain

上記はvscodeの例です。

  1. 大文字・小文字の区別をつけるオプション(Aa)をオンにする
  2. 正規表現(.*)をオンにする
  3. 上部分で大文字をキャッチしたいので[A-Z]
  4. その大文字部分をキャプチャしたいので()で囲む
  5. 下部分で\Lをつけてキャプチャした内容($1)で小文字に変換。直前に_をつける。

ということで一括変換ができました。

感想

変数の命名規則の付け方はプロジェクトごとに決まることが多いと思います。

キャメルケースの場合だと全部大文字にしたい単語(ID, FAX ... etc)があると切れ目がわからなくなるのでスネークケースの方が好みなのですが、

一括変換ができるのでもうほんとどっちでもいいなおいう気持ちになりました。

C++をやってみる

経緯

『プログラマーが知るべき97のこと』を読んでいて、他のパラダイムの言語を習得することで、元の言語の理解も深まる旨記載があった。

目下、目の前の仕事を楽にするにはもっとコーディングがうまくなる必要があると考えている。

コーディングが上手いってなんだろう。。。と考えてみるとどうやら3つくらいにわかれるのかもしれない。

  1. アルゴリズムとデータ構造をしっかり理解し、メモリや計算時間の最適化を目指す
  2. デザインパターン等を理解し、目の前のワークロードを適切にモデリングし、コードに落とし込める
  3. フレームワークIDEを使いこなして開発効率を高める

いずれも大事だけど、なんとなく1.の習得に時間がかかりそうだと思い、アルゴリズムに挑戦しようと思う。

そうなってくると必然目につくのが、競プロ(特にAtCoder)なわけだが、多くの解説がC++で書かれている。

ということで、C++の習得を最近は目指している。

やっていること

簡単な基礎の文法はUdemyの講座を一周流してみた。

pointerの理解は曖昧だが、まだ仕事で書くわけではないのでいったん放置。

で、今はけんちょんさんの本を勉強中。

備忘

で、ここからは本題だけど、ちょっとしたSyntaxとかでメモしておきたいことをここにメモしておく。

1. C++ 11を使う

C++コンパイルをするときはg++コマンドを打っている。 xcodeとともにinstallされたg++だとversion11の公文(範囲loop, auto型など)は使えない。 (ちょっとこのへんのツールの理解は曖昧です)

対症療法的にですが、

$ g++ --std=c++11 <file/path>

で使用可能になった。

2. vectorいじり

pythonとかjsから入門した私からしたら、配列というのは言わずもがな可変長なのだが、CやC++の配列は定義時に長さを指定する必要がある。

そこで、vectorというSTLを使用する。 STLとはStandard Template Libraryの略で、 内部的にC++のTemplate構文(型を変数みたいに扱う)を使っていろんな局面で使えるようにしているLibraryのことである。

なお、あんまりvectorでは個別要素の操作は想定していないようである。

#include <vector> // STLの読込み

vector<int> a; // aというvectorを定義

a.assign(50, -1) // 50の長さをvectorを初期値-1で初期化