Flume は、大量のログデータを効率的に収集、集約、移動することを目的に開発された、高い信頼性と可用性を持つ分散型のサービスです。Flume を使えば、クラスタ内の各マシンのログファイルを収集し、これらのログファイルを Hadoop Distributed File System (HDFS) などの中央の永続的ストアに集約するロギングシステムを構築できます。
Flume は、大量のログデータを効率的に収集、集約、移動することを目的に開発された、高い信頼性と可用性を持つ分散型のサービスです。Flume を使えば、クラスタ内の各マシンのログファイルを収集し、これらのログファイルを Hadoop Distributed File System (HDFS) などの中央の永続的ストアに集約するロギングシステムを構築できます。
(訳注:この資料は、http://www.kernel.org/pub/software/scm/git/docs/user-manual.html に掲載されている 内容を日本語訳したものです。 英語が得意でないので、誤訳があるかもしれません。 必要な場合は、原文を参照してください。) git は高速な分散リビジョン管理システムです。 このマニュアルは、基本的な UNIX コマンドのスキルをもった人が読むことを想定していますが、 git に関する前提知識は必要ありません。 Chapter 1, リポジトリとブランチ と Chapter 2, 履歴の探索 では git を使用してプロジェクトを取得・調査する方法を説明します。 — これらの章を読むことで、ソフトウェアプロジェクトの特定のバージョンをビルドして テストしたり、回帰点を探し出す方法などを習得してください。 実際に開発する必要のあ
いまさら聞けない「Javadoc」と「アノテーション」入門:【改訂版】Eclipseではじめるプログラミング(22)(1/4 ページ) これからプログラミングを学習したい方、Javaは難しそうでとっつきづらいという方のためのJavaプログラミング超入門連載です。最新のEclipseとJava 6を使い大幅に情報量を増やした、連載「Eclipseではじめるプログラミング」の改訂版となります 注釈とコメントで開発しやすくしよう 開発者がソースコードにコメントを自由に記述すると、統一性がなくなり、同じ内容をさまざまな表現で書いてしまいます。これを防ぎ、重要な情報について統一的な表現で記述したいときは、「アノテーション(annotation、注釈)」を使うことを検討してみましょう。 Javaではアノテーションをプログラムのソースコードへプログラムのメタデータとして記述できます。また、プログラムにア
Wikiというものはとても便利なんだけど、 大量の文章を書くにはWebブラウザのインターフェースはまだまだ辛い オフラインで使えない(文章書くのは電車が一番) 複数の文章を再構成したり、一括で検索したり、置換したりは、Webだとやっぱりきびしい と言った欠点がある。 とは言え、誰でも気軽に編集できるWikiの魅力も捨てがたい。 そこで、「Wikiではあるんだけど、ローカルでも自分の好きなエディタで簡単に編集できるツールないかなー」と探してみたら、 Gitit というWikiを発見した。 ここ数日、結構な量のドキュメントをGititで書いてみて、わりと満足しているのだけど、検索してもGititの日本語の情報があまり出てこないので紹介してみる。 Gititの特徴 コンテンツをGitのレポジトリに保存する。 そのGItレポジトリをcloneして好きなようにいじってからcommit/pushすれば
業界トップ のエンタープライズ Hadoop 企業 Cloudera に入社しました http://www.cloudera.co.jp/ 今年の6月に、「平成21年度 産学連携ソフトウェア工学実践事業報告書」というドキュメント群が経産省から公表されました。 そのうちの一つに、NTTデータに委託されたHadoopに関する実証実験の報告書がありましたので、今更ながら読んでみることにしました。 Hadoop界隈の人はもうみんなとっくに読んでるのかもしれませんけど。 http://www.meti.go.jp/policy/mono_info_service/joho/downloadfiles/2010software_research/clou_dist_software.pdf 「高信頼クラウド実現用ソフトウェア開発(分散制御処理技術等に係るデータセンター高信頼化に向けた実証事業)」という
文系理系は無関係、学生は全員読め。もう一度いう、学生は必ず読め。 「上から目線」だの「えらそう」だの批判上等(ご指摘の通りだから)。その上で重ねて言う、必ず読め。かくいうわたしは、そう言ってくれる先達がいなかった。ゼミ発表やビジネス文書で「揉まれて」身に着けた我流の技術なので、心もとないことおびただしい。 今では論文・レポートの作成技術に関する本は沢山あるが、コンパクトな新書にここまで丁寧+徹底して「学生のレポート」に特化したものはない。「東大、京大、北大、広大の教師が新入生にオススメする100冊」の第8位で、この手のランキングに必ず本書が入っているところに、センセ方の苦労がしのばれる。 もちろん、ライティングの手ほどきを受けている方なら、「あたりまえ」のことばかり。しかし、その「あたりまえ」がないことでどれだけコミュニケーション・ロスが発生しているかゾッとさせられる。 たとえば、「事実と
本連載では、竹島愼一郎氏が提唱するインパクト抜群の「1枚企画書」をPowerPointで作る手順を全5回で紹介します。社会人になったらWordやExcelだけでなくPowerPointも使いこなせなくては、社内や取引先でのプレゼンに勝ち抜けません。しかし、ただ単に企画書をPowerPointで再現しただけでは、印象に残るプレゼンにはほど遠く、居眠りを誘う会議になってしまうことでしょう。 「1枚企画書」の最終回として、本書が出版に至った企画書の実例を含む、「プレゼン力の高い企画書」を3種類ご紹介します。実際の成功事例を踏まえてPowerPointをフル活用すれば、皆さんの仕事もきっと成功に近づくはずです。 ※本記事は「ビジネス極意シリーズ パワポで極める1枚企画書」から一部抜粋し、編集・再構成したものです。 Table of Contents プレ企画書1――飽和市場の「新商品企画書」 ■
自宅サーバのインフラ設計書を公開します。 Design paper of the home server(抜粋) 昨夜にTwitterで公開したら予想外に反響があったので、ちゃんとエントリに残すことにしました。クラックされるおそれがあるので、細かい部分は公開できないことをご了承ください。 内容はこんな感じ。 要件概要 機器仕様 ネットワーク設計 ソフトウェアスタック設計 共通基盤設計 サーバ詳細設計 上記にバックアップ設計や運用管理まわり*1を加えれば、インフラの設計書はだいたいこんな感じではないかと思います。 インフラの要件定義は難しい 一方で、インフラの要件定義は十分に標準化が進んでおらず、会社やチームによって文化がかなり違います。特に受託開発(SI)の場合は、お客様の中にインフラに詳しい人がいなくて調整に苦労することも多いと思います。費用と可用性のトレードオフの部分はなかなか伝わりづ
JavaのWebアプリ開発では、Strutsの登場以来、様々なフレームワークが誕生してきましたが、最近の動向はどうなんでしょうね? 群雄割拠、乱立状態で、良く分からん・・・ まあ、「どれが最適なフレームワークか?」なんてことは、目的・用途によっていくらでも変わるので、あまり意味のない議論だと思いますが、何が主流なのかぐらいは知っておきたいですね。 そこで、情報がないかなぁと調べてみたら、以下のサイトを見つけました。 Comparison of web application frameworks 機能比較があって、分かりやすい。 継続して、メンテナンスされている様子。 Javaだけでなく、Perl、PHP、Python、Ruby、ColdFusion、ASP.NETなんかのフレームワークについても書かれている。 10 Best Java Web Development Framework
IBM TechXchange Community Together, we connect via forums, blogs, files and face-to-face networking. Find your community Where is my content? If you’re looking for developerWorks content or a Support forum and ended up here, don't panic! You are in the right place. The content you're looking for. This page will help you find the content you are looking for, get answers to your questions, and find
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
Welcome to Scala hack-a-thon #1’s documentation!¶ Contents: 1. Scala開発環境の準備 1.1. Scala実行環境のインストール 1.2. 開発環境のセットアップ 1.3. その他やっておくと便利なこと 2. Scalaの開発スタイル 2.1. ソースコードとコンパイル 2.2. アプリケーションを作り、実行する 2.3. インタプリタでの実行 3. Scalaの基本 3.1. 基本的な文法 3.2. 関数編 3.3. クラス、オブジェクト、トレイト 3.4. トレイト(trait) 3.5. importとpackage 3.6. ケースクラスとパターンマッチ 4. Scalaの高度な機能 4.1. Implicit ConversionとImplicit Parameter 4.2. 型のパラメータ化 4.3. 遅延評価
8月に入社した佐々木です。こんにちわ! 入社してからはHadoopを使うことが多く、日々、大規模データと格闘しています。大変ではありますが、個人ではなかなか触ることが出来ないような大規模データを触れるのは楽しいです。 さて、Hadoopは最近色々なところで使われ始めてきていると思うんですが、実際に利用してみて困った事やtipsなど、実践的な情報はまだあまり公開されていません。その辺の情報をみんな求めているはず…!! そこで、僕が実際に触ってみて困った事やHadoopを使う上でポイントだと思ったことなどを社内勉強会で発表したので公開してみます。Hadoopを使っている(使いたいと思っている)方の参考になれば幸いです。 [slideshare id=2711363&doc=20091214techblog-091213183529-phpapp02] Hadoopの利用はまだまだ試行錯誤の連続
By: Alex Ziv – CC BY 2.0 「わかりやすい」と言われるような文章を書きたいものです。 とはいえ、単に「わかりやすい文章」というだけでは具体的に何をどう改善すればいいのかがイマイチ「わかりにくい」。 そこで、今回は読点(テン)の打ち方に絞って「わかりやすい文章」に一歩、近づくことにします。参考図書は、現代国語や小論文が苦手だった学生時代の僕に文章を書くことの楽しさと深遠さを教えてくれた以下の一冊。 「血まみれ」になったのはどっち? 、(テン)や。(マル)や「(カギ)のような符号は、わかりやすい文章を書く上でたいへん重要な役割を占めている。とくにこの場合、論理的に正確な文章という意味でのわかりやすさと深い関係をもつ。(p.74) ということで、テンの役割の重要性を示すために挙げられているのが次の例。 渡辺刑事は血まみれになって逃げ出した賊を追いかけた。 渡辺刑事は、血まみ
誰が読むのか。 読み手にどんな感想を持ってもらいたいか。 読み手はどれくらいの予備知識を持っているか。 読み手はどんな目的で、何を期待して読むのか。 読み手が真っ先に知りたいことは何か。 レポート・論文とは何か 問いが与えられ、または自分が問いを提起し、 その問題に対して明確な答えを与え、 その主張を論理的に裏付けるための事実・理論的な根拠を提示して、主張を論証する。 標準的な構成要素とは何か レポート・論文の構成は、 概要 序論 本論 論議 という要素が標準的である。次にそれぞれの要素について簡単に見てみる。 概要 論文全体を結論も含めて、すべて要約する。 序論 本論で取り上げる内容は何か。 その問題をどんな動機で取り上げたのか。 その問題の背景は何か。 その問題についてどんなアプローチを取ったのか。 本論 調査・研究の方法・結論 論議 自己の議論・結論を客観的・第三者的に評価する。 そ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く