渡り鳥の旅路

元半導体系エンジニア、今Webエンジニアの雑記

PHPer目線のRailsチュートリアル学習メモ#2

Ruby/Rails 学習メモ

#1はコチラ

続けて雑に書いていく

ソースコードはチュートリアルから引用

DBまわり

ORMについて
  • RailsではActive Recordを採用している。

  • Active RecordのオーナーはPostgreSQLに対するメンテは熱心だが、MySQLに対して冷たい(kamipoさんがMySQLのために日夜コミットされている。感謝)

  • CakePHPではEntityがあったがRailsではどうか？

  • LaravelのORMはEloquent
ほか
  • Controller名は複数形、Model名は単数形になるのはCakePHPと同じ
  • 同じくマイグレーションもある (そもそもRails->CakePHPだけど)
  • グヮッ https://youtu.be/2Ag8l-wq5qk
7.1.2 Userリソース

https://railstutorial.jp/chapters/sign_up?version=5.1#sec-a_users_resource

例えばUserモデルを作成済の場合、routes.rbにresourcesを記述するだけで、RESTfulなリソースに必要なアクションを利用できるようなる。

config/routes.rb

.
.
.
resources :users

Railsのルーティングについてはコチラ

7.1.3 debuggerメソッド

https://railstutorial.jp/chapters/sign_up?version=5.1#sec-debugger

byebug gemを入れるとdebuggerメソッドを使い直接的なデバッグを遂行できる。

例えば下記のように書いて/users/show/:idにアクセスすると、debuggerが差し込まれた時点での状態を確認することができる。

class UsersController < ApplicationController

  def show
    @user = User.find(params[:id])
    debugger // ココ
  end

  def new
  end
end

例えば下記のようにdebugger時点でのuserが持つ属性を確認することができる。

@Railsサーバを立ち上げたターミナルのbyebugプロンプト上

(byebug) @user.name
"Example User"
(byebug) @user.email
"example@railstutorial.org"
(byebug) params[:id]
"1"
  • CakePHPだとDebug Kit - 3.6はあったけど、debuggerは用意されてないはず（IDE使えばできるけど。PhpStorm + Xdebugとか）

PHPer目線のRailsチュートリアル学習メモ#1

学習メモ Ruby/Rails

雑に書き残す。

下記、コードはRailsチュートリアルから引用

自分のバックグラウンド

プログラミング歴約1年、フレームワーク歴はCakePHP半年ほど

Rubyはすべてオブジェクト

って書いてあるけどメソッドは違うらしい。

言語の歴史的経緯として下記の違いがある。

  • Rubyは端から純粋なオブジェクト指向を目指して作られている
  • PHPは後からオブジェクト指向に対応

記述を短縮できるところはガンガンやっていき

4.3.2 ブロック

https://railstutorial.jp/chapters/rails_flavored_ruby?version=5.1#sec-blocks

symbol-to-proc記法

>> %w[A B C].map { |char| char.downcase }
=> ["a", "b", "c"]
>> %w[A B C].map(&:downcase)
=> ["a", "b", "c"]
4.3.3 ハッシュとシンボル

https://railstutorial.jp/chapters/rails_flavored_ruby?version=5.1#sec-hashes_and_symbols

  • ハッシュはPHPでいうと連想配列のこと
  • ハッシュのキーを次のような形式でかける（シンボルという）
  • Rubyではハッシュのキーは文字列よりシンボルを使うのが一般的

例えばuserというハッシュを作る場合、

これが

user = { "name" => "Taro Yamada", "email" => "aaa@aaa.com" }

こうなって、

user = { :name => "Taro Yamada", :email => "aaa@aaa.com" }

こうなる。

user = { name: "Taro Yamada", email: "aaa@aaa.com" }
4.4.5 ユーザークラス

https://railstutorial.jp/chapters/rails_flavored_ruby?version=5.1#sec-a_user_class

attr_accessorでシンボル指定しおくと、自動でgetter/setterが定義される。

各々定義したい場合はattr_reader/attr_writerを使う

  • attr_reader -> getterを定義
  • attr_writer -> setterを定義
class User
  attr_accessor :name, :email

  def initialize(attributes = {})
    @name  = attributes[:name]
    @email = attributes[:email]
  end

  def formatted_email
    "#{@name} <#{@email}>"
  end
end

bryankawa.hatenablog.com

【参加レポート】#しがないラジオmeetup 1 とTwitterライブ

参加者の皆さんのレポートがはやすぎて完全出遅れだけど、せっかくなので書きます。

