こんにちは、CX事業本部の若槻です。 Amazon Chimeは、オンラインミーティングやビデオ会議を行うためのAWSのサービスですが、 AWSが公式提供するAmazon Chime SDKを使うことで「Amazon Chimeの通信基盤を利用した音声、ビデオ、画面共有などの機能」を自社アプリケーションに組み込むことも可能となります。 Amazon Chime SDK このAmazon Chime SDKは、Slack社のSlackコールの機能にも採用されています。 Slack などのお客様が、リアルタイムコミュニケーションのために Amazon Chime SDKを選択しています | Amazon Web Services ブログ 今回は、Amazon Chime SDKの基本的な動作の確認として、Amazon Chime SDKをローカル環境上のReactアプリに組み込んでビデオ会議を

GraphQL/REST における Authorization, Authentication について。 https://www.prisma.io/tutorials/graphql-rest-authentication-authorization-basics-ct20/ REST API Authentication (認証) Authentication には JWT を利用する。JWT を生成するコードは、以下のようになる。読み込み権限を与えることを示す "read-post" を claim として保持させ、暗号化には HS256 を利用し、この暗号化時のシークレットキーとして "secret" という文字列を利用する。 code:js import * as jwt from "jsonwebtoken"; const token = jwt.sign({ claims:

Zennという技術情報共有サービスを作りました。有益な知見をシェアした開発者が、その見返りを得られるようなサービスにしたいと思います。気合いを入れつつも、時間をたっぷりかけて地道に育てていきます。 このページでは、Zennを支えている技術やサービスを紹介します。 フロントエンド Next.js フロントエンドにはNext.js（React）を使っています。開発当初はNuxt.jsを使っていたのですが、TypeScriptとの相性を考えてNext.jsへ移行しました。 技術情報共有サービスなので、主要な流入元はいずれ検索エンジンに落ち着くと予想しています。そのため、検索エンジンにインデックスしてもらいたいページはサーバーサイドレンダリング（SSR）しています。 動的コンテンツもキャッシュ Next.js 9.4からIncremental Static Regenerationという最高の機能

class Notification < ActiveRecord::Base belongs_to :notifiable, polymorphic: true end class Message < ActiveRecord::Base has_one :notification, as: :notifiable end class Like < ActiveRecord::Base has_one :notification, as: :notifiable end 一行で色んなクラスに対する関連が指定できて便利感がある。 だからって、これを安易に使う前にちゃんと考えよう。 ポリモーフィック関連は単に関連の定義を省力化するためのものじゃない。 ポリモーフィックという名前が示す様に、これは多態性を持ったものに対する関連を定義する事であって、インターフェースに対する関連の定義だということ

自分が複数のシステムの開発を経験して得た確信として、「認証と認可と課金とコアドメインの分離がめちゃくちゃ重要である」というものがあるので、コレを整理してアウトプットしていく 分離するモチベーションとは Microservice文脈でいうと、デプロイ独立性だったり、リソースの最適配分だったり、障害の局所化だったり、開発組織とのマッピングだったりがメリットとして語られることが多い。 だが、ここで取り上げたいのは戦術的DDD的観点でのコンテキスト分離の有用性である。 ※ちなみにコンテキスト分離のみであればモジュラモノリスだけで実現可能。 戦術的DDD的観点での関心事の分離によるメリットとは コンテキストが分離されていることによって、境界をまたぐ際に「このI/Fは正しいのか？」を都度考えることを強制することができる。 境界がなければ意図しない密結合を生みやすくなってしまう。 もちろん、境界を超える

2019/7/30 s-dev talks 〜サービス開発勉強会〜「チームビルディング」での小野の講演資料になります

この記事では、Webデザインやグラフィック制作がぐっと快適になる、最新便利オンラインツール、無料デザイン素材をまとめています。 これらのツールやサービスを利用すれば、これまで面倒だった作業も手軽に、そして短時間で行うことができ、普段のワークフロー改善にもつながります。用途や目的に応じて、お好みのツールを見つけてみましょう。 Web制作をもっと快適に！便利な最新オンラインツールまとめ CSS 3D Transform Examples 遠近感を利用した、奥行き感のある３DデザインをCSSで表現するサンプル集。コードをそのままコピーできるので、カスタマイズも自由自在。 BGJar ウェブサイトの背景デザインに適した、SVG画像をオンライン上で手軽に作成できる無料ツール。ボタン操作のみでカスタマイズを自由に行うことができ、商用利用にも対応しています。 VvvebJS 人気フレームワークBoots

