手持ちのアカウントが増えてくるとパスワードの管理方法が考えどころとなります。このところメジャーなネットサービスへの不正ログインやアカウントの悪用が相次いで報じられていることもあり パスワード管理の重要性は「古くて新しい問題」としてあらためて広い層に浸透しつつあります。 その一方でパスワードをきっちり管理することは必ずしも簡単ではありません。平易な内容だと第三者によって類推・導出されるリスクが大きいものの複雑にすると覚えにくい。だからと言って複数のサービスで同じものを使いまわすとそれが漏洩した場合に一斉に攻撃を受ける危険がある。結局、安全度の高いパスワードをサービスごとに使い分けることは人間の記憶だけでは困難なので何らかの外部記憶を利用することになります。ただし、それが何らかのデバイスであれコンピュータデータの形式であれ、情報としてそこへ保存した時点で盗難・流出の可能性はゼロではなくなります
現在、 MNX ではクラウドホスティングサービスの新しいデータセンタを立ち上げているところで、とてもバタバタしています。クラウドホスティングサービスは、今の私たちの主な業務ですが、この会社が始まった当初は、Linux管理のコンサルティングサービスを中心としていました。そのサービスを通じて、たくさんの顧客環境を目の当たりにしましたし、それと同じ数だけの、顧客ごとに異なるデバイス名の指定方法も見てきました。そしてもちろん、その全ての指定方法をいいなと思ったわけではありません。名前の付け方は、コンピュータ草創期からの問題ですよね。おのおのがホスト名の指定方法について一家言持っていました。でも、それらの方法は最初のうちはうまくいっても、時を経てシステムインフラが拡大し、状況に応じて変更を余儀なくされるようになると、すぐに扱いにくくなってしまうものがほとんどでした。 そこで今回は、先述した私たちのデ
こんにちは。MOONGIFTというサイトを運営している中津川と言います。MOONGIFTは10年くらい前からオープンソース・ソフトウェアを紹介しているのですが、昨年よりサーバのホスティング先をさくらさんに変更しています。そんなご縁もあって、今回からさくらのナレッジにて記事を書かせてもらうことになりました。オープンソース・ソフトウェアのレビューやクラウド周りの最新情報発信などを行っていきますのでよろしくお願いします！ 8月と言えば夏休みです。サーバ管理者の方もひと時の心休まるひと時を過ごされているのではないでしょうか。サーバルームの方が涼しいとか、いつ電話が鳴るか分からないなんてことは今は忘れましょう。 せっかくの夏休み、日頃の疲れを癒すべくゆったりと南国の空のもとで過ごすのも良いですが、ITエンジニアたるもの日々の精進は欠かせませんよね。ということで忙しい日々の業務に追われてなかなかトレン
こんにちは。オガリア開発チームの粂です。 弊社ではBitbucketとSourceTreeを使ってGitリポジトリを運用しています。他社の取り組みを参考にしつつ、日々試行錯誤しながらではあるのですが、ある程度運用指針のようなものができてきたので、2013年11月時点での弊社のGit運用指針を本記事でまとめておこうと思います。 前提：フロントエンドツールとしてSourceTree、リモートリポジトリはBitbucketを利用する GitHub Flowを採用する 基本的にはGitHub Flowに則ってmasterブランチとtopicブランチのみで運用しています。 masterブランチに直接pushしない 過去に本ブログでも書きましたが、Bitbucketでは任意のブランチにpushできるユーザ・グループを制御できます(AdministrationのBranch managementから)。
タイトルは若干釣り気味です GithubとGitlab両方使える MISAWA::MD https://chrome.google.com/webstore/detail/misawamd/legplkhbgdelfceignhcchogkmoflagl ミサワ画像をMarkdown形式でコピペできます Emoty https://chrome.google.com/webstore/detail/emoty/kgljgnbhcigffgoifhjbbifhbdkapmgm Githubなどで使える絵文字をポップアップで選んでクリップボードにコピペできます LTTM https://chrome.google.com/webstore/detail/lttm/jdidcgkdggndpodjbipodfefnpgjooeh textareaで手軽にミサワや LGTM.in/g の補完ができ
この記事は最終更新から1年以上経過しています。 気をつけてね。 アプリケーションプラットフォームの構築運用を少人数で行うためのツールとして、だいぶ浸透してきた感のあるOpscodeのChef。 chef-clientのクロスプラットフォーム性を支えるのが同じくOpscodeが保守するOhaiだ。 Github::opscode/ohai Ohaiに聞くとプラットフォームの情報が取れる Ohaiはインベントリ収集ツール。 レシピ(リソース/プロバイダ)を複数のプラットフォームに対応させるため、Chef-Clientが今から作用する対象を判断する情報をリストアップする。 Ohaiの利点は全てのプラットフォームで同じ問い合わせが出来ることだ、折角なので他のプログラムからも使えるように動作をチェックしてみる。 ohaiコマンド gemでohaiをインストールした後なら、コマンドラインからohaiを
Chefのクライアントバージョン11からchef-applyとコマンドラインツールが追加されていた。 ヘルプを見るとレシピのDSLを渡して実行してくれるものらしい。 追記： Chef12.1.0からnode.json的なファイルを渡せるようになったよ。 -j JSON_ATTRIBS, Load attributes from a JSON file or URL --json-attributes $ chef-apply --help Usage: chef-apply [RECIPE_FILE] [-e RECIPE_TEXT] [-s] --[no-]color Use colored output, defaults to enabled -e, --execute RECIPE_TEXT Execute resources supplied in a string -j JSO
勉強会やスライドで紹介していましたが、Ruby×クローラーという題材で、『Rubyによるクローラー開発技法』という本を書かせて頂きました。RubyとEmacsの鬼であるるびきちさんとの共著です。 Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例 作者: るびきち,佐々木拓郎出版社/メーカー: SBクリエイティブ発売日: 2014/08/25メディア: 大型本この商品を含むブログ (1件) を見る この本を書いた理由 そもそものキッカケは、るびきちさんのエントリーにある通り、SBクリエイティブの編集者さんが、クローラーの作成経験のある人を探していて、私の書いた「オープンソースのRubyのWebクローラー"Anemone"を使ってみる」を読んで打診してくださったというのが始まりです。 私自身も、Webからデータを収集して分析するということは、趣味として長年やってきました。一
twitterでちょっとつぶやいてたけど，最近自分がよく聴いてるPodcastをまとめてみる．Tech系以外もすこし混じってる．他にオススメあれば教えてください． 日本語 Rebuild - Podcast by Tatsuhiko Miyagawa - Podcastを聴くという習慣はここから始まった．大学院生のころからずっと聴いてる．Liveもできる限り聴いてる．大ファン．取り上げる技術もすごい尖っていて面白い．全エピソード好きだけど，敢えてあげるなら，“3: MessagePack”，“14: DevOps with Docker, chef and serverspec”，“27: Dragon Quest, Docker and AngularJS”，“35: You Don’t Need API Version 2”, “37: N Factor Auth”，“42: When
マウスでなぞるだけで、あらゆるデータ取得をAPI化——Y Com出身のスタートアップKimono Labsにインタビュー Kimono Labs 共同創業者 Ryan Rowe（左）と Pratap Ranade（右） 写真提供：Kimono Labs 〝Open The Kimono〟——すべてのデータを洗いざらい皆で共有しよう、という慣用句だ。筆者はネイティブ・スピーカーではないので、この表現が英語圏でどの程度広く通用するのかわからないが、このコンセプトを社名に冠したスタートアップが存在する。Y Combinator のインキュベーション・プログラムの最新バッチ（2014年1月〜3月）から輩出された Kimono Labs だ。 Kimono Labs のチームが先週から来日しており、共同創業者の Pratap Ranade と Ryan Rowe に話を聞くことができた。 ネット上に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
