ソフトウェア開発における「借入」との上手な付き合い方 - Nealle Developer's Blog
ソフトウェア開発における「借入」との上手な付き合い方こんにちは！ニーリーアドベントカレンダー2024 18日目は ARCHチームの野呂が、借入についての記事をお届けします！ ここだけの話なのですが、我が家のリビングのドアのドアノブが失われてそろそろ1ヶ月経ちます。 リビングのドアにドアノブがないと非常に不便です。 ちゃんと閉まらないのでエアコンの暖気がだだ漏れになりますし、猫が脱走して大暴れします。 皆様におかれましても、リビングのドアノブを持ち去られそうになった場合、勇気を持ってNoを言った方が良い結果を生むことが多いのではないかと思います。 相手がプロで、自分が素人であってもです。 参考になりましたら幸いです。 さて、ここからが本題なのですが、皆様はどのくらい借金をしていますか？ 適度に借金をしてきちんと返済すると、信用スコアが上昇し、次に借りられるお金の上限が緩和されがちです。 資本
個人的 Vibe Coding のやりかた
こんにちは、よしこです。 最近、個人的に欲しいツールをVibe Codingで作ることが増えてきたので、私の中で定着してきた進め方をまとめてみようかなと思いました。 ちなみに "Vibe Coding"（雰囲気コーディング）というのは、「人間が音声やテキストで指示を出し、AIが主体となってコードを書くコーディングスタイル」を指すワードです。 私もこのやりかたをするときはほとんどコード書いてません。 要件定義 まずは「何を作るのか」「ターゲットは誰か」「どんな機能が必要か」「画面構成はどうするか」などを決めます。好きなAIとチャットベースで喋りながらまとめていきます。 こっちが全然考えきってなくても、「◯◯なアプリ作りたいんだけど要件定義手伝ってー」から会話を始めれば必要な情報は向こうがヒアリングしてくれます。 ここはChatGPT 4oを使うことが多いです。トーンやノリが個人的な好みと合っ
Claude × Obsidian × Zettelkastenでテックブログ執筆ワークフローの脱構築をする
これはなに こんばんは、もりたです。 先日、3.5万文字くらいの記事群[1]を書き終えてホッとしています。今回はそのゆるゆるとした気持ちでテックブログ執筆環境と作業フローを作り直してみました。[2] 具体的にはClaude × Obsidian × Zettelkastenでの作業環境を作ります。また大きな気づきとしてワークフロー設計の大切さを感じているので、その点についてもまとめられればと考えています。 構成と何をやるか 構成 各ツールの紹介 Claude Obsidian Zettelkasten Zenn Github 作成した環境とワークフロー 実現したいもの 環境 ワークフロー 感想とNA 全体 Claude Obsidian Zettelkasten NA おわりに なにをやるのか？ 当初の目的はAIを用いて技術記事を書けるようにしたいと考えていた AIの作る記事は良い意味で安
Design Docの書き方
背景、目的 (Why?) 検討した別の方法 (alternatives considered) トレードオフ (Why not?: なぜ別の方法にしなかったのか？) 設計、アーキテクチャ (How?) メンバー (担当者やレビュワー) (Who?) セキュリティやプライバシーについての考察など 他プロジェクトとの関連性 テスト，モニタプランなど 基本的には、ソースコードを見てもわからない部分をDesign Docに書いて、議論するのが一般的のようです。 Design Docは、Googleに代表される最先端の技術企業で取り入れられている設計ドキュメントのスタイル。 単にドキュメントの書式だけを指すのではなく、書いた後の使い方までを含めた『開発のやり方』につながっているドキュメント方式。 アジャイルなどの現代的なソフトウェア開発スタイルにフィットしているため、シリコンバレーのスタートアップ企
Zodで真のTypeScript firstを手にする
fullstack TSなアプリケーションも増えてきた昨今、TSでvalidatorを実装する際に何を採用するかは一大トピックです。今回は、その中でも新しめなライブラリでありBlitzも採用しているZodについて見ていきます。 Zodとは Zodの特徴として、Schema firstなvalidationライブラリであるというのがあります。 validateするschema（単一のschemaからobject, arrayまで）を定義し、それをベースにparseするというものです。 公式にあるexampleを見てみましょう。 import { z } from "zod"; // creating a schema for strings const mySchema = z.string(); mySchema.parse("tuna"); // => "tuna" mySchema.p
「Platform Engineeringへの招待」、開発者の生産性を高めるプラットフォームを作り、運営していくための考え方とは（前編）。Platform Engineering Meetup #1
急速に注目を浴びつつある新しいムーブメント「Platform Engineering」についてのコミュニティイベント「Platform Engineering Meetup #1」が3月9日に都内でオンラインとオフラインのハイブリッドで開催されました。 Platform Engineeringとは、クラウドネイティブ時代においてソフトウェアエンジニアリング組織にセルフサービス機能を提供するためのツールチェーンやワークフローを設計し構築する技術分野とされています。 その最初のセッションとして行われた、イベントの主催者である草間一人氏の「Platform Engineeringへの招待 - Platform Engineeringって何？ 何故今注目なの？」の内容を紹介しましょう。 記事は前編と後編に分かれています。いまお読みの記事は前編です。
About this guide | Google developer documentation style guide | Google for Developers
Stay organized with collections Save and categorize content based on your preferences. This style guide provides editorial guidelines for writing clear and consistent technical documentation for an audience of software developers and other technical practitioners. If you're new to the guide and looking for introductory topics about our style, then start with Highlights, Voice and tone, and Text-fo
We help you create successful product culture and process
People, teams, and organizations that are outcome-centric focus their attention on the customers and users that consume their products and services. While finishing more work faster is valuable, none of that matters if your customers don’t use and get value from your products. Outcome-centric thinking isn’t just for products and services your organization sells, it’s also for the things you build
Trunk Based Development
One line summary A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’ *, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after. * main for the Git community since 2020 (master with unsavory connotations before) Sh
Sane GitHub Labels
TLDR; the default GitHub labels kinda suck; use a sane labelling scheme instead; and use git-labelmaker to simplify GitHub label editing. If you work for a company that manages any part of their codebase using GitHub, or if you work in some open-source repositories with at least a few contributors, then I’m sure you’re aware of how wonderful labels can be at organizing everyone’s work. Maybe you n
AWSを退職してYuimediに入社します
こんにちは。@watildeです。 世界で一人目となるDeveloper Relations Engineer(Mobile)として1年半ほど在籍したAWSを3/31にて退職をして、4月より世界で医療データの利活用を広く推進するYuimediへの入社をすることとなりました。AWS在籍中は@akitsukadaをはじめとする、多くの同僚に温かいご支援を頂いて成果を共創できたことを嬉しく思います。 本日にてAWSを退職しました、お世話になりました！これからのお話はブログにてまた書こうと思いますが、ひとまずご挨拶まで。 pic.twitter.com/lbaapJFwvi — Daijiro Wachi (@watilde) March 30, 2022 この記事では、過去・現在・未来の軸で 1) 何をしてきたのか 2) 今月から何を行うのか 3) 今後は何を目指すのか について共有して関係者、
Monorepo Explained
Everything you need to know about monorepos, and the tools to build them.- Made with love by Nx Understanding Monorepos Monorepos are hot right now, especially among Web developers. We created this resource to help developers understand what monorepos are, what benefitsthey can bring, and the tools available to make monorepo development delightful. There are many great monorepo tools, built by gre
Dockerに関するキャッシュたち
はじめに Dockerを用いた開発では、適切にキャッシュを用いることで高速にビルド・開発できます。そのための知見は様々な記事で共有されており、ありがたい限りです。 しかし、「Dockerのキャッシュ」と言っても開発時とCI・CDでは行うことが違います。 この記事ではDockerを用いた開発における、各段階のキャッシュ機能を確認したいと思います。 主に「Dockerのキャッシュ」というと以下の4つに分類できると思いますので、それぞれについて解説していきます。 Dockerのレイヤーキャッシュを活かす a. COPY・ADDの順番 b. dockerignoreの設定 c. マルチステージビルド buildkitによるキャッシュ a. --mount=type=cache CI・CDにおいてのキャッシュ a. 前回のビルドキャッシュを持ち越して使う リモートキャッシュ a. 開発者が初めてビル
リモートワークのための質問力向上研修を実施しました - Classi開発者ブログ
この記事は Classi developers Advent Calendar 2021 の 7日目の記事です。 こんにちは。顧客サポート基盤チーム兼、技術戦略室にてエンジニアをしています、中島です。 みなさんは、日々仕事をする上で必須である「誰かに質問をする」という行為について、自信を持って適切に行うことはできているでしょうか？ 先月弊社では外部講師である、株式会社フィッシャーデータのあんちべさん をお招きし、質問力向上のための研修を実施しました。今回はこの研修を実施するに至った背景、研修内容を少しお見せするのと、社内の反響をお伝えします。 質問力を向上しよう！と至った背景 弊社は2020年2月頃よりリモートワークへの移行を行い、1年半以上が経過しました。リモートワークのお困りごととして一般的にもよく聞かれる、コミュニケーションについての課題を見聞きするようになってきました。 （ちなみに
Minikube で無料で商用利用できる Docker 開発環境をつくる
Docker Desktop が有料化したことが話題になりました。私自身は Docker の中の人はきちんと稼いで開発の継続性を得てほしいと思っています。ともあれ有料だぞって言われると、いや無料でやれるぜって大喜利にしたくなるものです。 いくつか無料な代替手段を模索されているのを目撃しましたが、大喜利らしくハードな作例が多く、 Minikube + VirtualBox が簡単っぽいぜという紹介記事を書いてみました。 Minikubeはいいぞ。 Minikube とは Minikube は Kubernetes のローカル環境をシュシュッと作ったり潰したりするコマンドラインツールです。今回は k8s な部分は一切つかわないです。 https://kubernetes.io/ja/docs/tutorials/hello-minikube/ 制限 今回の作例では VirtualBox を利用
GitHub開発チームでのCodespacesの利用
先日github.comのTeamとEnterprise CloudプランでCodespacesがご利用いただけるようになりました。Codespacesはソフトウェアチームに対して、クラウド上でより速く、よりコラボレーティブな開発環境を提供します。詳しくはCodespacesのページをご覧ください。 GitHub.comのコードベースはもうすぐ14歳になります。GitHub.comの最初のコミットがプッシュされたとき、Railsはできてからまだ2年しか経っていませんでした。AWSはできてから1年で、AzureやGCPはまだ存在していませんでした。14年という歳月はCOBOLの世界では長くないかもしれませんが、インターネットの世界ではかなりの長さです。 この14年の間に、GitHub.comのコアリポジトリ（github/github）では100万回以上のコミットが行われました。これらのコミ
自分の勉強や開発をできなくなった - Konifar's ZATSU
最近夜や休日に自分の勉強や開発をできなくなった。 夜や休日にそんなことせずに業務時間内でやるべきでしょという意見もあると思うが、自分の場合は以前は苦もなく自然とやれていた。それが今はできていない。 理由は明確で、自分が集中できていないからである。背景には育児家事の話はもちろんあるが、時間が取れていないわけではない。 息子は睡眠エリートで毎日2~3時間昼寝をするし夜20時半には寝ている。寝ている時間に何かをすればよいのだが、手が付かない。イメージとしては、1日のMPを使い果たしている感じ。こういう感覚は育児に関係なく経験していて、集中できなくなってしまう時期はあった。 なので「育児家事で時間が取れない」というのは正確ではなくて、「自分が集中できていない」というのが正しい気がする。これは自分の考えであって、家庭にもよるとは思う。家事育児の事情は本当に家庭によって全然違う。子どもが生まれたことで
なんでもSPAにするんじゃねぇ！という主張のその先 - console.lealog();
Your shopping website is not an SPA. I repeat: your shopping website is not an SPA. Stop trying to sculpt David with a JS chainsaw and get yourself an HTML/CSS chisel.— Alex Russell (@slightlylate) 2021年8月10日 この主張、界隈（少なくとも自分の観測範囲）では割とよく見かけるし、なんか定期的に話題になるトピックなのかなーと。 まあ持論としてもコレには概ね同意しており、会社のスタンスとも相まって、常日頃からぼんやり考えてたりすることでもある。 で、そんな折にこのツイートを発見して、さらにそれに言及してる人々を見て、ふと自分でも現状を整理しておきたいなーという気持ちになったので筆を執った次第。
5歳娘「パパ、余分なpropsいっぱい書くんだね！」 - Qiita
新しい記事もよろしくやで！ 5歳娘「パパのReact、めっちゃ遅いね！」 とある平日 娘（5歳）「パパ、今日は何のお仕事してるの？」 ワイ「おお、娘ちゃん」 ワイ「今日はな、ショッピングサイトを作ってんのや」 今日のお仕事内容 ワイ「↓このデザインの通りに、コーディングをせなあかんのや」 娘「なるほどー」 娘「このショッピングサイトで商品を売りたい！っていうお店があったとして」 娘「そのお店の人が、最初にお店の情報を登録するためのページだね！」 ワイ「せやせや」 まずはデザインを眺めてみる ワイ「この店舗登録ページにはなぁ」 ワイ「↑こんな感じの」 ワイ「項目名と入力欄がセットになったパーツが何度も登場するから」 ワイ「そのためのコンポーネントを作ろうかなー、って」 ワイ「そう思ってたとこなんや」 娘「ふーん」 娘「ラベル付きテキストフィールド的なコンポーネントってことだね」 娘「どこまで
「ITの開発現場によくいるやっかいな人」の対処法をタイプごとに解説したサイトが登場
ソフトウェアの開発プロジェクトにはさまざまな経歴や役職を持つ人が関与するので、我が強い人や性格に難がある人が問題になることもしばしば発生します。ソフトウェア業界のよもやま話を語るブロガーのニール・グリーン氏が、ソフトウェア開発プロジェクトの中で問題になりがちな人をタイプごとにまとめつつ、それぞれのタイプの特徴と管理職向けの解決策を解説しました。 How to Deal with Difficult People on Software Projects https://www.howtodeal.dev/ 上記のサイトにアクセスしたのが以下。上から「プロダクトマネージャー」「デザイナー」「プロジェクトマネージャー」「開発マネージャー」「開発者」「品質保証(QA)」の6カテゴリに分かれていて、それぞれの役職の中によくいる「問題のある人」のタイプが動物のアイコンで示されています。例えば、「プロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
