ほんとうにあった開発生産性が爆下がりする話 - Qiita
昨今、継続的にプロダクト開発していくことが主流となり、Four Keysなどの開発パフォーマンスを測る指標なども出てきており開発生産性を向上させることが注目されています。 しかし、かつての開発現場では今では信じられないような開発生産性を爆下げするようなことをやっていました。 この記事では10年以上前に私が経験した開発生産性を爆下げする事例を書いていこうと思います。 (私が体験したことをベースに書いているので10年前は全てがこうだったということではないのでご留意ください ) 修正前のコードはコメントアウトで残す 当時、ウォーターフォールで開発していました。 ウォーターフォールでは開発工程とテスト工程が分かれています。 開発工程で一通りコーディングして、テスト工程で動作確認を行いバグを潰します。 問題はここからです。 とある現場では、テスト工程でバグを直すときにコードを破壊的に直すのではなく、
自動テストはなぜうまくいかないか？乗り越えるためには何が必要か？ - Qiita
リファクタリングの鶏卵問題 ソースコードがクソなので綺麗にしたい。 リファクタリングしたい。 しかし、リファクタリングが出来ない。 リファクタリングが出来ないのは、テストが無いからだ。 よし。じゃあテストを書こう。あれ、テストが書けない？ そのようなテストが無く、書き換えられないことによる矛盾や憤りは皆さん何百回と感じてきたと思います。 しかし、この「テストが出来ない」ということを言語化するのは、非常に難しいと思います。それは、「テストが出来ない」には実は2つの視点があります。 本質的にテストが困難なモジュールで、誰がやってもテストが書けない。 本質的にモジュールはテスト可能だが、自分の実力が足りず、自分ではテストが書けない。 1.のようなテスト困難なモジュールは誰がやってもテストは書けないです。しかし、問題は、「テストを書きたい」と思ったとき、「自分がそれほどテストに詳しくない」という場
SofTalkをご利用の皆様へのお知らせ - SofTalk
日頃よりご愛顧いただき誠にありがとうございます。 SofTalkは、長年AquesTalkに対応してまいりましたが、勝手ながら AquesTalkへの対応を中止させていただくこととしました。 SofTalkのようにAquesTalkを同梱している場合、利用者がAquesTalkの機能を使わずに、 OpenJTalkを商用利用する場合でも、AquesTalkのライセンス料を支払わなければなりません。 AQUEST社たってのお願いで7年ほど前に新ライセンスに移行しましたが、旧ライセンスに比べて 冷遇されている状況を思うと、趣味であるはずのプログラミングを苦痛に感じるようになりました。 AQUEST社とは一度話し合いの場が設けられることになりましたが、「ごあいさつ程度の意味合いで」 「食事のできるオープンなお店で」と言われたときに建設的な意見交換が望めないように感じ、 お会いしたくありませんと言
ミルクボーイがアジャイルを説明したら
序章駒場「最近、うちのおかんがシステム開発に興味を持っててなぁ、名前は忘れたらしいんやけど、迅速に開発できて、仕様変更にも対応できる、素晴らしい開発手法を取り入れてるところがあるらしいんやわ〜。」 内海「そんなもんアジャイルに決まってるがなぁ〜! 今やシステム開発と言えば、アジャイル。素早く変化に対応できるってゆーのが特徴なんよ。そもそも名前が “迅速” を意味する英語やねんから、アジャイルに決まってるがなぁ〜。」 チームの人数駒場「最初、オレもそう思たんやけどな、なんでも 40 人ぐらいで開発してるらしいんやわぁ〜。」 内海「ほなぁ、アジャイルちゃうかぁ…。アジャイルでは 5〜9 人ぐらいが推奨されてるからなぁ〜。40 人もおったら、とてもやないけど、コミュニケーションが成立するとは思われへんなぁ〜。効率の悪い伝言ゲームになるのは目に見えてるからなぁ〜。おかん、他にもなんか言うてなかった
実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
Android開発をする上で知っておいてほしいなと思うこと - こやまカニ大好き
現在の Android Developers の情報は非常に充実していて、Developer Guides を順に読み進んでいくだけで開発に必要な知識とGoogleが想定している(であろう)最も基本的な実装を学ぶことができる。 特にこの「基本的な実装」というものが重要で、これを知っておかないと開発者間の意思疎通がスムーズに行えなかったり、そもそも気をつけておくべき注意点を見落としがちになってしまう。 とはいえ、今の膨大な公式ドキュメントをただ読めというのは厳しいので、Android開発をする上で最低限理解しておいてほしい(と僕が思っている)事柄と、それについて知ることができるドキュメント類についてまとめてみることにする。 2018/03/25 : リリース周りについて別記事に追記した。 nein37.hatenablog.com 公式ドキュメントの重要ページ 公式ドキュメントと言った場合、
プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!
今やどんなビジネスでもITが関係している。ITを支えているのはソフトウェアだ。あらゆるものがソフトウェアで実現される時代になった。そんな事業や生活に密接に関わるソフトウェアだが、その開発について知られていないことも多い。 とくに経営者がプログラミング経験がないことで、ソフトウェア開発のリーダーシップをとるときに的外れなマネジメントをしてしまうことがある。あまねく経営者がプログラミング経験があれば良いのかもしれないが、それは現実的ではない。 プログラミング経験がなくても、せめてソフトウェア開発の特性について知っておくと良さそうなこともあると思い、なるべく専門用語を使わずに本稿を書いた。 プログラミングは製造ではなく、設計である いまだにソフトウェア開発を、ビルや家屋の建築に喩える人がいるし、工場でモノを製造するようにプログラムが作られると思っている人もいる。 ここが間違いのもとだ。ハードウェ
フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話 - Qiita
テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした： 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま
SIerからWEB系に転職して7年経ったので比較してみた
本記事ではSIerからWeb系の転職した筆者が働き方を比較した記事です。 技術や文化、企業風土や評価制度などあらゆる点でSIerとWeb系には違いがあります。 特にWeb系は退職金がなかったり年収が低かったりする傾向にあるためデメリットを把握しておくことも重要です。 この記事で詳細に紹介していきますので必ず最後までご覧ください。 働き方が自由そうなWeb系ですが実はデメリットも多いです。 例えば退職金がない企業が大半です。 さらにWeb系は薄利多売のビジネスモデルが多く、激しい競争環境のため利益率は低く給料が上がりづらい傾向です。 このようなデメリットを避けるために、メガベンチャーや業界No1の企業を選びましょう。 もし企業の探し方が分からない方はITに特化した転職エージェントに「メガベンチャーや業界No1の企業を紹介してほしい」と依頼しましょう。 当サイトではマイナビIT AGENTが人
良いエラーメッセージの書き方 - Qiita
エラーには大抵「エラーメッセージ」が付いています。 自分は過去に、エラーメッセージの内容を雑にしてしまい後悔することがよくありました。 その経験から、良いエラーメッセージの書き方を考えました。 エラーメッセージを2つに分類する まず、エラーメッセージといっても次の2つのパターンで大きく異なってきます。 (1) ユーザーが見るエラーメッセージ (2) 開発者が見るエラーメッセージ (1) ユーザーが見るエラーメッセージ 内部実装のことは書かないようにする
Markdownエディタを作って月15万円稼ぐためにやったこと — Inkdrop
自分でもびっくりしてるいぬさん僕はフリーランスをしながら脱受託を目指してアプリを作って生活しています。だいたい1年のうち7割ぐらいをアプリ作りの時間に充てています。本稿では、Inkdropというマルチプラットフォーム対応のMarkdownエディタを一人で開発して月15万円の売上を達成するまでにやった事を包み隠さずにシェアしたいと思います。 Inkdropの月間売上の推移やったこと概要毎日感じるちょっとした問題を見つける自分自身がこれだ！と思えるまでプロトタイプを作るプライベートβ期間でヘビーユーザを作る継続性を重視して価格をつける決済処理はStripeで楽に実装する良いランディングページを作るユーザサポートを最優先にする自分の得た知見を惜しまずブログに書くクオリティで勝負する批判を全て無視する毎日感じるちょっとした問題を見つける僕は別に特別でもなんでもありません。人は意外と同じ事を感じたり
［速報］Java 9が正式リリース、Javaをモジュール化するProject Jigsawがついに実現。今後のJavaは6カ月ごとタイムベースのアップデートへ
［速報］Java 9が正式リリース、Javaをモジュール化するProject Jigsawがついに実現。今後のJavaは6カ月ごとタイムベースのアップデートへ 米オラクルは9月21日（日本時間9月22日未明）、Javaの最新バージョンとなるJava 9正式版を公開しました。 Java 9 is Out!!!!#JDK9 #Java9 #Javahttps://t.co/VE7BI4KPlK pic.twitter.com/kOdNiLJ1ky — Java (@java) 2017年9月21日 Java 9最大の新機能は「Project Jigsaw」として開発されたJavaのモジュール化機能です。おそらくJavaの開発のなかでももっとも難産なプロジェクトだったといえるでしょう。 難産の末にProject Jigsawがついに実現 Javaをモジュール化して必要な部分だけを使えるようにする
iOSアプリ開発の全体像 - Qiita
超技術書展で頒布したiOSアプリ開発の全体像をだらだら書いた本を記事として公開。 ただのポエムです。 2年くらいまえに、SwiftもObjCも一切書いたことないし、アプリも一回も作ったことがない状況でiOSアプリを作ってリリースするミッションのお仕事が降ってきたので、そのときにこんな情報があったら全体が見通せて、気持ち的に楽だったなと思った内容をまとめました 1. iOSアプリ開発を取り巻く環境 iOSアプリ開発には、基本的にmacOSを搭載したコンピューターとXcodeとよばれるソフトウェアが必要です。もともと主にObjective-Cという言語が使われるケースがほとんどでしたが、2014年6月にAppleがプログラミング言語Swiftを発表して以後の新規開発には、ほとんどの場合Swiftが採用されているようです。またSwiftは、Objective-Cのコードと共存できるため、もともと
コーディング不要のディープラーニング開発ツール、ソニーが無償提供
コーディング不要で、ディープラーニングのプログラムを生成できるソフトウェア「Neural Network Console」を、ソニーが無償提供。 ソニーは8月17日、コーディングの知識がなくても、ディープラーニング（深層学習）のプログラムを生成できるソフトウェア「Neural Network Console」の無償提供を始めた。自社の製品・サービス開発にも利用しているツールを多くの開発者や研究者に使ってもらうことで「ディープラーニング技術の発展につなげる」という。 同社は今年6月、ディープラーニングのプログラムを生成する際に使うコアライブラリー（基盤ソフトウェア）「Neural Network Libraries」（以下、Libraries）をオープンソース化した。人間の脳を模倣した「ニューラルネットワーク」の設計、製品・サービスへの搭載を効率化する演算モジュール群だが、利用には高度なプロ
「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました - Hatena Developer Blog
はてなのアプリケーションエンジニアのid:shiba_yu36です。社内技術勉強会で「新機能作成時に開発ブランチに細かくmergeしていく戦略」という発表をしたので、資料を公開します。 speakerdeck.com 以下、簡単に文字でまとめておきます。 戦略 ユーザーに新機能が見えないようにする工夫をし、新機能のbranchもどんどん開発ブランチにmergeしていく mergeされたものは随時本番にリリースされるが、ユーザーに見えない工夫をしているので問題なし PRは可能な限り細かくする 機能が完成したら最後にユーザーに新機能を見えるようなPRを作り、mergeしてリリースする なぜこの戦略を使うのかいろんな失敗を経験して、この戦略を最近使っている。 失敗パターンその1: 巨大PRパターン 失敗パターンその2: 新機能リリースブランチパターン 失敗パターンその1: 巨大PRパターン 新機
個人開発のやっていき方
2017年7月20日に行われた Rails Developers Meetup #3 の発表資料です。
コードレビューの極意。それは「自分のことは棚に上げる」こと！！ - Qiita
はじめに：コードを良くするためなら遠慮は不要 昨日Twitterに投稿した内容が思った以上に拡散されていたので、タイムラインに流れてしまわないようにQiitaにも書いておきます。 内容は上に書いてあるとおりです。 コードレビューはコードの問題点を指摘し、そのコードを良くすることが第一の目的です。 そのため、少しでもおかしいと思った部分は遠慮せずにどんどんツッコむ必要があります。 しかし、レビューする側が「これ、自分もあまりできてないんだよなあ」「お前もできてないじゃん！って言われたら返す言葉もないし・・・」などと思って遠慮してしまうと、コードを改善できるせっかくのチャンスが失われてしまいます。 「自分ができているかどうか」と「そのコードを改善すること」は、それぞれ別の問題です。 なので、レビューする人は自分のことを棚に上げてでも、コードの問題点を指摘する必要があります。 また、レビューされ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【魚拓】みずほ銀行の炎上プロジェクトに支援に行ってきた話|問題編 - ここもちろぐ
GitHub English Challenge Cheat Sheet - Qiita
