$ emacs memo.md

Emacsが主戦場。学生エンジニアの技術系ブログ

【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を作っていきます。

完成版は下記リポジトリにあります。

github.com

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/usersPOSTリクエストを投げてみてください。

なお、 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

  • ブロックチェーン
    • 技術的にすごい革新を起こしたわけじゃない
    • 「中央集権ではない」が「完全な非中央集権ではない」
  • 現在:今まで国や大企業を信頼してきて成り立っている
  • ブロックチェーンが作る未来:プロトコルを信頼して成り立つ

注意

決してブロックチェーンを否定する記事ではありません!

今日勉強会に来てた人たちで議論したことをそのまま載せています。

ただし、ブロックチェーン初心者の僕が発表とその後の議論を聞いて、

自分の言葉で まとめたものです。

したがって、発表者の方の意見から少し違う方向にいってしまっているところがあるかもしれません。

その点はご了承ください。

そして、間違っていることや意見があれば、ぜひコメントで教えてください!

勉強会情報

キーノート ざっくりまとめ

1. IOSTという企業の紹介とどういうことをしているのか

発表者:M.Oさん(IOSTの社員の方、本名フルネームだったためイニシャルだけの表記です)

概要

IOSTが採用しているコンセンサス・メカニズム

  • PoB(Proof of Believability)
    • 10分に1回行われる投票 および ネットワークへの貢献により 貢献度(Servi) が貯まる
    • Serviをたくさん貯めることでブロックプロデューサーになれる
      • ブロックプロデューサー:ブロックを作れる人
      • ブロック作成時にServiを消費するので、特定の人がめちゃくちゃServi持ってる状態が起こりにくい = ブロックプロデューサーがどんどん交代する(はず)
  • 1度に選ばれるプロデューサーは17ノード
    • 17ノードという数字に意味はありそうだが、ちゃんとした理由は明かされていない
    • ちょっと前まで21ノードだったらしいが、いろいろ検証した結果これに落ち着いたらしい
      • 分断体制的に17ノード? → 素数だとネットワーク分断されても1ノードだけになる可能性が低い?

Slackコミュニティ あるよ

ブロックチェーンの活用事例

よく言われるとこで言うと

  • 偽造/真正制
  • マイクロペイメント
  • P2P売買
  • デジタル所有権/公平な決済メカニズム

中でもIOSTが注力する分野

感想

PoWでは、ブロック作成者が特定の人に固まりやすいという問題があり、

近年、EOSといった他のコンセンサス・メカニズムが考えられているそうです。

今回のPoBは、そのEOSに似ているそうです。

EOSには少し問題があるようで、

やり方次第ではブロック作成者が偏ってしまうらしい。

したがって、PoBでもブロック作成者が

特定の人に寄っていってしまうのではないか?と議論になっていました。

結論は出ず。でしたが、

もう少し(12月?)でgo-iostのドキュメントを更新されるそうで、

その中にPoBに関する記述もあるそうなので、要チェックですね!

developers.iost.io

2. 私が思うところのブロックチェーンとは

発表者:運営の方(名前の表記を見つけられず…)

When do you need blockchain? の内容を見てみる

じゃあ何がすごいの?

↓ 合意形成アルゴリズムがイケてる ↓

いろいろな合意形成アルゴリズム

  • リーダ選挙問題
  • 2人の将軍問題
  • ビザンチン将軍問題
  • 2フェーズコミット
  • Paxos/Raft
  • PBFT

などなど

上述の合意形成アルゴリズムにより

我々が信頼する対象が変化する ↓

信用主体

とはゆっても、「完全に管理主体がない」というのは無理だろう。

だから、せめてプラットフォームのコードを公開するといった透明性を高める活動が必要。

