Firebaseで完結するリッチなWebアプリ構築の勘所 - Qiita
先日、Togetter社長の@yositosiさんとひょんなことからお友達になり「なんかFirebase使って面白いことやろうよ」という話になったので一緒に面白いことをやりました。 この記事は、 Firebaseを使うと何ができるのか Nuxt.js/Vue.jsとFirebaseの勘所 Firestoreでの複雑なクエリ処理にどう対応するか などのトピックを中心に紹介していければと思っています。 なんとかPay Togetterの社長の@yositosiさんからFirebaseを使ったアプリ構築の話を頂きお手伝いさせていただいた、エイプリルフールの企画の「なんとかPay」というサービス。誰でも自由にPayを発行できる、昨今のPay蔓延している社会に物申しているようなそうでもないようなそんなサービス。 今回は技術周りで色々とお手伝いをさせていただきました！ 自分だけのPayが作れる リアル
「それコンテナにする意味あんの？」迷える子羊に捧げるコンテナ環境徹底比較 #cmdevio2019 | DevelopersIO
みなさんコンテナを使うことの意味を自信もって答えられるでしょうか？ ここ1年ほどコンテナ関連の仕事をメインでやっているハマコーですが、いろんなお客様からこういったお声をいただくことが多くありました。 「それはコンテナ化する意味があるの？」 「こんなコンテナ運用は危ない？」 「ECSの設定とか実際めんどい。docker runじゃだめ？」 「EKSって使えんの？」 そういう声を聴く中で、自分なりの答えを模索していたわけですが、岡山での弊社イベントAWS最新技術の祭典Developers.IO 2019 at 岡山城へ登壇するにあたり、そのあたりのもやもやを自分なりに昇華したのが、本日の内容です。 「このアプリをコンテナ化する意味があるのか、わからない」 「コンテナ化することで余計めんどくさくなった」 「AWSのコンテナサービスの何を使ったら良いのかわからない」 という悩みを抱えている方には、
Kubernetesでステートフルなゲームサーバを動かした思い出
とあるスマートフォン向けMMORPGのプロジェクトで、アプリケーションサーバをほぼすべてGKE(Google Kubernetes Engine)に乗っけて動かしていました。 このゲームは、モバイル向けながら、複数プレイヤ間でそこそこリアルタイム性の高い同時プレイができるものでした。同じフィールドを誰かが歩けば、自分が見ている画面でもほぼ同時にそいつが歩いて横切っていく、同じ敵と皆で一緒に戦えば、誰かが繰り出した攻撃が参加者全員の画面に即同期される、もちろんチャットもできる、そんな具合です。今ではさほど珍しくないのかもしれませんが、PCのオンラインゲームのような機能を搭載した、リアルタイム性の高いモバイルゲームでした。 さて、こうなってくると、オーソドックスなWebサーバのような、HTTP/1でリクエスト/リプライを捌く、というサーバだけでは要件を満たすことができません。 複数プレイヤ間で
役割駆動設計で巨大クラスを爆殺する - Qiita
大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、ドメイン駆動設計を基本思想とする「役割駆動設計」を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 小さくシンプルな構造に落とし込み、堅牢で変更容易性の高い設計へ昇華させる。 例１：筆者をモデリング 分かりやすくなるよう、まず私を例にモデリングしてみます。私は以下のような特徴があります。 IT企業の従業員 家族がいる(妻, 子供) 趣味でゲーム制作している ダメな設計 何も考えずに人クラスとして設計すると、よく以下のような構造になりがちです。 従業員として仕事をする、父親として家族サービスする、趣味としてゲーム制作する、それぞれのメソッドが備わってい
「インプットもアウトプットも多いのにつまらない人」と「インプットが増えるほど面白くなっていく人」の違い｜ふろむだ@分裂勘違い君劇場
やたらとインプットとアウトプットをたくさんやっているのに、なんだか、言っていることが表面的で、ちっとも面白くない人がいる。 そういう人はたいてい、「アウトプット」はやってるけど「活用」を疎かにしている。 たとえば、「良い文章の書き方」の本を読んだら、そういう人は、単に「良い記事の書き方」のまとめ記事を書く。そして、それを「アウトプット」と言っている。 しかし、これでは、知識は血肉にならない。 血肉になっていない知識は、畳の上で練習した水泳のようなもので、いくらやっても泳げるようにはならない。 インプットした知識を血肉にするには、インプットした「良い文章の書き方」のテクニックを使って、自分のオリジナルの文章を書く必要がある。 つまり、インプットした知識をそのまま出力するだけではダメで、その知識を使って、具体的な何かをしないと、血肉にならないのだ。 アウトプット ＜＜＜｜越えられない壁｜＜＜＜
僅か100万円で開発した「Amazon Go」型店舗 その意外な仕組み
欲しい商品を手に取り、店を出れば支払いが終了──。米アマゾン・ドット・コムがレジなしコンビニ「Amazon Go」を一般向けに開業して以降、その驚異の買い物体験は大きな話題となり、さまざまな企業が 「ウオークスルー（通り抜けるだけで決済が完了する）」を実用化しようと開発競争を繰り広げている。しかし、手に取った商品を正確に認識して決済まで持っていく精度の問題や、膨大なコストなどの面から実際の店舗に導入されているケースは非常に少ない。 そんななか、「完全キャッシュレス」「レジなし」「ウオークスルー」を実現したAmazon Go型カフェが2019年2月、東京・秋葉原にオープンした。システム開発のクラスメソッド（東京・千代田）が運営する「Developers.IO CAFE」だ。
エンジニアの業績評価をやめるべき理由 - 室長のひとりごち
身も蓋もない言い方をすれば、エンジニアの評価なんて必要ない。というか、できない。 できない理由は幾つかある。エンジニアに求められるスキルは広く深さがある。その人を形作る基礎スキルはもちろん、エンジニアが身につけている技術を適用してアウトプットする技術スキルの両方が評価対象となる。 評価対象は、所属する組織の事業により違いがある。事業領域が広ければ、事業として必要とする技術領域は広がる一方、そうした技術の幅は一人のエンジニアでは賄えないから複数のエンジニアでカバレッジをすることになる。結果、同じ事業を一翼を担うエンジニアの担当する技術は違うが、評価は同じ軸で行われる。 そこで持ち出すのが事業への貢献、役割になる。ビジネスでリーダーシップを発揮したか、などを問うようになる。 担当する業務もSI（新規開発）とSO（維持管理）で同等の評価をしない。SIでは新しいビジネス、サービス開発により事業貢献
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
