今回は、任意の人物の所得を人口統計データを使って予測する手法をご紹介します。使用するのは 20年前の人口統計データ です。 この例を用いて、関係データベースの情報から予測モデルを導き出す方法と、その途中で起こり得るトラブルについて触れたいと思います。 このデータの優れた点は、データの作成者が下記のようなアルゴリズムの精度をデータに添付している点です。こうした数値はスモークテストの結果評価に役立ちます。 Algorithm Error -- ---------------- ----- 1 C4.5 15.54 2 C4.5-auto 14.46 3 C4.5 rules 14.94 4 Voted ID3 (0.6) 15.64 5 Voted ID3 (0.8) 16.47 6 T2 16.84 7 1R 19.54 8 NBTree 14.10 9 CN2 16.00 10 HOODG

私は GitHub が大好きです。GitHubはオープンソースへの コントリビューション （寄与貢献）を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトのGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時

現在、 MNX ではクラウドホスティングサービスの新しいデータセンタを立ち上げているところで、とてもバタバタしています。クラウドホスティングサービスは、今の私たちの主な業務ですが、この会社が始まった当初は、Linux管理のコンサルティングサービスを中心としていました。そのサービスを通じて、たくさんの顧客環境を目の当たりにしましたし、それと同じ数だけの、顧客ごとに異なるデバイス名の指定方法も見てきました。そしてもちろん、その全ての指定方法をいいなと思ったわけではありません。名前の付け方は、コンピュータ草創期からの問題ですよね。おのおのがホスト名の指定方法について一家言持っていました。でも、それらの方法は最初のうちはうまくいっても、時を経てシステムインフラが拡大し、状況に応じて変更を余儀なくされるようになると、すぐに扱いにくくなってしまうものがほとんどでした。 そこで今回は、先述した私たちのデ

Hacker School在籍中、ネットワーキングの理解をより深めたいと思い、小規模なTCPスタックを書いてみようと思い立ちました。個人的には、C言語よりもPythonの方になじみがありましたし、その頃ちょうど、パケット送信を 非常に簡単に する scapy ネットワーキングライブラリも見つけたところでした。 そんなわけで、 teeceepee を書き始めました。 基本的な構想は次のとおりです。 TCPパケットを送信可能にするRaw socketを開く google.comを取得するためにHTTP要求を送る 応答を取得しパースする 成功を祝う 適切なエラー処理などについてはさほどの注意も払わず、ただただウェブページを取得し、勝利を宣言しようと思っていました(^_^) ステップ1：TCPハンドシェイク 手始めは、GoogleとのTCPハンドシェイクです（以下は必ずしも正しく動作しませんが、原

メッセージキュー について書いている連載の続きとして、今週末は分散型メッセージングを実行するための様々なライブラリを詳細に分析していきたいと思います。今回の分析では、APIの特性、デプロイメントやメンテナンスの容易さ、そしてパフォーマンスの質を含めて2、3種類の異なる側面に着目します。メッセージキューは2つのグループに分類できます。ブローカレス（brokerless）とブローカード（brokered）です。ブローカードなキューはエンドポイント間に何かしらのサーバを挟んでいますが、ブローカレスなメッセージキューは、メッセージ送信の際でも間に何も挾まないP2Pです。 今回分析するのは以下のシステムです。 ブローカレス nanomsg ZeroMQ ブローカード ActiveMQ gnatsd Kafka Kestrel NATS NSQ RabbitMQ Redis 取り掛かりとして、ほぼ間違

Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys

モノリシックがダメだからといって、マイクロサービスが解決策になるわけではない ソフトウェア開発業界は流行に左右されやすいという証拠に、今マイクロサービスが、いたるところで大騒ぎされています。”次の大ブーム”だと思う人もいるでしょう。また、（10年前に”上出来”と見なされたような）大型のSOA、サービス指向アーキテクチャが単に軽量化して進化したものだと捉える人もいるでしょう。私は現在のマイクロサービスアーキテクチャに関しては好意的に見ています。しかし、だからといってこのアーキテクチャは決して万能薬ではありません。言うまでもないことかもしれませんが、多くの人が間違った理由でマイクロサービスに飛び付いているように思えるのです。 これは私の講演でよくお見せするスライドで、 以前ブログにも書きましたた が、ソフトウェアシステムを開発するにはいろいろな方法があります。まず、昔ながらのモノリシック（一枚

