タグ

2014年3月13日のブックマーク (5件)

  • Qiitaの記事タイトルに隠された秘密のルール - Qiita

    まずは、2つの記事のスクリーンショットをご覧ください。 この2つには、ある違いがあります。さて、何でしょうか? スクリーンショット1 スクリーンショット2 違いに気づいたでしょうか? 記事のタイトルが「Scala」と「スカラ」で違うとか、URLが違うのはもちろんですが、<title> タグの内容が違っています。つまり、ブラウザのタイトルバーの内容が異なっているのです。 スクリーンショット1のほうは「Scalaについての記事 - Qiita」になっていますが、スクリーンショット2では「Scala - スカラについての記事 - Qiita」になっています。 違いを決めているのは何か? このような違いが出るのはどうしてでしょうか? いくつかQiita上の記事を見て検証したところ、 タグと同じ文字列が記事に含まれていない場合、タグを自動的にタイトルに含める というルールがあるようです。 先のスクリ

    Qiitaの記事タイトルに隠された秘密のルール - Qiita
    ngyuki
    ngyuki 2014/03/13
  • ランダムなパスワードを1行で生成する - Qiita

    ランダムなパスワードや文字列を生成する方法を6つ紹介します。 1. str_shuffle() を使う 同じ文字が2回出ない 36文字まで生成可能 <?php function random($length = 8) { return substr(str_shuffle('1234567890abcdefghijklmnopqrstuvwxyz'), 0, $length); }

    ランダムなパスワードを1行で生成する - Qiita
    ngyuki
    ngyuki 2014/03/13
  • OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい(もしくはコードレビューの話) - kazuhoのメモ置き場

    以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1 https://twitter.com/kazuho/status/431602421068877824 今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。 「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、 ふりかえってみると、Linux の手法や成功の前例は G

    OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい(もしくはコードレビューの話) - kazuhoのメモ置き場
  • Git2.0がリリース!一足早く新機能を紹介するよ · DQNEO日記

    Git2.0がまもなくリリースされるようです。 Git v2.0 Release Notes リリースノートをもとに、一足早く新機能と変更点の紹介をしてみます。 (各機能についてはまだ動作確認しておりませんので、ここがおかしいなどあればご指摘ください) 引数なしのgit pushが安全になりました。 When "git push [$there]" does not say what to push, we have used the traditional "matching" semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). In Git 2.0, the default is no

    Git2.0がリリース!一足早く新機能を紹介するよ · DQNEO日記
    ngyuki
    ngyuki 2014/03/13
  • 些末なコードレビュー - naoyaのはてなダイアリー

    朝起きて布団から出るのがつらいので、HBFav をつらつらと眺めていた。 あるサービスの JavaScript が重いとか、そのコードが難読化されてないとか、担当者とおぼしき人間が書いたコメントがそのまま残ってるから消しましょうよとか、そんなことが書かれていた。JavaScript が重い、という話は結局そのサービスの JavaScript が重かったのではなく、ユーザーが自分で導入した広告が重いというだけの話だった。 コードが難読化されていない、趣味の製品ではなく会社の製品なのでコメントそのまま残ってるから消しましょう・・・実にくだらない。 ところで話は変わってコードレビューについて。 コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい

    些末なコードレビュー - naoyaのはてなダイアリー
    ngyuki
    ngyuki 2014/03/13
    後から見た人が不安を感じるようなコメントは残さないほうがいいかなーと思う。なぜなら不安を解決しようとして無駄な時間を過ごしてしまうから