ブロックチェーンのメリットとそこから導き出せるブロックチェーンの未来

  • メリット

    • 価値の可視化
      • どんなデータに価値があるかなどは大企業を中心に決まっている。ブロックチェーンを介すれば、お金を介さずに価値を見いだせる。
    • 独自経済圏の形成
      • 同じ価値観、利害が一致するもの同士で経済圏を作れる
    • データの公共化
      • 私企業によるデータ収集とは異なり、公にデータを蓄積・共有できる
      • データは企業のサーバに持つんじゃなくて、ブロックチェーンにのせておいて、それを企業がもっていく形式(悪用した企業・人に罰則をつけれたらなおよし)
  • 未来

    • ある特定の大企業だけが情報を持つのではなく、公共の場所にデータを置いておく
    • 欲しい企業はトークンを支払い持っていけばいい
    • どのデータに価値があるは大企業が決めるのではなく、各企業が決めれる
    • 高いお金をかけて自社サーバを用意し、データを貯める必要もない
    • この仕組みは、ブロックチェーンという 大企業を信頼するのではなく、プロトコル(合意形成アルゴリズム)を信頼する技術があるからこそ成り立つ!

参考サイト

  • 私達はいつこの技術を使うべきか?国連ブロックチェーンイベント alis.to

  • (他にもあげてくださっていましたが、メモできず… 資料をあげてくださることに期待)

感想

僕自身、ブロックチェーン初心者ということもあり、なかなか難しい話でした。

でも、話を聞いて、ブロックチェーンが従来技術と比較して何が違うのか、

どういったメリットがあるのか、少し分かった気がします。

もっとブロックチェーンに関する知見を深めないといけないですね。

総評

ブロックチェーンって何に使えるの? どこがすごいの?状態だったため、

まずは、もっとブロックチェーンについて知りたい!と思ったのが、

今回の勉強会に参加した理由でした。

やはり、僕自身、ブロックチェーンに関する知識が少ないために

まだブロックチェーンの本質が見えておらず、

使い道やメリットが見えにくくなっているのだなと実感しました。

今後もブロックチェーンについて、どんどんキャッチアップしていこうと思います。

【OSS入門】今日からあなたもContributor!

TL;DR

OSS始めてみたい…

って思ったことないですか?

僕はあります!

でも、初心者エンジニアにとってOSSって

なんだか魔物(すごいエンジニア)の巣窟っぽいイメージで

「こわっぱの自分なんかが…」って思いがちですよね?ね?

https://2.bp.blogspot.com/-avJFYWIu4_s/WI1zYXY2QNI/AAAAAAABBYU/Xe8q_a8YJawkZo0CJcgBvw-7D679lxc3gCLcB/s800/computer_programming_contest.png

大丈夫!OSS入門を支援する人たちがいる!

世界には親切な人が多いです。

だから、OSS開発をやってみたいと思っている初心者エンジニアを

応援してくれる人たちもたくさんいます。

今日紹介するのは↓これです!

github.com

とりあえず上記サイトに行ってみてください。

英語で「うっ…」てなったあなたも大丈夫。

日本語版もあります!

f:id:yyh-gl:20181122002925p:plain
この日本語翻訳も世界の誰かがやってくれているんです!

なんなのこのサイト

OSS初心者のエンジニアがOSSに入門するための第一歩」を

歩ませてくれるサイトです!

サイトの手順どおりにやるだけで、

リポジトリのコントリビューターになれます。

つまり、あなたも晴れてOSSコントリビューターの仲間入りです!

https://2.bp.blogspot.com/-xsOlcjRc2oI/Ub5Z12xERPI/AAAAAAAAU1Y/RJtCsqStNJc/s400/nyugaku_girl.png

どうやるの?

ここでは手順を説明しません。

実際に前述したリンクに飛んで、

説明を読み、

OSS活動を行ってみてください。

そして、作業中には、

その作業手順を用意してくれた人が

世界のどこかにいることを感じてください!

実際に多くのコントリビューターによって作られたものの上で作業することにより

今回紹介したサイトが様々なコントリビューターたちの手によってできあがっていることを実感できるはずです!

(ですので、ここでは手順の説明をしません。)

感想

本当に簡単な作業ではありますが、

実際に Contributor.md に自分の名前が載ると嬉しいですよね!

(僕は嬉しくて嬉しくて、即スクショしました…!)

この嬉しさが次のOSS活動に繋がると思います。

本プロジェクト発起人の Roshanjossey さんに敬意を示します。

まだ僕もがっつりOSSやっている人ではないので

この記事を読んでOSSやろう!って思った方と

一緒にステップアップしていきたいなと思います!

一人でも多くOSS開発者が増えるといいですね

(そして、良いプロダクトを作って、僕をさぼらせてください! …うそです。僕もがんばります。)

最後に