パイプライン は、最近のソフトウェアエンジニアリングにおいて、非常に便利な（そして驚くほど活用されていない）アーキテクチャパターンです。ソフトウェアでデータの流れを制御するためにパイプとフィルタを用いる考え方は、最初のUNIXシェルが作られた1970年代からあります。もしターミナルエミュレータでパイプ” | ”を使ったことがあるなら、”パイプとフィルタ”を活用できていることになります。以下の例を見てみましょう。 cat /usr/share/dict/words | # Read in the system's dictionary. grep purple | # Find words containing 'purple' awk '{print length($1), $1}' | # Count the letters in each word sort -n | # Sort l

現代のプログラマを取り巻く世界には無数の方法で組み合わされた、たくさんのUnixツールがあふれています。優れたツールは開発環境とシームレスに統合されますが、そうでないツールは使うたびに不満がたまっていきます。また、優れたツールはあなたの想像力次第でどんなものにも適用できますが、そうでないツールはあなたの開発環境で動かすためだけでも、あの手この手の対策を講じなければならないことがよくあります。 “One thing well” misses the point: it should be “One thing well AND COMPOSES WELL” — marius eriksen (@marius) October 10, 2012 “一つのことだけうまくやればいい”という考えでは目標に到達しない。”うまくいったものを、うまく組み合わせる”ことまで考えるべきだ 良い設計に必要なもの

Make は、様々なタイプのファイルのビルド作業を自動的に行ってくれるシンプルかつ強力なツールです。しかしながら、makefileを書く際に問題にぶち当たるプログラマもいれば、Makeの基本知識がないことで、既存のものを再発明してしまうプログラマもいます。 Makeの働き デフォルトでは、Makeは一番目のターゲットから開始します。このターゲットのことをデフォルトゴールと呼びます。 Makeはカレントディレクトリのmakefileを読み込み、一番初めのルールで処理を開始します。しかし、Makeが完全にこのルールを処理する前に、ルールが依存するファイルのためのルールを処理しなければなりません。各ファイルそれぞれは、自身のルールに従って処理されます。 実はこれは、各ターゲットの再帰的アルゴリズムになっています。 ターゲットをビルドするルールを見つける。ルールがないようであれば、Makeはうまく

私の小論 “In Search of Types” では、プログラミングで使われる“型”という言葉の概念や目的、考え方について、公平な批評を心がけました。所々で、私の真剣さを感じ取っていただけるはずです。このブログ記事では逆に、思い切って堂々と批評していきます。いくつかの意見や考え方に、私は苛立ちを隠せません。先日参加したStrange Loopでも、このような状況に陥りました（補足しますが、すばらしいコンファレンスでした）。この機会に、“型”について多くの人が（誤って）語った“重大な誤り”をリストアップしていきます。 ここで話す内容は、説得力のあるものです。私が苛立ちを覚えるのは、人々が正当かつ透明性のある議論を行っていないことに対してです。結論に誤りがあってはいけません。私は、OCamlである程度の数のプログラミングを行っており、それは型チェックから多くの価値を得ることができるシンプル

この記事は http://www.cl.cam.ac.uk/~srk31/blog/2014/10/07/ この文書の和訳である。原文も別に個人的には興味深いとは言い難いし、CSについての専門知識は全然ないので適任でもなんでもないのだが、例によって「POSTD」の日本語訳( http://postd.cc/7-deadly-sins-of-talking-about-types/ )が余りにも余りなので、私にわかる限りでもう少しマトモな翻訳にするとどうなるか試してみる。Markdownの脚注と[ ]内は訳者の（余計な）補足である。 型を語るということの七つの大罪 「型を求めて In Search of Types」という小論で、私はプログラミングにおける「型 type」という語を取り巻く様々な概念と目的と態度についての、感情抜きの冷静な批評を試みました。それでも所々で、私の感情がかなり透け

