タグ

celt69cobraのブックマーク (8,579)

  • 技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience

    2022-12-21 技術的負債の返済から改善する開発者体験 - Techmee vol.5 https://timeedev.connpass.com/event/268296/ 動画 https://youtu.be/tQ3BGgnvMwQ

    技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience
  • ローカル環境を汚さずDockerコンテナのオーバーヘッドもなく、開発環境を自在に構築できる「Devbox 0.2.0」登場

    ローカル環境を汚さずDockerコンテナのオーバーヘッドもなく、開発環境を自在に構築できる「Devbox 0.2.0」登場 Dockerコンテナの技術を用いることで、プログラミング言語のランタイムやライブラリ、ミドルウェアなどの開発環境一式を比較的容易に導入することが可能になりました。 ただしDockerコンテナにもファイルシステムのオーバーヘッドなどがあり、Dockerコンテナ内の開発環境ではコンパイルなどに時間がかかってしまう場合があったと開発ツールベンダのJetpack Technologiesは自社の経験から指摘します。 そこで同社がオープンソースで開発しているのが「Devbox」です(ちなみにマイクロソフトによる仮想化された開発環境の「Dev box」とは名前は似ていますが別のものです)。 Devboxは、ローカル環境上に分離した環境を用意しそこで開発環境を構築可能にしつつ、Do

    ローカル環境を汚さずDockerコンテナのオーバーヘッドもなく、開発環境を自在に構築できる「Devbox 0.2.0」登場
  • スクラムチームの成果を最大化させた7つの改善 ~ 新米リーダーの挑戦 ~

    ログラスエンジニアの村です。 この記事では、ログラスのスクラムチームで取り組んだ改善事例をご紹介しようと思います。 改善事例を紹介しようと思ったキッカケは、2022年8月から私の所属チームのチームリーダーがEMに昇格し、私がチームリーダーになったことです。 チームリーダーになったことで、これまであまり意識してこなかったチームの成果を最大化する方法を考える機会が生まれました。 そして様々な改善アプローチをスピード感を持って試すことで、効果を実感できた改善もいくつか生まれ、チームがどんどん良くなっていくという素晴らしい経験ができました。 この記事では、効果を実感できた改善の中で特に印象的だった7つをご紹介しようと思います。 この記事を通して、スクラムをやりたいと考えている方や、スクラム開発をやっていて課題感を感じている方、ログラスに少しでもご興味がある方のご参考になれば幸いです。 2022

    スクラムチームの成果を最大化させた7つの改善 ~ 新米リーダーの挑戦 ~
  • 勉強2022

    毎朝6時間勉強し、その様子を配信している。 https://www.youtube.com/c/r7kamura 勉強に寄与したと感じる習慣を挙げる。 午前中に行う ポモドーロ法に従う 外音を遮断する 通知を切る 環境を整える 水を飲む 計画的に休憩する 運動する 考えを書いてまとめる 成果を共有する 誰かと一緒にやる 仕組み化する 良くなかったのでやめた習慣を挙げる。 毎日9時間勉強する 長時間運動する 何度も運動する 休憩時間にマイクで話す 無音で勉強する 学んだすべてを書き留める メモ書きを共有する 睡眠の習慣については『早起き2022』という記事でも触れた。

  • 近似最近傍探索の最前線

    MIRU 2019 チュートリアル http://cvim.ipsj.or.jp/MIRU2019/index.php?id=tutorial 松井 勇佑(東京大学生産技術研究所)http://yusukematsui.me/index_jp.html ベクトルの集合を前にして新たにクエリベ…

    近似最近傍探索の最前線
  • git push -f が更に安全になる --force-if-includes - id:onk のはてなブログ

    歴史改変、してますか? 私は歴史改変が大好きで、毎日 rebase しています。なので割と毎日 git push -f することになっています。 口で -f と言っても、実際には --force-with-lease --force-if-includes をしているので、これらのオプションのご紹介。 この記事は はてなエンジニア Advent Calendar 2022 の 18 日目です。昨日は id:rokoucha さんで 壊れたデータベースとの向きあいかた - rokoucha でした。 qiita.com -f の危険性 ...--F--G--H <-- main という状態で push した後、H をコミットし直したとしよう。 ...--F--G--H' <-- main \ H <-- origin/main このまま H' (main) を origin/main に p

    git push -f が更に安全になる --force-if-includes - id:onk のはてなブログ
  • 1年間本番運用してわかった、スタートアップこそAWS Copilot CLIを使うべきNつの理由

    AWS Startup Community Conference 2022 の登壇資料です。

    1年間本番運用してわかった、スタートアップこそAWS Copilot CLIを使うべきNつの理由
  • UIから「白」が消える日|ritar

    これは designing plus nine Advent Calendar 19日目の記事です。 こんにちは。ritarと申します。 今年の10月頃、YouTubeに大きいデザイン変更がありました。 アイコンの変更、角丸やレイアウトなど全体的に一新されているのですが、中でも自分が仰天したのは「アンビエントモード」という新機能です。 アンビエントモードこのモードをオンにすると、動画の下側のUI領域が、まるで動画部分から光が漏れているかのようにじんわりと色づきます。 これを見たとき自分は度肝を抜かれました。なんたってUIの領域にコンテンツの色が侵しているのです。 これを踏まえて、最近UIと色について考えたことを、UIデザインの歴史を振り返りながら記していきます。先に要点を言うと、UIはどんどん「無色透明」になっていくと考えます。これは「技術が生活に浸透することによってUIは存在感を減らし

    UIから「白」が消える日|ritar
  • SWR 2.0 の発表 – SWR

    日、SWR 2.0 のリリースを発表できることに興奮しています!この新しいバージョンには、新しいミューテーション API や楽観的更新パターンに対する改善、DevTools、React の並行処理機能のサポートといった多くの改善と新しい機能が含まれています。このリリースを可能にしてくれた全てのコントリビュータとメンテナに感謝しています。 ミューテーションと楽観的 UI 更新 useSWRMutation ミューテーションはデータフェッチングの重要な要素の一つです。ミューテーションはローカルとリモートのデータそれぞれの更新を可能にします。既存の mutate API は、リソースの再検証及び手動による更新をサポートしています。SWR 2.0 では、useSWRMutation という新しいフックは宣言的な API でよりシンプルにリモートのデータ更新を可能にします。このフックを使いミューテ

    SWR 2.0 の発表 – SWR
  • Railsでやってしまいがちな保守性を下げてしまうコードとその解決策 - Qiita

    こんにちは。COUNTERWORKSアドベントカレンダー13日目担当の疋田です。 先月からエンジニアとしてJOINしました。現在、業務ではshopcounterというサービスのRailsアプリケーション開発や日々の運用、データ集計や分析を元にしたプロダクトの改善などをメインで行っています。 スタートアップのエンジニアを経験していく中で、常に素早くPDCA回してユーザからのフィードバックをプロダクトに反映することが重要になってくるため、エンジニアとしてはコードの変更のしやすさとか捨てやすさ、読みやすさってかなり重要だなーと改めて強く思ってます。 今回は3年くらいRailsやってきた中でちょっとずつ溜まってきたメンテするときこういうコード辛かったなって部分を共有できたらなと思います。 ちなみに、これらはすべて今までの自分自身もやっていた時期があるコードであり、反省の意味も込めて書いてみます。

    Railsでやってしまいがちな保守性を下げてしまうコードとその解決策 - Qiita
  • 何を、なぜ、どのように

    何を、なぜ、どのように #WebRTCとは? #WebRTC とは、Web Real-Time Communication の略で、API であると同時にプロトコルでもあります。WebRTC プロトコルは、2 つの WebRTC エージェントが双方向の安全なリアルタイム通信をネゴシエートするための一連のルールです。WebRTC API は、開発者が WebRTC プロトコルを使用するためのものです。WebRTC API は、JavaScript のみで規定されています。 似たような関係として、HTTP と fetch API があります。プロトコルとしての WebRTC が HTTP で、API としての WebRTC が fetch API となります。 WebRTC プロトコルは、JavaScript 以外の API/言語でも利用可能です。また、WebRTC 用のサーバーやドメイン固有

  • RSA署名を正しく理解する

    初めに 「署名とはメッセージのハッシュ値を秘密鍵で暗号化したものであり、検証は署名を公開鍵で復号してハッシュ値と等しいかを確認することである」という説明(×)をよく見かけます。 正しい署名の定義と実際のRSA署名がどのようなものであり、上記説明(×)がなぜよくないのかを理解しましょう。 署名の定義 署名の解説は署名の概要でも解説しましたが、再掲します。 署名(方式)は鍵生成(KeyGen)、署名(Sign)、検証(Verify)の3個のアルゴリズムからなります。 KeyGenではアリスが署名鍵sと検証鍵Sを生成します。署名鍵sは自分だけの秘密の値なので秘密鍵、検証鍵Sは他人に渡して使ってもらう鍵なので公開鍵ともいいます。 Signは署名したいデータmに対して署名鍵sを使って署名と呼ばれるデータσを作ります。 データmと署名σのペアを他人(ボブ)に渡します。 Verifyはボブが検証鍵Sを使

    RSA署名を正しく理解する
  • GraphQL Client Architecture Recommendation 社外版 | メルカリエンジニアリング

    この記事は、Merpay Advent Calendar 2022 の15日目の記事です。 こんにちは。メルペイのvvakameです。 最近、社内向けにGraphQL Client Architecture Recommendationというドキュメントを書きました。社内のiOS/Android、そしてバックエンドのエンジニア向けにGraphQLをやるならこの辺りの条件を満たしておかないと恩恵を感じられなくなっちゃうかもよ、と伝えるためのものです。嬉しいことに、今までに100名弱の人たちがこのドキュメントを閲覧してくれたようです。 これをAdvent Calendarで公開するために、ちょっと調整したものがこの社外版です。 すでにGraphQLをやっているけどあまり便利じゃないな…なんでだろ?とか、これから導入したいんだけど何を気をつけるべきかな…と考える時の材料にしてください。 併せて、

    GraphQL Client Architecture Recommendation 社外版 | メルカリエンジニアリング
  • Firebase Test Labで動かしていたiOSのE2Eテストを実機で動かして安定化させたら開発者の喜びが爆上がりした話 - Uzabase for Engineers

    記事は、NewsPicks Advent Calendar 2022 の 12/14 公開分の記事になります。 こんにちは。NewsPicks SREチームの 海老澤 です。 今回は iOSのE2Eテストを実機で動かす上でのインフラ周りの設定方法を紹介しようと思います。 課題 構成図 詳細 cdk Mac側の処理 結果 課題 NewsPicksではサーバーリリース時に Firebase Test Labで iOSのE2Eテストを実行していました。 Firebase Test Labは時間帯(夕方くらいになると混んでくる傾向)によってはテスト開始が遅い場合があり、リリースサイクルを高速化するために実機iPhoneでの安定したE2Eテストの実行に取り組みました。 構成図 構成図は以下です。 まずリリース時にAWS Step Functionsから SQSにメッセージを送信し、S3のテスト結果

    Firebase Test Labで動かしていたiOSのE2Eテストを実機で動かして安定化させたら開発者の喜びが爆上がりした話 - Uzabase for Engineers
  • Clean Agileを読みました|食べログ フロントエンドエンジニアブログ

    こんにちは。べログのフロントエンドチーム の荒川です。 先日、「Clean Agile 基に立ち戻れ」を読みました。 日はこのの要約を、私たちのチームの活動を交えてご紹介しようと思います。 著者の Robert C. Martin氏は、アジャイルマニュフェストの創案者の一人で、 国際的なソフトウェアコンサルティング、スキル開発を行っています。 https://agilemanifesto.org/iso/ja/manifesto.html 1章 アジャイル入門 アジャイル歴史 アジャイル歴史は5万年以上前、人間同士が協力して、共通の目標を達成しようとしたことが始まりと述べています。ソフトウェア開発においては、アラン・チューリングがチューリングマシンの論文を執筆した1936年の当時や、1946年にACE(Automatic Computing Engine)のために書いた最初のコ

    Clean Agileを読みました|食べログ フロントエンドエンジニアブログ
  • RustでOSを書いた

    はじめに RISC-V CPUFPGA 上に実装して、マイクロカーネル OS を Rust で書いて動かしてみました。 CPU について RISC-VとChiselで学ぶ はじめてのCPU自作 に沿って RISC-VCPU を作り、機能をエンハンスしました。 乗除算命令、RVC命令、ビット拡張命令の一部を追加 7段パイプライン化 DRAM コントローラ 4KB命令キャッシュ、8KBデータキャッシュ 2ビット分岐予測 周辺コントローラ実装(SDC、UART、タイマー、割込コントローラ) Arty A7-35T という FPGA ボード上で動作させています。 スーパーバイザーモードは実装していないので、仮想メモリは使えません。みんなで仲良くメモリを共有します。 CPU の実装はこちらに置いてあります。書籍のサポートリポジトリの fpga 実装版を fork して機能追加しています。

    RustでOSを書いた
  • SmartHRのOSSガイドラインを公開しました - SmartHR Tech Blog

    こんにちは、エンジニアのkinoppydです。日は、SmartHRが公開したOSSガイドラインに関してご紹介します。 github.com SmartHR OSS ガイドライン SmartHRでは、すべてのサービスでOSSが使用されています。RubyRuby on RailsReactTypeScriptは必ずすべてのサービスで使われていますし、その他にもたくさんのOSSがSmartHRのサービスを構成しています。これらOSSによってSmartHRのサービスは支えられているので、我々もOSSに対してなにか貢献をすることができると良いなと思っています。しかし、現在社内には業務時間中のOSS活動に関する明示的な文章が存在せず、業務としてOSSにコミットする労務/法務的なルールが不明でした。また、OSS文化に対する経験が浅い人にとっては貢献する方法などもよくわからず、ハードルが高いと感じ

    SmartHRのOSSガイドラインを公開しました - SmartHR Tech Blog
  • Engineering Managerを廃止して1年経ちました - Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)

    こんにちは、ゆのん(id:yunon_phys)です。このエントリーはAkatsuki Games Advent Calendar 2022の14日目の記事です。昨日はMaxBaconPowerさんの「巨大数でわかる Elixir の魅力」でした。Elixirが再帰が得意とはいえ、良くこんな題材を思いついたなと感心しました。早くふぃっしゅ数を見てみたいものです。 さて題に入るわけですが、昨年、Engineering Manager(EM)を廃止して3つに分割したという話を書きました。そこから1年経ち、どのような状態になったのか、ふりかえりも含めて書いていきます。記事は前回の記事を読まなくても読めるようにしていますが、更に背景理解したい方は前回の記事も読んでみてください。 hackerslab.aktsk.jp ずばりEMを無くして良かったのか これはマクロに見ると明確に良かったと思って

    Engineering Managerを廃止して1年経ちました - Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)
  • GraphQL の Fragment Colocation を導入したら依存関係がスッキリしてクエリもコンポーネントも書きやすくなった

    この記事は Money Forward Engineering 1 Advent Calendar 2022 11 日目の投稿です 🎄 昨日 10 日目は cabossoldir さんによる 『コードレビューのとき、私は何をレビューしているのか?』 でした。 🙈 TL;DR Fragment Colocation とは、コンポーネントが必要とするデータを Fragment にまとめてコンポーネントと同じ場所に配置 (co-locate) すること Fragment Colocation を導入することで、「Query や Mutation を実行するコンポーネント」と、「それらの結果を必要とするコンポーネント」との関心の分離ができる Query, Mutation, Fragment はそれを実行するあるいは必要とするコンポーネントと同じファイル内に宣言すると依存関係が見やすく、変更が

    GraphQL の Fragment Colocation を導入したら依存関係がスッキリしてクエリもコンポーネントも書きやすくなった
  • vim-lspでできること - Qiita

    最近になってようやくlspを使い始めたのですが、結局補完とエラー取得と定義ジャンプしかしていないなーと思ったので、他にどんな事ができるのかを調べて見ました。 設定方法等はvim-lspのREADMEやWikiを見たら行けるかと思います。 また、最近ではmattn/vim-lsp-settingsというプラグインが作成され、LSPの面倒くさい設定を書かなくてもローカルに自動でLSをインストールしてくれるようになりました。 もし面倒くさくてインストールしていないという方がいれば、試してみることをおすすめします。 基的にはヘルプで確認すればいいんですが、僕のLSPに対する知識のなさと英語力のなさで結構わからない事があったのでメモがわりに書きます。 ※ この記事は定期的に便利なコマンドに気づいたときに加筆したりしています。なので古い情報と新しい情報が混ざっていることがあるので注意ください。 基

    vim-lspでできること - Qiita