だらだらと思いついたこととか書くブログ

エンジニア的なネタとか備忘録とかを書いていく予定

RESTについて - part.1

RESTの成熟度レベル

  • Level 0:SOAPXMLでやりとりをするHTTP通信 → URI と HTTPが 1to1
  • Level 1:URLでリソースを表すようにする(リソースを動詞でなく名詞で表す)
  • Level 2:HTTPメソッド(GET, POST, PUT, DELETE)を正しく使い分けている
  • Level 3:レスポンスの中に関連するリンクを含める → HATEOAS

[アプリケーションのRESTful度合いをどう計測するか|https://www.infoq.com/jp/news/2011/05/measuring-rest] [RESTとは何か|http://qiita.com/aosho235/items/125af74e2eab66c7a816] [Richardson Maturity Model|https://martinfowler.com/articles/richardsonMaturityModel.html] [フロントエンド開発者の僕にもやっとわかった!RESTfulの本当の意味|https://www.webprofessional.jp/what-does-restful-really-mean/] [第3回 マイクロサービス アーキテクチャ 読書会 メモ|http://nashcft.hatenablog.com/entry/2016/09/08/014818]

JJUG CCC 2017 Springに行ってきた

今更ながら参加してきたので当日のメモなどを 本当に適当なメモ書きレベルなので後で編集したい・・

レガシーアプリケーションの巻き取りとモジュール分割

ブランチ運用

テスト(CI/CD) 単体 → junit(validation etc) 画面単体 結合

@Runwith(Enclosed.class) → レビューアに優しいテストコード

selenide → 自動テストに利用

SpotBugs

tool

コーディング規約ならCheckStyle 問題検出は、PMD、SpotBugs、CheckerFw、 error-proneから選ぶ感じ

findbugs

onlyAnalizeで対象クラスを絞る visitorsで利用detectorをけずる(何を優先してチェックするのか) → これは使いやすいと思うとのこと

Spring cloud stream

Batchをスケールアウトしたことで、ポーリングによるRDBへの負荷が高まった → spring cloud streamを使った仕組みにつくりかえ => イベントドリブンに作り変え

SCS(spring cloud stream)

  • メッセージドリブンなマイクロサービスが実装しやすい(pub-subモデル)
  • spring bootアプリケーション
  • consumer groups → レポート作成のスケールアウトが容易になった => これによりノードごとに別IDの処理が行えるようになった(Batchをスケールアウトしたことで、ポーリングによるRDBへの負荷が高まった)
  • binder application → アプリ-ミドルウェア間が疎結合になるらしい(共通のdestination設定でOK)

spring batch job管理テーブルに大量INSERTでエラー(Sink側のSpring Batchが大量に起動した時に、Job管理テーブルに大量のinsertが流れてエラーに… )

  • maxAttemptの調整 → これだけだと不十分
  • DeadLetterQueue → エラーリカバリ用のMQを用意 => SCSのautoBindDlqをtrueに する

→ただ根本対応にはなっていないのでJobRepository側の対応方法を調査中。。

ポーリング型からイベントドリブンに変えたことでスループットが向上

CloudFoundryへ移行してスケールアウトが容易にできるようにする  → cflogin, cfpush? => この辺も含めて謎なので調べてみる

c.f) 第2世代への作り変えについて https://www.slideshare.net/techblogyahoo/jjugccc-cccf1-phpjava

c.f) pulsar https://www.infoq.com/jp/news/2016/10/pulsar

Jigsaw

・module-info.java - dependency disclosure scope → JAR内のこのファイルにモジュールの依存を記述する(module-info.javaでjarのメタ情報(依存性と公開範囲)を管理してModule化)

java –list-modules、現状73個のモジュールがリストされる

Cookpad tech kitchen#8に参加してみた

Cookpad tech kitchen #8に当選できたので初参加して来ました 色々と経験出来たのでメモ

tech kitchenについて

まず、ガッツリ料理が出てきたのにびっくり。。 野菜もふんだんに使われていて、見た目も味もステキな料理が食べられてこれだけでも来た価値が・・とちょっと思ってしまった笑 飲み物も提供されていて、セッション始まるまでは何しに来たのかちょっとわからなくなるほどのおもてなし感

セッションについて

非同期なジョブ

  • ワーカーがスケーラブルではない  → キューをトリガーにdockerでワーカーが必要な分だけ起動する  → activejobとAWSSNS,SQSなど)を活用

  • Barbeque → ジョブキュー管理システム

  • Hako → コンテナ管理ツール

アプリとワーカーで同じイメージから起動しているため環境差分が無くスケールしやすい

kuroko2

クックパッドのジョブ管理システム

美しいバッチの壊し方

  • Bricolarge
  • 1ジョブ = 1SQL → よいバッチ(運用しやすいバッチ=障害の対応がしやすい)を作るため