現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR

Gitを使用している人であれば、プルリクエストには馴染みがあるでしょう。これは、分散バージョン管理システムが世に出始めてから、何らかの形で使われています。BitbucketやGitHubのように凝ったWebユーザインターフェイスが構築される前は、プルリクエストは単純に電子メールベースで行われており、Aliceのリポジトリから変更をプルするように依頼していました。プルリクエストを受けた側がこの変更を妥当だと判断すれば、いくつかのコマンドを実行しmasterブランチに変更をプルするという流れです。 $ git remote add alice git://bitbucket.org/alice/bleak.git $ git checkout master $ git pull alice master もちろん、手あたり次第Aliceの変更をmasterにプルすることは、 得策 ではありませ

数年前、Webは全体的に暗号化されていませんでした。HTTPSはWebページの最も重要な部分だけのために確保されていました。暗号化が必要なのは大切なユーザデータだけで、Webページの公開される部分は暗号化せずに送ってもいいということで意見が一致していました。 しかし、 今は 状況 が 違います 。現在では、どんなWebトラフィックでも暗号化されていないのは良くないということが分かっているので、Webサイトを運営する誰もがコンテンツに関係なく強固なHTTPSを設定しなければなりません。 お恥ずかしい話ですが、私自身のWebサイトは2年近くも全くHTTPSをサポートしていませんでした ^(1) 。 Eric Mill の 今すぐ無料でHTTPSに切り替えよう という素晴らしい記事が最終的に私に喝を入れてくれました。私は休暇中、HTTPSをセットアップして Qualys SSL Report で

NginxでHTTPS：ゼロから始めてSSLの評価をA+にするまで Part 2 – 設定、Ciphersuite、パフォーマンス 今日のインターネットの世界では、一般的な静的Webサイトも含め、 全てのWebサイト に、強固で安全なHTTPSのセットアップが必要となります。この記事は、Nginxセキュリティをどのようにセットアップするのかに関するシリーズのパート2です。 パート1 は、Webサーバに有効な署名証明書をセットアップする話で終了しました。しかしこれには、最適な設定とは言い難い、デフォルトのNginxの設定を使用していました。 この記事を読み終えれば、SSL Labsのレポートで、A+の評価を獲得できる安全なHTTPSの設定ができます。それだけでなく、追加でいくつかの微調整も行い、パフォーマンスそしてUXも向上させていきます。 ここに掲載した記述やコードの抜粋の他にも、すぐに使

パフォーマンス分析のメソドロジーとは、システムやアプリケーションのパフォーマンスを分析する際に準拠できる手法です。メソドロジーを手がかりとして作業に着手できますし、根本原因やその他の要因の発見に役立ちます。異なる種類の問題を解決するのには、それぞれに適したメソドロジーがあります。目的を達成するまでに何度か方法を変えて試してみるといいかもしれません。 メソドロジーを使わない分析は手探りの探索になり、ある問題に対する手がかりが見つかるまで（もしあればですが）ずっと場当たり的にメトリクスを分析することになってしまいます。 このサイトでは以下のメソドロジーについて詳しい資料を公開しています。 USE（Utilization Saturation and Errors）メソッド ：リソースのボトルネックを見つける TSA（Thread State Analysis：スレッドステート分析）メソッド ：

ビヘイビア駆動開発（BDD：Behavior-Driven Development、振る舞い駆動開発ともいう）を実務に沿って簡単に紹介し、ソフトウェア開発プロセスに対してこの手法がどれほど有益かを説明します。 はじめに BDDで重視しているのは、フィードバックループを最小限に短縮することです。BDDはソフトウェア開発手法の進化の中で、理論的に一歩前進したものといえます。本稿ではBDDの概念と、その原型のモデルを説明します。 ソフトウェア開発者や、エンジニア部門のマネージャー職に就いている人ならば恐らく、以下の図のようなウォーターフォールモデルはよくご存じでしょう。 注釈: Waterfall model：ウォーターフォールモデル System Requirements：システム要件定義 Software Requirements：ソフトウェア要件定義 Analysis：要求分析 Progr

