技術的負債について考えた - 考えた。
技術的負債についての自分の考えをまとめます。 言いたいこと 最初から綺麗なコード・設計を書ける状態を目指せ。 そうもいかないものは天秤だが、勝手に背負うな。 技術的負債とは？ 技術的負債は事業リスクです。放置することによって事業が失速したり損害が発生したりするため、適切に取り扱う必要があります。 負債の種類と対応は、以下の三つに別けられると自分は考えています。 1. 新規で書く末端機能のクソコード・クソ設計 最初から綺麗なコード・設計を書けるを目指すべきですが、時間がかかるのであればスピード重視でよいでしょう。 「もっと良いように書けるべきだけど、どうすればよいか？」とコメントでも添えて、さっさとプルリを投げてしまうべきです。 末端機能で、あとで上に乗っかる物がないのであればコードの品質はそれほど問題ではありません。テストを整備しておけば、後でレベルが上がったときに綺麗にできるでしょう。
バグをドラゴンと呼ぶ運用を始めて1ヶ月くらいたった - Konifar's WIP
1ヶ月くらい前、 「バグをドラゴンと呼んだらどうなるか」というTweetを見ました。 確かに、バグをドラゴンと読んだ場合「Sクラスのドラゴンが出ました！」「Aクラスのドラゴンを相手にしてる最中だってのに！」って会話になるし、ドラゴンは結局人の手で生み出されたものってところが中二ファンタジーっぽくて良い— 尾野（しっぽ） (@tail_y) March 18, 2015 これは天才的発想だなと思って職場で雑談で話してみたところ、 同僚のスペイン人エンジニアにバカウケしまして、 それからちょいちょいバグのことをドラゴンと呼ぶようになりました。 せっかくなので、どんな雰囲気になるのかまとめてみようと思います。 先に言っておくと、自分ともう1人スペイン人エンジニアが時々チャット上で使っているだけで、 正直そんなに流行ってないです。 なんかテンションが上がる バグ修正ってマイナスをゼロにするだけで何
「【DeployGate x はてな】スマートフォンアプリ開発最前線」を4/13（月）に開催します！ #hatenatech - Hatena Developer Blog
こんにちは、はてなチーフエンジニアの id:onishi です。 このたび、株式会社デプロイゲートさんと共同で「【DeployGate x はてな】スマートフォンアプリ開発最前線」と題し、スマートフォンアプリ開発に関するセミナーを開催します。 DeployGateさんと、はてなの開発チームのエンジニアスタッフが、スマートフォンアプリ開発の最前線について発表を行います。 前半では各社での具体的な取り組みの発表をおこない、後半はパネルディスカッションの場をもうける予定です。 セミナー後は、ささやかですが懇親会も予定しています！ みなさまのご参加をお待ちしています。 「【DeployGate x はてな】スマートフォンアプリ開発最前線」に申し込む 16:20 追記 応募者多数につき 100名から 150名に席を追加しました！ 開催概要 セミナー名：【DeployGate x はてな】スマートフォ
Kazuho's Weblog: 「技術的負債」は避けるべき？ - 割引率を使って考えてみた
「技術的負債」をコントロールする定量評価手法への期待 からの続きです。 ソフトウェアサービス企業における技術責任者の最も重要な仕事のひとつが、エンジニアリングの効率化です。そのためには、サービスの初期開発コストだけでなく、運用コストを織り込んだ上で正しい技術的判断を行っていく必要があります。 「技術的負債」という言葉は、この運用コスト最適化の重要性を指摘する上で、とてもキャッチーなフレーズだと考えられます。しかし、「技術的負債」を産まないように、あるいは負債を早めに返していこうとすると、開発工数が大きくなってしまうという問題もあります。 初期開発コストと運用コストのバランス注1を、どのようにとっていけば良いのでしょう？ 同等の機能を提供する「ソフトA」と「ソフトB」を考えてみます。ソフトAは、初期開発工数が6だが、２年目以降の維持工数が毎年4かかるとします注2。ソフトBは、初期開発工数が1
【後編】大先輩のフリークアウトCTOが語ってくれた、マネジメントの深くてイイ話
＜前編のあらすじと後編のお話＞ 本企画のホストである伊藤直也（以下「naoya」）と、『フリークアウト』執行役員であり『ヤフー』のフェロー／名誉黒帯でもある明石信之（以下「明石」）。意外にも初顔合わせとなる二人だったが、Web業界を長年リードし続けてきたという共通項もあり、酒肴を愉しみながらのマネジメント談義は大いに盛り上がりを見せた。明石氏が『フリークアウト』に参画後、色を組織名にするなど、破天荒とも思える組織マネジメントの実例も披露され、その深い洞察にもとづく一手に、naoya氏は大いに感銘を受けるのだった――。 ⇒【前編】の記事はこちら 【後編】となる今回は、明石氏の『フリークアウト』における取り組みを掘り下げていくことで、そのマネジメント論の神髄に迫っていきます。大の魚好きという点でも一致する二人の会話は、酒の力もあってますますヒートアップしていきます。 — naoya：チーム名の
プロダクトオーナーとエンジニアの役割分担が失敗した話
By: Magic Madzik 友達から「優秀なエンジニアが会社をやめた」という話を聞いた。まぁ、とても残念な話ではあるだろうが、友人の話がなぜか心の奥にひっかかっていたので、考えをまとめながらここに書いてみる。 衝突と絶望 あるエンジニアがいた。彼はあるプロダクトに長く貢献していた人物だ。最近、組織や体制が変わったことにより、プロダクトの作り方や方針に変化がでてきた。 やがて、プロダクト面とエンジニアリング面で衝突がよく起きるようになった。 プロダクト面からは、決まった方針とともに作業が降りてくる。プロダクトに責任を持つ立場だとすればその気持ちもわかる。一方で、プロダクトを愛し、これまでに貢献してきたというプライドを持ったエンジニアの気持ちもわかる。エンジニア視点の意見も当然あるだろう。 ひとつのプロダクトに関わっているはずなのに、両者には溝が生まれた。 そして、当初、そのエンジニアは
【後編】七転八倒の先に見出したCTO道――グリーCTOに、色々ホンネで聞いてみた / 飲み会で探るエンジニアのホンネ #naoya_sushi 編
＜前編のあらすじと後編のお話＞ 寒風吹きすさぶ師走の夜、伊藤直也氏（以下「naoya」）が寿司屋に招いたのは、かつての上司でもある『グリー』CTOの藤本真樹氏（以下「藤本」）。インターネット業界におけるCTOの第一人者であり、私淑するエンジニアも多いことで知られる藤本氏だが、焼酎片手に語り出したのは、かつてマネジメント業務で四苦八苦したという反省の歴史。CTOとしての藤本氏の“凄さ”を知る伊藤氏にとっては意外な話のオンパレードで、会話のボルテージは時とともに高まっていくのであった――。 ⇒【前編】の記事はこちら さて、今回の後編では、藤本氏のCTOとしての取り組みをさらに深掘りすることで、いかにして「CTOとはかくあるべし」と開眼するにいたったのかを明らかにしていきます。実は生魚が苦手という藤本氏ですが、今のところは料理も愉しんでいただいている様子で一安心。ぼちぼち酔いもまわってきて、二人
今まで経験したプロジェクトでありがちな展開と、エンジニアとしてアウトプットしていくパターン - mizchi's blog
なんか最近、(比較的)アウトプットしてないな、とふと気づいたんだけど、よく考えたらプロジェクトの進捗のフェーズによってアウトプットの分量が偏るのはいつものことだなー、とも思った。 それらのフェーズを前期、中期、後期、運営期で考えみる。 初期段階 おそらくライブラリの選定段階から始まる。この時期のアウトプットは、いわゆる「やってみた系」の記事が増える。ウェブに出る記事だと、これが大多数をしめる。汎用性が高く、技術的に挑戦的なものが多い。(立場的な話をするとQiitaはそういう記事がたくさん共有されると助かる) 選定が終わった段階で、アーキテクト的な役割の人は、たぶんこうあるべきだ、みたいな思想を形成する。それをクラス図やコード規約や役割に応じたドメイン特化基底クラスとして表現したりする。DDD的なアレならこれをユビキタス言語の構築としてプロジェクトを通してやるべきなんだろう。 使う予定のフレ
スタック・オーバーフロー
python × 134 javascript × 53 python3 × 43 c++ × 32 linux × 30 html × 27 c × 24 java × 22 c# × 20 android × 18 vscode × 16 google-apps-script × 16 typescript × 16 ruby × 15 windows × 15 ruby-on-rails × 14 pandas × 14 swift × 13 php × 13 mysql × 13 css × 13 postgresql × 12 ios × 11 bash × 11 shell × 11 macos × 10 docker × 10 r × 10 rust × 10 aws × 9 ubuntu × 9 アルゴリズム × 9 laravel × 9 正規表現 × 9 network
組織能力を圧倒的に成長させること - Kentaro Kuribayashi's blog
この記事は、Pepabo Advent Calendar 2014の12日目の記事です。前日は、hisaichi5518さんの「Web APIを作るときに考えること。 - パルカワ2」でした。 ここ半年ほど考えていることを、以下に述べる。 技術とは何か？ 「技術とは何か？」という問いに対しては様々な回答があり得るが、ひとまず「企業にとっての技術」という観点からいえば、経営学による以下の記述にその定義を求めてもよいだろう*1。 すべての企業が、自分が必要なインプットを市場から買ってきて、それに自分が得意とする「技術的変換」を加えて、その結果として生まれてくる製品やサービスを市場で売っている。 (中略) 誰にでも容易に手に入る財やサービスであれば、とくに企業が存在してその提供を業とする必要はない。その提供プロセスが難しいからこそ、その困難さを解決する努力が企業の「技術的変換」になるのである。
『Webアプリエンジニア養成読本』お役立ちリンク集をつくった - the code to rock
少し時間ができたので、『Webアプリエンジニア養成読本』を読み返しつつ一個一個コードを実行させて新たなチャレンジを進めています。 Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus) 作者: 和田裕介,石田絢一(uzulla),すがわらまさのり,斎藤祐一郎出版社/メーカー: 技術評論社発売日: 2014/03/11メディア: 大型本この商品を含むブログ (5件) を見る 今はRuby編のSinatra入門をやっていますが、たしか以前に同じ部分を読んだ時はけっこう早い段階で「ん・・書いたとおりにやってるのに出来へんやんけ・・」とか勝手にハマって断念とかしていた記憶があるのだけど、それってどこだったっけ、というぐらいスイスイ進んでいます。 まあ、おそらく以前のそれは今年の3〜4月ぐらいで、先日ようやく収まっ
発注者「簡単なアプリです」エンジニア「簡単か否かを決めるのはお前じゃない」
発注者「誰かiPhoneアプリ作ってくれませんか？簡単なアプリです！！」 エンジニア「簡単かどうかを決めるのはお前じゃない。」 — のり@食べるの大好きエンジニア (@sugi511) 2014, 11月 10 発注側と受注エンジニア側だけでなく、同一社内の営業と開発という部門間でも生じやすいギャップのお話。はた目にはシンプルそうに見える、ちまたに沢山出回っているから簡便そうに見える、だから作るのも簡単だろう。作ってくれませんかと発注側は語るけれど、実のところ開発が簡単か否かを決めるのは発注側では無くて開発側。 数枚、あるいは数行の仕様での発注案件でも、いざ開発してみると山ほどのリソースを投入して数か月かけても終わらないという事案も山ほどある。プログラム、アプリ開発周りで分かりにくければ、料理などが分かりやすいかな。シンプルに見えるけど目新しくて美味しい料理。そこにたどり着くまでにどれほど
Google、モバイルBaaSのFirebaseを買収、クラウドに統合へ。モバイルアプリのオフライン対応、リアクティブプログラミングなどを実現
Google、モバイルBaaSのFirebaseを買収、クラウドに統合へ。モバイルアプリのオフライン対応、リアクティブプログラミングなどを実現 Googleは、モバイル向けのバックエンドサービス、いわゆるモバイルBaaSを提供しているFirebaseの買収を発表しました。 Googleは以前からGoogle Compute Engineなどにモバイルバックエンド向けのフレームワークを提供していましたが、今回のFirebaseの買収によってその機能が飛躍的に強化されることになりそうです。 FirebaseはいわゆるモバイルBaaSで、Webアプリケーションやモバイルアプリケーションの開発者向けにスケーラブルなバックエンドサービスを提供しています。 JavaScript、Objective-C、Javaに対応しており、開発者はこれらのプログラミング言語を用いてクライアント上でデータベースを操作
Travis CIでiOSアプリのリリース作業を自動化する - 24/7 twenty-four seven
この記事において利用している.travis.ymlとRakefileの全体はGistにて公開しています。 ↓ Rakefileの全体はこちら gist.github.com/kishikawakatsumi/8918124 ↓ .travis.ymlはこちら gist.github.com/kishikawakatsumi/8918365 概要 ユビレジではiOS アプリを申請する際に発生する作業の大部分をCIで自動化しています。 申請の作業としてユビレジでは下記のワークフローを決めています。 1. リリースブランチを作る 2. リリースするバージョンのバイナリをビルドする 3. 2と同等のアプリケーションを社内に配布して最終チェックをする 4. クラッシュレポートのサービスとしてCrittercismを利用しているので、そこにデバッグシンボル（dSYM）をアップロードする 5. 2のバイ
テスト駆動開発（TDD）はもう終わっているのか？ Part 1 | POSTD
後編を公開しました（2014/10/8） これは、テスト駆動開発（TDD）とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2～3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
モダンWebシステム開発
デザイナーとエンジニアの良い関係
コードレビューの話
Amazon.co.jp: Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール: 塩谷啓, 紫竹佑騎, 原一成, 平木聡: 本
TechCrunch
