第17回 「Software Quality Environment」による静的解析でソースコードの品質を向上させる | gihyo.jp
本格派エンジニアの工具箱 第17回「Software Quality Environment」による静的解析でソースコードの品質を向上させる パッケージの依存関係を可視化する「Dependency Finder」 前回に引き続き、NetBeans向けの静的コード解析ツールである「Software Quality Environment」（以下、SQE）を紹介します。 SQEに付属する4つのツールのうちのひとつ、「Dependency Finder」は、コンパイル済みのJavaコードからパッケージの依存関係を解析して可視化するツールです。もともとのツールは依存関係をXML形式やHTML形式またはテキスト形式で出力するものですが、SQEに含まれるNetBeansプラグインではグラフ状のマップとして出力する機能が提供されます。 Dependency Finderによる解析は、プロジェクト名を
第16回 Javaソフトウェアのための静的コード解析ツールをセットにした「Software Quality Environment」 | gihyo.jp
本格派エンジニアの工具箱 第16回Javaソフトウェアのための静的コード解析ツールをセットにした「Software Quality Environment」 「Software Quality Environment」とは ソフトウェアの品質を確保するためには、単体テストをはじめとする動的テストと並んで、ソースコードの静的チェックが極めて重要となります。「Software Quality Environment」（以下、SQE）は、Javaアプリケーション開発向けに公開されている複数の静的コード解析ツールをセットにした、NetBeans用のプラグインです。現在、SQEには次に挙げる4つのツールが含まれています。 FindBugs PMD Checkstyle Dependency Finder これらのツールはそれぞれ単体で利用することもできますが、SQEのメリットは、手軽に複数の異な
第7回 御社のトップは腹をくくっていますか？―改善活動は部活ではない | gihyo.jp
現場だけの業務改善 「業務改善は現場だけで自発的に行っていけばよいのか？」という質問を受けることがあります。理想的な答えは「イエス」です。現場の自主性・主体性を活かせればそれに越したことはありません。 改善活動の初期段階に立ちはだかる壁として多いものは、「改善ばかりしていて仕事をしていない」と言われることです。他部門への働きかけを行おうとすると、「何の権限があって、うちを巻き込むんだ？」と部門責任者から断られます。良かれと思って、動き始めてもこのような場面に直面し、「ちゃんと社内で認知されていないアングラ活動なんだ…」と無力感を感じて、一気にトーンダウンすることも少なくありません。 したがって、現実的な答えとしては、僕らは「ノー」と言います。業務改善ができないというのではなく、現場だけで進めると業務改善の限界が早く来るということです。 改善は仕事ではない？ もう1つ考えなければいけな
第15回 「Play Framework」でモデル／コントロールをカスタマイズする | gihyo.jp
コントロールのカスタマイズ 前回に引き続き、「Play Framework」（日本語サイトはこちら）の使い方を解説します。Play Frameworkで作成したアプリケーションはモデル/ビュー/コントロールの各パーツから構成され、それぞれプロジェクトのmodels/views/controllersフォルダ内に格納されています。前回はビューの修正を行ったので、今回はまずコントロールをカスタマイズしてみましょう。 デフォルトのコントロールはcontrollersフォルダにApplication.javaとして作成されています。このindex()メソッドがビューのindex.htmlに関連付けられていることは前回説明しました。index()メソッドでは、次のようにrender()メソッドの呼び出しを行っています。これがPlay Frameworkのテンプレートエンジンを利用してWebページ
第6回 「自分は悪くない！」のか：業務フローと問題発見 | gihyo.jp
自分は悪くない 仕事でトラブルやミスが発生したとき、それも皆さんの仕事ではなく、他人や他部門が原因で被害を被った場合に、どのような反応をしますか？ 「また、あいつかよ……」と不満を漏らす。「あの部門がちゃんとやらないから！」と、やはり不満を漏らす。あなたでなくとも、身の回りで思い当たる場面は数えればいくつもあることでしょう。 かく言う筆者も、開発の仕事ですでにほぼ設計が完了していたときに、営業から「顧客から要求変更があり仕様が変わった」の一言で、それまでの設計に費やした時間が振り出しに戻った経験があります。当時は、若気の至りもあり、行き場のない怒りを営業や上司にぶつけて、「もっと早く言え！」と食ってかかったものです。とくに、ハードウェア設計ではプリント板を起こすにはマスク発注だけで数百万円は最低かかることもあります。また、ASIC（Application Specific Integr
第25回 猛暑とCPUの発熱対策［その2］ | gihyo.jp
前回紹介したように、手元のCore i7 CPUを使った開発機ではカーネルやGCCといった大規模なソフトウェアをmakeの-jオプションを使って並列度を上げてビルドしようとするとCPUの温度が危険なほど上昇してしまいます。この問題が起きるのは「大規模なソフトウェアを並列度を上げてビルドする」というかなり限定された場合のみなので、並列度を下げることで問題を回避することは可能ですが、そうするとビルドにかかる時間がずいぶん長くなってしまって不便です。 何かいい方法はないかなぁ……、と考えているうちにCpufreqと呼ばれる動作周波数数管理機能のことを思い出しました。 Linuxの動作周波数管理機能 去年買ったCore i7の動作周波数は2.93GHzだったように、最近のCPUの動作周波数は2GHzを大きく超えています。CPUの動作周波数は高ければ高いほど、1秒あたりの処理回数が増えて性能は向上し
本格派エンジニアの工具箱：第14回 Ruby on RailsライクなJavaフレームワーク「Play Framework」｜gihyo.jp … 技術評論社
Play Frameworkとは 「Play Framework」（日本語サイトはこちら）は、Rub on RailsライクなJavaアプリケーション開発フレームワークです。簡単なコマンドの実行でアプリケーションの雛形を構築し、手軽に開発をスタートさせることができます。構築されるアプリケーションの雛形はモデル、ビュー、コントロールの3つのパーツから構成され、データベースシステムとJavaの永続化機能によるモデル、テンプレートエンジンを利用したビュー、Javaプログラムで記述するコントロールをシームレスに連携させたアプリケーション開発を行うことが可能です。 Play Frameworkの大きな特徴のひとつは、JavaコードやHTMLファイル、テンプレートファイルなどを修正しても、コンパイルやサーバへのデプロイ、サーバの再起動などを一切することなく、ブラウザでWebサイトをリロードするだけで
第5回 自分の業務を書けますか、説明できますか？ | gihyo.jp
おおよその業務改善の目的・目標などが定まり、改善の対象範囲・部門、初期の中核（コア）メンバーも決まったら、次にやることは業務の実態はどうなっているのか、つまり「己を知る」ということです。 最初に、ドキュメントがちゃんとあるかを調べます。ここで言うドキュメントとは、“規程”“マニュアル”などです。ないところは少ないでしょうが、これが後々、業務改善を進めていくと、意外な鍵になる場合が少なくありません。 規程を調べる まず規程ですが、押さえておくべきなのは、 「業務分掌に関する規程」 「組織に関する規程」 「決裁権限に関する規程」 の3つです。規程はほかにもありますが、最低限、この3つが初期段階では重要です。この3つは、企業によっては1つの規程に取りまとめられていたり、「決裁、権限に関する規程」は「稟議規程」などのほかの規程に包括されている場合もあります。 「業務分掌」には、一般に部門
第8回 Perlによる大規模システム開発・設計のツボ（3） | gihyo.jp
技術的負債の「見える化」 どのようなソフトウェアにも設計上のミスはあります。設計時点ではサービスの発展性や日々変わりゆく要件を完全に予測することはできないからです。ある時点で正しい設計も、その次のサービスリリースでは設計上の修正を必要とするかもしれません。これらの変更への粘着性や複雑性のある状態を、「技術的負債」と言います。 mixiでは技術的負債は長らく、コードレビューや技術力の高いエンジニアによる新機能リリース時の修正などで対応を行ってきました。しかし、これまでに紹介した「わかりやすいコードの指針」や「アーキテクチャパターン」をレビューや教育だけで維持することは、ソフトウェアが巨大になり、開発者数が増加するにつれて難しくなります。そのため現在では、ソフトウェアの設計品質評価を自動化するツール群を開発し、それらを用いて技術的負債を見える化し、計画的に解消していく試みを行っています。 コ
第183回 ハードウェアから温度情報などを取得する | gihyo.jp
気温の上がる夏[1]は、コンピューターの筐体内の温度も高くなりがちです。そこで今回は、温度監視のトピックをお届けします。 Linux Hardware Monitoringプロジェクト LinuxにはLm_sensors（Linux hardware Monitoring）というプロジェクトがあります。このプロジェクトは、コンピューターを構成する部品のうち、マザーボードやCPU、グラッフィックカードに搭載されているセンサーから各種情報を取得することを目的としています。取得することのできる情報は温度に限らず、稼働電圧、ファンの回転数なども含まれます。 Ubuntuに導入するには、UbuntuソフトウェアセンターやSynapticパッケージマネジャーでパッケージ「lm-sensors」をインストールしてください。 センサーに対応するカーネルモジュールの特定 lm-sensorsは、各種情報を取
第182回 Taskwarriorでターミナルからタスクを管理する（1） | gihyo.jp
Ubuntuには様々なタスク管理ツールが存在します。代表的なものは第78回で紹介したTasqueですが、これ以外にも第171回のTomboyなどを用いてタスクを管理することができますし、Webサービスを直接利用することを含めれば、無数の選択肢があります。今回はその中でもひと味ちがったタスク管理ツール、ターミナル上で動作する『Taskwarrior』を紹介します。 Taskwarriorの導入 Taskwarriorは、ターミナル上で動作するToDo/タスク/プロジェクト管理ツールです。単純なToDoアイテム管理ツールに留まらず、バーンダウンチャートなどの各種チャートの生成機能・レポートツールなどを備えています。ただし、2011年7月現在、UI部分は英語のままなので、英語に苦手意識があると、慣れるまでは少々厳しいかもしれません[1]。とはいえ、日本語のタスク名称等は登録できるので、平易な英
第181回 Avidemuxで動画の変換をする | gihyo.jp
今回は「MADを作ってみよう第2弾」ということで、動画編集に関するレシピをお届けします。 前回扱ったKdenliveは、複数のファイルを組み合わせてビデオを作成する目的には適しているのですが、ひとつの動画ファイルに対して変換や補正、抽出を行うには少々おおげさな印象を受けます。今回ご紹介するAvidemuxは動画ファイルのコンバーターであり、筆者はkdenliveで取り込むクリップの下処理に利用しています。 Avidemuxとは AvidemuxとはLinuxではもちろん、WindowsやMac OS X、BSDでも利用可能なビデオ編集ソフトウェアです。kdenliveとは異なり、ひとつのビデオファイルに対する操作を主眼としているため、リニア編集ソフトウェアと呼ぶのがふさわしいかもしれません。 マルチプラットフォームに対応するためにさまざまなフレームワークを利用しています。音声の入出力にSD
第5回 これからHadoopを活用するエンジニアが理解しておくべきこと | gihyo.jp
第4回まではHadoopの活用事例や、どのような用途に向いているのかということを中心に解説してきました。さて、最終回となる第5回は、Hadoopをこれから活用し始めようとしているエンジニアが理解しておくべきことや、情報収集のポイントなどについて解説します。 Hadoopの構成要素を理解する Hadoopの導入を検討する際には、まずは構成要素を理解しておきましょう。Hadoopは大きく2つの要素から成り立っています。1つは分散ファイルシステムの「Hadoop Distributed File System（HDFS）」、もう1つは分散処理フレームワーク「Hadoop MapReduce（MapReduceフレームワーク）」です。どちらも大量のサーバから構成されるクラスタシステムとして動作します。現在はWebから得られる情報や書籍が充実しているのでここでは詳しい説明はしませんが、こう
第180回 KdenliveでH.264/AACなMADムービーを作る | gihyo.jp
今回はノンリニアビデオ編集ソフトウェアであるKdenliveを使い、映像圧縮にH.264（MPEG-4 Advanced Video Coding）、音声圧縮にAAC（Advanced Audio Coding）を利用し、MP4コンテナにデータを突っ込んだビデオを作成する方法をお届けします。 ノンリニアビデオ編集とは ノンリニアビデオ編集は、デジタル化したビデオ情報をソフトウェア的に加工していく方法です。 「ノン」というからにはリニアなものもあり、こちらはビデオ情報をテープに記録して扱う場合の編集方法です。テープを再生するためのデッキと録画するためのデッキの2台を用意し、必要な箇所だけを成果物となるテープにダビングしていきます。 ノンリニアビデオ編集のほうがより自由度の高い編集が可能ですが、映像と音声がセットとなったビデオ情報をコンピュータで扱うため、その分、ある程の性能でなければ作業
第12回 Echo Web FrameworkのクライアントサイドAPIによるWebアプリケーションの作成 | gihyo.jp
JavaScriptによるWebアプリケーションの作成 前回は、軽量Webアプリケーションフレームワークのひとつである「Echo Web Framework」（以下、Echo）について、サーバサイドのJava用APIを利用してWebアプリケーションを作成する方法を解説しました。EchoのサーバサイドAPIを利用した場合、HTMLを一切記述することなく、JavaプログラムだけでWebサイトのUIが構築できます。 その一方で、EchoにはJavaScriptによるクライアントサイド用のAPIも用意されています。これを利用した場合、今度はサーバ側のプログラムを一切記述することなく、JavaScriptと最小限のHTMLだけでUIが構築できます。サーバサイド／クライアントサイドで、それぞれ個別に、同等のUIを実現するAPIを備えているというのがEchoの特徴なのです。今回はクライアントサイドのJ
第2回 業務改善のキッカケ――“気づきのプロセス”と“自分が困るプロセス” | gihyo.jp
業務改善の“やらされ感”をなくする方法とは 傍観者ばかりの“無関心な現場”で進める業務改善。あなたが部門の責任者や、改善活動の事務局など改善活動を率先する立場だったら、どのように進めていくでしょうか？ 一般に、業務改善は即効性のある効果が期待されることが多く、どうしても現場には「改善効果のアウトプット」が早く求められます。しかし、そこには動かない現場。変わりたくない社員という大きな壁が立ちはだかります。あなたはそんな現場に対して、イラッとしてしまうかもしれません。 「二度とやるものか…」と思っている社員に対して、頭ごなしに「やれ！」と言っても、うまくいかないのは目に見えています。改善に対する“やらされ感”をなくし、当事者意識を持たせていくかが業務改善の成功の鍵となります。 今回は、この“やらされ感”をいかに感じさせることなく、自ら積極的に関わっていくようにしていくかを考えてみま
第9回 MODxとMySQLの関係 + おまけスニペット | gihyo.jp
はじめに 連載開始からしばらく経ちました。今では多くの皆さんが快適なMODxライフをお過ごしかと思います（笑）。一方で、既存サイトのコンテンツが多い、複雑といった事情から、なかなかMODxやCMSの導入に踏みきれない方もいらっしゃるのではないでしょうか？ 今回は、バックエンドデータベースから見たMODxについて解説していきます。データベース側の構造を知ることで、既存サイトのコンテンツをひとつひとつコピー＆ペーストし、管理画面から登録するのではなく、データベース側からサイトを半自動的にマイグレーションする、という手段を検討することができ、より効率的な運用管理を目指すことができるようになります。 前回紹介したように、MODx-2.1からはMS SQL Serverがサポートされるようになりましたが、実績の面からはMySQLを使う方が間違いなく無難です。今回もMySQLを前提とした解説を行っ
第11回 JavaのみまたはJavaScriptのみでのWebアプリケーション開発が可能な「Echo Web Framework」 | gihyo.jp
本格派エンジニアの工具箱 第11回JavaのみまたはJavaScriptのみでのWebアプリケーション開発が可能な「Echo Web Framework」 Echo Web Frameworkとは 「Echo Web Framework」（以下、Echo）は、Ajaxに対応したオープンソースのWebアプリケーション・フレームワークです。Webアプリケーション開発向けのフレームワークは無数に存在しますが、Echoがそれらのフレームワークと大きく異なるのは、サーバサイドのJavaコードのみによるアプリケーション開発と、クライアントサイドのJavaScriptのみによるアプリケーション開発の両方を同時にサポートしている点です。 Javaコードによるアプリケーション開発では、AWT/Swingに似たコンポーネント・ベースのプログラミングモデルによってUIを作成します。クライアントとサーバとの通信
第1回 バーストトラフィックの発見と対処 | gihyo.jp
はじめに 初めまして、（株）ミクシィの中野和貴です。私はシステム本部運用部インフラグループネットワークチームという部署で働いており、ほかのメンバーと共にmixiのネットワーク部分全般に関して設計・保守・運用を行っています。ここでは『WEB+DB Press』Vol.50～55にて連載されていた「大規模Webサービスの裏側」で紹介しきれなかったエピソードや、その後のインフラ事情を紹介していきます。 日々大量のトラフィックが流れるmixiのネットワークですが、大きくなってくるとやはりいろいろな問題も出てきます。今回はそれらの問題の中で普段運用しているとなかなか気付きにくいバーストトラフィックに起因する問題事例を紹介します。 ミクシィのネットワーク構成と問題の発覚 mixiでは主要なネットワーク機材にはお金をかけていますが、サービス規模からどうしてもラック数が多くなってしまうため、エッジスイッ
第177回 サウンドシステムの使いこなし | gihyo.jp
本連載ではこれまで十数回にわたり、Ubuntuでサウンドを扱う話題を紹介してきました。Ubuntuのサウンド環境はALSA、PulseAudioそしてJACKなどといった複数のソフトウェアで構成されているため、そろそろ混乱してくるころです。というわけで今回は、UbuntuもといLinuxの現在のサウンドシステムに関して、MIDIも考慮しながら整理してみたいと思います。 ALSAの役割 ALSAとはAdvanced Linux Sound Architectureの略称で、Linuxにおける高機能なサウンドシステムを提供するためのソフトウェア群です。「Advanced」ということは「Advancedでない」ものがあるわけで、それが本連載の第144回でお伝えしたOpen Sound Systemです。Open Sound Systemには同時に音声を出力出来るソフトウェアの最大数が４つ、多チ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
