【まとめ】これ知らないプログラマって損してんなって思う汎用的なツール 100超 - Qiita
2019/06/11追記: これは2012年の投稿です。なぜかはてなブックマークで拡散されていますが、内容は時代にそぐわなくなったものもあるのでご注意ください。 これ知らないプログラマって損してんなって思う汎用的なツールのコメントに寄せられたツールを分類分けしてみました。 解説は、ほぼコメントに寄せられた内容のコピペです。 URLのみの記述は公式サイト(か、ほぼ公式サイトと化しているサイト) 公式サイトとは別に、ページタイトルだけでツールを説明しきっているページへのリンクも付けておきました。類似ページが複数ある場合は、はてブのブックマーク数が多いものを選びました。 知らないツールもあるので、分類がいいかげんなところもあると思います。何か気づいたらコメントください。 解説が不十分なツールについても、補足（コピペで本文に取り込める体裁だとありがたい）を頂けると助かります！ 元ネタの投稿は現在進
俺史上最強のiptablesをさらす - Qiita
#!/bin/bash ########################################################### # このスクリプトの特徴 # # 受信・通過については基本的に破棄し、ホワイトリストで許可するものを指定する。 # 送信については基本的に許可する。ただし、サーバが踏み台になり外部のサーバに迷惑をかける可能性があるので、 # 心配な場合は、送信も受信同様に基本破棄・ホワイトリストで許可するように書き換えると良い。 ########################################################### ########################################################### # 用語の統一 # わかりやすさのためルールとコメントの用語を以下に統一する # ACCEPT :
ウェブ開発で大切な3つの環境: 開発・ステージング・プロダクション - Qiita
もはや常識だと思うが、ウェブシステム開発にあたって3つの環境はそれぞれ独立して用意しておくといい。（独立といっても同じサーバにあっても構わないこともある。） 開発サーバ: 開発者用テスト環境 ステージングサーバ: 顧客用レビュー環境 プロダクションサーバ: 本番環境 開発サーバ 開発者がコミットした内容を開発者が反映し、開発者がテストする環境。基本的に顧客や運用チームに見せることはない。 ローカル開発環境とは別に用意するのがポイント。「ローカルだと動くんだけど」病にいち早く気がつくために重要。ローカルはしばしば、開発者がライブラリへのリンクや各種設定を無意識のうちに行なっていて、そのためローカルでは動くがサーバでは動かないということがある。 この病の典型的な例としては次のようなものがある。 Case-Insentive環境(ローカル)で動くが、Case-sensitive環境(リモート)で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
