ngrok - secure introspectable tunnels to localhost🤯 Introducing Traffic Inspector - Observability right from the ngrok dashboard. Learn more ->
ソフトウェア開発におけるリスクと居心地の悪さについて - 表道具
アウトライン ソフトウェア開発には，時間の見積も，できるかどうかすらもわからない，リスクのあるタスクがある リスクのあるタスクには，逃げたり既存の工数などに載せないで，特別扱いしてちゃんと負担を減らしながらリラックスして取り組む環境を作るべき はじめに 何で自分がソフトウェア開発という分野に居心地の悪さを感じるのか考えていた．納期の短さが原因だけではないことは明らかである．やればできるし，ただそれだけだからである．それよりも，常につきまとう漠然とした不安が物事を見えにくくしている． 特にインタラクティブ・システムや拡張現実感技術，コンピュータビジョン，機械学習などの分野は，まだ単にライブラリを持ってきただけ機械的にシステムを構成できる分野ではない．そうでなくても，ある程度大規模で複合的なシステムなら，バグ1つの解消にえらく時間がかかったりする． このように，ある機能を実装したり，バグを取っ
書類仕事を追いかけて - steps to phantasien
大きなコードベースの真ん中あたりをさわっていると、仕事の大半はリファクタリングに費やされる。機能を足そうと書くコードも 8 割リファクタリングで新緑は 2 割。失敗して捨てるものも多いから、かける時間は 9 対 1 くらいかもしれない。 それどころかリファクタリング自体がプロジェクトにもなりうる。「今四半期はこの腐ったコードどもをなんとかするのが目標」というように。私もいま大きなリファクタリング、あるいはリアーキテクティング、の手伝いをしている。仕事時間のほぼすべてがリファクタリングに費やされる。今の勤務先で通用する唯一の特技がリファクタリングな私にとってこれはたぶん適職だ。 リファクタリングにコーディングの大半を捧げる人は他にもいる。 プログラマ相手の管理職をエンジニアリング・マネージャと呼ぶ。ほぼ全員プログラマ出身。現場に近いマネージャは多くがコードも書く。ただ血気盛んな人を除くと新機
開発環境のデータをできるだけ本番に近づける - クックパッド開発者ブログ
こんにちは。技術部の吉川です。 今回はクックパッドの開発環境構成、特に開発用データベースの構成についてご紹介します。 開発環境の構成 クックパッドのシステム環境は以下のようなフェイズに分かれています。 ※ これはcookpad.comの構成で、サブシステムや個別のサービスはその規模や特性に応じて構成が異なります。 development 開発者が実際に開発を行う環境です。クックパッドでは仮想環境は用いず、手元のマシンでRailsアプリケーションを動かして開発を行っています。 データベースはローカルではなく、開発者全体で共通の開発用データベースに接続しています。 test 手元でテストを実行する場合は、ローカルマシンのデータベースを利用します。CI（rrrspec）などの場合も同様で、テスト実行サーバーのデータベースが利用されます。 staging stagingといえば準本番環境として、本
そのガチャの確率、本当に合ってます？〜RSpecで統計的に確認する話〜 - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
背景 ソーシャルゲームでよく見かける「ガチャ」ですが、この記事ではその重み付き確率の保証方法を紹介します。 ガチャは売上・ユーザー体験・ゲームバランスに直結するので、意図通りの動作をするか慎重に確認する必要があります。 またアカツキではTDD (Test Driven Development)を採用しているので、 実装したプログラムが想定している確率に従っているかを確認するためのスペックが必要となります。 理論 使用する数理モデルは「離散確率密度変数」です。 例えばガチャで入手できるキャラクターのIDが であり、 その入手確率が (実装の便宜上自然数としますが、非負の実数としても一般性を失いません)によって重み付けされているとします。 このとき、ID のキャラクタが入手できる確率は、 となります。 さて、10000回の試行（ガチャを引くこと）をしたとき、入手できる確率が50%のキャラクタを
モダンなチーム開発環境を整える | サーバントワークス株式会社
モダンなチーム開発環境 モダンなチーム開発環境の考慮ポイントの図解 ソフトウェア開発は、ビジネス価値を創造する一翼を担っていますので、ビジネスアイデアをビジネス価値に転換するビジネスパーソンの意向は、とても大切です。それを「動くソフトウェア」にするために、開発エンジニアリングを行うわけですが、それがとても複雑であるということです。ウォーターフォールモデルで開発できる場合は、工程ごとにガッツリ全体を作っていくのである意味シンプルに見えます。しかし、それらの成果の関連や追跡可能性を考えてみるとウォーターフォールモデルで追跡可能性を創出し、維持することはとても難しいことはわかってきます。では、アジャイルな開発、優先順位を決めて、提供可能なものを選んで開発し、提供し続けるモデルの場合は、企画ー計画ー開発ービルドーデプロイが何度も繰り返されるだけではなく、パラレルに動くことが要求されます。たとえば、
Code Anything
DevLOVE2012 ■GitHub Activity Tunes http://labs.unit8.net/github-activity-tunes/ ■Cert Publisher http://www.youtube.com/watch?v=xOjqAgwE9lM ■Longadeseo http://www.youtube.com/watch?v=eyROLXJzYJ8 ■Redmine Impasse http://www.youtube.com/watch?v=61BsQc-PMZI ■Bootstrap customize maven plugin http://www.youtube.com/watch?v=2x7IeJgBBgQRead less
継続的Webサービス改善ガイド 記事一覧 | gihyo.jp
第5章ビジネス視点の改善～効果検証に基づく機能改善と、チームでの仕事の進め方 安宅啓 2014-02-21
第2章 開発環境の改善～技術的負債の返済と、レガシーコードの仕様化テスト | gihyo.jp
技術的負債と開発環境の改善 本章では、サービスの成長とともに大きくなる「技術的負債」に着目し、筆者が勤務するpaperboy&co.（以下、ペパボ）で取り組んでいる開発環境の技術的負債を返済していく具体的な方法について紹介します。 技術的負債とは 技術的負債は、英語でTechnical Deptと呼ばれます。技術的負債の「概念」が最初に登場したのはWikiの開発者として知られるWard Cunninghamが1992年に発表した「The WyCash Portfolio Management System」という報文の中です。そこから年を経ること17年後の2009年に、アジャイルソフトウェア開発宣言などで知られるMartin Fowlerによって「技術的負債」という名前が付けられました。 Webサービス開発での技術的負債の例 技術的負債は、サービスを構成するソースコードそのものであるアプリ
ストーリー、エピック、テーマ by Mike Cohn - kawaguti’s diary
「アジャイルな見積りと計画作り」の著者マイク・コーンさんがブログで、「ストーリー」と「エピック」の使い分けについて説明していましたので、だいたい訳して載せておきます。 ちょうど最近、ストーリーとエピックについてご質問をいただいたので、これを参考にしていただけるとうれしいです。 ストーリー、エピック、テーマ ( STORIES, EPICS AND THEMES by Mike Cohn) http://blog.mountaingoatsoftware.com/stories-epics-and-themes 最近、「ユーザーストーリー」「エピック」「テーマ」の違いがわからないというメールを受けることがだんだん多くなってきている。今回はこれらの用語を説明する事を通じて、基本的な(でもとても役立つ)領域に立ち返り、確認していく。 まず、この用語にはあまり深い意味はない。この用語には、プログラ
技術的負債を抱えた状態で技術者がすべきこと - sandbox
この Qiita のエントリに触発され、元文章の目的はさておき、技術的負債についての自分の考えを書いてみようと思う。 技術的負債の定義や、問題は下記エントリを参照して頂くとして、なかでも最後の「技術者がすべきこと」について、「自分だったらこの様にアプローチするか」ということを書く。 技術者がすべきこと 大前提 開発前にステークホルダー(ここではプロジェクトの責任者とする)に、プロジェクトの性質として何を重視するかを認識、選択してもらう。 短期的な価値実現を最優先とし、初速を重視、ソフトウェアの健全さ、プロダクトの成長速度を犠牲にする 長期的な価値実現を最優先とし、ソフトウェアの健全さ、プロダクトの成長速度を重視し、初速を犠牲にする 1 を選択するという事について、健全でない状態や、成長速度が犠牲になった状態がどの様なものかを、プロジェクトが走り出す前に十分に認識してもらう必要がある。 …と
技術的負債 - Qiita
この文章の目的 開発者とステークホルダーが「技術的負債」という言葉で正しくコミュニケーションをとれるようになることをゴールとする。技術的負債については色々な所で語られるが、実際の現場では技術的負債が管理されてない事が多いのでは無いだろうか。この場で技術的負債という言葉についての知見をまとめ、たたき台とする事で、ゴールに到達する第一歩としたい。 対象読者 開発者 責任者/見積もりに対して決定権を持つ人 技術的負債とは何か 技術的負債とは、コード・設計の状態を表す見積もりのための言葉である。継続的に開発を行う上で理想状態から離れたものを負債という比喩で表していている。 たとえば、省略可能なプロセスを飛ばす事で開発の高速化を行う事があり、初期開発を高速に行う開発者の中には意識的・無意識的問わずこれを行っている事例が多々存在する。このようにして抱えられた技術的負債は長期的に見た場合に問題を引き起こ
エンジニアの「出来る」を正しくマネジメントする為に必要なこと - GoTheDistance
この記事面白かったです！ 「出来る」と「実装する」の間には多くの解決すべき問題が含まれているから気をつけろよっていう警鐘を鳴らしている記事なのに、「出来るからやるって単純バカなんだけど」っていう反応が多いのが印象的でした。その理由の９割は、タイトルに「エンジニアはネ申」って書いたせいだと思うけど。 私からは、社内業務システム内製を通じて感じました、創造主であるところのエンジニアとハッピーに仕事をするためにはこういうことを一緒に考えよう、っていう話をしたいと思います。 実装可能と実現可能は別問題 前述の記事も僕の補足も、主題はこれだけ。だいたいそんな感じ。でも、順を追って説明します。 技術的に実装可能なのか否かは、当然一番最初に考える問題です。そこでNoならこの話は終わります。技術的と簡単にまとめますが、エンジニアによって判断基準は全然違うから悩ましいです。そこは差し引いて、単純に求められた
Base DDD(ドメイン駆動設計） 参考文献を巡る旅
より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料：http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ
Githubの組織が成長する過程で変えたことと変えなかったこと - ワザノバ | wazanova
GithubのZach Holmanが語るGithubの組織戦略です。まず最初に、 Step #1: ロックスターエンジニアを雇う Step #2: ものすごく透明性のある経営をする Step #3: ブログ/ソーシャルメディアなどでテクノノロジーについて発信する Step #4: カンファレンスで会社について話す Step #5: カネに余裕ができる Step #6: 社員を大勢雇う Step #7: 会社のことを話さなくなる Step #8: コミュニティを無視する Step #9: 創業者が株を売って儲ける Step #10: 別の会社をはじめる という事例を挙げて、Githubは組織が成長する中で、このようなパターンに陥らないように、コミュニケーション及び仕事の進め方をどのように進化させてきたかについて紹介してます。 Dunbar's numberとしてよく知られるとおり、人間が良
Ruby製アプリじゃなくてもTurnipで自動受け入れテストがしたい - orangain flavor
Python製のWebアプリケーションの自動受け入れテストをしたくて、調べてみました。 Ruby界隈だと、最近ではCucumberに代わってTurnipというツールが流行っているみたいなので試してみました。 (c) .foto project 自動受け入れテスト用のライブラリ Rubyで自動受け入れテストをしようとすると、以下の3つの選択肢があるようです。 Cucumber テストケースを自然文で書けるため、非プログラマでも読みやすい。 Turnip Cucumberと似ているが、プレースホルダーを簡単に書ける点とRSpecの一部として使える点がメリット。 RSpecのfeature spec RSpec（+Capybara）で完結。非プログラマには読みにくい。 Cucumberは以前にも使ったことがあるので、今回はTurnipを選択してみました。詳しい説明は以下のページに譲ります。 Ru
microservicesに分割する際に注意するべき5つのこと - Qiita
はじめに マーティンファウラーがmicroservicesの記事で、小さな役割をもったサービス群にアプリケーションを分割することを提案しています。 cookpadが、サービスをマイクロサービス群に分割していることの記事が注目を浴びており、最近急速にバズワード化しているように感じます。 バズワード化して、ポイントが損なわれる前にいくつかの注意点をまとめておきます。 1.インフラコストは基本的に増大する microservicesは、今まで単一のアプリケーションコードで行われていたことを複数のサービスサーバーに分割して管理・運営していくことです。ですので、プロセスを跨いだ通信が大量に発生します。その結果、サーバー台数は増大します。 つまり、インフラコストの増大と開発速度の高速化のコスト感覚をバランスして判断していく必要があります。疎結合性が高まり、アーキテクチャとしては美しく感じますが、実施に
DMM inside
日本アニメ初の快挙！海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
コマンドラインツールについて語るときに僕の語ること #yapcasia
http://yapcasia.org/2014/talk/show/b49cc53a-027b-11e4-9357-07b16aeab6a4
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Developers Summit 2014 「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」
