「Women Developers Summit 2023(デブサミウーマン2023)」で大反響だったセッション「Git中級者への第1歩」が、パワーアップしてCodeZineに帰ってきました。この連載では、コマンドの使い方やGitの効率的な学び方など、知っておくと役立つ情報をお届けし、基礎から更なるステップアップを目指すみなさまを応援していきます。 はじめに こんにちは、都内でソフトウェアエンジニアとして働いている藤澤です。最近はフロントエンドの開発を担当しており、TypeScript、Reactあたりをよく触っています。 今回は「Git中級者への第1歩」と題しまして「普段の業務では困らないくらいにGitを使えているけど、もっと便利にGitを使いたい」という方向けの記事を3回にわたって書いていきます。 本連載は「Women Developers Summit 2023」にて筆者が発表した「
はじめに 2024年2月5日夜の東京 外は雪が降っている。tmuxとの出会いは、新卒としての初めての職場でした。メンターがターミナルの管理において最初に紹介してくれたのがtmuxで、この出会いが私の開発効率と作業環境を大きく変革しました。tmuxの基礎を学んだ後、私は自分の開発環境をさらにカスタマイズし、tmuxを日々の作業効率化のために積極的に使い始めました。ここでは、私が実際に使っているtmuxの設定と、日常的に使うコマンドを紹介します。これらは、より快適なターミナル操作環境を実現するために役立ちます。 この過程で、tmuxはただのツール以上のものになり、私の開発作業における最適なパートナーになりました。tmuxを使いこなすことで、複数のプロジェクトを同時に管理する能力が向上し、長時間の作業も中断せずに続けられるようになりました。リモートワークが増えた今では、tmuxのセッション管理機
About reserved postingIf you register a secret article by the day before the same day, it will be automatically published around 7:00 on the same day. About posting periodOnly articles submitted after November 1 of the year can be registered. (Secret articles can be registered anytime articles are posted.)
みなさんこんにちは。@ryuzeeです。 2024年1月10日〜12日開催のRegional Scrum Gathering Tokyo 2024の登壇資料を公開します。 「ベロシティ Deep Dive」ということで過去のDeep Diveシリーズの続きになっています。 過去のDeep Diveシリーズはこちらからご覧ください。 プロダクトバックログ Deep Dive スプリントプランニング Deep Dive スプリントレビュー Deep Dive セッション資料は以下になります。 結論から言うと、「ベロシティなんかにDeep Diveせず、もっと重要なところに集中しろ」です。 スクラムチームの状況を何らかの数値で表したいという考え自体は尊重しますし、それが役に立つこともあります。 ただし、数字遊びをしたところでプロダクトの価値を生み出せるわけではないので、ほどほどにしましょう。 ス
1Passwordを使って、ローカルにファイル(~/.configや.env)として置かれてる生のパスワードなどを削除した 最近、コミットはされないがローカルのディレクトリに置かれている.envのようなファイルから生のパスワードやAPI Tokenを削除しました。 これは、ローカルでマルウェアを実行した場合に、ローカルに置かれている生のパスワードやAPI Tokenを盗まれる可能性があるためです。 最近は、npm install時のpostinstallでのデータを盗むようなマルウェアを仕込んだりするソフトウェアサプライチェーン攻撃が多様化しています。 Compromised PyTorch-nightly dependency chain between December 25th and December 30th, 2022. | PyTorch What’s Really Goin
背景、目的 (Why?) 検討した別の方法 (alternatives considered) トレードオフ (Why not?: なぜ別の方法にしなかったのか?) 設計、アーキテクチャ (How?) メンバー (担当者やレビュワー) (Who?) セキュリティやプライバシーについての考察など 他プロジェクトとの関連性 テスト,モニタプランなど 基本的には、ソースコードを見てもわからない部分をDesign Docに書いて、議論するのが一般的のようです。 Design Docは、Googleに代表される最先端の技術企業で取り入れられている設計ドキュメントのスタイル。 単にドキュメントの書式だけを指すのではなく、書いた後の使い方までを含めた『開発のやり方』につながっているドキュメント方式。 アジャイルなどの現代的なソフトウェア開発スタイルにフィットしているため、シリコンバレーのスタートアップ企
事業の成果や開発組織のリソースを最終的なアウトプット先である管理会計や財務会計に、私達が日頃から作っているソフトウェアどういった風に計上されているか。前提としては、自社開発でのソフトウェア資産計上とする。 まずは、なぜ資産計上をするべきかなのか、ひいてはプロダクト開発にどう関わってくるかを考えていく。 なんでソフトウェアを資産計上しないといけないのか私達が作ったソフトウェアというを資産計上しなければいけないかというと、端的に言えば、正しい財務諸表(B/S : 貸借対照表)のためです。あと普通に資産計上しないと脱税になるはず。(実際には、色々な資産巡りでのあれこれでの対策防止があるらしい) B/Sの中で、固定資産という枠があり、ソフトウェアはその中の「無形固定資産」にあたります。細かいですが、ソフトウェアで計上できるものは確実に将来の収益や費用削減が見込まれるものになります。それ以外は、費用
ビジネスリーダーをはじめ、ソフトウェアプロジェクトの関係者にとって、ソフトウェア開発上の関心事は、開発の進捗とシステムトラブルだ。ソフトウェアの内部品質や開発プロセス上の問題や課題なんて、開発者以外に興味を示す人などほとんどいない。だから、関係者ばかりか開発者自身も、開発の進捗とシステムトラブルにばかり注意を向ける。 そのような状況に、一部の優秀な開発者は我慢ならない。憂いている。「このままではまずい、積み上がった問題に取り組むために時間が欲しい」「まとまった時間でなくても、継続的に取り組むための少しの割り当てでも構わない」と。そんな願いも虚しく、使える時間はすべて、担当する開発を進捗させることにのみ費やすことを強いられる。 私たちエンジニアリングマネージャーやテックリードは、このような状況を見て見ぬふりをしていないだろうか。開発の進捗やシステムトラブル以外にも注意を向けるべき対象がある。
シェルの歴史 総まとめ(種類と系統図)と POSIX の役割 〜 シェルスクリプトの現在・過去・未来【POSIX改訂間近】ShellScriptBashUNIXPOSIXksh はじめに Linux / Unix をターミナルから使う時に使用するソフトウェアがシェルです。シェルの役目は CLI ベースのユーザーインターフェースとしてユーザーからの操作でプログラム(主に CLI コマンド)の実行を仲介したり、その操作を自動化するためのシェルスクリプトを実行する機能を持っています。現在最も使用されているシェルは GNU プロジェクトが開発している bash ですが、OS によって異なるさまざまなシェルが使われています。 シェルの最低限の仕様は POSIX で標準化されています。この標準規格に準拠しているシェルは「POSIX(準拠)シェル」と一般的に呼ばれています。シェルは大別すると「POSIX
The Rust Programming Language by Steve Klabnik and Carol Nichols, with contributions from the Rust Community This version of the text assumes you’re using Rust 1.67.1 (released 2023-02-09) or later. See the “Installation” section of Chapter 1 to install or update Rust. The HTML format is available online at https://doc.rust-lang.org/stable/book/ and offline with installations of Rust made with rus
こんにちは。壮(@sew_sou19)と申します。 メガベンチャー企業でエンジニアとして働いています。 エンジニアにジョブチェンジした当初は、ドキュメントの書き方なんてこれっぽっちも分かりませんでした。読みやすいドキュメントを書くことが本当に苦痛だったのですが、考えて、試行錯誤し続けた結果、以下のような評価を得るに至りました。 リーダーから「君は情報の整理が上手でドキュメントが本当に読みやすい。チーム全体の能力向上に繋げたいからドキュメント書く際のポイント共有してほしい」と言われたので、意識していることを言語化しつつテクニカルライティングの本でインプットしてるけど、学びが多い。ついでにnoteにもまとめてる — 壮 (@sew_sou19) November 28, 2022 そこでこのnoteでは、僕がドキュメントを作成するときに、特に意識して実践している7つのことを書きます。(本当は2
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く