BPStudy#120の発表資料です。 board(https://the-board.jp/ )を立ち上げて事業として成立するようになるまでの取り組みを発表しました。
ファイルシステムとはファイルとしてデータを扱う仕組みだ。 このページでは、Linuxのファイルシステムの作成方法について一通りまとめている。 実際の運用でファイルシステムを変更するような機会はなかなかないと思うが、LPICの出題範囲でもあるし、Linuxの理解を深めるという意味でも、概要は掴んでおきたい。 OSの基本機能の一つだ。ファイルシステムは「ファイルをとり扱うための枠組みと方法」を指す。 ファイルシステムがないと、データを読み出すときにも「192588セクタと192589セクタのデータを取り出す」といったよくわからない指示をしなければならない。 セクタとはディスクの区画のことで、コンピュータはデータを取り出すときこれを見に行っている。しかし、数字での管理は人間にとってとてもわかりにくい。 ファイルシステムを使うと、「/etc/test.txtファイルを開く」などのように人間でもわか
ビジネスの俊敏性を支えるための 実践的アプローチを整理 厳しい競争のなか、企業は“変われる”、すなわち施策を迅速に実行に移せる俊敏性を求められている。 では、どうすれば俊敏性を高められるのか。1つの解を示すのが、ビジネスアーキテクチャという考え方だ。 本パートでは、ビジネスアーキテクチャの考え方と、 その実現に向けてIBMが提唱する実践的アプローチを解説する。
はてブではすでにボロクソ言われてますね。フラグ立ちまくりと。ちょっとこれは解説せねばなるまいか… 以下はすべてとある人からの伝聞です。伝聞なんだってば。 みずほ銀行が次期システムの開発をマルチベンダー体制で進めることが日経コンピュータの取材で判明した。富士通、日立製作所、日本IBM、NTTデータの4社に分割発注する。 [スクープ]みずほの次期システムはマルチベンダー、4社に分割発注 | 日経 xTECH(クロステック) 周知の話だけすると、現行システムにおいては 勘定系(ホスト)…富士通 営業店端末システム…富士通 インターネットチャネル(ダイレクトバンキング)…IBM 情報系システム…IBM 周辺系(中継系)…IBM 外部接続系…日立 コーポレート銀行勘定系…日立 等々、すでにここに出てきているベンダーがマルチベンダーの状態で仕事をしている。また、ここ重要なところだと思うけれども、ベンダ
0x00. はじめに 筆者はJava製のWAF(Web Application Firewall)、Guardian@JUMPERZ.NETの開発とメンテナンスを行っている。元は自社のシステムを守るために(そして半分趣味で)作ったものだが、数年前にこれをコアのエンジンとしてさらに拡張し、SaaS型の商用サービス「Scutum(スキュータム)」を立ち上げた。 その後順調に顧客を獲得することができ、システムリソース的にも増強が必要となる段階などを経験した。Google、mixiやはてな等、さまざまな大規模サイトのインフラエンジニアの方々がインフラ設計に関する考え方などをインターネット上で公開してくれているおかげで、初期のシステム設計時に「将来的にスケールアウト可能なシステム構成にしておくこと」が重要であるということがわかっていた。その教えに従っていたおかげで、リソースの逼迫(ちなみに今回はCP
先月末に、塩見卓也弁護士が、ついった上で http://twitter.com/#!/roubenshiomi/status/130875404641763328 >本日、過労死ライン以上働かされ耐えられずに退職を申し出たところ、会社から損害賠償請求すると言われ、退職したら本当に2000万円を請求する訴訟を起こされた件の判決がありました。会社の請求は全部棄却。こちらの反訴請求は、未払残業代と付加金を併せて1100万円以上が認容されました。 とつぶやいていた事件の判決文が、さっそく最高裁のHPにアップされました。 それだけの値打ちのある判決だと思われたわけですね。 これです。 http://www.courts.go.jp/hanrei/pdf/20111129185940.pdf 会社側が、この労働者に「2000万円払え!」と訴えた甲事件については、 >本件においては,被告BあるいはCチー
ソフトウェアの欠陥の原因 † エラー(error) 「間違った結果を生み出す人間の行為」 フォールト(fault) 「要求された機能をコンポーネントまたはシステムに果たせなくする、コンポーネントまたはシステムの中の不備」 ≒ バグ、欠陥 プログラマのエラー(error)によって、プログラムにフォールト(fault)が埋め込まれる 故障(failure) 「コンポーネントやシステムが期待した機能、サービス、結果を提供できないこと」 フォールト(fault)が、発現して故障(failure)になる。 フォールト(fault)のあるコンポーネントが使われることがなければ故障(failure)は発生しない フォールト(fault)が無くても、放射能や電磁波、コンピュータウイルスにより故障(failure)が発生する インシデント(incident) 「ソフトウェア・システムを実際に使うユーザやテス
情報システム部の存在意義は、ITサービスを通したユーザ利便性の向上にあります。ITサービスとは単一、もしくは複数のシステムによって提供されるものですから、新しいシステムを企画立案して運用に漕ぎつけるまでの流れは、情報システム部の主たる業務と言えるでしょう。 新しいシステムを構築するためには、企画段階で得た構想を要件レベルに具体化し、システム設計者に引き渡します。企画をした人間が設計・構築・テスト・リリースまで担当できるにこしたことはないのですが、上流工程を担当する人間はスキルセット上、高コスト(月単価150万円以上)であることがほとんどですし、そもそも社内でシステム実装スキルを有する人間を必要数確保できないという根本的な課題もあって、要件定義フェーズ以前と設計フェーズ以降では担当者が異なることが多いのが実情です。 そこで要件定義フェーズで整理したことを正確に設計フェーズにつなげるために用い
何が良いプログラムかという点はもちろん人やコンテキストによって異なりますが、少なくともプログラマーとしての私の信念としては、 機能拡張や変更が容易なプログラム 単体試験によって正しく動作することの検証が容易なプログラム どういった内容が記述されているか理解しやすいプログラム といったものこそ、「品質の高い」プログラムが持つべき性質として、まず真っ先に挙げるべき事項であると考えています。もちろん、前提として顧客の要件に従うということは大切なことです。しかし、一般に要件は長期にわたって変更されるものですし、使い捨てのプログラムを除けば、プログラムを長期にわたって保守するコストという点も見過ごすべきではありません。したがって、ユーザーの目には触れない上記の性質をもっと重視すべきだと思うのです。 DRYの原理 上記のような性質を満たすプログラムを作る上で大切になってくる原理として、DRYの原理とい
前回のエントリいまさらですが、職業Javaプログラマーなら理解しておいてほしい「継承」の意味についてのブクマのコメントで、 すごく今さら感がw 最近の開発はフレームワーク使うことが多いようだから知らなくても作れちゃうと思ってたけど違うのかなあ。 という感想をいただきました。実際に、SI業界で多くの方々、特に、アプリケーション開発の下流工程を担当しない層の方でこのように考えている方はほんとうに多いのではないかと思います。確かに最近ではSalesforceなどの製品もありますし、CRUD処理を行うような見栄えの良い業務アプリケーションは非常に簡単に開発できるようになっているということはあります。また、Visual BasicやMS Accessなど気軽にアプリケーションを開発できるツール類は昔からありました。そして、業界構造などの理由からやむを得ない側面があるとはいえ、SIerの提供する多くの
システムインテグレータ(SI)のビジネスは大きく以下のような流れで進みます。 集客 営業 要件定義 製造 検収・請求 フォローアップ 集客 どんなビジネスでも同じですが、まずは見込み客を集めます。システム開発に興味を持ったお客様を探しアポイントを取ります。よく使われる手法に商品・サービスの説明をするテレアポ、割引を謳ったDM、自社の推す技術のセミナー、役員が個人的に懇意にしている既存顧客の紹介があります。会社の規模やブランドにマッチした手法を選ぶ必要がありますが、会社が成長にするにつれ手法を変えていかなければいけないのが難しいところです。 営業 アポイントの取れたお客様に顧客に直接、自社の提供するサービス、商品の説明を行います。また会社の紹介も同時に行います。お客様がある程度の金額を掛けてソフトウェア開発を行いたいと意思表示をされた場合に次の段階に入ります。そこで現状の課題を聞き出します。
Satohru Note(http://satohru.blogspot.jp/)では、ITに関する考察や作品(写真、小説、音楽)の掲載などを行っています。 新作小説『エクストリームセンス』連載中。 【案内】小説『エクストリームセンス』について 小説『エクストリームセンス』は、本ブログを含めていくつか掲載していますが、PC、スマフォ、携帯のいずれでも読みやすいのは、「小説家になろう」サイトだと思います。縦書きのPDFをダウンロードすることもできます。 小説『エクストリームセンス』のURLは、 http://ncode.syosetu.com/n7174bj/ 私は先日、KenichiroMurata氏のブログ「要件定義の怪物、ビジネスルールをいかにして仕様化するか?」を読みました。これは、システム開発の上流工程に携わる人々にとって、大きなテーマだと思います。 私は富士通グループの開発者と仕
アップグレードの前には、5章squeeze で知っておくべき問題点 に書かれている情報も読むことをお勧めします。この章に書かれている問題点は、アップグレードの過程と直接は関係がないかもしれませんが、それでもアップグレードを開始する前に知っておくべき重要事項である可能性があります。 システムをアップグレードする前に、完全なバックアップを取っておくよう強くお勧めします。少なくとも、失いたくないデータや設定情報だけでもバックアップしておきましょう。アップグレードのツールや処理はきわめて信頼性の高いものですが、アップグレードの最中にハードウェア障害が起こると、システムに大きなダメージを与えることがありえます。 バックアップしておくべき主な対象として、/etc、/var/lib/dpkg、/var/lib/apt/extended_states の中身、dpkg --get-selections "
情報処理推進機構(IPA)は5月20日に、IT人材に関する調査結果をまとめた「IT人材白書2011~未来指向の波を作れ 今、求められる人材イノベーション~」を発行した。本特集では、「IT人材白書2011」の調査結果を抜粋して、5回に分けて解説していく。 第1回目の今回は、IT企業およびユーザー企業における、IT人材の「量」と「質」に対する過不足感の変化と、グローバル化がIT技術者に与える影響について見ていこう。 8割以上の企業が、IT人材の「質」に不足感 まずは、IT企業における、IT人材の「量」と「質」に対する過不足感を見てみよう。 図1と図2は、IT企業に対して「御社では、事業戦略上必要なIT人材を、現在、十分に確保できていますか。『量』と『質』の両面における御社の人材の過不足感として、当てはまる番号に○をつけてください」と尋ねた結果である。選択肢は、「大幅に不足している」「やや不足し
私の所属している会社では、2年程前にバージョン管理システムをSubversionからGitに移行し、現在まで開発フローを試行錯誤してきました。ようやく形になってきたということで、守秘義務に接触しない程度に紹介&考察していきたいと思います。 形になってきたとはいえ、まだまだ試行錯誤中ですので色々なツッコミは大歓迎です。 現在の開発フローの俯瞰図# 現在の開発フローを俯瞰してみると大体下記図のような感じになっています。途中で図を書くのが面倒になった都合上、Jenkinsさんが1人しか居ませんが、実際はmasterブランチの他にreleaseブランチも監視してもらっています。 以降この図を元に話を進めていきたと思います。 Gitoriousを利用して自由に開発# GitoriousというGitHubに似たサービスがあります。このGitoriousはオープンソースとしても公開されていますので社内に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く