今回紹介したようなOSS入門支援プロジェクトは他にもあります。

僕が参加したことのあるところで言うと、

OSS Gate です。

f:id:yyh-gl:20181122004035p:plain:w500

OSS Gateでは、実際にOSSを触って、問題を見つけ、

issueを送るところまでやります。

ときには修正もしてプルリク投げたりもしちゃいます!

なので、今回の記事でコントリビューターの仲間入りした方で、

もう少しOSSの基礎を学びたいという方がおられれば、

OSS Gateに是非参加してみてはいかがでしょうか?

Enjoy! OSS life !

エイチームさんの勉強会に行ってきた『見せます!Webサービス開発を支えるミドルウェア/ツール』

TL;DR

  • エイチームさんが実際のサービスで使った便利なミドルウェアやツールの紹介
  • MySQLオンラインマイグレーションツールgh-ostで深夜メンテ回避
  • RUNDECKでジョブを一元管理
  • VSCodeが熱い!(Emacs民に人権なし。悲しみ。)
  • MySQL界隈が熱い!
  • 俺はエンジニアだ!俺は速くしたい!(パフォーマンスチューニングの話)

勉強会情報

キーノート おおざっぱまとめ

1. MySQLオンラインマイグレーションツールgh-ostで深夜メンテナンスを無くした話

発表者:s2terminal さん

ある日、深夜メンテナンスが必要となった

  • エイチームさんのとあるサービス

    • DAU:数十万
    • Monthle Page View:億以上
  • そのサービスで使用しているDB

    • MySQL
      • 構成:master/slave
      • donwloads:600万件以上
      • データベースI/O:数十/秒(同社サービス内トップ?)
  • あるテーブルに新しくカラムを追加しないといけなくなった

    • 現在DBに格納されているレコード数は膨大
    • migrateに時間がめちゃくちゃかかる

↓でもでも

  • サービスを止めるわけにはいかない…(じゃあ、深夜メンテ?)
  • 深夜メンテは絶対にしたくない…
  • なにか良い方法はないか…

GitHubがいい感じのツールをOSSで開発してるよ

その名は 『gh-ost

github.com

  • 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がssh接続でサーバにアクセスしジョブを実行する(エージェントレス)
    • cronと同じ形式で記述可能(cronからコピペするだけでいい)
    • webhook対応(slackへの通知も可能)
    • fluentdにログ保存可能
    • rundeckのGUIでジョブ登録可能(コマンドとかジョブ名、実行サーバ名とか入力するだけ)

rundeckで運用してみて

  • rundeck自体が落ちたら全ジョブが死ぬ(当たり前)
  • 動作が重い
    • t2.smallで運用していたが、ジョブが増えるにつれて重くなった
    • 対策:JVMのチューニング
  • h2databaseがデフォルトDB
    • Java動作で負荷が高くなった(重い?)
    • 対策:外部DBに変更
  • ジョブの頻度が多い場合に負荷が高くなり始めた
    • ログが大量になったため負荷が高くなった
    • 対策:ログを定期的に削除
      • APIが存在するが、全削除しかなくて困る(対策要検討)

感想

こちらの話も実際にRUNDECKで運用してみてどうだったかという話まで聞けたので、参考になった。

ジョブは一元管理するか、ドキュメント作ったりしないと、すぐに迷子になってしまうものだと思っているので、こういうツールはいいと思いました。

ただ、デメリットも多い模様で、使うときは要検討!

LT大会 おおざっぱまとめ

1. Effective Debugging React Apps in VSCode

発表者:むらじゅん(@murajun1978)さん

あまりメモ取れてません。ごめんなさい笑 (流れがスムーズすぎて、つい聞き入ってしまったんです。ええそうです。)

宣伝

  • Shinosaka.rb #32 やるからきてね〜

shinosakarb.doorkeeper.jp

どのエディタ使ってますか?

  • VSCodeが大半
  • わたくし、Emacs民の人権なし

No more Print Debug

  • print debug は無駄が多い
  • VSCodeデバッグ機能をどんどん活用していこうという話
    • ただし、Railsでは ruby-debug-idedebase gemが必要
      • 最新版はうまく動作しないから、Beta版使わないといけない
  • VSCode Recipes にデバッグのサンプルいっぱい
  • なにやらVSCodeデバッグに関する設定ファイル?について話されていたが、そもそもVSCode使っていない僕にはなんのことか分からなかった…(ここが本題だったのに…)