Zennという技術情報共有サービスを運営しています。長期的にZennの流入経路の多くは「検索」になると予想しています。むしろ検索流入が多いサービスであるべきだと考えています。 具体的なソースコードや数式が並ぶ文章は、ソーシャルメディアではあまりシェアされません。ある程度抽象的な内容でないと、読者層が狭く、読み手も労力を必要とするからです。 （具体的な話を盛り込みつつ話題を集める文章を書けるスーパーな方もときどきいますが） しかし、いざ仕事で問題に直面したとき、自分を助けてくれるのは、たいてい具体的なコードを含む記事や実際に問題に直面した人によるニッチな体験談です。すぐに誰かに届くものではないけれど、後から同じ道を通った人は助かる… そんな先人の知恵がたくさん集まる場所になったらいいなと考えています。 SEOに関する情報収集源 本題に入る前に、僕が参考にしているSEO対策の情報源を紹介してお

SaaSシステムを開発しているみなさま、お元気でしょうか。 SaaSシステムというといわゆるWebサービスよりももう少しBtoBの雰囲気が漂ってまいります。 SaaSシステムでは契約者（ここではテナントと呼ぶ）が複数いて、テナント毎に複数のログインユーザーやロールが存在するのが一般的です。そして当然ながらテナント毎のデータは漏洩・混濁が許されない高いセキュリティが求められます。 SaaSシステムの構築はスケーラビリティにおいても100テナント程度から始まりゆくゆくは数千、数万テナントまで少なくとも線形にスケールするアーキテクチャを開発当初から求められ、さらに突発的な大規模テナントも問題なく吸収したいという要求があります。 その要求を満たす設計・開発・保守・運用をやっていくのは当然ながら簡単ではありません。 というわけで今日はマルチテナントアーキテクチャのお話です。 世に出る情報がとっても少

SmartHR のソフトウェアエンジニア ぷりんたい です。SmartHR には2017年2月に入社しました。 この記事は SmartHR 長時間のサービス停止を伴うシステムメンテナンスのお知らせ によせて書かれたものです。 ご挨拶 SmartHR では、昨年の6月より週2日という頻度で夜間のサービス停止を行ってきました。まずは、この運用形態を選択したことによりご利用中のお客様にはご不便をおかけしたことをお詫び申し上げます。 今日のクラウドサービスでは、無停止運用が当たり前といった風潮もありますが、なぜ SmartHR が停止メンテナンス運用を選択したのか、今後のサービス提供においてどのようなことを重視していくのかを技術者としての立場からご説明させて頂きます。 SmartHR の開発初期とマルチテナント問題 SmartHR は2015年2月に開発が始まり、同年11月にサービスインしました。

プログラマが知るべき97のこと大人気の書籍『プログラマが知るべき97のこと』のエッセイを無料で公開中！すべてのプログラマにおすすめの本がウェブで読めるようになりました。 エッセイ一覧分別のある行動関数型プログラミングを学ぶことの重要性ユーザが何をするかを観察する（あなたはユーザではない）コーディング規約を自動化する美はシンプルさに宿るリファクタリングの際に注意すべきこと共有は慎重にボーイスカウト・ルール他人よりまず自分を疑うツールの選択は慎重にドメインの言葉を使ったコードコードは設計であるコードレイアウトの重要性コードレビューコードの論理的検証コメントについてのコメントコードに書けないことのみをコメントにする学び続ける姿勢誰にとっての「利便性」かすばやくデプロイ、こまめにデプロイ技術的例外とビジネス例外を明確に区別する1万時間の訓練ドメイン特化言語変更を恐れない見られて恥ず

プロジェクト・マネジャーが知るべき97のこと大人気の書籍『プロジェクト・マネジャーが知るべき97のこと』のエッセイを無料で公開中！すべてのプロジェクト・マネジャーにおすすめの本がウェブで読めるようになりました。 エッセイ一覧できるだけ早期にユーザーを巻き込むモグラたたき開発を避けようローカライゼーションのせいで締め切りに遅れるプロジェクト・オーナーは強力なプロジェクトサポーター複雑よりもシンプルな方がいい負債を支払うスキルでなく素質のある人を加えようシンプルにいこうあなたは特別ではないスクロールから学んだこと問題にかかるコストを削減するすぐれた開発者を見つけるには熟練と並の開発者の生産性大きさが重要手順を文書化して、守られているか確かめようさあ、プラクティスを投げ捨てよう要求と仕様成功はビジネス価値で評価される休暇をキャンセルしない集中する時間を取るプロジェクトマネジメントはプロブレムマネ

2020 年 8 月にツイートした HTML/CSS/JavaScript のツイートまとめです。見出しをクリックするとツイート元に遷移するので、気に入ったらフォロー・ファボ・リツイートお願いします。 1. enterkeyhint属性 スマホキーボードのエンターキ表示を最適化でき、フォームが送信されたときの動作をあらかじめ伝えられます。 <input enterkeyhint="enter"> <input enterkeyhint="go"> <input enterkeyhint="done"> <input enterkeyhint="next"> <input enterkeyhint="previous"> <input enterkeyhint="search"> <input enterkeyhint="send"> 各属性値を指定したときの表示は以下のようになります。 2

