TECH PLAY

BASE株匏䌚瀟

BASE株匏䌚瀟 の技術ブログ

å…š590ä»¶

BASE株匏䌚瀟 Owners Experience Frontend チヌムのパンダ @Panda_Program です。 BASE では BASE の UI を構築するための瀟内コンポヌネントラむブラリ「BBQ」を䜿っおフロント゚ンドの開発をしおいたす。 BBQ は Vue2 + Storybook v5 で䜜成されおいたす。珟圚、フロント゚ンドの有志たちで Storybook のバヌゞョンを最新の v6.2 にする察応をしおいたす。 この蚘事では、Vue2 + Storybook v5 のコンポヌネントを v6 向けに曞き換える方法を玹介したす。 なお、本蚘事ではStorybook v6 自䜓の機胜の説明や、 main.js や preview.js の曞き方ずいった Storybook の環境構築の方法には觊れたせん。 Storybook コンポヌネントを v5 から v6 に曞き換える ここでは button-group を v5 から v6 に曞き換えた䟋を玹介したす。 たずは v5、v6 の曞き方をそれぞれご芧ください。その埌、倉曎点をそれぞれ解説をしおいきたす。 v5 の button-group.stories.js // bbq/stories/elements/button-group.stories.js import { action } from '@storybook/addon-actions' import { number, select, text, withKnobs } from '@storybook/addon-knobs' import { storiesOf } from '@storybook/vue' import { withInfo } from 'storybook-addon-vue-info' import { ButtonGroup } from '../../elements/buttonGroup/button-group.vue' import README from '../../elements/buttonGroup/README.md' import { devices } from '../../values/Devices' // Storybook コンポヌネント名 const buttonStories = storiesOf( 'Elements/ButtonGroup' , module) buttonStories // addon-knob .addDecorator(withKnobs) // addon-info .addDecorator(withInfo) .add( 'ButtonGroup' , () => { return { components: { ButtonGroup } , // Vue Template template: ` <div : class = "'theme-'+device" > <p> <h2>デフォルト</h2> <div>アむコン+ラベル</div> <bbq-button-group :tag= "tag" :items= "iconsAndLabels" @change= "({index}) => {this.selected = index; change(index)}" :selected= "selected" :width= "width" /> <div>アむコン</div> <bbq-button-group :tag= "tag" :items= "icons" @change= "({index}) => {this.selected = index; change(index)}" :selected= "selected" :width= "width" /> <div>ラベル</div> <bbq-button-group :tag= "tag" :items= "labels" @change= "({index}) => {this.selected = index; change(index)}" :selected= "selected" :width= "width" /> </p> <p> <h2>カスタムUI</h2> <bbq-button-group :tag= "tag" :items= "['a','b', 'c', 'd']" @change= "({index}) => change(index)" :selected= "selected" :width= "width" > <template v-slot= "{items, change}" > <button v- for = "(item, index) in items" @click= "change(index)" > {{ item }} : {{ index }} </button> </template> </bbq-button-group> </p> </div> `, // Data data() { return { device: select(`device`, devices, 'pc' ), selected: number( 'selected' , 0), width: select( 'width' , [ '' , 'full' ] ), } } , // Props props: { tag: { default : text( 'tag' , 'ul' ) } , } , // Computed computed: { icons() { return [{ icon: 'list' } , { icon: 'grid' }] } , labels() { return [{ label: 'ドラッグで䞊び替え' } , { label: '数倀で䞊び替え' }] } , iconsAndLabels() { return [ { icon: 'list' , label: 'リストで䞊び替え' } , { icon: 'grid' , label: 'グリッドで䞊び替え' } , { icon: 'attentionCircle' , label: '念で䞊び替え' } , ] } , } , // methods methods: { change: action( 'change' ), } , } } , // Parameters { notes: README, } ) v6 の button-group.stories.js // bbq/elements/buttonGroup/button-group.stories.js import { devices } from '../../values/Devices' import ButtonGroup from './ButtonGroup' import README from './README.md' export default { // Storybook コンポヌネント名 title: "V6/Elements/ButtonGroup/Vue" , // import したコンポヌネントを指定 component: ButtonGroup, // parameters parameters: { notes: { README } , docs: { extractComponentDescription: ((_, { notes } ) => notes?.README) } } , argTypes: { // addon-knob の select で定矩しおいた倉数 device: { options: devices, defaultValue: devices [ 0 ] , control: { type: "select" } } , width: { options: [ "" , "full" ] , control: { type: "select" } } , // addon-action で定矩しおいた関数 change: { action: 'changed' } } } ; const Template = (args, { argTypes } ) => ( { components: { ButtonGroup } , props: Object .keys(argTypes), template: ` <div : class = "'theme-'+device" > <div> <h2>デフォルト</h2> <div>アむコン+ラベル</div> <bbq-button-group :tag= "tag" :items= "iconsAndLabels" @change= "({index}) => {this.selected = index; change(index)}" :selected= "selected" :width= "width" /> <div>アむコン</div> <bbq-button-group :tag= "tag" :items= "icons" @change= "({index}) => {this.selected = index; change(index)}" :selected= "selected" :width= "width" /> <div>ラベル</div> <bbq-button-group :tag= "tag" :items= "labels" @change= "({index}) => {this.selected = index; change(index)}" :selected= "selected" :width= "width" /> </div> <div> <h2>カスタムUI</h2> <bbq-button-group :tag= "tag" :items= "['a','b', 'c', 'd']" @change= "({index}) => change(index)" :selected= "selected" :width= "width" > <template v-slot= "{items, change}" > <button v- for = "(item, index) in items" @click= "change(index)" > {{ item }} : {{ index }} </button> </template> </bbq-button-group> </div> </div> ` } ); export const Default = Template.bind( {} ) Default.args = { // Default コンポヌネントに䞎える Props selected: 0, tag: "ul" , icons: [{ icon: 'list' } , { icon: 'grid' }] , labels: [{ label: 'ドラッグで䞊び替え' } , { label: '数倀で䞊び替え' }] , iconsAndLabels: [ { icon: 'list' , label: 'リストで䞊び替え' } , { icon: 'grid' , label: 'グリッドで䞊び替え' } , { icon: 'attentionCircle' , label: '念で䞊び替え' } , ] , } ; なお、 devices の定矩は const devices = ['pc', 'sp'] です。 Storybookv6の倉曎点 䞊蚘、新旧ファむルの倉曎点を抜粋しおコヌドを比范したす。 Storybook 䞊のコンポヌネント名 Storybook で衚瀺されるコンポヌネント名の定矩方法の倉曎点です。 // v5 import { storiesOf } from '@storybook/vue' const buttonStories = storiesOf( 'Elements/ButtonGroup' , module) // v6 export default { title: "Elements/ButtonGroup" , // ... } v6 では @storybook/vue を import する必芁がなくなりたした。その代わりに、default export するオブゞェクト内にコンポヌネントのメタ情報を蚘述したす。 衚瀺するコンポヌネントを指定 コンポヌネントを指定する箇所も倉曎になっおいたす。 // v5 import { storiesOf } from '@storybook/vue' import { ButtonGroup } from '../../elements/buttonGroup/button-group.vue' const buttonStories = storiesOf( 'Elements/ButtonGroup' , module) buttonStories.add( 'ButtonGroup' , () => { return { components: { ButtonGroup } , // ... } } ) // v6 import ButtonGroup from './ButtonGroup' export default { // ... component: ButtonGroup, } v6 ではコンポヌネントを default export するオブゞェクトのプロパティに远加したす。 parametersを定矩する箇所の倉曎 v5 では add メ゜ッドの第䞉匕数だった parameters の定矩箇所が、v6 では default export するオブゞェクトに倉曎になりたした。ここではマヌクダりンファむル README.md を v6 で読み蟌める曞き方を玹介したす。 // v5 import { storiesOf } from '@storybook/vue' import { withInfo } from 'storybook-addon-vue-info' import README from '../../elements/buttonGroup/README.md' const buttonStories = storiesOf( 'Elements/ButtonGroup' , module) buttonStories .addDecorator(withInfo) // decorator で addon-vue-info を掻甚しおいる .add( 'ButtonGroup' , () => { ... } , { notes: README } ) // v6 import README from './README.md' export default { // ... parameters: { notes: { README } , docs: { extractComponentDescription: ((_, { notes } ) => notes?.README) } } , } v6 では Storybook 䞊の Docs タブで README.md を衚瀺できたす。このため、 @storybook/addon-notes 、 storybook-addon-vue-info は䞍芁になりたす。 今回は v6 のコンポヌネント内で定矩したしたが、 preview.js に以䞋のように蚘述するず Storybook の党コンポヌネントに parameters が远加されるため、 docs を各ファむルで蚘述するこず避けられたす 「Migrating from notes/info addons」 。 // preview.js import { addParameters } from '@storybook/client-api' ; addParameters( { docs: { extractComponentDescription: ((_, { notes } ) => notes?.README) } , } ); なお、今回は既存資産を掻かすためにマヌクダりンファむルをそのたた䜿いたしたが、 MDXを甚いる方法も公匏で玹介されおいたす。 addon-knob の曞き換え v5 では addon-knob を䜿うず Storybook 䞊でコンポヌネントに䞎える倀を画面䞊で倉曎できたした。 v6 では addon-essentials に含たれおいる controls を䜿えば同様のこずができたす。 以䞋では knob の number 、 select 、 text 関数を曞き換えおいたす。 // v5 import { number, select, text, withKnobs } from '@storybook/addon-knobs' import { devices } from '../../values/Devices' buttonStories. add( // ... data() { return { device: select(`device`, devices, 'pc' ), selected: number( 'selected' , 0), width: select( 'width' , [ '' , 'full' ] ), } } , props: { tag: { default : text( 'tag' , 'ul' ) } , } , } ) // v6 import { devices } from '../../values/Devices' export default { // ... argTypes: { // select 関数で䜜成しおいた倀 device: { options: devices, defaultValue: devices [ 0 ] , // 初期倀の蚭定 control: { type: "select" } // この行は省略可胜 } , width: { options: [ "" , "full" ] , control: { type: "select" } // この行は省略可胜 } , } ; const Template = (args, { argTypes } ) => ( { ... } ); export const Default = Template.bind( {} ) Default.args = { selected: 0, // number 関数で䜜成しおいた倀 tag: "ul" , // text 関数で䜜成しおいた倀 } ; select 関数の代わりになる control: { type: "select" } で定矩した倀は、 defaultValue で初期倀を蚭定できたす。 なお、 export default の䞭で定矩しおいる device 、 width は以䞋のように Default.args で定矩するこずも可胜です。 // v6 Default.args = { device: devices, width: [ "" , "full" ] , selected: 0, tag: "ul" , } ; 参考: Dealing with complex values  addon-actions の action 関数の曞き換え addon-actions を䜿ったダミヌのコヌルバック関数の定矩方法も倉曎になりたした。 // v5 import { action } from '@storybook/addon-actions' buttonStories .add( // ... () => { // ... methods: { change: action( 'changed' ), } , } } ) // v6 export default { argTypes: { change: { action: 'changed' } } } ; 参考: addon-actions  ただし、以前のように action 関数を甚いおも問題なく動䜜するため、曞き換えは必須ではありたせん。 コンポヌネントに枡すデヌタの定矩の倉曎 v5 で蚘述しおいた data, props, computed で定矩しおいた倀を Storybook の画面䞊で自由に倉曎したい堎合は、 argTypes や args に集玄可胜です。 // v5 buttonStories .add( // ... () => { // ... // Data data() { return { device: select(`device`, devices, 'pc' ), selected: number( 'selected' , 0), width: select( 'width' , [ '' , 'full' ] ), } } , // Props props: { tag: { default : text( 'tag' , 'ul' ) } , } , // Computed computed: { icons() { return [{ icon: 'list' } , { icon: 'grid' }] } , labels() { return [{ label: 'ドラッグで䞊び替え' } , { label: '数倀で䞊び替え' }] } , iconsAndLabels() { return [ { icon: 'list' , label: 'リストで䞊び替え' } , { icon: 'grid' , label: 'グリッドで䞊び替え' } , { icon: 'attentionCircle' , label: '念で䞊び替え' } , ] } , } , // ... // v6 export default { // ... argTypes: { // addon-knob の select で定矩しおいた倉数 device: { options: devices, control: { type: "select" } } , width: { options: [ "" , "full" ] , control: { type: "select" } } , } ; // ... export const Default = Template.bind( {} ) Default.args = { selected: 0, tag: "ul" , icons: [{ icon: 'list' } , { icon: 'grid' }] , labels: [{ label: 'ドラッグで䞊び替え' } , { label: '数倀で䞊び替え' }] , iconsAndLabels: [ { icon: 'list' , label: 'リストで䞊び替え' } , { icon: 'grid' , label: 'グリッドで䞊び替え' } , { icon: 'attentionCircle' , label: '念で䞊び替え' } , ] , } ; ただし、data や props、computed をそのたた残すこずも可胜です。その堎合、 props 以倖は GUI 䞊で倀を倉曎できたせん。Storybook の GUI 䞊で倉曎したい倀であれば、args で蚘述すれば良いず思いたす。 BASE BBQ の.Storybook では様々なパタヌンがあるため、たずは v6 の曞き換えを優先しおいたす。このため、data 等で定矩しおいる倀は䞀旊 args に集玄し、コンポヌネントごずの现かい調敎は個別に察応する予定です。 以䞊のパタヌンで BASE の BBQ で䜜成された Storybook コンポヌネントの倧抵のケヌスを網矅しおいたす。 その他、より詳しい倉曎点は、 Storybook 6 Migration Guide をご芧ください。 addon に぀いお v6 で利甚可胜な Essential addons には、今たでの䞻芁な.addon の機胜がたずめられおいたす。 Docs Controls Actions Viewport Backgrounds Toolbars & globals Storybook で開発するにあたり、 @storybook/addon-essentials は開発䜓隓を向䞊させおくれるため、v6 からは必須ずいっおも過蚀ではないでしょう。 ここでは、先皋玹介した䟋で䜿甚しおいる addon のみ取り䞊げたす。 addon-knob v6 では deprecated addon-essentials の controls を代わりに䜿う addon-info knob ず同様に v6 では deprecated addon-essentials の docs を代わりに䜿う addon-action v7 で deprecated になる予定 v6 ではただ䜿えるが、可胜なら control に眮き換えるず次のバヌゞョンアップがスムヌズになる v6 で addon-action を䜿いたい堎合は、以䞋のように蚘述すれば OK です。 const Template = (args, { argTypes } ) => ( { // ... template: `...`, methods: { change: action( "changed" ), } } ); 衚瀺を確認する v6 の曞き方に倉曎したコンポヌネントを実際にStorybook で衚瀺するず以䞋のようになりたす。 StorybookのButtonGroup ンポヌネント control で倀を倉曎しお様々な props の衚瀺ケヌスを確認できるようになりたした。 たた、「Docs」ずいうタブをクリックするず README が衚瀺されおいたす。 StorybookのButtonGroupコンポヌネントのDocs これで v6 ぞの曞き換えが完了したした。 Storybook v6 で向䞊した開発䜓隓 v5 ず異なり、v6 では以䞋の点で開発䜓隓が向䞊したした。 コンポヌネントに䞎えるデヌタを Vue の倖args, argTypesで定矩できる args ずしお定矩した倀は addon-knob を䜿わなくおも Storybook 䞊で倀を曞き換えられる 䞊蚘の䟋では取り䞊げおいたせんが、args を倉えるこずでコンポヌネントのバリ゚ヌションを容易に䜜成できる using-args  むンストヌルする addon の数や、stories ファむルのボむラヌプレヌトが枛った おわりに 今回は Vue2 + Storybook v5 の環境で Storybook を v6 にアップデヌトする詳现な方法を玹介したした。 Storybook のバヌゞョンアップにあたり本蚘事の内容が参考になれば幞いです。 倚くの方はお気づきだず思いたすが、v5 から v6 ぞの曞き換えずいっおもパタヌンが決たっおいたす。 このため、手順さえ分かっおしたえばプログラムで機械的に眮換するだけで察応できたす。 この考え方をもずに、TypeScript Compiler API を䜿っおメタプログラミングで v5 のコンポヌネントを v6 に曞き換えたので、次回の蚘事でその方法をご玹介しようず思いたす。
この床は、5/29(土)にオンラむンで開催された PHP カンファレンス沖瞄 2021 にゎヌルドスポンサヌずしお協賛し、たた 4 名のメンバヌが登壇したした。 登壇者 4 名から発衚内容の補足など、PHP カンファレンス沖瞄 の参加レポヌトをお届けしたす phpcon.okinawa.jp 発衚内容ず補足 杉浊のセッション内容に぀いお こんにちはBASE 株匏䌚瀟でバック゚ンドの開発をしおいる杉浊 yutakasugiura です。この床、PHP カンファレンス沖瞄 で、BASE のスポンサヌトヌクずしお「倉化する時代の゚ンゞニアリング」に぀いお発衚させおいただきたした。 発衚内容の意図 PHP に関するカンファレンスでしたが、スポンサヌセッションの発衚内容は PHP 以倖のこずでも良いずのこずでしたので、広い意味で゚ンゞニアリングに぀いおお話ししたした。普段の業務における゚ンゞニアリングずは PHP のような蚀語が話題の䞭心ですが、せっかく頂いた機䌚なので、より倧きな芖点で゚ンゞニアリングを語るこずにしたした。 登壇資料 発衚内容の芁旚 䌁業掻動における゚ンゞニアリングはマヌケットニヌズに埓属的です。2010 幎代に CakePHP がフレヌムワヌクずしお支持されたのも「䟿利な web サヌビスを早く䜿いたい」ずいうニヌズが背景にありたすし、これほど AWS が広たった理由も「い぀アクセスが爆発的に増加するかわからない」ずいう課題ぞの察凊ずしお有効だったからです。スマホの普及によっお、web サヌビスぞのニヌズが 2010 幎代を通じお爆発的に増加したからこそ、これらの゚ンゞニアリングが時代の朮流ずなったず蚀えたす。 䞀方で、泚意しなければならないこずは、゚ンゞニアリング単䜓で物事を考えるず、ニヌズにそっぜを向いおしたう可胜性があるず蚀うこずです。玔粋な研究開発は別ずしお、䌁業掻動の最終目的は、顧客にサヌビスを提䟛するこずにあり、その手段ずしお゚ンゞニアリングがありたす。考えおみれば圓たり前の事実ですが、圓たり前だからこそ、この単玔な事実を忘れやすいずいうのも、たた真理です。 web 業界は誕生しおたもないこずもあり、ニヌズず技術が乖離しおしたうずいう経隓倀が少ない業界です。ですが、歎史を広く芋枡せば、時代の倉化によっお、顧客ニヌズず゚ンゞニアリングが乖離しおしたい、ビゞネスずしおは幞せにならなかった䟋は枚挙にいずたがありたせん。 今回のセッションでは、1980 幎代の DRAMダむナミック・ランダム・アクセス・メモリヌにおける゚ンゞニアリングの倱敗䟋を挙げたしたが、1 ぀の技術に粟通する゚ンゞニアほど、ニヌズに乖離しおしたうずいうのは埀々にしおありたす。科孊技術の䞖界ではパラダむムシフト、ビゞネスの䞖界ではむノベヌションのゞレンマがよく知られたすが、専門家であっおも、垞識の倉化を機敏に感じ取るこずは容易ではないのです。 2021 幎の時点で web 業界は成長産業ですし、2040 幎ぐらいたで急成長が続くこずは、ほが確実な未来です。ですが、この疑いない状況が未来氞劫、氞遠に続くのかず問われれば、その回答は「その限りではない」ず断蚀したす。 だからこそ、゚ンゞニアは现心の泚意を払っお「この゚ンゞニアリングによっおどんなニヌズが満たされるのか」「顧客ニヌズはどのように倉化しおいくのか」を、垞日頃から考え続けなければならないのでしょう。 感謝 技術に関するカンファレンスの登壇は初めおの経隓でした。貎重な䜓隓をさせおいただき、関係者の皆様に埡瀌申し䞊げたすありがずうございたした 炭田のセッション内容に぀いお こんにちはBASE 株匏䌚瀟の炭田 @tac_tanden です。今回の PHP カンファレンス沖瞄 2021 にお「PHP で throw しない䟋倖ハンドリング」をテヌマに 30 分間発衚させおいただきたした。 セッション内容に぀いお PHP で throw せずに䟋倖ハンドリングを行う事䟋をご玹介する前に、そもそも䟋倖ずは䜕かずいう郚分を敎理したり、PHP 以倖の蚀語でどのように throw しないで䟋倖ハンドリングを行っおいるのかを説明させおいただいたした。 特に、前半の䟋倖の抂念を説明するのに苊劎し、発衚でもわかりにくい郚分があったかず存じたす。䟋倖に぀いおは様々な意芋や芋解があるかず思いたすが、みなさたの議論や考えの敎理にこの発衚が少しでもお圹立おれば幞いです。 カンファレンスでの発衚に぀いお 今回自分は初めおのカンファレンスの発衚だったのですが、発衚を通しお色々な方ず関わるこずができ、ずおも楜しいカンファレンスでの発衚䜓隓になりたした 発衚䞭に twitter で様々なコメントをいただいたのも、すごく嬉しかったです。今埌も機䌚があればぜひ発衚したいず思いたした。この堎をお借りしお、運甚の皆様、参加者の皆様にお瀌申し䞊げたす。ありがずうございたした セッション動画はこちらになりたすので、興味のある方ぜひご芧いただけるず嬉しいです https://www.youtube.com/watch?v=kOhsJCW9YIE&t=14093s 倧接のセッション内容に぀いお 2021 幎 2 月から BASE 株匏䌚瀟に入瀟したした倧接 @cocoeyes02 です。PHP カンファレンス沖瞄 2021 では Git のコミットにた぀わるトヌクをさせおいただきたした。 たた、セッションの動画はこちらになりたす。 コミットぞのFBをもらうずGood 最埌のスラむドでこのセッションは自戒が含たれおいるず曞いおいたすが、それは私自身過去にコミットによる FB をたくさん受けたこずがあるからです。 䟋えば NG 䟋ずしお挙げたコミットメッセヌゞ「䞀旊コミット」「PR で指摘したので反映」「バグを盎した」は、党お過去に僕が曞いたコミットメッセヌゞだったりしたす。このコミットメッセヌゞが䜕故ダメなのか FB をもらっお、ようやく理解できるようになりたした。 コミットを芋るのは他人ず蚀う話をしたしたが、リヌダブルなコミットを曞くこずによるメリットを受け取れたか刀断するのも他人です。今回のトヌクの tips を参考にし぀぀他人から FB をもらうず、リヌダブルなコミットを曞けおいるのか刀断できるので良い思いたす スタッフの皆様ありがずうございたした 最初のオヌプニングから、最埌の懇芪䌚たで楜しく過ごすこずができたした 今幎はコロナ枊ずいうこずもあっお、盎接沖瞄の䌚堎ぞ向かうこずは叶いたせんでしたが次回は是非珟地にお登壇したいず思っおいたす 東口のセッション内容に぀いお はいさいBASE BANK 株匏䌚瀟の東口 ( @hgsgtk )です。圓カンファレンスでは、プロダクト開発のため E2E テスト環境を敎備しおきた䞭で、泥臭くなりがちなテスト環境・テストデヌタの考え方ず工倫に぀いお発衚させおいただきたした。 懇芪䌚等、PHP コミュニティの方ずも楜しくコミュニケヌションさせおいただきたした。前回の PHP カンファレンス沖瞄では盎接沖瞄珟地に䌺い、PHP コミュニティの方ず盎接話したり゜ヌキそばなどを堪胜したり楜しい時間でしたので、たた来幎・再来幎ずコロナが萜ち着いおきた際に、盎接沖瞄の䌚堎に䌺えればいいなず思いたす。 最埌に 今回匊瀟は蚈 4 名のメンバヌが登壇しお発衚する機䌚をいただき、ずおも充実した時間を過ごすこずができたした たた自身の発衚だけでなく、倚くの方々の発衚を通しお様々な知識にふれるこずができ、各々が新たな知芋や芖点を持ち垰っお来れたず考えおおりたす。 それもひずえに PHP カンファレンス沖瞄実行委員䌚の皆様のおかげです。心より感謝申し䞊げたす。 それでは、来幎もたた皆様にお䌚いできるこずを楜しみにしおおりたす
BASE株匏䌚瀟Data Strategyチヌム兌 Data Platformチヌムの楊(@wyang)です。 ショッピングアプリ「BASE」では、 前回公開した蚘事 の通り、商品怜玢基盀をCloudSearchからAWS Elasticsearch Serviceぞ移行したした。 この蚘事では、レスポンス速床改善ず怜玢粟床改善をメむンにご玹介したす。 1. レスポンス速床改善に぀いお 1-1. ElasticsearchのProfile API この Profile API を利甚するず怜玢ク゚リを分析し、どんなク゚リが発行されたのか、どのくらいの凊理時間がかかっおいるのかなどを簡単に知るこずが出来たす。 GET items/_search { "query": { "bool": { "filter": [ { "range": { "date_field": { "gte": "now-180d" } } } ] } }, "profile": "true", // profile: trueで有効になる "size": 0 } BASEではAWS Elasticsearch Serviceを䜿っおいる郜合䞊、X-Packの Search Profiler を利甚するこずはできたせんが、こちらではより手軜にパフォヌマンス分析をするこずができたす。 1-2. 改善された倉曎点 1-2-1. 時間Rangeク゚リの䞞め蟌み BASEでは長期間でログむンされおいないショップの制埡など、怜玢の芁所芁所でdate型デヌタに察する絞り蟌みをしおいたす。 GET items/_search { "query": { "bool": { "filter": [ { "range": { "date_field": { "gte": "now-180d" } } } ] } } } しかし、 Elasticsearch公匏のドキュメント )にもある通り、時刻によるフィルタリングはfilter cacheに茉らないため、毎回絞り蟌みが行われレスポンス速床が䜎速になる傟向がありたした。 ドキュメントのガむドのように時刻を䞞め蟌むこずにより、filterク゚リがfilter cacheの察象ずなり、レスポンス速床が倧幅に改善されたした。 GET items/_search { "query": { "bool": { "filter": { "range": { "date_field": { "gte": "1600819200000" } } } } } } 1-2-2. 必芁最䜎限のフィルタヌを利甚、䞍芁なドキュメントの削陀 Profile APIで時間がかかるフィルタヌにあたりを぀けた埌、怜玢むンデックスで管理する必芁がないフィヌルドずフィルタヌを削陀したした。この郚分は、むンデックス曎新バッチ偎で制埡しおおり、䞍芁なドキュメントをそもそも登録しないなどの察応で、むンデックスサむズを軜量化させたした。結果ずしお、ク゚リの軜量化にも繋がり、レスポンス速床が改善されたした。 1-2-3. search_analyzerの䜿甚 シノニム蟞曞を利甚した怜玢を実珟するために、むンデックス時ず怜玢時でanalyzerを分けお管理したした。 詳しい内容は Elastic瀟公匏の蚘事 にもありたすが、 むンデックスサむズに圱響が出ない。 甚語の統蚈党䜓は同じに保たれる。 同矩語ルヌルを倉曎するにあたり、ドキュメントの再むンデックスは必芁ない。 など、倧きなデメリットはなく、こちらの蚭蚈を採甚しおいたす。 2. 粟床改善に぀いお 2.1. A/Bテスト運甚 Firebase Remote Config による怜玢の A/Bテストを実斜しおいたす。アプリのアップデヌトを配垃せずずも、Remote Configのコン゜ヌル䞊で蚭定を修正するだけで、指定の比率でテストサむズを蚭定できるようになりたした。 2-2. A/Bテストの評䟡指暙 実際に改善に繋がったかどうかを以䞋の指暙で刀断しおいたす。 商品閲芧に぀ながった怜玢率 商品閲芧に぀ながった怜玢のうち、商品閲芧䜍眮(衚瀺順䜍)の最小倀の平均倀 怜玢結果を1件も返せなかった率 怜玢結果のうち䞊䜍k件の商品閲芧率(SERP@k) 商品お気に入りに぀ながった率 怜玢実行からレスポンスを返すたでの時間 閲芧率だけでなく他の評䟡項目(商品の倚様性など)も含めたした。 2-3. これたでに効果があった倉曎点 2-3-1. 耇数語怜玢時の絞り蟌み条件の緩和 ナヌザヌが耇数語で怜玢した堎合、語順を考慮する怜玢(type: phrase)ず、語順を考慮しない怜玢(type: best_fields)では、語順を考慮した怜玢のほうが成瞟が良いこずがわかりたした。ただし、䞀郚のキヌワヌドの結果に察しおはヒット件数が0件になっおしたうため、ヒット件数が䞀定件数以䞋になった堎合に、条件を緩和しお語順を考えないク゚リで再怜玢をするようにしおいたす。結果、CTR改善に繋げるこずができたした。 2-3-2. function_score BASEのおすすめ順では、ナヌザが怜玢したキヌワヌドに該圓するドキュメントをスコアリングする際にfunction_scoreを利甚しおいたす。function_scoreにより、ショップ情報や、商品情報の耇数の芁玠に察しお、それぞれ重みづけをしたオリゞナルのスコアを蚭定するこずができたす。 GET items/_search { ... "function_score": { "functions": [ { "field_value_factor": { "field": "score_field_A" // スコアに関するfield } }, { "gauss": { "date_field_B": { // 日付に関するfield "origin": "now", "scale": "180d", "decay": "0.5" } } } ], "score_mode": "multiply", "boost_mode": "multiply" } } 䞊蚘のク゚リでは、score_field_Aずdate_field_Bのスコアを乗算しおスコアリングをしおいたす。 gaussを利甚する堎合では、origin(now:珟圚時刻)を基準ずしお、scale(180d: 180日)の日付差の地点に察しお、decay(0.5)の枛衰をする正芏分垃のスコアを蚭定するこずができたす。 その他 日々登録される商品デヌタのサむズや、曎新反映たでに求められる時間を考慮し、 Bulkで投入するリク゚ストデヌタのサむズ refresh_interval に察する調敎をそれぞれ行い、効率的にドキュメントを曎新できる蚭定にしおいたす。 おわり 今回は移行埌におけるレスポンス速床改善ず怜玢粟床改善に぀いおご玹介したした。AWS Elasticsearch Serviceぞの移行を行うこずで継続的な怜玢性胜の改修、改善をしやすい環境を䜜るこずができたした。これからさらなる改善を行なっおいきたいず思いたす。
こんにちは、BASE株匏䌚瀟Data Strategyチヌムの杉です。 ショッピングアプリ「BASE」では、怜玢にAmazon Cloudsearchを䜿甚しおいたした。今回、怜玢基盀をAmazon Elasticsearch Service(以䞋、ES)に移行し、Data Strategyチヌムで管理をする方針にしたした。 この蚘事では商品が曎新された際などにどのように怜知し、デヌタをESにいれるようにしたかなど、基盀の郚分をメむンにご玹介をしたす。 1. 背景 怜玢は新しいショップに出䌚うきっかけを䜜っおくれたり、探しおいた商品をいち早く芋぀けるこずができるこずができたす。 そのため、怜玢機胜はどのECサむトなどでも芋かける存圚であり、掻甚しおいる人も倚いのではないでしょうか。 䟋えばショッピングアプリ「BASE」の怜玢はこのような画面になっおいたす。 このようにさたざたな䟿利さをもっおいる怜玢機胜ですが、ショッピングアプリ「BASE」では継続的な怜玢性胜の改修、改善ができおいないずいう問題がありたした。 これらの課題に察し、今回怜玢基盀の移行を行うこずで怜玢性胜改善ぞの第䞀歩を進めたした。 2. 新基盀の移行に぀いお 今回の移行はAmazon CloudsearchからESぞデヌタを移行するだけに芋えたす。 しかし、内郚的には管理をData Strategyチヌムに移行するため、商品が曎新された際に怜知、デヌタの取埗や同期など党䜓的に新しく䜜り盎す必芁がありたした。 たた、実際に移行蚈画を進めおいくず、様々な問題の壁に圓たりたした。 䟋えば Data Strategyチヌムの管理に倉えるために参照するデヌタベヌスを倉える必芁がある デヌタを党おロヌドし盎す必芁がある 商品曎新時にできる限りリアルタむムに曎新をしたいがどう実装するべきか 商品情報に関するテヌブルがたくさんある などが挙げられたす。 これらの課題が存圚したため、手探りでlogstashを詊したりembulkでデヌタ同期を詊みたりもしながら、珟圚の基盀を䜜りたした。 2-1. システム構成 今回は商品怜玢のみの移行をしたしたが、怜玢を行う䞊で商品情報に関するテヌブルは倚くありたす。 たた、これらのテヌブルがそれぞれ曎新が起きた際にESにもデヌタを同期させる必芁がありたす。 これらを考慮し、最終的に以䞋のシステム構成で実装を行いたした。 商品情報の曎新 定期的に動いおいるbatchがS3から前回起動情報を取埗 デヌタ曎新の有無の確認 曎新分のデヌタを取埗 ESのデヌタを曎新 S3ぞ曎新埌の情報を蚘録 ずいう流れで動いおいたす。これを短い時間で繰り返すこずでリアルタむムに近い間隔でデヌタを曎新するこずが実珟できたした。この「短い時間」は定期実行時間を䜕分毎ず蚭定しおいるわけではなく、可胜な最短時間で動かしおいたす。 S3に入っおいる前回起動情報はデヌタ同期をしおいるテヌブルのそれぞれの実行情報を蚘録しおいたす。このような蚘録をし、郜床取埗をするこずで急にDBの同期が䞊手くいかなくなった堎合にも、自動で埩旧するような仕組みになっおいたす。 さらに、batchはデヌタの取埗からESのデヌタ挿入たで党おPythonで䜜りたした。このPythonでの実装時にいく぀かの现かい蚭定をしたした。 こちらはinsert時のコヌド䟋です。 es = Elasticsearch( ..., timeout=timeout # (1) ) retry_count = 0 while retry_count < retry_max: # (2) try : ... es.bulk(body) time.sleep( 1 ) # (3) break except BaseException : ... time.sleep( 1 ) retry_count += 1 (1) timeoutを明瀺的に曞く timeoutを曞かない堎合、デフォルトの秒数ずなりたす。しかし、実際に動かしおみるず皀にtimeoutになるこずがありたした。 bulk時にはサむズで区切っおいたのですが、商品情報は商品説明文などが長いこずがあり、想定よりサむズが倧きくなっおしたうこずがありたした。この際にtimeoutが発生しおしたっおいたのですが、䌞ばすこずでtimeoutでの゚ラヌはなくなりたした。 (2) retry凊理をいれる こちらも同様にbulk時の凊理で皀に倱敗するこずがありたした。 しかし同じデヌタをもう䞀床詊すず成功するこずも倚かったため、retry凊理をいれるこずで察応をしたした。 (3) sleepをいれる 今回、商品情報が曎新されたら曎新分を党お曎新する仕様です。こちらも頻繁に起こるこずではありたせんが、ある時間に倧量の商品情報曎新がかかるこずもありたす。 その際に短時間に䜕床もbulkを行うず、内郚キュヌが溜たりすぎおしたうこずがありたした。䞊限倀を超えた堎合、砎棄されおしたうため、デヌタが欠損しおしたう恐れがありたす。 ESの蚭定で䞊限倀を倉曎するずいう手段もありたすが、䞊限倀を倉えおも送る量が䞊限倀を超えないずいう保蚌はなかったため、スピヌドを緩和させるこずで察応をしたした。 このように、ずおも现かい郚分の蚭定ではありたすが、これらの凊理をいれるこずでデヌタの欠損もなくスムヌズにESにデヌタをいれるためのシステムを実装するこずができたした。 2-2. 初期ロヌド 通垞の商品が远加や曎新された際のデヌタ曎新はシステム構成で曞いたような内容で行われおいたす。 しかし、今回ESには商品情報がれロの状態から始めるため、今たでのデヌタを入れ盎す必芁がありたした。 察応策ずしおは、別途batchを䜜り初期ロヌド専甚の䜜業を行いたした。 初期ロヌドのbatchは以䞋のような流れでデヌタをいれるようにしたした。 メむンの商品テヌブル以倖は䞀気に党郚取埗 user_idもしくはitem_idごずにデヌタをたずめる 商品テヌブルをID区切りでデヌタを取埗し、2のデヌタずjoin これをIDを倉えながら繰り返すこずで今たでのデヌタを党郚入れたした。 通垞時のESのinsertはupdateもしくはdeleteを䜿甚しおいたすが、初期ロヌドではindexを䜿い少しでも速くなるようにしたした。 2-3. 䟋倖テヌブル システム構成でも曞いたように、今回商品に関するテヌブルは倚くありたす。 テヌブルに䜕かしらの倉曎に起きた際に曎新をかけるずいう方法でうたくいかないテヌブルも存圚したした。 具䜓的には batchで蚈算した結果を栌玍するため同時刻に䜕十䞇、䜕癟䞇のレコヌドがinsertされるテヌブル 曎新頻床がずおも高く、玄1分間に玐づくレコヌドが䜕十䞇、䜕癟䞇存圚するテヌブル がありたす。 これらのテヌブルに関しおは、䞊の凊理ずは別の凊理も加えおテヌブル内容の同期を行なっおいたす。 2-3-1. batch蚈算結果を栌玍しおいるテヌブル こちらに関しおは、垞にinsertが走っおいるわけではなく、dailyやweeklyずいった頻床であったこずから、insert時に党おのデヌタを曎新するのではなく、少しず぀曎新をする方針にしたした。 batchでの蚈算結果の远加 定期的に動いおいるbatchがS3から前回デヌタを取埗 ID区切りでデヌタを確認 デヌタを取埗 前回デヌタずの差分を確認 差分発生デヌタのみESを曎新 S3ぞ曎新埌の情報を蚘録 倧たかな流れは通垞動いおいるシステムず同様ですが、S3に前回のデヌタを保存しおいる点ず曎新分党おを取埗するのではなく、ID区切りで他の曎新の劚げにならない量に抑えおいる点が異なるポむントずなりたす。 このような工倫をするこずで、他のテヌブルの曎新にも圱響がでず、スムヌズに曎新をするこずが可胜になりたした。 2-3-2. 曎新頻床が高いテヌブル 曎新頻床が高いテヌブルの問題点ずしおは、同時刻に曎新しなくおはいけないレコヌドが倚く、best effortでの曎新を行なっおいるずどんどん詰たっおいき、党䜓の曎新が遅くなるずいうこずがありたした。 曎新レコヌドが倚く、曎新も垞に起こっおいるためbatch蚈算結果テヌブルのようにIDで区切っお少しず぀いれるようなこずもできたせんでした。 怜蚎の察象ずなった曎新頻床が高いテヌブルでは、倚くの情報が入っおおり、少しの曎新でもレコヌド党䜓に曎新がかかっおしたっおいたした。 そのため、必芁な情報のみをS3ぞ保存し、曎新が起きた際にS3の情報ず比范をし、必芁な情報に曎新が起きた際のみ、ESのデヌタも曎新をする方法にしたした。 S3に前回情報を保存し、毎回取埗するこずはデヌタ曎新の速床に圱響しおしたう可胜性もありたしたが、幞いにも本圓に曎新すべきデヌタがかなり枛ったため、速床アップに぀ながりたした。 おわり 今回は移行埌の基盀に぀いおをメむンにご玹介したした。 このように実装を行い、珟圚のショッピングアプリ「BASE」では移行埌のシステムで皌働をしおいたす。 実際には基盀完成埌にAPIのresponse timeが遅い問題の察応や、CTRの改善などを行なっおいたす。こちらの詳现に぀いおは来週ご玹介させおいただきたす。 移行を行うこずで継続的な怜玢性胜の改修、改善をしやすい環境を䜜るこずができたした。これからさらなる改善を行なっおいきたいず思いたす。
はじめに こんにちは。BASEのCSEチヌムの秋谷です。 CSEチヌムは瀟内業務の効率化ず財務の信頌性担保するこずを専門ずするチヌムずしお開発や瀟内の敎備を行なっおいたす。そんなCSEの取り組みを玹介できればず思いたす。 CSEに぀いお詳しくはこちらをご芧ください devblog.thebase.in BASEショップの売䞊金の担保ずJ-SOX察応 BASEではショップの売䞊を䞀時的にプラットフォヌム偎が預かっおおり、申請があった段階で売䞊金を匕き出せるようになっおいたす。 そのため、ECプラットフォヌムはショップに察しお、以䞋のこずを担保するこずが倧前提です。 デヌタが適切であるこず 発泚、決枈デヌタの適切な蚘録がされおいるこず 䞊蚘デヌタから䜜成される、売䞊蚈䞊のデヌタの䜜成が適切であるこず 集蚈範囲、抜出がただしくおこなわれおいるこず BASEは2019幎12月に䞊堎したこずもあり、J-SOXぞの察応を求められるようになりたした。これにより、より厳栌にショップの売䞊金に察しおデヌタの透明性を担保し、たたそれに察しお監査を受ける矩務が発生したした。 J-SOXずは 財務報告に係る内郚統制報告制床の抂芁 J-SOXにおいおは、経営者は財務報告に係る内郚統制を構築する責任を有しおおり、その有効性を自ら評䟡し、倖郚に察しおその結果を報告するこずが求められたす。たた、財務報告に係る内郚統制の有効性に関する経営者の評䟡を倖郚監査人が監査するこずによっお、その評䟡の適正性を確保する制床ずなっおいたす。 監査人による内郚統制報告曞の監査 J-SOXでは、財務報告に係る内郚統制の有効性に関する経営者の評䟡を監査人が監査するこずによりその適正性を確保するこずずされおいたす。たた、内郚統制監査は、原則ずしお財務諞衚監査ず同䞀の監査人が実斜するこずずされ、内郚統制監査報告曞は財務諞衚監査報告曞ず合わせお䜜成するこずが原則ずされおいたす。 参照 https://www.pwc.com/jp/ja/knowledge/ipo-guideline/j-sox.html ショップの売䞊金の怜蚌ず経理業務の負担 店舗預かり金に぀いお BASEではショップの売䞊金を店舗預かり金ず称しおいたす。この店舗預かり金に察しお経理チヌムがデヌタを怜蚌し、劥圓性を担保しおいたす。 圓初は売䞊デヌタを取埗するのに時間がかかっおしたったり、日々動いおいるトランザクションに察しお垞にSQLを実行しおいるためキャンセルなどが発生した堎合に再集蚈するず過去の結果が倉わっおしたったり、Excelでデヌタの確認䜜業を行なっおいたためExcelが重くなり開けなくなるなどの物理的な問題もありたした。 たた、売䞊金を担保するためにBASEシステム䞊のデヌタず各決枈デヌタずの突合しなければなりたせんが、これにもかなりの時間がかかっおいたした。 reportシステムの構築 そこでCSEでは䞊蚘の問題を解決するために、BASEのデヌタ集蚈やレポヌティングのためのシステム以䞋reportシステムを䜜成したした。 先述の通り、BASEでは各ショップの売り䞊げを䞀時的に預かっおいるため、特に以䞋の点に぀いお詳しくチェックをしおいたす。 店舗預り金のBASEシステムのデヌタが適切に䜜成されおいるか 䟋商品の代金、送料、各皮手数料が正しく蚈算されおいる 店舗預かり金の構成芁玠に倉曎はないか 䟋新芏決枈手段の远加AmazonPayなど 決枈デヌタの突合 䟋BASEシステム䞊のデヌタずクレゞットカヌドの決枈情報が正しいか この売䞊デヌタの取埗やデヌタの突合をしやすくしたり、構成芁玠の倉曎をわかりやすくするために、日次でBASEシステムの本番DBから必芁なデヌタをAmazon Athenaにむンポヌトしおいたす。 reportシステムの構成に぀いお次に詳しく説明したす。 構築 reportシステム抂芁 reportシステムの抂芁はざっくりこんなかんじです。 1. BASEシステムの本番DB(Amazon Aurora)から、必芁なデヌタをAmazon Athenaに日次で取り蟌む 2. Amazon Athenaに察しおSQLを実行しお、レポヌトずなるCSVを出力 reportシステムの構成 report-dataloader図䞭の青枠、青矢印 レポヌトシステムのデヌタを準備する Auroraのクロヌン䜜成機胜でテンポラリDBを䜜成 Embulkを甚いお、テンポラリDBからレポヌトに関わるテヌブル、列のデヌタをAthenaにロヌド ( civitaspo/embulk-output-s3_parquet を䜿甚) report図䞭の赀枠、赀矢印 レポヌトのデヌタを抜出する 店舗預り金に関わるデヌタを抜出するク゚リをAthenaに発行する ク゚リの結果からCSVを䜜成する レポヌトシステム 各決算デヌタの取埗機胜 各決枈デヌタずBASEシステム䞊のデヌタを突合するために、各決枈システムからデヌタを取埗しおAthenaにむンポヌト report-datacollector 各決枈の倖郚のシステムからデヌタをダりンロヌドをしおきおS3に保存 決枈システムによっお取埗方法が異なる 各皮APIの利甚など report-dataloader S3に保存したデヌタからAthenaのテヌブルを䜜成 report-dataloader reportシステム構築による効果 reportシステムの構築によりAmazon Athenaぞク゚リを実行するこずによっお、重たいク゚リを実行しなくずもBASEシステム䞊で取埗しおいた店舗預かり金ず同等のデヌタが取埗可胜になり、日次でのデヌタの突合もし易くなりたした。 BASEにはさたざたな決枈方法があるため䞀抂には蚀えたせんが、䞀番トランザクション数の倚い決枈で玄人日分の工数の削枛出来おいたす。ク゚リの実行時間は決枈方法に関わらずほが同䞀なので、トランザクション数が倚い決枈ほど工数が削枛されおいるこずになりたす。 終わりに 䞊蚘に挙げた以倖にも、BASEではreportシステムには経理業務を改善するための现かな機胜を随時远加しおいたす。 ここに挙げた䟋はCSEの掻動の䞀郚です。CSEは Corporate Solutions Engineering の略であり、瀟内業務のより良く改善できればず思っおいたす。 CSEチヌムでは、゚ンゞニア力で瀟内業務の効率化やJ-SOX察応をリヌドできるコヌポレヌト゚ンゞニアを募集しおおりたす。 䞋蚘のリンクから気軜にご連絡ください。 https://open.talentio.com/r/1/c/binc/homes/4380
こんにちは。BASE BANK株匏䌚瀟 Dev Divisionにお、 Software Developerをしおいる氞野 ( @glassmonkey ) です。 今回は匊瀟でブロンズスポンサヌずしお協賛したした。 PHPをメむン蚀語ずしお䜿甚しおいるBASE瀟ず異なり、BASE BANK瀟ではGoをメむン蚀語ずしお䜿っおいるので、今回は初めおBASE BANK瀟ずしおスポンサヌドさせおいただきたした。色々至らぬこずもありたしたが、この堎を借りおお瀌を申し䞊げたす。 登壇の内容に関しおですが、業務ではなく趣味で觊っおるFlutterネタです。勢いでProporsalに出したら通しおいただいたので、趣味党開な圢になりたした。 GoConference2021 Springに぀いお gocon.jp https://gocon.jp/ Go Conferenceは半幎に1回行われるプログラミング蚀語Goに関するカンファレンスです。 今回は初のオンラむン開催ずいう蚘念すべき回でもありたした。 本蚘事のGopherアむコンのラむセンスは以䞋の通りです。 github.com The Go gopher was designed by Renee French. ( http://reneefrench.blogspot.com ) The gopher stickers was made by Takuya Ueda ( https://twitter.com/tenntenn ). Licensed under the Creative Commons 3.0 Attributions license. 感想ず振り返り 発衚内容に぀いお 今回は個人の趣味でハマっおるFlutterネタを発衚させおいただきたした。 私自身はGoæ­Ž1幎ぐらいのただただ初心者ではありたすが、機䌚をいただけおよかったです。 speakerdeck.com 発衚の様子はこちらです。 youtu.be 発衚に぀いおの振り返り 話のベヌスずしお觊れた gomobile が䜕かず䞍安定なので、サンプルアプリを䜜る際は色々ずハマりたした。それも登壇ネタになったかなず考えるず矎味しい思いはできた気がしたす。 その埌の懇芪䌚でも、色々Firebaseの話ができたりGoのむベントなのにモバむルアプリの開発談矩ができお倧倉楜しい時間を過ごせたした。 たた、「FlutterずGoのAPIの通信する」アプリを予想されおた思われおた方も居たようで、いい意味で予想をひっくり返せたのは良かったです。改めおGoの自由さを玹介できた点は良かったずおもっおおりたす。 時間配分を少し間違えお埌半駆け足になっおしたったのは反省ずしお今埌の登壇には掻かしたい所存です。 アドリブ気味ではあったのですが、発衚時にオヌプンク゚スチョンを投げるこずができたのも満足でした。 懇芪䌚 Remoで実斜されおおり、前半はテヌブルごずで雑談、埌半はみんなでわいわいクむズ倧䌚な流れでした。 remo https://remo.co/remo-101 特に @tenntenn さんの出題した go quiz めちゃくちゃ難しかった思いです。䞀番印象に残ったのはgo 1.16から入るembedに関しおのクむズですね。勉匷になりたした。 これコンパむル通るか  embedが適応されるケヌス。倉数の䞭身にファむルの内容が栌玍される。 //go:embed hoge.json var message string ただのコメントアりト(//の埌にスペヌスがあるのでembedではなくコメント扱いになる // go:embed hoge.json var message string 感想ず謝蟞 発衚時の進行に関しおは事前にリハヌサルや説明を @micchiebear さんを始めずした運営の皆様の厚いフォロヌがあったので圓日はスムヌズに行うこずができたので発衚に集䞭できたした。運営の皆様ありがずうございたした。 たた、スポンサヌドの窓口ずしおも関わらせおいただいたのですが、運営の皆様に手厚くフォロヌしおいただいおありがずうございたした。 https://gocon.jp/ に自瀟のロゎが茉っおいるずわかった瞬間感無量でした。 私自身Go歎は1幎ぐらいなので党然わからないこずだらけではあったのですが、 参加された方々の Go Love が䌝わっおきおもっず私自身頑匵ろうずいう気持ちにさせおいただきたした。 特に登壇資料を業務時間を割いお䜜っおる䞭フォロヌしおれた同僚にも感謝です。 宣䌝 今回は趣味ネタでFlutter×Goを觊れさせおいただきたしたが、 私たちの普段の業務はGo, Python, PHPを䞭心に、フロントからむンフラたでを䞀気通貫で開発しおいたす。 たた、開発だけでなく・機胜をグロヌス・サポヌトたで担圓したす。 そんな開発スタむルに興味あるぞっお方は氞野( @glassmonkey )にDMを送っおいただくか、 䞋蚘のリンクから気軜にご連絡ください。 open.talentio.com 最埌たでご芧いただきありがずうございたした。
こんにちは、デザむナヌの河越です。 「BASE」では今幎の2月に、泚文時に賌入者に送られる賌入完了メヌルをリニュヌアルしたした baseu.jp これたで「BASE」から賌入者に送られるメヌルはほずんどがテキストメヌルでした。 各ショップが工倫しおネットショップ䞊でブランドの䞖界芳を衚珟しおいるにも関わらず、賌入者が受け取るメヌルがショップの䞖界芳ずマッチしおおらず賌入者に違和感を䞎えおしたうずいう課題がありたした。 そこで今回、「BASE」から送られおいるあらゆるメヌルをHTMLメヌル化する「メヌル改善プロゞェクト」が始たりたした。 たず第䞀匟ずしお賌入完了メヌルがHTMLメヌル化されたしたが、どのような経緯でリニュヌアルに至ったのか、デザむンで工倫した点などを振り返りたいず思いたす 賌入完了メヌルのHTMLメヌル化の経緯 「メヌル改善プロゞェクト」は、デザむナヌ䞻導で始たりたした。 「BASE」の䜓隓をより良くできそうな箇所があれば、デザむナヌが䞻䜓的に課題を解決しおいける環境があるのはBASEの良いずころだなず思いたす☺ プロゞェクトのキックオフが終わったら、たずは「BASE」から賌入者やショップオヌナヌに送信されおいるすべおのメヌルをリストアップしたした。 賌入完了メヌルや発送完了メヌル、お問い合わせ完了メヌルなど、賌入者に送信されおいるものだけで32皮類ものメヌルがあるこずがわかりたした。 メヌルを掗い出したあずには、ショップオヌナヌや賌入者の声を䞀番近くで聞くCS (Customer Support) チヌムに、メヌルに関しおどのような問い合わせが来るかをヒアリングしたした。 その結果「 ブランドのお店で泚文をしたのに"BASE"からメヌルがきお混乱した 」「 銀行振蟌決枈を遞択しお泚文したあず、どこに振り蟌めば良いのかわかりづらかった 」ず感じおいる賌入者がいるこずがわかりたした。 CSチヌムからのヒアリングを経お 賌入者の賌入䜓隓を向䞊させるこず ショップのブランドブランドの䞖界芳を壊さないこず を念頭に、たずは賌入完了メヌルをリニュヌアルするこずに決めたした。 完成したデザむン ショップロゎや、蚭定しおいるSNSを衚瀺 ショップがロゎを蚭定しおいる堎合、メヌルのヘッダヌ郚分にショップロゎが衚瀺されるようになりたした。 これにより「"BASE"っおサヌビスからメヌル来たけどなぜ」ずいう戞惑いをなくすこずや、ショップの䞖界芳ず倧幅に解離したメヌルをなくすこずで、泚文時から䞀貫したショップでの賌入䜓隓を賌入者に提䟛するこずを意識したした。 たた、フッタヌパヌツに蚭定しおいるSNSやショッピングアプリ「BASE」ぞの導線を配眮するこずで、ショップの普段の掻動や商品に぀いお賌入者が知りやすくなりたした。 賌入した商品がファヌストビュヌに衚瀺させるこずで、賌入盎埌のわくわく感も醞成できたら良いなず思っおいたす😆 レコメンド゚リアを远加 そのショップで販売されおいるその他の商品を画像付きで衚瀺させるこずで、リピヌト率の向䞊やショップの売䞊増加を狙う導線を新たに取り入れたした。 たずめ 賌入完了メヌルをリニュヌアルしお早2ヶ月。 期埅通り「その他の商品」からの賌入が増えおいたす。 たた、メヌルが芋やすくなったこずで瀟内からも奜評をいただいおいたす これたで以䞊にカスタマヌサポヌトやカスタマヌサクセスの声を聞きながらデザむンを䜜ったこずや、圱響範囲の倧きい品質向䞊に関われたこずで達成感が倧きく、このプロゞェクトにアサむンされおよかったなず思いたす。 たた、「BASE」から送られおいるHTMLメヌルがほずんどなかったため、コンポヌネントを1から考えお䜜れる楜しさも感じれたした。 賌入完了メヌルは「BASE」を利甚しおいるwebのネットショップからの賌入でも、ショッピングアプリ「BASE」からの賌入でも芋られるので、賌入のさいにチェックしおいただけるず嬉しいです😉 今回は賌入完了メヌルをリニュヌアルしたしたが、「BASE」から賌入者に送信しおいるその他のメヌルもどんどんリニュヌアルしおいきたいず思いたす。
集合写真写真真ん䞭よりちょっず䞊にお、巊胞にBASEロゎがあるパヌカヌを着おいる倧接 こんにちは。Product Dev Divisionに所属しおいる 倧接 です。 今回、PHPerKaigi 2021にコアスタッフずしお参加したした。私がなぜコアスタッフずしお参加したのかずいう点も含め、カンファレンスの裏偎に぀いおレポヌトしたいず思いたす PHPerKaigi 2021ずは PHPerKaigi 2021ずは、3月26日金〜3月28日日の期間で開催されたPHP系の技術カンファレンスです。今幎で4回目の開催ずなりたす。 phperkaigi.jp オフラむンカンファレンスだった䟋幎ずは違い、今幎はニコニコ生攟送を䜿っお進行するオンラむンカンファレンス圢匏になりたした。 グリヌンバックに写っおいる人が芋る生攟送甚ディスプレむ グリヌンバックに写っおいる人が芋る生攟送甚ディスプレむ 匊瀟もゎヌルドポンサヌずしお協賛し、スピヌカヌや䞀般聎講者ずしお数名が参加したした。以䞋の蚘事に参加レポヌトが曞かれおいたすのでそちらも是非ご芧ください devblog.thebase.in 舞台裏ではどんなこずをしたの PHPerKaigi 2021では以䞋のような仕事がありたした。私が担圓したのはこの䞭の䞀郚です プロポヌザルの採択 デザむンの採択ロゎ、ノベルティボックス、Tシャツ、パンフレット、公匏サむトなど ノベルティボックスの発泚、発送 公匏サむトのコヌディング 攟送時に䜿う動画や録画されたセッション動画の線集 広報、宣䌝 生攟送の進行 セッション動画を再生するなどの生攟送機材操䜜 動画終了埌のアナりンス Ask The Speakerの叞䌚 TLTwitter監芖、お問い合わせ察応 アンカンファレンスに参加しお賑やかす twitter や discord、ニコニコ生攟送でわいわいコメントする ノベルティボックスの発送やセッション動画の線集、生攟送の進行はオンラむンカンファレンスならではの仕事だったかもしれたせん。 今幎のPHPerKaigiはオンラむンだけど、ノベルティ、ありたす ステッカヌやTシャツ、スポンサヌさたご提䟛ノベルティが入ったステキなボックスがみなさんのお手元に ノベルティ付きチケットは2/28たで販売䞭 写真はデザむナヌさんによる詊䜜品です #phperkaigi https://t.co/bjcXHQuoD9 pic.twitter.com/33Qr5hzOea — PHPerKaigi 2021 @3/26-3/28 (@phperkaigi) 2021幎2月25日 生攟送ず録画甚の機材 䞀般聎講者やスピヌカヌの方々は終始完党オンラむンでしたが、倧䜓のスタッフはオフラむンで䜜業しおいたした。 物理的な受付がない分お問い合わせが増えるこずを予期しお、TLTwitter監芖やお問い合わせ察応の人数を増やすなどの察応もありたした。 生攟送の進行をするスタッフも、それぞれが聞きたいセッションを䌑憩時間にしたり、Ask The Speakerでスタッフも質問を投げかけおみたり、スタッフもアンカンファレンスに参加するなど、スタッフ自身が楜しむずいうこずも心がけながら良いオンラむンカンファレンス䜓隓を目指しお裏で動いおいたした スタッフが念を送っおいる時の様子 コアスタッフずしお参加し続ける理由 実はPHPerKaigi 2020でもコアスタッフだったので、コアスタッフは2回目ずなりたす。 私がコアスタッフずしお参加し続けるモチベヌションに぀いおお話ししたす。 いち゚ンゞニアずしおメリットがある コアスタッフずしお参加するず、仕事を通しお様々なメリットを埗るこずができたす。 䟋えば、プロポヌザルの採択の際に自分がコアスタッフであれば、自分が聞きたいセッションを採択しやすくするこずができたす。もちろんプロポヌザル採択の芳点は色々あるため、必ず叶うずいうわけではありたせん。ですが、芳点の1぀ずしお「スタッフがいち参加者ずしおこのセッションを聎いおみたいか」があるため、可胜性は十分にありたす。 たたむベントを運営するにあたっお様々な仕事をこなすこずになるため、むベントの運営力が䞊がりたす。カンファレンス運営のノりハりは、芏暡を問わず他のむベント運営でも掻かすこずのできる点は倚いです。自分がむベントの開催をするこずになった時、ずおも圹に立ちたす。 他にも、PHPコミュニティに所属しおいるスタッフず仲良くなれる、スタッフはカンファレンスに無料で参加できるずいうようなメリットもありたす。 お䞖話になっおいるコミュニティに貢献したい BASEでは、私たちが䜿っおいる技術スタックのむベント・カンファレンス・勉匷䌚ぞの参加を掚奚しおいたす。 その理由の䞀぀ずしお、「自分たちが䜿っおいるOSSや技術情報を発信しおいる方々ぞ貢献できるから」ずいうこずを匊瀟では挙げおいたす。どのような行動が貢献に繋がるのでしょうか私なりに䟋を挙げおみたした。 聎講者ずしお参加し、圓日のむベントの様子を口頭やブログなどで䌝えるこず スピヌカヌずしお登壇し、自分の知芋を広めるこず。 カンファレンススタッフずしおむベントを盛り䞊げるこず。 䞊蚘のいずれもコミュニティの掻性化ぞず繋がるので、党お立掟なコミュニティぞの貢献掻動だず私は考えおいたす。その䞭でも私は、PHPerKaigiのカンファレンススタッフずしおむベントを盛り䞊げるずいう圢で貢献するこずを遞びたした。 PHPerKaigiは、私が技術カンファレンスの䞭で 初めお登壇した むベントです。そのこずがきっかけで他のカンファレンスでも登壇するこずになり、登壇を通じお゚ンゞニアずしお成長するこずができたした。 初めお登壇したカンファレンスがPHPerKaigiで思入れがあるこずず、同じように誰かぞ成長の機䌚を䞎える偎になりたいずいう想いで、コアスタッフずしお参加しおいたした。 最埌に 来幎もPHPerKaigiが開催されるならば、コアスタッフで参加したいず思っおいたす。参加した皆さんにずっお良いカンファレンスであったのであれば幞いです たた、カンファレンススタッフだけでなくスピヌカヌずしお登壇するこず、聎講者ずしお参加ブログを曞いおむベントの様子を広めおいくずいう圢でも貢献し続けおいきたいず思いたす
この3ヶ月で行ったBDIの内容を玹介したす こんにちは、デザむナヌの枡邊です。 今回はBASEのデザむンチヌムが行っおいる勉匷䌚「BDI」の内容をご玹介したいず思いたす。 BDIずは 『BDI』は「BASE Design Inspiration」の略。 2018幎の秋頃から掻動しおいる、デザむナヌがやりたいこずを持ち寄っお、 デザむンに関する幅広い知芋をみんなで楜しく孊ぶこずを目的ずした任意参加の瀟内勉匷䌚です。 BASEのデザむナヌであれば、デザむナヌだけでなく誰でも参加するこずができたす。 Inspirationの名の通り新たなひらめきに぀ながる新しいトピックを取り䞊げるこずも倚くありたす。 過去にはBDIのロゎも制䜜したりしたした↓ devblog.thebase.in BASEのデザむナヌがどんな掻動をしおいるのか気になっおいる方に読んでいただきたいのはもちろん、 瀟内勉匷䌚やワヌクショップのネタずしおもご掻甚くださいね 1月 新幎曞き初めで䜜字を孊がう 新幎ずいうこずで、お正月らしいオンラむン曞き初め䌚を開催したした。 デザむナヌだけでなくいろんな方に参加しおいただきたかったので、 䜜字のコツを解説する簡単なLTを冒頭に実斜 初心者歓迎ムヌドを打ち出し 手曞きOK、写真を撮っおアップするだけ などなど、参加ハヌドルを䞋げる工倫をしたした。 芋る専の人も楜しめるように、ファシリテヌタヌの手元のiPadをミラヌリングしおリアルタむムに䜜字が出来䞊がる過皋も芋おもらいたした。 できた䜜品はJamboardに貌り付け、みんなで芳賞。 耒め蚀葉の嵐でさながらボディビル倧䌚のようになり、かなり盛り䞊がりたした 身近なデザむン4倧原則を分析しおマスタヌしよう デザむンの基本ずなる「デザむン4原則」を実際に䜿われおいる事䟋から分析するワヌクショップをしたした。 デザむンの基本ずなる「デザむン4原則」を心理孊にも觊れながら解説するLT 事䟋を芋ながら4原則のどの芁玠が䜿われおいるかを分析 実際にかんたんなワヌクショップで実践 ず、マゞメでしっかりタメになる䌚でした 䞁寧なLTは初心者にもわかりやすく、デザむナヌ以倖の方も「なにが良いデザむンなのか」を刀断するための倧きなヒントになる内容でした。 スラむド/LP/パンフレットを芳察しながら原則ず照らし合わせるこずで、レむアりトぞの理解がより深たりたした。 たた経隓豊富なデザむナヌが「なんずなく」で出来おしたっおいる情報の匷匱も、改めお原則を孊び盎すこずで根拠あるデザむンなんだな〜ず振り返るこずができた䌚になったず思いたす 2月 ノヌコヌド系ツヌルを觊っおみよう コヌディングを必芁ずせずにシステム開発やアプリケヌション開発ができるノヌコヌドツヌルが盛り䞊がっおいるずいうこずで、BDIの時間でみんなでおさわり䌚を開催したした。 前半はWebflow, Wix, STUDIOの3぀のノヌコヌドツヌルに぀いお簡単に解説、実践線ではSTUDIOを実際に觊りながら、感想や気付きを共有したした。 耇数人の同時線集が出来るのは個人的に衝撃でした...䞊手く䜿いこなせば爆速でLPずか䜜れちゃうんだろうな、ずいろんな可胜性を感じおかなり盛り䞊がりたした。 1時間で架空ブランドのコンセプトを䜜っおみよう BASEを利甚するショップオヌナヌの仕事を远䜓隓するため、ブランディングのワヌクショップをやっおみたした。 競合調査からタヌゲット決め、ブランド名を䜜るずころたで1時間の短い時間でこなすのはかなり倧倉でしたが、 事前にmiroに甚意したテンプレヌトを埋めるこずで途䞭かなり急かしたりしちゃいたしたがやり切りたした... ここで制䜜したブランドコンセプトたちは埌のBDIでロゎ制䜜、ショップ開蚭ワヌクショップに掻かしおいきたす。 3月 俺みたいになるなしくじりLT䌚 某人気テレビ番組のフォヌマットを拝借し、 4名のBASE瀟員に、仕事や私生掻でのしくじりずそれを経お埗た教蚓をLT圢匏で発衚しおもらいたした。 今回は詊隓的に芖聎者のslackコメントをリアルタむムで画面䞊に流しおみたのですが、結果かなり盛り䞊がりたした ツヌルは こちら を䜿甚させおいただきたした。 すぐに反応が返っおくるので、リモヌトでも登壇者が寂しい気持ちにならずに楜しく発衚できおたした。しくじりの内容は瀟内限定なのでお芋せできないのですが、涙ず笑いなしには芋られない玠晎らしいものでした 90秒ドロヌむングをやっおみよう 矎術・デザむン系孊校でよく行われるドロヌむング。シル゚ットや構造を芳察する目が身に付くずいわれおいたすが、瀟䌚人になっおからもやっおいるずいう人は少ない...。ずいうわけでBDIでチャレンゞしおみたした ドロヌむングのwebサむト を利甚したり、瀟員の写真を䜿いながら集䞭しおドロヌむング、埌半はみんなで講評をしたした。人によっお曞き蟌む箇所が違ったり、立䜓感の出し方に気付いお短時間で画力が成長しおいる人が珟れたりずなかなかためになる時間でした。単玔に絵を曞くこずは楜しいず思い出せる機䌚にもなりたしたので、みなさんも是非挑戊しおみおください たずめ 月2回ペヌスで開催しおいるBDI。最近はありがたいこずに参加者も増えお盛り䞊がっおきたした。 玹介した䌁画は党おオンラむン䞊で行っおいたす。オフィスに出瀟できずチヌム間のコミュニケヌションが少なくなっおしたいがちですが、こういった勉匷䌚はゆるっずした絡みを䜜るのにもずおも良い機䌚だず感じおいたす。 これからもためになっお楜しい䌁画を運営メンバヌを䞭心に日々考えおいきたす。4月以降もお楜しみに
BASE株匏䌚瀟 ServiceDev Payment Group 所属の田仲です。 珟圚ぱンゞニアリングマネヌゞャヌを担圓しおいたすが、以前はサヌバヌサむド゚ンゞニアずしお開発をしおいたした。その頃の経隓を玹介したいず思いたす。 BASEの゚ンゞニアはPM・ディレクタヌから芁件を聞き、蚭蚈を行いたす。 仕様や蚭蚈を元にサヌバヌサむド゚ンゞニアはサヌバヌサむドの実装し、フロント゚ンドに関しおはフロント゚ンド゚ンゞニアが実装しおいたす。 少し前のプロゞェクトになるのですが、「送り状デヌタダりンロヌドApp」の開発プロゞェクトを担圓した際にサヌバヌサむドだけではなくフロント゚ンドの開発にも携わるこずになりたした。 普段、サヌバヌサむド゚ンゞニアずしお開発を行っおいる゚ンゞニアがフロント゚ンドの開発も行うこずで良い経隓になったずいう話を玹介したいず思いたす。 送り状デヌタダりンロヌドAppに぀いお 商品を発送する際にダンボヌルなどの箱に送り状を貌りたすが、出荷件数が倚いショップでは1件づ぀送り状を印刷しお貌るのは手間が掛かり限界がありたす。手間を解決するために配送䌚瀟の集荷を利甚するこずや倖郚倉庫ぞの委蚗などの方法はありたすが、費甚が掛かるためショップの負担になりたす。 そのようなショップの課題を解決するために配送業者各瀟が提䟛しおいる送り状発行システムを利甚しお送り状を䞀括印刷できるようにするためにBASEのシステムからCSVデヌタを出力できるようにする機胜になりたす。 普段の開発プロセス BASEの開発プロゞェクトは、サヌバヌサむド゚ンゞニアずフロント゚ンド゚ンゞニアがそれぞれアサむンされ協働しながら開発を進めおいたす。 今回の送り状デヌタダりンロヌドAppの開発プロゞェクトでは、サヌバヌサむドずフロント゚ンドのタスクはざっくりですが䞋蚘のようになりたした。 サヌバヌサむド 固定倀の登録・曎新デヌタのCRUD 各配送䌚瀟システムに合わせたCSVファむルの出力凊理 フロント゚ンド 固定倀の登録・曎新画面 CSV出力凊理モヌダル 入力倀のバリデヌション/゚ラヌ衚瀺 BASEはフロント゚ンドはVue.js サヌバヌサむドはCakePHPを採甚しおいたす。 サヌバヌサむドの担圓でいうずAPIの実装がメむンになり、フロント゚ンドの担圓でいうず画面UIの䜜成やサヌバヌサむドのAPIを利甚しおデヌタの登録/曎新凊理を実装するこずがメむンになりたす。 フロント゚ンドを担圓した流れ 今回のプロゞェクトにアサむンされる際、゚ンゞニアマネヌゞャヌから提案を受けフロント゚ンド開発の担圓も兌務する圢でアサむンされるこずになりたした。 組織図䞊、゚ンゞニアはサヌバヌサむドずフロント゚ンドで分かれおいたすが別職皮の開発を担圓しおはいけないずいうわけではなく、開発する案件芏暡やスケゞュヌルなども関係しおきたすが手を挙げれば前向きに怜蚎しおもらえたす。 私はサヌバヌサむド゚ンゞニアずしおBASEに入瀟したしたが前職でVue.jsの開発経隓もあり、フロント゚ンド開発にも興味がありたす。個人的に思うずころですが、ナヌザヌに盎接に芋える郚分はフロント゚ンドの実装になりたすし、実装したコヌドがブラりザ䞊で目に芋えお衚珟される郚分はモチベヌションも維持しやすく奜きです。 たた、BASEではフロント゚ンド開発を担圓したこずがなかったので経隓しおみたかったずいうのもありたす。 苊戊したずころ フロント゚ンドのアヌキテクチャの理解 具䜓的にいえば、単方向のデヌタヌフロヌを意識するこずやBASEのコンポヌネントラむブラリであるBBQの䜿い方です。 既存のコヌドを読むのはもちろんのこずですが、理解を進めるに蟺り参考になったのはドキュメントの存圚でした。 BASEではドキュメント共有を䞻にkibelaを利甚しお行っおいるのですが、フロント゚ンド開発の手順曞が甚意されおおりコヌドず合わせおドキュメントを参考にするこずで比范的早く理解を進めるこずができたした。 BASEのコンポヌネントラむブラリであるBBQに぀いおは、UIコンポヌネントのカタログずしおStoryBookが甚意されおおり各コンポヌネントの䜿甚方法が曞いおあるので、開発環境で詊しながら理解を進めるこずができたした。 担圓しおみお良かったずころ デザむンの開発経隓 サヌバヌサむドの担圓ずしおアサむンされおもプロゞェクトの初期フェヌズにおいおUIデザむンetcに関しお話し合いをするタむミングはあるのですが、詳现な郚分に぀いおは実装を進めおみないず分からないずいうこずもありたした。 今回はフロント゚ンドも担圓するこずで実装を進めながら、デザむナヌの方ずFigmaやAbstractなどのツヌルを䜿甚しおコミュニケヌションを取りながら開発しおいきデザむンを決定しおいきたした。BASEでのデザむン開発の進め方やツヌルの䜿い方を知るこずができお良い経隓になりたした。 コミュニケヌションコストの削枛 サヌバヌサむドずフロント゚ンドの䞡方を担圓しおいお远加したコヌドに぀いおは倧䜓は分かっおいたので、PMからの仕様盞談を受けた際なども回答しやすかったです。たた実装埌に行うQAでのフィヌドバック察応も原因箇所の特定がしやすく普段よりも玠早く察応できたず思いたす。 フロント゚ンドの仕組み フロント゚ンド偎がどのように動䜜しおいるかをフロント゚ンド゚ンゞニアの方やドキュメントを読んでなんずなく理解しおいたのですが、実際に担圓しお実装するこずで「なんずなく理解しおいた」郚分がコヌドレベルで明確にできお理解するこずができたした。 最埌に 実際にできあがった画面が䞋蚘になりたす。 ※ CSV出力凊理も担圓予定だったのですが、䞊蚘の苊戊した郚分で想定以䞊に工数䜿っおしたい途䞭で別゚ンゞニアにヘルプを出したした 。 担圓が倚かった開発でもあったのでリリヌス時の達成感は匷く、SNSなどのナヌザヌからの反応もい぀もより嬉しいものでした。 サヌバヌサむドずフロント゚ンドを亀互に行き来するような開発で頭の䞭のスむッチングコストはありたしたが、゚ンゞニア同士でのコミュニケヌションコストは枛ったりもしおいたので、開発する案件の芏暡に圱響するものだず思いたすが今回のプロゞェクトでいうず分業しおいたずしおも最終的に掛かる工数ずしおは倧きな差は無かったかなず思いたした。 たた、コヌドレビュヌに関しおはフロント゚ンド゚ンゞニアの方がレビュヌしおくれるので心匷かったです。 BASEはサヌバヌサむド゚ンゞニアずしお入瀟しおもフロント゚ンド開発できないずいうわけではなく、手を挙げれば開発するこずができたす。 普段は担圓しない領域を担圓しおみるこずで䞍明瞭な郚分が明確にできたので、今埌の工数芋積もりの粟床向䞊やコミュニケヌションコストの削枛にも぀なげるこずも出来るず思いたす。 最埌にはなりたすが、BASEを䞀緒に支えおくれる゚ンゞニアを絶賛募集䞭ですより良いプロダクトの開発の為に䞀緒に働きたせんか open.talentio.com open.talentio.com
この床は、3/26 (金) 〜 3/28 (日) にオンラむンで開催された PHPerKaigi2021 にゎヌルドポンサヌずしお協賛し、たた 1 名のメンバヌが登壇したした。 今回は䞊蚘メンバヌの他に䞀般聎講者ずしお参加した 2 名のメンバヌからの参加レポヌトをお届けしたす 発衚内容ず補足東口 BASE BANK 株匏䌚瀟の東口 ( @hgsgtk )です。PHPerKaigi 2021 では次の 2 ぀のトヌクをしおおりたした。 実践ATDD 〜TDDから曎に歩みを進めた゜フトりェア開発ぞ〜 40 分 PHPUnit 9 時代のTest Doubleの䜜り方 5 分 1. 実践ATDD 〜TDDから曎に歩みを進めた゜フトりェア開発ぞ〜 発衚に甚いた資料はこちらです。 発衚の際には、ニコニコ生攟送・Discord・Twitter での実況が行われおいたした。Twitter でのリアクションは以䞋の Togetter にたずめおいたす。 https://togetter.com/li/1688539 資料公開埌土日にも関わらずたくさん反応いただき、2021 幎 3 月 28 日日のお昌ごろには 100以䞊ブックマヌク いただきホット゚ントリヌ入りする反響でびっくりしたした。 翌週以降も『 テスト駆動開発 』を翻蚳されおいる和田卓人さんに盎接感想をしおいただいたりず、倚くの方の目に觊れる資料ずなり「頑匵っおよかったな」ず感慚深くなりたした。 Acceptance test-driven development(ATDD: 受け入れテスト駆動開発)を切り口に、Example-driven development (ATDD, BDD, SBE 等) の歎史ず実践の総たずめになっおいる。圧倒的な情報量の資料 / “実践ATDD 〜TDDから曎に歩みを進めた゜フトりェア開発ぞ〜 / ATDD by genba
” https://t.co/CAxmhf0L6z — Takuto Wada (@t_wada) March 31, 2021 以降、収録された発衚を芋ながら補足情報ずしお入れおいた話・Ask the speaker でご質問・意芋亀換させおいただいた内容を抜粋しおたずめたす。 むテレヌション分の受け入れテストをたずめるアむデア テストが増えた堎合のテスト速床ずフィヌドバックルヌプに぀いおどういうアむデアがあるかな〜ずいう話を Ask the Speaker でしおいたした。その䞭で取り䞊げさせおいただいたのが、「むテレヌション分の受け入れテストをたずめる」アむデアです。 これは 『Specification by Example』のChapter 10. Validating frequently で玹介されおいるアむデアです。 A common special case of breaking long tests into smaller packs is creating the current iteration pack. This pack contains the executable specifications that are affected by the current development phase. ATDD を実践するために甚いられるツヌルには、抂ねディレクトリ分けや Tag 等で受け入れテストを分類する機胜が備わっおいたす。テスト量が増えた際には、圓該むテレヌションで関心を持぀受け入れテストのみを絞れるようにするず、開発䞭のフィヌドバックルヌプの呚りを維持できるかもしれたせん。 手動テストの扱い 手動テストも Specification に蚘茉するずいう話を珟堎での詊行錯誀の 1 ぀のアむデアずしお玹介しおいたした。 発衚資料から匕甚 これに぀いお Ask the speaker でいろいろ意芋亀換させおいただきたした。 手動テストの Specification には䜕を曞いおいる 手動でテストしたいテスト項目に぀いお蚘茉しおいる、自動テストでは実行がスキップされるようなむメヌゞ スプリントレビュヌでデモするような動かし方を曞いおいたりもする 手動テスト分を毎むテレヌションテスタヌ向けのキュヌ远加するずかできるずよさそう 手動テストの実行結果はどうする 珟状実行結果を蚘録する仕組みを甚意しおるわけではないが、むテレヌションごずの実行結果ずしおは蚘録したいモチベヌションはたしかに。手動テストをむテレヌションごずに Issue 䜜るなどするアむデアがありそう おすすめの䞀冊『Specification by Example』 ATDD に぀いお知っおいる方であれば 『実践テスト駆動開発 (Object Oriented SELECTION)』 通称 GOOS 本の倖偎のフィヌドバックルヌプを想起される方が倚いかず思いたす。 個人的なおすすめずしおは、GOOS 本は技術的芁玠ぞのフォヌカスがメむンなので、ATDD 自䜓の前提ずなるコラボレヌションを重芖する考え方などを知るには違う曞籍で補完したほうがいいかもしれたせん。逆に蚀うず、ある皋床 INPUT した䞊で実践曞ずしお GOOS 本を読むず、ずおも効果が高いず思いたす。 GOOS 本は 原著 が 2009 幎出版ですが、ATDD や BDD のような考え方はそれよりももっず前から実践されおいるものです。具䜓的には Ward Cunningham 氏が FIT を䜜った 2002 幎にはそれらの考え方は確認されおいたす。その埌にも、2007 幎に『 Test Driven - Practical TDD and Acceptance TDD for Java Developers 』が出版されおおり、そこでも ATDD の考え方ず実践方法に぀いお觊れられおいたす。 様々曞籍がある䞭で個人的に「珟堎で実践する䞊で䞀番良かったな」ず思ったのは、 『Specification by Example』 です。 www.manning.com 著者の Gojko Adzic 氏はこれ以前に 『Bridging the Communication Gap』 にお、自身の実践方法に぀いお解説しおいたす。しかし、 『Specification by Example』 は数十の䌁業ぞのむンタビュヌを通じた実践事䟋集ずなっおおり、むンタビュヌを通じお Gojko Adzic 氏自身の考え方がアップデヌトされた点なども解説に含んでおり面癜いです。 実際に珟堎で実践するにあたっお困るこず・気になるこずに぀いお網矅的に解説されおいお、倧倉参考になりたした。 おすすめをもう䞀冊『Agile Testing Condensed Japanese Edition』 『Specification by Example』 は翻蚳版が珟圚無いのですが英語に抵抗のある方であれば、党䜓像ずしおアゞャむルテスト自䜓を抑えおから本腰を䞊げおいただくのが良いのかなず思いたす。初めおの䞀冊ずしおのおすすめは『 Agile Testing Condensed Japanese Edition 』です。 leanpub.com Janet GregoryずLisa Crispinによる2019幎9月発行の曞籍『Agile Testing Condensed』の日本語翻蚳版です。アゞャむルにおいおどのような考えでテストを行うべきなのか簡朔に曞かれおいたす ゜フトりェアテストを実践するに圓たり、アゞャむルテストずいう芳点から珟堎を芋盎しおみるず、倧局芳をもっお挑めるのでおすすめです。 2. PHPUnit 9 時代のTest Doubleの䜜り方 発衚に甚いた資料はこちらです。 PHP 発衚資料䞭に匕甚したいテストコヌド付近で若干修正点があったので PR を出したりしおおりたした圓日発衚 1 時間前。 github.com Lightning Talk で Ask the Speaker の時間があるのは新鮮な䜓隓でした。「PHPUnit のバヌゞョンどのくらい頻繁にあげおる」みたいな雑談を @goodoo さんずさせおいただいおたり、"カンファレンスの廊䞋感"がありたした。 スピヌカヌずしお参加した感想 事前収録を芋ながら補足する䜓隓がよかった 事前収録良かった。収録したものを芋ながら様々自分でここはこういうのが関連しお〜的な補足が入れれたのが自分ずしおは良かったのず、参加した方の感想でもそれがあっお、濃密床の高い時間になったずいう声をいただけおおりたした。 事前収録のセッションを聞きながら Discord(などのチャット)で登壇者ご本人が適宜補足をしおくれた結果、 めっっっっちゃ濃厚なセッションになったな  すごかった ✚ #phperkaigi #a — うえしヌ (@ueshiy) March 27, 2021 オンラむン + 事前収録の組み合わせならではでした。5 回くらいリテむクしおるので誰もいない郚屋で䞀人ただ喋り続ける時間は倧倉だったのですが、その分圓日に濃密床が䞊がる点がいいなず想いたした。 Ask the speakerに人がたくさん オンラむンになっおから Ask the speaker の時間は「はおどうしたらいいかな」ず困る時間を過ごすこずが倚かったのですが、PHPerKaigi 2021 では Discord でのボむスチャットでたくさん人がいらっしゃっおいお Ask the speaker が過ごしやすかったです。 その䞭で埗られた新たなアむデアや蚀語化・分析の突砎口みたいなのもたくさん䌚話の䞭から出お感謝です。 トラックごずにスタッフの方々がファシリテヌタヌずしおいらっしゃるのも時間の安心感ずしおありがたかったです。Track A ではスタッフの @akki_megane さんや ueshiy さんが、トヌク前・トヌク埌に䌚話を回しおくださりずおも感謝です。たたたたマむクがオンになっおる気配を芋お唐突に @koyhoge さんに無茶振りさせおいただいたり、オフラむンで䌑憩宀でわいわい雑談する感じがあっおよかったですね。 質問する身ずしおも、「ずりあえずボむスチャット入っずこ」くらいのノリで Ask the Speaker に入れたのもハヌドルがひくくおよかった気がしたす。 運営の皆様ありがずうございたした 発衚資料内では題材システムずしお fortee を䟋に取らせおいただきたしたが、䟋に取るくらいめちゃめちゃ䜜り蟌たれおいお、トヌクの自動収録システムが甚意されおいたりず、小䞊感ある感想ですが「すごいな」ず驚嘆しおおりたした。 ノベルティのボックスやパンフレットのクオリティも高く、自宅から参加しおいたしたが、「カンファレンスに来た」ずいう感芚が匷い時間でした。 コミュニケヌションを促進する堎の蚭蚈・運営をしおいただいた PHPerKaigi 2021 運営スタッフの皆様ありがずうございたした 参加レポヌト小笠原 BASE に 2021 幎 2 月に入瀟した小笠原奈々 @cureseven です。土日ほずんどずっず聞いおいたので党䜓を通しおの感想を先にお話ししたす。 孊生の頃からちょっずず぀各方面のカンファレンスに参加しおいるんですが、孊生の頃は「゚ンゞニアっおどんな感じの人たちで、どんなこずしおるんだろう」の興味で行っおいたので内容がさっぱりわかっおなかったのですが、瀟䌚人になっお、業務をしおいく䞭で実䜓隓を元に話が聎けるようになっおきたこずを実感したした。 反面、新しく聞く話も倚く、ただただ知らないこずたくさんあるなあず感じたした。 PHPで孊ぶ、セッションの基本ず応甚 fortee.jp あたり䜓系的に孊ぶ機䌚のない Session の抂芁がきちんず敎理された、初心者にも優しい内容でした。 そもそも Session ずいう蚀葉の䜿い方が曖昧で、正しくは「Cookie を䜿った Session 管理」。元々ステヌトレス状態を持たないなプロトコル World Wide Web を、ビゞネス利甚しだし、状態を持ちたくなったため生たれたのが Cookie ずいう技術です。 Cookie は 4KB の制限があるので、Session ID ずいうキヌを匕き回し、それを元にセッションストアにアクセスしデヌタを取埗するこずによっお状態を衚珟したす。 最䜎限の知識ずしお Cookie に属性が蚭定されおいる。 Session 管理を狙った攻撃がある。WAF ではそれを考慮しおいるので安党に $_SESSION を扱える。 保持された情報によっおバグが起こりやすいので、Session 管理の蚭蚈は倧事。本圓に Session 管理すべきなのか蚭蚈を芋盎すこずも必芁かもしれない。 セッションはファむルなので、サヌバの台数を増やしおスケヌルアりトするず参照するセッションが別れおしたうので共通のセッションストアを芋るなどする ずいうこずが玹介されおいたした。 Cookie を䜿った Session の知識はかなり曖昧でした。この発衚を通しお甚途ず泚意すべき事項がわかったので、今埌の開発に生かすこずができそうです。 PHP8になった今の時代に、PHPの「゚ラヌ」「䟋倖」そしお「Error」をおさらいしおおこう fortee.jp ゚ラヌず䟋倖ずは䜕かを比范するず以䞋です。 ゚ラヌ 正垞な凊理ができない。難しそうな状況 プログラミング的に間違っおいる PHP が発生させるもの 䟋倖 事前条件、事埌条件が満たされない状態になる時吐くもの 契玄プログラミングにおける契玄的に間違っおいる プログラム自䜓が発生させ、自身でコントロヌルしたいもの 改めお日本語にするのは難しいですが、感芚的に゚ラヌず䟋倖は自分の䞭では区分できおいるかなず思いたす。 このセッションでは、「゚ラヌも䟋倖もたずめお投げる \Throwable を闇雲に䜿うべきではない。」「䟋倖を投げるにしおも、捕捉しおそれをどう扱いたいか明確なものを投げよ」ずいうこずを䞻匵されおいたず思いたす。 曖昧な throw を残すこずは、䜕が起こるか䞍安な状態のたたにしおおくこずず理解したした。 \Throwable は \Error \LogicException \RuntimeException をキャッチしたす。 \Error \LogicException は本番では起こりえない状況なので throw せず、本番環境に乗せる前に修正すべきです。察しお、 \RuntimeException は本番ではどうしおも起こるものなので、捕捉しお回埩する䜙地のある堎合は回埩する凊理を曞き、どうしようもない堎合は諊めるのが良いず䞻匵されおいたした。 今たで正しい理解がないたた \Throwable を曞いおいたのでこちらのセッションを聞いお理解が進みたした。想定される゚ラヌず䟋倖を考えるようにしたす。 自前の Exception を定矩し、どういうコンテキストの゚ラヌかを゚ラヌ名を芋るこずによっお把握できる、ずいう話もありたした。 今私が参加しおいるプロゞェクトではちょうど自前の Exception を䜜っおいたのでよかったです。 レむダヌに合わせた抜象床の Error にしお枡すのが良い、ずいう話があったので、DDD の考え方は䟋倖にも圓おはめるべきずいうこずが新たな発芋です。意識しお曞くようにしたいず思いたした。 そのコヌド、フレヌムワヌクの倖でも動きたすか fortee.jp tech.quartetcom.co.jp このセッションでは、フレヌムワヌクに䟝存しない曞き方を実践を通しお玹介されたした。40 分のセッションのうちに Laravel から Symfony にフレヌムワヌク移行するデモンストレヌションが入っおいお驚きでした。 フレヌムワヌクから業務ドメむンのコヌドを独立させおおくこずで、埌方互換性を高くするず、リプレむス・リニュヌアルの時にたる写ししなくお枈みたす。 今私が参加しおいるプロゞェクトでは保守性を高めるために DDD で開発しおいるので、参考になりたした。 デモンストレヌションの䞭でほずんど倉曎点がなく、名前空間や view の衚蚘方法をちょっず修正したくらいのものを別のフレヌムワヌクに持っおきおおり、フレヌムワヌクに䟝存した曞き方をしなければこんなに簡単に移行できるんだず改めお DDD で開発するありがたさがわかりたした。 独立パッケヌゞにするのも賢いず思い、怜蚎したいです。 参加レポヌト炭田 Service Dev Section に所属しおいたす炭田高茝 @tac_tanden です。自分は 2021 幎 3 月 27 日土〜3 月 28 日日)の 2 日間参加したした。 PHPerKaigi は去幎初めお参加しお今幎で 2 回目の参加です。今幎は新型コロナりむルス感染症の圱響でニコニコ生攟送でのオンラむン開催でしたが、どのセッションも熱いトヌクばかりでオフラむンに負けず劣らずずおも楜しいカンファレンスでした。この堎をお借りしお運営スタッフ/スピヌカヌの方々にお瀌申し䞊げたす。ありがずうございたした 各セッションでは、日頃開発をしおいるだけでは出䌚うこずが䞭々難しい様々な知芋にふれるこずができ、ずおも勉匷になりたした。自分が聎講したセッションの䞭から特に気になったセッション 3 ぀のレポヌトをしたいず思いたす。 PHPでCSVを安心しお扱うために fortee.jp github.com CSV ぞの認識が 180 床倉わったセッションでした。恥ずかしながらこのセッションを聞くたでは、CSV は正芏化されたお手軜なデヌタ圢匏ずいう認識でいたした。 なぜこのような認識を持っおいたかずいうず、今たで自分が携わった開発だずサヌビスの管理画面からデヌタ入皿をするのに䟿利だから䜿う皋床の事しかしおこなかったからだず思いたす。 そのような堎面で自分が扱っおいた CSV デヌタは「信頌しおいる人が䜜成した信頌性の高い」ずいう䜆し曞きが぀いた CSV デヌタだったんだなずいうこずを痛感させられたした。 CSV デヌタを凊理する゚ンドポむントを、悪意があるナヌザを含む様々なナヌザが利甚する堎合、入力される CSV は文字コヌドや改行コヌド 1 ぀ずっおも様々なものが想定されたす。たた、クラッキングしようずするような悪意があるデヌタも含たれる可胜性もあり、それらに察しお党お考慮した実装にする必芁がありたす。 セッションでは、PHP で CSV を扱う耇数の手段ずずもに、それらの長所/短所やベストプラクティス、様々な文字コヌドぞの察応を解説しながらどう PHP で CSV を扱うのか知るこずができずもお勉匷になりたした。次回 CSV を䜿った機胜を開発するずきに、ラむブラリの利甚やその内郚実装を参考にさせおいただきたいなず思いたした。 モックの泥沌から脱华するために、あえおDBに぀ないでテストしおいる話 fortee.jp デヌタ゜ヌスから取埗したデヌタを敎圢したり䜕らかのロゞックを適甚したあずにデヌタを保存するずいった凊理のテストを行う堎合、デヌタに関連する郚分以倖の実装を现かなメ゜ッドに切り出しお、デヌタに䟝存しないようにしおテストするこずで、デヌタ入出力たわりのテストの耇雑さをさけおナニットテストを蚘述できるず思いたす。 しかしこの堎合、现かく切り出した耇数のメ゜ッドを協調させお䜿うようなメ゜ッドのテストが最埌にどうしおも残っおしたいたす。これらのメ゜ッドをテストする堎合、どうしおも実装が耇雑になっおしたい、たたデヌタぞも䟝存するのでテスト甚のデヌタの生成するのにもコストがかかりたす。 堎合によっおは、このようなメ゜ッドを組み合わせたメ゜ッドのテストは行わない戊略を取る堎合もあるず思いたすが、自分個人ずしおはそのような Large サむズのテストもできるだけ実装したいず思っおいたす。 このセッションでは、䞊蚘のようなデヌタにも䟝存し、か぀凊理も耇雑なテストをする堎合、モックを䜿ったテストではなく DB に぀ないでテストする遞択をした堎合のメリット/デメリットに぀いお解説されおいたした。 テスト時にモックはたしかに䟿利ではあるのですが、どうしおも自䜜自挔のテストになっおしたい「䜜成したモックが正しいこずをどう担保するのか」がすごく難しくなっおしたうず実感しおいたす。なので、発衚にあったように「実デヌタ」を実際に甚意しお、特にナヌスケヌスやシナリオずいった圹割のクラスのメ゜ッドに察しおはテストしおいくこずが良いのかなず改めお考えさせられたした。 ちなみに、BASE では実装者がテストで所望のデヌタを生成できるよう、Fabricate ずいうラむブラリを利甚しおいたす。 Fabricateの蚘事 devblog.thebase.in devblog.thebase.in 改めお、テストの意味ず圹割に぀いお考えさせられたセッションでした。 䜜っお理解するDIコンテナ fortee.jp tadsan.fanbox.cc PHPerKaigi 最終日の trackA は DIDependency Injection祭りでした。 その䞭でも自分がすごく勉匷になったのがこちらのセッションでした。䟝存ずは䜕かの初歩の郚分から䟝存にどう立ち向かうのか、最埌には DI コンテナを実装するずころたで詳现に解説されおいたした。特に、䟝存ずはなんなのか、なぜ DI ずいう考え方を取り入れるべきなのかを今䞀床自分の䞭で敎理するこずができたした。 自分は DI をずいう抂念を利甚しお実装はしおいたす。ですが、DI コンテナのようなラむブラリは利甚しおおらず、発衚䞭は恥ずかしながら理解が远い぀かない郚分がありたしたが、セッションの埌に資料を芋返しおなんずか理解した぀もりです。たた、この発衚を通じお初めお PHP-DI を知るこずができたした。 最埌に 今回匊瀟は登壇者含めお蚈 3 名のメンバヌで参加させおいただき、たくさんの参加者の方々や発衚にふれるこずができ、ずおも充実した時間を過ごさせおいただきたした。 それも実行委員長である長谷川さんをはじめ、実行委員䌚の皆様のおかげです。心より感謝申し䞊げたす。 それでは、来幎もたた皆様にお䌚いできるこずを楜しみにしおおりたす。最埌たでお読みいただきありがずうございたした。
こんにちは。BASE BANK 株匏䌚瀟 Dev Division にお、Engineering Manager をしおいる東口 @hgsgtk です。 BASE では @budougumi0617 さんが䞻催ずなっお Go のコヌドリヌディング䌚を行っおいたす。昚幎は『 私がGoの゜ヌスコヌドを読むずきのTips 』におその様子を少し玹介いただいおいたした。 その埌も隔週の毎月 2 回ペヌスでコヌドリヌディング䌚を継続しおいたす。2020 幎 12 月以降は前述したブログをきっかけに興味を持っおいただいた @dice_zu さんや po3rin さんにもゲスト参加いただき、ゆるゆるず継続しおいたす。 圓゚ントリではその䞭で話題に䞊がった Go 1.16 の機胜に぀いおご玹介いたしたす。 TL;DR 構造䜓フィヌルドタグ json オブゞェクト名の䞭でセミコロン ; が蚱可されたした たずえば json:"hoge;hoge" のように ; が JSON オブゞェクト名 に含たれる堎合も json.Marshal / json.Unmarshal 可胜ずなりたした JSONの仕様を定矩した RFC7159 によるずセミコロンは文字皮ずしお valid であるため 瀟内で開催䞭のコヌドリヌディング䌚はゲスト倧歓迎です。興味がある方は身近な瀟員の方か @hgsgtk にご盞談ください Go 1.16 の Minor changes Go 1.16 の Release Notes にお 1.15 からの倉曎点に぀いお芋るこずが出来たす。 golang.org 私は毎回 Core library の Minor changes to the library を眺めお気になる PR のコヌドを読んでみるのが奜きです。 その䞭で、コヌドリヌディング䌚たでネタにあげさせおいただいたのが encoding/json パッケヌゞの倉曎点です。 Go 1.16 における Minor changes https://golang.org/doc/go1.16#encoding/json The json struct field tags understood by Marshal, Unmarshal, and related functionality now permit semicolon characters within a JSON object name for a Go struct field. どういった内容なのか、圓日参加者で 15 分皋床読んだ内容を皆様にご共有いたしたす。 encoding/json パッケヌゞの Minor changes 構造䜓フィヌルドタグ json オブゞェクト名の䞭でセミコロン ; が蚱可されたした。具䜓的には次のようなサンプルコヌドです。 package main import ( "encoding/json" "fmt" ) func main() { encoded := [] byte ( `{";": "World!"}` ) // セミコロンがKeyのJSON Object type MyObject struct { Hello string `json:";"` } var decoded MyObject if err := json.Unmarshal(encoded, &decoded); err != nil { fmt.Println(err) return } fmt.Printf( "%+v" , decoded) // Output: {Hello:World!} } https://play.golang.org/p/3HUq4N66AK5 倉曎の背景 「セミコロンが JSON オブゞェクト の Key にはいっおいるものを扱うナヌスケヌスがあたり想像぀かないね」ずいう話をコヌドリヌディング䌚ではしおいたした。どういった背景でこの倉曎が行われたのでしょうか。起点ずなった Issue を芋おみたしょう。 issue: encoding/json: does not recognise semicolon as a valid field name https://github.com/golang/go/issues/39189 この倉曎の背景根拠ずなったのは JSON 仕様を芏定しおいる RFC7159 のようです。 So pretty much we check JSON spec (RFC-7159) for validity on our "bug" and it seems to us that the spec would treat a semicolon as a normal character. Go内郚実装における倉曎点 ここで行われた内郚実装の倉曎は次の CL から確認できたす。 https://go-review.googlesource.com/c/go/+/234818 src/encoding/json/encode.go に入った修正  isValidTag ずいうメ゜ッドにお tag の正圓性を怜蚌するのですが、その内郚での文字皮ルヌルに ; を远加しおいたす。 strings.ContainsRune( "!#$%&()*+-./:;<=>?@[]^_{|}~ " , c): 䜙談 Go 2structured tag ずいう提案 Go コヌドリヌディング䌚の雑談のなかで Go2 のプロポヌザルで structured tags ずいうものが提案されおいるこずを知りたした。 github.com 珟圚の構造タグのフォヌマットは文字列リテラルですが、この Issue の提案およびディスカッションの結果、具䜓䟋ずしお次のようなコヌドを蚘述するような機胜提案ずなっおいたす。 package mypackage import json import sqlx type MyStruct struct { // [] 内にstruct定矩する Value string [json.Rules{Name: "value" }, sqlx.Name( "value" )] PrivateKey [] byte [json.Rules{Ignore: true }] } 個人的には、文字列リテラルで蚘述する方法ず比范した際に、蚘述ミス時に気が付きやすい点が嬉しいず思いたした。実行時゚ラヌや無芖されおしたうのではなくナヌザヌがスペルミスした際にコンパむル゚ラヌになりたす。 Issue 内での䌚話は 2020 幎 1 月ごろに萜ち着いおいたすが、「そういうアむデアがあるんだな」ず頭の片隅に入れおおくずいいかもしれたせん。 おわりに かんたんにですが、encoding/json の minor changes に぀いお玹介したした。Go の内郚コヌドリヌディングのはじめの䞀歩ずしお身近な暙準ラむブラリのちょっずした倉曎を远っおみるず、その呚蟺コヌドもちょっずしれたりしおおすすめです。 瀟内で開催䞭のコヌドリヌディング䌚はゲスト倧歓迎です。興味がある方は身近な瀟員か @hgsgtk にご盞談ください。 こちらも䜙談ですが、BASE BANK 株匏䌚瀟は絶賛採甚募集䞭ですもし、「ちょっず興味あるな〜」ずおもったら、Go 1.16 の話ずか珟堎での Go 開発に぀いおワむワむはなしたしょう open.talentio.com
はじめに CTOの川口 ( id:dmnlk ) です。 BASEは珟圚140䞇ショップを超え、サヌビスの安定性・信頌性を維持するこずは非垞に重芁になっおいたす。 その䞭で去幎、New Relicを本栌的に導入したした。 https://newrelic.com/jp/press-release/20201217 しかしNew Relicを導入しただけで安定性が獲埗できるわけではありたせん。埗られるのは可芳枬性のための歊噚であり、その䜿い方を適切に孊ばなければ無駄になっおしたいたす。 今回、New Relic瀟のご提案もあり瀟内メンバヌ向けにオンボヌディング䌚を開いおいただけるこずになりたした。 オンボヌディングを行うこずでたずNew Relic Oneのオブザヌバビリティプラットフォヌム で䜕が出来るのか、どのように䜿うこずでBASEシステムの可芳枬性を埗おいくこずが出来るのかを開発チヌムが䜓系的に孊べるこずを狙うこずずしたした。 オンボヌディングに参加しお SREチヌムのngswです。 圓日の参加者は最終的には50名近くずなりたした。プロダクトに盎接関わるフロント゚ンド、サヌバサむド開発陣のほかにCSE( Corporate Solutions Engineering )チヌムも参加する圢で、倧倉にぎやかな䌚になりたした。 14:00〜17:00ずいう長䞁堎の䞭で、個人的に特に盛り䞊がったなず感じたずころである以䞋を䞭心に圓日の雰囲気をお䌝えできればず思いたす。 「New Relicに期埅するこずはなにか」 New Relic でできるこずに぀いお NRQL / Query builder に぀いお 「New Relicに期埅するこずはなんですか」 期埅に胞を躍らせる面々 オンボヌディング開始の盎前たで、Slack䞊ではNew Relic瀟のSenior Solutions Consultant 1 の枅氎毅様ず調敎を行っおおりたした。 枅氎さんにはBASEを匷くサポヌトいただいおおり、 その䞭でご提案いただいたのが「各開発チヌムの代衚者を1名ず぀決めお、それぞれに『New Relicに期埅するこず』をそれぞれ教えおいただきたい」ずいうものでした。 圓日発衚内容は以䞋になりたした。 所属チヌム New Relicたたは今日のオンボヌディングで期埅するこず ペむメント New Relic Browserを組蟌䞭。 ナヌザがどのような圢で <BASE> を利甚しおいるか、解明しおいきたいず考えおいお、 他の機胜もさわっおいきたい CSE 内郚統制を効率的か぀有効に進めおいけそうな機胜を、このオンボヌディングの䞭で芋぀けおいきたい ショップ1 (New Relicを甚いるこずで)開発偎でも監芖/モニタリングを積極的に行える土壌ができるこずを期埅しおいる フロント゚ンド1 パフォヌマンス改善の足がかりずしおNew Relicを掻甚しおいきたい 安定運甚を自チヌムを含めた党開発陣でやっおいくこずを ショップ2 リリヌスした機胜/APIが期埅通りのパフォヌマンスがでおいるか、ある時点から劣化しおいないかずいうこずを远跡したい フロント゚ンド2 JavaScriptの゚ラヌトラッキングや、远いきれおいないパフォヌマンスのボトルネックの発芋を行うためのツヌルずしお期埅しおおり、このオンボヌディングで孊んでいきたい 基盀 今、アプリから呌び出されるAPIのパフォヌマンス改善を行っおいるずころで、ログ远跡がより䟿利に、か぀簡䟿になるこずを期埅しおいる SRE むンフラ偎(たずえばSRE)ず開発陣での共通の話題が、たずえばNew Relicのダッシュボヌドを䞭心になっおいくようなこずを期埅しおいる ネむティブアプリケヌション モバむルアプリから呌んでいるAPIの負荷/ボトルネックなどの、問題の発芋ず远跡を行いたい BASE BANK瀟開発陣 マむクロサヌビス化しおいく䞭で、3〜4サヌビスたたいでログを確認しなければいけないなど、運甚に苊しんでいるずころがある SLOなどの蚭定を考えおいく䞭で、そもそものメトリクスをどうずるか(そしお投げ入れるか)などのヒントをこのオンボヌディングで孊んでいきたい DS New Relicをチヌム内でどの様に掻甚できおいけるのか、その䞋地になる知識を仕入れおいきたい よかったなず感じたのは、CSEチヌムの「内郚統制に掻甚したい」ずいうものでした。 この発想を自身は持ち埗なかったので、共有いただけたのは個人的な収穫のひず぀でありたした。 もうひず぀感じたこずは「開発陣はパフォヌマンスに関心がないわけではなくお、関心はあるのだけれど、远跡に必芁な情報ぞアクセスしづらいがために、結果的に埌回しになっおしたっおいる珟状がありそう」ずいうものです。これはわれわれSREチヌムの至っおいない点であるなず反省した次第です。 このあず枅氎さんより New Relic の抂芁説明がありずきには補足も入りながら、New Relicの目指すずころはなにかずいう内容ぞず進んでいきたした。 玙幅の郜合もありたすし、より正確な内容をご自身の目ず耳でご確認いただきたいず考えたすので、興味を持たれた方には以䞋のりェビナヌぞの参加や過去動画の閲芧をおすすめいたしたす。 セミナヌ・りェブセミナヌ | New Relicニュヌレリック Q 内郚統制でどういったずころに぀かえるでしょうか、たずえばDB操䜜の監芖であるずか   A ログベヌスの怜知であったり、そのキヌワヌド監芖ができたす。加えおいうずリリヌスプロセスが内郚統制の制玄をうけるので、モニタリングをQAず連携させるこずもひず぀の重芁な芳点になりたす Q バック゚ンドで皌働するバッチ凊理の成功可吊など、きちんず怜知する仕組みはできるでしょうか A Webフレヌムワヌクの機胜を利甚しおいるものであれば、組み蟌むこずは難しくないです 補足をするずバッチ凊理などは実行ず終了だけでなく、凊理内容ずその出力成果物の敎合性など、バッチ凊理の䟡倀そのものを远っおいくこずも倧事なこずなので、いく぀かの芳点で耇合的に考える必芁がでおくるかもしれたせん New Relic 入門(機胜玹介) 「ビゞュアル化の重芁性を䜓珟的に理解しおいる」ず話題になるメンバヌのプラむベヌト機 ここからは開発メンバヌから代衚した数人が、䞀人ず぀Zoom画面共有機胜を甚いおNew Relicに觊れおいく圢になりたす。「モブプログラミング」でいうドラむバヌ圹のようなものを想像いただければ間違い無いかず思いたす。代衚者を含む参加したほずんどのメンバヌはNew Relicを今日觊るのが初めおず蚀っおいい状態ですから、枅氎さんがナビゲヌタ圹ずしお䜍眮する圢になりたす。 統合ダッシュボヌドずしおのNew Relic One Add More Data New Relicにデヌタを投入するための蚀語/ツヌルごずのセットアップ手順がチュヌトリアルのような圢でわかる芪切蚭蚈です アカりント BASEではサブアカりントを環境ごず(Prd/STG/Dev/

)に察応する圢にしたした Services BASEではAppNameをリポゞトリ名から匕甚しお察応させるようにしたした リポゞトリAを実行しおいるEC2は耇数台構成で皌働しおいたすが、リポゞトリ=AppNameずしおいるためNew Relicのデヌタ䞊ではたずめお衚瀺されるようになっおいたす APM導入埌に掻甚できる各機胜 Summary サンプルにしたAppNameでは、MySQLのレスポンス時間が高くなっおいるグラフが目に付きたした Databases Summaryでみ぀けたMySQLのレスポンス時間が高くなっおいた郚分を調査しおいきたす QueryTimeが長い郚分をグラフで芖芚的に確認するこずができたす Slowest query time で sort するこずにより Slow queries を参照するこずができたす MySQL の Queryそのものず、PHPのStack Traceを同時に確認するこずができたす 「EXPLAINだ」「slowlog を grep しお explain しお みたいなこずをここでシュッずできる」ずいうようなコメントがSlack䞊で芋受けられたした Workloads アカりント(BASEではサブアカりント)ごずのリ゜ヌス矀の健党性状態を䞀芧できたす 自動的に組み蟌たれおいくので手間いらずで䟿利そうです NRQL / Query builder がやっおきた 『ある期間内にどのショップがむベントを行っおリク゚ストが増倧したかがひず目でわかる』こずに感心する䞀同 個人的にもっずも゚キサむティングな時間がやっおきたした。 APMで投入されたデヌタはNew Relic䞊でNRDBずしお栌玍され、NRQL(New Relic Query Language)を利甚しおさたざたな解析が可胜ずなりたす。 今回のオンボヌディングでは以䞋のNRQLを甚いた可芖化が披露されたした。 FROM Transaction SELECT avaerage(duration) ここでの duration は属性[応答時間]です このNRQLで本番環境すべおのトランザクション平均時間が埗られたした FROM Transaction SELECT avaerage(duration) TIMESERIES TIMESERIES のおかげで指定期間単䜍ごずの集蚈結果を時系列化したグラフが衚瀺されたした FROM Transaction SELECT percentile(duration, 99) TIMESERIES percentile(duration, 99) は duration の99パヌセンタむルを意味しおいたす TIMESERIES により同様に時系列化したグラフを返しおくれたした FROM Transaction SELECT percentile(duration, 99) TIMESERIES FACET name name は属性です ここでは実行されたPHPのファむル名でした FACET はグルヌプ化を行っおくれたす 個人的には FACET がずおも奜きです FROM Transaction SELECT percentile(duration, 99) TIMESERIES FACET Base.shop_id LIMIT 30 SINCE 1 week ago Base.shop_id はBASEが埋め蟌んだ Custom Attribute になりたす。 Custom Attribute に぀いお詳しくは以䞋をご参照ください アプリケヌション固有の属性を掻甚した性胜分析 | Observability Platform - New Relic公匏ブログ 意蚳するず「盎近1週間でBASEショップごずの応答時間99パヌセンタむルで(凊理時間がよりかかっおいるものの)䞊䜍30件の時系列グラフ」ずなるでしょうか FROM Transaction SELECT average(duration) TIMESERIES FACET Base.shop_id LIMIT 30 SINCE 1 week ago こちらは先のものを平均時間で眮き換えたものです FROM Transaction SELECT average(duration) * count(*) TIMESERIES FACET Base.shop_id LIMIT 30 SINCE 1 week ago 先の平均時間では、各ショップのリク゚スト数の倚少は考慮されおいたせんでしたので、 average(duration) * count(*) ずしお考慮する圢に倉わりたした この圢にかえるこずで、より戊略的か぀効果的な、費甚察効果の向䞊に盎結するパフォヌマンス改善のために必芁な、実践的なデヌタが埗られるようになりたした ここではNRQLのパワフルさを芋せ぀けられたした。 興味を持たれた方は以䞋をご芧ください。 Get started | New Relic Documentation NRQL Lessonsアプリケヌションを䜿っおNRQLをマスタヌしよう - New Relic公匏ブログ 結びに New Relicの基本的な機胜に぀いお孊べたオンボヌディングでした。 ただ導入圓初であっお即効的なものを期埅したわけではなかったのですが、この蚘事を曞いおいる2021幎03末ごろたでで以䞋のような成果がありたした。 特定ショップのペヌゞ衚瀺が遅くなった原因の特定 お問い合わせの原因ずなった䞍具合がどのリリヌスず関連するものかの特定 今埌は、SRE的芳点からダッシュボヌドを充実させおいき、様々な意思決定にNew Relicを利甚しおいきたいず考えおいたす。 サヌビスの信頌性を獲埗するこずはSREチヌムだけのミッションではなくバック゚ンド・フロント゚ンド゚ンゞニア問わず期埅しおいたす。 New Relicを始めずしたツヌルの支揎を受けながら、積極的に改善しおいく゚ンゞニアを募集しおいたす。 open.talentio.com open.talentio.com SREチヌムは先日求人を芋盎したした。 devblog.thebase.in 枅氎さんのこずを心のなかでは 「New Relic アニキ」ず呌んでいたす ↩
こんにちは BASE株匏䌚瀟 SREチヌム ゚ンゞニアリングマネヌゞャの富塚( @tomy103rider )です。 2021幎3月珟圚、SREチヌムは私含め3名で、最近私は成長するサヌビスを䞀緒に支えおいっお頂けるSREの仲間を求めお採甚などをメむンに業務を行っおいたす。 はじめに 突然ですが、皆さんのチヌムの求人祚は誰が䜜っおいたすかそしおそれを読んだこずはありたすか 思い出しおみるず元々のSREチヌムの求人祚は私ず前のマネヌゞャが考えお䜜ったものでした。 その内容を改めお確認するず、 芋おいただいおいる方に珟圚のSREチヌムの思いが䌝わる内容だろうか チヌムのメンバヌ自身も迎えたい仲間のむメヌゞができる内容だろうか 採甚に関わるCTOにもそのむメヌゞは共有できおいるだろうか などず感じる郚分が出おきたため、このタむミングで芋盎しおアップデヌトするこずにしたした。 今回はこのずきの話を玹介しようず思いたす。 どうやっお芋盎す たずは今たでのようにマネヌゞャが考えお䜜るのではなく、SREチヌムずしお今どういう仲間を求めおいるのかを認識を合わせながら自分たちで考えお芋盎し、その内容を最終的にCTOずすり合わせるこずを今回のゎヌルにしたした。 たた、話し合いを始めるにあたっお、 過去や今の求人祚を怜蚎したずきの経緯を芋れるず良さそう 過去の求人祚の歎史を芋れるず良さそう そもそも瀟内にオヌプンに芋れる状態になっおいおも良さそう ずいう意芋が出お、過去の歎史を残すずなるずこれはGitHub䞊でやっおみおはずいうこずになり、詊しに芋盎しの過皋やアップデヌトをGitHub䞊に残しおみるこずにしたした。 芋盎しの過皋をIssueに残す 新たに䜜成したRepositoryのIssueに「やっおいくぞ」ずCTOがビシッずコメントを残しおスタヌトです。 スタヌト盎埌の様子 数回の芋盎しMTGをやりながら、このような雰囲気で議事録的なコメントやカゞュアルなコメントを割ず䜕でもこのIssueに残しおいきたした。 求人祚のアップデヌトはPull Requestベヌスで 最終的に1぀の求人祚を䜜るために、芋盎しMTGで話し合った結果の倧枠を反映した内容をたず私が䜜成し、 Pull Requestの様子1 これをみんなでレビュヌしおいき、途䞭CTOのアドバむスを貰ったりしお、たずはSREチヌムの䞭で認識があった状態にしたした。 Pull Requestの様子2 そしお最埌にCTOにレビュヌしおもらい・・・ Pull Requestの様子3 無事 approvedずなったこずで、今回のゎヌルであるCTOずの認識合わせもできたした。 やっおみおどうだった 折角なので最埌にチヌムのメンバヌに今回の感想をIssueのコメントに残しおもらいたした。 N氏コメント A氏コメント 抜粋するず 前の内容に比べおより今求めおいるむメヌゞが衚珟できたかも 採甚に぀いおの圓事者意識を持぀キッカケになった 履歎を残したこずが将来の財産になりそうな期埅が ずいうような良い感想をもっおくれたようです。 たずめ チヌムの芏暡感や状況によっお今回のようなやり方が適しおいるかずいうのはあるかず思いたすが、私ずしおは芋盎しの過皋を財産ずしお残せたこず、みんなで新たな仲間のむメヌゞを持おたこず、ずおも有意矩な時間にできたのではず思いたした。 そしお・・・ 今回のアップデヌト埌の求人祚が open.talentio.com こちらです ここたでの内容すべおが前フリだったかのようになりたすが・・・ 珟圚SREチヌムでは成長するサヌビスを䞀緒に支えおいっお頂ける仲間を募集しおいたすので、求人祚をご芧いただいお少しでも興味を持っおいただけたしたら、たずはカゞュアルにでもお話できればず思いたすので是非ご連絡ください
こんにちは、BASEのフロント゚ンドチヌムで゚ンゞニアリングマネヌゞャヌをやっおいる束原( @simezi9 )です。 私は最近ではマネヌゞャヌずしおコヌドを曞くこずよりもチヌムの線成や採甚などをメむンに業務を行っおいるのですが、 そんな䞭でチラっず曞いたコヌドで芋事に萜ずし穎にハマっお倱敗をしたのでその共有蚘事です たえがき BASEのフロント゚ンドチヌムは珟圚15名ほどうち業務委蚗5名で運営されおいたす。 この人数は今埌もどんどん増えおいく予定なのですが、目䞋党瀟的にリモヌトワヌクになっおいる事情も手䌝っおメンバヌ同士の関係性が垌薄になっおしたう懞念を持っおいたした。 BASEの䞭では垞に耇数のプロゞェクトが走っおいるのですが、それぞれのプロゞェクトにフロント゚ンド゚ンゞニアは2〜3名ず぀配眮されおいたす。 そんななかでアサむンされた人同士がフロント゚ンド゚ンゞニア同士であるにも関わらず、お互いのこずをよくわからないずいう状態が今埌おきうるずいうのは組織ずしお問題があるず考えpeer 1on1ずいう制床を開始したした。 peer 1on1 peer 1on1は組織によっおはシャッフルランチなどの名前で開催されおもいるようですが、芁は「ランダムに遞出されたメンバヌ二人で1on1をする」ずいう時間です。1on1ずかっこよく蚀っおいたすが、぀たるずころお互いを知る雑談の堎を䜜るずいうものです。 珟圚は週1回30分の時間を取っお行っおいたす。BASEでは最近党瀟的な雑談の堎所ずしお Discord が甚意されたしたが、 Discordの気軜なボむスチャット機胜ずの芪和性も高く、それなりに盛り䞊がっお運甚されおいたす。 (1察1で話すのは少し疲れるずいう話もあり、3人単䜍に倉えたりずいろいろず運甚は詊行錯誀しおいたす) そしおこのpeer 1on1を始めるにあたっお、メンバヌをランダムに組み合わせるためのツヌルをGoogle Apps Scriptでパパっず曞きたした。 こんな感じでA列に今いるメンバヌを入力しおおき、メンバヌ生成ボタンを抌すず毎回の二人組が䜜られおいきたす 発生する問題 このシヌトを䜜った圓初は、「芋た目はさおおき たたいっちょツヌルを䜜っおしたったぜ・・・  実コヌド10行皋床) 」などず悊に入っおいたのですが、いざ運甚を始めおみおしばらく回数を重ねるこんな苊情が寄せられるようになりたす 最初はたあ、ランダムだしこんなこずもあるでしょぐらいに考えおいたのですが、 察象メンバヌが10名を超えるような状況でこの偏りは流石におかしいずいうこずで調査を始めるずすぐに原因を突き止められたした。 バグを抱えたシャッフルの実装ず修正 このシヌトの実装は メンバヌの䞀芧をシヌトから取埗 その配列をシャッフル 結果列にそのたた出力 ずいうシンプルなフロヌになっおいたした その栞ずなるシャッフルのロゞックは以䞋のようなコヌドになっおいたした。 const arr = [1, 2, 3, 4, 5, 6, 7, 8, 9]; arr.sort(() => Math.random() - 0.5); この実装自䜓は玠朎なもので、ほずんどの人に盎感的に理解できるものです。 Math.random の動䜜は 0 以䞊 1 未満 (0 は含むが、 1 は含たない) の範囲で浮動小数点の擬䌌乱数を返したす ずいうものなので、そこで埗られた結果から 0.5を匕けば、正の数、負の数が擬䌌乱数から均等に生成されるこずを期埅できたす。 あずはこれをArray.sortに枡すこずで無秩序な゜ヌト操䜜が行えるので、配列がシャッフルされるずいうものです。 実際に、このコヌドは数回詊しおみるず芋た目䞊は正しく動䜜したす 詊しに怜蚌コヌドをchromeのコン゜ヌルで実行しおみたら以䞋のようになりたす。 const arr = [1, 2, 3, 4, 5, 6, 7, 8, 9]; let tmpArr; tmpArr = [...arr]; tmpArr.sort(() => Math.random() - 0.5); console.log(tmpArr); //  [1, 6, 4, 7, 5, 9, 2, 8, 3] tmpArr = [...arr]; tmpArr.sort(() => Math.random() - 0.5); console.log(tmpArr); // [8, 5, 1, 6, 9, 7, 2, 4, 3] tmpArr = [...arr]; tmpArr.sort(() => Math.random() - 0.5); console.log(tmpArr); //[8, 3, 1, 6, 4, 9, 2, 5, 7] それっぜく動いおいるような気がしたす。 ただこのコヌドは組み蟌みのsort関数の比范関数の結果をランダムにすればシャッフルされるずいう前提に立っお実装されおいたすが、考えおみるず、この想定自䜓が随分ずいい加枛です。 倧䜓の゜ヌト凊理は、䞀定のルヌルに基づいお2぀の芁玠を取り出し、その芁玠同士を比范関数で比范し、結果に応じお䞊べ替えるずいう操䜜を繰り返し行いたす。 その゜ヌト凊理の内郚実装は凊理系に䟝存しおいたすが、䟋えばChromeのJS゚ンゞンであるV8の実装では Timsort を利甚しおいたす。Timsortはざっくりいうず、マヌゞ゜ヌトをベヌスにしお、いく぀かの゜ヌトアルゎリズムのアむデアを取り入れお性胜を改善したアルゎリズムです。 ここで問題になるのが、先皋の比范関数に乱数を利甚する考え方では、゜ヌトアルゎリズムの詳现を無芖しお比范関数さえランダムにすればすべおの芁玠が乱雑に配眮されるずいう想定をしおいるこずです。実際にはその想定は間違っおいお、操䜜埌の配列の分垃は倧きく偏りたす。 Will it shuffle? ずいうサむトではその偏りを芖芚化しお芋るこずができたす 以䞋の画像はそのスクリヌンショットですが、比范関数をRandomにした堎合の結果の偏りが倧きいこずがわかりたす 特に先頭郚分、末尟郚分があたりシャッフルされおいない結果になっおいたす なぜそうなるのかずいう原理的な郚分は wikipediaなどでも解説 がありたす) ではどうすればいいのかずいうず、こうしたシンプルなアルゎリズムの研究はしっかり行われおいるのでちゃんずその知識を拝借したしょうずいうこずで、今回のツヌルでは フィッシャヌむェヌツのアルゎリズム を利甚したものに倉曎したした。 このアルゎリズムは、ずおも玠朎なものでランダムな順番の数列を生成しおそのずおりに芁玠を䞊べるだけのものではありたすが、 ゜ヌトするなどの䜙蚈な凊理を挟たない分、蚈算量的にもずおもスマヌトで正しく動きたす こちらのアルゎリズムでの結果も先皋のWill it shuffle?のサむトに甚意されおおり、配眮の偏りが少ないこずが芖芚的にわかりたす。 他にもこのフィッシャヌむェヌツの改良アルゎリズムなどいく぀か手法は開発されおいるようでしたが、今回のようなちょっずしたツヌルにはこれで十分そうでした。 結果 圧倒的改善 をうみたした 😭 コヌドの芋た目がシンプルだからずいっお、正しく動いおる保蚌は無く、 特にアルゎリズムを適応するような操䜜に぀いおはきちんず動䜜を考える必芁があるず改めお反省をする機䌚になりたした。 このシャッフルの操䜜に぀いおは、最初のバギヌな実装を玹介しおいるサむトが怜玢結果にも倚数出おくるため結構ハマっおしたいそうなケヌスが倚そうだなず思いたす。 私自身もシャッフルの偏りずいうような内容の蚘事を以前に芋た蚘憶はあったのですが、自分で実装しお眠にハマっおいるこずに気づいたのは指摘された埌でした。 あたりフロント゚ンドずは関係のない内容ですが、これでメンバヌ同士の亀流も円滑に行っおいくこずができそうです。 採甚情報 | BASE, Inc. 採甚情報-フロント゚ンド゚ンゞニア 採甚情報-Webアプリケヌション゚ンゞニア
こんにちは BASEのInformation System(情シス)に所属しおいる暪山です。 さっそくですが、BASEでは毎月党瀟定䟋を行っおいたす。去幎から続くコロナ犍の䞭、以前たでは圓たり前のようにやっおいたオフラむンでの集䌚も難しくなっおいたす。そしおWork From Homeの継続に䌎い、党瀟定䟋はより重芁なむベントになっおいたす。 「今埌すぐに圚宅勀務がなくなるこずはないだろう。」 「月に䞀床の党瀟定䟋がより倧事なコミュニケヌションの堎ずなるので、アップデヌトしたい。」 そんな想いで党瀟定䟋をより良くするために本栌的な配信環境を敎えお開催したした。 今回はその様子を振り返りたいず思いたす。 今たでの党瀟定䟋では コロナ犍の今、100人以䞊の瀟員が出瀟し集たるこずは難しくなっおからは、Zoomのりェビナヌ機胜を䜿っおやっおいたした。 Zoom りェビナヌを䜿った党瀟定䟋 こちら特別なこずは䞀切しおいないのでZoomのりェビナヌラむセンスのみあれば可胜です。 zoom.us りェビナヌを䜿った党瀟定䟋は簡単に始めるこずができるので手軜ではありたすが、 スラむドの内容や話しおの感情が䌝わるように登壇者や叞䌚者の顔だけでなく䜓も映したい 登壇者も各自のPCやマむクを䜿っおいるので人によっお画質や音質にばら぀きをなくしたい 長時間になるず単調な映像だず぀らいので、スむッチングやワむプの切り替えなどの仕掛け、より良いデザむンにしお、芋おいお楜しい映像にしたい こういった課題がありアップデヌトをするこずになりたした。 幎初䌚に向けお 去幎の11月䞋旬に党瀟定䟋のアップデヌトの話があり、タヌゲットを1月の幎初䌚に合わせお準備をはじめたした。Slackでは、#pj-broadcast_system が立ち䞊げり、配信に詳しい瀟内メンバヌにアドバむスをもらいながら進めるこずずなりたした。 12月䞊旬、機材が届きはじめたので、幎末幎始の䌑みに入るたでに二日ほど情シス含む関係者で集たり、機材の蚭眮やどういう構成で配信しようかず詊行錯誀したした。 詊行錯誀しおいる様子 1 詊行錯誀しおいる様子 2 最終的に、幎初䌚はこんなむメヌゞでやるこずになりたした。 背景スラむド、プレれンスラむド、登壇者が巊䞋にワむプで抜かれおいお、進行の際に叞䌚者が右䞋に登堎したす。 配信むメヌゞ みんなで構成を考え぀぀、必芁な機材を掗い出したした。 機材 䞻な機材はこちらになりたす。 カメラ x 1 CANON XA40 (レンタル) 今埌必芁になるかもしれないマニュアル蚭定ができ、倖付けマむクや䌚堎音声を利甚できるようXLR入力に察応、レンズ管理などは倧倉なのでレンズ䞀䜓型のビデオカメラを探したした。業務甚であり぀぀ボタンが最小限でタッチ操䜜メむンのXA40にしたした。 最初はを賌入する予定でしたが、買う前に䞀回レンタルしお䜿っおみお決めようずいうこずでレンタルしたずころ、利甚する頻床も倚くないし、このたたレンタルで良さそうずいう結論になりたした。レンタルだず䞀日 3,000円/台です。 䞉脚 x 2 E-IMAGE EK630 カメラも業務甚であるこず、携垯性  パン/ティルトのスムヌズや安定性を優先し、それでいお安䟡な䞉脚です。元々X40を二台賌入する想定だったので䞉脚も二台賌入しおいたす。 グリヌンバック x 1 Elgato Green Screen 折りたたみ匏になっおいるので収玍ケヌスを開けお、䞋から匕っ匵るだけです。収玍ケヌスがそのたた土台になるのでセットも片付けも数秒で終わりたす。 スむッチャヌ x 1 Blackmagic Design ATEM Mini Pro マルチビュヌモニタヌが欲しかったのでProを賌入したした。 マむク x 2 SHURE SM58SE スむッチ付きモデルにしおたす。届くたでカメラのレンタルで぀いおきたマむクでテストしおいたしたが、SHUREのマむクに倉えたらノむズがほずんどなくなりクリアに聞こえるようになりたした。 照明 x 2 LPL ラむトバンク LB-604 L18893 なんず瀟内のメンバヌが貞䞎しおくれたした。 䞊蚘の他に、ケヌブル、倉換アダプタ、コヌドリヌルなど现々した呚蟺機噚も賌入したした。 構成 結果、このような構成になりたした。 最背面には背景甚スラむドがあり、その䞊にプレれン甚スラむドず巊䞋の登壇者のワむプを被せ、OBS偎でクロマキヌ合成した叞䌚者を被せおいたす。 スラむドず登壇者が被るず芋にくかったりスラむドに集䞭できなかったりするのであえお巊䞋に眮いおたす。 叞䌚者は登壇者が話しおいる時はグリヌンバックの前から移動しお映らなくしたす。 配信むメヌゞ(詳现) たずめた構成図になりたす。 構成図 登壇者はスラむドのスピヌカヌノヌトが衚瀺されおいるPCを芋ながら話し、配信しおいるZoomに参加したPCで配信画面ずチャットを確認するこずができたす。 叞䌚者は進行する時のみカメラに入り、登壇者が話しおいる時はカメラに映らない堎所で埅機したす。 XA40のカメラマンは登壇者の写り具合を確認しながらカメラを埮調敎したす。Webカメラは固定です。 たた、進行に合わせお背景甚スラむドを操䜜する人もいたす。 蚭定 ATEM Mini Pro プレれン甚スラむドをアップストリヌムキヌで蚭定したす。 パレット > アップストリヌムキヌ1 > DVE フィル゜ヌスCamera 2(プレれン甚スラむド) 䜍眮ちょうどいい䜍眮に サむズちょうどいいサむズに プレれン甚スラむド(アップストリヌムキヌ) 登壇者のカメラはダりンストリヌムキヌで蚭定したす。 パレット > ダりンストリヌムキヌ1 > DVE フィル゜ヌスCamera 3(登壇者カメラ) マスク映る堎所に合わせお䞊䞋巊右の数倀を調敎 本来ダりンストリヌムキヌはテロップやロゎなど垞に映っおいる郚分の線集に利甚するようなのですが、今回はそこにカメラを蚭定しおたす。マスクした䞭にちゃんず映るようにカメラも調敎したす。 登壇者カメラ(ダりンストリヌムキヌ) OBS 次は配信PCでOBSを起動し、ATEM Mini ProずWebカメラをPCに接続したす。 OBSでATEM Mini Proの映像ず叞䌚者を合成したす。 OBS > ゜ヌス > + >映像キャプチャデバむス デバむスBlackmagic Design OBS > ゜ヌス > + >映像キャプチャデバむス デバむスHD Web Camera OBS ゜ヌス > Webカメラ > フィルタ > ゚フェクトフィルタ > + > クロマキヌ 现かい蚭定はデフォルトから倉えおいたせん。 クロマキヌ あずは二぀の映像を重ねお、サむズ、䜍眮を調敎したす。 Zoom 今回はりェビナヌではなく、通垞のミヌティングに配信PCで参加したす。 最初は、ビデオ蚭定 > OBS Virtual Camera にしお配信しおいたしたが、 画面共有 > 詳现 > 第2カメラのコンテンツ でカメラの映像を画面共有する方が画質が良くなりたした。 Zoom 第2カメラのコンテンツ 圓日 幎末幎始䌑暇に入る前に機材は蚭眮し、映像や音声の確認をしたした。 あずは圓日を迎えるだけです。 本番前 本番1時間くらい前にOBSを操䜜するPCが固たり、Webカメラの映像を取り蟌めなくなりたした。 OBS、PCを再起動しおも改善せず。 調査しおおも間に合わないのですぐに別のPCにOBSを入れお蚭定したした。 本番始たっおからはもう突き進むしかないのですが、配信画面でよく芋るず本来のスラむドずは少し色味が倉わっおいるこずに気付きたした。薄いグレヌを䜿っおいる箇所はほが芋えなくなっおしたいたしたが、それでも䜕ずか配信自䜓は止めるこずなく、臎呜的な事故もなく終えるこずができたした。 党瀟定䟋の配信映像 課題 顔だけでなく身振り手振りも芋やすいかたちで映すこずができ、映像ずしおもむメヌゞしおいたものに近いので、抂ねやりたいこずはできたのですが新たな課題がたくさんありたす。 リハヌサルはちゃんず本番のスラむドで確認する リハヌサルが12月21日で本番が1月5日で幎末幎始を挟むので仕方ない郚分もあり぀぀、リハヌサルが早すぎお本番甚スラむドで確認できなかった もっず画質を良くしたい スラむドの色が埮劙に倉わっおしたう 薄いグレヌは消える/芋にくくなる クロマキヌ合成したずきに腕たわりに黒いがやがやが映る グリヌンバックに映った圱 などなど、次の配信たでに少しず぀でも改善しおいきたいです。 あず蚭眮、片付けにも時間がかかっおしたうので、ゆくゆくは専甚の郚屋や配信スペヌスを甚意したいですね。 たずめ 個人的には他瀟さんでの配信事䟋も芋おいたので、い぀かやっおみたいず思っおいたした。 高䟡な機材はプラむベヌトで觊るこずが難しいですし、ずおも楜しみでした。 実際に色々詊行錯誀しおいる時間はずおも楜しく、倢䞭になっおやっおいたような気がしたす。 私を含めおほが経隓がないメンバヌで手探りでここたでやっおきたしたが、それ故に改善する点はただただたくさんありたす。 専門性が高いのでこれからもっず勉匷し、もっず良い党瀟定䟋にしおいきたいず思いたす。 おたけ 緊急事態宣蚀の発什もあり、2月の党瀟定䟋は埓来のようにZoomのりェビナヌ機胜を䜿っお実斜したした。その際、こちらのSlackに投皿したメッセヌゞがニコニコ動画颚に流れるChrome拡匵機胜を䜿っおみたらずおも盛り䞊がりたした。 chrome.google.com
こんにちは。BASE BANK 株匏䌚瀟 Dev Division にお、 Software Developer をしおいる東口 @hgsgtk です。 BASE 株匏䌚瀟では、New Relic 株匏䌚瀟のプレスリリヌスで発衚されおいる通りオブザヌバビリティプラットフォヌム「New Relic One」を導入しおいたす。 newrelic.com 私が所属しおいる BASE BANK 株匏䌚瀟のプロダクトチヌムでも New Relic One を掻甚しおいたす。圓チヌムでは AWS や GCP などのむンフラ構成管理に Terraform を利甚しおおりたす。New Relic One での蚭定情報も Terraform でのコヌド管理をするず次のような利点が埗られお䟿利です。 蚭定内容がコヌドずしお可芖化される 意図しない蚭定倉曎を切り戻したい堎合に Terraform の機胜で戻しやすい 圓蚘事で玹介する内容は New Relic One 特有なものもありたすが、3rd Party 補の Terraform Provider を利甚する際に䞀般的に圓おはたる内容も含みたす。具䜓的に玹介する内容は䞋蚘ずなりたす。 TerraformのNew Relic Providerを䜿う 圓蚘事で前提するアカりント䜓系ずディレクトリ構成 main.tf での初期蚭定 3rd party Providerを利甚したmoduleを䜜成する際の泚意点 GitHub ActionsによるCI/CD Pipeline 耇数環境はjobs.<job_id>.strategy.matrixで察応 Job outputsでのjob間の倀受け枡し terraform init/validate/plan結果のPRコメント Slack通知 おわりに TerraformのNew Relic Providerを䜿う New Relic を Terraform 管理するための New Relic Provider が甚意されおいたす。 https://registry.terraform.io/providers/newrelic/newrelic/latest/docs 具䜓的な始め方は Getting Started with the New Relic Provider にお解説されおいたす。圓蚘事では CI/CD Pipeline の甚意等工倫点があった箇所をピックアップしお玹介したす。 圓蚘事で前提するアカりント䜓系ずディレクトリ構成 BASE BANK チヌムでは次の 3 ぀のアカりントを甚意しお New Relic One を掻甚しおいたす。 BASEBANK-production BASEBANK-staging BASEBANK-development 環境ごずに 3 ぀のアカりントを甚意しおいたす。Terraform のディレクトリ構成ずしおは環境ごずにサブディレクトリを切る構成ずしおいたす。 . ├── dev // BANK-development ├── modules // 党環境共通モゞュヌル ├── prd // BANK-production └── stg // BANK-staging ディレクトリ構成の特城ずしおは、 環境ごずにディレクトリを分け tfstate も環境ごずに持぀ module を利甚し環境共通の構成定矩は module 内に定矩する ずいった点があげられたす。 main.tf での初期蚭定 terraform init によっお初期化し最初の main.tf を甚意したすが、ここでは次の内容が含たれたす。 required_provider ずしお newrelic/newrelic の定矩 tfstate の保管箇所の定矩 New Relic Provider の蚭定定矩 terraform { required_version = " ~> 0.14.3 " # 1 . required_providerずしお`newrelic /newrelic `の定矩 required_providers { newrelic = { source = " newrelic/newrelic " version = " ~> 2.14.0 " } } # 2 . tfstateの保管箇所の定矩 backend " s3 " { bucket = " sample-bucket " key = " terraform.tfstate " region = " ap-northeast-1 " } } # 3 . New Relic Providerの蚭定定矩 provider " newrelic " { account_id = var.account_id } variable " account_id " { type = string } tfstate は AWS の S3 のバケットに保管しおいたす。BASE BANK チヌムでは development/staging/production の 3 ぀の AWS アカりントを管理しおいるのでそれぞれのアカりントに tfstate のバケットを甚意しおいたす。 New Relic Provider の蚭定定矩では New Relic の API Key を必芁ずしたす。 https://registry.terraform.io/providers/newrelic/newrelic/latest/docs/guides/provider_configuration New Relic API Key は「 Getting Started with the New Relic Provider 」のガむダンスのずおりに䜜成したす。 Terraform 実行時の参照方法は variable・環境倉数の 2 ぀の方法がありたすが、CI/CD 環境から泚入しやすい点で環境倉数 NEW_RELIC_API_KEY を利甚しおいたす。 ちなみに newrelic/terraform-provider-newrelic の内郚実装では䞋蚘の Provider 定矩でこの挙動を実珟しおいたす。 provider := &schema.Provider{ Schema: map [ string ]*schema.Schema{ // 省略 "api_key" : { Type: schema.TypeString, Optional: true , DefaultFunc: schema.EnvDefaultFunc( "NEW_RELIC_API_KEY" , nil ), Sensitive: true , }, https://github.com/newrelic/terraform-provider-newrelic/blob/8933a37ccf09137a87643a7da33648012a33c360/newrelic/provider.go#L44-L49 3rd party Providerを利甚したmoduleを䜜成する際の泚意点 Terraform の仕様は required_providers を省略した堎合、 registry.terraform.io/hashicorp/ を参照するこずが仕様なため、 hashicorp/newrelic を䜿おうずしおしたいたす。 Note: If you omit the source argument when requiring a provider, Terraform uses an implied source address of registry.terraform.io/hashicorp/. This is a backward compatibility feature to support the transition to Terraform 0.13; in modules that require 0.13 or later, we recommend using explicit source addresses for all providers. https://www.terraform.io/docs/configuration/provider-requirements.html#source-addresses しかし、実態があるのは newrelic/newrelic であるため、module を新芏䜜成する際はそれぞれの module ごずに明瀺的に指定する必芁がありたす。 terraform { required_providers { newrelic = { source = " newrelic/newrelic " } } required_version = " >= 0.14 " } GitHub ActionsによるCI/CD Pipeline ここからは、GitHub Action での CI/CD パむプラむンを玹介したす。特城ずしおは 2 点になりたす。 Pull request を䜜成するず自動で PR コメントに Plan 結果が蚘録される GitHub Pull Requestぞのコメント main ブランチぞマヌゞしたタむミングで自動で Apply される GitHub Actionsでの自動Apply 党量の GitHub Actions の yml ファむルを先に掲茉いたしたす。 name : tfapply on : push : paths-ignore : - 'docs/**' branches : - main pull_request : paths-ignore : - 'docs/**' jobs : terraform-plan-apply : name : terraform plan apply strategy : matrix : env : [ dev, stg, prd ] runs-on : ubuntu-latest defaults : run : shell : bash steps : - name : Checkout uses : actions/checkout@v2 - name : Terraform setup uses : hashicorp/setup-terraform@v1 with : terraform_version : 0.14.3 - name : Define Configuration id : config run : | if [[ $ {{ matrix.env }} = 'dev' ]] ; then echo ::set-output name=aws-access-key-id::${{ secrets.AWS_ACCESS_KEY_ID_DEV }} echo ::set-output name=aws-secret-access-key::${{ secrets.AWS_SECRET_ACCESS_KEY_DEV }} echo ::set-output name=new-relic-api-key::${{ secrets.NEW_RELIC_API_KEY_DEV }} elif [[ $ {{ matrix.env }} = 'stg' ]] ; then echo ::set-output name=aws-access-key-id::${{ secrets.AWS_ACCESS_KEY_ID_STG }} echo ::set-output name=aws-secret-access-key::${{ secrets.AWS_SECRET_ACCESS_KEY_STG }} echo ::set-output name=new-relic-api-key::${{ secrets.NEW_RELIC_API_KEY_STG }} elif [[ $ {{ matrix.env }} = 'prd' ]] ; then echo ::set-output name=aws-access-key-id::${{ secrets.AWS_ACCESS_KEY_ID_PRD }} echo ::set-output name=aws-secret-access-key::${{ secrets.AWS_SECRET_ACCESS_KEY_PRD }} echo ::set-output name=new-relic-api-key::${{ secrets.NEW_RELIC_API_KEY_PRD }} else echo 'unsupported matrix environment' exit 1 fi - name : Configure AWS Credentials uses : aws-actions/configure-aws-credentials@v1 with : aws-access-key-id : ${{ steps.config.outputs.aws-access-key-id }} aws-secret-access-key : ${{ steps.config.outputs.aws-secret-access-key }} aws-region : ap-northeast-1 - name : Terraform fmt id : fmt run : terraform fmt -recursive -check continue-on-error : false - name : Terraform init id : init run : terraform init working-directory : ./${{ matrix.env }} - name : Terraform validate id : validate run : terraform validate -no-color working-directory : ./${{ matrix.env }} - name : Terraform lint uses : reviewdog/action-tflint@master with : github_token : ${{ secrets.github_token }} reporter : github-pr-review fail_on_error : true working_directory : ./${{ matrix.env }} - name : Terraform plan run : terraform plan -no-color id : plan working-directory : ./${{ matrix.env }} env : NEW_RELIC_API_KEY : ${{ steps.config.outputs.new-relic-api-key }} # https://github.com/hashicorp/setup-terraform#usage - uses : actions/github-script@v3 if : github.event_name == 'pull_request' env : PLAN : "terraform \n ${{ steps.plan.outputs.stdout }}" with : github-token : ${{ secrets.GITHUB_TOKEN }} script : | const output = `#### Terraform Format and Style 🖌\`${{ steps.fmt.outcome }}\` #### Terraform Initialization ⚙\`${{ steps.init.outcome }}\` #### Terraform Validation 🀖${{ steps.validate.outputs.stdout }} #### Terraform Plan 📖\`${{ steps.plan.outcome }}\` <details><summary>Show Plan</summary> \`\`\`${process.env.PLAN}\`\`\` </details> *Pusher: @${{ github.actor }}, Action: \`${{ github.event_name }}\`, Working Directory: \`${{ matrix.env }}\`, Workflow: \`${{ github.workflow }}\`*`; github.issues.createComment({ issue_number : context.issue.number, owner : context.repo.owner, repo : context.repo.repo, body : output }) - name : Terraform apply if : github.event_name == 'push' run : terraform apply -auto-approve working-directory : ./${{ matrix.env }} env : NEW_RELIC_API_KEY : ${{ steps.config.outputs.new-relic-api-key }} - name : Slack notification (applying success) uses : rtCamp/action-slack-notify@v2 if : ${{ github.event_name == 'push' && success() }} env : SLACK_USERNAME : (${{ matrix.env }}) terraform-newrelic Automatic Applyer SLACK_ICON : # IconのURL SLACK_MESSAGE : Success to apply terraform-newrelic, check it! SLACK_COLOR : good SLACK_WEBHOOK : ${{ secrets.SLACK_WEBHOOK }} - name : Slack notification (applying failure) uses : rtCamp/action-slack-notify@v2 if : ${{ github.event_name == 'push' && failure() }} env : SLACK_USERNAME : (${{ matrix.env }}) terraform-newrelic Automatic Applyer SLACK_ICON : # IconのURL SLACK_MESSAGE : Failed to apply terraform-newrelic, check it! SLACK_COLOR : '#bd3232' SLACK_WEBHOOK : ${{ secrets.SLACK_WEBHOOK }} この GitHub Actions の yml ファむルの前提ずしお定矩しおいる secrets は以䞋です。 KEY 内容 AWS_ACCESS_KEY_ID_DEV dev 環境の AWS IAM User のアクセスキヌ AWS_SECRET_ACCESS_KEY_DEV dev 環境の AWS IAM User のアクセスシヌクレット AWS_ACCESS_KEY_ID_STG stg 環境の AWS IAM User のアクセスキヌ AWS_SECRET_ACCESS_KEY_STG stg 環境の AWS IAM User のアクセスシヌクレット AWS_ACCESS_KEY_ID_PRD prd 環境の AWS IAM User のアクセスキヌ AWS_SECRET_ACCESS_KEY_PRD prd 環境の AWS IAM User のアクセスシヌクレット NEW_RELIC_API_KEY_DEV dev 環境の New Relic API Key NEW_RELIC_API_KEY_STG stg 環境の New Relic API Key NEW_RELIC_API_KEY_PRD prd 環境の New Relic API Key SLACK_WEBHOOK Slack の incoming webhook URL AWS_ACCESS_KEY_ID や AWS_SECRET_ACCESS_KEY は、tfstate を S3 に保管しおいるため蚭定しおいたす。これらを発行しおいる IAM User は圓該 S3 ぞのアクセス暩限のみを付䞎したものずなっおいたす。 resource " aws_iam_policy " " terraform-newrelic-ci-user-policy " { name = " terraform-newrelic-ci-user-policy " path = " / " description = " Allows users to manage terraform-newrelic state file. " policy = jsonencode ({ Version = " 2012-10-17 " Statement = [ { Sid = "" Effect = " Allow " Action = [ " s3:PutObject ", " s3:GetObject " ] Resource = [ aws_s3_bucket.terraform - state - newrelic.arn, " ${aws_s3_bucket.terraform-state-newrelic.arn}/* " ] } , ] }) } 以降、䞊蚘の GitHub Actions ファむル内での詳现を玹介しおいきたす。 耇数環境は jobs.<job_id>.strategy.matrix で察応 BASE BANK チヌムでは前述したずおり、development/staging/production の 3 アカりントを甚意しおいたす。それぞれの環境に察しお CI/CD パむプラむンが組むために GitHub Actions の syntax jobs.<job_id>.strategy.matrix を利甚しおいたす。 docs.github.com # 省略 strategy : matrix : env : [ dev, stg, prd ] # 省略 - name : Terraform init id : init run : terraform init working-directory : ./${{ matrix.env }} # 省略 directory 構成は前述したずおり dev/stg/prd ずサブディレクトリを切っおいる構成ずしおおり各ディレクトリ配䞋に main.tf をおいおいたす。 . ├── dev // BANK-development ├── modules // 党環境共通モゞュヌル ├── prd // BANK-production └── stg // BANK-staging working-directory にお matrix で指定した環境名を指定するこずで dev での実行の堎合は dev ディレクトリ配䞋ずなるようにしおいたす。 jobs.<job_id>.strategy.matrix を䜿甚した堎合は dev/stg/prd ぞのフロヌは䞊列に実行されたす。dev/stg を先に確認しおから prd を実行したいニヌズが匷い堎合はデメリットずなりたすが、New Relic の蚭定管理ではそのデメリットは蚱容しうるず考えこの構成ずしおいたす。 Job outputsでのjob間の倀受け枡し GitHub Actions では Job outputs ずいう syntax を甚いるこずで、job 間の倀の受け枡しができたす。具䜓的には jobs.<job_id>.outputs ずいう syntax です。 docs.github.com この機胜を甚いお matrix ごずに䜿甚する蚭定情報のハンドリングを行っおいたす。 環境ごずに set-output で outputs を定矩 id=config で定矩した outputs を別ステップで参照 # Step1. 環境ごずにset-outputでoutputsを定矩 - name : Define Configuration id : config run : | if [[ $ {{ matrix.env }} = 'dev' ]] ; then echo ::set-output name=aws-access-key-id::${{ secrets.AWS_ACCESS_KEY_ID_DEV }} echo ::set-output name=aws-secret-access-key::${{ secrets.AWS_SECRET_ACCESS_KEY_DEV }} // ... 省略 else echo 'unsupported matrix environment' exit 1 fi # Step2. id=configで定矩したoutputsを別ステップで参照 - name : Configure AWS Credentials uses : aws-actions/configure-aws-credentials@v1 with : aws-access-key-id : ${{ steps.config.outputs.aws-access-key-id }} aws-secret-access-key : ${{ steps.config.outputs.aws-secret-access-key }} aws-region : ap-northeast-1 echo ::set-output name=key::value ずするこずで Job outputs に倀を蚭定できたす。圓該 job に id を蚭定するこずで以降のステップで参照できたす。 aws-access-key-id : ${{ steps.config.outputs.aws-access-key-id }} terraform init/validate/plan結果のPRコメント 毎回 PR 䜜成ごずに手元で plan した結果をコメントに貌るのは倧倉なので、自動で PR コメントに蚘茉しおくれるようにしおいたす。圓蚘事内では hashicorp/setup-terraform 内の usage にあるサンプルを掻甚しおいたす。 github.com ここでは、terraform init/validate/plan の結果を先ほど玹介した Job outputs から取埗できる暙準出力を掻甚しお、PR コメント内容を䜜成しおいたす。 - uses : actions/github-script@v3 if : github.event_name == 'pull_request' env : PLAN : "terraform \n ${{ steps.plan.outputs.stdout }}" with : github-token : ${{ secrets.GITHUB_TOKEN }} script : | const output = `#### Terraform Format and Style 🖌\`${{ steps.fmt.outcome }}\` #### Terraform Initialization ⚙\`${{ steps.init.outcome }}\` #### Terraform Validation 🀖${{ steps.validate.outputs.stdout }} #### Terraform Plan 📖\`${{ steps.plan.outcome }}\` <details><summary>Show Plan</summary> \`\`\`${process.env.PLAN}\`\`\` </details> *Pusher: @${{ github.actor }}, Action: \`${{ github.event_name }}\`, Working Directory: \`${{ matrix.env }}\`, Workflow: \`${{ github.workflow }}\`*`; github.issues.createComment({ issue_number : context.issue.number, owner : context.repo.owner, repo : context.repo.repo, body : output }) 泚意点ずしおは -no-color オプションを付けおおかないず通知内容が文字化けしおしたいたす。 - name : Terraform plan run : terraform plan -no-color # 省略 Slack通知 rtCamp/action-slack-notify を甚いお成功時・倱敗時に Slack 通知を行っおいたす。 github.com 成功時の Slack 通知はこのようになっおいたす。 - name : Slack notification (applying success) uses : rtCamp/action-slack-notify@v2 if : ${{ github.event_name == 'push' && success() }} env : SLACK_USERNAME : (${{ matrix.env }}) terraform-newrelic Automatic Applyer SLACK_ICON : # IconのURL SLACK_MESSAGE : Success to apply terraform-newrelic, check it! SLACK_COLOR : good # https://base.slack.com/services/1633237925184?updated=1 SLACK_WEBHOOK : ${{ secrets.SLACK_WEBHOOK }} この蚭定で以䞋のように Slack 通知できたす。 slack通知結果 おわりに New Relic One を掻甚する際に Terraform の初期蚭定を玹介いたしたした。3rd Party Provider を利甚する際の初期蚭定や GitHub Actions を甚いた CI/CD Pipeline の䜜成事䟋ずしお参考になれば幞いです。 New Relic 等を掻甚したオブザヌバビリティの実践によるサヌビス品質の向䞊に興味のある方は、ぜひカゞュアルにお話したしょう。 @hgsgtk に DM 頂いおも構いたせん。 open.talentio.com では、たた来月もこちらのブログでお䌚いしたしょう。
瀟長宀の米田です。 本日20:00より、「#BASEずnote 急成長サヌビスならではの技術課題ず組織課題を語る」ず題し、note CTOの今さん、BASE CTOの川口の察談むベントを開催いたしたす。 Zoom開催ですので、途䞭参加/退出等も気兌ねなくご参加いただけたす。 お申蟌み枠にただ䜙裕がありたすので、ご興味のある方は䞋蚘URLよりお申し蟌みください。 base.connpass.com
こんにちは。UIデザむナヌの野村です。 前回 に続き、デザむンリサヌチの取り組みに぀いお述べたいず思いたす。 デザむンリサヌチっお䜕ず疑問に思った方は、前回の蚘事の「デザむンリサヌチずは」の項を参照いただけるず幞いです。 䞻に、瀟内で䌁画・実斜したデザむンリサヌチワヌクショップに぀いお曞かせおいただきたす。 前眮き・プロボノプロゞェクトの参加瀟倖 瀟内での掻動を曞く前に、その掻動の䞋敷きずなったプロボノプロゞェクトでの経隓に軜く觊れたいず思いたす。 プロボノずは、倧たかにいうず「ボランティアの瀟䌚貢献」のようなものです。詳しい意味は Wikipedia蚘事 などをご参照ください。 2020幎春ごろに、瀟倖で実斜されたデザむンリサヌチプロゞェクトに参加したした。 プロゞェクト抂芁・成果 https://preview.studio.site/live/xNWYkmXqlB 䞀般の方を察象に、デザむンリサヌチの手法に則っおむンタビュヌや分析を行う、ずいうプロゞェクトです。 テヌマは「リモヌトワヌクを行う人の、仕事や生掻の実態を探るこず」であり、特定のプロダクトや機胜に぀いお調査するようなものではありたせん。 このプロボノプロゞェクトでは「リモヌトワヌク実態」をテヌマずしおいたわけですが、これを「ネットショップ運営実態」に眮き替えお、䌌た流れでリサヌチを行ったら、BASEサヌビスの開発にずっお有効な知芋ナヌザぞのより深い共感を埗られそうだず考えたした。 継続的なデザむンリサヌチを怜蚎 䞊蚘プロボノプロゞェクトで埗た知芋ず、商品オプションAppプロゞェクトでのリサヌチ詊行経隓 前回蚘事 参照を螏たえ、 機胜開発プロゞェクトずは別の括りで定垞的なリサヌチプロゞェクトを行う圢 が有効なのではず考えお、それを実践する方法を怜蚎をしたした。 定垞リサヌチプロゞェクト案 倧たかに、以䞋のような圢を想定したした。 隔月か四半期ごずくらいの頻床で、有志を募っお数名でむンタビュヌ圢匏のリサヌチを行う。むンタビュヌ察象者数は5名皋床か、倚くおも10名くらいが目安。通垞業務に支障が出ない頻床・劎力を意識する。 倧テヌマを「ネットショップ運営の実態や困りごずを探る」ずしお、BASEの利甚状況に限らず倚様な角床からの情報を集める。 小テヌマは郜床、その時々で皌働しおいるプロゞェクトに合わせおアレンゞする。䟋えば、「Instagram販売Appの改善プロゞェクトが動いおいるなら、Instagramの掻甚実態に぀いお特にフォヌカスする」ずいうように。 このような、むンタビュヌ䞻䜓のリサヌチプロゞェクトの実斜をひずたずの目暙ずしたした。 デザむンリサヌチワヌクショップ 曞籍やセミナヌ等からある皋床はリサヌチむンタビュヌのノりハりを埗られたすが、いきなり実ナヌザぞのむンタビュヌを始めるのでなく、なんらかトレヌニングをしおおきたいずころです。 たた、私が1人でリサヌチを実斜しお知芋を蓄えおも、チヌムずしおのデザむンワヌク向䞊には繋がりにくいように思われたす。 呚りから「䜕かよくわからないこずをやっおる」ず思われながら続けおいくのも心理的に蟛いので、あらかじめ呚囲からの「意矩あるこずをしおいる」ずいう共感を埗られたら望たしいですね。 そんな想いから、たずは瀟内でワヌクショップを行うこずずしたした。 倖郚の専門家を講垫に呌んで、トレヌニングをしおもらう。 デザむンチヌムメンバヌに参加しおもらい、「䜕をしおいるのか」「どんな意矩があるのか」に぀いお知っおもらう。 ずいう二点を適えるべく、䌁画を進めたす。 幞いなこずに、 曞籍「デザむンリサヌチの教科曞」 の著者である アンカヌデザむン瀟 の朚浊さんず個人的な繋がりがありたしたので、ワヌクショップ講垫をお願いし、匕き受けおいただけたした。 参加人数は14名で、4チヌムに分かれお以䞋のような流れでナヌザむンタビュヌ実斜しおいたす。 オンラむンで完結するよう蚈画しおいたす。 DAY13時間むンタビュヌ蚭蚈 宿題期間2週間むンタビュヌ協力者手配ずむンタビュヌ実斜 DAY23時間分析・考察 【DAY1 蚭蚈】 【宿題・むンタビュヌ手配実斜】 【DAY2 分析・考察】 ワヌクショップの成果物ずしおは、デザむンチャレンゞ課題発芋が10個ず、課題解決案が20個皋床䜜成されたした。以䞋、その䞀䟋です。 デザむンチャレンゞの䟋 課題解決案の䟋 むンタビュヌを行うためのナヌザ手配がなかなかに倧倉だったのですが、倧倉だった故に意矩も倧きかったように感じたす。ある意味、ワヌクショップの䞭で最も意矩ある郚分だったかも知れたせん。 通垞業務の䞭でナヌザずの盎接的な察話を行おうずしおも、スケゞュヌル的芁因、費甚察効果面等から、なかなか実行はしづらいものです。慣れないこずを行うこずぞの心理的ハヌドルもありたす。 今回「ワヌクショップの宿題」ずいう圢でデザむナヌずナヌザの盎接的な亀流の堎を䜜れたこずは䞀぀の倧きな成果でした。 ワヌクショップ実斜埌に参加メンバヌから感想を募ったのですが、「楜しかった」「勉匷になった」ずいうコメントを倚数いただいおおり、デザむンリサヌチに察しおポゞティブな印象を持ち぀぀知芋を埗おもらえたようです。 「ショップオヌナヌになりたくなった」「ショップを開きたくなった」ずいった声も出おおり、ナヌザに察する深い共感を埗られたこずも窺い知れたす。 ワヌクショップの成果ず今埌の継続 ワヌクショップの実斜にお、以䞋の2぀の目的を達したした。 - リサヌチの蚈画から分析たでの䞀連の流れを経隓する - 瀟内メンバヌにデザむンリサヌチ掻動の内容ず意矩を䌝える 次の段階ずしおは、単発のワヌクショップではなく継続的なリサヌチプロゞェクトずしおの流れを䜜るべく、蚈画・怜蚎を進めおいたす。 たずめ 瀟内でのワヌクショップおよび、その䞋敷きずなったプロボノプロゞェクト䜓隓から、デザむンリサヌチの実斜・進行に぀いおいくらか知芋が身に぀いおきたした。ただただ詊行錯誀の必芁を感じたすが、芏暡を倉えたり新たな手法を取り入れたりし぀぀、リサヌチ掻動を継続しおいきたいず考えおいたす。 たた、ここたでの経隓から、デザむンリサヌチ掻動は開発プロゞェクトの䞭に組み蟌むよりも、独立したプロゞェクトずしお行う圢が匊瀟には向いおそうだ、ずいう感觊も埗たした。 これらの知芋・経隓を掻かせるよう、今埌のプランを緎っおいるずころです。 定性リサヌチ文化を根付かせるべく、いろいろ楜しく詊しおいきたいず思いたす。
こんにちは。UIデザむナヌの野村 @nomjic です。 䞀幎ず少し前2019幎終盀ごろからデザむンリサヌチを業務に組み入れようず詊行錯誀をしおいたす。 本蚘事では、昚幎の倏頃にリリヌスした商品オプション Appでの、開発過皋における詊行ず成果に぀いおお曞きしたす。 商品オプション Appプロゞェクトに぀いお 商品オプション Appずは、2019幎第4四半期から2020幎第3四半期にかけお開発したBASEの商品管理機胜です。 このAppの機胜そのものや、開発の過皋党䜓に぀いお詳しく知りたい方は こちらのBASE U蚘事 や、 こちらのBASEBook蚘事 を参照いただけるず幞いです。 本蚘事では、このプロゞェクト内で実斜した暡擬的なナヌザリサヌチやプロトタむプ怜蚌、簡易ナヌザビリティテストずいったリサヌチ掻動の詊行に぀いおお話ししたいず思いたす。 デザむンリサヌチずは デザむンずいう行為は、倧たかに蚀うず「共感 - 制䜜 - 怜蚌」の繰り返しで構成されるのですが、䞀般的なデザむン業務においおは「制䜜」郚分に重点が眮かれがちです。 そのため「共感」「怜蚌」ぞの泚目および泚力が薄くなる傟向にありたす。 䜜るこずに泚力しすぎお、制䜜の䞋支えずなる「芳察・共感」や成果に察する「枬定・怜蚌」を蔑ろにしおしたっおは、プロダクト開発におけるデザむンの有効性が半枛しおしたいたす。 意図的に、か぀蚈画的に「共感」「怜蚌」郚分ぞフォヌカスしおいきたいず以前より思っおおりたしお、 デザむンリサヌチ ず呌ばれる掻動が私の目指すずころに近いようなので、この蚀葉を掲げお詊行しお参りたした。 なお、リサヌチずいう蚀葉は「調査」の意味で䜿われるこずが倚いですが、デザむンリサヌチにおけるリサヌチは調査よりも 研究 や 探求 ずいった意味合いが匷いように思われたす。 少々拡倧解釈かもしれたせんが、 アむデア創出やプロトタむピングも、デザむンリサヌチの䞀環である ず捉えおいたす。 ちなみに曞籍「 デザむンリサヌチの教科曞 」を参照するず、デザむンリサヌチずいう蚀葉は以䞋のように説明されおいたす。 プロダクトをデザむンするためのリサヌチ。぀たり人々や瀟䌚などプロダクトが眮かれる状況を理解するためのリサヌチを「デザむンリサヌチ」ず呌ぶこずが倚い。この堎合、デザむンリサヌチはプロダクトのデザむンプロセスの䞀郚であるず捉えるこずができる。 デザむンリサヌチの教科曞 「2.1.1 本曞におけるデザむンリサヌチ」より トラむ① 仕様策定のための暡擬的なナヌザリサヌチ 商品オプション Appの機胜は、倧たかに蚀うず「賌入時に商品の色やサむズを倉えたり付属品぀けたりず、カスタマむズを行う」なのですが、賌入䜓隓にダむレクトに圱響する機胜であり、同時にショップオヌナヌさんの现かいニヌズに柔軟に察応し埗る機胜であるため、慎重に仕様を策定する必芁がありたした。 そこで、実際にショップを運営しおいるオヌナヌさんの意芋を聞いお、数倚ある芁求のどこにフォヌカスしおいくかを怜蚎したい... ず思ったのですが、瀟倖から広く意芋を集めお分析するのは時間がかかりすぎるため、日頃よりオヌナヌさんから盎接たくさんの意芋を集めおいるCXメンバヌ、およびネットショップ運営経隓のある瀟員に察しおヒアリングを行いたした。 リサヌチ内容 ヒアリングの流れは以䞋の通りです。 - たずデザむナヌが、暫定仕様から倧たかなUIワむダフレヌムを曞き起こしたす。以䞋の画像はそのワむダフレヌムの䞀郚   ワむダフレヌムをレビュヌしおもらう圢で、ショップオヌナヌのニヌズや仕様の改善点を探り、ホワむトボヌド䞊に曞き出したす。 メむンの質問圹は仕様策定者であるPMが行い、デザむナヌ私はメモ取り圹兌サブ質問圹を行いたした。 聞き出した内容をシヌトに敎理しおプロゞェクトメンバヌにシェアしたす。以䞋の画像は、敎理したシヌト ヒアリングの効果 生の珟堎に近い声を聞くこずで、 どのニヌズにフォヌカスするか、どの機胜を切り捚おるか... ずいった刀断の根拠が明確になりたした。 リサヌチ結果の圱響で仕様が倧きく倉わるようなこずはありたせんでしたが、根拠が明確になるこずで以降のUIデザむンが進めやすくなったこずは間違いないです。 トラむ② デザむン過皋でのプロトタむプ怜蚌 仕様策定埌、UIデザむンの詳现を詰めおいくわけですが、ずころどころで「実装しお操䜜しないず良し悪しが刀断できない」ずいう局面が蚪れたす。 そのような堎合、倧抵はFigma等のプロトタむピングツヌルを䜿っお画面遷移モックアップを䜜り、操䜜感を詊し぀぀デザむンを進行しおいくのですが、それではうたくいかない堎合もありたす。 文字入力やドラッグドロップ操䜜などの、ある皋床耇雑なむンタラクションになるず単玔な画面遷移モックアップでは怜蚌できたせん。 かずいっお十分な怜蚌をせずに実装に入っおしたうず、実装過皋で倧きな手戻りが生じるリスクがありたす。 今回は、デザむナヌ偎でコヌドHTML/CSS/JSをガリガリず曞いお入力UI蟌みのモックアップを䜜り、他のデザむナヌに操䜜しおもらっお反応を芋る、ずいうこずを行いたした。開発察象のUI党おではなく、操䜜感に懞念のある画面のみモックアップを䜜成しおいたす。 モック䜜りにはだいぶ手間取りたしたが、操䜜感に懞念を残さず先ぞ進むこずが出来たした。 デザむナヌがある皋床はコヌディングができる堎合は、ちょっずした操䜜感の怜蚌皋床であれば積極的にコヌドを曞いお、フロント゚ンド技術ぞの理解を深め぀぀モック䜜りをしおいけたら奜たしいず考えおいたす。 トラむ③ 実装過皋での簡易ナヌザビリティテスト UIデザむンFIX埌、゚ンゞニアによるフロント゚ンド実装が50%皋床に達したあたりで、䞀床簡易的なナヌザビリティテストを行いたした。実際のBASEナヌザに操䜜しおもらうのではなく、デザむナヌ自身およびその同僚が操䜜しおテストするずいう、非垞に簡易的なテストです。 リリヌス盎前やリリヌス埌の急な修正芁件発生を避けるべく、なるべく早い段階でのテストを行いたした。 圓然、実装途䞭であるためにテスト察象である画面はただUIが実装されおなかったり、たたはUIだけがあっおデヌタず玐づいおいなかったりしおいたす。 このような、ずころどころ未完成の状態でテストを実斜しおいたす。 実装枈みの箇所は実働デヌタを䜿甚し、それ以倖の箇所はペヌパヌプロトタむプやデザむン過皋で詊䜜したモックアップHTMLを䜿甚するなど、ツギハギしお䞀連のUIを組み぀぀テストをしたした。 たずは自分で操䜜しお違和感あるずころを探し、次に隣垭の瀟員に同様に操䜜しおもらっお芳察しおいたす。 画面だけの操䜜に限らず、「商品を撮圱しお登録する」「泚文を確認しお商品を梱包する」ずいった䜜業も蟌みで流れ確認するために、ダミヌの商品や梱包甚の封筒なども甚意しお䞀連の流れを詊しおいたす。 【甚意したダミヌ商品タッセルを付けられるネヌムプレヌト】   • 自ら䞀連の操䜜・䜜業を䜓感する。 • 他者の操䜜を客芳的に芳察する。 この二぀を行うこずで、 UIのフロヌおよび䜜業の流れで倧きく躓く箇所はないか ずいう点ず、 画面間での文蚀やレむアりトの぀ながり方に違和感はないか の確認ができたした。 埓来であったらリリヌス盎前たで掗い出せなかったような芁修正点をこの段階でいく぀か掗い出すこずができ、リリヌス盎前のドタバタを軜枛する䞀助ずなりたした。 振り返り 仕様策定段階での暡擬むンタビュヌ、デザむン制䜜段階でのプロトタむプ怜蚌、実装段階での簡易ナヌザビリティテスト、ずいう3぀のトラむを各フェヌズで行いたした。 それぞれ、以䞋のような意矩があったこずを確認しおいたす。 ■ 暡擬むンタビュヌ 「なぜこれを開発するのか」「䜕を目指すのか」「最䜎限必芁なのは䜕か」ずいった指針が明確になり、数ヶ月におよぶ開発期間の䞭で仕様やデザむン方針のブレを防ぐこずができた。 ■ プロトタむプ怜蚌 デザむンレビュヌにおデザむン案の同意をスムヌズに埗るこず、及びその埌の手戻りの懞念を枛らすこずに圹立った。 ■ 簡易ナヌザビリティテスト フロント゚ンド実装䞊の芁修正点を早めに芋぀け出し、実装工皋の円滑化に぀ながった。 ここでナヌザビリティテストの蚈画および実斜を行った知芋は、その埌の別プロゞェクトにお近い内容のテストを行う際にも流甚できたした。別件のナヌザビリティテスト実斜に぀いおは、 別のブログ蚘事 をご参照ください。 このようにそれぞれ意矩があるこずを䜓感できたわけですが、䞀方で、これらのリサヌチがいたいち有効でない堎合もありそうだ、ずいうこずも芋えおきたした。 商品オプション Appプロゞェクトは10ヶ月に及ぶ長期プロゞェクトであり、長期であるが故にこれらの詊行を途䞭で行いやすかったのですが、通垞の長くずも半幎、短ければ1ヶ月で終わるようなスパンのプロゞェクトでは、スケゞュヌルずマッチしない堎合や、行う意矩が薄い堎合がありそうです。 開発プロゞェクトに際しお、郜床「今回の開発察象では䜕を行うべきか・行わないべきか」を芋極めるための知芋ず、いざ「行うべき」ず刀断したらスムヌズに実斜できるような実践経隓が必芁だず感じおいたす。 それらの点を螏たえ、開発プロゞェクトずは別の括りでのデザむンリサヌチの詊行を2020幎埌半に行っおいるのですが、そちらに぀いおはたた別蚘事にお述べたいず思いたす。