平素は株式会社ライブドアのサービスを ご利用いただきありがとうございます。 提言型ニュースサイト「BLOGOS」は、 2022年5月31日をもちまして、 サービスの提供を終了いたしました。 一部のオリジナル記事につきましては、 livedoorニュース内の 「BLOGOSの記事一覧」からご覧いただけます。 長らくご利用いただき、ありがとうございました。 サービス終了に関するお問い合わせは、 下記までお願いいたします。 お問い合わせ ※カテゴリは、「その他のお問い合わせ」を選択して下さい。
![BLOGOS サービス終了のお知らせ](https://cdn-ak-scissors.b.st-hatena.com/image/square/ea13b559ab8a92213578f10c01241372b4e3e3fe/height=288;version=1;width=512/https%3A%2F%2Fblogos.com%2Fimg_ogp_blogos.jpg)
Linuxにソフトウェアをインストールするという作業には、かつてほどではないものの、注意すべき落とし穴がまだいくつか存在している。しかし、本記事で紹介している項目を参考にすることで、あなたのLinuxライフはよりシンプルで安全なものとなるはずだ。 #1:.rpmや.debを採用しているシステムにもかかわらず、ソースコードからイントールを行う Linux初心者の中には、OS上にインストールされるすべてのアプリケーションが、rpmやapt(あるいはdpkg)といったパッケージ管理システムによって管理されるということすら知らない人も多い。とは言うものの、こういったシステム(rpmやapt、dpkg)が管理できるものは、当該システムを用いてインストールしたアプリケーションに限られるのである。このため、ソースコードだけが提供されているようなアプリケーションを入手し、自分自身でコンパイルしたとしても、
NTT オープンソースソフトウェアセンタ 板垣 貴裕 PostgreSQL でロケール (国際化と地域化) の設定を行うと、データベース内での文字列処理、日付や通貨の表示、メッセージの言語などを変更することができます。特に PostgreSQL 8.4 では、日本語のメッセージ・カタログが追加されたため、エラーメッセージを日本語化したい場合にはロケールを設定する必要があります。 ただし、C ロケール以外を設定すると、インデックスが使われないなどの性能への影響がある場合もあります。また、特に古いバージョンの PostgreSQL では、誤った設定によりサーバが正しく動作しなくなるケースもありました。 この記事では、ロケール設定の効果を結果例を交えて解説すると共に、トラブルへの対応方法を示します。PostgreSQL で日本語を扱う際に、ロケール設定を決める時の参考にして下さい。 Postgr
スクラムとCMMIの基礎知識 では、スクラムとCMMIの対比に入る前に、まずはそれぞれの基礎を簡単に振り返っておきましょう。以下の図1をご覧ください。これはスクラム開発の流れを簡単にまとめたものです。 スクラムでは、まず「プロダクトバックログ」を管理します。システムが備えるべき機能をエンドユーザー視点でまとめたものを「ユーザーストーリー」と言いますが、プロダクトバックログとは、それを機能単位に分割し、一覧にしたものです。例えば、オンラインショップのシステムなら「新規ユーザーを登録する」 「商品を検索する」などです。プロダクトバックログは、真ん中の大きな輪で示した「スプリント」に回され、開発作業に入ります。 「スプリント」とは、2~4週間のサイクルで繰り返し行う「作業時間の単位」です。ここでは、開発するプロダクトバックログを管理可能な単位に分割した「スプリントバックログ」という概念が存在しま
仮想環境ではゲストOSとネットワークに無数の脆弱性が存在する。ハイパーバイザー攻撃の成功を許せば、壊滅的な結果を招きかねない。ただし、適切な計画を立ててデータ保護の強化を図れば、仮想環境とハイパーバイザーの脆弱性を最小限に抑えることが可能だ。 セキュリティ対策は事後に追加するよりも、システム(OSやハイパーバイザーなど)に組み込んだ方がいいという点で、ほとんどのセキュリティ専門家の見解は一致する。だが、多くの主要なハイパーバイザーが設計された当初は、ハイパーバイザーにセキュリティ対策を組み込むのは難しかった。サーバやストレージ、ネットワークといった仮想化の機能が十分に実現されているわけではなかったからだ。例えば、「VMware vMotion」のようなモビリティツールは、2001年にVMware ESX 1.0が登場してから2~3年後にリリースされた。この間にソフトウェアスタックの規模と複
「私物モバイルデバイスの業務利用は、日本が最も遅れている」という調査結果をジュニパーネットワークスが発表した。私物デバイスを業務に利用している比率は、世界全体で56%だが、日本では33%と約半分だという(関連記事)。 半分なのは事実だとして、「遅れている」と言われると日本人としては面白くない。別になんでもかんでも欧米のあとを追いかけなくてもいいのではとも思う。日本のBYOD(私物デバイス活用)は本当に“遅れている”のだろうか。 多くの調査が示す日本の私物利用の少なさ そんなことを考えたきっかけはジュニパーの調査だが、ほかの調査でも日本と海外での違いは大きいという結果が出ている。 ESETは米国の従業員の81%が何らかの私物デバイスを仕事に使用しているという調査結果を発表している(関連記事)。 これに比べ、日本での私物利用の割合は少ない。ITproが実施した読者アンケートでは「私物デバイスを
システムの寿命が延びている。最新の結果では14.6年で、この5年で約1年伸びた。一方、システム構築プロジェクトの成功率は高くはない。500人月以上のプロジェクトでは、40.5%が工期遅延、34.8%が予算超過、26.2%で品質の不満、に遭遇している。IT投資評価についても課題が多い。 ビッグデータやクラウドなど、ITのトレンドは目まぐるしく変わる。一方で、事業の根幹を支えるシステムは、そう簡単にスクラップ&ビルドできるものでもない。中期的な視点でIT戦略を立案・実行する必要がある。 前回はクラウドやポストPC端末といった新しいITの導入状況について紹介した。今回は視点を、企業の基幹系システムに移し、システムの寿命やシステム構築プロジェクトの成功率、IT投資評価の実態などについて見ていこう。前回同様、日本情報システム・ユーザー協会が実施した最新の調査結果「企業IT動向調査2012」(調査概要
勘定系システムの開発失敗を巡るスルガ銀行と日本IBMの裁判について、東京地方裁判所が3月29日に下した判決の詳細が明らかになった。日経コンピュータは『スルガ銀が事実上の全面勝訴 IBMの責任認めた判決の深層』として判決の概要とその影響を速報した。ただ、日本IBMが判決について閲覧制限を申請していたため、これまでは約74億円の賠償を命じた判決理由は公開されていなかった。 今回、本誌が入手した判決文によれば、日本IBMが敗訴した最大の理由は、同社が米フィデリティ・インフォメーション・サービス(FIS)の勘定系パッケージソフト「Corebank」の選定に際し、リスクの回避策など十分な検討を怠った点(図)。上流の工程で日本IBMに重大な不備があった以上、スルガ銀が支払った費用は全て返還すべきという論理だ。 東京地裁は合計3回実施した要件定義が迷走したことを判断根拠とした。日本IBMは1回目の要件定
みなさんこんにちは。@ryuzeeです。 昨日Twitter上で@yujioramaさんから「これは成功すると思えたスクラム導入の兆しとか読んでみたいです!」という要望を頂いたので個人的な見解を書いてみたいと思います。 なお、僕は基本的に、技術力とかツールの話以前の話としてチームの態度や周りとの協調関係を重視しているので、主にそういう観点が多いことを念頭においておいてください。 プロダクトオーナープロダクトオーナーが明確なプロダクトバックログアイテムを書いている自分が書いたプロダクトバックログアイテムに責任をもっている。開発チームがプロダクトプロダクトバックログアイテムの中身についてプロダクトオーナーに確認できる開発チームが必要なときにはいつでもプロダクトオーナーにコンタクトできるプロダクトオーナーが開発チームのそばにいるプロダクトオーナーと開発チームが敵対関係でなく会話しているプロダクト
このところ「SIerの今後について」というテーマについて、意見を求められたりディスカッションしたりすることが多く、またエンタープライズ業界に身を置く立場として、売り上げ比・人口比とも業界の大半を占めるSIerが今何に取り組んでいて、今後どのようになっていくのか、というのは私自身関心のあるテーマなので、昨日は「SIerでのキャリアパスを考える」勉強会に参加してきた。 というわけで勉強会の中で印象的だったことや考えたことを書く。 勉強会の前半パートではゆもとさんによるSIerの現状分析、ひがさんによるSIerの中でのキャリア戦略が話題に上り、その中でも特に「上流と下流が工程分断されている」ことが現状のSIerを取り巻く諸問題の元凶、という指摘があった。 この「分断」については、中島聡さんの「ソフトウェアの仕様書は料理のレシピに似ている」というエントリが有名だが、今回の勉強会でのゆもとさんの資料
先日より続いているアクセス不具合についてチューニング(というほどのものではありませんが)を実施しました。何回か報告する機会がありそうなのでとりあえず「その1」に。 不具合に関連する事象で把握できているのは次の3点です。 Apache プロセスのメモリが増加し続け(メモリリーク)、1日で数百MBに膨れ上がる 何らかの契機にレスポンスが突然遅くなる(お昼休み等、アクセスが集中すると×?) Apache を再起動すればアクセスは正常になる チューニング関連の記事を調べた結果、下記の2つのディレクティブについて httpd.conf に設定することにしました。 MaxRequestsPerChild これは個々の子サーバが稼働中に扱うリクエスト数の上限で、このディレクティブに設定された値を超えると子プロセスは終了(再起動)します。デフォルトは 0(=子プロセスを終了しない)ですが、現在は 5000
403 error - Forbiddenで発表させて頂きました。発表資料をSlideShareにあげました。ご自由にダウンロードしてください。 あと、当日は結婚のお祝いということでケーキを頂いてしまいました。ひがさん、山岡さん、笠木さん、ごちそうさまでした&ありがとうございましたー! SIerでのキャリアパスを考える発表資料 View more presentations from Michitaka Yumoto 15分では全然伝えきれなかったので、下記によくわかる解説を加えておきます。資料の向こう側にある背景を掴んでください。 何を話そうか最後まで悩んだんですが、今までブログで僕が問題提起しているSI業界構造の問題を再認識してもらい、「問題が問題であることを認識してもらってから、次のアクションを考えてもらえるきっかけの一助に」という狙いから、上記のような資料になりました。僕が今まで問
全文は紙面でないと読めないのが残念ですが、非常に気になるニュースが飛び込んできました。 富士通、余剰SE変身作戦 富士通がグループで抱える約3万人のシステムエンジニア(SE)の大がかりな職務転換に乗り出した。一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むSEは仕事がなくなり、余剰人員問題が顕在化するからだ。野副州旦元社長の急進的な改革路線を修正した富士通はSE余剰問題で軟着陸を目指すが、クラウドの奔流にのみ込まれる危うさもはらむ。 富士通、余剰SE変身作戦 実は富士通グループさんには弊ブログを頻繁にご覧頂いておりまして、企業ドメインの中では最もアクセスの多いドメインであります。クロールしにきているのかなと思うぐらい。ブログで言及している「なんでもかんでも受託開発では、もうSIビジネスで成長することは出来ない」という危機
次期年金システムの開発プロジェクトが、発注の失敗をきっかけに1年以上停滞していることが本誌の取材で明らかになった。設計作業を受注したIT企業の1社が役目を果たせず途中でギブアップし、再発注がなされないままの状態になっている。税と社会保障の一体改革をめぐる政治の混乱もあり、再開のメドは立っていない。 ストップしているのは、オープン化を目指す次期年金システムのプロジェクトだ。厚生労働省は「年金記録問題」が表面化した後、既に着手していた基本設計の一部をやり直す「補完工程」を3社に分割発注した(図)。3社のうちシステム基盤設計を3億8640万円で受注したユーフィット(現TIS)が、契約を履行できなかった。 アプリケーション設計を担当したNTTデータと工程管理支援を受注したTDCソフトウェアエンジニアリングは、それぞれ「契約どおりに作業を進めた」(厚労省年金局)。一方、システム基盤設計の進行は遅れた
某セッションでちょっとしゃべったことをつらつらと。SIの現状と近い将来について思うところをまとめておきます。自分自身の立ち位置も確認していくという意味で。 結論的にいうと、SI自体は必要とされていますが、SI屋さんのビジネスモデルは成立しないという状況になるので、旧来の「SI屋さんの方法」ではうまくいきません。なので、別のやり方でSIをどうやっていくか?という議論が必要になりますね、という話です。 まずSI事業は人月稼働で商売をしています。スタート地点はそうではなかったのですが、一旦大きな人数を抱えると、食わせる必要があるため、より大きな仕事を取る羽目になります。要は稼働させる事、それ自体が目的になります。稼働を維持させる事で、収入を確保する事ができ、確保された収入で稼働のための人員を維持できる。そもそもそういう循環をベースに組織の目的が、「結果として」形成されてしまっています。 副作用と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く