これは Kyash Advent Calendar 2024 1日目の記事です。 2022年1月から VP of Engineering という役割でKyashの開発組織全体のマネジメントを始め*1、2024年1月から 執行役員 VP of Engineering になり1年くらい経ちました*2。 当初は「今までどおりいいプロダクトを作っていけるように行動していくだけだし大きくは変わらん」と思っていたのですが、想像以上に変化もあったので備忘として残しておきます。 ここに書ききれないこともたくさんあります。「1年近くやってこんな抽象的なことしか書けないのか」と感じられるかもしれませんが、まああまり背伸びせず反省も込めて今のスナップショットをそのまま書くことにします。 結果として事業はよくなっている Kyash のようなカード発行型の決済サービスというのは、決済単体の収益性で見ればいわゆる "
私は都内のベンチャー企業でSaaSの開発をしているエンジニアです。 最近、事業を進めるなかで感じていることがあります。それは、エンジニアとしての「優秀さ」の定義が変わってきているな、ということです。 もはや技術力では勝負がつかないかつてエンジニアの優秀さの定義は「いかに高い技術力を持つか？」が大きな割合を占めていました。 しかし、いまの日本のWeb事業において、ぶっちゃけ「技術力」が事業の決定打になることはほぼありません。 たとえば「Wantedly」のような求人掲載サービスも「クックパッド」のようなレシピ共有サービスも、機能として見たときには大きな違いがないですよね。情報が登録できて、表示されて、検索できて、いいねや検索条件の保存ができて……と、基本機能はほぼ同じように見えます（あくまで外から見た限りですが）。 私たちが開発中のSaaSも、基本機能は「データ入力、保存、表示」なので、さほ
はじめに はじめまして、さかがみ かずと(@_skgm092)です。 今回は自分がお手伝いしているプロジェクトで、本番DBへのアクセス作業中に発生したトラブルについて記録します。 自分の失敗を公開することは恥ずかしいものですが、同じような事故を防ぐための参考になればと思い、共有することにしました。 自分のしかばねを糧にして、皆様は同じ失敗をしないようにしてください。 トラブルの概要 起きてしまったこと 担当プロジェクトはコアタイムがPM10-AM03頃のSNSサービスでした。 サービスの主要機能が完全に機能停止する事態が発生し、コアタイムの大部分を緊急メンテナンスで停止せざるを得ない状況となりました。 どんな作業で発生したか マスタデータを含むテーブルの列を書き換える作業中に発生しました。 具体的には、とあるマスタデータのJSON型の列を全てブランク値で上書きしてしまいました。 何が問題だ
iPhone17 ProシリーズではiPhone16 Proシリーズと比べて何が変更されるのか、予想や噂に基づく主な8種類の変更点をMacRumorsがまとめています。 iPhone17 Proシリーズは、デザインも大きく変更されると噂されています。 リアカメラ部のデザインは大きく変更され、長方形になると予想されています。 現行デザインのままでリアカメラ部を拡大すると、アクセサリーがMagSafe部に干渉するのが避けられないのも理由の1つとも考えられます。 また、リアカメラ部はiPad Pro (M4)のようにアルミニウム合金製になり、背面パネル下部はMagSafeに対応させるためにガラス製になるとみられています。 https://iphone-mania.jp/iphone17-590787/
EMになってかれこれ1年半ほど経過しました。仕事でほとんどコードを書かなくなってからは1年くらいが経ちます。代わりに組織やヒトのマネジメントが主務になっています。情報収集をしてチームの軌道修正をしたり、メンバーの活躍や成長を助けたり、組織の成果を大きくするための変化を企画したりといった具合です。何かを考えておく、文書にまとめるという仕事が日々大量に襲ってきます。それらを効率よくこなす訓練をしていくと、日々の仕事の不確実性はどんどん下がっていきます。この件は30分で結論を出す！この企画書は1時間でまとめきる！それを見積り通りやれるようになっていきます。パフォーマンスを出す上で、仕事に不確実性はないし許容できないというマインドが強くなるのを感じます。 そんな暮らしの中で、月に1件くらい開発タスクをやることがあります。チームの負荷を下げるためメインラインではない保守運用を巻き取ることにしているの
TOPICS System/Network 発行年月日 2024年12月 PRINT LENGTH 164 ISBN 978-4-8144-0091-1 原書 Tidy First? FORMAT Print PDF EPUB 乱雑なコードは厄介です。コードを読みやすくするには、管理できる小さなまとまりに分割する必要があります。本書は、エクストリームプログラミングの考案者で、ソフトウェアパターンの先駆者であるケント・ベックが、システム全体の構造を念頭に置き、コードを改善するには、いつどこで整頓するのがよいかを解説します。 整頓のしかたを一気に習得するのではなく、整頓を少しずつ試しながら自身の課題解決につなげます。コード行数の多い大きな関数については論理的にコードを小さなチャンクに分割する方法を学び、その過程で、結合、凝集、ソフトウェアシステムの経済的価値（ディスカウントキャッシュフローやオ
最近、Webエンジニア界隈で、共通項を感じる印象的な出来事があった。具体的には以下の2件。 ゆーすけべーがHonoを作ったこと Hono - ゆーすけべー日記 おぎじゅんさんが職業プログラマーに戻ってきた(きていた)こと 転職してソフトウェアエンジニアをやっている 猫廼舎を閉店しました 共通項はそれぞれ長めのブランクがありながら、ソフトウェアエンジニアリングの世界に戻ってきて一線級以上の活躍をしているということだ。二人とも僕と同世代かそれ以上の年齢でもある。これは勇気と希望をもらえることだ。 もちろん彼らの能力の高さゆえに第一線に戻ってこられたのかもしれない。ただ、どちらにせよ、別のことに興味があれば、職業エンジニアを離れて、フォーカスする期間があっても良いと言うことだ。能力不足ならなおさら中途半端になるよりフォーカスしたほうが良いとも言える。 それに多分戻ってこられる。ゆーすけべーの様に
シニアエンジニアとイシュースカベンジャーの苦悩 誰もやりたがらないIssueは、誰もやらないまま残り続け、やがてゴミになる。例を挙げるとすれば以下のようなものだ。 リファクタリングなど、成果が見えづらいIssue ライブラリアップデートなど、面倒臭いIssue 納期があるからと後回しにしたIssue これらは労力やスキルを必要とするわりに地味で成果が見えづらく楽しくない。いわゆる「コスパの悪いIssue」だ。人事評価という制度がある以上、自身の評価を上げるにはコスパの悪いIssueは誰もやりたがらない。 しかし、ゴミIssueを放置すると腐り始め徐々にプロジェクト全体を蝕む厄介な存在になる。 私は、こういったクソタスクを拾って対応する役割を「イシュースカベンジャー（造語:Issue Scavenger）」と呼んでいる。そして自分がまさにその役割を担っている。 私の場合、他メンバーよりも我慢
「コードを書くのは好きだけどドキュメントは苦手」 「ドキュメントはつい後回しにしてしまう」 エンジニアの皆さん、そんな覚えはありませんか？ 本書は、日本語ドキュメントのスペシャリストであるテクニカルライターの著者が、エンジニアが「いつ」「何のドキュメントを」「どうやって」書けばよいのかを、イチから解説します。 先生役の著者と生徒役をキャラクターにし、全編にわたってイラストを豊富に掲載。 はじめてドキュメントを書くエンジニア、またはこれまで自己流で書いてきたエンジニアが、一度読めば一生使える知識満載です。 装丁画と挿絵は、カケヒジュンさんが手がけます。 ＜基礎編＞ Chapter１ 良いドキュメントを効率良く書くために Chapter２ ドキュメントの読み方を理解する Chapter３ 読み手とテーマを選定する Chapter４ テーマを分解する Chapter５ ドキュメントの骨組みを組む
例外ハンドリング周りによく悩むので、改めて考え直してみた ちなみに、例外とエラーは置き換え可能として、区別せず、 try-catch形式を想定してます 全体のイメージ イメージとしてはこんな感じ 利用者やアプリケーションは、 APIサーバなのか、Web/スマホアプリなのかによって変わるけど、 アプリケーション ... 作った部分 利用者 ... アプリケーションを使うユーザやシステム 外部システム ... アプリケーションが利用してる部分 実行環境 ... アプリケーションを動かしてる部分 というイメージ 例外のいろんな分類 例外の分類には色んなバリエーションがあるっぽい 業務例外とシステム例外 業務例外 ... 業務ロジック(ビジネスロジック)での例外 システム例外 ... それ以外のシステムの技術的な例外 回復可と回復不可 回復可 ... 再操作などでリカバリ可能 回復不可 ... リ
こんにちは。コミュニケーションアプリ「LINE」のモバイルクライアントを開発している石川です。 この記事は、毎週木曜の定期連載 "Weekly Report" 共有の第 51 回です。 LINEヤフー社内には、高い開発生産性を維持するための Review Committee という活動があります。ここで集まった知見を、Weekly Report と称して毎週社内に共有しており、その一部を本ブログ上でも公開しています。（Weekly Report の詳細については、過去の記事一覧を参照してください） 確信的な質問 ある開発者が、以下の関数 getOnlineUserStates のコードレビューの依頼を受けた状況を想定しましょう。 fun getOnlineUserStates(userIds: Set<UserId>): Map<UserId, UserState> { if (userI
Amazonの推薦をいい感じにするブラウザ拡張Amaxというブラウザ拡張をリリースしました。会員登録など必要なく、もちろん無料で、ブラウザ拡張をインストールしていつも通り Amazon を使うだけでいい感じになります。手軽なのでぜひ使ってみてくださいね。 chromewebstore.google.com 私の専門は推薦システムで、特にユーザーサイドの推薦システムに力を入れて研究をしています（プロフィール）。このブラウザ拡張にはユーザーサイドの推薦システムの研究成果がふんだんに詰め込まれています。 本稿では、ブラウザ拡張の紹介のほか、開発の裏側やもとになった技術について詳しく説明します。 目次 目次 Amax の紹介 開発の裏側 ユーザーサイドの推薦システムについて おわりに 関連論文 Amax の紹介 ブラウザ拡張をインストールして、商品ページにアクセスすると、「Amax によるおすすめ
背景 システムを運用する中でAuroraのメトリクスで、Rollback Segment History List Lengthのメトリクスが急激に増加したことがありました。恥ずかしながらこのメトリクス自体を知らなかったので、このメトリクスは何者なのか、このメトリクスが増加すると何が発生するのかを調べたことを書いていきたいと思います。 Rollback Segment History List Length MySQLのストレージ領域で発行されるundoログの履歴数を示したメトリクスである。 undoログ MySQLのストレージエンジンであるInnoDBが発行するログの種類の一つです。他にはredoログなども存在します。有名どころのログであるslow queryやaudit logなどはストレージエンジンのログではありません。redoログについては下記記事が詳しいので、一読することをおすす
こんにちは。サーバーサイドエンジニアの @atolix_です。 今回はメドピアで運用しているアプリケーションのkakariの監査ログをDB管理からS3管理に移行したので、その方法と手順について紹介したいと思います。 kakari.medpeer.jp 背景 従来kakariではAuditedを用いて、監査ログを専用のauditsテーブルに保管する処理を行っていました。 github.com # application_record.rb class ApplicationRecord < ActiveRecord::Base ... include Auditable # auditable.rb module Auditable extend ActiveSupport::Concern included do audited ... end しかしレコードの変更の度にauditsテーブ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
