はじめに 自分の場合、CentOS上でRailsを動かしていることが多いので、OSディストリビューションやカーネル(32bit or 64bit)情報、rubyやRailsのバージョンなどを示すのが良いと思う。 参考にするときに環境情報が分からないと困ることがあるので、みんな載せると良いと思う。フレームワークや言語によってちょっとずつ違うと思うので修正すると良いんじゃないかな。 まずは自分から載せてみよう。
![Qiitaに書くときに示しておきたい環境情報 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/9afcb959930ac8b0a9a302ec55f4924526170c38/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9UWlpdGElRTMlODElQUIlRTYlOUIlQjglRTMlODElOEYlRTMlODElQTglRTMlODElOEQlRTMlODElQUIlRTclQTQlQkElRTMlODElOTclRTMlODElQTYlRTMlODElOEElRTMlODElOEQlRTMlODElOUYlRTMlODElODQlRTclOTIlQjAlRTUlQTIlODMlRTYlODMlODUlRTUlQTAlQjEmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtY2xpcD1lbGxpcHNpcyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTIwMWI3MmMzZWM3ZjBjMDUwZTgwMGRmZTk4Mzg1MjIw%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwbm9yaWFraSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9Nzg0ZmI2NmJiOWYxMWFiZmZhNGQ2YzdmNGVhNWQwZjM%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D731d17a6de1d281b08bd3179239b63f8)
コマンドラインツールについて語るときに僕の語ること - YAPC::Asia Tokyo 2014 コマンドラインツールが好きで昔からつくってきた. 今年のYAPCで,そのコマンドラインツールをつくるときにどういうことを意識して作っているのか?どのような流れで開発しているのか?といったことを語る機会をもらえた. 具体的な内容については,是非トークを聴きに来てもらうとして, スライドをつくるにあったって過去に読んだ資料や,よく参考にしている記事を集め直したので,その一部を参考資料としてまとめておく. UNIXという考え方 UNIXという考え方 Mike GancarzによるUNIXの思想や哲学をまとめた本.古いが全然色あせてない. コマンドラインツールの作り方を書いた本ではないが,これらの思想の上で動くツールはこの思想に準拠して作られるべきだと思う.何度も読んで考え方を染み付かせた. 小さい
git-ignore add みたいのが欲しい— azu (@azu_re) August 24, 2014 ちょろっと書けそうだったので書いた。 yuroyoro/git-ignore · GitHub Demo Installation PATH通った場所においてくれ curl -sL https://raw.githubusercontent.com/yuroyoro/git-ignore/master/git-ignore > ~/bin/git-ignore Examples `git ignore add "pattern"`で、.gitignoreへ追加する。 $ git ignore add '*.log' .gitignoreから削除するには、`git ignore remove "pattern"`を実行する。 $ git ignore remove '*.log' a
シェルスクリプト入門として, 基本的な書き方をまとめました. 長いですが, 1ページにまとめてみました. 良かったら目次も参考にしてご覧になって下さい. 目次 シェルスクリプトとは 作り方, 実行の仕方 コメント ユーザーからのキーボード入力を受け付ける 変数 通常の変数 特別な変数 演算子 数値計算演算子 比較演算子 コマンドを繋げる演算子 条件文に使える比較演算子 条件文 制御構文(分岐) if文 case文 制御構文(ループ) for文 while文 until文 select文 文字列処理 文字列置換 削除 複数行のテキストの出力(ヒアドキュメント) 関数 シェルスクリプトとは シェルスクリプトとは, シェルの動作をまとめて記述したスクリプトのことです. 決められた文法にしたがって処理を記述することによって, シェルでの処理をまとめて行ったり, 作業を自動化できたりします(例 複数
session.gc_probabilityの値を書き変えると、こういうエラーが出るようになる。 PHP Notice: session_start(): ps_files_cleanup_dir: opendir(/var/lib/php5) failed: Permission denied (13) in /var/www/(以下略) 通常、PHPでセッションを開始すると、一定の確率で古いセッションファイルが削除されるようになっているが、ubuntuではアクセス権がなくエラーになってしまう。 ここに説明があった。 Obscure error with PHP5 on Debian/Ubuntu debian系(ubuntu含む)では、セッションファイルの保存ディレクトリがrootでないと読めないので、cronで削除するようになっている。PHPのセッションファイル削除機能は、実行する確
しばらくLinuxネタが続く・・。 近いうちに最近出たJava8ネタを書いてみようと思います。が、もう少しLinuxネタにお付き合いください。 前回はsshdを対象に親プロセスをkillした場合の動作を確認した。 killされたプロセスの子プロセスは孤児プロセスとなり、カーネルによって自動的にinitプロセスの子として扱われる事を説明した。(この動作を「リペアレンティング」と呼ぶ) 今回はこの続き。 Linuxで作業していてCtrl+Cしてプロセスを終了した場合、フォアグラウンドのプロセスやその子プロセスも一緒に終了する。 ということは、子プロセスは孤児として扱われず、リペアレンティングされていないことになる。 今回の記事ではこの振る舞いの違い(リペアレンティングされるか否か)に着目し、kill -SIGINTコマンドとCtrl+Cの違いについて考えていく。 そもそもkillコマンドやCt
はじめに サーバを運用したり環境を構築したりしていて「あれ。あのプロセスで吐いてるログどこだっけ・・」など困るときがあります。 そんなときに頼りになるかもしれないコマンドを 3つご紹介します。 @madeth 師匠に教えていただきました。 1. proc でプロセスが使っているファイルを見る 困ったこと プロセスの吐くログのパスがどうしても分からない・・。 解決法 (編集 2014/09/10) 知りたいプロセスの ID を調べます。 $ ps aux | grep unicorn deploy 3335 xxx xxx xxx xxx X XX 15:14 0:07 unicorn master -c /var/www/myproject/unicorn/staging.rb -E staging -D プロセスID (この場合は 3335) をもとに root 権限でファイルディスクリ
何に関連して記事を書こうと思った訳でもないです。たんなる一人コードリーディングです。 GNU CoreUtils に入ってる rm を読みました。 GNU Project Archives http://ftp.gnu.org/gnu/coreutils/ 読んだのは coreutils-8.17.tar.xz に入ってる src/rm.c preserve_root 変数は 203行目にある main で int main (int argc, char **argv) { bool preserve_root = true; struct rm_options x; true に初期化されていて319行目 if (x.recursive && preserve_root) { static struct dev_ino dev_ino_buf; x.root_dev_ino = get
ASCII Booksのサイトをご利用いただき、ありがとうございます。 2016年12月6日をもちまして、サイトを閉鎖させていただくことになりました。 今までサイトをご利用いただき、ありがとうございました。 アスキー・メディアワークスを引き続き、よろしくお願いいたします。
cles::blog 平常心是道 blogs: cles::blog NP_cles() « X220 が Fan Error. により完全に沈黙 :: X220 のファンユニットを交換 » 2014/06/04 /etc/init.d/hoge start と service hoge start は何が違う? systemmanagemant cli 214 4へぇ 普段、Linux でデーモンを制御するには /etc/init.d/hoge というスクリプトを叩いている*1のですが、あるマニュアルを読んだら service hoge を使いましょう的なことが書いてありました。 試してみると確かに /etc/init.d/hoge start の代わりに service hoge start としても同じようにデーモンが起動できるようです。 ただ、困ったことに僕にはこの2つの違いが
ログファイルを空にしたいときなど、いつも忘れるので・・・。 : > file % : > file これが一番シンプルですね。 : という区切りのコマンドがあり、それを file にリダイレクトしてあげるとファイルが空になります。man bash には以下のように記述されています。おそらくzshでは一番シンプルです。 ・・・ A : separates the event specification from the word designator. ・・・ ・ ・ ・ SHELL BUILTIN COMMANDS Unless otherwise noted, each builtin command documented in this section as accepting options preceded by - accepts -- to signify the end of
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか? この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
シェル上だと動くのにcron上だと動かない。 よく聞くお話ですよね。 大体はcron上と普段のシェル上で環境変数が違うために起こる問題です。 そういう時に使えるtipsを共有します。 個人のマシン上で適当に動かすようなcronだと みたいにしてログインシェルを間に噛まして環境変数を上書きして実行することでごまかしたりもできます。 これまた別の依存する箇所を増やすので 個人のマシンかrcファイルがちゃんと管理されているような状況以外ではオススメできません。 なのでcron上で実行される状況とほぼ同じ状況でスクリプトを実行してみましょう。 cron上では環境変数はほぼ空なので環境変数を空にしてみましょう。
README のファイル名は慣習的にすべて大文字(であることが多い) GitHub でプロジェクトを作るときに README を作成するオプションを入れておくと、README.md というファイルができる。それ以外の場所のプロジェクトでも README.txt や README など、ファイル名がすべて大文字になっているものをよく見かける。 なんか気持ち悪いなぁ、って思ってました。 readme でいいじゃん、と。 詳解 Linuxカーネル 第3版 作者: Daniel P. Bovet,Marco Cesati,高橋浩和,杉田由美子,清水正明,高杉昌督,平松雅巳,安井隆宏出版社/メーカー: オライリー・ジャパン発売日: 2007/02/26メディア: 大型本購入: 9人 クリック: 269回この商品を含むブログ (71件) を見る 調べてみた README - Wikipedia, th
MySQL Performance Blogの翻訳。インストール後に必ず設定を確認しなければならない設定パラメータ10つを挙げ、その意味を解説する。MySQLの設定変更時の、一般的な注意点も合わせて。 January 28, 2014 By Stephane Combaudon 我々がパフォーマンス監査の仕事をする時には、MySQLの設定のレビューと改善提案を求められる。大抵の場合、たくさんのオプションがある中でほんのいくつかの設定しか変更するように提案しないことに、多くの顧客は驚く。この記事のゴールは、もっとも重要な設定をいくつか挙げてみることにある。 既にこういった提案は過去にもしているが数年前のもので、それ以来MySQLの世界ではたくさんの変化があったのだ。 話の前に 熟練した人でも、重大なトラブルを引き起こすミスをしでかすことがある。従って、ここに挙げたものを盲目的に適用する前に、
tar tvf ファイル名 で表示。 $ tar tvf ./test.tar drwxr-xr-x hoge/fuga 0 2007-03-18 11:18:49 ./dir/ -rw-r--r-- hoge/fuga 20374 2005-03-13 02:36:51 ./dir/piyo.txt gzipで圧縮されたtarだった場合は、tar tvfz ファイル名。 $ tar tvfz ./test.tar.gz drwxr-xr-x hoge/fuga 0 2007-03-18 11:18:49 ./dir/ -rw-r--r-- hoge/fuga 20374 2005-03-13 02:36:51 ./dir/piyo.txt bzip2で圧縮されたtarだった場合は、tar tvfj ファイル名。 $ tar tvfj ./test.tar.bz2 drwxr-xr-x h
digコマンドとnslookupコマンドの違いについて digコマンドもnslookupコマンドも、ネームサーバに対して問い合わせを行い、その応答結果を表示するコマンドですが、一番の違いは、digコマンドがネームサーバの応答を比較的そのまま表示するのに対し、nslookup コマンドは応答を加工して表示するという点です。 nslookupコマンドは実際に行いたい問い合わせ以外にもサーバに対して問い合わせを行い、場合によっては意図しない結果に見えることがあります。 ■nslookupの検証 nslookup www.apple.com Server: 127.0.0.1 Address: 127.0.0.1#53 →上記は、問い合わせたDNSの名前と位置です。 www.apple.com canonical name = www.apple.com.akadns.net. Name: www
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く