昨日いつも聴いているPodcast「しがないラジオ」のミートアップがあり、ちょこっと運営お手伝いもしつつ参加してきました。

shiganai.org

shiganai.connpass.com

レポート的なあれこれ

この記事を書いてる今も続々と参加レポートがあがってきているので、当日の雰囲気はそちらを見て頂ければと思います。

とりあえずハッシュタグ貼っときます。

#しがないラジオmeetup

ハッシュタグのTLを追いきれんwという方もいると思うので、 そんな人はVTRyoさんの素晴らしすぎるまとめ記事と、 てぃーびーさんのブログにレポート記事リストがあるのでそちらを御覧ください。

愛されがつよい

今回参加しててすごく感じたのですが、パーソナリティの2人の愛され感がすごいなと感じました。

会場にいないてぃーびーさんからの遠隔LTがあったり

OSCAさんのLT中、パーソナリティ2人とのやりとりがあったり、

また、LTの発表内容がしがないラジオの影響を受けて行動を起こしたら環境が変わって感謝いっぱいの内容だったり。

あと、今回地味にすごかった点として登録者の出席率が9割超えしてたのもすごかったです。

Twitterライブで得たTips

あまり表立って告知されてなかった気がしますが、 今回は当日参加できない遠隔地のゲストさん＆リスナーさん向けにTwitterライブをやっていました。

普段から写真や動画を積極的に撮る方ではないのでiPhoneあれば何とかなるだろ〜とほぼ準備ゼロでやった結果、 色々つらみと発見があったので今後はじめてやる方向けに書き残しておきます。

ポジション大事

ライブ撮影する上であらかじめ見通しの良さを考えておいた方が良いなと感じました。

たまたま運が良かったのですが、今回はプロジェクタに向かって椅子が並んでいて真ん中を通れるように通り道があったおかげで、 一番うしろからでもプロジェクタ全体を写しやすい状態でした。

雑に書くとこんな感じです↓

f:id:roo_oregon:20180524220323p:plain:w300

ぶっちゃけ撮り慣れてる人的にはポジション取り大事なのは常識なんだと思いますが、 特に発表の動画撮影は場所を固定することが多いと思うので会場レイアウトを考えるときに考慮しておいた方が良いなと感じました (小並感)

三脚あった方が良いよ

単純に手持ちで撮ると腕がプルプルになるよねという話だけではないです。 今回自分で撮影した動画を見返してみると、結構ゆらゆらして自分で見返して酔いそうになったので、 固定は大事なんだなと思いました (小並感)

Periscopeアプリ入れとこう

今回ハッシュタグ上で動画を流そうと思ってTwitterの公式アプリ上でライブ機能を使いました。

ツイートするときに表示されるライブってやつですね↓

f:id:roo_oregon:20180524222150p:plain:w300

実はこの表示、下記のようにテキストを入れてる状態だと表示されません。。 （当日はライブスタートと同時にずっきーさんにリツイートしてもらい対処してましたw）

f:id:roo_oregon:20180524222655p:plain:w300

当日は時間もなくテンパってたので見つけられなかったんですが、写真マーク押したら普通に出てきますw

f:id:roo_oregon:20180524223249p:plain:w500

で、あとはさっきと同じくライブボタンを押すだけでしょ？ってなると思うんですが、 なぜかこの場合「Periscopeアプリをインストールしますか？」とメッセージが出てきて中々撮らせてくれません（怒

というわけで、事前にインストールしておきましよう(｀･ω･´)

アプリインストール済だとまずストリーミングの初期化が始まり、

f:id:roo_oregon:20180524223920p:plain:w300

完了すると撮影開始できるようになります。

下の例だとハッシュタグのみですが、もちろんコメントやリプライを入れることもできます。 ちなみにライブを止めると自動的にツイート投下されてしまうため、コメントは先に入れておきましょう。

f:id:roo_oregon:20180524223932p:plain:w300

撮り終わったら右上のバツボタンを押してライブを止めましょう。

VTRyoさんも書いてますが、ライブ撮影以外も遠くから参加できない方向けに他にも色々できることありそうだな〜と思いました。

というわけで、、

楽しかったよ！

f:id:roo_oregon:20180524211544j:plain

【LTしてきた】WEBエンジニア勉強会 #07

勉強会

タイトルどおりLTしてきたのでそのまとめ

今回は7回目のWEBエンジニア勉強会に参加してきた。会場はYahoo! LODGE

