「なぜDI(依存性注入)が必要なのか？」についてGoogleが解説しているページを翻訳した - Qiita
イマイチ理解しきれていなかったDIに関して調べていところ、Google Guiceの解説がすごく分かりやすかったので、和訳してみました。 （ところどころ意訳気味です。明らかに解釈の誤った訳がありましたら、ご指摘ください） ちなみにGoogle Guiceというのは、Googleが開発したDIライブラリです。この例ではJavaが使用されていますが、Scalaでも使用可能です。最近Play Frameworkでも採用されたので話題になっているようです。 用語の定義 本文を読む前に目を通すことで、内容をスムーズに理解できます。 用語 意味 本文中の例
OMake つかったらC言語でプログラム書く手間がバカみたいに減った - 日記を書く[・ _ゝ・]はやみずさん
OMakeすごい。OMakeはマジですごい。 OMakeはGNU makeの代替品みたいなものなんだけど、正直なところこのツールの強力さはGNU makeと比べると失礼なくらいすごい。これのおかげで、「コード修正→ビルド→デバッグ→コード修正→・・・」のループの、ビルドにあたる作業がほぼ消え去った。 ファイルの依存関係の解析がとにかくすごい。よくあるユースケースなんかの場合、最小限の手間でほぼ完璧に依存関係を網羅して、よしなにビルドしてくれる。 とりあえず、はやみずが実際に使ってみたケースを例にとってそのすごさの一端を紹介しようと思う。 case study 論より証拠ということで、自分が OMake を試しにつかってみたケースを紹介する。C言語でスタティックライブラリを作っていて、それに加えて簡単なテストプログラムを書いている。 /include/ 以下にヘッダファイルが全部ある /sr
![OMake つかったらC言語でプログラム書く手間がバカみたいに減った - 日記を書く[・ _ゝ・]はやみずさん](https://cdn-ak-scissors.b.st-hatena.com/image/square/04e015dad70084a57fdfa9a2686c0c93441c5d2d/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127128184977%2F17680117127128193858%2F1557447212)
ニコニコ動画(く)リリース失敗に寄せて
そういうわけなので今日は公開資料を中心にリリース失敗の技術的な要因を分析してみたいと思います。 Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - QiitaドワンゴアカウントシステムはScalaのコードだけで22万行を越え、ドワンゴ社内で最大のScalaリポジトリとして知られています。 ドワンゴのユーザーアカウント基盤は明らかに破綻しています。 10 年以上にわたり、ガラケー時代から今に至るまで多くの業務をコードに落としていくことは極めて難しい作業であったと思います。そうはいってもやってるうちに一回なんとか出来なかったのかとは思うわけです。やっている当人たちがテンションを上げているほどには開発効率が出ていない、むしろ足を引っ張っているという可能性はかなり高いと思います。 ニコニコ生放送におけるdock
友人から「しんぺいさん DI について書いてほしい」みたいな話をだいぶ前からされてたんだけど書く気力ずっとなかった。でも仕事の気分転換にちょっとずつ書いたやつがいい量まとまったので公開するです。たいしたことは書いてないっていうか知ってるひとにはあたりまえのことしか書いてない。サンプルコードはわたしの趣味で Scala で書いてあるが、Java が読めればなんとなく読めると思います。 DI ってなに Dependency Injection、日本語で言えば依存性の注入です。おしまい。 で記事を終えてもいいんだけど、そもそも依存性とはなんなのか、それを注入するとはどういうことなのか、なぜ DI が必要となるのかみたいな話をこれからします。 そもそも依存性ってなあに 例を出します。入力された文字列をもとにおみくじをひいて、その結果を twitter に投稿するプログラムにしましょう。 まずは普通
以下の文章は、Martin Fowler の「Inversion of Control Containers and the Dependency Injection pattern」を、かくたにが翻訳したものです。原著者の許可を得て翻訳・公開しています。 翻訳にあたっては、kdmsnr さんにご協力をいただきました。ありがとうございます。公開後の改訂履歴を記事の最後に記述しています。 Java コミュニティでは軽量コンテナが花盛りである。 軽量コンテナは、異なるプロジェクトのコンポーネントをひとまとまりのアプリケーションとして組み立てることを支援する。 このようなコンテナの根底には、コンポーネントの結び付け方についての共通したパターンがある。 そのパターンのコンセプトは「Inversion of Control(制御の反転)」と、まことに包括的な名前で呼ばれている。 本記事では、このパタ
本記事はRubyについて書かれたものではありますが、Python、JavaScript、Javaなど、全ての言語コミュニティに当てはまる事実を述べたものです。依存関係が引き起こす負の連鎖は誰のためにもなりません。 上の図は、私がこれまでに使用した全てのRailsアプリの依存関係を可視化したものです。以下の例はいずれも、どこかで聞いたことのあるものではないでしょうか。 何百ものエントリを含むGemfile 本番環境で読み込まれるテスト用Gem 数百メガバイトもRAMを食うRailsのプロセス Rubygemsシステムは、それを再利用する誰もが容易にRubyのパッケージを作ることができるという点で、賞賛に値するものです。しかし、その便利さが意味するところは、そうしたGemと他のGemを非常に安易に結び付け、さらにそれが、「インターネットでダウンロード」され、数百もの依存関係を持つRailsアプ
Railsフロントエンド技術の今とこれから
待望されたYarnサポートの入ったRails5.1が2017年4月にリリースされました。 Ruby on Rails 5.1 Release Notes — Ruby on Rails Guides 他にもjQueryがデフォルトdependencyから外されたり、Optionalでwebpackサポートが入ったりしており、Railsのフロントエンドは大きな転換点を迎えたと言ってよいでしょう。本エントリではRailsのフロントエンド技術の今を振り返り、今後どうなっていくかをまとめてみたいと思います。 DisられてきたRailsフロントエンド Railsのフロントエンド技術スタックは、フロントエンドを専業とするエンジニアにDisられるものでした。具体的には下記の技術要素です。 jQueryCoffeeScriptAssets Pipeline (sprockets)gemのエコシステムに乗っ
こんにちは Rails5.1に向けて、DHHのjqueryを依存から外す発言を発端にフロントエンド周りが急激に発展しているので、簡単にですがまとめてみました。 各issue, PRの詳細には踏み込みませんが、知見に溢れているので読んでみるの推奨です。 間違い、足りないものがあったら編集リクエストお願いします。 jQuery依存を無くす話が出る rails(issue): Drop jQuery as a dependency jquery-ujsはjqueryに依存しないようにする jquery-ujs: Drop jQuery as a dependency "jquery"-ujsじゃなくなったので名前変更 rails-ujs誕生 実際にRailsからjquery依存がなくなる rails: Drop jQuery as a dependency jsライブラリを入れる方法がnpmパッ
意外と分からずに、「とりあえず」とか「なんとなく」で使っちゃうパターンが多い系案件な気がして書いてみます。 こんな事ありませんか？ DIとDIコンテナの違いを説明出来ない DIとサービスロケータの違いを説明出来ない DIを使ってるつもりが、サービスロケータになっている DI、サービスロケータが、ただの「パターン」の１つであることを理解してない DI(Dependency Injection)を正しく理解する そもそも、Dependeny Injectionを日本語にするとどういう意味になるでしょうか。 多くの人が「依存性の注入」とか応えるのではないでしょうか？ 私もそうでした。きっと何かで読んだのでしょう。 (wikipediaに「依存性の注入」と書いてありますね) 補足 なぜ依存性を注入してあげると良いのか、そのメリット等は後述しますが、 DIというのはただのパターンの１つです。 たまに
テンプレートエンジンのくせに最近のPHPはオブジェクト志向やらDIやらイキり始めた件 - JavaScriptをがんばるブログ
※2017/05/29現在Repositoryの章までしか聞けていません。聞いている際に浮かんだインスピレーションが揮発しないよう永続化する為に書いた記事です。 php-genba.shin1x1.com まさか日本語でこの内容を聞けるコンテンツがあるとは思わなかったです。 これは英語をマスターすれば Sound of Symfony The Laravel Podcast Ruby on Rails Podcast JavaScript Air devchat.tv などのPodcastからより多くの興奮を得られる事を意味します。 プログラミング経験3年、細かい修正ばかりで設計レベルの経験値が全くない自分ですが、各章について以前から個人的に思っていた事、お三方の知見からインスピレーションを得た内容を書き残します。 1. DI 「依存性の注入(Dependency Injection)」と
汎用的なコードの依存関係の抽出ツール rexdep を作りました！ ― 正規表現で依存関係を大雑把に抽出しよう！ - プログラムモグモグ
あらすじ ソフトウェアの中の依存関係について 正規表現で抽出できることとその限界 コードの依存関係を抽出するツール rexdep を作りました ソフトウェアの構造を概観するには あなたは、大きなソフトウェアを目にした時、何をしますか？ ファイルが何十、何百もある時、どこから読みますか？ ソフトウェアが巨大になると、そのコードの構造を把握するのは難しくなります。 特にプロジェクトに入りたての人にとって巨大なコードベースを一目で理解することは難しく、細かなタスクをこなしていく中で徐々に「どこに何が書いてあるか」を理解していくしかありません。 ソフトウェアによってはモデルとコントローラ、データベースとビューと言った具合にコードが分かれており、これくらいの分類はディレクトリ名を見れば理解できるかもしれません。 しかしそのようなざっくりとしたコードの分類が分かったところで、ソフトウェアの構造を理解し
« Re: Go でシングルバイナリな Web アプリを開発しているときに webpack --watch をうまいところやる | Main | Ruby の a = a + 1 はなぜ undefined method '+' for nil:NilClass なのか » golang にはパッケージマネージャが無数にあります。 PackageManagementTools · golang/go Wiki · GitHub Home Articles Blogs Books BoundingResourceUse cgo ChromeOS CodeReview CodeReviewComments CodeTools C... https://github.com/golang/go/wiki/PackageManagementTools 僕もその一つの gom というのを開発している
Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita
DIを使わない状態ではUserRepositoryというインターフェースが定義されているのにもかかわらず、UserServiceはUserRepositoryImplの参照も持っていました。 これではせっかくインターフェースを分離した意味がありません。 UserServiceがUserRepositoryインターフェースだけを参照(依存)するようにすれば、具体的な実装であるUserRepositoryImplの変更に影響されることはありません。 この問題を解決するのがDIの目的です。 それではDIのインジェクタを加えて、上記のクラス図を修正しましょう。 謎のインジェクタの登場によりUserServiceからUserRepositoryImplへの参照がなくなりました。 おそらくインジェクタは何らかの手段でサービスであるUserRepositoryImpl(Dependency)をクライアン
やはりあなた方のDependency Injectionはまちがっている。 — A Day in Serenity (Reloaded) — PHP, FuelPHP, Linux or something
今日はPHP界隈で大人気のDependency Injectionと、それに関連する用語について整理しておこうと思います。 以下のような状況があるのではないか？と思ったからです。 多くのPHPユーザがDependency Injection（DI）をよくわかっていない、あるいは正確に説明できません。 そして、デザインパターンである「DIパターン」とDIをサポートするツールである「DIコンテナ」を混同しています。 また、「DIパターン」と「サービスロケータパターン」をうまく区別できていません。 Dependency Injectionとは何か？ Dependency Injectionとは「Dependency」を「Injection」するというデザインパターンです。 日本語では何故か「依存性の注入」と訳されており、これが混乱の元ではないかと思います。 日本語で「依存性」と言うと、「依存性は
Go言語のDependency/Vendoringは長く批判の的になってきた（cf. “0x74696d | go get considered harmful”, HN）．Go1.5からは実験的にVendoringの機能が入り，サードパーティからはDave Chaney氏を中心としてgbというプロジェクベースのビルドツールが登場している．なぜこれらのリリースやツールが登場したのか?それらはどのように問題を解決しようとしているのか?をつらつらと書いてみる． Dependencyの問題 最初にGo言語におけるDependecy（依存解決）の問題についてまとめる．Go言語のDependencyで問題なのはビルドの再現性が保証できないこと．この原因はimport文にある． Go言語で外部パッケージを利用したいときはimport文を使ってソースコード内にそれを記述する．このimport文は2通りの
LLRBというRuby向けのメソッドJITコンパイラを書いている github.com RubyKaigi 2015の最後のキーノートで@evanphxが「LLVMでCRubyのコードをインライン化するメソッドJITを実装したら速いんじゃね」みたいな発表をしていたのを覚えているだろうか。 LLRBというのはまさにそれを実装しているプロジェクトであり、少なくとも現時点で「LLVMでCRubyのコードをインライン化するメソッドJIT」と言える状態まで実装でき、ものによっては効果が出る状態になったので公開した。 なんで書いてるの 言語を自分で実装するとその言語に関する理解が大分深まる、というのをHamlの実装とかCコンパイラとかで体験していて、僕が一番好きな言語はRubyなのでRubyでもそれをやっておきたい、というのがあった。また、Rubyは遅いと言われがちだが、どこに改善可能な点が眠っている
現代開発を加速させる古来の術式
浮かない顔をしておるな。ワケを話してみよ。 npmの依存パッケージが増えた ふむ。npmで依存パッケージを増やしたと。それで？ なに、他の開発者から 動かない と言われたのか。で、毎回 npm ciをしてくれ と頼んでいるわけか。 …その問題、半世紀ほど前に解決されておるぞ。 何かの縁じゃ。お主に開発環境を自動更新する古来の術式を教えてやろう。 詠唱準備 手始めに適当なパッケージを作るかの。今からの操作は空ディレクトリの中で作業していくぞ。 お主がNode.jsをインストール済であれば、
SpringでField InjectionよりConstructor Injectionが推奨される理由 - abcdefg.....
SpringでField InjectionよりConstructor Injectionが推奨される理由を調べてみたメモです。 (2016/12/30) サンプルコードにfinalをつけるように修正 (2017/03/29) Immutabilityについて追記 --- 家でも会社でもIntelliJを使って開発しているのですが、 Spring Bootで@Autowired(@Inject)を使うと下記のような警告が出るようになりました。 警告内容を見てみると、フィールドインジェクションは推奨されません、とのこと。 「Field injection is not recommended.」 警告の詳細を見てみると下記のように書いてあります。 「Field injection is not recommended. Spring Team recommends: "Always use
先日アナウンスされた脆弱性とその周辺について、とりとめなく。 The npm Blog — Package install scripts vulnerability Vulnerability Note VU#319816 脆弱性の概要 VU#319816 によれば、今回問題になっているのはnpmの以下の性質を利用するとnpmパッケージでワーム（自己増殖力のあるマルウェア）を作れるというもの。 依存パッケージのバージョンをロックせず、semverにより範囲指定することが多い CLIで一度npmへloginすると、明示的にnpm logoutするまで認証が永続化される npm registry が中央集権型サーバーである 具体的な手法として、Chris Contoliniが PoC として pizza-party というリポジトリを公開している*1。以下のように動作する。 ワームが仕込まれ
Dependency Walker is a free utility that scans any 32-bit or 64-bit Windows module (exe, dll, ocx, sys, etc.) and builds a hierarchical tree diagram of all dependent modules. For each module found, it lists all the functions that are exported by that module, and which of those functions are actually being called by other modules. Another view displays the minimum set of required files, along with
Home page | Yarn
Yarn is a package manager that doubles down as project manager. Whether you work on simple projects or industry monorepos, whether you're an open source developer or an enterprise user, Yarn has your back. This documentation covers Yarn 4+. For the previous documentation dedicated to 3.6 and below, please refer to v3.yarnpkg.com. WorkspacesFirst package manager built specifically around workspaces
RequireJS はみんな使ってるらしーし、 何かかっこいいし、意識高そうだし、使っとくか！ ・・・と、思って試しに使い始めてみたのですが、 自分が作るような小規模なものの場合、 大変な割に良い事あんまりないので使うのを止めました。 以下、忘れそうなのでその理由をメモって置きます。 基本的に、1枚のJSファイルが1モジュール、ファイル名がコードに影響する。それもあって、結合・圧縮は r.js という専用のツールが必要になる。Grunt の concat とか uglify とか使えない。 AMD の仕様では、「JSファイルのリストを順番通りに読み込み/実行する」ということができない。実際何が困ったかというと、分割した mocha テストケースを順番通りに実行できなくなったということ。結果は変わらなくても、順番通りに実行されないと結果が見辛いし、問題が起こった時に発見が難しい。ただしこれは
Gradle Build Tool
Gradle Build Tool accelerates developer productivity Gradle is the open source build system of choice for Java, Android, and Kotlin developers. From mobile apps to microservices, from small startups to big enterprises, it helps teams deliver better software, faster. Build Anything Write in Java, Kotlin, C++, or any language of your choice. Package for deployment on any platform. Go monorepo or mul
Maven - Welcome to Maven
Dependency Injection の基本的なアイディア Inversion of Control コンテナと Dependency Injection パターンを読みました。関連する事柄を広くカバーした、隙のない記事です。 ただ、割とボリュームがあるので、「Dependency Injection って結局何なの?」ということを手っ取り早く知りたい向きにはあまり向かないかもしれません。そこで、基本的なアイディアを手短にまとめてみました。 Dependency Injection (依存性注入、DIと略) とはその名の通り、依存性を注入するパターン (テクニック) です。もう少し言葉を加えると、依存性を内部に抱え込まずに外部から注入する、パターンです。 Dependency Injection の基本的なアイディアは「依存性を外部から注入する」です。 DIコンテナと呼ばれるフレームワ
実戦での Scala: Cake パターンを用いた Dependency Injection (DI) · eed3si9n
2011-04-23 Akka の作者として益々注目を集めている Jonas Bonér が 2008年に書いた “Real-World Scala: Dependency Injection (DI)” を翻訳しました。翻訳の公開は本人より許諾済みです。翻訳の間違い等があれば遠慮なくご指摘ください。 2008年10月6日 Jonas Bonér 著 2011年4月22日 eed3si9n 訳 さて、実戦での Scala シリーズ第二弾の今回は、Scala を用いた Depenency Injection (DI) の実装をみていきたい。Scala は、備わっている言語機構だけを用いても何通りかの DI を実現できる非常に豊かでディープな言語だが、必要に応じて既存の Java DI フレームワークを使うこともできる。 Triental では、一つの戦略に落ち着くまで三つの異なる方法を試した
今日は、iOSエンジニアの@orakaroです。 iOSエンジニアの皆さん、iPhone Xの対応はいかがでしょうか？ メルカリアッテはようやくSwift4／RxSwift4／iPhone Xの対応が落ち着いたところです。 このブログでは、10月11日に開催した Souzoh iOS Talkの中で発表した メルカリ アッテを支えるオートマトンについて、より詳細な内容をお伝えします。 当日のスライドは下記になります。 speakerdeck.com 会員登録フロー 会員登録フローを実装する時に、以下のような基本的な機能を実装することがあります。 メールアドレスとパスワードで登録できること メールアドレスとパスワードでログインできること Facebookで認証（登録、ログイン）できること パスワード再発行できること さらに、メルカリ アッテのようにセカンドパーティーのアプリなら、メルカリ連携
CoRecursiveより。 今日の番組では、リチャード・ヒップと、サバイバルが世界の中核インフラになることについてに話します。SQLiteは至る所にあります。ウェブブラウザにも、携帯電話にも、おそらく車の中にも、そして旅客機の中にも間違いなく存在します。iMessagesやWhatsAppのメッセージが保存されているのもSQLiteです。コンピュータで*.dbを検索すると、驚くほど多くのSQLiteデータベースが見つかります。 今日は、リチャードが彼の物語を紹介します。小さなオープンソースのプロジェクトを立ち上げ、それが自分の野心を超えて成長したという話です。そして、テック巨人との関係から、興味深いテスト方法まで、その成功をどこまでも追いかけていく物語です。 注: このポッドキャストは、聞くことを前提としています。可能であれば、ページに記載されていない部分を含めて、音声を聞くことを強くお
Rust の DI を考える –– Part 2: Rust における DI の手法の整理 - paild tech blog
paild 社でお手伝いをしている yuki です。前回に引き続き Dependency Injection 略して DI の話題を書いていきたいと思います。今回は Rust における DI についていろいろと考えてみました。今回紹介する実装はかなり単純な例を用いたもので、この記事からさらにみなさんのアプリケーションの実装状況に合わせていくつか工夫は必要になるかもしれません。ただ、とっかかりとしては十分なものになっていると思うので、DI でお困りの方はぜひ参考にしてみてください。 今回実装したいアプリケーションのお題について 今回紹介する技法の種別について コンストラクタインジェクション 静的ディスパッチを用いたもの 動的ディスパッチを用いたもの 静的ディスパッチと動的ディスパッチの利点・欠点 shaku （DI コンテナ）を用いたインジェクション shaku の利点・欠点 余談: DI
Help us learn about your current experience with the documentation. Take the survey! '> To bring existing projects to GitLab, or copy GitLab groups and projects to a different location, you can: Migrate GitLab groups and projects by using direct transfer. Import from supported import sources. Import from other import sources. Migrate from GitLab to GitLab by using direct transfer The best way to c
Dependency Injectionとはコンポーネント間の依存関係をプログラムのソースコードから排除し、外部の設定ファイルなどで注入できるようにするソフトウェアパターンである ってwikipedia先生が言ってました。 Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita を読んでいろいろ考えたので、なんで今さらって感じのことを書きます。 ScalaでDIというとDIコンテナとかCake PatternとかReader Monadとかって話になっちゃうんですが、これらはいかにかっこよくDIするかの話であって、別にこういった道具やパターンを使わなくてもDIは可能という話です。 Constructor Injection 簡単な例で考えます。今ここにUserRepositoryにべったり依存し
はてなブログ | 無料ブログを作成しよう
パスタ習作#2 飽き性な性格なのに#1を書いた以降も意外とパスタ熱が冷めなかった。当たり前のことだが、基本が分かってくると応用ができる。応用ができると自由度が増す。自由を手に入れると継続ができる。批評家の福尾匠が自身の日記に、小倉知巳のペペロンチーノのレシピはよくで…
gemspecにRUBY_VERSIONによるif文書くのは意味がないので今すぐやめるべき - くりにっき
自戒です tl;dr 発端 間違った対処法 だがしかし sonots先生曰く 検証結果 所感 Rubyのバージョンによる分岐を全部Gemfileに寄せた結果 謝辞 tl;dr gemspecの中でRubyのバージョンによってインストールしたいgemのバージョンを変えたい時は、gemspecではなくGemfileでif文書くのがおそらく正解 発端 先月くらいのFacebook内のちょっとした会話がきっかけでした *1 activesupportやactiverecord 5系以降ではRuby 2.2.2以降必須になった https://github.com/rails/rails/blob/v5.0.0/activesupport/activesupport.gemspec#L10 自分のgemがactivesupport (activerecord)に依存していた場合、そのままだとRuby
Prioritize and remediate risk exposure with Snyk AppRisk for ASPM.
GitHub
バーガーショップで例えるオールアバウトでのLaravelアーキテクチャ - オールアバウトTech Blog
オールアバウトで開発チームに所属している@pakkunです。 12月も近くなり、大きく時期から外れてしまいますが、弊社では8月から9月にかけてサマーインターンを行いました。 その際に弊社で導入しているLaravelというPHPフレームワークの付き合い方を資料とライブコーディングでインターン生に説明しました。 抜粋になりますが、弊社でのLaravelとの付き合い方をブログでも公開します。 とは言え、Laravelを知らない人もいるかと思いますので、まず初めに軽く説明します。 3行でLaravelを知る PHPで書かれたフルスタックフレームワーク。 MVCベース。 PHP界隈ですごく流行っている。 MVCベースと記載しましたが、開発者のTaylor Otwellさんは「MVC Is Killing You」と著書で言っており、MVCに縛られると辛くなるので、あまり深くとらわれないようにしましょ
こんにちは、シニアアプリケーションエンジニアのid:taraoです。はてなエンジニアアドベントカレンダー2014の21日目として、依存先のファイルが更新されたらコンパイルしなおす処理をgulpで実現する方法について、とくにLessを例にとって紹介します。 はてなでは、JavaScriptやCSSなどの静的ファイルをTypeScriptやLessなどからコンパイルして生成することが増えています。CSS(Less)は主にデザイナが書くため、コンパイル手順はできる限り簡単にする必要があります。多くのチームでは、サーバアプリケーションをローカル環境で実行している最中はファイルの変更に応じて自動的にコンパイルしなおすようになっています。 ファイルの更新監視からコンパイルまでの処理にはGruntなどを使ってきましたが、コンパイル対象のファイルに依存関係がある場合、依存先のファイルの変更に応じて依存元の
by @dekokun on 2013/05/21 23:46 Tagged as: Capistrano, Fabric. 最近、Fabric, Capistranoと立て続けに2種類のデプロイツールを使ってデプロイ環境を構築する機会がありましたので、その際に感じた両者の利点を書いてみたいと思います。 両者の簡単な解説 そもそもCapistrano, Fabricについて、「片方は知っているけど片方は知らないよ」という人がいるかと思いますので、簡単な説明をします。 両方とも何かを知らない人は…「自動デプロイ」とかそのあたりで検索してみるといいんじゃないですかね。 Capistranoとは Ruby製のFabricみたいなものです Fabricとは Python製のCapistranoみたいなものです Fabricは私の中ではデプロイツールという認識なのですが、最近Chefと比較されること
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
要するに DI って何なのという話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
Inversion of Control コンテナと Dependency Injection パターン
依存関係をなくそう : Rubyアプリ・Gemの開発者への提言 | POSTD
Rails5.1に向けてフロントエンド周りで起こっている革命まとめ - Qiita
DI・DIコンテナ、ちゃんと理解出来てる・・？ - Qiita
Big Sky :: golang オフィシャル謹製のパッケージ依存解決ツール「dep」
Go言語のDependency/Vendoringの問題と今後．gbあるいはGo1.5
CRuby向けのLLVMベースのJITコンパイラを書いている話 - k0kubun's blog
npm install scriptの脆弱性とオープンソースと信頼 - teppeis blog
Dependency Walker (depends.exe) Home Page
RequireJSを使うのを止めた理由 | それなりブログ
Dependency Injection の基本的なアイディア - bkブログ
オートマトンを活用したiOS版メルカリ アッテの会員登録画面 | メルカリエンジニアリング
リチャード・ヒップとのSQLiteの秘話
Import and migrate groups and projects | GitLab
DIについてあれこれ - tototoshi の日記
新横浜密着情報シンヨコのサイト
Open Source Insights
gulpで依存関係を考慮した自動コンパイル - Hatena Developer Blog
デプロイツール比較 CapistranoとFabric