このように独立したポートが必要なとき*3に $PORT を利用することで汎用性が保たれます。 $PORT の開始番号を指定する(-p, --port) 標準では $PORT は 5000 から始まります。しかし、以下のように指定すると 6000 から始まるようになります。 foreman start -p 6000 foreman は、主に Web アプリケーションと非同期/定期処理とを並列動作させる目的で使われます。 その場合、Procfile の先頭に Web アプリケーションを書くという慣習があります。それは Web アプリケーションが利用するポート番号がわかりやすいからです。 foreman を止める foreman を正式に止めるには、foreman のプロセスに SIGTERM を送信してください。 foreman は起動した個々のプロセスに対して SIGTERM を送信し、全
ついにGAになったdocker for macとdocker for windows。これでVirtualboxやVMWareを別途インストールする事なくdockerが利用可能になりましたね! docs.docker.com docker for macですが、既にdocker toolboxでdocker一式をインストールしている状態でも、特に何かをアンインストールする事なくdocker for macをインストールすれば、途中でマイグレーションする?と聞かれてそのままdocker-machineからdocker for macに移行できます。 という事で早速試してみたのですが、MySQLのコンテナにリモートで接続しようとして、ちょっと困った事が起きました。 MYSQLコンテナにつながらない!? MySQLコンテナを起動する 何故localhostではダメなのか my.cnfを指定したm
伊藤直也さんが「些末なコードレビュー」というエントリを書いて話題になっている。このエントリで伊藤さんはコードレビューの話と、はてなのJavaScriptの話と2つの話題に触れている。前者のコードレビューについてはアプレッソでは8年ほど前から「コードレビューを通っていないコードはコミット不可」というルールですべてのソースコードに対してコードレビューを必須にしてきた関係で私も思うところがあるので、エントリを書いてみようと思う。 伊藤さんが例示しているように、インデントやreturnの省略などの話は好みの問題であり、議論してもソフトウェアの改善につながらない。なのでコードレビューでこうした宗教論争が起こるようなら、コーディング規約を見直すべきだ。「無駄に悩んだり議論したりすることを減らす」ことはコーディング規約の主たる効果のひとつだと言える。 コードレビューに慣れないチームが、何の考えもナシにコ
「HRTの原則」という言葉をご存知だろうか。 これは書籍 Team Geek ―Googleのギークたちはいかにしてチームを作るのか で紹介されている言葉であり、本書ではほぼ一冊すべてをかけてこのHRTの原則とその実践方法とを様々な角度から紹介している。 1. 謙虚(Humility) 2. 尊敬(Respect) 3. 信頼(Trust) の3つの価値が大切にされており、エンジニアとしてもチームや組織、顧客との対話においてこれらの価値を重んじていくことが成功につながる、というものである。 あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ Team Geek p.15 プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。君が思っている以上に、チームは個人の生産性や幸福に直接影響するのである。 Team
積んであった Beautiful Code を読んでみる. 第一章はカーニハンによる正規表現の話. 数十行のコードで簡単な正規表現を実装してみせる. パターン文字列を内部表現に変換せずマッチに使うぜ, コードも短い, ビューティホー! ...という主張なのだが, それはほんとにビューティホーなのか. UNIX 人の感覚にはついていけない. それにしても彼らは正規表現が好きだ. いつものその話ばかりしている. artu はいうまでもなく プログラミング作法 にも正規表現が出てきた. まったくこのマンネリめ. そう斜に構えつつ読み直してみると, 案外ラディカルな話も載っているのに気付く. 9.7 "オンザフライコンパイル" より: Ken Thompson はまさにこの方法によって 1967 年に IBM7094 上に正規表現を実装した. 彼のバージョンは, 正規表現に含まれる様々な処理を小さ
This account is no longer active. For updates on status, head to https://www.stackstatus.net/ OverviewOn July 20, 2016 we experienced a 34 minute outage starting at 14:44 UTC. It took 10 minutes to identify the cause, 14 minutes to write the code to fix it, and 10 minutes to roll out the fix to a point where Stack Overflow became available again. The direct cause was a malformed post that caused o
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く