タグ

ブックマーク / tech.uzabase.com (10)

  • プログラミングの原則:enumの比較はすべてバグ - Uzabase for Engineers

    こんにちは、ソーシャル経済メディア「NewsPicks」のむとうです。 この記事は NewsPicks アドベントカレンダー 2023 の3日目の記事です。 昨日は@J_Nakagawa(隼佑 中川)さんによる『LambdaレスポンスストリーミングとAWS-SDKを使ってSlackに進捗バーを表示させる』でした! 世の中には再現が難しく一見してバグがありそうに思えないコードもありますが、一方でプロダクションコードの中にはひと目見てバグが有りそうなコードもまた多いものです。いくつかの特定のパターンをとる文字列(環境名など)やenum(以下どちらもenumと表現します)に関する条件分岐もその一つです。プルリクを見てこのようなパターンがあれば、バグの疑いが強くなります。周囲を見渡すと、大抵すでにバグっているか潜在バグを含むコードが見つかります。すべてバグというのは言い過ぎにせよ、わかりやすさと変

    プログラミングの原則:enumの比較はすべてバグ - Uzabase for Engineers
  • プロダクト開発組織のチームビジョンを作ったらすごいパワーが生まれた話 - Uzabase for Engineers

    こんにちは。NewsPicks プロダクトチームの文字です。今日はプロダクト開発組織のチームビジョンを作ったら、すごいパワーが生まれた話をさせて頂きます。 「経済を、技術でもっとおもしろく。」 今年の春、NewsPicks のプロダクトチームでは、こんなチームビジョンを作りました。実は NewsPicks のタグラインは「経済を、もっとおもしろく。」なので、会社の掲げるタグラインをほぼ踏襲しているように見えます。しかし一見凡庸なこのビジョンが、実はとても大きなパワーを秘めていたのです。 1/ なぜビジョンをつくったのか 増大し続ける技術的負債と運用負荷 組織の急拡大 2/ みんなでビジョンをつくる 合宿の開催 腹落ちできるビジョンが完成 3/ ビジョンをつくったら、どうなったのか? ビジョンはパワー 4/ これからのプロダクトチーム 1/ なぜビジョンをつくったのか そもそも、何故こんなチ

    プロダクト開発組織のチームビジョンを作ったらすごいパワーが生まれた話 - Uzabase for Engineers
  • NewsPicksにCTOとして入社して1年でDX Criteriaを大幅改善した話 - Uzabase for Engineers

    こんにちは。このブログでは初めまして。2020年の2月にNewsPicksに入社した高山です。 今回は僕がNewsPicksのCTOになってからの1年でやったお仕事について書いていきます。 CTO最初のミッション DX Criteriaについて 「デプロイ回数」を定点観測 やってきたチャレンジ 1年経ってみて CTO最初のミッション NewsPicksは2013年に誕生し、5年ほどの壮大な創業期の間にたくさんの新しい領域に挑戦しており、僕が入社したときには既に事業面でもシステム面でも「それなりの複雑さ」という感じでした。 前任CTOの杉浦さん(今はグループ内でアメリカでの新規サービスの立ち上げをしています)からバトンを受け取って最初のミッションが「DX Criteriaを上げること」だと聞いたときにそのあたりの事情を全て察しました。😅 結論から先に書くと、1年で大幅改善を達成することがで

    NewsPicksにCTOとして入社して1年でDX Criteriaを大幅改善した話 - Uzabase for Engineers
  • ペアプログラミングはXPの5つの価値をエクストリームにする - Uzabase for Engineers

    SaaS Product Team の野口です。 以前にもいくつかの記事で触れたように、SaaS Product Team では XP(エクストリーム・プログラミング)をベースとしたチーム開発に取り組んでおり、ほぼ全ての作業をペアで行っています。*1 かく言う私もこのチームに入ってから 1 年以上の間 *2、日々ペアプログラミングに取り組む中でわかってきたことがあるので、この記事で共有したいと思います。 XP はうまくいくことを極限(エクストリーム)まで推し進めることから生まれた ペアプログラミングは XP の 5 つの価値を極限まで推し進める 注記 コミュニケーション シンプリシティ フィードバック 勇気 リスペクト 旅は続く 一緒にペアプログラミングと XP を探求しませんか? XP はうまくいくことを極限(エクストリーム)まで推し進めることから生まれた Kent Beck の『エクス

    ペアプログラミングはXPの5つの価値をエクストリームにする - Uzabase for Engineers
  • Kubernetes で運用する JVM アプリケーションの OutOfMemoryError に備える - Uzabase for Engineers

    こんにちは。SPEEDA 開発チームの old_horizon です。 JVM アプリケーションの運用について回るのが、OutOfMemoryError (以下 OOM) への対処です。 しかし実際に発生した際に、適切なオペレーションを行うのは意外と難しいのではないでしょうか。 特に番環境では、まず再起動して復旧を急ぐことも多いかと思います。しかし、ただそれを繰り返すばかりでは原因がいつまでも特定できません。 今回は Kubernetes で運用する JVM アプリケーションに対して、ダウンタイムを抑えつつ調査に役立つ情報を自動的に収集する仕組みを構築してみたいと思います。 環境構築 OOM 発生時に、自動的にヒープダンプを取得しコンテナを再起動する java コマンドのオプション指定 補足 ヒープダンプ出力先のボリュームをマウント readinessProbe によるヘルスチェック レ

    Kubernetes で運用する JVM アプリケーションの OutOfMemoryError に備える - Uzabase for Engineers
  • 方法より原理 〜正規化ルールとリレーショナルモデルについて〜 【理屈編】 - Uzabase for Engineers

    今日は。 SPEEDA を開発している濱口です。 アプリケーションデータの永続化を担うデータストアには様々な選択肢があります。 その1つとして、リレーショナルデータベース(以下、RDB)がありますが、 RDBを選択した場合、データの容れものとしてリレーショナルモデルを選択した、という表明になります。 ひいては、このモデルを正しく使用することが生産性の観点から必要となります。 (明白な設計によるコミュニケーションや制約によるデータ不整合の回避など) その方法の1つとして正規化ルールがあります。 正規化ルール遵守は有効か 「あたりまえ」と軽視されがち 「設計時のみに発生するタスク」という誤解 正規化ルールを忘れ、モデルに導かれて、正規化ルールに至る リレーショナルモデルとは この続き 正規化ルール遵守は有効か あの星野源さんも知っているはずという、正規化ルールですが、基情報技術者の試験範囲で

    方法より原理 〜正規化ルールとリレーショナルモデルについて〜 【理屈編】 - Uzabase for Engineers
  • Smalltalkで『テスト駆動開発』の「第I部 多国通貨」をハンズオンしたら快適で楽しかった - Uzabase for Engineers

    今日は。 SPEEDAの開発をやっている濱口です。 SPEEDA開発チームではテスト駆動開発(TDD)、ペアプログラミングを徹底しています。 だからなのか、『テスト駆動開発』はすごく楽しく読めました。 今回ハンズオンを行った「第I部 多国通貨」でも、ペアプロをしながら著者が語りかけてくるような感じで、 読者側も、著者の意図をひとつずつ理解しながら読み進めていけるようになっています。 有意義なハンズオンを、より有意義にしたい 古くてあたらしい言語(環境)、Smalltalkにふれたい Smalltalkでは、わりと忠実な写経が可能だった Javaのコンストラクタのような特別なメソッドが無い インスタンス変数のスコープと意図を伝えるためのプロトコル 型が無い(untyped) 有意義なハンズオンを、より有意義にしたい ただ、そうは言っても、 読むだけよりも手を動かしたほうがよいと思いますし、

    Smalltalkで『テスト駆動開発』の「第I部 多国通貨」をハンズオンしたら快適で楽しかった - Uzabase for Engineers
  • ReactとReactHooksを使って、Flux的なアーキテクチャを実現する - Uzabase for Engineers

    こんにちは。SPEEDA開発チームの冨田です。 昨今のフロントエンドでは、Fluxというアーキテクチャが利用されることが多くなってきています。SPEEDAでもVueを使っている画面がありますが、そこではVuexというVue向けのFluxライブラリで状態管理をしています。 Fluxではデータの流れを一方向にすることで見通しのよい設計が行えるようになります。 今回は、素のReactを使ってデータの流れを単一方向にする設計を紹介します。 今回作ってみるもの セットアップ 1. GettersとActionsをつくる 2. GettersとActionsをどこのコンポーネントからでもアクセスできるようにする 3. Todoを表示するコンポーネントを作る 4. アプリコンポーネントを作る 5. テストを書く 今回作ってみるもの Todoアプリを作ってみましょう。 以下のようなことができる画面を作りま

    ReactとReactHooksを使って、Flux的なアーキテクチャを実現する - Uzabase for Engineers
  • ペアプロと育休の取得しやすさの関係について - Uzabase for Engineers

    こんにちは。SPEEDA開発チームの鈴木です。 昨年一児(娘)の父になりまして、凄い勢いで変化していく様子に喜んだり困ったりしながら過ごしております。 色々できることが増えると嬉しいのですが、それは同時にいたずらの幅が広がることも意味するんですよね。例えばものを引っ張ることを覚えたのは嬉しいのですが、私の髪の毛をひっぱってむしるのはやめていただきたい。そんな感じです。 髪をむしる娘の図。言葉は通じない。 今回はそんなうちの子が産まれたときに取得した育休の話をしたいと思います。 育休の話とはいっても育休をハックする話とか育児アプリとかの話ではなく、「育休を取得しやすい(と私は思う)SPEEDA開発チームの環境」についての話をします。 編がそこそこ長い(スミマセン)ので前置きはここら辺で切り上げることとします。 男性の育休取得率 男性が育休を取らなかった理由 育休を取らなかった理由の原因を考

    ペアプロと育休の取得しやすさの関係について - Uzabase for Engineers
  • 【k8s合宿】 Kubernetesのログ分析環境を作る - Uzabase for Engineers

    こんにちは、SPEEDAのSREチームでエンジニアをしている阿南です。SPEEDAのSREチームでは、昨年末kubernetesについて理解を深めるために合宿を行いました。やり方はA〜Cの3チームに分けて、それぞれのチームでkubernetesに関することを調査、構築するという形式で、今回はAチームが実際にやってみた内容についてブログを書きたいと思います。(それぞれのチームでかなりボリュームがあるので、複数回に渡って連載的な形でお届けしたいと思います。) Aチームでは、kubernetes番環境に投入するにあたり、ログ収集周りをあまり調査できてないなと感じ、GCP上に環境を作ってみることにしました。 構築する環境 構築手順 クラスター構築 wordpress + MySQL構築 Fluentdイメージの作成 ConfigMap設定 DaemonSet設定 まとめ お知らせ 構築する環境

    【k8s合宿】 Kubernetesのログ分析環境を作る - Uzabase for Engineers
  • 1