前回の参加がきっかけで運営をお手伝いすることになり、そのまま勢いで発表申込みしたのが背景。

web-engineer-meetup.connpass.com

自分の発表

イベントが公開されたのはだいたい一か月前。その時はまだ発表内容も決まっていなかったため、とりあえず「初心者Webエンジニアを支える技術」といういくらでもピボットできそうなタイトルで申し込んだ。GWも挟むし何とかなるだろう、とわりとお気楽な感じでに申込みボタンを押した。

じつのところ発表テーマが固まったのは勉強会の3日前くらいだったんだけど。。

というのも、最初はわりとエモめな内容を考えていてストーリーラインも何度か推敲して形にはなっていた。だけど自分の中で「せっかく勉強会で発表するんだからお気持ちだけで発表するのはもったいない」「ちゃんと技術寄りなことで発表したい」「せっかくだから新しくインプットしたことを整理したい」という悶々が続き、直前になりSQLじゃね？っと腹が決まりそこから内容を考え直した。

テーマが決まったら次はどんな流れにするか？

基本的には業務中に自分がハマったことベースで、その時には時間優先で終わらせたことに対してちょっと原理的なところを深堀してみたり、多言語・フレームワークに視野を広げてみたりと厚みをつける方向で情報を整理していった。

お勉強方向に深堀りしすぎると眠くなるので、ある程度のところで参考文献の紹介に留めて具体例も盛り込んでいった。 Webの世界はオープンですばらしい参考文献が転がっていて、感謝感謝と念じながらふんだんに引用させていただいた。

スライドの基本ができたら何回か見直して、説明が飛びすぎな部分にページを追加したり、プレゼンを楽しんでもらうためのお気持ちページを入れた。 あとは細々したところを調整したつもりだったんだけど、発表後に見返してみると色々粗がみえてきたので次に活かすということにしてそっとブラウザを閉じた。

というわけで出来上がりがコチラ↓

www.slideshare.net

発表を振り返ってみると、ゆるさを意識しすぎて説明が雑だったなと思う。あとは端折るつもりのところを全部しゃべりきったのでたぶん時間すぎちゃってた。もうしわけない

SQL改善例のおねだりしたら #WEBエンジニア勉強会の方でいくつかコメント頂いてて、ありがとうございます。

みなさんの発表

色々テンパっててまとめきれてないので、詳しくはOSCAさんブログの勉強会レポートで！

techblog.oscasierra.net

運営お手伝い

事前にslackでやりとりしてたけど、実働は当日のみなのでサクッと書く。

詳しくはOSCAさんブログに書いてあるけど、今回は会場がYahoo! LODGEでのリベンジ開催ということでOSCAさんの熱を感じる仕事ぶりを間近（リモートだけど）で見ることができた。職業柄ってのもあるかもしれないけれど、すごく周到な準備をされていてとても勉強になった。

そんな姿を見ていたので、当日は気づいたことがあれば何でもやるぞ！ということでちょろちょろと動き回っていた。

まとめ

運営＆発表やると打ち上げのビールがうまい(・∀・)

おまけ

今回Slideshareに資料をアップロードをするときハマったので、下記リンクも貼っておく。

KeynoteのスライドをSlideShareにアップロードすると日本語が表示されない問題

基本的に日本語サポートをしてないらしい。。

プログラマーになりたいと思った人がやるべき７つのこと、を読んで自分の勉強体験を思い返す

学習メモ

自分がIT業界で転職活動する上でとても参考にしたAXIAの社長ブログがある。

そのブログで最近下記のような記事が書かれていて、このところ自分の経験の棚卸中だったので記事の流れに沿って勢いで書いてみる。

axia.co.jp

１. とりあえずプログラミングしてみる

まだ前職にいた頃、転職を視野にいれてプログラミングを勉強しようと考えていた。

元々メーカーで開発職だったこともあり、個人的に関心がある分析系のライブラリが多く初心者がとっつきやすいと聞いたPythonで勉強すること決め, 色々と本も買ってみた。

しかし元々プログラミングに抵抗がある（大学でC言語で挫折した）初心者が最初から本で勉強するのはハードルが高く悶々していたところ、 たまたま見かけたSchooというサービスでPython入門の授業があると知り藁にもすがる思いで受講してみた。

schoo.jp

大げさかもしれないけど、この授業が今自分がWebエンジニアになる大きなきっかけとなる。