美しいバッチとは!?

  • I/Oの対象ごと(DB、テーブル、ファイルなど)にジョブ分割
  • ジョブ管理システムで結合

http://www.shigemk2.com/entry/cookpad_tech_kitchen_8_3

Others

Hakoとは

dockerで賄えないDNSやDB接続情報なども設定ファイルで管理できる(?)ツール

https://techconf.cookpad.com/2017/yoshiori.html

DWHについて

DBA的な仕事もしつつアプリ(バッチ)もガッツリ書く ブリコラージでジョブ管理をしているのでバッチはほとんどRuby製(ただし、中にはシェルなどを呼び出している部分も・・) DWH(Amazon redshift)のキャパ的にはバッチ処理自体では全然余裕があるが、DEVやビジネスサイドで呼ばれるクエリ処理がガンガン来るため大変・・(グルーバル展開もしているため、それこそ一日中来てしまう。。)

Cookpadの開発環境について

本番と開発環境のDBのレプリケーションについて

本番DBと開発DBの間にもう1個DBがかまされている(※わかりやすさのため準本番とする) 本番DBから準本番DBへのレプリケーションステートメントベース 準本番から開発DBへのレプリケーションはレコードベース(IDが変わってしまうなどの問題があるため) 準本番から開発DBへのレプリは開発用のデータはID1から、レプリは必ず6万以上から、といったような感じでMySQLのAUTO INCREMENT(?)機能などを活用して運用している どうしてもレプリ時にエラーとなってしまうデータ(重複エラーなど)は無視する 詳しくはブログにも書いてあるとのこと

開発チーム、体制について

リリース(?)、システムははリクエストごとにdockerイメージがスケールしていくような構成になっている → スケーラブルな仕組み 開発チームはビジネスサイドのディレクターさんなども含めた2〜3人とかの小規模なチーム プロジェクトにチーム(人)が紐付いているような感じで体制は流動的

セッションはRubyAWSも使っているわけではないため概念的な部分とかしか理解できず、持ち帰れたものが少なかったかも・・ ただ、やっぱりバッチがどうあるべき、どういう問題を抱えていてこうした、みたいな話が聞けて良かったし、個別にお話させて頂いて色々聞けたのも良い機会でした!

ダンスレッスン@20170605

ダンスレッスン

ちゃんとしたプライベートレッスンを受けるの約2年ぶり・・ 久しぶりのレッスンかつ初めて習う先生、初めて行ってみたスタジオで色々と新鮮さや学びがあったので忘れないうちにメモ

 レッスン対象

チャチャチャ - バリエーション

 レッスン

全体

1個1個の音をはっきりさせる → 音を一つ一つ言いながら動けるくらいにはしておく 2人で動くところはどこの音の瞬間にどのアクションになるのかはっきりさせておく

出だし

4でキック、1でアクション 次は3で右足を寄せるところまでいく

1で振り向いたところ~

1でパートナーと合わせてアクション その後は右のアームを下げていきながら、床を踏んでボディテンションを上げていく

タイムステップetc

2&3で右にタイムステプ その後は4で左足を寄せる、&で左足に踏み変えながら180°回転、1で右足を踏む

シャッセで移動

1個の音(半拍)で踏み変えて、次の足を出して踏む直前まで動く 1個1個で出て踏んでいるようでは遅い

前に移動

右→左→右で前に移動、&で左、4で右足(+1で左足?) その後は4で自分が前に出ながらパートナーを引く(この時に右手でしっかり押さえる) 1で今度は自分が下がってパートナーを出す

入れ替わり~ランジ

4で左足体重で180°回転(この時、やや自分側に体を引く感じ) 1で右足に乗る 2で左足をやや入り気味に出して3でロンデして1でランジ

パートナーのスピン

パートナーがスピンするところではムリに回そうとしない(ワクを作ってパートナーが回転する場所を作ってあげるだけくらいのイメージ) 1でラインを作るきっかけを与えるだけくらいで良い

いろいろ教わったのでちゃんと動きながら理解してモノにしたいし、他のところでも使えるようにしないとな。。

ドメイン駆動設計 - Part.1

ドメイン駆動設計について調べてみた(その1)

まずは概念的なものをまとめてみる

ドメイン駆動設計

ドメインロジックの断片化

プレゼンテーション層

  • 画面の入出力

アプリケーション層

  • データ処理の手順

データソース層

  • データベース操作

ドメインロジックを"ドメインモデル"に集約する ドメインを学び学んだことをコードで豹男減する

分析設計(分析しながら設計する)

技法

オブジェクト指向

  • 抽象データ型 → 人間の知りたい事/やりたいことを定義する => 抽象化=人間の関心事に近づける
  • モジュール構造 → 抽象データ型を部品として全体を組み立てる

