ほんとうにあった開発生産性が爆下がりする話 - Qiita
昨今、継続的にプロダクト開発していくことが主流となり、Four Keysなどの開発パフォーマンスを測る指標なども出てきており開発生産性を向上させることが注目されています。 しかし、かつての開発現場では今では信じられないような開発生産性を爆下げするようなことをやっていました。 この記事では10年以上前に私が経験した開発生産性を爆下げする事例を書いていこうと思います。 (私が体験したことをベースに書いているので10年前は全てがこうだったということではないのでご留意ください ) 修正前のコードはコメントアウトで残す 当時、ウォーターフォールで開発していました。 ウォーターフォールでは開発工程とテスト工程が分かれています。 開発工程で一通りコーディングして、テスト工程で動作確認を行いバグを潰します。 問題はここからです。 とある現場では、テスト工程でバグを直すときにコードを破壊的に直すのではなく、
自動テストはなぜうまくいかないか？乗り越えるためには何が必要か？ - Qiita
リファクタリングの鶏卵問題 ソースコードがクソなので綺麗にしたい。 リファクタリングしたい。 しかし、リファクタリングが出来ない。 リファクタリングが出来ないのは、テストが無いからだ。 よし。じゃあテストを書こう。あれ、テストが書けない？ そのようなテストが無く、書き換えられないことによる矛盾や憤りは皆さん何百回と感じてきたと思います。 しかし、この「テストが出来ない」ということを言語化するのは、非常に難しいと思います。それは、「テストが出来ない」には実は2つの視点があります。 本質的にテストが困難なモジュールで、誰がやってもテストが書けない。 本質的にモジュールはテスト可能だが、自分の実力が足りず、自分ではテストが書けない。 1.のようなテスト困難なモジュールは誰がやってもテストは書けないです。しかし、問題は、「テストを書きたい」と思ったとき、「自分がそれほどテストに詳しくない」という場
だれかの進捗をうまく把握できないときのフレーズ集 - Qiita
ほとんどの人はだれかと恊働しています。マネージャーやリーダーであるなら、この割合はより大きくなります。 筆者は、仕事の重要な要素のひとつを「進捗を出すこと」と定義しています。そして進捗を出すには、進捗をただしく把握することも重要になってきます。 しかし「進捗を把握する」と言っても、想像以上に難しいと感じる場面が多々ありました。たとえば、 進捗はどうですか？ → 進行中です／〜をやっています なにか問題はありますか？ → とくにないです 〜までに終わりそうですか？ → たぶん大丈夫だと思います というようなやりとりは一般的なコミュニケーションだと思いますが、あまり有用な情報は得られていません。 この記事では、自身の経験則をもとに、進捗にまつわる良い情報をゲットするための具体的な質問を考えてみました。 なぜ進捗を把握すべきなのか 話の前に、なぜ進捗を把握すべきなのでしょうか。 それは良い計画づ
モダンプログラマになれない組込みプログラマの苦悩 - Qiita
はじめに 10年以上組込みエンジニアをしている@yagisawaです。 Qiitaのトップ記事では新しいフレームワークの使い方とかモダン言語の新しい言語仕様の解説とかが流れてきて、いつも羨ましいなーと思いながら読んでいます。 本記事は組込みシステム開発をしていて経験したこと・感じたことを自虐ネタとして書き連ねていこうと思います。他ITエンジニアの人に「うわっ、可愛そう」って思ってもらうのが目標です（ぇ 各業界それぞれに悩みはあると思うので、自分たちが一番不幸とかは思っていません。おそらく隣の芝が青く見えているだけです。それよりあまり組込みの記事は見かけないので、「組込みエンジニアの仕事ってこんな感じ」というのを知ってもらう意図があったりします。 内容によっては「それはあなたの設計が悪いからです」と言われてしまうようなところもあるとは思いますが、建設的なご意見は大歓迎ですが基本は温かい目で見
最近のポケモンはデジモンっぽいのか、ディープラーニングに聞いてみた - Qiita
はじめに ポケモンについて何となく知っている人向けの記事です（デジモンは知らなくてOK） ３月ごろにポケモンたかさおじさんが集計したアンケートの分析をお手伝いしたところ、アンケートの自由記述回答の6353件中、155件もデジモンについて言及するコメントがあった。 「デジモンと区別付かないよね」 「もはやポケモンじゃない…。デジモン…。昔のデザインに戻ってほしいなぁ…。。。」 「主観ですが、伝説のポケモンが角張った印象で、デジモンのような印象を受ける。」 「全体的に毛がなさそうなツルッとしたフォルムの子達が増えた気がします。デジモンっぽい」 「デザインがごちゃごちゃしすぎて子供が描くのが難しい デジモンに近くなってきている」 「ダイパまでのデザインがポケモンっぽいデザイン。それ以降はデジモンみたいな雰囲気。」 私は幼少期からポケモンには触れてきたが、デジモンにはあまり縁がなかったため、 デジ
5歳娘「パパ、変なAPIを作らないで？」 - Qiita
とある休日 娘（5歳）「パパ、一緒に技術ブログを始めない？」 娘「昔から私とパパがローカルに書き溜めてる技術記事が、かなり溜まってきたでしょ？」 娘「それをブログとして公開してみようよ」 ワイ「おお、それは楽しそうやな」 ワイ「どこのブログサービスを使おうかいな」 娘「せっかくなら、ブログシステムから自分たちで作ってみようよ」 娘「私はフロントエンドを担当するから」 娘「パパはRuby on Railsか何かで、APIを作ってよ」 ワイ「おお、Ruby on Railsなら昔やったことあるわ」 ワイ「RailsのAPIモードで、ブログ記事を返すエンドポイントを作ればええんやな」 娘「そうそう」 次の日 ワイ「API、できたで！」 ワイ「/api/articlesっていうエンドポイントにアクセスしてくれたら」 ワイ「ブログ記事が取得できるようにしておいたわ」 娘「さすがパパ」 娘「そういえば
現場で役立つシステム設計の原則メモ - Qiita
※この記事は著者の増田さんの了解の上で限定公開させて頂いております。 https://twitter.com/masuda220/status/1215122054795522049?s=20 オブジェクト指向、設計がなぜ必要か = ソフトウェア全体の整理整頓をするため 第1章 小さくまとめてわかりやすくする 変更が大変なプログラムの特徴 メソッドが長い クラスが大きい 引数が多い 関心事を詰め込みすぎている ちょっとずつゴミコードが追加されていった結果 重複しているコードをutil神クラスに押し込むと、あらゆる関心事が集中してしまう 変更に強いプログラムの書き方 メソッドは短く、クラスは小さく 略語は使わない 意味のまとまりで空行をうまく使う 説明用のローカル変数の導入（変更の影響範囲を局所化） 1つの変数に代入を繰り返す破壊的代入を避ける 意味のあるコードのまとまり（段落）を「メソッド
【魚拓】ほんとうに怖い。さくらのレンタルサーバー - Qiita
・ 10月04日 16時 x.com取得時のダイアログを非表示に変更しました ウェブ魚拓は表示に必要なHTMLソースへの変更は可能な限り避 ...
同じチームにいて最高に心強かったエンジニアの特徴をまとめてみた - Qiita
これまで私はプロダクトマネジメントやデザインディレクションを行う立場として、BtoBにBtoC、iOSにAndroidにWebにWatchOSにIoT、ゼロイチにグロース。様々な分野、プラットフォーム、フェーズでサービスを開発する機会に恵まれてきました。 その中で一緒にチームを組んだフロントエンド、サーバーサイド、iOS、Android、インフラ、データ、様々なエンジニアの方を思い出しながら「ああ、心強いな」と感じた色々なタイプの特徴を、リスペクトの想いを持って、プロダクトマネージャーやデザイナーの視点でまとめてみました。 それではいってみましょう。 目的にフォーカスしている 要件をただ実装するのではなく、ビジネスの目的はなにか、ユーザーが真に求めているものはなにか、なにがサービスの生死を分けるのか、技術は目的を達成するための手段だと客観的に捉え、真の目的に対して解決策を提案し続けてくれる
日立社員「社内からQiitaに投稿？できるのそれ」 - Qiita
(2019-12-18 表現を一部訂正しました。) メタ記事。投稿するのにかかる手間に関する投稿です。 1 どうしてこんな記事を書こうと思ったか 日立製作所もガンガンOSS活動をしていることを知ってほしい。日立に興味があるが、OSSコントリビューションは社外発信にどれくらい熱心なのか気になる人向けに、とある一部署の情報をシェアしたい。 タイトルのような感想を持つ弊社内の人に情報発信してもらいたい。 (残念なことに、) 社内の情報共有サイトに書くよりQiitaに書いたほうが読まれそう。 後輩がAdvent Calendarの記事集めに苦労していたので気の毒になったため 注: 全社的な審査プロセスではなく、(株)日立製作所 ITプロダクツ統括本部のやりかたです。 では全社的なプロセスは？他の部署は？ → 詳しい方、（申請の上）コメントください。 ITプロダクツ統括本部って何？ Google i
いつものように本番作業してたはずなのに - Qiita
この記事は「本番環境でやらかしちゃった人 Advent Calendar 2019」の1日目です。 https://qiita.com/advent-calendar/2019/yarakashi-production なかなか濃いラインナップが期待されますが、まずはさらっといきたいと思います。 具体性が乏しい部分もあると思いますが、そこはお察しください。。。 やらかし 背景（前提条件） いっていに昔の話です ETL（データ加工）サーバ 数十を超えるシステムからデータを集める BIツールなどで活用できるように各種加工処理を行い、DBなどにロードする 繁忙の違いはあれど、24/365で常時一定量の処理は稼働している 複数のチームが共存しているサーバ アプリ面では比較的疎 ETL処理のリリース前に本番サーバ上で試験をする取り決めになっていた 性能や本番相当データのテストが安全に行えるような環境
エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita
本記事は、Engineering Manager Advent Calenderの１日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ
slackで「投稿ルールが守られない問題」を自作のスラッシュコマンドで解決する(設定編) - Qiita
slackあるある ※※お知らせ※※ 今後、備品購入を希望される方は当チャンネルで ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 【購入品名】 ： 【購入URL】 ： 【購入承諾者】： 【納品希望日】：2019/mm/dd 【備考】 ： ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ というフォーマットを使って下さい。 (ピンどめしておきます) 現実は・・・ フォーマットを自己流に改変する人 そもそもフォーマットを使ってくれない人 別のチャンネルで依頼する人 etc..... 解決策 今後、備品購入依頼は 当チャンネルで /bihin と投稿し、 表示されるダイアログから依頼して下さい。 表示されるダイアログ 簡易バリデーションチェックあり ダイアログ経由で生成される投稿 確実に期待したフォーマットで投稿してもらえる 指定のチャンネル以外でコマンドを使用した際のエラー表示 投稿者本人だけにエラーが通知され、無駄
早すぎる抽象化の危険性(その抽象化、今のタイミングで大丈夫ですか？) - Qiita
※ 色々と誤解を招くというご指摘を受けたためタイトルを変更しました 早すぎる抽象化の危険性 ↓ 早すぎる抽象化の危険性(その抽象化、今のタイミングで大丈夫ですか？) 元の記事の趣旨としては、 抽象化をするな という訳ではなく、 その抽象化は本当に今すべきなのか一歩立ち止まって考えろ ということだと思っております。 何か不適切な点などございましたらご指摘頂けますと幸いですm(_ _)m ~~ 以下本文 ~~ ちょっと前の記事なのですが とても印象深く 今後も気をつけていきたいと思い 自分なりにまとめてみました。 早すぎる抽象化とは？ 問題になっていることを十分に理解する前に 可能性のあるすべてのパターンを把握しきる前に 抽象化をしてしまうこと ※コメントでのご指摘がありましたように 「早すぎる抽象化」はの結果として 「誤った抽象化」に陥ってしまうことが問題であり、 定義を下記のように修正しま
侍エンジニア塾の解約・返金に成功したので公開するby弁護士プログラマ - Qiita
はじめまして。 弁護士プログラマのイッテルビウムです。 今回は玄人な方には全く関係のないニッチな話題ですが・・ プログラム初心者のみなさま！ 侍エンジニア塾の高額コースを契約して後悔しているみなさま！！ 侍エンジニア塾を解約できましたーー！！！ そうなんです。 私、何かと炎上している侍エンジニア塾との契約解除・返金交渉に成功しました。 同じように悩んでいる方のお役に立てたらと思っております。 弁護士という肩書は出さなかったので、どなたの役にも立つと思います。 そして、円満にいったので、特に恨みもなく、いい終わり方ができました。 皆様にくわしく紹介します。 侍エンジニア塾とは 侍エンジニア塾とは、日本初マンツーマン指導のプログラミング学習塾です。 ２０１９年２月４日現在のホームページによりますと ４か月でフリーランスとして独立できたり ３か月でフルスタックエンジニアになれたり といった非常識
iPadでプログラミングしてる人、今まで馬鹿にしててすみませんでしたァァァァ!!!! - Qiita
こちらの記事内容は3年以上前のものなので、記事内にあるアプリケーションなどの動作やUIは実際と異なる可能性があるのでご注意ください。 (2023/01/04追記) iPadでプログラミングwwwアホちゃうかwww ワイ「え？お前全部iPadでプログラミングしてんの？そんなん効率悪いに決まっとるやんw」 ワイ「せいぜいでっかい画面でGithubのコード眺めるくらいしかできないやろwてかハイライトすらないんじゃn」 ?!(Monokaiで表示されとるやんけ...) ワイ「おっ、おう。シンタックスハイライトくらいはできるんやな。」 ワイ「まあ、考えてみればそのくらいは余裕だわなwでもな〜wコードだけ書けてもプレビューは？流石にそれが出来ないことには使えるとはいえn」 ?!?!(localhostで立ててくれるんか...これならCDN使えば簡単なサイトくらいやったらiPadだけで楽に作れるやんけ.
アセンブリに触れてみよう - Qiita
.LC0: .string "%d\n" main: push rbp mov rbp, rsp sub rsp, 16 mov DWORD PTR [rbp-4], 1 mov DWORD PTR [rbp-8], 2 mov edx, DWORD PTR [rbp-4] mov eax, DWORD PTR [rbp-8] add eax, edx mov esi, eax mov edi, OFFSET FLAT:.LC0 mov eax, 0 call printf mov eax, 0 leave ret …何が書かれているか分かりませんね。 というわけで、今回は最終的に、このアセンブリがなんとなく読めるようになることを目標にします。 それでは前提知識を説明していきます。はじめに、アセンブリなどの用語の説明をしていきます。 2. 前提知識 用語説明 まず、それぞれの言葉を説明しま
【新元号】改元のシステム改修で慌てるシステム屋は「無能」とのこと - Qiita
という記事を見ての職業プログラマ歴３年程度の若造の過剰反応です。 まとまっていないポエムのようなものなので、 こんなことあるんだなっていう程度に思っていただいたら幸いです。 作ったプログラムを保守しているとは限らない まずはこれが大前提。 「作ったやつが無能」だとか「あらかじめ予想していなかった人が問題」だとか、 いろいろ思うことは当然私にもないとはいいませんが、 そういうことは後続の人が云ってはいけないと思っています。 なぜそうなったかの原因究明は必要ですが、悪口を言うための究明なら時間の無駄でしかない。 考慮ができていない「おかしなプログラム」を直すのが我々保守の一端、おざなりにしてはいけない。 １か月でリリースは難しい そもそもプログラムに直接書き込まれていて、 なおかつオフラインで運用されているシステムが、全国各地にある場合にある場合、 たった１か月で「調査→修正→テスト→納品」で
世の中の小説作家と編集者は今すぐ Word や G Suite を窓から投げ捨てて Git と GitHub の使い方を覚えるべきだ - Qiita
世の中の小説作家と編集者は今すぐ Word や G Suite を窓から投げ捨てて Git と GitHub の使い方を覚えるべきだGitGitHub小説 タイトルは釣りではありません。 最近、小説の執筆にあたって Git を導入して原稿の進捗履歴を管理しました。めちゃくちゃ便利でした。 GitHub を使って友人と一緒に校正校閲の作業をしました。めちゃくちゃ捗りました。 短編 SF 小説が短期間で完成しました。でも広告が目的ではないのでリンクは貼りません。 Git のことを何も知らない奴が Git と GitHub の使い方を覚えたら便利だったし捗ったので、記事にしてしまおうぜという試みです。 2019年1月4日 追記 本記事は「執筆」および「校正・校閲」の段階における Git と GitHub の有用性を主張する記事です。 「組版」や「デザイン」の段階における Git の有用性について
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【魚拓】Webエンジニア業界に感じた違和感 - Qiita