下記の理由で、Schooを利用した勉強が初心者の自分にとっては本で独学するよりも合っていた。

  • 動画は情報量が多く本より飽きにくい
  • 現役のエンジニアが何を考えながらプログラミングしているかを話してくれる
  • Schooの特徴でもある対話型のスタイルだと、詰まりやすいところの補足説明が多い

のちのち存在を知ったProgateも素晴らしいサービスで自分も大変お世話になったが、自分にとっての原点はSchooだった。

最初のプログラミングへの心理的ハードルを乗り越え、これならよりガッツリ勉強に取り組んでも大丈夫だなと考えIT留学を決めた。

そんなこんなでプログラミングの最初のハードルを越えた自分だったが、すぐに次のハードルにぶつかった。

授業や本のコードをなめるだけではプログラミングに手慣れるまではいかない

そこで何か問題をひたすら解いて、コードを書くという感覚を手に馴染ませたいと思った。

ググってみると下記のようなサイトに問題がたくさん置いてあるのを知る。

paiza.jp

AIZU ONLINE JUDGE: Programming Challenge

手始めとしてPaizaで初級ランク(C, D)の問題を全部解くことにした。C, Dランクだけでも合わせて100問以上あり、修行のごとく解きまくった。

Dランクは単純計算が多いのだけど、Cランクはちょっとしたストーリーに乗せて出題されるため楽しみながら続けられた。

毎度反省点を見直しながらCランクを解くうちに、コードを書き始める前にどんなロジックで書くかプランを組み立てるべきということが分かってきた。

Bランクの問題も解けるようになった段階で留学期間が始まり、Paizaでの学習には一区切りつけた。

２．何をやりたいのかを明確にする

これに関してはかなりふわっとしてたが、自分の生き方の選択肢を増やしたいなと考えていた。

前職がメーカーで、製品があるところに自分がいなければならないという縛りにつらみを感じていた経験がベースにあり、 住む場所や働く時間を人生のフェーズに合わせて変化させていけるようにしたかった。

他にも理由はあるけど、ここではさらっと流す。

３．自分が目指す業界のことを知る

この点については、主に2方向から調べた。

  • 現役のエンジニア
  • 積極的に発信してる方のブログ
  • テック系Podcast

1つ目のに関しては、留学先のメンターさんが経験豊富なエンジニアだったため、授業に限らず休憩やご飯の時間に色々お話を聞いた。 あとはよく遊びに行っていたシェアオフィスで現地のエンジニアやマネージャーと出会う機会があり、積極的に情報収集をしていた。

2つ目はブログで、IT業界は他と比べて個人で情報発信してる人が多いため調べようと思えばいくらでも出てくる。厳しい話と夢のある話、バランスよい感じでリンクを貼っておく。

axia.co.jp

kuranuki.sonicgarden.jp

www.hassy-blog.com

最後はテック系Podcast。最近Webエンジニアを中心にテック系Podcastが増えている。自分は留学仲間からRebuild.fmの存在を教えてもらったのがきっかけで、今でも色々なチャンネルを発掘しては聴いている。

ぶっちゃけるとRebuild.fmは前提知識がないときついので、しがないラジオが聴きやすくておススメ

rebuild.fm

shiganai.org

４．本格的にスキルを習得する

ここはスクールに通う人はそのカリキュラムにも寄ると思う。 自分の場合はHTML/CSSからJavaScript(jQuery)/PHP(Laravelのさわり)までを一通りやった。

個人的に良かったのは下記の点

  • 初日から「わからないことはまずググれるようになれ」スタイルで教わった
  • フレームワークを触る前に生PHPでMVCモデルを採用したアプリを作った
  • Vagrantを用いた環境構築も体験した
  • Gitを使って小チームで開発をした

教わったメンターさんがフリーランス経験者だったこともあり、実践投入を意識した形で勉強できたように思う。

実は案件を受注してみるカリキュラムもあったが、欲しいスキルが得られなさそうだったので自分はやらなかった。 （自分はサーバサイドを目指したが、クラウドソーシング案件はフロント寄りが多かったため）

５．何でも良いので何か一つ作ってみる

2-3人でチームを組んでいくつか作った。作品と機能はこんな感じ↓

  • ECサイト：商品一覧/詳細表示、おススメ商品表示、カテゴリ分け機能、カートに保存、購入
  • Twitterもどき：ログイン/ログアウト、タイムライン、プロフィール画面、フォロー/アンフォロー

あと上述した受託案件をやらない時間で、Raspberry Piを触っていた。

