ピクシブ株式会社（本社：東京都渋谷区、代表取締役：國枝信吾、以下ピクシブ）は、3Dアバターモデルを用いたWebアプリケーションの開発をより簡単にするWeb開発者向けライブラリ「pixiv three-vrm」を、2019年9月12日（木）よりオープンソースとして公開します。 pixiv three-vrm: https://github.com/pixiv/three-vrm/ 「pixiv three-vrm」は、人型3Dアバターモデルのデータを扱うためのフォーマットである「VRM」を読み込み、Webブラウザに表示するためのライブラリです。 three-vrmが使用されている「VRoid Hub」(https://hub.vroid.com/) pixiv three-vrmは、3Dアバターモデルを扱うための専門的な技術知識を持たないWeb開発者が、VRMで記述されたモデルデータをより簡

渡辺です。 そろそろ冬籠もりの準備をする季節です。 Developers.IO Cafe のインフラはLambdaを軸としたサーバレスアーキテクチャです。 Lambdaはサーバレスの中核として非常に使い勝手の良いサービスですが、制限と上手く向き合うことも必要です。 特にコールドスタートはパフォーマンスに直結する大きな課題です。 本エントリーでは、カフェのバックエンドLambdaで実施したパフォーマンスチューニングについて解説します。 コールドスタートとLambda Lambdaを扱う以上、 コールドスタート は避けられない問題です。 一般的に、サーバレスアーキテクチャでは、サービスが利用されていない時間帯は、コンピュータリソースを使わないように設計されています。 言い換えると、サービスが最初に利用される場合、サービスをスケールする場合、サービスがアップデートされた場合などに、 サービスが都

まだ現職辞めへんで！！ということを最初に宣言しておきつつ、どういう時に仕事/会社を辞めたくなるかを考えてみたい。 朝眠いとかだるいとかそもそも働きたくないとか5000兆円欲しいとかそういうやつではなく、基本的にはやる気がある状況でもふと環境をリセットしたくなるというか、ああなんだかめんどくさいなーと感じるみたいな、比較的ライトな感情の変化の話である。人によっては「にゃーん」とツイートしたり、シャワーを浴びながら「つらい…」とつぶやいてしまったりするアレだ。 なんでこんなことを考えてるかというと、最近TL上で「この人が辞めるのマジか」とか「この人が入社したのかすげえ」と感じることが何度かあり、全然そんな素振りを感じなかったのにやはり一期一会なのだろうかと思ったことがきっかけである。仕事を辞めるのにポジティブな理由だけということはまずないという持論がある。 自分にも感情の波みたいなものがあって

<script type="importmap"> { "imports": { "three": "https://cdn.jsdelivr.net/npm/three@0.168.0/build/three.module.js", "three/addons/": "https://cdn.jsdelivr.net/npm/three@0.168.0/examples/jsm/", "@pixiv/three-vrm": "https://cdn.jsdelivr.net/npm/@pixiv/three-vrm@3/lib/three-vrm.module.min.js" } } </script> <script type="module"> import * as THREE from 'three'; import { GLTFLoader } from 'three/addo

と書いて webpack でビルドすると、生成される bundle ファイルのサイズが非常に大きくなってしまいます。これは、moment.js が持つすべてのロケールファイルが bundle ファイルに含まれてしまうためです。ファイルサイズにシビアなフロントエンドではかなり大きな問題です。 (上図は source-map-explorer を使って生成しました） 解決策 webpack の IgnorePlugin か ContextReplacementPlugin を使えば、この問題を回避することが出来ます。 IgnorePlugin を使う場合 「デフォルトの en 以外にロケールファイルは必要ない」という場合は、IgnorePlugin が使えます。 const webpack = require('webpack'); module.exports = { //... plugi

この記事について 先日 DDD-Community-Jp の DDD Talk MeetUp #2 というイベントでトーク枠にて参加させて頂き Flyweight DDD というアーキテクチャスタイルの提案とする一つのスライドを発表させて頂きました。 https://speakerdeck.com/hirodragon112/ddddao-ru-nita-miqie-renaifang-hezeng-ru-2ceng-plus-cqs-akitekutiya-flyweight-ddd ただ、本稿はこのスライドの「内容」とは全く関係ありません。 本稿で取り上げたいのはこのタイトルに登場している CQSという単語についてです。 このスライドをきっかけにCQSとCQRSの違いについて自分なりに思考の整理を記載したいと思います。 CQS ? CQRS ? きっかけは twitter にて @j5

.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads

2014年にAWS Lambdaが登場し、Functionを単位としてアプリケーションを実行する基盤をFunction as a Service(以下、FaaS)と呼ぶようになった。 そして、同時にサーバーレスアーキテクチャ、またはサーバーレスコンピューティングと呼ばれる新しいコンセプトが普及するに至った。 当初、そのコンセプトが一体何を示すかが定まっていなかったために議論が巻き起こり、今現在では一定の理解に着地し、議論が落ち着いているようにみえる。 しかし、サーバーレスという名付けが悪いということで議論が着地したようにみえていることにわずかに疑問を覚えたために、2019年の今、これらの流れを振り返ってみて、サーバーレスアーキテクチャとは何かを改めて考えてみる。 サーバーレスとの個人的関わり サーバーレスアーキテクチャという名を僕がはじめて耳にしたのはAWS Lambdaが登場した2015

【追記：2019/9/17】 記事で誤りがあった部分を修正いたしました。 またサンプルも正しいものに修正しておりますので、是非ご確認ください。 【追記:2019/9/10】 コメントでもご指摘を頂いておりますが、一部誤った内容が含まれております。 すぐに修正に取り掛かりますが、内容の修正まで今しばらくお待ち頂けますようお願いいたします。🙇‍♂️ また、今回多くの方に誤った内容をお伝えしてしまったこと、深くお詫び致します。 （多くのいいねを頂いており、ストックに登録して頂いている方もいらっしゃると思いますので、非公開にせず修正又は内容の削除で対応致します。） 先日インターンでソシャゲ用のAPIを作った時に、サーバーサイド未経験ながらGolang＆クリーンアーキテクチャ（的な）のAPIを構築しました。 特にインターンで用意されていた内容というわけではなく、個人の課題としてクリーンアーキテクチ

サーモンランでバイト仲間と一緒にサバイバルしている方も居るでしょう。 レギュラーマッチで気楽にナワバリバトルに興じている方もいるでしょう。 しかし、スプラトゥーンの醍醐味はなんといってもガチマッチ！ 1の頃から変わらず、とにかく起動してはガチマッチにもぐり、ウデマエの上下に心も動揺する。 どうしようもないまま負けてしまい味方運ゲーじゃねえか！とキレる。 何もしていないのに軽々と勝ってしまう。 自分の活躍で逆転出来ることもある。 特定の強い敵にボコボコにされたりもする。 そんな様々な試合展開に気を揉み、それが病みつきになるのがガチマッチです。 そんなガチマで遊ばれている方がプレイヤーでは圧倒的多数だと思います。(身内でチームを組んで、他のチームと戦う対抗戦もメジャーな遊び方のひとつですが、彼らも普段はガチマッチ勢です) 私、前作ではウデマエカンストにわずか届かず、今作でもより高いガチパワーを