タグ

ブックマーク / docs.esa.io (5)

  • diary/2018/07/01/ハッカーズチャンプルー2018でesaのデザインの話をしてきました #hcmpl

    ハイサイ デザイナーの@ken_c_loです。台風接近中の沖縄・那覇からお送りしています。 ハッカーズチャンプルー2018という沖縄で開催されたイベントで、『esaのデザインの話 - 自分たちのWebサービスを作るデザイナーとしてやっていること 』というタイトルで発表をさせていただきました。 > 発表の補足など発表の補足など 懇親会やネットなどで質問やリアクションをいただいたり、色々お話できたりしたので、それも踏まえて何点か補足したいと思います。 デザインは理論か?感覚か? 今回は、デザインするときの思考プロセスをわかるように説明しようと整理したので、一見ロジカルに段階を踏んで考えているように見えるのですが、実際にはここまできれいに段階を踏んで考えているわけでもなくて、割と感覚的に瞬間的に思いついたことを、後から理屈が通っているかどうか、ひとつひとつ検証した結果がこんな感じである、という方

    diary/2018/07/01/ハッカーズチャンプルー2018でesaのデザインの話をしてきました #hcmpl
  • esaトーク/日常もesaもハックするリモートワーカー集団 ─ Vol.5 株式会社Misoca様

    こんにちは (\( ⁰⊖⁰)/) esaのユーザーさんに、esa社のワレワレが突撃してお話を聞きにいくという企画、 esaトークの第5回です! 今回は、株式会社Misoca さん(以下 Misocaさん)です。 Misocaさんには、2017年の1月に、esa meetup @ Misocaを開催して頂いたり、普段の業務の請求書にも利用させて頂いていたり、とてもお世話になっております。 Misocaさんの社オフィスは名古屋にありますが、多くのスタッフがリモートワークで、自宅や松江にもオフィス等の遠隔地から働いています。 今回のインタビューは秋葉原にある弥生株式会社さんのオフィス(Misocaさんは弥生さんのグループ会社)でやらせていただいたのですが、各地から色んな人が飛び入りリモート参加するという、Misocaさんならではの面白いスタイルになりました。お楽しみください(\( ⁰⊖⁰)/)

    esaトーク/日常もesaもハックするリモートワーカー集団 ─ Vol.5 株式会社Misoca様
  • policies/サービス運用ポリシー #noexpand

    この文書は、esa LLC(以降、当社と呼ぶ)の運営する、esa.ioの運用に関してのポリシーである。 > サービス運用責任者サービス運用責任者 深谷篤生 > サービス運用に関する通知手段サービス運用に関する通知手段 > サービス全般の通知手段サービス全般の通知手段 ドキュメントページ docs.esa.ioへの記載 Twitterのesa公式アカウントからの発信 > 監視における異常状況の通知手段監視における異常状況の通知手段 ドキュメントページ docs.esa.ioへの記載 Twitterのesa公式アカウントからの発信 利用者が登録したメール宛への配信 > その他状況の通知手段その他状況の通知手段 ステータス通知用サイト status.esa.ioにて通知 > サービス運用監視サービス運用監視 > 運用監視通知の段階運用監視通知の段階 運用監視通知は以下の2段階で行う。 速報として

    policies/サービス運用ポリシー #noexpand
  • help/複数チームの決済連結(1会社で複数チームを持つ際の、お得な料金決済方法)

    (チームごとにユーザ数に¥500を掛けて計算) (TeamAの料金) + (TeamBの料金) + (TeamCの料金) = ¥500 x 2 + ¥500 x 1 + ¥500 x 1 = ¥2,000 > チームを連結した場合チームを連結した場合 (親子関係のあるチーム内に所属するユーザ数に¥500を掛けて計算) (User1の料金) + (User2の料金) = ¥500 x 1 + ¥500 x 1 = ¥1,000 > 設定の仕方設定の仕方 親チーム側の SETTINGSページのご利用料金メニューより、子チームを連結決済対象チームとして追加/解除することが出来ます。この操作をするユーザーは 親チームと子チーム両方のチームのownerである必要があります。 ↓ ご利用料金ページの最下部に「複数チームの連結決済」の設定画面があります。 > 注意点注意点 クレジットカード情報は親チーム

    help/複数チームの決済連結(1会社で複数チームを持つ際の、お得な料金決済方法)
    jazzanova
    jazzanova 2016/08/31
    便利
  • diary/2016/03/30/インフラの引っ越しを行いました

    以下、ざっくり説明していきたいと思います。 > Web Server/Workerの移行Web Server/Workerの移行 従来はHeroku(US region)にサーバがあったため、日からのアクセスの場合チューニングをどう頑張っても数百msの遅延がありました。これをAWS(Tokyo region)に移行することで、ページを表示するのに要する時間が1/2 ~ 1/3まで改善されました。 > DockerDocker 移行開始直後は自分が不慣れなこともあり、このタイミングでDockerを採用する気はありませんでした。しかし、実際にECS上でのデプロイを検証したり、Dockerについて学習するうちに移行のイメージが掴めてきたのでDockerを採用することにしました。 もともとHerokuで動いていて The Twelve-Factor App にほぼ沿っていたので、やってみるとDo

    diary/2016/03/30/インフラの引っ越しを行いました
  • 1