TECH PLAY

株匏䌚瀟スタメン

株匏䌚瀟スタメン の技術ブログ

å…š237ä»¶

こんにちは。゚ンゞニアの河井です。 7月11に日に開催された Google Developers ML summit Tokyo の参加報告蚘事です。 参加の背景 サヌビスの芏暡が拡倧しおきたこず、デヌタ集蚈基盀を構築したこず、 ダッシュ ボヌドを敎備したこずなどから、次は分析を自動化できるず良いのではないかず個人的に考えおいお、情報収集のために参加したした。 Jeff Deam 氏によるキヌノヌトセッション Google の AI 研究チヌム Google Brain のトップを務める Jeff Dean 氏のセッションです。 機械孊習 を必芁ずする問題に察しお専門家が少なすぎるずいう問題意識から、珟圚の solution = ML expert + data + computation ずいう関係性を、将来的には solution = data + computation にしたいずいう匷いモチベヌションをもっおいるこずが䌝わっおきたした。 そのような文脈から研究が進んでいる AutoML は、デヌタに適合する 機械孊習 モデルを自動で探玢したす。 画像・ 自然蚀語 ・テヌ ブルデヌ タなど、様々な圢匏のデヌタに察しお成果が出おきおいるようです。 画像認識においお、AutoML の自動探玢によるモデルが専門家が構築したものより高粟床を出したずいうものです。䞊のスラむドは こちらの論文 に茉っおいたす。 こちらは 機械孊習 モデルの粟床を競う コンペティション で、テヌ ブルデヌ タ課題においお AutoML チヌムが2䜍に入賞した話です。報告蚘事は こちら です。 他にも 機械孊習 党般の話や、AI開発におけるガむドなどありたしたが、総じお AutoML を匷く掚しおいる印象を受けたした。 機械孊習 の各分野で次々ず成果を出しおいる Google が、この䞖界芳をどのレベルで実珟するのかを考えるずワクワクしたすね。 Auto ML に぀いお 続いお クラりド サヌビスずしおの AutoML 関連のセッションに参加したした。 粟床の高いモデルを䜜るずいう点が匷調されがちだが、プロダクションぞの配信からその埌の運甚たでを幅広くカバヌするものだずいうこずを説明しおいたした。 孊習時に優先する芁玠の蚭定やモデルのバヌゞョン管理機胜なども含め、 機械孊習 のワヌクフロヌにおいお属人性を排するこずに繋がりそうなので、プロダクション環境で 機械孊習 システムを運甚する際には遞択肢ずしお入っおきそうだなずいう印象を受けたした。 AutoML Vision 掻甚事䟋 Twitter で話題になった ラヌメン二郎 分類噚の開発者である土井さんの発衚で、もずもず自前で実装・チュヌニングしたモデルず AutoML Vision で孊習したモデルを比范しおみたずいう話です。 土井さんが自前で孊習したモデルは、最新の手法を論文から取り入れ぀぀モデル構築やデヌタ拡匵・パラメヌタチュヌニングをしたもので、分類粟床は 99% を超えるずいうこずで、非垞に粟床が良いモデルが出来䞊がっおいたす。 察する AutoML の成果ですが、限界たで孊習させた結果、なんず 98% の粟床を達成したした。 本圓にデヌ タセット ず アノテヌション だけで、専門家がチュヌニングしたモデルに匹敵するものが出来䞊がるずは、ず感動したした。しかしながら今はただ完璧ではなく、孊習時間が長い、モデルサむズが倧きくお掚論時間が遅い、それでいお粟床はただ負けおいたす。 PoC的なものはこれでサクッず立ち䞊げお、プロダクションに乗せるずなったら専門家がチュヌニングしたものを䜿うのが良さそうです。 たずめ 機械孊習 研究の最先端を行く䌁業の䞭の人達の話を盎接聞ける機䌚はずおも貎重で、倚くの孊びがありたした。 専門家がいなくおも 機械孊習 を、ずいうメッセヌゞを色々な堎面よく芋かけるようになりたした。誰でも粟床の高いモデルを䜜れるずいうこずだけがその真意ではなく、孊習から配信・運甚たでを クラりド サヌビスの゚コシステムでたずめお取り扱えるようにする、ずいう意味合いも兌ねおいたす。 粟床面ではただただ専門家に劣るずころはあるものの、 機械孊習 技術の研究は日々めたぐるしく進歩しおいるので、今埌に期埅し぀぀キャッチアップを怠らないようにしたいですね。
こんにちは 最近、高速化にハマっおいるRails゚ンゞニアのシュヌル( @shule517 )です。速くなった時の感動が半端ないですよね はじめに 䞍具合調査っおめちゃめちゃ倧倉じゃないですか 問題の原因が分かっおいなくお、手元で䞍具合が再珟できない時は、調査がかなり難しいです。そのため、䞍具合が発生したタむミングにできるだけ倚くのデバッグ情報を残したくなりたすよね ずいうこずで、今回のテヌマは「䞍具合調査の時間を短瞮するための仕組み」に぀いおです Bugsnagで䟋倖がどこで発生したのかすぐ分かる 「 スタメンの開発環境に぀いお 」で玹介をしたしたが、Railsの゚ラヌ監芖に Bugsnag ずいうサヌビスを䜿っおいたす。Slackずの連携ができ、リアルタむムに通知が飛んでくるので、すぐに問題に気づくこずができたす 実際の画面はこちらです。 Bugsnagで分かる内容 どこで、どんな䟋倖が発生したのか 䟋倖を螏んだナヌザヌは誰なのか どんな環境なのか(OS / ブラりザの皮類) などなど、Bugsnagを導入するずたくさんの情報を集めおくれたす ずおも䟿利 でも、もう少しデバッグ情報がほしい 䞍具合を調査するずなるず、Bugsnagでこんな情報が芋れるず嬉しいですよね 䟋えば・・・ メ゜ッドに枡っおきた匕数はどんな倀 モデルのidは モデルに保存されおいる倀は 今回はこの぀の情報を通知する仕組みを䜜っおいきたす。䞍具合の再珟方法を頑匵っお探すよりも、Bugsnagを芋たら原因がすぐに分かるようにしたいですよね 調査①  Bugsnagの公匏ドキュメントを読む Bugsnagの公匏ドキュメント( bugsnag DOCS - Rails integration guide )を確認するず、新しいタブを远加しお、こちらで蚭定した情報を茉せられるようです ここに远加のデバッグ情報を茉せられたら、良さそうです。 class ApplicationController < ActionController :: Base before_bugsnag_notify :add_diagnostics_to_bugsnag # Your controller code here private def add_diagnostics_to_bugsnag (report) report.add_tab( :diagnostics , { product : current_product.name }) end end 次にデバッグ情報をどのように取埗するか怜蚎しおいきたしょう。 メ゜ッドに枡っおきた匕数はどんな倀 モデルのidはいく぀ モデルに保存されおいる倀は 「うヌん。。 どうしたら良いんだろう 呚りのサヌビスなどではどうしおるんだろう」ず思い、2぀のgem(Better Errors / New Relic)のコヌドを読んでみたした。 調査②  BetterErrors の gem を参考にする みんなお䞖話になっおいるであろう Railsのデバッグずいえばこれですよね。BetterErrorsのコン゜ヌルに倉数名を入力すれば、倀を出力できるので、参考にできそう Better Errors ※ BetterErrors より 画像を匕甚 ① BetterErrorsのコン゜ヌルは、binding.eval(str)を実行しおるだけ module BetterErrors module REPL class Basic def initialize (binding, _exception) @binding = binding end def send_input (str) [execute(str), " >> " , "" ] end private def execute (str) " => #{ @binding .eval(str).inspect }\n" rescue Exception => e " !! #{ e.inspect rescue e.class.to_s rescue " Exception "}\n" end end end end ② そのBindingは、Exceptionを拡匵し䟋倖クラスに保持しおいる module BetterErrors module ExceptionExtension prepend_features Exception def set_backtrace (*) if caller_locations.none? { |loc| loc.path == __FILE__ } @__better_errors_bindings_stack = :: Kernel .binding.callers.drop( 1 ) end super end def __better_errors_bindings_stack @__better_errors_bindings_stack || [] end end end なるほどなるほど。䟋倖元のBindingを取埗するこずができれば、匕数やModelの情報が取れそうですね 調査③  New Relic の gem を参考にする 次に目を぀けたのは、パフォヌマンスの監芖でい぀もお䞖話になっおいるNew Relicです。DBの怜玢時間などの凊理時間を现かくデヌタを取っおいるので、参考になりそう。gemのコヌドを読んでみるず、ActiveRecordでよく䜿われおいるメ゜ッド達(saveなど)に枬定甚の凊理を埋め蟌んでいたした。たた、むベントをフックしお、凊理を埋め蟌んでいるみたいです。思った以䞊に泥臭いぞ。。。 New Relic ※ New Relic より 画像を匕甚 # encoding: utf-8 # This file is distributed under New Relic's license terms. # See https://github.com/newrelic/rpm/blob/master/LICENSE for complete details. require ' new_relic/agent/prepend_supportability ' module NewRelic module Agent module Instrumentation module ActiveRecordPrepend ACTIVE_RECORD = ' ActiveRecord ' .freeze module BaseExtensions def save (*args, &blk) :: NewRelic :: Agent .with_database_metric_name( self .class.name, nil , ACTIVE_RECORD ) do super end end def save! (*args, &blk) :: NewRelic :: Agent .with_database_metric_name( self .class.name, nil , ACTIVE_RECORD ) do super end end end # saveず同じように䞋蚘のメ゜ッドの実装がされおいた略 # - touch # - update_all # - delete_all # - destroy_all # - calculate # - pluck end end end end なるほどなるほど。䟋倖のむベントが取埗できれば、なんずかなりそうですね 調査④  TracePointで䟋倖をフックする Rubyのむベントフックを探しおみるず、TracePointクラスを䜿うず䟋倖発生時のむベントがフックできるみたいです るりた - TracePointクラス TracePoint .new( :raise ) do |tp| # ブロック内は䟋倖が発生した時に動く tp.raised_exception # Exceptionが取埗できる end でも、TracePointっお遅いのでは 単玔にTracePointを実行するず、玄8倍遅くなる (Traceなし45.1ms → Traceあり370.2ms) trace = TracePoint .new {} 10 .times.map { Benchmark .realtime { 1000000 .times { 1 + 2 } } }.sum/ 10 # Traceなし => 0.04516370000201277 10 .times.map { Benchmark .realtime { trace.enable { 1000000 .times { 1 + 2 } } } }.sum/ 10 # Traceあり => 0.3702467000024626 䟋倖だけをフックすれば、圱響がない むベントフックの察象を䟋倖だけに限定すれば、通垞の凊理には圱響がありたせん (Traceなし42.9ms → Traceあり42.5ms) trace_raise = TracePoint .new( :raise ) {} 10 .times.map { Benchmark .realtime { 1000000 .times { 1 + 2 } } }.sum/ 10 # Traceなし => 0.04297380000061821 10 .times.map { Benchmark .realtime { trace_raise.enable { 1000000 .times { 1 + 2 } } } }.sum/ 10 # Traceあり => 0.04251920000097016 これなら速床も問題なさそうですね これで材料が揃いたした 調査結果のたずめ Bugsnagに新しいタブを远加しお、情報を远加できる 䟋倖発生元のBindingが取埗できれば、匕数やModelのデヌタを取埗できる TracePointで䟋倖のむベントをフックしお、䟋倖発生元のBindingが取埗できる Bugsnagにデバッグ情報を远加できたした 完成 調査結果を元に、Bugsnagの通知内容にデバッグ情報を増やしおみたした。 察応した内容 BugsnagのペヌゞにModelAttributesタブを远加 メ゜ッドに枡した匕数の倀が確認できるようになった Modelで䟋倖が発生した堎合は、idや各カラムの倀が芋えるようになった やったヌ これで、どのModelで䟋倖が起きたかは分かるけど、どのレコヌドか分からないっおいうこずが無くなりたす。匕数に枡っおきたパラメヌタも分かるので、䞍具合の調査も捗りそうです 最終的なコヌドはこちら 説明のためにコヌドを簡略化し、解説コメントを远加しおありたす。 実際には、機密情報に関わる郚分はBugsnagで通知しないなどの察応を行っおいたす。 䟋倖時に、䟋倖発生箇所のbindingを保持する # 䟋倖発生むベントをフックする TracePoint .trace( :raise ) do |trace_point| exception = trace_point.raised_exception # 䟋倖の発生元の情報を取埗するためBindingを保持する if trace_point.binding.respond_to?( :callers ) bindings = trace_point.binding.callers.drop( 1 ) else bindings = [trace_point.binding] end # exception.error_bindingsに、䟋倖発生元のbindingを保持させる exception.define_singleton_method( :error_bindings ) do bindings end end Controllerで䟋倖が発生した時に、Bugsnagを通知する class ApplicationController < ActionController :: Base rescue_from Exception , with : :notify_bugsnag # Controller内で䟋倖が発生した堎合に、Bugsnagを通知する def notify_bugsnag (exception) BugsnagReporter .notify(exception) raise exception end end 䟋倖の発生箇所の匕数や、ActiveRecordのモデル情報をBugsnagぞ通知する module BugsnagReporter class << self def notify (exception) Bugsnag .notify(exception) do |report| # Bugsnagに新しいタブを远加する report.add_tab( :model_attributes , models : model_attributes(exception)) end skip_bugsnag(exception) # 二重で通知されないように通知をスキップする end def skip_bugsnag (exception) def exception. skip_bugsnag true end end def model_attributes (exception) # 䟋倖に保持しおおいたbindingを䜿う exception.error_bindings.map do |binding| instance = binding.eval( ' self ' ) debug = {} # ActiveRecordModelの䞭で䟋倖が発生した堎合は、カラムのデヌタを出力する debug.store( "#{ instance.class.name.downcase } _attributes " , instance.attributes) if instance.respond_to?( :attributes ) # 䟋倖発生堎所のロヌカル倉数を出力 debug.store( :local_variables , local_valiables(binding)) # 䟋倖発生堎所のむンスタンス倉数を出力 debug.store( :instance_variables , instance_variables(instance)) [trace_path(binding), debug] end .compact.to_h end # 䟋倖発生堎所のロヌカル倉数を取埗 def local_valiables (binding) binding.local_variables.map { |name| [name, format(binding.local_variable_get(name))] }.to_h end # 䟋倖発生堎所のむンスタンス倉数を取埗 def instance_variables (instance) instance.instance_variables.map { |name| [name, format(instance.instance_variable_get(name))] }.to_h end # デヌタを読みやすいように加工 def format (value) return value.attributes if value.respond_to?( :attributes ) return value.to_sql if value.respond_to?( :to_sql ) value end # 䟋倖発生堎所のファむルパスを生成する def trace_path (binding) instance = binding.eval( ' self ' ) method_name = binding.eval( ' __method__ ' ) file = binding.eval( ' __FILE__ ' ) line = binding.eval( ' __LINE__ ' ) "#{ instance.class.name } # #{ method_name } - #{ file } : #{ line }" end end end おわりに Bugsnagを拡匵しお、䞍具合の調査を楜にする仕組みに぀いお解説したした。この察応は、僕が䞍具合の原因を突き止めるたでに時間がかかっおしたった倱敗をもう䞀床起こさないようにするための改善の぀です。このように、 スタメンの゚ンゞニアチヌムの行動指針 にもある「倱敗に向き合う」が実践でき、自分自身、そしおサヌビスを改善成長しおいける゚ンゞニアを募集しおいたす ぜひ、たずは ゚ンゞニア採甚サむト を芋おみおください ブログを最埌たで読んでいただいお、ありがずうございたした
スタメン ゚ンゞニアの束谷( @uuushiro )です。 2019幎6月12日(æ°Ž)〜6月14日(金)に AWS の日本最倧玚のカンファレンス AWS Summit Tokyo が 幕匵メッセ で開催されたした。そのむベント2日目に実斜される 「 AWS Startup Architecture Of The Year 2019」ずいうコンテストのファむナリストずしおスタメンが遞出されたこずもあり、せっかくならず3日間フルで参加しおきたした。1日目から3日目たでで、それぞれ印象に残った出来事をお䌝えしたいず思いたす。 玠晎らしい機䌚を頂いた1日目 幕匵メッセ で開催ずいうこずもあり、さすがの芏暡ず盛り䞊がりでした。 ただ、1日目はほずんど䌚堎で過ごす時間がなかったのでセッションは聞けなかったのですが、 AWS 䞻催のMeeting of Mindsずいう招埅制ディナヌに参加しおきたした。 そのディナヌでは、 Amazon WorkSpaces や AWS Glue のマネヌゞャヌの方々や、WEB業界で著名な䌁業のCTOや゚ンゞニアの方々ずざっくばらんにお話するこずができたした。 AWS ずいう䞖界最前線で掻躍する゚ンゞニアの方々の茝かしいキャリア話も、グロヌバルなチヌムならではのマネゞメントにおける苊劎話も党おが自分の想像を遥かに超えるスケヌルで、聞いおいるだけで興奮したした。詳现はこれ以䞊曞きたせんが、普通では手が届かないような孊びをたくさん持ち垰るこずができたした。今回の Meeting of Minds は日本では第1回目ずのこずで、次回もあったら是非参加させおいただけたら嬉しいです。 最埌に党員でパシャリ。 ぀いにコンテスト圓日の2日目 コンテスト圓日です。 Startup Architecture Of The Year のファむナリストの特兞ずしお、Startup Central内での゜リュヌション展瀺ブヌスを出展できる暩利を頂きたした。匊瀟のCTO小林ず、゚ンゞニアの接田が応揎に駆け぀けおくれお、䞀緒にブヌスの蚭営をしたした。ちなみに、このブヌスでアピヌルする アヌキテクチャ ヌのポスタヌは、匊瀟デザむナヌの束本が手䌝っおくれたした Startup Architecture Of The Year では䞋の写真のように、パネル展瀺された各 アヌキテクチャ 図に投祚甚のIoTボタンが蚭眮されおおり、プッシュが最も倚かった アヌキテクチャ がオヌディ゚ンス賞を獲埗できるずいう䌁画がありたした。 17時からの本番に先立っお、展瀺䌚堎で15分間ピッチの機䌚を頂いたので、 アヌキテクチャ のアピヌルずスタメン゚ンゞニアチヌムの玹介をさせおいただきたした。 スタメンのブヌスに立ち寄っおくださった方、オヌディ゚ンス賞のボタンを抌しおくださった方、15分ピッチを聞いおくださった方、ありがずうございたした そしお、぀いに本番です 今回スタメンが゚ントリヌした アヌキテクチャ は TUNAG のETL基盀(デヌタ凊理基盀)でした。この アヌキテクチャ ヌで工倫したポむントは倧きく぀です。 1぀目は、S3をデヌタレむクずしお掻甚したこずです。組織゚ンゲヌゞメントずいう、確立した分析指暙がただない分野においお、デヌタレむクのような アゞャむル な分析環境の構築は TUNAG のビゞネス䞊重芁な鍵ずなっおいたした。たた、S3に保存するこずで、倚様なフォヌマットの安党な保存・高い可甚性ずスケヌラビリティ・埓量課金によるコスト削枛・他 AWS サヌビスずの容易な連携などのメリットを獲埗するこずができたした。 2぀目は、マネヌゞド・サヌビスずサヌバヌレスを組み合わせおETL基盀を構築したこずです。党お埓量課金制のサヌビスなので、増加するデヌタ量に合わせお最䜎限の料金でシステムを皌働させるこずができたす。たた、マネヌゞド・サヌバヌレスのメリットを最倧限に掻甚し、構築・運甚コストを最小限に抑えながら倧芏暡なデヌタに察応可胜な基盀になりたした。 アヌキテクチャ の詳现に぀いおは、 AWS Start Up ブログ を埡芧ください 結果ずしおは、グランプリを受賞するこずができたした 今回評䟡しおいただいたETL基盀をフル掻甚し、デヌタに基づいた組織の゚ンゲヌゞメント分析をより䞀局進めおいきたいず思いたす。たた、この受賞をきっかけにスタメンの アヌキテクチャ に興味を持っおくれる゚ンゞニアの方が増えれば嬉しいなず思いたす。関係者の皆さた、応揎しおくださった皆さた、本圓にありがずうございたした。 今回のピッチで䜿甚したスラむドはこちらです。 https://speakerdeck.com/uuushiro/tunag-false-etlji-pan-aws-summit-startup-architecture-of-the-year-2019 グランプリの副賞ずしお re:inventペアチケット を頂いたのですが、re:inventはずっず行きたいず思っおいた海倖カンファレンスの1぀だったのでずおも嬉しいです。ペアチケットずいうこずで、CTO小林ず2人で行っおきたす re:inventに行かれる方、是非ラスベガスでお䌚いしたしょう やっず萜ち着いおセッションを聞けた3日目 3日目は、ようやくじっくりセッションを聞くこずができたした。 ずくに印象に残っおいるセッションは以䞋です。 * Amazon RDS におけるパフォヌマンス最適化ずパフォヌマンス管理 * Kubernetes on AWS  Amazon EKS実践入門 * サヌビスメッシュは本圓に必芁なのか、䜕を解決するのか * Amazon Pinpoint でナヌザヌを掎んで離すな TUNAGのシステムにおいお、盎近に課題になっおいるパヌ゜ナラむズされた通知基盀( AWS Pinpoint)や、コンテナ技術・マむクロサヌビスなどTUNAGの将来的な展望になっおいる技術の話が聞けお、より具䜓的にTUNAGの技術的ロヌドマップをむメヌゞできた3日目でした。 たずめ 3日間ずおも充実した時間を過ごせたした。特にスタヌトアップずいう括りで参加した分、Meeting of Minds や、 Startup Architecture Of The Year など本圓にいい経隓をするこずができたした。re:inventにも参加できるずいうこずで䞀局 AWS ぞのモチベヌションが䞊がりたした。もっずもっず䞊手く AWS を䜿い倒し、より良い アヌキテクチャ を远求しおいきたいず思いたす。 スタメンでは、゚ンゞニアの成長支揎を行う䞀環ずしお、技術曞の賌入費や、カンファレンス参加費の補助の制床がありたす。今回の AWS Summitは出匵扱いずしお参加費・亀通費・宿泊費を䌚瀟に負担しおもらいたした。 スタメンでは AWS など クラりド の進化の波に䞊手く乗りながら、䞀緒にTUNAGを良くしおいく゚ンゞニアを絶賛募集䞭です興味がある方は Wantedly よりご連絡ください。    
TL;DR (抂芁) ​ GitHub の Webhook を甚いお、PullRequest が merge されたずきに、 WordPress の テヌマを自動曎新する蚭定です。 この蚭定をするこずで、デザむナヌが WordPress テヌマを修正した際の、本番ぞの反映の手間を倧幅に削枛でき、LPO等のサむトの改善がぐんぐん進むようになりたす。 ​ 背景 ​ 広報や採甚担圓でWebサむトを曎新しやすくするために WordPress で、サむトを構築するこずがありたす。この堎合、サむトのデザむンは、 WordPress の テヌマ を自䜜するこずで行いたす。 ​ スタメンでは、テヌマは、瀟内の Webデザむナヌ が䜜り Github で管理しおいたすが、 WordPress ぞの 反映は、 WordPress のファむル管理の プラグむン である File Manager を甚いいお、曎新したファむルを手動でアップデヌトしおいたした。 この方法は、手間もかかるし、ミスも起きやすく、スマヌトではありたせん。 ​​ WordPress ず Github ずの連携は、 WP Pusher のようなサヌビスで実珟できたすが、テヌマを Github の Private repository で管理しおいるこずもあり、 それなりに費甚がかかる こずもあり、 Github Webhook を甚いお自䜜しおみるこずにしたした。 ​ Github で PulLRequest が Merge されたずきに、 WordPress に反映する手順 ​ Git pull するための蚭定 ​ たず、 WordPress が皌働しおいるサヌバヌにお、 Github リポゞトリ から git pull しお、 WordPress テヌマを取埗できるようにする必芁がありたす。 ​ Wordpress が皌働するサヌバヌにお、 OpenSSH の 鍵を぀くりたす。 ​ $ ssh-keygen -t rsa -f id_rsa_wordpress 生成された公開鍵を Github の Deploy Keys に蚭定したす。 ​ ​ ​ 次に、 httpd サヌバヌ の実行暩限で、git pull できるようにしたす。 ​ これは、 Github Webhook で WordPress が動䜜する PHP 関数を呌び出したすが、 WordPress は、 apache ナヌザヌで動䜜しおいるため、 apache ナヌザヌで git pull できないず テヌマを曎新するこずができないからです。 ​ 今回は、以䞋の内容の /home/ apache /bin/git- ssh .sh を぀くり、git pull 時に GIT_ SSH 環境倉数 にお指定するようにしおいたす。 ​ #!/bin/sh ssh -oStrictHostKeyChecking = no -oUserKnownHostsFile = /dev/null -i /home/ < user_name > /.ssh/id_rsa " $@ " ​ git- ssh .sh では、䞋蚘の傟向メッセヌゞが衚瀺されお、git pull が倱敗しないように、StrictHostKeyChecking を off にするなどのオプションを぀けおいたす。 ​ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ ​ ​ 以䞋のように、 wordpress theme が存圚する git repository で、git pull できれば準備は完了です。 ​ $ sudo -u apache GIT_SSH =/home/apache/bin/git-ssh.sh git pull origin master From github.com: < theme repository > * branch master - > FETCH_HEAD Already up-to-date. ​ WordPress に action を远加 ​ ​ WordPress の wp_ ajax _nopriv を利甚するこずで、 Github hook から任意の PHP 関数を実行するこずができたす。 ​ wp_ajax_nopriv {$ REQUEST[‘action’]} | Hook | WordPress Developer Resources ​ 今回は、䞋蚘の関数を theme ディレクト リの functions. php に远加するこずで、 https://your-wordpress-site/wp-admin/admin-ajax.php?action=wp_ajax_nopriv_update_theme にアクセスすれば、git pull されるようにしたす。 ​ ​ /** * Add deploy hook endpoint */ add_action('wp_ajax_nopriv_update_theme', 'update_theme_from_github'); function update_theme_from_github() { $secret = "XXXXXXXXXXXXXXXXXXXXXXXXXXXX"; $posted = file_get_contents('php://input'); if ( empty ($posted)) { return; } $signature = 'sha1='.hash_hmac('sha1', $posted, $secret); if ($_SERVER['HTTP_X_HUB_SIGNATURE'] !== $signature) { header('HTTP/1.1 403 Forbidden'); error_log('Signatures didn\'t match... '); return; } $json = json_decode($posted); error_log(__FUNCTION__.": \n".var_export($json, true)); if ($json- > ref === 'refs/heads/master') { $git_root = dirname(__FILE__); exec("cd ${git_root} && GIT_SSH=/home/apache/bin/git-ssh.sh git pull origin master 2 > & 1", $out); error_log(join("\n", $out)); echo join("\n", $out); } else { error_log(__FUNCTION__.": nothing for ".$json- > ref); } } ​ このずき、 GitHub の Webhook の Secret 機胜 を利甚するこずで、 GitHub の Webhook からのアクセス時のみ git pull するようにしおいたす。 デバッグ しやすいにように、 ​error_log で、webhook の payload を出力しおいたすが、䞍芁だったら消しおください。 GitHub に Webhook を远加 ​ あずは、テヌマの リポゞトリ にお、Webhook を蚭定すれば、完成です。 ​ ​ ​ たずめ ​ これたで、曎新の際は、ファむルを䞀぀䞀぀アップロヌドしおいたのが、 GitHub WebHook によっお、git pull するこずで、PullRequest を Merge するこずで、 WordPress に反映されるようになりたした。 ​ これによっお、 WordPress の曎新の手間が倧幅に枛ったため、LPO などの现かい改善がより進むようになりたした。たた、 GitHub Flow で WordPress テヌマを曎新するフロヌが確立したこずで、個々の修正に察しお、チヌムレビュヌが定着し、ノりハりの共有やミスの䜎枛を達成するこずができたした。 ​ ほんず、嬉しいこずだらけです ​ ただし、 httpd が動䜜する暩限で、git pull をするため、 レンタルサヌバ ヌなどの瀟倖含めた耇数のアカりントが共存する環境では、セキュリティず Webhook による git pull は、共存できないかもしれたせん。その堎合は、 WP Pusher などの プラグむン を入れたしょう。 ​ ​ 参考にしたサむト ​ WordPress テヌマを Git 管理しお自動デプロむする - Qiita GitHubのWebhookをPHPで受け取る緎習 - tanaka's Programming Memo GitHubのWebhookをPHPで自䜜する時に曞く怜蚌コヌド - Qiita WordPress Git deployments with WP Pusher
スタメンのデザむナヌの ( @kiyoshifuwa )です。 先日 スタメンの登壇資料テンプレヌトを Keynote で䜜成し、党瀟員に展開を行いたした。 䜜成の手順や気を぀けたこず、展開埌のフォロヌずしお行ったこずなどをご玹介したす。 なぜ䜜ったか 最近、スタメン瀟員䞻に゚ンゞニアが倧きな セミ ナヌやカンファレンスで登壇する機䌚が増えおきたした。 これたでは登壇者が毎床0から䜜成しおいたしたが、 トンマナの統䞀 䌚瀟ずしおの統䞀感を持たせたい 安定したクオリティ 各々のデザむンスキルに䟝存しないようにしたい 資料䜜成の 工数 削枛 登壇者には資料よりも話す内容に泚力しおもらいたい 䞊蚘を達成するために、スタメン共通の登壇資料テンプレヌトを䜜成するこずにしたした。 どのように䜜ったか どんなレむアりトのパタヌンが必芁なのか把握したいので、掗い出しのために ゚ンゞニアが䜜った登壇資料のラフをもらい、党おのペヌゞに最適なデザむンを適甚させたした。 その際、「これらの情報は䞊列の関係」「箇条曞きが適切か最適なのはフロヌではないか」など、詳现たで認識をすり合わせたした。 実際に䜜ったスラむドは こちら です。 そしお、必ず䜿うものやよく䜿うものをテンプレヌトに萜ずし蟌みたした。 できたものがこちら ▲テンプレヌトず䜿甚䟋䞀郚抜粋 甚意したスタむルは以䞋の通りです。 衚玙 自己玹介 アゞェンダ 箇条曞き 箇条曞きチェックリスト 番号付きリスト フロヌ 画像+テキスト 画像+テキスト説明付き 補足 アゞェンダ の数は3〜5぀たで察応しおいたす。 ゚ンゞニアは図やコヌドを芋せるこずが倚いので、瞊や暪に倧きく䜿えるスタむルを甚意したした。 スタメンのほずんどが Mac ナヌザヌなので、 Keynote ファむルのみ䜜成したした。 盎近で必芁な資料の芁件に合わせ、4:3で䜜成したした。埌々16:9も䜜成する予定です。 甚意したデヌタの詳现 䜿甚䟋ずマスタヌスラむドが入っおいる、「テンプレヌト.key」を甚意したした。 登壇者は、以䞋の手順で登壇資料を䜜成したす。 「テンプレヌト.key」を耇補 ↓ 䞍芁な䜿甚䟋を削陀 ↓ 䜿える䜿甚䟋は曞き換え たたはマスタヌスラむドから新芏䜜成 たた「カラヌパレット. clr 」も甚意したした。 これは登壇者のPCの「~/Library/Colors/」に远加したす。 登壇資料䜜成時に色を倉曎したい堎合は、甚意したパレットから色を遞んでもらいたす。 気を぀けたこず テンプレヌト䜿甚のハヌドルを䞊げないよう、ルヌルを詳现たで固めすぎないように気を぀けたした。 「ガむドに沿っお敎列しおね」ずだけ䌝えお、あずは自由に䜿っおもらっおいたす。 資料䜜成埌のデザ むンチェ ックも必須ではなく、登壇者本人が必芁ずする堎合のみ確認するようにしたした。 展開埌のフォロヌずアップデヌト テンプレヌトのデヌタを展開埌、瀟内勉匷䌚で登壇資料の䜜り方の詳现を説明したした。 デザ むンチェ ックや Keynote の䜿い方説明は、芁望があれば個別で行うようにしおいたす。 たた、珟状のものは完成圢でなく、随時アップデヌトをかけお改善し続けたいずいう旚を䌝えたした。 スタメン瀟員が「テンプレヌト.key」を䜿甚しお登壇資料を䜜った際は、改善点や新たに増やしたいマスタヌスラむドなどをフィヌドバックしおもらっおいたす。 実際にこのテンプレヌトを利甚しお、資料を䜜成した゚ンゞニアからは䞋蚘のフィヌドバックをもらいたした。 テンプレヌトをそのたた䜿っお資料を䜜るだけで、デザむン的に敎った資料になり楜だった。 デザむンを意識する必芁がないため、発衚内容のブラッシュアップに集䞭できた。 意図したずおり、登壇者が発衚内容に泚力できたのは良かったので、改善点などももらっおアップデヌトを続けおいきたす。 たずめ 以䞊、登壇資料テンプレヌトの䜜成から展開たでに行ったこずをご玹介したした。資料テンプレヌト䜜成をご怜蚎の方の参考になれば幞いです。 株匏䌚瀟スタメンでは䞀緒に働く仲間を募集しおいたす。ぜひお気軜に話を聞きに来おください Wantedly は こちら
スタメン ゚ンゞニアの束谷( @uuushiro )です。6/8に開催された 名叀屋Ruby䌚議04 でRuby×AWS Lambdaの内容に぀いお発衚しおきたした。発衚時に口頭で補足しおいた内容も含めお今回蚘事にしたした。こちらのスラむドは図を倚めに説明をしおいるので参考にしおいただければ幞いです。 https://speakerdeck.com/uuushiro/ruby-x-aws-lambdade-sabaresufalsedao-ru-tunagfen-xi-ji-pan-falseshi-li-womotoni TL;DR スタメンが運営しおいるサヌビス「TUNAG」におけるデヌタ凊理基盀にAWS Lambdaを導入するこずで、簡単に䞊列凊理を実珟しデヌタ凊理時間を倧幅に短瞮するこずができ、サヌバヌ運甚コストから解攟されたした。今回はRuby × AWS Lambda × SAM を利甚したアプリケヌションの䜜成方法、自動テストに぀いお共有したす。 AWS Lambda掻甚の背景 スタメンが運営しおいるサヌビス、「TUNAG」は䌚瀟ず瀟員・瀟員同士の‚゚ンゲヌゞメント(信頌関係)向䞊を‚目的ずした䌁業向けSNSです。TUNAGで発生したコミュニケヌションなどのデヌタは、䌚瀟ぞの関心や瀟員同士の関係性が反映されおいたす。そのデヌタを分析するこずで、瀟内の゚ンゲヌゞメント状況を定量的に枬定するこずができたす。このデヌタずいう根拠に基づいた瀟内掻性化斜策のPDCAを回すこずができるずいうずころが TUNAG の匷みの1぀です。そのため、デヌタ凊理基盀はこれからのTUNAGのビゞネス䞊重芁な鍵になっおいたす。 しかし、゚ンゲヌゞメントのような定性的なものを数倀化するずいうこずはただただ䞍確実性が高いです。そのため頻繁に分析指暙の芋盎しをするこずがあるのですが、過去党期間分の指暙の再集蚈ずもなるず既存のデヌタ凊理基盀では8時間ほどの時間がかかっおしたい、詊行錯誀の回数に制限がありたした。そこでAWS Lambdaのオヌトスケヌルを掻甚するこずで、耇数のEC2むンスタンスの管理をせずに䞊列凊理を実珟でき、集蚈時間を短瞮するこずができたした。たた、スタメンではRubyに慣れおいる゚ンゞニアが倚いずいう理由から、AWS LambdaではRuby ランタむムを利甚したした。この蚘事では、Ruby × AWS Lambda × SAM を利甚したアプリケヌションの䜜成及び自動テストの方法に぀いお共有したす。 管理フレヌムワヌク SAMを利甚した開発 デヌタ凊理基盀のように䞀定の芏暡以䞊のシステムをサヌバヌレスで構築する堎合、耇数のAWS Lambda関数を管理する必芁があり煩雑になりがちです。そしおRubyのコヌドをLambdaにデプロむする際にも、S3ぞファむルをアップロヌドしAWS Lambdaず玐付ける䜜業が必芁で時間ず手間がかかっおしたいたす。このような悩みを解決しおくれるのが、AWS SAM(Serverless Application Model)です。 AWS SAM(Serverless Application Model) SAMは以䞋の特城を持぀、サヌバヌレスアプリケヌションを構築するためのフレヌムワヌクです。 * サヌバヌレスアプリケヌションの管理フレヌムワヌク * CloudFormationのサヌバヌレスリ゜ヌス特化の拡匵 * アプリケヌションのビルド・パッケヌゞング・デプロむコマンドを提䟛 * ロヌカルでAWS Lambdaの構築・テスト・デバッグが可胜 このため、耇数のLambda関数をCloudFormationのようにコヌドで管理するこずができ、たたCLIでデプロむを簡単に実行できたす。具䜓的なSAMの䜿い方を芋おいきたす。 SAMずは SAMの開発フロヌ 以䞋のように、 sam init --runtime ruby2.5 ずするこずでランタむムがRubyに指定されたアプリケヌションのサンプルの雛圢が䜜成されたす。ここで生成された template.yml ずいうファむルにはAWSのサヌバヌレスリ゜ヌスが蚘述されおおり、以䞋の AWS::Serverless::Function はAWS Lambdaの関数を衚しおいたす。 以䞋のSAMコマンド package を実行するず、察象関数のフォルダ(CodeUriプロパティ)の .zip ファむルを䜜成しS3ぞアップロヌドし、さらにロヌカルの生成物ぞの参照をアップロヌドしたS3のURLに眮き換えた packaged.yamlずいうファむルが䜜成されたす。 $ sam package --s3-bucket tunag-sam-temlate-store そしお以䞋の deployコマンドを実行するず、テンプレヌトに蚘述されおいる通りのリ゜ヌスがAWS䞊に構築されたす。 $ sam deploy \ --template-file packaged.yaml \ --stack-name sample-functions \ --capabilities CAPABILITY_NAMED_IAM Gemの扱いに぀いお RubyでAWS Lambdaのアプリケヌションを䜜成する際にも、通垞のRubyアプリケヌション開発ず同じように䟿利なGemで開発効率を䞊げたいです。䞋蚘のsam buildコマンドは、アプリケヌション内の関数を繰り返し凊理し、Gemfileをもずに䟝存関係を解決し、Lambdaにデプロむできる成果物を.aws-sam / buildフォルダヌに曞き蟌みたす。 $ sam build Gemfileに応じお䞋蚘のコマンドが実行されるため、成果物のディレクトリ構成は以䞋のようになりたす。 $ bundle install --deployment --without development test AWS Lambdaでは、以䞋のように vendor/bundleがgemの探玢ディレクトリ察象(GEM_PATH)であるため、sam build コマンドで生成された成果物をデプロむするだけでAWS LambdaからGemを利甚するこずができたす。 # GEM_PATH $LAMBDA_TASK_ROOT/vendor/bundle/ruby/2.5.0 /opt/ruby/gems/2.5.0 ネむティブ拡匵があるGemの扱いに぀いお ネむティブ拡匵があるGemは、Lambdaの実行環境ず同等環境で成果物を生成する必芁がありたす。 䟋えば、nokogiri が䟝存しおいる libxml2 ず libxslt はLambdaのむメヌゞに含たれおいるので、以䞋のコマンドでビルド可胜です。 buildコマンドに --use-containerオプションを぀けるず、Lambdaの実行環境ず同等環境のコンテナ内ででビルドを実行しおくれたす。 $ sam build --use-container それに察しお、mysql2 が䟝存しおいる mysql-devel はAWS Lambdaのむメヌゞに含たれおいないため、Lambdaむメヌゞコンテナで必芁なパッケヌゞをむンストヌルした䞊でbundle installをする必芁がありたす。 $ docker run -v `pwd`:/var/task -it lambci/lambda:build-ruby2.5 \ /bin/bash -c "yum -y install mysql-devel; bundle install --path=ruby/gems;" このずき、必芁な共有ラむブラリ(libmysqlclient)は、 LD_LIBRARY_PATHに配眮するこずでLambdaから読み蟌むこずができたす。 $ LD_LIBRARY_PATH: /var/task:/var/task/lib:/opt/lib AWS Lambda Layers 耇数のAWS Lambdaの関数を組み合わせおシステムを構築しおいるず、耇数の関数の間で共通のロゞックコヌドがでおきたす。 AWS Lambdaでは、それぞれの関数に共通するコヌドをそれぞれの関数に察しアップロヌドする必芁がありたす。たた、ロゞックを曎新するたびに activesupport や mysql2 のGemのファむル矀など、倉曎がないファむルをアップロヌドする必芁がありたす。その結果、アップロヌドするファむルの容量が無駄に増え、容量の制限やデプロむ時間の遅延など問題が出おきたす。そこで AWS Lambda Layers ずいう機胜が圹に立ちたす。AWS Lambda Layersは以䞋の特城がありたす。 耇数のAWS Lambdaでコヌドを共有できる仕組み Lambdaを呌び出すずLayersがコンテナの/opt配䞋にマりントされる sam build は珟時点で非察応 AWS Lambda Layers は、共有コヌドを管理したり、コヌドの倉曎頻床が少ないラむブラリやGemを配垃したりする堎合に特に䟿利です。Layersのパッケヌゞを耇数のLambda関数に添付しお䜿甚するこずができるため、AWS Lambda関数のビゞネスロゞックが単玔化され、䟝存関係管理が容易になり、デプロむパッケヌゞのサむズを小さくできたす。 たた、AWS Lambdaのデプロむパッケヌゞの最倧サむズは50 MBですが、最倧5぀のLayersをアタッチするこずで、250MBたで䞊限を増やすこずができたす。たた、Gemや共有コヌドなどの䟝存関係ずビゞネスロゞックの間で、関心事の分離を匷制できるこずがLayersを利甚するこずの副次的なメリットでもあるず思いたす。 AWS Lambda Layers 参考URL 共通コヌド甚をLayersで扱う方法は、以䞋のように template.yamlに AWS::Serverless::LayerVersionずいうリ゜ヌスを定矩し、AWS::Serverless::FunctionのLayersプロパティから参照するだけです。 LayersにおけるRubyラむブラリの探玢パス(RUBY_LIB)は ruby/lib なので、以䞋のような構成でコヌドを配眮すれば、LambdaからLayersを通しお読み蟌むこずができたす。 LayersにおけるGemの探玢パス(GEM_PATH)は ruby/gems/2.5.0 なので、以䞋のような構成でGemを配眮すれば、LambdaからLayersを通しお読み蟌むこずができたす。 img2lambdaを䜿ったLayersのデプロむ(おたけ) Layersを䜜成する際に、䟝存関係の管理などが倚少煩雑になっおいたした。この管理をもう少し簡単にする方法は無いかず色々探しおいた䞭で、AWSが提䟛しおいる img2lambda ずいうラむブラリがあったので玹介したす。 これは、DockerむメヌゞをLambdaやLayersに倉換しデプロむできるツヌルで、これを利甚するこずで䟝存関係をむメヌゞに閉じ蟌め‚倉曎があれば再ビルドずいう圢で簡単に管理できるようになりたす。ずおも䟿利なので䜿っおみたかったのですが、埌述するSAMのAWS Lambda Layersのロヌカル実行機胜が利甚できなくなっおしたうので、今回は採甚を芋送りたした。 img2lambda 自動テスト AWS Lambdaのコヌドに぀いおも普通のアプリケヌションず同様に自動テストを曞いおいきたす。ただ、AWS Lambdaずいう環境の特性を考慮し、以䞋のような方針で自動テストを行うこずにしたした。 クラりド䞊での怜蚌はデプロむなどを含め時間が掛かり過ぎるのでなるべく ロヌカルでテスト したい AWS Lambdaは他のAWSサヌビスずの連携が倚く統合テストが重芁になる IAM暩限などの、クラりドでしか怜蚌できないものに限りクラりド䞊でテストを行う 今回はAWS Lambdaをロヌカルでテストをする方法に぀いおフォヌカスしたす。AWS Lambdaのロヌカルテストにおいお、以䞋3点のポむントを考慮しテストを䜜成したした。 AWS Lambda特有の䟝存を排陀し単䜓テストを行いやすいコヌドにする AWSサヌビスに䟝存するロゞックはスタブを利甚する ロヌカルにLambdaの゚ンドポむントを起動し、AWS Lambda・Layersの組み合わせでテストする 実際に、TUNAGのデヌタ凊理基盀で想定されるテストケヌスずしお、Athenaぞのク゚リが倱敗した堎合を考えおみたす。テストの手順ずしお、以䞋の1~3をコヌドず共に瀺したす。 ① Athenaぞのク゚リ実行APIを叩く ② ク゚リは非同期的に凊理されるため‚実行IDをもずに実行状況を問い合わせる ③ ク゚リの結果を取埗し状態が‚ “FAILED”なら䟋倖を投げる たずここで1぀目のポむント、 AWS Lambda特有の䟝存を排陀し単䜓テストを行いやすくする を考慮し、以䞋のようにLambdaに䟝存するハンドラヌの匕数などの箇所からロゞックを切り離したす。 そうするこずで以䞋のように、Lambdaに䟝存しないコヌドになり、通垞のRubyのクラスずしおテストが可胜になりたした。 続いお、Athenaのような他AWSサヌビスに䟝存するロゞックをどのようにテストをすればいいでしょうか。ここで、2぀めのポむントの AWSサヌビスに䟝存するロゞックはスタブを利甚 を実践したす。AWSが提䟛する、AWS SDK for Ruby には 䟿利なスタブ機胜があり、APIアクセスのレスポンス・゚ラヌを簡単にスタブするこずができ、AWS APIクラむアントを実行するように振る舞いたす。 クラむアントをスタブする方法は、以䞋のように、クラむアントオブゞェクト䜜成時に stub_responsesパラメヌタにtrueを蚭定したす。そしお、stub_dateメ゜ッドでスタブデヌタを䜜成し、stub_responsesメ゜ッドの匕数に蚭定するこずで、特定のAPI呌び出しメ゜ッドのレスポンスにスタブデヌタを蚭定するこずができたす。 ここで䜜成したスタブオブゞェクトを匕数でテスト察象に枡すこずで、ロヌカルでAWSサヌビス䟝存のテストができるようになりたした。 AWS Lambdaのテストに぀いおは @t_wada さんの資料 Testable Lambda がずおも参考になったので、興味のある方は是非芋おみおください。この資料の䞭で利甚されおいる LocalStackずいう、ロヌカルにAWSサヌビスず同等に振る舞う゚ンドポむントを提䟛しおくれるサヌビスを利甚しおテストをしおも良かったのですが、今回デヌタ凊理基盀に必芁なAWS Athena・Glueは‚非サポヌトだったため、AWS SDK for Ruby のスタブ機胜を利甚したした。 そしお3぀目のポむント、 ロヌカルにLambdaの゚ンドポむントを起動し、AWS Lambda・Layersの組み合わせでテスト をしたす。ロヌカルでAWS Lambda・Layers を組み合わせおテストをする方法ずしお、SAMにはロヌカルでLambdaの゚ンドポむントを起動するコマンドが甚意されおいたす。 $ sam local start-lambda 䞊蚘のコマンドを実行し、以䞋のように゚ンドポむントをロヌカルに向け、テスト察象のLambdaをinvokeするこずで、Layersを含めたAWS Lambdaのテストがロヌカルで実行可胜になりたす。 たずめ 以䞊、Ruby × AWS Lambda × SAMにおけるアプリケヌション䜜成・自動テストに぀いお説明したした。通垞のRubyアプリケヌション開発ず比べるず考慮するべき事項が倚く、決しお簡単ではありたせんでした。しかし、今回のデヌタ凊理基盀においお、AWS Lambdaの「オヌトスケヌル」、「埓量課金性によるコストパフォヌマンスの向䞊」、「サヌバヌ運甚コストからの解攟」ずいうメリットは、そのようなコストを優に䞊回ったのではないかず考えおいたす。 たた今回玹介した開発・自動テスト方法がベストだずは思いたせんので䟋えば、SAMではなくServerless Frameworkならもっず簡単にできるよ、このツヌル䟿利だよ、ずかありたしたら是非フィヌドバックいただけるず嬉しいです。 スタメンでは、Railsアプリケヌションの開発及び、基盀システムをAWSで構築する゚ンゞニアを倧募集䞭です興味をもたれた方は是非こちらの ゚ンゞニア採甚サむト から気楜にご連絡ください。
スタメン ゚ンゞニアの接田です。スタメンで運営しおいるサヌビス、「TUNAG」では、毎日、デヌタベヌスの"その日の状態"を別々のデヌタベヌスずしお残しおいたした。こちらの運甚を、 AWS のS3、Glue、Athenaを利甚しお眮き換えたのですが、その䞭で利甚した、 MySQL 互換Auroraから、S3䞊ぞのデヌタ抜出甚 スクリプト の玹介をいたしたす。 TL;DR (抂芁) TUNAGでは、デヌタベヌスずしお、 Amazon Aurora ( MySQL 互換)を䜿甚しおいたす。サヌビス利甚状況の分析などで、過去の特定時点でのデヌタベヌスが必芁ずなるため、いたたでは、日次でデヌタベヌスのコピヌを䜜成し、䞀぀のRDS むンスタンス 内に远加しおいたした。 この圢匏では、党おを䜿い慣れたデヌタベヌス䞊で完結できるため、機胜の構築は玠早く行えたのですが、デヌタ総量が日々増え、凊理時間が次第に増倧しおいたした。なんらかの原因で凊理が倱敗した堎合の再詊行にかかる時間も含めるず蚱容できない長さになり぀぀あったため、以䞋のように眮き換えおいたす。 Auroraのクロヌン機胜 を利甚しお特定時点でのDBクロヌンを䜜成した䞊で、 AWS Glueゞョブで各テヌブルの内容を parquet 圢匏でS3䞊に抜出し、デヌタの利甚は Athena 経由ずしおいたす。 今回玹介するのは、図の黄色い郚分で䜿甚したGlueゞョブの スクリプト です。 Glueを利甚しおS3にファむルを䜜成する AWS Glue は抜出、倉換、ロヌド (ETL)を行うマネヌゞド型のサヌビスです。今回は、Auroraのテヌブルをそのたたの圢でファむルずしお出力するだけなので、 AWS Consoleの「Add job」ボタンから、コヌドを䞀行も曞かずに凊理を䜜成するこずも可胜です。 ただ、その堎合、 たず、出力元のデヌタベヌスに察し クロヌラヌ を蚭定しデヌタカタログを䜜成 テヌブル数だけGlueのゞョブを䜜成 今埌、テヌブルの远加があった堎合、手動で個別にゞョブを远加 ずいった手順が必芁ずなりたす。元になるデヌタベヌスぞのテヌブル远加はそれなりの頻床で発生するため、そのたびにゞョブを䜜成するのは嬉しくありたせん。そこで、生成された スクリプト をベヌスに、 mysql のinformation_schemaを参照しお、デヌタベヌス内の党おのテヌブルを調べお抜出するよう倉曎したした。 import sys import datetime from awsglue.transforms import * from awsglue.utils import getResolvedOptions from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.job import Job # ゞョブのパラメヌタヌを取埗 arg_keys = [ 'JOB_NAME' , 'jdbc_url' , 'db_user' , 'db_password' , 'bucket_root' , 'db_schema' ] args = getResolvedOptions(sys.argv, arg_keys) (job_name, jdbc_url, db_user, db_password, bucket_root, db_schema) = [args[k] for k in arg_keys] # Athenaで利甚する際、パヌティション分割をするため、幎月日を取埗しおおく now = datetime.datetime.now() date = [now.year, now.month, now.day] sc = SparkContext() glueContext = GlueContext(sc) spark = glueContext.spark_session # 党テヌブルを察象ずするため、たず、information_schemaのテヌブル情報を取埗 df = glueContext.create_dynamic_frame_from_options( 'mysql' , connection_options={ "url" : jdbc_url + "information_schema" , "user" : db_user, "password" : db_password, "dbtable" : "tables" } ) # 抜出する必芁がないテヌブルはfilterで匟いおおく。ar_internal_metadataはRailsが自動生成するテヌブル target_tables = df.toDF().filter( "TABLE_SCHEMA = '{0}' AND TABLE_NAME <> 'ar_internal_metadata'" .format(db_schema)).collect() # 1テヌブルず぀抜出 for row in target_tables: table_name = row[ 'TABLE_NAME' ] ds = glueContext.create_dynamic_frame_from_options( 'mysql' , connection_options={ "url" : jdbc_url + "dbname" , "user" : db_user, "password" : db_password, "dbtable" : table_name }) # S3䞊にdynamic frameを曞き出す。パスには、パヌティションを付加しおおく glueContext.write_dynamic_frame.from_options( frame=ds, connection_type= "s3" , connection_options={ "path" : bucket_root + table_name + "/YEAR={0[0]:0>4}/MONTH={0[1]:0>2}/DAY={0[2]:0>2}" .format(date)}, format = "parquet" ) 実行数を調敎する Glueのゞョブには、Maximum capacityずいう項目があり、スケヌルアりトするために䜿甚できるデヌタ凊理単䜍(DPU)を指定できたす。これはデフォルトでは10に蚭定されおいるのですが、 DPU の容量蚈画のモニタリング を参考にメトリクスを確認したずころ、先述の スクリプト の曞き方ではDPUを䜿い切れおいなかったので、適圓ず思われる数字に枛らしお蚭定し盎したした。 1 ぀の DPU はアプリケヌションマスタヌ甚に予玄されおいたす。9 個の DPU はそれぞれ 2 ぀の゚グれキュタヌを実行し、1 ぀の゚グれキュタヌは Spark ドラむバヌ甚に予玄されおいたす。そのため、割り圓おられる゚グれキュタヌの最倧数は、2*9 - 1 = 17 です。 DPU の容量蚈画のモニタリング に以䞊のように曞かれおいるので、゚グれキュタヌの数は、DPU x 2 - 3になるず思われたす。぀たり、DPU2だず利甚できる゚グれキュヌタ数は1ですが、DPU3だず3で、䞉倍になりたす。もし、゚グれキュヌタヌ時間3で終わる凊理があるずするず、DPU2では3/1で3時間、DPU3なら3/3で1時間で終わりたす。Glueの課金はDPU時間あたりなので、DPU3(3 x 1時間 = 3)であれば、DPU2(2 x 3時間 = 6)の半額で枈む蚈算です。Maximum capacityは、必芁ずされる゚グれキュタヌの数を䞊回らない範囲で倧きな倀を蚭定するず、凊理が早く、か぀、費甚が抑えられるこずになるず思われたす。 たずめ Glueを利甚しおデヌタを抜出する郚分を玹介させおいただきたしたが、生成されたファむル利甚しおをAthena経由で集蚈、結果を分析甚デヌタベヌスにロヌドするなど、埌続の凊理は AWS Lambdaで Ruby スクリプト を䜿っお実装しおいたす。こちらに぀いおは、 @uuushiro が 名叀屋Ruby䌚議04 で発衚したすので、よろしければお越しください。 たた、 AWS Summit Tokyo内で行われる、 Startup Architecture of the Year 2019 にも出堎させおいただきたすので、よろしくお願いしたす。
株匏䌚瀟スタメンでWebフロント゚ンド・サヌバヌサむドの開発をしおいたす、河井ず申したす。 本蚘事では react-chartjs-2 の䜿い方に぀いおの解説をしたす。React でグラフを曞くこずになったけど始め方が分からないなどずいったずきに参考にしおいただければ幞いです。 TL;DR (抂芁) グラフ描画のためのラむブラリである Chart.js を React の コンポヌネント ずしお利甚できるようになるラむブラリ、react-chartjs-2 の解説蚘事です。グラフに衚瀺するデヌタを むンタラクティブ に切り替えたり、図を綺麗に芋せるために Plugin を甚いた実装を解説したす。 グラフの描画 前提ずしお、玹介するラむブラリは既にむンストヌルされおいるものずしたす。 たた、簡単のため コンポヌネント は分割せずに1぀の コンポヌネント 内で完結するようにしおいたす。 たずは基本圢です。Line や Bar ずいった コンポヌネント に察し、data ず options(必芁であれば) を枡したす。 import React, { Component } from 'react' ; import { Line } from 'react-chartjs-2' ; class SampleChart extends Component { render { const data = { labels: [ 'April' , 'May' , 'June' , 'July' , 'August' , 'September' ] , datasets: [ { data: [ 67, 79, 52, 41, 66, 43 ] , // 省略 } , ] , } ; const options = { // 省略 } ; return ( <Line data= { data } options= { options } /> ); } } 以䞋のようなグラフが衚瀺されたす。 䜿甚できる コンポヌネント の皮類は react-chartjs-2 のレポゞトリ を、 data ず options の圢匏に぀いおは、 本家 chart.js のドキュメント を参照しおください。 デヌタの取埗ずグラフの曎新 data や labels を動的に取埗したい堎面のほうが倚いかず思うので、それらを state ずしお管理したす。 実際の利甚シヌンずしお、ずあるグラフが日付を起点ずしおデヌタを取埗しおいるずき、その起点ずなる日付を指定しおグラフを曎新したい、ずいった状況を想定しおみたす。 たず、ペヌゞの衚瀺時には componentDidMount() 内でデヌタを取埗したす。 䜕らかの方法で日付を曎新したずしお、その日付が state であれば コンポヌネント が再描画されたす。その盎埌に呌び出されるラむフサむクルメ゜ッドずしお componentDidUpdate() があり、ここでその日付に応じおデヌタを再取埗したす。 以䞋がその実装䟋です。DatePicker は、カレンダヌから日付を遞択するような コンポヌネント を想定しおいたす。 import React, { Component, Fragment } from 'react' ; import moment from 'moment' ; class SampleChart extends Component { constructor(props) { super (props) this .state = { date: moment() } ; } componentDidMount() { this .getData(); } componentDidUpdate(prevProps, prevState) { if (prevState.date !== this .state.date) { this .getData(); } } getData() { const { data, labels } = fetchData( this .state.date); //日付に基づいた䜕らかのデヌタ取埗凊理 this .setState( { data: data, labels: labels } ); } render { // 省略 各皮倉数の定矩等 return ( <Fragment> <DatePicker date= { date } onDateChange= { (newDate) => { return this .setState( { date: newDate } ); }} /> //䜕らかの日付倉曎凊理 <Line data= { chartData } options= { chartOptions } /> </Fragment> ); } } if (prevState.date !== this.state.date) { ... } の郚分で曎新前の日付ず曎新埌の日付を比范しおいお、異なっおいればデヌタが再取埗されたす。 クリックむベントの远加 グラフ芁玠をクリックしお、クリックされたラベル日付などに応じお凊理をしたいずきのために、クリックむベントを远加するこずができたす。 以䞋は、クリックしたグラフ芁玠に察応するラベルのむンデックスをコン゜ヌルに出力するサンプルです。むンデックスは elements[0]._index で取埗するこずができたす。 import React, { Component } from 'react' ; import { Bar } from 'react-chartjs-2' ; class SampleChart extends Component { handleClick(elements) { if (elements.length === 0) return ; console.log(elements [ 0 ] ._index); } render { return ( <Bar data= { data } options= { options } onElementsClick= { (elements) => this .handleClick(elements) } /> ); } } 拡匵機胜 の利甚 Chart.js はそれだけでもなかなか 衚珟の自由 床が高いものですが、さらにその幅を広げるための 拡匵機胜 extensionsが甚意されおいたす。 extensions を甚いるず远加のグラフパタヌンが䜿えるようになったり、より凝った衚瀺オプションを蚭定できるようになりたす。今回はその䞭の chartjs-plugin-datalabels を玹介したす。 chartjs-plugin-datalabels はその名の通りラベルに関する拡匵で、どのような皮類のグラフに察しおも自由な䜍眮にラベルを衚瀺できるようになりたす。 数倀差が倧きくなるず小さい方の数倀が把握しにくくなるので、パッず芋おわかるようにしたいです。この プラグむン を䜿っお棒グラフの終端に数字を衚瀺しおみたいず思いたす。 ラベルの衚瀺に関するパラメヌタはいろいろありたすが、今回の実装のためには anchor 、 align が関係しおきたす。 具䜓的には、anchor でグラフの先頭、䞭心、終端のどこにラベルを眮くかの基準点を指定し、align で anchor で指定した基準点からどの方向にラベルを蚭眮するかを指定したす。 これらを組み合わせお、 anchor: 'end', align: 'right' ずするこずで、終端の右偎に衚瀺したす。 実装は以䞋のようになりたす。 import 'chartjs-plugin-datalabels' ; const chartOptions = { plugins: { datalabels: { display: true , anchor: 'end' , align: 'right' , formatter(value) { if (value === null || value === 0) { return '' ; } return `$ { value } %` } , } , layout: { padding: { right: 50, } , } , // 省略 } ; ラベルを衚瀺する䜙癜をが必芁がほしかったので右偎に padding を入れおいたす。 たた、衚瀺する倀に単䜍を付ける、3桁ごずにカンマで区切るなどの衚瀺圢匏は、 formatter の䞭で蚘述するこずができたす。 今回は暪向き棒グラフを䜿いたいので、 HorizontalBar コンポヌネント を䜿いたす。 render ( <HorizontalBar data= { chartData } options= { chartOptions } /> ) これを実際に衚瀺するず次のようになりたす。 たずめ 本蚘事では、react-chartjs-2 の䜿い方を、基瀎から応甚たで玹介したした。基本的な機胜がデフォルトで揃っおいながらも、非垞に柔軟なラむブラリでもあるので、グラフを実装する際はぜひカスタマむズしお䜿っおみおください。 たた、株匏䌚瀟スタメンでは䞀緒に働く仲間を募集しおいたす。お気軜にお話を聞きに来おいただければず思っおいたす 名叀屋から䞖界ぞHRtechサヌビスの自瀟開発゚ンゞニアず話したせんか 参考 Chart.js react-chartjs-2 Github Chart.js popular extensions
こんにちはスタメンで TUNAG の iOS / Android アプリ開発 を担圓しおいる @temoki です。 CTOの小林が スタメンの゚ンゞニアが䜜っおいる『TUNAG』の技術的な解説 で TUNAG 党䜓のテク ノロ ゞヌ スタックに぀いおお話しおいたすが、今回は iOS アプリにフォヌカスを圓おおお䌝えしようず思いたす。 蚀語 TUNAG の iOS アプリはすべお Swift で曞かれおいたす。Swift のバヌゞョンアップにもすぐに察応しおいるため、珟時点で最新の Swift 5 を䜿甚しおいたす。Swift は Optional 型により Null Safety を実珟しおおり、TUNAG iOS アプリでは今のずころ Null Pointer Exception によるクラッシュレポヌトは届いたこずがありたせん玠晎らしい。 Swift は初期のバヌゞョン〜あたりたではバグやバヌゞョンアップごずに砎壊的に仕様が倉わっおいくのに苊劎したしたが、バヌゞョン以降は仕様も安定し、安心しお利甚できるようになりたしたね。 サヌビス TUNAG は AWS + Ruby on Rails で構築されおいたすが、mBaas (mobile backend as a service) の Firebase も利甚しおいたす。特に今幎の月に正匏リリヌスされたばかりの Cloud Firestore のおかげで、非垞に即時性の高いチャット機胜を実珟するこずができたした。たた、Cloud Firestore はオフラむン利甚のために取埗枈みのデヌタを自動的にロヌカルストレヌゞにキャッシュしおくれたすし、デヌタがどこかを意識するこずなくアクセスできる点もずおも䟿利です。 Cloud Firestore だけでなく、TUNAG ず連携したナヌザヌ認蚌のために Authentication 、クラッシュレポヌティングのために Crashlyitics など、Firebase を広く掻甚しおいたす。 たた、アプリぞのプッシュ通知配信には NIFTY CLOUD mobile backend を珟圚利甚しおいたすが、これも Firebase の Cloud Messaging ぞの移行を怜蚎䞭です。 (2020/2/5 远蚘) アプリぞのプッシュ通知配信は、2019幎9月に Firebase の Cloud Messaging に移行し、配信速床が栌段に向䞊したした。 ラむブラリ iOS アプリでは、HTTPネットワヌキングは Almofire を䞭心ずし、画像の読み蟌みに AlamofireImage 、Web API クラむアントの実装のために Almofire のラッパヌである Moya を䜿甚しおいたす。アプリからは様々な Web API を䜿甚したすが、Moya はその API 仕様に沿っお宣蚀的に実装しおいけるずころがお気に入りです。 たた、先日 TUNAG iOSアプリのチャット機胜をVIPERアヌキテクチャで開発した話 にも曞きたしたが、デヌタレむダヌで Cloud Firestore から受け取るリアルタむムアップデヌトに察しおリアクティブに凊理するために Reactive X の Swift 実装である RxSwift を䜿甚しおいたす。 その他には Swiftコヌド の静的解析の SwiftLint 、画像やStoryboardのようなリ゜ヌスをタむプセヌフに扱うために SwiftGen などの開発支揎のためのツヌルも掻甚し、コヌド品質を確保しおいたす。 これらのラむブラリは基本的に Carthage でむンストヌルするこずで開発䞭のビルド時間の短瞮しおいたすが、Carthage に非察応のラむブラリのみ Cocoapods を利甚しおいたす。 ベヌタテスト TUNAG はスタメンのメンバヌ自身がヘビヌナヌザヌです。そのためアプリの新バヌゞョンは垞に瀟内メンバヌでのテストを実斜しおいたす。 開発䞭のステヌゞング環境で動䜜するアプリは、 Fabric の Beta ずいうサヌビスにより開発メンバヌの iOS デ バむス にデプロむしおいたす。この Fabric は Twitter 瀟が提䟛しおいたモバむルアプリの開発支揎サヌビスですが、 Google 瀟に売华されお珟圚 Firebase ぞの統合が進められおいる状態 です。Crashlytics も Fabric が提䟛するサヌビスの䞀぀でしたが、Firebase ぞの統合もほが完了しおいたす。Beta も Firebase App Distribution ずしお統合される予定です。そのため Beta による ベヌタテスト 䞭にアプリがクラッシュした堎合も、Crashlytics によりちゃんずレポヌトされるので助かりたす。 (2020/2/5 远蚘) Firebase App Distribution がベヌタリリヌスされたため、2019幎12月に Fabric Beta からの移行したした。 新バヌゞョンの開発の終盀では、開発メンバヌだけではなく瀟内のたくさんのメンバヌにお普段利甚しおフィヌドバックしおもらうために、プロダクション環境で動䜜するアプリを Apple 公匏の Test Flight で瀟内メンバヌに配信しおいたす。 そしおテストやリリヌスのためのアプリのビルドには Fastlane を䜿甚しおいたす。Fastlane には Beta や Testflight ぞのアプリのアップロヌドや、クラッシュ解析甚のシンボルファむルのアップロヌドなどの機胜が揃っおいるため、ビルドからデプロむたでの䞀連の流れをコヌドで定矩しお自動実行できおしたいたす。 さいごに いかがでしたでしょうか。TUNAG の iOS アプリの開発はこのようなモダンな環境で行なっおいたす。これは実はこの半幎間くらいで敎備しおきたもので、今埌は Android アプリの方も培底改善しおいく予定です。 このようなモダンな環境での iOS アプリ開発 や、今埌の Android アプリ開発 環境がどのように改善されおいくのかに興味を持たれた方は、 こちら から気軜にご連絡ください
抂芁 こんにちは、スタメンの小林( @lifework_tech )です。 スタメンの名叀屋オフィスは、 東海道新幹線 の高架䞋にある倉庫のような広い空間に、 ものすごく倧きな机 をみんなでシェアしお䜿っおいたす。 机が広くお、暪幅ず奥行きがあるため、゚ンゞニアやデザむナヌが圚籍するプロダクト郚のみんなはそれぞれの奜みの環境にしお快適に仕事をしおいたす。 今回、䜕人かに、こだわりの環境に぀いおむンタビュヌしたしたので、ご玹介させおください。 暙準的な机 たずは、スタメン暙準環境。 スタメンの゚ンゞニア or デザむナヌは、 MacBook Pro 15むンチ + LG 27むンチ 4Kディスプレむ + Apple Magic Keybord もしくは、Magic Trackpad ずいう環境が暙準です。キヌボヌドやマりスは持ち蟌んでも良く、あずで玹介しおいるように自分でカスタマむズしおいる人もいたす。 キヌボヌド垫匠 (ネむティブチヌムの゚ンゞニア) ネむティブ゚ンゞニアのKさんのデスクです。 Kさんによっお、デュアルキヌボヌドの良さが垃教されたため、勝手にキヌボヌド垫匠ず思っおいたす。 タむピングによる肩甲骚の痛みを解消するために、 日本語配列 の貎重な分割キヌボヌド MiSTEL BAROCCO MD600 を䜿甚しおいたす。日本語印字がなく、オレンゞのアクセントカラヌがお排萜です。 このキヌボヌドはそもそも Mac 甚に最適化されおいるわけではなく、よく䜿甚するカヌ゜ルキヌや英数・かなキヌがないため、キヌボヌド本䜓のカスタマむズ機胜ず Karabiner Elements を駆䜿しお Mac の 日本語配列 に極力近づけおいたす。 パヌムレスト は高さがぎったりなので FILCO の分割キヌボヌド甚のもの をチョむス。 普段は Macbook っぜく真ん䞭に配眮した Magic Trackpad で操䜜、資料䜜成など必芁に応じお右偎の Magic Mouse を䜿いたす。 CTOの小林 ドラえもん のような䟿利な道具をだせる゚ンゞニアでありたいず思っおいお、机にはい぀も ドラえもん がいたす。 この ドラえもん は、小芥子( こけし ) なんです。瀟員旅行で行った 銬籠宿 の民芞店で賌入したした。 マりスを真ん䞭に眮くず、手を䌞ばさなくおも操䜜できるので、右腕の疲れ具合が枛るんです。 腕を前に䌞ばすず、腕を支えるために筋力を䜿うので疲れやすく、䜓の近くにマりスを眮くず疲れにくいず、ゞムのトレヌナヌにアド バむス 頂いおからこうしおいたす。 肩を開いた方が疲れにくいずのキヌボヌド垫匠の薊めで、Magic Keybord を2台を Karabiner-Elements で連動させおいたす。 マりスパッドは、steeleseries の ゲヌミングマりスパッドで、かなり衚面が固くおマりスがよく滑るため、長幎䜿っおいたす。 打ち合わせ等で垭を離れるこずも倚く、ケヌブルの抜き差しが楜になるように、 Belkin Thunderbolt 3 Express Dock を䜿っおいたす。 デザむナヌ Mさん マりスをたくさん動かせるよう、広いマりスパッドをおいおいたす。 時々 iPad Proや、ラフを曞くためのノヌト、印刷物を眮くので なるべくスッキリさせおおきたす。 SREチヌムの゚ンゞニア Tさん Ubuntu を䜿甚しおいるこずもあっお、HHKB JP配列に芪指 トラックボヌル ずいう暙準的な構成です 手前の リストレスト は肘が痛くならないようにおいおいたす トラックボヌル を Logicool M570 から ELECOM EX-G に替えた以倖は、7幎ほどこの構成です ボヌルはM570の方が奜みなので、ボヌルのみM570のに入れ替えお䜿っおいたす 䜙ったボヌルは嚘(3æ­³)のおもちゃずしお掻躍しおいたす たずめ ゚ンゞニアにずっお、開発環境の快適さは非垞に倧切で、特に䞀番觊れるこずの倚いキヌボヌドやその配眮は皆さんこだわりがありたすよね。 ご玹介した以倖にも、 ThinkPad トラックポむント・キヌボヌド を䜿っおいる人がいたり、それぞれ快適な環境を敎えおいたす。 スタメン名叀屋オフィスは、たさに ベンチャヌ ずいう感じの 新幹線の高架䞋にあるガレヌゞのようなオフィス で、各自の机以倖にも、 ペアプロ や勉匷䌚にも䜿えるながヌいダむニングテヌブル(䞋図)があったりず、働きやすい工倫が詰たったオフィスです。 どんなオフィスか芋おみたいなず思っおくださったら、ぜひ @lifework_tech ぞお気軜にご連絡ください。オフィスをご案内したす
はじめに こんにちは、スタメンで iOS/Android アプリの゚ンゞニアをしおいる @temoki です。 昚幎の10月にスタメンにゞョむンしおからの私の最初のミッションは、 TUNAG iOS アプリのチャット機胜の開発プロゞェクトでした。本蚘事ではこのチャット機胜開発プロゞェクトにおいお採甚した VIPER ずいうアヌキテクチャに぀いお玹介し、チャット機胜の初版リリヌスからいく぀かの機胜改善を経た珟圚における所感をお䌝えしたいず思いたす。 VIPERの抂芁 VIPERずは 私が VIPER を知ったのは objc.io の Architecting iOS Apps with VIPER ずいう蚘事です。これを読めば VIPER に぀いお䞀通り理解するこずができたすが、端的に説明するために次の文を匕甚したす。 VIPER is an application of Clean Architecture to iOS apps. The word VIPER is a backronym for View, Interactor, Presenter, Entity, and Routing. Clean Architecture divides an app’s logical structure into distinct layers of responsibility. This makes it easier to isolate dependencies (e.g. your database) and to test the interactions at the boundaries between layers: ぀たり次のずおりです日本語に翻蚳しただけですが。 VIPER は iOS アプリケヌションに Clean Architecture を適甚したもの VIPERずいう蚀葉は、 V iew、 I nteractor、 P resenter、 E ntitiy および R outing を衚す バクロニム アプリケヌションの論理構造を責任の異なるレむダヌに分割するこずでデヌタベヌス等の䟝存関係を分離し、レむダヌ間の境界で盞互䜜甚をテストするこずが簡単になる VIPERのメむンパヌツ VIPER は次の぀のパヌツに分類され、それぞれが明確な責務を持ちたす。 V iew Presenter からの指瀺を衚瀺する ナヌザヌ入力を Presenter に䌝える I nteractor アプリケヌションの䞭の䞀぀のナヌスケヌス画面単䜍などを衚珟する デヌタ操䜜ずビゞネスロゞックを含む P resenter Interactor から受けずったデヌタを衚瀺するための準備を行う ナヌザヌ入力に反応しお Interactor に新しいデヌタを芁求する このようなビュヌロゞックを含むが、iOS の UIKit には䟝存しない E ntity Interactor のみに䜿甚される単玔なモデルオブゞェクト R outer 画面がどのように衚瀺されるかの画面遷移ロゞック その衚瀺する画面の生成䟝存性泚入 これは Passive View 方匏の MVP (Model View Presenter) アヌキテクチャがベヌスになっおおり、倧きくなりがちな Presenter から画面遷移ず生成の責務を Router に、そしお画面固有のナヌスケヌスを Interactor に分離しおいるのが特城的です。 それぞれのパヌツの぀ながりは䞋図のようになりたす objc.io の蚘事からの匕甚。 TUNAG アプリぞの適甚 ここからは TUNAG iOS アプリぞの VIPER 適甚に぀いおお話しおいきたす。 なぜ VIPER を採甚したのか TUNAG のチャットは耇数の画面で構成されたすが、メむンずなるチャットルヌム画面のスクリヌンショットがこちらです。 メンション、絵文字、スタンプ、写真投皿、ファむル添付などたくさんの機胜がありたす。TUNAG のチャットは簡易的なものではなく、メンバヌ間の日垞コミュニケヌションやビゞネス甚途ずしおも利甚されるものですので、この぀の画面だけでもずおも倚くの衚瀺パタヌンず入力パタヌンがありたす。そしお TUNAG ずいう事業は長く継続しおいくものですので、今埌の倉曎などのメンテナンスのこずを考えるず最初から適切にモゞュヌルを分割しおいく必芁がありたす。 VIPER は特定のプラットフォヌムやラむブラリに䟝存しおいるものではなく、オブゞェクト指向でアプリケヌションを適切に蚭蚈しおいくためのガむドラむンのようなものです。そのため、開発チヌム内でモゞュヌル分割の方針を共通認識ずしお開発を進めおいけるず感じたため、VIPER を採甚するこずにしたした。 たた、開発チヌムには開発経隓の少ない若手メンバヌもおり、VIPER での構築を実践しおいくこずでメンバヌの蚭蚈力向䞊に぀ながるのではないかずいう期埅もありたした。 TUNAG アプリの VIPERによる構成 最終的に、TUNAG アプリの構成は䞋図のようになりたした。各パヌツで <~> ず蚘述しおいるものは、そのパヌツが準拠する Protocol です。それぞれのパヌツは、その Protocol により接続されるこずになりたす。 View, Presenter, Interactor, Router は基本的に画面単䜍に甚意したす。画面を開発するずきは、その画面における各パヌツの圹割を Protocol で定矩し、それらを Contract (契玄) ずしおたずめたファむルを䜜るようにしたした。こうするこずでこの画面の機胜がたずたったカタログができたす。以䞋が、タスクリスト画面を䜜るずした時の Contract の䟋ずなりたす。そしお、Router がそれぞれの䟝存性を泚入し、たずめお䞀぀の画面モゞュヌルずしお組み立おたす。 /// タスクリスト画面 View protocol TaskListView : class { // Dependency var presenter : TaskListPresentation! { get } /// タスクリストの読み蟌み䞭の衚瀺をする func showLoadingState () /// タスクリストを衚瀺する func showTaskList (_ taskList : [ TaskCellModel ] ) /// タスクリストが䞀぀もない状態を衚瀺する func showEmptyState () } /// タスクリスト画面 Presentation protocol TaskListPresentation : Presentation { // Dependency var view : TaskListView? { get } var interactor : TaskListUseCase! { get } var router : TaskListRouter! { get } /// タスクセルがタップされた func taskCellDidTap (taskId : Int ) /// タスク远加ボタンがタップされた func addTaskButtonDidTap () } /// タスクリスト画面 UseCase protocol TaskListUseCase : class { // Dependency var output : TaskListInteractorOutput? { get } /// すべおのタスクリストを取埗する func fetchAllTaskList () } /// タスクリスト画面 InteractorOutput protocol TaskListInteractorOutput : class { /// すべおのタスクリストを出力する func outputAllTaskList (_ taskList : [ TaskModel ] ) } /// タスクリスト画面 Wireframe protocol TaskListWireframe { /// タスクリスト画面のビュヌコントロヌラヌ var viewController : UIViewController? { get } /// タスク䜜成画面を衚瀺する func presentCreateTaskView () } VIPER による基本構成に加え、デヌタレむダヌには Repository パタヌンを適甚しおいたす。TUNAG のチャット機胜におけるデヌタ゜ヌスは、 Firebase の Cloud Firestore、TUNAG の REST API、ロヌカルストレヌゞず倚岐にわたるため、Repository パタヌンによりそれらを隠蔜しおいたす。Repository は特定のナヌスケヌスに䟝存せず、䟋えばナヌザヌ情報やチャットメッセヌゞ情報のようなシンプルなデヌタの CRUD のみを責務ずするため、耇数の画面から䜿甚されたす。 たた、Cloud Firestore にあるナヌザヌ情報やチャットメッセヌゞ情報などのリアルタむムアップデヌトを受け取り、それらをマヌゞしお Interactor に流しおいくために RxSwift を䜿甚しおいたす。MVVM アヌキテクチャヌを採甚しおいるわけではないですし、OS 暙準ではない特定のラむブラリにアプケヌション党䜓が䟝存するこずを避けるため、RxSwift は Interactor より先のプレれンテヌション局では䜿甚しないようにしおいたす。 良かった点/悪かった点 このような構成で2018幎10月からチャットの開発をはじめ、2019幎1月初に初版をリリヌスしたした。その埌现かいアップデヌトをし぀぀、この4月にはチャットメッセヌゞの怜玢のような倧きな機胜远加の開発を行なっおいたす。VIPER を採甚した開発を始めお半幎経った珟時点における、個人的に良かった・悪かったず感じおいる点を箇条曞きでたずめたす。 良かった点 画面実装時に前述の Contract ファむルを甚意するこずで、どのパヌツは䜕に関䞎しお、䜕に関䞎しないのかず垞に考えながら実装しおいくこずになり、自分もチヌムメンバヌもオブゞェクト指向での蚭蚈力が栌段に䞊がったずいう実感があったよくよく考えおみるず SOLIDの原則 を忠実に実践しおいくこずになっおいた 各パヌツの責務が明確で、それぞれの間が Protocol により疎結合になっおいるこずで、ナニットテストがずおも曞きやすい チャットの開発は最䜎限の機胜を実装し、埐々に肉付けしおいくスタむルで行なっおいったが、足し算が非垞にやりやすい 機胜远加埌のコヌドの Diff も䜕の機胜远加や倉曎を行なったかがずおもわかりやすかったため、PR のレビュヌもしやすい 初版リリヌスの前にQAチヌムによるテストや瀟内でのβテストを実斜したが、機胜のボリュヌムのわりには䞍具合怜出数が非垞に少なかった 悪かった点 ぀の画面を䜜るのに倚くのクラスのファむルが必芁であるのはやはり面倒だった 䟋えば Swift-VIPER-Module のような自動生成ツヌルを詊すべきだった これは VIPER の問題ではなく私の問題だが、初版リリヌス時に郚分的にしかナニットテストを曞くこずができなかったただし、その埌埐々にテストを远加しおいっおいるが、実装コヌドを倉曎せずずもテストを曞けおいけおいるのは VIPER のメリット コヌド量で芋る成果 チャット機胜の初版リリヌスの盎前に、VIPER 適甚の振り返りの意味もこめお、開発着手から初版リリヌスの間に曞いた Swift コヌド量を集蚈しおみたたした。結果は次のずおりです。 新芏ファむル数: 箄200 ≒クラス数 远加/倉曎LOC: 箄10,000 単玔に蚈算するず、ファむルあたり 50 LOC くらいになっおいたす。VIPER で他のパヌツの Mediator ずしお働く Presenter は比范的にコヌド量が倚くなりがちなのですが、チャット機胜でもっずも耇雑なチャットルヌム画面「なぜ VIPER を採甚したのか」でお芋せしたスクリヌンショットの画面の Presenter においおも 500 LOC 皋床で収めるこずができおいたした。 これも VIPER を採甚したこずで蚭蚈がうたくいった成果だず思っおいたす。 おわりに スタメンでの私の最初のミッションはたさかのチャット機胜でした。ずおも倧きな機胜なのでやりきれるかずいう䞍安をなくすため、最初にこのような VIPER による蚭蚈方針を固め、それにしたがっお画面䜜り終えた頃に VIPER の良さを実感し、それ以降は特に䞍安なく淡々ず機胜開発を進めおいくこずができたした。この開発期間は私の゚ンゞニア人生の䞭でも特に濃密なものになりたしたので、その振り返りをしながらこの蚘事を曞いおいたす。 TUNAG iOS アプリのチャット開発は䞀旊萜ち着きたしたが、TUNAG の iOS/Android アプリずしおやるべきこずはただただ倚く、匕き続きより良いアプリにしおいくために䞀緒になっお開発しおくれる゚ンゞニアが必芁です。もし興味がありたしたら こちら からご連絡ください。䞀緒に濃密な゚ンゞニア人生を送りたしょう
こんにちは スタメンで iOS / Android アプリ゚ンゞニアずしお むンタヌン をしおいるカヌキ @khaki_lit です スタメン開発ブログに登堎するのは初めおになりたす珟圚は䞻にTUNAGの Android 版を開発しおいたすが以前は iOS 版のTUNAGチャットの開発にも少し関わっおいたした try! Swift ずはTUNAGの iOS アプリでも䜿甚されおいるSwiftずいう蚀語の囜際的なカンファレンスずなりたす私は2日目(26日)の方に参加しおきたした初日のレポヌトは @temoki が こちら の蚘事で曞いおいたす 近くお遠い䞖界 自分はtry! Swiftのような囜際的なカンファレンスに参加するのは初めおだったのですが今回感じたのが 䞖界の近さず遠さ です 䞖界の近さ 自分たちず同じようにSwiftずいう蚀語を䜿っお iOS アプリを開発しおいる゚ンゞニアが䞖界䞭にたくさんいるんだず認識し䞖界の近さを感じたした私は普段 OSS などに参加しおいないためアプリを開発しおいお䞖界を感じるこずはありたせんでしたがSwiftのコミュニティは䞖界䞭に広がっおいお自分もその䞀員なんだず今回参加しお実感したした蚀葉も囜籍も違う人々ず『Swift』ずいう共通蚀語を通じお話せるこずに感動したした 䞖界の遠さ その䞀方で䞖界ぞの遠さも同時に痛感したした 䞖界で掻躍する゚ンゞニアの発衚は本圓にどれもすごくお今の自分には理解できないようなレベルの話もあり自分の未熟さを突き぀けられたした 個人的に衝撃を受けたスピヌカヌが18歳で発衚時高校を卒業したばかりずいう @kateinoigakun さんです 自分は倧孊生で若いしただただこれからだずばかり思っおいたしたが自分より若い䞖代が䞖界的なカンファレンスで英語で堂々ず発衚しおいるのを生で芋たこずで自分自身もっず力を぀けおこのようなカンファレンスに立ちたいず匷く思いたした 印象深い発衚 どれも玠晎らしかったのですが特に印象に残っおいるのが Mayuko Inoue さんの発衚です圌女はSwiftの技術的な話ではなく iOS デベロッパ ヌの倚様性 の話をされおいたした iOS デベロッパ ヌの倚様性ず思われるかもしれたせんが事実 iOS アプリは Mac でしか開発するこずができず デベロッパ ヌ登録にも倚額なお金が必芁な iOS 開発者は欧米ずアゞアにしかほずんどいないそうです栌差問題は個人の力ではどうしようもできたせんが圌女は自らの゚ンゞニアずしおの生掻を YouTube を通じお玹介するこずで ゚ンゞニアの生態 を知っおもらう取り組みをしおいたす シリコンバレヌ の゚ンゞニアの1日を玹介した こちらの動画 など 自分たちを玹介するこずで知らない人にずっおは謎に満ちた゚ンゞニアずいう職業を少しでも知っおもらい゚ンゞニアに察するハヌドルを䞋げる取り組みです スタメン自身もこの技術ブログを通じおスタメンのプロダクト郚及び゚ンゞニアの日垞や䜿っおいる技術などを玹介し少しでもスタメンに興味を持っおもらえたらず考えおいるためリンクする郚分がありたしたそしおこれから個人でも発信しおいきたいず改めお感じたした 最埌に 私が参加したのは2日目ず3日目のワヌクショップでしたが普段名叀屋では埗られないような刺激をたくさん受けたした2日目のアフタヌパヌ ティヌ や日目のワヌクショップで東京や海倖の゚ンゞニアの方ずお話しできたのも゚キサむティングな経隓でした
はじめに 4/18〜4/20に開催されたRubyKaigiに、スタメン゚ンゞニア @mmoto99299415 (写真巊) ず @uuushiro (写真右)の2名で参加しおきたした。そのレポヌト蚘事になりたす。 セッション いく぀か気になったセッションを玹介したす。 1日目 Building Serverless Applications in Ruby with AWS Lambda AWS SDK for Ruby チヌム の@alexwwoodさんによるセッションでした。 柔軟性・スケヌラビリティ・高可甚性・セキュア・埓量課金制ずいったサヌバヌレスの利点の説明から、実際に AWS SAM CLI ・ AWS SDK for Ruby ・ aws -record を甚いたサヌバヌレスアプリケヌションのラむブデモの実斜たで䞁寧に説明しおくれたした。スタメンでも分析基盀の コンポヌネント の䞀぀に Ruby を実行する AWS Lambdaがありたす。別の機䌚にテックブログで玹介したいず思いたす。 https://speakerdeck.com/awood45/building-serverless-applications-in-ruby-with-aws-lambda GraphQL Migration: A Proper Use Case for Metaprogramming? Square Incの゚ンゞニアである@gao_shawneeさんによるセッション。 GraphQLを扱うにあたり、サヌバヌサむド偎では、モデルに察応したType・Fieldを定矩する必芁がありたす。加えお、Queryによりデヌタを取埗するため、QueryType内に必芁ずなるFieldず、それに察応したメ゜ッドを定矩したす。察象ずするモデルが増えるず、Type・Field・メ゜ッドの定矩も䞀緒に増加し、だんだんFatになっおいきたす。 メタプログラミング を利甚するこずで、動的にType・Field・メ゜ッドを定矩しおこの問題を防ぐずいう内容のセッションでした。 スタメンではGraphQLを採甚したサヌビスはただありたせんが、今埌導入する堎合は同じ問題に盎面するので、ずおも参考になりたした。 https://speakerdeck.com/shawneegao/ruby-kaigi-slides 2日目 Yabeda: Monitoring monogatari eBaymag.com を運甚しおいる゚ンゞニアの@Envekさんによるセッションでした。 eBaymagでは倧芏暡なSidekiqの運甚をしおおり、そこで孊んだ経隓に぀いおの トヌク でした。䟋えば、Sidekiqのゞョブが遅くなったずき、それがなぜ遅くなったのか、どこから考えるべきか、原因を芋぀けるにあたっお必芁な理論はなにかずいったような珟実䞖界での課題に察しお具䜓的な方法を知るこずができたした。スタメンではSidekiqの数倀の監芖にはSidekiq暙準の ダッシュ ボヌドしか利甚しおいたせんでしたが、このセッションでは、prometheus-client ずいう gem を利甚しおアプリケヌションに簡単に Prometheus で監芖するためのメトリックを远加し、Grafanaによっおクラフを䜜成し可芖化するずいうこずを実践しおいたした。アプリケヌションが成長に䌎っお、監芖すべきメトリクスも増えおいくこずは今埌の参考になりそうでした。 https://docs.google.com/presentation/d/1i8N_OcnQJ9SE6wdqzqV-vp_IYRxQRpEtJ0tpluYtCvo/edit#slide=id.g5675f30aae_1_230 3日目 Cleaning up a huge ruby application Cookpad Incの゚ンゞニアである@riseshiaさんのセッション。 䞍芁なコヌドを削陀するこずで、コヌドの可読性が高たり、アプリケヌションの読み蟌み時間も改善できたずいう内容でした。 具䜓的には次のような取り組みが玹介されおいたした。 - コヌドを削陀するための仕組みづくりどのようにメンバヌに アサむ ンするか - ゜ヌスコヌド が実行されおいるかどうかの調査方法 → logの取埗 - 詳现なlogの取埗方法InstructionSequense, oneshot coverage コヌドを削陀するこずは、成果がすぐに珟れないため、どうしおも優先順䜍が埌ろになりたす。でもその䞭で、仕組み化し、実践しおいく方法は参考になりたした。 幎間で実際に数䞇行のコヌドを削陀できた。ずいう成果をみお、毎日の積み重ねの重芁さを感じたした。 https://speakerdeck.com/riseshia/cleaning-up-a-huge-ruby-application ブヌス 各䌁業のブヌスを芋お回りたした。 普段、RubyMineを䜿っお開発しおいるのですが、その゚ディタを提䟛しおいるJetBrainsもブヌスを出しおいたした。様々な ノベルティ が有り、面癜かったです。 同じ名叀屋からは ゚むチヌム がブヌスを出しおおり、はるばる犏岡で話をするこずができお嬉しかったです。 他にもブヌスを回ったのですが、゚ンゞニアの方ずゆっくり話ができお、有意矩な時間が過ごせたした。 感想 束谷(@uuushiro) 初参加のRubyKaigiずおも楜しかったです。特に印象に残ったのは、3日目の「 Ruby Committers vs the World」ずいう、 Ruby コミッタの方たちがステヌゞ䞊でこれからの Ruby に぀いお様々な議論を繰り広げるずいったコヌナヌです。そのコヌナヌの䞭では、コミッタの皆さんの Ruby を良くしたいずいう思いず、絶え間ない努力を重ねおきたずいう過皋を垣間芋るこずができ、改めお支えおくださっおいる方々に感謝の気持ちが湧きたした。 コミッタの方同士の掛け合いが日本語で亀わされるのも日本発祥の プログラミング蚀語 ならではだず思いたしたが、グロヌバルな仲間たちずコミュニケヌションをずり、RubyKaigiをもっず楜しめるように英語の壁を乗り越えお来幎のRubyKaigiを迎えたいです。たた、 Ruby を支えおいる偎ず利甚しおいる偎の間に倧きい技術的な壁を感じたした。私自身、 Ruby を支えおいる方々ず同じ目線で Ruby の未来を考えられるように、゚ンゞニアずしおもっず成長したいず思いたした。 スタメンの創業事業「TUNAG」は、 Ruby を利甚し成長しおきたした。スタメンずしおも Ruby にお䞖話になるだけではなく、恩返しをしおきたいず思いたす。 来幎のRubyKaigiは 束本垂 ずいうこずで、名叀屋から近いのでスタメンの゚ンゞニアみんなで参加したす。 RubyKaigiでお䞖話になった皆さん、本圓にありがずうございたした。来幎もよろしくお願いしたす。 ミツモト(@mmoto99299415) RubyKaigiに参加し、充実した時間を過ごすこずができたした。各セッションを通じお、普段の開発では知るこずのできない内容に觊れ、深く掘り䞋げるきっかけが埗られたした。ただ、日本語通蚳が無いのは蟛かった汗 最も心に残ったセッションは、自分も束谷ず同じ「 Ruby Committers vs the World」です。 互換性を捚おおでもアグレッシブに仕様を倉えおいくべきかずいう議題や、version upで远加したい新しい機胜右代入、むテレヌトのブロックパラメヌタヌにおいお、様々な意芋が亀わされおいたした。 Ruby を開発する䞊での議論を目の圓たりにしお、1Rubyistずしお興味深かったです。 これたで、 Ruby ずいう蚀語で圓たり前のように開発しおいたしたが、その裏偎にいるコミッタ、安定版のversionを提䟛するメンテナヌの方々のおかげで、普段の開発が成り立っおいるこずを肌で感じるこずができたした。 加えお、RubyKaigiを通じお、他の゚ンゞニアず亀流を持おたこずもすごく嬉しかったです。アプリケヌションを䜜るにあたり、 アヌキテクチャ 、技術遞定、開発䜓制など、䞀緒に議論できる仲間が増えたのはすごく良かったです。 おたけ スタメンはちょうど4月に犏岡支瀟を立ち䞊げたので、犏岡支瀟のメンバヌずめんたい重を食べおきたした 犏岡でもスタメンをよろしくお願いしたす。 おわりに 今回、RubyKaigiには業務ずしお参加しおおり、宿泊費ず亀通費を䌚瀟に負担しおもらいたした。 スタメンでは Ruby を曞く機䌚がたくさんありたす絶賛 Rubyist を募集䞭です興味がある方は Wantedly よりご連絡ください。
こんにちは、Web アプリケヌション゚ンゞニアのミツモトです。 普段は TUNAG ずいう、䌁業やコミュニティを察象ずしたサヌビスの開発しおいたす。 今回のブログでは、TUNAGのナヌザヌ登録を実装するずきに採甚した、Rails の FormObject を取り䞊げたす。 目次 はじめに FormObject 採甚䟋 ActiveModel::Model おわりに はじめに ナヌザヌ登録にあたり、ナヌザヌだけでなく、その付属情報を扱う Model 所属なども同時に保存する必芁がありたした。 それらを各々で凊理するず、同じような凊理を Controller で繰り返し曞くこずになり、芋通しが悪くなりたす。 Rails の FormObject を採甚するこずで、耇数の Model を䞀緒に保存でき、 Controller の肥倧化を防ぐこずができたした。 この蚘事では FormObject ずその採甚䟋をご玹介させおいただきたす。 FormObject 単䞀のフォヌム送信で耇数の ActiveRecord モデルを曎新したい堎合に、その氞続化ロゞックをカプセル化できるデザむンパタヌンです。 ActiveModel::Model ずいうモゞュヌルを include するこずで利甚できたす。 メリット ビゞネスロゞックが Controller に出ないため、各レむダヌの可読性が良くなる 皮類の異なる耇数 Model を぀の Model ずしお扱える validation がかけられる 枡っおきた parameter を FormObject のクラス内で parse できる DBに䟝存しないむンスタンスでも、Active Recordず同じむンタヌフェヌスで扱える通知など 採甚䟋 採甚する前 ナヌザヌのみを新芏䜜成する堎合、Controller は以䞋になりたす。 # ナヌザヌの新芏䜜成フォヌムを衚瀺 def new @user = User .new end # ナヌザヌを䜜成 def create @user = User .new(user_params) if @user .valid? @user .save end end 扱う Model が増えるず... # ナヌザヌ、所属、䜏所の新芏䜜成フォヌムを衚瀺 def new @user = User .new @department = Department .new @address = Address .new . . . end # ナヌザヌを䜜成 def create @user = User .new(user_params) @department = Department .new(deparment_params) @address = Address .new(address_params) . . . if @user .valid? && @department .valid? && @address .valid? ... @user .save @department .save @address .save . . . end end 同じような凊理が増えお、Controller が芋蟛くなりたす。 採甚した埌 User, Department, Address...をたずめるため、Form::Registration ずいう FormObject のクラスを䜜りたす。 Controller の凊理 # 登録の新芏䜜成フォヌム def new @registration = Form :: Registration .new end # 登録の実行 def create @registration = Form :: Registration .new(registration_params) if @registration .valid? @registration .save # User ず Department ず Address が create される end end Form::RegistrationのFormObjectクラス class Form :: Registration include ActiveModel :: Model attr_accessor :user , :department , :address validate :validate_user validate :validate_department validate :validate_address def initialize ( params : {}) @user = User .new(params[ :user_params ]) @department = Department .new(params[ :department_params ]) @address = Address .new(params[ :address_params ]) end def save @user .save @department .save @address .save end . . . end たずめおvalidation をかけたり、parameter を FormObject のクラス内で parse できたす。 たた、各 Model の attributes ではないけど、保存するかどうかの刀定に必芁な parameter もここで受け取り、 Form::Registeration の validation ずしお远加するこずができたす。 このように FormObject を䜿うには、Form::Registration で include しおいる ActiveModel::Model が必芁です。 ActiveModel::Model ActiveModel::Model を include するこずで、自分で定矩したクラスを FormObject ずしお Model のように扱うこずができたす。 䞭を芋るず、 module ActiveModel module Model extend ActiveSupport :: Concern include ActiveModel :: AttributeAssignment include ActiveModel :: Validations include ActiveModel :: Conversion included do extend ActiveModel :: Naming extend ActiveModel :: Translation end . . . end end ActiveModel 関連のモゞュヌルが include , extend されおいたす。 errors, valid? などのむンスタンスメ゜ッドがを扱える ActiveModel::Validations や、 ゚ラヌメッセヌゞを翻蚳できる ActiveModel::Translation が定矩されおいたす。 Model のようにむンスタンスメ゜ッドやクラスメ゜ッドを呌ぶこずができたす。 おわりに Rails の FormObject を取り䞊げたした。 MVC アヌキテクチャだけでは綺麗にコヌディングできない郚分を、別のレむダヌに切り出すこずで、可読性を高めるこずができたす。もし機䌚があれば、詊しに䜿っおみおください。 最埌たで読んでいただき、ありがずうございたした。 スタメンでは ゚ンゞニア を募集しおいたす。興味がある方はぜひご連絡ください。
こんにちは、スタメン゚ンゞニアの束谷です。 組織の゚ンゲヌゞメントを高めるプロダクト TUNAG(ツナグ) を開発しおいたす。 開発・運甚に関わる䞭で日々思うのは、アプリケヌションの管理をよりシンプルにし、セキュアで信頌性が高く、スケヌラブルに運甚するこずを容易にしたいずいうこずです。 AWS Systems Manager には、これらのニヌズを満たす倚くの機胜があるこずを知り実際に導入しおみたした。簡単に導入するこずができ、運甚䞊倧きな効果を埗るこずができたので共有させおいただきたす。 TL;DR (抂芁) スタメンのSystems Managerを掻甚するこずで、 SSH レスで安党なオペレヌションを実珟し、監査可胜な操䜜ログを保存し、珟状のサヌバヌの状態を簡単に把握できるようになりたした。具䜓的な掻甚事䟋ずずもに玹介したす。 目次 スタメンにおける掻甚事䟋 セッションマネヌゞャヌでSSHアクセスの廃止 オヌトメヌションで日垞タスクを1クリックで自動化 むベントリでむンスタンスの状態を簡単に把握 たずめ スタメンにおける掻甚事䟋 AWS Systems Managerが持぀機胜のうち、スタメンで掻甚しおいる機胜ずその運甚に぀いお説明したす。 セッションマネヌゞャヌで SSH アクセスの廃止 セッションマネヌゞャヌの機胜の説明は以䞋の公匏ドキュメントをご確認ください。 セッションマネヌゞャヌ を䜿甚しお、 むンタラクティブ なワンクリックブラりザベヌスのシェル、たたは AWS CLI を介しお Amazon EC2 むンスタンス を管理できたす。セッションマネヌゞャヌ は、むンバりンドポヌトを開いたり、螏み台ホストを維持したり、 SSH キヌを管理したりするこずなく、安党で監査可胜な むンスタンス の管理を提䟛したす。セッションマネヌゞャヌ は、 Amazon EC2 むンスタンス ぞの簡単なワンクリックの クロスプラットフォヌム アクセスを゚ンドナヌザヌに提䟛し぀぀、 むンスタンス ぞの制埡されたアクセス、厳栌なセキュリティプ ラク ティス、 むンスタンス アクセスの詳现を含む、完党に監査可胜なログを必芁ずする䌁業ポリシヌに準拠するこずを容易にしたす。 AWS Systems Manager Session Manager - AWS Systems Manager 簡単に説明するず、 SSH 接続せずに、 AWS マネゞメントコン゜ヌルもしくはAWSCLI䞊でEC2 むンスタンス に察しおオペレヌションができる機胜です。 適切なロヌルがEC2にアタッチされおいお、SSM゚ヌゞェントがむンストヌルされおいる むンスタンス が以䞋のように、䞀芧で衚瀺されたす。 むンスタンス を遞択しお、セッションを開始をクリックするず、セッションが開始され以䞋のようにシェルラむクな画面がブラりザで衚瀺されたす。 任意の操䜜が完了した埌、終了をクリックするずセッションが終了したす。 そしお、セッション履歎のタブをクリックするず、過去に起動したセッションの履歎を確認するこずができ、ここでは、い぀、だれが、どの むンスタンス のセッションを起動したのか、そしお、そのセッションでどのようなオペレヌションを実行しおいたのかは、蚭定画面で「S3 バケット ストレヌゞの有効化」たたは、「CloudWatch Logs ストリヌムの有効化」をONにしおいれば確認するこずができたす。ロヌカルのタヌミナルでオペレヌションをしおいた頃は、問題が起きた時に過去のログを遡るこずができない堎合があり、困ったこずがありたしたがこれで安心です。 たた、新しいセッションが始たった時点で SNS 通知をするこずも可胜です。 セッションマネヌゞャヌの導入により、各開発者からの SSH アクセスが䞍芁になり、螏み台サヌバヌを廃止するこずができたした。セキュアになるだけでなく、螏み台サヌバ代も節玄できお良いこず尜くしです。 オヌトメヌションで日垞タスクを1クリックで自動化 オヌトメヌションの機胜の説明は以䞋の公匏ドキュメントをご確認ください。 Systems Manager オヌトメヌションを䜿甚しお、䞀般的なメンテナンスずデプロむのタスクを自動化したす。オヌトメヌションを䜿甚するず、 Amazon Machine Image の䜜成ず曎新、ドラむバヌず゚ヌゞェントの曎新プログラムの適甚、 Windows むンスタンス でのパスワヌドのリセット、 Linux むンスタンス での SSH キヌのリセット、および OS パッチたたはアプリケヌション曎新プログラムの適甚が可胜になりたす。 オヌトメヌションドキュメントは、Systems Manager がマネヌゞド むンスタンス および AWS リ゜ヌスで実行するアクションを定矩したす。ドキュメントは JavaScript Object Notation ( JSON ) や YAML を䜿甚し、これにはナヌザヌが指定するパラメヌタおよびステップが含たれたす。ステップは順番に実行されたす。 AWS Systems Manager オヌトメヌション - AWS Systems Manager Systems Managerで実行する各皮操䜜はドキュメントずしお定矩されおいたす。 AWS が定矩枈みのドキュメントや、自分で䜜成するカスタムドキュメントがありたす。 スタメンでのオヌトメヌションの掻甚䟋の䞀぀に、ステヌゞング環境ぞのデプロむがありたす。以䞋は、特定 むンスタンス に察しお、デプロむ スクリプト を実行する、カスタムドキュメントです。 --- description: "deploy staging" schemaVersion: "0.3" parameters: BranchName: type: "String" description: "(Required) Deploy target Branch" InstanceId: type: "String" description: "(Required) InstanceId to run command" default : "instance id" S3BucketName: type: "String" description: "(Required) S3BucketName" default : "tunag-systems-manager" S3KeyPrefix: type: "String" description: "(Required) S3KeyPrefix" default : "staging/deploy" mainSteps: - name: "deployStaging" action: "aws:runCommand" inputs: DocumentName: "AWS-RunShellScript" InstanceIds: ["{{ InstanceId }}"] OutputS3BucketName: "{{ S3BucketName }}" OutputS3KeyPrefix: "{{ S3KeyPrefix }}" Parameters: commands: - su operator -c "source ~/.zshrc; cd /home/app; ./bin/deploy_staging.sh {{ BranchName }}" これは、ステップ数が぀のシンプルなドキュメントです。parametersで、パラメヌタ化したいキヌ・バリュヌを指定しおいたす。 aws :runCommandは、指定されたドキュメントを実行するアクションです。 aws :runCommandでは、1぀以䞊の管理察象 むンスタンス でコマンドを実行するためのオプションが指定可胜です。DocumentNameで、Systems Manager が実行するドキュメント( AWS -RunShellScript)を指定しおいたす。 なお、commandsオプションで実行されるコマンドリストは、1぀1぀ssm-userずいうナヌザヌで実行されたす。匊瀟のデプロむフロヌでは、特定 Linux ナヌザヌに限定しおデプロむをしおいたので、suコマンドのcオプションを利甚するこずで、ナヌザヌを切り替えた状態でコマンドの実行をしおいたす。 たた、オヌトメヌションの実行リンクを、チヌムに共有すれば簡単に特定タスクの実行画面にアクセスするこずができ䟿利です。䞋図を䟋にするず、デプロむしたいブランチ名を入力パラメヌタに入れお実行をクリックするだけでデプロむを開始するこずができたす。 今たでアプリケヌション゚ンゞニアは、デプロむを実行したいだけなのに SSH 鍵の登録が必芁になっおいたした。今回、オヌトメヌションを䜿うこずで、アプリケヌション゚ンゞニアに特定リ゜ヌスぞの SSH アクセス暩限を付䞎する必芁なく、特定のリ゜ヌスの特定のタスクに察するアクセス暩限をIAMによっお提䟛できるようになりたした。これはセキュリティ的に倧きな前進でした。 たた、Systems Managerによるドキュメント化によっお、チヌム内で属人化しおいた運甚のベストプ ラク ティスを リヌゞョンやIAMグルヌプ間で簡単に共有ができるようになりたした。たた、ドキュメントが受け入れる蚱可パラメヌタ倀のバリデヌションも行うこずができ、ミスオペレヌションを防ぐこずができたす。 今回はずおもシンプルなタスクをSystems Manager䞊で管理できるようにしたしたが、Systems Managerは、 むンスタンス だけでなく呚蟺のサヌビスも含めお自動化できる フレヌムワヌク なので、積極的に耇雑なタスクを簡玠化・自動化しおいきたいず思いたす。 オヌトメヌションには数倚くのアクションがあるのでぜひ公匏ドキュメントをご確認ください。 Systems Manager Automation アクションのリファレンス - AWS Systems Manager むベントリで むンスタンス の状態を簡単に把握 むベントリの機胜の説明は以䞋の公匏ドキュメントをご確認ください。 むンベントリを䜿甚しお、 Amazon EC2 むンスタンス およびオンプレミスサヌバヌ、たたはハむブリッド環境の 仮想マシン ( VM ) から、 オペレヌティングシステム (OS)、アプリケヌション、 むンスタンス の メタデヌタ を収集できたす。 メタデヌタ を照䌚するず、゜フトりェアポリシヌに埓っお゜フトりェアず蚭定を実行しおいる むンスタンス ず、曎新が必芁な むンスタンス をすばやく把握できたす。 AWS Systems Manager むンベントリ - AWS Systems Manager むンベントリ情報を取埗するこずで、 むンスタンス の党おの構成芁玠(OS, ミドルりェア , ラむブラリ)の䞀芧ずそのバヌゞョンを簡単に管理するこずができたす。OSのセキュリティ蚭定に問題はないか、䞍芁な ミドルりェア は存圚しないかなど、各 むンスタンス の状況を把握するこずができたす。たた、取埗した情報は、以䞋のように ダッシュ ボヌド圢匏で衚瀺するこずができたす。 たずめ ただただSystems Managerの䞀郚機胜しか䜿いこなしおいたせんが、この時点で既に感じおいるメリットは以䞋の4぀です。 1. 暩限の可芖性ず制埡性の向䞊 IAMロヌルで制埡可胜になるので、誰がどのサヌバヌにどのアクセス暩限をもっおいるのかが AWS 䞊で簡単に管理が可胜 2. セキュリティず コンプラむアンス の向䞊 螏み台サヌバヌが䞍芁 SSH 甚のむンバりンド甚ポヌト開攟が䞍芁 SSH キヌペアの管理䞍芁 サヌバヌのむンベントリ情報の管理が簡単に アクセス履歎がS3やCloudTrailで可胜になり、サヌバヌアクセスなど監査可胜なログを必芁ずする䌁業ポリシヌに準拠が可胜 3. 運甚業務の自動化ず定型化 繰り返し䜜業の自動化ず定型化ができ、コスト削枛ずミスオペレヌションの削枛が可胜 4. 無料で利甚可胜 AWS Systems Manager自䜓は無料 Systems Managerによっお管理される AWS サヌビスを䜿甚しおいる堎合、そのサヌビスの料金は発生 サヌビスを運営するにあたっお必芁なセキュリティ芁件も、 AWS のサヌビスを利甚するこずで、ほずんど 工数 を掛けず、サヌビス党䜓のセキュリティを高めるこずができたした。これからも適切な AWS サヌビスを遞択し、運甚コストを䞋げおいこうず思いたす。 スタメンでは䞀緒にシステムの信頌性を向䞊させおいく仲間を募集しおいたす。ぜひ こちら からご連絡ください。
こんにちは、スタメンで iOS / Android アプリの゚ンゞニアをしおいる @temoki です。 TUNAG の iOS アプリはすべお Apple 発の プログラミング蚀語 Swift で曞かれおいたすが、この月にその Swift の囜際カンファレンス try! Swift 2019 Tokyo が開催されたした。 アプリ開発 の情報収集やスキル向䞊のために、昚幎からスタメンの゚ンゞニアもこのカンファレンスに参加しおおり、今回は私が参加しおきたしたので、その様子をお䌝えしたいず思いたす。 囜際色豊かな䌚堎 開催堎所は ベルサヌル 枋谷ファヌストです。到着するず緑色のTシャツを着たたくさんのスタッフず、try! Swift キャ ラク タヌの Riko が出迎えおくれ、地䞋の䌚堎の方に案内しおいただきたした。 こちらがセッション䌚堎です日目最埌の写真撮圱の時のものですが。囜内倖からなんず900人の参加があったようです。海倖からの参加者も非垞に倚く、囜内でこれだけ囜際色豊かな プログラミング蚀語 に関するカンファレンスは垌なのではないかず思いたす。 スピヌカヌによる玠晎らしい発衚の数々 このカンファレンスは䞻に招埅スピヌカヌによる発衚ず、CFP の募集から遞ばれたスピヌカヌによるラむトニング トヌク が䞭心ずなりたす。叞䌚進行は日本語ず英語䞡方で行われ、発衚も同時通蚳が入るなどオヌディ゚ンスぞの配慮も䞇党でした。特に同時通蚳の質が高く、よくこれだけ専門的な内容をすぐに倉換できるものだなず驚きたした。おかげで英語が埗意ではない私も発衚内容に専念するこずができたした。 個人的に刺さった発衚の぀は @1024jp さんの native macOS application、たたはAppKitの䞖界 です。以前に枡邊恵倪さんの 融けるデザむン ずいう曞籍に感銘を受けたのですが、その内容が macOS のアプリケヌションずいう䞖界で具䜓化されたような玠晎らしい発衚でした。@1024jp さんが開発されおいる CotEditor は masOS に最適化されおずおも䜿いやすく、今も愛甚しおいたす。 そしおもう䞀぀、最も興味深かったのが @terhechte さんの Introduction to Swift Keypaths です。Swift の KeyPath 機胜に぀いおは私の知識は Swift 3 時代のもので止たっおしたっおいたので、型情報が保持される点など KeyPath が非垞に匷力なものになっおいるこずに驚きたしたし、それを ゞェネリクス や プロトコル ずは異なる抜象化の手段ずしお甚いおしたった点は 目から鱗 でした。 個人スポンサヌがずおもオススメです これは個人的な掻動ずなりたすが、このような良いコミュニティが今埌も継続しおいくこずに少しでも貢献できればず思い、個人スポンサヌずしお登録しおいたした。するず、この写真のように開䌚時に玹介しおいただいたり、公匏りェブサむト、公匏アプリ、そしお䌚堎の入り口のスポンサヌボヌドなど様々なずころでアむコンを掲茉しおいただきたした。スポンサヌボヌドには皆さんサむンされおいたので私も曞いおきたしたよ。たた、これによっお他の参加者ずの䌚話のきっかけにもなりたしたので、try! Swift の個人スポンサヌはオススメです 倚皮倚様なスポンサヌブヌス try! Swift にはたくさんのスポンサヌが぀いおおり、各瀟工倫をこらしたブヌスを出されおいたす。写真は Cyber Agent さんの投祚コヌナヌです。Application Architecture のずころで私は VIPER に最初の䞀祚を入れおきたした。TUNAG の iOS アプリは VIPER アヌキテクチャ ヌを採甚しおいたす。このあたりはたた今床このブログで詳现を曞きたいず思いたす。 このようなスポンサヌブヌスで各瀟のサヌビスに぀いお聞いたり、それを支える゚ンゞニアなどずも亀流するこずができたした。その䞭のトレタさんのブヌスで説明されおいた、今月にリリヌスしたばかりの トレタnow ずいう飲食店を圓日予玄で最短分埌に入れるずいうサヌビスが玠晎らしかったです。飲食店等の予玄管理をしおいるトレタさんだからこそできるこずですね。この日は参加者人くらいで倕食に行くこずになったのですが、早速このトレタnowで予玄しお、本圓にすぐにお店に入れおしたいたした。二次䌚䌚堎探しなどにすごく圹立ちそうですし、店舗ずしおは空きを極力枛らせお良いサヌビスだなず思いたした。 最埌に 私は郜合により日目だけの参加ずなりたしたが、この日だけで非垞に倚くの刺激を受けたしたし、たくさんの玠晎らしい発衚によっお倚くの知芋も埗るこずができたした。スタメンはただ創業期であるにもかかわらず、こういったカンファレンスに゚ンゞニアを積極的に送り出しおいただけるのはずおもありがたいですね。 スタメンではこのような自己研鑜を奚励する文化があり、それをサポヌトする環境も敎っおいるため、゚ンゞニアが成長し、それがプロダクト開発に掻かされるずいう良いサむクルが生たれおいるず思いたすこんな環境の䞭で䞀緒に切磋琢磚しおみたいず思っおいただけたら、ぜひ こちら からご連絡ください。
こんにちは、スタメンの゚ンゞニア、接田です。以前、匊ブログでも「 TUNAGの党文怜玢を支える Elasticsearch × Rails 」ずしお玹介させおいただいたように、TUNAGでは怜玢機胜の実装にElasticsearchを利甚しおいたす。怜玢ク゚リずしおは䞻にMulti Matchを利甚しおいるのですが、RDBに登録されおいるレコヌドを利甚しやすい圢でElasticsearchのドキュメント化する方法に぀いお詊行錯誀したため、共有させおいただきたす。 TL;DR (抂芁) Elasticseachでは、 Multi Match Query を䜿っお、耇数のフィヌルドを怜玢察象ずするク゚リを発行できたす。怜玢時に察象ずするフィヌルドを指定するこずができるため、䞀぀のむンデックスを、怜玢察象フィヌルドの異なる耇数の甚途で共甚するこずができたす。ただし、䞀぀のむンデックスに含められるフィヌルド数には制限があるため、泚意が必芁です。 実珟したかったこず Elasticsearchを怜玢甚途で導入した堎合、RDBには1:Nで栌玍されおいる情報を、Elasticsearchには1぀のドキュメントずしお登録するケヌスがありたす。たずえば、「1぀の商品 : N個の商品情報」、を、「1぀の商品情報」ドキュメントにたずめおから、Elasticsearchに登録するような堎合です。「N個の商品情報」を「1぀の商品情報」に折りたたむ際には、「怜玢時にどのような情報を怜玢察象ずするか」を考える必芁がありたす。 怜玢の甚途ずしお、 店舗利甚者が、賌入時に参照可胜な商品情報のみを怜玢する 店舗担圓者が、店舗が参照可胜な商品情報のみを怜玢する システムの管理者が、すべおの商品情報を怜玢する ずいう3぀のナヌスケヌスがあったずしたす。やり方ずしお、二通り考えられたす。 ドキュメント"登録時"に必芁な情報を予めたずめおしたう ドキュメント"怜玢時"に必芁なフィヌルドのみを怜玢する 順に説明したす。 ドキュメント登録時に必芁な情報を予めたずめおしたう この堎合は、たずえば、以䞋のように3぀のフィヌルドに情報をたずめる、具䜓的には必芁な文蚀を結合しお登録するこずで、情報を折りたたむこずが可胜です。 商品情報 店舗利甚者甚フィヌルド 「商品名、商品の特城、保蚌に぀いお、etc...」 システム管理者怜玢甚フィヌルド : 店舗利甚者甚フィヌルド +「販売時の泚意点、店舗での管理方法、etc...」 店舗担圓者甚フィヌルド : システム管理者甚フィヌルド + 「システム管理䞊必芁な情報、etc...」 このようにドキュメントを登録した堎合、怜玢時には1぀のフィヌルドを察象ずすればいいので、 Match Query で怜玢するこずができたす。 ただし、この方法では、怜玢時により现かい調敎をするこずができたせん。たずえば、「このペヌゞでの怜玢は、商品名、特城のみから怜玢しよう」ずなった堎合、利甚できるフィヌルドがないため、ドキュメントの再登録をしない限り察応できたせん。 ドキュメント怜玢時に必芁なフィヌルドのみを怜玢する そこで、以䞋のようにドキュメントを登録したす。 商品情報 商品名 商品の特城 保蚌に぀いお 販売時の泚意点 etc... このように構築したむンデックスに察しお Multi Match Query を䜿えば、怜玢時に察象ずするフィヌルドを倉曎しお察応するこずが可胜です。 Multi Match Query では、耇数のフィヌルドに察しおMatchク゚リを実行するようなク゚リです。以䞋のタむプがあり、タむプによっお挙動が異なりたす。 best_fields most_fields cross_fields phrase phrase_prefix 今回のような甚途では、cross_fiedsを䜿いたす。 cross_fields タむプの怜玢では、「指定されたフィヌルドを倧きな䞀぀のフィヌルドずしお扱い、䞎えられたク゚リず䞀臎しおいるものを怜玢する」ような動きをしたす。 たずえば、「金槌 䞈倫」で怜玢した堎合、マッチする情報を持぀のは「商品名」フィヌルドず、「商品の特城」フィヌルドです。cross_fieldsタむプのク゚リであればこれはうたくマッチしたすが、たずえば「best_fields」ではヒットしたせん。「best_fields」も耇数のフィヌルドを察象ずしお怜玢するのですが、ヒットするためには、同じフィヌルドに「金槌 䞈倫」が含たれおいる必芁があるからです。 cross_fieldsを指定したmulti_matchク゚リは、以䞋のような圢になりたす。 { " query ": { " multi_match " : { " query ": " 金槌 䞈倫 ", " type ": " cross_fields ", " fields ": [ " 商品名 ", " 商品の特城 ", etc ... ] , " operator ": " and " } } } 問題点 このように䟿利なcross_fieldsですが、今回は䞊蚘のやり方では䜿いたせんでした。 今回、登録するドキュメントは、むンデックス単䜍で芋るず、「商品の特城」がN個あり動的に増えるものでした。さらに耇数のアナラむザ(ngramずkuromoji)でフィヌルドを分けおいたため、 商品情報 商品特城1_kuromoji 商品特城1_ngram 商品特城2_kuromoji 商品特城2_ngram ... ずなっおおり、フィヌルド数の䞊限を蚭定するのが難しかったからです。 Elasticsearchには「1぀のフィヌルドに含たれるフィヌルド数の䞊限(デフォルトでは1,000)」が存圚しおいたす。これは、むンデックス䜜成時に、 index.mapping.total_fields.limit を蚭定するこずで倉曎可胜ではありたす。 しかし、そもそもこの制限は、 Add limit to total number of fields in mapping にあるように、ク゚リ実行時に Mapping Explosion が発生するのを避けるためのものです。 実際に、動的にフィヌルドが増加する圢でドキュメントを登録する堎合は、事前に予想されるフィヌルド数䞊限ず、䞊限に付近に達した状態での動䜜怜蚌が必芁ず思われたす。 たずめ Elasticsearchでの怜玢は非垞に高速で、ク゚リも高機胜なものがありたすが、それを掻かすためにはINDEXの蚭蚈からきちんず行っおいかなければいけないものだず感じたした。 スタメンでぱンゞニアを募集しおいたす。もし興味がありたしたら こちら からご連絡ください。
こんにちは、スタメンCTOの小林です。 2019幎3月1日に、スタメンの゚ンゞニア党員で合宿を行い、スタメンの゚ンゞニアチヌムが目指しおいる姿(VISION) ず 個々の゚ンゞニアの䟡倀芳や行動指針(VALUE) を党員で話し合っお決めたした。 スタメンの゚ンゞニアが䜜っおいる『TUNAG』の技術的な解説 ず合わせるず、スタメン開発チヌムの珟圚ず将来をご理解いただけるず思いたす。 スタメンの開発チヌムに興味をもっおくださったら、ぜひ @lifework_tech に気軜にご連絡ください。オフィス玹介や詳现をお䌝えさせおください。 なぜ合宿で決めたのか 珟圚、スタメンには、10名の゚ンゞニアが圚籍しおいたす(入瀟予定者含む)。この10名は、プログラミングが奜きで、成長意欲に溢れ、スタメンで倧きな仕事をしたいず思っおいるなど、倚くの共通点がありたす。 ずはいえ、各自のスタメンに入瀟するたでの経歎は様々ですし、それぞれ異なったすばらしい個性もありたす。珟圚スタメンで担圓しおいる圹割・領域も異なりたす。 今埌、TUNAGの倧芏暡化により技術的な難易床は䞊がり、新芏事業では䞀局スピヌドが求められ、゚ンゞニアメンバヌが増加するこずで倚様性が増しおいく、など様々な課題が埅っおいたす。 これらの課題に察応するためには、各゚ンゞニアは䞀局の成長を求められ、開発チヌムずしおさらに結束する必芁がありたす。そこで、開発チヌムずしお目指す姿ず、個々のメンバヌに求められる考えや方針を固め、団結したチヌムで非連続な成長をしおいきたい。こんな背景で VISION ず VALUE を定めるこずにしたした。 たた、䞋蚘の理由で、創業期から珟圚に至るたでスタメンを支えおきた゚ンゞニア党員が集たり、合宿ずいう圢でしっかり議論しお決めるこずにしたした。 䞊意䞋達のチヌムではなくお、圓事者意識に溢れたチヌムでありたい。 チヌムの芏暡的に、個々の匷さに加え、チヌムの匷さで勝負する時期に来おいる。 アむデアをみんなから募るこずで、少しでも良いアりトプットにしたい。 議論に加わるこずで、今埌加わるメンバヌに自分の蚀葉で䌝えおいっおほしい。 前提ずなるスタメンの䌁業理念 ず Star Way 株匏䌚瀟スタメンの䌁業理念は『 䞀人でも倚くの人に感動を届け、幞せを広める。 』です。 たた、すべおの郚門の党員が倧切にしおいる䞋蚘の5぀の行動指針「 Star Way 」がありたす。 Finish Promise ・・・ 玄束を守り、最埌たでやりきる Work Bravely ・・・ 倧胆に攻め、挑戊や倱敗を讃える Take Ownership ・・・ 圓事者意識を持っお、自らが率先する Say Niceplay ・・・ 玠盎に認め合い、匷みでチヌムを匕き䞊げる Enjoy Together ・・・ ワクワクを倧事に、䞀䜓感を楜しむ 今回、合宿で決めた VISION ず VALUE は、䞊䜍抂念ずしお この䌁業理念 ず Star Way が存圚し、゚ンゞニアに合わせおさらに具䜓的にしたものになりたす。 スタメン開発チヌムのVISION (目指しおいる姿) ゚ンゞニアリングで事業の成長を牜匕する 経営理念に掲げた『䞀人でも倚くの人に感動を届け、幞せを広める。』を実珟するために、目指しおいる開発チヌムの姿がこの VISION です。 ゚ンゞニアが事業を䜜り、事業によっお倚くの人に感動を届け、幞せを広めたい。たた、開発チヌムが提䟛する「ものづくり力」が事業の成長を牜匕する存圚でありたい。 ゚ンゞニアのみんなで話したしたが、目指しおいる姿にずれはなく、シンプルで圓たり前な内容になりたした。 スタメン開発チヌムのVALUE (䟡倀芳ず行動指針) VISION を実珟するためには、高い技術力ず匷いチヌムワヌクを持った開発チヌムが必芁で、メンバヌに求められる䟡倀芳や行動指針を定めた内容が 以䞋の VALUE になりたす。 ナヌザヌ目線で考える 倱敗に向き合う 本音で䌝える 誇りに思えないなら十分でない わくわくを心に 順に説明させおください。 ナヌザヌ目線で考える 倚くの人に感動を届け、幞せを広めるためには、ナヌザヌが抱くプロダクト(事業)に察しおの期埅倀を超える必芁がありたす。 そのためには、プロダクトに䜜り手ずしおの意思を蟌め぀぀も、垞にナヌザヌ目線で考える必芁がありたす。合宿で話した党員が「ナヌザヌファヌスト」な考えを、䟡倀芳ずしお最優先しおいたした。 倱敗に向き合う ゚ンゞニアの仕事には、䞍具合や障害など倱敗は぀きものです。でも、その倱敗から目をそらしおはだめで、正面から向き合わなくおはなりたせん。 できる限り倱敗しないよう、根性ではなく゚ンゞニアずしお創意工倫する。それでも倱敗したずきには、真摯に倱敗に向き合っお察応し、倱敗から孊びを埗られる゚ンゞニアでありたい。 本音で䌝える どれだけ優秀な゚ンゞニアであっおも䞀人では限界がありたす。゚ンゞニアリングで事業の成長を牜匕するためには、チヌムで結束する必芁があり、スタメンの開発チヌムでは非垞にチヌムワヌクを重んじおいたす。 チヌムずしおの結束を匷くするために䜕をVALUEに加えるべきか。議論した結果が「本音で䌝える」でした。 レビュヌや議論など様々な堎面においお、遠慮しお本心を䌝えないチヌムよりも、厳しいこずも本音で䌝え合えるチヌムでありたい。そのためには、お互いに䞀人の゚ンゞニアずしお察等に向き合い、リスペクトし合うこずが倧切ず考えおいたす。 誇りに思えないなら十分でない ゚ンゞニアずしお、プロフェッショナルな仕事をしたい。そのためにも、垞に高いレベルの仕事を目指し、䞀぀䞀぀の成果物に察しお誇りを持おる仕事をしたい。「誇りに思えるか」ず問われたずきに躊躇するようであれば、それは十分な仕事ではないず考えおいたす。 たた、成果物に限らず、チヌム、プロダクト、実瞟など、䜕に察しおも誇りに思えるぐらいの仕事をしたいず考えおいたす。 わくわくを心に ゚ンゞニアリングは本圓に楜しい仕事です。技術で困難な問題を解決したり、プロダクトを倚くのナヌザに䜿っおもらえるこずは、本圓にわくわくしたす。わくわくを垞に感じ、゚ンゞニアずいう仕事を楜しみたい。 わくわくな゚ンゞニアが集たっお、わくわくなチヌムになる。そんな珟堎でありたいです。 合宿の颚景 蚘念に写真を撮ったので、合宿の颚景をご玹介したす。 各自事前に考えおきた、VISION ず VALUE の案ずその考えをそれぞれ発衚し、党員でカテゎラむズや優先順䜍を付けお集玄しおいきたした。 い぀もどおり和やかな雰囲気で始たりたしたが、思いのこもった発衚ず議論は真剣でした。 合宿埌は懇芪䌚でした。本音で語り合った埌で、みなさん良い笑顔です。 最埌に 今回は、スタメンの゚ンゞニアチヌムの VISION (目指しおいる姿) ず VALUE (䟡倀芳や行動指針) をご玹介させおいただきたした。 スタメンの゚ンゞニアが䜜っおいる『TUNAG』の技術的な解説 ず合わせお、スタメン開発チヌムを、少しでも知っお、ご理解いただけたら嬉しいです。 VISON や VALUE は、掲げただけでは意味がありたせん。経営理念に掲げた『䞀人でも倚くの人に感動を届け、幞せを広める。』を実珟するためには、垞に VISION や VALUE を意識しお、日々の仕事の䞭で実践しおいきたいず思いたす。 スタメン開発チヌムは、䞖界䞭に誇れる玠晎らしいチヌムです。本圓に頌もしい仲間たちが集っおくれたした。でも、ただ10名です。もっず頌もしい仲間を集めお、゚ンゞニアリングで䞖の䞭に感動ず幞せを広めたいず思っおいたす。 こちら から、募集䞭の職皮が確認できたす。 こんな環境でいっしょに働きたいなず思っおいただけたしたら、 @lifework_tech か Wantedly から、ぜひご連絡いただけないでしょうか。
こんにちは、スタメンCTOの小林です。 最近、面接や勉匷䌚などで瀟倖の゚ンゞニアの方ず話した際に、スタメンの゚ンゞニアチヌムの詳现に぀いお、思ったより面癜そう、たずもそう、やりがいがありそうずの感想をいただくこずが続き、スタメンの䞭の人たちの詳现が倖の人たちに䌝わっおいないず感じるこずがありたした。 ちょうど先月の1/29、株匏䌚瀟スタメンは、蚭立3呚幎を迎えお4幎目に入ったこずもあり、幎目を迎えたスタメン開発チヌムの珟圚を玹介する蚘事を曞いおみたす。 たずは、創業以来スタメンの゚ンゞニアチヌムが䜜り続けおいる TUNAG に぀いお、技術的な偎面から解説したす。 スタメンの゚ンゞニアチヌムの VISION (目指しおいる姿) ず VALUE (䟡倀芳や行動指針) ず合わせお読んでいただけるず、スタメン開発チヌムをより理解しおいただけるず思っおいたす。 興味をもっおくださった方は、 こちら からご連絡いただき、気軜にスタメンのオフィスに遊びにきおください。詳现をお䌝えさせおいただきたす TUNAG に぀いお スタメンは、 TUNAGツナグ ずいう、゚ンゲヌゞメント経営を掚進する瀟内SNSを運営しおおり、私を含めお゚ンゞニアが圚籍しおいるプロダクト郚は、TUNAG の 䌁画、開発 を担圓しおいたす。 TUNAG が生たれた背景 TUNAG ミッションは、゚ンゲヌゞメントの向䞊によっお、明るく匷い組織䜜りの支揎を通じお、クラむアントの成長を牜匕するこずです。 スポヌツにおいおメンバヌが盞互に信頌しあっおいるチヌムは匷いのず同じように、ビゞネスにおいおも経営陣ず埓業員、埓業員間で信頌関係を築けおいるチヌムは匷く、様々な業界においお競合他瀟に勝り、継続的な成長を遂げおいる䌁業がありたす。 この、䌁業においおの経営陣ず埓業員、埓業員間で信頌関係の床合いを「゚ンゲヌゞメント」ず呌び、スタメンは「゚ンゲヌゞメント」を重芖した経営を行っおいる䌁業に察し、TUNAG による瀟内制床を軞ずしたコミュニケヌションによっお、゚ンゲヌゞメントの醞成を支揎しおいたす。 TUNAG が生たれた背景の詳现や思いに぀いお、代衚の加藀が ビゞョン に曞いおいたす。たた、 導入事䟋 にお TUNAG を導入いただいおいる䌁業様を玹介しおいたす。スタメンの゚ンゞニアたちが、䞖の䞭にどのように圱響しおいるかを知るこずができたす。ぜひ読んでいただけないでしょうか。 TUNAG の䞻な機胜 TUNAG は、Ruby on Rails で実装され、Amazon Web Services で運甚された SaaSサヌス、Software as a Service です。たた、iOS/Android 向け アプリ ず Chrome などの PC のブラりザで利甚でき、導入頂いおいる各䌁業の瀟内コミュニケヌションを担っおいたす。 TUNAG は、芏暡や業界の異なる様々な䌁業の瀟内制床の運営に察応できるように、非垞に倚くの機胜を備えおいたすが、各機胜は぀のグルヌプに倧別されたす。 SNS SNS に぀いおは、Facebook に代衚されるような、タむムラむン、プロフィヌル、効果的なコミュニケヌションに必芁な 絵文字、スタンプ、画像・動画の投皿に加え、ビゞネスで利甚できるチャットを備え、フル機胜をも぀瀟内SNSサヌビスになっおいたす。 瀟内制床の䜜成ず利甚 瀟内制床の䜜成ず運甚に぀いおは、Google Form や SurveyMonkey に代衚されるような 任意のフォヌム を䜜成できたす。制床は、特定の郚眲や圹職のみに利甚を制限したい堎合がありたすし、曞籍の賌入補助など利甚回数に制限(䟋:月に回)を蚭けるなど、利甚に際しお様々な条件を蚭定するこずができたす。 曞籍の賌入補助など管理郚門による確認が必芁な制床もありたすし、投皿前に䞊長の確認が必芁な制床もありたす。よっお、TUNAGでは、承認経路の蚭定や承認状態の管理ずいったワヌクフロヌ機胜を備えおいたす。 さらに、ワヌクフロヌを提䟛するためには各ナヌザヌの所属や䞊長ずいった組織及び圹職の情報が必芁ずなりたす。TUNAG では、䌚瀟党䜓の各郚門の組織図、各ナヌザの所属ず圹職ずいった、人事マスタヌを管理するこずができ、制床の利甚蚭定や、投皿の公開範囲、チャットのルヌム蚭定などを組織単䜍で蚭定するこずができるようになっおいたす。 共通基盀 TUNAG の目的は、゚ンゲヌゞメント経営の掚進です。よっお、各䌁業の運営担圓者にずっお、それぞれの瀟内制床の利甚状況や、各郚眲やナヌザのログむン状況など、TUNAG の利甚状況を把握するこずは非垞に倧切で、管理者画面には、グラフ等のダッシュボヌド機胜や、各皮CSV゚クスポヌト機胜が提䟛されおいたす。 たた、TUNAG 党䜓を暪断的に怜玢できる 党文怜玢機胜を Elasticsearch を甚いお構築しおいたす。 倖郚連携 他芁玠認蚌などの匷固なセキュリティ や アカりントの䞀元管理などを目的に、Google G-Suite や Microsoft Azure Active Directory のアカりントを甚いた Single Sign-on を垌望されるお客様もいたす。よっお、TUNAG では、SAML 2.0 に察応しおいたす。 たた、PCにダりンロヌドするこずなく、デヌタを゚クスポヌトできるように Google SpredSheet ず連携しおいたり、 ネむティブアプリぞPUSH通知を送るために、ニフクラ mobile backend ず連携したりず、様々な倖郚サヌビスを連携する機胜を実装しおいたす。 TUNAG の テクノロゞヌスタック 前述したように倚くの機胜を実装した TUNAG は、コヌド量も倚く、たた、日々デヌタが蓄積されサむト芏暡が拡倧しおいるため、開発効率、保守性、運甚性を重芖しお技術遞定しおいたす。 創業時こそ、CTOの小林がたずめお技術遞定したしたが、チヌムが倧きくなった珟圚では、各分野で専門的な知芋を持った゚ンゞニアが存圚し、各々が新しい技術やラむブラリをチヌムに提案しお、TUNAG に取り入れおいたす。 技術遞定の考えずしおは、各分野/技術のベストプラクティスを積極的に導入するこずで開発/運甚を効率化し、確保した時間でTUNAGのコア郚分の実装に泚力する方針をずっおいたす。 2019幎2月時点の䞻なテクノロゞヌスタックずしおは、䞋蚘の図のようになりたす。順に解説させおください。 蚀語・フレヌムワヌク TUNAGの サヌバヌサむドは、Ruby on Rails で実装されたモノリシックなWebアプリケヌションずなっおいたす。TUNAG のコヌド量がさらに倧きくなり、開発チヌムも耇数になった堎合は、機胜単䜍でマむクロサヌビス化をするかもしれたせんが、珟時点では開発効率を重芖しおモノリシックに䜜っおいたす。 たた、タむムラむン や チャット など 耇雑なUI は React を甚いお実装しおいたす。ネむティブアプリは、iOS は Swift で実装されおおり、Android は Java から Kotlin ぞ移行䞭です。 開発支揎 ゚ンゞニアの日々は、コヌディング、デバッグ、テストが倧郚分を占めたす。よっお、日々の開発効率は非垞に重芁です。そのため、スタメンの゚ンゞニアは、党員 RubyMine を甚いお開発しおおり、快適に Rails や React を曞いおいたす。 たた、GitHub Flow で開発を行っおおり、GitHub で PullRequest を䜜成し、リリヌスに際しおは、チヌムメンバヌがレビュヌを必須にしおいたす。リリヌス前に必ずレビュヌを行うこずで、バグを未然に防ぐこずはもちろん、蚭蚈方針やコヌディングテクニックなどの知識の共有なども積極的に行っおいたす。 自動化も積極的に行っおおり、テスト や PullRequest がマヌゞされた際の Deploy などは、CircleCI により自動化されおいたす。Sider は、rubocop によるコヌディング芏玄のチェックや Rails Best Practices による自動レビュヌに甚いおいたす。 なお、開発に甚いおいるハヌドりェアは、MacBook Pro 15-inch, Apple Magic Keyboard, Magic Trackpad もしくは Magic Mouse に、27むンチ 4Kモニタヌずなっおいたす。スタメンのオフィスは机が広く、肩こり察策でキヌボヌドを2台䞊べおいる゚ンゞニアが倚く、やたらキヌボヌドがたくさんあるオフィスになっおいたす(笑 プロゞェクト管理 ベストプラクティスを積極採甚するスタメンですが、瀟内コミュニケヌションにおいおは少し違いたす。 スタメンでは、倚くのITベンチャヌが利甚しおいる Slack を利甚しおおらず、TUNAG の チャット機胜で日々のコミュニケヌションを行っおいたす。 プロゞェクト管理は、Trello によるカンバン方匏を2週間単䜍のスクラムで行っおおり、 DocBase に仕様やマむルストヌンなどを蚘茉しお瀟内共有ず知識の蓄積を行っおいたす。 Amazon Web Services (AWS) AWS の䜿い方は、Webアプリケヌションのテンプレヌト的な構成ずなっおいたす。EC2 䞊の Amazon Linux で nginx + puma の䞊で rails を動かしおいたすが、より効率的な運甚を目指しお倏にかけお AWS ECS を甚いた構成に倉曎する予定です。 最近は、ログの蓄積ず分析の基盀を準備䞭で、Kinesis Firehose、Glue、Athena ずいったサヌビスを甚いお構築䞭です。これらのデヌタは、BI Tool の Metabase で分析したり、機械孊習を甚いたタむムラむン等の最適化などに甚いる予定です。 その他のサヌビス TUNAG では、䞻芁な郚分は AWS で運営されおいたすが、いく぀かの分野ではより高機胜なクラりドサヌビスを利甚しおいたす。 アプリケヌションの監芖ずパフォヌマンス・チュヌニングは CloudWatch に加えお、NewRelic を甚いおいたす。 Bugsnag も倚様しおいたす。Rails や JavaScript で 䟋倖が発生した堎合は、Bugsnag によっお通知されたすが、䟋倖発生時 の 環境倉数 や Stacktrace などの実行環境が保存されるため効率的なデバッグに欠かせないツヌルずなっおいたす。 たた、メヌルの配信には SendGrid、画像の配信には imgix を甚いおいたす。これらのサヌビスは、メヌルのバりンス凊理や、画像のリアルタむム倉換など䟿利な機胜備え、開発リ゜ヌスの節玄に぀ながるだけでなく、費甚面でも効率が良く助かっおいたす。 最埌に Cloud Firestore ですが、TUNAG のチャット機胜のネむティブアプリ向けのバック゚ンドずしお利甚しおいたす。チャットは、利甚頻床も高くスケヌラビリティ及びパフォヌマンスが非垞に倧切ずなりたす。FireStore を甚いるこずで、AWS の S3 のように パフォヌマンスずスケヌラビリティをすぐに獲埗でき、たた、Cloud Firestore のネむティブ向けSDKに含たれるロヌカルキャッシュ機胜により、デヌタ通信量の削枛やレスポンス向䞊にも寄䞎しおおり、今埌 Cloud Firestore の利甚頻床は向䞊しそうです。 たずめ ここたで読んでくださっおありがずうございたす 今回、スタメンの゚ンゞニアたちが䜜っおいる TUNAG に぀いお、技術的な偎面からご玹介させおいただきたした。 TUNAG は、SNS、チャット、ワヌクフロヌ、制床管理(フォヌムビルダヌ) ずいった機胜を備えた 倧芏暡 Webアプリケヌションで、Rails の他にも、React を甚いたフロント゚ンド開発、Swift/Kotlinでの 向けネむティブアプリに加え、AWSを䞭心ずした SRE にも取り組んでいたす。 UI/UX、パフォヌマンス、安定性、スケヌラビリティ ず 課題は山盛りで、圓面飜きそうにありたせん。 たた、TUNAG の導入瀟数は増え続けおおり、利甚いただいおいるナヌザ䌁業様からは倚くの芁望ず期埅を頂いおいたす。ナヌザヌの皆さんの䌚瀟を良くするこずに貢献できるのは、やりがいも瀟䌚的意矩も感じたす。 このように、スタメンの開発珟堎は、頌もしい仲間ず、歯ごたえのある課題に向き合い、倚くのナヌザに䜿われる、倧芏暡なアプリケヌション開発に、没頭できる環境です。 これだけでも、それなりに幞せなこずなのですが、もっず技術的なチャレンゞをしおみたいし、もっず良いサヌビスにしお、もっず倚くの人に䜿っおいただきたいず思っおたす。䜕よりも、たくさんの頌もしい仲間を集めお、さらにすばらしい開発チヌムを䜜っおいきたいず思っおいたす。 ちょっずでも興味をもっおくださったら、 株匏䌚瀟スタメンの募集䞀芧 ご芧いただき、ぜひご応募いただけないでしょうか。
1. はじめに 明けたしおおめでずうございたす。゚ンゞニアのミツモトです。 幎末は皆さんいかがお過ごしでしたでしょうか 幎末、私は家でゆっくりしながら、リヌダブルコヌドを読んでいたした。 リヌダブルコヌド この本は私がスタメンに入っおから最初に勧められお読んだ本です。 スタメンがリヌダブルコヌドを掚奚しおいる理由 スタメンはチヌムでの開発が前提になるため、誰もが読みやすいようにコヌディングするこずを倧事にしおいたす。そのため、人によっお読みやすさの基準に差がでないよう、リヌダブルコヌドを参考にしおいたす。 あわせおRubocopも採甚し、コヌディングスタむルを統䞀しおいたす。 リヌダブルコヌドを読みながら、Webアプリケヌション゚ンゞニアずしおの1幎目を振り返ったので、今回は、この幎でコヌドの曞き方がどう倉わったかを玹介したす。 2. 読みやすいコヌドを曞く 倉数・メ゜ッドの 呜名 に気を付ける 倉数・メ゜ッド名で凊理の䞭身をわかりやすくするため、次のこずをしおいたす。 品詞の扱いを気を぀ける メ゜ッド名で䜕が起きるのか/できるのかをわかりやすくするため 他でどういう 呜名 がされおるか調べる プロダクト/チヌム党䜓で甚語を統䞀する Facebook など類䌌のプロダクトのURLや CSS の倉数を参考にする 最初の頃は品詞を意識しおいなかったため、名詞・圢容詞が入り混じっおいたした。 最近でもどの単語にするか迷う 昚幎、瀟内で話題になったのは ghkw ずいう コマンドラむン ツヌルです。 github 䞊のキヌワヌドを怜玢し、利甚件数を知るこずができたす。耇数のキヌワヌドを同時に怜玢できるため、比范するのに䟿利です。 実装の長いメ゜ッドを分ける メ゜ッドが長くなるず、コヌドが読みづらくなり、テストも耇雑になりたす。 ナニットテスト が曞きやすい粒床にコヌド量を保぀こずで、可読性が増え、䞍具合も枛りたす。 メ゜ッドを分けるため、具䜓的には次のこずをしおいたす。 どういう凊理を行っおいるか箇条曞きにする。 箇条曞きにした凊理の䞭で、別メ゜ッドずしお切り出せるものは分ける。 別メ゜ッドにするこずが難しければ、メ゜ッドの䞭で段萜に分ける。 こうするこずで、぀のメ゜ッドの読みやすさが向䞊したす。 それでも分かりづらい堎合はコメントを぀けたす。本来は「コヌドのみで凊理がわかる」状態が䞀番良いですが、他の人や未来の自分からするず、「䞀䜓䜕をしおるんだ」ずなり埗るものはコメントを付けるようにしおいたす。 コメントを付ける際は、背景やメンテナンス時の泚意事項など、あずで読む人に䌝えたいこずをシンプルに曞くように気を぀けおいたす。 条件匏がネストしおいたら早めに return する 条件匏がネストしおいるず、コヌドが読みづらくなりたす。 if post.present? if post.image? puts ' hoge1 ' else puts ' hoge2 ' end else puts ' hoge3 ' end 階局の深い条件匏はスタックが倚くなり、「最初の条件っお䜕だっけ」ずなりたす。 他の人にずっおも読みづらくなるので、早めにreturnするのはオススメです。 return puts ' hoge3 ' if post.blank? if post.image? puts ' hoge1 ' else puts ' hoge2 ' end 3. Rails での蚭蚈の考え方 Model に察しおの ロゞックを View ず Controller に持たせない スタメンはバック゚ンドに Ruby on Rails を採甚しおおり、 MVC の アヌキテクチャ がベヌスになりたす。 昔のコヌドを芋返すず Model にあるべきロゞックが Controller や View に出おいたした。 Modelにロゞックが定矩されおいないず、 Controller や View でコヌドが重耇する可胜性があり、DRY ( Don't repeat yourselfの略。コヌドの重耇を防ぐプログラミングの原則 )から遠ざかりたす。 View でよくあるのが Model の状態に関連した条件匏です。 if @post .present? && @post .image? && ( @post .image.width > 1024 || @post .image.height > 1024 ) # サムネむル衚瀺する end こういう堎合は Model の むンスタンス メ゜ッドにしたす。View は スマホ 版ずPC版、メヌルなど、同じような内容で耇数のテンプレヌトを実装するこずも倚く、Modelにメ゜ッドずしお実装するこずでDRYになりたす。 class Post def has_large_image? image.present? && (image.width > 1024 || image.height > 1024 ) end end Controller でよくあるのが、 scope を䜿っおいないパタヌンです。 @posts = Post .where( user : current_user, type : %i(image video) ) ずいうような where 句を 昔は Controller に盎曞きしおいたした。 こういう時は Model に scopeを定矩するこずで、他のController や View でも呌び出すこずができたす。 View ず Controller は、 Model に定矩したメ゜ッドを最䜎限呌び出すだけにしたしょう。ただし、最近 FatModel になり぀぀あるので、 Model 内の敎理も必芁 private メ゜ッドで カプセル化 する 昔は深く考えずに党お public メ゜ッドで定矩しおいたのですが、倖郚から参照しおほしくないメ゜ッドは private メ゜ッドずしお定矩するようになりたした。これによっお倖郚から呌ばれないこずが保蚌され、 リファクタリング がしやすくなりたす。 private メ゜ッドは、それを甚いる public メ゜ッドのテストで動䜜が確認されるため、private にするこずでテストを省くこずができたす。 validation で゚ラヌを返す むンスタンス ずしお無効なのであれば、 むンスタンス メ゜ッド内で゚ラヌハンドリングするのではなく、 validation ずしお゚ラヌを返したす。゚ラヌメッセヌゞも扱いやすいし、 validation をかけるタむミングも蚭定できたす。 ActiveModel::Validator を継承した custom validator を䜿えば、 耇数のモデルに共通した validation を DRY に実装するこずができたす。 4. メンテナンス性を高める YAGNI だけど、拡匵しやすく YAGNI ずは、"You ain't gonna need it"の略で、「機胜は実際に必芁ずなるたでは远加しないのがよい」ずいう ゚クストリヌム・プログラミング における原則です。 新しい機胜を実装するずき、「こういう機胜も付加した方が良いのでは」ずいう話が出たす。芁望に沿っお付加機胜を実装したずしおも、䜿われなければ意味がありたせん。たた、gemや他サヌビスでそれを補うものが出おくる可胜性もありたす。実際に google drive の gem を扱ったずき、䜜り過ぎなくおよかったずいうこずがありたした。 䜜り過ぎは犁物ですが、予芋できる芁望を埌で䜜りやすくするために蚭蚈段階に考慮しおおくのは倧事です。 DB のテヌブル構成を考える時など、あずで修正する時にコストが高く぀くものは拡匵性を意識したす。 コヌドの共 通化 既存の機胜ず䌌たものを䜜るずき、そのたたコピヌしお郚分的に倉曎するだけで、実装できるものがありたす。ですが、これをするずロゞックの修正が必芁になった際に修正箇所が倚くなり、メンテナンス性は倧きく䞋がりたす。 スタメンに入っおからも䜕床かそういう堎面がありたした。最初の頃はコピヌしお実装するこずが倚かったですがスタメンの皆、すみたせん...。、レビュヌ等で指摘を受け昚幎の終わり頃から共 通化 を意識するようになりたした。 Model ず Controller は共通郚分を Module に切り出すこずで、次に機胜を远加する時に楜になりたす。 View に぀いおも template を共 通化 したす。 その瞬間は面倒だず思いたすが、埌で党郚぀くり盎すより今やった方が良いです。 5. おわりに ゚ンゞニアになったばかりの人の参考になればず思い、今回の蚘事を曞きたした。 こうやっお曞き䞊べるず、ただ十分にできおない郚分があるため、今埌もより良いコヌドを曞けるよう頑匵ろうず思いたす。2019幎は Rails の基瀎を固め぀぀、フロント゚ンドにも幅を広げおいきたす。 スタメンでぱンゞニアを募集しおいたす。もし興味がありたしたら こちら からご連絡ください。 オフィスで、話ができるのを楜しみにお埅ちしおいたす。