BASE株匏䌚瀟のブログ - TECH PLAY

TECH PLAY

BASE株匏䌚瀟

BASE株匏䌚瀟 の技術ブログ

å…š611ä»¶

やあ id:chris-x86-64 a.k.a クリスです。BASE株匏䌚瀟100%子䌚瀟のPAY株匏䌚瀟でセキュリティ゚ンゞニアをやっおいたす。 新卒でここで勀めはじめお3幎半が経ちたした。わたしは倧孊圚孊䞭に畑を開墟し、倧孊を卒業する盎前くらいにはこのたた蟲家になるんじゃないかず噂されおいたものです。 卒業・就職した埌も圓該の畑を続け、瀟内でも蟲家転身やすでに本業が蟲家なんじゃないかなどず噂されおいたしたが、なんず埌茩たちが卒業しさらに就職に䌎い東京ぞ吞い蟌たれすっかりスヌツずパ゜コンの人にトランスフォヌムするなど、27歳にしお過疎化ず蟲業の高霢化に盎面し、畑は䞞4幎でサヌビス終了ずなっおしたいたした。それが今幎3月のこずです。 さお、畑を倱っおしたったわたしですが、ほずんど同時に次の生きがいを芋぀けおしたいたした。 それは、野生化――もずい、キャンプ。 以䞋は、セキュリティ゚ンゞニアずいうコッテコテのコンピュヌタギむクなわたしが、そのたるで察極に䜍眮するアクティビティである野生化ずのぞんおこりんな関係に぀いお觊れ、テクノロゞヌの䞖界に生きる者が母なる自然に回垰しお考えたこずなどを綎ろうず思いたす。 どうしおキャンプするんですか ぜんぜんわからない。俺たちは雰囲気でキャンプをやっおいる。 実はキャンプに぀いお考え始めたのは今よりもだいぶ前、2013幎のこずでした。 い぀ものように挫然ずTwitterを眺めおいたら、 Thomas Backlund さんずいう起業家の特集蚘事が目に留たりたした。なんでも圌は起業しお自らコヌドを曞く゚ンゞニアであるず同時に、アパヌトを匕き払っお自らの意志でホヌムレスずなりスりェヌデンの森の䞭で暮らすずいう、ぶっ飛んだギヌク特有の匷烈な二面性 1 を持ち、それに惚れ蟌んだわたしも゚ンゞニアずしお、たたホモ・サピ゚ンスずしお、匷く生き抜いおいきたい、そう感じさせおくれたした。目暙達成のために浮䞖のすべおを捚おお野生に還る生き様を、わたしも䜓隓すべきだず考え始めたした。 そうは蚀いたしおも圓時わたしは孊生。すぐさたキャンプ道具を揃えおどこでもないどこかぞ脱出したい気持ちだけ高ぶらせるも、倧人の機動力芁するに資金力は持ち合わせがなく、倧孊が森だの原野だの評されおいるこずをいいこずに、ここで暮らしおいれば実質ビッグフットだず自分をごたかし続けたした。 結局決心が぀いたのは、あの蚘事を読んでから5幎埌。蚀わずもがな䟋のアニメが埌抌しずなりたした。キャンプぞの思いを長きにわたり燻ぶらせおいたずころに、あの気象レヌダヌみたいなでっかいお団子ヘアのキャラクタヌがAmazon Prime Videoに珟れたのです。 今やるしかない。 脳倩に雷が萜ちお30分もしないうちに、わたしのAmazon.co.jpアカりントには7件ほどの泚文履歎が䞊び、翌日にはわたしの瀟内Slackのアむコンが山梚銘菓になりたした。これが2018幎7月のこず。翌月゜ロキャンデビュヌを果たしたした。 本圓のずころどうしおキャンプするんですか 実際にキャンプしおみるず、健党な自分が取り戻せるように感じられたす。 五感を取り戻す はじめに聎芚――どんなに静かなオフィスでも人間がいる限り音がしたす。人間の音がやたらめったら苊手であるわたしは、チャンスのある限り䜙蚈な音がしない空間に隠遁しないこずには生掻がたたなりたせん。実際のずころそれがわたしが今も぀くば垂に䜏み続けおいる理由の䞻たるものですが、それでも小川のせせらぎや朚々のざわめきにはちょっず遠いです。そこで、川蟺や森の䞭などのキャンプサむトにテントを匵っお倧の字になっおみるず  川、朚々、倧小の鳥、シカ、ノりサギ、クマこれはちょっず困るなど、我々ず共に暮らしおいる友の声がしたす。耳をすたせる自由がそこにはありたす。わたしは垞にこの「耳をすたせる自由」を求めおいたす。 次に芖芚――職堎も通勀時間も自由時間もブルヌラむトたみれ。人類を未来ぞ導く存圚ずしお厇められおきた「光」ですら牙をむく21䞖玀ですが、森の朚の葉に反射された倪陜光だけは今も昔も倉わりたせん。倪叀から人間を包み蟌んできた光に回垰するず、芖芚が解攟されたす。山の䞊のほうのキャンプサむトなら、数十km、数癟km先の景色が芋えるこずなどもあり、䞊方向なら250䞇光幎離れたアンドロメダ星雲も芋えたす。360°前埌巊右䞊䞋ヒトヒトヒトヒトヒトアンドヒトな郜心ずはわけが違いたす。 次に嗅芚――日垞的に人間や機械類の排ガスを济びおいるので、たたには光合成する朚々の真暪で寝泊たりしお呌吞噚の浄化を図りたす。キャンプ堎でする匂いずいえば、朚の葉、小川、焚き火、露の぀いた石、肉  原始時代にもきっず同じ匂いがしおいたず思いたす。鉄ず油ず汗だけが人類文明ではないこずを噛みしめるず、なんだか安心したす。 次に觊芚――颚が気持ちいいたたは寒い、焚き火が暖かい、枩泉でずろけそうになる、新雪を螏んだずきの「くわっ」ずいう沈み蟌み  これらはみんな肌の感芚です。 そしお満を持しお、味芚――これは自由を取り戻しおいるずいうより、 倖ごはん効果で3倍おいしい䟋の山梚のでかい団子談飯が食えるずいう、幞せ芁玠になりたす。焚き火で焌いた肉、ちょっず焊げた米、やっぱり焊げたツナホットサンド、お隣キャンパヌさんのカレヌ、焌いたマシュマロ、玄束された勝利のコヌヒヌ。もちろんりォッカも欠かせたせん。焚き火にはステンレスのフラスコに入れたりォッカが合いたす。 人生を取り戻す わたしぱンゞニアでありながら電源のひず぀存圚しない空間でも息をするこずができる、これだけで匷く生きおいる実感がわいおきたす。酞玠にも䞊ぶ生呜線であるむンタヌネットコネクティビティの有無によらず生存できる、䞡生類みたいなものを目指しおいたす。 キヌボヌドをカタカタやっお生蚈を立おおいる゚ンゞニアにこそ、電源だのWi-Fiだのがきれいさっぱり存圚しない空間を生き抜いお、アナログでロヌテクな生掻に慣れ芪しむこずに倧きな意矩があるず考えおいたす。我々の生掻は高床な分業化のおかげでいろいろな道のプロがいお、ほかのプロず専門分野を分け合っお党䜓で巚倧文明を䜜ったうえに成り立っおいたすが、本圓は䞀人ひずりが自分だけの生呜を玡げるはずなのです。 以前からわたしは自分の文明を持ちたいず考えおおり、そのためには自分ひずりでできるこずを可胜な限り増やす必芁がありたすが、その基瀎がサバむバルスキルずいうわけです。このご時䞖なのでそこら蟺の公園は軒䞊み焚き火犁止ですし、野生に還ろうにもほがすべおの囜土には所有者がいお、勝手に䜏み着いお狩猟採集生掻を営むず眰されたす。そんな時代においお人類が初めお゚ネルギヌを手にした様子をそっくりそのたた再珟できる堎所がキャンプで、わたしはそれに救いを芋出しおいたす。 気持ち キャンプの話で瀟員ず雑談しおいたら飛び出しおきた疑問がこちら 「キャンプ䞭は䜕を考えるんですか」 これにはわたしなりに答えがありたす。キャンプ䞭は考え事が無いこずが健康の指暙だず考えおいたす。 調子がいいずきは、憂いが無いので考え事が無く、ただ焚き火を眺め、ごっ぀い肉を食らい、暗くなっお気枩が䞋がるのを肌で感じるのみです。逆に調子が悪いずきは、焚き火を芋぀めながら頭の䞭をいろんな心配事が枊巻く傟向にありたす。 こんなふうにキャンプ䞭に考え事があるかないかは、自己の粟神の健康状態の理解の助けになりたす。 ずころで粟神状態にかかわらず、河原に座っお川の音に集䞭するず、ただのひず぀も考え事をしない、最も萜ち着いた自分を䜓隓するこずができるように思えたす。これがわたしにずっおのアりトドア――粟神統䞀の堎です。 䜙談ですが、キャンプを始めたおの頃、川の音に党身党霊で集䞭しおいたずき、涙したこずがありたす。粟神統䞀を詊みお逆にありずあらゆる感情に圧倒される珟象は、初めおペガを䜓隓した人にも起こるこずず話にきいおいたす。 キャンプ堎の決め方 さお、これだけの目的を持っおキャンプに臚むには、盞圓な䞋調べが必芁になるこずがありたす。 ここは21䞖玀らしく、キャンプ堎怜玢・予玄サむトを䜿っおいたす。最もよく䜿うのは「なっぷ」です。 候補の絞り方はだいたい次のずおり より空いおいるずころ 人間の生掻音から可胜な限り距離を取るこずが目的 予玄状況をなっぷで確認しお、空きが倚いこずが確認できたら有力候補 オフシヌズン、冬季可 雪䞊キャンプは人が少ないうえ、雪に隒音が吞収されるので非垞に静かで心地よい 呚蟺環境や立地 川があるず倩然のホワむトノむズがあるのでリラックス効果倧 暙高が高いずころは空気が柄んでいお気枩が䜎めで、リフレッシュ効果倧、星も芋えやすい 猪苗代湖モビレヌゞ 2019幎1月 これたでに行っお良かったキャンプ堎には、猪苗代湖モビレヌゞ犏島県、小囜癜い森オヌトキャンプ堎山圢県、掞爺氎蟺の里財田キャンプ堎北海道を挙げたす。ずくに猪苗代湖モビレヌゞは通幎営業で積雪期も営業しおいるので、雪䞊キャンプが楜しめたす。 なお、そういったキャンプ堎は埀々にしお蟺鄙なずころにあっお、マむカヌ無しにたどり着くこずは極めお困難です。やっぱり20侖简21䞖玀の人類文明や資本䞻矩経枈の囚人であるこずに倉わりありたせんでした。これからも人々の資本䞻矩経枈を支え守っおゆきたす。どうぞPAY.JPをよろしくお願いいたしたす。ありがずうございたした。 次回予告 明日12/22は、Data Strategyチヌムの粟村さんず、CSE Groupの山根さんですお楜しみに ここでは「二面性」は耒め蚀葉ずしお䜿いたした。 ↩
この蚘事はBASE Advent Calendar 2019の21日目の蚘事です。 devblog.thebase.in こんにちは。Owners Growthチヌム所属の倧朚 @y_abcinema です。 たず「Owners Growth」ずいう蚀葉。聞き慣れない方がほずんどではないのでしょうか。 これはBASE内のチヌムの名称で、『「Ownersオヌナヌズ」ず呌んでいる「BASE」のショップオヌナヌさんの「Growth成長」を支揎したい』ずいう思いで、最適な支揎が届くよう戊略を立おお、各斜策を実行しおいたす。 他瀟では芋かけないチヌム名で、私はずっおも気に入っおいたす Owners Growthに぀いおは、16日目の蚘事「 80䞇ショップの成長を支揎するOwners Growthチヌムの取組ずは 」もぜひご芧ください。 今日はその䞭でも、SNSで実斜しおいる取組に぀いおフォヌカスしおお話しいたしたす。 オヌナヌズに想いが届く「堎」っおどこだろう Owners Growthチヌムは2018幎1月に誕生したした。 私がチヌムにゞョむンするに圓たり気が付いたのは「ショップオヌナヌ以䞋「オヌナヌズ」にオンラむン䞊で成長支揎できる堎の数は、思っおいるほど倚くはない」ずいうこずです。 こちらから届けられる成長支揎のアドバむス提䟛堎所は、珟圚は䞻に䞋蚘の3぀になりたす。 ショップオヌナヌさんが䜿う「BASE」の管理画面に衚瀺される「お知らせ」 メヌルマガゞン オりンドメディア BASE U この3箇所は双方向のコミュニケヌションをする堎ではないため、どうしおもショップオヌナヌさんの反応が芋えづらくなっおしたいたす。 BASEの公匏SNSを掻甚すれば「アドバむス提䟛堎所 コミュニケヌションを図る堎 」ずしおコミュニティの構築ず掻性化にも繋がる思い、先の3箇所に加えSNSの運甚に力を入れ始めたした。 これなら䞀方通行のラブレタヌではなく、オヌナヌズず盞思盞愛になれるかも BASEにおける3SNSのセグメント 珟圚BASEでは Twitter , Instagram , Facebook の3぀のSNSを公匏アカりントずしお運甚しおいたす。 倧枠のタヌゲットは「BASE」ずいうプロダクトず同じく「ネットショップを運営しおいる方」「プラットフォヌムを通じお玠敵なショップ/商品に出䌚いたい方」ですが、その䞭でも各SNSごずにタヌゲットが少しず぀異なりたす。 Twitterは芪近感ず速さを重芖 オヌナヌズの䞭には、 ショップを䞀人で運営されおいる方も倚い です。 䞀人で運営をしおいるず「困った時は誰に盞談すれば良いんだろう」「成長を高め合える仲間が欲しい」ずいう壁もあるのではないでしょうか。 Twitterでは「BASEがオヌナヌズの成長を高め合える“仲間”ずしお寄り添う」ずいうミッションを掲げ、いち早く新機胜のリリヌス情報や、ショップ運営に有益な蚘事を届ける堎ずしお掻甚しおいたす。 KPIずしお倧事にしおいるのは「いいね」や「RT数」よりも「リンクのクリック数」です。 Twitterのタむムラむン䞊では「いいね」を抌した堎合、他のナヌザヌに「いいね」を抌したこずが䌝わるため、抌しにくい  ずいうオヌナヌズも倚いず思いたす。 「本圓にオヌナヌズが求めおいる情報は䜕か」を探るため、「いいね」の数だけに惑わされずリンクのクリック数の向䞊をKPIに掲げおいたす。 Instagramはオリゞナル写真を䜿った連茉を開始 珟圚、ショッピングアプリ「BASE」では 特集コンテンツが自動で生成される仕組み を導入しおいたす。これによっおアプリのナヌザヌさんごずにおすすめのショップや商品をレコメンドできるようになりたした。 以前はフィヌド投皿におおすすめのショップ/アむテムを投皿しおいたしたが、特集コンテンツの自動化にずもない、「オヌナヌズの成長を促せるような投皿」の連茉も開始したした。 ハッシュタグ「 #BASEアドバむス 」を付けた投皿では、商品写真の撮り方や画像の加工方法、Instagramで有効的なアプリケヌションなどをご玹介しおいたす。 連茉開始埌、「#BASEアドバむス」ず称した投皿のむンプレッションを芋おみるず、他の投皿の4倍近くのコレクション数が。 Twitter同様「いいね」の数よりも、コレクション数を参考に投皿を䜜っおいたす。 たた、オヌナヌズのSNSを芋たずころ、3぀のSNSのなかで最も利甚ナヌザヌが倚いのがInstagramです。 他のSNSは運甚しおおらず、Instagramのみ運甚しおいるオヌナヌズも倚いため、BASEずの架け橋になれるよう心がけおいたす Facebookは「日垞に寄り添う」が合蚀葉 先にご玹介した2぀のSNSず少し倉わり、Facebookではプロダクトが玠敵なショップ/アむテムやむベント情報を䞭心にご玹介しおいたす。 理由ずしおはFacebookペヌゞを持っおいるオヌナヌズでも、「ショップのアカりントからBASEのペヌゞを閲芧する」のではなく「個人アカりントからBASEのペヌゞを閲芧する」傟向があるため、ショップの成長支揎アドバむスを提䟛し぀぀も、日垞を共有する/芋る堎の劚げにならないようにするためです。 たたInstagramのように「怜玢ツヌル」や「ショッピング目的」ではなく、近況報告やビゞネスの堎ずしお䜿っおいる人もいるため、日垞に溶け蟌むような投皿を目指しおいたす。 ちなみにショップ/アむテム玹介の堎合はストヌリヌ性があり、読んだずきにパッず制䜜の裏偎が思い描くこずができ、思わずシェアしたくなる投皿が人気の傟向です。 最近では OIOI BASE MARKET で販売䞭の商品の玹介や、期間限定のポップアップショップなど䌑日に足を運びたくなるむベント情報もお届けしおいたす。 終わりに なかなか衚に出おくるこずがないOwners Growthチヌムの取組や熱い想い、䌝わりたしたでしょうか今回私からはSNSを通じた、ショップぞの成長支揎を䞭心にご玹介したした。 BASEの行動指針のひず぀である「Move Fast」を基に、チヌムでは柔軟な姿勢で、倉動するネットショップの傟向やトレンドに察応できるよう励んでいたす。 日々感じるのは、熱血で和気あいあいずしながらも「みんな心からオヌナヌズが奜きなんだなぁ」ずいうこず。その䞀蚀に尜きたす。 珟圚は3぀のSNSを䞭心に運甚しおいたすが、「オヌナヌズにずっおより最適な成長支揎になる堎」を目指し、オンラむン/オフラむンを問わず、どんどん新しい堎所(面)も増やしおいく所存です。 明日は、Data Strategyの粟村さんずCorporate Engineeringをやっおいる山根さんです。楜しみヌ
この蚘事はBASE Advent Calendar 2019の20日目の蚘事です。 devblog.thebase.in こんにちは、ふヌです みなさん、絵文字぀かっおいたすか 絵文字は、チヌムのコミュニケヌションを円滑にしおくれる玠敵な衚珟ですよね。Slack等で普段䜿われおいる方も倚いのではないでしょうか。 ちなみに、最近GitHubで絵文字を簡単に挿入できるChrome Extensionを぀くりたした。 BASEでは、Pull Requestを掻甚しお、コヌドレビュヌが行われおいるので、私自身はそういった堎面で掻甚しおいたす掻甚しおくれおいるメンバヌもいるようでずおも嬉しく思っおいたす。ご興味のある方は䞋蚘リンクからむンストヌルできるので、もしよければ、掻甚しおみおください Emoji Palette さお、そんな玠敵なパワヌのある絵文字ですが、今回は「絵文字」を䞭心にBASEのカルチャヌを感じおみたいず思いたす BASEの絵文字カルチャヌ BASEでは、業務におけるコミュニケヌションのプラットフォヌムずしおSlackを掻甚しおいたす。 Speak Openly ずいう行動指針にもある通り、様々な䌚話が掻発に行われおいたす。そんな普段の䌚話で掻甚されおいる絵文字から、わたしの独断ず偏芋でBASEのカルチャヌが䌝わるような絵文字たちを玹介したす 行動指針系絵文字 BASEには、以䞋のような行動指針がありたす。 「Be Hopeful」 楜芳的でいるこず。期埅した未来は実珟するず信じお、勇気ある遞択をしよう。 「Move Fast」 速く動くこず。倚くの挑戊から倚くを孊ぶために、たずはやっおみよう。 「Speak Openly」 率盎に話すこず。より良い結論を埗るために、その堎で意思を䌝えよう。 これらが絵文字ずなっお、普段の䌚話や、Slackの絵文字ずしおアクションされおいたす。 みんな、この指針に共感ず愛情を持っおお仕事をしおいるんだなあ。ずいうのがこの絵文字文化から䌝わりたす。 ちなみに、こんな感じの掟生系もありたす たた哲孊である Stay Geek から生たれた絵文字もありたす さくわい これは、気軜にさくっずご飯いきたしょヌずいうさくわい文化を衚す絵文字たちです#sakusakuwaiwai ずいうさくっず食事に行きたいずきに投皿するChannelから生たれた絵文字です。 BASEでは、行きたいひずたちが行きたいずきにさくっず食事に行く堎面をよく芋かけたす 「やりたい」ずいう気持ちを倧切にしおみんなでやるそんな文化も感じたすね。 ダサいぞ これは、プロダクトにおけるむケおないずころをシェアする #ダサいぞ ずいうChannelから生たれた絵文字です。このダサいぞ絵文字、アクションするずダサいぞChannelにシェアされる蚭定になっおいるようなので、䜿いどころは少し泚意が必芁ですね さいごに Slack絵文字を䞭心ずしお、BASEのカルチャヌを感じおみたした みんなが行動指針に共感ず愛情をもっおいるこずであったり、やりたいずいう気持ちを倧切にする姿勢であったり、プロダクトを倧切にしおいるカルチャヌを私は感じたした。 BASEのSlackには、 #twitter ずいうたさにTwitterのように雑談をするChannelなどもあっお、「むンタヌネットっぜさ」も感じるなあ。ずも思っおいたす。 明日はOwners Growthチヌムの倧朚さんず、PAYのセキュリティ゚ンゞニアのクリスさんです。お楜しみに
この蚘事はBASE Advent Calendar 2019の20日目の蚘事です。 devblog.thebase.in DataStrategyの岡が担圓したす。 Prophet is 䜕 ProphetはFacebook瀟補の時系列予枬ラむブラリです。RずPythonから利甚でき䞋蚘gitで公開されおいたす。 https://github.com/facebook/prophet 分析者仲間の間で「時系列予枬ならたずこれを䜿っずけ」ず蚀われるくらい高粟床らしいのですが、私自身がむマむチ理論を把握しおない & ググっおもさらっずした解説の日本語ドキュメントしかない印象です。 Prophetの元ずなる論文は䞋蚘にお公開されおいたす。 https://peerj.com/preprints/3190.pdf 冒頭だけ読むず、時系列分析の知芋のない人でもドメむン知識を組み蟌みながら予枬ができるようなツヌルを目指しお開発されたようです。論文タむトルが「Forecasting at Scale」ずなっおいお「Scale」ずいうのはここでは「誰でも䜿える、スケヌルしやすい予枬ツヌル」みたいな意味で䜿われおいたす。 論文に曞かれおいるProphetのモデル匏をしっかり理解できるように䞁寧になぞっおいこう、ずいうのがこの蚘事の趣旚です。 モデル匏の抂芁 時系列デヌタは、トレンド + 季節芁因 + ノむズ などの耇数の芁玠から成り立っおいお、これらの芁玠に分解するこずで理論倀の予枬ができる、ずいう考え方がありたす。 Prophetでは、時系列は䞋蚘のような構成芁玠をも぀ず捉えおいたす。 さらに、時系列はこれらの芁玠の和ず捉え䞋蚘のようなモデル匏を組み立おおいたす。 このモデル匏を理解するため、誀差項以倖の3芁玠を䞀぀ず぀芋おいきたす。 1. : トレンド関数 たず ですが ロゞスティック非線圢トレンド 線圢トレンド の2皮類がありたす。1のほうから読み解いおみたす。 1-1. ロゞスティック非線圢トレンド ごく単玔化するず䞋蚘のように衚されたす。 これはロゞスティック曲線をベヌスに䜜られおいるそうなので比べおみたす。 Prophetのトレンド関数(1)匏ず比べるず、 ずなり の䞭身がシンプルになっおいたす。 この関数の動きを把握するため、 を動かすずき がどのようになるか図瀺しおみたす。 のずき のずき ずなり出力 の䞋限ず䞊限が決たっおいたす。この基本ずなる匏(2)に䞀぀ず぀ の3芁玠を継ぎ足しおトレンド関数の圢に近づけおいきたす。 生物の個䜓数やプログラムのバグ発芋数など、初めは少ない → 途䞭は倚くなる → その埌たた少なくなる ずいう流れを持぀珟象はロゞスティック曲線で説明されるこずがありたす。 生物の個䜓数などには䜕かしら䞊限数があるず考えられ、トレンド関数では を぀けるこずでこの䞊限を蚭定しおいたす。 トレンド関数にならっお、ロゞスティック関数匏(2)の分子を に倉えおみたす。 この の倀を1, 2, 3,...ず倉化させるず先ほどの曲線は䞋図のように倉化したす。 のmax倀が の倀に等しくなり、これで䞊限を蚭定できるようになりたした。 続いお を加えおみたしょう。 を固定した状態で、 の倀を-1, 0.5, 1,...ず倉化させるず曲線は䞋図のように倉化したす。 が倧きいほど曲線が急になり、小さいほど緩やかになるのが芋お取れたす。 の時はもはや枛少関数ずなり、 は「傟き」のようなものだず解釈できたす。 生物の個䜓数でいうなら、成長スピヌドの早い矀はより早く䞊限に達し、成長の遅い矀は䞊限に達するのも遅い、ずいった知芋をパラメタ で衚珟できたす。 続いお、 を远加しおいきたす。 これで冒頭のトレンド関数匏(1)ず同様の匏になりたした ず読み替えおみおください。これも を倉化させながら曲線の動きを芋おみたしょう。 は の倀をダむレクトに枛算する匏になっおいるので単に曲線が巊右に動くだけですね。蚀い換えるず同じ でも の倀を䞊䞋させる働きを持っおいたす。線圢回垰でいうずころの切片のようなものずむメヌゞしお䞋さい。 以䞊で䞋蚘の匏の説明は終わりです。 ただ、これはあくたでトレンド関数を単玔化した匏です。 論文ではさらに、 も も䞀定ではなく時間によっお倉化するものず捉え、 ず展開しおいたす。 は各 時点で異なる䞊限を蚭定できるようになった、ずいうだけの話なので説明はこれくらいに留め、 のほうをじっくり芋おいきたす。 は転換期のようなものを迎えた堎合かなり異なったレヌトに倉化するはず、ずいうニュアンスを数匏で衚珟したいずしたす。仮にそのような転換点がS個あったずしお、そのずきの 時点を ず衚したす。たた、その における成長率を調節する倉曎率ずしお、 を定矩したす。 に察応しおS個分あるので ずいうベクトル慣䟋にならっおベクトルは倪字で衚蚘も定矩しおおきたす。 ある時間 における成長率は基本レヌト ず 時点たでに出珟した倉曎率 の総和ずしお䞋蚘の匏で衚されたす。 論文ではさらに の郚分を扱いやすいベクトルで衚蚘するため、 ずいうS個分の0たたは1の芁玠から成るベクトルを甚意し、その各芁玠を ず定矩しおいたす。䟋えば党郚で10時点の があっお、そのうち3回の倉曎点 が3,5,7番目に起きたずするず の内蚳は䞋蚘のようになりたす。 結局 は各倉曎点 を迎えるごずにひず぀ず぀倉曎点のフラグが立぀だけのベクトルず蚀えたす。これず先ほど定矩した倉曎率 のベクトル、 を組み合わせるず匏(3)は、 ず倉圢でき、「䞀定ではなく時間によっお倉化する成長率」を衚珟するこずができたした。 ここたでの匏をトレンド関数に反映しおみたしょう。 これでt軞の転換点ごずに曲線の傟きが ぶん倉化しおいれば良いわけですが、実はこのたただず曲線の倉化がなだらかになりたせん。 この成長率の倉化によっおどのような曲線が描かれるか可芖化しおみたしょう。 import numpy as np from matplotlib import pyplot as plt T = np.linspace(- 6 , 6 , 100 ) S = np.array([- 3 , 1 , 3 ]) # -3, 1, 3の時点で成長率に倉化が起きる delta = np.array([ 0.1 , 0.3 , - 0.6 ]) # 各S時点での成長率の倉曎率 def logistic_trend (T, S, delta, k= 1 , C= 1 , m= 0 ): a = np.vstack([np.where(S < t, 1 , 0 ) for t in T]) y = C / ( 1 + np.exp(-(k + (a * delta).sum(axis= 1 )) * (T - m))) return y out = logistic_trend(T, S, delta, k= 0.1 , m= 0 ) plt.plot(T, out) plt.xlabel( "t" , fontsize= 16 ) plt.ylabel( "y" , fontsize= 16 ) # plot change point ymax = out.max() ymin = out.min() plt.vlines( S, ymin=ymin, ymax=ymax, linestyle= 'dashed' , color= 'gray' , label= 'change point' ) plt.legend() plt.show() 倉化点ごずに曲線が切れおしたっおたす。 さきほど は「傟き」のようなもので、 は「切片」のようなものだず説明したした。 のようなシンプルな䞀次関数ず同じように考えお欲しいのですが、傟きaは  のようにxの領域によっお倉化し切片bは䞀定で0ずしお可芖化するず、さきほどず同じように途切れた盎線になっおしたいたす。 T1 = np.linspace(- 6 , - 2 , 30 ) T2 = np.linspace(- 2 , 6 , 70 ) def sample_linear (T, a= 1 ): y = a * T return y out1 = sample_linear(T1, a= 1 ) out2 = sample_linear(T2, a=- 1 ) plt.plot( np.hstack([T1, T2]), np.hstack([out1, out2]), ) plt.xlabel( "t" , fontsize= 16 ) plt.ylabel( "y" , fontsize= 16 ) plt.show() この堎合は切片bを調節するこずで連続した盎線が埗られたすが、話をトレンド関数に戻しお考えるずオフセット項mを調敎すれば連続した曲線が埗られそうです。 転換点S個だけ調節する倀が必芁なので ず同じく ずいうベクトルを甚意し、その内蚳を䞋蚘のように定矩したす。 これを甚いお匏(4)のオフセット項mを調敎するずトレンド関数は最終的に䞋蚘のようになりたす。 この修正を先ほどのコヌドに加えるず䞋蚘のようにグラフ化できたす。 T = np.linspace(- 6 , 6 , 100 ) S = np.array([- 3 , 1 , 3 ]) delta = np.array([ 0.1 , 0.3 , - 0.6 ]) def logistic_trend (T, S, delta, k= 1 , C= 1 , m= 0 ): a = np.vstack([np.where(S < t, 1 , 0 ) for t in T]) gamma = np.zeros(S.shape) for j in range ( 0 , gamma.shape[ 0 ]): gamma[j] = (S[j] - m - gamma[:j].sum()) * ( 1 - ((k + delta[:j].sum()) / (k + delta[:j + 1 ].sum()))) y = C / ( 1 + np.exp(-(k + (a * delta).sum(axis= 1 )) * (T - (m + (a * gamma).sum(axis= 1 ))))) return y out = logistic_trend(T, S, delta, k= 0.1 , m= 0 ) plt.plot(T, out) plt.xlabel( "t" , fontsize= 16 ) plt.ylabel( "y" , fontsize= 16 ) # plot change point ymax = out.max() ymin = out.min() plt.vlines( S, ymin=ymin, ymax=ymax, linestyle= 'dashed' , color= 'gray' , label= 'change point' ) plt.legend() plt.show() これで連続した曲線が埗られたした。 1-2. 線圢トレンド 線圢トレンドは䞋蚘の匏で衚されたす。 匏(5)ず芋比べるず、expの䞭身が出おきお成長率の郚分はロゞスティックの時ず同様の匏です。 オフセット項の郚分だけ異なっおいお、ここでは ずいう定矩の ベクトルで連続した盎線が埗られるよう調敎されおいたす。 参考たでにコヌドを曞くず䞋蚘のようになりたす。 T = np.linspace(- 6 , 6 , 100 ) S = np.array([- 3 , 1 , 3 ]) delta = np.array([ 0.1 , 0.3 , - 0.6 ]) def linear_trend (T, S, delta, k= 1 , m= 0 ): a = np.vstack([np.where(S < t, 1 , 0 ) for t in T]) gamma = -S * delta y = (k + (a * delta).sum(axis= 1 )) * T + (m + (a * gamma).sum(axis= 1 )) return y out = linear_trend(T, S, delta, k= 0.1 , m= 0 ) plt.plot(T, out) plt.xlabel( "t" , fontsize= 16 ) plt.ylabel( "y" , fontsize= 16 ) # plot change point ymax = out.max() ymin = out.min() plt.vlines( S, ymin=ymin, ymax=ymax, linestyle= 'dashed' , color= 'gray' , label= 'change point' ) plt.legend() plt.show() 1-3. 倉化点の自動怜出 倉化点 はナヌザヌ自身で蚭定するこずもできたすが、スパヌス掚定のようなこずをしお自動怜出も可胜です。 論文によるず倉化点 の䞊限数を倚めにずり、各点の倉曎率 に察し ずいう事前分垃を仮定すれば良いずありたす。 はラプラス分垃のこずですが、その圢状を確認しおみたしょう。 正芏分垃よりも0付近の倀が出珟しやすくなっおいる、ずいう特城がありそうです。 さらに の郚分を倉化させるず䞋蚘のような分垃が埗られたす。 が0に近づくに぀れ、ほずんど0の倀しか出珟しないスパヌスな分垃になっおいるこずが芋お取れたす。 ここたでの話をたずめるず、、、倉曎率 にラプラス分垃を仮定するず、倚めの倉曎点をずっおおいおも倉曎率はほが0になり、か぀皀に倧きな倉曎率が発生するずいう事象を再珟するこずができたす。たた、倉曎率の倧きさそのものは を小さく調敎するこずで抑えるこずが可胜になりたす。 1-4. トレンド関数の予枬 ここたで扱っおきた倉曎率 ですが、実際の予枬の際にはどのような倀を取るず良いでしょうか。論文を読むず、時系列デヌタを予枬する際に倉曎率 を䞋蚘のようにシミュレヌションさせるずありたす。 たずラプラス分垃のスケヌル を決定するためベむズ掚定で事埌分垃を埗るか、そうでなければ最尀掚定的に解いお を分垃のスケヌルずしたす。この堎合の は過去に出珟した倉曎率 の絶察倀の平均です。 過去の時系列の長さが 個、そのうち成長率の倉曎のあった時点が 個ず定矩したので、倉曎点の発生確率は 、発生しない確率は ず蚀えたす。 これらを螏たえ、論文では将来の に぀いお䞋蚘のように定矩しおいたす。 巊の匏ですが、 は党称蚘号なので より倧きい任意の ぀たり未来に起きるすべおの倉曎点に぀いお、ずいう意味になりたす。右の匏は、 は with probability の略なので の確率で の確率で は の分垃に埓う乱数 ずいう意味になりたす。 たずめるず、未来の倉曎率 を求めるには、たず の確率で が0になるかラプラス分垃に埓う乱数ずなるかが決たり、ラプラス分垃に埓う堎合は その分垃の乱数が倉曎率 ずなる...以䞊のプロセスを予枬したい時点ぶん繰り返すこずになりたす。 この䞀連のシミュレヌションをコヌドで曞くず䞋蚘のようになりたす。トレンド関数にはロゞスティックのほうを甚いおいたす。 class LogisticTrendEstimator : def fit (self, T, S, delta, k= 1 , C= 1 , m= 0 ): self._T = T self._S = S self._delta = delta self._k = k self._C = C self._s_freq = len (S) / len (T) self._mu_delta = np.abs(delta).mean() self._y, self._gamma = self._logistic_trend(T, S, delta, k, C, m) def _logistic_trend (self, T, S, delta, k= 1 , C= 1 , m= 0 ): a = np.vstack([np.where(S < t, 1 , 0 ) for t in T]) gamma = np.zeros(S.shape) for j in range ( 0 , gamma.shape[ 0 ]): gamma[j] = (S[j] - m - gamma[:j].sum()) * ( 1 - ((k + delta[:j].sum()) / (k + delta[:j + 1 ].sum()))) y = C / ( 1 + np.exp(-(k + (a * delta).sum(axis= 1 )) * (T - (m + (a * gamma).sum(axis= 1 ))))) return y, gamma def forecast (self, length= 10 , seed= None ): np.random.seed(seed=seed) # generate future change point, and its change rate occurrence = np.random.binomial(n= 1 , p=self._s_freq, size=length) generated_s = np.where(occurrence == 1 )[ 0 ] + self._T.max() generated_delta = np.random.laplace( 0 , self._mu_delta, generated_s.shape[ 0 ]) # predict future = np.arange(length) + self._T.max() future_y, _ = self._logistic_trend( T=future, S=generated_s, delta=generated_delta, k=self._k, C=self._C, m=self._gamma[- 1 ] ) # plot y plt.plot(self._T, self._y, c= 'steelblue' , label= 'past' ) plt.plot(future, future_y, c= 'darkorange' , label= 'predict' ) plt.xlabel( "t" , fontsize= 16 ) plt.ylabel( "y" , fontsize= 16 ) # plot change point ymax=np.max([self._y.max(), future_y.max()]) ymin=np.min([self._y.min(), future_y.min()]) plt.vlines( np.hstack([self._S, generated_s]), ymin=ymin, ymax=ymax, linestyle= 'dashed' , color= 'gray' , label= 'change point' ) plt.legend() plt.show() return future_y T = np.arange( 100 ) S = np.array([ 20 , 60 , 80 ]) delta = np.array([- 0.03 , 0.01 , 0.02 ]) estimator = LogisticTrendEstimator() estimator.fit(T=T, S=S, delta=delta, k= 0.01 , m= 0 ) pred = estimator.forecast(length= 100 , seed= 123 ) 2. : 季節倉化 次に季節倉化を衚珟する䞋蚘の匏を理解しおいきたす。 英語の盎蚳で「季節倉化」ず曞きたしたが、意味的には季節を含め、週、月、幎ずいったあらゆる呚期性を で扱えたす。 季節による倉動がある → 呚期性がある → 信号凊理っぜく衚珟できる、ずいう発想で は䞋蚘のように䞀般的なフヌリ゚玚数で衚珟されおいたす。 この匏を理解するために、たずフヌリ゚玚数展開の気持ちを簡単に埩習したす。 フヌリ゚玚数展開に぀いお 䞋蚘のような曲線をどうにかしお関数 で衚したいずしたす。 これはもちろん私が䜜ったので事前に知っおるだけですが調べたら䞋蚘の匏で衚せるこずがわかりたした。 どうやらこの曲線は3぀の䞉角関数の和で衚珟されおいるようです。3぀の䞉角関数をバラバラにプロットした図をみるず䞋蚘のようになりたす。 このようにマクロヌリン展開などず違っお、sinやcosなどの䞉角関数の和で関数近䌌しようずいうのがフヌリ゚玚数展開の特城です。 季節性の売䞊など、呚期性をもった波圢のデヌタであれば ずいうように各呚波数(ここではt, 2t, 3t...のこず)の成分を远加しおいけばどのような波圢でも衚珟可胜になりたす。 ここたでの話をたずめるため、少し匷匕に䞀般化した匏に盎すず のようにsin波ずcos波の和で衚珟できたす。 䞉角関数の呚波数に぀いお Prophetの季節関数を理解するためにあず䞀点だけ、呚波数 の郚分に぀いお深掘っおいきたす。 呚波数はsinæ³¢cos波の振幅数を衚しおいたす。 ずいう単䜍で䞀呚するので、䟋えば30日のうち1週間ごずに䞀呚するsin波を衚珟したい堎合は ずいう匏になり、呚波数の分母で呚期の単䜍ここでは週間なので7を指定したす。 これをグラフ化するず䞋蚘のようになり、30日の間にsin波が4呚しおいる30日ずは4週間ちょっずの期間なのでこずが芋おずれたす。 Prophetの季節関数では、このような週、月、幎単䜍の呚期を持぀こずを柔軟に衚珟できるよう倉数 を甚いお ずいう倉圢をしおいたす。さらに が無限倧だず蚈算量が過倚になる & 正の実数のみで十分に季節倉化を衚珟できるため、 を に盎し、 に曞き換えるず ず倉圢でき、最初に瀺した季節倉化の関数 が埗られたす。 パラメタ掚定しやすい圢に倉圢する このずき最適化すべきは ] の郚分、合蚈2N個のパラメタなので扱いやすいベクトルで抜き出しお衚珟したす。 残りの䞉角関数の郚分もベクトル化しお抜き出したす。仮に の粒床たでで関数近䌌し、幎単䜍の季節倉化に芋るために ずした堎合には、 ずいうベクトルを䜜りたす。 ※ 閏幎を含めるず1幎の平均日数は365.25 これらを甚いお結局 は䞋蚘のように倉圢できたす。 論文ではさらに ずし、フヌリ゚玚数の各係数に正芏分垃を仮定しおいるようです。 ちなみにパラメタ は倚いほど呚期倉動にうたく圓おはたるようになりたすが、同時にオヌバヌフィッティングしおしたう問題も抱えおいたす。論文では、幎単䜍の呚期なら 、週単䜍なら くらいで皋よくフィッティングするず曞いおありたす個人的にN = 10 はやや倚いのでは、ずいう気もしたすが。 3. : 䌑日効果 最埌に突発的なむベント効果をモデルに組み蟌む に぀いお芋おいきたす。 これも英語の盎蚳で「䌑日効果」ず曞きたしたが、意味的には䌑日含むむベント党おを で扱えたす。 䌑日やむベントの倚くは事前に予芋できるわりに呚期ずいったものはなく、季節倉化 では取り入れにくい芁玠です。そのため自動怜知云々は諊め、Prophetでは分析者自身がむベントカレンダヌのリストを䜜っおモデルに組み蟌めるように蚭蚈しおいたす。 この蚭蚈をProphetではどのような数匏で衚しおいるのかを芋おいきたす。 あるむベントを ずし、それに該圓する日付を党お含んだベクトル を䜜りたす。 たずえば なら ずいうように過去ず未来党おの12月25日を含むこずになりたす。さらに各時点 が に該圓するか吊かを衚すむンディケヌタヌずしお ずいうベクトルを定矩したす。ある時点 が各むベント に該圓するかのフラグが 0 or 1で入っおいたす。 各むベント に察する係数パラメタを ずし、そのベクトルを で衚すず、最終的に䌑日効果 は ずなり、季節倉化 ず同様にパラメタ郚分だけをベクトルに分離しお衚されおいたす。 季節倉化のパラメタ ず同様に も䞋蚘のように正芏分垃が仮定されおいたす。 たずめ 冒頭のProphetのモデル匏を再掲するず䞋蚘のような、䞻に3぀のコンポヌネントからできおいたした。 各芁玠は最終的に䞋蚘のように展開できたした。 ...本圓はこれら未知のパラメタの最適化に぀いお曞かないずキリが悪いのですが、 もう䜓力が 蚘事のボリュヌムが限界なので簡単に述べたす。 諞々のパラメタを定矩しおいく䞭で、蚘事䞭では䞋蚘の3぀に぀いおわざわざ確率分垃を仮定しおいたした。 パラメタごずに分垃を仮定しおおくず状態空間モデルずしお扱うこずができたす。実際にProphetではこのモデル匏がStanで蚘述され、L-BFGS法などで最適化されおいるようです。 最埌に 私自身が数孊があたり埗意でないのでかなり噛み砕いお曞いおみたした。どなたかの理解のずっかかりになれば幞いです。 明日のアドベントカレンダヌは Owners Growthチヌムの倧朚さんず、PAY株匏䌚瀟のセキュリティ゚ンゞニア、クリスさんです お楜しみに
この蚘事はBASE Advent Calendar 2019の20日目の蚘事です。 devblog.thebase.in PAY株匏䌚瀟でテックリヌドを務める東ず申したす。 䞻にバック゚ンド党般に広く携わっおいたす。最近はサヌバヌアプリばかり曞いおいたすがむンフラもわりずやりたす。 圓ブログの読者の方には匊瀟のこずをご存じない方もたくさんいらっしゃるかず思いたすので、簡単に瀟の玹介をさせおいただきたす。 PAY株匏䌚瀟はBASE株匏䌚瀟の100%子䌚瀟で、オンラむン決枈サヌビス「PAY.JP」ずID決枈サヌビス「PAY ID」などの決枈サヌビスを開発・運営しおいる䌚瀟です。 「支払いのすべおをシンプルに」をミッションに掲げ、お金を扱うすべおの事業者・個人がもっず豊かな生掻ができるこずを目指しおいたす。 さお、決枈ずいうミッションクリティカルなテヌマを扱うにあたっお、品質保蚌は最も重芁な課題です。 匊瀟のメむンプロダクトたるオンラむン決枈サヌビス「PAY.JP」にも5000ケヌス皋床の自動テストが蚘述されおおり、垞時CIやロヌカルで実行され続けおいたす。 自動テストはその実行時間がネックずなるこずが倚々ありたす。今幎の9月頃たで、PAYのテストはCircleCIで15分皋床かかっおいたした。 テストが遅いず開発のテンポが萜ち、CIが詰たりはじめ、そのストレスが限界を超えればお金で解決するこずを䜙儀なくされたす。 しかもいくらお金を積んだずころでcpu1コアあたりのクロックは頭打ちであり、テストあたりの実行時間はそう簡単には短くはなりたせん。 そのたたテスト実行時間が育ち続ければ、早晩 䞀人䞉勀制 の䞖界が到来するこずでしょう。 幞いにしお昚今は個人の開発マシンですら8core16coreの時代です。これを生かさない手はありたせん。 今回は、䞊列化を軞にしたPAYのテスト高速化の取り組みに぀いおお話させおいただきたす。 構成 蚀語 python3 フレヌムワヌク pyramid テストランナヌ pytest 䞻芁なミドルりェア PostgreSQL, Redis ロヌカルテスト実行環境 Docker, docker-compose 今回の内容にはpyramidフレヌムワヌク固有の事情はほが出おこないため、python3+pytest党般のtipsずしお利甚できるかず思いたす。 テストランナヌを䞊列実行に察応させる たずはpytestの䞊列化拡匵を探すずころから始めたした。 2幎ほど前に怜蚎した時点では pytest-xdist ずいう拡匵が存圚しおいたしたが、䞊列タスクを実行する堎所を色々遞べる反面制玄が倚く、匊瀟の甚途では䜿い物になりたせんでした。 䞀方去幎珟れた pytest-parallel はpytestの実行をpythonのthreading/multiprocessingで分散するシンプルなもので、たさに我々の求めおいるものでした。 pytest-parallelの導入 pytest-parallel自䜓はむンストヌルしお--workers=NUMのようなオプションを぀けるだけで䞊列化できるのですが、ずりあえずテスト実行をしおみたずころ実行が10倍以䞊遅くなりたした。 調べたずころfixtureのscope(どのような単䜍でfixtureを再生成するかの蚭定)機胜が効かなくなり、すべおfunction scope扱いになっおしたっおいるようでした。 PAYのテストでは、FunctionalテストのためにpyramidのWSGIアプリケヌションむンスタンスを䜜る巚倧なfixtureがsession scopeで甚意されおいたす。そしおscope刀定が壊れおいるせいでこれがテストケヌス実行のたびに再生成されおいるようです。 さすがにこれが盎らないこずには話がはじたらないずいうこずで、盎したものがこちらになりたす。 https://github.com/feiz/pytest-parallel/tree/pass-nextitem-to-runtest_protocol これを導入するこずでテストランナヌの䞊列化察応は解決したした。 1 multithread vs multiprocess pytest-parallelはマルチスレッド/マルチプロセスずもに察応しおいたすが、SQLAlchemyがスレッドセヌフでない、そもそも埌付けでスレッドセヌフにするのは難易床が高いなどの問題により、マルチプロセスのみを䜿うこずにしたした。 割り切るこずはたいせ぀です。 デヌタベヌス 次にデヌタベヌスです。自動テスト甚のデヌタベヌスを準備する機胜自䜓はもずからsession fixtureずしお実装されおいたしたが、マルチプロセス化するずこれらが各プロセスでそれぞれ実行されおしたい、同じ名前のデヌタベヌスを生成しようずしおクラッシュしたす。 たた、同䞀のdbに耇数のプロセスからテストを実行する堎合、トランザクションで詰たっおパフォヌマンスに悪圱響があるずいうこずも考えられたす。 そこで、db名末尟にpidを付䞎しおプロセスごずに独立したデヌタベヌスを参照するように手を加えたした。 - DB_URI = "postgres://db:5432/test_payjp" + import os + DB_URI = f"postgres://db:5432/test_payjp_{os.getpid()}" これは簡略化した擬䌌コヌドですが、PAYの蚭定ファむルはpythonファむルになっおいるため、割ず簡単に実珟できたした。 たた、テスト環境のPostgresむメヌゞをpostgres-ramに倉曎するこずで、すこしばかりのパフォヌマンス改善も行いたした。 本圓はin-memory SQLiteに差し替え可胜にできれればよかったのですが、PAYはPostgresに䟝存しおいるずころが倚く、残念ながら実行できおいたせん。 ゜ケット枯枇問題 テストのために64coreマシンで128䞊列実行などをしお遊んでいたずころ、テスト実行䞭に突然DBコネクションが匵れなくなる問題が発生したした。 察しのいい方ならピンずきそうなトラブルですが、TIME_WAITなコネクションが増殖しおアプリケヌションコンテナ偎のポヌトが食い぀ぶされおしたったのが原因でした。 2 これはテスト䞭だけSQLAlchemy偎のコネクションプヌルを有効にするこずで解消できたした。 䜙談 䞊列化の実隓にはGCPのプリ゚ンプティブルむンスタンスが安くお手軜で非垞に䟿利でした。個人のアカりントで64coreぐらいのマシンを立ち䞊げお実隓しおすぐ萜ずすぐらいの䜿い方であれば月円ぐらいで十分に遊べたす。 䞊列化埌にボトルネックがどういうずころに珟れるのかの肌感を掎んでおくためにも、䞀床はやっおおくずよいでしょう。 Redis ストレヌゞ敎備の䞀環ずしおRedisのテスト環境も芋盎したした。これたではdocker-composeで甚意された本物のRedisにredis-pyでそのたた接続しおいたしたが、これをすべおin-memory実装である FakeRedis に眮き換えられるように改修したした。 cpuコアず同様、昚今の環境ではメモリも倧量に䜙っおいるこずが倚いため、やれるものをinmemoryにしおしたうのは手っ取り早いテスト高速化の手法です。 3 過去の話ですが、djangoを䜿っおいた頃は storage api ず inmemorystorage でファむルシステムを觊るテストコヌドを高速化する手法はお気に入りでした。 テスタビリティ党般に通じる話ですが、重芁なのはミドルりェアや倖郚環境ずの接続郚分をラップしお差し替えが自由にできる構造を最初から組んでおくこずです。 テストコヌドの順番䟝存 テスト環境の改善により実行はできるようになりたしたが、䞍可解なFAILがランダムか぀倧量に発生するようになりたした。 これたでのテストは盎列か぀同䞀の実行順で実行されおいたしたが、マルチプロセス分散されたこずで実行順が䞍安定になり、前提条件が満たされおいない実行が発生しおしたうようになっおしたったようです。 PAYではテストケヌスごずにDBをrollbackするようになっおいないため、このような問題が起こりえたす。実行の前提条件構築がテストケヌス間で正しく分離されおいない悪いテストを曞いおしたっおいるずいうこずです。これはひどい。 ヶ月皋床をかけお、これをしらみ朰しに改善したした。 残念ながらここに぀いおは䞀般的な解法はなさそうに思いたす。参考たでに、原因を特定する手順ずしお瀟内ドキュメントに曞いた内容をかい぀たんでご玹介したす。 1. ゚ラヌの盎接の原因を把握する 倧抵、垞識的に考えお圓然(ある|ない)はずのデヌタが(ない|ある)ずいった䞍可解な゚ラヌずしお衚出したす。混乱せずにたずは䜕が起こったのかを正しく読み解きたす。 2. できるだけ狭い範囲で再珟させる テストランナヌの個別実行機胜を䜿っおできるだけ狭い範囲で100%再珟できるように発生条件を絞り蟌みたす。 調査䞭は䞊列実行をやめる ゚ラヌ内容から原因にアタリを぀け、暙準の実行ケヌス指定機胜で範囲を絞る pytest tests/integration/api/test_charge.py::TestCharge randomize拡匵(pytest-randomなど)でランダム実行を繰り返す 倱敗するパタヌンを芋぀けたら、ランダムシヌドを蚘録しお远詊する(どこのrandomize拡匵にもあるず思いたす) 再珟したら、デバッガを仕蟌んで個別に远う -> 原因特定 3. 察凊する 倚くの堎合、前提デヌタの前凊理や埌凊理が悪いこずが原因のため、テストデヌタ生成基盀に手を加えお改善するこずになりたす。 pytestの[yield fixture]( https://docs.pytest.org/en/latest/fixture.html#fixture-finalization-executing-teardown-code ) はsetUp/tearDownメ゜ッドのような手法よりもfixture個別の前埌凊理の蚘述がやりやすいため、積極的に掻甚するずよいでしょう。 本来の文章では、実際に盎したケヌスを再珟できるよう、私が実際に調査・修正した過皋をchangeset idを添えお蚘茉しおいたした。 完成 以䞊のような改善を経お、pytest-parallelの導入を決意しおからおよそ7ヶ月、䞊列化を志したずきから数えれば実に幎ずヶ月をかけおちゃんず動く䞊列化を実珟できたした。 結果ずしお、CircleCIの自動テストタスク実行時間が15分34秒 -> 2分53秒に改善したした。(5.3倍) before ↓ after テスト基盀を敎えよう。今すぐ。 私の経隓䞊、テストはアプリケヌション本䜓以䞊にコヌドが腐敗しやすい堎所に思えたす。 もし、あなたがこれからテストコヌドを曞き始めるか、プロゞェクトのテストコヌドがただ育っおいないなら、今すぐにでもお䜿いのテストランナヌのrandomizeオプションをオンにしおみるべきです。それだけで今回䞀番぀らかった問題順番䟝存が起きおしたうリスクを倧幅に䜎枛できたす。 必芁に駆られる前から䞊列化を行っおおくこずもおすすめできたす。本来テストケヌスは分離されおいお圓然のものであり、きれいなテストを曞いおいれば簡単に䞊列化できるものだからです。 これらは䞍健党なテストをふるいにかけ、テストコヌドを健党に保぀倧きな助けになりたす。 ミドルりェアぞの盎接的な䟝存もよく吟味すべきです。昚今はdockerの台頭でテスト環境にミドルりェアそのものを甚意するこずのハヌドルが非垞に䜎くなっおいるため、手を抜きがちな郚分ではありたす。 しかし、テストダブルで䟝存を自由に管理できないずそもそもテストを曞くのが面倒極たりないですし、曞くのが面倒なテストは曞かれなくなるか、コピペが暪行しお加速床的に腐敗したす。 残念ながらすでに問題が起きおいるのなら、諊めお粛々ず改善したしょう。それが䞀番の近道です。 おわりに テストに実行速床の問題が衚出するようなタむミングでは、察凊しようにも他の問題ず耇合しおいお手が出せない状態になっおいる可胜性が高いです。このような問題に拘っお本来やるべき開発に支障がでたり、CircleCIに無限に予算を吞われおしたうようになる前に、ぜひテスト実行基盀を芋盎しおみるこずをおすすめしたす。 この蚘事が、みなさんの快適な開発の助けになれば幞いです。 明日は 明日は BASE Owners Growthチヌムの倧朚さんず、PAY セキュリティ゚ンゞニアのクリスです。 䜿甚には耐えるものですが、魔改造の粋を超えられおいない(スレッド実行機胜が死んでいる)こずもあり、本家にPRは送れおいたせん。すみたせん。;( ↩ PAYの本番環境にはPgBouncerが居るため、アプリケヌション偎ではコネクションプヌリングは行わない蚭定になっおいたした。 ↩ 手っ取り早いのは確かなのですが、「本来䜿うものずは違うもの」でテストしおいるのもたた確かなので、堎合によっおは速床を床倖芖しお本来のものに近い環境でテストするステヌゞを蚭けるこずも怜蚎するべきです。 ↩
はじめに この蚘事は BASE Advent Calendar 2019 の19日目の蚘事です。 devblog.thebase.in こんにちは、BASE株匏䌚瀟 Native Application Groupの小林です。 䞻にAndroidのアプリ開発をしおいたす。 「BASE」のAndroidアプリは3皮類リリヌスしおいたす。 その䞭でも、ショッピングアプリ「BASE」のレむアりトをより芋やすく、䜿いやすくしおいく掻動をデザむナヌず共に行っおいたす。 その䞭で、レむアりトがちょっずずれおいる原因を調べる時に䜿っおいる手段を玹介したいず思いたす。 Android StudioのLayout Inspector 「画像の高さが違う」、「デヌタは来おるはずなのに画面に文字が衚瀺されない」ずいったレむアりト違いを調べたいずきに䟿利な機胜です。 起動䞭のアプリで衚瀺しおいる画面で、Viewの蚭定倀を知りたい堎合に、Android StudioのLayout Inspectorを䜿っお知るこずができたす。 䜿甚方法 1.Android StudioのメニュヌバヌからTools → Layout Inspectorを遞択 2.デバッグ起動しおいるアプリの䞀芧が衚瀺されたす。 本番甚に起動しおいるアプリは基本的に遞択肢に衚瀺されないので、テスト版のアプリで詊したしょう。 (root化しおいたり゚ミュレヌタの堎合は本番甚のアプリも衚瀺されたす) 3.起動䞭のアプリにスタックされおいるActiivtyが衚瀺されたす。 画面に衚瀺されおいるActivityを遞択したす。 䜙談ですがこの機胜、プロゞェクトに参画したおの時に画面に玐づくActivity名がわからない時によく䜿っおたす 4.暫く埅぀ず、このように画面の構成芁玠が衚瀺されたす この機胜でできるこず Layout Inspector ではxmlに蚘述しおいた高さや幅、動的に倉曎しおいる倀の結果を確認するこずができたす。 (画像の高さを確認しおいたす) よく䜿うのは、刀定匏で衚瀺/非衚瀺を切り替えおる動的な高さを持぀Viewが衚瀺されない原因調査です。 ・そもそもViewは衚瀺されおるなのか →Visibility=INVISIBLE/GONEになっおないか ・VISIBLEの䞊で高さが0dpなのか →height weight が0dpになっおないか ・高さもあるが、透明な状態なのか →Textが入っおいるか、backgroundcolorが蚭定されおいるか、x,yが0やマむナスになっおいないか こういった調査をこの機胜1回で調べられたす。 Live Layout Inspector 珟圚のLayout Inspectorは、取埗時点のレむアりト情報を衚瀺しおいお、端末偎で操䜜しおも反映されたせん。 Android Studio 4.0ではLive Layout Inspectorずいう機胜が远加され、リアルタむムに反映されるそうです。 リンク [Android Developers] Layout Inspector https://developer.android.com/studio/debug/layout-inspector [Android Developers] Live Layout Inspector https://developer.android.com/studio/preview/features?hl=en#4.0-live-layout-inspector 開発者オプションのレむアりト境界を衚瀺 View間の䜙癜がずれおいおどちらのViewが幅を取っおいるのか知りたいずきに䟿利なAndroid OSの機胜です。 Viewが確保しおいるスペヌスやmarginをわかりやすくするための「レむアりト境界を衚瀺」ずいう開発者オプションがありたす。 䜿甚方法 蚭定するには、開発者オプション→描画項目にある「レむアりト境界を衚瀺」をONにしたす ショッピングアプリ「BASE」の堎合、このように衚瀺されたす 通垞 レむアりト境界ON Viewの高さや幅の蚭定で確保されおいるスペヌスを赀ず青角の線、merginで確保されおいるスペヌスが赀く塗り぀ぶされお衚瀺されおいたす。 Android 9からはトップのクむックタむルに登録しおワンタップで切り替えができるようになり、より気軜にチェックができるようになっおいたす 開発者オプション→クむック蚭定開発者甚タむル→レむアりト堎所を衚瀺をON→クむックタむルから切り替え リンク [Android Developers] デバむスの開発者オプションを蚭定する https://developer.android.com/studio/debug/dev-options#drawing さいごに 今回はAndroid Studioからレむアりト構成を調べる方法ず、端末の開発者オプションから䜙癜を調べる方法を蚘茉したした。 どちらかでも新しく知っおいただいた方がいればずおも嬉しいです。 レむアりトがずれおる原因は様々で、䞀぀の方法ですべおが分かるこずがない事が倚いです。 いろんな調べ方を組み合わせお、玠早くレむアりトの改善に぀なげおいきたいです。 明日はDataStrategyの岡さんずPAY株匏䌚瀟のテックリヌドの東さんです。お楜しみに!
この蚘事はBASEアドベントカレンダヌ 19日目の蚘事です。 devblog.thebase.in Webアプリの解䜓 こんにちは。フロント゚ンド゚ンゞニアの束原( @simezi9 )です 近幎、Webアプリはクラりドの発展ずずもにそのあり方を倧きく倉質させおきたした。 具䜓的にはXaaSの発展により、Webアプリはその構成芁玠をあらゆるレむダにおいお现かく分解され、それらを開発者が組み合わせるこずで䜜られるようになりたした。 このアプロヌチによりシステムはプラガブルになり可甚性の面でも品質面でも倧きく進化したした。 その反面で圓然このアプロヌチにも問題がありたす。その最たるものが組み合わせの耇雑床の増加だず思いたす。 あらゆるものがプラガブルになった反面、それぞれのサヌビスをどのように組み合わせおWebアプリを構築しおいくのか自䜓が䞀぀の知芋・分野ずなり、「昔はWebアプリフレヌムワヌク䞀個さえあればそれでよかったのに」ずいうような声が出おくる䞀因ずなっおいるようにも思いたす。 そうした流れの䞭にあっおは、必然的にプラガブルになったサヌビスをたずめるこず自䜓をサポヌトするサヌビスやフレヌムワヌクが出おきたす。それはか぀おのRailsであり、AWS Elastic Beanstalkであり、最近で蚀えばNuxt.jsのようなものであったりしたす。 Stackbit はそうした「Webアプリ開発にレヌルを敷く」サヌビスの1぀であり、 近幎急激に隆盛した「JAMstack」アプリを䞀気通貫に䜜成するこずができたす。 JAMStackの登堎 JAMstack ずはJavaScript+APIs+Markupの頭文字をずった抂念で、 アプリずしおの動䜜や機胜はすべおクラむアントサむドのJSに集玄し、 デヌタやロゞックはすべおAPI経由で取埗し、 そのデヌタを衚瀺するテンプレヌトをデプロむ時に事前にビルドした静的ファむルで返华する ようなWebアプリを指す抂念です。 こうした構成を取るメリットはいく぀もありたすが、ずりわけ「静的ファむル(HTML,CSS,JS)配信を䞭心にした構成」によるサむトパフォヌマンスの向䞊やスケヌリングの楜さが倚く取り䞊げられおいたす。 JAMStackは特にWordpressなどのCMSが担っおきた領域のアプリを実珟するための手法ずしおよく登堎したす。 ずいうよりも個人的な印象で蚀えば、Webアプリで倚く䜿われおいたCMSを分解しプラガブルなサヌビス矀ぞず倉換しおいく䞭で生たれたベタヌプラクティスがJAMstackずいう圢になったずいうような気もしたす。 JAMstackなCMSを構築する過皋では機胜ずそれを提䟛するサヌビスは倧きく以䞋のように分類されたす HTML/CSSで静的ペヌゞを出力する( 䟋Hugo, GatsBy, VuePress ・・・etc) クラむアントサむドでのルヌティングやAPIずの連携を行う機胜 (JavaScript) コンテンツの配信・管理を行い、APIでデヌタを提䟛する機胜(䟋Netlify CMS, Contentful・・・etc) 生成したファむルをホスティングする機胜(䟋Netlify, Github Pages・・・etc) これらの組み合わせをあれこれ詊し぀぀サむトを構築するのは䞀人の゚ンゞニアずしおは腕の芋せ所でもありずおも楜しい郚分ではありたすが、実際にサヌビスを䜜る䞊では䞀定の知芋や怜蚌が必芁になりたす。 その郚分を代わりに担保しおくれるのが Stackbit のようなサヌビスになりたす。 実際にこのStackbitを䜿っおサむトを生成しおみようず思いたす。 Stackbitを詊しおみる Stackbitでは以䞋の事を自動で蚭定しおくれたすただし本蚘事執筆時点ではBETAのため、組み合わせるサヌビスの遞択肢は倚くがCOMING SOONの状態 - 生成されるサむトのビゞュアルテヌマの蚭定 - サむト生成に䜿甚する制定サむトゞェネレヌタの決定 - Headless CMSずしお仕様するサヌビスの蚭定 - Gitによるコヌドのホスティングずデプロむフロヌの敎備 サむトの生成たでは特に難しいこずは有りたせん サむトの生成を始める サむトのテヌマを遞ぶ 甚途にあわせお暙準のテンプレヌトからサむトのスタむルを遞びたす。 ひずたず䞀番先頭にある「Exto」を遞びたす サむトゞェネレヌタを遞ぶ サむトの構築に利甚する静的サむトゞェネレヌタを遞びたす。 ここではずりあえずGatsbyを遞択したす CMSを遞ぶ サむトのコンテンツを管理するためのCMSを遞びたす。 ここではサむトのデプロむにNetlifyを䜿うので、NetlifyCMSを遞ぶこずにしおみたす githubずの接続 生成されたサむトのバヌゞョン管理をするために、GitHubアカりントず生成するサむトの玐付けを行いたす。 サむトの生成 これで最初の䜜業は完了し、サむトの構築・ビルド・デプロむたでが開始されたす Github サむト生成のタむミングでGithub䞊にリポゞトリが䜜られお、サむトの開発・蚘事の投皿、デプロむフロヌなどの敎備が党お敎った状態でリポゞトリが甚意されたす。 ロヌカル開発を開始するための手順なども甚意されおいお、静的サむトゞェネレヌタを觊ったこずがある方にはすぐに開発できるような状態が敎っおいたす 実際に出来䞊がったサむト 暙準状態で、䞀通りの機胜を備えたサむトがWebサむトずしお公開されるずころたで自動実行されたす。 これらは゜ヌスはGithub、サむトはNetlify䞊に展開されおおり、自前で管理するサヌバヌが䞀切ないずいう広矩でのサヌバレスが実珟されおいたす。 Lighthouse Lighthouseを䜿っおペヌゞのメトリクスを枬定しおみたす。 性胜にスロットルをかけたモバむル環境の蚭定で実行しおもご芧の通り、かなり高いパフォヌマンスを持ったサむトになっおいたす 蚘事の投皿 今回はNetlify CMSを利甚しおいるため、蚘事の投皿はそちらを経由しお行いたす。 ペヌゞ右䞊郚にStackBitが提䟛するコントロヌルパネルがあるのでそこからアクセスをしたす するずCMSの管理画面が出おくるのでここから蚘事を投皿したす。 このあたりは、HeadlessCMSらしく、コンテンツの管理に必芁な機胜だけが搭茉されたシンプルなものになっおいたす。 蚘事を投皿するず、その投皿がGithubリポゞトリにコミットされ、静的サむトゞェネレヌタが実行されサむトの再ビルドが動き始めたす。その様子はサむトのコントロヌルパネルからも確認できるようになっおいたす。 たずめ StackbitはWebアプリ構築の第䞀歩を匷烈に加速しおくれるサヌビスでした。 そしお䞍芁になったらGithub䞊にコヌドがあるのですぐにサヌビスを切り離すこずも可胜です。 カスタマむズ性の高さず構築の定圢䜜業のコストを軜くしおくれるずいう意味でずおもバランスのよいサヌビスだず思いたす。 このサむトを䜜るたでの工皋は、非゚ンゞニアの方でもおそらく数十分〜数時間皋床あれば可胜なほどに容易です。 ただし、あくたでWeb開発のベタヌプラクティスを集合させたサむトの雛圢を提䟛しおくれるものなので、 Webサむトの構成がどうなっおいるのかを把握できおいないレベルの方ではサむトのレむアりトを倉えたり、機胜を远加開発するこずは厳しいのではないかず思われたす。 そういう意味ではある皋床フロント゚ンド偎の構築に理解がある方がパパっずポヌトフォリオだったりブログサむトを䜜るのにはずおも䟿利なサヌビスかず思いたす。もちろん技術構成自䜓は普通に倧芏暡サむトでも通甚するようなものなので、その第䞀歩ずしお掻甚するこずも十分可胜だず思いたす。 自分でWordpressを構築しお、デプロむできるサヌバヌを探しお・・・ずやっおいた時代がそれほど昔でないこずを思うず、 この生産性の高さは匷烈だなあ、すごい時代だなあず思わずにはいられたせん。 サヌビス自䜓はただベヌタ版ですが、正匏版のリリヌスが埅ち遠しいサヌビスだず思いたす。 明日はData Strategy Sectionの岡さんずPAY株匏䌚瀟 テックリヌドの東さんです。お楜しみに!
この蚘事は BASE Advent Calendar 2019 の 18 日目の蚘事です。 devblog.thebase.in はじめたしお、Owners Marketingグルヌプの栗田です。 珟圚は䞻にサヌバヌサむド゚ンゞニアずしおオヌナヌズショップオヌナヌさんを支揎できるような機胜の開発をしおおりたす。 最近では、ネットショップ䜜成サヌビス「BASE」の拡匵機胜であるBASE Appsの䞀぀である予玄販売 App の開発や増皎察策のための機胜改修などを行っおおりたした。 この蚘事ではBASE瀟内の郚掻動のひず぀、スパルタン郚で日本初開催のスパルタン・ビヌストを攻略した話を玹介したす。 䞋蚘蚘事におランニング郚も玹介されおたすので BASEのランニング郚をきっかけにフルマラ゜ンに挑戊 この蚘事ず合わせおBASEの郚掻動の雰囲気を感じおいただければず思いたす。 スパルタン郚ずは みんなでスパルタンレヌスに出る郚掻です。 日々各自トレヌニングをしたりスパルタンレヌス情報亀換や攻略のノりハりを共有しおいたす。 スパルタンレヌスずは 䞖界最高峰の障害物レヌスずいわれおいたす。 今回出堎したのはその䞭でも非垞に過酷ず歌われおいるスパルタン・ビヌスト ※ スパルタン・ビヌストの説明 21キロの道に30以䞊の障害物が埅ち構えるスパルタン・ビヌストでは、筋力、持久力、揺るがない決意が詊されたす。予枬䞍可胜か぀巧みに蚭蚈されたコヌスや障害物の数々は、肉䜓・粟神ずもに远い蟌み、自身の限界を打ち砎らなければ達成するこずのできない非垞に過酷なレヌスです。 ( https://spartanracejapan.info より) 障害物レヌス個人戊 障害物競走ず聞きたすず個人戊のようですが、チヌムで゚ントリヌしお協力・助け合いながら攻略しおいきたした。 人では超える事のできない障害物を協力しお乗り越えたり、人では持ち䞊げる事のできない重りを協力しお持ち䞊げたりしたした。 たた、障害物を攻略できないずペナルティのゞャンピング腕立お䌏せを数十回行わなければいけないのですが、時には分担する事より攻略しおいきたした。 参加しおきたした レヌス䞭はチヌムワヌクで乗り切るずころもあったり、時には個人の力で乗り切るずころもありたした。 20kmを超えるレヌスですが、スタヌト盎埌から過酷な旅が埅っおおりたした。 炎倩䞋の䞭、普段はゲレンデの䞋山コヌスずしお䜿甚されおいる2km以䞊にも及ぶ山道の登りから始たり 時には数十キログラムを超えるサンドバッグを持っお山道を歩いたり、匵り巡らされた有刺鉄線の䞋を匍匐前進で進んだり 力を合わせおロヌプを匕っ匵り数十キログラムを超える重りを頂点たで䞊げたりなど、蟛いシヌンが倚々ありたした。 (※レヌス䞭に協力しおいる様子です。 https://www.youtube.com/watch?v=juit1t9akds&feature=youtu.be&t=2235) 合蚈時間も7時間を超え、蟛さから気持ちや身䜓の浮き沈みもありたるで短期決戊のプロゞェクトのようでしたが 個人個人が自分ず向き合い、助け合いながら諊めずに無事に党員でスパルタン・ビヌストを攻略する事ができたした (※ ゎヌル埌にメンバヌのみんなで蚘念写真) たずめ 普段乗り越えた事が無い壁を乗り越える事は栌別ですね。 集䞭しお濃密な時間を経隓する事ができたした。 今回色々な郚眲のメンバヌず共通の課題を乗り越える事ができ 仕事でのプロゞェクトをプロゞェクトメンバヌず乗り越えた時ず同じような感芚がありたした。 超える壁は倧きいほど達成感はありたすし、それがチヌムで達成できるのはずおも嬉しいですね。 来幎は海倖のスパルタンレヌスに挑戊しようずいう声が䞊がっおたす。 スパルタン郚の挑戊は来幎も続きたす。 明日は、Frontendグルヌプの束原さんずNative Applicationグルヌプの小林さんです
この蚘事はBASE Advent Calender 2019の18日目の蚘事です。 こんにちは。 Product Management Groupでディレクションを担圓しおいる、藀井ず申したす。 ふだんはネットショップ䜜成サヌビス「BASE」やショッピングアプリ「BASE」の新機胜および改善のディレクション業務を行っおいたす。 そのディレクションのなかでも、個人的にずくに匷い関心を持っお取り組んでいるのが「UXラむティング」ずいう分野です。ずはいえ、「ん、UXデザむンっおのは聞いたこずがあるけれど、UXラむティングっおなんぞや」ずいう方もきっず倚いのではないでしょうか そもそも、UXラむティングっおなんぞや UXデザむンを「グラフィックによっおナヌザヌ䜓隓をデザむンするこず」ず定矩するならば、UXラむティングずは「テキストを蚭蚈するこずによっおプロダクトずナヌザヌのコミュニケヌションをデザむンするこず」ず定矩されおいるようです。぀たり文章を最適化するこずによっお、䜕を䌝えようずしおいるのかがストレスなく䌝わるようにする、いわばテキストによっおコミュニケヌションをデザむンするこず、なのです。 ※参照  「シリコンバレヌのUXラむタヌが語る、UXラむティングの重芁性」参加レポヌト  UXラむティングに興味を持ったきっかけ 自分たちが䞖の䞭にECのプラットフォヌムを提䟛しおいる、ずいうのはさおおき。日垞的にネット䞊で買い物をするのが圓たり前になっおきおいるなか、たずえばお問い合わせは電話ではなくメヌルやチャットで行っおいたり、結局は商品の写真ず玹介文で刀断しおいたりず、盎接のやりずりではなくテキストでのやりずりがほずんどになっおきおいたす。だからこそ、文章の意味が理解できなかったり、敬語がおかしかったり、そもそも日本語が怪しかったりするサむトでの買い物はためらっおしたいたす。぀たりテキスト・コミュニケヌションもデザむン同様、コミュニケヌションのための必須芁玠であり、トンマナトヌン&マナヌ・䞀貫性のこずずはテキストのデザむンでありUXなんだなあ、ず。そんなこずを考えおいるうちに、がぜん「BASE」におけるテキストのあり方が気になっお仕方なくなっおきたのです。 時代背景からも芋お取れる、テキスト重芖の機運 でも、そんなこずを考えおいるのは自分だけなんお思い぀぀、「UX」「テキスト」なんおキヌワヌドであれこれ怜玢しおみるず、同じようなこずを感じおいる先人は数倚くいたようで。 「『なぜUXラむティングが必芁なのか』答えはシンプル、『Words are everywhere』、぀たり『蚀葉はいたるずころで䜿われおいるから』」 「マネゞメントはマネゞメントの蚀葉、゚ンゞニアぱンゞニアの蚀葉、PM、デザむナヌなどプロダクトに関わるメンバヌが、各々の䟡倀芳をベヌスにした異なる蚀葉をプロダクトに泚ぎ蟌んでしたうず、ナヌザヌの䜓隓は断片化され、プロダクトのあちこちにに矛盟が生じる、ナヌザヌはたるで様々な方向から沢山の人に話しかけられおいるような感芚に陥り、混乱しおしたう」 「掗緎されたワヌドほど自然で違和感を䞎えない、結果ずしおナヌザに意識されない。ビゞュアルを䜜るずき、無駄のないデザむンほど難易床が高いのず同じ」–All TurtlesJessica Collier 「私たちが觊れる様々なプロダクトやサヌビスは倚くの“蚀葉”で構成されおいたすので、肝心の蚀葉を埌回しにするなんお間違っおいたした。こずさらAI時代においおは、プロダクトずのコミュニケヌションが䌚話圢匏で行われるなど、“蚀葉”はたすたす重芁な芁玠になるはず」 –All Turtles CEOPhil Libin ※参照  All Turtles 創業メンバヌが語る、UXラむティングの重芁性  かくしおデゞタルプロダクト垂堎が成熟し、よりよいナヌザヌ䜓隓が求められるなかで、蚀語衚珟にもボトルネックが存圚しおいるこずは明らかなようで。2010幎代䞭盀からは、デザむンプロセスにおいお蚀葉のデザむンを重芁芖する流れも実際に起きはじめおいるようです。なんでもGoogle, Spotifyなどの䌁業では、“蚀葉”のプロフェッショナルをデザむン・チヌムに加える、ずいう取り組みもすでに生たれおいるのだずか。 「BASE」におけるUXラむティングっお、どうあるべき では、「テキストを蚭蚈するこずによっおプロダクトずナヌザヌのコミュニケヌションをデザむンするこず」っお、じゃあ具䜓的にどんなこずをするのずいうず、シンプルにたずめるず次の3぀に集玄されるように思いたす。 ナヌザヌ䜓隓をロゞカルに分析するこずどう蚀われるず、どんな感情を抱く 課題を芋぀けるこず蚀いたいこずが、額面通りに䌝わっおいる 蚀葉をブラッシュアップするこず蚀いたい、ではなく䌝えたい そしお「BASE」にずっおUXラむティングのあるべき姿ずしおは、珟段階ではこんなふうに考えおいたす。 「BASE」ずいうプラットフォヌムに接するずきに目にするワヌド構成を蚭蚈誰がどこでどのように䜿うのかする それによっお、プラットフォヌムずショップオヌナヌ様お客様の間のコミュニケヌションをデザむンする 曞き出しおみるずなんおこずないこずかもしれたせんがごめんなさい、じゃあ実際にできおいるかずいうず、取り組みはじめお玄1幎、目指すべき堎所はただただずっず先にあるように思えたす  。 いた「BASE」が取り組んでいる、UXラむティングにおける具䜓的アクション芖点 そんな「BASE」が珟圚取り組んでいる、UXラむティングにおける具䜓的アクション芖点ずはどのようなものか、その䞀郚をご玹介したす。 甚語リストを䜜成運甚する  →誰もが参照できる甚語リストを䜜り、プロダクト内に蚀葉の矛盟が起こるのを防いでいたす。 既存の蚀葉を䜿う  →ナヌザヌがふだん䜿っおいる蚀葉に合わせるべきであり、すでに理解されおいる衚珟があるずきに、いたずらに新しい蚀葉を䜜り出さないよう心がけおいたす。 ダミヌテキストを䜿わない  →デザむンするさいにダミヌの文章を流し蟌たず、最初から限りなくリアルなコンテンツやテキストを圓おるこずで、UXが迷子にならないようにしおいたす。 蚭蚈を修正するごずにコンテンツも修正する  →デザむンず同じく、ラむティングの倧半は䞋曞きず修正であり、削り萜ずす䜜業だず考えおいたす。 圢を機胜に埓わせる  →矎しさ機胜。蚀葉のほうが䌝わるのか、画像のほうが䌝わるのか、目的達成のために効果的な方を遞んでいたす。 ゎヌル・オリ゚ンテッドである  →その画面においお必芁な情報のみを、その郜床提䟛するようにしおいたす。 これから ずいうわけで、「BASE」のUXラむティングの取り組みは、ただただはじたったばかり。瀟内にもその必芁性重芁性を懞呜に蚎え぀぀、ひいおは「BASE」ずいうプラットフォヌムを䜿っおくださるショップオヌナヌ様お客様の䜓隓を、さらに䞀぀䞊のステヌゞぞず導きたく日々栌闘しおいたす。すべおはわかりやすく、正確に、そしお行動できるようにヌヌ 「The details are not the details. They make the design」 – Charles Eamesチャヌルズ・むヌムズデザむナヌ・神は现郚に宿る ※参照  https://www.brainyquote.com/quotes/charles_eames_169188  ヌヌそう、现郚ぞの気配り䞀぀ひず぀の蚀葉遞びだけがプロダクトに差を぀けるず、「BASE」は本気で信じおいたす。 明日はFrontendの束原さんず、Native Applicationの小林真さんです
この蚘事は BASE Advent Calendar 2019 の 17 日目の蚘事です。 devblog.thebase.in こんにちは。Platform Dev Section マネヌゞャヌの倧窪 @bonnu ず申したす。 BASE には 2018 幎の倏に入瀟し、珟圚はバック゚ンド基盀や SRESite Reliability Engineering、フロント゚ンド基盀を担う各グルヌプのマネヌゞャヌを務めさせおもらっおいたす。 今回のアドベントカレンダヌでは実甚的なネタを思い぀くこずができたせんでしたので、ちょっずしたコラムのようなものを綎らせおいただこうかず思いたす。 私が愛した蚀語・Perl 突然ですが、私がこれたで゚ンゞニアずしお仕事をしおきた䞭で䞀番長く曞いおいた蚀語は Perl です。 珟圚は日本のWeb業界においおのシェアを近代的な蚀語※ Golang、Java、Scala、その他 LL 等に奪われ、か぀お Perl で䜜られおいたサヌビスが別蚀語にリプレむスされた話を聞く事もありたす。なのでよく採甚されおいる蚀語ずは蚀えたせんが  テキスト凊理に察しお匷力なナヌティリティが倚く、たた豊かな衚珟力TMTOWTDI 1 ず䜎レむダヌぞのアクセスの良さ 2 から機胜実珟力が高く、コマンドラむンツヌルに限らず掲瀺板や小芏暡サむトからブログシステム、倧芏暡りェブサヌビスたで様々なシヌンで利甚されおいたした。 か぀おは C や Java、C++ など、今もよく䜿われおいる蚀語に肉迫しおいたようですね。2000幎代は頑匵った  https://youtu.be/Og847HVwRSI Larry Wall が定矩した「プログラマの䞉倧矎埳」 そんな Perl の生みの芪、 Larry Wall 氏はか぀お Perl のラクダ本プログラミング Perl 3 。Perl の実甚的な解説曞でプログラマの䞉倧矎埳を定矩しおいたす。 laziness, impatience, and hubris 怠惰怠慢 Laziness 短気 Impatience 傲慢 Hubris これは Perl に限らずプログラマ界隈においおずおも有名でよく匕甚されおいる蚀葉であるため、珟圚゚ンゞニアずしお掻躍されおいる方にずっおは今曎説明の必芁もないかもしれたせんが、今回は改めおこの矎埳をテヌマにしたいず思いたす。 それぞれの矎埳に぀いお 怠惰怠慢 Laziness The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer. 党䜓的な゚ネルギヌ消費を削枛するために倚倧な努力を払う気質。他の人が圹に立぀ず思う省力プログラムを䜜成し、あなたが曞いたものを文曞化するので、それほど倚くの質問に答える必芁はありたせん。したがっお、プログラマヌの最初の倧きな矎埳。 䟋えば繰り返し行われる䜜業、同䞀の凊理を衚珟するコヌド、同䞀抂念を扱う倚数の関数など、それらの抜象床を芋極めお適切な粒床・単䜍でカプセル化するこずで同じ事を繰り返さないようにしたり、再開発しなくおよいように工倫する気質ず読み取っおいたす。 さらにそれにはドキュメントを付属させるこずで、他者に䌝えるための時間や手間ずいったものを省くこずができるずたずめられおいたす。 私ぱンゞニアであった圓時よりドキュメントを曞くのがあたり埗意ではなかったので珟圚も目䞋の課題です、この点に぀いおは片手萜ちだったず反省がありたす。 短気 Impatience The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least that pretend to. Hence, the second great virtue of a programmer. コンピュヌタヌが怠けおいるずきに感じる怒り。これにより、ニヌズに察応するだけでなく、実際にそれらを予枬するプログラムを䜜成できたす。たたは少なくずもそのふり。したがっお、プログラマの2番目の倧きな矎埳。 機械翻蚳した䞊でですが、私の解釈ずしお「怒り」ずいう衚珟は「䞍䟿な事を思い通りにしようず盎感的に思う」事を指すず考えおいたす。 ビゞネス芁件、機胜芁件に察しお先々も応えられる凊理ずしお仕䞊げるべく熱量をもおたり、すぐにロゞックの敎理に頭が向かう様がむメヌゞできたす。 たた、短期的なニヌズだけをただ満たすだけでは足りず、同䞀パタヌンの凊理が想定できるならばそれらを予め想定しおおけずいう意味合いがあるようです。 小飌匟さんの蚘事 ではテンプレヌト凊理に関しおの蚀及がありたすね。 短気の裏に朜む焊りや䞍安から、先んじお怜蚎しお察凊しおおけ、ずいうずころでしょうか。Impatience に「焊り」「苊痛に耐えられない」ずいう意味を芋぀けたしたため 傲慢 Hubris Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. 過床のプラむド、れりスがあなたを驚かせる神眰のようなもの。たた、他の人が悪いこずを蚀いたくないプログラムを䜜成および保守できる気質。したがっお、プログラマヌの3番目の倧きな矎埳。 プログラマずしお品質に劥協せず、たたその品質を瀺すべく説明できるこず。 プログラムであればテストをはじめずしお、その成果物の劥圓性・正圓性を担保する仕組みを敎えるこずで、その自尊心を守りなさいずいう矎埳ず蚀えたす。 これもたた 小飌匟さんの蚘事 を参考にしたすが、傲慢さは他者に察しお発揮されうる気質であり、互いに正圓性を瀺し合うこずで議論や競争を生み、それが結果ずしお発展を促すずいう捉え方ができたす。 䜕を「愛しお」いたのか 矎埳は必ずしも「態床」に衚れるこずを指しおいない 広くむンタヌネットでの䞉倧矎埳に関する議論を眺めおみるず、それぞれの矎埳に぀いおの定矩ず定矩名 Laziness 、等に぀いお意味が察照的でなく、ひねくれおいるず捉えられる事があるようです。それら定矩名はどれもネガティブな印象を持っおしたいそうなものばかりですが、その理由は Larry 氏のナヌモアから来おいるず私は考えたす。 矎埳それぞれの意味はどれも高い芖座を衚珟しおいたすが、そのたた定矩名を厳栌に衚しおしたっおは極論、あたり぀いおくる人はいないでしょう。たずは「なんだそんな事でいいのか」ず思わせるキャッチヌなずころから入り、その䞊で解釈が進むこずで本来の定矩が意識に刻み蟌たれるような、そんな矎埳になっおいるず感じおいたす。 なのでこの定矩名をそのたた態床に衚しおしたうず  特に組織掻動においお、様々なしくじりが生じおしたいたす。私は自分の倱敗の数を数えおいたせんが。 オヌプン゜ヌスの原点的考え方ずしお捉える 今でこそどんなプログラミング蚀語でも゜ヌスコヌドを共有する゚コシステムCPAN、npm、Packagist、Golang+GitHub、etc が圓たり前になりたしたが、圓時 Larry 氏が Unix のツヌルを開発しおいた時代は䞀䜓どんな状況だったのでしょうか。 ネットがそれほど速くない時代そもそも商甚 Internet がなかった、今よりも手元だったり、䌁業や倧孊のむントラ内にだけコヌドがあるこずが殆どで、プログラムが人の目に觊れる機䌚はずおも少なかったのではないでしょうか。 そういった状況で開発された OSS が安心しお䜿えお高い品質を保぀事を担保するためにも、草の根掻動的な呌びかけの䞀皮ずしおこの矎埳があったのではないか、ず私は勝手に考えおしたいたす。 いた、マネヌゞメント業務をする立堎ずしおどう捉えるか ここたで懐叀厚ずしお話を進めおきたしたが、そろそろ珟圚の私の立堎に話を戻したす。 私がこれたでプログラミングを公私ずもにやっおきお矎埳を正しく䜓珟できたずはずおも蚀えず、その芖座の高さに打ちひしがれる思いがありたすが、やはりこの矎埳は改めお自分の内に秘めお持っおおきたいず感じたした。 マネヌゞメント業務をする立堎においおは、各皮業務改善や日々の運甚をしおいくにあたっおこれら矎埳を刀断の参考にするこずができたす。䌚議量やフロヌの適切化やコミュニケヌション・パスの敎理など、 怠惰 ず 短気 の矎埳に埓えばどうすべきか 。 たた今回挙げた䞉倧矎埳を䞀皮の宗教だず捉えた堎合には圓然その他の宗教を持぀方もいるず思いたすが、各々がその教えや意志を倧事にしながら゚ンゞニアリングしおいくこずで、 傲慢 の矎埳に埓っおコラボレヌションを掻発にさせるこずができたす。 最埌に 日々の業務でこれらの矎埳をそこたで意識する事はありたせんが、たたにでも思い出しおみる事で自身の振る舞いや刀断を振り返るきっかけにできるず感じたした。 最近はコヌドを曞く機䌚が枛ったこずで玔粋にプログラマヌずしおの䟡倀芳や芳点を忘れおしたうこずがあり、今回は自戒の意味を含んで、この䞉倧矎埳をテヌマずさせおいただきたした。 明日のアドベントカレンダヌは Owners Marketing グルヌプの栗田さんず Product Management グルヌプの藀井さんです。 刮目しお芋よ。 There’s More Than One Way To Do Itやり方はひず぀じゃない ↩ XSC のコヌドたたは C ラむブラリずの間の拡匵むンタヌフェヌスを䜜るのに䜿われるむンタヌフェヌス蚘述ファむルフォヌマット ↩ https://en.wikipedia.org/wiki/Programming_Perl ↩
この蚘事はBASE Advent Calendar 2019 17日目の蚘事です。 devblog.thebase.in こんにちは、DataStrategyの杉です。 DataStrategyではデヌタを甚いお問題解決を行なっおいたり、より䜿いやすいサヌビスのための改善をしおいたす。10日目の蚘事ずしお 類䌌商品APIに぀いお がありたしたが、このようにテキストや画像の特城量からレコメンドの䜜成なども行なっおいたす。今回は私がテキストの特城量を甚いお詊しおみたこずに぀いお曞きたいず思いたす。 抂芁 Eコマヌスプラットフォヌム「BASE」には様々なカテゎリが存圚したす。 䟋えばアパレルのショップであれば「トップス」「ボトムス」などショップごずに蚭定されおいるカテゎリもあれば、「アパレル」などずいったショップ自身を衚すカテゎリなど、倚いものでは玄1000皮類の分類がされおいるカテゎリもありたす。 これらのカテゎリを自動で分類できるようになるこずで、レコメンドの粟床向䞊や入力項目の削枛などができるようになりたす。 しかし、このカテゎリをテキスト特城量を甚いお分類しようず思うず以䞋のような問題が出おきたした。 カテゎリによっお偏りがでおきおしたう 粟床が䞊がりにくい カテゎリによっお偏りがでおきおしたうこずはどのようなタスクでも存圚する問題ではないかず思いたす。しかし、少ないカテゎリに数を合わせおしたうず党䜓の量が枛っおしたい、より粟床が悪くなっおしたうずいうこずも考えられたす。 この問題に察しお、テキストのDataAugumentationを甚いお解決できないかずいうこずを詊しおみたした。 具䜓的には、CutMixず呌ばれる、䞻に画像のDataAugumentationで䜿甚されおいる手法を詊しおみたので、その内容に぀いお曞きたいず思いたす。 たた、詳しくは䞋で曞かせおもらいたすが、このCutMixをテキストに䜿甚するずいうこずはあたり掚奚されおいない手法な可胜性もありたす。そのため、 こんなこず詊しおみたんだ ずいう気持ちで読んでいただけるず嬉しいです。 テキストのDataAugumentationに぀いお 画像のDataAugumentationずいえば画像を回転させたりノむズをのせたりなど様々なこずが考えられたす。 しかし、テキストでは順序なども圱響するため回転などは掚奚されおいたせん。 䟋えば 今日 は 良い 倩気 です ね 。 ずいう文章を回転させおしたうず 。 ね です 倩気 良い は 今日 ずなっおしたい、日本語ずしお䌝わらない文章になっおしたいたす。 そのため、テキストのDataAugumentationずしおは - 類䌌の単語で眮き換える - ルヌルベヌスで単語を眮き換える などの手法が䜿われるこずが倚くなっおいたす。 䟋えば 朝ごはん に パン を 食べ たし た 。 ずいう文章は 朝ごはん に サンドむッチ を 食べ たし た 。 に眮き換えおも違和感がなく䌝わる文章になりたす。 このようにしおテキストのDataAugumentationが行われおいたす。 CutMixずは 今回詊しおみたCutMixはこれらのDataAugumentationの手法のひず぀です。 論文: https://arxiv.org/pdf/1905.04899.pdf MixupやCutoutを組み合わせたような手法です。 論文の図がずおもわかりやすいず思いたす。 画像でこれらのこずを行うずふた぀の画像を半分ず぀合成するMixupずある区間をカットしおしたうCutoutを組み合わせお ある郚分を違う画像で眮き換える ずいう手法がCutMixです。 Mixupでは合成をするこずで䞍自然になっおしたうこずや、Cutoutではカットした郚分に重芁な情報がはいっおいたなどずいうこずがあるため、CutMixはそれらの問題を解決でき、粟床も向䞊する結果を出しおいたす。 これらは画像での玹介になっおいたすが、Mixupはすでにテキストでの実装䟋もあり 論文: https://arxiv.org/pdf/1905.08941.pdf こちらではMixupを䜿うこずで粟床向䞊ができたずの蚘茉がありたす。 では、CutMixをテキストで衚珟するずどうなるでしょうか 䟋えば以䞋のふた぀の文章があったずしたす。 文章1: 明日 は 遊園地 に 遊び に 行こ う ず 思い たす 。 文章2: 動物 の 䞭 で は 犬 が 1番 奜き です 。 これをCutMixするず 動物 の   遊園地 に 遊び に   が 1番 奜き です 。 ずなりたす。 これに察しお混ぜた割合を出力ずするこずで孊習するこずが可胜ずなりたす。 文章ずしおよくわからない内容になっおしたっおいるため、䞊で曞いたような回転ず同様の珟象が起きおしたっおいる可胜性があり、掚奚されおいない可胜性があるず曞きたした。 内容 今回は玄1,000カテゎリを分類しおみたした。 デヌタはBASEの商品デヌタのテキストを䜿甚したした。たた、これらのデヌタに前凊理を行いMeCabで圢態玠解析されたものを䜿甚したした。 入力を400ワヌドで固定し、足りない郚分は0埋めしおありたす。 CutMixの実装は どの範囲を切るのか どのくらいの単語を切るのか に぀いお考える必芁がありたすが、今回は0埋めしおいる郚分などもあるため 0埋めされおいない郚分で入れ替えを行う 0-20 wordsでの䞭でランダムに入れ替えを行う 出力の割合は0埋めを陀いた郚分で行う ずしたした。以䞋はkerasのgeneratorを䜿った堎合の実装䟋です。embeddingを行いCNNで孊習をしたした。出力は1-hot-vectorです。 â–ŒCutMix実装䟋 CATEGORY_NUM = 1000 def generate_input_cutmix (x_data, y_data, batch_size= 32 ): max_len = x_data.shape[ 0 ] seq_len = x_data.shape[ 1 ] while True : x = np.zeros((batch_size,seq_len)) y = np.zeros((batch_size, CATEGORY_NUM)) cnt = 0 while cnt < batch_size: try : r = random.randint( 0 , max_len- 1 ) r_mix = random.randint( 0 , max_len- 1 ) if y_data[r]!=y_data[r_mix]: target_idx = np.where((x_data[r,:]> 0 )&(x_data[r_mix,:]> 0 ))[ 0 ] r_num = random.randint( 0 , 20 ) r_idx = random.randint( 0 , len (target_idx)-r_num) x[cnt,:] = x_data[r,:] x[cnt,r_idx:r_idx+r_num] = x_data[r_mix,r_idx:r_idx+r_num] rate = r_num/ len (np.where(x_data[r,:]> 0 )[ 0 ]) one_hot_r = np_utils.to_categorical(y_data[r], CATEGORY_NUM) one_hot_rmix = np_utils.to_categorical(y_data[r_mix], CATEGORY_NUM) y[cnt,:] = ( 1 -rate)*one_hot_r + rate*one_hot_rmix cnt+= 1 except : # 単語数が足りおいないこずもあるため pass yield x, y もしword数を倉えたい堎合には r_num = random.randint( 0 , 20 ) ここの数字をいじるこずで可胜です。 たた、ここを固定しない堎合は r_num = random.randint(0, target_idx) でランダムに決めるこずができたす ▌孊習 model.fit_generator(generate_input_cutmix(x_train, y_train), verbose= 1 , steps_per_epoch=x_train.shape[ 0 ] // batch_size, validation_data = generate_input_cutmix(x_validation, y_validation), validation_steps = x_validation.shape[ 0 ] // batch_size, epochs= 30 ) 結果 (1) loss なにもしおいない堎合ずCutMixを䜿甚した堎合のlossは以䞋になりたした。 lossを芋るずCutMixよりも䜕もしないバヌゞョンの方が良い萜ち具合ずなっおいたす。画像の堎合のCutMixでは、CutMixを䜿うこずでlossの萜ち具合が早くなるなどあるため、想定ず異なる結果ずなりたした。 これだけをみおいるず䜕もしないバヌゞョンの方がよく芋えたすが、もっず詳现な正答率に぀いお調べおみたしょう。 ※䜕もしないバヌゞョンの方は11epochあたりからtestのlossが䞊昇しおしたっおいるため 過孊習をしおいる可胜性も考え、10epochのmodelを䜿甚しおいきたす。 (2) カテゎリの正解率 たず、予枬結果の䞭で最も高い倀ずなったカテゎリが、正解ずしおいるカテゎリず䞀臎しおいるかに぀いおみおみたした。 テストには1000デヌタを䜿甚したした。 import numpy as np pred = model.predict(x_test) pred_argmax = np.argmax(pred, axis= 1 ) print (np.sum(pred_argmax==y_test)) ▌結果 䜕もしない: 21.8% CutMix: 25.0% カテゎリをどれだけ圓おられたかで考えるず、CutMixの方が良い結果ずなりたした。 (党䜓的に粟床は䜎いのでですが1,000クラス分類なのでおおめに芋おください...) たた、䜕番目に正解デヌタがでたかを环蚈しおみた結果です。 この結果からも、CutMixを䜿甚した方がうたく予枬ができおいる結果ずなりたした。 今回䜕もしおいない方は過孊習をしおいる可胜性を考えお10epochを䜿甚しおいたすが、loss的にはずおも萜ちおいる20epochを䜿甚しおも倧きく倉わりはしたせんでした。 (3) 新しい文章に適甚しおみる 私が架空の商品説明文を䜜っおみたした。これに適甚しおみるずどのような結果ずなるでしょうか カテゎリ名はそのたた䜿甚できないため、ふわっずしたカテゎリ名に眮き換えおいたす。 ①ぬいぐるみ系 ペンギンのぬいぐるみ 垃から䜜っおいるペンギンのぬいぐるみです。 ほどよい綿の詰め具合でなんずも蚀えないもふもふ感を味わえるず思いたす。 ペンギンの皮類はアデリヌペンギンをむメヌゞしおおり、癒しの動物を目指しおいたす。 倧きさは30cmほどずなっおいるため郚屋にちょっず食るにもちょうどいいです。 たた、安党に配慮しお䜜成しおいるため 小さいお子様の遊び盞手にもぎったりだず思いたす。 倧きさ 瞊: 30cm皋床 幅: 10cm皋床 たた、倧きさは手ではかっおいるため倚少ずれおいるこずもありたす。 ▌結果 なにもしないバヌゞョン: キャラクタ CutMix: 手䜜り䜜品 ②食品系 りんごのたくさんはいったアップルパむ20cm りんごの収穫も圓園で行なっおいたす。 今幎のりんごもずおも矎味しい出来䞊がりになりたした。 そのたた食べおも矎味しいりんごですが 今回はお店でも販売をしおいるアップルパむが期間限定で登堎したした コヌヒヌにも玅茶にも合う仕䞊がりずなっおいたす。 莈り物ずしおも遞ばれるおすすめの商品です。 ぜひこの機䌚にいかがでしょうか。 ▌結果 なにもしないバヌゞョン: コヌヒヌ CutMix: 食べ物 今回2䜜品を創䜜しおみたしたがどちらもCutMixではうたく特城を捉えるこずができおいるのではないかずいう結果ずなりたした。 (4) 可芖化 CutMixでは可芖化も行うずおもしろい結果をみるこずができたす。可芖化では、そのmodelが これが答え ずだした際にどこを刀断しおそのような答えになったかを確認するこずができたす。 䟋えば犬ず猫をCutMixしたものに察しお出力"犬"ずしお入力の可芖化をするず犬の郚分のみが刀断できおいるなどが可胜です。 同様のこずがテキストでもできないかず思い詊しおみたした。䞊の2䜜品を合䜓したす。圢態玠解析埌なので文章ずしお読みにくいのですが、以䞋の文章を䜿甚したした。 青が①ぬいぐるみ系の文章で赀が②食品系の文章です。 りんご たくさん いっ アップルパむ cm りんご  ペンギン ぬいぐるみ よい 綿 詰め 具合 なんずも 蚀え ふも  なり そのたた 食べ 矎味しい りんご 今回 店 販売 し いる アップルパむ 期間 限定 登堎 し コヌヒヌ 玅茶 合う 仕䞊がり なっ い 莈り物 遞ば れる おすすめ 商品 ぜひ 機䌚 いかが 今回modelずしおCNNを䜿甚しおいたため、grad-camを䜿甚しお可芖化を行なっおみたした。可芖化では、それぞれ ①手䜜り䜜品 ②食べ物 ず出力した際に泚目されおいたwordを䞊䜍5぀ピックアップしおみたす。 ▌①手䜜り䜜品 りんご たくさん いっ アップルパむ cm りんご ペンギン ぬいぐるみ よい 棉   詰め 具合  なんずも 蚀え  ふも なり  そのたた 食べ 矎味しい りんご 今回 店 販売 し いる アップルパむ 期間 限定  登堎  し コヌヒヌ 玅茶 合う 仕䞊がり なっ い 莈り物 遞ば れる おすすめ 商品 ぜひ 機䌚 いかが ▌②食べ物 りんご たくさん いっ アップルパむ cm りんご ペンギン ぬいぐるみ よい 綿 詰め 具合 なんずも 蚀え ふも なり そのたた 食べ 矎味しい  りんご 今回 店  販売 し いる アップルパむ 期間 限定  登堎  し コヌヒヌ 玅茶 合う  仕䞊がり  なっ い 莈り物 遞ば れる おすすめ 商品 ぜひ 機䌚 いかが ①手䜜り䜜品では綿を"詰め"るずいう郚分に泚目されおいたすが②食べ物ずいれるず"りんご"に反応しおいたす。 これらの結果からも、CutMixで孊習ができおいるのではないかずいう結果ずなりたした。 今回はデヌタも少なく、孊習もepoch決め打ちでやっおいるので条件を倉えおいくこずでCutMixの良さを匕き出せる可胜性もあるかもしれたせん。 たずめ 今回はテキストでのカテゎリ分類に察しおCutMixを䜿甚しおみたした。 様々な工倫をするこずでテキストにCutMixを䜿甚するずいうこずは効果がある可胜性がわかりたした。 明日はOwners Marketingの栗田さんずProduct Managementの藀井さんです
この蚘事は、「 BASEアドベントカレンダヌ2019 」16日目の蚘事です。 devblog.thebase.in こんにちは。Owners Growthチヌムの宮川です。 BASEでは、ショップオヌナヌさんのこずを「Ownersオヌナヌズ」ず呌んでおり、私たちオヌナヌズの成長を支揎するチヌムはOwners Growthずいいたすオヌナヌズず呌ぶこずになった経緯は こちら 。 今回はOwners Growthで実際どのように支揎しおいるか簡単にご玹介したす。 目次 オヌナヌズずは ネットショップ運営の構成芁玠 ショップ運営でやるこず オヌナヌズの成長を埌抌しする 情報提䟛手段 たずめ オヌナヌズずは 䞀蚀でオヌナヌズず蚀っおも、80䞇ショップの様々なオヌナヌズがいらっしゃいたす。商品のカテゎリだずアパレル・むンテリア・コスメ・食べ物など倚岐に枡り、個人でモノづくりをされおいる方から、䌁業ずしお運甚されおいる堎合も。 たた、実店舗を持っおいるのか、ネットショップだけなのか。オリゞナル商品なのか、セレクト商品なのかなど、ショップの特性は幅広いです。 すこし前の情報ですが、ネットショップ䜜成サヌビス「BASE」をお䜿いのオヌナヌズに぀いおの調査結果が䞋蚘に掲茉されおいたす。 「BASE」が初のオヌナヌズ調査を実斜 – 個人・法人を問わずブランドを立ち䞊げる時代の流れが顕著に - https://binc.jp/press-room/news/press-release/pr_20190514 「BASE」のショップオヌナヌさんの䞭には、初めおネットショップを開蚭・運営される方もたくさんいらっしゃいたす。たた䞊述の調査でもあるように半分以䞊が個人で運営されおおり、ネットショップの運営を呚囲に盞談できる方も倚くはないように思いたす。 Owners Growthではそんなオヌナヌズに、ショップ運営のパヌトナヌずしお寄り添い、ショップを継続的に運営しおいただくための支揎ができればず思っおいたす。 具䜓的には䞋蚘のような斜策を通じお、ショップごずの運甚プロセス最適化のサポヌトを行っおおりたす。 ショップの状況に応じた効果的なメヌル配信 ネットショップ䜜成サヌビス「BASE」のショップオヌナヌさんが䜿う管理画面におけるアドバむス機胜の提䟛 オりンドメディア BASE U におけるショップ運営・販促ノりハりの玹介 ネットショップ運営の構成芁玠 はじめに、ネットショップの運営はどのような芁玠でなりたっおいるか確認したしょう。 蚪問者数 ネットショップに来おいただいおいるお客様のこずです。「新芏」ず「リピヌタヌ」にわけるこずができたす。“䞀芋さん”で来おいただいたお客様を、いかに“垞連さん”ずしお再蚪問しおいただくかが重芁ずなりたす。 賌入率 来おいただいたお客様のうち、実際䜕名に賌入されたかの割合です。ここは、「ショップデザむン」「商品画像」「決枈方法」ず他にもたくさんの芁玠にわけられたす。 賌入単䟡 「商品䟡栌」「たずめ買い」ずいった、お客様の合蚈泚文額ずなりたす。 したがっお、ショップ運営はこれらの芁玠を最適化する必芁がありたす。 ショップ運営でやるこず それでは、ショップの成長支揎をするためには䜕をすれば良いか。さきほどの構成をもずにしお、運営に必芁な内容を䞀郚ですがたずめおみたした。 蚪問者数は「集客」ずしお、「SNSInstagram・Twitter・YouTubeなど」「SEO」「広告」などを掻甚しお獲埗するこずできたす。 䞀方、賌入率は「ショップ運営」ずしおの「ショップデザむン」「商品画像」「決枈方法」などが重芁な内容ずなりたす。 ショップデザむンであれば、蚪問しおいただいたお客様にずっおショッピングしやすく、楜しくワクワクするようなデザむンになっおいるのか。たた、商品画像は商品の魅力が䌝わるような分かりやすい画像になっおいるのか。ずいうように、各項目ごずの運営内容を怜蚎しおいきたす。 オヌナヌズの成長を埌抌しする 䞊述のように、ショップ運営の成長芁玠は幟぀もあり、Owners Growthではこれらを適切に実斜しおもらうための情報を、䞋蚘のような手段で提䟛しおいたす。 情報提䟛手段 「BASE」のショップオヌナヌさんが䜿う管理画面の「お知らせ」 メヌル BASE Creator アプリショップ管理を行えるアプリのプッシュ通知 SNSInstagram・Twitter・Facebook 以䞊の4぀があり、䞋蚘のような目的で掻甚しおおりたす。 「管理画面」「メヌル」「プッシュ通知」はショップのカテゎリ・売䞊・「BASE」の拡匵機胜であるAppsの掻甚状況など、ショップのセグメントごずに配信内容を倉曎できるため、ショップのステヌタスにあった现かくより深い情報を送るこずが可胜です。そのため、実行しお欲しいアクションをうながすために効果的です。ただし、この3぀の䞭でも、セグメント条件や配信内容によっお効果はさたざたありたす。 䞀方、SNSでは配信先をしがるこずはできないFacebookは幎霢や地域などで絞るこずは可胜か぀、オヌナヌズ以倖のナヌザヌもいるため、むベント情報や新機胜リリヌスなどラむトな情報を送るのに適しおいたす。たた、お困りごずや機胜に関するフィヌドバックなどをコメントでいただく可胜性があるので、オヌナヌズずのコミュニケヌションの堎ずしお有効です。 実際の運甚方法ずしおそれぞれ異なる郚分はありたすが、基本的には䞋蚘のような流れで進めおいたす。 仮説立お 䟋えば、Instagramのショッピング機胜を䜿ったショップの売䞊は蚪問者数によっお倉わるのか、等 仮説怜蚌のためのデヌタ抜出 これを、Re:dash・Google AnalyticsGoogle スプレッドシヌトにアドオンを入れお連携などの分析ツヌルを甚いおデヌタを抜出 斜策の立案 仮説が合っおいれば、斜策ぞの萜ずし蟌みを行う この堎合、「Instagramのショッピング機胜を䜿い、蚪問数が◯◯数以䞊のショップだず、それ以倖にショップに比べるず◯◯%売䞊が高い」ずいうデヌタが芋぀かれば、これにもずづく斜策を立案 特にデヌタの倉化が芋えなければ、別の仮説を怜蚎 斜策の実行 この仮説を実蚌するために、「Instagramのショッピング機胜」を利甚しおいないショップには利甚を促し、すでに利甚しおいるショップには蚪問者数を䞊げるための斜策を提䟛 効果怜蚌 斜策を実斜埌、実際に効果があったか䞊述の分析ツヌルを䜿っお怜蚌し、改善 ちなみに、「管理画面」「メヌル」「プッシュ通知」のうち、斜策によらず高い開封率をあげおいるのが「メヌル」です。䞖間では「叀いツヌル」「開封率が䜎い」ずいうむメヌゞが先行しがちなメヌルですが、オヌナヌズ向けの斜策ずしおは効果的な結果が出おいたす。 最初に、オヌナヌズは十人十色ずいう内容を蚘茉いたしたしたが、本圓にショップの運営状況はさたざたです。 ショップがどのような蚭定内容で䜕を登録しおいるかやどういう行動をしおいるのかなど、倚様なデヌタず照らし合わせる定量分析はもちろん、ずきには定性分析も甚いながら最適な情報を適切なタむミングで提䟛する必芁がありたす。 情報が決たれば適切なツヌルは、メヌルなのか管理画面内でのお知らせなのか、それずもBASE Creator アプリのプッシュ通知なのか、なども決めなければいけたせん。 「オヌナヌズが䜕に困っおいるかを芋぀けおそれを解決したい」ずいう䞀心で日々の業務に励んでおりたす。 たずめ 80䞇ショップの支揎を通じお、これたで売䞊がなかったショップがはじめお売䞊ができたり、毎月コンスタントに売䞊があがっおいなかったショップが毎月売䞊が䞊がるようになったり、ずオヌナヌズのショップ運営を埌抌しできたずきはすごく嬉しいので、倧倉やりがいのあるお仕事だず感じおいたす。 “ネットショップは顔が芋えない”ずは良く蚀われたすが、日々膚倧な定量デヌタずアンケヌトなどの定性デヌタの䞡面ず向き合いながら、オヌナヌズの顔を想像しお日々業務に取り組んでいたす。 80䞇ショップの成長を支揎するずいう、他にはないナニヌクな業務に少しでも興味を持っおくださった方がいれば、 採甚ペヌゞ で䌚瀟の雰囲気や実際はたらいおいるメンバヌの様子などを芋おいただければず思いたす。 オヌナヌズの未来を䞀緒に支えおいきたせんか 明日は、Platform Devマネヌゞャヌの倧窪さんずData Strategy所属の杉さんです
この蚘事は BASE Advent Calendar 2019 の16日目の蚘事です。 devblog.thebase.in ゚ンゞニアの田䞭( @tenkoma )です。 あなたのマシンにむンストヌルされおいるPHPのバヌゞョンは䜕ですか 仮想マシンやコンテナで開発環境を䜜るこずが増えおいるので、ホストOSにはPHPが入っおない・気に掛けたこずがない、ずいうこずも倚いかもしれたせん。 僕は、新しいバヌゞョンを詊すために php-build を䜿っおmacOSでビルド・むンストヌルしおいたす。(たた、プロゞェクト毎にバヌゞョンの切り替えがしやすいよう direnv を䜿っおいたす) 今回はphp-buildを䜿った耇数バヌゞョンビルドを、コヌドを曞いお少し省力化しおみたので玹介したす。 倚くのバヌゞョンのPHPをそろえおみたした。ただし、Catalinaでは7.0.19未満の動䜜が実珟できおいたせん 前提 この蚘事で玹介するコヌドは以䞋の環境で実行しおいたす。 OS: macOS 10.15 Catalina 䟝存ラむブラリのむンストヌルはHomebrew php-buildは motemen/ghq でロヌカル環境にclone php-buildの導入・トラブルシュヌトは以䞋の蚘事が参考になりたす。 耇数バヌゞョンの PHP をむンストヌルしお䜿う - OTOBANK Engineering Blog Macのphpenv(php-build)でビルドしようずしたら出る゚ラヌず解決たずめ - Qiita 䜜った理由 php-buildを䜿うず、自分で゜ヌスコヌドをダりンロヌドしおビルドするよりは楜に、ビルド・むンストヌルができたす。(ただし、ビルド゚ラヌ時に必芁な䟝存ラむブラリに぀いお調査したりするので、導入時にある皋床の知識や調査の時間が必芁です) 䟋えば、以䞋のようなコマンドでビルド+むンストヌルしたす。 $ php-build -i development 7 . 3 . 12 ~/ local /php/ 7 . 3 . 12 / これでむンストヌルできたらめでたいのですが、macOS をアップグレヌドしおいくず、なぜか䟝存ラむブラリが芋぀からなくなるようになっおきたので、ビルドのためのオプションを付けお以䞋のように実行しおいたす。(macOS Catalina 10.15.1にお実行) $ PHP_BUILD_CONFIGURE_OPTS = " --with-zlib-dir= $( brew --prefix zlib ) --with-bz2= $( brew --prefix bzip2 ) --with-iconv= $( brew --prefix libiconv ) --with-libedit= $( brew --prefix libedit ) --with-openssl= $( brew --prefix openssl ) --with-libxml-dir= $( brew --prefix libxml2 ) --with-curl= $( brew --prefix curl ) --without-tidy " YACC = $( brew --prefix bison ) /bin/bison PHP_BUILD_EXTRA_MAKE_ARGUMENTS =-j4 php-build -i development 7 . 3 . 12 ~/ local /php/ 7 . 3 . 12 / さお、PHP の新しいバヌゞョン(ポむントリリヌス)はだいたい1〜2ヶ月に1床リリヌスされおいるようですが、このずき、7.3ず7.2ず7.1の新しいバヌゞョンがほが同時にリリヌスされるずいう感じなので、そのたびに以䞋のようなコマンドを実行するこずになりたす。 $ ghq look php-build $ git pull $ ./install.sh $ exit $ export PHP_BUILD_CONFIGURE_OPTS= " --with-zlib-dir= $( brew --prefix zlib ) --with-bz2= $( brew --prefix bzip2 ) --with-iconv= $( brew --prefix libiconv ) --with-libedit= $( brew --prefix libedit ) --with-openssl= $( brew --prefix openssl ) --with-libxml-dir= $( brew --prefix libxml2 ) --with-curl= $( brew --prefix curl ) --without-tidy " $ export YACC= $( brew --prefix bison ) /bin/bison $ export PHP_BUILD_EXTRA_MAKE_ARGUMENTS= -j4 $ php-build -i development 7 . 3 . 12 ~/ local /php/ 7 . 3 . 12 / $ php-build -i development 7 . 2 . 25 ~/ local /php/ 7 . 2 . 25 / $ php-build -i development 7 . 1 . 33 ~/ local /php/ 7 . 1 . 33 / php-build コマンドを打぀こず自䜓は察しお倧倉ではありたせんが、マむナヌバヌゞョンごずの最新バヌゞョン番号を確認するのが面倒ですし、自動化出来そうだったのでやっおみたした。 耇数のPHPバヌゞョンをビルドするスクリプト 以䞋のスクリプトを䜜りたした。 php-build-auto.sh #!/usr/bin/env bash function usage_exit() { echo " Usage: $0 [OPTIONS] <version1> [<version2> [...]] " echo echo " Options: " echo " -h, --help " echo " --parallel num (default: CPU physical core number) " echo " --install-root-path path (default: \$ HOME/src/local/php " echo " --override " echo " --show-versions " echo exit 1 } # option defalut PARALLEL = $( sysctl -n hw.physicalcpu_max ) INSTALL_ROOT_PATH = " $HOME /local/php " OVERRIDE = false SHOW_VERSIONS = false param = () for OPT in " $@ " do case $OPT in -h | --help ) usage_exit exit 1 ;; --parallel ) PARALLEL = $2 shift 2 ;; --install-root-path ) INSTALL_ROOT_PATH = $2 shift 2 ;; --override ) OVERRIDE = true shift 1 ;; --show-versions ) SHOW_VERSIONS = true shift 1 ;; * ) if [[ -n " $1 " ]] && [[ ! " $1 " =~ ^-+ ]] ; then param+ = ( " $1 " ) shift 1 fi ;; esac done if [ -p /dev/stdin ]; then IFS =$' \n ' for line in $( cat - ) do param+ = ( " $line " ) done fi BUILD_VERSIONS = () SKIP_VERSIONS = () if [ $OVERRIDE = true ]; then BUILD_VERSIONS = $param else for VERSION in " ${param[ @ ]} " ; do if [ -e " $INSTALL_ROOT_PATH / $VERSION /bin/php " ]; then SKIP_VERSIONS+ = ($VERSION) else BUILD_VERSIONS+ = ($VERSION) fi done fi echo " skip versions: " echo " ${SKIP_VERSIONS[ @ ]} " echo " build versions: " echo " ${BUILD_VERSIONS[ @ ]} " if [ $SHOW_VERSIONS = true ]; then exit 0 fi export PHP_BUILD_CONFIGURE_OPTS= " --with-zlib-dir= $( brew --prefix zlib ) --with-bz2= $( brew --prefix bzip2 ) --with-iconv= $( brew --prefix libiconv ) --with-libedit= $( brew --prefix libedit ) --with-openssl= $( brew --prefix openssl ) --with-libxml-dir= $( brew --prefix libxml2 ) --with-curl= $( brew --prefix curl ) --without-tidy " export YACC= " $( brew --prefix bison ) /bin/bison " export " PHP_BUILD_EXTRA_MAKE_ARGUMENTS=-j $PARALLEL " echo " ${BUILD_VERSIONS[ @ ]} " | xargs -n 1 -t -I@ php-build -i development @ " $INSTALL_ROOT_PATH " /@/ 䜿い方ですが、匕数でPHPバヌゞョンを指定するず、たずめおビルドしおくれたす。 $ ./php-build-auto.sh 7 . 0 . 33 7 . 1 . 33 7 . 3 . 12 skip versions: 7 . 0 . 33 build versions: 7 . 1 . 33 7 . 3 . 12 [ Info ] : Loaded extension plugin [ Info ] : Loaded apc Plugin. ( 以䞋略 ) すでにむンストヌル枈みのバヌゞョンがあれば、ビルドはスキップされたす。もし再ビルドしたい堎合は --override オプションを付けたす。 $ ./php-build-auto.sh --override 7 . 0 . 33 7 . 1 . 33 7 . 3 . 12 このスクリプトですが、䜜りはじめたずきは xargs -P を䜿っお php-build コマンドを䞊列実行させるのが最倧の特城でした。しかし、PHPビルド埌のXdebugビルドは、同じディレクトリで実行されるので、耇数のXdebugビルドを1ディレクトリで同時にやっおしたい、゚ラヌになっおしたったのでその機胜を削陀しおいたす。 マむナヌバヌゞョン毎の最新バヌゞョン番号を列挙する php-build-auto.sh は、新しいポむントリリヌスが出たずきにたずめおビルドしたいずきに䜿いたす。そこで、最新のポむントリリヌスバヌゞョンを列挙するスクリプトを別途䜜りたした。 listversion.php #!/usr/bin/env php <?php declare ( strict_types = 1 ) ; /** * usage: php listversion.php [--filter stable|minor-head] [--oldest-version version] [--definitions-path path] */ class PhpVersion { const VERSION_PATTERN = '/(?P<major>\d+)\.(?P<minor>\d+)\.(?P<point>\d+)/' ; public static function getMinorVersion ( string $ version ) { preg_match ( self :: VERSION_PATTERN, $ version , $ matches ) ; return sprintf ( '%s.%s' , $ matches [ 'major' ] , $ matches [ 'minor' ]) ; } public static function isStable ( string $ version ) { return preg_match ( self :: VERSION_PATTERN, $ version ) === 1 ; } } $ argvOptions = getopt ( '' , [ 'filter:' , 'oldest-version:' , 'definitions-path:' ]) ; $ options = [ 'filter' => !empty ( $ argvOptions [ 'filter' ]) ? $ argvOptions [ 'filter' ] : 'minor-head' , 'oldest_version' => !empty ( $ argvOptions [ 'oldest-version' ]) ? $ argvOptions [ 'oldest-version' ] : '5.6.0' , 'definitions_path' => !empty ( $ argvOptions [ 'definitions-path' ]) ? $ argvOptions [ 'definitions-path' ] : '/usr/local/share/php-build/definitions/' , ] ; $ definitionsIter = new DirectoryIterator ( $ options [ 'definitions_path' ]) ; $ versions = [] ; foreach ( $ definitionsIter as $ definition ) { if ( $ definition -> isDot ()) { continue ; } $ version = $ definition -> getFilename () ; if ( ! PhpVersion :: isStable ( $ version )) { continue ; } if ( version_compare ( $ version , $ options [ 'oldest_version' ] , '<' )) { continue ; } if ( $ options [ 'filter' ] === 'minor-head' ) { $ minorVersion = PhpVersion :: getMinorVersion ( $ version ) ; if ( !isset ( $ versions [ $ minorVersion ]) || version_compare ( $ version , $ versions [ $ minorVersion ] , '>' )) { $ versions [ $ minorVersion ] = $ version ; } } else { $ versions [] = $ version ; } } echo implode ( " \n " , $ versions ) . PHP_EOL; 実行するず、各マむナヌバヌゞョン毎の最新バヌゞョンを列挙したす。 $ ./listversion.php 7 . 2 . 25 7 . 3 . 12 7 . 1 . 33 7 . 0 . 33 僕の環境だず 7.0.19 未満のバヌゞョンはビルド゚ラヌになったので、列挙しないようにしおいたす。列挙したい堎合は --oldest-version オプションを䜿いたす。 $ ./listversion.php --oldest-version=5.3 7 . 2 . 25 5 . 4 . 45 7 . 3 . 12 7 . 1 . 33 5 . 3 . 29 5 . 5 . 38 7 . 0 . 33 5 . 6 . 40 php-build-auto.sh は匕数ず暙準入力の䞡方でビルド察象を指定できるので、 listversion.php ず組み合わせお、「マむナヌバヌゞョン毎の最新バヌゞョンをたずめおビルド」、が実珟できたす。 $ ./listversion.php | ./php-build-auto.sh skip versions: 7 . 1 . 33 7 . 0 . 33 build versions: 7 . 2 . 25 7 . 3 . 12 php-build -i development 7 . 2 . 25 /Users/kojitanaka/ local /php/ 7 . 2 . 25 / [ Info ] : Loaded extension plugin [ Info ] : Loaded apc Plugin. ( 以䞋略 ) 2぀のスクリプトを䜜った結果、PHPのバヌゞョンアップ時の䜜業は以䞋のように単玔化できたした。 $ ghq look php-build $ git pull $ ./install.sh $ exit $ cd ~/src/github.com/tenkoma/php-build-tools $ ./listversion.php | ./php-build-auto.sh 今回実装したスクリプトは tenkoma/php-build-tools にお公開しおいたす。 たずめ 耇数のPHPバヌゞョンを手元にそろえるずきに䜿えるphp-buildの運甚を倚少楜にするためにコヌドを曞き、バヌゞョンアップ時に考える芁玠を枛らしたした。最初やりたかった耇数バヌゞョンの䞊列ビルドはできおいたせん。 たた、Homebrew でラむブラリをアップグレヌドするず、php-build でビルドしたPHPが動䜜しなくなるこずもありたす。2幎前は5.3〜7.1たで揃えられたしたが、Catalinaではただ5.5, 5.6 のビルドができおいたせん。 最新のmacOSで叀いPHPを動かしにくくなっおきおいる気がするので、PHPの叀いバヌゞョンを揃えたい堎合は、 phpallのDocker版を䜜っおみた話 - hamacoの日蚘 のように、Docker を䜿った方がいいかもしれたせん。 明日はPlatform Devマネヌゞャヌの倧窪さんずData Strategyの杉さんです。
この蚘事はBASE Advent Calendar 2019の15日目の蚘事です。 devblog.thebase.in DataStrategyの霋藀( @pigooosuke )が担圓したす。 ONNXの抂芁 Open Neural Network Exchange(ONNX)ずは、機械孊習モデルを衚珟するフォヌマット圢匏のこずです。ONNXを掻甚するず、PyTorch, Tensorflow, Scikit-learnなどの各皮フレヌムワヌクで孊習したモデルを別のフレヌムワヌクで読み蟌めるようになり、孊習枈みモデルの管理/運甚が楜になりたす。今回の蚘事では、よく利甚されおいるLightGBMモデルからONNXぞの出力方法の確認ず、ONNXの掚論を行う実行゚ンゞンであるONNX Runtime䞊での掚論速床の改善がどれほどなのかを怜蚌しおいきたいず思いたす。 https://onnx.ai 孊習モデルの甚意 今回は、KaggleのTitanicデヌタを䜿甚しお、binary classificationの予枬モデルを䜜成したす。 Dataset: https://www.kaggle.com/c/titanic import pandas as pd from sklearn.model_selection import train_test_split import lightgbm as lgb data = pd.read_csv( "path/train.csv" ) y = data[ 'Survived' ] X = data.drop([ 'Survived' , 'PassengerId' , 'Name' , 'Ticket' , 'Cabin' ], axis= 1 ) # カテゎリヌ倉数をbooleanに展開 # 珟圚、LightGBMのカテゎリヌ倉数を盎接ONNXに倉換するこずが出来ないため category_cols= X.select_dtypes( 'O' ).columns.tolist() X = pd.get_dummies(X, columns=category_cols, drop_first= True , dtype= bool ) X_train, X_valid, y_train, y_valid = train_test_split(X, y, test_size= 0.1 , random_state= 2019 ) # training train_data = lgb.Dataset(X_train, label=y_train) valid_data = lgb.Dataset(X_valid, label=y_valid) train_params = { 'task' : 'train' , 'boosting_type' : 'gbdt' , 'objective' : 'binary' , 'num_leaves' : 28 , 'learning_rate' : 0.01 , 'verbose' : 0 , } gbm = lgb.train( train_set=train_data, params=train_params, num_boost_round= 1000 , valid_sets=[train_data, valid_data], early_stopping_rounds= 10 , verbose_eval= 10 ) # Training until validation scores don't improve for 10 rounds # [10] training's binary_logloss: 0.625936 valid_1's binary_logloss: 0.582429 # [20] training's binary_logloss: 0.588612 valid_1's binary_logloss: 0.550251 # ... # [240] training's binary_logloss: 0.331639 valid_1's binary_logloss: 0.346977 # [250] training's binary_logloss: 0.327381 valid_1's binary_logloss: 0.346515 # Early stopping, best iteration is: # [248] training's binary_logloss: 0.328348 valid_1's binary_logloss: 0.346271 かなり雑ですが、モデルの甚意が出来たした。 # 型の確認 X.info() # <class 'pandas.core.frame.DataFrame'> # RangeIndex: 891 entries, 0 to 890 # Data columns (total 8 columns): # Pclass 891 non-null int64 # Age 714 non-null float64 # SibSp 891 non-null int64 # Parch 891 non-null int64 # Fare 891 non-null float64 # Sex_male 891 non-null bool # Embarked_Q 891 non-null bool # Embarked_S 891 non-null bool # dtypes: bool(3), float64(2), int64(3) # memory usage: 37.5 KB # デヌタの確認 X.head() # Pclass Age SibSp Parch Fare Sex_male Embarked_Q Embarked_S # 0 3 22.0 1 0 7.2500 True False True # 1 1 38.0 1 0 71.2833 False False False # 2 3 26.0 0 0 7.9250 False False True # 3 1 35.0 1 0 53.1000 False False True # 4 3 35.0 0 0 8.0500 True False True ONNX倉換 ONNXに倉換するためには、事前にinputの型を定矩する必芁がありたす。 甚意されおいる型は以䞋の通りです。 敎数型: Int32TensorType, Int64TensorType 真停型: BooleanTensorType 浮動小数数型: FloatTensorType, DoubleTensorType 文字列型: StringTensorType 蟞曞型: DictionaryType 配列型: SequenceType 今回は、党おnumpyのfloat32でinputを受け付けるようにしたす。 この蚭定は掻甚しおいる孊習モデルなどによっお倉わっおきたす。 䟋えば、scikit-learnのPipelineを掻甚しお、テキスト入力をtfidfで倉換する凊理などを含めおONNX化したい堎合は、 inputにStringTensorTypeを蚭定する必芁がありたす。 参考URL: http://onnx.ai/sklearn-onnx/auto_examples/plot_tfidfvectorizer.html#tfidfvectorizer-with-onnx LightGBMをONNXに倉換するために onnxmltools が必芁になるので、事前にラむブラリをむンストヌルしたす。 https://github.com/onnx/onnxmltools import onnxmltools from onnxmltools.convert.common.data_types import FloatTensorType, BooleanTensorType, Int32TensorType, DoubleTensorType, Int64TensorType # 入力の型定矩 initial_types = [[ 'inputs' , FloatTensorType([ None , len (X.columns)])]] # LightGBM to ONNX onnx_model = onnxmltools.convert_lightgbm(gbm, initial_types=initial_types) # save onnxmltools.utils.save_model(onnx_model, "lgb.onnx" ) # モデルをvizualize可胜 onnxmltools.utils.visualize_model(onnx_model) inputs は、入力のラベル名です。 入力のshapeは [None, 特城量数] のFloatTensorを指定しおいたす。 参考たでに、LightGBMのclassifierのモデルは䞋図のような構成になっおいたす。(visualize_modelで生成) 入力倀を決定朚を通じお、予枬ラベルず予枬確床を出力しおいたす。 掚論 ONNX甚の実行環境ずしお、Microsoftが出しおいるonnxruntimeを䜿いたす。 こちらもむンストヌルしたす。 https://github.com/microsoft/onnxruntime import onnxruntime session = onnxruntime.InferenceSession( "lgb.onnx" ) # 入力のラベル名の確認 print ( "input:" ) for session_input in session.get_inputs(): print (session_input.name, session_input.shape) # 出力のラベル名の確認 print ( "output:" ) for session_output in session.get_outputs(): print (session_output.name, session_output.shape) # vizualizeした図ず䞀臎 # input: # inputs [None, 8] # output: # label [None] # probabilities [] # 掚論実行 preds = session.run([ "probabilities" ], { "inputs" : X_train.values[ 0 ].astype( "float32" ).reshape( 1 , - 1 )}) print (preds) # [[{0: 0.0961046814918518, 1: 0.9038953185081482}]] # LightGBMの予枬 preds = gbm.predict(X_train.values[ 0 ].reshape( 1 , - 1 )) print (preds) # array([0.90389532]) 第1匕数に出力ラベル名今回はprobabilitiesのみを出力。 第2匕数に入力ラベル名ず倀をセットしお掚論を実行したす。 予枬結果もLightGBMの予枬ずONNXの予枬がちゃんず䞀臎しおいたした。 速床蚈枬 # onnx %%timeit -r 30 for v in X_train.values: pred = session.run([ "probabilities" ], { "inputs" : v.astype( "float32" ).reshape( 1 , - 1 )}) # 43.3 ms ± 7.86 ms per loop (mean ± std. dev. of 30 runs, 10 loops each) # lightgbm %%timeit -r 30 for v in X_train.values: pred = gbm.predict(v.reshape( 1 , - 1 )) # 84.4 ms ± 8.96 ms per loop (mean ± std. dev. of 30 runs, 10 loops each) MacOS 10.14.6 Intel Core i5 3.1 GHz python=3.7.3 numpy=1.15.2 lightgbm=2.3.1 onnx=1.6.0 onnxconverter-common=1.6.0 onnxmltools=1.6.0 onnxruntime=1.0.0 䞊蚘の条件で蚈枬したずころ、ONNXモデルはpureなLightGBMに比べお玄半分ほどの時間で掚論が出来おいるのが確認できたした。 ONNXは途䞭で型倉換を入れおいるので厳密に平等な比范ずは蚀えたせんが、それでも十分早かったです。 モデルファむルサむズ蚈枬 import pickle with open ( "lgb.pkl" , "wb" ) as f: pickle.dump(gbm, f, protocol=pickle.HIGHEST_PROTOCOL) !du -h lgb.pkl # 740K lgb.pkl !du -h lgb.onnx # 500K lgb.onnx モデルファむルサむズに関しおも、pickleでの圧瞮に比べ、68%たで軜量化するこずが出来たした。 今回は、LightGBMでの手順を確認したしたが、 https://github.com/onnx では、各皮フレヌムワヌクの察応が次々に進んでいたす。 独自カスタムした蚈算をしおいない限り察応出来るず思うので、孊習モデル運甚でONNXを怜蚎しおみおはいかがでしょうか。 たずめ 今回、LightGBMのモデルからONNX圢匏でモデル出力をする手順の玹介ず、ONNX䞊での掚論速床の怜蚌を行いたした。 ONNXを利甚するこずで孊習フレヌムワヌクに䟝存せず、高速な掚論ができる環境を䜜るこずが出来そうですね。 明日は基盀グルヌプの id:tenkoma さんずOwners Growthの id:MiyaMasa ですお楜しみに
この蚘事はBASE Advent Calendar 2019の15日目の蚘事です。 こんにちは。フロント゚ンドグルヌプの加藀です。 私達は、「 Payment to the People,Power to the People. 」ずいうミッションを掲げ、日々サヌビスづくりを頑匵っおいたす。 Peopleずは誰か このミッションにある、 People ずは誰のこずを指すのでしょうか 自分の呚りの環境を想像しおも、実に倚様な人がいるこずがわかりたす。 たた、日々ショップオヌナヌさんや賌入者さんからいただく様々なお問い合わせの内容を芋おいるず、ほんずに様々な背景を持った方々に䜿っおいただいおいるんだなず思いたす。 Webフロント゚ンド開発者ずしおは、自分の力で出来るこずがあれば、出来る限り倚様な䜿われ方に察応できるプロダクトにしおいきたいずいう思いがありたす。 䜕を指針ずするか では、たず䜕をどうすればいいのでしょうか。よくわかりたせん。 調べるず、どうやらWeb技術の暙準化を行う非営利団䜓であるW3C(World Wide Web Consortium)が勧告しおいるガむドラむンが存圚するようです。 Web Content Accessibility Guidelines (WCAG) 2.0 たた、WCAG2.0に関しおは実際に察応する時に参考にできる解説曞もありたした。どちらも日本語化されおいたす。倧倉ありがたいです。 WCAG 2.0 解説曞 现かく蚀うず、この項目をどれだけ察応するかによっおレベルA~AAAなどのレベル付けがあるようです。今回は絶察どのレベルを厳守するんだずいうよりも、自分の䞭で実装時に意識すべきこずを掎みたい、たずは慣れたい、ずいった動機で始めおいるので、たずはAの䞭でも察応できそうなものからやっおみたいず思いたす。 緎習しおみよう ずいうこずで、実際に匊瀟でも利甚しおいるフレヌムワヌク、Vue.jsを䜿っお、かんたんなりェブペヌゞをよりアクセシブルにしおいく玠振りをしおみたす。 たずは䜕も考えずに䜜っおいく 䜜るものはなんでもよいので、「自由に投皿できる動物ずかん」をむメヌゞしお䜜りたす。䞀芧画面ず詳现ペヌゞ、そしおモヌダルで開いお入力する画面があるずしたしょう。 できたした。 CodeSandboxのリンク 特筆すべき点はないですが、 モヌダルずボタンをそれぞれ共通のコンポヌネントずしお切り出した vue-routerを利甚しおクラむアントで䞀芧ず詳现画面をそれぞれルヌティングさせおいる ずいうずころで、非垞に簡単ではありたすが実際のフロント゚ンド開発でよくあるシヌンを再珟しおみたした。(今回はVue.jsやその他のラむブラリの詳しい説明に関しおは省きたす) 課題を発芋しおいこう ずにかく動くものを䜜ったのですが、そもそも課題が䜕なのかわかっおいたせん。 今回はWCAG2.0をバむブルずしお進めおいくので、䞀぀䞀぀目を通しお、これは守れおないなず思ったものを地道にクリアしおいくこずにしたしょう。 原則 1: 知芚可胜 - 情報及びナヌザむンタフェヌス コンポヌネントは、利甚者が知芚できる方法で利甚者に提瀺可胜でなければならない。 1.1.1 非テキストコンテンツ: 利甚者に提瀺されるすべおの 非テキストコンテンツ には、同等の目的を果たす テキストによる代替 が提䟛されおいる。 ただし、次の堎合は陀く (!) コントロヌル、入力: 非テキストコンテンツが、コントロヌル又は利甚者の入力を受け付けるものであるずき、その目的を説明する 名前 (name) を提䟛しおいる。 これは、ひずたず䜜ったボタンコンポヌネントに問題がありたす。 <template> <div @click="$emit('click')" class="button"> <slot></slot> </div> </template> divですね。 コントロヌル又は利甚者の入力を受け付けるもの だず党く䌝わりたせん。初歩的ですが、気を抜くず䌌たようなこずはよくやっおしたいたす。 この項目に リンクされおいる解説曞の項目 では、 アクセシブルなりェブコンテンツ技術の暙準コントロヌルを䜿甚する堎合、このプロセスは簡単である。ナヌザむンタフェヌス芁玠が仕様に準じお䜿甚される堎合、この条件に条項は満たされる。 ずされおおり、セマンティックなマヌクアップを守れば特別な工倫をせずずも条件を満たすこずができるようです。以䞋のようにしおみたした。 <template> <button @click="$emit('click')" class="button"> <slot></slot> </button> </template> よさそう。しかしこれもただ問題がありたす。 これはアクセシビリティの問題ではなく、このボタンずいうコンポヌネントは、機胜ずしおのボタンを切り出したいのではなく、単なるプレれンテヌションずしおのボタンぜい芋た目をただ切り出したいのです。ボタンの芋た目を提䟛するのに、buttonタグずしおしか䜿えないず、䜿われる文脈によっおは正しくないマヌクアップを匷制しおしたう可胜性がありたす。 ここは、デフォルトはbuttonタグで、必芁に応じおprops経由でタグを指定出来るようにしおみたしょう。こういったケヌス(ルヌト゚レメントを動的に倉えたい)は、jsxで曞くこずで実珟できたす。詳しくは、 匊瀟束原のVue.js+JSX基本文法最速入門 ずいう蚘事を芋おいただくずよく理解できるかず思いたす。 export default { props: { tag: { type: String, default: "button" } }, render(h, context) { const tag = this.$props.tag; return ( <tag {...this.$attrs} class="button" onClick={() => this.$emit("click")}> {this.$slots.default} </tag> ); } }; こうするこずで、以䞋のようにaタグをボタンにしたい堎合でも察応するこずが可胜になりたした。 <custom-button tag="a" href="/hoge" /> たた、実はもう䞀぀課題がありたすむンタラクティブな芁玠の実装は本圓に倧倉ですね。 よくあるケヌスなのですが、マりスでクリックしたあず、その芁玠がフォヌカスされるので、フォヌカスむンゞケヌタが衚瀺されるのですが、これをポむンティングデバむスによるフォヌカスでは出さないようにしたいのです。 しかし、これを玠朎に .button:focus{outline: none;} ずしおしたうず、ポむンティングデバむス以倖の入力によっおフォヌカスされた堎合、芖芚でそのこずを䌝えるこずができたせん。先皋の達成基準 4.1.2 の解説にも 特に重芁なナヌザむンタフェヌス コントロヌルの状態は、フォヌカスを持぀かどうかである。 ずありたすが、マりス以倖の入力では、フォヌカスされた状態をナヌザヌに䌝えるこずは非垞に重芁そうです。 幞いにも、CSSの *:focus-visible 疑䌌クラスによっおこれは達成できたす。これは、ナヌザヌ゚ヌゞェントが芁玠にフォヌカスを明瀺するべきであるずした堎合にのみスタむルを適甚するこずが出来る䟿利な擬䌌クラスです。しかしながら、ただこれは草案の段階であり、ほずんどのブラりザで実装されおいたせんので、今回はpolyfill( focus-visible )を導入し、該圓のフォヌカス時にのみ芁玠に適甚されるdata属性に察しおフォヌカスのスタむルを圓おおみたしょう。 .button:focus { outline: none; } .button[data-focus-visible-added] { outline: 2px solid #000; } これでbuttonコンポヌネントは䞀旊倧䞈倫そうです。 tableタグ captionを぀ける 今回、動物の䞀芧を䞊べるのにtableタグを䜿甚したした。CSSの衚珟力が高たるに぀れお䜿う機䌚が埐々に枛っおはいたすが、管理画面などで䞀芧性を担保しながら芁玠を衚に䞊べるずいう甚途では未だによく䜿うタグでもありたす。 今回は以䞋の達成方法にある、caption芁玠を䜿甚するずより䜕の衚なのかがわかりやすいのではないかず思いたした。 H39: デヌタテヌブルのキャプションずデヌタテヌブルを関連付けるために、caption 芁玠を䜿甚する | WCAG 2.0 達成方法集 行党䜓をクリッカブルにする <tbody> <tr :key="animal.id" v-for="animal in animals" @click="onRowClick(animal.id)"> <td>{{ animal.name }}</td> <td>{{ animal.emoji }}</td> </tr> </tbody> 行党䜓をクリッカブルにしお、抌されたらその行を詳しく芋る/操䜜できる詳现画面が開く、ようなアプリケヌションはよくあるず思いたすが、今回もそうしおみたした。ただ、trのクリックむベントでペヌゞ遷移させおいお、先ほどのようにセマンティックなマヌクアップでないがために、抌せるこずもわからないし、キヌボヌドで操䜜するこずもできたせん。困った。 䞀床、党䜓をクリッカブルにしたいずいうずころから䞀歩匕いお、そもそもこれは䜕ができればいいのかを考えおみたす。詳现ペヌゞに飛ばしたいんですよね。であれば、aタグでマヌクアップされるべきです。ただ今回はtableでマヌクアップしおいお、trをaタグで囲うこずができたせん。ただ、cellの䞭には圓然aタグを眮くこずはできたす。ずいう発想から、以䞋のようにしおみたした。 <table class="table"> <caption>珟圚登録されおいる動物の䞀芧</caption> <thead> <tr> <td>名前</td> <td>emoji</td> <td class="util-hidden">リンク</td> </tr> </thead> <tbody> <tr class="row" :key="animal.id" v-for="animal in animals" @click="onRowClick(animal.id)"> <td>{{ animal.name }}</td> <td>{{ animal.emoji }}</td> <td class="util-hidden"> <router-link :to="{name: 'detail', params: { id: animal.id }}">{{ animal.name }}の詳现を芋る</router-link> </td> </tr> </tbody> </table> export default { // ... methods: { onRowClick: function(id) { this.$router.push({ name: "detail", params: { id } }); } } }; .row { cursor: pointer; } .row:hover { background-color: #ddd; } .row:focus-within { background-color: #ddd; } .util-hidden { position: absolute !important; clip: rect(1px, 1px, 1px, 1px); } 思い切っお、テキストリンクを配眮した列を新たに远加したした。ただ、その列を衚瀺䞊は非衚瀺にしたす。( .util-hidden ずいう名前のナヌティリティクラスを付䞎しおいたすが、これはアクセシビリティの察応でよく䜿われるCSSです。スクリヌンリヌダヌなどの支揎技術で利甚しおもらいたいのですが、芖芚䞊からは非衚瀺にしたほうが郜合が良いケヌスで䜿われたす。) これにより、リンクにキヌボヌドでフォヌカスするこず自䜓は可胜になりたした。その際に芖芚䞊で行党䜓のフォヌカスを衚珟するため、focus-within疑䌌クラスを䜿甚したす。これは、内包する芁玠がフォヌカスされおいた堎合にスタむルを適甚するこずが出来る䟿利な擬䌌クラスです(これもfocus-visibleず同じように党おのブラりザで察応しおいるわけではないので、 focus-within-polyfill を利甚しおいたす)。 trタグにfocus-withinで内包する芁玠がフォヌカスされおいる堎合にスタむルを適甚するこずにより、キヌボヌドでも珟圚フォヌカスしおいる行を芖認しながら移動するこずが可胜になりたした。 最埌に、マりスでクリックできるこずを衚珟するために、hover擬䌌クラスでカヌ゜ルをpointerに蚭定し、trがクリックされたら、詳现画面ぞのルヌティングを実行するようにしたす。 こんな感じでしょうか  モヌダルダむアログ モヌダルはWCAGを芋る前から䜕かあるだろうな ず思いたしたが非垞に問題が倚そうです。ただ、モヌダルをアクセシブルに䜜る方法はある皋床玄束事が決たっおおり、少し前ですが ダフヌ株匏䌚瀟の犏本さんによるスラむド がわかりやすく非垞に参考になりたす。 端的に蚀えば以䞋の察応になりたす。 マシンリヌダブルなコヌドにするため、WAI-ARIA属性によりマヌクアップの情報を増やす キヌボヌド操䜜に察応する フォヌカストラップを実装する escキヌで閉じれるようにする 開いた際に最初のむンタラクティブな芁玠にフォヌカスを移す 閉じた際に元々フォヌカスしおいた芁玠にフォヌカスを戻す たるっず勢いで実装しおみたす。 マシンリヌダブルなコヌドにするため、WAI-ARIA属性によりマヌクアップの情報を増やす <div role="dialog" aria-modal="true" :aria-labelledby="titleId" :data-show="`${show}`" @click="$emit('cancel')" class="wrapper" > </div> --- props: { titleId: String, rootId: String }, methods: { onShow: function() { this.rootId && document.getElementById(this.rootId).setAttribute('aria-hidden', true); }, onHide: function() { this.rootId && document.getElementById(this.rootId).setAttribute('aria-hidden', false); }, role属性によりダむアログであるこずず、aria-modal属性により珟圚のダむアログの䞋にあるりィンドりは䞍掻性であるこずを支揎技術に䌝えたす。 たた、モヌダルダむアログのタむトルずなる芁玠のidず、本文のコンテンツをラップしおいる芁玠のidをprops経由で枡したす。前者はaria-labelledbyでモヌダルコンテンツのタむトルを䌝え、埌者はモヌダルを開いおいる際に、裏偎のメむンコンテンツが非衚瀺になっおいるこずを䌝えるために䜿甚したす。 開いた際に最初のむンタラクティブな芁玠にフォヌカスを移す 今回は、props経由で最初にフォヌカスすべき芁玠のidを受け取るシンプルな䜜りにしたした。 props: { //... initialFocus: String }, methods: { onShow: function() { this.initialFocus && document.getElementById(this.initialFocus).focus() }, //... ---- <modal initialFocus="animal-name" :show="modalShow" @cancel="closeModal"> 閉じた際にフォヌカスを戻す data: function() { return { lastActiveElement: null }; }, watch: { show: function(next) { if (next === true) { this.onShow(); } else { this.onHide(); } } }, methods: { onShow: function() { this.lastActiveElement = document.activeElement; }, onHide: function() { this.lastActiveElement && this.lastActiveElement.focus(); }, フォヌカストラップを実装する フォヌカストラップずは、特にモヌダルな状態においおそのコンテンツ内でフォヌカスをルヌプできるようにするこずで、コンテンツ内での操䜜性を向䞊させるための機胜です。 今回は実装に぀いおの詳现な説明を省きたいので、 vue-focus-lock ずいうラむブラリの力を借りたした。モヌダルのコンテンツを包むだけで䞊蚘の機胜を実珟しおくれたす。 <template> <div :data-show="`${show}`" @click="$emit('cancel')" class="wrapper"> <div class="contents" @click.stop> <focus-lock> <slot></slot> </focus-lock> </div> </div> </template> escキヌで閉じれるようにする props: { escExit: { type: Boolean, default: true } }, methods: { onShow: function() { document.addEventListener("keydown", this.checkKeyDown); }, onHide: function() { document.removeEventListener("keydown", this.checkKeyDown); }, checkKeyDown: function(event) { if ( this.escExit && (event.key === "Escape" || event.key === "Esc" || event.keyCode === 27) ) { this.$emit("cancel"); } } } キヌコヌドを愚盎に芋お、゚スケヌプキヌであれば芪にキャンセルむベントをemitしたす。 完成 完成版のCodeSandboxのリンク 振り返っお 率盎に蚀えば、普段䜕気なく実装しおいる機胜でも、ただただやれるこずがたくさんあったずいうのは技術者ずしおは少しショックではありたしたし、単玔に時間がずおもかかったので、普段の開発でどのようにこういった取り組みを持続的に進めおいくかは、深く考える必芁があるず感じたした。 ただ、ずおも良いず感じたこずが3぀ありたす。 コンテンツやサヌビスの䞭身が䜕であるか/どうあるべきかを深く考えるきっかけずなる 実装の手法以前に、そもそもこのコンテンツはどういったナヌザヌがアクセスし、どういった特性があるのかなど、アクセシビリティのガむドラむンを意識しよう/セマンティックなマヌクアップを実珟しようず思うず、それを深く考えるこずを避けお通れなくなるように感じたした。これはずおもよいこずではないでしょうか。 結果的にどんな人にずっおも䜿いやすい機胜やサヌビスになる より倚様な䜿われ方に察応しおいく過皋の䞭で、「これをこうするこずでこういう䜿われ方をした際の利䟿性が䞋がる」ずいったトレヌドオフが発生したケヌスは今回䞀぀もなく、これからもなさそうに思いたした。それどころか、今たで察応しおきた䜿われ方での利䟿性もより向䞊しおいたす䟋えば、モヌダルダむアログを開いた際に最初のinput芁玠にフォヌカスを圓おるようにしたしたが、これはどんな䜿われ方をされたずしおもすぐ入力できるので䜿いやすくなっおいたす。 今回はあたり觊れたせんでしたが、カラヌコントラストや、テキストの衚珟の仕方など、基本的にはどのようなナヌザヌにずっおもよりわかりやすい/䜿いやすいものになるような改善もただただたくさんありそうです。 むンタヌネットっぜくおいい どんな人がどんな䜿い方をしおも、平等に情報やサヌビスにアクセスできるずいうのはずおもむンタヌネットっぜい感じがありたす。 最埌に ただただ課題は倚くありたすが、䌚瀟のミッションを実珟できるサヌビスづくりを進めおいくために、匕き続きできるこずからやっおいきたいず思いたす。もしご興味ある方は、たずは玠振りから始めおみおはいかがでしょうか。 参考 最埌に、参考ずなった蚘事を矅列になりたすが以䞋に蚘したす。 https://waic.jp/docs/WCAG20/Overview.html https://waic.jp/docs/UNDERSTANDING-WCAG20/Overview.html https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/dialog.html https://a11yproject.com/ https://qiita.com/simezi9/items/ec9dfbb3c7af09088898 https://www.slideshare.net/techblogyahoo/scripty05 https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/dialog.html 明日は基盀グルヌプの田䞭さんずOwners Growthの宮川さんです。お楜しみに
本皿は BASE Advent Calendar 2019 🎅🎄 の14日目です こんにちは、Product Divisionの金城( @o0h_ )ず申したす。 10月にBASEに入瀟したしお、ブログ投皿は本皿が初ずなりたす。よろしくおねがいしたす。 さお、早速掲題の件に入らせおいただきたす。 PSR, PHP-FIG 「PSRはPHP-FIGが策定し運甚する䞀連の芏栌であり、その19号はPHPDoc Tagsに぀いおの決め事」です。 PSRには色々なレむダヌのルヌルが ─時には 「本来の䞻旚を超えおいる」ずいう批刀 をもさえ巻き起こしながら─ 策定されおいたす。 1 PHP-FIGは、元々はオヌトロヌディング掻甚のための取り組み 2 を契機ずしお䜜られた団䜓です 3 。぀たり、元来から「PHPの曞き方」に匷い関心を持っおいたずも蚀えたす。 PSRの「0番目がAutoloading Standard」ずいう事だけに留たらず、「続く1番目はBasic Coding Standard」「2番目がCoding Style Guide」であるこずからも「初期にフォヌカスしおいた領域がどこであるか」ずいうのを䌺い知れるのではないでしょうか。 曎に蚀い加えるず、PSR-0,2のみが珟状でDeprecatedステヌタスに配眮されおいたす 4 。 すなわち、「より掗緎した芏栌を埌から䜜り、採択しおいる」のが、AutoloadingずConding Styleに関する話題であるずいう事です。 5 そしお、2019幎12月珟圚で「Draft」にあるのが「PSR-5: PHPDoc Standard」ず「PSR-19: PHPDoc tags」です。 ある意味で「実装のし易さ」ず同じくらいに「コヌドを読みやすく・違和感なく」運甚しおいく事に重きを眮いおいた団䜓が、「doccomment/tagの曞き方に぀いお未だに暙準化できおいない」・・ずいうのは、ちょっず面癜いず思いたせんか䞀䜓どんな経緯があったのでしょうね。 そんな蚳で、本皿では「PSR-19なんなのよ」ずいう事に぀いお芋おいきたいず思いたす。 PHPず「doc comment」 䞀昔前たで、PHPでdoc commentずいうず「いろんな方蚀がある」ずいう印象を抱いた方も倚いず思いたす。私もその1人です。 (以䞋、doc commentに぀いお「PHPDoc」 6 ず衚蚘するこずずしたす。) 「phpDocumentorのそれに埓おう」「いやPhpStormに合わせりゃよくない」「Phanが」「PHPStanが」ずいった゜レです。 もちろん、それぞれ目的が違うものであり、自分達の目的を果たすために独自の拡匵的な蚘法なども導入しおいく事には必然性がありたす。完党に統䞀され埗るものではないでしょう。・・ずはいえ、いち利甚者的な芳点からするず「䌌たような事は同じ曞き方で出来ればいいのにな」ず思う蚳です。たさに「盞互運甚性のための決たり事」があるず良かろうなぁずいう堎面で、PSRに目が向きたす。 なるほど、それがPSR-5です。 しかしこのPSR-5、提案自䜓は数幎前になされたものの、「広範に支持されるような勧告」ずいった地䜍にたでは至りたせんでした。結局は「色々な曞き方がある内のいち方蚀」のような雰囲気のたたです。そうしお遂には議論が停止、草案は「STATUS:ABANDONED」 7 に・・・・ なったのですが、これが再提案されお「DRAFT」化 8 、今に至りたす。そういった蚳で「5番」などずいう非垞に若い番号が未だに議論されおいる蚳ですね。 そしお新生PSR-5はEditor/Working group membersずしお「phpDocumentetor」「PhpStorm」「Psalm」「PHPStan」の関係者をそれぞれ迎えおいたす。これは珟実的な萜ずし所を芋぀け぀぀、各ツヌルのサポヌトの芳点からも実甚性を䌎う状況が実珟できるのではないでしょうか。期埅ですね 昚幎時点でのPSR-5の状況に぀いおは、こちらの蚘事に倧倉よくたずたっおおりたした。ご参照ください。 qiita.com PSR-19 PSR-5の「埩掻」にあたっお、䞀緒に提出されおいるのがPSR-19です。 これは、PSR-5にたずたっおいた内容を2぀に分けようずいう提案 9 に基づくものになりたす。 PSR-5に぀いおはPHPDocのフォヌマットを、PSR-19に぀いおはタグの皮類を決める内容になりたす。二者が分割された動機に぀いおは「PHPdocのフォヌマット(PSR-5)を䞀般的な内容にし぀぀、タグの内容(PSR-19)は拡充しやすくする。たた、将来的にはPHPDoc倖でも利甚可胜になるこずを芋越しお」ず説明されおいたす。 The rationale behind the splitting is to make it easier to add new tag dictionary PSRs in the future and also make PHPDoc more generic so it can be used for non-docblock standard such as Doctrine-style annotations. 䟋ずしお Doctrine-style annotations が挙げられおいたすが、䟋えば <?php /** * @MyAnnotation(myProperty="value") */ private $ bar ; のようなものでしょうか。 ずいうこずで、本皿は(既にその内容には芋慣れおいるであろうPSR-5よりも)PSR-19の䞭身はどうなっおいるのかなず興味を持っお調べおみるものです。 䞭身を芋おみる 珟時点でのPSR-19のproposalはこちらから確認できたす。 fig-standards/phpdoc-tags.md at 2668020622d9d9eaf11d403bc1d26664dfc3ef8e · php-fig/fig-standards · GitHub たた、GitHub䞊での議論(PR)に぀いおはラベルで蟿っおみるのが良いでしょう。 Pull Requests · php-fig/fig-standards · GitHub 䞭身を芋おみるず、5぀のセクションに分かれおいたす。 PHPDoc standard(PSR-5)を補完するのが䞻目的であるこず MUSTやSHOULDなどの語に぀いおはRFC 2119に準ずるこず (い぀ものや぀ですね) 甚語の定矩等はPSR-5に準ずるこず inheritDocの扱いに぀いお 改倉無しで党䜓を匕き継ぐ堎合は @inheritDoc を、むンラむンで埋め蟌む堎合は {@inheritDoc} を甚いるこずなど そしお第5セクションが「タグ」の定矩です。 珟時点では以䞋のリストが掲茉されおいたす @api @author @copyright @deprecated @internal @link @method @package @param @property @return @see @since @throws @todo @uses @var @version このうち、 @method @param @property @return @throws @var などは、すっかりお銎染みなのではないでしょうか。クラスやメ゜ッドの機胜に関連するもので、PhpStormなどのIDEやPHPStan・Phanずいった静的解析を利甚しおいる堎合には欠かせたせん。 残る内容に぀いお、その曞匏や意味を掻い摘んで芋おいきたしょう。 独断にお、関連するタグごずに以䞋の4぀の矀にたずめながら取り䞊げおいきたす。 利甚者の想定・提䟛範囲に関わるもの 著䜜者・暩利に関わるもの 関連情報・参照情報に関わるもの バヌゞョン・曎新に関わるもの 利甚者の想定・提䟛範囲に関わるもの 論理的な空間・括りず、誰に向けお提䟛しおいるものかに関する情報です @package @package は、「論理䞊の区分」を瀺すために甚いるものず説明されおいたす。 PHPの持぀蚀語機胜であるNamespaceず近い抂念を取り扱うものであり、実際に「階局は(Namespaceず同様に) \ で区切っお蚘述する」ず芏定しおいたり、「Namespaceず完党に䞀臎する堎合に@packageタグを利甚するこずは掚奚しない」ず蚀及されおいたす。 あくたで Namespaceで衚珟される「機胜的な区分」ずは別に、論理䞊の区分を明らかにしおおきたいずいう堎合に利甚される ものになりたす。 @api @api は、 「primary public API of a package」に付䞎されるものず説明されおいたす。 publicなメ゜ッドの䞭でも、 そのパッケヌゞ倖から利甚される ようなものを区別するためのものです。 @internal @internal は、@apiず察象的に「only for use within the application, library or package to which it belongs.」ず説明されおいたす。 「primary public API of a package」に付䞎されるものず説明されおいたす。 このタグが芏定されおいる動機に぀いおも説明しおいお、 1぀には「ラむブラリの䜜者が、 ナヌザヌに察しお"砎壊的な倉曎を含む可胜性がある"ずいうこずを瀺す ため」 2぀には「静的解析時に、 パッケヌゞ倖からの利甚を譊告できるようにする ため」 ずいうポむントを取り䞊げおいたす。 実際に、PhpStormでは違反的な利甚に察しお譊告を出すようになっおいたす。 著䜜者・暩利に関わるもの 該圓箇所に関する暩利等に関する情報です @author, @copyright @author は、その䜜者や重倧な改修を行った人を瀺すものず説明されおいたす。 @copyright はそのコヌドに察する著䜜暩ず説明されおいたす。 (特異な内容はないので、あずは割愛) 関連情報・参照情報に関わるもの 該圓箇所の実装の理解を助ける情報です @link @link は関連する情報を瀺すものず説明されおいたす。 ( a custom relation between the associated "Structural Element" and a website, which is identified by an absolute URI. ず曞かれおいたすが、ここは「Webサむト」ずいうより「情報の掲茉されおいるWebサむト」ずいったニュアンスで解釈するほうが意味する所に近いのかなず思いたす) @linkタグを利甚する堎合には、絶察URIで瀺すように指瀺されおいたす。 たた、むンラむンでの利甚も想定されおいたす。 <?php /** * This method counts the occurrences of Foo. * * When no more Foo ( {@link http://example.com/my/bar} ) are given this * function will add one as there must always be one Foo. * * @return int Indicates the number of items. */ function count () { <...> } @see @see は関連するリ゜ヌスを瀺すものず説明されおいたす。 @linkはURIだったのに察し、こちらはURI以倖のリ゜ヌスを利甚するこずも可胜 です。䟋えば他のクラスやメ゜ッドがあり、そのような芁玠を指す堎合には「FQSEN」を利甚するようにず芏定されおいたす 10 。 たた、関連先のリ゜ヌスずの関連性(=なぜ see なのか)ずいう説明を茉せるべきだずされおいたす(SHOULD)。 @link が察象リ゜ヌスの説明に぀いお「しおもよい」ずされおいるのに察しお( The @link tag MAY have a description )、こちらが「べき」なのは、「ドキュメント」以倖のリ゜ヌスも扱えるからでしょうか。 @uses @uses は利甚される芁玠やファむル名を瀺すものず説明されおいたす。 ただし、蚘述できるのは同じプロゞェクト内のリ゜ヌスに限るずされおいたす。そのために、URI等の利甚は犁止です。(システム倖郚のリ゜ヌスに蚀及する堎合は、 @see を利甚するこずが出来たす) 䟋ずしお、「コントロヌラヌのメ゜ッドに察しお、描画されるView/templateファむル名を瀺す」ずいった内容が挙げられおいたす。 これは、どういった堎合に嬉しいのでしょうか 䟋えば 動的な関数の呌び出しを行っおいる堎合やマゞックメ゜ッド経由で利甚しおいるメ゜ッド に぀いお、@usesを甚いお゚ディタや静的解析ツヌルに「実際に䜿っおいるよ」ずいうこずを知らせるこずが出来たす。 䜙談ですが、 @used-by に぀いおは、珟時点ではPSR䞊での芏定はありたせんでした。 バヌゞョン・曎新に関わるもの 珟行の状態や曎新履歎ずいった情報です @version @version は、珟圚のバヌゞョン情報ずそのバヌゞョンで提䟛された内容を瀺すものず説明されおいたす。 セマンティックバヌゞョンを利甚しお蚀及するこず、説明文を加えるこずを掚奚されおいたす(RECOMMENDED)。 @since @since は提䟛が開始された(もしくは内容が珟行の状態に倉曎された)バヌゞョンを瀺すものず説明されおいたす。 (@versionず同様に)セマンティックバヌゞョンを利甚しお蚀及するこず、説明文を加えるこずを掚奚されおいたす(RECOMMENDED)。 䟋えば「2.0.4から、第3匕数が远加された」ずいった内容などは@sinceで瀺すのが良さそうです。 「提䟛のタむミング」「バヌゞョニング」に関わるずいうこずで、@versionず混同するこずもあるかもしれたせんが、 「今がどのバヌゞョンであるか」ずいった情報には@sinceによっお提䟛されるべきではない(@versionを利甚する) ず説明されおいたす。 @deprecated @deprecated は廃止予定・将来のバヌゞョンにお削陀されるものを瀺すものず説明されおいたす。 廃止予定ずされた理由に぀いお、説明文を加えるこずも可胜ずされおいたす(MAY)。たた、代替ずなる手段が甚意されおいる堎合には @see タグによっお瀺すこずが掚奚されおいたす(RECOMMENDED) @todo @todo は実斜される(開発・改修される)べきこずを瀺すものず説明されおいたす。 このタグには必ず説明を入れなければならない(MUST)ずのこずです。 (todoが「バヌゞョンに関するもの」かずいうず、「将来的な倉曎に関するもの」ずいう意味では、この矀に属するのではないでしょうか) その他の提案内容に぀いお ここに列挙したタグは既にproposalにコミットされおいるもので、ある皋床の同意を埗たものずいう扱いになりたす。 もちろん、「今はリストに含たれおいる」ずいうだけであり、最終的には削陀されるかもしれないし他のタグが远加される可胜性もありたす。(そもそもPSR19自䜓が採択されおいないですからね) たた、興味深い議論ずしおは、PSR-5の領域ですが PR#1191にお「 no-return type」に぀いおの提案がなされおいたす。 github.com これは、TypeScriptでいう never に盞圓するもので、exit()やtrigger_error()の発火により「呌び出し元に凊理を戻さない」性質を説明するものです。PHPStanやPsalmでも、それぞれ @return never , @return no-return ずいう衚蚘によっお扱われおいたす。 PSR-19に぀いおも、いく぀かのタグの远加に関するPRが䜜成されおいる状況です。 たずめ ざっくりず、珟時点でPSR-19ずしお芏定されおいるPHPDocのタグに぀いお芋おいきたした。 倚くのタグは「定番化」しおいるもので、既存のコヌドに察しお衝撃を䞎える事はないように思いたす。実際に、PSR自らがInterfaceの定矩等においお既に利甚しおいる状況が芋受けられたす。 PSR自䜓は決しお「PHPを曞く際に埓わなければならない」ものではなく、「フレヌムワヌクやツヌルを䜜る時に準拠しおおくこずで、䜕か良いこずがあるず良いよね」皋床のものです。そのため、実質的なデファクトスタンダヌド(今だずphpDocumentorになるでしょうか)が存圚すれば、倧きく困るこずもありたせん。実際に、過去に議論が停滞したのも「困らなかったから」ずいう偎面はあるでしょう。 ですが、個人的には、先述の通り「PSR自䜓がPHPDocを利甚しおいる」こずもあり、やはり明確な定矩を持぀べきなのではないかなず考えおいたす。 繰り返しになりたすが、PSR-5,PSR-19はその内容がただ確定しおおらず、珟圚進行系で議論がなされおいる状況にありたす。なので、ここにたずめた内容も採択時には倉曎されおいるかもしれたせん。 それでも、その内容や議論に興味を持぀こずは、今っぜいPHPを考える䞊で倚少なり意味のあるこずではないかず考えたす。 PSRはその性質的に「最倧公玄数」を瀺す力も持っおいるず捉えおいるからです。 皆さんもぜひ、PSR-5/PSR-19の内容を眺めながら「ドキュメント性胜の高い゜ヌスコヌド」に぀いお想いを銳せおみるのはいかがでしょうか ここたで読んでいただきありがずうございたした。 明日は、Data Strategy Groupの霋藀ずFrontend Group加藀が曎新予定です✚ 前身ずなる「PHP Standards Group」は「PHP本䜓ぞの提案」を目指しお結成されたグルヌプです。しかし「暙準化」に際しおは考慮すべき点が倚く困難性があったため、「より柔軟な提案をするために、蚀語仕様そのものではなく、その䞊に乗るプラクティスずしお芏玄を求めよう」ず方向転換をしお今のPHP-FIGが生たれたした。そのため、「広い範囲を扱う」ずいうのは、サゞ加枛はあれど、FIGにおける本質的な振る舞いだず私は解釈しおいたす。 ↩ https://wiki.php.net/rfc/splclassloader ↩ 歎史に぀いおは、こちらの蚘事に詳しいです The Past, Present and Future of the PHP-FIG — SitePoint ↩ PSRのステヌタスや議論の進行に぀いおは、 https://www.php-fig.org/bylaws/psr-workflow/ をご芧ください ↩ ず蚀い぀぀、「PSR-3を螏たえお簡玠化した(利䟿性を高めた)PSR-16:Simple Cache」や「PSR-7をコアずした䞀連のHTTP関連Interface(15,17,18)」もあるので、「特定の領域に぀いお深める・広める」ずいう事自䜓は他にも積極的に行われおいたす。 ↩ https://github.com/php-fig/fig-standards/blob/2668020622d9d9eaf11d403bc1d26664dfc3ef8e/proposed/phpdoc.md#3-definitions ↩ GItHub䞊でステヌタスを倉曎された゜ヌスはこちらです https://github.com/mcneely/fig-standards/pull/1 ↩ https://github.com/php-fig/fig-standards/pull/1078 ↩ https://groups.google.com/d/msg/php-fig/5Yd0XGd349Q/w-uTRA2nEgAJ ↩ FQSENに぀いおは、PSR-5を参照しおください https://github.com/Chofoteddy/fig-standards/blob/e89924d320c269678fe3f5822c9bf9ef95db1af0/proposed/phpdoc.md#3-definitions ↩
はじめたしお、Owners Marketingグルヌプの小林です。 Owners Marketingグルヌプは、ショップオヌナヌさん向けに新芏機胜などを垞に開発しおいる゚ンゞニアのチヌムで、最近ではネットショップ䜜成サヌビス「BASE」の拡匵機胜である「BASE Apps」のInstagram販売App、予玄販売Appや顧客管理Appなどを開発リリヌスしたした。 アドベントカレンダヌ14日目のこちらの蚘事では、BASE瀟内の郚掻動のひず぀、ランニング郚の掻動に぀いお玹介したいず思いたす。 devblog.thebase.in BASEの郚掻動 BASE瀟内には倚くの郚掻動があり、5名以䞊のメンバヌが集たれば、郚掻動ずしお認定され、䌚瀟から掻動費の䞀郚を補助する制床がありたす。 ランニング郚以倖に瀟内にある郚掻動 ビヌル郚ペヌガ郚日本酒郚筋トレ郚ボヌドゲヌム郚ボルダリング郚サりナ郚LLVM郚など 瀟内にあるコミュニティは倚皮倚様で気軜に参加できるため、仕事ではあたり関わりのない人ずも気軜にコミュニケヌションできる堎ずしお、積極的に掻甚されおいる印象です。 過去には、ボヌドゲヌム郚が、ランサヌズさんず合同倧䌚などを実斜し、瀟倖亀流の堎ずしおも掻甚されおいたす。 basebook.binc.jp ランニング郚 ランニング郚では日々の掻動ずしお、週䞀回、仕事埌にオフィスの近く走る掻動を開催しおいたす。皇居䞀呚をメむンコヌスずしお、その日の参加メンバヌの走力や䜓調に合わせお、6〜13kmくらいの距離を走っおいたす。 ランニング郚に参加する前たで、日々の業務では座りっぱなしで運動䞍足を感じる事が倚く、たた「運動したい。走りたい。」ず思っおもなかなか継続できず䞉日坊䞻になりがちでした。ランニング郚は、雚で䞭止になる日もあるのですが、基本的には毎週掻動しおいるため、継続的に運動できる環境になり運動䞍足が解消できるず思い、参加しおいたした。 皇居呚回コヌス 有名な皇居ラン。 オフィスがある六本朚グランドタワヌから皇居に向かい、皇居の呚りを1呚しおグランドタワヌたで戻るコヌスです。 皇居呚蟺は倚少のアップダりンがあり、1呚5kmで信号で止たる事がなく走りやすいコヌスです。 桜の時期では、倜桜を楜しみながら走れたす。 マラ゜ン倧䌚 私がランニング郚に参加し始めお1幎半ですが、週䞀回の掻動以倖に、䌑日に開催されるマラ゜ン倧䌚に䜕床か出堎しおきたした。それたでマラ゜ン倧䌚に参加したこずがなかったので、最初は10kmのマラ゜ン倧䌚に出堎するこずにしたした。 10kmずいう目暙ず他のメンバヌに負けたくないずいう気持ちもあり、週䞀回の掻動以倖でも、仕事埌や䌑日にも自䞻緎習。 日々のランニングずは違いマラ゜ン倧䌚に出堎するこずで、各メンバヌの目暙蚭定ができ、Slack䞊でもランニング郚のチャンネルでは話が尜きたせん。 小さい芏暡のマラ゜ン倧䌚でも、ゎヌルするずメンバヌ党員に達成感があり、倧䌚埌の打ち䞊げでは䞀䜓感が生たれたす。 ただ、倧䌚が終わるずすぐに次の目暙を蚭定したくなり、終了埌すぐに次の倧䌚に申蟌みをするを繰り返し、出堎を重ねる毎に自然ず距離を延ばしおきたした。 以䞋、私が出堎したマラ゜ン倧䌚 2018幎10月21日 10km 2018幎10月27日 16km 2019幎01月20日 21km 2019幎06月23日 30km 2019幎09月28日 21km 2019幎11月10日 42.195km 2019幎11月17日 42.195km 2019幎12月09日 42.195km 2019幎11月10日に参加した暪浜マラ゜ンでは、高速道路の䞀郚区間が䞀郚芏制ずなり、高速道路を走る事ができたした。奥にはベむブリッゞも芋えおずおも気持ちがよかったです。 たずめ 仕事を䞀生懞呜するのは勿論ですが、職堎のメンバヌず他の事にも挑戊できる環境であるこずは玠晎らしいず思いたす。 最初は運動䞍足解消やコミュニケヌションの堎ずしお、ランニング郚を掻甚しおいたしたが、少しず぀小さな達成を積み重ね、い぀のたにかフルマラ゜ンを走れるくらいの走力が぀いおいたした。 䜕事にも圓おはたるず思いたすが、 THERE IS NO FINISH LINE. そこにゎヌルはありたせん倧䌚埌の打ち䞊げを楜しみ぀぀、継続した挑戊をしおいきたいず思いたす。 最埌たで読んでいただきありがずうございたした 明日は、Frontendグルヌプの加藀さんずData Strategyチヌムの霋藀さんですお楜しみに。
この蚘事はBASE Advent Calendar 2019 13日目の蚘事です。 devblog.thebase.in こんにちは。UIデザむナヌの野村です。 2019幎4月にBASEに入瀟し、䞻にショップオヌナヌさんが䜿う管理画面のUIデザむンに携わっおいたす。 デザむンワヌクの䞋敷きになるようなトラむをいく぀か行っおおりたしお、今回はそのあたりの話をさせおいただきたいず思いたす。 [これたでに実斜したトラむ] 2床のデザむン思考ワヌクショップ 非デザむナヌ向けのデザむンツヌル講習䌚 サヌビスデザむンの勉匷䌚で組織デザむンに぀いお孊ぶ瀟倖 開発プロゞェクト内での実践途䞭 なぜそんなトラむをしおるのか、ずいう話 受蚗デザむンの䞖界からむンハりスぞ移行しお 私はBASE入瀟前はデザむン制䜜䌚瀟に勀めたりフリヌランスで働いたりしおいたのですが、携わった業務はほが党お受蚗案件でした。 業務委蚗の圢で事業䌚瀟内で勀めたこずはあったものの、むンハりスデザむナヌずしおの経隓はずおも浅い状態で入瀟しお参りたした。 受蚗での仕事ず、事業䌚瀟内むンハりスでのデザむンワヌクには色々ず違いがありたす。 受蚗デザむナヌをしおいるず、基本的には「お客さん䟝頌者が提瀺する情報をベヌスにモノを䜜る」ずいう圢をずりたす。 実際のずころ、プロゞェクト開始段階でお客さんから十分な情報を提瀺されるこずは皀でしお、远加で色々ず調査・怜蚎を行うこずずなりたす。 もらった情報を粟査した䞊で、䞍足を補うためにお客さんにヒダリングをしたり、内倖ぞの調査を提案し蚈画したり、技術や呚蟺事情に぀いおの勉匷䌚や講習䌚を行ったり... などなど、良いアりトプットに到達するための斜策を打っおいくわけですが、ずはいえ基本的には情報収拟ず取りたずめはお客さん偎で担圓するこずが䞻で、受蚗デザむナヌずしおの自分は「 お客さんの情報収拟掻動をサポヌトし぀぀、制䜜に泚力する 」ずいうのが基本スタンスずなりたす。 そうなるず、情報の深いずころたではむマむチ理解が浅いたた玍期優先で業務を進行するこずになったりするのですが、それは「 仕方ないこず 」ず飲み蟌んできたした。 むンハりスデザむナヌずしお仕事をしおいるず、自ら瀟内で動いお事業やナヌザの深い情報を掻き集めながらプロダクトを䜜っおいくこずができたす。 マネヌゞャヌが取りたずめおくれた情報のみから業務を進めおいくこずも可胜ではありたすが、瀟内の各郚眲で持っおいる知芋や䜓隓を掻き集めお自ら消化・敎理しお業務に反映するこずで、アりトプットの質は目に芋えお向䞊したす。倧倉ではありたすが、むンハりスデザむナヌずしお働くにあたっおの面癜いポむントの1぀です。 効率よく、か぀深く情報を共有するには 自ら組織内のナレッゞ掻き集めようずした時、新参者は 誰がどんな知識をもっおいるかわからない ずいう事態に陥りがちです。 それらはドキュメントずしお蓄積されおたりしたすが、党おが明文化されおいるわけではありたせん。 たた、ドキュメントには文章や図の圢で知識を溜めおいくこずはできたすが、そこに各人の想いや䜓隓ひっくるめお ナラティブ 、ず呌ぶこずにしたすたで蟌めるのは難しいです。文章曞くの苊手な人も居たすし。 ナレッゞは有圢文章・図化しお蓄積可胜だけど、ナラティブは無圢のたた流動し続けるこずしかできない、ずでも申したしょうか。 そしお、ナラティブのようなバックグラりンドを螏たえおないず、せっかくの知識もその真の意味、深い意味が抜け萜ちた䞊っ面だけのものになっおしたうこずがありたす。非垞に勿䜓ない事態ですね。 そんな想いから、郚眲の垣根を超えお各人のナラティブをそれずなく共有できるような、そんな堎を組織内に䜜れないものか、ず考えたした。 プラむベヌトなこずを掘り䞋げようずいうものでなく、仕事やプロダクトに぀いおのナラティブを共有するのが䞻なので、 プロダクトの䌁画をテヌマにしたワヌクショップ をするのが良いかな、ずいう思いに至り、䌁画ず実斜をしたした。他、非デザむナヌ向けにデザむンツヌルの講習䌚をしたり、デザむン組織醞成に関する瀟倖の勉匷䌚に出たり、ずいったトラむをしたした。 2床のワヌクショップ 「デザむン思考を䜓隓するワヌクショップ」ずいう名目で、2時間皋床のショヌトワヌクショップを瀟内で2床実斜したした。2回ずも、参加人数は10名前埌の、小芏暡なものです。 第1回ワヌクショップ たずはやっおみよう、ずいうこずで7月にパむロット版的な圢で実斜したした。 内容ずしおは、私が過去に参加した1DAYワヌクショップを䞋敷きに、2時間皋床の尺で収たるよう圧瞮したものです。 いくらかバタ぀いたものの、10名匷の参加者には楜しんでいただけたようで、パむロット版ずしおは成功を玍めたず思っおいたす。 その時の様子は こちら 。 第2回ワヌクショップ 第2回のワヌクショップは、流れずしおは抂ね第1回ず同じなのですが、第1回での反省点や、いただいたフィヌドバックなどを螏たえ、か぀段取りのバタ぀いた箇所を敎理するなど、いく぀かのアレンゞをしたした。 その時の様子は以䞋の通り↓ ワヌクショップ振り返り 2回のワヌクショップの埌には、参加者からはそれなりにポゞティブなフィヌドバックをいただけたした。「楜しかった」「普段話せない人ず話せおよかった」「良い頭の運動になった」など 90〜120分皋床のワヌクショップをスムヌズに進めるための段取りも䜜れたず思っおいたす。 自身のファシリテヌション力向䞊にも぀ながり、良いトラむができたした。 他、ナラティブ共有に぀いおのトラむ 「他郚眲メンバヌのナラティブを埗る」ずいう䞻旚からは少々逞れるのですが、以䞋のようなトラむを行いたした。 非デザむナヌ向けの、デザむンツヌル講習䌚 これは私が䌁画したわけではなく、デザむンチヌムメンバヌの小山が䞻導したものなのですが、デザむナヌ以倖ぞのデザむンツヌル講習を行いたした。業務の効率化を意図しおの斜策ですが、デザむナヌから他郚眲メンバヌぞの良いナレッゞ共有・ナラティブデザむナヌの䜜業姿勢ずか共有になったず考えおいたす。 組織ナラティブに関しお勉匷䌚参加瀟倖 瀟倖で行われたサヌビスデザむンに関する勉匷䌚にお、組織におけるナラティブ構築に関しお敎理・発衚したりもしたした。この勉匷䌚の圱響で、ナラティブずいう単語を倚甚するようになった私です。口には出しおないけど。 開発プロゞェクトの䞭にナラティブ収集のフェヌズを組み蟌んでみるトラむ ここたででご玹介したのは開発プロゞェクトの倖偎で実斜しおきた内容なのですが、珟圚は「 プロトタむプ怜蚌のための瀟内ヒダリング 」ずいう名目で、プロゞェクト初期段階で他郚眲から意芋を収集するフェヌズを䜜るこずにトラむしおいたす。 単なる意芋収集に留たらず、ナラティブ共有の䞀助になっおいる、ず感じおいたす。 この件に぀いおはただプロゞェクト進行䞭に぀き詳しくは曞けないのですが、いずれ敎理しおたた蚘事化したいず思いたす。 敎理途䞭のものをチラ芋せするず以䞋のような具合です。 トラむのたずめず今埌 業務の傍でいく぀か斜策をトラむしおみたした。 それぞれ倚くの知芋を埗られたしたが、䞀方で、拡倧しおいく組織の䞭で個々のメンバヌの想いや䜓隓を収集するこずの難しさを感じおいたす。デザむンワヌクに本圓に圹立っおいるのかは、正盎ただよくわかりたせん。 最埌に挙げたデザむンプロセスのトラむに぀いおは、進行䞭の開発プロゞェクトに取り蟌み぀぀詊しおるため、デザむンワヌクに察しおそれなりの効果があるこずを実感できおいたす。たずはこのプロセスを敎理しお瀟内で共有し、トラむを重ねおいきたい次第です。 ワヌクショップに぀いおも参加者からはポゞティブな感想をいただいおいたすので、こちらも続けおいきたい想いでいたす。 ただ、これたでに実斜したワヌクショップよりも、もう少し業務ずの繋がりをむメヌゞしやすいような圢のワヌクショップを行いたいず思っおいたす。 具䜓的に䜕かモノプロトタむプを䜜っお怜蚌するような圢をずれたら良いのではないかず思い、珟圚はプロトタむピングにフォヌカスしたワヌクショップに぀いお孊習・研究しおいるずころです。 なんやかんやず、 チヌムを超えお存圚朜圚しおいる集合知をデザむンワヌクに繋げるこずを意図したトラむをしおいたす 、ずいうお話でした。最埌たでお読みいただきありがずうございたす。 明日はPlatform Devの金城さんずService Devの小林さんです
はじめに この蚘事はBASE Advent Calendar 2019 13日目の蚘事です devblog.thebase.in こんにちは。BASE株匏䌚瀟 Product Design Divison でデザむンリヌドをしおいる北村 ( @naomi_kun )です。 ふだんはオヌナヌさた向けの管理画面やショッピングアプリの改善、新機胜の開発たでいろんな郚分でUI蚭蚈を担圓しおいたす。盎近では、既存機胜のフルリニュヌアルプロゞェクトを進めおおり、おんおこ舞いになりながらもずおも楜しみながら開発しおいたす。 実は、9月にデザむンマヌケットのテヌマ䜜者さん向けの機胜が少しアップデヌトされたした。デザむンマヌケットでテヌマを䜜成しようず思っおいるデザむナヌさんは、ぜひ BASE Developers からデザむナヌ申請しおみおください。 https://developers.thebase.in/ 今日は、BASEに入瀟しお2幎半を迎えたので、BASEの考える「Move Fast」をデザむナヌ芖点で振り返りながら、いろいろ曞いおみようず思いたす。 BASEのMove Fastずいう文化 入瀟圓初からBASEには「Move Fast」ずいう文化が浞透しおおり、今珟圚のプロダクトの開発にもその考え方が匷く根付いおいたす。自分が携わっおきたプロゞェクトも、たずリリヌスしおみよう、ファヌストリリヌスを恐れるな、ずいう考えが匷く、チャレンゞングな䌚瀟の雰囲気を感じずったのを芚えおいたす。 前Qのはじめにも、あらためお「Move Fastを䜓珟したプロダクト䜜りを正ずする」ずいうこずが党瀟的に語られ、各プロゞェクトの開発珟堎では、「DAY1にこだわるために䜕をすべきか」ずいう議論が飛び亀っおいたす。 プロゞェクトが煮詰たるあたり、圓初の芁件から膚れ䞊がったり、リリヌスが遅れがちになるずいったプロゞェクトを経隓しおいたこずもあるので、このスピヌド感ず意思決定の方法はずおも「匷い」なず思いたした。匷い、ずいう衚珟が適切かはわからないんですが、匷さを持っおいる䌚瀟だなず感じおたす。 日々感じおいるこずですが、「BASE」のショップオヌナヌさんは本圓に成長速床が早く、気づいたらずおもおおきなブランドになっおいる、ずいうこずも倚いです。 そんなオヌナヌさんたちの成長速床に぀いおいくための方法ずしお、「DAY1にこだわる」ずいう意思決定が蚀語化されたこずは、私個人ずしおは、腑に萜ちた気がしたす。 入瀟圓初を振り返りながら圱響されたこず 入瀟した圓初、私はアプリの開発チヌムにアサむンされたしたが、振り返っおみるず珟圚のBASEのMove Fastを䜓珟するような珟堎だったなあず思いたす。 その頃のチヌムにはディレクタヌがいなかったため、開発メンバヌ党員がオヌナヌシップをもっお取り組んでおり、仕様決めやUI蚭蚈を䞀緒に進められたこず、䞍具合時の察応もリアルタむムで議論しおいたこずなど、いろんなずころに銖を぀っこめる環境のおかげもあっお、結果的にサヌビスぞの理解がずおも深たったず思っおいたす。 たた、珟圚のVP of Product・CTO・テックリヌドなど、珟圚のBASEの開発の根幹を担っおいるメンバヌが集たっおいたため、圌らの決定力ずスピヌド感にも倚くの圱響を受けたように思いたす。 このスピヌド感を保぀には、粗が出るこずもあるし、完璧なデザむンや実装にはならなかった郚分もあるのかもしれないですが、そのずきにくだした意思決定は圧倒的に正しくおあずから状況が倉わっおそれが最適ではなくなるこずももちろんありたすが、珟圚のBASEはそれを積み重ねおきた結果なんだなず思っおいたす。 あずは、「Be Hopeful」な文化もあり、気負わず自然にお互いを埌抌しできるような空気があったのも、Move Fastを進められる倧きな芁因だず思いたした。 Move Fastは難しい 䞊に曞いたようなスピヌド感のある開発は、入瀟圓初の芏暡感だからこそ実珟できおいたもので、今はそれが以前に比べお難しくなっおいるのも事実です。あずは単玔にプロゞェクトで開発する圱響範囲の粒床が倧きく、機胜改修や新機胜を考えるずきにはやはり慎重になっおしたう堎面が増えたした。ショップの数も増え、瀟内の開発メンバヌも増え、考慮すべき郚分も増えた今では、いろいろなパタヌンを考慮するあたり、仕様が過剰になり、時間もかかっおしたうのは、この芏暡だずある皋床仕方ないず思っおいたす。 それを削ぎ萜ずすための刀断軞ずしお、「DAY1にこだわる」ずいうスロヌガンがあるのですが、個人によっお考え方や持っおいる背景が違ったりするので、軞ずしお機胜させるのもなかなか難しいなあず。 BASEのデザむナヌずしお「Day1にこだわる」ずいう意思決定をするためには、仕様も、ブランディングも、垂堎での立ち䜍眮も含め、「BASE」ぞの理解が深くないず行えない、ずいう、圓たり前のずころに立ち返っおいたす。 これは自省ずしお曞くのですが、い぀かのMTGで、VP of Productの神宮叞 が「デザむナヌが䞍安になるず、プロゞェクトマネヌゞャヌも、開発メンバヌもみんな䞍安になる」ずいうこずを話しおいたした。 今でもその蚀葉が残っおいお、デザむナヌが慎重に・䞍安になっおしたうのには色々な芁因があるず思うのですが、私自身がチャレンゞングな環境のBASEに助けられおきた郚分があるので、自分のいるプロゞェクトでは、なるべく「すごい」ずか「めっちゃいい」ずか「はやくリリヌスしたい」っおいうアクションをするように意識するようになりたした。 Be HopefulになれればMove Fastも぀いおくる、ずいう空気を、デザむナヌが持おるず良いよなあず思っおいたす。 Move Fastずは、未来のオヌナヌズに遞ばれるこず 3Qのはじめに、デザむンチヌムのミッションを皆で考える時間がありたした。 「BASE」の䟡倀をMove Fastにサヌビスに具珟化し、未来のオヌナヌズに遞ばれ続ける 「はじめに」でも曞きたしたが、「BASE」のショップオヌナヌさんの成長速床に远い越されないよう、「BASE」ももっず成長しおいく必芁があり、Move Fastずは、未来のオヌナヌズに遞ばれるための最速手段だず感じおいたす。 おわりに 2幎半を振り返りながらいろいろ曞きたしたが、この先の未来にも、もっず新しい構想や、やりたいこずなどが山積みで、その党おが未来のオヌナヌズのみなさんに遞ばれるための決断なんだずいう郚分は揺るぎないので、ワクワクしおいたす。 いた開発䞭の機胜もはやくリリヌスしたいDAY1ずいう気持ちのほうが倧きいです。 おわり 明日は基盀グルヌプの金城さんず 、Owners Marketingグルヌプの誠さんです
Product Management Groupの坂東 @7auto です。 この蚘事は BASE Advent Calendar 2019 の12日目の蚘事になりたす。 devblog.thebase.in 私はアヌトが奜きでしょっちゅうギャラリヌや矎術通を巡っおいたす。 䌚瀟のお昌䌑みや、フレックスなのでたたに17時頃など早めに退勀しおいそいそずギャラリヌを巡っおいるのですが、昌䌑みにぶらりず行っおみるずずおも良い気分転換になりたすよ みなさんは行きたすかギャラリヌ。 最近ではアヌト思考の曞籍が倚数発売されたり矎術通が60䞇人を超える動員をしおいたりず、アヌトに関する情報を耳にするこずも倚くなっおいるように感じたす。 アヌトが話題に䞊がりやすくなったこずはずおも嬉しいこずではあるのですが、 矎術通などに展瀺されるアヌティストはトップオブトップな人たちです。 その裏には今たさに制䜜掻動を行い切磋琢磚しおいるアヌティストやアヌティストを支えるギャラリヌがありたす。 倧倉ありがたいこずに、Eコマヌスプラットフォヌム「BASE」はたくさんのそうしたギャラリヌやアヌティストの方々にもご利甚いただいおいたす。 ただ、そんなギャラリヌやアヌティストはただただ䞀般によく知られる存圚ではないのかなず感じおいたす。 そこでよりよく知っおもらうため、本皿ではその魅力をご玹介したいず思いたす。 ギャラリヌっおなに そもそもギャラリヌずはなんでしょう。 ざっくりず蚀えばアヌティストの䜜品などを展瀺しおる堎所になりたす ※ギャラリヌにもレンタルギャラリヌずコマヌシャルギャラリヌがありたすが、ここでは埌者を指したす。 䜜品の展瀺ず蚀われお思い浮かぶのは矎術通ではないでしょうか 123億円の䜜品が展瀺されおいた展瀺が六本朚ヒルズで開催されお話題になっおいたしたね。 そんな矎術通ずギャラリヌの倧きな違いは収益構造です。 矎術通は入堎料を取るのに察し、ギャラリヌは基本入堎料を取りたせん。 ではどこで収益を埗るのかず蚀うず䜜品の売買によっお収益を埗おいたす。 なのでそれぞれで目的が倧きく違っおいたす。 ・矎術通入堎しおもらう ・ギャラリヌ䜜品を販売する 目的は䜜品の販売ですがギャラリヌには䜜家を露出させお䟡倀を育おるずいう偎面もあるず思っおいるので、個人的には昌䌑みにぶらりず芋に行き䟡倀を感じるだけでも良いのではないかず思っおいたす。 そんな䜜家の䟡倀を芋出し育おおいく関係性は、起業家ず投資家の関係に少し䌌おいるのかなず感じたりしたす。 最近ちょうど「 ほが日刊むトむ新聞 」さんが䜜家ずギャラリヌの関係性に぀いおの蚘事を曞かれおいたす。 芋たこずや聞いたこずのある䜜家の名前も出おいるかもしれたせん。 倩才もしくは狂人ず、その䌎走者 ギャラリヌやアヌトの䞖界が少し身近になったでしょうか 䜕が楜しいの 私は若手䜜家のいわゆる珟代アヌトにカテゎラむズされる䜜品を奜んで芋に行きたす。 難解だず蚀われがちな珟代アヌトですが、ずにかく衚珟に察する倚皮倚様なアプロヌチや切り口おもしろいです。 小林健倪 さんや 岡田舜 さんら奜きな䜜家を䞊げ始めるずきりがないのですが、いろいろな目線やアプロヌチで䜜られた衚珟の䟡倀ずは䜕なのか、情報の䌝達ずは䜕なのかみたいなこずを考える良いきっかけになっおいたす。 難しく考えすぎず、䜕か刺激を埗られるずいいな、くらいの気持ちで足を運んでみおはいかがでしょうか ギャラリヌっおどこにあるの そんな楜しいギャラリヌですが、どこにであるのでしょう 個人的に数えたこずがあるのですが、東京郜内で500件以䞊、オフィスのある六本朚にも50件匱くらいありたした。 ビルの地䞋など目立たないずころにあったりするので、Googleマップで「ギャラリヌ」などのワヌドで調べおみるず意倖ず身近なずころに芋぀かるかもしれたせん。 Google マップで「ギャラリヌ」で怜玢しおみる ギャラリヌの営業日は火曜~土曜で19時頃には閉たるこずが倚い印象です。 䜜品っおいくらぐらいなの 売買が目的だずすれば気になるのは倀段です。 もちろん、アヌティストの知名床や䜜品のサむズなどによっお倀段も様々ですが、私がこれたで䜜品を芋おきた感芚でいうずPCやスマホず同じくらいずいう印象です。 䜜品は流行り廃りのあるものではないのでワクワクが持続するように感じたす。個人の印象です。 そう考えるず案倖手に入れおみるのもいいかも、ず思えるかもしれたせん たた今はアヌト売買やレンタル、分散保有などのサヌビスも生たれおきおいお、䜜品の所有に察する障壁は䜎くなっおるように感じたす。 私も AND ART ずいうサヌビスを通しお↓のKAWSの䜜品1点の0.23%を所有しおみたした。 KAWSを(0.23%だけ)所有しおいるず蚀えるこずは、ずおもプラむスレスな䜓隓です。 賌入方法や所有方法も倚皮倚様になっおきおいるので、自分にあったスタむルで䞀床賌入しおみおはいかがでしょうか 䜕か新しい発芋があるかもしれたせん 最埌に ギャラリヌや䜜家に少し興味を持っおいただけたしたでしょうか BASEのミッション には䞋蚘のような蚘茉がありたす。 ひずりひずりに眠る、想いが、感性が、才胜が。 䞖界䞭の、必芁な人に届くように。 そこから生たれる、䜜品に、アむデアに、掻動に。 正圓な察䟡を、受け取れるように。 今回ご玹介したような切磋琢磚しお䜜品を䞖に送り出しおいる䜜家やギャラリヌの方々をサポヌトしおいけるよう、「BASE」ずいうサヌビスを磚き続けおいきたす。 明日はProduct Design Divison でデザむンリヌドの北村さんずUIデザむナヌの野村さんです