サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
creators-note.chatwork.com
こんにちは!フロントエンド開発部の石山です! フロントエンド開発部では、スケールしやすいアプリケーションを目指して日々改善を行なっています。 今回はコードの品質を高めるためにフロントエンドチームが行なっている、モブレビュー会を紹介します! モブレビュー会とは モブレビュー会を始めたきっかけ モブレビュー会の流れ なぜマージ済みのPRをレビューするのか レビューをするときに意識していること 実際のレビューコメント モブレビューをやってみてよかったこと 他フロントエンドメンバーの感想 さいごに モブレビュー会とは モブレビュー会は1つのPRをフロントエンドメンバー全員でレビューを行う場です。 ここではコードに対しての疑問点や改善点を絞り出すことに焦点を置いてレビューします。 モブレビュー会を始めたきっかけ フロントエンド開発部では、メンバー間でアーキテクチャや知識を共有する目的でモブワークを行
こんにちは。DevHR ( 開発人事 ) の 門田 ( @nottegra ) です。 今回は Chatwork の開発チーム活動で利用している SaaS サービスについてご紹介したいと思います。 ※GitHub などの開発関連のサービスは (他の人が書いてくれることを期待して) 除外します Chatwork / Chatwork Live Google Workspace Confluence JIRA Miro Zapier 最後に Chatwork / Chatwork Live Chatwork 開発チームのコミュニケーションは、 Chatwork を活用しています。 チーム単位でのコミュニケーション以外にも、特定の技術トピック毎に作られたグループチャットがあり、職種などを限定せず活発な情報交換が行われています。 また、開発チームの文化として「分報」に近い個人毎のチャットルームを設
みなさん、こんにちは!Chatworkの原田 (@shinharad) です。 今回は、最近弊社で取り組んでいる Scala 3 の社内勉強会について、このような流れでご紹介したいと思います。 最初に Scala 3 の今の状況をざっと確認 Chatworkでは Scala 3 の社内勉強会を継続的に開催している 勉強会で使っている資料、情報源のご紹介 勉強会でやったことをいくつかご紹介 Scala 3 の状況 まずは、Scala 3 の今の状況について軽く確認しておきましょう。 待ちに待った Scala 3 は、この記事を執筆している時点での最新版が Scala 3.0.0-RC3 で、大きな問題がなければこの5月中にも安定版がリリースされる予定です。 Scala 3 は、Scala 2 で不便だった機能や、煩雑で分かりづらかった機能が大幅に見直されました。 具体的には、代数的データ型(
どうも、かとじゅん(@j5ik2o)です。 Scala製ライブラリでの依存ライブラリ更新と定期リリースをGithub Actionsを使って自動化するようにしたので、以下にその方法をまとめます。 具体的な例を見たい場合は以下のリポジトリを参照してください。 github.com 自動化した作業 依存ライブラリのバージョンアップのPR作成とマージ リリースノートの生成 JARファイルの公開 ツールの前提条件など sbt-ci-release, sbt-scalafix, sbt-scalafmtのsbtプラグインは必須としています。CIでリリースするだけならsbt-ci-releaseの設定だけでOK project/plugins.sbt 参照 sbt-ci-releaseの設定 git tagに振られたバージョンに基づいてリリースするのでversion.sbtを削除 sbt-releas
こんにちは、Chatworkのさかぐち(cw-sakaguchi)です。 「Google Apps Script」を利用して「業務効率化」する手順を不定期に更新しております。 Chatworkを利用する中でメッセージを「予約投稿」したいと思ったことはありませんか? 今回は「指定した日にChatworkへメッセージを投稿する仕組み」を作成しようと思います。 目次 目次 Google Apps Scriptとは この記事でできること 手順 Chatwork API Tokenの発行 スプレットシートの作成 予約投稿したい内容を記載 Google Apps Scriptの作成 ライブラリの読み込み トリガーの設定 動作確認 まとめ Google Apps Scriptとは gsuite.google.co.jp Googleが提供しているJavaScriptベースのスクリプト言語です。 インスト
こんにちはー。突然ですが、聞いてくださいよー。 Babelのバージョンアップしたら「Chatworkのルーム切り替えが重くなった」と社内で言われてしまいました。 みんなの仕事の効率を悪くするわけにもいかないので、戻すしかありません。Babelの更新って、本当に怖いですよねー。 そんなわけで、こんにちは。フロントエンド開発部のひむら(id:eiel)です。 さて、この話自体は少し前のことなのですが、その際に原因を特定する余裕がなく、Babelの更新は後回しになっていました。 ルーム切り替え自体が歴史的経緯もあって、「とーっても」*1難易度が高くなっていて、最悪これを改善すれば更新できるだろうと期待もしてたりもしました。 ところが、うっかり再発させてしまったので、ここで気合をいれて改善することにしました。 今日はその話を記録しておきます。 要約 経緯 原因の特定 試しにIE11をターゲットから
今回はEKSでDNSを安定させるために対応した話を書きたいと思います*1。 一定数のPod以上になるとサービスが不安定になる conntrack溢れの犯人はkube-dns(CoreDNS) conntrackのmaxを増やす kube-dnsのautoscale node-local-dnsも入れる node-local-dnsを入れた途端にDNSまわりが再び不安定に node-local-dnsの利用ポイント@EKS 無事に安定 一定数のPod以上になるとサービスが不安定になる creators-note.chatwork.com Chatworkでは、2020年にEC2で動かしていたレジェンドシステムをEKSに移行しました。 その移行の際(EC2側とEKS側でRoute53での重み付けによる並行稼動しながら)、ある割合以上のリクエストをEKS側に流すと、途端に不安定になる状態になりま
こんにちは。SRE部坂本です。毎年最低1回はフルマラソンに出ていますが、2020年はあえなく参加できずに終わりました。 2月にギリギリ行われたハーフマラソンではなんとか90分切り(89分台)を達成し、今年は3時間10分以内を目指してただけに残念ですが、仕方ありません。 特に部活等で走っていたわけでもなく、トラックの大会に参加するのはやや抵抗があり、年間の走行距離ぐらいしか目標がなく、これを書いている12月中旬で2591kmとなっています。昨年が2724kmだったので、なんとか更新したいなーというのが今の気持ちです。 さて、Chatworkでは2016年からKubernetesを導入しております。EKSもない時代ですので、kube-awsというツールを利用してEC2にホスティングして運用していましたが、今年EKSに移行しました。 aws.amazon.com そんなChatworkのKube
こんにちはかとじゅんです。 この記事は、ドメイン駆動設計 Advent Calendar 2020の23日目の記事です1。DDDというよりRustの記事になってしまった…。 Rustの勉強を始めたのは2017年あたりと古いのですがなかなか身が入らず、本腰入れたのは今年の11月ぐらいでした(遅ッ。Scalaで実装してたライブラリをRustに書き換えたおかげでようやく開眼しました2。 というわけで、今回は完全趣味の領域であるRustでドメインモデルをどう実装すればいいのかについて、僕の意見やアイデアなど雑にまとめてみたいと思います。まぁこれについてもいろんな観点がありますが、値オブジェクトやエンティティを実装するならという観点です。 ※あ、Rustの所有権システムなどの言語仕様については細かく触れないので、各位適宜正しい情報源を参照してください。 構造体とメソッド 見慣れた(見飽きた)銀行口座
みなさま、お疲れ様です!エンジニア採用広報の高瀬 (@Guvalif) です。 この記事は、Chatwork Advent Calendar 2020 における、16 日目の記事です。 Chatwork にはたくさんの部活動があるのですが、その中に「数学部」という部活があります。 この記事は、数学部の活動として定期的に実施していた社内圏論勉強会からスピンオフして、 「さまざまなデータ構造の背景にある、数学的な構造」を、わかりやすーく (≒ No ほむほむ*1に) 紹介してみるものです。 I. 参考文献のご紹介 II. データのまとまりとはなんだろう? III. 適切なモデルを考える IV. 2 つの列は同じもの? V. 連結操作に代数構造を加える VI. 代数構造を変えれば、データ構造も変わる VII. まとめ I. 参考文献のご紹介 まず本題に入る前に、この記事の元となった資料をご紹介し
これは Chatwork Advent Calendar 2020 / Scala Advent Calendar 2020 10日目 の記事になります。 こんにちは。サーバーサイド開発部の Scala プロダクトを開発運用する部署でマネージャーをしている、 hayasshi です。 Chatwork は Scala を採用すると決めてから、約 6 年経ちました。 その中で、失敗もしながら、少しずつ Scala のシステム領域を広げてきました。 今回と次回の二記事にて、この 6 年で開発し、いま実際に稼働運用されている、 Chatwork の Scala プロダクトの紹介と、それを普段どのように開発運用しているかについて、書きたいと思います。 Scala プロダクトの紹介 今回は Chatwork の Scala プロダクトについてご紹介します。 特に下記の項目についてそれぞれ記載したいと
こんにちわ。id:cw-tomitaです。 この記事は、Chatwork Advent Calendar 2020 - Qiita の3日目の記事です。 早速ですが、皆さんはauto incrementなRDBのtableのidにはどのような型を利用されていますか? Chatworkでは多くのテーブルでint型が指定されているのですが、9年前にサービスを開始した時には想像もつかないくらいに多くのお客様に使っていただけるサービスへと成長した結果、int型なauto incrementのidを利用しているテーブルで、レコード数がintの上限を迎えそうなテーブルが複数現れ、どかっとまとめてALTER TABLEを実施するという2020年を代表する一大イベント(?)がありました。 今回は、その時に利用したpt-online-schema-changeというツールを使ってのALTER TABLEの実
こんにちは! Chatwork 株式会社のプロダクトマネージャー (PM)、宮下 (@ryugoo_) です。 2013 年にモバイルアプリエンジニアとして入社し、 2014 年に Android 専任になり、 2019 年からは PM に転向してそろそろ 2 年になろうとしています。 さて、今回はエンジニアから PM になった私から見た、 Chatwork の技術選定の流れの変化について話してみようと思います。 技術選定の歴史 2013 年 - PMF を目指すために 2014 〜 2016 年 - 技術的課題を解決するために 2017 〜 2020 年 - ユーザー影響を最小化するために これから - 攻めた技術選定を、ユーザーのために 2013 年 - PMF を目指すために 2013 年当時の Chatwork は PMF (Product Market Fit) を目指すフェーズ
おはこんにちは、かとじゅん(@j5ik2o)です。 今回の記事は、IDフォーマットの一種であるULIDの実装についての記事です。 ULIDよーわからんという人は、以下の僕の記事を参照してみてください。 zenn.dev ID生成をどうするか議論によくなりますが、最近はソート可能なUUIDとしてULIDが話題にあがります。128ビットでかつ文字列型のキーが許容できるのであれば、ULIDはよい選択肢になりそうです。 既存のScala実装 実際Scalaで使おうと思うと以下が代表的な選択肢になると思います。 Scalaで実装されたものを使う GitHub - petitviolet/ulid4s: ULID implementation in Scala GitHub - wvlet/airframe: Essential Building Blocks for Scala ulid4sがair
お久しぶりです、かとじゅん(@j5ik2o)です。テックブログを書くのは何年ぶりか…。 サービスが停止したり応答性が低下すると、お叱りや逆に励ましをいただきますが、エンジニアとして設計レベルからそういった問題に対処するにはどうするか、日々精進しているところですmm。この記事はそういう論点で注目されている「リアクティブ原則」についてまとめてみたいと思います。 それなりのボリュームになってしまったので、時間があるときに読んでいただければと思います。 さて、Linux Foundation内の新たなトップレベルプロジェクトであるReactive Foundationが主催する、Reactive Summit 2020が11月10日にオンラインで開催されたので参加しました。 www.reactivesummit.org 参加されていたスピーカーはLightbendをはじめ、Netflix, Fac
こんにちはー。藤井 (@yoshiyoshifujii) です。 Akkaってスウェーデンの山の名前なんですって、ご存知でした?わたしは知りませんでした。 そういえば、Akkaのロゴって山っぽいですもんねー さて、今回の標題の件ですが、ひらたくいうと、 「プロダクトバックログを作成して、バーンアップチャートを作り、Velocityを計測して、観測しましょう」 ということになります。 アジャイルの書籍やコミュニティでの発表など、それが必要で効果のあることだと分かってはいたのですが、なかなか実践できておりませんでした。 先日、Scrum Inc.主催のLicensed Scrum Product Owner研修を受けさせていただき、その中で教わった内容を、早速、現場で実践したところ、チームの評判も良く、ステークホルダーへの説明にも効果を発揮しそうな肌感を得ておりますので、そのあたりをご紹介でき
まえがき こんにちは!サーバーサイド開発部(PHP)の中田です。 今回は北海道在住の私がコロナ禍真っ只中でChatworkに入社するまでの思い出と、 3ヶ月の試用期間を終えた今も1度も社員と直接あったことのないレベル(笑)の純フルリモート業務を体験した感想をつらつらと書いていきます。 この記事でコロナ禍の就職&転職活動をしている皆さんになにかお伝えできれば幸いです。 去年10月末に化粧直ししたニッカおじさん 記事のまとめ コロナの影響なく、転職に成功 東京に行くはずが札幌に残ることに... フルリモートで働いているが、意外と仕事はできる でもリモート下のコミュニケーションはちょっとハードル高い 入社するまで 内定が決まった4月から入社した6月までを順に思い返していきます。 4月 内定。しかし。。。 4月6日に内定を受け、Chatworkへの転職を確定しました。内定までの面接や面談、入社時の
みなさん、こんにちは〜😃 モバイルアプリケーション開発部のAndroidエンジニア、ジェロームです。 この記事では、モバイルアプリチームのリリースフロー改善について紹介します。 先日#ChatworkTechTalkで発表させていただいた内容をより多くの方に知ってもらいたいため、ブログにまとめました😄 リリースフローとは? 今モバイルアプリチームで使っているツール 改善前のリリース作業の違い リリースフロー スケジュール ステップ 今までの問題 どうやって改善するの?🤔 Bundlerとは 改善した後 1. コードフリーズ 改善前 改善後 翻訳依頼 2. リリースノート 3. ストア申請 4. リリース 改善のときに苦労したところ 改善した効果 Hotfixの場合? まとめ リンク リリースフローとは? アプリの開発をしたり、不具合を修正した時に、ストアに新しいバージョンを公開するま
こんにちは、守谷(@emim)です。 今までWebアクセシビリティについて、デザイン部*1内で勉強会を実施したり、クリエイティブ職以外への啓蒙活動などを社内でちょこちょこ開催してきました。 実施内容すべて漏れなくは報告できていませんが、このCreator's Noteでも私以外の複数のメンバーもブログ記事にまとめてくれています(Accessibilityあるいはa11yというタグで、閲覧いただけます)。 そんな中しばらく私を悩ませていたのは、いくら自分自身(デザイナー)が知識を貯めて啓蒙を進めたところで、実際プロダクトの設計フローに「アクセシビリティ施策実施」という要件が乗らない限り、永遠に改善を深部まで進められない……という現実とのジレンマでした。 そんな中! 今夏やっと、プロダクトに改善施策を反映していくためのチームを立ち上げることができました!!!👏🏻 名付けて……と思ってはいた
こんにちは! フロントエンド開発部の澁谷(shibe23) です。Creator's Noteには初投稿となります。 「レガシーフロントエンド脱却への挑戦」というテーマで各メンバーが投稿してきましたが、今回の投稿で一区切りとなります。 各メンバーの投稿はこちらです。 自前アーキテクチャなコードを Redux 構成に書き換えているお話 【Chatworkフロントエンドを大解剖!!】フロントエンド開発部に入社して3ヶ月が経ちました ウェブフロントエンドの設計力を高めるためにアプリケーションの構造を捉えてみる話 最後のテーマは、jQuery -> Reactへの移行にあたって特に重要な役割を果たしている、ACL(腐敗防止)層です。 「jQueryからReactへの移行ってどうやってるの?」という質問をいただく機会も多いので、今回の記事が参考になれば幸いです。 Chatworkのアーキテクチャの変
こんにちはー。 フロントエンド開発部の火村(ひむら/id:eiel)です。前回までは id:cw-himura で記事を書いていましたが、個人アカウントに切り替わりました。 よろしくおねがいします。 以前はサーバーサイド開発部に所属していましたが、2019年6月ぐらいからフロントエンドチームにヘルプとして無期限レンタル移籍中です。 主な担当している業務は「難しいバグ対応」と「これからChatworkのウェブフロントエンドをどうするかを考える」です。 昨日は期待の新人であるレオくんの入社して3ヶ月の熱烈な想いでした。アツいです。 さて、今回のお題は「レガシーフロントエンド脱却への挑戦」と雑に上から投げられたのですが、未来のことを考える作業をしているので書きやすいネタがありません。 あってもオチがつきません。 ということで、設計に役立つかもしれない話をラフに書くことにしました。 アプリケーショ
こんにちは、フロントエンド開発部の西口 (cw_nishiguchi) です。 Chatwork はおかげさまで、サービス開始から来年で 10 年を迎えようとしています。 この記事は、その歳月においての Web クライアントのアーキテクチャの変遷をたどるお話になります。 アーキテクチャの変遷 これまでのアーキテクチャを大まかに分けると、 サービス開始当初の jQuery 期 React 導入期 Redux 導入期 となり、現在は Redux へ移行中というステータスです。 便宜的に 3 期に分けて書きましたが、実際には jQuery 期のコードも部分的にですが、まだ現役で動いています。 アーキテクチャの刷新を実際におこなうには、それなりのコストが発生します。また、その間機能開発を止めるわけにもいかないので、エイやで一度に置き換えられないため、部分的に少しずつ機能開発と並行して進めています。
こんにちは。cw-kajiwaraです。 privateレポジトリに対してScala StewardをCircleCIで定期実行するようにしてみたので、その設定方法の共有をさせていただきます。 社内レポジトリなどのpublicにできない or したくないレポジトリの依存ライブラリ更新作業を省力化したい方はぜひご覧ください。(社内レポジトリをpublicにして公式botに更新してもらうというのもかっこいい選択だとは思います) TL;DR Scala StewardをCircleCIで定期実行させるために必要な手順は以下です。 bot用のGitHubアカウントを作成する bot用のGitHubアカウントのAPIトークンを作成する Scala Steward用のレポジトリを作成する Circle CIプロジェクトを作成する 環境変数を設定する Circle CIを実行する Scala Stewa
こんにちは、梶原(cw-kajiwara)です。 Biryani PJシリーズでの投稿です。今回の記事ではメッセージ検索機能におけるメッセージの差分マイグレーションを行うKafka Consumerアプリケーション、通称Indexerについて紹介いたします。 vol.1ではプロジェクト発足の背景・概要を、vol.2ではPJ前後のシステム構成、Elasticsearchの負荷試験考察やCWでの運用方法、vol.3ではデータマイグレーションについて紹介していますのでご興味あればぜひこちらもご覧ください。(ご興味あれば、と言いつつも読んでもらっていることを前提にしてしまっているところは所々あります) Biryani プロジェクト(メッセージ検索機能のCloudsearchからElastcsearchへのリプレイス)について vol.1 - Chatwork Creator's Note Biry
こんにちわ、cw-tomitaです。 前回の記事に続いて、Biryaniプロジェクトに関して、あれこれと書いていきたいと思います。なお、この記事は、先日公開した以下の記事の続きとなりますので、こちらを未読の方は、是非vol.1からお読みいただければと! creators-note.chatwork.com 先の記事では、PJが始まった経緯、Elasticsearchを第一候補として選んだ理由等について書きました。今回は、POC/実装を進めていく中で、苦戦したポイントと解決方法に関して、主だったポイントを挙げていきたいと思います。 最初にどのようなものを作ったかをざっと紹介し、その上で、 今回の記事の中では、Elasticsearch 自体にフォーカスをあてて、色々と紹介していきたいと思います。 Sparkでのデータマイグレーションや、Scalaのindexerの実装等に関しては今回は取り上
こんにちわ、SRE部のcw-tomitaです。 今回は、7/17(金)に行われた全社合宿で、プロジェクトとしては惜しくもベストPJ賞を逃したものの、オーディエンス賞を受賞(全社跨いで、半期の間に実施された数々のPJの中で厳選された3つのPJだけが賞をもらえる)し、また、このプロジェクトをリードしたcw-kajiwaraが、このプロジェクトを通しての圧倒的なコスト削減の実績からCFO賞を個人受賞するという、上期の社内の賞レースを席巻した、メッセージ検索機能のリプレイス(通称:Biryani PJ) *1 に関して紹介したいと思います。 写真は、先週行われた全社のオンライン(役員・準備/進行担当の方を除く)合宿での、感動の受賞シーン。 目次 目次 tl;dr 移行前の構成 移行を検討することになった背景 規模の変化 構成の変化 移行先の検討の開始 Elasticsearchの事前調査 Powe
こんにちは、新井です。 子供と並んでアゲサゲコンボするのが愉快な今日この頃です。 チームでリモート環境を前提としたモブワークを始めて約1年が経ちました。 当初部分的に始めたモブプロが、プログラミング以外に領域を広げてモブワークになり、モブをベースとして仕事をするようになり……という変遷がありました。この経験で得られた知見を共有したいと思います。 リモート環境で"1つのことを考える"ことの重要さ、困難さ モブワークを始めた当時「モブプログラミング・ベストプラクティス」*1を読みました。 かなり詳細かつ具体的にモブプロのプラクティスが紹介されていましたが、 物理的に同じ場所にいることが前提になっていて、そのまま自分たちに適用できないなーと思ったのを覚えています。 私が思うに、モブプロ、モブワークをする上で最も重要なポイントは「1つのことを考える」です。 モブワークには知識の共有・同期をはじめと
Chatwork 坂本です。 本ブログは2020年1月23日に行われた、下記のコンテナ支部での発表を補足する内容で、eksctlの設定ファイルとvariantの具体的な使い方に焦点を当てて書きたいと思います。 jawsug-container.connpass.com speakerdeck.com 目次 eksctlの設定ファイル preBootstrapCommandsについて variantの具体的な使い方 まとめ 最後に(どうでもいいニュース) eksctlの設定ファイル 発表資料では、主にeksctlをvariantでwrapして、運用している、という話をしましたが(さらにeksctlの設定ファイルのテンプレートからの生成もvariantで)、そもそもなんでそのような運用が必要なのか、というのを、eksctlの設定ファイルの構成から説明していきたいと思います。 下記がChatwo
こんにちは。プロダクトデザイン部マネージャーの @cw-take です。 今年Chatworkのプロダクトデザイン部で「UIデザイナーのスキルマップ」をつくりました。 この記事では簡単なスキルマップの説明をした上で、アクセシビリティスキルを掘り下げて紹介したいと思います。 UIデザイナーのスキルマップ スキルマップ作成の背景 新しいデザイナーの入社をきっかけに、今年プロダクトデザイン部では価値観の相互理解などお互いを知るための取り組みをおこなってきました。 「UIデザイナーのスキルマップ」をつくったのもこういった取り組みのひとつです。 スキルマップを使いUIデザイナーそれぞれが持つ強みを可視化し共有することで、 伸ばしたいスキルについてお互いが支援できる環境 をつくりたいと考えました。 スキルマップの12項目 スキルマップの項目は「プロダクトデザイナーのスキルマップを考えてみた : cou
次のページ
このページを最初にブックマークしてみませんか?
『Chatwork Creator's Note』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く