OSのインストールからちょっとした環境構築まで自分でやるため、正直ハゲそうになりながら下記のようなことをやっていた。(Raspberry Piは初心者が独学でやるのは危険なのでArduinoから始めるのがおススメ)

  • Juliusというエンジンを使った音声認識
  • Siriに話しかけたら8x8のLED上をインベーダーゲームのキャラが走る

2つ目の構成イメージ↓

f:id:roo_oregon:20180408153329p:plain

実は自分のやったことを発表するためにIoTイベントを企画したのだけど、それはまた別の機会に。

６．ソースコードはGitHubで公開する

しょぼくて恥ずかしいと思いつつも、先述のTwitterもどきのソースコードを載せていた。フレームワークも使えていない頃のやつなのでそろそろ隠したい。

７．取り組んだことはブログで公開する

これは転職後にやり始めたので、これから継続しておきたい項目。

最近は勉強会の参加メモばかりなので、もうちょっと自分のことをアウトプットしていきたい。

まとめ

今回書いたことはだいたい8か月間でやった内容

IT業界に入ったら入ったでこの100倍くらいやることが見え、やっていかねばと思う今日この頃。。

WEBエンジニア勉強会 #06に参加してきた

勉強会 Web

勉強会に参加してきたので復習用メモです。

web-engineer-meetup.connpass.com

WEBエンジニア勉強会の特徴

  • 若手エンジニア向けに役立つ内容
  • 言語に偏らない汎用的な技術について学べる
  • 発表初心者でも登壇しやすい雰囲気

ハッシュタグはこちら↓

#WEBエンジニア勉強会06 hashtag on Twitter

またこの勉強会の主催者がどんな思いで勉強会を始めたのか、しがないラジオのsp.6a, bで聞くことができます。

shiganai.org

今回の会場は渋谷にあるココラブルさんのオフィスです。 勉強会はまるで秘密基地のようなかっこいい部屋で行われました。

アイスブレイクは会場を提供して頂いた@ariarijpさん

@ariarijpさんはRedashのコミッター兼Redash Meetupの運営者でもあり、 この勉強会の事前アンケート結果もRedashで表示して見せてくれました。

発表とメモ

CSVと戦うためのPandas by @ariarijpさん

一発目の発表は引き続き@ariarijpさん

「Redashで扱うDB用データの前処理をPandasでやってみたよ」というお話でした

PandasはCSVなどのデータソースをデータフレームにして使う

->行や列の抽出、各要素への関数適用など、Pandasを使うとデータ分析に必要な前処理などが簡単にできる。

今AidemyでPandasを触ってるんですが、前職でエクセルで前処理していたのを思い出すと泣きそうになるくらい便利です　笑

はじめてのサーバーレス関数 by @engineer_oscaさん

サーバーレスとは？

作成したアプリをデプロイすると、サーバーの存在を意識せずにいい感じに動かしてくれる

  • サーバーを管理する労力を削減できる
  • 負荷に応じていい感じにスケーリングしてくれる
  • アクセス量だけのミリ秒レベルの課金
サーバーレス"関数”とは？

サーバーレスの仕組みの上で動かす、入力と出力が明確な小さな機能のこと。APIやトリガーなどに利用

サービス例
  • Azure -> Azure functions
  • AWS -> Lambda
  • GCP -> Cloud functions
特徴

　ものにより使用言語、課金単位、時間制限が異なる

　時間制限があることから、バッチ処理は想定していない

どんなときに使う？
  • HTTPリクエスト
  • タイマー起動
  • DBの更新トリガー
  • ファイルストレージの更新トリガー
  • GitHub webhook

OSCAさんの個人プロジェクト：WEBクローラ関数の実装

->指定したURLのサマリを取得する関数をデプロイ

　->個人ニュースサイト製作に利用

デプロイツールはApache Mavenを利用

メリット

無料枠が大きい、越えてもやすい、コード書くだけ

注意点

PCが動いた分だけ課金される。間隔を開けるとPCの起動時間が必要になり、初動に時間がかかる

まとめ

クラウド移行のファーストステップとしてどうでしょう？

API仕様管理フレームワーク「Swagger」 by @ykaganoさん

speakerdeck.com

SwaggerをREST APIのお仕事が楽になるよ、というお話でした

使い方
  • Swagger editorを利用
  • yaml形式でAPIの仕様を書く
swagger yamlにかけること
  1. メタデータとサーバー情報の記述
  2. エンドポイントの記述
  3. モデル定義の記述

.

  • APIのモックをオンラインで作るのはセキュリティ的に不安