2015年05月27日: 表が見にくいというご意見を頂いたため、原文著者に連絡のうえ体裁を修正しました。 上位のレベルには下位のレベルの知識も蓄積されているということに注意してください。つまり、レベル n であれば n より低いレベルの知識も全てあります。 コンピュータサイエンス データ構造

(注記：6/9、いただいた翻訳フィードバックを元に記事を修正いたしました。) 今回の記事は毎秒300万ものリクエストを処理できるほど強力で高性能なWebクラスタの構築についてのパート1になります。まず初めに、あまり多くはありませんが、私がこれまで使用したことのあるロードジェネレータツールをいくつか紹介します。私のようにてこずって時間をかけてしまわないよう、今回の記事が理解の手助けになれば幸いです。 ロードジェネレータはテストを目的とした数種類のトラフィックを発生させるプログラムです。それによって高負荷においてサーバがどのように動いているか、そのサーバの弱点はどこなのか、などが見えてきます。負荷テストを通じてサーバの限界を知ることは、サーバのレジリエンシーを測定する最適な方法であり、あらゆる問題に対する準備の手助けにもなります。 ロードジェネレータツール 負荷テストをする際に頭に入れておくべ

科学はその方法論上のイメージよりもはるかに”ぞんざい”かつ”非合理的”なものである。 Paul Feyerabend著『Against Method（方法への挑戦）』（1975年） プログラミング言語は魅力的な分野です。それは、計算機科学（と論理）を 社会学や人間とコンピュータの相互作用 、科学的に定量化できない直感や嗜好、そして（良くも悪くも）政治などを含む分野と結び付けてくれるからです。 プログラミング言語を話題にする場合、たいてい何らかの客観的な真実を追求する科学的議論になってしまいます。科学は完璧のオーラに包まれているため、科学的本質の核心部だけに集中し、他の部分を無視するのが正しいプログラミング言語の考え方だと単純に思ってしまうのも無理ありません。 しかし、これではプログラミング言語を面白くしている多くのものが除外されてしまいます。この隙間を埋める1つの方法は、科学の哲学に目を向

自分で行うセキュリティ管理、パート1：エアギャップ・コンピュータ、GPG、スマートカード(YubiKey) この記事は以下のシリーズの一環です ラップトップへのログインと自動的な復号化 保持しているパスワードもしくはセキュリティ情報の暗号化と復号化 暗号化したメールの送受信 Webにログインする際の、2段階認証コードの提供 モバイルフォンでの上記内容の実施 マシン上のsudoに対する認証 sshキーのシームレスな管理 各種の初期登録などで使われる、同意の署名 免責事項 もちろん、このガイドで100％のセキュリティが確保できるわけではありませんし、全てを網羅するものでもありません。また、安全保障に関わる政府の諸機関から、目をつけられずに済むという保証もありません。どうか、気軽に学べる趣味という程度に考えてください。結局、この記事は全てセキュリティ侵害についてであり、私は誰もがするように、適当

ついに、インターネット技術タスクフォース（IETF）が RFC7469 HTTP公開鍵ピンニング拡張 （HPKP）を発表しました。このアイデアを出してくれた同僚のRyan Sleevi、Adam Langley、Chris Evansに感謝します。また、RyanとChris EはRFCの最終稿に先立つ大量のドラフトの執筆を助けてくれました。そして、ドラフトにコメントし、RFCとして公開できるまでにしてくれたIETFの多くの参加者にも感謝します。 ピンニングとは何か？　何を解決できるのか？ HPKPは Web PKI の大きな問題の1つを解決する試みです。その問題とは、基本的に認証局（CA）や中間認証局は、どのWebサイトにもエンドエンティティ（EEまたは”リーフ”）証明書を発行することができてしまうことです。例えば、mail.google.comの証明書が”Google Internet