業務の知りたい事/やりたい事をクラス名とメソッド名で表現する

XP

変化に適応するソフトウェア開発

  • フェーズに分けない → 毎日少しずつ成長する
  • 効率を追求する

ドメイン駆動設計 分析しながら設計する - SlideShare https://www.slideshare.net/masuda220/ss-74962182

ドメイン駆動設計 基本を理解する https://www.slideshare.net/masuda220/ss-59756718

ダンスメモ@20170513

久しぶりにチャチャ&ルンバのベーシック中心のオシャレなフィガーとそれを踊るにあたってどう動けばいいのか?という内容についてのグループレッスンを受けたのでメモ

ChaChaCha

カール

思っている以上に早めにリードする → よく使うホッケースティックなどとは違う動きになることを早めに知らせる

後退~ファン

後退の時にはパートナーを自分の左前にリードする(それと真逆に自分が動く)  → 相手に来て欲しい位置と反対側に自分が移動する  => 自分の左(もしくはやや左後ろ)くらいにリードしてしまいがちなので注意する

クローズドヒップツイスト~スパイラル(?)

ワクでパートナーをリードしてから自分が右足に体重移動することでパートナーを自分の左に向けて前進させる  → そこから左にアームを上げてスパイラルのリード  => 回転後はしっかり左のアームを元の高さまで戻すことに注意

Rumba

アレマーナ

このルーティンでのアレマーナは通常と違うので左シェイプ(?)を掛けて行う

アレマーナのあと

アレマーナで掛けたシェイプを元に1カウントで入れ替わる  → この時、右足体重

ホッケースティック

ホッケースティックのあとは自分の右前(逆壁斜め)に対してオープンで出ていく感じになるので、アレマーナ~踏み変えの後の後退で自分が左後ろに後退してリードするようにする

感想

特にリード部分は結構、 ・よくよく考えるとそうだよなって思うところ や ・そういえばそう教わってはずだけどすっかり忘れてしまっていた ということがたくさんありとても勉強になったになった良い時間でした

あと、久しぶりにちゃんと色々と考えながら踊ったのもあり、何か「ホッケースティックでのチェック」や「キューバンロックスでのチェック」、はたまたランジの後のファンなど今更ながらどう踊るのが正解なのか迷子にになった。。

また定期的に練習するようにしたいな、と思っていることもあり、教わったことを実践できるようにしつつ、この辺の迷子課題の解決策を見つけたいところ ともあれ、やっぱりダンス楽しいし、新しいことを覚えられるのは楽しいなーとあらためて思えた一日でした

 参考

すっかり忘れていたのでダンスのアライメント、LODについて

socialdance.asia

vagrantでelasticsearch&kibanaを動かしてみる

久しぶりにvagrantをいじってみた

インストールは以前に試していたのでその他の設定を

ネットワークの設定 [ここ(http://qiita.com/kidachi_/items/e63c1607705178aa257c)]を参考に設定

で、色々入れてみるもメモリが足りてないことが判明

メモリの拡張 [メモリの設定(http://d.hatena.ne.jp/tbpg/20131107/1383834516)]を参考にvagrantfileを編集

メモリが設定したサイズになっていることを確認 [vagrant@localhost ~]$ free total used free shared buffers cached Mem: 1020540 181204 839336 0 12904 101644 -/+ buffers/cache: 66656 953884 Swap: 2621432 0 2621432

elasticsearch最新版を入れてみる https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.0.0.tar.gz tar zxvf elasticsearch-1.0.0.tar.gz mv elasticsearch-1.0.0 elasticsearch

elasticsearch.ymlを編集 http.port: 9200

kuromojiをインストール sudo ./bin/plugin --install elasticsearch/elasticsearch-analysis-kuromoji/1.5.0

servicewrapper https://github.com/elasticsearch/elasticsearch-servicewrapper

sudo mv service/ /usr/local/src/elasticsearch/bin/

sudo ./elasticsearch install

sudo /etc/init.d/elasticsearch start

kibanaも入れてみる

wget https://download.elasticsearch.org/kibana/kibana/kibana-3.0.0milestone5.tar.gz

tar xvfz kibana-3.0.0milestone5.tar.gz

mv kibana-3.0.0milestone5 /var/www/html/kibana

あれ、、動かないと思ったがiptablesの設定が足りてなかったので、対応すると kibanaの画面が!

・esとtd-agentの連携 参考サイト

-連携用プラグインのインストール /usr/lib64/fluent/ruby/bin/gem install fluent-plugin-elasticsearch --no-ri --no-rdoc -V

-td-agent.confの編集

apache-loggenで疑似ログを出力しkibanaで確認 apache-loggen --rate=10 --rotate=60 --progress /var/log/httpd/access_log