100万行オーバーのモノリシックRailsアプリをマイクロサービス化したクックパッドの手順 マイクロサービスの導入事例を、中の人が徹底的に語ります。クックパッドでは、100万行オーバーの超巨大なRuby on Railsアプリのマイクロサービス化に挑みました。アプリをいかに分離し、連携できるようにするか、など、同社が採ったマイクロサービス化の戦略を聞きました。 Ruby on Railsのバージョンアップに1年かかっていた 【マイクロサービス化戦略】まずはコードを減らすことから 【マイクロサービス化戦略】アプリ固有のバッドノウハウを減らす 【マイクロサービス化戦略】まずは分離しやすい部分からお試しで 【マイクロサービス化戦略】データベースが切れていればサービスも切りやすい 【マイクロサービス化戦略】インフラ構成を標準化する 【マイクロサービス化戦略】サービスメッシュを入れて通信の課題をクリ

はじめに はじめまして、今年のRecruit Job for Student 2020 で Web フロントエンドエンジニアとしてアルバイトをしていた井関です。 私は 1 ヶ月のアルバイト期間で、あるプロジェクトに参画してユーザー体験 (以下 UX) を改善する取り組みを行いました。今回改善していたアプリケーションは、目的を達成するまでに入力しなければならないフォームがとても多い、正確な入力が要求される、利用者がとても多いという特徴があります。この特徴に沿って、多くのユーザーがより快適に正しく入力できるフォームを目指して様々な施策を行ったので、調査から改善までの手順や具体的な改善例を開発者の目線から紹介します。 想定読者 UI / UX に興味がある開発者 フォームの改善に興味がある開発者 目次 調査方法 改善のプロセス 実際に見つかった問題と改善例 フォーカスとアウトライン表示 フォーム

2020年10月1日、東京証券取引所はアローヘッドの機器故障によりシステム障害が発生し、終日売買を停止すると発表しました。故障した機器は交換が行われ、取引は翌日再開されています。ここでは関連する情報をまとめます。 機器故障起きるも縮退運用に失敗 障害概要図 アローヘッド内の共有ディスク装置1号機で機器故障が発生した。実際故障したのはサーバー上のメモリ周辺機器とされる。 1号機故障により両現用で稼働していた2号機のみのフェールオーバー（縮退運用）が行われるはずだったが何らかの問題により行われなかった。 共有ディスク装置を使用する相場配信、売買監視のシステムで障害が発生。 障害復旧時に発生する注文データ消失による市場混乱を避けるため当日終日の取引停止の措置を実施。（遮断） フェールオーバー失敗原因は設定ミス フェールオーバーに失敗した理由が特定できたとして10月5日に発表。 障害発生時のフェー

2020年は、はてな初のオンラインでのインターンシップ開催。 その講義の動画とインターン生に取り組んでもらった課題を公開します。 1週間という短い期間の中で、どれだけのものを吸収して持ち帰ってもらえるか、 はてなスタッフが全力で準備したカリキュラムを、 少しでも体験していただけるとうれしいです。 課題では、Kubernetes上に構築されたブログシステムを題材としました。 ブログシステムはマイクロサービスを意識しており、メインであるブログサービスに加えて、 アカウントサービスや、Markdownなどの記法を変換するサービスが用意されています。 それぞれのサービス間はgRPCを使って通信しています。

みなさんこんにちは。@ryuzeeです。 とある同人誌に寄稿した原稿を知り合いに共有していたのですが、ブログでオープンにしてほしいという依頼を受けたので公開します（同人誌の発行者には許可を取っています）。 怪文書みたいなものですが、感想お待ちしております。 本稿で何を書こうか考えていたところ、Twitterで「これがNASA流の仕事術、「プロジェクトマネージャーが守るべきルール100」が公開される」 という2014年の記事を見かけました。書かれている内容はとても妥当なもので、プロジェクトマネージャーだけでなく、組織のリーダーでもプロダクトマネージャーでもプロダクトオーナーでもあてはまるものでした。 ただ問題は100個という数です。チェックリストに100個の項目があっても覚えられません。プロダクトバックログに100個の項目があった場合、覚えているのは先頭の方と、気になる項目だけになるでしょう

はじめに RSpecって結構「RSpecらしく書くこと」を求められたりします。 たとえば、describeやcontextでしっかりグループを分けましょう、再利用するデータはletやsubjectに切り出しましょう、ひとつのexample（it）の中でテストするのはひとつの項目だけにしましょう、等々の方針です。 よくあるのが「Better Specsを読んで、こんなふうに書くようにしましょう！」っていうパターンですね。 Better Specs しかし僕の場合、最近は「そこまでがんばってキレイにしなくてもいいのでは？」と考えるようになってきています。 その結果、テストコードがだんだん雑になってきています。 というわけで、この記事では最近僕が実践している「雑なRSpec」の書き方を紹介します。 備考 この記事は以前自分のブログに書いた内容を加筆・修正したものです。 「雑なRSpec」以外の話