AtCoder 版！蟻本 (初級編) - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 0 はじめに プログラミングコンテストチャレンジブック (通称、蟻本) は日本の競技プログラミングの普及に多大な貢献を果たしています。多くの競技プログラマたちが蟻本を手に取りながらコンテストの世界に没入して行きます。しかしながら発売から 6 年以上経過する間に競技プログラミング界隈には大きな変化がありました。蟻本的に影響が大きいのは以下の点です: POJ が国内ではあまり使用されなくなった (計算速度が遅いなど) AtCoder 上で問題を解くことが盛んになった 今回はこの完全解決を試みます。具体的には、蟻本に載っている例題たち (ほと
コードでデザインをするということ｜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
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? DRY原則。 WebフレームワークRuby on Railsが基本理念のひとつとして採用している有名なソフトウェア開発原則です。素晴らしい原則なのですが、最近Railsを始めた人や新卒のエンジニアさんなど、DRY原則を誤認してしまう人が非常に多い為、DRY原則に関する説明をQiitaにまとめておくことにします。 よくある間違った認識 DRY原則を誤認しているとはどういうことなのか？最も多いのが「DRYとはコードを重複させないという意味である」と認識しているケースです。当然、コードを重複させないという部分もDRYの一部ではあるのですが、こ
MediaPipe Solutions guide | Google AI Edge | Google AI for Developers
Get started You can get started with MediaPipe Solutions by selecting any of the tasks listed in the left navigation tree, including vision, text, and audio tasks. If you need help setting up a development environment for use with MediaPipe Tasks, check out the setup guides for Android, web apps, and Python. Legacy solutions We have ended support for the MediaPipe Legacy Solutions listed below as
Conventional Commits
Conventional Commits 人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様 Conventional Commits 1.0.0 概要 Conventional Commits の仕様はコミットメッセージのための軽量の規約です。 明示的なコミット履歴を作成するための簡単なルールを提供します。この規則に従うことで自動化ツールの導入を簡単にします。 コミットメッセージで機能追加・修正・破壊的変更などを説明することで、この規約は SemVer と協調動作します。 コミットメッセージは次のような形にする必要があります: 原文： <type>[optional scope]: <description> [optional body] [optional footer(s)] 訳： <型>[任意 スコープ]: <タイトル> [任意 本文] [任意 フッター] あな
Next.js + NestJS + GraphQLで変化に追従するフロントエンドへ 〜 ショッピングクーポンの事例紹介
今回は、fragmentを活用するためにパターンCを採用しており、厳密には、以下のように方針を定めています。 SSR時のクエリ発行: ページコンポーネント単位 CSR時のクエリ発行: CSRが必要なコンポーネント単位 この際、取得したqueryの結果をどのようにfragmentへ変換するかというのがポイントです。 そこで、graphql-anywhereの filter メソッドを用いることで、クエリ結果をfragmentへ変換します。 以下は、簡略化されたクーポンページの実装例です。 type DetailPageProps = { // GraphQLクエリの結果 data: Query } const DetailPage: FunctionComponent<DetailPageProps> = ({ data }) => { // couponはGraphQLのCouponスキー
How I/we got 2k stars - ゆーすけべー日記
Honoという僕が作っているWebフレームワークのGitHubスター数が2,000に迫ってきた。これまで作ってきたOSSのソフトウェアでは最高で revealgo の221、次点で gh-markdown-preview の134だ。それが一気に2,000である。 もちろん、スターの数がソフトウェアの良し悪しを決めるものではない。 それに2,000はとりわけ多いわけではない。 でも、以前の自分には遥か彼方に見えていた数を獲得できたのは、とても嬉しいことだ。 去年12月から作り始めて9ヶ月間、552コミット。 今や使ってくれる人も増えた。 cdnjs のAPI Serverのバックエンドにも使われているし、 HonoをきっかけにGitHubスポンサーをしてくれている企業や人も現れている。 なにより、いろんなことを勉強させてもらった。 今回はHonoというプロダクトがどうやって2,000のスタ
フロントエンドのテストコードを書くときに大切にしていること - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、フロントエンドエキスパートチームの @mugi_unoです！ kintone では フロントエンドの刷新プロジェクト（通称フロリア）が進行中です。 blog.cybozu.io kintone の開発では E2E 主体の自動テストを整備していましたが、 フロントエンドの刷新に合わせて、新たにフロントエンド側でのテストコードを積極的に書いています。 テストを書くことに不慣れなメンバーもいるため、日々 Pull Request 上でのレビューやペア・モブ作業を通じて、知見の共有が行われています。今回はフロントエンド刷新のテストを書いてきた中から、筆者が有用だと感じた知見やノウハウを紹介したいと思います。 目次 💡「実はそれ最初からパスしてるかもしれない」 期待する操作で期待する結果になることを厳密に検証する 他のテストケースによって前提条件を担保する 💡「テストコード上のロジッ
2016年だけどMakefileを使ってみる - Qiita
この資料はなに？ Makeの良さを伝えるものです CとかC++の持ち物じゃない 普段使うコマンドのショートカットみたいな 2016年でもMakefileは便利 頑張らないでScala 〜VOYAGE GROUPにおけるアドネットワーク開発の戦略〜 // Speaker Deck Makeってなに？Makefile??? make(メイク)は、プログラムのビルド作業を自動化するツール。コンパイル、リンク、インストール等のルールを記述したテキストファイル (makefile) に従って、これらの作業を自動的に行う。 出典：https://ja.wikipedia.org/wiki/Make つまり、自動化のためのツール。 make が生成するのはふつう C のプログラムだが、べつに C のプログラムに限らず、Makefile に書く生成コマンドの書きように よっては、TeX のファイルだろうが
RailsDiff
The page navigation is complete. You may now navigate the page content as you wish.
CPUアーキテクチャの種類(x86, x64, arm) - わくわくBank
命令の仕方 x86 x64 は CISC(Complex Instruction Set Computer) と呼ばれる命令セットです。 「複雑な処理」を「少ない命令」で実行しようとする思想です。 arm は RISC(Reduced Instruction Set Computer) と呼ばれる命令セットです。 ビット数 ビット数が大きくなるにつれ、一度に処理できる量が増えます。処理スピードUP・利用可能なメモリ容量UPが見込めます。 x86, x64 x86 は 32bit です。 x64 は 64bit です。 arm arm については、ARMv7 では 32bit でした。 ARMv8(2011年発表) では実行モードというのがあり、AArch32だと32bit 、AArch64だと64bit となるようです。(ややこしい…) Linuxでは、ARMv7までのアーキテクチャの表記
なにこれ便利すぎる！ WebページのURLを入力すると、編集可能なFigma用に変換できるプラグイン -html.to.design
WebページのURLを入力するだけで、編集可能なFigmaデザインに変換できる無料プラグインを紹介します。 AppleなどのWebページを1クリックで変換するのはもちろん、日本語のWebページでも問題なく動作しました。Webデザインの勉強用に、既存サイトをリニュアールする用にも便利ですね。 html.to.design -Figma URLを入力するだけでFigmaに変換 html.to.designの利用方法 html.to.designの使い方 URLを入力するだけでFigmaに変換 html.to.designは、URLを入力するだけでFigmaに変換できる無料のプラグインです。さまざまなWebページを編集可能なFigmaデザインに変換します。 すべてをゼロから作成することなく、別のWebサイトを使用して独自のデザインのインスピレーションを得られます。 既存のWebサイトをリデザイン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NatML for Unity | Unity
GitHub - kt3k/remarker: :arrow_forward: Remark cli
Help content — Shopify Polaris