　->オフライン版があるよ

  • レスポンスを変えるには？

　->yamlを編集 or serviceフォルダのjsを編集

さらに

REST APIのソースコードにアノテーションを記述して ソース=ドキュメントを作ったりできるが、yamlでそこまでやると運用コストがでかいので状況とご相談

WEBエンジニアのための転職術 〜転職と採用の経験から〜 by @yuhei_kondoさん

３０歳まで未経験からIT業界のキャリアをスタートして色々経験した上で思ったこと、というお話でした。

採用者目線での話もあり、転職活動する上でこういうこと気を付けるべき注意点が参考になりました。

  • 自走して技術を身に着ける
  • 一つの現場に依存しすぎない
  • 受ける会社からみて自分に価値があることを示せるか

ゼロから始めるPWA入門 by @__syumaiさん

speakerdeck.com

PWAを使って色々やってみたよ、というお話でした。遊び心があるデモ付きで、聞いてて楽しい発表でした^^

PWAとは？
  • ウェブの良いところ

　手軽、更新が楽、データが軽い

  • アプリの利点

　オフライン可能、プッシュ通知、動作が軽い

　　->PWAならアプリの利点をウェブで実現できる

事例

Twitter lite, Instagram(画像のフィルターをすべてJSで作っている！)

PWAの構成要素
  • Service worker (一番大事)
  • Cache Storage
  • Web App Manifest
開発ツールについて
  • Chrome Dev Toolが最強

　Youtubeに詳しい動画がある！（Google社員がアップ） 　Totally Tooling Tips with Addy Osmani & Matt Gaunt - YouTube

  • Lighthouse(Chrome拡張)

表も裏もTypeScriptでWebサイトをリニューアルした話(タイトル変更) by @zuckey_17さん

しがないラジオパーソナリティずっきーさんの発表でした。

SPAで作っていたしがないラジオWebページをサーバサイド/フロントともにTypeScriptで書き直したときの経験をシェア、というお話

なぜやったの？
  • OGPタグのみSSR
  • 音声マネージド・サービスからの脱却

参考ブログ↓

note.mu

  • watch_severもwatch_clientで変更を検知

  • type.d.ts：型定義を共通化

　->実はサーバサイドとフロントで使いたい型が違い、結局分けた

全リソースぶっ壊し回避のためのterraform構成 by @3s_hvさん

speakerdeck.com

しがないラジオsp.17aに出演されていたWeb系インフラエンジニアのVTRyoさんの発表

この一年Terraformを触ってきて感じた便利な点や大変だったことのお話でした。

Terraformとは？

AWSなどのリソースをコード管理できるツール

コード化されたインフラのメリット
  • 人為的ミス回避
  • 工数削減
  • インスタンス落とし忘れ回避
大変だったところ
  • 書ける人が少ない

　インフラ寄りの人はあまりコードを書かない

  • リソースが再作成

　tfstateファイルの管理ミス。。

　　->terraform.tfstateファイルは重要！

  • 元々管理しづらいディレクトリ構成になっていた

　メンテしやすくしたよ！

まだテーブル定義書をエクセルで書いて消耗してるの？ by @nabedgeさん

タイトルは煽り系ですが、最終的にはイイ話に収束していました　笑

テーブル定義書を自動生成して運用コストを下げたよ、というお話 （Dockerはイイぞ、というお話も）

  • DBフルートを利用（JavaのORM）
変わるものと変わらないものを見極めてツールをチョイスしよう
  • RDBSはあまりかわらない
  • ”CREATE TABLE HOGEGOGE”は変わらない
  • ツールは変わる
テーブル定義書はある方がいい
  • インデックスと外部キー制約、ユニーク制約の存在までわかるやつ
  • ER図もあるほうがいいけど、なくてもいい

　->ShemaSpyっていうER図作成ツールもあるけど。。

Docker / docker-composeは覚えておくと良い
  • 異なる言語環境を必要とするツールをどう扱うか？
  • すべてdockerコマンドで動かせるようにしておけば、どこでも動く
  • ローカル環境としての利用
  • 使いたいものに合わせて公式イメージを探そう

OSCAさんコメント： 最初はエクセルでDB定義するが、 運用になったら実DBをマスターとして管理をするなどフェーズにより使い分けた方が良い

打ち上げ

近くの飯屋にて。コミュニティ運営の話とか色々

次回

5/18 (金) Yahoo! Lodgeにて

lodge.yahoo.co.jp