タグ

2012年4月9日のブックマーク (10件)

  • 使えるとちょっと便利なSSHのTIPS

    こんにちは、牧野です。久々の、9か月以上ぶりのブログです。。 仕事では、ここ1年近くずっっとインフラ関係のことをやっていました。 今日は、SSHに関するTIPSを紹介します。 1. 特定のサーバーにSSHログインする時に、特定の設定を使用する ホームディレクトリ/.ssh/configファイルに設定を書いておくと、特定のサーバーにログインする時に、自動的に特定の設定を使うようにできます。 SSHのオプションをサーバーによって分けたい時に入力が楽になります。 以下は、xxx.yyy.zzz.aaaでアクセスする時に使う秘密鍵をid_rsa_testに設定しています。 .ssh/config Host xxx.yyy.zzz.aaa IdentityFile /home/asial/.ssh/id_rsa_test 2. ホストキーをチェックしないようにする LinuxからサーバーにSSH接続

    使えるとちょっと便利なSSHのTIPS
    hokorobi
    hokorobi 2012/04/09
  • ローソンWi-Fiが誕生日と電話番号を誰かに伝えることを禁止! - Togetter

    先日始まった LAWSON Wi-Fi を利用するために必要なローソンアプリの利用規約がとんでもなかった件。 アプリ利用中は誰の誕生日も電話番号も知らせてはいけないし、知ろうとしてもいけない! Pontaカードを解約しようとしてもローソンアプリの規約で退会出来無い!詰んだ! 【4/10 22:10】 続きを読む

    ローソンWi-Fiが誕生日と電話番号を誰かに伝えることを禁止! - Togetter
    hokorobi
    hokorobi 2012/04/09
  • ネギ焼き by ★M★A★S★H★ [クックパッド] 簡単おいしいみんなのレシピが40万品

    2022/1/13をもって お客様がご利用中のブラウザ (Internet Explorer) のサポートを終了いたしました。 (詳細はこちら) クックパッドが推奨する環境ではないため、正しく表示されないことがあります。 Microsoft Edge や Google Chrome をご利用ください。 (Microsoft Edgeでクックパッドにログインできない場合はこちら)

    ネギ焼き by ★M★A★S★H★ [クックパッド] 簡単おいしいみんなのレシピが40万品
    hokorobi
    hokorobi 2012/04/09
    作った。目が痛い……。ぱりっと焼き上げるなら焼くときの量をもっと少なくしないと。中がとろっとした仕上がりに。これはこれでおいしかった。ポン酢でいただきました。
  • Good night, Posterous

    Posterous Spaces is no longer available Thanks to all of my @posterous peeps. Y'all made this a crazy ride and it was an honor and pleasure working with all of y'all. Thanks to all of the users. Thanks to the academy. Nobody will read this.

  • ベロシティに対する誤解 | Ryuzee.com

    みなさんこんにちは。@ryuzeeです。 スクラムをはじめとしたアジャイル開発の見積りでよく使われるのがストーリーポイントです。 ストーリーポイントは研修でもよく聞かれるテーマであるとともに、誤解も多いものなので、今回基からまとめて解説したいと思います。 なお、文脈の前提として、スクラムでの活用を想定しています。 ストーリーポイントとは?まずは、ストーリーポイントとは何なのかを見ていきましょう。 書籍『アジャイルな見積りと計画づくり ー価値あるソフトウェアを育てる概念と技法』(Mike Cohn 著、安井力、角谷信太郎 訳、マイナビ出版、2009/1/29)の61ページから62ページにかけて、ストーリーポイントは以下のように定義されています。 ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさをあらわす単位である。 ストーリーポイントを使った見積りではそのような

    ベロシティに対する誤解 | Ryuzee.com
  • INとEXISTSの実行計画の違い 理想は泥臭いアーキテクト

    最近行った現場で見ました。何故か昔から(特にOracle界隈?)盲目的に「INよりEXISTSのほうが速い」という迷信があって、も杓子もみーんなEXISTSになっている現場があったりします。 ※以下はOracle10g相手にあれこれチューニングした経験を踏まえての記述ですが、大筋は他のDBでも変わらないと思います。 INもEXISTSもそれぞれ、一概にどっちが良いと決まっている訳じゃないので、ケースバイケースでどっちを使うかちゃんと考えないといけません。 結論 ・INが適している場合とは→選択的述語が副問合せに有る ・EXISTSが適している場合とは→選択的述語が親問合せに有る 選択的述語なんてふにゃっとした単語がでてきたけど、要は副問合せ側で条件絞込みできる場合はIN、親問合せ側で条件絞込みできる場合はEXISTS(のほうが適している可能性が高い)てことです。 ※以下はOracle10

    hokorobi
    hokorobi 2012/04/09
  • 検査するな、確認せよ

    みなさんこんにちは。@ryuzeeです。 マイク・コーン氏が書かれた「CHECK IN, DON’T CHECK UP」という記事が素晴らしいので抜粋・意訳にてご紹介します。 良いスクラムマスターがどのように振る舞うべきなのかについて参考になると思います。 私は、特にアジャイルスクラムを使い始めてからは、マイクロマネージャではなかった。 ただ、私のキャリアの最初のころは、検査するのに忙しすぎた時を除いては、マイクロマネージャに陥っていた可能性があることは否定できない。 しかし、チームや人の行動を検査するのを避けてきた一方で、一緒に確認することに消極的だったことはない。 私は小さな成功の重要性についての記事を読んで、このことを思い出した。 検査と確認は同じようにみえるかもしれない。 しかしチームの確認をしているのにもかかわらずマイクロマネジメントになってしまう、ということを避けるために良い

    検査するな、確認せよ
  • 連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説(前編)

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説(前編)
  • MercurialとTracを連動させてみた。

    先日Mercurialサーバを立ててTracと連動させる機会があったので、 その際のハマりポイントとかをメモしておこうと思います。 環境は Ubuntu10.04 64bit Servea Edition が前提です。 Gitの手順は結構あるのですが、Mercurialはやっぱり情報少なめなんですよね。。 Tracのインストールについては以前にまとめているんでそちらを参照あれ。 Nginx + uwsgi で Trac環境を作った時のメモ Mercurialリポジトリの作成 基的にはTracが稼働しているサーバに作成するのがいいでしょう。 そのため、基的にはすでにTracのインストールが完了していること前提で話を進めます。 Mercurial のインストール まずはこれがないと始まりません。 Ubuntu10.04の場合は標準のaptでインストールしてしまうと思いの外古いバージョンが入

    MercurialとTracを連動させてみた。
  • 『NISTによる組み合わせテストに関する包括的な文書』

    ソフトウェアの組み合わせテスト技法の1つであるペアワイズ法(Pairwise法)(またはオールペア法(All-pairs法)ともいう)と直交表を採用した組み合わせテストケース生成ツール PictMasterの使い方をはじめ、テスト全般のトピックスを掲載していきます。 米国立標準技術研究所(National Institute of Standards and Technology, NIST)は、民間と政府機関の共同で標準化された規格の開発と評価に直接関与している組織です。NISTが公開している文書に Combinatorial and pairwise testing tutorial があります。 この文書のエグゼクティブ・サマリーには次のように書かれています。 2003年にNISTは、ソフトウェア開発予算の50%から80%をテストが占めており、年間595億ドルのコストがかかっていると

    『NISTによる組み合わせテストに関する包括的な文書』