感想

shinosaka.rb 行ってみよう!

最近、VSCodeが熱い!って話をよく聞くけど、会場の8割型がVSCodeユーザだったのは焦った。

自分もちょっと試してみようかな!

2. MySQL InnoDB Cluster

発表者:@masayuki14 さん

speakerdeck.com

MySQL InnoDB Cluster がすごい

  • 3つのコンポーネントを使って作る高可用性構成
  • セットアップが簡単
    • MySQL Shell で簡単にセットアップ
  • 自動フェイルオーバー
  • マスターの自動昇格
  • M/Sの接続を自動で切り替える
  • スケールアップが容易

感想

こんな便利な機能があるんですね!

他の参加者の方がMySQL Routerが単一障害点になるからどうなんだろう…って議論されていて、それを聞くのも、またおもしろかったです!

@masayuki14 さんの発表で↓こういうものがあります。 かなりおもしろかったです! ぜひご一読を!

speakerdeck.com

3. サービスで活用したRailsパフォーマンスチューニングツールの話

発表者:@sakupa さん(エイチームの方)

パフォーマンスチューニングをやることになった経緯

  • 開発優先でパフォーマンスチューニングできてなかった
  • ISUCONに出て刺激を受けた
    • 大会でやったことを業務に活かす!
  • なぜパフォーマンスチューニング?
    • 俺はエンジニアだ!俺は速くしたい!
      • ↑かっこよすぎる笑

パフォーマンスチューニングにおける優先度を決定

  • CV(コンバージョン)に繋がるページ
    • コンバージョン:Webサイト上で獲得できる最終的な成果
  • できるだけ小さい改修
  • あくまでリファクタリング

パフォーマンス監視サービスの導入

  • New Relic
    • ローカル段階から導入できる!
    • Railsならgemいれるだけで動く

発行クエリ数が多いぞ!?

  • New Relicにより発見
  • 続けてrack-mini-profilerで調査するとN+1問題が発生していることも見つけた
  • bulletでN+1問題の場所特定
  • チューニング!

パフォーマンスチューニングにおいて大事なこと

感想

パフォーマンスチューニングをやるさいに、先輩からなぜやるのか聞かれたそうですが、 「俺はエンジニアだ!俺は速くしたい!」と言い切ったそうです笑

こういうエンジニアになりたいですね笑

プロファイラは、自分も使ったことがありますが(開発のバイトやってます)、導入が大変だったのを覚えています。 RailsならGem入れるだけなんですね!


全体を通じての感想

Meet Up 形式のイベントだったため、 勉強会スタート前からお酒飲んだり、ご飯を食べたり、かなりアットホームな雰囲気で始まりました。

エイチームさんが実際に使っているツールを知ることができ、加えて、実運用においてどうだったかというところまで教えてもらえたので、かなり有意義な時間でした。

次は来年の1,2月ごろ開催だそうです。 また参加したい!

技術系ブログ始めました

よし、個人ブログを始めよう

f:id:yyh-gl:20181116191419p:plainf:id:yyh-gl:20181116191424p:plain

近年、 Qiita日本語版スタックオーバーフロー など

日本人エンジニアが集まる情報共有サイトは充実してきており、

発進の場もかなり増えてきている。

そんななか、自分がなぜ個人ブログを始めたのか。

それは単純。

『個人ブログ持ってたら、なんかすごそう』だから。

ってことで、技術系ネタ中心のブログ始めます!

自己紹介

現在、京都在住の大学院生

来年から東京でITエンジニアとして働きます。

高校まではサッカーをばりばりやってて、全国大会にも出場。

つまり、かなり異色な経歴。(ですよね?)

大学入学後から本格的にプログラミングを始め、

様々な企業でのインターン、開発のバイトを通して

エンジニアとして進化!

でも、まだまだひよっ子エンジニア。

ここでアウトプットしていき、さらなる進化を目指します。

技術者としての自分

  • サーバーサイドが得意
  • 実務経験がある言語
  • 新技術大好きです!
  • 今は開発系のバイトでゲームのバックエンド開発してます

f:id:yyh-gl:20181116191645p:plain
ひよこドーンでさようなら