「“良くないコード”に腹を立てても意味はない」 新しい事業・新しいプロダクト・新しいコードに触れる時に意識したいこと
「初学者から上級者までが楽しめるWeb系の技術カンファレンス」をコアコンセプトに掲げる「Kaigi on Rails」。ここで登壇したのは、STORES株式会社CTO・藤村大介氏。別会社が自社にジョインしたことにより、新しく加わったプロダクトのRailsアプリケーションを触り改善する中で、見ていたこと・考えていたことなどを発表しました。全2回。後半は、既存Railsアプリに触れる時の心構えと、改善に向けて実際にやったことについて。前半はこちら。 「良くない」と思うコードに腹を立てても意味はない 藤村大介氏：既存Railsアプリに触る時の心構えと、新たに事業、プロダクト、コードなどをチームに受け入れる時、触れる時の心構えをお話ししようと思います。これは新しく会社に入る時や会社に新しいプロダクトがジョインする時に役に立つ話じゃないかなと思います。 1個目です。事業をやっていると、常にあらゆる状
フックに関するよくある質問 – React
この記事は古くなっており、今後更新されません。新しい React 日本語ドキュメントである ja.react.dev をご利用ください。 新しいドキュメントではフックを使って React が学べます。 フック (hook) は React 16.8 で追加された新機能です。state などの React の機能を、クラスを書かずに使えるようになります。 このページではフックに関するよくある質問にいくつかお答えします。 導入の指針 フックが使える React のバージョンはどれですか？ クラスコンポーネントを全部書き換える必要があるのですか？ クラスではできず、フックでできるようになることは何ですか？ これまでの React の知識はどの程度使えますか？ フック、クラスのいずれを使うべきですか、あるいはその両方でしょうか？ フックはクラスのユースケースのすべてをカバーしていますか？ フックは
OAuth認証とは何か?なぜダメなのか - 2020冬 - r-weblife
こんばんは。ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2020 1日めの記事です。 qiita.com 初日なのでゆるふわな話をしましょう。 何の話か もうだいぶ前ですね。9月のお話です。こんなTweetを見かけました。 社内Slackにいる「OAuth認証」と書くと訂正してくれるbotが丁寧な解説をするようになっていた 認証(Authentication)と認可(Authorization)は間違えやすいわりにミスると甚大な被害をもたらしがちなので、常日頃から意識を高めていきたいですね pic.twitter.com/oVQxBgZcHS— greenspa (@greenspa) 2020年9月28日 このbotに対する思うところはもう良いです。 今回は、「OAuthの仕様に沿ってID連携を実装するいわゆる"OAut
OAuth 2.0 クライアント認証 - Qiita
はじめに この記事では、OAuth 2.0 の『クライアント認証』について説明します。 RFC 6749 に記述されているクライアント認証方式のほか、クライアントアサーションやクライアント証明書を用いるクライアント認証方式についても説明します。 1. クライアント認証方式 1.1. トークンエンドポイント 認可サーバーがあります。 認可サーバーからアクセストークンの発行を受けたいクライアントアプリケーションがあります。 アクセストークンは、幾つかの例外を除き、認可サーバーのトークンエンドポイントから発行されます。そのため、認可サーバーはトークンエンドポイントを用意します。 クライアントアプリケーションは、アクセストークンの発行を受けるために、トークンエンドポイントにトークンリクエストを投げます。 認可サーバーは、トークンレスポンスを返します。この応答の中に、アクセストークンが含まれます。
OAuth 2.0 の Client Type についての考え方
ritou です。 OAuth 2.0 のクライアントの種類、いわゆる Client Type についての基本的なお話です。 よくある認識 仕様だと Public : ClientSecret を安全に管理できず、他の方法でもセキュアなクライアント認証ができないクライアント Confidential : ClientSecret を安全に管理できる、または他の方法でセキュアなクライアント認証ができるクライアント と書いてあり、実際の分類となると Webアプリ : Confidential モバイルアプリ、SPA、デスクトップアプリ : Public となります。 Webサーバーの内部など、ある程度アクセス制限のされた状態で管理されているが、SPAのソースコードやモバイルアプリのバイナリの解析とかによって取得しうるみたいなのは直感的かと思いますが、これだけだといろいろ迷う人がいるらしい、とい
Ruby の拡張ライブラリを、Rust を使ってお手軽に実装する - さんちゃのblog
magnus というcrate を利用すると、超簡単に Ruby の拡張ライブラリが実装できます。 具体的には、Rust 側の記述はこんな感じになります。 use magnus::{define_class, function, method, prelude::*, Error}; #[magnus::wrap(class = "Point")] struct Point { x: isize, y: isize, } impl Point { fn new(x: isize, y: isize) -> Self { Self { x, y } } fn x(&self) -> isize { self.x } fn y(&self) -> isize { self.y } fn distance(&self, other: &Point) -> f64 { (((other.x - s
Ruby gem で Rust をつかって爆速にしたい!!!!!!11
Ruby Gems で Rust が Native として利用可能になった のでとりあえず UUIDv4 を生成してみた。 リポジトリ 準備 Ruby 側の gem に Rust を利用する準備として rb_sys と rake-compiler を利用します。この二つの gem は native compile するためにインストールしておきます。 Rust 側から Ruby へ関数を公開するために rb-sys と magnus を利用します。 gem install とりあえず cargo で Rust のパッケージを作って Rust を書いてみます。 > bundle gem rust_uuid --mit --ext rust_uuid # --ext を指定してnative build する gem を作成 > cd rust_uuid # 作成した gem のディレクトリへ移
施策を "Own it" するエンジニア 〜オーナーエンジニア制度の紹介〜 - クックパッド開発者ブログ
レシピサービス開発部の新井（@SpicyCoffee66）です。いろんなゲームが好きなのでどれも中途半端にしか上手くならないことに 10 年以上悩んでいます。 この記事では、クックパッドのレシピサービス開発に導入している "オーナーエンジニア" と呼ばれる制度について紹介します。 クックパッドでサービス開発をしているエンジニアがどういう働き方をしているのか知りたい ディレクターやデザイナーと上手く協業する方法が知りたい サービス開発エンジニアはやることが多すぎてどうやって仕事をすればいいか悩んでいる といったような方の参考になると思いますので、興味があれば是非ご一読ください。 制度導入の背景 オーナーエンジニアという役割について述べる前に、まずはレシピサービスの開発を取り巻く環境について軽く解説します。 現在クックパッドのレシピサービスは、エンジニアが 10 名と少し、デザイナーが 5 名
AtCoder 版！蟻本 (中級編) - Qiita
0 はじめに 前回の初級編に続いて、今度は中級編です。 プログラミングコンテストチャレンジブック (通称、蟻本) は日本の競技プログラミングの普及に多大な貢献を果たしています。多くの競技プログラマたちが蟻本を手に取りながらコンテストの世界に没入して行きます。しかしながら発売から 6 年以上経過する間に競技プログラミング界隈には大きな変化がありました。蟻本的に影響が大きいのは以下の点です: POJ が国内ではあまり使用されなくなった (計算速度が遅いなど) AtCoder 上で問題を解くことが盛んになった 今回はこの完全解決を試みます。具体的には、蟻本に載っている例題たち (ほとんどすべて POJ 上の問題です) を AtCoder 上でジャッジできる問題に対応付けようという試みです。今回は中級編を扱います。AtCoder 上で見つからなかったものは AOJ, yukicoder 上の問題も
AtCoder 版！蟻本 (初級編) - Qiita
0 はじめに プログラミングコンテストチャレンジブック (通称、蟻本) は日本の競技プログラミングの普及に多大な貢献を果たしています。多くの競技プログラマたちが蟻本を手に取りながらコンテストの世界に没入して行きます。しかしながら発売から 6 年以上経過する間に競技プログラミング界隈には大きな変化がありました。蟻本的に影響が大きいのは以下の点です: POJ が国内ではあまり使用されなくなった (計算速度が遅いなど) AtCoder 上で問題を解くことが盛んになった 今回はこの完全解決を試みます。具体的には、蟻本に載っている例題たち (ほとんどすべて POJ 上の問題です) を AtCoder 上でジャッジできる問題に対応付けようという試みです。今回は初級編を扱い、中級編、上級編は別記事に続きます。AtCoder 上で見つからなかったものは AOJ, yukicoder 上の問題も載せています
コードでデザインをするということ｜Hiroki Tani
この記事は2022年12月10日開催のSpectrum Tokyo Design Fest 2022で話したセッションの内容を文字起こししたものです。 僕は15年ほどWebに関する業界で働いています。はじめは小さなベンチャーでWebデザイナーとして仕事をはじめ、自分でデザインして自分でコーディングするというキャリアからはじまりました。それからフロントエンドデベロッパー、UXエンジニア、デザインエンジニアと肩書を変えてきています。 その中で、CSS設計の書籍の執筆や、Figmaのプラグイン開発、デザインシステムのリードなどの活動をしてるんですが、基本的にはコードを書くことをメインにしつつも、デザインに近い領域で仕事をしてきています。 Code is a Material僕がデザインとコードの両方についての考えを巡らせるきっかけになったのは、2019年に観たデザインシステムのカンファレンスのい
エンジニアのスキルマップ・テックリードへの途 - 電通総研 テックブログ
みなさんこんにちは。電通国際情報サービス(ISID) 金融ソリューション事業部の水野です。 これは電通国際情報サービス Advent Calendar 2022の16日目の記事です。 今回は、ISID金融事業部で運用しているスキルマップについてご紹介します。 テックリードとは 実は、ISIDの少なくとも金融事業部にテックリードと言うポジションはありません。 実在するのはチーフアーキテクトと言う職種のみで、各プロジェクトでリードエンジニアやテックリードという仮想的なロールがあるのが実態です。 一時期はフルスタックエンジニアと呼んでいる時期もありましたが、近年このワーディングが好まれない印象なので、大々的に使っていません。 主観ですが、フルスタックエンジニアはインフラ知識／運用系の知識のウェイトが高いエンジニアで、テックリードはソフトウェアアーキテクチャ、Webアプリケーション実装技術寄りのエ
Four Keysがなぜ重要なのか - 開発チームのパフォーマンスを改善する方法について - yigarashiのブログ
ソフトウェアエンジニアとして働き始めて以来、ずっとソフトウェアデリバリーのパフォーマンスに興味を持って、さまざまな改善活動をしてきた。当初はスクラムを中心としたプロセスの改善に注力したが、最近はチームの成熟に伴って技術的なプラクティスに興味が移りつつある。より広い視点からデリバリーについて考えるのは非常に楽しい仕事だ。 デリバリーのパフォーマンスを改善していくには、定量指標として確立されたFour Keysを計測し改善するのが業界標準となりつつある。恥ずかしながら、私はこれまでこのFour Keysが腹落ちせず、積極的に計測してこなかった。しかし、多方面に興味が向いて知識や経験が蓄積するにつれて、猛烈にFour Keysの重要性が腹落ちしてきた。この記事では、現時点における自分のFour Keysに関する理解と解釈を整理してみようと思う。 Four Keysとは Four Keysの妥当性
技術的負債じゃなく、もはや技術的不良債権
何番煎じか分かりませんがバズワードについて怪文書を書きます。 自分の思考の整理でしかありません （技術的）負債の誤用 技術的負債という言葉を多くの日本人はまちがって使っているらしい（要出典）。 本来的な意味はこちらであった https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor 自分なりに解釈すると。 簡単に言えば、元々の意味は、場当たり的なコードのことではなく不完全なものをインクリメンタルにブラッシュアップして開発すること。 その不完全さを一時的に許容することを負債と呼んでいた。返済も必要だとのこと。 なるほど、負債ってそういうものか。技術的負債に関して、元々の会計上の負債という考え方に沿って元銀行員の方が考えたのが面白かった。 https://zenn.dev/ikeo/articles/33e3e6a0905577
Web フロントエンドにおけるコロケーション (co-location) という考え方について - mizdra's blog
Webフロントエンド界隈の文献などにあたっていると、「コロケーション (co-location)」という考え方が時々登場します。 コロケーションを簡単に説明すると、関連するリソース同士を近くに置いておく、という考え方です。 FooComponent.tsx と同じディレクトリに FooComponent.test.tsx を置く GraphQL fragment は、クエリを発行するコンポーネントファイル (pages/user.tsx) ではなく、fragment を利用するコンポーネントファイル (components/UserInfo.tsx) の中で定義する pages/user.tsx からはサブコンポーネントのファイルで定義されている fragment を import してきて、クエリを組み立てて発行する API ドキュメントは API.md に書くのではなく、コードの中にド
npm-scripts を書く時の手癖 - mizdra's blog
かれこれ 5 年くらい趣味開発で npm-scripts を書き続けている。長年書き続けているとノウハウが蓄積されてきて、「こう書くとスッキリする」「迷いがなくなる」「後から拡張したくなった時に、簡単に拡張できる」みたいな書き方が身についてきた。自分の型、あるいは手癖のようなものだと思う。 せっかくなので、id:mizdra の今の npm-scripts を書く時の手癖を書き連ねてみる。 基本形 { "scripts": { "build": "webpack --mode production", "dev": "webpack-dev-server --mode development", "lint": "eslint .", "test": "jest" } } 一番シンプルな npm-scripts を書く時のパターン。以下の 4 つの script を登録している。 buil
あなたはDRY原則を誤認している？ - Qiita
DRY原則。 WebフレームワークRuby on Railsが基本理念のひとつとして採用している有名なソフトウェア開発原則です。素晴らしい原則なのですが、最近Railsを始めた人や新卒のエンジニアさんなど、DRY原則を誤認してしまう人が非常に多い為、DRY原則に関する説明をQiitaにまとめておくことにします。 よくある間違った認識 DRY原則を誤認しているとはどういうことなのか？最も多いのが「DRYとはコードを重複させないという意味である」と認識しているケースです。当然、コードを重複させないという部分もDRYの一部ではあるのですが、これではソースコードだけに着目しているので、OAOO(Once And Only Once)原則に近い考え方になってしまいます。 OAOOとは何か 厳密な定義を書かないと斧が飛んできそうですが、長文になってしまうのであえて一言で説明すると、「コードを重複させな
MediaPipe Solutions guide | Google AI Edge | Google AI for Developers
Send feedback MediaPipe Solutions guide Stay organized with collections Save and categorize content based on your preferences. MediaPipe Solutions provides a suite of libraries and tools for you to quickly apply artificial intelligence (AI) and machine learning (ML) techniques in your applications. You can plug these solutions into your applications immediately, customize them to your needs, and u
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NatML for Unity | Unity
GitHub - kt3k/remarker: :arrow_forward: Remark cli
