Submit Search
Upload
社内の画像変換サーバーをGoで置き換えた話
•
Download as PPTX, PDF
•
3 likes
•
6,407 views
A
aoi shirase
Follow
2016/03/17
Read less
Read more
Engineering
Report
Share
Report
Share
1 of 25
Download now
Recommended
SQLアンチパターン 26章「とりあえず削除フラグ」 2015/08/31 @ GMO Yours #ronsakucasual https://atnd.org/events/68902
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
BigQueryのクエリをより速い形に書き換えるTips
BigQuery Query Optimization クエリ高速化編
BigQuery Query Optimization クエリ高速化編
sutepoi
devfest tokyo 2017
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
pospome
社内勉強会向け資料
REST API のコツ
REST API のコツ
pospome
2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
DDD.rb #5 における、ドメイン駆動設計についての発表
ドメイン駆動設計 at DDD.rb #5
ドメイン駆動設計 at DDD.rb #5
啓 杉本
2021/12/21 PHPerKaigi petit - PHP8.1リリース祝賀会 でのトーク「モダンPHPテクニック 12選 ―PsalmとPHP 8.1で今はこんなこともできる!―」のスライドです。発表時点からごくわずかに加筆修正した部分があります。 https://phperkaigi.connpass.com/event/233022/
モダン PHP テクニック 12 選 ―PsalmとPHP 8.1で今はこんなこともできる!―
モダン PHP テクニック 12 選 ―PsalmとPHP 8.1で今はこんなこともできる!―
shinjiigarashi
設計ナイト2022 「トランザクションスクリプト」でのディスカッション枠スライドです。
Tackling Complexity
Tackling Complexity
Yoshitaka Kawashima
Recommended
SQLアンチパターン 26章「とりあえず削除フラグ」 2015/08/31 @ GMO Yours #ronsakucasual https://atnd.org/events/68902
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
BigQueryのクエリをより速い形に書き換えるTips
BigQuery Query Optimization クエリ高速化編
BigQuery Query Optimization クエリ高速化編
sutepoi
devfest tokyo 2017
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
pospome
社内勉強会向け資料
REST API のコツ
REST API のコツ
pospome
2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
DDD.rb #5 における、ドメイン駆動設計についての発表
ドメイン駆動設計 at DDD.rb #5
ドメイン駆動設計 at DDD.rb #5
啓 杉本
2021/12/21 PHPerKaigi petit - PHP8.1リリース祝賀会 でのトーク「モダンPHPテクニック 12選 ―PsalmとPHP 8.1で今はこんなこともできる!―」のスライドです。発表時点からごくわずかに加筆修正した部分があります。 https://phperkaigi.connpass.com/event/233022/
モダン PHP テクニック 12 選 ―PsalmとPHP 8.1で今はこんなこともできる!―
モダン PHP テクニック 12 選 ―PsalmとPHP 8.1で今はこんなこともできる!―
shinjiigarashi
設計ナイト2022 「トランザクションスクリプト」でのディスカッション枠スライドです。
Tackling Complexity
Tackling Complexity
Yoshitaka Kawashima
2015/08/31 論理削除Casual Talks #1
MySQLで論理削除と正しく付き合う方法
MySQLで論理削除と正しく付き合う方法
yoku0825
2013/04/20 デブサミ 2013 アワード & リバイバル
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
- phpcon2022 の発表 - https://fortee.jp/phpcon-2022/proposal/b85ca73f-6383-4485-b2ae-4ec3e0913e72
導入から 10 年、PHP の trait は滅びるべきなのか その適切な使いどころと弱点、将来について
導入から 10 年、PHP の trait は滅びるべきなのか その適切な使いどころと弱点、将来について
shinjiigarashi
第20回中国地方DB勉強会の発表資料です。
Ormとの付き合い方
Ormとの付き合い方
豊明 尾古
2017年3月11日 JAWS DAYS 2017 のワークショップにてハンズオンを実施した資料です。
AWSで始めるサーバレスな RESTful API システム
AWSで始めるサーバレスな RESTful API システム
Masayuki Kato
DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
Twitterのsnowflakeについて
Twitterのsnowflakeについて
moai kids
2016/05/25 de:code2016での、渡部の講演資料になります
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
Recruit Technologies
2023/11/11に開催されたJJUG CCC 2023 Fallでの講演「アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ」の資料です
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
Yusuke Suzuki
題の問題に対して、InnoDBのバッドノウハウ紹介
なかったらINSERTしたいし、あるならロック取りたいやん?
なかったらINSERTしたいし、あるならロック取りたいやん?
ichirin2501
私にとっては致命的な仕様上の問題があったためSlideShareをやめてSpeakerDeckに移行することを決めました。 今後のプレゼン資料ははこちらを参照ください。 https://speakerdeck.com/mamohacy
SlideShareをやめて SpeakerDeckに移行します
SlideShareをやめて SpeakerDeckに移行します
Mamoru Ohashi
より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料:http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ CQRSはDDDと切り分けて単独でも適用することができるので、DDDについてご存知ない方もご覧いただけます。日本語の文献は意外と少ないので、この辺りの分野に興味がある人の参考になれば幸いです。
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
RDFチェックツール「rdflint」の使い方 ・RDFとトリプル ・rdflintで出来ること
RDFチェックツール「rdflint」のご紹介
RDFチェックツール「rdflint」のご紹介
Takeshi Mikami
先日のLTで使用した資料です
RESTful API 入門
RESTful API 入門
Keisuke Nishitani
RailsにおけるRESTfulなURL設計勉強会 千駄ヶ谷.rb #12 #sendagayarb
RESTful Web アプリの設計レビューの話
RESTful Web アプリの設計レビューの話
Takuto Wada
アーキ部 #12 「複雑さ」について語り合う会 の参考資料です
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?
Yoshitaka Kawashima
MySQLにおける空振りDeleteによるlockの違いについて 山田 雄(株式会社リクルートライフスタイル)
やってはいけない空振りDelete
やってはいけない空振りDelete
Yu Yamada
メインフレーム上に構築された「モノリシック」な基幹システムは、まだまだ現役です。こうした基幹システムをリプレイスする際に、複数のアプリケーションを「疎結合/高凝集」に組み合わせるいわばマイクロサービス的な設計が目指されることはよくあります。その時に重要なのは、システムをどう分割し、統合するかという方針です。 本講演では、こうしたコンテキストでドメイン駆動設計をとりあげ、アーキテクチャに関する具体的な意思決定をする方のために、有益な考え方を示すことを目指します。 受講対象: システムのマイクロサービス化を実現したい開発者の皆様、特にどのように開発をすすめていけば良いかわからない方はぜひご参加ください。 和智 右桂 株式会社ハピネット 情報システム部 新基幹開発チーム
[AC05] マイクロサービスは分割がキモ!基幹システムのためのドメイン駆動設計
[AC05] マイクロサービスは分割がキモ!基幹システムのためのドメイン駆動設計
de:code 2017
・OSC徳島 ・PostgreSQLカンファレンス ・JJUG CCC の登壇資料です
PostgreSQLアンチパターン
PostgreSQLアンチパターン
Soudai Sone
アーキ部#13で使ったスライドです。 サンプルコードはこちらです。 https://github.com/kawasima/revisiting-domain-model
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Yoshitaka Kawashima
Shinjuku.rs #4 の発表資料です。
RustでWebSocketな自社APIを使う
RustでWebSocketな自社APIを使う
Satoshi Yoshikawa
テスト・テスト
第1回勉強会
第1回勉強会
Yukie Kanzawa
More Related Content
What's hot
2015/08/31 論理削除Casual Talks #1
MySQLで論理削除と正しく付き合う方法
MySQLで論理削除と正しく付き合う方法
yoku0825
2013/04/20 デブサミ 2013 アワード & リバイバル
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
- phpcon2022 の発表 - https://fortee.jp/phpcon-2022/proposal/b85ca73f-6383-4485-b2ae-4ec3e0913e72
導入から 10 年、PHP の trait は滅びるべきなのか その適切な使いどころと弱点、将来について
導入から 10 年、PHP の trait は滅びるべきなのか その適切な使いどころと弱点、将来について
shinjiigarashi
第20回中国地方DB勉強会の発表資料です。
Ormとの付き合い方
Ormとの付き合い方
豊明 尾古
2017年3月11日 JAWS DAYS 2017 のワークショップにてハンズオンを実施した資料です。
AWSで始めるサーバレスな RESTful API システム
AWSで始めるサーバレスな RESTful API システム
Masayuki Kato
DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
Twitterのsnowflakeについて
Twitterのsnowflakeについて
moai kids
2016/05/25 de:code2016での、渡部の講演資料になります
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
Recruit Technologies
2023/11/11に開催されたJJUG CCC 2023 Fallでの講演「アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ」の資料です
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
Yusuke Suzuki
題の問題に対して、InnoDBのバッドノウハウ紹介
なかったらINSERTしたいし、あるならロック取りたいやん?
なかったらINSERTしたいし、あるならロック取りたいやん?
ichirin2501
私にとっては致命的な仕様上の問題があったためSlideShareをやめてSpeakerDeckに移行することを決めました。 今後のプレゼン資料ははこちらを参照ください。 https://speakerdeck.com/mamohacy
SlideShareをやめて SpeakerDeckに移行します
SlideShareをやめて SpeakerDeckに移行します
Mamoru Ohashi
より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料:http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ CQRSはDDDと切り分けて単独でも適用することができるので、DDDについてご存知ない方もご覧いただけます。日本語の文献は意外と少ないので、この辺りの分野に興味がある人の参考になれば幸いです。
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
RDFチェックツール「rdflint」の使い方 ・RDFとトリプル ・rdflintで出来ること
RDFチェックツール「rdflint」のご紹介
RDFチェックツール「rdflint」のご紹介
Takeshi Mikami
先日のLTで使用した資料です
RESTful API 入門
RESTful API 入門
Keisuke Nishitani
RailsにおけるRESTfulなURL設計勉強会 千駄ヶ谷.rb #12 #sendagayarb
RESTful Web アプリの設計レビューの話
RESTful Web アプリの設計レビューの話
Takuto Wada
アーキ部 #12 「複雑さ」について語り合う会 の参考資料です
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?
Yoshitaka Kawashima
MySQLにおける空振りDeleteによるlockの違いについて 山田 雄(株式会社リクルートライフスタイル)
やってはいけない空振りDelete
やってはいけない空振りDelete
Yu Yamada
メインフレーム上に構築された「モノリシック」な基幹システムは、まだまだ現役です。こうした基幹システムをリプレイスする際に、複数のアプリケーションを「疎結合/高凝集」に組み合わせるいわばマイクロサービス的な設計が目指されることはよくあります。その時に重要なのは、システムをどう分割し、統合するかという方針です。 本講演では、こうしたコンテキストでドメイン駆動設計をとりあげ、アーキテクチャに関する具体的な意思決定をする方のために、有益な考え方を示すことを目指します。 受講対象: システムのマイクロサービス化を実現したい開発者の皆様、特にどのように開発をすすめていけば良いかわからない方はぜひご参加ください。 和智 右桂 株式会社ハピネット 情報システム部 新基幹開発チーム
[AC05] マイクロサービスは分割がキモ!基幹システムのためのドメイン駆動設計
[AC05] マイクロサービスは分割がキモ!基幹システムのためのドメイン駆動設計
de:code 2017
・OSC徳島 ・PostgreSQLカンファレンス ・JJUG CCC の登壇資料です
PostgreSQLアンチパターン
PostgreSQLアンチパターン
Soudai Sone
アーキ部#13で使ったスライドです。 サンプルコードはこちらです。 https://github.com/kawasima/revisiting-domain-model
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Yoshitaka Kawashima
What's hot
(20)
MySQLで論理削除と正しく付き合う方法
MySQLで論理削除と正しく付き合う方法
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
導入から 10 年、PHP の trait は滅びるべきなのか その適切な使いどころと弱点、将来について
導入から 10 年、PHP の trait は滅びるべきなのか その適切な使いどころと弱点、将来について
Ormとの付き合い方
Ormとの付き合い方
AWSで始めるサーバレスな RESTful API システム
AWSで始めるサーバレスな RESTful API システム
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Twitterのsnowflakeについて
Twitterのsnowflakeについて
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
なかったらINSERTしたいし、あるならロック取りたいやん?
なかったらINSERTしたいし、あるならロック取りたいやん?
SlideShareをやめて SpeakerDeckに移行します
SlideShareをやめて SpeakerDeckに移行します
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
RDFチェックツール「rdflint」のご紹介
RDFチェックツール「rdflint」のご紹介
RESTful API 入門
RESTful API 入門
RESTful Web アプリの設計レビューの話
RESTful Web アプリの設計レビューの話
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?
やってはいけない空振りDelete
やってはいけない空振りDelete
[AC05] マイクロサービスは分割がキモ!基幹システムのためのドメイン駆動設計
[AC05] マイクロサービスは分割がキモ!基幹システムのためのドメイン駆動設計
PostgreSQLアンチパターン
PostgreSQLアンチパターン
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Similar to 社内の画像変換サーバーをGoで置き換えた話
Shinjuku.rs #4 の発表資料です。
RustでWebSocketな自社APIを使う
RustでWebSocketな自社APIを使う
Satoshi Yoshikawa
テスト・テスト
第1回勉強会
第1回勉強会
Yukie Kanzawa
就職に強いプログラミングスクール「DIVE INTO CODE(ダイブ・イントゥ・コード)」 ★ホームページ : https://diveintocode.jp/ ★電話番号 : 03-5459-1808 10:00-22:00まで営業中!!(木曜休業) 人材紹介会社と連携した、本気のカリキュラムと手厚いサポートで、わずか6ヶ月でRailsエンジニアに転職することをご支援しております。 ご入校の無料説明会を開催しております。お気軽にお電話ください。
ゼロからのプログラミングRails講座 Codeanywhere版
ゼロからのプログラミングRails講座 Codeanywhere版
DIVE INTO CODE Corp.
2017.03.03 Hadoopソースコードリーディング 第22回 https://www.eventbrite.com/e/hadoop-22-tickets-31987821435
Automation of Rolling Upgrade of Hadoop Cluster without Data Lost and Job Fai...
Automation of Rolling Upgrade of Hadoop Cluster without Data Lost and Job Fai...
Yahoo!デベロッパーネットワーク
Go 1.7 Release Party in Tokyo http://gocon.connpass.com/event/37332/
Goji とレイヤ化アーキテクチャ
Goji とレイヤ化アーキテクチャ
Shiroyagi Corporation
PHP Conference 2017 にて発表された資料です。 http://phpcon.php.gr.jp/2017/
PHP Version Up と AWS への移行
PHP Version Up と AWS への移行
gree_tech
SpringFest2017の以下のセッションの資料です。 Yahoo! JAPANのコンテンツプラットフォームを支えるSpring Cloud Streamによるマイクロサービスアーキテクチャ http://springfest2017.springframework.jp/
Yahoo! JAPANのコンテンツプラットフォームを支えるSpring Cloud Streamによるマイクロサービスアーキテクチャ #jsug #sf_52
Yahoo! JAPANのコンテンツプラットフォームを支えるSpring Cloud Streamによるマイクロサービスアーキテクチャ #jsug #sf_52
Yahoo!デベロッパーネットワーク
Creators MeetUp #36発表資料
Webブラウザで使えるいろんな処理系
Webブラウザで使えるいろんな処理系
祐司 伊藤
HHVM/Hack勉強会 vol.1 20分枠
HHVM/Hackを本番投入した話
HHVM/Hackを本番投入した話
Kenjiro Kubota
PHPカンファレンス福岡2015 懇親会LT
Hashicorpツールズ
Hashicorpツールズ
Uchio Kondo
2014/2/8に行ったゲームサーバ勉強会でのスライドです。 サーバー構成図で登場するApplicationサーバーとDBについての基本的な事項と気をつける事について紹介しました。
サーバーのおしごと
サーバーのおしごと
Yugo Shimizu
gotanda.js #2 のLT資料です。
request-specを利用していい感じにモックデータを作ってフロントエンド開発を楽にしたい!
request-specを利用していい感じにモックデータを作ってフロントエンド開発を楽にしたい!
Masato Noguchi
Developers Summit 2013 15-C-2
グリーにおけるスマホアプリ開発~HTML5編
グリーにおけるスマホアプリ開発~HTML5編
Mitsuhiro Tanda
BEAR.Sunday@phpcon2012
BEAR.Sunday@phpcon2012
Akihito Koriyama
ADC MEETUP Round08 「最低限のコードでWebサイトを作成しよう」
最低限のコードでWebサイトを作成しよう(ADC MEETUP 08)
最低限のコードでWebサイトを作成しよう(ADC MEETUP 08)
壽子 大倉
Dangerというツールを使って Pull Request のレビューでの指摘を減らしましょう。
Dangerでpull requestレビューの指摘事項を減らす
Dangerでpull requestレビューの指摘事項を減らす
Shunsuke Maeda
Aiming のクラウド採用基準について東京ゲームショー2014 FUSION CLOUD 様のスポンサーセッションにて
Aiming のクラウド採用基準
Aiming のクラウド採用基準
Takahiro Hozumi
3,000名が受講したRailsの登竜門講座。経験ゼロでもインターネット上に自作のWebアプリケーションを公開することができます。 本セミナーの講義動画と手順は、どなたでもご覧いただけます。 【講義動画】 https://youtu.be/dkWipixPCJs ※ DIVE INTO CODE公式チャンネルにもぜひご登録をお願いします! 【手順】 https://diver.diveintocode.jp/seminar_documents プロのエンジニアになるために挑戦する人が、チャンスをつかめる場をつくる。 DIVE INTO CODEでは、コースの卒業後に卒業発表会を開催しています。 エンジニアへの就職やキャリア相談、 サービス内容に関するご質問がありましたら、ぜひ一度カウンセリングにお越しください。 https://diveintocode.jp/briefings DIVE INTO CODE 東京校 〒150-0044 東京都渋谷区円山町28番4号大場ビルA館 cs@diveintocode.jp
【入門】3時間でアプリ公開!ゼロからのプログラミングRails講座
【入門】3時間でアプリ公開!ゼロからのプログラミングRails講座
DIVE INTO CODE Corp.
CodeCamp LT大会のLTスライドです。 PHPフレームワークのPhalconを使ってREST APIを作った話をしました。主にPhalconの紹介をしています。
爆速フレームワークでREST APIを作った話
爆速フレームワークでREST APIを作った話
Shohei Tai
2008/11/27 Internet Week 2008 「実践!IPv6 Webサービス構築」で発表した資料。
PHPプログラミングのIPv6対応の実際
PHPプログラミングのIPv6対応の実際
Tetsuji Koyama
Similar to 社内の画像変換サーバーをGoで置き換えた話
(20)
RustでWebSocketな自社APIを使う
RustでWebSocketな自社APIを使う
第1回勉強会
第1回勉強会
ゼロからのプログラミングRails講座 Codeanywhere版
ゼロからのプログラミングRails講座 Codeanywhere版
Automation of Rolling Upgrade of Hadoop Cluster without Data Lost and Job Fai...
Automation of Rolling Upgrade of Hadoop Cluster without Data Lost and Job Fai...
Goji とレイヤ化アーキテクチャ
Goji とレイヤ化アーキテクチャ
PHP Version Up と AWS への移行
PHP Version Up と AWS への移行
Yahoo! JAPANのコンテンツプラットフォームを支えるSpring Cloud Streamによるマイクロサービスアーキテクチャ #jsug #sf_52
Yahoo! JAPANのコンテンツプラットフォームを支えるSpring Cloud Streamによるマイクロサービスアーキテクチャ #jsug #sf_52
Webブラウザで使えるいろんな処理系
Webブラウザで使えるいろんな処理系
HHVM/Hackを本番投入した話
HHVM/Hackを本番投入した話
Hashicorpツールズ
Hashicorpツールズ
サーバーのおしごと
サーバーのおしごと
request-specを利用していい感じにモックデータを作ってフロントエンド開発を楽にしたい!
request-specを利用していい感じにモックデータを作ってフロントエンド開発を楽にしたい!
グリーにおけるスマホアプリ開発~HTML5編
グリーにおけるスマホアプリ開発~HTML5編
BEAR.Sunday@phpcon2012
BEAR.Sunday@phpcon2012
最低限のコードでWebサイトを作成しよう(ADC MEETUP 08)
最低限のコードでWebサイトを作成しよう(ADC MEETUP 08)
Dangerでpull requestレビューの指摘事項を減らす
Dangerでpull requestレビューの指摘事項を減らす
Aiming のクラウド採用基準
Aiming のクラウド採用基準
【入門】3時間でアプリ公開!ゼロからのプログラミングRails講座
【入門】3時間でアプリ公開!ゼロからのプログラミングRails講座
爆速フレームワークでREST APIを作った話
爆速フレームワークでREST APIを作った話
PHPプログラミングのIPv6対応の実際
PHPプログラミングのIPv6対応の実際
社内の画像変換サーバーをGoで置き換えた話
1.
社内の画像変換サーバーを Goで置き換えた話 @ieee0824
2.
プロフィール ID/ ieee0824 かく言語 趣味 /
C, C++, Go, x86 asm 仕事 / JavaScript, PHP, Ruby エディタ/ Viぽい動きする何か 株式会社リブセンス/転職会議エンジニア
3.
やったこと 社内に存在していた画像変換サーバーを Go言語で置き換えました
4.
置き換えの動機 昔からある画像サーバを見てテンション上が らない PHP + imagemagickである 全社的に使ってるものから画像サーバーを切 り離したい
5.
Go言語は良い落とし所だっ た CPU処理がボトルネックになりそうなところ リクエストが沢山飛んで来る レスポンス速度を要求される CPUの処理が多い 他にもいろいろといいところが
6.
いろいろな利点 コンパイル言語なので速い それなりの量のリクエストにも耐えやすい ネットワーク関連のpackageが多い サーバーアプリを書きやすい 画像処理がGo言語のみでも十分行える 画像formatを気にしなくてもだいたい扱える
7.
いろいろな利点 曖昧な文法が少ない C/C++のような闇のコードが生まれにくい 型が違うと必ずcastが必要 クロスコンパイルが優秀 mac上で開発してLinuxのバイナリを出したりとかが簡単 割り込みっぽい処理も書きやすい
8.
いろいろな利点 Gopherくん可愛い mattnさんの熱意の伝わる資料 “http://qiita.com/mattn/items/b7889e3c036b 408ae8bd”
9.
ところで転職会議の画像事情は 1ページ開いた時の画像は地味に多い 1ページ開くごとに20~50枚くらい画像を処 理する それを毎回リサイズしている 次の日にキャッシュが使えない可能性もあ る
10.
主な仕様 ロードバランサーにAWSのELBを使う cacheとしてnginxを使う アプリケーションをGoでかく Circle CI +
CodeDeployでdeployをする 負荷がかかったらauto scaleされる ストレージの代わりにS3を使う
11.
だいたいこんな感じ
12.
だいたいこんな感じ
13.
Goで主にやった処理
14.
Goで画像を開く jpeg, PNG, gif,
bmp, webpが扱える image.Decodeを使えばだいたい開ける ヘッダーとか壊れてると開けないけど imagemagickはなんとかしてくれてた なんか問題ありそうだったら今後どうにかする 確率低いから良いのではないかという割り切り
15.
Goで画像を処理する go-libjpegとか使えば速い 今回はデコードがボトルネックじゃないので標準のimage/jpegを使う resizeはntftのLanczos3を使った vipsthumbnail使えば速くなっただろうが特に問題にもならなかったの で使わなかった 何も気にせず動くほうが嬉しい アス比を維持してリサイズする処理とかは自分で書いた
16.
nfnt/resizeは優秀である “github.com/nfnt/resize”を使った 有名どころのアルゴリズムが困らない NearestNeighbor Bilinear Bicubic Lanczos2、Lanczos3
17.
S3にデータを投げる 社内データサーバーとS3のデータの同期 “github.com/aws/aws-sdk-go”使ってNASからS3にデータを投げるの を書く 管理が自分の部署じゃないサーバーでも外でコンパイルしたバイナ リ1個設置するだけなので楽である 転送速度が上がり過ぎないように制御しながらデータを投げた 送った量を監視しながらゴルーチンとタイムアウトを使って制御し た
18.
設定ファイルを定義する 設定ファイルを素jsonだけで書くのは辛い apache.confみたいにimportとかやりたい 作った “https://github.com/ieee0824/configure”
19.
github.com/ieee0824/configu re { "hoge":"hage", "include":[ "confiugre0.json", "confiugre1.json", "./foo/confiugre2.json", "/bar/confiugre3.json", ] } keyにinclude指定すると設置した場所のjsonも含めれる
20.
困ったこと1 ただ後々にViperといういいものがあること に気がつく “https://github.com/spf13/viper” jsonだけでなくyamlも扱える
21.
logの扱い 標準のlog packageが貧弱 logrusを使うがそれでも貧弱 warningをerrorで上書きしたい時とか ちょっとだけ自分で拡張する logrotateのことを考えてないとfileをどうやってcloseするか悩むこと になる copytruncateで対処
22.
その他やったこと 作ったサーバーがちゃんと動くか適当なURL にアクセスして叩くクライアント 負荷試験をやりたかったのでベンチマーク用 controllerとnode 通信周りをチャネルにほとんど任せたので 細かい制御とかに関して手を抜けた
23.
Goでやらなかったこと アプリケーションのデーモン化 upstartに任せました キャッシュとかの処理 nginx素晴らしいから書かなくていいやん
24.
感想 Go言語的なところで困ることは意外に少ない やりたいことのpackageがだいたいある 自分が仕込んだバグとか意外では今のところ問題が 起こってない Go言語は自分でなんでも書くイメージがあるが意 外と部品が揃ってて作る部分が少ない
25.
おわり
Download now