1. LeaderをSpaceキーにする Leader は素晴らしい概念です。キーの 組み合わせ ではなく 並び によって、操作を行えるようにするものです。私はこれを使っているので、操作のために” Ctrl -何らかのキー”の組み合わせを押す必要はめったにありません。 私は長い間、 , を Leader キーとして使っていました。ですがある時、キーボードの中で一番目立つキーにマップすることを思い付いたのです。Space（スペース）キーです。 これで私のVim生活は激変しました。今や、私は Leader をどちらの親指でも押すことができ、他の指は常にホームポジションにあります。 Leader がとても使いやすくなったので、私が様々なキーバインドで用いるようになったことは周知の話です。 2. 自分が特によく行う操作をLeaderにマップする 私は、自分がVimで作業を行っている中で、その時間の

[Webinar] Don’t Get Left Behind: Unlock the Secrets of Shifting Left | Register Now

PART 1.はこちら : 強固なデータ・インフラストラクチャを構築するためのログの活用（デュアル書き込みがダメな理由）PART 1. ログが使われる場面について4つ説明したいと思います。まずデータベースストレージエンジンの内部です。 B-tree はアルゴリズムの授業で学びましたよね？　ストレージエンジンに広く使われているデータ構造です。ほぼ全てのリレーショナルデータベースと、多くの非リレーショナルデータベースで使われています。 B-treeについて簡単に説明しましょう。B-treeは、ディスク上で固定長のブロックとなる ページ から構成されており、通常、その固定長は4KBか8KBです。ある特定のキーを探したい時は、まずtreeのルートにあるページから探索を始めます。そのページは他のページへのポインタを内包していて、各ポインタはキーのレンジ（範囲）にタグ付けられています。例えば、もしキー

これは Craft Conference 2015 で私が行った 講演 を編集して記事にしたものです。その時の 動画 と スライド もご覧頂けます。 あなたのデータベースは、どのようにして確実にデータをディスクに保存しているのでしょう？　ログを使っているのです。 データベースのレプリカは、どのようにして他のレプリカと同期するのでしょう？　ログを使っているのです。 Raft などの分散アルゴリズムはどのようにして合意を取っているのでしょう？　ログを使っているのです。 Apache Kafka などのシステムでは、アクティビティデータはどのように記録されるのでしょう？　ログを使っているのです。 あなたのアプリケーションのデータ・インフラストラクチャはどのように規模相応の堅牢性を保つのでしょうか？　答えは･･･ ログは至るところにあります。私はプレーンテキストのログファイル（syslogやlog

Linuxのスレッドは、洗練された美しい設計です。スレッドは仮想アドレス空間とファイルディスクリプタテーブルを共有するプロセスに過ぎません。プロセスによって生成されたスレッドは、メイン”スレッドの”親プロセスに追加された子プロセスです。これらは同じプロセス管理のシステムコールを通して処理されるので、スレッドに関するシステムコールのセットを分ける必要性を取り除きます。これはファイルディスクリプタと同様に洗練された方法です。 一般的に、UNIX系のシステムではfork()を使ってプロセスを生成します。新しいプロセスは、オリジナルのコピーとして独自のアドレス空間とファイルディスクリプタテーブルを取得します。（Linuxではコピーオンライトを使用して、この部分を効率的に処理します。）しかし、これは非常に高度なスレッドの生成方法なので、Linuxでは別の clone() システムコールを使用します。

