開発時に標準的に使われるコマンドを整備する Next.js のプロジェクトであれば pnpm run typecheck pnpm run build などがあることは当然だろうから、それらはpackage.jsonに書いて実行可能な状態にしておくと良い。AIは既存のコードを学習しているので、これらのコマンドを変換結果の確認に使おうとする。その時に独自のコマンド名にしていたり、コマンドを準備していないと実行に失敗して無駄な試行錯誤の時間を取られてしまう。 また、AIがコードを編集したとしてもレビューをするのは人間なので差分を見やすい状態に維持しておきたい。AIは大量にコードを書くし、Vibe Codingだと差分が大きくなりがち。ただでさえ差分が多いと量的にレビューが大変なのに加えてフォーマットのような本質的でない差分が含まれているとよりレビューが辛くなる。全部必要だが個人的な優先順は、ビ
概要 Julia では（邪道を含めて）いろんな繰り返し処理・イテレーションの書き方ができます。思いつく限りの書き方を列挙していきます。次のイテラブルなオブジェクトを考えます。
期初/期末であったり, プロジェクトの終了だったりといった節目に｢振り返り｣をして, 良かったことや課題をチームで見つけ, 次に向けたアクションを考えるのは非常に重要です. これまで, 振り返りの司会はチーム内でアサインすることが多かったのですが, 最近社内で｢他チームの人に任せる｣という選択肢が流行っているので, そのメリットなどを書いてみます. 関係者全員が｢振り返り｣に集中出来る これはかなり大きいメリットでした. これまで｢振り返り｣をするときは, チームの責任者であったり, スクラムマスターが司会をすることが多かったですが, どうしても司会の役割を任された人は, 進行に集中する必要があり, 十分に振り返りに参加できないという事がありました. 特に, プロジェクトの中でリーダー的な役割をしていた人が司会をすることになると, その人が体験してきたこと, 気づいたことをうまく｢振り返り
こんにちは、影山鴉です。 個人ゲーム開発にチャレンジしたけど難しすぎて挫折した 途中で飽きて辞めてしまった いつまで経っても完成が見えず心が折れた この記事ではそんなゲーム開発に失敗してしまった人に向けて、実体験を元にゲームを完成させる方法を伝えたいと思います。 そもそもなぜゲームを完成させるのが大事なのか？よくある例えとして、仮にゲーム開発をしたいと思う人が100人居た場合、実際に作り始める人は10人、完成させられるのは1人と言われています。 そのくらいゲームを完成させるのは難しいということです。 私自身も個人ゲーム開発に何度も挑戦しましたが、途中で挫折したり、忙しくなって熱が冷めてしまったり、作っている間にあれもこれもと変えたくなり収集がつかなくなったりと何度も失敗してきました。 しかし試行錯誤し、ついにゲームを1つ完成させる事が出来ました。下記がそのゲームです。 作ったゲームは本当に
走り書き。根拠はない。 まだ小さな開発チームなので社内のプルリクエストを流し読み程度に全て見るようにしている。コードの品質は人によってさまざまあるのは当然だが、仕様の理解度に差があるように感じている。それは人によって異なっていて、常に理解度の高い人と低い人がいる。 仕様を読むためには、主に3つの要素があるのではないかと考えた。 前提知識 環境要因 完成の定義 前提知識 システム開発だと0から作ることは少なく、多くの場合は追加開発になる。要求は何か、既存のシステムがどうなっているか、技術的に何が使われて何を使えばいいのか、がわかっている必要がある。 例えば、「ルービックキューブに黒い面を追加する」という追加開発があったとする。要求は「他の6面と同様な7面目を追加する」ということになり、既存のシステムは「3x3マス、立方体の組み合わせ、回転できる」等である。技術的な部分は「回転機構、各パーツの
すでにGTDの情報に触れているので、「電話」とか「パソコン」とか「外出」とか、そういうコンテキストを設定するのではないか。
忙しいときに質問されたら「ここに書いておいたから読んでおいて」というためのブログ記事。システム開発では様々な問題に直面することになるが、その解決方法について経験的に有効だと思う方法について書き連ねておく。考えが変わったらあとでアップデートするかもしれない。私はこうやっているよ、という話。 基本としての「いかにして問題をとくか」 もっとも汎用的な問題解決の手法としては、有名なポリアの「いかにして問題をとくか」を参考にすると良い。書籍は名著だと思うが癖があるので購入する場合はサンプルを確認することをお薦めする。骨子はWikipediaで確認できるのでそれを読むだけでも十分である。書籍ではこの内容を深める（独特の）エッセーが読める。 いかにして問題をとくか - Wikipedia いかにして問題をとくか 作者:G．ポリア丸善出版Amazon（2022年より前に刷られた活版印刷版が特に味わい深い。
はじめに 本記事では、Dagsterとオニオンアーキテクチャを組み合わせたETLパイプラインの実装について解説します。 Wikipedia APIからデータを取得してCSVに保存する具体例を通じて、保守性と拡張性を兼ね備えたデータパイプラインの構築方法を紹介します。 完全なコード例は以下のリポジトリで公開しています： https://github.com/nokoxxx1212/dagster-onion-example オニオンアーキテクチャとは 概要 オニオンアーキテクチャは、ソフトウェアの関心事を層で分離し、内側の層が外側の層に依存しないよう設計するアーキテクチャパターンです。 主要な4つの層から構成されます Domain層: ビジネスロジック・データモデル・抽象インターフェース Infrastructure層: 外部システム（API、データベース、ファイルシステム）の具体実装 Us
dbt Advent Calendar 2024 23日目の記事です。 dbtのincremental_strategyに新たにmicrobatchが導入され、大規模な時系列データの処理方法が革新的に変わろうとしています。 この記事では、microbatchと従来のincrementalを比較しながら、本番環境への導入に向けた重要なポイントを解説します。 前提: batch_size="hour" で動かすと壊れる @2024/12/23時点 解消済みです。 当記事では筆者の実際の運用環境を想定し、batch_size="hour"での実装を前提に解説を進めます。 ただし、現在dbt-coreのバグにより、hourオプションは使用できない状態です。 hourでの運用を検討されている方は、以下のissueの解決をお待ちください。 microbatchの基本設定 {{ config( mate
以前の記事で「なんか案件降ってこないかなー」と書いてみたのを知って知らずか、WEBサービスの企画およびシステムの設計を裏表どっちもやるトンデモ案件が降ってきてしまってちょっと更新が止まってしまってました・・・。楽しいから良いのですが、フォトショを起動してる時間よりパワポを起動してる時間の方が圧倒的に長いので、そろそろ自分がWEBデザイナーである事を忘れつつあります・・・。しかし、そんなある日、システム部の方々と共同で企画書作りをしてふと気付いた事があります。ノンデザイナーの方々ってわざとやっているのかというくらい企画書の体裁や見た目には全く頓着しないのだという事です。文字サイズは全部一緒、改行位置も要素の配置もめちゃくちゃ・・・。これは勿体ない。とても勿体ないです。 いくら優れた企画力や専門知識を有していたとしても、それを相手に上手く伝えられなければこんなに勿体ない事はありません。今回はち
現在こちらの記事は筆者視点で、推奨されていない可能性があります。最新の見解としては下記記事を参考にしてください。 知的・技術的進歩のスピードを限界まで加速するノートアプリ『Heptabase』 #新人プログラマ応援 - Qiita はじめに Obsidian... 検索して一番最初に到達したのがこの記事。 がんばらなくて良いのは嬉しいですね。早速目次を確認してみましょう。 めちゃくちゃがんばっとるやないか。 僕も一瞬そう思いました。しかしそれは凡人の考え方。 この長い旅路は、ほとんどが「準備」に割かれているのがお分かりでしょうか。 上級者ともなると、頑張らないために頑張るのは当然。 つまりここまでの作業は努力ではありません。ただの「準備」です。 準備はノーカン。覚えておきましょう。 使い方のポイント準備が終わった記事後半から「何を書くか」という話に入っていきますね。 Obsidian Me
![[Obsidian] みんなデイリーノート、どう使ってるの？](https://cdn-ak-scissors.b.st-hatena.com/image/square/f38d182fa524bf0b3ab3a91e186f5292562929d5/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fpouhon.net%2Fwp-content%2Fuploads%2F2023%2F06%2FObsidian_logo2023.png){kind=logo}
ビジネスの重要指標をモニターするために、ダッシュボードを作ったものの、時間の経過と共に、誰にも見られなくなってしまう、といった経験はありませんか？ そうなってしまう理由の1つに、そこから得られる情報がビジネスの改善に結びつかない、あるいは特定のアクションに結びつかないため、ダッシュボードの閲覧者にとってあえて見る必要がなくなってしまうことがあります。 そこで、ダッシュボードの閲覧者に役立つ効果的なダッシュボードを作成するうえで、おさえるべき4つのポイントを紹介いたします。 1. モニターすべきは遅行指標でなく先行指標です「売上」、「閲覧数」、「サインアップ数」などの「後追い指標」をモニターしても、それらは既に起こった「結果」なので、もうすでにとき遅しです。つまり、望む結果を得るために行動を変えることができません。 そこでしっかりとモニターしなくてはいけないのが、「リピート率」、「エンゲージ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
