【Go言語(golang)入門】golangに入門してみた話
Goがいけてるらしい
結構前からずっと「golangがいけてる👍」ってよく聞きます。(よね?)
でも、これまでgolangって触ったことがありませんでした。
だから、golangで簡単なAPIサーバを作って、どんな感じの言語なのか感じておこうと思います!
Go言語(golang)
言語仕様
golangの特徴として以下のようなことが、よく挙げられていました。
- 速い
- コンパイル型言語
- 平行処理のサポートが良い
- シンプルな記述
- 高い安全性
golang における Web Application Framework(WAF)
golangにおけるWAFは基本的にマイクロフレームワークのようです。
もちろん、フルスタックフレームワークも存在します。
代表的なマイクロフレームワーク
代表的なフルスタックフレームワーク
いろいろありますが、
こちらのサイトを参考にすると、
golang標準ライブラリの net/http
互換であるものがいいらしい!
ということで、
上記参考サイトでおすすめされているものの中で最もGitHubのスター数が多かった
mux を使ってみることにしました。
今回作るもの
mux を使って、TODOを管理するAPIを作っていきます。
完成版は下記リポジトリにあります。
golang + mux でTODO管理API作成
動作環境
いざ、実装
1. main.go
を作成
まずはじめに、muxではルーティングおよびハンドラ(処理)を
どのように設定するのか確認するために
1ファイルで簡単なAPIを実装してみます。
// Filename: main.go package main import ( "fmt" "log" "net/http" "github.com/gorilla/mux" ) func main() { const Host = "localhost:5000" // Go的慣例:定数には型を指定しない router := mux.NewRouter() router.HandleFunc("/users/{id:[0-9]+}", usersHandler).Methods("GET") fmt.Println("Server Start >> " + Host) log.Fatal(http.ListenAndServe(Host, router)) } func usersHandler(w http.ResponseWriter, r *http.Request) { vars := mux.Vars(r) w.WriteHeader(http.StatusOK) fmt.Fprintf(w, "User No.%v", vars["id"]) }
上記コードについて説明します。
main関数
- ルーティング設定
/users/{id:[0-9]+}
はパスパラメータで指定したユーザの情報を取得するためのパスを設定しています。
/users/{id:[0-9]+}
のパスに来たリクエストを処理するのは usersHandler
です。
(usersHandler関数については後述)
- サーバ設定
今回は localhost:5000
でリクエストを受け付けるようにします。
usersHandler関数
本関数は先程述べたとおり
/users/{id:[0-9]+}
のパスに来たリクエストに対する処理内容を記述します。
ビジネスロジックとかって言い方しますよね。
2. 起動
$ go run main.go
上記コマンドでサーバを起動します。
実際に実行してみると
$ go run main.go Server Start >> localhost:5000
このように表示されるでしょう。
では、実際にリクエストを投げてみます。
3. テスト
Postmanでもなんでもいいので
GETメソッドで http://localhost:5000/users/1
にリクエストを投げます。
すると
User No.1
というレスポンスが返って来たと思います!
http://localhost:5000/users/2
にリクエストを投げれば
User No.2
になりますよね!
4. より実践的なプログラムに変更
僕的、実践的プログラムとは、
- ハンドラごとにファイルを分離
- DBからデータを取得
上記のような処理を内包するプログラムです。
では、まずファイルの分離からやっていきましょう。
ディレクトリ構成
├── handler │ └── users_handler.go └── main.go
ルーティングとハンドラ(ビジネスロジック)を分けてみます。
コードの中身
// Filename: main.go package main import ( "fmt" "log" "net/http" "github.com/gorilla/mux" "api-server-tutorial/handler" // ★ここ!handlerディレクトリ配下をインポート ) func main() { const Host = "localhost:5000" router := mux.NewRouter() router.HandleFunc("/users/{id:[0-9]+}", handler.UsersHandler).Methods("GET") fmt.Println("Server Start >> " + Host) log.Fatal(http.ListenAndServe(Host, router)) }
// Filename: handler/users_handler.go package handler import ( "fmt" "github.com/gorilla/mux" "net/http" ) func UsersHandler(w http.ResponseWriter, r *http.Request) { vars := mux.Vars(r) w.WriteHeader(http.StatusOK) fmt.Fprintf(w, "User No.%v", vars["id"]) }
main.go
にて、
api-server-tutorial/handler
配下のハンドラをインポートします。
これでhandler
ディレクトリ配下に配置したハンドラを利用できるようになります。
各自レスポンスが正しく返ってくるか試してみてください。
5. DBからデータを取得
Webサービスを作成するにあたってDBは必須ですよね!
今回は、GoでDB操作するさいによく使われているらしい
Gormを使ってみます。
GormとMySQL用パッケージのインストール
$ go get -u github.com/jinzhu/gorm $ go get -u github.com/go-sql-driver/mysql
-u
オプションは最新バージョンをインストールする
っていう意味です。
今回はMySQLを使用します。
テーブル作成
テスト用にUsersテーブルを作成します。
CREATE TABLE users ( id INT AUTO_INCREMENT NOT NULL PRIMARY KEY, name VARCHAR(255) NOT NULL, age INT NOT NULL, created_at DATETIME, updated_at DATETIME );
mysql> describe users; +------------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +------------+--------------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | name | varchar(255) | NO | | NULL | | | age | int(11) | NO | | NULL | | | created_at | datetime | YES | | NULL | | | updated_at | datetime | YES | | NULL | | +------------+--------------+------+-----+---------+----------------+
DB操作機能を追加
package main import ( "api-server-tutorial/handler" "fmt" "github.com/gorilla/mux" _ "github.com/jinzhu/gorm/dialects/mysql" "log" "net/http" ) func main() { const Host = "localhost:5000" router := mux.NewRouter() router.HandleFunc("/users/{id:[0-9]+}", handler.UsersShowHandler).Methods("GET") // 【変更箇所】 router.HandleFunc("/users", handler.UsersCreateHandler).Methods("POST") // 【変更箇所】 fmt.Println("Server Start >> " + Host) log.Fatal(http.ListenAndServe(Host, router)) }
今回はDBからIDを指定してユーザを取得するAPIと
名前と年齢を指定して新しいユーザを作成するAPIを作成します。
したがって、 main.go
は ルーティング部分(【変更箇所】)が変わっています。
また、各エンドポイントごとにハンドラを設定しています。
// Filename: handler/users_handler.go package handler import ( "encoding/json" "fmt" "github.com/gorilla/mux" "github.com/jinzhu/gorm" _ "github.com/jinzhu/gorm/dialects/mysql" "net/http" "time" ) // Model共通分を表す構造体 type Model struct { ID uint `gorm:"primary_key" json:"id"` CreatedAt time.Time UpdatedAt time.Time } // Userを表す構造体 type User struct { Model Name string Age int } // User作成用のパラメータを表す構造体 type UserParams struct { Name string Age int } func UsersShowHandler(w http.ResponseWriter, r *http.Request) { // DBに接続 db := gormConnect() defer db.Close() // dbを使い終わったらクローズ vars := mux.Vars(r) // 指定IDのユーザを取得 var user User db.First(&user, vars["id"]) w.WriteHeader(http.StatusOK) fmt.Fprintf(w, "Show this user -> %v", user.Name) } func UsersCreateHandler(w http.ResponseWriter, r *http.Request) { // DBに接続 db := gormConnect() defer db.Close() // dbを使い終わったらクローズ // リクエストBodyをJSONにパース decoder := json.NewDecoder(r.Body) var userParams UserParams error := decoder.Decode(&userParams) // userParamsとbody内の対応するキーの値を入れてくれる if error != nil { w.Write([]byte("json decode error" + error.Error() + "\n")) } defer r.Body.Close() // bodyを使い終わったらクローズ //INSERT実行部分 var user User user.Name = userParams.Name user.Age = userParams.Age db.Create(&user) w.WriteHeader(http.StatusOK) fmt.Fprintf(w, "Create this user -> %v", user.Name) } func gormConnect() *gorm.DB { DBMS := "mysql" USER := "root" PASS := "mysql" PROTOCOL := "tcp(127.0.0.1:3306)" DBNAME := "go_api_db" db,err := gorm.Open(DBMS, USER+":"+PASS+"@"+PROTOCOL+"/"+DBNAME) if err != nil { panic(err.Error()) } return db }
(<>
部分は各自変更してください)
handler/users_handler.go
の方は
UsersShowHandler()
:指定IDのユーザを取得UsersCreateHandler()
:名前と年齢を指定してユーザを作成
上記2つのハンドラを作成ました。
URLの中からパラメータ (リクエストクエリ)を取得する方法と
リクエストBodyからパラメータを取得する 方法が異なるので注意が必要です。
defer
というのを使っていますが、
これは 特定の処理を関数の一番最後に実行する という機能を持っています。
したがって、今回の場合だと db
を使い終わったらコネクションを破棄することができます。
本来であればDB設定は別ファイルに切り出すべきでしょうが、今回は簡略化のためにusers_handler.go
の中に記述します。
6. テスト
新規ユーザの作成
ユーザがいなければ取得もできないので、まずはユーザを作成してみましょう。
http://localhost:5000/users
に POST
リクエストを投げてみてください。
なお、 Bodyは以下のようにします。
{ "name": "hogehoge", "age": 20 }
リクエストを投げると…
Create this user -> hogehoge
このようなレスポンスがきましたね!
では、DBを見てみましょう。
SELECT * FROM users WHERE id = 1;
結果は
+----+----------+-----+---------------------+---------------------+ | id | name | age | created_at | updated_at | +----+----------+-----+---------------------+---------------------+ | 1 | hogehoge | 20 | 2019-02-07 16:02:17 | 2019-02-07 16:02:17 | +----+----------+-----+---------------------+---------------------+
作成できていますね!
指定ユーザの取得
先程作成したユーザを取得してみましょう。
ID は 1 でしたね。
したがって、以下のエンドポイントに対して GET
リクエストを送信します。
http://localhost:5000/users/1
結果は
Show this user -> hogehoge
はい、指定ユーザの名前を取得できました!
唐突のまとめ
普段僕は Spring Boot や Rails, FuelPHP など、いわゆるフルスタックフレームワークによる開発をメインで行っています。
なので、今回初めてマイクロフレームワークを使うと、不便だと感じることが多々ありました。
でも、フルスタックフレームワークだと、細かいところに手が届かないときがあるので、そういう点ではマイクロフレームワークの方がいいなと思います。小回りが効きますね!
(コード書くのが大好きな僕からすると、いろいろ処理書けるので、ただただおもしろい!)
マイクロサービス主流のこのご時世、マイクロフレームワークという選択肢を持っておくことは必須ですよね。
是非ともマスターしたい技術です!
P.S.
ところどころ手抜きがある & 僕自身golang初心者なので、「golang + mux ってこんな感じなんだ」 程度に見てくださいね笑
【ブロックチェーン討論会】京都で行われたブロックチェーン勉強会に行ってきました
TL;DR
- ブロックチェーン
- 技術的にすごい革新を起こしたわけじゃない
- 「中央集権ではない」が「完全な非中央集権ではない」
- 現在:今まで国や大企業を信頼してきて成り立っている
- ブロックチェーンが作る未来:プロトコルを信頼して成り立つ
注意
決してブロックチェーンを否定する記事ではありません!
今日勉強会に来てた人たちで議論したことをそのまま載せています。
ただし、ブロックチェーン初心者の僕が発表とその後の議論を聞いて、
自分の言葉で まとめたものです。
したがって、発表者の方の意見から少し違う方向にいってしまっているところがあるかもしれません。
その点はご了承ください。
そして、間違っていることや意見があれば、ぜひコメントで教えてください!
勉強会情報
- イベント名:Blockchain Kyoto #09
- 主題:ブロックチェーンに関する発表
- イベントリンク:blockchain-kyoto.connpass.com
キーノート ざっくりまとめ
1. IOSTという企業の紹介とどういうことをしているのか
発表者:M.Oさん(IOSTの社員の方、本名フルネームだったためイニシャルだけの表記です)
概要
ブロックチェーンプラットフォームを作っている会社
- 本社:シンガポール iost.io
- go-iost
- ブロックチェーンプラットフォーム github.com
- テストネット公開中
- 今年 12月ごろに バージョン2.0 をリリース予定
- 来年2月にメインネットを公開予定
ブロックチェーン関連のサービスを作りたい企業さんに代わって開発を請け負う
IOSTが採用しているコンセンサス・メカニズム
- PoB(Proof of Believability)
- 10分に1回行われる投票 および ネットワークへの貢献により 貢献度(Servi) が貯まる
- Serviをたくさん貯めることでブロックプロデューサーになれる
- ブロックプロデューサー:ブロックを作れる人
- ブロック作成時にServiを消費するので、特定の人がめちゃくちゃServi持ってる状態が起こりにくい = ブロックプロデューサーがどんどん交代する(はず)
- 1度に選ばれるプロデューサーは17ノード
- 17ノードという数字に意味はありそうだが、ちゃんとした理由は明かされていない
- ちょっと前まで21ノードだったらしいが、いろいろ検証した結果これに落ち着いたらしい
- 分断体制的に17ノード? → 素数だとネットワーク分断されても1ノードだけになる可能性が低い?
Slackコミュニティ あるよ
ブロックチェーンの活用事例
よく言われるとこで言うと
中でもIOSTが注力する分野
- ゲーム
- サプライチェーン
- 教育
感想
PoWでは、ブロック作成者が特定の人に固まりやすいという問題があり、
近年、EOSといった他のコンセンサス・メカニズムが考えられているそうです。
今回のPoBは、そのEOSに似ているそうです。
EOSには少し問題があるようで、
やり方次第ではブロック作成者が偏ってしまうらしい。
したがって、PoBでもブロック作成者が
特定の人に寄っていってしまうのではないか?と議論になっていました。
結論は出ず。でしたが、
もう少し(12月?)でgo-iostのドキュメントを更新されるそうで、
その中にPoBに関する記述もあるそうなので、要チェックですね!
2. 私が思うところのブロックチェーンとは
発表者:運営の方(名前の表記を見つけられず…)
When do you need blockchain? の内容を見てみる
じゃあ何がすごいの?
↓ 合意形成アルゴリズムがイケてる ↓
いろいろな合意形成アルゴリズム
- リーダ選挙問題
- 2人の将軍問題
- ビザンチン将軍問題
- 2フェーズコミット
- Paxos/Raft
- PBFT
などなど
上述の合意形成アルゴリズムにより
我々が信頼する対象が変化する ↓
信用主体
とはゆっても、「完全に管理主体がない」というのは無理だろう。
だから、せめてプラットフォームのコードを公開するといった透明性を高める活動が必要。
ブロックチェーンのメリットとそこから導き出せるブロックチェーンの未来
メリット
未来
参考サイト
感想
僕自身、ブロックチェーン初心者ということもあり、なかなか難しい話でした。
でも、話を聞いて、ブロックチェーンが従来技術と比較して何が違うのか、
どういったメリットがあるのか、少し分かった気がします。
もっとブロックチェーンに関する知見を深めないといけないですね。
総評
ブロックチェーンって何に使えるの? どこがすごいの?状態だったため、
まずは、もっとブロックチェーンについて知りたい!と思ったのが、
今回の勉強会に参加した理由でした。
やはり、僕自身、ブロックチェーンに関する知識が少ないために
まだブロックチェーンの本質が見えておらず、
使い道やメリットが見えにくくなっているのだなと実感しました。
今後もブロックチェーンについて、どんどんキャッチアップしていこうと思います。
【OSS入門】今日からあなたもContributor!
TL;DR
- OSS簡単に始められるよ!
- ↓OSS入門を支援してくれる人たちがいるよ! github.com oss-gate.github.io
OSS始めてみたい…
って思ったことないですか?
僕はあります!
でも、初心者エンジニアにとってOSSって
なんだか魔物(すごいエンジニア)の巣窟っぽいイメージで
「こわっぱの自分なんかが…」って思いがちですよね?ね?
大丈夫!OSS入門を支援する人たちがいる!
世界には親切な人が多いです。
だから、OSS開発をやってみたいと思っている初心者エンジニアを
応援してくれる人たちもたくさんいます。
今日紹介するのは↓これです!
とりあえず上記サイトに行ってみてください。
英語で「うっ…」てなったあなたも大丈夫。
日本語版もあります!
なんなのこのサイト
「OSS初心者のエンジニアがOSSに入門するための第一歩」を
歩ませてくれるサイトです!
サイトの手順どおりにやるだけで、
本リポジトリのコントリビューターになれます。
つまり、あなたも晴れてOSSコントリビューターの仲間入りです!
どうやるの?
ここでは手順を説明しません。
実際に前述したリンクに飛んで、
説明を読み、
OSS活動を行ってみてください。
そして、作業中には、
その作業手順を用意してくれた人が
世界のどこかにいることを感じてください!
実際に多くのコントリビューターによって作られたものの上で作業することにより
今回紹介したサイトが様々なコントリビューターたちの手によってできあがっていることを実感できるはずです!
(ですので、ここでは手順の説明をしません。)
感想
本当に簡単な作業ではありますが、
実際に Contributor.md
に自分の名前が載ると嬉しいですよね!
(僕は嬉しくて嬉しくて、即スクショしました…!)
この嬉しさが次のOSS活動に繋がると思います。
本プロジェクト発起人の Roshanjossey さんに敬意を示します。
まだ僕もがっつりOSSやっている人ではないので
この記事を読んでOSSやろう!って思った方と
一緒にステップアップしていきたいなと思います!
一人でも多くOSS開発者が増えるといいですね
(そして、良いプロダクトを作って、僕をさぼらせてください! …うそです。僕もがんばります。)
最後に
今回紹介したようなOSS入門支援プロジェクトは他にもあります。
僕が参加したことのあるところで言うと、
OSS Gate です。
issueを送るところまでやります。
ときには修正もしてプルリク投げたりもしちゃいます!
なので、今回の記事でコントリビューターの仲間入りした方で、
もう少しOSSの基礎を学びたいという方がおられれば、
OSS Gateに是非参加してみてはいかがでしょうか?
Enjoy! OSS life !
エイチームさんの勉強会に行ってきた『見せます!Webサービス開発を支えるミドルウェア/ツール』
TL;DR
- エイチームさんが実際のサービスで使った便利なミドルウェアやツールの紹介
- MySQLオンラインマイグレーションツールgh-ostで深夜メンテ回避
- RUNDECKでジョブを一元管理
- VSCodeが熱い!(Emacs民に人権なし。悲しみ。)
- MySQL界隈が熱い!
- 俺はエンジニアだ!俺は速くしたい!(パフォーマンスチューニングの話)
勉強会情報
- イベント名:ATEAM TECH 大阪「見せます!Webサービス開発を支えるミドルウェア/ツール」
- 主催:エイチームさん(大阪支社)
- 主題:Web開発において便利なミドルウェアやツールを紹介。主にサーバサイド
- イベントリンク: ateam.connpass.com
キーノート おおざっぱまとめ
1. MySQLオンラインマイグレーションツールgh-ostで深夜メンテナンスを無くした話
発表者:s2terminal さん
ある日、深夜メンテナンスが必要となった
エイチームさんのとあるサービス
- DAU:数十万
- Monthle Page View:億以上
そのサービスで使用しているDB
- MySQL
- 構成:master/slave
- donwloads:600万件以上
- データベースI/O:数十/秒(同社サービス内トップ?)
- MySQL
あるテーブルに新しくカラムを追加しないといけなくなった
- 現在DBに格納されているレコード数は膨大
- migrateに時間がめちゃくちゃかかる
↓でもでも
- サービスを止めるわけにはいかない…(じゃあ、深夜メンテ?)
- 深夜メンテは絶対にしたくない…
- なにか良い方法はないか…
GitHubがいい感じのツールをOSSで開発してるよ
その名は 『gh-ost』
- GitHub's Online Schema Migrations for MySQL
- オンラインマイグレーションツール
- 本番で動いているテーブルのコピー(ゴーストテーブル)を作成し、そっちにmigrateかけて、できあがったら本番のものと入れ替える
- 本番用のテーブル内のデータが更新されたときは、非同期でゴーストテーブルも更新する。
- レプリケーションの作成って非同期ですよね?それと同じ仕組みを使うことで、
gh-ost
も非同期で、データ同期できます!- すなわち、
binary log
を見てる
- すなわち、
- レプリケーションの作成って非同期ですよね?それと同じ仕組みを使うことで、
gh-ostのいいところ
- 実行状況をGUIで確認できる
- migrateが完了したゴーストテーブルと本番テーブルの入れ替えは手動で行える
- gh-ostにmigrate作業を深夜のうちにやっておいてもらい、担当者が出社してきたら、テーブルの入れ替えをコマンドひとつでぽちーっとやって、動作チェックできる!
- もちろん全て自動で行うことも可能!
つまり、深夜メンテしなくてよくなった!
感想
エイチームさんが運用している大きなサービスで実際に使ったツールに関する話で、動かしてみてどうだったかというところも聞けたのでかなりおもしろい話だった。
自分も来年から大規模なサービスに関わるので、こういった知識は大変ためになる。
2. サービスを支えるジョブ管理システム
発表者:kytiken さん
エイチームにおけるジョブ(バッチ処理)
- アフィリエイトサービスにおける、クライアント企業へのレポートメールなどはジョブとして、定期的に自動で行っている。
ジョブ管理システム有名所
- cron
- 管理するジョブが増えてくると分かりづらい(ただのコマンドの列挙だし)
- サーバが増えてくると、あのcronどこで管理してたっけ?ってなる
- エラー時のログが分かりづらい
解決策 『RUNDECK』
- RUNDECK
rundeckで運用してみて
- rundeck自体が落ちたら全ジョブが死ぬ(当たり前)
- 対策:クラスタモード
- 動作が重い
- t2.smallで運用していたが、ジョブが増えるにつれて重くなった
- 対策:JVMのチューニング
- h2databaseがデフォルトDB
- Java動作で負荷が高くなった(重い?)
- 対策:外部DBに変更
- ジョブの頻度が多い場合に負荷が高くなり始めた
- ログが大量になったため負荷が高くなった
- 対策:ログを定期的に削除
- APIが存在するが、全削除しかなくて困る(対策要検討)
感想
こちらの話も実際にRUNDECKで運用してみてどうだったかという話まで聞けたので、参考になった。
ジョブは一元管理するか、ドキュメント作ったりしないと、すぐに迷子になってしまうものだと思っているので、こういうツールはいいと思いました。
ただ、デメリットも多い模様で、使うときは要検討!
LT大会 おおざっぱまとめ
1. Effective Debugging React Apps in VSCode
発表者:むらじゅん(@murajun1978)さん
あまりメモ取れてません。ごめんなさい笑 (流れがスムーズすぎて、つい聞き入ってしまったんです。ええそうです。)
宣伝
Shinosaka.rb #32
やるからきてね〜
どのエディタ使ってますか?
No more Print Debug
- print debug は無駄が多い
- VSCodeのデバッグ機能をどんどん活用していこうという話
- ただし、Railsでは
ruby-debug-ide
とdebase
gemが必要- 最新版はうまく動作しないから、Beta版使わないといけない
- ただし、Railsでは
- VSCode Recipes にデバッグのサンプルいっぱい
- なにやらVSCodeのデバッグに関する設定ファイル?について話されていたが、そもそもVSCode使っていない僕にはなんのことか分からなかった…(ここが本題だったのに…)
感想
shinosaka.rb 行ってみよう!
最近、VSCodeが熱い!って話をよく聞くけど、会場の8割型がVSCodeユーザだったのは焦った。
自分もちょっと試してみようかな!
2. MySQL InnoDB Cluster
発表者:@masayuki14 さん
MySQL InnoDB Cluster がすごい
- 3つのコンポーネントを使って作る高可用性構成
- セットアップが簡単
- MySQL Shell で簡単にセットアップ
- 自動フェイルオーバー
- マスターの自動昇格
- M/Sの接続を自動で切り替える
- スケールアップが容易
感想
こんな便利な機能があるんですね!
他の参加者の方がMySQL Router
が単一障害点になるからどうなんだろう…って議論されていて、それを聞くのも、またおもしろかったです!
@masayuki14 さんの発表で↓こういうものがあります。 かなりおもしろかったです! ぜひご一読を!
3. サービスで活用したRailsパフォーマンスチューニングツールの話
発表者:@sakupa さん(エイチームの方)
パフォーマンスチューニングをやることになった経緯
- 開発優先でパフォーマンスチューニングできてなかった
- ISUCONに出て刺激を受けた
- 大会でやったことを業務に活かす!
- なぜパフォーマンスチューニング?
- 俺はエンジニアだ!俺は速くしたい!
- ↑かっこよすぎる笑
- 俺はエンジニアだ!俺は速くしたい!
パフォーマンスチューニングにおける優先度を決定
- CV(コンバージョン)に繋がるページ
- コンバージョン:Webサイト上で獲得できる最終的な成果
- できるだけ小さい改修
- あくまでリファクタリング
パフォーマンス監視サービスの導入
- New Relic
- ローカル段階から導入できる!
- Railsならgemいれるだけで動く
発行クエリ数が多いぞ!?
- New Relicにより発見
- 続けて
rack-mini-profiler
で調査するとN+1問題が発生していることも見つけた bullet
でN+1問題の場所特定- チューニング!
パフォーマンスチューニングにおいて大事なこと
- ボトルネックを細かく追うこと
感想
パフォーマンスチューニングをやるさいに、先輩からなぜやるのか聞かれたそうですが、 「俺はエンジニアだ!俺は速くしたい!」と言い切ったそうです笑
こういうエンジニアになりたいですね笑
プロファイラは、自分も使ったことがありますが(開発のバイトやってます)、導入が大変だったのを覚えています。 RailsならGem入れるだけなんですね!
全体を通じての感想
Meet Up 形式のイベントだったため、 勉強会スタート前からお酒飲んだり、ご飯を食べたり、かなりアットホームな雰囲気で始まりました。
大阪消費激しめ#AteamMeetUp pic.twitter.com/8Haszck5UT
— エンジニアさん 🌓 (@yyh_gl) 2018年11月15日
エイチームさんが実際に使っているツールを知ることができ、加えて、実運用においてどうだったかというところまで教えてもらえたので、かなり有意義な時間でした。
次は来年の1,2月ごろ開催だそうです。 また参加したい!
技術系ブログ始めました
よし、個人ブログを始めよう
近年、 Qiita や 日本語版スタックオーバーフロー など
日本人エンジニアが集まる情報共有サイトは充実してきており、
発進の場もかなり増えてきている。
そんななか、自分がなぜ個人ブログを始めたのか。
それは単純。
『個人ブログ持ってたら、なんかすごそう』だから。
ってことで、技術系ネタ中心のブログ始めます!
自己紹介
現在、京都在住の大学院生
来年から東京でITエンジニアとして働きます。
高校まではサッカーをばりばりやってて、全国大会にも出場。
つまり、かなり異色な経歴。(ですよね?)
大学入学後から本格的にプログラミングを始め、
様々な企業でのインターン、開発のバイトを通して
エンジニアとして進化!
でも、まだまだひよっ子エンジニア。
ここでアウトプットしていき、さらなる進化を目指します。