GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている
GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている 4月10日でサービス開始からちょうど15周年を迎えたGitHubは、当初からRuby on Railsを用いたモノリシックなアプリケーションとして作られてきました。現在では200万行近い規模のコードになっているそうです。 今年1月にはGtHubを利用しているデベロッパーが1億人に到達したことも発表しました。GitHubはまさに世界最大級のRailsアプリケーションだと言っていいでしょう。 そのGitHubは5年前の2018年、Railsのバージョンを3.2から5.2に上げる作業に1年半を費やし。そして二度とこのようなことにならないよう、より頻繁にアップデートを行うべき、などの教訓を得たとしていました。 そして現在、GitHubは毎週月曜日にRailsのアップデート作業
BUNDLED WITH で Gemfile.lock が更新されてしまう件 - Qiita
BUNDLED WITH って何？ bundler 1.10.0 以降で作成された Gemfile.lock では、BUNDLED WITH というセクションがあって、使用された bundler のバージョンがトラックされるようになっている [3485] 。 例えば bundler 1.9.0 で作成された Gemfile.lock のあるプロジェクト上で、 最新の bundler 1.10.3 を使用して bundle install --path vendor/bundle すると、 Gemfile.lock には以下の差分ができる。 これをもう一度 1.9.0 で bundle install すると、上の文字はきれいさっぱり消える。 BUNDLED WITH の何が困るか 多人数で開発するときには、この変更は微妙に邪魔で、意図しない Gemfile.lock 変更が出てしまうことで
Goを使い複雑性を回避する | POSTD
『銀の弾などない— ソフトウェアエンジニアリングの本質と偶有的事項』 を書いたFred Brooksはその論文の中で、 偶有的な複雑性と本質的な複雑性 について重要な区別をしています。 本質的な複雑性 とは、問題特有の領域から生じる複雑性のことを指します。例えば、SMTPクライアントを作成しているディベロッパは、 RFC 5321 の核心の細かいところ全てに取り組む必要がありますが、これはSMTPクライアントの作業をする上で避けては通れないものです。これに対して 偶有的な複雑性 とは、私たちが自ら作り上げた問題から生じる複雑性のことを指します。 技術者としては、自らの選択で生じる偶有的な複雑性によって、余計な負担が増えないようにとても注意しなければなりませんよね。その意味では、言語の選択は偶有的な複雑性を軽減できる完璧な例と言えます。Webアプリケーションを書くのにアセンブリ言語を選びます
composer install をどこで実行するか
最近の PHPer が集まれば、一度は話題に上がるのが、この composer install をどこで実行するのか問題。 これまで聞いた話をまとめると、大きく分けて、以下の２パターンになります。どちらの方法を取っているか教えて下さい 😀 0. 前提 前提ですが、以下のような方法で、Composer 関連のファイルは管理しているとします。おそらく多くはこのような形になっていると思います。 PHP コードは、Git などの VCS で管理する。 composer.json, composer.lock は、VCS で管理する。 composer.phar, vendor/ は、VCS で管理しない。 また、今回対象としているのはアプリケーションで、Packagist に登録して、配布するようなフレームワークやライブラリは対象外です。 1. 本番サーバで実行 本番PHPサーバ上で compo
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
wheelを使ってPythonのC拡張モジュールを本番デプロイする
Pythonの話。wheelを使ってC拡張モジュールをデプロイする仕組みが上手く稼動したのでメモ。 依存パッケージの本番デプロイ アプリケーションが依存しているPythonパッケージをどうやって本番サーバーにデプロイするか。大抵はrequirements.txtにpip freezeで吐いた内容を保存しているだろう。とすると、本番サーバーでpip install -r requirements.txtすれば良いんだが、githubが落ちてたりPyPIが落ちてたりすると、外部要因でデプロイスクリプトが途中でコケる、というダサい事態になる。それを避けるために事前にパッケージを固めて各サーバーに配布する仕組みが必要になる。C拡張モジュールを使いたいけど本番サーバーでCコンパイラが自由に使えない、という時も同様で、事前にコンパイル済みの物を配布する必要がある。 pip bundleを使う場合 (d
ポータブルなWebアプリケーション - naoyaのはてなダイアリー
140文字で書ききれなかったのでブログに殴り書き。 Heroku のアプリケーションを人に渡す 昨日、「naoyaさんが作ってるiOSアプリのバックエンドサーバーに相乗りさせてもらえないか」という話をいただいた。自分でも同じようなAndroidアプリを作っているけど、サーバーサイドは作ってないからということらしい。 対して「githubにコードあるからgit cloneしてheroku pushすれば動くし、自分で heroku にデプロイしてよ」と応えた。相乗りしてもらってもよかったのだけど、こちらでコードを書き換えたりメンテしたときに先方のアプリが停止することを考えると同じコードベースでサーバーは自分で立ててもらう方が何かと良い。 対象になったソフトウェアは Heroku で動かしていたので、Heroku Ready な形、つまり、必要な外部パッケージの一覧やサーバーの起動手順なんかは
PHP: The Right Way
ようこそ 時代遅れの情報がウェブ上にあふれている。そんな情報を見たPHP初心者は戸惑ってしまうだろう。そして、まずい手法やまずいコードが広まってしまう。 そんなのはもうやめよう。PHP: The Right Way は気軽に読めるクイックリファレンスだ。PHPの一般的なコーディング規約、 ウェブ上のよくできたチュートリアルへのリンク、そして現時点でのベストプラクティスだと執筆者が考えていることをまとめた。 大事なのは、 PHPを使うための正式なお作法など存在しない ってこと。 このサイトの狙いは、はじめて PHP を使うことになった開発者に、いろんなトピックを紹介すること。 経験豊富なプロの人にとっても、これまで深く考えることなく使ってきた内容について、新鮮な見方を伝えられるだろう。 このサイトは、決して「どのツールを使えばいいのか」を教えるものじゃない。 いくつかの選択肢を示して、それぞ
www.phptherightway.com
Welcome There’s a lot of outdated information on the Web that leads new PHP users astray, propagating bad practices and insecure code. PHP: The Right Way is an easy-to-read, quick reference for PHP popular coding standards, links to authoritative tutorials around the Web, and what the contributors consider to be best practices at present. There is no canonical way to use PHP. This website aims to
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
実例で学ぶGoプログラム開発