わずかな文字がいかにしてパフォーマンスに大きな違いを生めるかというお話 正規表現は、私たち開発者がことあるごとに駆使する呪文のようなものですが、私たちはそれをどんな時も巧みに使いこなしていると言えるでしょうか。正規表現は繊細で精密な言語です。入念な慎重さで記述してやれば、ボウリングで一瞬にして完璧なストライクを取るような強力なテキストとなり得ます。 しかし、正規表現が精密さに欠ける状態で投げ出されると、さながら酔っ払いがよろよろとつまずきながらテキストの上を歩くがごとく、そのボールはぎこちなくボウリングのレーンを転がり、ピンを1つか2つ倒すだけで終わってしまうのです。 これら2つの正規表現の違いは何なのか。何がいい表現と悪い表現を分けるのか。正規表現に素晴らしい力を与えるメカニズムを、この投稿で明かしてみようと思います。効果的な表現とそうでない表現との大きな違いをきっと分かってもらえるはず

ここHumanGeo社ではPythonを使うことが多く、それは極上の楽しみでもあります。美しく機能的なコードを短時間で記述するのにPythonはうってつけで、私個人にとっても一押しの言語です。仕事に限らずプライベートでも使っています。そんな素晴らしいPythonですが、欠点がないわけではありません。それはあまりにも遅いことです。幸いPythonには、コードをプロファイリングするための優れたツールがいくつかあるので、コードの美しさと速さを共存させることができます。 HumanGeoで働き出した頃、実行に長時間を要すプログラムのボトルネックを探り、何とかしてそれを速くさせるという仕事を担当しました。その内容は、 cProfile や PyCallGraph （ ソース ）、はたまたPyPy（高速なPython用代替インタプリタ）などの各種ツールを使って、プログラムを最適化するためのベストな方法

リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術（ビッグデータ、NoSQL、JavaScriptなど）を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか？ 私は開発者として、理解していないものを

(訳注：2016/1/5、いただいた翻訳フィードバックを元に記事を修正いたしました。) よくある主観的で痛烈な意見を題名に付けたクリックベイト（クリック誘導）記事だろうと思われた方、そのとおりです。以前指導してくれた教授から教わったある洞察/処世術は、些細でありながら私の人生を変えるマントラとなったのですが、私がこの記事を書いたのはそれによるものです。「同じタスクを3回以上繰り返す必要があるなら、スクリプトを書いて自動化せよ」 そろそろ、このブログはなんだろうと思い始めているのではないでしょうか。半年振りに記事を書いたのですから。ツイッターで書いた Musings on social network platforms（ソーシャル・ネットワークプラットフォームについてじっくり考える） はさておき、この半年の間書き物をしていないというのはうそです。正確には、400ページの 本 を書きました。

対象読者 これは、プロジェクトのITインフラへのアクセスや管理でLinux ワークステーションを使用しているシステム管理者向けの資料です。 システム管理者が遠隔から管理をしている場合は、ワークステーションが主要なセキュリティ条件を満たしていることを確認することで、ITインフラ全体へのサイバー攻撃の進入経路となることを防ぐことができます。その際、ここに書いたガイドラインを参考にしてください。 システム管理者が遠く離れた場所にいない場合でも、携帯可能なノートパソコンを使用している可能性や緊急対応用に自宅から会社のネットワークにアクセスできるよう設定している可能性があります。いずれの場合でも、環境に合ったガイドラインの適用をお勧めします。 制約事項 これは、「ワークステーションの強化」を徹底した資料とは言えません。しかし、これが明白なセキュリティ上のエラーを起こすのを回避できる基本的ガイドとなれ

(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注：2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳：　プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション：なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest

(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) 開発者は嫌うでしょう。 ここでは、標準的なコツや策略について書きますが、本当に興味があるのは、別のことです。究極の奇策を見つけたいと思います。策略をひとつずつ試して、プログラミングの聖域に少しでも近づければ良いのですが。 はじめに 私が初めて書いたビデオゲームは、 Ninja Wars （忍者戦争）でした。 そう、これは、画像で埋めたHTMLのtableです。 src 属性を変えることで、動きを実現しています。JavaScriptファイルの冒頭は下記のようになっています。 var x = 314; var y = 8; var prevy= 1; var prevx= 1; var prevsw= 0; var row= 304; var endrow= 142; var sword= 296; v