はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Qiita株式会社様 主催の『Qiita Engineer Festa 2024 後夜祭 ～アウトプットの祭典！～』で登壇させてもらえることになったので、私が書いた記事の内容をベースに、アウトプットを出すための個人的な考えを話してきました。 今回の記事は、テックブログ感の薄い内容ではありますが、Qiita関連イベントの延長線上だと思って見逃してください。 登壇のきっかけになった記事： 発表スライド： もくじ アウトプットを出したいなら具体的に困るところから 1. 具体的なアクションには具体的な課題（困りごと）が必要 2. 具体

※ 最小の意思決定にしては粒度が粗めですがイメージはつくかなと思います 開発プロセスも同様で、目的に対して複数のステップを踏むことがほとんどですよね。リファクタリングであれば単体テストをあてる ⇒ メソッドの内部実装変える ⇒ テストのリファクタリングする、みたいな。 こうした１つ１つの小さな意思決定という単位で履歴（意図）を残すことは、開発者の責任です。なぜなら、変更の差分はPRを見ればわかりますが、「なんでその意思決定（コードの変更）をしたのか？」はコミットメッセージを見ないと分からないからです。そういう意味で、開発者の Why? を把握するために、最終的なPRの差分がどのようにして出来上がったのかを知るために、最小単位の意思決定の履歴はレビュワーが欲しいと思う重要な情報なのです。 コミットメッセージが簡潔で分かりやすい コミットが意思決定の最小単位になっている と関連しますが、意思決

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 開発生産性をテーマとした技術イベントに出まくった結果、ある程度体系化された知識のおすそわけ記事です。 この記事を読めばわかること 開発生産性のトピックでよく語られている前提の部分 開発生産性を語るうえで大事なざっくりとした体系的な知識 開発生産性を測るためによく使われるメトリクス 雑に言えば、数字とってデータ駆動でPDCA回そうという話です。 この記事を読んだ後に、「開発生産性の議論 ﾅﾝﾓﾜｶﾗﾝ ...。」という人でも「まずはこの辺調べてみよう」ができる状態になればいいなと思って書いてます。 この記事を読んでもわからないこ

はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう！』 『今までモック使ってたけど意外とモック使わなくても書けるね！』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 もくじ テスト駆動不具合修正 or リファクタリング手順 なぜテストが書けないのか 依存関係を排除できればテストは書ける 依存関係を排除するためのカギになる考え方 書けない単体テストがなくなる２

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 動機 OSのコンセプト？やってること？はざっくり理解したので、つぎはLinuxの基本を勉強する。 DevOps Roadmap 対象の初学者向けLinux本 ゼロからわかる　Linuxコマンド200本ノック―基礎知識と頻出コマンドを無理なく記憶に焼きつけよう！ ITエンジニア1年生のための まんがでわかるLinux コマンド＆シェルスクリプト基礎編 [試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識 個人的に、順番は上記の列挙順がおすすめ。 1冊目は初学者でもめちゃくちゃわかりやすく書いてくれている 2冊目

18:45~ | 開場 19:00~ | オープニング 19:10~ | LT * 5 - 開発生産性と開発者体験の向上に向けたCI/CD改善の取り組み：PRONI株式会社/末澤 尚也さん - AWSで構築するCDパイプラインとその改善：株式会社スマートラウンド/山原 崇史さん - CIは5分以内！素早い開発サイクルを支えるCI：ファインディ株式会社/浜田 直人さん - CI/CDボトルネックの把握とその先へ：サイボウズ株式会社/加瀬 健太さん - デプロイ再考2024：株式会社estie/杉田 毅博さん 20:20~ | 懇親会 参加の動機 私自身がこれからCI/CDをやっていく人としてまず「自組織のあるべき姿を描く」ため、自組織の現状と理想とのギャップを知る必要がある。理想状態を知るためには他社の取り組み知るのも１つの手だよなと思ったので、参加してみよう、という動機。 感想 結論、CI

私の場合、自身の興味関心（インプット対象）と仕事が結びついているので、アウトプットの行動が業務内容にかなり依存しています。ですが業務外の内容だとしても、上記の学びのサイクルは当たり前のフローかと思うので、だれにでも適用できるものだと思っています。 そうだね、アクティブラーニングだね。 アウトプット先を意識したインプットをしよう この記事の根幹を揺るがす発言なのですが、正直な話、知ったかぶりはある程度知識があればできてしまうんですよね。しかし『インプット過多』、これは知ったかぶりアンチパターンです。 一般的な「知ったかぶりへの嫌悪感」は、嘘を教えられたことによる信頼の失墜や、理解の浅さが露呈している他人への嫌悪ですよね。（もちろん人間性の問題もありそうだが）これは無知の知を自覚できない状態で自信だけが大きくなることに起因します。（まさにダニング=クルーガー効果） なので知ったかぶりアンチパタ

ほかにもいろいろできることはあるかと思うので、 １週間ごとにテーマを区切ってやる みんなを巻き込んでキャンペーンする みたいな感じで楽しく継続的にやっていければベストですね！ さて、どこからやっていこう？ コスパを考えたら「多くの人が読むコードから」やっていければベストですが、計測が難しいです。 なので、「より多く変更が加えられているクラスから」、がいいのではないでしょうか。 その中でもさらに優先順位をつけるとするなら、 自分が過去に修正を加えたコードとその周辺から 静的解析の結果で判明したCodeSmellがある箇所から 今やっている機能強化・不具合修正しているところから テストカバレッジが低い箇所から などでしょうか。 ここはメンバーや組織の方針などを考慮して決められたらいいと思います。 ▼ 参考 ▼ 「特定ディレクトリ以下の変更回数の取得」に関しては以下のGitコマンドでテキストファ

// 追記（2023/12/9） なんとミノ駆動 さんにコメントいただけました。 もちろん良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方は読んで影響を受けてます。 とってもうれしい。 想定読者 新卒 ~ ２年目くらいまでのプログラミング初心者 Webアプリの保守開発をしているエンジニア 3ヶ月前くらいの自分（未経験からエンジニアになって１年くらい） こんなことないでしょうか 先輩などから原理原則の観点を共有してもらったり、そのうえで自分なりに勉強をしているはずなのに、実務ではなかなか手が動かない 変更指示に対して、「先輩が言っているんだし正しいんだろうな」とその場では指示の理由や目的が分からないまま修正を行うことがある（分かっていないため別の機会で同じ指摘を受けることがある） 自身のコーディングには判断基準や根拠がなく、なんとなくの判断に頼ることがある 上

はじめに こんにちは、タイトル通り文系出身新卒未経験エンジニアやらせてもらっています。 2023/06で開発部門に配属されてちょうど1年になります。（チーム配属は8月ですが） １年やってみた感想としては、「苦しい！」「覚えること多すぎ！」「成長実感ない！！！！」という状況なのですが、先日、23卒（後輩）の開発部門系の研修に参加させていただく機会がありました。 そこでは「自分もこんな感じで最初マジで意味わからんかったな...」と当時を思い出したと同時に、「あ~でもさすがにこのくらいなら分かるようになったなぁ」と地味に成長を実感できる良い機会でした。（なみだ） さて、そんなこんなで今回は私自身にちょうど１年を振り返る機会がありましたので、「先輩にしていただいて救われたこと / 助かったこと」 を書いてみようと思います。 これから新しく新卒未経験エンジニアの後輩を持つであろう先輩方や、新卒当時の

こんにちは。 VJの話します……！！！ VJ（Visual Jockey）という言葉自体の流行りは、少し過ぎ去ってしまったような気がしますが、 近年、音楽と映像がより一体化するようになってきている中で、もはや、当たり前の技術になりつつあるといえるのではないでしょうか？ そんなVJを行うためのアプリケーションの有名どころの一つが**「Resolume」**です。 オランダ発のアプリケーションで、リアルタイムに映像を編集したり、プロジェクションマッピング等もできます。 他の有名なVJのツールはMacのみにしか対応していないものが多いですが、ResolumeはWinにも対応しているので、Winしか持ってない人もこれでVJがやれるわけです。 さて、今回は、Processing で作った映像をResolumeにリアルタイムで送ってみようと思います。 連動にはSyphon(Mac)、Spout(Win

この記事はSpeee Advent Calendar 2016 の12日目の記事です。 前日の記事は @suemocのre:dashの権限管理とその活用事例 - Qiita です。 新卒エンジニアの@_miyachikです。今回は(フロントの変更なら)エンジニアの工数を必要とせず、アプリケーションの開発言語を問わない汎用的ABテスト基盤の話をします。 前提 今回のABテスト基盤では ブランチを分けた状態で個別にABテストができる(masterにマージする必要なし) フロントの軽微な修正はエンジニアにはエンジニアの工数は割かない(ディレクターとデザイナーのみで行えるようにする) API側などbackendのロジックに対するABテストも行えるようにする 開発言語にとらわれずABテスト基盤導入をすることが可能 を実現することが出来ます。まずは最上段の振り分けについて話したいと思います。 *　ただ